Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    settembre 2017
    L M M G V S D
    « gen    
     123
    45678910
    11121314151617
    18192021222324
    252627282930  
  • Tag Cloud

Archivi per la categoria 'Sicurezza' Categoria


E ora cosa usiamo al posto di TMG (Threat Management Gateway)?

Scritto da Ivan Salvade' il 25 luglio 2013

Forefront Threat Management Gateway 2010 è ormai stato abbandonato da Microsoft (con un annuncio del 12 settembre 2012), sebbene il supporto continui fino al 14 aprile 2015, per chi dovesse averlo implementato in rete.

In molti scenari, TMG era caldamente consigliato soprattutto come Reverse Proxy, ovvero con il compito di rendere disponibili all’esterno particolari protocolli applicativi come SMTP, HTTP, HTTPS ecc., proteggendo nel contempo le comunicazioni grazie alle sue caratteristiche di Firewall, URL Filtering e Intrusion Detection.

Sono famose le implementazioni di TMG 2010 per il Reverse Publishing dei servizi di Exchange Server oppure di Lync Server : addirittura, nei corsi ufficiali su questi due prodotti, un intero modulo è dedicato alla configurazione di TMG a questo scopo.

E ora cosa possiamo utilizzare al suo posto?

Fatta salva la possibilità di utilizzare una miriade di terze parti (Kemp Loadmaster, Squid, Kerio Control, EServ, Ositis WinProxy…), volendo rimanere in campo Microsoft cosa possiamo scegliere?

Le soluzioni sono 2 : IIS ARR (Application Routing Request) e UAG (Unified Access Gateway) 2010.

IIS ARR (Application Request Routing)

Si tratta di un componente opzionale di IIS, installabile su Windows Server 2008, 2008 R2 e 2012.  Il componente permette ad IIS di gestire URL Rewrites, richieste di Reverse Proxy, bilanciamenti di carico e altre features ancora, soprattutto se fatto lavorare con un altro modulo di IIS, il URL Rewrite Module.

Il server IIS con ARR e URL Rewrite non necessita di essere installato in ambiente Active Directory.

Sommariamente, ARR e URL Rewrite, congiuntamente, garantiscono le seguenti possibilità :

  • regole di routing applicabili al protocollo http
  • meccanismi sofisticati di bilanciamento di carico, con possibilità di Client Affinity per redirezionare le richieste provenienti da un client ad uno specifico server, utilizzando i cookies
  • Host Name Affinity
  • regole di Reverse Proxy
  • regole di rewriting di URLs, tag HTML, variabili server, intestazioni HTTP
  • supporto per il Failed Request tracing di IIS

Il link per il download diretto di ARR 2.5, in inglese a 64 bit, è il seguente :

http://download.microsoft.com/download/A/A/E/AAE77C2B-ED2D-4EE1-9AF7-D29E89EA623D/requestRouter_amd64_en-US.msi

Il link per il donwload diretto di URL Rewrite Module, in inglese a 64 bit,  è il seguente :

http://go.microsoft.com/?linkid=9722532

Forefront Unified Access Gateway 2010

UAG ha qualcosa in più (e anche qualcosa in meno) rispetto a TMG.

UAG ha le seguenti funzionalità non presenti in TMG :

  • SSL VPN (ma la si può implementare direttamente su Windows Server 2008/R2/2012)
  • migliori possibilità di configurazione delle autenticazioni e del Single Sign-On
  • ILP (Information Leakage Prevention)
  • Endpoint Security (con le Endpoint Access Policies per il controllo dei client)

UAG non ha le seguenti funzionalità di TMG :

  • Proxy in uscita
  • Malware inspection
  • IDS (Intrusion Detection System)
  • Templates di configurazione delle reti

L’ultimo Service Pack di UAG 2010 (il Service Pack 3) ha introdotto le seguenti nuove features :

  • Supporto per il publishing di Exchange 2013
  • Supporto per il publishing di SharePoint 2013
  • Supporto per tutte le applicazioni della suite di Office 2013
  • Supporto per Windows 8
  • Supporto per RDC 8.0 in esecuzione su Windows 8

Se aggiungiamo il già esistente supporto per Exchange, Lync e SharePoint 2010, e il supporto per iOS 5 su iPhone e iPad, Android 4 e Windows Phone 7.5, direi che UAG è assolutamente in grado di sopperire all’assenza di TMG.

Ricordo comunque che TMG continuerà a ricevere supporto base fino al 2015, e supporto esteso ben oltre questa data : nella mia opinione, può anche non essere necessario avventurarsi di colpo verso altre soluzioni.

  • Share/Bookmark

Pubblicato in Gestione dei Sistemi, Sicurezza | Nessun commento »

Non si riescono a creare trust verso altri domini/foreste

Scritto da Ivan Salvade' il 25 novembre 2011

Potreste incorrere (soprattutto in ambiente virtuale) nell’impossibilità di creare trust fra due intere foreste di Active Directory, o fra un dominio di una foresta e un dominio di un’altra.

Il problema è testimoniato dal wizard di creazione del trust (lanciato dalla console “Active Directory Domain and Trusts”), che nella sua pagina finale riporta il seguente (ed immediato) errore :

“The operation failed. The Error is : This operation cannot be performed on the current domain.”

Purtroppo leggendo questo errore non è immediatamente comprensibile la motivazione, e nel Visualizzatore Eventi non vengono riportate informazioni aggiuntive.

Bisogna attivare il logging diagnostico di Active Directory per avere maggiori informazioni.  Questo si effettua utilizzando il registro di sistema del Domain Controller, posizionandosi nella seguente chiave :

HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics

In questa chiave, localizzare il valore di tipo REG_DWORD ”9 Internal Processing“ e porlo a 5 (il default è 0).    Questa operazione registra nel log “Directory Service” qualunque tipo di evento interno ad Active Directory, comprese le stringhe di debug e le modifiche di configurazione.  E’ il tracing più avanzato e dettagliato disponibile.

Ripetendo l’operazione di creazione del trust con il logging diagnostico attivo, compariranno nel log “Directory Service” degli eventi più dettagliati.   In particolare saranno visibili dei codici errore 1481, con sorgente “ActiveDirectory_DomainService” e categoria “Internal Processing”, simili al seguente esempio :

“Internal error : The operation on the object failed.

Additional Data

Error value:

2 0000208F:NameErr: DSID-031001F7, problem 2006 (BAD_NAME), data 8350,….

2 000020EF:NameErr: DSID-032500EB, problem 2001 (NO_OBJECT), data -1601,….

0:00002074:DSID-0312052C, problem 2001 (NO_ATTRIBUTE_OR_VAL), data 0, Att ffffffff (Not in cache!)

Questo tipo di errore è identificativo di un (grave!) conflitto di SID tra i due domini che si vogliono trustare!   E’ un problema più unico che raro : può capitare in ambiente virtuale di test/laboratorio, quando sono stati creati due domini su due domain controller provenienti entrambi da una stessa immagine di partenza, non sottoposta ad operazione di sbiancamento dei SID (quello che fa il SYSPREP, per intenderci).

Infatti, la procedura di creazione di un trust controlla sempre i seguenti pre-requisiti :

  1. Il livello funzionale delle foreste deve essere almeno Windows Server 2003, se quello che stiamo creando è un Forest Trust
  2. I DNS delle due foreste devono risolversi reciprocamente (usare forwarding, zone secondarie o di stub), se quello che stiamo creando è un Forest Trust
  3. Il nome DNS dei domini da trustare deve essere differente
  4. Il nome NETBIOS dei domini da trustare deve essere differente
  5. Il SID dei domini da trustare deve essere differente

Proprio la mancanza del requisito del punto 5) genera l’errore sopra-riportato.

Il SID di un dominio è facilmente identificabile utilizzando l’utility PSGETSID.EXE (strumento della Sysinternals, scaricabile al seguente link : http://technet.microsoft.com/en-us/sysinternals/bb897417.aspx )

La sintassi del comando è la seguente (utilizzarlo sui Domain Controller dei due domini) :

PSGETSID.exe \\NOMEDOMAINCONTROLLER  oppure   PSGETSID.exe \\NOMEDOMINIO

Se il comando restituisce lo stesso SID su entrambi i Domain Controller dei due domini, il problema è localizzato.

La modifica del SID di un dominio non è una strada percorribile con semplici comandi o procedure.  Il Domain controller di quel dominio deve essere rimesso in modalità workgroup (e se quello è l’unico DC del dominio, significa che deve essere rimosso l’intero dominio!!), deve essere eseguito un SYSPREP su di lui, e quindi si re-installa il domain controller (e il dominio intero, se quello era l’unico domain controller disponibile).

In definitiva, ricordate : non bisogna mai creare due domain controller (di domini diversi o anche dello stesso dominio) partendo da un’immagine comune su cui non è stata eseguita l’operazione di SYSPREP.

  • Share/Bookmark

Pubblicato in Gestione dei Sistemi, Sicurezza, Windows Server 2008 R2 | Nessun commento »

Event ID 13 - Autoenrollment dei certificati di tipo Domain Controller

Scritto da Ivan Salvade' il 10 maggio 2011

Su un Domain Controller Windows Server 2003 SP1 o successivi, inserito in un dominio con la Certification Authority installata su un differente server, è possibile la ripetuta comparsa (ogni 8 ore circa) nell’Application Log del seguente errore :

snag-0005.jpg

L’errore è causato dagli avanzamenti di sicurezza del protocollo DCOM, introdotti dal SP1 di Windows Server 2003.

Il protocollo DCOM è utilizzato dai Servizi Certificati per le operazioni di amministrazione e di rilascio dei certificati.   Numerose interfacce DCOM sono fornite dai Servizi Certificati per rendere eseguibili le suddette operazioni, ed i Servizi Certificati presuppongono che queste interfacce DCOM siano impostate con le necessarie autorizzazioni per permettere le chiamate remote (”Remote Activation”) verso di loro.

Gli avanzamenti di sicurezza del protocollo DCOM prevedono la creazione del gruppo di sicurezza “CERTSVC_DCOM_ACCESS” (in Active Directory, come gruppo di tipo Domain Local, se la Certification Authority è installata su un Domain Controller, oppure nel database locale di sicurezza, come gruppo locale, se la Certification Authority è installata su un server membro).  Di questo gruppo devono far parte tutti gli account con diritto di richiesta/rilascio dei certificati.   Per vari motivi, la membership di questo gruppo potrebbe non essere correttamente modificata. 

In questo caso, eseguire le seguenti operazioni :

  1. Inserire nel gruppo CERTSVC_DCOM_ACCESS il gruppo ”Domain Controllers”
  2. Sulla Certification Authority, aggiornare i settaggi di sicurezza DCOM con i seguenti comandi :
    • Certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
    • net stop certsvc
    • net start certsvc

Al termine delle operazioni, al successivo ciclo di richiesta dei certificati, dovrebbe apparire il seguente evento informativo al posto dell’errore 13 :

snag-0006.jpg

  • Share/Bookmark

Pubblicato in Sicurezza | Nessun commento »

Restrizioni sulle versioni dei certificati rilasciabili dalle CA

Scritto da Ivan Salvade' il 7 gennaio 2011

Può capitare, in fase di progetto di una PKI (Public Key Infrastructure), di sbagliare la scelta del sistema operativo del server su cui installare la Certification Authority. 

Tipicamente, durante l’installazione di una CA, è possibile scegliere se installarla di tipo “Standalone” o di tipo “Enterprise”, a seconda delle esigenze.  Se le esigenze riguardano il rilascio dei template di Versione 2 e/o di versione 3, ecco le restrizioni da tenere presente : 

  • I templates di certificato rilasciabili, dipendono sia dalla versione che dall’edizione del sistema operativo
  • I templates di certificato di Versione 3 possono essere rilasciati solo da una Enterprise CA installata su Windows Server 2008 Enterprise o Datacenter Edition
  • I templates di certificato di Versione 2 possono essere rilasciati solo da una Enterprise CA installata su Windows Server 2003 o Windows Server 2008 Enterprise o Datacenter Edition 
  • Se una Enterprise CA è installata su un sistema operativo di edizione Standard, solo i templates di certificato di Versione 1 sono rilasciabili 

E’ sempre possibile effettuare un aggiornamento in-place di un sistema operativo di edizione Standard verso un sistema operativo di edizione Enterprise, purchè si mantenga la stessa architettura (32 o 64 bit).  

Questo nel caso si sia commesso l’errore di installare una Enterprise CA su una edizione Standard del sistema operativo.  

Ricordare che Windows Server 2008 R2 è disponibile solo in architettura a 64 bit.

  • Share/Bookmark

Pubblicato in Generale, Sicurezza | Nessun commento »

 
Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
Ok