[S4Y] Server 2. mal gehackt und 0 Hilfe

Wie sicher Deine Skripte sind, mag und will hier niemand von uns beurteilen. Deswegen sind wir ja auf der Suche nach dem Einstiegsloch für den "Hacker". Die access_logs könnte man z.B. nach dubiosen Inhalten von GET und POST Variablen. Wichtiger wäre übrigens, bevor man damit anfängt, zu wissen, welcher Prozess den DDoS ausgeführt hat. Von da kommen wir gleich viel weiter.

Dann halt zum dritten Mal...
 
Wenn der Server ausläuft, kündigen.

Das sowieso. Kündigungsschreiben ist eben fertig geworden, nach der Aktion will ich nur noch weg da. Aber erst bei Vertragsende. Bin gespannt, ob sie mir auch vorher Kündigen um mir meinen Server nicht nach Hause zu schicken :rolleyes:

edit: Soll ich alle access_logs posten ??? oO
Was das genau ausgeführt hat weiss ich nicht, ich ging, wie oben beschrieben, vom Apache aus.
 
Bin gespannt, ob sie mir auch vorher Kündigen um mir meinen Server nicht nach Hause zu schicken :rolleyes:

edit: Soll ich alle access_logs posten ??? oO

1. Gab einen ähnlichen Fall, aber da sei freundlich und optimistisch, denke schon, dass du den bekommen wirst, wenn der Server nicht nochmal gehackt wird.

2. Ja, Auszüge aus den Logs sind interessant, um die Fehlerquelle zu lokalisieren.
 
zum Beispiel:

Code:
# grep -i [I]GET[/I] /var/log/apache2/access.log

bzw.

Code:
# grep -i [I]POST[/I] /var/log/apache2/access.log

Den Pfad zur access.log musst du evtl. noch selbst anpassen. Hoffe grep geht noch.
 
Last edited by a moderator:
Ja, wenn ich mich mit Hacks nicht auskenne kann ich auch nicht nach "dubiosen" sachen suchen. ICH HABE MIT HACKS KEINE AHNUNG auch nicht wie man sie startet oder sonst was. Ich wiederhole mich da mehrfach, dass ich keine Ahnung habe, wonach ich genau suchen müsste.
Das ist das erste mal das ich vor so einem Problem stehe und tut mir leid, dass ich nicht weiss wonach ich suchen muss, ich stand vor diesem Problem nie und habe daher keine Erfahrung was ich suchen muss.

Für euch ist es ja vielleicht das normalste der Welt sowas zu finden, aber genau aus diesem Grund bin ich hier, damit mir Menschen, die Ahnung haben helfen.

@phor
ja grep geht noch, aber das Problem ist, dass ich nicht weiss, was als "böses" get/post zu sehen wäre.
 
Last edited by a moderator:
Ich gehe Dich an? Auch hier verkennst Du leider vollkommen die Situation als solches und Deine Position in selbiger. Was ich tue ist nach Informationen zu fragen.

Wenn Du Probleme mit der Administration Deines Servers hast, können wir da erstmal wenig dran drehen. Du kannst mir gewiss vieles unterstellen, aber nicht, dass ich unfreundlich oder gar persönlich unsachlich wurde. Ich stelle lediglich Fragen, die uns helfen (sollen) den Sachverhalt zu klären.

Deine "Hommage" an S4Y hilft uns da zum einen nicht weiter und ist zum anderen auch noch gänzlich falsch. Ferner relativierst Du Deine Aussagen der sicheren Programmierung selbst, in dem Du konstatierst, dass Du von etwaigen Hackertechniken keine Ahnung hast.

Wenn Du gar keine Ahnung hast, was dubios sein könnte musst Du einen Admin bezahlen, der Dir das System zumindest neu initialisiert und die Fehlerquelle evtl. lokalisieren kann. Du wirst doch gewiss einsehen, dass wir ohne Kenntnis der Sachlage gar nicht helfen können.

Beste Grüße,
marneus
 
Dann ist heute der erste Tag vom Rest Deines Lebens!

