Paweł Goleń, blog

Muszę przyznać, że dziwnie się czuję rozmawiając o arp poisoning i różnym zachowaniu Windows i Linux w kontekście komendy arp -s (swoją drogą muszę sprawdzić jak zachowują się w tym przypadku Windowsy nowsze niż XP), różnicami w reasemblacji pakietów albo manipulacji TTL w kontekście unikania IDS/IPS.

Ja uczyłem się od podstaw, z nieśmiertelnej Biblii TCP/IP. Ponieważ wiem (mniej więcej) jak to działa, te pomysły są dla mnie zrozumiałe (w zasadzie każdy mając taką wiedzę może na to wpaść). Mam jednak wrażenie, że w tej chwili dominuje podejście od drugiej strony, od strony narzędzi/rozwiązań. Ludzie są uczeni, że jeśli wydadzą takie magiczne polecenie, to są bezpieczni. Nie rozumieją jednak do końca na czym polega problem i jak jest w danym przypadku rozwiązywany. I właśnie to powoduje, że czuję się dziwnie.

PS: No dobra, może i z tej książki nie nauczysz się na czym polegają optymalizacje w obsłudze[arp who-has](http://en.wikipedia.org/wiki/AddressResolutionProtocol), ale z drugiej strony będziesz w stanie sam się domyślić dlaczego system otrzymujący takie zapytanie aktualizuje swoją tablicę arp.

By zobrazować to lepiej – dlaczego 172.16.0.6 odpowiedział 172.16.0.128 skoro wcześniej nie zapytał jaki jest adres MAC dla tego adresu?

30516 91.105464000 Microsofd1:3c:14 Broadcast ARP 60 Who has 172.16.0.6? Tell 172.16.0.128 30517 91.105507000 IntelCorca:c2:74 Microsof_d1:3c:14 ARP 42 172.16.0.6 is at 00:16:ea:ca:c2:74 30518 91.106570000 172.16.0.128 172.16.0.6 ICMP 98 Echo (ping) request id=0x2cc6, seq=1/256, ttl=64 (reply in 30519) 30519 91.106884000 172.16.0.6 172.16.0.128 ICMP 98 Echo (ping) reply id=0x2cc6, seq=1/256, ttl=128 (request in 30518)

Oryginał tego wpisu dostępny jest pod adresem Old School

Autor: Paweł Goleń