perl irc bot :(

[thomast]

hi,

nachdem ich die immerwieder laufenden perlbots z.b. "ilegalbrain PerlBot v4.5"
nicht weg bekommen habe, habe ich mein vps komplett neu installiert.

nach bereits einem tag läuft der perlbot auf dem neuen system wieder. Ich hatte alle passwörter geändert und alle OS-updates eingespielt.

es muss also irgendein, joomla, worpress o.ä. mit lücken sein über das der bot rein kommt.

Gibt es eine möglichkeit raus zu finden welches die unsicheren dateien sind?

 

[Mr.Check]

MOD: Full-Quote entfernt!

Steht denn nichts in den Logfiles dazu? Ansonsten würde ich empfehlen (da der Befall ja recht schnell kommt) die von dir genannten Scripts nach und nach zu installieren und abzuwarten, wann der Bot wieder auftaucht. Im Zweifelsfall einfach von allen genannten die aktuellste Version verwenden, dann solltest du eigentlich auf der sicheren Seite sein.

 

[its]

Leider kann man das, ohne einen Blick in die Logfiles zu werfen, nicht definitiv sagen, wie die Angreifer bei dir immer wieder rein kommen.

Sofern du keinen Trojaner auf deinem eigenen Rechner hast, würde ich auf

- TimThumb Hack

tippen. (aber meine Glaskugel ist leider nicht allwissend)

Poste doch bitte mal ein paar Logfiles, oder schaue selber mal nach RFI,SQLi,etc Angriffen in den Logfiles.

 

[mr_brain]

MOD: Full-Quote entfernt!

Könnte z.B. Joomla und auf Grund erlaubter PHP-Optionen allow_url_include und allow_url_fopen eingefangen worden sein.

 

[thomast]

Poste doch bitte mal ein paar Logfiles, oder schaue selber mal nach RFI,SQLi,etc Angriffen in den Logfiles.

das ist leider nicht so einfach, da auf dem server knapp 30 domain laufen, mit jweils eigenen logfiles, da ich auch freunden webspace gegeben habe, muss ich dort jede domain dursuchen, was installiert ist

wenn ich wüste wonach ich in den logs suchen muss??

in /tmp liegen immer die perlbot scripte, mit z.b. namen "a.txt"

in den logfiles steht jedoch nichts dergleichen.

ich denke der holt den bot von irgendwo gepackt, und entpackts dann in /tmp.
aber auch sowas wie GET *.zip etc. hab ich in den logs nicht gefunden.

 

[virtual2]

Dann sicher das system doch ein wenig via suexec & strike php einstellungen.

 

[nexus]

das ist leider nicht so einfach, da auf dem server knapp 30 domain laufen, mit jweils eigenen logfiles, da ich auch freunden webspace gegeben habe, muss ich dort jede domain dursuchen, was installiert ist

Sorry, aber das ist nunmal deine Aufgabe als ServerAdmin, die Logfiles zu überprüfen...und zwar regelmäßig und nicht erst, wenn die Kiste vor die Wand gefahren wurde...

P.S.:
Was die Webspacevergabe an deine Freunde angeht, hast du hoffentlich mit denen eine (schriftliche) Vereinbarung getroffen, in der du deinen Freunden die Verantwortung für alles überträgst, was auf deren Webspaces passiert. Denn offenbar gibt es Probleme auf deinem Server und als Mieter der Kiste bist du erstmal für ALLES verantwortlich, was über deine Kiste läuft!

 

[cmeerw]

MOD: Full-Quote gekürzt!
in /tmp liegen immer die perlbot scripte, mit z.b. namen "a.txt"

Dann hast ja zumindest einen Timestamp (von den Files) - dann brauchst ja nur nach dem Timestamp +/- ein paar Sekunden in den Log-Files suchen (sollte mit find/grep ja kein Problem sein).

 

[TerraX]

Vielleicht hilft es Dir pro Domain eigene Tempverzeichnisse einzurichten. Maybe erwischst Du damit die schuldige Domain und damit das verantwortliche Script (http://wiki.hetzner.de/index.php/Apache_PHP5_fcgi_und_SuExec).

 

[d4f]

Alternativ (einfacher ein zu richten) kannst du auch mpm_itk verwenden, dann kannst du mod_php wie gewohnt weiterbenutzen, musst nur eine Zeile "AssignUserId" in die vHosts setzen -und natuerlich die entsprechenden Unix-Accounts entweder in einer Datei oder per nss-XYZ in einer Datenbank haben.

Meist kann man diese Form der Exploits schon durch die 30tage-verzoegerte kostenfreie GotRoot mod_secuerity Regeln stoppen - allerdings stoppst du damit nur die bekannten Moeglichkeiten der Ausnutzung, nicht das Sicherheitsloch.

Es waere vermutlich klug bis auf weiteres mod_perl/mod_cgi und PHP's shell_exec sowie Konsorten zu deaktivieren bis du die SIcherheitsrisiken im Griff hast. Aktuell ist es naemlich grobe Fahrlaessigkeit wenn der Server -respektiv die betroffenen Benutzerkonten- weiter am Netz ist und dir der Einbruch bekannt ist....