Als Rootserveradmin MUSS man sich mit der Sicherheit des eigenen Servers auseinandersetzen! :eek: Bedauerlicherweise macht das keiner der Möchtegernadmins, insofern ist das (deutsche) Internet voll von leicht hackbaren Servern.

Hast Du Dir die Ausgaben der beiden Befehle überhaupt schon mal angesehen? Verdächtig wären Passagen, in denen ein Skript auf Deinem Rechner versucht, Sachen von externen Websites nachzuladen und potentiell in Verzeichnisse zu schreiben, auf die der Apache eigentlich überhaupt keinen Zugriff haben sollte.
 
In den Logs ist leider nichts Auffälliges zu finden. Vllt. reichen sie nicht weit genug zurück, vllt. hat der Hacker sie aber auch erfolgreich modifiziert. Die Möglichkeiten sind sowas von vielfältig, dass wir wahrscheinlich keine Möglichkeit haben hier zu einer Lösung zu kommen.

Fakt ist, dass Du auf jeden Fall Deinen Server neu initialisieren musst. Daran geht kein Weg dran vorbei. Dann solltest Du alle Applikationen auf den neuesten Stand bringen, evtl. (oder gewiss) vorher auch gleich auf Etch (Debian 4.0) upgraden.

Damit ist das Problem nur leider noch nicht gelöst. Ein Schritt wäre mod_security zu installieren und sich anzuschauen, was dort so an dubiosen Dingen getrieben wird.

Beste Grüße,
marneus
 
Ich setze mich mit allem immer gern auseinander, nur wenn ich keinerlei Hilfe bei hab, wird es schwer. Ich lese schon einiges an Büchern, jedoch habe ich persönlich große Probleme mit Buchbeispielen.

Konnte damals als ich mit PHP angefangen hab, mit dem Buch keine DB-Connection ausführen, bis ich mir das live in ein paar Skripten angesehen habe. Ich weiss nicht woran es liegt, aber "Fachbücher" helfen mir weniger als direkte Beispiele.

Auch ist es immer problematisch, wenn man das erste mal mit Konfrontiert ist und man nicht weiterweiss und niemanden kennt, der Ahnung hat und mal raufschaut und vielleicht gleich nach 1-2 Befehlen weiss, was los ist. Soweit bin ich noch nicht, da ich nie Opfer eines solchen Angriffs wurde. Ausser von Scripten die z. B. versuchten zu Bruteforcen.

Ich habe mir die Ausgaben angesehen, aber mehr als meine eigenen Zugriffe auf den phpmyadmin, dem Zugriff eines Kumpels auf sein pop3 und 2-3 andere User konnte ich nicht erkennen.

edit:
@Marneus
Würde ich sofort gern machen.
Jedoch habe ich allein nur mit Debian3.1 und Suse Erfahrung und weiss nicht, in wiefern dann z. B. meine Aktuelle Confixx auf dem neuen System (Debian4) nutzen lässt. Da ich 10 Webs habe und ca. 100GB an Daten die ich auch wieder einspielen muss.
 
Last edited by a moderator:
Zeitlich kannst du das Ganze nicht einordnen? Durch Infos von S4Y? Sind ja teils tagelange Löcher in den Logs.
 
Zeitlich kannst du das Ganze nicht einordnen? Durch Infos von S4Y? Sind ja teils tagelange Löcher in den Logs.

Das ist nur der Ausschnitt durch grep post und grep get.
Ich kann gerne die archivierten Logs zugänglich machen, kann diese aber nur als tar.gz anbieten da gzip hinüber ist.

Zeitlich wüsste ich maximal 6.12. 22:XX
Ab da, wenn ich mich nicht irre, funktionierte der Mailserver nicht mehr und lässt keine Mails durch.
Aber als Lösung hiess es bei S4Y es war ein Netzteil kaputt.
 
Gut, dass es jetzt hier wieder sachlicher geworden ist -- ich wollte gerade schon vorschlagen, dass jetzt alle Beteiligten für eine halbe Stunde den Rechner aus machen (der kompromittierte Rechner läuft ja ohnehin hoffentlich im Rescue-Modus) und durch den Regen spazieren gehen. Bei einem Einbruch hilft es wirklich, einen kühlen Kopf zu bewahren, dann erkennt man die Ursachen deutlich besser ;)

Beim groben überfliegen der Logauszüge habe ich jetzt verdächtiges entdeckt. Allerdings können injections und XSS-Angriffe auch über normale PHP-Seitenzugriffe erfolgen, die jetzt nicht bei den GET und POST-Zeilen dabei sind. Schau Dir die Logfiles noch mal in Ruhe an.

Viele Grüße,
LinuxAdmin
 
Beim groben überfliegen der Logauszüge habe ich jetzt verdächtiges entdeckt. Allerdings können injections und XSS-Angriffe auch über normale PHP-Seitenzugriffe erfolgen, die jetzt nicht bei den GET und POST-Zeilen dabei sind. Schau Dir die Logfiles noch mal in Ruhe an.

Viele Grüße,
LinuxAdmin

Wie gesagt, ausser bei den von mir gescripteten wo ich weiss, was kann und was nicht, kann ich mir genauso gut ein Spanischwörterbuch ansehen. Ich kenne keine bösen Zeilen oder sowas :(:o

Ältere Files kann ich mir eh nicht ansehen, da die getart sind und somit für mich nicht mehr erreichbar.

Kann der netstat auszug hier eventuell helfen ?

alpha591:~# netstat --numeric-hosts --numeric-ports -p -a -o
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name Timer
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 2802/mysqld aus (0.00/0/0)
tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN 2543/spamd.pid aus (0.00/0/0)
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 3016/proftpd: (acce aus (0.00/0/0)
tcp 0 0 85.25.130.61:53 0.0.0.0:* LISTEN 2536/named aus (0.00/0/0)
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 2536/named aus (0.00/0/0)
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2712/exim4 aus (0.00/0/0)
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 2536/named aus (0.00/0/0)
tcp 0 0 85.25.130.61:25 76.7.140.187:29328 VERBUNDEN 30693/exim4 aus (0.00/0/0)
tcp 0 1 85.25.130.61:36271 76.7.140.187:113 SYN_SENT 30693/exim4 ein (7,78/2/0)
tcp6 0 0 :::993 :::* LISTEN 2627/couriertcpd aus (0.00/0/0)
tcp6 0 0 :::995 :::* LISTEN 2647/couriertcpd aus (0.00/0/0)
tcp6 0 0 :::110 :::* LISTEN 2635/couriertcpd aus (0.00/0/0)
tcp6 0 0 :::143 :::* LISTEN 2609/couriertcpd aus (0.00/0/0)
tcp6 0 0 :::80 :::* LISTEN 31170/apache2 aus (0.00/0/0)
tcp6 0 0 :::22 :::* LISTEN 2998/sshd aus (0.00/0/0)
tcp6 0 0 :::25 :::* LISTEN 2712/exim4 aus (0.00/0/0)
tcp6 0 0 ::1:953 :::* LISTEN 2536/named aus (0.00/0/0)
tcp6 0 0 :::443 :::* LISTEN 31170/apache2 aus (0.00/0/0)
tcp6 0 0 ::ffff:85.25.130.61:22 ::ffff:84.58.213.:52918 VERBUNDEN 25178/sshd: root@no keepalive (1883,32/0/0)
tcp6 0 820 ::ffff:85.25.130.61:22 ::ffff:84.58.213.:51667 VERBUNDEN 23311/0 ein (0,46/0/0)
tcp6 0 0 ::ffff:85.25.130.61:110 ::ffff:84.58.213.:55319 TIME_WAIT - timewait (51,55/0/0)
tcp6 0 0 ::ffff:85.25.130.61:22 ::ffff:84.58.213.:54073 VERBUNDEN 27100/sshd: root@no keepalive (4588,41/0/0)
tcp6 0 0 ::ffff:85.25.130.61:80 ::ffff:84.58.213.:55120 VERBUNDEN 27123/apache2 keepalive (6774,91/0/0)
tcp6 0 0 ::ffff:85.25.130.61:80 ::ffff:84.136.68.1:1678 TIME_WAIT - timewait (40,34/0/0)
tcp6 0 0 ::ffff:85.25.130.61:80 ::ffff:84.136.68.1:1688 VERBUNDEN 25554/apache2 keepalive (7190,47/0/0)
tcp6 0 0 ::ffff:85.25.130.61:80 ::ffff:84.136.68.1:1689 VERBUNDEN 29427/apache2 keepalive (7191,01/0/0)
tcp6 0 16060 ::ffff:85.25.130.61:80 ::ffff:194.165.13:28076 VERBUNDEN 29446/apache2 ein (1,06/0/0)
udp 0 0 0.0.0.0:32768 0.0.0.0:* 2536/named aus (0.00/0/0)
udp 0 0 85.25.130.61:53 0.0.0.0:* 2536/named aus (0.00/0/0)
udp 0 0 127.0.0.1:53 0.0.0.0:* 2536/named aus (0.00/0/0)
udp6 0 0 :::32769 :::* 2536/named aus (0.00/0/0)
Aktive Sockets in der UNIX Domäne (Server und stehende Verbindungen)
Proto RefZäh Flaggen Typ Zustand I-Node PID/Program name Pfad
unix 12 [ ] DGRAM 2530 2525/syslogd /dev/log
unix 2 [ ACC ] STREAM HÃRT 2633 2556/clamd /var/run/clamav/clamd.ctl
unix 2 [ ACC ] STREAM HÃRT 2719 2603/authdaemond.pl /var/run/courier/authdaemon/socket.tmp
unix 2 [ ACC ] STREAM HÃRT 2931 2802/mysqld /var/run/mysqld/mysqld.sock
unix 3 [ ] STREAM VERBUNDEN 673902 27100/sshd: root@no
unix 3 [ ] STREAM VERBUNDEN 673901 27104/-bash
unix 3 [ ] STREAM VERBUNDEN 673900 27100/sshd: root@no
unix 3 [ ] STREAM VERBUNDEN 673899 27104/-bash
unix 3 [ ] STREAM VERBUNDEN 668579 25178/sshd: root@no
unix 3 [ ] STREAM VERBUNDEN 668578 25200/sftp-server
unix 3 [ ] STREAM VERBUNDEN 668577 25178/sshd: root@no
unix 3 [ ] STREAM VERBUNDEN 668576 25200/sftp-server
unix 2 [ ] STREAM VERBUNDEN 16502 17226/rm
unix 2 [ ] DGRAM 16498 16913/CRON
unix 2 [ ] DGRAM 2939 2803/logger
unix 2 [ ] DGRAM 2780 2650/courierlogger
unix 2 [ ] DGRAM 2779 2651/courierlogger
unix 2 [ ] DGRAM 2745 2629/courierlogger
unix 2 [ ] DGRAM 2725 2616/courierlogger
unix 2 [ ] DGRAM 2706 2602/courierlogger
unix 2 [ ] DGRAM 2577 2543/spamd.pid
unix 2 [ ] DGRAM 2553 2536/named
unix 2 [ ] DGRAM 2542 2528/klogd

edit 2: noch mal als jpg angehangen, sollte übersichtlicher sein.
 

Attachments

  • putty.jpg
    putty.jpg
    194.7 KB · Views: 103
Last edited by a moderator:
Hallo!

1) Nur um das mal kurz zu klären. Server4you stellt dir die Hardware deine Servers zur verfügung. Jegliche vorinstallierte Software gehört nicht zum lieferumfang. Die Confixx Lizenz ist eine nette Zugabe allerdings an die OS Templates von Server4you gebunden. Es gibt genug Anbieter für Server bei dennen du keine Zugaben bekommst.

2) Wie äußert sich der "Hack"?
Das der Apache manchmal viel Load verursacht ist nichts neues.
Hast du vieleicht beim Basteln in der Console das Binary von "ls" gelöscht?

