Dette er del to i denne kronikkserien om OpenBSD. I den første delen fortalte kronikkforfatteren blant annet om hvordan han kunne få løst visse utfordringer med maskinvarestøtten på kort tid ved å kommunisere direkte med utviklerne.
Det aner meg at du lurer på hva det var som fikk meg til å gå over til å være nesten ren OpenBSD-bruker.
I 2001 var OpenBSD fortsatt noe jeg bare eksperimenterte med, men erfaringene med å bruke Linux og iptables hadde fått meg til å bli veldig motivert for å skifte til en mer fornuftig konstruert brannmur. Jeg hadde eksperimentert litt med brannmuren IPF, som var i OpenBSD til og med versjon 2.9. Så skjedde det som noen av oss kanskje husker: OpenBSD-utviklerne og andre ble klar over at lisensen som IPF var utgitt under, faktisk ikke var fri og ikke tillot endringer, så det var nødvendig å skifte ut dette ganske omfattende delsystemet med noe annet.
Faktisk var det mest sikkerhets-orienterte, frie operativsystemet i verden uten et pakkefilter i
-current i noen uker i 2001.
Utviklerne jobbet intenst, nesten febrilsk, i de påfølgende månedene med å erstatte IPF. Faktisk var det mest sikkerhetsorienterte, frie operativsystemet i verden uten et pakkefilter i -current i noen uker i 2001. Heldigvis viste det seg at den nye koden hadde bedre ytelse enn delsystemet som det erstattet. Det nye delsystemet, The OpenBSD Packet Filter, som oftest forkortet til PF, var kommet til verden og ble presentert i OpenBSD 3.0 i desember 2001. Opprinnelig hadde planen vært å gi ut denne versjonen i november, men det ble forskjøvet en måned for å få hacket «den fungerende prototypen» til en form som var virkelig brukbar og nyttig i praksis.
Det var, som en kanskje kan tenke seg, disse hendelsene som fikk meg til å ta de siste stegene i retning av å erstatte de Linux-baserte gatewayene jeg hadde i drift, med OpenBSD. I prosessen fikk jeg en del behagelige overraskelser. Ikke bare var ytelsen bra, men da jeg så bedre etter, inneholdt OpenBSD i basesystemet en ganske komplett samling verktøy som var godt dokumenterte og som gjorde at jeg fikk bedre innsikt enn tidligere i hva som faktisk skjedde. For meg var det begynnelsen på en prosess som blant annet førte til at jeg skrev The Book of PF og tok den teksten gjennom tre utgaver så langt. Men mer om det senere.
Avslørte dårlig IT-sikkerhet i forskningssektoren: Slik brøt de seg inn i systemene
Full lisensgjennomgang
Det er verdt å nevne at episoden med IPFs ikke godtagbare lisens førte til at OpenBSD-utviklerne gjennomførte en lisensgjennomgang gjennom hele kildekode-treet og ports (portet tredjepartsprogramvare) for å unngå å få tilsvarende episoder i fremtiden. Denne aktiviteten gikk over en del måneder og avdekket et ikke ubetydelig antall potensielle problemer. Theo de Raadt oppsummerte arbeidet i en melding til e-postlisten openbsd-misc 20. februar 2003.
I den systematiske gjennomgangen fant utviklerne et ikke ubetydelig antall filer som faktisk ikke var utgitt under en fri lisens, på samme måte som hele IPF-delsystemet hadde vært. Dette var kode som det var nødvendig å erstatte. I andre deler var det enten ikke oppgitt noen lisens eller ikke angitt hvem som hadde opphavsrett. I noen tilfeller ga utviklerne eksplisitt tillatelse til å fortsette å bruke koden, men det var en hel del programvare som det var nødvendig å skrive på nytt og utgi under fri lisens, slik at OpenBSD og annen fri programvare kunne gå videre uten opphavsrettslige problemer.
Senere hørte jeg i en uformell sammenheng at i de tilfellene det ikke fantes noen angitt opphavsrett eller lisens, var det ofte mulig å finne ut hvem som hadde utviklet koden via logger i versjonskontrollsystemer eller via arkiverte e-postlister. I svært mange av disse tilfellene var første reaksjon noe i retning av «Hva? Er det fortsatt noen som bruker det der?».
SSH, åpen og bedre
PF ble som nevnt skrevet fra bunnen av for å erstatte et delsystem som det viste seg var ulovlig å bruke i fri programvare-sammenheng. Men det var ikke første gang OpenBSD-prosjektet hadde erstattet kode fordi lisensen ikke var akseptabel.
Noen få år før episoden som førte til at PF ble utviklet, ble det klart at de som opprinnelig hadde utviklet systemet for sikker shell-pålogging, ssh, hadde fått forretningsmessige ambisjoner og hadde endret lisensen i klart proprietær retning. Etter en del diskusjon startet OpenBSD-utviklerne med å finne frem til tidligere versjoner av koden som hadde blitt utgitt under en akseptabel lisens. De fant en eldre versjon som oppfylte kravene og startet en forgrening av koden. Så fulgte en periode med å utvikle mer moderne funksjonalitet som manglet i den gamle koden.
Resultatet ble lansert som OpenSSH i OpenBSD 2.6 i 1999.
Resultatet ble lansert som OpenSSH i OpenBSD 2.6 i 1999. I løpet av de neste få årene fikk vi en -portable-versjon av OpenSSH, som ble tatt i bruk i andre systemer og begynte å ta over markedsandeler i høyt tempo. Sist jeg sjekket, var OpenSSHs markedsandel et sted i den høyere delen av nittitallet i prosent.
Med industristandarden for sikker shell-pålogging på plass, og som for hver eneste versjon fikk ny og nyttig funksjonalitet, kom tiden endelig til å gjøre slutt på ikke-krypterte shell-pålogginger i OpenBSD. OpenBSDs telnetd ble fjernet fra den aktive delen av CVS før OpenBSD 3.8 ble utgitt i november 2005.
En annen ting som er verd å merke seg om OpenSSH, er at den var den første daemonen som fikk innført privilegieseparasjon. Privilegieseparasjon er en praksis som ble innført i en grundig overhalt OpenSSH i OpenBSD 3.2 i mars 2002. Siden den tid har privilegieseparasjon blitt innført i alle daemoner i OpenBSD der det var verdt innsatsen å gjøre det, og det er nå en helt sentral del av «sikker i utgangspunktet»-praksisen som er utgangspunktet for alle nyere deler av OpenBSD.
Slik vil Tiktok stilne kritikken mot selskapet
Å ja, det pakkefilteret
Jeg nevnte OpenBSDs pakkefilter PF tidligere. PF har vært en viktig del av livet for meg i mange sammenhenger siden tidlig 2000-tall. I løpet av disse årene må jeg innrømme at ting jeg har skrevet har bidratt til å etablere en utbredt, men rent faktisk feilaktig, forestilling om at OpenBSD er et operativsystem som nesten bare kan brukes til brannmurer. Det er mange nyttige og ganske morsomme funksjoner som har dukket opp i eller i tilknytning til PF, og som OpenBSD var først eller tidlig ute med. Noen funksjoner ble portet til eller imitert i andre systemer, mens andre av forskjellige grunner fortsatt bare finnes i OpenBSD.
Så jeg skal kort fortelle om noen av funksjonene i PF, eller som har nær tilknytning til PF, som jeg selv har hatt stor glede av, i litt tilfeldig ,men nesten kronologisk rekkefølge.
Plaging av spammere med OpenBSD spamd(8)
Da jeg begynte å leke med OpenBSD generelt og PF spesielt den gangen for lenge siden, hadde jeg allerede ansvar for SMTP-eposttjenesten for en liten gruppe kolleger og venner. Gatewayene kjørte OpenBSD, mens mailserveren rosalita (oppkalt etter en Springsteen-låt), var en relativt godt utrustet server, som kjørte FreeBSD med exim som e-postserver-program, som så kjørte mottaket av meldinger gjennom spamassassin og clamav for innholdsfiltrering, før det gjenværende ble lagt i brukernes postkassefiler.
Så da det gikk opp for meg at jeg kunne sette opp OpenBSDs spam-forsinker spamd(8) på gatewayen som stod ut mot internett, og avlaste stakkars rosalita som gikk ganske så varm på grunn av innholdsfiltreringen, tok det ikke lang tid før jeg satte i drift noe som hentet inn og brukte velkjente blokkeringslister.
Telenor synker på bredbånd – men fiberkundene blir flere
Først farge grått, så fange
I løpet av få minutter ble viftestøyen fra postserveren betydelig redusert.
Effekten viste seg umiddelbart. I løpet av få minutter ble viftestøyen fra postserveren betydelig redusert. Så da spamd også fikk utviklet grålisting kort tid etter, innarbeidet jeg også det i konfigurasjonen, og hørte at viftestøyen fra rosalita igjen gikk ned både i tone og volum. Etter enda et par versjoner fikk vi gråfanging (greytrapping) – en teknikk som går ut på å legge IP-adressene fra SMTP-forbindelser vi mottar i blokkeringslister dersom leveringsforsøket er til adresser i domener vi håndterer som vi har angitt som ugyldige – og det hørtes ut som underholdningspotensial godt nok til at jeg ikke nølte med å ta det i bruk.
Ideen med å identifisere spamkilder ved hjelp av de oppdiktete adressene de allerede forsøkte å levere til, hørtes bare ut som for bra til ikke å prøves. Vi visste også at det ville være uhyre lett å komme i gang. Vi hadde lenge sett oppføringer for mislykkete leveringsforsøk i loggene på e-postserverne, mange med forsøk på å levere til adresser som aldri hadde eksistert i våre domener. Dermed var det bare å høste fra ganske rikholdige kilder og legge inn slikt vi var sikre på aldri ville bli gyldige adresser i listen over spamfeller. Jeg tror den første konfigurasjon hadde et par hundre oppføringer, men jeg noterte ikke nøyaktig antall da vi startet.
I juli 2007 hadde jeg bestemt meg for å offentliggjøre både listen over spamfeller og en liste med gråfangete adresser, som ble generert en gang i timen. Begge disse listene er fortsatt tilgjengelige og kan lastes ned gratis. Listen over spamfeller, som i mellomtiden har blitt utvidet med stoff fra flere kilder, inneholder nå litt over 270.000 fantasivenner, mens antallet IP-adresser som til enhver tid er gråfanget, ligger typisk et sted mellom 3000 og 5000. Til tider vokser listen til 20.000 eller mer, typisk når noen kjører kampanjer der de bruker adresselister med påtakelig lav kvalitet. Jeg er nokså sikker på at listen har vært på mer enn 100.000 ved noen anledninger.
Poenget med det hele er at det er underholdende å se på innimellom, og det ser helt klart ut som en ikke helt liten andel av våre spamfeller har blitt innlemmet i adresselistene som aktive spamsendere rutinemessig bruker. Jeg hadde i utgangspunktet ikke trodd at jeg fortsatt ville drive med å sanke inn nye spamfeller så mange år etter at vi begynte. Ja, det høres egentlig ganske absurd ut, men det fungerer godt for å holde innboksene her stort sett spam-frie, selv om det av og til føles litt som å drive med et litt aparte kunstprosjekt. Hvis du er interessert i mer informasjon om listene vi tilbyr, er denne artikkelen et bra utgangspunkt.
Dette er en serie i tre deler. Første del er tilgjengelig her. I tredje og siste del, som kommer i morgen, ser Peter Hansteen nærmere på hva OpenBSD kan tilby av enkle grep for å stoppe passordgjettere, samt hvordan operativsystemet fikk ny og bedre nettverksadresseoversetting, trafikkforming, hvordan skaffe innsikt i nettverkstrafikk og et TLS-delsystem som trengte vennlig, men bestemt behandling for at det skulle være mulig å ta med seg inn i en sikrere fremtid.
Konsulenthus åpne om skyhøyt lønnsnivå: Ti års erfaring gir en årslønn opp mot 2,1 millioner kroner
