DNS Resolution Required - Aanvullend wapen in strijd tegen malware en botnets

SIDN Labs heeft een prototype ontwikkeld van DNS Resolution Required en daarmee de eerste tests uitgevoerd. De Arnhemse organisatie heeft die techniek bedacht als aanvulling op dns-firewalls om malware en botnets te bestrijden.

Malware en botnets zijn te bestrijden door de IP-adressen en domeinnamen die ze gebruiken bij hun kwaadaardige toepassingen, te blokkeren. De achterliggende basis is dns, het systeem dat ip-adressen koppelt aan domeinnamen. Met dns-firewalls kom je een heel eind om dat soort kwaadaardige toepassingen tegen te gaan, maar ze houden niet alle soorten malware tegen. Bij SIDN Labs bedachten ze daarom een extra beschermlaag: DNS Resolution Required. Voor bepaalde toepassingen kan deze techniek in de toekomst wellicht bijdragen aan de strijd tegen malware en botnets.

Jelte Jansen

"Het idee kwam voort uit een gesprek met een beveiligingsclub uit de medische sector", vertelt Jelte Jansen, research engineer bij SIDN. "Op een gegeven moment ging dat over het feit dat medische apparatuur steeds vaker aan internet hangt. Ze vertelden dat ze daar een mooie dns-firewall voor hadden. Toen dachten wij: maar wat als de malware niet afhankelijk is van de ingestelde dns-resolver? Zo is dat balletje gaan rollen."

Hoe zat het ook alweer met dns? Een client, zoals een browser, wil een website bezoeken en doet een request bij een recursive dns-server van bijvoorbeeld een provider. Die gaat daarop op zoek naar het IP-adres dat bij de naam hoort. Die vraag komt uit bij een authoritative dns-server, de houder van het 'telefoonboek' dat de domeinnamen en bijbehorende IP-adressen bevat. Het antwoord bevat het IP-adres dat bij de opgevraagde domeinnaam hoort, zodat de client de website te zien krijgt.

Dns-malware

Er zijn uit het verleden tal van voorbeelden bekend van kwaadaardige toepassingen die misbruik maken van of via dns. Zo beschreven onderzoekers van de Vrije Universiteit Amsterdam al in 2011 de werking van Feederbot, een botnet dat dns gebruikt als communicatiekanaal met command & control-servers. Of neem Multrigrain, dat creditcardgegevens van betaalpunten via dns-servers binnenhengelde, of DNSMessenger, dat kwaadaardige Powershell-commando's in textrecords van dns verstopte.

Het projectteam van de SIDN richt zich op malware die 'iets doet met dns' of zijn eigen dns implementeert. Zo kon bijvoorbeeld Cutwail zelf de dns-resolutie uitvoeren en maakten de Nugache- en Storm-botnets dankzij p2p al nagenoeg helemaal geen gebruik van dns. Ook was er al malware die dns-configuraties aanpast, zoals DNSChanger, dat zo doorverwees naar zijn eigen nameservers om advertenties te kunnen injecteren.

"Het is het zoveelste puzzelstukje om tot een veiliger internet te komen""We hebben niet gemeten hoe groot de verspreiding is van dit soort malware". vertelt Jansen. "Er zijn diverse varianten. De basis van dit idee was dan ook niet dat dit het grootste probleem is dat nu opgelost moet worden. Vaak wordt gebruikgemaakt van dns-firewalls, maar die hebben weinig nut als de malware geen dns gebruikt. Als hier een oplossing voor komt, is dat het zoveelste puzzelstukje waarvan wij denken dat het kan helpen om tot een veiliger internet te komen."

Afbeelding over de werking van dns die de FBI publiceerde bij de waarschuwing voor DNSChanger.
Deze malware wist tot 2011 miljoenen systemen te infecteren en gedupeerden die de pagina's van onder andere Apple iTunes of Netflix bezochten, door te sluizen naar eigen advertentiepagina's. Daarmee werden miljoenen dollars verdiend.

Botnets frustreren met rpz

Paul Vixie,
bedenker van rpz

Dns-firewalls werken met lijsten van als kwaadaardig aangemerkte of potentieel schadelijke IP-adressen en domeinnamen. De werking kan bijvoorbeeld berusten op een response policy zone of rpz. Dit is een open standaard die door Paul Vixie van het Internet Systems Consortium is ontwikkeld en die in 2010 werd gepresenteerd bij de beveiligingsevenementen Black Hat en Defcon. Het idee is dat beveiligingsdiensten nagenoeg in real time feeds met die schadelijke adressen en namen kunnen aanleveren, waarop recursive DNS-servers zich kunnen abonneren. Dit moet de beveiliging up-to-date houden in een tijd waarin het zo eenvoudig is voor scammers, spammers en andere criminelen om snel en massaal kwaadaardige domeinamen te registreren.

Die servers kunnen vervolgens met die aangeleverde lijsten voorkomen dat clients de host- en domeinnamen bereiken of die redirecten naar een walled garden, of ze kunnen de toegang blokkeren tot hostnamen die refereren aan schadelijke IP-adressen. Dit kan de werking van botnets en andere malafide toepassingen frustreren. Rpz stond een tijd op de lijst om als IETF-internetstandaard aangewezen te worden, maar die behandeling lijkt stil te liggen. Hoe dan ook is het rpz-mechanisme geïmplementeerd in de dns-software BIND van het Internet Systems Consortium en in de lichtgewicht resolver Unbound van NLnet Labs.

Dit systeem werkt, maar omzeilen is ook weer niet heel moeilijk. "Dns is gewoon pakketjes sturen en antwoord krijgen. Dus het is niet heel moeilijk voor malwareschrijvers om zelf een mini-dns-resolvertje te bouwen, zeker als dat maar een beperkte functionaliteit nodig heeft", meldt Jansen. "Dat zie je bijvoorbeeld bij Cutwail. Dat is gelukkig heel makkelijk te herkennen aan het soort pakketjes dat het stuurt, maar je ziet dus ook dat het zelf dns-requests stuurt naar authoritative dsn-servers en niet via de resolver gaat." Met simpelweg al het verkeer naar poort 53 blokkeren wapen je je alleen tegen een deel van dit soort malware.

DRR: werken met automatische allow-listing

DNS Resolution Required, of DRR, garandeert dat geen van de genoemde soorten malware nog langer kan communiceren via netwerken, door alleen verkeer toe te staan van en naar IP-adressen uit dns-antwoorden. Met andere woorden, een client in een netwerk kan standaard geen contact maken met externe IP-adressen, totdat een geautoriseerde dns-resolver antwoord geeft. DRR geeft de dns-firewall vervolgens instructie de poort te openen, zodat het dns-antwoord de client kan bereiken.

De stappen bij toepassing van DNS Resolution Required

Dat klinkt vrij eenvoudig en doet denken aan allow-listing. "De basis is ook een soort allow-listing, maar dan geautomatiseerd. Meestal denk je bij toegangslijsten aan lijsten die handmatig of via bestaande lijstjes geconfigureerd worden, maar dat is hier niet het geval. Het idee is dat het hier automatisch gebeurt doordat er gewoon nette dns-requests worden verstuurd. Het heeft wel het meeste nut als je het gebruikt met een resolver die zelf wel block- of allow-listing gebruikt."

"Bij voice-over-ip gaat het mis"De basis kan dan eenvoudig lijken, de brede uitvoering in de praktijk is dat niet, want er komen al gauw moeilijkheden om de hoek kijken. Jansen: "Een van de grote moeilijkheden is dat het niet algemeen toepasbaar is. Als je bijvoorbeeld voice-over-ip-apparaten neemt, die wisselen onder water ook IP-adressen uit. Daar komt geen dns-request aan te pas en dan gaat het mis doordat het verkeer geblokkeerd wordt." DRR blokkeert alle verkeer dat niet gebruikmaakt van dns om IP-adressen te vinden, waarmee bijvoorbeeld ook peer-to-peernetwerken standaard geblokkeerd worden. En er zijn meer beperkingen.

Zo werkt DRR standaard ook niet in combinatie met DNS over Https of DNS over TLS, omdat een DRR-systeem dns-verkeer moet kunnen inzien en dit dus onversleuteld moet blijven. Het idee was toch juist om technieken als DoH en DoT meer te gaan inzetten om de beveiliging op te schroeven? "Ja, op zich wel", erkent Jansen. "De ene beveiligingstechniek staat de andere soms in de weg. Je ziet dat ook bij intrusion detection, die ook dns-requests monitort en dat gaat ook stuk bij DoH of DoT. Aan de andere kant, er is ook malware die DoH gebruikt. Die werkt dan ook niet, want alle poorten zijn geblokkeerd."

Er zijn oplossingen voor de combinatie met versleuteld dns-verkeer, volgens Caspar Schutijser, die samen met Jansen aan het DRR-project werkt. "Als je per se als client dns met encryptie wilt gebruiken, zou het een idee zijn om je DRR-systeem op de een of andere manier te koppelen aan je eigen dns-resolver, zodat DRR wel weet welke queries er zijn gedaan en je toch encryptie op dns kunt toepassen."

