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.
Step 1
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.
Step 2
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.
Step 3
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.
Excellent, actionable information.
Alex, thanks for the straightforward info!
Great info this directly went to my signature list change window tonight and we could protect our critical assets from exploit.
This is exactly what I was looking for! Thanks so much.
Great suggestions.
Can you add rni:// recommendations?
what is the port is passed in the ldap uri?
This is intended to be an example of how you might go about using the Correlation rules/policy feature. Yes, you should evaluate the threats and modify or create additional rules as needed. As an example, rather than looking for specific outbound ports, looking for outbound connections with the LDAP protocol might yield better results.
What about IPS signature config for FMC? Talos mentions:
“Cisco Talos has released ClamAV rules Java.Exploit.CVE_2021_44228-9914600-2, Java.Exploit.CVE_2021_44228-9914601-4, and Java.Exploit.CVE_2021_44228-9915330-0. Please refer to the Coverage section for more details.”
is the above not required if we follow the blog?
Use every tool at your disposal! Correlation rules are a good way to detect suspicious/malicious behavior however they don’t replace other features like Snort deep packet inspection, Security Intelligence, Malware & File inspection, etc.
Succinct, to the point. Thank you Alex!
What about if the LDAP server is answering on any other port then 389? Can’t we block the application “ldap” from a an ip range to an ip range instead?
Absolutely, this is just a bare bones example of the use of Correlation rules/policy. There are a ton of additional fields in a connection event you can use to make rules like this more flexible as new information becomes available regarding this threat.
Great information Alex. I got this information from Marshall Lewis.
In the examples of Log4j I’ve seen so far, the port is usually not the standard 389… Application layer inspection may be a better option.
Any thoughts?
There’s no reason why you can’t create several correlation rules to look for evidence of the attack. Use the application protocol is one way but there are surely others as well. Also, don’t forget that the correlation rule will only tell you that the attack is underway – it won’t stop it. Using the Talos Snort rules and blocking outbound connections are still recommended to actually thwart an attack.
In my opinion this is a bad blog post….
Because of this reasons:
* Attackers can use different ports, blocking 389 is not enough, real attackers probably use ports like 443 or 80 to bind their LDAP server. So blocking the LDAP ports is not enough at all.
* Attackers can use LDAPS, they are not limited to LDAP, if LDAPS is used the connection is end to end encrypted.
The steps 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.
There is a huge difference between a “bad” post and a “general knowledge” post.
most of web server are already using LDAP to communicate with internal LDAP servers , so a more specific rule is needed to get matches only if outbound connections to internet hosts
Readers should use the examples to create their own environment specific custom rules based on up-to-date threat intelligence.
Nice one and concrete. Thanks.
Sad to see some comments though it is clearly mentioned in the post that ‘The example is not meant to be all encompassing for the Log4j vulnerability . .’