Własny DNS cache jako lekarstwo na problemy z siecią

Jest powiedzenie, że nowe to dobrze zapomniane stare. Tak jest w przypadku DNS i ataków różnej maści. Niedawno głośno było o DDoSach z użyciem DNS amplification, potem o podmianie DNS (głównie na routerach, nie jak kiedyś na komputerach, ale cel ten sam), a od niedawna popularne stało się generowanie dużej ilości zapytań do serwerów DNS rekursywnych ISP (AFAIK też ostatecznie rodzaj DDoSu). Na tyle dużej, że niektórzy operatorzy mieli/mają problemy z obsłużeniem żądań pochodzących od swoich klientów na swoich serwerach cache’ujących.

Z różnych pokątnych źródeł (Facebook, IRC) wiem, że pierwszego dnia, gdy się to zaczęło, były problemy z dostępem do Internetu w sieciach należących do Inei i Multimedii. Nie znam przyczyny, ale biorąc pod uwagę, że jeszcze jednemu providerowi „kończyły się” maszyny obsługujące rekursywne DNS i że w przypadku Multimedii pomagała zmiana w systemie na np. serwery DNS Google, przypuszczam, że chodzi właśnie o niewydolność serwerów DNS dostarczanych użytkownikom tych sieci przez ISP.

Rozwiązanie jest dość proste – wystarczy uruchomić swój serwer DNS rekursywny lub forwarder na desktopie czy routerze w swojej sieci, by sieć zaczęła działać lepiej i być mniej zależna (lub nawet niezależna) od DNSów naszego ISP. Ja na swoich desktopach (oczywiście Linux) od dłuższego czasu mam uruchomionego unbound (pokłosie benchmarków DNS) – jest lekki i bezproblemowy. W obecnej sytuacji mamy podwójną korzyść z własnego cache: po pierwsze, jak zwykle odpowiedzi udzielane będą nieco szybciej[1], po drugie, uniezależniamy się od serwerów naszego ISP, który w związku z niewesołą sytuacją w sieci może mieć problemy z działaniem w ogóle.

Z kolei w przypadku sieci lokalnych i routerów sprzętowych działających pod kontrolą OpenWrt lub podobnego systemu warto zwrócić uwagę na mały i zgrabny dnsmasq, którego konfigurację opisywałem kiedyś dość dokładnie.

Niezależnie od wyboru, koniecznie pamiętajmy o zabezpieczeniu czyli poprawnej konfiguracji naszego serwera DNS. Obsługujmy zapytania rekursywne tylko z naszej zaufanej sieci (np. LAN). W przeciwnym razie nasz serwer może zostać wykorzystany do DDoS poprzez DNS amplification. Ograniczać można na wiele sposobów w zależności od użytego serwera i możliwości: firewall, ograniczenie nasłuchiwania do konkretnego interfejsu lub definicje obsługiwanych prefiksów w konfiguracji samego serwera.

[1] Nie zawsze jest to prawdą, liczy się nie tylko opóźnienie do serwera, ale także zawartość jego cache czy wydajność sprzętu, na którym działa. Pisałem kiedyś szerzej o wyborze serwera DNS.

0-day w Linksysie ma szerszy zasięg czyli problem z UPnP dla Broadcom..

Zgodnie z wcześniejszą zapowiedzią firma DefenseCode opublikowała szczegóły nt. niedawnego 0-day na routery Linksys. Okazuje się, że chodzi o implementację UPnP w firmware Broadcom i – jak można się spodziewać – w takiej sytuacji podatnych jest znacznie więcej routerów, różnych producentów. Na pewno podatność dotyczy Linksysa WRT54GL, WRT54G3G, prawdopodobnie WRT310N, poza tym, dotknięty potencjalnym błędem chip może występuje w urządzeniach urządzeniach wielu producentuów, m.in. Netgear, Asus, D-Link, Zyxel, TP-Link.

Padało pytanie, czy exploit działa z WAN czy z LAN. Z dokumentu wynika, że w wielu przypadkach działa spoza sieci lokalnej. Pojawia się stwierdzenie, że jedyna popularna implementacja UPnP, która nie posiada błędu, to MiniUPnP (tak, open source, tak, OpenWrt jest odporne). Pora na zmianę firmware’u, chociaż UPnP mam wyłączone. Ciekawe swoją drogą, czy wyłączenie UPnP eliminuje podatność.

UPDATE: Znalazłem dwa ciekawe, polskie serwisy nt. bezpieczeństwa, do których odsyłam zainteresowanych tematem bezpieczeństwa. W szczególności pierwszy pisze więcej o tym konkretnie zagadnieniu (wygląda, że wyłączenie UPnP pomaga), a tutaj znajdziecie istny pogrom domowych urządzeń sieciowych.

0-day w Linksysie załatany?

Widzę, że właśnie na stronach Linksysa pojawił się do pobrania nowy firmware, oznaczony Ver.4.30.16 (Build 4), z datą wydania 10.01.2013 (co ciekawe, jeszcze wczoraj go tam nie było). Prawdopodobnie chodzi o załatanie 0-day opisywanego ostatnio. Z release notes możemy wyczytać:

Firmware 4.30.16 (build 4)- Resolves XSS issue.

Pora na aktualizację.

UPDATE: W komentarzu lolo napisał, że takowego firmware’u nie ma. Jak nie ma, jak jest? pomyślałem (nawet zainstalowany), ale patrzę i faktycznie. Zamiast tego pojawił się Ver.4.30.16 (Build 2), który w release notes ma dokładnie taki sam opis. Jak będę przy kompie, gdzie mam pobrany Ver.4.30.16 (Build 4), to sprawdzę, czy są identyczne binarnie. Stay tuned.

Co prawda nadal nie sprawdziłem czy się różnią, ale proponowana wersja zależy od tego, czy pozwolimy się przekierować ze strony dla US, czy nie.