Introducción
Un equipo suele cargar documentos en docs.approved.test. Una pequeña captura grabada también contiene cargas a otro destino. Tienes autorización para construir un detector sin conexión para estos intercambios sintéticos.
Una captura de paquetes (PCAP) almacena paquetes de red. Suricata reconstruye sus solicitudes HTTP y prueba reglas de detección. Aquí lee archivos y no contacta esos hosts. Todos los nombres y documentos son ficticios. HTTP sin cifrar permite ver el cuerpo; este ejercicio no demuestra cómo leer tráfico HTTPS cifrado.
Introduce comandos en la pestaña Analyst. Selecciona la pestaña Traffic Reference para ver las mismas solicitudes preparadas que traffic/requests.txt; la página de referencia se abre directamente. Son ejemplos grabados, no una topología en vivo. Solo necesitas saber introducir comandos y cambiar de pestaña. No se presupone experiencia con IDS.
Reconocer solicitudes de carga
Selecciona la pestaña Analyst en la interfaz del laboratorio para comenzar este paso.
En este paso, crea una primera regla que encuentre solicitudes POST, incluidas las cargas normales. Una alerta indica una coincidencia; no demuestra un compromiso ni bloquea tráfico.
HTTP es un protocolo de solicitudes y respuestas. El método indica la acción: POST envía contenido y GET solicita un recurso. La cabecera Host identifica el sitio de destino, la URI su ruta y el cuerpo los campos del documento enviado. Cambia a la pestaña Traffic Reference para ver los intercambios HTTP preparados en el navegador. La página es una referencia, no un monitor de paquetes en vivo. Vuelve después a la pestaña Analyst para leer los mismos intercambios y ejecutar todos los comandos siguientes. cat imprime un archivo y las rutas indican su ubicación.
Cambia a la pestaña Analyst antes de ejecutar el siguiente comando.
cat traffic/requests.txt
Compara el POST legítimo a docs.approved.test, el GET del colector y el POST con classification=internal. La organización permite documentos internos en el servicio aprobado. La ruta del colector puede recibir documentos públicos de demostración, pero no internos. Importa la combinación de destino y contenido; un host desconocido no basta como prueba.
Una regla Suricata tiene cabecera y opciones entre paréntesis. alert http genera alertas sobre HTTP analizado. Los dos pares any any aceptan cualquier dirección y puerto de origen/destino; -> indica origen a destino. flow:established,to_server limita la inspección a solicitudes de un cliente conectado. El punto y coma termina cada opción. msg describe la coincidencia, sid es el identificador numérico de firma y rev la revisión. Cada regla usa un sid único.
Un búfer persistente selecciona el campo HTTP que inspeccionará el siguiente content. http.method selecciona el método. content:"POST" busca ese texto; startswith y endswith exigen el campo completo, no una subcadena. Usa la siguiente regla.
cat > method.rules escribe el archivo y reemplaza su contenido anterior. <<'RULE' inicia una entrada literal de varias líneas; el RULE final debe estar solo en su línea. Es una forma sencilla de editar. Si te equivocas, ejecuta de nuevo el bloque completo.
cat > method.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; sid:1000001; rev:1;)
RULE
Reproduce la captura. mkdir -p crea el directorio de salida y acepta uno existente. --runmode single usa un hilo para procesar paquetes; -c selecciona la configuración; -S carga exclusivamente tu archivo de reglas; -r lee el PCAP; -l elige la salida. --init-errors-fatal detiene el proceso si una regla no carga. La configuración inspecciona hasta 64 KB de cada cuerpo; todos los suministrados caben. Los límites de un despliegue real requieren otra evaluación.
mkdir -p method-output
suricata --runmode single -c suricata.yaml -S method.rules -r traffic/core.pcap -l method-output --init-errors-fatal
python3 /opt/c09/read-alerts.py method-output/eve.json
El mensaje de parada de Suricata es normal al llegar al final del archivo sin conexión. eve.json contiene un objeto JSON por evento. JSON usa campos con nombre: event_type: alert identifica una coincidencia, signature_id su regla y los campos HTTP la solicitud. El lector Python suministrado muestra puerto de origen, método, host, URI e ID de firma por alerta. El puerto vincula el intercambio con la referencia; no es una condición de política.
Espera Alerts: 10. Aparecen tanto el POST normal de documentos como los POST al colector. GET y PUT quedan silenciosos. Este primer detector, deliberadamente amplio, enseña la coincidencia por método.
El comprobador ejecuta tu regla sin modificar sobre dos pequeños corpus independientes en directorios de salida desechables. Ignora registros guardados y conserva regla y capturas. Comprueba el detector de método:
python3 /opt/c09/check.py method.rules method
Ambas líneas deben indicar 10 intercambios previstos. Si Suricata informa de un error de sintaxis, revisa comillas, puntos y comas y paréntesis final, reescribe y reintenta. Reutilizar el directorio de salida añade eventos; usa uno nuevo al comparar cantidades. El comprobador siempre empieza limpio.
Seleccionar el destino del colector
Selecciona la pestaña Analyst en la interfaz del laboratorio para comenzar este paso.
En este paso, combina método y host para excluir las cargas normales al servicio de documentos. Todos los búferes de una regla deben coincidir en la misma transacción HTTP.
El nombre del sitio de destino pertenece a http.host, no a una búsqueda en el cuerpo: un documento podría mencionar el colector sin enviarse allí. Suricata normaliza este búfer a minúsculas. La referencia incluye collector.example.test.other.test, un host distinto que la coincidencia de campo completo mantiene separado.
Crea otro archivo y conserva el primer detector para comparar. Mantén cabecera y condición de método; el nuevo búfer añade el destino.
Cambia a la pestaña Analyst antes de ejecutar el siguiente comando.
cat > destination.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; http.host; content:"collector.example.test"; startswith; endswith; sid:1000001; rev:1;)
RULE
mkdir -p destination-output
suricata --runmode single -c suricata.yaml -S destination.rules -r traffic/core.pcap -l destination-output --init-errors-fatal
python3 /opt/c09/read-alerts.py destination-output/eve.json
Espera Alerts: 6. Desaparecen el servicio aprobado y el host de nombre parecido. Los POST a /status y /collect-backup siguen coincidiendo porque todavía no se distinguen rutas. Son falsos positivos conocidos útiles: coincidencias fuera del comportamiento que deseas investigar.
python3 /opt/c09/check.py destination.rules destination
Ambos corpus deben coincidir en seis intercambios de método y host. Si un host permitido sigue alertando, comprueba que startswith; endswith; sigan al contenido del host. Cambiar un evento JSON guardado no corrige el detector; cambia la regla y reproduce.
Limitar la detección a la ruta de carga
Selecciona la pestaña Analyst en la interfaz del laboratorio para comenzar este paso.
En este paso, crea un detector de ruta funcional y reconoce su limitación respecto al contenido. La URI es la ruta de la solicitud, como /collect, y es distinta del host.
Usa http.uri y coincidencia de campo completo para seleccionar exactamente /collect. /collect-backup es otra ruta. Conserva las restricciones de método y destino para no alertar sobre solicitudes de salud ni destinos legítimos.
Cambia a la pestaña Analyst antes de ejecutar el siguiente comando.
cat > upload.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; http.host; content:"collector.example.test"; startswith; endswith; http.uri; content:"/collect"; startswith; endswith; sid:1000001; rev:1;)
RULE
mkdir -p route-output
suricata --runmode single -c suricata.yaml -S upload.rules -r traffic/core.pcap -l route-output --init-errors-fatal
python3 /opt/c09/read-alerts.py route-output/eve.json
Espera Alerts: 4, correspondientes a 41002, 41003, 41007 y 41011. Compara sus cuerpos en la referencia: dos contienen documentos internos y dos demostraciones públicas. Los cuatro son POST al host y ruta elegidos. El detector supervisa la ruta, pero exagera las cargas sensibles.
python3 /opt/c09/check.py upload.rules route
Ambos corpus deben coincidir en cuatro intercambios de ruta. El comprobador también cambia nombres de documentos y puertos de origen: esos valores incidentales no deben decidir la detección. Explica el propósito de la regla al compartir alertas. El siguiente laboratorio añade contexto documental y prueba la reducción de ruido en un entorno nuevo.
Resumen
Construiste detectores de método, destino y ruta mediante la reproducción real de Suricata. Relacionaste las alertas con solicitudes grabadas e identificaste falsos positivos de documentos públicos antes de afirmar que detectabas cargas sensibles.
