Archivi tag: tuning

Tenere sotto controllo le performance di Apache con mod_status e Nagios

Apache è uno dei server Web più utilizzati al mondo poichè molto robusto, piuttosto performante e soprattutto perchè open source.

Ovviamente, affichè le prestazioni dell’applicativo in questione possano migliorare sensibilmente, è necessario operare sul suo file di configurazione, effettuando un tuning dello stesso. A tal proposito, è alquanto utile, durante questa attività, tenere Apache sotto controllo utilizzando uno dei suoi moduli appositamente creato per svolgere la suddetta mansione, ovvero mod_status.

 

apache_status.jpeg

Vediamo ora come abilitarlo e configurarlo in modo opportuno.

Configurazione di Apache

Per prima cosa editiamo il file /etc/httpd/conf/httpd.conf, operando su di esso le seguenti modifiche:

1) decommentiamo la direttiva:

LoadModule status_module modules/mod_status.so

2) abilitiamo le statistiche estese, decommentando la seguente entry:

ExtendedStatus On

Nell’ambito della configurazione del vhost (o dei vhosts) su cui vogliamo fare in modo che siano consultabili le statistiche relative al funzionamento del nostro server Web, inseriamo quanto segue:

<Location /server-status>
 SetHandler server-status
 Order deny,allow
 Deny from all
 Allow from <IP 1>
 Allow from <IP 2>
 Allow from <IP 3>
 Allow from <IP 4>
 Allow from <IP 5>
 </Location>

dove i vari IP sono quelli consentiti per la visualizzazione della pagina Web contenente lo stato di funzionamento di Apache.

Se non utilizzate vhosts, potete semplicemente decommentare le suddette entries (già presenti nel file di configurazione di Apache).

Riavviamo dunque il demone per rendere effettive le modifiche:

[root@serverWeb ~]# service httpd reload

Configurazione di Nagios

Una volta configurato Apache, è possibile utilizzare Nagios per automatizzare i controlli sul server Web. Ovviamente, l’indirizzo IP del nostro NMS deve essere tra quelli consentiti in <Location /server-status>.

Il plugin che ho scelto per effettuare i check in questione è check_apachestatus.pl, scaricabile da qui.

Rinominiamo lo scrip appena scaricato e rendiamolo eseguibile:

[root@NMS ~]# mv check_apachestatus.pl.txt ckeck_apachestatus.pl

[root@NMS ~]# chmod +x check_apachestatus.pl

Spostiamolo nella dir dei plugin di Nagios:

[root@NMS ~]# mv check_apachestatus.pl  /usr/lib/nagios/plugins/

Prima di eseguirlo, però, è necessario scaricare le librerie perl relative a Nagios, mediante il comando:

[root@NMS ~]# yum install perl-Nagios-Plugin

Ora possiamo procedere con la configurazione di Nagios vera e propria.

Per prima cosa, all’interno del file /etc/nagios/objects/commands.cfg definiamo questo nuovo comando:

# 'check_apache_status' command definition
define command{
command_name    check_apache_status
command_line    $USER1$/check_apachestatus.pl -H $ARG1$ -p $ARG2$ -t $ARG3$ -w $ARG4$ -c $ARG5$
}

dove -H rappresenta l’FQDN o semplicemente l’indirizzo IP del nostro server Web su cui è in esecuzione mod_status (e su cui è consultabile la relativa pagina server-status); -p rappresenta la porta su cui il server Web è in ascolto; -t rappresenta il timeout relativo ad ogni check; -w rappresenta il numero di open slots al di sotto del quale far scattare un warning; -c rappresenta il numero di open slots al di sotto del quale far scattare un avviso di tipo critical.

A titolo di informazione, gli open slots rappresentano semplicemente il numero di processi fork in ascolto (ovvero in attesa di nuove connessioni) relativi ad httpd.

Non ci resta che creare un apposito servizio sul file di configurazione di Nagios che identifica il nostro server Web. Ad esempio, all’interno del file /etc/nagios/objects/serverweb.cfg possiamo scrivere:

define service{
        use                             local-service         ; Name of service template to use
        host_name                       serverweb.vostrodominio.com
        service_description             Apache Status
        check_command                   check_apache_status!serverweb.vostrodominio.com!80!10!5!0
        notifications_enabled           0
        }

Infine, riavviamo Nagios:

[root@NMS ~]# service nagios restart

Ed abbiamo finito.

Alla prossima.


Nuovo server casalingo a risparmio energetico: migrazione completata

Finalmente il nuovo server è operativo (dopo aver completato la fase di tuning e di test, durata circa 2 giorni). Just a little pic:

31122011029.jpg

Dai primi esperimenti sembra solido come una roccia e non raggiunge mai carichi eccessivi, nonostante gli n servizi attivi. Staremo a vedere, ma tutti gli indizi portano ad essere ottimisti 😀

A presto.

Tuning di snort 2.9.0.5 (rules)

In questo post ho spiegato come effettuare un tuning minimale dei preprocessori di cui si avvale snort 2.9.0.5. Ora, invece, vedremo come disabilitare tutte quelle regole che potrebbero generare dei falsi positivi.

snort

Per prima cosa posizioniamoci nella directory /etc/snort/rules:

nightfly@nightbox:~$ cd /etc/snort/rules

Lanciamo un ls per visualizzare il contenuto della dir:

nightfly@nightbox:/etc/snort/rules$ ls

il cui outuput sarà simile al seguente:

attack-responses.rules  misc.rules           snmp.rules
backdoor.rules          multimedia.rules     specific-threats.rules
bad-traffic.rules       mysql.rules          spyware-put.rules
blacklist.rules         netbios.rules        sql.rules

ecc.

Come è facile intuire, esiste un file *.rules per ogni possibile minaccia, dove ciascun file contiene tutta una serie di regole che identificano i tentativi di attacco. Ad esempio, analizzando il file attack-responses.rules, noteremo delle entry del tipo:

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES directory listing"; flow:established; content:"Volume Serial Number"; classtype:bad-unknown; sid:1292; rev:9;)

alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES command completed"; flow:established; content:"Command completed"; nocase; metadata:policy balanced-ips drop, policy security-ips drop, service http; reference:bugtraq,1806; classtype:bad-unknown; sid:494; rev:13;)

alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES command error"; flow:established; content:"Bad command or filename"; nocase; classtype:bad-unknown; sid:495; rev:10;)

E’ possibile disabilitare una qualunque entry semplicemente commentandola (ovvero inserendo un # ad inizio riga). Però, per evitare che tale entry ritorni attiva dopo l’aggiornamento delle regole mediante oinkmaster, dobbiamo operare direttamente sul file /etc/oinkmaster.conf:

nightfly@nightbox:/etc/snort/rules$ sudo nano /etc/oinkmaster.conf

aggiungendo la direttiva disablesid seguita dal sid dell’alert che ci interessa (ad esempio 1292 per ATTACK-RESPONSES directory listing):

disablesid 1292

Salviamo il file, riavviamo snort con un sudo service snort restart ed abbiamo finito.

A presto.

Tuning dei preprocessori di snort 2.9.0.5

In questo post abbiamo visto come aggiornare snort alla versione 2.0.9.5 su piattaforma *buntu. Adesso vedremo come effettuare del tuning minimale per evitare tutta una serie di falsi positivi (base rate fallacy), che possono distogliere la nostra attenzione dalle reali minacce.

snort

 

Personalmente credo che sui sistemi che vengono utilizzati per la semplice navigazione Web (o che fungono da GW verso la rete esterna) e su cui è presente un qualunque applicativo p2p occorre disabilitare le seguenti regole, inserendo le seguenti direttive nel file /etc/snort/threshold.conf:

suppress gen_id 119, sig_id 2
suppress gen_id 129, sig_id 12
suppress gen_id 129, sig_id 19
suppress gen_id 119, sig_id 15
suppress gen_id 120, sig_id 3
suppress gen_id 129, sig_id 14
suppress gen_id 129, sig_id 15
suppress gen_id 129, sig_id 5
suppress gen_id 129, sig_id 4

Tutte le regole riportate in precedenza sono identificate mediante un gen_id ed un sig_id, dove per gen_id si intende l’ID del preprocessore, mentre per sig_id si intende l’alert generato dal preprocessore coinvolto. Per avere un’idea più chiara di cosa sto parlando basta aprire in lettura il file /etc/snort/gen-msg.map. Così facendo potremo notare come al gen_id 119 ed al sig_id 2 corrisponde l’alert http_inspect: DOUBLE DECODING ATTACK, al gen_id 129 ed al sig_id 12 corrisponde l’alert stream5: TCP Small Segment Threshold Exceeded, e così via.

Nello specifico, ecco come appariranno le entry del file gen-msg.map:

126 || 2 || telnet_pp: Telnet data encrypted
126 || 3 || telnet_pp: Subnegotiation Begin without matching Subnegotiation End
128 || 1 || ssh: Gobbles exploit
128 || 2 || ssh: SSH1 CRC32 exploit
128 || 3 || ssh: Server version string overflow
128 || 4 || ssh: Protocol mismatch
128 || 5 || ssh: Bad message direction
128 || 6 || ssh: Payload size incorrect for the given payload
128 || 7 || ssh: Failed to detect SSH version string

ecc.

Riavviate snort per rendere effettive tali modifiche:

nightfly@nightbox:~$ sudo service snort restart

ed il gioco è fatto.

A presto.

Snort: disabilitare la notifica DOUBLE DECODING ATTACK

Che Snort generi una miriade di falsi positivi durante il normale utilizzo della rete è abbastanza risaputo. Ultimamente, però, ho notato la presenza, piuttosto insistente, di notifiche simili alle seguenti:

 [**] [119:2:1] (http_inspect) DOUBLE DECODING ATTACK [**]
 [Priority: 3]
 05/12-21:23:59.624917 192.168.*.*:1299 -> 212.52.84.153:80
 TCP TTL:128 TOS:0x0 ID:5340 IpLen:20 DgmLen:98 DF
 ***AP*** Seq: 0xC593D3E7  Ack: 0x1DDBAA89  Win: 0xFFFF  TcpLen: 20

A quanto pare il preprocessore http_inspect si altera perchè nota la presenza di un doppio meccanismo di codifica mentre si naviga sulla webmail di Libero (per la precisione mailbeta.libero.it). Il fatto che venga utilizzata questa tecnica di codifica non è un’anomalia, semplicemente moltissimi siti Web preferiscono codificare più volte le variabili in modo da garantire un livello di sicurezza più elevato.

images.jpg

 

Come procedere quindi per disabilitare l’alert in questione?

Una soluzione abbastanza rapida consiste nel modificare il file threshold.conf presente nella directory /etc/snort/:

nightfly@nightbox:/etc/snort$ sudo nano threshold.conf

Aggiungendo la stringa:

suppress gen_id 119, sig_id 2

Adesso verifico che il file threshold.conf venga effettivamente utilizzato da snort.conf:

nightfly@nightbox:/etc/snort$ sudo nano snort.conf

A tal proposito è sufficente decommentare la stringa:

# include threshold.conf

che diventerà:

include threshold.conf

Riavvio infine Snort mediante il comando:

nightfly@nightbox:/etc/snort$ sudo service snort restart

e questo piccolo tuning è stato completato.

A presto.