Ricerche IT

Tempo fa mi è capitato di avere per le mani un firewall Cisco PIX 506e che non completava la fase di boot, praticamente, collegandosi in console al dispositivo, arrivava a mostrare quella che chiama la “PCI Device Table”, che dovrebbe essere l’elenco di alcuni componenti del firewall (tra cui le interfacce di rete) e si piantava in quel punto, senza che fosse possibile andare oltre.

Per fortuna, cercando sul Web, ho trovato una soluzione piuttosto semplice anche se “curiosa”, che consiste nello spegnere l’aggeggio (il Pix), aprirlo, e trovare un jumper presente nel bel mezzo della scheda madre; tale jumper fa da ponticello su due piedini, lasciandone un terzo libero, consentendo quindi di posizionare il jumper su due diverse posizioni, per cui, seguendo il consiglio trovato sul Web, ho spostato il jumper nell’unica altra posizione possibile, ho chiuso il firewall, quindi ho avviato il dispositivo, ottenendo il risultato sperato, cioé il corretto funzionamento della macchina.

Link di riferimento

http://www.velocityreviews.com/forums/t56103-cisco-pix-506e-wont-boot.html
http://www.experts-exchange.com/Security/Software_Firewalls/Enterprise_Firewalls/Cisco_PIX_Firewall/Q_23316894.html

Se abbiamo configurato un firewall Cisco ASA 5505 in una piccola rete locale in cui non esiste un server di dominio, possiamo impostare il firewall in modo tale che funga da server DHCP; ovviamente, l’ASA può fornire il servizio DHCP anche se abbiamo un server di rete, ma penso che, normalmente, sia preferibile impostare come server DHCP lo stesso server di rete.

Prima di procedere alla configurazione del servizio DHCP, dobbiamo pianificare le modalità di assegnazione degli indirizzi IP. Se siamo in una rete piccola, e si ritiene inverosimile un deciso incremento dei client della rete locale, non è necessario specificare un range di indirizzi pari a tutta la classe di appartenenza della sottorete assegnata, poiché, con molta probabilità, vi sarà la necessità di dover mettere in rete dispositivi (tipicamente print server o server) che necessitano di indirizzi IP statici, per cui è bene prevedere fin da subito un range di indirizzi da assegnare staticamente, in modo tale da non dover gestire indirizzi riservati sul DHCP.

Ipotizziamo di avere un firewall ASA su una rete configurata nel modo seguente (la stessa del precedente articolo sul firewall Cisco):

in questa situazione, faremo in modo che ai client della rete venga assegnato un indirizzo IP compreso nel range 192.168.40.50 - 192.168.40.100; oltre agli indirizzi IP, assegneremo dinamicamente anche il server DNS ed il default gateway della rete locale.

Il primo passaggio consiste nel configurare il pool degli indirizzi IP assegnati agli host:

(config)# dhcpd address 192.168.40.50-192.168.40.100 inside

Ora dobbiamo assegnare dinamicamente ai client della rete locale i server DNS per la risoluzione dei nomi:

(config)# dhcpd dns 151.99.125.2 151.99.250.2

Il passaggio successivo consiste nell’indicare qual è il router predefinito per gli host della LAN, che altri non è, nel nostro caso, che il nostro firewall:

(config)# dhcpd option 3 ip 192.168.40.254

Arrivati qui, siamo quasi a posto per una configurazione minimale del servizio DHCP sul firewall; l’ultimo passo da compiere riguarda la durata dei parametri assegnati ai client, cioé la durata del lease, specificata in millisecondi. Il valore predefinito del servizio DHCP sull’ASA è di un’ora,un valore un po’ bassino; possiamo allungare la durata del lease ad una settimana, con questo comando:

(config)# dhcpd lease 604800

Ora la configurazione è completa, rimane solamente l’attivazione del servizio DHCP:

(config)# dhcpd enable inside

A questo punto il servizio DHCP è attivo e funzionante, quindi per non perdere la configurazione al riavvio successivo del firewall digitare il comando:

# write memory

che consente di memorizzare in modo permanente la configurazione del Cisco ASA.

Link di approfondimento: http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/dhcp.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.

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.

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

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).

Quando ci si trova a lavorare con router e firewall Cisco utilzzando la riga di comando (CLI), in genere si utilizza, in ambiente Windows, Hyperterminal per lavorare tramite console, oppure direttamente il comando telnet se si lavora tramite rete, oppure Putty se si accede tramite SSH. Soprattutto se si deve lavorare più o meno contemporaneamente su più dispositivi, è molto comodo utilizzare un unico programma, e ciò è possibile utilizzando Putty.

Putty è un software di emulazione terminale piuttosto completo, quindi permette di connettersi ad un dispositivo sia tramite porta seriale sia utilizzando diversi protocolli di rete. Putty mi piace molto di più di Hyperterminal quando ci si deve connettere ad un dispositivo Cisco tramite console, soprattutto quando si deve fare copia-incolla delle configurazioni degli apparati. Bisogna però dire che, almeno nelle connessioni seriali, ho riscontrato una certa instabilità di Putty, anche se ancora non mi sono dato la briga di giocare un po’ con le opzioni di connessione.

Per utilizzare Putty per connettersi ad un dispositivo tramite porta seriale, all’apertura del programma scegliere l’opzione "Serial" (l’ultima della lista di fianco a SSH), che è stata introdotta da non molto (credo). Da lì, nel campo "Serial line" scegliere la porta seriale su cui connettersi (COM1 è quella predefinita) e la velocità (9600 bit/s quella predefinita, adatta per connettersi ai dispositivi Cisco), quindi, eventualmente, dal menu ad albero sulla sinistra (Category), andare sulla voce Connection e quindi su Serial per specificare ulteriori opzioni di collegamento. A questo punto, cliccando su Open, ci si ritrova connessi alla porta seriale e possiamo agire sul nostro apparato.

Oltre a qualche pecca di stabilità via seriale (che però appunto potrebbe dipendere da una non corretta configurazione dei parametri di connessione), con Putty non funziona la combinazione di tasti CTRL+BREAK, utile quando si vuole fare un recovery della password di un router Cisco; per ovviare al problema, una volta avviata la connessione cliccare sull’iconcina di Putty in alto a sinistra sulla barra del titolo, scegliere la voce "Special command" quindi scegliere la voce "Break", in modo da ottenere un effetto equivalente alla pressione dei tasti CTRL+BREAK

Per gestire la configurazione di un firewall PIX di Cisco può essere utile l’accesso via telnet, invece del più scomodo accesso via console. Siccome i dati scambiati tramite protocollo telnet non sono criptati, il firewall PIX normalmente non permette l’accesso via telnet sull’interfaccia esterna (outside) del firewall, considerata poco sicura, per cui è possibile abilitare l’accesso via telnet solamente sull’interfaccia interna (inside).

Assumendo che il nostro firewall abbia un indirizzo IP sull’interfaccia inside uguale a 192.168.0.254, per abilitare il protocollo telnet diamo i seguenti comandi:

telnet 192.168.0.254 255.255.255.0
telnet timeout 5

In questo modo tutti i PC della rete locale potranno accedere al firewall, che richiederà una password per l’autenticazione; se non diamo altri comandi riguardo alla configurazione dell’accesso via telnet, la password predefinita per connettersi al firewall è "cisco", anche se poi dobbiamo conoscere la password per entrare in privileged mode per poter configurare il firewall.

Se vogliamo cambiare password di accesso e non lasciare la password predefinita per l’accesso via telnet, dobbiamo utilizzare il comando

passwd password

dove per password si intende la password che sceglieremo per l’accesso via telnet al nostro firewall.

Guida pubblicata su WinInizio

ANALISI DEL PROBLEMA

In una rete locale, prima o poi ci si pone sempre il problema di come collegare l’intera rete locale alla rete Internet. Il collegamento alla rete Internet avviene in genere tramite un unico punto di accesso, questo per evitare spese nell’acquisto di più indirizzi IP pubblici ed anche (e soprattutto) per motivi di sicurezza, poiché una rete esposta direttamente ad Internet è una rete insicura. E’ quindi necessario utilizzare un dispositivo che permetta di separare le due reti, rete locale e rete Internet. Un metodo ancora più sicuro è quello di utilizzare un firewall che separa il punto d’accesso alla rete Internet e la rete locale.

SOLUZIONE DEL PROBLEMA

Una possibile soluzione (tra le tante disponibili) potrebbe essere quella di utilizzare un server Windows 2003 che funga da default gateway verso Internet per la rete locale e che abbia anche funzionalità di firewalling, in modo da proteggere la rete da intrusioni esterne. Tutto ciò è possibile senza utilizzare programmi di terze parti utilizzando Routing and Remote Access (RRAS). La rete sarà quindi organizzata come indicato in figura 1:
Continue Reading »

STABILIRE PIU’ VPN SU UN UNICO FIREWALL CISCO PIX

Per avere attive più VPN su un unico firewall Cisco PIX (che quindi avrà il collegamento con più sedi), seguire le istruzioni indicate nel link sottostante. La cosa di cui tenere conto è che il natting dovrebbe avvenire su tutte e due la ACL create appositamente per il tunnel da stabilire. Ciò, se non sbaglio, non è possibile, quindi bisogna creare una terza ACL in cui inserire tutte le route permesse (cioè le route che servono per comunicare con le reti private da raggiungere via VPN) e quindi nattare l’ACL creata allo scopo. Inoltre, bisogna inserire le informazioni sulla VPN sulla stessa crypto map ma con policy diverse, quindi creare un peer isakmp aggiuntivo per ogni VPN da aggiungere alla prima creata.

Fatto tutto ciò, dare i comandi

# clear ipsec sa
# clear isakmp sa

per resettare le “Security Associations” e permettere di stabilire le VPN appena aggiunte.

LINK DI RIFERIMENTO

Creare VPN “meshed”: http://www.cisco.com/warp/public/110/pixmeshed.html