Archivi categoria: SO: Linux

Logica di funzionamento del DNS (Domain Name System)

Prima di approfondire un argomento che avevo già trattato tempo addietro, ovvero il DNS cache poisoning (vedi qui per ulteriori dettagli), è utile illustrare la logica di funzionamento su cui si basa il Domain Name System.

Esistono, in soldoni, 2 tipologie di query DNS:
1) ricorsive;
2) iterative.

Supponiamo che il client voglia risolvere l’FQDN www.ciao.com

Nel primo caso il client contatterà il proprio resolver (ad esempio il nameserver dell’ISP) sottoponendogli la query. Se la risposta non è contenuta all’interno
della sua cache, esso effettuerà una query ai root nameserver. I root nameserver forniranno una risposta di tipo referral (con ANSWER SECTION vuota ed AUTHORITY SECTION non vuota), contenente una lista di nameserver da contattare per il top level domain (in gergo TLD) .com.
A questo punto il resolver contatterà uno dei nameserver autoritativi appena individuati, il quale fornirà una risposta di tipo referral indicando il nameserver autoritativo per il dominio cercato. Infine, quest’ultimo verrà interrogato e fornirà una risposta alla query (ANSWER SECTION non vuota) indicando l’indirizzo IP relativo al record A (www) ricercato (sempre se il suddetto record esiste).
La risposta, una volta giunta al resolver, verrà quindi girata al client.

recursiveDa notare che sia i root nameserver che i nameserver autoritativi per i TLD forniscono esclusivamente risposte di tipo referral, ergo funzionano solo
in modalità iterativa. Infatti, pensate a cosa accadrebbe se ciascun root nameserver interrogato (13 in tutto) iniziasse a fare query ricorsive per individuare
un determinato indirizzo IP… sarebbe una scelta davvero sconveniente (per usare un’espressione moderata) sia in termini di carico che in termini di latenza.

Inoltre, ciascun software che svolge funzioni di namserver utilizza degli algoritmi ben precisi per individuare il server a cui sottoporre la query (root, TLD o autoritativo che sia).
Nella fattispecie, bind usa la tecnica dell’RTT (Round Trip Time), grazie alla quale dovrebbe riuscire ad individuare il namserver più peformante (che coincide con quello che ha risposto più velocemente alla query).

Per ciò che concerne le query iterative, esse prevedono (in generale) il coinvolgimento diretto del client. Per prima cosa esso sottoporrà la query al proprio resolver, che gli risponderà con la lista dei root nameserver (risposta di tipo referral). Il root nameserver successivamente contattato dal client, gli fornirà una risposta di tipo referral indicando una lista di namserver autoritativi per il TLD .com. Dopodichè il client sottoporrà la query ad uno dei predetti nameserver, il quale gli fornirà come risposta una lista dei namserver autoritativi per il dominio ciao.com.
Infine, il client contatterà uno dei nameserver autoritativi per ciao.com che gli girerà la risposta contenente l’indirizzo IP per www.ciao.com (sempre se il record esiste).

Un esempio di query iterativa più essere facilmente ricavato utilizzando dig con l’opzione +trace, ad esempio:

[root@linuxbox ~]# dig +trace www.ciao.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2 <<>> +trace www.ciao.com
;; global options: +cmd
.                       440639  IN      NS      b.root-servers.net.
.                       440639  IN      NS      m.root-servers.net.
.                       440639  IN      NS      h.root-servers.net.
.                       440639  IN      NS      k.root-servers.net.
.                       440639  IN      NS      a.root-servers.net.
.                       440639  IN      NS      i.root-servers.net.
.                       440639  IN      NS      f.root-servers.net.
.                       440639  IN      NS      e.root-servers.net.
.                       440639  IN      NS      j.root-servers.net.
.                       440639  IN      NS      d.root-servers.net.
.                       440639  IN      NS      l.root-servers.net.
.                       440639  IN      NS      g.root-servers.net.
.                       440639  IN      NS      c.root-servers.net.
;; Received 496 bytes from 192.168.1.1#53(192.168.1.1) in 38 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 490 bytes from 192.203.230.10#53(192.203.230.10) in 4323 ms

ciao.com.               172800  IN      NS      dns2.progtech.net.
ciao.com.               172800  IN      NS      dns.progtech.net.
;; Received 111 bytes from 192.33.14.30#53(192.33.14.30) in 623 ms

www.ciao.com.           86400   IN      A       185.60.164.38
ciao.com.               86400   IN      NS      dns2.progtech.net.
ciao.com.               86400   IN      NS      dns.progtech.net.
;; Received 127 bytes from 80.190.149.57#53(80.190.149.57) in 82 ms

Per completezza, riporto il contenuto di una risposta ad una quey DNS, con le relative sezioni (QUERY, ANSWER, AUTHORITY, ADDITIONAL)

[root@linuxbox ~]# dig libero.it

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2 <<>> libero.it
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23298
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;libero.it.                     IN      A

;; ANSWER SECTION:
libero.it.              300     IN      A       37.9.239.32

;; AUTHORITY SECTION:
libero.it.              10799   IN      NS      n2.libero.it.
libero.it.              10799   IN      NS      n1.libero.it.

;; ADDITIONAL SECTION:
n2.libero.it.           10799   IN      A       156.154.67.47
n1.libero.it.           10799   IN      A       156.154.66.47

;; Query time: 256 msec
;; SERVER: 10.1.1.1#53(10.1.1.1)
;; WHEN: Tue May 31 09:29:06 2016
;; MSG SIZE  rcvd: 109

essa ci tornerà utile quando vedremo più nel dettaglio la logica su cui si basa il DNS cache poisoning.

DNS Spoofing a fin di bene

Facendo una rapida ricerca su Google si evince che il DNS Spoofing è una tecnica di cracking che rientra nella categoria MITM (Man in The Middle), tramite la quale “si fa credere” al PC della vittima che il sito X (ad esempio www.facebook.com) risponde all’indirizzo IP della macchina dell’aggressore (ad esempio 192.168.1.5). Se oltre a ciò sulla macchina dell’aggressore è presente anche una replica della home di facebook (ottenuta, ad esempio, mediante wget), le credenziali della vittima potranno essere facilmente individuate, a meno di messaggi HSTS (connessione non sicura/sito non attendibile) e di utenti più smaliziati (assenza del “lucchetto” di fianco alla barra degli indirizzi del browser).

Essa può essere realizzata seguendo 2 alternative: l’inserimento di record ad hoc all’interno del file hosts della macchina vittima oppure modificando il suo nameserver primario (dalle impostazioni di rete). In quest’ultimo caso parliamo di DNS Hijacking.

dnsspoofing

Dopo questa breve premessa è comunque utile fare una precisazione: il DNS Spoofing non è sempre sinonimo di cracking. Infatti, basti pensare al caso in cui l’ISP decide di “bloccare” l’accesso ad un sito per via dei suoi contenuti, agendo direttamente sui propri nameserver in modo da creare una mappatura statica indirizzo IP/FQDN che rimanda ad una pagina Web specifica, in cui viene notificato all’utente il blocco in atto (con eventuale registrazione degli indirizzi delle macchine che tentano di accedervi).

Un altro caso di utilizzo “bonario” della tecnica in questione riguarda il “blocco” di domini che veicolano notoriamente spyware, adaware e malware di ogni tipo. In questo post vi mostrerò come configurare il nameserver locale (realizzato grazie a dnsmasq, vedi qui per ulteriori dettagli) in modo da ottenere il blocco dei suddetti domini, semplicemente facendoli puntare a 127.0.0.1 (localhost).

Occorre precisare, inoltre, che tale tecnica funziona solo ed esclusivamente nel caso in cui gli utenti non abbiano privilegi di amministrazione sulle loro macchine e che quindi non siano in grado di modificare le impostazioni delle schede di rete (lasciando come nameserver primario quello da noi configurato). In aggiunta, la manutenibilità dei siti da bloccare è di gran lunga superiore rispetto a quella offerta dai blocchi mediante file hosts di ciascuna macchina (poichè, nel primo caso, si ha a disposizione una lista “centralizzata” di domini malevoli).

Ma passiamo alla configurazione vera e propria di dnsmasq. I domini che intendiamo bloccare sono i seguenti:

doubleclick.net
scorecardresearch.com
criteo.com
imrworldwide.com

per cui le direttive da aggiungere a dnsmasq saranno le seguenti:

address=/doubleclick.net/127.0.0.1
address=/scorecardresearch.com/127.0.0.1
address=/criteo.com/127.0.0.1
address=/imrworldwide.com/127.0.0.1

da notare che verranno bloccati non solo i suddetti domini, ma anche tutti gli eventuali sottodomini ad essi riconducibili.

Riavviamo dnsmasq:

root@ubuntubox:~# service dnsmasq restart

e testiamo il funzionamento del blocco appena configurato, pingando uno dei domini che intendiamo “dirottare” su localhost:

root@ubuntubox:~# ping criteo.com
PING criteo.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.035 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.037 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.036 ms

ed anche qualche sottodominio:

root@ubuntubox:~# ping pippo.criteo.com
PING pippo.criteo.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.033 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.051 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.040 ms
64 bytes from localhost (127.0.0.1): icmp_req=4 ttl=64 time=0.039 ms

Infine, diamo una ripulita ai PC degli utenti utilizzando software specifici quali Malwarebytes (in modo da eliminare il problema alla radice), continuando anche a monitorare le hit del proxy alla ricerca di eventuali domini “sospetti”.

Alla prossima.

PS: tale tecnica, a mio avviso, è più performante (ma meno malleabile) rispetto al blocco realizzato mediante l’uso di un proxy (ad esempio squid + squidguard), poichè agendo direttamente sul meccanismo di risoluzione dei nomi, si crea meno overhead e si ottengono tempi di risposta molto più ridotti.

dnsmasq ed Ubuntu: configurare un server DNS/DHCP per ambienti SOHO

Premesso che per mettere in piedi un nameserver locale si possono utilizzare diverse soluzioni open source, anche di tipo enterprise (una su tutte è rappresentata da bind/named), ho deciso di installare dnsmasq su un server Ubuntu per 2 motivi:

1) la rete aveva dimensioni estremamente ridotte (un server, qualche workstation e 3 stampanti), quindi rientrava nell’ambito delle infrastrutture SOHO (Small Office Home Office);

2) vi era la necessità di tirar su anche un servizio di DHCP, configurabile direttamente sull’applicativo in questione (che quindi può svolgere, contemporaneamente, sia il ruolo di nameserver che quello di DHCP server).

dnsmasq

Configurazione del DHCP server

Fare in modo che dnsmasq svolga le funzioni tipiche di un server DHCP è un’operazione abbastanza banale. Infatti, è sufficiente editare la configurazione del demone in questione (operando sul file /etc/dnsmasq.conf), aggiungendo le seguenti direttive:

no-dhcp-interface=eth1

dhcp-range=eth1,192.168.0.100,192.168.0.199,8h

In particolare, ho messo in ascolto il server DHCP sulla sola interfaccia eth0 (dato che si tratta di una macchina dual homed, in cui la scheda eth1 è collegata ad Internet mediante uno screened router). Inoltre, ho definito il pool di indirizzi che possono assere assegnati ai client che ne fanno richiesta, con relativo lease time (8h).

Configurazione del nameserver

Tale configurazione è un po’ più complessa rispetto alla precedente ma risulta comunque abbordabile.

Diciamo che dnsmasq è un nameserver “giocattolo”, in cui molti record DNS devono essere definiti all’interno di un file “piatto”, quale, ad esempio, /etc/hosts (anche se è possibile definire un file ad hoc per tale scopo), senza che vi sia quindi la necessità di creare una specifica zona DNS (cosa che invece risulta essere mandatoria con altri nameserver “un po’ più seri”).

I record di tipo A presenti nel file /etc/hosts avevano un formato simile al seguente:

192.168.0.2     proxy
192.168.0.4     server1
192.168.0.5     PC1
192.168.0.6     stampante1
192.168.0.7     stampante2
192.168.0.9     stampante3
192.168.0.10    PC2

Per quanto riguarda, invece, la configurazione del servizio DNS, ho abilitato le seguenti direttive (all’interno del file /etc/dnsmasq.conf):

interface=eth0
except-interface=eth1
listen-address=192.168.0.2

expand-hosts

domain=soho.loc

Le prime 3 servono a mettere in ascolto il server solo ed esclusivamente sull’interfaccia rivolta verso la LAN. Con expand-hosts e domain=soho.loc, invece,  ho fatto in modo che le query DNS vadano a buon fine anche nel caso in cui venga fornito il solo hostname della macchina di cui si vuole conoscere l’indirizzo IP.

Poichè il suddetto nameserver deve risolvere solo ed esclusivamente gli indirizzi locali, ho dovuto definire i forwarder (o nameserver di upstream) a cui inviare le query per tutte le zone DNS pubbliche. La direttive che ho utilizzato sono le seguenti:

resolv-file=/etc/resolv.dnsmasq
strict-order

dove il contenuto del file /etc/resolv.dnsmasq era il seguente:

nameserver 8.8.8.8
nameserver 208.67.222.222
nameserver 8.8.4.4
nameserver 208.67.220.220

La direttiva strict-order faceva in modo che i forwarder venissero contattati seguendo  l’ordine con cui sono stati definiti all’interno del suddetto file (il secondo nameserver viene contattato solo nel caso in cui il primo non sia raggiungibile, ergo, per ottenere una maggiore ridondanza, ho deciso di alternare ai nameserver di Google quelli di OpenDNS).

Per avere un maggiore controllo sulle query inoltrate al nameserver locale, ho deciso di loggarle su un apposito file di testo grazie ai seguenti parametri di configurazione:

log-queries
log-facility=/var/log/dnsmasq/query.log

Ho anche configurato la rotazione dei log mediante il file dnsmasq posto all’interno della directory /etc/logrotate.d:

/var/log/dnsmasq/query.log {
        rotate 7
        weekly
        compress
        missingok
        notifempty
}

Infine, affinchè i client della LAN riuscissero a “riconoscere” i record DNSSEC (garantendo loro una maggiore sicurezza durante la navigazione su Internet), ho fatto in modo che dnsmasq girasse le query DNSSEC ai forwarder (demandando loro il ruolo di validator).

La direttiva che mi ha consentito di fare ciò è la seguente:

proxy-dnssec

Il fatto che il nameserver primario di Google (8.8.8.8) sia il primo della lista dei forwarder non è certamente un caso. Infatti, esso garantisce dei tempi di risposta più brevi rispetto a quelli di OpenDNS, oltre ad essere anche DNSSEC compliant (cosa che OpenDNS non è).

In definitiva, la configurazione di dnsmasq (in base alle mie esigenze) si è rivelata essere la seguente:

no-dhcp-interface=eth1

dhcp-range=eth1,192.168.0.100,192.168.0.199,8h

interface=eth0
except-interface=eth1
listen-address=192.168.0.2

expand-hosts

domain=soho.loc

resolv-file=/etc/resolv.dnsmasq
strict-order

log-queries
log-facility=/var/log/dnsmasq/query.log

proxy-dnssec

Dopo aver effettuato un controllo sintattico della suddetta configurazione mediante il comando:

root@ubuntubox:~# dnsmasq --test

ed aver riavviato il demone:

root@ubuntubox:~# service dnsmasq restart

sono passato ai test funzionali mediante dig. Per prima cosa ho effettuato una query di tipo A per il record proxy, utilizzando dapprima il solo hostname:

root@fw-scar:~# dig @localhost proxy

; <<>> DiG 9.8.1-P1 <<>> @localhost proxy
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3216
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;proxy.                         IN      A

;; ANSWER SECTION:
proxy.                  0       IN      A       192.168.0.2

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri May 20 15:50:11 2016
;; MSG SIZE  rcvd: 39

e successivamente l’intero FQDN:

 root@fw-scar:~# dig @localhost proxy.soho.loc

; <<>> DiG 9.8.1-P1 <<>> @localhost proxy.soho.loc
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30251
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;proxy.soho.loc.                        IN      A

;; ANSWER SECTION:
proxy.soho.loc.         0       IN      A       192.168.0.2

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri May 20 15:52:15 2016
;; MSG SIZE  rcvd: 48

Successivamente mi sono concentrato sui tempi di risposta per i domini pubblici (da parte dei forwarder), ottenendo i seguenti tempi pre-cashing:

root@fw-scar:~# dig @localhost repubblica.it | grep "Query time"
;; Query time: 50 msec

e post caching:

root@fw-scar:~# dig @localhost repubblica.it | grep "Query time"
;; Query time: 0 msec

Infine, ho testato la risoluzione dei record DNSSEC, utilizzando il comando:

root@fw-scar:~# dig @localhost pir.org +dnssec +multi

; <<>> DiG 9.8.1-P1 <<>> @localhost pir.org +dnssec +multi
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35285
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;pir.org.               IN A

;; ANSWER SECTION:
pir.org.                299 IN A 97.107.141.235
pir.org.                299 IN RRSIG A 5 2 300 20160602204000 (
                                20160519204000 58424 pir.org.
                                cJwr7HlIMA+DyQ8vqqmkNtHRAqsGVdKWTQkJeP/a5698
                                UTyK/cF08uYhH8xMk9I0RMWqtkJDM8od8hWmYUZgidzi
                                7Fh26m1FQYGAcN/PMw2/6wEnNh4ErWZtXe2fXRAS8btx
                                I+nyRPOCoAHR3CjC0cjKqtniUoWHt5x/51iEBw4= )

;; Query time: 86 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri May 20 15:57:36 2016
;; MSG SIZE  rcvd: 219

ricevendo come risposta sia il record A che il relativo RRSIG.

Alla fine della fiera ho messo in piedi un server DNS/DHCP funzionante e funzionale.

Alla prossima.

lftp: mirroring di un sito remoto da CLI

Supponiamo che vi sia la necessità di trasferire il contenuto di un sito Web su un altro sito Web autorizzato (tale pratica, in gergo, prende il nome di mirroring). Supponiamo, inoltre, che il task in questione debba essere automatizzato tramite un cronjob oppure uno scheduled task di Windows. Cosa fare dunque? Semplice, iniziare ad utilizzare lftp.

lftp

Il suddetto tool è dotato di una console integrata, che può essere richiamata digitando semplicemente lftp, ad esempio:

[root@linux ~]# lftp
lftp :~>

Nel caso in cui si volesse creare un task automatico, sconsiglio fortemente l’uso della console in questione (a meno di tool esterni, quali expect, in grado di interagire con essa), e raccomando di avvalersi dell’opzione -e, grazie alla quale i comandi lftp possono essere inviati direttamente da CLI, ad esempio:

lftp -u vostrouser,vostrapassword sitodamirrorare -e 'set ftp:use-feat off; set ftp:ssl-allow off; mirror -c / ../sitemirrored; exit'

Nella fattispecie, ho disabilitato l’invio del comando FEAT (ftp:use-feat off) ed ho inibito qualsiasi tentativo di connessione tramite FTPS (ftp:ssl-allow off). Inoltre, ho inizializzato il mirroring (comprensivo di resume in caso di disconnessione, grazie all’opzione -c che sta per –continue), specificando la directory sorgente (in questo caso /) e quella di destinazione (../sitemirrored).

