Archivi tag: router

Cisco 877: configurazione del server DHCP integrato

Come ogni router che si rispetti, anche il Cisco 877 può essere configurato a mo’ di server DHCP, seguendo una procedura abbastanza semplice ed intuitiva. In questo post vedremo come tirare giù una configurazione base, comprensiva di una exclusion e di una reservation.

cisco 877Definizione dei pool DHCP e della reservation

Per prima cosa occorre definire i pool di indirizzi IP da cui il nostro server andrà “a pescare” quelli da assegnare alle macchine che ne faranno richiesta. Nello specifico, ho creato 2 pool, uno per gli indirizzi della LAN (pool wifi) ed uno necessario alla reservation (pool pcportatile), ovvero:

ip dhcp pool wifi
   network 192.168.7.0 255.255.255.0
   default-router 192.168.7.1
   dns-server 192.168.7.1
!
ip dhcp pool pcportatile
   host 192.168.7.3 255.255.255.0
   client-identifier 0149.d224.a5d4.0e
   default-router 192.168.7.1
   dns-server 192.168.7.1

Da notare che per il pool pcportatile ho utilizzato la direttiva client-identifier, recante il MAC address del dispositivo oggetto della reservation, nella forma aaaa.bbbb.cccc e con prefisso 01. Nella fattispecie, il MAC address del PC è 49:d2:24:a5:d4:0e, che in notazione Cisco diventa 49d2.24a5.d40e. Aggiungiamo quindi lo 01 come prefisso ed avremo il client-identifier finale, ovvero 0149.d224.a5d4.0e.

Detto ciò, un modo rapido di ricavare il suddetto identificativo consiste nell’utilizzo del seguente comando:

sh ip dhcp binding

il cui output sarà simile al seguente:

Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
                    Hardware address/
                    User name
192.168.7.3         0149.d224.a5d4.0e       Infinite                Manual
192.168.7.8         0151.f0d3.fc7d.54       Sep 07 2016 09:15 AM    Automatic

Definizione dell’exclusion

Per ciò che concerne l’exclusion, la sua configurazione consta di un’unica direttiva, ovvero:

ip dhcp excluded-address 192.168.7.2

In tal modo faremo sì che l’IP 192.168.7.2 non rientri nei pool precedentemente definiti e quindi non possa essere assegnato a nessun dispositivo (poichè trattasi di un indirizzo statico associato ad una stampante).

Il post termina qui, alla prossima.

check_noise_margin e check_attenuation: script Nagios per verificare la qualità della nostra linea ADSL

Premessa

Vi sono numerosi fattori che possono influenzare negativamente o positivamente la qualità della nostra linea ADSL, ma i più importanti sono sicuramente il rapporto segnale rumore (SNR o noise margin) e l’attenuazione.

In particolare, nel primo caso un valore elevato indica una qualità migliore; viceversa, nel secondo caso, un valore elevato indica una qualità peggiore. Inoltre, i valori di attenuazione sono molto influenzati dalla distanza che intercorre tra la nostra abitazione e la centrale di zona dell’ISP (va da se che maggiore sarà questa distanza, maggiore sarà l’attenuazione).

Esistono comunque dei valori di massima (sia per l’SNR che per l’attenuazione) sui quali ci si può basare per fare una stima qualitativa del nostro collegamento ADSL. Li riporto di seguito:

SNR

1) <= 6dB : pessimo, numerosi errori si sincronizzazione con la portante;
2) tra i 7dB ed i 10dB: scarso;
3) tra gli 11dB ed i 20dB: buono;
4) tra i 20dB ed i 28dB: eccellente;
5) >= 29dB: eccezionale.

 Attenuazione

1) < = 20dB: eccezionale;
2) tra i 20dB ed i 30dB: eccellente:
3) tra i 30dB ed i 40dB: molto buona;
4) tra i 40dB ed i 50dB: buona;
5) tra i 50dB ed i 60dB: scarsa, con diversi errori di connessione.
6) >= 60dB: pessima, con numerosi errori di connessione.

Tenendo conto dei suddetti valori, ho deciso di realizzare 2 scrip bash (da integrare a Nagios), in modo da tenere traccia dei valori di SNR ed attenuazione relativi alla mia linea ADSL. Il router di riferimento è un Cisco 877.

Entrambi gli scrip in questione (check_noise_margin e check_attenuation), si basano su un ulteriore scrip expect (get_dsl_info) che esegue la query sul router, lanciando il comando sh dsl int atm0.

Il contenuto di tale scrip è il seguente:

#!/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 "sh dsl int atm0\r"
send " "
expect "#"
send "exit\r"
expect eof

L’output da esso generato verrà quindi dato in pasto ed elaborato da check_noise_margin e da check_attenuation. Il loro contenuto è molto simile ed è (rispettivamente):

#!/bin/bash

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

usage="check_noise_margin <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" -gt "$warning" ];then

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

                                        else

                                                output=`/usr/lib64/nagios/plugins/get_dsl_info $1 $2 $3 | grep "Noise"  | awk -F " " '{print $3,$5}'`
                                                output1=`echo $output | awk '{print $1}'`
                                                output2=`echo $output | awk '{print $2}'`
                                                unit="db"
                                        fi

                                        if [ -n "$output" ];then

                                                if [ $(echo "$output1 < $critical" | bc) -eq 1 -o $(echo "$output2 < $critical" | bc) -eq 1 ];then

                                                        echo "CRITICAL: downstream noise margin is $output1 db, upstream noise margin is $output2 db | downstream_noise_margin=$output1$unit;$warning;$critical upstream_noise_margin=$output2$unit;$warning;$critical";
                                                        exit 2;

                                                elif [ $(echo "$output1 > $critical" | bc) -eq 1 -a  $(echo "$output1 < $warning" | bc) -eq 1 -o $(echo "$output2 > $critical" | bc) -eq 1 -a $(echo "$output2 < $warning"  |bc) -eq 1 ];then

                                                        echo "WARNING: downstream noise margin is $output1 db, upstream noise margin is $output2 db| downstream_noise_margin=$output1$unit;$warning;$critical upstream_noise_margin=$output2$unit;$warning;$critical" ;
                                                        exit 1;

                                                else

                                                        echo "OK: downstream noise margin is $output1 db, upstream noise margin is $output2 db | downstream_noise_margin=$output1$unit;$warning;$critical upstream_noise_margin=$output2$unit;$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

per check_noise_margin, e:

#!/bin/bash

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

usage="check_attenuation <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_dsl_info $1 $2 $3 | grep "Attenuation"  | awk -F " " '{print $2, $4}'`

                                                output1=`echo $output | awk '{print $1}'`
                                                output2=`echo $output | awk '{print $2}'`
                                                unit="db"
                                        fi

                                        if [ -n "$output" ];then

                                                if [ $(echo "$output1 > $critical" | bc) -eq 1 -o $(echo "$output2 > $critical" | bc) -eq 1 ];then

                                                        echo "CRITICAL: downstream attenuation is $output1 db, upstream attenuation is $output2 db | downstream_attenuation=$output1$unit;$warning;$critical upstream_attenuation=$output2$unit;warning;$critical";
                                                        exit 2;

                                                elif [ $(echo "$output1 < $critical" | bc) -eq 1 -a  $(echo "$output1 > $warning" | bc) -eq 1 -o $(echo "$output2 < $critical" | bc) -eq 1 -a  $(echo "$output2 > $warning" | bc) -eq 1 ];then

                                                        echo "WARNING: downstream attenuation is $output1 db, upstream attenuation is $output2 db | downstream_attenuation=$output1$unit;$warning;$critical upstream_attenuation=$output2$unit;$warning;$critical";
                                                        exit 1;

                                                else

                                                        echo "OK: downstream attenuation is $output1 db, upstream attenuation is $output2 db | downstream_attenuation=$output1$unit;$warning;$critical upstream_attenuation=$output2$unit;$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

per check_attenuation.

Da notare che in entrambi i casi ho aggiunto le perfdata da dare in pasto a pnp4nagios. Inoltre, poichè i valori restituiti possono contenere dei decimali, ho dovuto utilizzare il comando bc per i calcoli aritmetici. Ciò si è reso necessario poichè bash tratta nativamente le variabili come stringhe.

Una volta fatto ciò, ho semplicemente creato i comandi per Nagios:

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

collegandoli, successivamente, ai servizi del router Cisco:

define service{
 use                             local-service         ; Name of service template to use
 host_name                       router
 service_descripion             Noise Margin
 check_command                   check_noise_margin!pass1!pass2!10!6
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       router
 service_descripion             Attenuation
 check_command                   check_attenuation!pass1!pass2!51!61
 }

Infine, ho lanciato un reload del servizio:

[root@nightbox objects]# service nagios reload

e finalmente la qualità della mia linea ADSL è sotto monitoraggio.

Alla prossima.

PS: per chi le preferisse, ecco le varianti in Perl dei suddetti scrip:

#!/usr/bin/perl

use strict;
use warnings;

my $host=$ARGV[0];
my $password1=$ARGV[1];
my $password2=$ARGV[2];
my $warning=$ARGV[3];
my $critical=$ARGV[4];

my $usage="check_noise_margin.pl <host> <password1> <password2> <warning> <critical>";

if ($host ne "") {
        if ($password1 ne "")
        {
                if ($password2 ne "")
                {
                        if ($warning ne "")
                        {
                                if ($critical ne "")
                                {
                                        if ($critical > $warning)
                                        {
                                                print "UNKNOWN: critical has to be less than warning";
                                                exit 3;
                                        }
                                        else
                                        {
                                                my $output=`/usr/lib64/nagios/plugins/get_dsl_info $host $password1 $password2 | /bin/grep "Noise"`;

                                                if($output ne "")
                                                {

                                                        my @columns = split /\s+/, $output;
                                                        my $downstream = $columns[2];
                                                        my $upstream = $columns[4];
                                                        my $unit = "db";

                                                        if ($downstream < $critical || $upstream < $critical)
                                                        {
                                                                print "CRITICAL: downstream noise margin is $downstream db; upstream noise margin is $upstream db | downstream_noise_margin=$downstream$unit;$warning;$critical upstream_noise_margin=$upstream$unit;$warning;$critical\n";
                                                                exit 2;
                                                        }
                                                        elsif ($downstream > $critical && $downstream < $warning || $upstream > $critical && $upstream < $warning)
                                                        {
                                                                print "WARNING: downstream noise margin is $downstream db; upstream noise margin is $upstream db | downstream_noise_margin=$downstream$unit;$warning;$critical upstream_noise_margin=$upstream$unit;$warning;$critical\n";
                                                                exit 1;
                                                        }
                                                        else
                                                        {
                                                                print "OK: downstream noise margin is $downstream db, upstream noise margin is $upstream db | downstream_noise_margin=$downstream$unit;$warning;$critical upstream_noise_margin=$upstream$unit;$warning;$critical\n";
                                                                exit 0;
                                                        }
                                                }
                                                else
                                                {
                                                                print "UNKNOWN: output is null";
                                                                exit 3;
                                                }
                                        }
                                }
                                else
                                {
                                        print "$usage";
                                        exit 3;
                                }
                        }
                        else
                        {
                                print "$usage";
                                exit 3;
                        }
                }
                else
                {
                        print "$usage";
                        exit 3;
                }
        }
        else
        {
                print "$usage";
                exit 3;
        }
}
else
{
        print "$usage";
        exit 3;
}

e

#!/usr/bin/perl

use strict;
use warnings;

my $host=$ARGV[0];
my $password1=$ARGV[1];
my $password2=$ARGV[2];
my $warning=$ARGV[3];
my $critical=$ARGV[4];

my $usage="check_attenuation.pl <host> <password1> <password2> <warning> <critical>";

if ($host ne "") {
        if ($password1 ne "")
        {
                if ($password2 ne "")
                {
                        if ($warning ne "")
                        {
                                if ($critical ne "")
                                {
                                        if ($critical < $warning)
                                        {
                                                print "UNKNOWN: critical has to be more than warning";
                                                exit 3;
                                        }
                                        else
                                        {
                                                my $output=`/usr/lib64/nagios/plugins/get_dsl_info $host $password1 $password2 | /bin/grep "Attenuation"`;

                                                if($output ne "")
                                                {

                                                        my @columns = split /\s+/, $output;
                                                        my $downstream = $columns[1];
                                                        my $upstream = $columns[3];
                                                        my $unit = "db";

                                                        if ($downstream > $critical || $upstream > $critical)
                                                        {
                                                                print "CRITICAL: downstream attenuation is $downstream db; upstream attenuation is $upstream db | downstream_attenuation=$downstream$unit;$warning;$critical upstream_attenuation=$upstream$unit;$warning;$critical\n";
                                                                exit 2;
                                                        }
                                                        elsif ($downstream < $critical && $downstream > $warning || $upstream < $critical && $upstream > $warning)
                                                        {
                                                                print "WARNING: downstream attenuation is $downstream db; upstream attenuation is $upstream db | downstream_attenuation=$downstream$unit;$warning;$critical upstream_attenuation=$upstream$unit;$warning;$critical\n";
                                                                exit 1;
                                                        }
                                                        else
                                                        {
                                                                print "OK: downstream attenuation is $downstream db, upstream attenuation is $upstream db | downstream_attenuation=$downstream$unit;$warning;$critical upstream_attenuation=$upstream$unit;$warning;$critical\n";
                                                                exit 0;
                                                        }
                                                }
                                                else
                                                {
                                                                print "UNKNOWN: output is null";
                                                                exit 3;
                                                }
                                        }
                                }
                                else
                                {
                                        print "$usage";
                                        exit 3;
                                }
                        }
                        else
                        {
                                print "$usage";
                                exit 3;
                        }
                }
                else
                {
                        print "$usage";
                        exit 3;
                }
        }
        else
        {
                print "$usage";
                exit 3;
        }
}
else
{
        print "$usage";
        exit 3;
}

