Prawidłowa jest opcja „Filtruj anonimowe żądania dotyczące Internetu”, bo właśnie ona ogranicza widoczność rutera z zewnątrz i utrudnia przeprowadzenie skutecznego ataku DDoS. W praktyce oznacza to, że router nie odpowiada na pewne typy pakietów przychodzących z Internetu (np. ping/ICMP echo czy skanowanie portów), jeśli nie są one powiązane z istniejącą sesją lub zainicjowane od strony sieci lokalnej. Z punktu widzenia napastnika taki router jest „mniej atrakcyjnym celem”, bo trudniej go wykryć, zidentyfikować jego usługi i przygotować masowy atak zalewający. W wielu domowych i małych firmowych routerach ta funkcja jest opisana jako „Block Anonymous Internet Requests”, „Stealth Mode” albo podobnie i jest zalecana do włączenia w dobrych praktykach bezpieczeństwa sieci brzegowej. Moim zdaniem to jedna z tych opcji, które powinno się mieć domyślnie aktywne, chyba że świadomie administrujesz jakąś usługą publiczną i wiesz, co robisz. W połączeniu z zaporą SPI (Stateful Packet Inspection) oraz poprawnie skonfigurowanym NAT-em, filtr anonimowych żądań pomaga ograniczać skutki prostszych form DDoS, zwłaszcza tych opartych na masowym pingowaniu czy skanowaniu. Oczywiście nie zabezpieczy to całkowicie przed dużym, rozproszonym atakiem na łącze, bo przepustowości nie oszukasz, ale zgodnie z dobrymi praktykami bezpieczeństwa należy minimalizować powierzchnię ataku – i dokładnie to robi ta opcja. W realnym środowisku administracyjnym przy audycie bezpieczeństwa zawsze sprawdza się, czy router brzegowy nie odpowiada bez potrzeby na niezamówione pakiety z Internetu, a ta funkcja jest jednym z kluczowych przełączników w tym obszarze.
Intuicyjnie wiele osób kojarzy różne opcje filtrowania w panelu rutera z bezpieczeństwem i łatwo założyć, że każda z nich w jakiś sposób chroni przed atakami DDoS. W rzeczywistości jednak te ustawienia mają różne cele i nie wszystkie są powiązane z ochroną przed masowym zalewaniem ruchem. Filtracja komunikatów typu multicast dotyczy głównie ruchu wewnątrz sieci lokalnej, np. transmisji IPTV, protokołów automatycznego wykrywania urządzeń czy różnych usług sieciowych. Jej zadaniem jest ograniczenie niepotrzebnego rozgłaszania pakietów do wszystkich hostów w LAN, co wpływa na wydajność i porządek w sieci, ale nie stanowi realnej bariery dla ataku DDoS z Internetu na interfejs WAN. To bardziej kwestia optymalizacji ruchu niż klasyczne bezpieczeństwo perymetryczne. Podobnie opcja filtrowania protokołu IDENT (port 113) dotyczy bardzo konkretnej, historycznej usługi identyfikacji użytkownika, używanej kiedyś m.in. przez niektóre serwery IRC czy pocztowe. Zablokowanie tego portu jest sensowne ze względów bezpieczeństwa i prywatności, ale nie ma związku z typowymi scenariuszami DDoS – napastnicy nie potrzebują portu 113, żeby zalać łącze lub wyczerpać zasoby urządzenia. To raczej dokładanie kolejnej cegiełki do ogólnej polityki zamykania nieużywanych portów. Filtr przekierowań internetowych NAT tylko dla IPv4 bywa nieco mylący. NAT i przekierowania portów służą do wystawiania usług z sieci LAN do Internetu. Ograniczenie lub filtrowanie tych przekierowań może zmniejszyć liczbę dostępnych z zewnątrz usług, co ogólnie jest dobre z punktu widzenia bezpieczeństwa, ale samo w sobie nie jest mechanizmem anty-DDoS. Ataki rozproszone bardzo często celują w sam adres IP lub w otwarty, dozwolony serwis (np. HTTP, HTTPS), a nie w sam mechanizm NAT. Typowym błędem myślowym jest założenie, że „im więcej filtrów, tym lepiej przeciwko DDoS”, bez zrozumienia, jaki typ ruchu dana opcja faktycznie blokuje. W ochronie przed DDoS kluczowe jest ograniczanie anonimowych, niezamówionych żądań z Internetu, stosowanie zapór stanowych, ewentualnie filtrów po stronie operatora lub usług typu scrubbing center. Pozostałe wymienione opcje mogą poprawić ogólne bezpieczeństwo lub porządek w sieci, ale nie są bezpośrednią odpowiedzią na problem ataków DDoS, dlatego wybór ich jako głównego mechanizmu ochrony jest merytorycznie chybiony.