Jan 132013
 

Oggi vi presento un articolo molto interessante di pubblicato su infosecinstitute.com .

Con la significativa prevalenza di server web Linux a livello globale, la sicurezza è spesso pubblicizzata come un punto di forza della piattaforma per questo scopo. Tuttavia, un server Linux esposto sul web è sicuro tanto quanto la sua configurazione e molto spesso molti sono abbastanza vulnerabili alla compromissione. Mentre configurazioni specifiche variano molto a causa di ambienti o l’uso specifico, ci sono vari passaggi generali che possono essere adottati per assicurarsi che alcune considerazioni di sicurezza di base siano a posto.

Molti rischi sono possibili dalla compromissione di un server web tra cui fornire malware a chi utilizza il server web, la creazione ed invio di spam, proxy web o TCP, o altre attività dannose. Il sistema operativo ed i pacchetti possono avere tutte le patch con gli aggiornamenti di sicurezza e il server potrebbe essere ancora compromesso basandosi puramente su una configurazione fatta con scarsa sicurezza. La sicurezza delle applicazioni web inizia come prima cosa con la configurazione del server stesso e yenedendo a mente una rigorosa politica di sicurezza.




Molti spesso creano vari strati, come un WAF, IDS, o Mod Security per reagire in tempo reale alle varie minacce hacker sulle richieste HTTP. Tuttavia, garantire all’intero server e tutti i servizi in esecuzione un livello elevato di sicurezza è il primo passo fondamentale per evitare il rischio di essere violati o compromessi. Con l’abbondanza di malware installato da applicazioni web ospitate su server basati su Linux (come le recenti vulnerabilità di timthumb.php un plugin WordPress), è chiaro che molti server sono configurati con poca o nessuna sicurezza in mente.

Per gli utenti di blog personali, una compromissione è spesso motivo di imbarazzo e disagio. Tuttavia per le imprese piccole e grandi, avere un sito o un blog della vostra azienda che serve malware dopo essere stato compromesso è una perdita di affari e crea un riflesso molto povero dei servizi IT della vostra azienda sul pubblico e sui potenziali clienti.

I Server Web che sono compromessi e forniscono il malware spesso sono poi molto rapidamente indicati nel profilo di Google Safe Browsing, a cui la maggior parte di tutti i principali browser sono iscritti. Quando segnalato, spesso 24 ore o più sono necessarie per cancellarsi dall’elenco in quanto il controllo per la Navigazione sicura esplora i siti solo una volta al giorno per le modifiche.

040512_1427_TheImportan1

Fuga di informazioni

Le prime e relativamente banali, modifiche alla configurazione che dovrebbero essere apportate sono di disattivare qualsiasi fuga di informazioni dal server. Tutte le distribuzioni Linux hanno configurazioni predefinite troppo “parlanti” per quanto riguarda la fuga di informazioni per Apache e altri servizi. Mentre la maggior parte respingono questo come un non problema, meno informazioni trasmettiamo ad un possibile attaccante, meglio è. Ogni richiesta al server web Apache può rispondere con informazioni quali la versione esatta dell’OpenSSL, la versione del PHP, e molte altre articoli. Mentre alcune applicazioni come OpenSSH richiedono la comunizaione online della loro versione nel banner per il funzionamento, non vi è alcuna ragione funzionale per Apache di trasmettere il suo numero di versione al mondo, e allo stesso modo quetso è vero per altri moduli di Apache correlati. Recuperiamo le intestazioni HTTP con curl da un sito d’esempio è vediamo che informazioni sono fornite al pubblico:

$ curl -I example.com
HTTP/1.1 200 OK
Date: Sun, 25 Mar 2012 02:11:54 GMT
Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 Phusion_Passenger/2.2.11 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_wsgi/2.5 Python/2.5.2
Last-Modified: Mon, 15 Dec 2008 03:07:18 GMT
ETag: "c622-f16-45e0d23f9c580"
Accept-Ranges: bytes
Content-Length: 3862
Content-Type: text/html

La firma del server viene visualizzata anche su tutte le pagine 404: TheImportan2 Le seguenti modifiche possono essere fatte per configurare sia Apache che PHP in modo che non comunichino le loro informazioni sulla versione.

Configurazione di Apache:

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Header unset ETag
FileETag None

PHP configurations to be made in php.ini:

expose_php = Off
display_errors = Off
track_errors = Off
html_errors = Off

Configurazioni PHP da essere fatte nel file php.ini:

expose_php = Off
display_errors = Off
track_errors = Off
html_errors = Off

Dopo aver apportato le modifiche e riavviato Apache, lo stesso comando curl per recuperare le intestazioni HTTP fornisce ora informazioni minime:

$ curl -I example.com
HTTP/1.1 200 OK
Date: Sun, 25 Mar 2012 02:13:01 GMT
Server: Apache
Last-Modified: Sat, 24 Jul 2010 18:21:28 GMT
Accept-Ranges: bytes
Content-Length: 15
Vary: Accept-Encoding
Content-Type: text/html

Verifica dell’esecuzione di servizi aggiuntivi E’ fondamentale verificare e disattivare tutti i servizi in esecuzione sul server che non sono necessari. Molti spesso utilizzano un ‘web server’ e senza saperlo sul server sono in esecuzione molti altri servizi, che spesso hanno bisogno di essere verificati e sistemati. Se altri servizi sono in esecuzione sul server web, le opzioni di tali servizi devono essere modificate per eliminare ogni trasmissione del numero di versione o altre informazioni non richieste che rappresentano per noi fughe di notizie. Altri servizi che potrebbero essere in esecuzione includono SMTP (Postfix banner, o Sendmail banner), SSH (banner suffisso ssh), o anche DNS (Anche BIND dispone di un banner!). Anche se questi servizi possono essere completamente separati da qualsiasi applicazione web o web server, essere consapevoli del fatto che anche loro trasmettono informazioni sulla versione e che spesso possono fornire ulteriori informazioni a un hacker potenziale è una cosa molto utile.
Nmap può essere utilizzato per eseguire una rapida scansione dei servizi aperti in esecuzione sull’host e anche riferire i banner pubblicati da ciascun servizio. Il comando nmap da utilizzare è:

$ sudo nmap -sV [target]

Di seguito è riportato un server Linux che espone molti servizi aperti a internet, tutte le informazioni sulla versione sono trasmesse nel banner:

$ sudo nmap -sV example.com
Password:

Starting Nmap 5.51 ( http://nmap.org ) at 2012-03-24 21:46 EDT
Nmap scan report for example.com (192.168.1.120)
Host is up (0.051s latency).
rDNS record for 192.168.1.120: test.example.com
Not shown: 986 closed ports
PORT    STATE   SERVICE     VERSION
22/tcp   open   ssh         OpenSSH 5.1p1 Debian 5 (protocol 2.0)
25/tcp   open   smtp        Postfix smtpd
53/tcp   open   domain      ISC BIND 9.6-ESV-R4
80/tcp   open   http        Apache httpd 2.2.9 ((Debian) DAV/2 SVN/1.5.1 Phusion_Passenger/2.2.11 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_wsgi/2.5 Pyth...)
110/tcp  open   ssh         OpenSSH 5.1p1 Debian 5 (protocol 2.0)
111/tcp  open   rpcbind
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
443/tcp  open   ssl/http    Apache httpd 2.2.9 ((Debian) DAV/2 SVN/1.5.1 Phusion_Passenger/2.2.11 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_wsgi/2.5 Pyth...)
445/tcp  open   netbios-ssn Samba smbd 3.X (workgroup: HOME)
465/tcp  open   ssl/smtp    Postfix smtpd
587/tcp  open   smtp        Postfix smtpd
1720/tcp filtered H.323/Q.931
4444/tcp filtered krb524
Service Info: Host:  example.com; OS: Linux

Qui di seguito sono elencati alcuni servizi che potrebbero essere in esecuzione sul vostro host web che potrebbero avere il banner configurato per rivelare una quantità minima di informazioni:
Disattivare il suffisso SSH Debian e Ubuntu consentono agli utenti di disattivare il suffisso sulla versione Debian dal banner SSH impostando la seguente opzione nel file /etc/ssh/sshd_config:

DebianBanner no

Disabilitare il banner postfix Il banner di Postfix è facilmente configurabile in /etc/postfix/main.cf modificando la seguente riga nel modo desiderato:
smtpd_banner = Hello!

Speriamo samba non sia raggungibile da Internet, ma il banner del server samba è configurabile nel file /etc/samba/smb.conf

server string = Samba Server Version %v

Rimuovere la versione dal banner di BIND Utilizzare questa configurazione nel vostro named.conf per disabilitare la trasmissione della versione: opzioni
options
{
version "Not disclosed";
}

Considerazioni sul Firewall

Tutti i server Linux dovrebbero utilizzare il firewall integrato che nella maggior parte dei casi è iptables. Red Hat rende molto semplice l’interfaccia a linea di comando per la gestione del firewall. Non c’è più bisogno di scrivere complessi script iptables a meno che non vi sia una particolare esigenza o il desiderio di farlo. Debian e Ubuntu integrano un’applicazione chiamata ufw che è una interfaccia a linea di comando per iptables. Utilizzando ufw, con semplici comandi è possibile aprire o chiudere le porte, senza la necessità di essere un mago di iptables.

Red Hat’s firewall management tool:

# system-config-firewall-tui

theImportan3  

Indipendentemente se firewall aggiuntivi sono a posto, Il softarew del firewall interno al server deve essere sempre abilitato. Solo i servizi ammessi dovrebbe essere in grado di comunicare dentro e fuori alle porte e interfacce di rete specifiche. Considerate il caso in cui il firewall perimetrale di un’azienda sia compromesso. L’unico strato di difesa sarebbe il software di firewall presente sull’host. E allo stesso modo, se l’host è compromessa attraverso una applicazione web, limitare l’accesso del traffico di rete di quella server fornisce una certa protezione contro l’intrusione.

Disabilitare ICMP – Non richiesto Molti amministratori spesso disattivano o filtrano le richieste ICMP, anche se questo non ha effetti sulla sicurezza. Nel caso di qualcosa di simile al DNS, le richieste ICMP vengono effettivamente utilizzate nelle specifiche DNS per interrogare se un server è disponibile prima di inviare la richiesta DNS. Le risposte ICMP sono estremamente vantaggiose per server web in quanto possono servire per la risoluzione di un server web che sembra non rispondere più alle richieste HTTP. La minaccia di un ping flood è minima oggi. A meno che l’attaccante abbia una larghezza di banda notevolmente più grande rispetto al bersaglio, il tentativo di flood provocherà un effetto minimo. Le risposte Ping echo utilizzano molto poca CPU quindi forse è un po’ come gettare tanti sassolini nel tentativo di abbattere un muro di mattoni. È per questo che la maggior parte degli attacchi DoS di oggi si concentrano su richieste HTTP invece che ICMP in quanto è molto più facile far aumentare l’utilizzo di CPU e di memoria dal server web in questo modo. In breve, non vi è motivo per disabilitare ICMP.

Permessi

I permessi dei file e delle directory in Linux sono spesso un argomento confuso che porta a diversi punti di vista, in particolare nel caso di directory e file web. Il peggior consiglio, che non dovrebbe mai essere seguito, è quello di modificare i file o le cartelle a 777. Questo consente a chiunque in tutto il mondo di eseguire o scrivere sul server. Il miglior esempio di questo è un plugin malware di WordPress che gli hacker malintenzionati utilizzano sul server tramite un semplice comando HTTP POST. Se le autorizzazioni della directory sono 777, questo permette a chiunque di leggere, scrivere o eseguire qualsiasi cosa in quella directory compresa la pubblicazione di codice dannoso.

Molti utenti di WordPress, in particolare, sono stati recentemente compromessi da un plugin maligno che è stato installato in quanto gli utenti avevano modificato le autorizzazioni a 777 per l’installazione di WordPress.

Di seguito è riportato un esempio di log di un utente remoto malintenzionato che usa la remote exploit di un plugin direttamente nella directory dei plugin di WordPress con una singola richiesta HTTP POST:
xx.xx.xxx.xxx - - [06/Mar/2012:03:17:41 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)"
In generale, le directory dovrebbero essere 750 o 755. I file dovrebbe essere 644 o 640. I seguenti comandi possono essere utilizzati per individuare directory directory e file sul server web, che sono 777.

Individuare le directory che sono 777 sul server:

$ sudo find /var/www/ -type d -perm -002

Individuare i file che sono 777 sul server:

$ sudo find /var/www/ -type f -perm -002

A parte la lettura/scrittura/permessi di esecuzione, anche la proprietà del file ha anche bisogno di attenzione. La directory sul server Web non deve essere di proprietà dell’utente apache. Un utente normale dovrebbe essere il proprietario della directory web, e il gruppo deve essere l’utente apache. Anche se la lettura /scrittura/esecuzione autorizzazioni sono ben fatti, un processo canaglia o una applicazione php possono avere pieno accesso per apportare modifiche alla vostra intera web directory.

Questo cambio di proprietà può rendere purtroppo gli aggiornamenti tramite l’apposito pulsante di Drupal e WordPress problematico. Nell’essere consapevoli della sicurezza, si consiglia di modificare temporaneamente la proprietà all’utente apache ai fini dell’applicazione di aggiornamenti tramite un’interfaccia web, e quindi modificare la proprietà di nuovo ad un utente normale dopo che gli aggiornamenti sono stati completati.

Di seguito è riportato una pagina di esempio di amministrazione hacker di un server che è stato compromesso da povere autorizzazioni, dove l’utente apache era configurato come proprietario e il gruppo:
TheImportan4

applicazioni PHP

Avere PHP in esecuzione su un server Linux è necessario per molte applicazioni popolari come Drupal, WordPress, ed altre. Nuove vulnerabilità si trovano non solo nel codice scritto male in PHP, ma nel linguaggio stesso ad un ritmo allarmante. Viche che il PHP è spesso accoppiato con MySQL una compromissione PHP può significare compromettere il database MySQL utilizzato dal server web. A tal fine, è fondamentale effettuare qualsiasi aggiornamento del software PHP o dei suoi plugin. Non installare o utilizzare codice PHP da fonti sconosciute. Per il software di blogging, ridurre al minimo il numero di plug-in o estensioni in uso. Se un plugin o add-on non è attivato o in uso sul blog o sito web, rimuovere i file non utilizzati dal server. Assicurarsi che le pagine 404 del server non forniscono alcuna informazione estranee e non interpretino ciò che è stato messo nella barra degli indirizzi. Visitare una pagina a caso 404 sul server web per fare un test come http://example.com/asdf. I risultati della pagina 404 dovrebbero fornire solo un generico ‘Siamo spiacenti, la pagina non è stata trovata’ e non cercare di interpretare o inoltrare i risultati che l’utente ha inserito nella barra degli indirizzi. Le pagine 404 che consentono la manipolazione di input dell’utente sono un punto di ingresso per gli attaccanti con XSS artigianali e altri tentativi dannosi.

Tenere sotto controllo i Log

I log sono una parte fondamentale per il monitoraggio della sicurezza di un server web. Molti strumenti esistono nelle distribuzioni Linux per automatizzare il monitoraggio dei log. L’applicazione logwatch invia un rapporto giornaliero delle e-mail di tutti i log del server per informnarvi del variare delle voci di registro, come il numero di email inviate, potenziali aggressori web e IP che causano errori nei log di Apache, tentativi di attacchi su ssh e altri aspetti. In un ambiente aziendale di grandi dimensioni, è comune inviare le e-mail di logwatch insieme ad altra posta diretta per l’utente root (cron, errori e messaggi di sistema) in un unica e-mail ad una lista aziendale. Gli amministratori dei sistemi della società poi si iscrivono a tale lista e-mail per essere sempre informati di eventuali segnalazioni allarmanti nei log dei vari server.

Risorse aggiuntive

La NSA ha in passato pubblicato molti documenti su come proteggere i server Red Hat Linux, che possono valere anche per altre distribuzioni. Al momento di questo post del blog, la NSA ha tolto link a queste guide. Tuttavia, il documento è ancora disponibile a questo percorso:

http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

Conclusioni

Linux è un sistema operativo popolare per i server web e di hosting web ed è, purtroppo, allo stesso modo un obiettivo popolare per gli atatcchi. Un Esame rigoroso per la sicurezza è necessario per garantire di mitigare ed evitare attacchi e tentativi per l’inserimento di codice maligno. Facendo attenzione a ridurre la fuga di informazioni, limitare le autorizzazioni, mantenere le applicazioni PHP e tutto il resto aggiornato e controllare tutti i log del server aiuterà l’amministratore del sistema aggiornato su tutti gli atatcchi ed eventuali problemi saranno risolti quanto prima.

Popular Posts:

flattr this!

  3 Responses to “L’importanza di mettere in sicurezza un server Web Linux”

  1. Real life example: The hosting customer demands their directories to have permission 777, Selinux must be disabled and they have bad code everywhere and If you don’t answer that need, they will move on to somebody else and you wil loose that income.
    How about that?

    • I understand your point, the problem is, who they will blame when they will be hacked and/or defaced ?
      My suggestions:

      1) Try to talk with him and explain that setting up that kind of permissions is highly dangerous for their business, and propose to them an alternative.
      2) If they continue to ask for an insecure setup ask them to write/sign that they understand that they are the only responsible for any security problem, because you can guarantee anything with that setup.

  2. Great article that sums up everything together. An additional section on SELinux would probably be fitting, since it is very important not to overlook it as well especially on public facing servers. SELinux can block activity even after an initial security breach on the system.

 Leave a Reply

(required)

(required)


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>