ScanZeker.nl
Transparantie

Methodologie & Bronnen

ScanZeker raadpleegt meerdere externe bronnen en protocollen per scan. Hieronder vind je precies welke databronnen we gebruiken, welke controles we uitvoeren en hoe onze scores tot stand komen.

Twee outputs, één scan

Elke ScanZeker-scan vult twee complementaire views: een lineair rapport en een interactieve kaart. Je hoeft niet te kiezen en je wisselt binnen de resultatenpagina met één klik tussen beide.

APIProtocolDatabaseRFC/Standaard

Website Headers

We checken de instellingen die jouw webserver meestuurt bij elke pagina. Die instellingen bepalen of een browser bezoekers beschermt tegen dingen als phishing, afluisteren en klik-trucs. Als je site de bezoeker doorstuurt (bijvoorbeeld van voorbeeld.nl naar www.voorbeeld.nl en dan naar een beveiligde versie), dan checken we elke tussenstop. Krijgen we geen antwoord omdat er een beveiligingsmuur voor zit? Dan openen we jouw site via een echte browser om dezelfde informatie alsnog op te halen.

Bronnen

  • Protocol
    Directe HTTP(S) verbinding

    Stap 1: GET-request met browser User-Agent, volgt redirect-chain en bewaart security headers uit alle hops

  • Protocol
    Remote browser (Chromium)

    Stap 2 (bij WAF-blokkade): echte headless browser leest response headers na JS-executie. Passeert Akamai, Cloudflare en andere WAFs

  • API
    Mozilla Observatory

    Stap 3 (laatste fallback): HTTP Observatory v2 API als browser en HTTP beide falen

  • RFC/Standaard
    Google CSP Evaluator

    Patronen voor CSP-effectiviteitsanalyse (unsafe-inline, JSONP bypass-domeinen, etc.)

  • RFC/Standaard
    RFC 9116 (security.txt)

    Validatie van /.well-known/security.txt inclusief Contact, Encryption, Policy en Expires

Controles

  • Drielaags scan-keten: HTTP fetch (snel) → remote browser bij WAF-blokkade → Observatory als laatste fallback
  • Remote browser toont "direct gemeten via browser" in de UI, echte headerwaarden, geen extern totaaloordeel
  • Content-Security-Policy (CSP, 15pt) met effectiviteitsanalyse: unsafe-inline/eval, wildcard bronnen, data:/blob: URIs, http: bronnen, bekende JSONP bypass-domeinen (googleapis.com, cdnjs, etc.), form-action en object-src checks
  • CSP-Report-Only herkenning: 50% van de punten als actieve CSP ontbreekt
  • Strict-Transport-Security (HSTS, 10pt) met max-age, includeSubDomains en preload analyse
  • X-Content-Type-Options (9pt), X-Frame-Options (5pt), Referrer-Policy (5pt)
  • Permissions-Policy (1pt), X-XSS-Protection (1pt, legacy)
  • Security headers uit alle redirect-hops worden bewaard (eerste voorkomen wint)
  • WAF/bot-blokkade detectie: bij kleine response (<5KB) + fout-status of WAF-tekst wordt remote browser ingeschakeld
  • SSRF-bescherming: interne/private URLs worden geblokkeerd vóór browser-scan
  • HTTPS redirect, X-Powered-By en Server header lekkage
  • security.txt validatie (RFC 9116) inclusief Contact, Encryption, Policy
  • Directory listing en foutpagina informatielek

SSL/TLS Deep Scan

We testen grondig hoe sterk de versleuteling is tussen bezoekers en jouw website. Dat is wat het slotje in de browser betekent. Niet elke versleuteling is even veilig: oude varianten zijn gekraakt, nieuwere niet. We kijken ook of het certificaat nog geldig is, bij wie het hoort en of er bekende kwetsbaarheden zijn waarop we moeten letten.

Bronnen

  • API
    Qualys SSL Labs

    Industriestandaard voor SSL/TLS-beoordeling

  • Protocol
    Directe TLS-scan (fallback)

    Eigen TLS-handshake als SSL Labs niet bereikbaar is

Controles

  • SSL Labs Grade (A+ t/m F)
  • Protocol-ondersteuning (TLS 1.0 t/m 1.3, SSL)
  • Forward Secrecy
  • HSTS-configuratie
  • OCSP Stapling
  • Heartbleed, POODLE, BEAST, FREAK, Logjam, DROWN, ROBOT
  • Cipher suite sterkte
  • Certificaat-chain validatie

E-mail Beveiliging

Oplichters kunnen proberen mails te sturen die eruitzien alsof ze van jouw bedrijf komen (spoofing). We checken of je de instellingen hebt staan die dat tegenhouden. Drie maatregelen werken samen: SPF zegt welke servers namens jou mogen mailen, DKIM zet er een digitaal waarmerk op, en DMARC zegt wat er moet gebeuren als een mail die twee controles faalt. Verstuur je geen mail vanaf dit domein? Dan checken we of je dat expliciet hebt dichtgezet.

Bronnen

Controles

  • Kernscore (100 punten): SPF (25pt), DMARC (30pt), DKIM (25pt), MX (20pt)
  • SPF record aanwezigheid en policy (-all vs ~all vs ?all)
  • DKIM selectors en sleutelsterkte (2048-bit RSA of ed25519)
  • DMARC policy (none/quarantine/reject) en rapportage (rua)
  • MX records, fallback en provider-detectie
  • Extra hardening (informatief, geen scoreimpact): MTA-STS, TLS-RPT, BIMI
  • No-mail domein detectie: SPF -all zonder includes + geen MX = apart scoringmodel

DNS Beveiliging

DNS is het telefoonboek van internet: het vertaalt een domeinnaam naar het adres van de server die de website draait. We checken of jouw telefoonboek-regels goed beschermd zijn. Als die beveiliging ontbreekt, kan een aanvaller bezoekers stiekem naar een nep-versie van jouw site sturen zonder dat ze het doorhebben.

Bronnen

  • Protocol
    DNS queries (SOA, NS, AAAA, CAA)
  • API
    Google DNS-over-HTTPS

    DNSSEC-validatie via AD flag, DNSKEY en DS records

  • API
    Cloudflare DNS-over-HTTPS

    Fallback DNSSEC-validatie via AD flag

  • API
    Cloudflare RPKI API

    Route Origin Validation (ROV) voor BGP-beveiliging

  • Protocol
    DNSSEC validatie

    Multi-provider check: AD flag (Google + Cloudflare), DNSKEY records (type 48), DS records (type 43)

Controles

  • DNSSEC inschakeling en validatie (20pt, kernmaatregel tegen DNS-spoofing)
  • Nameserver redundantie (20pt)
  • SOA record aanwezigheid (15pt)
  • CAA records voor certificaatuitgifte beperking (12pt)
  • IPv6-ondersteuning via AAAA records (3pt, bonus, moderniseringssignaal)
  • RPKI route origin validatie (5pt, geavanceerd, niet hard straffen bij onbekend)
  • DANE/TLSA records (3pt, zeer geavanceerd, bonus)
  • DNS-provider detectie voor contextbewuste aanbevelingen

Server Exposure

Servers hebben allemaal "deuren" die open of dicht kunnen staan (poorten). Sommige deuren horen open te zijn (bijvoorbeeld voor je website), andere horen juist dicht omdat er gevoelige dingen achter zitten (databases, beheer-panelen). We kijken welke deuren er openstaan, wat erachter draait en of daar bekende problemen mee zijn. We checken ook of externe bronnen dit IP-adres al gemeld hebben als verdacht, zodat open deuren die er al in het vizier zijn zwaarder meetellen.

Bronnen

  • API
    Shodan

    Betaalde licentie voor poorten, CVE's, services en OS-fingerprints (passieve cache)

  • Protocol
    TCP-verificatie

    Lichte actieve TCP-handshake op door Shodan gerapporteerde poorten om de cache te bevestigen op moment van scan

  • API
    AlienVault OTX

    Open threat intelligence (pulse feeds en tags), gebruikt als context-versterker

  • API
    AbuseIPDB

    IP-abuse rapportage en confidence score, gebruikt als context-versterker

  • API
    NVD (NIST CVE-database)

    Versie-gebaseerde CVE-verrijking voor whitelisted producten (nginx, apache, openssh, redis, elasticsearch, mongodb, docker)

Controles

  • Open poorten en services, inclusief control-panel poorten (cPanel 2082/2083, WHM 2086/2087, Webmail 2095/2096, DirectAdmin 2222, Plesk 8443, Webmin 10000)
  • Lichte TCP-verificatie per Shodan-poort: handshake bevestigt of de service nu daadwerkelijk antwoordt (Live bevestigd / Niet meer bereikbaar / Niet live bevestigd). We proberen alleen wat Shodan al rapporteert, breiden de attack surface niet uit, met 2,5s timeout en max 20 poorten op risico-prioriteit (Kritiek > Hoog > Middelmatig)
  • Interstitial-detectie: cPanel JS-challenges en Cloudflare bot-checks worden vertaald naar begrijpelijke labels
  • Bekende CVE-kwetsbaarheden via Shodan + NVD-verrijking per service-product
  • Threat-intel correlatie: AbuseIPDB (≥25% confidence) of OTX-pulses worden gekoppeld aan open beheer-/database-/control-plane services
  • Context-versterker bumpt risico-label naar Hoog voor: SSH, RDP, SMB, MSSQL, PostgreSQL, MySQL, VNC, LDAP, SNMP, NFS
  • Context-versterker bumpt risico-label naar Kritiek voor: Docker API, Kubernetes API, kubelet, Jenkins, Redis, MongoDB, Elasticsearch, Memcached, CouchDB
  • Threat-intel zonder open kwetsbare service blijft informatief, niet alarmerend
  • CDN/proxy-detectie via ASN, organisatie, rDNS (Cloudflare, Fastly, Akamai, etc.)
  • CDN-standaardpoorten worden herkend en niet meegeteld in de score
  • Shared infra detectie: provider-herkenning en domein-telling op IP-niveau
  • False positive filtering: compromised-tags en EOL-OS op gedeelde hosting
  • Per-service AuditDetail: aparte mapping voor Elasticsearch, Redis, MongoDB, RDP, SMB, Docker API, Kubernetes API, kubelet, Jenkins, VNC, X11, Memcached

Technologie Stack

Elke website draait op software: een webserver (zoals nginx of Apache), vaak een CMS (zoals WordPress), een framework en soms extra tools. We kijken welke software aan de buitenkant zichtbaar is. Als je site te veel prijsgeeft over welke versie je draait, maak je het hackers makkelijker om bekende zwakke plekken te zoeken.

Bronnen

  • Protocol
    HTTP header fingerprinting

    Server, X-Powered-By, X-Generator, en 40+ specifieke headers (X-Akamai-*, cf-ray, x-amz-cf-id, x-vercel-id, x-nf-request-id, etc.)

  • Protocol
    HTML/DOM patroonherkenning

    Meta tags, script sources, CSS classes, inline patronen

  • Protocol
    Set-Cookie fingerprinting

    PHPSESSID, JSESSIONID, ak_bmsc (Akamai), laravel_session, connect.sid, etc.

Controles

  • WAF-detectie: Cloudflare (cf-ray), Akamai (headers + Bot Manager cookies), Imperva/Incapsula, AWS WAF, Azure WAF (Front Door + App Gateway), Google Cloud Armor, Fastly NGWAF, Sucuri, Barracuda, F5 BIG-IP, FortiWeb, Wallarm. Europese alternatieven: OVHcloud (Frankrijk), Scaleway (Frankrijk), Bunny Shield (Slovenië), G-Core Labs (Luxemburg), CDN77 (Tsjechië)
  • CDN-detectie: Cloudflare, Akamai, Fastly, AWS CloudFront, Azure Front Door, KeyCDN, StackPath, Bunny.net, OVHcloud, Scaleway, G-Core Labs, CDN77, Vercel, Netlify, TransIP
  • Hosting-detectie: Vercel, Netlify, Fly.io, Render, Railway, Heroku, Google App Engine, Deno Deploy
  • Webserver fingerprinting: Nginx, Apache, Microsoft IIS, LiteSpeed, OpenResty, Caddy, Envoy, Gunicorn, Uvicorn, Kestrel
  • Framework/CMS detectie: WordPress, Drupal, Shopify, Next.js, Nuxt.js, React, Vue, Gatsby, Laravel, Django, Flask, ASP.NET, Ruby on Rails, Express.js
  • Taaldetectie via headers en cookies: PHP, Java, Python, Ruby, Node.js.NET
  • Platform-aware analyse (managed hosting en CDN-platformen worden anders beoordeeld)
  • Server header informatielek beoordeling
  • Directory listing detectie
  • Error page disclosure controle
  • Third-party script inventarisatie per extern domein (eigen subdomeinen worden correct als first-party herkend)
  • Subresource Integrity (SRI) controle per extern script
  • Supply chain risico via trust-tiers: grote providers (Google, Cloudflare), open-source CDNs, analytics/tracking, onbekende domeinen

Domein Beveiliging

Een domeinnaam is geregistreerd bij een partij die het voor je beheert (de registrar). We checken hoe oud dat domein is, wie het beheert, en of er sloten op staan die voorkomen dat iemand het stiekem overneemt. Voor subdomeinen (zoals admin.voorbeeld.nl) kijken we naar de gegevens van het hoofddomein, want subdomeinen worden niet apart geregistreerd.

Bronnen

  • Protocol
    WHOIS protocol

    Directe WHOIS-query via whois servers

  • Protocol
    RDAP (Registration Data Access Protocol)

    Moderne opvolger van WHOIS via IANA bootstrap

Controles

  • Domeinleeftijd
  • Registrar informatie
  • DNSSEC ondertekening (via WHOIS)
  • Privacy/WHOIS bescherming
  • Registratiedatum

Reputatie Check

We vragen aan verschillende organisaties of ze jouw domein of server-adres al eerder als verdacht hebben geregistreerd: phishing, malware, spam of misbruik. Als Google, Microsoft of grote anti-spam-diensten je markeren als kwaadaardig, krijgen bezoekers waarschuwingen in hun browser en belanden je mails in de spambox. Alleen bronnen met een goede reputatie tellen mee, bekende ruisbronnen laten we bewust weg om valse alarmen te voorkomen.

Bronnen

  • API
    Google Safe Browsing

    Realtime threat-database die Chrome, Firefox en Safari gebruiken voor waarschuwingsschermen bij phishing en malware

  • Database
    Spamhaus ZEN

    SBL, XBL en CSS gecombineerd, primaire bron (zen.spamhaus.org)

  • Database
    Barracuda Central

    Barracuda Reputation Block List, primaire bron (b.barracudacentral.org)

  • Database
    Spamhaus DBL

    Domain Block List, primaire bron (dbl.spamhaus.org)

  • Database
    SURBL

    Spam URI Reputation Block List (multi.surbl.org)

  • Database
    URIBL

    URI Black List voor phishing/spam (black.uribl.com)

  • Database
    SpamCop

    Aanvullende bron, gebaseerd op spam-meldingen (bl.spamcop.net)

  • Database
    Composite Blocking List

    Aanvullende bron, botnets en malware-infecties (cbl.abuseat.org)

Controles

  • Google Safe Browsing v4: phishing (SOCIAL_ENGINEERING), malware, ongewenste software (UNWANTED_SOFTWARE), potentieel schadelijke applicaties (PHA)
  • Bij Safe Browsing-hit: zware score-penalty (-50), risk level forced naar Kritiek, top-level waarschuwingsbanner, géén automatische F zodat één bron het hele model niet kaapt
  • IP-reputatie tegen 4 DNSBL databases
  • Domein-reputatie tegen 3 URI blacklists
  • Strikte filtering van false positives (Spamhaus PBL, cloud-resolver errors)
  • Onderscheid primaire bronnen vs. aanvullende signalen

Certificaten

Elk SSL-certificaat dat ooit voor jouw domein is uitgegeven wordt openbaar gelogd in een publiek register. We kijken welke certificaten er in dat register staan. Dat geeft een beeld van welke partijen namens jou certificaten hebben aangevraagd. Een onverwacht certificaat kan een teken zijn dat iemand anders zich probeert voor te doen als jouw organisatie.

Bronnen

Controles

  • Totaal aantal uitgegeven certificaten
  • Wildcard certificaten
  • Laatste uitgever (CA)
  • Geldigheidsduur
  • Verdachte of onverwachte certificaten

Subdomains & Infrastructure

Naast je hoofddomein (voorbeeld.nl) bestaan vaak allerlei subdomeinen (mail.voorbeeld.nl, staging.voorbeeld.nl, oud.voorbeeld.nl). Soms vergeten teams die, en vergeten subdomeinen met verouderde software zijn een bekende manier waarop aanvallers binnenkomen. We zoeken in drie publieke bronnen welke subdomeinen er bestaan, checken welke nog leven, en signaleren risico's zoals verweesde namen die iemand kan overnemen of vergeten loginpagina's. Op verzoek kun je per subdomein een diepere analyse starten waarbij we ook kijken naar TLS-config, ontbrekende security-headers, login-pagina's en wat de buitenwereld over die specifieke server weet.

Bronnen

  • Database
    crt.sh (Certificate Transparency)

    Primaire CT-bron, breedste dekking

  • API
    Certspotter (SSLMate)

    Tweede CT-bron, dekking als crt.sh niet beschikbaar is

  • API
    AlienVault OTX (passieve DNS)

    Derde bron met observaties uit malware-sandboxes en passieve DNS-collectoren, vangt subs die niet in CT-logs staan

  • Protocol
    DNS wordlist enumeratie

    Test 200+ veelvoorkomende subdomeinnamen, fallback bij volledig falen van CT-bronnen

  • Protocol
    TCP reachability check

    Verbindingstest op poort 443 en 80 (5s timeout) om daadwerkelijke bereikbaarheid te bevestigen

  • Protocol
    CNAME resolution

    Detecteert dangling CNAMEs naar externe services

  • Protocol
    HTTP fingerprinting

    Verificatie van onbeheerde services (Heroku, S3, Azure Traffic Manager, GitHub Pages, Vercel, etc.)

  • Protocol
    Reverse DNS (PTR records)

    Detecteert hosting provider via rDNS patronen

  • Protocol
    IP range matching

    Fallback voor bekende CDN/cloud CIDRs (Cloudflare, Vercel, Fastly, etc.)

  • API
    Shodan Host API (deep-scan)

    Per-IP enrichment in fase 2: ports, banners, ASN, indicatieve CVEs. Apart van apex-exposure scan; per uniek non-CDN/non-private IP, met 24u cache.

  • API
    NVD CVE-database (deep-scan)

    Banner-versie → bekende CVEs voor 8 whitelisted producten. Top 5 per service, gesorteerd op CVSS-score, 24u cache per CPE-string.

Controles

  • Fase 1: drie CT-bronnen + DNS-wordlist parallel, met circuit-breaker per bron en wall-clock budget van 50s
  • Drielaags status: bereikbaar (TCP connect ok), DNS actief (resolvt maar niet bereikbaar op 80/443), inactief (geen DNS)
  • Sorteer op risico: TAKEOVER → RISICO → CHECK (sensitive+bereikbaar) → INFO (sensitive+DNS) → overige bereikbaar → DNS actief → inactief
  • Risicobadges in tabel: CHECK (amber, sensitive+bereikbaar), INFO (grijs, sensitive+DNS), RISICO (amber, potentiële takeover), TAKEOVER (rood, bevestigd)
  • Gevoelige subdomeinen (admin, staging, test, etc.) met gedifferentieerde scoring: bereikbaar -5pt, DNS-only -2pt
  • Subdomain takeover detectie via CNAME + HTTP-fingerprinting (15+ services), met onderscheid bevestigd kwetsbaar vs verificatie nodig (Azure Traffic Manager-uitzondering)
  • Hosting provider identificatie (AWS, Azure, Google Cloud, Vercel, Hetzner, etc.)
  • CDN detectie via ASN-lijst (Cloudflare, Fastly, CloudFront, Akamai, BunnyCDN, Azure CDN, Google CDN, KeyCDN, CDNetworks, Limelight)
  • SaaS platform detectie (Microsoft 365, Google Workspace, Shopify, etc.)
  • Nederlandse hosters (TransIP, Hostnet, Antagonist, Mijndomein, LeaseWeb)
  • Fase 2 (deep-scan, max 15 hosts): TLS-versie + cipher per host, ontbrekende headers (HSTS, CSP, X-Frame-Options), login-detectie via homepage-scrape + 44 standaardpaden parallel
  • Fase 2 host-exposure: per uniek non-CDN/non-private IP een Shodan-host-call. Private/loopback/CGNAT-IPs worden vooraf gefilterd. CDN-IPs (op basis van ASN) krijgen alleen een context-label, geen findings, omdat Shodan-data daar generiek en niet zinvol is.
  • Fase 2 ASN-vergelijk: subdomein op andere ASN dan apex = aandachtspunt (amber chip), niet automatisch risico. Tekst: "controleer of dit bewust onderdeel is van de architectuur".
  • Fase 2 NVD CVE-enrichment: alleen voor whitelisted producten (nginx, Apache HTTPD, OpenSSH, PHP, WordPress, MariaDB, MySQL, PostgreSQL), top 5 CVEs per service gesorteerd op CVSS V3.1/V3.0/V2 score, expliciet als indicatief gelabeld met backport-disclaimer (distros backporten security fixes zonder versie-string te wijzigen).

Datalekken

Als een website (bijvoorbeeld van een leverancier) gehackt wordt, komen wachtwoorden van gebruikers vaak op straat te liggen. We kijken of e-mailadressen die eindigen op jouw domein voorkomen in bekende datalekken of op computers die besmet zijn geweest met wachtwoord-stelende malware. We maken onderscheid tussen medewerkers en klanten, omdat medewerkersaccounts vaak gevoeliger zijn voor een bedrijf dan een enkele klant.

Bronnen

