On Mon, Jun 12, 2000 at 07:10:10PM +0200, Georg Graf wrote:
> kannst Du kurz sagen, was diese state machine ist?
Also, unter der Voraussetzung, daß ich die Anmerkungen in der manpage
richtig verstanden habe (falls nicht, bitte den clue-by-four auspacken):
Wenn Du eine ganz normale Verbindung hast, sagen wir mal ein telnet, dann
sind das zwei Datenkanäle. Einer von Port X auf Deiner Maschine (mit X >
1024) zu Port 23 des Telnet-Servers und einer von Port 23 des Servers zum
Port X auf Deiner Maschine. Lies, die Pakete gehen zweimal durch den
Firewall durch.
Die Richtung "raus" ist einfach zu erschlagen:
add pass tcp from <my-ip> to any 23
(Das ist NICHT optimal!)
Und was ist mit der Gegenrichtung? Wenn man da jetzt reinschreibt, "erlaube
alles, was von Port 23 einer anderen Maschine kommt", ist das nicht viel
besser als ein Selbstmord. Dann fährt man halt den eigenen Telnet-Server
runter und startet das Winnuke von Port 23 :)
Eine Lösung bieten die Interna von TCP. Beim Aufbau einer TCP-Verbindung
passiert ganz grob folgendes:
Client schickt ein Paket mit gesetztem "SYN"-Flag
Server schickt ein Paket mit gesetzten "SYN"- und "ACK"-Flags
Client schickt ein Paket mit gesetztem "ACK"-Flag
Alle jetzt folgenden Datenpakete haben im Normalfall das ACK-Flag gesetzt.
Wenn Du jetzt wissen willst, was das alles soll und wozu das gut ist,
empfehle ich Dir das Buch TCP/IP-Administration aus dem Verlag O'Reilly
oder gleich die CD "Networking CD Bookshelf". Pflichtlektüre für jeden,
der sich mit Netzwerken auseinandersetzt.
Zurück zum Thema: Ich kann ein Paket, daß in einer "legalen" Verbindung
im Rückkanal ist, also ganz einfach an der Tatsache erkennen, daß das
ACK-Flag gesetzt ist. Und daher findet sich in den meisten Firewall-Regeln
was in der Art:
ipfw add pass tcp from any to <myip> established
Und "established" meint ein Paket, bei dem das ACK-Flag gesetzt ist. Und
das auch zu findende "setup" meint ein Paket, bei dem nur das SYN-Flag
gesetzt ist.
[In den Beispielen in /etc/rc.firewall wird übrigens eine etwas andere
Variante verwendet, die ich nicht so toll finde. Wo liegt der Vorteil
dieser Version?
ipfw add pass tcp from <myip> to any setup
ipfw add pass tcp any to any established
Clue-by-four explizit erbeten
]
Aber so richtig toll ist das auch nicht. Denn was mache ich, wenn mich
ein Script-Kiddie mit Paketen bombardiert, die alle fälschlicherweise
das ACK-Flag gesetzt haben? Dumm zugucken, wie sie durch meinen Firewall
rauschen.
Und das ist der Punkt, an dem die State-Machine ins Spiel kommt. Hier mal
das Beispiel aus der Manpage.
ipfw add check-state
ipfw add deny tcp from any to any established
ipfw add allow tcp from my-net to any setup keep-state
Ich verbiete rein prinzipiell erstmal allen Traffic mit gesetzem ACK-Flag
(zeile 2). Wenn eine TCP-Verbindung von meinem Netz zu irgendwem aufgebaut
werden soll (Zeile 3, Teil von "tcp bis setup"), dann erlaube ich das
(das allow) und merke mir das (keep-state).
Effektiv trägt der Firewall dann dynamisch zwei Rules ein, die ausgeschrieben
so lauten:
add allow tcp from <remote system> <remote port> to <local machine>
<local port> established.
add allow tcp from <local system> <local port> to <remote machine>
<remote port> established.
Und diese Rules werden gelöscht, sobald die Verbindung beendet wird. Und das
ist schön, weil die Script-Kiddies damit wieder ein Förmchen aus der Hand
genommen wird. Jetzt können sie ihre Bömbchen nämlich nur noch schicken,
wenn sie auf dem Ziel-Rechner sind und da meinen ausgehenden Port aus dem
netstat raussuchen. Und nicht mehr quer durchs Netz ballern.
Aber ohne Peng, ich lese da auch noch viele Seite Manuals und Bücher...
> kann man ja auch ; am tun<N> device. IMHO haben die Filter im ppp haupt
> sächlich die dial-trigger und keepalive funktion. Daß man noch in
> und out filtern kann, gut, braucht man nicht wirklich, wie du richtig
> sagst.
Dann muß ich allerdings die access lists selber im link-up zusammenbauen.
Und kann definitv nicht FIREWALL_DEFAULT_TO_ACCEPT nehmen - sonst habe ich
im Moment des Verbindungsaufbaus einen völlig offenen Rechner. Ok, die
Option würde ich zwar eh nicht nehmen, allerdings hat sie während der
Testphase ein paar heftige Vorteile, wenn man eine Firewall-Maschine
ohne Tastatur und Monitor hat, die per ssh durchs LAN ferngesteuert wird.
> Und wenn du NAT über natd und den Kernel / ipfw machst ?
user-ppp mit natd? Geht das? Ich dachte bisher, man müßte die NAT-Option
vom ppp nehmen?
> yup! - brauch ich auch nicht, daß mir lustige Leute die Telefonrechnung
> verteuern ;-) Wobei sich gute Provider sehr wohl um dieses Thema kümmern.
Was Dir im Zweifelsfalle wenig nutzt. Ok, mir könnte es egal sein, da
flatrate :-)
> Ich bastel grad an einem Ding, das mit squid und socks läuft, da fühl
> ich mich schon etwas besser, wenn ich keine Pakete forwarden muß.
Steht für den Sommerurlaub auf der Liste.
/s/Udo
-- A lady came up to me on the street and pointed at my leather jacket. "You know a cow was murdered for that jacket?" she sneered. I replied in a psychotic tone, "I didn't know there were any witnesses. Now I'll have to kill you too." To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Wed 14 Jun 2000 - 06:20:10 CEST