INFN Sec. Group

Sicurezza per il server WWW:
un ricettario

v 1.5
12 Maggio 1998

Roberto Cecchini


Indice

Introduzione
Script CGI
Configurazione del server
Configurazione del sistema operativo
Bibliografia
 

Introduzione

Questo documento, ben lungi dall'avere pretese esaustive sull'argomento, vuole essere un "ricettario" minimo sui passi da intraprendere per migliorare la sicurezza del proprio server web. La bibliografia dovrebbe essere un punto di partenza sufficiente per chi desideri approfondire alcuni aspetti particolari.

Ovviamente un server web non può essere sicuro se non lo è anche la macchina che lo ospita: le considerazioni sulla sicurezza in generale di una macchina unix sono reperibili in un altro documento.

 

Script CGI

Gli script CGI (Common Gateway Interface) sono una delle più comuni fonti di vulnerabiltà di un server web. Il loro numero deve essere ridotto al minimo indispensabile e vanno attentamente controllati.

  1. Guardare la bibliografia per informazioni su come scrivere degli script sicuri. Quelle che seguono sono sono alcune note sugli errori più comuni.

    • Cercare di evitare che lo script faccia lo spawn di una shell (ad esempio comando system o `...` in perl). Se viene passata una stringa non controllata per l'esistenza di caratteri speciali (ad esempio ;), possono venire eseguiti comandi arbitrari sul server.

      Mi pare che nelle nuove versioni dei server www (perlomeno Apache) i caratteri speciali siano automaticamente preceduti da \, il problema sembra quindi meno grave.

    • Controllare la lunghezza delle stringhe di input per evitare i buffer overflow.

    • Non utilizzare script SUID è molto difficile renderli sicuri. Se uno script deve proprio girare con un UID diverso da quello di httpd, usare CGIwrap o sbox, ma fare attenzione a quello che la Web security FAQ dice.

    • Se si usa Perl, utilizzare l'opzione -T (tainted perl).

  2. Eliminare le Server Side Includes (SSI) perchè possono far sì che gli utenti siano in grado di eseguire qualunque programma sul server (oltre ad avere ripercussioni negative sulle prestazioni).
    Per i server Apache e NCSA le direttive interessate sono: Option Includes (per disabilitarle totalmente), Option IncludesNoExec (per disabilitare solo la funzionalità più pericolosa) e AddType text/x-server-parsed-html ....

  3. Consentire l'esecuzione di script CGI solo da una directory ad accesso controllato (tipicamente cgi-bin): leggi non consentire agli utenti di scriversi i propri script.

  4. Attenzione ai seguenti script (possono essere utilizzati per eseguire comandi non autorizzati sul server):

    • Count.cgi, 1.0-2.3
      Serve per inserire i contatori di accesso sulle singole pagine (narcisismo puro?), ad ogni modo la versione 2.4 ha eliminato il bug.

    • php.cgi
      La versione Apache, fornita come modulo, dovrebbe essere priva di questo bug.

    • Microsoft FrontPage Extensions, 1.0-1.1

    • FormMail 1.0
      Permette di riempire un form e di inviarlo via mail all'autore. Il bug è stato corretto nelle versioni successive.

    • phf
      Veniva distribuito con i server NCSA e Apache. Va eliminato.

    • test-cgi
      Veniva distribuito con i server NCSA e Apache. Va eliminato.

    • glimpseHTTP
      Viene usato come front-end di Glimpse per indicizzare i documenti web.
      È stato abbandonato e va sostituito con WebGlimpse.

    • Excite per Web Servers, V 1.1
      Motore di ricerca per server web.
      Va sostituito con la nuova versione.
 

Configurazione del server

Gli esempi di seguito sono riferiti ai server NCSA e Apache.

  • Versioni raccomandate:

    • Apache: versioni successive alla 1.2 (caldamente consigliata la 1.2.5, con le ultimissime correzioni);
    • CERN: non sono noti bug;
    • NCSA: versioni successive alla 1.4;
    • WN: non sono noti bug.

  • Non far girare il server come root: farlo partire come root (altrimenti non è possibile utilizzare la porta 80, quella di default per http), ma poi modificarlo in utente non privilegiato: tipicamente www, gruppo www (meglio di nobody, per non interferire con altri eventuali programmi di sistema).
    Comandi User e Group in httpd.conf).

  • Permettere solo a root l'accesso alle directory di configurazione e di log.

  • Aggiungere gli utenti abilitati a modificare le pagine web al gruppo di httpd e rendere la directory radice dell'albero www scrivibile solo dai membri di questo gruppo. Ad esempio, nell'ipotesi di sopra:
    drwxr-xr-x   5 www   www    1024 Aug  8 00:01 cgi-bin/
    drwxr-x---   2 root  sys    1024 Jun 11 17:21 conf/
    -rwx------   1 www   www  109674 May  8 23:58 httpd
    drwxrwxr-x   2 www   www    1024 Aug  8 00:01 htdocs/
    drwxr-x---   2 root  sys    1024 May  4 22:23 logs/
    
    (notare le protezioni di conf e logs) mentre i documenti sotto htdocs:
    drwxrwxr-x   3 www   www    1024 Jul  1 03:54 contents
    drwxrwxr-x  10 www   www    1024 Aug 23 19:32 examples
    -rw-rw-r--   1 www   www    1488 Jun 13 23:30 index.html
    -rw-rw-r--   1 pinco www   39294 Jun 11 23:00 guide.html
    
    Questo metodo presenta l'inconveniente che, a meno di definire opportunamente l'umask, ma probabilmente non è opportuno, i file nuovi sono modificabili solo dal proprietario, che si deve ricordare di cambiare la protezione per il gruppo (quella di default è r--).

  • Non abilitare gli upload (directory incoming) via ftp anonimo sul server web, o, se proprio non si può farne a meno, non consentire a www l'accesso, nemmeno in lettura, alla directory di upload.

  • Analizzare periodicamente i propri file di log!
    Fare attenzione in particolare alle invocazioni di programmi di sistema (ad es. rm, login, chmod, ecc.) e a URL molto lunghe (potrebbero essere indicative di tentativi di overflow dei buffer di input di un programma).
 

Configurazione del sistema operativo

Nel caso sia possibile è consigliabile che la macchina su cui gira il server web sia dedicata, senza cioè account utenti (un pc con linux va benissimo). Le eventuali home page utenti (le URL ~user) possono essere montate via NFS (read-only, ovviamente) o, ancora meglio, copiate localmente (ad esempio via rdist).

Altri passi da intraprendere per migliorare la sicurezza della macchina (alcuni di questi non sono realizzabili su macchine non dedicate):

  • Tenere sempre aggiornati all'ultima versione named e sendmail.

  • Non lanciare sendmail come demone, ma periodicamente tramite cron.

  • Installare configurare tcp-wrappers, wu-ftp (in genere è migliore dell'ftp originale), tripwire e ssh (vedi documento generale sulla sicurezza).

  • Disabilitare tutte le applicazioni di rete non necessarie, ad esempio: telnet, rsh, rlogin, finger ecc..
 

Bibliografia

Ovviamente i seguenti non sono che punti di partenza.
  1. The Web security FAQ (Lincoln Stein), il testo fondamentale.
  2. The Unofficial Web Hack FAQ, molto interessante.
  3. Safe CGI Programming (Paul Phillips).
  4. Perl CGI Program (ming) (Shishir Gundavaram e Tom Christiansen), fondamentale nel suo genere.
  5. CERT advisory on CGI metacharacters, come ripulire le stringhe di input.
  6. COAST Hotlist Contents, una bibliografia sterminata, con una vasta sezione su www.
 

Roberto Cecchini

Last modified: Tue May 12 09:36:46 METDST 1998