REJECT vs DROP quando si utilizza iptables

C'è qualche motivo per cui vorrei avere

iptables -A INPUT -j REJECT

invece di

iptables -A INPUT -j DROP

Come regola generale, usa REJECT quando vuoi che l'altra estremità sappia che la porta non è raggiungibile 'usa DROP per le connessioni agli host che non vuoi che le persone vedano.

Di solito, tutte le regole per le connessioni all'interno della LAN dovrebbero usare REJECT. Per Internet, ad eccezione di ident su alcuni server, le connessioni da Internet vengono generalmente DROPPED.

L'uso di DROP fa sembrare che la connessione sia indirizzata a un indirizzo IP non occupato. Gli scanner possono scegliere di non continuare la scansione degli indirizzi che sembrano non occupati. Dato che NAT può essere utilizzato per reindirizzare una connessione sul firewall, l'esistenza di un servizio ben noto non indica necessariamente l'esistenza di un server su un indirizzo.

Ident dovrebbe essere passato o rifiutato su qualsiasi indirizzo che fornisce il servizio SMTP. Tuttavia, l'uso delle ricerche Ident da parte dei servizi SMTP è fallito. Esistono protocolli di chat che si basano anche su un servizio ident funzionante.

EDIT: Quando si utilizzano le regole DROP: - I pacchetti UDP verranno eliminati e il comportamento sarà lo stesso della connessione a una porta non protetta da firewall senza alcun servizio. - I pacchetti TCP restituiranno un ACK / RST che è la stessa risposta con cui risponderà una porta aperta senza servizio. Alcuni router risponderanno con e ACK / RST per conto dei server inattivi.

Quando si utilizzano le regole REJECT viene inviato un pacchetto ICMP che indica che la porta non è disponibile.

La differenza è che il target REJECT invia una risposta di rifiuto alla sorgente, mentre il target DROP non invia nulla.

Questo può essere utile ad es. Per il servizio ident. Se si utilizza REJECT, i client non devono attendere il timeout.

Maggiori informazioni su questo: http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html

Di solito, si desidera ignorare le sonde dagli aggressori a determinate porte, il che significa che non si desidera inviare nuovamente "connessione rifiutata". "Connessione rifiutata" significa: "c'è un server qui" e probabilmente fornisce più informazioni, mentre l'eliminazione di un pacchetto non fornisce indizi sulle versioni del software, sulle possibili vulnerabilità o persino sul fatto che un server stia ascoltando il tuo IP.

Quanto sopra è uno dei motivi principali per utilizzare DROP invece di REJECT.

Vedo molte risposte contrastanti qui e dato questo è il primo articolo su Google con le parole chiave giuste; ecco la spiegazione corretta.
È semplice:

DROP non fa nulla con il pacchetto. Non viene inoltrato a un host, non riceve risposta. La manpage di IPtables dice che lascia cadere il pacchetto sul pavimento, cioè non fa nulla con il pacchetto.

REJECT differisce da DROP per il fatto che restituisce un pacchetto, ma la risposta è come se un server si trovasse sull'IP, ma non abbia la porta in uno stato di ascolto. IPtables invierà un RST / ACK in caso di TCP o con UDP una porta di destinazione ICMP non raggiungibile.

Se stai cercando di nascondere completamente l'esistenza della tua macchina, -j DROPè appropriato. Ad esempio, è possibile utilizzare questo per implementare una lista nera.

Se stai cercando di nascondere il fatto che una porta è aperta, dovresti imitare il comportamento che si verificherebbe se la porta non fosse aperta:

• TCP: -p tcp -j REJECT --reject-with tcp-reset
• UDP: -p udp -j REJECT --reject-with icmp-port-unreachable

Se uno scanner di porte rileva che alcune porte rilasciano pacchetti mentre la maggior parte li rifiuta, può presumere che i pacchetti rilasciati si trovino su porte aperte ma nascoste.

Nonostante le molte risposte corrette, solo i miei due centesimi:

Ecco un breve PoC FW.IDS-DROP-vs-REJECT di me sull'argomento per quanto riguarda le regole per il ban-system (firewall, IDS, ecc.).

In breve:

• DROP può essere utilizzato per intrusi recidivi, se vieta tutte le porte (quindi sembra che il server sia inattivo sul lato intruso)
• REJECT --reject-with tcp-reset è la scelta migliore per il divieto multi-porta, perché sembra comportarsi come una vera porta chiusa
• se alcune porte stanno rispondendo (l'intruso sa che l'host è vivo) DROPe REJECT(senza tcp-reset) darà all'intruso un "segnale" che c'è qualcosa di bloccante (in modo che possa stimolarlo a continuare l '"attacco" nella speranza di fornire i dati richiesti ad un certo punto)

Sì, l'uso di DROP non ha senso. Usa REJECT.

Anche quando la regola dice "DROP" il sistema risponde ancora a un SYN in arrivo con un TCP RST / ACK - che è il comportamento predefinito per le porte senza servizi in esecuzione. (tcpdump et al non registrano questo.)

Se un servizio è in esecuzione, SYN viene soddisfatto con TCP SYN / ACK.

Poiché il DROP non risponde come di consueto con un TCP SYN / ACK, ma con un RST / ACK, la tua regola DROP pubblicizzerà il tuo firewall e gli scanner delle porte sapranno che stai firewalling qualcosa e potrebbero continuare a martellarti nelle speranze di abbattere il firewall.

Questo è ora nmap può segnalare "filtrato" anziché "chiuso", ad esempio:

$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -I INPUT -p tcp --dport 1111 -j DROP
$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
1111/tcp filtered lmsocialserver

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -D INPUT 1

Pertanto, l'unica configurazione "invisibile" del firewall è quella in cui un dispositivo dedicato si trova tra i dispositivi e inoltra selettivamente le porte.

Se vuoi davvero scherzare con gli scanner di base, puoi TARPIT connessioni tcp, che imposta la finestra TCP su 0 in modo che nessun dato possa essere trasferito dopo l'apertura della connessione, ignorando le richieste di chiusura della connessione, il che significa che lo scanner deve attendere affinché si verifichi il timeout della connessione, se vuole essere sicuro. Ma è insignificante per un attaccante rilevare questo e rendere il suo timeout molto breve.

Tutto sommato, probabilmente stai meglio usando semplicemente REJECT o mettendo un dispositivo di port forwarding dedicato tra il tuo server e Internet.

O semplicemente eseguendo servizi sui tuoi computer con connessione a Internet che non richiedono firewall.

In genere REJECT è la soluzione migliore per i server Web, poiché qualunque servizio stia tentando di accedervi (probabilmente il più delle volte, tu) riceverà rapidamente una risposta e gli utenti o altri servizi non continueranno ad aspettare chiedendosi se c'è un'interruzione della rete.