Serversicherheit

F

feiz

Eroberer
Hallo.

Ich möchte meinen Server besser absichern, da ich einen Einbruchversuch hatte, der Angreifer wollte meinen Server als Spamschleuder missbrauchen.
Aufgrund der Firewall gelang es ihm aber nicht
Die Firewall ist auf einem anderen System und kann von meinem Server aus nicht umgangen oder geändert werden. (Sie ist als separate Dienstleistung gebucht und hat ein eigenes Webinterface wo man alles einstellen kann)
Zum Glück waren die Ports auch ausgehend so restiktiv eingestellt, dass keine Email rausging. Weil ich Postfix (und andere Sachen) nicht sicher konfigurieren kann, hatte ich einfach alle Ports (ausser HTTP, FTP, SSH) eingehend und ausgehend dicht gemacht, da email nicht benötigt wird. (reiner Webserver)
(Habe Postfix nur installiert, weil er als Bedinung von anderen Programmen verlangt wurde)

Jetzt möchte ich den Server sicherer machen.
Folgende Maßnahmen habe ich bereits ergiffen:

Administrationsaccount, login nur mit administrationsaccount möglich, weder mit root noch mit irgendetwas anderem. Um als Root zugriff zu bekommen muss ich erst mit dem Administrationsaccount einloggen und dann unter Angabe des Root-Passwort zu root wechseln.

SSH habe ich von Port 22 auf einen anderen, vom standard abweichenden Port gelegt.
Den SSH Zugang zu meinem Server habe ich über die externe Firewall auf mein IP-Subnet begrenzt (Ich habe quasi-statische IP beim Internetzugang, nur letzte Ziffer ändert sich gelegentlich)

Cronjob für automaitisches Update eingerichtet, clamAV und chkrootkit installiert.

Meine Linuxkenntnisse gehen so weit, dass ich, ausgehend von einem Minimalst-Linux (also nur KErnsystem mit SSH Zugang) einen Webserver mit php und mysql und allen weiteren benötigten Diensten nur über die Konsole installallieren und einrichten kann.
Allerdings kenne ich mich nicht wirklich gut aus wenns ins Detail geht.

Ich bin gut genug, das ganze funktionsfähig einzurichten.
Allerdings ist das dann auch mehr eine Standard-Konfiguration, die etwa das bietet was man bei den Webhostern üblicherweise so als Standardpaket bekommt. Wenn mehr gefordert wird, komme ich aber auch schon ganz schön ins schwitzen. Ich kenne die Konfigurationsdateien nicht auswendig, und muss jedes mal Dokus oder HowTos lesen oder in Büchern nachschlagen.

Den Sicherheitsaspekt habe ich leider immer etwas vernachlässigt, kenne auch nicht so die Sicherheitslöcher und die Schwachstellen.
Da ich mich sicherheitsmäßig nicht so gut auskenne, habe ich auch die Firewall als externe Dienstleistung in Anspruch genommen, da ich mir selbst nicht zutraue, mit iptables und anderen Maßnahmen ein System schön dicht zu bekommen. Bisher war es auch einzig und alleine die separat gemietete Firewall, die den Server dann doch "sicher" gemacht hat. Ohne die professionell eingerichtete Firewall mit diversen sicherheitsfunktionen wär wohl viel schneller jemand in den Server eingedrungen, so hat es halt relativ lange gedauert.
Hohe Mauer mit schwerem Stahltor ums Grundstück, aber dann ne marode Haustür ohne Schloss, so lässt sich die Situation beschreiben.

Deswegen will ich jetzt mal den server selbst sicherer gestalten.
Ich würde ihn am liebsten von grund auf neu aufsetzen und dann gleich von Anfang an auf Sicherheit achten (und nicht nur darauf, dass es funktioniert)

Wie richtet man insbesondere die folgenen Programme sicher ein:
Debian 4 Grundsystem mit: Apache 2, PHP 5, MySQL 5.1, Postfx, FTP-Server.
 
Zuletzt bearbeitet:
Da du es ja schon selber erkannt hast, spar ich mir mal den obligatorischen root-und-kein-plan-link....:devil:

Zur Frage, auf die Schnelle:

Generell:

- Security-mailing-Liste von Debian mitlesen
- IDS wie snort installieren
- Software up-2-date halten

Apache:

- Puh, da gibt es vieles. Das DDOS-Modul von Apache ist sicher schon mal ein guter Anfang.

Mysql:

- Das hängt im Wesentlichen von der Applikation ab, die darauf zugreift -> Stichwort: SQL-Injection
- Nur dem root-user ist ein "drop ...." erlaubt

Kurze Auswahl weil ich keinen Bock hab mir einen Wolf zu tippen, andere tragen bestimmt auch noch einiges bei.
 
Ich möchte meinen Server besser absichern, da ich einen Einbruchversuch hatte, der Angreifer wollte meinen Server als Spamschleuder missbrauchen.
Aufgrund der Firewall gelang es ihm aber nicht
Die Firewall ist auf einem anderen System und kann von meinem Server aus nicht umgangen oder geändert werden. (Sie ist als separate Dienstleistung gebucht und hat ein eigenes Webinterface wo man alles einstellen kann)
Zum Glück waren die Ports auch ausgehend so restiktiv eingestellt, dass keine Email rausging

Moment mal:

Wenn ich das richtig verstehe, dann war der Angriff selbst aber erfolgreich und Dein System wurde kompromittiert.

Wurden Mails vom System selbst versendet und dann "später" von der externen Firewall geblockt?

Wenn ja, dann wurde das System kompromittiert.

Dann hilft nur eines:

=> System runterfahren, Daten für Analyse sichern, Lücke ausfindig machen und schliessen, System abgesichert neu aufsetzen und erst dann wieder ans Netz nehmen.
 
Moment mal:

Wurden Mails vom System selbst versendet und dann "später" von der externen Firewall geblockt?

Ja. Das System versuchte ständig emails abzusetzten, aber die Firewall verhinderte dies. Postfix bekam keine Verbindung zu web.de, gmx, t-online und co um die mails da abzusetzen, und ich bekam das auch als x-tausendfache Fehlermeldung beim Log zu lesen.

Die Firewall hat mir eine Warnung geschickt, darauf hin habe ich auch mal das Log vom Server gelesen.
 
Dann ist das System kompromittiert worden und das Kind liegt im Brunnen.

Maßnahmen stehen oben, nimm die Kiste vom Netz, wer weiß, was der Angreifer noch alles angestellt hat, was Du _nicht_ findest.

HTTP und FTP sind offen? Schön, darüber (wahrscheinlich über den Webserver) kam der Angreifer rein und über diese Kanäle kommt er sicher auch wieder raus, und damit lässt sich genügend Schindluder treiben.
 
Ja. Das System versuchte ständig emails abzusetzten, aber die Firewall verhinderte dies. Postfix bekam keine Verbindung zu web.de, gmx, t-online und co um die mails da abzusetzen, und ich bekam das auch als x-tausendfache Fehlermeldung beim Log zu lesen.

Die Firewall hat mir eine Warnung geschickt, darauf hin habe ich auch mal das Log vom Server gelesen.

Achja der Angreifer ist per SSH eingedrungen, er hat irgendwie das Root Passwort herausgefunden und dann irgend ein Bot oder so installiert.
 
*AAAAAAAAAAAARGGHHHHHHHHHHHHHHH*

Deine Kiste wurde also auch noch komplett "gerootet"?

Schalt das DING ab!

Und wenn man nicht mal seinen SSH-Login absichern kann, dann sollte man sie auch nicht mehr so schnell anschalten!
 
Dann ist das System kompromittiert worden und das Kind liegt im Brunnen.

Maßnahmen stehen oben, nimm die Kiste vom Netz, wer weiß, was der Angreifer noch alles angestellt hat, was Du _nicht_ findest.

HTTP und FTP sind offen? Schön, darüber (wahrscheinlich über den Webserver) kam der Angreifer rein und über diese Kanäle kommt er sicher auch wieder raus, und damit lässt sich genügend Schindluder treiben.

Ja, webserver und FTP waren offen, irgendwie hat er dadurch dann wohl die ersten Maßnahmen ergriffen um später per SSH ganz gemütlich den rest zu machen.
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

*AAAAAAAAAAAARGGHHHHHHHHHHHHHHH*

Deine Kiste wurde also auch noch komplett "gerootet"?

Schalt das DING ab!

Und wenn man nicht mal seinen SSH-Login absichern kann, dann sollte man sie auch nicht mehr so schnell anschalten!

Naja ich habe erst mal alle Ports in der Firewall gesperrt, will noch veruschen herauszufinden was der angreifer alles gemacht hat bevor ich den Recovery (neuinstallation mit Debian-Grundsystem) beauftrage.
 
