Perdonate la banalità del titolo, che storpia un modo di dire dialettale delle mie parti (" Crik, Crok e a rot' d' scort' "... in italiano si puo' tradurre con "Crik, Crok e la ruota di scorta"), ma mi sembrava piuttosto efficace, non solo ad attrarre la vostra attenzione, ma anche a spiegare il concetto che e' alla base di questo articolo. Infatti, nel pianificare la sicurezza di uno o piu' sistemi, spesso si prendono in considerazione soltanto i piu' evidenti e noti mezzi di rafforzamento, normalmente un firewall e un IDS (..."Crik e Crok" appunto...), tralasciando tante piccole "ruote di scorta" che, in alcuni casi, potrebbero fare la differenza. Tra le tante, e' il caso sicuramente di ricordare: l'intelligente partizionamento del disco, un'installazione mirata alle esigenze, la scelta di password sicure, l'aggiornamento dei pacchetti... ed anche l'oggetto di questo articolo, ovvero il filesystem /proc. Spesso di sente parlare di questo particolarissimo filesystem, la cui caratteristica principale e' di far si' che l'utente possa ottenere informazioni sul sistema o, come vedremo, cambiare specifici parametri senza ricompilare il kernel, come di un filesystem "virtuale"... dato che i file al suo interno vengono creati soltanto nel momento dell'accesso, non occupando cosi', fino a quel momento, spazio sull'hard disk. Volendo parlare di sicurezza, tralasceremo quella parte del filesystem destinata alla raccolta di informazioni sul sistema, concentrandoci, invece, sulla parte modificabile dall'utente e in particolar modo sulla directory /proc/sys/net/ipv4. Utilizzeremo, inoltre, "0" e "1" come variabili booleane (rispettivamente "FALSO" e "VERO") per cambiare dinamicamente, tra i possibili parametri del kernel, quelli che maggiormente ci interessano. Tutto questo sara' possibile, pero', soltanto se CONFIG_SYSCTL sara' stato definito durante la compilazione del vostro kernel (cosa che comunque le maggiori distribuzioni fanno di default). Cominciamo allora con due accortezze abbastanza comuni e di facile comprensione. Disabilitiamo, infatti, le risposte ai "ping"...

/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

e alle richieste generate dagli indirizzi di broadcast/multicast...

/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Cosi' impostati, questi due parametri ci permetteranno sia di risultare "invisibili" al metodo piu' banale, ma proprio per questo forse il piu' utilizzato, per verificare se un host e' attivo (l'ICMP PING appunto) e sia di evitare, ignorando le richieste provenienti dagli indirizzi di broadcast, che il nostro host possa essere utilizzato come amplificatore di un attacco Smurf. Fatto questo, evitiamo ora che il nostro host accetti pacchetti "source routed". Il source routing e' raramente utilizzato per scopi legittimi, e spesso un "attacker" utilizza questa tecnica per generare del traffico che sembri provenire dall'interno della vostra rete. L'IP source routing, infatti, serve a specificare l'esatto percorso che un pacchetto dovra' fare prima di giungere a destinazione. Chiaramente, permettere a chiunque di pilotare il traffico attraverso un'interfaccia classificata dall'host come "sicura", potrebbe, in alcuni casi, comprometterne la sicurezza. Disabilitamolo, quindi, con il comando:

/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route

Particolare attenzione deve, poi, essere prestata anche ai messaggi ICMP reindirizzati. Se non si ha a che fare con la configurazione di un router, infatti, sarebbe meglio disabilitarli, poiche' possono essere utilizzati per alterare le tabelle di instradamento. Evitiamo quindi che vengano accettati con il comando:

/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

Dato che ci siamo, abilitiamo anche la protezione dai messaggi di errore generati dai routers che violano la RFC 1122, eviteremo cosi' che il nostro kernel li registri e riempia i file di log di inutile spazzatura:

/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

Bene, fatto questo, passiamo adesso ad analizzare il cosiddetto "reverse path filtering". Qualora questo parametro venga attivato, il nostro kernel provvedera' automaticamente a rigettare tutti i pacchetti in entrata che provengano da un'interfaccia di rete diversa da quella prevista dalla tabella di instradamento per quell'indirizzo. In pratica, aiuta a prevenire gli attacchi interni (e non anche quelli provenienti dall'esterno...) basati sulla falsificazione dell'indirizzo IP, ovvero, in una parola, dall'IP Spoofing. Per abilitarlo usiamo il comando:

for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do
/bin/echo "1" > ${interface}
done

Inoltre, dato che il nostro compito principale e' quello di essere paranoici, per essere ancora piu' sicuri e scampare da possbili bug presenti all'interno dello stack TCP/IP, e' sempre possibile "passare" qualche linea in piu' ad Iptables e scartare tutti i pacchetti diretti a noi e provenienti da indirizzi "anomali", come ad esempio potrebbe essere il nostro indirizzo Ip, gli indirizzi di multicast, di loopback, di broadcast e di quant'altro, considerata la vostra rete, possa tornare utile. La sintassi di Iptables, valida per tutti questi casi, e' quasi banale:

iptables -A INPUT -i INTERFACCIA -s 127.0.0.0/8 -j DROP
A INTERFACCIA dovrete sostituire con la vostra interfaccia (eth0,ppp0...)

Questo e', ovviamente, un esempio per gli indirizzi di loopback... a voi poi il compito di sostituire quelli dell'esempio con gli altri indirizzi appropriati. Parlando di "reverse path filtering", non si puo' ignorare un altro interessantissimo aspetto delle capacita' di networking di Linux, ovvero l'IP Forwarding. Infatti, proprio questa sua propensione verso il mondo delle Reti, porta la maggior parte delle distribuzioni a rendere attivo di default questo parametro che permette di inoltrare il traffico tra interfacce diverse. La maggior parte degli utenti, pero', non ha bisogno di questa caratteristica che puo' essere tranquillamente disabilitata con il comando:

/bin/echo "0" > /proc/sys/net/ipv4/ip_forward

Benissimo. Registrare, inoltre, i tipi di pacchetti analizzati fin'ora potrebbe tornare utile...

/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

dira' al nostro kernel di fare quest'ulteriore sforzo per tutti i pacchetti contraffatti, i "source routed" e quelli reindirizzati. Come ultimo parametro da prendere in considerazione, ho preferito lasciare i cosiddetti "SYN Cookies", sui quali spenderemo due parole in piu' e che proteggono dagli attacchi basati sulla inondazione di pacchetti SYN... sicuramente piu' noti con il nome di "SYN Flooding". Questo conosciutissimo attacco, come sappiamo, mira a rendere inoperativo il sistema bersaglio, inondando, appunto, la sua memoria di sistema di connessioni semi aperte. Quando, infatti, un qualsiasi client ha la necessita' di stabilire una qualsiasi connessione TCP con un altro sistema (magari un server), scambia con quest'ultimo alcuni pacchetti di dati, dando il via alla cosiddetta "threeway handshake". La possiamo sintetizzare con un banale disegnino come questo:

Client Server
------ ------
SYN----------------------->

<---------------------SYN-ACK
ACK---------------------->

Soltanto successivamente a questo scambio, la connessione sara' realmente stabilita e i dati cominceranno a circolare liberamente in entrambe le direzioni.
La debolezza e' insita nel metodo, e sorge poiche' il server si preoccupa di tenere traccia di tutte le connessioni potenziali e di allocarne le risorse gia' nel momento in cui riceve un pacchetto SYN (per essere piu' precisi, un pacchetto TCP con il flag SYN attivo) destinato ad una porta in ascolto. Interrompere quindi l'handshake, evitando di rimandare indietro l'ACK che lo conclude, comporta comunque che il server, per un periodo di tempo, rimanga in "attesa" e conservi quelle risorse... Un carico eccessivo di pacchetti SYN, spediti da un indirizzo sorgente che non sara' in grado di resettare il SYN/ACK del server, come e' facile immaginare, saturera' le sue risorse, non permettendo a nessuno, nella peggiore delle ipotesi, di connettersi alla "vittima". La risposta piu' efficace a questo tipo di attacco si basa, come spesso accade, sulla crittografia.
Parliamo dei SYN Cookies. Abilitandoli con il comando:

/bin/echo "1" > /proc/sys/net/ipv4/tcp_syncookies

il nostro kernel, nel momento in cui ricevera' un pacchetto SYN, pur continuando a rispondere con un SYN-ACK, calcolera' l'intestazione ACK da una sequenza di numeri estratti da determinati campi dell'intestazione (indirizzo e porta di provenienza, indirizzo e porta di destinazione... soltanto per citarne alcuni), crittografandoli attraverso un generatore di hash unidirezionali. Le risorse del sistema verranno allocate soltanto se un pacchetto ACK tornera' indietro dal client e soltanto se, l'intestazione di quel pacchetto, conterra' dei dati che combaceranno con quelli calcolati dal server al momento della creazione del pacchetto SYN-ACK. Soltanto in questo caso il server aprira' la porta di destinazione, ponendola direttamente nello stato TCP_ESTABLISHED e non, come avviene normalmente, nello stato TCP_SYN_RECV, ovvero quello che indica la connessione semi aperta. La connessione, allora, verra' aggiunta alla coda "backlog" (quella che si preoccupa di tenere traccia delle connessioni attive), le risorse saranno allocate e la comunicazione vera e proprio potra' avere inizio. In caso contrario, il pacchetto verra' immediatamente scartato e l'handshake non sara' completato. In questo modo, il server non dovra' attendere lo scadere del tempo previsto per il "timeout" delle connessioni e l'attacco verra' stroncato sul nascere.
Ma non e' ancora tutto...

Quando ci troviamo, infatti, alle prese con un server o, piu' in generale, con un sistema soggetto a notevoli carichi di traffico, l'utilizzo dei SYN Cookies potrebbe portare altri problemi non meno rilevanti. Non e' raro infatti che, l'escamotage visto fin'ora, impedisca in questi casi le connessioni in entrata effettivamente valide. Per arginare allora il problema dei SYN flooding, possiamo ricorrere, ancora una volta, al nostro IPtables. Utilizzeremo, in questo caso, il modulo "limit" di Netfilter, che, pur essendo principalmente usato per limitare il logging del kernel (mai sentito parlare di Jolt2...?), puo' tornarci utile anche adesso...

iptables -A FORWARD -p tcp --syn -m limit 1/s -j ACCEPT

Questa regola ci permettera' di limitare l'analisi ad un pacchetto SYN al secondo con una raffica (--limit-burst) di default... ovvero di 5. Mi spiego meglio. Specificando un limite di 1 pacchetto al secondo con burst di 5, la prima volta che la regola sara' soddisfatta, saranno confrontati i primi 5 pacchetti... superato questo limite, ne sara' preso in considerazione soltanto uno ogni secondo. Inoltre per ogni secondo in cui non si riceveranno pacchetti, ne sarà recuperato uno dal burst. Come facilmente si intuisce, questa regola sara' un'ottima "diga" pronta ad arginare un eventuale attacco basato sul SYN Flooding.
Vi rimando comunque, per un doveroso approfondimento, al sito ufficiale:
http://netfilter.samba.org/

Qui c'e' tutto quello che vi serve... e anche di piu'!! Bene, l'articolo ormai e' alla fine. Mi rimane soltanto da dirvi che, le modifiche al file system /proc viste in questo articolo, possono essere inserite sia all'interno del vostro script per Iptables, ovvero, se non ne avete predisposto uno, possono essere aggiunte all'interno del file sysctl.conf, presente nella directory /etc. Inoltre, oltre ai links gia' inseriti nell'articolo, per ulteriori informazioni ed approfondimenti su quanto qui accennato, mi sento di consigliarvi la "Bibbia" del filesystem /proc, ovvero l'unico documento veramente completo che ho trovato in Rete e da cui ho preso alcuni spunti. E' scritto da Bowden, Bauer e Nerin.
Alla prossima gente...

Questo documento può essere liberamente copiato e distribuito da chiunque, ma a nessuno è permesso di cambiarlo in alcun modo. Ogni copia o documento derivato dovrà riportare l'indicazione alla fonte. Eventuali correzioni di questa pubblicazione saranno disponibili sul sito internet http://www.techtown.it.

- The Jackal - jackalXtechtown.it ( sostituite la X con @)