”Fördelen med standarder är att det finns så många att välja bland”
Hur man möjliggör missbruk av tekniska standarder genom lathet, snålhet, ovilja och en oförmåga att läsa innantill; kort sagt, en seriös skopa inkompetens. Ett raljerande inlägg i teknikdebatten av Joaquim Homrighausen, WebbPlatsen i Sverige AB, joho@webbplatsen.se.
Genom att tänja på gränser har vi nått sann innovation inom flera områden, så även IT. Varje minut kläcker någon nästa storsäljande webbtjänst, varje dag lanseras det nya säkerhetsprodukter som skall förbättra våra liv tillsammans med Internet, och varje dag kommer det s k ”trendanalyser” (som ofta är dåligt maskerade sponsrade ”undersökningar”) och rapporter om nya hot.
En stor del av Internet skulle fungera så mycket bättre om beslutsfattarna förstod vad teknikerna håller på med, och om samma beslutsfattare förstod vilka konsekvenser det får när tekniker inte gör det de borde göra.
Protokoll
Att kommunicera är inte så svårt, för det mesta. Man hittar någon gemensam form av dialog och tar fasta på den; det kan vara ett språk, en metod, en princip, osv. För människan räcker det inte med att vi har riktiga religionskrig, vi måste hitta på våra egna. I ett rum fullt av duktiga systemutvecklare tar det förmodligen mindre än 30 sekunder att skapa ett verbalt inferno genom att påstå att ett språk eller en metod är bättre än den andra. Alltid är det någon som känner sig trampad på tårna.
För att hitta en gemensam form krävs ofta regler, protokoll och standarder. Många som använder och utvecklar för Internet idag har inget minne från eller kunskap av hur det såg ut i ”IT-branschen” för mindre än 25 år sedan. Att få två datorer att kommunicera effektivt över en modemlänk var ingen självklarhet. Så fort någon skapat ett överföringsprotokoll så försökte någon förbättra detta; genom att tänja på gränserna. Tyvärr fick det ofta som konsekvens att mjuk- och hårdvara som faktiskt följt specifikationer och standarder inte längre kunde kommunicera med de mer ”moderna” lösningar som såg dagens ljus i ett allt snabbare tempo. Inom loppet av 10 år blev det extremt enkla överföringsprotokollet Xmodem ett relativt effektivt sätt att överföra filer mellan datorer.
Xmodem/CRC, Ymodem, SEAlink, Kermit, Zmodem, Hydra, m fl var alla överföringsprotokoll som på ett eller annat sätt förbättrade Xmodem. Här, precis som i andra situationer, uppstod dock problemet att om man enbart kunde eller ville implementera t ex Zmodem så kunde man bara utbyta filer med andra produkter som kunde kommunicera via Zmodem. Det var inte ovanligt att de ”bästa” s k Terminalprogrammen hade stöd för 4-10 filöverföringsprotokoll.
25 år senare borde vi ha tagit stora steg framåt i vår utveckling. Vi borde ha lärt oss. Vi borde ha insett fördelarna för användare, kunder och utvecklare att kunna falla framåt och att kunna gå tillbaka, vi borde ha insett vikten av att implementera våra lösningar enligt gällande standarder och normer. Vi borde. Vi borde kunna använda XML till nästan alla former av datautbyte. Vi borde. EDI borde ha blivit enklare, bättre och billigare att implementera. Vi borde. SQL borde inte vara en fråga om vilken leverantör jag väljer eller tvingas att använda. Vi borde.
Inte alla ägg äro av ondo
Det finns väldigt mycket som fungerar bra ”ute på nätet”. Det finns en mängd operatörer, tekniker, administratörer och beslutsfattare som förstår vad det handlar om. De har lärt sig (av lust eller tvång) att de måste kommunicera eller försvinna. Leverantörer av infrastruktur har knytpunkter som utbyter stora mängder trafik på ett relativt väl fungerande sätt. Leverantörer av mjukvara blir ständigt utsatta för Internetgemenskapens sylvassa kritik om de inte sköter sig.
Tekniker, administratörer och beslutsfattare på många företag verkar dock få springa omkring med hela huvudet mitt i handen utan att någon höjer ett ögonbryn eller kräver någon form av åtgärd.
DNS och SMTP
DNS och SMTP; eller Domain Name System och Simple Mail Transfer Protocol är två nyckelbegrepp i Internetvärlden. Länge har vi använt dem och förutsatt att allt bara skulle fungera som det alltid gjort. Handen på hjärtat, hur många har en aning om hur de två får flera terrabyte av information att byta händer varje dygn?
För inte så länge sedan hade ingen tänkt tanken att dessa kunde utgöra allvarliga hot mot den mjuka delen av Internets infrastruktur. Skräppost var något man kunde be någon sluta skicka och så upphörde det, ett tag. Att attackera en DNS, som fungerar som en telefonkatalog för användare och applikationer, hörde inte till de högst rankande ”hoten” på ”säkerhetsföretagens” listor.
Sedan sköljde våg efter våg över oss med produkter och tjänster som skulle rädda oss från dessa hot som hotade att tvinga ned Internet på knä. S k ”phishing”-attacker där angriparen försöker få tag på önskad information genom att lura en besökare eller applikation att den pratar med rätt värd, och på så sätt framtvingar en överlämning av hemlig eller känslig information (användarnamn, lösenord, kontouppgifter), överbelastningsattacker (DoS), m fl haglade över oss genom media och programvaruuppdateringar från olika företag.
Ett stort utropstecken i debatten är att många av dessa problem inte skulle behöva finnas, om någon bara kunde vara så vänlig att läsa de standarddokument som hundratals människor lagt ned arbete med att ta fram; om fler kunde tänka lite längre än näsan och sluta tro att man kan allt om e-posthantering bara för att man kan klicka på ”Nästa” åtta ggr i en mailserverkonfigurationsguide och inse att detta kan få förödande konsekvenser. I bästa fall resulterar det i att e-post inte kommer fram, eller att en webbsida inte går att nå, eller någon annan mindre kännbar konsekvens. I värsta fall påverkar det tusentals användare och företag.
Skräppost kan stoppas
Mer än 90% av all elektronisk skräppost som skickats sedan den ”uppfanns” borde aldrig ha kommit fram (nu menar jag inte den som skickas av ”välvilja”, i form av ”kolla in den här bilden Jocke!”). Trots detta visar daglig ”statistik” att en förödande del av den e-post som faktiskt skickas på Internet är just skräppost.
På grund av uruselt konfigurerade e-postservrar bland främst företag och Internetleverantörer så kan en av de mest effektiva metoderna att stoppa skräppost inte användas. Jag pratar om grålistning.
Grålistning är en enkel ”bromsmetod” som använder sig av en inbyggd mekanism i SMTP-protokollet för att fördröja det första leveransförsöket. Om det sändande systemet försöker alltför snabbt igen så nekas det igen. Om nästa leveransförsök kommer inom förutbestämda intervaller släpps leveransen igenom. Det står självklart den mottagande servern helt fritt att vitlista leveransförsök från vissa adresser och servrar, eller att automatiskt vitlista genom någon form av uppslag eller algoritm.
Grålistningstekniken baserar sig på att sådana som skickar skräppost helst inte vill ”hänga kvar” längre än nödvändigt vid en viss leverans; dels för att det tvingar systemet att vara uppkopplat, vilket i teorin skulle kunna göra det enklare att spåra och dels för att man vill maximera spridningen av skräppostleveransen.
Varför går det inte då att använda grålistning fullt ut? Därför att de flesta leverantörer som tillhandahåller e-posttjänster inte klarar av att komma överens om två nummer: hur många minuter väntar vi efter det första leveransförsöket innan vi skickar, och vilka sifferkoder betyder att vi skall försöka igen. Det första problemet borde ta 10 sekunder per leverantör att lösa. För det andra problemet heter lösningen: LÄS INNANTILL. Det står i standarden för SMTP vilka koder som betyder vad.
En leverantör som vill implementera grålistning måste då välja mellan pest eller kolera. Antingen investerar man i betydligt dyrare system och rutiner för att tvätta den initiala skräpposten, eller så sitter man med stora mängder användare och förklarar att det är den skickande servern som är helt galet konfigurerad, när e-posten så småningom ramlar in, sju timmar försenad.
För att implementera grålistning korrekt så krävs också att den sändande servern förstår att alla treställiga SMTP-svarskoder som börjar på 45 och följs av ytterligare en siffra betyder ”försök igen senare”. Tydligen så sitter flera ur hjärntrusten bland utvecklare som inte kan läsa på företag som utvecklar eller konfigurerar just e-postservrar då många helt enkelt skickar tillbaka e-posten till avsändaren och säger att leveransförsöket misslyckades; därför att de trodde att förklaringen i standarden betydde att ”alla situationer vi inte förstår hanterar vi genom att lägga oss på rygg och skicka tillbaka e-posten till avsändaren”. Inte ens en av de största ”skräppostfiltreringsföretagen” hanterade detta korrekt tills ganska nyligen (och då efter påtryckningar från gräsrötter).
Två andra effektiva komponenter i skräppostfiltrering är RBL, eller realtime-black-list. En metod som går ut på att man jämför den skickande serverns IP-adress och/eller värdnamn mot en databas som uppdateras i realtid någonstans på Internet. Denna metod är inte 100% tillförlitlig, men används i princip av alla större leverantörer som ett första filter.
Den andra metoden är att den mottagande e-postservern på ett mycket strikt sätt kräver att SMTP-sessionen mellan servrarna följer standarden och att de parametrar som definerats i denna standard faktiskt efterlevs. Det skall gå att slå upp värdnamnet som presenteras i någon DNS (den skall med andra ord inte heta ”.local” på slutet, som är vanligt även bland riktigt stora företag som man tycker borde ha råd att anlita kompetent personal).
Hur många som läser detta tror att man kan aktivera den sistnämnda metoden maximalt och ändå ta emot e-post? Jag har under en 12-månadersperiod studerat loggar från ett system som använde en kombination av programvaran Postfix (e-postserver) och DSPAM (skräppostfilter) där både Postfix och DSPAM var väldigt ”hårt åtskruvade”. Resultatet var fascinerande, men inte desto mindre irriterande. Över hälften av de äkta leveranser som stoppades i dörren kom från Microsoft Exchange-servrar hos börsnoterade bolag. Cirka en fjärdedel kom från e-postservrar vars namn inte gick att slå upp i någon DNS. Resten var en blandning av trasiga servrar som på ett eller annat sätt inte kommunicerar enligt specifikationen.
Konsekvensen? Man måste lätta på restriktionerna och därmed behandla e-postleveranserna på ett betydligt mer resurskrävande sätt. Hur många hänger med på argumentet att detta självklart också släpper igenom enorma mängder skräppost? Förslag? Gör rätt.
DNS
I takt med att fler attacker riktats mot företags och Internetleverantörers DNS:er så har säkerheten sakta blivit bättre. Många av attackerna skulle aldrig ha kunnat utföras om servrarna hade varit uppdaterade och/eller inte hade varit konfigurerade på ett sätt som kanske hade varit acceptabelt på 1980-talet, men knappast en bra bit in på 2000-talets första årtionde.
DNSSEC är ännu ett steg på vägen mot en bättre infrastruktur.
Även här finns det dock tyvärr ganska allvarliga brister; framför allt i sättet som de större leverantörerna konfigurerar sina DNS-servrar. Man åtsidosätter standarder och funktioner som finns inbyggda i ett väldokumenterat tillvägagångssätt för att minimera lasten på sina egna system. Det finns t ex sätt att påtala hur länge DNS-data skall få lagras i en tillfällig databas, en s k ”cache”. Detta missbrukas naturligtvis av sådana som inte förstår (eller inte vill förstå) hur dessa parametrar påverkar hela kedjan, men att som t ex Bredbandsbolaget och Telia inte klara av att en s k ”zonfil” har en omladdningstid på 15 minuter är bara ett tecken på den arrogans man visar när man får lite för många kunder som inte ställer krav. Vid flera tester i ”bruksmiljö” (som t ex bredbandskonsument) kan man inom loppet av sex timmar få två versioner av samma DNS-data, trots att det ursprungliga datat enbart finns hos Bredbandsbolaget. En cache som lever sitt eget liv kan man tänka sig.
Det finns fler exempel på arrogans och inkompetens. Det utvecklas också ständigt både nya hot och nya ”lösningar”. Om vi lade ned en bråkdel av vår kapacitet och resurser på att implementera det vi har på ett korrekt sätt så skulle vi kanske i lugn och ro kunna fokusera på morgondagens lösningar istället för att ständigt jaga gårdagens misstag.
Exit
Ett stort tack till alla gräsrötter, utvecklare, systemadministratörer, tekniker och beslutsfattare som osjälviskt fortsätter att arbeta för en säkrare, bättre konfigurerad och mer effektiv tillvaro på Internet.
Ett hett tips till alla er som utvecklar system som skapar e-post i någon form (beställnings- och bokningsbekräftelser, automatiska svarsmail, mm); sök efter ett standarddokument som beskriver meddelandefälten Message-Id och In-Reply-To. Ett amatörnätverk som heter FidoNet med ca 80 000 entusiaster och ett femtiotal utvecklare i sina glansdagar klarade av att hantera meddelandelänkning för 20 år sedan, KOM-systemen har fixat det ännu längre, jag tror ni grejar det också.