Attenzione: se state utilizzando la versione Windows di lftp, consiglio di copiare l’eseguibile nella stessa unità in cui si trova la dir di destinazione, in quanto ho riscontrato diversi problemi relativi all’attraversamento delle directory.

Una volta completato il mirroring del sito, è possibile effettuare la stessa operazione in modo incrementale, ovvero “copiando” solo ed esclusivamente i nuovi file (quelli che non presenti durante la prima tornata). Il comando da utilizzare è il seguente:

lftp -u vostrouser,vostrapassword sitodamirrorare -e 'set ftp:use-feat off; set ftp:ssl-allow off; mirror -n / ../sitemirrored; exit'

dove l’opzione -n sta per –only-newer.

Non ci resta che creare il cronjob (o lo scheduled task) ed abbiamo finito.

Alla prossima.

auto_clean_zombies: event handler per Nagios in grado di ripulire il sistema dai processi zombie

In questo post ho illustrato il codice di uno scrip da me realizzato, in grado di ripulire il sistema dai processi zombie. Ora vedremo come fare ad integrare, sotto forma di event handler, il predetto scrip con Nagios. Per prima cosa è necessario creare l’event handler vero e proprio (che funge da wrapper), il quale richiamerà lo scrip clean_zombies in caso di necessità:

#!/bin/bash

case "$1" in
OK)
        ;;
WARNING)
        ;;
UNKNOWN)
        ;;
CRITICAL)
       case "$2" in
                SOFT)
                        case "$3" in
                        3)
                                echo -n "Cleaning zombie processes (3rd soft critical state)..."
                                usr/bin/sudo /root/scrips/clean_zombies
                                ;;
                                esac
                        ;;
                HARD)
                        echo -n "Cleaning zombie processes (3rd soft critical state)..."
                        usr/bin/sudo /root/scrips/clean_zombies
                        ;;
                esac
                ;;
        esac

exit 0

Successivamente occorre creare un apposito comando all’interno del file /etc/nagios/object/commands.cfg:

# 'auto_clean_zombies' command definition
define command {
        command_name      auto_clean_zombies
        command_line      /usr/lib64/nagios/plugins/eventhandlers/auto_clean_zombies $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$
        }

A questo punto possiamo assegnare l’event handler al servizio Total Processes definito nel file di configurazione dell’host per il quale si intende monitorare il numero dei processi:

define service{
        use                            local-service         
        host_name                      localhost
        service_descripion             Total Processes
        event_handler                  auto_clean_zombies
        check_command                  check_local_procs!280!400!RSZDT
        }

Inoltre, affinchè l’untente nagios possa lanciare il suddetto scrip senza che vi sia la necessità di inserire la password di autenticazione, occorre editare il file /etc/sudoers nel seguente modo:

nagios   ALL=NOPASSWD:   /root/scrips/clean_zombies

Ricarichiamo la configurazione di Nagios:

[root@linuxbox ~]# service nagios reload

ed abbiamo finito. Alla prossima.

clean_zombies: script bash per ripulire il sistema dai processi zombie

Tenere sotto controllo il numero di processi attivi sulla nostra macchina è certamente una buona pratica, soprattutto quando si parla di sistemi in produzione. Tale monitoraggio può essere realizzato mediante il buon vecchio Nagios, il quale provvederà ad inviarci un’opportuna notifica nel caso in cui il numero dei processi superi una determinata soglia (definibile a piacere).

bashOccorre precisare, però, che nel computo totale rientrano anche i processi zombie, i quali, per definizione, non possono essere killati (sono già in stato defunct). Ergo, per sbarazzarsene occorrerà “fermare” il processo padre (o parent process). Ora, poichè non esiste pratica più noisa dell’andare a ricercare i padri dei vari processi zombie, ho deciso di realizzare il seguente scrip bash in grado di automatizzare il task in questione (con relativo respawning del parent process):

parents=`ps -ef | grep defunct | grep -v grep | awk '{print $3}' | sort -u | wc -l`

p=1

parentidlist=`ps -ef | grep defunct | grep -v grep | awk '{print $3}' | sort -u`

if [[ ! -z "$parents" ]] && [[ "$parents" -gt 0 ]];then
        while [[ "$p" -le "$parents" ]]
        do
                parentid=`echo $parentidlist | awk -v p="$p" '{print $p}'`
                parentname=`ps -o cmd -p $parentid | grep -v CMD`

                if [[ ! -z "$parentid" ]] && [[ ! -z "$parentname" ]];then
                        echo "Terminating $parentname with PID $parentid..."
                        kill -15 "$parentid"
                        sleep 10
                        running=`ps aux | grep "$parentname" | grep -v grep`
                        if [[ -z "$running" ]];then
                                echo "Starting $parentname..."
                                eval $parentname
                        else
                                echo "Error: the process $parentname is still running, switching to the next one..."
                        fi
                fi

                let p=p+1
        done
else
        echo "No defunct process, exiting..."
        exit 1
fi

Il suddetto codice è abbastanza intuitivo. Per prima cosa individuo il numero totale e la lista dei PPID (parent process id) associati a ciascun processo in stato defunct (se esistono). A questo punto, mediante un banale ciclo while, “termino” i processi padre ricavati in precedenza, con successivo respawning degli stessi (sempre che il kill -15 aka SIGTERM sia andato in buon fine, altrimenti skip e si procede con il PPID successivo). Da notare che ho utilizzato la direttiva eval piuttosto che exec, poichè, in quest’ultimo caso, veniva forzata l’uscita dal while.

Se volete fare qualche test potete utilizzare quest’altro scrip bash (fork_zombies) che ho creato allo scopo:

#!/bin/bash

(sleep 1 & exec /bin/sleep 60)

è sufficiente lanciarne qualche istanza in background mediante il comando:

[root@linuxbox ~]# ./fork_zombies &

Nel prossimo post vedremo come integrare il suddetto scrip con Nagios (sotto forma di event handler).

Alla prossima.

check_ntp_peers: script bash per il monitoraggio dei peer NTP mediante Nagios

Il protocollo NTP ci consente, in soldoni, di tenere aggiornate la data e l’ora di sistema, sincronizzandole con un’apposita sorgente di tempo. Per i sistemi *nix, nella stragrande maggioranza dei casi, è sufficiente configurare il servizio NTP (attivo mediante il demone ntpd, o, in alternativa, utilizzando l’accoppiata ntpdate + crontab) agendo sul suo file diconfigurazione (ovvero ntp.conf) e definendo le sorgenti alle quali sincronizzarsi.

