Forum Discussion
Apache Log4j Detection Optimizations Summary: While the...
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.
Please can you confirm that the basic agent scan through tenable.io no longer carries out a full file system scan?
Wow, this is a pretty dramatic move... while I understand the intent behind the change, there is a reason people do not want to do entire file system checks (especially when you run daily Agent scans).
Exactly which changes have been made to plugin 156001 between versions 1.9, 1.10 and 1.11, respectively? We are especially interested in information about any changes to the following command-line launched by that plugin, since that's what seems to cause the problem.
$jars = $(cmd.exe /c dir /A-L /s /r /b 'DIR1' 'DIR2' 'DIR3' | findstr /R '.*\.jar$ .*\.war$ .*\.ear$
We have servers with 16 million files, and pipe:ing that complete file listing to findstr might not be a good idea. That file search also generates 128.000 Powershell events (EID 800). Is plugin 156001 supposed to handle servers with this amount of files?
We have a high priority support case for this since January 14, but unfortunately we haven't received any concrete information at all.
Probably it would have been wise to google for an efficient way to get the files...
Maybe try this one, since PS is used anyways: https://superuser.com/a/1459251
It appears that Tenable is trying to optimize the 'inner loop', rather than addressing the overall approach of the plugin. There is a lot of discussion in the Community about Powershell issues with foreach loops causing memory use, event logs (as Markus noted), etc. Until that 'outer loop' to collect the files is made efficient, these other changes are really moot.
The thorough tests requirement was removed December 22 as mentioned in this Release Highlight: https://community.tenable.com/s/feed/0D53a00008FRFabCAH
Please contact technical support to show your support for getting thorough tests back in place.
There are trade-offs with using dir/findstr vs Powershell but the plugin was 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 handles. This should assist with the garbage collection and result in considerably less resource usage.
