Come quasi tutti voi certamente sapete Iptables è il tool in user-space per interagire con netfilter, la componente del kernel linux che si occupa di fare da firewall, e non solo, per la nostra linux-box.

In questo articolo andiamo ad elencare e commentare una serie di regole che dovrebbero essere presenti nella maggior parte delle installazioni. Lo scopo è aggiungere un po’ di sicurezza in più ai nostri sistemi informatici.

Come prima cosa diamo uno sguardo a questa utilissima immagine tratta da http://en.wikipedia.org/wiki/Iptables che rappresenta il percorso che i nostri pacchetti seguono quando attraversano il netfilter del nostro linux.

Netfilter Packet FlowLa parte che prenderemo in esame noi è quella con sfondo verde, ed in particolare la tabella filter con le sue tre chains, o catene: input, forward e output. Per rendere semplice la comprensione tralasceremo tutte le altre che in ogni caso non ci servono per realizzare le funzionalità di firewall in senso stretto.

Filter Table Input Chain:
Questa chain viene attraversata da tutti i pacchetti che provengono dall’esterno della linux-box e sono diretti ad essa.

Filter Table Forward Chain:
I pacchetti IP generati all’esterno e diretti all’esterno passano questa chain; ciò è utile se il nostro linux svolge funzionalita di routing e il packet forward è abilitato.

Filter Table Output Chain:
Il traffico generato dai processi locali attraverserà questa catena.

Una catena, o chain, è sostanzialmente formata da una serie di regole di match e da una action per ognuna di queste regole. Quando un pacchetto entra in una chain viene confrontato con le regole di match (che possono essere ip sorgente/destinazione, protocollo, porta, ecc…) se il matching è postivo viene applicata la action corrispondente (le più comuni sono ACCEPT e DROP) e il pacchetto verrà accettato o scartato.
Per ogni Chain viene inoltre definita una Policy di default che viene applicata a tutti i pacchetti che sono arrivati in fondo alla chain senza essere stati “matchati” da nessuna regola.

Andiamo ora a vedere i comandi per aggiungere le regole, che non dovrebbero mai mancare, chain per chain e a commentarle.

Filter Table Input Chain:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp -m tcp –dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m recent –set –name SSHTRY –rsource
iptables -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 3 –name SSHTRY –rsource -j DROP
iptables -A INPUT -p tcp -m tcp –dport 22 -j ACCEPT
iptables -m state –state RELATED,ESTABLISHED -j ACCEPT
iptables -P INPUT DROP

La 1° regola accetta il traffico proveniente dall’interfaccia di loopback. La 2°, se supponiamo di avere due schede di rete, di cui una connessa ad una LAN fidata, consente l’ingresso proveniente dalla LAN stessa. Se il nostro linux è un web server accettiamo le richieste web con la 3° regola.
La 4°,5° e 6° regola vanno assieme: è un piccolo trucco per scoraggiare gli attacchi brute-force verso ssh. In pratica consentiamo allo stesso ip sorgente di effettuare al massimo 3 nuove connessioni nell’arco di un minuto, la maggior parte delle configurazioni standard del demone ssh prevede che si possano fare 3 tentativi di login dopodiché si viene disconnessi. 3 tentativi di login a connessione per 3 connessioni fanno 9 tentativi al minuto, sufficienti per tenere alla larga avversari occasionali (badate bene: occasionali! Contro attaccanti ben preparati che vi hanno preso di mira questi accorgimenti sono necessari ma non sufficienti).
La 7° regola ci serve per poter ricevere il traffico di risposta dalle connessioni iniziate dall’host stesso. Ad esempio se richiediamo una pagina http://www.linuxtips.it/ il programma di navigazione chiederà al kernel di stabilire una connessione tcp verso l’ip di linuxtips.it e porta 80. Il kernel assegnerà alla connessione anche un ip sorgente  scelto in base alle routing table (diciamo w.x.y.z) e una porta sorgente scelta tra una di quelle al momento libere (diciamo 61867). Quando il server risponde, risponderà ad ip destinazione w.x.y.z e porta destinazione 61867. Come potete vedere nelle nostre regole non ce n’è nessuna che consente a questo tipo di traffico di entrare e noi non riusciremmo a vedere (con molta molta tristezza) la home page di www.linuxtips.it. La 7° regola istruisce il firewall a verificare se quel pacchetto è relativo ad una connessione in fase di hand-shake, oppure già stabilita, e di consentirne il transito. I più smaliziati sapranno, e i più curiosi vorranno sapere, che la presenza o meno di questa possibilità è ciò che differenzia un firewall stateful inspection (come è Netfilter) da uno stateless.
Tutto ciò che non è esplicitamente consentito è vietato! Così la regola 8 imposta la policy di default, e quindi l’action da eseguire, se il pacchetto in ingresso non ha trovato la sua regola.

Ovviamente le regole devono essere personalizzate in relazione alle vostre esigenze, se ad esempio non avete un server web la 3° regola è da togliere, se invece di un server web avete un qualunque altro tipo di server è sufficiente adattare la porta ed eventualmente il protocollo. Notate anche che in questo esempio il traffico ICMP non è consentito e se “pingate” non riceverete risposta.

Filter Table Forward Chain:
Nessuna regola. Se il vostro linux non è destinato a svolgere il ruolo di router ,gateway di accesso, o qualunque altro dispositivo di rete che debba inoltrare pacchetti, questa chain non verrà mai utilizzata. Assicuratevi di aver disabilitato il packet forward con “cat /proc/sys/net/ipv4/ip_forward” e verificando che sia zero, se è 1 disattivatelo temporaneamente con “echo 0 > /proc/sys/net/ipv4/ip_forward” ed editando il parametro nel file /etc/sysctl.conf per far sopravvivere l’impostazione al riavvio del sistema.

Filter Table Output Chain:
In teoria, se siamo abbastanza bravi, la nostra macchina dovrebbe essere sicura e fidata e tutto il traffico in uscita dovrebbe essere stato generato perché lo volevamo noi. Possiamo quindi impostare la policy di default ad ACCEPT e non inserire nessuna regola. Se volete potete anche inserire la policy DROP e, con lo schema delle regole di input, inserire mano a mano le regole di output, ci vuole solo un po di pazienza. Software come tcpdump possono esserci utili in questo caso, e magari tratteremo il suo utilizzo in prossimo articolo.

Have a good Filter!!!!

Lascia un Commento

Devi aver fatto il login per inviare un commento

Page 1 of 11