Tras casi una semana de haber dejado mi antiguo lugar de trabajo por diversas razones personales, haciendo unas revisión general para ver cómo estaban las cosas, me dio la curiosidad y me puse a revisar el servidor Ubuntu que tienen a ver que había de nuevo...Sorpresa!!! al darme una vuelta por los logs de autenticación veo que han querido acceder por medio de un ataque de fuerza bruta (con el usuario root y algunos otros) al servicio sshd mostrando las siguientes entradas en el archivo /var/log/messages/auth.log.0 :
Jan 17 08:51:45 ubuntu sshd[24173]: Failed password for root from 115.146.138.5 port 36764 ssh2
Jan 17 08:51:48 ubuntu sshd[24179]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.146.138.5 user=root
Jan 17 08:51:50 ubuntu sshd[24179]: Failed password for root from 115.146.138.5 port 37070 ssh2
Jan 17 08:51:52 ubuntu sshd[24183]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.146.138.5 user=root
Jan 17 08:51:54 ubuntu sshd[24183]: Failed password for root from 115.146.138.5 port 37377 ssh2
Jan 17 08:51:57 ubuntu sshd[24187]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.146.138.5 user=root
Jan 17 08:51:59 ubuntu sshd[24187]: Failed password for root from 115.146.138.5 port 37706 ssh2
Jan 17 08:52:01 ubuntu sshd[24191]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.146.138.5 user=root
Correcto! Estaban atacando el servicio SSH (sshd) queriendo ingresar con el usuario root y aparte de este usuario habían otros como: sasha, bryan, peter, guest, john, www-data, etc.
La seguridad mínima (pero muy mínima...) que se le puede aplicar a un servidor ssh recién instalado es poner la directiva PermitRootLogin en no en el archivo /etc/ssh/sshd_config y reiniciar solamente el servicio sshd con /etc/init.d/ssh restart
Luego de esta sorpresita, le hice un escaneo de puertos al server y pues obviamente, al tener el puerto predeterminado abierto encontré lo siguiente:
tuxracer@hackerbox:~# nmap -O -vv server1.mi-ex-trabajo.com
Starting Nmap 4.76 ( http://nmap.org ) at 2010-01-22 16:02 CST
Initiating OS detection (try #1) against server1.mi-ex-trabajo.com
Retrying OS detection (try #2) against server1.mi-ex-trabajo.com
Host server1.mi-ex-trabajo.com appears to be up ... good.
Interesting ports on server1.mi-ex-trabajo.com:
Not shown: 991 closed ports
PORT STATE SERVICE
22/tcp open ssh (interesante... ¬¬)
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
1025/tcp filtered NFS-or-IIS
1720/tcp filtered H.323/Q.931
4444/tcp filtered krb524
5000/tcp filtered upnp
OS fingerprint not ideal because: Host distance (7 network hops) is greater than five
Aggressive OS guesses: Linux 2.6.24 (95%), Linux 2.6.9 - 2.6.26 (95%), Linux 2.6.22 - 2.6.23 (94%)...
Entonces, como segundo paso de la seguridad más mínima que se le puede aplicar a un servidor SSH es cambiarle el puerto predeterminado, ya que la mayoría de botnets que dejan algunos delincuentes informáticos al lanzar pruebas de intrusión lo hacen a servicios que tienen el puerto que viene por default en su archivo de configuración, el 22 en este caso para sshd.
Para cambiarlo, editamos siempre el archivo /etc/ssh/sshd_config y buscamos la directiva port para cambiar el valor a cualquier número arriba del 1024 (y menor de 65535) que no esté siendo utilizado por otro servicio que estemos ofreciendo, quedando (por ejemplo) de esta manera:
port 25259
Y como siempre, reiniciamos solamente el servicio sshd para que surtan efecto los cambios realizados. Así, al pasar un escaneo de puertos nuevamente ya no lo reconoce como un servicio estándar y de hecho, ya no lo muestra en el otro escaneo de puertos (sencillo) que le realicé.
tuxracer@hackerbox:~# nmap -O -vv server1.mi-ex-trabajo.com
Starting Nmap 4.76 ( http://nmap.org ) at 2010-01-22 16:22 CST
Initiating OS detection (try #1) against server1.mi-ex-trabajo.com
Retrying OS detection (try #2) against server1.mi-ex-trabajo.com
Host server1.mi-ex-trabajo.com appears to be up ... good.
Interesting ports on server1.mi-ex-trabajo.com:
Not shown: 992 closed ports (aparece 1 puerto cerrado más que en el escaneo anterior)
PORT STATE SERVICE
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
1025/tcp filtered NFS-or-IIS
1720/tcp filtered H.323/Q.931
4444/tcp filtered krb524
5000/tcp filtered upnp
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Bravo!!! ya no aparece listado el servicio de sshd por el puerto 22, es más ni en ningún otro puerto*.
Es cierto, la seguridad por medio de la obscuridad, no es confiable, además la herramienta nmap tiene muchas opciones las cuales también pueden ser agregadas y encontrar un sin fin de cosas, pero como mencionaba, esas 2 directivas son básicas para dar una seguridad de lo más mínima a un servidor que esté ofreciendo conexiones por medio de ssh.
(Eso de las dos directivas "más básicas" es una subjetividad mía, los que son expertos en seguridad de servicios en Sistemas GNU/Linux o que tengan más experiencia pueden tener otra apreciación de mi punto de vista)
En el archivo de configuración /etc/ssh/sshd_config hay muchas opciones de seguridad que más adelante (en otro post) las iré comentando, sin mencionar que se pueden crear reglas con iptables o también se puede echar mano de fail2ban.
En fin, las opciones para asegurar servicios (y en especial ssh) son muy variadas que ni siquiera las conozco todavía, pero en lugar de creer que GNU/Linux por sí solo es muy seguro y podemos dejar las configuraciones por default de los servicios que ofrecemos al público, sabre decir que no es una muy buena idea, a pesar de que (comparado con el S.O. de Redmond) es muy bueno, seguro y robusto, éste tampoco hace milagros en cuanto a la seguridad, revisiones y actualizaciones que uno debe de realizar periodicamente.
Y de hecho, que por qué sigo al tanto de la seguridad (que yo humildemente conozco) de un servidor donde ni siquiera trabajo ya y ni me pagan por ello?
Simple, no hay que pagar un mal con otro mal. Al menos cuando llegue algun empleado que le gusten un poco los servidores GNU/Linux y la seguridad informática (mínima o básica) como me gusta a mi, pues cambiará los medios de acceso y con respecto a la seguridad sabrá qué hacer. No hacer nada también es una opción, pero...
También, Proverbios 3:27 dice: "No te niegues a hacer el bien a quien es debido, Cuando tuvieres poder para hacerlo."
Saludos!
[Editado: 24/14/2010 00:22:58]
Después de hacer los cambios en el puerto de escucha del servidor ssh, tengo que mencionar/aclarar que para nuevas conexiones a los servidores con el nuevo puerto en cuestión se tiene que agregar la opción de especificación de puerto a ssh (-p #de-puerto) antes del nombre o dirección IP del servidor, ya que cuando quise volverme a conectar poniendo dicha opción al final del nombre del servidor, si lo hacía de la forma:
# ssh usuario@server1.mi-ex-trabajo.com -p 25259
La respuesta que obtenía después de unos 5 minutos (aprox.) era que la conexión se cerraba por caducarse el tiempo.
# ssh usuario@server1.mi-ex-trabajo.com -p 25259
ssh: connect to host server1.mi-ex-trabajo.com port 25259: Connection timed out
Si lo hacía de esta:
# ssh -l usuario server1.mi-ex-trabajo.com -p 25259
Después de 1 hora no obtuve respuesta alguna, sin embargo tampoco obtenía el mensaje que me dijera que la conexión se cerraba porque se había caducado el tiempo para establecer tal conexión.
Así que, la forma correcta de hacerlo es:
# ssh -p 25259 usuario@server1.mi-ex-trabajo.com
ó
# ssh -l usuario -p 25259 server1.mi-ex-trabajo.com
# ssh -p 25259 -l usuario server1.mi-ex-trabajo.com
Bytes!
0 comentarios:
Publicar un comentario