Guten Morgen zusammen,
ich bin gerade dabei, unsere Server zu konfigurieren, bestehend aus
1x Mail Server
1x Webserver,
1x MySQL Server
1x Image/Video Server
Alle Systeme laufen auf Debian Etch 64 bit
Auf allen Systemen kommt momentan folgende Pakete/Konfiguration zum Einsatz:
- iptables
- fail2ban
- harden paket
- bastille
- rkhunter & chkrootkit
- logcheck
- integrit
Auf dem Webserver läuft noch:
- Apache 2.2.3 mit mod_security
- PHP 5.2.5 von dotdeb.org + Suhosin Extension & Patch
Auf dem Image/Video Server:
- Lighttpd
- PHP 5.2.5 von dotdeb.org mit FastCGI + Suhosin Extension & Patch
Auf dem Mail Server:
- Postfix, Courier, Imap SSL
ansonsten nix - die kisten tun also nur den dienst, den der name schon verrät :)
Auf dem Cisco Router wurden auch noch Regeln eingerichtet, die nur die entsprechenden Ports Freischalten (Webserver: http, Mailserver: imap, pop3, smtp, Image/Video-Server: http)
Hat jemand noch ein paar sinnvolle Tips, Pakete oder Vorschläge, um die ganze Config noch etwas sicherer zu machen ?
Vielen dank im voraus
gruß
jan
Serverabsicherung - wer hat noch ideen ?
-
- Posts: 31
- Joined: 2007-12-14 19:48
Re: Serverabsicherung - wer hat noch ideen ?
hab wohl nen leidiges thema erwischt *g
-
- Administrator
- Posts: 2643
- Joined: 2004-01-21 17:44
Re: Serverabsicherung - wer hat noch ideen ?
iptables ist auf Stand-Alone-Servern überflüssig (dafür gibt's im Zweifel dedizierte Firewalls), und fail2ban ist gefährlich. An den gewählten Programmen, die Du für die Server-Dienste einsetzt, gibt's erst mal nix auszusetzen - da ist Sicherheit mehr eine Frage der Konfiguration und des Patchlevels. Was das harden-Paket von Debian bei Dir bewirkt kann ich nicht beurteilen - das hängt davon ab, wie Du die mitgelieferten Tools nutzt, welches IDS (hostbasiert) Du als Grundlage verwendest etc.
Wenn Du ohnehin mit mehreren Servern hantierst, würde es sich ggf. noch anbieten, Logs per syslog-ng über die verschiedenen Maschinen zu verteilen, so dass ein Angreifer, der bei einer der Kisten Erfolg hatte, keine Chance hat, die Logfiles zu manipulieren.
Wenn Du ohnehin mit mehreren Servern hantierst, würde es sich ggf. noch anbieten, Logs per syslog-ng über die verschiedenen Maschinen zu verteilen, so dass ein Angreifer, der bei einer der Kisten Erfolg hatte, keine Chance hat, die Logfiles zu manipulieren.
-
- Posts: 31
- Joined: 2007-12-14 19:48
Re: Serverabsicherung - wer hat noch ideen ?
@jfreud
als IDS wollte ich snort einsetzen
bzgl. fail2ban - spielst du auf die logfile manipulation an ? dies hat sich ja (m.E.) mit der aktuellen version erledigt.
über einen seperaten logserver denke ich schon nach :-)
snost noch irgendwelche tipps, wie ich die server (vorallendingen den webserver) sicherer bekommen könnte ?
viele grüße
als IDS wollte ich snort einsetzen
bzgl. fail2ban - spielst du auf die logfile manipulation an ? dies hat sich ja (m.E.) mit der aktuellen version erledigt.
über einen seperaten logserver denke ich schon nach :-)
snost noch irgendwelche tipps, wie ich die server (vorallendingen den webserver) sicherer bekommen könnte ?
viele grüße
-
- Posts: 12
- Joined: 2007-12-18 14:39
Re: Serverabsicherung - wer hat noch ideen ?
grsecurity solltest du dir mal anschauen
-
- Posts: 774
- Joined: 2004-04-26 15:57
Re: Serverabsicherung - wer hat noch ideen ?
Die Frage ist:
Was nutzt ein IDS wenn ein Angreifer das IDS abschalten kann weil der Angriff nicht gestoppt wurde? Ein IPS wäre da eher angebracht, was allerdings sinnfrei ist.
Snort ist ein guter ansatz, Snort-inline kann mit abgestimmten Regelwerken viele Angriffe auf Dienste verhindern und teilweise auch dank default rules unbekannte Angriffe. Am besten ist man mit den Regeln von den Snort machern bedient, vielleicht ist es dir ja das Geld wert. Aber was nutzt es die Codebase zu erhöhen und damit mehr Angriffsfläche zu geben? Es gab in der Vergangen hat schon öfters die möglichkeit ein Rechner mittels Snort vom Netz zu nehmen weil Snort ein Programmierfehler hatte. Da wären wir wieder bei der Codebase :) Ausserdem musst du auch überlegen das viele Verbindungen bzw. viel Traffic auch erstmal von Snort analysiert werden muss, also wäre es nicht gerade intelligent http mit Snort zu prüfen und ein Datenstau zu verursachen.
Lass die Axt im Wald und beschränk dich auf das wesentlichste. Im Forum gibt es da sogar massenhaft diskussionen.
iptables würd ich vielleicht fürs QoS mit Einplanen, die "Firewall" oder besser gesagt dein Packetfilter ist ja wie du schon gesagt hast eine Cisco Box. Die macht das selbe wie iptables.
Ansonsten Spiel noch einen Sicherheitspatch in deinen Kernel ein, Grsec und Pax zum Bleistift, und erstelle Regelwerke für diese. Für mod_security gibt es ja auf gotroot ein ganzen Pack an Regeln. Mit dem Hardened Kernel kannst du dann auch ein chroot betreiben das eigentlich als sicher gilt. Sperr da die Dienste soweit es geht ein. Der Einfachkeit halber habe ich für jeden Chrootet Dienst eine LVM Partition erstellt und dort das Chroot eingerichtet und den entsprechenden Dienst bzw. Dienste. Diese werden nur Read Only gemountet, was veränderungen am Dateisystem unmöglich macht, sogar mit eine PHPWebshell.
Apache, Mysqld und PHP müssen ja im selben Chroot laufen. Ein FTPd ist ja nicht eingeplant, nimm da gleich WebDAV zusammen mit https. Zertifikate kaufen oder von cacert holen.
Webseiten liegen dann auf einer eigenen Partition, genauso wie die Datenbanken und werden dann entsprechend gemountet.
Logs würde ich an einen Syslog Server senden, Syslog-NG leistet da gute Dienste. Mit einem VPN (z.B.: stunnel) ist das ganze auch gleich ein ganzes Stück sicherer. Wenn der Hostserver doch einmal geknackt wird kann man wenigstens in die Logs reinkucken. Auf dem Logserver läuft ausser einer getarnten SSH (google -> Portknocking) und Syslog-NG nichts, die Chance auf ein Hack dort sind sehr unwahrscheinlich.
Denk beim bauen aber auch an die Wartbarkeit der Kiste. Wenn du für einfache Administrative Arbeiten extreme Umwege gehen musst läuft vielleicht etwas verkehrt.
Was nutzt ein IDS wenn ein Angreifer das IDS abschalten kann weil der Angriff nicht gestoppt wurde? Ein IPS wäre da eher angebracht, was allerdings sinnfrei ist.
Snort ist ein guter ansatz, Snort-inline kann mit abgestimmten Regelwerken viele Angriffe auf Dienste verhindern und teilweise auch dank default rules unbekannte Angriffe. Am besten ist man mit den Regeln von den Snort machern bedient, vielleicht ist es dir ja das Geld wert. Aber was nutzt es die Codebase zu erhöhen und damit mehr Angriffsfläche zu geben? Es gab in der Vergangen hat schon öfters die möglichkeit ein Rechner mittels Snort vom Netz zu nehmen weil Snort ein Programmierfehler hatte. Da wären wir wieder bei der Codebase :) Ausserdem musst du auch überlegen das viele Verbindungen bzw. viel Traffic auch erstmal von Snort analysiert werden muss, also wäre es nicht gerade intelligent http mit Snort zu prüfen und ein Datenstau zu verursachen.
Lass die Axt im Wald und beschränk dich auf das wesentlichste. Im Forum gibt es da sogar massenhaft diskussionen.
iptables würd ich vielleicht fürs QoS mit Einplanen, die "Firewall" oder besser gesagt dein Packetfilter ist ja wie du schon gesagt hast eine Cisco Box. Die macht das selbe wie iptables.
Ansonsten Spiel noch einen Sicherheitspatch in deinen Kernel ein, Grsec und Pax zum Bleistift, und erstelle Regelwerke für diese. Für mod_security gibt es ja auf gotroot ein ganzen Pack an Regeln. Mit dem Hardened Kernel kannst du dann auch ein chroot betreiben das eigentlich als sicher gilt. Sperr da die Dienste soweit es geht ein. Der Einfachkeit halber habe ich für jeden Chrootet Dienst eine LVM Partition erstellt und dort das Chroot eingerichtet und den entsprechenden Dienst bzw. Dienste. Diese werden nur Read Only gemountet, was veränderungen am Dateisystem unmöglich macht, sogar mit eine PHPWebshell.
Apache, Mysqld und PHP müssen ja im selben Chroot laufen. Ein FTPd ist ja nicht eingeplant, nimm da gleich WebDAV zusammen mit https. Zertifikate kaufen oder von cacert holen.
Webseiten liegen dann auf einer eigenen Partition, genauso wie die Datenbanken und werden dann entsprechend gemountet.
Logs würde ich an einen Syslog Server senden, Syslog-NG leistet da gute Dienste. Mit einem VPN (z.B.: stunnel) ist das ganze auch gleich ein ganzes Stück sicherer. Wenn der Hostserver doch einmal geknackt wird kann man wenigstens in die Logs reinkucken. Auf dem Logserver läuft ausser einer getarnten SSH (google -> Portknocking) und Syslog-NG nichts, die Chance auf ein Hack dort sind sehr unwahrscheinlich.
Denk beim bauen aber auch an die Wartbarkeit der Kiste. Wenn du für einfache Administrative Arbeiten extreme Umwege gehen musst läuft vielleicht etwas verkehrt.
-
- Posts: 31
- Joined: 2007-12-14 19:48
Re: Serverabsicherung - wer hat noch ideen ?
vielen dank für die umfangreiche detailierte antwort. ein paar fragen bleiben dennoch *g
was ist denn nu sicherer *g ein u.u. unsicheres snort oder gar kein snort ? :)
wenn ich jetzt als beispiel den webserver nehme. auf dem nur apache&php läuft (neben den oben aufgeführten sicherheitstools) - is dann ein chrooten überhaupt sinnvoll ? denn ich habe in einem anderen thread gelesen, dass chrooten nur etwas bringt, wenn mehrere sachen (bspw, mailserver, webserver und sqlserver) auf ein und derselben kiste betrieben werden ?!
viele grüße
also hälst du ids und auch ips für quatsch ?Die Frage ist:
Was nutzt ein IDS wenn ein Angreifer das IDS abschalten kann weil der Angriff nicht gestoppt wurde? Ein IPS wäre da eher angebracht, was allerdings sinnfrei ist.
Code: Select all
Snort ist ein guter ansatz, Snort-inline kann mit abgestimmten Regelwerken viele Angriffe auf Dienste verhindern und teilweise auch dank default rules unbekannte Angriffe. Am besten ist man mit den Regeln von den Snort machern bedient, vielleicht ist es dir ja das Geld wert. Aber was nutzt es die Codebase zu erhöhen und damit mehr Angriffsfläche zu geben? Es gab in der Vergangen hat schon öfters die möglichkeit ein Rechner mittels Snort vom Netz zu nehmen weil Snort ein Programmierfehler hatte. Da wären wir wieder bei der Codebase :) Ausserdem musst du auch überlegen das viele Verbindungen bzw. viel Traffic auch erstmal von Snort analysiert werden muss, also wäre es nicht gerade intelligent http mit Snort zu prüfen und ein Datenstau zu verursachen.
Code: Select all
Ansonsten Spiel noch einen Sicherheitspatch in deinen Kernel ein, Grsec und Pax zum Bleistift, und erstelle Regelwerke für diese. Für mod_security gibt es ja auf gotroot ein ganzen Pack an Regeln. Mit dem Hardened Kernel kannst du dann auch ein chroot betreiben das eigentlich als sicher gilt. Sperr da die Dienste soweit es geht ein. Der Einfachkeit halber habe ich für jeden Chrootet Dienst eine LVM Partition erstellt und dort das Chroot eingerichtet und den entsprechenden Dienst bzw. Dienste. Diese werden nur Read Only gemountet, was veränderungen am Dateisystem unmöglich macht, sogar mit eine PHPWebshell.
ja das habe ich vor. ist es hierbei irrelevant, ob der syslog server im selben internet netz ist (im rechenzentrum) oder kann ich den getrost bei mir ins büro hinstellen ?Logs würde ich an einen Syslog Server senden, Syslog-NG leistet da gute Dienste. Mit einem VPN (z.B.: stunnel) ist das ganze auch gleich ein ganzes Stück sicherer. Wenn der Hostserver doch einmal geknackt wird kann man wenigstens in die Logs reinkucken. Auf dem Logserver läuft ausser einer getarnten SSH (google -> Portknocking) und Syslog-NG nichts, die Chance auf ein Hack dort sind sehr unwahrscheinlich.
viele grüße
-
- Posts: 31
- Joined: 2007-12-14 19:48
Re: Serverabsicherung - wer hat noch ideen ?
*push* :-)
keiner mehr ideen oder vorschläge ?
keiner mehr ideen oder vorschläge ?