Guten Abend Liste, nun habe ich heute ca. 460000 Einträge in der Art: Sep 18 23:45:51 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC= SRC=64.92.150.46 DST=217.255.54.135 LEN=98 TOS=0x00 PREC=0x00 TTL=58 ID=12723 DF PROTO=UDP SPT=4672 DPT=11164 LEN=78 in /var/log/messages (rund 97 pro Sekunde). Die Datenquelle schaut immer aus in der Art (nur Auszüge ... ;)): SRC=64.209.193.4 SRC=64.209.193.5 SRC=64.209.193.5 SRC=64.209.193.5 SRC=64.209.193.5 SRC=64.209.193.6 SRC=64.209.193.6 SRC=64.209.193.6 SRC=64.209.193.6 SRC=64.209.193.7 SRC=64.209.193.8 SRC=64.209.193.8 SRC=64.209.193.8 SRC=64.209.193.9 SRC=64.209.193.9 SRC=64.209.193.9 SRC=64.209.193.10 SRC=64.209.193.10 SRC=64.209.193.10 SRC=64.209.193.10 SRC=64.209.193.11 SRC=64.209.193.11 SRC=64.209.193.11 SRC=64.209.193.11 SRC=64.209.193.12 SRC=64.209.193.12 oder aber: SRC=64.92.150.51 SRC=64.92.150.51 SRC=64.92.150.51 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.66 SRC=64.92.150.53 SRC=64.92.150.53 SRC=64.92.150.53 SRC=64.92.150.53 SRC=64.92.150.53 SRC=64.92.150.54 SRC=64.92.150.54 SRC=64.92.150.54 SRC=64.92.150.54 Um das Ganze aber nicht langweilig zu machen, werden die Ports 11164 & 6881 angesprochen ... Die Logdatei hat mittlerweile (nur für heute, 18.09.2004), eine Größe von 180MB. Kann man da irgendetwas gegen tun, außer die Verbindung zum Internet zu trennen? Rein rechtlich würde ich denjenigen gerne anstinken, da es, wenn man keine Flatrate haben sollte, teuer werden kann ... Danke & Gruß Torsten
Am Sonntag, 19. September 2004 00:04 schrieb Torsten E.:
Guten Abend Liste,
nun habe ich heute ca. 460000 Einträge in der Art: Sep 18 23:45:51 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC= SRC=64.92.150.46 DST=217.255.54.135 LEN=98 TOS=0x00 PREC=0x00 TTL=58 ID=12723 DF PROTO=UDP SPT=4672 DPT=11164 LEN=78 in /var/log/messages (rund 97 pro Sekunde).
Die Datenquelle schaut immer aus in der Art (nur Auszüge ... ;)): SRC=64.209.193.4 SRC=64.209.193.5 [...] oder aber: SRC=64.92.150.51 SRC=64.92.150.66 [...]
Um das Ganze aber nicht langweilig zu machen, werden die Ports 11164 & 6881 angesprochen ...
Sehr klug! Alles unnassigned Ports. Schuß ins Blaue! Da ist ein "Wurmfinder" am Werk und versucht Verbindung zu seinen Kindern aufzunehmen. Oder es ist einfach eine DOS-Attacke.
Die Logdatei hat mittlerweile (nur für heute, 18.09.2004), eine Größe von 180MB.
Ich hoffe Du hast /var auf einer eigenen Partition.
Kann man da irgendetwas gegen tun, außer die Verbindung zum Internet zu trennen?
Eine Abuse-Mail an abuse@savvis.net schreiben mit relevanten Auszügen aus Deinen Logs und eventuell, dass Du Dir das Recht vorbehältst Strafanzeige zu erstatten, sollte der Mißstand nicht abgestellt werden.
Rein rechtlich würde ich denjenigen gerne anstinken, da es, wenn man keine Flatrate haben sollte, teuer werden kann ...
Ich denke, dass SAVVIS dafür haftbar gemacht werden kann. lg, Andreas.
Andreas Scherer schrieb am Sonntag, 19. September 2004 00:53:
Am Sonntag, 19. September 2004 00:04 schrieb Torsten E.:
Guten Abend Liste,
[ ... ]
Um das Ganze aber nicht langweilig zu machen, werden die Ports 11164 & 6881 angesprochen ...
Sehr klug! Alles unnassigned Ports.
Schuß ins Blaue! Da ist ein "Wurmfinder" am Werk und versucht Verbindung zu seinen Kindern aufzunehmen.
Oder es ist einfach eine DOS-Attacke.
Die Logdatei hat mittlerweile (nur für heute, 18.09.2004), eine Größe von 180MB.
Ich hoffe Du hast /var auf einer eigenen Partition.
Yep ... :-) ... 10GB (noch 3GB frei).
Kann man da irgendetwas gegen tun, außer die Verbindung zum Internet zu trennen?
Eine Abuse-Mail an abuse@savvis.net schreiben mit relevanten Auszügen aus Deinen Logs und eventuell, dass Du Dir das Recht vorbehältst Strafanzeige zu erstatten, sollte der Mißstand nicht abgestellt werden.
Habe nun eine Email mit einer csv-Datei als Anhang (~40000 Zeilen aus dem Zeitraum 19:00 - 21:00) an: abuse@exodus.net, ncc@exodus.net & abuse@exodus.net geschickt. Zusätzlich habe ich den gesamten Vorgang noch an die Abteilung für Computerkriminalität des FBI geschickt ...
Rein rechtlich würde ich denjenigen gerne anstinken, da es, wenn man keine Flatrate haben sollte, teuer werden kann ...
Ich denke, dass SAVVIS dafür haftbar gemacht werden kann.
lg, Andreas.
Danke Dir! Gruß Torsten
On Sunday 19 September 2004 01:00, Torsten E. wrote:
Andreas Scherer schrieb am Sonntag, 19. September 2004 00:53:
Am Sonntag, 19. September 2004 00:04 schrieb Torsten E.:
Guten Abend Liste,
[ ... ]
Um das Ganze aber nicht langweilig zu machen, werden die Ports 11164 & 6881 angesprochen ...
Sehr klug! Alles unnassigned Ports.
Schuß ins Blaue! Da ist ein "Wurmfinder" am Werk und versucht Verbindung zu seinen Kindern aufzunehmen.
Oder es ist einfach eine DOS-Attacke.
Die Logdatei hat mittlerweile (nur für heute, 18.09.2004), eine Größe von 180MB.
Ich hoffe Du hast /var auf einer eigenen Partition.
Yep ... :-) ... 10GB (noch 3GB frei).
Kann man da irgendetwas gegen tun, außer die Verbindung zum Internet zu trennen?
Eine Abuse-Mail an abuse@savvis.net schreiben mit relevanten Auszügen aus Deinen Logs und eventuell, dass Du Dir das Recht vorbehältst Strafanzeige zu erstatten, sollte der Mißstand nicht abgestellt werden.
Habe nun eine Email mit einer csv-Datei als Anhang (~40000 Zeilen aus dem Zeitraum 19:00 - 21:00) an: abuse@exodus.net, ncc@exodus.net & abuse@exodus.net geschickt. Zusätzlich habe ich den gesamten Vorgang noch an die Abteilung für Computerkriminalität des FBI geschickt ...
Rein rechtlich würde ich denjenigen gerne anstinken, da es, wenn man keine Flatrate haben sollte, teuer werden kann ...
Ich denke, dass SAVVIS dafür haftbar gemacht werden kann. Ich hab vor einiger Zeit ein ähnliches Symptom aus dem Adressbereich von Chinanet und einem Netzbetreiber von den Phillipinen gehabt, 11.161.41.0/255.255.255.0, 218.21.64.0/255.255.192.0, 218.85.0.0/255.255.128.0 und 61.129.0.0/255.255.0.0.
Allerdings nicht wie bei dir in DOS manier sondern als Portscan mit jeweils über einer Stunde Verzögerung zwischen den Scans und auf den gesammten Port Bereich über 1024. Und jedesmal wurde mit einer anderen IP gescant, allerdings jeweils nur aus diesen IP Bereichen. Ich hab diese Bereiche in die /etc/hosts.deny eingetragen (ALL: 218.21.64.0/255.255.192.0 : DENY). Jemand vom BSI-Cert, hab den Namen schon wieder vergessen, meinte zu mir das dies bereits seit einiger Zeit zu beobachten sei. Tschüss, Thomas
On Sunday 19 September 2004 00:04, Torsten E. wrote:
Guten Abend Liste,
nun habe ich heute ca. 460000 Einträge in der Art: Sep 18 23:45:51 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC= SRC=64.92.150.46 DST=217.255.54.135 LEN=98 TOS=0x00 PREC=0x00 TTL=58 ID=12723 DF PROTO=UDP SPT=4672 DPT=11164 LEN=78 in /var/log/messages (rund 97 pro Sekunde).
Heißt das DROP da oben, daß Pakete verworfen werden, anstatt sie RFC-Konform zu REJECTen?
Kann man da irgendetwas gegen tun, außer die Verbindung zum Internet zu trennen?
Du könntest das Logging für deinen Paketfilter abschalten oder nur solche Zugriffe loggen, die von evtl. Interesse sind.
Rein rechtlich würde ich denjenigen gerne anstinken, da es, wenn man keine Flatrate haben sollte, teuer werden kann ...
Vergiß es. Martin
Martin Schmitz schrieb am Sonntag, 19. September 2004 12:25:
On Sunday 19 September 2004 00:04, Torsten E. wrote:
Guten Abend Liste,
nun habe ich heute ca. 460000 Einträge in der Art: Sep 18 23:45:51 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC= SRC=64.92.150.46 DST=217.255.54.135 LEN=98 TOS=0x00 PREC=0x00 TTL=58 ID=12723 DF PROTO=UDP SPT=4672 DPT=11164 LEN=78 in /var/log/messages (rund 97 pro Sekunde).
Heißt das DROP da oben, daß Pakete verworfen werden, anstatt sie RFC-Konform zu REJECTen?
Selbstredend DROPpe ich die - ansonsten erzeuge ich ja doppelten Traffic ... ;)
Kann man da irgendetwas gegen tun, außer die Verbindung zum Internet zu trennen?
Du könntest das Logging für deinen Paketfilter abschalten oder nur solche Zugriffe loggen, die von evtl. Interesse sind.
Nöö ... das ist nicht unbedingt das gewollte.
Rein rechtlich würde ich denjenigen gerne anstinken, da es, wenn man keine Flatrate haben sollte, teuer werden kann ...
Vergiß es.
Leider wird es wohl darauf hinauslaufen.
Martin
Torsten
On Sunday 19 September 2004 16:53, Torsten E. wrote:
Selbstredend DROPpe ich die - ansonsten erzeuge ich ja doppelten Traffic ... ;)
Aha. Dial-up Benutzer ohne nennenswert clue aber dafür mit "voll krass sicherer Firewall".
Du könntest das Logging für deinen Paketfilter abschalten oder nur solche Zugriffe loggen, die von evtl. Interesse sind.
Nöö ... das ist nicht unbedingt das gewollte.
Was willst Du denn? *Kein* irgendwie zu Dir findendes IP-Paket dürfte für Dich von wie auch immer geartetem Interesse sein (außer den Antworten auf Deine Anfragen). Du verstehst doch sowieso nicht, was da vor sich geht. Martin
Martin Schmitz schrieb am Sonntag, 19. September 2004 22:56:
On Sunday 19 September 2004 16:53, Torsten E. wrote:
Selbstredend DROPpe ich die - ansonsten erzeuge ich ja doppelten Traffic ... ;)
Aha. Dial-up Benutzer ohne nennenswert clue aber dafür mit "voll krass sicherer Firewall".
Wat???? Aus welchem Grunde soll ich: a) die Leitung gänzlich schließen (durch Erzeugung zusätzlichem traffics) b) einer ggf. schlechten Software (keine Timeout counting, o. ä.) noch eine Daseinsberechtigung geben c) ...
Du könntest das Logging für deinen Paketfilter abschalten oder nur solche Zugriffe loggen, die von evtl. Interesse sind.
Nöö ... das ist nicht unbedingt das gewollte.
Was willst Du denn? *Kein* irgendwie zu Dir findendes IP-Paket dürfte für Dich von wie auch immer geartetem Interesse sein (außer den Antworten auf Deine Anfragen). Du verstehst doch sowieso nicht, was da vor sich geht.
Da bin ich dann aber wirklich froh, daß es Typen wie dich gibt!! Ich wüßte nicht, daß ich nach einer Möglichkeit zum Abschalten des Loggings gefragt habe, sondern was man gegen solche Vorgehensweisen tun kann (bspw. Beenden und Neustarten einer Verbindung zum Internet (kam aber nicht als Hinweis)), was man zusätzlich noch präventiv tun kann (kam der Hinweis auf die hosts.deny), wie es rechtlich ausschaut. Aber da ich ja eh nichts verstehe, brauche ich mich mit dir ja auch nicht weiter zu unterhalten ... ach, stimmt ja, ich vergaß, laut einer Studie ist ja durchschnittlich jeder 14te Bundesbürger, zumindest gemäß medizinischer Definition, als debil zu bezeichnen ...
Martin
Torsten
On Mon, Sep 20, 2004 at 09:12:48AM +0200, Torsten E. wrote:
Martin Schmitz schrieb am Sonntag, 19. September 2004 22:56:
On Sunday 19 September 2004 16:53, Torsten E. wrote:
Selbstredend DROPpe ich die - ansonsten erzeuge ich ja doppelten Traffic ... ;)
Man könnte dieses Verhalten asozial nennen. http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject | DROP offers no effective barrier to hostile forces but can dramatically | slow down applications run by legitimate users.
Aha. Dial-up Benutzer ohne nennenswert clue aber dafür mit "voll krass sicherer Firewall".
Wat???? Aus welchem Grunde soll ich: a) die Leitung gänzlich schließen (durch Erzeugung zusätzlichem traffics) b) einer ggf. schlechten Software (keine Timeout counting, o. ä.) noch eine Daseinsberechtigung geben c) ...
Du könntest das Logging für deinen Paketfilter abschalten oder nur solche Zugriffe loggen, die von evtl. Interesse sind.
Nöö ... das ist nicht unbedingt das gewollte.
Was willst Du denn? *Kein* irgendwie zu Dir findendes IP-Paket dürfte für Dich von wie auch immer geartetem Interesse sein (außer den Antworten auf Deine Anfragen). Du verstehst doch sowieso nicht, was da vor sich geht.
Da bin ich dann aber wirklich froh, daß es Typen wie dich gibt!! Ich wüßte nicht, daß ich nach einer Möglichkeit zum Abschalten des Loggings gefragt habe, sondern was man gegen solche Vorgehensweisen tun kann (bspw. Beenden und Neustarten einer Verbindung zum Internet (kam aber nicht als Hinweis)), was man zusätzlich noch präventiv tun kann (kam der Hinweis auf die hosts.deny), wie es rechtlich ausschaut.
Sag mal, geht's noch? Du bist zu feige deinen vollständigen Namen zu nennen und machst hier völlig unberechtigt 'nen lauten. Die Ursache für dein "Problem" wurde Dir doch genannt. Hast Du das ignoriert oder nicht verstanden? Mit solchen Logeinträgen muss man als Dial-Up User nunmal rechnen. Die böse rechtliche Keule hilft Dir da nicht weiter.
Aber da ich ja eh nichts verstehe, brauche ich mich mit dir ja auch nicht weiter zu unterhalten ... ach, stimmt ja, ich vergaß, laut einer Studie ist ja durchschnittlich jeder 14te Bundesbürger, zumindest gemäß medizinischer Definition, als debil zu bezeichnen ...
Ich habe mir meine Meinung gebildet zu welcher Gruppe Du gehörst. Jürgen
Am Montag, 20. September 2004 09:58 schrieb Jürgen Knelangen:
On Mon, Sep 20, 2004 at 09:12:48AM +0200, Torsten E. wrote:
Martin Schmitz schrieb am Sonntag, 19. September 2004 22:56:
On Sunday 19 September 2004 16:53, Torsten E. wrote:
Selbstredend DROPpe ich die - ansonsten erzeuge ich ja doppelten Traffic ... ;)
Man könnte dieses Verhalten asozial nennen. http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
| DROP offers no effective barrier to hostile forces but can dramatically | slow down applications run by legitimate users. |
Also Jürgen Knelangen, man muß Leuten nicht gleich asoziales Verhalten vorwerfen nur weil sie Verbindungen Droppen und nicht Rejecten. Da brauch man sich dann auch nicht über entsprechende gegenreaktionen zu wundern wie sie am Ende Eures Disputs nachzulesen sind. Zumal mir auch nicht ganz klar ist welches denn die "legitimen User" sein sollen die da in Mitleidenschaft gezogen werden. Liegt wahrscheinlich daran das ich den Text unter der o.g. Adresse nicht vollständig verstehe. Vielleicht könntest Du ja das noch mal mit eigenen Worten erklären, man möchte sich schließlich nicht asozial verhalten, oder gar Leute schädigen...nur weil man Dropt. Micha P.s. : Auch wenn ich der Meinung bin das es zu einer Sachlichen Diskussion nicht notwendig ist seine Personalien auszutauschen, möchte ich darauf hinweisen das mein vollständiger Name aus der emailadresse hervor geht ...
Aha. Dial-up Benutzer ohne nennenswert clue aber dafür mit "voll krass sicherer Firewall".
Wat???? Aus welchem Grunde soll ich: a) die Leitung gänzlich schließen (durch Erzeugung zusätzlichem traffics) b) einer ggf. schlechten Software (keine Timeout counting, o. ä.) noch eine Daseinsberechtigung geben c) ...
Du könntest das Logging für deinen Paketfilter abschalten oder nur solche Zugriffe loggen, die von evtl. Interesse sind.
Nöö ... das ist nicht unbedingt das gewollte.
Was willst Du denn? *Kein* irgendwie zu Dir findendes IP-Paket dürfte für Dich von wie auch immer geartetem Interesse sein (außer den Antworten auf Deine Anfragen). Du verstehst doch sowieso nicht, was da vor sich geht.
Da bin ich dann aber wirklich froh, daß es Typen wie dich gibt!! Ich wüßte nicht, daß ich nach einer Möglichkeit zum Abschalten des Loggings gefragt habe, sondern was man gegen solche Vorgehensweisen tun kann (bspw. Beenden und Neustarten einer Verbindung zum Internet (kam aber nicht als Hinweis)), was man zusätzlich noch präventiv tun kann (kam der Hinweis auf die hosts.deny), wie es rechtlich ausschaut.
Sag mal, geht's noch?
Du bist zu feige deinen vollständigen Namen zu nennen und machst hier völlig unberechtigt 'nen lauten. Die Ursache für dein "Problem" wurde Dir doch genannt. Hast Du das ignoriert oder nicht verstanden?
Mit solchen Logeinträgen muss man als Dial-Up User nunmal rechnen.
Die böse rechtliche Keule hilft Dir da nicht weiter.
Aber da ich ja eh nichts verstehe, brauche ich mich mit dir ja auch nicht weiter zu unterhalten ... ach, stimmt ja, ich vergaß, laut einer Studie ist ja durchschnittlich jeder 14te Bundesbürger, zumindest gemäß medizinischer Definition, als debil zu bezeichnen ...
Ich habe mir meine Meinung gebildet zu welcher Gruppe Du gehörst.
Jürgen
On Mon, Sep 20, 2004 at 10:41:44AM +0200, Michael wrote:
Am Montag, 20. September 2004 09:58 schrieb Jürgen Knelangen:
On Mon, Sep 20, 2004 at 09:12:48AM +0200, Torsten E. wrote:
Martin Schmitz schrieb am Sonntag, 19. September 2004 22:56:
On Sunday 19 September 2004 16:53, Torsten E. wrote:
Selbstredend DROPpe ich die - ansonsten erzeuge ich ja doppelten Traffic ... ;)
Man könnte dieses Verhalten asozial nennen. http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
| DROP offers no effective barrier to hostile forces but can dramatically | slow down applications run by legitimate users. |
Also Jürgen Knelangen, man muß Leuten nicht gleich asoziales Verhalten vorwerfen nur weil sie Verbindungen Droppen und nicht Rejecten.
Hmpf. Ich schrieb man _könne_ es asozial nennen.
Da brauch man sich dann auch nicht über entsprechende gegenreaktionen zu wundern wie sie am Ende Eures Disputs nachzulesen sind. Zumal mir auch nicht ganz klar ist welches denn die "legitimen User" sein sollen die da in Mitleidenschaft gezogen werden.
Jeder der ohne böse Absicht einen Verbindungsaufbau begehrt, hat IMHO das Recht ein REJECT zu bekommen. Dann weiss man sofort, daß der Dienst nicht zu Verfügung steht. Im anderen Fall (DROP) kommt keine Antwort. Die Verbindungsanfragen werden wiederholt. Erfolglos. Irgendwann gibt es einen Timeout. Die Zeit des Anfragenden wurde verschwendet, der Traffic erhöht. Im Fall von Torsten E. waren es diverse Filesharing-Programme die eine Ver- bindung mit dem Vorbesitzer seiner IP-Adresse wünschten. Nenne mir einen guten Grund warum man hier nicht mit REJECT antworten sollte. Ein REJECT würde in seinem Fall sogar die Verbindungsanfragen reduzieren.
Liegt wahrscheinlich daran das ich den Text unter der o.g. Adresse nicht vollständig verstehe.
Ich finde ihn leicht verständlich.
Vielleicht könntest Du ja das noch mal mit eigenen Worten erklären, man möchte sich schließlich nicht asozial verhalten, oder gar Leute schädigen...nur weil man Dropt.
Hab's oben versucht.
Micha
P.s. : Auch wenn ich der Meinung bin das es zu einer Sachlichen Diskussion nicht notwendig ist seine Personalien auszutauschen, möchte ich darauf hinweisen das mein vollständiger Name aus der emailadresse hervor geht ...
Helga schickt regelmässig einen Hinweis auf die Etikette in dieser Liste. http://lists.suse.com/archive/suse-linux/2004-Sep/0675.html Gruß, Jürgen
Jürgen Knelangen schrieb am Montag, 20. September 2004 11:17:
On Mon, Sep 20, 2004 at 10:41:44AM +0200, Michael wrote:
Am Montag, 20. September 2004 09:58 schrieb Jürgen Knelangen:
On Mon, Sep 20, 2004 at 09:12:48AM +0200, Torsten E. wrote:
Martin Schmitz schrieb am Sonntag, 19. September 2004 22:56:
On Sunday 19 September 2004 16:53, Torsten E. wrote:
[...]
Also Jürgen Knelangen, man muß Leuten nicht gleich asoziales Verhalten vorwerfen nur weil sie Verbindungen Droppen und nicht Rejecten.
Hmpf. Ich schrieb man _könne_ es asozial nennen.
Da brauch man sich dann auch nicht über entsprechende gegenreaktionen zu wundern wie sie am Ende Eures Disputs nachzulesen sind. Zumal mir auch nicht ganz klar ist welches denn die "legitimen User" sein sollen die da in Mitleidenschaft gezogen werden.
Jeder der ohne böse Absicht einen Verbindungsaufbau begehrt, hat IMHO das Recht ein REJECT zu bekommen. Dann weiss man sofort, daß der Dienst nicht zu Verfügung steht.
Hat er nicht, da er nicht sicherstellen kann, daß das von ihm generierte Paket auch an den richtigen Empfänger geht. Er geht lediglich davon aus, er nimmt also an, daß das Paket an den vermeintlich richtigen Empfänger gesendet wird. Zusätzlich kommt in diesem (meinem) Fall hinzu: die Einwahl (Vergabe der IP-Adresse) fand etwa 75 Minuten VOR dem ersten erhaltenen Paket statt. Weiterhin heißt ein source-port nicht automatisch, daß die normalerweise zugeordnete Applikation dieses Paket erstellt und verschickt hat (es muß also kein eMule Client aus einem kompletten Subnet gewesen sein).
Im anderen Fall (DROP) kommt keine Antwort. Die Verbindungsanfragen werden wiederholt. Erfolglos. Irgendwann gibt es einen Timeout. Die Zeit des Anfragenden wurde verschwendet, der Traffic erhöht.
Im Fall von Torsten E. waren es diverse Filesharing-Programme die eine Ver- bindung mit dem Vorbesitzer seiner IP-Adresse wünschten. Nenne mir einen guten Grund warum man hier nicht mit REJECT antworten sollte.
Naja, mit run 75 minütiger Verzögerung lohnt der Gang zur Videothek, Musikothek, whatever ...
Ein REJECT würde in seinem Fall sogar die Verbindungsanfragen reduzieren.
Liegt wahrscheinlich daran das ich den Text unter der o.g. Adresse nicht vollständig verstehe.
Ich finde ihn leicht verständlich.
Dem "Normalanwender" werden ggf. wohl die Erläuterungen in /etc/sysconfig/SuSEfirewall2 verständlich vorkommen: # 26.) # Do you want to REJECT packets instead of DROPing? # # DROPing (which is the default) will make portscans and attacks much # slower, as no replies to the packets will be sent. REJECTing means, that # for every illegal packet, a connection reject packet is sent to the # sender. # # Choice: "yes" or "no", if not set defaults to "no" # FW_REJECT="no" Warum sollte SuSE dem "Normalanwender" zu einem, je nach Standpunkt/Ansicht, "asozialem Verhalten" raten?
Vielleicht könntest Du ja das noch mal mit eigenen Worten erklären, man möchte sich schließlich nicht asozial verhalten, oder gar Leute schädigen...nur weil man Dropt.
Hab's oben versucht.
Micha
P.s. : Auch wenn ich der Meinung bin das es zu einer Sachlichen Diskussion nicht notwendig ist seine Personalien auszutauschen, möchte ich darauf hinweisen das mein vollständiger Name aus der emailadresse hervor geht ...
Helga schickt regelmässig einen Hinweis auf die Etikette in dieser Liste. http://lists.suse.com/archive/suse-linux/2004-Sep/0675.html
Gruß, Jürgen
Torsten
Sodenn. jetzt mal was zu drop vs. reject aus netzwerksicht... (die ganze sozial/asozial diskussion geht mir langsam auf den wecker). bei DROP werden eingehende Pakete für gesperrte Ports ignoriert. Das wird oft vorgeschlagen, weil dann der Rechner im Netz "Unsichtbar" wäre. Das stimmt aber nur, wenn der betreffende Rechner 1. keinen einzigen Dienst anbietet und 2. auch ping pakete ignoriert. bei reject werden eingehende pakete auf gesperrten ports mit einer "nein ich mag nicht" nachricht beantwortet. Intelligente Software sollte dann merken dass auf der adresse und dem port nix ist, und es nicht nochmal versuchen. also noch mal kurz: sobald man auch nur einen einzigen dienst anbietet (einen offenen port auf dem was lauscht), oder auf ping antwortet, oder auch nur in der susefirewall die hohen ports freischaltet, ist DROP keine tarnung mehr. bye, MH
Mathias Homann, Montag, 20. September 2004 11:55:
also noch mal kurz: sobald man auch nur einen einzigen dienst anbietet (einen offenen port auf dem was lauscht), oder auf ping antwortet, oder auch nur in der susefirewall die hohen ports freischaltet, ist DROP keine tarnung mehr.
Drop ist nie eine Tarnung. Denn keine Antwort von einer IP-Adresse zu bekommen, ist soviel wie zu wissen, daß da ein Rechner ist und läuft. Denn andernfalls würde man nämlich bereits vom Router des ISP ein Host Unreachable bekommen. Drop zur Tarnung ist nutzlos. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Andreas Feile wrote:
Drop ist nie eine Tarnung. Denn keine Antwort von einer IP-Adresse zu bekommen, ist soviel wie zu wissen, daß da ein Rechner ist und läuft. Denn andernfalls würde man nämlich bereits vom Router des ISP ein Host Unreachable bekommen.
Un im lokalen Subnetz reicht sogar ein Blick in den ARP-Cache.
Drop zur Tarnung ist nutzlos. ACK
mfg Thomas
On 20 Sep 2004 at 11:55, Mathias Homann wrote:
Sodenn.
jetzt mal was zu drop vs. reject aus netzwerksicht... (die ganze sozial/asozial diskussion geht mir langsam auf den wecker).
bei DROP werden eingehende Pakete für gesperrte Ports ignoriert. Das wird oft vorgeschlagen, weil dann der Rechner im Netz "Unsichtbar" wäre. Das stimmt aber nur, wenn der betreffende Rechner 1. keinen einzigen Dienst anbietet und 2. auch ping pakete ignoriert.
bei reject werden eingehende pakete auf gesperrten ports mit einer "nein ich mag nicht" nachricht beantwortet. Intelligente Software sollte dann merken dass auf der adresse und dem port nix ist, und es nicht nochmal versuchen.
also noch mal kurz: sobald man auch nur einen einzigen dienst anbietet (einen offenen port auf dem was lauscht), oder auf ping antwortet, oder auch nur in der susefirewall die hohen ports freischaltet, ist DROP keine tarnung mehr.
Hallo Mathias, ich habe meine Firewall versucht mit iptables ... -j REJECT zu schreibe, was allerdings mit Fehler quittiert wird, daraufhin habe ich auch DROP eingesetzt. In der ManPage zu iptables finde ich auch kein REJECT. Irgendwelches Tips? Danke+Gruß Daniel
Am Montag, 20. September 2004 17:40 schrieb Daniel Bauer:
ich habe meine Firewall versucht mit iptables ... -j REJECT zu schreibe, was allerdings mit Fehler quittiert wird, daraufhin habe ich auch DROP eingesetzt. In der ManPage zu iptables finde ich auch kein REJECT.
Irgendwelches Tips? Danke+Gruß Daniel
nee, leider nicht... bei mir läuft die susefirewall2 so wie sie aus der tüte kommt... bye, MH
On 20 Sep 2004 at 17:56, Mathias Homann wrote:
Am Montag, 20. September 2004 17:40 schrieb Daniel Bauer:
ich habe meine Firewall versucht mit iptables ... -j REJECT zu schreibe, was allerdings mit Fehler quittiert wird, daraufhin habe ich auch DROP eingesetzt. In der ManPage zu iptables finde ich auch kein REJECT.
Irgendwelches Tips? Danke+Gruß Daniel
nee, leider nicht... bei mir läuft die susefirewall2 so wie sie aus der tüte kommt...
tja sowie ich das aus der Mail von Torsten entnehmen konnte, macht diese aber auch einen DROP :( Außderdem wollte ich gerne wissen wie es funktioniert und selbst darüber Kontrolle haben was meine Firewall tut ... Gruß Daniel
On Monday 20 September 2004 17:40, Daniel Bauer wrote:
ich habe meine Firewall versucht mit iptables ... -j REJECT zu schreibe, was allerdings mit Fehler quittiert wird, daraufhin habe ich auch DROP eingesetzt. In der ManPage zu iptables finde ich auch kein REJECT.
Aus der Manpage von iptables: REJECT This is used to send back an error packet in response to the matched packet: otherwise it is equivalent to DROP so it is a terminating TARGET, ending rule traversal. This target is only valid in the INPUT, FORWARD and OUTPUT chains, and user-defined chains which are only called from those chains. The following option controls the nature of the error packet returned: --reject-with type The type given can be icmp-net-unreachable, icmp-host-unreachable, icmp-port- unreachable, icmp-proto-unreachable, icmp-net-prohibited or icmp-host-prohib ited, which return the appropriate ICMP error message (port-unreachable is the default). The option tcp-reset can be used on rules which only match the TCP protocol: this causes a TCP RST packet to be sent back. This is mainly useful for blocking ident (113/tcp) probes which frequently occur when sending mail to broken mail hosts (which won't accept your mail otherwise). Hast Du evtl. das '--reject-with' vergessen? Eine vollständige Regel könnte z.B. so aussehen: iptables -A INPUT -p tcp --dport 3306 -j REJECT --reject-with tcp-reset HTH, Martin
On 20 Sep 2004 at 19:36, Martin Schmitz wrote:
On Monday 20 September 2004 17:40, Daniel Bauer wrote:
ich habe meine Firewall versucht mit iptables ... -j REJECT zu schreibe, was allerdings mit Fehler quittiert wird, daraufhin habe ich auch DROP eingesetzt. In der ManPage zu iptables finde ich auch kein REJECT.
Aus der Manpage von iptables:
REJECT This is used to send back an error packet in response to the matched packet: otherwise it is equivalent to DROP so it is a terminating TARGET, ending rule traversal. This target is only valid in the INPUT, FORWARD and OUTPUT chains, and user-defined chains which are only called from those chains. The following option controls the nature of the error packet returned:
--reject-with type The type given can be icmp-net-unreachable, icmp-host-unreachable, icmp-port- unreachable, icmp-proto-unreachable, icmp-net-prohibited or icmp-host-prohib ited, which return the appropriate ICMP error message (port-unreachable is the default). The option tcp-reset can be used on rules which only match the TCP protocol: this causes a TCP RST packet to be sent back. This is mainly useful for blocking ident (113/tcp) probes which frequently occur when sending mail to broken mail hosts (which won't accept your mail otherwise).
Hast Du evtl. das '--reject-with' vergessen? Eine vollständige Regel könnte z.B. so aussehen:
iptables -A INPUT -p tcp --dport 3306 -j REJECT --reject-with tcp-reset
Hi Martin, wiedereinmal ist der klar im Vorteil der lesen kann, ich hatte nur oben die ACCEPT, DROP, QUEUE und RETURN gelesen, das mit REJECT hatte ich vorher aus der Liste und nachdem es nicht geklappt hatte, habe ich einfach auf DROP umgestellt und mein Script lief ... iptables -P INPUT REJECT Bad policy iptables -P INPUT DROP ok Das es dann für einzelne Regeln funktioniert ... Danke + Gruß Daniel
Am Montag, 20. September 2004 17:40 schrieb Daniel Bauer:
ich habe meine Firewall versucht mit iptables ... -j REJECT zu schreibe, was allerdings mit Fehler quittiert wird, daraufhin habe ich auch DROP eingesetzt. In der ManPage zu iptables finde ich auch kein REJECT.
Irgendwelches Tips? IMHO geht reject nur mit TCP. Ansonsten wäre dir fehlermeldung interessant.
MfG Markus
Markus Hochmann wrote:
Am Montag, 20. September 2004 17:40 schrieb Daniel Bauer:
ich habe meine Firewall versucht mit iptables ... -j REJECT zu schreibe, was allerdings mit Fehler quittiert wird, daraufhin habe ich auch DROP eingesetzt. In der ManPage zu iptables finde ich auch kein REJECT.
Irgendwelches Tips? IMHO geht reject nur mit TCP. Ansonsten wäre dir fehlermeldung interessant.
Jein. ;-) Auszug aus meinem Script: --- |iptables -P INPUT DROP |iptables -P OUTPUT DROP |iptables -P FORWARD DROP | | [...] | | iptables -A INPUT -i ppp0 -p tcp -j REJECT --reject-with tcp-reset | iptables -A INPUT -i ppp0 -p udp -j REJECT | | [...] --- Weshalb ich das hier so mache, steht in man iptables in der Erklärung zu TARGET EXTENSIONS -->REJECT Nebenbei, bei SuSEfirewall werden Pakete an Port 113 "Rejectet" Für spezielle Freunde ( fixe IPs die permanent "dossen", p2p-Störer, ms-freigabeports) benutze ich dennoch DROP. Die "Perverslinge" können ruhig in ein unhöfliches Timeout laufen, denn die merken eh nix. MfG Benn -- #250319 - http://counter.li.org
Am Mo, den 20.09.2004 schrieb Bernd Schmelter um 23:07:
Markus Hochmann wrote:
Am Montag, 20. September 2004 17:40 schrieb Daniel Bauer:
ich habe meine Firewall versucht mit iptables ... -j REJECT zu schreibe, was allerdings mit Fehler quittiert wird, daraufhin habe ich auch DROP eingesetzt. In der ManPage zu iptables finde ich auch kein REJECT.
Irgendwelches Tips? IMHO geht reject nur mit TCP. Ansonsten wäre dir fehlermeldung interessant.
Jein. ;-)
Auszug aus meinem Script:
--- |iptables -P INPUT DROP |iptables -P OUTPUT DROP |iptables -P FORWARD DROP | | [...] | | iptables -A INPUT -i ppp0 -p tcp -j REJECT --reject-with tcp-reset | iptables -A INPUT -i ppp0 -p udp -j REJECT | | [...] ---
Weshalb ich das hier so mache, steht in man iptables in der Erklärung zu TARGET EXTENSIONS -->REJECT
Nebenbei, bei SuSEfirewall werden Pakete an Port 113 "Rejectet"
Für spezielle Freunde ( fixe IPs die permanent "dossen", p2p-Störer, ms-freigabeports) benutze ich dennoch DROP. Die "Perverslinge" können ruhig in ein unhöfliches Timeout laufen, denn die merken eh nix.
ACK! Laut dem Logging hier: 42792 packets in database 1626 packets younger than 1 day 1580 packets today First was at 2004-09-02 13:00:26 Last was at 2004-09-20 23:13:29 Top Ports microsoft-ds 445 14788 epmap 135 12581 monkeycom 9898 1472 sgi-esphttp 5554 1350 netbios-ssn 139 1078 ms-sql-s 1433 820 unknown 1023 616 netbios-ns 137 474 ms-sql-m 1434 304 blackjack 1025 248 Bye Michael -- Alle Speere zu mir. -- Die letzten Worte eines Sportlehrers ________________________________________________________________________ http://macbyte.info/ ICQ #151172379 http://dattuxi.de/
On 20 Sep 2004 at 23:07, Bernd Schmelter wrote:
Markus Hochmann wrote:
Am Montag, 20. September 2004 17:40 schrieb Daniel Bauer:
ich habe meine Firewall versucht mit iptables ... -j REJECT zu schreibe, was allerdings mit Fehler quittiert wird, daraufhin habe ich auch DROP eingesetzt. In der ManPage zu iptables finde ich auch kein REJECT.
Irgendwelches Tips? IMHO geht reject nur mit TCP. Ansonsten wäre dir fehlermeldung interessant.
Jein. ;-)
Auszug aus meinem Script:
--- |iptables -P INPUT DROP |iptables -P OUTPUT DROP |iptables -P FORWARD DROP | | [...] | | iptables -A INPUT -i ppp0 -p tcp -j REJECT --reject-with tcp-reset | iptables -A INPUT -i ppp0 -p udp -j REJECT | | [...] ---
Weshalb ich das hier so mache, steht in man iptables in der Erklärung zu TARGET EXTENSIONS -->REJECT
Nebenbei, bei SuSEfirewall werden Pakete an Port 113 "Rejectet"
Für spezielle Freunde ( fixe IPs die permanent "dossen", p2p-Störer, ms-freigabeports) benutze ich dennoch DROP. Die "Perverslinge" können ruhig in ein unhöfliches Timeout laufen, denn die merken eh nix.
Tach Bernd, die Unhöflichkeit ist mir dabei "egal", aber es leuchtet mir ein das viele Tests hintereinander evtl. mehr Traffic verursachen als ein klares Nein, es ist halt wie immer eine "Glaubensfrage". Das mit dem -- reject-with tcp-reset find ich auf jeden Fall klasse ;) Danke und bis dann Daniel
On 20 Sep 2004 at 19:38, Markus Hochmann wrote:
Am Montag, 20. September 2004 17:40 schrieb Daniel Bauer:
ich habe meine Firewall versucht mit iptables ... -j REJECT zu schreibe, was allerdings mit Fehler quittiert wird, daraufhin habe ich auch DROP eingesetzt. In der ManPage zu iptables finde ich auch kein REJECT.
Irgendwelches Tips? IMHO geht reject nur mit TCP. Ansonsten wäre dir fehlermeldung interessant.
Hallo Markus, siehe dazu auch die Mail an Martin: Mein Fehler lag hier: iptables -P INPUT REJECT Bad policy iptables -P INPUT DROP ok Es funktioniert nicht als Default Policy Bis dann und danke Daniel
On Mon, Sep 20, 2004 at 11:39:14AM +0200, Torsten E. wrote:
Dem "Normalanwender" werden ggf. wohl die Erläuterungen in /etc/sysconfig/SuSEfirewall2 verständlich vorkommen: # 26.) # Do you want to REJECT packets instead of DROPing? # # DROPing (which is the default) will make portscans and attacks much # slower, as no replies to the packets will be sent. REJECTing
Was juckt es den Angreifer, wenn seine automatisierten Skripte langsamer ablaufen? Ob die Antwort sofort oder mit Verzögerung kommt, dürfte egal sein.
means, that # for every illegal packet, a connection reject packet is sent to the # sender. # # Choice: "yes" or "no", if not set defaults to "no" # FW_REJECT="no"
Warum sollte SuSE dem "Normalanwender" zu einem, je nach Standpunkt/Ansicht, "asozialem Verhalten" raten?
Das wüsste ich auch gerne. Jürgen
Am Montag, 20. September 2004 11:17 schrieb Jürgen Knelangen:
On Mon, Sep 20, 2004 at 10:41:44AM +0200, Michael wrote:
Am Montag, 20. September 2004 09:58 schrieb Jürgen Knelangen:
On Mon, Sep 20, 2004 at 09:12:48AM +0200, Torsten E. wrote:
Martin Schmitz schrieb am Sonntag, 19. September 2004 22:56:
On Sunday 19 September 2004 16:53, Torsten E. wrote:
Selbstredend DROPpe ich die - ansonsten erzeuge ich ja doppelten Traffic ... ;)
Man könnte dieses Verhalten asozial nennen. http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
| DROP offers no effective barrier to hostile forces but can | dramatically slow down applications run by legitimate users.
Also Jürgen Knelangen, man muß Leuten nicht gleich asoziales Verhalten vorwerfen nur weil sie Verbindungen Droppen und nicht Rejecten.
Hmpf. Ich schrieb man _könne_ es asozial nennen.
Da brauch man sich dann auch nicht über entsprechende gegenreaktionen zu wundern wie sie am Ende Eures Disputs nachzulesen sind. Zumal mir auch nicht ganz klar ist welches denn die "legitimen User" sein sollen die da in Mitleidenschaft gezogen werden.
Jeder der ohne böse Absicht einen Verbindungsaufbau begehrt, hat IMHO das Recht ein REJECT zu bekommen. Dann weiss man sofort, daß der Dienst nicht zu Verfügung steht.
Im anderen Fall (DROP) kommt keine Antwort. Die Verbindungsanfragen werden wiederholt. Erfolglos. Irgendwann gibt es einen Timeout. Die Zeit des Anfragenden wurde verschwendet, der Traffic erhöht.
Im Fall von Torsten E. waren es diverse Filesharing-Programme die eine Ver- bindung mit dem Vorbesitzer seiner IP-Adresse wünschten. Nenne mir einen guten Grund warum man hier nicht mit REJECT antworten sollte. Nenn mir einen Grund weshalb ich FileSharing freundlich gegenüber stehen sollte. Genau das Problem das Thorsten eigentlich besprechen wollte, wird doch durch FileSharing verursacht. FileSharing ist das asoziale Problem das es nicht auch noch durch freundliche Antworten zu unterstüßen gilt. In diesem Sinne gebe ich Thorsten Recht das es darum geht den Traffik nicht noch zu potenzieren dadurch das man auch noch darauf Antwortet.
Ein REJECT würde in seinem Fall sogar die Verbindungsanfragen reduzieren.
Kann ich mir nicht vorstellen. Der einzelne Client bekommt zwar schneller seine Antwort giebt diese aber nicht sofort an die 100.000 anderen Clients weiter. Soweit ich weiß fragt ein Client in regelmäßigen abständen ob eine Quelle noch vorhanden ist. Ist sie es nicht (oder nicht mehr) hört er damit auf. Da spielt es also keine Rolle ob er eine Ablehnende Antwort oder gar keine bekommt. Der einzige der von einem Reject profitiert ist der FileSharing Client ...
Liegt wahrscheinlich daran das ich den Text unter der o.g. Adresse nicht vollständig verstehe.
Ich finde ihn leicht verständlich.
Vielleicht könntest Du ja das noch mal mit eigenen Worten erklären, man möchte sich schließlich nicht asozial verhalten, oder gar Leute schädigen...nur weil man Dropt.
Hab's oben versucht.
Micha
P.s. : Auch wenn ich der Meinung bin das es zu einer Sachlichen Diskussion nicht notwendig ist seine Personalien auszutauschen, möchte ich darauf hinweisen das mein vollständiger Name aus der emailadresse hervor geht ...
Helga schickt regelmässig einen Hinweis auf die Etikette in dieser Liste. http://lists.suse.com/archive/suse-linux/2004-Sep/0675.html
Hierzu bin ich der Meinung das wenn die besondere Etikette dieser Liste so wichtig ist sollte sie gleich mit der Anmeldung zu der Liste versand werden. Ich für meinen Teil hätte jedenfalls noch keine Etikette zu sehen bekommen, wenn ich nicht durch eine Fußnote darauf aufmerksam geworden wäre. (also kein Posting der Etikette seit 25.07.2004 in dieser Liste) Gruß Micha
Gruß, Jürgen
Am Montag, 20. September 2004 11:47 schrieb Michael:
Am Montag, 20. September 2004 11:17 schrieb Jürgen Knelangen: [...]
Helga schickt regelmässig einen Hinweis auf die Etikette in dieser Liste. http://lists.suse.com/archive/suse-linux/2004-Sep/0675.html
Hierzu bin ich der Meinung das wenn die besondere Etikette dieser Liste so wichtig ist sollte sie gleich mit der Anmeldung zu der Liste versand werden. Ich für meinen Teil hätte jedenfalls noch keine Etikette zu sehen bekommen, wenn ich nicht durch eine Fußnote darauf aufmerksam geworden wäre. (also kein Posting der Etikette seit 25.07.2004 in dieser Liste)
Gruß Micha
Gruß, Jürgen
Hallo Michael, das stimmt aber nicht so ganz. Die Etikette wird _jeden_ Sonntag gepostet. Ist vielleicht Dein spamd nicht korrekt konfiguriert? Schau mal im Listenarchiv nach, ob Dir nicht tatsächlich ein paar Postings fehlen... Gruss Mario
Am Montag, 20. September 2004 11:59 schrieb Mario van der Linde:
Am Montag, 20. September 2004 11:47 schrieb Michael:
Am Montag, 20. September 2004 11:17 schrieb Jürgen Knelangen:
[...]
Helga schickt regelmässig einen Hinweis auf die Etikette in dieser Liste. http://lists.suse.com/archive/suse-linux/2004-Sep/0675.html
Hierzu bin ich der Meinung das wenn die besondere Etikette dieser Liste so wichtig ist sollte sie gleich mit der Anmeldung zu der Liste versand werden. Ich für meinen Teil hätte jedenfalls noch keine Etikette zu sehen bekommen, wenn ich nicht durch eine Fußnote darauf aufmerksam geworden wäre. (also kein Posting der Etikette seit 25.07.2004 in dieser Liste)
Gruß Micha
Gruß, Jürgen
Hallo Michael,
das stimmt aber nicht so ganz. Die Etikette wird _jeden_ Sonntag gepostet. Ist vielleicht Dein spamd nicht korrekt konfiguriert? Schau mal im Listenarchiv nach, ob Dir nicht tatsächlich ein paar Postings fehlen...
Werd noch mal schaun,aber am spamfilter kans nicht liegen. Eher das ich n Header übersehen habe ... Muß jetzt aber zur Arbeit schade, wo's gerade so nett wurde ;-) Micha
Gruss Mario
On Mon, Sep 20, 2004 at 11:47:34AM +0200, Michael wrote:
Am Montag, 20. September 2004 11:17 schrieb Jürgen Knelangen:
Jeder der ohne böse Absicht einen Verbindungsaufbau begehrt, hat IMHO das Recht ein REJECT zu bekommen. Dann weiss man sofort, daß der Dienst nicht zu Verfügung steht.
Im anderen Fall (DROP) kommt keine Antwort. Die Verbindungsanfragen werden wiederholt. Erfolglos. Irgendwann gibt es einen Timeout. Die Zeit des Anfragenden wurde verschwendet, der Traffic erhöht.
Im Fall von Torsten E. waren es diverse Filesharing-Programme die eine Ver- bindung mit dem Vorbesitzer seiner IP-Adresse wünschten. Nenne mir einen guten Grund warum man hier nicht mit REJECT antworten sollte. Nenn mir einen Grund weshalb ich FileSharing freundlich gegenüber stehen sollte.
Mir ging es mehr um das grundsätzliche Problem des DROPing. Das File- sharing zu 99% zum Tausch von illegalen Inhalten genutzt wird ist traurig, aber wahr. Aber das verhindern deine DROPs auch nicht. DROP statt REJECT erhöht die Sicherheit nicht. Gruß, Jürgen
Hallo Leute, Am Montag 20 September 2004 11:47 schrieb Michael:
Am Montag, 20. September 2004 11:17 schrieb Jürgen Knelangen:
Helga schickt regelmässig einen Hinweis auf die Etikette in dieser Liste. http://lists.suse.com/archive/suse-linux/2004-Sep/0675.html
Hierzu bin ich der Meinung das wenn die besondere Etikette dieser Liste so wichtig ist sollte sie gleich mit der Anmeldung zu der Liste versand werden.
Der Hinweis auf die Etikette wird mit der Begrüßungsnachricht des ezmlm beim Subscribe der Liste mitgeschickt. Und die schickt der Listmaster von SuSE. Die Etikette hat eine ziemlich lange Tradition und sorgt zuverlässig dafür, daß die Liste einigermaßen lesbar und der Ton hier zivil bleibt. Wer findet sich schon gerne mit irgendwelchen Mistmails im Internet wieder - daher wird hier der Realname bevorzugt. Leute mit 'schicken' Pseudonymen oder Kürzeln neigen erfahrungsgemäß eher zu d(t)rolligen Postings. Wir hier sind hoffentlich alle vernünftige Menschen, die wissen, daß gewisse Spielregeln das Leben und das Umgehen miteinander erleichtern und in gewissem Sinne standardisieren. Diese Regeln sind gewachsen und werden, stillschweigend, von den meisten hier respektiert und eingehalten. Nehmt es bitte so hin. Ansonsten, niemand ist gezwungen, die Umgangsformen hier auszuhalten. Wie man sich austrägt, steht unter jeder Mail drunter. Also bitte, keine Diskussion um das Für und Wider der Etikette. Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Am Montag, 20. September 2004 13:42 schrieb Helga Fischer:
Hallo Leute,
Am Montag 20 September 2004 11:47 schrieb Michael:
Am Montag, 20. September 2004 11:17 schrieb Jürgen Knelangen:
Helga schickt regelmässig einen Hinweis auf die Etikette in dieser Liste. http://lists.suse.com/archive/suse-linux/2004-Sep/0675.html
Hierzu bin ich der Meinung das wenn die besondere Etikette dieser Liste so wichtig ist sollte sie gleich mit der Anmeldung zu der Liste versand werden.
Der Hinweis auf die Etikette wird mit der Begrüßungsnachricht des ezmlm beim Subscribe der Liste mitgeschickt. Und die schickt der Listmaster von SuSE.
Die Etikette hat eine ziemlich lange Tradition und sorgt zuverlässig dafür, daß die Liste einigermaßen lesbar und der Ton hier zivil bleibt. Wer findet sich schon gerne mit irgendwelchen Mistmails im Internet wieder - daher wird hier der Realname bevorzugt. Leute mit 'schicken' Pseudonymen oder Kürzeln neigen erfahrungsgemäß eher zu d(t)rolligen Postings.
Wir hier sind hoffentlich alle vernünftige Menschen, die wissen, daß gewisse Spielregeln das Leben und das Umgehen miteinander erleichtern und in gewissem Sinne standardisieren.
Diese Regeln sind gewachsen und werden, stillschweigend, von den meisten hier respektiert und eingehalten.
Nehmt es bitte so hin.
Ansonsten, niemand ist gezwungen, die Umgangsformen hier auszuhalten. Wie man sich austrägt, steht unter jeder Mail drunter. Also bitte, keine Diskussion um das Für und Wider der Etikette.
Hey Helga, ich hatte nicht vor die Etikette in Frage zu stellen, ganz im Gegenteil, ich weiß respektvolle Umgangsformen durchaus zu schätzen ;-) In diesem Sinne have a lot of fun Micha
Helga
-- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Jürgen Knelangen wrote:
Also Jürgen Knelangen, man muß Leuten nicht gleich asoziales Verhalten vorwerfen nur weil sie Verbindungen Droppen und nicht Rejecten.
Hmpf. Ich schrieb man _könne_ es asozial nennen.
Dann meinst du wahrscheinlich "KÖNNTE" (mit "T"), sonst ist der Satz naemlich falsch.
Jeder der ohne böse Absicht einen Verbindungsaufbau begehrt, hat IMHO das Recht ein REJECT zu bekommen. Dann weiss man sofort, daß der Dienst nicht zu Verfügung steht.
Nein. Wenn der Rechner nicht da ist, bekommt er ja auch keine Antwort. Es handelt sich bei einem Drop um ein ganz normales Verhalten. Und nein, man KÖNNTE es nichteinmal asozial nennen, da ja der "unschuldig" empfangende Rechner so tut als wäre er gar nicht da.
Im anderen Fall (DROP) kommt keine Antwort. Die Verbindungsanfragen werden wiederholt. Erfolglos. Irgendwann gibt es einen Timeout. Die Zeit des Anfragenden wurde verschwendet, der Traffic erhöht.
Dann soll er sich halt überlegen wo er sich hinverbindet. Keine Antwort ist eine ganz normale, auch gut abfangbare, Reaktion.
Im Fall von Torsten E. waren es diverse Filesharing-Programme die eine Ver- bindung mit dem Vorbesitzer seiner IP-Adresse wünschten. Nenne mir einen guten Grund warum man hier nicht mit REJECT antworten sollte.
Wozu?
Ein REJECT würde in seinem Fall sogar die Verbindungsanfragen reduzieren.
Das ist nicht gesagt und meiner Erfahrung nach macht das keinen grossen Unterschied.
Hab's oben versucht.
Schluessig ist es immer noch nicht. Ciao T
Dr. Thorsten Brandau, Montag, 20. September 2004 11:54:
Nein. Wenn der Rechner nicht da ist, bekommt er ja auch keine Antwort. Es handelt sich bei einem Drop um ein ganz normales Verhalten.
Das stimmt nicht. Dann meldet nämlich schon der Provider ein Host Unreachable. Deshalb gilt: keine Antwort = IP-Adresse existiert. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Am Montag, 20. September 2004 12:11 schrieb Andreas Feile:
Dr. Thorsten Brandau, Montag, 20. September 2004 11:54:
Nein. Wenn der Rechner nicht da ist, bekommt er ja auch keine Antwort. Es handelt sich bei einem Drop um ein ganz normales Verhalten.
Das stimmt nicht. Dann meldet nämlich schon der Provider ein Host Unreachable. Deshalb gilt: keine Antwort = IP-Adresse existiert.
Das kommt auf die Konfiguration der Hardware des Providers an. Viele Antworten auch einfach gar nicht. Mfg, Thomas
Hey Talker, ich hab da mal ne Frage: Am Montag, 20. September 2004 11:54 schrieb Dr. Thorsten Brandau:
Jürgen Knelangen wrote:
Also Jürgen Knelangen, man muß Leuten nicht gleich asoziales Verhalten vorwerfen nur weil sie Verbindungen Droppen und nicht Rejecten.
Hmpf. Ich schrieb man _könne_ es asozial nennen.
Dann meinst du wahrscheinlich "KÖNNTE" (mit "T"), sonst ist der Satz naemlich falsch.
Jeder der ohne böse Absicht einen Verbindungsaufbau begehrt, hat IMHO das Recht ein REJECT zu bekommen. Dann weiss man sofort, daß der Dienst nicht zu Verfügung steht.
Nein. Wenn der Rechner nicht da ist, bekommt er ja auch keine Antwort. Es handelt sich bei einem Drop um ein ganz normales Verhalten.
Und nein, man KÖNNTE es nichteinmal asozial nennen, da ja der "unschuldig" empfangende Rechner so tut als wäre er gar nicht da.
Stellt sich also die folgende Frage: Sind Rechner Wesen mit Sozialverhalten und wie kann man eine Resozialisierung eines asozialen Rechners einleiten?
Am Montag, 20. September 2004 09:58 schrieb Jürgen Knelangen:
On Mon, Sep 20, 2004 at 09:12:48AM +0200, Torsten E. wrote:
Martin Schmitz schrieb am Sonntag, 19. September 2004 22:56:
On Sunday 19 September 2004 16:53, Torsten E. wrote:
Selbstredend DROPpe ich die - ansonsten erzeuge ich ja doppelten Traffic ... ;)
Man könnte dieses Verhalten asozial nennen. <http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
Das würde also bedeuten, dass SuSE asoziales Verhalten fördert indem bei der SuSE-Firewall per default Pakete gedropt werden und _nicht_ rejected. Oder habe ich Dich falsch verstanden? lg, Andreas.
On Mon, Sep 20, 2004 at 11:26:36AM +0200, Andreas Scherer wrote:
Am Montag, 20. September 2004 09:58 schrieb Jürgen Knelangen:
On Mon, Sep 20, 2004 at 09:12:48AM +0200, Torsten E. wrote:
Martin Schmitz schrieb am Sonntag, 19. September 2004 22:56:
On Sunday 19 September 2004 16:53, Torsten E. wrote:
Selbstredend DROPpe ich die - ansonsten erzeuge ich ja doppelten Traffic ... ;)
Man könnte dieses Verhalten asozial nennen. <http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
Das würde also bedeuten, dass SuSE asoziales Verhalten fördert indem bei der SuSE-Firewall per default Pakete gedropt werden und _nicht_ rejected. Oder habe ich Dich falsch verstanden?
Das bedeutet, daß DROP nicht immer die richtige Wahl ist, und Default- Einstellungen nicht immer die richtigen sind. ;) IMHO. Gruß, Jürgen
On Monday 20 September 2004 11:26, Andreas Scherer wrote:
Am Montag, 20. September 2004 09:58 schrieb Jürgen Knelangen:
On Mon, Sep 20, 2004 at 09:12:48AM +0200, Torsten E. wrote:
Martin Schmitz schrieb am Sonntag, 19. September 2004 22:56:
On Sunday 19 September 2004 16:53, Torsten E. wrote:
Selbstredend DROPpe ich die - ansonsten erzeuge ich ja doppelten Traffic ... ;)
Man könnte dieses Verhalten asozial nennen. <http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
Das würde also bedeuten, dass SuSE asoziales Verhalten fördert indem bei der SuSE-Firewall per default Pakete gedropt werden und _nicht_ rejected. Oder habe ich Dich falsch verstanden?
Ja. Sollte das tatsächlich den "default"-Einstellungen von SuSEs "Firewall" entsprechen, so ist das tatsächlich unsinnig und asozial von SuSE. Die "personal-firewall" "rejectet" die Anfragen übrigens ordnungsgemäß. TCP/IP funktioniert nunmal nach bestimmten Regeln. Wenn da jeder sein eigenes Süppchen kocht, dann können wir die Interoperabilität des Internets ganz schnell vergessen. Wer näheres dazu wissen möchte, der lese RFC 1122. Um es mal mit einer einfachen Analogie zu versuchen: Du bist oft in fremden Städten unterwegs. Um Dein Ziel zu finden, fragst Du die Leute auf der Straße nach dem Weg und erhälst oft freundliche Antworten, die Dir weiterhelfen. Wenn Dich nun zu Hause jemand nach dem Weg fragt, gehst Du dann einfach weiter, ohne wenigstens zu sagen "tut mir Leid, ich kenne den Weg auch nicht"? Das unbeantwortete Wegwerfen von IP-Paketen ist in der IP-Kommunikation über TCP nunmal nicht vorgesehen. Es ist technisch auch nicht haltbar, daß so ein Verhalten irgendeinen Vorteil gegenüber dem regelgerechten bringt. Martin
Martin Schmitz schrieb am Montag, 20. September 2004 15:55:
On Monday 20 September 2004 11:26, Andreas Scherer wrote:
Am Montag, 20. September 2004 09:58 schrieb Jürgen Knelangen:
On Mon, Sep 20, 2004 at 09:12:48AM +0200, Torsten E. wrote:
Martin Schmitz schrieb am Sonntag, 19. September 2004 22:56:
On Sunday 19 September 2004 16:53, Torsten E. wrote:
[...]
Das würde also bedeuten, dass SuSE asoziales Verhalten fördert indem bei der SuSE-Firewall per default Pakete gedropt werden und _nicht_ rejected. Oder habe ich Dich falsch verstanden?
Ja. Sollte das tatsächlich den "default"-Einstellungen von SuSEs "Firewall" entsprechen, so ist das tatsächlich unsinnig und asozial von SuSE. Die "personal-firewall" "rejectet" die Anfragen übrigens ordnungsgemäß. TCP/IP funktioniert nunmal nach bestimmten Regeln. Wenn da jeder sein eigenes Süppchen kocht, dann können wir die Interoperabilität des Internets ganz schnell vergessen. Wer näheres dazu wissen möchte, der lese RFC 1122.
Um es mal mit einer einfachen Analogie zu versuchen: Du bist oft in fremden Städten unterwegs. Um Dein Ziel zu finden, fragst Du die Leute auf der Straße nach dem Weg und erhälst oft freundliche Antworten, die Dir weiterhelfen. Wenn Dich nun zu Hause jemand nach dem Weg fragt, gehst Du dann einfach weiter, ohne wenigstens zu sagen "tut mir Leid, ich kenne den Weg auch nicht"?
Das unbeantwortete Wegwerfen von IP-Paketen ist in der IP-Kommunikation über TCP nunmal nicht vorgesehen. Es ist technisch auch nicht haltbar, daß so ein Verhalten irgendeinen Vorteil gegenüber dem regelgerechten bringt.
Nun, ich abe nun einmal die Einstellung geändert (wenn das nun tatsächlich die Einstellungen sind): # /etc/sysconfig/SuSEfirewall2 # # for use with /sbin/SuSEfirewall2 version 3.1 which is for 2.4 kernels! ... #FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom" FW_CUSTOMRULES="" ... # 26.) # Do you want to REJECT packets instead of DROPing? # # DROPing (which is the default) will make portscans and attacks much # slower, as no replies to the packets will be sent. REJECTing means, that # for every illegal packet, a connection reject packet is sent to the # sender. # # Choice: "yes" or "no", if not set defaults to "no" # # FW_REJECT="no" FW_REJECT="yes" Ein Beenden & Neustarten der FW2 erbrachte keine Änderung, und nach einem Neustart des Systems erscheint folgendes in den Logdateien: Sep 20 16:52:44 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 ... Sep 20 16:52:44 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 ... Sep 20 16:52:45 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 ... Sep 20 16:52:47 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 ... Sep 20 16:52:49 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 ... Sep 20 16:52:50 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 ... Sep 20 16:52:51 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 ... Sep 20 16:52:52 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 ... Sep 20 16:52:53 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 ... Da ist nichts mit REJECTen ... und nun?
Martin
Torsten
On Monday 20 September 2004 16:55, Torsten E. wrote:
Da ist nichts mit REJECTen ... und nun?
Evtl. hilft Dir Abschnitt 1.) aus /etc/sysconfig/SuSEfirewall2 weiter: # 1.) # Should the Firewall run in quickmode? # # "Quickmode" means that only the interfaces pointing to external networks # are secured, and no other. all interfaces not in the list of FW_DEV_EXT # are allowed full network access! Additionally, masquerading is # automatically activated for FW_MASQ_DEV devices. and last but not least: # all incoming connection via external interfaces are REJECTED. # You will only need to configure 2.) and FW_MASQ_DEV in 6.) # Optionally, you may add entries to section 9a.) # # Choice: "yes" or "no", if not set defaults to "no" # FW_QUICKMODE="yes" Martin
Hi, nun mal ein paar Infos, die ich aufgrund meiner Nachfragen/Beschwerden bekam. Kontaktiert hatte ich dazu: BSI-CERT, IFCC (FBI), Fa. Savvis, Fa. Exodus. Zumindest das CERT und IFCC gehen davon aus, daß es sich um eine DOS Attacke gehandelt hat. Beide Institutionen raten mir, sollte so etwas nochmals vorkommen, den gesamten Traffic mittels tcpdump mitzuschneiden, und ihnen dann neben den Logeinträgen zukommen zu lassen. Ein Mitarbeiter des CERT hat auch eine recht interessante Erklärung zu der Häufigkeit, dem IP-Adresswechsel, etc. abgegeben. Sowohl das CERT als auch IFCC waren recht interessiert an den Daten, und wollen auch weiterhin gerne informiert werden, sollte sich Savvis oder Exodus dazu melden. Zum Thema DROP oder REJECT gibt es keine klaren, sich festlegenden Meinungen: im Tenor: je mehr Anfragen solcherart kommen, desto größer ist die Wahrscheinlichkeitkeit, daß man aufgrund der REJECTs und dem damit zusätzlich entstehenden Verkehrs das eigene System unerreichbarer macht - allerdings auf Kosten "legitimer" Systeme, welche eine Verbindung aufbauen wollen. Laut Fa. Savvis allerdings verhält sich das Ganze etwas anders - wobei das Resultat des betroffenen Systems allerdings gleich bleibt. Dort habe ich mich erkundigt, on sie etwas gegen diese massiven Verbindungsversuche unternehmen können/würden, da das angegebene Quellnetzwerk zu den ihren gehört. Nun gab es vor einigen Minuten eine offizielle Antwort von dort: es würde sich um einen Suchrobot der Fa. "Overpeer, Inc." handeln, welcher andere Systeme/Netzwerke nach "copyrighted material" in Netzwerken & p-2-p Clients sucht. Die Fa. Overpeer habe ich nun einmal per Email angeschrieben, um zu erfahren, ob dem tatsächlich so ist - zumindest ist dies laut ihrer Website durchaus denkbar (http://www.overpeer.com/). Fa. Exodus hat sich bis dato noch gar nicht gemeldet ... So, nun wäre es zukünftig noch hilfreich, wenn es eine Möglichkeit gäbe, automatisch bspw. eine 20 minütige tcpdump Aufzeichnung anstoßen zu lassen .. ;-) Gruß Torsten
Hallo Am Dienstag, 21. September 2004 20:07 schrieb Torsten E.:
nun mal ein paar Infos, die ich aufgrund meiner Nachfragen/Beschwerden bekam. Kontaktiert hatte ich dazu: BSI-CERT, IFCC (FBI), Fa. Savvis, Fa. Exodus. [...]
Nun gab es vor einigen Minuten eine offizielle Antwort von dort: es würde sich um einen Suchrobot der Fa. "Overpeer, Inc." handeln, welcher andere Systeme/Netzwerke nach "copyrighted material" in Netzwerken & p-2-p Clients sucht. Die Fa. Overpeer habe ich nun einmal per Email angeschrieben, um zu erfahren, ob dem tatsächlich so ist - zumindest ist dies laut ihrer Website durchaus denkbar (http://www.overpeer.com/).
Mindestens diesen Punkt finde ich dabei doch recht witzig. Währe schön wenn man das noch etwas "verfestigen" könnte. Gruß Harald
On Tuesday 21 September 2004 20:17, Harald Huthmann wrote:
Hallo
Am Dienstag, 21. September 2004 20:07 schrieb Torsten E.:
nun mal ein paar Infos, die ich aufgrund meiner Nachfragen/Beschwerden bekam. Kontaktiert hatte ich dazu: BSI-CERT, IFCC (FBI), Fa. Savvis, Fa. Exodus. [...]
Nun gab es vor einigen Minuten eine offizielle Antwort von dort: es würde sich um einen Suchrobot der Fa. "Overpeer, Inc." handeln, welcher andere Systeme/Netzwerke nach "copyrighted material" in Netzwerken & p-2-p Clients sucht. Die Fa. Overpeer habe ich nun einmal per Email angeschrieben, um zu erfahren, ob dem tatsächlich so ist - zumindest ist dies laut ihrer Website durchaus denkbar (http://www.overpeer.com/).
Mindestens diesen Punkt finde ich dabei doch recht witzig. Währe schön wenn man das noch etwas "verfestigen" könnte. Vor allem schreit das ja geradezu nach einem honeypot der defaultmässig auf allen Linux Büchsen installiert wird und der gefakte positive responses generiert. Deren Augen möchte ich sehen wenn die von den gefakten positives überschwemmt werden. Deren DOS ähnliche Scans würden sich ruck zuck in eine zurückschwingende Keule verwandeln. *lach*
Ich bin beileibe kein Freund von irgendwelchen mafiösen Raubkopierern die im grossen Stil sich das Eigentum anderer aneignen wie diese Obskuren Leute die letztens im München hops genommen wurden. Allerdings sollte man die Kirche auch im Dorfe lassen. Wenn Companies wie diese overdingsda bereits jetzt durch DOS ähnliche Scans so viel Traffic erzeugen dann wird das in kürze zu einem Problem anwachsen gegen dem die heutige Spam Situation ein Witz ist. Tschüss, Thomas
Torsten E. schrieb:
nun habe ich heute ca. 460000 Einträge in der Art: Sep 18 23:45:51 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC= SRC=64.92.150.46 DST=217.255.54.135 LEN=98 TOS=0x00 PREC=0x00 TTL=58 ID=12723 DF PROTO=UDP SPT=4672 DPT=11164 LEN=78
Ist es bei allen Einträge der Port 4672? Lt. einer schnellen Google-Suche ist es ein Standardport von eMule. Markus
Torsten E. wrote:
Guten Abend Liste,
nun habe ich heute ca. 460000 Einträge in der Art: Sep 18 23:45:51 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC= SRC=64.92.150.46 DST=217.255.54.135 LEN=98 TOS=0x00 PREC=0x00 TTL=58 ID=12723 DF PROTO=UDP SPT=4672 DPT=11164 LEN=78 in /var/log/messages (rund 97 pro Sekunde).
Aeh, SPT 4672 ist edonkey. DPT ist wohl ein port eines edonkey servers der mal deine IP hatte. dagegen kannst du GAR NICHTS machen.
Die Datenquelle schaut immer aus in der Art (nur Auszüge ... ;)): SRC=64.209.193.4
sag bloss. Das sind rechner die den esel laufen lassen.
Um das Ganze aber nicht langweilig zu machen, werden die Ports 11164 & 6881 angesprochen ...
6881 ist gnutella.
Die Logdatei hat mittlerweile (nur für heute, 18.09.2004), eine Größe von 180MB.
shit happens.
Kann man da irgendetwas gegen tun, außer die Verbindung zum Internet zu trennen?
weder noch. es gibt die moeglichkeit den loglevel zu aendern (in susefirewall2) und dadurch diese meldungen zu unterdruecken.
Rein rechtlich würde ich denjenigen gerne anstinken, da es, wenn man keine Flatrate haben sollte, teuer werden kann ...
altbekanntes problem, daher kann man smpppd auch so einstellen, das er die anfragen auf unassigned ports nicht als traffic zaehlt. hauptsache dein rechner ist auf diesen ports dicht. ein portscan sieht anders aus und kommt nicht immer vom gleichen port. ciao T
Dr. Thorsten Brandau wrote:
Torsten E. wrote:
Guten Abend Liste,
nun habe ich heute ca. 460000 Einträge in der Art: Sep 18 23:45:51 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC= SRC=64.92.150.46 DST=217.255.54.135 LEN=98 TOS=0x00 PREC=0x00 TTL=58 ID=12723 DF PROTO=UDP SPT=4672 DPT=11164 LEN=78 in /var/log/messages (rund 97 pro Sekunde).
Aeh, SPT 4672 ist edonkey. DPT ist wohl ein port eines edonkey servers der mal deine IP hatte. dagegen kannst du GAR NICHTS machen.
Hallo! Hatte mal was ähnliches als ich eine IP geerbt hatte... Da hatte ich in den ersten Tagen gut 120'000 Zugriffe pro Tag auf edonkey ports, erst nach ca 2 wochen verstummten die dann ziemlich als die merkten dass das bei mir nicht läuft... Also entweder abwarten bis es aufhört - ich nehme an es wird auch bei dir jeden Tag ca 10-20% weniger..., oder ansonsten neu einwählen oder so und auf eine neue IP hoffen (wenn man immer wieder dieselbe kriegt ev versuchen das alte lease zu löschen). Gruss Matti
Am Montag, 20. September 2004 07:18 schrieb Dr. Thorsten Brandau:
Torsten E. wrote:
Guten Abend Liste,
nun habe ich heute ca. 460000 Einträge in der Art: Sep 18 23:45:51 warblade kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC= SRC=64.92.150.46 DST=217.255.54.135 LEN=98 TOS=0x00 PREC=0x00 TTL=58 ID=12723 DF PROTO=UDP SPT=4672 DPT=11164 LEN=78 in /var/log/messages (rund 97 pro Sekunde).
Aeh, SPT 4672 ist edonkey. DPT ist wohl ein port eines edonkey servers der mal deine IP hatte. dagegen kannst du GAR NICHTS machen.
Die Datenquelle schaut immer aus in der Art (nur Auszüge ... ;)): SRC=64.209.193.4
sag bloss. Das sind rechner die den esel laufen lassen.
Um das Ganze aber nicht langweilig zu machen, werden die Ports 11164 & 6881 angesprochen ...
6881 ist gnutella. Nak, Ports 6881-6999 sind Bittorent.
Die Logdatei hat mittlerweile (nur für heute, 18.09.2004), eine Größe von 180MB.
shit happens.
Kann man da irgendetwas gegen tun, außer die Verbindung zum Internet zu trennen?
weder noch. es gibt die moeglichkeit den loglevel zu aendern (in susefirewall2) und dadurch diese meldungen zu unterdruecken.
Rein rechtlich würde ich denjenigen gerne anstinken, da es, wenn man keine Flatrate haben sollte, teuer werden kann ...
altbekanntes problem, daher kann man smpppd auch so einstellen, das er die anfragen auf unassigned ports nicht als traffic zaehlt.
hauptsache dein rechner ist auf diesen ports dicht. ein portscan sieht anders aus und kommt nicht immer vom gleichen port.
ciao
T
participants (21)
-
Andreas Feile -
Andreas Scherer -
Bernd Schmelter -
Daniel Bauer -
Dr. Thorsten Brandau -
Georg Schilling -
Harald_mail＠t-online.de -
Helga Fischer -
Jürgen Knelangen -
Mario van der Linde -
Markus Hochmann -
Markus Neugebauer -
Martin Schmitz -
Mathias Homann -
Matthias Keller -
Michael -
Michael Raab -
Thomas Gräber -
Thomas Stark -
Thomas Templin -
Torsten E.