7.2 Alcuni file importanti

Alcune delle variabili in /proc/sys/net sono particolarmente importanti dal nostro punto di vista in quanto ci consentono di proteggere il kernel da diversi tipi di attacchi.

Di base, la directory che più ci interessa di /proc/sys/net è sicuramente ipv4.

In quest directory, dovreste trovare alcuni file tra cui:

• icmp_echo_ignore_broadcasts -- questo file vi consente di dire al kernel se accettare o ignorare dei ``ping'' inviati ad indirizzi di broadcast. Un ping non è altro che il pacchetto generato dal comando ``ping'' per vedere se un computer è in funzione o meno. In questo caso, un valore di 0 (falso) dice al kernel di non ignorare i ping di broadcast, mentre un valore di 1 (vero) di ignorarli. Normalmente, è meglio impostare questo file ad ``1''. Provate ad immaginare cosa potrebbe succedere se una persona qualsiasi mandasse un ping (aka icmp echo request) a 16 milioni di computer, utilizzando come destinazione un indirizzo di broadcast e come mittente l'indirizzo ip del vostro computer.

  Con una cinquantina di byte, vi manderebbe contro circa 16 milioni di risposte al ping... (fortunatamente, la maggior parte dei computer in rete non rispondono a ping di broadcast).

  Questa variabile viene principalmente utilizzata all'interno di net/ipv4/icmp.c:icmp_rcv.

• icmp_ignore_bogus_error_responses -- disabilita o abilita il logging di risposte errate mandate da alcune apparecchiature di rete. Utile soltanto per evitare di riempire i vostri log. Fa riferimento principalmente all'RFC1122 e alla funzione icmp_unreach chiamata da icmp_rcv in net/ipv4/icmp.c.
• ip_forward -- questo file, invece, vi consente di abilitare o disabilitare il ``forwarding''. Il forwarding consiste nel consentire a linux di ``copiare'' i dati ricevuti da un'interfaccia di rete ad un'altra. Senza il forwarding abilitato, non potremmo utilizzare linux come firewall ed i pacchettini non potrebbero passare da un'interfaccia all'altra.
• ipfrag_* -- sebbene i default siano normalmente più che validi, è bene spendere due parole sui terribili frammenti. Alcune reti, a livello hardware, non riescono a trasmettere più di un numero di byte limitato per volta. Una rete ethernet per esempio, non consente di trasmettere più di 1500 (circa) bytes per volta (questo limite viene anche detto MTU, ovvero Max Transfer Unit). Esiste per questo un sistema per spezzettare i pacchetti ed inviarli come tante unità indipendenti. Questi vengono normalmente chiamati frammenti e possono creare diversi problemi:
  • Per esempio, inviando frammenti sufficientemente piccoli la parte iniziale del pacchetto che contiene le informazioni sul protocollo tcp o udp viene suddivisa su più pacchetti. Queste informazioni però, vengono utilizzate proprio dai firewall per capire la destinazione e lo scopo del pacchetto. In passato, alcuni firewall facevano semplicemente passare questi frammenti, altri si inceppavano, mentre altri ancora li buttavano via. L'approccio utilizzato attualmente da linux è quello di assemblare lui direttamente come firewall tutti i frammenti. In pratica, linux deciderà se far passare o meno un pacchetto solo dopo averlo completamente riassemblato. Questo proteggerà i nostri server anche da altri tipi di attacco.
  • Al contrario, dividendo il pacchetto in frammenti sufficientemente grossi, l'header tcp/udp viene inserito solo nel primo frammento. Così, se arrivano prima frammenti successivi al primo, il firewall deve decidere se far passare o meno il pacchetto senza avere tutte le informazioni necessarie a disposizione. Anche in questo caso, far assemblare i pacchetti al firewall può essere una buona soluzione.
  • Un altro esempio è quello di alcuni attacchi che prendevano dei grossi pacchetti, li spezzettavano in frammenti molto piccoli e li mandavono poi ad una macchina bersaglio in un ordine completamente casuale.

    Questa macchina si doveva quindi prodigare per ricomporre il puzzle riordinando e riunendo i pacchetti nel corretto ordine, sovraccaricando notevolmente la cpu arrivando persino a bloccare la macchina.

    Per rimediare, in linux si utilizzano proprio i file ipfrag_*. In pratica, si stabiliscono dei limiti oltrepassati i quali linux si ``arrenderà'' nel tentare di riordinare i pacchetti, evitando di bloccarsi su questo compito. I valori di default di tali limiti sono ben tarati, anche se potrebbe rendersi necessario abbassarli, a seconda della tipologia di macchina utilizzata e a secondo dell'attacco cui si è soggetti.

    Capita raramente poi, che per migliorare le prestazioni di alcuni servizi, come per esempio NFS, tali limiti debbano essere alzati.

  • Alcuni vecchi attacchi attualmente praticamente inoffensivi erano basati sul produrre frammenti che si sovrapponessero (``overlapping fragments'') in modo da portare i sistemi operativi a sbagliare il calcolo della memoria da utilizzare, bloccando il sistema (CERT CA-1997-28).
  Il significato dei file è quello classico di tutti i meccanismi basati su un limite (threshold). Quando la memoria utilizzata per riassemblare i frammenti supera ipfrag_high_thresh questi vengono bloccati fintanto che il valore non torna sotto ipfrag_low_thresh. ipfrag_time indica per quanto tempo al massimo un frammento può essere mantenuto in memoria.

  Questi limiti sono utilizzati principalmente in net/ipv4/ip_fragment.c:ip_defrag ed ip_evictor.

