Dlaczego hakerzy mieliby atakować serwer DNS za pomocą DoS?
Budzę się dziś rano na zrestartowanym serwerze. Serwer DNS działał na ponad 100%. Po odrobinie pracy dostałem fail2ban, aby zablokować wszystkie te żądania.
Same żądania są ważne, powtarzane setki razy na sekundę. Gdy blok otrzyma wiele (sto) adresów IP, widzę, że co kilka godzin blokuję 1 milion trafień UDP.
Czy to tylko atak [D] DoS? (prawdopodobnie uważany za dynamiczny, ponieważ w grę wchodzi wiele komputerów, a gdy jeden został zablokowany wystarczająco długo, wygląda na to, że zatrzymuje żądania)
Inną możliwością, o której przychodzi mi do głowy, jest to, że osoba atakująca próbuje zawiesić serwer DNS i uzyskać dostęp po ponownym uruchomieniu lub awarii całego komputera i próbie połączeń z innymi usługami. (tj. jeśli nie wiesz, jak zainstalować zaporę ogniową przed uruchomieniem usług)
Od czasu ostatniego resetu zapory, oto moje statystyki:
Odsłon: 2,346,742
Liczba IP: 473
To idzie szybko. Kilkaset uderzeń na sekundę. Liczba adresów IP nie rośnie jednak zbytnio.
Odpowiedzi
Na podstawie komentarza @ Schroeder przeprowadziłem dodatkowe wyszukiwania i dowiedziałem się znacznie więcej o tego typu atakach.
Byłem celem!
Przede wszystkim wygląda na to, że jestem celem ataku. Czemu? Ponieważ atak DNS Amplification oznacza, że port źródłowy żądań DNS jest ustawiony na 53. Umożliwia to wymuszenie na moim serwerze DNS wysłania odpowiedzi, o którą nie żądano, do innego serwera (patrz wykres poniżej). Ponieważ mam mniej niż 0,1% takich trafień korzystających z tego portu, nie sądzę, że mój DNS był używany do wzmocnienia, ale raczej, że był celem.
Jak działa atak?
Atakujący konfiguruje komputer z oprogramowaniem wysyłającym pakiety UDP do niektórych losowych serwerów DNS z prośbą o podanie nazwy domeny. Pakiet wygląda normalnie, z wyjątkiem faktu, że atakujący jako źródło podaje adres IP innego komputera zamiast swojego adresu IP. W rezultacie DNS wysyła odpowiedź do niewłaściwego komputera :
10.0.0.1 10.0.0.2 10.0.0.3
+------------+ +------------+ +------------+
| | | | | |
| Attacker +-->| Some DNS +-->| Me |
| | | | | |
+------------+ +--+---------+ +------------+
| ^
v |
+---------+--+ This step is not required, it happens if
| | your DNS is setup to accept recursive
| Master DNS | requests (which is not a good idea)
| |
+------------+
10.0.0.4
W powyższym przykładzie żądanie atakującego powinno mieć 10.0.0.1 jako adres źródłowy UDP. Zamiast tego atakujący zmienia swój adres IP na 10.0.0.3. W rezultacie, gdy DNS w 10.0.0.2 odbierze pakiet UDP i jest gotowy do wysłania odpowiedzi, wysyła dane do 10.0.0.3.
Główny DNS domeny będzie używany, jeśli DNS pod adresem 10.0.0.2 nie wie nic o pytanej nazwie domeny.
WAŻNA UWAGA: Dotyczy to wszystkich usług UDP. DNS jest prawdopodobnie najgorszy pod względem amplifikacji, ale na przykład NTP może być również celem.
Dlaczego po prostu nie zweryfikować adresu źródłowego?
Nie jest to możliwe od wersji 10.0.0.2, ponieważ UDP nie pamięta prawdziwego źródła pakietu.
Dostawcy usług internetowych mogą sprawdzić, czy wszystkie pakiety wychodzące z danego komputera mają adres IP tego komputera. Myślę, że niektórzy tak, ale najprawdopodobniej nie. Ma niewielki wpływ na szybkość ... z czego oczywiście można się śmiać przy wzmocnieniu DNS (wzmocnienie DNS ma o wiele gorszy wpływ na Internet niż małe sprawdzenie pochodzenia pakietów UDP).
Inną rzeczą może być to, że użytkownik nadal może być w stanie połączyć się z Internetem w taki sposób, że omija weryfikację dostawcy usług internetowych. Nie wiem, czy i / lub jak byłoby to możliwe, ale nie zdziwiłbym się, że można to zrobić.
W rzeczywistości jest to bardzo problematyczne, ponieważ pochodzenie takich ataków jest trudne do wyśledzenia iz pewnością dlatego nadal występują masowo.
Dlaczego to DDoS?
Pakiet żądający rekordu DNS, który tak się dzieje, jest bardzo mały, może 300 bajtów. Zatem atakujący musi wysłać tylko jeden mały pakiet UDP.
Odpowiedź może jednak obejmować wiele kilobajtów danych. W szczególności istnieje domena, która jest używana w tych atakach:
peacecorps.gov
a ta domena zwraca ponad 3 KB danych! (Definiuje wiele pól „TXT”, które są używane w tym ataku wzmacniającym.) Dlatego nazywa się to atakiem wzmacniającym.
W rezultacie żądania od atakującego są przekształcane w około 10 razy większe odpowiedzi, a atakowany komputer (10.0.0.3) zostaje zasypany dużą liczbą dość dużych pakietów UDP.
Tutaj pokazuję wynikowy wpis w iptables. Pierwsza liczba oznacza liczbę trafień na mój komputer DNS po około 40 minutach (czyli ponad 10000 trafień na minutę ...):
pkts bytes target prot opt in out source destination
61637 4376227 DROP udp -- eno1 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 STRING match "|0a7065616365636f72707303676f76|" ALGO name bm TO 65535
Zwróć również uwagę, jak ciąg został w pełni przekształcony w liczby szesnastkowe.
Czy żądanie HTTP nie byłoby jeszcze gorsze ?!
HTTP 0.9 / 1.0 / 1.1 / 2 używa protokołu TCP, który jest protokołem dwukierunkowym i nie można generować wzmocnienia za pomocą protokołu TCP. tj. TCP zrywa, jeśli nie połączyłeś się poprawnie z pełnym uzgadnianiem.
Jednak HTTP / 3 wprowadza protokół QUIC , który jest HTTP przez pakiety UDP. Jak dotąd nie słyszałem o poważnych problemach z QUIC, ale protokół bardzo się zmienił w ciągu ostatnich 6-7 lat i nie jest jeszcze powszechnie wdrażany. Oto artykuł o tym, że QUIC ma wbudowane funkcje zapobiegające atakom amplifikacji, więc jest nadzieja, że zadbano o to.
Niektórzy mówią o używaniu HTTP do zapytań o nazwy domen. (DoH - domena przez HTTP). Miejmy nadzieję, że nie zostałby zaimplementowany przy użyciu QUIC ...
Jak mogę rozwiązać ten problem?
Wzmocnienie ma miejsce, ponieważ Twój DNS jest skonfigurowany tak, aby akceptować żądania nazw domen, których nie kontrolujesz (tj. Domen, których nie jesteś właścicielem).
BIND ma opcję, która umożliwia mu wzmocnienie, które w języku DNS nazywa się rekursją. Ta funkcja jest teraz domyślnie wyłączona, ale być może została włączona (przez pomyłkę?).
Oto złe ustawienie :
allow-recursion { any; };
Chcesz użyć poprawnych ustawień :
trusted-servers { 192.0.2.4; } // list all your trusted servers
allow-recursion { trusted-servers; };
Spowoduje to, że serwer automatycznie odrzuci wszystkie takie żądania. Jeśli więc nie peacecorps.govjesteś i otrzymasz takie żądanie, BIND po prostu zatrzyma się w tym miejscu i zapisze notatkę w dziennikach DNS o odrzuconym żądaniu.
Czy mogę zablokować adres IP przed tymi żądaniami?
Tak. Zacząłem od tego, ponieważ mój serwer działał znacznie ponad 100% czasu procesora. Jednak może to nie być rozsądne. Na powyższym obrazku widać, że Twój serwer DNS znajduje się między napastnikiem a ofiarą. Jeśli zablokujesz źródłowy adres IP, to nie adres IP atakującego, który blokujesz, to adres ofiary. Oznacza to, że faktycznie uniemożliwiasz ofierze zobaczenie nazw domen i wykonanie uzasadnionych żądań. Prawdopodobnie nie tego chcesz!
Najpierw wygenerowałem komunikat dziennika z mojej zapory. Gdybym miał wykryć 5 lub więcej żądań do portu 53 (UDP) z tego samego adresu IP w krótkim czasie (5 sekund), zablokowałbym ten adres IP. Aby to zrobić, użyłem fail2ban.
Najpierw mam filtr, który wykrywa połączenia z UDP i portem 53 jako miejscem docelowym:
# Filter: /etc/fail2ban/filter.d/named-fast-requests.conf
[Definition]
failregex = \sIN=[a-z0-9]+ .* SRC=<HOST> .* PROTO=UDP .* DPT=53\s
Po drugie, mam więzienie, które podaje inne parametry:
# Jail: /etc/fail2ban/jail.d/named-fast-requests.conf
[named-fast-requests]
enabled = true
filter = named-fast-requests
action = named-action[scheme=all,period=year,reason=named fast requests]
logpath = /var/log/iptables/iptables.log
maxretry = 5
findtime = 5
bantime = 1036800
Głównym punktem jest tutaj ustawienie maxretryi, findtimektóre są ustawione na 5 razy w ciągu 5 sekund lub mniej. Kiedy tak się stanie, blokuję <HOST>.
Będziesz chciał zaktualizować akcję własną rzeczą. Używam iplocktutaj własnego narzędzia. Polecenie, którego używam w akcji:
actionban = /usr/sbin/iplock -s named -b <ip>
Domyślnie fail2ban używa iptablesbezpośrednio. Przeszukaj ich działania, aby zobaczyć, jak to się robi.
Nie bądź źródłem wzmocnienia
Powinieneś blokować żądania, których źródłowy port UDP jest mniejszy niż 1024. Te są nieprawidłowe. Jeśli oferujesz serwer, port 53 będzie portem docelowym, a nie źródłowym.
iptables -I INPUT 123 -i eth0 -p udp -m udp --sport 0:1023 -j DROP
UWAGA: zastąpić pozycję (123) prawidłowym numerem!
Ta reguła mówi, że dla każdego przychodzącego pakietu UDP eth0, który ma port źródłowy między 0 a 1023, odrzuca pakiet. Zapobiega to używaniu twojego serwera DNS do wzmocnienia. Jednak nie chroni to twojego własnego serwera przed wzmocnieniem od innych. Zwróć uwagę, że nawet przy prawidłowej allow-recursionkonfiguracji nie zapobiegniesz atakowi polegającemu na wzmocnieniu, jeśli osoba atakująca prawidłowo wybierze jedną z nazw domen do ataku.
Uwaga: jeśli określisz inny serwer nazw do rozwiązywania nazw domen na swoim komputerze, możesz chcieć otworzyć te połączenia, zanim zablokujesz wszystko od portu 0 do 1023. To byłoby mniej więcej tak:
iptables -I INPUT 123 -i eth0 -p udp -m udp --sport 53 -s 8.8.8.8 \
-d <your-static-ip> -j ACCEPT
To są dane zwrócone z serwera nazw 8.8.8.8, które prawdopodobnie chcesz otrzymać. Nie jest prawdopodobne, aby Twój dostawca lub inny oficjalny serwer nazw był bezpośrednim źródłem ataku UDP. Jeśli nie masz statycznego adresu IP, nie musisz uwzględniać tej -dopcji.
Jednak prawdopodobnie dużo lepiej jest skorzystać z ESTABLISHEDfunkcji, która jest teraz dostępna dla wiadomości UDP (już od jakiegoś czasu, ale pamiętam czasy, kiedy to nie było dostępne ...):
iptables -I INPUT 123 -i eth0 -p udp -m state \
--state ESTABLISHED,RELATED -m udp -d <your-static-ip> -j ACCEPT
Oznacza to, że automatycznie zaakceptujesz odpowiedzi od dostawcy serwera nazw domen, ponieważ zapora sieciowa będzie wiedzieć, że wysłałeś żądanie i chcesz zaakceptować odpowiedzi. Ta reguła musi pojawić się przed DROPpowyższą regułą.
Wczesne odrzucanie niechcianych żądań
Oczywiście posiadanie przez BIND akceptacji wszystkich tych żądań peacecorps.govnie jest czymś, czego nikt by nie chciał. W rzeczywistości możesz zablokować je bezpośrednio w zaporze. Działa to, ponieważ pakiety UDP nie są szyfrowane, więc nazwa domeny jest widoczna.
Oto reguła, której można użyć, aby zablokować te żądania nazwy domeny:
sudo iptables -I INPUT 123 -i eno1 -p udp -m udp --dport 53 \
-m string --hex-string "|0A|peacecorps|03|gov|" --algo bm -j DROP
Oczywiście, jeśli Twój DNS ma jakąkolwiek domenę lub subdomenę, w tym „peacecorps.gov”, nie powinien używać tej iptablesreguły. Dla większości z nas, choć powinno to być rzadkie.
Ta --hex-stringopcja umożliwia określenie ciągu. Sposób, w jaki jest zdefiniowany w pakiecie UDP, wykorzystuje postać ciągu P (rozmiar + dane). Ponieważ „peacecorps” ma 10 znaków, wstawiamy przed nim 0x0A. Ponownie „gov” składa się z trzech liter, więc używamy 0x03. Gdybyśmy mieli użyć ciągu „peacecorps.gov”, to nie zadziałałoby, ponieważ kropka nie pasowałaby do bajtu 0x03. Jednak pierwszy rozmiar jest opcjonalny (chociaż można dopasować wszystko, co wygląda tak samo, np. „Bestpeacecorps”).
Posiadanie takiej reguły zaoszczędzi Twojej usłudze nazw domen mnóstwo całkowicie niechcianego ruchu.
Update: Chociaż atak zatrzymał się o dwa tygodnie po tym, jak pisał moje pytanie, w „peacecorps.gov” problem nadal zdarza się około 10 razy dziennie.
Źródło: https://defragged.org/2020/05/20/tips-and-tricks-blocking-dns-requests-via-iptables/
Debugowanie DNS
Aby zobaczyć, jakie zapytanie otrzymuje serwer DNS i na które odpowiada, możesz uruchomić następujące polecenia w konsoli:
sudo rndc querylog
Teraz spójrz na dzienniki, zwykle tutaj:
less /var/log/named.log
Spójrz na dole (trafienie Gw less) i należy rozpocząć widząc zapytań ze zdalnych adresów IP. Dzienniki zawierają nazwę sprawdzanej domeny. Jest to bardzo praktyczne, zwłaszcza jeśli przegapiłeś wpisanie niektórych własnych nazw domen w drugorzędnym lub trzeciorzędnym DNS.