Controles

  • Datalekken per bron
  • Gelekte datatypes (wachtwoorden, e-mail, IP, etc.)
  • Infostealer-infecties met accounttype-onderscheid: medewerkers (organisatierisico) vs gebruikers (bezoeker's apparaat besmet)
  • Severity op basis van accounttype: medewerkers-accounts wegen zwaarder dan gebruikersaccounts
  • Beveiligingsimpact correctie alleen bij medewerker-infostealer signalen, niet bij gebruikers-only
  • Paste dumps met gelekte data

Cookies & Privacy

We checken welke cookies je site plaatst vóórdat de bezoeker ergens op heeft geklikt, en welke tracking-scripts al meteen meedraaien. In Europa moet je mensen toestemming vragen voordat je tracking-cookies plaatst. We openen de site met een echte browser om precies te meten wat er gebeurt voor iemand de cookie-popup ziet of ermee interacteert.

Bronnen

  • Protocol
    HTTP Set-Cookie headers

    Stap 1: cookies die de server direct meegeeft (= vóór consent)

  • Protocol
    Remote browser (Chromium)

    Stap 2 (bij WAF-blokkade): echte browser verzamelt cookies na JS-executie, inclusief cookies die pas na page load verschijnen

  • Protocol
    HTML/script patroonherkenning

    Detecteert 40+ tracking platforms en 26+ consent tools

  • Protocol
    JavaScript bundle analyse

    Downloadt en parst JS-bestanden voor verborgen tracking en consent-code

  • Protocol
    Preconnect/DNS-prefetch hints

    Onthult tracking-domeinen in initiële HTML

  • Database
    Cookie knowledge base

    Classificatie van 100+ bekende cookies (platform, categorie, retentie)

  • Database
    Bekende consent wall domeinen

    DPG Media (nu.nl, ad.nl, etc.), Mediahuis (telegraaf.nl, etc.), RTL/Talpa

Controles

  • Laag 1: Pre-consent compliance. Worden niet-essentiële cookies geplaatst vóór toestemming?
  • Laag 2: Privacy profiel. Welke tracking is vermoedelijk actief na toestemming?
  • Laag 3: Cookie hygiëne. Lifecycle/retentie (max-age/expires), security flags, third-party domeinen
  • Drie signaalniveaus binnen Laag 1: bewezen (cookie gezet), sterk signaal (script geladen), indicatie (preconnect)
  • Functionele cookies (sessie, CSRF, load balancer) uitgesloten van penalties
  • Consent banner / CMP detectie (26+ platforms, inclusief JS-bundle scan)
  • Bot/WAF-blokkade detectie: bij Access Denied of gelijkwaardige response + bekende uitgevers wordt consent wall aangenomen
  • Cookie lifecycle classificatie (sessie, <24u, <30d, <1j, >1j)
  • Geen consent + tracking: zwaardere scoring dan tracking achter consent

Hoe komt de score tot stand?

De score van ScanZeker is geen optelsom van aanvinkbare controls. In plaats daarvan beoordelen we wat we daadwerkelijk kunnen vaststellen over het risico van een domein. De impact van elke bevinding wordt bepaald op basis van drie principes:

Bevestiging schaalt op
Een signaal uit een externe databron is indicatief. Een bevinding die tijdens de scan actief wordt bevestigd, weegt zwaarder. Een gerapporteerde open poort is een aanwijzing, maar een poort die we zelf via een TCP-handshake kunnen bereiken, is een feit. Hoe sterker het bewijs, hoe groter de impact op de score.
Context dempt of versterkt
Dezelfde observatie kan een andere betekenis hebben afhankelijk van de omgeving. Een beheerpoort op een hostingpaneel (cPanel, Plesk) weegt anders dan dezelfde poort op een losse server. Cookies zonder Secure-flag zijn vaak een hygiëne-issue, maar bij sessie- of authenticatie-cookies wordt het een concreet hijack-risico. Dreigingssignalen, zoals een abuse-score, wegen pas zwaar mee als er ook een technisch aanknopingspunt is dat misbruikt kan worden.
Specificiteit verfijnt
Niet alleen de aanwezigheid van een beveiligingsmaatregel telt, maar ook de kwaliteit ervan. Een basisconfiguratie en een goed doordachte configuratie worden anders beoordeeld. Een eenvoudige CSP levert bijvoorbeeld minder punten op dan een configuratie met nonce en strict-dynamic. Hetzelfde geldt voor e-mailbeveiliging, HSTS en andere controls.

Opbouw van de score

Elke module levert een score van 0 tot 100. De totaalscore is een gewogen gemiddelde, waarbij fundamentele beveiligingsmaatregelen en direct bereikbare risicodiensten het zwaarst meewegen: SSL/TLS (18%), Website Headers (14%), E-mail (12%), Server Exposure (12%), Datalekken (10%), DNS en Subdomains (elk 8%), Certificaten en Technologie (elk 5%), Cookies (4%), WHOIS en Reputatie (elk 2%). Dit vormt de basisscore.

A
85-100
Extern profiel is op orde
B
70-84
Basis op orde, enkele aandachtspunten
C
55-69
Meerdere verbeterpunten gevonden
D
40-54
Zichtbare risico's, opvolging aanbevolen
F
0-39
Verhoogd risico, directe opvolging aanbevolen

De labels beschrijven wat een externe scan kan vaststellen, niet de algehele beveiliging van de organisatie. Een hoge score is een positief extern signaal, geen garantie voor interne weerbaarheid; een lage score is een aanleiding tot opvolging, geen veroordeling.

Daarbovenop wordt een aparte beveiligingsimpact toegepast voor bevindingen die zwaarder wegen dan configuratie alleen, zoals direct bereikbare services of duidelijke risicocombinaties. Deze correctie kan de score met maximaal 25 punten verlagen.

Aandachtspunten naast de score

Naast de gewogen totaalscore toont het rapport een Aandachtspunten-paneel met de meest urgente individuele bevindingen, gesorteerd op ernst (kritiek, hoog, middel, laag). Dit is een aparte prioritering bovenop dezelfde scan-data, bedoeld voor "wat moet ik nu eerst doen". De score geeft de algehele staat aan, de aandachtspunten geven de volgorde van actie aan.

Kritieke aandachtspunten worden altijd zichtbaar getoond (anti-paniek principe: één kritiek mag nooit verstopt zijn). Daarna geldt een minimum van twee zichtbare items in totaal, met de rest achter een "toon meer"-knop. Sommige aandachtspunten worden samengevoegd of vervangen door een sterkere variant, zodat dezelfde bevinding niet dubbel telt.

Beveiligingsimpact

Bovenop de gewogen basisscore past ScanZeker een aparte correctielaag toe voor bevindingen die zwaarder wegen dan configuratiepunten. Deze correctie is contextbewust: bij shared hosting, mailservers of cPanel-omgevingen worden bepaalde poorten en protocollen anders gewogen. Maximaal -25 punten.

De correctie is opgebouwd uit de volgende categorieën:

Kritieke netwerkdiensten
Telnet, RDP, VNC, Redis, MongoDB, Elasticsearch, Memcached: -10 per dienst. MySQL, PostgreSQL, MSSQL: -8 per dienst. FTP: -8 baseline, verlaagd bij TLS-ondersteuning of hosting-context; blijft een aandachtspunt.
Plaintext mail (POP3 + IMAP)
Samen geteld als één bevinding op basis van STARTTLS-advertising: bevestigd op alle poorten = 0 (informatief), gedeeltelijk = -2, alleen 993/995 als alternatief open = -4, geen enkele vorm van versleuteling = -8.
Beheerpoorten
Poorten zoals 2222, 8080, 8443, 8880, 9090: -5 per poort, gecapt op -10. Hoort dit bij een hostingpaneel (cPanel, Plesk, Webmin), dan max -3 (expected gedrag). Met indicatieve CVE of threat-intel signaal schaalt het op tot max -7.
Infostealer signalen
Alleen bij medewerker-accounts en alleen als recent (< 6 maanden): ≥50 accounts = -5, ≥10 = -3, anders -2. Gebruikersaccounts (bezoekers) tellen niet mee voor de organisatiescore.
Shared infra correctie
Bij meer dan 10 domeinen op hetzelfde IP worden poortgerelateerde correcties niet toegepast, omdat open poorten op IP-niveau niet eenduidig aan deze applicatie toe te wijzen zijn.

De eindscore is: basisscore minus beveiligingsimpact (max -25). Beide worden apart getoond in het rapport, zodat je precies kunt zien waar de correctie vandaan komt.

Beïnvloedbaarheid van bevindingen

Een technisch juiste bevinding is niet altijd iets wat jij als domeineigenaar zelf kunt wegnemen. Op gedeelde hostingomgevingen worden bijvoorbeeld mailprotocollen (POP3, IMAP, SMTP) en beheerpanelen (cPanel, Plesk, Webmin) vrijwel altijd door de hostingprovider beheerd. ScanZeker labelt daarom per bevinding wie er daadwerkelijk aan de knoppen zit, zodat fix-advies aansluit bij wat haalbaar is.

Direct
Eigen verantwoordelijkheid. Je kunt het zelf aanpassen in je server-, DNS- of applicatie-instellingen. Dit is de default; er verschijnt geen badge.
Via hostingprovider
De service wordt door je hoster beheerd (typisch mailpoorten op shared hosting). Aanpassen vereist een ticket, een andere configuratie-optie of een overstap naar een ander pakket.
Onderdeel van platformkeuze
De poort is onlosmakelijk verbonden met het hostingplatform zelf (bijvoorbeeld cPanel op 2083 of Plesk op 8443). Afsluiten kan alleen door te wisselen van platform.

De classificatie is bewust conservatief: bij twijfel over de context valt een poort terug op direct, zodat we geen risico's wegmoffelen voor domeinen met eigen beheer. Kritieke services zoals databases, control-plane poorten (Docker, Kubernetes, Jenkins) en plaintext netwerkdiensten (Telnet, RDP, VNC, Redis, MongoDB) blijven altijd op direct staan, ook in shared-hosting contexten. Ze horen nooit op het publieke internet, ongeacht wie de infrastructuur beheert.

In de huidige versie is het label puur informatief: een badge op de poort-kaart maakt duidelijk wanneer een bevinding buiten de directe invloedssfeer ligt, maar de beveiligingsimpact-correctie wordt er nog niet op afgeschaald. Een optionele tier-factor (waarbij indirecte en platform-gebonden bevindingen minder zwaar meetellen) staat voorbereid achter een feature-flag, zodat we de kalibratie eerst tegen een bredere dataset kunnen toetsen voordat we hem activeren.

Threat intelligence als context-versterker

AbuseIPDB en AlienVault OTX leveren signalen dat een IP-adres gerapporteerd is voor misbruik (scanning, brute-force, C2, phishing). Op zichzelf zegt zo'n score weinig, een AbuseIPDB-percentage van 42% leidt zonder context tot vage aanbevelingen. ScanZeker gebruikt deze signalen daarom niet als losse score, maar als amplifier op bestaande exposure-bevindingen: een verhoogde abuse-score telt pas mee als er ook een open beheer- of dataservice is die concreet misbruikt kán worden.

Drempel: AbuseIPDB ≥ 25% of meaningful OTX-pulse
Lager dan vroeger (50%), omdat we alleen tellen bij correlatie. Benigne CA/cert-tags in OTX worden gefilterd om ruis te voorkomen.
Boost-niveau Hoog
Beheer/database services die brute-force gevoelig zijn: SSH, Telnet, RDP, SMB, MSSQL, Oracle, MySQL, PostgreSQL, VNC, LDAP, SNMP, NFS.
Boost-niveau Kritiek
Control plane en services zonder authenticatie standaard: Docker API (2375/2376), Kubernetes API (6443), kubelet (10250), Jenkins agent (50000), Redis, MongoDB, Elasticsearch, Memcached, CouchDB, Hadoop NameNode.
Géén correlatie = informatief
Abuse-score zonder open kwetsbare service blijft zichtbaar maar wordt expliciet gemeld als informatief. Geen alarmtoon, geen zware penalty.
Bron-badge op de port-card
Geboostte services krijgen een visuele bron-badge ("AbuseIPDB + Shodan" of "OTX + Shodan") met tooltip. Het oorspronkelijke risk-label blijft zichtbaar in het audit-trail.
Eén samenvattende banner
Boven de findings-lijst toont een banner welke services geboost zijn en met welke ruwe waarden (X% AbuseIPDB, N OTX-pulses).

Het verschil zit in de framing: niet “IP heeft abuse-score 42”, maar “dit IP wordt actief gescand door aanvallers terwijl jouw Docker API publiek bereikbaar is, dat is geen hypothetisch risico meer”. Voor Google Safe Browsing geldt een vergelijkbare logica, maar zwaarder: een hit is een direct extern signaal dat browsers al een waarschuwingsscherm tonen aan bezoekers. Daarom volgt daar wel een zware score-penalty plus top-level banner, maar géén automatische grade-F zodat één bron het hele model niet kaapt.

Shared infra detectie

ScanZeker herkent wanneer een IP-adres wordt gedeeld met meerdere domeinen. Dit is relevant omdat open poorten op IP-niveau niet altijd toe te wijzen zijn aan de specifieke applicatie die wordt gescand.

De detectie werkt op twee niveaus:

Severity correctie
Meer dan 10 domeinen op hetzelfde IP: poortgerelateerde correcties worden niet toegepast. Alleen het domein-aantal telt.
False positive filtering
Provider-herkenning (Cloudflare, Azure, TransIP, etc.) én domein-aantal worden gecombineerd om Shodan-artefacten als false positive te markeren.

Bij minder dan 10 domeinen op een IP (zoals een kleine gedeelde hostingomgeving) worden poortbevindingen nog steeds meegenomen, omdat de kans groot is dat de poorten daadwerkelijk bij de gescande applicatie horen.

Mogelijke Aanvalspaden

Naast losse bevindingen combineert ScanZeker signalen uit meerdere modules tot mogelijke dreigingsscenario's. Dit toont niet alleen wat er mis is, maar hoe het samen een aanvalspad zou kunnen vormen.

Belangrijke kanttekening: dit zijn scenario's op basis van observeerbare signalen, geen bevestigde kwetsbaarheden. Ze zijn bedoeld als startpunt voor verificatie door een beveiligingsprofessional, niet als vaststelling dat een aanval daadwerkelijk mogelijk is.

Account Takeover
Gelekte credentials + zwakke e-mail auth, open webmail of publiek identity-endpoint (SSO/ADFS/login)
Phishing & Spoofing
Ontbrekende SPF/DMARC + geen CSP header
Server Exploitatie
Open poorten + bekende CVE's + misbruikt IP
Database Direct Bereikbaar
Open DB-poort + versiedetectie + datalekken + CVE's
Remote Access Publiek Bereikbaar
RDP/VNC/Telnet open + gelekte credentials
Verouderde SSH-server
OpenSSH < 8 + brute-force risico bij datalekken
Verhoogd Risico via Externe Scripts
Externe scripts zonder SRI + geen CSP
Onversleutelde Mailprotocollen
POP3/IMAP plaintext + gelekte credentials
Subdomain Takeover
Dangling CNAME naar verlopen service (Heroku, S3, Azure, etc.)
Gevoelige Subdomeinen Publiek Zichtbaar
Staging/admin subdomains publiek bereikbaar

Elk aanvalspad krijgt een severity (hoog risico, verhoogd, aandacht) en een concreet advies. Dit helpt bij het signaleren en prioriteren van risico's.

Uitvalbestendigheid

Alle externe API-bronnen zijn optioneel. Als een bron niet beschikbaar is (door rate limits, onderhoud of netwerkstoringen), gaat de scan gewoon door met de overige bronnen. De score wordt dan berekend op basis van de beschikbare data.

Bij WAF/bot-blokkade (zoals Akamai, Cloudflare challenge pages) worden headers niet leesbaar via een standaard HTTP-verzoek. In dat geval wordt een externe headless browser ingezet die de WAF passeert met een echte TLS-fingerprint en JavaScript-executie. Lukt ook dat niet, dan dient Mozilla Observatory als laatste fallback voor de headerscore. Het rapport toont de gebruikte meetmethode: "direct gemeten" (HTTP), "direct gemeten via browser" (headless Chromium), of "Observatory" (extern totaaloordeel). Bij cookies wordt bij WAF-blokkade eveneens de browser ingezet om cookies na JS-executie te verzamelen. Als fallback wordt bij bekende uitgevers (DPG Media, Mediahuis) een consent wall aangenomen.

Start een scan