Vlákno názorů k článku Odposloucháváme data na přepínaném Ethernetu (2.) od Martin Haller - Ohledne toho uceni MAC adres jste to napsal...

  • Článek je starý, nové názory již nelze přidávat.
  • 20. 6. 2006 15:54

    Martin Haller
    Ohledne toho uceni MAC adres jste to napsal hezky. Jen snad jsem chtel pripomenout ze obycejne prirazeni MAC a port na switchi tomuto útoku nezabrání. Muselo by jít o L3 switch který by si pároval MAC/IP a nejlépe ještě port
  • 20. 6. 2006 20:12

    anonymní
    Samotna port-security take neni vsespasitelna, jak se mnozi trosku mylne domnivaji (nebo to schvalne nepublikuji?) - specialne ne na utoky smerovane na ARP... Novejsi switche/softwary tohle reflektuji (alespon bavime-li se o Ciscu) a umoznuji i dalsi pokrocilejsi obranne techniky - napr. Dynamic ARP Inspection, IP Source Guard branici IP spoofingu, rate-limiting ARP na urovni switchu (zamezeni ARP floodu); obrany proti podvrhnuti DHCP serveru ze stanice (DHCP snooping)... nicmene tohle vsecko je na dve veci, kdyz to lidi nepouzivaji :-D
  • 20. 6. 2006 12:21

    Vojta (neregistrovaný)
    Nevím jak jinde, ale aspoň ve starších kernelech Linuxu se používala politika "Unsolicited ARP is not accepted by default". To znamená, že pokud počítač neposlal ARP dotaz, nepřijme (ignoruje) odpovědi. Aby odpověď přijal, musel v nedávné minulosti poslat příslušný dotaz.

    Což je komplikace pro útočníka, ten totiž musí poslat podvrženou odpověď až po obdržení dotazu (broadcast), a to dřív, než právoplatný příjemce - jde o milisekundy.

    Nemyslíte že tato vlasnost ARP driveru silně komplikuje případný útok?
  • 20. 6. 2006 13:47

    h4x0rr@paneboze.cz (neregistrovaný)
    pokud by jste cetl fyodoruv original, vedel by jste ze linux se ucit ip/mac pairy jak z requestu tak z replies. linux ignoruje reply pokud nevidel arp request, takze se zda byt vse v poradku - ale neni. linuxu z nejakeho perverzniho duvodu staci kdyz se ho nekdo zepta z dane mac/ip na nejakou absolute bogus ip a on zdrojovou mac/ip pair sezere i s navijakem.
    jine os se zase uci pouze z arp replies (bsd stack) takze ettercap posila na poisonuti jedne entry jak request z unasene ip adresy tak reply, aby to fungovalo vsude.

    na linuxu je bez patche jediny workaround, a to je zmenit /proc/sys/net/ipv4/neigh/default/locktime na nekolik hodin. to zajisti to ze se polozka v arp cache prepise _pouze_ je-li starsi nez zadany cas. pripadne si napsat script ktery veme soucasne arp entries (zarucene neotravene), narve je do /etc/ethers, a polozky nacte pomoci arp -f jako _staticke_ zaznamy z /etc/ethers. tento skript je potreba pustit pri zmene jakekoliv mac adresy na siti. paranoici muzou potom jeste vypinat dynamicke arp uplne (ifconfig eth0 -arp) ale to neni rozumne protoze pak nefunguji nove ip bez spousteni daneho skriptu (ktery se pousti treba jednou za noc). toto reseni pouzivam ja a ettercap si na gw ani neskrtnul.

    jo, jeste tu je dalsi reseni. dat si interface do bridge (samotny) a pouzivat ebtables/arptables na nejake flexibilnejsi filtrovani. a nebo mit v iptables dropovany vsecko krome danych ip/mac pairs (velmi oblibene u wifi zlatokopu) moznosti je hodne, ale nejlepsi je mit stejne pevne definovane mac na port (mac/port security), protoze vsechno resite pouze na switchi a jinde muze bezet vsechno legacy a je to jedno... dneska ty smart switche nejsou zase tak drahy.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).