Archivi categoria: Networking

Azure Application Gateway: come monitorarlo con Log Analytics

L’Azure Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, disponibile in ambiente Azure, che consente di gestire il traffico HTTP e HTTPS delle applicazioni. In questo articolo verrà approfondito come effettuare il monitor degli Azure Application Gateway utilizzando Log Anaytics.

Figura 1 – Schema di base dell’Azure Application Gateway

Utilizzando l’Azure Application Gateway è possibile usufruire delle seguenti funzionalità:

  • Routing basato su URL
  • Redirection
  • Multiple-site hosting
  • Session affinity
  • Secure Sockets Layer (SSL) termination
  • Web application firewall (WAF)
  • Supporto nativo per i protocolli WebSocket e HTTP/2

Per maggiori dettagli sugli Azure Application Gateway è possibile consultare la documentazione ufficiale Microsoft.

Configurazione Diagnostics logs dell’Application Gateway

L’Azure Application Gateway prevede l’invio dei log di diagnostica verso un workspace di Log Analytics. Questa funzionalità è molto utile per controllare le performance, per rilevare eventuali errori ed è   fondamentale per operazioni di troubleshooting, in particolare in presenza del modulo WAF.  Per abilitare la diagnostica dal portale Azure è possibile selezionare la risorsa Application Gateway specifica ed accedere alla sezione “Diagnostics logs”:

Figura 2 –  Avvio della configurazione dei Diagnostics logs

Figura 3 – Configurazione dei Diagnostics logs

Dopo aver scelto il workspace di Log Analytics dove inviare i dati di diagnostica, nella sezione Log, è possibile selezionare quale tipologia di Log collezionare tra i seguenti:

  • Access log (ApplicationGatewayAccessLog)
  • Performance log (ApplicationGatewayPerformanceLog)
  • Firewall log (ApplicationGatewayFirewallLog): questi log vengono generati solo se il Web Application Firewall è configurato sull’Application Gateway.

Oltre a questi log sono inoltre collezionati di default gli Activity Log generati da Azure. Questi log vengono mantenuti per 90 giorni nello store dell’Azure event logs. Per maggiori dettagli è possibile consultare questo documento specifico.

Solution Azure Application Gateway analytics di Log Analytics

Microsoft mette a disposizione la solution Azure Application Gateway analytics che può essere aggiunta al workspace di Log Analytics seguendo questi semplici step:

Figura 4 – Avvio della procedura di aggiunta della solution al workspace OMS

Figura 5 – Selezione della solution Azure Application Gateway analytics

Figura 6 – Aggiunta della solution nel workspace selezionato

Dopo aver abilitato l’invio dei log di diagnostica verso il workspace di Log Analytics ed aver aggiunto sullo stesso la solution, selezionando il tile Azure Application Gateway analytics presente nella pagina di Overview, si potrà visualizzare una overview dei dati di log raccolti dall’Application Gateway:

Figura 7 – Schermata di overview della solution Azure Application Gateway analytics

Sarà inoltre possibile consultare i dettagli per le seguenti categorie.

  • Application Gateway Access logs:
    • Client and server errors for Application Gateway access logs
    • Requests per hour for each Application Gateway
    • Failed requests per hour for each Application Gateway
    • Errors by user agent for Application Gateways

Figura 8 – Schermata degli Application Gateway Access logs

  • Application Gateway performance:
    • Host health for Application Gateway
    • Maximum and 95th percentile for Application Gateway failed requests

Figura 9 – Schermata delle performance degli Application Gateway

Dashboard personalizzata di Log Analytics per il monitor dell’Application Gateway

Oltre a questa solution può essere conveniente utilizzare anche una apposita dashboard di Log Analytics, specifica per il monitoring dell’Application Gateway, reperibile a questo indirizzo. Il deploy della dashboard avviene tramite template ARM e richiede anche in questo caso l’abilitazione dei Diagnostics logs dell’Application Gateway, come descritto precedentemente. Le varie query di Log Analytics, utilizzate dalla dashboard, sono documentate in questo blog. Grazie a queste query la dashboard riporta diverse informazioni aggiuntive esposte dalla diagnostica dell’Application Gateway.

Figura 10 – Dashboard custom di Log Analytics per il monitor dell’Application Gateway

Query di Log Analytics per monitorare i Firewall Log

Utilizzando la solution Azure Application Gateway analytics di Log Analytics oppure la dashboard custom (riportata nel paragrafo precedente) non sono al momento contemplati i Firewall log, generati quando risulta attivo il Web Application Firewall (WAF) sull’Application Gateway. Il WAF si basa sulle regole di OWASP Core Rule Set 3.0 o 2.2.9 per intercettare gli attacchi, alle applicazioni Web, che sfruttano le più note vulnerabilità. Per citarne alcune, troviamo ad esempio gli attacchi SQL injection e gli attacchi cross site scripting.

In questo caso, qualora si decida di verificare i Firewall log, è necessario eseguire direttamente delle query di Log Analytics, come ad esempio:

Figura 11 – Query di LA per recuperare le richieste bloccate dal modulo WAF, negli ultimi 7 giorni, per uno specifico URI, suddivise per RuleId

Per consultare la lista delle regole del WAF, associando il RuleId alla relativa description, è possibile consultare questo documento.

Il messaggio descrittivo della rule viene riportato anche all’interno dei risultati restituiti dalla query:

Figura 12 – Query di LA per recuperare le richieste bloccate dal modulo WAF, negli ultimi 7 giorni, per uno specifico URI e per specifica RuleId

Conclusioni

Secondo la mia esperienza, nelle architetture Azure che richiedono la pubblicazione sicura di servizi Web verso internet, è spesso utilizzato il servizio Azure Application Gateway con il modulo WAF attivo. Grazie alla possibilità di inviare i log di diagnostica di questo componente verso Log Analytics si ha la possibilità di avere un monitor completo, che risulta fondamentale per analizzare eventuali condizioni di errore e per valutare lo stato del componete in tutte le sue sfaccettature.

Microsoft Azure: panoramica delle soluzioni di monitoring per la rete

In Microsoft Azure sono disponibili diverse soluzioni che consentono di monitorare le risorse di rete, non solo per ambienti cloud, ma anche in presenza di architetture ibride. Si tratta di funzionalità cloud-based, orientate a controllare lo stato di salute della rete e la connettività verso le proprie applicazioni. Inoltre, sono in grado di fornire informazioni dettagliate sulle performance di rete. In questo articolo verrà effettuata una panoramica delle diverse soluzioni riportandone le caratteristiche principali, necessarie per orientarsi nell’utilizzo degli strumenti di monitor della rete più opportuni per le proprie esigenze.

Network Performance Monitor (NPM) è una suite che comprende le seguenti soluzioni:

  • Performance Monitor
  • ExpressRoute Monitor
  • Service Endpoint Monitor

Oltre agli strumenti inclusi in Network Performance Monitor (NPM) è possibile utilizzare Traffic Analytics e DNS Analytics.

Performance Monitor

L’approccio sempre più frequentemente utilizzato è quello di avere ambienti ibridi con un networking eterogeneo, che consente di mettere in comunicazione la propria infrastruttura on-premises con l’ambiente implementato nel cloud pubblico. In alcuni casi si potrebbe disporre anche di differenti cloud provider, che rendono ancor più complicata l’infrastruttura di rete. Questi scenari richiedono pertanto l’utilizzo di strumenti di monitor flessibili e che possano lavorare in modo trasversale on-premises, in cloud (IaaS), e in ambienti ibridi. Performance Monitor ha tutte queste caratteristiche e grazie all’utilizzo di transazioni sintetiche, fornisce la possibilità di monitorare, pressoché in tempo reale, i parametri di rete per avere le informazioni relative alle performance, come la perdita di pacchetti e la latenza. Inoltre, questa soluzione consente di localizzare facilmente la sorgente di una problematica in uno specifico segmento di rete o identificando un determinato dispositivo. La soluzione richiede la presenza dell’agente di OMS e tenendo traccia dei pacchetti di retransmission e del tempo di roundtrip, è in grado di restituire un grafico di facile e immediata interpretazione.

Figura 1 – Diagramma Hop-by-hop fornito da Performance Monitor

Dove installare gli agenti

