IPTables: DROP vs REJECT

Shotokan - giovedì 12 Settembre

Ebbene si, parliamo di firewall!
Un utente medio normalmente sa che le porte possono essere:

  • Aperte (regola INPUT settata su ACCEPT, e un servizio in ascolto su quella porta)
  • Chiuse (regola INPUT settata su DROP o REJECT, o nessun servizio in ascolto su quella porta)

Ma e’ proprio cosi’?

Binary is three.

Esattamente, non e’ solo “Aperto” o “Chiuso”, in questo caso cio’ che ci frega e’ proprio il “Chiuso”.
Ci sono due stati di “rifiuto” dei messaggi:

  • Chiuso aka PACKET REJECTED
  • Filtrato aka PACKET DROPPED

Cosa cambia tra i due?

Iniziamo parlando dal packet dropping (-j DROP) in quanto il piu’ semplice, e spesso piu’ usato, anche se in apparati ‘a rischio’ sarebbe meglio informarsi prima di droppare qualsiasi pacchetto senza conoscere le possibili conseguenze.

Dunque, cosa fa il DROP?

Prendiamo in considerazione questo script bash minimale e carino che e’ in autorun sul notebook da cui sto scrivendo per cercare di spiegarlo meglio:

#!/bin/bash
################
#FW BY Shotokan#
################

#Clean UP!
iptables -F INPUT
#Accept everything from localhost
iptables -A INPUT -i lo -j ACCEPT
#Accept everything already extabilished
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#Accept ping
iptables -A INPUT -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
#Drop everything else
iptables -A INPUT -j DROP

Cosa fa in brevis:
Svuota le regole in INPUT (-F), accetta qualsiasi connessione da locale a locale (-i lo), accetta le connessioni gia’ stabilite (–state ESTABILISHED,RELATED), accetta i ping e… Droppa tutte le altre connessioni in ingresso.
Torniamo al discorso drop appunto: che cambia da reject?

Quando un pacchetto arriva in INPUT ad iptables, e non rispecchia le regole sopra elencate, esso viene “droppato”, ovvero semplicemente viene scartato in modo silenzioso, senza generare messaggi di risposta.

Se creassi una regola sul firewall del genere per esempio:

iptables -F INPUT
iptables -A INPUT -j DROP

E provassi a fare una scansione del mio host “firewall” da un secondo host nella rete, esso risulterebbe praticamente “inesistente”, mi potrei accorgere dell’esistenza dell’host solo da eventuali suoi pacchetti in uscita.

What ‘bout REJECT?

Il REJECT, al contrario del DROP, risponde in ogni caso alla comunicazione con un pacchetto ICMP di tipo 3 codice 13 (type=Destination Unreachable, code=Communication administratively prohibited)

Quindi, da come possiamo rapidamente vedere, il REJECT sicuramente usa piu’ banda di un DROP SE stiamo parlando di una rete ISOLATA (Es: c’e’ solo un server nella rete, e lo stesso server e’ firewall di se stesso) pero’ il DROP sicuramente rende il mio host “piu’ anonimo”.

MA se io avessi nella mia rete un server, non firewallato, ed un firewall con regole DROP, a cosa posso andare incontro?

Situazione tipo:

Server, Firewall(drop), Attacker

L’attacker inizia a SynFlooddare il Server, spoofando il suo ip con quello del Firewall.

Attacker(Spoof)->SYN->Server->ACK+SYN->Firewall

Ma il Firewall semplicemente non risponde, allora il server continua a rimandare ACK al firewall aspettando almeno una risposta ICMP negativa, che non arriva.

Ergo: il nostro firewall sta ‘aiutando’ l’attacker nel suo synflood.

Se il firewall infatti avesse avuto regole REJECT, il server avrebbe smesso di contattarlo da subito, ricevendo ICMP type3 code13.

Morale:
se dovete programmare un firewall, usate REJECT.
E’ conforme agli standard e non vi ritroverete persone incazzate.

Se sapete quel che fate e sapete bene QUANDO usare DROP, usatelo.
Ma con cautela.

Theme made by Koala