PPS: se sul vostro router è stato abilitato il protocollo SNMP, gli OID che consentono di monitorare SNR ed attenuazione sono i seguenti:

.1.3.6.1.2.1.10.94.1.1.3.1.5.11 = downstream attenuation 
.1.3.6.1.2.1.10.94.1.1.2.1.5.11 = upstream attenuation 
.1.3.6.1.2.1.10.94.1.1.3.1.4.11 = downstream noise margin
.1.3.6.1.2.1.10.94.1.1.2.1.4.11 = upstream noise margin

In particolare, l’ultima parte dell’OID (.11) si riferisce all’Interface Index della Dialer (nel mio caso si tratta della Dialer0).

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

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

vpn-ipsec1Utilizzando 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.

Realizzare un server AAA mediante CentOS 6 e tac_plus

Premessa

Quando si ha a che fare con reti di grandi dimensioni (che contano centinaia e centinaia di dispositivi connessi tra di loro), occorre fare in modo che gli account utente (ed i relativi permessi) vengano gestiti in modo centralizzato. Tale funzione viene svolta dai cosiddetti server AAA, i quali, mediante l’uso di determinati protocolli (come RADIUS, DIAMETER o TACACS+), forniscono dei meccanismi per l’autenticazione dell’utente (Athentication), per la gestione dei relativi permessi (Authorization) e per la “registrazione” delle azioni  compiute dopo aver ottenuto accesso ai dispositivi (Accounting).

aaa

Un po’ di teoria

Come già detto in precedenza, i protocolli maggiormente utilizzati per le funzioni AAA sono RADIUS (anche nella variante più recente DIAMETER) e TACACS+.

Il primo è uno standard open, basato sul protocollo UDP, meno sicuro rispetto al TACACS+ (in quanto cifra solo ed esclusivamente il pacchetto che contiene le credenziali di autentica, lasciando il resto delle comunicazioni in plaintext) e che combina in un unico processo i meccanismi di autenticazione ed autorizzazione.

Il secondo, invece, è uno standard basato sul protocollo TCP (porta 49), proprietario (Cisco), più sicuro rispetto al RADIUS (cifra tutti i pacchetti) e che gestisce ciascuna funzione tipica dell’AAA in modo separato e distinto.

Dati i presupposti, la scelta del protocollo da utilizzare nel nostro ambiente ricade abbondantemente su TACACS+ (essendo inoltre di casa Cisco i dispositivi di rete che si intende gestire).

Installazione e configurazione del server AAA

Come si può banalmente evincere dal titolo, il server in questione è stato realizzato utilizzando una Linux box (CentOS 6) con a bordo il demone tac_plus.

Per prima cosa, occorre quindi installare il suddetto applicativo, aggiungendo il repository yum specifico (nux-misc.repo) alla repolist della nostra macchina:

[root@linuxbox ~]# cd /etc/yum.repos.d/
[root@linuxbox ~]# nano nux-misc.repo

il cui contenuto dovrà essere:

[nux-misc]
name=Nux Misc
baseurl=http://li.nux.ro/download/nux/misc/el6/x86_64/
enabled=0
gpgcheck=1
gpgkey=http://li.nux.ro/download/nux/RPM-GPG-KEY-nux.ro

Fatto ciò possiamo procedere con l’installazione vera e propria:

[root@linuxbox ~]# yum --enablerepo=nux-misc install tac_plus

Una volta installato il pacchetto facciamo un backup della sua configurazione di default:

[root@linuxbox ~]# cp /etc/tac_plus.conf /etc/tac_plus.conf.bak

e focalizziamo la nostra attenzione sul file di configurazione che andremo a creare ex-novo:

[root@linuxbox ~]# nano /etc/tac_plus.conf

Il cui contenuto dovrà essere simile al seguente:

key = <passphrase tacacs+>

#ACL

acl = default   {
                permit = 192\.168\.0\.1
}

# * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
# *                      ACCOUNTING                       *
# * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 

accounting file = /var/log/tac_accounting.log

#

# * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
# *                     AUTHENTICATION                    *
# * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

user = Pippo {
        default service = permit
        login = des 43v/eMDQqTT2o
        member = NOC
}

user = Pluto {
        login = des 44LWBaN31RmGg
        member = NOC

        #AUTHORIZATION ENTRIES
        cmd = show {
                permit .*
        }
        cmd = exit {
                permit .*
        }
}

group = NOC {
        acl = default
}

# End config file

Analizziamo il suddetto file. Esistono fondamentalmente due macro sezioni, ovvero authentication ed accounting.

Nella prima ho specificato i 2 utenti (con relativa password) che possono avere accesso ai dispositivi di rete, mentre nella seconda ho indicato il file di log in cui “registrare” tutti gli eventi associati all’accounting.

Da notare che la password degli utenti è in formato DES (cifrata), ed è stata ottenuta utilizzando il tool tac_pwd nel modo seguente:

[root@linuxbox ~]# tac_pwd <salt>

Inoltre, all’interno della sezione authentication, ho inserito, per l’utente Pluto, alcune restrizioni sui comandi che possono essere lanciati. Nella fattispecie, egli potrà utilizzare solo ed esclusivamente i comandi show (il permit = .* indica tutto ciò che viene dopo la keyword show) ed exit. Per quanto riguarda l’utente Pippo, essendoci un deny implicito per il servizio di authorization (quindi tutti i comandi non espressamente dichiarati vengono automaticamente inibiti), ho dovuto aggiungere la direttiva default service = permit.

Da notare che ho inserito anche un’opportuna ACL per fare in modo che solo i dispositivi autorizzati possano dialogare col suddetto demone (ACL coadiuvata da regole di firewalling ad hoc, in modo da rispettare il più possibile il modello defense in depth).

A configurazione ultimata, possiamo avviare il demone:

[root@linuxbox ~]# service tac_plus start

e fare in modo che venga avviato automaticamente dopo ogni reboot:

[root@linuxbox ~]# chkconfig tac_plus on

Come ultimo step relativo alla configurazione del server AAA, sarà necessario creare un’opportuna regola netfilter (utilizzando iptables) per consentire il traffico TACACS+ in ingresso:

-A INPUT -m state --state NEW -m tcp -p tcp -s 192.168.0.1/32 --dport 49 -j ACCEPT -m comment --comment "router"

 Configurazione dei dispositivi di rete

Per semplificare un po’ le cose utilizzerò come modello di riferimento la configurazione di un router 2811, anche se essa dovrebbe essere comunque molto simile (se non identica) per la stragrande maggioranza dei dispositivi marchiati Cisco.

Per prima cosa abilitiamo le funzionalità AAA:

Router(config)# aaa new-model

per poi soffermarci sull’autentica:

Router(config)# aaa authentication login default group tacacs+ local

e sulla definizione del server TACACS+ con relativa chiave:

Router(config)# tacacs-server host <ip>
Router(config)# tacacs-server key 0 <pass>

Occorre precisare che l’autenticazione è stata configurata in modo da prevedere un meccanismo di fallback, ovvero nel caso in cui il server AAA non fosse più raggiungibile, sarà comunque possibile loggarsi sul dispositivo utilizzando gli account utente definiti localmente.

Inoltre, nel caso in cui il suddetto server fosse raggiungibile dagli uffici periferici mediante dei tunnel VPN dedicati, occorrerà specificare nella loro configurazione l’interfaccia dalla quale esso puotrà essere contattato:

Router(config)# ip tacacs source-interface <int>

Successivamente possiamo procedere con la configurazione dell’authorization:

aaa authorization exec default group tacacs+ local
aaa authorization commands 1 default group tacacs+ local
aaa authorization commands 15 default group tacacs+ local

e dell’accounting:

Router(config)# aaa accounting system default start-stop group tacacs+
Router(config)# aaa accounting network default start-stop group tacacs+
Router(config)# aaa accounting exec default start-stop group tacacs+
Router(config)# aaa accounting commands 0 default start-stop group tacacs+
Router(config)# aaa accounting commands 15 default start-stop group tacacs+
Router(config)# aaa accounting session-duration ntp-adjusted

