Drop vs Reject

Questo articolo non sarà specificatamente applicabile a pfSense, ma piuttosto ai firewalls in genere.
Molti firewalls hanno come impostazione predefinita il drop silente dei pacchetti al posto del reject per le regole di negazione del traffico. Ma qual è la differenza? E' veramente meglio il drop del reject?

Se non vi siete mai posti la domanda la risposta vi sorprenderà! Quindi non perdiamo altro tempo ed incominciamo.

Il controllo del traffico
I firewalls normalmente mettono a disposizione tre opzioni per il controllo del traffico:

• Pass o Accept: Lascia che il traffico passi;
• Block o Drop: Scarta il pacchetto in modo silente senza generare messaggi di risposta;
• Reject: Rifiuta il pacchetto e risponde con un pacchetto ICMP type3, code 13 (type=Destination Unreachable, Code=Communication administratively prohibited).

Cosa succede durante un port scan?

Uno scanner di rete identifica host e stato delle porte basandosi sulle risposte ricevute ai pacchetti sonda inviati al sistema. Le risposte che può ricevere sono due:

• TCP SYN/ACK: La porta è aperta;
• TCP RST/ACK: La porta è chiusa.

 Allargando il concetto a livello internet le risposte che si possono ottenere sono le seguenti:

• Host off-line: Viene restituito un pacchetto ICMP host unreachable dal router a monte;
• La rete a cui è collegato l'host è off-line: Viene restituito un pacchetto ICMP network unreachable dal router a monte;
• Un host o un firewall effettuano un reject: Viene restituito un pacchetto ICMP communication administratively prohibited;
•  Un host o un firewall effettuano un drop/block: Non viene restituito alcun pacchetto.

Fatte attenzione agli ultimi due comportamenti perchè riguardano proprio il drop ed il reject di un pacchetto. Se viene effettuato un drop, lo scanner non riceve nulla in risposta ai pacchetti sonda, mentre se viene effettuato un reject allora riceve un pacchetto ICMP di risposta.

Perchè i costruttori di firewalls preferiscono il Drop o Block?

Se provate a domandare ad un venditore perchè il comportamento predefinito del suo firewall è drop al posto del reject, molto probabilmente vi risponderà con queste due motivazioni:

1. Permette di nascondere meglio il firewall ed il suo IP;
2. Permette un minor consumo di banda.

Apparentemente queste due affermazioni sembrano avere un senso e sembrano essere vere, ma ora vi mostrerò come invece risultano essere decisamente false.

Il firewall è realmente nascosto con il drop?

La prima affermazione deriva dalla logica che se il firewall non restituisce alcun pacchetto ad un possibile attaccante, questo non sarà in grado di sapere che esiste. Se riguardiamo le quattro casistiche viste precedentemente vediamo che l'unico caso in cui uno scanner di rete non riceve risposte di ritorno è quando c'è un firewall che effettua un drop. Quindi il drop dei pacchetti non aiuta affatto a nascondere il firewall, ma comunica in modo inequivocabile che c'è un firewall. Per questo motivo tools come nmap quando non ricevono pacchetti di risposta indicano come "filtered" l'host su cui stavano attuando la scansione.

L'affermazione che il drop nasconde l'IP del firewall è solo parzialmente corretta perchè una volta scoperto che esiste un firewall che sta effettuando il drop dei pacchetti si può agevolmente sfruttare il trace route per scoprire l'IP del firewall.

Il drop permette realmente un minor consumo di banda?

Se si considera il fatto che il firewall che effettua il drop dei pacchetti non genera direttamente traffico l'affermazione sembra vera ma non tiene conto della natura e del protocollo TCP/IP basato sull'inaffidabilità della rete. Pertanto per ogni pacchetto che il nostro firewall blocca ne vengono ritrasmessi altri generando più traffico di un semplice pacchetto di RST/ACK.

Il drop favorisce lo spoofing

Uno dei maggiori problemi generati dall'uso del drop è il fatto di rendere il range dei vostri IP più attraenti per lo spoofing.

