Hallo zusammen,
Penetrant, wie ich nun mal bin, melde ich mich noch mal in um Unterstützung heischender Weise. Mein Endziel ist Fail2ban, und es liefe auch schon, wenn ich es nur angeschaltet hätte. Vorher brauche ich noch Eure professionelle Meinung zu meiner aktuellen, entschlackten und überarbeiteten iptables Konfiguration, dessen Basis dereinst von Plesk gesetzt wurde. Da ich den Server auch ohne iptables weitgehend abgesichert habe, schwebt mir ein sehr schlanker FW vor, dessen Regelsatz durch fail2ban noch „teuer“ genug werden wird (ich habe nur einen mageren vServer). Vielleicht entdeckt Ihr ja Dinge, die unbedingt mit rein sollten, oder gar Überflüssiges oder besser zu Lösendes. Ich poste den wesentlichen Teil des (kommentierten) Scripts – und nerv dann mit meinen Fragen:
1.) Im Kopf der Datei setze ich Default Policies (alle auf DROP). Dann kommt mein Regelwerk und dahinter, bei mir als „# Leftover rules“ gekennzeichnet, ein erneutes DROP von INPUT und FORWARD. Ist dies nicht redundant und damit überflüssig? Bei OUTPUT macht es m.E. Sinn, da es von der Default Policy abweicht. Kann ich die für INPUT und FORWARD am Ende raus nehmen?
2) Zum SYN packets check habe ich derzeit:
ich denke, ein REJECT ist „teurer“ als ein DROP:
Unter dem Aspekt „Flooding“, wäre da ein DROP nicht angebrachter? Oder den DROP noch vor das REJECT gesetzt, eben nur für NEW Verbindungen?
3) Mein ssh Port ist weit, weit weg gelegt und mit Key und ellenlanger Passphrase gesichert und kein root kommt drüber rein. Ich habe (hier) gelernt, dass weitgehende Sicherheit immer erfordert, eigene Ansätze unter bösesten Aspekten und von „außen“ zu betrachten. Wäre ich ein schlechter Mensch, so hätte ich wohl am meisten Interesse an einem ssh Zugang. Also gebe ich allen, die einen wollen, was sie gern hätten:
Die Frage ist nur: Schieße ich mir damit selbst ins Knie? Nmap zeigt diesen Port jetzt in rot (Status closed, Dienst ssh) und impliziert damit, dass es ihn gibt – und das eine Suche an einer anderen Stelle somit überflüssig sein könnte (nicht müsste). Der Status „Closed“ sagt weiter: "Vergiss es hier. Möglicherweise über eine lokale Konsole administriert, was auch immer – auf zu neuen Ufern". Kostet natürlich mehr als gar keine Regel, macht aber Spaß – wie seht Ihr das?
4) Mich beunruhigen die vielen Mailports. Ich nutze Horde Webmail, qmail und Courier. Jede Regel kostet und ich hätte keine Hemmungen, meinen (Web)Mail Nutzern einen bestimmten Zugang aufzuoktruieren. Wie seht Ihr das? Kann da was weg?
Port 106 macht mir noch Gedanken. Im Original Plesk Setup war er offen, und ich verstehe nicht, warum. Eigentlich ist in eine Password Änderung doch nur der localhost involviert. Kann man den Port, ähnlich wie bei MySQL, an den localhost binden, um dann auf die DROP Regel verzichten zu können?
5) ICMP/Ping: Der Plesk Setup erlaubt ICMP Typ 0 und 8. An vielen Stellen wird dazu geraten, generell ein DROP auszuführen – ggf. bei freigegebener statischer IP als Ausnahme. Oder gibt es Gründe, generell Typ 0 und 8 zu bedienen? Z.B. guter Stil oder gutartige Anfragen, so es denn solche gibt.
6) Macht eine Ergänzung um folgendes Sinn, als zusätzliche Syn-flood protection, oder ist dies auf einem vServer nutzlos?
7) Gibt es eine OUTPUT Regel, ohne die man nicht leben sollte?
8) Anregungen für weitere zielführende Regeln. Macht ein --limit bei manchen Aktionen Sinn, unter Berücksichtigung des Aufwands für ein zusätzliches Modul?
Wie immer, danke für allen sachdienlichen Hinweise.
Thomas
Penetrant, wie ich nun mal bin, melde ich mich noch mal in um Unterstützung heischender Weise. Mein Endziel ist Fail2ban, und es liefe auch schon, wenn ich es nur angeschaltet hätte. Vorher brauche ich noch Eure professionelle Meinung zu meiner aktuellen, entschlackten und überarbeiteten iptables Konfiguration, dessen Basis dereinst von Plesk gesetzt wurde. Da ich den Server auch ohne iptables weitgehend abgesichert habe, schwebt mir ein sehr schlanker FW vor, dessen Regelsatz durch fail2ban noch „teuer“ genug werden wird (ich habe nur einen mageren vServer). Vielleicht entdeckt Ihr ja Dinge, die unbedingt mit rein sollten, oder gar Überflüssiges oder besser zu Lösendes. Ich poste den wesentlichen Teil des (kommentierten) Scripts – und nerv dann mit meinen Fragen:
Code:
# Initialize/Reset whole configuration
# Flush/delete all rules in every chain
/sbin/iptables -F
# delete every non-builtin chain in the table
/sbin/iptables -X
# Zero the packet and byte counters in all chains
/sbin/iptables -Z
# Set Default Policies
# Default policy for INPUT chain
/sbin/iptables -P INPUT DROP
# Allowing already established Sessions to receive traffic
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Reject all packets with inproper syn
/sbin/iptables -A INPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset
# Drop all invalid packets
/sbin/iptables -A INPUT -m state --state INVALID -j DROP
# Default policy for OUTPUT chain
/sbin/iptables -P OUTPUT DROP
# Allowing already established Sessions to output traffic
/sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Reject output of all packets with inproper syn
/sbin/iptables -A OUTPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset
# Drop all invalid output packets
/sbin/iptables -A OUTPUT -m state --state INVALID -j DROP
# Default policy for FORWARD chain
/sbin/iptables -P FORWARD DROP
/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -p tcp ! --syn -j REJECT --reject-with tcp-reset
/sbin/iptables -A FORWARD -m state --state INVALID -j DROP
# Accept everything from local loopback
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
/sbin/iptables -A FORWARD -i lo -o lo -j ACCEPT
# Trusted IP's (Home, Office..)
# /sbin/iptables -A INPUT -s my.stat.ip.addr -j ACCEPT
# mangle Table for packet alterations
/sbin/iptables -t mangle -F
/sbin/iptables -t mangle -X
/sbin/iptables -t mangle -Z
/sbin/iptables -t mangle -P PREROUTING ACCEPT
/sbin/iptables -t mangle -P OUTPUT ACCEPT
/sbin/iptables -t mangle -P INPUT ACCEPT
/sbin/iptables -t mangle -P FORWARD ACCEPT
/sbin/iptables -t mangle -P POSTROUTING ACCEPT
# nat table is consulted when a packet creates a new connection
/sbin/iptables -t nat -F
/sbin/iptables -t nat -X
/sbin/iptables -t nat -Z
/sbin/iptables -t nat -P PREROUTING ACCEPT
/sbin/iptables -t nat -P OUTPUT ACCEPT
/sbin/iptables -t nat -P POSTROUTING ACCEPT
# General Web/File Services
# Allow all incoming traffic on the non-default SSH port (myMovPort)
/sbin/iptables -A INPUT -p tcp --dport "myMovPort" -j ACCEPT
# Allow plesk-https (Port 8443)
/sbin/iptables -A INPUT -p tcp --dport 8443 -j ACCEPT
# Allow plesk-http (Port 8880)
/sbin/iptables -A INPUT -p tcp --dport 8880 -j ACCEPT
# Allow all incoming web traffic (Port 80 and 443)
/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Simulate filtered (non-existing) ssh port 22 to confuse the rotten
/sbin/iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with tcp-reset
# Mail message submission (Port 587, qmail smtpd)
/sbin/iptables -A INPUT -p tcp --dport 587 -j ACCEPT
# smtp (Port 25): "Filtered" even w/o FW because of checked "Nachrichtenübermittlung aktivieren", which limits smtp to Port 587
/sbin/iptables -A INPUT -p tcp --dport 25 -j ACCEPT
# smtps (Port 465, qmail)
/sbin/iptables -A INPUT -p tcp --dport 465 -j ACCEPT
# pop3 (Port 110: Courier pop3d)
/sbin/iptables -A INPUT -p tcp --dport 110 -j ACCEPT
# pop3s (Port 995, Courier pop3s)
/sbin/iptables -A INPUT -p tcp --dport 995 -j ACCEPT
# imap (Port 143, Courier imap)
/sbin/iptables -A INPUT -p tcp --dport 143 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 993 -j ACCEPT
# Block poppassd (Port 106, needed for pop-users password change by localhost only - to do: check if binding to localhost can be done elsewhere )
/sbin/iptables -A INPUT -p tcp --dport 106 -j DROP
# Needed by OpenVPN/Parallels Plesk Panel VPN
/sbin/iptables -A INPUT -p udp --dport 1194 -j ACCEPT
# DNS Ports
/sbin/iptables -A INPUT -p udp --dport 53 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 53 -j ACCEPT
# Allow ICMP packets (to do: limit, see next 2 lines)
# /sbin/iptables -A INPUT -p icmp -m limit --limit 10/second -j ACCEPT
# /sbin/iptables -A INPUT -p icmp -j DROP
/sbin/iptables -A INPUT -p icmp --icmp-type 8/0 -j ACCEPT
# Leftover rules
/sbin/iptables -A INPUT -j DROP
/sbin/iptables -A OUTPUT -j ACCEPT
/sbin/iptables -A FORWARD -j DROP1.) Im Kopf der Datei setze ich Default Policies (alle auf DROP). Dann kommt mein Regelwerk und dahinter, bei mir als „# Leftover rules“ gekennzeichnet, ein erneutes DROP von INPUT und FORWARD. Ist dies nicht redundant und damit überflüssig? Bei OUTPUT macht es m.E. Sinn, da es von der Default Policy abweicht. Kann ich die für INPUT und FORWARD am Ende raus nehmen?
2) Zum SYN packets check habe ich derzeit:
Code:
# Reject all packets with inproper syn
/sbin/iptables -A INPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset
Code:
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP3) Mein ssh Port ist weit, weit weg gelegt und mit Key und ellenlanger Passphrase gesichert und kein root kommt drüber rein. Ich habe (hier) gelernt, dass weitgehende Sicherheit immer erfordert, eigene Ansätze unter bösesten Aspekten und von „außen“ zu betrachten. Wäre ich ein schlechter Mensch, so hätte ich wohl am meisten Interesse an einem ssh Zugang. Also gebe ich allen, die einen wollen, was sie gern hätten:
Code:
# Simulate filtered (non-existing) ssh port 22 to confuse the rotten
/sbin/iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with tcp-reset4) Mich beunruhigen die vielen Mailports. Ich nutze Horde Webmail, qmail und Courier. Jede Regel kostet und ich hätte keine Hemmungen, meinen (Web)Mail Nutzern einen bestimmten Zugang aufzuoktruieren. Wie seht Ihr das? Kann da was weg?
Port 106 macht mir noch Gedanken. Im Original Plesk Setup war er offen, und ich verstehe nicht, warum. Eigentlich ist in eine Password Änderung doch nur der localhost involviert. Kann man den Port, ähnlich wie bei MySQL, an den localhost binden, um dann auf die DROP Regel verzichten zu können?
5) ICMP/Ping: Der Plesk Setup erlaubt ICMP Typ 0 und 8. An vielen Stellen wird dazu geraten, generell ein DROP auszuführen – ggf. bei freigegebener statischer IP als Ausnahme. Oder gibt es Gründe, generell Typ 0 und 8 zu bedienen? Z.B. guter Stil oder gutartige Anfragen, so es denn solche gibt.
6) Macht eine Ergänzung um folgendes Sinn, als zusätzliche Syn-flood protection, oder ist dies auf einem vServer nutzlos?
Code:
# Drop all fragmented packets
/sbin/iptables -A INPUT -f -j DROP
# Drop malformed XMAS packets
/sbin/iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
#Drop all NULL packets
/sbin/iptables -A INPIT -p tcp --tcp-flags ALL NONE -j DROP7) Gibt es eine OUTPUT Regel, ohne die man nicht leben sollte?
8) Anregungen für weitere zielführende Regeln. Macht ein --limit bei manchen Aktionen Sinn, unter Berücksichtigung des Aufwands für ein zusätzliches Modul?
Wie immer, danke für allen sachdienlichen Hinweise.
Thomas
Last edited by a moderator: