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.
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:
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.
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.
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.
IOPS antenn
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.
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ändaanledningar, 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.
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.