Durcissement

Un déploiement Chinaski est livré verrouillé par défaut : le service tourne dans un sandbox systemd, les fichiers ont des permissions restrictives, le daemon se lie au loopback derrière un reverse proxy, et le CMS ajoute des en-têtes de sécurité stricts à chaque réponse. Cette page explique ce que sont ces protections et quelques choses que vous pouvez faire pour les maintenir intactes.

Sandbox systemd

L'unité systemd de production exécute chaque instance comme un utilisateur chinaski dédié dans un sandbox strict :

Tout le système de fichiers est en lecture seule sauf le répertoire propre de l'instance ; un exploit dans l'app ne peut rien atteindre d'autre sur l'hôte.
L'instance obtient un /tmp privé, ne peut pas voir les répertoires home, et ne peut pas toucher aux réglages du noyau ni créer de fichiers privilégiés.
La mémoire est plafonnée à 1 Go (avec un plafond souple de 768 Mo), le CPU à 200 %, et 256 tâches concurrentes, de sorte qu'un job déchaîné ne puisse pas affamer l'hôte.
À l'arrêt, le service s'arrête proprement, laissant aux requêtes en vol et à un build en cours le temps de finir.
Les redémarrages sont automatiques mais limités, et toute la sortie atterrit dans le journal : lisez-le avec journalctl -u chinaski@<instance>.

Ces limites viennent du fichier d'unité ; ajustez-les sur des hôtes plus grands, mais peu de sites ont besoin de plus que les valeurs livrées.

Permissions des fichiers

L'installateur définit des permissions restrictives à l'installation et vous n'avez pas besoin de les changer :

Le répertoire de l'application appartient à l'utilisateur chinaski et ne peut être lu que par cet utilisateur et les membres du groupe.
Le fichier de base de données (chinaski.db) n'est lisible que par l'utilisateur chinaski et le groupe.
Le répertoire détenant le fichier env (qui contient votre secret) est réservé au propriétaire (0700) et le fichier env lui-même est 0600.
Le répertoire de backup est réservé au propriétaire (0700).

Si l'appartenance dérive (par exemple, un deploy exécuté comme le mauvais utilisateur), le script de deploy réapplique l'appartenance correcte au répertoire de l'application à la prochaine exécution.

Garder le daemon hors du réseau public

Liez le CMS à une adresse loopback (http://127.0.0.1:3001 est l'exemple dans l'unité systemd) et laissez le reverse proxy faire face à internet. Le daemon ne fait confiance aux IP client transmises que depuis les connexions loopback ; le lier à une interface publique permettrait aux visiteurs d'usurper leur IP et de défaire les rate limits et les lockouts de connexion.
Si votre proxy parle au daemon depuis une adresse non loopback (par exemple un réseau bridge Docker), définissez CHINASKI_TRUSTED_PROXIES à cette plage d'IP (adresses ou plages IPv4 séparées par des virgules) pour que la vraie IP client reste reconnue. Le loopback est toujours de confiance ; rien d'autre ne l'est, sauf si vous le listez.
En mode hors ligne (« EOTW ») hypnotoad sert du HTTP simple directement sans proxy. Le CMS lit alors l'adresse réelle de la connexion et ignore entièrement les en-têtes transmis, de sorte que le rate limiting fonctionne tel quel. Mais il n'y a pas de TLS dans ce mode : n'envoyez pas de mots de passe sur un réseau non fiable ; restreignez l'accès avec un VPN ou des règles de firewall.

Mode airgap

Définissez CHINASKI_AIRGAP=1 avant de démarrer le serveur sur des hôtes isolés. Cela coupe toute requête sortante (webhooks de build, webhooks de formulaire, et la vérification du bot-check) et cache le widget de vérification même si des clés sont stockées dans la base de données. Le CMS continue sinon de fonctionner.

En-têtes de réponse

L'application ajoute elle-même des en-têtes de sécurité à chaque réponse ; aucune configuration de proxy n'est nécessaire pour les bases :

Elle retire l'en-tête Server et définit la protection de frame (SAMEORIGIN), la protection contre le sniffing de content-type, une politique de referrer stricte, et un HSTS d'un an (le TLS est censé se terminer à votre reverse proxy).
Les fonctionnalités du navigateur que le CMS n'utilise jamais (caméra, micro, géolocalisation, paiement, USB, et plus) sont désactivées via Permissions-Policy.
Les scripts et styles en ligne sont protégés par un nonce par requête dans la Content Security Policy. Les submissions et l'intégration de formulaires sont verrouillées à l'origine propre du site.
Deux relâchements délibérés, tous deux restreints à des surfaces non publiques : les previews de contenu assouplissent la politique pour que les previews de thème se rendent correctement (elles requièrent une session admin ou un token de preview secret), et les pages de formulaires publics autorisent l'intégration par d'autres sites puisque c'est leur usage prévu, tandis que les submissions de formulaires ne postent toujours que vers votre serveur.

Les exemples de proxy (Caddy et nginx dans deploy/) reprennent ces en-têtes en ceinture et bretelles pour qu'ils soient définis même quand le proxy répond avec une erreur mise en cache.

Honeypots pour scanners

Les exemples de proxy routent les sondes courantes des scanners (.env, .git/config, wp-login.php, wp-admin, phpmyadmin, xmlrpc.php, et compagnie) vers le CMS au lieu du serveur statique. Les visites sont loguées et délibérément ralenties plutôt que discrètement 404. Si vous utilisez les exemples de proxy livrés, cela fonctionne automatiquement ; gardez le bloc honeypot quand vous adaptez la config.