Tres preguntas que espero que alguien pueda ayudar a responder:
Estoy ejecutando CentOS 6, pila LEMP
¿Cómo sé si mi servidor ya está comprometido debido al error Shellshock?
Usted no Esa es la idea de una vulnerabilidad de seguridad. Si tuviera que hacer clic en ¿ Dejar entrar las galletas? OK / Cancelar no sería una gran vulnerabilidad.
Es posible que tengas suerte comprobando los registros de tus vectores de ataque, pero dado que tantos servicios son vulnerables y no todos registran cada acceso, es probable que no sea posible encontrar un ataque de manera concluyente.
Si se vio comprometido, ¿hay una carpeta en particular donde debería buscar archivos maliciosos?
No, un archivo malicioso podría estar en cualquier lugar.
Rootkits comunes se instalan en /rooto /o /tmpo uno de los caminos binarios, pero en realidad podrían estar en cualquier parte. Pueden tener un nombre similar a un servicio real o algo "importante" que se parezca a " IPTables" o " kernel-bin", pero también pueden ser cadenas de caracteres al azar o el mismo nombre que un binario genuino (solo en una ruta diferente). Puede detectar un rootkit realmente obvio cargando /etc/rc.localo haciendo conexiones a través de netstat -neopa. Busque nombres de procesos sospechosos en top -c.
Un rootkit menos común y mucho más difícil de encontrar reemplaza una biblioteca o se carga a sí mismo como una biblioteca shim e intercepta las llamadas del sistema. Esto es casi imposible de encontrar a menos que coloque / trace cada cosa que se ejecute en su sistema y compare el comportamiento con el comportamiento esperado de un sistema o código fuente bien conocido.
Sería más rápido, más fácil y más concluyente volver a cargar el sistema.
¿Cómo se ve un archivo malicioso?
Probablemente como cualquier otro binario o biblioteca ELF regular. También puede ser un guión.
En conclusión, si cree que existe la posibilidad de que su sistema se haya visto comprometido, trátelo como si se hubiera visto comprometido y tome las medidas necesarias.
bashinstalado y un cable de red conectado, ¿verdad?shellshock no es un gusano, por lo que no hay archivos que buscar. Shellshock es una forma de atacar una red para obtener acceso. Una vez dentro, quién sabe lo que hará el atacante.
fuente
is there a particular folder where I should look for malicious files.He visto un intento de explotar el error, que instalaría un bot IRC como
/var/tmp/x. Pero, en general, no hay archivos particulares para buscar, ya que podrían estar en cualquier lugar o en ninguna parte.Si se ve comprometido a través del servidor web, cualquier nuevo archivo o proceso propiedad del usuario del servidor web sería sospechoso.
En caso de que un atacante usara primero el
basherror para ingresar al sistema y luego una vulnerabilidad local para convertirseroot, podría ser casi imposible detectarlo.También mira esta pregunta similar .
fuente
Me gustaría hacerme eco de la respuesta de suprjami y decir que si su sistema es vulnerable, entonces debería tratarlo como comprometido.
Si está ejecutando Apache, puede verificar los registros de intentos de intrusión de Shellshock con el siguiente comando:
Este comando extrae todas las líneas que contienen "cgi" de los registros de acceso de Apache (por defecto llamados access_log, access_log.1, access_log.2, etc.) y luego lo canaliza a egrep con la expresión regular.
(Fuente: http://linux.slashdot.org/story/14/09/24/1638207/remote-exploit-vulnerability-found-in-bash )
fuente
Dado que hay varios vectores de ataque para Shellshock, algunos de ellos aún desconocidos para el público en general o causados por un script CGI personalizado, no hay una forma definitiva de saber si está comprometido o no.
Además del enfoque habitual "veamos si algunos archivos del sistema han cambiado o si ha sucedido algo sospechoso últimamente", es posible que desee vigilar el comportamiento de su servidor.
netstatMuestra conexiones de red extrañas ops auxmuestra procesos que no reconoce?Si tiene una supervisión adecuada del estado del servidor (como
Zabbix) en funcionamiento, también puede ayudarlo a descubrir violaciones de seguridad. También puede comparar las sumas MD5 / SHA de los archivos del sistema con una buena copia de seguridad conocida.Básicamente, actúa como si tu servidor se hubiera visto comprometido e investiga todo lo que puedas imaginar.
fuente
Acabo de tener el placer de limpiar un viejo sistema Plesk comprometido. Lo primero que lo delató fueron numerosos procesos que comenzaron a escuchar una serie de puertos y otros que intentaban descargar código del servidor de escaneo original.
Siguiendo los registros, descubrí que el último agujero era un
cgi_wrapperguión, algo que se suponía que debía proteger y proteger el sistema es lo que realmente rompió el agujero en la protección. Estas son algunas de las líneas de registro de las sondas y el ataque exitoso:Estas son las líneas de access_log, ya que esto es solo una muestra, tenga en cuenta el 200 en dos de las líneas, mientras que las otras fallan con 404. No tiene que preocuparse por las líneas que tienen un 404 ya que no tuvieron éxito, los que tienen 200 sin embargo lo hicieron. El patrón en estos ataques aquí es siempre el mismo: 1. encuentre un script cgi vulnerable, use el exploit shellshock para descargar y ejecutar un script perl, elimine el script perl nuevamente. El script perl en realidad descargará algunos archivos fuente (tgz), los compilará y los ejecutará, por lo que he visto incluyen al menos una puerta trasera y un mecanismo de actualización automática, además de lo que parecen exploits para tratar de obtener privilegios de ejecución elevados. Todos los scripts iniciales se ejecutan realmente como el usuario proporcionado por el reiniciador, mientras que los servicios posteriores se inician con un PPID de 1 (iniciado desde el proceso raíz).
Y aquí las líneas correspondientes de error_log:
Archivos descargados a / tmp Como se podría adivinar, no tengo el archivo bot.pl ya que se elimina de inmediato.
Después de un tiempo noté conexiones ssh desde varios lugares como China que generalmente no visitan tanto nuestro servidor. Parcheé bash como medida de emergencia (hubiera sido bueno tener fuentes parcheadas disponibles en el sitio web de FSF y no solo las fuentes y archivos de parches realmente ANTIGUOS (uno de los cuales no se aplicó correctamente al principio). El sistema está programado para un completo limpie ahora, así que si alguien está buscando algo más sobre el ataque, puede preguntar, pero hágalo pronto.
fuente
Esta respuesta no está especialmente relacionada con Shellshock, pero para cualquier sistema que pueda considerar comprometido
segunda nota: no puede estar seguro de haberse recuperado de un sistema comprometido a raíz. Su única acción es destruir y reaprovisionar el sistema.
Intente obtener una compilación estática limpia
rpmy ejecutar el comandorpm --verify --all. Le dirá qué archivos que pertenecen a un paquete se han modificado. Pero como puede ejecutarlo en un sistema comprometido, es posible que no confíe completamente en el resultado. Luego, simplemente puede hacer unarpm -qapara obtener la lista de paquetes, recrear otro sistema con las mismas versiones de paquetes y luego unfind / -type f |xargs -r -n 100 md5sum |sorten ambos sistemas y ver qué difiere. Además, si administra su sistema correctamente (es decir, no instala nada manualmente fuera de / opt o / usr / local / bin u otro lugar no administrado), puede buscar todos los archivos en su sistema que no pertenecen a un paquete, confind / -type f -exec rpm -qf {} \;. Debería mostrar errores para archivos desconocidos. Te dejo no mostrar los aspectos positivos como un ejercicio ;-)Para hacer lo mismo periódicamente con la prueba criptográfica, hay una herramienta llamada
Tripwireque todavía puede encontrar como versión gratuita. Es viejo pero hace su trabajo. Una alternativa más nueva esAIDE, pero no estaba usando cripto cuando lo miré hace años.Hay algunas herramientas que pueden ayudar. Por ejemplo, busque el paquete
rkhunter. Escaneará su computadora en busca de kits de herramientas raíz conocidos y archivos explotados.Obviamente, estas herramientas deberían haberse instalado y configurado antes de que el sistema se vea comprometido, y estas herramientas también pueden ser dirigidas si su sistema ha sido pirateado con éxito para acceso root. Además, estas herramientas pueden ser muy intensivas y ralentizar su sistema.
fuente
La única forma de saber si su servidor está comprometido es tener en algún lugar una firma de sus archivos y comparar sus archivos actuales. Sin embargo, puedes ver si eres vulnerable.
fuente
Cómo saber si su caja de linux está comprometida.
Si si regresa
usted está.
Para ejecutar la actualización, en root ejecute el siguiente comando
fuente
yumy no otro administrador de paquetes.Puede verificar si es vulnerable ejecutando los siguientes comandos (código proporcionado por el CSA). Abra una ventana de terminal e ingrese el siguiente comando en el indicador $:
Si su bash NO está actualizado, imprimirá:
Si tu bash está actualizado, solo verás:
Más detalles están disponibles detrás de este enlace .
fuente