Michael Meyer [23:45 29.09.02]:

wenn er lesen will muss er eingehende verbindungen von port 119 auf ports '>1024' erlauben. ein offener port 119 hilft ihm nicht.

Ah, da kommen wir der Sache schon näher. Aber wie kann ich das in eine iptables-Regel gießen, d.h. wie erkenne ich, welche eingehende Verbindung auf den Router zu welchem Client "dahinter" durchgereicht werden soll, und auf welchen Port des Clients? Gruß. Andy

Hallo, On Sun, 29 Sep 2002, Andy Feile wrote:

Michael Meyer [23:45 29.09.02]:

...

wenn er lesen will muss er eingehende verbindungen von port 119 auf ports '>1024' erlauben. ein offener port 119 hilft ihm nicht.

Ah, da kommen wir der Sache schon näher. Aber wie kann ich das in eine iptables-Regel gießen, d.h. wie erkenne ich, welche eingehende Verbindung auf den Router zu welchem Client "dahinter" durchgereicht werden soll, und auf welchen Port des Clients?

Am einfachsten verwendest du die Features von iptables! Konkret, das "stateful"-Filtering in Kombination mit "connection tracking": ==== IPT=/usr/sbin/iptables STATE_RE="-m state --state RELATED,ESTABLISHED" STATE_NRE="-m state --state NEW,RELATED,ESTABLISHED" WORLDIF="ppp0" [..] $IPT -A INPUT -i $WORLDIF $STATE_RE -j ACCEPT $IPT -A OUTPUT -o $WORLDIF $STATE_NRE -j ACCEPT ==== Das ist zwar sicherlich keine optimale Loesung, da es von intern alles akzeptiert, aber mit ein paar (restriktiven!) Regeln davor (z.B. fuer ungueltige Pakete, ports 137-139 etc.) sowie einer DROP-Policy sollte das eigentlich "passen" -- je nach Situation ist das natuerlich weiter einzuschraenken, z.B. auf bestimmte Protokolle, Ports usw. Obiges erlaubt _keinerlei_ Verbindungen von aussen (aber alle von innen!), es sei denn, es ist vorher durch eine passende Sonderregel explizit erlaubt worden... Achso: RTFM! Eine URL wurde dir ja schon "nebenan" gesagt. Denn ohne zu verstehen, wie ne Firewall allgemein funktioniert und wie man das mit iptables umsetzen kann wirst du kaum auf einen gruenen Zweig kommen und dich hoechstens in faschler Sicherheit wiegen. Generell gilt: erstmal _alles_ dichtmachen (ok, ein Regel-Paaerchen fuer das 'lo' ist angebracht ;), und dann schrittweise aufmachen und erstmal alles mitloggen... ("Chains" zum loggen helfen dabei: $IPT -N LOGDROP $IPT -A LOGDROP -j LOG --log-level debug \ --log-prefix "iptables: DROP: " $IPT -A LOGDROP -j DROP $IPT -N LOGACCEPT $IPT -A LOGACCEPT -j LOG --log-level debug \ --log-prefix "iptables: ACCEPT: " $IPT -A LOGACCEPT -j ACCEPT $IPT -N LOGDREJECT $IPT -A LOGREJECT -j LOG --log-level debug \ --log-prefix "iptables: REJECT: " $IPT -A LOGREJECT -j REJECT Und dann eben fuer jede neue Regel eben erstmal LOG${TARGET} statt ${TARGET} verwenden... (und das Logfile per tail -f mitlaufen lassen). Ein Umleiten der Debugmessages in ein eigenes logfiile hilft: ==== /etc/syslog.conf ==== *.=debug -/var/log/debugmessages ==== -dnh -- "N race conditions on the wall, N race conditionsa You take one down, pass it around, and wait. And wait some more." -- Bytor in #tribes