Approcci alternativi all'uso di DMZ per proteggere le comunicazioni da e verso il server Web esterno all'esterno del firewall

7

Sono uno sviluppatore di software con poca conoscenza della sicurezza della rete e quasi nessuna conoscenza dell'attuale architettura di rete per l'ambiente in cui lavoro. Se ne avessi, non vorrei ancora divulgare alcuna informazione in quanto tale potrebbe essere un rischio per la sicurezza . Attualmente, la politica aziendale impedisce qualsiasi comunicazione del server al di fuori della nostra rete. Poiché le esigenze stanno cambiando, sono alla ricerca di un modo per trasmettere alla direzione che esiste un approccio alternativo sicuro, affidabile e sicuro per consentire a un server Web esterno di comunicare con un server interno e viceversa.

Suppongo che il percorso di avere un server aziendale nella DMZ fosse di evitare i problemi di non avere accesso remoto e di non essere governati dal team della rete aziendale. L'approccio desiderato è possibilmente utilizzare un servizio di terze parti, ad esempio attraverso un servizio cloud, e ottenere così il controllo sulle nostre implementazioni.

Un approccio alternativo suggerito da un peer per avere un server nella DMZ era consentire solo la comunicazione con il protocollo HTTP, bloccare tutte le porte tranne 80 (non sono sicuro se su server e / o firewall) e consentire solo GET e Verbi POST.

Per favore illuminami con le possibilità, le preoccupazioni, gli effetti collaterali, i suggerimenti e gli approcci alternativi per ottenere la capacità di consentire a un server esterno di comunicare internamente e viceversa che non coinvolga una DMZ. Si prega di non utilizzare un collegamento a un PDF di 500 pagine come risposta, a meno che non sia fornito come riferimento con qualche buon dettaglio.

Grazie in anticipo!

    
posta Alban 12.07.2011 - 21:25
fonte

3 risposte

6

La risposta tradizionale è un'architettura a tre livelli: web, app e dati. Il tuo livello Web è isolato frontalmente e può comunicare al server dell'app solo con metodi limitati (ad esempio, solo un numero limitato di chiamate RPC-ish disponibili). Il server dell'app quindi parla con il livello dati (base) e, naturalmente, è possibile fare qualsiasi cosa con ACL o stored procedure per renderlo più sicuro. Per motivi di sicurezza, un'architettura a tre livelli è una buona soluzione se eseguita correttamente .

Il tuo suggerimento da parte dei pari riguardo il solo permettere che la porta 80 sia una specie di minimo ipotizzato. E la whitelist dei verbi va bene, ma renditi conto che la maggior parte degli attacchi che dovrai affrontare opereranno al di sopra di quel livello e si indirizzeranno tranquillamente su GET / POST. Il che porta alla risposta moderna: i sistemi di prevenzione delle intrusioni che guarderanno tutto il traffico, individueranno i pattern dannosi e agiranno per interdirli.

La risposta tradizionale e la risposta moderna portano tutte alla vera risposta: non è possibile impostare [un server web esterno] che sia sicuro, affidabile e sicuro come non averne uno in primo luogo. Qualsiasi cosa tu faccia aumenterà il tuo rischio di qualche margine. Come lo farai cambierà quanto è grande quel margine di rischio. Indipendentemente dal tipo di architettura a tre livelli, IDS / IPS, monitoraggio e avviso dei registri, ecc. Tu e il tuo management decidete come mitigare il rischio e portatelo a un livello accettabile.

E sfortunatamente, imparare a mitigare il rischio in modo sicuro significa scavare attraverso PDF di 500 pagine per imparare i trucchi. Un cappello per un gatto o un gatto per un cappello, ma niente per niente.

    
risposta data 12.07.2011 - 21:53
fonte
3

Architetture che potresti utilizzare:

  • Per i dati che non sono soggetti a modifiche, è possibile utilizzare un metodo push inserendo il contenuto sul sito Web utilizzando un metodo autenticato e sicuro (vpn, https o ssh / sftp) in modalità batch, durante la notte o su richiesta. per esempio. Caricamento del codice aggiornato sul sito Web, caricamento del database dei prezzi, caricamento dei dati aziendali a cui accedere.
  • Per i dati che possono essere inseriti nella DMZ puoi mettere tutti i tre livelli (Web Server, App Server e DB Server) nella DMZ e lasciarlo lì, se hai bisogno dei dati internamente puoi probabilmente convincerli a copiare il db internamente o fare riferimento alla rete interna.
  • Per i dati interni che sono necessari in tempo reale dal tuo sito Web, puoi costruire un'interfaccia minima che potrebbe superare il tuo dipartimento Sicurezza / Rete. Qualcosa come una minima funzione di db che è strettamente protetta, usa meno privilegi e monitorata possibilmente utilizzando un database di bastioni intermedio o simili (pensa ai database di oracle collegati da collegamenti a database).

