Installazione di mod_security2 su Debian Squeeze

Mod_security è un WAF (web application firewall). Basato su un sistema di regole che consentono di respingere,registrare e negare gli accessi da parte di qualsiasi minaccia esterna, mod_security fa parte di quella categoria di software delegati al virtual-patching.

Grazie alle sue capacità mod_security viene utilizzato per impedire la negoziazione di determinati contenuti che hanno la necessità di essere protetti, di negare l’accesso a determinate risorse presenti sul server grazie ad un sistema basato sull’analisi con le espressioni regolari di ogni agente esterno che tenta di effettuare una connessione al web server. Particolarmente utile nella rilevazione e nel blocco di attacchi SQL Injection ed XSS, la struttura di mod_security è basata su una serie di regole che possono essere applicate al traffico in ingresso sul web server. Continue reading

Post simili:

Upgrade di Nginx alla versione 0.8.54

In attesa di Nginx 0.9.5, ancora in fase di sviluppo, se vuoi fare un upgrade della tua attuale versione portandola alla 0.8.54 segui questo breve post.

L’esigenza di un upgrade può nascere nel caso in cui sul sistema sia installata una versione superata, ciò accade tipicamente su Debian o CentOS dove i binari pacchettizzati sono fermi alla 0.6.32.

La procedura che segue è riferita ad un sistema Debian 5.0 Lenny perciò prima di iniziare il tutto sarà necessario installare la suite di compilazione oltre alle librerie pcre e libevent necessarie per Nginx :

# apt-get install libevent-dev libpcre3-dev build-essential

Prima di compilare Nginx è importante predisporre un backup del vecchio binario oltre ad un salvataggio dei precedenti file di configurazione, ciò per evitare dolorose sovrascritture :

# cd /usr/src
# cp /usr/sbin/nginx nginx_06
# cp -r /etc/nginx/ old_conf

Se attivo fermiamo il demone Nginx :

 # /etc/init.d/nginx stop

Assicuriamoci inoltre di appuntare su un pezzo di carta gli attuali path in cui risiede il binario ed i file di configurazione. Solitamente /usr/sbin/ e /etc/nginx/. Abbiamo bisogno di sapere anche dove dovrà essere allocato il pid del demone, generalmente nella directory /var/run e la directory dove saranno salvati i log di errore ovvero /var/log/nginx. Con questi dati possiamo prelevare il codice sorgente e configurare i path.  :

# wget http://nginx.org/download/nginx-0.8.54.tar.gz
# tar zxf nginx-0.8.54.tar.gz
# cd nginx-0.8.54
# ./configure --sbin-path="/usr/sbin/nginx" --conf-path="/etc/nginx/nginx.conf" \

--error-log-path="/var/log/nginx/error.log"  --pid-path="/var/run/nginx.pid" \

--with-ipv6 --with-http_ssl_module --with-http_gzip_static_module

Dato che non vogliamo ritornare più di una volta in futuro a ricompilare qualche opzione mancante assicuriamoci di abilitare il modulo per l’Ipv6.

Dopo aver configurato la compilazione controlliamo che le opzioni presentate corrispondano alle nostre aspettative :

nginx path prefix: "/usr/local/nginx"
nginx binary file: "/usr/sbin/nginx"
nginx configuration prefix: "/etc/nginx"
nginx configuration file: "/etc/nginx/nginx.conf"
nginx pid file: "/var/run/nginx.pid"
nginx error log file: "/var/log/nginx/error.log"
nginx http access log file: "/usr/local/nginx/logs/access.log"
nginx http client request body temporary files: "client_body_temp"
nginx http proxy temporary files: "proxy_temp"
nginx http fastcgi temporary files: "fastcgi_temp"
nginx http uwsgi temporary files: "uwsgi_temp"
nginx http scgi temporary files: "scgi_temp"

Se la risposta è si avviamo la compilazione :

# make

A questo punto, piuttosto che digitare il classico make install, ci interessa copiare solamente il binario prodotto dalla compilazione dato che sul sistema è già presente lo scheletro dell’installazione della precedente versione di Nginx :

# cd objs/
# cp nginx /usr/sbin/

Abbiamo quasi finito, controlliamo che il nuovo eseguibile corrisponda alla versione che abbiamo prelevato :

# nginx -v
nginx version: nginx/0.8.54

Restano solo alcuni ritocchi :

# mkdir /usr/local/nginx
# touch /usr/local/nginx/client_body_temp

Controlliamo che il nuovo eseguibile non riscontri problemi con i file di configurazione in /etc/nginx già presenti sul sistema :

# nginx -t
the configuration file /etc/nginx/nginx.conf syntax is ok
configuration file /etc/nginx/nginx.conf test is successful

E’ andato tutto per il verso giusto. Per terminare riavviamo il demone Nginx appena installato :

# /etc/init.d/nginx start

Post simili:

Distribuzioni Linux, un confronto

Durante gli anni il nostro staff si è trovato a lavorare a cuore aperto su un vasto ecosistema di sistemi operativi e derivati. Il nostro lavoro si concentra sui server. Il post che segue è lungi dal voler scatenare “guerre di religione” tra i sostenitori di una distribuzione Linux piuttosto che di un’altra. Di flame in rete se ne trovano già tanti. Si tratta piuttosto di qualche riga scaturita da quelle che sono state le nostre esperienze, le nostre sensazioni a contatto con 3 delle distribuzioni Linux attualmente più diffuse e più utilizzate su sistemi server : Debian, CentOS e Ubuntu.

Lasceremo volutamente fuori Red Hat (CentOS ne è una derivazione), Gentoo, openSUSE ed un elenco sterminato di ottimi prodotti che girano fluidamente sui server di tutto il pianeta. Ci concentreremo invece su queste 3 distribuzioni che incarnano attualmente la scelta quasi obbligata per chi allestisce un server fuori dalle logiche commerciali di prodotti come Red Hat o SUSE, analizzandone pregi, difetti e personalità. (Molti obietteranno come Ubuntu rientri eccome all’interno di logiche commerciali. Tuttavia qui con il termine “commerciale” abbiamo voluto indicare quelle distribuzioni che hanno un costo di licenza a carico dell’utilizzatore finale.)

Ubuntu

ubuntu Distribuzioni Linux, un confronto

Si comincia con Ubuntu. Molti amministratori di sistema storceranno il naso. La scelta di Ubuntu per sistemi server mission critical è spesso criticata ampiamente. Se avete voglia di fare un giro sulle mailing list delle vulnerabilità 0day vi accorgerete come molte versioni di Ubuntu figurano come pesantemente vulnerabili ad alcuni degli exploit più pericolosi. I bug fix si susseguono di giorno in giorno. Ma questa non è assolutamente una prerogativa di Ubuntu. Tutte le distribuzioni Linux nessuna esclusa sono vulnerabili. La nota di merito è che i bug vengono chiusi tempestivamente con rilasci molto veloci delle patch più urgenti.

Uno dei punti che gioca a sfavore di Ubuntu è la sua reputazione di distribuzione Linux votata all’utilizzo desktop e molto diffusa al grande pubblico. Se questo può essere un vantaggio da una parte, dall’altra scoraggia i professionisti più puristi ad utilizzarla sui server destinati a missioni importanti. Più di un provider ci ha confermato che Ubuntu è inadatta all’utilizzo per ambienti virtualizzati per via di alcuni bug che ne minerebbero la stabilità come nodo per ospitare sistemi VPS multipli.

Debian

debian1 Distribuzioni Linux, un confronto

Debian è una delle distribuzioni più stimate. Tra i vantaggi riconosciuti vi è la freschezza dei pacchetti software (alla pari di Ubuntu), la stabilità e la facilità di deploying. Debian è la distribuzione stabile per eccellenza. Il gruppo di sviluppo è professionalmente accreditato e ciò garantisce una grande qualità degli aggiornamenti del sistema. Vi sono però alcuni difetti sostanziali tra i quali la presenza degli stessi bug che affliggono Ubuntu e che non consentono a Debian di essere utilizzata con successo in ambienti virtualizzati.

Debian è molto stimata tra i professionisti che la ritengono adatta per alcuni degli utilizzi più importanti. Abbiamo visto server equipaggiati con Debian sfoggiare uptime degni di un mainframe. Notevole inoltre la possibilità di far attecchire Debian sui sistemi e sui dispositivi più svariati grazie alle grandi possibilità di adattamento sulle architetture più esotiche come sparc, mips e powerpc. A differenza di Ubuntu, Debian è guardata con sospetto dal grande pubblico degli utenti desktop ma a ciò fa da contraltare uno stimato utilizzo sugli ambienti server.

CentOS

centos Distribuzioni Linux, un confronto

CentOS deriva dal codice sorgente di Red Hat Enterprise Linux. Una garanzia per alcuni, un disastro per altri. Tuttavia i vantaggi superano di gran lunga le pecche. CentOS viene utilizzato su alcune delle architetture server più famose come Dell. La diretta derivazione da Red Hat fa si che CentOS disponga di un ottimo supporto hardware che si tramuta in una grande disponibilità di driver per i sistemi server di fascia alta. Essendone solo una derivazione, CentOS è penalizzato dalla mancanza di un supporto commerciale alla stregua di Red Hat.

La stabilità è uno dei grandi vantaggi di cui gode CentOS. Scelto come partner ideale sui sistemi server a contatto con applicazioni mission critical, l’unica nota di demerito che possiamo muovergli è la scarsa disponibilità di pacchetti “freschi”, aggiornati alle versioni più recenti e la mancanza di alcune librerie di sviluppo necessarie per l’installazione dei software più disparati. Tuttavia stabilità vuol dire anche poter disporre di pacchetti verificati e privi di bug piuttosto che rincorrere l’ultima versione di un software che potrebbe nascondere uno o più bug potenzialmente letali.

End

A pubblicare post come quello che (si presume) abbiate letto si corre sempre il rischio di innescare antipatie e flame. Però è un rischio che accettiamo volentieri di correre perchè amiamo il nostro lavoro ed amiamo scriverne. Non è un caso se Ubuntu, Debian e CentOS siano tra le distribuzioni più utilizzate a livello server. Ci scusino i sostenitori dei vari Fedora, OpenSUSE o Gentoo, avremo modo di parlarne in uno dei prossimi post. Per tutti gli altri che fossero interessati a partecipare al confronto con opinioni, esperienze e quant’altro sarete i benvenuti nello spazio sottostante dedicato ai commenti.

Alla prossima.

Post simili: