Quanto è grave il problema di creare un buco nella DMZ su un server Web?

Al momento abbiamo il nostro server Web in una DMZ. Il server Web non può vedere nulla all'interno della rete interna, ma la rete interna può vedere il server Web. Quanto sarebbe sicuro creare un buco nel firewall tra la DMZ e la rete interna su un solo server Web nella rete Intranet? Stiamo lavorando a qualcosa che si interfaccia con molte delle nostre applicazioni di back-office (che sono tutte su un server) e sarebbe molto più semplice fare questo progetto se potessimo comunicare direttamente con il server IBM i che contiene questi dati ( tramite servizi web).

Da quanto ho capito (e non conosco i marchi), abbiamo un firewall per DMZ con un IP esterno diverso dal nostro IP primario con un altro firewall. Un altro firewall si trova tra il server Web e la rete Intranet.

Quindi qualcosa del tipo:

Web Server  <==== Firewall ===== Intranet
     |                              |
     |                              |
  Firewall                      Firewall
     |                              |
     |                              |
 Internet IP1                  Internet IP2

Non c'è nulla di sbagliato nella creazione di meccanismi di accesso per gli host nella DMZ per accedere agli host nella rete protetta quando ciò è necessario per raggiungere il risultato desiderato. Forse non è preferibile farlo, ma a volte è l'unico modo per portare a termine il lavoro.

Le cose chiave da considerare sono:

• Limitare l'accesso alla regola del firewall più specifica possibile. Se possibile, nominare gli host specifici coinvolti nella regola insieme ai protocolli specifici (porte TCP e / o UDP) che verranno utilizzati. Fondamentalmente, apri solo un piccolo buco di cui hai bisogno.

• Assicurarsi di registrare l'accesso dall'host DMZ all'host sulla rete protetta e, se possibile, analizzare tali registri in modo automatizzato per individuare eventuali anomalie. Vuoi sapere quando succede qualcosa di straordinario.

• Riconosci che stai esponendo un host interno, anche se indirettamente, a Internet. Rimani aggiornato su patch e aggiornamenti per il software che stai esponendo e il software del sistema operativo dell'host stesso.

• Prendere in considerazione l'autenticazione reciproca tra l'host DMZ e l'host interno, se possibile con l'architettura dell'applicazione. Sarebbe bello sapere che le richieste che arrivano all'host interno provengono effettivamente dall'host DMZ. Se puoi farlo o no dipenderà in larga misura dall'architettura dell'applicazione. Inoltre, tieni presente che qualcuno che "possiede" l'host DMZ sarà in grado di effettuare richieste all'host interno anche se si sta verificando l'autenticazione (dal momento che, in effetti, sarà l'host DMZ).

• Se c'è preoccupazione per gli attacchi DoS, considerare l'utilizzo della limitazione di velocità per impedire all'host DMZ di esaurire le risorse dell'host interno.

• È possibile prendere in considerazione l'utilizzo di un approccio "firewall" di livello 7, in cui le richieste dall'host DMZ vengono passate prima a un host interno per scopi speciali in grado di "sanificare" le richieste, controllarle in modo igienico e quindi passarle a il "vero" host back-end. Dal momento che stai parlando di interfaccia con le tue applicazioni di back-office sul tuo IBM iSeries, immagino che tu abbia una capacità limitata per eseguire i controlli di integrità contro le richieste in arrivo sull'iSeries stesso.

Se ti approcci in modo metodico e tieni un po 'di buon senso al riguardo, non c'è motivo per cui non puoi fare ciò che stai descrivendo mantenendo allo stesso tempo il rischio minimizzato.

Francamente, che hai una DMZ che non ha accesso illimitato alla rete protetta ti fa fare passi da gigante oltre molte reti che ho visto. Per alcune persone, a quanto pare, DMZ significa semplicemente "un'altra interfaccia sul firewall, possibilmente con alcuni indirizzi RFC 1918 diversi e un accesso praticamente illimitato a Internet e alla rete protetta". Cerca di mantenere la tua DMZ il più bloccata possibile mentre raggiungi gli obiettivi aziendali e farai bene.

Ci sono ovviamente alcuni pericoli, ma puoi farlo. Fondamentalmente stai aprendo un foro stenopeico attraverso il quale qualcuno potrebbe entrare, quindi rendilo minuscolo. Limitare solo ai server su entrambe le estremità e consentire solo i dati sulle porte scelte. Non è una cattiva idea usare la traduzione dell'indirizzo della porta per usare solo porte bizzarre. Tuttavia, la sicurezza per oscurità non è affatto sicurezza. Assicurati che qualunque sia il server dall'altra parte abbia un qualche modo per verificare che le informazioni che attraversano quella connessione siano veramente quelle che sembrano ... o almeno hanno una sorta di firewall consapevole del contesto in atto. Inoltre, ci sono alcuni firewall creati per questo tipo di cose ... So che Microsoft ISA fa la stessa cosa per i server OWA ed Exchange.