Virus de phishing encontrado en el servidor

6

Hace poco recibí una llamada de BELL sobre un virus en nuestro servidor Linux (Debian). Al parecer, Google le envió un correo electrónico a nuestro cliente sobre una base de datos italiana encontrada en nuestro servidor que estaba haciendo phishing. Le pidieron a Bell que bloqueara nuestra IP si no podíamos encontrarla dentro de una hora.

La carpeta se llamó "Mostrar" y dentro de ella había un index.PHP y un montón de otros archivos. Lo borré y ahora está bien.

Los derechos de carpeta eran root: root. Creo que se agregó cuando el administrador del sitio cargó un archivo desde su PC. Pero, ¿cómo serían las propiedades del archivo root: root?

¿Cómo puedo prevenir estos problemas? ¿Hay algún paquete de Linux que ayude?

*** En caso de que sea relevante, el cliente está usando phpMyFaq y la carpeta "Mostrar" estaba dentro de la carpeta "Archivos adjuntos".

P.s en mi access.log Tengo muchos de estos:

- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"
- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"
- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"
- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"

donde XXX.XXX es una IP real ...

¿Podría estar relacionado? Después de buscar en Google estos códigos, siempre obtengo algo sobre SSL.

    
pregunta Adam 02.05.2011 - 17:54
fuente

3 respuestas

7

Lo primero es lo primero: usted debe (insisto, debe ) borrar su disco duro y reinstalarlo desde cero. Cualquier atacante malintencionado o mero virus que pueda obtener acceso de root en un sistema no se detendrá después de agregar una carpeta. Es muy probable que se hayan instalado una o varias puertas traseras, en varias utilidades del sistema y / o en el propio kernel, en formas que no podrá detectar desde la propia máquina. Así que haga una copia de seguridad de los archivos de datos, vuelva a instalar el sistema y vuelva a copiar los archivos solo después de una verificación completa (en particular, los archivos fuente de PHP).

Una conexión SSL / TLS comienza con un primer mensaje enviado por el cliente, y comienza con un encabezado cuyos tres primeros bytes tendrán un valor 0x16, 0x03 y 0x01, en ese orden (suponiendo que el cliente implementa TLS 1.0 , que es el caso más común). Sus líneas de registro parecen que alguien intentó conectarse a su servidor HTTP como si fuera un servidor HTTPS, y su servidor, incapaz de entender los bytes enviados por el cliente, respondió con un mensaje de error HTTP apropiado (que probablemente el cliente Tampoco entendí, ya que estaba tratando de establecer una conexión TLS, no de intercambiar mensajes HTTP). Probablemente esto sea inofensivo y posiblemente no esté relacionado con su problema de intrusión.

Para evitar cualquier intrusión adicional, solo debe usar un software que no tenga errores, lo que no es posible con la tecnología actual basada en la Tierra. Lo más cerca que puede acercarse es mantener su sistema actualizado con las correcciones de seguridad conocidas; debe verificar las actualizaciones de seguridad diariamente (con Debian, esto es una cuestión de apt-get update && apt-get dist-upgrade ).

    
respondido por el Thomas Pornin 02.05.2011 - 20:40
fuente
3

desde mi perspectiva, esta sería una solución de 3 puntas. En realidad, la solución es una mala palabra para usar ... "mitigación" es mucho más aplicable. En primer lugar, estoy de acuerdo con @Thomas Pornin y te digo que debes limpiar el sistema. Después de ese paso, las tres puntas son las siguientes:

  1. Supervise el sistema para detectar cambios en el sistema de archivos. Una gran opción aquí es tripwire . Esta herramienta debe ejecutarse primero en un sistema limpio (lo mejor es una instalación completamente nueva y nueva) para obtener una línea de base. Luego, basándose en un trabajo cron, los archivos especificados en el sistema serán revisados en busca de cambios.
  2. Supervisar los registros del sistema. De esta manera, podrá seguir el rastro de papel hasta la fuente en el futuro. La mejor manera de hacerlo es a través de una solución SIEM (es decir, OSSIM )
  3. Monitorear posibles vectores de ataque. Utilice algún tipo de escáner de vulnerabilidad. Esto te indicará la apertura, lo que puede permitir ataques. Una posible solución es nessus .

Hay muchas soluciones para todas estas herramientas. Algunas otras cosas a tener en cuenta son los monitores y perfiladores de red como nagios y OrionNPM que se puede usar para un poco más de análisis. No estoy seguro de las capacidades de alerta de Orion, pero supongo que podría alertar si hay conexiones sospechosas, nuevos hosts de red, ataques de denegación de servicio o cualquier evento para el que le gustaría crear un perfil.

Esto parece mucho trabajo si tiene una operación pequeña, pero puede ser de gran ayuda. Creo que todos menos orionNPM son soluciones gratuitas (o se puede encontrar una versión legal gratuita).

Si tiene datos o servicios valiosos en los que otros confían, en lo que a mí respecta, todas estas prácticas son parte de la diligencia debida del administrador de activos (o del responsable de seguridad, administrador o de quienquiera que esté a cargo de su seguridad). ).

Tenga en cuenta que esta respuesta tiene que ver con las herramientas que podría haber usado o que podría usar en el futuro para ayudar a prevenir este tipo de ataque. También tenga en cuenta las mejores prácticas ... mantenerse actualizado, usar canales de comunicación seguros, usar contraseñas seguras, controlar los permisos de las cuentas, restringir los recursos de los usuarios que han iniciado sesión, etc. ....

PS tripwire está definitivamente en ubuntu apt-get repos, así como en el escáner de vulnerabilidades openVAS (pero he tenido problemas al intentar implementar openVAS).

    
respondido por el Ormis 02.05.2011 - 22:52
fuente
0

Un archivo propiedad de root:root no es un problema. De hecho, si tiene problemas con su aplicación web que está siendo desfigurada, hacer un chown root:root -R /var/www evitará que la aplicación comprometida cambie los permisos en el archivo. Hacer un chmod -R 555 . /var/www junto con la propiedad de la raíz es una gran idea. Estos permisos harán que sea imposible que un virus basado en PHP dañe su aplicación web.

Aunque la raíz del problema es que hay una vulnerabilidad en su aplicación web. Es probable que esté utilizando una aplicación o biblioteca antigua que sea vulnerable al ataque .

    
respondido por el rook 02.05.2011 - 20:38
fuente

Lea otras preguntas en las etiquetas