[Guida] Attacco SSH: come proteggersi!

Sistemi operativi Linux e software open source
Avatar utente
conoscenza
Messaggi: 3821
Iscritto il: venerdì 2 dicembre 2011, 23:27
Località: Parma

[Guida] Attacco SSH: come proteggersi!

Messaggio da conoscenza »

Grazie al suggerimento che ho scritto qui ieri sera mi sono accorto di essere sotto attacco SSH con modalità bruteforce (di cui non è questa la sede in cui verrà spiegato il come farlo :D ).

Uso GNOME e avendo il terminale aperto ho visto i messaggi:
[root@localhost ~]# sshd[25247]: Address 62.212.68.132 maps to hosted.by.leaseweb.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
sshd[25247]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=62.212.68.132 user=root
sshd[25247]: Failed password for root from 62.212.68.132 port 41834 ssh2
sshd[25248]: Received disconnect from 62.212.68.132: 11: Bye Bye
sshd[25250]: Address 62.212.68.132 maps to hosted.by.leaseweb.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
sshd[25250]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=62.212.68.132 user=root
sshd[25250]: Failed password for root from 62.212.68.132 port 42280 ssh2
sshd[25251]: Received disconnect from 62.212.68.132: 11: Bye Bye
...non aspettavo "ospiti" e pertanto mi sono insospettito.

La prima cosa da fare in questi casi è disabilitare il servizio SSH, meglio sarebbe tenerlo disabilitato sempre, ma ci sono circostanze che impediscono di tenerlo off.
Ho disabilitato il servizio mediante il comando:

Codice: Seleziona tutto

chkconfig sshd off
lanciato da root.

Controlliamo -inutile ma lo faccio- che sia andato off su tutti i run level:

Codice: Seleziona tutto

[root@localhost ~]# chkconfig | grep sshd
sshd           	0:off	1:off	2:off	3:off	4:off	5:off	6:off
Tolto il giochino al nostro "amico", chiudendo il servizio l'abbiamo praticamente gambizzato, controlliamo eventuali danni.
Quindi dobbiamo controllare il /var/log/secure e il listato degli ultimi utenti connessi!

Per controllare il /var/log/secure cerchiamo di "limitare" l'output mediante match con la parola ssh!
Ndr: potremmo lanciare il comando

Codice: Seleziona tutto

cat /var/log/secure | grep ssh | less

per meglio formattare la pagina e scorrerla passo passo.

Il mio listato è qualcosa del tipo:
[root@localhost ~]# cat /var/log/secure | grep ssh
.......
......
......
Dec 28 23:59:07 localhost sshd[2406]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.147.217.138 user=root
Dec 28 23:59:09 localhost sshd[2406]: Failed password for root from 221.147.217.138 port 2634 ssh2
Dec 28 23:59:12 localhost sshd[2406]: Failed password for root from 221.147.217.138 port 2634 ssh2
Dec 28 23:59:14 localhost sshd[2406]: Failed password for root from 221.147.217.138 port 2634 ssh2
Dec 28 23:59:16 localhost sshd[2406]: Failed password for root from 221.147.217.138 port 2634 ssh2
Dec 28 23:59:19 localhost sshd[2406]: Failed password for root from 221.147.217.138 port 2634 ssh2
Dec 28 23:59:21 localhost sshd[2406]: Failed password for root from 221.147.217.138 port 2634 ssh2
Dec 28 23:59:21 localhost sshd[2407]: Disconnecting: Too many authentication failures for root
Dec 28 23:59:21 localhost sshd[2406]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.147.217.138 user=root
Dec 28 23:59:21 localhost sshd[2406]: PAM service(sshd) ignoring max retries; 6 > 3
Dec 28 23:59:25 localhost sshd[2423]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.147.217.138 user=root
Dec 28 23:59:27 localhost sshd[2423]: Failed password for root from 221.147.217.138 port 2638 ssh2
Dec 28 23:59:30 localhost sshd[2423]: Failed password for root from 221.147.217.138 port 2638 ssh2
Dec 28 23:59:32 localhost sshd[2423]: Failed password for root from 221.147.217.138 port 2638 ssh2
Dec 28 23:59:35 localhost sshd[2423]: Failed password for root from 221.147.217.138 port 2638 ssh2
Dec 28 23:59:38 localhost sshd[2423]: Failed password for root from 221.147.217.138 port 2638 ssh2
Dec 28 23:59:40 localhost sshd[2423]: Failed password for root from 221.147.217.138 port 2638 ssh2
Dec 28 23:59:40 localhost sshd[2424]: Disconnecting: Too many authentication failures for root
Dec 28 23:59:40 localhost sshd[2423]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.147.217.138 user=root
Dec 28 23:59:40 localhost sshd[2423]: PAM service(sshd) ignoring max retries; 6 > 3
Dec 29 00:02:52 localhost sshd[2514]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.147.217.138 user=root

Dec 30 01:55:02 localhost sshd[25247]: Failed password for root from 62.212.68.132 port 41834 ssh2
Dec 30 01:55:02 localhost sshd[25248]: Received disconnect from 62.212.68.132: 11: Bye Bye
Dec 30 01:55:03 localhost sshd[25250]: Address 62.212.68.132 maps to hosted.by.leaseweb.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Dec 30 01:55:03 localhost sshd[25250]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=62.212.68.132 user=root
Dec 30 01:55:06 localhost sshd[25250]: Failed password for root from 62.212.68.132 port 42280 ssh2
Dec 30 01:55:06 localhost sshd[25251]: Received disconnect from 62.212.68.132: 11: Bye Bye
Dec 30 02:51:16 localhost sshd[1396]: Received signal 15; terminating.
Ovviamente è solo una parte del listato, dove mi accorgo della modalità di attacco (tenta di indovinare la password) e che dopo la sesta volta che sbaglia iptables gli chiude la porta "in faccia".

Proviamo a vedere per scrupolo caso mai è riuscito comunque a loggarsi qualche volta con il comando:

Codice: Seleziona tutto

last |head -n 20
lanciato da root.

Ho un listato tipo:
[root@localhost ~]# last |head -n 20
amabile pts/3 :0.0 Fri Dec 30 16:27 still logged in
amabile pts/2 :0.0 Fri Dec 30 14:47 still logged in
amabile pts/1 :0.0 Fri Dec 30 14:33 - 14:33 (00:00)
amabile pts/0 :0.0 Fri Dec 30 14:04 still logged in
amabile tty1 :0 Fri Dec 30 14:02 still logged in
reboot system boot 2.6.35.14-106.fc Fri Dec 30 14:01 - 18:01 (03:59)
amabile pts/0 :0.0 Fri Dec 30 11:42 - 11:59 (00:16)
amabile tty1 :0 Fri Dec 30 11:41 - 11:59 (00:18)
reboot system boot 2.6.35.14-106.fc Fri Dec 30 11:41 - 11:59 (00:18)
amabile pts/4 :0.0 Fri Dec 30 02:27 - 02:43 (00:16)
amabile pts/3 :0.0 Fri Dec 30 02:06 - 02:43 (00:37)
amabile pts/2 :0.0 Fri Dec 30 01:56 - 01:57 (00:00)
amabile pts/1 :0.0 Fri Dec 30 00:51 - down (01:59)
amabile pts/0 :0.0 Fri Dec 30 00:41 - 02:01 (01:20)
amabile tty1 :0 Fri Dec 30 00:21 - down (02:29)
reboot system boot 2.6.35.14-106.fc Fri Dec 30 00:21 - 02:51 (02:30)
amabile tty1 :0 Thu Dec 29 20:21 - down (01:24)
reboot system boot 2.6.35.14-106.fc Thu Dec 29 20:20 - 21:46 (01:25)
amabile pts/0 :0.0 Thu Dec 29 17:42 - 17:42 (00:00)
amabile tty1 :0 Thu Dec 29 17:26 - 17:44 (00:17)
e noto, con grande piacere, che a parte il mio user non si è loggato nessun altro.

