È meglio impostare -j REJECT o -j DROP in iptables?

C'è un esempio delle regole di iptables sul wiki di archlinux:

# Generated by iptables-save v1.4.18 on Sun Mar 17 14:21:12 2013
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
COMMIT
# Completed on Sun Mar 17 14:21:12 2013

Qualche giorno fa il mio amico mi ha chiesto perché c'è REJECTnelle ultime tre regole. Mi ha detto che ci dovrebbe essere DROPinvece, e ha menzionato qualcosa su una migliore sicurezza in caso di DROP.

Quindi, ho due domande:

Cosa fanno le tre regole?
Fa differenza quando li metto DROPsul posto REJECT --reject-with? Se sì, qual è la differenza?

— Mikhail Morfikov
fonte

Domanda simile sulla sicurezza delle informazioni : rifiutare i pacchetti IP con un errore ICMP o semplicemente rilasciarli?

— Gilles 'SO- smetti di essere malvagio' il

Cosa fanno le tre regole?

Queste 3 regole sembrano piuttosto autoesplicative:

Rifiuta i pacchetti UDP in arrivo con un messaggio ICMP "porta non raggiungibile"
Rifiuta i pacchetti TCP in arrivo con "tcp reset"
Rifiuta i pacchetti in arrivo (di qualsiasi altro protocollo) con il messaggio ICMP "protocollo non raggiungibile"

Se stai cercando maggiori dettagli (sui pacchetti UDP / TCP, ICMP), devi scavare nei documenti di rete e forse man iptablesanche.

Fa differenza quando inserisco DROP in posizione REJECT --reject-with? Se sì, qualcuno potrebbe spiegarmi la differenza, lo apprezzerò davvero.

Fa la differenza. E contrariamente alla credenza popolare, DROPnon offre una sicurezza migliore di REJECT. Inconveniente agli utenti legittimi e in realtà non è una protezione da quelli dannosi. Questo post spiega in dettaglio il ragionamento:

http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

Un motivo comune per utilizzare DROP piuttosto che REJECT è evitare di fornire informazioni su quali porte sono aperte, tuttavia, scartare i pacchetti fornisce esattamente quante più informazioni del rifiuto.

Con REJECT, esegui la scansione e classifica i risultati in "connessione stabilita" e "connessione rifiutata".

Con DROP, classifichi i risultati in "connessione stabilita" e "connessione scaduta".

Lo scanner più banale utilizzerà la chiamata "connetti" del sistema operativo e attenderà il completamento di un tentativo di connessione prima di iniziare il successivo. Questo tipo di scanner verrà notevolmente rallentato facendo cadere pacchetti. Tuttavia, se l'attacco imposta un timeout di 5 secondi per tentativo di connessione, è possibile scansionare tutte le porte riservate (1..1023) su una macchina in sole 1,5 ore. Le scansioni sono sempre automatizzate e a un utente malintenzionato non importa che il risultato non sia immediato.

Uno scanner più sofisticato invierà i pacchetti stessi anziché fare affidamento sull'implementazione TCP del sistema operativo. Tali scanner sono veloci, efficienti e indifferenti alla scelta di REJECT o DROP.

CONCLUSIONE

DROP non offre alcuna barriera efficace alle forze ostili ma può rallentare notevolmente le applicazioni gestite da utenti legittimi. DROP non dovrebbe essere normalmente utilizzato.

— Smetti di far del male a Monica
fonte

@janos: potresti scrivere qualcosa in più su ciò che accade realmente quando un pacchetto raggiunge ciascuna delle tre regole?

— Mikhail Morfikov,

@Kiwy: leggi il link e provalo tu stesso. DROP non offre una sicurezza migliore di REJECT. Inconveniente agli utenti legittimi e in realtà non è una protezione da quelli dannosi. Questo perché gli utenti legittimi soffrono di una connessione lenta mentre attendono il timeout della connessione e i cracker si limitano a configurare i propri strumenti per non attendere un timeout. il fatto che la connessione sia lenta (a causa dell'attesa di un timeout) indica che il server è presente e protetto da firewall.

— Pantera

Non vado con questa conclusione. Rifiuta genera una risposta ICMP che può essere analizzata. Sulla base di questa analisi, i buoni motori di attacco possono derivare dal sistema operativo utilizzato. Quindi su un sistema in cui tutte le porte sono conosciute, la caduta potrebbe essere migliore. Questo vale per i server in un ambiente di produzione.

— Nils,

Un firewall che inoltra solo determinate porte è ancora migliore. DROP an REJECT non è la stessa cosa che nessun servizio esegue il primo posto. Molti scanner di porte contrassegnano il tuo host come potenziale obiettivo per future scansioni nella speranza di abbattere il firewall se trovano REJECTS o DROPS lì, poiché entrambi possono essere rilevati dall'esterno. chiark.greenend.org.uk/~peterb/network/drop-vs-reject

— Dagelf

Nota che il testo citato ha un altro paragrafo, un aggiornamento, che dice che DROP è meglio se hai un attacco DDoS, che è relativamente raro, ma quando succede, probabilmente è bene averlo ... cosa ne pensi?

— Alexis Wilke,