Manhã calma, Tarde Turbulenta (Continuando)

A tarde não foi tão calma assim (já começava a acreditar na "SEXTA-FEIRA 13"), das diversas solicitações dos nossos clientes e incidentes que aconteceram, este problema que descreverei foi realmente instigante.

.... A saga ....

Descobrimos do que se tratava o problema de roteamento do post anterior, um problema no mínimo interessante.

Olhem a situação:

Foi relatado um problema no acesso a Internet em umas das redes que administramos, este acesso é provido por um servidor firewall com squid e outras coisas. Aparentemente tudo estava funcionando perfeitamente(regras de firewall, squid, etc), mas os clientes estavam recebendo a seguinte resposta do proxy "No route to host", um típico problema de roteamento. Então parti para testar a comunicação com o roteador e tudo normal. Fiz um teste a partir do firewall "telnet www.site.com.br 80" e a resposta foi a mesma "No route to host", parei o serviço do squid e retirei a regra de REDIRECT e, adivinhem, os clientes passaram a acessar a Internet.

O que era mais estranho é que o acesso a partir do firewall continuava recebendo o "No route to host"(O squid recebia a mesma resposta por estar localizado no fw), mas se os clientes saem nateados" com o ip do firewall, como eles conseguem acessar a Internet? e conexões iniciados no firewall não?

.:. A hipótese : o problema não está no firewall .:.

Parti para analisar a comunicação com o roteador, basicamente um tcpdump na placa externa do fw:

tcpdump -n -i eth1 not port 22 and icmp

15:34:54.606905 IP iprouter > ipfirewall: icmp 36: host siteexterno1
unreachable
15:34:55.132254 IP iprouter > ipfirewall: icmp 36: host siteexterno2
unreachable
15:34:56.184025 IP iprouter > ipfirewall: icmp 36: host siteexterno3
unreachable
15:34:56.428330 IP iprouter > ipfirewall: icmp 36: host siteexterno4
unreachable
15:34:56.602347 IP iprouter > ipfirewall: icmp 36: host siteexterno5
unreachable
15:34:56.782162 IP iprouter > ipfirewall: icmp 36: host siteexterno6
unreachable
...

O roteador estava respondendo "host unreachable", para todo site acessado, mas curiosamente o firewall não acessava e os clientes que acessavam por ele sim. Colocamos as máquinas internas para sair por um outro link e colocamos um notebook no lugar do firewall com o windows XP e acessou, e com o firewall nada.

Tirei a regra de NAT para os clientes internos no fw para aparecer no trace apenas conexões iniciadas pelo firewall e melhorar a nossa visão.

Coloquei um regra para "DROPAR" o host-unreachable do icmp.

"3/1" = host-unreachable
iptables -A INPUT -i eth1 -p icmp -m icmp --icmp-type 3/1 -j DROP

O teste foi feito com o mesmo telnet.

PKT 1 15:20:38.350441 IP ipfirewall.55970 > ipexterno.http: S
1658018876:1658018876(0) win 5840 0,nop,wscale 2>
PKT 2 15:20:38.353838 IP iprouter > ipfirewall: icmp 36: host ipexterno
unreachable
PKT 3 15:20:41.349671 IP ipfirewall.55970 > ipexterno.http: S
1658018876:1658018876(0) win 5840 0,nop,wscale 2>
PKT 4 15:20:41.432224 IP ipexterno.http > ipfirewall.55970: S
3240653776:3240653776(0) ack 1658018877 win 8192
PKT 5 15:20:41.432343 IP ipfirewall.55970 > ipexterno.http: . ack 1 win 5840

E, adivinhem? funcionou.

.:. A explicação .:.

1. O primeiro pacote com SYN eh enviado.
2. O roteador diz que o host é inalcansável "host ipexterno unreachable"
3. Como existe a regra de bloqueio do "host unreachable" do icmp o firewall não toma conhecimento deste evento e tenta enviar novamente outro início de conexão com o SYN.
4. O ipexterno finalmente responde com SYN/ACK
5. O ipfirewall fecha o handshake com um ACK.

Os clientes estavam acessando porque quem recebia o "host ipexterno unreachable" era o firewall e as máquinas clientes não tomavam conhecimento e continuavam as tentativas de conexão, conseguindo na segunda tentativa. O roteador respondia apenas ao primeiro pacote e as outras conexões passavam estranhamente.

Conclusão, o problema estava no roteador e chamamos o responsável por ele para investigar, pois o roteador não estava sobre o domínio da empresa e não podiamos entrar no roteador e verificar o que estava acontecendo.

Mas realmente foi um problema interessante. :> Quando resolvido se diz interessante, quando não, se diz "PUTZ" :)


Fábio Henrique.
----------------------------------------
Security Engineer / Intrusion Analyst