Archivi tag: vpn

Cisco 2811: utilizzare le route-map per creare delle regole di destination NAT basate su IP sorgente

20 agosto 2015Networking2811, acl, cisco, destination nat, dnat, dns, firewall, ipsec, iptables, nameserver, route-map, router, site-to-site, srv, vpnnazarenolatella

Scenario

Supponiamo che si abbia a che fare con un ufficio centrale (main office) a cui sono collegati N uffici periferici (branch office) tramite dei tunnel VPN IPsec Site-to-Site dedicati (che concorrono a formare la classica topologia a stella). Supponiamo, inoltre, che i suddetti uffici periferici, per questioni di failover, debbano essere in grado di raggiungere i servizi presenti nell’ufficio centrale anche nel caso in cui i tunnel VPN non siano disponibili (passando quindi direttamente per Internet).

Utilizzando delle regole di destination NAT classiche, del tipo:

ip nat inside source static tcp 192.168.2.4 80 interface fastethernet0/0 80

(dove 192.168.4.2 è l’IP locale del server Web esposto su Internet), i branch office non saranno in grado di raggiungere il server in questione tramite il tunnel VPN (utilizzando il protocollo HTTP).

Ergo, il fatto che un determinato servizio sia pubblicato su Internet, implica automaticamente l’impossibilità di raggiungerlo anche tramite il tunnel VPN.

Per ovviare a tale problematica esistono 2 soluzioni: la prima, meno impegnativa (ma che richiede la modifica della URL lato client in caso di failover), consiste nel modificare la configurazione del server in modo tale che rimanga in ascolto su 2 porte distinte, ad esempio la TCP 80 per Internet e la TCP 81 per la VPN; la seconda, più impegnativa (ma anche molto più scalabile), consiste nel creare sul nostro router Cisco 2811 (main office) delle route-map (che si avvalgono di opportune ACL) in grado di filtrare gli indirizzi IP sorgenti dei client che vogliono collegarsi al server Web. In questo modo, se la richiesta di connessione proviene da un determinato IP privato tipico di una VPN Site-to-Site (ad esempio 192.168.3.1), per essa non viene applicato il destination NAT; viceversa, nel caso in cui la richiesta di connessione provenga da Internet, verrà applicato il destination NAT come di consueto.

Ho definito la seconda soluzione come la più scalabile delle 2 per un semplice motivo: impostando la route-map sul router del main office e modificando sul nameserver locale il record di tipo A che punta all’IP del server Web, si può fare in modo che quest’ultimo possa essere contattato tramite tunnel VPN o tramite Internet a seconda dei casi senza dover modificare la URL lato browser (passando, ad esempio, da http://www.vostrodominio.com a http://www.vostrodominio.com:81).

Vediamo adesso come mettere in pratica la soluzione #2.

Configurazione del router Cisco 2811 (main office)

Per prima cosa occorre creare l’ACL in grado di “riconoscere” gli IP locali e di negare il destination NAT:

Router(config)# access-list 150 deny ip host 192.168.2.4 192.168.3.0 0.0.0.255
Router(config)# access-list 150 deny ip host 192.168.2.4 192.168.4.0 0.0.0.255
Router(config)# access-list 150 deny ip host 192.168.2.4 192.168.5.0 0.0.0.255
Router(config)# access-list 150 deny ip host 192.168.2.4 192.168.6.0 0.0.0.255
Router(config)# access-list 150 permit ip host 192.168.2.4 any

Successivamente creiamo la route-map vera e propria:

Router(config)# route-map nonat
Router(config-route-map)# match ip address 150

dove 150 è il numero dell’ACL estesa precedentemente definita.

Infine, associamo la route-map appena creata alla regola di destination NAT:

Router(config)# ip nat inside source static tcp 192.168.2.4 <IP Pubblico> 80 route-map nonat extendable

Ovviamente, affinchè la suddetta soluzione sia realmente scalabile, è necessario che il vostro collegamento ad Internet sia dotato di indirizzo IP pubblico statico.

Salviamo adesso la configurazione del nostro router:

Router# copy run start

e passiamo al vaglio alcune soluzioni alternative alle route-map.

1) Utilizzo dei record DNS di tipo SRV (vedi qui per ulteriori dettagli). Essi ci consentono non solo di specificare il protocollo di comunicazione ma anche la porta su cui è in ascolto il server, definendo una priorità per ciascuna entry che li compone:

_http._tcp.vostrodominio.com. 86400 IN SRV 0 5 81 www.vostrodominio.com.
_http._tcp.vostrodominio.com. 86400 IN SRV 1 5 80 www1.vostrodominio.com.

dove 0 e 1 sono le priorità, 81 e 80 le porte su cui è in ascolto il server. In caso di timeout sulla porta 81 e l’IP di www (raggiungibile via VPN) il browser “dovrebbe” switchtare automaticamente sulla 80 e l’IP di www1. Ho utilizzato il condizionale poichè non tutti i broswer supportano tale meccanismo ed un workaround (applicato però solo da alcuni di essi), consiste nel definire record A con il medesimo hostname ma indirizzi IP differenti: nel caso in cui la connessione al primo IP della lista vada in timeout, il broswer tenterà automaticamente di connettersi al secondo IP (e così via).

2) Utilizzo di un firewall interno per filtrare le connessioni in uscita (outbound). ln questo caso, grazie ad esso, potremmo creare delle regole ad hoc (source NAT) per il mapping delle porte di destinazione, ad esempio (utilizzando iptables):

[root@firewall ~]# iptables -t nat -A OUTPUT -p tcp -d www.vostrodominio.com --dport 80 -j DNAT --to-destination www.vostrodominio.com:81

Anche in questo caso, prima di applicare la suddetta regola di firewalling, sarà necessario modificare sul nameserver il record A per l’hostname www.

E’ tutto. Alla prossima.

CentOS 6 ed rsyslog: creare un sistema di log centralizzato per i dispositivi di rete

5 agosto 2015Networking, SO: Linuxcentos, cisco, ipsec, iptables, linux, netfilter, rsyslog, site-to-site, syslog, vpnnazarenolatella

Scenario

Diversi uffici periferici (in gergo branch office), connessi all’ufficio centrale (main office) mediante dei tunnel IPSec site-to-site dedicati (classici link VPN utilizzati per creare una intranet con topologia a stella).

Problema

Creare un sistema di log centralizzato per tutti i dispositivi di rete, compresi i router degli uffici periferici.

Soluzione

Utilizzare una Linux box (CentOS 6) con a bordo il demone che funge da syslog server, ovvero rsyslog.

Configurazione della Linux box e del syslog server

Per prima cosa occorre fare in modo che la nostra Linux box sia in grado di ricevere correttamente (sulla porta UDP 514) i log inoltrati dai dispositivi di rete. Per fare ciò è sufficiente creare la seguente regola di netfilter (ultilizzando iptables):

-A INPUT -m state --state NEW -m udp -p udp -s 192.168.0.0/16 --dport 514 -j ACCEPT

ed aggiungerla all’interno del file /etc/sysconfig/iptables, per poi lanciare un:

[root@linuxbox ~]# service iptables restart

in modo da rendere la suddetta regola operativa (da notare che 192.168.0.0/16 è la subnet classe B che raggruppa tutte le /24 utilizzate dai branch office).

Una volta fatto ciò è necessario aggiungere la seguente direttiva all’interno del file di configurazione rsyslog, ovvero /etc/rsyslog.conf:

$template CiscoVPN,"/var/log/cisco/system-%HOSTNAME%.log"

*.* -?CiscoVPN

e creare la dir di target in cui verranno salvati i log, ovvero /var/log/cisco:

[root@linuxbox ~]# mkdir -p /var/log/cisco

A questo punto possiamo riavviare rsyslog in modo da rendere effettive le suddette modifiche:

[root@linuxbox ~]# service rsyslog restart

Configurazione dei dispositivi di rete

Per semplicità mi soffermerò solo ed esclusivamente nella configurazione dei router (Cisco) dei branch office. Tale operazione consiste in 2 fasi: la definizione di una sorgente SNTP affidabile ed identica per tutti i network device (in modo da poter effettuare un’eventuale correlazione tra gli eventi) e la configurazione del syslog server target.

Per configurare la sorgente SNTP è sufficiente lanciare il comando:

Router(config)# sntp server <IP del server SNTP>

Ad esempio, se volessimo utilizzare come server SNTP ntp1.inrim.it, dovremmo digitare:

Router(config)# sntp server 193.204.114.232

Per quanto riguarda la configurazione del target dei log, è sufficiente lanciare i seguenti comandi:

Router(config)# service timestamps log
Router(config)# logging source-interface Vlan1
Router(config)# logging <IP del syslog server>

Il primo comando serve a fare in modo che il timestamp dell’evento venga aggiunto automaticamente alla entry del log; il secondo comando specifica l’interfaccia dalla quale i log devono essere inviati (essendo in VPN, l’interfaccia di riferimento è quella della LAN, in questo caso la Vlan 1); l’ultimo comando specifica molto banalmente l’indirizzo IP del syslog server.

Infine, controlliamo che i log vengano popolati in real time, lanciando il comando:

[root@linuxbox ~] #tail -f /var/log/system-<hostname>.log

dove <hostname> è l’hostname del dispositivo di rete di cui volete consultare il file di log.

Se tutto funziona a dovere possiamo dire di aver finalmente realizzato il nostro sistema di log centralizzato.

A presto.

OpenVPN e client multipli

30 novembre 2014Networking, Sicurezza, SO: Linuxclient multipli, nameserver, nat, openvpn, vpnnazarenolatella

In questo post ho discusso della configurazione di OpenVPN (sia client che server). Tale configurazione si basa su una rete privata punto-punto, consentendo quindi la connessione in VPN ad un solo client per volta (solitamente quello dell’amministratore di rete per eventuali attività da remoto).

Nel caso in cui, invece, si voglia consentire a più utenti di connettersi contemporaneamente al nostro VPN concentrator, è necessario apportare delle modifiche alla configurazione del server.

Di seguito gli step da seguire.

Configurazione del server

Per prima cosa, è necessario sostituire la direttiva:

ifconfig 192.168.110.1 192.168.110.2

con

server 192.168.110.0 255.255.255.0

Inoltre, mediante l’opzione:

 ifconfig-pool-persist ipp.txt

imporremo ad OpenVPN di mantenere una lista persistente di IP associati ai client, affinchè ad ogni nuova connessione venga loro assegnato sempre il medesimo indirizzo.

Per ragioni di sicurezza è meglio non far comunicare tra loro i client connessi in VPN ma, nel caso in cui si voglia consentire tale tipologia di traffico, è sufficiente aggiuntere questa opzione al file di configurazione del server:

client-to-client

Infine, se volessimo fare in modo che i client vegano nattati su Internet utilizzando l’IP pubblico del server VPN, è sufficiente aggiungere tali direttive al file di configurazione del demone in oggetto:

push "redirect-gateway def1"

impostando il nostro VPN concentrator come default gateway e:

push "dhcp-option DNS 8.8.8.8"

per forzare il nameserver da utilizzare durante la risoluzione degli FQDN in indirizzi IP.

E’ bene notare che, qualora fosse necessario, si dovrà operare anche sulla configurazione di netfilter del server VPN, impostando una regola di NAT simile alla seguente:

iptables -t nat -A POSTROUTING -s 192.168.110.0/24 -o eth1 -j MASQUERADE

e, nel caso in cui fosse abilitato lo steteful inspection, sarà necessario creare una regola del tipo:

iptables -A FORWARD -i eth1 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT

dove eth1 è l’interfaccia esposta su Internet e tun0 è l’interfaccia associata alla VPN.

Configurazione del client

Per il client, occorre semplicemente rimuovere la direttiva:

ifconfig 192.168.110.2 192.168.110.1

ed abbiamo finito.

Il post termina qui, alla prossima.

Configurare un router Cisco 2800 come server VPN PPTP

28 novembre 2014Networking, Sicurezzacisco, microsoft, pptp, vpn, vpndnazarenolatella

Premesso che le VPN PPTP non sono il massimo per ciò che concerne la sicurezza, a volte è conveniente scegliere tale tecnologia per questioni di semplicità. Infatti, il protocollo PPTP, essendo stato introdotto da Microsoft, è ampiamente supportato dai client Windows e quindi la loro configurazione risulta quasi immediata.

Ma bando alle ciance a vediamo come configurare il nostro router.

Per prima cosa è necessario abilitare il server VPN mediante il comando:

Router(config)# vpdn enable

successivamente occorre creare un gruppo vpnd, specificando diversi parametri come, ad esempio, il virtual-template:

