Page 1 of 1

Frage IPTables

Posted: 2011-11-25 09:32
by AWOHille
Hallo,

ich bin gerade dabei mich mit iptables auseinanderzusetzen bzw. verstehen zu lernen. Es wäre sehr nett, wenn sich jemand mal meine Regeln anschauen könnte. Meine Frage, sind die soweit korrekt (auch Sicherheitsrelevante Fragen)?
Mein System: Debian6, Apache2, Postfix, Dovecote, Amavis-New, Clamav, spamassassin

Code: Select all

#!/bin/bash


case "$1" in
start)
echo "Starte IP-Paketfilter"

# iptables-Modul
modprobe ip_tables
# Connection-Tracking-Module
modprobe ip_conntrack
# Das Modul ip_conntrack_irc ist erst bei Kerneln >= 2.4.19 verfuegbar
modprobe ip_conntrack_irc
modprobe ip_conntrack_ftp

# Tabelle flushen
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X

# Default-Policies setzen
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# MY_REJECT-Chain
iptables -N MY_REJECT

# MY_REJECT fuellen
iptables -A MY_REJECT -p tcp -j REJECT --reject-with tcp-reset
iptables -A MY_REJECT -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A MY_REJECT -p icmp -j DROP
iptables -A MY_REJECT -j REJECT --reject-with icmp-proto-unreachable

# MY_DROP-Chain
iptables -N MY_DROP
iptables -A MY_DROP -j DROP

# Korrupte Pakete zurueckweisen
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP

# Stealth Scans etc. DROPpen
# Keine Flags gesetzt
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j MY_DROP

# SYN und FIN gesetzt
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j MY_DROP

# SYN und RST gleichzeitig gesetzt
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j MY_DROP

# FIN und RST gleichzeitig gesetzt
iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j MY_DROP

# FIN ohne ACK
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j MY_DROP

# PSH ohne ACK
iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j MY_DROP

# URG ohne ACK
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j MY_DROP

# Loopback-Netzwerk-Kommunikation zulassen
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Connection-Tracking aktivieren
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# HTTP
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 80 -j ACCEPT

# HTTPS
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 443 -j ACCEPT

# SSH
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 22 -j ACCEPT

# SMTP
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -i eth0 -m state --state NEW -p tcp --dport 25 -j ACCEPT

# SMTP Submission
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 587 -j ACCEPT

# SMTPS
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 465 -j ACCEPT

# POP3
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 110 -j ACCEPT

# POPS
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 995 -j ACCEPT

# IMAP
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 143 -j ACCEPT

# IMAPS
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 993 -j ACCEPT

# ICMP
iptables -A INPUT -p icmp --icmp-type ping -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type ping -j ACCEPT


# Default-Policies mit REJECT
#iptables -A INPUT -j MY_REJECT
#iptables -A OUTPUT -j MY_REJECT

# Max. 500/Sekunde (5/Jiffie) senden
echo 5 > /proc/sys/net/ipv4/icmp_ratelimit

# Speicherallozierung und -timing für IP-De/-Fragmentierung
echo 262144 > /proc/sys/net/ipv4/ipfrag_high_thresh
echo 196608 > /proc/sys/net/ipv4/ipfrag_low_thresh
echo 30 > /proc/sys/net/ipv4/ipfrag_time

# TCP-FIN-Timeout zum Schutz vor DoS-Attacken setzen
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

# Maximal 3 Antworten auf ein TCP-SYN
echo 3 > /proc/sys/net/ipv4/tcp_retries1

# TCP-Pakete maximal 15x wiederholen
echo 15 > /proc/sys/net/ipv4/tcp_retries2

;;

stop)
echo "Stoppe IP-Paketfilter"
# Tabelle flushen
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X
# Default-Policies setzen
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
;;

status)
echo "Tabelle filter"
iptables -L -vn
echo "Tabelle nat"
iptables -t nat -L -vn
echo "Tabelle mangle"
iptables -t mangle -L -vn
;;

*)
echo "Fehlerhafter Aufruf"
echo "Syntax: $0 {start|stop|status}"
exit 1
;;

esac
Gruß Hille

Re: Frage IPTables

Posted: 2011-11-27 14:04
by daemotron
Zwei Anmerkungen:

1. Warum verwendest Du DROP anstelle von REJECT?
2. Was für einen Sicherheitsgewinn willst Du denn erreichen? Also konkret: Welche Angriffe willst Du mit iptables unterbinden?

Re: Frage IPTables

Posted: 2011-11-29 13:25
by rudelgurke
Ähm - ist das Script aus irgendeiner Quelle ? Wenn Dovecot etc. laufen, läuft da auch POP3 oder wird nur IMAP verwendet - oder andersrum ?

Generell macht es ohnehin wenig Sinn Ports zu blocken auf denen nichts lauscht.

Re: Frage IPTables

Posted: 2011-12-02 15:22
by AWOHille
daemotron wrote:Zwei Anmerkungen:

1. Warum verwendest Du DROP anstelle von REJECT?
2. Was für einen Sicherheitsgewinn willst Du denn erreichen? Also konkret: Welche Angriffe willst Du mit iptables unterbinden?

zu 1. Ja, die saubere Lösung wäre sicher per REJECT eine Rückmeldung an den entfernten Host zu senden.

zu 2. Ob eine Firewall notwendig ist oder nicht, bin ich mittlerweile auch ins grübeln gekommen. Normalerweise ist ja ein Port generell geschlossen, wenn kein Dienst lauscht. Was ich sicher mal testen werden, ist das Port Knocking, um den SSH Port zu verbergen. Persönlich denke ich mal, das dies ein kleiner Sicherheitsgewinn zum Thema Port-Scan darstellt.

Was ich aber auch für Sinnvoll halte, ist das hier.

http://blog-speedy.de/iptables-lander-b ... ussperren/.

@rudelgurke Nein, das Script habe ich selber zusammengestellt. Natürlich habe ich mich vorher in Foren und Büchern belesen und somit auch einige Regeln übernommen.

Gruß Hille

Re: Frage IPTables

Posted: 2011-12-03 00:00
by ddm3ve
Chinesen kommen aber auch sehr gerne über proxies. Also blöde Idee. Im Sinne von vergeblicher Liebesmühe.

Re: Frage IPTables

Posted: 2011-12-03 14:01
by AWOHille
ddm3ve wrote:Chinesen kommen aber auch sehr gerne über proxies. Also blöde Idee. Im Sinne von vergeblicher Liebesmühe.
Ja, das kann man sehen wie man will. Dieses Script bezieht sich ja nicht nur auf China. Sinnvoll finde ich es aber auch z.B, um generell die besten Spamländer von vornherein zu blocken.

Re: Frage IPTables

Posted: 2011-12-04 02:00
by Joe User
AWOHille wrote:Sinnvoll finde ich es aber auch z.B, um generell die besten Spamländer von vornherein zu blocken.
Also insbesondere USA und halb Europa inklusive Deutschland...
Sorry, aber China gehört ausserhalb Chinas nicht zu den "besten Spamländern".

Re: Frage IPTables

Posted: 2011-12-04 14:08
by ddm3ve
Wenn man spam verhindern will gibt es z.B. policyd_weight was das Spamaufkommen erheblich reduziert.
Ich konnte auf einer einzelnen Adresse, die nur noch zur Kontrolle mails empfängt, das spamaufkommen um über 99% reduzieren.
Bei bis zu 150 Spammails am Tag kommen auf dem Account i.d.R. nur noch 1-2 Spammails / woche durch.
Solange Du allein auf dem Hobel bist, ist es ausschliesslich Dein Problem, wenn ggf. Emails aus anderen Kontinenten etc. nicht ankommen oder grössere Personen Gruppen ausgesperrt werden.
Bei der zunehmenden Knappheit an IP Ressourcen übrigens ändert sich zunehmend öfters der "Nutzer" der IP. Die Regulierungsbehörde entzieht und vergibt IP Blöcke auch mal wieder. Damit ist das fest zurren einer IP Adresse auf einen Regionalen Raum ziemlich schwierig bzw. kurzweilig.

Bist Du nicht mehr allein auf Deinem Host, sondern hostest dort z.B. auch Kunden, würden sich diese durchaus bedanken, wenn denen dicke Aufträge durch die Lappen gehen, weil Sie aus China heraus nicht erreichbar sind.
Zumal IPTables die ungeeignetste Wahl ist um ein Zugriffs, Spam / Mailprobleme zu lösen.


Aber um mal wieder theoretisch an dem Thema an zu knüpfen.
Mit dem Einsatz von IPTables erweiterst Du Deine Angriffsfläche.
Das Risiko wird sich zwar nur gering erhöhen, aber auch das Angriffsrisiko bzw. das Risiko einen erfolgreichen Angriffes erhöht sich.
(In Deinem genannten Fall auf jeden Fall)
Warum erhöht es sich?

Nun Du schliesst ungefähr 1 Milliarde Menschen von Deinem Service aus.
Diese sehen nur IPTables. Werden mit einem Reject nur von IPTables abgefrüstückt.

Die restlichen ca. 3 Milliarden aber werden über IPTables an den jeweiligen Dienst z.B. Port 25 durch gelassen.
Also 2 Softwarekomponenten / Code Stücke, die an er Stelle greifen.
3 Milliarden Menschen könnten sehr theoretisch betrachtet 2 statt nur einen Dienst angreifen und attackieren.
Sei es eine DOS Attacke, DDOS, oder sogar das ausnutzen einer Sicherheitslücke.

Und wie prüft Du, ob Dein Schütz "Sperre alle Chinesen aus" auch funktioniert?
Hart gesagt, implementiert Du etwas, was zwar etwas tun soll, ob es aber vollumfänglich funktioniert, das weisst Du nicht und kannst es ggf. nicht mal überwachen ob der Schutz wirkt.

Re: Frage IPTables

Posted: 2011-12-04 15:03
by ddm3ve
Kleiner Nachtrag:
Damit die Diskussion nicht wieder auf kommt.

Per se sind die Chinesen auch nicht schlimmer als andere Völker. Angriffe kommen von überall her. Die Bedrohung also ziemlich ausgeglichen.

Das gerne genommene Argument an der Stelle, dass iptables eine Schutzanwendung ist und von Haus aus sicher ist.
Und alles andere womöglich nicht, Damals ging es um ssh mit iptables absichern.

Wenn an es nicht beurteilen kann, ob eine Anwendung sicher ist, muss man sich einfach mal die Changelogs ansehen und prüfen in welcher Taktzahlt derzeit Änderungen durch geführt werden. Jede Änderung hat das potential einen unbekannte Bug(s) zu enthalten.

Wenn man es also partu nicht einschätzen kann, dann muss man leider vom Worst Case aus gehen und die betreffenden Produkte bei einer Risiko Bewertung mit dem gleichen Risiko versehen. Also gleicher Bewertung die max. schlechteste im Zweifel.

Es geht also nicht darum nach zu weisen, dass ein Service möglicherweise eine Sicherheitsloch hat, ansonsten gilt er sicher, sondern darum nach zu weisen, dass ein Dienst Sicher ist.
Da man dies aber bei jedem Dienst nachweisen kann, dass er Feher beinhaltet, wird das mit dem "Ist sicher" ziemlich schwierig. Man hat ggf. keinen Fehler gefunden, ja. Aber wirklich sicher?
Also mit Hand ab, wenn man sich verzettelt?
Ich würde das nicht ein gehen.

Nur so als denkanstoss, wie man das Thema Absicherung besser an geht.
Denn getreu dem Motto "Viel hilft Viel". haben sich einige schon selbst ausgesperrt.