Archivi tag: logging

Apache virtual host su IP pubblico dedicato

SO: Linux, , , , , , , , , ,

Scenario

Un virtual host di Apache che deve essere accessibile solo da determinati indirizzi IP pubblici.

Problema

Sulla macchina sono presenti anche altri virtual host “pubblici”.

Soluzione

Mettere in bind il virtual host in oggetto su un indirizzo IP pubblico dedicato e successivamente creare delle regole ad hoc mediante Iptables.

 

apache,virtual host,httpd,bind,virtual interface,dedicated public ip,private access,logging,syslogd,iptables,rc.local

Per prima cosa occorre creare un’interfaccia virtuale da associare all’indirizzo IP pubblico dedicato. Su CentOS tale operazione è piuttosto banale e consta dei seguenti passi:

1) Creo il file contenente i parametri dell’interfaccia all’interno della directory /etc/sysconfig/network-scrips/:

[root@server network-scrips]# sudo nano ifcfg-eth0:0

il cui contenuto dovrà essere simile al seguente:

 DEVICE=eth0:0
 ONBOOT=yes
 HWADDR=
 IPADDR=<indirizzo IP pubblico>
 NETMASK=<netmask>
 BROADCAST=<indirizzo di broadcast>
 GATEWAY=<indirizzo del default gw>
 NETWORK=
 TYPE=Ethernet

2) Attivo l’interfaccia virtuale e mi sincero che sia effettivamente operativa:

[root@server network-scrips]# ifup eth0:0

[root@server network-scrips]# ifconfig

il cui output dovrebbe essere simile al seguente:

eth0:0    Link encap:Ethernet  HWaddr <mac address>
           inet addr:<indirizzo IP>  Bcast:<indirizzo di broadcast>  Mask:<netmask>
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           Interrupt:169 Memory:fb5e0000-fb600000

Successivamente creo la configurazione del virtual host all’interno della directory /etc/httpd/vhosts.d/:

[root@server vhosts.d]# nano privatevhost.conf

il cui contenuto dovrà essere:

Listen <ip pubblico assegnato all'interfaccia virtuale>:80
NameVirtualHost <ip pubblico assegnato all'interfaccia virtuale>:80

<VirtualHost <ip pubblico assegnato all'interfaccia virtuale:80>
  ServerName privatevhost.dominio.com
  ServerAlias privatevhost.dominio.com

  DocumentRoot /var/www/virtual/privatevhost.dominio.com/htdocs

  ErrorLog /var/www/virtual/privatevhost.dominio.com/logs/error.log
  CustomLog /var/www/virtual/privatevhost.dominio.com/logs/access.log combined
  #ServerSignature Off

  Redirect 404 /favicon.ico

  <Location /favicon.ico>
   ErrorDocument 404 "No favicon"
  </Location>

</VirtualHost>

Lancio un reload della configurazione di Apache per rendere effettive le suddette modifiche:

[root@server vhosts.d]# service httpd reload

A questo punto posso procedere con la creazione dei filtri di accesso mediante iptables:

iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

iptables -A INPUT -s <IP sorgente consentito>/32 -d <IP pubblico assegnato all'interfaccia virtuale>/32 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -s <IP sorgente consentito>/32 -d <IP pubblico assegnato all'interfaccia virtuale>/32 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -s <IP sorgente consentito>/32 -d <IP pubblico assegnato all'interfaccia virtuale>/32 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -s <IP sorgente consentito>/32 -d <IP pubblico assegnato all'interfaccia virtuale>/32 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -d <IP pubblico assegnato all'interfaccia virtuale>/32 -j LOG  --log-prefix "Private Area Access Attempt:" --log-level 4
iptables -A INPUT -d <IP pubblico assegnato all'interfaccia virtuale>/32 -p ICMP -j ACCEPT
iptables -A INPUT -d <IP pubblico assegnato all'interfaccia virtuale>/32 -j DROP

exit 0

In soldoni, ho prima consentito l’accesso via Web al suddetto virtual host solo a determinati indirizzi IP pubblici. Successivamente ho impostato una regola per il logging dei tentativi di accesso non autorizzati, consentendo solo il traffico ICMP (aka ping) proveniente da qualunque indirizzo sorgente (per questione di praticità durante le eventuali operazioni di diagnostica).

Infine ho droppato tutto il traffico diretto all’interfaccia virtuale che non rispetta nessuna delle regole definite in precedenza.

Copio le suddette regole all’interno del file /etc/rc.local per renderle attive anche dopo eventuali reboot della macchina e facciamo alcuni test per verificare che tutto funzioni correttamente (tentativo di accesso via Browser al virtual host, prima da indirizzo IP consentito e successivamente da indirizzo IP non consentito).

Inoltre, per loggare i tentativi di accesso non autorizzati, occorre modificare la configurazione del file syslog.conf, aggiungendo la seguente entry all’inizio del file in questione:

kern.warning                                    /var/log/iptables.log

Infine, lancio un restart del demone di logging:

[root@server vhosts.d]# service syslog restart

E’ tutto, alla prossima.

Logging con Varnish Cache

SO: Linux, , , , , , , , ,

In questo post ho spiegato, a grandi linee, cos’è Varnish Cache ed a cosa serve. Il problema che mi ponevo era, sostanzialmente, quello di individuare l’IP sorgente delle richieste HTTP, in modo che il log di Apache (httpd) fosse in grado di tenerne traccia.

http, header http, client ip, logging, x-forwarded-for, varnishlog, backand, varnishncsa, httpd, apache

Infatti, nel caso in cui Varnish sia in esecuzione sulla stessa macchina su cui gira Apache, l’IP sorgente delle richieste HTTP sarà sempre e comunque 127.0.0.1 (aka localhost). In particolare, sarà Varnish ad intercettare le suddette richieste sulla porta 80 e, successivamente, ad inoltrarle al server Web di backend.

Sempre nel post in questione ho mostrato una direttiva del file di configurazione di Varnish (dafault.vcl), in cui viene manipolato il dato HTTP, modificandone l’header (precisamente considerando il campo X-FORWARDED-FOR come IP sorgente della richiesta, in modo da inserirlo nel file di log). Inutile dire che tale soluzione, seppure lecita, è sconveniente per due motivi:

1) manipolare i dati HTTP risulta in qualche modo oneroso in termini computazionali;

2) tale operazione potrebbe non andare a buon fine, in quanto il campo X-FORWARDED-FOR potrebbe essere vuoto.

Cosa fare dunque? Semplice, utilizzare due validi strumenti messi a disposizione da Varnish Cache, ovvero varnishncsa e varnishlog.

Il primo ci consente di salvare in un file di log apposito le richieste HTTP che Varnish ha preso in carico. Il secondo, invece, può essere facilmente customizzato, in modo da tenere traccia solo delle informazioni che ci interessano. Personalmente, ritengo che utilizzare entrambi per loggare il traffico utente sia inutile, ecco perchè uso varnishncsa per il logging delle richieste HTTP e varnishlog per tenere traccia delle comunicazioni con i backend.

Ma vediamo adesso come utilizzare i tool in questione (che su CentOS sono semplicemente dei demoni).

Per prima cosa avviamo varnishncsa utilizzando il comando:

[user@host varnish]# service varnishncsa start

Successivamente, facciamo in modo che il suddetto demone entri in esecuzione automaticamente su diversi runlevel, mediante il comando chkconfig:

[user@host varnish]# chkconfig --level 2345 varnishncsa on

A questo punto non ci rimane che configurare varnishlog. Se lanciamo il comando:

[user@host varnish]# varnishlog help

otteniamo una lista delle flag utilizzabili. Quella che a noi interessa è -b, ovvero si vuole imporre a varnishlog di registrare solo gli eventi relativi alla comuncazione con i backend (utile in caso di troubleshooting). Ecco uno stralcio del man che indica il significato della suddetta flag:

 -b     Include log entries which result from communication with a backend server.  If neither -b nor -c  is  specified, varnishlog acts as if they both were.

Modifichiamo il demone, posizionandoci nella directory /etc/init.d e digitando:

[user@host varnish]# nano varnishlog

Nella direttiva:

DAEMON_OPTS="-a -w $logfile -D -P $pidfile"

inseriamo la flag -b. Essa diventerà:

DAEMON_OPTS="-a -b -w $logfile -D -P $pidfile"

Ora impostiamo l’esecuzione automatica del demone in questione (come già fatto per varnishncsa):

[user@host varnish]# chkconfig --level 2345 varnishlog on

Infine, avviamolo:

[user@host varnish]# service varnishlog start

Adesso Varnish Cache sarà in grado di loggare tutti gli eventi che la coinvolgono.

Alla prossima.

Varnish + httpd su CentOS 5: logging del vero IP sorgente

SO: Linux, , , , , , , ,

Per ottimizzare i tempi di risposta dei server Web possono essere utilizzati degli accelleratori http (i quali svolgono principalmente operazioni di caching). Uno di questi prende il nome di varnish, software open source piuttosto diffuso ed altamente performante.

cache, varnish, httpd, apache, centos 5, http accelerator, caching, logging, source IP

Ora, poichè dal punto di vista legislativo è necessario che vengano loggati gli IP sorgenti delle richieste http, è indispensabile che il demone httpd sia in grado di individuarli e registrarli correttamente. Con una configurazione standard del suddetto demone ciò non è possibile, in quanto l’IP sorgente sarà sempre e comunque quello del server varnish che gli ha inoltrato la richiesta.

Per aggirare tale problematica occorre operare sulla configurazione di varnish e di httpd.

Per prima cosa, modifichiamo il file /etc/varnishd/defaul.vcl aggiungendo la seguente entry:

sub vcl_recv {
if (req.http.x-forwarded-for) {
    set req.http.X-Forwarded-For =
    req.http.X-Forwarded-For ", " client.ip;
  } else {
    set req.http.X-Forwarded-For = client.ip;
  }
}

In questo modo il campo http.X-Forwarded-For presente nell’header http verrà popolato con il vero IP sorgente della richiesta.

A questo punto dobbiamo semplicemente dire al demone httpd come interpretare le informazioni ricevute da varnish:

[root@bqweb1 varnish]# nano /etc/httpd/conf/httpd.conf

LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" varnishcombined

e come CustomLog utilizzeremo la seguente direttiva:

CustomLog logs/access_log varnishcombined

Riavviamo sia varnish che httpd ed il gioco è fatto.

Alla prossima.

Script kiddie ed errore HTTP 404: tiriamo le somme

Sicurezza, , , , , , ,

Non è certamente un caso che abbia configurato swatch in modo da tenere d’occhio anche gli errori HTTP 404 (Not Found). In questo modo ho potuto “registrare” in un file apposito tutti i tentativi di cracking perpetrati contro i miei server Web, individuando quali sono le URL cercate dai lamer di turno.

Ecco le 2 entry più significative:

 211.191.168.214 - - [26/Dec/2011:21:01:57 +0100] "GET /admin/Y-ivrrecording.php?php=info&ip=uname HTTP/1.1" 404 2050 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0"

173.243.121.58 - - [06/Jan/2012:19:54:16 +0100] "GET /admin/config.php HTTP/1.1" 404 2041 "-" "Python-urllib/2.4"

Nel primo caso hanno verificato la presenza di FreePBX sulla mia macchina (ovviamente con interfaccia di management in forwarding e dunque accessibile dall’esterno).

Nel secondo caso, invece, hanno controllato se sul mio server fosse presente l’interfaccia di gestione relativa a trixbox. Ho optato per trixbox (anzichè PHPMyAdmin), in quanto, dopo aver lanciano un nmap avente come target l’IP sorgente loggato, la porta TCP 443 (HTTPS) risultava in ascolto e proprio grazie ad essa era raggiungibile l’interfaccia Web di trixbox. Si trattava quindi di una testa di ponte.

Inoltre, dallo User Agent (Python-urllib/2.4) si può avere la certezza che si tratta di uno scrip (editato in Python), il cui compito è quello di scansionare range di IP alla ricerca di macchine vulnerabili.

Tra qualche mese vedrò di stilare un nuovo report.

A presto.

Swatch: configurazione per il monitoraggio dei server FTP (vsftpd)

Sicurezza, , , , , ,

