Idag kretsar en hel del av arbetet här på Tripnet runt hur vi på bästa sätt upprätthåller säkerheten på de system som vi har driftansvaret för. Det har dock inte alltid varit så...
Följ med mig på en historisk resa och mina minnen från de första åren – från att tankarna på att starta en verksamhet började ta form 1994 till hur vi sedan kom i gång med vår modempool året därpå till att sedan utveckla webbhotellstjänster de kommande åren.
Från riks till lokalt
En av våra drivkrafter bakom att starta Tripnet var väldigt enkel. Det fanns inte någon lokal ISP i Göteborg vilket gjorde att man med uppringd internet betalade för ”rikssamtal” till Stockholm. Priset var över en krona i minuten, vilket snabbt blev kostsamt om man ville vara uppkopplad en längre stund. Detta gjorde att vårt fokus i början handlade om att etablera en modempool i 031-området för att slippa betala höga minutavgifter till Telia, som förresten precis hade bytt namn ifrån Televerket.
Direkt från start använde Tripnet Linux, vilket då var nästan nytt. Internetservrar kördes vanligen på någon av de stora Unixdialekterna som Solars från SUN, då dessa hade en stark ställning bland världens universitet och stod för en stor del av internetanvändandet. Att Tripnet valde Linux berodde på att en av grundarna hade experimenterat en del med Linux och hade insett hur prisvärd en standard-PC med Linux var, jämfört med en SUN med Solaris som han arbetade med till vardags.
Fokus på tillgänglighet och stabilitet
Den första tiden låg fokus på tillgänglighet och stabilitet, då allt inte var helt moget. Vi brottades med allt ifrån modem som blev opålitliga så fort de varit på några dagar till serieportsdrivrutiner med buggar som bara dök upp när man hade många serieportar i samma server. Detta ihop med att utvecklingen gick snabbt på Linux gjorde att vi ibland uppdaterade våra servrar dagligen i jakt på den senaste buggfixen som skulle lösa något av våra stabilitetsproblem.
Att lägga på patchar på sitt operativsystem var dessutom ett ganska stort äventyr jämfört med idag. På Linux-sidan var det normala förfarandet att kompilera sin egen kernel, och då laddade man inte ner hela källkoden på nytt eftersom den var stor och det tog lång tid, utan man utgick ifrån den version man redan hade och laddade bara ner patcharna, så kallade diff-filer, innan man kompilerade kerneln på nytt. Detta tog inte bara lång tid, det var också mer regel än undantag att något gick fel i hela processen och man fick börja från början. Även när man kommit hela vägen och installerat den nya kärnan var det fortfarande bäst att hålla tummarna för att den verkligen skulle boota. Att vi dessutom använde relativt ovanliga serieportkort i våra Linux-servrar för att kunna ansluta 24-modem till varje server, gjorde att vi drabbades av en del tidigare oupptäckta fel i Linux serieportsdrivrutin.
Daniel Ryde
Starkt stöd av ikoniske Alan Cox
För att få bukt med dessa fick vi hjälp Alan Cox som på den tiden var Linus Torvalds högra hand när det gällde utvecklingen av Linux. Han skrev kernel-fixar till oss men eftersom han inte hade den hårdvara vi använde, och vi själva inte hade några test- eller labb-servrar med denna hårdvara, hade dessa fixar inte testats alls innan vi körde dem i vår produktion. Kanske inte helt konstigt att både jag och Daniel Ryde, som var de två som mest jobbade med tekniken på Tripnet, lade oss till med vanan att ringa vår modempool varje gång vi hade varit i närheten av Tripnet och skulle åka hem. Det var lika jobbigt varje gång man kom hem och behövde vända i dörren för att något hade hängt sig! Tilläggas ska att ingen jobbade heltid på Tripnet. Vi hade inte heller något övervakningsverktyg som kunde larma när något var sönder utan fick förlita oss på att både vi själva och våra vänner och bekanta använde tjänsterna och ringde oss när något var trasigt.
Tripnet öppnade ett av Sveriges första webbhotell
I våra modemabonnemang ingick möjligheten att ladda upp en egen hemsida men den hamnade då på en adress som tillhörde Tripnet som kunden inte kunde påverka. Ganska snart började det dyka upp förfrågningar om att kunna ha webbsidor på kundens eget domännamn, vilket inte var helt enkelt att lösa. Varken http-protokollet eller den webbserver-mjukvara som var dominerande, NCSA HTTPd, var gjorda för att hantera flera olika domännamn på samma server. Detta var långt före de virtuella servrarna så normalt krävdes en dedikerad fysisk server för varje domännamn. Med en del arbete, pålagda patchar och andra workarounds lyckades vi faktiskt skapa ett av Sveriges första webbhotell där du fick eget domännamn och där det inte syntes i adressfältet i browsern att du delade server med andra kunder.
Men säkerheten då?
Nästan inga av de verktyg som idag är helt självklara och oundvikliga – i alla fall inte om du vill ha en Internetansluten server – användes och vissa av dem fanns inte ens ännu. Varken brandväggar, antivirus, kryptering eller 2FA var vanligt använda för Internetservrar. Vi använde inte heller VLAN, utan alla datorer, oavsett om de var webbservrar, klientdatorer eller Novell-filservern, satt på ett och samma nät som var direktanslutet till routern från vår Internetleverantör. Nätet var ett 10Mbit/s coax ethernet, Internetanslutningen var 64Kbit/s och WiFi var inte uppfunnet ännu. Novell-servern hade gissningsvis inte ens TCP/IP installerat, klientdatorerna kördes på Windows 3.11 och Trumpet Winsock. Microsoft släppte inte ens en egen IP-stack förrän i Windows 95.
De säkerhetsåtgärder vi jobbade mest med var att ”härda" operativsystemen, dvs stänga ned onödiga tjänster som var i gång som standard. En del av dem krävde inte ens inloggning för att kunna användas – eller missbrukas. En av anledningarna till att detta precis börjat ses som viktigt var att ett av de första sårbarhetsscanningsverktygen, SATAN, precis hade släppts. SATAN eller ”Security Administrator Tool for Analyzing Networks” som det egentligen hette men ingen någonsin kallade det, fick ganska stor uppmärksamhet då det dramatiskt förenklade arbetet med att skanna efter sårbara tjänster på ett nätverk och användes av hackare med både vita och svarta hattar. En del var av uppfattningen att det var oetiskt att släppa ett så här farligt verktyg fritt på internet men i efterhand så är det för mig ganska tydligt att det snarare satte fokus på att det var viktigt med säkerhet. Flera av de stora tillverkarna, såsom HP, Sun och IBM, kom som ett direkt svar på SATAN ut med bulletiner om vad systemadministratörer behövde göra för att säkra sina produkter – information som tidigare varit mycket svårare att hitta.
Kryptering var fortfarande i sin linda. Utvecklingen av funktioner som vi idag tar för givna, såsom SSH och HTTPS, pågick men var mer eller mindre oanvända, ofta av bra skäl. Till exempel blev HTTPS inte standard förrän år 2000 och innan dess var det inte säkert att en webbläsare från en tillverkare kunde prata med en webbserver från en annan om man försökte använda kryptering.
Eftersom kryptering inte användes var det fortfarande väldigt vanligt att lösenord skickades runt i klartext, vilket ju självklart var en säkerhetsutmaning. Fick man in någon typ av malware på en dator var en av de första saker den försökte göra att avlyssna nätet efter lösenord, och utan nätverkssegmentering, och inte ens några switchar, kunde alla datorer på ett nät avlyssna all trafik och lätt komma över alla lösenord som användes i nätet. Därför pågick ett arbete att byta till protokoll som åtminstone inte skickade lösenordet i klartext, till exempel var CHAP helt nytt och ansågs mycket säkrare än PAP som ersattes.
Säkerhetsarbetet påbörjades – och pågår fortfarande
Efter några år började 1995 års statiska webbsidor ersättas med mer avancerade webapplikationer, skrivna i språk som PHP, Java och ASP. Ungefär samtidigt började Microsoft få fotfäste på webbservermarknaden med NT4 och IIS. Webbshoppar började dyka upp och med dem ökade insikten om behov av säkerhet runt systemen, även om det fortfarande då var ganska många år kvar till att kortindustrin skulle ta fram sin säkerhetsstandard PCI. Kombinationen av mer komplicerade system och högre krav gjorde att säkerhetsarbetet började rullas framåt, och vad jag kan se så rullar det fortfarande. Vi på Tripnet fortsätter där vi började. Med förbättringsarbete och ökad användarnytta i fokus. Då kanske främst för att spara pengar och för att teknik var galet kul – idag mer för att skydda och värna om våra kunders värdefulla data. Och för att teknik är galet kul!
Fortsätt läsa – The Tripnet story!
