Tutti gli articoli di nazarenolatella

Nagios: script bash + expect per monitorare il numero di NAT translation sui router Cisco

Dopo aver cercato a lungo un OID SNMP che potesse restituirmi on-the-fly il numero di NAT translation attive sul mio router Cisco, sono arrivato alla conclusione che il modo più semplice per ricavare tale informazione consiste nel creare uno scrip bash + expect da dare in pasto a Nagios.

Nagios_logo_blackPer prima cosa, dunque, mi sono soffermato sulla creazione dello scrip expect, in modo da poter interrogare il router oggetto di monitoraggio, lanciando un comando specifico, che è il seguente:

Router# show ip nat statistics

Ed ecco lo scrip expect vero e proprio:

#!/usr/bin/expect

set ip [lindex $argv 0]
set password1 [lindex $argv 1]
set password2 [lindex $argv 2]

spawn ssh -l nightfly "$ip"
expect "*?assword:*"
send "$password1\r"
expect ">"
send "ena\r"
expect "Password:"
send "$password2\r"
expect "#"
send "show ip nat statistics\r"
expect "#"
send "exit\r"
expect eof

Esso riceve come parametri l’IP del dispositivo, la password vty e la password ena.
Dopo averlo chiamato get_nat_num (ed averlo reso eseguibile con chmod +x get_nat_num), mi sono soffermato sulla creazione dello scrip bash, che è il seguente:

#!/bin/bash

host=$1
password1=$2
password2=$3
warning=$4
critical=$5

usage="check_nat_translations <host> <password1> <password2> <warning> <critical>"

if [ -n "$host" ]; then

        if [ -n "$password1" ];then

                if [ -n "$password2" ];then

                        if [ -n "$warning" ];then

                                if [ -n "critical" ];then

                                        if [ "$critical" -lt "$warning" ];then

                                                echo "UNKNOWN: critical has to be greater than warning"
                                                exit 3;

                                        else

                                                output=`/usr/lib64/nagios/plugins/get_nat_num $1 $2 $3 | grep "Total active translations"  | awk '{print $4}'`

                                        fi

                                        if [ -n "$output" ];then

                                                if [ "$output" -ge "$critical" ];then

                                                        echo "CRITICAL: total number of active NAT translations is $output | nat_translations=$output;$warning;$critical";
                                                        exit 2;

                                                elif [ "$output" -lt "$critical"  -a  "$output" -ge "$warning" ];then

                                                        echo "WARNING: total number of active NAT translations is $output | nat_translations=$output;$warning;$critical";
                                                        exit 1;

                                                else

                                                        echo "OK: total number of active NAT translations is $output | nat_translations=$output;$warning;$critical";
                                                        exit 0;

                                                fi
                                        else

                                                echo "UNKNOWN: output is null"
                                                exit 3;

                                        fi

                                else

                                        echo "$usage"
                                        exit 3;
                                fi

                        else

                                echo "$usage"
                                exit 3;
                        fi

                else

                        echo "$usage"
                        exit 3;
                fi
        else

                echo "$usage"
                exit 3;
        fi

else

        echo "$usage"
        exit 3;

fi

Esso accetta in ingresso 5 parametri: i primi 3 da passare allo scrip get_nat_num, gli ultimi 2 da utilizzare come soglie per Nagios (una warning ed una critical).

Rendiamo eseguibile anche questo scrip (chmod +x check_nat_translations) e soffermiamoci sulla configurazione di Nagios.

Come primo step occorre creare il comando che utilizza i plugin appena creati:

# 'check_nat_translations' command definition
 define command{
 command_name    check_nat_translations
 command_line    $USER1$/check_nat_translations $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$
 }

Successivamente è necessario creare un servizio (da inserire nel file di configurazione relativo ad un host determinato), che si avvalga del comando creato in precedenza:

define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_descripion             NAT Translations Number
 check_command                   check_nat_translations!password1!password2!40000!50000
 }

Salviamo la configurazione, riavviamo Nagios, ed il gioco è fatto.

Alla prossima.

Centos 6: realizzare un Web cluster Active/Standby con keepalived

La ridondanza in ambito sistemistico è sinonimo di affidabilità. In questo post spiegherò come creare un Web cluster (Apache) Active/Standby su CentOS 6 utilizzando keepalived. keepalivedSchema di rete

Entrambi i nodi sono connessi in LAN, utilizzando un IP della classe 192.168.1.0/24 (eth0),  rispettivamente 192.168.1.3 per il nodo master e 192.168.1.4 per il nodo slave, mentre keepalived sta in ascolto su un due interfacce di rete configurate in bonding (bond0, formata da eth1 ed eth2).  L’IP virtuale del cluster è 192.168.1.2.

Installazione e configurazione di keepalived

Per prima cosa installiamo il suddetto demone su entrambi i server mediante yum:

[root@node1 ~]# yum install keepalived
[root@node2 ~]# yum install keepalived

Ad installazione completata possiamo procedere con la sua configurazione, editando il file /etc/keepalived/keepalived.conf, il cui contenuto, per il nodo 1, dovrà essere il seguente:

global_defs {
  notification_email {
    vostro.indirizzo@email.it
  }
  notification_email_from node1@localhost.localdomain
  smtp_server localhost
  smtp_connect_timeout 30
}

vrrp_script chk_httpd {
   script "killall -0 httpd"      # verify the pid existance
   interval 2                     # check every 2 seconds
   weight 2                       # add 2 points of prio if OK
}

vrrp_instance VI_1 {
   interface bond0               # interface to monitor
   state MASTER
   virtual_router_id 54          # Assign one ID for this route
   priority 101                  # 101 on master, 100 on backup
   advert_int 1
   smtp_alert
   virtual_ipaddress {
       192.168.1.2               # the virtual IP
   }
   track_script {
       chk_httpd
   }
}

mentre per il nodo 2 la configurazione è questa:

global_defs {
  notification_email {
    vostro.indirizzo@email.it
  }
  notification_email_from node2@localhost.localdomain
  smtp_server localhost
  smtp_connect_timeout 30
}

vrrp_scrip chk_httpd {
   scrip "killall -0 httpd"               # verify the pid existance
   interval 2                             # check every 2 seconds
   weight 2                               # add 2 points of prio if OK
}

vrrp_instance VI_1 {
   interface bond0               # interface to monitor
   state MASTER
   virtual_router_id 54          # Assign one ID for this route
   priority 100                  # 101 on master, 100 on backup
   advert_int 1
   smtp_alert
   virtual_ipaddress {
       192.168.1.2                # the virtual IP
   }
   track_scrip {
       chk_httpd
   }
}

Si può facilmente notare come la priorità del nodo master (nodo 1) sia superiore a quella del nodo slave (priorità assegnata mediante la direttiva priority).

Affinchè il servizio Apache rimanga in ascolto su entrambi i nodi anche quando l’IP virtuale del cluster (192.168.1.2) non è fisicamente allocato sulla macchina, è necessario fare un po’ di kernel tuning, lanciando il seguente comando:

[root@node1 ~]# echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
[root@node2 ~]# echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

e successivamente editando il file /etc/sysctl.conf per rendere la suddetta direttiva permanente, ovvero anche dopo eventuali riavvii delle macchine, inserendo quanto segue:

net.ipv4.ip_nonlocal_bind = 1

Prove di funzionamento

Basta stoppare il servizio httpd sul nodo master:

[root@node1 ~]# service httpd stop

e successivamente verificare che l’IP virtuale del cluster sia “migrato” sul nodo slave, lanciando su quest’ultimo il comando:

[root@node2 ~]# ip addr | grep 192.168.1.2

A questo punto ritiriamo su httpd sul nodo master:

[root@node1 ~]# service httpd start

e lanciamo

[root@node1 ~]# ip addr | grep 192.168.1.2

per verificare che l’IP virtuale sia “ritornato” sulla macchina principale.

Alla prossima.

Script powershell per identificare le password di dominio “deboli”

Ogni tanto fare una sorta di security audit sulla nostra rete è cosa buona e giusta, soprattutto se in passato questo task è stato totalmente ingnorato dai sistemisti di turno.

Proprio per questo motivo, ho pensato di realizzare un scrip powershell in grado di testare la robustezza delle password utilizzate dalle varie utenze di dominio.

powershellPreparazione

Per prima cosa occorre creare una lista di password “deboli” all’interno di un file di testo (weakpasswords.txt). Tale file dovrà contenere una sola password per riga, ad esempio:

 password1
 password2
 password3

Una volta fatto ciò occorre salvare in un altro file di testo le utenze di dominio, lanciando tale comando direttamente sul domain controller:

NET USERS /DOMAIN > users.txt

Il contenuto del file users.txt sarà simile al seguente:

User accounts for \\DC
------------------------------------------------------------------ utente1                        utente2               utente3  utente4                        utente5               utente6

Affinchè lo scrip possa funzionare, però, è necessario che vi sia un solo utente per riga, ergo bisogna parsare il file users.txt e salvare il suo contenuto (opportunamente formattato) all’interno di un altro file (parsed.txt). Per farè ciò ho utilizzato awk (su una Linux box):

[root@server ~]# cat users.txt | awk '{print $1}' >> parsed.txt
[root@server ~]# cat users.txt | awk '{print $2}' >> parsed.txt
[root@server ~]# cat users.txt | awk '{print $3}' >> parsed.txt

Contenuto dello script

Adesso il file parsed.txt può essere spostato sul DC e possiamo creare il nostro scrip (che chiameremo testauth.ps1) il cui contenuto dovrà essere:

Function Test-ADAuthentication {
    param($username,$password)
    (new-object directoryservices.directoryentry "",$username,$password).psbase.name -ne $null
}

$users = Get-Content parsed.txt 
foreach ($user in $users) {
    $user = $user.Trim()
    $passwords = Get-Content weakpasswords.txt
    foreach ($password in $passwords) {
        $password = $password.Trim()
        $result = Test-ADAuthentication "NOMEDOMINIO\$user" "$password"
        if ($result -like "True") {
            echo "Username $user has got a the weak password $password" >> passresult.txt
        }
        else
        {
            echo "Password for user $user did not match" 
        }
    }
}

Esecuzione

Non ci resta che eseguire tale scrip powershell mediante il comando:

./testauth.ps1

e successivamente verificare il contenuto del file passresult.txt, in cui saranno presenti le associazioni utente/password “debole”.

Alla prossima.

CentOS 6: Watchdog open source mediante Monit

Premesso che Monit può essere configurato anche come NMS a tutti gli effetti (sia centralizzato che distribuito, vedi M/Monit), lo scopo di questo post è quello di illustrarne la configurazione come semplice watchdog.

watchdogEsso, infatti, si occuperà di riavviare eventuali servizi “in stallo” (nella fattispecie httpd e mysql), riducendo notevolmente i tempi di downtime.

Per prima cosa occorre installare il suddetto applicativo:

[root@server ~]# yum install monit

Una volta installato possiamo editarne la configurazione (/etc/monit.conf) nel modo seguente:

set httpd port 2813 and #2813 è la porta su cui è in ascolto l'interfaccia Web di Monit
     use address <indirizzo IP>  #l'indirizzo IP è quello su cui l'interfaccia Web di Monit è in binding
     allow 0.0.0.0/0          #semplice ACL per consentire a qualunque IP sorgente di connettersi alla suddetta interfaccia  
     allow username:password      # credenziali di accesso all'interfaccia Web di Monit
     allow @monit           
     allow @users readonly

A questo punto creiamo due file all’interno della directory /etc/monit.d, rispettivamente httpd e mysqld.

Il primo conterrà le seguenti direttive:

check process httpd with pidfile /var/run/httpd.pid
group apache
start program = "/etc/init.d/httpd start"
stop program = "/etc/init.d/httpd stop"
if failed host 94.23.68.182 port 80
protocol http then restart
if 5 restarts within 5 cycles then timeout

Il secondo, invece, avrà il seguente contenuto:

check process MySQL-Server with pidfile /var/run/mysqld/mysqld.pid
    start program = "/etc/init.d/mysqld start"
    stop program = "/etc/init.d/mysqld stop"
    if failed host localhost port 3306
    protocol mysql then restart
    if 5 restarts within 5 cycles then timeout

Verifichiamo la sintassi delle suddette configurazioni mediante il comando:

[root@server ~]# monit -t

Ora possiamo avviare il nostro watchdog:

[root@server ~]# service monit start

imponendone l’avvio automatico dopo ogni reboot del server:

[root@server ~]# chkconfig monit on

Verifichiamo l’effettiva raggiungibilità dell’interfaccia Web di Monit mediante la URL:

http://IP:2813

ed il gioco è fatto.

E’ tutto. Alla prossima.

Configurare una VPN IPsec site-to-site tra un router Cisco 2811 ed un router Cisco 877W

Affinchè si possa realizzare un canale di comunicazione “sicuro” tra due o più filiali, sfruttando, ad esempio, una normale linea ADSL, è necessario affidarsi ad una tecnologia VPN che supporti tale funzionalità. Lo standard “de facto” per i collegamenti Site-to-Site è rappresentato dal protocollo IPsec.

Adesso vedremo come configurare tale tipologia di VPN, utilizzando come piattaforme hardware un router Cisco 2811 (main office) ed un router Cisco 877W (branch office).

Lo schema di rete si può riassumere come segue:

vpn-ipsecConfigurazione del router Cisco 2811 (Main Office)

La prima cosa da fare è creare la policy ISAKMP per gestire le Security Associations (in gergo dette semplicemente SA), ovvero le due entità che vogliono instaurare il tunnel VPN.

R1(config)crypto isakmp policy 1
R1(config-isakmp)# encr 3des
R1(config-isakmp)# hash md5
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 2
R1(config-isakmp)# lifetime 86400

In particolare, sto definendo alcuni parametri relativi alla fase 1 IKE (in realtà ISAKMP è solo uno dei 3 protocolli definiti nella suite IKE), ovvero:

1) il tipo di cifratura simmetrica da utilizzare (3des);

2) l’algoritmo di hashing per l’HMAC (md5), utilizzato per garantire l’integrità dei pacchetti scambiati tra le parti;

3) il tipo di autentica (tramite chiave condivisa – pre-shared);

4) il gruppo Diffie-Helman da utilizzare (l’algoritmo in questione definisce un metodo “sicuro” per lo scambio delle chiavi tra le parti);

5) la durata del tunnel IPSec (in secondi).

Ora si può procedere con la definizione della chiave condivisa:

R1(config)# crypto isakmp key cisco address 2.2.2.3

A questo punto possiamo configurare la fase 2 IKE, impostando l’apposito transform set:

R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac

Esso si occupa di cifrare i dati trasmessi tra le due parti dopo l’instaurazione del tunnel.

Definiamo adesso l’ACL che si occuperà di indentificare il traffico VPN (detto, in gergo, interesting traffic):

R1(config)# ip access-list extended VPN-TRAFFIC
R1(config-ext-nacl)# permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

A questo punto sarà possibile definire la crypto map:

R1(config)# crypto map CMAP 6 ipsec-isakmp 
R1(config-crypto-map)# set peer 2.2.2.3
R1(config-crypto-map)# set transform-set TS
R1(config-crypto-map)# match address VPN-TRAFFIC

Inoltre, dobbiamo evitare che il traffico LAN-to-LAN venga nattato. E’ possibile fare ciò definendo un’ACL ad hoc:

R1(config)# access-list 100 remark --NO-NAT--
R1(config)# access-list 100 deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
R1(config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 any
R1(config)# access-list 100 remark

associandola, successivamente, al processo di NAT vero e proprio:

R1(config)# ip nat inside source list 100 interface fastethernet0/0 overload

Come ultimo step dobbiamo associare la crypto MAP precedentemente definita all’interfaccia fa0/0 (Internet):

R1(config)# int fa0/0
R1(config-if)# crypto map CMAP

Configurazione del router Cisco 877W (Branch Office)

La configurazione del Branch Office è del tutto speculare a quella del Main office. L’unica stostaziale differenza sta nell’interfaccia esposta ad Internet: per il main office è la fa0/0 mentre per il branch office è la dia1 (protocollo PPPoE).

IKE fase 1:

R2(config)#  crypto isakmp policy 1
R2(config-isakmp)# encr 3des
R2(config-isakmp)# hash md5
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)# group 2
R2(config-isakmp)# lifetime 86400

Pre-shared key:

R2(config)# crypto isakmp key cisco address 2.2.2.2

IKE fase 2 (transform set):

R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac

 ACL per il traffico LAN-to-LAN:

R2(config)# ip access-list extended VPN-TRAFFIC
R2(config-ext-nacl)# permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

 Crypto map:

R2(config)# crypto map CMAP 6 ipsec-isakmp 
R2(config-crypto-map)# set peer 2.2.2.2
R2(config-crypto-map)# set transform-set TS
R2(config-crypto-map)# match address VPN-TRAFFIC

No-NAT:

R2(config)# access-list 100 remark --NO-NAT--
R2(config)# access-list 100 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
R2(config)# access-list 100 permit ip 192.168.2.0 0.0.0.255 any
R2(config)# access-list 100 remark
R2(config)# ip nat inside source list 100 int dia1 overload

Binding crypto map/interfaccia:

R2(config)# int dia1
R2(config-if)# crypto map CMAP
R2(config-if)# crypto ipsec df-bit clear

L’ultimo comando relativo alla configurazione dell’interfaccia dia1 ci mette al riparo da eventuali problemi dovuti ad un MTU mismatch (ad esempio, il router Cisco 2811 utilizza una MTU pari a 1500 byte mentre il router Cisco 877W, essendo configurato per un accesso ad Internet di tipo PPPoE, usa una MTU pari a 1492 byte).

Test e troubleshooting

Per testare l’effettivo funzionamento del tunnel VPN appena configurato è sufficiente, in primo luogo, lanciare un semplice ping verso la LAN del peer, avendo cura di definire come interfaccia sorgente quella esposta sulla rete privata:

R1(config)ping 192.168.2.1 source fa0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 41/44/46 m

Il primo ping ha restituito un timeout poichè il tunnel VPN viene tirato su solo on-demand, ovvero dopo aver appurato la presenza di traffico LAN-to-LAN, per poi rimanere attivo fino al timeout definito nella policy ISAKMP (86400 secondi).

Altri comandi utili per verificare lo stato del tunnel VPN sono i seguenti:

show crypto session
show crypto isakmp sa
show crypto ipsec sa
debug crypto isakmp
debug crypto ipsec

E’ tutto. Alla prossima.

Configurare un server VNC su CentOS 6

Avere a disposizione un server VNC sulla nostra linux box è molto comodo, soprattutto quando la si utilizza come “ponte” per accedere all’interfaccia Web di configurazione di alcuni dispositivi di rete (quali NAS, access point, router e così via).

vnc

Di seguitò illustrerò come fare ad installare e configurare un server VNC sulla nostra macchina CentOS 6.

Installazione  del server VNC

Per scaricare il server VNC è sufficiente utilizzare il packet manager integrato alla distro, ovvero yum:

[root@vncserver ~]# yum install tigher-vnc

Configurazione del server VNC

Per prima cosa occorre creare le utenze che andranno ad utilizzare il server VNC:

[root@vncserver ~]# useradd <username1>
[root@vncserver ~]# passwd <username1>
[root@vncserver ~]# useradd <username2>
[root@vncserver ~]# passwd <username2>

Una volta create le utenze,  occorre settare i parametri delle sessioni VNC a cui avranno accesso, editando il file /etc/sysconfig/vncserver:

VNCSERVERS="1:username1 2:username2"
VNCSERVERARGS[1]="-geometry 1024x768"
VNCSERVERARGS[2]="-geometry 1024x768"

Per entrambi gli utenti precedentemente definiti abbiamo previsto delle sessioni VNC con risoluzione a 1024×768.

A questo punto, ciascun utente, dovrà impostare la propria password VNC mediante il comando:

[username1@vncserver ~]$ vncpasswd

Infine, dovrà editare il file xstartup presente nella propria home directory:

[username1@vncserver ~]$ nano /home/username/.vnc/xstartup

commentando la entry:

#twm &

ed inserendo la seguente direttiva (nel caso in cui sulla linux box sia installato KDE come X server):

startkde &

Invece, se si sta utilizzando Gnome, la direttiva da inserire è la seguente:

exec gnome-session

Configurazione del firewall

Per configurare il firewall (netfilter) occorre editare il file /etc/sysconfig/iptables, aggiungendo quanto segue:

-A INPUT -m state --state NEW -m tcp -p tcp -m multiport --dports 5901:5903,6001:6003 -j ACCEPT

Riavviamo netfilter con il seguente comando:

[root@vncserver ~]# service iptables restart

e facciamo in modo che il nostro server VNC venga eseguito in modo automatico dopo ogni riavvio della macchina:

[root@vncserver ~]# chkconfig vncserver on

Infine, avviamo il suddetto demone:

[root@vncserver ~]# service vncserver start

Client VNC

Il client che preferisco è Real VNC Viewer e potete scaricarlo da qui.

Fine del post, a presto.

Websockets e Squid Proxy

Ultimamente ho deciso di approfondire una tecnologia Web abbastanza recente, ovvero i Websockets. In particolare, essa consente di instaurare un tunnel di comunicazione client/server attraverso il protocollo HTTP, riducendo notevolmente, rispetto al classico longpolling tipico del linguaggio AJAX, la mole di traffico richiesta e soprattutto l’overhead del server. Mediante i Websockets sarà possibile inviare “gli aggiornamenti” al client “in tempo reale”, ovvero senza che l’utente debba effettuare i classici “refresh” della pagina Web.

In ambito open source esistono diverse implementazioni dei Websockets. Quella che preferisco in assoluto si basa sulla libreria socket.io, integrata ad un applicativo nodejs (quest’ultimo rappresenta una vera e propria rivoluzione poichè ha consentito di utilizzare un linguaggio di programmazione nato per i client, ovvero Javascript, come un vero e proprio linguaggio server-side).

Ora, effettuando alcuni test su un proxy Web (Squid per la precisione), ho notato che i tentativi di connessione verso il server nodejs (sfruttando quindi i Websockets), venivano sistematicamente bloccati.

squid

La spiegazione è molto semplice. Infatti, andando a visualizzare la configurazione di default del suddetto proxy, è possibile notare la presenza di tale parametro:

http_access deny CONNECT !SSL_ports

Tale direttiva impone a Squid di negare l’uso del metodo HTTP CONNECT da parte dei client nel caso in cui non si stia utilizzando il protocollo HTTPS (HTTP + SSL/TLS). Infatti, di per se, il protocollo HTTPS prevede l’instaurazione di un “tunnel” di comunicazione “sicuro” tra client e server, utilizzando, per l’appunto, il metodo CONNECT. Ora, tale metodo viene utilizzato anche dai Websocket per creare il “canale” di comunicazione HTTP con i client, ergo basta commentare la suddetta entry per consentire l’accesso ai client:

#http_access deny CONNECT !SSL_ports

Effettuiamo reload della configurazione di Squid mediante il comando

[root@webProxy ~]# squid -k reconfigure

ed il gioco è fatto.

Alla prossima.

Record SPF troppo lunghi: ecco la soluzione

Alcuni DNS provider (come GoDaddy) sono in grado di gestire automaticamente i record TXT/SPF troppo lunghi, “spezzandoli” in stringhe separate (la lunghezza massima per ciascuna stringa contenuta in un record TXT è pari a 255 caratteri). Altri, invece, permettono di inserire dei record TXT/SPF contenuti in strighe lunghe a piacere, senza prevedere alcun meccanismo per lo “split” automatico del loro contenuto.

spf

Ciò è profondamente sbagliato, in quanto qualunque interrogazione DNS (ad esempio dig vostrodominio.com TXT), riporterà un numero eccessivo du bytes nella risposta, non consentendo la consultazione dei record SPF e quindi compromettendo del tutto il funzionamento di tale protocollo sperimentale.

Per evitare ciò è sufficiente utilizzare la direttiva include. Ad esempio, inserendo tale record TXT per la zona @:

"v=spf1 include:spf1.vostrodominio.com include:spf2.vostrodominio.com -all"

richiameremo altri 2 record TXT, ovvero:

spf1.vostrodominio.com  "v=spf1 ip4:244.11.23.13 ip4:144.21.23.13 -all"
spf2.vostrodominio.com  "v=spf1 ip4:222.11.11.13 ip4:244.182.23.191 ip4:203.101.22.13 -all"

aggirando quindi il problema delle stringhe eccessivamente lunghe.

Per testare il corretto funzionamento di tale settaggio potete consultare questo sito.

Alla prossima.

Cisco 877W: configurare una porta ethernet come WAN

Alcuni provider esteri prevedono l’accesso ad Internet tramite connessione diretta (via cavo UTP) tra il router del cliente (CPE – Customer Premise Equipment) ed un loro router di zona. Ciò permette di evitare completamente la vecchia linea POTS (detta anche PSTN), garantendo un servizio sicuramente migliore.

Per quanto riguarda il router Cisco 877W, occorre precisare che con l’IOS fornita di default (ovvero la 870-advsecurityk9-mz.124-24.T4.bin), l’unico modo per connettersi al service provider è mediante l’interfaccia ATM, utilizzando quindi il doppino telefonico. Per questa ragione, affinchè si possa configurare una porta ethernet WAN dedicata, è necessario, in primo luogo, aggiornare l’IOS del dispositivo in oggetto, sostituendo la  870-advsecurityk9-mz.124-24.T4.bin con la c870-advipservicesk9-mz.124-24.T6.bin.

cisco 877

Preparazione del router

Per prima cosa è necessario assegnare al router un indirizzo IP che possa contattare il server SCP (su cui copiare la vecchia IOS come backup e da cui scaricare quella nuova).

Router>
Router#
Router(config)# int vlan 1
Router(config-if)# ip address 192.168.1.9 255.255.255.0
Router(config-if)# end
Router# copy run start

Facciamo un ping al server SCP (per sincerarci che sia effettivamente raggiungibile):

Router# ping 192.168.1.8

Upgrade dell’IOS 

