REJECT è più bello per le altre persone: se la connessione è il risultato di un errore onesto (un errore di configurazione), chiunque abbia provato ad avviare una connessione riceve la risposta approvata dagli standard che nessuno sta ascoltando su quella porta. Con DROP, non viene restituito nulla, quindi chiunque stia tentando di connettersi attenderà fino a quando non si annoierà.
Mentre REJECT sembra migliore per la risoluzione dei problemi, si può fare un caso su come DROP sia effettivamente migliore per il tracciamento dei bug. In effetti, immagina un sistema client che possa connettersi a diversi server, finché non si trova uno che risponde correttamente (in un modo simile ai server DNS). Se il primo server nell'elenco non è configurato correttamente, ma viene utilizzato un REJECT, gli utenti umani non noteranno nulla: ogni tentativo proverà a quel server e verrà prontamente risposto con un pacchetto di errore e il sistema client si connetterà immediatamente al secondo server . Una situazione del genere può essere in vigore per molto tempo, poiché l'utente umano non vede nulla di sbagliato. D'altra parte, con un criterio DROP, l'errata configurazione si presenta come un ritardo di timeout per ogni richiesta, che indurrà l'utente umano a indagare.
In effetti, nel mio lavoro quotidiano, dove devo indagare regolarmente su tali problemi (*), il ritardo derivante da una cattiva configurazione DNS da qualche parte è spesso uno strumento inestimabile per individuare il problema.
Per un PC personale , un punto tecnico aggiuntivo è asimmetria . In particolare, un PC domestico con un accesso a Internet di solito ottiene molta più larghezza di banda di download rispetto al caricamento (che è "A" in ADSL ). Quando qualcuno invia al PC un tentativo di connessione (un SYN TCP), questo utilizza una piccola parte della larghezza di banda del download. Tuttavia, se il tuo PC risponde con un rifiuto (un RST TCP), allora questa risposta userà un po 'della tua larghezza di banda upload . Questo apre la possibilità di un facile negazione del servizio : se hai 10 download di Mbs e 1 Mbs carica la larghezza di banda e usa il "bello" REJECT, quindi l'hacker deve solo inviarti circa 1 pacchetto SYN da 1 Mbs per saturare la tua rete, indipendentemente dal fatto che debba inviare dieci volte di più se DROP.
In questo senso, DROP è probabilmente migliore di REJECT su base generale, almeno per un PC di casa. O, forse ancora meglio, una politica di limitazione della velocità che si comporta come REJECT fino a qualche soglia e DROP in seguito (ad esempio non più di 10 pacchetti RST restituiti al secondo); Non so se iptables possa essere facilmente configurato per farlo.
(*) Nominalmente dovrei aiutare a progettare alcuni sistemi pelosi relativi a PKI, ma in pratica passo molto tempo facendo questo .