Czy tcpdump omija iptables?

Przez pomyłkę skonfigurowałem otwarty serwer rozpoznawania nazw DNS, który wkrótce został użyty do wielu ataków DDoS pochodzących z / do Rosji. Z tego powodu całkowicie zablokowałem port 53 na obu serwerach DNS dla wszystkich oprócz zaufanych adresów IP. Działa, nie mogę się już z nimi połączyć, ale wydaje mi się dziwne, że kiedy uruchamiam tcpdump na eth1 (który jest interfejsem na serwerze z publicznym Internetem), widzę wiele przychodzących pakietów od atakującego do portu 53.

Czy to normalne, że tcpdump wyświetla te pakiety, nawet jeśli iptables je upuszczą? A może źle skonfigurowałem iptables?

Z drugiej strony nie widzę żadnych wychodzących pakietów z mojego serwera, co zrobiłem wcześniej, więc przypuszczam, że zapora działa. Dziwi mnie tylko to, że jądro nie upuszcza pakietów całkowicie? A może jest tcpdumppodłączony do jądra w taki sposób, że widzi pakiety jeszcze zanim przejdą do iptables?

To miłe pytanie.

W rzeczywistości, tcpdump jest pierwszym oprogramowaniem występować po drucie (i NIC, jeśli będzie) na drodze IN , a ostatni na drodze OUT .

Wire -> NIC -> tcpdump -> netfilter/iptables

iptables -> tcpdump -> NIC -> Wire

W ten sposób widzi wszystkie pakiety docierające do interfejsu i wszystkie pakiety opuszczające interfejs. Ponieważ pakiety do portu 53 nie otrzymują odpowiedzi, co widać w tcpdump, pomyślnie sprawdziłeś, czy reguły iptables zostały poprawnie skonfigurowane.

EDYTOWAĆ

Być może powinienem dodać kilka szczegółów. tcpdump jest oparty na bibliotece libpcap , która tworzy gniazdo pakietów . Kiedy w stos sieciowy odbierany jest zwykły pakiet, jądro najpierw sprawdza, czy gniazdo jest zainteresowane nowo przybyłym pakietem, a jeśli istnieje, przesyła pakiet do tego gniazda. Jeśli wybrana jest opcja ETH_P_ALL , wszystkie protokoły przechodzą przez gniazdo pakietu.

libpcap implementuje jedno takie gniazdo pakietu z aktywowaną opcją, zachowuje kopię do własnego użytku i duplikuje pakiet z powrotem na stos sieciowy, gdzie jest przetwarzany przez jądro w zwykły sposób, włączając przekazywanie go najpierw do netfilter , jądra -przestrzeń odpowiednik iptables . To samo, w odwrotnej kolejności ( tzn. Najpierw filtr sieciowy, a następnie przejście przez gniazdo pakietu), w drodze do wyjścia.

Czy to jest skłonne do hakowania? Ale oczywiście. Z pewnością istnieją rootkity typu proof-of-concept używające libpcap do przechwytywania komunikacji przeznaczonej dla rootkita, zanim zapora sieciowa będzie mogła położyć na nich rękę. Ale nawet to blednie w porównaniu z faktem, że proste zapytanie Google wykrywa działający kod, ukrywający ruch nawet przed libpcap . Mimo to większość specjalistów uważa, że ​​zalety znacznie przewyższają wady debugowania filtrów pakietów sieciowych.