Voorbeeld van een scenario waarbij de DRR als uitbreiding van een lokale resolver werkt en zo over benodigde DNS-informatie beschikt. Daardoor kan DRR ook werken als het DNS-verkeer versleuteld is. Bron: SIDN Labs

Het risico dat DRR zelf een kwetsbaar punt in de keten wordt, achten Jansen en Schutijser niet groot. Jansen: "Alles wat je draait, is natuurlijk een potentiële aanvalsvector. Je moet er wel voor zorgen dat de werking in een DRR-systeem bijvoorbeeld geen buffer overflows bevat." Maar in principe is de werking volgens hem heel simpel, wat de kans op fouten verkleint. Schutijser: "Het prototype was enkele honderden regels code en dan hou ik het aan de hoge kant. We gebruiken dan wel dns-library's waar van alles onder valt, maar de code om die library's aan elkaar te knopen, was niet groot."

Weinig processorkracht, veel queries

Jansen en Schutijser hebben twee prototypes van DRR-systemen gemaakt. Die draaiden op werkstations en op de router van Jansen in een thuisnetwerk. Veel processorkracht vergt het volgens hen niet. Internetbrowsen was wel merkbaar langzamer dan normaal, vanwege de vele dns-queries die hierbij uitgestuurd werden. DRR onderschept alle dns-verkeer en moet firewallregels aanpassen voordat het dns-antwoord bij de client afgeleverd kan worden. Dat kost tijd.

Een shortcut zou zijn om het DNS-antwoord alvast aan de client door te geven en het aanpassen van de firewall ondertussen op de achtergrond uit te voeren. Dat levert volgens Schutijser echter een brakke gebruikerservaring op, omdat de kans dan aanwezig is dat het pakket de client al bereikt heeft voordat het IP-adres op de allow-lijst is gezet, waardoor het verkeer alsnog geblokkeerd zou worden. De prototypesoftware maakt daarom gebruik van de Python-module NetfilterQueue, die pakketjes op basis van een iptables-regel eventjes tegenhoudt. "We denken dat als je iets als IP-sets gebruikt in plaats van iptables of nftables voor de rechtstreekse configuratie, het snelheidsprobleem een heel stuk minder wordt", aldus Jansen.

Dan is er nog het probleem van de aangepaste firewallregels: hoelang moeten de open- en sluitopdrachten van kracht blijven? SIDN Labs bedacht hier time-to-live-waarden voor te gebruiken, zodat de regels slechts een bepaalde periode geldig blijven en de firewall daarna weer sluit. Sommige verbindingen moeten echter langere tijd openblijven. Bij de prototypes is er daarom voor gekozen om TCP-verkeer als voortzetting van een bestaande verbinding altijd toe te staan. Anders zou het DRR-systeem openstaande verbindingen moeten monitoren om deze open te kunnen houden bij een verlopen ttl.

Door de beperkingen die de SIDN-initiatiefnemers zijn tegengekomen, denken ze dat de extra beveiliging van DRR het best tot zijn recht komt bij internet-of-thingstoepassingen en medische apparaten die met internet zijn verbonden. Jansen: "Je zou verder aan industriële scada-beheersystemen kunnen denken, maar dan vooral om te voorkomen dat je systeem nadat het al gehackt is, nog meer narigheid gaat uithalen." Met de verwachting dat het aantal internet-of-thingsapparaten met vele miljoenen gaat toenemen in de komende jaren, zou DRR weleens een schakel in de beveiligingsketen kunnen worden. Daarvoor moet echter nog veel gebeuren. Als het idee omarmd wordt, moeten bijvoorbeeld routerfabrikanten warm gemaakt worden om het mechanisme te implementeren in hun software.

Een vinkje in je routersoftware

"Ik vermoed dat als het opgepikt gaat worden, dat eerst door de fabrikanten van beveiligingsrouters gaat gebeuren. Als we zelf een openbaar prototype maken, zal dat in de vorm van een OpenWRT-package zijn. Misschien dat het dan opgepikt kan worden, maar zover hebben we nog niet vooruitgedacht", aldus Jansen.

Hij vervolgt: "In de ideale situatie wordt het een vinkje in je routersoftware. In het ultieme flexibele scenario wordt het een vinkje in de router- en in je dns-software, want dan kun je het dus wel met DoH en DoT gebruiken. Schutijser: "En mogelijk ook een optie in je routersoftware om per apparaat in te stellen of je het wel of niet wilt. Stel je hebt laptops waarmee je wilt videobellen, maar je hebt ook slimme lampen, dan wil je het misschien alleen voor die lamp doen en niet voor de laptop."

