Il blog sull'informatica

Recentemente su uno dei miei server ho lanciato il comando:

nightfly@nightbox:~$ sudo iptables -L

e con mio enorme disappunto mi sono accorto che le regole di firewalling che il server avrebbe dovuto caricare all'avvio erano praticamente assenti (eccezion fatta per fail2ban), indi per cui ho deciso di monitorare lo stato di iptables mediante Nagios.

Lo script che ho utilizzato per i check potete scaricarlo da qui. Inoltre, poichè tale script è piuttosto bacato, ho deciso di apportare qualche piccola correzione. Di seguito la versione originale dello script:

PARAM1=$1
TABLE=$2
MINRULES=$3
PARAM4=$4
LOG=/var/log/iptables/iptables.log
CHKIPTBLS=`/sbin/iptables -n -t filter -L |wc -l`

#
# Parameter Validation
##

if [ "$PARAM1" != "-T" -o "$TABLE" == "" -o "$MINRULES" != "-r" -o "$PARAM4" == "" ]; then
        echo "Usage: $0 -T <table> -r <min rules>"
        echo ""
        exit 3
                # Nagios exit code 3 = status UNKNOWN = orange


if [ "$PARAM1" == "-h" ]; then
        echo ""
        echo "         -h = Display's this Help"
        echo "         -T = Table to check"
        echo "                 Available Tables:"
        echo "                    nat"
        echo "                    mangle"
        echo "                    filter"       
        echo "         -r = Minimun quantity of rules"
        echo ""
        # Nagios exit code 3 = status UNKNOWN = orange
                exit 3
   fi
fi

##
#    DO NOT MODIFY ANYTHING BELOW THIS
##

$CHKIPTBLS >/dev/null 2>/dev/null

if [ "$CHKIPTBLS" == 0 ]; then
    TOTRULES=$CHKIPTBLS
else
    TOTRULES=$[$CHKIPTBLS-8]
fi


if [ "$TOTRULES" -gt "$PARAM4" ]; then
                    echo "OK - Iptables are OK the table $TABLE has $TOTRULES rules configured"
                    # Nagios exit code 0 = status OK = green
                    exit 0
else
                    echo " CRITICAL - Iptables are CRITICAL the table $TABLE has $TOTRULES rules configured"
                    for i in `w  -h | cut -f1 -d" " | sort | uniq`
                    do
                           
                        echo "`date '+%d/%m/%Y - %H:%M:%S'` - CRITICAL - $i is logged in and there are only $TOTRULES loaded" >> $LOG
                    done
                    # Nagios exit code 2 = status CRITICAL = red
                    exit 2               
fi

Punto primo: la seconda condizione dell'if non ha praticamente senso, in quanto la prima è sempre verificata.
E' bastato invertire le due condizioni e trattarle separatamente:

#
# Parameter Validation
##

if [ "$PARAM1" == "-h" ]; then
        echo ""
        echo "          -h = Display's this Help"
        echo "          -T = Table to check"
        echo "          Available Tables:"
        echo "          nat"
        echo "          mangle"
        echo "          filter"
        echo "          -r = Minimun quantity of rules"
        echo ""
        # Nagios exit code 3 = status UNKNOWN = orange
        exit 3
fi

if [ "$PARAM1" != "-T" -o "$TABLE" == "" -o "$MINRULES" != "-r" -o "$PARAM4" ==                                                                                         "" ]; then
        echo "Usage: $0 -T <table> -r <min rules>"
        echo ""
        exit 3
        # Nagios exit code 3 = status UNKNOWN = orange
fi

Punto secondo: la variabile CHKIPTBLS utilizza sempre e comunque la tabella filter, dunque il parametro -T non ha senso di esistere. Possiamo però ovviare a tale mancanza, permettendo all'utente di scegliere su quale tabella (tra filter, mangle e nat) effettuare i controlli, modificando la variabile citata in precedenza nel seguente modo:

CHKIPTBLS=`sudo /sbin/iptables -n -t "$TABLE" -L |wc -l`

Punto terzo: la condizione

if [ "$TOTRULES" -gt "$PARAM4" ]; then

controlla che il numero di regole caricate sia strettamente maggiore di quello definito mediante il parametro -r. Questo però cozza con quanto dichiarato dall'autore dello script, ovvero:

OK - The number of Iprules equal o more than the minimun that we setup on the -r variable

Per ovviare a tale errore, occorre sostituire la condizione riportata in precedenza con questa:

if [ "$TOTRULES" -ge "$PARAM4" ]; then

Punto quarto: nagios non ha i permessi per lanciare iptables, ergo dobbiamo effettuare delle modifiche al file /etc/sudoers, inserendo la entry:

nagios   ALL = NOPASSWD: /sbin/iptables

alla fine del file. 

In definitiva, lo script per controllare lo stato di iptables dovrà essere il seguente:

PARAM1=$1
TABLE=$2
MINRULES=$3
PARAM4=$4
LOG=/var/log/check_iptables.log
CHKIPTBLS=`sudo /sbin/iptables -n -t "$TABLE" -L |wc -l`

#
# Parameter Validation
##

if [ "$PARAM1" == "-h" ]; then
        echo ""
        echo "          -h = Display's this Help"
        echo "          -T = Table to check"
        echo "          Available Tables:"
        echo "          nat"
        echo "          mangle"
        echo "          filter"
        echo "          -r = Minimun quantity of rules"
        echo ""
        # Nagios exit code 3 = status UNKNOWN = orange
        exit 3
fi

if [ "$PARAM1" != "-T" -o "$TABLE" == "" -o "$MINRULES" != "-r" -o "$PARAM4" == "" ]; then
        echo "Usage: $0 -T <table> -r <min rules>"
        echo ""
        exit 3
        # Nagios exit code 3 = status UNKNOWN = orange
fi

##
#       DO NOT MODIFY ANYTHING BELOW THIS
##

$CHKIPTBLS >/dev/null 2>/dev/null

if [ "$CHKIPTBLS" == 0 ]; then
        TOTRULES=$CHKIPTBLS
else
        TOTRULES=$[$CHKIPTBLS-8]
fi


if [ "$TOTRULES" -ge "$PARAM4" ]; then
                    echo "OK - Iptables is OK The Table $TABLE has $TOTRULES rules configured"
                    # Nagios exit code 0 = status OK = green
                    exit 0
else
                    echo " CRITICAL - Iptables is CRITICAL The Table $TABLE has $TOTRULES rules configured"
                                        for i in `w  -h | cut -f1 -d" " | sort | uniq`
                                        do
                                                echo "`date '+%d/%m/%Y - %H:%M:%S'` - CRITICAL - $i is logged in and there are only $TOTRULES loaded" >> $LOG
                                        done
                    # Nagios exit code 2 = status CRITICAL = red
                    exit 2
fi

Se il file /var/log/check_iptables.log non esiste, dovrete crearlo mediante il comando:

nightfly@nightbox:~$ sudo touch /var/log/check_iptables.log

A questo punto possiamo rinominare lo script:

nightfly@nightbox:~$ mv check_iptables_status.sh check_iptables_status

rendondolo successivamente eseguibile:

nightfly@nightbox:~$ chmod +x check_iptables_status

Spostiamolo nella directory /usr/lib/nagios/plugins:

nightfly@nightbox:~$ sudo mv check_iptables_status /usr/lib/nagios/plugins

Creiamo il file iptables.cfg nella directory /etc/nagios-plugins/config:

nightfly@nightbox:/etc/nagios-plugins/config$ sudo nano iptables.cfg

il cui contenuto dovrà essere il seguente:

# 'check_iptables_status' command definition
define command{
        command_name    check_iptables_status
        command_line    /usr/lib/nagios/plugins/check_iptables_status -T '$ARG1$' -r '$ARG2$'
        }

infine aggiungiamo la seguente direttiva al file dell'host su cui vogliamo monitorare lo stato di iptables (tale file è presente nella directory /etc/nagios3/conf.d):

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       localhost
        service_description             iptables
                check_command                   check_iptables_status!filter!84
}

Dove 84 è il numero minimo di regole di firewalling attive.

Infine, riavviamo nagios:

nightfly@nightbox:~$ sudo service nagios3 restart

ed abbiamo finito.

Alla prossima.

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 script che permettesse di automatizzare tale procedura.

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/xined.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.

Script per il backup automatico della configurazione relativa al SOHO 77

Prima di mostrarvi lo script, è 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 script non appare in quanto viene automaticamente skippato da myblog per ragioni di sicurezza).

