"Ungenutzten Anschluss 4662 blockiert" nervt

#1 Mit NIS 2003 habe ich "mittlere Benachrichtigungsstufe" eingestellt und bekomme jetzt im Sekundentakt "Ungenutzten Anschluss 4662 blockiert" angezeigt. Ich lese immer dass dieser Port was mit eDonkey etc. zu tun hat. KaZaalite hatte ich installiert aber wieder runtergeworfen. Hängt das damit zusammen? Ich habe keine Lust den Anschluss freizugeben. Das bedeutet doch dass jemand von außen versucht auf diesen Anschluss zuzugreifen, oder?
Uwe Beck

#2 Ähm, ok. Zu schnell geschossen. Mit "Suche" habe ich genau den passenden Thread zu meiner Frage gefunden. Sorry. Weiß zwar noch nicht was ich tun soll, aber kenne jetzt die Hintergründe. Da ich aber doch eine dynamische IP habe, müßte sich doch dieser Effekt nicht immer ergeben? ich kann doch nicht immmer die IP von einem edonkey etc. zugewiesen bekommen?

#3

Zitat

Pirmin postete
ich kann doch nicht immmer die IP von einem edonkey etc. zugewiesen bekommen?

Naja, ich denke es ist wohl eher Glück, wenn man eine IP bekommt, die vorher nicht von einem edonkey User genutzt wurde - so hat man zumindest den Eindruck!

R:
__________
powered by http://different-thinking.de - Netze, Protokolle, Sicherheit, ...

#4 Ich habe exakt das gleiche Problem wie Pirmin, weiß jetzt allerdings nicht, welchen passenden 'Antwort'-Thread er meint (nichts gefunden).
Wenn ich zwischen den Zeilen lese, hat es was mit dyn. IP's zu tun, die vorher wer anders (z.B. ein eDonkey-User) verwendet hat.
--> Habe ich das nun richtig verstanden??

Was mir nun noch nicht klar ist:
- Sollte man solche Anfragen nun in jedem Fall und weiterhin von NIS blockieren lassen?
==> Wenn ja:
- Wie kann man zumindest die wirklich nervigen Meldungen unterdrücken, ohne gleich den kompletten AlertTracker ausschalten zu müssen?
==> Wenn nein:
- Wie muß ich NIS konfigurieren, um solch eine Anfrage fortan zuzulassen, (damit die Meldungen nicht mehr erscheinen)?
- Was passiert dann mit der Anfrage, wenn sie mal durch die Firewall durchgegangen ist?

#5 Kannst du denn überhaupt auswählen, was NIS mit der Anfrage machen soll? Das hielte ich für ziemlich sinnlos, da der Port sowieso nicht benutzt wird, also geschlossen ist.
Der Unterschied, ob man eine ohnehin "erfolglose" Anfrage durchlässt oder nicht, ist eher unwesentlich. Ich könnte mir höchstens vorstellen, dass im Fall des Blockens keinerlei Antwort an den Ursprung der Anfrage gesandt wird ("stealth") und im Fall des Durchlassens der Absender benachrichtigt wird, dass der Port zu ist ("closed.")
Andere Firewalls nerven den User jedenfalls nicht mit solch sinnlosen Mitteilungen, wenn an einen geschlossenen Port Anfragen stattfinden (bei Kerio z.B. erfolgt höchstens(!) ein Log-Eintrag.)

Ich weiß leider nicht, ob und wie du NIS konfigurieren kannst, damit solche Meldungen in Zukunft ausbleiben.

Auch aus diesen Gründen wird hier übrigens meistens von dem Einsatz von NIS abgeraten...

Edit: Noch was: Im Grunde ist ein "closed" in so einem Fall günstiger, damit der anfragende edonkey-Rechner weiß, dass bei dir kein Esel mehr läuft, und nicht immer wieder (nach langen Timeouts) neu anfragt. Ich weiß aber wie gesagt nicht, ob sich das mit NIS realisieren lässt...
__________
"Scheinsicherheit" - wie leicht lassen sich Viren- und Trojanerscanner austricksen?

#6 Ich beschäftige mich schon eine Zeit lang mit diesen eDonkey-Anfragen auf Port 4662.

1. Wenn die Firewall den request blockiert und das meldet, dann macht sie ihren Job. Ich meine aber, dass jede halbwegs vernünftige FW sich so konfigurieren lässt, dass sie weiter blockiert aber nichts mehr meldet. Wenn NIS das nicht kann, dann gehört das Prog in den Müll.
Man sollte sich darüber hinaus überlegen, ob man die 4662 überhaupt noch mitloggen lässt. Meine FW (Outpost) stürzte nämlich immer dann ab, wenn die Anzahl der Requests über 40 pro Sekunde ging. Die Ursache war nicht die Menge der Blockaden, sondern die Menge der LOG-Einträge auf einmal.

2. Die Requests von eDonkey sind nicht nur auf 4662 (TCP), sondern auch auf 4665 (UDP); oft habe ich noch TCP-Anfragen auf die Nachbar-Ports, insgesamt von 4661-4669; ich vermute mal alles kommt von derselben Quelle.

