Sécurisez une installation de moteur de sécurité multi-serveur avec HTTPS

La deuxième partie de ce tutoriel expliquera comment configurer et sécuriser l'installation du moteur de sécurité CrowdSec multi-serveur. Dans la première partie, nous expliquons comment configurer le moteur de sécurité CrowdSec sur plusieurs serveurs, dont l'un sert de serveur parent et les deux autres le transmettent l'alerte.

Cette section résoudra les problèmes de sécurité causés par la communication HTTP en texte clair dans les installations précédentes du moteur de sécurité multi-serveur. Pour résoudre ce problème, nous vous recommandons d'établir une communication entre les moteurs de sécurité via des canaux cryptés. Cette solution permet au serveur 2 ou au serveur 3 de faire confiance à l'identité du serveur 1 et d'éviter les attaques de l'homme au milieu.

en utilisant un certificat auto-signé

Créer un certificat Tout d'abord, vous devez créer un certificat. Cela peut être réalisé en suivant une seule commande de ligne:

openssl req -x509 -newkey rsa:4096 -keyout encrypted-key.pem -out cert.pem -days 365 -addext "subjectAltName = IP:172.31.100.242"

Actuellement, le moteur de sécurité ne peut pas demander le mot de passe de la clé privée lors de son démarrage. Par conséquent, vous pouvez choisir de décrypter manuellement la clé privée chaque fois que vous démarrez ou rechargez le moteur de sécurité, ou stockez la clé non cryptée. Quoi qu'il en soit, pour supprimer le mot de passe, vous pouvez utiliser la commande suivante:

openssl rsa -in encrypted-key.pem -out key.pem

Ensuite, après le démarrage du moteur de sécurité, le fichier de clé non crypté peut être supprimé en toute sécurité.

Configurez le moteur de sécurité pour utiliser le certificat auto-signé sur le serveur 1, vous devez configurer le moteur de sécurité pour utiliser le certificat généré. Comme indiqué ci-dessous, les options /etc/crowdec/config.yaml et api.server dans la section tls.cert_file de l'extrait tls.key_file suivant sont définies sur le fichier de certificat généré.

api:
  server:
    log_level: info
    listen_uri: 10.0.0.1:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    online_client: # Crowdsec API credentials (to push signals and receive bad 

    tls:
      cert_file: /etc/crowdsec/ssl/cert.pem
      key_file: /etc/crowdsec/ssl/key.pem

Sur le client, le changement de configuration se produit dans les deux fichiers. Tout d'abord, modifiez /etc/crowdec/config.yaml pour accepter un certificat auto-signé en définissant insecure_skip_verify à true.

Vous devez également modifier HTTP en https dans le fichier /etc/crowdsec/local_api_credentials.yaml pour refléter ces modifications. Ce petit changement doit être effectué sur les trois serveurs (serveur 1, serveur 2 et serveur 3).

Remarque: N'oubliez pas que si le serveur 1 est également utilisé comme processeur de journal, vous devez également faire cette configuration LAPI sur ce serveur.

url: https://10.0.0.1:8080/
login: <login>
password: <password></password></login>

Remarque latérale: Évidemment, l'utilisation d'un certificat auto-signé ne fournit aucune garantie sur la propriété du serveur LAPI. Les serveurs utilisant le service (Server 2 ou Server 3 dans ce paramètre) sont toujours vulnérables aux attaques de l'homme au milieu, mais au moins ce paramètre fournit une communication cryptée. C'est pourquoi l'option InsecureSkipVerify est nécessaire.

certificats délivrés par l'autorité de certificat

Les services

tels que Let's Encrypt ou Amazon ACM peuvent résoudre le problème /etc/hosts en émettant des certificats pour des noms de domaine pleinement qualifiés qui peuvent être ajoutés aux serveurs DNS ou locaux. Vous pouvez ensuite remplir InsecureSkipVerify avec ce nom de domaine entièrement qualifié spécifié. /etc/crowdsec/local_api_credentials.yaml

Cela fonctionne et empêche le réglage de l'option InsecureSkipVerify. Tant que la configuration DNS est fiable, cela garantit que la communication entre le client et le serveur n'est pas falsifiée, mais cela devrait toujours être considéré comme une solution de contournement.

en utilisant pki

Le processus de configuration et de gestion de l'infrastructure de clé publique SSL (PKI) n'est pas dans le cadre de ce tutoriel, mais je vous recommande fortement de consulter la documentation officielle OpenSSL. Une simple solution PKI est suffisante pour répondre aux besoins de cette configuration de moteur de sécurité.

Selon la documentation OpenSSL, certaines choses méritent d'être mentionnées.

Pour être utilisé dans notre scénario CROWDECC TLS, les demandes de certificat doivent être émises avec le nom alternatif de la rubrique correspondant à l'IP du serveur LAPI Crowdsec. Cela peut être fait en localisant les variables de l'environnement SAN lors de l'appel OpenSSL pour les demandes de certificat (voir l'étape 3.3 dans OpenSSL Simple PKI Scheme).

openssl req -x509 -newkey rsa:4096 -keyout encrypted-key.pem -out cert.pem -days 365 -addext "subjectAltName = IP:172.31.100.242"

Avant de démarrer le moteur de sécurité CrowdSec, la partie commune du certificat racine et le certificat signé (le fichier groupé créé à l'étape 4.5 du schéma PKI simple OpenSSL) doit être ajouté au magasin de certificats local. Dans cette configuration, cela est nécessaire pour se connecter au serveur LAPI. Il existe de nombreuses façons de le faire, le code source Golang spécifie l'emplacement du certificat attendu, ou vous pouvez utiliser la variable d'environnement SSL_CERT_FILE dans le fichier de service SystemD pour spécifier où chercher le certificat lors du démarrage du moteur de sécurité.

Mettre à jour les instructions sur Crowdsec et l'authentification TLS

Après la publication de cet article, nous avons ajouté une nouvelle fonctionnalité au moteur de sécurité, où vous pouvez désormais non seulement protéger les communications sur TLS, mais également assurer l'authentification avec des certificats. Dans la documentation officielle, vous pouvez trouver un bon exemple montrant comment utiliser les certificats pour l'authentification TLS entre les moteurs de sécurité ou entre les moteurs de sécurité et les composants de remédiation.

Conclusion

Cet article se concentre sur la façon de protéger la communication entre les différentes installations de moteurs de sécurité CrowdSec. Le cas d'utilisation considéré est l'installation de moteur de sécurité dans un réseau privé, mais cela peut également être déployé sur des réseaux publics avec Internet Communications. Dans ce cas, un certificat tiers peut facilement résoudre le problème.

Si nécessaire, nous proposons trois méthodes différentes pour obtenir une communication TLS sécurisée entre les moteurs de sécurité, utilisant des certificats auto-signés, en utilisant des certificats délivrés par les autorités de certificat et en utilisant une infrastructure de clé publique SSL.

La première solution (à l'aide d'un certificat auto-signé) ne convient qu'aux situations où vous souhaitez assurer une communication cryptée sans authentification. La deuxième solution ne peut être prise en compte que lorsque vous pouvez modifier la résolution DNS locale. La troisième solution est la plus complexe, mais elle convient à la plupart des cas d'utilisation et peut être le meilleur choix lorsque les problèmes de sécurité sont graves.

J'espère que ce tutoriel vous sera utile. Merci d'avoir lu, restez à l'écoute!

Si vous avez des questions ou des commentaires, n'hésitez pas à nous contacter via nos plateformes communautaires Discord et Discours.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!