Il blog sull'informatica

Recentemente, tentando di mettere in ascolto ntop sull'interfaccia eth1 di una sonda basata sulla distro Backtrack 4, dopo un tempo totalmente randomico notavo che il servizio in questione si schiantava in modo alquanto brusco. Ad ulteriore conferma di quanto detto individuo un messaggio lapidario su /var/log/messages, ovvero:

Mar 28 16:54:02 sonda-bt4-ext kernel: ntop[4599]: segfault at 41445036 ip b72d6a18 sp b15dd230 error 6 in libc-2.8.90.so[b7265000+158000]

Oh che bello, un fantastico sementation fault. Cosa fare quindi? Gira che ti rigira individuo la presunta causa del problema nel file dnsCache.db presente nella dir /var/lib/ntop_eth1

Lancio il comando:

nightfly@bt4:/var/lib/ntop_eth1# cat /dev/null > dnsCache.db

avvio ntop_eth1 digitando:

nightfly@bt4:/var/lib/ntop_eth1# sudo service ntop_eth1 start

ed il problema è stato risolto.

Bye.

In questo post ho riportato uno script da me creato il cui scopo è quello di eseguire un backup della configurazione di un router Cisco SOHO 77. Inoltre, sempre nell'ambito del post in questione, ho descritto la procedura per installare e configurare correttamente un server TFTP sulla nostra linux box.

Dando per scontato che il server TFTP sia già attivo e che il file vuoto firewall.cfg sia già presente nella directory /tftpboot, vediamo come configurare il nostro firewall affinchè possa comunicare con il server in ascolto.

Una volta effettuato il login sul PIX 501 lanciamo un conf t e successivamente digitiamo il comando:

PIX501(config)# tftp-server inside <IP del server TFTP> /tftpboot/firewall.cfg

In questo modo stiamo dicendo al PIX qual è l'indirizzo del server ed il pathname del file su cui salvare la configurazione.

Lanciamo un write mem per salvare le modifiche relative alla configurazione del firewall e successivamente accediamo alla nostra linux box. Fattò ciò creiamo il file backup_conf_pix501 il cui contenuto dovrà essere il seguente:

#!/usr/bin/expect

set password1 "<pass1>"
set password2 "<pass2>

spawn telnet <IP del firewall>
expect "Password:"
send "$password1r"
expect "Password:"
send "$password2r"
expect ">"
send "enar"
expect "Password:"
send "$passwordr"
expect "#"
send "write netr"
expect "#"
send "exitr"
expect eof

NB: ricordatevi di mettere un backslash prima di "r".

Rendiamo il file eseguibile digitando:

nightfly@nightbox:~$ sudo chmod +x backup_conf_pix501

spostiamolo in /usr/bin e successivamente editiamo il file /etc/crontab aggiungendo la entry:

00 00   * * * root backup_conf_pix501

Riavviamo cron:

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

ed il gioco è fatto.

See ya.

Recentemente mi è capitato di dover creare un nuovo utente locale che potesse loggarsi (via vty, console oppure aux) su un router Cisco 2851. Per fare ciò mi è bastato digitare il comando:

Router(config)# username <vostro username> privilege 15 secret <vostra password>

Affinchè tale comando abbia effetto, è necessario che sia specificato il login local per ogni line, ad esempio:

Router(config)# line console 0

Router(config-line)# login local

Router(config)# line vty 0 4

Router(config-line)# login local

e così via.

Lanciamo infine un copy run start per salvare le nuove impostazioni ed il gioco è fatto.

Fine del post, a presto.

Ho già trattato diversi argomenti in cui veniva discussa la corretta configurazione di un logserver basato su sitemi *nix. Ora vedremo come monitorare mediante nagios3 il demone che si occupa della raccolta dei log.

Nella fattispecie, il demone in questione è rsyslogd, evoluzione del più datato syslogd. Esso consente di salvare le informazioni inviate dai vari dispositivi di rete su di un apposito file creato all'occorrenza, in modo da tenere traccia degli eventi più rilevanti.

Ora, tale demone (per default) rimane in ascolto sulla porta 514 ed utilizza per il protocollo UDP per il trasporto. Ciò significa che non è previsto alcun meccanismo di SYN SYN/ACK ACK come invece avviene per il protocollo TCP (molto più affidabile ma allo stesso tempo molto più oneroso in termini di banda).

Detto ciò, vediamo come monitorare lo stato di tale servizio sfruttando nagios3. Per prima cosa scarichiamo questo PERL script.

Successivamente salviamo il file appena scaricato nella directory /usr/lib/nagios/plugins e rinominiamolo in check_syslog:

nightfly@nightbox:/usr/lib/nagios/plugins$ sudo mv check_syslog_02.pl check_syslog

A questo punto rendiamo lo script eseguibile digitando:

nightfly@nightbox:/usr/lib/nagios/plugins$ sudo chmod +x check_syslog

Definiamo il comando attraverso il quale verificheremo il corretto funzionamento di rsyslogd. Per fare ciò occorre creare il file syslogd.cfg il cui contenuto dovrà essere:

# 'check_syslog' command definition
define command{
        command_name    check_syslog
        command_line    /usr/lib/nagios/plugins/check_syslog -l '$HOSTADDRESS$' -f '$ARG1$'
        }

Posizioniamoci ora nella directory /etc/nagios3/conf.d ed editiamo il file di configurazione relativo al logserver aggiungendo il seguente servizio:

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       localhost
        service_description             Rsyslog
                check_command                   check_syslog!/var/log/syslog
        }

A questo punto occorre operare sui permessi di lettura/scrittura associati al file syslog. Per prima cosa posizioniamoci nella directory /var/log e lanciamo un ls -ila | grep syslog:

2097425 -rw-r-----  1 syslog      adm       171910 2011-03-21 11:54 syslog

Come possiamo notare il gruppo che ha la possibilita di accedere al file in lettura è adm. Aggiungiamo l'utente nagios al gruppo adm editando il file group presente nella dir /etc:

adm:x:4:nagios

Riavviamo nagios3:

nightfly@nightbox:/etc$ sudo service nagios3 restart

ed abbiamo finito.

A presto. 

Premessa

Prima di introdurre questa piccola guida, occorre spiegare cosa s'intende per WMI. Nella fattispecie, tale acronimo sta per Windows Management Instrumental, ovvero un'estensione del Win32 driver model, grazie alla quale è possibile monitorare e gestire le macchine (sia client che server) su cui è installato il sistema operativo di casa Microsoft (da Windows 2000 in poi).

Inulte dire che esistono già delle piattaforme sviluppate ad hoc che supportano le query WMI (tra cui SCOM), ma la cosa veramente interessante consiste nel poter sviluppare i propri sistemi di monitoraggio basati su script custom editati in VBscript o PowerShell.

Ora, nel caso in cui si voglia allestire un sistema di monitoraggio che supporti le query WMI in ambiente open source, la scelta ricade necessariamente su nagios3. Inoltre, poichè nagios3 non supporta in modo nativo le query WMI, si rende indispensabile l'utilizzo di un tool che funge da tramite tra il server di monitoraggio e le macchine che verranno interrogate. Tale tool prende il nome di NRPE_NT (potete scaricarlo da qui, è gratuito).

Come si può capire dall'immagine precedente, nagios3, attraverso il comando check_nrpe, invia una query ad NRPE_NT (installato su una macchina Windows), il quale la inoltrerà (comportandosi come un vero e proprio proxy) all'host Microsoft di destinazione.

Ricapitolando, abbiamo bisogno dei seguenti elementi per mettere in piedi il nostro sistema di monitoraggio WMI:

1) nagios3;

2) il plugin check_nrpe;

2) NRPE_NT;