3. Eine Anfrage bei eDonkey selber ergab: Die fühlen sich nicht verantwortlich für die Störungen; Ursache seien die geklonten schlampig programmierten Tauschprogramme. Die Orginalsoft würde bemerken, wenn sich ein User ausklinkt und die dann nicht mehr benutzte IP dem Server melden, der die IP dann aus seiner Datenbank löschen würde.
Ob das stimmt sei mal dahin gestellt; ich kenne die interne Struktur der eDonkey-Tauschbörse jedenfalls nicht.

Eine Firewall ist genau für diese Probleme da.

Reinhart

#7

Zitat

Eine Firewall ist genau für diese Probleme da.

Wie meinst du das? Eine Firewall kann diese Probleme doch auch nicht lösen. Im Gegenteil, durch den "stealth"-Mode wird das ganze (wie oben erläutert) eher noch schlimmer...
__________
"Scheinsicherheit" - wie leicht lassen sich Viren- und Trojanerscanner austricksen?

#8 Ich meine es so:

Erstmal kann ich die Ursache nicht beseitigen. Solange sich die eDonkey-Leute nicht kümmern, ballern die uns weiter auf den 4662.

Dann habe ich ne Firewall, die die requests abblockt, stealth hin, stealth her. Wenn ich das Loggen abschalte, merke ich nix davon. Punktum. System läuft, Port ist zu. Irgend einer könnte mal testen, ob es weniger requests gibt, wenn man den Port auf closed setzt.

Mehr können wir, glaube ich, im Moment nicht machen.

Reinhart

#9 Grundsätzlich: Der Port 4662 ist sowieso zu, wenn du nicht gerade edonkey laufen hast, Firewall hin oder her. Der einzige Unterschied ist, dass ohne Firewall der Anfragende darauf hingewiesen wird, dass bei dir kein Esel läuft.

Bei mir sind die Ports nur "closed", nicht "stealth" und ich würde behaupten, dass es schon etwas bringt. Ist aber schwer einzuschätzen...
__________
"Scheinsicherheit" - wie leicht lassen sich Viren- und Trojanerscanner austricksen?

#10 "Erstmal kann ich die Ursache nicht beseitigen. Solange sich die eDonkey-Leute nicht kümmern,ballern die uns weiter auf den 4662."

Der störende Faktor in diesem Fall ist eindeutig die Firewall oder dessen Einstellungen.
Ohne damit eine Debatte anfangen zu wollen kann ich das auch klar argumentieren.
Persönlich bekomme ich von all diesen P2P-User nichts mit.Also kann es mich auch nicht stören.Für die benutzte Bandbreite zahlen sie schließlich wie jeder andere auch.
P2P-User sind für die ISP ein wahrer Segen sprich beste Kunden.Ob dessen die sich bewußt sind weiß ich nicht.Für viele bedeutet Internet=P2P.Sollte diese Kundschaft wegfallen dann würden die Dienstleister in einer noch besch... Lage sein und wir könnten uns über noch höhere Tarife freuen.

Gruß
Ajax

#11 Heißen Dank soweit an alle Beteiligten!

Glücklich darüber, nun den ungefähren Hintergrund dieser Meldungen erfahren zu haben, habe ich bei NIS 2003 mal ein bißchen rumprobiert, wie die Meldungen fortan unterdrückt werden können und möchte das Ergebnis nun allen in gleicher Weise Leidgeprüften zur Verfügung stellen.

1) Status Einstellungen > Persönliche Firewall > [Konfigurieren]
2) Registerkarte "Erweitert" > [Allgemeine Regeln...]
3) [Hinzufügen] und dann im einzelnen:
- "Internetzugriff BLOCKIEREN" > [Weiter]
- "Verbindungen VON anderen Computern" > [Weiter]
- "Alle Computer" > [Weiter]
- "TCP", außerdem noch...
- "Nur die unten aufgeführten..." > [Hinzufügen]
- Im neuen Fenster dann "Einzeln angegebene Anschlüsse", in der darauf erscheinenden Eingabezeile "4661 4662" (alternativ geht natürlich auch bei "Anschlußbereich" 4661 und 4662 eintragen) und als Standort "lokal"> [Ok] > [Weiter]
- Bei "Benachrichtigung" müssen nun alle Haken draussen sein (wer will, kann sie zunächst noch drin lassen und sich anschließend vom Ergebnis seines Werkes im AlertTraker oder der Protokollanzeige überzeugen lassen - nachträglich rausnehmen über Editieren der neuen Regel)
- Dem Kind im letzten Fenster noch nen griffigen Namen geben, x-mal [Ok] und man hat endlich Ruhe beim Surfen !!!!!
(Wenn dann in Zukunft noch weitere unbenutzte Anschlüsse in der bekannten Form angegangen werden, diese dann einfach zu der neuen Regel hinzufügen.)

-> Falls wer von den Profis (ich zähl mich nämlich nicht gerade dazu) noch Anmerkungen/Verbesserungsvorschläge hat, immer her damit - aber so müßte es doch gehen und man verbaut sich nix, oder??

THX und Gruß an alle!

#12 [Mittels eines FW kann man zwar die Requests blocken - sie belegen allerdings immer noch Bandbreite. Je nach Aufkommen kann das bei OnlineSpielen einen sehr stoerenden hohen Ping erzeugen...
__________
"Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." Linus Benedict Torvalds