Ricerche IT

Leggendo questo post di Andrea Beggi, e proseguendo la lettura dei relativi commenti, viene descritta una situazione in cui si ha una rete che esce verso Internet tramite un router, e contestualmente si ha una VPN con un’altra sede che esce tramite un router separato, per cui bisogna lavorare bene con l’instradamento del traffico, facendo in modo che il traffico verso la VPN non esca tramite il router Internet, ma tramite il router VPN. Andrea Beggi propone una soluzione che consiste nel creare una route statica sul default gateway della rete locale, che sia in grado di reinstradare il traffico verso la VPN in modo trasparente all’utente; il problema potrebbe porsi nel traffico dalla sede remota ad un host della rete locale e ritorno, se infatti l’host non ha una valida configurazione di routing, la sede remota potrebbe comunque non comunicare con gli host della rete locale. In realtà normalmente ciò non accade, poiché il router, una volta configurato, utilizza il meccanismo chiamato ICMP Redirect Message per mandare messaggi ICMP ai vari host con le informazioni necessarie ad aggiornare la tabella di routing degli host, informandoli sul percorso più corretto da seguire per raggiungere la sottorete corrispondente alla sede remota connessa in VPN.

Nei commenti al post di Andrea Beggi, c’è chi ha proposto soluzioni alternative per raggiungere lo stesso fine, tra cui mi ha colpito la tecnica di distribuire una (o più) route statiche ai client della rete locale tramite server DHCP; il motivo principale per cui mi ha colpito è che ignoravo quest’opzione di DHCP. Al momento ho testato la soluzione solamente su un server Windows Server 2003 R2 SP1 e su un client Windows XP Professional SP2, e devo dire funziona senza problemi. In sostanza, l’obiettivo che vogliamo ottenere è fare in modo che i client della rete 172.16.1.0/24 possano raggiungere la rete 192.168.1.0/24 tramite il router 172.16.1.253; per raggiungere lo scopo, è necessario configurare nelle opzioni dell’ambito DHCP precedentemente configurato l’opzione “249 Classless Static Routes”, in cui indicare (tramite il tasto Add Route) la rete di destinazione, la subnet mask e il router tramite il quale raggiungere la sottorete in questione, come visibile dalla figura 1:

Fatto questo, dare conferma, riavviare il servizio DHCP e infine verificare che la distribuzione delle route statiche avvenga correttamente. Tenere presente che esiste un’altra opzione di DHCP che si occupa di distribuire route statiche ai client, la “033 Static Route Option”, che però non è applicabile nella nostra situazione, in quanto con questa route è possibile specificare solamente un host come destinazione e non un’intera sottorete.

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

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

Può succedere di dimenticare o dover modificare la password di un router Cisco, in questi casi bisogna effettuare la procedura di recovery in modo da rientrare in possesso del proprio router. Per effettuare il recovery, è necessario avere accesso fisico al router, poiché bisogna fare la procedura utilizzando un emulatore di terminale (in Windows va benissimo l’HyperTerminal) collegando la porta seriale del PC con la porta console del router utilizzando il cavo console fornito a corredo del router da Cisco; va da sé che chiunque in possesso di questi requisiti può cambiare a piacimento la configurazione del router, per cui è necessario limitarne l’accesso fisico così come si farebbe con un server. In questo caso parliamo del router Cisco 827, con altri router Cisco la procedura da seguire può essere diversa.

Per effettuare la connessione con la porta console, aprire HyperTerminal, creare una nuova sessione e connettersi alla porta COM1 coi seguenti parametri:

Bit per secondo: 9600
Bit di dati: 8
Parità: nessuno
Bit di stop: 1
Controllo di flusso: Hardware

Effettuata la connessione bisogna riavviare il router, e quando compaiono diverse righe di testo il cui inizio è "System Bootstrap…" premere la combinazione di tasti CTRL + BREAK (su alcune tastiere questo tasto prende il nome  "Pausa"), dopodiché comparirà il prompt rommon 1>. A questo punto, digitare il comando confreg 0×2142 e comparirà il prompt rommon 2>, in questo modo al successivo riavvio il router non caricherà la configurazione corrente, così da poter disporre a piacimento dell’apparato senza limitazioni; digitare quindi il comando reset per riavviare il router.

Al riavvio il router non richiede nessuna password, compare però la seguente domanda:

Would you like to enter the initial configuration dialog? [yes/no]

in cui viene richiesto all’operatore se eseguire una sorta di configurazione guidata del router, a cui rispondere "no". A questo punto siamo entrati nel router e possiamo compiere il passo successivo, cioè entrare in "privileged mode" col comando enable, dopodiché bisogna caricare in memoria la configurazione di partenza del router per poterla modificare a piacimento con il comando copy startup-config running-config. Prima di compiere questo passo però è bene salvare la configurazione corrente in modo da poter tornare indietro in casi di errori. Visualizzare la configurazione corrente tramite il comando show running-config, quindi ad ogni schermata fare un copia-incolla dei comandi e riportare tutta la configurazione in un file di testo, ciò ci permette di operare sul router con la consapevolezza di poter sempre ritornare alla configurazione precedente.

Per modificare la password di privileged mode, una volta caricata la configurazione di partenza bisogna entrare nella modalità di configurazione del router tramite il comando configure terminal, quindi digitare il comando enable secret password dove al posto di password va digitata la password prescelta. Ora è possibile uscire da privileged mode tramite il comando exit, quindi salvare la configurazione in modo permanente utilizzando il comando write mem; non rimane altro che riportare il valore del registro modificato in precedenza al valore normale, altrimenti ad ogni riavvio del router la configurazione NON verrà caricata: digitare il comando config-register 0×2102 e riavviare il router, a questo punto dovrebbe essere tutto funzionante con la nuova password impostata.

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 »

Guida pubblicata su WinInizio

ANALISI DEL PROBLEMA
Si prendano in considerazione due reti Ethernet, una chiamate Rete A con indirizzo di rete 192.168.1.0/24 e una chiamata Rete B con indirizzo di rete 192.168.5.0/24. Queste due reti sono separate tra di loro sia fisicamente che logicamente. Lo scopo è quello di far comunicare tra di loro le due reti, senza modificare il loro indirizzamento IP. La rete avrà l’aspetto mostrato nella figura 1

Figura 1

SOLUZIONE DEL PROBLEMA
Per far comunicare tra di loro due reti con indirizzamento IP distinto, la soluzione più ovvia è quella di utilizzare un router. Detto router deve avere due interfacce di rete Ethernet, una che sia ingrado di comunicare con la Rete A e una che comunichi con la Rete B. In questo caso, prendiamo in considerazione l’utilizzo di un server Windows Server 2003, con installate due schede di rete. I concetti qui esposti sono validi anche (con minime differenze) per un server con installato Windows 2000 Server, la cosa importante è che su detto server siano installate due schede di rete. Ovviamente, anche un router dedicato funzionerà altrettanto bene (se non meglio).
Continue Reading »

Guida pubblicata su WinInizio

ANALISI DEL PROBLEMA
Si prendano in considerazione due reti Ethernet, una chiamate Rete A con indirizzo di rete 192.168.1.0/24 e una chiamata Rete B con indirizzo di rete 192.168.5.0/24. Queste due reti sono separate tra di loro sia fisicamente che logicamente. Lo scopo è quello di far comunicare tra di loro le due reti, senza modificare il loro indirizzamento IP. La rete avrà l’aspetto mostrato nella figura 1

Figura 1

SOLUZIONE DEL PROBLEMA
Per far comunicare tra di loro due reti con indirizzamento IP distinto, la soluzione più ovvia è quella di utilizzare un router. Detto router deve avere due interfacce di rete Ethernet, una che sia ingrado di comunicare con la Rete A e una che comunichi con la Rete B. In questo caso, prendiamo in considerazione l’utilizzo di un PC con Windows XP Professional, con installate due schede di rete.
Continue Reading »