Router(config)# vpdn-group 1

Router(config-vpdn)# accept-dialin
Router(config-vpdn-acc-in)# protocol pptp
Router(config-vpdn-acc-in)# virtual-template 1

Ora è necessario configurare il suddetto virtual-template:

Router(config)#int virtual-template 1
Router(config)# ip unnumbered FastEthernet0/1
Router(config)# ip nat inside
Router(config)# ip virtual-reassembly
Router(config)# peer default ip address pool PPTP-Pool
Router(config)# no keepalive
Router(config)# ppp encrypt mppe 128
Router(config)# ppp authentication ms-chap ms-chap-v2

In particolare, con i comandi:

Router(config)#ip unnumbered FastEthernet0/1

Router(config)# peer default ip address pool PPTP-Pool

faremo in modo che ai client VPN venga assegnato un IP del pool associato alla nostra LAN (PPTP-Pool non è altro che il nome del pool DHCP configurato sul router), mentre con il comando:

Router(config)# ip nat inside

consentiremo ai client VPN di uscire su Internet utilizzando l’IP pubblico del router.

Per la creazione delle utenze, è sufficiente lanciare il seguente comando in modalità di configurazione:

Router(config)# username <user> password <pass>

Se avete abilitato il service password-encryption la password non verà mostrata in chiaro nella configurazione ma in formato digest propriatario Cisco (che è comunque reversibile).

Salviamo la configurazione con un copy run start ed abbiamo finito.

Alla prossima.

Traffico PPTP in uscita dai router Cisco

22 gennaio 2013Networkingacl, cisco, egre, gre, microsoft, pptp, spoofing, vpnnazarenolatella

Il PPTP (Point to Point Tunnel Protocol) è uno dei protocolli utilizzati nell’ambito delle cosiddette VPN (Virtual Private Network). Esso venne introdotto dalla Microsfot e garantisce un certo livello di sicurezza, certamente molto inferiore a quello tipico delle VPN IPSec o SSL/TLS.

Senza scendere troppo nel dettaglio è bene specificare che il protocollo PPTP non va per niente daccordo con il NAT/PAT. Per questo motivo, affinchè le connessioni in uscita dalla nostra LAN e dirette al server VPN remoto vadano a buon fine, è necessario implementare un meccanismo di PPTP Passthrough. In realtà, tale meccanismo si basa sull’EGRE (Enhanced Generic Routing Protocol), quindi quello che faremo sarà semplicemente consentire il traffico GRE in ingresso alla nostra LAN.

Inoltre, poichè tale connessione è di tipo punto-punto, il router non vedrà l’indirizzo IP sorgente relativo alla VPN, ergo non dovremo neppure modificare le regole dell’ACL che hanno come scopo il blocco del traffico proveniente da Internet e con indirizzi IP privati (spoofing).

Come al solito, bando alle ciance ed ecco la regola da inserire subito prima il deny ip any any (implicito) della nostra ACL:

access-list 102 permit gre any any log

Ebbene si, il GRE è un protocollo differente da quelli visti fin’ora (ad esempio IP, TCP o UDP), non prevede l’uso di porte ed è abbastanza intelligente da lavorare senza ulteriori configurazioni.

Una volta aggiunta tale regola sul nostro router Cisco sarà possibile atterrare tranquillamente sul VPN Concentrator, ricevere un indirizzo IP appartenente al pool privato e navigare tra le risorse di rete (ed eventualmente su Internet) come se si fosse connessi direttamente alla LAN dell’ufficio.

E’ tutto. Bye.

Reboot script per i router Draytek Vigor

26 dicembre 2012Networkingautoreboot, bug, cli, cron, draytek vigor 3300v, expect, firewall, router, vpnnazarenolatella

Premesso che giornalmente devo “scontrarmi” con un Draytek Vigor 3300V, sono pian piano giunto alla conclusione che tale aggeggio abbia più difetti che pregi.

Ad esempio, il content filtering consente di bloccare al massimo 8 (e dico 8!) keyword e non ne vuole sapere di gestire l’HTTPS; la pagina relativa ai DDNS, nonostante la presenza delle credenziali per aggiornare l’associazione IP – FQDN, non inoltra alcuna richiesta al sito del provider e quindi i record A scadono; il server DHCP integrato non consente di settare delle normalissime exclusion su alcuni IP che rientrano nel pool ma che non devono essere assegnati a nessun utente.

Ora, potrei continuare quasi all’infinito, ma l’ultima bega che mi son dovuto accollare riguarda la gestione delle VPN. Si, esatto, questo fantastico router funge anche da VPN concentrator, riuscendo (per modo di dire) a gestire VPN IPSec, L2TP e PPTP. Peccato che ogni “tot” si incarti miseramente, lasciando fuori alcuni utenti che cercano di atterrare sulla LAN via VPN, mentre altri riescono tranquillamente ad accedere alla rete interna.

Ho provato a cercare una soluzione un pò più pulita rispetto al classico riavvio, ma credetemi se vi dico che non c’è (forse si potrebbe procedere con la disattivazione/riattivazione della VPN ma non sono sicuro che una cosa del genere non preveda comunque un reboot).

In definitiva, ecco lo scrip expect che mi permette di riavviare il router ogni notte:

#!/usr/bin/expect

set password1 "password"

exec date
spawn ssh -l draytek 10.1.10.1
expect "?"
send "yr"
expect "*?assword:*"
send "$password1r"
expect ">"
send "sys rebootr"
expect "?"
send "yr"
expect eof

Ovviamente l’esecuzione di tale scrip avviene mediante cron e non fa altro che connettersi al router, lanciare un sys/reboot ed uscire.

Attenzione però: dopo ogni riavvio il router cambia il proprio fingerprint SSH (non chiedetemi il perchè), quindi il suddetto scrip, dopo il primo riavvio, fallirebbe miseramente in quanto il client SSH, vedendosi cambiare di punto in bianco il fingerprint dell’host a cui sta provando a connettersi, penserebbe in un attacco MITM.

Per evitarè ciò è necessario editare il file /etc/ssh/ssh_config aggiungendo in testa le seguenti direttive:

Host 10.1.10.1
     StrictHostKeyChecking no
     UserKnownHostsFile=/dev/null

Infine, voglio precisare che il router è comunque dotato di un comando in grado di definire il reboot automatico (mi sa che gli stessi costruttori fossero a conoscenza del fatto che tale aggeggio tende ad incartarsi di continuo). Nonostante questo comando bundle, chiamato appunto autoreboot, ho preferito operare come indicato in precedenza per un semplice motivo:

DrayTek> sys autoreboot ?
 Full Name:
    auto reboot function
 Description:
 Syntax:
    autoreboot -s                                (Show status)
    autoreboot -e <Enable>
    autoreboot -t <Hours>
 Parameters:
    <Enable>                                         (0: Disable, 1: Enable)
    <Hours>                                          (Number of hours)

Si, avete capito bene, se volessi riavviare il router ogni mattina alle 3 (quindi esattamente ogni 24 ore) dovrei lanciare i comandi:

DrayTek> sys autoreboot -e 1

DrayTek> sys autoreboot -t 24

indovinate a che ora? ALLE 3 DEL MATTINO. No comment.

Alla prossima.

Strani log sul router Cisco 837

9 dicembre 2011Sicurezzaacl, cisco 837, crypto engine, crypto map, hack, router, vpnnazarenolatella

Ieri, mentre facevo i soliti controlli di routine, ho dato un’occhiata al log dei comandi lanciati sulla shell del mio Cisco 837 ed ho avuto una sincope appena ho letto le seguenti info:

*Dec  8 00:00:21.523: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:access-list 199 permit icmp host 10.10.10.10 host 20.20.20.20
*Dec  8 00:00:21.835: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:crypto map NiStTeSt1 10 ipsec-manual
*Dec  8 00:00:22.119: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:match address 199

*Dec  8 00:00:22.315: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:set peer 20.20.20.20

*Dec  8 00:00:22.367: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:exit
*Dec  8 00:00:22.471: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:no access-list 199
*Dec  8 00:00:22.571: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:no crypto map NiStTeSt1

WTF!??? Una VPN? Sono riusciti ad ottenere l’accesso (abusivo) al mio router?

Bhè, per fortuna non era niente di grave, in quanto questi comandi vengono lanciati automaticamente ad ogni riavvio del router per verificare il corretto funzionamento del suo crypto engine.

Falso allarme… e vissero tutti felici e contenti.