Frage, Teil eines Botnetz, aber durch was?

D

Domi

Member
Hallo Leute, ich habe seit gestern ein kleines Problem und dachte eigentlich ich hätte es gelöst.. aber Pustekuchen.

Auf meinem Server sind Domains von mir, und ein paar Domains von Bekannten von mir. Bevor ich aber jeden Anpfeife das er seine Webinhalte prüfen soll, wollte ich selbst einmal auf die Suche gehen.

ClamAV hat leider nichts gefunden. Und via 'netstat' habe ich auch nichts herausgefunden. Ich vermute mal, dass lag auch eher daran das weil die Verbindungen genau dann NICHT zustande kamen als ich geschaut habe.

Jetzt ist also meine Frage an Euch, wie ich dem Phänomen auf die Schliche gehe um es zu lösen :) Mein Server meldet sich ab und an mit folgenden Daten,
- "BOT/0.1 (BOT for JCE)"
- "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"

Hat jemand einen oder mehrere Tipps für mich, oder handelt es sich hierbei um ein Phänomen wie es bei manchen Windows Systemen der Fall ist, und ich muss alles am besten komplett neu aufsetzen?!

Gruß, Domi
 
Mein Server meldet sich ab und an mit folgenden Daten,
- "BOT/0.1 (BOT for JCE)"
- "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
Click to expand...
Wie kann sich dein Server so melden?
Du meinst, es kommen Anfragen mit diesen Browser-Kennungen an deinen Server?
 
Ne ne... Sorry, das war vielleicht doof formuliert. Das Abuse Team von Hetzner hat mir folgende Zeilen mitgesendet,
Code: 
Here are more information about xxx.xxx.xxx.xxx:
Lines containing IP:xxx.xxx.xxx.xxx in /furanet/sites/*/web/htdocs/logs/access

/furanet/sites/espartinas.net/web/htdocs/logs/access:xxx.xxx.xxx.xxx - - [07/Dec/2014:02:52:15 +0100] "GET /images/stories/petx.php?baca HTTP/1.1" 404 1440 "-" "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
/furanet/sites/espartinas.net/web/htdocs/logs/access:xxx.xxx.xxx.xxx - - [07/Dec/2014:02:52:22 +0100] "GET /images/stories/explore.php?baca HTTP/1.1" 404 1440 "-" "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
/furanet/sites/espartinas.net/web/htdocs/logs/access:xxx.xxx.xxx.xxx - - [07/Dec/2014:02:52:29 +0100] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1" 303 - "-" "-" "BOT/0.1 (BOT for JCE)"

Date: Sun Dec  7 02:52:35 CET 2014

Unix timestamp: 1417917150.6

Und da sieht man ja, dass mein Server oder meine IP eine Verbindung zu dem genannten Server aufbaut und einen HTTP Request hin sendet.

Gruß, Domi
 
Also die Joomla Versionen sind auf einem aktuellen Stand. Es sind unter anderem 2.5 und 3.x installiert. Ein Upload Verzeichnis gibt es auch in einer der Versionen. Auch zwei WordPress Systeme sind installiert, diese habe ich aber am Donnerstag in der Nacht auf Freitag mit den aktuellsten Updates für den Core und Plugins bestückt.

Gibt es vielleicht eine Möglichkeit zu tracken, von wo aus mein Server diese Verbindung aufbaut, oder ist das eher eine unmögliche Geschichte?
 
Du hast ja die genauen Zeitpunkte der Zugriffe aus den Logs, die Hetzner dir mitgeschickt hat.
Evtl. kannst du auf deinem Server über die Access-Logs herausfinden, wer zu diesem Zeitpunkt (+/- 30s) merkwürdige Requests, insbesondere POST-Requests ausgeführt hat. Darüber hättest du einen Anhaltspunkt, wo die Ursache - meistens irgendwelche getarnten Scripte - liegen könnte. Alternativ kann eine Suche nach dem Remote-Hostname (in diesem Fall vermutlich espartinas.net) über deine Access-Logs helfen - falls da entsprechende Anfragen per GET-Parameter gekommen sind, würdest du sie so sehen.

Akut kannst du mit tcpdump (vorher auf aktuellste Version updaten!) mal alle ausgehenden Verbindungen mit DST-Port 80 prüfen - da werden ja wohl aktuell wohl noch Requests rausgehen. Parallel kannst du dann schauen, ob sich da was in irgendwelchen Logfiles zeigt oder Prozesse aktiv werden.

Die Syntax für tcpdump lautet in diesem Fall so in etwa:
Code: 
tcpdump -i eth0 -n 'dst port 80 && src host DEINESERVERIP' -X

Damit werden alle ausgehenden Daten zu Port 80 auf die Konsole geschrieben und du kannst sehen, ob da Anfragen mit den passenden User-Agents rausgehen.
 
Hallo Lord Gurke,

die access.log Files hatte ich als aller erstes mit 'grep' durchsucht. Sowohl nach dem Hostnamen, als auch der IP Adresse. Entweder habe ich etwas falsch gemacht, oder es war wirklich nichts zu finden.

Aber nach der Uhrzeit im Log hatte ich noch nicht geschaut. Das wäre natürlich ein guter Ansatz. Parallel werde ich mal mit 'tcpdump' schauen ob ich etwas finde und dann gebe ich mal ein Feedback. Dafür muss ich nur erst mal den Server wieder aus dem Rescue Modus holen ;)

Danke schon mal für die Tipps.
Gruß, Domi
 
Hallöchen... Also eigentlich wollte ich Fortschritte in der ganzen Geschichte posten, aber nachdem ich gestern einmal ein Update von einigen Paketen gemacht hatte, ist das System nicht mehr hoch gefahren.

Als ich dann via LARA alles heile machen wollte, gab es da schon Probleme mit dem System... irgendwie machte auch das Rescue System Probleme :rolleyes:

Nun ja, nachdem ich dann ein paar Stunden daran saß, alles schön zu machen, habe ich einfach mein Backup genommen, das System neu installiert (installimage) und dieses wieder eingespielt. Lustigerweise ist nun, obwohl alle Daten 1zu1 zurück gespielt worden, ruhe auf dem Server...

Ich werde es aber weiter beobachten und ein Statement abgeben, wenn sich wieder etwas bemerkbar macht ;)

Gruß, Domi
 
Ich würde empfehlen generell Benutzer, Zeitpunkt und IP+Port des Ziels von ausgehenden Verbindungen zu loggen. Natürlich musst du die Mitverwender des Servers darüber informieren aber es vereinfacht die Analyse bei Problemen deutlich.

Dazu brauchst du mal zuerst eine entsprechende Iptables-Regel:
Code: 
iptables -I OUTPUT -p tcp -m state --state NEW -j LOG --log-uid --log-prefix "tcp-out: "

In einem nächsten Schritt musst du die entsprechenden Log-Einträge in der rsyslog.conf filtern, dazu als allererste Regel:
Code: 
:msg, contains, "tcp-out: "  /var/log/connections-out.log
& ~

Nun hast du eine Logdatei mit folgenden Einträgen:
Dec 9 02:19:46 XXX kernel: [18968027.280335] tcp-out: IN= OUT=eth0 SRC=DIES.IST.DEINE.IP DST=DIES.IST.EMPFAENGER.IP LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=61635 DF PROTO=TCP SPT=60588 DPT=9000 WINDOW=65535 RES=0x00 SYN URGP=0 UID=BENUTZER-ID GID=BENUTZER-GRUPPE
Click to expand...

Das kann natürlich noch aufbereitet werden und Aktionen basierend auf diesen Ergebnissen durchgeführt werden aber das wird schon etwas komplexer ;)

ClamAV hat leider nichts gefunden. Und via 'netstat' habe ich auch nichts herausgefunden
Click to expand...
ClamAv ist _sehr_ schlecht im Erkennen von Exploits oder ähnlichem. Hier kann ich die 50$ einmalige Investition in den CXS Exploit-Scanner nur empfehlen. Als Schmankerl erkennt er bei üblicher Software auch veraltete Versionen oder sogar Plugin-Versionen was für Präventivmaßnahmen top ist.
Offiziell gibt es ihn nur als cPanel-Plugin, die Binärdatei funktioniert jedoch auch tadellos unter gängigen anderen Systemen auf der Konsole.
 
Hi d4f, danke schon mal für die Information mit dem iptables. Hätte mir auch einfallen könne, aber hatte noch nie das Bedürfnis ausgehende Verbindungen loggen zu müssen.

Da ich in einem anderen Topic davon ausging, dass es wieder vom WordPress kam, ist dort auch der Tipp gekommen "wenn du fast-cgi / fpm verwendest" dann könnte ich anhand der User ID herausfinden von wo das kommt. Mein Vorteil ist, dass ich das mittlerweile verwende... vielleicht erhalte ich dann noch genauere Informationen.

Aber da habe ich schon mal einen Ansatz zum prüfen.
Und wenn du sagst, dass man für $50 schon mal etwas bekommt, was ziemlich (oder relativ) zuverlässig ist, dann zahle ich das auch gerne.

Gruß, Domi

Nachtrag: Ich habe mal als source, meine IP eingetragen da er auch die localhost Verbindungen mit protokolliert. Aber UID und GID erfasst er auch. Somit kann ich schon mal den Kreis weiter einschließen, wenn es zu Problemen kommt :)
 
Last edited by a moderator:
"wenn du fast-cgi / fpm verwendest"
Click to expand...
Ich ging davon aus dass jeder Webspace unter einem eigenen Benutzer läuft. Die Zeiten vom "www-data Problem" und damit verbundenen Sicherheitsproblemen sollten schon länger vorbei sein....
Da oft mod_php zum Einsatz wegen diversen Vorteilen in Flexibilität, Leistung und Administration zum kommt kann ich zum Erreichen der gleichen Vorteile Apache MPM_ITK empfehlen. Dann laufen die Apache-Prozesse unter dem jeweiligen Benutzer, die Serverumgebung selber muss dafür aber nicht umgekrempelt werden.

Ich habe mal als source, meine IP eingetragen da er auch die localhost Verbindungen mit protokolliert.
Click to expand...
Localhost ist in der Tat unnötig, es sei denn du lässt direkten Zugriff auf Port 25 zu (sowohl lokal als auch extern). Dies würde ich aber generell blockieren, PHP-Anwendungen sollen entweder eine korrekte SMTP-Authentisierung auf SMTP-Submission Port 587 durchführen oder mail() verwenden.
 
Wegen dem MPM_ITK Paket lese ich mich mal schlau, aber das dürfte ja weg fallen wegen fast_cgi oder fpm was ich bei mir auf dem Server verwende. Wobei ich bevorzugt 'fast_cgi' verwende, denn manche Dinge wie Uploads in einem CMS machen oft Probleme bei aktivierten 'fpm' was wohl besser sein soll.

Und wegen dem SMTP Port, da wird Auth verlangt um keinen Open-Relay bereit zustellen. Ebenfalls ist die php mail() disabled über die php.ini im Apache, CGI und FPM Verzeichnis. Zumindest sagt mir php_info() das es nicht erlaubt ist :)

Gruß, Domi
 
Und wegen dem SMTP Port, da wird Auth verlangt um keinen Open-Relay bereit zustellen.
Click to expand...
Generell ist da aber localhost ausgeschlossen, wenn ein Skript über TCP also nach localhost Port 25 verbindet kann es Emails ohne Authentisierung versenden.
Dann bliebe auch noch Port 25 ausgehend, viele Spam-Skripte sind (leider) so klug direkt Emails an den Empfänger zu zu stellen. Besonders prekär ist dabei dass natürlich dann keine Einträge im eigenen Mail-Log dazu zu finden sind.

Wegen dem MPM_ITK Paket lese ich mich mal schlau, aber das dürfte ja weg fallen wegen fast_cgi oder fpm was ich bei mir auf dem Server verwende.
Click to expand...
Genau, du brauchst nur das Eine oder das Andere. Die Kombination ergibt nicht sonderlich viel Sinn.

Ebenfalls ist die php mail() disabled über die php.ini im Apache, CGI und FPM Verzeichnis.
Click to expand...
Damit wirst du zwar Spammer einen Stein in den Weg legen, aber auch sehr vielen legitimen Programmen. So ziemlich jede PHP-Anwendung will irgendwann Emails versenden.
 
Moin moin.. Ich wollte mal ein Feedback zu der Geschichte wegen dem Log abgeben :)

Also das hat prima funktioniert. Als eine meiner Domains wieder versucht hatte, nach draußen zu senden, habe ich einfach mal geschaut welche UID dort zu den Zeiten hinterlegt war. Anschließend habe ich dann im Log der Domain die Zeiten verglichen und die Böse Datei identifizieren können :)

Es sind definitiv die installierten WordPress Systeme... eines der Systeme wurde gestern noch einmal kompromittiert und ich habe stumpf das Verzeichnis leer gemacht, das aktuellste System ohne Themes oder Plugins hoch geladen. Anschließend habe ich die gesäuberten Uploads hoch geladen und nun behalte ich das einmal im Auge :)

Gruß, Domi
 
You must log in or register to reply here.
Back
Top