Consideriamo un tipico attacco SYN flood dove un attaccante cerca di sovraccaricare di richieste un server con richieste illegittime facendo in modo che questo non possa più rispondere alle richieste legittime. L'attaccante, per mantenere occupato il server, crea delle connessioni che vuole lasciare pendenti per tenere il server in attesa di risposta. Il modo migliore per raggiungere questo obiettivo è inviare dei pacchetti spoofed (pacchetti in cui l'IP del mittente è contraffatto) che consentono anche di mantenere l'identità dell'attaccante nascosta.

Quali IP sono più attraenti per effettuare spoofing? Sicuramente gli IP corrispondenti a firewalls che effettuano drop perchè non rispondendo ai pacchetti SYN/ACK che vedranno arrivare, manterranno il server attaccato in attesa di risposte che non arriveranno mai.

Quindi, ricapitolando, abbiamo visto come possa tornare comodo ad un attaccante individuare e sfruttare dei firewalls che fanno uso di drop per:

• Nascondere la vera entità dell'attaccante (anche se l'attacco avviene da host zombie è utile proteggerli);

• Far si che l'IP "spoffato" non risponda e si renda parte attiva dell'attacco.

A queste due motivazioni ne aggiungiamo una terza:

• Far in modo che l'attaccato rimanga occupato più a lungo possibile con un singolo pacchetto. 

Per comprendere questa affermazione dobbiamo ricorrere all'elenco iniziale integrato con ulteriori informazioni:

• Host on-line: Invia RST/ACK, tempo di risposta 50 ms o inferiore;
• Host off-line: Invia host unreachable, tempo di risposta 3 ms o inferiore;
• Network off-line: Invia network unreachable, tempo di risposta 50 ms o inferiore;
• Regola di reject: Invia communication administratively prohibited, tempo di risposta 50 ms o inferiore;
• Regola di drop/block: Non invia nulla, tempo di attesa 30 s o superiore.

Cosa dice lo standard?
Per ora ci siamo limitati a fare delle considerazioni di convenienza ma, cosa dicono gli standard?
Riferendoci al RFC 1122 (Requirements for Internet Hosts - Communication Layers) troviamo la seguente affermazione:

"3.3.8  Error Reporting

         Wherever practical, hosts MUST return ICMP error datagrams on
         detection of an error, except in those cases where returning an
         ICMP error message is specifically prohibited."

Con "specifically prohibited" si fa riferimento al fatto che non è ammesso rispondere ad un pacchetto di errore con un altro pacchetto di errore per non creare dei loop. Quindi possiamo affermare che anche lo standard vorrebbe che venissero impiegati dei pacchetti di risposta piuttosto che dei drop silenti.

I vantaggi del reject

Finora abbiamo smontato le false credenze sui vantaggi del drop, abbiamo visto che può essere utile per chi fa attacchi SYN flood con spoofing, ed abbiamo preso in considerazione cosa dice lo standard; ora vedremo quali possono essere i vantaggi che il reject può offrire.
Essenzialmente i vantaggi offerti dal reject possono essere i seguenti:

1. Facilita il lavoro di troubleshooting in caso di problemi;
2. Riduce il traffico di rete;
3. Riduce i tempi di risposta (per questo motivo molti, pur rimanendo legati al drop, lo utilizzano per le regole interne alla lan per evitare agli host perdite di tempo in attesa di risposte che non giungeranno mai);
4. Meno sfruttabile per attacchi SYN flood con spoof.

Conclusioni

Con questo articolo spero di avervi convinto che il drop non è sicuramente meglio del reject o perlomeno, spero di avervi messo qualche dubbio che vi induca ad approfondire l'argomento anche con dei test sul campo o sarebbe meglio dire sulla rete.

Sul web troverete delle vere e proprie guerre di religione legate all'argomento pertanto questo articolo può essere considerato un mio punto di vista con qualche dato a dimostrazione della tesi.
Se proprio non potete far a meno di utilizzare il drop potete almeno provare ad usare il reject sull'interfaccia lan e potrete verificare voi stessi i primi tre vantaggi riportati sopra.

Siccome la mediazione è sempre la strada migliore potreste trovare firewalls in cui, utilizzando il reject, i messaggi di risposta possono essere configurati in modo da ingannare l'attaccante e spacciare il firewall per un router intermedio o meglio ancora per sovraccaricarlo mettendo in atto il tarpit per mitigare gli attacchi DDoS.