Bärbar router som skyddar integriteten: lägg till stöd för DNS-Over-TLS i OpenWRT (LEDE) med Unbound

I dag vill vi dela en detaljerad guide till hur du konfigurerar DNS-Over-TLS med GL-AR750, skriven av Junade Ali. Om du inte vet vad DNS-Over-TLS är kommer här lite bakgrundsinformation:

Din nyfikna ISP kan kartlägga allt du gör på internet och sälja uppgifterna till annonsörer och marknadsföringsföretag. DNS-Over-TLS är ett nytt säkerhetsverktyg för webbsurfning som skyddar användarnas integritet. Det krypterar DNS-förfrågningarna och förhindrar avlyssning och manipulering av DNS-data genom man-in-the-middle-attacker.

---

Om du vill gå direkt till instruktionerna kan du rulla till nästa avsnitt. Men jag är lika mångordig som en TLS-handskakning, så håll till godo med inledningen.

Föreställ dig följande: jag är på en restaurang och behöver ha ett privat telefonsamtal, men tyvärr är mobilens batteri slut. För att lösa problemet lånar jag min väns telefon och slår numret. För att skydda min integritet går jag ut. När samtalet är slut går jag in igen och lämnar tillbaka telefonen.

Telefonen lagrar visserligen inte själva samtalet, men den sparar det senast uppringda numret i en logg. Om vännen som jag lånade telefonen av ville skulle hen enkelt kunna se vem jag ringde, även om hen inte vet exakt vad vi pratade om.

Ibland kan uppgiften om vem du har pratat med säga väldigt mycket om samtalet. Om någon ringer en stödlinje eller ett inkassoföretag kan man förmodligen dra många slutsatser om samtalet utifrån telefonnumret.

När vi surfar på internet använder vi kryptering för att försöka skydda vår kommunikation. När du ansluter till en webbplats via HTTPS visas ett grönt hänglås i webbläsaren. Det visar att din kommunikation är krypterad så att det krävs stora beräkningsresurser för en angripare mellan dig och webbplatsens server att se vad du kommunicerar om.

Jag har tidigare bloggat om hur det under vissa omständigheter är möjligt att ta bort den här krypteringen och vilka motåtgärder webbplatser kan använda för att förhindra det. Tyvärr finns det ett betydligt mer grundläggande problem för integriteten på nätet.

Som de flesta inom IT vet måste klienten, innan webbläsaren upprättar en HTTP-anslutning till en webbplats (till exempel cloudflare.com), göra en DNS-förfrågan för att ta reda på vilken IP-adress HTTP-anslutningen ska göras till. Detsamma gäller alla andra protokoll i applikationslagret när du ansluter med ett värdnamn i stället för en IP-adress. Om du vill ha en introduktion till DNS finns en artikel om grunderna i DNS i vårt Learning Centre.

Krypteringsteknik har funnits ganska länge för själva HTTP, men först nyligen har sådana krypteringstekniker standardiserats för DNS. Om du inte vet om din DNS-trafik är krypterad är den förmodligen inte det.

I praktiken betyder det att när du ansluter till en webbplats som använder HTTPS kan någon som avlyssnar din anslutning, trots att kommunikationen är krypterad, se vilken webbplats du söker efter och (beroende på hur webbplatsen är skyddad) till och med manipulera svaret så att du kommunicerar med en annan server.

Det här är särskilt användbart för avlyssnare, oavsett om det är nätverksoperatören bakom en gratis Wi-Fi-hotspot som vill sälja dina uppgifter till annonsörer för riktad reklam eller en hackare som sippar på en latte medan hen avlyssnar din nätverkstrafik (ironiskt nog klädd i svart huvtröja och rånarluva).

Genom att ställa in din DNS-resolver på Cloudflares DNS Resolver får du en snabbare surfupplevelse samtidigt som du säkerställer att de som driver din DNS-resolver inte säljer uppgifterna för att rikta reklam till dig. Men även om Cloudflare Resolver stöder både DNS-over-HTTPS och DNS-over-TLS kan du, för att säkerställa att anslutningen mellan dig och Cloudflare Resolver är krypterad, behöva göra några ytterligare inställningar, som att aktivera en DNS over HTTPS-klient.

Det här blogginlägget förklarar hur du konfigurerar en OpenWRT-router för att kryptera utgående trafik till Cloudflare Resolver. Det är särskilt användbart när du vill skydda trafiken från enheter i hemmet som kanske inte stöder krypterade DNS-protokoll, till exempel din TV eller din IoT-anslutna brödrost. Lokala klienter kan fortfarande uttryckligen åsidosätta routerns lokala DNS-resolver, men många använder den som standard.

OpenWRT (LEDE)

Helgen innan jag skrev det här inlägget beställde jag en ny trådlös router, GL.iNet GL-AR750. Den här routern är mycket liten och marknadsförs som en ”reserouter”. Den kan fungera både som Wi-Fi-repeater och som en vanlig Wi-Fi-router. Routerns längsta sida är ungefär lika lång som mitt pekfinger:

Jag beställde inte den här routern bara för storlekens skull. Den levereras också med OpenWRT förinstallerat, ett inbäddat Linux-baserat operativsystem som lämpar sig väl för routrar. I maj 2016 förgrenades OpenWRT till LEDE (Linux Embedded Development Environment) och återförenades med OpenWRT-projektet i januari 2018.

Om du inte har en router med LEDE förinstallerat kan du följa anvisningarna i det här blogginlägget med vilken annan router som helst som kan installeras med OpenWRT-firmware. Mer information finns på sidan OpenWRT Support Devices. Tänk dock på att det, beroende på din enhet, kan innebära en viss risk.

Stöd för DNS-over-TLS (eller avsaknaden av det)

Routern jag testar har en inställning för att konfigurera en uppströms DNS Resolver som används när en förfrågan inte är cachelagrad i den egna interna resolverfunktionen. Den lokala resolvern föreslås sedan för klienter som ansluter till routern.

För experimentets skull kan jag via webb-UI konfigurera routern att använda 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 och 2606:4700:4700::1001 som uppströms DNS-servrar (med adresserna för IPv6 uppdaterade om nätverket inte stöder dem):

Genom att ansluta routerns WAN-port till min dator kan jag fånga upp trafiken med Wireshark när den lämnar routern, innan den går ut på det faktiska WAN-nätet. När en DNS-förfrågan inte finns i routerns cache vidarebefordras den till 1.1.1.1. Eftersom routern skickar förfrågningarna okrypterade i stället för att använda DNS-over-TLS kan jag se hur dessa DNS-förfrågningar skickas över internet i okrypterad form:

Cloudflare Resolver stöder DNS-over-TLS, men det gör tyvärr inte min router, som helt enkelt skickar alla förfrågningar okrypterade.

Konfigurera DNS-Over-TLS

Som standard levereras LEDE med Dnsmasq förinstallerat som intern resolver och stöder därför inte DNS-over-TLS. För att våra förfrågningar ska bli krypterade ska vi ersätta Dnsmasq med Unbound och odhcpd. Jag har utgått från den mycket användbara dokumentationen för OpenWRT-paketet Unbound i stegen jag följer.

Innan vi börjar behöver vi ansluta till routern via SSH. Om du blir ombedd att ange ett lösenord är det troligen samma som du ställde in för webbportalen:

LEDE använder ​opkg​ som pakethanterare. Först uppdaterar vi paketlistan och sedan installerar vi Unbound med Unbound-Control och den fullständiga versionen av odhcpd:

opkg update
opkg install unbound odhcpd unbound-control
opkg remove dnsmasq

Observera att du även kan installera Luci-appen för Unbound om du vill styra det via standardgränssnittet.

opkg install luci-app-unbound

Eftersom min router inte kör en oförändrad version av LEDE påverkas inte gränssnittet om jag installerar det här, och jag har inte testat den här modulen själv.

När Unbound är installerat kan vi lägga till inställningar så att Unbound använder 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 och 2606:4700:4700::1001 som DNS-resolvrar med TLS-kryptering. Jag har gjort det genom att lägga till inställningar i /etc/unbound/unbound_ext.conf med Vim:

forward-zone:
  name: "."
  forward-addr: 1.1.1.1@853
  forward-addr: 1.0.0.1@853
  forward-addr: 2606:4700:4700::1111@853
  forward-addr: 2606:4700:4700::1001@853
  forward-ssl-upstream: yes

I konfigurationsfilen för Unbound på /etc/config/unbound har jag lagt till några nödvändiga parametrar enligt paketets dokumentation. I mitt fall säkerhetskopierade jag konfigurationsfilen och använde helt enkelt följande:

config unbound
  option add_local_fqdn '1'
  option add_wan_fqdn '1'
  option dhcp_link 'odhcpd'
  option dhcp4_slaac6 '1'
  option domain 'lan'
  option domain_type 'static'
  option listen_port '53'
  option rebind_protection '1'
  option unbound_control '1'

Om du har ytterligare parametrar i filen ska du kontrollera att inget åsidosätter de angivna parametrarna. Var särskilt försiktig med parametern unbound_control.

Jag har även slagit samman följande konfiguration med /etc/config/dhcp (och lämnat vissa befintliga poster orörda):

config dhcp 'lan'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option interface 'lan'
        option leasetime '12h'
        option ra 'server'
        option ra_management '1'

config odhcpd 'odhcpd'
        option maindhcp '1'
        option leasefile '/var/lib/odhcpd/dhcp.leases'
        option leasetrigger '/usr/lib/unbound/odhcpd.sh'

Till sist kan vi aktivera automatisk start för Unbound och starta det:

service unbound enable
service unbound start

Här är beviset: när vi fångar upp DNS-förfrågningar mellan vår router och resten av internet ser vi att de är krypterade med TLS v1.2:

Slutsats

I det här blogginlägget har vi diskuterat hur kryptering av din DNS-trafik kan hjälpa till att skydda integriteten när du surfar. Genom att ersätta Dnsmasq med Unbound kan vi låta OpenWRT dra nytta av DNS-over-TLS för att kryptera vår webbtrafik.

---

Tack Junade Ali för att vi får dela den här artikeln på vår webbplats. Artikeln publicerades ursprungligen på Cloudflares webbplats den 9 april 2018: https://blog.cloudflare.com/dns-over-tls-for-openwrt/