Except if you lived in a cave or a desert island for more than 2 months, you should have eared about Log4J vulnerabilities, Log4Shell. In short, it's a zero-day vulnerability found in the Java logging framework, Log4J.
The primary cause is the lack of input validation allowing to execution of arbitrary Java code.
An attacker can use this vulnerability, to destroy your servers, evade sensitive data, use your workload as bots, or use your VMs as crypto miners, it can encrypt your data (against a ransom) or install a backdoor for later exploitation…
one of the best approaches you can use here is to assume you are compromised, before waiting to have any proof of this.
How can you prevent, mitigate, and recover from attacks in Azure?
Inventory
The first action to prevent attacks is to know what is deployed on your servers, all applications, software, components, and their version.
It could be directly during the deployment phase where everything. But Azure could also help.
You can use Change Tracking and inventory in Azure Automation to track Windows software and Linux Package. You can also track file changes.
Change tracking and inventory can help to detect affected software but also unwanted change in your VMs. Change tracking.
A more powerful option is to use a vulnerability management solution. Vulnerability management can scan a VM to detect software and components with security vulnerabilities .
Azure includes a vulnerability management solution in Microsoft Defender for Cloud. This solution is based on Qualys and it can help you to detect Log4J installation and other 0-days vulnerabilities. Microsoft Defender for Cloud.
Visibility
Another helpful solution is IaaS monitoring. It will not help to detect any installation of Log4J but it may not help to detect some potential attacks in your VMs. But an increase in the CPU usage of a VM can indicate the presence of a crypto miner while connections to an unknown internet host can indicate the presence of a command and control tool inside a VM.
Application log collection can also help to detect attacks.
Enabling log and metrics collection is essential for workload, Azure Monitor and Azure network
Network
Detection and visibility is the first step, but the time between the detection of a vulnerability, the availability of an update, and the correction of VMs and applications can be too long.
You can prevent and mitigate log4J attacks (and other 0-days related attacks) on the network side. There are several solutions in Azure to achieve that.
NSG is the last defense tool in your Azure network infrastructure. A Network Security Group contains 0 to several network rules to allow or deny traffic based on source, destination, protocol, and port. NSG can be applied on subnet and network interface.
NSG can help to limit and prevent attacks in several ways.
NSG allows you to limit the connection between virtual machines inside and outside its subnet to the strictly necessary, limiting this way the possibility of a compromised VM to access other services, especially when NSG is applied on the VM nic.
Internal communication should be filtrated to prevent lateral movement, but outbound communication should be also limited to what is necessary for applications. Doing so will limit the attacker's opportunities to leak data or go further in the attack.
Finally, flow logs should be activated on all NSG for suspicious behavior inspection and forensic after attack.
The NSG Flow Log is part of the Network Watcher, logs can be analyzed by traffic analytics or sent to other SIEM.
Azure Firewall plays the same role as NSG in protecting your VNET in Azure. But, unlike NSG, Azure firewall is a centralized managed service, working on layers 4 and 7 of the OSI network model. It can filter outbound connections by FQDN and not only by IP or tag like in NSG.
Firewall implementation is more complex than NSG as you will need to implement routing from your VNET to the firewall.
If you choose to use Azure Firewall Premium you will have access to the network intrusion detection and prevention system feature. This is the feature you are looking for to protect you against 0-days based attacks as a new rule can be added by Azure to prevent these kinds of attacks.
Most of the time you are running Internet-facing applications, while NSG and/or firewall help to isolate web applications from other systems they may not be the ultimate tools to protect these applications. With Log4J vulnerabilities, the first targets were web servers, attackers sending GET/POST HTTP requests to any IP to test what they have.
There is a need for a more specialized tool
In Azure, this tool is Azure Web Application Firewall, WAF v2. Azure WAF, is a layer 7 device scanning incoming HTTP/S requests for attacks in POST, GET and PUSH requests. After the discovery of the Log4J vulnerabilities, a new rule was automatically available to mitigate them.
The Azure WAF v2 object lets you create a centralized set of rules that can be deployed in Azure Application Gateway, Azure Front Door, and Azure CDN.
To be sure to protect workloads behind these services, you need to make sure that the WAF policy object is set to prevention mode (detection only log attacks), and when deploy ensure that a storage account is associated with Azure App Gateway or Front Door to collect logs.
Even if, you follow these recommendations, VM scanned, workloads isolation, logging and monitoring, firewall, and WAF in place, you can still be vulnerable. You still need a plan to recover from an attack.
It depends on your situation. If your workloads are not stateful, if they store data needed to operate, you will need to backup them. In Azure, you can use Azure Backup. Azure Backup can be used on Azure VM, SQL Server in Azure VM, File share, and Azure blob.
Databases as Service (Azure SQL Database, Azure Database for MySql, Azure Database for MariaDB, and Azure Database for PostgreSQL) include by default a backup solution, the retention should be aligned to other workload retention.
These recommendations should be taken as a base policy to secure your environment in Azure. It must be adapted and enriched using Security baselines for Azure
Latest comments (0)