FreeLIX

FeeLIX

Struttura SW

(Realizzato da pvb265, disponibile online)

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 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
• obfuscazione 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'obfuscatore 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 obfuscare 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 la 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_k
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. File:Pro.png

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.