# Vært ## Hvad det er En vært er en computer for enden af en netværkssti: den maskine, trafikken er adresseret til og kommer fra, i modsætning til de routere og switche, der kun sender den videre. Mange teknikere bruger det engelske ord _host_ uændret. Navnet, maskinen svarer på, er dens _værtsnavn_, og i virtualisering taler man om den fysiske vært, der bærer gæstemaskiner. At _hoste_ noget, som i webhosting, er at køre det på sådan en maskine. Internettets egen definition er fra oktober 1989. RFC 1122, kravdokumentet for internetværter, kalder en værtscomputer, eller bare en vært, den endelige forbruger af kommunikationstjenester, en maskine, der som regel kører applikationsprogrammer på vegne af sine brugere. Den svarer til det, OSI-modellen kaldte et slutsystem. Netværkene mellem værterne er forbundet af gateways, som i dag hedder routere. Det samme dokument dækker alt fra værter med ét enkelt formål til værter med fuld service og kalder en vært med mere end ét netværksinterface for multihomed. Grænsen mellem vært og router trækkes af adfærd, ikke af hardware. RFC 1122 siger, at enhver vært, der videresender datagrammer, som en anden vært har skabt, optræder som gateway, kræver en kontakt, der slår gateway-funktionen fra, og kræver, at den kontakt som standard står på fra. En vært med to netværksinterfaces begynder altså ikke selv at videresende. En bærbar, en telefon, en printer, en lejet virtuel maskine og en container med sin egen adresse er alle værter. NIST's ordliste har to definitioner side om side. Den ene regner enhver hardwareenhed med en vej ind på et netværk. Den anden, fra vejledning om at sikre webservere, siger, at en server er vært for sine klienter, og at en klientstation også er en vært, fordi den er en kilde til information på netværket, i modsætning til en router eller switch, der dirigerer trafik. Det er den nyttige kontrast til ordet server. En server er en rolle, et program udfylder ved at svare på forespørgsler. En vært er maskinen, hvad enten den svarer nogen eller ej. Én vært kan køre mange servere, og en bærbar, der kører nul servere, er stadig en vært. En vært samler navne. Søsterdokumentet RFC 1123 fastlagde reglerne for værtsnavne: det første tegn må være et bogstav eller et ciffer, værtssoftware skal kunne håndtere navne på op til 63 tegn og bør kunne håndtere navne på op til 255, og hvor en bruger kan skrive en værts navn, bør det også virke at skrive dens adresse i punktum-decimal form. Oven i det kan DNS pege et vilkårligt antal navne på én adresse, og HTTP lader en klient sige, hvilket af dem den vil have, i feltet `Host` i hver forespørgsel, så én vært kan svare for mange sites. ## Hvorfor det betyder noget Værten er den enhed, driften tæller i. Inventarer opregner værter, overvågning holder øje med værter, firewallregler og adgangslister navngiver dem, og cloududbydere fakturerer dem pr. time eller måned. En plan, der siger »tilføj en vært«, er konkret på en måde, som »tilføj kapacitet« aldrig bliver: den betyder én maskine mere, der skal oprettes, navngives, opdateres, sikkerhedskopieres og betales. Den er også den enhed, der bliver kompromitteret. Den, der styrer en vært, styrer hvert serverprogram på den, hver nøgle på dens disk og hver forbindelse, den kan oprette. Det, en vært rummer, bestemmer, hvad det koster at miste den, og derfor beslutter omhyggelige driftsfolk pr. vært, hvilke hemmeligheder, hvilke data og hvilke netværksveje den får, og giver den ikke mere. Og det er her, navnene mødes. Den samme maskine kendes på navnet i inventaret, det navn, den kalder sig selv, de DNS-navne, der peger på dens adresse, og navnene i de forespørgsler, den modtager. Når de stemmer overens, fører en loglinje, en alarm og en supportsag til den samme kasse. Når de glider fra hinanden, bruger den, der bliver kaldt ud om natten, de første minutter af hændelsen på at finde maskinen. ## Sådan ser det ud i praksis Dette sites driftsarbejde behandler værten som det, der bygges fra kode og får sine egne hemmeligheder. Da platformen skulle have en ekstra maskine hos en anden udbyder, blev det sådan, at [en ny vært kan oprettes eller overtages igen fra repositoryet](/da/portfolio/provisioned-a-second-server-from-code-123/). Den første maskine var oprettet manuelt og havde fået sin firewall bagefter, og det efterlader et tidsvindue, hvor en helt ny vært med en standardpolitik for adgangskoder kan nås fra internettet. Rollen, der opretter den nye, overtager en eksisterende maskine i stedet for at lave en dublet, så det er sikkert at køre den igen, og dens egen fil oplyser instanstype, region, specifikation og den månedlige pris i euro, fordi den er den eneste rolle i repositoryet, der bruger penge. Overgangen fra én vært til to afslørede derefter hver værdi, der var skrevet ud fra en antagelse om, at der altid kun ville være én. [Hver driftshemmelighed blev en tabel med værten som nøgle](/da/portfolio/split-every-operational-secret-per-host-125/). Siden beskriver, hvorfor deling var forkert på to måder. En dead man's switch, som to værter deler, alarmerer mindre end to switches, ikke mere: så længe én af værterne stadig melder sig, forbliver den grøn, mens den anden er død. Og to værter, der deler en adgangssætning til backup, er ét lager med to mapper. Den eksisterende vært blev skrevet ind i alle fire tabeller med sit lager og begge switches tomme, hvilket siden kalder den sandfærdige tilstand. Set fra en besøgendes side betyder ordet noget mindre: et navn, browseren kontakter. Sikkerhedssiden opfordrer læseren til at [åbne browserens netværksfane og tælle værterne](/da/security/), og siger, at der er én, og at den er sitets egen. ## Hvor det går galt **En vært begynder at videresende trafik, den kun skulle modtage.** Containernetværk og VPN-software slår IP-videresendelse til, og fra da af router værten mellem sine interfaces. Dockers dokumentation siger for eksempel, at Docker slår begge indstillinger herunder til, når den starter, og derefter dropper videresendte pakker, medmindre en regel accepterer dem. Hvor videresendelse er slået til uden sådan en regel, lader firewallregler, der er skrevet til trafik adresseret til værten, trafik, der passerer igennem den, være i fred, og et netværk bag den kan nås ad en vej, som ingen har tegnet. Læs kontakterne, og skriv regler for videresendelse med vilje, hvor de viser `1`: ```sh sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding ``` **Navnene er uenige.** Inventaret siger én ting, maskinen kalder sig det, udbyderens image valgte, DNS har et tredje navn og TLS-certifikatet et fjerde. Hver alarm bærer så det navn, ingen bruger. Tag maskinens eget værtsnavn fra samme kilde som inventaret og DNS-posterne, og sæt det, når værten oprettes, i stedet for når nogen lægger mærke til det. **En server svarer på hvilket som helst værtsnavn, den får.** Feltet `Host` kommer fra klienten, og en server, der besvarer ukendte navne med et standardsite, bygger links, omdirigeringer og cachede sider ud fra et navn, en angriber har valgt. RFC 9110 advarer om, at feltet ofte er mål for skadelig software, der vil forgifte en delt cache eller omdirigere en forespørgsel til en utilsigtet server. Svar kun på de navne, værten faktisk betjener, afvis resten, og byg absolutte links ud fra konfigurationen i stedet for ud fra forespørgslen. **Klonede værter deler identitet.** En maskine, der er kopieret fra et image, bærer, hvad imaget indeholdt: SSH-værtsnøgler, tokens, nogle gange en adgangssætning til backup. Klienter kan så ikke længere skelne kopierne fra hinanden, og ét læk åbner dem alle. Generér værtsnøgler ved første opstart, hold hemmeligheder ude af images, og giv hver vært sin egen post, hvor en hemmelighed konfigureres. ## Læs mere - [host — NIST CSRC Glossary](https://csrc.nist.gov/glossary/term/host) — begge definitioner, også den, der stiller værter op over for routere og switche. - [RFC 1122: Requirements for Internet Hosts, Communication Layers](https://www.rfc-editor.org/rfc/rfc1122.html) — definitionen af en vært fra 1989, multihoming og videresendelse, der som standard er slået fra. - [RFC 1123: Requirements for Internet Hosts, Application and Support](https://www.rfc-editor.org/rfc/rfc1123.html) — reglerne for værtsnavne og deres længder i afsnit 2.1. - [RFC 9110, HTTP Semantics: Host and :authority](https://www.rfc-editor.org/rfc/rfc9110.html#section-7.2) — hvordan én server holder mange værtsnavne ude fra hinanden, og hvorfor feltet er et mål.