11

We are intermittently seeing kernel: martian source log entries for eth0 on a couple of our servers. The interesting thing is that they are to and from the same IP. For instance:

Nov  4 02:20:27 tcffmppr6db09 kernel: martian source 10.153.242.13 from 10.153.242.13, on dev eth0.3171

This only happens on a couple servers. There are about 60 which have eth0 configured in the same manner (different IP, obviously).

What should I be looking at to track this down?

EDIT:

The route for this particular interface is the default route so I don't think it is a matter of being sent out the wrong interface.

9

Problem

I encountered the same problem today, where martian packets flooded my kernel logs. All the martian packets are from the same public IP address of eth0 to the same public IP address of eth0 (the real IPs and header is removed).

IPv4: martian source x.x.x.x from x.x.x.x, on dev eth0
ll header: 00000000: aa bb cc dd ee ff gg hh ii jj kk ll 08 00

After some research, I realized the reason is hidden in the ll header of the martian packets.

Theory

Assuming this in a Ethernet connection, ll header actually shows the beginning part of a Ethernet Type II Frame, which contains the destination MAC address, source MAC address, and a ID indicates the type of the rest part of the packet.

Ethernet Type II Frame Format[1]

As you see, the first 6 bytes are the destination MAC address, the next 6 bytes are the source MAC address, and a code in last 2 bytes. Common codes are:

  • 08 00: IP Packets
  • 86 dd: IPv6 Packet
  • 08 06: ARP Packet

Explanation

Back to my example.

IPv4: martian source x.x.x.x from x.x.x.x, on dev eth0
ll header: 00000000: aa bb cc dd ee ff gg hh ii jj kk ll 08 00

This tells us,

  • there was a packet received with the SAME source and destination IP address.
  • It was sent by GG:HH:II:JJ:KK:LL, which is a MAC address I don't know.
  • Its destination is AA:BB:CC:DD:EE:FF, which is my own MAC address.
  • It was an IP packet (08 00).

If a packet has the same source and destination IP addresses, it must be sent by the same network interface, but the MACs for source and destination are different! How can it be possible?

Thus, it is clear that the packet comes from Mars, either there are some routing problems, a machine within the network is configured, or someone is trying to spoof the IP/MAC addresses. The next step is checking the source MAC address in question.

7
excerpt from Linux: Log Suspicious Martian Packets / Un-routable Source Addresses

A Martian packet is nothing but an IP packet which specifies a source or destination address that is reserved for special-use by Internet Assigned Numbers Authority (IANA).

Here are examples of such address blocks:

  • 10.0.0.0/8
  • 127.0.0.0/8
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::/128
  • ::/96
  • ::1/128

To track this down you have several options. You could just ignore it, you could block it via your firewall, or you could use tcpdump or wireshark to dissect the contents of the packet, which will likely give you insight into what's causing this.

Additional descriptions and sources

One other phrase that shows up when you search for this is the following:

These are packets that Linux does not expect from the direction they came from (i.e. packets from internal hosts coming in on the external interface). The cause is probably a misconfigured machine on your LAN. You can turn off logging those packets via /proc/sys/net/ipv4/conf/interface/log_martians which is documented in /usr/src/linux/Documentation/proc.txt

I could not find the original source of this paragraph, but if you search for it, it shows up a lot, verbatim! This describes the issue as a packet that has come into the system on an interface (NIC) that it's not designated to be coming in through.

Finally I'd cite Wikipedia on this topic as well, which too, states roughly the same as the above.

A Martian packet is an IP packet which specifies a source or destination address that is reserved for special-use by Internet Assigned Numbers Authority (IANA). If seen on the public internet, these packets cannot actually originate as claimed, or be delivered.1 However, certain reserved addresses can be routed using multicast, or on private networks, local links, or loopback interfaces, depending on which special-use range they fall within.2

Martian packets commonly arise from IP address spoofing in denial-of-service attacks,3 but can also arise from network equipment malfunction or misconfiguration of a host.1

References

  • Nice explanation however....use of these blocks tends to be pretty common especially behind NAT'd networks. Thus based on your explanation, I'd expect to see these messages all the time. So there is something more going on in the kernel message, I'd be interested in knowing what. – mdpc Nov 5 '14 at 0:50
  • @mdpc - additional info describes cause of martian packets: How broken is routing strategy that causes a martian packet (so far only) during tracepath? – slm Nov 5 '14 at 1:27
  • 1
    We're going to be running a 24-hour tcpdump on the servers in question. That said, I understand the concept of a martian packet. What I don't understand, is why an interface would consider its own IP as such. – theillien Nov 5 '14 at 3:18
  • pointless answer in fact. – poige Jul 29 '18 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.