3) Eine neuinstalltion wird dir bestimmt helfen. Achte darauf dein System aktuell zu halten. Hardwarefirewalls sind bei der von dir geschilderten Problematik unnötig.

4) Es gibt viele Managed Rootserver zu guten Preisen. Wäre wohl eine Idee für dich.
 
Hallo zusammen

Ich muß mal noch was loswerden zum Thema rkhunter.
Hier ist meiner Meinung nach etwas völlig untergegangen. Wer es noch nicht weiß, wenn man sich den rkhunter neu installiert, natürlich auf einem 100%ig sauberen System, muß man initial die Datenbank erstellen, gegen die rkhunter in Zukunft die Systembinaries vergleicht.

Auf dem gehackten Server wurde das nicht gemacht und jetzt nützt es (leider) nichts mehr. Da diese Datenbank nicht erstellt wurde, hat rkhunter keinerlei Grundlage für einen Vergleich der aktuell vorhandenen Binaries (von. z.B. ls, df, top etc.). Das führt eine Aussage a la 'rkhunter hat nichts gefunden, das ist also nicht so schlimm' ad absurdum.

Der entsprechende Hinweis ist auch recht ausführlich in der geposteten rkhunter Logdatei zu finden:

[01:27:21] The file of stored file properties (rkhunter.dat) does not exist, and so must be created. To do this type in 'rkhunter --propupd'.
[01:27:21]
[01:27:21] Warning: WARNING! It is the users responsibility to ensure that when the '--propupd' option
is used, all the files on their system are known to be genuine, and installed from a
reliable source. The rkhunter '--check' option will compare the current file properties
against previously stored values, and report if any values differ. However, rkhunter
cannot determine what has caused the change, that is for the user to do.

Ich denke diese Meldung ist eindeutig genug.

Jetzt erst recht: Neuinstallation, da keinerlei Alternative.
 
Hallo!

2) Wie äußert sich der "Hack"?
Das der Apache manchmal viel Load verursacht ist nichts neues.
Hast du vieleicht beim Basteln in der Console das Binary von "ls" gelöscht?
Ich bin vielleicht nicht der schlaueste, aber ich weiss mich in einem Betriebssystem seit Dos 6.0 zu bewegen. Nein habe nicht einfach mal was gelöscht.

Der Hack äussert isch darin, dass z. B. l, gzip, teamspeak und weitere Befehle einfach einen "Speicherzugriffsfehler" verursachen und mein Mailserver alle einkommenden e-Mails mit einem "550 Administrative prohibition" ablehnt.

3) Eine neuinstalltion wird dir bestimmt helfen. Achte darauf dein System aktuell zu halten.
Jetzt wo ich weiss, dass ich statt nur apt-get update vorher apt-get upgrade machen sollte, ist dies weniger ein Problem und wird von mir auch wöchentlich durchgeführt.

@Mario
danke für die Information, das ist mir komplett untergegangen.
Eine Installation werde ich nach dem Backup auch starten, aber ich sehe mich jetzt schon wieder vor einem "neuen" aber veralteten Confixx und DB-Problemen, weil Confixx nicht richtig updated oder wieder eine Lizenz ausgelaufen ist...
Ist bei jeder Neuinstallation das Gleiche.
 
Last edited by a moderator:
@ Bibabu: Ja... Da schreibst Du nix neues, das hatten wir alles schon in den letzten Posts drin.

@ Exportforce:
Ich hab mir mal nochmal alles durchgesehen. Du hast immer noch nicht geschrieben, womit genau Dein Server auffällig geworden ist. Hat Dir S4Y denn hier keinen Hinweis gegeben, im Umfeld Deiner Sperrung? In diesem Thread ist jedenfalls keiner zu finden. Hat der Server gespammt, oder geDDoSed? Waren Phishing Seiten drauf? Bis auf pathetische Anklagen in Richtung S4Y steht hier leider nix Handfestes.
 
Back
Top