Schutijser: "Als mensen er wat in zien, zou ik ook wel een serieuzer prototype voor apparaten met weinig resources willen maken. Ik heb de huidige prototypes op mijn laptop draaien, maar komende versies zou ik op mijn router willen hebben." De uiteindelijk software zou dan in het ideale geval niet in Python, maar in een lowleveltaal ontwikkeld worden. De huidige software is nog te alfa en SIDN verstrekt deze alleen op verzoek, maar eventuele komende prototypes worden door SIDN direct publiekelijk, open source beschikbaar gesteld, beloven Jansen en Schutijser.

Reacties (40)

[laurens0619]

Ik snap het artikel niet helemaal.
Als je zeker wilt dat je DNS server gebruikt wordt, dan kun je toch al het verkeer op poort 53 routeren naar je eigen dns? Zoals mensen ook met pihole doen:

iptables -t nat -A PREROUTING -i br0 -p udp ! --source piholeaddress ! --destination piholeaddress --dport 53 -j DNAT --to piholeaddress

iptables -t nat -A PREROUTING -i br0 -p tcp ! --source piholeaddress ! --destination piholeaddress --dport 53 -j DNAT --to piholeaddress

[mdavids]

Als je zeker wilt dat je DNS server gebruikt wordt, dan kun je toch al het verkeer op poort 53 routeren naar je eigen dns?

Klopt, maar dat is nog maar een deel van het verhaal. Je wilt daarnaast ook dat er van die DNS gebruikt wordt gemaakt, om te bepalen of toegang tot bepaalde IP-adressen wordt toegestaan. Dus niet dat malware rechtstreeks op basis van IP-adressen communiceert, zonder gebruik te maken van DNS. Sommige legitieme software doet dit trouwens ook en dat is meteen een van de uitdagingen, zoals het artikel ook beschrijft. Want standaard is alles geblokkeerd.

[Reactie gewijzigd door mdavids op 26 juli 2024 17:04]

[laurens0619]

Ah dus het idee is
- Als er een dns response komt van een dns partij die filtering doet, dan zou het wel legitiem zijn en mag het doorgelaten worden?

Als dat zo is:
Kun je dan niet beter de block list van die dns partij direct gebruiken en de inverse hiervan alleen als allow-list toepassen?

[mdavids]

Ah dus het idee is

Eh... nee

Het idee is dat deze speciale DNS resolver fungeert als een soort sleutel naar het internet (omdat hij een firewall kan aansturen).

Dus stel, 'example.nl' heeft IP-adres 198.51.100.80 en een applicatie wil daar naartoe. Dan volgt een DNS-vraag, naar de speciale DNS-resolver van dit verhaal dus. So far so good.

Als die resolver 'example.nl' vertrouwd, zet 'ie de firewall open voor dat adres en kan de applicatie door. Standaard is de toegang voor alle IP-adressen echter geblokkeerd. Als de domeinnaam op een blokkeer-lijst staat, blijft de toegang gesloten.

Daarmee gaat deze speciale resolver verder dan standaard DNS-filters. Daarmee kun je weliswaar ook voorkomen dat de applicatie die de DNS-vraag stelt het IP-adres 198.51.100.80 terugkrijgt. Maar het voorkomt niet dat een malafide applicatie het DNS-filter omzeilt, bijvoorbeeld omdat 'ie het IP-adres hard-coded al aan boord heeft of gebruik maakt van een publieke resolver elders op het internet (zoals 8.8.8.8).

Bij de speciale resolver uit dit verhaal staat alles dicht en kun je hem niet omzeilen (want dan kom je gewoon het internet niet op). Je moet dus echt eerst langs deze speciale DNS-resolver als je überhaupt het internet op wil (vandaar de naam: DRR = DNS Resolution Required). En alleen als 'example.nl' vertrouwd wordt, geeft de resolver het bijbehorende IP-adres terug en opent het de firewall.

Dit staat of valt natuurlijk met de kwaliteit van de blokkeer-lijst. Als 'example.nl' malafide is, maar hij staat nog niet op de lijst, kan de applicatie er nog steeds verbinding mee maken.

[Reactie gewijzigd door mdavids op 26 juli 2024 17:04]

[jelte.jansen]

Dat beschermt inderdaad tegen malware die hun eigen DNS doet, en kan zeker ook sterk bijdragen aan de veiligheid. DRR zou ook nog malware tegenhouden die geen DNS over port 53 doet, of die überhaupt geen DNS gebruikt.

[MoonWatcher]

Zou dit type malware dan niet gewoon gebruik gaan maken van dns-over-https naar een eigen DNS server over poort 443 ergens op het internet?