L’installazione dell’agente di Operations Management Suite (OMS) è necessario farla su almeno un nodo connesso a ogni sottorete dalla quale si intende monitorare la connettività verso altre sottoreti. Nel caso si intenda monitorare uno specifico link di rete è necessario installare gli agenti su entrambe gli endpoint del link. Nei casi dove non si è a conoscenza della topologia esatta di rete, un possibile approccio è quello di installare gli agenti su tutti i server che detengono workload particolarmente critici e per i quali è necessario monitorare le performance di rete.

Costo della soluzione

Il costo della funzionalità Performance Monitor in NPM è calcolato sulla base della combinazione di questi due elementi:

  • Subnet link monitorati. Per ottenere i costi per il monitoring di un singolo subnet link per un mese, è possibile consultare la sezione Ping Mesh.
  • Volume di dati.

Per maggiori dettagli a riguardo è possibile consultare la pagina ufficiale Microsoft.

ExpressRoute Monitor

Utilizzando ExpressRoute Monitor è possibile effettuare il monitor della connettività end-to-end e verificare le performance tra l’ambiente on-premises ed Azure, in presenza di connettività ExpressRoute con connessioni Azure Private peering e Microsoft peering. Le funzionalità chiave di questa soluzione sono:

  • Auto-detection dei circuit ExpressRoute associati alla propria subscription Azure.
  • Detection della topologia di rete.
  • Capacity planning e analisi dell’utilizzo di banda.
  • Monitoring e alerting sia per il primary che per il secondary path dei circuit ExpressRoute.
  • Monitoring sulla connettività verso i servizi Azure come Office 365, Dynamics 365 che utilizzano ExpressRoute come connettività.
  • Rilevamento di eventuali degradi della connettività verso le varie virtual network.

Figura 2 – Topology view di una VM su Azure (sinistra) connessa a una VM on-prem (destra), tramite connessione ExpressRoute

Figura 3 – Trend sull’utilizzo della banda e sulla latenza riscontrata sul circuit ExpressRoute

Dove installare gli agenti

Per poter utilizzare ExpressRoute Monitor è necessario installare almeno un agente di Operations Management Suite su un sistema che risiede sulla virtual network di Azure e almeno un agente su una macchina attestata sulla sottorete nell’ambiente on-premises, connessa tramite private peering di ExpressRoute.

Costo della soluzione

Il costo della soluzione ExpressRoute Monitor è calcolato in base al volume dei dati generato durante le operazioni di monitoring. Per maggiori dettagli è possibile consultare la sezione dedicata nella pagina dei costi di NPM.

Service Endpoint Monitor

Utilizzando questa soluzione si ha la possibilità di monitorare e testare la raggiungibilità dei propri servizi e delle proprie applicazioni, pressoché in tempo reale, simulando gli accessi degli utenti. Si ha inoltre la possibilità di rilevare problemi nelle prestazioni lato network e di individuare il segmento di rete problematico.

Si riportano le funzionalità principali della soluzione:

  • Effettua il monitor end-to-end delle connessioni di rete verso le proprie applicazioni. Il monitor può essere fatto di qualsiasi endpoint “TCP-capable” (HTTP, HTTPS, TCP, e ICMP), come websites, applicazioni SaaS, applicazioni PaaS, e database SQL.
  • Correla la disponibilità delle applicazioni con le performance della network, per localizzare con precisione il punto di degrado sulla rete, partendo dalla richiesta dell’utente fino al raggiungimento dell’applicativo.
  • Testa la raggiungibilità delle applicazioni da differenti location geografiche.
  • Determina le latenze di rete e i pacchetti persi per raggiungere le proprie applicazioni.
  • Rileva hot spots sulla rete che possono causare problemi di performance.
  • Effettua il monitor della raggiungibilità di applicazioni Office 365, tramite test built-in specifici per Microsoft Office 365, Dynamics 365, Skype for Business e altri servizi Microsoft.

Figura 4 – Creazione di un Service Connectivity Monitor test

Figura 5 – Diagramma che mostra la topology di rete, generata da diversi nodi, per raggiungere un Service Endpoint

Dove installare gli agenti

Per utilizzare Service Endpoint Monitor è necessario installare l’agente di Operations Management Suite su ogni nodo da cui si vuole monitorare la connettività di rete verso uno specifico service endpoint.

Costo della soluzione

Il costo per l’utilizzo di Service Endpoint Monitor è basato su questi due elementi:

  • Numero delle connessioni, dove la connessione è intesa come test di raggiungibilità di un singolo endpoint, da un singolo agente, per l’intero mese. A questo proposito è possibile consultare la sezione Connection Monitoring nella pagina dei costi.
  • Volume di dati generato dall’attività di monitor. Il costo lo si ricava dalla pagina dei costi di Log Analytics, nella sezione Data Ingestion.

Traffic Analytics

Traffic Analytics è una soluzione totalmente cloud-based, che consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. In Azure per poter consentire o negare la comunicazione di rete verso le risorse connesse alle Azure Virtual Networks (vNet) vengono utilizzati i Network Security Group (NSG), che contengono una lista di regole di accesso. I NSG vengono applicati alle interfacce di rete connesse alle macchine virtuali oppure direttamente alle subnet. La platform utilizza i NSG flow logs per mantenere la visibilità del traffico di rete in ingresso e in uscita dai Network Security Group. Traffic Analytics si basa sull’analisi dei NSG flow logs e dopo una opportuna aggregazione dei dati, inserendo l’intelligence necessaria relativamente a security, topologia e mappa geografica, è in grado di fornire informazioni dettagliate sul traffico di rete del proprio ambiente cloud Azure.

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

  • Visualizzare le attività di rete cross Azure subscriptions e identificare hotspots.
  • Intercettare potenziali minacce di security lato network, per poi poter adottare le giuste operazioni correttive. Questo viene reso possibile grazie alle informazioni riportate dalla soluzione: quali porte sono aperte, quali applicazioni tentano di accedere verso Internet e quali macchine virtuali si connettono a reti non autorizzate.
  • Comprendere i flussi di rete presenti tra le varie region Azure e Internet, al fine di ottimizzare il proprio deployment di rete in termini di performance e capacità.
  • Individuare configurazioni di rete non corrette che portano ad avere tentativi di comunicazione errati.
  • Analisi delle capacità dei gateway VPN o di altri servizi, per rilevare problemi generati da over-provisioning o sottoutilizzo.

Figura 6 – Traffic Analytics overview

Figura 7 – Map delle Region Azure attive sulla subscription

DNS Analytics

La soluzione DNS Analytics è in grado di collezionare, analizzare e correlare i log del servizio DNS e mette a disposizione degli amministratori le seguenti funzionalità:

  • Indentifica i client che tentano di risolvere domini ritenuti malevoli.
  • Rileva i record appartenenti a risorse obsolete.
  • Mette in evidenza nomi di dominio frequentemente interrogati.
  • Mostra il carico delle richieste ricevute dai server DNS.
  • Effettua il monitor delle registrazioni dinamiche sul DNS fallite.

Figura 8 – Overview della solution DNS Analytics

Dove installare gli agenti

La soluzione richiede la presenza dell’agente di OMS oppure di Operations Manager installato su ogni server DNS che si intende monitorare.

Conclusioni

All’aumentare della complessità delle architetture network in ambienti ibridi, aumenta di conseguenza la necessità di potersi avvalere di strumenti in grado di contemplare differenti topologie di rete. Azure mette a disposizione diversi strumenti cloud based e integrati nella fabric, come quelli descritti in questo articolo, che consentono di monitorare in modo completo ed efficace il networking di questi ambienti. Ricordo che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Tutto quello che bisogna sapere sui nuovi Load Balancer di Azure

Microsoft ha recentemente annunciato la disponibilità in Azure degli Standard Load Balancer. Si tratta di load balancer Layer-4, per i protocolli TCP e UDP che, rispetto ai Basic Load Balancer, introducono dei miglioramenti e consentono di avere un controllo più granulare di determinate funzionalità. In questo articolo verranno riportate le caratteristiche principali degli Standard Load Balancer di Azure, al fine di poter avere gli elementi necessari per scegliere la tipologia di bilanciatore più opportuna per le proprie esigenze.

Qualsiasi scenario dove è possibile utilizzare la SKU Basic degli Azure Load Balancer, può essere soddisfatto anche utilizzando la SKU Standard, ma le due tipologie di bilanciatori presentano importanti differenze in termini di scalabilità, funzionalità, livelli di servizio garantito e costo.

Scalabilità

I Load Balancer Standard hanno una maggiore scalabilità, rispetto ai Basic Load Balancer, per quanto riguarda il numero massimo delle istanze (IP Configuration) che possono essere configurate nei pool di backend. La SKU Basic consente di avere fino a 100 istanze, mentre utilizzando la SKU Standard il numero massimo di istanze è pari a 1000.

Funzionalità

Backend pool

Per quanto riguarda i Basic Load Balancer, nei pool di backend, possono risiedere in modo esclusivo:

  • Macchine virtuali che si trovano all’interno di un availability set.
  • Una singola VM standalone.
  • Virtual Machine Scale Set.

Figura 1 – Associazioni possibili nei backend pool dei Basic Load Balancer

Negli Standard Load Balancer invece è consentito inserire nei pool di backend qualsiasi macchina virtuale attestata su una determinata virtual network. Lo scope di integrazione in questo caso non è infatti l’availability set, come per i load balancer Basic, ma è la virtual network e tutti i relativi concetti ad essa associati. Un requisito da tenere in considerazione, per poter inserire nei backend pool degli Standard Load Balancer le macchine virtuali, è che queste non devono avere IP pubblici associati oppure devono avere IP Pubblici con SKU Standard.

Figura 2 – Associazione nei backend pool degli Standard Load Balancer

Availability Zones

Gli Standard Load Balancer contemplano scenari di integrazione con le Availability Zones, nelle region che comprendono questa funzionalità. Per maggiori dettagli a riguardo è possibile consultare questo specifico documento Microsoft, che riporta i concetti principali e le linee guida di implementazione.

Alta disponibilità delle porte

I load balancer con SKU Standard, di tipologia “Internal”, consentono di bilanciare i flussi TCP e UDP su tutte le porte simultaneamente. Per farlo, nella regola di load-balancing, c’è la possibilità di abilitare l’opzione “HA Ports”:

Figura 3 – Configurazione rule di bilaciamento con opzione “HA Ports” abilitata

Il bilanciamento avviene per flusso, il quale è determinato dai seguenti elementi: source IP address, source port, destination IP address, destination port, e protocollo. Questa funzionalità risulta particolarmente utile in scenari dove vengono utilizzate delle Network Virtual Appliances (NVAs) che richiedono scalabilità. Questa nuova funzionalità consente di migliorare le attività richieste relative ad implementazioni in HA delle NVAs.

Figura 4 – Architettura di rete che prevede l’utilizzo del LB con opzione “HA Ports” abilitata

Un altro possibile utilizzo di questa funzionalità è quando si ha la necessità di bilanciare un elevato numero di porte.

Per maggiori dettagli in merito all’opzione “HA Ports” è possibile consultare la documentazione ufficiale.

Diagnostica

I Load Balancer Standard introducono le seguenti funzionalità in termini di capacità diagnostica:

  • Multi-dimensional metrics: si possono recuperare differenti metriche che consentono di consultare, in tempo reale, lo stato di utilizzo dei load balancer, sia pubblici che interni. Queste informazioni risultano particolarmente utili anche per operazioni di troubleshooting.

Figura 5 – Metriche dei Load Balancer dal portale Azure

  • Resource Health: in Azure Monitor si ha la possibilità di consultare lo stato di salute dei Load Balancer Standard (al momento disponibile solo per i Load Balancer Standard di tipologia Public).

Figura 6 – Resource health del Load Balancer in Azure Monitor

Si può inoltre consultare lo storico dello stato di health:

Figura 7 – Health history del Load Balancer

Tutti i dettagli relativi alla diagnostica, dei Load Balancer Standard, possono essere consultati nella documentazione ufficiale.

Sicurezza

I Load Balancer con SKU standard sono configurati di default in modo sicuro in quanto, per consentire il funzionamento, è necessario avere un Network Security Group (NSG) dove il flusso di traffico viene consentito in modo esplicito. Come riportato in precedenza, i Load Balancer Standard sono completamente integrati nella virtual network, la quale è caratterizzata dal fatto che è privata e di conseguenza chiusa. I Load Balancer Standard e gli IP Pubblici Standard vengono utilizzati per consentire l’accesso alle virtual network dall’esterno e ora di default è necessario configurare un Network Security Group (chiuso di default) per consentire il traffico voluto. Nel caso non sia presente un NSG, attestato sulla subnet oppure sulla NIC della macchina virtuale, non sarà consentito il relativo accesso da parte del flusso di rete proveniente dal Load Balancer Standard.

I Load Balancer Basic sono invece di default aperti e la configurazione di un Network Security Group è opzionale.

Connessioni in Outbound

I Load Balancer in Azure supportano scenari di connettività sia in inbound che in outbound. I Load Balancer Standard, rispetto ai Load Balancer Basic, si comportano in modo differente per quanto riguarda le connessioni in outbound.

Per effettuare il mapping degli indirizzamenti IP interni e privati della propria virtual network verso gli indirizzi IP pubblici dei Load Balancer viene utilizzata la tecnica Source Network Address Translation (SNAT). I Load Balancer Standard introducono un nuovo algoritmo per avere politiche di SNAT più robuste, scalabili e precise, che consentono di avere una maggiore flessibilità e di disporre di nuove funzionalità.

Utilizzando i Load Balancer Standard è opportuno considerare i seguenti aspetti per quanto riguarda gli scenari di outbound:

  • Devono essere creati in modo esplicito per consentire alle macchine virtuali la connettività in uscita e sono definiti sulla base delle regole di bilanciamento in ingresso.
  • Le regole di bilanciamento definiscono come avvengono le politiche di SNAT.
  • In presenza di più frontend, vengono utilizzati tutti i frontend e per ognuno di questi si moltiplicano le porte SNAT preallocate disponibili.
  • Si ha la possibilità di scegliere e controllare se uno specifico frontend non lo si vuole utilizzare per le connessioni in uscita.

Nei Basic Load Balancer, in presenza di più frontend IP Pubblici, viene scelto un singolo frontend per essere utilizzato nei flussi in uscita. Questa selezione non può essere configurata e avviene in modo casuale.

Per designare un indirizzo IP specifico è possibile seguire la procedura descritta in questa sezione della documentazione Microsoft.

Operazioni di Management

I Load Balancer di tipologia Standard consentono l’abilitazione delle operazioni di management in modo più rapido, tanto da portare i tempi di esecuzione di queste operazioni al di sotto dei 30 secondi (contro i 60-90 secondi necessari per i Load Balancer con SKU Basic). I tempi di modifica dei pool di backend sono dipendenti anche dalla dimensione degli stessi.

Altre differenze

Al momento per i Public Load Balancer di tipologia Standard non è possibile prevedere l’utilizzo di un indirizzo IPv6 pubblico:

Figura 8 – IPv6 pubblico per i Public Load Balancer

 

Service-Level Agreement (SLA)

Un importante aspetto da tenere in considerazione, nella scelta della SKU più opportuna per le diverse architetture, è il livello di servizio che si deve garantire (SLA). Utilizzando i Load Balancer Standard viene garantito che un Load Balancer Endpoint, che serve due o più istanze di macchine virtuali in stato di salute, sarà disponibile temporalmente con uno SLA del 99.99%.

I Load Balancer Basic non garantisco questo SLA.

Per maggiori dettagli a riguardo è possibile consultare l’articolo specifico SLA for Load Balancer.

 

Costo

Mentre per i Load Balancer Basic non sono previsti dei costi, per i Load Balancer Standard sono previsti dei costi di utilizzo in base ai seguenti elementi:

  • Numero delle regole di load balancing configurate.
  • Quantità dei dati processati in ingresso e in uscita.

Non sono invece previsti costi specifici per le regole di NAT.

Nella pagina dei costi dei Load Balancer possono essere consultati i dettagli e le cifre.

 

Migrazione tra SKUs

Per i Load Balancer non è previsto il passaggio dalla SKU Basic alla SKU Standard e viceversa. Ma è necessario prevedere una migrazione in side by side, tenendo in considerazione le differenze funzionali precedentemente descritte.

 

Conclusioni

L’introduzione dei Load Balancer Standard in Azure consente di disporre di nuove funzionalità e garantiscono una maggiore scalabilità. Queste caratteristiche potrebbero consentire di non dover utilizzare, in scenari specifici, soluzioni di bilanciamento offerte da vendor di terze parti. Rispetto ai Load Balancer tradizionali (SKU Basic) cambiano diversi principi di funzionamento e hanno caratteristiche distinte in termini di costi e SLA, che è bene valutare attentamente per poter scegliere la tipologia di Load Balancer più opportuna, sulla base dell’architettura che si deve realizzare.

Come monitora le attività di rete nel cloud Azure con Traffic Analytics

Le reti nel mondo cloud presentano differenze sostanziali rispetto a quelle presenti in ambiente on-premises, ma sono accomunate dalla necessità di essere costantemente monitorate, gestite e analizzate. Tutto ciò è importante per poterle conoscere al meglio, al fine di proteggerle ed ottimizzarle. Microsoft ha introdotto in Azure la soluzione Traffic Analytics, totalmente cloud-based, che consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. Questo articolo analizza le caratteristiche della soluzione e spiega come è possibile attivarla.

Principi di funzionamento della soluzione

In Azure per poter consentire o negare la comunicazione di rete verso le risorse connesse alle Azure Virtual Networks (vNet) vengono utilizzati i Network Security Group (NSG), che contengono una lista di regole di accesso. I NSG vengono applicati alle interfacce di rete connesse alle macchine virtuali oppure direttamente alle subnet. La platform utilizza i NSG flow logs per mantenere la visibilità del traffico di rete in ingresso e in uscita dai Network Security Group. Traffic Analytics si basa sull’analisi dei NSG flow logs e dopo una opportuna aggregazione dei dati, inserendo l’intelligence necessaria relativamente a security, topologia e mappa geografica, è in grado di fornire informazioni dettagliate sul traffico di rete del proprio ambiente cloud Azure.

Figura 1 – Data flow di Traffic Analytics

Funzionalità della soluzione

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

  • Visualizzare le attività di rete cross Azure subscriptions e identificare hotspots.
  • Intercettare potenziali minacce di security lato network, per poi poter adottare le giuste operazioni correttive. Questo viene reso possibile grazie alle informazioni riportate dalla soluzione: quali porte sono aperte, quali applicazioni tentano di accedere verso Internet e quali macchine virtuali si connettono a reti non autorizzate.
  • Comprendere i flussi di rete presenti tra le varie region Azure e Internet, al fine di ottimizzare il proprio deployment di rete in termini di performance e capacità.
  • Individuare configurazioni di rete non corrette che portano ad avere tentativi di comunicazione errati.

Come abilitare la soluzione

Per poter analizzare il traffico di rete è necessario disporre di un Network Watcher in ogni region dove sono presenti i NSG per i quali si intente analizzare il traffico. Il Network Watcher è un servizio regionale grazie al quale è possibile monitorare e diagnosticare il networking di Azure. L’abilitazione del Network Watcher può essere fatta dal portale Azure, tramite Powershell oppure via REST API. Creandolo dal portale non è possibile stabilire il nome del Network Watcher e il relativo Resource Group, ma viene assegnato un nome di default a entrambe le entità.

Figura 2 – Abilitazione del Network Watcher dal portale

Figura 3 – Abilitazione del Network Watcher tramite PowerShell

Trattandosi di un servizio in preview per poterlo utilizzare è necessario effettuare nuovamente la registrazione del network resource provider sulla subscription Azure interessata. Inoltre è necessario registrare il provider Azure Insights.

Figura 4 – Registrazione dei provider tramite PowerShell

Per poter abilitare la raccolta degli NSG Flow Logs è necessario dotarsi di uno storage account sul quale memorizzarli. Inoltre è necessario disporre di un workspace OMS Log Analytics sul quale Traffic Analytics consoliderà i dati aggregati e indicizzati. Le informazioni presenti in Log Analytics verranno poi utilizzate per generare la relativa analisi.

Primo step di configurazione delle impostazioni dei NSG flow logs:

Figura 5 – Selezione dei NSG sui quali abilitare la raccolta dei flow logs

Scelta dello storage account e del workspace OMS Log Analytics per ogni NSG:

Figura 6 – Abilitazione della raccolta dei NSG flow logs e del consolidamento in OMS Log Analytics

Gli step precedentemente riportati dovranno essere ripetuti per ogni NSG per il quale si desidera abilitare Traffic Analytics.

Figura 7 – Lista dei NSGs con le impostazioni abilitate

Entro alcuni minuti dall’abilitazione, tempo necessario per avere un quantitativo di dati aggregati sufficientemente indicativo, viene popolata la relativa dashboard con le informazioni di Traffic Analytics.

Figura 8 – Dashboard di Traffic Analytics

Dalla dashboard di Traffic Analytics sono facilmente reperibili le informazioni quali: gli host con un livello elevato di comunicazione, i protocolli applicativi maggiormente utilizzati, le comunicazioni che avvengono in modo più frequente e i flussi relativi al traffico di rete nel cloud.

Selezionando la sezione di interesse viene mostrata la query di Log Analytics che estrapola i dati:

Figura 9 – Esempio di query Log Analytics che mostra il traffico malicious consentito

Per avere una panoramica completa dei possibili scenari di utilizzo di Traffic Analytics è possibile consultare questo documento Microsoft.

Conclusioni

Traffic Analytics è una nuova funzionalità, al momento in preview, introdotta in Azure. Si tratta di uno strumento efficace e di facile utilizzo che consente di tenere sotto controllo lo stato della rete in Azure riportando dati molto utili, come chi si sta collegando e dove, quali porte sono esposte verso internet, quale traffico di rete viene generato e molto altro. Si tratta di informazioni fondamentali per individuare eventuali anomalie e apportare le dovute azioni correttive. Tutte operazioni di difficile raggiungimento senza questo strumento totalmente integrato nella platform.

OMS e System Center: novità di Novembre 2017

Nel mese di novembre ci sono state diverse novità annunciate da Microsoft riguardanti Operations Management Suite (OMS) e System Center. In questo articolo verranno riepilogate in modo sintetico con i riferimenti necessari per poter effettuare ulteriori approfondimenti in merito.

Operations Management Suite (OMS)

Log Analytics

Come già annunciato a partire dal 30 ottobre 2017 Microsoft ha avviato il processo di upgrade dei workspace OMS non ancora aggiornati manualmente. A questo proposito è stata rilasciato questo utile documento che riporta le differenze tra un workspace OMS legacy e un workspace OMS aggiornato, con i riferimenti per ottenere maggiori dettagli.

Solutions

Coloro che utilizzano circuit ExpressRoute saranno lieti di sapere che Microsoft ha annunciato la possibilità di effettuarne il monitor tramite Network Performance Monitor (NPM). Si tratta di una funzionalità al momento in preview che consente di monitorare la connettività e le performance tra l’ambiente on-premises e le vNet in Azure in presenza di circuit ExpressRoute. Per maggiori dettagli sulle funzionalità annunciate è possibile consultare l’articolo ufficiale.

Figura 1 – Network map che mostra i dettagli della connettività ExpressRoute

Agente

Come di consueto è stata rilasciata una nuova versione dell’agente OMS per sistemi Linux che ormai da tempo avviene con cadenza mensile. In questo rilascio sono stati risolti bug riguardanti la diagnostica durante la fase di onboarding degli agenti. Non sono stare introdotte ulteriori novità. Per ottenere la versione aggiornata è possibile consultare la pagina ufficiale GitHub OMS Agent for Linux Patch v1.4.2-124.

Protezione e Disaster Recovery

Azure Backup ha sempre protetto i backup effettuati dal mondo on-premises verso Azure tramite encryption che avviene utilizzando la passphrase definita in fase di configurazione della soluzione. Per la protezione delle macchine virtuali in Azure la raccomandazione per avere maggiore sicurezza nei backup era di utilizzare VM con disk-encrypted. Ora Azure Backup utilizza Storage Service Encryption (SSE) per fare l’encryption dei backup delle macchine virtuali su Azure, consentendo di avere in modo integrato nella soluzione un meccanismo per la messa in sicurezza dei backup. Questo avverrà anche per i backup esistenti in modo automatico e tramite attività in background.

Microsoft, al fine di far maggiore chiarezza in merito al pricing ed al licensing di Azure Site Recovery, ha aggiornato le FAQ che è possibile consultare nella pagina ufficiale del pricing della soluzione.

System Center

Come già avviene per il sistema operativo e per System Center Configuration Manager, anche gli altri prodotti  System Center, in particolare Operations Manager, Virtual Machine Manager e Data Protection Manager seguiranno un rilascio di versioni aggiornate ogni 6 mesi (semi-annual channel). L’obiettivo è di fornire rapidamente nuove funzionalità e di garantire una pronta integrazione con il mondo cloud, il che diventa fondamentale vista la velocità con cui si evolve. Nel mese di novembre è stata annunciata la preview di System Center versione 1711 che è possibile scaricare a questo indirizzo.

Figura 2 – Sintesi delle novità introdotte nella preview di System Center versione 1711

Per conoscere i dettagli delle le novità introdotte in questo rilascio è possibile consultare l’annuncio ufficiale.

System Center Configuration Manager

Per System Center Configuration Manager current branch versione 1706 è stato rilasciato un importante update rollup che è consigliabile applicare in quanto risolve un numero considerevole di problematiche.

Rilasciata la versione 1710 per il Current Branch (CB) di System Center Configuration Manager che introduce nuove funzionalità e importanti miglioramenti nel prodotto. Tra le principali novità di questo aggiornamento emergono sicuramente le possibilità offerte dal Co-management che ampliano le possibilità di gestione dei device utilizzando sia System Center Configuration Manager che Microsoft Intune.

Figura 3 – Caratteristiche e benefici del Co-management

Per l’elenco completo delle nuove funzionalità introdotte in questa versione di Configuration Manager è possibile consultare l’annuncio ufficiale.

Rilasciata la versione 1711 per il branch Technical Preview di System Center Configuration Manager. Tra le novità introdotte in questo aggiornamento troviamo:

  • Miglioramenti nel nuovo Run Task Sequence step.
  • User interaction in fase di installazione di applicazioni nel contesto System anche durante l’esecuzione di una task sequence.
  • Nuove opzioni, nello scenario di utilizzo di Configuration Manager connesso con Microsoft Intune, per gestire policy di compliance per device Windows 10 in relazione a Firewall, User Account Control, Windows Defender Antivirus, e OS build versioning.

Vi ricordo che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

Rilasciata una versione aggiornata del Configuration Manager Client Messaging SDK.

System Center Operations Manager

Rilasciata la nuova wave dei Management Pack di SQL Server (versione 7.0.0.0):

I Management Pack relativi a SQL Server 2017 possono essere utilizzati per il monitor di SQL Server 2017 e di release successive (version agnostic), questo consente di evitare di dover gestire differenti MP per ogni versione di SQL Server. I controlli per le versioni di SQL Server precedenti alla 2014 sono inclusi nel MP generico “Microsoft System Center Management Pack for SQL Server”.

System Center Service Manager

Microsoft ha pubblicato una serie di accorgimenti e di best practices da seguire in fase di Authoring di Management Pack di System Center Service Manager (SCSM).

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

OMS e System Center: novità di Agosto 2017

In questo articolo vengono riassunte le principali novità e vengono riportati gli aggiornamenti, riguardanti Operations Management Suite (OMS) e System Center, che sono stati annunciati durante il mese di agosto.

Operations Management Suite (OMS)

Log Analytics

  • Per Log Analytics è stato pubblicato quello che può essere definito il più importante aggiornamento dalla data del suo rilascio. Tra le principali novità introdotte da questo aggiornamento troviamo un nuovo e potente linguaggio per la creazione delle query, l’introduzione del nuovo portale Advanced Analytics e una maggiore integrazione con Power BI. Per maggiori dettagli vi invito a consultare l’articolo specifico Log Analytics: un importante aggiornamento evolve la soluzione.

Figura 1 – Upgrade di Log Analytics

Agente

  • L’agente OMS per sistemi Linux è in continua evoluzione ed è stata rilasciata una nuova versione che ha risolto alcuni bug e ha migliorato la gestione degli errori in fase di onboarding dell’agente per facilitare le operazioni di troubleshooting: OMS Agent for Linux GA v1.4.0-45

Figura 2 – Elenco Bug Fix e novità del nuovo agente OMS per Linux

Solutions

  • La solution OMS Network Performance Monitor è stata migliorata ed arricchita con le seguenti nuove funzionalità:
    • Diagnostica dell’agent: la solution ora fornisce la possibilità di monitorare in una specifica view lo stato di salute dei vari agenti NPM distribuiti sulla rete e in caso di problemi riporta delle informazioni di diagnostica utili per la relativa risoluzione.
    • Hop-by-hop latency breakdown: la topology map della rete è stata arricchita con i dettagli dei tempi di latenza riscontrati tra due punti specifici.
    • Disponibilità sul portale Azure: oltre a continuare ad essere disponibile dal portale OMS può essere aggiunta dal Marketplace Azure e utilizzata direttamente dal portale Azure.
    • Presenza in ulteriori region di Azure: la solution è ora disponibile anche per la region Azure West Central US.

Per maggiori dettagli a riguardo è possibile consultare l’annuncio Improvements to OMS Network Performance Monitor.

  • La tecnologia emergente Docker container è sempre più diffusa e il monitor diventa un componente essenziale. Per questo motivo il team di OMS ha annunciato la disponibilità della nuova solution Container Monitoring che consente di:
    • Visualizzare in un’unica location le informazioni relative a tutti gli host container.
    • Conoscere quali container sono in esecuzione, dove lo sono e con quale immagine.
    • Vedere informazioni di audit riguardanti le azioni svolte sui container.
    • Visualizzare e ricercare log a fini di troubleshooting senza dover accedere agli host Docker.
    • Individuare i container che stanno consumando un quantitativo eccessivo di risorse sull’host.
    • Visualizzare a livello centralizzato informazioni di performance relative ai container riguardanti l’utilizzo della CPU, della memoria, dello storage e della network.

Figura 3 – Schema di sintesi della solution Container Monitoring

Tutti i dettagli sulla solution Container Monitoring è possibile consultarli nel documento Container Monitoring solution in Log Analytics.

  • Rilasciata in preview la nuova solution per il monitoring delle Azure Logic Apps. La solution consente di visualizzare diverse informazioni relative allo stato delle logic app e di fare il drill down per consultare maggiori dettagli utili a fini di troubleshooting. Tutti gli aspetti di questa solution è possibile consultarli nella documentazione ufficiale Microsoft.

Security e Audit

  • La baseline assesment di OMS Security si arricchisce con la funzionalità Web security baseline assessment che è stata annunciata in public preview e consente di effettuare la scansione dei web server con Internet Information Service (IIS) per controllare la presenza di eventuali vulnerabilità di security e fornisce utili raccomandazioni relative alla corretta configurazione dell’ambiente. Il documento Web Baseline Assessment in Operations Management Suite Security and Audit Solution riporta ulteriori informazioni in merito.

Figura 4 – Dashboard dell’assessment della Web security baseline

 

System Center

System Center Configuration Manager

  • Lo scorso mese è stata rilasciata la versione 1706 per il Current Branch (CB) di System Center Configuration Manager come riportato nell’articolo OMS e System Center: novità di Luglio 2017. In data 8 agosto è stato pubblicato un package di update per correggere alcuni errori che sono stati riscontrati durante i primi deployment, ma tale package introduceva dei problemi pertanto in data 11 agosto è stato sostituito con una nuova versione. Per coloro che hanno aggiornato SCCM alla versione 1706 tra l’8 agosto e l’11 agosto è necessario che venga installato un ulteriore aggiornamento come documentato nella knowledge base Microsoft Update for System Center Configuration Manager version 1706, first wave. Tale aggiornamento è possibile installarlo accedendo al nodo “Updates and Servicing” della console di SCCM. Sarà inoltre rilasciato un ulteriore aggiornamento nelle prossime settimana per chi ha effettuato l’update di SCCM alla versione 1706 prima dell’8 agosto.
  • Rilasciata la versione 1708 per il branch Technical Preview di System Center Configuration Manager: Update 1708 for Configuration Manager Technical Preview Branch – Available Now!. Vi ricordo che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

System Center Operations Manager