Rendiamo lo script 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 script. 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 script descritto in precedenza.

Riavviamo cron per rendere effettive le nuove impostazioni:

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

ed abbiamo finito.

A presto.

Non finirò mai di ribadire quanto sia importante "registrare" tutto ciò che accade sul nostro router, in modo da avere il pieno controllo su di esso. Tra i log "di vitale importanza" rientrano sicuramente quelli relativi ai comandi lanciati da shell: tale mini-guida ha come scopo principale proprio quello di illustrare la procedura per abilitare e configurare i log citati in precedenza.

Per prima cosa entriamo in modalità enable e successivamente accediamo alla modalità di configurazione del nostro router:

router>ena
router#conf t

Adesso posizioniamoci nell'archivio, ovvero dove verranno salvati i log che ci interessano:

router(config)#archive

Abilitiamo quindi il logging vero e proprio:

router(config-archive)#log config
router(config-archive-log-cfg)#logging enable

e successivamente configuriamolo, imponendogli di spedire i log al nostro logserver, avendo cura però di nascondere le eventuali password che verranno digitate in futuro (hidekyes):

router(config-archive-log-cfg)#notify syslog
router(config-archive-log-cfg)#hidekeys
router(config-archive-log-cfg)#exit
router(config-archive)#exit

Impostiamo il livello dei log da inviare al logserver (in questo caso settandolo su informational):

router(config)#logging trap informational

ed infine salviamo la configurazione:

router(config)#exit
router#copy run start

Da ora in poi il nostro logserver terrà traccia dei comandi lanciati dalla shell del router.

Bye.

PS: se non sapete come abilitare l'invio dei log su un server apposito, potete utilizzare questo post come riferimento.

PPS: il logging level da impostare sul server per poter ricevere i log dei comandi è pari 5 (o superiore).

Una rete che si possa definire "sicura" deve necessariamente utilizzare un IDS per identificare i tentativi di intrusione. Inoltre, è indispensabile che venga controllato il corretto funzionamento dell'IDS, in modo da evitare tempi morti durante i quali il network risulti "sguarnito". A tal proposito ho deciso di monitorare il mio IDS (per la precisione snort), attraverso l'uso di nagios (nella fattispecie la versione 3.0).

Ma andiamo con ordine. Per prima cosa scarichiamo l'add-on di nagios denominata check_snort (non è altro che un semplice script bash). Potete trovarlo a questo indirizzo.

Successivamente scompattiamo la tarball mediante il comando:

nightfly@nightbox:~$ tar -xf check_snort.tar

e copiamo il file check_snort dentro la directory /usr/lib/nagios/plugins:

nightfly@nightbox:~$ cp check_snort /usr/lib/nagios/plugins/

Creiamo quindi un servizio specifico che si occupi di controllare lo stato di snort:

nightfly@nightbox:~$ cd /etc/nagios-plugins/config
nightfly@nightbox:/etc/nagios-plugins/config$ sudo nano snort.cfg

inserendo all'interno del file appena creato il seguente contenuto:

# 'check_snort' command definition
define command{
        command_name    check_snort
        command_line    /usr/lib/nagios/plugins/check_snort

}

A questo punto possiamo aggiungere il seguente servizio alla configurazione dell'host su cui vogliamo attivarlo:

nightfly@nightbox:~$ cd /etc/nagios3/conf.d
nightfly@nightbox:/etc/nagios3/conf.d$ sudo nano localhost_nagios2.cfg

e digitiamo:

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       localhost
        service_description             Snort
                check_command                   check_snort
}

salviamo il tutto, riavviamo nagios:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo service nagios3 restart

ed abbiamo finito.

Adesso anche snort è sotto il controllo di nagios.

A presto.

Da un po' di tempo a questa parte mi capita di non ricevere le notifiche via mail da qualcuno dei miei server. Purtroppo ciò accade saltuariamente ed in modo pseudorandom, quindi per mettere bene a fuoco la problematica ho dovuto effettuare un'attenta analisi degli eventi.

Ma andiamo con ordine. Ieri, dopo aver aperto il mio client di posta elettronica, mi sono accorto che mancavano TUTTE le email di notifica del mio server casalingo (qualche giorno prima mi era successo la stessa cosa con il server di un amico commercialista). Accedo quindi alla shell via SSH e lancio il comando:

nightfly@nightbox:~$ cat /var/log/exim4/mainlog | grep mioindirizzoemail

Una delle entry riportava le seguenti informazioni:

** *@nightbox.it R=hub_user_smarthost T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL FROM:<> SIZE=2430: host rm.virgilio.it [62.211.72.20]: 550 mail not accepted from blacklisted IP address [188.11.59.93]

Uhm, il mio IP pubblico, ovvero 188.11.59.93 è stato blacklistato dall'SMTP di virgilio... ma per quale motivo?

Mi collego dunque al sito www.senderbase.org e digito il mio indirizzo IP pubblico. Come risultato mi becco una bella schermata in cui c'è scritto che l'IP da me digitato è classificato come poor ed è stato inserito nella pbl di spamhaus.org. Bene, ma cosa diavolo è questa pbl? Cito testualmente:

The Spamhaus PBL is a DNSBL database of end-user IP address ranges which should not be delivering unauthenticated SMTP email to any Internet mail server except those provided for specifically by an ISP for that customer's use. The PBL helps networks enforce their Acceptable Use Policy for dynamic and non-MTA customer IP ranges.

Ok, quindi il problema è dovuto al fatto che ho inviato le email al mio MTA (out.virgilio.it) senza essermi prima autenticato. Inoltre, il controllo viene effettuato solo sugli IP pubblici che iniziano con 188.*, ovvero gli ultimi (in ordine di tempo) messi a disposizione per gli utenti di Aliceadsl.

Ne è la riprova il fatto che gli altri server che utilizzano un IP pubblico diverso da 188.* non vengono blacklistati, nonostante continuino a non usare l'autentica per connettersi all'SMTP di virgilio.

Per completezza, queste sono le blacklist su cui si basa l'SMTP citato in precedenza:

http://www.spamhaus.org
http://ipremoval.sms.symantec.com
http://cbl.abuseat.org
http://psbl.surriel.com

Ma come fare per risolvere il problema? Semplice, basta fare in modo che venga utilizzata l'autentica in fase di invio dei messaggi email (soluzione definitiva), oppure cambiare indirizzo IP pubblico, sperando che non ce ne venga assegnato nuovamente uno del blocco 188.* (soluzione temporanea).

A presto.

Aggiornamento

A quanto pare il controllo sull'autenticazione SMTP è stato esteso anche ad altri netblock, ad esempio il 79.*. Dunque vi consiglio di settare l'autentica per lo smarthost (se utilizzate exim4 come mail server locale, potete trovare informazioni utili in questo post).

La IOS C837-K9O3Y6-M sviluppata per il router Cisco 837 ha un bug, ovvero è possibile che dopo qualche reload si "dimentichi" di una o più PAT translations che riguardano porte più alte delle well-known (per intenderci, superiori alla 1023).

Nel mio caso, il problema ha iniziato a verificarsi da quando ho deciso di mettere in ascolto SSH su una porta non standard, in modo da risparmiarmi i tentativi di attacco lanciati dagli script kiddie di turno.

Inoltre, per motivi di sicurezza, ho consentito l'accesso via SSH al router solo dagli host della LAN, quindi, nel caso in cui dovessi accedere alla sua configurazione, atterro sul server e da lì mi collego al router.

Ovviamente, se la porta SSH non è forwardata non posso atterrare sul server, dunque l'unica soluzione praticabile consiste nell'andare fisicamente dal cliente e ricreare la regola per il PAT.

E qui viene il bello: poichè mi sono stancato di dover perdere almeno un'ora per andare dal cliente, riconfigurare il tutto e tornarmene a casa, ho deciso di creare il seguente script, il quale si collega al router tre volte al giorno e ricrea la regola per l'SSH.

Ecco lo script:

#!/usr/bin/expect

set password1 "<password1>"
set password2 "<password2>"

spawn ssh -l <username> <IP del router>
expect "*?assword:*"
send "$password1r"
expect ">"
send "enar"
expect "Password:"
send "$password2r"
expect "#"
send "conf tr"
expect "(config)#"
send "no ip nat inside source static tcp <ip> <porta> interface Dialer0 <porta>r"
expect "(config)#"
send "ip nat inside source static tcp <ip> <porta> interface Dialer0 <porta>r"
expect "(config)#"
send "exitr"
expect "#"
send "copy run startr"
expect "?"
send "r"
expect "#"
send "exitr"
expect eof

Come al solito, mancano i backslash prima della r perchè myblog li filtra.

Una volta che avete creato lo script, convertitelo in eseguibile lanciando il comando:

nightfly@nightbox:~$ sudo chmod +x ssh_autoforward

e salvatelo nella directory /usr/bin:

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

A questo punto potete creare la regola per cron, in modo da schedulare l'esecuzione dello script alle 6, alle 12 ed alle 18:

nightfly@nightbox:~$ sudo nano /etc/crontab

00 06,12,18   * * *     root          ssh_autoforward

Riavviamo cron:

nightfly@nightbox:~$ sudo service cron restart

ed abbiamo finito.

A presto.

PS: non preoccupatevi se lo script entra in esecuzione mentre siete loggati sul server: la regola per il forward dell'SSH non verrà rimossa poichè la state già utilizzando, quindi niente perdita di connessione.

Per tutti coloro che fossero alle prese con l'upgrade di una qualche IOS e non sapessero come funziona la complicatissima nomenclatura utilizzata da Cisco, ecco un documento riassuntivo che vi tornerà sicuramente utile.

A presto.

Finalmente, dopo tanto tribolare, il mio Cisco 827 ha iniziato a fare il suo sporco lavoro. Per rendere il tutto un po' più stabile e robusto, ho aggiunto un banco di RAM da 32 MB (in modo da non soffocarlo con le NAT translations) ed ho aggiornato la IOS, passando dalla c827v-y6-mz.121-1.XB (una EARLY DEPLOYMENT che non conosce nemmeno il significato di PPPoE) alla c820-k9osy6-mz.123-5.

Ecco lo sh ver:

NightRouter#sh ver
Cisco Internetwork Operating System Software
IOS (tm) C820 Software (C820-K9OSY6-M), Version 12.3(5), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2003 by cisco Systems, Inc.
Compiled Tue 28-Oct-03 10:31 by kellythw
Image text-base: 0x80013148, data-base: 0x80A9890C

ROM: System Bootstrap, Version 12.1(1r)XB1, RELEASE SOFTWARE (fc1)

NightRouter uptime is 20 minutes
System returned to ROM by power-on
System restarted at 18:03:31 UTC Thu Nov 3 2011
System image file is "flash:c820-k9osy6-mz.123-5.bin"


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

CISCO C827 (MPC855T) processor (revision 0x501) with 31744K/1024K bytes of memory.
Processor board ID JAD04330G9Y (2953292797), with hardware revision 0000
CPU rev number 5
Bridging software.
1 Ethernet/IEEE 802.3 interface(s)
1 ATM network interface(s)
128K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read/Write)
2048K bytes of processor board Web flash (Read/Write)

Configuration register is 0x2102

Adesso il mio SOHO77 può andare meritatamente in pensione.

A presto.

Premessa

Per effettuare l'upgrade del nostro router da SOHO 77 a 827 è necessario che esso soddisfi i requisiti hw richiesti dalla IOS che abbiamo intenzione di installare.

Se ad esempio la IOS implementa diverse feature, come un firewall, la possibilità di gestire il traffico VOIP o di realizzare VPN PPTP, i requisiti in termini di RAM potrebbero superare di gran lunga quelli in dotazione al nostro router. Un ostacolo ancora maggiore potrebbe essere rappresentato dalle dimensioni della memoria flash (solitamente 8 MB), dunque è impossibile installarci sopra una IOS che abbia dimensioni superiori agli 8 MB.

Esistono, ovviamente, dei moduli di espansione per la flash (piuttosto costosi), mentre per la RAM potete utilizzare un banco di SDRAM a 100pin PC100 dalla capacità di 32 MB (per intenderci, quella installata sulle stampanti). Per la precisione anche un banco di RAM a 64 MB va bene, sappiate però che il router riuscirà a leggere (e quindi ad utilizzare) solo 48 MB dei 64 disponibili.

Upgrade della piattaforma

Ma vediamo come far digerire al nostro SOHO 77 una IOS sviluppata per l'827.

Spegniamo il router e riaccendiamolo. Una volta avviata la fase di boot teniamo premuto CTRL+PAUSA, in modo di accedere al rom monitor.

Successivamente, il prompt ci apparirà nel modo seguente:

rommon 1 >