Volgens mij omzijl je als malware provider dan vrijwel alle "beschermingen".
Inclusief dezege uit dit artikel.

[Blokker_1999]

Hoe lang denk je dat die DoH onder de radar van een DRR blacklist zal blijven?

[MoonWatcher]

Ongeveer dezelfde tijd als het duurt om een willekeurige endpoint van een malware provider te vinden en te blokkeren.

Aangezien DNS-over-HTTPS aan de buitenkant er niet anders uitzien dan willekeurige SSL traffic is het goed te verstoppen.

Je kunt het endpoint zelfs achter CDN achtige services van bekende partijen verstoppen.

Daarnaast moet een malware applicatie vaak toch verbinden naar een command server. Deze communicatie moet hij al verstoppen. Mocht een DNS-over-Https endpoint geblokkeerd raken dan zou hij via de command server een nieuw DNS endpoint kunnen opvragen. Uiteraard gaat de malware applicatie zelf zich ook niet houden aan lijsten van geblokkeerde DNS-over-HTTPS lijsten.

Dus in de praktijk kan dit lang volgehouden worden.

[Kees]

Nee, als iets of iemand een niet vertrouwde dns server gebruikt wil je dat blocken, en alle apparaten die jij in je beheer hebt moet je naar je eigen DNS server wijzen.

Als er dan iets is dat een externe DNS server wil gebruiken dan is dat niet iets wat jij hebt ingesteld, en dat kan dan wellicht malware zijn die jouw dns firewall wil omzeilen op die manier. Dat is dus al genoeg reden om het te blokkeren.

[kozue]

Zoiets gaat al snel je netwerk kapot maken natuurlijk. Corporate VPN (alleen offfice verkeer via VPN, maar alle resolutie via de VPN’s DNS), hostfile regels, online gaming waar een server meestal alleen een IP adres is, DNS caching op clients die langer werkt dan de TTL die de router hanteert, etc. Ik denk niet dat je zoiets ooit op je router voor het hele netwerk in wilt stellen. Het internet is groter dan alleen een beetje webbrowsen.

[thijsjek]

Er wordt dan ook gesuggereerd dat dit voor bepaalde netwerken een ideaal bescherming biedt, en dat er voor thuis gebruik inderdaad niet zomaar gaat werken.
Ideaal als je een industriëel netwerk toch wil moet benaderen via internet. En dan kun je voor net dat soort slimme malware, net de deur op slot doen.

[arjankoole]

Er wordt dan ook gesuggereerd dat dit voor bepaalde netwerken een ideaal bescherming biedt, en dat er voor thuis gebruik inderdaad niet zomaar gaat werken.
Ideaal als je een industriëel netwerk toch wil moet benaderen via internet. En dan kun je voor net dat soort slimme malware, net de deur op slot doen.

ik zie dit in kantoor netwerken (uitgezonderd devs/ops) wel werken. Een van de grootste zwakke schakels zijn normale gebruikers (non-technisch, hoewel ook de techs niet immuun zijn). Die gebruiken op kantoor geen VPN's oid. VoIP zit meestal in een separaat VLAN. Het is toch weer een extra barrière die je kunt opwerpen.

[dutchgio]

Stel je hebt laptops waarmee je wilt videobellen, maar je hebt ook slimme lampen, dan wil je het misschien alleen voor die lamp doen en niet voor de laptop."

Het doel is dan ook niet om je hele netwerk er gebruik van te laten maken, maar specifieke apparaten waarvan de impact niet zo groot is.
En naast die lamp dus bijvoorbeeld ook andere internet-of-things en medische apparaten.

Daarvan zal het netwerkverkeer een stuk 'logischer' zijn en kun je dit dus gebruiken om malware die naar buiten wil communiceren te voorkomen.

[jurroen]

Ik zou dit zelf inderdaad niet op het hele thuisnetwerk uitrollen, mede omdat ik dan anderen over mij heen krijg. Echter, dit zou ik wél op bepaalde delen willen toepassen. Daarvoor heb ik ondersteuning nodig van pf(4) en divert(4).

De prototypes maar eens uit elkaar trekken en zien of ik dit kan ontwikkelen (of meehelpen in de ontwikkeling ervan)

Ik gebruik zelf OpenBSD, maar OPNsense en pfSense (en andere BSDs) zouden dit ook gelijk kunnen gebruiken.

[Reactie gewijzigd door jurroen op 26 juli 2024 17:04]

[defixje]

En waarom zouden de malware en bot makers niet overstappen op IP-only ipv domeinen? Dan heeft dit toch allemaal geen nut meer want het heeft dan geen DNS meer nodig, of zie ik dat verkeerd?

[jurroen]

Omdat het in de regel makkelijker / sneller is om een IP adres offline te halen. Voor de ontwikkelaar van een botnet heeft het nog een ander voordeel, het IP adres sowieso met een bepaalde interval wisselen, wat analyse ook bemoeilijkt.

Let wel, de meeste malware gebruiken meerdere domeinnamen, met wisselende extensies. Dus het is ook niet zo eenvoudig als met een lijstje bij één partij, zoals ICANN aankloppen

[arjankoole]

Let wel, de meeste malware gebruiken meerdere domeinnamen, met wisselende extensies. Dus het is ook niet zo eenvoudig als met een lijstje bij één partij, zoals ICANN aankloppen

hoewel dat wel precies is wat shadowservers.net doet. En vervolgens heb je een hele prachtige blip in je netwerk, want als je traffic naar specifieke shadowserver IP's ziet gaat, weet je dat er wat in je netwerk zit (wat al dan niet onschadelijk is gemaakt - maar even goed een big red flag)

[mdavids]

En waarom zouden de malware en bot makers niet overstappen op IP-only ipv domeinen?

Het idee is dat elk IP-adres standaard wordt geblokkeerd. En alleen een (goedgekeurd) DNS-request kan de toegang tot een IP-adres openzetten.

[jelte.jansen]

Dat is juist het idee hierachter; sommige malware omzeilt DNS-blocklists door over te stappen naar IP-only. Door alles te blokkeren waar niet eerst een DNS-request naar je (vertrouwde) resolver aan vooraf is gegaan stop je daarmee juist die IP-only malware om verdere schade te doen.

[livePulse]

openbaar prototype

Geef je dan niet alles al weg?

[xbeam]

SIDN is geen commerciële bedrijf ( ook acteren ze wel steeds vaker zo ) en eigenlijk is dit soort ontwikkelen al buiten hun mandaat waarvoor ze door ons domein houders worden gefinancierd.

[Reactie gewijzigd door xbeam op 26 juli 2024 17:04]

[arjankoole]

SIDN is geen commerciële bedrijf ( ook acteren ze wel steeds vaker zo ) en eigenlijk is dit ontwikkelen al buiten hun mandaat waarvoor ze door ons domein houders worden gefinancierd.

SIDN beheert root-nameservers. Dus DNS beveiliging mechanisms vallen perfect binnen hun mandaat. Toko's als RIPE, SIDN, etc hebben altijd al stapels opensource contributies gedaan.

[Reactie gewijzigd door arjankoole op 26 juli 2024 17:04]

[xbeam]

Daar verschillen de meningen nog al over. De vraag is waar stopt het beheer en waar begint product development wat prima aan commerciële partijen overgelaten kan worden. Want wat ze hier presenteren is niets nieuws en is gewoon als commercieel product verkrijgbaar bij de verschillende online security bedrijven.

Dat zegt niet dat ik persoonlijke voor thuis gebruik niet blij met een opensource oplossing ;-) wat ook de insteek was van mijn reactie waarom ze het als opensource publiceren en voor hun zelf houden en commercieel uitbuiten (wat ze met hun cybersecurity tak/ service wel proberen )

[Reactie gewijzigd door xbeam op 26 juli 2024 17:04]

[arjankoole]

de oorsprong van SIDN is academisch. Dat merk je aan veel dingen, zoals dit. Alles maar aan commerciële partijen overlaten is niet wat je wil.

Partijen als SIDN, RIPE maar ook AMS-IX hebben een vested interest in de algehele veiligheid van internet. Ze diskwalificeren omdat ze niet commercieel zijn is echt heel erg onszelf in de voet schieten.

[xbeam]

Ik diskwalificeer ze helemaal niet op kennis. Ik zet alleen vraagtekens bij de huidige uitbreiding van hun cybersecurity afdeling die momenteel probeert te concurreren met bestaande commerciële partijen en dat deze ongevraagde ambitie betaald wordt met de verhoging van je domein beheer afdragen kosten hoe afgelopen jaren.

Alles-in-één oplossing CyberSterk

De alles-in-één oplossing CyberSterk lanceerden wij op 26 november 2019. CyberSterk voorziet duidelijk in de behoefte van ondernemers om op een begrijpelijke manier inzicht te krijgen in de kwetsbaarheden in hun bedrijfsnetwerk en -website. Daarnaast biedt de oplossing ook direct hulp bij gesignaleerde problemen.

