Ricerche IT

Se si deve gestire un firewall Linux con iptables, in determinate situazioni può riverlarsi indispensabile poterne gestire il logging nel modo più lineare possibile; il passo più logico per raggiungere questo scopo è quello di effettuare un logging su file delle attività di iptables che si intende monitorare. Si tenga presente che questi passaggi sono stati effettuati su Debian Etch.

L’operazione consta di più passaggi:

1. configurazione di iptables per fare in modo che venga fatto il logging di determinati tipi di traffico su file;
2. installazione e configurazione di syslog-ng, che consentirà di specificare uno specifico file su cui redirigere il logging di iptables;
3. configurazione di logrotate per poter ruotare i file di log di iptables.

Configurazione di iptables

Per prima cosa, dobbiamo decidere quale tipo di traffico vogliamo monitorare, in questo caso, scegliamo di monitorare il traffico icmp verso l’ipotetica interfaccia esterna del nostro firewall. Se si prende come riferimento l’articolo precedente riguardante iptables, bisogna aggiornare lo script di iptables, caricando per prima cosa il modulo ipt_LOG tramite la direttiva:

modprobe ipt_LOG

Ora è possibile specificare un’istruzione per il logging del traffico ICMP sull’interfaccia esterna, assumendo che questa prenda il nome eth1:

iptables -A INPUT -i eth1 -p icmp -j LOG --log-level 4 --log-prefix='LOG_ICMP '

quest’istruzione è da inserire prima dell’eventuale direttiva che consente o nega il traffico ICMP verso l’interfaccia eth1. Da notare la direttiva log-prefix, che farà precedere le stringhe di logging da ciò che abbiamo specificato tra apici (nel nostro caso LOG_ICMP ). Con questo comando termina la configurazione di iptables.

Installazione e configurazione di syslog-ng

In questo secondo passaggio andremo a sostituire il server syslog classico con syslog-ng, un server syslog più evoluto che permette una gestione più raffinata dei messaggi di log provenienti da kernel e demoni. Prima di configurare syslog-ng, dobbiamo però fare in modo che i log di iptables non compaiano in console (che in pratica si traduce nella comparsa dei vari log sul monitor del PC), cosa decisamente fastidiosa: ciò è possibile editando il file /etc/sysctl.conf:

nano /etc/sysctl.conf

quindi, dobbiamo decommentare la riga 1 del seguente listato sostituendola con la riga 3:

1
2
3

#kernel.printk = 7 4 1 7
 
kernel.printk = 4 4 1 7

in tal modo, indicando il valore 4 in vece del valore 7, si indica che il logging a console viene abilitato solo per il logging di livello inferiore a 4, avendo indicato noi nello script di iptables che il nostro logging è di valore 4, la console rimarrà immacolata.

AGGIORNAMENTO
Un metodo alternativo per raggiungere lo stesso scopo è quello di editare il file /etc/default/syslog-ng decommentando l’ultima riga, che diventerà:

CONSOLE_LOG_LEVEL=4

al posto di 4, potremo mettere, nel caso, anche un numero inferiore fino ad arrivare a 1. Una volta riavviato il demone di syslog-ng, verrà modificato come visto in precedenza il file kernel.printk per prevenire la visualizzazione sulla console dei log di iptables.
FINE AGGIORNAMENTO

Ora, installiamo syslog-ng con il classico apt:

apt-get install syslog-ng

che non si limita ad installare syslog-ng ma disinstalla anche il classico syslog, di cui va a prendere il posto. A questo punto va configurato syslog-ng per far sì che i log non vadano a finire nei file /var/log/messages, /var/log/kern.log e /var/log/syslog, editando il file /etc/syslog-ng/syslog-ng.conf:

nano /etc/syslog-ng/syslog-ng.conf

dove bisogna aggiungere in fondo al file le seguenti righe:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# configurazione logging di iptables
 
destination df_firewall {
        file("/var/log/iptables.log");
};
 
filter f_firewall {
match("LOG_ICMP ");
};
 
log {
        source(s_all);
        filter(f_firewall);
        destination(df_firewall);
};

Le righe da 3 a 5 servono per parametrizzare il file dei log di iptables, le righe da 7 a 9 rappresentano il criterio con cui viene deciso, da parte di syslog-ng, quando redirigere le stringhe di logging verso il file specificato in precedenza attraverso la condizione

match("LOG_ICMP ")

mentre le righe da 11 a 15 rappresentano la direttiva vera e propria verso syslog-ng per loggare tutto ciò che proviene da iptables contenente la stringa “LOG_ICMP “.

Lasciando le cose in questo modo, il logging verso il file /var/log/iptables.log funziona perfettamente, però i log vengono inviati anche verso i file “canonici” di log del kernel. Per ovviare al problema, bisogna modificare il file /etc/syslog-ng/syslog-ng.conf in modo che syslog-ng non scriva i messaggi provenienti da iptables nei file indicati in precedenza; primo passo, la modifica del filtro f_kern:

1
2
3

filter f_kern { facility(kern); };
 
filter f_kern { facility(kern) and not match("LOG_ICMP "); };

dove la riga numero 1 viene sostituita dalla riga numero 3, così da evitare che le voci di log vadano a finire nel file /var/log/kern.log; il passo successivo riguarda la modifica della voce relativa al filtro f_syslog:

1
2
3

filter f_syslog { not facility(auth, authpriv); };
 
filter f_syslog { not facility(auth, authpriv) and not match ("LOG_ICMP "); };

dove andremo a sostituire la riga numero 1 con la riga numero 3, per impedire che il logging di iptables vada a popolare il file /var/log/syslog. Ora rimane da modificare il filtro f_messages, che da così

filter f_messages {
        level(info,notice,warn)
            and not facility(auth,authpriv,cron,daemon,mail,news);
};

diventa così

filter f_messages {
        level(info,notice,warn)
            and not facility(auth,authpriv,cron,daemon,mail,news)
                and not match ("LOG_ICMP ");
};

modifica che inibisce il logging di iptables nel file /var/log/messages. In tutte e tre le situazioni, abbiamo aggiunto la condizione

and not match ("LOG_ICMP ")

condizione che istruisce syslog-ng ad ignorare, per quel determinato filtro, tutti i log che contengono la stringa “LOG_ICMP “, per cui, se si modifica la configurazione di iptables utilizzando, per il logging, un prefisso diverso da quello indicato (tramite la direttiva log-prefix di iptables), tutte le segnalazioni finiranno nei file “normali” e non nel file /var/log/iptables.log che abbiamo creato.

Configurazione di logrotate

Tenendo le cose così come sono, con l’andare del tempo il file /var/log/iptables.log assumerà dimensioni sempre più grandi, rendendo quindi i log di difficile lettura. La soluzione al problema sta nell’istruire logrotate (che dovrebbe essere già presente in Debian Etch) per routare il nostro file di log personalizzato secondo i criteri che preferiamo. Prima di configurare logrotate, vediamo brevemente come funziona.

