Category Archives: Networking

Azure Networking: introduction to the Hub-Spoke model

A network topology increasingly adopted by Microsoft Azure customers is the network topology defined Hub-Spoke. This article lists the main features of this network architecture, examines the most common use cases, and shows the main advantages that can are obtained thanks to this architecture.

The Hub-Spoke topology

In a Hub-Spoke network architecture, theHub is a virtual network on Azure that serves as the point of connectivity to the on-premises network. This connectivity can be done through VPN Site to site or through ExpressRoute. The Spoke are virtual networks running the peering with the Hub and can be used to isolate workloads.

The architecture basic scheme:

Figure 1 – Hub-Spoke basic network architecture

This architecture is also designed to position in the Hub network a network virtual appliance (NVA) to control the flow of network traffic in a centralized way.

Figure 2 - Possible architecture of Hub vNet in the presence of NVA

In this regard it should be noted that Microsoft recently announced the availability of the’Azure Firewall, a new managed service and fully integrated into the Microsoft public cloud, that allows you to secure the resources present on the Virtual Networks of Azure. At the moment the service is in preview, but soon it will be possible to assess the adoption of Azure Firewall to control centrally, through policy enforcement, network communication streams, all cross subscriptions and cross virtual networks. This service, in the presence of Hub-Spoke network architectures , lends itself to be placed in the Hub network, in order to obtain complete control of network traffic.

Figure 3 - Positioning Azure Firewall in the Hub Network

For additional details on Azure Firewall you can see Introduction to Azure Firewall.

When you can use the Hub-Spoke topology

The network architecture Hub-Spoke is typically used in scenarios where these characteristics are required in terms of connectivity:

  • In the presence of workloads deployed in different environments (development, testing and production) which require access to the shared services such as DNS, IDS, Active Directory Domain Services (AD DS). Shared services will be placed in the Hub virtual network, while the various environments (development, testing and production) will be deployed in Spoke networks to maintain a high level of insolation.
  • When certain workloads must not communicate with all other workloads, but only with shared services.
  • In the presence of reality that require a high level of control over aspects related to network security and needing to make a segregation of the network traffic.

Figure 4 – Hub-Spoke architecture design with its components

The advantages of the Hub-Spoke topology

The advantages of this Azure network topology can be summarized as:

  • Cost savings, because shared services can be centralized in one place and used by multiple workloads, such as the DNS server and any virtual appliances. It also reduces the VPN Gateways to provide connectivity to the on-premises environment, with a cost savings for Azure.
  • Granular separation of tasks between IT (SecOps, InfraOps) and workloads (Devops).
  • Greater flexibility in terms of management and security for the Azure environment.

Useful references for further reading

The following are the references to the Microsoft technical documentation useful to direct further investigation on this topic:

Conclusions

One of the first aspects to consider when you implement solutions in the cloud is the network architecture to be adopted. Establish from the beginning the most appropriate network topology allows you to have a winning strategy and avoid to be in the position of having to migrate workloads, to adopt different network architectures, with all the complications that ensue.

Each implementation requires a careful analysis in order to take into account all aspects and to make appropriate assessments. It is therefore not possible to assert that the Hub-Spoke network architecture is suitable for all scenarios, but certainly it introduces several benefits that make it effective for obtaining certain characteristics and have a high level of flexibility.

What's new in Virtual Machine Manager 1807

Following the first announcement of the Semi-Annual Channel release of System Center, took place in February with the version 1801, in June has been released the new update release: System Center 1807. This article will explore the new features introduced in System Center Virtual Machine Manager (SCVMM) the update release 1807.

Networking

Information related to the physical network

SCVMM 1807 introduced an important improvement in the field of network. In fact, using the Link Layer Discovery Protocol (LLDP), SCVMM can provide information regarding connectivity to the physical network of Hyper-V hosts. These are the details that SCVMM 1807 can retrieve:

  • Chassis ID: Switch chassis ID
  • Port ID: The Switch port to which the NIC is connected
  • Port Description: Details on the port, such as the Type
  • System Name Manufacturer: Manufacturer and Software version details
  • System Description
  • Available Capabilities: Available features of the system (such as switching, Routing)
  • Enabled Capabilities: Features that are enabled on the system (such as switching, Routing)
  • VLAN ID: Virtual LAN identifier
  • Management Address: management IP address

The consultation of this information can be via Powershell or by accessing the SCVMM console: View > Host > Properties > Hardware Configuration > Network adapter.

Figure 1 – Information provided by SCVMM 1807 regarding the physical connectivity of Hyper-V hosts

These details are very useful for having visibility on the physical network and to facilitate troubleshooting steps. This information will be made available for Hyper-V hosts that meet the following requirements:

  • Windows Server Operating System 2016 or later.
  • Features DataCenterBridging and DataCenterBridging-LLDP-Tools enabled.

Conversion SET in Logical Switch

SCVMM 1807 can convert a Hyper-V Virtual Switch, created in Switch Embedded Teaming mode (SET), in a logical switch, using directly the SCVMM console. In previous versions of SCVMM this operation was feasible only through PowerShell commands. This conversion can be useful to generate a Logical Switch, that can be used as a template on different Hyper-V hosts that are managed by SCVMM. For more information on Switch Embedded Teaming (SET) I invite you to consult the article Windows Server 2016: the new Virtual Switch in Hyper-V

Support for host VMware ESXi v6.5

SCVMM 1807 introduced support for VMware ESXi host v 6.5 within its fabric. For what is my experience, even in environments that consist of multiple hypervisors, hardly you use SCVMM to manage VMware host. This support is important because it introduces the ability to convert VMs hosted on VMWare ESXi host 6.5 in Hyper-v VMs.

 

Storage

Support for selecting the CSV to use when adding a new disk

SCVMM 1807 allows you to specify, during the addition of a new virtual disk to an existing VM, in which cluster shared volumes (CSV) place it. In previous releases of VMM this possibility was not provided and by default the new virtual disks were placed on the same CSV where the disks that have been associated with the virtual machine were present. In some circumstances, such as in the presence of CSV with little free space available, this behavior could be inadequate and inflexible.

Figure 2 – Adding a new disk to a virtual machine by selecting which CSV place it

Support for the update of cluster Storage Spaces Direct (S2D)

In Virtual Machine Manager 2016 there is support for making the deployment of Storage Spaces Direct cluster (S2D). With SCVMM 1807 has also introduced the possibility of patching and update of Storage Spaces Direct cluster nodes, orchestrating the entire update process, which will use the baseline configured in Windows Server Update Services (WSUS). This feature allows you to more effectively manage the Storage Spaces Direct environment, cornerstone of the Software Defined Storage of Microsoft, that leads to the achievement of the Software Defined Data Center.

 

Statement of support

Support for SQL Server 2017

In SCVMM 1807 was introduced the support for SQL Server 2017 to host its database. This allows you to upgrade from SQL Server 2016 to SQL Server 2017.

 

Conclusions

The update release 1807 introduces several innovations in Virtual Machine Manager that greatly enrich it in terms of functionality. In addition, This update also addresses a number of issues listed in Microsoft's official documentation. It is therefore recommended to evaluate an update of the Virtual Machine Manager deployments, for greater stability and to take advantage of the new features introduced. Remember that the release belonging to the Semi-Annual Channel have a support period of 18 months.

To try out System Center Virtual Machine Manager, you must access to theEvaluation Center and after the registration you can start the trial period.

Introduction to Azure Firewall

Microsoft recently announced the availability of a long-awaited service required by the users of systems in the Azure environment , it is the’Azure Firewall. The Azure Firewall is a new managed service and fully integrated into the Microsoft public cloud, that allows you to secure the resources present on the Virtual Networks of Azure. This article will look at the main features of this new service, currently in preview, and it will indicate the procedure to be followed for its activation and configuration.

Figure 1 – Positioning of Azure Firewall in network architecture

The Azure Firewall is a type of firewall stateful, which makes it possible to centrally control, through policy enforcement, network communication streams, all cross subscriptions and cross virtual networks. This service, in the presence of type of network architectures hub-and-spoke, lends itself to be placed in the Hub network, in order to obtain a complete control of the traffic.

The Azure Firewall features, currently available in this phase of public preview, are the following:

  • High availability (HA) Built-in: high availability is integrated into the service and are not required specific configurations or add-ons to make it effective. This is definitely an element that distinguishes it compared to third-party solutions that, for the configuration of Network Virtual Appliance (NVA) in HA, typically require the configuration of additional load balancers.
  • Unrestricted cloud scalability: Azure Firewall allows you to scale easily to adapt to any change of network streams.
  • FQDN filtering: you have the option to restrict outbound HTTP/S traffic towards a specific list of fully qualified domain names (FQDN), with the ability to use wild card characters in the creation of rules.
  • Network traffic filtering rules: You can create rules to allow or of deny to filter the network traffic based on the following elements: source IP address, destination IP address, ports and protocols.
  • Outbound SNAT support: to the Azure Firewall is assigned a public static IP address, which will be used by outbound traffic (Source Network Address Translation), generated by the resources of the Azure virtual network, allowing easy identification from remote Internet destinations.
  • Azure Monitor logging: all events of Azure Firewall can be integrated into Azure Monitor. In the settings of the diagnostic logs you are allowed to enable archiving of logs in a storage account, stream to an Event Hub, or set the sending to a workspace of OMS Log Analytics.

Azure Firewall is currently in a managed public preview, which means that to implement it is necessary to explicitly perform the enable via the PowerShell command Register-AzureRmProviderFeature.

Figure 02 – PowerShell commands for enabling the public preview of Azure Firewall

Feature registration can take up to 30 minutes and you can monitor the status of registration with the following PowerShell commands:

Figure 03 – PowerShell commands to verify the status of enabling Azure Firewall

After registration, you must run the following PowerShell command:

Figure 04 – Registration command of Network Provider

To deploy the Azure Firewall on a specific Virtual Network requires the presence of a subnet called AzureFirewallSubnet, that must be configured with a sunbnet mask at least /25.

Figure 05 – Creation of the subnet AzureFirewallSubnet

To deploy Azure Firewall from the Azure portal, you must select Create a resource, Networking and later See all:

Figure 06 - Search Azure Firewall in Azure resources

Filtering for Firewall will also appear the new resource Azure Firewall:

Figure 07 – Microsoft Firewall resource selection

By starting the creation process you will see the following screen that prompts you to enter the necessary parameters for the deployment:

Figure 08 – Parameters required for the deployment of the Firewall

Figure 09 – Review of selected parameters and confirmation of creation

In order to bring outbound traffic of a given subnet to the firewall you must create a route table that contains a route with the following characteristics:

Figure 10 - Creation of the Rule of traffic forwarding to the Firewall Service

Although Azure Firewall is a managed service, you must specify Virtual appliance as next hop. The address of the next hop will be the private IP of Azure Firewall.

The route table must be associated with the virtual network that you want to control with Azure Firewall.

Figure 11 - Association of the route table to the subnet

At this point, for systems on the subnet that forwards the traffic to the Firewall, is not allowed outgoing traffic, as long as it is not explicitly enabled:

Figure 12 – Try to access blocked website from Azure Firewall

Azure Firewall provides the following types of rules to control outbound traffic.

Figure 13 – The available rule Types

  • Application rules: to configure access to specific fully qualified domain names (FQDNs) from a given subnet.

Figure 14 - Creating Application rule to allow access to a specific website

  • Network rules: enable the configuration of rules that contain the source address, the protocol, the address and port of destination.

Figure 15 – Creating Network rule to allow traffic on port 53 (DNS) towards a specific DNS Server

Conclusions

The availability of a fully integrated firewall in the Azure fabric is certainly an important advantage that helps to enrich the capabilities provided natively by Azure. At the time are configurable basic operations, but the feature set is definitely destined to get rich quickly. Please note that this service is currently in preview, and no service level agreement is guaranteed and is not recommended to use it in production environments.

Azure Application Gateway: monitoring with Log Analytics

Azure Application Gateway is an application load balancer (OSI layer 7) for web traffic, available in Azure environment, that manages HTTP and HTTPS traffic of the applications. This article is discussed how to monitor of Azure Application Gateway using Log Analytics provides.

Figure 1 - Azure Application Gateway basic schema

Using the Azure Application Gateway you can take advantage of the following features:

  • URL-based routing
  • Redirection
  • Multiple-site hosting
  • Session affinity
  • Secure Sockets Layer (SSL) termination
  • Web application firewall (WAF)
  • Native support for WebSocket and HTTP/2 protocols

For more details on Azure Application Gateway can be found in the Microsoft's official documentation.

Configuring Diagnostics logs for the Application Gateway

The Azure Application Gateway can send diagnostic logs to a workspace of Log Analytics . This feature is very useful for checking the performance, to detect any errors and is essential for troubleshooting steps, in particular in the presence of the WAF module. To enable the diagnostic from the Azure portal you can select the Application Gateway resource and go to the "Diagnostics logs":

Figure 2 – Starting configuration of Diagnostics logs

Figure 3 – Configuring Diagnostics logs

After choosing your Log Analytics workspace where to send diagnostics data, in the Log section, you can select which type of log collecting among the following:

  • Access log (ApplicationGatewayAccessLog)
  • Performance log (ApplicationGatewayPerformanceLog)
  • Firewall log (ApplicationGatewayFirewallLog): these logs are generated only if the Web Application Firewall is configured on the Application Gateway.

In addition to these logs are also collected by default Activity Log generated by Azure. These logs are maintained for 90 days in the store of the Azure event logs. For more details you can refer this specific document.

Azure Application Gateway analytics solution of Log Analytics

Microsoft offers the solution Azure Application Gateway analytics that can be added to the workspace of Log Analytics by following these simple steps:

Figure 4 - Launching the procedure of adding the solution to the OMS workspace

Figure 5 – Selection of the Azure Application Gateway analytics solution

Figure 6 - Addition of the solution in the selected workspace

After enabling the sending of diagnostics logs into the workspace of Log Analytics and adding the solution to the same, by selecting the tile Azure Application Gateway analytics in the Overview page, you can see an overview of the collected log data from the Application Gateway:

Figure 7 – Screen overview of the Azure Application Gateway analytics solution

You can also view the details for the following categories.

  • 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

Figure 8 - Screenshot of the Application Gateway Access logs

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

Figure 9 – Screenshot of the Application Gateway performance

Customized dashboard of Log Analytics for the Application Gateway monitor

In addition to this solution can also be convenient to use a special dashboard of Log Analytics, specifically for the monitoring of the Application Gateway, available at this link. The deployment of the dashboard is via ARM template and requires also in this case the Diagnostics logs of the Application Gateway enabled, as described above. The various queries of Log Analytics, used by the dashboard, are documented in this blog. Thanks to these queries the dashboard shows several additional information exposed by the diagnostic of the Application Gateway.

Figure 10 – Custom dashboard of Log Analytics for Application Gateway monitoring

Query of Log Analytics to monitor the Firewall Log

Using the solution Azure Application Gateway analytics of Log Analytics or the custom dashboard (stated in the previous paragraph) are not contemplated at the time the Firewall log, generated when is active the Web Application Firewall (WAF) on the Application Gateway. The WAF is based on rules of OWASP Core Rule Set 3.0 or 2.2.9 to intercept attacks, for the web applications, that exploit the known vulnerabilities. To name a few, we find for example the SQL injection and attacks cross site scripting.

In this case, if you decide to check the Firewall log, you must directly query the Log Analytics, for example:

Figure 11 – The Query to retrieve blocked requests by the WAF module, over the past 7 days, for a specific URI, divided by RuleID

To see the list of rules of the WAF, by associating the RuleId to its description, you can consult this document.

The descriptive message of the rule is also listed within the results returned by the query:

Figure 12 – The Query to retrieve blocked requests by the WAF module, over the past 7 days, for a specific URI and for a specific RuleId

Conclusions

In my experience, in Azure architectures that require secure publishing of web services to Internet, is often used Azure Application Gateway service with the WAF module active. With the ability to send diagnostic logs of this component to Log Analytics you have the option of having a qualified monitor, that is fundamental to analyse any error conditions and to assess the state of the component in all its facets.

Microsoft Azure: network monitoring solutions overview

Microsoft Azure provides several solutions that allow you to monitor network resources, not only for cloud environments, but even in the presence of hybrid architectures. That are cloud-based features, to check the health of your network and connectivity to your applications. In addition, they give detailed information about network performance. This article will be made an overview of the various solutions such as the main features, needed to orient the use of the network monitor tools most appropriate for your needs.

Network Performance Monitor (NPM) is a suite that includes the following solutions:

  • Performance Monitor
  • ExpressRoute Monitor
  • Service Endpoint Monitor

In addition to the tools included in the Network Performance Monitor (NPM) you can use Traffic Analytics and DNS Analytics.

Performance Monitor

The most commonly used approach is to have hybrid environments with heterogeneous networking, that allows you to connect your own on-premises infrastructure with the environment implemented in the public cloud. In some cases you may also have different cloud providers, that make the network infrastructure even more complicated . These scenarios require the use of flexible monitor tools that can work across on-premises, in cloud (IaaS), and in hybrid environments. Performance Monitor has all of these characteristics and thanks to the use of synthetic transactions, provides the ability to monitor, almost in real time, the network parameters to get performance information, like packet loss and latency. In addition, this solution allows to easily locate the source of a problem in a specific network segment or identifying a particular device. The solution requires the presence of the OMS agent and keeping track of the retransmission packets and the roundtrip time, it is able to return a graph of easy and immediate interpretation.

Figure 1 - Hop-by-hop chart provided by Performance Monitor

Where to install the agents

The installation of the agent of Operations Management Suite (OMS) is necessary on at least one node connected to each subnet from which it intends to monitor the connectivity to other subnets. If you plan to monitor a specific network link you must install agents on both endpoints of the link. In cases where you do not know the exact network topology, one possible approach is to install agents on all servers that hold critical workloads and for which you need to monitor your network performance.

The Cost of the Solution

The cost of the feature Performance Monitor in NPM is calculated on the basis of the combination of these two elements:

  • Monitored Subnet link. To obtain the costs for monitoring of a single subnet link for one month, you can see Ping Mesh.
  • Data volume.

For more details please visit the Microsoft's official page.

ExpressRoute Monitor

Using ExpressRoute Monitor it is possible to monitor the end-to-end connectivity and verify the performance between on-premises environment and Azure, in the presence of ExpressRoute connectivity with Azure Private peering and Microsoft peering connections. The key features of this solution are:

  • Auto-detection of the circuit ExpressRoute associated with your subscription Azure.
  • Detection of network topology.
  • Capacity planning and bandwidth usage analysis.
  • Monitoring and alerting both the primary and the secondary path of the circuit ExpressRoute.
  • Monitoring connectivity towards the Azure services such as Office 365, Dynamics 365 using ExpressRoute as connectivity.
  • Detection of possible deterioration of connectivity with the various virtual network.

Figure 2 – Topology view of a VM on Azure (left) connected to a VM on-prem (right), via ExpressRoute

Figure 3 - Trend on the use of the bandwidth and latency on the ExpressRoute circuit

Where to install the agents

In order to use ExpressRoute Monitor you need to install an Operations Management Suite agent on a system that resides on Azure virtual network and at least one agent on a machine attested on the subnet on-premises, connected via private peering of ExpressRoute.

The Cost of the Solution

The cost of ExpressRoute Monitor solution is calculated based on the volume of data generated during the monitoring operations. For more details please visit the specific section in the cost page of NPM .

Service Endpoint Monitor

Using this solution, you have the ability to monitor and test the reachability of your services and your applications, almost in real time, simulating user access. You also have the ability to detect network side performance problems and identify the problematic network segment.

Here are reported the main features of the solution:

  • It does the monitor end-to-end of the network connections to your applications. The monitor can be done by any endpoint "TCP-capable" (HTTP, HTTPS, TCP, and ICMP), as websites, SaaS applications, PaaS applications, and SQL databases.
  • It correlates application availability with network performance, to precisely locate the degradation point on the network, starting from the user's request until the application.
  • It tests applications reachability from different geographical location .
  • It determines the network latencies and lost packets to reach the applications.
  • It detects hot spots on the network that can cause performance problems.
  • It does the monitor of the availability of applications Office 365, through specific built-in test for Microsoft Office 365, Dynamics 365, Skype for Business and other Microsoft services.

Figure 4 - Creating of a Service Connectivity Monitor test

Figure 5 – Diagram showing the topology of the network, generated by different nodes, for a Service Endpoint

Where to install the agents

To use Service Endpoint Monitor you must install the Operations Management Suite agent on each node where you want to monitor network connectivity to a specific service endpoint.

The Cost of the Solution

The cost for using Service Endpoint Monitor is based on these two items:

  • Number of connections, where the connection is understood as reachability test of a single endpoint, from a single agent, for the entire month. In this regard you can see Connection Monitoring in the cost page.
  • Volume of data generated by the monitor. The cost is obtained from cost page of Log Analytics, in the section Data Ingestion.

Traffic Analytics

Traffic Analytics is a totally cloud-based solution, allowing you to have an overall visibility on network activities that are undertaken in the cloud environment. In Azure to allow or deny network communication to the resources connected with Azure Virtual Networks (vNet) it uses the Network Security Group (NSG), containing a list of access rules. The NSGs are applied to network interfaces connected to the virtual machines, or directly to the subnet. The platform uses NSG flow logs to maintain the visibility of inbound and outbound network traffic from the Network Security Group. Traffic Analytics is based on the analysis of NSG flow logs and after an appropriate aggregation of data, inserting the necessary intelligence concerning security, topology and geographic map, can provide detailed information about the network traffic of your Azure cloud environment.

Using Traffic Analytics you can do the following:

  • View network activities cross Azure subscriptions and identify hotspots.
  • Intercept potential network security threats, in order to take the right remedial actions. This is made possible thanks to the information provided by the solution: which ports are open, what applications attempt to access to Internet and which virtual machines connect to unauthorized networks.
  • Understand network flows between different Azure regions and Internet, in order to optimize their deployment for network performance and capacity.
  • Identify incorrect network configurations that lead to having incorrect communication attempts.
  • Analysis of the VPN gateway capabilities or other services, to detect problems caused by over-provisioning and underutilization.

Figure 6 – Traffic Analytics overview

Figure 7 - Map of Active Azure Regions on the subscription

DNS Analytics

DNS Analytics solution is able to collect, analyze and correlate logs of DNS and provides administrators the following features:

  • Identifies clients that try to resolve domains considered malevolent.
  • Finds records that belong to obsolete resources.
  • It highlights domain names frequently questioned.
  • View the load of requests received by the DNS server.
  • It does the monitor of dynamic DNS registrations failed.

Figure 8 – Overview of DNS Analytics solution

Where to install the agents

The solution requires the presence of the OMS agent or the Operations Manager agent installed on each DNS server to be monitored.

Conclusions

With increasing complexity of network architectures in hybrid environments, consequently increases the need to be able to use tools able to contemplate different network topologies. Azure provides several cloud based tools and integrated into the fabric, such as those described in this article, that allow you to fully and effectively monitor the networking of these environments. Remember to test and evaluate free Operations Management Suite (OMS) you can access this page and select the mode that is most appropriate for your needs.

Everything you need to know about new Azure Load Balancer

Microsoft recently announced the availability in Azure of Standard Load Balancer. They are load balancers Layer-4, for TCP and UDP protocols that, compared to Basic Load Balancer, introduce improvements and give you more granular control of certain features. This article describes the main features of the Standard Azure Load balancers, in order to have the necessary elements to choose the most suitable type of balancer for your needs.

Any scenario where you can use the SKU Basic of Azure Load balancers, can be satisfied using the Standard SKU, but the two types of load balancers have important differences in terms of scalability, functionality, guaranteed service levels and cost.

Scalability

The Standard Load balancers have higher scalability, compared to Basic Load Balancer, as regards the maximum number of instances (IP Configuration) that can be configured in the backend pool. The SKU Basic allows you to have up to 100 instances, while using the Standard SKU the maximum number of instances is equal to 1000.

Functionality

Backend pool

With regard to the Basic Load Balancer, in the backend pool, can reside exclusively:

  • Virtual machines that are located within an availability set.
  • A single standalone VM.
  • Virtual Machine Scale Set.

Figure 1 – Possible associations in the Basic Load Balancer backend pool

In Standard Load Balancer instead, it is allowed to enter into backend pool any virtual machine attested on a particular virtual network. The integration scope, in this case, is not in fact the availability set, as for the Basic load balancer , but it is the virtual network and all its associated concepts. A requirement to consider, in order to insert into the backend pool of Standard Load Balancer the virtual machines, is that these should not have associated public IP or must have Public IP with Standard SKU.

Figure 2 Standard Load Balancer backend pool association

Availability Zones

Standard Load Balancers provide integration scenarios with Availability Zones, in the regions that include this feature. For more details you can refer this specific Microsoft document, that shows the main concepts and implementation guide lines.

Ports High Availability

The load balancers with Standard SKU, of type "Internal", allow you to balance the TCP and UDP flows on all ports simultaneously. To do that, in the rule of load-balancing, there is the possibility to enable the "HA Ports" option:

Figure 3 - Configuring the load balancing rule with "HA Ports" option enabled

The balancing is done for flow, which is determined by the following elements: source IP address, source port, destination IP address, destination port, and protocol. This is particularly useful in scenarios where are used Network Virtual Appliances (NVAs) requiring scalability. This new feature improves the tasks that are required for NVAs implementations.

Figure 4 - Network architecture which provides the use of LB with "HA Ports" option enabled

Another possible use for this feature is when you need to balance a large number of ports.

For more details on the option "HA Ports" you can see the official documentation.

Diagnostics

Standard Load Balancer introduce the following features in terms of diagnostic capability:

  • Multi-dimensional metrics: You can retrieve various metrics that allow you to see, in real time, usage status of load balancer, internal and public. This information is particularly useful for troubleshooting.

Figure 5 – Load Balancer metrics from the Azure Portal

  • Resource Health: in Azure Monitor you have the opportunity to consult the health status of Standard Load Balancer (currently only available for Standard Load Balancer, type Public).

Figure 6 – Resource health of Load Balancer in Azure Monitor

You can also consult the history of the health state :

Figure 7 – Health history of Load Balancer

All details related to diagnostics, of the Standard Load Balancer, can be found in the official documentation.

Security

The Load Balancer with standard SKU are configured to be secure by default in fact, in order to operate, you must have a Network Security Group (NSG) where the traffic flow is explicitly allowed. As previously reported, the Load Balancer standards are fully integrated into the virtual network, which is characterized by the fact that it is private and therefore closed. The Standard Load Balancer and the public Standard IP are used to allow the access to the virtual network from outside and now by default you must configure a Network Security Group (closed by default) to allow the desired traffic. If there is no a NSG, on the subnet or on the NIC of the virtual machine, you will not be allowed the access by the network stream from the Standard Load Balancer.

The Basic Load Balancers by default are opened and the configuration of a Network Security Group is optional.

Outbound connections

The Load Balancer on Azure support both inbound and outbound connectivity scenarios. The Standard Load Balancer, compared to the Load Balancer Basic, behave differently with regard to outbound connections.

To map the internal and private IP address of the virtual network to the public IP address of the Load Balancer it uses the Source Network Address Translation technique (SNAT). The Load Balancer Standard introduce a new algorithm to have stronger SNAT policies, scalable and accurate, that allow you to have more flexibility and have new features.

Using the Standard Load Balancer you should consider the following aspects with regard to outbound scenarios:

  • Must be explicitly created to allow outgoing connectivity to virtual machines and are defined on the basis of incoming balancing rules.
  • Balancing rules define how occur the SNAT policies.
  • If there are multiple frontend, It uses all the frontend and for each of these multiply the preallocated SNAT ports available.
  • You have the option to choose and control whether a specific frontend you don't want to use for outbound connections.

Basic Load Balancers, in the presence of more public frontend IP, it is selected a single frontend to be used in outgoing flows. This selection can not be configured and occurs randomly.

To designate a specific IP address, you can follow the steps in this section of the Microsoft documentation.

Management operations

Standard Load balancers allow enabling management operations more quickly, much to bring the execution times of these operations under 30 seconds (against the 60-90 seconds to the Load Balancer with Basic SKU). Editing time for the backend pools are also dependent on the size of the same.

Other differences

At the moment, Public Standard Load Balancer cannot be configured with a public IPv6 address:

Figure 8 – Public IPv6 for Public Load Balancer

Service-Level Agreements (SLA)

