Par défaut, le bouncer CrowdSec (crowdsec-firewall-bouncer) injecte sa propre chaîne dans iptables. Shorewall étant maître des règles firewall, il efface cette chaîne à chaque shorewall safe-restart. Les IPs bannies par CrowdSec ne sont plus bloquées.

La solution

Deux petites modifications suffisent.

1. Bouncer CrowdSec — /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

Passer le mode de iptables à ipset, et commenter les chaînes iptables :

mode: ipset

#iptables_chains:
#  - INPUT
#  - FORWARD
#  - DOCKER-USER

Redémarre le bouncer :

systemctl restart crowdsec-firewall-bouncer

2. Shorewall — /etc/shorewall/shorewall.conf

Ajouter ces deux directives :

# Crowdsec
DYNAMIC_BLACKLIST=ipset-only:crowdsec-blacklists
SAVE_IPSETS=Yes

DYNAMIC_BLACKLIST indique à Shorewall de déléguer le blocage dynamique à l'ipset crowdsec-blacklists (alimenté par le bouncer), et SAVE_IPSETS=Yes assure la persistance au reboot.

Recharge Shorewall :

shorewall safe-restart

Vérification

# L'ipset est bien peuplé par CrowdSec
ipset list crowdsec-blacklists

#output
198.244.240.165 timeout 12880 packets 0 bytes 0
39.101.94.83 timeout 11880 packets 15 bytes 900
87.3.25.245 timeout 9865 packets 0 bytes 0
198.244.168.192 timeout 8927 packets 0 bytes 0
89.200.229.42 timeout 10302 packets 0 bytes 0
176.31.139.6 timeout 9534 packets 0 bytes 0
39.101.93.209 timeout 11861 packets 0 bytes 0
198.244.168.182 timeout 12904 packets 0 bytes 0
198.244.183.121 timeout 9057 packets 0 bytes 0
86.97.49.220 timeout 11702 packets 0 bytes 0
39.101.93.55 timeout 13020 packets 0 bytes 0
45.146.8.36 timeout 12929 packets 0 bytes 0

C'est tout, Shorewall et CrowdSec cohabitent sans se marcher dessus.

L’article CrowdSec + Shorewall : Comment les faire cohabiter est apparu en premier sur Aukfood.

Je vous renvoi vers les articles sur Alloy pour les concepts, par exemple https://www.aukfood.fr/remonter-les-metriques-vers-prometheus-avec-grafana-alloy/

Installation

Pour l'installation rien de mystérieux, j'ai pris la documentation officielle.

Remonter des métriques.

Pour les métriques j'ai repris un peu la même configuration que l'articles Linux en adaptant pour Windows.

logging {
    level = "warn"
}

// Export metrics
prometheus.exporter.windows "default" {
  enabled_collectors = ["cpu","cs","logical_disk","net","os","service","system", "memory", "scheduled_task", "tcp"]
}

prometheus.scrape "windows_metrics" {
  targets    = prometheus.exporter.windows.default.targets
  forward_to = [prometheus.remote_write.metrics_service.receiver]
}

// Write metrics to prometheus
prometheus.remote_write "metrics_service" {
endpoint {
        url = "https://url-prom/api/v1/write"

        basic_auth {
           username = "identifiant"
           password = "password"
        }
    }

    external_labels = {
           "client" = "nomclient",
           "serveur" = "nomserveur",
    }
}

// Open dashboard Alloy
prometheus.scrape "default" {
  targets = array.concat(
    prometheus.exporter.windows.default.targets,
    [{
      // Self-collect metrics
      job         = "alloy",
      __address__ = "0.0.0.0:12345",
    }],
  )

  forward_to = [prometheus.remote_write.metrics_service.receiver]

}

On obtiens donc ceci dans la visualisation Alloy :

Pour Grafana j'ai utilisé ce dashboard.

Remonter les logs

Pour la remontée des logs vers Alloy :

// Export des logs Windows vers Loki
loki.source.windowsevent "application"  {
    eventlog_name = "Application"
    use_incoming_timestamp = true
    exclude_event_data = true
    forward_to = [loki.write.endpoint.receiver]
    labels = {
       job = "windows_eventlog",
       instance = constants.hostname,
    }
}

loki.source.windowsevent "security"  {
    eventlog_name = "Security"
    use_incoming_timestamp = true
    forward_to = [loki.write.endpoint.receiver]
    labels = {
       job = "windows_eventlog",
       instance = constants.hostname,
    }
}

loki.source.windowsevent "system"  {
    eventlog_name = "System"
    use_incoming_timestamp = true
    forward_to = [loki.write.endpoint.receiver]
    labels = {
       job = "windows_eventlog",
       instance = constants.hostname,
    }
}

loki.source.windowsevent "setup"  {
    eventlog_name = "Setup"
    use_incoming_timestamp = true
    forward_to = [loki.write.endpoint.receiver]
    labels = {
       job = "windows_eventlog",
       instance = constants.hostname,
    }
}

// Loki Endpoint
loki.write "endpoint" {
    endpoint {
        url ="http://10.87.200.43:3100/loki/api/v1/push"
        }
}

Ce qui va donner ceci dans la visualisation Alloy.

On à donc maintenant notre remontée de métriques et de logs depuis Windows.

L’article Grafana Alloy sur Windows est apparu en premier sur Aukfood.

 Le HPB

Le High Performance Backend (HPB) nécessite un service de signalisation et se compose de trois éléments fonctionnant en synergie :

• un service STUN (Session Traversal Utilities for NAT) pour découvrir les adresses IP externes NATées/protégées par un pare-feu. Nextcloud fournit un serveur STUN par défaut, mais vous pouvez le remplacer par le vôtre.
  Exemples : stun.nextcloud.com:443 ou stun.votredomaine.tld:3478 ou les deux
• Service TURN (Traversal Using Relays around NAT) tel que « coturn » ou « eturnal » pour connecter des adresses IP externes NATées/protégées par un pare-feu et contrôler les flux WebRTC. Son rôle principal est d'aider les clients WebRTC derrière des routeurs à communiquer et de relayer les données audio et vidéo à travers les pare-feu et les restrictions de port.
  Exemples : turn.votredomaine.tld:3478 ou votredomaine.tld:3478.
  Le chiffrement est facultatif pour TURN et STUN et sera géré par Nextcloud chiffré.
• Un service de signalisation WebRTC tel que « Janus WebRTC server » ou « Spreed WebRTC server » est nécessaire pour les appels et les conversations avec plusieurs participants. Le serveur de signalisation est utilisé pour établir une connexion WebSocket entre les participants à l'appel. Sans lui, tous les participants devraient télécharger individuellement leurs propres fichiers audio/vidéo pour chaque autre participant, ce qui entraînerait des problèmes de connectivité.
  Exemple : https://signal.yourdomain.tld

Allons un peu plus loin sur le fonctionnement théorique

Nextcloud Talk repose entièrement sur WebRTC. Il faut distinguer clairement trois couches :

Client (navigateur / app)
        │
        │ HTTPS / WebSocket
        ▼
Nextcloud Server (logique métier)
        │
        │ WebSocket (signaling)
        ▼
Signaling Server (HPB)
        │
        │ WebRTC (ICE / RTP)
        ▼
P2P direct ou TURN

J'ai demandé à une IA de me générer une image plus claire (ou pas) :

SDP — Décrire un appel

SDP (Session Description Protocol) est un document texte qui décrit une session, mais ne transporte aucun média.

Il contient notamment :

• codecs (opus, VP8, H264…)
• types de médias (audio / vidéo / data)
• ports et protocoles
• directions (sendrecv, recvonly…)

Exemple simplifié :

m=audio 9 UDP/TLS/RTP/SAVPF 111
a=rtpmap:111 opus/48000/2
a=sendrecv

Dans Nextcloud Talk :

• le client génère le SDP
• le serveur de signaling l’échange
• Nextcloud ne l’interprète pas

SDP incorrect = appel impossible avant même ICE.

ICE — Trouver un chemin réseau

ICE (Interactive Connectivity Establishment) a pour objectif de trouver le meilleur chemin réseau possible entre deux pairs.

Types de candidats ICE

ICE teste les candidats dans cet ordre :

1. host
2. srflx
3. relay

Le premier chemin fonctionnel est utilisé.

STUN — Découverte d’adresse publique

STUN permet à un client de découvrir comment il est vu depuis Internet.

Principe :

Client → STUN
STUN → "Tu es 91.x.x.x:port"

Le client crée alors un candidat srflx.

Limites fondamentales de STUN

STUN échoue avec :

• NAT symétrique
• firewalls stricts
• réseaux mobiles complexes

STUN est une aide, pas une solution.

TURN — Relais média

TURN (Traversal Using Relays around NAT) est utilisé quand toute communication directe échoue.

Fonctionnement théorique :

Client A → TURN → Client B

TURN :

• relaie les paquets RTP chiffrés
• ne décode pas le média
• consomme beaucoup de bande passante

En pratique, TURN est presque toujours utilisé.

