Hallo!
Ich bin zwar kein Experte in Sachen DHCP und habe auch nicht so schnell die Möglichkeit etwas zu testen, aber grundsätzlich kann ich folgendes Sagen:
- mangle/nat Tabellen sind üblicherweise nur dazu da um "Sonderfälle" zu handhaben und IP-Header im Ein-/Ausgang zu verändern; sie dürften keinen Einfluß auf DHCP nehmen
- X-Windows Desktop-Manager (wie viele andere Client/Server-Anwendungen) benutzen Unix- oder TCP/IP-Sockets um mit anderen Anwendungen zu kommunizieren; das macht die Verwendung von "X-Clients" (oder nennen wir sie zum besseren Verständnis "Network Clients" oder "Thin Clients") über xdmcp erst möglich
- wenn die lokale Anmeldung nach Einsatz der FW-Tools nicht läuft, würde das bedeueten, dass dies bei SuSE über eine öffentliche IP-Adresse erfolgt (loopback ist ja frei).... Sinn und Unsinn sei dahingestellt; es gibt bei SuSE allerdings irgendwo eine Konfigurationsdatei wo dies eingestellt wird..... /etc/sysconfig/xdm oder /etc/X11/xdm oder irgendsowas.... bin mir nicht mehr 100%ig sicher in der Sache (versuch evtl. kurz ein "lsof -i" dann siehst du welche Anwendung sich lokal an welchen Port bindet)
Im Anhang die abgekürzte Version des gleichen Skripts unter Verwendung von stateful connections. Ich habe das mit DHCP noch nicht getestet, aber denke schon, dass das conntrack-Modul die Sachen erkennt. Nimm bei Nicht-Funktionieren evtl. die state-Befehle weg, im Log sollte sich schon einiges finden. Ausserdem ist es vielleicht nützlich (und korrekter) die LOG-Befehle einzuschränken sonst ist dein Server bei viel Verkehr womöglich innerhalb ein paar Stunden mit einem großen Logfile zugestopft.
Grüße,
Günther
(See attached file: fwtest.txt)
Günther Mair Internet Engineer
ENERGIS Italia GmbH Pfarrhofstrasse 60/A I-39100 Bozen (BZ) Tel.: +39 0471 254000 Fax: +39 0471 251617 Email: guenther.mair@energis.it Web: http://www.energis.it
luigi in3dzz@gmx.de An: liste lugbz lugbz-list@lugbz.org Gesendet von: Kopie: lugbz-list-admin Thema: [Lugbz-list] iptables @lugbz.org
22.05.2003 11:44 Bitte antworten an lugbz-list
Hallo Liste! Kämpfe gerade mit iptables. Dabei habe ich zunächste versucht dhcp für das LAN frei zu bekommen. ref: SuSE-8.1, iptables 1.2.7a-17. Hier das Skript
#!/bin/bash #/root/fw-ipt/fw-start # 0.1 - 14.5.2003
# Dieses Skript entfernt alle Regeln, Ketten und auch die Module. # Es funktioniert bestimmt. /root/fw-ipt/fw-stop
#################################Module laden########################################################### modprobe ip_tables modprobe ip_conntrack modprobe ip_conntrack_ftp modprobe ipt_state modprobe iptable_nat modprobe ipt_MASQUERADE echo "fw-start -- Module geladen."
################################# IPT=/usr/sbin/iptables
LAN_INTERFACE="eth0" # Interface zum LAN LOOPBACK_INTERFACE="lo" # Loopback-Interface
LAN_IPADDR="192.168.1.1" # Adresse des Lan-Interfaces LAN_ADDRESSES="192.168.1.0/24" # LAN-Bereich" BROADCAST_SRC="0.0.0.0" # Broadcast-Absender BROADCAST_DEST="255.255.255.255" # Broadcast-Empfänger
########################################################################################################
$IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP
$IPT -t nat -P PREROUTING DROP $IPT -t nat -P OUTPUT ACCEPT $IPT -t nat -P POSTROUTING ACCEPT
$IPT -t mangle -P PREROUTING DROP $IPT -t mangle -P OUTPUT ACCEPT
#Loopback freischalten $IPT -A INPUT -i lo -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT
########################################################################################################
# DHCP
#source-address 0.0.0.0.68 dest-address 255.255.255.255.67 #dhcp-discover und dhcp-request benutzen das gleiche Muster $IPT -A INPUT -i $LAN_INTERFACE -p udp -s $BROADCAST_SRC --sport 68 -d $BROADCAST_DEST --dport 67 -j ACCEPT
#source-address 192.168.1.1.67 dest-address 192.168.1.199.68 #dhcp-offer und dhcp-ack benutzen das gleiche Muster $IPT -A OUTPUT -o $LAN_INTERFACE -p udp -s $LAN_IPADDR --sport 67 -d $LAN_ADDRESSES --dport 68 -j ACCEPT
#source-address 192.168.1.199.68 dest-address 192.168.1.1.67 #Freigeben oder erneuern benutzen diese Muster $IPT -A INPUT -i $LAN_INTERFACE -p udp -s $LAN_ADDRESSES --sport 68 -d $LAN_IPADDR --dport 67 -j ACCEPT
$IPT -A OUTPUT -o $LAN_INTERFACE -j LOG $IPT -A INPUT -i $LAN_INTERFACE -j LOG
exit 0
Wenn ich nat/POSTROUTING,OUTPUT und mangle/OUTPUT nicht auf ACCEPT setze, dann kann ich vom W98-Client (ausführen --> winipcgf --> aktualisieren) die Adresse nicht mehr aktualisieren. Ein Überprüfen der /var/log/messages sagt dann lintsz01 dhcpd: DHCPACK on 192.168.1.199 to 00:a0:24:ef:94:a1 via eth0 lintsz01 dhcpd: send_packet: Operation not permitted
Ein Überwachen des Interfaces (tcpdump -i eth0 "udp[2:2] = 67 or udp[2:2] = 68] zeigt, dass eine Anfrage zwar ankommt, aber keine Antwort abgeht.
Und hier die Fragen 1. Warum muß ich nat/POSTROUTING,OUTPUT und mangle/OUTPUT auf ACCEPT stellen? 2. Damit dhcp funktioniert sollte ich also entsprechende Regeln auch für diese drei Ketten anfügen? Wie kann sowas aussehen? 3. Diese Einstellungen verhindern auch die Anmeldungen am KDE bzw., wenn KDE bereits aktiv ist kann man keine neue Anwendung aufrufen. Warum?
Danke für die Hilfe und bitte nicht laut lachen..... Luigi
_______________________________________________ http://www.lugbz.org/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
Am Donnerstag, 22. Mai 2003 14:08 schrieb guenther.mair@energis.it: Hallo günther! Danke für die schnelle Antwort. Ich werde dein Skript jetzt einmal testen. Wollte auf die conntarck zunächst verzichten (möglichst wenig einbauen). Merkwürdig ist wohl das Verhalten von dem Test-Skript. Ich habe zwar ein ganz gutes Buch hier von M&T Jahr 2002, aber netfilter scheint doch komplizierter zu sein als man zunächst annimt. Nochmals danke Bis bald luigi
Hallo!
Ich bin zwar kein Experte in Sachen DHCP und habe auch nicht so schnell die Möglichkeit etwas zu testen, aber grundsätzlich kann ich folgendes Sagen:
- mangle/nat Tabellen sind üblicherweise nur dazu da um
"Sonderfälle" zu handhaben und IP-Header im Ein-/Ausgang zu verändern; sie dürften keinen Einfluß auf DHCP nehmen
- X-Windows Desktop-Manager (wie viele andere
Client/Server-Anwendungen) benutzen Unix- oder TCP/IP-Sockets um mit anderen Anwendungen zu kommunizieren; das macht die Verwendung von "X-Clients" (oder nennen wir sie zum besseren Verständnis "Network Clients" oder "Thin Clients") über xdmcp erst möglich
- wenn die lokale Anmeldung nach Einsatz der FW-Tools nicht
läuft, würde das bedeueten, dass dies bei SuSE über eine öffentliche IP-Adresse erfolgt (loopback ist ja frei).... Sinn und Unsinn sei dahingestellt; es gibt bei SuSE allerdings irgendwo eine Konfigurationsdatei wo dies eingestellt wird..... /etc/sysconfig/xdm oder /etc/X11/xdm oder irgendsowas.... bin mir nicht mehr 100%ig sicher in der Sache (versuch evtl. kurz ein "lsof -i" dann siehst du welche Anwendung sich lokal an welchen Port bindet)
Im Anhang die abgekürzte Version des gleichen Skripts unter Verwendung von stateful connections. Ich habe das mit DHCP noch nicht getestet, aber denke schon, dass das conntrack-Modul die Sachen erkennt. Nimm bei Nicht-Funktionieren evtl. die state-Befehle weg, im Log sollte sich schon einiges finden. Ausserdem ist es vielleicht nützlich (und korrekter) die LOG-Befehle einzuschränken sonst ist dein Server bei viel Verkehr womöglich innerhalb ein paar Stunden mit einem großen Logfile zugestopft.
Grüße,
Günther
(See attached file: fwtest.txt)
Günther Mair Internet Engineer
ENERGIS Italia GmbH Pfarrhofstrasse 60/A I-39100 Bozen (BZ) Tel.: +39 0471 254000 Fax: +39 0471 251617 Email: guenther.mair@energis.it Web: http://www.energis.it
luigi <in3dzz@gmx.de> An: liste lugbzlugbz-list@lugbz.org Gesendet von: Kopie: lugbz-list-admin Thema: [Lugbz-list] iptables @lugbz.org
22.05.2003 11:44 Bitte antworten an lugbz-listHallo Liste! Kämpfe gerade mit iptables. Dabei habe ich zunächste versucht dhcp für das LAN frei zu bekommen. ref: SuSE-8.1, iptables 1.2.7a-17. Hier das Skript
#!/bin/bash #/root/fw-ipt/fw-start # 0.1 - 14.5.2003
# Dieses Skript entfernt alle Regeln, Ketten und auch die Module. # Es funktioniert bestimmt. /root/fw-ipt/fw-stop
#################################Module laden########################################################### modprobe ip_tables modprobe ip_conntrack modprobe ip_conntrack_ftp modprobe ipt_state modprobe iptable_nat modprobe ipt_MASQUERADE echo "fw-start -- Module geladen."
################################# IPT=/usr/sbin/iptables
LAN_INTERFACE="eth0" # Interface zum LAN LOOPBACK_INTERFACE="lo" # Loopback-Interface
LAN_IPADDR="192.168.1.1" # Adresse des Lan-Interfaces LAN_ADDRESSES="192.168.1.0/24" # LAN-Bereich" BROADCAST_SRC="0.0.0.0" # Broadcast-Absender BROADCAST_DEST="255.255.255.255" # Broadcast-Empfänger
################################################################# #######################################
$IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP
$IPT -t nat -P PREROUTING DROP $IPT -t nat -P OUTPUT ACCEPT $IPT -t nat -P POSTROUTING ACCEPT
$IPT -t mangle -P PREROUTING DROP $IPT -t mangle -P OUTPUT ACCEPT
#Loopback freischalten $IPT -A INPUT -i lo -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT
################################################################# #######################################
# DHCP
#source-address 0.0.0.0.68 dest-address 255.255.255.255.67 #dhcp-discover und dhcp-request benutzen das gleiche Muster $IPT -A INPUT -i $LAN_INTERFACE -p udp -s $BROADCAST_SRC --sport 68 -d $BROADCAST_DEST --dport 67 -j ACCEPT
#source-address 192.168.1.1.67 dest-address 192.168.1.199.68 #dhcp-offer und dhcp-ack benutzen das gleiche Muster $IPT -A OUTPUT -o $LAN_INTERFACE -p udp -s $LAN_IPADDR --sport 67 -d $LAN_ADDRESSES --dport 68 -j ACCEPT
#source-address 192.168.1.199.68 dest-address 192.168.1.1.67 #Freigeben oder erneuern benutzen diese Muster $IPT -A INPUT -i $LAN_INTERFACE -p udp -s $LAN_ADDRESSES --sport 68 -d $LAN_IPADDR --dport 67 -j ACCEPT
$IPT -A OUTPUT -o $LAN_INTERFACE -j LOG $IPT -A INPUT -i $LAN_INTERFACE -j LOG
exit 0
Wenn ich nat/POSTROUTING,OUTPUT und mangle/OUTPUT nicht auf ACCEPT setze, dann kann ich vom W98-Client (ausführen --> winipcgf --> aktualisieren) die Adresse nicht mehr aktualisieren. Ein Überprüfen der /var/log/messages sagt dann lintsz01 dhcpd: DHCPACK on 192.168.1.199 to 00:a0:24:ef:94:a1 via eth0 lintsz01 dhcpd: send_packet: Operation not permitted
Ein Überwachen des Interfaces (tcpdump -i eth0 "udp[2:2] = 67 or udp[2:2] = 68] zeigt, dass eine Anfrage zwar ankommt, aber keine Antwort abgeht.
Und hier die Fragen
- Warum muß ich nat/POSTROUTING,OUTPUT und mangle/OUTPUT auf
ACCEPT stellen? 2. Damit dhcp funktioniert sollte ich also entsprechende Regeln auch für diese drei Ketten anfügen? Wie kann sowas aussehen? 3. Diese Einstellungen verhindern auch die Anmeldungen am KDE bzw., wenn KDE bereits aktiv ist kann man keine neue Anwendung aufrufen. Warum?
Danke für die Hilfe und bitte nicht laut lachen..... Luigi
http://www.lugbz.org/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
Am Donnerstag, 22. Mai 2003 14:08 schrieb guenther.mair@energis.it: Hallo Günther! Ich habe jetzt dein Skript ausprobiert. Wenn ich es um die Einträge ergänze, die auch die nat und mangle Tabellen sperren, zeigt sich derselbe Effekt: 1) Ein Erneuern der Adresse wird nicht mehr erlaubt 2) Der X-Server lässt keine weitere Applikationen starten. 3) Andereseits, wenn ich nat und mangle nicht explizit sperre, dann gelten sie als offen (ACCEPT), dann geht ja alles ungehindert drüber.
Ich habe etwas weitergelesen und bin auf "Hooks" gekommen. Es scheint so zu sein, dass es im Kernel 5 vordefinierte Lauschstellen für jeweilige Netfilter-Module gibt. Wenn dem so ist, kann es sein, dass Tabellen, die mit meinem Vorhaben nichts am Hut haben sollten, dennoch Pakete sperren?
Ich habe den dhcp-Verkehr mit Ethereal mitgeschnitten. Die drei Dateien sind sehr kurz, deshalb erlaube ich mir diese beizulegen. Bis bald Luigi
Hallo!
Ich bin zwar kein Experte in Sachen DHCP und habe auch nicht so schnell die Möglichkeit etwas zu testen, aber grundsätzlich kann ich folgendes Sagen:
- mangle/nat Tabellen sind üblicherweise nur dazu da um
"Sonderfälle" zu handhaben und IP-Header im Ein-/Ausgang zu verändern; sie dürften keinen Einfluß auf DHCP nehmen
- X-Windows Desktop-Manager (wie viele andere
Client/Server-Anwendungen) benutzen Unix- oder TCP/IP-Sockets um mit anderen Anwendungen zu kommunizieren; das macht die Verwendung von "X-Clients" (oder nennen wir sie zum besseren Verständnis "Network Clients" oder "Thin Clients") über xdmcp erst möglich
- wenn die lokale Anmeldung nach Einsatz der FW-Tools nicht
läuft, würde das bedeueten, dass dies bei SuSE über eine öffentliche IP-Adresse erfolgt (loopback ist ja frei).... Sinn und Unsinn sei dahingestellt; es gibt bei SuSE allerdings irgendwo eine Konfigurationsdatei wo dies eingestellt wird..... /etc/sysconfig/xdm oder /etc/X11/xdm oder irgendsowas.... bin mir nicht mehr 100%ig sicher in der Sache (versuch evtl. kurz ein "lsof -i" dann siehst du welche Anwendung sich lokal an welchen Port bindet)
Im Anhang die abgekürzte Version des gleichen Skripts unter Verwendung von stateful connections. Ich habe das mit DHCP noch nicht getestet, aber denke schon, dass das conntrack-Modul die Sachen erkennt. Nimm bei Nicht-Funktionieren evtl. die state-Befehle weg, im Log sollte sich schon einiges finden. Ausserdem ist es vielleicht nützlich (und korrekter) die LOG-Befehle einzuschränken sonst ist dein Server bei viel Verkehr womöglich innerhalb ein paar Stunden mit einem großen Logfile zugestopft.
Grüße,
Günther
(See attached file: fwtest.txt)
Günther Mair Internet Engineer
ENERGIS Italia GmbH Pfarrhofstrasse 60/A I-39100 Bozen (BZ) Tel.: +39 0471 254000 Fax: +39 0471 251617 Email: guenther.mair@energis.it Web: http://www.energis.it
luigi <in3dzz@gmx.de> An: liste lugbzlugbz-list@lugbz.org Gesendet von: Kopie: lugbz-list-admin Thema: [Lugbz-list] iptables @lugbz.org
22.05.2003 11:44 Bitte antworten an lugbz-listHallo Liste! Kämpfe gerade mit iptables. Dabei habe ich zunächste versucht dhcp für das LAN frei zu bekommen. ref: SuSE-8.1, iptables 1.2.7a-17. Hier das Skript
#!/bin/bash #/root/fw-ipt/fw-start # 0.1 - 14.5.2003
# Dieses Skript entfernt alle Regeln, Ketten und auch die Module. # Es funktioniert bestimmt. /root/fw-ipt/fw-stop
#################################Module laden########################################################### modprobe ip_tables modprobe ip_conntrack modprobe ip_conntrack_ftp modprobe ipt_state modprobe iptable_nat modprobe ipt_MASQUERADE echo "fw-start -- Module geladen."
################################# IPT=/usr/sbin/iptables
LAN_INTERFACE="eth0" # Interface zum LAN LOOPBACK_INTERFACE="lo" # Loopback-Interface
LAN_IPADDR="192.168.1.1" # Adresse des Lan-Interfaces LAN_ADDRESSES="192.168.1.0/24" # LAN-Bereich" BROADCAST_SRC="0.0.0.0" # Broadcast-Absender BROADCAST_DEST="255.255.255.255" # Broadcast-Empfänger
################################################################# #######################################
$IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP
$IPT -t nat -P PREROUTING DROP $IPT -t nat -P OUTPUT ACCEPT $IPT -t nat -P POSTROUTING ACCEPT
$IPT -t mangle -P PREROUTING DROP $IPT -t mangle -P OUTPUT ACCEPT
#Loopback freischalten $IPT -A INPUT -i lo -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT
################################################################# #######################################
# DHCP
#source-address 0.0.0.0.68 dest-address 255.255.255.255.67 #dhcp-discover und dhcp-request benutzen das gleiche Muster $IPT -A INPUT -i $LAN_INTERFACE -p udp -s $BROADCAST_SRC --sport 68 -d $BROADCAST_DEST --dport 67 -j ACCEPT
#source-address 192.168.1.1.67 dest-address 192.168.1.199.68 #dhcp-offer und dhcp-ack benutzen das gleiche Muster $IPT -A OUTPUT -o $LAN_INTERFACE -p udp -s $LAN_IPADDR --sport 67 -d $LAN_ADDRESSES --dport 68 -j ACCEPT
#source-address 192.168.1.199.68 dest-address 192.168.1.1.67 #Freigeben oder erneuern benutzen diese Muster $IPT -A INPUT -i $LAN_INTERFACE -p udp -s $LAN_ADDRESSES --sport 68 -d $LAN_IPADDR --dport 67 -j ACCEPT
$IPT -A OUTPUT -o $LAN_INTERFACE -j LOG $IPT -A INPUT -i $LAN_INTERFACE -j LOG
exit 0
Wenn ich nat/POSTROUTING,OUTPUT und mangle/OUTPUT nicht auf ACCEPT setze, dann kann ich vom W98-Client (ausführen --> winipcgf --> aktualisieren) die Adresse nicht mehr aktualisieren. Ein Überprüfen der /var/log/messages sagt dann lintsz01 dhcpd: DHCPACK on 192.168.1.199 to 00:a0:24:ef:94:a1 via eth0 lintsz01 dhcpd: send_packet: Operation not permitted
Ein Überwachen des Interfaces (tcpdump -i eth0 "udp[2:2] = 67 or udp[2:2] = 68] zeigt, dass eine Anfrage zwar ankommt, aber keine Antwort abgeht.
Und hier die Fragen
- Warum muß ich nat/POSTROUTING,OUTPUT und mangle/OUTPUT auf
ACCEPT stellen? 2. Damit dhcp funktioniert sollte ich also entsprechende Regeln auch für diese drei Ketten anfügen? Wie kann sowas aussehen? 3. Diese Einstellungen verhindern auch die Anmeldungen am KDE bzw., wenn KDE bereits aktiv ist kann man keine neue Anwendung aufrufen. Warum?
Danke für die Hilfe und bitte nicht laut lachen..... Luigi
http://www.lugbz.org/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
Am Donnerstag, 22. Mai 2003 14:08 schrieb guenther.mair@energis.it: Hallo Günther, hallo Liste! Ich habe noch ein paar Sachen herausgefunden, die du bestimmt schon kennst. Die Ketten existieren alle separat, z.B. die OUTPUT-Kette der nat oder die OUTPUT-KETTE der mangle- bzw. filter-Tabelle müssen als verschiedene Dinge betrachtet werden. Die filter-tabelle ist die einzige, die grundsatzlich nichts am Paket verändern kann. Die anderen beiden schon. Ich vermute, dass die Ketten aller Tabellen hintereindander abgearbeitet werden. Das würde einiges erklären.
Hallo!
Ich bin zwar kein Experte in Sachen DHCP und habe auch nicht so schnell die Möglichkeit etwas zu testen, aber grundsätzlich kann ich folgendes Sagen:
- mangle/nat Tabellen sind üblicherweise nur dazu da um
"Sonderfälle" zu handhaben und IP-Header im Ein-/Ausgang zu verändern; sie dürften keinen Einfluß auf DHCP nehmen
Da stimme ich dir ohne weiteres zu. Vermutlich gehört das Sperren dieser Ketten eher in den Bereich Sonderfälle.
- X-Windows Desktop-Manager (wie viele andere
Client/Server-Anwendungen) benutzen Unix- oder TCP/IP-Sockets um mit anderen Anwendungen zu kommunizieren; das macht die Verwendung von "X-Clients" (oder nennen wir sie zum besseren Verständnis "Network Clients" oder "Thin Clients") über xdmcp erst möglich
Ich glaube, dass ein ACCEPT für mangle und nat das Problem gar nicht aufkommen lässt, werde es bei Gelegenheit probieren.
- wenn die lokale Anmeldung nach Einsatz der FW-Tools nicht
läuft, würde das bedeueten, dass dies bei SuSE über eine öffentliche IP-Adresse erfolgt (loopback ist ja frei).... Sinn und Unsinn sei dahingestellt; es gibt bei SuSE allerdings irgendwo eine Konfigurationsdatei wo dies eingestellt wird..... /etc/sysconfig/xdm oder /etc/X11/xdm oder irgendsowas.... bin mir
Da habe ich nichts gefunden
nicht mehr 100%ig sicher in der Sache (versuch evtl. kurz ein "lsof -i" dann siehst du welche Anwendung sich lokal an welchen Port bindet)
Das ist ein sehr guter Tipp.
Im Anhang die abgekürzte Version des gleichen Skripts unter Verwendung von stateful connections. Ich habe das mit DHCP noch nicht getestet, aber denke schon, dass das conntrack-Modul die Sachen erkennt. Nimm bei Nicht-Funktionieren evtl. die state-Befehle weg, im Log sollte sich schon einiges finden. Ausserdem ist es vielleicht nützlich (und korrekter) die LOG-Befehle einzuschränken sonst ist dein Server bei viel Verkehr womöglich innerhalb ein paar Stunden mit einem großen Logfile zugestopft.
Werde ich beherzigen.
Grüße,
Heute habe ich noch die benutzerdefinierten Ketten etwas angeschaut. Ich glaube bis Ende nächster Woche müsste meine firewall stehen. Nochmals allen ein schönes Wochenende. Luigi
hallo
On Fri, 2003-05-23 at 21:50, luigi wrote:
Die filter-tabelle ist die einzige, die grundsatzlich nichts am Paket verändern kann. Die anderen beiden schon. Ich vermute, dass die Ketten aller Tabellen hintereindander abgearbeitet werden. Das würde einiges erklären.
bevor ihr da rumprobiert um sachen rauszufinden: auf www.netfilter.org gibts genug dokumentation wo genau beschrieben ist wie, welche chains fuer was gebraucht werden und wie das alles funktioniert. gibts sogar in mehreren sprachen und in mehreren formaten.
da steht z.b wie die pakete die filter passieren: http://www.netfilter.org/documentation/HOWTO/de/packet-filtering-HOWTO.html#...
Am Sonntag, 25. Mai 2003 13:06 schrieb Peter Warasin: Hallo Peter,
hallo
On Fri, 2003-05-23 at 21:50, luigi wrote:
Die filter-tabelle ist die einzige, die grundsatzlich nichts am Paket verändern kann. Die anderen beiden schon. Ich vermute, dass die Ketten aller Tabellen hintereindander abgearbeitet werden. Das würde einiges erklären.
bevor ihr da rumprobiert um sachen rauszufinden: auf www.netfilter.org gibts genug dokumentation wo genau beschrieben ist wie, welche chains fuer was gebraucht werden und wie das alles funktioniert. gibts sogar in mehreren sprachen und in mehreren formaten.
da steht z.b wie die pakete die filter passieren: http://www.netfilter.org/documentation/HOWTO/de/packet-filtering- HOWTO.html#toc6
hole ich mir, danke Luigi
http://www.lugbz.org/mailman/listinfo/lugbz-list LUGBZ is pcn.it-powered
-
guenther.mair＠energis.it -
luigi -
Peter Warasin