Debian/Webserver sicher machen

Hallo liebe Gemeinde,

ich befinde mich zwar zur zeit im Urlaub doch wird man auch da nicht ganz von der Arbeit abgehalten …

Problem ist das eine Webseite auf meinem Root-Server des öfteren Ziel von Code-Injection gewurden ist. Es wurde bisher immer javascript in die index-seiten injiziert welches beim Ausführen Malware herunterläd und den Rechner des Nutzer verseucht. Ich habe schon die Dateirechte aller vom Webserver erreichbaren Dateien soweit es geht eingeschränkt (alle nur lesen, Owner kann zusätzlich schreiben aber keiner hat ausführen), dennoch konnte wieder in die Dateien geschrieben werden …
D.h. für mich das der Angreifer mit den Rechten des Owners (oder gar root?) arbeiten muss. Ich habe aber keine Ahnung wie das möglich sein kann. Webserver (Gruppe: web-data) hat nur lesen daher schließ ich den Apache mal aus das über diesen auf die Dateien geschrieben werden kann. Aber bei hacks ist ja eigentlich alles möglich.

Meine Frage daher an die Linux-Server-Kenner und -Freaks hier ob ihr mir ein paar Tipps geben könnt wie ich meinen Root noch sicherer gegen solche „Attacken“ machen kann? Gibt es neben „rkhunter“ und „chkrootkit“ noch andere Programme die den Server nach bösartiger Software durchsuchen? Ich kann mir momentan das Beschreiben der Dateien nicht anders erklären als das sich ein bösartiker Prozess auf dem Server befindet der mit ausreichend Rechten ausgestattet ist und somit immer wieder die Dateien beschreiben kann?

Freu mich über Tipps und Anregungen!

MfG und gut Schuß
VuuRWerK :wink:

Hi Chris, interessantes Thema! Hab von der Server-Materie nicht so den Durchblick, aber es wird immer empfohlen die jeweils aktuellste PHP-Version einzusetzen, um die Einfallstore, die allein schon durch PHP genutzt werden können, zu schließen.
Oftmals bietet dann fehlerhafter Code von PHP-Programmierern zusätzliche Probleme mitsich.
Ist denn überhaupt sicher, dass die Angriffe über SQL-Injection ausgeführt werden und nicht über eine andere Lücke?

Wie die Sachen in die Dateien auf meinem Server gelangen weiß ich gar nicht, es sind nur Spekulationen da ich mir irgendwie nix anderes vorstellen kann das es daran liegen könnte.

Ich werde zudem mal das Suhosin installieren. Aber irgendwie denk ich noch das ein Prozess auf meinem Server läuft welcher diese Javascript-Sachen in die Dateien schreibt, da auch nen Bekannter dasselbe Problem hatte und dieser Irgendwie einen Prozess ausfindig machte welcher das wohl ausführte, allerdings konnte er mir noch nicht sagen wie der Prozess hieß und ich aber nix auffälliges fand.

Gut Schuß
VuuRWerK :wink:

verdammt ich hab das ja garnicht abgeschickt

Also erstmal solltest du die Quelle des Übels beseitigen, dh deine Webseiten so sicher machen das keine SQL Injection mehr möglich ist.
Sieh nach, unter welchem Benutzer läuft denn dein Apache und die DB?
der Benutzer unter dem der Apache läuft sollte auch nur Schreibrechte auf dem Webverzeichnis haben und wo anders als in dem Verzeichnis sollten auch keine Websachen liegen

Also SQL-Injection kann ich eigentlich ausschließen, da ich ausschließlich mit einem Framework entwickelte Webseiten laufen habe welche aber alle Arten von SQL und XSS verhindern. Ich denke eher das mein Root-Server an sich nicht sicher ist und über etwas anderes der Zugriff gelang.
Ich hatte bspw. einmal einen Flood-Bot welcher sich über einen Bug im TS3-Server auf meinem Server installierte und dann 5 Tage lang 1TB Traffic verursachte und Daten an IRC-Server gespammed hat …

