What is a Martian Packet?
The IANA defines a Martian packet as one which arrives on an interface where the interface does not use that network. For Linux, it’s any packet that arrives on an interface which is not configured for that subnet in any way.
Any martian packet notice should be investigated. Martian packets:
- Are frequently used in hacking intrusion.
- May be a symptom of a misconfigured server elsewhere on the network.
- May indicate a network infrastructure issue.
If configuration items in your /etc/sysctl.conf file disable this detection, they should be enabled and the sysctl program rerun. Some sample entries to check are:
net.ipv4.conf.all.log_martians=1 net.ipv4.conf.default.log_martians=1 net.ipv4.conf.bondib0.log_martians=1
In this post, we will illustrate how to interpret martian source messages with some real-world examples.
Example 1 – How to interpret the martian source message
Let’s use the example shjown below:
Aug 22 11:08:21 server kernel: martian source 192.168.12.197 from 192.168.12.198, on dev bondib0 Aug 22 11:08:21 server kernel: ll header: 08:00:00:00:45:00:01:00:00:00:40:00:40:11:9f:11:c0:a8:0c:c6:c0:a8:0c:c5
It means that the server receives a packet on the interface bondib0, the source of the packet (sender) was 192.168.12.198, and the destination of the packet (recipient) was 192.168.12.197. However, without additional information, we do not know why the packet was reported as martian packet.
Example 2 – Invalid broadcast
May 22 03:40:37 example2 kernel: IPv4: martian source 255.255.255.255 from 10.140.249.4, on dev eth1 May 22 03:40:37 example2 kernel: ll header: 00000000: ff ff ff ff ff ff 00 50 56 ad 59 09 08 00 .......PV.Y...
Here eth1 received a broadcast packet from the sender 10.140.249.4, and the recipient 255.255.255.255 is a limited broadcast, the target audience is all hosts in ‘local network’ (here is the 10.140.249.4 segment with unknown netmask), and the traffic should never be forwarded by a router.
However, in this case, eth1 has the IP address 10.168.252.8/16, it was not the same network as the sender 10.140.249.4. So it’s not expected to receive such broadcast packet from this sender, and the packet was rejected as a martian source. Such an issue can be caused by a misconfigured router.
Example 3 – Reverse Path Filtering
May 25 16:46:04 example3 kernel: martian source 10.255.16.101 from 10.255.1.140, on dev eth0 May 25 16:46:04 example3 kernel: ll header: 00:10:e0:3b:1b:8a:00:1f:27:3f:34:00:08:00
Here on example3, eth0 received a packet from 10.255.1.140, and the recipient is 10.255.16.101. To understand why it was rejected, we must inspect the network configuration of the 2 hosts, as illustrated below:
The server example3 have 2 interface eth0 (10.255.16.101), and bond0 (10.255.1.101), they were connected to L3 Switch and L2 Switch, separately. The L3 switch connected to 2 network segments: 10.255.16.0/24, and 10.255.1.0/24. The Sender was directly connected to the L2 Switch, and the L2 switch was connected with L3 Switch.
Here the sender to tried to reach the eth0 on example3, the packet will go through the L2 Switch and L3 Switch and reach the destination 10.255.16.101. This would be allowed normally. However, modern Linux usually have Reverse Path Filtering enabled:
# sysctl -a | grep eth0.rp_filter net.ipv4.conf.eth0.rp_filter = 1
In restricted mode, kernel test the incoming packets with RFC3704, if the interface is not the best reverse path the packet check will fail. In this case, the sender should have been able to reach the server example3 via bond0 since they were in the same segment. The check failed and the packet was rejected.
The easiest solution is to connect bond0 (10.255.1.101) instead. If that’s not feasible due to some special reason, either disable the Reserve Path filtering or use loose mode on eth0.