Archivi tag: linux

Mettere in ascolto snmpd su un’interfaccia specifica

SO: Linux, , , , ,

Recentemente ho riscontrato diverse grane con il demone snmpd installato su una macchina CentoOS 5.

snmpLogo.jpg

Durante le operazioni di troubleshooting ho deciso di mettere in ascolto il demone in questione su una specifica interfaccia, avendo a che fare con un host dual-homed. Per la precisione, tale host presentava due interfacce di rete più una loopback, ovvero:

eth0 IP 10.0.0.1

eth1 IP 192.168.2.1

lo IP 127.0.0.1

Dove la eth1 è utilizzata per l’heartbeat del cluster.

Lanciando un netstat -ano | grep :161 ottenevo il seguente output:

udp        0      0 0.0.0.0:161                 0.0.0.0:*                               off (0.00/0/0)

Ciò significava che il demone stava in ascolto su tutte le interfacce. Ad ulteriore riprova di ciò lanciavo un snmpwalk -v2c -c publickey dapprima diretto verso l’IP dell’eth0, poi verso l’IP dell’eth1 ed infine verso l’IP della loopback. In tutti casi alla query era seguita una risposta.

Bene, decidevo quindi che l’snmpd doveva rimanere in ascolto solo sull’IP dell’eth0. Mi posizionavo dunque nella directory /etc/init.d ed accedevo al file snmpd mediante un editor di testo:

 [nightfly@linuxbox ~]# cd /etc/init.d
 [nightfly@linuxbox init.d]# nano snmpd

Nella fattispecie, la riga di mio interesse era la seguente:

OPTIONS="-LS4d -Lf /dev/null -p /var/run/snmpd.pid -a"

Che ho modificato nel seguente modo:

OPTIONS="-LS4d -Lf /dev/null -p /var/run/snmpd.pid 10.0.0.1 -a"

Successivamente, riavviavo il demone snmp mediante il comando:

[nightfly@linuxbox init.d]# service snmpd restart

e verificavo che fosse effettivamente attivo lanciando il comando:

[nightfly@linuxbox init.d]# service snmpd status

ottenendo come output:

snmpd (pid  2499) is running...

Tutto sembrava funzionare alla grande. Verificavo infine che il demone fosse in ascolto solo sull’indirizzo 10.0.0.1:

udp        0      10.0.0.1:161                 0.0.0.0:*                               off (0.00/0/0)


Con mio grande piacere constatavo che finalmente snmpd stava in ascolto su una sola interfaccia, eliminando il problema dei continui restart dello stesso.

A presto.

Script per il backup automatico della configurazione di un firewall Cisco PIX 501

Networking, , , , , ,

In questo post ho riportato uno scrip 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.

pix501

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 "$password1\r"
 expect "Password:"
 send "$password2\r"
 expect ">"
 send "ena\r"
 expect "Password:"
 send "$password\r"
 expect "#"
 send "write net\r"
 expect "#"
 send "exit\r"
 expect eof

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.

Monitorare rsyslogd mediante Nagios

Networking, , , , ,

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

nagios.gif

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

Logging del traffico droppato da iptables

Sicurezza, , , ,

Qualsiasi firewall che si rispetti, oltre a dover filtrare il traffico secondo le regole definite dall’utente, deve mettere a disposizione un buon meccanismo di logging. In tal senso, iptables rientra a pieno titolo tra i firewall degni nota.

In particolare, il firewall in questione consente di loggare il traffico mediante rsyslogd, variante del celeberrimo syslogd, ovvero il demone *nix che si occupa del salvataggio dei log. Ma vediamo come realizzare il logging attraverso iptables.

Per prima cosa, dobbiamo decidere cosa loggare. Potremmo infatti “registrare” tutto il traffico che attraversa il firewall, oppure concentrarci esclusivamente sul traffico droppato. Personalmente ritengo che, per le reti di piccola dimensione, la seconda scelta sia sicuramente la migliore.