Poichè l’IOS (ovvero il sistema operativo del router) viene salvata all’interno della memoria flash (che comunque è piuttosto limitata in termini di spazio), occorre dapprima cancellare quella di default, rimuovendo anche tutti i file con estensione *.tar ed il file home.shtml (che concorrono a formare l’SDM).

Per prima cosa facciamo un backup della vecchia IOS (nel caso in cui l’operazione di upgrade dovesse non riuscire):

Router# copy flash: scp://user@192.168.1.8:870-advsecurityk9-mz.124-24.T4.bin

cancelliamo i file precedentemente elencati:

Router# delete flash:c870-advsecurityk9-mz.124-24.T4.bin
Router# delete flash:home.tar
Router# delete flash:common.tar
Router# delete flash:sdm.tar
Router# delete flash:home.shtml

e salviamo la nuova immagine nella memoria flash:

Router# copy scp://user@192.168.1.8:c870-advipservicesk9-mz.124-24.T6.bin flash:

A questo punto dobbiamo definire la nuova immagine da caricare al boot:

Router# conf t
Router(config)# boot system flash:c870-advipservicesk9-mz.124-24.T6.bin
Router(config)# end
Router# copy run start
Router# reload

Dopo il riavvio del router dobbiamo appurare che la nuova IOS sia stata effettivamente caricata. Per fare ciò è sufficiente lanciare il comando:

Router# sh ver

Bene, ora che il dispositivo in questione è stato aggiornato correttamente, possiamo procedere con la configurazione dello stesso.

Configurazione

Per prima cosa cancelliamo la nvram (dove è stata salvata la configurazione precedente):

Router# erase nvram:

e successivamente passiamo alla configurazione vera e propria:

no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname RouterADSL
!
boot-start-marker
boot-end-marker
!
logging exception 100000
logging count
logging message-counter syslog
logging queue-limit 10000
logging buffered 150000 notifications
logging console informational
enable secret <secret>
enable password <password>
!
no aaa new-model
clock timezone UTC 2
!
!
dot11 syslog
ip source-route
!
!
ip dhcp excluded-address 192.168.1.1 192.168.1.127
!
ip dhcp pool LAN
   network 192.168.1.0 255.255.255.0
   default-router 192.168.1.1
   dns-server 8.8.8.8 8.8.4.4
   domain-name uniqro.local
!
!
ip cef
ip name-server 8.8.8.8
ip name-server 8.8.4.4
!
multilink bundle-name authenticated
!
vpdn enable
!
vpdn-group 1
 accept-dialin
  protocol pptp
  virtual-template 1

!
!
!
no spanning-tree vlan 2
username admin password <password>
!
!
!
archive
 log config
  hidekeys
!
!
!
!
interface ATM0
 no ip address
 shutdown
 no atm ilmi-keepalive
!
interface FastEthernet0
 switchport access vlan 2
 no cdp enable
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface Virtual-Template1
 ip unnumbered Vlan1
 ip nat inside
 ip virtual-reassembly
 peer default ip address pool PPTP-Pool
 no keepalive
 ppp encrypt mppe 128
 ppp authentication ms-chap ms-chap-v2
!
interface Dot11Radio0
 no ip address
 shutdown
 speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0
 station-role root
!
interface Vlan1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 ip tcp adjust-mss 1452
!
interface Vlan2
 no ip address
 pppoe enable group global
 pppoe-client dial-pool-number 1
!
interface Dialer1
 ip address negotiated
 ip mtu 1492
 ip virtual-reassembly
 ip nat outside
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication chap pap callin
 ppp chap hostname <username>
 ppp chap password <password>
 ppp pap sent-username <username> password <password>
 ppp ipcp dns request accept
 ppp ipcp route default
 ppp ipcp address accept
!
ip local pool PPTP-Pool 192.168.1.244 192.168.1.254
ip forward-protocol nd
no ip http server
no ip http secure-server
ip route 0.0.0.0 0.0.0.0 Dia1
!
!
!
!
!
ip nat inside source list 1 interface Dialer1 overload
!
access-list 1 permit 192.168.1.0 0.0.0.255
dialer-list 1 protocol ip permit
!
control-plane
!
!
line con 0
 password <vostrapass>
 login
 no modem enable
line aux 0
line vty 0 4
 access-class 1 in
 password <vostrapass>
 login
!
scheduler max-task-time 5000
sntp server 193.204.114.232
!

