Nyt værktøj skal gøre det lettere at teste it-sikkerheden på dit domæne

Hmm.

Forbindelsen er usikkert når jeg ikke har IPv6 på min linie eller min server?

At der kommer en advarsel er vel i orden, men at testen fejler? Det har da ikke noget med sikkerhed at gøre om man har IPv6 eller ej.

Der er potentielt ting man ikke kan tilgå, men hvordan kan det blive et sikkerhedsproblem?

Vi snakker om www.sikkerpånettet.dk ikke www.har-jeg-adgang-til-alt-på-nettet.dk

Det sidste har staten jo allerede sørget for at vi ikke har jfr dns-blokeringen som staten forsøger sig med.

/Henning

Læser man teksten syntes jeg der er en del forbehold for forhold de ikke kan, fx cipher rækkefølgen.

https://weakdh.org/ siger at DH-2048 er sikkert, men her er det ikke sikkert, hvad skal man dog tro på, når nu der er masser af forbehold det ene sted.

Forbindelsen er usikkert når jeg ikke har IPv6 på min linie eller min server?

Jeg vil nu mere sige det er en stakket frist, siden der er praktisk taget ikke flere ledige IPv4 på nettet.

Før-eller-siden vil der blive slukket for IPv4 og vi vil have IPv6, så det kunne være en god ide at anskaffe sig en IPv6 forbindelse.

Hvis du kan ikke få det igennem din Internetudbyder, så kan du altid få det fra eksempelvis Tunnelbroker.net, men det er en suboptimal løsning.

Især fordi sites som eksempelvis Netflix hader VPN løsninger, så her skal der pilles ved DNS, så dine maskine får kun fat i IPv4 versionen af Netflix DNS records.

IPv6 SLAAC med privacy extensions giver så sine egne udfordringer, hvis du vil gerne have RDNS på dit eget IPv6 range, fordi du har 64 bit reserveret til adressering af de enkelte host på dit subnet vs 8 bit for et klasse C subnet i IPv4, eller endnu mindre hvis dit CIDR prefix er /25, /26 ... /32.

Den mest elegante løsning på IPv6 RDNS er vel nok All knowing DNS?

Læg så hele det rod oveni, hvis man bruger Active Directory på ens subnet (f.eks. i form af en SAMBA server) og det bliver et rent mareridt at holde styr på DNS lookups.

Jeg er i hvert fald kommet til konklusionen at Bind DNS er ikke fleksibel nok, så man kan løse alle opgaverne ved brug af Bind alene.

Jeg var ellers ret glad for at man kunne inddele quiries i forskellige views alt efter hvem det var der spurgte min server.

://weakdh.org/ siger at DH-2048 er sikkert, men her er det ikke sikkert, hvad skal man dog tro på, når nu der er masser af forbehold det ene sted.

Jeg synes nu at testen er tæt på en ren kopi af https://en.internet.nl/. :-)

Det er de samme referencer, der bliver brugt, når de siger at et-eller-andet fejler.

Referencen arbejder med begreberne forældet, okay og anbefalet.

Testen fejler kun hvis ting er forældet, eller en cifferrækkefølge er forkert, men hvis du vil være på forkant, så gå efter anbefalet indstillinger hvor muligt, så du skal ikke ind og opdatere så tit på din server.

Ting der er klassificeret som okay har det med at blive forældet indenfor et år eller to... :-)

• Failed : Modern address (IPv6). Your website is not reachable for visitors using a modern internet address (IPv6), or improvement is possible.

• Failed : Secure connection (HTTPS). The connection with your website is not or insufficiently secured (HTTPS).

• Warning: Not all recommended application security options are set for your website.

https://sikkerpånettet.dk/site/www.version2.dk/8212/

Så nu kan alle tjekke min side - og se hvor hackning skal forsøges.

Hvis Digitaliseringsstyrelsen bakker op om værktøjet, så er der måske en lille chance for at vi kan presse udbyderne til endelig at tilbyde IPv6?

...uagtet om det primært er af sikkerhedshensyn eller ej ;-)

Bare rolig Claus. Hacker har meget bedre og vildere værktøjer til det. :)

Referencen arbejder med begreberne forældet, okay og anbefalet.

