Fontes marcianas do meu IP público

Question

Hoje em dia eu recebo alguns pacotes marcianos no 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..

A origem "XXX.XXX.XXX.XXX" é o endereço IP público do meu servidor.

Estou pesquisando no Google, não encontrei realmente o que era. Isso é um ataque de falsificação ou simplesmente um problema de configuração de rede no meu servidor?

Eu tenho duas interfaces no meu servidor:

• eth1 é a interface principal (IP público)
• eth2 é uma interface RPN (Rede Privada Real, portanto não conectada à rede pública) e cujo endereço IP começa com 10.91 ...
• lo que é loopback, obviamente.

Aqui está minha configuração sysctl.conf, em que rp_filter = 1 e 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

Alguém pode me ajudar? Devo me preocupar com esses marcianos?

O que você diz sobre adicionar regras iptables a DROP e LOG os pacotes, como:

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

Muito obrigado pela sua ajuda

    

Answer 1

Você deve ser capaz de encontrar a fonte verificando os endereços MAC embutidos nos dados "44 a8 12 41 1d 2b 13 8b 9c ab 34 89 10 00". 44: a8: 12: 41: 1d: 2b deve ser o endereço MAC da sua interface. 13: 8b: 9c: ab: 34: 89 deve ser o endereço MAC do dispositivo remoto.

Tente verificar seu cache para ver se você tem outros endereços para esses endereços MAC. arp -a deve ser o comando a ser usado.

Para verificar seus dispositivos, os endereços MAC usam ip link show ou ifconfig .

    

Answer 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"

Erros de fontes marcianas que aparecem no log de mensagens