Archiv verlassen und diese Seite im Standarddesign anzeigen : firewall blockt ACK,SYN-Pakete
SniperRifle
05.01.03, 00:09
Hi,
ich verwende auf meinem Router iptables. Es funzt alles einwandfrei, was maskierten Transfer angeht und auch die verschiedenen Server auf dem Router tun (FTP, sshd, ...)
Jetz hab ich noch den mldonkey drauf getan und für ihn genau 3 neue Regeln:
iptables -A INPUT -i ppp0 -p udp --dport 4666 -m state --state NEW -j ACCEPT
iptables -A INPUT -i ppp0 -p tcp --dport 4662 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o ppp0 -m owner --pid-owner $(pidof mldonkey) -m state --state NEW -j ACCEPT
Ganz am Anfang der Chains habe ich noch die Regeln:
# Bestehene Verbindungen zulasssen
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
Erstaunlicherweise blocken diese Regeln die ACK,SYN-Pakete von Verbindungen, die der mldonkey zu anderen Clienten (also outgoing tcp 4662) aufbaut.
Auszug aus der Syslog:
Jan 5 00:57:03 DSL-Gateway kernel: IN=ppp0 OUT= MAC= SRC=203.177.146.111 DST=62.226.50.145 LEN=64 TOS=0x00 PREC=0x00 TTL=120 ID=59534 DF PROTO=TCP SPT=4662 DPT=1952 WINDOW=65535 RES=0x00 ACK SYN URGP=0
Meine syslog quillt über von diesen messages, und ich denk auch mal dass mir dadurch sources vom donkey verloren gehen. Warum werden diese Pakete geblockt?
mfg Chris
PS: es läuft iptables-1.2.3 auf Redhat 7.2
Welche IP ist jetzt deine? 203.177.146.111 oder 62.226.50.145?
Denn dieses Paket ging anscheinend nicht raus - sondern kam rein:
Jan 5 00:57:03 DSL-Gateway kernel: IN=ppp0 OUT=
Der Source-Port (SPT) ist der von der "fragenden" Maschine - leider ging die Frage aber nicht an den richtigen Port (DST=1952). Oder ist es schon zu früh zum nachdenken :ugly:
ciao
Michael
SniperRifle
05.01.03, 01:10
Die 62.266.... ist meine IP.
Also das Prob ist: Das erste Paket (das SYN-Paket) sendet der mldonkey an tcp4662 irgendeines anderen donkeyclienten. Das Antwortpaket, das von dem andern Clienten zurückkommt, ist das ACK,SYN-Paket (von tcp4662 bei ihm auf irgendeinen port bei mir), und genau dieses Paket wird geblockt.
Eigentlich sollte es aber von der Regel "iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT" akzeptiert werden, da ja die verbindung established ist. Aber das tut es nicht.:confused:
Hoffe das war jetz verständlicher :)
moin moin
mal ne blöde frage. woran erkennst du das das paket geblockt wurde? ich mein du hast das script ja anscheinend selbst geschrieben und weißt daher wohl auch was gelogt wird. für mich ist an dem auschnitt aus dem log allerdings nicht zu erkennen, das das geblockt wurde.
ps: vielleicht ist es auch bloß schon zu spät ;)
Gruß HL
SniperRifle
05.01.03, 01:34
Dass es geblockt wurde, weiß ich daher, dass jedes paket, welches geloggt wird auch gedroppt wird ;)
Wenn ein paket auf keine regel passt, wird in die LOGGING-kette gesprungen:
iptables -A LOGGING -j LOG
iptables -A LOGGING -j DROP
hi
Dass es geblockt wurde, weiß ich daher, dass jedes paket, welches geloggt wird auch gedroppt wird ;)
ich hab's befürchtet ;) so auf den ersten blick weiß ich aber auch nicht, warum er die pakete nicht reinläßt. bin aber auch nicht grade ein held, was iptables angeht ;)
Gruß HL
iptables -A INPUT -i ppp0 -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -j ACCEPT
test mal setz es als erste input regel
SniperRifle
05.01.03, 14:00
Diese Regel könnte ich zwar einsetzen, aber ich versteh trotzdem nicht, warum das Paket nicht von meinen schon existierenden Regelns akzeptiert wird. Denn wenn ich mit ftp, telnet oder sonstwas arbeite, werden ja auch alle Pakete akzeptiert. Nur beim mldonkey werden die ack,syn-pakete gedroppt.
1. lass auch RELATED zu
2. First Match win!
Mehr kann man aufgrund fehlendem Script nicht sagen.
HTH
SniperRifle
05.01.03, 14:50
Dann kommt jetzt mal das ganze Skript:
(Die Regeln, die ich oben schon angegeben hab, waren zum besseren Verständnis etwas abgewandelt.;) Ich hoffe, dass ihr mit meinem skript klarkommt, aber im grunde ist es einfach zu verstehen ;) Das ganze mache ich so, damit ich meinen transfer auslesen kann)
ich hab die wichtigen stellen nochmal blau hervorgehoben.
#!/bin/sh
echo "IPTables initialisieren..."
# Module laden
modprobe iptable_nat
modprobe ip_conntrack
modprobe ip_conntrack_ftp
# IP-Forwarding aktivieren
echo 1 > /proc/sys/net/ipv4/ip_forward
# Sämtliche Regelketten löschen
iptables -F
iptables -t nat -F
iptables -X
# Alles verbieten
iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP
# Logging-Chain
iptables -N LOGGING
iptables -A LOGGING -j LOG
iptables -A LOGGING -j DROP
#################################### FORWARD ######################################
echo "Forward..."
#~~~~~~~~~~~~~~~~~ UDP
iptables -N UDP
# NetBIOS-Pakete droppen
iptables -A UDP -p udp --sport 137 -j DROP
iptables -A UDP -p udp --sport 138 -j DROP
iptables -A UDP -p udp --sport 139 -j DROP
# Bestehende Verbindungen
iptables -A UDP -p udp -m state --state ESTABLISHED -j ACCEPT
# DNS-Client
iptables -A UDP -i eth0 -o ppp0 -p udp --sport 1024:65535 -s 192.168.0.0/24 --dport 53 -d 212.185.248.212 -m state --state NEW -j ACCEPT
iptables -A UDP -i eth0 -o ppp0 -p udp --sport 1024:65535 -s 192.168.0.0/24 --dport 53 -d 194.25.2.129 -m state --state NEW -j ACCEPT
# Starcraft-Client
iptables -A UDP -p udp --sport 6112 --dport 6112 -m state --state NEW -j ACCEPT
iptables -A UDP -i eth0 -o ppp0 -p udp --sport 6112 --dport 1024:65535 -m state --state NEW -j ACCEPT
iptables -A UDP -i ppp0 -o eth0 -p udp --dport 6112 -m state --state NEW -j ACCEPT
# Teamspeak-Client
iptables -A UDP -p udp --sport 1024:65535 -s 192.168.0.0/24 --dport 9666 -m state --state NEW -j ACCEPT
# KaZaA-Client
iptables -A UDP -p udp --sport 1214 -s 192.168.0.0/24 --dport 1024:65535 -m state --state NEW -j ACCEPT
iptables -A UDP -j LOGGING
#~~~~~~~~~~~~~~~~~ TCP
iptables -N TCP
# Bestehende Verbindungen
iptables -A TCP -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
# FTP-Client
iptables -A TCP -i eth0 -o ppp0 -p tcp --sport 1024:65535 -s 192.168.0.0/24 --dport 21 -m state --state NEW -j ACCEPT
# SMTP-Client
iptables -A TCP -i eth0 -o ppp0 -p tcp --sport 1024:65535 -s 192.168.0.0/24 --dport 25 -m state --state NEW -j ACCEPT
# HTTP-Client
iptables -A TCP -i eth0 -o ppp0 -p tcp --sport 1024:65535 -s 192.168.0.0/24 --dport 80 -m state --state NEW -j ACCEPT
# POP3-Client
iptables -A TCP -i eth0 -o ppp0 -p tcp --sport 1024:65535 -s 192.168.0.0/24 --dport 110 -m state --state NEW -j ACCEPT
# HTTPS-Client
iptables -A TCP -i eth0 -o ppp0 -p tcp --sport 1024:65535 -s 192.168.0.0/24 --dport 443 -m state --state NEW -j ACCEPT
# POP3S-Client
iptables -A TCP -i eth0 -o ppp0 -p tcp --sport 1024:65535 -s 192.168.0.0/24 --dport 995 -m state --state NEW -j ACCEPT
# ICQ-Client
iptables -A TCP -i eth0 -o ppp0 -p tcp --sport 1024:65535 -s 192.168.0.0/24 --dport 5190 -m state --state NEW -j ACCEPT
# Starcraft-Client
iptables -A TCP -i eth0 -o ppp0 -p tcp --sport 1024:65535 -s 192.168.0.0/24 --dport 6112 -m state --state NEW -j ACCEPT
iptables -A TCP -j LOGGING
#~~~~~~~~~~~~~~~~~ ICMP
iptables -N ICMP
# Ausgehende Echo-Request (8)
iptables -A ICMP -i eth0 -o ppp0 -p icmp --icmp-type echo-request -s 192.168.0.0/24 -m state --state NEW -j ACCEPT
# Eingehende Echo-Reply (0)
iptables -A ICMP -i ppp0 -o eth0 -p icmp --icmp-type echo-reply -d 192.168.0.0/24 -m state --state ESTABLISHED -j ACCEPT
# Durchgehende Port-unreachable (3/3)
iptables -A ICMP -p icmp --icmp-type port-unreachable -m state --state RELATED -j ACCEPT
# Eingehende Time-exceeded (11/0)
iptables -A ICMP -i ppp0 -o eth0 -p icmp --icmp-type ttl-zero-during-transit -d 192.168.0.0/24 -m state --state RELATED -j ACCEPT
iptables -A ICMP -j LOGGING
################################################## #################################
iptables -N fwdINPUT
iptables -N fwdOUTPUT
# Je nach Protokoll in die entsprechende Kette springen
iptables -A fwdINPUT -p tcp -j TCP
iptables -A fwdINPUT -p udp -j UDP
iptables -A fwdINPUT -p icmp -j ICMP
iptables -A fwdOUTPUT -p tcp -j TCP
iptables -A fwdOUTPUT -p udp -j UDP
iptables -A fwdOUTPUT -p icmp -j ICMP
iptables -A fwdINPUT -j LOGGING
iptables -A fwdOUTPUT -j LOGGING
# In/Outputfilterung
iptables -A FORWARD -i ppp0 -j fwdINPUT
iptables -A FORWARD -o ppp0 -j fwdOUTPUT
iptables -A FORWARD -j LOGGING
##################################### INPUT #########################################
echo "Input..."
#~~~~~~~~~~~~~~~~~ inUDP
iptables -N inUDP
# NetBIOS-Pakete droppen
iptables -A inUDP -p udp --dport 137 -j DROP
iptables -A inUDP -p udp --sport 137 -j DROP
iptables -A inUDP -p udp --sport 138 -j DROP
iptables -A inUDP -p udp --sport 139 -j DROP
# Bestehende Verbindungen
iptables -A inUDP -p udp -m state --state ESTABLISHED -j ACCEPT
# MLDonkey-UDP
iptables -A inUDP -p udp --sport 1024:65535 --dport 4666 -m state --state NEW -j ACCEPT
# MLDonkey (Overnet)
iptables -A inUDP -p udp --sport 1024:65535 --dport 4994 -m state --state NEW -j ACCEPT
# Teamspeak-Server
iptables -A inUDP -p udp --sport 1024:65535 --dport 8767 -m state --state NEW -j ACCEPT
iptables -A inUDP -j LOGGING
#~~~~~~~~~~~~~~~~~ inTCP
iptables -N inTCP
# NetBIOS blocken
iptables -A inTCP -p tcp --dport 139 -m state --state NEW -j DROP
# Bestehende Verbindungen
iptables -A inTCP -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
# FTP-Server
iptables -A inTCP -p tcp --sport 1024:65535 --dport 21 -m state --state NEW -j ACCEPT
# ssh-Server
iptables -A inTCP -p tcp --sport 1024:65535 --dport 22 -m state --state NEW -j ACCEPT
# SMTP-Server
iptables -A inTCP -p tcp --sport 1024:65535 --dport 25 -m state --state NEW -j ACCEPT
# IMAP-Server
iptables -A inTCP -p tcp --sport 1024:65535 --dport 143 -m state --state NEW -j ACCEPT
# MLDonkey-Watch-Server
iptables -A inTCP -p tcp --sport 1024:65535 --dport 4001 -m state --state NEW -j ACCEPT
# MLDonkey-HTTP-Server
iptables -A inTCP -p tcp --sport 1024:65535 --dport 4080 -m state --state NEW -j ACCEPT
# MLDonkey
iptables -A inTCP -p tcp --sport 1024:65535 --dport 4662 -m state --state NEW -j ACCEPT
# MLDonkey (Overnet)
iptables -A inTCP -p tcp --sport 1024:65535 --dport 4994 -m state --state NEW -j ACCEPT
# Webmin-Server
iptables -A inTCP -p tcp --sport 1024:65535 --dport 10000 -m state --state NEW -j ACCEPT
# Teamspeak-HTTP-Server
iptables -A inTCP -p tcp --sport 1024:65535 --dport 14534 -m state --state NEW -j ACCEPT
iptables -A inTCP -j LOGGING
#~~~~~~~~~~~~~~~~~ inICMP
iptables -N inICMP
# Eingehende echo-reply (0)
iptables -A inICMP -p icmp --icmp-type echo-reply -m state --state ESTABLISHED -j ACCEPT
# Eingehende host-unreachable (3/1)
iptables -A inICMP -i ppp0 -p icmp --icmp-type host-unreachable -m state --state RELATED -j ACCEPT
# Eingehende port-unreachable (3/3)
iptables -A inICMP -i ppp0 -p icmp --icmp-type port-unreachable -m state --state ESTABLISHED,RELATED -j ACCEPT
# Eingehende port-unreachable (3/4)
iptables -A inICMP -i ppp0 -p icmp --icmp-type fragmentation-needed -m state --state RELATED -j ACCEPT
# Eingehende time-exceeded (11/0)
iptables -A inICMP -i ppp0 -p icmp --icmp-type ttl-zero-during-transit -m state --state RELATED -j ACCEPT
iptables -A inICMP -j LOGGING
################################################## ###################################
iptables -N ppp0INPUT
iptables -N eth0INPUT
# Je nach Protokoll in die entsprechende Kette springen
iptables -A ppp0INPUT -p tcp -j inTCP
iptables -A ppp0INPUT -p udp -j inUDP
iptables -A ppp0INPUT -p icmp -j inICMP
iptables -A eth0INPUT -p tcp -j inTCP
iptables -A eth0INPUT -p udp -j inUDP
iptables -A eth0INPUT -p icmp -j inICMP
iptables -A ppp0INPUT -j LOGGING
iptables -A eth0INPUT -j LOGGING
# In/Outputfilterung
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i ppp0 -j ppp0INPUT
iptables -A INPUT -i eth0 -j eth0INPUT
iptables -A INPUT -j LOGGING
#################################### OUTPUT #########################################
echo "Output..."
#~~~~~~~~~~~~~~~~~ outUDP
iptables -N outUDP
# Bestehende Verbindungen
iptables -A outUDP -p udp -m state --state ESTABLISHED -j ACCEPT
# DNS-Client
iptables -A outUDP -o ppp0 -p udp --sport 1024:65535 --dport 53 -d 212.185.248.212 -m state --state NEW -j ACCEPT
iptables -A outUDP -o ppp0 -p udp --sport 1024:65535 --dport 53 -d 194.25.2.129 -m state --state NEW -j ACCEPT
# NTP-Client
iptables -A outUDP -o ppp0 -p udp --sport 123 --dport 123 -m state --state NEW -j ACCEPT
# MLDonkey-Client
iptables -A outUDP -o ppp0 -p udp --sport 1024:65535 -m owner --pid-owner $(pidof mldonkey) -m state --state NEW -j ACCEPT
iptables -A outUDP -j LOGGING
#~~~~~~~~~~~~~~~~~ outTCP
iptables -N outTCP
# Bestehende Verbindungen
iptables -A outTCP -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
# FTP-Client
iptables -A outTCP -o ppp0 -p tcp --sport 1024:65535 --dport 21 -m state --state NEW -j ACCEPT
# SMTP-Client
iptables -A outTCP -o ppp0 -p tcp --sport 1024:65535 --dport 25 -m state --state NEW -j ACCEPT
# HTTP-Client
iptables -A outTCP -o ppp0 -p tcp --sport 1024:65535 --dport 80 -m state --state NEW -j ACCEPT
# POP3-Client
iptables -A outTCP -o ppp0 -p tcp --sport 1024:65535 --dport 110 -m state --state NEW -j ACCEPT
# CVS-Client
iptables -A outTCP -o ppp0 -p tcp --sport 1024:65535 --dport 2401 -m state --state NEW -j ACCEPT
# No-IP-Client
iptables -A outTCP -o ppp0 -p tcp --sport 1024:65535 --dport 8245 -m state --state NEW -j ACCEPT
# MLDonkey-Client
iptables -A outTCP -o ppp0 -p tcp --sport 1024:65535 -m owner --pid-owner $(pidof mldonkey) -m state --state NEW -j ACCEPT
iptables -A outTCP -j LOGGING
#~~~~~~~~~~~~~~~~~ outICMP
iptables -N outICMP
# Ausgehende port-unreachable (3/3)
iptables -A outICMP -p icmp --icmp-type port-unreachable -m state --state RELATED -j ACCEPT
# Ausgehende echo-request (8)
iptables -A outICMP -p icmp --icmp-type echo-request -m state --state NEW -j ACCEPT
iptables -A outICMP -j LOGGING
################################################## ###################################
iptables -N ppp0OUTPUT
iptables -N eth0OUTPUT
# Je nach Protokoll in die entsprechende Kette springen
iptables -A ppp0OUTPUT -p tcp -j outTCP
iptables -A ppp0OUTPUT -p udp -j outUDP
iptables -A ppp0OUTPUT -p icmp -j outICMP
iptables -A eth0OUTPUT -p tcp -j outTCP
iptables -A eth0OUTPUT -p udp -j outUDP
iptables -A eth0OUTPUT -p icmp -j outICMP
iptables -A ppp0OUTPUT -j LOGGING
iptables -A eth0OUTPUT -j LOGGING
# In/Outputfilterung
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -o ppp0 -j ppp0OUTPUT
iptables -A OUTPUT -o eth0 -j eth0OUTPUT
iptables -A OUTPUT -j LOGGING
#################################### Masquerading ###################################
echo "Masquerading aktivieren..."
# Masquerading aktivieren
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
################################### Port-Forwarding #################################
# KaZaA
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 1214 -j DNAT --to 192.168.0.102
# Starcraft
iptables -t nat -A PREROUTING -i ppp0 -p udp --dport 6112 -j DNAT --to 192.168.0.102
Hallo
ich würde sagen das die verbindung erst ESTABLISHED ist
wenn du das syn packet von dem anderen rechner angenommen hast.
(wenn sich die zwei rechner auf einen Port geeinigt haben).
Profbunny
SniperRifle
05.01.03, 16:00
IMHO ist nur das allererste Paket NEW alle folgenden sind ESTABLISHED
SYN ---> NEW
ACK,SYN <--- ESTABLISHED
ACK ---> ESTABLISHED
ACK <--- ESTABLISHED
ACK ---> ESTABLISHED
ACK <--- ESTABLISHED
ACK,FIN ---> ESTABLISHED
FIN <--- ESTABLISHED
So stell ich mir das vor und wenn ich grad nicht total daneben bin, hat das auch so gefunzt :ugly:
verbesserungen sind erwünscht ;)
IMHO ist nur das allererste Paket NEW alle folgenden sind ESTABLISHED
SYN ---> NEW
ACK,SYN <--- ESTABLISHED
ACK ---> ESTABLISHED
ACK <--- ESTABLISHED
ACK ---> ESTABLISHED
ACK <--- ESTABLISHED
ACK,FIN ---> ESTABLISHED
FIN <--- ESTABLISHED
Wenn das ACK und das SYN Bit gesetzt sind ist die Verbindung noch im Aufbau und nicht established (Im Sinne des TCP Protokolls)
Was Iptables als established bezeichnen... hmm gute Frage;)
Ich guck mich mal um...
mfg
cane
SniperRifle
06.01.03, 13:30
hmmm, ich bin immer noch der meinung, dass für _iptables_ das ack,syn-paket bereits established ist. Denn ... mit
-----
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -P OUTPUT DROP
iptables -P INPUT DROP
-----
werden ja alle ausgehenden verbindungen zugelassen und auch die ack,syn-pakete, die reinkommen, werden akzeptiert.
Können die fehler daran liegen, dass eine übermenge an Verbindungen verwaltet werden müssen? Es sind laut netstat ~300. Aber irgendwie kann ich das nicht glauben, dass iptables das nicht packt :confused:
Dann änder doch mal
-----
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -P OUTPUT DROP
iptables -P INPUT DROP
-----
in
-----
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -P OUTPUT DROP
iptables -P INPUT DROP
-----
und guck obs funktioniert...
mfg
cane
SniperRifle
06.01.03, 13:49
nö :D
weil nämlich die firewall dann ja umsonst ist. Wenn ich das NEW bei INPUT und OUTPUT reinmache, werden ja alle Verbindungen erlaubt und das ist ja nicht sinn der firewall;)
mein vorschlag (wo das NEW beim INPUT fehlt), funzt ja auch einwandfrei. sowohl bei maskierten connections, als auch bei den connections vom bzw. zum Router.
z.b. wenn ich vom Router aus eine FTP-verbindung zu irgendeinem FTP aufbaue, wird das zurückkommende ack,syn-paket von der regel "iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT" durchgelassen.
NUR die ack,syn-paket die zum _mldonkey_ zurückkommen nimmt er nicht an.
:rolleyes: :p :confused: :eek: :cool: ;) :ugly:
Wollte ja auch nur wissen ob der Fehler nicht woanders liegt
also die Mldonkey Verbindung sonst funktioniert.
Also das Prob ist: Das erste Paket (das SYN-Paket) sendet der mldonkey an tcp4662 irgendeines anderen donkeyclienten. Das Antwortpaket, das von dem andern Clienten zurückkommt, ist das ACK,SYN-Paket (von tcp4662 bei ihm auf irgendeinen port bei mir), und genau dieses Paket wird geblockt.
Welchen Port?
Vielleicht liegt es daran dass das eingehende ACK SYN Packet nicht auf dem Port ankommt von dem aus dass ACK Packet gesendet wurde...
Ist nur ne Vermutung aber könnte ich mir vorstellen dass es daran liegt.
Vielleicht kann man die Ports ja in Mldonkey einstellen?
Alle Infos rund um Mldonkey findest Du auf http://www.micha-cambeis.de/mldonkey.htm
Wenn Dir die Seite oder die Mailingliste deren Adresse auch auf der Seite zu finden ist nicht weiterhilft dann weiß ich
es auch nicht...
Wenn ich meine DSL Anbindung hab werd ich mir auch Mldonkey installieren (Nachdem ich die Features kenne)
Viel Glück und meld Dich - warums nicht geklappt hat interessiert mich...
cane
Kann es vielleicht am pid liegen. In meiner manpage wird dieses feature als experimental betitelt.
SniperRifle
07.01.03, 09:44
@cane
Danke für den Link, ich werd dann wohl auch mal die mailingliste bemühen.
Vielleicht liegt es daran dass das eingehende ACK SYN Packet nicht auf dem Port ankommt von dem aus dass ACK Packet gesendet wurde...
Du meinst SYN, gelle ;)
Das ist eine gute Idee. Evtl. ist das die Lösung. Ich hab mal auf ein gedropptes Paket gewartet und dann ein netstat gemacht:
Jan 7 10:25:43 DSL-Gateway kernel: NEWIN=ppp0 OUT= MAC= SRC=80.133.126.200DST=217.80.180.181 LEN=52 TOS=0x00 PREC=0x00 TTL=123 ID=8066 DF PROTO=TCP SPT=16384 DPT=4155 WINDOW=17203 RES=0x00 ACK FIN URGP=0
tcp 0 0 217.80.180.181:4155 80.133.126.200:4662 VERBUNDEN 12860/mldonkey aus (0.00/0/0)
Ja, auch ACK,FIN Pakete zieht iptables aus dem verkehr ;)
Die verbingung besteht auf remote tcp 4662, aber das paket kommt von remote 16384. Klar, dass das von iptables nicht zu der verbindung gezählt wird. Aber warum macht der donkey das?
UND (!) ich habe noch eine regel eingebaut "iptables -A INPUT -m state --state NEW -j LOG --log-prefix NEW" und dieses Paket wird von dieser Regel geloggt. Also ein ACK,FIN sieht iptables als verbindungsaufbauendes Paket an :confused:
Eigentlich dachte ich, dass verbindungsaufbauende pakete (SYN) NEW sind, verbindungszugehörige (ack,syn; ack; ack,fin; fin) ESTABLISHED und verwandte RELATED und diejenigen, die nicht zugeordnet werden können sind INVALID und diese ACK,FIN sollte ja dann eigentlich INVALID sein, oder nicht?
Das versteh mal einer :D
@jinto
stimmt, das owner-modul ist noch als experimental eingestuft. Aber die owner-Abfrage mache ich ja nur für die SYN-Pakete, welche mein mldonkey rausschickt. Und das funzt ja einwandfrei; es werden keine ausgehenden Verbindungen geblockt.
ich werde das jetzt noch weiter verfolgen, wie das mit den ACK,FIN bzw. ACK,SYN paketen ist. mal sehen, was sich da noch aufspüren lässt :)
@SniperRifle
Also ich habe mir dein Script jetzt nochmals genauer angesehen. Frage mich allerdings, warum du überhaupt einen PF einsetzt. Es hat für mich den Anschein, dass der Zugang Internet/LAN genau die gelichen Filterregeln besitzt (z. B. kann über das Internet auf den mldonkey Webserver Port zugegriffen werden).
Teste bitte mal folgende Zeilen:
iptables -I INPUT -i ppp0 -m state --state NEW -p tcp --dport 4661 -j ACCEPT
iptables -I INPUT -i ppp0 -m state --state NEW -p tcp --dport 4662 -j ACCEPT
iptables -I INPUT -i ppp0 -m state --state NEW -p tcp --dport 4663 -j ACCEPT
iptables -I INPUT -i ppp0 -m state --state NEW -p udp --dport 4665 -j ACCEPT
iptables -I INPUT -i ppp0 -m state --state NEW -p udp --dport 4666 -j ACCEPT
und wenn das nichts hilft zusätzlich noch:
iptables -I OUTPUT -o ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
Gruß
SniperRifle
10.01.03, 17:00
hi,
das mit den offenen ports werd ich mir nochmal genauer anschauen ;)
Nun zu deinen Regeln:
Ich hab das so gemacht, dass ich zuerst für den mldonkey nichts erlaubt habe und ihn dann laufen ließ. Dann hab ich im Syslog geguckt, welche ports angesprochen werden und habe dann auch genau die freigeschaltet. Und es wurde nur incoming UDP4662 und TCP4666 verlangt. outgoing lass ich ja alles zu, was vom mldonkey kommt.
Aber ich hab trotzdem nochmal deine Regeln eingebaut, aber es bringt keinerlei Veränderung. Zumal sie ja nur die incoming connections regeln.
Hier noch ein paar Zeilen aus syslog + netstat (natürlich gleichzeitig):
Jan 10 17:43:14 DSL-Gateway kernel: STATENEWIN=ppp0 OUT= MAC= SRC=24.191.166.103 DST=217.80.180.133 LEN=40 TOS=0x00 PREC=0x00 TTL=50 ID=49130 DF PROTO=TCP SPT=28303 DPT=2438 WINDOW=5749 RES=0x00 ACK FIN URGP=0
tcp 0 0 217.80.180.133:2438 24.191.166.103:4662 TIME_WAIT - timewait (49,98/0/0)
Jan 8 23:12:26 DSL-Gateway kernel: STATENEWIN=ppp0 OUT= MAC= SRC=80.34.71.157 DST=217.80.180.181 LEN=64 TOS=0x00 PREC=0x00 TTL=113 ID=37041 DF PROTO=TCP SPT=4662 DPT=2865 WINDOW=64240 RES=0x00 ACK SYN URGP=0
Jan 8 23:12:29 DSL-Gateway kernel: STATENEWIN=ppp0 OUT= MAC= SRC=80.34.71.157 DST=217.80.180.181 LEN=64 TOS=0x00 PREC=0x00 TTL=113 ID=37119 DF PROTO=TCP SPT=4662 DPT=2865 WINDOW=64240 RES=0x00 ACK SYN URGP=0
Jan 8 23:12:33 DSL-Gateway kernel: STATENEWIN=ppp0 OUT= MAC= SRC=80.33.49.24 DST=217.80.180.181 LEN=40 TOS=0x00 PREC=0x00 TTL=114 ID=57278 PROTO=TCP SPT=4662 DPT=2870 WINDOW=0 RES=0x00 ACK RST URGP=0
Jan 8 23:12:35 DSL-Gateway kernel: STATENEWIN=ppp0 OUT= MAC= SRC=80.34.71.157 DST=217.80.180.181 LEN=64 TOS=0x00 PREC=0x00 TTL=113 ID=37284 DF PROTO=TCP SPT=4662 DPT=2865 WINDOW=64240 RES=0x00 ACK SYN URGP=0
tcp 0 1 217.80.180.181:2865 80.34.71.157:4662 SYN_SENT 12860/mldonkey ein (5,30/1/0)
Hier werden ja eindeutig Pakete gedroppt, welche zu aktiven Verbindungen gehören, und ich verstehe das einfach nicht.
Ich habe noch "iptables -A INPUT -m state --state NEW -j LOG --log-prefix STATENEW" ganz ans ende gestellt, und wie oben zu sehen, wurden diese Pakete als NEW eingestuft, was aber wohl schlecht sein kann. Damit ist ja auch klar, warum sie von --state ESTABLISHED,RELATED -j ACCEPT nicht durchgelassen werden.
Dann würd mich noch interessieren was das DF, was ich fett gemacht habe, bedeuten soll. Das ist bei dem ACK,RST-Paket ja nicht drin.
Und nochmal zum Verständnis: Kommt das flag RST nur in verbindung mit ACK vor und nur als Antwort auf ein SYN Paket, um die Anfrage abzuweisen?
Die Ports die benötigt werden findest du auf http://www.edonkey2000.com und auf der MLDonkey Seite (mldonkey verwendet statt 4663/udp 4666/udp).
Ich habe noch "iptables -A INPUT -m state --state NEW -j LOG --log-prefix STATENEW" ganz ans ende gestellt, und wie oben zu sehen, wurden diese Pakete als NEW eingestuft, was aber wohl schlecht sein kann. Damit ist ja auch klar, warum sie von --state ESTABLISHED,RELATED -j ACCEPT nicht durchgelassen werden. Nein, ist es nicht. Woher willst du überhaupt wissen, dass diese IP-Pakete für dich bestimmt sind?
Aber um mal in eine andere Richtung zu gehen:
Hast du dir den Kernel selbst gebaut? was bringt ein lsmod? und versuche zu meinen genannten Regeln zusätzlich noch ein:
iptables -I OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Irgendwie habe ich bei dem owner Modul bedenken.
SniperRifle
10.01.03, 20:03
Nein, ist es nicht. Woher willst du überhaupt wissen, dass diese IP-Pakete für dich bestimmt sind?
Ich gehe davon aus, dass sie für mich sind, weil netstat mir z.b.
tcp 0 1 217.80.180.181:2865 80.34.71.157:4662 SYN_SENT 12860/mldonkey ein (5,30/1/0)
liefert und ich im syslog folgendes geblocktes Paket finde:
Jan 8 23:12:26 DSL-Gateway kernel: STATENEWIN=ppp0 OUT= MAC= SRC=80.34.71.157 DST=217.80.180.181 LEN=64 TOS=0x00 PREC=0x00 TTL=113 ID=37041 DF PROTO=TCP SPT=4662 DPT=2865 WINDOW=64240 RES=0x00 ACK SYN URGP=0
Warum sollte dieses Paket nicht für mich sein?
Mein kernel ist selbst gebaut.
lsmod bringt:
Module Size Used by
ide-cd 27168 0 (autoclean)
cdrom 28448 0 (autoclean) [ide-cd]
ipt_owner 1408 4 (autoclean)
vfat 9200 0 (autoclean)
fat 31520 0 (autoclean) [vfat]
ipt_MASQUERADE 1584 1 (autoclean)
ipt_multiport 1008 0 (autoclean)
ipt_state 896 75 (autoclean)
ipt_LOG 3744 5 (autoclean)
iptable_filter 2000 0 (autoclean) (unused)
ip_conntrack_ftp 3728 0 (unused)
iptable_nat 16368 0 [ipt_MASQUERADE]
ip_conntrack 15600 3 [ipt_MASQUERADE ipt_state ip_conntrack_ftp iptable_nat]
ip_tables 11520 9 [ipt_owner ipt_MASQUERADE ipt_multiport ipt_state ipt_LOG iptable_filter iptable_nat]
ppp_async 6640 1 (autoclean)
ppp_generic 18464 3 (autoclean) [ppp_async]
slhc 5120 0 (autoclean) [ppp_generic]
ne 6944 1
8390 6480 0 [ne]
8139too 12768 1
Was gefällt dir an dem owner-modul nicht? Ich hatte noch eine Version meines FW-Skriptes ohne owner-matchin und es traten exakt dieselben probs auf.
SniperRifle
16.01.03, 15:09
Hat keiner mehr ne Idee...?? :(
Scheinbar nicht...
Schreib doch eine Mail an einen der Iptables Entwickler;)
cane
Sorry, irgendwie gehen mir manchmal einzelne Threads "verloren".
Was gefällt dir an dem owner-modul nicht? Der experimental Status ist es was mich stört, ich habe deswegen kein so richtiges vertrauen (hinzu kommt, dass es bei mir ja funktioniert, allerdings ohne owner Modul).
Hast du es denn mal mit meiner Output Zeile versucht?
SniperRifle
17.01.03, 14:21
Jo, ich hab mal deine OUTPUT-Regel ausprobiert, aber das bringt keinerlei Veränderung.
Vielleicht sollte ich mal iptables upgraden?
Also wie bereits gesagt mit den folgenden Zeilen funktioniert es bei mir:
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state NEW -p tcp --dport 4661 -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state NEW -p tcp --dport 4662 -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state NEW -p tcp --dport 4663 -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state NEW -p udp --dport 4665 -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state NEW -p udp --dport 4666 -j ACCEPT
ich verwende Kernel 2.4.18 mit iptables 1.2.6a.
HTH
SniperRifle
18.01.03, 09:16
Bei mir läuft der mldonkey ja auch, aber ein gewisser Teil der Antwortpakete wird gedroppt. Ich vermute, dass mir dadurch ein paar Quellen verloren gehen.
Was mich aber am meisten an der Sache stört, ist, dass ich einfach nicht verstehe, warum diese Pakete über den Jordan gehen.
Muss ich beim Upgrade von iptables irgendwas besonderes beachten? Vielleicht schafft das ja Abhilfe.
Hi SniperRifle
könnte es nicht sein, das diese antwortpakete gar nicht zu einer von dir gestarteten verbindung gehören? du arbeitest ja mit connection tracking. dabei werden die von innen gestarteten verbindungen ja in einer extra tabelle *gespeichert*. anhand dieser entscheidet dein paketfilter dann, was NEW, ESTABLISHED etc. ist.
die entscheidung was *rein darf* wird also nicht anhand der tcp flags gefällt, sondern anhand der tabelle. meine vermutung ist jetzt, das diese syn,ack pakete zwar antwortpakete sind aber eben nicht zu einer von dir gestarteten verbindung gehören. mögliche erklärung => die pakete gehören zu einer verbindung des *ip vorbesitzers*.
du kannst ja deinen paketfilter mal von connection tracking auf *tcp flags filterung* umstellen.
iptables -A INPUT -i ppp0 -p tcp --dport 4661 ! --syn -j ACCEPT
dann dürften eigentlich keine ack,syn pakete mehr gedropt werden.
ps: hoffentlich hab ich mich jetzt nicht völlig blamiert :D
Gruß HL
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.