I have OpenVas 9 running (apparently fine) on Ubuntu 16.04. I was surprised when I ran a scan on a remote router and it missed port 3389 where a RDP service is running.
OpenVas is updated.
NMAP detects port and I ran vulnerability scans scripts against that router.
The most common reason for this is that you have chosen a port list which doesn’t include the port 3389/tcp.
Other reasons are e.g. that the service stopped to respond during the scan (RDP might be a little fragile against vulnerability scans depending on the RDP implementation used on the remote device). Firewalls and additional security measures on the remote host might play a role here as well.
Thank you for your reply.
I used OpenVAS default port settings which includes TCP port reange from 3372 to 3403.
Nmap picks up information quite well.
That’s odd. I’ll keep carry on with investigation.
You could also verify if your installation is indeed up to date and not running outdated GVM components (there is at least one repository known which is shipping outdated versions). The current official/stable/supported versions are listed in the following topic:
Send us the log-file (/tmp/openvas-check-setup.log) to help analyze the problem.
Use the parameter --server to skip checks for client tools
like GSD and OpenVAS-CLI.
Step 1: Checking OpenVAS Scanner …
OK: OpenVAS Scanner is present in version 5.1.3.
OK: redis-server is present in version v=3.0.6.
OK: scanner (kb_location setting) is configured properly using the redis-server socket: /var/run/redis/redis.sock
OK: redis-server is running and listening on socket: /var/run/redis/redis.sock.
OK: redis-server configuration is OK and redis-server is running.
OK: NVT collection in /var/lib/openvas/plugins contains 48872 NVTs.
WARNING: Signature checking of NVTs is not enabled in OpenVAS Scanner.
SUGGEST: Enable signature checking (see http://www.openvas.org/trusted-nvts.html).
WARNING: The initial NVT cache has not yet been generated.
SUGGEST: Start OpenVAS Scanner for the first time to generate the cache.
Step 2: Checking OpenVAS Manager …
OK: OpenVAS Manager is present in version 7.0.3.
OK: OpenVAS Manager database found in /var/lib/openvas/mgr/tasks.db.
OK: Access rights for the OpenVAS Manager database are correct.
OK: sqlite3 found, extended checks of the OpenVAS Manager installation enabled.
OK: OpenVAS Manager database is at revision 184.
OK: OpenVAS Manager expects database at revision 184.
OK: Database schema is up to date.
OK: OpenVAS Manager database contains information about 48871 NVTs.
OK: At least one user exists.
OK: OpenVAS SCAP database found in /var/lib/openvas/scap-data/scap.db.
OK: OpenVAS CERT database found in /var/lib/openvas/cert-data/cert.db.
OK: xsltproc found.
Step 3: Checking user configuration …
WARNING: Your password policy is empty.
SUGGEST: Edit the /etc/openvas/pwpolicy.conf file to set a password policy.
Step 4: Checking Greenbone Security Assistant (GSA) …
OK: Greenbone Security Assistant is present in version 7.0.3.
OK: Your OpenVAS certificate infrastructure passed validation.
Step 5: Checking OpenVAS CLI …
OK: OpenVAS CLI version 1.4.5.
Step 6: Checking Greenbone Security Desktop (GSD) …
SKIP: Skipping check for Greenbone Security Desktop.
Step 7: Checking if OpenVAS services are up and running …
OK: netstat found, extended checks of the OpenVAS services enabled.
OK: OpenVAS Scanner is running and listening on a Unix domain socket.
OK: OpenVAS Manager is running and listening on a Unix domain socket.
OK: Greenbone Security Assistant is running and listening on all interfaces.
WARNING: Greenbone Security Assistant is listening on port 4000, which is NOT the default port!
SUGGEST: Ensure Greenbone Security Assistant is listening on one of the following ports: 80, 443, 9392.
Step 8: Checking nmap installation …
WARNING: Your version of nmap is not fully supported: 7.01
SUGGEST: You should install nmap 5.51 if you plan to use the nmap NSE NVTs.
Step 10: Checking presence of optional tools …
OK: pdflatex found.
OK: PDF generation successful. The PDF report format is likely to work.
OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
WARNING: Could not find rpm binary, LSC credential package generation for RPM and DEB based targets will not work.
SUGGEST: Install rpm.
WARNING: Could not find makensis binary, LSC credential package generation for Microsoft Windows targets will not work.
SUGGEST: Install nsis.
It seems like your OpenVAS-9 installation is OK and I’m running updates daily. Still nothing comes up regarding port 3389 as if it isn’t there.
Just some additional clarification, the detection of a RDP service doesn’t show up in default view of a report and there are only 4 VTs in the feed which is actually checking for a vulnerability in RDP (and thus could report such a vuln) remotely.
To see the actual detection of RDP you need to configure your filter to show “Log” level items as well. Then look out for an entry of one of the following VTs:
Microsoft Remote Desktop Protocol Detection (OID: 126.96.36.199.4.1.256188.8.131.52062)
Collect banner of unknown services (OID: 184.108.40.206.4.1.256220.127.116.1154)
If none of both are showing up most likely the following is valid:
Thank you for your help and support.
Activating log I can see RDP now.
Please, one more question: nmap is reporting lots of vulnerabilities while OPENVAS reports 0%. of risk. Should I consider nmap results as false positives?