É importante corrigir avisos sobre pacotes marcianos no buffer de anel do kernel?

Question

Estas são as saídas que vejo quando executo dmesg

[1373335.656608] device eth0 entered promiscuous mode
[1373364.891962] device eth1 entered promiscuous mode
[1374537.599978] IPv4: martian source 10.5.0.2 from 203.115.192.116, on dev eth0
[1374562.256536] device eth1 left promiscuous mode
[1375229.342282] device eth1 entered promiscuous mode
[1376178.967446] device eth0 left promiscuous mode
[1376182.455498] device eth0 entered promiscuous mode

• Q1) Eu sei que os pacotes marcianos têm endereços de origem que usam IPs não roteáveis. Esse host é uma instância de computação do Google com um IP público efêmero. O que significa "fonte marciana 10.5.0.2 de 203.115.192.116"?
• Q2) Devo eu iptables filtrar estes (por causa da segurança)?

Answer 1

Pacotes marcianos são quando um endereço local esperado é visto naquela interface (por exemplo, pacotes locais para a rede com uma rede diferente daquele pacote).

Embora não seja um projeto de rede recomendado, pode acontecer que algumas redes tenham pacotes "marcianos" por design (por exemplo, VLANs / redes físicas com várias redes lógicas).

Se você estiver usando iptables em um servidor, pode não ser uma má ideia filtrar os pacotes que você não deve ver.

Observe que, embora eu tenha um registro marciano em uma configuração de pré-produção, prefiro não registrar marciano, já que geralmente ele gera muitos logs e sobrecarrega suas operações de E / S.

    

Answer 2

Um pacote que chega em uma interface é considerado "marciano" se um pacote de resposta hipotético for roteado através de uma interface diferente. No seu caso 203.115.192.116 enviou um pacote para 10.5.0.2, que chegou na sua interface eth0. Se 10.5.0.2 for seu endereço, ip route get 203.115.192.116 relata corretamente uma interface diferente de eth0, e você realmente pretende fazer tal roteamento assimétrico, então esses logs marcianos devem ser desabilitados como

echo 0 > /proc/sys/net/ipv4/conf/eth0/log_martians

e rp_filter também devem ser desativados. Caso contrário (e isso parece muito mais provável) existe um problema de roteamento em algum lugar que deve ser corrigido. Se não puder ser corrigido (bem possível em um ambiente de nuvem hospedado), você pode desabilitar o log como acima ou soltar mais seletivamente por iptables (a cadeia filter pode ser muito tarde para isso, embora).