Certificazione sistemistica

Transcript

1 AVANZATO Certificazione sistemistica Lodi settembre 2016 (prima sessione) ottobre 2016 (seconda sessione) Relazione a cura di Daniele Cinquanta 1

2 indice 1. WEB SERVER Certificati SSL + VirtualHost Moduli Configurazione file Monitoring Tool Apache vs IIS 2. APPLICATION SERVER Best Practices Log Analisys Monitoring Tools SSO & LDAP 3. DB SERVER SQL Server Best Practices SQL Server Mantenance Plan SQL Server Tools PostgreSQL Oracle accenni 4. CLIENT TOOLS Browser tools (accenni) Network analyzer 2

3 web server direttive globali Direttive globali per Windows e Linux Editare il file di configurazione conf\httpd.conf Modificare o aggiungere se non presenti le seguenti direttive: Timeout 300 la direttiva TimeOut attualmente definisce la quantità di tempo (in secondi) che Apache attenderà per tre cose: - la quantità totale di tempo necessario per ricevere una richiesta GET; - la quantità di tempo che intercorre tra la ricezione di pacchetti TCP su richiesta POST o PUT; - la quantità di tempo che intercorre tra ACKs sulla trasmissione dei pacchetti TCP nelle risposte; KeepAlive On consente di servire richieste multiple utilizzando la stessa connessione TCP; MaxKeepAliveRequests 0 indica il numero massimo di richieste che possono essere trasportate attraverso la stessa connessione TCP quando KeepAlive è impostato su On, 0 indica infinito; KeepAliveTimeout 80 indica il tempo entro il quale una richiesta viene mantenuta in vita senza passaggio di dati. Su server ad alto carico è preferibile tenere un valore basso per evitare il proliferare di connessioni attive ma senza passaggio di dati. 3

