Martian Packets | Packets from Mars?

Martian packets are the packets having an impossible source or destination IP address, hence considered invalid packets suited to be dropped by the system.

"Having an impossible IP address in the packet" generally means one of the following situations:

• • The IP address falls under an IP range that is reserved by the Internet Assigned Numbers Authority(IANA) for special use.
    For e.g.
    • a class E IP address
    • private address 192.168.0.1 discovered on the public Internet
    • local address 127.0.0.1 arriving at an interface other than the loopback interface, etc.
  • The IP address cannot be routed back to. That is, if the system has to send any traffic back to the source IP address, it doesn't have a route defined.
  • More specifically, the packet was received from a source IP address at one interface but isn't routable through the same interface.
  • For e.g. a packet with source address 172.17.12.2/24  arrives at the eth0 interface having address 192.168.12.2/24 . But when the system checks the reverse path, it cannot imagine itself sending traffic to 172.17.12.2/24 via the eth0 interface.
• Having a martian packet arrive on a system is analogous to a Martian arriving on Earth. They are considered invalid and dropped by default. (Wonder what the human rights - or rather martian rights - have to say about this!)
•  
• On such event, it's logged as follows in /var/log/kern.log.

• Nov 7 14:03:41 logpoint kernel: [12177002.029866] IPv4: martian source 100.100.1.40 from 172.17.16.9, on dev eth0

• Nov 7 14:03:41 logpoint kernel: [12177002.029880] ll header: 00000000: 00 50 56 01 16 27 00 09 0f 09 04 12 08 00

• Reverse path forwarding is a security mechanism in Linux kernel that validates the source address of the incoming network packets. It is enabled with the rp_filter directive (net.ipv4.conf.default.rp_filter).
  
  By default, it is set to 1 that refers to Strict mode as defined in RFC 3704. In a nutshell, it means "if a packet is received from a address at an interface but isn't routable on the same interface, it's dropped."
•  

Common Causes of Martian Packets

• There is a misconfiguration in the network or bad network topology design.
• Having multiple NICs in the same subnet is usually the cause.
• Someone is sending packets to our system with spoofed IPs.
• There is a IP clash between the interfaces of the system. Common scenarios are as follows:
  • A log packet with source address 171.17.0.2/24 arrives at the eth0 interface with address 10.45.14.20/24. But, there is no reverse route from this system to 171.17.0.2/24 via the eth0 interface, because there is also the docker bridge interface docker0 with IP 172.17.0.1/16 . And, the system thinks the correct route to the 171.17.0.2/24 is via the docker0 interface, hence the clash.
  • Another scenario is a log packet incoming from a device with source IP 10.99.X.X . This clashes with our support VPN interface which operates in the same 10.99.X.X subnet.
• There may also be multiple default routes from the system due to an improper netplan configuration.

How do we prevent/handle Martian Packets?

1. Make sure the network is properly configured. Here is a common checklist:
   • Avoid having multiple NICs in the same subnet. Choose bonding the NICs in such situtations.
   • Configure routes properly.
     • Avoid having multiple default routes.
     • Use static routes when necessary.
       For e.g. If you have configured SIEM to receive logs from the 10.99.X.X devices, to prevent it from clashing with the support VPN interface tap0 , add static routes to your Netplan configuration.
   • Prevent interface IP clashes.
     • To prevent clash with the docker0 (docker bridge IP interface), you can change your docker bridge interface IP by simply using the command change-docker-bip as li-admin as pointed out in the docs .
2. To simply disable the log messages, you can turn off martian packets logging by setting using sysctl.
   • net.ipv4.conf.all.log_martians to 0 
   • net.ipv4.conf.default.log_martians to 0
     However, we're most probably well off without disabling this feature.
3. In dire situations, there is also an option to disable reverse path forwarding by setting the net.ipv4.conf.default.rp_filter to 0, or enable loose reverse path forwarding by setting the net.ipv4.conf.default.rp_filter to 2 using sysctl as defined here. 

References

• http://www.faqs.org/rfcs/rfc1812.html
• https://www.ietf.org/rfc/rfc3704.txt
• https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-server_security-reverse_path_forwarding#sect-Security_Guide-Server_Security-Reverse_Path_Forwarding
• https://www.cyberciti.biz/faq/linux-log-suspicious-martian-packets-un-routable-source-addresses/
• https://netplan.readthedocs.io/en/stable/