Protecting against Log4j with Secure Firewall & Secure IPS – Cisco Blogs

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 protect against attacks leveraging this vulnerability while patching their infrastructure.

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.

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 unnecessary outbound connections from DMZ servers. This is something that should already be in place as a general security practice. For this situation, add an Access Control rule to block outbound connections from your DMZ hosts on the LDAP port – 389/tcp. Going further by blocking all unnecessary outbound connections is an even better way, especially since all the potential attack vectors are not fully known.  However, if you are worried about impacting existing business processes, you may want to at least start with LDAP connections.

Enable logging for this 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.

If you cannot block outbound connections, the next steps will allow monitoring for these connections.  This will not stop the attack, but will notify you that follow-up action may be required.

Step 2

Enable outbound connection logging for your DMZ hosts or other potentially vulnerable systems.

Connection logging can be very 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 a Correlation Rule that triggers for any 389/TCP connections initiated from DMZ hosts to anywhere. 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.

You will probably want to limit this rule to connections from specific hosts to the LDAP port. To do this,  add conditions for the IP ranges and for the port.

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.

Then add a condition for the Responder Port 389.  This would use the AND operator combined with the source IP ranges added above.

In the end, your rule will look something like this:

Finally, create or add this rule to a Correlation policy and enable eternal 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.

Additional Resources

Cisco Talos Log4j Advisory

Cisco Event Response: Apache Log4j Java Logging library

Share: