Posts

Showing posts from May, 2023

Enabling Microsoft Defender for Cloud via Azure Policy

Image
Azure Policy comes with a variety of built-in policy definitions, one of which is used to enable Microsoft Defender for Cloud on the scope you chose. In order to enable the service on all existing and future subscriptions, it's enough to simply assign the Enable Azure Security Center on your subscription policy to your root management group.  To onboard a management group and all its subscriptions to Defender for Cloud, follow these steps: 1.  Make sure to log in with an account that has Security Admin permissions, open Azure Policy, and search for the Enable Azure Security Center on your subscription policy definition.  Figure 1.1 – Policy definition to enable Defender for Cloud 2.  Select the definition, and then click Assign: Figure 1.2 – Assigning the policy definition 3.  Select Tenant Root Group as the assignment scope. There are no other parameters you need to change.  Figure 1.3 – Assigning the policy definition to your Tenant Root Group 4.  Cl...

Understanding Azure Front Door

Image
 Azure Front Door works very similarly to Application Gateway but on a different level. Like Application Gateway, it's an L-7 load balancer with an SSL offload. The difference is that Application Gateway works with services in a single region, whereas Azure Front Door allows us to define, manage, and monitor routing on a global level. With Azure Front Door, we can ensure the highest availability using global distribution. A similar thing can be achieved with Azure Traffic Manager (in terms of global distribution),  but this service lacks L-7 load balancing and SSL offloading. What Azure Front Door provides actually combines Application Gateway and Traffic Manager to enable an L-7 load balancer with global distribution. It's also important to mention that a WAF is also available on Azure Front Door. Using a WAF on Azure Front Door, we can provide web application protection for globally distributed applications. Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Hub-and-spoke network topology

Image
For large and enterprise organizations, a hybrid cloud can become complex, and hard to manage and secure. With multiple VNets and hybrid cloud implementation, it can become difficult to monitor network traffic or even know the exact traffic flow. For complex network topologies, it is recommended to implement the hub-and-spoke model. In this model, we have a central point (hub) to which all on-premises connections and VNets (spokes) are connected. This way, traffic is easy to monitor, inspect, and manage. There are two possible implementations for the hub-and-spoke topology in Azure. Hub VNet Hub VNet implementation has a single VNet and a central network where everything else is connected: Figure – Hub virtual network All other networks (spokes) are connected to the hub VNet. On-premises networks are connected over VPN Gateway (or ExpressRoute) and VNets are connected with peering. A hub network can come with other network resources, such as Azure Firewall, Azure Bastion, and Azure DDo...

Azure Bastion

Image
When running IaaS, exposing management ports such as RDP (port 3389) or SSH  (port 22) is not a good idea. Bad actors are constantly scanning public networks in  the search for exposed endpoints. If they detect such a port open, they will trigger  a brute-force attack in the hope of gaining access to a service. This is usually mitigated by creating a jump box, a VM that enables us to securely connect to it before connecting to other VMs on the network. Azure Bastion is a service that provides the ability to connect to our VMs using the browser and Azure portal. Similar to a jump box, it provides a secure way to connect  to our virtual network. But unlike a jump box (which we need to maintain and update), Azure Bastion is a fully managed service. With Azure Bastion, we are able to securely access VMs over RDP/SSH from the Azure portal over TLS.  Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Azure DDoS protection

Image
 Distributed Denial of Service (DDoS) is one of the most common cyber attacks. A DDoS attack attempts to overload system resources and make a system unavailable to legitimate users. An attack can target any endpoint that is publicly reachable through the internet.  Azure DDoS protection comes in two different flavors: Basic and Standard.  Every property in Azure is protected by DDoS Basic protection at no additional cost.  To protect customers and prevent impacts on other customers, Basic protection provides defense against network layer attacks with always-on traffic monitoring and real-time mitigation. It requires no additional configuration or any user action; it is a built-in service protecting all Azure services, both IaaS and PaaS. The standard plan provides additional functionalities, including the following: •  Guaranteed availability •  Cost protection •  Custom mitigation policies •  Metrics and alerts •  Mitigation reports and flow...

Connecting on-premises networks with Azure

In most cases, we already have some sort of local infrastructure and want to use the cloud as a hybrid where we combine cloud and on-premises resources. In such cases, we need to think about how we are going to access VNet from our local network. There are three options available: • Point-to-Site connection (P2S) is usually used for management and/or end use connections. It enables you to create a connection from a single on-premises computer to Azure VNet. It has a secure connection, but not the most persistent one, and shouldn't be used for production purposes, only to perform management and maintenance tasks, or to access applications. •  Site-to-Site connection (S2S) is a persistent connection that enables a network-to- network connection. In this case, that would be from an on-premises network to  a VNet, where all on-premises devices can connect to Azure resources and vice versa. Using S2S enables you to expend local infrastructure to Azure, use a hybrid cloud, and take ...

Introducing security defaults

Image
Security defaults are a rather new capability that will enforce basic identity security mechanisms across an Azure AD. These capabilities will ensure that user and administrator accounts are better protected from common identity-related attacks, such as brute force, or password spray. Security defaults are enabled by default on new Azure AD enrollments but might need to be manually enabled on existing ones. To manage security defaults, navigate to Azure Active Directory and click the Properties option in the left navigation pane. Then, click the Manage Security defaults link and switch the Enable Security defaults setting to Yes , as shown in Figure 1.1: Figure 1.1 – Enable Security defaults Security defaults will require all users and administrators to use MFA and block legacy authentication protocols. Once security defaults have been enabled, users will be asked to proceed through the MFA procedure you already know from the previous section.  However, the first screen that users ...

MFA activation from a user's perspective

Image
After enforcing MFA for Cracky, a new window will appear after his next successful login, telling him that his organization needs more information to protect his account, as shown in Figure 1.1: Figure 1.1 – New message at the first login after enforcing MFA Cracky now only has two options: Use a different account to log in or click Next to proceed through the MFA activation process. With that being said, you should inform your users before activating MFA to let them know what's going to happen and to reduce the number of support tickets required! Let's look at what happens if Cracky decides to complete the process: 1. Cracky decides to proceed, so he clicks the Next button. 2. On the following screen, Cracky is asked to download the Microsoft Authenticator app to his smartphone. Once finished, he clicks Next. Figure 1.2 – Downloading the Microsoft Authenticator app 3. The next screen gives Cracky a short intro into what's coming, and he presses Next again. Figure 1.3 – Kee...