Uit onderzoek bleek namelijk dat de meeste mkb-bedrijven hun basisbeveiliging niet op orde hebben. Dat komt vooral omdat het ze ontbreekt aan tijd, kennis of financiële middelen hiervoor. Drijfveer voor SIDN was om een maatschappelijk probleem aan te pakken en mkb-bedrijven weerbaarder te maken. Met de ontwikkeling en introductie van CyberSterk is hiervoor een goede basis gelegd.

Dit is nu niet iets wat met veilig beheren van mijn domeinnamen te maken heeft daarnaast is het ook niet zo dat er nog geen commercieel partijen actief zijn op dit gebied en dat deze partijen daar geen geld voor ontwikkeling en bewustwording instoppen.

Geld vrij maken voor bewustwordingscampagne en af en toe een opensource donaties vindt ik nog kunnen maar wat ze nu doen is echt concurreren met netwerk beveiligingsbedrijven en is wat mij persoonlijk betreft net een stapje buiten hun mandaat.

[Reactie gewijzigd door xbeam op 26 juli 2024 17:04]

[arjankoole]

SIDN is geen commercieel bedrijf. We zijn professioneel en zakelijk, maar streven naar maximalisatie van onze toegevoegde waarde voor de Nederlandse maatschappij en economie. Het rendement van nieuwe producten zetten we in om de positie van .nl te versterken

lijkt mij prima passen binnen het mandaat. Namelijk een toevoeging zijn voor .nl

Dat er al commerciële partijen actief zijn, en er nog meer bij komen is ook geen argument.

Ik zet alleen vraagtekens bij de huidige uitbreiding va hun cybersecurity afdeling die momenteel probeert te concurreren met bestaande commerciële partijen en dat ongevraagde ambitie betaald wordt met de verhoging van je domein beheer afdragen kosten het af gelopen jaren.

Dat is niet aan jou om te bepalen. Jij wil een .nl domein, en betaald daarvoor. Hoe SIDN daarna dat geld exact inzet is aan hun, en voornamelijk het bestuur van. De ISP aftap toko heeft zich ook gediversifieerd naar een security door een wasstraat aan te bieden. Uiteindelijk dient het nog altijd een gemeenschappelijk nut.

[xbeam]

Dat er al commerciële partijen actief zijn, en er nog meer bij komen is ook geen argument.

Ow zeker Wel , dan hadden ze geen dot NL beheer stichting moet beginnen maar één cybersecurity BV

[Reactie gewijzigd door xbeam op 26 juli 2024 17:04]

[arjankoole]

[...]

Ow zeker Wel dan hadden geen dot NL beheer stichting moet beginnen maar één cybersecurity BV

SIDN bestond al voor de term cybersecurity gecoined was. Dus nee, HEEL slecht argument.

[xbeam]

Ik heb niet over een hipe term voor de het oude netwerk en computer beveiligingsbedrijf branche :-) maar over de rechtsvorm en oprichtings-statute van deze stichting. Maar nu is het duidelijk dat je vanuit je mening en onderbuik het meer doen dan strikt noodzakelijke doel van deze stichting goed praat.

[Reactie gewijzigd door xbeam op 26 juli 2024 17:04]

[arjankoole]

Nee, ik begrijp gewoon niet waar je naar toe wil.

Het een sluit het ander totaal niet uit.

[kodak]

De belangrijkste reden van bestaan van SIDN en beheer van .nl zijn niet al die randzaken waar ze geld in kunnen stoppen wat ze met .nl verdienen, maar het in stand houden en promoten van .nl. Dat promoten en in stand houden niet uitsluit dat ze randzaken kunnen doen is niet het discussiepunt, maar wel waar de grens ligt. Een grens die sommige mensen liever niet bespreken. Feit is dat SIDN heel veel geld ontvangt voor .nl diensten en dat investeerd in zaken die niet duidelijk aansluiten op de behoefte van de vele klanten, maar meer op wat SIDN en medewerkers bevalt. Om het een beetje ontopic te houden: het ontbreekt aan duidelijkheid waarom dit werkelijk een oplossing is door niet in te gaan waarom het gebrek aan een oplossing een goed uitgangspunt is. Deze edge apparatuur hoort in de eerst plaats al niet zomaar verbinding met onbekende systemen te hebben. Dat het kan wil niet zeggen dat er dus maar een nieuwe oplossing met dns moet komen, maar dat je eerst toont wat er in de basis mis is en wat daarbij aan bestaande ontwikkeling ontbreekt. Maar de voorkeur lijkt om geld in een idee met dns als oplossing te stoppen, om een nieuw idee te hebben om dns .nl en sidn te promoten en het te veel aan geld uit te geven. En voor nu het argument komt dat je er in verhouding niet zoveel voor betaald of het vast wel ergens goed is en je ook een ander tld kan nemen: dat is niet waarom klanten betalen. Die betalen voornamelijk voor .nl en dat promotie zorgt dat ze het terug zien in waar ze duidelijk iets aan hebben zoals beveiliging waar duidelijk behoefte aan is door aantoonbaarheid van noodzaak.

