Este post le ayudará a escribir Reglas Snort efectivas para mejorar materialmente su postura de seguridad. Comenzaremos con un desglose de cómo se construye una regla y luego exploraremos las mejores prácticas con ejemplos con el fin de capturar tantas actividades maliciosas como sea posible mientras se utilizan tan pocas reglas como sea posible.
Snort es un sistema de detección de intrusos de red de código abierto (NIDS) que proporciona análisis de paquetes en tiempo real y es parte de la solución Coralogix STA. Si eres un cliente de Coralogix STA, asegúrate de revisar también mi anterior post sobre cómo editar Reglas Snort en STA.
Anatomía de las Reglas Snort
Antes de sumergirnos en las diferentes estrategias para escribir tus mejores reglas snort, comencemos diseccionando un ejemplo de Regla Snort:
alert: le dice a Snort que reporte este comportamiento como una alerta (es obligatorio en las reglas creadas para STA).
tcp: significa que esta regla sólo se aplicará al tráfico en TCP.
any: en este contexto, significa «desde cualquier puerto de origen», luego hay una flecha ‘->’ que significa «una conexión a» (no hay un operador ‘<-‘, pero puede simplemente voltear los argumentos alrededor del operador. Puedes usar el operador ‘<>’ para indicar que la dirección de la conexión es irrelevante para esta regla), luego un rango de IP que indica la dirección IP de destino y luego el puerto. Puede indicar un rango de puertos utilizando dos puntos como 0:1024 que significa 0-1024. En el paréntesis redondo, hay algunas directivas para establecer el mensaje de alerta, metadatos sobre la regla, así como comprobaciones adicionales.
msg: es una directiva que simplemente establece el mensaje que se enviará (a Coralogix en el caso de STA) en caso de que se detecte un tráfico coincidente.
flow: es una directiva que indica si el contenido que vamos a definir como nuestra firma tiene que aparecer en la comunicación al servidor («to_server») o al cliente («to_client»). Esto puede ser muy útil si, por ejemplo, queremos detectar la respuesta del servidor que indica que ha sido vulnerado.
established: es una directiva que hará que Snort limite su búsqueda de paquetes que coincidan con esta firma sólo a los paquetes que forman parte de conexiones establecidas. Esto es útil para minimizar la carga de Snort.
uricontent: es una directiva que indica a Snort que busque un determinado texto en el contenido URI HTTP normalizado. En este ejemplo, buscamos una url que sea exactamente el texto «/root.exe».
nocase: es una directiva que indica que queremos que Snort realice una búsqueda sin distinción de mayúsculas y minúsculas.
classtype: es una directiva que es un atributo de metadatos que indica qué tipo de actividad detecta esta regla.
reference: es una directiva que es un atributo de metadatos que enlaza con otro sistema para obtener más información. En nuestro ejemplo, el valor url,<https://….> enlaza con una URL en Internet.
sid: es una directiva que es un atributo de metadatos que indica el ID de la firma. Si está creando su propia firma (incluso si sólo está reemplazando una regla incorporada), utilice un valor superior a 9.000.000 para evitar una colisión con otra regla preexistente.
rev: es una directiva que indica la versión de la regla.
Hay mucho más que aprender acerca de las reglas de Snort que soporta el análisis RegEx, el análisis específico del protocolo (al igual que uricontent para HTTP), la búsqueda de datos binarios (no textuales) mediante el uso de valores hexadecimales de bytes, y mucho más. Si quieres saber más puedes empezar por aquí.
Mejores prácticas para escribir reglas Snort efectivas
- Dirígete a la vulnerabilidad, no al exploit – Evita escribir reglas para detectar un kit de exploits específico porque hay innumerables exploits para la misma vulnerabilidad y podemos estar seguros de que se están escribiendo nuevos mientras estás leyendo esto. Por ejemplo, muchas de las primeras firmas para detectar ataques de desbordamiento de búfer tenían este aspecto:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")
La razón de ello es, por supuesto, que para lanzar un ataque de desbordamiento de búfer con éxito, el atacante necesita llenar el búfer de una determinada variable y añadir su carga maliciosa al final para que sea ejecutable. Los caracteres que elija para llenar el búfer son completamente insignificantes y, de hecho, tras la aparición de este tipo de firmas, muchos conjuntos de herramientas de ataque simplemente utilizaron una letra o letras diferentes para llenar el búfer y evadieron completamente este tipo de detección de firmas. Una forma mucho mejor sería intentar detectar este tipo de ataques mediante la detección de la entrada incorrecta en los campos basándose en su tipo y longitud.
- Tu peculiaridad es tu mejor activo, así que úsala – Cada organización tiene cosas que la hacen única. Muchas de ellas pueden ser bastante útiles cuando intentas detectar actividades maliciosas en tu organización, tanto externas como internas. Al utilizar este profundo conocimiento interno a su favor, esencialmente convertirá el problema de un problema tecnológico a un problema de inteligencia de la vieja escuela, obligando a los atacantes a tener un conocimiento mucho más íntimo de su organización para poder ocultar sus huellas de manera efectiva. Estas cosas pueden ser de naturaleza tecnológica o estar basadas en los hábitos de trabajo y las directrices internas de tu organización. Aquí hay algunos ejemplos:
- Horas de trabajo típicas: Algunas organizaciones en las que trabajé no permitían a los empleados trabajar desde casa en absoluto y la mayoría de los empleados ya habrían dejado la oficina a las 19:00. Para organizaciones similares, tendría sentido establecer una alerta para notificar las conexiones desde la oficina después de una hora determinada. Un atacante que instalara software malicioso en su organización tendría que conocer ese comportamiento y afinar su malware para comunicarse con sus servidores de Control de Comando & precisamente a la misma hora en que dichas comunicaciones pasarían desapercibidas.
- Navegador típico: Supongamos que su organización ha decidido utilizar el navegador Brave como navegador principal y que se instala en cada nuevo portátil corporativo de forma automática y que usted ha eliminado los accesos directos del escritorio al navegador IE/Edge de todos sus portátiles corporativos. Si este es el caso, una conexión desde la organización, tanto a una dirección interna como externa que utilice un navegador diferente como IE/Edge debe ser configurada para lanzar una alerta.
- Rangos IP basados en Roles: Si es posible asignar diferentes rangos de IP para diferentes servidores basados en su rol, por ejemplo, tener todos los servidores de base de datos en 192.168.0.0/24, los servidores web en 192.168.1.0/24, etc. entonces sería posible e incluso fácil configurar reglas inteligentes basadas en el comportamiento esperado de sus servidores basados en su rol. Por ejemplo, los servidores de bases de datos no suelen conectarse a otros servidores por su cuenta, las impresoras no intentan conectarse a sus controladores de dominio, etc.
- Intentos de conexión inusuales: Muchas organizaciones utilizan un recurso compartido público en un servidor de archivos para ayudar a sus usuarios a compartir archivos entre ellos y utilizan impresoras habilitadas en red para permitir a sus usuarios imprimir directamente desde sus ordenadores. Esto significa que los ordenadores cliente no deberían conectarse entre sí, incluso si se ha optado (sabiamente) por bloquear dicho acceso en un cortafuegos o en el conmutador, el mero intento de conexión de un cliente a otro ordenador cliente debería levantar una alerta y ser investigado a fondo.
- Puertos no comunes: Algunas organizaciones utilizan una librería especial para la optimización de la comunicación entre servicios, de forma que toda la comunicación HTTP entre servidores utiliza un puerto diferente a los comunes (como el 80, 443, 8080, etc). En este caso, es una buena idea crear una regla que se active ante cualquier comunicación en estos puertos normalmente comunes.
- Honeytokens – En un campo de batalla como Internet, donde todo el mundo puede ser casi cualquiera, el engaño, funciona tan bien para los defensores como para los atacantes, si no mejor. Trucos como cambiar el nombre de la cuenta de administrador incorporada a un nombre diferente y menos atractivo y crear una nueva cuenta llamada Administrador que nunca utilizarás y crear una regla Snort para detectar si este nombre de usuario, correo electrónico o contraseña se utilizan alguna vez en la red. Sería casi imposible que los atacantes se dieran cuenta de que Snort ha detectado sus intentos de utilizar el usuario administrador falso. Otro ejemplo es crear productos, clientes, usuarios y registros de tarjetas de crédito falsos en la base de datos y luego hacer coincidir las reglas de Snort para detectarlos en el tráfico de la red.
Esperamos que haya encontrado esta información útil. Para obtener más información sobre el STA de Coralogix, consulte las últimas características que hemos publicado recientemente.