Encuentre el proceso que realiza llamadas HTTP salientes, intentando auditarlo con syslog-ng

Encuentre el proceso que realiza llamadas HTTP salientes, intentando auditarlo con syslog-ng

Algunas aplicaciones (se desconocen) realizan solicitudes HTTP(S) salientes breves, raras, no regulares y esporádicas a un host/puerto/url conocido (este es un honeypot WAF, el host/url/puerto se conoce) utilizando el protocolo HTTPS. Las solicitudes pueden realizarse una vez cada 3 a 5 días. Es literalmente una solicitud breve cada 3 a 5 días. El objetivo es definir qué aplicación (ruta al binario, PID, etc.) realiza estas solicitudes. El servidor tiene una gran cantidad de software instalado, incluidos nginx, php, mariadb, etc.redisdocker

Para simplificar, la IP del honeypot tendrá aquí 7.7.7.7.

Lo que he probado hasta ahora:

  1. tcpdump
$ sudo tcpdump -i any dst host 7.7.7.7 and "tcp[tcpflags] & (tcp-syn) != 0" and "tcp[tcpflags] & (tcp-ack) == 0" &> /tmp/out_7.7.7.7_$(date "+%Y.%m.%d-%H.%M.%S").log &

Parece tcpdumpque no permite detectar la identificación del proceso o el ejecutable que realiza solicitudes http salientes.

  1. auditctl/auditado
sudo auditctl -a exit,always -F arch=b64 -S connect -k connectLog

auditctl/auditdParece que puede generar la ruta y el pid, pero carece de función de filtrado. Si inicio la regla de auditoría durante 3 a 5 días, mi disco estará lleno de registros de auditoría. O, si los registros de auditoría están rotando, podría perder los datos de registro requeridos en el archivo de registro que ya está rotado y eliminado. Si auditctltuviera una función de filtrado en escritura (no en registros de análisis) por IP de destino, probablemente sería el mejor candidato. ¿Quizás me falta algo y tiene función de filtrado?

Otra opción que descubrí es crear algún script bash, que:

  • inició la auditoría deconnect
  • Comenzó el proceso de monitoreo así: ( tail -f -n0 /var/log/audit/audit.log & ) | grep -q "7.7.7.7"
  • Una vez que el monitor detecte esto, deje de auditar.auditctl -d...

El problema es que este evento puede ocurrir después de 3 a 5 días, cuando todos los discos estén llenos.

  1. netstat
$ sudo netstat -tupnc | grep 7.7.7.7

Parece que netstatcon -cla opción (continuos) se repite la lectura cada 1 segundo. Dado que las solicitudes son muy breves, es posible que se pierda esta solicitud.

  1. ss

ssParece que no muestra el proceso que originó la conexión saliente.

  1. lsof
lsof -i TCP:80,443 -r 1

La conexión saliente es muy corta y rápida; es posible que no se registre ejecutando lsof cada 1 segundo.

  1. wireshark Wireshark tiene buenas funciones de filtrado (por IP), pero parece que no muestra el nombre del proceso de origen de la conexión o el pid.

  2. Actualmente estoy atrapado con la solución: combinar syslog-ng(que tiene capacidades de filtrado al recibir registros a través de TCP/red) como receptor y auditdcomo remitente de eventos de registro. Logré comenzar syslog-ngen el puerto 2222, recibir datos de la red y filtrarlos por alguna cadena (probado con curl). Pero no puedo gestionar auditdel envío de registros a la red.

Qué he hecho:

7.1) Instalado audisp-remote-plugin:

$ sudo apt install audispd-plugins

7.2) Habilitado audisp-remote plugin:

en el archivo /etc/audit/plugins.d/au-remote.conf: estableceractive = yes

7.3) audisp-remoteComplemento configurado:

en archivo /etc/audit/auditsp-remote.conf:

remote_server = 127.0.0.1
port = 2222

7.4) Escritura deshabilitada en un archivo de registro local

en archivo /etc/audit/auditd.conf:

write_logs = no

y reiniciado auditado:

$ sudo systemctl restart auditd

7.5) Se agregó una regla de auditoría para detectar conexiones ( connectsyscalls):

$ sudo auditctl -a exit,always -F arch=b64 -F saddr_fam=2 -S connect -k sckt

7.6) Registros rotados para limpiar datos anteriores en auditdlos registros

$ service auditd rotate

7.7) Llamada HTTP de prueba realizada:

$ curl -v https://7.7.7.7/api/v1/t

7.8) syslog-ngRegistro verificado, pero no tiene registros esperados.

Si alguien conoce cuál es el mejor enfoque más apropiado, fácil y simple para hacer esto, ¡cualquier ayuda será apreciada!

Respuesta1

Probablemente podría ingerir el registro de auditoría utilizando una fuente de archivo en syslog-ng y luego usar un tiempo de retención relativamente corto para los registros de auditoría.

Con eso, puede aplicar filtrado en el lado syslog-ng y generar los registros interesantes en un archivo de registro separado.

información relacionada