Archivi tag: backup

RANCID e CentOS: creare un sistema centralizzato di controllo e backup per le configurazioni dei dispositivi di rete

Avere a disposizione uno o più backup della configurazione dei dispositivi di rete è indispensabile, soprattutto nell’ottica di un eventuale disaster recovery. Inoltre, tenere traccia (mediante versioning) delle modifiche apportate alle suddette configurazioni ci può certamente aiutare a tracciare le operazioni svolte dai vari sistemisti di rete (oppure ad identificare eventuali modifiche “malevoli” effettuate dagli hacker/cracker di turno).

Il software (open source) che fa al caso nostro prende il nome di RANCID ed in questo post vedremo come installarlo e configurarlo su una macchina CentOS 6.5.

router_ciscoInstallazione

Prima di eseguire l’installazione vera e propria occorre fare una premessa: tale applicativo verrà installato mediante repository yum e non mediante compilazione dei sorgenti, in modo da risparmiarci tutta una trafila di configurazioni aggiuntive che introdurrebbero solo entropia alla nostra attività.

Per prima cosa, quindi, è necessario installare il repository EPEL da cui attingere per ottenere il suddetto software. Una volta fatto ciò possiamo passare all’installazione vera e prorpia dell’applicativo, digitando:

[root@linuxbox opt]# yum install rancid

Configurazione

Editiamo il file di configurazione /etc/rancid/rancid.conf, apportando le seguenti modifiche:

FILTER_PWDS=YES; export FILTER_PWDS
NOCOMMSTR=YES; export NOCOMMSTR
LIST_OF_GROUPS="main-office branch-office"
MAILHEADERS=""; export MAILHEADERS

Da notare che tali opzioni ci consentono, nell’ordine, di:

1) filtrare le password dalla configurazione backuppata. Ad esempio, per i dispositivi di casa Cisco, la secret è in formato digest MD5 mentre le altre password (se il comando service password-encryption è stato abilitato) sono in formato “digest” proprietario, che è assolutamente reversibile, quindi insicuro;

2) filtrare le community string utilizzate dal protocollo SNMP. Certo, nel caso in cui si stia utilizzando il suddetto protocollo nella versione 1 o 2 tale informazione può essere facilmente ricavata sniffando il traffico in oggetto, ma questa operazione è comunque più complicata (sia dal punto di vista logistico che da quello tecnico) rispetto alla lettura di un file di configurazione in cui le community string sono riportate in chiaro;

3) definire i gruppi di dispositivi da monitorare. Nel mio caso ho identificato solo 2 gruppi, ovvero branch-office (uffici periferici) e main-office (ufficio centrale). Entrambi utilizzano dei dispositivi di rete marchiati Cisco (router e switch);

4) non customizzare l’header delle email di notifica inviate da RANCID.

Controlliamo che sia presente il cron job in grado di lanciare la verifica delle configurazioni in modo automatico ad ogni ora:

[root@linuxbox opt]# cat /etc/cron.d/rancid

il cui contenuto dovrà essere:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/var/rancid
# Run config differ hourly
1 * * * * rancid /usr/libexec/rancid/rancid-run

Ora verifichiamo che sia presente il file di configurazione relativo a logrotate, il cui scopo è quello di ruotare ad intervalli regolari i file di log generati da RANCID:

[root@linuxbox rancid]# cat /etc/logrotate.d/rancid

il cui contenuto dovrà essere:

/var/log/rancid/* {
    weekly
    rotate 1
    notifempty
    missingok
    compress
    olddir old
}

Infine, verifichiamo che sia presente l’utente rancid (creato in automaticamente durante l’installazione dell’applicativo in questione):

[root@linuxbox rancid]# finger rancid
Login: rancid                           Name: RANCID
Directory: /var/rancid/                 Shell: /bin/bash
Never logged in.
No mail.
No Plan.

Se tutte le verifiche preliminari sono andate a buon fine possiamo dedicarci all’inizializzazione del repository CVS (versioning) di RANCID, lanciando i comandi:

[root@linuxbox opt]# su rancid
[rancid@linuxbox opt]$ /usr/bin/rancid-cvs

Posizioniamoci adesso nella home dell’utente e creiamo il file (nascosto) .cloginrc. Esso conterrà tutte le informazioni necessarie a RANCID per effettuare il login in modo automatizzato sui dispositivi di rete.

[rancid@linuxbox opt]$ cd --
[rancid@linuxbox opt]$ nano .cloginrc

Il cui contenuto dovrà avere il seguente formato:

add method <IP> <protocollo>
add user <IP> <username>
add password <IP> <password> <enable password>

ad esempio:

add method 192.168.1.1 ssh
add user 192.168.1.1 admin
add password 192.168.1.1 p4ssw0rd s3cr3t3n4bl3

Assegniamo i giusti permessi al file appena creato:

[rancid@linuxbox opt]$ chmod 700 .cloginrc

e lanciamo manualmente un login di prova, individuando dapprima dove si trova il binario clogin:

[rancid@linuxbox opt]$ locate clogin

il cui output potrebbe essere:

/usr/libexec/rancid/clogin

quindi digitiamo:

[rancid@linuxbox opt]$ /usr/libexec/rancid/clogin <IP>

Nel caso in cui volessimo testare contemporaneamente il login e l’invio di un comando specifico, possiamo utilizzare il comando:

[rancid@linuxbox opt]$ /usr/libexec/rancid/clogin -t <timeout> -c "comando1;comando2" <IP>

A questo punto occorre fare una precisazione: poichè alcuni tool messi a disposizione dal nostro applicativo fanno uso implicito di clogin, è necessario che il suo percorso venga esportato tra le variabili d’ambiente. Per fare ciò è necessario lanciare il comando:

[rancid@linuxbox opt]$ export PATH=$PATH:/usr/libexec/rancid

Adesso possiamo testare il funzionamento di RANCID per il singolo apparato, digitando:

[rancid@linuxbox opt]$ rancid -t <tipo> <IP>

dove <tipo> rappresenta, molto banalmente, il tipo di dispositivo di rete (marca e macromodello – per una panoramica dei dispositivi supportati potete consultare il file /etc/rancid/rancid.types.base).

Ora possiamo dedicarci all’editing dei gruppi. In particolare, tale attività consta di una sola operazione, ovvero l’inserimento all’interno del file router.db delle specifiche dei dispositivi di rete che intendiamo monitorare.

Però, prima di fare ciò, occorre indentificare la versione di RANCID installata, lanciando il comando:

[root@linuxbox ~]# rancid -V

Ciò è fondamentale poichè dalla versione 3.0 è stato introdotto il supporto all’IPv6, che, come sapete, utilizza abbondantemente i :. Proprio per questo motivo, il formato del contenuto del file router.db è diventato simile al seguente:

IP;marca;stato

anzichè:

IP:marca:stato

Premesso che la versione installata è la 3.1, il file router.db per il gruppo main-office avrà questo contenuto:

192.168.1.1;cisco;up
192.168.1.2;cisco;up

mentre per il gruppo branch-office avremo:

192.168.110.1;cisco;up
192.168.111.1;cisco;up
192.168.112.1;cisco;up
192.168.113.1;cisco;up
192.168.114.1;cisco;up
192.168.115.1;cisco;up

Testiamo RANCID sui gruppi:

[rancid@linuxbox rancid]$ rancid-run main-office
[rancid@linuxbox rancid]$ rancid-run branch-office

e definiamo gli indirizzi a cui dovranno essere inviate le email di allarme/notifica:

[root@linuxbox rancid]# nano /etc/aliases
rancid-main-office: vostro.indirizzo@email.it
rancid-admin-main-office: vostro.indirizzo@email.it
rancid-branch-office: vostro.indirizzo@email.it
rancid-admin-branch-office: vostro.indirizzo@email.it

In particolare, ciascun gruppo necessità di 2 indirizzi email: uno per il recapito delle informazioni “standard” e l’altro per le notifiche agli amministratori di rete.

Rendiamo effettive le modifiche apportate al file /etc/aliases:

[root@linuxbox rancid]# newaliases

e passiamo all’integrazione con tac_plus.

Integrazione tra RANCID e tac_plus

In questo post ho illustrato i vari step necessari per la creazione di un server AAA basato sul demone tac_plus (ed il protocollo made in Cisco TACACS+). Adesso faremo in modo che RANCID possa collegarsi ai vari dispositivi di rete contattando direttamente il server AAA. Nella fattispecie, è sufficiente editare il file /etc/tac_plus.conf aggiungendo le seguenti direttive:

user = rancid {

        login = des CjzxbdLRbG6sY

        service = exec {
                priv-lvl = 15
        }

        cmd = show { permit .* }
        cmd = exit { permit .* }
        cmd = dir { permit .* }
        cmd = more { permit .* }
        cmd = write { permit term }
}

dove la password (in formato DES + salt) è stata creata utilizzando l’applicativo tac_pwd. Da notare che all’utente rancid viene garantito il login in modalità enable (privilege 15 in gergo Cisco) e gli viene data la possibilità di lanciare 5 comandi (e relativi sub comandi), ovvero show, exit, dir, more e write.

Ricarichiamo la configurazione del demone tac_plus:

[root@linuxbox rancid]# service tac_plus reload

ed abbiamo finito.

Alla prossima.

Exchange ed i transaction log

Se lo spazio su disco della vostra macchina Exchange 2010 sta per esaurirsi, l’ultima cosa da fare è cancellare A MANO i transaction log. Infatti, in tal caso vi ritroverete con dei backup del DB di Exchange non funzionanti, ergo qualunque operazione di ripristino sarà un buco nell’acqua.

Altra cosa da non sottovalutare: per i backup di Exchange evitate di utilizzare dei tool “amatoriali” o per ambienti home (ad esempio Nova Backup), ma optate sempre per l’utility di backup/restore presente di default sulle macchine Windows Server 2008 R2.

E’ tutto, alla prossima.

 

Shrinking di un database Firebird

L’ABC dell’informatica ci ha insegnato che non esiste un solo tipo di file system. Infatti, oltre al file system utilizzato dal sistema operativo esiste anche il file system del DBMS, il network file system (ad esempio NFS e Microsoft DFS) e così via.

Bene, solitamente quando si cancellano N record da una o più tabelle del DB, il DBMS a cui l’istanza afferisce non rilascerà automaticamente al sistema operativo lo spazio appena liberato. Questo significa che il file che identifica il DB manterrà le propre dimensioni originarie, nonostante le operazioni di rimozione dei record.

Per quanto riguarda Firebird, l’unico modo per effettuare lo shrinking del database (ovvero la sua contrazione in termini di spazio occupato su disco) è eseguire il backup di quest’ultimo e successivamente ripristinarlo.

database, dbms, shrinking, disk space, restore, backup, gfix, gbak, garbage collection, firebird

Fortunatamente, Firebird ci mette a disposizione un valido strumento per tale scopo: gbak.

Per default tale applicativo effettuerà anche la garbage collection dei record duplicati (generati dai rollback delle transazioni), impiegando un certo lasso di tempo (in quanto trattasi di un’operazione abbastanza onerosa in termini computazionali). Per fare in modo che gbak non proceda con la garbage collection occorre usare la flag -G. Ad esempio:

server ~ # gbak -B nomedatabase.fdb nomedatabase.fbk
-v -y backup.log

eseguirà il backup del nostro DB, salvando le informazioni relative a tale operazione (-v -y) nel file backup.log, mentre:

server ~ # gbak -B -G nomedatabase.fdb nomedatabase.fbk
-v -y backup.log

eviterà di eseguire la garbage collection (che, solitamente, viene messa in atto automaticamente ad intervalli di tempo regolari, secondo quanto definito nel file di configurazione di Firebird).

Inoltre, è possibile effettuare la garbage collection in un secondo momento, utilizzando gfix:

server ~ # gfix -s nomedatabase.fdb

Una volta creato il file di backup (con estensione *.fbk), sarà necessario ripristinarlo. Il comando da utilizzare è il seguente:

server ~ # gbak -C nomedatabase.fbk nomedatabase.fdb
-v -y restore.log

Assegnamo i giusti permessi al file appena creato:

server ~ # chown firebird:firebird nomedatabase.fdb

riavviamo Firebird:

server ~ # /etc/init.d/firebird restart

ed abbiamo finito.

Alla prossima.

Backup di un sito Web mediante wget

Qualche giorno fa mi è capitato di dover effettuare il backup di un sito Web senza conoscere le credenziali FTP. Fortunatamente si trattava di un sito sprovvisto di codice lato server, quindi per me è stato piuttosto semplice salvarne una copia in locale.

wget,web,dump,backup,client web,server web,ftp

Per fare tale operazione ho utilizzato il mitico wget, ed in particolare il comando:

nightfly@nightbox:~$ wget -r www.siteexample.it

Tutto il contenuto del sito è stato automaticamente salvato nella directory www.siteexample.it.

Devo ammettere però che ho avuto un po’ di fortuna. Infatti, non tutti i server Web consentono liberamente il dump dei loro siti (il termine phishing vi dice qualcosa?). Proprio per impedire tale pratica, molto spesso viene implementato un meccanismo di protezione basato sul riconoscimento del client Web: nel caso in cui il server si accorgesse che è wget a richiedere le pagine del sito, risponderà picche.

Tale controllo risulta comunque facilmente aggirabile. Infatti wget consente lo spoofing del client, che può essere impostato manualmente digitando:

nightfly@nightbox:~$ wget -r -U "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" www.siteexample.it

Invece, nel caso in cui i controlli si basassero anche sui tempi che intercorrono tra la visualizzazione di una pagina e quella successiva, oppure sulla velocità di download delle stesse, basterà utilizzare correttamente le flag –wait e –limit-rate:

nightfly@nightbox:~$ wget --wait=30 --limit-rate=10K -r -U "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" www.siteexample.it

Ed il backup del sito è pronto.

A presto.

Script *.bat per il backup automatico via FTP della directory “Documenti”

Chi è del mestiere sa che i backup sono di fondamentale importanza, soprattutto quando riguardano dati piuttosto sensibili. Affidare tale operazione agli utenti (anche se si tratta di piccoli ambienti) è sconsigliabile. Ho dunque pensato di creare il seguente scrip (per reti SOHO) che “zippa” la directory Documenti e la invia, tramite FTP, ad un server interno.

batch

Ovviamente tale scrip può essere ulteriormente migliorato, se avete dei suggerimenti contattatemi.

Ecco il codice:

set mese=%DATE:~3,2%
set giorno=%DATE:~0,2%
set anno=%DATE:~-4%
set comfile="com.txt"

zip Documenti_PC1_%giorno%_%mese%_%anno% "C:UsersnomeutenteDocuments"
cd "C:Usersvostroutente"

echo username> %comfile%
echo password>> %comfile%
echo put Documenti_PC1_%giorno%_%mese%_%anno%.zip>> %comfile%
echo quit>> %comfile%

ftp -i -s:"com.txt" <indirizzo IP server>

Lo scrip, da posizionare nella directory di ciascun utente, scrive i dati per la connessione al server FTP ed i relativi comandi su un file, che ho chiamato com.txt. Tale informazioni vengono infine date in pasto al comando ftp, da utilizzarsi con le flag -i (per non visualizzare i prompt interattivi) e -s (che consente di specificare il file sorgente dei comandi). Ovviamente anche il file com.txt deve trovarsi all’interno della directory utente.

Per la precisione, il file com.txt ci apparirà nel modo seguente:

username
password
put Documenti_PC1_29_09_2011.zip
quit

Ora, la realtà nella quale tale scrip dovrà lavorare è caratterizzata dalla presenza di un solo utente per PC, quindi è stato piuttosto semplice gestire i vari backup. Per ambienti un pò più complessi dovranno essere apportate sicuramente delle modifiche al codice.

Fatene buon uso.

A presto.

PS: per “zippare” la directory ho utilizzato la suite gratuita Info-ZIP, il cui file zip.exe è stato copiato nella dir di ciascun utente.

Script bash per il backup automatico di un database

Dovendo gestire diversi database su più server ho avuto la necessità di creare uno scripino che automatizzasse la creazione dei loro backup. Riporto quindi lo scrip per intero e successivamente provvederò a spiegare le varie sezioni del codice, anche se a primo acchito tutto dovrebbe apparire piuttosto chiaro.

#!/bin/bash

data=$(date +"%d_%b_%y")

montaggio=$(mount | grep /media/disk)

#File di log
FILELOG=/var/log/backup

ROOT_UID=0

if [ "$UID" -ne "$ROOT_UID" ];then

ERRORE1="Errore 1: Devi essere root per eseguire lo scrip"
echo $ERRORE1
echo "$(date) $ERRORE1" >> $FILELOG

exit 1

fi

if [ ! -n "$montaggio"  ]; then

mount /media/disk

fi

if [ ! -d /media/disk/backup/ ]; then

cd /media/disk

mkdir /media/disk/backup

fi

cd /media/disk/backup

mysqldump nomedatabase -u username -pvostrapassword > database_$data.pl

exit 0

Per prima cosa salvo all’interno della variabile “data” l’output del comando date formattato nel seguente modo:

giorno_prime 3 lettere del mese (in inglese)_anno

successivamente definisco all’interno della variabile FILELOG il pathname relativo al file su cui verranno loggati i vari messaggi di errore dello scrip, in questo caso /var/log/backup. Dopodichè mi accerto che lo scrip venga eseguito da root, poichè lo stesso verrà dato in pasto a cron per essere eseguito con tali privilegi.

A questo punto verifico che l’hard disk secondario sia montato, eseguendo il comando:

mount | grep /media/disk

Se tale comando restituisce una stringa vuota eseguo il mount dell’hard disk secondario e successivamente mi posiziono in /media/disk.

Ora devo verificare che la cartalla backup sia presente in /media/disk. Se non lo è provvedo a crearla (in realtà tale operazione verrà effettuata soltanto durante la prima esecuzione dello scrip).

Bene, posso quindi posizionarmi in /media/disk/backup e successivamente effettuare il dump del database mediante il comando mysqldump. Notate che tra la flag -p e la password per accedere al database non vi sono spazi. Inoltre, il dump verrà salvato in un file il cui nome è costituito dalla stringa database_dataattuale.pl, ad esempio:

database_01_Jul_01.pl

Abbiamo quasi finito, non ci resta che creare un binario criptato (RC4) partendo dal nostro scrip, poichè quest’ultimo contiene diverse informazioni critiche, quali, ad esempio, username e password di accesso al database.

Per fare ciò possiamo utilizzare una semplice applicazione, ovvero shc (il sito ufficiale è il seguente: http://www.datsi.fi.upm.es/~frosal/)

Scarichiamo tale applicazione tramite wget:

wget http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.7.tgz

Scompattiamo la tarball:

tar -xvf shc-3.8.7.tgz

e posizioniamoci nella cartella tar -xvf shc-3.8.7:

cd shc-3.8.7/

Lanciamo il make:

make

Dopodichè facciamo un test per verificare che tale operazione sia andata a buon fine:

make test

Se non ci sono errori dovremmo vedere lo scrip shc presente nella dir shc-3.8.7

Ora trasformiamo il nostro scrip per il backup in eseguibile mediante il comando:

./shc -f /home/nomeutente/database

dove database è il nome del nostro scrip.

Se non ci sono problemi di sorta dovremmo ritrovarci i seguenti 2 file nella nostra home:

database.x e database.x.c

Copiamo ora database.x nella dir /usr/bin/

sudo cp database.x /usr/bin

Infine, mediante cron, scheduliamo l’esecuzione di database.x alle 20 e 30 di ogni sera:

sudo nano /etc/crontab

30 20   * * *   root    backupdb.x > /dev/null 2>&1

redirigendo lo standard output e lo standard error su /dev/null.

Il nostro scrip per il backup giornaliero dei database è finalmente pronto.

See ya.

PS: ovviamente se abbiamo a che fare con database di grandi dimensioni eseguire un backup giornaliero è sconsigliato, sarebbe meglio eseguire backup settimanali o mensili.

PPS: inutile dire che tale scrip supporta solo MySQL.