Logrotate ha un file di configurazione, /etc/logrotate.conf, in cui sono indicate le opzioni generali di configurazione, ed ha una directory, /etc/logrotate.d, in cui vi sono i file di configurazione riguardanti il logging delle singole applicazioni; questi file di configurazione vengono richiamati dalla direttiva presente nel file /etc/logrotate.conf

# packages drop log rotation information into this directory
include /etc/logrotate.d

Nel nostro caso, dovremo creare un file chiamato iptables nella directory /etc/logrotate.d, quindi editarlo per indicare a logrotate come routare il nostro file:

touch /etc/logrotate.d/iptables
nano /etc/logrotate.d/iptables

Nel file /etc/logrotate.d/iptables andremo ad inserire questo contenuto:

1
2
3
4
5
6
7
8

/var/log/iptables.log {
        weekly
        rotate 4
        compress
        notifempty
        missingok
        endscript
}

Vediamo di esaminare nel dettaglio le varie istruzioni del file: weekly indica che il file di log viene routato con cadenza settimanale, rotate 4 significa che vengono conservati 4 log già routati, compress specifica che i file di log routati vengono compressi, notifempty sta ad indicare a logrotate di non routare il file di log se questo è vuoto, missingok permette a logrotate di non segnalare errori se per qualche motivo il file di log non esiste, endscript indica semplicemente il termine delle istruzioni di configurazione per il file corrente. Per ulteriori informazioni sulle opzioni di logrotate è possibile consultare le pagine man di logrotate oppure gli ultimi due collegamenti nella sezione Link di riferimento di quest’articolo.

Ora non rimane che verificare nel tempo il corretto funzionamento di logrotate.

Link di riferimento

http://tuttodebian.blogspot.com/2008/05/iptables-and-syslog-how-to-log-in.html
http://www.linux.it/~rubini/docs/printk/printk.html
http://openskill.info/infobox.php?ID=779
http://www.uielinux.org/blog/14-usare-linux/87-ubuntu-professionale-usiamo-il-logrotate.html

N.B. Sono un principiante nella configurazione di firewall Cisco, per cui è possibile che abbia scritto delle imprecisioni: se così fosse, potete lasciare un commento per correggere le eventuali imprecisioni.

In una rete medio-piccola, una configurazione abbastanza diffusa quando si ha un collegamento ad Internet con più IP pubblici, prevede la messa in funzione di un firewall, il quale consente di:

• separare la rete pubblica dalla rete privata;
• proteggere la rete privata da intrusioni indesiderate;
• utilizzare un unico indirizzo IP pubblico (a parte il router), tramite NAT, per consentire l’accesso verso Internet alla LAN interna;
• monitorare e limitare il traffico in uscita;
• pubblicare servizi come Web server e Mail server;
• eventualmente connettere in VPN sedi remote.

Un firewall funzionale e robusto che si presta bene per questi scopi in infrastrutture non troppo "impegnative" è il Cisco ASA 5505. L’ ASA 5505 è il prodotto di fascia bassa dei firewall marchiati Cisco, che va a sostituire il PIX 501, ed è dotato di otto porte Ethernet, di una porta console, e di tre porte USB riservate per usi futuri. All’interno della confezione del firewall sono presenti il cavo console (da collegare ad un PC via porta seriale) e due cavi di rete. In questo articolo verrà descritto come compiere una configurazione di base del firewall, che avrà la funzione di connettere la rete LAN alla rete Internet, non aprendo nessuna porta verso l’esterno e consentendo a tutto il traffico di uscire dall’interno verso l’esterno. Lo schema di rete è il seguente, in cui sono mostrati anche gli indirizzi IP della rete locale e degli apparati di rete:

Come descritto nello schema, dobbiamo posizionare il firewall tra le rete locale ed il router Internet, per cui dobbiamo configurare il router cambiando gli indirizzi IP delle interfacce di rete, in questo caso Ethernet0/0 e Ethernet0/1 (corrispondenti alle porte 0 e 1 dell’ASA); per farlo, il primo passaggio è quello di connettere, tramite il cavo console, la porta seriale del PC con la porta console del firewall, quindi utilizzare un emulatore di terminale per poter interagire con l’IOS (il sistema operativo Cisco presente sull’ASA) del firewall. Come descritto tempo fa, è possibile utilizzare Putty per svolgere questa funzione, ed è consigliabile utilizzare l’ultimo rilascio del programma, poiché, per quanto mi riguarda, lo ritengo molto più stabile per questo compito rispetto alle release precedenti. Una volta connessi in console, ci si presenterà un prompt del tipo

ciscoasa>

e, giunti qui, non rimane che configurare il firewall! Per prima cosa, controlliamo le caratteristiche del firewall, le porte presenti e la versione di IOS installata con il comando

> show version

Ora possiamo entrare in privileged exec mode, quella modalità che ci dà un accesso completo al firewall ed alla sua configurazione. Per entrare in questa modalità, digitare il comando

> enable

quindi premere il tasto Invio alla richiesta di password. Se la password non viene accettata, significa che la configurazione predefinita del firewall è stata modificata, quindi bisognerà effettuare una operazione di recovery password del dispositivo per poterne rientrare in possesso. Entrati in priviliged exec mode, è possibile, anche per semplice curiosità, dare un’occhiata alla configurazione corrente, digitando il comando

# show running-config

Notare che il prompt ha l’ultimo carattere trasformato in cancelletto (#) rispetto al precedente simbolo di maggiore (>), ciò indica il passaggio in privileged mode. Ora è possibile entrare nella modalità in cui inserire i comandi IOS di configurazione effettiva del firewall con il comando

# configure terminal

Il prompt cambia di nuovo forma, mettendo dopo il nome host la dicitura (config)# per indicare che siamo nella modalità di inserimento dei comandi di configurazione del firewall. Giunti qui, impostiamo il nome host del firewall, utile per identificare in un attimo su quale dispositivo stiamo lavorando, col comando

(config)# hostname firewalltest

Adesso è possibile assegnare gli indirizzi IP alle interfacce di rete dell’ASA, e qui è necessario fare una premessa: come già esposto, l’ASA 5505 ha otto interfacce ethernet, che compongono uno switch Layer 2, quindi non c’è una separazione fisica tra le porte di rete, cosa che in un firewall è da evitare; il Cisco ASA risolve il "problema" assegnando ogni interfaccia di rete ad una VLAN, in modo da separare logicamente le porte ethernet. Tenere presente che con una licenza base, l’ASA 5505 consente di creare al massimo tre VLAN nella modalità routed (la modalità predefinita), così da poter configurare il firewall che separa la rete LAN, la rete Internet ed eventualmente una DMZ. Esaminando la configurazione di default, si può notare che sono previste due VLAN già configurate, Vlan1 e Vlan2, dove Vlan1 rappresenta l’interfaccia di rete sulla LAN, con un contesto di sicurezza 100 (porta sicura) e con indirizzo IP 192.168.1.1, mentre Vlan2 rappresenta l’interfaccia di rete sulla WAN, con un contesto di sicurezza 0 (interfaccia non sicura) e un indirizzo IP assegnato dal server DHCP del provider Internet. Nella configurazione proposta, non cambieremo le impostazioni di base, per cui sfrutteremo la configurazione esistente che prevede due VLAN con due diversi contesti di sicurezza, ma cambieremo gli indirizzi IP come mostrato nello schema di rete; per far questo però, occorre tenere presente che nella configurazione predefinita è attivo un server DHCP, per cui non possiamo cambiare l’indirizzo dell’interfaccia Vlan1 se prima non modifichiamo la configurazione del server DHCP, cambiano l’ambito o eliminandolo, personalmente preferisco tenere il server DHCP della LAN su un server di rete e non sul router, per cui, disattiviamo il server DHCP:

(config)# no dhcpd address 192.168.1.2-192.168.1.254 inside
(config)# no dhcpd enable inside

Ora possiamo configurare l’interfaccia Vlan1 come segue:

(config)# interface vlan1
(config-if)# ip address 192.168.40.254 255.255.255.0
(config-if)# exit

Configurata Vlan1, passiamo alla configurazione di Vlan2. Come esposto prima, Vlan2 cerca un server DHCP del provider Internet, poiché evidentemente Cisco presuppone che il firewall sia connesso ad Internet tramite modem Ethernet, mentre in realtà, nella nostra configurazione, l’ASA è connesso direttamente al router, per cui l’indirizzo IP di Vlan2 è fisso. A tal proposito, per prima cosa disabiliteremo l’assegnazione dei valori dei server DNS e WINS sull’interfaccia outside (Vlan2), quindi procederemo all’assegnazione dell’indirizzo IP prestabilito:

(config)# no dhcpd auto_config outside
(config)# interface vlan2
(config-if)# ip address 111.1.1.2 255.255.255.248
(config-if)# exit

Ora possiamo controllare se la configurazione di rete, almeno dal punto di vista della LAN, è corretta, semplicemente pingando da un PC in LAN l’indirizzo IP del firewall:

ping 192.168.40.254

Se riceviamo la risposta dal firewall, significa che questa prima parte della configurazione è andata a buon fine. Per fare la stessa prova sull’interfaccia outside, o abbiamo un PC sulla stessa rete del firewall (e quindi con un IP pubblico), oppure dobbiamo provare a pingare l’ASA dal router; in genere, tutti i router hanno una sezione di diagnostica dov’è possibile effettuare un ping verso un host, in caso di router Cisco, è possibile effettuare il ping direttamente con il comando ping, che esiste anche su IOS.

Giunti fin qui, dobbiamo completare la configurazione di rete indicando al firewall il proprio gateway predefinito, nel nostro caso il router che consente il collegamento alla rete Internet:

(config)# route outside 0.0.0.0 0.0.0.0 111.1.1.1 1

dove indichiamo che, partendo dall’interfaccia outside, per tutte le destinazioni che non appartengono alla nostra rete, il firewall inoltrerà le richieste verso il router 111.1.1.1 con metrica 1. Eseguito questo comando, è possibile effettuare un ping verso l’indirizzo IP 66.102.9.99 (Google), che ci dovrebbe rispondere senza problemi, se così non è, c’è un errore nella progettazione della rete, o nella programmazione del firewall, o nella connessione fisica tra gli apparati. Arrivati a questo punto, è bene ricordare che i comandi di configurazione fin qui impartiti hanno un effetto immediato sulla configurazione dell’ASA, configurazione però che non viene mantenuta in caso di riavvio dell’apparato, poiché non viene modificata la configurazione di startup presente sulla memoria flash del firewall; per salvare in modo permanente la configurazione, utilizzare il comando

# write memory

Per impartire questa direttiva, sono uscito dal privileged exec mode, ma il comando ha effetto anche in privileged mode; quando si configura il firewall, ricordarsi di dare questo comando di tanto in tanto, giusto per non perdere d’un botto la configurazione già fatta.

A questo punto i client della rete locale possono navigare sul web, poiché il natting è già preconfigurato sull’apparto, per cui la configurazione di rete sarebbe terminata… ma in realtà, sempre dai PC in LAN, non è possibile pingare o fare un traceroute verso host presenti sulla rete Internet, poiché l’ASA non permette in modo predefinito al protocollo ICMP di attraversare le due diverse interfacce; per ovviare al problema (problema fastidioso, che limita molto la possibilità di fare troubleshooting di base in caso di problemi), è necessario configurare una access list (ACL) che consenta il traffico ICMP da qualsiasi sorgente verso qualsiasi destinazione, quindi bisogna applicare l’ACL sull’interfaccia outside dell’ASA:

(config)# access-list acl_icmp extended permit icmp any any
(config)# access-group acl_icmp in interface outside

Ora possiamo considerare terminata la configurazione di rete del firewall, rimangono però da sistemare alcuni aspetti legati alla sicurezza, l’accesso via ssh al firewall, e la riconfigurazione dell’accesso via http(s) all’ASA. Per prima cosa, assegniamo una password per entrare in privileged exec mode con il comando

(config)# enable password testopassword

dove al posto di testopassword va indicata la password scelta per entrare in privileged mode. Ora bisogna assegnare una password per l’accesso via telnet o ssh, che ci servirà per proteggere l’accesso via ssh all’ASA:

(config)# passwd testopassword

dove al posto di testopassword va indicata la password per l’accesso via rete al firewall. Assegnate queste password, vediamo come abilitare l’accesso via ssh, da preferirsi all’accesso via telnet, poiché quest’ultimo non prevede la possibilità di crittografare le connessioni, col traffico quindi perfettamente sniffabile, password comprese:

(config)# crypto key generate rsa modulus 1024
(config)# ssh 192.168.40.0 255.255.255.0 inside
(config)# ssh timeout 30
(config)# ssh version 2

Il primo comando serve per creare le chiavi di sicurezza richieste da SSH con una crittografia a 1024 bit, il secondo comando serve per abilitare l’accesso via SSH all’intera rete locale (giocando con le subnet è possibile restringere ulteriormente l’accesso al firewall), il terzo comando indica il timeout espresso in minuti, mentre il quarto comando serve per forzare l’utilizzo del protocollo ssh versione 2. Utilizzando un qualsiasi client SSH (come Putty), è ora possibile, se l’host appartiene alla rete LAN, connettersi all’ASA utilizzando l’utente pix e la password indicata con il comando passwd.

Ora rimane da vedere l’accesso via http(s) al firewall. La configurazione predefinita abilita questo tipo di accesso alla rete 192.168.1.0/24, rete che non esiste più, quindi si tratta di eliminare l’impostazione precedente e ricrearla utilizzando l’indirizzamento di rete corretto:

(config)# no http 192.168.1.0 255.255.255.0 inside
(config)# http 192.168.40.0 255.255.255.0 inside

Siamo arrivati al termine della configurazione di base del firewall, quindi la nostra rete locale ha ora il pieno accesso alla rete Internet, situazione che presenta diversi svantaggi, visto che sarebbe il caso di restringere ulteriormente l’accesso ad Internet agli utenti della rete locale, argomento che esula dagli scopi di quest’articolo.

Quando su un PC siamo in presenza di sintomi chiari di un’infezione da malware, e riusciamo a salvarci un file che riteniamo veicolo dell’infezione, possiamo utilizzarlo per poter fare con calma alcune indagini, allo scopo di cercare di capire il più possibile su come funziona il malware in questione. La prima preoccupazione dev’essere quella per testare il file infetto in sicurezza, senza quindi intaccare i dati ed i programmi che utilizziamo normalmente. Per evitare problemi, il modo migliore sarebbe quello di utilizzare uno o più PC dedicati proprio a sperimentazioni di vario tipo, altrimenti, se non si dispone dei mezzi/spazi/risorse per avere un ambiente di test, è possibile utilizzare un software di virtualizzazione come VMWare o Virtual PC, con cui creare una o più macchine virtuali a scopi di testing.

Nella mia prova, utilizzerò VMWare, in cui prima di ogni altra cosa utilizzerò la funzione di snapshot, che mi permetterà di tornare alla situazione pre-test su quelle macchine virtuali che utilizzerò per le operazioni di testing. Il passo successivo consiste nel copiare il presunto file infetto nella macchina virtuale per fare un primo esame, che consiste nell’esaminare il file col servizio VirusTotal, che permette di fare una scansione antivirus con una pletora di motori di scansione di diversi produttori, in modo da identificare il tipo di malware con cui abbiamo a che fare. Com’è possibile vedere dall’immagine, il malware in questione è il trojan Win32.Dialer.tl, di cui, dopo una ricerca con Google, possiamo trovare alcune informazioni sul suo funzionamento sul sito ThreatExpert.

Figura 1

Ora sappiamo quindi che il file in esame è un trojan e conosciamo alcune caratteristiche peculiari di questo malware, per cui abbiamo già un’idea di cosa ci aspetta; in particolare, essendo anche un dialer, il trojan andrà a modificare il file rasphone.pbk per creare una nuova connessione di rete (comportamento appunto tipico di un dialer), quindi creerà un nuovo processo in memoria, modificherà alcune voci di registro legate ad Internet Explorer ed infine creerà un mutex che impedirà che il processo infetto sia attivo più volte in memoria.

Raccolte informazioni sul malware, possiamo passare alla parte "pratica". Per prima cosa, scarichiamo alcuni software che ci possono essere utili per capire il comportamento del trojan in questione una volta entrato in azione:

Process Monitor: software di Sysinternals (ora acquisita da Microsoft) che ci permette di vedere in tempo reale ciò che avviene sulla nostra macchina, in particolare controlla quali processi sono in esecuzione e le variazioni effettuate sul registro di sistema;

TCPView: altra utility Sysinternals che consente di verificare le connessioni di rete attive ed in ascolto, in pratica, un’interfaccia grafica per il comando netstat;

Wireshark: sniffer di rete che permette di monitorare e registrare il traffico di rete in entrata ed in uscita da un PC.

Installate o copiate queste utilità sulle due macchine virtuali, cambiamo indirizzo IP ad entrambe in modo tale che non comunichino con la rete del nostro sistema principale e che non possano uscire verso Internet, dopodiché facciamo partire Process Monitor e TCPView e lanciamo il file infetto (cosa DA NON FARE se non a scopi di testing ed avendo cura di non infettare le proprie macchine di produzione e soprattutto di non creare traffico inutile e potenzialmente dannoso sulla rete Internet). Una volta lanciato l’eseguibile infetto dal disco E:, lasciamo fare al PC, dando ogni tanto un’occhiata a TCPView, e dopo qualche minuto, possiamo salvare il log relativo a Process Monitor per osservarlo con calma; per salvare il log, dalla finestra di Process Monitor cliccare su File, quindi su Save e comparirà la finestra illustrata in Figura 2:

Figura 2

La cosa più evidente è una certa attività relativa al file infetto 9268125.exe, che va a creare una connessione di rete ad un numero internazionale andando a modificare il file %CommonAppData%\Microsoft\Network\Connections\Pbk\rasphone.pbk, ed inoltre si può notare dalla Figura 3 che il file in questione va a ricercare diverse librerie nella stessa directory da cui è stato lanciato (E:\), non trovandole poiché queste librerie si trovano nella cartella di sistema C:\Windows\System32, quindi per fare in modo che il dialer agisca nel pieno delle proprie facoltà (dannose), probabilmente dovrei far partire il file dalla cartella System32.

Figura 3

Forse per il fatto di aver "sbagliato" la posizione del file infetto da eseguire, gli effetti sono stati piuttosto limitati, infatti, per quanto ho potuto constatare, di fatto l’infezione consiste semplicemente nella creazione del dialer di nome "Internet", inutile e causa di scarsi problemi se in presenza di un collegamento ad Internet di tipo xDSL o in fibra. Questa è una prima analisi superficiale fatta solamente con lo strumento File Monitor, più avanti proverò ad analizzare un worm, file maligno per cui saranno utili le utilità TCPView e Wireshark.

Quando si gestisce un sistema informativo, bisogna fare in modo che questo sia protetto da attacchi più o meno subdoli. Una delle precauzioni principali da prendere riguarda la gestione delle credenziali d’accesso al sistema, che devono rispondere a specifici criteri di sicurezza che prevengano accessi non autorizzati, in ottemperanza alle elementari regole di sicurezza informatica ed al D. Lgs. 196 del 2003 conosciuto anche come "Testo Unico sulla Privacy". Pur esistendo dispositivi che permettono di fornire le proprie credenziali in modo sicuro, come ad esempio smart card e dispositivi biometrici, in realtà il metodo più usato consiste ancora nel fornire un’accoppiata Nome Utente - Password come credenziali d’accesso al sistema informativo. In particolare, è centrale il problema di come gestire le password associate ad ogni account, che rappresentano il punto debole e maggiormente attaccabile da parte di un malintenzionato, per cui è necessario prendere alcuni accorgimenti nella scelta e gestione delle password:

• segretezza della password: la password deve essere segreta, e nota solamente al legittimo utilizzatore di quelle determinate credenziali d’accesso ed al responsabile delle password, inoltre, l’utente non deve lasciare in giro appunti o post-it con in bella mostra la propria password, come troppo spesso succede;
• lunghezza della password: se un ipotetico "attaccante" cerca di scoprire la password di un utente tramite "tentativi" automatizzati (il cosidetto attacco a forza bruta), l’attacco avrà maggior successo se la password attaccata è breve, a differenza di una password lunga che, ovviamente, per essere indovinata necessita di un maggior numero di tentativi;
• complessità della password: l’utente, scegliendo una password, dovrà fare in modo che questa non contenga riferimenti a sé stesso o all’ambito familiare, infatti un malintenzionato, utilizzando eventualmente tecniche di ingegneria sociale, potrà scoprire riferimenti della vita privata dell’utente che riutilizzerà immediatamente come tentativo di accesso non autorizzato, se poi l’attaccante è un nostro collega di lavoro (cosa possibile anche se non frequente) non dovrà sforzarsi molto per conoscere particolari che ci riguardano; altro accorgimento in questo senso può essere quello di utilizzare caratteri non standard (come segni di interpunzione o spazi) nella composizione della password, misura utile anche nei casi di attacchi "brute force";
• durata della password: una password, per essere considerata sicura, dev’essere cambiata entro un periodo di tempo ragionevole, ciò rende la vita più difficile ad un malintenzionato che intende "rubare" la password, inoltre consente di "richiudere fuori" un attaccante venuto in possesso delle nostre credenziali, anche se in questo caso probabilmente il danno è già stato fatto

Considerata l’importanza di queste politiche di protezione, non si può delegarne l’osservanza alla buona volontà dell’utente finale, dev’essere l’amministratore di sistema ad imporre queste policy a livello centralizzato, in modo tale che l’utente possa solamente trovarsi a scegliere se autenticarsi sul sistema informativo secondo le regole impostate dal sysadmin o se mollare tutto e passare la giornata al bar.
Per quanto concerne una piattaforma Windows Server, in un dominio Active Directory è possibile definire e imporre una policy delle password valida a livello dell’intero dominio. Per definire i criteri relativi alle password, aprire la console "Active Directory Users and Computers", portarsi alla radice del dominio e quindi cliccare col tasto destro e scegliere la voce Properties, quindi andare sulla scheda "Group Policy", comparirà una finestra simile a quella mostrata nella figura sottostante (i passaggi saranno diversi se si utilizza lo snap-in di Group Policy Management, ma il punto d’arrivo è il medesimo):

Si può vedere che esiste già un criterio di gruppo per il dominio (Default Domain Policy), che però non sarà quello che andremo a modificare, poiché Microsoft consiglia di non utilizzare il criterio predifinito per queste operazioni, ma di creare un nuovo criterio di gruppo e modificare quello, per cui, tramite il pulsante New, creare un nuovo criterio di gruppo a cui assegnare il nome "Password Policy", quindi modificare il criterio appena creato cliccando il tasto Edit, che farà comparire l’editor del criterio di gruppo prescelto; i parametri che ci interessano sono quelli definiti in "Computer Configuration" - "Windows Settings", come mostrato nella seguente immagine:

In particolare, dovremo far riferimento, inizialmente, alla sezione "Security Settings" - "Account Policies", e lì scegliere la voce "Password Policy", in cui andranno impostate le seguenti opzioni:

• Enforce password history: serve per definire il numero di password "ricordate" dal server, ciò significa che prima di poter riutilizzare una password bisogna cambiare password (la quale ovviamente sarà sempre diversa) almeno x volte, dove per x si intende il valore impostato per questo parametro, che nella maggior parte dei casi secondo me può essere uguale a 10
• Maximum password age: indica il numero di giorni di validità della password, passato questo periodo, verrà imposto il cambio di password, pena l’impedimento all’accesso sul client da parte dell’utente finale; il valore consigliato non deve superare i 90 giorni, che è il limite massimo consentito dal Testo unico sulla privacy in caso di trattamento di dati sensibili, mentre Microsoft consiglia di non superare i 42 giorni di validità della password, che è anche l’impostazione predefinita in caso di attivazione di questa password policy
• Minimum password age: questa policy viene automaticamente attivata quando si attiva l’impostazione "Maximum password age" mettendo come impostazione predefinita 30 giorni; in realtà, questo settaggio consente di specificare la validità minima della password, cioé il numero minimo di giorni in cui non è consentito un cambio della password a partire dalla data di creazione della stessa, quindi è bene specificare un valore più basso per consentire un più tempestivo cambio della password che si può rendere necessario per diversi motivi, infatti Microsoft consiglia di impostare questo valore a 2
• Minimum password length: definisce la lunghezza minima della password intesa come numero di caratteri; secondo il Testo Unico sulla Privacy la lunghezza minima della password deve essere di otto caratteri, per cui ci possiamo attenere a questa prescrizione, in modo tale che l’utente non possa utilizzare password più corte di otto caratteri, ovviamente nessuno vieta di utilizzare password composte da più di 8 caratteri
• Password must meet complexity requirements: impostazione che obbliga l’utente ad immettere password utilizzando criteri di complessità in grado di rendere una password "sicura": in particolare, la password deve essere lunga almeno sei caratteri (precauzione superata dagli 8 caratteri specificati nel parametro "Minimum password length"), non deve contenere tre o più caratteri che fanno parte del nome utente, e deve includere almeno tre di cinque categorie di caratteri:
  • lettere dalla A alla Z maiuscole
  • lettere dalla a alla z minuscole
  • cifre comprese tra 0 e 9
  • segni di interpunzione e caratteri non alfanumerici (virgola, punto e virgola, $, %, ecc…)
  • caratteri unicode (simboli)

L’impostazione di queste opzioni consente di definire dei criteri di protezione validi per tutto il dominio, per cui, ogni utente che si autentica sul dominio, sarà "costretto" a seguire queste regole, ciò fa sì che, almeno da questo punto di vista, non ci siano utenti che mettono a rischio la sicurezza del sistema informativo semplicemente facendosi da sé le regole di accesso al sistema. Di importanza fondamentale rimane però la sensibilizzazione degli utenti riguardo queste tematiche, troppo spesso accade che l’utente finale comunichi le proprie credenziali ai colleghi con motivazioni del tipo "non ho nulla da nascondere", così come altrettanto spesso si vedono post-it appiccicati al monitor con in bella evidenza la propria password; ciò accade perché gli utenti non hanno ben chiaro che vanno protette non (solo) le informazioni personali, ma i dati personali o sensibili di terzi che si trattano col lavoro di tutti i giorni.

Link di riferimento: applicazione dell’utilizzo di password complesse nell’organizzazione

Quando si fa un backup su Windows Server 2003 utilizzando l’utilità integrata (ntbackup), può capitare che per qualche motivo non venga eseguito il backup; le cause possono essere varie, ed a questo proposito è bene controllare il log di ntbackup, che di solito descrive, seppur in modo striminzito, le ragioni del mancato salvataggio. Se il log dà un responso simile a questo:

Backup Status
The requested media failed to mount. The operation was aborted.

e nel log degli eventi compare un evento con Id 168 e l’origine Removable Storage Service, ciò significa che per qualche ragione il servizio Removable Storage non riesce a comunicare con l’unità di backup. In questo caso, una possibile soluzione consiste nel disinstallare da Gestione periferiche (Device manager) l’unità di backup e nel successivo riavvio del server, in modo tale che Windows reinstalli l’unità di backup appena disinstallata; fatto questo, se tutto va bene avremo di nuovo il nostro backup funzionante.

Se si dispone di uno o più indirizzi IP pubblici statici con la propria connessione ad Internet, è abbastanza consueto che si voglia approfittarne per pubblicare un proprio server Web, un proprio server di posta, o altri servizi che necessitano di un IP pubblico statico, come una VPN. In questi casi, una buona politica di sicurezza è far passare tutto il traffico diretto verso uno di questi servizi pubblicati attraverso un firewall, che poi ridirigerà le richieste verso un server posto verso la rete "interna", che prenderà il nome di DMZ (zona demilitarizzata), una rete "intermedia" che è posta tra la rete pubblica (Internet) e la rete locale e su cui saranno posti solamente quei server che devono pubblicare servizi verso Internet, oltre ad un eventuale firewall che connetta LAN e DMZ.

Per fare in modo che il firewall "esterno" rediriga le richieste verso il/i server in DMZ, esiste un meccanismo chiamato "port forwarding", che dal firewall esterno riceve la comunicazione in ingresso su una determinata porta con un determinato protocollo di trasporto, e la "rimbalza" verso il server in DMZ con lo stesso protocollo di trasporto e su una porta che spesso è identica a quella della richiesta originaria, ma che può anche cambiare.

Se si utilizza un firewall Linux, il port forwarding è impostato tramite iptables, che oltre a fungere da firewall è perfettamente in grado di gestire anche la redirezione del traffico. In particolare, si prenda in esame una configurazione di iptables come quella mostrata qui, dove la cosa di cui tenere conto quando si configura il port forwarding, è che il comportamento predefinito relativo alla catena di FORWARD consiste nel blocco del traffico, per cui, oltre all’istruzione necessaria per indicare la redirezione vera e propria, è necessario impostare una regola di FORWARD  che abilita il traffico dall’interfaccia esterna (eth1) alla DMZ (la cui interfaccia di rete definita sul firewall Linux è eth0) solamente per il tipo di richiesta necessaria. Si consideri la pubblicazione di un server Web che risponde alla canonica porta 80, e la cui interfaccia di rete in DMZ ha indirizzo IP 192.168.20.1; questa esigenza viene soddisfatta scrivendo queste due righe di configurazione di iptables:

iptables -A FORWARD -i eth1 -o eth0 -p tcp –dport 80 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp -i eth1 –dport 80 -j DNAT –to 192.168.20.1:80

A questo punto, se dall’esterno si digita in un browser l’indirizzo IP (o il corrispondente nome host) dell’interfaccia eth1, si vedrà il sito pubblicato tramite il port forwarding di iptables.

Può capitare, avendo un sito web composto da diverse directory e/o sottodirectory, di dover consentire l’accesso ad una particolare directory solamente ad alcuni utenti. Avendo un web server come Apache su piattaforma Linux (le informazioni indicate di seguito le ho provate su una Debian Etch), è possibile utilizzare un file .htaccess, da creare nella directory a cui si vuole limitare l’accesso, per raggiungere lo scopo prefisso.

Il primo passo consiste appunto nella creazione del file .htaccess e nell’assegnazione dei corretti permessi al file stesso:

# touch /var/www/sito/dirProtetta/.htaccess
# chmod 644 /var/www/sito/dirProtetta/.htaccess

Fatto questo, editare il file .htaccess col proprio editor preferito inserendo queste righe:

AuthName "Area protetta"
AuthType Basic
AuthUserFile /var/www/sito/dirProtetta/.htpasswd
<Limit GET PUT POST>
Require valid-user
</Limit>

L’istruzione nella prima riga rappresenta il titolo della finestra di richiesta autenticazione, la seconda riga indica invece il tipo di autenticazione alla directory, cioé l’autorizzazione di tipo Basic, che consente il passaggio in chiaro del traffico di autenticazione, a differenza dell’autenticazione di tipo Digest; la terza riga specifica il percorso del file .htpasswd, che altri non è che il file contenente le accoppiate username -> password degli utenti a cui è consentito autenticarsi. Di seguito abbiamo il tag <Limit>, con gli attributi GET, PUT e POST che rappresentano le operazioni consentite in relazione alla directory (rispettivamente download, upload e invio informazioni tramite form), al cui interno vi è l’istruzione "Require valid-user" che dice ad Apache di consentire l’accesso alla directory solamente agli utenti riconosciuti come validi, cioé che hanno fornito le corrette credenziali d’accesso.

Eseguiti questi passaggi, bisogna creare gli utenti del caso tramite il comando htpasswd. La creazione del primo utente comporta anche la creazione del file .htpasswd, tramite questo comando:

# htpasswd -c /var/www/sito/dirProtetta/.htpasswd utente1

Digitato questo comando, verrà chiesta per due volte la password da assegnare all’utente, e contestualmente verrà creato il file .htpasswd nella directory specificata con l’opzione -c; a questo file vanno assegnati adeguate autorizzazioni, in particolare il gruppo www-data (il gruppo che contiene l’utente omonimo che esegue il demone apache2) dovrà poter accedere al file almeno in lettura:

# chown root:www-data /var/sito/dirProtetta/.htpasswd
# chmod 640 .htpasswd

Ora possiamo creare gli altri utenti in questo modo:

# htpasswd /var/www/sito/dirProtetta/.htpasswd utente2

Creati gli utenti, abbiamo fatto quasi tutto; l’ultimo passaggio consiste nel modificare la configurazione di Apache in modo tale che sia consentito l’accesso ai file .ht per la directory che vogliamo proteggere, infatti, almeno in Debian (non so se è così anche con altre distribuzioni), l’accesso ai file .ht è inibito per default, quindi bisogna dire ad Apache che vogliamo sovrascrivere questa impostazione limitatmente alla directory specifica. In particolare, cercare all’interno del file /etc/apache2/apache2.conf il tag <Files> in modo tale che la configurazione finale sia questa:

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
</Files>

<Directory /var/www/sito/dirProtetta/>
    AllowOverride AuthConfig Limit
</Directory>

dove il tag <Directory> rappresenta appunto la sovrascrittura delle impostazioni date all’interno del tag <Files>.

E’ tutto, ora quando un utente accede a questa particolare directory del sito si ritroverà davanti alla richiesta di inserimento di username e password che Apache dovrà autenticare o meno.

E’ ormai una pratica consolidata, in una rete aziendale, quella di avere un firewall perimetrale attraverso cui passa tutto il traffico in uscita della rete locale, e che regola il traffico in arrivo dall’esterno. La situazione ideale è quella di permettere il traffico in uscita verso Internet e di bloccare tutto il traffico in ingresso da Internet ad eccezione delle risposte alle richieste generate all’interno della rete locale, poi ovviamente succede sempre che devi aprire una porta per il tal servizio, poi l’altro vuole l’accesso remoto, quindi magari pensi che ci starebbe bene una VPN, ecc…

Esistono diversi firewall hardware che svolgono ottimamente questo compito, ma se abbiamo già disponibile un vecchio PC con due schede di rete, possiamo costruirci in modo autonomo un firewall utilizzando una qualsiasi distribuzione Linux. Un’ottima distribuzione da utilizzare per questo scopo è una Debian con installato solamente il sistema di base, infatti tutto ciò che serve per gestire il firewall è compreso nel kernel e più precisamente nel componente Netfilter, che permette appunto di gestire firewall e natting sulla propria macchina Linux tramite diverse regole che vengono definite dall’amministratore tramite il programma iptables.

Iptables raggruppa logicamente i pacchetti in transito sul firewall in base al loro "comportamento" e li suddivide in tre catene generali: INPUT (i pacchetti in ingresso), OUTPUT (i pacchetti in uscita) e FORWARD (i pacchetti in transito tra una scheda di rete e l’altra), quindi, all’interno di queste tre catene, è possibile regolare il traffico di rete in modo anche molto sofisticato. Nel nostro caso invece dovremo semplicemente creare un firewall e non avremo bisogno di un elevato grado di sofisticazione.

Il nostro firewall si posiziona tra la rete locale ed il router Internet che avrà un indirizzo IP pubblico, per cui, il firewall avrà un’interfaccia di rete chiamata eth0 con un indirizzo IP valido sulla LAN, ed un’interfaccia di rete eth1 connessa direttamente col router e con un indirizzo IP pubblico assegnato in grado di comunicare con il router; a questo punto possiamo cominciare con la definizione delle regole del nostro firewall.

Per farlo, creiamo un piccolo script che posizioniamo nella directory /etc/default/ (in realtà penso si possa posizionare più o meno ovunque, io lo metterei comunque dentro /etc) chiamato semplicemente firewall (o comunque lo vogliamo chiamare), quindi lo rendiamo eseguibile e lo andiamo ad editare:

# touch /etc/default/firewall
# chmod 755 /etc/default/firewall
# nano /etc/default/firewall

Come primo passo, dobbiamo abilitare il "routing" tra le due schede di rete, scrivendo all’interno del file l’istruzione

echo 1 > /proc/sys/net/ipv4/ip_forward # abilita il routing tra le due schede di rete

Ora dobbiamo cancellare qualsiasi altra impostazione precedente data a Netfilter e specificare il comportamento predefinito delle tre catene principali:

iptables -F #cancella le impostazioni delle tre catene principali
iptables -X #cancella eventuali catene personalizzate
iptables -P INPUT DROP #rifiuta le connessioni in ingresso
iptables -P OUTPUT DROP #rifiuta le connessioni in uscita
iptables -P FORWARD DROP #rifiuta le connessioni in transito

Trattandosi di un firewall, dobbiamo grossolanamente specificare che le connessioni in uscita sono abilitate mentre non lo sono quelle in ingresso ed in transito, per evitare che le connessioni richieste dalla rete Internet verso la rete LAN possano essere accettate; in questo modo però non sono accettate nemmeno le richieste di connessione dalla rete LAN verso il firewall, ed anche se fossero accettate, non riuscirebbero ad arrivare all’interfaccia eth1 a causa del comportamento predefinito della catena FORWARD, si tratta quindi di raffinare il comportamento del firewall. Inoltre, in questo caso, blocchiamo anche le connessioni in uscita, che non è quel che ci serve, ma come politica predefinita è più sicura, poiché se un pacchetto in uscita non sa come comportarsi, viene scartato. Come prima cosa, accettiamo le connessioni in ingresso su eth0 provenienti dalla nostra LAN, non strettamente necessario ma sicuramente molto utile per amministrare il firewall:

iptables -A INPUT -s 192.168.10.0/24 -i eth0 -j ACCEPT #accetta le connessioni in ingresso dalla propria LAN

ora dobbiamo permettere che i pacchetti in transito da eth0 a eth1 non vengano filtrati dal firewall, quindi dobbiamo fare in modo che i pacchetti di ritorno di connessioni generate dalla nostra rete locale possano transitare nella direzione opposta, cioè da eth1 a eth0:

iptables -A FORWARD -s 192.168.10.0/24 -i eth0 -o eth1 -j ACCEPT #permette il transito di pacchetti provenienti dalla nostra rete locale con destinazione il mondo esterno
iptables -A FORWARD -i eth1 -o eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT #consente ai pacchetti di ritorno di transitare da eth1 a eth0 solo se la connessione era stata già stabilita

Così facendo, i client possono accedere ad Internet ma il firewall non può, cosa che non è positiva visto che di tanto in tanto è necessario aggiornare la nostra distribuzione, quindi vanno aggiunte queste due righe, di cui la seconda ha effetto anche per :

iptables -A INPUT -i eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT #consente ai pacchetti generati direttamente dal firewall di tornare indietro
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE #abilita il natting in modo tale che tutti gli IP mittente vengano cambiati con l’IP di eth1

A questo punto, bisogna fare due operazioni, la prima permettere che i pacchetti che arrivano in ingresso su eth0 possano tornare verso la rete locale (operazione necessaria essendo la catena OUTPUT impostata su DROP come comportamento predefinito), quindi, per fare uscire il firewall verso Internet, bisogna che l’interfaccia eth1 sia abilitata in uscita:

iptables -A OUTPUT -d 192.168.10.0/24 -o eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT #consente l’invio dei pacchetti di risposta generati in seguito a richieste della rete locale
iptables -A OUTPUT -o eth1 -j ACCEPT #consente il transito dei pacchetti in uscita da eth1

Ora i nostri client e il nostro firewall sono in grado di navigare, ovviamente però i client dovranno avere come default gateway l’indirizzo IP di eth0 del firewall. Per rendere attive queste impostazioni, è sufficiente lanciare lo script appena creato, il problema è che così facendo le modifiche andrebbero perse al successivo riavvio del firewall, per cui, è possibile richiamare questo script dal file /etc/network/interfaces in modo da applicare le regole di iptables ad ogni riavvio della rete, e quindi ad ogni riavvio del firewall; per farlo, è sufficiente aggiungere al file /etc/network/interfaces questa riga:

pre-up /etc/default/firewall

ed a questo punto abbiamo il nostro firewall pronto per entrare in funzione.

Possiamo vedere un’ultima casistica, e cioè quella dell’apertura di porte al mondo esterno sul nostro firewall. Ad esempio, potrebbe essere utile aprire la porta 22 del nostro firewall per consentirne l’amministrazione tramite SSH, quindi aggiungere la seguente riga al nostro script

iptables -A INPUT -s 1.1.1.1 -i eth0 -p tcp –dport 22 -j ACCEPT #consente l’accesso via SSH al nostro firewall esclusivamente all’indirizzo IP 1.1.1.1

che consente di accedere ad SSH sul firewall solo all’indirizzo IP 1.1.1.1, se limitare l’accesso SSH per indirizzo IP non è possibile, allora va levata l’opzione -s.

AGGIORNAMENTO

Questa configurazione dà alcuni problemi se si cerca di iniziare una sessione FTP dall’interno della nostra rete locale verso un server FTP esterno, in particolare, connessione ed autenticazione funzionano senza problemi, ma non si riesce ad aprire la sessione dati col server FTP; per ovviare a questo inconveniente, basta mettere nel nostro script contenente le regole di iptables l’istruzione:

modprobe ip_nat_ftp

a questo punto basta far ripartire lo script e sarà possibile effettuare il normale trasferimento di file via FTP.

Link utili
http://guide.debianizzati.org/index.php/Condividere_la_connessione_a_internet
http://it.wikipedia.org/wiki/Netfilter/iptables

In una rete locale aziendale un grosso problema può essere quello di impedire che gli utenti della rete utilizzino programmi che sfruttano la rete Internet per scopi non attinenti con l’attività lavorativa, e che soprattutto possono creare problemi legali o d’immagine all’azienda. Ad esempio, pensiamo a quei programmi come i software di instant messagging (che comunque possono essere anche usati a scopo lavorativo), e soprattutto ai programmi di file sharing, la cui utilità in campo lavorativo è nulla, e che anzi tendono a saturare la banda disponibile sulla connessione Internet.

Per ovviare a questi problemi, è possibile utilizzare un server proxy, in particolare gli esempi esposti in seguito sono stati testati con un client Windows XP e con un server Windows Server 2003 con installato Squid 2.6. Per conseguire i nostri scopi, dobbiamo configurare i client in modo tale che non accedano alla rete tramite un router, ma esclusivamente tramite un proxy; ciò è possibile configurando in modo opportuno un server DHCP e impedendo tramite policy che gli utenti possano modificare le loro impostazioni TCP/IP. Purtroppo questo passo si rende necessario in quanto su Windows non è possibile far agire Squid come transparent proxy, così come invece accade su Linux.

Già facendo questi pochi passi, si eliminano gran parte delle connessioni indesiderate verso Internet, infatti la maggior parte degli utenti non sa nemmeno cos’è un server proxy e non è quindi in grado di impostare la connessione di un software verso Internet utilizzando un server proxy. Queste considerazioni però non portano molto lontano, poiché bisogna sempre considerare la possibilità di avere a che fare con un utente smanettone, che ad esempio, potrebbe sapere che programmi come Emule possono usare un server proxy per la connessione (che comunque in questa situazione non avverrà mai con ID alto), e potrebbe essere a conoscenza del fatto che Emule funziona anche in modalità standalone, e che quindi può funzionare anche senza essere installato sulla macchina e in assenza dei privilegi di amministratore.

Con Squid ho testato (solo in un ambiente di test, finora) con successo due metodi, uno che funziona anche se non molto flessibile, l’altro invece molto più adattabile a diverse situazioni. Il primo metodo consiste nell’abilitare solamente certe porte ad uscire verso il Web su protocollo HTTP, tramite una ACL simile a questa:

acl porteConcesse port 21 80 443

Questa ACL descrive quelle connessioni a server che rispondono sulle porte 21, 80 e 443 (tipicamente FTP e navigazione Web), per cui, dovremo specificare che le uniche connessioni concesse sono quelle verso le porte citate in precedenza, utilizzando questa regola d’accesso:

http_access deny !porteConcesse

che significa "nega tutto ciò che si connette su porte diverse da quelle indicate nella ACL porteConcesse". In questo caso, applicazioni come Emule non possono connettersi ai vari server che tipicamente rispondono su porte diverse da quelle indicate e superiori alla 1024, mentre con queste impostazioni continua ad essere accessibile la rete Messenger per l’utilizzo di Windows Live Messenger.

Un altro metodo consiste nell’intercettare gli user-agent utilizzati dai vari software che si connettono via proxy, ed abilitare solo quei software che contengono nella stringa identificativa dello user-agent solo determinate parole; ad esempio se prendiamo in esame la seguente ACL

acl userAgent browser Mozilla

notiamo che sono definiti tutti quei software che si identificano con uno user-agent che contiene la parola Mozilla al suo interno, come i browser Internet Explorer e Firefox. Prendendo quindi spunto da questa ACL, andiamo a definire una regola d’accesso che consente agli utenti della rete locale di connettersi verso Internet solamente con programmi con user-agent contenenti la sottostringa Mozilla:

http_access deny !useragent

In questo modo Emule continua a non connettersi, mentre continua ad essere possibile la navigazione sul Web; rimane possibile anche connettersi con Windows Live Messenger, poiché anche il suo user-agent contiene la parola Mozilla, per cui, se si vuole evitare questo tipo di connessione, bisogna creare una ulteriore ACL:

acl messenger browser Messenger

con la conseguente regola d’accesso che vieta la connessione alla rete Messenger, regola d’accesso che dev’essere posizionata prima della precedente regola d’accesso legata alla acl userAgent:

http_access deny messenger

In questo modo, anche l’accesso a Messenger è vietato, ed inoltre, si può gestire con una buona flessibilità l’accesso al Web di diverse altre applicazioni. Da notare comunque che Squid è esclusivamente un proxy HTTP ed FTP, e che quindi consente l’accesso ad Internet solamente a quei software in grado di usare i due protocolli HTTP ed FTP; tanto per fare un esempio, non sarà possibile utilizzare nella rete locale programmi come Outlook, Outlook Express o Thunderbird che cercano di scaricare o inviare posta tramite SMTP o POP3, ma ci dovrà essere un server di posta elettronica posto all’interno della rete locale.

Site and Content Rules in ISA Server 2000 consente di definire le applicazioni ed i siti che è possibile utilizzare durante la propria navigazione sul Web, ma soprattutto, è possibile applicare queste regole ad utenti e/o gruppi definiti in Active Directory, rendendo possibile una gestione delle autorizzazioni semplice ed al tempo stesso efficiente. Ad esempio, è possibile creare una regola che impedisca ad un determinato gruppo di utenti di scaricare file video o audio, così com’è possibile limitare un altro gruppo di utenti consentendo loro di visitare solamente siti con determinati URL.

Su ISA Server 2000 però, quando si crea una regola in Site and Content Rules, bisogna prestare attenzione alle regole già create, infatti, a differenza di ISA Server 2004, non si può indicare un ordine preciso di applicazione, ma è ISA Server 2000 ad applicare un suo ordine specifico, in particolare:

1. regole di negazione (deny) applicate ad ogni richiesta (accesso anonimo)
2. regole di approvazione (allow) applicate ad ogni richiesta (accesso anonimo)
3. regole di negazione (deny) applicate ad utenti o gruppi
4. regole di approvazione (allow) applicate ad utenti o gruppi

Da qui si può capire che, se ho una regola che consente di navigare sul Web a chiunque, e successivamente creo una regola che impedisce ad un gruppo di utenti di navigare su alcuni siti, quest’ultima regola non verrà applicata, in quanto in precedenza avevo già consentito la navigazione anonima a tutti gli utenti. Per ovviare al problema e consentire l’applicazione della regola di negazione, dovrò cambiare la regola in cui consento la navigazione indiscriminata consentendo l’accesso Web solamente agli utenti autenticati (ad esempio il gruppo Domain Users).