Linux e le reti LAMP Server

Transcript

1 Linux e le reti LAMP Server Università degli Studi di Firenze Facoltà di Ingegneria Alessio Bazzica alessio.bazzica@gmail.com

2 Licenza d'uso Licenza d uso Questo documento è rilasciato con licenza Creative Commons Questo Attribution-NonCommercial-ShareAlike documento è rilasciato con licenza ed è possibile: riprodurre, distribuire, comunicare, esporre, rappresentare, Creative Commons Attribution-NonCommercial-ShareAlike eseguire, recitare o modificare quest opera. ed è possibile: riprodurre, distribuire, comunicare, esporre, rappresentare, eseguire, recitare o modificare quest opera. Chi usufruisce del presente materiale è tenuto a: attribuirne la paternità (citando nome, cognome ed indirizzo dell autore), non usarlo per fini commerciali o redistribuirlo, se modificato, solo con una licenza identica a questa. Chi usufruisce del presente materiale è tenuto a: attribuirne la paternità (citando nome, cognome ed indirizzo dell autore), non usarlo per fini commerciali o redistribuirlo, se modificato, solo con una licenza identica a questa. Maggiori informazioni sul tipo di licenza impiegata possono essere reperite all indirizzo Maggiori informazioni sul tipo di licenza impiegata possono essere reperite all indirizzo I marchi citati sono di proprietà delle rispettive aziende. I marchi citati sono di proprietà delle rispettive aziende. 2

3 Introduzione In questa sede concentriamo l attenzione sull installazione di un server web LAMP (Linux Apache MySQL PHP) che possiamo usare per pubblicare CMS, gestionali, forum e wiki solitamente usati nelle reti interne delle aziende. 3

4 Introduzione Da anni utilizziamo internet per accedere alle pagine web e ogni giorno vengono effettuate miliardi di richieste verso i server web di tutto il mondo. Nonostante ciò il deployment di un server web non è scontato. Dobbiamo scegliere la distro più adatta, i pacchetti da installare e la loro configurazione in base a fattori come: tipo di applicazione ospitata prestazioni richieste esposizione ad attacchi architettura server amministrazione 4

5 Introduzione Verranno analizzate alcune tecniche per la messa in piedi di un server LAMP: lo scopo è mostrare come operare in modo ordinato con Linux per garantire disponibilità del servizio, sicurezza e stabilità e facilitare la manutenzione. Le modalità di lavoro qui esposte dovrebbero diventare uno spunto anche per la messa in piedi di altri servizi (es. server di posta, server dns). Questo documento non intende essere un HowTo: sarebbe lavoro inutile riportare ritagli delle ottime e complete documentazioni disponibili in rete. 5

6 Obiettivo L obiettivo è costruire un sistema affidabile e sicuro: questo può non coincidere con assemblare hardware, sistema operativo, servizi e applicazioni in modo indipendente. È necessario partire dalle funzionalità richieste dalle applicazioni web ospitate e vedere tutti i componenti come un unico sistema. l applicazione potrebbe gestire i permessi su determinati file i servizi ereditano vulnerabilità dal sistema operativo un file system potrebbe essere un unità remota condivisa 6

7 Scelta della distro 7

8 Scelta della distro Per scegliere la distro GNU Linux più adatta dobbiamo valutare i seguenti fattori: compatibilità hardware (in particolare controller RAID e NIC) supporto e costi (per garantire la continuità a volte non è sufficiente un bravo amministratore di rete quindi è bene prendere in considerazione anche soluzioni commerciali) gestore dei pacchetti (e/o dei ports), tempi di rilascio degli aggiornamenti documentazione (ufficiale e non, una comunità attiva può aiutarci più efficacemente) disponibilità di pacchetti e/o librerie rilasciati e testati per la distro necessari alla/e applicazione/i web da installare (es. non tutti i ports per BSD offrono le caratteristiche dei pacchetti originali rilasciati per Linux) periodo di supporto (evitare migrazioni frequenti, implicano interruzione del servizio quindi SLA ridotti) 8

9 Ambiente di Test e Installazione 9

10 Ambiente di Test È fondamentale effettuare test: testare la distro prima di installare sui server di produzione se possibile riprodurre stesso ambiente di rete utilizzare lo stesso hardware obbligatoriamente stessa architettura (x86, PPC, etc.) possibilmente stessi controller RAID e/o SCSI se possibile affiancare al server di produzione una macchina di test evitare di compilare sulla macchina in produzione provare procedure di aggiornamento (es. passaggio da PHP 4 a PHP 5) 10

11 Ambiente di Test Una seconda macchina può essere utile anche per altri scopi: fornire agli sviluppatori un ambiente quanto più simile al server di produzione (es. provare nuove librerie, testare modifiche all applicazione e/o alle impostazioni) tools per team sviluppatori e amministratori, tools di manutenzione repository delle versioni (cvs, svn) pianificazioni eventi (cron) backup fornire agli utenti finali una ulteriore copia dell applicazione (esercitazioni periodiche, prove con operazioni delicate) È necessario sincronizzare periodicamente con macchina in produzione. 11

12 Ambiente di Test Le configurazioni finali create sulla macchina di test possono essere facilmente esportate sulla macchina di produzione: solitamente si tratta di copiare dei file con estensione.conf e di riavviare eventuali demoni coinvolti (es. dopo un cambiamento in apache2.conf è necessario riavviare il server web Apache)..conf.conf.conf 12

13 Installazione La prima fase consiste nell installazione di un ambiente di base (le modalità variano in base alla distribuzione scelta). Successivamente è necessario personalizzare il server con: moduli aggiuntivi di Apache (es. mod_security) moduli aggiuntivi di PHP (es. php-cli, pear, gd, curl, sqlite, xsl, ldap,...) pacchetti per l amministrazione e utility (es. openssh-server, cvs, lynx,...) front-end web amministrativi (es. phpmyadmin) 13

14 Apache Hardening 14

15 Apache Hardening Problema: spesso si crede che sia sufficiente effettuare gli aggiornamenti per avere un sistema sicuro. Hardening: step fondamentale, implementazione delle politiche di sicurezza e tuning del kernel e dei demoni. Obiettivo: rendere più robusto dagli attacchi il server ovvero minimizzare i possibili danni in caso di attacco. Come utile riferimento consultare in cui sono disponibili linee guida per l hardening dei sistemi operativi, dei servizi che operano su di essi e degli apparati di rete. 15

16 Apache Hardening Elenchiamo gli step per l hardening di Apache: separare le directory per binari, document root e log creare un utente ristretto per l esecuzione del demone scaricare e compilare i sorgenti di Apache* configurare il demone Apache, rimuovere i file non necessari creare un certificato SSL e installare mod_ssl installare e configurare mod_security creare una jail *: solitamente non necessario 16

17 Apache Hardening Creare utente e gruppo ristretto per l esecuzione del demone Quando un utente avvia un eseguibile dalla propria sessione il programma eredita i permessi dell utente. demone (o servizio) user daemon programma in ascolto su una o più porte e su una o più interfacce può essere caricato all avvio, è necessario indicare con quale utente (e gruppo) lanciarlo utilizzare utenti e gruppi ad-hoc con diritti minimi strettamente necessaria per la corretta esecuzione del demone 17

18 Apache Hardening Creare utente e gruppo ristretto per l esecuzione del demone Quando un utente avvia un eseguibile dalla propria sessione il programma eredita i permessi dell utente. i demoni sanno solo prendere i diritti degli utenti che li invocano, sacrifichiamo utenti ristretti demone (o servizio) user daemon programma in ascolto su una o più porte e su una o più interfacce può essere caricato all avvio, è necessario indicare con quale utente (e gruppo) lanciarlo utilizzare utenti e gruppi ad-hoc con diritti minimi strettamente necessaria per la corretta esecuzione del demone 17

19 Apache Hardening Tipicamente vengono usati i nomi nobody, www, httpd o www-data. Anche questa operazione viene già eseguita dallo script di installazione del package; vediamo comunque questi comandi: # groupadd httpd crea il gruppo httpd # useradd -d /var/www/ -g httpd -c Web Server aggiunge l utente httpd appartenente al gruppo httpd # passwd -l httpd blocca l utente (utilizzabile solo dall utente root) # usermod -s /bin/false httpd rimuove la shell per l account $ login httpd testare tentando il login (deve fallire) 18

20 Apache Hardening Scaricare e compilare i sorgenti di Apache In generale compilare un servizio può essere utile per: migliorare le prestazioni compilazione sulla propria macchina scelta dei parametri di compilazione compilazione statica delle estensioni (no chiamate a librerie condivise) migliorare la sicurezza Abbiamo due opzioni per gestire la compilazione: manualmente (download, verifica autenticità e integrità, compilazione, installazione) tramite package manager di sistema (preferibile) 19

21 Apache Hardening Sicurezza di Apache: possiamo cambiare i banner del server web per disorientare gli attaccanti e gli strumenti di fingerprinting. Problema: tecniche di fingerprinting avanzate. tools come nikto e nmap inviano sequenze di pacchetti sonda (TCP, UDP o IP) cercando di scatenare risposte note proprie di un certo sistema per accertarne o ipotizzarne l identità individuano il sistema operativo individuano i servizi in ascolto e le versioni dei software si basano anche sul modo con cui vengono respinte richieste e/o pacchetti comunque cambiando i banner mettiamo in difficoltà gli attaccanti Per approfondimenti: e 20

22 Apache Hardening Chi attacca prova di tutto per conoscere di più sull host: Nota: è possibile configurare Apache per passare al modulo PHP i file.htm in modo da mascherare il linguaggio di scripting utilizzato PHP 4 PHP 5 21

23 Apache Hardening Compilazione gestita manualmente: scaricare i sorgenti da $ wget verificare integrità ed autenticità dei sorgenti $ wget $ wget $ wget $ pgp -ka KEYS $ pgp httpd-2.2.x.tar.gz verificare presenza messaggio Good signature (autenticità) $ cat httpd-2.2.x.tar.gz.md5 $ md5 httpd-2.2.x.tar.gz.md5 verificare che i checksum siano uguali (integrità) configurazione + compilazione + installazione (vedere documentazione) $./configure <parametri> $ make && sudo make install 22

24 Apache Hardening Compilazione gestita da package manager (es. Debian): indicare il mirror dal quale reperire i sorgenti (se necessario) $ vi /etc/apt/sources.lists aggiungere linea: deb-src dapper main installare le chiavi per la verifica dell autenticità dei pacchetti (se necessario) $ wget -O- sudo apt-key add - download dei sorgenti e installazione delle dipendenze $ apt-get source <package-name> $ apt-get build-dep <package-name> tecnica Debian: creare un package (file.deb) dai sorgenti $ cd <package-sources-dir> $ debuild -us -uc $ cd.. $ dpkg --install <package-name>.deb 23

25 Apache Hardening Configurare il demone Apache La configurazione di base risiede in apache2.conf o httpd.conf (vedi documentazione). Fanno parte della configurazione anche i file.htaccess: posizionati all interno della document root permettono di ridefinire alcuni parametri per la directory in cui risiedono evitarne l uso manutenzione più difficile se si cambia un parametro in apache2.conf e tale parametro è stato ridefinito in molti.htaccess può essere necessario modificare singolarmente questi file potenziale vulnerabilità un attaccante potrebbe cambiare a suo favore il comportamento di una directory sovrascrivendo il file.htaccess 24

26 Apache Hardening Vediamo alcune direttive di apache2.conf. Direttiva ServerSignature Off Descrizione Nelle risposte di errore Apache non trasmette informazioni sulla versione. ServerTokens Prod Nell header HTTP Apache non trasmette informazioni sulla versione. Alias /manual Rimuovere questa direttiva per eliminare l accesso alla documentazione del server web (fornirebbe informazioni ad un attaccante). ErrorDocument <http_err_num> errors/<http_err_num>.htm Creare pagine personalizzate da inviare in caso di errore HTTP in modo da rendere ancora più difficoltoso il riconoscimento del server web. 25

27 Apache Hardening Direttiva Descrizione <Directory /> Order Deny, Allow deny from all </Directory> Serve a prevenire l accesso alla root del file system. <Directory /var/www/"> <LimitExcept GET POST> deny from all </LimitExcept> Options -FollowSymLinks -Includes -Indexes -MultiViews AllowOverride None Order allow,deny Allow from all </Directory> LimitExcept abilita soltanto richieste GET e POST disabilitando in particolare richieste TRACE che permettono ad un attaccante di individuare server proxy. AllowOverride None disabilita l utilizzo dei file.htaccess. 26

28 Apache Hardening Apache può essere esteso tramite moduli (per esempio PHP può essere installato come modulo). Vediamo alcuni dei moduli più noti: info, status: sicuramente da disattivare, forniscono informazioni ad un eventuale attaccante autoindex: sicuramente da disattivare, permette il browsing delle directory in assenza di un file predefinito userdir: se non necessario disabilitare, abilita l accesso alle home degli utenti ssl: vivamente consigliata, abilita la gestione delle richieste HTTPS utili non solo per accertare l identità del server al quale i client si connettono ma anche per crittografare il traffico ed evitare di trasmettere in chiaro credenziali e/o contenuti privati In generale la migliore politica è disabilitare ciò che non è necessario; questo principio vale quindi anche per la configurazione e la scelta dei moduli di Apache. 27

29 Apache Hardening Creare un certificato SSL e installare mod_ssl HTTPS permette di crittografare il traffico tra client e server e di autenticare tali host. L autenticazione è per entrambi gli host non solo per il server: certificato lato server certificati firmati da enti accreditati (i browser fanno riferimento a tali enti per la verifica dei certificati) oppure self-signed certificato lato client può essere generato al volo dai client sprovvisti di un certificato ad-hoc (utilizzo comune) oppure il client possiede un certificato firmato con la chiave privata del server che è stato consegnato per potersi autenticare (es. accesso servizi finanziari online) In teoria solo nel caso in cui il server web sia in DMZ possiamo configurare Apache con HTTPS ma ci sono casi in cui anche anche altri host di supporto sfruttino lo stesso certificato del server. 28

30 Apache Hardening Supponiamo di disporre del certificato (self-signed o acquistato presso un ente accreditato). Per comunicare attraverso un canale SSL sono necessari il certificato da inviare al client (server.crt, verrà utilizzato per verificare l identità del server) e la chiave privata (server.key). La configurazione di Apache dovrà puntare a questi file: copiamoli in un directory dedicata con i permessi corretti. In particolare fare attenzione ai permessi di server.key! Secondo voi? Alcune buone norme per la generazione dei certificati: generare la chiave privata in un contesto sicuro non trasmettere la chiave privata attraverso canali in chiaro, evitare in ogni caso di trasferirla tenere la chiave privata nel file system solo dove è necessaria e con i permessi corretti 29

31 Apache Hardening Installare e configurare mod_security mod_security ( è un modulo di Apache: layer di filtraggio normalizzazione SecFilterCheckURLEncoding On, SecFilterCheckUnicodeEncoding On pattern matching SecFilter drop[[:space:]]table protegge da index.php?execsql=drop%20table%20log logging e auditing SecAuditLog /var/log/apache2/modsec_log configurazione caricata all avvio di Apache non è possibile la configurazione a runtime quindi non è un IDS 30

32 Apache Hardening mod_security può essere utile anche per patchare le applicazioni in attesa del rilascio di un bugfix. Vediamo un semplice esempio: loadpage.php <?php if(!$_get[ PAGE_ID ]) { $_GET[ PAGE_ID ] = 1; //default page } $SQL = SELECT FileToInclude FROM pages WHERE PageID =. $_GET[ PAGE_ID ];?> //send query, fetch result, include required page... require pages/. $RS[ FileToInclude ]; Questo script può essere sfruttato per un attacco di SQL injection: 31

33 Apache Hardening Il bug fix in questo caso sarebbe banale: loadpage_fixed.php <?php if(!eregi( ^[0-9]+$, $_GET[ PAGE_ID ])) { $_GET[ PAGE_ID ] = 1; //default page } $SQL = SELECT FileToInclude FROM pages WHERE PageID =. $_GET[ PAGE_ID ];?> //send query, fetch result, include required page... require pages/. $RS[ FileToInclude ]; Con mod_security basterebbe aggiungere questa linea (analoga al bugfix): SecFilter ARGS:PAGE_ID!([0-9]+) Nota: SecFilter drop[[:space:]]table protegge solo dal comando DROP TABLE, un attaccante può usare altro codice SQL 32

34 Apache Hardening Aiuta anche con le tecniche di evasione: tenendo conto che il file richiesto si trova in /var/www/ viene normalizzata in: Nota: questo filtro serve a niente se poi il codice non controlla la directory! if( eregi( ^/var/www/, $_GET[ FILE ]) &&!eregi( /../, $_GET[ FILE ]) ) {... } mod_security è di supporto, le applicazioni devono comunque validare l input sempre. Utilizzi avanzati: filtraggio nei reverse proxy jailing introduciamo la tecnica, poi vediamo come implementare con mod_security 33

35 Apache Hardening Creare una jail jail (o ambiente chrooted): ambiente ristretto per l esecuzione di un demone In sintesi questa tecnica consiste nel far vedere al demone come root del file system una subdirectory della root reale. la jail non può accedere al resto del sistema operativo il sistema operativo può accedere alla jail JAIL jail di Solaris migliori: vere e proprie virtual machines in Linux solo a livello di filesystem, no separazione CPU e RAM in teoria le tecniche di evasione non portano da nessuna parte o meglio non portano fuori dalla jail! solo in teoria: cercare in rete breaking chroot jail 34

36 Apache Hardening L implementazione manuale non è facile: è necessario copiare manualmente le librerie necessarie al demone imprigionato ; altrimenti possiamo compilare tutto staticamente. in entrambi i casi un aggiornamento di una libreria implica un intervento (copia della libreria aggiornata nella jail o ricompilazione); preferibile la prima scelta Altre soluzioni: con makejail solo nei sistemi Debian-like, funziona tentando iterativamente l avvio del demone nella jail e copiando in automatico eventuali librerie mancanti che fanno fallire l avvio (non risolve il problema della soluzione con copia manuale) con mod_security soluzione migliore, non abbiamo più problemi quando aggiorniamo librerie inoltre l implementazione è comune a tutte le distribuzioni 35

37 Apache Hardening L implementazione con mod_security è veramente semplice: è sufficiente indicare nella direttiva SecChrootDir il percorso per la jail. Inoltre nella documentazione è riportato un aspetto molto interessante: With mod_security under your belt, you only need to add one line to the configuration file: SecChrootDir /chroot/apache and your web server will be chrooted successfully. Apart from simplicity, mod_security chrooting brings another significant advantage. Unlike external chrooting (mentioned previously) mod_security chrooting requires no additional files to exist in jail. The chroot call is made after web server initialisation but before forking. Because of this, all shared libraries are already loaded, all web server modules are initialised, and log files are opened. You only need your data in jail. Tratto da: 36

38 Apache Hardening Attacchi DoS (Denial of Service) È sempre buona norma limitare le risorse: limiti hardware RAM CPU banda connessione alla rete stima carico di lavoro max connessioni simultanee memoria per sessione Consultare 37

39 PHP e MySQL 38

40 PHP PHP non è direttamente esposto però alcuni parametri riflettono ciò che le applicazioni possono fare. Dobbiamo quindi limitare i danni potenzialmente causati da applicazioni scritte male. Il file di configurazione è fondamentalmente suddiviso in sezioni che riguardano: sicurezza (in particolare register_globals, variables_order, magic_quotes_gpc) gestione di errori e log prestazioni preferenze di base e delle estensioni compatibilità con precedenti versioni di PHP Vediamo solo alcune direttive, gli aspetti di sicurezza sono ben documentati (consultare sezione Security nella documentazione ufficiale di PHP). 39

41 Configurazione di PHP register_globals = Off Se è On le variabili passate come POST o GET vengono istanziate come variabili con visibilità globale. In questo esempio, se la direttiva è impostata ad On, si avrebbe una grave falla di sicurezza nel sistema di autenticazione: index.php <?php //Make MySession object... if(mysession::isauth()) { $blnloggeduser = true; } if($blnloggeduser) { include 'private_zone.php'; }?> open_basedir = /directory/base Qualsiasi richiesta di apertura file viene soddisfatta solamente se il file è contenuto nella directory indicata o in una sua sotto directory. 40

42 Configurazione di PHP register_globals = Off Se è On le variabili passate come POST o GET vengono istanziate come variabili con visibilità globale. In questo esempio, se la direttiva è impostata ad On, si avrebbe una grave falla di sicurezza nel sistema di autenticazione: index.php <?php index.php?blnloggeduser=true //Make MySession object... if(mysession::isauth()) { $blnloggeduser = true; } if($blnloggeduser) { include 'private_zone.php'; }?> open_basedir = /directory/base Qualsiasi richiesta di apertura file viene soddisfatta solamente se il file è contenuto nella directory indicata o in una sua sotto directory. 40

43 Configurazione di PHP expose_php = Off Evita che venga rilevata la presenza di PHP (e soprattutto il relativo numero di versione) negli header inviati al client. display_errors = Off Eventuali errori (percorsi, file, SQL, numeri di riga, etc.) sarebbero utili ad un attaccante; un applicazione scritta bene dovrebbe richiamare un file di impostazioni d ambiente che a runtime imposti questa direttiva ad Off. error_reporting = E_ALL Livello di verbosità degli errori. Ci sono varie opzioni. Tale livello è in comune agli errori restituiti al client e agli errori annotati nel file di log. 41

44 PHP Si possono fare molte altre considerazioni sulla sicurezza di PHP ma tutto dipende da come sono scritte le applicazioni. Per un sistemista e/o amministratore i possibili scenari sono sostanzialmente due: conosce le applicazioni ospitate conosce il team di sviluppo è anche uno sviluppatore pubblica un applicazione come un CMS non effettua il deployment amministrazione di un server per hosting incaricato solo per l installazione (no manutenzione) 42

45 PHP Si possono fare molte altre considerazioni sulla sicurezza di PHP ma tutto dipende da come sono scritte le applicazioni. Per un sistemista e/o amministratore i possibili scenari sono sostanzialmente due: conosce le applicazioni ospitate conosce il team di sviluppo in base all applicazione e alla fiducia verso il team di sviluppo configura PHP è anche uno sviluppatore pubblica un applicazione come un CMS non effettua il deployment amministrazione di un server per hosting incaricato solo per l installazione (no manutenzione) 42

46 PHP Si possono fare molte altre considerazioni sulla sicurezza di PHP ma tutto dipende da come sono scritte le applicazioni. Per un sistemista e/o amministratore i possibili scenari sono sostanzialmente due: conosce le applicazioni ospitate conosce il team di sviluppo in base all applicazione e alla fiducia verso il team di sviluppo configura PHP è anche uno sviluppatore pubblica un applicazione come un CMS non effettua il deployment amministrazione di un server per hosting deve contenere i possibili danni adottando ogni contromisura incaricato solo per l installazione (no manutenzione) 42

47 MySQL MySQL non è esposto a rischi come Apache in quanto il demone dovrebbe essere accessibile solo al server web. Sotto questa ipotesi è sufficiente impostare la password per l utente root (inizialmente vuota) ed eliminare ogni altro utente predefinito. In seguito è buona norma: creare utenti ad-hoc per i singoli database creare utenti ad-hoc per la manutenzione (es. backup) assegnare privilegi minimi Un altro aspetto al quale l amministratore deve fare attenzione è quali engine rendere disponibili. Un engine è un motore di memorizzazione; tra i più noti MyISAM (no transazioni, ottime prestazioni) e InnoDB (supporta transazioni, discrete prestazioni). 43

48 MySQL Se necessario è possibile utilizzare SSL per crittografare il traffico del servizio MySQL. Per attivare questa opzione nel file di configurazione di MySQL si devono indicare i file relativi al certificato e alla chiave. Questa funzionalità non è gratis quindi è da usare solo quando il traffico in chiaro è una vulnerabilità. Può risultare utile abilitare il logging di certi eventi, per esempio: query DROP DATABASE, DROP TABLE e TRUNCATE query lente 44

49 Deployment e Test finali 45

50 Deployment L amministrazione di un server difficilmente è indipendente dalle applicazioni ospitate. Il primo deployment dovrebbe essere eseguito insieme al sistemista che si è occupato dell installazione. È bene creare una procedura per la pubblicazione, segue un template: * copia dei file nella document root * init/restore data base * init/restore file esterni alla document root * assegnazione e verifica permessi (default www-data:www-data 770) * creazione/copia.htaccess dove previsti * modifica dei file di configurazione delle applicazioni o URL per l'accesso all'applicazione web o path assoluti all'applicazione e alle directory esterne alla document root 46

51 Deployment o parametri per l'invio della posta elettronica + mittente e reply to + invio tramite { (sendmail) ( (smtp smtp-over-ssl) {user@pwd}<servername serverip>:<port> ) } + numero max destinatari per ogni invio * modifica dei file di configurazione delle applicazioni o password per l'accesso al/ai database MySQL usati * test applicazione, in particolare o upload di file o invio o autenticazione + con utenti su database + con utenti su server LDAP, Raidus, etc. o generazione di file per download (es. generazione report pdf) o verificare tempi per la creazione di connessioni al database o verificare tempi per l'invio di Questa lista dovrebbe essere creata per ogni applicazione ospitata indicando i parametri specifici. 47

52 Test finali Dopo aver pubblicato e testato le funzionalità delle applicazioni è consigliabile eseguire un test complessivo di sicurezza. Utilizziamo nikto: -***** SSL support not available (see docs for SSL install instructions) ***** + Server: Microsoft-IIS/5.0 + HTTP method 'TRACE' is typically only used for debugging. It should be disabled. OSVDB /manual/images/ - Apache 2.0 directory indexing is enabled, it should only be enabled for specific directories (if required). Apache's manual should be removed and directory indexing disabled. (GET) + /scripts/ - Directory indexing of CGI directory should be disabled. (GET) + /phpinfo.php - Contains PHP configuration information (GET) + /phpmyadmin/db_details_importdocsql.php? submit_show=true&do=import&docpath=../../../../../../../etc - Needs Auth: (realm "phpmyadmin running on ") + / xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<font%20size=50>defaced<!--//-- - MyWebServer is vulnerable to HTML injection. Upgrade to a later version. (GET) 48

53 Test finali Dopo aver pubblicato e testato le funzionalità delle applicazioni è consigliabile eseguire un test complessivo di sicurezza. Utilizziamo nikto: ci sarà cascato così -***** SSL support not available facilmente? (see docs for SSL install instructions) ***** + Server: Microsoft-IIS/5.0 + HTTP method 'TRACE' is typically only used for debugging. It should be disabled. OSVDB /manual/images/ - Apache 2.0 directory indexing is enabled, it should only be enabled for specific directories (if required). Apache's manual should be removed and directory indexing disabled. (GET) + /scripts/ - Directory indexing of CGI directory should be disabled. (GET) + /phpinfo.php - Contains PHP configuration information (GET) + /phpmyadmin/db_details_importdocsql.php? submit_show=true&do=import&docpath=../../../../../../../etc - Needs Auth: (realm "phpmyadmin running on ") + / xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<font%20size=50>defaced<!--//-- - MyWebServer is vulnerable to HTML injection. Upgrade to a later version. (GET) 48

54 Test finali Dopo aver pubblicato e testato le funzionalità delle applicazioni è consigliabile eseguire un test complessivo di sicurezza. Utilizziamo nikto: ci sarà cascato così -***** SSL support not available facilmente? (see docs for SSL install instructions) ***** + Server: Microsoft-IIS/ no + HTTP method 'TRACE' is typically only used for debugging. It should be disabled. OSVDB /manual/images/ - Apache 2.0 directory indexing is enabled, it should only be enabled for specific directories (if required). Apache's manual should be removed and directory indexing disabled. (GET) + /scripts/ - Directory indexing of CGI directory should be disabled. (GET) + /phpinfo.php - Contains PHP configuration information (GET) + /phpmyadmin/db_details_importdocsql.php? submit_show=true&do=import&docpath=../../../../../../../etc - Needs Auth: (realm "phpmyadmin running on ") + / xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<font%20size=50>defaced<!--//-- - MyWebServer is vulnerable to HTML injection. Upgrade to a later version. (GET) 48