Prima di salvare la configurazione, testiamo il corretto funzionamento del meccanismo di autentica, digitando:

Router# test aaa group tacacs+ <user> <pass> legacy

il cui output dovrebbe essere:

Attempting authentication test to server-group tacacs+ using tacacs+
User was successfully authenticated.

Adesso si può finalmente procedere con il salvataggio della configurazione:

Router# copy run start

ed abbiamo finito.

Alla prossima.

Configurare il protocollo SNMP su un router Cisco 2811

In questo post abbiamo visto come configurare una linux box affinchè possa ricevere le trap SNMP. Adesso vedremo come configurare il portocollo SNMP (sia polling che trap) su un router Cisco 2811.

cisco2811Configurazione generica

Per prima cosa occorre accedere alla CLI del router in modalità ena e successivamente lanciare i seguenti comandi:

Router# conf t
Router(config)# snmp-server host <IP> keypublic
Router(config)# snmp-server community keypublic RO
Router(config)# snmp-server community keyprivate RW

Mediante il primo comando stiamo definento l’host target delle trap SNMP, mentre con il secondo ed il terzo comando specifichiamo rispettivamente la community string in lettura e quella in scrittura.

Abilitazione delle trap

A questo punto possiamo definire le trap che dovranno essere inviate alla nostra linux box, ad esempio:

Router(config)# snmp-server enable traps snmp
Router(config)# snmp-server enable traps vrrp
Router(config)# snmp-server enable traps hsrp
Router(config)# snmp-server enable traps tty
Router(config)# snmp-server enable traps ethernet cfm cc
Router(config)# snmp-server enable traps ethernet cfm crosscheck
Router(config)# snmp-server enable traps memory
Router(config)# snmp-server enable traps config-copy
Router(config)# snmp-server enable traps config
Router(config)# snmp-server enable traps resource-policy
Router(config)# snmp-server enable traps pppoe
Router(config)# snmp-server enable traps cpu
Router(config)# snmp-server enable traps syslog
Router(config)# snmp-server enable traps isakmp policy add
Router(config)# snmp-server enable traps isakmp policy delete
Router(config)# snmp-server enable traps isakmp tunnel start
Router(config)# snmp-server enable traps isakmp tunnel stop
Router(config)# snmp-server enable traps ipsec cryptomap add
Router(config)# snmp-server enable traps ipsec cryptomap delete
Router(config)# snmp-server enable traps ipsec cryptomap attach
Router(config)# snmp-server enable traps ipsec cryptomap detach
Router(config)# snmp-server enable traps ipsec tunnel start
Router(config)# snmp-server enable traps ipsec tunnel stop
Router(config)# snmp-server enable traps ipsec too-many-sas

Inutile dire che la tipologia di trap da abilitare dipende strettamente dalla configurazione del router, dalle feature abilitate (VPN IPsec), dal tipo di connessione WAN (PPP), ecc.

Polling SNMP tramite Nagios

Premesso che gli OID SNMP possono variare in base alla versione di IOS installata sul nostro router (a tal proposito vi consiglio di consultare questo sito), per prima cosa occorre definire i comandi specifici (all’interno dei file /etc/nagios/object/commands.cfg) che dovranno essere utilizzati dal nostro NMS per interrogare il dispositivo target.

Eccone un esempio:

# 'check_snmp_if_status' command definition
define command{
        command_name    check_snmp_if_status
        command_line    $USER1$/check_snmp -t 20 -H $HOSTADDRESS$ -C $ARG1$ -o $ARG2$ -r $ARG3$
        }
# 'check_snmp_cpu_load' command definition

define command{
        command_name    check_snmp_cpu_load
        command_line    $USER1$/check_snmp -t 20 -H $HOSTADDRESS$ -C $ARG1$ -o $ARG2$ -w $ARG3$ -c $ARG4$
        }

# 'check_snmp_used_memory' command definition

define command{
        command_name    check_snmp_used_memory
        command_line    $USER1$/check_snmp -t 20 -H $HOSTADDRESS$ -C $ARG1$ -o $ARG2$ -w $ARG3$ -c $ARG4$
        }

# 'check_snmp_uptime' command definition

define command{
        command_name    check_snmp_uptime
        command_line    $USER1$/check_snmp -t 20 -H $HOSTADDRESS$ -C $ARG1$ -o $ARG2$ -w $ARG3$ -c $ARG4$
        }

