Om DANE te kunnen gebruiken is het gebruik van een andere veiligheidseis nodig: DNSSEC. De toepassing van DNSSEC is gangbaar: 100% van de waterschappen en provincies passen dit toe. Ook is het bij 99% van de gemeentedomeinen in gebruik. Cybersecuritybedrijven en politieke partijen zijn hier minder goed in met respectievelijk 79% en 72%.
Microsoft ondersteunt DANE vanaf maart 2024 middels opt-in. Vanaf juli 2024 is het standaard. Het is dus een beetje flauw om dit nu af te keuren op duizenden domeinen, terwijl het over een maand goed is in te stellen.
Met deze uitzondering komen bijna alle onvoldoende metingen te vervallen. De exacte getallen worden in de komende dagen te staan op basisbeveiliging.nl.
Daarom wordt er vanaf 15 februari een uitzondering toegevoegd voor DANE op Microsoft domeinen. Deze uitzondering vervalt automatisch op 1 juli 2024. Dit raakt ongeveer 2000 gemeten domeinen.
We krijgen regelmatig de vraag waarom basisbeveiliging Google Analytics negatief beoordeelt bij haar privacymeting. Er wordt dan verklaard dat Analytics is ingericht volgens de handleiding van de Autoriteit Persoonsgegevens.
De Autoriteit geeft bij tweakers aan geen specifiek advies te geven welke tools voldoen. Dat is sinds 11 augustus 2023 waar, omdat de bewuste handleiding (archief) en de per ongeluk impliciete goedkeuring/promotie toen van hun site is gehaald.
De reden dat wij Google Analytics en dergelijke diensten afkeuren is eenvoudig: Google heeft een tweede belang bij het verzamelen van informatie over bezoekers: verkopen. Dat is niet in het belang van de bezoeker of de organisatie die het product toepast. We zien dat de overheid in 23% van de gevallen Analytics verkeerd inricht.
In dit artikel laten we zien waarom diensten als Google Analytics een probleem zijn, waarom dit probleem ontstaat en blijft bestaan en welke mogelijke oplossingen er zijn voor dit probleem.
Inzicht geven in surfgedrag
Het bijhouden van bezoekersstatistieken en wat bezoekers op een site doen is handig. De eigenaar kan zo zien welke informatie populair is en of de site voldoende wordt bezocht. Er zijn honderden bedrijven die hiervoor diensten aanbieden.
Ieder bedrijf zit anders in elkaar. Sommige verlenen slechts één dienst: inzicht geven in bezoekers en hun gedrag. Andere bedrijven leveren meer producten en diensten om de begroting rond te krijgen. Soms zijn deze activiteiten met elkaar verweven, zoals advertenties en bezoekersstatistieken. Specifiek in het laatste scenario is Google de grootste naam.
Google is groot geworden door de combinatie van uitmuntende technologie met gerichte advertenties. Ze verkopen dus beiden, waardoor ze hun technologie goedkoop of zelfs gratis kunnen aanbieden. Google Analytics (GA) is de tool waarmee bezoekersstatistieken worden verzameld. De verzamelde gegevens worden dus ook gebruikt voor gerichte advertenties op deze bezoekers. Die advertenties zijn vaak pas zichtbaar op een andere website.
Analytics wordt gebruikt door ontelbaar veel organisaties. Het kost snel miljarden om een platform als dit te bouwen, terwijl het goedkoop of zelfs gratis is om te gebruiken. Dit wordt betaald met gerichte advertenties. Sceptici zeggen daarom dat de dienst wordt “betaald met privacy”. Wanneer een overheid kiest om zoiets te gebruiken, betalen hun inwoners dit met hun privacy.
Google zegt zelf met versie 4 te voldoen aan alle eisen. Ze zeggen daarna in hetzelfde artikel waarom dit een wassen neus is. Dat gaan we zo uitleggen.
Omvang van Analytics
Diverse Europese landen verbieden het gebruik van Google Analytics (voor de overheid). Dit zijn Denemarken, Italië, Frankrijk, Noorwegen en Oostenrijk. De reikwijdte van dit verbod wisselt per land, maar het is in ieder geval een signaal om het niet te gebruiken.
Een dergelijk verbod zal ondernemers niet tegenhouden om alsnog een bedrijf te beginnen met ongeveer hetzelfde businessmodel. De focus ligt bij Google omdat dit de grootste speler is. Daarom is Analytics een naam voor het onderliggende probleem: verzamelde gegevens voor iets anders inzetten dan uitsluitend het verlenen van de dienst voor de klant. Dit geldt natuurlijk ook voor andere diensten van Google als YouTube en Google Maps.
Wij meten dat Analytics 1774 keer wordt ingezet bij de overheid. 1038 keer bij de centrale overheid, 676 bij gemeenten en 60 keer bij provincies. Het is de grootste in deze markt voor de overheid. Als we alle diensten van advertentiebedrijven meten, dan zien we bijvoorbeeld dat 70% van de gemeenten (242) zoiets toepast. Wij monitoren daarbij vooral Amerikaanse bedrijven omdat Europese bedrijven nog niet op de bekende volg-mij-niet-lijsten staan.
De dans met de regels
De advertentiemarkt is een miljardenindustrie. Het is van onschatbare waarde, vaak ook bedrijfsgeheim, op welke manieren bezoekers worden gevolgd en hoe gegevens worden gecombineerd.
Bedrijven zoals Google houden zich op een subversieve manier aan de wet: de wet wordt perfect en strikt gevolgd en dus wordt de grens altijd opgezocht. Een belangrijk doel van advertentiebedrijven is dat het onderliggende probleem nooit helder wordt of wordt opgelost. Daarvoor worden verschillende strategieën gebruikt. Drie hiervan zijn:
Werken naar halve regelgeving, certificeringen en audits: regulatory capture
Focus op haakjes om gegevens aan op te hangen: zoals een IP adres
Ieder van deze methodes leggen we hieronder uit. Hierdoor zie je dat deze allemaal geen oplossing zijn.
Wij zeggen hier dus niet dat Google ergens misbruik van maakt of ze iets doet dat niet mag. Juist het tegenovergestelde: men houdt zich dus perfect aan de wet.
Strategie 1: Keuzes
Het aanbieden van keuzes is een gouden greep. Het verlegt de verantwoordelijkheid naar de kiezer en kiezen gaat gegarandeerd fout. Iedere keer dat dit fout gaat wordt er geld verdient.
Het maken van keuzes bij Analytics gaat zowel fout bij de aanbieder (de overheid) als bij de gebruiker (de burger):
Bij de aanbieder, de overheid, meten we dat er 419 keer verbinding wordt gelegd met een doubleclick domein van Google Ads, zonder dat er toestemming is gegeven. In 23% van de gevallen is Analytics dus verkeerd ingericht. Blijkbaar is dit te lastig voor professionele organisaties met hoogopgeleide ICT-medewerkers.
De gebruiker, de burger, krijgt dagelijks vele malen de keuze of ze gevolgd wil worden. De vraag is dan “wil je alle functies op deze website gebruiken?”. Toestemming geven is vaak makkelijker dan weigeren. Hier treed moeheid en conditionering op, waardoor men toch op “OK” klikt. De vraag om toestemming is vaak doorspekt met slimmigheden waardoor men eigenlijk geen kans heeft om te weigeren.
Die keuze voorleggen aan de burger is geregeld in de Telecommunicatiewet. De wet richt zich op alle mogelijke technische vormen van volgen. Omdat de meestgebruikte techniek een cookie is, wordt dit onderdeel van de wet vaak de cookiewet genoemd. Dit is dus onvolledig.
Strategie 2: regulatory capture
Het opstellen van regels, certificering en audits is een andere gouden greep. Hierbij snijdt het mes aan twee kanten. Linksom: voor nieuwe organisaties wordt het lastiger om toe te treden tot de markt. Rechtsom: je hebt zelf al de markt en de inkomsten, hierdoor kan je aan de nieuwe regels voldoen ongeacht hoe complex deze zijn.
Het beste is dus om regels te stimuleren waar alleen jouw organisatie aan kan voldoen. Bijvoorbeeld het verbieden van het volgen van gebruikers via een specifieke methode om profielen aan op te hangen (zgn “haakje”) zoals het IP adres. Dat is prima voor Google, omdat ze hiervoor andere haakjes kan aanwenden door schaalgrootte en bereik. Een voorbeeld hiervan staat in methode 3.
Het ontstaan en stimuleren van regulatory capture gebeurt bijna vanzelf. Feit is namelijk dat regelgevers vaak achter de feiten aanlopen: ze moeten leren omgaan met een altijd veranderende realiteit. Dat levert een spanningsveld, want je wil de maatschappij niet lamleggen of tegenhouden. Het opstellen van nieuwe regels, deze goed verwoorden en het probleem begrijpen is een vreselijk lastig en langdurig proces. Hier liggen bijvoorbeeld kansen voor denktanks en lobbyisten om de focus te verleggen naar iets wat logisch lijkt, maar het niet is.
Dit artikel gaat verder na de afbeelding met methode 3.
242 gemeenten gebruiken een dienst van een (Amerikaans) tracking bedrijf. 101 doen dat niet.
Strategie 3: Verbod op een specifiek haakje
Op de privacy-pagina van versie 4 van Google Analytics, staat letterlijk: “IP-address data is used solely for geo-location data derivation before being immediately discarded“.
In plaats van een persoon gaat het nu over een locatie: een adres, gezin, straat, wijk et cetera. Inderdaad niet herleidbaar tot één specifiek persoon: dus geen persoonsgegeven. Dat iets niet herleid tot een persoon wil dus niet zeggen dat deze informatie onschadelijk of betekenisloos is.
Google weet van alle IP adressen ter wereld namelijk de fysieke locatie. Dat komt omdat iedereen dit aan hen verteld. Bijvoorbeeld door het maken van een route in Google Maps of Waze, het zoeken naar informatie over de wijk, het bekijken van je huis op Streetview, het bezoeken van websites in de buurt zoals die van een hobbyclub, sportclub of gemeente (Analytics staat overal). Er is geen partij ter wereld die zo goed een locatie aan een IP adres kan koppelen als Google.
Zelfs als je je best doet om jezelf te beschermen hoeven je buren dat niet te doen. En omdat het IP adres van de buren bijna dezelfde is als die van jou heeft dat impact op je. Een schoolvoorbeeld is dat in armere wijken duurdere goederen verkocht kunnen worden omdat dit een status geeft. Iedereen helpt dus onbewust elkaars profiel op te stellen.
Een regelgever zou het gebruik van fysieke adressen kunnen verbieden, maar dan is er weer een ander haakje om gegevens aan te koppelen. Het is onmogelijk om dit probleem op een technische manier te stoppen, de belangen zijn simpelweg te groot.
Qua handhaving is er ook enorm veel ruimte, maar handhavers krijgen natuurlijk te weinig capaciteit, mandaat en kennis omdat de ernst van het probleem niet breed genoeg wordt onderschreven.
Oplossen van het echte probleem
Een verbod op een specifiek bedrijf of specifieke technologie lost niets op. Daarvoor zijn de belangen te groot. Maar er is wel hoop. Zo op het eerste gezicht zien we drie oplossingen, maar er zijn er vast meer.
A: Betere wetgeving?
Het echte probleem zit in de hoek van doelbinding: dat gegevens op geen enkele andere manier mogen worden ingezet dan het doel. Dus ook niet worden afgeleid, gecombineerd, verkocht en dergelijke.
Waarschijnlijk is dit juridisch ongelofelijk lastig op te schrijven. De cookiewet was hiervoor een eerste poging, maar biedt onvoldoende bescherming. Het leverde een van de subversieve oplossingen: keuzes.
De overheid kan natuurlijk wel voor zichzelf eisen opstellen en e.e.a. verbieden. Dat heeft natuurlijk weinig invloed op het grote geheel, maar het is een goed begin.
Een wettelijke oplossing is in ieder geval niet morgen geregeld, hoewel die behoefte en noodzaak er wel is.
B: Alternatieve bedrijven met betere waarden?
Privacy kan worden vereist bij de toepassing en aankoop van producten en diensten in allerlei markten. Maar ook dat is erg lastig: juist organisaties met een tweede doel zullen vaak aan de eisen voldoen omdat de eisen niet doordacht zijn vastgelegd.
Het is belangrijk om het onderliggende probleem te begrijpen: het beschermen van zoveel mogelijk mensen. Dit kan onder andere door te eisen dat gegevens maximaal voor 1 doel mogen worden ingezet en alle andere gronden te weigeren.
Gelukkig zijn er al tientallen bedrijven die dit al garanderen. Denk bijvoorbeeld aan Piwik Pro, Monsido en dergelijke. Deze bedrijven zijn helaas niet altijd transparant over hun prijzen. Matomo is dat wel. Hier wordt per bezochte pagina betaald. Voor 1 miljoen hits, een behoorlijk populaire site, is dat 160 euro per maand.
Zou Google haar Analytics tak afsplitsen naar een bedrijf met maar één enkel belang, dan is er geen bezwaar om het te blijven gebruiken. Dan moeten ze er wel (meer) geld voor moeten gaan vragen. Wedden dat niemand de daadwerkelijke prijs hiervoor wil betalen?
Wat ook helpt is de wetenschap dat 95% van de verzamelde gegevens in tools als Analytics niet relevant zijn voor dagelijkse sturing. Het verzamelen hiervan is dus overbodig werk.
C: Zelf maar iets draaien?
Zelf een tool draaien is een optie. Tweakers.net heeft onlangs een overzicht gepubliceerd van vier verschillende tools die Analytics kunnen vervangen.
De haken en ogen aan deze aanpak zitten niet in de technologie maar in de organisatie. Wanneer een organisatie zelf iets draait zitten hier verantwoordelijkheden aan. Zo moet er een server worden geregeld, deze moet worden ingericht en onderhouden, de software moet ingericht worden zodat het aan de wet voldoet en moet ook nog regelmatig (en soms acuut) worden bijgewerkt. Ook dan moet er nog steeds betaald worden aan dit soort projecten: anders worden kwetsbaarheden niet opgelost of is draait het op een verouderd (kwetsbaar) systeem. De medewerkers die dit uitvoeren krijgen natuurlijk salaris. Alles bij elkaar gaat het snel over een behoorlijk bedrag.
Zelf iets draaien is dus niet altijd even economisch of duurzaam. Alle haken en ogen kosten al snel meer dan iets afnemen bij een van de vele dienstverleners. Dat is namelijk de business case.
Wat keurt basisbeveiliging?
Basisbeveiliging keurt sinds april 2023 privacy op twee dingen: of een site op zichzelf staat en, wanneer dat niet zo is, of er verkeer wordt gestuurd naar bekende advertentiebedrijven.
De lijst met advertentiebedrijven komt van het Amerikaanse bedrijf Disconnect.Me. Zij verkopen diensten waarmee privacy vergroot kan worden. Hun lijst met bedrijven is openbaar, zodat iedereen dit kan inzien, aanpassen en gebruiken.
Het zal je niet verbazen dat op deze lijst voornamelijk Amerikaanse bedrijven staan. Ook neemt dit diensten mee waarbij Google zegt géén privacygevoelige informatie te verzamelen zoals bij het aanbieden van lettertypen (maar wel alle andere mogelijke data natuurlijk).
Op de techreuzen na opereren de organisaties op de lijst niet in Nederland. In de EU en Nederland zijn er wel bedrijven actief die op die lijst horen. Denk bijvoorbeeld aan Shoppingminds uit Hilversum. Op hun voorpagina pronken ze met de slogan: “Sell it Better”. Er is één overheid die dit gebruikt, maar mogelijk is dit contractueel goed geregeld.
In de toekomst gaat basisbeveiliging dus ook Europese / Nederlandse bedrijven die meerdere belangen hebben bij het vergaren van gebruikersdata afkeuren.
Tot slot
Gebruik dus geen diensten van bedrijven die bezoekersgegevens voor andere doelen inzetten dan de door jouw de gevraagde dienst. En doe dit natuurlijk zelf ook niet.
In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.
Poort 8080 is gesloten (of toch open)
We kregen een korte mail met de melding: “Poort 8080 staat niet open”. Dus wij tikken in onze browser: http://[gemeentesite].nl:8080. In plaats van ‘geen gehoor’ wordt de gebruiker doorgestuurd naar de site van een gemeente. Daarna proberen we de site http://[gemeentesite].nl:9090, en daar gebeurd niets.
Conclusie: op poort 8080 gebeurd wel iets, dus deze poort staat open met iets overbodigs. We kunnen niet zien wat en of dit een uitzondering waard is. Dus de conclusie ‘overbodige poort’ blijft staan.
Screenshot bij het bezoeken van het hoofd-domein op dit adres op :8080. De melding op deze pagina zegt dat je mogelijk iets bijzonders moet hebben gedaan om geblokkeerd te worden. Daaronder valt dus ook gewoon bezoeken 🙂
Fix voor uitzondering G1 certificaten
De overheid geeft een certificaat uit dat by design niet wordt vertrouwd in browsers. Dit is het G1 certificaat. We hebben al wat jaren code in Basisbeveiliging die hiervoor een uitzondering toevoegt. Of… dat dachten we.
We ontvingen een mailtje met de vraag of we een G1 certificaat konden uitzonderen. We hadden zoiets van: dit doen we toch al?
Dit was het begin van een paar uur lang debuggen. Uit de logs konden we halen dat deze uitzondering is aangeroepen na de ‘niet vertrouwd’ conclusie van de TLS meting. We hebben de code erbij gepakt en het met de hand aanroepen van alle functies ging goed.
We hebben de code lokaal en op de server gedraaid als allerlei gebruikers: werkt altijd. We hebben extreem gedetailleerde logging toegevoegd aan deze code en we zagen dat alleen op de server, tijdens het meten via een worker, een specifieke SSL foutmelding optrad.
De conclusie is dat een van de componenten om parallel te kunnen meten (“gevent” voor de nerds) de SSL bibliotheek aanpast wat kan zorgen voor ander gedrag. Nadat we de worker hadden omgezet naar ‘prefork’ zagen we dat het probleem was opgelost.
We hebben deze taak dus overgezet naar een prefork worker. Dat kost wat meer geheugen maar dan hebben we wel zekerheid dat de meting goed gaat.
Inmiddels is de helft van de uitzondering-checks er doorheen en zijn er 83 G1 certificaten gevonden. We zien dit certificaat o.a. op sites als api.kvk.nl, isb.rdw.nl, en data.* subdomeinen van gemeenten.
Overzicht van uitzonderingsmetingen op het domein van de vraagsteller…
In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.
Dienst voor medewerkers via het open internet
Een organisatie die graag mailtjes stuurt maakt gebruik van een standaardpakket. Medewerkers kunnen op die omgeving inloggen en de nieuwsbrieven opstellen.
Wij raden aan om dit soort diensten niet publiek te zetten: die vraag was voorgelegd aan de hoster. De hoster geeft aan bang te zijn om deze aanpassing door te voeren. Het zou meer problemen leveren dan het oplost. Dus ze gaan dat niet doen.
Oplossing: In dit geval zien we een Plesk PHP omgeving staan. Beiden zijn bekend en geroemd om hun vele kwetsbaarheden. Dat betekent voor een aanvaller: “Rustig wachten op de dag… van een nieuwe kwetsbaarheid… van een nieuwe kwetsbaarheid“. Dan kan IT weer fijn in het midden van de nacht / carnaval stekkers ergens uit halen, patchen, datalekmeldingen sturen enzovoorts. All in a good days work: maar je kan ook kiezen voor nachtrust, een goede reputatie en een stabiele dienstverlening.
Het is alsof je een deel van de interne organisatie buiten het gebouw naast de ingang zet. In plaats van binnen met verwarming, een beveiligingspoortje en een receptie. Iedereen kan er naartoe lopen en proberen binnen te komen: via gokken op het loginformulier of via een (nieuwe) kwetsbaarheid. Net zoals je bij een bedrijf een veiligheidspoortje hebt, wil je voor de toegang tot dit soort diensten altijd een controle uitvoeren.
Daar is in dit geval ook wel een poging tot gedaan. In plaats van de dienst op het standaard poort 443 aan te bieden, word deze “verborgen” op poort 8443. Dat soort security through obscurity werkt vertragend, maar uiteindelijk niet.
Er zijn diverse manieren om diensten te verbergen voor de buitenwereld. Het mooiste is achter een VPN, waarbij er publiek niets meer te vinden is. Een medewerker logt in op het deel VPN en kan dan naar mailing.intern.belangrijkeorganisatie.nl gaan om het werk te doen. Het is ook mogelijk om toegang op basis van certificaat of IP in te richten: dan kan een buitenstaander zien dat er nog wel *iets* is, maar niet meer wat. Dat is natuurlijk minder mooi en uiteindelijk ook meer werk. Er zijn vast nog wel andere oplossingen te bedenken. Wij gaan altijd voor de optie om zo min mogelijk diensten over het open internet aan te bieden.
Onjuiste header meting
We kregen de melding dat we onterecht bevinden dat bepaalde http security headers ontbreken. We gingen op onderzoek uit.
Oplossing: Hier hebben we inderdaad een fout gemaakt. We stuurde een “Host” header mee, maar hielden geen rekening met dat we konden worden doorgestuurd. Dat betekent dat we de verkeerde site (“Host”) opvroegen nadat we werden doorgestuurd naar een andere site.
We hebben dit aangepast.
Ook zagen we dat we http headers aan het meten waren op sites als http://example.nl:443. Dan sturen we dus met opzet een onversleuteld verzoek naar een versleutelde pagina. Een gemiddelde webserver geeft dan een behulpzame waarschuwing dat dit niet is wat je wil. Om ook daar op headers te controleren gaat wel erg ver, dus dat hebben we even uitgezet. We kijken daar wel naar andere dingen zoals versienummers bijvoorbeeld.
In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.
Schunnige subdomeinen bij de overheid?
Dat de overheid veel sites heeft weten we. Een van onze bezoekers wees ons op een mooie website: platformhoutrook.nl. Er werd gewezen op het bestaan van het subdomein “cleavage.platformhoutrook.nl” op onze site en daarna nog wat andere. Mogelijk is dat niet de bedoeling.
Oplossing: Eerst dachten we: misschien heeft iemand bij de overheid gewoon slechte smaak. Hout… houthakken… cleavage… lame. Maar er blijkt iets anders aan de hand te zijn. In de archieven van het domein blijkt dat er talloze subdomeinen zijn aangemaakt: bustywifey, giggles, friendsworld, sniper en honderden anderen. Op de site zelf staan google ads.
Het is duidelijk dat daar iemand met matige bedoelingen bezig is, en gewoon het domein heeft gekocht. Het platform achter deze site is namelijk in rook op opgegaan opgeheven in 2021 en kort daarna begonnen de problemen. We hebben het domein bij ons op verwijderd gezet en alle onderliggende domeinen geofferd aan onze hamsters. Er is ook een mailtje gestuurd aan de maker van de brondata.
Een paar van de vele subdomeinen op het domein dat nu van een ander is.
Er word aan gewerkt!
Soms krijgen we verklaringen binnen waar we graag iets mee willen, maar niets mee kunnen.
Zo kregen we de melding dat men RPKI aan het toevoegen is op een site. Het duurt nog ongeveer vier maanden voordat dit af is. “De doorlooptijd is hoog, maar het staat op de roadmap.”
Oplossing: Supergoed nieuws dat hieraan wordt gewerkt! Dit is namelijk 1 van de paar laatste oranje metingen bij deze organisatie. So close!
De comply or explain functie is bedoeld voor verklaringen waarbij de afwijking iets veilig of veiliger maakt. Het gaat om iets dat “by design” wordt toegepast. Dat is nu niet het geval, daarom kunnen we de bevinding niet wegstrepen.
Een andere reden is dat we geen toezeggingen of beloften willen verwerken in een uitleg. We hebben dit in een ver verleden wel gedaan en daar werd ook goed gebruik van gemaakt. Maar wat je dan ziet is dat het soms niet of verkeerd wordt opgeleverd: dan staat iets ten onrechte als correct op de site. Dit hebben we dus geschrapt.
In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.
Intrusion attacks bij bezoeken site…
De eerste vraag gaat over een firewall. Deze ziet een intrusion attack als we de website bezoeken via http://. Het verkeer via https werd geweigerd. Dus basisbeveiliging ziet alleen een blokkade-website en dat is niet de site die de beheerder verwachtte.
Oplossing: Als je niet gemeten wil worden, dus bijvoorbeeld ip-restricties toepast, dan moet je dat op alle endpoints doen: ook op http://. Ons vermoeden: De firewall herkent ons gewone bezoek niet als een bekend IP, dus blokkeert dat als ‘intrusion’. Maar we zouden deze website helemaal niet mogen zien natuurlijk, want het is maar een gewoon websitebezoek.
Fortinet firewall blokkeert bezoek aan http:// website
Beheer op een vreemde poort
De tweede vraag ging over een vreemd poortnummer. We geven daar een oranje beoordeling aan. De hoster van de site gebruikte dit poortnummer om beheer uit te voeren via het plesk beheersysteem.
Oplossing: Voor iedere vorm van beheer (van overheidssites) raden we een VPN/afgescheiden netwerk aan. Hierdoor is zo’n beheerpanel niet meer bereikbaar via het publieke internet: dus veel minder mensen die het kunnen vinden en er een aanval kunnen uitvoeren. Er zijn natuurlijk regelmatig kwetsbaarheden in dit soort beheerpanelen: ze geliefd door aanvallers.
Op de schermprint zie je geen 2e factor, wat wel gebruikelijk is voor beheerpanelen. Het kan natuurlijk zijn dat je die vraag pas krijgt nadat je een inlogpoging hebt gedaan… of niet.
