Parlando di security i servizi di proxy rivestono da sempre un ruolo fondamentale.
L’idea di base di un proxy è quella di concentrare le richieste in un punto controllabile ed inviarle a destinazione in luogo e per conto del richiedente.
Lo scopo è, ovviamente quello di mettere un layer di divisione tra il client che richiede il servizio e il server che lo eroga, per semplificare:
Client Proxy Server
Il vantaggio di questa operazione è che il proxy è un punto di accesso deterministico, su cui è possibile implementare azioni di controllo e monitoraggio arbitrari indipendentemente dall’origine e destinazione della richiesta.
L’uso di proxy è comune per diverse tecnologie ed è diffusissimo anche se spesso vengono usati nomi diversi. Un esempio su tutti è il servizio di MTA che esegue per conto del protocollo SMTP il servizio di proxy.
Una applicazione classica dei servizi di proxy è legata alla navigazione web. in altri articoli abbiamo parlato diffusamente di come la navigazione web necessiti di una serie di tecnologie concorrenti per proteggere la navigazione dell’utente.
Un errore comune quando si parla di proxy è quello di paragonare il servizio offerto al suo duale: il servizio di Reverse Proxy.
il sevizio di Reverse Proxy, di fatto, serve a dare un layer di isolamento tra Server e client in una ottica di questo tipo:
Server Reverse Proxy Client
Se pur in apparenza le due attività sembrano analoghe richiedono approcci profondamente diversi in quanto devono indirizzare richieste estremamente diverse.
Cerchiamo quindi di fare un po’ di chiarezza sull’argomento:
Proxy
un proxy tradizionale nasce per indirizzare le richieste di una serie di client verso dei server specifici.
l’approccio ingegneristico tiene conto, nella progettazione, della natura della transazione, tenendo presente che il soggetto della operazione è il client, e l’oggetto il server.
Questo significa che il proxy deve essere progettato per rispondere ad una serie minima di esigenze sia in termini di performance che di sicurezza:
1) controllo del traffico
il controllo del traffico viene demandato, fondamentalmente, a due aspetti salienti: il riconoscimento del client e le sue autorizzazioni di accesso.
Il riconoscimento del client, sempre più spesso, va a sovrapporsi con le problematiche di autenticazione, ma in linea di massima significa trovare quel, o quei, parametri univoci che consentono al proxy di distinguere un client da un altro.
La base elementare di questa analisi è l’indirizzo IP del richiedente la transazione, su cui si possono montare altre proprietà che vanno da propietà LDAPDirectory (ex Microsoft Active Directory) a caratteristiche intrinseche della richiesta (target, protocolli, e cosi via).
2) sicurezza
la sicurezza di un proxy si divide in:
- sicurezza del servizio (integrita del sistema, integrità delle policy e cosi via)
- sicurezza del client che richiede il servizio
il secondo punto significa mettere in campo tutte quelle tecnologie che sono in gradi di proteggere il client da effetti indesiderati causati durante la transazione. Tipici esempi di ciò sono i servizi antivirus, quelli antimalware, i servizi di reputation, i filtri URL e cosi via.
Tutta la logica implementativa è rivolta a proteggere il client da possibili interferenze.
3) performance
Dal punto di vista prestazionale l’ottica generale di un proxy è quella di cercare di ridurre il numero di chiamate verso i server accorpando più chiamate client in una sola. in quest’ottica spesso i servizi di cache offrono dei miglioramenti a patto che la dinamicità delle risposte sia limitata e che sia possibile implementare efficienti servizi di prefetching.
Il servizio di proxy, quindi, è una componente del mondo client.
Reverse Proxy
Completamente diversa la situazione di un Reverse Proxy.
Il compito del reverse proxy, come si è detto, è isolare il server dai client (e non viceversa). le problematiche cui va incontro sono profondamente diverse perché diverse sono le esigenze di un client rispetto a quelle di un server.
Fondamentalmente un reverse proxy “virtualizza” il server nei confronti dei client e, dal punto di vista ingegneristico, deve essere progettato per tenere presente le esigenze del “server”.
per analogia con il servizio diretto vediamo lacune considerazioni inerenti il reverse:
1) controllo del traffico
il controllo del traffico in ambito reverse proxy si concentra, fondamentalmente, nella distribuzione delle risorse al fine di poter rispondere al maggior numeri possibile di client senza perdita di performance. a parte casi particolari in cui vengono richieste attività di autenticazione lato proxy, la maggior parte delle autenticazioni in ambito reverse vengono effettuate direttamente a livello di server o di protocollo.
2) sicurezza
la sicurezza in ambito reverse è una questione estremamente delicata. I principali aspetti da tenere sotto controllo sono:
- continuità di erogazione del servizio
- protezione della integrità dei dati sul server
- protezione della integrità delle transazioni col client
Il primo problema viene spesso affrontato da un lato moltiplicando le istanze del reverse proxy che espone il servizio, permettendo a costi ridotti, di aumentare il livello di affidabilità del sistema, dall’altro permettendo al proxy di essere rimesso in funzione in tempi brevissimi.
La teoria è quella della scatola vuota, l’idea di base è che il reverse proxy non contiene, di per se, informazioni sensibili o processi complessi, svolti invece dal server. Può essere quindi riattivato in termini estremamente rapidi.
La protezione della integrità dei dati invece si prospetta come un problema estremamente piu complesso e dipende dalla natura dei dati e dal tipo di transazioni offerte dal server.
In linea di massima un proxy per venire incontro a queste esigenze deve essere capace di interpretare le richiesteistruzioni provenienti da un client ed entrarne nel merito.
Si pensi ad esempio alle SQL injection, per poter bloccare questo tipo di attacco occcorre che il proxy conosca la sintassi relativa e sia in grado di accettare solo le stringhe lecite.
Ovviamente per ottenere il massimo della security da un reverse proxy questo dovrebbe essere “dedicato”, ossia costruito sulle esigenze del servizio che sta proxando.
Se il fattore economico diventa critico può essere utile un general reverse proxy, tendndo presente che in questa maniera si abbassa sensibilmente il livello di security.
3) performance
Essendo il server protetto il generatore delle risposte risultano di scarsa utilità per un reverse proxy meccanismi di prefetching e caching, in quanto questi sono uno degli oggetti implementativi del server medesimo.
è impensabile che un reverse proxy possa migliorare le prestazioni di un server mal progettato, può però fornire supporto in termini di distribuzione di carico delle richieste, e alcuni livelli di aggregazione.
I Reverse Web Proxy
A questo punto vale la pena soffermarsi su un tipo particolare di reverse proxy, il Web Reverse Proxy.
Questo particolare servizio ha la funzione di riesporre un servizio Web su Internet isolando il Web server originale.
Generalmente una applicazione web viene divisa in strati distinti per diversi motivi: aumentare la capacità elaborativa, specializzare alcune componenti, proteggere i canali di comunicazione tra le diverse componenti. Nella figura sopra ho schematizzato una soluzione web in un DB server di backend che fornisce i dati ad un application server che di fatto costruisce il servizio Web e passa le informazioni ad un front-end che espone attraverso un webserver la applicazione dotandola delle opportune interfacce di comunicazione verso l’esterno. I proxy sono poi esposti su internet e fanno da intermediari tra il richiedente (client o proxy che sia) ed il webserver che espone i suoi metodi ed interfacce specifiche.
La funzione dei reverse proxy, in quest’ambito è, principalmente, quella di permettere:
1)una distribuzione geografica del carico nei confronti dei client
in quest’ottica è possibile prevedere la pubblicazione su reverse del servizio in aree geografiche anche distanti, per rendere minori le latenze di traffico IP
2) una più alta affidabilità in caso di fault
La moltiplicazione dei punti di accesso rende possibile la creazione di un grid che aumenta la affidabilità del servizio in caso di non raggiungibilità di uno dei nodi
3) un layer di separazione tra il webserver reale ed il client
Se in quest’ottica non possiamo evitare attacchi application aware, e diretti al webserver in quanto erogatore di un specifico servizio, possiamo quantomeno diversificare le piattaforme di esposizione rendendo più difficile l’Hacking e la presa di controllo della piattaforma e, contemporaneamente, più veloce il ripristino della interfaccia esposta.
A questo livello occorre, se vogliamo utilizzare tecniche di protezione più elevate, passare da un general purpose proxy, ad un application specific proxy. In altri termini se vogliamo proteggere anche il webserver e le interfacce e metodi esposti dall’ application server, nonché i dati del DBserver occorre che il porxy sia in gradi di discriminare i linguaggi i metodi e le sintassi utilizzate dai client per escludere quelle non lecite o pericolose.
L’utilizzo di servizi generici, quali antivirus, rendono il servizio solo minimamente protetto, è infatti essenziale procedere al:
Hardening del sistema operativo
Hardening dell’ application server
Hardening del canale di comunicazione tra Webserver ed Application server
Hardening del DB server
Hardening del canale di comunicazione tra DBserver ed application server.
Buona regola di sopravvivenza è impedire cross reference tra i diversi server rendendo la comunicazione piuttosto rigida anche in termini di cosa ed in che forma sia possibile effettuare una richiesta.
Direct vs Reverse
Come si vede il riferimento di sviluppo di un proxy e di un reverse proxy sono estremamente diversi, usi necessità e finalità sono distanti cosi come le tecnologie necessarie al fine di generare un flusso di dati coerente e sicuro.
Mescolare le due tecnologie può dare adito a problemi di tipo sia amministrativo che di deployment; pur avendo sul mercato la disponibilità di macchine multipurpose (ossia che fungono tanto da proxy quanto da reverse) i deploy sono profondamente diversi e richiedono interazioni e locazioni anche in rete abbastanza contrapposti.
Software Vs. Appliance
Non ho in termini generici una preferenza per quello che riguarda il reverse proxy tra applaince eo software.
L’appliance fornisce possibilità di Hardening maggiori ma una minore flessibilità configurativa rispetto al software che invece può vantare, soprattutto grazie alle correnti tecniche di virtualizzazione, una maggiore flessibilità sia in termini di personalizzazione (application aware) che di distribuzione su HW. per entrambi i tempi di recupero in caso di fault sono, generalmente, minimi a patto di aver disegnato correttamente il sistema.
Il confronto col mondo dei proxy web è difficile, in questo caso la scelta di uso dell’appliance risulta generalmente migliore sia in termini di costi che di security, tenendo presente che un webproxy, a differenza di un reverse web proxy, è general purpose e non dedicato ad una specifica applicazione.
Si risparmia allora a prendere un proxy che sia anche reverse?
Se i parametri di calcolo sono il mero costo di acquisto della soluzione (sic) direi che spesso si può risparmiare comprando una unità multipla, ma se nei calcoli di costo consideriamo che il deploy deve essere distinto, i costi di manutenzione e amministrazione, i costi legati ala security una soluzione dedicata risulta decisamente più sensata cost effective.
alla prossima
Antonio
![[google-logo.jpg]](https://i0.wp.com/2.bp.blogspot.com/_ebKDfm0h1oI/SqUUJUhpgJI/AAAAAAAAIgM/pd_ek5J3t-Q/s1600/google-logo.jpg?w=900){kind=logo}
