Since the last few days the internet world has been taken over by a serious network/application security issue called Log4j – tracked as “CVE-2021-44228”. The US government cybersecurity agency has termed it a major threat and companies like Microsoft and Amazon have issued advisories to deal with the same. A software patch has already been released and now network engineers around the world are rushing to apply the fix.
Why is the Log4j issue so threatening?
Log4j is an Apache open source, Java-based logging framework which is used in Java applications across the globe. A part of this is the JNDI – Java naming directory interface which allows Java applications to find data through a directory. Application users use the JNDI along with LDAP to find Java Objects that they need. And as the LDAP can reside anywhere (not locally but on virtual servers) on the internet it can be remotely controlled by an attacker using the URL.
If an attacker is successful in gaining control then they can cause the Java program to load an object from a malicious server that they control. This allows the attacker to do a remote controlled execution (RCE). An RCE is one can say – one of the most feared vulnerabilities and poses a major security issue to all Java-based applications being used worldwide.
To make it worse, hackers are trying to exploit this vulnerability – some of whom are also openly sharing their “how to exploit” tactics. A lot of applications like Apple iCloud, social media and shopping applications are dependent on Log4j. Network teams and F5 engineers are therefore in a hurry to fix this issue by rolling out software patches and upgrades before something tragic happens.
Identifying vulnerable servers that need immediate protection
Internet facing F5 GTMs without sufficient protection to respond to outgoing traffic from an organization are seen as vulnerable by organizations. Organizations are therefore looking at ways to bulk update F5 iRules to mitigate the risk of log4j.
Adding iRules to virtual servers using ADC+
To secure the vulnerable servers against the log4j threat F5 has released an iRule “K59329043”. This F5 iRule definition can be used to mitigate the impact of the Apache Log4j2 Remote Code Execution (RCE) vulnerability in your network infrastructure – but the challenge lies in implementing this rule to multiple devices and hosted applications at once.
F5 engineers can use AppViewX ADC+ interface to attach F5 iRules to a set of virtual servers. F5 iRules allow us to manipulate the server and client side traffic all the way upto the application layer. Adding an F5 iRule sequence to a group of servers all at once can save time and help you cut down on errors that result from performing repetitive tasks.
A fairly simple process to apply the iRule using ADC+
- Select the devices and their associated VIPs that need to be modified or provide URL
- Choose the F5 iRule that needs to be applied
- To create a new F5 iRule simply type the new iRule code to be executed in the new iRule Option
- On submit, the new F5 iRule will be implemented
The entire upgrade process only takes 2 to 5 minutes. Moreover if an F5 engineer does a manual F5 iRule update through the F5 interface, he won’t be able to save the F5 iRule that is being overwritten. But ADC+ has the option to keep a backup of the old rule as well.
A large investment bank needed to apply changes to the F5 devices and VIPs at a short notice. Luckily for them, they have ADC+ for managing their F5 installations. They used ADC+ templates for F5 iRule modification (and) control centre to point out gtm and its associated VIPS and objects. To make it even easier for business users, ADC+ has built-in logic to look up at the url, match with certificate common name and easily filter out the VIP and its related objects which made it easier for them to choose and update the F5 iRule in a workflow.