/var/log/secure:Feb 9 13:21:45 secure sshd[1230]: Failed password for illegal user tobias from xxx.xxx.xxx.xx port 43836 ssh2
/var/log/secure:Feb 9 13:21:46 secure sshd[1233]: Illegal user web000 from xxx.xxx.xxx.xx
/var/log/secure:Feb 9 13:21:49 secure sshd[1233]: Failed password for illegal user web000 from xxx.xxx.xxx.xx port 43939 ssh2
Wie heist denn der Schlingel, und wie kann ich den Identifizieren?
Nein im Ernst. Benutze mal die Forensuche.
Man versucht sich auf deinem Server einzuloggen, aber da du die IP ausge"x"t hast kann man auch net sagen woher das kommt. Aber ich sehe keinen ausgehenden versuch, die werden nicht geloggt.
Gruß Christian
BofH excuses: YOU HAVE AN I/O ERROR -> Incompetent Operator error
Ja, genau.
Es hat eine Beschwerde gegeben, und da hab ich das eben gesehen.
Nun weiss ich nicht, wie ich das lokalisieren kann wer da was macht, und woher das kommt.
Noch 2 Beschwerden, und der Server wird vom Netz genommen.
Schau doch mal nach was an Prozessen läuft und komisch ist.
Wobei wenn Du jemand auf der Maschine hast es nix mehr vertrauenswürdig ist, wenn dem so ist kommst du um ein Reinitialisieren eh net rum.
Was spricht ein netstat -tulpen?
Ist wer eingeloggt außer dir?
Gruß Christian
BofH excuses: YOU HAVE AN I/O ERROR -> Incompetent Operator error
Ne, ich bin alleine eingeloggt.
Diese Angriffe kommen wohl durch irgendeinen Wurm, der vielleicht durch ein User im Forum wbb hochgeladen wurde. Ich hatte CPU load 75 und habe einen reboot gemacht. Nun ist es wieder ruhig, aber das wird ja nicht lange dauern, biss es wieder anfängt.
Du kannst den User zwar löschen und seine Verzeichnisse entfernen, das garantiert dir aber nicht, dass nicht irgendwo noch etwas liegt bzw. Hintertürchen offen sind.
Also Server in den Rescue-Modus, Daten sichern, Logs sichern und die Kiste neu initialisieren lassen.
Bevor du neustartest, kannst du mal schauen, ob du im /tmp-Verzeichnis noch etwas findest, was Rückschlüsse auf die Sicherheitslücke zulässt.
Scheint nun wieder zu gehen.(Mit großartiger Hilfe :D)
Der Hack wurde über eine Datei namens p.php gestartet.
Der Angreifer kam / kommt über eine rumänische IP von Cablelink Slatina
Auszusperrende IPs:
82.78.140.0 - 82.78.143.255
Bei mir sah es ähnlich aus.
Anscheined hat sich die Datei durch eine alte Version von phpBB in einer vergessenen Subdomain auf meinem Server eingeschlichen.
Ersteinmal das phpBB-Forum deaktiviert und gelöscht. Wurde sowieso nicht mehr genutzt!
Auf dem Server durfte ich auch einige Dateien im /tmp und /var/lib/wwwrun löschen um den ganzen Kram los zu werden.
Ich muß zugeben, das ich einige elementar Sicherheitsrichtlinien nicht beachtet habe.
Mein "public_html"-Verzeichniss habe ich immer mit FTP als Root bearbeitet. Also waren auch alle Datei root:root. Ganz Böse!!!
Einen reinen FTP-User und Gruppe erzeugt. Keinen Shell Zugriff.
Anschließend alle Dateien in "public_domain" auf den FTP-User gesetzt ftp_user:ftp_group (natürlich nicht mit diesen Namen!)
Und vorsichtshalber den zugriff auf /var/lib/wwwrun deutlich eingeschränkt.
Seid 2 Monaten habe ich keine Probleme mehr mit dem Eindringling.
Für Vorschläge was man besser/anders machen kann bin ich natürlich offen.
Safemode = off Rest war standart.
Bei mir war kein phpbb mehr drauf, aber eine WBB 2.3.3
Die habe ich immer noch im Verdacht, aber es kann auch über unsichere FTP Passwörter passiert sein, die ich jetzt nach einem neuen Image auch anders generiert habe.
Bei dem 2 Angriff wurden folgende Dateien verändert:
/sbin/sysctl [ BAD ]
/bin/kill [ BAD ]
/bin/more [ BAD ]
/bin/ps [ BAD ]
/usr/bin/top [ BAD ]
/usr/bin/w [ BAD ]
/usr/bin/whereis [ BAD ]
Dieses Mal war es dann auch der root als User.
Kann man die iP Blöcke nicht in der http.conf sperren?
Was brauche ich rumänische Besucher???
afrika123 wrote:Bei dem 2 Angriff wurden folgende Dateien verändert:
/sbin/sysctl [ BAD ]
/bin/kill [ BAD ]
/bin/more [ BAD ]
/bin/ps [ BAD ]
/usr/bin/top [ BAD ]
/usr/bin/w [ BAD ]
/usr/bin/whereis [ BAD ]
Dieses Mal war es dann auch der root als User.
Kann man die iP Blöcke nicht in der http.conf sperren?
Was brauche ich rumänische Besucher???
Server neu initialisieren lassen!
Konfiguriere deine Dienste besser oder sperre alle User aus (shutdown -h now), partiell irgendwelche IPs zu sperren und die eigentlichen Sicherheitslücken offen zu lassen, ist doch schwachsinnig
Es ist schon ein neues Image drauf, und auch gleich mit aktuelleren Versionen. Trotzdem werden nie alle Sicherheitslücken zu schließen sein, wenn User eigene Daten hochladen können.
Feb 23 17:19:01 www kernel: printk: 85 messages suppressed.
Feb 23 17:19:01 www kernel: ip_conntrack: table full, dropping packet.
Feb 23 17:19:05 www kernel: printk: 17 messages suppressed.
Feb 23 17:19:05 www kernel: ip_conntrack: table full, dropping packet.
Feb 23 17:19:10 www kernel: printk: 17 messages suppressed.
Feb 23 17:19:10 www kernel: ip_conntrack: table full, dropping packet.
Feb 23 17:19:20 www kernel: printk: 223 messages suppressed.
Feb 23 17:19:20 www kernel: ip_conntrack: table full, dropping packet.
Heute Morgen um halb 3 wurde der Root von meinem Provider vom Netz genommen, weil er laut dessen Aussage DoS-Attacken durchführte...
Nun bin ich im Rescue-System und weiß nicht wirklich weiter... wie finde ich nun heraus was da los ist und wie kann ich es unterbinden? Ich habe auf dem server einige Webseiten, die schnellstens online müssen - aber wenn ich die Kiste im normalen Modus boote und er macht weiter wirds sehr teuer....