Ecco la configurazione di swatch che sto utilizzando sui miei server per tenere d’occhio il demone vsftpd:

ignore /127.0.0.1/

#FTP File Status OK
watchfor  /150 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP File Status OK

#FTP Command Not Implemented
watchfor  /202 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Command Not Implemented

#FTP User Logged Out
watchfor  /221 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP User Logged Out

#FTP Directory Send OK
watchfor  /226 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Directory Send OK

#FTP User Logged In
watchfor  /230 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP User Logged In

#FTP Requested File Action Ok
watchfor  /250 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Requested File Action Ok

#FTP Service Not Avaliable
watchfor  /421 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Service Not Available

#FTP Can't Open Data Connection
watchfor  /425 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Can't Open Data Connection

#FTP Transfer Aborted
watchfor  /426 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Transfer Aborted

#FTP File Unvailable
watchfor  /450 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP File Unvailable

#FTP Command Unrecognized
watchfor  /500 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Command Unrecognized

#FTP Syntax Error
watchfor  /501 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Syntax Error

#FTP Command Not Implemented
watchfor  /502 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Command Not Implemented

#FTP Bad Sequence Of Commands
watchfor  /503 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Bad Sequence Of Commands

#FTP Login Incorrect
watchfor  /530 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Login Incorrect

#FTP Illegal File Name
watchfor  /553 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Illegal File Name

 

ftp,vsftpd,simple watchdog,status code,logging,swatch,rc.local

Come potete notare, le espressioni regolari verificano che all’interno del file /var/log/vsftpd.log siano presenti gli status code tipici del protocollo FTP.

Occorre precisare, però, che per default vsftpd non prevede il logging degli status code. Per abilitare tale funzione occorre modificare il file /etc/vsftpd.conf nel modo seguente:

xferlog_enable=YES

log_ftp_protocol=YES

xferlog_std_format=NO

A modifica completata riavviamo il demone in questione:

nightfly@nightbox:~$ sudo service vsftpd restart

ed infine inseriamo una entry nel file /etc/rc.local in modo da rendere automatica l’esecuzione di swatch per il monitoraggio di vsftpd ad ogni avvio del sistema:

swatch -c /etc/swatchftp.conf -t /var/log/vsftpd.log

Ora anche vsftpd può definirsi “sotto controllo”.

Alla prossima.

PS: per una lista (semi)completa degli status code relativi al protocollo FTP, potete consultare questo link.

PSAD: individuare i port scan diretti ai nostri server

Sicurezza, , , ,

PSAD (Port Scan Attack Detector), è un software utile ed abbastanza robusto, in grado di individuare l’indirizzo IP sorgente di un eventuale attacco port scan lanciato verso i nostri server. Nella fattispecie, in questo post illustrerò come installarlo e configurarlo.

 

psad,nmap,portscan attack,iptables,logging

 

Procediamo dunque con l’installazione del pacchetto citato in precedenza, digitando:

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

Poichè tale software si basa sui log generati da iptables, è necessario che sul nostro server siano attive le seguenti regole di firewalling:

iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG

Personalmente ho deciso di abilitare tali regole direttamente all’avvio del server, in modo da rendere psad subito operativo. Modifichiamo dunque il file /etc/rc.local:

nightfly@nightbox:~$ sudo nano /etc/rc.local

aggiungendo le entry:

#psad

iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG

Ovviamente, dopo aver installato psad è necessario configurarlo. Per fare ciò dobbiamo aprire in scrittura il file psad.conf, presente nella directory /etc/psad:

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

Inseriamo l’indirizzo email a cui verranno inviati gli alert generati da psad:

EMAIL_ADDRESSES             vostro.indirizzo@email.it;

impostiamo correttamente la soglia che fa scattare gli alert (ovvero il numero minimo di porte vittima del port scan):

PORT_RANGE_SCAN_THRESHOLD   3;

e successivamente facciamo in modo che vengano ignorati alcuni indirizzi IP inoffensivi. Per fare ciò occorre modificare il file /etc/psad/auto_dl, inserendo ad esempio queste direttive:

127.0.0.1       0;
193.204.114.232 0;
193.204.114.233 0;
10.0.3.0/24        0;
224.0.0.251     0;

