Ho avuto alcuni problemi di sicurezza con un mio server, alcuni utenti SSH hanno creato incendi o problemi.

Mi piacerebbe:

• Tieni traccia degli accessi e dei logout degli utenti
• Traccia l'attività di questi SSH, al fine di scoprire eventuali attività dannose
• Impedire agli utenti di eliminare i registri

Non sono un amministratore di sistema e sono abbastanza inesperto in questa materia, quindi qualsiasi tipo di consiglio sarebbe molto gradito e molto utile. :)

Dal momento che stiamo parlando di server SSH, ti darò soluzioni da riga di comando.

• Tieni traccia degli accessi e dei logout degli utenti. È facile, il file /var/log/auth.logdovrebbe contenere queste informazioni.

• Traccia l'attività di quegli utenti: se sono abbastanza innocenti, puoi controllare il file .bash_historynella loro home directory . Vedrai un elenco dei comandi che hanno eseguito. Il problema è ovviamente che possono eliminare o modificare questo file.

• Impedire agli utenti di eliminare i registri: gli utenti non dovrebbero essere in grado di toccare auth.log. Per impedire loro di giocare con .bash_historyte, devi fare un paio di trucchi .

• Cosa succede se l'utente riesce ad ottenere l'accesso come root? : Sei fregato. A meno che non commettano un errore, saranno in grado di nascondere tutti i loro passi.

[DISCLAIMER] Mi rendo conto di essere in ritardo alla festa, ma vorrei incollare una risposta che ho dato a un'altra domanda , perché sento che può offrire una buona intuizione ai lettori e questa domanda sembra essere la scelta giusta posto per informazioni ssh di base.

C'è stato un problema simile che mi ha colpito dopo aver letto questa domanda qui su AskUbuntu e aver verificato il mio VPS, solo per vedere un bazillion di tentativi di forza bruta. Questo è quando ho deciso di agire.

Ora, in base alla domanda a cui mi sono collegato, se desideri vedere tentativi di accesso non riusciti sul tuo computer su ssh (potrebbero essere tentativi di forza bruta o altro), prova a digitare questo:

grep sshd.\*Failed /var/log/auth.log | less

Se l'output è costituito da più righe, ovvero molti tentativi di forza bruta, soprattutto se si sono verificati tra brevi intervalli, è possibile che si desideri eseguire le seguenti azioni:

Modifica il file di configurazione ssh

Per fare ciò, apri il file che si trova in / etc / ssh / sshd_config con il tuo editor preferito, in questo modo vim /etc/ssh/sshd_config.

1. Prova a spostare ssh dalla porta 22 : ora individua la riga che dice:

# What ports, IPs and protocols we listen for
Port 22

e commentare Port 22, e usare chiunque ti possa piacere. Esempio:

# What ports, IPs and protocols we listen for
# Port 22
Port 28934

Ricordare che le porte inferiori a 1024 richiedono un'autorizzazione speciale (root). Non so come ciò possa interferire con esso, ma sto solo dicendo.

2. Disabilitare gli accessi root tramite ssh : poiché il nome utente root è prevedibile e fornisce un accesso completo al sistema, fornire un accesso illimitato a questo account su SSH non è saggio. Individua la riga che legge PermitRootLogin e impostala su no .

PermitRootLogin no

3. Disabilita autenticazione password : genera e usa le chiavi SSH per accedere al tuo sistema. Senza le password abilitate, gli utenti malintenzionati dovranno indovinare (o rubare) la chiave privata SSH per accedere al server. Qualcosa che è molto molto difficile. Procedere per trovare la riga che legge PasswordAuthentication e impostarla su no

PasswordAuthentication no

!AVVERTIMENTO! Prima di farlo, consulta questa guida qui su come impostare l'autenticazione con certificato.

NOTA: dopo aver apportato le modifiche, utilizzare sudo /etc/init.d/ssh restart. Per connettersi a un'altra porta via ssh uso: ssh username@hostname.com -p <port_number>.

Installa un firewall

Consulta questa guida su come impostare il firewall estremamente potente ed efficace, integrato in Linux, IPTables .

Script di installazione per aiutarti con la sicurezza

Uno che uso personalmente e rapidamente mi viene in mente Fail2Ban . Fail2ban monitorerà i file di registro per tentativi di accesso non riusciti. Dopo che un indirizzo IP ha superato il numero massimo di tentativi di autenticazione, verrà bloccato a livello di rete e l'evento verrà registrato /var/log/fail2ban.log. Per installarlo:sudo apt-get install fail2ban

Controlla la cronologia dei comandi tramite ssh

C'è un comando linux, chiamato history, che ti permette di vedere quali comandi sono stati inseriti fino a quel momento. Prova a digitare historyun terminale per vedere tutti i comandi fino a quel momento. Potrebbe aiutare se tu fossi root .

Per cercare un comando particolare prova:history | grep command-name

Per elencare tutti i comandi dopo ssh :fc -l ssh

Puoi anche modificare i comandi usando vi (non l'ho provato vim, anche se suppongo che funzioni anche):fc -e vi

Puoi anche eliminare la cronologia :history -c

NOTA: se non sei un fan del comando historyc'è anche un file nella tua home directory ( cd ~), chiamato .bash_history (se stai usando bash) che puoi catvedere tutto ciò che è stato digitato nella shell bash.

Un po 'eccessivo, ma puoi vedere tutto ciò che viene eseguito sul tuo sistema usando il "connettore dell'evento di processo":

http://www.outflux.net/blog/archives/2010/07/01/reporting-all-execs/

1. Javier ha già risposto a questo: /var/log/auth.log
2. Ho trovato un ottimo articolo su questo qui .
3. Se i tuoi utenti non hanno accesso a root, i tuoi file di registro dovrebbero essere al sicuro. Puoi provare a creare alcune regole personalizzate nel file sudoers per limitare ciò a cui i tuoi utenti possono accedere e come. Inoltre è possibile aumentare il livello di registro per il demone sshd.

Oltre al login stesso non esiste un modo sicuro per tenere traccia / accedere alle azioni degli utenti dopo aver effettuato l'accesso, supponendo che abbiano una conoscenza di base di Linux che saranno in grado di disabilitare il log delle shell o semplicemente di eseguire comandi da altre shell (ad esempio python).

Invece dovresti essere prudente nel fornire l'accesso ssh, ne hanno davvero bisogno? Non è molto comune concedere l'accesso ssh a meno che non ci si trovi sulla shell per fornire business.