Il blog sull'informatica

Come sono solito ricordare, la sicurezza dei dispositivi deve iniziare dai livelli più bassi (ad esempio da quello fisico, utilizzando case allarmati oppure posizionando i device all'interno di CED dotati di meccanismi per il controllo biometrico all'ingresso), fino ai livelli più alti (come quello applicativo).

Seguendo questo ragionamento, si può facilmente affermare che le celeberrime ACL standard, estese e nominali lavorano a livello 3 e 4, mentre il port security lavora a livello 2 (alias Data Link, in particolare sublyer MAC).

Ma come funziona realmente il port security? Semplice, controlla i MAC address provenienti da una data interfaccia ed in caso di anomalia (come la ricezione di un indirizzo MAC diverso da quello atteso) applica delle misure di protezione (ad esempio disabilitando la porta).

In questo modo lo switch (ma tale ragionamento vale anche per i router ed i firewall dotati di interfacce Ethernet), presenta una maggiore resistenza ad attacchi di vario tipo, come il cosiddetto MAC flooding, il cui scopo è quello di saturare la memoria CAM (di cui sono dotati gli switch), causando una sorta di denial of service.

Ma vediamo adesso come abilitare tale funzionalità su uno switch Cisco.

Per prima cosa occorre identificare le porte su cui applicare il port security. Per fare ciò è necessario indicare esplicitamente la modalità di funzionamento della porta stessa (access o trunk), in quanto tale misura di sicurezza non può essere applicata alle porte in dynamic mode.

Onestamente credo che abilitare il port security su una porta in trunk sia controproducente, poichè sarebbe meglio operare sul vlan allowed piuttosto che su un filtraggio a livello 2 (non possiamo conoscere a priori tutti i MAC address che transiteranno lungo il trunk ed anche se questo fosse possibile, bisognerebbe dichiararli tutti manualmente con grande mole di lavoro annessa).

Ergo, mettiamo in access le porte su cui vogliamo abilitare il port security, ad esempio:

Switch(config)# int fa0/0
Switch(config-if)# switchport mode access

Se volessimo mettere in access più porte possiamo utilizzare il comando int range, ad esempio:

Switch(config)# int range fa 0/0 - 12
Switch(config-if)# switchport mode access

Ora sulle porte che abbiamo messo in access possiamo abilitare il port security:

Switch(config-if)# switchport port-security

In questo modo, lo switch terrà conto del MAC address ricevuto su una data porta (e salvato nella CAM), e nel caso in cui su quella stessa porta riceverà un MAC address diverso da quello memorizzato, la disabiliterà.

Nel caso in cui, invece, su una data porta dello switch sia allacciata ad esempio una macchina fisica su cui gira un middleware (come VMWare ESX) che gestisce N macchine virtuali (ognuna delle quali è dotata di una o più schede Ethernet e quindi uno o più MAC address), possiamo utilizzare il parametro maximum per specificare il numero massimo di indirizzi MAC che possono essere ricevuti su quella specifica porta:

Switch(config)# int fa0/0
Switch(config-int)# switchport port-security maximum 5

Inoltre, è possibile definire a priori il MAC address consentito su una specifica interfaccia dello switch:

Switch(config-int)# switchport port-security mac-address XXXX.YYYY

I 16 byte utilizzati per la rappresentazione di un MAC (in notazione esadecimale, conosciuta anche come hex), nei dispositivi Cisco devono essere indicati come XXXX.YYYY.

Se un'interfaccia va in error-disabled state a causa di una violazione identificata dal port security, è possibile riabilitarla utilizzando i seguenti comandi:

Switch# term mon
Switch# conf t
Switch(config)# int fa0/0
Switch(config-int)# shut

Appena riceverevo in output una notifica simile alla seguente:

1w0d: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to down

possiamo riabilitare la porta:

Switch(config-int)# no shut

