MISCONFIGURATION: kernel rp_filter settings,
reverse path filtering
Sistema utilizado: Red Hat Enterprise Linux Server release 5.10 (Tikanga)
SINTOMA:
Configuramos o servidor para ser um banco de dados Oracle, esse server ficava durante um tempo, tipo 1 dia, funcionando normalmente mas de repente o mesmo parava de responder a qualquer tipo de conexão vindo de determinadas máquinas, simplesmente os pacotes chegavam no servidor, em sua interface de rede, e o mesmo não respondia não importando o tipo de conexão vindas de determinadas máquinas. O firewall deste servidor assim como SELinux estavam desativados e não existia também nenhum filtro no caminho entre os servidores envolvidos nessa comunicação.
PROBLEMA:
O esquema de segurança contra ataque tipo Spoofing é assegurado por um parâmetro de Kernel rp_filter settings no Red Hat e esse parâmetro foi ajustado incorretamente. A versão 5 do Red Hat admite somente dois valores para esse parâmetro(0 ou 1), já a versão 6 do Red hat admite 3 valores(0,1 e 2).
Sistema utilizado: Red Hat Enterprise Linux Server release 5.10 (Tikanga)
SINTOMA:
Configuramos o servidor para ser um banco de dados Oracle, esse server ficava durante um tempo, tipo 1 dia, funcionando normalmente mas de repente o mesmo parava de responder a qualquer tipo de conexão vindo de determinadas máquinas, simplesmente os pacotes chegavam no servidor, em sua interface de rede, e o mesmo não respondia não importando o tipo de conexão vindas de determinadas máquinas. O firewall deste servidor assim como SELinux estavam desativados e não existia também nenhum filtro no caminho entre os servidores envolvidos nessa comunicação.
PROBLEMA:
O esquema de segurança contra ataque tipo Spoofing é assegurado por um parâmetro de Kernel rp_filter settings no Red Hat e esse parâmetro foi ajustado incorretamente. A versão 5 do Red Hat admite somente dois valores para esse parâmetro(0 ou 1), já a versão 6 do Red hat admite 3 valores(0,1 e 2).
No Red Hat 5:
rp_filter - BOOLEAN
1 - Faz a validação da origem usando o caminho reverso, como
especificado no RFC1812. Opção recomendada para servidores e roteadores de
rede. Poderá causar problemas para redes complexas rodando um protocolo não
confiável e lento(tipo RIP) ou que usa rotas estáticas.
conf/all/rp_filter deve ser
também configurado para TRUE para fazer a validação de origem na interface.
No Red Hat 6:
rp_filter - INTEGER
0 - Sem validação de origem.
1 - Modo rígido como definido na RFC3704. Cada pacote que chega é testado
contra a FIB(Forwarding Information Base, encontra a interface apropriada para
a qual a interface de entrada deverá encaminhar um pacote) e se a interface não
é o melhor caminho reverso o check do pacote falhará. Por padrão pacotes que
falharam são descartados.
2 - Modo folgado como definido na RFC3704 cada endereço de origem do pacote que
chega é também testado contra a FIB e se o endereço de origem não é alcançável
via qualquer interface o check do pacote falhará.
SOLUÇÃO:
Se este problema de comunicação estiver acontecendo em seu
servidor devemos primeiramente habilitar o log de martians packet:
echo 1 >
/proc/sys/net/ipv4/conf/eth0/log_martians
sysctl -w
net.ipv4.conf.default.log_martians=1
sysctl -p
Check os logs no
dmesg:
dmesg | grep
-i martian
Algo do tipo
"martian source 169.254.179.40 from 169.254.179.43, on dev eth0" irá
aparecer no seu log.
O nosso
problema foi que configuramos o parâmetro rp_filter no arquivo /etc/sysctl.conf
na versão 5 do Red Hat com o valor 2(Sendo que essa versão só aceita dois
valores 0 ou 1):
net.ipv4.conf.default.rp_filter
= 2
Modificamos o
parâmetro para o valor certo em dois parâmetros e o sistema parou
de logar martian packet e derrubar as conexões legitimas vindas outros servidores da nossa rede:
net.ipv4.conf.default.rp_filter
= 1
net.ipv4.conf.all.rp_filter
= 1
