Using "Machines"

crowdsec
1

I’m playing around with Crowdsec and installed the dashboard. But I’m curious about the MACHINES option in there. Is there a way to use a single dashboard to connect and monitor to multiple servers (“Machines”)? I couldn’t find any clear guidelines on how to use this.

Thanks so much in advance for any guidance.

2

Hello @blues !

While for users that want a simple fail2ban replacement, crowdsec might appear as a standalone software, it can actually be broken down into several components, where the “agents” (machines in your case) can run here & there, while reporting their alerts to a central component (local API) that is then used by cscli and bouncers to consume & view alerts.

You can thus connect several machines to the same local api, as it might appear in this schema :

image
image1062×659 70.8 KB

Please check if this piece of documentation answer your questions : https://doc.crowdsec.net/Crowdsec/v1/localAPI/#machines

And let me know :slightly_smiling_face:

3

Hi:

Thanks. Unfortunately the data in the documentation for the link you provided is very obtuse. Maybe if I provide a simple scenario someone can help me figure out how to make it happen?

Machine #1 with IP 123.456.789.001
This machine is where I install the full CROWDSEC stack including the dashboard. For the purposes of this scenario lets assume that its handling NGINX logs.

Machine #2 with IP 123.456.789.002
This machine is where I install the full CROWDSEC stack without the dashboard. For the purposes of this scenario lets assume that its also handling NGINX logs.

How do I get Machine #2 to connect to Machine #1 and push its data there so that I can monitor Machine #2 from machine #1’s dashboard?

Unfortunately, reading the documentation under “machines” does not make it clear at all how to do something like this. Maybe I’m just not smart enough to read abstracted ideas and implement them in the real world. (Or maybe I need to get Machine #1’s dashboard to connect to machine #2 instead and pull the data? It’s not clear whether one machine should be pulling or pushing data. The image above uses the term “push” so I assume "pushing from machine #2 to #1 is the correct paradigm…)

Thanks very much for any additional help this group can provide!

4

Hello !

Sure, let’s take this occasion to further improve the documentation, it is indeed still quite obtuse :slightly_smiling_face:

We’re going to make machine #1 the “master” (with the dashboard etc.) : It has crowdsec, the local API and the dashboard, and machine #2 will simply be a slave to it, pushing its alerts there :

  • make sure machine #1 API can be reached from machine #2
  • generate a new machine account on machine #1 that can be used on machine #2
  • configure machine #2 so that it pushes its alerts to machine #1

Assuming you have crowdsec already install on both machines, we are going to make sure that machine #2 pushes its alerts to machine #1 instead of dealing with them locally (so your assumption was right) :

  1. on machine #1, let’s edit /etc/crowdsec/config.yaml to make sure that the API can be reached from machine #2. You’re going to find the api → server section to edit the listen address :
api:
...
  server:
    log_level: info
    listen_uri: 0.0.0.0:8080

note: with this change, once you restart crowdsec, the API should be accessible from other machines. Ensure that you can telnet 123.456.789.001 8080 from machine #2 before moving further

  1. on machine #1, let’s create a new machine credentials :
$ sudo cscli machines add machine_2 -a -f machine_2
$ cat ./machine_2
url: http://127.0.0.1:8080/
login: machine_2
password: xxxx

note: what matters here is the login and the password, we’re going to use them later

  1. on machine #2, we’re going to configure crowdsec so that it pushes alerts to machine #1. This time, we’re going to first of all edit /etc/crowdsec/local_api_credentials.yaml (you can see this file referenced in the /etc/crowdsec/config.yaml file, api → client section). It is the file that tells crowdsec to which API endpoint (and with which credentials) it should speak to.
url: http://123.456.789.001:8080/
login: machine_2
password: xxxx

note: I replace the url with the example IP of machine #1, use the real ip here.

Once this is done, if you trigger an attack on machine #2, you should see it in cscli decisions list and the dashboard on machine #1. If you’re using cscli from machine #2, it should as well speak directly to machine #1

Please let me know. Once it’s good, I’ll update the documentation with this :slight_smile:

3 Likes
5

Hi - Thanks. I’ll run with this and give you feedback on how it worked.

1 Like
6

Hi:

It looks like we were able to connect the machines. However, in viewing the data in the dashboard, a lot of the lists don’t show a “machine” column so we’re not sure exactly which machine is triggering each item in a list. Is is possible to add a “machine” column to the raw data lists (eg: descisions, alerts, events etc?

7

Hello, @blues

Indeed this column is missing, we are going to add it.
We come back to you when you will can reinstall your dashboard.

8

Thank you ,that worked for me, after hours of searching…

9

Ok for

listen_uri: 0.0.0.0:8080

next I dit it via :

on machine 2 “client”

cscli lapi register --machine machine2 -u Ip_Machine1:8080

On machine 1 “server”

cscli machines validate machine2

No pass or edit to do on /etc/crowdsec/local_api_credentials.yaml

Is it “legit” ??? Did I miss something ?

10

Hello @tranbert ,

Yes it’s legit :sweat_smile: :

  • cscli lapi register --machine machine2 -u Ip_Machine1:8080 : on “client” machine, this will write to /etc/crowdsec/local_api_credentials.yaml, instructing crowdsec to speak to Ip_Machine1 to push its alerts
  • cscli machines validate machine2 will actually allow “client” to speak to the server

And on this note, we’ve published a blogpost about this topic that I hope will help :

11

Thanks…

Seen that blogpost yesterday… after posting ! :yum:

1 Like
12

ahah sorry, better late than never :grimacing: