Forum Discussion
Apache Log4j Detection Optimizations Summary: While the...
Apache Log4j Detection Optimizations
Summary:
While the operating system ultimately controls scheduling and resource allocation, we have made additional optimizations to the Apache Log4j JAR Detection (Windows) (156001) plugin to reduce the resource usage while scanning entire file systems along with inspecting each Java archive file on the target Windows host during the scan.
Impact:
Customers should observe fewer resources being consumed on Windows scan targets during a local or Agent scan but may also observe longer scan times.
Note that the plugin timeout can be adjusted under Advanced Settings (e.g. timeout.156001) to a different timeout other than the default of one hour to assist in performance.
Also, please make sure that any security controls on the host are not interfering with the detection and possibly causing additional resource usage.
Plugin:
Apache Log4j JAR Detection (Windows) (156001)
Target Release Date:
January 19, 2022 (released in Nessus plugin feed 202201200227)
The plugin has been updated to no longer use the 'dir' and 'findstr' anymore since this can potentially use more resources and using Powershell for the file system scan, while potentially slower, uses less resources. Also, the plugin has been updated to slow down the Java archive inspection in Powershell before explicitly closing the handle. This should assist with the garbage collection and result in considerably less resource usage.
31 Replies
I think I am seeing this same issue in our enviornment. Scan says it ran from 2 to 3, but the script is still hogging resources from 2 to 8.
We have problems with a lot of devices when agent scan is running. High CPU, DISK and memory. We have to restart PC (sometimes button switch off) to be able to work
We have to stop all scan agents policies because this problems.
Has tenable any solution to fix this problem?
I am really confused by this sentence - Note that the plugin timeout can be adjusted under Advanced Settings to a different timeout other than the default of one hour to assist in performance. When I check "Advanced Settings > plugin timeout" it is set to 320 seconds or a little over five minutes. Where is the one-hour setting? @Scott Przywara @Donald Bakowski
The default one hour timeout comes from the plugin itself.
The custom setting, timeout.<plugin ID>, can be set for specific plugins such as 156001 (e.g. timeout.156001).
From the Advanced Settings page:
Enter the plugin ID in place of <plugin ID>. The maximum time, in seconds, that plugin <pluginID> is permitted to run before Nessus stops it. If set for a plugin, this value supersedes plugins_timeout.
I added this custom setting. Is this correct? Also, Would it be better to edit the plugin timeout for more than one hour or less than one hour for better performance? @Donald Bakowski @Scott Przywara @Greg Betz
where is this setting in Tenable IO?
How do you configure plugin specific settings in Tenable.sc? Tenable.io? Agents?
I'm getting increasingly disappointed in the lack of clear communications for this issue. I have a high priority ticket open and was basically told to just look here.. well unfortunately here isn't providing any of the answers.
It's very strange there was such a shift from requiring through checks for this then not..
Why is the plugin scanning the whole file system without thorough checks enabled? I thought that was the point of the thorough checks option?
That is our standard requirement but after customer feedback and consideration for the prevalence of Apache Log4j files, it was decided make an exception and to no longer require thorough tests. Additionally, customers were omitting thorough tests in subsequent scans which was causing the vulnerability to appear remediated in T.io and T.sc. Also, customers did not want other plugins that use thorough tests to be run.
We are considering re-introducing the thorough tests requirement in the future but not at this time.
Thanks for the response. Given the operational impact of the scanning the entire file system that others are mentioning, it seems like there is no way around impacting the system except for disabling the plugin completely which is not ideal. If I enable thorough checks, I expect increased scan time and resource usage. I don't expect that from a standard authenticated scan.
An earlier article mentioned that a scan without thorough checks would check running java processes for log4j and a scan with thorough checks would also scan the file system. I still think this is a good functional separation to have.
Hello,
There's no option to do so with Basic agent scans. How can I remove these plugins from basic agent scans ?
I see the updated date on the 156001 has been changed to 1/19 do these changes include addressing the high memory usage issue?
Hello Tony. Yes, the changes released in Nessus plugin feed 202201200227 should address the high memory usage issue some customers were seeing.
The changes below have been released in Nessus plugin feed 202201200227.
The plugin has been updated to no longer use the 'dir' and 'findstr' anymore since this can potentially use more resources and using Powershell for the file system scan, while potentially slower, uses less resources. Also, the plugin has been updated to slow down the Java archive inspection in Powershell before explicitly closing the handle. This should assist with the garbage collection and result in considerably less resource usage.
This doesn't exactly detail what was changed, just the plugins that were added/modified. We still don't have an answer to the questions above.
The resource consumption mentioned in the release highlight was the focus of the changes. More details were added to the original post and the comment above.
Plugin Apache Log4j JAR Detection (Windows) (156001) on version 202201200227.
Has anyone got any customer feedback if the updates have improved and reduced resources?
For two weeks, I've seen numerous scans where PowerShell has launched from the scan and 100% memory usage.
Both times the feedback from Tenable support has been the plugin has been modified (sensors up-to-date with the latest plugins in both instances) however this leaves me to test on production environments.
Hi,
In our environment the resource usage stopped after I updated all the plugins on all the scanners.
Tested the scan on agent and remote scanned machines and powershell "only" consumed around 700MB RAM and caused no issues. The scan time is much longer, it was 5 minutes on my pc now it's 50 minutes.
Previously my agent scanned client pc and remote scanned windows server crashed because of too much memory consumption.
