Simone Weil

Dopo la prima e la seconda parte su come attivare un firewall sulla nostra distribuzione linux debian, ecco una terza parte dove si tratta l’argomento dei già citati attacchi DoS (denial of service) cioè quegli attacchi che non mirano ad impadronirsi di un server, semplicemente lo sommergono di richieste per fare in modo che esaurisca le risorse e quindi automaticamente si metta fuori servizio da solo.

Già nella seconda parte, sull’abilitazione del traffico icmp, erano state prese misure contro questo tipo di attacchi, adesso con una serie di comandi specifici di iptables andiamo proprio a monitorare se il server sta ricevendo “eccessive e sospette richieste” di connessione.

IPTABLES -N syn-flood
IPTABLES -A INPUT -i eth0 -p tcp –syn -j syn-flood
IPTABLES -A syn-flood -m limit –limit 1/s –limit-burst 4 -j RETURN
IPTABLES -A syn-flood -j DROP
IPTABLES -A INPUT -p tcp ! –syn -m state –state NEW -j DROP

Questi strani comandi, a prima vista incomprensibili, servono proprio a controllare che il server non stia ricevendo troppe richieste di connessioni (e quindi sia oggetto di attacco DoS). Esiste, nel protocollo tcp, un flag che si chiama appunto SYN e serve per indicare che l’host che ha inviato il pacchetto intende stabilire una nuova connessione. Controllando i pacchetti che arrivano sull’interfaccia di rete (eth0) verifico se hanno il SYN settato, se lo hanno li “immagazzino in una nuova catena” diversa da quelle di input, output, forward. Su questa nuova catena verifico che il flusso dati in arrivo non superi un certo limite (terzo comando iptables) nel qual caso lo scarto.Per sicurezza viene anche scartato tutto il traffico tcp in ingresso, sulle nuove connessioni, che non presenta il flag SYN settato (pacchetti tcp malformati).

Bene e anche questa è fatta. Ora non resta altro da fare che trasformare tutti questi bei comandi che abbiamo visto in queste 3 puntate, in uno script che si avvia quando si accende il server così che sempre il nostro firewall sia attivo.

Alla prossima puntata.

Secondo appuntamento di studio con la creazione di un firewall linux. Nel primo post abbiamo visto una soluzione (funzionante ma incompleta) su come implementare un firewall a protezione per esempio di un server Debian.

C’è però un piccolo problema con quella soluzione: tutto il traffico di controllo icmp verso il server è scartato (drop) perché non è stata creata nessuna regola che permetta questo tipo di traffico in ingresso. Per esempio se volessimo controllare che il server è attivo con il comando Ping non funzionerebbe perché il firewall del server scarterebbe i pacchetti in quanto ping funziona con il protocollo icmp.

Ecco allora la necessità di inserire nuove regole di filtraggio nella catena di INPUT che permettano il traffico icmp:

IPTABLES -A INPUT -p icmp –icmp-type echo-reply -m state –state ESTABLISHED,RELATED -j ACCEPT
IPTABLES -A INPUT -p icmp –icmp-type echo-request -m limit –limit 5/s -m state –state NEW -j ACCEPT
IPTABLES -A INPUT -p icmp –icmp-type destination-unreachable -m state –state NEW -j ACCEPT
IPTABLES -A INPUT -p icmp –icmp-type time-exceeded -m state –state NEW -j ACCEPT
IPTABLES -A INPUT -p icmp –icmp-type timestamp-request -m state –state NEW -j ACCEPT
IPTABLES -A INPUT -p icmp –icmp-type timestamp-reply -m state –state ESTABLISHED,RELATED -j ACCEPT

Con queste regole permettiamo il traffico icmp nuovo (NEW) o che è già stabilito o ha relazioni (ESTABLISHED, RELATED) con traffico già richiesto. Una nota importante è il secondo comando con limit 5/s che stabilisce appunto un limite di 5 pacchetti/secondo oltre il quale il traffico viene scartato. Questa regola ci protegge in parte da attacchi di tipo DoS (Denial of Service) su Ping.

Ecco che il nostro firewall inizia a prendere forma. Mancano ancora delle regole per proteggere adeguatamente il nostro server da attacchi DoS e sicurezze varie.

Insomma: ci sarà sicuramente una terza puntata.