Rischio per i membri del dominio in un dominio esteso nella DMZ

4

Sono un amministratore di AD che cerca di guardare le cose dal punto di vista del proprietario di un application server.

Immagina uno scenario in cui un dominio AD copre l'autenticazione sia nella LAN aziendale che nella DMZ. La LAN ha RWDC, il DMZ ha il sandwich standard del firewall RODC.

I RODC sono stati temprati; nessun account è stato memorizzato nella cache, è stato applicato un set di attributi filtrati (FAS), è presente un account amministratore RODC delegato, è presente un firewall, sono presenti AV, i server sono corretti.

Per i server delle applicazioni nella DMZ posso solo gestirli tanto quanto AD mi consente di; Limito il numero di utenti con privilegi di amministratore ai server, mi assicuro che il firewall sia a posto, i server siano corretti, AV abbia, forse c'è qualche restrizione Kerberos per l'account.

Ci sono altre difese nella DMZ; per esempio. il team di rete ha il proprio firewall di rete, ma non posso controllarlo e non posso controllare ciò che i proprietari dell'applicazione fanno al di fuori di quanto ho detto sopra.

Come appare la sicurezza dei server nella DMZ, sarebbero in buone condizioni? Se un server è stato compromesso nella DMZ, qual è il raggio di esplosione da quello; è il dominio alla minaccia, sono altri server nella DMZ e la LAN alla minaccia?

Quale sarebbe il più probabile percorso di escalation di compromesso?

Glossario:

AD: active directory
DMZ: demilitarized zone; location for internet facing servers
LAN: (internal network; separated from DMZ by firewall
RWDC: read/write domain controller
RODC: read only domain controller
    
posta idarryl 28.06.2016 - 12:59
fonte

2 risposte

0

Utilizzerò il ISC2 come riferimento.

Ci sono 10 domini generali che sono al centro della sicurezza. Ecco una panoramica di loro per riferimento.

Hai discusso molto e per questa risposta cercherò di concentrarmi su (3) che sembrano interessarti di più:

  • Controllo di accesso
  • Crittografia
  • Architettura e progettazione della sicurezza

Domini di sicurezza

Prima di entrare in questo ambito, i domini di sicurezza sono ampi e si concentrano su molti aspetti diversi del dominio identificato. Sto limitando i miei punti e sono generalizzati. Le persone possono identificare il rischio in generale, ma è difficile sapere quanto sia limitato il rischio senza accesso all'ambiente.

Controllo di accesso

In base allo scenario, suppongo che il RODC sia utilizzato per l'autenticazione e / o l'autorizzazione. Altrimenti, non so perché ne hai una seduta là fuori. Sembra che tu abbia una buona conoscenza della configurazione sicura di un DC, quindi direi che il rischio maggiore qui riguarda i diritti di cui l'Applicazione ha bisogno / deve svolgere i suoi compiti. Direi che un account di servizio bloccato per questa applicazione dovrebbe essere sufficiente. Vorrei verificare con il proprietario dell'app ciò di cui hanno bisogno per l'applicazione

Crittografia

Non specificamente discusso, ma suggerisco sempre (o richiesto a seconda dello scenario) che venga utilizzata la comunicazione sicura. LDAPS, TLS, ecc. Dovrebbero essere comuni e, se si accede esternamente a questi sistemi, preferisco sempre certificati certificati di terze parti rispetto ai certificati CA interni.

Architettura e progettazione della sicurezza

Questa è probabilmente una domanda più ampia. È ciò che hai progettato una buona implementazione? In breve, quello che hai descritto va bene, anche standard (mi sembrano molte configurazioni simili.)

Questo argomento è estremamente ampio e potresti fare molte domande al riguardo:

  • Quali sono le pratiche di provisioning / de-provisioning per gli amministratori?
  • Quali utenti accederanno all'applicazione?
  • Gli altri DC sono protetti allo stesso modo?
  • Se comprometto una DC riconfigurata in una DMZ diversa, posso accedere al RO in questo?

Potrei andare avanti. (In generale, questo è il motivo per cui lavoriamo negli ambiti, perché chiedere queste domande è infinito).

Quindi qual è il probabile percorso di escalation?

Dall'esperienza generale, i compromessi esterni sono di solito:

  • Difetto di sviluppo dell'applicazione (E.G SQL Injection)
  • Errore del server delle applicazioni (file .htaccess errato di E.G)
  • Servizio esposto sul firewall (E.G Telnet aperto attraverso il firewall)

Se hai una ragionevole fiducia nell'altro team per configurare i loro sistemi, dovresti sentirti ragionevolmente sicuro che la tua DMZ è sicura. La grande domanda che potresti voler prendere in considerazione è: se la mia DMZ è compromessa, qual è il mio rischio per la rete interna?

Probabilmente il tuo RODC deve tornare al RWDC attraverso un firewall. Cosa succede se un computer che non è il tuo RODC si connette al RWDC? Potrebbe essere una bandiera rossa.

    
risposta data 16.09.2016 - 22:38
fonte
2

Mi preoccuperei principalmente di cosa è permesso dai firewall, e quali sono i privilegi degli account usati nella DMZ sulle macchine interne. La vera domanda è IMHO che cosa potrebbe accadere se un utente malintenzionato potrebbe violare la sicurezza di un'applicazione in esecuzione su un server DMZ:

  • il firewall consente le connessioni da quel server alla lan interna?
  • un server interno (o un computer client con risorse condivise) accetta connessioni da uno degli utenti utilizzati nella DMZ?

Se i rischi di cui sopra (DMZ - > zona interna) sono già coperti, puoi allora considereggiare DMZ - > DMZ, ovvero se un'applicazione in DMZ è compromessa, questo account è in grado di fare qualsiasi cosa su altre applicazioni dallo stesso server, e che dire degli altri server.

So che questi sono solo suggerimenti, ma è il meglio che posso senza altri elementi sulla configurazione attuale, inclusi i piccoli dettagli come notato da paj28 nel suo commento.

    
risposta data 16.09.2016 - 16:38
fonte

Leggi altre domande sui tag