Identificando autenticaciones exitosas y fallidas de SSH en un Ubuntu 10 LTS

Algunas veces necesitamos revisar las autenticaciones exitosas y fallidas mediante consola.

Para ello sólo disponemos de los archivos logs. Por defecto el sistema operativo tiene configurado guardar las bitácoras de estas transacciones.

Para realizar esta tarea es necesario tener acceso como usuario root mediante la consola. El usuario root tiene los privilegios para poder leer los archivos.

 root@mail:~# cd /var/log/  
 root@mail:/var/log# ls auth.log*  
 auth.log auth.log.1 auth.log.2.gz auth.log.3.gz auth.log.4.gz  

Verificando conexiones exitosas en los archivos no comprimidos

 root@mail:/var/log# grep "Accepted password for" auth.log auth.log.1
auth.log:Jan 6 22:35:56 mail sshd[4108]: Accepted password for usera from 190.n.n.n port 50114 ssh2
auth.log:Jan 7 08:58:56 mail sshd[28804]: Accepted password for usera from 190.n.n.n port 54843 ssh2
auth.log:Jan 7 11:58:13 mail sshd[29570]: Accepted password for userb from 213.n.n.n port 6914 ssh2

Verificando conexiones exitosas en los archivos comprimidos

 root@mail:/var/log# zgrep "Accepted password for" auth.log.*.gz
auth.log.2.gz:Dec 24 07:09:51 mail sshd[14896]: Accepted password for usera from 190.n.n.n port 63614 ssh2
auth.log.2.gz:Dec 25 13:56:44 mail sshd[20526]: Accepted password for userb from 79.n.n.n port 54520 ssh2
auth.log.2.gz:Dec 25 14:30:51 mail sshd[25996]: Accepted password for userc from 79.n.n.n port 48334 ssh2

Verificando conexiones fallidas en los archivos no comprimidos

 root@mail:/var/log# grep "Failed password for" auth.log auth.log.1
auth.log:Jan 6 07:09:55 mail sshd[13766]: Failed password for root from 37.221.176.190 port 38119 ssh2
auth.log:Jan 6 08:17:31 mail sshd[21566]: Failed password for root from 165.227.10.194 port 37922 ssh2
auth.log:Jan 6 08:17:35 mail sshd[21572]: Failed password for invalid user admin from 165.227.10.194 port 45174 ssh2
auth.log:Jan 6 08:17:38 mail sshd[21574]: Failed password for root from 165.227.10.194 port 49548 ssh2
auth.log:Jan 6 08:17:42 mail sshd[21612]: Failed password for invalid user admin from 165.227.10.194 port 53660 ssh2
auth.log:Jan 6 08:17:46 mail sshd[21636]: Failed password for invalid user user from 165.227.10.194 port 58186 ssh2
auth.log:Jan 6 08:41:24 mail sshd[24368]: Failed password for invalid user admin from 111.224.137.56 port 49376 ssh2
auth.log:Jan 6 08:49:45 mail sshd[24948]: Failed password for invalid user wangtao from 118.89.35.251 port 35152 ssh2
auth.log:Jan 6 08:55:26 mail sshd[26061]: Failed password for invalid user ubnt from 77.89.18.151 port 65234 ssh2
auth.log:Jan 6 08:59:54 mail sshd[26141]: Failed password for invalid user sunday from 118.89.35.251 port 58508 ssh2
auth.log:Jan 6 09:09:25 mail sshd[27160]: Failed password for invalid user user1 from 118.89.35.251 port 52168 ssh2

Verificando conexiones fallidas en los archivos comprimidos

 root@mail:/var/log# zgrep "Failed password for" auth.log.*.gz
auth.log.2.gz:Dec 23 07:14:46 mail sshd[10933]: Failed password for invalid user sammy from 50.207.108.136 port 54181 ssh2
auth.log.2.gz:Dec 23 08:12:05 mail sshd[19370]: Failed password for root from 179.90.181.117 port 35552 ssh2
auth.log.2.gz:Dec 23 08:12:17 mail sshd[19411]: Failed password for invalid user ubnt from 179.90.181.117 port 35554 ssh2
auth.log.2.gz:Dec 23 08:12:43 mail sshd[19409]: Failed password for root from 60.160.183.162 port 65174 ssh2
auth.log.2.gz:Dec 23 08:53:50 mail sshd[25931]: Failed password for invalid user debian-spamd from 50.237.11.68 port 49229 ssh2
auth.log.2.gz:Dec 23 08:56:43 mail sshd[26530]: Failed password for invalid user debian-spamd from 50.237.11.88 port 49177 ssh2
auth.log.2.gz:Dec 23 09:00:11 mail sshd[26914]: Failed password for invalid user svt from 50.237.11.68 port 34586 ssh2

Como se puede observar, si los archivos logs no han sido "alterados", se puede validar los datos de conexión mediante SSH para las autenticaciones exitosas y fallidas, además se puede observar como están intentando autenticarse en el sistema con usuarios inexistentes y desde direcciones IPs diferentes de las redes conocidas.

Los mensajes "Failed password for invalid user" validan que el servidor está sufriendo un ataque por fuerza bruta.

Con la información anterior se pueden analizar sobre los usuarios autenticados, cantidad de conexiones por IPs/usuarios.

 root@mail:/var/log# grep "Accepted password for" auth.log auth.log.1 | awk '{print $9, $11}' | sort | uniq -c
5 usera 181.n.n.n
11 usera 190.n.n.n
1 userb 141.85.241.113
3 userb 164.132.160.178
1 userb 5.255.86.129
1 userb 62.210.69.91
1 userc 213.233.101.245
1 userd 141.85.241.113
3 userd 164.132.160.178
1 userd 5.255.86.129
1 userd 62.210.69.91

También se pueden analizar las autenticaciones fallidas.

Cantidad de intentos de autenticación por usuarios existente en el servidor:

 root@mail:/var/log# zgrep "Failed password for" auth.log.*.gz | grep -v invalid | awk '{print $9}' | sort | uniq -c | sort -nrk1
805 root
10 mysql
9 ftp
8 backup
7 nobody
7 mail
7 info
7 bin
5 send
4 www-data
4 libuuid
3 userd
2 vmail

Cantidad de intentos de autenticación por usuario inexistente en el servidor:

 root@mail:/var/log# zgrep "Failed password for invalid" auth.log.*.gz | awk '{print $11}' | sort | uniq -c | sort -nrk1
582 admin
116 ubnt
100 test
74 user
70 oracle
67 pi
54 ubuntu
44 usuario
39 ftpuser
33 postgres
32 service
32 nagios
32 git
26 minecraft
24 vps
24 ts3srv
24 teamspeak
23 hadoop
22 server
21 deploy
19 jenkins
18 ts3
18 tester
18 guest
16 weblogic
16 support
15 testuser

Top de IPs con autenticaciones fallidas:

 root@mail:/var/log# zgrep "Failed password for" auth.log.*.gz | grep -oP "(\d+\.){3}\d+" | sort | uniq -c | sort -nrk1
8 79.137.29.111
7 76.65.112.201
7 36.156.24.93
7 218.39.46.231
6 98.226.244.119
6 95.116.2.15
6 95.107.65.55
6 94.219.63.173
6 91.80.134.42
6 89.246.124.148
6 81.32.156.180
6 77.185.183.142
6 77.178.194.208
6 73.47.219.102
6 62.85.13.18
6 5.37.139.156
6 49.161.172.150
6 49.1.244.86
6 41.222.225.173
6 39.116.1.229
6 37.79.114.112

Existen alternativas para tratar de disminuir este tipo de ataques:

• Cambiar el puerto por defecto del protocolo SSH. Se sugiere un puerto arriba del 40000.
• Instalar y configurar denyhosts para automáticamente bannear las IPs que generan autenticaciones fallidas.
• Restringir la autenticación del usuario root via SSH.
• Restringir las autenticación via SSH a determinado grupo de usuarios. Normalmente se crea un grupo con ese privilegio/permiso y se adicionan al grupo sólo los usuarios que realmente requieren el acceso vía SSH.
• Restringir las conexiones SSH a determinadas redes.
• Activar la autenticación por medio de llave pública/privada.

* Este post nació a partir de que un cliente y amigo me pidiera que revise su servidor de correo electrónico que está publicado en Internet y que le estaban llegando unos emails raros.