The objective of this guide is:
- Measure how much our firewall (and also what is behind it) is, or is not, secure, through the use of a Vulnerability Assessment System, that is a tool that is able to find the known vulnerabilities affecting the scanned system , and advise (sometimes) a method to solve the problem.
- Create safety reports that can enrich the audits required by the GDPR regulation.
- Test OpenVAS on pfSense to measure vulnerabilities. Obviously with the same parameters you could do the same thing with OPNsense and IPfire.
The current situation: what is happening
It is now known that, as never before, the subject of security is investing the IT sector like a flood. This for 2 main reasons.
– Attacks on computer security take place at all levels (from small businesses to multinationals) with increasing intensity.
– The current legislation on privacy, or regulation (EU) n. 2016/679 and better known by the acronym GDPR, which imposes standards such as periodic security audits, and control procedures.
Much more frequently than in the past, it happens to hear stories of companies that have had to pay thousands of euros in ransom to get their data back after a virus, or a hacker, had encrypted them making them unusable.
On a sample of about 100 companies that had “discomfort” in the field of computer security, we discovered that almost all had a firewall, which in most cases had an obsolete operating system and therefore in “end of life” and no longer manutentuto. In some cases the same firewall was “obsolete” with many open ports configured in forward mode, which forwarded traffic to obsolete operating systems using unsafe protocols.
But how can we know if our pfSense, OPNsense, Zeroshell, IPfire firewall is secure and well configured?
Who can tell us?
How do we “certify” that we have done everything possible to ensure the security of our network and our data?
OpenVAS comes to our aid!
How we performed the tests
Below we list the tools we have used for this article.
Hardware:
Virtual Appliance A3 Server, 32 GB RAM, SSD disks.
To run this solution it would also be possible to use cheaper hardware like:
Virtual Appliance A2 Server, or Virtual Appliance A1 Server
Download the ready-to-use solution!
We have prepared and made available for free the simulation environment described below.
It is a ready-to-use Linux VM to be run in a Virtual Box environment.
Just download the image, unzip it and run it with Virtual Box. Following all the steps below will be much simpler and more intuitive.
Use OpenVAS to verify firewalls and create reports for the GDPR.
What is OpneVAS, how it is born and what it does.
OpenVAS is a complete vulnerability scanner. Among its features we find thousands of ready-to-use tests for Internet and industrial protocols (both high-level and low-level), performance optimization for large-scale scans, and a powerful internal programming language to implement any type of test of vulnerability.
The scanner includes a vulnerability test consisting of a database updated daily by the community that currently has more than 50,000 tests.
The project was born in 2005 as a fork of the famous Nessus (commercial), and is released as Open Source to the community under the GNU General Public License (GNU GPL). In fact it is completely free and free.
The 3 milestones of the project are the following:
- The solution must go beyond the simple vulnerability scan to a complete vulnerability management solution.
- Create a turnkey appliance product for business customers.
- Adhere to the Open Source style. Create a transparent security technology.
How to set up a scan:
First you need to know that:
NVT = Network Vulnerability Test
VAS = Vulnerability Assessment System
We take for granted that the VM we created, and that you can download for free here:
is working and updated. So let’s skip all the installation and initial configuration part.
Once running, open a terminal and execute these commands to update the operating system:
# apt update
# apt upgrade
Start the service by giving the command
# sudo gvm-start
Access the system localhost on port 9392
# https://172.0.0.1:9392
The screen that we will display will be the following.
Username: admin
Password: admin (the access data will be sent with the registration email).
This will take you to the main Dashboard: We immediately refresh the page by clicking on “No auto-refresh” and set “Refresh every 30 Sec.”
To make the first scan, click on: SCAN, then TASKS as shown in the figure.
Then click on the blue icon, then New Task as shown in the figure.
To carry out the tests we used an old machine with Windows XP which, of course, will give us a chance to see how openVAS displays many serious vulnerabilities.
The screen will then open that will allow us to indicate the target of our vulnerability test.
Let’s fill out this form with: the name we want to assign to the task and a comment.
Then click on the blue icon to set the Scan Target. This menu is used to set the target (s) / s. We can indicate an IP address or we can upload a text file and indicate multiple targets. In this example we will limit ourselves to indicating a single ip in correspondence of the manual field.
The two Port list and Alive Test menus allow access to advanced configuration menus.
By clicking on SSH we can also set a user id and a password with which openVAS will try to access. This example will allow us to check if we have forgotten our default password on our pfSense, OPNsense, Zeroshell or IPfire. In this example we will leave everything by default
Click on create, then create again.
We therefore created our first task.
The screen we will see will be this:
To start the scan, click on the green arrow on the right under the heading Actions.
Please note that running a vulnerability test on a target not owned by us and without the owner’s authorization is against the law.
Under the status column we can see the progress of the task with the percentage of completion.
At the end of the scan, the status of the task is marked as “Done”.
To perform a scan, depending on the hardware used, it can take anywhere from 15 minutes to many hours. OpenVAS is very expensive, especially CPU.
Attention also to the target, as the tests subject it to a traffic which, depending on the conditions in which it is found, could put it in crisis as much CPU will be required.
To see the results, click on the last column on the date that appears in blue “Jun 24 2019”.
In this screen we can see the results that OpenVAS has found.
We immediately note the writing Report: Results (219 of 327). This means that on screen I will only see 219 reports with respect to the total of 327 that was found. This is mainly to limit the reports with respect to the QoD parameter (explained later in this article). If we wanted to visualize everything, we will simply click on the wrench to the right of the filter field and select what we want to see. For example, we can change the QoD parameter to 0. Click on Update.
Let’s better analyze the most important columns.
Vulnerability: description of the vulnerability found.
By clicking inside we can view the details of the vulnerabilities found. To date, there are approximately 51400 in the OpenVAS database.
(Second column) Solution Type: this information shows possible solutions for the vulnerability fix. The possible scenarios we can find are:
- Alternative solution: Information is available on an alternative configuration that can be used to avoid exposure to the vulnerability. This is generally the “first line of defense” against a new vulnerability before a vendor mitigation solution has been published, or even discovered.
- Attenuation: the information is available on a configuration scenario, or implementation, which helps to reduce the risk of vulnerability, but which does not resolve the vulnerability on the product concerned. The attenuations can include the use of devices, or access controls, external to the product concerned. Mitigation may, or may not, be released by the original author of the product and may or may not be officially issued by the document manufacturer.
- Vendor-Fix: information is available on an official correction issued by the original author of the product concerned. Unless otherwise stated, this correction is assumed to completely resolve the vulnerability.
- None available: no fix is available at the moment. The information should contain details on why there is no correction.
- WillNotFix: there is no fix for the vulnerability and there will never be one. This is often the case when a product on which development has been abandoned is at the end of the life cycle (end of life), or in any case deprecated. The information should contain details on why no correction will be issued.
Severity: the severity of the vulnerability found.
Gravity is a value between 0.0 (no gravity) and 10.0 (highest gravity) and also expresses a gravity class (None, Low, Medium or High). This concept is based on CVSS (Common Vulnerability Scoring System) but is also applied where a complete CVSS base vector is not available.
Comparison, weighting, prioritization: all possible for any scan result or NVT as this concept of severity is strictly applied to the entire system.
Gravity classes None, Low, Medium and High are defined by sub-intervals of the main interval 0.0-10.0. Users can choose to use different classifications. The default is the NVD classification, which is the most commonly used one.
The results of the scan are assigned a severity as they are tested and found. However, the severity of the relative NVT can change over time. Users can select Dynamic Severity to allow the system to always use the latest NVT severity.
Quality of Detection (QoD) or the quality of detection.
Quality of Detection (QoD) is a value between 0% and 100% that describes the reliability of the detection of the vulnerability or the detection of the product.
Below we publish a table that aims to explain:
| QoD | Tipo di QoD | Descrizione |
| 100% | exploit | Detection took place via an exploit and is therefore fully verified. |
| 99% | remote_vul | Remote active controls (execution of code, traversal attack, SQL injection etc.) In which the answer clearly shows the presence of the vulnerability. |
| 98% | remote_app | Remote active controls (code execution, traversal attack, sql injection etc) In which the answer clearly shows the presence of the vulnerable application. |
| 97% | package | Checks with authenticated access attempts based on packages for Linux systems (oid). |
| 97% | registry | Checks with registry-based access attempts for Windows systems. |
| 95% | remote_active | Active remote controls (code execution, traversal attack, sql injection etc.) In which the answer shows the probable presence of the vulnerable application. “Probably” means that they are only possible in rare circumstances where detection would be wrong. |
| 80% | remote_banner | Verifica di banner a distanza di applicazioni che offrono un livello di patch nella versione. Molti prodotti proprietari lo fanno. |
| 80% | executable_version | Remote banner verification of applications that offer a patch level in the version. Many proprietary products do this. |
| 75% | This value was assigned to any pre-qod result during system migration. However, some NVTs may eventually have this value for some reason. | |
| 70% | remote_analysis | Remote controls that perform some analysis but are not always completely reliable. |
| 50% | remote_probe | Remote controls where intermediate systems such as firewalls could feign the correct detection so that it is not actually clear if the application itself has responded. This can happen for example for non-TLS connections. |
| 30% | remote_banner_unreliable | Remote banner verification of applications that do not offer patch level in version identification. For example, this is the case with many Open Source products due to backport patches. |
| 30% | executable_version_unreliable | The authenticated executable version verifies Linux systems (oid) in which applications do not offer patch level in version identification. |
| 1% | general_note | General note on the potential vulnerability without finding any present questions. |
The 70% value is the default minimum used to display results in reports.
If we wanted to see the “hidden” results as well, we need only act on the filter parameter explained in the upper rows.
How to get an official vulnerability report.
If we wanted to have a report in pdf of the task just executed we can click in the upper left corner on “Anonymous XML” and select the desired format from a list very much supplied.
Selecting the PDF format creates a document that can be attached to the audit to be attached to the GDPR documentation.
OpenVAS applied to a pfSense installation.
Now that we have learned how to perform scans and know how to produce results we can try testing a firewall with pfSense.
To test the goodness of OpenVAS we simulate some critical issues such as:
– A version of pfSense not very up to date (ver. 2.3.2)
– We enable the ping response on our pfSense installation.
– We “forget” the default password.
Now we launch the scan keeping the de default values.
Here are the results:
As we can see, OpenVAS immediately identifies the presence of default credentials and reports it with a 100% QoD and reports as many as 50 results of which:
– 5 with severity Hight
– 6 with Medium severity
– 1 with severity Low
– 30 classified as Log.
Now let’s try to make things worse and install a very old version of pfSense:
– pfSense version 2.1.5
– We enable the ping response on our pfSense installation.
– We “forget” the default password.
The result we get is the following:
As you can see, we obtained as many as 72 reports compared to the 50 previously reported.
OpenVAS continues to inform us immediately of the presence of default credentials. The 72 results are divided into:
– 8 with severity Hight
– 23 with Medium severity
– 5 with severity Low
– 36 classified as Log.
For those wishing to investigate other aspects related to the optimization of firewalls and the GDPR legislation can read this article. (https://blog.miniserver.it/en/gdpr-pfsense-opnsense/)
Final Notes:
Normally it is not good that the company that made the sale and installation of the firewall to the end customer performs security checks (or as we have seen Vulnerability Assessment). If this happened it would be as if the “controlled” coincided with the “controller”.