Zur Zeit läuft noch ein ZNC-Bouncer-Server, sonst eben die üblichen Verdächtigen wie Webserver, Datenbank, Mailserver, etc … alles aber gesteuert und verwaltet über Confixx, ich hab da nix manuell dran gemacht. D.h. der Benutzer des Apache ist www-data und vom MySQL-Deamon mysql.

Schreibrechte habe ich wie gesagt schon einmal alle soweit als möglich eingeschränkt. Für Dateien alle nur lesen, der Besitzer zusätzlich noch schreiben (oktal: 644). Verzeichnisse haben lesen und ausführen für alle plus schrieben für den Besitzer (oktal: 755).

Gut Schuß
VuuRWerK :wink:

ok dann mal meine Tipps
Sieh nach ob ein sicheres Root pw gesetzt ist
Verbiete den Root Login
Versuche ob du Bouncer abschalten kann, die sind oft buggy :wink:
Vermeide Confixx auch gern gehackt :wink:
mach lieber manuelle Config

Also ich habe den root-login über SSH deaktiviert. Ich habe derzeit alle Dateien die es betrifft auf chmod 444 gesetzt. Also jetzt kann nur noch der Root schreiben wenn man explizit bestätigt in eine schreibgeschütze Datei zu schreiben.
Ich habe mein Debian Etch via „apt-get dist-upgrade“ auf den neusten Stand von Lenny gebracht. Allerdings steht beim Loggin immernoch „2.6.24-etchnhalf.1-686“, hab allerdings den Server bisher noch nicht neugestartet. Ich habe PHP (PHP Version 5.2.13-0.dotdeb.1) und MySQL auf den neusten Stand gebracht und zudem ist PHP jetzt abgesichert mit Suhosin. Dennoch war nach all den Updates ein erneuter Zugriff möglich!
Mir war zudem aufgefallen das besonders die Haupt-Javascript-Datei des TinyMCE komplett leer war und sich darin nur ein document.write befand welches wiederum ein script in die Seite schrieb welches dann wiederum die Malware läd. Das kuriose war wie gesagt daran das dies die einzige Datei war die komplett leer war und in welcher das document.write allein drin stand, in allen anderen *.js Dateien befand sich das document.write nur ans Ende der Datei angehangen. Irgendwie schaut es so aus als wäre über diesen wysiwyg-Editor eine Art buffer-Overflow gemacht wurden über welchen dann der Zugriff auf die Datein gelangte, wie gesagt nur reine Spekulation. Seit ich das gestern gemerkt und die Schreibrechte voll eingeschränkt habe ist kein neuer Befall zu verzeichnen. Den TinyMCE hab ich zudem auf die neuste Version geupdated.

Was ich jetzt noch ausprobiert habe, den Bouncer-Server abzuschalten, da dieser momentan noch im Channel des Open-Source Projektes sitzt bei dem ich als Entwickler tätig bin. Ich werde aber denk ich dennoch in den sauren Apfel beißen müssen und den einfach mal abschalten/updaten um zu sehen ob es wirklich an diesem lag.

Auf Confixx kann ich momentan eh nicht zugreifen da nach meinen updates Confixx das mysql.sock nicht findet obwohl der pfad stimmt -.- Naja mal schauen.

Falls Ihr dennoch weitere Tipps habt wie man einen Server gegen potentielle Gefahren schützen kann wäre ich Euch zu tiefstem Dank verbunden wenn Ihr mir noch weitere Tipps geben könntet. Mir sind in der letzten Zeit häufig Sachen wie iptables etc. über den Weg gelaufen, aber bisher hab ich noch nicht so recht ermitteln können wie man dies konfiguriert, bin halt nur ein Soft und kein Admin, ist ja schließlich auch ein extra Berufszweig :stuck_out_tongue:

Gut Schuß
VuuRWerK :wink:

ok dann mal wieder paar neue Tipps

  1. mach dir clamav drauf und jags über dein System
  2. mach dich mal nach Rootkit Suchern schlau und jag sie mal über dein System
  3. warte bis ich zu hause bin dann gibts paar Infos zu IPTables :wink:

mehr weiß ich gerade nicht und deshalb FEIERABEND :smiley:

Ok, erstmal kurz der Stand der Dinge. Ich habe das Einfallstor ausfindig gemacht … Man glaubt kaum was die hacker nicht alles so ausprobieren ^^
Naja es lag daran das ich im backend einer Seite auf meinem Server eine PHP Anwendung laufen hatte welche einen minimalen FTP-Client darstellte. Irgendwie war es den Angreifern möglich eine Schwachstelle (entweder im FTP Protokoll oder von PHP, genaueres muss ich nochmal nachlesen aber die links hab ich daheim) auszunutzen und konnte so ohne Anmeldung via FTP die infizierten Dateien hochzuladen. Herausgefunden habe ich es beim checken der xferlog, die Logdatei des FTP-Servers(?).
Naja, den „FTP-Client“ hab ich erstmal vom Server genommen ganz klar. Eventuell kennt ja jemand das Problem und kennt eine Möglichkeit dies zu verhindern, auch wenn man FTP-Transfer via PHP machen möchte, sofern das geht.

Ansonsten spiel ich mir mal das clamav aufn Server. chkrootkit und rkhunter hab ich bereits auf dem Server installiert und auch schon geupdated.

Die Sache zu iptables würde mich wirklich brennend interessieren, wenn Du also noch paar Infos dazu hast, Adlerauge, egal ob von Dir verfasst oder in Form von links würde ich mich sehr freuen, Danke!

Gibts nicht sowas wie ne Fireall für Linux-Server? Da müssten doch solche Zugriffe ausgeschlossen werden, oder? Klar der FTP-Port wäre zwar offen damit man sich drauf verbinden kann aber vllt. gibts spezielle Filter die genau solche Zugriffe ohne Authentifizierung ermöglichen? Ich glaub iptables sollte sowas können, einschränken von IP-Bereiche, oder?

Gut Schuß
VuuRWerK :wink:

uf das klingt böse vuurwerk
ich denk mal das es nen Bug in deinem PHP Kram war.

Firewall für Linux ist IPTables

Kurzversion:

  • IPTables basiert auf 3 Regelketten
    – FORWARD, Kette für Weiterleitungen
    – OUTPUT, Kette für die Sachen die rausgehen
    – INPUT, für die Sachen die reinkommen

Eine Anfrage wir solange durch ein Kette gejagt bis sie jemand ACCEPT oder DROP macht
Du kannst die Überprüfungen anhand des Protokolls (TCP/UDP/IMCP/…) aber auch anhand des Ports und Interfaces machen
Mit einigen Erweiterungen ist über IPTables auch QoS, NAT oder Regeln anhand des höheren Protokolls (HTTP usw) möglich

Hier ein Teil des Scripts von einem meiner Server

[bash]
EXTIF=“venet0”
IPTABLES="/sbin/iptables"

echo “Start …”

echo -n “Regeln löschen …”
$IPTABLES -F
$IPTABLES -t nat -F
echo “Gelöscht”

echo -n “Ping gestatten …”
$IPTABLES -A INPUT -i $EXTIF -p icmp -j ACCEPT
echo “OK”

echo -n “Loopback freischalten …”
$IPTABLES -A INPUT -i lo -j ACCEPT
echo “OK”

echo -n “Polices setzen …”
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
echo “OK”

echo -n "SMTP setzen … "
$IPTABLES -A INPUT -i $EXTIF -p TCP --dport 25 -j ACCEPT
$IPTABLES -A INPUT -i $EXTIF -p TCP --dport 465 -j ACCEPT
echo “OK”

echo -n "POP setzen … "
$IPTABLES -A INPUT -i $EXTIF -p TCP --dport 110 -j ACCEPT
$IPTABLES -A INPUT -i $EXTIF -p TCP --dport 995 -j ACCEPT
echo “OK”[/bash]

Was mir gerade noch zum Thema FTP eingefallen ist, sperr deine User die auf den FTP Server gehen in ihren Home Laufwerken ein
Das bringt dir auch noch einmal etwas Sicherheit oder schalte FTP komplett ab und setz auf SFTP (FTP über SSH) und setz den SSH Port auf einen anderen als 22