DSL Verbindung wird (oft) nicht getrennt
Hallo, Umgebung: Suse 8.1, squid, samba, pppd, Dial-on-demand, idel 60 sec, TDSL Problem: "Einfache Verbindnungen" (Verbindung durch ein ping hergestellt und am Leben gehalten) werden nach 60 sec getrennt (wenn für 60 sec kein Traffic festgestellt wird). Und so soll es auch sein. "Andere Verbindungen" (z.B. duch 5 min surfen) kommen nicht mehr auf 60 sec Idle-Time und werden folglich nicht getrennt. Folgendes habe ich festgestellt (mit ethereal): Irgendwann gibt es eine erste TCP Anfrage (meistens - evtl. auch immer) von einer IP eines T-Online Nutzers (Source: xxxxdip.t-dialin.net, Dest; yyydip.t-dialin.net; yyyy = wir). Das wiederholt sich i.A. mehrmals. Später kommen weitere Anfragen von anderen Orten dazu, z.B. x.x.x.nl, x.x.x.uk, x.x.x.x.ch, x.hansenet.x.x - x steht für irgendwas was ich mir nicht merken kann und will). Einmal ganz genau: Source: p213.54.70.80.tisdip.tiscali.de Destination: pD9538B05.dip-t-dialin.net Protocol: TCP Info: 64557 > 4662 [SYN] Seq=252962097 Ack=0 Win=32768 Len=0 Die Info der Antwort lautet: 4662 > 64557 [RST, Ack] Seq=0 Ack=252962098 Win=0 Len=0 Frage 1: Es sieht für mich so aus, als würde sich die Existenz der uns zugeteilten IP herumsprechen. Was wollen die bei uns. Verbieten kann ich solche Anfragen sicherlich nicht, aber kann ich dem pppd sagen dass er sie ignorieren soll? Frage 2: Was bedeutet die "Info"? Eine Anfrage auf Port 4662? Was bedeuten SYN, RST, ACK, Seq, Win, Len? 4662 = eine edonkey = file sharing Anfrage? Habe folgendes versucht: In /etc/ppp/options die active-filtering Lösung aus der Ct eingebaut: active-filter 'outbound' active-filter 'not icpm[icmptype] == icmp-unreach' active-filter 'not tcp[tcpflags] & (tcp-rst | tcp-fin) != 0' Ich denke das ist mit der Suse-Lösung identisch (oder?). active-filter 'outbound and not icmp[0] == 3 ans not tcp[13] & 4 != 0' Samba habe ich "beruhigt" (durch hosts allow und bind interfaces); gustavo und Konsorten kriegen jetzt ein denied. SuseFirewall2 hatte ich mal versuchsweise an, dass gab aber andere Probleme. Um Firewall möchte ich mich eigentlich erst kümmern, wenn der Rest funktioniert. Nach 3 Tagen googlen und lesen geht mir jetzt langsam die Puste aus. Die Hitze scheint meinem Hirn ebenfalls nicht gerade gut zu tun, denn Iddeen produziert es jetzt keine mehr. Ich hoffe jemand aus der Liste kann mich in die Richtige Richtung schubsen und verbleibe euer Michael
Hallo,
Michael Helms
Hallo,
Umgebung: Suse 8.1, squid, samba, pppd, Dial-on-demand, idel 60 sec, TDSL
Problem:
"Einfache Verbindnungen" (Verbindung durch ein ping hergestellt und am Leben gehalten) werden nach 60 sec getrennt (wenn für 60 sec kein Traffic festgestellt wird). Und so soll es auch sein.
"Andere Verbindungen" (z.B. duch 5 min surfen) kommen nicht mehr auf 60 sec Idle-Time und werden folglich nicht getrennt.
Folgendes habe ich festgestellt (mit ethereal): Irgendwann gibt es eine erste TCP Anfrage (meistens - evtl. auch immer) von einer IP eines T-Online Nutzers (Source: xxxxdip.t-dialin.net, Dest; yyydip.t-dialin.net; yyyy = wir). Das wiederholt sich i.A. mehrmals. Später kommen weitere Anfragen von anderen Orten dazu, z.B. x.x.x.nl, x.x.x.uk, x.x.x.x.ch, x.hansenet.x.x - x steht für irgendwas was ich mir nicht merken kann und will).
Einmal ganz genau: Source: p213.54.70.80.tisdip.tiscali.de Destination: pD9538B05.dip-t-dialin.net Protocol: TCP Info: 64557 > 4662 [SYN] Seq=252962097 Ack=0 Win=32768 Len=0
Die Info der Antwort lautet: 4662 > 64557 [RST, Ack] Seq=0 Ack=252962098 Win=0 Len=0
Frage 1: Es sieht für mich so aus, als würde sich die Existenz der uns zugeteilten IP herumsprechen. Was wollen die bei uns. Verbieten kann ich solche Anfragen sicherlich nicht, aber kann ich dem pppd sagen dass er sie ignorieren soll?
Dei Adressen werden ja dynamisch vergeben, d.h. deine Adresse wurde einige Minuten vorher von einem anderen Host benutzt. Pppd kannst du den Empfang nicht verbieten, da er die Daten nicht sieht.
Frage 2: Was bedeutet die "Info"? Eine Anfrage auf Port 4662? Was bedeuten SYN, RST, ACK, Seq, Win, Len? 4662 = eine edonkey = file sharing Anfrage?
Das sind hergestellte Verbindungen von der Source zur Destination, von Port 64557 an Port 4662 SYN = synchronize, also eine von fremder Seite aktivierte Verbindung RST = reset, d.h. das Datenpaket enthält Fehler oder ist nicht für dich bestimmt, daher wird der Header verworfen. Ack = acknowlegement, die Bestätigung das der Verbindung hergestellt wird. WIN = Window Size, etwas vereinfacht ist dies die Bandbreite, die für ein Datenpaket bereitgestellt wird. Seq = Sequenz, im Grunde eine Nummerierung der Datenpakete Als ganz schnell Paketfilter aktivieren, damit diese Verbindungsversuche zurückgewiesen werden. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Dieter Kluenter schrieb:
Als ganz schnell Paketfilter aktivieren, damit diese Verbindungsversuche zurückgewiesen werden.
Du meinst SuSEfirewall2 ?? Oder wie aktiviert man Paketfilter ?? Ich guck mal ob ich das jetzt alles richtig verstanden habe. Es kommen Anfragen (z.B. port 4662) an unseren Rechner. Aufgrund der Einstellungen in /etc/ppp/options werden die eintreffenden Pakete vom pppd nicht beachtet. Aber unser Rechner antwortet. Die Antwort wird beachtet. Folge: die Idle-Time wird nicht erreicht. Es ist also wichtig bereits die Anfragen abzufangen (womit die Einträge in /etc/ppp/options überflüssig werden, so das Abfangen vor dem pppd geschieht); mit einem Paketfilter. In der Annahme das mit Packetfilter SuSEfirewall2 gemeint ist, habe ich die mit YaST2 konfiguriert (nach bestem Wissen und Gewissen). Dann hab ich noch in /etc/sysconfig/SuSEfirewall2 die Services für squid und samba freigegeben (FW_SERVICE_SQUID="yes", FW_SERVICE_SAMBA="yes", FW_SERVICES_EXT/DMZ/INT_TCP="139 3128"). Nach letzterem habe ich die FW mit "SuSEFirewal2 stop/start" neu gestartet. Auf den ersten Blick ist es etwas ruhiger geworden, aber auflegen ist immer noch nicht. Ein Blick in ethereal enthüllt eine menge DNS Anfragen die von uns ausgehen. Info: Standard query PTR ppp0.wvigmbh.de. Schätze das passt zur Firewall-Start-Meldung: iptables: No chain/target/match by that name iptables v1.2.7a: host/network 'ppp0' not found Was mach ich falsch??? Desweiteren: Wird bei laufender FW die Verbindung getrennt stirbt auch meine VNC-Sitzung. Dazu hab ich rausgefunden, das im ip-up 2 Einträge der Form: start_firewall sind. Einer in der ip-up)[war auskommentiert] und einer in der ip-down) Sektion. Wieso Start in der ip-down) Sektion? Wieso sind hier überhaupt Einträge? Reicht es nicht die FW beim booten zu starten un dann ist gut? Sorry wenn ich hier dummes Zeug fasele oder dumme Fragen stelle, aber mit Firewall hab ich mich bis jetzt noch nicht beschäftigt. Bin immer davon ausgegangen das mich eine dynamich von der Telekom vergebene IP davor bewart eine FW aufsetzen zu müssen, und bei unserm alten ISDN Zugang war es auch so (wohl weil kaum jemand mit ISDN noch edonky und ähnliches benutzt). Grüße Michael
Hallo,
Michael Helms
Dieter Kluenter schrieb:
Als ganz schnell Paketfilter aktivieren, damit diese Verbindungsversuche zurückgewiesen werden.
Du meinst SuSEfirewall2 ?? Oder wie aktiviert man Paketfilter ??
Paketfilter sind Kernelmodule, es gibt zwei, ipchains und iptables (früher ipfilter genannt). SuSEfirewall ist auch nur ein Script, das iptables mit entsprechenden Filterregeln aktiviert.
Ich guck mal ob ich das jetzt alles richtig verstanden habe.
Es kommen Anfragen (z.B. port 4662) an unseren Rechner. Aufgrund der Einstellungen in /etc/ppp/options werden die eintreffenden Pakete vom pppd nicht beachtet. Aber unser Rechner antwortet. Die Antwort wird beachtet. Folge: die Idle-Time wird nicht erreicht.
pppd ist nur ein Daemon, der vom System aufgerufen wird, um eine point to point Verbindung zu einer vorgebenen Adresse herzustellen und dabei dann noch Authentifizierungsdaten prüft und überträgt, TCP/IP Datenpakete können von pppd nicht analysiert werden. Wenn also ein lokaler Prozess versucht, ein Datenpaket an eine fremde Adresse zu senden, wird pppd aktiv und stellt die Initialverbindung zum Einwahlserver her und hält diese Verbindung offen solange vom lokalen System Daten nach außen gesandt werden. Du hast richtig erkannt, daß die Idle Time nicht erreicht wird, solange Datenpakete nach außen fließen.
Es ist also wichtig bereits die Anfragen abzufangen (womit die Einträge in /etc/ppp/options überflüssig werden, so das Abfangen vor dem pppd geschieht); mit einem Paketfilter.
So ungefähr, wobei Paketfilter drei Möglichkeiten haben, 1. das Datenpaket zu akzeptieren und an den zuständigen Prozess weiterzuleiten, 2. das Datenpaket nicht zu akzeptieren und dem Absender diese mitzuteilen, 3. das Datenpaket nicht zu akzeptieren und keine weitere Aktion zu veranlassen.
In der Annahme das mit Packetfilter SuSEfirewall2 gemeint ist, habe ich die mit YaST2 konfiguriert (nach bestem Wissen und Gewissen). Dann hab ich noch in /etc/sysconfig/SuSEfirewall2 die Services für squid und samba freigegeben (FW_SERVICE_SQUID="yes", FW_SERVICE_SAMBA="yes", FW_SERVICES_EXT/DMZ/INT_TCP="139 3128").
Ich muß gestehen daß ich SuSEfirewall2 nicht eingehend kenne und daher auch nicht weiß, was diese Regeln bewirken sollen, also ob ein Reject, drop oder accept.
Nach letzterem habe ich die FW mit "SuSEFirewal2 stop/start" neu gestartet. Auf den ersten Blick ist es etwas ruhiger geworden, aber auflegen ist immer noch nicht. Ein Blick in ethereal enthüllt eine menge DNS Anfragen die von uns ausgehen.
Ja, daher wird die Idle Time nicht erreicht. Das sind möglicherweise WINS Anfragen auf Port 135-137 der Windows Clients, prüfe das mal.
Info: Standard query PTR ppp0.wvigmbh.de. Schätze das passt zur Firewall-Start-Meldung: iptables: No chain/target/match by that name iptables v1.2.7a: host/network 'ppp0' not found
Dazu kann ich wenig sagen, da ich nicht weiß, wie das Device in das Firewallscript eingebunden wird.
Was mach ich falsch???
Schwer zu sagen, vermutlich hast du nur die Filterregeln nicht verstanden.
Desweiteren: Wird bei laufender FW die Verbindung getrennt stirbt auch meine VNC-Sitzung. Dazu hab ich rausgefunden, das im ip-up 2 Einträge der Form: start_firewall sind. Einer in der ip-up)[war auskommentiert] und einer in der ip-down) Sektion. Wieso Start in der ip-down) Sektion? Wieso sind hier überhaupt Einträge? Reicht es nicht die FW beim booten zu starten un dann ist gut?
Ich vermute, daß SuSE das Firewallscript zweigeteilt hat, um die bei der Einwahl dynamisch zugewiesenen Adresse einzubinden und dann bei Beendigung diese Adresse wieder zu löschen.
Sorry wenn ich hier dummes Zeug fasele oder dumme Fragen stelle, aber mit Firewall hab ich mich bis jetzt noch nicht beschäftigt. Bin immer davon ausgegangen das mich eine dynamich von der Telekom vergebene IP davor bewart eine FW aufsetzen zu müssen, und bei unserm alten ISDN Zugang war es auch so (wohl weil kaum jemand mit ISDN noch edonky und ähnliches benutzt).
Das ist kein dummes Zeug, aber mit Netzwerksicherheit solltest du dich beschäftigen. Eine dynamisch zugewiesene Adresse bewahrt nicht vor einem Einbruchsversuch. Wenn du dich eingehender mit iptables beschäftigen möchtest, frage mal David Haller, er hat vor ca. 2 Jahren mal modulariserte Scripts geschrieben und veröffentlicht. Das Mailarchiv ist mit Sicherheit voll von iptables Regeln, da mußt du nur mal suchen. Wenn du dann die Funktion von Paketfiltern und Regeln verstanden hast, kannst du auch SuSEfirewall für dein System richtig konfigurieren. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
* Donnerstag, 07. August 2003 um 12:21 (+0200) schrieb Michael Helms:
Es ist also wichtig bereits die Anfragen abzufangen (womit die Einträge in /etc/ppp/options überflüssig werden, so das Abfangen vor dem pppd geschieht); mit einem Paketfilter.
Es können mit dem Paketfilter keine eingehenden Pakete _vor_ dem
ppp-Interface abgefangen werden, da der Paketfilter erst dahinter
filtert.
Mit einem Paketfilter kannst du die Dial-On-Demand-Problematik nicht
lösen, du musst das "active-filter"-Feature des pppd nutzen (Oder
den diald, aber das ist eine ganz andere Baustelle...).
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Mit, 2003-08-06 um 16.26 schrieb Michael Helms:
Frage 1: Es sieht für mich so aus, als würde sich die Existenz der uns zugeteilten IP herumsprechen. Was wollen die bei uns. Verbieten kann ich solche Anfragen sicherlich nicht, aber kann ich dem pppd sagen dass er sie ignorieren soll?
Ich bin kein Netzwerkguru, aber die Anfragen kommen vom eDonkey-Netzwerk, eine Tauschbörse. Du bekommst wohl oft eine IP, welche kurz (wobei kurz mehrere Stunden sein kann) ein Börsianer benutzt hat. Diese IP wurde anderen eDonkey-Nutzern mitgeteilt als Quelle eines Files. Und diese fragen nun bei Dir nach "noch da?". Ich wüsste nicht, wie man das verhindern kann. MfG, Thomas B.
----- Original Message -----
From: "Thomas Bitschnau"
Am Mit, 2003-08-06 um 16.26 schrieb Michael Helms:
Frage 1: Es sieht für mich so aus, als würde sich die Existenz der uns zugeteilten IP herumsprechen. Was wollen die bei uns. Verbieten kann ich solche Anfragen sicherlich nicht, aber kann ich dem pppd sagen dass er sie ignorieren soll?
Ich bin kein Netzwerkguru, aber die Anfragen kommen vom eDonkey-Netzwerk, eine Tauschbörse. Du bekommst wohl oft eine IP, welche kurz (wobei kurz mehrere Stunden sein kann) ein Börsianer benutzt hat. Diese IP wurde anderen eDonkey-Nutzern mitgeteilt als Quelle eines Files. Und diese fragen nun bei Dir nach "noch da?".
Ich wüsste nicht, wie man das verhindern kann.
MfG,
Thomas B.
hmmmm versuch doch mal den port 4662 zu sperren das is der xDonkey Port (x = jegliche Version des elektronischen esels) mfg Matthias
* Mittwoch, 06. August 2003 um 16:26 (+0200) schrieb Michael Helms:
Habe folgendes versucht:
In /etc/ppp/options die active-filtering Lösung aus der Ct eingebaut: active-filter 'outbound' active-filter 'not icpm[icmptype] == icmp-unreach' active-filter 'not tcp[tcpflags] & (tcp-rst | tcp-fin) != 0'
Ich denke das ist mit der Suse-Lösung identisch (oder?). active-filter 'outbound and not icmp[0] == 3 ans not tcp[13] & 4 != 0'
Ich glaube, die Ct-Lösung kann so nicht funktionieren, denn AFAIK
kann der pppd nicht mehr als eine "active-filter ..."-Zeile auswerten.
Schreibe doch einmal die obigen drei Filter-Ausdrücke "and"-verknüpft
in eine Zeile...
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Michael Helms wrote:
"Einfache Verbindnungen" (Verbindung durch ein ping hergestellt und am Leben gehalten) werden nach 60 sec getrennt (wenn für 60 sec kein Traffic festgestellt wird). Und so soll es auch sein.
gut so.
"Andere Verbindungen" (z.B. duch 5 min surfen) kommen nicht mehr auf 60 sec Idle-Time und werden folglich nicht getrennt.
Das ist nicht schlimm, wenn "nach" dem Surfen der Timeout greift.
Folgendes habe ich festgestellt (mit ethereal): Irgendwann gibt es eine erste TCP Anfrage (meistens - evtl. auch immer) von einer IP eines T-Online Nutzers (Source: xxxxdip.t-dialin.net, Dest; yyydip.t-dialin.net; yyyy = wir). Das wiederholt sich i.A. mehrmals. Später kommen weitere Anfragen von anderen Orten dazu, z.B. x.x.x.nl, x.x.x.uk, x.x.x.x.ch, x.hansenet.x.x - x steht für irgendwas was ich mir nicht merken kann und will).
Einmal ganz genau: Source: p213.54.70.80.tisdip.tiscali.de Destination: pD9538B05.dip-t-dialin.net Protocol: TCP Info: 64557 > 4662 [SYN] Seq=252962097 Ack=0 Win=32768 Len=0
Die Info der Antwort lautet: 4662 > 64557 [RST, Ack] Seq=0 Ack=252962098 Win=0 Len=0
Frage 1: Es sieht für mich so aus, als würde sich die Existenz der uns zugeteilten IP herumsprechen. Was wollen die bei uns. Verbieten kann
Nein. Wenn ich edonkey richtig verstehe, merken sich die clients ihre Kollegen, mit denen sie _mal_ Kontakt hatten und Fragen diese wieder an. Da Du eine Adresse aus einem dynamischen Pool hast, reicht es aus, wenn einer deiner Vorgänger so eine Adresse hatte.
ich solche Anfragen sicherlich nicht, aber kann ich dem pppd sagen dass er sie ignorieren soll?
Ja, aber ... (s.u.)
Frage 2: Was bedeutet die "Info"? Eine Anfrage auf Port 4662? Was bedeuten SYN, RST, ACK, Seq, Win, Len? 4662 = eine edonkey = file sharing Anfrage?
Syn ist 'ne Verbindungsanfrage, Ack steht für Acknowledge. Und 4662 ist edonkey. Den wirst Du auch nicht so schnell los.
Habe folgendes versucht:
In /etc/ppp/options die active-filtering Lösung aus der Ct eingebaut: active-filter 'outbound' active-filter 'not icpm[icmptype] == icmp-unreach' active-filter 'not tcp[tcpflags] & (tcp-rst | tcp-fin) != 0'
Ich denke das ist mit der Suse-Lösung identisch (oder?). active-filter 'outbound and not icmp[0] == 3 ans not tcp[13] & 4 != 0'
may be, aber Dein Problem ist, das Du (wie ich oben deinem Trace entnehme) auf den Syn 'ne Antwort schickst. Damit der Timeout vom pppd greift (mit diesen Filteroptionen) DARFST du nichts selber rausschicken. Du musst IMO einen Paketfilter (Firewall) wie SuSEfirewall verwenden, die die Pakete direkt "hinter" dem pppd verwirft und nicht bis zum "Ablehnen" kommt. Damit erkennt der pppd den incoming Traffic, setzt dann aber seinen Idle Timer nicht zurück, weil die Filterkriterien greifen. Nun musst Du aber sicherstellen, das diese Pakete einfach nur verworfen werden und NICHT zu einer Antwort führen. Auch eine Ablehnung auf einen Verbindungsaufbau ist eine Antwort. Das ist _mein_ Verständnis der Materie. Ich bin allerdings weder ein "echter" Protokoll-Experte noch wirklich sattelfest mit netfilter und Konsorten. Falls ich also hier völligen Blödsinn rede, ignoriert mich einfach. Ich kann nur sagen: Bei mir (DSL bei T-Online) wird mit pppd-Filtering und SuSEfirewall2 prima nach 300sec. getrennt. Zuverlässig! Immer! Andreas PS: Bitte nicht wieder eine Diskussion darüber, ob SuSEfirewall 'ne echte Firewall ist oder nur ein Paketfilter. Ich weiss, was eine echte Firewall ist. Schliesslich haben wir so'n Teil in der Firma. PPS: Nichtsdestoweniger läuft die SuSEfirewall bei mir zu Hause zuverlässig und stabil und tut seinen Job.
Andreas Kyek schrieb:
Michael Helms wrote:
Source: p213.54.70.80.tisdip.tiscali.de Destination: pD9538B05.dip-t-dialin.net Protocol: TCP Info: 64557 > 4662 [SYN] Seq=252962097 Ack=0 Win=32768 Len=0
Die Info der Antwort lautet: 4662 > 64557 [RST, Ack] Seq=0 Ack=252962098 Win=0 Len=0
....
Habe folgendes versucht:
In /etc/ppp/options die active-filtering Lösung aus der Ct eingebaut: active-filter 'outbound' active-filter 'not icpm[icmptype] == icmp-unreach' active-filter 'not tcp[tcpflags] & (tcp-rst | tcp-fin) != 0'
Ich denke das ist mit der Suse-Lösung identisch (oder?). active-filter 'outbound and not icmp[0] == 3 ans not tcp[13] & 4 != 0'
may be, aber Dein Problem ist, das Du (wie ich oben deinem Trace entnehme) auf den Syn 'ne Antwort schickst. Damit der Timeout vom pppd greift (mit diesen Filteroptionen) DARFST du nichts selber rausschicken. Du musst IMO einen Paketfilter (Firewall) wie SuSEfirewall verwenden, die die Pakete direkt "hinter" dem pppd verwirft und nicht bis zum "Ablehnen" kommt.
Ja, auf das Syn wird ne Antwort geschickt. Und das Syn wird (hoffentlich) ignoriert (active-filter 'outbound'). Allerdings hätte ich erwartet, dass die Antwort auch ignoriert wird (active-filter 'not tcp[tcpflags] & (tcp-rst | tcp-fin) != 0'). Ich hab auch schon mal alle 3 Regeln mit 'and' in eine Zeile geschieben (siehe mail von Andreas Koenecke). Ob das jetzt funktioniert kann ich nicht mit absoluter Sicherheit sagen, da momentan noch irgendwelche NBNS Anfragen von ausserhalb unseren Rechner veranlsssen DNS Anfragen an die Telekon zu schicken. Ich schätze aber schon, da bei der letzten Einwahl 60sek nach der letzten DNS Anfrage aufgelegt wurde, und dass obwohl noch jede Menge TCP-EDonkey Anftage eingingen. Nichts desto trotz hat mich die ganze Diskussion davon überzeugt, dass es ohne einen Paketfilter (einfache Firewall) nicht vernünftig geht. Ausserdem ist vermutlich effektiver auf eine Anfrage nicht zu antworten als eine Ablehnung zu senden und diese dann bei der Idle-Time zu ignorieren. Grüße Michael Helms
* Freitag, 08. August 2003 um 11:00 (+0200) schrieb Michael Helms:
Nichts desto trotz hat mich die ganze Diskussion davon überzeugt, dass es ohne einen Paketfilter (einfache Firewall) nicht vernünftig geht. Ausserdem ist vermutlich effektiver auf eine Anfrage nicht zu antworten als eine Ablehnung zu senden und diese dann bei der Idle-Time zu ignorieren.
Aber dann darf man sich nicht "beschweren", wenn weiterhin Anfragen
hereinkommen. Man sollte IMHO dem anfragenden Rechner/Programm
mitteilen, dass auf dem angefragten Port kein Verbindungsaufbau
möglich/erwünscht ist, und dazu sollte man mit TCP-Reset oder
ICMP-Destination-unreachable antworten. (Ja, ich weiss: Gerade die
beliebten P2P-Programmen kümmern sich sich nicht um solchen Antworten,
aber vielleicht ändert sich das irgendwann einmal...)
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
participants (6)
-
Andreas Koenecke -
Andreas Kyek -
Dieter Kluenter -
Matthias Beber -
Michael Helms -
Thomas Bitschnau