iptables Script macht IMAP langsam

Hallo,

ich habe mir ein kleines Script geschrieben mit dem ich meine iptables Firewall konfiguriere. Soweit läuft das Script auch, nur funktioniert der Zugriff mittels IMAP dann nicht mehr richtig. Es dauert ewig und dann sagt mir Evolution es kann keine Verbindung herstellen. Anbei mal das Script. Was habe ich falsch gemacht, bzw. was könnte man besser machen?

Greifst du von deinem Firewallrechner auf imap-, pop3- und smtpserver zu?

Ich frage deshalb weil alles über die INPUT- und OUTPUT-Ketten läuft und in deinem Skript etwas von einer Routerkonfiguration steht. Wenn du von einem Rechner vor der Firewall ins Netz zugreifen willst, solltest du die FORWARDING Chain benutzen.

Btw, das aktive ftp solltest du besser ganz auschalten, beim passiven solltest du das ftp-conntracking Modul benutzen.

Außerdem nutzt du iptables statisch und öffnest deine Firewall damit. Vergleiche dein Skript einmal hiermit:
http://www.linux-club.de/viewtopic.php?t=21303

etwas tiefer im Thread steht ein firewallskript für einen Router.

mfG
gaw

Hallo,

danke schonmal für die Antwort. Also der Rechner auf dem ich das Script laufen habe, ist ein Web/Mail/FTP/wasichhaltwill Server. Deshalb sind die Regeln schon soweit an der richtigen Stelle. Der Routingabschnitt ist nur drinnen, damit ich den Überblick behalte weshalb ich welche Einstellung gemacht habe.

Dein Script habe ich mir angesehen, aber ich gebe zu, ich blicke (noch) nicht ganz durch und solange ich das nicht tue will ich es nicht 1zu1 kopieren, sonst lerne ich ja nichts draus.

Was ich nicht ganz verstanden habe, ist warum ich aktiv FTP abschalten sollte. Ich ging immer davon aus, dass das für den Server besser sei, da somit nur 2 fest definierte Ports (20 und 21) verwendet werden und ich somit keine ganze Range dafür freigeben muss.

Vielleicht solltest du in deinem Skript dann auch Server- und nicht Routerkonfiguration schreiben, denn ein Router ist das offensichtlich nicht.

Was das Durchblicken angeht, da helfen Tutorials oder Bücher über TCP/IP, denn da hapert es meistens, wenn es um Firewallprobleme mit iptables geht. Du musst die Protokolle und die Vorgänge beim Verbindungsaufbau kennen (Stichworte u.a. tcp, udp, ports sockets und tcp 3-Wege Handschlag). iptables bietet zum Beispiel die Möglichkeiten stateful inspection filtering zu betreiben, in den meisten Fällen wendest du aber statisches Filtern an. Nehmen wir zum Beispiel das Regelpaar:
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT;
$IPTABLES -A OUTPUT -p tcp --sport 80 -j ACCEPT;

aus deinem Skript, dass Zugriff auf einem Webserver erlauben soll. Das funktioniert war, aber mit deinen Regeln reißt du deine Firewall sehr weit auf. Alles was will darf über den Port 80 rein und raus, ganz gleich wieso und warum. So kann ein x-beliebiges Programm unter Nichtrootrechten von der Firewall aus Verbindungen aufnehmen. Ebenso können alle den Webserver kontaktieren, letzeres mag vielleicht sogar Absicht sein.

Was brauchst du aber um einen Webserver laufen zu lassen?
1. Ein Client musst die Verbindung aufnehmen, also
muss er eine neue Verbindung einleiten dürfen, ebson muß er danach weitere Anfragen und Bestätigungen schicken dürfen. Der Zielport ist dann 80, der Quellport liegt zwischen 1024:65535.

2. Die Zieladresse (oder Zielname) dieses Client ist der Webserver, andere Zieladressen müssen nicht berücksichtig werden.

3. Die Schnittstelle über die Pakete hereinkommen, Pakete über andere Schnittstellen sollten nicht berücksichtig werden.

Dann sollte eine Regel für die ankommenden Pakete in etwa so aussehen:

$IPTABLES -A INPUT -i $INTERFACE -d $WEBSERVER -p tcp --dport 80 --sport 1024:65535 m state NEW,ESTABLISHED,RELATED -j ACCEPT

wobei $INTERFACE so etwas wie eth0, eth1 oder ath1 sein kann, eben die Bezeichnung der Netzwerkkarte. $WEBSERVER enthält die IP-Adresse des Webservers oder einen gültigen Domainnamen.

Nun gibt es zwei unterschiedliche Strategien, im einen Fall wird allen Paketen die zu bestehenden Verbinungen gehören das Passieren gestattet. Iim zweiten Fall wird nur den Paketen die zu bestimmten Verbindung gehören die Rückkehr gestattet. Ich bevorzuge die zweite Strategie, die entsprechende Regel lautet also:

$IPTABLES -A OUTPUT -o $INTERFACE -s $WEBSERVER -p tcp --dport 80 --sport 1024:65535 m state ESTABLISHED,RELATED -j ACCEPT

Hiermit werden die Anzahl der Möglichkeiten gegenüber dem statischen Filtern schon erheblich reduziert. Alle anderen Pakete die nicht zu dieser gewollten Kommunikation gehören werden so weit wie irgendmöglich ausgeschlossen.

Was den passiven und aktiven FTP-Transport betrifft, so lässt du ja alles durch was irgendwo eine 21 als Port im TCP-Header hat. Ein spezifische Einstellung ist das auf keinen Fall, so dass der Unterschied bei deiner Konfiguration völlig unerheblich ist. In Wirklichkeit öffnest du also keine zwei Ports sondern 65535 Ports, wenn der Quellport 21 sind. Wenn ich ein Programm schreibe dass irgendeinen Zielport avisiert , muss ich nur daraufachten, dass dieses Programm den Quellport 21 im TCP-Header einträgt und ich kann deine Firewall passieren, als ob diese gar nicht existiert. Mit anderen Worten, du hast durch diese Regel nicht den Port 21 geöffnet sondern 65535 Ports.

Leider unterliegen viele diesen Irrtum, weil sie nicht genau wissen, was Ports eigentlich sind. Sie denken dabei an Löchern oder andere obskure Dinge und weniger an Multiplexing. Besser du stellst dir das wie Bürobriefe vor. Die haben oft eine Zeile mit dem Feld Ihr Zeichen, Unser Zeichen. Im Grunde sind Portnummern nichts anderes als solche Adressierungen die ein Multiplexing der Kommunikation erlauben, nur dass sie über diese Nummern keine Bürovorgänge adressieren die eine Sekretärin dann in Akten (auch eine Art Protokollstapel) ablegt, sondern Prozesse adressiert die vom Betriebssystem an den Prozess weitergegeben werden der für diesen Port zuständig ist (umgangssprachlich an diesem Port lauscht).

Ein TCP- oder UDP-Paket verfügt also immer über zwei Portnummern ebenso wie ein Geschäftsbrief über zwei Aktenzeichen verfügt (verfügen sollte).

Der Zielport adressiert im Grunde den Serverprozess, also der Port 80 addressiert gewöhnlich einen Webserver wie den Apache. Der Quellport liegt dabei zwischen 1024 und 65535 und wird von dem Rechner auf dem der Webbrowser läuft gewählt in dem eine zufällige Nummer überhalb von 1023 die nicht in der Datei /etc/services freigeschaltet ist gewählt wird. Daher muss der Server alle Pakete reinlassen, dessen Zielport 80 ist und dessen Quellport zwischen 1024 und 65535 liegt. Das müssen Pakete sein, die neue Verbindungen initialisieren und solche die zu bestehenden Kommunikationsstängen gehören.

Es besteht aber kein Grund, warum Pakete reinkommen dürfen die einen Quellport unter 1024 haben. Ebenso besteht bei deiner Ausgangslage kein Grund, Pakete reinzulassen, die eine andere IP-Adresse im IP-Header aufweisen, als die deines Webservers.

Noch viel weniger ist es einzusehen, dass andere deinen Rechner zu ihren Zwecken mißbrauchen weil du dem Rechner erlaubst von sich aus neue Verbindungen einzugehen. Genau dass ist aber möglich, wenn du statisches Filtern benutzt.

Statisches Filtern ist quasi schon fast obsolet. Um bei den Vergleichen zu bleiben, es ist so als wenn in deiner Wohngegend vermehrt Einbrüche ablaufen und du zum Schutz einen Jägerzaun um dein Grundstück ziehst. Ein statischer Paketfilter ist vielleicht besser als keiner, weil er ganz unbedarfte Kiddies abhält, ebenso wie der Jägerzaun die Hemmschwelle eines potentiellen Zufallseinbrechers erhöht darüberzusteigen. Mit iptables besitzt du aber die Möglichkeit stateful inspection zu betreiben. Zusammen mit den anderen einschränkenden Parametern kannst du also die erlaubten Pakete ziemlich gut auf die Kommunikation beschränken und es ist ziemlich schwierig Pakete daran vorbeizuschmuggeln. Im Vergleich nimmt sich das Filtern mit stateful inspection (einschließlich der Verwednung einschränkender Parameter) gegenüber dem statischen Filtern (so wie du es in deinem Skript praktizierst) wie eine 5m hohe glatte Betonwand gegenüber besagten Jägerzaun aus.

Angreifer nutzen dann eher Schwachstellen der lauschenden Serverprozesse, davor zu schützen ist auch nicht Aufgabe einer Firewall. Das kann sie ebensowenig leisten, wie die Betonwand davor schützen kann, dass die dicke Marie im Zuge eines vorzeitigen Beendigung des staatlichen Hotelaufenthalt ihres angetrauten Ehegatten, Tresor-Ede mit spitzen Fingern einzuleiten gedenkt, indem sie den Schlüssel vom Seiteneingang aus der Jackentasche des Gefängniswärtes entwendet, wenn dieser bei einem seiner regelmässigen Besuche im einschlägig bekannten Etablishements besagter Marie die Jacke - über den Stuhl hängend - während anstregender sportlicher Leibesübungen kurzzeitig unbeaufsichtig lassen sollte.

Beim aktiven und passiven FTP ist der Transport noch viel komplexer, weil die Kommukation über getrennte Verbindungen läuft. Beides sicher zu konfigurieren ist ziemlich schwierig. Aus Sicht der Clients ist aber passives FTP sicherer und sollte soweit es überhaupt eingesetzt wird mit einem contracking Modul geschehen. Bei mir schalte ich passives FTP über einen Router dynamisch ein, wenn ich es brauche und danach wieder aus, weil es eine Firewall auf Dauer eben etwas unsicherer macht.

Viele Systemadministratoren verbieten den FTP-Transport über eine Firewall ganz und setzen statt dessen auf andere Protokolle.

Da deine Firewall fast ganz offen ist, müsste auch die IMAP Kommunikation laufen, ich vermute einmal, dass es nicht an deinem Paketfilter liegt, wenn dabei irgendetwas nicht hinhaut.


mfG
gaw

Vielen Dank für deine ausführlich und auch eingängigen Erklärungen.
Ich weiß, dass das Script nicht optimal ist - noch nicht - aber man muss ja erstmal irgendwo anfangen und sich das Wissen aneigenen.

gaw schrieb:

Vielleicht solltest du in deinem Skript dann auch Server- und nicht Routerkonfiguration schreiben, denn ein Router ist das offensichtlich nicht.

Zum Vergrößern anklicken....

Kuck nochmal nach - ganz oben steht Serverkonfiguration

Das kann sie ebensowenig leisten, wie die Betonwand davor schützen kann, dass die dicke Marie im Zuge eines vorzeitigen Beendigung des staatlichen Hotelaufenthalt ihres angetrauten Ehegatten, Tresor-Ede mit spitzen Fingern einzuleiten gedenkt, indem sie den Schlüssel vom Seiteneingang aus der Jackentasche des Gefängniswärtes entwendet, wenn dieser bei einem seiner regelmässigen Besuche im einschlägig bekannten Etablishements besagter Marie die Jacke - über den Stuhl hängend - während anstregender sportlicher Leibesübungen kurzzeitig unbeaufsichtig lassen sollte.

Zum Vergrößern anklicken....

Also den Absatz rahme ich mir ein

Da deine Firewall fast ganz offen ist, müsste auch die IMAP Kommunikation laufen, ich vermute einmal, dass es nicht an deinem Paketfilter liegt, wenn dabei irgendetwas nicht hinhaut.

Zum Vergrößern anklicken....

Leider nein, es muss definitiv mit der Firewall zusammenhängen. Sobald ich diese abschalte läuft die Kommunikation einwandfrei.

Scheint als hätte ich eine Lösung - irgendwie werden wohl Pakete über die lokale Schnittstelle gedroppt. Ich habe noch zwei Regel hinzugefügt die den Datentransfer über die lokale Schnittstelle erlauben. Jetzt gehts einigermaßen, wenn auch die Geschwindigkeit mit der Mails abgerufen werden immer noch etwas verzögert ist.