[linux-l] iptables (Eheamals: Fedora3 Firewall)

[Volker Grabsch]

On Tue, Nov 15, 2005 at 02:09:09AM +0100, Olaf Radicke wrote:
> Am Dienstag, 15. November 2005 00:35 schrieb Volker Grabsch:
> > On Mon, Nov 14, 2005 at 10:11:03PM +0100, Olaf Radicke wrote:
> [...]
> > Dass das alles in /etc/services steht, ist für mich
> > Netzwerk-Grundwissen. Genauso elementar wie z.B. /etc/hosts.
> 
> Das ist Linux (Unix) speziefisch. Unter Windows wird es kein /etc/services 
> geben.
> 
> [...]
> > > Z.Z. sie mein sh-Skript so aus:
> > > <ipt-sh-skript>
> > > #!/bin/sh
> > > iptables -F
> > >
> > > iptables -A INPUT -p udp --sport 53 -j ACCEPT # DNS
> > > iptables -A INPUT -p udp --dport 53 -j ACCEPT # DNS
> > > iptables -A INPUT -p tcp --dport 443 -j ACCEPT # https
> > > iptables -A INPUT -p tcp --dport 80 -j ACCEPT # http
> > > iptables -A INPUT -p tcp --dport 22 -j ACCEPT # ssh
> > > iptables -A INPUT -p tcp --dport 25 -j ACCEPT # smtp
> > >
> > > iptables -P INPUT DROP
> > > iptables -P OUTPUT ACCEPT
> > > #sleep 30
> > >
> > > #iptables -F INPUT
> > > #iptables -P INPUT ACCEPT
> > > </ipt-sh-skript>
> > >
> > > Tut aber nicht das was ich erwarte. Wenn ich das ausführe komm ich nicht
> > > mehr raus (kein Ping, http, etc zu anderen Rechnern). Weiß der Teufel
> > > warum.
> >
> > Das liegt einfach daran, weil du die Antwort-Pakete, die dein System
> > nach draußen zurück schickt, ebenfalls blockierst.
> 
> Dann weiß ich nicht warum ich dann noch eine Zeile
> -P OUTPUT ACCEPT
> brauche.

Weil das nichts damit zu tun hat. Den INPUT-Chain durchlaufen *alle*
Pakete, egal ob sie von "außen" oder "innen" kommen.

Generell willst du mit dem OUTPUT-Chain nichts zu tun haben, das ist
für spezielle Sachen. Ich hab's noch nie wirklich gebraucht. Wenn
du dort sowieso nichts sperrst, kannst du die Zeile natürlich weghauen,
weil "ACCEPT" ja sowieso die Default-Einstellung von iptables ist.
Kurz: Ignorier das einfach.

> > Woran du scheiterst sind keine "Kernel-Details", sondern
> > "Netzwerk-Details".
> Auserhalb von Linux gibt es kein iptables.

Mag sein. Aber dass Netzwerk-Pakete in *beide* Richtungen fließen,
und dass die Firewall nunmal ein *Packet*-Filter Filter ist, das sollte
man wissen. Das hatte ich mit "Grundlagen" gemeint.

Dass man die Sachen nicht nur auf Paket-Ebene, sondern auf Ebene
von *Verbindungen* betrachten kann, dafür ist das Connection-Tracking
da.

> > Also eine früher sehr gängige, heutzutage eher als quick&dirty
> > bezeichnete Lösung ist folgende:
> 
> Also in der Programmierung steht "quick&dirty" für Code den keine Sau mehr 
> versteht aber der funktioniert und den deshalb niemand mehr anfassen will. 
> Na, dann fühle ich mich bestätigt.

Nein, nein, im Gegentei. Der Code ist doch noch gut lesbar. Er ist halt
nur nicht 100%ig sauber. "quick & dirty" bezog sich auf die Technik
dahinter, dass nämlich kein Connection-Tracking benutzt wird, sondern
die Sperrung eher auf "Nebeneffekte" beruht.

> > #!/bin/sh
> > iptables -F
> >
> > iptables -A INPUT -p udp --sport 53 -j ACCEPT # DNS
> > iptables -A INPUT -p udp --dport 53 -j ACCEPT # DNS
> >
> > iptables -A INPUT -p tcp ! --syn -j ACCEPT
> > iptables -A INPUT -p tcp --syn --dport 443 -j ACCEPT # https
> > iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT # http
> > iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT # ssh
> > iptables -A INPUT -p tcp --syn --dport 25 -j ACCEPT # smtp
> >
> > iptables -P INPUT DROP
> 
> Die Zeile ist ja dann eigentlich überflüssig, weil wir ja oben schon alle 
> Ports aufgerissen haben (außer für syn's).

Falsch!

"außer für syn's" ist genau der springende Punkt.

Wurde man die letzte Regel entfernen (also alles durchlassen), kämen
auch SYN-Pakete an die anderen Ports ran, und man könnte entsprechend
zu allen Ports TCP-Verbindungen aufbauen - kurz: Die Firewall wäre
komplett unwirksam, und dein Server offen wie ein Scheunentor.


Ich merke schon, da gibt es einige grundsätzlich falsche Vorstellungen
über die Funktionsweise der Firewall bei dir. Ich kenne das, aber damals
habe ich irgendwas gutes gelesen (weiß leider nicht mehr, was), und dann
war mir klar, wierum der Hase läuft. Anfangs (mit ipchains) bin ich über
die selben Fallen gestolpert wie du.

Ein gutes Tutorial sollte vielleicht nicht alles lang und breit
erklären, aber es einem ermöglichen, diese Fallstricke gut zu umschiffen.
Dennoch möchte ich an dieser Stelle erwähnen, dass z.B. "netconf"
(aus "linuxconf") oder YaST  an der Stelle zwar "Vereinfachungen"
vornehmen, aber dadurch noch schlimmere Fallstricke provozieren.

Ganz schlimm finde ich, dass sie vorallem eine falsche Vorstellung von
der Sache geben, die einem ab einen gewissen Punkt daran hintert,
bestimmte (kompliziertere) Probleme zu verstehen, geschweige denn zu
lösen.


> [...]
> > Das ist wiegesagt die "alte Schule", heutzutage macht man das
> > wesentlich sauberer via Connection Tracking, das ich mir nochmal
> > ansehen werde.
> 
> Noch nichts von gehört.
> 
> Die...
>  /etc/network/if-pre-up.d/000iptables
> ...gibt es unter Fedora übrigens nicht. Soll ich es in die 
> /etc/sysconfig/iptables
> abkippen?

Ich glaube, das ist keine gute Idee.

Zu Fedora kann ich da ATM nichts weiter sagen. Auf jeden Fall kannst
du's in /etc/init.d/ reinhauen. :-)
Sorge einfach dafür, dass es vor den Netzwerk-Devices gestartet wird.


Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR