Voor ieder systeem dat u beheert krijgt u een email waarin de gedetecteerde security kwetsbaarheden worden opgesomd. In de mail eerst algemene informatie gegeven over de host en zijn beheerders. Daaronder worden alle gevonden kwetsbaarheden opgelijst met de belangrijkste informatie over de kwetsbaarheid:

• Synopis: samenvatting van de kwetsbaarheid
• Solution: de actie die u dient te ondernemen om de kwetsbaarheid weg te werken
• VPR Score: dit is de score die onze security scanner toekent aan kwetsbaarheden. Zie https://docs.tenable.com/tenablesc/Content/RiskMetrics.htm. Een score vanaf 7 verdient uw directe aandacht. Lager kan ingepland worden, maar moet ook behandeld worden op termijn.
• Risk: vertaling van de VPR score in zijn categorie naam.
• Exploit available: geeft aan of er een exploit beschikbaar is online. Wanneer hier ja staat, wil dit zeggen dat de kwetsbaarheid een zeer grote kans heeft om misbruikt te worden.
• Patch pub date: sinds wanneer de oplossing van de kwetsbaarheid beschikbaar is. Wanneer dit reeds lang in het verleden ligt, duidt dit erop dat u uw systeem weinig update.
• PluginID info: link naar volledige informatie over de kwetsbaarheid.
• Plugin text: specifieke informatie om een bepaalde kwetsbaarheid op te lossen. Bv het pad of de URI met de kwetsbaarheid.

---

Van de beheerders verwachten we dat ze op redelijke termijn de kwetsbaarheden oplossen. Wanneer dit niet gebeurt nemen we gepaste maatregelen. Beheerders van virtuele servers dienen zich ook bewust te zijn van de gebruiksvoorwaarden.

Onze eerste maatregel is het op de hoogte brengen van de beheerders van het bestaan van de kwetsbaarheden met daaraan gekoppeld de nodige suggesties. We rekenen in eerste instantie op ieders verantwoordelijk om zijn eigen systemen zo veilig mogelijk te houden.

Indien er geen gevolg wordt gegeven aan onze rapportering nemen we de volgende maatregelen:

• Wanneer de machine onbeheerd blijkt te zijn halen we de machine offline omdat deze een ernstig security risico vormt.
• Afhankelijk van de kwetsbaarheid kunnen we ervoor kiezen om de machine te isoleren (bv niet meer toegankelijk te maken via het Internet).
• In overleg met de beheerder kunnen we beslissen om het risico te aanvaarden.

Wanneer dit niet gebeurt zullen we de machines offline halen aangezien zij een ernstig security-risico inhouden.

Het Bestuurscollege heeft op 17.6.2022 beslist om DICT het recht te geven om IT-systemen die een ernstig risico vormen te isoleren van UGentNet of uit te schakelen, mits de nodige communicatie en duiding aan betreffende lokale IT-beheerders.

---

In het document 10 punten voor veilig servers/service beheren voor systeembeheerders vindt u enkele aanbevelingen.

Voor ieder systeem adviseren we het automatisch installeren van de security updates. Voor Windows en Linux systemen is er geen enkele redenen om dit niet meer te doen. De update procedures zijn robuust en de kans dat er iets fout gaat is miniem. Zie hieronder voor de tools die we adviseren:

• Debian/Ubuntu: unattended-upgrades
• RHEL/Centos: dnf-automatic (8 en hoger), yum-cron (7 en lager) (RHEL portal)
• Windows 
• MacOS

---

De software die werd aangekocht is Tenable.SC. Tenable.SC maakt gebruik van Nessus. Een gekende software om IT-kwetsbaarheden op te sporen.

---

Omdat de software met uw systemen connectie maakt en probeert te achterhalen of uw systeem kwetsbaar is zult u in uw log-files meldingen zien verschijnen. U kunt deze negeren. Indien nodig zult u uw eigen monitoring software moeten aanpassen om hiermee rekening te houden. Indien de scans performantie overlast veroorzaken kunt u dit signaleren aan de helpdesk.

De scans gebeuren van de volgende hostnames. De IP's kunnen veranderen en de lijst kan in de toekomst uitgebreid worden:

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

We vragen ook om connecties van de scanners niet te blokkeren omdat zo kwetsbare systemen niet gedetecteerd kunnen worden.

---

Er wordt gebruik gemaakt van de de informatie in netadmin en van wie toegang heeft tot een virtuele server. Het is de taak van deze personen om de server up to date te houden.

Indien u van mening bent dat u geen verantwoordelijke bent, vragen wij dat u één van volgende zaken doet:

• u overlegt met de andere verantwoordelijken en staat uw toegang af tot de virtuele server;
• indien u de verantwoordelijke bent in Netadmin, dan dient u een nieuwe verantwoordelijke te zoeken en aan deze te vragen via Netadmin het eigenaarschap op te nemen;
• indien er geen enkele verantwoordelijke meer is, dan neemt u contact op met de helpdesk en vraagt u om de server te verwijderen.

Voor virtuele servers, kunt u via de DICT selfservice instellen wie toegang heeft tot een virtuele machine.

---

Gewoonlijk treden valse positieven bij het scannen op kwetsbaarheden op wanneer de scanner slechts toegang heeft tot een subset van de vereiste informatie, waardoor hij niet nauwkeurig kan bepalen of er een kwetsbaarheid bestaat.

Om het aantal valse positieven te verminderen, kunnen we onze scanners configureren met de juiste inloggegevens. De scans hebben toegang nodig tot alle vereiste informatie over bedrijfsmiddelen, zodat u nauwkeurig kunt bepalen of er een kwetsbaarheid bestaat.

Waarom treden er valse positieven op?

Er kan een fout-positief optreden wanneer de scanner alleen de configuratie-informatie van servicebanners kan lezen. Een scanner die een Apache-banner leest, kan bijvoorbeeld detecteren dat alleen versie 2.2.15 is geïnstalleerd vanaf de HTTP-banner, zelfs als versie 2.2.15-39 ook is geïnstalleerd en dat de versie een softwarefix bevat die is gebackported.

Een ander voorbeeld is wanneer de scanner de banner leest en de geïnstalleerde versie van SSH detecteert, maar het patchniveau of het besturingssysteem niet kan detecteren. Als de scanner detecteert dat SSH-2 is geïnstalleerd, maar het besturingssysteem niet kan bepalen, kan de scanner in sommige gevallen niet nauwkeurig bepalen of er een kwetsbaarheid bestaat. De kwetsbaarheid kan correct worden geïdentificeerd op één asset, maar is een fout-positief op de andere asset, omdat SSH-kwetsbaarheden op Red Hat SSH mogelijk niet hetzelfde zijn voor andere Linux®-besturingssystemen.

Waarom halen scanners niet alle vereiste informatie op?

Kwetsbaarheidsscanners hebben niet altijd toegang tot de informatie die ze nodig hebben om nauwkeurig te bepalen of er een kwetsbaarheid bestaat. Deze beperking resulteert gewoonlijk in valse positieven.

Kunnen we geauthenticeerde scans instellen?

Momenteel hebben we dit niet geïmplementeerd. In de toekomst kunnen we dit misschien doen.

Waarom worden sommige kwetsbaarheden dubbel geteld?

Sommige kwetsbaarheden kunnen meer dan één keer in de lijst voorkomen, bijvoorbeeld voor verschillende poorten. In uitzonderlijke gevallen kan de software ook een fout gemaakt hebben. Gelieve dit te signaleren, zodat we dit kunnen onderzoeken.

---

In eerste instantie verwijzen we u graag naar
de Tenable website https://www.tenable.com/plugins en
de specifieke CVE pages: https://www.tenable.com/cve.

In tweede instantie

• systeembeheer vragen: https://helpdesk.ugent.be/helpme/
• inhoudelijke vragen m.b.t. de gedetecteerde kwetsbaarheden: stuur gerust een email naar vulnerabilityscanning@ugent.be

---

Het rapport vermeldt veel kwetsbaarheden en u weet niet waar u moet beginnen? U kunt het onderstaande advies volgen:

1. Als de software/server niet meer wordt gebruikt, verwijdert u het asset.
2. Upgrade naar de nieuwste ondersteunde versie van uw besturingssysteem en softwaretoepassing en zorg ervoor dat updates automatisch worden geïnstalleerd.
3. Als de kwetsbaarheid niet kan worden opgelost, past u een uitstekende mitigatiestrategie toe:
   1. Configureer firewallregels om toegang te voorkomen. bijv. beperk de toegang tot de machine: geen internettoegang, of beter alleen toegang vanaf specifieke IP's
   2. Plaats een authenticatiesysteem vóór de service, zodat gebruikers zich moeten authenticeren voordat ze toegang krijgen tot de service.

Kwetsbaarheden met een VPR > 7 of die misbruikt kunnen worden, moeten onmiddellijk aandacht krijgen.

 

---

Wachtwoordauthenticatie voor SSH is minder goed dan sleutelauthenticatie om verschillende redenen:

1. Kwetsbaar voor brute force-aanvallen

• Wachtwoorden kunnen door brute force-tools geraden worden. Zelfs met beschermingen zoals Fail2Ban blijven zwakke wachtwoorden een risico.
• Bij sleutelauthenticatie moet een aanvaller zowel de privésleutel als de passphrase hebben, wat aanzienlijk moeilijker is.

2. Kwetsbaarheid voor datalekken

• Wachtwoorden kunnen gestolen worden via phishing, malware of datalekken.
• SSH-sleutels zijn cryptografische bestanden die niet zomaar gedeeld of gestolen kunnen worden zonder toegang tot het apparaat waar ze staan.

3. Gevoeligheid voor menselijke fouten

• Mensen gebruiken vaak hergebruikte of zwakke wachtwoorden.
• Sleutels worden gegenereerd met sterke cryptografie, waardoor ze veel veiliger zijn dan door mensen gemaakte wachtwoorden.

4. Geen beperking tot één locatie

• Wachtwoorden kunnen vanaf elk apparaat worden ingevoerd, wat het risico vergroot bij compromittering.
• Sleutelauthenticatie vereist toegang tot het apparaat waar de privésleutel is opgeslagen, wat fysieke controle over de toegang versterkt.

5. Geen aanvullende beveiliging

• Wachtwoorden bieden geen extra beveiligingslaag.
• Sleutels kunnen worden beveiligd met een passphrase, wat betekent dat zelfs als een sleutel wordt gestolen, deze zonder de passphrase onbruikbaar is.

6. Geen traceerbaarheid

• Wachtwoorden kunnen door meerdere personen worden gedeeld, waardoor auditing moeilijk wordt.
• SSH-sleutels zijn uniek en kunnen aan specifieke gebruikers gekoppeld worden, wat traceerbaarheid en verantwoording verbetert.

7. Reactieve bescherming vs. Proactieve beveiliging

• Tools zoals Fail2Ban blokkeren aanvallen pas na detectie van verdacht gedrag.
• Sleutelauthenticatie voorkomt aanvallen helemaal omdat toegang zonder de privésleutel onmogelijk is.

8. Schalen en beheer

• Het beheren van wachtwoorden voor meerdere gebruikers of systemen is complex en foutgevoelig.
• Sleutels kunnen centraal beheerd, ingetrokken en vervangen worden zonder gebruikers te storen.

Kortom, sleutelauthenticatie biedt een veel hoger beveiligingsniveau door sterke cryptografie, betere toegangscontrole en minder kwetsbaarheid voor menselijke fouten en aanvallen.

---

Het zelf uitvoeren van een vulnerability scan of het rechtstreeks raadplegen van de resultaten is niet standaard voorzien. Binnen onze organisatie zijn dergelijke scans voorbehouden aan het functiedomein ICT om een uniforme aanpak en optimale beveiliging te garanderen.

Voor IT-contactpersonen die een groot (>10) aantal machines moeten beheren kan er toegang voorzien worden onder bepaalde voorwaarden.

Wil je een scan aanvragen of meer informatie over de mogelijkheden voor jouw omgeving, neem dan contact op met de helpdesk.

---

ssh <hostname> -o PreferredAuthentications=password -o PubkeyAuthentication=no

---