Ok, so I created a LXD container and installed CrowdSec. I read the documentation and it appears to be an IPS system. It installed just fine. I figured it might have some kind of web interface. I’m not seeing any web interface on port 80 of the server. It appears that this is an IPS system to use a command line interface to test a target server for ummm something. After 40 years of networking background, I have no clue what this product is doing or how. I read pages and pages of command line tests you can use to test remote servers. So, I conclude that this is a port scanner. Am I right?
Hi and thanks for your post.
FIrst of all: I have no experience with LXD containers so I can’t answer anything in relation to that.
It seems there’s a basic understanding of CrowdSec you need to have in place first. In its simplest form, a workign installation of CrowdSec consists of the agent and the bouncer. CrowdSec works by parsing log streams typically found in a log file and detects attacks. The agent is the intelligent part that does the heavy lifting and the bouncer blocks.
So no, it’s not a port scanner.
I don’t know if you’re a person who prefers looking a videos to learn but if you do, here’s a good one.
Feel free to get back once you’ve achieved a basic understanding of CrowdSec.
You were correct in that this video was a good start. I believe that this product will work well for folks that have a network configuration that is “soft on the inside” where node level security is needed. Since crowdsec and its bouncers need to be installed on every single server instance, the level of labor and maintenance required appears to exceed the utility. The same could be said for running a firewall on each server. CrowdSec is probably very appealing for a University or Corporate network where “inside hardening” is of paramount importance. My mistake in first looking at this product was believing that it was installed on one node and could operate on a network. I guess I was hoping that CrowdSec could become a network Service like Pi-Hole or Unbound and provide overall utility and function to everything on the network. I tend to shy away from software that complicates configurations. Application virtualization on LXC containers would necessitate an installation of CrowdSec on each and every container if I understand correctly.
Hi again
What makes you think that CrowdSec can’t run from one central server? That’s exactly what it’s designed for. It’s possible to centralize logparsing with syslogd and have logparsing in one or a few central servers. Those communicate with bouncers (that needs to be installed on each server since they do the actual blocking of traffic). There doesn’t need to more than one local api server which would handle other CrowdSec agent instances. On Introduction | CrowdSec under ‘Architecture’ you will see that each component of CrowdSec communicates via http rest api.Each of those components can run distributed.
Did you have a particular architecture in mind?
I would think that an architecture similar to Mesh Central would be more attractive. Specifically, the installation and maintenance of the client piece needs to be managed and tracked from your central server. Hand installation of distributed clients is problematic and labor intense. Tracking which clients lack the bouncers is also critical in an architecture that is supposed to provide server hardening.
That is spot on. That’s why people build playbooks for Ansible for instance. In that sense we’ve created a product that’s very devops friendly. Also we plan to release a commercial version of our web console for fleet management for enterprises who has that need.