Datasvammel

Mitt nyårslöfte i år var att bli av med Wordpress. Ja, tro det eller ej, men den typen av nyårslöften kan jag i alla fall försöka hålla.

Anledningen till att få bort Wordpress är relativt enkel, den gör det inte enkelt för mig att blogga. Jag skriver helst inte text i fancy-schmancy-verktyg, utan gärna rått i en ren texteditor i format som Markdown. Dessutom börjar det bli rätt hårigt att underhålla verktyg som Wordpress eftersom man måste stå på tårna och uppgradera så fort det kommer en ny version eller sårbarhet. Att dessutom få Wordpress att inte sätta några kakor är också rätt krångligt.

Så därför har jag letat efter vettiga verktyg för att generera statiska webbsajter. Och jag har hittat ett, Hugo. Väldigt lätt att hantera, och kan rendera hela den här bloggen på cirka 160ms på den maskin där jag kör den. Det är ganska fort. Så snabbt bloggar inte jag, vilket märks om man tittar på mina inlägg. Mest intensivt bloggade jag kanske mellan 2005 och 2008.

Dessutom ville jag stöka om på mitt hemmanät, och exponera några tjänster ut, bl.a. över HTTP(S). Då fick jag bygga om lite för att skapa en extern HTTP-proxy. Denna proxy genererar dessutom Let’s Encrypt-certifikat för de tjänster som behöver det, och sedan skickar de in trafiken till tjänster som hostas i kvm:er. Nu är proxyn en Nginx, och jag använder acmetool för att underhålla certifikaten. Dock blev jag sugen på att använda Caddy som proxyserver istället, då den dels verkar riktigt bra, och dels har inbyggt stöd för Let’s Encrypt.

Den här bloggen genereras på samma gamla Wordpress-instans, men nu som statisk HTML. Det går som jag nämnt väldigt fort att rendera sajten statiskt. Men som bonus har jag minimera ytan för sårbarheter avsevärt. Buggar i PHP, Wordpress eller alla dessa Wordpress-tillägg behöver jag inte längre bry mig om. Och backup kan jag mycket enkelt göra genom att lagra källan till bloggen som ett git-repo, och publicera helt öppet på Github. Eftersom inget i denna backup innehåller några hemliga element är detta trivialt.

Det var svårare att göra backup med en Wordpress-instans eftersom Wordpress lagrar data i två skilda världar, dels MySQL (redan där borde jag ha avvecklat Wordpress för länge sen), och dels i filsystemet. Och inte nog med det lagras det ju också lösenord där, för saker som administratörer, användare och inloggning till MySQL.

Men att byta från Wordpress till något annat är inte helt enkelt, särskilt inte om man vill bevara gammalt innehåll. Nu finns det en del verktyg för att dra ut innehåll ur en gammal Wordpress - men inte direkt till en Hugo-instans. Det gick dock att dra ut det som Jekyll-data, och för Hugo finns det en Jekyll-importer, så det blev lösningen den här gången. Det betyder dock inte att allt innehåll dyker upp felfritt.

Att gå in och manuellt granska och anpassa innehållet var faktiskt det som tog mest tid. Wordpress använder ju HTML som markup, vilket Markdown faktiskt hanterar.

När man går igenom en dump som den jag gjorde från min Wordpress, som varit igång sedan 2005 (12 år!) så märker man hur mycket som ändrats under ytan på Wordpress. Inlägg som gjorts har formatterats på en uppsjö olika sätt. Nu har jag inte ändrat all HTML till Markdown, för det orkar jag inte, och det mesta fungerar ändå. Men att göra ett försök till att genomföra en konvertering med automatik vore dömt att misslyckas.

Så, nu återstår bara att skapa ett enklare flöde för publicering av nya inlägg. Läser ni det här har jag åtminstone gjort ett lyckat första försök.

Helt borta från PHP är jag inte, det finns ju bl.a. Gnuheter som behöver en del vård. Och Creeper behöver en hel del uppdateringar ändå.

Nu saknar jag ingenting från Wordpress egentligen. Men det innehåll som inte följde med den här konverteringen var kommentarer. Skönt egentligen. Det vanliga är att man sätter upp Disqus tillsammans med Hugo för att slippa egen teknik, men jag vill inte ladda alltför många externa resurser till denna sajt. Jag känner inte till Discus egentliga affärsmodell, eller ens vem som äger dem. Ett lockande alternativ är att använda Github Issues som kommentarer, som Don Williamson skrivit om. Men egentligen behövs de inte tycker jag.

Eller vad tycker du..?

Efter dagens presentationer på 32c3 om Tor, Tor Onion Services, More Useful Than You Think, och State of the Onion, så beslöt jag mig för att börja lägga till alla mina egna (mest privata) tjänster som hidden services.

Instruktionerna för att skapa en konfiguration för sin hidden service är rätt bra, och rätt enkla om man vill dölja en webbtjänst. Men om man vill använda t.ex. en SSH-klient för att ansluta till sin SSH-service så får man söka rätt ordentligt på nätet för att ta reda på hur man gör.

Så här är snabb-snabb-instruktionerna för hur man skapar sin SSH-tjänst som en hidden service på en debian/ubuntu-maskin - kör som root:

apt-get install tor

Lägg till följande i din konfiguration i /etc/tor/torrc:

HiddenServiceDir /var/lib/tor/ssh_hidden_service/
HiddenServicePort 22 127.0.0.1:22

Sedan kör du

systemctl reload tor.service

Du hittar din .onion-adress genom att köra

cat /var/lib/tor/ssh_hidden_service/hostname

Nu har du alltså en SSH uppsatt som en hidden service. Bra! Men hur ansluter man?

Jo, såhär. Man lägger till följande proxy-information i sin .ssh/config, förutsatt att ens socks-proxy för Tor körs på port 9050 (vilket är default):

Host *.onion
ProxyCommand /usr/bin/nc -xlocalhost:9050 -X5 %h %p

Nu ska man alltså helt utan problem kunna köra ett ssh-kommando för att ansluta till en .onion-adress:

ssh pawal@exempelhash123.onion

Om du har en massa maskiner bakom NAT underlättar ju även det här att komma åt dem, även om det blir en hel del extrahopp över Tor-nätet på vägen.

En fotnot: Den här bloggen är även tillgänglig på http://hxrni7witdpetpuf.onion/, men pga hur Wordpress fungerar så är det väldigt mycket jobb att få till det så att länkar och bilder går .onion-adresserna istället för att läcka ut till den vanliga sajten.

Jag gjorde en snabb körning på hur det ser ut med TLS hos våra toppdomäner i världen. Med den nuvarande tillväxten av nya toppdomäner har vi idag 1082 delegerade toppdomäner i root, och det växer sakta tills dess att ICANN har delegerat alla nya toppdomäner.

Eftersom vi vill att TLS ska finnas på alla webbsajter är det intressant att se hur toppdomäner skyddar sin kommunikation med allmänheten. Så min första enkla analys är att helt enkelt se vilken URL man registrerat hos IANA, och se om de har https som default. IANA har en WHOIS-databas för toppdomänerna där man kan registrera sin webbsida. Detta har 1010 av 1082 toppdomäner gjort, dvs 93% av alla toppdomäner.

Men sedan kommer det lite nedslående resultatet. Tittar jag efter https i resultatet så är det bara 23 registryn som registrerat en webbsida med HTTPS:

Dvs, enbart 2% av alla toppdomäner har registrerat en webbsida som skyddas av HTTPS. En närmare analys ger förhoppningsvis ett bättre resultat, då man kanske glömt att registrera en webbsida med https istället för http.

Script:

https://gist.github.com/anonymous/efe3f122c0e091868ff2

Hela resultatet hos Pastebin.

Inspirerat av WikiCreeperEdit så har jag fått hjälp med att skapa en sida på Creeper som visar samma ändringar, men lite mer sammanställt, och förhoppningsvis mer användarvänligt.

Sidan ligger nu uppe här: http://gnuheter.com/creeper/wikipedia

Samtidigt har jag publicerat källkoden på Github, för lite mer tillgängliggörande för den som vill hjälpa till med ändringar och förbättringar. Jag föredrar att ändringar skickas som pull requests, men det går naturligtvis bra att skicka ändringar direkt till mig i e-post om man inte vill skylta med sitt namn.

För den som vill skapa andra applikationer baserat på de IP-adresser som används av Creeper finns det nu en enklare JSON-publicering av adresserna. Vad som behövs är till exempel verktyg för att verifiera och administrera ändringar av adresserna. Men att bara verifiera IP-adresserna genom ett litet fiffigare webbgränssnitt än vad som är tillgängligt nu vore mycket bra att ha.

Den här artikeln är skriven till ett annat forum och är skriven för DFRI:s räkning, men publicerades aldrig.

En mobiltelefon med Wifi påslagen skickar ut en unik signal som går att avlyssna med enkel utrustning. Några som lyssnar på dessa signaler är Bumbee Labs, som byggt ett system kallat IOPS. Syftet med systemet är att mäta rörelsemönster i stadskärnor, och just nu testas det i Västerås och Borås.

