Hallo,
die Firewall (iptables) hat mir folgendes Paket rausgefischt:
Jan 3 16:30:36 intranet kernel: DROP-ICMP IN= OUT=eth0 SRC=192.168.20.1 DST=192.168.20.88 LEN=56 TOS=0x00 PREC=0xC0 TTL=255 ID=34583 DF PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.20.88 DST=207.26.131.137 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=15380 PROTO=ICMP TYPE=8 CODE=0 ID=768 SEQ=32569 ]
Die beteiligten Rechner: A 192.168.20.88 = Windows-Laptop B 192.168.20.1 = Linux-Router/Firewall C 207.26.131.137 ???
Masquerading ist eingeschaltet, Ping nach draussen ist erlaubt. Scheinbar ist das ein Antwortpaket von C an A auf ein Ping. Allerdings gingen von A gar keine Pakete zum Router, egal ob TCP, UDP oder ICMP. Trotzdem kamen über mehrere Stunden solche Pakete zurück(?). Inzwischen ist die Windose aus und es herrscht Ruhe. Mal sehen wie's morgen ist.
C läßt sich nicht anpingen und der Name ist auch nicht auflösbar.
Kann mir jemand sagen, was die Ursache sein kann?
Danke, Rico
On Thu, Jan 03, 2002 at 08:17:29PM +0100, Rico Koerner wrote:
Hallo,
Hallo Rico,
die Firewall (iptables) hat mir folgendes Paket rausgefischt:
Jan 3 16:30:36 intranet kernel: DROP-ICMP IN= OUT=eth0 SRC=192.168.20.1 DST=192.168.20.88 LEN=56 TOS=0x00 PREC=0xC0 TTL=255 ID=34583 DF PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.20.88 DST=207.26.131.137 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=15380 PROTO=ICMP TYPE=8 CODE=0 ID=768 SEQ=32569 ]
Die beteiligten Rechner: A 192.168.20.88 = Windows-Laptop B 192.168.20.1 = Linux-Router/Firewall C 207.26.131.137 ???
Da scheint jemand ein traceroute auf dem Host 192.168.20.88 laufen zu lassen. Von dort wurde nämlich ein 'ping request' (Packetinformationen zwischen den Klammern) abgeschickt, mit einer TTL von 1. Dieses Packet erreicht also gerade mal den 1. HOP (192.168.20.1) und hat dort nun eine TTL von 0. Das veranlasst den Router, ein Timeout-ICMP Packet zurückzuschicken, das nun in deiner Firewall hängen bleibt.
Es handelt sich also nicht um einen Crackerangriff, sondern um eine Art Scan, der normalerweise von traceroute benutzt wird, um den Weg von Datenpacketen zu verfolgen. Warum eine WindowsKiste das nun macht kann ich dir aber auch nicht sagen... :)
Ciao, Tobias
On Tue, Jan 01, 2002 at 10:47:12PM +0100, Tobias Koenig wrote:
Jan 3 16:30:36 intranet kernel: DROP-ICMP IN= OUT=eth0 SRC=192.168.20.1 DST=192.168.20.88 LEN=56 TOS=0x00 PREC=0xC0 TTL=255 ID=34583 DF PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.20.88 DST=207.26.131.137 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=15380 PROTO=ICMP TYPE=8 CODE=0 ID=768 SEQ=32569 ]
Die beteiligten Rechner: A 192.168.20.88 = Windows-Laptop B 192.168.20.1 = Linux-Router/Firewall C 207.26.131.137 ???
Da scheint jemand ein traceroute auf dem Host 192.168.20.88 laufen zu lassen. Von dort wurde nämlich ein 'ping request' (Packetinformationen zwischen den Klammern) abgeschickt, mit einer TTL von 1. Dieses Packet erreicht also gerade mal den 1. HOP (192.168.20.1) und hat dort nun eine TTL von 0. Das veranlasst den Router, ein Timeout-ICMP Packet zurückzuschicken, das nun in deiner Firewall hängen bleibt.
Ja, so sehe ich das auch. Während traceroute(unix) mit UDP + ICMP port unreachable arbeitet, nimmt das windowsche tracert ICMP echo req + echo reply. Obiges log ist also ziemlich wahrscheinlich ein Antwortpaket auf eine Anfrage von Windows-tracert vom Laptop aus.
Reinhard
Erstmal Danke an alle.
Tobias Koenig wrote:
On Thu, Jan 03, 2002 at 08:17:29PM +0100, Rico Koerner wrote:
Hallo,
Hallo Rico,
die Firewall (iptables) hat mir folgendes Paket rausgefischt:
Jan 3 16:30:36 intranet kernel: DROP-ICMP IN= OUT=eth0 SRC=192.168.20.1 DST=192.168.20.88 LEN=56 TOS=0x00 PREC=0xC0 TTL=255 ID=34583 DF PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.20.88 DST=207.26.131.137 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=15380 PROTO=ICMP TYPE=8 CODE=0 ID=768 SEQ=32569 ]
Die beteiligten Rechner: A 192.168.20.88 = Windows-Laptop B 192.168.20.1 = Linux-Router/Firewall C 207.26.131.137 ???
Da scheint jemand ein traceroute auf dem Host 192.168.20.88 laufen zu lassen.
traceroute, darauf bin ich nicht gekommen. Es war aber kein vom User gestartetes Programm. Es war auch kein Laptop sondern eine HP-(PC)-Kiste, wie mir der dortige Admin heut mitteilte. Mit einem Brut-Force-Find ;-) auf der Festplatte fand sich auch die IP in einer Datei, welche zum Treiber einer HP-Multimediatastatur gehörte. Da die Tastatur nicht mehr existiert, konnte dieser entfernt werden und nun herrscht Ruhe.
Jaja nicht nur E.T. will nach Hause telefonieren. Von HP-Printservern hab ich dieses Verhalten auch schon erlebt. :-(
Von dort wurde nämlich ein 'ping request' (Packetinformationen zwischen den Klammern) abgeschickt, mit einer TTL von 1. Dieses Packet erreicht also
echo-request hab ich auch festgestellt, das mit der TTL ist mir entgangen.
gerade mal den 1. HOP (192.168.20.1) und hat dort nun eine TTL von 0. Das veranlasst den Router, ein Timeout-ICMP Packet zurückzuschicken, das nun in deiner Firewall hängen bleibt.
Wieder was dazugelernt. :-)
Ein traceroute darauf verliert sich übrigens bei 20 Hops.
Danke an Konrad für's abschreiben der ICMP-Type-Liste. ;-) Nach langem vergeblichen Suchen in den Linux-Howtos wußte google einen Weg zur passenden Information. Mein Firewallbuch lag gestern unerreichbar zuhause.
Rico
On Fri, Jan 04, 2002 at 05:31:23PM +0100, Rico Koerner wrote:
Jaja nicht nur E.T. will nach Hause telefonieren. Von HP-Printservern hab ich dieses Verhalten auch schon erlebt. :-(
Ist bekannt, wozu diese Treiber/Drucker nach Hause telefonieren?
Danke an Konrad für's abschreiben der ICMP-Type-Liste. ;-) Nach langem vergeblichen Suchen in den Linux-Howtos wußte google einen Weg zur passenden Information. Mein Firewallbuch lag gestern unerreichbar zuhause.
Warum in die Ferne schweifen? Aus /usr/include/netinet/ip_icmp.h
/* * Definition of type and code field values. */ #define ICMP_ECHOREPLY 0 /* echo reply */ #define ICMP_UNREACH 3 /* dest unreachable, codes: */ #define ICMP_UNREACH_NET 0 /* bad net */ #define ICMP_UNREACH_HOST 1 /* bad host */ #define ICMP_UNREACH_PROTOCOL 2 /* bad protocol */ #define ICMP_UNREACH_PORT 3 /* bad port */ #define ICMP_UNREACH_NEEDFRAG 4 /* IP_DF caused drop */ #define ICMP_UNREACH_SRCFAIL 5 /* src route failed */ #define ICMP_SOURCEQUENCH 4 /* packet lost, slow down */ ...
Reinhard
Reinhard Foerster wrote:
Warum in die Ferne schweifen? Aus /usr/include/netinet/ip_icmp.h
Als C-unkundiger für mich nicht so naheliegend.
/*
- Definition of type and code field values.
*/ #define ICMP_ECHOREPLY 0 /* echo reply */ #define ICMP_UNREACH 3 /* dest unreachable, codes: */ #define ICMP_UNREACH_NET 0 /* bad net */ #define ICMP_UNREACH_HOST 1 /* bad host */ #define ICMP_UNREACH_PROTOCOL 2 /* bad protocol */ #define ICMP_UNREACH_PORT 3 /* bad port */ #define ICMP_UNREACH_NEEDFRAG 4 /* IP_DF caused drop */ #define ICMP_UNREACH_SRCFAIL 5 /* src route failed */ #define ICMP_SOURCEQUENCH 4 /* packet lost, slow down */ ...
Zumindest diese Zeilen hier machen mich auch nicht schlauer. Aber ich glaube die nachfolgenden könnten interessanter werden. ;-)
Rico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 03 January 2002 20:17, Rico Koerner wrote:
die Firewall (iptables) hat mir folgendes Paket rausgefischt:
Jan 3 16:30:36 intranet kernel: DROP-ICMP IN= OUT=eth0 SRC=192.168.20.1 DST=192.168.20.88 LEN=56 TOS=0x00 PREC=0xC0 TTL=255 ID=34583 DF PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.20.88 DST=207.26.131.137 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=15380 PROTO=ICMP TYPE=8 CODE=0 ID=768 SEQ=32569 ]
[cut]
C läßt sich nicht anpingen und der Name ist auch nicht auflösbar.
Kann mir jemand sagen, was die Ursache sein kann?
Wenn ich das richtig interpretiere hat der LapTop ein Ping (Type=8) losgeschickt, irgendwann hat die TTL(*) des Pakets 0 erreicht und es wurde eine Fehlermeldung erzeugt (Type=11, time exceeded). Pruef mal mit traceroute, wie weit C von Dir entfernt ist. Default TTL bei Linux ist 30.
(*) TTL=Time To Live: dieser Wert wird mit einer Zahl (meist 30 oder 255) initialisiert und bei jedem Router eins runtergezaehlt. Wenn er 0 erreicht wird davon ausgegangen, dass das Paket in einer Endlosschleife haengt und das Paket wird verworfen, ausser bei ICMP Type 11 Nachrichten wird dann eine ICMP-Fehlermeldung erzeugt (Type 11, s.o.) - bei ICMP 11 nicht, weil man sonst nix gekonnt haette.
Kleine Uebersicht ueber ICMP (Quelle: W.R.Stevens "TCP/IP Illustrated", vol. 1 "The Protocols"):
ICMP type Bedeutung 0 ping reply 3 destination unreachable (warum steht im ICMP code) 4 source quench (flow control) 5 redirect (router error) 8 ping request 9 router advertisement 10 router solicitation 11 time exceeded, TTL reached 0 (code=0: while in transit, code=1: while reassembling) 12 parameter problem (code=0: IP Header bad; code=1: IP Option missing) 13 timestamp request 14 timestamp reply 15/16 information request/reply (obsolete) 17 address mask request 18 address mask reply
Konrad
- -- Death, when unnecessary, is a tragic thing. -- Flint, "Requiem for Methuselah", stardate 5843.7
lug-dd@mailman.schlittermann.de
-
konrad.rosenbaum＠t-online.de -
Reinhard Foerster -
Rico Koerner -
Tobias Koenig