Infine, definiamo i servizi che si avvarranno dei suddetti comandi:

define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Uptime
 check_command                   check_snmp_uptime!keypublic!.1.3.6.1.6.3.10.2.1.3.0!@61:900!@0:60
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Last Minute CPU Load
 check_command                   check_snmp_cpu_load!keypublic!.1.3.6.1.4.1.9.2.1.57.0!80!90
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Last 5 Minutes CPU Load
 check_command                   check_snmp_cpu_load!keypublic!.1.3.6.1.4.1.9.2.1.58.0!80!90
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Used Memory
 check_command                   check_snmp_used_memory!keypublic!1.3.6.1.4.1.9.9.48.1.1.1.5.1!100000000!120000000
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Status Interface WAN
 check_command                   check_snmp_if_status!keypublic!.1.3.6.1.2.1.2.2.1.8.1!1
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Status Interface LAN
 check_command                   check_snmp_if_status!keypublic!.1.3.6.1.2.1.2.2.1.8.2!1
 }

A questo punto sarà sufficiente ricaricare la configurazione di Nagios mediante il comando:

[root@linuxbox ~]# service nagios reload

ed abbiamo finito.

Alla prossima.

Reboot script per i router Draytek Vigor

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

vigor3300.jpg

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.

Idle timeout sulle sessioni SSH con i router di Alice Telecom

Il mio lavoro consiste principalmente nella gestione di server *nix. Potrebbe accadere che, mentre sono a casa, debba connettermi ad uno dei suddetti server perchè qualcosa non funziona (o funziona male).

Quindi, oltre a sbattermi per cercare di risolvere il problema, devo anche imprecare contro il router Pirelli di Alice Telecom, che come tutti ben sanno ha il firmware bloccato e droppa le sessioni SSH (ma credo anche altri tipi di connessione) dopo un certo idle.

alice-router.jpg

Esistono comunque diversi workaround, tra i quali:

1) rimuovere il firmware di casa Telecom ed abilitare quello nativo di casa Pirelli (su Internet esiste una documentazione ben dettagliata che descrive questa procedura);

oppure:

2) cambiare le impostazioni del demone sshd, imponendo l’invio di keepalive ai client che si connettono.

La seconda opzione, ovviamente, è praticabile solo dagli utenti che hanno accesso alle impostazioni del suddetto demone.

Per abilitare i keepalive occorre semplicemente aggiungere le seguenti direttive al file di configurazione sshd_config che trovate nella dir /etc/ssh:

ClientAliveInterval 45
ClientAliveCountMax 1000

Riavviate il suddetto demone con un:

[root@bqweb1 ssh]# service sshd restart

E finalmente avete “risolto” il problema degli idle timeout su SSH.

Alla prossima.

Script per il backup automatico della configurazione di un router Cisco SOHO 77

Premessa

Un sistemista di rete previdente sa che è di vitale importanza poter contare su di un backup valido delle configurazioni relative ai vari network device. Proprio per questo motivo ho deciso di creare uno scrip che permettesse di automatizzare tale procedura.

soho.JPG

 

Configurare un server TFTP

Occorre precisare che il backup della configurazione del nostro router Cisco SOHO 77 verrà archiviato su di un server TFTP basato su una distribuzione *buntu.

Ma veniamo al dunque. Per prima cosa installiamo il server TFTP digitando:

nightfly@nightbox:~$ sudo apt-get install tftp tftpd xinetd

A questo punto posizioniamoci sulla directory /etc/xinetd.d e creiamo il file tftp il cui contenuto dovrà essere:

service tftp
 {
 protocol        = udp
 port            = 69
 socket_type     = dgram
 wait            = yes
 user            = nobody
 server          = /usr/sbin/in.tftpd
 server_args     = /tftpboot
 disable         = no
 }

Come si può notare dalla direttiva server_args     = /tftpboot il nostro server salverà la configurazione del router nella directory /tftpboot. Inoltre, poichè tale dir non è presente sulla nostra macchina è necessario crearla digitando:

nightfly@nightbox:/$ mkdir tftpboot

posizioniamoci all’interno di /tftpboot e creiamo il file vuoto router.cfg che conterrà la configurazione del SOHO 77:

nightfly@nightbox:/tftpboot$ sudo touch router.cfg

A questo punto lavoriamo sui permessi della directory appena creata e del suo contenuto:

nightfly@nightbox:/$ sudo chmod 777 -R tftpboot