I systemet sparas telefonens unika identitet, den så kallade MAC-adressen, samt vilka platser den befunnit sig på och vid vilken tidpunkt. Bumbee Labs hävdar att de inte sparar telefonens MAC-adress, utan bara en kod som motsvarar den, och att det inte går att räkna ut i efterhand vilken MAC-adress koden motsvarar.

Forskning visar dock att det lätt går att göra baklängesberäkningar för att ta reda på vilken MAC-adress som koden motsvarar. Men egentligen spelar det ingen roll. Genom att över tid titta på hur en telefon rör sig går det ändå att lista ut vilken individ som äger den, oavsett om MAC-adressen är tydligt utskriven eller bara motsvaras av en kod.

Det är också möjligt att missbruka systemet åt andra hållet. Genom att själv ta reda på en persons MAC-adress och se vilken kod den motsvarar i systemet kan man i datan sedan följa hur personen, tidigare eller i framtiden, rör sig.

Att avidentifiera data är med andra ord ingen lätt uppgift. Tyvärr har Bumbee Labs hittills inte gett oss någon information som tyder på att de lyckats. Tvärtom har flera av deras uttalanden fått oss att tvivla på att de förstår det grundläggande problemet.

När nu systemet byggs ut i stadskärnorna och efterfrågas av fler städer, skapas alltså en gigantisk databas över inidviders nationella rörelsemönster.

Vi tror inte att Bumbee Labs har för avsikt att övervaka individer, men det blir ändå konsekvensen av systemet. Faktum är att alla typer av storskalig datainsamling kan användas för att kartlägga individer om inte all data är helt avidentifierad.

Vi anser inte att det är fel i sig att samla in statistik över besöksströmmar, men insamlandet måste ske på ett sätt som inte kränker människors grundläggande rätt till integritet.

Vi anser också att ett minimikrav på ett sådant system är transparens, där alla som vistas i områden där kartläggningar pågår kan ta del av den tekniska lösningen, källkod till systemet, databasinnehåll och den statistik som tas fram. Utan dessa möjligheter kan vi inte veta om systemet faktiskt lever upp till att skydda vår integritet. Istället är vi hänvisade till uppgifter från företaget som ligger bakom.

Vår förhoppning är även att MAC-adresser, likt IP-adresser, som lagras på det här sättet klassas som personuppgifter och behandlas därefter. Allra minst ska det finnas tydliga skyltar om att MAC-adresserna samlas in, i likhet med vad som gäller för övervakningskameror.Något som är trivialt att bygga ut IOPS-systemet med är att fånga upp fler av de signaler som läcker ut samma väg som MAC-adressen. Många telefoner sänder också ut så kallade SSID:s för att snabbt koppla upp sig till nät kan vara tillgängliga. Dessa SSID:s kan avslöja var personen bor, vilket hotell man bott på och personens arbetsplats. Detta har demonstrerats i system som Snoopy och CreepyDOL. Dessa system kopplar effektivt ihop mobiltelefoninnehavarens MAC-adress med andra databaser, och kan därmed med lite tur lätt identifiera en individs hemvist. Det är trivialt för Bumbee Labs att bygga ut IOPS med den här typen av funktionalitet. MAC-adressen blir en effektiv länk mot andra databaser som effektivt kan identifiera individer. Det är också lätt för andra som spanar efter en MAC-adress - arbetsgivare, polis eller kriminella organisationer - att fråga Bumbee Labs om rörelsemönster för en viss mobiltelefon. Särskilt problematiskt blir detta då de inte redovisar hur företaget skyddar sin databas eller hur länge de sparar data om din telefons rörelsemönster.

Jag slog precis på tvåfaktorautentisering här på min blogg. Det tog ungefär tre minuter.

Om du vill slippa all teori omkring så gör man så här:

1. Installera FreeOTP på din telefon.
2. Ladda ner tillägget Two Factor Auth till din Wordpress.
3. Om den inte fungerar, installera php5-mcrypt och se till att den fungerar i din installation.
4. Klicka på Two Factor Auth i win Wordpress-meny och aktivera TOTP.
5. Läs av QR-koden med FreeOTP på telefonen.
6. Logga ut från Wordpress.
7. Logga in på Wordpress med ditt vanliga lösenord. Nu får du frågan om OTP-koden.
8. Generera koden i telefonen med FreeOTP och skriv in den i Wordpress.

Nästa blogginlägg får bli teorin kring denna lösning.

Min dotter har börjat spela Minecraft rätt mycket. I somras satte jag upp en Minecraft-server åt henne, och det tog rätt lång tid att sätta sig in i vad man egentligen ville köra för programvara. Företaget Mojang som gör spelet har en egen server som man kan installera och köra, men i grundutförandet så är den lite tråkig om man vill hitta på lite mer alternativa spel. Så jag installerade en programvara som heter CraftBukkit.

Om man klickar på länken nu får man reda på att den har utsatts för en DMCA-takedown.

Det upptäckte vi dock inte genom att surfa till CraftBukkit-projektet, utan att det helt enkelt inte gick in att logga in på servern längre. Snabbt felsöka, och upptäcka att det inte gick att hämta hem nyare versioner, då allt var nedtaget tack vare den amerikanska lagstiftningen Digital Millenium Copyright Act. Varför det inte gick att spela på servern längre var inte så lätt att förklara för en sjuåring. Så jag försökte istället hitta en annan programvara som inte tagits ner. Och alternativet tycktes vara Spigot. Sagt och gjort, en halvtimme senare kunde de logga in på servern och spela.

Idag upptäcker jag att även Spigot tagit emot en DMCA-takedown notice. Tack så mycket. Servern funkar dock fortfarande.

Allt tycks bero på att utvecklaren Wolvereness (Wesley Wolfe) bidragit med en stor mängd kod till Bukkit, och det här innebär en hel mängd licensbekymmer. Det sorgliga är att han nu skickar runt DMCA-takedowns till allt och alla. Här finns en summering av det som hänt hittills.

Återstår hoppet till att Mojang ska reda ut detta? Att det ska vara komplicerat med öppen programvara vs sluten programvara - det enklaste i det här läget är att göra all programvara för Minecraft-servrar som öppen källkod under en väldigt fri licens. Att förklara licensfrågor för en sjuåring tänker jag dock inte utsätta mig för.

Nästan alla kör BIND från ISC för sin DNS. Så är det bara. Men det finns många nya alternativa namnservrar som är minst lika bra, och som inte lider av det kod-arv som BIND 9 gör. BIND har skrivits om från grunden två gånger i modern tid, först från BIND 4 till BIND 8, och sedan till BIND 9. Ett tredje försök har gjorts under de senaste åren från ISCs sida, nämligen med det havererade BIND 10-projektet. ISC har dock varit väldigt öppna med hur och varför projektet havererade, och det är bara att konstatera att vi kommer att få dras med BIND 9 ett väldigt långt tag framöver.

Men under de senaste åren har ett par riktigt bra alternativ till BIND tagits fram av andra aktörer. Min favorit för auktoritativ DNS är Knot DNS från CZ.NIC. Som också ISC själva säger, framtida DNS-innovation kommer sannolikt att komma från andra aktörer än ISC. Ett av de nuvarande problemen med BIND är att den försöker göra allt. Den är både auktoritativ namnserver, och cacheande resolver, och säkert mycket annat också samtidigt. Knot DNS är “nästan bara” en auktoritativ namnserver. Men i nuvarande versioner har de även lagt till online-signering för DNSSEC, och kommer att i version 1.6 komma närmare OpenDNSSEC vad gäller hanteringen för nyckelsigneringspolicy - något som andra DNS-programvaror saknar helt. Man håller också på att byta från OpenSSL till GnuTLS, dels av kända anledningar, och dels för att GnuTLS har betydligt bättre stöd för PKCS#11, något som krävs om man vill använda HSM:er. Vidare har man även möjlighet att köra sina egna moduler för att utföra dynamisk hantering av DNS-svar, och för IPv6 kan man exempelvis också dynamiskt generera reverse-svaren för IP-adresserna. Se gärna presentationen från RIPE68.

Själv har jag kört Knot DNS ett långt tag på en av mina egna namnservrar. Den är både betydligt enklare att konfigurera, men den har också betydligt bättre prestanda än BIND. Något som jag förvisso inte har något större behov av, eftersom mina domäner inte drar särskilt mycket trafik. Som ett alternativ till Knot DNS finns också självklart NSD 4 från NLNet Labs, som har funnits betydligt längre, och används kanske mest av TLD:er idag - men också Yadifa från EURid.

För att köra en cacheande resolver så kan man med fördel använda Unbound, också från NLNet Labs. Unbound har också givetvis fördelarna med att den är betydligt enklare att konfigurera, och har betydligt högre prestanda än BIND. En cacheande resolver kör man med fördel med DNSSEC påslaget för DNSSEC-validering, så nära de tjänster man har som behöver lita på DNS (det är i princip samtliga internet-tjänster).

Om man känner sig lite osäker på att behöva byta från BIND kan man kanske titta på antalet kända sårbarheter… Och som med alla monokulturer, de är sårbara för breda attacker. Därför är det också bra att börja köra alternativa programvara. Gärna på någon udda  CPU-arkitektur, så att inte alla kör Intel.

(Jag har fullständigt medvetet inte skrivit om programvaror som inte är öppen källkod.)

I en serie poster tänkte jag nu framöver posta lite mer renskrivna texter om DNS från mina anteckningar på olika internet-konferenser. Jag hoppas detta kan vara till glädje för någon som är intresserad av vad som händer i DNS-världen.

DNS har funnits i drift i över 25 år. Det är bara under de senaste 15 åren som säkerhet i protokollet diskuterats, och 2005 gick RFC:erna för DNSSEC genom IETF. Men kravet i protokollet för att skydda den personliga integriteten har aldrig funnits - förrän under det senaste året.

Med anledning av Edward Snowdens avslöjanden så har IETF sakta börjat se över de protokoll som IETF i någon form ansvarar för, och med publiceringen av RFC 6973, “Privacy Considerations for Internet Protocols” så kan man säga att arbetet satt igång på allvar. Inom IETF har man också satt upp en mailinglista för att diskutera “pervasive surveillance” med ett lite bredare perspektiv, perpass@ietf.org.

Gamla protokoll designades i en annan tidsålder, innan övervakning var på agendan. Dessa protokoll läcker mycket för mycket metadata (och data). Men det finns många begränsningar i dessa protokoll som kan förhindra eller försvåra att man gör tillägg för att gynna den personliga integriteten såsom latency, stabilitet och att protokollen blivit universella.

En DNS-fråga avslöjar vem som frågar, och vad som frågas efter. Detta underminerar säkerheten i andra protokoll, som till exempel HTTPS. Vad finns då i qname-delen av en DNS-fråga? “www.political-party.example”, eller “_bittorrent-tracker._tcp.domain.example” - MPAA kan vara intresserade. “le-pc-de-pascal.domain.example” - personlig information, eller t.ex. PGP-nycklar i DNS. Helt enkelt saker som avslöjar saker om ditt internet-beteende som de protokoll du använder dig av normalt kanske skyddar - men där informationen skickas i klartext i DNS. Detta beteende i DNS vill man ju ändra på.

Vi behöver en lösning för att skydda informationen “on the wire” och “på servern”. Resolvrar kan också läcka information genom t.ex. sysadmins, och en cache innehåller också all denna information i klartext. Att skydda DNS-informationen på protokollnivå kräver dock ändå olika lösningar, en för att skydda klient-kommunikationen mot en resolver, och en annan för att skydda kommunikationen från en resolver till auktoritativa namnservrar.

Från att ha diskuterats på perpass flyttade diskussionen till dnsop, och nu är flyttad till en egen dnsprivacy-lista. Det finns en möjlig lösning implementerad (men inga andra), DNSoverTLSoverTCP. Ingen officiell working group ännu, men vem som helst kan ändå posta förslag till IETF.

Problem statement: draft-bortzmeyer-dnsop-dns-privacy - problemet behöver dokumenteras innan man kan lösa det…

Minimizing the qname - fulla frågenamnet behöver inte skickas till auktoritativa namnservrar högre upp i hierarkin. Detta går att implementera i Unbound och BIND, men ingen har gjort det ännu. Påverkar DNS-OARC och DITL, eftersom informationen att göra forskning på minskar. Vilket ju också är lite av poängen…

Tyvärr förekommer det alldeles för lite diskussion om dessa förslag på listorna, och intresset verkar lågt (trots riktigt stora möten på IETF). Att förändra DNS är också väldigt svårt.

Efter förra helgens DNS-OARC-möte skickade Paul Vixie ett mail till IETF:s dnsop-arbetsgrupp och uttalat sitt stöd för minimering av innehållet i frågorna, så det arbetet kanske tar lite fart igen.

På söndag är det Cryptoparty på Cyklopen i Högdalen, med lite extra festligheter den här gången. DFRI och Sparvnästet arrangerar.

Där tänkte jag hålla i en liten workshop om vår översättning av Cory Doctorows bok Little Brother. Du behöver dock inte vara med där för att hjälpa till att översätta.

Bara två dagar efter Cryptoparty är jag med och arrangerar #MeraKrypto som är ett samarbete mellan DFRI, SNUS, Sunet och ISOC-SE!

Vi ses på något av arrangemangen hoppas jag!