An important aspect to consider, in choosing the most appropriate SKU for different architectures, is the level of service that you have to ensure (SLA). Using the Standard Load Balancer ensures that a Load Balancer Endpoint, that serve two or more instances of health virtual machines, will be available in time with an SLA of 99.99%.

The Load Balancer Basic does not guarantee this SLA.

For more details you can refer to the specific article SLA for Load Balancer.

 

Cost

As for Basic Load Balancer are not expected cost, for Standard Load Balancer there are usage charge provided on the basis of the following elements:

  • Number of load balancing rules configured.
  • Number of inbound and outbound data processed.

There are no specific costs for NAT rules.

In the Load Balancer cost page can be found the details.

 

Migration between SKUs

For Load Balancer is not expected to move from the Basic SKU to the Standard SKU and vice versa. But it is necessary to provide a side-by-side migration, taking into consideration the previously described functional differences.

Conclusions

The introduction of the Azure Standard Load Balancer allows you to have new features and provide greater scalability. These characteristics may help you avoid having to use, in specific scenarios, balancing solutions offered by third party vendors. Compared to traditional Load balancers (Basic SKU) change operating principles and have distinct characteristics in terms of costs and SLAS, this is good to consider in order to choose the most suitable type of Load Balancer, on the basis of the architecture that you must accomplish.

How to monitor network activities in Azure with Traffic Analytics

Worldwide cloud networks have substantial differences compared to those in the on-premises, but they are united by the need to be constantly monitored, managed and analyzed. All this is important for to know them better, in order to protect them and optimize them. Microsoft introduced in Azure the solution called Traffic Analytics, fully cloud-based, allowing you to have an overall visibility on network activities that are undertaken in the cloud environment. This article analyzes the characteristics of the solution and explains how you can turn it.

Operating principles of the solution

In Azure to allow or deny network communication to the resources connected with Azure Virtual Networks (vNet) it uses the Network Security Group (NSG), containing a list of access rules. The NSGs are applied to network interfaces connected to the virtual machines, or directly to the subnet. The platform uses NSG flow logs to maintain the visibility of inbound and outbound network traffic from the Network Security Group. Traffic Analytics is based on the analysis of NSG flow logs and after an appropriate aggregation of data, inserting the necessary intelligence concerning security, topology and geographic map, can provide detailed information about the network traffic of your Azure cloud environment.

Figure 1 – Data flow of Traffic Analytics

Solution functionality

Using Traffic Analytics you can do the following:

  • View network activities cross Azure subscriptions and identify hotspots.
  • Intercept potential network security threats, in order to take the right remedial actions. This is made possible thanks to the information provided by the solution: which ports are open, what applications attempt to access to Internet and which virtual machines connect to unauthorized networks.
  • Understand network flows between different Azure regions and Internet, in order to optimize their deployment for network performance and capacity.
  • Identify incorrect network configurations that lead to having incorrect communication attempts.

How to enable the solution

In order to analyze the network traffic you must have a Network Watcher in every region where there are the NSGs for which you intend to analyze traffic. The Network Watcher is a regional service, which makes it possible to monitor and diagnose the networking of Azure. Enabling Network Watcher can be made by Azure Portal, using Powershell or via REST API. By creating it from the portal it is not possible to determine the name of the Network Watcher and its Resource Group, but is assigned a default name in both entities.

Figure 2 – Enabling Network Watcher from the portal

Figure 3 – Enabling Network Watcher using PowerShell

As this is a preview service in order to use it you need to redo the registration of the network resource provider on the Azure subscription interested. You must also register the provider Azure Insights.

Figure 4 - Registration of the providers through PowerShell

In order to enable the collection of NSG Flow Logs you must have a storage account on which to store them. You must also have a workspace OMS Log Analytics on which Traffic Analytics will consolidate the aggregated and indexed data. The information present in Log Analytics will then be used to generate the analysis.

First configuration step of the NSG flow logs settings:

Figure 5 - Selection of the NSGs on which enable the collection of flow logs

Choice of storage account and workspace OMS Log Analytics for each NSGs:

Figure 6 – Enabling the collection of NSG flow logs and consolidation in OMS Log Analytics

The steps above must be repeated for each NSG for which you want to enable Traffic Analytics.

Figure 7 – List of NSGs with settings enabled

Within a few minutes from enabling, time necessary to obtain a quantity of sufficiently indicative aggregated data, its dashboard is populated with the information of Traffic Analytics.

Figure 8 – Traffic Analytics Dashboard

From the dashboard of Traffic Analytics information is readily available such as: hosts with a high level of communication, the most widely used application protocols, the communications that occur more frequently and the flows relating to network traffic in the cloud.

Selecting the section of interest is shown the query of Log Analytics that extrapolates the data:

Figure 9 - Sample query of Log Analytics showing the allowed malicious traffic

For a complete overview of the possible scenarios for using Traffic Analytics you can see this Microsoft's document.

Conclusions

Traffic Analytics is a new feature, currently in preview, introduced in Azure. It is an effective and easy-to-use tool that helps you keep track of the status of your network in Azure reporting very useful data, as who and where are connected, which ports are exposed to the internet, which network traffic is generated and more. This information is critical for detecting anomalies and make appropriate corrective actions. All operations that are difficult to achieve without this fully integrated tool in the platform.

OMS and System Center: What's New in November 2017

In November there have been several announcements from Microsoft concerning Operations Management Suite (OMS) and System Center. This article will summarize briefly with the necessary references to be able to conduct further studies.

Operations Management Suite (OMS)

Log Analytics

As already announced since 30 October 2017 Microsoft has launched the upgrade process of the OMS workspaces not yet updated manually. In this regard has been released this useful document that shows the differences between a legacy OMS workspace and a updated OMS workspace, with references for further details.

Solutions

Those that use circuit ExpressRoute will be glad to know that Microsoft announced the ability to monitor it through Network Performance Monitor (NPM). This is a feature currently in preview that allows you to monitor connectivity and performance between the on-premises environment and vNet in Azure in the presence of ExpressRoute circuit. For more details about the features announced you can consult theofficial article.

Figure 1 – Network map showing details of ExpressRoute connectivity

Agent

As usual it was released a new version of the OMS Agent for Linux systems that now takes place on a monthly basis. This release fixes bugs related diagnostics during agents onboarding. Are not being introduced new features. To obtain the updated version please visit the official GitHub page OMS Agent for Linux Patch v 1.4.2-124.

Protection and Disaster Recovery

Azure Backup always protected backups from on-premises world toward Azure using encryption that takes place using the passphrase defined during the configuration of the solution. To protect VMs in Azure the recommendation for greater security in the backup was to use VMs with disk-encrypted. Now Azure Backup uses Storage Service Encryption (SSE) to do the encryption of backups of virtual machines on Azure, allowing to obtain in an integrated manner in the solution a mechanism for the implementation of the backup security. This also will happen to existing backup automatically and through a background task.

Microsoft, in order to bring more clarity with regard to pricing and licensing of Azure Site Recovery, updated the FAQ which you can see in the official page of pricing of the solution.

System Center

As is already the case for the operating system and System Center Configuration Manager, the other System Center products, in particular, Operations Manager, Virtual Machine Manager, and Data Protection Manager will follow a release of updated versions every 6 months (semi-annual channel). The goal is to rapidly deliver new capabilities and to ensure a speedy integration with the cloud world, which is essential given the speed with which it evolves. In November was announced the System Center preview version 1711 which you can download at this link.

Figure 2 – Summary of what's new in System Center preview version 1711

To know the details of the new features in this release, please consult theofficial announcement.

System Center Configuration Manager

For System Center Configuration Manager current branch version 1706 was issued an important update rollup you should apply as it solves a lot of problems.

Released the version 1710 for the Current Branch (CB) of System Center Configuration Manager that introduces new features and major improvements in the product. Among the main innovations of this update definitely emerge the possibilities offered by the Co-management that expand the possibilities for device management using either System Center Configuration Manager and Microsoft Intune.

Figure 3 – Features and benefits of Co-management

For a complete list of new features introduced in this version of Configuration Manager, you can consult theofficial announcement.

Released the version 1711 for the Technical Preview branch of System Center Configuration Manager. The new features in this update are:

  • Improvements in the new Run Task Sequence step.
  • User interaction when installing applications in the System context even when running a task sequence.
  • New options, in the scenario of using Configuration Manager associated with Microsoft Intune, to manage compliance policy for devices Windows 10 related to Firewall, User Account Control, Windows Defender Antivirus, and OS build versioning.

I remind you that the releases in the Technical Preview Branch allows you to evaluate in preview new SCCM functionality and is recommended to apply these updates only in test environments.

Released an updated version of the Configuration Manager Client Messaging SDK.

System Center Operations Manager

Released the new wave of the SQL Server Management Packs (version 7.0.0.0):

The Management Packs for SQL Server 2017 can be used for the monitor of SQL Server 2017 and subsequent releases (version agnostic), this allows you to avoid having to manage different MPs for each version of SQL Server. The controls for versions of SQL Server earlier than 2014 are included in the generic MP "Microsoft System Center Management Pack for SQL Server".

System Center Service Manager

Microsoft has published a series of tips and best practices to be followed during Authoring Management Pack of System Center Service Manager (SCSM).

Please remember that in order to test and evaluate for free Operations Management Suite (OMS) you can access this page and select the mode that is most appropriate for your needs.

OMS and System Center: What's New in August 2017

This article summarizes the main new features and includes upgrades, concerning Operations Management Suite (OMS) and System Center, that were announced during the month of August.

Operations Management Suite (OMS)

Log Analytics

  • For Log Analytics was published what may be called the most significant upgrade from the date of issue. Among the main changes introduced by this update there is a new powerful query language, the introduction of the new Advanced Analytics portal and greater integration with Power BI. For more details, I invite you to consult the specific article Log Analytics: a major update evolves the solution.

Figure 1 – Upgrade of Log Analytics

Agent

  • The agent who for Linux systems is constantly evolving and we released a new version that has fixed some bugs and improved error handling during onboarding of agent for easier troubleshooting: OMS Agent for Linux GA v 1.4.0-45

Figure 2 – Bug fixes and what's new for the OMS agent for Linux

Solutions

  • The OMS solution Network Performance Monitor has been improved and enhanced with the following new features:
    • The diagnostic agent: the solution now provides the ability to monitor in a specific view the health status of various agents deployed on the network and in case of problems NPM reports useful diagnostic information for troubleshooting.
    • Hop-by-hop latency breakdown: the topology map of the network has been enriched with details of timings found between two specific points.
    • Availability on the Azure Portal: as well as continuing to be available from OMS can be added from the Marketplace Azure and used directly by the Azure Portal.
    • Presence in additional region of Azure: the solution is now also available for the region Azure West Central US.

For more details see the announcement Improvements to the who Network Performance Monitor.

  • The emerging technology is becoming more widespread and monitor containers Docker becomes an essential component. For this reason the OMS team announced the availability of the new solution Container Monitoring that allows you to:
    • Display in a unique location information for all hosts container.
    • Learn which containers are running, where I am and with which image.
    • See audit information concerning action taken on container.
    • View and search logs for troubleshooting without needing access to hosts Docker.
    • Locate the containers that are consuming an excessive amount of resources on the host.
    • Display performance information centrally about the container about CPU usage, of memory, storage and network.

Figure 3 – Synthesis pathway of solution Container Monitoring

Full details on the solution Container Monitoring you can consult them in the document Container Monitoring solution in Log Analytics.

  • Released in preview the new solution for the monitoring of Azure Logic Apps. The solution displays various information about the status of logic app and then drill down to see details useful for troubleshooting. All aspects of this solution you can consult them in Microsoft's official documentation.

Security and Audit

  • The baseline assessment of OMS Security is enhanced with functionality Web security baseline assessment that was announced in public preview and lets you scan the web server with Internet Information Services (IIS) to check for security vulnerabilities and provides useful recommendations regarding the correct environment setup. The document Baseline Assessment in Operations Management Suite Web Security and Audit Solution shows additional information about.

Figure 4 – Assessment dashboard of Web security baseline

 

System Center

System Center Configuration Manager

  • Last month it was released version 1706 for the Current Branch (CB) System Center Configuration Manager as described in the article OMS and System Center: What's New in July 2017. In date 8 August was released a package update to correct some errors that were encountered during the first deployment, but this package introduced problems therefore on 11 August has been replaced with a new version. For those who have updated SCCM to version 1706 between August 8 and August 11 you need to install an additional update as documented in Microsoft knowledge base article Update for System Center Configuration Manager version 1706, first wave. This update can be installed by accessing the node "Updates and Servicing" of the SCCM console. A further update will be released in the coming week to who made the SCCM update to version 1706 prior to August 8.
  • Released version 1708 for the branch Technical Preview of System Center Configuration Manager: Update 1708 for Configuration Manager Technical Preview Branch – Available Now!. I remind you that the releases in the Technical Preview Branch allows you to evaluate in preview new SCCM functionality and is recommended to apply these updates only in test environments.

System Center Operations Manager

Following the news about the SCOM Management Pack 2016:

  • Advanced Threat Analytics 1.7 Management Pack version 1.7.1.1.
  • Service Map Management Pack in public preview: Thanks to this new MP you can integrate maps are created dynamically by the OMS Service solution Map with diagrams of the Distributed Application in Operations Manager to ensure that the latter are dynamically generated and maintained.

For more information I invite you to consult related documentation available online.

Figure 5 – Integration of the Service Map of who and the SCOM Distributed App

  • Available a hotfix to solve some problems related to the WMI monitor health.

How to connect third-party security solutions at OMS

Between the various features of Operations Management Suite (OMS) There is a possibility to collect events generated in standard form Common Event Format (CEF) and events generated by Cisco ASA devices. Many vendors of security solutions generate events and log files matching the syntax defined in the standard CEF for interoperability with other solutions. Configuring the sending of data in this format to who and adopting the solution OMS Security and Audit You can correlate the different information collected, leverage the powerful search engine of OMS to monitor your infrastructure, retrieve audit information, detect problems and use Threat Intelligence.

This article will be fleshed out the necessary steps to integrate the logs generated by Cisco Adaptive Security Appliance (ASA) within the who. Before you can configure this integration you must have a Linux machine with installed agent OMS (version 1.2.0-25 or later) and configure it to forward the logs are received by the who to the workspace. For installation and onboard Linux agent I refer you to the official Microsoft documentation: Steps to install the OMS Agent for Linux.

Figure 1 – Architecture for collecting logs from Cisco ASA in OMS

Cisco ASA apparatus must be configured to forward events to the Linux machine defined as collector. To do this you can use Cisco ASA device management tools such as Cisco Adaptive Security Device Manager:

Figure 2 – Syslog Server configuration example Cisco ASA

On the Linux machine must be running the syslog daemon will send events to UDP port 25226 local. The agent who is listening on this port for all incoming events.

For this configuration, you must create the file Security-config-omsagent. conf respecting the following specifications depending on the type of Syslog running on Linux machine. For example, a sample configuration to send all events with facility local4 the agent who is as follows:

  • If daemon rsyslog the file must be present in the directory /etc/d/rsyslog. with the following content:
#OMS_facility = local4

local4.* @ 127.0.0.1:25226
  • If daemon syslog-ng the file must be present in the directory /etc/syslog-ng/ with the following content:
#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); };  

The next step is the creation of the configuration file Fluentd named security_events. conf that lets you collect and make parsing of events received by the agent who. The file you can download it from GitHub repository and must be copied into the directory /etc/opt/microsoft/omsagent/<workspace id>/conf/d/omsagent..

Figure 3 – Configuration file Fluentd the agent OMS

At this point, to make the changes, You must restart the syslog daemon and agent who through the following commands:

  • Restarting Syslog daemon:
sudo service rsyslog restart or sudo/etc/init.d/syslog-ng restart
  • Restart agent OMS:
sudo/opt/microsoft/omsagent/bin/service_control restart

Complete these steps the agent who should view the log to see if there are any errors using the command:

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

After finishing the configuration from the who portal you can type in the query Log Search Type = CommonSecurityLog to analyze data collected from the Cisco ASA:

Figure 4 – Query to see Cisco ASA events collected at OMS

Log collection is enriched by Threat Intelligence present in solution Security & Compliance Thanks to an almost real-time correlation of data collected in the repository OMS with information from leading vendor of Threat Intelligence and with the data provided by the Microsoft security centers allows you to identify the nature and results of any attacks involving our systems, including the network equipment.

By accessing the solution Security And Audit from the OMS section appears Threat Intelligence:

Figure 5 – Information of Threat Intelligence

By selecting the tile Detected threat types You can see details about intrusion attempts that in the following case involving the Cisco ASA:

Figure 5 – Detected threat on Cisco ASA

In this article you entered the configuration details of Cisco ASA, but similar configurations you can make them for all solutions that support the generation of events in standard form Common Event Format (CEF). To configure the integration of Check Point Securtiy Gateway with who I refer you to the document Configuring your Check Point Security Gateways to send logs to Microsoft OMS.

Conclusions

Using Operations Management Suite there is a chance to consolidate and to correlate events from different products that provide security solutions allowing you to have a complete overview of your infrastructure and respond quickly and accurately to any incident of security.