Signaling — La pièce manquante de WebRTC

WebRTC n’inclut volontairement aucun mécanisme de signaling.

Le signaling sert à :

• échanger SDP
• échanger ICE candidates
• gérer l’état des participants

Dans Nextcloud Talk :

• assuré par le High Performance Backend (HPB)
• via WebSocket
• totalement séparé du média

P2P vs TURN (théorie)

P2P direct

Client ↔ Client

faible latence
fragile, rare en entreprise

TURN relay

Client → TURN → Client

fiable
compatible enregistrement
coûteux en ressources
En production, TURN est la norme.

 De la théorie à la pratique

On va voir maintenant comment mettre en place tout ça pour Nextcloud Talk. Il y à plusieurs possibilités pour faire cette mise en place, je vais choisir ici une installation conteneurisée avec des conteneurs, un premier pour le signaling et un second pour le recording. Il est possible que plus tard je refasse un article avec un autre modèle d'installation.

 HPB Signaling

On va avoir besoins de tokens pour cette configuration pour les générer voici la commande

openssl rand --hex 16

Les tokens seront les suivants :

• TURN_SECRET : le token pour accéder au serveur turn
• SIGNALING_SECRET : le token entre Nextcloud et le HPB
• INTERNAL_SECRET : le token pour la communication entre les composants

 Le déploiement

On va créer un docker-compose pour déployer la partie signaling en un seul conteneur :

name: 'hpb'

services:

  nc-talk:
    container_name: talk_hpb
    image: ghcr.io/nextcloud-releases/aio-talk:latest
    init: true
    ports:
      - 3478:3478/tcp
      - 3478:3478/udp
      - 127.0.0.1:8081:8081/tcp
    environment:
      - NC_DOMAIN=url-nextcloud
      - TALK_HOST=url-hpb
      - TURN_SECRET=******
      - SIGNALING_SECRET=****
      - TZ=Europe/Paris
      - TALK_PORT=3478
      - INTERNAL_SECRET=****
    restart: unless-stopped

 Le proxy

Pour accéder à ce service on va mettre en place un proxy apache2 :

<VirtualHost *:80>
  ServerName url-hpb
  Redirect Permanent / https://url-hpb
</VirtualHost>
<VirtualHost *:443>
  ServerName hpb-rocks.aukfood.ovh

    LogLevel warn
    ErrorLog "|/usr/bin/rotatelogs -lc /var/log/apache2/signaling_error.%Y.%m.%d 86400"
    CustomLog "|/usr/bin/rotatelogs -lc /var/log/apache2/signaling_access.%Y.%m.%d 86400" combined

    # SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/https://hpb-rocks.aukfood.ovh/standalone-signaling/cert.pem
    SSLCertificateChainFile /etc/letsencrypt/live/url-hpb/chain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/url-hpb/privkey.pem

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

    # Activate http/2
    Protocols h2 h2c http/1.1

    H2Push          on
    H2PushPriority  *                       after
    H2PushPriority  text/css                before
    H2PushPriority  image/jpeg              after   32
    H2PushPriority  image/png               after   32
    H2PushPriority  application/javascript  interleaved

    # Encoded slashes need to be allowed
    AllowEncodedSlashes NoDecode

    # Container uses a unique non-signed certificate
    SSLProxyEngine On
    SSLProxyVerify None
    SSLProxyCheckPeerCN Off
    SSLProxyCheckPeerName Off

    # keep the host
    ProxyPreserveHost On

    # Preserve host
    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
    RequestHeader set X-Real-IP expr=%{REMOTE_ADDR}

        ProxyPass "/standalone-signaling/" "ws://127.0.0.1:8081/"

        RequestHeader set X-Real-IP %{REMOTE_ADDR}s
        RewriteEngine On
        RewriteRule ^/standalone-signaling/spreed/$ - [L]
        RewriteRule ^/standalone-signaling/api/(.*) http://127.0.0.1:8081/api/$1 [L,P]
</VirtualHost>

 Configuration Nextcloud

Dans la partie Talk il faut configurer :

• Infrastructure Haute Performance
• STUN
• TURN

L'url est de la forme https://url-hpb/standalone-signaling

 HPB Recording

