Il blog sull'informatica

Dopo aver scoperto che tutte le versioni di vsftpd precedenti alla 2.3.4 (ovvero l'ultima release) sono vulnerabili ad attacchi di tipo DoS (Denial of Service), ho deciso di effettuare un upgrade del demone in questione.

Prima, però, mi sono sincerato che vsftpd non fosse già aggiornato, lanciando il comando:

nightfly@nightbox:~$ vsftpd -v

il cui output è stato il seguente:

vsftpd: version 2.2.2

Bene, come sospettavo, il demone non era aggiornato. Ho provato quindi un aggiornamento tramite aptitude:

nightfly@nightbox:~$ sudo apt-get update

nightfly@nightbox:~$ sudo apt-get upgrade

Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze
Lettura informazioni sullo stato... Fatto
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

Niente da fare, secondo aptitude, vsftpd è all'ultima versione.

Alla luce di ciò, ho proceduto con un'installazione manuale dello stesso.

Per prima cosa ho scaricato la tarball con i sorgenti puntando alla URL ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.3.4.tar.gz

nightfly@nightbox:~$ wget ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.3.4.tar.gz

Successivamente ho scompattato la tarball:

nightfly@nightbox:~$ tar -xzvf vsftpd-2.3.4.tar.gz

Mi sono quindi posizionato nella directory di riferimento:

nightfly@nightbox:~$ cd vsftpd-2.3.4

ed ho lanciato il comando:

nightfly@nightbox:~/vsftpd-2.3.4$ make

A questo punto, lanciando un ls ho notato la presenza del binario di vsftpd all'interno della directory.

Ho dunque proceduto con la sostituzione della versione precedente del demone, presente in /etc/init.d, con questa versione appena compilata, previo backup:

nightfly@nightbox:~/vsftpd-2.3.4$ cd /etc/init.d

nightfly@nightbox:/etc/init.d$ sudo mv vsftpd vsftpd.bak

Poi ho effettuato la sostituzione vera e propria:

nightfly@nightbox:/etc/init.d$ cd /home/nightfly/vsftpd-2.3.4

nightfly@nightbox:~/vsftpd-2.3.4$ sudo cp vsftpd /etc/init.d

Dopo aver fatto ciò, ho verificato che la versione di vsftpd fosse quella giusta:

nightfly@nightbox:~$ vsftpd -v

ricevendo come output:

vsftpd: version 2.2.4

Infine ho proceduto con il riavvio del servizio:

nightfly@nightbox:~$ service vsftpd restart

Ed ecco che il mio server FTP risultava finalmente patchato.

Alla prossima.

Recentemente si è manifestata la necessità di aumentare la durata delle sessioni relative ad uno dei CRM che ho sviluppato, in modo da non costringere l'utente ad effettuare nuovamente il login dopo un certo periodo di inattività.

Il modo più semplice ed efficace per ottenere tale risultato consiste nel modificare il valore associato al parametro session.gc_maxlifetime del file php.ini, portandolo da 1440 (24 minuti) a 28800 (8 ore).

Per fare ciò occorre editare il suddetto file mediante il comando:

nightfly@nightbox:~$ sudo nano /etc/php5/apache2/php.ini

Una volta completata l'operazione, è necessario riavviare apache2 digitando:

nightfly@nightbox:~$ sudo service apache2 restart

ed abbiamo finito.

A presto.

NB: ovviamente la sessione verrà comunque terminata alla chiusura del browser.

Grazie a squid ed alla sua estensione squidGuard è abbastanza semplice realizzare un proxy open-source in grado di filtrare i contenuti Web.

Supponendo che squid sia già presente sulla nostra macchina (in questo post è riportata l'intera procedura di installazione e configurazione), vedremo adesso come installare e configurare correttamente squidGuard.

Per prima cosa scarichiamo ed installiamo tale estensione digitando il comando:

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

Ora, affinchè squid possa utilizzare squidGuard per i redirect, occorre aggiungere la seguente stringa all'interno del file /etc/squid/squid.conf:

#Squidguard
redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

Fatto ciò, scarichiamo e scompattiamo le blacklist che verranno utilizzate da squidGuard per il content filtering:

nightfly@nightbox:~$ wget http://squidguard.mesd.k12.or.us/blacklists.tgz

nightfly@nightbox:~$ tar -xvf blacklists.tgz

nightfly@nightbox:~$ cd blacklists/

Copiamo tutto il contenuto della dir blacklists all'interno di /var/lib/squidguard/db:

nightfly@nightbox:~/blacklists$ sudo cp -R * /var/lib/squidguard/db

Compiliamo successivamente le blacklist appena scaricate:

nightfly@nightbox:~/blacklists$ sudo squidGuard -d -C all

Adesso cambiamo l'owner (sia a livello di gruppo che a livello di singolo utente) per la directory db il cui path è /var/lib/squidguard/db:

nightfly@nightbox:~$ sudo chown proxy:proxy -R /var/lib/squidguard/db

Modifichiamo, inoltre, il file squidGuard.conf presente nella dir /etc/squid inserendo le seguenti direttive:

dest aggressive {
        domainlist aggressive/domains
}

dest drugs {
        domainlist drugs/domains
}

dest gambling {
        domainlist gambling/domains
}

dest hacking {
        domainlist hacking/domains
}

dest porn {
        domainlist porn/domains
}

dest proxy {
        domainlist proxy/domains
}

dest redirector {
        domainlist redirector/domains
}

dest spyware {
        domainlist spyware/domains
}

dest suspect {
        domainlist suspect/domains
}

dest violence {
        domainlist aggressive/domains
}

dest warez {
        domainlist warez/domains
}

acl {
        default {
                pass !aggressive !drugs !gambling !hacking !porn !proxy !redirector !spyware ! suspect !violence !warez
                redirect http://ipvostramacchina/block.html
        }

}


Così facendo, abbiamo definito l'acl default che nega (!) l'accesso ai siti contenuti nelle varie blacklist (ads, aggressive, audio-video, ecc.), consentendo tutto il resto.

L'ultimo passo consiste nel realizzare la pagina su cui verranno reindirizzati gli utenti quando tenteranno di accedere ad un sito Web non consentito:

nightfly@nightbox:~/blacklists$ cd /var/www

nightfly@nightbox:~/blacklists$ sudo nano block.html

<html>
<head>
<title>Proibito</title>
</head>
<body>
PROIBITO
</body>
</html>

Ovviamente tale pagina (estremamente semplice e scarna) rappresenta solo un esempio. Potete infatti sbizzarrirvi e creare una pagina Web ad hoc, inserendo all'interno di essa il logo aziendale, eventuali indirizzi email per contattare gli amministratori, ecc.

Rendiamo effettive le nuove impostazioni aggiornando la configurazione di squid attraverso il comando:

nightfly@nightbox:/var/www$ sudo squid -k reconfigure

ed abbiamo finito.

A presto.

Una delle operazioni più importanti per la messa in sicurezza dei Webserver consiste nella corretta configurazione del file php.ini.

Infatti, alcune funzioni presenti nel file in questione che per default risultano abilitate, potrebbero essere la causa di eventuali falle di sicurezza non indifferenti.

Editiamo quindi il file php.ini presente nella directory /etc/php5/apache2/:

nightfly@nightbox:~$ sudo nano /etc/php5/apache2/php.ini

Una volta aperto il file in scrittura modifichiamo le seguenti direttive:

1) settiamo ad off i parametri safe_mod e safe_mod_gid entrambi deprecati dalla versione 5.3.0 di PHP:

safe_mod = Off
safe_mod_gid = Off

2) restringiamo l'open_basedir alla sola directory /var/www:

open_basedir = /var/www

In questo modo limiteremo la possibilità di aprire file mediante PHP (ad esempio utilizzando la funzione fopen()) esclusivamente alla directory specificata.

3) Disabilitiamo alcune funzioni di PHP che potrebbero compromettere il nostro sistema:

disable_functions = exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source, php_uname, getmyuid, getmypid, leak, listen, diskfreespace

4) disabilitiamo la visualizzazione degli errori, in modo da non dare punti di riferimento ad eventuali attaccanti che potrebbero utilizzare delle tecniche specifiche (ad esempio il blind SQL injection) per minare alla sicurezza del nostro server:

display_errors = Off

5) disabilitiamo la direttiva register_globals, ormai deprecata, in quanto non consente di fare alcuna distinzione tra le variabili passate mediante POST e quelle passate mediante GET:

register_globals = Off

6) disabilitiamo la direttiva allow_url_fopen che consente l'apertura di file mediante URL:

allow_url_fopen = Off

7) settiamo ad off la direttiva allow_url_include che consente l'inclusione di file mediante URL:

allow_url_include = Off

8) se le vostre applicazioni server side non prevedono l'upload di alcun tipo di file occorre disabilitare la direttiva file_uploads:

file_uploads = Off

9) affinchè i cookie non siano accessibili da script client side (editati, ad esempio, in javascript oppure in vbscript), riducendo notevolmente i rischi di attacchi XSS, occorre abilitare l'opzione session.cookie_httponly:

session.cookie_httponly = 1

10) per salvare le sessioni in una dir non convenzionale, evitando così che eventuali utenti con accesso shell possano intercettarle, dobbiamo operare sul parametro session.save_path:

session.save_path = "/tmp/phpsessions"

11) Infine, per irrobustire le difese del core PHP consiglio di installare la patch suhosin mediante il comando:

nightfly@nightbox:~$ sudo apt-get install php5-suhosin

Adesso il nostro server può essere considerato "quasi" sicuro, almeno per quanto riguarda la configurazione di PHP.

A presto.

La funzione date() è sicuramente un ottimo strumento per rappresentare le date nel formato gg/mm/aaaa et similia, ma diventa deltutto insufficiente quando si ha a che fare con le date in italiano.

A tal proposito, torna certamente utile la funzione strftime() che abbinata alla funzione setlocale() ci consente di ottenere la visualizzazione della data nella lingua che preferiamo.

Ma facciamo un esempio pratico. Per prima cosa richiamiamo la funzione setlocale() nel modo seguente:

setlocale(LC_TIME, 'ita', 'it_IT.utf8');

Il secondo parametro, ovvero ita è essenziale per il i server Windows, mentre il terzo parametro, ovvero 'it_IT.utf8' è indispensabile per i server *nix.

Richiamiamo adesso la funzione

$data = strftime("%A, %d %B %Y");

Dove %A è il nome del giorno della settimana, %d è il giorno del mese in notazione gg, %B è il nome del mese e %Y è l'anno nel formato yyyy.

Ora, poichè la funzione echo di per sè non visualizza correttamente i caratteri accentati (per i giorni Lunedì, Martedì, ecc.) è necessario utilizzare la funzione utf8_decode(). Avremo quindi:

echo utf8_encode($data)

Un esempio di output così ottenuto è il seguente:

martedì, 14 giugno 2011

Alla prossima.

NB: per ottenere una lista delle localizzazioni attive sulla nostra linux box basta lanciare il comando:

nightfly@nightbox:~$ locale -a

Qualche tempo fa, mentre lavoravo per il progetto PIT di Selex Communications, è sorta la necessità di appurare quale degli n-NOC avesse lanciato un reboot su uno dei router di una sala operativa. Poichè l'history non riportava alcuna informazione sulla data e sull'ora di esecuzione del comando, non è stato possibile individuare con certezza il responsabile, quindi la questione si è risolta con un nulla di fatto.

Alla luce di ciò, ho deciso di scrivere questa breve guida in cui viene descritta la procedura per aggiungere il datetime al file history nell'ambito dei sistemi basati su Debian.

Per prima cosa è necessario editare il file nascosto .bashrc presente nella home dell'utente:

nightfly@nightbox:~$ sudo nano .bashrc

e successivamente aggiungere la seguente direttiva:

HISTTIMEFORMAT="%d/%m/%y %T "

In particolare, ogni comando presente nel file history verrà proceduto da giorno (%d), mese (%m), anno (%y) ed ora (%T) (nel formato hh:mm:ss) di esecuzione dello stesso.

Subito dopo esserci riloggati alla macchina digitiamo il comando:

nightfly@nightbox:~$ history

il cui output sarà simile al seguente:

 1995  12/06/11 11:49:57 history
 1996  12/06/11 11:49:57 exit
 1997  12/06/11 11:26:49 history
 1998  12/06/11 11:50:17 sudo nano .bashrc
 1999  12/06/11 11:53:13 history

Ovviamente tale operazione non è retroattiva, nel senso che tutti i comandi precedenti alla modifica del file .bashrc avranno come datetime quello della modifica stessa.

A presto.

L'accoppiata squid + squidGuard rappresenta un'ottima soluzione per l'implementazione di un sistema dedicato al content filtering. Infatti, basta scaricare le blacklist aggiornate di squidGuard per avere un un filtraggio dei contenuti Web efficace ed efficiente.

A tal proposito, ho pensato di realizzare uno script bash per l'aggiornamento automatico di tali blacklist. Ecco il codice:

#!/bin/bash

logfile=/var/log/squidguardupdate.log

ROOT_UID=0

if [ "$UID" -ne "$ROOT_UID" ];then

        ERRORE1="Errore 1: Devi essere root per eseguire lo script"
        echo $ERRORE1
        echo "$(date) $ERRORE1" >> $logfile

        exit 1

fi

wget http://squidguard.mesd.k12.or.us/blacklists.tgz

tar -xvf blacklists.tgz

cd blacklists/

cp -R * /var/lib/squidguard/db

squidGuard -d -C all

chown proxy:proxy -R /var/lib/squidguard/db

squid -k reconfigure

cd ..

rm blacklists.tgz

exit 0

Tale script non fa altro che scaricare le blacklist mediante wget, compilarle ed aggiornare la configurazione di squid.

Per ulteriori chierimenti contattatemi.

A presto.