How time flies… it's been two years since we first talked about Crowdsec… I intend to make some updated documents on the possibilities of its deployment, since it is a very interesting product to protect our organizations against threats and offers us many interesting possibilities.

In previous posts, perhaps more detailed, we already described the possibilities of Crowdsec, but to make an introduction for those who do not know him, It is software that can be installed on different types of machines, with Windows OS, Linux… And the goal is to protect that machine (or your network), By reading the machine logs you will make decisions, such as banning the IP that has been made by an attack attempt, or someone has validated themselves badly, etc…

There are several components, has an agent that processes the machine logs, of the services it runs, such as the event viewer, of an IIS, Nginx, Apache, MariaDB, Exchange, Nextcloud, SMB, RDP… compares the logs with the different scenarios and sends the alerts to the LAPI service (local API); that receives alerts and turns them into decisions (based on the protections we have set up). And then we have the bouncer (o Remediation component), which consults the decisions of the LAPI and implements them; for example the firewall bouncer, that will create rules in the OS's FW denying access to the IP address that has generated an attack.

In principle, although it may seem otherwise, it is very simple, all components are installed together when installing the Crowdsec Agent (o Engine). When Crowdsec is installed on a Windows or Linux, it will detect the services that the machine is running, and therefore they will already be protected, if it is a Linux and has (For example) a Nginx will already read and process the OS logs, as well as those of Nginx himself, looking for patterns that detect attempted abuse by vulnerabilities, Scans, improper access… In addition, other types of collections may be added’ to read other types of logs, just in case a Nextcloud runs in that Nginx, and we want Crowdsec to also process Nextcloud logs…

What I said, It's simple, It's new if you don't know it, but it is very well planned, if we install it on a Windows Server, ditto, it will detect if we have, for example, an IIS installed, or a SQL Server… and as we install the Crowdsec Agent it will detect patterns in the event viewer logs to protect us. And what I said, whether that IIS runs any particular service, Well, we can also protect it, be it for example an Exchange (both OWA and SMTP) being able to read their specific logs.

What we would have left is to be able to apply the actions, that if he reads something he doesn't like in a log, Act. To do this,, usually on Windows and Linux we need to install the firewall bouncer later, As I said, so that this remediation component can create a rule in the operating system firewall, Windows or Linux, A Temporary Rule, of denial, blocking access from the attacking IP address.

This is how we have our Windows or Linux machines protected, but they do not speak to each other, and it would be interesting if they could communicate with each other. So this step is optional, perhaps for small environments, but of course totally recommended for any organization. We can easily create a Crowdsec server in a Docker container, For saying, this server will share a centralized database with all decisions via LAPI, ¿For what? In case we are interested in that if a machine receives an attack, the rest of the Crowdsec machines find out and take an action, however to protect and ban a particular IP address, All at once. And another of the wonderful containers that we will deploy is Crowdsec blocklist mirror, Pure magic, this container will publish in a URL the blacklist that all Crowdsec machines share. ¿For what? To be able to access it from our internal or perimeter firewalls such as Fortigate, Checkpoint, pfSense… and make rules of denial, Between networks, from the WAN… and directly isolate attackers to another level.

Well, After this rant, And already being the ember, Today's document is based on how to unfold this last part that we have talked about, We are going to deploy the core infrastructure, we are going to deploy these containers and in other documents we will see how to install Crowdsec on a Windows and protect it, centralized or not; as well as a Linux.

Crowdsec deployment for multi-server environment

Mkdir Crowdsec CD Crowdsec

We start for example on an Ubuntu Server, with his FQDN, a static IP address, with NTP properly configured, updated and with Docker installed. Let's see how quickly these two containers unfold. We create a directory, Walked, and we start. We will create the docker-compose.yml file with the following content:

version: '3'

services:
  crowdsec:
    image: CrowdSecurity/Crowdsec Restart: Always ports:
      - '8080:8080'
      - '6060:6060'
    volumes:
      - ./crowdsec-db:/var/lib/crowdsec/data/
      - ./crowdsec-config:/etc/crowdsec/ crowdsec-blocklist-mirror:
    container_name: crowdsec-blocklist-mirror image: crowdsecurity/blocklist-mirror depends_on:
      - "crowdsec"
    ports:
      - 41412:41412
    Volumes:
      - ./cfg.yaml:/etc/crowdsec/bouncers/crowdsec-blocklist-mirror.yaml volumes:
  crowdsec-db:
  crowdsec-config:

