> Could anyone tell me what is this message is or indicated...?..? > > Jan 11 10:45:28 dns2 kernel: martian source dd9f89c6 for 019f89c6, dev eth1 > Jan 11 10:45:28 dns2 kernel: ll header: ff ff ff ff ff ff 00 60 08 94 59 4c > 08 06 > net/ipv4/route.c >> martian_source: >> #ifdef CONFIG_IP_ROUTE_VERBOSE >> if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) { >> /* >> * RFC1812 recommenadtion, if source is martian, >> * the only hint is MAC header. >> */ >> printk(KERN_WARNING "martian source %08x for %08x, dev %s\n", sa >> ddr, daddr, dev->name); >> if (dev->hard_header_len) { >> int i; >> unsigned char *p = skb->mac.raw; >> printk(KERN_WARNING "ll header:"); >> for (i=0; ihard_header_len; i++, p++) >> printk(" %02x", *p); >> printk("\n"); >> } >> } >> #endif look at RFC1812 maybe? proc/sys/net/ipv4/conf >> log_martians >> Log packets with source addresses with no known route to kernel log. Documentation: >> CONFIG_IP_ROUTE_VERBOSE >> If you say Y here, which is recommended, then the kernel will print >> verbose messages regarding the routing, for example warnings about >> received packets which look strange and could be evidence of an >> attack or a misconfigured system somewhere. The information is >> handled by the klogd daemon which is responsible for kernel messages >> ("man klogd"). martian packets are simply ones the kernel can _easily_ tell are spoofed or otherwise incorrect. You'll notice the first one has the source set to the local-net broadcast address -- obviously an incorrect packet. (When devices are attempting to discover their IP address, they use a source address of zeros and send _to_ the local-net broadcast address.) The second packet has a source address set to the IP address of the network interface that received the packet -- obviously an incorrect packet. I'd classify these as "mostly harmless" -- if you have security problems that are remotely exploitable, chances are good the attacker already knows about them. If you don't have any remotely exploitable security problems, these are really nothing to be afraid of. There isn't a lot you can do, aside from trace the linklevel header (reporting ethernet MAC pairs of source and destination, I don't recall in which order) and find the machine that is injecting these bad packets onto the network. It means there are some bogus packets floating around your network.. Are you doing any tricky ARP stuff? Of course, it could also be my stupid bloody WindoZe box trying to spray port 137 & 138 messages advertising its shares out into the net proper. {sigh} > Martians are incorrectly routed packets, usually spoofed. I doubt you will > be able to trace them regardless. Well, its coming on eth1, an internal interface.. its probably a local machine and should be traceable. Unlikely to be spoofed in this case either if you look at the IP address. > > How do I tell which machine they are coming from given the > > following type > > of message? > > > > Jul 21 18:02:02 ratri kernel: martian source 169.254.255.255 > > from 169.254.9.151, on dev eth1 169.254.* are IP addresses that Windows PCs use when they are configured to use DHCP but for whatever reason fail to get an IP. So you've likely got a Windows PC that came up and couldn't get an IP address. > > Jul 21 18:02:02 ratri kernel: ll header: > > ff:ff:ff:ff:ff:ff:00:06:5b:dc:b4:22:08:00 The source MAC address I believe is 00:06:5b:dc:b4:22, this can be looked up in a list of manufacturers and the MACs assigned to them, such as the one at http://standards.ieee.org/regauth/oui/oui.txt 00-06-5B (hex) Dell Computer Corp. 00065B (base 16) Dell Computer Corp. One Dell Way Round Rock TX 78682 UNITED STATES Thus, if I haven't made some mistake on picking apart the ll header (which I may have, never cared to look before), you are dealing with a Dell PC running Windows that failed to get a DHCP address. If you are concerned with it, you can track it down and kick it. >> > Joerg Henner wrote: >> > [...] Once again, complete: Oct 24 00:00:23 trinity kernel: martian source 255.255.255.255 from 10.225.80.1, on dev eth1 Oct 24 00:00:23 trinity kernel: ll header: ff:ff:ff:ff:ff:ff:00:09:7b:8d:08:54:08:00 > >>>ll header: ff:ff:ff:ff:ff:ff:00:09:7b:8d:08:54:08:00 >> >>> ^^^^^^^^^^^^^^^^^ >> This does not really seem to be a MAC-Adress.. >> http://www.susesecurity.com/faq/ -> see about in the middle for >> Martians... >> I found another link...how about this one? >> >> >> >> >> >> *giggl* - well, i meant that HE has to find the Network-Card with >> the specified MAC-Adress ;)))) >> >> >> > >> > arp arp - n was a good idea... Address HWtype HWaddress Flags Mask Iface 217.162.200.1 ether 00:09:7B:8D:08:54 C eth1 My Net is Class A 10.0.0.0 Subnet is 255.0.0.0 IP 217.162.200.80 -> one IP of my Cablemodem My Server really has 2 Network-Cards: eth0 -> LAN 10.0.0.0/8 eth1 -> WAN 217.162.200.80/Cablemodem eth0 Link encap:Ethernet HWaddr 00:04:5A:65:F8:B7 inet addr:10.0.0.2 Bcast:10.255.255.255 Mask:255.0.0.0 inet6 addr: fe80::204:5aff:fe65:f8b7/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:29371 errors:0 dropped:0 overruns:0 frame:0 TX packets:27561 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:4649259 (4.4 Mb) TX bytes:5552056 (5.2 Mb) Interrupt:5 Base address:0x7000 eth1 Link encap:Ethernet HWaddr 00:00:E8:56:EB:D7 inet addr:217.162.200.80 Bcast:255.255.255.255 Mask:255.255.248.0 inet6 addr: fe80::200:e8ff:fe56:ebd7/10 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2514331 errors:0 dropped:0 overruns:0 frame:0 TX packets:644829 errors:0 dropped:0 overruns:0 carrier:0 collisions:428 txqueuelen:100 RX bytes:181205855 (172.8 Mb) TX bytes:112859445 (107.6 Mb) Interrupt:11 Base address:0x220 2 interfaces are needed for the routing between internet/lan. see ifconfig below. i am nearly sure, that there is a misconfiguration error. >> > >> > Or am I missing something here? >> > >> > Christian > > ok, Roger gave you the link where to read more about. > This is a message from kernel routing. > Please check both lines in /var/log/messages, the first on tells you the > (claimed) source IP and the destination IP and the interface where it > was detected. The second one (see above) contains the MACs from where to > where the packet should be routed. Both should be interfaces on the same > net segment, one belongs probably to the listed interface (eth0). > > What does these messages tell you? > if the (claimed) sorce IP is a valid IP in your LAN, and these messages > are random somehow (well, I need to explain this more detailled ..), > then it's most likely a mis-configured client, for example routing (see > in docs mentioned above). > If the source IP is not valid in your LAN, and you have these messages > in a sequence (for example every 2 seconds, or increasing IP), then it's > most likely that someone scans with spoofed IPs. > > What to do? > If you don't care about the scans (probably 'cause you know that your > firewall is prepared for it:), then you may just ignore these messages. > If you feel that its a mis-configured client, fix it. > You simply may switch of the logging by > > echo 0 >/proc/sys/net/ipv4/conf//log_martians i've done this as normally i trust my firewall.... > > Does this answer you question? > Achim Please try echo 0 >/proc/sys/net/ipv4/conf/eth1/log_martians echo 0 >/proc/sys/net/ipv4/conf/all/log_martians echo 0 >/proc/sys/net/ipv4/conf/default/log_martians > > I've been getting messages about Martian Source since Sunday night, > > I've also been unable to connect. I think it's now solved! I had used ADSL-start as well as the RP-PPOE gui to start connections. Both were set to keep the connection up so when I killed the extra PPP it was started up again. that would be a /28 leaving your 4 bits of IP space. 2 to the 4th power is 16. 16 minus network,router,and broadcast addrs leave your 13 IP's At 11:26 AM 2/19/01 -0600, you wrote: >Okay all, here's a Monday morning quandry for you all. > >I have a Debian box at home that I would like to use as a firewall, >as well as a NAT box. I have DSL, and I have 13 useable static IPs >(it's 32-47 with 47 the broadcast, 32 the network and 46 the router >which makes is a /what? /24?). Now this is great for us, as we split >it 7 ways, and each person can have their own static to play with. >The problem is that sometime I have a bunch of people over, and >it's a real pain for them to have to set up all the network stuff for my >net, then set it back when they leave. > >So I had the thought that I would set up a box that simply >forwarded the statics to the router, and used DHCP and NAT for >the "guest" machines. The layout would be like so: > my.public.net.x______ > \-----eth1(10.0.0.254)--firewall---> > 10.0.0.x(guests)_____/ > > >---eth0(my.public.net.45)--->router(my.private.net.46) > >The problem is that eth1 will not accept IPs from the "bogus" >addresses that are not part of the 10.0.0.255 subnet, and it logs all >sorts of "martian source" errors and displayes them on the console >and in the logs. > >So the question is, is there a way I can make this work without >physically separating the two networks? Is there a better way to do >this? > >Thanks! On Sun, 20 Jul 2003 09:29, Sharrea wrote: > Recently I got a satellite internet connection which uses a PCI Telemann > Skymedia 200DPA card. It was working fine until a few days ago when > suddenly all packets received via this card are dropped by the kernel > with the 'martian source' messages in syslog: > > Jul 20 09:22:40 tbird kernel: martian source 203.109.204.173 from > 210.55.24.8, on dev sm200d > Jul 20 09:22:40 tbird kernel: ll header: > ff:55:01:bc:90:00:00:90:bc:01:55:ff:08:00 > > So obviously the kernel does not know where to route the packets to. No > settings were changed and my firewall rules are the same as when the > connection was working. Besides, this also happens with no firewall > running. > > I still use a dialup 56K modem to upload (dynamic IP), so only download > via satellite. When the sat. card's driver is loaded this what ifconfig > shows for these two devices: > > > Does anyone know how I tell the kernel that this device is supposed to > receive packets from the internet? I've spent two days fiddling with > problem and I'm at a loss as to what to try next... and I've not much > hair left to pull out ;) ANY help would be very much appreciated. Just thought I'd let everyone know in case it happens to someone else: the answer was to issue the command (as root user): echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter Thanks to Nic on the NZLUG mailing list. Oops, forgot to mention: see kernel docs- Configure.help from line 5220 > On Wednesday 19 March 2003 21:44, Sherwin T. Ang wrote: > > is your ethernet running in promiscuous mode? > > no... Then, all you have is a packet that showed up at your Linux host's ethernet interface with a source packet that makes no sense and is invalid in that context. If your machine is on the inward side of a filtering router ("firewall"), then you should add rulesets to the filtering router that drop & log packets that are addressed either from or to nonsensical addresses (broadcast addresses, RFC 1918 private-IP addresses, etc.). Any properly configured filtering router should already do this! If your machine, like mine, is fully exposed to the public Internet, then you can realistically expect to get bizarre, invalid packets thrown at it _all the time_. Welcome to the Internet! Your machine will be pummelled by invalid/malformed packets, attempts to find and exploit known vulnerabilities in in popular software, many times each and every day. The only other clue, as I see now, is that the messages come at exactly 2-minute intervals. I have fetchmail running as a background process polling every 2 minutes. So this makes some sense of that. For "martian source" partial reference jump to the following, it is illuminant!! =:`) "[SLE] martian source in dev eth0" from Carlos Illana (cillana@teleline.es) http://lists.suse.com/archives/suse-linux-e/2000-Jul/0221.html and related Eilert Brinkmann's (eilert@Informatik.Uni-Bremen.DE) reply: http://lists.suse.com/archives/suse-linux-e/2000-Jul/0282.html HTH nslookup 213.228.0.68 Note: nslookup is deprecated and may be removed from future releases. Consider using the `dig' or `host' programs instead. Run nslookup with the `-sil[ent]' option to prevent this message from appearing. Server: 213.228.0.68 Address: 213.228.0.68#53 Non-authoritative answer: 68.0.228.213.in-addr.arpa name = mrelay4-1.free.fr. 68.0.228.213.in-addr.arpa name = dnscache1-1.free.fr. Authoritative answers can be found from: nslookup 212.27.32.177 Note: nslookup is deprecated and may be removed from future releases. Consider using the `dig' or `host' programs instead. Run nslookup with the `-sil[ent]' option to prevent this message from appearing. Server: 213.228.0.68 Address: 213.228.0.68#53 Non-authoritative answer: 177.32.27.212.in-addr.arpa name = adsl-ns2.free.fr. Authoritative answers can be found from: [root@BenAthlux etc]# nslookup 212.27.32.176 Note: nslookup is deprecated and may be removed from future releases. Consider using the `dig' or `host' programs instead. Run nslookup with the `-sil[ent]' option to prevent this message from appearing. Server: 213.228.0.68 Address: 213.228.0.68#53 Non-authoritative answer: 176.32.27.212.in-addr.arpa name = adsl-ns1.free.fr. Authoritative answers can be found from: