Folgen eines offensichtlichen DOS-Angriffs - httpd versucht, Kontakt zum Angreifer aufzunehmen

Folgen eines offensichtlichen DOS-Angriffs - httpd versucht, Kontakt zum Angreifer aufzunehmen

Ich habe einen Server, auf dem mehrere Webhosts laufen (alle intern verwaltet), der gestern Abend Ziel eines scheinbaren DoS-Angriffs war. Ich habe die angreifende IP in IPTABLES für die Eingabe- und Ausgabeketten blockiert. Das schien das Problem zu lösen und ich ging nach Hause.

Heute Morgen ist der Server erneut abgestürzt – diesmal scheint es laut Netstat so, als ob er mehrere SYNs an die angreifende IP gesendet hätte. OffensichtlichSie wurden von der IPTABLES OUTPUT-Kette gelöscht, es waren jedoch so viele im Stapel, dass ein Fehler auftrat.

Ich mache mir Sorgen, dass der Server Syns an den Angreifer sendet. Vermutlich versucht er, eine neue ausgehende Verbindung zur Angreifer-IP auf Port 80 herzustellen, aber warum? Bedeutet das, dass der Server kompromittiert ist? Wie kann ich herausfinden, was die Ursache dafür ist? Ich habe es mit netstat -p versucht, aber es zeigt nur den Besitzer der ausgehenden Versuche als httpd an.

Das Webverzeichnis enthält einige große Sites, sodass mein Versuch, in allen Webdateien nach der IP-Adresse des Angreifers zu suchen, Tage dauern würde.

Was zu tun?

Vielen Dank im Voraus....

Antwort1

Der Server/virtuelle Host ist möglicherweise kompromittiert und die Site versucht möglicherweise, zusätzliche Shells/Backdoors/Anweisungen herunterzuladen. Es ist schwer zu sagen, wie man herausfinden kann, welcher virtuelle Host betroffen ist.

Wenn Sie nicht auf dem Produktionsserver greppen können, können Sie versuchen, auf dem Backup zu greppen. Dasselbe gilt für Protokolle.

Oder schauen Sie sich einfach die Dateien an, die in den letzten 24–48 Tagen geändert wurden.

Wenn httpd=Apache ist, können Sie versuchen, die PID von netstat abzurufen und dann eine Übereinstimmung in der Serverstatusausgabe zu finden (wenn die IP gelöscht wird, wird dieser Server-Thread möglicherweise sehr lange ausgeführt, bis wget/curl/was auch immer eine Zeitüberschreitung verursacht).

Sie können auch versuchen, Anfragen mit sehr langen Antwortzeiten in den httpd-Protokollen zu finden (Sie müssen das Protokollformat ändern, da normalerweise keiner der Webserver die Anfragezeit protokolliert).

verwandte Informationen