ntpAd esempio:

server ntp1.inrim.it
server ntp2.inrim.it

Ora, per saggiare lo stato di sincronizzazione del nostro server, a parte il classico comando date, è possibile utilizzare un apposito tool per le interrogazioni NTP, ovvero ntpq:

[root@linuxbox ~]# ntpq
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp1.inrim.it   .CTD.            1 u    4   64  377   45.819    0.219   2.655
+ntp2.inrim.it   .CTD.            1 u  903 1024  377   48.974    1.788   0.978

In particolare, con il comando pe, sono riuscito a recuperare la lista dei peers (ovvero le sorgenti di tempo) con i relativi valori di offset (i quali rappresentano la discrepanza, in ms, tra l’ora locale di sistema e quella del peer stesso), di jitter (ovvero il ritardo, anch’esso espresso in ms, accumulato tra 2 aggiornamenti immediatamente successivi) e di delay (RTT, in ms, associato alla comunicazione con il time server remoto). Da notare, inoltre, che il campo refid indica qual è (se esiste, dipende dallo stratum, specificato dal campo st) la sorgente di tempo utilizzata a loro volta dai server che sto interrogando (rispettivamente ntp1.inrim.it ed ntp2.inrim.it), mentre il carattere * mostra quale dei 2 server da me definiti all’interno del file ntp.conf sto utilizzando per sincronizzare la data e l’ora di sistema.

Dopo questa breve carrellata introduttiva veniamo al dunque, per cui riporto il contenuto dello scrip bash in grado di tenere sotto controllo i valori associati alle sorgenti NTP definite sul nostro sistema:

#!/bin/bash

warn_values=$1
crit_values=$2

warn_delay=`echo $warn_values | awk -F "," '{print $1}'`
warn_offset=`echo $warn_values | awk -F "," '{print $2}'`
warn_jitter=`echo $warn_values | awk -F "," '{print $3}'`

