RootForum Community

Hallo Zusammen!

Unser Server wurde heute morgen um 6:15 gehackt! Jemand hat unsere index.php gelöscht und durch eine .html (mit einem Hack-blabla) ersetzt.

Folgender Error-log-Eintrag ist interessant, aber ich verstehe ihn (bin Newbie - sorry!) nicht: ok, also Apache hat die URL ausgeführt und von dort diese Telnet-Client geladen. Nur, wie schafft man es, unseren Apache dazu zu bewegen???

Gefunden habe ich den (telnetd) in einem unterverzeichnis von meinem Forum (dieses braucht Verzeichnis-Rechte 777).

Es befanden sich mehrere warez-Dateien in dem Ordner, die ich gelöscht habe...
Traffic ist bisher kein nennenswerter angefallen.


Es handelt sich um ein (von 1&1) installiertes Suse 8.1 mit Confixx2Pro.

Was sollte ich am besten als nächstes tun?
Der Aufwand mit einer Anzeige lohnt sich meiner meinung nach nicht und herunterfahren (oder ins Resque) möchte ich das System nicht, da ich froh bin, endlich mal ein paar mehr Seitenzugriffe zu haben...

Gruß, Danke!
Flat-Jack

<paranioa>
runterfahren und zwar sofort!!!


du weist nich wieviele hintertüren sie sonst noch eingbaut haben wie hier scho öfters gesagt ->

recsue system alle logs sichern, chrootkit drüberlaufen lassen dann mal alle pws ändern oder am besten gleich neu initialisieren -> nachdem dun backup gemacht hast

so wies aussieht hatten sie zwar nur rechte von deinem apachen können aber sicher noch woanderst dateien abgelegt haben die du nicht gefunden hast -> evtl auch den attack nochmal machen
</paranioa>

Nur, wie schafft man es, unseren Apache dazu zu bewegen???

Bei

Gefunden habe ich den (telnetd) in einem unterverzeichnis von meinem Forum (dieses braucht Verzeichnis-Rechte 777).

wundert mich das nicht sonderlich viel. Wie oft hatte ich doch hier in den Foren gleich nochmal geschrieben, dass es NIE einen Grund gibt, warum man etwas auf 777 oder Schreibrechte für others setzen sollte?!

ok, keine 777-verzeichnis-rechte mehr...

Also, der Server ist frisch neu installiert worden - ich würde das ungern alles nochmal einrichten müssen.

chroot-kit meldet alles ok, außer: Das müsste doch ohne komplette Neuinitialisierung zu beheben sein, oder?


Danke für die Hilfe...
Gruß
Flat-Jack

Guter Rat : Neuinstallation ist das schnellste und sicherste in deiner Lage.

Hallo,

nur um Dich ein wenig nervös zu machen:

telnetd von dem von Dir genannten Server mag vielleicht (!)
auch ein "Telnet-Server" sein, in erster Linie ist es aber ein "Linux.RST.B"

-> http://securityresponse.symantec.com/av ... 10739.html
-> http://www.sophos.com/virusinfo/analyses/linuxrstb.html
-> http://www.sophos.de/virusinfo/analyses/linuxrstb.html

coolsurfer

ausgeführt habe ich den aber nicht, sonder direkt gelöscht - mein System sollte eigentlich nicht infiziert sein, oder?
Wenn doch, wo bekomme ich denn einen virenscanner? Habe da bisher nicht viel gefunden - ist ja eigentlich ein Thema der Windows-Welt! :?

Gruß
Flat-Jack

Ja du hast ihn nicht ausgeführt aber dein "Gast".

Ich würde dir wärmstens eine Reinitialisierung empfehlen.

Hoi Hoi,

mensch mensch, ich will ja nichts sagen, aber sowas betreibt RootServer... ein ganz klein wenig Ahnung..

Es gibt auch in der Unix Welt div. Backdoors usw. dich geht das also schon was an, da es sich hier um einen Schädling aus der Linux / Unix Welt handelt...