Altri problemi:

  • Se la comunicazione viene trasmessa su Internet, è necessario crittografare e autenticare (vpn, https o sftp / ssh).
  • Potresti chiedere agli esperti di sicurezza il modo migliore per integrare i dati interni ed esterni, se non riesci a sconfiggerli, falli investire in una soluzione.
  • Cerca di determinare le preoccupazioni dei tuoi addetti alla sicurezza, sono generalmente validi e ho cercato di spiegare cosa potrebbero essere dalla mia esperienza simile, ma dovrai iniziare a pensare al modo in cui guardano il mondo (un po ' di un'esplorazione su questo sito di scambio di sicurezza ti fornirà suggerimenti).
risposta data 13.07.2011 - 13:13
fonte
1

Asunci: l'interfaccia tra la rete interna e la rete esterna fornisce attualmente il livello desiderato di garanzia. Il server esterno è poco affidabile e potrebbe essere compromesso.

Obiettivi: mantenere l'attuale livello di sicurezza nella connessione tra le reti interne ed esterne. Aggiungi una nuova interfaccia alla connessione senza impostare una DMZ.

Sfortunatamente la risposta dipende dalla tua architettura attuale, ma proverò a indovinare ciò che potresti avere. Suppongo che tu abbia un router connesso a un singolo server bastion (combo firewall, IDS, NAT, proxy, ecc.) E che l'altro lato del server bastion sia la tua rete interna. Volete preservare la sicurezza esistente della vostra configurazione attuale, quindi penso che la modifica dell'architettura il meno possibile sia prudente.

Nota: questo è uno schizzo approssimativo, è necessario eseguire un'analisi e una pianificazione approfondite prima di implementare una soluzione.

Acquista una nuova macchina in grado di supportare due interfacce ethernet fisicamente separate. Quello che voglio dire è che se la scheda madre ha Ethernet su scheda allora hai bisogno di una scheda Ethernet PCI o PCI Express. Se la scheda madre non dispone di Ethernet su scheda, sono necessarie due schede Ethernet PCI o PCI Express.

Se l'host del bastione può supportare una nuova scheda Ethernet fisicamente separata, quindi ottenere una nuova scheda per il server bastion.

Se si dispone di una nuova scheda Ethernet per il server bastion, collegare una delle porte Ethernet della nuova macchina alla nuova scheda sul server Bastion. Altrimenti basta collegare la nuova macchina a qualsiasi porta disponibile sul server Bastion.

Scegli una macchina interna come punto di contatto interno per la nuova macchina. Se possibile, installare una nuova nuova scheda Ethernet fisicamente separata sul punto di contatto interno. Installare il software VPN sulla nuova macchina e il punto di contatto interno. Configurare il server bastion per accettare solo i pacchetti in entrata (necessari anche in uscita?) Del tipo corretto dall'indirizzo MAC della nuova macchina. Se il server Bastion dispone di una nuova scheda Ethernet, configurare il server Bastion per accettare solo pacchetti dalla nuova macchina sulla nuova interfaccia fisica. Configurare il firewall sul computer interno per accettare solo i pacchetti VPN in arrivo dalla nuova macchina (se possibile, sulla nuova interfaccia Ethernet). Configura la nuova macchina per accettare i pacchetti appropriati da Internet. Collegare l'altra interfaccia ethernet fisicamente separata al router che è connesso a Internet. Controlla regolarmente i log di audit, mantieni buoni backup, ecc.

Questo non è troppo costoso. Un PC (non deve essere a livello di server), tre schede Ethernet, alcuni cavi, alcuni software e molta configurazione. La parte bella è che ora hai una macchina a cui hai accesso fisico, che è connessa a Internet e richiede modifiche minime all'architettura di rete per adattarla. La parte cattiva è che ci vorrà molta configurazione e probabilmente un po 'di energia convincente dei proprietari dell'host bastion e della macchina di contatto interna.

    
risposta data 14.07.2011 - 02:05
fonte

Leggi altre domande sui tag