Archiv verlassen und diese Seite im Standarddesign anzeigen : Rootserver gesperrt
Hi,
heute morgen ging mein Rootserver auf einmal offline und kam nicht wieder. Eben erhielt ich folgende Antwort auf meine Supportanfrage:
Guten Tag,
der Server wurde heute aufgrund einer Dringlichkeits-Anfrage vom BSI (Bundesamt für Sicherheit in der Informationstechnik) gesperrt.
Sie hosten auf Ihrem Server Malware - siehe hierzu auch die Ihnen weitergeleitete Mail vom heutigen Tage.
http://123.123.123.123/gift.jpg.exe ist die betroffene URL.
Die Freigabe des Servers kann erst wieder erfolgen, wenn der Wurm/Trojaner/Virus entfernt ist (bitte KVMoverIP beantragen!) und alle in der Mail genannten Kontaktpersonen:
From: auscert@auscert.org.au
To: info@meinprovider.de
Cc: auscert@auscert.org.au, emailfraud@apacs.org.uk, dfncert@cert.dfn.de, certbund@bsi.bund.de
informiert worden sind.
Offensichtlich wurde mein Server gehackt und ein Dialer (Dialer sind doch Malware?) hochgeladen.
Muss ich jetzt mit irgendwelchen Konsequenzen rechnen?
Hat jemand zufälligerweise Erfahrung mit solchen Problemen?
:(
Oh man!!!!! Kann es sein, dass sich derartige Meldungen in letzter Zeit hier im Forum häufen? (Bewusst keine Antwort auf die Frage gegeben)
Hallo,
tja, wer nicht hören will, muß halt zahlen ...
Gruß
hp_tux
Hallo,
tja, wer nicht hören will, muß halt zahlen ...
Gruß
hp_tux
Toller Spruch, der mir was genau sagen soll?
Hallo,
Toller Spruch, der mir was genau sagen soll?
wenn man keine Ahnung von der Materie hat, sollte man halt keinen Root-Server betreiben.
Gruß
hp_tux
P.S. Wie es aussieht, hast Du sogar noch verdammtes Glück gehabt, daß es nur Malware ist, was auf Deinem Server gefunden wurde!
Muss ich jetzt mit irgendwelchen Konsequenzen rechnen?
Hat jemand zufälligerweise Erfahrung mit solchen Problemen?Wäre schön wenn Du für Dich selbst Konsequenzen ziehst, bevor Du den Server neu aufsetzt. Also Dich in Punkto Sicherheit schlau machst.
Was auf Dich zukommen kann: Je nachdem, was über Deinen Server verteilt worden ist strafrechtliche Ahndung und zivilrechtliche Schadensersatzansprüche. Das hängt davon ab, welchen Verfolgungseifer die Geschädigten an den Tag legen. Das musst Du jetzt aber eh auf Dich zukommen lassen, für die Vergangenheit lässt sich nichts mehr ändern.
Um so mehr solltest Du vor dem Neuaufsetzen in Dich gehen. Und sichere vorher die massgeblichen Logs, vllt. lässt sich ja ermitteln, wer sich auf Deinem Server niedergelassen hat, dann kannst Du Dich Deinerseits an den Schädiger halten. Der sitzt zwar wahrscheinlich auf den Niederländischen Antillen, aber vllt. kommst Du ja an ihn ran...
Und ja: Hier gibt es üblicherweise kein Mitleid für so ein Vorkommnis. Dafür bekommen wir alle hier zuviel Spam und Malware von so Schleudern wie Deinem Server...
Kreol
Kündige am besten sofort den Server, schau dich nach einem Anwalt um und lies dir DANN das folgende Posting (http://www.linuxforen.de/forums/showthread.php?t=178731) von Tomek durch!
Und ja: Hier gibt es üblicherweise kein Mitleid für so ein Vorkommnis. Dafür bekommen wir alle hier zuviel Spam und Malware von so Schleudern wie Deinem Server...
Ich krieg selber täglich 500 Spam-Mails...
Ich hatte den Server von der Software her eigentlich immer recht aktuell gehalten und den SSH-Zugriff auch mit einem Schlüssel versehen.
Auf dem Server habe ich nur ein einziges Programm installiert und zwar nen TS2-Server. Ansonsten wurde nur der Apacheserver und die mySQL-Datenbank genutzt.
Ob der Server gut vorkonfiguriert war kann ich nicht beurteilen. Ich habe zusammen mit einem jahrenlangen Linux-Admin diverse Änderung bzgl. der Sicherheit gemacht. Diese waren anscheinend nicht ausreichend...
Naja, der Server sollte sowieso nächste Woche weg, weil er mir für den geringen Umfang den ich genutzt habe zu teuer ist.
Von dem geplanten rootDS-Server werde ich wohl Abstand nehmen und mir ein passendes managed Hosting Angebot suchen.
Hoffentlich endet die Gesichte glimpflich...
Jo selbst schuld.
Aber mal so als kleiner Tip schau dir die Mail doch nochmal ganz genau an. Irgendwie scheinst du es ja nicht so ganz verstanden zu haben
Bevor du die URL zum BSI nicht findest, hier (http://www.bsi.bund.de/) ist er; kannst dir ja auch gerne mal den Wikipedia-Eintrag (http://de.wikipedia.org/wiki/Bundesamt_f%C3%BCr_Sicherheit_in_der_Informationst echnik) dazu durchlesen.
Windoofsklicker
23.02.07, 06:58
Ich finde, Ihr solltet alle mal aufhören mit Steinen zu schmeißen.
Jedem der einen Server betreibt, kann sowas passieren.
Ohne zu wissen über welchen Dienst oder Weg die Kiste geknackt wurde wird hier wieder fröhlich vor sich hin gebasht.
Bevor also die übliche "Wenn du zu blöd bist, dann lass es"-Leier kommt, solltet Ihr erstmal ein paar mehr Infos haben.
my2cents...
ein bisschen werfen darf man schon: Allein die Tatsache, dass dort was passiert ist lässt darauf schliessen, dass irgendwas nicht entsprechend abgesichert war.
Das kann eine Drittsoftware sein (fremde Scripte, die Löcher enthalten), ein nicht gepatchtes Sicherheitsloch, evtl. nicht vertrauenswürdige User auf dem System, ... - Möglichkeiten gibt es viele.
Von dem her, was der TE geschrieben hat (SSH, Apache, MySQL) würde ich mal auf eine unsaubere Webanwendung tippen (reine Vermutung) - und da darf man durchaus den mahnenden Finger heben...
Windoofsklicker
23.02.07, 07:25
Klar, aber lies dir den Thread mal durch.
Bevor der Kollege mit Apache/MySQL um die Ecke kam, wurde schon fröhlich eingedroschen.
So gesehen nicht nett, aber es ändert nichts an der Tatsache an sich...
Und seien wir mal ehrlich: _gedacht_ hat doch jeder das gleiche beim Lesen des ersten Postings im Thread?
Seit Server billiger und einfacher zu bekommen sind wie Handys oder Zeitschriften-Abos kommen Meldungen aus der Klientel der "üblichen Verdächtigen" recht oft - und da man hier meist nur aus dem Anmeldedatum und der Postingzahl nicht wirklich erkennen kann ob da jetzt Ober-Guru oder Super-Dau dran sitzt - "gehen wir mal vom schlimmsten aus..."
Windoofsklicker
23.02.07, 07:35
Genau... wenn mir jemand erzählt:"Ich hatte einen Autounfall.", dann falle ich auch immer gleich über Ihn her und sage Ihm, dass er keine Ahnung vom Autofahren hat und gefälligst erstmal einen Führerschein machen soll.
Aber wir sollten nicht den Thread kapern. Das fällt eher in die, im Forum bereits geführte, Diskussion der Art und Weise des Umgangs hier.
Um bei dem Beispiel zu bleiben: Wenn aber einer einen Autounfall hat kann ich immerhin davon ausgehen, dass er einen Führerschein besitzt und prinzipiell weiss, was er tut (Regeln im Straßenverkehr, grobes technisches Hintergrundwissen).
Bei Server-Betreibern bin ich mir da nicht so sicher...
_Meine_ Erfahrung hier ist übrigens leider, dass - so man an einen DAU kommt - die Erkenntnisresistenz der Leute sehr hoch ist und sie oftmals erst durch deutliche Worte zumindest mal dazu gebracht werden konnten, über ihre Qualifikation nachzudenken - daher bin ich auch hier ein Freund deutlicher Worte (wenn ich auch meist versuche, sie freundlich rüber zu bringen)
oracle2025
23.02.07, 08:11
Ist euch eigentlich bewußt, dass nur weil eine fremde Datei auf dem Server liegt der noch lange nicht gekapert worden sein muss. In der Regel reicht da ein laxes PHP Script aus, um Dateien upzuloaden, und schon haben wir den Salat. Das kann jedem passieren, besonders wenn er anderer Leute PHP-Skripts hostet. Und um Spam zu versenden reicht in der Regel auch jedes Gästebuch das die Email-Addresse nicht ausreichend prüft.
Wenn man will kann man ja jedes PHP-Skript Zeile für Zeile durchgehen und auf Lücken prüfen, ich bezweifle aber ob man das von jedem verlangen kann.
Soweit richtig.
Nur - wer sagt Dir, dass nur diese eine Datei geändert wurde?
Es mag vielleicht ein bisschen paranoid sein - aber wenn auch nur eine Datei auf dem Server auftaucht, die da definitiv nichts zu suchen hat - so ist das System an sich nicht mehr vertrauenswürdig. Von daher ist der Ratschlag, neu zu installieren durchaus berechtigt.
Dass man parallel auch herausfinden sollte, wie denn die Datei da nun gelandet ist und dann versuchen sollte, diese Lücke zu schliessen ist eigentlich ja selbstverständlich...
Die Verwendung von Dritt-Software ist natürlich immer so eine Sache - ob man nun jede Datei durch ein Code-Audit jagt, bevor man sie online stellt? Kann man machen, kenne ich auch so von einer Firma, wo ich mal war... Für den Normalanwender sicherlich nicht machbar - alleine wegen den evtl. nicht vorhandenen Programmierkenntnissen... wenn man das ins Extreme treiben will dürfte man ja nicht mal ein BS installieren ohne Audit...
Mal schauen ob sich der Vorgang nachher anhand der Logs nachvollziehen lässt.
Ich werde wohl nächste Woche auf einen managed rootDS umsteigen, so das mir solche Probleme hoffentlich in Zukunft erspart bleiben :rolleyes:
Ist denn all Deine Software aktuell? Insbesondere die PHP-Skripte? Welche Skripte setzt Du ein?
Auf dem Server läuft 2x das Burning Board 2 (aktuellste Version). Und 1x das Burning Board Lite (aktuellste Version).
Ansonsten sonsten noch eine Imagegallery (der Name ist mir gerade entfallen).
naja - Managed oder nicht, wenn es über eine Webapplikation reingekommen ist bleibt sowas wieder "an Dir" hängen...
Oder wie weit ist der Server dann gemanaged? Standard ist ja meist nur BS-relevante Elemente...
Die managed Erweiterung ersetzt vereinfacht ausgedrückt das eigene technische
Personal. In der günstigen monatlichen Pauschale sind folgende Leistungen enthalten:
- Pflege des Systems inklusive einspielen wichtiger Systemupdates
- Kostenlose Reboots 24/7/365
- Problemlösung mit Scripten und Programmen
- Ausführung von Installationen ( sofern diese vom OS unterstützt werden)
Ist allerdings die Frage ob sich das für 18 € im Monat lohnt, oder ich die BS-Updates nicht besser selber einspielen kann.
Wenn es an irgendwelche PHP-Skripten liegt kann ich es nicht ändern. Das nötige Fachwissen dafür hätte ich zwar, aber sämtliche Skripte auf Hintertürchen zu untersuchen ist mir ehrlichgesagt zu aufwendig.
@HyperSurf:
Auch wenn einige vielleicht gleich zu sehr draufgehauen haben, finde ich, ein Fuenkchen Wahrheit ist da wohl dran. Du hast wenigstens mit einem Admin zusammen eine Haertung vorgenommen, aber damit ist es leider nicht getan. Auch das aufspielen von Sicherheitsupdates allein macht es nicht. Wenn du den Server betreust, musst du selber umfassende Unix-Kenntnisse haben. Mal einige Stichpunkte:
-SSH: Schon fast Thema Nr.1. Ist der root-Zugang abgeschaltet gewesen? Ist das Passwort wirklich sicher? Ist sichergestellt, das User die sich nicht anmelden muessen (z.B. technische User) keine Login-Shell haben?
-Entfernter Syslog-Daemon: Wenn ein Hacker erstmal drin ist und er wirklich gut ist, wird er all seine Spuren verwischen. Wenn du nochjemanden kennst, der auch einen Server hat, koennte man sich wechselseitig die Syslogd-Meldungen schicken. Somit kann er nichts mehr verwischen. Besonders wichtig sind z.B. auch Meldungen aus /var/log/wtmp.
-Anwendungen, die moeglicherweise Loecher haben, kann man mit zusaetzlichen Schutzmechanismen wie SELinux oder AppArmor sicherer machen.
-Bei besonders kritischen Sachen kann man ueber process accounting nachdenken.
-Es gibt auch Verfahren, mit denen sich Aenderungen in Dateien, z.B. mit MD5-Summen, aufspueren lassen. Schon recht hardcore, aber wirksam.
-SUID bits sollten ggf. entfernt werden. Auch sollten fuer den unpriviligierten Login-User einige Programme abgeknipst werden. Dazu zahlen z.B. top, ps, w, who, netstat, last und alles, womit er feststellen koennte, ob und wann jemand angemeldet ist und welche Programme laufen.
Solltest du von alledem nur Bahnhof verstanden haben, rate ich ernsthaft, einen managed Server zu waehlen. Selbst wenn es diesmal noch glimpflich ausgeht, kann es beim naechsten mal ganz anders aussehen. Ich sage es jedes mal, aber niemand will es wissen.
Gruss Stephan
PS: Noch ne Idee: Warum sich nicht von der Buechse ne Mail schicken lassen, sobald sich jemand anmeldet?
Hallo,
-Entfernter Syslog-Daemon: Wenn ein Hacker erstmal drin ist und er wirklich gut ist, wird er all seine Spuren verwischen. Wenn du nochjemanden kennst, der auch einen Server hat, koennte man sich wechselseitig die Syslogd-Meldungen schicken. Somit kann er nichts mehr verwischen. Besonders wichtig sind z.B. auch Meldungen aus /var/log/wtmp.
Man hoert das solche Syslog Server dann einfach geflutet werden, und schwupps hat man
moeglicherweise ein Speicherplatzproblem.
Es ist vielleicht eine gute Idee auf eine Serielle Konsole zu loggen, und Arbeit in Scripte zu
stecken die definierte Zustaende gegen neue Aenderungen checken.
Das macht z.B. Tripwire mit einer Datenbank, nur wenn jemand ueber den, sagen wir mal apache, einbricht und lokal einen Root-Exploit einspielt, kann er auch wieder die Datenbank updaten usw. usw.
Fuer die Checkliste: sichere Sudoers Konfiguration, Mailen und Parsen der Logs, Public-Key Logins checken, jaja :ugly:
... deswegen sollte man die DB ja auch auf einem RO-Medium haben...
... deswegen sollte man die DB ja auch auf einem RO-Medium haben...
Ja, das hatte ich noch vergessen. :rolleyes:
Wäre es da eigentlich möglich die Daten im RAM zu fälschen? Das Checkprogramm sagt ok. (manipuliert), die CD/fd0 etc. bleibt unangetastet.
... und deswegen sollte man solche Tests von einem vertrauenswürdigen System aus laufen lassen - also z.B. einer Live-CD (Super-Paranoid-Mode On) oder halt nur von CD aus laufen lassen mit einer statisch kompilierten Version...
Das ein tripwire vom lokalen System von der lokalen Platte aus nicht unbedingt ein non-plus-ultra an Vertrauenswürdigkeit darstellt - klar.
In meinem Fall war doch jetzt aber die Vertrauenswürdigkeit des Grund-
systems egal.
Wieso wird der Server denn gesperrt, wenn der Malware nur passiv anbietet? :confused:
Es ist doch niemand gezwungen, dort downzuloaden und erst recht nicht, das zu installieren! Die Begründung für die Sperrung ist doch an den Haaren herbeigezogen; über den Iloveyou-Virus, den ich seit vielen Jahren auf meinen FTP-Servern habe, hat sich noch nie jemand beschwert.
Und exe-Dateien funktionieren sowieso nicht unter den meisten Betriebssystemen (Linux, MacOS, HP-UX, FreeBSD, OpenBSD, ...).
Wo wird der betreffende Rootserver denn gehostet?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.