On Sat, Jun 16, 2001 at 16:19 +0000, Erich Nachtmann wrote:

Hi!

Hier eine annonymisierte Mail aus einer LUG.

CU Erich

---------- Weitergeleitete Nachricht ----------

Hallo Leute,

Wenn ich meiner Firewall glauben darf (tu ich), dann scheint das TDSL- Netz der Telekom die absolute Speilwiese für Hacker zu sein. Seitdem der Linux-Route im Netz hängt habe ich immer volle Firewall Logs. Ein Ausdruck würde jeden Tag mehrere Seiten Papier füllen.

Seit Tagen habe ich aber im 10-Sekunden-Takt Scans von verschiedenen Quellports auf den TCP-Port 6346, und zwar stundenlang von einem Angreifer. Danach ist Ruhe und kurze Zeit später geht es von einem anderen weiter.

Ein Beispiel :

Eigene IP : 217.80.29.15

Jun 16 00:12:04 et kernel: Packet log: inWEB DENY ppp0 PROTO=6 208.227.166.222:3623 217.80.29.15:6346 L=48 S=0x00 I=29219 F=0x4000 T=50 SYN (#52) Jun 16 00:12:07 et kernel: Packet log: inWEB DENY ppp0 PROTO=6 208.227.166.222:3623 217.80.29.15:6346 L=48 S=0x00 I=29221 F=0x4000 T=50 SYN (#52) Jun 16 00:12:13 et kernel: Packet log: inWEB DENY ppp0 PROTO=6 208.227.166.222:3623 217.80.29.15:6346 L=48 S=0x00 I=29222 F=0x4000 T=50 SYN (#52)

nslookup 208.227.166.222 ergibt 208.227.166.222.quickclick.ctc.net

Was macht man dagegen.

Kann man Gegenmaßnahmen einleiten, die den Angreifer so beschäftigen, daß er aufhört ?? Rechtlich wirds wohl sehr schwierig.

Jemand ne Idee ??

1. Du bist hier etwas OT, versuch es in suse-security. 2. Man sollte sich bei dem ISP beschweren, von dessen Adressbereich der (vermutliche) Angriff ausgeht. Manchmal hilft es. 3. Auf jeden Fall sollte man keine "Gegenschläge" führen- man könnte sich selbst strafbar machen... Grüße Volker

On Mon, Jun 18, 2001 at 09:53:38AM +0200, Peter Mack wrote:

...

Wenn ich meiner Firewall glauben darf (tu ich), dann scheint das TDSL- Netz der Telekom die absolute Speilwiese für Hacker zu sein. Seitdem der Linux-Route im Netz hängt habe ich immer volle Firewall Logs. Ein Ausdruck würde jeden Tag mehrere Seiten Papier füllen.

Seit Tagen habe ich aber im 10-Sekunden-Takt Scans von verschiedenen Quellports auf den TCP-Port 6346, und zwar stundenlang von einem Angreifer. Danach ist Ruhe und kurze Zeit später geht es von einem anderen weiter. [..] Jemand ne Idee ??

Sicher ist das hier etwas "off topic" aber wer sagt denn, daß das Problem nicht unter ISDN genauso auftreten kann?!

Seit meinem Umstieg auf T-DSL habe ich dieses (naja) Phänomen auch. Es sind immer die gleichen Ports betroffen: 1214, 6346 um mal die zwei häufigsten zu nennen. Ich habe mir mal die Mühe gemacht und gesucht welche Dienste diese Ports benutzen (ist schon wieder ein paar Wochen her, deshalb bitte nicht schlagen wenn's falsch ist): 6346 ist E-Donkey.

Die offizielle Liste liefert: # Ward Silver kazaa 1214/tcp KAZAA kazaa 1214/udp KAZAA gnutella-svc 6346/tcp gnutella-svc gnutella-svc 6346/udp gnutella-svc

Also grob gesagt Peer-to-Peer Dienste.

Ich sehe das also nicht als Hacker-Angriff sondern als puren Zufall an. Bedingt durch die dyn. IP-Adresse.

Ich sehe es auch nicht als Angriff, bin mir aber nicht sicher ob es nur an dyn. IP liegt oder z.B: im Fall des gnutella ports die Suche nach neuen gnutella hosts ist.

Naja, lästig ist es allemal. Das Log-File läuft voll und was noch viel lästiger ist: der Schei.. hält die Verbindung offen!

Aber eigentlich nur wenn man sich als "schwarzes Loch" (DENY) ausgibt, bei REJECT sollte der Spuk schnell aufhoeren.

Ich hatte hier schon den Fall, daß die Kiste ca. 8 Stunden ungewollt online war. Na gut, ich habe die T-DSL Flat, da juckt es mich nicht weiter. Aber gut fand ich das nicht!

Ich habe mir zwar schon "den Wolf" gesucht aber eine Lösung noch nicht gefunden. :-(

(Kurzfassung) Das Problem ist, daß der PPPD bestimmt ob die Verbindung offen bleibt und dann erst der Firewall die ungewollten Pakete wegwirft.

Vielleicht hat ja hier Jemand eine gute Idee!

Ja da muss generell etwas gemacht werden. Moeglich waer zum Beispiel ueber netfilter die Pakete durch einen daemon zu bewerten und dann gezielt den pppd runterzufahren (bewerten := nur bestimmte Pkt duerfen den timeout counter resetten). Aehnlich kann man selektives DOD steuern. -- Karsten Keil SuSE Labs ISDN development

On Mon, Jun 18, 2001 at 12:13:58PM +0200, Kilian Krause wrote:

Hi Karsten,

Montag, 18. Juni 2001, 11:44:15, schriebst du: KK> Ja da muss generell etwas gemacht werden. Moeglich waer zum Beispiel KK> ueber netfilter die Pakete durch einen daemon zu bewerten und dann gezielt KK> den pppd runterzufahren (bewerten := nur bestimmte Pkt duerfen den timeout KK> counter resetten). Aehnlich kann man selektives DOD steuern. das klingt ja prima.. gibts dazu ne vorlage? auch für das selektive DOD?

Nein das sind nur Ueberlegungen, kein Plan es zu realisieren. -- Karsten Keil SuSE Labs ISDN development

On Mon, Jun 18, 2001 at 08:26:50PM +0200, Peter Mack wrote:

On Mon, 18 Jun 2001, Karsten Keil wrote:

...

Die offizielle Liste liefert:

# Ward Silver kazaa 1214/tcp KAZAA kazaa 1214/udp KAZAA

gnutella-svc 6346/tcp gnutella-svc gnutella-svc 6346/udp gnutella-svc

Blöde Frage: wo gibt es diese Liste?

http://www.isi.edu/in-notes/iana/assignments/port-numbers

Ja, gut, erster Anlaufpunkt ist immer meine /etc/services. Nu ist aber meine /etc/services schon ein paar "Tage" alt! Wo finde ich was wirklich aktuelles?

s.o. (wobei ich die Addresse selbst auch aus der services hab :-)

[..]

...

Aber eigentlich nur wenn man sich als "schwarzes Loch" (DENY) ausgibt, bei REJECT sollte der Spuk schnell aufhoeren.

Da sollte ich vielleicht einfach mal meine Filterregeln ändern...

[..]

...

Ja da muss generell etwas gemacht werden. Moeglich waer zum Beispiel ueber netfilter die Pakete durch einen daemon zu bewerten und dann gezielt den pppd runterzufahren (bewerten := nur bestimmte Pkt duerfen den timeout counter resetten). Aehnlich kann man selektives DOD steuern.

Im aktuellen pppd ist ja so etwas schon vorgesehen. Aber nur in Verbindung mit FreeBSD!

Gruß

Peter

-- To unsubscribe, e-mail: suse-isdn-unsubscribe@suse.com For additional commands, e-mail: suse-isdn-help@suse.com

-- Karsten Keil SuSE Labs ISDN development