Share via

Microsoft Forefront

  • Articolo

Utilizzo di Microsoft Forefront TMG 2010 come gateway Web di sicurezza

Yuri Diogenes, Jim Harrison e Mohit Saxena

Quando le società di stabilire un criterio di protezione, un obiettivo chiave è consentire ai dipendenti di accedere in modo protetto a Internet. Naturalmente, ciò comprende un'area molto vasta e vengono trattati numerosi requisiti, ad esempio:

  • Assicurarsi che gli utenti aderiscono a criteri aziendali relativi all'accesso a Internet.
  • Ispezionare il traffico e bloccare eventuali malware e attività sospette.
  • Assicurarsi di conoscere che il loro traffico Web viene controllato gli utenti finali.

Fortunatamente, sfruttare le funzionalità del gateway Web protette in Microsoft Forefront Threat Management Gateway (TMG) 2010 può aiutarvi a soddisfare tali obiettivi. Nella figura 1 illustra le principali funzionalità di Forefront TMG 2010 che è possibile utilizzare per implementare un gateway di accesso Web protetto:

 

 

Figura 1 Core Forefront TMG 2010 funzionalità per Secure Web Gateway Scenario

Come si può vedere, Forefront TMG vengono utilizzati tre componenti principali cloud: Microsoft Update Service Telemetry e servizio reputazione Microsoft (MRS). Microsoft Update consente di mantenere aggiornate le firme di ispezione Network System (NIS) e antimalware. Il team di risposta di Microsoft software dannoso utilizza telemetry report forniti da TMG scoprire quali sono gli attacchi sono essere visti e pertanto migliorare la qualità di firma. MRS mantiene un vasto database di URL categorizzati Forefront TMG 2010 possono eseguire query.

In questo articolo verrà focalizzata su HTTPS ispezione e filtraggio URL. We covered malware inspection in-depth in our previous  TechNet Magazine February 2009 article, and the feature hasn’t changed in Forefront TMG 2010.

Utilizzando un'esperienza di esplorazione più sicurezza di filtro URL

Filtro URL può essere visualizzato come Forefront TMG prima linea di difesa per la protezione di accesso al Web della propria organizzazione. Utilizzando filtro per richieste di blocco per i siti Web non desiderabili URL Forefront TMG possono dedicare meno tempo rilevamento di software dannoso e più tempo di consegna di contenuto utile.

Filtro URL è costituito da due parti principali, ovvero il filtro proxy Web che valuta le richieste Web e MRS, fornisce le definizioni di categoria da cui il filtro determina come una richiesta deve essere classificato.  Ecco una forma semplificata del processo che si verifica per una richiesta Web:

  1. L'applicazione Web invia una richiesta per “ http://malware.contoso.com/nefarious ” tramite TMG.

  2. Filtro proxy Web passa la richiesta tramite filtro URL.

  3. Filtro URL suddivide l'intera richiesta in diverse parti. Per esempio, le parti sarebbe simile:

    • Com
    • Contoso.com
    • Malware.contoso.com
    • Malware.contoso.com/nefarious

  4. Filtro URL Cerca ogni parte nella categoria cache URL locale.

    Nota: se la richiesta non può essere associata a una categoria URL all'interno della cache locale, filtraggio URL query MRS. Se restituisce “ sconosciuto ” MRS o se non è possibile contattare MRS, URL filtro restituisce una risposta per il proxy Web “ sconosciuta ” filtro.

  5. Una volta il filtro URL è in grado di categoria associata a ogni parte dell'URL, determina la categoria che verrà applicate all'intero URL. Per effettuare questa operazione, TMG utilizza un elenco di precedenza predefinite fornito da MRS informa TMG le categorie che hanno la precedenza rispetto agli altri utenti. Ad esempio:

    • COM = sconosciuto
    • Contoso.com = business
    • Malware.contoso.com = dannoso
    • Malware.contoso.com/nefarious = sconosciuto In questo esempio vengono identificate due categorie: Generale aziendali e dannoso. A seconda dell'elenco predefinito, intenzionali ha la precedenza su Business; di conseguenza, l'intero URL verrà designato come intenzionali.

  6. Se l'insieme di categorie di URL risultante corrisponde a una regola di negazione, la richiesta viene rifiutata e una risposta di errore viene restituita all'applicazione Web.

  7. Se la categoria di URL non corrisponde a una regola di negazione e corrisponde a una regola di autorizzazione, la richiesta viene pubblicata in base ai criteri della regola di corrispondenza restanti.

  8. Se la richiesta non corrisponde alcun negazione creati dall'utente oppure consentire regola, se l'elaborazione della regola TMG tramite l'impostazione predefinita Nega regola e restituisce una risposta di rifiuto all'applicazione Web.

Poiché gli utenti tendono a essere statisticamente habitual nell'utilizzo del Web, la cache di categoria URL diventerà più rilevante per l'organizzazione nel tempo come Forefront TMG elabora le richieste dell'utente. In questo modo, il rapporto tra le query MRS alle richieste dell'utente alla fine verrà ridotta. Poiché le categorie di URL sono soggette a modifica, MRS assegna un per durata per ogni voce. Di conseguenza, il numero di richieste MRS raggiungeranno mai completamente da zero, anche se gli utenti passare sempre gli stessi siti.

Per comprendere a fondo come funziona il filtro URL, è necessario inoltre comprendere come creano connessioni di applicazioni Web e inviare le richieste. Le applicazioni Web in genere rientrano in due categorie: quelli configurati come client proxy Web e quelli che non sono.

  • Proxy Web (CERN): Questo tipo di applicazione Web è configurato in modo che è a conoscenza di un proxy Web e in grado di comportarsi di conseguenza. L'applicazione Web si connette al listener di proxy Web e richieste di problemi in un modulo specifico:

HTTP:

METHOD http://website.contoso.com/path/page.aspx?querystring HTTP/1.x
METHOD http://1.2.3.4/path/page.aspx?querystring HTTP/1.x

In questo caso, Forefront TMG e, di conseguenza, filtro, URL è l'URL completo disponibile per il confronto con il database di filtro URL.

Nota: METHOD può essere qualsiasi metodo HTTP valida, ad esempio GET, POST e così via.

HTTPS:

CONNECT website.contoso.com:443 HTTP/1.x
CONNECT 1.2.3.4:666 HTTP/1.x

Per queste richieste Forefront TMG e filtraggio URL hanno solo il nome host o indirizzo IP (in base al modo in cui il client invia la richiesta) e la porta per confronto con il database di filtraggio URL.

  • Proxy Web non: Quando l'applicazione Web non è configurato per operare come client proxy CERN, tenterà di risolvere il nome del sito Web in un indirizzo IP e se l'esito è positivo, tenterà di connettersi a quell'indirizzo IP utilizzando qualsiasi porta faceva parte dell'URL originale. Indipendentemente dal fatto che il client sia un client TMG (precedentemente noto come client firewall) o un client SecureNET (cioè client SecureNAT), la richiesta verrà inviata tramite il seguente formato:
METHOD /path/page.aspx?querystring HTTP/1.x

In questo caso, la capacità di filtro per valutare la richiesta URL dipende da due criteri:

  • La connessione diretta alla porta HTTP predefinita? In tal caso, il proxy Web potrebbe essere in grado di intercettare la richiesta e passare al filtro per il confronto degli URL. Se non, la richiesta non verrà visualizzata da URL filtraggio e pertanto non può essere confrontato con il database.
  • Se la connessione viene indirizzata alla porta HTTPS all'impostazione predefinita, viene attivato HTTPS ispezione? In tal caso, ispezione HTTPS possibile colmare la connessione e filtraggio URL avrà un'opportunità per confrontare la richiesta al database.

Che cosa potrebbe non sembrare ovvio è che filtro nell'URL e di se stesso non fornisce alcun tipo di meccanismo di blocco, ovvero risponde semplicemente per il proxy Web con le categorie associate all'URL richiesto come proxy Web (e pertanto filtraggio URL) in grado di interpretare tale. In tutti i casi, quando filtraggio URL riceve una richiesta client, funziona come illustrato in Figura 2.

 

Nella figura 2 flusso base di filtro URL

Se è necessario eseguire una query MRS Forefront TMG, viene effettuata una richiesta utilizzando una singola chiamata di servizi Web per il portale di servizi Web MRS. MRS elabora i dati presentati da Forefront TMG e risponde con le categorie di URL corrente che si applicano ai dati MRS ricevuti. Forefront TMG 2010 è disponibile un insieme di dominio predefinito che include il portale destinazioni in vigore quando Forefront TMG spedito (vedere Figura 3).

 

Nella figura 3 Set Domain MRS

Se vengono trovate le categorie di URL restituite dal filtraggio URL in una regola “ negare ”, Forefront TMG invia una risposta di rifiuto (risultato-codice HTTP 502) al client. A seconda se il client è un browser o altre applicazioni Web, l'utente può vedere la pagina di risposta Forefront TMG; in caso di un'applicazione non browser (ad esempio Windows Media Player o a un'applicazione FTP CERN proxy), l'utente può semplicemente visualizzato un messaggio di errore dall'applicazione stessa.

Poiché l'attività più dispendiosa Forefront TMG deve eseguire per determinare che la categoria di URL è a query MRS, questo processo è molto meno costosi in termini di CPU, memoria e le risorse di rete rispetto a consentendo di raggiungere il sito Web, quindi di dover eseguire malware in tutto il contenuto di scansione richiesta.

Controllare il canale crittografato utilizzando HTTPS ispezione

Gli utenti siano stati informati da molti anni per eseguire una transazione in linea protetta, essi hanno utilizzano HTTP con SSL (HTTPS). Tuttavia, questo canale protetto è stato utilizzato anche per scopi dannosi. Quando l'utente avvia una transazione tramite HTTPS, il traffico crittografata in genere a un'estremità (dall'utente al server di destinazione), esegue contenuto scambiato tra di essi non leggibili a tutte le periferiche intermedie. Sebbene si tratti di un comportamento consigliabile, poiché non si desidera che chiunque osservando la transazione di carta di credito in linea, lo svantaggio è che non è possibile valutare qualsiasi operazione dannoso all'interno di questo canale. Nella figura 4 evidenzia le parti principali di questa operazione utilizzando ISA Server 2006 come il firewall.

 

Nella figura 4 tradizionale scenario HTTPS

Nella figura 4 illustrato uno scenario in cui il client accede un sito HTTPS con un proxy completo. Riepilogare operazioni sono suddivise in due fasi principali, come descritto di seguito:

Fase 1 – tunnel SSL

  1. Client si connette al proxy Web.
  2. Client emette una richiesta di tunnel SSL: CONNECT malicious.contoso.com:443 HTTP/1.1.
  3. Proxy Web risolve malicious.contoso.com all'indirizzo IP 1.2.3.4.
  4. Proxy Web si connette a 1.2.3.4 sulla porta TCP 443.
  5. Web proxy invia “ 200 OK ” al client.

Fase 2 – Encrypted conversazione

  1. I client e Web server SSL handshake messaggi di scambio delle chiavi di crittografia e certificati.
  2. Client dispone ora di un tunnel crittografato-end-to-end con il server di destinazione e verrà avviato invio e ricezione di traffico attraverso il tunnel.
  3. ISA Server manterrà tale tunnel aperta tra client e server, ma non verrà ispezionare il traffico perché non dispone di questa funzionalità.

Il potenziale rischio in questo scenario è che come della fase 2, il firewall perimetrale non è a conoscenza di ciò che veramente vengono trasmessi su quel canale. In uno scenario in cui il server di destinazione è violato e inserito codice dannoso, è un potenziale rischio per il server di destinazione verrà inviato tramite questo canale crittografato che il client riceverà senza immediatamente poiché proviene tramite una connessione trusted apparentemente malware.

Ispezione HTTPS TMG Forefront questo pericolo si riduce il traffico viene ispezionato da mantenere separati i canali crittografati con l'utente e il server. Nella Figura 5 viene illustrato in che modo Forefront TMG che svolge.

 

Nella figura 5 ispezione HTTPS in azione

Riepilogo procedura ancora è suddivise in due fasi principali; tuttavia, il processo include ora ispezione:

Fase 1 – richiesta client

  1. Client si connette a un listener TMG Web proxy.
  2. Client emette una richiesta di tunnel SSL: CONNECT malicious.contoso.com:443 HTTP/1.1.
  3. TMG risolve malicious.contoso.com all'indirizzo IP 1.2.3.4.
  4. TMG si connette a 1.2.3.4 sulla porta TCP 443.
  5. TMG negozia una connessione SSL con il server e viene valutato il certificato.
  6. Se il certificato è valida e attendibile, risponde TMG “ 200 OK ” al client.

Fase 2 – Encrypted conversazione con ispezione

  1. Client e TMG scambiano messaggi di handshake SSL, le chiavi di crittografia e certificati. Si noti che poiché TMG genera un certificato server utilizzando informazioni derivate dal certificato server Web, il client crede che comunica con il server Web.

  2. Client dispone ora di un tunnel crittografato con Forefront TMG e Forefront TMG dispone di un tunnel crittografato con il server di destinazione. Forefront TMG sarà in grado di controllare tutto il traffico inviato tra client e server seguendo questa sequenza:

    a) TMG riceve e lo decrittografa il traffico crittografato dal server di destinazione.

    b) TMG Applica filtri ispezione Malware e NIS al traffico.

    c) se il software dannoso e filtri NIS consentono, TMG verrà crittografare i risultati e inviarlo a workstation client.

    d) client verrà visualizzato, decrittografare ed elaborare il traffico.

Per stabilire l'handshake SSL con il client, Forefront TMG è necessario un certificato server. Per crearlo, Forefront TMG crea un certificato di spoof basato su dati del certificato server originale e firmato con il certificato CA ispezione HTTPS.  Per garantire prestazioni ottimali, Forefront TMG mantiene una cache dei certificati server duplicato. TMG eseguirà la ricerca di un certificato server duplicato nella cache locale e se non viene trovato uno, verrà duplicare il certificato del server upstream e inserirlo nella cache. La cache viene memorizzata solo in memoria. In questo modo, la cache del certificato spoof è vuota dopo il riavvio del servizio firewall.

Nota: La dimensione della cache (numero di certificati) è controllata dalla proprietà LowLevelSettings.ClonedCertificatesCacheSize COM.

Opzioni di ispezione HTTPS

Prima di configurare ispezione HTTPS, è importante comprendere la serie completa di funzionalità e le opzioni di questa funzionalità. Nella figura 6 vengono illustrate le aree in cui è possibile configurare HTTPS ispezione.

 

Nella figura 6 HTTPS ispezione Feature Set

Quando si pianifica l'implementazione di ispezione HTTPS, è necessario innanzitutto esaminare le impostazioni dei certificati, per decidere se si utilizzerà un certificato autofirmato o un certificato emesso da una CA interna. Durante l'importazione di un'autorità di certificazione attendibile esistente, è necessario un file PFX contenente il certificato dell'autorità di insieme con la relativa chiave privata. È necessario questa chiave privata per firmare il certificato di spoof emesso da TMG. Assicurarsi inoltre che l'utilizzo della chiave di certificato è impostato per la firma del certificato. Questo certificato CA deve quindi essere distribuito nei computer client (in “ Autorità di certificazione principale attendibili ” dell'archivio certificati computer locale); in caso contrario, il client non attendibili del server certificato ricevuto dal TMG.

In Forefront TMG, ispezione HTTPS può essere attivato tramite Criteri di accesso Web. Attenersi alla seguente procedura per attivare questa funzionalità:

  1. Dalla console di Forefront TMG, fare clic su criteri di accesso Web e selezionare Configura ispezione HTTPS in attività di protezione Web nel riquadro attività.
  2. Nella scheda Generale della schermata ispezione HTTPS in uscita, selezionare la casella di controllo di controllo Abilita HTTPS come illustrato in Figura 7.

 

Nella figura 7 Enabling ispezione HTTPS

In questo esempio, utilizzeremo un certificato autofirmato Forefront TMG. Fare clic su genera e una pagina simile a quello di Figura 8 apparirà .

 

Nella figura 8 genera certificati finestra

  1. Compilare il nome dell'autorità emittente, data di scadenza e l'istruzione emittente in base alle esigenze della società nella pagina genera certificato, quindi fare clic su genera certificati.
  2. Verrà generato un nuovo certificato e viene visualizzata la pagina certificato. Verificare la configurazione del certificato e fare clic su Chiudi.
  3. Scegliere OK per chiudere la finestra.
  4. Nella finestra di ispezione HTTPS in uscita, fare clic sul pulsante HTTPS ispezione Trusted Root CA certificati opzioni. Come illustrato in Figura 9 viene visualizzata la finestra Opzioni di distribuzione di certificati.

 

Nella figura 9 scelta come distribuire il certificato

  1. Se TMG appartiene a un dominio, il metodo di distribuzione consigliata è “ automaticamente tramite Active Directory. ” Quando si sceglie questa opzione, il certificato della CA TMG verrà distribuito automaticamente ai computer client utilizzando Criteri di gruppo. Fare clic sul pulsante di credenziali di amministratore di dominio e digitare le credenziali che verranno utilizzate per questa operazione. Scegliere OK . Nota non includere il dominio nel campo nome dell'utente.
  2. Poiché Forefront TMG utilizza lo strumento certutil per la pubblicazione del certificato della CA TMG in Active Directory, è possibile notare una finestra del prompt dei comandi breve. Fare clic su OK nella finestra di messaggio “ distribuzione automatica dei certificati ha avuto esito positivo ” e OK nella finestra di dialogo Opzioni di distribuzione di certificati.
  3. Fare clic su OK per terminare l'operazione.

Importante: Oltre a soddisfare i criteri di protezione dell'organizzazione, è inoltre necessario valutare eventuali normative legali e di conformità prima di attivare ispezione HTTPS. Tutti i siti in cui ispezione HTTPS viene considerato inappropriato possono essere aggiunti all'elenco delle eccezioni.

Esperienza utente avanzata

HTTPS ispezione e filtraggio URL in Forefront TMG consentono non solo offrono un ambiente di esplorazione protetta per gli utenti finali, includono inoltre funzionalità che migliorano l'esperienza dell'utente finale attraverso i messaggi informativi e fornendo i messaggi di errore personalizzati o preciso l'utente finale può essere direttamente correlato a.  

Notifiche client HTTPS

Per mantenere la conformità con i criteri di privacy aziendale, è possibile attivare notifiche lato client, che avvisa l'utente finale quando viene controllato da un sito SSL e lui offre la possibilità di abbandonare il sito per proteggere le informazioni che ritiene personali o classificata. Nella figura 10 viene illustrato questo comportamento.

 

Nella figura 10 HTTPS ispezione client-side notifica

Per l'utente di ricevere notifica di ispezione HTTPS, il computer client deve disporre di Forefront Client TMG installato e deve disporre di HTTPS ispezione attendibile autorità di certificazione principale installata nel computer locale autorità di certificazione fonti attendibili certificato memorizzare. È importante ricordare che se si dispone di configurazione TMG upstream e downstream, le notifiche di HTTPS necessario nel proxy downstream rispetto a monte proxy sia attivato.

Per implementare la notifica di HTTPS ispezione del lato client, è necessario attivarlo su client e server Forefront TMG. Per attivare le notifiche di ispezione HTTPS sul server:

  1. Nella console di gestione di TMG Forefront fare clic su criteri di accesso Web.
  2. In operazioni nel riquadro di destra fare clic su Configura ispezione HTTPS.
  3. Nella scheda notifiche client fare clic su notifica agli utenti che contenuto HTTPS è viene ispezionato e quindi fare clic su OK.

Per attivare le notifiche di Forefront TMG client:

  1. Fare clic con il pulsante destro del mouse sull'icona Forefront TMG client nella barra delle applicazioni e fare clic su Configura.
  2. Nella scheda ispezione Secure Connection selezionare notifica quando viene esaminato il contenuto inviato a siti Web protetti e fare clic su OK.

Messaggi di errore filtro URL

Un amministratore può consentire o negare l'accesso Web agli utenti finali in base alle categorie di URL. Se un utente tenta di visitare un sito è stato negato l'utente verrà visualizzato un errore di pagina simili a quelle nella Figura 11 , mostrare che l'accesso al sito è stato negato perché sono stati categorizzato come tali da Amministratore Forefront TMG.

 

Nella figura 11 accesso negato pagina Web

Il messaggio di errore può essere personalizzato dall'amministratore TMG. Per effettuare questa operazione:

  1. Aprire la console di gestione Forefront TMG e fare clic su criteri di accesso Web.
  2. Fare doppio clic per aprire la regola creata dall'amministratore per consentire o negare l'accesso.
  3. Fare clic nella scheda operazione come mostrato nella Figura 12.

 

Nella figura 12 personalizzazione di un messaggio di errore di filtro URL

È possibile aggiungere qualsiasi messaggio personalizzato alla notifica di negazione Visualizza utente nella casella di testo. È anche possibile utilizzare contenuto HTML, purché il codice HTML è valido all'interno del contesto di un elemento HTML < body >, ma non è possibile includere gli script.

È inoltre possibile visualizzare la categoria in cui è stato negato l'accesso al sito. A tale scopo, selezionare la casella di controllo per Add negato categoria della richiesta di notifica. Ciò è particolarmente utile se un sito è stato categorizzato in modo non corretto in modo che l'utente finale può informare. È, a sua volta, può inviare questo feedback a Microsoft tramite telemetry e contemporaneamente impostare una categoria di override per correggere la categorizzazione finché non viene risolto.

Se si desidera modificare l'aspetto dell'intera URL filtro errore messaggio pagina, sarà necessario modificare la pagina HTML 12232.htm. Troverete informazioni su questo argomento nella pagina Nega pagina Personalizzazione su Forefront TMG 2010Blog del team di prodotto Forefront (TMG) (ISA Server).

Jim Harrison unito il team di ISA Server supportavano Engineering come un tester QFE nel gennaio 2003. Ora è un program manager con Forefront Edge CS e un appassionato supporter server ISA e responsabile dell'implementazione di sistemi, nonché coautore di pagina community di Forefront chiamato “ racconti dal contorno ”

**Yuri Diogenes  *** *lavora per Microsoft una protezione senior supporta escalation engineer nel team di ISA Server/IAG. Diogenes è un coautore di pagina community di Forefront chiamato “ racconti dal contorno ”

**Mohit Saxena  *** *è il responsabile tecnico per Microsoft ISA Server supporto team, un gruppo di supporto e ai tecnici di escalation che funziona con i clienti con interruzione di risolvere i problemi, i bug e progettare le richieste di modifica.

Contenuto correlato