Ebbene si, parliamo di firewall!
Un utente medio normalmente sa che le porte possono essere:
Ma e’ proprio cosi’?
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:
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.
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.