Ora, poichè iptables interpreta le regole seguendo una logica top-down, affinchè il traffico possa essere loggato è necessario fare in modo che i pacchetti vengano registrati immediatamente prima di essere scartati.

Quindi, il giusto ordine delle rule dovrebbe essere il seguente:

iptables -A INPUT -s 10.0.0.0/8 -i eth1 -j LOG --log-prefix "Spoofed traffic detected: " --log-level 4
iptables -A FORWARD -s 10.0.0.0/8 -i eth1 -j LOG --log-prefix "Spoofed traffic detected: " --log-level 4

iptables -A INPUT -s 10.0.0.0/8 -i eth1 -j DROP
iptables -A FORWARD -s 10.0.0.0/8 -i eth1 -j DROP

Come potete notare, prima ho loggato il traffico spoofato e solo dopo ho scartato i pacchetti incriminati. Inoltre, alcuni parametri interessanti per il logging che ho utilizzato nelle regole precedenti sono:

–log-prefix, che ci permette di identificare più facilmente i log relativi ai pacchetti droppati dal firewall (il prefisso può essere costituito da un massimo di 29 caratteri);

–log-level, che ci consente di definire la “pericolosità” degli eventi registrati dal firewall.

Nella fattispecie, i log level utilizzati da rsyslogd sono i seguenti:

level    verbose     explanation
 0         emerg       system is unusable
 1         alert          action must be taken immediately
 2         crit            the system is in a critical condition
 3         err            there is an error condition
 4         warning    there is a warning condition
 5         notice       a normal but significant condition
 6         info          a purely informational message
 7        debug       messages generated to debug the application

Detto ciò, per il logging dei pacchetti droppati da iptables ho utilizzato un livello 4, ovvero warning.

Creiamo ora il file di log vero e proprio, in cui verranno salvati gli eventi intercettati dal firewall:

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

Infine, modifichiamo il file di configurazione di rsyslogd:

nightfly@nightbox:~$ sudo nano /etc/rsyslog.d/50-default.conf

ed inseriamo la seguente stringa:

kern.warning                 /var/log/iptables.log

da posizionare subito prima di

kern.*                          -/var/log/kern.log

Riavviamo rsyslogd digitando:

nightfly@nightbox:~$ sudo service rsyslog restart

ed il gioco è fatto.

A presto.

PIX 501 e logging su una linux box

Networking, , , ,

Un’operazione fondamentale nell’ambito dell’amministrazione di rete o di sistema consiste nella raccolta dei log e nella successiva analisi degli stessi.

Ora, tale raccolta può avvenire localmente (ovvero direttamente sui dispositivi di rete interessati) e/o nell’ambito di server dedicati, detti logserver. E’ buona pratica, prima di mettere in produzione uno o più di questi server specializzati nella raccolta dei log, effettuare un hardening del sistema, oltre ad adottare politiche di accesso ristretto. Ciò si rende necessario poichè i log devono rimanere intatti e devono essere protetti da eventuali operazioni di tampering (manomissione, alterazione) messe in atto da un possibile attaccante.

Dopo questa breve premessa, vediamo come abilitare il logging remoto su una linux box e come reindirizzare le informazioni registrate dal nostro firewall (nella fattispecie un PIX 501) verso il logserver stesso.

Linux Box

Per prima cosa occorre accedere in scrittura al file syslogd presente nella directory /etc/default:

nightfly@nightbox:~$ sudo nano /etc/default/syslogd

A questo punto dovremmo visualizzare la seguente stringa:

SYSLOGD=””

alla quale dovremo aggiungere le opzioni -r e -m 0:

SYSLOGD=”-r -m 0″

Nella fattispecie, -r abilita il logging remoto mentre -m 0 evita di visualizzare ogni tot minuti (20 per default) entry del tipo — MARK — (una sorta di keepalive) all’interno del file di log.

Ora accediamo al file /etc/syslog.conf:

nightfly@nightbox:~$ sudo nano /etc/syslog.conf

ed aggiungiamo la seguente stringa:

local4.4 /var/log/pix.log

dove local4 è il nome usato da syslogd (ovvero il demone che effettua le operazioni di logging) per identificare il firewall, mentre il 4 dopo il . indica il livello di logging che deve essere applicato per il dispositivo di rete in questione. In particolare, i livelli di logging utilizzabili sono i senguenti:

0 – Emergency (emerg)
1 – Alerts (alert)
2 – Critical (crit)
3 – Errors (err)
4 – Warnings (warn)
5 – Notification (notice)
6 – Information (info)
7 – Debug (debug)

Maggiore è il livello di logging, più precise saranno le informazioni salvate. Da notare che ad una maggiore precisione corrisponde un maggior numero di dati registrati, con conseguente saturazione dei file di log in tempi piuttosto brevi (ecco perchè nell’esempio ho scelto il livello 4 e non il livello 7).

Per ciò che concerne la stringa:

/var/log/pix.log

essa specifica il file in cui dovranno essere raccolte le informazioni provenienti dal PIX.

Poichè stiamo utilizzando un file dedicato, è inutile salvare tali informazioni anche su /var/log/syslog. Per fare quindi in modo che ciò non avvenga devo aggiungire la stringa:

local4.none

nelle varie sezioni del file syslog.conf. Ad esempio:

*.*;auth,authpriv.none,local4.none -/var/log/syslog

per la sezione dedicata ai tentativi di autenticazione, oppure:

*.=debug; auth,authpriv.none; news.none;mail.none -/var/log/debug local4.none

per la sezione dedicata alle informazioni di livello 7 (debug), e così via.

Per evitare che il file di log dedicato al PIX raggiunga dimensioni eccessive è buona norma attivare il logrotate. Occorre dapprima creare il file pix nella directory /etc/logrotate.d/

nightfly@nightbox:~$ sudo nano /etc/logrotate.d/pix

ed all’interno di tale file aggiungere le seguenti direttive:

/var/log/pix.log {

rotate 7

daily

compress

missingok

notifempty

}

Nella fattispecie, ogni giorno (daily) verrà generato un nuovo file pix.log, archiviando automaticamente il logfile del giorno precedente. Inoltre, la durata degli archivi è pari ad una settimana (rotate 7), dopodichè essi verranno cancellati.

Riavviamo syslogd per rendere effettive le nuove impostazioni:

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

Verifichiamo che il nostro logserver sia effettivamente in ascolto, digitando:

nightfly@nightbox:~$ sudo nmap -sU localhost

Se visualizzeremo il seguente output:

514/udp  open|filtered syslog

significa che la linux box è pronta a ricevere i log provenienti dal PIX.

PIX 501

Non ci resta che abilitare il logging sul PIX, specificando l’indirizzo del logserver:

firewall(config)# logging on
firewall(config)# logging timestamp
firewall(config)# logging trap informational
firewall(config)# logging facility 20
firewall(config)# logging host inside <ip del logserver>

Salviamo le nuove impostazioni mediante il comando

firewall(config)# write mem

ed abbiamo finito. See ya.

Aggiornamento

Se state utilizzando rsyslog anzichè il classico syslog non dovete apportare alcuna modifica al file /etc/default/syslogd, in quanto tale procedura risulta obsoleta. Piuttosto, dovete mettere mano al file /etc/rsyslog.conf:

nightfly@nightbox:~$ sudo nano /etc/rsyslog.conf

ed in seguito decommentare le stringhe:

$ModLoad imudp
$UDPServerRun 514

Riavviate dunque rsyslog digitando:

nightfly@nightbox:~$ sudo service rsyslog restart

ed avete finito.

Apache 2: abilitare SSL

SO: Linux, , , , ,

In questo post abbiamo visto come configurare LAMP. Adesso vedremo come abilitare SSL sul nostro server Web Apache.

Per prima cosa è necessario generare un certificato SSL. A tale scopo possiamo utilizzare openSSL:

nightfly@nightbox:/etc/apache2$ sudo openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/apache.pem -keyout /etc/apache2/apache.pem

dove il parametro -x509 indica proprio che si tratta di un certificato appartenente allo standard X.509 ed il parametro -days specifica la durata della validità relativa al certificato stesso.

Una volta digitato il comando sopra citato verrà richiesto l’inserimento di tutta una serie di parametri necessari per caratterizzare il certificato stesso, quali nazione, città, nome della società, indirizzo e-mail, ecc.

Ora occorre abilitare il modulo SSL di Apache, sfruttando il tool a2enmod (apache2 enable module):

nightfly@nightbox:/etc/apache2$ sudo a2enmod ssl

E’ necessario, inoltre, abilitare il virtual host SSL:

nightfly@nightbox:/etc/apache2$ sudo a2ensite default-ssl

Fatto ciò sarà necessario mettere in ascolto Apache sulla porta 443 (HTTPS), editando il file ports presente nella DIR /etc/apache2/ports. Il file in questione dovrà apparire nel seguente modo:

nightfly@nightbox:/etc/apache2$ cat ports.conf
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

NameVirtualHost *:80
Listen 80

<IfModule mod_ssl.c>
# SSL name based virtual hosts are not yet supported, therefore no
# NameVirtualHost statement here
Listen 443
</IfModule>

Posizioniamoci ora sulla cartella available-sites:

nightfly@nightbox:/etc/apache2$ cd sites-available/

ed editiamo il file default-ssl aggiungendo le seguenti righe di codice:

 SSLEngine On
 SSLCertificateFile /etc/apache2/apache.pem

e rimuovendo:

SSLCertificateFile /etc/ssl/private/ssl-cert-snakeoil.key

Riavviamo Apache mediante il comando:

nightfly@nightbox:/etc/apache2$ /etc/init.d/apache2 restart

E colleghiamoci al nostro server anteponendo HTTPS (e non HTTP) all’indirizzo. Accettiamo il certificato (anche se il browser lo segnala come inattendibile)… et voilà, siamo dentro il nostro sito Web.

A presto.

Creazione di un utente FTP ed assegnazione di una directory

SO: Linux, , ,

Gestendo un piccolo server Web casalingo (rigorosamente su piattaforma Linux), ho avuto la necessità di creare un utente apposito, in modo da poter effettuare da rete esterna l’upload via FTP delle pagine aggiornate. Quindi, per prima cosa ho creato l’utente mediante il comando useradd:

nightfly@nightbox:~$ sudo useradd userupload

Successivamente, all’utente appena creato ho assegnato una password attraverso il comando passwd:

nightfly@nightbox:~$ passwd userupload

Dopo aver fatto ciò, ho modificato la directory di default relativa a tale utente:

nightfly@nightbox:~$ usermod -d /var/www/sito userupload

ed infine ho cambiato la ownership di tale cartella:

nightfly@nightbox:~$ chown userupload:userupload /var/www/sito

Ecco fatto, ora siamo pronti a caricare le pagine aggiornate sul nostro sito web.

PS: Ovviamente, affinchè l’upload vada a buon fine è necessaria una corretta configurazione del firewall della vostra rete (sempre se ne avete uno) e del router, mettendo in forwarding la porta 21, protocollo TCP (supponendo che usiate FTP solo in modalità passiva).

Ci aggiorniamo, bye.

ddclient: DNS dinamico per Linux

SO: Linux, , ,

