Så självhostar du CyberChef 2026: säker åtkomst, stateless hosting och uppdateringar

Den kortaste CyberChef-demonstrationen visar att en process lyssnar på port 80. För produktion krävs starkare bevis. Följande scenario måste fungera även efter att containern har ersatts: skapa ett recept med flera steg, exportera det, bearbeta en representativ fil och bekräfta att resultatets hash matchar ett känt värde.

CyberChef distribueras med ett tydligt syfte: som en webbläsarbaserad arbetsyta för kodning, avkodning, parsning och kryptografi. Den vanligaste fällan vid distribution är att stora operationer tömmer webbläsarens minne trots att servern fungerar, så hantering av publika URL:er och persistent state måste få lika mycket uppmärksamhet som att image:n startar.

Välj den minsta fungerande CyberChef-topologin

Ett användbart CyberChef-diagram visar den publika routen, den privata porten 80, state-gränsen och alla stödkrav. Markera vilka pilar som överför autentiseringsuppgifter och vilka som utgör vanlig användartrafik. Standardbygget av CyberChef behöver ingen databas eller separat persistent runtime-tjänst. Håll webbcontainern utbytbar och placera framtida autentisering, samarbete eller lagring bakom en separat, dokumenterad gräns.

Bevisa diagrammet med en verklig åtgärd: skapa ett recept med flera steg, exportera det, bearbeta en representativ fil och bekräfta att resultatets hash matchar ett känt värde. Den troliga belastningen kommer från webbläsarens minne och CPU vid stora recept, snarare än från beräkningar på containersidan i den standardiserade statiska distributionen. Övervaka därför den vägen i stället för att behandla alla HTTP-anrop som likvärdiga.

Kör den första produktionsliknande instansen

Använd containern som en utbytbar runtime, inte som platsen där sanningen lagras.

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

Bekräfta det lokala kravet innan exponering: standardbygget på klientsidan behöver ingen databas. Kontrollera containerns användare, skrivbara sökvägar och bundna listener innan du exponerar den. Kör hela åtgärden — skapa ett recept med flera steg, exportera det, bearbeta en representativ fil och bekräfta att resultatets hash matchar ett känt värde — och spara den exakta image-referens som gav resultatet.

Testa CyberChef utanför servern

Publicera det statiska gränssnittet på en betrodd HTTPS-origin. Skicka det valda värdnamnet till containerns port 80, vidarebefordra den ursprungliga host-headern och HTTPS-schemat och undvik att publicera en andra direkt origin.

Testa CyberChef från en extern klient i en ren miljö. Separera ingressfel från den kända applikationsgränsen — stora operationer tömmer webbläsarens minne trots att servern fungerar. Ett certifikat-, DNS- eller 502-fel hör till routingen. En förfrågan som når CyberChef men misslyckas senare hör till applikationens state, kapacitet eller dess stödkrav. Guiden för TLS med anpassad domän täcker den första gruppen.

Hitta alla beständiga byte i CyberChef

Standardcontainern för CyberChef har ingen obligatorisk mount för applikationsdata. Återställningsmängden är ändå tydlig: inga applikationsdata; bevara distributionskonfigurationen och image-pinnen. Skapa inte en tom volume bara för att få distributionen att se stateful ut. Bevara i stället den exakta image-referensen och den granskade konfigurationen.

Bygg om CyberChef på en tom värd och kör acceptanstestet. Återställningen är godkänd när det pinnade statiska bygget kan återskapas och ett exporterat recept ger samma kända resultat. Alla anslutna databaser eller samarbets tjänster följer sin egen applikationskonsistenta plan för säkerhetskopiering, medan den utbytbara webbcontainern återskapas från kod. Guiden för distribution från Git till produktion beskriver den reproducerbara gränsen.

Spara en checksumma eller digest för den senast fungerande image:n och testa igen efter uppdateringar. För en stateless-tjänst är en lyckad ombyggnad återställningstestet. För extern state måste CyberChef-runbooken länka till den separata ägaren och återställningsproceduren.

Skydda den värdefulla delen av CyberChef

Lägg inte till en påhittad miljöhemlighet bara för att få CyberChef att se säkrare ut. Den verkliga risken är att känsligt material bearbetas i en modifierad eller ej betrodd image. Publicera därför endast en officiell eller reproducerbart byggd image när operatörer kommer att klistra in autentiseringsuppgifter, captures eller kodade bevis.

Begränsa den publika routen vid behov, verifiera image-digesten och kör containern utan host-mounts eller privilegier som den inte behöver. Sätt begränsningar utifrån webbläsarens minne och CPU för stora recept, snarare än beräkningar på containersidan i den standardiserade statiska distributionen. Loggar bör registrera fel och tidsåtgång utan att spara känslig input som bearbetats av CyberChef.

Felsök en CyberChef-instans som ser frisk ut

Mät webbläsarens minne och CPU för stora recept, snarare än beräkningar på containersidan i den standardiserade statiska distributionen, medan du kör detta regressionstest: skapa ett recept med flera steg, exportera det, bearbeta en representativ fil och bekräfta att resultatets hash matchar ett känt värde. Håll liveness-proben enkel. Konvertering eller arbete i webbläsaren hör hemma i en separat releasekontroll så att ett tungt exempel inte utlöser en restart-loop.

Uppgraderingsrisken är att CyberChef-operationer och bundlade bibliotek kan ändra resultat eller kompatibilitet, så det pinnade bygget behöver ett regressionstest. Kör kandidat-digesten bredvid den aktuella image:n, mata båda med samma kända input och jämför resultat, headers och tidsåtgång. Om stora operationer tömmer webbläsarens minne trots att servern fungerar ska du spara den misslyckade förfrågan och image-referensen innan du ändrar routen.

Gör smoke-testet för CyberChef till en releasekontroll

Releaseposten för CyberChef behöver fakta, inte ”ser bra ut”. Spara den valda image-digesten, konfigurationschecksumman, den publika hosten och ett tidsstämplat resultat för följande: skapa ett recept med flera steg, exportera det, bearbeta en representativ fil och bekräfta att resultatets hash matchar ett känt värde. Använd exempeldata som inte kommer från produktion så att kontrollen kan köras efter varje deployment.

Bevisa två livscykelhändelser separat. Ett containerbyte måste bevara normal drift. En ren återställning måste visa att det pinnade statiska bygget kan återskapas och att ett exporterat recept ger samma kända resultat. Medan kontrollerna körs mäter du webbläsarens minne och CPU för stora recept, snarare än beräkningar på containersidan i den standardiserade statiska distributionen, och sparar resultatet som förväntat intervall för den här versionen.

Testa även ett nekad eller ogiltigt tillstånd: skicka in ofarlig input nära den resurs- eller formatgräns som hör till denna gräns — stora operationer tömmer webbläsarens minne trots att servern fungerar. CyberChef ska misslyckas på ett diagnostiserbart sätt och får inte skriva över fungerande state. Återgå till det giltiga tillståndet, kör exemplet igen och bifoga relevanta, maskerade loggar. Dessa artefakter ger ett framtida rollback-beslut konkret underlag.

Flytta det repeterbara infrastrukturarbetet till Dockup

För stateless CyberChef är Dockups uppgift begränsad och användbar: starta den pinnade image:n, håll port 80 privat, anslut HTTPS-routen och ersätt containern utan att hitta på någon lagring. Distributionen kan riktas mot Dockup-infrastruktur eller en kundansluten server.

Slutför applikationskonfigurationen: publicera det statiska gränssnittet på en betrodd HTTPS-origin. Dockup ska bevara CyberChef-runtimens inställningar medan operatören bekräftar det lokala kravet: standardbygget på klientsidan behöver ingen databas. Kör denna acceptansåtgärd: skapa ett recept med flera steg, exportera det, bearbeta en representativ fil och bekräfta att resultatets hash matchar ett känt värde. Valfri autentisering eller externa tjänster ska beskrivas som separata konfigurationer och beroenden så att distributionen förblir korrekt.

Vanliga frågor

Vad behöver CyberChef för en produktionsdistribution?

Routa CyberChef-containern på port 80 via en enda HTTPS-origin. Standardbygget av CyberChef behöver ingen databas eller separat persistent runtime-tjänst. Markera inte CyberChef som redo förrän du kan skapa ett recept med flera steg, exportera det, bearbeta en representativ fil och bekräfta att resultatets hash matchar ett känt värde.

Vilka CyberChef-data ska ingå i en säkerhetskopia?

Standardimage:n för CyberChef har ingen obligatorisk mount för applikationsdata. Bevara dess distributionskonfiguration och säkerhetskopiera anslutet state separat. Återställningen är godkänd när det pinnade statiska bygget kan återskapas och ett exporterat recept ger samma kända resultat.

Kräver CyberChef HTTPS bakom en reverse proxy?

Använd HTTPS för den publika CyberChef-originen och håll port 80 på den interna routen. Tillämpa CyberChef-inställningen korrekt: publicera det statiska gränssnittet på en betrodd HTTPS-origin. För CyberChef skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och säkerställer konsekvent klientbeteende som är känsligt för origin.

Hur bör en CyberChef-uppgradering testas?

Distribuera den nya CyberChef-image:n bredvid den aktuella och upprepa acceptanstestet med känd input. Var särskilt uppmärksam eftersom CyberChef-operationer och bundlade bibliotek kan ändra resultat eller kompatibilitet, så det pinnade bygget behöver ett regressionstest. Standardcontainern har ingen datamigrering, så behåll den tidigare digesten tills kontrollerna av resultat och kompatibilitet är godkända.