nightfly@nightbox:/$ sudo chown nobody tftpboot

Riavviamo xinetd digitando:

nightfly@nightbox:/$ sudo /etc/init.d/xinetd stop

nightfly@nightbox:/$ sudo /etc/init.d/xinetd start

Infine, verifichiamo che il nostro server TFTP sia in ascolto digitando:

nightfly@nightbox:/$ sudo nmap -sU localhost

se l’output sarà simile al seguente:

69/udp   open|filtered tftp

vuol dire che il server risulta effettivamente in ascolto.

Scrip per il backup automatico della configurazione relativa al SOHO 77

Prima di mostrarvi lo scrip, è necessario installare un tool indispensabile al suo funzionamento. Tale tool prende il nome di expect:

nightfly@nightbox:/$ sudo apt-get install expect

Creiamo ora il file backup_conf_soho77 il cui contenuto dovrà essere il seguente:

#!/usr/bin/expect

set password1 "<pass1>"
set password2 "<pass2>" #necessaria nel caso in cui la password per l'enable sia diversa da quella per l'accesso via telnet

spawn telnet <IP del router>
expect "Password:"
send "$password1r"
expect ">"
send "enar"
expect "Password:"
send "$password2r"
expect "#"
send "copy system:running-config tftp://<IP del server TFTP>/router.cfgr"
expect "?"
send "r"
expect "?"
send "r"
expect "#"
send "exitr"
expect eof

NB: prima della r all’interno delle virgolette ci vuole il backslash, in modo da inviare al router un ritorno a capo (nello scrip non appare in quanto viene automaticamente skippato da myblog per ragioni di sicurezza).

Rendiamo lo scrip eseguibile mediante il comando:

nightfly@nightbox:~$ sudo chmod +x backup_conf_soho77

e successivamente spostiamolo nella directory /usr/bin:

nightfly@nightbox:~$ sudo mv backup_conf_soho77 /usr/bin

Adesso non ci resta che “schedulare” l’esecuzione dello scrip. Per fare questo è sufficiente inserire una entry in /etc/crontab:

00 00   * * * root backup_conf_router

In particolare, ogni mezzanotte verrà eseguito il backup della configurazione mediante lo scrip descritto in precedenza.

Riavviamo cron per rendere effettive le nuove impostazioni:

nightfly@nightbox:~$ sudo /etc/init.d/cron restart

ed abbiamo finito.

A presto.

 

Strani log sul router Cisco 837

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?

crypto.jpg

 

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.

A presto.

Errore su Cisco SOHO 77: MALLOCFAIL

Recentemente, esaminando i log del mio SOHO 77 ho notato la presenza dei seguenti messaggi d’errore:

Mar 10 13:27:24 *** 714: 000185: Mar 10 13:27:25.256 UTC: %SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed from 0x801381A8, alignment 0
Mar 10 13:27:24 *** 715: Pool: Processor  Free: 233440  Cause: Memory fragmentation
Mar 10 13:27:24 *** 716: Alternate Pool: None  Free: 0  Cause: No Alternate pool
Mar 10 13:27:24 *** 717:
Mar 10 13:27:24 *** 718: -Process= "IP Input", ipl= 0, pid= 34
Mar 10 13:27:24 *** 719: -Traceback= 8013C184 8013E2A8 801381AC 8058F648 80584810 80585568 80248C24 80248F40 80248FF4 80249148 80162010 80165628
soho77-2.jpg

 

Trattandosi di MALLOCFAIL e di Memory Fragmentetion sono quasi sicuro che la poca RAM installata onboard si sia esaurita. Inoltre, poichè sul server ho attivo un demone p2p 24/7, sono altrattanto certo che la causa sia imputabile alla mole di traffico ed alle troppe NAT translations.

Accedo dunque al router, digito un conf t ed imposto dei nuovi timeout per il NAT:

SOHO77(config)# ip nat translation timeout 420
SOHO77(config)# ip nat translation tcp-timeout 120
SOHO77(config)# ip nat translation syn-timeout 120
SOHO77(config)# ip nat translation udp-timeout 120
SOHO77(config)# ip nat translation dns-timeout 120
SOHO77(config)# ip nat translation icmp-timeout 120

Lancio infine un copy run start per rendere permanenti le modifiche appena messe in atto:

SOHO77(config)# copy run start

Ora non resta che controllare che la memoria non stia sempre a tappo (mediante il comando sh memory) e che le translations attive non siano troppe (mediante uno sh ip translations statistics).

A presto.