Det undrer så mig at man giver grønt lys for en simpel HSTS politik uden inkludering af subdomains (som f.eks. på SikkerPåNettet's egen side). For en browserbruger, der fast tilgår en service via roddomænet, efterlader det jo www alternativet ubeskyttet for førstegangsangreb. I betragtning af at browserne nu allerede generelt advarer mod ukrypterede forbindelser, burde man vel kræve inkludering af subdomains for at få gult og preload (som sikrer mod førstegangsangreb) for at få grønt.

Sammenholdt med at IP4 bliver udstillet som en sikkerhedsrisiko, som allerede kommenteret her i tråden, undrer det mig også at der ikke testes for CAA som sammen med Certificate Transparency er et simpelt, men effektivt værktøj for browserfabrikanterne til at begrænse forsøg på svindel imod og iblandt den globale bande af CA'er. Det er i hver fald en policy, som benyttes af mange større sites, som f.eks. Google, Facebook, Netflix, BBC og Danske Bank, selvom disse langt fra understøtter alle de ting, SikkerPåNettet tester for.

Jeg synes nu at testen er tæt på en ren kopi af https://en.internet.nl/. :-)

Det lægger de heller ikke skjul på.

Koden til Internet.nl er i øvrigt open source: https://github.com/NLnetLabs/Internet.nl

På forsiden står der:

Danske websites udsættes for ca. 20.000.000 hackerangreb årligt. Du risikerer at miste din identitet pa nettet – og i værste fald hele dit forretningsgrundlag, hvis nettet er kritisk for din virksomhed.

Det virker ærlig talt en smule tragikomisk, at de fleste DNS udbydere, mail udbydere, cloud udbydere etc. tilbyder 2FA, men tilbyder DK Hostmaster 2FA? Nej, men domænet er jo også kun det allermest kritiske.

De har godt nok deres VID-service, men for et personligt domæne virker det som en forholdsvis dyr og tung løsning (nu når alle andre kan tilbyde let og simpel 2FA gratis). 2FA er så vidt jeg forstået dog i deres roadmap, og har været det i 2+ år, så de får det forhåbentlig implementeret inden for en overskuelig årrække.

Forbindelsen er usikkert når jeg ikke har IPv6 på min linie eller min server?

Jeg vil nu mere sige det er en stakket frist, siden der er praktisk taget ikke flere ledige IPv4 på nettet.

Før-eller-siden vil der blive slukket for IPv4 og vi vil have IPv6, så det kunne være en god ide at anskaffe sig en IPv6 forbindelse.

Hvis du kan ikke få det igennem din Internetudbyder, så kan du altid få det fra eksempelvis Tunnelbroker.net, men det er en suboptimal løsning.

Især fordi sites som eksempelvis Netflix hader VPN løsninger, så her skal der pilles ved DNS, så dine maskine får kun fat i IPv4 versionen af Netflix DNS records.

IPv6 SLAAC med privacy extensions giver så sine egne udfordringer, hvis du vil gerne have RDNS på dit eget IPv6 range, fordi du har 64 bit reserveret til adressering af de enkelte host på dit subnet vs 8 bit for et klasse C subnet i IPv4, eller endnu mindre hvis dit CIDR prefix er /25, /26 ... /32.

Den mest elegante løsning på IPv6 RDNS er vel nok All knowing DNS?

Læg så hele det rod oveni, hvis man bruger Active Directory på ens subnet (f.eks. i form af en SAMBA server) og det bliver et rent mareridt at holde styr på DNS lookups.

Jeg er i hvert fald kommet til konklusionen at Bind DNS er ikke fleksibel nok, så man kan løse alle opgaverne ved brug af Bind alene.

Jeg var ellers ret glad for at man kunne inddele quiries i forskellige views alt efter hvem det var der spurgte min server.

Hvad har denne omgang noget med sikkerhed at gøre?

Hvad har denne omgang noget med sikkerhed at gøre?

Jeg reseachede lidt på emnet, men jeg er langt fra ekspert. En ting jeg fandt var dog, at folk har en tendens til at tage den første og bedste tunnelling de finder. Der er der en risiko for at man vælge en hvor MITM er by design. Men det er et problem for ISPerne at løse, ikke hjemmesider.

IPv6 also supports more-secure name resolution. The Secure Neighbor Discovery (SEND) protocol is capable of enabling cryptographic confirmation that a host is who it claims to be at connection time. This renders Address Resolution Protocol (ARP) poisoning and other naming-based attacks more difficult. And while not a replacement for application- or service-layer verification, it still offers an improved level of trust in connections. With IPv4 it’s fairly easy for an attacker to redirect traffic between two legitimate hosts and manipulate the conversation or at least observe it. IPv6 makes this very hard.

Kilde: Sophos.com

Hvad har denne omgang noget med sikkerhed at gøre?

Okay en del off-topic og dog:

"En server er usikker på grund af manglende IPv6".

Det er ikke sikkerhed i traditionel forstand stand, men mere "sikkerhed for at dit website STADIGVÆK virker, når der pludselig slukkes for IPv4".

Er det en bedre forklaring?

Siden en stor del af befolkningen har ikke native IPv6, så må man tyde til IPv6 via en VPN tunnel, hvis man vil være forberedt.

Det kan så gøre en sårbar overfor det scenarie Martin skriver om.

I server verdenen er dette scenarie dog mere akademisk - i hvert fald hvis serveren bliver hosted i et professionelt setup, fordi sandsynligheden for at din hosting provider har et IPv6 subnet er temmelig høj.

Jeg mener det er ligefrem et krav fra RIPE, ARIN og de andre at man har en IPv6 udrulningsplan, når man søger om at få tildelt et IPv4 subnet?

Men hvis du vælger at hoste din server på dit eget lokalnetværk, er det en problematik du måske skal forholde dig til.

I så fald er det nok ikke klassisk serverhosting man skal tænke på som det mest oplagte scenarie, men mere alt problematikken omkring VPN til arbejdet, IoT, multiplayer delen i spil og lignende.

Her ved jeg personlig erfaring at det kan blive noget rod hurtigt. :-)

