Absichern des eigenen Servers: Unterschied zwischen den Versionen
Yehudi (Diskussion | Beiträge) |
Gehrke (Diskussion | Beiträge) K (interne Verlinkung) |
||
(10 dazwischenliegende Versionen von 6 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
+ | Autor: nbkr | ||
+ | Ich will in diesem Thread versuchen darzustellen wie man den eigenen Webserver möglichst sicher macht. Anregung, Vorschläge und Ergänzungen sind jederzeit willkommen. | ||
+ | |||
+ | |||
+ | Alles abschalten oder entfernen | ||
+ | Man sollte auf einem Server alles Abschalten was man nicht unbedingt braucht. Wenn es sich einrichten lässt sollte man entsprechend Pakete sogar entfernen. | ||
+ | |||
+ | * '''Alles Compilerwerkzeuge''' | ||
+ | Auf einem Server sollten keine Compiler oder ähnliches zu finden sein. Ein | ||
+ | Eingreifer der bereits eingedrungen ist könnte das sonst nutzen um weitere Exploits zu compilieren. Braucht man ein Paket auf dem Server dass nicht im Paketverwaltungssystem enthalten ist sollte man man es auf einer zweiten Maschine compilieren und mittels "checkinstall" in ein Paket umwandeln welches man dann auf dem Server installieren kann. | ||
+ | |||
+ | * '''Dienste abschalten''' | ||
+ | Alle Dienste die nicht benötigt werden sollten abgeschaltet werden. Inetd ist z.B. ein Dienst den man nicht unbedingt braucht. Auch die ganzen r - Dienste wie rsh, sowie Telnet sollte man abschlaten da es mit ssh und scp bessere alternativen dafür gibt. | ||
+ | |||
+ | * '''Dienste nur an das loopback device binden''' | ||
+ | Dienste die nicht von außen erreichbar sein müssen (wie z.B. mysql) sollten nur an das Loopbackdevice gebunden sein (also nur auf die Adresse 127.0.0.1 hören). Lassen sich Dienste nicht an bestimmte Adressen binden sollten sie mit einer Firewall daran gehindert werden an anderen Adressen zu lauschen. | ||
+ | |||
+ | * '''Nur Distributionen verwenden die regelmäßige Updates erhalten.''' | ||
+ | Man sollte für einen Server z.B. kein Debian testing oder unstable einsetzen, da diese nicht über die automatischen Sicherheitsupdates wie die Stablevariante haben. | ||
+ | |||
+ | * '''ssh nur per Publickey und nicht für root.''' | ||
+ | Man sollte den Zugang mittels Username & Passwort für [[SSH]] abschalten (Anleitung gibts hier im Wiki), da sonst eine Brootforce Attacke Erfolg haben könnte. Außerdem sollte man [[Root]] das anmelden per [[SSH]] generel verbieten. Stattdessen sollte man sich einen normalen User erstellen über welchen man sich einloggt und dann mittels "su" rootrechte erlangt falls benötigt. | ||
+ | |||
+ | Desweiteren sollte man dem [[SSH]] Daemon eine Liste der Benutzer mitgeben die sich überhaupt einloggen dürfen. (Das geht in der sshd_config über die Einstellung "allowUsers <benutzername1> <benutzername2>" | ||
+ | |||
+ | * '''Firewall aktivieren''' | ||
+ | Eine '''Firewall''' bietet zwar keine 100% wirksamen Schutz gegen Fehler in Anwendungen, aber schaden kann sie auch nicht. | ||
+ | |||
+ | Unter: | ||
+ | <!-- | ||
+ | http://www.harry.homelinux.org/modules.php?name=iptables_Generator | ||
+ | den gibt es nicht mehr, ich glaube nachfolgend das ist der neue Link, bin mir aber nicht ganz sicher --> | ||
+ | http://www.tobias-bauer.de/computer/iptables/index.html | ||
+ | gibt es eine recht guten Generator für [[iptables]] Scripte. Besser wäre jedoch ein entsprechendes Buch zu lesen und zu verstehen und dann ein eigenes Script zu schreiben. | ||
+ | |||
+ | Was auch noch passt, Hinweise zur Dateiintegrität (z.B. Tripwire) und Hilfstools zur Loganalyse (z.B. Logwatch). Dazu noch Hinweise zu Tools wie chrootkit ... | ||
+ | |||
+ | von PC Ulf: | ||
+ | |||
+ | Zur Sicherheit gehört auch, Veränderungen am System richtig zu analysieren, und dies ist ohne Vorbereitung echte Arbeit. Ich sichere mir z.B. immer das Verzeichnis /etc, mit diff ist anschließend jede Änderung am System sehr genau analysiert (CVS ist auch hier ein überaus praktisches Werkzeug). | ||
+ | |||
+ | von PP-checker: | ||
+ | |||
+ | http://denyhosts.sourceforge.net/ | ||
+ | Ein Tool, das Angreifer auf die /etc/hosts.deny setzt -> derjenige wird ignoriert, er kann keine Verbindungen mehr mit dem Server aufbauen. Es wurde speziell für SSH entwickelt, kann aber auch für andere Dienste verwendet werden. | ||
+ | |||
+ | Grundlage ist ein Skript, das /var/log/messages auf Einbruchversuche durchsucht. | ||
+ | |||
+ | Wichtig sind des Weiteren in der sshd_config: | ||
+ | |||
+ | MaxAuthTries = 0 (bei falscher Passworteingabe neu verbinden, ist für Denyhosts wichtig) | ||
+ | MaxStartups = 7 (gleichzeitige SSH Nutzung von, in diesem Fall, 7 Leuten) | ||
+ | |||
+ | |||
+ | Das Tool ist extrem wirksam, es kann sogar über e-mail über die Angriffe informieren. | ||
+ | |||
+ | Die IP Adressen können nach einer gewissen Zeitspanne von dem Programm wieder aus der hosts.deny Liste rausgelöscht werden, sozusagen ein IP-Verfallsdatum (IPs werden ja nach maximal 24h geändert, wenn nicht dynamisch). Eine allow-liste kann verwendet werden. | ||
+ | |||
+ | Fazit: Bruteforceattacken können von dem Programm zuverlässig abgewendet werden und es trägt wesentlich zur Sicherheit des Servers bei. | ||
+ | |||
+ | Wenn die User allerdings Passwörter wie "abc123" oder "linux" haben und dann der Server gehackt wird und dann auf Denyhosts geschimpft wird, dann haben die Leute was Grundlegendes nicht verstanden. | ||
+ | |||
+ | von framp: | ||
+ | |||
+ | Ganz geschickt finde ich auch folgendes: | ||
+ | Code: | ||
+ | |||
+ | iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT | ||
+ | iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force " | ||
+ | iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP | ||
+ | |||
+ | Damit sind nur maximal 3 Verbindungsversuche pro Minute erlaubt von jeder IP-Adresse im Internet. Sollte diese Marke überschritten werden muss eine Minute gewartet werden bis wieder Verbindungen zugelassen werden. | ||
+ | |||
+ | siehe auch http://www.linux-club.de/viewtopic.php?t=63277 | ||
+ | |||
+ | '''Weitere Informationen zu diesem Thema''' | ||
+ | *[[Wie sichere ich meinen ssh Server]] | ||
+ | *[[Einrichten von public keys mit ssh]] | ||
+ | *[[Mit putty und ssh key auf einen sicheren Linux Server zugreifen]] | ||
+ | *[[Passwörter]] | ||
+ | |||
+ | ---- | ||
+ | [[Security|Zurück zu Security]] | ||
[[Category:Security]] | [[Category:Security]] |
Aktuelle Version vom 23. November 2013, 15:37 Uhr
Autor: nbkr
Ich will in diesem Thread versuchen darzustellen wie man den eigenen Webserver möglichst sicher macht. Anregung, Vorschläge und Ergänzungen sind jederzeit willkommen.
Alles abschalten oder entfernen
Man sollte auf einem Server alles Abschalten was man nicht unbedingt braucht. Wenn es sich einrichten lässt sollte man entsprechend Pakete sogar entfernen.
- Alles Compilerwerkzeuge
Auf einem Server sollten keine Compiler oder ähnliches zu finden sein. Ein Eingreifer der bereits eingedrungen ist könnte das sonst nutzen um weitere Exploits zu compilieren. Braucht man ein Paket auf dem Server dass nicht im Paketverwaltungssystem enthalten ist sollte man man es auf einer zweiten Maschine compilieren und mittels "checkinstall" in ein Paket umwandeln welches man dann auf dem Server installieren kann.
- Dienste abschalten
Alle Dienste die nicht benötigt werden sollten abgeschaltet werden. Inetd ist z.B. ein Dienst den man nicht unbedingt braucht. Auch die ganzen r - Dienste wie rsh, sowie Telnet sollte man abschlaten da es mit ssh und scp bessere alternativen dafür gibt.
- Dienste nur an das loopback device binden
Dienste die nicht von außen erreichbar sein müssen (wie z.B. mysql) sollten nur an das Loopbackdevice gebunden sein (also nur auf die Adresse 127.0.0.1 hören). Lassen sich Dienste nicht an bestimmte Adressen binden sollten sie mit einer Firewall daran gehindert werden an anderen Adressen zu lauschen.
- Nur Distributionen verwenden die regelmäßige Updates erhalten.
Man sollte für einen Server z.B. kein Debian testing oder unstable einsetzen, da diese nicht über die automatischen Sicherheitsupdates wie die Stablevariante haben.
- ssh nur per Publickey und nicht für root.
Man sollte den Zugang mittels Username & Passwort für SSH abschalten (Anleitung gibts hier im Wiki), da sonst eine Brootforce Attacke Erfolg haben könnte. Außerdem sollte man Root das anmelden per SSH generel verbieten. Stattdessen sollte man sich einen normalen User erstellen über welchen man sich einloggt und dann mittels "su" rootrechte erlangt falls benötigt.
Desweiteren sollte man dem SSH Daemon eine Liste der Benutzer mitgeben die sich überhaupt einloggen dürfen. (Das geht in der sshd_config über die Einstellung "allowUsers <benutzername1> <benutzername2>"
- Firewall aktivieren
Eine Firewall bietet zwar keine 100% wirksamen Schutz gegen Fehler in Anwendungen, aber schaden kann sie auch nicht.
Unter: http://www.tobias-bauer.de/computer/iptables/index.html gibt es eine recht guten Generator für iptables Scripte. Besser wäre jedoch ein entsprechendes Buch zu lesen und zu verstehen und dann ein eigenes Script zu schreiben.
Was auch noch passt, Hinweise zur Dateiintegrität (z.B. Tripwire) und Hilfstools zur Loganalyse (z.B. Logwatch). Dazu noch Hinweise zu Tools wie chrootkit ...
von PC Ulf:
Zur Sicherheit gehört auch, Veränderungen am System richtig zu analysieren, und dies ist ohne Vorbereitung echte Arbeit. Ich sichere mir z.B. immer das Verzeichnis /etc, mit diff ist anschließend jede Änderung am System sehr genau analysiert (CVS ist auch hier ein überaus praktisches Werkzeug).
von PP-checker:
http://denyhosts.sourceforge.net/ Ein Tool, das Angreifer auf die /etc/hosts.deny setzt -> derjenige wird ignoriert, er kann keine Verbindungen mehr mit dem Server aufbauen. Es wurde speziell für SSH entwickelt, kann aber auch für andere Dienste verwendet werden.
Grundlage ist ein Skript, das /var/log/messages auf Einbruchversuche durchsucht.
Wichtig sind des Weiteren in der sshd_config:
MaxAuthTries = 0 (bei falscher Passworteingabe neu verbinden, ist für Denyhosts wichtig) MaxStartups = 7 (gleichzeitige SSH Nutzung von, in diesem Fall, 7 Leuten)
Das Tool ist extrem wirksam, es kann sogar über e-mail über die Angriffe informieren.
Die IP Adressen können nach einer gewissen Zeitspanne von dem Programm wieder aus der hosts.deny Liste rausgelöscht werden, sozusagen ein IP-Verfallsdatum (IPs werden ja nach maximal 24h geändert, wenn nicht dynamisch). Eine allow-liste kann verwendet werden.
Fazit: Bruteforceattacken können von dem Programm zuverlässig abgewendet werden und es trägt wesentlich zur Sicherheit des Servers bei.
Wenn die User allerdings Passwörter wie "abc123" oder "linux" haben und dann der Server gehackt wird und dann auf Denyhosts geschimpft wird, dann haben die Leute was Grundlegendes nicht verstanden.
von framp:
Ganz geschickt finde ich auch folgendes: Code:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force " iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Damit sind nur maximal 3 Verbindungsversuche pro Minute erlaubt von jeder IP-Adresse im Internet. Sollte diese Marke überschritten werden muss eine Minute gewartet werden bis wieder Verbindungen zugelassen werden.
siehe auch http://www.linux-club.de/viewtopic.php?t=63277
Weitere Informationen zu diesem Thema
- Wie sichere ich meinen ssh Server
- Einrichten von public keys mit ssh
- Mit putty und ssh key auf einen sicheren Linux Server zugreifen
- Passwörter