Occorre precisare che il comando term mon è fondamentale se ci si connette al dispositivo mediante vty, in quanto abilita la visualizzazione delle notifiche (ad esempio il cambio di stato di un'interfaccia).

Per verificare se il port security è stato applicato su una specifica porta è sufficiente digitare:

Switch# sh run int <nome porta>

Mentre per visualizzare le informazioni relative al port security applicato ad una specifica interfaccia occorre usare il comando:

Switch# sh port-security int <nome interfaccia>

Per visualizzare le informazioni sul port security relativo a tutte le interfacce su cui è stato applicato basta lanciare il comando:

Switch# sh port-security

Infine, per listare tutti i MAC address memorizzati dal port security (e quindi ritenuti sicuri), è necessario digitare:

Switch# sh port-security address

Ovviamente il port security consente una maggiore customizzazione rispetto alla procedura (piuttosto basilare) mostrata in questo post. Dunque per maggiori dettagli vi invito a leggere la guida ufficiale Cisco.

A presto.

Consentire agli utenti della propria LAN l'accesso ai siti Web mediante Proxy è ormai una prassi. Analizzare i relativi file di log, però, risulta essere un'operazione piuttosto tediosa, indi per cui è molto conveniente utilizzare dei software in grado di generare i report degli accessi in modo automatico.

Se il proxy che avete tirato su è Squid e non implementate meccanismi di autentica (ad esempio NTLM), potete usare Calamaris come generatore di report.

L'installazione e la configurazione di tale applicativo è piuttosto semplice. Infatti, per installarlo basta digitare:

nightfly@nightbox:~$ sudo apt-get install calamaris

Ad installazione completata possiamo passare alla configurazione. Per prima cosa creiamo la directory calamaris in /var/www:

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris

e le sottodirectory daily, weekly e monthly, in cui andranno salvati rispettivamente i report giornalieri, settimanali e mensili:

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris/daily

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris/weekly

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris/monthly

assegniamo i giusti permessi alle directory appena create:

nightfly@nightbox:~$ cd /var/www

nightfly@nightbox:/var/www$ sudo chown nomeutente:nomeutente -R calamaris

A questo punto possiamo creare il primo report, digitando:

nightfly@nightbox:/var/www$ sudo calamaris -a -F html /var/log/squid/access.log > /var/www/calamaris/index.html

Il report sarà visualizzabile mediante browser alla seguente URL:

http://vostroippubblico/calamaris

Per consentire solo ad uno specifico utente la visualizzazione del report occorre creare un file .htaccess recante le seguenti direttive:

AuthName "Sezione riservata Calamaris"
AuthType Basic
AuthUserFile /etc/apache2/passwd
Require user <nome utente>

ovviamente il nome utente deve essere presente nel file /etc/apache2/passwd (in cui viene fatta l'associazione tra l'utente stesso ed il digest della sua password)

Infine, modifichiamo il file /etc/apache2/apache2.conf in questo modo:

<Directory /var/www/calamaris>
AllowOverride AuthConfig
</Directory>

Salviamo il tutto e riavviamo apache:

nightfly@nightbox:~$ sudo service apache2 restart

Per ricevere i report direttamente via email (oltre ad ottenere il loro salvataggio nelle dir precedentemente create), possiamo modificare come segue il file cron.conf posizionato in /etc/calamaris:

daily:vostro.indirizzo@email.it:/var/www/calamaris/daily/index.html:both:'Squid giornaliero'
weekly:vostro.indirizzo@email.it:/var/www/calamaris/weekly/index.html:both:'Squid settimanale'
monthly:vostro.indirizzo@email.it:/var/www/calamaris/monthly/index.html:both:'Squid mensile'

Inoltre, sarà necessario abilitare la cache di squid (se non l'avete ancora fatto), decommentando la direttiva cache_dir presente nel file /etc/squid/squid.conf.

Done, enjoy!

Lo standard de facto per realizzare i tunnel VPN è sicuramente IPSec. Tale protocollo è compatibile con dispositivi di vendor diversi (interoperabilità) e permette di creare dei tunnel altamente affidabili e robusti in termini di sicurezza. Per contro, però, esso risulta essere piuttosto complesso da configurare e proprio per questo motivo, soprattutto in ambito SOHO, si opta per soluzioni alternative. Una di queste è sicuramente OpenVPN, in grado di realizzare dei tunnel cifrati mediante i protocolli SSL/TLS.

Di seguito un breve howto in cui viene descritta la configurazione di OpenVPN per un bastion host dual-homed Linux.

Nello specifico, la rete locale è così definita:

Internet - Screened router - interfaccia UNTRUST del bastion - FW IPTABLES - interfaccia TRUST del bastion - LAN

Configurazione del server

Per prima cosa occorre installare l'applicativo in questione digitando il comando:

nightfly@nightbox:~$ sudo apt-get install openvpn

ad installazione completata, posizioniamoci nella directory /etc/openvpn e creiamo le subdir certificati e log:

nightfly@nightbox:/etc/openvpn$ sudo mkdir log
nightfly@nightbox:/etc/openvpn$ sudo mkdir certificati

Successivamente, creiamo i due file in cui verranno salvati i log:

nightfly@nightbox:/etc/openvpn$ cd log
nightfly@nightbox:/etc/openvpn/log$ sudo touch openvpn.log openvpn-status.log

A questo punto possiamo creare il file di configurazione:

nightfly@nightbox:/etc/openvpn$ sudo nano server.conf

il cui contenuto dovrà essere simile al seguente:

tls-server

port 5002

dev tun
ifconfig 192.168.110.1 192.168.110.2

persist-key
persist-tun

push "route 192.168.1.0 255.255.255.0"

#Percorsi dei certificati
ca certificati/ca.crt
cert certificati/server.crt
key certificati/server.key 
dh certificati/dh1024.pem
tls-auth certificati/ta.key 0 # 0 per il server ed 1 per il client, essenziale per la generazione dell'hash HMAC nell'header TLS

cipher BF-CBC
comp-lzo

keepalive 10 120

#log and security
user nobody
group nogroup
status log/openvpn-status.log
log-append log/openvpn.log
verb 3
script-security 2

Mediante la direttiva tls-server sto imponendo al mio bastion host di fungere da server per le sessioni TLS.

Con port specifico su quale porta OpenVPN deve rimanere in ascolto, mentre con dev tun sto scegliendo la tipologia di interfaccia da realizzare. A tal proposito, occorre precisare che i tipi di interfaccia che può tirar su OpenVPN sono 2, ovvero:

1) tun, per le VPN routed (livello 3);

2) tap, per le VPN bridged (livello 2).

Con ifconfig specifico l'indirizzo IP del tunnel VPN lato server (192.168.110.1) e lato client (192.168.110.2). Per la natura delle interfacce tun, trattasi di un collegamento point-to-point (/30).

con push "route 192.168.1.0 255.255.255.0" sto iniettando la rotta per raggiungere la mia LAN (interfaccia TRUST del bastion-host) sul client VPN.

Con le direttive:

cipher BF-CBC
comp-lzo

sto definendo il tipo di cifratura (BlowFish) ed il tipo di compressione (LZO - Lempel-Ziv-Oberhumer) messe in atto nel tunnel VPN.

Con keeplive faccio in modo che il tunnel rimanga attivo anche in assenza di traffico, mentre nella sezione #log and security definisco (in quest'ordine) i permessi, i file di log, il verbosity (accuratezza dei log) ed il livello di sicurezza di questo script di configurazione.

Salviamo il file in questione e procediamo con la generazione delle chiavi e dei certificati. Lato server i comandi da lanciare sono i seguenti:

nightfly@nightbox:~$ cd /usr/share/doc/openvpn/examples/easy-rsa/2.0/

nightfly@nightbox:~$ sudo nano vars

che andrà editato customizzando i campi indicati

nightfly@nightbox:~$ ./vars

nightfly@nightbox:~$ ./clean-all

nightfly@nightbox:~$ ./build-ca

per la generazione del certificato relativo alla CA

nightfly@nightbox:~$ ./build-dh 

per lo scambio delle chiavi mediante l'algoritmo Diffie-Helman (leggasi premaster-key)

nightfly@nightbox:~$ openvpn --genkey --secret ta.key

per la generazione della chiave segreta.

Una volta generate le chiavi ed i certificati copiamoli nella directory /etc/openvpn/certificati:

nightfly@nightbox:~$ sudo cp ca.crt server.crt server.key dh1024.pem ta.key /etc/openvpn/certificati

A questo punto possiamo avviare il demone OpenVPN:

nightfly@nightbox:~$ sudo service openvpn start

Verifichiamo che l'interfaccia tun0 sia attiva mediante il comando ifconfig:

nightfly@nightbox:~$ ifconfig

tun0     Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
     indirizzo inet:192.168.110.1  P-t-P:192.168.110.2  Maschera:255.255.255.255
     UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
     RX packets:0 errors:0 dropped:0 overruns:0 frame:0
     TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
     collisioni:0 txqueuelen:100
     Byte RX:0 (0.0 B)  Byte TX:0 (0.0 B)

Configurazione di IPTABLES

Il bastion host ha DROP come azione di default per la chain FORWARD. Proprio per questo motivo, occorre consentire il transito del traffico dall'interfaccia tun0 a quella TRUST (eth0) e viceversa. Le regole da definire sono le seguenti:

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT

Configurazione del client

A questo punto è possibile installare e configurare il client, che però dovrà utilizzare lo stesso file ca.crt del server, la medesima chiave ta.key del server ma una propria chiave privata (client.key) ed un proprio certificato (client.crt).

Per ambienti Windows vi consiglio questo client Openvpn (se utilizzate Windows 7 fate riferimento a questa pagina per la procedura di installazione).

Quest'altro client, invece, evitatelo come la peste (in quanto bacatissimo, d'altronde è una versione alpha).

Ad installazione completata potrete utilizzare il seguente file di configurazione:

remote <indirizzo IP pubblico del server OpenVPN> 5002
client
tls-client
nobind
dev tun
ifconfig 192.168.110.2 192.168.110.1
pull

ca key/ca.crt
cert key/client.crt
key key/client.key
tls-auth key/ta.key 1

persist-key
persist-tun

cipher BF-CBC

comp-lzo

keepalive 10 120

script-security 2

verb 3

Da notare che gli algoritmi di compressione e cifratura devono essere i medesimi di quelli utilizzati dal server, pena l'impossibilità di connettersi allo stesso.

Diagnostica

A connessione VPN avvenuta, potete verificare la raggiungibilità attraverso il tunnel degli host della LAN mediante un seplice ping, ad esempio:

ping 192.168.1.2

Se il ping dovesse andare in timeout, provate a mettere in ascolto tcpdump sulle interfacce tun0 ed eth0 e controllate la tabella di routing del vostro bastion host (attraverso il comando route).

Verificate inoltre che la rotta verso la LAN sia stata correttamente iniettata sul client (Windows), digitando:

route print

Fine del post, bye.