Fwd: Welcher Dienst verursacht martian source?
Hallo liebe Listenleser,
ich versuche es nochmal, da wahrscheinlich meine letzte Mail irgendwie
untergegangen zu sein scheint:
Nachdem ich fleißig gegoogelt habe, insbesondere über die Archive der
SuSE Listen, habe ich auch keine befriedigende Erklärung auf folgendes
Problem bekommen:
Im Logfile /var/log/messages taucht immer wieder der Eintrag
Mar 25 14:25:18 anton kernel: martian source 123.123.123.123 from
127.0.0.1, on dev eth0
Mar 25 14:25:18 anton kernel: ll header:
00:02:b3:cd:89:72:00:04:dd:56:12:c2:08:00
auf. Ich weiß mittlerweile was das ist und wie ich es abstellen kann,
aber ich möchte zu gern wissen, wer der Verursacher ist! Deshalb habe
ich mal tcpdump bemüht und folgende Meldung zur gleichen Zeit bekommen:
14:25:18.060280 localhost.http > anton.example.com.1177: R 0:0(0) ack 690
814977 win 0
Ich kann mir nicht vorstellen, dass der Apache dafür verantwortlich ist.
Auf dem Rechner läuft SuSE 8.2 mit SuSEFirewall2 und snort. (Der
Rechnername und die Domain wurden geändert.)
Kann mir jemand ein paar Tipps geben, wie man den Verursacher
herausfinden kann?
Besten Dank im voraus!
Gruß,
Steffen.
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
suse-linux-unsubscribe@suse.com
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: suse-linux-help@suse.com
-------------------------------------------------------
--
Steffen Petter
Am Montag, 29. März 2004 10:17 schrieb Steffen Petter:
Hallo liebe Listenleser,
ich versuche es nochmal, da wahrscheinlich meine letzte Mail irgendwie untergegangen zu sein scheint:
Nachdem ich fleißig gegoogelt habe, insbesondere über die Archive der SuSE Listen, habe ich auch keine befriedigende Erklärung auf folgendes Problem bekommen: [...martian source...]
Gib mal bei Google: die Suchbegriffe: linux mailingliste martian source ein. Da findest du ausreichend Material für weitere Recherchen. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-Hoehne@t-online.de / _____________________________________/
* Steffen Petter postete am 29. Mär. 2004 folgendes:
Nachdem ich fleißig gegoogelt habe, insbesondere über die Archive der SuSE Listen, habe ich auch keine befriedigende Erklärung auf folgendes Problem bekommen:
Also ich weise bei mir IPTABLES mit for i in /proc/sys/net/ipv4/conf/*; do \ echo 0 > $i/log_martians 2> /dev/null; done an, das die ausserirdischen Aktivitäten nicht geloggt werden. ;) Bye Michael -- Sie: Wir brauchen eine neue Ausrede. Er: Wieso, glauben sie den Netzwerkausfall nicht mehr? Sie: Nein, wir installieren bald Linux. -- IBM Werbespot _______________________________________________________________________ http://macbyte.info/ ICQ #151172379 http://autohbci.macbyte.info/
Am Mo, den 29.03.2004 schrieb Michael Raab um 10:28:
* Steffen Petter postete am 29. Mär. 2004 folgendes:
Nachdem ich fleißig gegoogelt habe, insbesondere über die Archive der SuSE Listen, habe ich auch keine befriedigende Erklärung auf folgendes Problem bekommen:
Also ich weise bei mir IPTABLES mit
for i in /proc/sys/net/ipv4/conf/*; do \ echo 0 > $i/log_martians 2> /dev/null; done
an, das die ausserirdischen Aktivitäten nicht geloggt werden. ;)
Es wäre sehr sinnvoll, herauszufinden, /warum/ martians an deinem System ankommen. Es handelt sich dabei um Datenpakete, die an diesem Interface nix zu suchen haben, und bei einer Firewall ist es durchaus interessant, warum, z.B. externe IP-Pakete am internen Netzwerk rumgeistern. Vermutlich ist es nichtmal eine Attacke, sondern eine Fehlkonfiguration. Ich hatte die auch mal, und es zeigte sich, daß es keine gute Idee war, einen externen Router und interne Geräte an den gleichen Switch zu hängen. Das habe ich aber erst erfahren, als ich den Martians auf den Grund ging. Gruß, Ratti
Hallo auch, Am Montag, 29. März 2004 12:06 schrieb Joerg Rossdeutscher:
Ich hatte die auch mal, und es zeigte sich, daß es keine gute Idee war, einen externen Router und interne Geräte an den gleichen Switch zu hängen. Das habe ich aber erst erfahren, als ich den Martians auf den Grund ging.
Davon abgesehen, das ich mit dir darin übereinstimme, das es bestimmt keine schlechte Idee ist, dem Martian-Source auf den Grund zu gehen, würde mich interessieren, worin du das Problem siehst, interne und externe Geräte an einem Switch zu haben? Hab ich hier überall, dafür gibt es ja VLANs. Hast du da irgendwelche bestimmten schlechten Erfahrungen? Bernd -- [Zufallssig 3] Und dann war da noch der junge Mann, der unbedingt Schriftsteller werden wollte. Er wollte Emotionen wecken und die Leute zum Weinen bringen. Sein Traum wurde wahr, er verfaßt heute die Fehlermeldungen bei Microsoft.
Moin, Am Mo, den 29.03.2004 schrieb Bernd Tannenbaum um 12:17:
Davon abgesehen, das ich mit dir darin übereinstimme, das es bestimmt keine schlechte Idee ist, dem Martian-Source auf den Grund zu gehen, würde mich interessieren, worin du das Problem siehst, interne und externe Geräte an einem Switch zu haben? Hab ich hier überall, dafür gibt es ja VLANs. Hast du da irgendwelche bestimmten schlechten Erfahrungen?
Ich verwende shorewall als Firewall, un dort wird im FAQ dringendst davon abgeraten. Das ist mir Autorität genug. Inzwischen habe ich dahingehend umgestellt, daß auf dem Switch nur noch das Interne Netzwerk läuft, während unsere externen Adressen physikalisch getrennt an einem popeligen Hub hängen, und meine Martians sind inzwischen weg. Gruß, Ratti
Am Montag, 29. März 2004 12:06 schrieb Joerg Rossdeutscher:
Am Mo, den 29.03.2004 schrieb Michael Raab um 10:28:
* Steffen Petter postete am 29. Mär. 2004 folgendes:
Nachdem ich fleißig gegoogelt habe, insbesondere über die Archive der SuSE Listen, habe ich auch keine befriedigende Erklärung auf folgendes Problem bekommen:
Also ich weise bei mir IPTABLES mit
for i in /proc/sys/net/ipv4/conf/*; do \ echo 0 > $i/log_martians 2> /dev/null; done
an, das die ausserirdischen Aktivitäten nicht geloggt werden. ;)
Es wäre sehr sinnvoll, herauszufinden, /warum/ martians an deinem System ankommen. Es handelt sich dabei um Datenpakete, die an diesem Interface nix zu suchen haben, und bei einer Firewall ist es durchaus interessant, warum, z.B. externe IP-Pakete am internen Netzwerk rumgeistern. Vermutlich ist es nichtmal eine Attacke, sondern eine Fehlkonfiguration.
Erstmal Dank für die Antworten aber die Ratschläge wie ich die Fehlermeldungen abstelle bringen mich auf der Suche nach der Ursache nicht weiter. Die Fehlermeldung: Mar 25 14:25:18 anton kernel: martian source 123.123.123.123 from 127.0.0.1, on dev eth0 Mar 25 14:25:18 anton kernel: ll header: 00:02:b3:cd:89:72:00:04:dd:56:12:c2:08:00 hat, meiner Meinug nach, nichts mit der SuSEFirewall2 zu tun. Die IP-Adresse (hier nur eine Beispiel IP) 123.123.123.123 ist die des betreffenden Rechners selbst. Er schickt sich also selbst Pakete (bzw. mit eigener IP-Adresse als Absender). Mit tcpdump habe ich schon einen Anhaltspunkt, wie in der Ursprungsmail beschrieben, entdeckt. Man beachte die gleiche Urzeit: 14:25:18.060280 localhost.http > anton.example.com.1177: R 0:0(0) ack 690 814977 win 0 Die Angabe anton.example.com ist nur ein Ersatz für den eigenen Rechner. Da es nicht der lokale Apache sein kann, der die Pakete herumschickt, war ich nun auf der Suche nach geeigneten Eingrenzungsmethoden. Also noch einmal die Frage: Wie kann ich herausfinden welcher Dienst bzw. Software oder Fehlkonfiguration die Fehlermeldung verursacht? Mit welchen Optionen könnte ich tcpdump oder ethereal bemühen? Noch einmal: Ich will die Protokollierung dieser Fehlermeldung nicht abschalten! (Die SuSEFirewall2 läuft nur zum Schutz des eigenen Rechners und nicht für ein internes Netz. Demzufolge handelt es sich nicht um einen Router, Gateway oder dergleichen.) Folgende Dienste laufen auf dem Rechner: * Apache 1.3.* * Postfix * mysql * USV-Dämon * antivir * SuSEFirewall2 * snort Grüße, Steffen.
Am Di, den 30.03.2004 schrieb Steffen Petter um 21:51:
Mar 25 14:25:18 anton kernel: martian source 123.123.123.123 from 127.0.0.1, on dev eth0 Mar 25 14:25:18 anton kernel: ll header: 00:02:b3:cd:89:72:00:04:dd:56:12:c2:08:00
Verrat doch mal, welche interfaces du überhaupt in der Kiste drin hast - inclusive ippp, ppp, eth-aliases etc... Und dann sag doch mal, wie sie verdrahtet ist (Hub, switch, DSL-Modem am gleichen Hub wie Ethernet etc...) Gruß, Ratti P.S.: Wenn du Beispiel-Namen für deinen Rechner angibst, verwende bitte ungültige Domains wie example.foo, damit der Betreiber der gleichnamigen com-Domain nicht mit irgendwas behelligt wird. :-) -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Am Mittwoch, 31. März 2004 11:34 schrieb Joerg Rossdeutscher:
Am Di, den 30.03.2004 schrieb Steffen Petter um 21:51:
Mar 25 14:25:18 anton kernel: martian source 123.123.123.123 from 127.0.0.1, on dev eth0 Mar 25 14:25:18 anton kernel: ll header: 00:02:b3:cd:89:72:00:04:dd:56:12:c2:08:00
Verrat doch mal, welche interfaces du überhaupt in der Kiste drin hast - inclusive ippp, ppp, eth-aliases etc... Und dann sag doch mal, wie sie verdrahtet ist (Hub, switch, DSL-Modem am gleichen Hub wie Ethernet etc...)
An eth0 ist eine 100MBit Netzwerkkarte. Die zweite Netzwerkkarte ist nicht eingebunden. Es gibt keine ippp oder pppp! Der Rechner ist über eth0 direkt mit dem UNI-Netz und damit auch direkt mit dem Internet verbunden. ifconfig gibt folgende Ausgabe: eth0 Link encap:Ethernet HWaddr 00:02:B3:CD:89:72 inet addr:123.123.123.123 Bcast:123.123.123.255 Mask:255.255.255.0 inet6 addr: fe80::202:b3ff:fecd:8972/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:19220328 errors:0 dropped:0 overruns:0 frame:0 TX packets:4014871 errors:0 dropped:0 overruns:0 carrier:0 collisions:319030 txqueuelen:100 RX bytes:3821230945 (3644.2 Mb) TX bytes:1226026464 (1169.2 Mb) Interrupt:10 Base address:0xdce0 Memory:fcbff000-fcbff038 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:50247 errors:0 dropped:0 overruns:0 frame:0 TX packets:50247 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:39864153 (38.0 Mb) TX bytes:39864153 (38.0 Mb) Gruß, Steffen.
participants (5)
-
Bernd Tannenbaum -
Joerg Rossdeutscher -
Michael Hoehne -
Michael Raab -
Steffen Petter