Einrichten eines sicheren Debian-Servers

Hoeze

Lieutenant
Registriert
Juni 2010
Beiträge
706
Hi,
ich will mir demnächst einen Server zulegen, deshalb bereite ich im Moment schon meine gewünschten Einstellungen vor.
(Prinzipiell bin ich noch eher unerfahren mit Linux, ich kann mir jetzt aber schon selber helfen)
1. IPtables:
Code:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
 
# allow local loopback connections
-A INPUT -i lo -j ACCEPT
# allow connections from localhost
-A INPUT -s 127.0.0.1 -j ACCEPT
# drop INVALID connections
-A INPUT   -m state --state INVALID -j DROP
-A OUTPUT  -m state --state INVALID -j DROP
-A FORWARD -m state --state INVALID -j DROP

# allow all established and related
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# add anymore rules here

#OpenVPN
-A INPUT -p udp --dport 1194-1198 -j ACCEPT

#Minecraft
-A INPUT --dport 25565 -j ACCEPT

#SSH
-A INPUT -m tcp -p tcp –dport 22 -m state –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m tcp -p tcp –dport 22 -m state –state NEW -m limit –limit 3/min –limit-burst 3 -j ACCEPT
-A INPUT -m tcp -p tcp –dport 22 -j DROP

# block portscans
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP

$IPTABLES -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP

COMMIT

Die Regeln gegen Portscanning und zum SSH-Schutz hab ich mir von anderen Websites zusammengeklaut, funktionieren die anständig?

Habt ihr sonst noch irgendwelche Tipps für mich?

2. Ist es möglich, bestimmte Dienste wie PHP oder Apache komplett vom restlichen System zu trennen?
Sprich, als würden sie auf einer anderen Maschine laufen?
Wie stell ich das an?
 
Normalerweise solltest du den root Login unterbinden und möglichst nicht Standard-Ports benutzen. Das mit Iptables kannst du ja probieren. Was du machen möchtest mit unterschiedlichen Maschinen wäre dann ein Hypervisor:
http://wiki.debian.org/de/Xen
Ich habe im Endeffekt das ganze bei mir so gelöst, dass Iptables blockt wenn eine gewisse Anzahl von Versuchen fehlschlägt.
 
für Dinge wie "SSH Schutz" (was für eine vage Bezeichnung) gibt es Dinge wie fail2ban.
 
Mir geht's ziemlich ähnlich mit dir, hab mir auch einen Root geholt und erstmal ziemlich versucht den aufs Gröbste abzusichern.
Ich habe halt zum Beispiel den Loginport für den Login verändert.

An sich gibt es ja keine perfekte Sicherheit. Und für maximale Sicherheit bist du quasi ununterbrochen beschäftigt damit, nicht umsonst werden auch immer wieder große Unternehmen mit guten Sicherheitsvorkehrungen gehacked.

Ich sehe da einfach die Relation, wie wichtig es einem Hacker ist, meinen Server zu hacken und wie viel Aufwand zum Schutz dem gegenüber steht. Wenn sich ein Hacker total auf deinen Server fixiert, wird er's wohl früher oder später schaffen, wenn er aber schnell das Interesse verliert weil ich a) kein sonderlich lohnenswertes Ziel bin und b) er mit leichtem und mittelmäßigem Geschütz durchkommt, passt das meiner Meinung nach.

Außerdem kommt noch c) hinzu, dass man einfach immer wieder prüfen sollte, ob alles iO ist.
Auf meinem Server laufen nur Gameserver, später vllt noch TS3 Server und eventuell 'ne kleine Website, von daher ist man auch gut beraten den Traffic zu überwachen etc.

Hier noch zwei "Tutorials" die ich ganz nett finde.

http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html

https://library.linode.com/securing-your-server

http://www.debianroot.de/ wollte ich mir mal noch genauer angucken, weil es da auch ein paar gute Anleitungen gab, über die ich schon via Google gestolpert bin.


Übrigens bin ich auch über gute Ratschläge dankbar. Es klingt vielleicht oben im Text dass mir die Sicherheit nicht so wichtig wäre, mir geht es mehr um den Punkt, dass ich mich wegen der Sicherheit nicht mehr verrückt mache.
 
TCP/IP stack härten
ssh nur per sshkey, login per pwd aus, root login aus.
setze soviel wie möglich auf chmod 0700
soviel wie möglich readonly mounten
überall wo möglich noexec,nosuid,nodev mounten
Trimm dein System auf ein absolutes Minimum herunter, auch compiler/sudo usw raus.
Mach PAX im Kernel an.
Alle Module in den Kernel, loadable Module support im Kernel ausmachen.
Installier dir eine MAC-implementierung -> SELinux oder Tomoyo.

Kannst noch viel mehr machen, das sollte aber erstmal Sicherheit geben.
 
Zuletzt bearbeitet:
Hoeze schrieb:
Habt ihr sonst noch irgendwelche Tipps für mich?
Ja. Laß den geposteten iptables-Kram komplett weg. Um Ports, auf denen sowieso kein Netzwerkdienst läuft, brauchst du dich nicht zu kümmern. Da, wo was läuft, läßt du sowieso alles durch. Also laß das ganze komplett weg. Du scheinst nach "Viel Bastelkram hilft viel" zu agieren. Das ist Quark. Schieß dir nicht selbst ins Knie.

Kümmere dich um eine gescheite Konfiguration der angebotenen Diente (ssh, vpn, ...) und fertig. Das ist komplex genug.

Achja: Regelmäßig die Updates deiner Distribution einspielen ist wichtig. Evtl. trägst du dich auch auf der Mailingliste deiner Distri ein, auf der entdeckte sicherheitsrelevante Bugs und deren Behebung bekanntgeben werden
 
Zuletzt bearbeitet:
Hoeze schrieb:
2. Ist es möglich, bestimmte Dienste wie PHP oder Apache komplett vom restlichen System zu trennen?
Sprich, als würden sie auf einer anderen Maschine laufen?
Das wird eher nichts, aber da der Apache eh nicht als root laufen sollte ist das Problem eher klein.
Wenn du mehrere unabhängige Webseiten auf derselben Maschine laufen lassen willst, musst du dir noch Sorgen um eine Form von SUEXEC machen, z.B. sauber konfiguriertes MPM-ITK verwenden.

Mumpitzelchen schrieb:
für Dinge wie "SSH Schutz" (was für eine vage Bezeichnung) gibt es Dinge wie fail2ban.
Zusätzlich sollte man evtl. noch auf Jailkit setzen.
Mit aktivem Fail2Ban kann man SSH per Passwort sogar aktiv lassen. Die theoretische Wahrscheinlichkeit eines Brute/Force - Erfolges ist dann verschwindend gering, außer der Angreifer hat ein Botnetz mit massenhaft IPs zur Verfügung.
 
Der sshd (von openssh) biete selbst guten Schutz vor Bruteforce-Angriffen auf Passwörter. Fail2ban davorschalten ist in 99,9999% der Fälle grober Unfug. Das Tool kann man für Dienste nutzen, die keinen eigenen Schutz gegen solche Attacken bieten.

Passwortauthentikation kann man selbstverständlich aktiv lassen, wenn man mit ordentlichen Pass"wörtern" arbeitet.

Daaron schrieb:
Mit aktivem Fail2Ban kann man SSH per Passwort sogar aktiv lassen. Die theoretische Wahrscheinlichkeit eines Brute/Force - Erfolges ist dann verschwindend gering, außer der Angreifer hat ein Botnetz mit massenhaft IPs zur Verfügung.
Ein Botnetz bringt sowieso nix. Da der sshd (ganz ohne Extratools) eine Maximalzahl gleichzeitiger, noch nicht erfolgreicher Anmeldeversuche implementiert, erhöht ein verteilter Angriff gegenüber einem Angriff von einer IP aus die Zahl der Versuche pro Zeit gar nicht.

Man brauch nichts über die ssh-internen Mechanismen hinaus gegen Bruteforce. DIe ssh-Autoren sind ja nicht doof. Zusätzliche Paktefilter machen nur gegen _massive_ DOS-Angriffe Sinn (ganz sicher nicht mit fail2ban!), also wenn man sich selbst nicht mehr einloggen kann. In dem Fall hat man allerdings ganz andere Probleme. Für Otto Normaluser ist das gar kein Thema.
 
Das Botnet bezog sich eher auf dei allgemeine Funktionsweise von Fail2ban: es sperrt die angreifende IP temporär. Ein Botnet hat viele IPs, also auch deutlich mehr Versuche.
 
Lässt Du den Server denn ohne externe Firewall mit direktem Zugang zum WAN laufen? Ansonsten spar Dir viel Arbeit am Server und lass die Firewall die Arbeit für Dich machen (Sophos UTM, Sonicwall oder ähnliches hab ich ganz gute Erfahrungen mit gemacht).
 
Sorry, aber SSH nur mit pwd-file ist wohl zu unpraktisch, um es zu nutzen. Darauf habe ich keinen Bock.

Ein Problem, dem kaum beizukommen ist, ist leider, dass viele CMS oder ähnliche Web-Dienste mehr brauchen als 700.

SELinux ist zudem ***kompliziert.
 
Zuletzt bearbeitet:
F_GXdx schrieb:
Sorry, aber SSH nur mit pwd-file ist wohl zu unpraktisch, um es zu nutzen. Darauf habe ich keinen Bock.
?
Man spart sich die passwd Eingabe. Nach "$ssh xxx.xxx.xxx.xxx" ist man sofort im Server, ssh-keys ftw.

F_GXdx schrieb:
Ein Problem, dem kaum beizukommen ist, ist leider, dass viele CMS oder ähnliche Web-Dienste mehr brauchen als 700.
0700 ist natürlich nicht für jedes File sinnvoll, Files wie iptables.rules sollten es aber bekommen.

F_GXdx schrieb:
SELinux ist zudem ***kompliziert.
Dann nutze doch tomoyo, das hat sogar einen learning mode!
 
entropie88 schrieb:
?
Man spart sich die passwd Eingabe. Nach "$ssh xxx.xxx.xxx.xxx" ist man sofort im Server, ssh-keys ftw.
Man kann SSH Keyfiles wunderbar mit regulärem Passwort-Login kombinieren. Tatsächlich BRAUCHT man Keyfiles sogar, wenn man z.B. mit Dirvish Backups von bestimmten Ordnern ziehen will.

0700 ist natürlich nicht für jedes File sinnvoll, Files wie iptables.rules sollten es aber bekommen.
Wozu sollte man einer Config-Datei rwx --- --- geben? Fehler erkannt?
 
entropie88 schrieb:
?
Man spart sich die passwd Eingabe. Nach "$ssh xxx.xxx.xxx.xxx" ist man sofort im Server, ssh-keys ftw.
Wenn man aber ständig an unterschiedlichen PCs arbeitet?
 
F_GXdx schrieb:
Wenn man aber ständig an unterschiedlichen PCs arbeitet?
Wenn man möchte auch dann. Auf den "unterschiedlichen PCs" muß jeweils der (durch z.B. eine passphrase gesicherte) Key zum Einloggen auf den Server rumliegen. Und damit man diese passphrase bei mehrmaligem Login in den Server nacheinander nicht immer wieder eingeben muß, gibts den ssh-agent o.ä.
 
Mein Plan:
OpenVPN-Tunnel nur für mich zwischen Server und Desktop
=> SSH von außen komplett verbieten und dann nurnoch über diesen privaten Tunnel zulassen

Dabei fällt mir gerade ein:
Wie ist das eigentlich mit OpenVPN?
1. Wenn ich mehrere VPN-Server auf meinem Server laufen lasse, werden dann automatisch mehrere tap-Devices für jeden Server erstellt?
2. Wie weit kann/muss ich den Server absichern, wenn ich ein zweites Netz nur als VPN zum Verbinden mehrerer Clients verwenden will? Wie kann ich da den Server "aus dem Netz nehmen"? Reicht es da, alle Verbindungen des entsprechenden tap-Devices zu blocken oder bricht mir dadurch das VPN zusammen?

Außerdem: Wie bekomme ich die Ausgabe des Openvpn-Daemons bei Bedarf in mein Terminal?
 
Es wird ein tun/tap-device pro daemon-Instanz erstellt. Es reicht die Services einfach nur auf dem öffentlichen Interface(oder der IP) lauschen zu lassen und ggf. noch auf loopback. Wenn kein Dienst auf den tap-Interfaces einen Socket öffnet, gibt es auch keine Angriffsfläche.

Mit iptables auf dem tap-interface traffic zu droppen oder zu rejecten, würde ich lassen. Das kann ggf. das VPN nicht mehr lauffähig machen.

Man kann bei Openvpn die option clientoclient setzen. Damit erlaubt man Verbindungen zwischen CLients, ich weiß allerdings nicht, ob der Traffic dann durch die FORWARD-Queue läuft, oder nicht.

Ausgabe auf dem Terminal bekommst du mit tail -f <logfile der daemon-instanz>.

Ein logfile musst du in der Konfigurationsdatei des daemons per hand setzen. Automatisch tut der daemon das nicht.
 
Zuletzt bearbeitet:
Zurück
Oben