Der Aufwand mit einer Anzeige lohnt sich meiner meinung nach nicht und herunterfahren (oder ins Resque) möchte ich das System nicht, da ich froh bin, endlich mal ein paar mehr Seitenzugriffe zu haben...

und wenn ich sowas les, kommt mir die Galle hoch...
der Server gehört sofort in den Rescue Modus, egal ob du nun Seitenzugriffe hast oder nicht, du stellst damit eine potentielle Gefahr für andere dar. Gut, dass das nicht mein Ausbilder liest, der hätte noch verrücktere Kommentare dazu abgegeben! ;)

Da ich aber nicht nur "schimpfen" will...
Kann mich meinen Vorrednern nur anschließen..
wie gesagt, Server schnellstmöglichst ins Rescue System und dann div. Logfiles sichern und auswerten, was noch übrig ist.
Dann eine Neuinstallation des Server veranlassen und regelmäßig Security Patches, etc. einspielen... ich möchte es an dieser Stelle auch nochmal betonen, ein RootServer ist kein Spielzeug, sondern durch seine Anbindung eine potentielle Waffe des Internets.

Gruß

PG-Computer

ok, überzeugt, Server wird jetzt neu initialisiert...

Was muss ich beim Sichern beachten? Möchte ja nicht den Virus gleich wieder aufs neue System zurückspielen - aber meine files (sind ja alles keine Ausführbaren (ausser .cgi) muss ich natürlich sichern können...?

Ich tue was ich kann um zu lernen... Server war (mit YOU) stets auf dem neuesten Stand - der einzige Fehler war wohl das 777 Verzeichnis!


Gruß
Flat-Jack

Wie oft hatte ich doch hier in den Foren gleich nochmal geschrieben, dass es NIE einen Grund gibt, warum man etwas auf 777 oder Schreibrechte für others setzen sollte?!

Jetzt muss ich Laie in Sachen PHP eine doofe Frage stellen:

Bei manchen Scripten steht da, geben Sie der Datei oder dem Verzeichniss chmod 777.

Reichen denn da 775 Rechte aus, damit diese Scripte einwandfrei laufen oder gibt es unterschiedliche Scripte, die weniger anfällig sind, wenn Dateien für alle freigegeben sind?

Ich hab nämlich jetzt ein bisschen Angst bekommen 8O

Ich bitte die Profis um Aufklärung.

Gruß Pupsi

Nachtrag: Gilt das auch für gekauften Webspace? Was ist dort anders als auf einem Rootserver mit aktuellen Sicherheitspatches?

Pupsi wrote:

Wie oft hatte ich doch hier in den Foren gleich nochmal geschrieben, dass es NIE einen Grund gibt, warum man etwas auf 777 oder Schreibrechte für others setzen sollte?!

Jetzt muss ich Laie in Sachen PHP eine doofe Frage stellen:

Bei manchen Scripten steht da, geben Sie der Datei oder dem Verzeichniss chmod 777.

Das frage ich mich auch gerade!? Zum Beispiel Forenscripte
die für den Avatar-Upload Schreibrechte in einem Ordner brauchen
oder halt sonstige Uploadscripte.

Giffi

Am besten PHP Scripte als CGI unter der jeweiligen UID laufen lassen. Dann hat man dieses Problem schonmal nicht.

ein chroot für den webserver ist hier auch sehr zu empfehlen.

besondere vorsicht gilt außerdem bei den ganzen php-CMS'en, besonders phpnuke, dort sollte man immer sehr sorgfältig permissions checken, updates und fixes einspielen und bei der moduleauswahl auch nochmal nen blick über bugtraq wandern lassen.

Auch ein chroot allein wiegt mehr in Sicherheit, als das es etwas nutzt, da mittlerweile selbst schon Scriptkiddies Mittel und Wege kennen, aus dem chroot auszubrechen ... in Verbindung mit GRSecurity und geeigneter Konfiuration des Patchs sieht die Sache allerdings schon wieder ganz anders aus.

hmm welche foren soft hast du den laufen ?
und wie briegt man den apache dazu ein prog zu ziehen das muß doch ein bug in dem foren script sein oder ?

Bei manchen Scripten steht da, geben Sie der Datei oder dem Verzeichniss chmod 777.

Das Thema hatten wir schon öfters, z.B. in http://www.rootforum.org/forum/viewtopi ... =777#83309

Wenn ich sowas bei einem Skript lesen würde, wäre mein erster Schritt, das Skript in die Tonne zu treten.

Moin,

PG-Computer wrote: ...
wie gesagt, Server schnellstmöglichst ins Rescue System und dann div. Logfiles sichern und auswerten, was noch übrig ist.
...

wozu Logfiles sichern? Die sind schliesslich das Erste, was ich faken/löschen würde, wenn ich illegalerweise in ein System eingedrungen wäre...
Ansonsten ACK.

Gruss,
Markus

Joe User wrote:Moin,

PG-Computer wrote: ...
wie gesagt, Server schnellstmöglichst ins Rescue System und dann div. Logfiles sichern und auswerten, was noch übrig ist.
...

wozu Logfiles sichern? Die sind schliesslich das Erste, was ich faken/löschen würde, wenn ich illegalerweise in ein System eingedrungen wäre...
Ansonsten ACK.

Gruss,
Markus

Du glaubst garnicht, wie blöd manche SKs sind ... *lol*

Hallo Ihr C14L-nervös-macher! ;)