In seguito le novità relative ai Management Pack di SCOM 2016:

  • Advanced Threat Analytics 1.7 Management Pack versione 1.7.1.1.
  • Service Map Management Pack in public preview: grazie a questo nuovo MP è possibile integrare le mappe create dinamicamente dalla soluzione Service Map di OMS con i diagrammi delle Distributed Application di Operations Manager per fare in modo che quest’ultimi vengano generati e mantenuti in modo dinamico.

Per maggiori informazioni vi invito a consultare la relativa documentazione disponibile online.

Figura 5 – Integrazione tra le Service Map di OMS e le Distributed App di SCOM

  • Disponibile una hotfix per risolvere alcune problematiche relative al monitor WMI health.

Come connettere soluzioni di security di terze parti a OMS

Tra le varie funzionalità di Operations Management Suite (OMS) c’è la possibilità di collezionare eventi generati nel formato standard Common Event Format (CEF) ed eventi generati da device Cisco ASA. Molti vendor di soluzioni di security generano eventi e file di log rispettando la sintassi definita nello standard CEF per garantire l’interoperabilità con altre soluzioni. Configurando l’invio di dati in questo formato verso OMS e adottando la soluzione OMS Security and Audit è possibile mettere in correlazione le diverse informazioni raccolte, sfruttare il potente motore di ricerca di OMS per monitorare la propria infrastruttura, recuperare informazioni di audit, rilevare eventuali problemi e utilizzare la funzionalità di Threat Intelligence.

In questo articolo verranno approfonditi gli step necessari per integrare i log generati da Cisco Adaptive Security Appliance (ASA) all’interno di OMS. Per poter configurare questa integrazione è necessario disporre di una macchina Linux con installato l’agente di OMS (versione 1.2.0-25 o successiva) e configurarla per inoltrare i log ricevuti dagli apparati verso il workspace OMS. Per l’installazione e l’onboard dell’agente Linux vi rimando alla documentazione ufficiale Microsoft: Steps to install the OMS Agent for Linux.

Figura 1 – Architettura per la raccolta dei log da Cisco ASA in OMS

L’apparato Cisco ASA deve essere configurato per inoltrare gli eventi generati verso la macchina Linux definita come collector. Per farlo è possibile utilizzare gli strumenti di gestione del device Cisco ASA come ad esempio Cisco Adaptive Security Device Manager:

Figura 2 – Esempio di configurazione Syslog Server di Cisco ASA

Sulla macchina Linux deve essere in esecuzione il daemon syslog che si occuperà di inviare gli eventi verso la porta UDP 25226 locale. L’agente OMS è infatti in ascolto su questa porta per tutti gli eventi in ingresso.

Per fare questa configurazione è necessario creare il file security-config-omsagent.conf rispettando le specifiche seguenti a seconda della tipologia di Syslog in esecuzione sulla macchina Linux. Un possibile esempio di configurazione per inviare tutti gli eventi con facility local4 all’agente OMS è la seguente:

  • In caso di daemon rsyslog il file dovrà essere presente nella directory /etc/rsyslog.d/ con il seguente contenuto:
#OMS_facility = local4

local4.* @127.0.0.1:25226
  • In caso di daemon syslog-ng il file dovrà essere presente nella directory /etc/syslog-ng/ con il seguente contenuto:
#OMS_facility = local4  

filter f_local4_oms { facility(local4); };  

destination security_oms { tcp("127.0.0.1" port(25226)); };  

log { source(src); filter(f_local4_oms); destination(security_oms); };  

Lo step successivo è la creazione del file di configurazione Fluentd denominato security_events.conf che consente di collezionare e di fare il parsing degli eventi ricevuti dall’agente OMS. Il file è possibile scaricarlo dal repository GitHub e dovrà essere copiato nella directory /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/.

Figura 3 – File di configurazione Fluentd dell’agent OMS

Giunti a questo punto, per rendere effettive le modifiche apportate, è necessario riavviare il daemon syslog e l’agente OMS tramite i seguenti comandi:

  • Riavvio daemon Syslog:
sudo service rsyslog restart oppure sudo /etc/init.d/syslog-ng restart
  • Riavvio agente OMS:
sudo /opt/microsoft/omsagent/bin/service_control restart

Completate queste operazioni è opportuno visualizzare il log dell’agente OMS per verificare la presenza di eventuali errori utilizzando il comando:

tail /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log

Dopo aver concluso la configurazione dal portale OMS sarà possibile digitare in Log Search la query Type=CommonSecurityLog per analizzare i dati collezionati dall’apparato Cisco ASA:

Figura 4 – Query per visualizzare eventi del Cisco ASA raccolti in OMS

La raccolta di log di questo tipo è arricchita dalla funzionalità di Threat Intelligence presente nella solution Security & Compliance che grazie a una correlazione pressoché in tempo reale dei dati raccolti nel repository OMS con le informazioni provenienti dai principali vendor di soluzioni di Threat Intelligence e con i dati forniti dai centri di sicurezza Microsoft consente di individuare la natura e l’esito di eventuali attacchi che coinvolgono i nostri sistemi, compresi gli apparati di rete.

Accedendo alla solution Security And Audit dal portale OMS viene visualizzata la sezione Threat Intelligence:

Figura 5 – Informazioni di Threat Intelligence

Selezionando il tile Detected threat types è possibile consultare i dettagli relativi ai tentativi di intrusione che nel caso seguente coinvolgono l’apparato Cisco ASA:

Figura 5 – Detected threat su Cisco ASA

In questo articolo si è entrati nel dettagli della configurazione di Cisco ASA, ma configurazioni analoghe è possibile farle per tutte le soluzioni che supportano la generazione di eventi nel formato standard Common Event Format (CEF). Per configurare l’integrazione di Check Point Securtiy Gateway con OMS vi rimando al documento Configuring your Check Point Security Gateways to send logs to Microsoft OMS.

Conclusioni

Utilizzando Operations Management Suite c’è la possibilità di consolidare e di mettere in correlazione eventi provenienti da diversi prodotti che forniscono soluzioni di security consentendo di avere una panoramica completa della propria infrastruttura e di rispondere in modo rapido e preciso ad eventuali incident di security.

Monitorare le performance di rete con la nuova solution di OMS

In questo articolo vedremo come funziona e quali sono le caratteristiche principali della nuova solution di OMS chiamata Network Performance Monitor (NPM). Si tratta di una soluzione in grado di controllare lo stato della rete anche in presenza di architetture ibride consentendo di identificare rapidamente l’eventuale segmento o device di rete che in un determinato momento sta causando oppure ha causato disservizi o problemi di performance lato network. Questo nuovo servizio effettua il monitor della rete in modalità application centric e tale caratteristica la rende differente rispetto alle tradizionali soluzioni di monitor presenti sul mercato che tendenzialmente hanno un focus particolare sul controllo degli apparati di rete.

Figura 1 – Overview della solution NPM

Utilizzando la solution Network Performance Monitor di OMS è possibile avere una visibilità totale per quanto riguarda la disponibilità, le latenze e le performance della propria infrastruttura di rete. Il processo di attivazione e di funzionamento è il seguente:

  • Accedendo al portale OMS si aggiunge la solution “Network Performance Monitor (NPM)” presente nella gallery delle solution di OMS. Per farlo è possibile seguire gli step che trovate documentati nel seguente articolo: Aggiungere soluzioni di gestione di Operations Management Suite (OMS)
  • La solution richiede l’agente OMS installato sulle macchine presenti in ogni subnet che si desidera monitorare. Si tratta dell’agente OMS tradizionale e non è richiesta l’installazione di nessun ulteriore componente.
  • Le macchine con a bordo l’agente OMS effettueranno il download da OMS del Network Monitoring Intelligence Pack il quale consente di effettuare il detect della subnet su cui è attestata la macchina e di fare l’upload di queste informazioni verso il workspace OMS.
  • L’agente recupera a sua volta le configurazioni della rete da OMS e vengono effettuati dei probe per individuare eventuali perdite di pacchetti e le performance di rete. Network Performance Monitor (NPM) fa uso di transazioni sintetiche per calcolare quanti pacchetti vengono persi e la latenza presente per i vari link di rete. I pacchetti di probe che vengono inviati tra i vari agenti OMS per effettuare l’assessment e per monitorare lo stato della rete possono essere TCP (pacchetti TCP SYN seguiti da un TCP handshake) oppure ICMP (messaggi ICMP ECHO come quelli generati dall’utility tradizionale Ping). L’utilizzo del protocollo ICMP per effettuare i probe è utile in ambienti dove a causa di determinate restrizioni gli apparati di rete non sono in grado di rispondere a dei probe di tipologia TCP.
  • Tutti i dati vengono inviati verso il workspace OMS e vengono aggregati per visualizzare in modo chiaro e comprensibile lo stato della rete. Grazie infatti al Topology Map si ha a disposizione una visualizzazione grafica di tutti i percorsi di rete presenti tra i vari endpoint che aiuta a localizzare rapidamente eventuali problemi di rete. Le topology map sono interattive e consentono di fare il drill down sui vari collegamenti di rete per visualizzare hop-by-hop i dettagli della topologia. Inoltre è possibile impostare dei filtri in base allo stato di salute dei link, effettuare lo zoom sui segmenti di rete e personalizzare la topologia.

Figura 2 – Network Topology

Le principali caratteristiche della soluzione sono le seguenti:

  • La soluzione è agnostica dal punto di vista dei dispositivi di rete e dei relativi vendor ed è in grado di monitorare qualsiasi rete IP.
  • La solution è in grado di effettuare il monitor della connettività tra:
    • Data-center dislocati in site differenti e connessi tramite rete pubblica o privata.
    • Cloud pubblici quali Azure e AWS, reti on-premises e postazioni utente.
    • Reti virtuali presenti presso cloud pubblici e on-premises.

      Figura 3 – Componenti monitorati dalla solution NPM

  • NPM consente di identificare in modo preciso e dettagliato il path di rete che sta causando un disservizio o un degrado di performance, a prescindere dalla complessità della rete, grazie al modello di monitoring adottato:

    Figura 4 – Modello di monitoring

  • Grazie alla funzionalità definita Network State Recorder è possibile non solo vedere lo stato di salute attuale della rete, ma di valutarlo anche in un determinato momento del passato, utile per investigare segnalazioni di problematiche transitorie.

    Figura 5 – Network State Recorder

  • Utilizzando la funzionalità di alerting inclusa in OMS è possibile configurare l’invio di segnalazioni tramite posta elettronica a fronte di problematiche riscontrate dalla solution NPM. Inoltre è possibile scatenare azioni di remediation tramite runbook oppure configurare webhooks per integrarsi con una soluzione esistente di service management.

    Figura 6 – NPM alerting

  • La soluzione supporta non solo sistemi Windows Server ma l’agente funziona anche per sistemi operativi client (Windows 10, Windows 8.1, Windows 8 e Windows 7) ed è presente anche il supporto per sistemi operativi Linux (server e workstation).

Per quanto riguarda il costo ed il modello di licensing la solution Network Performance Monitor (NPM) è parte di OMS Insight & Analytics. Nella pagina Prezzi di Microsoft Operations Management Suite trovate tutti i dettagli inerenti al pricing di OMS.

 

Conclusioni

In ambienti IT che vedono architetture sempre più complesse è utile disporre di uno strumento per monitorare in modo efficace lo stato della rete e che permette di isolare con precisione la sorgente di eventuali problemi. Utilizzando la solution Network Performance Monitor (NPM) di OMS si ha una visibilità completa della rete anche in architettura ibride e si può agire in modo proattivo nell’identificazione di potenziali problemi. NPM è inoltre uno strumento adatto non solo per gli amministratori di rete, ma grazie alle sue caratteristiche può essere molto utile e facilmente utilizzabile anche da chi gestisce l’infrastruttura e gli applicativi.  Per chi è interessato ad approfondire ulteriormente questa e altre funzionalità di OMS ricordo che è possibile provare la soluzione OMS gratuitamente. Per maggiori informazioni relative alla solution Network Performance Monitor (NPM) è possibile consultare la documentazione ufficiale.

Windows Server 2016: Networking What’s New

GestioneNetworkController

In Windows Server 2016 sono molte le novità introdotte in ambito networking che ci consentono di realizzare una infrastruttura funzionale, denominata Software Defined Networking (SDN), che è alla base del Software Defined Datacenter (SDDC). Se volete saperne di più non perdetevi questo articolo sulla community WindowServer.it.

Windows Server 2016: Introduzione al Network Controller

In Windows Server 2016 sono molte le novità introdotte in ambito networking che ci consentono di realizzare una infrastruttura funzionale, denominata Software Defined Networking (SDN), che è alla base del Software Defined Datacenter (SDDC).

Le caratteristiche principali dell’architettura Software Defined Networking (SDN) sono l’adattabilità, la dinamicità e la facilità di gestione. Tutti questi aspetti possono essere contemplati al meglio grazie all’introduzione in Windows Server 2016 delle funzionalità che andremo ad approfondire in questo articolo.

Network Controller

Si tratta di un nuovo ruolo introdotto in Windows Server 2016 che può essere facilmente installato tramite Server Manager oppure utilizzando PowerShell e che consente di gestire, configurare e monitorare l’infrastruttura di rete virtuale e fisica del proprio datacenter. Grazie al Network Controller è anche possibile automatizzare la configurazione della propria infrastruttura di rete anziché dover configurare manualmente device e servizi. Questo ruolo può essere installato anche su macchine virtuali, prevede di essere messo in alta disponibilità e può scalare facilmente. Il deploy del Network Controller può essere fatto sia in ambiente di dominio, in questo caso l’autenticazione degli utenti e dei device di rete avviene tramite Kerberos, che in un ambiente non di dominio richiedendo l’autenticazione basata su certificati.

La comunicazione tra il Network Controller e i componenti di rete avviene utilizzando l’interfaccia Southbound API, figura 1, grazie alla quale viene fatto il discovery degli apparati di rete e rilevata la configurazione dei servizi. Inoltre tramite la stessa interfaccia vengono raccolte le informazioni di rete necessarie e trasmesse agli apparati le modifiche effettuate.

Tramite l’interfaccia Northbound API è possibile comunicare con il Network Controller per consultare le informazioni di rete ed utilizzarle per fare monitoring e troubleshooting. La stessa API viene utilizzata per apportare modifiche alla configurazione di rete e per fare il deploy di nuovi device.

2015_12_27_WS16NC_01
Figura 1 – Schema Comunicazione

La gestione e il monitor della rete tramite Network Controller, figura 2, può avvenire direttamente tramite PowerShell (Network Controller Cmdlets) oppure utilizzando applicazioni di management come ad esempio System Center Virtual Machine Manager (SCVMM) e System Center Operations Manager (SCOM).

2015_12_27_WS16NC_02

Figura 2 – Gestione Network Controller

Tramite il Network Controller è possibile gestire i seguenti componenti dell’infrastruttura di rete fisica e virtuale:

  • Hyper-V VMs e virtual switch
  • Switch
  • Router
  • Firewall software
  • VPN Gateway (compreso RRAS Multitenant Gateway)
  • Load Balancer

Funzioni Network Virtualizzate

La diffusione della virtualizzazione ha coinvolto anche il settore network e c’è sempre più interesse nelle appliance virtuali e nei servizi cloud che erogano servizi di rete con un mercato emergente in forte crescita. Nei software defined datacenter vediamo infatti sempre più frequentemente l’utilizzo di appliance virtuali per erogare funzionalità di rete che tipicamente venivano erogate esclusivamente da apparati fisici (come ad esempio bilanciatori, firewall, router, switch, etc.).

In Windows Server 2016 Technical Preview sono disponibili le seguenti virtual appliance:

Software Load Balancer

Si tratta di un bilanciatore software layer-4, con caratteristiche analoghe al load balancer già ampliamente utilizzato sulla piattaforma Azure. Per maggiori informazioni su Microsoft Azure Load Balancing Services vi invito a consultare Microsoft Azure Load Balancing Services.

Firewall Multi-Tenant

Il Datacenter Firewall, figura 3, è un nuovo servizio introdotto in Windows Server 2016. Questo firewall è in grado di proteggere il layer network delle reti virtuali ed è pensato per essere multitenant. Quando viene implementato può essere offerto come servizio dal service provider e l’amministratore del tenant può installare e configurare delle firewall policy per proteggere le proprie reti virtuali da potenziali attacchi che provengono da internet o dalle reti interne.

2015_12_27_WS16NC_03

Figura 3 – Firewall Policy

La gestione del Datacenter Firewall può essere fatta utilizzando il network controller. Il Datacenter Firewall offre i seguenti vantaggi per il cloud service provider:

  • Un servizio firewall software scalabile e gestibile che può essere offerto come servizio ai propri tenant
  • Offre protezione ai tenant indipendentemente dal sistema operativo in esecuzione sulla macchina virtuale
  • Libertà di spostare le macchine virtuali dei tenant su host della fabric differenti senza interrompere le funzionalità firewall erogate in quanto:
  • L’agente firewall viene deployato come porta vSwitch;
  • Le macchine virtuali del tenant prendono le policy assegnate al loro vSwitch;
  • Le regole del firewall vengono configurate in ogni porta del vSwitch, indipendentemente dall’host fisico che detiene la macchina virtuale

Per quanto riguarda i tenant invece il Datacenter Firewall offre i seguenti vantaggi:

  • Possibilità di definire regole sul firewall per aumentare la protezione dei workload esposti nelle virtual network verso Internet
  • Possibilità di creare delle regole sul firewall per la protezione tra macchine virtuali presenti sulla stessa subnet layer 2 oppure su subnet L2 differenti
  • Possibilità di definire delle regole firewall per aumentare la protezione e isolare il traffico di rete tra la rete tenant on premise e la propria virtual network presente presso il service provider

RAS Gateway

RAS Gateway viene utilizzato per fare routing del traffico di rete tra le reti virtuali e le reti fisiche. Diversi sono gli ambiti di utilizzo:

Site-to-Site Gateway

Soluzione gateway multi-tenant, figura 4, che consente ai tenant di accedere alle loro risorse e di gestirle utilizzando una connessione VPN site-to-site. Grazie a questo gateway è possibile mettere in comunicazione risorse virtuali nel cloud con la rete fisica del tenant.

2015_12_27_WS16NC_04

Figura 4 – S2S Gateway

Forwarding Gateway

Utilizzato per fare routing del traffico di rete tra le reti virtuali e la rete fisica del provider di hosting (nella stessa location geografica) – figura 5.

2015_12_27_WS16NC_05

Figura 5 – Forwarding Gateway

GRE Tunnel Gateway

I gateway sono in grado di creare tunnel basati sul protocollo GRE che forniscono connettività tra le virtual network dei tenant e le reti esterne. Il protocollo GRE è supportato in molti apparati di rete, pertanto è una scelta ideale quando non viene richiesta l’encryption del canale. Per maggiori dettagli sul tunnel GRE vi invito a consultare GRE Tunneling in Windows Server Technical Preview.

Hyper-V Network Virtualization

La Network Virtualization di Hyper-V (HNV) è un componente fondamentale della soluzione Software Defined Networking (SDN) di Microsoft e come tale sono molte le novità introdotte in Windows Server 2016 per renderlo sempre più funzionale e integrato nello stack SDN.

Un aspetto importante da tenere in considerazione quando si parla di SDN è che lo stesso stack è consistente con Microsoft Azure e ci consente quindi di portare le stesse potenzialità utilizzate nel public cloud di Azure presso la propria realtà.

Programmable Hyper-V Switch

Tramite il componente Network Controller è possibile fare la push delle policy HNV, figura 6, verso l’agent in esecuzione su ogni host che utilizza l’Open vSwitch Database Management Protocol (OVSDB – RFC 7047). L’Host Agent memorizza queste policy utilizzando una customizzazione dello schema VTEP ed è in grado di programmare regole anche complesse all’interno del performante motore dell’Hyper-V virtual switch.

2015_12_27_WS16NC_06

Figura 6 – Push Policies

Supporto a VXLAN Encapsulation

Il protocollo Virtual eXtensible Local Area Network (VXLAN – RFC 7348) è stato ampliamente adottato sul mercato con il supporto di importanti vendor come Cisco, Brocade, Dell, HP e altri. L’HNV ora supporta questo schema di incapsulamento utilizzando la modalità di distribuzione MAC attraverso il Microsoft Network Controller, il quale consente di programmare l’associazione tra gli indirizzi IP del tenant (Customer Address – CA) e gli indirizzi IP della rete fisica (Provider Address – PA). Il protocollo di incapsulamento Network Virtualization Generic Routing Encapsulation (NVGRE) continua ad essere supportato anche in Windows Server 2016.

Interoperabilità con il Software Load Balancer (SLB)

Il software load balancer (SLB) presentato in precedenza è pienamente supportato in ambito reti virtuali. Il SLB avviene attraverso il performante motore del virtual switch e controllato dal network controller per quanto riguarda il mapping Virtual IP (VIP) – Dynamic IP (DIP).

IEEE Compliant

Per garantire la piena interoperabilità con apparati di rete fisici e virtuali Microsoft garantisce che tutti i pacchetti trasmessi quando si utilizza HNV sono in tutti i suoi campi compliant con gli standard dettati da IEEE. Questo aspetto è stato fortemente curato e ulteriormente migliorato in Windows Server 2016.

Nuovi Elementi Introdotti (Cloud Scale Fundamentals)

In Windows Server 2016 sono state introdotte le seguenti funzionalità per avere la possibilità di configurare il proprio ambiente in modo più efficace, sfruttando al meglio le risorse hardware a disposizione:

Converged Network Interface Card (NIC): Questa funzionalità consente di utilizzare una singola scheda di rete per gestire tipologie differenti di traffico: il management, l’accesso allo storage (RDMA) e il traffico dei tenant. In questo modo è possibile diminuire il numero di schede di rete necessarie per ogni host fisico.

Switch Embedded Teaming (SET): SET è una nuova soluzione di NIC Teaming integrata nei Virtual Switch di Hyper-V. SET consente di avere teaming composti fino ad un massimo di otto schede di rete fisiche in un unico SET team. Questa modalità di teaming, essendo integrata nei virtual switch, può essere utilizzata solo sugli host fisici e non all’interno delle macchine virtuali, dove sarà comunque possibile configurare teaming in modo tradizionale (NIC Teaming in Virtual Machines). Questa modalità di teaming non espone interfacce di team, ma le configurazioni vanno apportate tramite Virtual Switch port.

2015_12_27_WS16NC_07

Packet Direct: Packet Direct consente di raggiungere un elevato throughput e una bassa latenza per il traffico di rete.

Novità Apportate ai Servizi Esistenti

DHCP
La funzionalità Network Access Protection (NAP) è già nello stato “deprecated” in Windows Server 2012 R2. In Windows Server 2016 il ruolo DHCP Server non supporterà più la funzionalità NAP e gli scope DHCP non potranno più essere NAP-enabled.

DNS Server
Approfondiamo ora quelle che sono in Windows Server 2016 le diverse novità introdotte sul servizio DNS Server per migliorare l’efficacia e la sicurezza:

DNS Policy: è possibile configurare delle policy DNS per definire come il server DNS risponde alle query DNS. Le risposte DNS possono essere in base a molti parametri, come ad esempio all’indirizzo IP del client (location) oppure all’ora del giorno. Le policy DNS aprono le porte a diversi scenari di configurazione come DNS location-aware, gestione del traffico, load balancing e split-brain DNS.

Response Rate Limiting (RRL): è possibile configurare sul server DNS dei limiti sul response rate. Questo tipo di configurazione ci consente di evitare l’utilizzo del sistema DNS da parte di sistemi malevoli per effettuare attacchi di tipo DOS (denial of service).

DNS-based Authentication of Named Entities (DANE): è possibile utilizzare i record TLSA (Transport Layer Security Authentication) per fornire informazioni ai DNS Client riguardanti quale CA è attesa per uno specifico domain name. Questo meccanismo risulta utile per poter prevenire attacchi ti tipologia man-in-the-middle.

Supporto degli Unknown Record: questa funzionalità consente di aggiungere record che non risultano supportati in modo esplicito dal Server DNS Windows.

IPv6 root hints: è possibile utilizzare gli IPV6 root server per effettuare la risoluzione dei nomi Internet.

Windows PowerShell Support: è stato migliorato il supporto PowerShell introducendo nuovi cmdlets per il DNS Server.

DNS e IPAM: miglior integrazione tra il servizio DNS e IPAM.

Vi invito ad approfondire e valutare direttamente sul campo le nuove funzionalità introdotte in ambito networking scaricando Windows Server 2016.