OSS: freeLIX
Lavorando in una azienda del mondo IT, occumandomi anche di sicurezza e vedendo i costi dei materiali, piano piano si è materializzata una domanda:
Potrei realizzare le stesse infrastrutture con Software OpenSource?
Iptables mi è parso sempre potente e con una granularità di controllo imbattibili, ma gli standard di mercato sono altri... mi serviva un interprete che capisse la sintassi e la semantica di una configurazione di un firewall commerciale e che traducesse al volo tutto in una configurazione iptables congruente Nel panorama dell'OpenSource, l'unico elemento non esistente per la realizzazione dell'esperimento era proprio questo.
Per questo motivo nasce freeLIX Ogni riferimento a freeLIX viene rimandato ai siti:
http://sourceforge.net/projects/lix/
http://freshmeat.net/projects/lix
Struttura SW
Per come la vedo, cercare di capire come funziona un FW significa comprendere come l'interfaccia dei comandi interagisca con il S.O. sottostante e come i concetti di filtro dei pacchetti si innestino nella struttura dello stack tcpip. Capire come funziona un FW significa perciò anche delineare le caratteristiche di utilizzo dell'interfaccia. Partendo dal punto di vista dell'amministratore della sicurezza si possono individuare tre categorie di comandi:
- Comandi Generici: qualcosa del tipo 'mostrami la configurazione' o 'mostrami gli elementi costitutivi dell'ObjectGroup A';
- Comandi di Controllo: qualcosa del tipo 'salva la configurazione' o 'ricarica il sistema';
- Comandi di Configurazione: qualcosa del tipo 'aggiungi la regola x all'ObjectGroup A' o 'crea un nuovo ObjectGroup con nome B';
Certamente la categoria più interessante è la terza in quanto ad ogni comando sintatticamente ben definito deve corrispondere una modifica immediata della configurazione del FW e del S.O. sottostante.
Alla partenza il processo Memory Command Server (MCS) formatta le strutture di memoria opportune e carica la configurazione precedentemente salvata che chiameremo Configuration Command Set (CCS).
Ogni elemento caricato da MCS produce una fork+execv e richiama uno script che modifica la configurazione del S.O. coerentemente; dopo di ciò il il processo MCS rimane in attesa di richieste da evadere.
Conseguentemente a MCS viene lanciato il Command Engine Server process (CES) il cui scopo è quello di gestire le connessioni nel modello client/server.
Una sessione interattiva dell'amministratore della sicurezza scatena una istanza di Command Editor Interface (CEI) che inizializza le comunicazioni con il server CES registrandosi.
CES risponde clonandosi in un Command Line Interface server (CLI) dedicato al colloquio con il CEI che ha scatenato il meccanismo.
Il colloquio tra CEI e CES/CLI e tra CES/CLI e MCS viene controllato e gestito tramite una implementazione di una macchina di Moore.
Il server Network Access Service (NAS) sincronizza le configurazioni tra due o più istanze di freeLIX per una gestione più professionale di impianti di tipo cluster. Il NAS deriva direttamente dai CEI e lo possiamo considerare come una re-implementazione per supportare socket tcp/ip.
CCS
La directory configuration è strutturata in tre sotto-directory contenenti le personalizzazioni di freeLIX nei file *.cfg.
I file di configurazione veri e propri li troviamo in duplice copia nei file con estensione txt accoppiati con i rispettivi valori hash.
MCS
Ogni comando di configurazione viene salvato in un file di testo e contemporaneamente anche memorizzato in una struttura ad albero.
I comandi li troviamo nei nodi foglia, in quelli intermedi vengono salvate informazioni di comodo come la categoria dei comandi o il peso della struttura.
CEI
Descriviamo ora la parte client della struttura freeLIX. Possiamo riassumere gli scopi di questo componente in:
- controllo sintattico dei costrutti;
- interpretazione dei messaggi di errore inviati dal server CES/CLI;
- gestione della coda dei comandi in una history
- ofuscazione della digitazione dei campi password
- gestone della sessione di colloquio con il CES/CLI attraverso la macchina di Moore
Comandi Ben Formati
Molte delle parole chiave che costituiscono il linguaggio di costruzione dei comandi posso allungare così tanto la linea dei comandi da renderla difficilmente gestibile dalle sole dita dell'amministratore della sicurezza.
Per questo motivo CEI accetta anche contrazioni univocamente identificabili delle parole chiave del linguaggio che devono essere opportunamente espanse prima di essere mandate in elaborazione su CLI.
CEI controlla solo la sintassi del comandi ad eccezione dei comandi che necessitano dell'inserzione di una password.
In quest'ultimo caso CEI si preoccupa attivare l'ofuscatore a video.
Gestione degli Errori
La componente server fornisce un ErrorCode per ogni richiesta evasa che CEI si preoccupa di tradurre nei messaggi utente e negli stati della macchina di Moore più appropriati.
History dei Comandi
Ogni comando espanso e Ben Formato, prima di essere inviato al CES/CLI viene memorizzato in una lista circolare. Il controllo della lista avviene tramite l'uso dei tasti freccia.
Gestione del Terminale
Naturalmente sul terminale video vengono stampati i caratteri associati all'evento di pressione di un determinato tasto. Per poter ofuscare l'inserimento di una password e per poter rimappare la composizione di sequenze di tasti specifiche per scopi di gestione di ogni CEI abbiamo utilizzato la libreria termio.
Driver di Sessione
Prima di tutto definiamo un vettore booleano di stati:
- opening condition: TRUE se il canale secondarion non è ancora in uso;
- closing condition: TRUE se è stato eseguito con successo una operazione che chiude il canale secondario;
- config mode request: TRUE se viene richiesta l'esecuzione di un comando di abilitazione alla modalità di configurazione;
- non config mode request: TRUE se viene richiesta l'esecuzione di un comando di uscita dalla modalità di configurazione;
- exec request: TRUE se è trasmettere un comando al CLI server.
Definiamo ora gli stati dell'NFA per la macchina di Moore:
- I stato iniziale
- T stato terminale
- E stato errore di sessione
- S1,S2,S3 stati intermedi
Definiamo η la funzione che calcola la natura della richiesta da inoltrare alla CLI (verbi) in base agli stati del vettore booleano pocanzi definito:
| η | openinig request | closing request | config mode request | non config mode request | exec request |
|---|---|---|---|---|---|
| I | APR | ||||
| T | |||||
| E | |||||
| S1 | REG | APK | |||
| S2 | DEREG | LOCK | EXEC | ||
| S3 | UNLOCK | EXEC |
A questo punto la macchina di Moore ha determinato quale tipo di richiesta deve inoltrare al server.
Il server risponderà con dei valori che determinano l'alfabeto delle risposte.
Definiamo ora la funzione δ che individua il cambio di stato della macchina di Moore:
| δ | APR_ok | REG_ok | DEREG_ok | APK_ok | ERR | LOCK_ok | UNLOCK_ok | EXEC_ok | LOCK_ko |
|---|---|---|---|---|---|---|---|---|---|
| I | S1 | E | |||||||
| T | |||||||||
| E | |||||||||
| S1 | S2 | T | E | ||||||
| S2 | S1 | E | S3 | S2 | S2 | ||||
| S3 | S2 | S3 |
Dopo aver modificato il suo stato interno, la macchina di Moore modifica anche il comportamento del client consistentemente allo tipo di return code registrato nella risposta del server:
CES/CLI
CES è uno dei server della struttura freeLIX, i suoi compiti sono:
- gestire le sessioni;
- controllare privilegi di accesso
- effettuare le modifiche al S.O.
Gestione Sessioni
Tutte le comunicazioni tra processi utilizzano il paradigma del socket. Quando una istanza CEI cerca di iniziare la comunicazione con CES, CES istanzia una copia di se stesso (CLI) che utilizzerà, in maniera esclusiva con quel determinato CEI.
Controllo Privilegi
Alla partenza di freeLIX, MCS carica le configurazioni depositate in CCS. Prima dell'esecuzione di ogni singolo comando, CLI controlla che il livello dello user soddisfi i permessi codificati nei nodi della struttura di menoria di MCS.
Modifica del S.O.
Quando l'esecuzione del comando è autorizzata, CLI delega la modifica del S.O. eseguendo uno dei plugin di freeLIX. I plugin sono semplicemente degli script che svincolano freeLIX dall'evoluzione del S.O. e lo rendono, al tempo stesso, maggiormente flessibile alle esigenze dell'amministratore di rete esperto.
NAS
Evoluzione di CEI. NON ancora implementato.
Classi di Utenza
Esistono 18 diverse classi di utenza: una classe base, 15 livelli di abilitazione, una classe di configurazione e una classe di SuperConfigurazione equiparabile a root. Nella classe base, l'utente può eseguire un set limitato di comandi. Nei livelli di abilitazione, usualmente utilizzeremo il quindicesimo, l'utente potrà eseguire tutti i comandi abilitati nella classe base più un set di comandi più evoluti. Nella classe di configurazione l'utente potrà, oltre ai comandi dei livelli inferiori modificare la configurazione. Nella classe di SuperConfigurazione l'utente potrà dare i comandi direttamente al S.O. Solo un utente alla volta potrà assumere i privilegi del configuratore.
