iptables für Server brauchbar?

[PierreS]

Hallo,

ich hatte bisher noch nichts mit iptables zu tun. Nach einem Wechsel von einem vServer zu einem dedizierten habe ich anhand eines HowTos folgende Regeln erstellt:


iptables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
1046 131K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
85 13284 interfaces all -- * * 0.0.0.0/0 0.0.0.0/0
78 12816 open all -- * * 0.0.0.0/0 0.0.0.0/0
2 112 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
30 10020 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 1067 packets, 637K bytes)
pkts bytes target prot opt in out source destination

Chain interfaces (1 references)
pkts bytes target prot opt in out source destination
7 468 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0

Chain open (1 references)
pkts bytes target prot opt in out source destination
1 60 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:512
26 1484 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
1 60 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
17 1020 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:465
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5222
1 60 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5223
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5269


Ich habe bisher leider hauptsächlich Howtos für Clients oder HomeServer gefunden. Sind die Regeln oben sinnvoll und vor allem nicht gefährlich?

Erreichbar soll sein:
ssh (512)
http(s)
smtp(s)
imap(s)
jabber

[Roger Wilco]

Was erhoffst du dir von dem Paketfilter? Wenn nur die Server für die von dir genannten Dienste laufen ist der Paketfilter überflüssig.
Er fügt deinem System vielmehr eine weitere Komponente hinzu, die ausnutzbare Sicherheitslücken enthalten könnte und durch die ein Angreifer ggf. Zugriff auf dein System erhält.

[PierreS]

Es läuft noch portmap auf port 111, dem ich nicht ganz traue. Den kann ich leider nicht abschalten, da er von courier (indirekt über fam) gebraucht wird.

[Roger Wilco]

Du solltest den Zugriff auf Portmap "sauber" einschränken:
man 8 portmap
man 5 hosts_access

...oder einen IMAP-Server nutzen, der IMAP IDLE ohne FAM implementiert, z. B. Cyrus IMAP. ;)

[PierreS]

Ja, tcp_wrapper nutze ich ja:


[root@server pierre]# cat /etc/hosts.allow
#
# /etc/hosts.allow
#

sshd:ALL
httpd:ALL

# End of file
[root@server pierre]# cat /etc/hosts.deny
#
# /etc/hosts.deny
#

ALL: ALL: DENY

# End of file


Dennoch ist der port offen. Ob das alleine schon ein Risiko ist, weiß ich nicht. Warum sich portmap nicht auf localhost beschränken läßt und wozu ich das überhaupt brauche, weiß ich ebenfalls nicht. ;-)

Du meinst also: besser keine iptables einsetzen?

PS: Und nein, ich habe erstmal keine Lust auf einen anderen imap-server zu migrieren; wo doch courier so schön aus einem Guß ist.

[caspartroy]

so ganz sinnlos ist ein paketfilter nicht... sollte jemand (ohne root-rechte ) ein einbruch gelungen sein, könnte der filter immerhin verhindern, dass derjenige sich auf unbenutzten ports irgendwelche (bösen) dienste einrichtet

[PierreS]

OK, da sagt wirklich jeder was anderes. ;-) Wären denn o.g. Regeln in Ordnung?

[Dukel]

Ich hoffe du hast verstanden, was du da konfigurirt hast. Es bringt nichts ein Howto abzutippen, wenn es nicht zum eigenen Szenario / eigenen Anforderungen passt.
Wenn du es verstanden hast, kannst du selber sagen, ob es was bringt.

[PierreS]

Ich bin mir recht sicher, daß ich weiß, was die iptables-Befehle tun. Das hilft mir aber nicht dabei festzustellen, ob das reicht oder sinnvoll ist.

[Thorashh]

Die Regeln sind nicht nur für einen Server völlig ungeeignet.

Du erlaubst viel zu viel. Deine Regeln lassen einfach *jede* Kommunikation zu den offenen Ports zu. Du erzwingst nicht mal korrekte TCP-Pakete.

Du erlaubst zwar alle bestehenden "RELATED,ESTABLISHED" Verbindungen, aber für den Verbindungsaufbau verwendest Du das Connection-tracking nicht.

Der REJECT mit "reject-with tcp-reset" ist geradezu eine Vorlage für einen DOS Angriff. Da bei einem Reset der vermeintliche Zielhost alle Verbindungen abbricht, lassen sich mit gefälschten Sourceadressen beliebige Verbindungen einfach unterbrechen.

Du solltest standardmäßig alles Chains DROPen und dann über eigene Regeln die notwendigen Verbindungen zulassen.

TCP Verbindungen kannst Du am einfachsten über das Connection-Tracking zulassen.

Beispiel:

# Alle weiteren Pakete einer bestehenden Verbindung erlauben
-A open -m state --state ESTABLISHED,RELATED -j ACCEPT
# Verbindungsaufbau für https erlauben
-A open -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
# Alle anderen Verbindungen verbieten
-A open -j REJECT --reject-with icmp-host-prohibited

Dann fehlen noch alle einfachen Regeln gegen spoofing. Du solltest alle Pakete von Privaten Adressen (192.168.0.0, etc.) und Pakete von der eigenen Adresse verbieten. um nur mal ein paar Beispiele zu bringen.

Für jeden Dienst den Du anbietest, gibt es bekannte Exploits, die häufig ausprobiert werden. Die meisten lassen sich mit geeigneten Rules zumindestens abschwächen.

[PierreS]

Vielen Dank für die ausführliche Antwort. Ich denke ich werde mich also mal nach Connection-Tracking und Spoofing erkundigen.

Warum sollte es für alle meine angebotenen Dienste Exploits geben? Setze eigentlich von allen Servern die neueste Version ein.