Oracle, firewall e DMZ

mercoledì 5 settembre 2007 alle 05:40 | Pubblicato su Installation and Configuration | Lascia un commento

Oggi voglio parlare di un argomento molto complesso ma in modo leggero. L’argomento è il rapporto fra Oracle, application server, firewall e DMZ. Ne parlerò in modo leggero non perchè lo ritenga un argomento leggero, tutt’altro, si tratta di un argomento molto complesso e ampio, tale da richiedere per una trattazione completa interi libri.

Premetto che la mia formazione riguardo sicurezza, trasmissione dei dati, crittografia risale e si limita all’ottimo corso di “Teoria dell’informazione e della Trasmissione” più comunemente chiamato T.I.T. che seguii all’ Università di Udine con il Professore Giacomo Della Riccia e l’allora suo assistente Francesco Fabris.

Secondo me la gestione della sicurezza e le configurazioni delle reti aziendali e DMZ varie sono spesso gestite in modo più complicato del necessario. Cominciamo a vedere un po’ di definizioni che ho trovato su Internet

DMZ

La definizione secondo me più sensata è quella che si trova sulla wikipedia, secondo questa definizione la DMZ è una sottorete che si trova tra la LAN Aziendale e Internet. La peculiarità di una DMZ è che vi si può accedere sia da Internet che dalla LAN Aziendale, mentre dalla DMZ ci si può connettere verso Internet ma non ci si può connettere verso la LAN aziendale. Nella DMZ quindi si mettono solitamente i Server che devono dare dei servizi pubblici su Internet, come ad esempio la posta. Nel caso degli attacchi esterni riescano a compromettere i server che si trovano sulla DMZ, la sicurezza della LAN non viene compromessa per l’impossibilità di accedere dalla DMZ alla LAN.

Questa definizione di DMZ è molto restrittiva, più comunemente viene estesa, una descrizione molto chiara, più estesa di quella data sulla Wikipedia e più vicina a quanto mi è capitato di incontrare è questa. In questa spiegazione viene rilassato un vincolo: i server in DMZ (front-end) possono comunicare con dei server back-end che si trovano nella LAN Aziendale.

Firewall

Un firewall è un dispositivo che filtra secondo delle regole il traffico tra due reti, per una definizione più estesa e precisa rimando alla solita Wikipedia.

Non essendo io ne un sistemista, ne un esperto di reti, ma solo un DBA Oracle appassionato di sistemi Linux e reti non ho grandissime competenze per quel che riguarda la sicurezza delle reti. Non mi sono mai curato di approfondire il tema proprio perchè lo considero una tematica importante e complessa da richiedere notevoli competenze. Trovandomi però a confrontarmi sulla tematica e non avendo ben chiare alcune cose ho deciso di documentarmi almeno un po’ e scrivere questo post per raccogliere le mie idee.

Fino a ieri trovavo sensata la politica che interpreta la definizione più stretta di DMZ come data sulla Wikipedia. Quindi ritenevo del tutto logico, dovendo pubblicare su Internet un servizio fornito da un’applicazione a due livelli (two-tier, application server-database server), porre in DMZ sia l’application server che il database server. A proteggere la sicurezza del database server e dei dati in esso contenuti secondo me era sufficiente il fatto il che il firewall che protegge la DMZ da Internet bloccasse gli accessi diretti al database. E’ però vero che un attacco che prenda il controllo dell’application server forse può far si che venga preso anche il controllo del database server, cosa secondo me complicata ma probabilmente non impossibile.

Architetture DMZ a più livelli

Come ho già accennato, l’interpretazione più comune estende la definizione di DMZ permettendo l’apertura di alcuni canali (porte TCP/IP) tra la DMZ e la LAN. Quindi i seguaci di questa interpretazione estesa consigliano di lasciare in DMZ solo i server fornitori del servizio, ad esempio l’application server deve stare in DMZ e il database server nella LAN, in questo caso lo sfondamento dell’application server permette l’attacco verso il database server solo attraverso l’unico canale lasciato aperto nel firewall tra DMZ e LAN, il canale usato dall’application server per comunicare con il database server (Ciò non toglie che comunque i dati non sono al sicuro). Quindi con un ragionamento più statistico che altro si conclude che il database server in questo modo è più protetto; infatti se tale database server stesse nella DMZ avrebbe tutti i canali di comunicazione aperti verso l’application server (anche questo è opinabile, secondo me in questo caso è sufficente lasciare aperto solo un canale che permetta l’accesso alla macchina per la sua amministrazione, tale canale può essere quello usato da SSH, sulla cui robustezza e sicurezza io ho pochi dubbi).

Posso obbiettare però che se quell’unico canale lasciato aperto tra la DMZ e il database server è sufficente per sfondare il database server allora l’attacco ha raggiunto l’intera LAN aziendale.

Un’evoluzione dell’architettura prevede che in DMZ vi sia solo un front-end ai servizi, ad esempio un http server, che poi si occupa di comunicare con l’application server che si trova in LAN, o meglio in un’altra DMZ (e qui siamo alle architetture DMZ a più livelli) che si trova tra la DMZ di primo livello, esposta su Internet e la LAN. A questo punto, dico io, aggiungiamo ancora una DMZ in cui sta il database server. Quindi arriviamo a tre DMZ e quattro Firewall. Faccio notare che tali firewall vanno configurati.

A parte secondo me la paranoia che ha indotto il proliferare dei firewall e delle regole con cui questi lavorano nella mia esperienza ho riscontrato che mettere un firewall tra application server e database server oracle può creare problemi, soprattutto se il firewall è di tipo “attivo” (vedi stateful firewall). Una delle caratteristiche più simpatiche di questi moderni firewall è quella di abbattere le connessioni TCP/IP che non generano traffico per un certo intervallo di tempo. Vi è poi un problema notevole se il database Oracle si trova su piattaforma Windows o, indifferentemente dalla piattaforma usa connessioni condivise (Shared server).

Oracle e i firewall

Per quanto riguarda Oracle su Windows vi è un problema legato al porting di Oracle su Windows che ha trasformato l’archiettettura da multi processi a mono processo e multi thread.

Nell’architettura originaria, multi processi, con processi dedicati, quando un client chiede una connessione al database inoltra una richiesta via TCP/IP (normalmente) al Listener (solitamente, per default, in ascolto sulla porta 1521) il listener gestisce tale richiesta chiedendo al server la creazione di un processo (spawn, a basso livello si tratta di una chiamata di sistema in Unix chiamata fork), a tale processo viene passato l’identificatore del socket creato tra il client ed il listener, a questo punto il listener ha concluso il suo compito ed il client è connesso il database server.

Su Windows, con l’architettutura multithread la sequenza sopra descritta non è possibile in quanto pare non sia possibile creare un nuovo thread e passargli il descrittore del socket. Quindi Oracle usa il cosiddetto meccanismo di REDIRECT, cioè quando un client richiede una connessione al database al listener, questi chiede al server la creazione di un nuovo thread, questo si mette in ascolto su una porta TCP/IP libera a caso, a questo punto il listener manda al client un messaggio con l’indicazione di connettersi alla porta su cui sta in ascolto il nuovo thread creato. Questo meccanismo è ben spiegato nella nota Metalink numero 66382.1 intitolata “Firewalls, Windows NT and Redirections“. Nella stessa nota spiega che il range di porte su cui si mette in ascolto il nuovo thread non è definito, ciò rende impossibile configurare un firewall. Quindi nella stessa nota spiega come risolvere il problema usando la chiave di registro “USE_SHARED_SOCKET”. Questa configurazione è spiegata più in dettagli nella nota metalink numero 124140.1 intitolata “How to configure USE_SHARED_SOCKET on Windows NT/2000“. Un’altra nota a cui forse vale la pena dare un’occhiata e che ribadisce il meccanismo è la numero 68652.1 intitolata “Solving Firewall Problems on Windows”. Infine, rimando ad una nota più recente e completa, la numero 361284.1 intitolata “Port 1521 opened in firewall yet cannot connect to Oracle Server (ORA-12535,TNS-12203)“. In quest’ultima nota si spiega come dalla versione 10g Oracle abbia introdotto un meccanismo, chiamato “HAND OFF” che evita il problema nel caso si connessioni in modalità server condiviso (shared server). Infatti anche in questa modalità, nelle versioni precedenti, e su tutte le piattaforme, veniva usato il meccanismo di “REDIRECT” che rendeva problematico la connessione al database attraverso firewall. Fra l’altro tale meccanismo viene usato anche i RAC, per il connection load balancing.

Ancora un’altra nota a cui voglio rimandare, molto breve, è la numero 416236.1 intitolata “Which Ports Need To Be Open In The Firewall for Oracle DB Connections ?

Il problema delle porte da aprire sul firewall quindi, stando alle note sopra citate sembra essere risolvibile, a questo punto però subentrano i famigerati, gia citati, firewall stateful. Come soluzione agli inconvenienti causati da questi firewall Oracle suggerisce, tramite la nota numero 257650.1 intitolata “Resolving Problems with Connection Idle Timeout” per la verità non molto recente, di attivare il cosiddetto DCD: “Dead Connection Detection”. Questo meccanismo si attiva settando il parametro SQLNET.EXPIRE_TIME sul file SQLNET.ORA del database server; non necessita del riavvio ne’ del listener ne’ dell’istanza, è subito attivo per le nuove connessioni. Il settaggio di tale parametro fa si che il server invii ogni n minuti (dove n è il valore settato per SQLNET.EXPIRE_TIME) un piccolo pacchetto TCP/IP (circa 20 byte) verso il client. Questo dovrebbe essere sufficente a far si che il firewall rilevi del traffico sulla connessione e non la stronchi. Fra l’altro questo meccanismo è stato implementato (e anche così chiamato) affinchè il server rilevi eventuali connessioni stroncate e pulisca le eventuali sessioni interessate. Il problema è che comunque su macchine windows per default il protocollo TCP/IP ha un timeout di due ore, il che significa che se la connessione TCP/IP tra un client ed il server per qualche motivo è stata stroncata, Oracle prima di due ore non è in grado di rendersene conto e fare pulizia. La cosa può essere particolarmente seccante nel caso in cui la sessione interessata dalla connessione stroncata detenga dei lock sul database. Si tratta di un situazione che mi è capitata presso un cliente e per questo la riporto.

Conclusioni

Può sembrare un po’ stupido, ma la scrittura di questo post mi ha aiutato a chiarirmi le idee su come si possono configurare le DMZ e perchè (forse) è meglio tenere il database nella LAN piuttosto che in DMZ. Secondo me in giro prevale la logica più firewall ci sono più sicuri si è. Secondo me questo non è necessariamente vero, è però sicuramente vero che tale logica fa si che spesso si implementino delle architetture più complesse del necessario, con spese superiori al necessario, con la scusa se sulla sicurezza non si può risparmiare. Occorrerebbe però riflettere se queste architetture sono veramente più sicure. In questi casi mi viene sempre da pensare ad un concetto basilare spiegatomi al famoso corso di Teoria dell’informazione e della Trasmissione, quando il professore parlava di crittografia:
“cifrare più volte lo stesso messaggio con la stessa tecnica non rende la decifrazione significativamente più difficile”

Lascia un commento »

RSS feed for comments on this post. TrackBack URI

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: