Protecting against the Apache Log4j exploitLast modified on 15 Dec, 2021. Revision 13
|Up to date for||
cOS Core 13.00.13
cOS Core 14.00.00
cOS Core 12.00
A recently discovered vulnerability in Apache Log4j 2 is reportedly being exploited in the wild, putting widely used applications and cloud services at risk. Log4j 2 is a popular Java logging framework developed by the Apache Software Foundation. The vulnerability, CVE-2021-44228, allows for remote code execution against users with certain standard configurations in prior versions of Log4j 2. As of Log4j 2.0.15 (released on Dec. 6), the vulnerable configurations have been disabled by default.
CVE-2021-44228 is considered a critical flaw, and it has a base CVSS score of 10, which is the highest possible severity rating.
What to do
Naturally the first thing to do would be to make sure that any affected system is either patched or the relevant configuration updated to make sure this exploit cannot be used. But it may also be an idea to either take the affected system offline, off the network or at least remove it from external access until the systems are configured to avoid the exploit or updated.
From cOS Core’s perspective (which is not affected by this exploit) there are some options available that could help protect or mitigate the exploit.
- Block the effected server(s)/service from external access using normal IP policy rules.
- As an example a simple drop rule towards the server or disable the rule that provide external users access to it. This should be considered temporary depending on the urgency of the problem encountered.
- If internal users should be blocked as well will be up to the administrator to decide.
- Enable IP reputation to add an additional layer of protection in order to block e.g. known scanners IP's.
- Use IDP to block the exploits on vulnerable systems.
Using IDP to block
There are currently (updated 2021-12-14 13:45) 14 signatures available to protect against this exploit. This list will be updated if/when new signatures are released.
ID Name Type/Group Release date
78167 Exploit.RCE.Apache.Log4j.CVE-2021-44228.A IPS LDAP GENERAL 2021-12-14
78168 Exploit.RCE.Apache.Log4j.CVE-2021-44228.B IPS LDAP GENERAL 2021-12-14
78169 Exploit.RCE.Apache.Log4j.CVE-2021-44228.C IPS LDAP GENERAL 2021-12-14
78170 Exploit.RCE.Apache.Log4j.CVE-2021-44228.D IPS LDAP GENERAL 2021-12-14
78171 Exploit.RCE.Apache.Log4j.CVE-2021-44228.E IPS LDAP GENERAL 2021-12-14
78172 Exploit.RCE.Apache.Log4j.CVE-2021-44228.F IPS LDAP GENERAL 2021-12-14
78173 Exploit.RCE.Apache.Log4j.CVE-2021-44228.G IPS LDAP GENERAL 2021-12-14
78174 Exploit.RCE.Apache.Log4j.CVE-2021-44228.H IPS LDAP GENERAL 2021-12-14
78175 Exploit.RCE.Apache.Log4j.CVE-2021-44228.I IPS LDAP GENERAL 2021-12-14
78176 Exploit.RCE.Apache.Log4j.CVE-2021-44228.J IPS LDAP GENERAL 2021-12-14
78177 Exploit.RCE.Apache.Log4j.CVE-2021-44228.K IPS LDAP GENERAL 2021-12-14
78178 Exploit.RCE.Apache.Log4j.CVE-2021-44228.L IPS LDAP GENERAL 2021-12-14
78179 Exploit.RCE.Apache.Log4j.CVE-2021-44228.M IPS LDAP GENERAL 2021-12-14
78180 Exploit.RCE.Apache.Log4j.CVE-2021-44228.N IPS LDAP GENERAL 2021-12-14
All signatures are in the IPS->LDAP->General group. IDP can therefore be configured as shown in the below picture to protect against this exploit.
Important: Using IDP, IP reputation etc. should not be considered the only action that is needed. The most important aspect is to patch the affected systems, using the Firewall to block the exploit is not a 100% guarantee to protect against the exploit as it might as well be an exploit that is attempted from inside the local network.
Note: IDP will not be able to detect the exploit attempt if the traffic is encrypted (such as HTTPS) or encapsulated in a VPN tunnel (such as IPsec). If the HTTPS server is located behind the firewall, the TLS ALG can be used to “decrypt” HTTPS and run IDP on the HTTP traffic.
14 Dec, 2021 easyaccess log4j
12 Jan, 2022 incenter log4j vuln