Da notare che la suddetta configurazione comprende la timezone (clock timezone UTC 2), un server SNTP tramite il quale aggiornare la data e l’ora del router (sntp server 193.204.114.232), i parametri per il logging, la configurazione del server DHCP embedded e la configurazione della VPN PPTP (vedi questo post per approfondire).

Occorre soffermarsi, inoltre, sulla configurazione della VLAN 2. Infatti, essa ci permette di fare in modo che una delle porte ethernet del router possa essere configurata come WAN (ed è il reale motivo per cui abbiamo aggiornato l’IOS, poichè quella di default non consentiva di configurare VLAN multipe). Il protocollo utilizzato per la connessione all’ISP è il PPPoE ed i parametri associati alla VLAN 2 sono i seguenti:

interface Vlan2
 no ip address
 pppoe enable group global
 pppoe-client dial-pool-number 1

Nella fattispecie, la suddetta VLAN viene messa in binding con l’interfaccia virtuale (spoofed) Dialer 1, nella quale bisogna configurare i seguenti parametri:

interface Dialer1
 ip address negotiated
 ip mtu 1492
 ip virtual-reassembly
 ip nat outside
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication chap pap callin
 ppp chap hostname <username>
 ppp chap password <password>
 ppp pap sent-username <username> password <password>
 ppp ipcp dns request accept
 ppp ipcp route default
 ppp ipcp address accept

Infine, nella configurazione completa che ho illustrato precedentemente, potete notare che il protocollo spanning-tree è stato disabilitato per la VLAN 2:

no spanning-tree vlan 2

Ciò è preferibile in quanto, non conoscendo la configurazione del router di zona del provider, potrebbe venir fuori un port type mismatch con il successivo shutdown dell’interfaccia fa0 del nostro router (mi è già successo).

Infine, salviamo la nostra configurazione mediante il comando:

RouterADSL# copy run start

ed abbiamo finito.

Alla prossima.

DHCP e lease time: alcune considerazioni

Dopo la recente migrazione di un server DHCP da un dispositivo di tipo embedded ad un server dedicato (nella fattispecie un domain controller), mi sono soffermato sulla corretta configurazione del lease time.

dhcplease

Premesso che non esiste una configurazione “corretta” a prescindere, ma che essa dipende strettamente dal tipo di network su cui il servizio DHCP è in ascolto, occorre trovare la giusta quadra tra un tempo di lease ragionevole e l’utilizzo delle risorse locali del server (tenendo in cosiderazione, ovviamente, anche l’eventuale traffico previsto sulla rete).

Infatti, di per sè, il servizio DHCP (soprattutto quello messo a disposizione da Microsoft, almeno fino alla versione Windows Server 2008, secondo quanto riportato qui), prevede un uso “intensivo” del disco (leggasi I/O rate), in quanto il database con le associazioni IP/MAC viene consultato ogni volta che un nuovo dispositivo si “presenta” in rete oppure intende rinnovare il proprio tempo di lease. Ciascun client DHCP tenterà un rinnovo del tempo di lease allo scadere del 50% dello stesso (passando dallo status BOUND a quello RENEWING). Se tale attività non andrà a buon fine, verrà tentato un rinnovo allo scadere dell’87.5% del lease time (passando dallo status RENEWING a quello REBINDING). Se anche in questo caso non si otterrà l’estensione del suddetto tempo di lease, il client entrerà in status INIT per richiedere un nuovo indirizzo IP. E’ palese che tali tentativi sono tanto più frequenti quanto il tempo di lease è ridotto.

Ora, un tempo di lease “basso” è comunque una scelta corretta quando si ha a che fare con una rete che prevede la connessione di un numero abbastanza elevato di dispositivi (Wi-Fi), pur essendoci a disposizione un pool DHCP (leggasi scope) non molto esteso (ad esempio una classe /25). In questo caso un lease time di 360 minuti (6 ore) sembra abbastanza ragionevole. Invece, se si ha a che fare con network in cui il numero di dispositivi è piuttosto ridotto, va bene mantenere il lease time di default (pari a 8 giorni per il DHCP server di casa Microsoft).

Una volta impostato il lease time conviene sempre e comunque tenere sotto controllo lo stato del servizio DHCP, poichè un’errata configurazione dello stesso potrebbe portare all’impossibilità, da parte dei client, di connettersi alla rete (DHCPNAK ad ogni nuova richiesta per via dello scope ormai saturo).

Qui trovate un link in cui sono presenti le varie icone (con relativo significato) che possono comparire sullo “status” del server DHCP Microsoft.

E’ tutto. Alla prossima.