Zuletzt bearbeitet:
Und das geht auch sicher in der seriellen Konsole.

Wenn "alle Ports" bedeutet http/ftp und ssh, dann geht es eh nur über diese.

Und das "Recovery" setzt Dir die Kiste spätestens dann mit der selben Lücke wieder ins Netz, wenn Du die selbe SW wieder draufknallst, die schon lief, das muss nicht das Grundsystem sein, aber es wäre möglich.

Dann kommt der (selbe?) böse Bube über die selbe Lücke wieder rein, Deine IP dürfte inzwischen auf gewissen Listen wahrscheinlich weit oben stehen.

Vorherige, _komplette_ Sicherung des jetzigen Systems zur "Post Mortem"-Analyse ist nicht vorgesehen?

Falls nein, eine sehr törichte Idee.
 
Hi.

Also serielle Konsole geht leider nicht, habe keinen pysikalischen Zugriff auf den Server.
Eine komplette Sicherung werd ich auf jeden Fall machen und mir das Image dann runterladen und auf dem PC analysieren.
Das Recovery ist ein vorgefertigtes Image vom Provider, wie sicher dieses ist kann ich nicht sagen.

Vielleicht kündige ich den Server aber auch, und hol mir nen normalen Webspace, ist zwar teurer (wenn ich keine Abstriche bei der Speicherkapazität mache) und weniger flexibel aber ich habe weniger Arbeit und Probleme damit.
 
Zuletzt bearbeitet:
Und das "Recovery" setzt Dir die Kiste spätestens dann mit der selben Lücke wieder ins Netz, wenn Du die selbe SW wieder draufknallst, die schon lief, das muss nicht das Grundsystem sein, aber es wäre möglich.

Ich tippe ja mal eher stark darauf, das das Image ok war / ist, jedoch durch nachfolgende Änderungen vom TE eben eine Lücke entstanden ist.

Wenn nämlich das Image des Providers fehlerhaft wäre, wäre das schon lange in einschlägigen Kreisen bekannt und entsprechende Angriffsversuche wären schon lange gestartet -> so was schlägt Wellen bzw. bleibt nicht unbemerkt.

Von daher denke, ist es etwas "über-paranoid" das image selber für fehlerhaft zu halten.

Auch wenn das zugegebenermaßen natürlich trotzdem möglich ist.
 
Wenn nämlich das Image des Providers fehlerhaft wäre, wäre das schon lange in einschlägigen Kreisen bekannt und entsprechende Angriffsversuche wären schon lange gestartet -> so was schlägt Wellen bzw. bleibt nicht unbemerkt.

Es geht eher um die Frage wie aktuell diese Images sind und ob da auch zumindest nach dem Recovery gleich die neusten Patches noch eingespielt werden oder ob das in der Verantwortung des Kunden liegt (und da es um Debian geht, sage ich nur SSL, mehr nicht).

Sollte z.B. die Erstinstallation vor dem Patchen der Lücke gewesen sein und der TE keine Updates eingespielt haben, dann wissen wir ja, wieso wahrscheinlich das Root-PW "erraten" wurde.
 
Es geht eher um die Frage wie aktuell diese Images sind und ob da auch zumindest nach dem Recovery gleich die neusten Patches noch eingespielt werden oder ob das in der Verantwortung des Kunden liegt (und da es um Debian geht, sage ich nur SSL, mehr nicht).

Sollte z.B. die Erstinstallation vor dem Patchen der Lücke gewesen sein und der TE keine Updates eingespielt haben, dann wissen wir ja, wieso wahrscheinlich das Root-PW "erraten" wurde.

Also dass ich den Server aufgesetzt habe ist schon länger her. Ein Update hatte ich im April gemacht. Wann war denn der besagte Patch?

Und wie oft sollte man updaten? Wöchentlich?
Reicht eine automatische Updateroutine via Cronjob oder muss man irgendwo noch selbst Hand anlegen?

Achja, die Programme wie Apache, PHP, usw habe ich per Apt-Get installiert und dann das meißte in der Standardeinstellung belassen, nur funktional wichtige Dinge hab ich dann angepasst.
Weiß bei vielen Optionen aber auch nicht, was sie überhaupt bewirken und muss mich auf verschiedene Tutorials und so verlassen.
 
Zuletzt bearbeitet:
Anhand Deiner letzten Postings ist das hier

Vielleicht kündige ich den Server aber auch, und hol mir nen normalen Webspace, ist zwar teurer (wenn ich keine Abstriche bei der Speicherkapazität mache) und weniger flexibel aber ich habe weniger Arbeit und Probleme damit.

die einzig vernünfige Idee.

Das ist nicht böse sondern ernst gemeint.
 
wer über SSH einen root-login zulässt und so selten updates fährt und heute erst von einem Problem erfährt welches Debian mit SSH hatte der sollte keinen Rootie betreiben weil er keinen Plan hat ... mach das was du vorgeschlagen hast und RM bestätigt hat.
 
Ob der Server jetzt über SSH auf Grund des OpenSSL-Fehlers kompromittiert wurde sei jetzt mal dahin gestellt, könnte genau so gut auch ein PHP-Script im falschen User-context gewesen sein das eine Ausführung einer Remote-Shell erlaubte... aber naja....

Jedenfalls sollte zum SSH-Auth der root-login verweigert, am besten nur Auth per Keys zugelassen und der SSH Port wegen lästigen Bots auf einen anderen Port gelegt werden.

Bezüglich Apache ist mod_security sicherlich erste Wahl mit einer Auswertung über Splunk.

Genaueres erfährst du unter [1]

Und wie meine Vorgänger schon erwähnten, wenn der Server bereits kompromittiert wurde, weg vom Netz mit dem Ding und neu installieren.

[1] http://www.debian.org/doc/manuals/securing-debian-howto/
 
Hi.

Habe jetzt erst mal ein normales Webhosting Angebot gebucht und will erst mal bisschen üben und mir im Lan nen Server einrichten.

Kennt jemand eine gute Anleitung bzw ein gutes Buch (in deutsch), in der das einrichten eines zeitgemäßen Linux Webservers erklärt wird? Und zwar unter Berücksichtigung der Sicherheitsaspekte?

Folgende Themen sollten bearbeitet werden. Gerne auch mit mehreren Büchern aber auf deutsch.

1. Einrichtung eines sicheren Debian-Grundsystems
Am besten aber mit Blick über den Tellerrand (also nicht nur distributionsbezogen), also auch allgemeine Erklärungen zu der Funktionsweise und den Internas von Linux, Erklärung des Kernsystems, Ablauf des Systemstarts, Konfiguration, Konfigurationsdateien etc.

2. Einrichtung eines zeitgemäßen, sicheren Webservers mit den üblichen Diensten (also etwa das was bei kommerziellen Webhosting Angeboten derzeit üblicherweise geboten wird)
Apache, Mysql, PHP, eMail

3. Systemsicherheit allgemein, etwa auf dem Sicherheitsniveau wie bei kommerziellen Webhosting-Angeboten.

4. Weitergehende Systemverwaltung, IP-Tables, Logrotate, Bash-Scripterstellung und was man sonst noch für den ordentlichen Betrieb eines Webservers so braucht.

Will das ganze jetzt auch mal verstehen und nicht nur irgendwie zum laufen bekommen.

Greetz feiz
 
Zuletzt bearbeitet:
Unter Umständen solltest du dir Scott Grannemans Linux Phrasebook ansehen, mehr dazu unter http://www.granneman.com/writing/books.htm

Zu Firewalls kann ich dir Andreas G. Lessings Linux Firewalls empfehlen, es ist als O'Reilly Openbook kostenlos unter http://www.oreilly.de/german/freebooks/linuxfire2ger/toc.html verfügbar.

Unter http://netzmafia.de/skripten/index.html findest du sicherlich weitere Erleuchtung.
Bücher vom selben Autor findest du unter http://netzmafia.de/skripten/buecher/index.html (Eines ist als PDF vollständig verfügbar)


Auf jeden Fall solltest du die Debian Security Annonuce Mailingliste abonnieren:
http://lists.debian.org/debian-security-announce/

PS: Wie wäre es wenn wir den ganzen Kram auf einer Wiki-Seite sammeln ?
 

Ähnliche Themen

SSH nicht mehr erreichbar nach fail2ban / disabling root login

PHP Version von 5.3 auf 5.4 Updaten (Centos 6.5)

Mail Transport Agent auf installieren? Welchen? Oder keinen?

Samba und APF Firewall

dovecot und postfix Konfiguration Problem

Zurück
Oben