Lo 0 indica il grado più basso di pericolosità associato all’IP, dove per pericolosità si intende un valore intero compreso nell’intervallo [0; 5].

Infine, riavviamo psad:

nightfly@nightbox:~$ sudo service psad restart

ed abbiamo finito.

Da notare che la configurazione trattata in questo post è piuttosto minimale e di tipo passivo, ovvero si limita ad individuare gli attacchi senza bloccarli. Potete però fare in modo che, appena psad riconosce un eventuale attacco, proceda automaticamente con la creazione di una regola iptables per bloccarlo (in questo caso parliamo di configurazione attiva).

A presto.

Swatch: un sistema di logging proattivo per ambienti Unix-like

SO: Linux, , , , ,

Un sistemista degno di questo nome dedica diverse ore della sua attività lavorativa alla lettura dei log. Ovviamente, poichè tale operazione spesso viene svolta dopo un po’ di tempo dalla generazione dei log stessi, è di fondamentale importanza utilizzare dei sistemi di logging proattivi, in grado cioè di “avvertire” l’amministratore del verificarsi di un qualche tipo di anomalia.

 

sysadmin_mug.jpg

Di software del genere ne esistono a miolioni ma in questo post ho deciso di concentrarmi su swatch per via della sua facilità d’uso e della sua flessibilità.

Infatti, grazie a swatch sarà possibile monitorare i diversi file di log generati sui nostri server, alla ricerca delle entry di nostro interesse.

Per installarlo è sufficiente lanciare il comando:

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

Ad installazione completata verrà creato un file di configurazione all’interno della nostra home dir, il cui nome sarà .swatchrc.

Personalmente credo che per ragioni di sicurezza swatch debba utlizzare un file di configurazione accessibile in lettura ma non in scrittura (ovvero che non possa essere modificato da utenti illegittimi), appartenente a root. Inoltre, consiglio di salvare il file in questione all’interno della directory /etc (per omogeneità).

Generiamo quindi il file di configurazione, il cui nome sarà swatch.conf:

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

in cui inseriremo un’unica regola, poichè ci troviamo ancora in fase di test:

#HTTP Forbidden
watchfor  /401/
       echo 
       mail addressess=vostro.indirizzo@email.it,subject=Failed Authentication

Grazie a questa entry, swatch ci avviserà via email ogniqualvolta si accorgerà che qualcuno ha provato a visualizzare una sezione riservata del sito Web presente sul nostro server (protetta mediante .htaccess).

Per fare in modo che swatch invii un’email immediatamente dopo aver individuato un determinato evento, occorre modificare il file /usr/share/perl5/Swatch/Actions.pm sostituendo:

if (! $args{'MAILER'} ) {
foreach my $mailer (qw(/usr/lib/sendmail /usr/sbin/sendmail)) {
$args{'MAILER'} = $mailer if ( -x $mailer );
}
if ($args{'MAILER'} ne '') {
$args{'MAILER'} .= ' -oi -t -odq';
}
}

con

if (! $args{'MAILER'} ) {
foreach my $mailer (qw(/usr/lib/sendmail /usr/sbin/sendmail)) {
$args{'MAILER'} = $mailer if ( -x $mailer );
}
if ($args{'MAILER'} ne '') {
$args{'MAILER'} .= ' -oi -t -odb';
}
}

Nel caso in cui decideste di non effettuare la modifica indicata in precedenza, swatch invierà le email dopo un lasso di tempo prefissato.

In alternativa, potete utilizzare i comandi bash per inviare gli alert alla vostra casella email. Per fare ciò, dovete creare una configurazione del tipo:

watchfor  /401/
exec echo 'SWATCH HOME: HTTP access forbidden: $_' | mail -iv -s "SWATCH HOME: Failed HTTP Authentication" vostro.indirizzo@email.it

Lanciamo quindi swatch con l’opzione -t (tail), ovvero in monitoraggio costante del file di log che andremo a specificare. Dovremo inoltre indicare qual è il file di configurazione a cui tale software dovrà riferirsi:

nightfly@nightbox:~$ swatch -c /etc/swatch.conf -t /var/log/apache2/ssl_access.log &

La & finale consente di lanciare il processo in background. Esiste anche l’opzione –daemon ma a quanto pare non accetta flag aggiuntive, quali -c o -t e monitorizza soltanto il file /var/log/messages.

Purtroppo swatch non consente di monitorare più file con un’unica istanza, quindi per fare ciò è necessario lanciare più istanze di tale programma, possibilmente utilizzando file di configurazione diversi a seconda del log che si intende tenere sotto osservazione.

Infine, è possibile mandare in esecuzione tale applicativo ad ogni avvio del nostro sistema operativo, semplicemente inserendo la seguente direttiva:

swatch -c /etc/swatch.conf -t /var/log/apache2/ssl_access.log

all’interno del file /etc/rc.local.

Fine del post, a presto.

Sincronizzare data ed ora dei dispositivi di rete mediante un server NTP

Networking, , , , ,

L’uso di un buon timeserver rappresenta la prima regola per ottenere dei log affidabili e soprattutto privi di eventuali inconsistenze. Inoltre, grazie ad esso, è possibile sincronizzare la data e l’ora sui vari dispositivi di rete, in modo da non dover necessariamente ricorrere ad un settaggio manuale di tali parametri.

synchronize-internet-time-server.jpg

Vediamo adesso come definire un timeserver su di un router Cisco SOHO 77, su di un firewall Cisco PIX 501 e su una macchina linux.

NTP su Cisco SOHO 77

Entriamo nella modalità di configurazione del nostro router:

SOHO77# conf t

e successivamente digitiamo il comando:

SOHO77(config)# sntp server <IP del server NTP>

In questo caso ho utilizzato come server NTP ntp.ubuntu.com, il cui indirizzo IP è 91.189.94.4

Adesso definiamo la timezone:

SOHO77(config)# clock timezone UTC +1

Come potete notare dal comando precedente, ho utilizzato la timezone UTC+1 poichè attualmente in Italia è in vigore l’ora legale.

Controlliamo che tutto sia andato a buon fine digitando il comando:

SOHO77(config)# sh clock

ed infine salviamo la configurazione:

SOHO77(config)# copy run start

NTP su Linux

Passiamo adesso all’installazione di un timeserver sulla nostra macchina linux.

Per fare ciò è sufficiente digitare:

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

Ad installazione completata editiamo il file di configurazione relativo ad ntpd, ovvero il demone che funge da timeserver:

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

Inseriamo i seguenti hostname:

# You do need to talk to an NTP server or two (or three).
 server ntp.ubuntu.com
 server ntp1.inrim.it
 server ntp2.inrim.it

Salviamo il file e riavviamo ntpd:

nightfly@nightbox:~$ sudo service ntp restart

NTP su Cisco PIX 501

Bene, ora non ci resta che configurare un server NTP sul nostro firewall. Per fare ciò occorre seguire questi step:

PIX501# conf t

PIX501(config)# ntp server <IP della nostra macchina linux su cui gira ntpd> source inside

PIX501(config)# clock timezone UTC +1

Inoltre, è necessario definire un’ACL apposita sul firewall in questione in modo da consentire il traffico udp sulla porta 123. Ciò si rende necessario poichè il server NTP interno (presente sulla macchina linux) deve poter ricevere gli aggiornamenti da quello esterno.

PIX501(config)# access-list inbound permit udp host 91.189.94.4 host <IP del server NTP interno> eq 123

Controlliamo che tutto sia andato a buon fine digitando:

PIX501# sh clock

ed anche:

PIX501# sh ntp status

il cui output dovrebbe essere simile al seguente:

Clock is synchronized, stratum 4, reference is <IP del server NTP interno>
 nominal freq is 99.9967 Hz, actual freq is 99.9966 Hz, precision is 2**6
 reference time is d1161f31.f0ef3448 (14:18:41.941 UTC Mon Feb 28 2011)
 clock offset is 3.5382 msec, root delay is 78.16 msec
 root dispersion is 1386.23 msec, peer dispersion is 880.07 msec

ed infine salviamo la configurazione con un write mem.

Adesso i nostri dispositivi dovrebbero essere sincronizzati alla perfezione con i server NTP di riferimento.

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.