Spring til indhold

Tre låse på døren, ingen af dem låst

Har fundet og lukket tre SSH‑beskyttelser mod brute force, der aldrig havde virket: en jail, der holdt øje med port 22, mens dæmonen lyttede på 1986, en ratebegrænsning, som en bredere regel over den overskyggede, og en blokeringshandling, hvis binærfil aldrig blev fundet, så ingen blokering nogensinde var trådt i kraft.

  • Door handle, handle, metal
    Foto: jhenning / Pixabay
  • Door, keyhole, design
    Foto: ferobanjo / Pixabay

tre brute force‑forsvar, der aldrig havde virket

Situation. En hærdningsgennemgang af produktionsværten i august 2026 stillede et spørgsmål, der normalt får et selvsikkert svar: virker SSH‑beskyttelserne mod brute force. Alle tre var konfigureret, alle tre optrådte i hver eneste rapport, nogen kiggede i, og alle tre havde været uvirksomme siden den dag, værten blev bygget.

Opgave. Kontrollerne skulle efterprøves mod det, kernen rent faktisk gør ved en pakke, og ikke mod de konfigurationsfiler, der beskriver, hvad der burde ske med den.

Handling. At læse konfigurationen ville have bekræftet det forkerte svar tre gange, så gennemgangen læste det kørende system i stedet. Jailen, der skulle blokere indtrængningsforsøg, holdt øje med port 22, mens dæmonen var flyttet til 1986 under den indledende hærdning — hver blokering, den skrev, gjaldt en port, som intet lyttede på. Firewallens hastighedsbegrænsning var værre på en mere subtil måde: reglen fandtes, og den lå under en bredere regel, der matchede først. Firewallens brugerregler evalueres oppefra og ned, og det første match vinder, så en bred tilladelse over en hastighedsbegrænsning gør begrænsningen til død kode, der stadig står i hver statusoversigt. Den tredje var den mest tavse af dem: blokeringshandlingen kalder et eksternt pakkefilterprogram, som pakkesystemet kun anbefaler og ikke kræver, så på en vært uden programmet starter jailen, tæller og beslutter og fejler så i netop det øjeblik, hvor den forsøger at blokere. Alle tre rettelser var små. Det, der kom ud af det, var ikke rettelsen, men to regler, der nu gælder for repositoryet: en sikkerhedskontrol får en assertion og ikke en kommentar, og en firewall verificeres på reglernes placering og ikke på, om de findes.

Resultat. Tre beskyttelser, der aldrig én eneste gang havde grebet ind, gør det nu, og den fejlklasse, de tilhører — en kontrol, hvis fejltilstand er, at den bliver ved med at melde, at alt er i orden — er den klasse, som platformens tjek nu er bygget til at fange. Alle tre havde været uvirksomme lige fra bootstrap. Alle tre så sunde ud alle de steder, nogen kiggede, hvilket er hele grunden til, at de overlevede så længe.

Ét stykke af en længere fortegnelse — og det hele ligger her på sitet.

Hver post er skrevet på samme måde: situationen, opgaven, hvad vi gjorde, og hvad der ændrede sig.

Se hele fortegnelsen