| |
Oto moje zrozumienie sytuacji: kiedy serwerowi DHCP zabraknie dzierżaw do przypisania, zabije najstarszą (pod względem użytkowania) dzierżawę. Jeśli urządzenie, które posiadało dzierżawę, nie jest włączone, dla odpowiednich wartości „on”, w tym czasie nie zostanie o tym powiadomione.Zwykły (być może standardowy, nie jestem pewien) proces polega na tym, że urządzenie potwierdza dzierżawę DHCP po ponownym włączeniu, aw tej sytuacji urządzenie zostanie powiadomione, że nie może mieć starej dzierżawy, ponieważ została zmieniona, a serwer zapewni kolejną dzierżawę (być może po zabiciu kolejnej dzierżawy). Jeśli jest to urządzenie Apple i zachowuje się w opisany sposób, po ponownym „włączeniu” nie będzie konsultować się z DHCP, ale ponownie wykorzysta posiadaną wcześniej dzierżawę. Jeśli serwer udzielił tej dzierżawy innemu urządzeniu, urządzenie Apple włączy się, powodując konflikt adresów IP. Przewrotnie, urządzenie Apple wkrótce to wykryje, faktycznie wykona żądanie DHCP i przełączy się bez wskazania użytkownikowi, pozostawiając drugie urządzenie zastanawiające się, dlaczego doszło do konfliktu adresów IP i jak sobie z tym poradzić. Czy jest to w jakikolwiek sposób nieprawidłowe? |  | |
O ile widzę na podstawie RFC i Googling, nie ma mechanizmu umożliwiającego serwerowi DHCP odzyskanie adresu IP przed wygaśnięciem dzierżawy, chyba że klient wyraźnie zainicjuje rezygnację z dzierżawy.Raz podany adres jest własnością klienta na czas trwania najmu. | | | |
Biorąc pod uwagę, że większość routerów zarządza siecią klasy C, a nawet wtedy przydzieliła pierwsze 100 adresów do użytku wewnętrznego (rozpoczynając pulę DHCP od 0,100), oznaczałoby to, że DoS dowolnego serwera DHCP byłoby trywialne w ciągu kilku sekund, po prostu zmieniając adresy MAC i dzierżawiąc wszystkie ich adresy.Oczywiście nie jest to realistyczne i nikt nigdy nie zaimplementowałby serwera DHCP, który na to pozwolił: będzie on śledził pewną stałą liczbę dzierżaw (prawdopodobnie/mam nadzieję, że tyle adresów IP, ile zarządza), a kiedy się skończy, będzie zmuszony odzyskać adres od innego użytkownika. Jeśli już, fakt, że taki mechanizm nie jest określony, po prostu pogorszy sytuację, ponieważ konkretna implementacja sposobu i czasu odzyskiwania zakończy się jako „co*kolwiek ma sens dla faceta pracującego nad tą konkretną implementacją serwera DHCP” i może stanowić pozornie przypadkowe zachowanie. | | | |
Nie musisz nawet zmieniać adresów MAC; po prostu wyślij komunikaty DHCPDECLINE na dowolny adres podany przez serwer. DHCP wymaga, aby każdy adres, który wywołuje tę odpowiedź od klienta, MUSI być oznaczony jako niedostępny, i nie zapewnia możliwości ponownego udostępnienia go.Ignorowanie klienta jest jedynym automatycznym mechanizmem, jaki zapewnia DHCP, aby temu przeciwdziałać. Trzeba pamiętać, że DHCP zostało odpisane, gdy zakładano, że kompetentny administrator systemów zarządza serwerem i może ręcznie reagować na wyczerpanie dostępnych adresów (co uznano za prawdopodobną oznakę błędnej konfiguracji), a nie próbowało określić, co zrobić w przypadku, gdy tak się stanie. W tym przypadku specyfikacja DHCP zaleca niepodawanie adresu i powiadamianie administratora systemu. W rzeczywistości sekcja 2.2 twierdzi, że „Mechanizm alokacji (zbiór serwerów DHCP) gwarantuje, że adres nie zostanie ponownie przydzielony w żądanym czasie”, więc wszelkie odzyskiwanie adresu IP ze strony serwera jest technicznie sprzeczne z RFC 2131. | | | |
Jestem zdezorientowany... czy zatem sugerujesz, że w ten sposób ludzie tacy jak Linksys powinni poradzić sobie z tym problemem? W pełni zdaję sobie sprawę, że specyfikacja została napisana w innym czasie, ale nie sądzę, aby zrobił to tzs: tak naprawdę powołuje się na specyfikację jako powód, dla którego te dzierżawy powinny pozostać. Kiedy idziesz do kawiarni, router nie emituje i prawdopodobnie nie powinien emitować sygnału dźwiękowego, gdy skończyły się dzierżawy DHCP, co powoduje, że barista chodzi po pokoju, znajdując laptopy, które zostały nieprawidłowo skonfigurowane… | | | |
Dostępne są rozsądne opcje inne niż naruszanie umów najmu.Na przykład w przypadku często używanego punktu dostępowego sensowne byłoby udzielanie tylko bardzo krótkich dzierżaw - powiedzmy 10 minut. Obsłużyłoby to odpływ 25 klientów na minutę, jeśli podajesz adresy z /24 (i nie ma powodu, dla którego nie mógłbyś użyć mniejszej maski sieci, do /8). Rozsądne byłoby również zignorowanie pojedynczego adresu MAC, gdy ma on więcej niż kilka zaległych dzierżaw. Nie pomaga to w przypadku złośliwego klienta - ale zerwanie dzierżawy też nie. Złośliwy klient może spowodować wystarczającą ilość trzepotania adresów, aby całkowicie uniemożliwić korzystanie z sieci. Naprawdę nie możesz chronić sieci Wi-Fi przed złośliwym klientem próbującym ją DoS - istnieje niezliczona ilość sposobów, aby to zrobić oprócz DHCP. | | | |
To trywialne dla DoS dowolnej sieci warstwy 2. To jest trywialne netsec. | | | |
Istnieje zasadnicza różnica między siedzeniem w sieci i zalewaniem jej (czynność, która wymaga faktycznego połączenia z siecią, chociaż może to być oczywiście małe i trudne do wykrycia urządzenie), a wysłaniem 256 pakietów i odejściem ze świadomością, że przez następne 24 godziny nikt nie będzie mógł korzystać z sieci, ponieważ posiadasz wszystkie dzierżawy DHCP. „To trywialny netsec”. | | | |
Nigdy nie powiedziałem powódź, powiedziałem DoS. Nie sądzę, żeby to było na temat, więc nie będę wchodził w szczegóły, ale powinieneś spoofing Google ARP. Te taktyki są dość trywialne i uczę studentów, aby robili to w przyszłym roku. | | | |
Miałem i nadal mam wrażenie, że tego rodzaju atak nie jest możliwy, gdy punkt dostępowy ma izolację węzła (bardzo powszechną funkcję, którą obsługuje nawet mój router MiFi, mimo że często jest wyłączany w środowiskach domowych, a nawet biurowych), jednak wspomniany wcześniej DHCP DoS na poziomie protokołu, który opisałem, zadziałałby na każdym urządzeniu, które zaimplementowało specyfikację DHCP. Dlatego nie rozumiem, w jaki sposób fałszowanie ARP jest istotne. Pamiętaj: dyskutujemy, czy jest uczciwe przekonanie, że jakakolwiek rozsądna implementacja DHCP zaimplementowałaby specyfikację zgodnie z deklaracją. | | | |
Właśnie o to mi chodzi. co opisuje JarekMócsię zdarzyć, ale jest to przypadek awarii, a nie przypadek normalnego działania. I jak pokazano w artykule, inżynierowie z Apple uwzględnili przypadek awarii, więc wszystko jest w porządku. Po prostu przyjęli bardzo rozsądne założenie, że serwer DHCP będzie normalnie działał, a nie w stanie kryzysowym, i że będzie honorował swoje kontrakty określone w dokumencie RFC. Jak trudne jest to? | | | |
TamJestzasada „konserwatywny w tym, co wysyłasz, liberalny w tym, co akceptujesz”, na której zbudowano UNIX i połowę Internetu. | | | |
Myślę, że Twój opis jest poprawny.Problemem jest wpływ fałszywego „konfliktu ip”, który jest spowodowany tą optymalizacją. Urządzenie, które wykryje konflikt IP, nie powinno zgadywać, czy jest to konflikt IP spowodowany optymalizacją na innym urządzeniu. Jak wskazano w innych komentarzach, konflikt adresów IP może spowodować zerwanie istniejących połączeń przez inne systemy. Nikt nie lubi powiadomień o konflikcie adresu IP ani zrywania połączeń. Graj ładnie. To wszystko. | | | |
Problem polega na tym, że serwer DHCP ponownie wystawił ważną dzierżawę drugiemu komputerowi. Z pewnością jest to problem z serwerem DHCP, który nie gra ładnie, a nie Apple? | | | |
Czy uważasz, że istnieje lepszy, bardziej tolerancyjny i mniej podatny na błędy sposób działania, który serwer DHCP mógłby podjąć, gdyby skończyły się dzierżawy? | | | |
Jeśli jesteśmy w stanie zmodyfikować serwer DHCP, aby zrobić coś sensownego, dlaczego nie zmodyfikować domyślnych ustawień routera, aby wydawał adresy /16 zamiast /24? Albo nawet 10/8? Jest mnóstwo miejsca na RFC1918, którego nie można przegapić.Tabele stanów NAT nie będą musiały rozciągać się tak daleko, ponieważ mogą przekraczać limit czasu nieużywanych połączeń, tak jak już to robią. Czy takie postępowanie miałoby jakieś niezamierzone skutki uboczne? Jeśli nie podoba ci się NAT, śmiało wyślij IPv6 :-) | | | |
Nie bardzo. Serwer DHCP może mieć wiele ważnych powodów do ponownego wystawienia technicznie ważnej dzierżawy, na przykład ponowne uruchomienie i utrata tabeli ważnych dzierżaw. Jak wskazałem w powyższej odpowiedzi, protokół DHCP jasno określa, że urządzenia powinny ponownie weryfikować swoje adresy po przebudzeniu. | | | |
Ta optymalizacja nie powoduje konfliktów adresów IP. Jeśli serwer DHCP nie śledzi prawidłowo czasu dzierżawy i nie zapewnia, że już przypisane adresy nie są ponownie wykorzystywane, gdy klient nadal ma ważną dzierżawę, mogą wystąpić konflikty adresów IP niezależnie od tego, czy w sieci są jakieś urządzenia Apple. | | | |
Proszę wymienić jeden lub więcej serwerów DHCP, które świadomie naruszą przyznaną dzierżawę, poprzez „zabicie najstarszego” lub w jakikolwiek inny sposób. | | | 
