Hey. Nous, l'équipe du projet CrowdSec, sommes heureux d'annoncer la sortie de CrowdSec 1.0.0. Cette version est extrêmement importante car en plus d'ajouter quelques nouvelles fonctionnalités, l'ensemble du projet a subi des changements architecturaux majeurs pour devenir plus rapide, plus grand et plus fort.
Tout d'abord, nous sommes heureux de vous présenter le principal changement de ce patch - l'introduction de l'API REST locale. Grâce à lui, l'ensemble du projet a sérieusement modifié son architecture pour simplifier et faciliter l'interaction des composants au niveau local. Cependant, la facilité d'utilisation globale n'a pas souffert - l'utilisation de CrowdSec est toujours facile et agréable.
Pour ceux qui ne connaissent pas CrowdSec ou qui se demandent comment la startup française est arrivée sur Habré en général, faisons une petite digression:
, , , Fail2Ban: «CrowdSec — Fail2Ban ».
, , IT-. . , — .
, . , , . 1.0.0 :)
Comment c'était et comment c'est devenu
La principale chose qui s'est produite avec la sortie de la version 1.0 a été l'introduction de modifications à l'architecture, qui se sont produites en raison de l'introduction de l'API REST locale dans le travail. D'un point de vue architectural, notre système se compose de trois composants principaux:
- un service CrowdSec fonctionnant en permanence qui surveille les journaux, les attaques, etc.
- ligne de commande, interface pour interagir avec le service;
- modules d'intégration (bouncers) pour assurer le blocage des adresses attaquantes.
Voici un diagramme de la façon dont CrowdSec fonctionnait auparavant:
Comme vous pouvez le voir sur le diagramme, au moins trois éléments du système accédaient constamment à la base de données. Dans le diagramme, ces directions sont marquées par des cercles rouges (cwcli-DB, plugins de sortie-DB, Bouncers-DB). Dans le même temps, «Bouncers» signifie au moins cinq modules qui communiquent en permanence entre la base de données de réputation et la base d'adresses IP interdites.
Lorsque vous développez un projet à partir de zéro, ces béquilles sont un moyen simple, rapide et peu coûteux de créer un prototype fonctionnel d'un système. Cependant, si l'on parle de stabilité et de rapidité de travail, autant de points d'accès à la base de données ne sont pas la meilleure solution. Cette architecture du projet a conduit à l'émergence d'un certain nombre de limitations que nous avons rencontrées lors des étapes de développement ultérieur de CrowdSec. Par conséquent, nous voulions nous en débarrasser le plus rapidement possible.
Après avoir repensé le projet au niveau architectural, nous avons décidé que la meilleure option serait une API REST locale, à travers laquelle la communication des composants ci-dessus et de la base de données passerait déjà.
En conséquence, nous avons obtenu l'architecture suivante:
Désormais, tous les modules internes communiquent entre eux et avec la base de données exclusivement via l'API REST.
Le principal avantage de l'API par rapport à l'ancienne implémentation est la simplification des modules (Bouncers) par rapport à l'ancienne version de CrowdSec. Si auparavant le videur accédait directement à diverses bases de données, maintenant, grâce au travail via l'API REST, il n'a besoin que d'une seule requête HTTP-get avec un jeton API. Tous les autres travaux se déroulent du côté de l'API.
Schéma cloud CrowdSec
Dans la vue classique, on suppose que l'une des machines aura la partie serveur de CrowdSec déployée, qui, via la nouvelle API, sera capable de gérer des modules sur d'autres machines au sein du réseau défini par l'administrateur. S'il le souhaite, l'utilisateur peut utiliser sa propre base de données d'adresses interdites, ou accéder à notre base de données sur une base payante. Cependant, créer un point de communication unique entre l'API REST locale et notre propre API crée une nouvelle opportunité: le fonctionnement de CrowdSec sur un modèle proche du cloud SaaS.
L'administrateur n'a plus besoin de déployer une partie serveur CrowdSec à part entière avec une API REST locale sur sa machine. Au lieu de cela, il peut utiliser notre API CrowdSec centrale externe et n'utiliser que des videurs pour sécuriser le réseau.
aditionellement
Pour ceux qui ont déjà utilisé CrowdSec, nous vous suggérons de consulter la liste complète des changements de la version 1.0.0 par rapport à la version 0.3.x sur GitHub .
Les nouveaux utilisateurs sont invités à se référer aux informations de notre référentiel sur GitHub .
Nous tenons à souligner que CrowdSec est un outil open source qui est publié sous la licence gratuite MIT. Ainsi, tout le monde peut l'utiliser gratuitement. Le projet n'a pas encore été monétisé , nous sommes au stade de l'élaboration de notre propre liste d'interdiction et de nos plans tarifaires. Sur notre site Web hub.crowdsec.net, spécialement pour les nouveaux utilisateurs, des collections, des configurations et des videurs prêts à l'emploi sont collectés pour faciliter la configuration et commencer à utiliser CrowdSec.
Vous pouvez poser toute question sur notre projet ici même dans les commentaires. L'utilisation de l'anglais simplifiera la communication - nous n'avons pas besoin d'utiliser Google, traduisez ou demandez à des amis russophones de traduire votre message pour nous.