What I said, will deploy two containers, one Crowdsec that will act in principle as a LAPI server in the 8080 and in the 6060 if interested, it will spit out metrics, On port 41412TCP we will have the container that publishes the blocklist, A mirror.

We unload and start the containers with:

sudo docker compose up -d

The first time, the Blocklist-Mirror container will not lift as it needs access with its API key, So we created the first Bouncer, for Blocklists:

sudo docker exec -it crowdsec-crowdsec-1 cscli bouncers add BlocklistMirror

GOOD, stop the Crowdsec container and delete the configuration file to recreate it below.

Sudo Docker Stop CrowdSEC-CrowdSEC-1 RM -rf cfg.yaml/

And we create with 'nano cfg.yaml’ the configuration file, That it must be something like this, keep in mind that you must indicate the API key that we have requested from Crowdsec and indicate the IP address by which we will publish the LAPI service. As well as in the Blocklist add the IP address that will connect and have access to the blocklist URL, for example our perimeter firewall.

config_version: v1.0 crowdsec_config:
  lapi_key: xxxxxxxxxxxxxxx lapi_url: HTTP://DIRECCION_IP_MAQUINA:8080
  update_frequency: 10include_scenarios_containing: []
  exclude_scenarios_containing: []
  only_include_decisions_from: []
  insecure_skip_verify: false blocklists:
  - format: plain_text # Supported formats are either of "plain_text"
    Endpoint: /security/blocklist authentication:
      type: none # Supported types are either of "none", "ip_based", "basic"
      user:
      password:
      trusted_ips: # IP ranges, or IPs which don't require auth to access this blocklist
        - 127.0.0.1
        - ::1
        - 192.168.1.1

listen_uri: 0.0.0.0:41412
TLS:
  cert_file:
  key_file:

Metrics:
  enabled: true endpoint: /Metrics log_media: stdout log_level: info

We will be able to start the Crowdsec container again and the Blocklist-Mirror container finally, Running:

Sudo Docker Start CrowdSEC-CrowdSEC-1 sudo Docker Restart CrowdSEC-Blocklist-Mirror

We test that we can access the blocklist URL from: HTTP://DIRECCION_IP_MAQUINA:41412/security/blocklist

Enroll in the CrowdSec Console

It will be highly recommended to register at https://app.crowdsec.net and register in our Crowdsec Console account. From here we will be able to view the status of our Crowdsec Agents or Engine, We may subscribe them to other blacklists in the community, Manage alerts, Historical… To register our Crowdsec, We will do it from the web, “Security Engine” > “Engines” > “Add Security Engine”, we will get a drop-down menu that we will copy and execute on our Crowdsec server (to call it something).

And we execute it, in this case we modify the command a little since we will execute it through Docker:

Sudo Docker exec -it crowdsec-crowdsec-1 cscli console enroll -e context xxxxxxxxxxxxxxx

Back to the Crowdsec Console (And if we don't see it, F5), We will find that it has detected our registration request, Click on “Acept enroll”,

Once we have it in stock, we can first edit the name to recognize it better, About her “Edit name or tags”,

We give it its machine name and click on “Update”,

We can continue if we want to subscribe it to certain Blocklists offered by Crowdsec, The Community… This way the machine will be protected from certain botnets, Evil… for this, Click on “Blocklist” where we see that it is subscribed to 0,

Click on “Browse available blocklists”,

And here we will come up with a series of lists, we can choose up to 3 for free with the Community type account, We can choose the type of the lists, the ones that convince us the most, Need… about each of them, We will give “Manage”,

And in “Add Security Engine”,

Here we will see the machines that have the Crowdsec agent installed, Select the machine to subscribe and the type of action, if a ban to the IP or require a Captcha when accessing. “Confirm Subscription”.

In principle we are going to leave the document here, We can say that the central scenario has been minimally left, the machine that will offer LAPI services for the rest of Crowdsec's Engines or the blacklist of our perimeter firewalls. The next steps will be to deploy Crowdsec agents where we need them, And if we are interested, because we integrate them into this facility and thus they can make joint decisions among themselves.

I hope it can bring you something, clarify if anyone had doubts or did not know him, or you want to implement it in a LAB and try solutions like these, Easy, Simple, for the whole family. And that we provide security and anticipate scares… Well, that, No? You know, I'm going to be a vampire, I hope it goes VERY well for you, Hugs!