For hidding the Apache version information we use server signature etc off like in httpd.conf
ServerSignature Off
ServerTokens Prod
TraceEnable Off
By doing the Apache header is not revealing any information about version like
$ curl --head localhost
HTTP/1.1 200 OK
Date: Mon, 13 Jun 2022 11:29:47 GMT
**Server: Apache**
Last-Modified: Thu, 13 Jan 2022 10:16:36 GMT
ETag: "0-5d573fb35b75d"
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
But some how Tenable scanner is still able to detect the Apache version ( 2.4.37 ) in Rocky 8 which is already updated with its repo. But scanner complaining about some vulnerabilities and pushing to update to 2.4.52 etc.
Below is extract from Tenable Scanner Report.
The remote operating system matched the following CPE :
cpe:/o:linux:linux_kernel -> Linux Kernel
Following application CPE's matched on the remote system :
cpe:/a:apache:http_server -> Apache Software Foundation Apache HTTP Server
cpe:/a:apache:http_server:2.4.37 -> Apache Software Foundation Apache HTTP Server
cpe:/a:gnupg:libgcrypt:1.8.5 -> GnuPG Libgcrypt
cpe:/a:openbsd:openssh:8.0 -> OpenBSD OpenSSH
How to hide the Apache version information completely from Scanner ?
Does your Tenable/Nessus scanner have SSH access to the server you are scanning? If so, then that would be normal since it will login and verify the exact packages installed. If there is no SSH access, then based on the profile used to scan, letâs say RHEL or Rocky, then it will predict the version installed but not be able to verify exactly what version it is. This is normally shown in the report itself within the Tenable/Nessus web interface. At least when Iâve used Nessus that is how it works.
Hi,
Yes it has it has ssh access to webservers.
Then this is normal behaviour. Removing SSH access would mean your scanner is not able to verify but it will still predict a certain version.
Since you are scanning your own network, and itâs being done for a reason, I suggest that the scanner should have as much information as possible to guarantee ensuring for 100% whether you have a security risk or not. It doesnât make sense in that instance to hide such important information.
hi walker,
Security scan is usually run by the Security team, there objective is to get vulberablity free reports in order to present to different audits conducted time to time.
Now in a report which is showing 14 vulerablity only due to Apache version it become very hard to convince them, that there is no issue in that
Below is report for one server only
Yes, the summary screen doesnât show much. Normally you click on each item and read what it says underneath and in some cases make the appropriate configuration options to resolve certain issues. Some, if requiring updates will obviously not be resolved until the updates are made. At which point, if a system hasnât been updated to the latest patch releases for Apache will mean updating the system and then re-running the scan.
Sure, everybody likes to see a report that is free from vulnerabilities, but the Security team should be checking each of those to ensure whether that vulnerability actually exists or not. Usually in the details of each error on the report it will say if it was able to verify if it exists or not - this would then show whether the actual SSH connection worked or not. If this is the case, then the SSH connection needs to be fixed so that it can login and gain access to root with sudo or via password with su.
Failing that, means someone needs to go through and verify the report properly and either make appropriate changes or comments that the item has been checked and the problem doesnât exist.
Personally, when I have ensured SSH access exists, then my reports have virtually no problems whatsoever. Iâll post a scan of one of my servers later to prove this as my scanner is at home and the machine is turned off right now.
The top entry in the image says âmod_lua Buffer Overflowâ.
Is that the same vulnerability as CVE-2021-44790 described in Red Hat Customer Portal - Access to 24x7 support and knowledge
which Red Hat has fixed in RHEL 8 with RHSA-2022:0258 Red Hat Customer Portal - Access to 24x7 support and knowledge
(as also seen from packages changelog with rpm -q --changelog httpd | grep CVE )
IF Tenable 16154 is CVE-2021-44790 and you have httpd >= 2.4.37-46
THEN Tenable has no idea how to properly scan RHEL/Rocky.
After running a scan on my rocky VM to check/verify, basically Tenable/Nessus is the problem here. With an updated instance, and using the Rocky profile on Nessus, it looks like it is just going by the version number than rather actually checking to see if the version is affected or not (eg: patched).
So assuming that everything is updated and patched, then the risks arenât there, but Nessus seems to only check so deep, or rather not and just compare version numbers. Which is poor to be honest, but common across a lot of the security scanners.
In such instances, itâs up to the person/department scanning it, to check/verify accordingly since the scan itself isnât enough. But that isnât Rockyâs or RHELâs problem, it is something you would need to bring up with Tenable.
Below screenshots:
1 Like
Regarding ânessusâ and ssh, it it true that it only offers ssh for the scanning (as opposed to having to install an âagentâ (as root) to each target system? Futther to that, does the ssh session run as a non-root user?
@gerry666uk nessus doesnt use agents. Ssh can be configured to connect as standard user and use sudo or su, or it can even connect directly as root. It all depends on how the scan policy is configured.
So does it actually need sudo or su, why?
I supposed itâs still much safer than bigfix, because at least you can audit every command that it runs.
Probably because it can only do certain commands with elevated privileges either using su or sudo. I am sure it is explained in the nessus documentation if you wish to check it out.
I was able to find confirmation that it requires sudo access in the docs, but Iâve no idea why it needs this.
Really good example here: Configuring Least Privilege SSH scans with Nessus - Blog | TenableÂŽ
Now letâs try an example from that link as a standard user on my system:
[ian@elise ~]$ dmidecode
# dmidecode 3.3
/sys/firmware/dmi/tables/smbios_entry_point: Permission denied
Scanning /dev/mem for entry point.
/dev/mem: Permission denied
so like I said, and is typical with Linux - if you cannot run commands as a standard user, then you need to use privilege escalation using sudo or su.
Another example with databases: Tenable Community
For scans to be accurate, is the biggest reason for why the privilege escalation is needed, so that Nessus can run the commands it needs to. If you donât allow it, then you wonât be able to have a complete and accurate report as to whether your system is vulnerable or not.
If you require more detail than that rather generic example it would mean asking Tenable directly for exactly what else they need privilege escalation for - eg: what commands are being run etc since they donât publish it.
Ah, it sounds like the first article is exactly what I was asking, and that many others have had the same conversation. The dmidecode is a good example, assuming a security scanner needs to run that. The database example; luckily the mysql versoin of it is quite harmless.
