Sådan selvhoster du CyberChef i 2026: sikker adgang, stateless hosting og opdateringer

Den korteste CyberChef-demo beviser, at en proces lytter på port 80. Produktion kræver stærkere dokumentation. Den skal bestå dette scenarie, selv efter at containeren er blevet udskiftet: opbyg en opskrift med flere trin, eksportér den, behandl en repræsentativ fil, og bekræft, at output-hashen matcher en kendt værdi.

CyberChef implementeres med et klart formål: som en browserbaseret arbejdsbænk til encoding, decoding, parsing og kryptografi. Den mest almindelige implementeringsfælde er, at store operationer opbruger browserens hukommelse, selv om serveren er sund. Derfor skal håndtering af offentlige URL'er og persistent state have samme opmærksomhed som opstart af imaget.

Vælg den mindst mulige CyberChef-topologi

Et nyttigt CyberChef-diagram viser den offentlige rute, den private port 80, state-grænsen og alle understøttende krav. Markér, hvilke pile der transporterer credentials, og hvilke der er almindelig brugertrafik. Standardbygget til CyberChef kræver hverken database eller en separat persistent runtime-service. Hold webcontaineren udskiftelig, og placér eventuelle fremtidige komponenter til authentication, collaboration eller storage bag en separat, dokumenteret grænse.

Bevis diagrammet med én reel handling: opbyg en opskrift med flere trin, eksportér den, behandl en repræsentativ fil, og bekræft, at output-hashen matcher en kendt værdi. Den største belastning kommer sandsynligvis fra browserens hukommelse og CPU ved store opskrifter frem for beregninger på containersiden i den almindelige statiske deployment. Overvåg derfor denne sti i stedet for at behandle alle HTTP-requests ens.

Kør den første produktionslignende instans

Brug containeren som en udskiftelig runtime – ikke som stedet, hvor sandheden ligger.

docker run -d \
  --name cyberchef \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  ghcr.io/gchq/cyberchef:latest

Bekræft den lokale forudsætning, før tjenesten eksponeres: Standardklienten kræver ingen database. Kontrollér containerbrugeren, skrivbare paths og den bundne listener, før du eksponerer den. Kør hele handlingen – opbyg en opskrift med flere trin, eksportér den, behandl en repræsentativ fil, og bekræft, at output-hashen matcher en kendt værdi – og gem den præcise image-reference, der producerede resultatet.

Test CyberChef udefra serveren

Publicér den statiske grænseflade på en betroet HTTPS-origin. Send det valgte hostname til containerens port 80, videresend den oprindelige host og HTTPS-scheme, og undgå at publicere en ekstra direkte origin.

Test CyberChef fra en ren ekstern klient. Adskil ingress-fejl fra den kendte applikationsgrænse – store operationer opbruger browserens hukommelse, selv om serveren er sund. En certifikat-, DNS- eller 502-fejl hører til routing. En request, der når CyberChef og fejler senere, hører til application state, kapacitet eller en understøttende afhængighed. Guiden til TLS på custom domains dækker den første gruppe.

Find alle persistente bytes i CyberChef

Standardcontaineren til CyberChef har ikke noget påkrævet mount til application data. Dens recovery-set er stadig eksplicit: ingen application data; bevar deployment-konfigurationen og image-pinnet. Opret ikke et tomt volume blot for at få deploymenten til at se stateful ud. Bevar i stedet den præcise image-reference og den gennemgåede konfiguration.

Genopbyg CyberChef på en tom host, og kør acceptance-transaktionen. Recovery er godkendt, når det pinnede statiske build kan genskabes, og en eksporteret opskrift producerer det samme kendte output. Enhver tilknyttet database eller collaboration-service følger sin egen application-consistent backup-plan, mens den udskiftelige webcontainer genskabes fra kode. Guiden til deployment fra Git til produktion beskriver denne reproducerbare grænse.

Gem en checksum eller digest for det kendte, velfungerende image, og test igen efter opdateringer. For en stateless service er en vellykket genopbygning restore-testen. For ekstern state skal CyberChef-runbooken linke til den separate ejer og recovery-procedure.

Beskyt den værdifulde del af CyberChef

Tilføj ikke en falsk environment secret blot for at få CyberChef til at se mere hardened ud. Den reelle bekymring er behandling af følsomt materiale i et modificeret eller utroværdigt image. Publicér derfor kun et officielt eller reproducerbart bygget image, når operatører skal indsætte credentials, captures eller encoded evidence.

Begræns den offentlige rute efter behov, verificér image-digesten, og kør containeren uden host mounts eller privileges, den ikke har brug for. Anvend limits baseret på browserens hukommelse og CPU ved store opskrifter frem for beregninger på containersiden i den almindelige statiske deployment. Logs bør registrere fejl og timings uden at gemme følsomt input, som behandles af CyberChef.

Fejlsøg en CyberChef, der ser sund ud

