Slik selvhoster du CyberChef i 2026: sikker tilgang, tilstandsløs drift og oppdateringer

Den korteste CyberChef-demoen viser at en prosess lytter på port 80. Produksjon krever sterkere bevis. Den må bestå dette scenarioet selv etter at containeren er byttet ut: bygg en oppskrift med flere trinn, eksporter den, behandle en representativ fil og bekreft at output-hashen samsvarer med en kjent verdi.

CyberChef distribueres med et tydelig formål: som en nettleserbasert arbeidsflate for encoding, decoding, parsing og kryptografi. Den vanligste feilen ved distribusjon er at store operasjoner tømmer nettleserens minne selv om serveren er frisk, så håndtering av offentlige URL-er og varig tilstand må få like mye oppmerksomhet som oppstart av imaget.

Velg den minste levedyktige CyberChef-topologien

Et nyttig CyberChef-diagram viser den offentlige ruten, den private porten 80, grensen for tilstand og alle støttende krav. Marker hvilke piler som overfører credentials, og hvilke som er vanlig brukertrafikk. Standardbygget for CyberChef trenger ingen database eller separat persistent runtime-tjeneste. Hold webcontaineren utskiftbar, og plasser eventuell fremtidig autentisering, samhandling eller lagring bak en separat og dokumentert grense.

Bevis diagrammet med én reell handling: bygg en oppskrift med flere trinn, eksporter den, behandle en representativ fil og bekreft at output-hashen samsvarer med en kjent verdi. Den sannsynlige belastningen kommer fra nettleserminne og CPU for store oppskrifter, ikke fra beregninger på containersiden i standarddistribusjonen som består av statiske filer. Overvåk derfor denne banen i stedet for å behandle alle HTTP-forespørsler likt.

Kjør den første produksjonslignende instansen

Bruk containeren som et utskiftbart runtime-miljø, ikke som stedet der sannheten ligger.

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

Bekreft det lokale kravet før eksponering: Standardbygget på klientsiden trenger ingen database. Kontroller containerbrukeren, skrivbare stier og bundet lytter før du eksponerer den. Kjør hele handlingen – bygg en oppskrift med flere trinn, eksporter den, behandle en representativ fil og bekreft at output-hashen samsvarer med en kjent verdi – og lagre den nøyaktige image-referansen som produserte resultatet.

Test CyberChef utenfra serveren

Publiser det statiske grensesnittet på en betrodd HTTPS-origin. Send det valgte vertsnavnet til containerens port 80, videresend den opprinnelige host-en og HTTPS-skjemaet, og unngå å publisere en ekstra direkte origin.

Test CyberChef fra en ren ekstern klient. Skill feil i ingress fra den kjente applikasjonsgrensen – store operasjoner tømmer nettleserens minne selv om serveren er frisk. En feil med sertifikat, DNS eller 502 hører hjemme i rutingen. En forespørsel som når CyberChef og feiler senere, hører hjemme i applikasjonstilstand, kapasitet eller et støttende krav. Veiledningen for TLS med egendefinert domene dekker den første gruppen.

Finn alle varige byte i CyberChef

Standardcontaineren for CyberChef har ingen nødvendig mount for applikasjonsdata. Gjenopprettingssettet er likevel tydelig: ingen applikasjonsdata; bevar distribusjonskonfigurasjonen og image-pinnen. Ikke opprett et tomt volume bare for å få distribusjonen til å se tilstandsfull ut. Bevar i stedet den nøyaktige image-referansen og den gjennomgåtte konfigurasjonen.

Bygg CyberChef på nytt på en tom vert og kjør akseptansetransaksjonen. Gjenoppretting er godkjent når det pinnede statiske bygget kan gjenskapes og en eksportert oppskrift produserer det samme kjente resultatet. Alle tilkoblede databaser eller samhandlingstjenester følger sin egen applikasjonskonsistente plan for sikkerhetskopiering, mens den utskiftbare webcontaineren gjenskapes fra kode. Veiledningen for distribusjon fra Git til produksjon beskriver denne reproduserbare grensen.

Bevar en checksum eller digest for imaget som er kjent for å fungere, og test på nytt etter oppdateringer. For en tilstandsløs tjeneste er en vellykket rebuild gjenopprettingstesten. For ekstern tilstand må CyberChef-runbooken lenke til den separate eieren og gjenopprettingsprosedyren.

Beskytt den verdifulle delen av CyberChef

Ikke legg til en falsk environment secret bare for å få CyberChef til å se sikrere ut. Den reelle bekymringen er behandling av sensitivt materiale i et endret eller upålitelig image. Publiser derfor bare et offisielt eller reproduserbart bygget image når operatører skal lime inn credentials, captures eller kodede bevis.

Begrens den offentlige ruten når det er nødvendig, verifiser image-digesten, og kjør containeren uten host-mounts eller privilegier den ikke trenger. Sett grenser basert på nettleserminne og CPU for store oppskrifter, ikke på beregninger på containersiden i standarddistribusjonen som består av statiske filer. Logger bør registrere feil og tidsbruk uten å lagre sensitive inndata som behandles av CyberChef.