Può capitare che il nostro router non supporti il DNS dinamico, rendendo difficile (se non impossibile) l’accesso alla nostra rete da remoto. Infatti, generalmente i service provider assegnano alla semplice utenza casalinga degli indirizzi IP dinamici, i quali possono cambiare (e generalmente lo fanno) ad ogni disconnessione del router/modem, anche se breve (dipende dalla congestione della centralina). Come risolvere questo problema? Semplice, basta installare sul nostro server Linux un semplice programmino, ovvero ddclient. Esso, appoggiandosi su un sito che permette la creazione di domini gratuiti di secondo livello (vedi dyndns.com), riesce a stabilire una corrispondenza biunivoca tra il dominio stesso ed il nostro indirizzo IP, così da permetterci di accedere alla nostra rete anche dopo eventuali cambiamenti di IP.

Vediamo ora come installare ddclient (per Linux Kubuntu):

nightfly@nightbox:~$ sudo apt-get install ddclient

Successivamente passiamo alla configurazione dello stesso editando il file ddclient.conf presente nella directory /etc:

nightfly@nightbox:~$ sudo nano /etc/ddclient.conf

Ci apparirà una schermata simile alla seguente:

# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf

pid=/var/run/ddclient.pid
protocol=dyndns2
use=web
server=members.dyndns.org
login=<username>
password='<password>'
<vostro dominio>

dove la variabile use=web impone a ddclient l’individuazione del nostro indirizzo IP mediante il sito del gestore (nel nostro caso dyndns.org). Alla variabile login occorre associare lo username che utilizziamo per accedere a dyndns.org (stesso discorso vale per la password, che però deve essere racchiusa tra due apici). Infine sostituiamo <vostro dominio> con il dominio dinamico che avete creato (ad esempio ciao.homeip.net).

Provate ora a disconnettervi momentaneamente, ovvero fino a quando non vi sarà assegnato un nuovo indirizzo IP. Riconnettetevi e dopo qualche istante eseguite un ping verso il vostro dominio:

nightfly@nightbox:~$ ping ciao.homeip.net

Se otterrete risposta vuol dire che ddclient sta funzionando correttamente.

La mini-guida termina qui. A presto.

Installare e configurare Snort 2.8.4 su Kubuntu 9.04

Sicurezza, , , , ,

Recentemente ho notato (con mio sommo dispiacere) che l’unica versione di Snort installabile su Kubuntu 9.04 mediante repository è la 2.7.x. Peccato però che tale versione non sia più supportata; ecco allora che ho pensato bene di rimuoverla dal mio sistema ed installare, previa compilazione, la versione 2.8.4.

snort1sm.jpg

Per prima cosa occorre scaricare la tarball in cui sono contenuti i sorgenti di Snort (seguite questo link). Fatto ciò controllate, prima di partire con la compilazione vera a propria, che tutte le dipendenze (librerie e compagnia bella) necessarie al software in questione siano soddisfatte. A tal proposito bisogna posizionarsi nella cartella in cui abbiamo precedentemente salvato la tarball e lanciare il comando:

tar -xzvf /home/nightfly/snort-2.8.1.tar.gz

Una volta estratti i file accediamo alla directory appena creata

cd /home/nightfly/snort-2.8.1

Bene, adesso lanciamo il comando ./configure che servirà proprio a verificare che tutte le dipendenze siano soddisfatte. Solitamente le librerie che Snort richiede sono libpcap0.8-dev e libpcre3-dev. Entrambe possono essere installate digitando:

sudo apt-get install libpcap0.8-dev

sudo apt-get install libpcre3-dev

Se la procedura di configurazione avviata in precedenza va a buon fine, possiamo usare il comando:

make

per compilare i sorgenti e successivamente

make install

per effettuare l’installazione vera e propria di Snort.

Creiamo la directory in cui andrà inserito il file di configurazione relativo a Snort, le regole di rilevamento delle intrusioni (rules) ed altri file necessari al corretto funzionamento dell’applicativo in questione:

sudo mkdir /etc/snort

sudo mkdir /etc/snort/rules

Andiamo a creare, inoltre, la directory in cui Snort salverà i log delle intrusioni

sudo mkdir /var/log/snort

Sempre dalla cartella in cui abbiamo estratto la tarball lanciamo il comando

rm Makefile Makefile.in Makefile.am

e successivamente

sudo cp etc /etc/snort

Passiamo adesso alla configurazione di Snort, la quale può essere effettuata mediante la modifica ad hoc del file snort.conf posizionato nella dir /etc/snort.

sudo nano /etc/snort/snort.conf

Impostiamo il valore della variabile HOME_NET con la classe di indirizzi IP utilizzata nell’ambito della nostra LAN, mentre nella variabile EXTERNAL_NET andreamo a sostituire any con !$HOME_NET. In questo modo stiamo dicendo a Snort di considerare come indirizzi esterni alla nostra LAN (e quindi sorgenti di potenziali attacchi) tutti quelli che non rientrano nella classe associata ad HOME_NET. Modifichiamo inoltre la variabile RULE_PATH assegnandogli il valore /etc/snort/rules.

Questa piccola modifica del file di configurazione ci consente di fare in modo che Snort inizi ad effettuare il monitoraggio della nostra rete in modo corretto. E’ possibile comunque adattare ulteriormente Snort alle nostre esigenze andando a modificare la sezione relativa ai cosiddetti “preprocessori”, quali, ad esempio, http_inspect (per l’individuazione di attacchi basati sul protocollo HTTP) oppure sfportscan (per la rilevazione dei portscan).

Passiamo adesso al download delle rules, necessario affinche Snort ci segnali eventuali tentativi di intrusione. Tale operazione può essere eseguita utilizzando un semplice programmino a linea di comando, ovvero oinkmaster. Non perdiamo tempo ed installiamolo:

sudo apt-get install oinkmaster

Per poter installare le rules è necessario dapprima registrarsi sul sito snort.org e successivamente procedere con la generazione di un oinkcode (ovvero di un digest MD5) che ci identifica univocamente. In particolare, sarà possibile fare ciò andando qui (previo login) e cliccando sul pulsante Generate code.

Fatto ciò passiamo alla modifica del *.conf ad esso associato.

sudo nano /etc/oinkmaster.conf

e inseriamo la seguente stringa:

url = http://www.snort.org/pub-bin/oinkmaster.cgi/<nostro_oinkcode>/snortrules-snapshot-2.8.tar.gz

Una volta completati download ed installazione delle rules, possiamo avviare Snort in modalità “test” per verificarne il corretto funzionamento. Digitiamo quindi:

sudo snort - T -c /etc/snort/snort.conf

e se ricevete la seguente stringa in output

 Snort sucessfully loaded all rules and checked all rule chains!
 Snort exiting

avete la prova che Snort sta funzionando correttamente. Un altro test che potrebbe tornare utile è quello che ci permette di visualizzare in tempo reale i pacchetti sniffati da snort:

sudo snort -c /etc/snort/snort.conf -v

Ora non ci resta che eseguire automaticamente Snort ad ogni avvio del sistema, possibilmente in modalità demone, ovvero in background. Per fare ciò andiamo ad editare il file rc.local presente nella directory /etc:

sudo nano /etc/rc.local

e successivamente inseriamo la stringa

sudo snort -c /etc/snort/snort.conf -i eth1 -l /var/log/snort -D

dove la flag -D specifica proprio l’esecuzione in background.

Infine, se ad esempio volessimo effettuare il download e l’aggiornamento delle rules ogni ora, possiamo procedere con la creazione di una regola per cron, mediante l’editing del file crontab:

sudo nano /etc/crontab

e digitiamo

0  *    * * *   root    oinkmaster -o /etc/snort/rules/

Bene, adesso Snort è configurato e pronto per l’uso. A presto.

PS: ho realizzato un piccolo programmino che invia, mediante SMS, gli alert generati da Snort. Per ulteriori informazioni non esitate a contattarmi.

PPS: è possibile effettuare download dal sito Snort.org solo ad intervalli (minimi) di quindici minuti, ergo non impostate regole di cron che agiscano troppo frequentemente.