CyberChef zelf hosten in 2026: veilige toegang, stateless hosting en updates

De kortste CyberChef-demo bewijst dat een proces op poort 80 luistert. Voor productie is sterker bewijs nodig. De deployment moet dit scenario ook doorstaan nadat de container is vervangen: bouw een multi-step recipe, exporteer die, verwerk een representatief bestand en controleer of de hash van de output overeenkomt met een bekende waarde.

CyberChef wordt met een duidelijk doel ingezet: als browser-workbench voor encoding, decoding, parsing en cryptografie. De meest voorkomende valkuil bij deployments is dat grote operaties het browsergeheugen uitputten terwijl de server gezond is. Daarom verdienen public URL-handling en duurzame state evenveel aandacht als het opstarten van de image.

Kies de kleinst mogelijke CyberChef-topologie

Een bruikbaar CyberChef-diagram toont de public route, private poort 80, state boundary en alle ondersteunende vereisten. Markeer welke pijlen credentials bevatten en welke gewone user traffic vervoeren. De standaard CyberChef-build heeft geen database of afzonderlijke persistente runtime-service nodig. Houd de webcontainer vervangbaar en plaats eventuele toekomstige authentication-, collaboration- of storage-componenten achter een afzonderlijk gedocumenteerde boundary.

Bewijs het diagram met één echte actie: bouw een multi-step recipe, exporteer die, verwerk een representatief bestand en controleer of de hash van de output overeenkomt met een bekende waarde. De voornaamste druk komt waarschijnlijk van browsergeheugen en CPU voor grote recipes, en niet van compute aan de containerzijde in de standaard static deployment; monitor dat pad in plaats van alle HTTP-requests als gelijkwaardig te behandelen.

Start de eerste productieachtige instance

Gebruik de container als een vervangbare runtime, niet als de locatie van de waarheid.

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

Bevestig de lokale vereiste voordat je de service blootstelt: voor de standaard client-side build is geen database nodig. Controleer de containergebruiker, writable paths en de gebonden listener voordat je de service exposeert. Voer de volledige actie uit — bouw een multi-step recipe, exporteer die, verwerk een representatief bestand en controleer of de hash van de output overeenkomt met een bekende waarde — en sla de exacte image reference op die het resultaat heeft geproduceerd.

Test CyberChef vanaf buiten de server

Publiceer de static interface op een trusted HTTPS-origin. Stuur de gekozen hostname door naar containerpoort 80, forward de oorspronkelijke host en HTTPS-scheme en voorkom dat je een tweede directe origin publiceert.

Test CyberChef vanaf een clean external client. Maak onderscheid tussen een ingress-fout en de bekende application boundary — grote operaties putten browsergeheugen uit terwijl de server gezond is. Een certificaat-, DNS- of 502-fout hoort bij routing; een request die CyberChef bereikt en pas daarna faalt, hoort bij application state, capacity of een ondersteunende vereiste. De handleiding voor TLS met een custom domain behandelt de eerste groep.

Vind elke duurzame byte in CyberChef

De standaard CyberChef-container heeft geen vereiste mount voor application data. De recovery-set is nog steeds expliciet: geen application data; bewaar de deploymentconfiguratie en pin de image. Maak niet zomaar een lege volume aan om de deployment stateful te laten lijken; bewaar in plaats daarvan de exacte image reference en de gereviewde configuratie.

Bouw CyberChef opnieuw op een lege host en voer de acceptance transaction uit. Recovery is geslaagd wanneer de gepinde static build opnieuw kan worden aangemaakt en een geëxporteerde recipe dezelfde bekende output oplevert. Elke gekoppelde database of collaboration-service volgt het eigen application-consistente backupplan, terwijl de vervangbare webcontainer opnieuw wordt aangemaakt vanuit code. De handleiding voor deployment van Git naar productie beschrijft die reproduceerbare boundary.

Bewaar een checksum of digest voor de bekende goede image en test opnieuw na updates. Voor een stateless service is een geslaagde rebuild de restore-test; voor externe state moet het CyberChef-runbook verwijzen naar de afzonderlijke eigenaar en recoveryprocedure.

Bescherm het waardevolle deel van CyberChef

Voeg geen nep-environment secret toe om CyberChef beter beveiligd te laten lijken. Het echte aandachtspunt is het verwerken van gevoelige gegevens in een aangepaste of untrusted image. Publiceer daarom alleen een officiële of reproduceerbaar gebouwde image wanneer operators credentials, captures of gecodeerd bewijsmateriaal zullen plakken.

Beperk de public route wanneer dat nodig is, controleer de image digest en voer de container uit zonder host mounts of privileges die niet nodig zijn. Pas limieten toe op basis van browsergeheugen en CPU voor grote recipes, en niet op basis van compute aan de containerzijde in de standaard static deployment. Logs moeten fouten en timings vastleggen zonder gevoelige input te bewaren die door CyberChef is verwerkt.

Diagnoseer een CyberChef die gezond lijkt

