For each system you manage, you will receive an email listing the detected security vulnerabilities. In the mail, you first get general information about the host and its administrators. Below that, all found vulnerabilities are listed with the most important information about the vulnerability:

• Synopis: summary of the vulnerability
• Solution: the action you need to take to eliminate the vulnerability
• VPR Score: this is the score that our security scanner assigns to vulnerabilities. See https://docs.tenable.com/tenablesc/Content/RiskMetrics.htm. A score of 7 or higher deserves your immediate attention. A vulnerability with a lower score can be planned in, but must also be treated in the long term.
• Risk: translation of the VPR score into its category name.
• Exploit available: Indicates whether an exploit is available online. If yes, this means that the vulnerability has a very high chance of being exploited.
• Patch pub date: since when the vulnerability fix has been available. When this is long in the past, it indicates that you do not update your system often.
• PluginID info: link to full information about the vulnerability.
  Plugin text: specific information to fix a certain vulnerability. Eg the path or URI containing the vulnerability.

---

We expect the administrators to resolve the vulnerabilities within a reasonable period of time. If this does not happen, we will take appropriate measures. Virtual server administrators should also be aware of the terms of use.

Our first measure is to inform the administrators of the existence of the vulnerabilities with the necessary suggestions. In the first instance, we count on everyone's responsibility to keep their own systems as secure as possible.

If no action is taken on our reporting, we will take the following measures:

• When the machine turns out to be unmanaged, we take the machine offline because it poses a serious security risk.
• Depending on the vulnerability, we can choose to isolate the machine (e.g. make it inaccessible via the Internet).
• In consultation with the responsible person, we can decide to accept the risk.

If this does not happen, we will take the machine offline as they pose a serious security risk.

The Executive Board of Ghent University has decided on 17.6.2022 that the central IT department DICT has the right to isolate IT-systems that present a serious risk from UGentNet, or to deactivate them, subject to proper communication and motivation to the local IT system administrator of the concerned systems.

---

We recommend installing security updates automatically for every system. For Windows and Linux systems, there is no reason not to do this anymore. The update procedures are robust and the chance that something goes wrong is minimal.

See below for the tools we recommend:

• Debian/Ubuntu: unattended-upgrades
• RHEL/Centos: dnf-automatic (8 and higher), yum-cron (7 and lower) (RHEL portal)
• Windows 
• MacOS

---

We are using Tenable.SC.

---

As the software connects to your system and tries to reveal the vulnerability of your system, you will see messages appearing in your log files. You can ignore these. If necessary, you will have to adapt your own monitoring software to take this into account. If the scanning performance causes a nuisance, you can report this to the helpdesk.

The scans are done from the following hostnames. The IPs may change and the list may be expanded in the future:

• dictscanner1.private.ugent.be
• dictscanner2.private.ugent.be
• dictscanner3.private.ugent.be

We also ask for connections from the scanners that cannot be disabled because vulnerable systems cannot be disabled.

---

We use the information in Netadmin and who has access to a virtual server. It is the task of these persons to keep the server up-to-date.

If you believe that you are not responsible, we ask that you do one of the following:

• you consult with the other responsible parties and relinquish your access to the virtual server;
• if you are the responsible person in Netadmin, you must find a new responsible person and ask them to take ownership via Netadmin;
• If there is no longer any responsible, contact the help desk and ask to delete the server.

For virtual servers, you can set who has access to a virtual machine via the DICT self-service.

---

Commonly, false positives in vulnerability scanning occur when the scanner can access only a subset of the required information, which prevents it from accurately determining whether a vulnerability exists.

To help reduce the number of false positives, we can configure our scanners with the appropriate credentials. The scans need access to all of the asset information required information from assets so that you can accurately determine whether a vulnerability exists.
 

Why do false positives occur?

A false positive might occur when the scanner can read only the configuration information from service banners. For example, a scanner that reads an Apache banner can detect that only version 2.2.15 is installed from the HTTP banner, even when version 2.2.15-39 is also installed and that the version contains a software fix that was backported.

Another example is when the scanner reads the banner and detects the version of SSH that is installed, but can't detect the patch level or the operating system. If the scanner detects that SSH-2 is installed but can't determine the operating system, the scanner can't accurately determine whether a vulnerability exists in some instances. The vulnerability might be correctly identified on one asset but is a false positive on the other asset because SSH vulnerabilities on Red Hat SSH might not be the same for other Linux® operating systems.

Why don't scanners retrieve all the required information?

Vulnerability scanners can't always access the information that they need to accurately determine whether a vulnerability exists. This limitation commonly results in false positives.

Can we set up authenticated scans?

Currently, we haven't implemented this. In the future, we may do this.

Why are some vulnerabilities counted twice?

Some vulnerabilities may appear more than once in the list, for example for different ports. In exceptional cases, the software may also have made a mistake. Please report this so we can investigate

---

First, we would like to refer you to
the Tenable website https://www.tenable.com/plugins and
the specific CVE pages: https://www.tenable.com/cve.

Secondly:

• system administration questions: https://helpdesk.ugent.be/helpme/en/
• substantive questions regarding the detected vulnerabilities: feel free to email vulnerabilityscanning@ugent.be. Please attach the report.

---

The report listed a lot of vulnerabilities and you don't know where to start? You can follow the advice below:

1. If the software/server isn't used anymore, remove the asset.
2. Upgrade to the latest supported version of your OS and software application and make sure updates are installed automatically.
3. If the vulnerability can't be solved apply an excellent mitigation strategy:
   1. Configure firewall rules to prevent access. E.g. limit access to the machine: no Internet access, or better only access from specific IPs
   2. Put an authentication system before the service so that users must authenticate before they access the service. 

Vulnerabilities that have VPR > 7 or which are exploitable must receive immediate attention. 

---

Password authentication for SSH is less secure than key-based authentication for several reasons:

1. Vulnerability to Brute Force Attacks

• Passwords can be guessed using brute force tools. Even with protections like Fail2Ban, weak passwords remain a risk.
• With key-based authentication, an attacker must have both the private key and the passphrase, which is significantly harder.

2. Susceptibility to Data Breaches

• Passwords can be stolen via phishing, malware, or data breaches.
• SSH keys are cryptographic files that cannot easily be shared or stolen without access to the device where they are stored.

3. Human Error

• People often use weak or reused passwords.
• Keys are generated using strong cryptography, making them much safer than human-created passwords.

4. No Location Restriction

• Passwords can be entered from any device, increasing risk if they are compromised.
• Key-based authentication requires access to the device where the private key is stored, adding a layer of physical control.

5. No Additional Security

• Passwords do not provide an extra layer of protection.
• Keys can be protected with a passphrase, meaning even if a key is stolen, it cannot be used without the passphrase.

6. Lack of Traceability

• Passwords can be shared among multiple people, making auditing difficult.
• SSH keys are unique and can be tied to specific users, improving traceability and accountability.

7. Reactive vs. Proactive Security

• Tools like Fail2Ban block attacks only after suspicious activity is detected.
• Key-based authentication prevents attacks entirely because access is impossible without the private key.

8. Scalability and Management

• Managing passwords for multiple users or systems is complex and prone to errors.
• Keys can be centrally managed, revoked, and rotated without disrupting users.

In summary, key-based authentication offers a significantly higher level of security through strong cryptography, better access control, and reduced vulnerability to attacks and human error.

---