2

These days I get some Martian packets in the kern.log:

Jul  7 02:28:20 box14932 kernel: [789192.798073] IPv4: martian source XXX.XXX.XXX.XXX from 10.91.12.01, on dev eth1
Jul  7 02:28:20 box14932 kernel: [789192.798095] ll header: 00000000: 44 a8 12 41 1d 2b 13 8b 9c ab 34 89 10 00        D.BB.......Y..
Jul  7 04:29:12 box14932 kernel: [798267.423393] IPv4: martian source XXX.XXX.XXX.XXX from 10.91.20.10, on dev eth1
Jul  7 04:29:12 box14932 kernel: [798267.423401] ll header: 00000000: 44 a8 12 41 1d 2b 13 8b 9c ab 34 89 10 00        D.BB.......Y..
Jul  7 04:29:12 box14932 kernel: [798267.423408] IPv4: martian source XXX.XXX.XXX.XXX from 10.91.20.10, on dev eth1
Jul  7 04:29:12 box14932 kernel: [798267.423410] ll header: 00000000: 44 a8 12 41 1d 2b 13 8b 9c ab 34 89 10 00        D.BB.......Y..

The source "XXX.XXX.XXX.XXX" is the public IP address of my server.

I'm searching on Google, I have not really found what it was. Is this a spoof attack or simply a network config problem on my server?

I have two interfaces on my server:

  • eth1 is the main interface (public IP)
  • eth2 is a RPN interface (Real Private Network, therefore not connected to the public network) and whose IP address starts with 10.91...
  • lo which is loopback, obviously.

Here is my sysctl.conf configuration where rp_filter=1 and log_martians=1 :

# Log Martians
net.ipv4.conf.all.log_martians = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1


# IP Spoofing protection
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0 
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Ignore send redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Block SYN attacks
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 5

# Ignore ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0 
net.ipv6.conf.default.accept_redirects = 0

Can someone help me? Should I worry about these martian?

What do you say about adding iptables rules to DROP and LOG the packets, like :

-A INPUT -i -s 10.0.0.0/8 ENO1 j DROP

Many thanks for your help

stambata
  • 1,668
  • 3
  • 14
  • 18
user2074224
  • 23
  • 1
  • 4
  • See [What is martian source / martian packets](http://www.cnblogs.com/super-king/p/4155910.html) – user Jul 07 '16 at 09:34
  • Do you have two NICs on the same switch? – stambata Jul 07 '16 at 09:44
  • @stambata yes, eth1 is on my public IP, eth2 is on a private network on a different network interface – user2074224 Jul 07 '16 at 11:22
  • If a computer has multiple NIC cards plugged in to the same switch, then it martian sources may be shown (this is the most common cause). – stambata Jul 07 '16 at 11:31
  • thanks @stambata so nothing to worry about? by security, should I block via INPUT 10/8 via iptables rule? – user2074224 Jul 07 '16 at 11:44
  • .. or just stop logging In sysctl.conf add "net.ipv4.conf..log_martians=0" – stambata Jul 07 '16 at 12:00
  • The format of the `martian source` log messages can be a bit confusing. The first IP address on the log line is the destination address, and the second IP address on the log line is the source address. See http://lxr.linux.no/linux+v3.1.5/net/ipv4/route.c#L2002 – kasperd Jul 07 '16 at 12:39
  • Those packets appear to have Ethertype `1000`, which is suspicious because IPv4 is supposed to be using Ethertype `0800`. And Ethertype `1000` is [listed](http://standards-oui.ieee.org/ethertype/eth.txt) as Private. – kasperd Jul 07 '16 at 12:47
  • thanks @kasperd 10.91.12.01 (the source address) is on eth2 on a Private Network (RPN) so no connected on Internet. This could explain the ethertype 1000? – user2074224 Jul 07 '16 at 14:26
  • @popcaan If it is Ethernet there should be a meaningful Ethertype. If it is not Ethernet, the `ll header` line shouldn't be in the log at all. But it may not be worth spending a lot of time figuring out the source of the spurious Ethertype. – kasperd Jul 07 '16 at 20:44

2 Answers2

2

Much of the problems experienced with martian source is caused by network topography considerations. The following may need to be addressed:

  • Router: The router may be routing through illegal addresses; make sure that the router is configured correctly.
  • Multiple NICS: If a computer has multiple NIC cards plugged in to the same switch, then it martian sources may be shown (this is the most common cause).
  • Firewall: Is there a firewall allowing inappropriate traffic in?
  • IP addresses: Are you using multicast or Class E network addresses?
  • Other computers: Are other servers or workstations MAC addresses responsible?

Potential Solutions

Multiple NICs on the same subnet: Multiple NICs on the same subnet is the most common cause. If you must have multiple NICs on the same subnet, use a managed switch. This can be tested by off-lining all but one NIC cards; if the messages go away, then you can assume that the multiple NICs are the cause. Another solution would be to bond the NICs together. Generally speaking a properly configured network should not require multiple NICs to be on the same subnet, except in the case of bonding.

Turn off logging to the kernel: If you are able to determine that the martian sources are not related to a security issue, then you may turn off martian source logging. Please note, you must make sure that you are sure that the network is secure and that the source of these messages are not from the router.

  • In /etc/sysconfig/sysctl add "net.ipv4.conf..log_martians=0"

  • Make sure that "sysctl" is set to run on boot by "chkconfig boot.sysctl on"

Martian sources errors showing in messages log

stambata
  • 1,668
  • 3
  • 14
  • 18
2

You should be able to find the source by checking the MAC addresses embeded in the data "44 a8 12 41 1d 2b 13 8b 9c ab 34 89 10 00". 44:a8:12:41:1d:2b should be your interface's MAC address. 13:8b:9c:ab:34:89 should be the remote device's MAC address.

Try checking your cache to see if you have any other addresses for those MAC addresses. arp -a should be the command to use.

To check your devices MAC addresses use ip link show or ifconfig.

BillThor
  • 27,737
  • 3
  • 37
  • 69
  • Yes Bill, "13:8b:9c:ab:34:89" corresponds to the MAC address of eth2 which is running a private network. So everything is "normal"? – user2074224 Jul 07 '16 at 13:56
  • @popcaan It looks like you may have a service bound to the external interface communicating with a device on eth2. It looks ok, but I generally try to use internal addresses on the internal network. – BillThor Jul 07 '16 at 22:38
  • @popcan You may want to disable martian detection on your internal interfaces while leaving it enabled on your external (eth0) interface. Check the output of 'sysctl -a | grep martian' for variables you can set. – BillThor Jul 08 '16 at 13:43