Bueno uno de los mitos más extendidos en el mundo de la informática, especialmente dentro de los recien llegados es que Linux es un sistema operativo muy seguro, cuando en realidad no existe un sistema operativo intrinsecamente seguro. Tan sólo administradores obsesionados con la seguridad.
El fin de semana pasado estuve ocupado recuperandome de un ataque contra uno de mis servidores, la solución que utilicé fue la más sencilla, reinstalar todo otra vez y restaurar desde los back-up. Pero sin embargo parece que eso no fue suficiente, a media semana el mismo servidor empezó a mostrar ciertos comportamientos erráticos, se congelaba y tenía que reiniciarlo. Luego de lo cual veía increíbles picos en el tráfico de red, en un principio creía que era el tráfico de mi proyecto de conversión de formatos de video flv2amv.com, por ello decidí el jueves pasado sencillamente poner fuera de servicio el site para evitar esas sobrecargas. Por eso algo no cuadraba cuando me di cuenta que el servidor seguía registrando alto tráfico el viernes en la mañana, razón por lo cual empecé a buscar que más podría estar ocurriendo y encontré que alguien había exitosamente entrado a través del ssh con privilegios de root y estaba ejecutando el script sipvicious que permite atacar servidores SIP.
Las dos cosas obvias en un escenario como este son bajar el servidor y erradicar la amenaza. Dado que era una instalación nueva y con las últimas actualizaciones sólo me quedaba suponer que alguno de los sites de amigos que alojo en ese server había servido como puerta de entrada al servidor, por ello lo primero que hice fue seguir los consejos que encontré en un foro y deshabilitar las siguientes funciones de PHP:
disable_functions = "apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode"
Luego busqué rastros de rootkits usando rkhunter y chkrootkit de los cuales he explicado su uso en un post anterior de este blog. No encontré ninguno pero me mostro que tanto el ssh como el sshd estaban corruptos, es decir había que reemplazarlos. Cuando intenté remover completamente los paquetes, me encontré con la sorpresa de que /usr/bin/ssh y /usr/sbin/sshd así como los archivos de configuración respectivos /etc/ssh/ssh_config y /etc/ssh/sshd_config no podían ser borrados porque tenía los atributos extendidos habilitados. No era la primera vez que me pasaba eso y sabía que tenía que remover esos flags, pero pasé un buen rato tratando de recordar los comandos que permiten hacerlo, esa es una de las razones para escribir este post, el permitirme en una próxima oportunidad tener a la mano la información y ahorrarme 15 minutos de googleo. En fin el problema fue resuelto con los comandos lsattr (listar atributos extendidos) y chattr (cambiar atributos extendidos).
Luego de remover, purgar y reinstalar los paquetes de openssh, pude poner en marcha nuevamente el servidor. Lamentablemente un efecto colateral de restringir lo que PHP puede hacer es que el proyecto flv2amv.com tiene que ser reescrito para no depender de funciones que en este momento están deshabilitadas, aunque lo que si esá claro es que no fue a través de ese website que entraron a mi server. Sin embargo hay una treintena de otros websites que pudieron servir como la puerta de acceso, dado que no tengo tiempo de buscar errores en código escrito por otras personas, por seguridad la lista de funciones que mencioné líneas arriba seguirán deshabilitadas. Como resultado, el website flv2amv.com temporalmente estará fuera de servicio hasta que me de un tiempo para reescribirlo.
UPDATE: Gracias a suhosin he podido capturar las IPs que siguen tratando de atacar mi server y ubicar donde habian escondido los scripts de PHP que utilizaban para tratar de escalar privilegios, así que aquí les dejo una colección de IPs que bien harían en bloquear en sus respectivos servers (reglas de iptables incluídas):
/sbin/iptables -A INPUT -s 64.50.236.0/24 -j DROP
/sbin/iptables -A INPUT -s 70.38.0.0/17 -j DROP
/sbin/iptables -A INPUT -s 67.228.137.0/27 -j DROP
/sbin/iptables -A INPUT -s 218.149.128.0/24 -j DROP
/sbin/iptables -A INPUT -s 119.245.0.0/16 -j DROP
/sbin/iptables -A INPUT -s 132.248.0.0/16 -j DROP
/sbin/iptables -A INPUT -s 188.40.0.0/16 -j DROP
/sbin/iptables -A INPUT -s 190.144.0.0/14 -j DROP
/sbin/iptables -A INPUT -s 118.127.0.0/18 -j DROP
/sbin/iptables -A INPUT -s 150.213.0.0/15 -j DROP
/sbin/iptables -A INPUT -s 67.195.115.0/24 -j DROP
/sbin/iptables -A INPUT -s 77.88.28.0/24 -j DROP
Podrías revisar los logs /var/log/messages y /var/log/secure – quizas te puedan dar un indicio de como entraron (quizás un ataque en bruto???)
Suerte!
Gracias por el tip.
Guao, nunca pense que virus podrian afectar a un sitio web, de todas maneras gracias a ti ahora tngo el tip y lo pondré en práctica. gracias 😀 saludos