Se la password fosse stata da "dizionario" probabilmente sarei stato vittima con esito d'attacco positivo.

Se non potete disabilitare il servizio SSH, vi lascio alcuni consigli:
1) usate una porta diversa dalla 22;
2) impostate iptables affinchè chiuda la connessione dopo 2 tentativi di password errata;
3) usare una chiave RSA per il protocollo SSH,
4) disabilitare, se non dispensabile, l'accesso da root via ssh.

NB: ferma il servizio SSHD prima di continuare!

Come fare:
1) da root lanciare:

Codice: Seleziona tutto

gedit /etc/ssh/sshd_config
e modificare la linea:
#Port 22
in:
Port xxx
dove 'xxx' è una porta scelta, configurandone opportunatamente il firewall. (Ricordo che il numero di porta deve essere compresa tra 1025 e 65535)

2) utilizzare l'opzione -hitcount <numero>
al comando iptables per specificare quanti possibili tentativi abbiamo prima che la connessione si chiuda.
Rimando a: man iptables per maggiori chiarimenti.

3) da root lanciare:

Codice: Seleziona tutto

gedit /etc/ssh/sshd_config
e modificare le linee:
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
in:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
poi da root lanciare il comando:

Codice: Seleziona tutto

ssh-keygen -t rsa
che genera la chiave RSA, seguendo le indicazioni in quale directory deve salvare la chiave, eventualmente crea la sotto-directory e non scrivendo nulla alle righe:
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
vi crea la chiave RSA sia per l'autenticazione che quella pubblica in:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
Si copia la chiave RSA pubblica sul server e si aggiunge nella home dell'utente:

Codice: Seleziona tutto

cat id_rsa.pub >> .ssh/authorized_keys
lanciato da root.

Impostiamo che tutte le chiavi siano lette e scritte solamente dai propri prietari con il comando:

Codice: Seleziona tutto

chmod 600 identity authorized_keys 
4) da root lanciare:

Codice: Seleziona tutto

gedit /etc/ssh/sshd_config
e modificare la linea:
#PermitRootLogin yes
in:
PermitRootLogin no
Facciamo ripartire il servizio SSHD e siamo pronti per una connessione sicura mediante il protocollo SSH, dando il comando:

Codice: Seleziona tutto

$ ssh utente@hostremoto -p xxx
da root e dalla macchina client, dove xxx è la porta scelta nella configurazione.

NdR: esiste un pacchetto che si chiama fail2ban molto utile nei casi di attacco ssh e non solo, che è ottimo ma da configurare per bene.
Per maggiori informazioni vi lascio la lettura dei manuali:
man fail2ban-client
man fail2ban-regex
man fail2ban-server
Sono allergico a mele morsicate e a finestre con tende.

Segnalate qui le vostre offerte di smartphone e tablet!!!

Avatar utente
dino
Messaggi: 16580
Iscritto il: mercoledì 30 novembre 2011, 18:21

Re: [Guida] Attacco SSH: come proteggersi!

Messaggio da dino »

Sui server che configuro e gestisco io utilizzo normalmente SSH che ovviamente è sempre attivato. I consigli che hai dato li reputo corretti tanto che anche io faccio così:

- uso una porta diversa dalla 22;
- uso una chiave per il protocollo SSH;
- l'accesso non è mai come utente root ma come utente limitato.
_____________________________
Working harder: http://www.dinofratelli.it
Listen House Music: https://www.dinobrosdj.it
Safety online https://omniadpi.it/

Avatar utente
conoscenza
Messaggi: 3821
Iscritto il: venerdì 2 dicembre 2011, 23:27
Località: Parma

Re: [Guida] Attacco SSH: come proteggersi!

Messaggio da conoscenza »

ho aggiunto anche il fatto che dopo 2 tentativi andati a male il server chiudesse la connessione!
cosi almeno se l'attacco è tramite brute force viene subito rispedito a casa. ;)

volendo si potrebbe anche gestire il tempo che intercorre tra un tentativo "errato" e l'altro...

Infine, se si deve accedere per forza da root, è meglio utilizzare una password seria: tipo quelle generate con ranpwd.
Sono allergico a mele morsicate e a finestre con tende.

Segnalate qui le vostre offerte di smartphone e tablet!!!

Avatar utente
dino
Messaggi: 16580
Iscritto il: mercoledì 30 novembre 2011, 18:21

Re: [Guida] Attacco SSH: come proteggersi!

Messaggio da dino »

Io le pwd di root le genero a "random-tastiera" :D
_____________________________
Working harder: http://www.dinofratelli.it
Listen House Music: https://www.dinobrosdj.it
Safety online https://omniadpi.it/

Avatar utente
conoscenza
Messaggi: 3821
Iscritto il: venerdì 2 dicembre 2011, 23:27
Località: Parma

Re: [Guida] Attacco SSH: come proteggersi!

Messaggio da conoscenza »

è anche un'ottimo rimedio!

Oppure lanci il comando:

Codice: Seleziona tutto

cat /dev/urandom | tr -dc '[:upper:] [:lower:]' | fold -w XXX | head -n YYY
dove:
XXX è quanto lunga deve essere la password;
YYY è quante password vogliamo generare;

e se la voglio più complessa aggiungo la stringa [:graph] al comando tr trasformandolo in:

Codice: Seleziona tutto

cat /dev/urandom | tr -dc '[:upper:] [:lower:] [:graph:]' | fold -w XXX | head -n YYY
... e ne escono delle belle! :asd:

Quasi quasi lo aggiungo a ranpwd: per coloro che non vogliono installare nulla! ;)
Sono allergico a mele morsicate e a finestre con tende.

Segnalate qui le vostre offerte di smartphone e tablet!!!

mafferri
Messaggi: 809
Iscritto il: martedì 10 gennaio 2012, 4:48

Re: [Guida] Attacco SSH: come proteggersi!

Messaggio da mafferri »

che ne pensate come soluzione una mini macchina virtuale sulla porta di default?

Avatar utente
conoscenza
Messaggi: 3821
Iscritto il: venerdì 2 dicembre 2011, 23:27
Località: Parma

Re: [Guida] Attacco SSH: come proteggersi!

Messaggio da conoscenza »

cioè?

la macchina virtuale gira comunque sulla macchina host: se entrano nella virtuale, non entrano anche nella/dalla host?
Sono allergico a mele morsicate e a finestre con tende.

Segnalate qui le vostre offerte di smartphone e tablet!!!

mafferri
Messaggi: 809
Iscritto il: martedì 10 gennaio 2012, 4:48

Re: [Guida] Attacco SSH: come proteggersi!

Messaggio da mafferri »

conoscenza ha scritto:cioè?

la macchina virtuale gira comunque sulla macchina host: se entrano nella virtuale, non entrano anche nella/dalla host?
no rimangono nel guest , e poi configuri l'host in modo che non deve accettare niente dall'ip del guest ma mappargli solo la porta 22 di default

mafferri
Messaggi: 809
Iscritto il: martedì 10 gennaio 2012, 4:48

Re: [Guida] Attacco SSH: come proteggersi!

Messaggio da mafferri »

però la vm deve occuparti 3-4 mega di ram questo deve essere fondamentale

Avatar utente
conoscenza
Messaggi: 3821
Iscritto il: venerdì 2 dicembre 2011, 23:27
Località: Parma

Re: [Guida] Attacco SSH: come proteggersi!

Messaggio da conoscenza »

non ne sono proprio sicuro, però potrebbe funzionare.
la cosa che si dovrebbe provare è che: se la macchina virutale viene raggiunta, vuol dire che la macchina host ha una porta aperta. Se ha una porta aperta, si può entrare.
Quindi trovo più sicuro usare il keygen.

Inoltre, per la vm che occupa 3-4MB di Ram... mmm mi sa che c'è solo MS-DOS! :look:
Sono allergico a mele morsicate e a finestre con tende.

Segnalate qui le vostre offerte di smartphone e tablet!!!

Rispondi