Me acabo de dar cuenta de que mis reglas de snort se activaron hoy en este, en un nuevo servidor ossim que estaba probando. "shellcode x86 inc ebx noo" activado con la ip de origen de Canadá. ¿Por qué un servidor nuevo, detrás de un firewall y un enrutador NAT, puede ver una alerta como esta proveniente de una IP externa?
En aras del argumento, supongamos que te refieres a la regla mencionada por Mark en su comentario. Esto funciona bien ya que cuando realizo una búsqueda de texto completo de su texto citado en todas las reglas VRT y ET, es el único que también encontré. Es sid 1390, que se encuentra en el archivo shellcode,rules para aquellos que realizan un seguimiento en casa.
El texto completo de la regla es:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"SHELLCODE x86 inc ebx NOOP"; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:1390; rev:9;)
Afortunadamente, esta es una regla agradable y simple. Para el mismo análisis, supongamos también que este dispositivo está en su borde y que las variables de IP se han configurado correctamente.
Por lo tanto, esta regla se comprueba en todos los paquetes de IP que llegan a su organización. Ya parece bastante ruidoso. Busca en la sección de carga útil del paquete la cadena que contiene 25 caracteres 'C' consecutivos. La razón de esto es que este carácter se asigna a la instrucción inc ebx para la arquitectura x86 (como lo indica el nombre de la regla). En la arquitectura x86, esta instrucción es funcionalmente equivalente a NOP y, como tal, puede usarse como parte de una diapositiva NOOP, pero es un poco menos evidente.
Esta regla específica, y muchas de las reglas de shellcode de hecho, son generadores bien conocidos de falsos positivos, ya que a menudo se pueden generar mediante la descarga de archivos binarios. El consejo de ajuste tradicional es deshabilitar estas reglas en los puertos web.
Por lo tanto, dependiendo de su umbral de riesgo, puede hacer lo siguiente:
Desactivar las reglas es fácil, y algo con lo que debería estar familiarizado si está intentando hacer un uso razonable de un IDS. La modificación puede ser un poco más complicada.
Dependiendo de su versión de Snort, ya debería tener dos variables configuradas en su snort.conf que serán útiles. Uno es HTTP_PORTS y el otro es SHELLCODE_PORTS . De forma predeterminada, están configurados en valores bastante básicos.
# Ports you run web servers on
portvar HTTP_PORTS [80,8080]
# Ports you want to look for SHELLCODE on.
portvar SHELLCODE_PORTS !80
Lo que recomendaría es cambiar HTTP_PORTS a lo que realmente uses en tu entorno, y luego configurar SHELLCODE_PORTS a la inversa de eso, así que algo como:
# Ports you run web servers on
portvar HTTP_PORTS [80,8080]
# Ports you want to look for SHELLCODE on.
portvar SHELLCODE_PORTS !$HTTP_PORTS
Luego, puede modificar la firma Snort para usar la variable de puerto adecuada.
alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"SHELLCODE x86 inc ebx NOOP"; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:1390; rev:9;)
Por lo tanto, ahora esto excluirá cualquier información proveniente de de un servidor web externo, por lo que digamos descargar un ejecutable de un sitio web de un proveedor. Es mejor tener en cuenta que dado que esta regla no tiene estado, un atacante malintencionado podría crear su exploit de tal manera que se evite la regla.
Alternativamente, podríamos ajustar la regla obligándola a tener estado en su lugar. Eliminemos la restricción de puertos y ajustemos la regla solo a la comunicación externa iniciada agregando la palabra clave de flujo, convirtiendo esa regla en:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"SHELLCODE x86 inc ebx NOOP"; flow:to_server,established; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:1390; rev:9;)
Así que ahora la regla buscará al menos 25 caracteres 'C' consecutivos en cualquier comunicación externa iniciada. Entonces, si bien ahora veremos los casos en que el usuario malintencionado falsifica sus puertos de origen, en un esfuerzo por eludir las restricciones del cortafuegos, perderemos los casos en que el código de explotación se descargue de un host local.
En ambos casos, hay formas obvias de omitir la rutina de detección, por lo que la dirección que elija depende completamente de su perfil de riesgo y su umbral de aceptación.
Lea otras preguntas en las etiquetas snort