Ich bin mir zwar ziemlich sicher, keine 777 directories zu haben, aber ich würd das ja lieber gern mal checken. Nur falls jemand das grad aus dem Kopf hier hinzaubern kann: wie kann ich denn das gesamte "www"-verzeichnis rekursiv nach Dateien mit 777-permissions durchsuchen?

Was ich allerdings nicht ganz verstehe: Kann man den Apachen wirklich dazu bringen, eine Datei von irgentwo runterzuladen oder war es irgentein script und ich habs nur überlesen? Und wieso taucht das Ding im Error-Log auf?

find /path/to/www -perm 777

Klasse. Danke dir Firefox747! :)

Moin,

C14L wrote: wie kann ich denn das gesamte "www"-verzeichnis rekursiv nach Dateien mit 777-permissions durchsuchen?

cd /path/to/www && ls -alhR | grep rwxrwxrwx | less

C14L wrote: Was ich allerdings nicht ganz verstehe: Kann man den Apachen wirklich dazu bringen, eine Datei von irgentwo runterzuladen oder war es irgentein script und ich habs nur überlesen?

Hint1: mod_proxy
Hint2: mod_$SCRIPTINTERPRETER
Hint3: buggy Scripte ala phpNuke
Hint4: unzureichendes Sicherheitskonzept
Hint5: bugtraq abonnieren und lesen
Hint6: ...

C14L wrote: Und wieso taucht das Ding im Error-Log auf?

ScriptKiddie am Werk...

HTH,
Markus

giffi wrote: Das frage ich mich auch gerade!? Zum Beispiel Forenscripte
die für den Avatar-Upload Schreibrechte in einem Ordner brauchen
oder halt sonstige Uploadscripte.

Giffi

Halloa,

-->Wie muss ich nun vorgehen wenn zB mein Forum einen 777 Ordner benötigt (Upload von Avatar)?

-> Habe noch kollegen auf dem Server, was ist wenn die einen Ordner mit den Rechten 777 erstellen? Kann man dies irgendwie überblicken, bzw. schützen?

Danke für eure Infos

Zimtstern

-->Wie muss ich nun vorgehen wenn zB mein Forum einen 777 Ordner benötigt (Upload von Avatar)?

Wie schon desöfteren hier gesagt : ein vernünftiges Forum suchen, oder so etwas sinnfreies weglassen