Ma che bello, l'ennesima porta da bloccare per evitare bypass... Grazie, mi era sfuggita. EDIT pero' e' 853 quella definitiva in RFC 9250, non 8853...
LucaTheHacker Conosco gente che lo ha fatto per farsi sbloccare dei DNS aziendali e si è vista arrivare una risposta negativa.
Che vuoi che ti dica? Cioe', sul forum di PF ci sono invece testimonianze, pubbliche, che dimostrano quel che dicevo io...
LucaTheHacker Peccato che un blocco sulla 25 sia comprensibile ed accettabile, un blocco sulla 53 e sulla 443 un po' meno, almeno per quanto mi riguarda.
Io invece preferisco un blocco costante piuttosto che uno intermittente come mi sembra proponessi tu prima... Almeno so che o cambiando porta o facendomi whitelistare il problema e' risolto sempre, e non a volte.
Cmq boh, non so te, ma io in passato ho avuto modo di mitigare alcuni DDoS in entrata (gigabit simmetrica su altro provider un po' di anni fa, DDoS volumetrici da 800 Mbps, nulla di che) e uno dei filtri statici piu' appropriati per non floodare male i """firewall""" a valle (che servivano pezzi di rete che non gestivo io purtroppo, e che per la tua gioia erano dei bellissimi TP-Link """enterprise""" con porte Fast Ethernet... 🤦) era proprio quello che andava a droppare pacchetti UDP con porta sorgente 53 e 443, visto che si trattava di flood di tanti pacchetti con IP sorgente spoofati e con molte poche altre caratteristiche in comune, tra cui pero' guarda caso proprio queste due porte sorgenti.
Per cui personalmente io questi filtri statici li ritengo una contromisura appropriata e molto efficace nella pratica, per quanto "brutti" teoricamente possano essere. Cioe', lamentiamoci piuttosto con gli script kiddies o come li chiamano oggi che hanno programmato in questa maniera i "cannoni" delle botnet... (E in realta' non lamentiamoci neanche troppo, che io preferisco 2 porte e basta piuttosto che tutte e 65536... [si', compresa la 0 perche' e' una porta valida, solo che non si puo' scegliere con le API UNIX/BSD dei socket]) 😉