[xbeam]

https://www.kvk.nl/orders...1&productgroep=Uittreksel

[CAPSLOCK2000]

Mooi initiatief, ik ben al langer op zoek naar iets dat hier op lijkt en dan met name de combinatie van een DNS- én IP-blokkade. De wereld wordt steeds dynamischer waardoor IP-gebaseerde firewalls steeds moeilijker worden. Door het tekort aan IPv4-adressen, content delivery networks en "de cloud" veranderen de gebruikte adressen steeds sneller.
Manieren om DNS te filteren of queries te beperken bestaan al langer, maar je kan er niet op vertrouwen dat iedere verbinding begint met een DNS-query.

Zo'n systeem lijkt me met name voor IoT-achtige zaken zoals een TV die het netwerk gebruikt voor een paar handige features (zoals Netflix) en een hele hoop vervelende zaken zoals het tracken van wat je kijkt.

Ik ga er dus eens goed naar kijken.

[Rob Coops]

Ik denk dat dit wel handig kan zijn in beperkte setting, zo als een medisch netwerk waar bijvoorbeeld de IC apparatuur aan hangt. Daar kun je redelijk eenvoudig bepalen dat je nooit zonder DNS verbinding mag maken en hoef je ook geen rekening te houden met tientallen andere dingen zo als VoIP of P2P. Ook zijn er genoeg bedrijfstoepassingen denkbaar waarbij je zeker weet dat in dit deel van je netwerk hoe dan ook nooit VoIP of P2P etc zal zijn en alle software gewoon met DNS records werkt (een gemiddelde Amazon/Google/Microsoft/FB server farm lijkt me een goed voorbeeld.

Ik zie hier wel wat in al vraag ik me af wat de impact is op latency wanneer er veel traffic is naar veel verschillende domeinen. Ik kan me niet geheel aan het idee onttrekken dat er een punt komt waarop dit simpel weg te langzaam zal zijn voor bepaalde toepassingen omdat het hoe dan ook tijd zal kosten om de extra controle uit te voeren en dat toch echt voor problemen zou kunnen zorgen als je dat maar vaak genoeg per seconde een nieuw request doet.

[beerse]

Nu gaat dit verhaal over communicatie via dns requests. Hoe verhoudt dat zich met dns-via-https?

Op basis van de iso-osi stack snap ik wel dat het voor alle dns zou moeten gelden, maar als het gaat om herkennen van dns-verkeer op de lijn, dan is dns-over-https niet eenvoudig te herkennen, zeker niet als het naar 'vreemde' dns servers gaat.

[Consequator]

Volgens mij is het gevaar dat hier misbruik van wordt gemaakt door de overheid groter dan wat het op gaat leveren als dit buiten privé netwerken gebruikt gaat worden.

[arjankoole]

Volgens mij is het gevaar dat hier misbruik van wordt gemaakt door de overheid groter dan wat het op gaat leveren als dit buiten privé netwerken gebruikt gaat worden.

Niet echt, want dat merk je vrijwel direct. De overheid heeft veel slimmere manieren die totaal niet, of nauwelijks opvallen.

Deze toepassing werkt op je thuisnetwerk ook niet, het zou waarschijnlijk gelijk problemen veroorzaken. Dit is wel prima geschikt voor zwaar beveiligde netwerken die nog net wel met internet mogen praten. (het beste is natuurlijk een volledig los netwerk, wat dat totaal niet kan)

[kodak]

De toepassing lijkt bedoeld voor apparatuur die je hoe dan ook al goed onder controle hoort te hebben wat betreft verbinding mogen maken.

Waarom zou je dan een lapmiddel gaan maken bij een oplossing die in beginsel al niet zomaar bedoeld is om genoeg controle te geven?

Die belangrijke vaak dedicated interne apparaten horen alleen te communiceren met geautoriseerde systemen, op een vooraf gedefinieerde wijze. Dat is hoe dan ook meer tegen houden dan een dns firewall je tegen gaat beschermen. Het probleem is niet het gebrek van de dns firewall, maar gebrek aan gepaste beveiliging en controle.

[TheDutchChief]

En hoe verhoudt dit zich dan weer tegenover DoH waarbij het verkeer niet eens meer over port 53 loopt. Medische apparatuur zou je misschien nog in een vlan kunnen zetten waarbij port 443 weer geblokkeerd wordt, maar kan dat bij alles? Je TV etc.?