Suchen Sie nach Prozessen, die ausgehende HTTP-Aufrufe tätigen, und versuchen Sie auditd mit syslog-ng

Suchen Sie nach Prozessen, die ausgehende HTTP-Aufrufe tätigen, und versuchen Sie auditd mit syslog-ng

Einige Anwendungen (unbekannt) stellen sporadisch unregelmäßige, seltene, kurze ausgehende HTTP(S)-Anfragen an einen bekannten Host/Port/URL (dies ist ein WAF-Honeypot, Host/URL/Port ist bekannt) unter Verwendung des HTTPS-Protokolls. Anfragen können einmal alle 3-5 Tage auftreten. Es ist buchstäblich eine kurze Anfrage alle 3-5 Tage. Ziel ist es, zu definieren, welche Anwendung (Pfad zur Binärdatei, PID usw.) diese Anfragen stellt. Auf dem Server ist jede Menge Software installiert, darunter nginx, php, mariadb, redis, dockerusw.

Der Einfachheit halber hat die Honeypot-IP hier 7.7.7.7.

Was ich bisher versucht habe:

  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 &

Es scheint tcpdumpnicht möglich zu sein, die Prozess-ID oder ausführbare Datei zu erkennen, die ausgehende HTTP-Anfragen stellt.

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

auditctl/auditdscheint den Pfad und die PID ausgeben zu können, aber es fehlt die Filterfunktion. Wenn ich die Audit-Regel für 3-5 Tage starte, ist meine Festplatte voll mit Audit-Protokollen. Oder, wenn Audit-Protokolle rotieren, könnten mir erforderliche Protokolldaten in der bereits rotierten und gelöschten Protokolldatei entgehen. Wenn es eine auditctlFilterfunktion beim Schreiben (nicht beim Parsen von Protokollen) nach Ziel-IP gäbe, wäre es wahrscheinlich der beste Kandidat. Vielleicht übersehe ich etwas und es hat eine Filterfunktion?

Eine andere Möglichkeit, die mir eingefallen ist, besteht darin, ein Bash-Skript zu erstellen, das:

  • begann mit der Prüfung vonconnect
  • habe den Überwachungsprozess folgendermaßen gestartet: ( tail -f -n0 /var/log/audit/audit.log & ) | grep -q "7.7.7.7"
  • Sobald der Monitor dies erkennt, beenden Sie die Überwachungauditctl -d...

Das Problem besteht darin, dass dieses Ereignis nach 3–5 Tagen eintreten kann, wenn alle Festplatten voll sind.

  1. netstat
$ sudo netstat -tupnc | grep 7.7.7.7

Es scheint, dass netstatmit -cder Option (continuos) das Lesen jede Sekunde wiederholt wird. Da die Anfragen sehr kurz sind, könnte diese Anfrage übersehen werden.

  1. ss

ssEs scheint, als würde der Prozess, der die ausgehende Verbindung initiiert hat, nicht angezeigt.

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

Die ausgehende Verbindung ist sehr kurz und schnell, sie kann nicht protokolliert werden, indem lsof jede Sekunde ausgeführt wird

  1. Wireshark Wireshark verfügt über gute Filterfunktionen (nach IP), aber es scheint, dass der Prozessname oder die PID des Verbindungsaufbaus nicht angezeigt wird.

  2. Momentan komme ich mit der Lösung nicht weiter: Combine syslog-ng(das Filterfunktionen beim Empfangen von Protokollen über TCP/Netzwerk hat) als Empfänger und auditdals Absender von Protokollereignissen. Ich konnte erfolgreich syslog-ngauf Port 2222 starten, Daten vom Netzwerk empfangen und sie nach einer Zeichenfolge filtern (getestet mit curl). Aber ich kann keine auditdProtokolle an das Netzwerk senden.

Was ich getan habe:

7.1) Installiert audisp-remote-plugin:

$ sudo apt install audispd-plugins

7.2) Aktiviert audisp-remote plugin:

in Datei /etc/audit/plugins.d/au-remote.conf: setzenactive = yes

7.3) Konfiguriertes audisp-remotePlugin:

im Ordner /etc/audit/auditsp-remote.conf:

remote_server = 127.0.0.1
port = 2222

7.4) Deaktivieren des Schreibens in eine lokale Protokolldatei

im Ordner /etc/audit/auditd.conf:

write_logs = no

und auditd neu gestartet:

$ sudo systemctl restart auditd

7.5) Audit-Regel zum Abfangen von Verbindungen ( connectSystemaufrufen) hinzugefügt:

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

7.6) Rotierte Protokolle, um vorherige Daten in auditdProtokollen zu bereinigen

$ service auditd rotate

7.7) Test-HTTP-Aufruf durchgeführt:

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

7.8) syslog-ngProtokoll geprüft, aber es enthält nicht die erwarteten Datensätze.

Wenn jemand die geeignetste, leichteste und einfachste Vorgehensweise hierfür kennt, ist er für jede Hilfe dankbar!

Antwort1

Sie könnten das Prüfprotokoll wahrscheinlich mithilfe einer Dateiquelle in syslog-ng aufnehmen und dann eine relativ kurze Aufbewahrungszeit für Prüfprotokolle verwenden.

Damit können Sie auf der Syslog-ng-Seite Filter anwenden und die interessanten Datensätze in einer separaten Protokolldatei ausgeben.

verwandte Informationen