Meet tijdens deze regression transaction het browsergeheugen en CPU voor grote recipes, en niet compute aan de containerzijde in de standaard static deployment: bouw een multi-step recipe, exporteer die, verwerk een representatief bestand en controleer of de hash van de output overeenkomt met een bekende waarde. Houd de liveness probe eenvoudig; conversie of browser-side werk hoort in een afzonderlijke release check, zodat een zwaar sample geen restart loop kan veroorzaken.

Het upgraderisico is dat CyberChef recipe-operaties en gebundelde libraries de output of compatibility kunnen wijzigen. Daarom heeft de gepinde build een regression test nodig. Voer de candidate digest naast de huidige image uit, geef beide dezelfde bekende inputs en vergelijk outputs, headers en timing. Als grote operaties het browsergeheugen uitputten terwijl de server gezond is, bewaar dan de mislukte request en image reference voordat je de route wijzigt.

Maak van de CyberChef-smoketest een release check

Het release record voor CyberChef heeft feiten nodig, geen “ziet er goed uit”. Bewaar de geselecteerde image digest, configuratie-checksum, public hostname en een resultaat met timestamp voor: bouw een multi-step recipe, exporteer die, verwerk een representatief bestand en controleer of de hash van de output overeenkomt met een bekende waarde. Gebruik non-production sampledata, zodat de check na elke deployment kan worden uitgevoerd.

Bewijs twee lifecycle-events afzonderlijk. Een container replacement moet de normale werking behouden; een clean recovery moet aantonen dat de gepinde static build opnieuw kan worden aangemaakt en dat een geëxporteerde recipe dezelfde bekende output oplevert. Meet tijdens de checks het browsergeheugen en CPU voor grote recipes, en niet compute aan de containerzijde in de standaard static deployment. Bewaar het resultaat als de verwachte envelope voor deze versie.

Test ook een denied of invalid condition: dien ongevaarlijke input in die dicht bij de resource- of formatlimiet voor deze boundary ligt — grote operaties putten browsergeheugen uit terwijl de server gezond is. CyberChef moet op een diagnoseerbare manier falen en mag gezonde state niet overschrijven. Keer terug naar de geldige toestand, voer het sample opnieuw uit en voeg de relevante geredigeerde logs toe. Deze artifacts leveren concreet bewijs voor een toekomstige rollbackbeslissing.

Verplaats het reproduceerbare infrastructuurwerk naar Dockup

Voor stateless CyberChef is de taak van Dockup beperkt en nuttig: start de gepinde image, houd poort 80 privé, koppel de HTTPS-route en vervang de container zonder storage te verzinnen. De deployment kan gericht zijn op Dockup-infrastructuur of op een server die door de klant is gekoppeld.

Rond de application configuration af: publiceer de static interface op een trusted HTTPS-origin. Dockup moet de CyberChef-runtime-instellingen behouden terwijl de operator deze lokale vereiste controleert: voor de standaard client-side build is geen database nodig. Voer deze acceptance action uit: bouw een multi-step recipe, exporteer die, verwerk een representatief bestand en controleer of de hash van de output overeenkomt met een bekende waarde. Optionele authentication of externe services moeten als afzonderlijke configuratie en dependencies worden weergegeven, zodat de deployment accuraat blijft.

Veelgestelde vragen

Wat heeft CyberChef nodig voor een productie-deployment?

Routeer de CyberChef-container op poort 80 via één HTTPS-origin. De standaard CyberChef-build heeft geen database of afzonderlijke persistente runtime-service nodig. Markeer CyberChef pas als klaar wanneer je een multi-step recipe kunt bouwen, die kunt exporteren, een representatief bestand kunt verwerken en kunt bevestigen dat de hash van de output overeenkomt met een bekende waarde.

Welke CyberChef-data hoort in een backup?

De standaard CyberChef-image heeft geen vereiste mount voor application data. Bewaar de deploymentconfiguratie en maak afzonderlijk een backup van gekoppelde state; recovery is geslaagd wanneer de gepinde static build opnieuw kan worden aangemaakt en een geëxporteerde recipe dezelfde bekende output oplevert.

Heeft CyberChef HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de public CyberChef-origin en houd poort 80 op de interne route. Pas de CyberChef-instelling correct toe: publiceer de static interface op een trusted HTTPS-origin. Voor CyberChef beschermt HTTPS credentials of user content tijdens transport en zorgt het voor consistent gedrag van client-side functionaliteit die gevoelig is voor de origin.

Hoe moet een CyberChef-upgrade worden getest?

Deploy de candidate CyberChef-image naast de huidige image en herhaal de acceptance transaction met bekende input. Let hier extra op, omdat CyberChef recipe-operaties en gebundelde libraries de output of compatibility kunnen wijzigen. Daarom heeft de gepinde build een regression test nodig. De standaardcontainer heeft geen datamigratie, dus bewaar de vorige digest totdat de output- en compatibilitychecks zijn geslaagd.