Avanti Indietro Indice

1. Introduzione

Salve ragazzi.

Questo documento è un viaggio che in alcune parti sarà molto comodo mentre in altre vi farà sentire abbandonati a voi stessi. Il miglior consiglio che vi posso dare è di prendere una grossa, intima tazza di caffè o di cioccolata calda, di procurarvi una confortevole sedia e, prima di avventurarvi nel mondo a volte pericoloso del network hacking, di assorbirne il contenuto.

Per comprendere meglio come utilizzare l'infrastruttura presente al di sopra del framework netfilter, raccomando di leggere il Packet Filtering HOWTO e il NAT HOWTO. Per informazioni riguardanti la programmazione del kernel suggerisco la Rusty's Unreliable Guide to Kernel Hacking e la Rusty's Unreliable Guide to Kernel Locking.

(C) 2000 Paul `Rusty' Russell. Licenza GNU GPL.

1.1 Che cos'è netfilter?

netfilter è un framework per il manipolamento dei pacchetti, esterno alla normale interfaccia socket Berkeley. Consta di 4 parti. Prima parte, ogni protocollo definisce degli "hook" (IPv4 ne definisce 5) i quali sono punti ben definiti nella traversata dei pacchetti nel protocol stack. In ciascuno di questi punti, il protocollo richiamerà il framework netfilter fornendo il pacchetto e il numero dell'hook.

Seconda parte, porzioni del kernel possono registrarsi per "ascoltare", per ogni protocollo, differenti hook. Perciò quando un pacchetto è passato al framework netfilter, esso controlla se qualcuno si è registrato per quel determinato protocollo e hook; se sì, a ciascuno di essi è data, in ordine, una chance per esaminare (e possibilmente alterare) il pacchetto, per scartarlo (NF_DROP), per lasciarlo proseguire (NF_ACCEPT), o per chiedere a netfilter di accodarlo per lo userspace (NF_QUEUE).

Terza parte, i pacchetti che sono stati accodati sono accumulati (dal driver ip_queue) per essere inviati allo userspace; questi pacchetti sono gestiti in modo asincrono.

La parte finale consiste in splendidi commenti sul codice e nella documentazione. Questa è strumentale per ogni progetto sperimentale. Il motto di netfilter (rubato spudoratamente a Cort Dougan) è:

        ``Orbene... quanto è meglio di KDE?''

(Questo motto si affianca a `Frustami, colpiscimi, fammi utilizzare ipchains').

In aggiunta a questo framework grezzo sono stati realizzati vari moduli che forniscono funzionalità simili ai kernel precedenti (pre-netfilter), in particolare un sistema NAT e uno di filtraggio dei pacchetti (iptables) entrambi estendibili.

1.2 Che cos'è che non va con la 2.0 e la 2.2?

  1. Nessuna infrastruttura per il passaggio dei pacchetti allo userspace:
  2. Il proxy trasparente è un "accrocchio":
  3. Creare regole di filtraggio dei pacchetti indipendenti dagli indirizzi delle interfacce non è possibile:
  4. Il mascheramento è incluso nel filtraggio dei pacchetti:

    interazioni tra filtraggio dei pacchetti e mascheramento rendono complessa la realizzazione del firewall:

  5. manipolazione TOS, redirezione, ICMP unreachable e marcamento (che riguarda port forwarding, instradamento e QoS) sono collocati assieme al codice di filtraggio.
  6. il codice di ipchains non è né modulare, né estendibile (per esempio filtraggio per indirizzo, filtraggio in base alle opzioni, ecc.).
  7. La mancanza di un'infrastruttura adeguata ha portato alla proliferazione di differenti tecniche:
  8. Incompatibilità tra CONFIG_NET_FASTROUTE e filtraggio dei pacchetti:
  9. L'ispezione dei pacchetti scartati a causa della protezione di instradamento (es. Source Address Verification) non è possibile.
  10. Nessun modo per leggere atomicamente i contatori delle regole di filtraggio dei pacchetti.
  11. L'opzione CONFIG_IP_ALWAYS_DEFRAG è da selezionare in fase di compilazione, ciò rende difficile la vita alle distribuzioni che desiderano un kernel con funzionalità generiche.

1.3 Chi sei?

Sono l'unico tanto insensato disponibile a farlo. Come coautore di ipchains e attuale manutentore del Linux Kernel IP Firewall ho conosciuto molti dei problemi incontrati dalle persone con l'attuale sistema, in aggiunta mi sono anche esposto a cercare di comprendere cosa cercavano di fare.

1.4 Perché si pianta?

Woah! Avreste dovuto vederlo la scorsa settimana!

Siccome non sono un così grande programmatore, come noi tutti potremmo desiderare, sicuramente non ho esaminato tutti gli scenari, a causa di mancanza di tempo, attrezzatura e/o ispirazione. C'è anche una suite di test alla quale vi incoraggio a contribuire.


Avanti Indietro Indice