3) i plugins V2 per NRPE_NT (potete scaricarli da qui).

Installazione di check_nrpe e configurazione di nagios3

Partendo dal presupposto che nagios3 sia già presente sulla nostra linux box, procediamo con l'installazione del plugin check_nrpe. Per fare ciò occorre digitare:

nightfly@nightbox:~$ sudo apt-get install nagios-nrpe-plugin

Adesso possiamo definire alcuni comandi custom da inviare alla macchina Windows su cui è installato NRPE_NT, affinchè quest'ultima possa inoltrare la query all'host di destinazione. In particolare, creiamo il file wmi.cfg all'interno della directory /etc/nagios-plugins/config, il cui contenuto sarà:

# nagios-WMI-cpu check command definition

define command {

command_name check_WMI_cpu

command_line /usr/lib/nagios/plugins/check_nrpe -H <IP macchina NRPE_NT> -c get_cpu -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

# nagios-WMI-disk check command definition

define command {

command_name check_WMI_disk

command_line /usr/lib/nagios/plugins/check_nrpe -H <IP macchina NRPE_NT> -c get_disk -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

# nagios-WMI-mem check command definition

define command {

command_name check_WMI_mem

command_line /usr/lib/nagios/plugins/check_nrpe -H <IP macchina NRPE_NT> -c get_mem -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

Ovviamente esistono altri comandi di cui si può usufruire, una lista a cui far riferimento la trovate qui.

Bene, adesso definiamo i servizi da monitorare per i nostri host Windows. Un file di configurazione da utilizzare come template e da posizionare nella directory /etc/nagios3/conf.d è il seguente:

define host {
host_name   hostWindows
alias       nightflyclient
address     192.168.1.11
use         generic-host
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_description             query WMI CPU for Microsoft Windows Machine
check_command                   check_WMI_cpu!CPU0!80,90
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_description             query WMI Disk for Microsoft Windows Machine
check_command                   check_WMI_disk!C:!80,90
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_description             query WMI Memory for Microsoft Windows Machine
check_command                   check_WMI_mem!_TOTAL!80,90
}

Salviamo il file appena creato e passiamo all'installazione di NRPE_NT sulla macchina Windows che fungerà da proxy per le query WMI.

Installazione di NRPE_NT

Per prima cosa scompattiamo il file nrpe_nt.0.8b-bin.rar e salviamone il contenuto all'interno della directory NRPE_NT presente in C:

Cremiamo inoltre, sempre all'interno della directory NRPE_NT, la cartella Plugins ed all'interno di quest'ultima creiamo un'ulteriore cartella che chiameremo V2, nella quale salveremo il contenuto del file wmi-1.3.rar.

A questo punto editiamo il file nrpe.cfg presente nella directory bin, che si trova dentro la cartella NRPE_NT.

I punti da modificare sono sostanzialmente tre, ovvero:

1) address.allowed_hosts=<IP della linux box su cui è installato nagios3> (in modo da consentire a nagios di connettersi ad NRPE_NT per usarlo come proxy);

2) dont_blame_nrpe=1 (in modo da consentire l'esecuzione di comandi da remoto);

3) include=C:NRPE_NTbinV2_nrpe_commands.cfg (per dare in pasto ad NRPE_NT alcuni comandi aggiuntivi di monitoraggio).

Una volta configurato NRPE_NT passiamo alla sua installazione. Per fare ciò apriamo il prompt (start->esegui->cmd), posizioniamoci in C: e successivamente nella dir bin presente in NRPE_NT.

A questo punto lanciamo il comando:

nrpe_nt.exe -i

dove la flag -i sta per install.

NB: nel caso in cui stiate utilizzando una macchina su cui è installato Windows 7, prima di procedere con l'installazione di NRPE_NT dovete modificare le impostazioni di controllo dell'account utente:

Una volta installato il servizio NRPE_NT occorre avviarlo mediante il comando net start nrpe oppure attraverso pannello di controllo -> strumenti di amministrazione -> servizi.

Controlliamo ora che NRPE_NT sia in ascolto sulla nostra macchina digitando:

netstat -ano | find ":5666"

il cui output dovrà essere simile al seguente:

TCP    0.0.0.0:5666           0.0.0.0:0              LISTENING       1976

NB: affinchè la macchina su cui è installato nagios3 possa connettersi ad NRPE_NT occorre disabilitare il Firewall di Windows.

Test per verificare il corretto funzionamento di NRPE_NT

Per verificare il corretto funzionamento di NRPE_NT effettuiamo il login sulla nostra linux box e posizioniamoci nella directory /usr/lib/nagios/plugins. A questo punto lanciamo il comando:

nightfly@nightbox:/usr/lib/nagios/plugins$ ./check_nrpe -H <IP della macchina Windows su cui è installato NRPE_NT>

Se l'output immediatamente successivo sarà:

NRPE_NT v0.8b/2.0

vuol dire che NRPE_NT funziona correttamente.

Infine, riavviamo nagios3 per rendere effettive le modifiche della sua configurazione messe in atto nella prima parte di questa guida:

nightfly@nightbox:~$ sudo service nagios3 restart

Adesso sarà possibile monitorare gli host Windows mediante nagios3 ed NRPE_NT.

See ya.

In riferimento a questo post, il fatto che il mio PIX 501 inizi a strillare per la dimensione "eccessiva" dei pacchetti provenienti da alcuni root nameserver (nella fattispecie K e J), è dovuto principalmente ad una questione di standard. Infatti, lo standard originario del DNS (risalente ormai al lontano 1980) prevedeva una dimensione massima di 512 byte per i pacchetti instradati mendiante il protocollo UDP.

Successivamente, l'introduzione dell'IPv6, l'uso opzionale del protocollo TCP per il trasporto e la presenza di alcune flag aggiuntive, specificate all'interno dello standard EDNS0 (acronimo che sta per Extension Mechanism for DNS), ha fatto si che le reply potessero raggiungere delle dimensioni superiori ai 512 byte.

C'è da dire però che proprio tale "aggiornamento" ha reso possibili alcuni tipi di attacco DDoS diretti ai nameserver, tra cui il DNS amplification.

Spero di essere stato esaustivo.

Bye.

E' lunedì mattina e come al solito do un'occhiata ai log collezionati dal mio server. Apro in lettura quelli del PIX e mi ritrovo queste entry:

Mar 14 06:56:44 ***%PIX-4-410001: Dropped UDP DNS reply from outside:192.58.128.30/53 to inside:*.*.*.*/23803; packet length 685 bytes exceeds configured limit of 680 bytes
Mar 14 06:56:45 ***%PIX-4-410001: Dropped UDP DNS reply from outside:193.0.14.129/53 to inside:*.*.*.*/27872; packet length 703 bytes exceeds configured limit of 680 bytes

Lancio un host sugli IP sorgenti, il cui risultato è il seguente:

nightfly@nightbox:/var/log$ host 193.0.14.129
129.14.0.193.in-addr.arpa domain name pointer k.root-servers.net.
nightfly@nightbox:/var/log$ host 192.58.128.30
30.128.58.192.in-addr.arpa domain name pointer j.root-servers.net.

Dunque mi chiedo: come mai i root nameserver mandano dei pacchetti dalle dimensioni così elevate?

Non mi rimane che modificare le impostazioni del PIX per evitare ulteriori notifiche di questo tipo.

A presto.

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

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.

In questo post abbiamo visto come salvare i log di un Cisco PIX 501 su di un apposito server linux. Oggi invece descriverò la procedura per impostare correttamente il logging su di un router Cisco SOHO 77, affinchè le informazioni da esso generate vengano inviate ad una linux box che funge da logserver.

SOHO 77

Per prima cosa entriamo in modalità enable e lanciamo un conf t:

soho77# conf t

soho77(config)#

Adesso digitiamo i seguenti comandi:

soho77(config)# logging <indirizzo IP del logserver>

soho77(config)# log facility local2

Nel caso in cui si voglia impostare un certo livello di severity (ad esempio warning), deve essere usato il comando:

soho77(config)# logging trap 4

Infine, lanciamo un copy run start per rendere effettive le modifiche apportate alla configurazione del nostro router:

soho77(config)# copy run start

Linux box

Sulla nostra linux box (ovvero il logserver) occorre fare in modo che il demone rsyslogd intercetti a dovere gli eventi inviati dal router.

Per prima cosa apriamo in scrittura il file 50-default.conf presente nella directory /etc/rsyslog.d ed inseriamo la seguente stringa subito dopo user.* :

local2.4                        /var/log/soho77.log

Creiamo il file che dovrà contenere i log del SOHO77:

nightfly@nightbox:/etc/rsyslog.d$ sudo touch soho77.log

Riavviamo quindi il demone rsyslogd:

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

A questo punto non ci resta che definire appositamente la logrotation, in modo da tenere traccia dei log inviati dal router per un giusto lasso di tempo, magari sottoforma di tarball.

Per fare ciò posizioniamoci nella directory /etc/logrotate.d/ e creiamo il file soho77, il cui contenuto dovrà essere:

/var/log/soho77.log {

rotate 7

weekly

compress

missingok

notifempty

}

In particolare, il numero massimo di log che verranno conservati (comprese le tarball) è pari a 7 (rotate 7), ciascun log verrà compresso (compress) ed archiviato settimanalmente (weekly). Inoltre, nel caso in cui il file di log sia mancante non verrà generato alcun messaggio di errore (missingok) e la rotation non verrà attuata quando il file di log risulta vuoto (notifempty).

Fine del post, alla prossima.

Recentemente mi è capitato di dover creare un form in cui inserire più campi di tipo select. Fin qui tutto facile, se non fosse per il fatto che a parte il primo, tutti gli altri campi di questo tipo devono essere "a comparsa". Per di più, l'unica discriminante in base alla quale viene deciso quale select inserire dinamicamente, si fonda solo ed esclusivamente sull'opzione scelta dall'utente nell'ambito della select immediantamente precedente.

Ma bando alle ciance, ecco il codice:

function dinamica() {
var tipologia = document.getElementById("tipologia");
if(tipologia.selectedIndex == 1)
{
document.getElementById('parah').innerHTML = "<br><strong>tipo entrata (*): </strong>
<select class='bordo' name='tipoentrata' id='tipoentrata' tabindex='3'>
<option>Seleziona tipo entrata</option>
<option>Finanziamenti</option>
<option>Biglietteria</option>
<option>Servizi</option>
<option>Banche</option>
</select>";
}
else if(tipologia.selectedIndex == 2)
{
document.getElementById('parah').innerHTML = "<br><strong>tipo uscita (*): </strong>
<select class='bordo' name='tipouscita' id='tipouscita' tabindex='3' onchange='javascript:dinamica()'>
<option>Seleziona tipouscita</option>
<option>Cassa</option>
<option>Banca</option>
<option>Effetti</option>
</select>";
}
else if(tipologia.selectedIndex == 3)
{
document.getElementById('parah').innerHTML = "<br><strong>mastro impegno (*): </strong>
<select class='bordo' name='mastroimpegno' id='mastroimpegno' tabindex='3'>
<option>Seleziona mastro</option>
<?php while($riga = $risultato_mastro_impegno_di_spesa -> fetch_assoc()){?>
<option><?php echo $riga["Nome"]?></option>
<?php } ?>
</select>";
}
}

In particolare, mi sono avvalso dell'innerHTML per inserire stralci di codice HTML in punti ben precisi della pagina, identificati mediante il termine parah.

Se avete qualche dubbio chiedete pure.

A presto.