4 web server certificati ssl Funzionamento di SSL 2.0 In un primo tempo, il client si connette al sito commerciale sicuro via SSL e richiede l'autenticazione. Il client invia anche la lista dei crittosistemi che supporta, smistati per ordine decrescente secondo la lunghezza delle chiavi. Alla ricezione della richiesta il server invia un certificato al client, contenente la chiave pubblica del server, firmata da un'autorità di certificazione (CA), nonché il nome del crittosistema in cima alla lista con il quale è compatibile (la lunghezza della chiave di codificazione - 40 bit o 128 bit - sarà quella del crittosistema comune con la chiave di più grandi dimensioni). Il client verifica la validità del certificato (fra cui l'autenticità del commerciante), poi crea una chiave segreta aleatoria (più esattamente un blocco volutamente aleatorio), codifica questa chiave con la chiave pubblica del server, e gli invia il risultato (la chiave di sessione). Il server è capace di decifrare la chiave di sessione con la sua chiave privata. Così, le due entità sono in possesso di una chiave comune che solo essi conoscono. Il resto delle transazioni può farsi attraverso una chiave di sessione che garantisce l'integrità e la confidenzialità dei dati scambiati. richiesta connessione SSL con invio crittosistemi compatibili Invio certificato con chiave pubblica e crittosistema invio chiave session key generata con chiave pubblica del server il server decifra la session key con la chiave privata e stabilisce la sessione sicura 4

5 web server certificati ssl Creazione del certificato SSL Requisiti Windows: Linux: Apache 2.2/2.4 con OpenSSL e, se richiesto da Apache, Visual C++ Redistributable per Visual Studio httpd, mod_ssl e openssl via yum Creazione della richiesta di certificato (Certificate Signing Request e Private Key) aprire il prompt dei comandi / shell e, in Windows posizionarsi nella cartella bin di Apache, in Linux nella conf di httpd; solo per Windows, settare la variabile di sistema OPENSSL_CONF: set OPENSSL_CONF=C:\Apache2.2\conf\openssl.cnf (dove C:\Apache2.2 è il percorso di estrazione dei binari di Apache) creare la chiave privata del server: openssl genrsa -out server.key 2048 creare il file di richiesta del certificato: openssl req -new -key server.key -out server.csr Creazione del certificato autoprodotto (alternativa sconsigliata all'autority Certificate) creare il certificato: openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt solo per Windows, se si usa IIS, convertire il certificato in formato pfx: openssl pkcs12 -export -in server.crt -inkey server.key -out server.pfx 5

6 web server certificati ssl Configurazione del certificato SSL per Apache su Windows Editare il file di configurazione C:\Apache24\conf\httpd.conf abilitare il modulo SSL decommentando la riga LoadModule ssl_module modules/mod_ssl.so includere le istruzioni SSL decommentando la riga Include conf/extra/httpd-ssl.conf Editare il file di configurazione SSL C:\Apache24\conf\extra\httpd-ssl.conf spostare i file.crt e.key nella cartella conf; SSLCertificateFile "C:/Apache24/conf/server.crt" SSLCertificateKeyFile "C:/Apache24/conf/server.key" aggiungere le direttive per il mount degli applicativi web solo per configurazione tramite mod_jk; Se necessario, settare il virtual host con i parametri adeguati DocumentRoot "C:/Apache24/htdocs" ServerName ServerAdmin admin@example.com ErrorLog "C:/Apache24/logs/error.log" TransferLog "C:/Apache24/logs/access.log" Verificare che il server sia raggiungibili sulla porta 443 (firewall fisici e firewall di Windows) Riavviare il servizio di Apache * nel caso di configurazione del certificato SSL in modalità Reverse Proxy vedere le note a pag. 15 6

7 web server certificati ssl Configurazione del certificato SSL per Apache su Linux Controllare i file di configurazione per l'abilitazione dei moduli in Apache 2.2 se necessario, abilitare il modulo SSL decommentando la riga LoadModule ssl_module modules/mod_ssl.so se necessario, includere le istruzioni SSL decommentando la riga Include conf.d/ssl.conf Controllare i file di configurazione per l'abilitazione dei moduli in Apache 2.4 nella versione 2.4 i moduli si abilitano nel file conf.modules.d/*.conf e normalmente sono già abilitati; Editare il file di configurazione SSL /etc/httpd/conf.d/ssl.conf SSLCertificateFile "/etc/httpd/conf/server.crt" SSLCertificateKeyFile "/etc/httpd/conf/server.key" aggiungere le direttive per il mount degli applicativi web (jk_mount o proxypass); Verificare che il server sia raggiungibili sulla porta 443 (firewall fisici, software e selinux) Riavviare il servizio di Apache In RedHat6 / CentOS6 service httpd restart In RedHat7 / CentOS7 systemctl restart httpd * nel caso di configurazione del certificato SSL in modalità Reverse Proxy vedere le note a pag. 15 7

8 web server virtualhost Hosting virtuale IP-based virtual hosting Si assegnano più indirizzi IP ad un server. Questo può essere fatto associando diversi indirizzi IP ad una stessa interfaccia. A ciascun indirizzo IP è associato un nome DNS. Il server web valuta l'indirizzo IP destinazione su cui è stata ricevuta la connessione TCP (ovvero uno dei propri indirizzi), e di conseguenza sceglie quale contenuto servire. Questa tecnica è compatibile con HTTP/1.0 e con HTTPS. Lo svantaggio è che per ciascun sito è richiesto un indirizzo IP dedicato, e questo può essere costoso. Port-based virtual hosting Questa tecnica è una variante della precedente, dove il server ascolta sullo stesso indirizzo IP ma su diverse porte TCP, e a ciascuna porta TCP è associato un sito (ed eventualmente il relativo certificato). In questo modo si evita la necessità di un indirizzo IP per sito, ma si usano porte non standard, che possono essere bloccate da firewall o proxy, e si devono usare URL contenenti il numero di porta, come " più difficili da ricordare. Name-based virtual hosting Questa tecnica richiede l'uso di HTTP/1.1, che prevede l'invio di un URL contenente il nome del sito richiesto nella richiesta HTTP. Il server è configurato con un solo indirizzo IP, a cui sono associati i nomi DNS di tutti i siti ospitati. Quando il server riceve una richiesta HTTP, legge l'hostname richiesto e decide di conseguenza quale dominio servire. Questo permette di utilizzare un solo indirizzo IP per molti siti utilizzando porte TCP standard e URL senza la specifica della porta. Questa tecnica è comunemente usata da providers di spazio web per siti internet. Name-based virtual hosting con HTTPS Un server HTTPS, quando riceve una connessione TCP, deve stabilire la sessione SSL, e per fare questo deve presentare il proprio certificato per provare al client la sua identità. Se però si usa il name-based virtual hosting, ciascun sito ospitato avrà un proprio certificato, e il server che riceve una connessione TCP non sa ancora quale sito gli viene richiesto, e quindi quale certificato deve presentare. Il browser, non ricevendo il certificato corrispondente al sito che ha richiesto, mostrerebbe un errore. Per questo motivo, il name-based virtual hosting viene normalmente evitato se si deve offrire il servizio HTTPS. Questa tecnica può essere usata solo in casi particolari, ovvero quando è possibile presentare un certificato che sia accettabile per tutti i siti HTTPS ospitati, mediante l'uso di certificati con DN wildcard (*.miodominio.com) e/o di nomi alternativi nel certificato. 8

9 web server virtualhost Esempio di Name-based virtual hosting con Apache NameVirtualHost *:80 <VirtualHost *:80> ServerName DocumentRoot /var/www/html/server1 </VirtualHost> <VirtualHost *:80> ServerName DocumentRoot /var/www/html/server2 </VirtualHost> Esempio di Name-based virtual hosting con IIS 9

10 web server compressione Abilitare la compressione del contenuto Con Apache: abilitare il mod_deflate in base alla versione di Apache, nel file conf/httpd.conf o conf.modules.d/00-base.conf, abilitare (o controllare che sia abilitato) il modulo deflate decommentando la riga LoadModule deflate_module modules/mod_deflate.so Aggiungere le seguenti direttive: BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bmsie!no-gzip!gzip-only-text/html BrowserMatch \bmsi[e]!no-gzip!gzip-only-text/html AddOutputFilterByType DEFLATE text/html text/plain text/xml text/js text/jsp text/javascript text/css application/x-javascript text/javascript text/x-js application/json application/xml application/javascript Con IIS: installare il componente Dynamic Content Compression Durante l'installazione, o successivamente, installare il componente Dynamic Content Compression (il ruolo Static Content Compression viene installato con la configurazione standard, se non è installato procedere all'installazione anche di tale ruolo); Questo ruolo è presente solo dalla versione 8 di IIS. 10

11 web server mpm Configurazione MPM su Windows (Multi Processing Module) Editare il file di configurazione MPM conf\httpd.conf includere il file di configurazione MPM decommentando la riga #Include conf/extra/httpd-mpm.conf Editare il file di configurazione MPM conf\extra\httpd-mpm.conf editare la sezione # WinNT MPM ThreadsPerChild 512 imposta il numero massimo di connessioni client simultanee; MaxConnectionsPerChild 0 imposta il limite di connessioni che un processo figlio può gestire, 0 impostandolo il valore ad infinito; Configurazione MPM su Linux Verificare quale Server MPM è stato impostato httpd -V (V maiuscola): Server MPM: prefork MPM Prefork: vengono creati vari processi figli di Apache, ognuno dei quali può contenere un solo thread, che a sua volta può servire una sola connessione. MPM Prefork utilizza più memoria rispetto al modulo MPM Worker. MPM Prefork in virtù dell utilizzo di thread singoli, è più adatto a sistemi a processore singolo. Apache, avvia il numero di processi figli indicati nella direttiva StartServers. Ogni processo serve le richieste HTTP finché raggiunge il numero di richieste massime indicate in MaxRequestsPerChild dopodichè il processo viene spento e sostituito da un processo nuovo. 11

12 web server mpm Editare il file di configurazione MPM /etc/httpd/conf/httpd.conf modificare (Apache 2.2) o aggiungere (Apache 2.4) le seguenti direttive: <IfModule prefork.c> StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 </IfModule> StartServers: indica il numero di processi figli che vengono generati all avvio di apache e che resteranno in attesa di connessioni da servire. La fase di generazione di un processo è onerosa in termini di risorse del sistema quindi conviene generare direttamente tutti i processi che serviranno in previsione delle richieste HTTP. MinSpareServers: indica il numero minimo di processi figli che vengono generati e che resteranno in attesa di connessioni HTTP da servire. Su server con previsioni di alto traffico web, è buona norma tenere un valore di MinSpareServers alto, per rendere poco traumatica la gestione dell impatto delle richieste HTTP verso i processi Apache. MaxSpareServers: Il numero massimo di processi figli che vengono generati e che resteranno in attesa di connessioni HTTP da servire. ServerLimit: indica il numero massimo assoluto di processi del server creati da Apache su UNIX. MaxClients: indica ad Apache la quantità massima di clients che il demone può servire contemporaneamente. MaxRequestsPerChild: indica il numero di richieste HTTP che un processo lanciato da Apache può gestire prima di essere terminato e sostituito da un processo fresco. 12

13 web server ajp Configurazione mod_jk File di configurazione connettore mod_jk LoadModule jk_module modules/mod_jk.so JkWorkersFile conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel error JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " Include conf/jk_mount.conf mod_jk.conf worker.list = tomcat1, tomcat2, loadbalancer1 worker.tomcat1.port = 8009 worker.tomcat1.host = ServerApp1 worker.tomcat1.type = ajp13 worker.tomcat2.port = 8009 worker.tomcat2.host = ServerApp2 worker.tomcat2.type = ajp13 worker.loadbalancer1.type = lb worker.loadbalancer1.balance_workers = tomcat1, tomcat2 workers.properties JkMount JkMount JkMount JkMount JkMount JkMount jk_mount.conf /HRPortal loadbalancer1 /HRPortal/* loadbalancer1 /HR-WorkFlow loadbalancer1 /HR-WorkFlow/* loadbalancer1 /PagheJ loadbalancer1 /PagheJ/* loadbalancer1 (da includere) 13

14 web server ajp Configurazione mod_proxy_ajp abilitare i moduli mod_proxy, mod_proxy_ajp e, solo per il bilanciamento, mod_proxy_balancer; ProxyRequests Off ProxyPreserveHost On ProxyPass /HRPortal ajp://serverapp1:8009/hrportal keepalive=on ProxyPassReverse /HRPortal ajp://serverapp1:8009/hrportal ProxyPass /PagheJ ajp://serverapp2:8009/paghej keepalive=on ProxyPassReverse /PagheJ ajp://serverapp2:8009/paghej pubblicazione standard ProxyRequests Off ProxyPreserveHost On <Proxy balancer://mycluster> BalancerMember ajp:// :8009 route=tomcat_a keepalive=on BalancerMember ajp:// :8010 route=tomcat_b keepalive=on BalancerMember ajp:// :8011 route=tomcat_c keepalive=on ProxySet lbmethod=bybusyness stickysession=jsessionid jsessionid </Proxy> ProxyPass /HRPortal balancer://mycluster/hrportal ProxyPassReverse /HRPortal balancer://mycluster/hrportal ProxyPass /PagheJ balancer://mycluster/paghej ProxyPassReverse /PagheJ balancer://mycluster/paghej pubblicazione con bilanciamento <Location /balancer-manager> (opzionale) SetHandler balancer-manager </Location> 14

15 web server reverse proxy Configurazione con Reverse Proxy nel caso dell'utilizzo di un reverse proxy, in tutti gli applicativi web vanno copiati i seguenti file: <app>/web-inf/classes/initscripts/splib.config <app>/web-inf/classes/initscripts/sprefererbound.config questi file si possono reperire dall'applicazione HRPortal. 3 reverse p roxy http/htt ps y prox a jp Configurazione standard http https 1 2 sq l http https h tt htt p ps ajp * nel caso di navigazione in HTTPS attraverso il reverse proxy, il web server 3 deve comunicare in https verso il web server 1, sul quale dovrà essere installato lo stesso certificato. 15

16 autenticazione ldap Autenticazione tramite LDAP (Lightweight Directory Access Protocol) il client, tramite utente e password, richiede l'autenticazione; 2. il web server inoltra la richiesta al server application; 3. l'applicativo HRPortal verifica le impostazioni di accesso dell'utente (autenticazione tramite LDAP o tramite database); 4. se deve verificare le credenziali tramite LDAP invia utente e password al servizio LDAP ed attende la risposta; 5. in caso di credenziali corrette, l'applicativo HRPortal sincronizza la password nella tabella cpusers con quella verificata dall'ldap e controlla le autorizzazioni dell'utente nel proprio database; 6. l'applicativo invia la risposta al web server; 7. il web server inoltra la risposta al client; 16

17 web server sso Autenticazione tramite SSO (Single sign-on) il client accede alla pagina di login; 2. il web server IIS richiede al browser l'utente connesso a Windows e lo verifica tramite il DC; 3. se l'utente appartiene al dominio viene passato (solo il nome utente) ad HRPortal; 4. l'applicativo verifica se l'utente esiste nel database, in caso affermativo modifica la password con una casuale; 5. l'applicativo invia la risposta al web server; 6. il web server inoltra la risposta al client; * nel caso di accesso dall'esterno (non tramite il web server con configurazione windows authentication) vedere le note a pag

18 autenticazione portalcall Autenticazione tramite PortalCall il client accede alla pagina interna di login HRPortal/servlet/portalcall inviando i parametri necessari tramite il web server; 2. il web server invia i parametri all'applicativo; 3. l'applicativo verifica tutti i parametri e se l'utente esiste nel database, in caso affermativo modifica la password con una casuale; 4. l'applicativo invia la risposta al web server; 5. il web server inoltra la risposta al client; Parametri da passare (funzionano sia in modalità POST che in GET): FunctionID default value 0000 ApplicationID default value UserID credenziale di login al portale ERM (ad es. zucchetti ) TimeStamp generato al momentoel formato gg/mm/aaaa hh:mm:ss (compatibile anche col formato inglese aaaa/mm/gg hh:mm:ss ) MAC token di controllo criptato. Corrisponde alla criptazione tramite algoritmo MD5 della stringa risultante dal concatenamento di: << FunctionID + ApplicationID + UserID + TimeStamp + chiaveprivata >> dove quest ultima chiaveprivata è una stringa impostata e conosciuta solo lato portale chiamante e lato portale ERM, a garantire la non riproducibilità manuale del token MAC stesso. 18

19 autenticazione portalcall Autenticazione tramite PortalCall Esempio una chiamata via GET: &TimeStamp=2007/05/18 14:00:00&MAC=18f57d0e504f7c4d3a3c6ee665b3510a Esempio una chiamata via POST (da form html): <form name="ermcall" action=" method="post"> <input type="hidden" name="functionid" value="0000"> <input type="hidden" name="applicationid" value="22222"> <input type="hidden" name="userid" value="zucchetti"> <input type="hidden" name="timestamp" value="2007/05/18 14:00:00"> <input type="hidden" name="mac" value="18f57d0e504f7c4d3a3c6ee665b3510a"> <input type="submit" value="lancio portale"> </form> Il parametro MAC è il risultato della criptazione (tramite md5) dei parametri FunctionID + ApplicationID + UserID + TimeStamp + knownprivkey. Il parametro knownprivkey viene definito all'interno della configurazione del Portale HR. I parametri UserID, TimeStamp e MAC devono essere chiaramente generato dinamicamente al momento della chiamata, ad esempio: MAC = md5( zucchetti2007/05/18 14:00:00knownprivkey ) * NOTE Dopo aver eseguito l'accesso tramite SSO o PortalCall non sarà più possibile accedere tramite la pagina di login principale, in quanto la password dell'utente (nel precedente accesso) è stata modificata. Per ovviare a questa problematica è possibile configurare anche l'autenticazione tramite LDAP, in questo modo l'applicativo non verificherà la password tramite la tabella cpusers ma tramite LDAP (ovviamente l'utente dev'essere nel dominio). 19

20 Accademia Zucchetti Via Solferino, Lodi formazione.accademia@zucchetti.it tel. 0371/ fax 0371/ Copyright by Zucchetti 2015 I diritti di traduzione, di riproduzione e di adattamento totale o parziale e con qualsiasi mezzo (compresi le copie fotostatiche, i film didattici e i microfilm) sono riservati per tutti i Paesi. L'elaborazione dei testi, anche se curata con scrupolosa attenzione, non può comportare specifiche responsabilità per eventuali involontari errori o inesattezze. 20