mboost-dp1
Martian source?
Hej med jer
Jeg koerer logcheck paa min linux-server i paranoia-mode. Det plejer ikke at give saa mange mail-notifikationer, men da jeg i dag tjekkede mail havde jeg over 60 nye mails i min indbakke fra logcheck. Alle har de noget at goere med 'Martian source'. Jeg har googlet begrebet, men er ikke helt sikker paa hvad det er, og om jeg evt. kan ignorere advarslerne.
Her er en log-snippet:
eth0 er mit lokal-net interface, men mit lokalnet er 192.168.0.0/24. Der maa vaere en eller flere computere paa mit netvaerk der opfoerer sig underligt (en virus?)
Er der nogen (kasperd) der kan forklare hvad man boer goere?
Jeg koerer logcheck paa min linux-server i paranoia-mode. Det plejer ikke at give saa mange mail-notifikationer, men da jeg i dag tjekkede mail havde jeg over 60 nye mails i min indbakke fra logcheck. Alle har de noget at goere med 'Martian source'. Jeg har googlet begrebet, men er ikke helt sikker paa hvad det er, og om jeg evt. kan ignorere advarslerne.
Her er en log-snippet:
Dec 18 16:25:14 rtr kernel: [21080.921928] martian source 192.168.2.255 from 192.168.2.197, on dev eth0
Dec 18 16:25:14 rtr kernel: [21080.921934] ll header: ff:ff:ff:ff:ff:ff:00:21:5d:a5:68:02:08:00
Dec 18 16:25:14 rtr kernel: [21080.922449] martian source 255.255.255.255 from 192.168.2.197, on dev eth0
Dec 18 16:25:14 rtr kernel: [21080.922454] ll header: ff:ff:ff:ff:ff:ff:00:21:5d:a5:68:02:08:00
Dec 18 16:25:42 rtr kernel: [21108.221506] martian source 192.168.2.197 from 192.168.2.1, on dev eth0
Dec 18 16:25:42 rtr kernel: [21108.221512] ll header: ff:ff:ff:ff:ff:ff:00:18:e7:e1:3e:88:08:06
eth0 er mit lokal-net interface, men mit lokalnet er 192.168.0.0/24. Der maa vaere en eller flere computere paa mit netvaerk der opfoerer sig underligt (en virus?)
Er der nogen (kasperd) der kan forklare hvad man boer goere?
Tukanfan (1) skrev:Jeg har googlet begrebet, men er ikke helt sikker paa hvad det er [...]
http://en.wikipedia.org/wiki/Martian_packet
http://freesoft.org/CIE/RFC/1812/123.htm
Tukanfan (1) skrev:[...] og om jeg evt. kan ignorere advarslerne.
http://en.wikipedia.org/wiki/Martian_packet skrev:Martian packets commonly arise from IP address spoofing in denial-of-service attacks, but can also arise from network equipment malfunction or misconfiguration of a host.
Øh, incoming/outgoing source/destination. Take your pick. Jeg kender ikke strukturen af din logfil. (Noobmode: Det kan da også være, at 192.168.2.197 forsøger at broadcaste på 192.168.2.255 eller noget.)
Kasper, hvor er du?!
P.S.
Jeg kom bare for informativ-ratingen.
Kasper, hvor er du?!
P.S.
Jeg kom bare for informativ-ratingen.
Dette er to pakker sendt fra 192.168.2.197 til broadcast adressen på det pågældende netsegment. Der sendes en pakke til 192.168.2.255 som er broadcast adressen for segmentet 192.168.2.0/24 og en anden pakke til 255.255.255.255 som er broadcast pakken for et vilkårligt segment. Jeg brugte http://lxr.linux.no/#linux+v3.1.5/net/ipv4/route.c... for at finde ud af rækkefølgen på adresserne i loggen.Tukanfan (1) skrev:Dec 18 16:25:14 rtr kernel: [21080.921928] martian source 192.168.2.255 from 192.168.2.197, on dev eth0
Dec 18 16:25:14 rtr kernel: [21080.921934] ll header: ff:ff:ff:ff:ff:ff:00:21:5d:a5:68:02:08:00
Dec 18 16:25:14 rtr kernel: [21080.922449] martian source 255.255.255.255 from 192.168.2.197, on dev eth0
Dec 18 16:25:14 rtr kernel: [21080.922454] ll header: ff:ff:ff:ff:ff:ff:00:21:5d:a5:68:02:08:00
Hvis vi så kigger på link-level headeren, så ser vi at destinationen er ff:ff:ff:ff:ff:ff, hvilket er Ethernet broadcast adressen. Det stemmer godt nok overens med destinations IP adresserne.
Afsenderadressen er 00:21:5d:a5:68:02. De første tre bytes af MAC adressen indikerer producenten. Ifølge http://standards.ieee.org/develop/regauth/oui/oui.... er 00215D tildelt Intel, så pakken bliver sendt fra et Intel netkort.
08:00 indikerer at det er en IPv4 pakke.
Rækkefølgen på felterne i link-level headeren fandt jeg frem til ved at kigge på et netværksdump med wireshark.
Dette er højst sandsynligt en enhed, der forsøger at besvare en af de ovenstående pakker. Den bliver sendt fra 192.168.2.1, og destinationen er 192.168.2.197 som sendte de to pakker overnfor.Tukanfan (1) skrev:Dec 18 16:25:42 rtr kernel: [21108.221506] martian source 192.168.2.197 from 192.168.2.1, on dev eth0
Dec 18 16:25:42 rtr kernel: [21108.221512] ll header: ff:ff:ff:ff:ff:ff:00:18:e7:e1:3e:88:08:06
Når vi kigger på link-level headeren kan vi se at denne også er sendt til Ethernet broadcast adressen ff:ff:ff:ff:ff:ff, og at den er sendt fra 00:18:e7:e1:3e:88. 0018E7 tilhører Cameo Communications. Det firma har jeg ikke hørt om før, men de har åbenbart lavet et netkort som findes på dit lokalnet.
08:06 betyder at det er en ARP pakke. Der er ganske enkelt tale om at 192.168.2.1 sender en broadcast pakke ud for at finde MAC adressen hørende til 192.168.2.197.
Vi kan nok godt gå ud fra at der bliver udvekslet flere pakker mellem de to enheder. Men de efterfølgende pakker bliver ikke sendt til Ethernet broadcast adressen, men derimod til en specifik MAC adresse, derfor ser serveren ikke resten af pakkerne imellem de to enheder.
Så er det klart at serveren ikke vil kendes ved pakker hørende til segmentet 192.168.2.0/24. Der er intet der forhindrer at man kører to forskellige IP segmenter på samme fysiske Ethernet segment. Man skal bare sørge for at man ved man gør, når man sætter sådan noget op.Tukanfan (1) skrev:eth0 er mit lokal-net interface, men mit lokalnet er 192.168.0.0/24.
Det vi kan se er at der er to enheder på netværket, som er enige om, at der bruges 192.168.2.0/24 på dette Ethernet segment.Tukanfan (1) skrev:Der maa vaere en eller flere computere paa mit netvaerk der opfoerer sig underligt (en virus?)
Et realistisk gæt er at 192.168.2.1 er en router med indbygget DHCP server, og 192.168.2.197 er en DHCP klient, som har fået sin IP adresse tildelt af førnævnte DHCP server.
Hvis du kører en tcpdump gennem længere tid burde du se noget DHCP trafik, hvis ovenstående gæt er rigtigt.
For det første find ud af hvilke enheder på dit netværk der har MAC adresserne 00:21:5d:a5:68:02 og 00:18:e7:e1:3e:88. Og kør tcpdump for at få flere oplysninger om trafikken.Tukanfan (1) skrev:Er der nogen (kasperd) der kan forklare hvad man boer goere?
Mit umiddelbare bud på en brugbar tcpdump kommando er:
tcpdump -ni eth0 -s0 -Uw /tmp/whatever 'arp||icmp||port 67||port 68'
Jeg har lige et par idéer mere.
For det første er en oplagt fejl man kan begå i opsætningen af sit netværk at tage en trådløs router og bruge som access point uden at slå DHCP serveren fra.
Hvis man har en trådløs router som man ikke har brug for at anvende som router, men gerne vil bruge som access point, så kan man forbinde en af LAN portene på denne router til sit lokalnet og lade denne trådløse routers WAN port være ubrugt.
Hvis man gør det skal man huske at slå DHCP serveren i routeren fra, da man ellers risikerer at der er enheder der får IP adresser fra denne DHCP server og dermed også bruger den trådløse router som default gateway, selvom den ikke har forbindelse til Internettet.
Dette kunne forklare hvad du ser.
Når man slår DHCP serveren i sådan en router fra er det en god idé at notere sig hvilken IP adresse routeren har, for næste gang man har brug for at konfigurere routeren er man nødt til at sætte en IP adresse op manuelt på en computer for at kunne forbinde til routerens konfiguration.
Hvis du gerne vil finde ud af om du har en DHCP server, der ikke burde være der, så kan du tage en seperat computer (laptop) og starte tcpdump på et netværksinterface og når tcpdump er startet forbinder du så det netværksinterface til netværket.
På den måde kan tcpdump vise dig hvad der sker når computeren bliver forbundet. Sørg for at computeren kører en DHCP klient således at du ser om der er en DHCP server på netværket, og hvad den svarer.
Hvis der er flere DHCP servere på netværket er det ikke sikkert at du ser mere end et svar. Det er muligt at nogle DHCP servere venter lidt for at se om der var andre der svarede, på den måde kan nogle DHCP servere være helt usynlige indtil du har fjernet den der svarer hurtigere.
Hvis du har en DHCP server som svarer for 192.168.0.0/24 kan du evt. finde ud af om du også har en DHCP server som svarer for 192.168.2.0/24 på følgende måde:
Rediger DHCP klientens gemte leases således at når DHCP klienten startes vil den se en gammel adresse fra 192.168.2.0/24 og først spørge efter denne. Når computeren forbindes til netværket og spørger efter en adresse fra 192.168.2.0/24 vil DHCP serveren for 192.168.0.0/24 ikke svare, men DHCP serveren for 192.168.2.0/24 vil svare.
Hvis du overhovedet ikke kan få et DHCP svar for 192.168.2.0/24 er der sandsynligvis noget mere mærkeligt galt med netværksopsætningen. Du kan midlertidigt prøve at konfigurere en computer med en statisk IP adresse i 192.168.2.0/24 og undersøge om du kan kommunikere med 192.168.2.1 eller 192.168.2.197. Hvis 192.168.2.1 er et trådløst access point er der en vis sandsynlighed for at den har et konfigurationsinterface på http://192.168.2.1/
Så snart en computer er konfigureret med en statisk IP adresse i 192.168.2.0/24 kan du afprøve ovenstående URL. Jeg gætter på der har været en DHCP server der er startet fra 192.168.2.200 og er gået nedad derfra og er nået til 192.168.2.197, så sandsynligvis er 192.168.2.201-192.168.2.254 tilgængelige for manuel tildeling.
For det første er en oplagt fejl man kan begå i opsætningen af sit netværk at tage en trådløs router og bruge som access point uden at slå DHCP serveren fra.
Hvis man har en trådløs router som man ikke har brug for at anvende som router, men gerne vil bruge som access point, så kan man forbinde en af LAN portene på denne router til sit lokalnet og lade denne trådløse routers WAN port være ubrugt.
Hvis man gør det skal man huske at slå DHCP serveren i routeren fra, da man ellers risikerer at der er enheder der får IP adresser fra denne DHCP server og dermed også bruger den trådløse router som default gateway, selvom den ikke har forbindelse til Internettet.
Dette kunne forklare hvad du ser.
Når man slår DHCP serveren i sådan en router fra er det en god idé at notere sig hvilken IP adresse routeren har, for næste gang man har brug for at konfigurere routeren er man nødt til at sætte en IP adresse op manuelt på en computer for at kunne forbinde til routerens konfiguration.
Hvis du gerne vil finde ud af om du har en DHCP server, der ikke burde være der, så kan du tage en seperat computer (laptop) og starte tcpdump på et netværksinterface og når tcpdump er startet forbinder du så det netværksinterface til netværket.
På den måde kan tcpdump vise dig hvad der sker når computeren bliver forbundet. Sørg for at computeren kører en DHCP klient således at du ser om der er en DHCP server på netværket, og hvad den svarer.
Hvis der er flere DHCP servere på netværket er det ikke sikkert at du ser mere end et svar. Det er muligt at nogle DHCP servere venter lidt for at se om der var andre der svarede, på den måde kan nogle DHCP servere være helt usynlige indtil du har fjernet den der svarer hurtigere.
Hvis du har en DHCP server som svarer for 192.168.0.0/24 kan du evt. finde ud af om du også har en DHCP server som svarer for 192.168.2.0/24 på følgende måde:
Rediger DHCP klientens gemte leases således at når DHCP klienten startes vil den se en gammel adresse fra 192.168.2.0/24 og først spørge efter denne. Når computeren forbindes til netværket og spørger efter en adresse fra 192.168.2.0/24 vil DHCP serveren for 192.168.0.0/24 ikke svare, men DHCP serveren for 192.168.2.0/24 vil svare.
Hvis du overhovedet ikke kan få et DHCP svar for 192.168.2.0/24 er der sandsynligvis noget mere mærkeligt galt med netværksopsætningen. Du kan midlertidigt prøve at konfigurere en computer med en statisk IP adresse i 192.168.2.0/24 og undersøge om du kan kommunikere med 192.168.2.1 eller 192.168.2.197. Hvis 192.168.2.1 er et trådløst access point er der en vis sandsynlighed for at den har et konfigurationsinterface på http://192.168.2.1/
Så snart en computer er konfigureret med en statisk IP adresse i 192.168.2.0/24 kan du afprøve ovenstående URL. Jeg gætter på der har været en DHCP server der er startet fra 192.168.2.200 og er gået nedad derfra og er nået til 192.168.2.197, så sandsynligvis er 192.168.2.201-192.168.2.254 tilgængelige for manuel tildeling.
Saa blev man igen klogere, tak for det.
Og problemet var rigtig nok en router med indbygget dhcp-server. Jeg havde et par dage forinden ville aendre lidt paa netvaerkstopologien, og aktiverede i den forbindelse dhcp-serveren. Saa fortroed jeg imidlertid, men lod bare vaere med at genstarte routeren, da aendringerne saa ikke ville tage effekt. Imidlertid kom der stroemafbrydelse, og dhcp-serveren blev aktiveret.
Saa jeg faar ikke saa mange mails mere - specielt efter at de enheder, der fejlagtigt fik en 192.168.2.x addresse, efterhaanden har mistet dem.
Til gengaeld har jeg opdaget en ny 'underlig' martian source:
MAC-addressen har jeg, takket vaere linket i #6, bestemt til at tilhoere Sony-Ericsson enhed, hvilket tyder paa en mobiltelefon (der er en Xperia Mini Pro i huset). Det undrer mig dog at den har den ip-addresse den har (enheden er svjv. ikke manuelt konfigureret, det er ikke zeroconf, og der er ingen dhcp-servere der er ansvarlige for 10.0.0.0/8 eller brudstykker heraf). Den proever tilsyneladende ogsaa at kontakte en eller anden addresse ude paa internettet fra denne maerkelige addresse.
Og problemet var rigtig nok en router med indbygget dhcp-server. Jeg havde et par dage forinden ville aendre lidt paa netvaerkstopologien, og aktiverede i den forbindelse dhcp-serveren. Saa fortroed jeg imidlertid, men lod bare vaere med at genstarte routeren, da aendringerne saa ikke ville tage effekt. Imidlertid kom der stroemafbrydelse, og dhcp-serveren blev aktiveret.
Saa jeg faar ikke saa mange mails mere - specielt efter at de enheder, der fejlagtigt fik en 192.168.2.x addresse, efterhaanden har mistet dem.
Til gengaeld har jeg opdaget en ny 'underlig' martian source:
Dec 20 22:46:21 rtr kernel: [216747.252589] martian source 192.168.0.1 from 10.180.62.99, on dev eth0
Dec 20 22:46:21 rtr kernel: [216747.252596] ll header: ff:ff:ff:ff:ff:ff:6c:23:b9:83:8a:7b:08:06
Dec 20 22:46:49 rtr kernel: [216775.382697] martian source 173.194.70.188 from 10.180.62.99, on dev eth0
Dec 20 22:46:49 rtr kernel: [216775.382704] ll header: 00:01:c0:07:cd:98:6c:23:b9:83:8a:7b:08:00
MAC-addressen har jeg, takket vaere linket i #6, bestemt til at tilhoere Sony-Ericsson enhed, hvilket tyder paa en mobiltelefon (der er en Xperia Mini Pro i huset). Det undrer mig dog at den har den ip-addresse den har (enheden er svjv. ikke manuelt konfigureret, det er ikke zeroconf, og der er ingen dhcp-servere der er ansvarlige for 10.0.0.0/8 eller brudstykker heraf). Den proever tilsyneladende ogsaa at kontakte en eller anden addresse ude paa internettet fra denne maerkelige addresse.
Det er der måske alligevel uden du er klar over det. Du siger at det tyder på der er tale om en mobiltelefon. 10.180.62.99 kan være en IP adresse som er tildelt af mobilnettet.Tukanfan (8) skrev:der er ingen dhcp-servere der er ansvarlige for 10.0.0.0/8 eller brudstykker heraf
173.194.70.188 er en IP adresse i et Google datacenter, sandsynligvis er det en Android telefon, de har typisk en del klientsoftware, der kommunikerer med Google.
Når en klient åbner en TCP forbindelse vælges IP adressen når forbindelsen åbnes. Denne IP adresse forbliver fast i hele TCP forbindelsens levetid.
Der kan være en TCP forbindelse, der er blevet åbnet på et tidspunkt hvor telefonen brugte data over mobilnettet. Når telefonen så skifter til at bruge WIFI vil TCP forbindelsen fortsat bruge samme IP adresse.
Det der så burde være sket er at TCP pakkerne sendes over din WIFI forbindelse fra mobiltelefonen til Google, og svar fra Google sendes over mobilnettet tilbage til din mobiltelefon.
Der er tre ting som kan ødelægge det, så den TCP forbindelse ikke virker.
1. Det kan være din mobiludbyder bruger NAT, og i det pakkerne begynder at gå over det andet netværk kommer de ikke længere gennem den NAT enhed, der kender den tilhørende tilstand.
2. Det kan være at din WIFI forbindelse bruger NAT og begynder på at lave NAT midt i en TCP forbindelse fordi den på det tidspunkt begynder at gå over din WIFI forbindelse.
3. Der kan være et filter et sted mellem WIFI access pointet og Google, som filtrerer pakker på deres source adresse, således at de ikke længere når frem til Google, fordi de kommer ad en anden rute end forventet.
Udfra de tilgængelige oplysninger antager jeg at alle tre ovenstående problemer er til stede, og den TCP forbindelse har ikke en chance for at overføre mere data. Der vil forekomme et timeout og derefter vil klienten sandsynligvis prøve igen med en ny TCP forbindelse. Og denne gang vil den formodentlig få en TCP forbindelse over WIFI, der vil fungere så længe den har WIFI forbindelse til access pointet.
Jeg går ud fra din server fungerer som gateway mellem dit WIFI access point og Internettet. Og den logger når den modtager en pakke med uventet IP adresse og smider den væk.
Mener du http://newz.dk/~conar? Den har tilsyneladende ingen indlæg skrevet de sidste 2 måneder. Til gengæld er dens seneste indlæg fra 12. december 2011. Det ligner en bug.Chewy (11) skrev:Jeg troede at vi skulle til at have en klassiske Conar tråd
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Support
Gå til bund