Proteggere Owa con un Apache proxy mod

di Pubblicato: 5 agosto 2009 Aggiornato: 5 novembre 2011 0 commenti

OWA (Outlook Web Access) è l’interfaccia webmail di Microsoft Exchange, il sistema di posta di casa Microsoft. Questa interfaccia che risiede nel medesimo server che offre i protocolli MAPI e l’interfacciamento ad Active Directory, gira su un server web IIS (Internet Information Server).
E’ ovvio che non è possibile esporre direttamente questo server verso Internet, sarebbe un bersaglio ambito dai malintenzionati. Per cui solitamente si usa un proxy per disaccopiare l’accesso dalla dmz alla intranet. Microsoft vende un prodotto apposito che si chiama ISA (Internet Security Access) in pratica un Proxy con velleità di Firewall, questo software però è a pagamento e non è compreso nella suite di Exchange.

Quello che vi propongo è una soluzione a costo zero usando Apache 2.0 e le mod mod_ssl e mod_proxy, spiegando passo passo come realizzare una efficace protezione di OWA.

Prima di tutto fissiamo alcune informazioni base per la spiegazione, si suppone che abbiamo Exchange e OWA perfettamente funzionanti, altresì abbiamo un server in ambiente Linux con Apache 2.x installato e funzionate.
Il server Exchange avrà come indirizzo ip 192.168.0.100 e la risoluzione dns in exchange.lan
Il server proxy-apache sarà raggiungibile da internet tramite un indirizzo pubblico a.b.c.d risolto come webmail.mydomain.com, mentre l’indirizzo interno sarà 192.168.10.50

Primo passo sarà quello di configurare le due mods per Apache, ove non presenti. Prima di tutto verifichiamo la situazione, da linux diamo il comando a2enmod -l
Dovremmo ottenere un risultato simile a:

actions alias auth_basic authn_file authz_host authz_groupfile authz_default authz_user authn_dbm autoindex cgi dir env expires include log_config mime negotiation setenvif ssl suexec userdir php5 proxy headers proxy_http proxy_ftp proxy_connect

il nostro target è quello di vedere aggiunti in questa lista ssl, proxy, proxy_http, proxy_connect e headers. Se li avete già saltate il prossimo paragrafo.

Con il comando a2enmod -q ssl aggiungeremo il modulo ssl alla lista precedente, che ricordo viene caricata all’avvio di Apache. Ripetiamo l’operazione per i moduli restanti

a2enmod -q proxy
a2enmod -q proxy_http
a2enmod -q proxy_connect
a2enmod -q headers

Riavviamo Apache ( /etc/init.d/apache2 restart ) e i moduli saranno caricati oltre che disponibili ad essere usati.
NOTA: in SuSE Linux Enterprise 10 abbiamo aggiustato anche le direttive APACHE_SERVER_FLAGS con il valore “SSL !NOSSL” presenti in \etc\sysconfig\apache2, o tramite YAST sotto il menu System -> Config Editor: Network/WWW.

Ora passiamo alla parte più complicata da spiegare, dobbiamo modificare il file di configurazione di Apache, nel caso specifico un VirtualHost, questa è la nostra modifica nel completo, più sotto spieghiamo alcuni passaggi:

DocumentRoot "/srv/www/htdocs"
ServerName webmail.mydomain.com
RequestHeader set Front-End-Https "On"
ProxyRequests Off
ProxyPreserveHost On
ServerAdmin support@mydomain.com
ErrorLog /var/log/apache2/webmailssl_error_log
TransferLog /var/log/apache2/webmailssl_access_log
CustomLog /var/log/apache2/ssl_request_log   ssl_combined

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLCertificateFile /etc/apache2/ssl.crt/owaserver.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/owaserver.key

SetEnvIf User-Agent ".*MSIE.*" \
  nokeepalive ssl-unclean-shutdown \
  downgrade-1.0 force-response-1.0

ProxyPass  http://webmail.mydomain.com/exchange
ProxyPassReverse http://webmail.mydomain.com/exchange
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
SSLRequireSSL

ProxyPass http://webmail.mydomain.com/exchweb
ProxyPassReverse http://webmail.mydomain.com/exchweb
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
SSLRequireSSL

ProxyPass http://webmail.mydomain.com/public
ProxyPassReverse http://webmail.mydomain.com/public
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
SSLRequireSSL

La chiamata ProxyPreserveHost inoltra l’header originale da parte del client al server (exchange).
RequestHeader forza l’uso di https:// al posto di http:// ed è richiesto per creare un tunnel SSL in quanto OWA offre l’autenticazione solo in chiaro, per cui è meglio avere una protezione criptata quando si offrono le proprie username e password.
SSLcertifcate files (.crt e .key in formato PEM) richiedo un certificato autofirmato se non volete spendere soldi, oppure uno acquistato dalle società di sicurezza tipo Verisign.

Ora la parte più interessante:

ProxyPass  http://webmail.mydomain.com/exchange
ProxyPassReverse http://webmail.mydomain.com/exchange
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
SSLRequireSSL

nell’uso di OWA occorre passare in proxy le subdomain /exchange /exchweb e /public.
Tramite SetEnv force-proxy-request-1.0 e SetEnv proxy-nokeepalive andremo a bypassare alcune problematiche di OWA con Apache, come riportato in questo estratto dalla documentazione Apache.

[Protocol Adjustments]
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

For circumstances where you have a application server which doesn’t
implement keepalives or HTTP/1.1 properly, there are 2 environment
variables which when set send a HTTP/1.0 with no keepalive. These are set
via the SetEnv directive.

Bene abbiamo quasi finito, dobbiamo solo indicare al server dove gira Apache come risolvere webmail.mydomain.com, visto che internamente girerà probabilmente su un suffisso diverso. Apriamo il file /etc/hosts ed aggiungiamo
192.168.0.100 webmail.mydomain.com

Operazione completata, riavviamo apache e le schede di rete e proviamo ad accedere dall’esterno alla nostra webmail all’indirizzo https://webmail.mydomain.com/exchange in cui dovrebbe apparire la pop-up con richiesta credenziali di Exchange (forse prima dovrete accettare il certificato se è autofirmato).

Un ultima nota, tutto quanto funziona se andiamo a puntare all’indirizzo https e con la declinazione /exchange, se invece puntate in http a webmail.mydomain.com otterrete una pagina di errore. Per redirigere in automatico la vostra utenza (e salvarvi da chiamate inutili in assistenza) potete usare questa semplice host directive da mettere nel VirtualHost in porta 80, ovviamente modificherete la chiamata RedirectMatch con i valori appropriati alla vostra situazione.

ServerAdmin support@mydomain.com
    ServerName webmail.mydomain.com
    ErrorLog /var/log/apache2/webmail.error_log
    CustomLog /var/log/apache2/webmail.access_log combined
    ServerSignature On

    RedirectMatch permanent /$ https://webmail.mydomain.com/exchange
    RedirectMatch permanent (/.*) https://webmail.mydomain.com$1

Vuoi dire o aggiungere qualcosa?

sezione commenti aperta al pubblico

Non ci sono ancora commenti!

Puoi essere il primo a commentare.

Rispondi