Feilsøk en CyberChef-instans som ser frisk ut

Mål nettleserminne og CPU for store oppskrifter, ikke beregninger på containersiden i standarddistribusjonen som består av statiske filer, mens du kjører denne regresjonstransaksjonen: bygg en oppskrift med flere trinn, eksporter den, behandle en representativ fil og bekreft at output-hashen samsvarer med en kjent verdi. Hold liveness-proben enkel. Konvertering eller arbeid i nettleseren hører hjemme i en separat release-sjekk, slik at et tungt eksempel ikke utløser en restart-loop.

Oppgraderingsrisikoen er at CyberChef-operasjoner og inkluderte biblioteker kan endre output eller kompatibilitet, så det pinnede bygget trenger en regresjonstest. Kjør kandidat-digesten ved siden av det gjeldende imaget, mat begge med de samme kjente inndataene, og sammenlign output, headere og tidsbruk. Hvis store operasjoner tømmer nettleserens minne selv om serveren er frisk, må du ta vare på den mislykkede forespørselen og image-referansen før du endrer ruten.

Gjør CyberChef-smoketesten til en release-sjekk

Release-registreringen for CyberChef trenger fakta, ikke «ser bra ut». Lagre valgt image-digest, konfigurasjons-checksum, offentlig vertsnavn og et tidsstemplet resultat for dette: bygg en oppskrift med flere trinn, eksporter den, behandle en representativ fil og bekreft at output-hashen samsvarer med en kjent verdi. Bruk eksempeldata fra ikke-produksjon, slik at sjekken kan kjøres etter hver distribusjon.

Bevis to livssyklushendelser separat. Et containerbytte må bevare normal drift. En ren gjenoppretting må vise at det pinnede statiske bygget kan gjenskapes, og at en eksportert oppskrift produserer det samme kjente resultatet. Mens kontrollene kjører, måler du nettleserminne og CPU for store oppskrifter, ikke beregninger på containersiden i standarddistribusjonen som består av statiske filer, og ta vare på resultatet som forventet rammeverk for denne versjonen.

Test også en avvist eller ugyldig tilstand: send inn ufarlige data nær ressurs- eller formatgrensen som er knyttet til denne grensen: store operasjoner tømmer nettleserens minne selv om serveren er frisk. CyberChef skal feile på en måte som kan diagnostiseres, og skal ikke overskrive frisk tilstand. Gå tilbake til den gyldige tilstanden, kjør eksempelet på nytt og legg ved relevante, anonymiserte logger. Disse artefaktene gir en fremtidig beslutning om rollback et konkret grunnlag.

Flytt det repeterbare infrastrukturarbeidet til Dockup

For tilstandsløs CyberChef er Dockups oppgave avgrenset og nyttig: start det pinnede imaget, hold port 80 privat, koble til HTTPS-ruten og bytt ut containeren uten å finne opp lagring. Distribusjonen kan målrettes mot Dockup-infrastruktur eller en server kunden har koblet til.

Fullfør applikasjonskonfigurasjonen: publiser det statiske grensesnittet på en betrodd HTTPS-origin. Dockup skal bevare runtime-innstillingene for CyberChef mens operatøren bekrefter dette lokale kravet: Standardbygget på klientsiden trenger ingen database. Kjør denne akseptansehandlingen: bygg en oppskrift med flere trinn, eksporter den, behandle en representativ fil og bekreft at output-hashen samsvarer med en kjent verdi. Valgfri autentisering eller eksterne tjenester bør representeres som separate konfigurasjoner og avhengigheter, slik at distribusjonen forblir korrekt.

Vanlige spørsmål

Hva trenger CyberChef for en produksjonsdistribusjon?

Rout CyberChef-containeren på port 80 gjennom én HTTPS-origin. Standardbygget for CyberChef trenger ingen database eller separat persistent runtime-tjeneste. Ikke erklær CyberChef som klar før du kan bygge en oppskrift med flere trinn, eksportere den, behandle en representativ fil og bekrefte at output-hashen samsvarer med en kjent verdi.

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

Standardimaget for CyberChef har ingen nødvendig mount for applikasjonsdata. Bevar distribusjonskonfigurasjonen, og sikkerhetskopier eventuell tilkoblet tilstand separat. Gjenoppretting er godkjent når det pinnede statiske bygget kan gjenskapes og en eksportert oppskrift produserer det samme kjente resultatet.

Krever CyberChef HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige CyberChef-originen, og hold port 80 på den interne ruten. Bruk CyberChef-innstillingen riktig: publiser det statiske grensesnittet på en betrodd HTTPS-origin. For CyberChef beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsistent klientatferd som er avhengig av origin.

Hvordan bør en CyberChef-oppgradering testes?

Distribuer kandidat-imaget for CyberChef ved siden av det gjeldende, og gjenta akseptansetransaksjonen med kjente inndata. Vær spesielt oppmerksom fordi CyberChef-operasjoner og inkluderte biblioteker kan endre output eller kompatibilitet, slik at det pinnede bygget trenger en regresjonstest. Standardcontaineren har ingen datamigrering, så behold den forrige digesten til kontroller av output og kompatibilitet er bestått.