Une fonction intéressante est de pouvoir enregistrer des réunions, webnaires etc à partir de la visio. C'est pour cela qu'on va rajouter un conteneur hpb recording, l'avantage c'est que les vidéos seront enregistrées directement dans Nextcloud (dans le répertoire Talk de l'initiateur de la visio).

 Déploiement

On crée le docker-compose suivant :

services:
  nc-recording:
    image: nextcloud/aio-talk-recording:latest
    container_name: nc-recording
    restart: unless-stopped
    shm_size: '4gb'
    ports:
      - "127.0.0.1:1234:1234"
    environment:
      - TZ=Europe/Berlin
      - NC_DOMAIN=url-nextcloud
      - HPB_DOMAIN=url-hpb
      - RECORDING_SECRET=******
      - INTERNAL_SECRET=******
      - TZ=Europe/Paris

 Le proxy https

<VirtualHost *:80>
  ServerName url-record
  Redirect Permanent / https://url-record
</VirtualHost>
<VirtualHost *:443>
  ServerName url-record

    LogLevel warn
    ErrorLog "|/usr/bin/rotatelogs -lc /var/log/apache2/recording_error.%Y.%m.%d 86400"
    CustomLog "|/usr/bin/rotatelogs -lc /var/log/apache2/recording_access.%Y.%m.%d 86400" combined

    # SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/url-record/cert.pem
    SSLCertificateChainFile /etc/letsencrypt/live/url-record/chain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/url-recordprivkey.pem

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

    # Activate http/2
    Protocols h2 h2c http/1.1

    H2Push          on
    H2PushPriority  *                       after
    H2PushPriority  text/css                before
    H2PushPriority  image/jpeg              after   32
    H2PushPriority  image/png               after   32
    H2PushPriority  application/javascript  interleaved

    # Encoded slashes need to be allowed
    AllowEncodedSlashes NoDecode

    # Container uses a unique non-signed certificate
    SSLProxyEngine On
    SSLProxyVerify None
    SSLProxyCheckPeerCN Off
    SSLProxyCheckPeerName Off

    # keep the host
    ProxyPreserveHost On

    # Preserve host
    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
    RequestHeader set X-Real-IP expr=%{REMOTE_ADDR}

    ProxyPass / http://127.0.0.1:1234/ 

</VirtualHost>

 Reste plus qu'à rajouter la configuration dans Nextcloud

Conclusion

C'est une façon de faire l'installation elle peut être discutée mais elle fonctionne assez bien, par exemple nos webinairs sont faits directement dans Nextcloud Talk et enregistrés en live.

Je vous invite à consulter nos vidéos ici : https://peertube.aukfood.net/

Un merci à Arno Wezel pour m'avoir partagé son article qui m'a permis de corriger ma configuration : https://arnowelzel.de/en/nextcloud-talk-high-performance-backend-with-docker

L’article Mise en place de services HPB pour Nextcloud Talk est apparu en premier sur Aukfood.

En analysant les IPs (99500 en 1/2 journée) on remarque qu'il y a quand même que 1% d'IPS Française, 10% d'US et le reste, beaucoup d'Afrique, d'Inde etc ... Je pourrais faire un schéma par Pays par exemple.

Un petit script sympa : https://github.com/christophetd/geolocate-ips/blob/master/geolocate.py

L'idée est donc de diminuer le nombre de requêtes en interdisant les Pays chez qui le client ne vend pas. J'ai donc l'idée de bloquer les pays depuis Apache.

 Mise en place du module Apache geoip

Ajout du module geoip pour Apache :

apt install libapache2-mod-geoip

Le module est automatiquement chargé, plus qu'à redémarrer Apache :

systemctl restart apache2

La base de données des pays se trouve ici /usr/share/GeoIP/GeoIP.dat

 Configuration Apache

Deux possibilités pour cette configuration, soit dans /etc/apache2/apache2.conf soit dans un vhost, comme pour cet exemple :

  DocumentRoot /var/www/www.monsite.fr/www/public
  <Directory /var/www/www.monsite.fr/www/public>

  <IfModule mod_geoip.c>  
    GeoIPEnable On  

     SetEnvIf GEOIP_COUNTRY_CODE FR AllowCountry
     SetEnvIf GEOIP_COUNTRY_CODE JP AllowCountry
     SetEnvIf GEOIP_COUNTRY_CODE ES AllowCountry

     SetEnvIfNoCase User-Agent "Googlebot|Storebot-Google|AdsBot-Google|Mediapartners-Google" AllowGoogle
     SetEnvIfNoCase User-Agent "Mediapartners-Google|bingbot|BingPreview" AllowOtherSEO

     <RequireAny>
      Require env AllowCountry
      Require env AllowGoogle
      Require env AllowOtherSEO
     </RequireAny>

    # Optional: Return a custom message  
    ErrorDocument 403 "Access denied: This site is not available in your country."  
  </IfModule>

  ...

 Pour tester

En curl :

curl -A "Googlebot" https://ton-site.tld/

En browser en allant sur https://www.locabrowser.com/ qui permet de simuler des navigateurs depuis des IPs étrangères.

 Rajouter le code Pays dans les logs Apache

Cela peut être sympa en plus de rajouter le code pays dans les logs. Dans /etc/apache2/apache2.conf rajouter :

# Add %{GEOIP_COUNTRY_CODE}e to log country codes  
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{GEOIP_COUNTRY_CODE}e" combined_geoip 

Et dans la configuration des vhosts :

  LogLevel warn
  ErrorLog "|/usr/bin/rotatelogs -l -L error.log -c /var/www/www.monsite.fr/var/log/apache2/error.%Y.%m.%d 86400"
  CustomLog "|/usr/bin/rotatelogs -l -L access.log -c /var/www/www.monsite.fr/var/log/apache2/access.%Y.%m.%d 86400" combined_geoip

L’article Apache bloquer certains pays est apparu en premier sur Aukfood.

Un cluster Teleport, ça fonctionne comment ?

« Un couple Auth + Proxy : l’Auth Service centralise identité, rôles et certificats, le Proxy Service expose un point d’entrée unique sécurisé pour toutes les connexions. »

Sortilège associé : « Cluster Unificatum ! »

Cela permet de centraliser et tracer les connexions :

Nodes SSH
Clusters Kubernetes
Bases PostgreSQL / MongoDB / CockroachDB / MySQL
Services cloud
Applications Web internes
Hôtes (Clients & serveurs « propriétaire »)

Dans ce projet, je l’utilise comme bastion d’administration pour sécuriser les accès SSH des administrateurs vers les serveurs Linux d’Aukfood.

Fonctionnement “Direct” vs “Reverse Tunnel”

Notre déploiement Teleport repose sur un Auth Service (PKI/RBAC/inventaire) et un Proxy Service (point d’entrée).
Dans le lab, les nodes rejoignent le cluster directement via l’Auth (3025) pour obtenir/renouveler leurs certificats et publier leur présence.
Lors d’un tsh ssh, l’admin passe par le Proxy, qui applique le RBAC puis se connecte directement au node sur le port SSH Teleport (3022).

En production (WAN/internet-facing/segmentation forte), on privilégie le reverse tunnel via Proxy : les nodes initient une connexion sortante vers le Proxy, souvent 443 en TLS routing et le port 3025 (Auth) ne doit jamais être exposé publiquement.

1⃣ Prérequis

Bastion Teleport

• Serveur Debian 13 à jour (APT fonctionnel)
• Accès administrateur via un compte dédié (sudo), root désactivé en SSH
• Service SSH durci (clé uniquement, un seul compte admin autorisé, port spécifique, ex : 666)
• Temps synchronisé (timedatectl, NTP actif) pour : TLS (certificats), MFA / TOTP, horodatage des journaux

Réseaux & DNS

• FQDN prévu pour le bastion : srvsecteleport.aukfood.net
• IP fixe, firewalls et DNS fonctionnels
• Trafic inter-réseaux maîtrisé + WAN (clients bastion Data Center)
• Ouverture des ports selon stratégie / emplacement : 53, 443, 666, 3022, 3025…

Postes d’administration

• Postes Linux à jour avec : client SSH standard, tsh installé (inclus dans le paquet teleport)
• Accès HTTPS vers https://srvsecteleport.aukfood.net

Serveurs cibles (nodes SSH)

• Serveurs Linux « Hardened »
• SSH durci (clé uniquement puis certificats, pas de root direct, utilisateurs explicitement autorisés)
• Comptes Unix créés (romadmin, secops, etc.)
• Accès sortant vers srvsecteleport.aukfood.net:3025
• Pare-feux locaux configurés (UFW ou autre)

Paquets utiles : curl, wget, sudo, ufw, htop, gnupg, ca-certificates, lsb-release

2⃣ Objectifs de la mise en place

Centraliser tous les accès SSH des admins derrière un bastion unique
Appliquer une logique Zero-Trust : MFA systématique, certificats éphémères, RBAC
Supprimer les ouvertures de port SSH direct depuis les réseaux d’admin
Améliorer la traçabilité : audit, enregistrement et replay des sessions
Tester un outil “enterprise-grade” dans un environnement lab Aukfood pour un déploiement postérieur

4⃣ Architecture « projet »

Teleport est déployé comme bastion d’administration au centre d’un lab multi-zones (3 LAN segmentés/séparés + WAN) :

• Réseau clients > 192.168.10.0/24 : postes d’admins avec tsh (client Teleport pour se connecter au cluster)
• Réseau bastion > 172.16.0.0/30 : un serveur srvsecteleport.aukfood.net qui joue le rôle de Proxy + Auth
• Réseau data center > 10.44.22.0/24 : des serveurs Linux (srvweb, srvbdd) intégrés comme nodes Teleport

Les briques Teleport

• Proxy Service (port 443) → Portail Web (interface d’administration), API, point d’entrée tsh
• Auth Service (port 3025) → PKI interne, base d’authentification, RBAC, stockage d’état du cluster
• Nodes SSH (port 3022) → agents Teleport installés sur les serveurs Linux (srvweb, srvbdd) qui se connectent au bastion

Flux réseau, ports et firewalls

• Depuis les postes d’admin → bastion Teleport : TCP 443 (HTTPS / proxy Teleport)
• Depuis les nodes SSH → bastion Teleport : TCP 3025 (Auth Service ok pour direct, non exposé en reverse tunneling)
• Si configuration Node SSH : TCP 3022 (com SSH Teleport)
• Bloquer les anciens accès SSH directs depuis l’extérieur : seul Teleport est exposé
• Accès SSH par port 666 Passphrase=50 et clé sécurisée à partir d’un seul poste d’admin pour config Teleport

« Protego Bastionem !! »

5⃣ Installation du bastion Teleport

Préparation du dépôt APT

# Teleport Community Edition
export TELEPORT_PKG=teleport
export TELEPORT_VERSION=v18
export TELEPORT_CHANNEL=stable/${TELEPORT_VERSION?}

# Variables OS (définit $ID, $VERSION_CODENAME)
source /etc/os-release

Ajouter la clé GPG et le dépôt

sudo mkdir -p /etc/apt/keyrings

sudo curl https://apt.releases.teleport.dev/gpg \
-o /etc/apt/keyrings/teleport-archive-keyring.asc

echo "deb \[signed-by=/etc/apt/keyrings/teleport-archive-keyring.asc\] \
https://apt.releases.teleport.dev/${ID?} ${VERSION_CODENAME?} \
${TELEPORT_CHANNEL?}" \
| sudo tee /etc/apt/sources.list.d/teleport.list > /dev/null

Installer le paquet

sudo apt-get update
sudo apt install -y ${TELEPORT_PKG?}

Après installation on obtient :

• le binaire teleport
• l’outil d’admin tctl
• le client tsh
• le service systemd teleport.service

Vérifications de base

Objectifs : Avoir un Teleport v18.x et un FQDN « propre » et résolvable

teleport version
hostname -f
sudo hostnamectl set-hostname srvsecteleport.aukfood.net

DNS Ok depuis poste-admin : nslookup/dig srvsecteleport.aukfood.net

Réinitialiser Teleport (re-config cluster ou node)

Repartir de zéro :

sudo systemctl stop teleport 2>/dev/null || true
sudo systemctl disable teleport 2>/dev/null || true

sudo rm -f /etc/teleport.yaml
sudo rm -rf /var/lib/teleport/*

• /etc/teleport.yaml : ancienne configuration Teleport
• /var/lib/teleport : état du cluster (CA interne, base, sessions…)

Je peux le purger sans risque : aucun cluster de production n’est actuellement en cours d’exécution.

« Réparo !! »

6⃣ Configuration du fichier /etc/teleport.yaml

Dans le lab, je laisse Teleport gérer son certificat TLS auto-signé, je n’utilise pas un FQDN résolu publiquement

teleport configure \
-o file \
--cluster-name=srvsecteleport.aukfood.net \
--data-dir=/var/lib/teleport \
--public-addr=srvsecteleport.aukfood.net:443

• --cluster-name : nom logique du cluster (PKI interne)
• --data-dir : stockage de l’état du cluster (/var/lib/teleport)
• --public-addr : FQDN + port utilisés par les admins

Sans --cert-file / --key-file / --acme, Teleport génère automatiquement un certificat auto-signé.

En production, ce certificat sera remplacé par un certificat issu de la PKI interne ou d’une AC publique (Let’s Encrypt, ACME…).

7⃣ Démarrage & premier accès au portail

Service systemd

sudo systemctl enable --now teleport
sudo systemctl status teleport

Contrôle des ports en écoute : sudo ss -tlnp | grep teleport

Premier accès Web, « First Run »

Depuis poste-admin : https://srvsecteleport.aukfood.net

Le certificat étant auto-signé, le navigateur affiche un warning, je vérifie le FQDN, j’accepte l’exception et Go Teleport.

« Revelio !! »

8⃣ Création du premier admin Teleport (MFA obligatoire)

Depuis srvsecteleport :

sudo tctl users add romadm --logins=romadm --roles=access,editor,auditor
sudo tctl users ls

La commande retourne une URL d’invitation valable 1h, à utiliser sur le poste d’admin.

1. Ouvrir l’URL d’invitation dans un navigateur
2. Choisir un mot de passe fort
3. Enregistrer le MFA (TOTP) dans Aegis (coffre fort + biométrie)
4. Entrer l’OTP dans l’interface Teleport

Teleport impose par défaut mot de passe + MFA, ce qui colle parfaitement à la logique Zero-Trust.

9⃣ Modèle RBAC & utilisateurs Teleport

Principe général : qui, quoi, sur quelles machines ?

Dans Teleport, on ne donne jamais des droits « en vrac » à un utilisateur. On assemble trois briques :

• Les utilisateurs Teleport : comptes nominatifs (romain, killian, guillaume…) qui s’authentifient avec mot de passe + MFA.
• Les rôles (RBAC) : chaque rôle décrit ce qu’un utilisateur a le droit de faire (ressources, verbes) et sur quelles cibles, via des filtres (labels).
• Les nodes (serveurs) : chaque serveur rejoint le cluster avec des labels (ex. env=lab, role=web, os=linux) qui servent de méta-données pour le filtrage.

Lorsqu’un utilisateur se connecte, Teleport regarde :

1. ses rôles (ex. auk-secops),
2. les logins Unix autorisés dans le rôle (ex. secops),
3. les labels des nodes (ex. env=lab, os=linux).

L’accès est accordé uniquement si tout correspond. Le lien se fait donc par des labels et des rôles.
Exemple : «Killian se connecte de son poste avec le rôle SecOps sur le bastion, la configuration lui permet de se connecter avec le compte secops sur les nodes Linux».

L’identité Teleport (utilisateur + rôle RBAC) est mappée sur des logins Unix existants sur les serveurs à joindre (logins:romadmin, secops).
Teleport ne crée pas ces comptes : s’ils n’existent pas, la connexion échoue (« unknown user »).

Rôles intégrés & rôles Aukfood

Dans Teleport, les rôles (RBAC) sont décrits en YAML et définissent précisément le périmètre d’accès : comptes Unix autorisés (logins), ressources ciblées via labels (node_labels) et permissions Teleport (rules).
Les rôles intègrent également des contraintes de sécurité (options) telles que des TTL de session courts et des exigences MFA, afin d’appliquer le moindre privilège et de réduire l’impact d’une éventuelle compromission.

Rôles intégrés Teleport :

• access → base utilisateur standard (accès SSH, labels, etc.)
• editor → admin technique du cluster (créer / modifier la plupart des ressources)
• auditor → lecture des journaux et enregistrements (aucun droit SSH)

Rôles Aukfood définis en YAML :

• auk-admin-bastion : administrateur du bastion (Romain)
• auk-secops : rôle Cybersécurité / SecOps (Killian)
• auk-audit-direction : lecture seule audit / direction (Guillaume)

Les fichiers sont stockés dans un dossier créé > /etc/teleport/rbac/*.yaml puis appliqués via tctl create -f.

Objectif : respecter le principe du moindre privilège : chaque rôle ne possède que les droits nécessaires à sa mission.

« Minima Privilegium ! »

Exemple de rôles « simplifiés » auk-admin-bastion / auk-secops

Application config :

sudo mkdir -p /etc/teleport/rbac
sudo nano /etc/teleport/rbac/auk-secops.yaml
sudo tctl create -f /etc/teleport/rbac/auk-secops.yaml
sudo chmod 600 /etc/teleport/rbac/*.yaml

Même logique pour auk-audit-direction.

Dans le rôle, on déclare aussi les logins Unix (romadmin, secops, etc.) sur lesquels Teleport estautorisé à se connecter.

Création/gestion des utilisateurs Teleport

Par la CLI :

sudo tctl users add romain --roles=auk-admin-bastion --logins=romadmin
sudo tctl users add killian --roles=auk-secops --logins=secops
sudo tctl users add guillaume --roles=auk-audit-direction --logins=auditor
# puni Guillaume, pas de SSH !

Suite à ces commandes on reproduit le même process d’inscription que pour l’administrateur.
L’utilisateur dispose d’une heure pour ouvrir le lien HTTPS fourni, valider son accès et paramétrer ses « crédentials ».

Par l’UI :

1. Access → Users → Create user
2. Saisir identifiant + e-mail
3. Assigner le rôle (auk-admin-bastion, auk-secops, auk-audit-direction)
4. Envoyer le lien d’invitation (mot de passe + MFA)

Intégration des serveurs Linux comme nodes Teleport

Principe

Sur chaque serveur (srvweb, srvbdd), un agent Teleport s’exécute :

• il ouvre une connexion sortante vers srvsecteleport.aukfood.net:3025
• il reçoit ses certificats internes et ses labels par srvsecteleport.aukfood.net:3022
• toutes les connexions SSH passent par le bastion, avec certificats éphémères et audit centralisé

Check réseau

Tests depuis la cible → srvsecteleport.aukfood.net:3025 (TCP) doit être joignable.

nc -vz srvsecteleport.aukfood.net 3025

Résultats :

• open / succeeded → réseau OK
• Connection timed out / No route to host → problème firewall / routing
• Connection refused → rien n’écoute → vérifier Teleport côté bastion

Il est aussi possible d’intégrer des serveurs en « Agentless mode » (sans agents) avec OpenSSH.
En raison de la taille de l’article je n’en ferai pas la démonstration ici.

Vous pouvez faire « Accio Nodes » ca marche aussi

Génération d’un join token pour un node

Depuis le bastion srvsecteleport : sudo tctl tokens add --type=node --ttl=1h

• Génère un token à usage unique, valide 1h
• Donne aussi une commande teleport start ... d’exemple (que je n’utilise pas ici)

Ce token permet à un nouveau node de se présenter au cluster Teleport de manière contrôlée.
Une fois enrôlé, le node reçoit ses certificats internes pour les connexions.

Installation du node srvweb

Sur Serveur Cible :

sudo apt update
sudo apt install teleport

Créer la configuration du node : sudo nano /etc/teleport.yaml

Exemple :

Points importants :

• auth_servers : liste des Auth Services Teleport à contacter
• auth_token : token d’enrôlement, utilisé une fois pour rejoindre le cluster
• labels : métadonnées attachées au node (env=lab, role=web, os=linux) utilisées pour le RBAC

Activer le service :

sudo systemctl enable --now teleport
sudo systemctl status teleport

Onboarding graphique

Depuis l’UI Teleport :

1. Add New → Resource → Add server
2. Choisir Linux / Teleport Agent
3. Copier la commande proposée
4. L’exécuter sur la cible via SSH classique
5. Vérifier l’apparition du node dans la liste avec ses labels

Scénarios de tests et démonstration

Dans la maquette, Teleport utilise un certificat auto-signé, d’où le --insecure côté tsh.
En production, on utilisera un certificat de confiance et on supprimera cette option !

Sortilège associé « TSH Connectum ! »

login TSH & visibilité des nodes ~ Admin romain :

tsh login --proxy=srvsecteleport.aukfood.net:443 --user=romain --insecure
tsh status
tsh ls

• user Teleport = romain
• proxy = srvsecteleport.aukfood.net
• nodes srvweb, srvbdd visibles avec leurs labels

login SSH par UI HTTPS ~ admin Romain sur srvdata avec romadmin :

Cliquer Connect sur la ressource pour accéder par interface WEB à l’interface de ligne de commande du serveur cible

• romain voit uniquement les nodes autorisés par ses labels
• SSH Ok en romadmin sur les machines prévues

login TSH SSH admin Killian sur srvweb avec secops :

tsh ssh secops@srvweb

• killian voit uniquement les nodes autorisés par ses labels
• pas de droit sur l’administration du bastion
• SSH Ok en secops sur les machines prévues

Traçabilité : Profil Audit avec guillaume

• Connexion à l’UI Teleport avec guillaume (password + MFA)
• Accès : Audit / Active Session / Live / Recordings
• Lecture des enregistrements sans accès SSH ni droits d’édition

« Expecto Auditum !! »

Voir les session SSH en cours

Audit de l’ensemble des Logs

Replay d’une session SSH

Apports concrets & limites de Teleport CE

Bénéfices observés

• Réduction de la surface d’attaque
  → Plus de SSH direct vers les serveurs, tout passe par le bastion
• Fin des clés SSH partagées
  → Certificats SSH éphémères, liés à un compte nominatif + MFA
• Traçabilité centralisée
  → Audit, journaux, replay des sessions depuis une seule interface
• Separation claire des rôles
  → Admin, SecOps, Audit / Direction avec des droits distincts
• Alignement Zero-Trust
  → Auth forte, identité, durée de vie courte des certificats, labels & RBAC

Limites de Teleport Community Edition

• Teleport CE couvre largement le besoin interne (SSH, RBAC, MFA, audit, SSO GitLab)
• Certaines fonctions avancées (SSO très poussé, HA “clé en main”, support éditeur, gouvernance d’identité complexe) sont côté EE
• Pour une production client, il faut bien clarifier le périmètre CE vs Enterprise car il existe des restrictions dans le cas de services « vendus ». Il faut bien payer les développeurs, la CE est déja très complète.

Ouverture : haute disponibilité

L’architecture décrite ici repose sur un bastion unique (Auth + Proxy sur la même VM, stockage local).

Pour aller vers une vraie haute disponibilité (HA) :

Utiliser PostgreSQL comme backend Teleport (au lieu du stockage local)
Déployer plusieurs Auth Services redondants pointant sur la même base
Placer plusieurs Proxy Services (stateless) derrière un Load Balancer (OPNsense HAProxy, F5, cloud LB…)
Versionner la configuration (teleport.yaml, rôles RBAC) dans Git et déployer via Ansible / Terraform

Ce scénario n’est pas détaillé dans l’article malgré des essais intéressants, mais constitue une piste d’évolution « sérieuse » pour une future production ou offre managée.

Bonnes pratiques & sauvegarde

• Toujours imposer MFA pour les comptes sensibles
• Jamais de root exposé via Teleport
• Contrôler strictement les AllowUsers / logins autorisés sur les cibles
• Surveiller les logs et idéalement les envoyé dans WAZUH : sudo journalctl -u teleport -f sur bastion idem nodes
• Sauvegarder au minimum :
  • /etc/teleport.yaml
  • /etc/teleport/rbac/*.yaml
  • /var/lib/teleport/ (ou backend PostgreSQL si utilisé)

RAID / HA ≠ sauvegarde : il faut malgré tout une stratégie de backup régulier et de restore testée.

Conclusion – Teleport

Teleport remplit parfaitement son rôle de bastion d’administration Zero-Trust : les accès SSH ne passent plus directement par les serveurs, chaque action est authentifiée, tracée et rejouable, et les rôles RBAC séparent clairement les responsabilités (ex : administration, SecOps, audit/direction).

Cette implémentation reste volontairement simple (un seul nœud Auth/Proxy, stockage local), mais elle pose des bases solides pour aller plus loin : backend PostgreSQL, haute disponibilité, intégration SSO avancée et déploiement automatisé via IaC.

Cet article complète celui dédié à Warpgate et s’inscrit dans une approche globale bastion + durcissement + supervision pour sécuriser les accès SSH dans les infrastructures Aukfood et pour nos clients.

Conclusion générale du projet

Un bastion ca se choisit !

Avec ce triptyque d’articles – analyse des bastions SSH, installation de Warpgate puis mise en place de Teleport – l’objectif n’était pas seulement de tester des outils « qui font joli en démo », mais de poser les bases d’une vraie démarche de sécurisation des accès d’administration chez Aukfood tout en observant leurs limites.

Warpgate illustre le bastion léger, moderne, open source, parfaitement adapté à des besoins ciblés (SSH / HTTP(S) / BDD) avec une mise en œuvre rapide et sans SaaS ni dépendance obscure.
Teleport, lui, représente une approche plus large, globale et industrielle, orientée Zero-Trust, certificats éphémères, RBAC fin et intégration profonde avec l’écosystème (SSH, bases, Kubernetes, applications web…).

Les deux solutions ne s’opposent pas : elles montrent surtout qu’il n’existe pas « un » bastion idéal, mais des réponses différentes selon le contexte, la taille du SI, les exigences d’audit et de conformité.

Au-delà des outils, ce travail met surtout en avant quelques constantes : ne plus exposer les serveurs en direct, imposer une authentification forte, tracer les actions, séparer les rôles, documenter ce qui est fait et penser dès le départ à la résilience (sauvegardes, HA, PKI, supervision).
La suite logique à mon projet sera de mener les déploiements et l’industrialisation des solutions : intégrer ces briques dans les pratiques internes, automatiser (IaC, Ansible), renforcer la supervision et aligner le tout avec les recommandations des organismes de référence comme l’ANSSI.

En résumé : ces trois articles ne clôturent pas le sujet, ils ouvrent au contraire la voie à une stratégie bastion cohérente, adaptée au terrain, et prête à évoluer avec les besoins, les risques… et les futurs projets.

Et vous, qu’est ce que vous en pensez ? Votre avis nous intéresse.

Merci pour votre lecture, n’hésitez pas à nous suivre sur les réseaux.

Romain GAUTIER

L’article Sécurité des accès SSH ~ Installation du bastion TELEPORT est apparu en premier sur Aukfood.

L'écosystème open source a réagi rapidement : en quelques heures suivant la disclosure, CrowdSec a déployé des règles de détection spécifiques dans sa collection de virtual patching, démontrant l'agilité et l'efficacité des solutions collaboratives.
 

Analyse technique de React2Shell

Nature de la vulnérabilité

CVE-2025-55182 est une faille de désérialisation non sécurisée dans le protocole "Flight" des React Server Components. Le code serveur traite les charges utiles HTTP sans validation appropriée, permettant à un attaquant d'injecter et d'exécuter du code arbitraire.

Packages vulnérables (versions 19.0.0 à 19.2.0) :

• react-server-dom-webpack
• react-server-dom-turbopack
• react-server-dom-parcel

Frameworks impactés :

• Next.js 15.0.4 à 16.0.6 (plus canaries 14.3.0-canary.77+)
• React Router (mode RSC)
• Waku, Vite RSC, Parcel RSC
• RedwoodSDK

Le point critique : même une application Next.js fraîche créée via create-next-app est vulnérable par défaut. Aucune configuration spécifique n'est nécessaire, la simple présence de Server Components suffit.

Scénario d'attaque

Un attaquant peut :

• Envoyer une requête HTTP POST malicieuse vers n'importe quel endpoint
• Exploiter la désérialisation pour exécuter du code arbitraire
• Obtenir un accès complet au serveur
• Exfiltrer des données, installer des backdoors, pivoter vers le réseau interne
   

La réactivité de CrowdSec face à React2Shell

Un écosystème collaboratif rapide
Ce qui différencie l'open source dans la cybersécurité, c'est la réactivité de la communauté. Quelques heures après la disclosure, CrowdSec a mis à disposition une règle de détection pour React2Shell : vpatch-CVE-2025-55182

Que fait la règle ?

La règle vpatch-CVE-2025-55182 de CrowdSec vise à détecter les tentatives d’exploitation de React2Shell en identifiant les caractéristiques propres à l’attaque. Elle s’appuie sur cinq signaux combinés, ce qui réduit fortement les faux positifs :

• Méthode HTTP POST → les attaques exploitent exclusivement des formulaires envoyés au serveur.
• Présence d’en-têtes propres aux React Server Actions (next-action, rsc-action-id) → indicateurs forts qu’il s’agit d’un flux RSC/Next.js.
• Paramètres internes de Flight modifiés (status, resolved_model) → champs sensibles utilisés par la désérialisation vulnérable.
• Payload contenant le motif suspect $@ → signature d’injection associée au contournement du modèle de résolution.

CrowdSec corrèle ces éléments pour repérer les patterns d’exploitation connus de React2Shell sans disposer d’un exploit public fonctionnel, ce qui en fait un virtual patch préventif, destiné à protéger les applications en attendant que les correctifs officiels soient déployés.

Comment installer la règle de protection CrowdSec

Si vous avez déjà suivi nos précédents tutoriels sur l’installation de CrowdSec, de son module WAF AppSec ou encore sur son automatisation via Ansible, vous êtes déjà parfaitement équipé pour ajouter ce virtual patch.

Pour rappel, nos guides sont disponibles ici :

• Devenez le Gandalf de votre serveur LAMP : "You SHALL Not Pass!"
• Crowdsec AppSec Component : Sécurié vos site web
• Automatiser l'installation et la configuration de CrowdSec avec Ansible

L’installation de la règle de mitigation pour React2Shell est ensuite très simple. Il suffit d’exécuter :

cscli appsec-rules install crowdsecurity/vpatch-CVE-2025-55182

En quelques secondes, votre WAF AppSec commence à appliquer le virtual patch et à détecter les tentatives d’exploitation liées à CVE-2025-55182.

N’oubliez pas de mettre à jour React et Next.js
L’installation de la règle CrowdSec offre une protection immédiate, mais elle ne remplace pas le correctif officiel. Pour éliminer définitivement React2Shell, veillez à mettre à jour vos dépendances dès que possible :

• React 19.x vers la version corrigée
• Next.js (toutes versions impactées) vers la release de sécurité publiée par Vercel
  Ces mises à jour corrigent la vulnérabilité à la source et doivent être appliquées même si votre WAF est en place.
   

Conclusion

CVE-2025-55182 (React2Shell) représente une menace sérieuse avec son score CVSS de 10.0, mais l'écosystème open source a démontré sa capacité à réagir rapidement. CrowdSec a publié des règles de détection quelques heures après la disclosure, illustrant la puissance du modèle collaboratif.

Chez Aukfood, notre approche Purple Team combinée à CrowdSec nous permet de :

1. Protéger proactivement nos clients via le virtual patching
2. Améliorer itérativement nos règles de détection
3. Bénéficier de l'intelligence collective de la communauté CrowdSec
4. Une validation continue

Notre recommandation : Toutes les organisations utilisant React 19 avec Server Components doivent :

1. Patcher immédiatement vers les versions corrigées
2. Déployer CrowdSec avec les collections de virtual patching
3. Surveiller activement les tentatives d'exploitation
4. Tester régulièrement l'efficacité des défenses (approche Purple Team)

L'objectif est d'utiliser les outils open source de manière optimale pour une défense collaborative et proactive, tout en respectant les principes de souveraineté des données qui sont au cœur de nos valeurs chez Aukfood.

Ressources complémentaires

• Detecting React2Shell: The maximum-severity RCE Vulnerability affecting React Server Components and Next.js
• Security Advisory: CVE-2025-66478
• React2Shell (CVE-2025-55182)

L’article React2Shell : le plat trop épicé de React 19. CrowdSec à la rescousse ! est apparu en premier sur Aukfood.

Warpgate – Bastion SSH

« No SaaS bullshit, No Jump hosts, No paid plan, No client » – warp-tech

Warpgate est un bastion open source léger et moderne, écrit en Rust, développé par warp-tech, qui permet de sécuriser les accès à :

SSH     HTTP/HTTPS     MySQL     PostgreSQL

Sans client propriétaire, sans plan payant, avec une philosophie très “simple & safe”.
Dans ce labo, Warpgate est utilisé comme bastion d’administration SSH pour accéder à des serveurs Linux durcis.

Alert RBAC : Role-Based Access Control
Plusieurs Targets pour des rôles différents sur le même serveur = Des privilèges bien gérés ! – Mawki

1⃣ Objectifs de la mise en place

• Centraliser et tracer les accès SSH
• Appliquer une logique Zero-Trust (clé + MFA)
• Isoler les serveurs derrière un bastion “internet-facing”
• Tester une solution légère pour un déploiement postérieur dans un environnement pro

2⃣ Binaire ou Docker ?

Mode binaire (choix pour le lab)

• Installation simple, très légère
• Intégration directe avec systemd et journalctl
• Mises à jour plus manuelles, besoin de durcir d’avantage l’OS et les Firewalls

Mode Docker

• Déploiement reproductible (compose, K8s…)
• Rollback facile via tags d’images
• Isolation accrue (namespaces, volumes…)
• Un peu plus de complexité (réseau, volumes, gestion Docker)

Pour un déploiement en lab ou petite infra, le binaire est confortable. Pour de la prod / HA / Infra as Code, Docker ou K8s sont à privilégier.

3⃣ Pré-requis

Système hôte

• Système serveur hôte “hardened” et mis à jour
• Un seul compte admin (sudo) et root désactivé

Paquets utiles : curl, wget, sudo, ufw, htop, gnupg, ca-certificates, lsb-release

Réseau & sécurité

• IP fixe, DNS fonctionnel, routage OK
• Pare-feu en amont configuré (ouverture des ports 22/2222, 8888, etc.)
• Trafic inter-zones (clients bastion Data Center) maîtrisé

Serveurs cibles

• SSH durci (clé uniquement, comptes dédiés, pas de root direct)
• Pare-feu locaux actif
• De préférence un port SSH non standard (ex : 666 côté cible)

Bien évidemment, pour la configuration on se connecte en SSH à notre futur hôte !

4⃣ Installation du binaire Warpgate

Téléchargement

Vérifier la dernière version sur GitHub :
« https://github.com/warp-tech/warpgate/releases »

Télécharger le binaire pour Linux :

wget https://github.com/warp-tech/warpgate/releases/download/v0.17.0/warpgate-v0.17.0-x86_64-linux -O warpgate

Mise en place du binaire

Déplacer le fichier, le rendre exécutable et créer le répertoire de données :

sudo mv warpgate /usr/local/bin/warpgate
sudo chmod +x /usr/local/bin/warpgate
sudo mkdir -p /var/lib/warpgate

Vérifications

which warpgate
warpgate version
warpgate --help

5⃣ Setup initial (config de base)

Warpgate peut être configuré en mode guidé ou non-interactif.

« Setup » guidé

sudo warpgate setup

Exemple de choix :

  Data path : /var/lib/warpgate
  HTTP (Admin UI) : 0.0.0.0:8888
  SSH : 0.0.0.0:2222
  MySQL : 0.0.0.0:33306
  PostgreSQL (optionnel) : 0.0.0.0:55432
  Recordings : activés
  Mot de passe admin : à définir

« Unattended-setup » non-interactif

sudo warpgate unattended-setup
  --ssh-port 2222 
  --http-port 8888 
  --data-path /var/lib/warpgate 
  --record-sessions 
  --admin-password 'MotDePasse@dminFort666!'

Après la config, on obtient :

• Fichier de config : /etc/warpgate.yaml
• Données : /var/lib/warpgate/
• DB SQLite par défaut : sqlite:/var/lib/warpgate/db
• Recordings : /var/lib/warpgate/recordings (chemin par défaut)

On peut constater à la fin de l’installation qu’il à aussi généré ses clés, son certificat TLS, l’admin (de base) et son rôle.

6⃣ Premier lancement et service systemd

Test “first run”

warpgate --config /etc/warpgate.yaml run

Puis accéder à l’interface admin à partir d’un client :
https://<IP-ou-FQDN>:8888/@warpgate/admin

Quand le test est OK, stopper avec CTRL+C afin de mettre fin au processus et de le passer en systemd

Intégration systemd

Créer le fichier /etc/systemd/system/warpgate.service (version simple, durcissement possible, voir GitHub) :

Activer le service et vérifier :

sudo systemctl daemon-reload
sudo systemctl enable --now warpgate
sudo systemctl status warpgate

Logs Live > en temps réel

sudo journalctl -u warpgate -f

Vous verrez : Created symlink ‘/etc/systemd/system/multi-user.target.wants/warpgate.service’ → ‘/etc/systemd/system/warpgate.service’
warpgate check peut aussi être utile en cas « d’error code »

La sortie de commande confirme « Warpgate service is running », on peut effectuer un second test en reboot le serveur.

7⃣ Préparation des serveurs cibles (SSH)

Comptes de service dédiés

Bonnes pratiques : j’ai créé deux comptes avec des privilèges différents, sans accès password, clé uniquement (on va les gérer via le bastion).
Dans ce cas, personne ne peut se connecter par MDP, attaque par force brute, connexion sans la clé du bastion et login par erreur sont impossible.

Exemple sur un serveur cible srvweb :

sudo adduser --disabled-password --gecos "" wgtusr
sudo mkdir -p /home/wgtusr/.ssh
sudo chown -R wgtusr:wgtusr /home/wgtusr/.ssh
sudo chmod 700 /home/wgtusr/.ssh
sudo touch /home/wgtusr/.ssh/authorized_keys
sudo chmod 600 /home/wgtusr/.ssh/authorized_keys

Si le compte admin local est par exemple romadmin, bien verrouiller les droits de son home : sudo chmod go-w /home/romadmin

Si les droits sur ~/.ssh ou authorized_keys ne sont pas stricts, sshd ignore le fichier et l’authentification sera refusée (“Auth rejected”).

8⃣ Déploiement de la clé Warpgate sur les cibles

Sur le bastion, afficher les clés Warpgate

sudo warpgate client-keys

Exemple de sortie (raccourcie) :

ssh-ed25519 AAAAC3NzaC1lZDI1NTE[...] warpgate
rsa-sha2-256 AAAADHblablabla[...] warpgate

Copier la clé dans authorized_keys des comptes cible, par exemple :

echo "ssh-ed25519 AAAAC3NzaCacestlacledubastion1lZDI1NTE[...] warpgate" | sudo tee -a /home/wgtusr/.ssh/authorized_keys

Tout est prêt pour finaliser l’installation !

Rôles (RBAC)

Menu : Config → Roles → Add role

Renseigner un nom clair : ops:ssh, admin:bastion, readonly:web, etc.
Un rôle relie Users Targets :

• Un user avec le rôle ops:ssh
• Une target autorisant le rôle ops:ssh
• L’utilisateur peut accéder à cette target.

Pour des niveaux de privilèges différents sur un même serveur, il est possible de :

• Créer plusieurs comptes locaux (ex : wgtusr et wgtadmin)
• Créer plusieurs roles et targets associés

N’oubliez pas la phrase de Mawki sûr le RBAC

Utilisateurs Warpgate

Menu : Config → Users → Add user

Checklist :

• username : ex. romadmin, tfred.eni
• description : Admin Bastion, DevOps, etc.
• Ajouter les credentials : Add public key (clé SSH du poste client), Add OTP (MFA), éventuellement SSO, Password, selon la politique
• Cocher les auth policies nécessaires (SSH / HTTP / MySQL / PostgreSQL)
• Assigner les rôles créés plus haut
• Optionnel : limiter la bande passante par user

MFA / OTP sur mobile

Pour un lab : TOTP (OTP basé temps) dans la réalité nous allons utiliser l’OIDC > SSO via OpenID Connect (KeyCloak), pour plus de sécurité.
Le TOTP va générer des tokens d’accès de 30 secondes, par déverouillage de coffre fort et authentification biométrique, en plus de la clé ssh !

Dans Warpgate : Config → Users → <user> → Add OTP → Warpgate affiche un QR code

Sur le mobile

• Installer un Authenticator open source et le configurer, j’ai choisis Aegis
• Scanner le QR code de l’utilisateur
• Valider le premier code OTP

De retour sur Warpgate : Entrer le code et cliquer Update configuration > Cela va valider le compte d’authentification
Ensuite, l’accès admin demandera clé SSH + OTP (MFA) à chaque demande de connexion.

Éviter les policies du type “Any credential” : forcer clé + OTP au minimum pour les comptes sensibles.

Targets (cibles)

Menu : Config → Targets → Add target

Exemple pour un serveur SSH srvweb :

• Type : SSH
• Name : srvweb_admin
• Host : srvweb.aukfood.net ou 100.44.22.5
• Port : 666 (port SSH cible)
• Username : wgtadm (compte local sur la cible)
• Roles : cocher ops:ssh (par exemple)

Ensuite, dans la fiche Target : Cliquer sur Check host key pour valider la clé de l’hôte et le lien bastion cible.

Si la config target, la clé et le lien sont conformes vous verrez : “Remote host key is thrusted”

Une target a un seul username, tous les utilisateurs Warpgate ayant un rôle autorisé sur cette target arriveront sur la machine avec ce compte !

Tests d’accès

Accès administrateur du bastion

Connexion à l’UI via https://srvwgt.aukfood.net:8888/@warpgate/admin – Authentification par clé SSH + OTP

Accès utilisateurs vers leurs serveurs

Le login SSH se fait au format : user:target@bastion – Authentification par clé SSH + OTP

Exemple connexion admin : ssh 'tfred.eni:srvweb_admin@srvwgt.aukfood.net' -p 2222

Exemple première connexion d’un utilisateur non admin :

Le fonctionnement :

1. Le client se connecte au bastion (srvwgt) sur le port 2222
2. Warpgate vérifie la clé SSH + OTP de l’utilisateur
3. L’utilisateur valide fingerprint pour déclarer à son poste l’authenticité du bastion
4. Il démarre son Authenticator, déverouille le coffre-fort (empreinte biométrique) et entre le code obtenu
5. Warpgate établit la connexion vers la target srvweb sur le port 666 en fonction de ses droits (cible admin ou non)
6. L’utilisateur est logué avec l’user local du serveur et n’a jamais les credentials directs de la cible
7. Warpgate conserve les logs et le recording de la session de l’utilisateur pour la tracabilté
8. Direct & Replay session possibles si actifs, rétention paramétrable
   > Si Fred à tout cassé on peut le savoir et surtout comprendre ce qui s’est passé, par chance il n’avait pas les droits !

Exemple Log et session recording avec Fred :

Bonnes pratiques & sauvegarde

• Toujours forcer MFA pour les comptes sensibles
• Pas d’accès root direct via Warpgate
• Utiliser des comptes de service dédiés sur les cibles
• Surveiller les logs : journalctl -u warpgate -f
• Sauvegardes minimales : /etc/warpgate.yaml + /var/lib/warpgate/ (ou DB externe si déporté)

RAID / HA ≠ sauvegarde : Garder au minimum une sauvegarde régulière des fichiers de config et de la base.

Retour d’expérience & avis

Après mise en place et premiers tests, Warpgate donne globalement une très bonne impression :

Points forts :

• Installation simple et config claire en YAML
• Support de SSH / HTTP(S) / MySQL / PostgreSQL dans un même outil
• MFA, clés SSH, intégration SSO possibles → esprit Zero-Trust
• Traçabilité : journaux détaillés, enregistrements de sessions, historique
• Consommation très faible, binaire Rust, peu de dépendances

Points de vigilance :

• La HA n’est pas magique : Il faut penser l’architecture globale : DB externe, load balancer, redondance réseau.
• La courbe d’apprentissage RBAC (rôles, users, targets) peut surprendre au début
• Gestion des enregistrements de sessions à prévoir (stockage, rotation, rétention)

Mon Ressenti :

• Très adapté pour un bastion SSH / HTTP moderne dans une petite/moyenne infra d’admin et un environnement cloud/VM où on veut faire simple et efficace.
• Moins adapté pour une solution “complète” clef en main avec déjà tout (portails utilisateurs, workflow d’approbation, catalogue d’applis, etc.) et dans un écosystème trop complexe.

Conclusion :

Warpgate est un excellent candidat pour un bastion open source moderne, encore plus si on accepte de construire soi-même la partie HA (DB, reverse-proxy, supervision, sauvegardes).
Dans notre contexte, il s’intègre bien à une approche cloud + open source avec un bon compromis : légèreté, sécurité, traçabilité.
A présent, on va le déployer sur une petite partie de notre infrastructure, histoire de s’amuser un peu.

Et vous, qu’est ce que vous en pensez ? Vous avez essayé ? On vous l’installe ?

Merci pour vôtre lecture, n’hésitez pas à nous suivre sur les réseaux.

Romain GAUTIER

L’article Sécurité des accès SSH ~ Installation du bastion WARPGATE est apparu en premier sur Aukfood.

Let's go ...

Mise en place de Keycloak

Je fais le choix d'une installation Keycloak en conteneur Docker pour l'isoler avec une base de données Postgresql.

Bien sûr à adapter, ici j'ai un proxy traefik devant, je vous renvoi à nos articles sur Traefik si besoins.

Oubliez pas le fichier .env avec les valeurs des variables.

services:
  keycloak:
    container_name: keycloak
    image: "quay.io/keycloak/keycloak:26.4.0"
    command: start
    environment:
      PROXY_ADDRESS_FORWARDING: true
      KC_PROXY: edge
      KEYCLOAK_ADMIN: ${KEYCLOAK_USER}
      KEYCLOAK_ADMIN_PASSWORD: ${KEYCLOAK_PASSWORD}
      KC_HOSTNAME: ${KEYCLOAK_URL}
      KC_DB: postgres
      KC_DB_USERNAME: ${POSTGRES_USER}
      KC_DB_PASSWORD: ${POSTGRES_PASSWORD}
      KC_DB_URL_HOST: keycloak_postgres
      KC_DB_URL_DATABASE: keycloak
      KC_HTTP_ENABLED: true
      KC_PROXY_HEADERS: xforwarded
    depends_on:
      keycloak_postgres:
        condition: service_healthy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /etc/localtime:/etc/localtime:ro
      - conf:/opt/keycloak/conf
      - data:/opt/keycloak/data
      - providers:/opt/keycloak/providers
      - themes:/opt/keycloak/themes
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik-proxy"
      - "traefik.http.routers.keycloak.entrypoints=websecured"
      - "traefik.http.routers.keycloak.rule=Host(`keyurl`)"
      - "traefik.http.routers.keycloak.service=keycloak"
      - "traefik.http.services.keycloak.loadbalancer.server.port=8080"
    networks:
      - "traefik-proxy"
      - "database"

  keycloak_postgres:
    container_name: keycloak_postgres
    image: postgres:17
    restart: always
    environment:
      POSTGRES_DB: keycloak
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - ./postgresql:/var/lib/postgresql/data
    networks:
      - "database"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d keycloak"]
      interval: 10s
      timeout: 5s
      retries: 5
    labels:
      - "traefik.enable=false"

networks:
  traefik-proxy:
    external:
      name: traefik-proxy
  database:
    name: database

volumes:
  conf:
    driver: local
  data:
    driver: local
  providers:
    driver: local
  themes:
    driver: local

Configuration de Keycloak

Une fois déployé il faut dans un premier temps créer un "royaume" un "realm", ne jamais utiliser le realm par défaut.

Créer un client pour Nextcloud

Ensuite on va créer un client pour notre application Nextcloud.

Mapping pour les groupes

Il faut préciser à Keycloak qu'il faut aussi envoyer les informations de groupes pour un utilisateur. Pour cela :

• aller dans "Client Scopes
• il doit y avoir un scope qui s'appelle "nextcloud-dedicated"
• créer un mapper de type "Group Membership" comme ceci

Créer un utilisateur

Il faut ensuite créer un utilisateur et spécifier au minima son login, son, email, son nom.

Créer un ou des groupes

Il faut créer les groupes et affecter les utilisteurs.

Paramétrer Nextcloud

Il faut installer l'application oidc_login ce qui remplace "social login" utilisé dans les précédents articles.

Une fois installé, dans le fichier config.php :

  // OIDC params
  'oidc_login_client_id' => 'nextcloud',
  'oidc_login_client_secret' => 'id_a_recup_dans_keycloak', 
  'oidc_login_provider_url' => 'https://url_keycloak/realms/lerealm',
  'oidc_login_end_session_redirect' => true,
  'oidc_login_logout_url' => 'https://url_nextcloud/',
  'oidc_login_auto_redirect' => true,
  'oidc_login_redir_fallback' => true,
  'oidc_login_button_text' => 'Connexion Keycloak',
  'oidc_login_attributes' => array(
    'id' => 'preferred_username',
    'mail' => 'email',
    'groups' => 'groups',
  ),
  'overwriteprotocol' => 'https',
  'oidc_login_scope' => 'openid profile roles email',
  'oidc_login_proxy_ldap' => false,
  'oidc_login_disable_registration' => false,
  'oidc_login_redir_fallback' => false,
  'oidc_login_tls_verify' => true,
  'oidc_create_groups' => true,

On a maintenant un bouton "Connexion Keycloak" :

On peut donc maintenant se connecter avec l'utilisateur créé dans Keycloak, les paramètres seront récupérés pour créer l'utilisateur dans Nextcloud.

Good Job ...

Sources

Quelques liens intéressants que je vous conseille :

• les liens Keycloak sur notre site bien sûr
• cet article de Connect IT
• cet article sur le mapping des groupes

L’article Authentification Nextcloud avec Keycloak est apparu en premier sur Aukfood.

Dans le cadre de mon projet chez Aukfood, j’ai mené une recherche approfondie concernant différents bastions d'administration SSH 100% open source.

Objectifs : Identifier une solution fiable, moderne, pérenne, adaptée à nos besoins sur le Cloud et compatible avec nos "outils" pour renforcer la sécurité des environnements administratifs dans un contexte spécifique.

Ce bastion sera exposé publiquement, donc potentiellement "visible" ; Il doit accepter des connexions SSH entrantes depuis n’importe où, tout en filtrant, authentifiant, journalisant, chiffrant. Il ne protège pas seulement un LAN, mais filtre des flux vers d’autres services à travers internet!

La solution sera "internet-facing", une politique de sécurité Zéro-Thrust avec durcissement est donc impérative. Des méthodes adaptées seront implémentées autour afin d'écarter les risques d'attaque. J'ai effectué mes recherches en respectant au maximum les exigences opérationnelles citées ci dessous ;

• Traçabilité complète des accès SSH
• Gestion centralisée des utilisateurs / groupes
• Intégration LDAP / SSO / MFA ...
• Audit, logs, historique et enregistrements
• Accès multi-plateforme (PC, mobile, CLI)
• Haute disponibilité (HA) et résilience
• Maintenabilité, sécurité et pérennité à long terme

Classement globale des solutions de Bastion éligibles à nos critères :

#	Nom du Bastion	Visibilité / Réputation	Communauté	Justification de sélection et limites
	Teleport Gravitational 92/100	Référence mondiale, grands comptes (IBM, Dropbox, Snowflake)	Très active	Le plus complet et polyvalent, éprouvé et maintenu activement Intègre SSH/RDP/K8s/DB, audit complet et RBAC Limites : Versions CE & EE (Community Edition), config initiale plus technique
	The Bastion OVH 88/100	Reconnu, déployé en production par OVH	Active	SSH pur, très robuste, totalement conforme aux préconisations ANSSI Bonne traçabilité, parfait pour infrastructures souveraines Limites : pas d’interface web pour évolution future, exclusivement CLI
	Warpgate warp.tech 85/100	Croissante, communauté Rust	Très active	Léger, moderne, innovant, futur prometteur grâce à Rust Intégration OIDC/TOTP native, adapté environnements Cloud/SSH purs Limites : solution récente, manque de complexité config pour HA et RBAC
	JumpServer Fit2Cloud 84/100	Large adoption internationale	Très active	PAM open source complet, bon compromis fonctionnalités/robustesse Multi-protocole (SSH/RDP/DB), audit avancé, intégration LDAP Limites : docs parfois partielles (origine asiatique), stack plus lourde

L’intérêt de ce classement est de mettre en avant des solutions ayant déjà fait leur preuves en fonction de leurs réputation, visibilité et disponibilité des contenus. La notation est calculée en fonction du niveau de sécurité et en adéquation à nos besoins techniques.

Matrice d’exigences technique détaillée :

Critère	Teleport	The Bastion (OVH)	Warpgate	JumpServer
Langage principal	Go	Perl / Shell	Rust	Python / Go
Licence	AGPLv3	Apache 2.0	Apache 2.0	GPL-3.0
Multi-protocoles (SSH/RDP/DB/K8s)	Oui	Non (SSH uniquement)	SSH/HTTP/DB basique	Oui (SSH pur plus sécurisé)
LDAP / SSO / MFA intégrés	OIDC, SAML, TOTP, WebAuthn	Auth forte, MFA externe possible	OIDC, TOTP natif	LDAP, MFA
Audit / replay / logs détaillés	Oui (replay, logs SIEM)	Oui (audit complet)	Oui (replay sessions)	Oui (SSH/RDP logs)
Gestion utilisateurs / RBAC	RBAC complet, certificats courts	Groupes et délégation	Rôles simples + OIDC	RBAC complet, approbations
Accès multi-plateforme	CLI/Web, mobile via client SSH	SSH natif, pas d’UI mobile	Compatible Termius/Blink	Accès web + proxy SSH
Haute disponibilité / Clusterisation	Multi-nœuds Auth/Proxy	Réplication manuelle	LB + PostgreSQL	Cluster complet Redis+DB
Durcissement / Zéro-Trust / Internet-facing	Natif (reverse tunnel + certs courts)	CLI robuste, conforme ANSSI	Nécessite proxy/LB sécurisé (Traefik /Nginx)	Possible via durcissement DMZ
Pérennité / Maintenabilité
Complexité déploiement	Moyenne/élevée	Simple/moyenne	Simple/moyenne	Moyenne
Adéquation Cloud / Internet	Optimisé pour Cloud public	Utilisé en frontal SSH	Léger et Cloud-ready	Plus orienté LAN, à isoler

Légende Conforme et adapté au déploiement Fonction partielle ou nécessitant intégration manuelle Absent nativement

Cette "matrice" démontre les avantages/inconvénients concernant la partie rôles/fonctions et s'il existe des complexité liées à l'environnement et à la sécurité. C'est une analyse fonctionelle qui nous permet d'observer si la solution peut "matcher" ou non avec ce que l'entreprise souhaite.

Implications de sécurité à prendre en compte :

Toutes les solutions doivent donc être durcies et encadrées par des couches externes (WAF, proxy, filtrage sortant, supervision).
La fiabilité du projet dépendra autant de cette enveloppe de sécurité que du choix du bastion lui-même.

Analyse transversales des solutions et des fonctions

Analyse finale – Synthèse

L’étude menée sur ces bastions SSH open source a permis d’identifier quatre solutions matures et techniquement crédibles :

• Teleport apporte une approche “Enterprise-grade” avec certificats éphémères, SSO, RBAC complet et audit centralisé.
• The Bastion (OVH) incarne la philosophie française open-source souveraine, avec une sécurité SSH stricte, une conformité ANSSI-ready, et une maintenance minimaliste.
• Warpgate, plus récent, se démarque par sa légèreté, son code Rust sécurisé, et son excellente compatibilité multi-plateforme (PC/mobile).
• JumpServer s’impose comme un PAM open source complet couvrant SSH/RDP/DB avec gestion LDAP et clusterisation.

Conclusion ouverte

L’évaluation démontre qu’aucune solution unique ne couvre parfaitement tous les scénarios, mais que chacune possède une forte valeur ajoutée selon le contexte d’exploitation.
Le choix définitif devra être guidé par les priorités internes (sécurité, mobilité, gouvernance, souveraineté), la politique de conformité et de traçabilité imposée aux environnements Cloud.

Dans tous les cas, l’approche Zero Trust, le durcissement de la surface exposée, et la centralisation de l’audit demeurent les véritables garants de la sécurité globale du projet.

L'étude menée lors de la première étape de mon stage m'a permise de découvrir l'environnement technique actuel, de comprendre comment étaient gérés les accès et ce qu'il était possible d'améliorer. La seconde étape consiste à déployer des "environnements de test" virtualisés et de documenter des procédures.

Après réalisation des tests, une décision concrète sera prise avec la direction et la Purple Team concernant la possibilité du déploiement définitif sur l'infrastructure.

L’article Projet R&D ~ Analyse de solutions de bastion d’administration SSH est apparu en premier sur Aukfood.

Ce webinair en partenariat avec Circuit Libre avait pour objectif de présenter les fonctionnalités majeures de Nextcloud et les nouveautés de la version "Autumn 25".

L’article Webinair : Nextcloud : le cloud collaboratif qui envoie les watts ! est apparu en premier sur Aukfood.