warn_delay_len=$((${#warn_delay} - 1))
warn_offset_len=$((${#warn_offset} - 1))
warn_jitter_len=$((${#warn_jitter} - 1))

crit_delay=`echo $crit_values | awk -F "," '{print $1}'`
crit_offset=`echo $crit_values | awk -F "," '{print $2}'`
crit_jitter=`echo $crit_values | awk -F "," '{print $3}'`

crit_delay_len=$((${#crit_delay} - 1))
crit_offset_len=$((${#crit_offset} - 1))
crit_jitter_len=$((${#crit_jitter} - 1))

if [[ "$warn_delay_len" -gt 5 ]];then
        echo "UNKNOWN: bad value for warning delay"
        echo "Usage: check_ntp_peers warndelay,warnoffset,warnjitter critdelay,critoffset,critjitter"
        exit 3;
fi

if [[ "$warn_offset_len" -gt 5 ]];then
        echo "UNKNOWN: bad value for warning offset"
        echo "Usage: check_ntp_peers warndelay,warnoffset,warnjitter critdelay,critoffset,critjitter"
        exit 3;
fi

if [[ "$warn_jitter_len" -gt 5 ]];then
        echo "UNKNOWN: bad value for warning jitter"
        echo "Usage: check_ntp_peers warndelay,warnoffset,warnjitter critdelay,critoffset,critjitter"
        exit 3;
fi

if [[ "$crit_delay_len" -gt 5 ]];then
        echo "UNKNOWN: bad value for critical delay"
        echo "Usage: check_ntp_peers warndelay,warnoffset,warnjitter critdelay,critoffset,critjitter"
        exit 3;
fi

if [[ "$crit_offset_len" -gt 5 ]];then
        echo "UNKNOWN: bad value for critical offset"
        echo "Usage: check_ntp_peers warndelay,warnoffset,warnjitter critdelay,critoffset,critjitter"
        exit 3;
fi

if [[ "$crit_jitter_len" -gt 5 ]];then
        echo "UNKNOWN: bad value for critical jitter"
        echo "Usage: check_ntp_peers warndelay,warnoffset,warnjitter critdelay,critoffset,critjitter"
        exit 3;
fi

ntp_delay=`/usr/sbin/ntpq -p | grep '*' | awk '{print $8}'`
ntp_offset=`/usr/sbin/ntpq -p | grep '*' | awk '{print $9}'`
ntp_jitter=`/usr/sbin/ntpq -p | grep '*' | awk '{print $10}'`

if [[ ! -z $warn_values ]];then
         if [[ ! -z $crit_values ]];then
                if [[ ! -z $warn_delay ]];then
                        if [[ ! -z $crit_delay ]];then
                                if [[ "$(echo $ntp_delay '>=' $warn_delay | bc)" -eq 1 ]] && [[ "$(echo $ntp_delay '<' $crit_delay | bc)" -eq 1 ]];then
                                        delay="NTP delay is $ntp_delay ms";
                                        delay_perf="| ntp_delay=$ntp_delay"
                                        retval_1=1;
                                elif [[ "$(echo $ntp_delay '>=' $crit_delay | bc)" -eq 1 ]];then
                                        delay="NTP delay is $ntp_delay ms";
                                        delay_perf="| ntp_delay=$ntp_delay"
                                        retval_1=2;
                                else
                                        delay="NTP delay is $ntp_delay ms";
                                        delay_perf="| ntp_delay=$ntp_delay"
                                        retval_1=0;
                                fi
                        else
                                echo "UNKNOWN: NTP critical delay is unknown"
                                exit 3;
                        fi
                else
                        echo "UNKNOWN: NTP warning delay is unknown"
                        exit 3;
                fi
                if [[ ! -z $warn_offset ]];then
                        if [[ ! -z $crit_offset ]];then
                                if [[ "$(echo $ntp_offset '<' 0 | bc)" -eq 1 ]];then
                                        warn_offset=$(echo "-1 * $warn_offset" | bc)
                                        crit_offset=$(echo "-1 * $crit_offset" | bc)
                                        if [[ "$(echo $ntp_offset '<=' $warn_offset | bc)" -eq 1 ]] && [[ "$(echo $ntp_offset '>' $crit_offset | bc)" -eq 1 ]];then
                                                offset="NTP offset is $ntp_offset ms";
                                                offset_perf=" ntp_offset=$ntp_offset"
                                                retval_2=1;
                                        elif [[ "$(echo $ntp_offset '<' $crit_offset | bc)" -eq 1 ]];then
                                                offset="NTP offset is $ntp_offset ms";
                                                offset_perf=" ntp_offset=$ntp_offset"
                                                retval_2=2;
                                        else
                                                offset="NTP offset is $ntp_offset ms";
                                                offset_perf=" ntp_offset=$ntp_offset"
                                                retval_2=0;
                                        fi
                                else
                                        if [[ "$(echo $ntp_offset '>=' $warn_offset | bc)" -eq 1 ]] && [[ "$(echo $ntp_offset '<' $crit_offset | bc)" -eq 1 ]];then
                                                offset="NTP offset is $ntp_offset ms";
                                                offset_perf=" ntp_offset=$ntp_offset"
                                                retval_2=1;
                                        elif [[ "$(echo $ntp_offset '>' $crit_offset | bc)" -eq 1 ]];then
                                                offset="NTP offset is $ntp_offset ms";
                                                offset_perf=" ntp_offset=$ntp_offset"
                                                retval_2=2;
                                        else
                                                offset="NTP offset is $ntp_offset ms";
                                                offset_perf=" ntp_offset=$ntp_offset"
                                                retval_2=0;
                                        fi
                                fi
                        else
                                echo "UNKNOWN: NTP critical offset is unknown"
                                exit 3;
                        fi
                else
                        echo "UNKNOWN: NTP warning offset is unknown"
                        exit 3;
                fi
                if [[ ! -z $warn_jitter ]];then
                        if [[ ! -z $crit_jitter ]];then
                                if [[ "$(echo $ntp_jitter '>' $warn_jitter | bc)" -eq 1 ]] && [[ "$(echo $ntp_jitter '<' $crit_jitter | bc)" -eq 1 ]];then
                                        jitter="NTP jitter is $ntp_jitter ms";
                                        jitter_perf=" ntp_jitter=$ntp_jitter"
                                        retval_3=1;
                                elif [[ "$(echo $ntp_offset '>' $crit_jitter | bc)" -eq 1 ]];then
                                        jitter="NTP jitter is $ntp_jitter ms";
                                        jitter_perf=" ntp_jitter=$ntp_jitter"
                                        retval_3=2;
                                else
                                        jitter="NTP jitter is $ntp_jitter ms";
                                        jitter_perf=" ntp_jitter=$ntp_jitter"
                                        retval_3=0;
                                fi
                        else
                                echo "UNKNOWN: NTP critical jitter is unknown"
                                exit 3;
                        fi
                else
                        echo "UNKNOWN: NTP warning jitter is unknown"
                        exit 3;
                fi
        else
                 echo "UNKNOWN: Critical values are unknown"
                 echo "Usage: check_ntp_peers warndelay,warnoffset,warnjitter critdelay,critoffset,critjitter"
                 exit 3;
        fi
else
        echo "UNKNOWN: Warning values are unknown"
        echo "Usage: check_ntp_peers warndelay,warnoffset,warnjitter critdelay,critoffset,critjitter"
        exit 3;
fi

if [[ "$retval_1" -eq 1 ]] || [[ "$retval_2" -eq 1 ]] || [[ "$retval_3" -eq 1 ]];then

        echo "WARNING: $delay $offset $jitter $delay_perf $offset_perf $jitter_perf"
        exit 1

elif [[ "$retval_1" -eq 2 ]] || [[ "$retval_2" -eq 2 ]] || [[ "$retval_3" -eq 2 ]];then

        echo "CRITICAL: $delay $offset $jitter $delay_perf $offset_perf $jitter_perf"
        exit 2

else

        echo "OK: $delay $offset $jitter $delay_perf $offset_perf $jitter_perf"
        exit 0

fi

Per prima cosa viene verificata la consistenza delle soglie di WARNING e CRITICAL per ciauscuno dei 3 valori monitorati (offset, jitter e delay), sia per quanto riguarda il numero di cifre utilizzate (5) che per ciò che concerne la coerenza logica (ad esempio il jitter/offset/delay di WARNING deve essere strettamente minore di quello CRITICAL).

A questo punto non ci rimane che configurare Nagios, editando, in prima istanza, il file /etc/nagios/objects/commands.cfg, dove verrà definito il comando che si avvarrà del suddetto plugin:

 # 'check_ntp_peers' command definition
define command{
        command_name check_ntp_peers
        command_line $USER1$/check_ntp_peers $ARG1$ $ARG2$
}

e successivamente associando uno specifico servizio all’host che rappresenta la nostra macchina, in modo da monitorare i valori associati all’NTP:

define service{
        use                             local-service         ; Name of service template to use
        host_name                       localhost
        service_description             NTP Peers Status
        check_command                   check_ntp_peers!80.000,2.000,2.000!90.000,3.000,3.000
        }

Facciamo il solito reload del nostro NMS:

[root@linuxbox ~]# service nagios reload

ed abbiamo finito.

Alla prossima.

PS: ho deciso di scrivere il suddetto scrip per sopperire alle limitazioni intrinseche del plugin Nagios (nativo) check_ntp_peer (senza la s finale). Nella fattispecie, quest’ultimo consente di ricavare solo ed esclusivamente il valore di offset associato alla sorgente di tempo remota e per funzionare è necessario che il server interrogato sia configurato in modo da rispondere alle query NTP (e quindi non solo alle richieste di sincronizzazione). Da notare che, nella stragrande maggioranza dei casi e per questioni di sicurezza, il server consentirà la sola sincronizzazione, ignorando gli altri tipi di query, come riportato nero su bianco (ad esempio) nella configurazione standard di ntpd:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

CentOS 6: monitorare le regole di auditing in modo proattivo mediante Nagios, NRDP e swatch

In questo post ed in quest’altro ho illustrato, rispettivamente, come configurare Nagios, NRDP e swatch per la ricezione dei check passivi e dei security alert.

Adesso vedremo come fare a monitorare in modo proattivo le regole di auditing definite in precedenza mediante il tool auditd (vedi qui per ulteriori dettagli).

Nagios_logo_blackIn soldoni, la configurazione si avvale di due passaggi:

1) creazione di un file da dare in pasto a swatch, nel quale sono definite le espressioni regolari in grado di identificare in modo univoco ciascun evento di auditing;

2) definizione dei servizi di Nagios per la ricezione dei check passivi.

Ecco uno stralcio della configurazione di swatch:

#time_changes auditing rule
watchfor /time_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='time_changes auditing rule' --output\='$_ | time_changes\=1'"
#system_locale_changes auditing rule
watchfor /system_locale_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='system_locale_changes auditing rule' --output\='$_ | system_locale_changes\=1'"
#shadow_changes auditing rule
watchfor /shadow_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='shadow-file auditing rule' --output\='$_ | shadow_changes\=1'"
#passwd_changes auditing rule
watchfor /passwd_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='passwd_changes auditing rules' --output\='$_ | passwd_changes\=1'"
#group_changes auditing rule
watchfor /group_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='group_changes auditing rule' --output\='$_ | group_changes\=1'"
#sudoers_changes auditing rule
watchfor /sudoers_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='sudoers_changes auditing rule' --output\='$_ | sudoers_changes\=1'"
#selinux_changes auditing rule
watchfor /selinux_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='selinux_changes auditing rule' --output\='$_ | selinux_changes\=1'"
#module_insertion auditing rule
watchfor /module_insertion/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='module_insertion auditing rule' --output\='$_ | module_insertion\=1'"
#webserver_watch_tmp auditing rule
watchfor /webserver_watch_tmp/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='webserver_watch_tmp auditing rules' --output\='$_ | webserver_watch_tmp\=1'"
#sshd_config auditing rule
watchfor /sshd_config/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='sshd_config auditing rules' --output\='$_ | sshd_config\=1'"
#httpd_config auditing rule
watchfor /httpd_config/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='httpd_config auditing rules' --output\='$_ | httpd_config\=1'"
#ntp_config auditing rule
watchfor /ntp_config/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='ntp_config auditing rules' --output\='$_ | ntp_config\=1'"
#iptables_config auditing rule
watchfor /iptables_config/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='iptables_config auditing rules' --output\='$_ | iptables_config\=1'"

Il comando da lanciare per rendere operativo il suddetto applicativo (che magari potremo inserire anche all’interno del file /etc/rc.local per l’avvio automatico dopo ogni riavvio della macchina) è il seguente:

swatch -c /etc/swatchaudit.conf -t /var/log/audit/audit.log --daemon

Di seguito, invece, riporto la configurazione dell’host di Nagios (localhost) per il quale occorre monitorare gli eventi di auditing:

define service{
        use                             local-service
        host_name                       localhost
        service_description             time_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             system_locale_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             shadow_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             group_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             sudoers_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             selinux_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             module_insertion auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             webserver_watch_tmp auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             sshd_config auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             httpd_config auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             ntp_config auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             iptables_config auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

Come al solito, lanciamo un reload di Nagios per rendere operative le suddette modifiche:

[root@linuxbox ~]# service nagios reload

ed abbiamo finito.

Alla prossima.

cURL: interagire con l’interfaccia Web dei dispositivi di rete mediante linea di comando

Spesso e volentieri abbiamo a che fare con delle macchine *nix sprovviste di Desktop Enviroment (altrimenti conosciuto come server X), attraverso le quali è necessario accedere all’interfaccia Web di alcuni dispositivi di rete SOHO, in modo da effettuare le classiche operazioni di management (cambio di configurazione, riavvio, ecc.).

A tal proposito, esiste un tool molto potente da utilizzare mediante CLI, che prende il nome di cURL.

curlAdesso vedremo quali sono le analisi preliminari che ci permetteranno di capire se l’interfaccia Web con cui vogliamo interagire potrà essere manipolata tramite cURL o meno.

Analisi del codice sorgente

Il primo step consiste nello scaricare il codice sorgente dalla pagina, utilizzando le giuste credenziali di accesso (se previste). Ad esempio:

[root@linuxbox ~]# curl -u username:password http://192.168.1.1

A questo punto possiamo distinguere due macro casi:

1) la pagina Web contiene prevalentemente del codice HTML ed i cambi di configurazione possono essere effettuati mediante dei semplici form e l’invio dei dati attraverso HTTP POST o GET. In tal caso siamo stati fortunati e potremo procedere;

2) la pagina Web contiene soprattutto del codice javascrip e tutte le operazioni di management si avvalgono del suddetto codice. In questo caso siamo stati sfortunati e dovremo demordere, in quanto cURL non supporta javascrip.

Poniamoci quindi nel caso 1 e procediamo.

Per prima cosa occorre analizzare il codice sorgente della pagina di interesse andando alla ricerca dei tag:

<form></form>

all’interno dei quali è presente l’attributo action che punta alla pagina Web che si occuperà di processare i dati del form. Ad esempio:

 
<form action="apply.cgi" method="post">
<input type="hidden" name="page" value="device.asp">

    <input type="submit" name="action" value="Reboot">
</form>

Inoltre, bisogna capire quali e quanti campi di input (con relativo valore), identificati mediante gli attributi id o name, è necessario sottoporre alla suddetta pagina Web. Infatti, molto spesso, come misura molto blanda per contrastare alcuni attacchi Web quali il CSRF (vedi qui per ulteriori dettagli), vengono utilizzati dei campi di input di tipo hidden da inviare insieme al contenuto degli altri campi del form.

Una volta capito quali sono i campi da inoltrare alla pagina specificata dall’attributo action del form HTML (magari utilizzando il classico metodo trial-and-error), possiamo procedere con il loro inoltro vero e proprio, avvalendoci, ad esempio, del seguente comando:

curl -u username:password -s -d "action=Reboot&page=device.asp" http://192.168.1.1/apply.cgi

Nella fattispecie, la pagina che si occuperà di processare i dati è apply.cgi, mentre i campi di input inviati sono action, il cui valore è Reboot, e page, il cui valore è device.asp. Da notare che le suddette informazioni sono state inviate in formato querystring (ovvero utilizzando il carattere & di concatenazione).

Infine, occorre precisare che la flag -s evita di inviare allo standard output le statistiche relative al processamento della pagina richiesta, mentre la flag -d (data) è quella che ci permette di inviare i dati attraverso un semplice HTTP POST.

Per ora è tutto. Alla prossima.

CentOS 6: configurare delle regole di auditing mediante auditd

In questo post ho accennato all’importanza che le operazioni di auditing ricoprono durante la messa in sicurezza dei nostri server.

Nella fattispecie, per la distro CentOS 6, l’applicativo che si occupa di “monitorare” (inteso come controllo degli accessi ed accounting) il sistema operativo, prende il nome di auditd.

Vedremo adesso come fare a configurare delle regole di auditing secondo le nostre esigenze, come ricercare determinati eventi negli appositi file di log e come creare dei report giornalieri (da inviare via email al nostro indirizzo di posta) contenenti l’insieme degli eventi di auditing individuati.

audit

Creazione delle regole

Per effettuare tale operazione è necessario utilizzare il tool auditctl. Esso è in grado di creare delle regole il cui scopo è quello di monitorare le operazioni (lettura, scrittura, esecuzione e modifica degli attributi) su un dato file o su di una specifica directory. Non solo: sarà possibile anche configurare dei meccanismi di monitoraggio delle chiamate di sistema (in gergo SYSCALL) che vengono eseguite durante il normale funzionamento della nostra macchina.

Ecco alcuni esempi di regole per il monitoraggio delle SYSCALL:

[root@linuxbox ~]# auditctl -a always,exit -F arch=b64 -S settimeofday -k time_changes
[root@linuxbox ~]# auditctl -a always,exit -F arch=b64 -S clock_settime -k time_changes
[root@linuxbox ~]# auditctl -a always,exit -F arch=b64 -S sethostname -S setdomainname -k system_locale_changes

In particolare, vengono monitorate le chiamate di sistema settimeofday, clock_settime, sethostname e setdomainname (specificate mediante la flag -S), le quali indicano palesemente delle modifiche macroscopiche relative alla configurazione del sistema operativo. Occorre precisare, inoltre, che è stato necessario indicare (mediante la flag -F) l’architettura della CPU (recuperabile mediante il comando uname -m), poichè i codici numerici che identificano ciascuna SYSCALL variano a seconda che si tratti di una x86 (32 bit) oppure di una x86_64 (64 bit). Qui trovate la lista delle chiamate di sistema per x86 e qui trovate quella per x86_64.

Per il monitoraggio di file e directory l’opzione da utilizzare è -w, seguita dal nome del file (o della directory) di interesse. Inoltre, mediante la flag -p, potranno essere specificate le operazioni di cui tenere traccia (a per modifica degli attributi, x per esecuzione, w per scrittura ed r per lettura). Infine, mediante la flag -k sarà possibile associare un’etichetta a ciascuna regola di auditing precedentemente definita. Eccco alcuni esempi:

[root@linuxbox ~]# auditctl -w /etc/shadow -p wa -k shadow-file
[root@linuxbox ~]# auditctl -w /etc/passwd -p wa -k passwd_changes
[root@linuxbox ~]# auditctl -w /etc/group -p wa -k group_changes
[root@linuxbox ~]# auditctl -w /etc/sudoers -p wa -k sudoers_changes
[root@linuxbox ~]# auditctl -w /etc/selinux/ -p wa -k selinux_changes
[root@linuxbox ~]# auditctl -w /sbin/insmod -p x -k module_insertion
[root@linuxbox ~]# auditctl -w /tmp -p x -k webserver_watch_tmp
[root@linuxbox ~]# auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config
[root@linuxbox ~]# auditctl -w /etc/httpd/conf/httpd.conf -p wa -k httpd_config
[root@linuxbox ~]# auditctl -w /etc/ntp.conf -p wa -k ntp_config

Possiamo, inoltre, elencare le regole finora definite utilizzando il comando:

[root@linuxbox ~]# auditctl -l

il cui output sarà simile al seguente:

-a always,exit -F arch=x86_64 -S settimeofday -F key=time_changes
-a always,exit -F arch=x86_64 -S clock_settime -F key=time_changes
-a always,exit -F arch=x86_64 -S sethostname,setdomainname -F key=system_locale_changes
-w /etc/shadow -p wa -k shadow-file
-w /etc/passwd -p wa -k passwd_changes
-w /etc/group -p wa -k group_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/selinux/ -p wa -k selinux_changes
-w /sbin/insmod -p x -k module_insertion
-w /tmp/ -p x -k webserver_watch_tmp
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/httpd/conf/httpd.conf -p wa -k httpd_config
-w /etc/ntp.conf -p wa -k ntp_config
-w /etc/sysconfig/iptables -p wa -k iptables_config

Ricerca degli eventi

Il file di log in cui vengono salvati gli eventi di auditing è /var/log/audit/audit.log. Attraverso l’applicativo ausearch, che punta al suddetto file, è possibile effettuare delle ricerche mirate specificando il file di interesse, ad esempio:

[root@linuxbox ~]# ausearch -f /etc/passwd

oppure l’etichetta precedentemente assegnata all’evento:

[root@linuxbox ~]# ausearch -k webserver_watch_tmp

Generazione dei report

E’ possibile generare dei report contenenti gli eventi di auditing di interesse. Per fare ciò è sufficiente utilizzare l’applicativo aureport, comprensivo di flag -k, -ts (time start) e -te (time end). Ad esempio:

aureport -k -ts yesterday 00:00:00 -te yesterday 23:59:59

Per schedulare il suddetto report ad intervalli di tempo regolari (ad esempio ogni giorno) e fare in modo di riceverlo sulla propria casella di posta elettronica, è necessario creare un apposito file di cronjob all’interno della directory /etc/cron.d:

[root@linuxbox cron.d]# nano ausearchreport

il cui contenuto dovrà essere:

MAILTO=vostro.indirizzo@email.it

00    00   * * *     root          /sbin/aureport -k -ts yesterday 00:00:00 -te yesterday 23:59:59

Da notare che tutte le regole precedentemente create mediante auditctl hanno durata temporanea (ovvero vengono eliminate dopo un reboot). Per renderle quindi permanenti, occorre inserirle all’interno del file /etc/audit/audit.rules, il cui contenuto dovrà essere simile al seguente:

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page

-a always,exit -F arch=b64 -S settimeofday -k time_changes
-a always,exit -F arch=b64 -S clock_settime -k time_changes
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k system_locale_changes
-w /etc/shadow -p wa -k shadow-file
-w /etc/passwd -p wa -k passwd_changes
-w /etc/group -p wa -k group_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/selinux/ -p wa -k selinux_changes
-w /sbin/insmod -p x -k module_insertion
-w /tmp -p x -k webserver_watch_tmp
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/httpd/conf/httpd.conf -p wa -k httpd_config
-w /etc/ntp.conf -p wa -k ntp_config
-w /etc/sysconfig/iptables -p wa -k iptables_config

# Disable adding any additional rules - note that adding new rules will require a reboot
-e 2

Come si può facilmente notare, in coda alla lista ho aggiunto l’opzione -e 2 che impedisce l’aggiunta di nuove regole on-the-fly (per questioni di sicurezza).

E’ sufficiente quindi restartare il demone auditd per rendere operative le suddette regole:

[root@linuxbox ~]# service auditd restart

Per ora è tutto. Nei prossimi post vedremo come monitorare in modo proattivo le regole di auditing mediante swatch, NRDP e Nagios.

Alla prossima.