Permanenter traffic auf tcp 4662

[Stormbringer]

Hallo,

hat jemand eine Idee, was diesen wahnisinnig hohen traffic auf tcp 4662 erzeugt?
Habe es nun einfach einmal eine zeitlang nachvollzogen:
Über einen Zeitraum von:
Betriebszeit 2 Tage 1 Stunden 52 Minuten
gab es insgesamt:
Schnittstelle Empfangen Gesendet Err/Drop
lo 17.04 MB 17.04 MB 0/0
eth0 16.03 MB 88.96 MB 0/0
ppp0 1.43 GB 40.83 MB 0/3
sit0 0.00 KB 0.00 KB 0/0
vom Internet zu meinem System - die FW dropped diesen zwar, mag aber für Leute mit einem volumanabhängigen Vertrag ausgesprochen übel sein ....

Gruß

[taylor]

eDonkey... ein Filesharing Programm.

[Stormbringer]

Hallo,

Danke für die Info!
Suchen die eDonkeynutzer einfach so ohne Anhaltspunkt nach möglichen P2P Teilnehmern?
Bin halt keiner, und daher wundert es mich .....

Gruß

[HangLoose]

moin moin

deine ip wird vorher ein edonkey user gehabt haben.

Gruß HangLoose

[Jinto]

Hi Stormbringer,

wenn vor dir jemand diese IP hatte musst du u. U. mit vielen Anfragen rechnen, selbst wenn du schon mehrere Stunden im besitzt dieser IP bist. Mein mldonkey speichert sich in einer Liste zusätzlich noch von welcher IP er welches File bezogen hat, von daher sollte es normal sein.

Eine weitere Möglichkeit zur Reduzierung wäre statt eines DROPs die tcp-Pakete mit REJECT (tcp-reset) abzulehenen. Damit sollten sich der Verbindungsanfragen auch reduzieren.

Gruß & HTH

[Stormbringer]

Hi Jinto,

Danke für die Antwort!!!
Ich bin in der Szene nicht so bewandert, und bin immer von einer serverseitig verwalteten Systemliste ausgegangen.
Da Du ja nun schreibst, daß solche Listen clientseitig geführt und genutzt werden, erklärt dies einiges.

Gruß

[Jinto]

Hi Stormbringer,

das war vielleicht missverständlich. Die Listen werden "Serverseitig" geführt, aber nicht nur. Sobald ich etwas herunterlade, bekomme ich ja die IP-Liste. Die Verbindung wird direkt zu den Clients aufgebaut und läuft nicht über den Server.

Wenn nun die IP-wechselt, weiss mein Client davon nichts (und der Server leider auch nicht) => Mein CLient versucht weiterhin die alte IP zu malträtieren und der Server gibt weiterhin eine gewisse Zeit die alte IP heraus.

Gruß

[rabenkind]

hi to all

das mit dem REJECT habe ich schon ausprobiert, hilft nicht die dinger (mldonkey) sind so stur wie der sprichwörtliche.

da dies mal wieder ein rechtsfreier raum ist, müssen die die ihr trafficaufkommen bezahlen, wohl in den sauren apfel beissen das andere zu ihren lasten das inet überfluten. :mad:

meine logs quellen auch wegen donkey-anfragen über, lästig aber leider nicht zu ändern. :(

greetz rabenkind :))

[Jinto]

@rabenkind
Wie hat sich dein REJECT ausgewirkt? Das es danach keine Anfragen mir gibt ist unwahrscheinlich, es sollten aber _insgesamt_ weniger anfragen werden.

Gruß

[rabenkind]

hi Jinto

nein die abfragen wurden nicht weniger, aber ich habe mir das auch nur über zwei tage angesehen und es dann wieder auf drop geändert.
ich denke da ich jeden tag eine neue ip bekomme macht das wenig sinn, da die donkey-user warscheinlich nicht jeden tag ihre listen updaten genauso wenig die server. somit habe ich dann am nächsten tag die user auf der leitung die mit dem menschen kommuniziert haben der gestern meine heutige ip hatte. :)

greetz rabenkind :))

ps sinnvoller wäre es wenn die donkey user/server vorher mal anklopfen würden, "ist der entsprechende dienst verfügbar" wenn nicht "aus der liste streichen", aber das funzt bei denen wohl nicht.

[tomes]

ewig :mad: Man sollte einfach auf jede anfragende IP ein Floyding machen ;)

T;o)Mes

P.S.: Ich habe die Firewall jetzt so eingestellt das sie bestimmte Ports nicht logt. Ist zwar nicht die beste Loesung, aber was soll's.

[rabenkind]

hi to all

habe vor jetzt portsentry einzusetzen, das ist ja aktives ids. damit lassen sich solche menschen vielleicht fernhalten, mal sehen.
weil bestimmte ports nicht zu loggen habe ich auch gemacht, finde ich aber auch nicht gut.

greetz rabenkind :))

[red.iceman]

mmh, sitzt portsentry nicht hinter der firewall, so dass es nur die anfragen mitbekommt, die die firewall passieren? oder wie machst du das??

ri

[rabenkind]

hi red.iceman

ich habe mich nach folgendem artikel mit portsentry befasst und es in meine sicherheitssruktur implementiert.
der artikel erklärt die funktionalität von portsentry ganz gut.

http://www.linuxfocus.org/Deutsch/September2001/article214.shtml

mit den advanced options

- Die Fünfte und Sechste sind "-atcp" und "-audp". Dies sind die effektivsten Optionen ("a" steht für erweitert (advanced)). Bei Nutzung dieser Optionen erstellt Portsentry eine Liste der lauschenden Ports, TCP und UDP, wenn beides gewählt wurde, und blockt kontaktierende Hosts auf den Ports, es sei denn, der Host soll von Portsentry ignoriert werden.
kann portsentry aktiv mit hilfe von iptables agieren.

greetz rabenkind :))

[red.iceman]

ja, nur hab ich nicht verstanden, welchen vorteil es dir fuer DIESES problem hier bringt, denn es bekommt ja nur etwas von dem mit, was die firewall passiert. da aber deine firewall die anfragen ablehnt, "merkt" portsentry davon doch eh nix, oder??

ri

[rabenkind]

hi to all

@red.iceman

doch da portsentry ja direkt auf den ports lauscht, werden anfragen an diese ports (aus der liste) erkannt und bei mir als neue iptables-regel nr.1 gedropt. dadurch tauchen sie in den /var/log/messages und warn nicht mehr auf und werden von dem/den fremden host/s als down gesehen.

@all

ob sich im endeffekt die häufigkeit der anfragen dadurch verringert weiß ich nicht, müsste man mal ausprobieren, indem ein bekannter den host in seine donkey-liste einträgt und dann die connect-versuche über einen definierten zeitraum protokolliert. ich kenne niemanden der donkey verwendet.

wär also schön wenn einer das mal testen würde.
allerdings kenne ich auch nicht alle donkey-ports bzw. weiß ich nicht ob da nur bestimmte benutzt werden oder wie auch immer das festgelegt ist, selber benutze ich es nämlich nicht!

meine logs quellen jetzt jedenfalls nicht mehr so schnell über. :) :)
die betreffenden ips sperre ich auch immer nur solange wie ich meine dynamische ip besitze, also nur für die eine sitzung (ca. 16std.)

greetz rabenkind :))

[Jinto]

In meinen Augen verschiebst du das Problem von einem Logfile in ein anderes (bitte korrigiere mich wenn ich mich irre).

Zudem erreichst du durch droppen eigentlich eher das gegenteil von den was du bezweckst (du willst ja weniger Traffik). Wenn das Paket nun einfach verworfen wird, probiert der Sender es einfach nohcmal (könnte ja verloren gegangen sein). Der korrekte Weg wäre eigentlich ein tcp-reset zu senden um dem Sender zu sagen er ist hier falsch (Port enthält kein Dienst). AFAIR einzig Windows sendet noch weitere 3 Pakete :(

Das sperren

[HangLoose]

@Jinto

das problem ist, edonkey stört sich auch nicht an einem *reject* und selbst wenn der spez. host dann das *reject* endlich kapiert hat, hast du noch anfragen von dutzenden von anderen rechnern. die jagen nämlich grundsätzlich im rudel ;)

ich kann ja mein logfile von heute posten. ;)


Gruß HangLoose

[rabenkind]

hi Jinto

das mit den logs ist so wie ich schon geschrieben habe, ein eintrag pro ip in messages das wars.

aber die sache mit dem tcp-reset klingt logisch, werde ich machen.
folgende regel müsste dem donkey ja dann mitteilen das er unerwünscht ist:

-I INPUT --dport xyz -j REJECT --reject-with tcp-reset füge ich dynamisch via portsentry ein, da mein filterscript klein bleiben soll.
wie gesagt ich weiß nicht wie donkey funktioniert, und ich habe keine lust/zeit mich damit zu beschäftigen. :)
mir persönlich ist der traffic egal, kostet eh dasselbe ob er hoch ist oder nicht, mir geht es nur um meine logs und die wachsen jetzt nicht mehr so schnell.
aber einige menschen stört wohl der traffic da dieser ja auch kosten verursacht (volumenabhängig) und eine möglichkeit diesen menschen zu helfen fände ich gut. :)

greetz rabenkind :))

[HangLoose]

hi rabenkind

edonkey läßt sich nicht so leicht abschütteln ;). allerdings bin ich mittlerweile auch der meinung das ein reject dem drop vorzuziehen ist.


ps: ich werd mir portsentry auch mal bei gelegenheit ansehen. momentan verwende ich den metalog, eventuell gibt es da ja auch entsprechende möglichkeiten, das loggen zu beeinflußen.

Gruß HangLoose

[HangLoose]

logfile vergessen

[Jinto]

@rabenkind
Das kam beim Ersten mal nicht so klar raus, dass immer nur eine IP geloggt wird. thx für die Info.

@hangloose
Das liegt i.d.R. nicht am jeweiligen Donkey, sondern am Stack des OS.

Gruß

[HangLoose]

hi Jinto


Original geschrieben von Jinto

@hangloose
Das liegt i.d.R. nicht am jeweiligen Donkey, sondern am Stack des OS.


du meinst sicher, den stack von windows, oder?


ps:ne kleine neueinwahl kann die *meute* zur not auch erstmal durcheinander bringen ;)


Gruß HangLoose

[rabenkind]

hi HangLoose

meinst du dieses metalog von frank denis?

hört sich nämlich gut an was in der doku steht, portsentry ist nämlich nicht so der hit. bin gerade auf der suche nach einer guten alternative.

bei portsentry fehlen ein paar möglichkeiten die ich von aktivem ids erwarte, bzw ich müsste mir mehrere scripte als zusatz selber schreiben, und dann brauche ich portsentry nicht, da snort die erkennung ja sowieso erledigt.

greetz rabenkind :))

[HangLoose]

hi

ich meine dieses metalog => http://metalog.sourceforge.net/


bin aber noch nicht dazu gekommen, mich ausführlicher mit zu beschäftigen


Gruß HangLoose