• tcp_ecn -- questo file regola l'utilizzo dell'ecn, ovvero ``Explicit Congestion Notification protocol''. Non che sia un rischio per la sicurezza, ma spesso firewall vecchi non conformi agli standard (RFC3168) tagliano via tutte le connessioni che utilizzano questo protocollo. Se da linux non riuscite a collegarvi a dei siti che invece non avete problemi a raggiungere con altri sistemi operativi, probabilmente dovete disabilitare l'ecn. Sicuramente quindi, almeno finché le cose non saranno cambiate, vi conviene tenerlo sempre disabilitato.
• tcp_max_syn_backlog e tcp_syncookies -- un altro tipo di attacco, abbastanza pericoloso e abbastanza in voga di questi tempi viene detto syn flood, ovvero inondazione di syn (CERT CA-1996-21). Il giochetto anche in questo caso è molto semplice: viene inviato il pacchetto tcp per iniziare una connessione ma non ne viene mai confermata l'apertura, costringendo il sistema operativo a ricordarsi di questa connessione in attesa che una conferma venga inviata.

  Facendo un paio di grossolani conti, considerando che esistono 65535 porte e che per ogni porta devono poter essere accettate più connessioni, è abbastanza evidente che il kernel di un qualsiasi sistema operativo non può permettersi di ricordarsi tutti i pacchetti di inizio delle connessioni ricevuti. In pratica, per ogni porta viene creata una coda di dimensioni molto piccole (si parla di numeri nell'ordine delle decine o centinaia). Quando questa coda è piena, la porta non può più accettare pacchetti. A peggiorare la situazione, le rfc indicano un timeout abbastanza alto (nell'ordine dei minuti) prima che il kernel possa buttare via questi pacchetti, svuotando la coda e dedicandosi ad altro. E' quindi abbastanza facile dimostrare che un attaccante, mandando pochi kilobyte di syn al secondo con un semplice modem 56k, può rendere inutilizzabile una porta di un qualsiasi server, senza nemmeno alzare il carico della cpu né saturare la banda.

  Le soluzioni sono diverse, ma poche si sono rivelate veramente valide:

  • alcuni firewall limitano il numero massimo di syn al secondo inviati ad ogni server protetto, facendo in modo che quando questo limite viene sorpassato vengano fatti passare ``equamente'' (e ci sono diverse discussioni su cosa si debba intendere per ``equamente'') syn inviati da mittenti diversi. Il problema è che essendo sufficiente un basso numero di syn al secondo per bloccare un server, è difficile riconoscere un attacco da un comportamento ``legale''. Esistono diversi algoritmi per gestire queste situazioni, e su internet sono disponibili i benchmark sull'efficacia di questo tipo di protezione, divisi per firewall e per rivenditore (cercate con google!). Non si tratta comunque della soluzione migliore ed è stato mostrato che con attacchi di particolari dimensioni si tratta di una difesa molto poco efficace che può tagliare facilmente del traffico che invece dovrebbe essere consentito.
  • un approccio più efficace adottato da altri firewall si è rivelato quello di far gestire le connessioni dal firewall stesso. In pratica, quando il firewall riceve un syn, questo ``si finge'' il server fino al ricevimento dell'ack di conferma della connessione. A questo punto, stabilisce una connessione ``vera'' con il server fingendosi il client dopodiché fa continuare la connessione come se il client ed il server si parlassero direttamente.

    In questo modo, un syn flood andrebbe a colpire solo il firewall proteggendo molto efficacemente i server.

    Firewall di questo tipo sono poi strutturati in modo da resistere molto bene a dei syn flood anche con un numero molto alto di syn al secondo, utilizzando tabelle più grosse di quanto si possa permettere un normale server e creando delle infrastrutture dinamiche in grado di gestire tali situazioni.

  • molto originale invece è l'approccio utilizzato da linux e da molti altri sistemi. Il sistema viene chiamato syn cookie, ``biscottini nel syn''. Tornando a parlare di three way handshake e tcp, quando un syn viene ricevuto (e per syn si intende un pacchetto che contenga il numero iniziale di sequenza, o numero di sincronia, e il cui syn flag sia settato), il sistema che lo riceve deve rispondere a sua volta inviando un syn con un ack. Questo secondo syn è normalmente un numero casuale difficile da indovinare ed è proprio dopo aver inviato quest'ultimo che il sistema deve rimanere in attesa del famoso ack. Il sistema utilizzato dai syn cookies consiste nel prendere un numero non casuale da inviare che contenga quelle informazioni (o parte di quelle informazioni) che verrebbero memorizzate nella famosa coda (se ci fosse spazio a disposizione...). In pratica, una volta che la coda è piena, le informazioni che dovrebbero essere memorizzate vengono inviate nel syn ack di risposta. Se l'handshake viene completato correttamente dal client inviando l'ack finale (il terzo passo dell'handshake), le informazioni vengono estratte dal pacchetto ricevuto (l'ack di risposta viene sempre calcolato a partire dal syn, ed è quindi possibile partendo da un ack ricalcolare il syn originale), non risentendo quindi del problema.

    Il syn però, deve continuare ad essere difficilmente indovinabile ed aumentare di pacchetto in pacchetto (non avrebbe ragione di esistere altrimenti, e sono condizioni imposte dall'rfc 793). Vengono quindi normalmente utilizzate delle funzioni one-way o degli hash che rispecchino queste caratteristiche, e l'informazione inviata si riduce normalmente in un ``connessione inizializzata correttamente'' (per maggiori informazioni, potete vedere il file net/ipv4/tcp_ipv4.c, in particolare la funzione tcp_v4_conn_request, oppure il file drivers/char/random.c funzione secure_tcp_syn_cookie per sapere come un syn cookie viene calcolato). Il problema è che è stato dimostrato che in particolari condizioni con particolari versioni del kernel linux era possibile indovinare questi syn e fare spoofing delle connessioni tcp. Sebbene attacchi di questo tipo siano stati raramente (se mai) utilizzati (non mi riferisco allo spoofing in generale, pratica largamente utilizzata, ma all'indovinare i syn grazie a questo bug nella creazione dei syn cookies), è bene abilitare i syn cookies solo su kernel relativamente recenti (dal 2.4.6 in su funzionano sicuramente correttamente), o in particolari condizioni (quando si è sotto attacco, per esempio).

    Ultima cosa da dire a proposito dei syn cookies è che questi vengono considerati da alcuni violare lo standard del tcp (ci sono state diverse discussioni in proposito, si veda per esempio il sito http://cr.yp.to/syncookies.html, di Dan Bernstein) e possono quindi introdurre dei problemi. I syn cookies, se abilitati, verranno quindi utilizzati da linux soltanto nel caso in cui la famosa coda si riempia.

  Tornando a parlare dei file in /proc, tcp_max_syn_backlog consente di specificare il numero massimo di connessioni che possono rimanere in coda per ogni porta (normalmente è impostato a 128 su sistemi con meno di 32 mega di ram e a 1024 su tutti gli altri sistemi - net/ipv4/tcp.c:tcp_listen_start, net/ipv4/tcp-ipv4.c:tcp_v4_conn_request e tcp_synq_is_full) mentre tcp_syncookies consente di abilitare o disabilitare i syn cookies.

  Rimane soltanto da aggiungere una cosa: come si fa a rendersi conto di essere sotto syn flood? Beh, con i syn cookies disabilitati, potreste dare un comando come:

            # netstat -npla |grep SYN_RECV
          
  

  Normalmente, dovreste vedere non più di 1-2 connessioni provenienti da indirizzi ip diversi. Se ne vedete più di una trentina, allora è molto probabile che vi troviate sotto syn flood. Per esperienza, posso dirvi che con un kernel 2.2 senza i syn cookies abilitati con circa 110-120 connessioni in SYN_RECV la porta attaccata diventava irraggiungibile.

  Per avere una ulteriore conferma, potreste infine verificare con tcpdump... se arrivano dei nuovi syn da uno stesso ip prima ancora che voi abbiate risposto con un altro syn-ack o dopo aver temporaneamente bloccato l'ip o il demone responsabile della porta, allora siete sotto syn-flood. Anche questa prova però non può essere considerata definitiva: il syn-flood viene considerato un blind attack, ovvero un attacco che non ha bisogno di ricevere le risposte per poter essere effettuato, per cui è estremamente semplice utilizzare dei ``mittenti'' falsificati nei pacchetti (ed utilizzare quindi ip multipli e differenti). L'ip che vedete in netstat o tcpdump potrebbe quindi essere quello di qualcuno che nulla ha a che vedere con l'attacco. L'unica condizione perchè un ip possa essere utilizzato è infatti che questo risulti irraggiungibile dalla vostra macchina (altrimenti manderebbe un reset dopo il vostro syn-ack). Infine, nel caso in cui il kernel si trovi a dover far uso dei syn cookies, dovreste vedere dei messaggi nei file di log.

• directory conf ok, qua dentro trovate i parametri per le singole interfacce di rete. A parte ``all'' e ``default'', che consentono rispettivamente di cambiare i parametri di tutte le interfacce o i default per le future interfacce, ogni sottodirectory contiene i parametri di una singola interfaccia di rete.

  Diamo quindi un'occhiata alla directory all (o eth0, o lo, o...):

  • accept_redirects fa in modo che vengano accettati redirect dalla particolare interfaccia. Un redirect consiste ``in un suggerimento'' per un percorso ``migliore'' per raggiungere un determinato punto (RFC792, pagina 12). Il problema è che è facile dare questi ``suggerimenti'' deviando il traffico a proprio piacimento (o comunque in modo da poter fare cose poco piacevoli). Un tempo i redirect erano molto pericolosi, adesso vengono accettati solo se determinate condizioni vengono verificate. Per un firewall, è comunque bene disabilitare questi redirects, o se necessario affidarsi a demoni come zebra o bird e a protocolli più evoluti per aggiornare dinamicamente le tabelle di routing.
  • secure_redirects e send_redirects consentono rispettivamente di accettare i redirect che rispettino condizioni molto più stringenti di quelle normali e di generare i redirect per gli altri host. In pratica, viene verificato che il redirect venga inviato da un gateway di default conosciuto (net/ipv4/fib_semantics.c:ip_fib_check_default chiamato da route.c:ip_rt_redirect).
  • accept_source_route fa in modo che vengano accettati ``source route'', ovvero pacchetti che chiedono che la risposta passi da determinati routers. Sebbene questo non sia un problema in se stesso, è meglio disabilitare questa opzione per rendere la vita più difficile a coloro che tentino la strada dello spoofing. Uno dei problemi principali dello spoofing è infatti quello di mettersi in grado di poter ricevere le risposte dei pacchetti falsificati, ed il source_route facilita notevolmente il raggiungimento di questo obiettivo. La maggior parte dei provider, infatti, bloccano pacchetti che utilizzano questa opzione del protocollo ip.
  • forwarding e mc_forwarding abilitano o disabilitano rispettivamente il forwarding ed il forwarding dei pacchetti di multicast per la singola interfaccia (lo stesso forwarding di cui parlavamo prima). Attenzione però che il forwarding dei pacchetti di multicast ha bisogno di un demone di supporto.
  • rp_filter abilita o disabilita il ``reversed path filter''. Con questo filtro abilitato, viene verificata la coerenza dell'indirizzo ip del mittente di un pacchetto rispetto l'interfaccia su cui tale pacchetto è stato ricevuto e le informazioni contenute nelle tabelle di routing. In caso le informazioni non risultino coerenti, il pacchetto viene scartato. Quest'opzione può creare problemi con tabelle di routing particolarmente complesse (utilizzando ip rule, per esempio, e tabelle di routing multiple) o quando si fa uso di link asimmetrici, ovvero dove le richieste escono da un'interfaccia mentre le risposte ritornano su un'altra (con collegamenti satellitari, per esempio, dove le richieste escono dal telefono e le risposte arrivano sulla parabolica). Utilizzato principalmente in sys/net/ipv4/fib_frontend.c:fib_validate_source.
  • log_martians fa in modo che pacchetti strani, improbabili o impossibili vengano registrati nei file di log. Il problema è che a volte, magari con particolari configurazioni, un po' troppi pacchetti vengono loggati.