Per avere una lista dei comandi disponibili è sufficiente digitare ?:

rommon 1 > ?
alias               set and display aliases command
boot                boot up an external process
break               set/show/clear the breakpoint
confreg             configuration register utility
cont                continue executing a downloaded image
context             display the context of a loaded image
cookie              display contents of cookie PROM in hex
dev                 list the device table
dir                 list files in file system
dis                 display instruction stream
dnld                serial download a program module
frame               print out a selected stack frame
help                monitor builtin command help
history             monitor command history
meminfo             main memory information
repeat              repeat a monitor command
reset               system reset
set                 display the monitor variables
stack               produce a stack trace
sync                write monitor environment to NVRAM
sysret              print out info from last system return
tftpdnld            tftp image download
unalias             unset an alias
unset               unset a monitor variable
xmodem              x/ymodem image download
rommon 2 >

Ora, per fare l'upgrade del router occorre visualizzare il cookie che identifica la piattaforma. Per fare ciò basta digitare il comando cookie:

rommon 2 > cookie

cookie:
01 01 00 01 96 71 b4 61 5b 00 01 00 01 ff 00 00
00 00 00 00 00 00 00 00 4a 41 44 04 33 30 47 39
59 05 01 00 00 00 00 00 00 ff ff ff 60 04 49 11
ec 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

A noi interessa modificare ESCLUSIVAMENTE il nono byte, portandolo da 5b a 3e. Tutti gli altri byte possono rimanere inalterati.

Per modificare il cookie occorre entrare in modalità privilegiata. E' dunque necessario digitare il comando priv con relativa password, dove la password può essere calcolata mediante questo tool, dandogli in pasto solo la prima riga del cookie sopra riportato.

Una volta ottenuta la password utilizziamola per accedere alla modalità privilegiata. Riceveremo in output il seguente messaggio:

You now have access to the full set of monitor commands.
Warning: some commands will allow you to destroy your
configuration and/or system images and could render
the machine unbootable.
rommon 4 >

Digitiamo nuovamente il comando cookie per procedere con la modifica di quest'ultimo:

rommon 4 > cookie

View/alter bytes of serial cookie by field --
Input hex byte(s) or: CR -> skip field; ? -> list values
byte  0x00       - version: 01
                          >

Per lasciare inalterati i valori di default ci basterà premere INVIO. Per la precisione dobbiamo modificare solo il nono byte, il cui valore dovrà essere 3e.

Una volta terminata la modifica del cookie, possiamo installare la IOS dell'827 mediante il comando tftpdnld. Prima di utilizzarlo, però, si dovranno settare alcune variabili di sistema che tale comando utilizzerà, ovvero:

IP_ADDRESS

IP_SUBNET_MASK

DEFAULT_GATEWAY

TFTP_SERVER

TFTP_FILE

Ad esempio:

IP_ADDRESS=192.168.1.2

IP_SUBNET_MASK=255.255.255.0

DEFAULT_GATEWAY=192.168.1.1

TFTP_SERVER=192.168.1.1

TFTP_FILE=c827v-y6-mz.121-1.XB.bin

Controlliamo che le variabili siano state impostate correttamente digitando semplicemente set.

Adesso procediamo con il download dell'IOS mediante tftpdnld (come applicativo che funga da server TFTP vi consiglio di utilizzare tftp32):

rommon 10 > tftpdnld

          IP_ADDRESS: 192.168.1.2
      IP_SUBNET_MASK: 255.255.255.0
     DEFAULT_GATEWAY: 192.168.1.1
         TFTP_SERVER: 192.168.1.1
           TFTP_FILE: c827v-y6-mz.121-1.XB.bin

Invoke this command for disaster recovery only.
WARNING: all existing data in all partitions on flash will be lost!
Do you wish to continue? y/n:  [n]:

Digitiamo y e proseguiamo con l'installazione:

Receiving c827v-y6-mz.121-1.XB.bin from 192.168.1.1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
File reception completed.
Copying file c827v-y6-mz.121-1.XB.bin to flash.

Erasing flash ................................................................
Programming flash ..............................

Digitiamo reset per riavviare il router e finalmente il nostro 827 è (o dovrebbe) essere pronto per l'uso.

A presto.

Dopo una breve (ma necessaria) pausa ho deciso di riprendere la pubblicazione sul blog, trattando argomenti di grande interesse che durante questo lasso di tempo ho potuto approfondire.

Uno di questi riguarda la configurazione di un router Cisco SOHO, nella fattispecie il 77, per il PPPoE (Point-to-Point Protocol over Ethernet). Infatti, da qualche mese, Telecom sta convertendo le proprie linee da ATM a FullIP, costringendo gli utenti ad utilizzare la configurazione PPPoE, l'unica compatibile con il FullIP.

Ma quali sono i vantaggi di una rete FullIP? Beh, uno su tutti è sicuramente la possibilità di ridurre l'overhead, facendo aumentare di conseguenza la banda disponibile all'utente.

Dopo questa breve introduzione passiamo alla configurazione vera a propria.

La prima cosa da fare è munirci di un cavo console (quello che esce in dotazione con il dispositivo - Vedi foto) e collegarlo alla porta com del nostro pc ed alla porta console (di colore blu) del router. A collegamento avvenuto apriamo hyperterminal (Start -> Programmi -> Accessori -> Comunicazioni -> Hyper Terminal) associamo un nome alla connessione (nella finestra di popup che appare dopo l'avvio del programma) e premiamo su "OK". Adesso selezioniamo la porta com del pc alla quale è collegato il cavo (nel mio caso COM1) clickiamo nuovamente su "OK" ed entreremo all'interno del menu di configurazione della porta precedentemente selezionata.

Scegliamo i seguenti parametri:

1) Bit per secondo: 9600

2) Bit di dati: 8

3) Parità: nessuno

4) Bit di stop: 1

5) Controllo del flusso: Hardware

Bene adesso selezioniamo "OK" e ci apparirà una schermata bianca (non vi preoccupate è perfettamente normale). Accendiamo quindi il router (dal pulsante opportuno presente nel retro del dispositivo) e vedremo apparire come per magia l'output relativo alla sequenza di bootstrap. Terminata tale operazione ci apparira il propt:

Router>

Entriamo in modalità enable che ci permette di accedere ai comandi di configurazione del router semplicemente digitando ena (oppure enable, è indifferente):

Router > ena

Adesso il prompt ci apparirà così:

Router#

Entriamo nel menù di configurazione vero e proprio digitando conf t (oppure configure terminal):

Router# conf t

Il prompt ci apparirà nel modo seguente:

Router(config)#

Impostiamo il nome del router utilizzando il comando hostname. Ad esempio:

Router(config)# hostname NightRouter

Il prompt cambierà nuovamente:

NightRouter(config)#

Definiamo password sia per la connessione via console sia per l'accesso tramite telnet, scrivendo rispettivamente:

NightRouter(config)# line console 0

NightRouter(config-line)# password <vostrapass>

NightRouter(config-line)# login

mentre per telnet:

NightRouter(config-line)# line vty 0 4

NightRouter(config-line)# password <vostrapass>

NightRouter(config-line)# login

Bene, adesso configuriamo la password per entrare in modalità enable:

NightRouter(config)# enable password <vostrapass>

NightRouter(config)# enable secret <vostrapass>

NightRouter(config)# service password-encryption

NightRouter(config)# exit

NightRouter#

Il comando service password-encryption serve a calcolare il digest md5 di tutte le password presenti all'interno del file di configurazione, in modo tale che un semplice show run non le mostri in chiaro.

Fatto ciò possiamo dedicarci alla configurazione delle varie interfacce. Cominciamo dall'interfaccia Ethernet:

NightRouter(config)# interface eth0

Associamo indirizzo ip e subnet mask alla stessa:

NightRouter(config-if)# ip address 192.168.1.0 255.255.255.0

"Accendiamo" l'interfaccia:

NightRouter(config-if)# no shutdown

Identifichiamo l'interfaccia interna per il NAT:

NightRouter(config-if)# ip nat inside

Usciamo dalla modalità di configurazione della porta Ethernet

NightRouter(config-if)# exit

NightRouter(config)#

Configuriamo ora l'interfaccia ATM:

NightRouter(config)# interface ATM0

NightRouter(config-if)# pvc 8/35

Dopo aver digitato questo comando, il prompt ci apparirà nel modo seguente:

NightRouter(config-atm-vc)#

Settiamo il protocollo PPPoE:

NightRouter(config-atm-vc)# pppoe-client dial-pool-number 1

Configuriamo il Dialer:

NightRouter(config)# int Dialer0

Poichè spesso si utilizza ip pubblico dinamico assegnato direttamente dall'ISP occorre digitare:

NightRouter(config-if)# ip address negotiated

NB: Se si utilizza ip pubblico statico bisogna associarlo all'interfaccia attraverso il comando ip adcdress <indirizzo> <subnet mask>

Identifichiamo l'interfaccia esterna per il NAT:

NightRouter(config-if)# ip nat outside

Definiamo il protocollo di incapsulamento:

NightRouter(config-if)# encapsulation ppp

Specifichiamo quale dialer pool utilizzare:

NightRouter(config-if)# dialer pool 1

Definiamo adesso i parametri (userid e pass) per collegarsi all'ISP:

NightRouter(config-if)# ppp chap hostname <vostrauserid>

NightRouter(config-if)# ppp chap password <vostrapassword>

Se il vostro provider utilizza il PAP anzichè il CHAP occorre digitare:

NightRouter(config-if)# ppp pap sent-username <vostrauserid> password <vostrapassword>

Ora, poichè si sta utilizzando il protocollo PPPoE, occorre definire la dimensione dell'MTU, che nella fattispecie è pari a 1492 byte (mentre per l'ATM è di 1500 byte).

NightRouter(config-if)# ip mtu 1492

NightRouter(config-if)# exit

NightRouter(config)#

Non abbiamo ancora finito. Poichè il PPPoE supporta una dimensione massima dei segmenti TCP pari a 1452, occorre settare il seguente paramentro nell'ambito dell'interfaccia ethernet0 (altrimenti la navigazione sul Web ne risentirà parecchio):

NightRouter(config)# interface eth0

NightRouter(config-if)# ip tcp adjust-mss 1452

NightRouter(config-if)# exit

NightRouter(config)#

Adesso possiamo configurare i DNS che il router utilizzerà per la risoluzione degli indirizzi:

NightRouter(config)# ip domain-lookup

NightRouter(config)# ip name-server 151.99.125.2

NightRouter(config)# ip name-server 151.99.125.3

Configuriamo il NAT:

NightRouter(config)# ip nat inside source list 1 interface dialer 0 overload

Definiamo una default route:

NightRouter(config)# ip route 0.0.0.0 0.0.0.0 dialer0

Definiamo la policy per l'access list 1:

NightRouter(config)# access-list 1 permit 192.168.1.0 0.0.0.255

NB: tale access list permette a tutti gli host della net locale di uscire verso la rete esterna (Internet). Il paramentro 0.0.0.255 è detto wildcard mask ed effettua un check solo sugli ultimi 4 bit degli indirizzi ip locali.

Adesso non ci resta che bloccare l'accesso Telnet dall'esterno (ovvero da Internet) ed abilitare i log:

NightRouter(config)# line vty 0 4

NightRouter(config-line)# access-class 1 in

NightRouter(config-line)# exit

NightRouter(config)# service timestamps log datetime localtime show-timezone msec

NightRouter(config)# service timestamps debug datetime localtime show-timezone msec

NightRouter(config)# service sequence-numbers

NightRouter(config)# logging queue-limit 10000

NightRouter(config)# logging buffered 1000000 notifications

NightRouter(config)# logging console critical

NightRouter(config)# logging monitor debug

NightRouter(config)# logging history notifications

NightRouter(config)# logging buffered 150000

NightRouter(config)# logging count

NightRouter(config)# logging exception 100000

NB: per visualizzare i log basta lanciare il comando show log (dalla modalità enable).

Ah, quasi dimenticavo, per motivi di sicurezza conviene disabilitare il server HTTP interno:

NightRouter(config)# no ip http

Adesso salviamo quanto fatto fino ad ora digitando:

NightRouter# copy run start

Ecco completata la configurazione del nostro Router. A presto :)

PS: Per utilizzare alcuni programmi, quali ad esempio client p2p, è necessario impostare correttamente il port forwarding. Un esempio di rule è la seguente (porta tcp di aMule):

NightRouter(config)# ip nat inside source static tcp 192.168.1.4 4652 interface dialer0 4652

Dove 192.168.1.4 è l'host su cui è in esecuzione aMule, tcp il protocollo utilizzato e 4652 il numero della porta usata per la connessione al server p2p.