Tam gdzie traceroute nie może…
Napisał: Patryk Krawaczyński
20/05/2010 w Ataki Internetowe, Bezpieczeństwo Brak komentarzy. (artykuł nr 257, ilość słów: 602)
W
nawiązaniu to artykułu “Fire(wall)walking – spacer po zaporze ogniowej” warto również wspomnieć o narzędziu noszącym nazwę tcptraceroute. Jest to przerobiona implementacja standardowego traceroute, która używa pakietów TCP. Jak zauważył jego autor – problemem zapewnienia standardu bezpieczeństwa w Internecie jest jego niestandardowe używanie.
Większość zapór sieciowych współczesnego Internetu filtruje lub powinna filtrować pakiety wysyłane przez program traceroute, uniemożliwiając zbadanie trasy pakietu. Jednak w wielu przypadkach firewalle chroniące wybrane sieci i hosty zezwalają na nowe połączenia na określone porty za nimi nasłuchujących maszyn. Dlatego wysyłanie specjalnych* pakietów TCP SYN zamiast UDP czy ICMP ECHO pozwala na ominięcie tego rodzaju restrykcji. Mając na myśli specjalne pakiety należy rozumieć połączenia TCP, które nigdy nie nawiązują pełnych połączeń z docelowym hostem. Jeśli wybrany host nie nasłuchuje na danym porcie – zostanie zwrócony pakiet z ustawioną flagą RST – informując program, że docelowy port jest zamknięty. Natomiast w przypadku odpowiedzi pakietem SYN/ACK – port uznawany jest za otwarty – a sam program tcptraceroute wysyła pakiet RST by nigdy nie ukończyć “potrójnego uścisku dłoni” i tym samym nawiązać połączenia. Jest to ta sama metoda jaką stosuje skaner bezpieczeństwa nmap wykonując skanowanie typu półotwartego (ang. SYN scan lub half-open scan). Dla przykładu zostanie przeprowadzony wywiad następującej sieci:
[Modem ADSL/Router Linksys AG241V2] - [Router/Firewall Linux] - [Serwer WWW]
Przy badaniu zostanie uaktywniony również mechanizm wykrywający NAT (ang. Network Address Translation):
nfsec:~# tcptraceroute -w 1 --dnat target.org Selected device eth0, address 12.12.12.12, port 58113 for outgoing packets Tracing the path to target.org (13.13.13.13) on TCP port 80 (www), 30 hops max 1 router1.pl (14.14.14.1) 0.287 ms 0.235 ms 0.201 ms 2 router2.pl (14.14.14.2) 9.114 ms 9.389 ms 12.100 ms 3 router3.pl (14.14.14.3) 8.242 ms 8.356 ms 8.426 ms 4 * * * Detected DNAT to 10.10.1.250 5 target.org (15.15.15.1) 37.728 ms 37.954 ms 37.061 ms 6 target.org (15.15.15.1) 37.383 ms 37.646 ms 37.980 ms 7 target.org (15.15.15.1) [open] 42.472 ms * 67.754 ms
Jak widać najsłabszym ogniwem tutaj jest modem ADSL, który oprócz ujawnienia przekazywania pakietów do sieci wewnętrznej zdradził również adres zewnętrznego interfejsu (eth0) routera linuksowego (10.10.1.250). Uchybieniem ze strony firewalla i zarazem routera opartego na Linuksie było ujawnienie dalszego przekazywania pakietów oraz przekazanie informacji o otwartym porcie 80’tym. Zastosujmy się teraz do reguł z wyżej wspomnianego artykułu na firewallu linuksowym dodatkowo dodając następujące reguły, które maskują zachowanie typowego routera.
iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 1 iptables -A OUTPUT -m state --state INVALID -j DROP
Przeprowadzony ponownie test:
nfsec:~# tcptraceroute -w 1 --dnat target.org Selected device eth0, address 12.12.12.12, port 54610 for outgoing packets Tracing the path to target.org (13.13.13.13) on TCP port 80 (www), 30 hops max 1 router1.pl (14.14.14.1) 0.265 ms 0.253 ms 0.213 ms 2 router2.pl (14.14.14.2) 9.177 ms 9.739 ms 8.696 ms 3 router3.pl (14.14.14.3) 8.714 ms 8.260 ms 8.604 ms 4 * * * Detected DNAT to 10.10.1.250 5 target.org (15.15.15.1) 63.710 ms 38.341 ms 37.302 ms 6 target.org (15.15.15.1) 37.599 ms !p 36.907 ms !p 38.261 ms !p
Wskazuje, że nasza zapora nie ujawnia już informacji o dalszym przekazywaniu pakietów czy otwartym porcie. Ostatnią czynnością w celu poprawy bezpieczeństwa jest wymiana modemu (lub firmware’u na alternatywny) na model obsługujący, co najmniej SPI (ang. Stateful Packet Inspection).
Więcej informacji: tcptraceroute, NAT, SPI