Dette er den tredje og siste delen i kronikkserien til Peter Hansteen om nylige og ikke helt nylige endringer i OpenBSD som gjør livet bedre. Her ser han nærmere på hva operativsystemet kan tilby av enkle grep for å stoppe passordgjettere, hvordan det fikk ny og bedre nettverksadresseoversetting, samt trafikkforming, hvordan man skaffer seg 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. Del én og del to bør leses først.
Storebrand flytter kritisk plattform til utlandet
Botene, passordgjetterne og tilstandssporingen
Hvis du kjører SSH eller egentlig en hvilken som helst tjeneste med mulighet for pålogging fra et nettverk som du ikke selv har kontroll på, vil du se et eller annet antall mislykte påloggingsforsøk som legger etter seg støy i loggene. Passordgjetting, eller som noen av oss kaller det, passordtafsing, ble etter hvert irriterende nok for relevante personer til at vi i OpenBSD 3.6-current, og senere OpenBSD 3.7, fikk en samling av funksjoner som bruker data som finnes i nettverksstakken om aktive forbindelser, på nye måter.
Dataene finnes uansett, men det nye var at vi fikk verktøy som ga mulighet til å bruke dataene til å utløse handlinger basert på terskelverdier du definerer, eksempelvis antall forbindelser fra en bestemt IP-adresse i løpet av et gitt antall sekunder.
Handlingen kunne for eksempel være å legge til i en tabell den IP-adressen som var kilde for trafikken som gikk over grensen. Trafikk fra adresser i den tabellen kunne så, med andre regler, behandles på andre måter enn annen trafikk. Siden den tid har regelsettene på steder jeg har kontroll over, som er eksponert mot internett, typisk hatt noe som likner dette:
table <bruteforce> persist
block quick from <bruteforce>
pass inet proto tcp from any to $localnet port $tcp_services \
flags S/SA keep state \
(max-src-conn 100, max-src-conn-rate 15/5, \
overload <bruteforce> flush global)
som betyr at om en maskin prøver mer enn hundre samtidige forbindelser, eller mer enn femten nye forbindelser i løpet av fem sekunder, blir de lagt til i tabellen og så blokkert, mens alle eksisterende forbindelser blir kuttet.
Tafseboter som dette vil etter all sannsynlighet ikke bli fikset før det har gått så lang tid
Det er god praksis å la oppføringer i slike tabeller gå ut på dato og bli fjernet etter en viss tid. Til å begynne med fulgte jeg eksempelet fra standardinnstillingen til spamd(8) og lot foreldelsen stå på 24 timer. Men med det vi vet om passordtafser-boter av typen som lar seg fange av disse reglene, ble det til at jeg for noen år siden gikk over til foreldelse først etter fire uker og noen måneder senere økte til seks uker. Tafseboter som dette vil etter all sannsynlighet ikke bli fikset før det har gått så lang tid. Og siden denne teknikken kan brukes for alle typer tjenester du måtte finne på å kjøre, vil tilstandssporing med overløp til tabeller være nyttig også for andre tjenester enn SSH.
I artikkelen «Forcing the password gropers through a smaller hole with OpenBSD's PF queues» finnes det noen eksempler på støybegrensning for andre tjenester.
På mange måter har tilstandssporingen mye til felles med gråfangingen som vi finner i spamd. I begge tilfellene har du her alt du trenger for å lage en konfigurasjon som tilpasser seg forholdene i nettverket og lærer ut fra trafikken den blir utsatt for.
Dette går ikke til et nivå som kan påstås å være kunstig intelligens (KI eller AI), men potensialet for å lage kvasi-vitenskapelige markedsføringsbegreper er såpass åpenbart at jeg undres over at ingen av de andre velkjente aktørene i markedet har imitert denne funksjonaliteten og markedsført den for alt det kunne være verdt.
Jeg vet hva jeg ville gjort i deres sted. Men jeg er mer tekniker enn markedsfører, og i alle kontekster der jeg bestemmer, er det beste alternativet bare å fortsette med å kjøre OpenBSD.
Dybdekirurgi på NAT
Da utviklingssyklusen frem til OpenBSD 4.7 kom i gang, hadde Henning Brauer lenge vedlikeholdt en diff på flere tusen linjer – som faktisk gjorde koden mindre etter påføring – og som inneholdt en total omskriving av koden for nettverksadresseoversetting i IPv4.
Tidligere versjoner av PF hadde regler av type 'nat on $interface' og 'rdr on $interface' , mens den nye koden i stedet innførte nat-to og rdr-to som alternativer for pass- eller match-regler.
Nøkkelordet match hadde blitt innført i OpenBSD 5.6 for å utføre handlinger på pakker og forbindelser, uten at det påvirket om trafikken skulle passere eller bli blokkert, typisk for å legge på spesifikke innstillinger eller legge til markører (tags), som så kunne føre til noe behandling senere i regelsettet. Nå med den omfattende omskrivingen av NAT med ny syntaks, ble det enda klarere at match var nyttig nøkkelord og funksjonalitet.
Med omskrivingen av NAT-behandlingen kom det mye ny fleksibilitet som kom til nytte for de av oss som skriver PF-regelsett. Og for min egen del gjorde denne endringen det nødvendig å skrive andre utgave av The Book of PF, som vi siktet inn på å være tilgjengelig så nær som mulig til utgivelsesdatoen for OpenBSD 4.7. Og ja, den nye, omskrevne koden ga bedre ytelse.
Nå blir det enklere å kode for forskere som jobber med biologiske data
Vi fikk moderne trafikkforming
I OpenBSD har trafikkforming vært en del av operativsystemet med delsystemet ALTQ siden helt tidligste tider. ALTQ ble integrert i PF nokså raskt, men koden ble fortsatt regnet som eksperimentell 15 år etter at den opprinnelig ble utviklet. I tillegg var syntaksen for konfigurering komplisert og – i de aller flestes øye – i beste fall lite elegant, i den grad at svært mange som prøvde å bruke systemet, ga opp uten å få til noe tilfredsstillende.
Henning Brauer engasjerte seg sterkt i problemet og konkluderte med at de mange forskjellige algoritmene i ALTQ faktisk var overflødige. Alle utenom én kunne bli redusert til enkle konfigurasjonsalternativer, enten ved å sette prioritet på pass- eller match-regler eller som variasjoner over temaet med basisalgoritmen Hierarchical Fair Service Curve (forkortet til HFSC).
Etter kort tid begynte en ikke helt liten diff å sirkulere mellom utviklerne. Patchen ble påført tidlig i utviklingssyklusen frem mot OpenBSD 5.5, og i den versjonen eksisterte både det nye systemet og ALTQ side om side.
All tilbakemelding jeg har registrert, går ut på at den mer rasjonelle syntaksen som det nye systemet bruker, har ført til at flere brukere enn tidligere har implementert trafikkforming. Her er en definisjon av køer for trafikkforming som jeg lagde for en av mine installasjoner:
queue rootq on $ext_if bandwidth 20M
queue main parent rootq bandwidth 20479K min 1M max 20479K qlimit 100
queue qdef parent main bandwidth 9600K min 6000K max 18M default
queue qweb parent main bandwidth 9600K min 6000K max 18M
queue qpri parent main bandwidth 700K min 100K max 1200K
queue qdns parent main bandwidth 200K min 12K burst 600K for 3000ms
queue spamd parent rootq bandwidth 1K min 0K max 1K qlimit 300
Denne endringen utløste et klart behov for å skrive tredje utgave av The Book of PF. Boken inneholder beskrivelser av både det nye og det gamle systemet, sammen med noen tips om hvordan en kan gå til en udramatisk overgang. ALTQ ble fjernet fra OpenBSD i syklusen som førte til OpenBSD 5.6, men finnes fortsatt i en eller annen form i FreeBSD og NetBSD.
Og hvis du tror at mine kø-definisjoner her setter opp noe som straffer spammere litt i tillegg til å bli utsatt for spamd(8), har du helt rett.
pflow(4) tilbyr nettverksinnsikt «lite»
Alle som har hatt i oppgave å passe på et nettverk, har før eller siden blitt i alle fall litt nysgjerrig på hva som faktisk beveger seg i nettet. Tidvis er det også behov for feilsøking, og det blir helt nødvendig å se hvordan trafikken flyter, mellom hvilke endepunkter, antall pakker og byte overført, hvilke protokoller som er brukt og så videre.
Hvis du ikke har behov for å se innholdet i dataene som blir overført, men er mer interessert i metadataene som beskrevet over, er standarden NetFlow og den nære slektningen IPFIX akkurat det du trenger. Netflow-verktøy var tilgjengelige som pakker på OpenBSD allerede, men fra og med OpenBSD 4.5 har PF tilstandssporing-alternativet pflow, som sammen med det virtuelle nettverksgrensesnittet pflow(4) tilbyr en fullverdig sensor-pakke for netflow-data.
Oppsettet er enkelt, du definerer ett eller flere pflow-grensesnitt som sender data til en eller flere innsamlere (collectors), og du legger til tilstandssporingsalternativet pflow på de reglene som er interessante å spore, eller som standardverdi for regelsettet, og så er innsamlingen i gang. Du kan til og med sende trafikk som treffer bestemte regler til separate pflow-enheter og innsamlingspunkter.
Artikkelen «Yes, You Too Can Be An Evil Network Overlord – On The Cheap With OpenBSD, pflow And nfsen» gir noen forklaringer og praktiske eksempler med en historie om hvordan vi en gang brukte en pflow-konfigurasjon til å finne og fjerne en støykilde i et lokalnett, pluss noen henvisninger til annen nyttig litteratur.
Har knekt koden: Ingen sak å lære unge talenter Cobol-programmering
LibreSSL, fordi det ikke hang på greip
Jeg hører ofte at folk tror at LibreSSL eksisterer som direkte følge av Heartbleed-episoden, men faktisk var det ikke slik. Men det var nær i tid.
LibreSSL-prosjektet ble faktisk startet noen uker før Heartbleed ble allment kjent. LibreSSL ble til fordi en gruppe OpenBSD-utviklere tok eksisterende kode fra OpenSSL og begynte å fikse.
Denne gangen var det ikke fordi koden hadde feil lisens. Nei, grunnen var at antallet OpenBSD-utviklere som begynte å lese OpenSSL-koden, som hadde vært del av OpenBSDs basissystem siden ganske tidlig, og kastet seg vekk med stigende kvalme og symptomer på annet fysisk ubehag, hadde kommet til en slags kritisk masse. Jeg hadde hørt OpenBSD-utviklere beklage seg over den rett ut grusomme koden i OpenSSL i mer enn ti år. Kodekvaliteten var bare helt utrolig ille.
Dette førte til at en gruppe hardkokte OpenBSD-utviklere tok koden fra OpenSSL og satte i gang to aktiviteter parallelt. Én var å se i OpenSSLs åpne bugrapport-system etter feilrapporter som ikke hadde blitt behandlet. Den andre aktiviteten var å omformatere OpenSSL-koden til noe som liknet OpenBSDs konvensjoner for lesbar og vedlikeholdsvennlig C.
Etter at koden hadde blitt mer leselig, ble det enklere å finne ut hva den faktisk gjorde. I tillegg til noen få åpenbare bugs som gjorde vondt å se på, fant LibreSSL-utviklerne en del særheter. Noen av disse, men langt fra alle er
- Ingen kode ble noen gang slettet, selv når den ble foreldet eller bare ikke relevant.
- OpenSSL brukte ikke operativsystemets normale minneallokering, men hadde i stedet implementert sitt eget system for dette, som aldri frigjorde minne etter bruk, men i stedet brukte det på nytt etter LIFO-prinsipp (sist inn, først ut) og lett kunne overtales til å lagre privat informasjon i logger.
- Det var skrevet i «OpenSSL C», som ifølge beck@ er en dialekt basert på «verste mulige fellesnevner» (worst common denominator).
Det er vel verdt å grave frem artikler og presentasjoner som LibreSSL-utviklere har laget i løpet av årene som har gått. Et tidlig høydepunkt er Bob Becks foredrag på BSDCan om de første 30 dagene med LibreSSL. (Takket være rask tenking av Jason Tubnor er det foreviget på Youtube). Denne presentasjonen er første registrerte bruk av begrepet «kodeflensing» (code flensing).
Siden OpenBSD 5.6 ble utgitt i 2014, har LibreSSL vært standard TLS-bibliotek i OpenBSD. LibreSSL har blitt portet til andre plattformer med utgangspunkt i -portable-varianten.
For min egen del kan jeg bare si at jeg aldri har kommet ut for et TLS-problem som var LibreSSL sin feil. Sannsynligvis finnes det fortsatt feil i koden, men LibreSSL er sannsynligvis et sunnere alternativ enn forgjengeren.
Dette var min liste av endringer i OpenBSD som har gjort livet bedre - jeg vil gjerne høre om dine erfaringer
Som jeg skrev innledningsvis, har dette vært min personlige oppsummering om hendelser i OpenBSD som jeg har satt stor pris på.
Sannsynligvis har du noen andre hendelser som du synes er viktigere. Det finnes nesten helt sikkert noe som er med i OpenBSDs liste med nyvinninger som jeg rett og slett har glemt mens jeg skrev dette.
Med hver nye versjon kommer det en detaljert liste over endringer, som denne for OpenBSD 6.9, og siden har referanser tilbake til tilsvarende sider for tidligere versjoner.
Om du har noen spesielle øyeblikk du setter pris på med OpenBSD, vil jeg veldig gjerne høre om dem.
Et foredrag som er sterkt beslektet med denne artikkelen, vil bli holdt hos NUUG i oktober.
Dette er en serie i tre deler. Første del er tilgjengelig her. Andre del finner du her.
Studie: Energiforbruket for populære programmeringsspråk er skyhøyt