Det er let for den at find fejl. Super usikre sites som google.com, gmail.com, Microsoft.com etc går alle i gul, da der ikke ser ud til at være DNSSEC på deres .com domæner. Google plejer ellers at spille efter alle internettets standarder.

Vi har et site, IPv6, DNSSEC etc, men det fejler på begge dele, IPv6 da DanDomain ikke har en IPv6 adresse, og DNSSEC fordi det CNAME vi har til en .com adresse hos en CDN ikke har DNSSEC.

Det er lidt svært for os at løse. Jeg har skrevet til DanDomain om de ikke kan lave en IPv6 NAT så de kan køse deres del. Men det løser så ikke manglende DNSSEC hos store amerikanske udbydere.

Men det løser så ikke manglende DNSSEC hos store amerikanske udbydere.

Derfor er fejlen jo ikke mindre, af at de ikke understøtter det, jo mere press der kommer på det, jo bedre for alle.

Synes det er fedt de for en gangs skyld har valgt at genbruge en open source løsning istedet for at strikke noget bras sammen selv, det kan man kun håbe på der sker mere af fremadrettet, tænk de penge der kunne være sparet på smitte stop app f.eks, eller endnu større løsninger/systemer.

Okay en del off-topic og dog:

"En server er usikker på grund af manglende IPv6".

Det er ikke sikkerhed i traditionel forstand stand, men mere "sikkerhed for at dit website STADIGVÆK virker, når der pludselig slukkes for IPv4".

Er det en bedre forklaring?

Tja, det er det vel.

Men umiddelbart vil jeg dog stadig hævde, at IPv6 ikke gør sikkerheden større end IPv4. Eller gør det?

Tja, det er det vel.

Men umiddelbart vil jeg dog stadig hævde, at IPv6 ikke gør sikkerheden større end IPv4. Eller gør det?

IPv4 bliver ikke slukket foreløbig.

Man kan argumentere for, at IPv6 tilføjer en lille smule sikkerhed for almindelige brugere, i form af at IP-adressen på den enhed, man anvender, typisk skifter med jævne mellemrum (EUI-64 med privacy extensions). Det kan i visse tilfælde gøre det sværere at nå en bruger udefra - i hvert fald hvis angriberen forsøger at nå brugeren på en IPv6-adresse, der er udløbet og erstattet af en anden adresse, som angriberen endnu ikke kender.

Det kan heller ikke lade sig gøre at scanne et netværk for IPv6-adresser, på samme måde som man kan på IPv4 (der er alt for mange kombinationer).

Så man kan sige, IPv6-only i bedste fald har en lille, positiv betydning for sikkerheden for den enkelte bruger. I praksis har det nok mindre betydning, for de fleste kører dual stack alligevel.

For servere har det ingen sikkerhedsmæssig betydning - ud over at administratoren skal huske at opsætte firewall for både IPv4 og IPv6.

Jeg er på ingen måde teknisk ekspert. Men når jeg tester googles domæne får jeg resultatet, at de kører de forældede TLS 1.0 og 1.1.

Hvis jeg anvender andre online testværktøjer, får jeg at vide, at Google kører TLS 1.3.

Det gør jo ligesom en forskel, når det handler om at sende mails. Og jeg er også overbevist om, at Google har styr på deres ting.

Det er lidt svært for os at løse. Jeg har skrevet til DanDomain om de ikke kan lave en IPv6 NAT så de kan køse deres del. Men det løser så ikke manglende DNSSEC hos store amerikanske udbydere.

Google Workspace kunder kan anvende Googles DNSSEC MX hosts.

mx1.smtp.goog

mx2.smtp.goog

mx3.smtp.goog

mx4.smtp.goog