Brundon Ewanye

Stagiaire en administration d'infrastructures sécurisées (AWOUI × LeGuideInfo), je rassemble ici mes travaux : du poste de travail jusqu'à une production durcie, que j'ai ensuite attaquée moi-même pour vérifier qu'elle tient.

Curieux d'intégrer la sécurité au plus tôt dans le cycle de vie des systèmes : infrastructure as code, conteneurisation, supervision et bonnes pratiques réseau.

Neuf étapes progressives du stage, du poste de travail à une production sécurisée et testée.

Une requête doit franchir plusieurs couches avant d'atteindre le site, et l'administration n'a qu'une seule porte.

1. Accès administrateurSSH par clé uniquement : pas de mot de passe, connexion en root interdite, liste de comptes autorisés. Joignable seulement par le réseau privé (VPN).
2. NavigateurHTTPS imposé pendant un an (HSTS), politique CSP limitant les scripts à ceux que j'autorise, version du serveur masquée. Note A+ sur securityheaders.com.
3. RequêtesPare-feu applicatif ModSecurity avec 914 règles OWASP : au-delà du seuil de 5 points, la requête reçoit un refus 403.
4. ComportementCrowdSec repère les attaquants et bannit leur adresse pendant 4 heures. Le réseau privé est exempté.

Tout est versionné dans le dépôt, sans secret, et livré par une demande de fusion.

Le chiffrement HTTPS se fait sur mon serveur : le front de la plateforme ne fait qu'aiguiller la connexion sans pouvoir la lire. Chaque requête franchit quatre couches avant d'atteindre la page.

Plutôt que de supposer mon serveur sûr, j'ai attaqué mon propre site et mon propre accès, un test à la fois.

1. Pare-feu applicatif : l'attaque est bloquée, le visiteur préservé

?fichier=/etc/passwd          -> 403  (lecture de fichier système)
?q=<script>alert(1)...        -> 403  (injection de script)
?id=1' OR '1'='1              -> 403  (injection SQL)
User-Agent: Nikto             -> 403  (scanner connu)
visite normale                -> 200  (acceptée)

[id 932160] Remote Command Execution: Unix Shell Code Found
[id 949110] score cumulé 30, seuil de blocage 5 -> refus

2. Accès administrateur : rien à deviner

Mot de passe forcé, compte « root », ancien port : trois refus. Seule ma clé, par le réseau privé, ouvre la porte.

3. Le videur : de la détection au bannissement

Je me suis banni moi-même 2 minutes (403, puis 200 après la levée). Puis le vrai test de bout en bout : mon téléphone en 4G a lancé une fausse attaque, reçu le 403, puis la page « CrowdSec Access Forbidden » pour toutes les visites suivantes. Ban levé ensuite à la main.

4. Ce que ces essais m'ont appris

• Un test peut me bannir moi-même : mes premières attaques lancées depuis le serveur ont banni l'adresse du serveur. Depuis, je teste depuis un poste extérieur et je garde la commande de levée de ban sous la main.
• Une règle d'accès mal écrite m'a coupé le terminal de secours : j'avais confondu l'adresse du client et celle du serveur dans la liste des comptes autorisés. Corrigé depuis la console d'administration de la plateforme. Leçon : tester la nouvelle porte avant de fermer l'ancienne.
• Le navigateur peut mentir : une page déjà visitée restait affichée depuis son cache alors que le ban était actif. Les journaux du serveur, eux, ne mentent pas.
• Limite connue : le réseau privé est exempté de bannissement, pour ne jamais me couper de mon propre serveur. Si un poste de ce réseau était compromis, CrowdSec ne le bannirait pas.
• Mon pare-feu a coupé mes propres images : ModSecurity analysait aussi les réponses du serveur et tronquait les images les plus lourdes (règle 959100, « Outbound Anomaly Score »). Le journal d'erreurs m'a donné la cause. Comme le site est statique, j'ai retiré cette seule règle de blocage des réponses : les attaques sur les requêtes reçoivent toujours un 403.

Le site est surveillé en continu par une sonde HTTP planifiée (cron), qui journalise son état et déclenche une alerte en temps réel (ntfy) si le site ne répond plus.

Une pile d'observabilité (Blackbox Exporter, Prometheus, Grafana) collecte et affiche l'historique de disponibilité :

Ce portfolio est lui-même un projet d'infrastructure. Il existe sous trois formes : un conteneur Docker multi-stage avec healthcheck (Job 03), un playbook Ansible idempotent qui le redéploie à l'identique (Job 04), et la production sur nginx avec domaine et HTTPS (Jobs 08 et 09).

Chaque changement passe par une branche et une demande de fusion relue, jamais par un push direct sur main.

Contribution à un projet collectif : l'agenda événementiel de l'association Eau Vive Boulogne, en parallèle du stage individuel.

Bloc 13 · RGPD (mon bloc)

Mise en conformité RGPD de l'agenda : pages Mentions légales et Politique de confidentialité, livrées par le flux Git standard (branche + demande de fusion) et fusionnées sur main.

Disponible pour une alternance en cybersécurité & cloud, à partir du 9 novembre 2026. N'hésitez pas à me contacter.

kevinewanye@gmail.com · Île-de-France · mobilité nationale