Updated December 21, 2021.
The Apache Log4j vulnerability (CVE-2021-44228) has taken the Internet by storm in the past few days. This blog details quick ways Secure Firewall Threat Defense (FTD) and Secure IPS users can mitigate risk against attacks leveraging this vulnerability while patching their infrastructure. The main focus of this blog is to remind us that there are features – such as Correlation Rules – available in addition to Snort deep packet inspection.
Note: The steps below show an example of how to use Correlation rules and policy to provide enhanced visibility into unusual or suspicious activity. The example is not meant to be all encompassing for the Log4j vulnerability as additional attack vectors have been identified since this article was initially published. Readers should use the examples below to create their own environment specific custom rules based on up-to-date threat intelligence.
Talos first released updated Snort rules on Friday, December 10. For customers inspecting ingress traffic— with decryption if traffic is TLS (Transport Layer Security) encrypted — these rules will alert and can block attacks based on this vulnerability. Relevant Snort 2 rules are 58722-58744, 58751 and Snort 3 rules 300055-300058. New detection was released Saturday and will be updated again on Monday, December 13. Customers should continue to check for Snort rule updates out of band via automatic or manual updates as needed. Checking for new Snort SRU/LSP updates at least daily is recommended. For up-to-date information on current Snort rules and other Cisco security solutions visit the Talos Log4j blog here: https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html.
The following are further steps you can take to mitigate the risk of compromise.
While information regarding the attack techniques is still evolving, the most common vectors involve a vulnerable server accessing a malicious LDAP server to be fully exploited. With this in mind, here are steps that Cisco Secure Firewall Threat Defense network and security administrators can take to mitigate attacks on their systems.
Block outbound connections from DMZ servers. This is something that should already be in place as a general security practice.
Enable logging for this block rule and monitor for any attempts by your servers to connect to an external system. This could be an indication of a system that is under attack.
Enable outbound connection logging for your DMZ hosts or other potentially vulnerable systems.
Connection logging can be high volume, so it is important to be selective, but we need connection events for the next step to work. One way to do this is to add an Access Control Monitor rule to log your outbound connections from these systems. A Monitor rule is a safe way to add a rule to the Access Control policy without impacting traffic flow. Monitor rules only provide connection logging and do impact processing by other Access Control rules. Be sure to specify your DMZ host IP addresses/ranges as the source for this rule and place it high enough that traffic from your DMZ systems will hit it.
Create Correlation Rules to look for evidence of attacks such as outbound connections initiated (or attempted) from DMZ hosts to untrusted networks. Add appropriate alerting to this rule to notify of potential compromise.
Correlation rules provide additional notifications for existing events. In this case, the intent is to raise a flag any time we see behavior from a host that might indicate a compromise. Depending on your Firewall Management Center (FMC) configuration you can send a SNMP trap, Email or Syslog message when a Correlation Rule triggers. In addition, when enabled, these rules will always generate Correlation events in the FMC.
Quick steps to create such a rule:
Navigate to Policies –> Correlation –> Rule Management.
Create a rule.
Give it a name.
Select Connection event for the event type in the If drop-down.
In Connection events the client (your DMZ server in this case) is called the Initiator, so create a condition that will be true for connections initiated from these hosts. It would read something like “Initiator IP is in 10.0.0.0/24” – enter your own IP range here. If you need to add multiple source IP ranges, use the “Add Complex Condition” option. You can then add multiple condition rules using the OR operator to include multiple network ranges.
The example below shows a specific responder port but you can use any of the fields in a connection event, including fields like application protocol, country, initiator/responder IP, etc. You can use the AND/OR operators to create the specific logic for your rules.
In the end, a simple rule will look something like this:
The main idea behind a Correlation Rule is to look for unusual or anomalous traffic patterns. The great thing about these rules is they are not attack or vulnerability specific. This is because most attacks follow similar patterns, especially during and after a compromise. Using correlation rules to detect these patterns can greatly reduce your time to recognize and respond to an attack. As a bonus, these rules often work equally well when traffic is encrypted, as they do not need to look inside packets to be effective.
Finally, create or add this rule to a Correlation policy and enable external alerting as needed.
Cisco has a YouTube video describing Correlation Policy and rule creation available here: https://www.youtube.com/watch?v=bfqSUTLGHyY&t=3s
Stay abreast of further developments via the Talos Blog page here: https://blog.talosintelligence.com/
Following the steps above can help mitigate and/or alert for malicious behavior surrounding the Log4j vulnerability.