Mål browserens hukommelse og CPU ved store opskrifter frem for beregninger på containersiden i den almindelige statiske deployment, mens du kører denne regressionstransaktion: opbyg en opskrift med flere trin, eksportér den, behandl en repræsentativ fil, og bekræft, at output-hashen matcher en kendt værdi. Hold liveness-proben billig. Konvertering eller browserbaseret arbejde hører til i et separat release-check, så et tungt sample ikke udløser en restart-loop.

Opgraderingsrisikoen er, at CyberChef-operations og bundled libraries kan ændre output eller kompatibilitet. Derfor skal det pinnede build have en regressionstest. Kør kandidat-digesten ved siden af det aktuelle image, giv begge de samme kendte inputs, og sammenlign outputs, headers og timings. Hvis store operationer opbruger browserens hukommelse, selv om serveren er sund, skal du gemme den fejlslagne request og image-reference, før du ændrer ruten.

Gør CyberChef-smoketesten til et release-check

Release-recordet for CyberChef skal indeholde fakta, ikke “ser godt ud”. Gem den valgte image-digest, konfigurations-checksummen, det offentlige hostname og et tidsstemplet resultat for: opbyg en opskrift med flere trin, eksportér den, behandl en repræsentativ fil, og bekræft, at output-hashen matcher en kendt værdi. Brug sampledata, der ikke er fra produktion, så testen kan køres efter hver deployment.

Bevis to lifecycle-hændelser separat. En udskiftning af containeren skal bevare normal drift. En ren recovery skal vise, at det pinnede statiske build kan genskabes, og at en eksporteret opskrift producerer det samme kendte output. Mål samtidig browserens hukommelse og CPU ved store opskrifter frem for beregninger på containersiden i den almindelige statiske deployment, og gem resultatet som det forventede niveau for denne version.

Test også en afvist eller ugyldig tilstand: indsend harmløst input tæt på den ressource- eller formatgrænse, der er knyttet til denne grænse: store operationer opbruger browserens hukommelse, selv om serveren er sund. CyberChef skal fejle på en måde, der kan diagnosticeres, og må ikke overskrive sund state. Gå tilbage til den gyldige tilstand, kør samplen igen, og vedhæft de relevante redigerede logs. Disse artefakter giver en fremtidig rollback-beslutning konkret dokumentation.

Flyt det gentagelige infrastrukturarbejde til Dockup

For stateless CyberChef er Dockups opgave snæver og nyttig: start det pinnede image, hold port 80 privat, tilknyt HTTPS-ruten, og udskift containeren uden at opfinde storage. Deploymenten kan målrettes Dockup-infrastruktur eller en server, som kunden har tilknyttet.

Færdiggør applikationskonfigurationen: publicér den statiske grænseflade på en betroet HTTPS-origin. Dockup skal bevare CyberChef-runtimeindstillingerne, mens operatøren bekræfter denne lokale forudsætning: Standardklienten kræver ingen database. Kør denne acceptance-handling: opbyg en opskrift med flere trin, eksportér den, behandl en repræsentativ fil, og bekræft, at output-hashen matcher en kendt værdi. Valgfri authentication eller eksterne services skal repræsenteres som separat konfiguration og separate dependencies, så deploymenten forbliver korrekt.

Ofte stillede spørgsmål

Hvad kræver CyberChef til en produktionsdeployment?

Route CyberChef-containeren på port 80 gennem én HTTPS-origin. Standardbygget til CyberChef kræver hverken database eller en separat persistent runtime-service. Erklær ikke CyberChef klar, før du kan opbygge en opskrift med flere trin, eksportere den, behandle en repræsentativ fil og bekræfte, at output-hashen matcher en kendt værdi.

Hvilke CyberChef-data hører hjemme i en backup?

Standardimaget til CyberChef har ikke noget påkrævet mount til application data. Bevar deployment-konfigurationen, og tag separat backup af enhver tilknyttet state. Recovery er godkendt, når det pinnede statiske build kan genskabes, og en eksporteret opskrift producerer det samme kendte output.

Kræver CyberChef HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige CyberChef-origin, og hold port 80 på den interne rute. Anvend CyberChef-indstillingen korrekt: publicér den statiske grænseflade på en betroet HTTPS-origin. For CyberChef beskytter HTTPS credentials eller brugerindhold under transport og sikrer en ensartet, origin-følsom client-adfærd.

Hvordan skal en CyberChef-opgradering testes?

Deploy kandidat-imaget til CyberChef ved siden af det aktuelle image, og gentag acceptance-transaktionen med kendt input. Vær særligt opmærksom, fordi CyberChef-operations og bundled libraries kan ændre output eller kompatibilitet. Derfor skal det pinnede build have en regressionstest. Standardcontaineren har ingen datamigrering, så behold den tidligere digest, indtil output- og kompatibilitetstjek er bestået.