Hello, everyone. My name is Hamza and this is my colleague Sebastian. We are working
at CrowdSec and today we're going to introduce you CrowdSec, show you how, explain you how
it works and show you how we can protect your Kubernetes cluster using it. So, how CrowdSec
was created. We start with the basic statement that, yeah. So, cybersecurity, we start with
the basic statement that cybersecurity is not a problem of means. As you can see, those
big companies has huge amount dedicated to cybersecurity. They have security teams, but
they get stick hacked. And the reason, we think that the reason why is because, sorry,
because they try to fight alone, like using the superhero approach, fighting alone attackers
while those attackers are sometimes collaborating together to attack. So, as we are a lot of
users that want to legitimate businesses, why not collaborating, sorry, all together to
fight those attackers? So, how this collaborative IPS works. So, basically, CrowdSec needs to
ingest logs. So, we have a lot of handled data sources, like flat file, basic. It can
also act as a syslog server to receive syslog inputs. You can also read your Docker container
output logs on the cloud part. We have a cloud trail on the stream processing. We have also
Kafka, Kinesis, and so on. Then, we have the IDS part. So, the IDS part is a component,
what we call the agent. The agent is here to pass the logs and detect bad behaviors.
And this is where the community aspect starts. We have a hub, like Docker hub, where we wrote,
we wrote, sorry, our scenarios to detect the common attacks. And we share them with the
community. And then, here, the other users, they write their own parsers to handle new
services, new bad behaviors, et cetera. And they share them with the community. You can
also write your own scenarios to detect, like, a specific behavior in your internal
infrastructure, for example, and not share it, of course. And once this detection is done,
we have the IDS part. So, the IDS part is what we call, it's another component of CrowdSec
called the bouncers. And the bouncers are here to allow you to do a remediation in multiple
parts of your infrastructure. So, for example, the basic one is to have the firewall bouncers.
So, the firewall bouncers will communicate with the CrowdSec, get the decisions, and
block them at the firewall level. That you want sometimes have a smarter remediation,
like, for example, you run an eShop, and we know that sometimes we have a lot of clients
that are behind a single IP. So, what we want to do is to, when a bad behavior is detected
from an IP, we want to push a captcha to the user. So, we let humans still access to the
website, but block the bots. And, of course, we have a lot of other bouncers on the Cloud
side, or also other bouncers that are written by us and by the community, of course, and
they are also available in the hub. And when this remediation is done, we have the reputation
part, and what we call the community block list. So, we receive the signals for, we send
the signal to the community, to the central API, sorry, we receive all those signals,
we curate them, and then we return to the community the most aggressive IPs. So, you
are protecting yourself and protecting the community, and you benefit also from the community
feeds. So, we are, CrowdSec already deal with a lot of common attacks, more than 50. Web
scan, port scan, traditional scan, stuff. But also, thanks to the inference engine of
CrowdSec, you can, it allows us to detect more complex attacks, like, for example, L7D
dose or credit card stuffing, which is a very business-specific issue. So, for example,
when you have for credit card stuffing, it's when an attacker buys some credit cards from
a shady website and wants to test if those credit cards are valid. So, here we go to
a eShop and try to do a small purchases. So, you can detect this kind of attacks, also
both scalping, et cetera. Basically, you can detect, if it's in the logs, as CrowdSec ingest
logs, you can detect it. And thanks to that, we are building a real-time, a real-time map,
sorry, of cyber criminals. It's kind of like ways that in cybersecurity. So, the more we
are and the more efficient is the radar. And, of course, it will allow us to kill the most
important resource for the attackers, which is the IP addresses. Now, I will let my colleague
take the next slide. Hello, everyone. So, first thing about privacy, because, as Hamza
mentioned, you do send us data about the attacks you see. But we do collect only the strict
minimum to be able to build the community block list. This means that your logs will
never, ever leave your own server. Logs are processed locally by CrowdSec, and you will
only send some metadata about the behaviors that are detected by CrowdSec. So, those metadata
are just the IP that you blocked, the reason why. So, for example, SSH could force, and
the time at which you block the attack. And that's it. Nothing else. And also, this part
is totally optional. If you do not want to send anything to us or the community, you
don't have to. But if you don't send data, if you don't share with the community, in
return, you will not get the community block list. And also, we keep the data for the least
amount of time possible. So, basically, every IP in the community block list will be automatically
dated after one week if the IP does not perform any more attack on the community. And for
the raw data we receive, after three months, it's degraded, and after nine months, it's
totally dated. Now, how do we build this community block list? Because we receive reports from
all over the community, but we cannot trust those reports because it's just an API. If
someone wants to send us the information that ISO 1.1.1 performing SSH could force my server,
we have no way, basically, to know if it's true or not. So, we build something called
the consensus. So, we get the report from all over the community. And then, each user
in the community has a trust score. So, this score is really how much we trust you. It's
built over time. So, the longer you are part of the community, the more your score will
increase. But it will also take into account how active you are in the community. So, if
you report just one IP per day or someone that is reporting 100 IP per day, we will just
give a slightly better score to the user reporting 100 IP per day. And we will also correlate
your report with other community members. If you are the only one sending us the information
about a particular IP, this IP will never go into the community block list because we
cannot confirm that it is indeed an IP trying to attack servers on the internet. But if multiple
users report this IP, then we will be more confident about the fact that this report is
exact. We do also run some own iPods and because those are fully controlled by us, they are
fully trusted. So, if someone tries to attack them, we know that this is an actual report.
We do also have some white list because if someone send us IP belonging, for example,
to a cloud flare, obviously, this is not something we want to redistribute to the community.
And again, if you do send us too many false positive reports like this, your score will
be reduced because we know that your report are potentially false. And lastly, we do also
have some more advanced algorithms that, for example, we look at the bigger picture, if
you take a slash 24 network, and like 50% of this network is already in the community
block list, when if we see another IP belonging to this network, it's quite likely that this
IP is also bad. Same thing, for example, if the IP reported to us exposes, like I don't
know, a tenant server, 20 different services on the internet, again, it's more likely that
the IP has been compromised. And so, when a report goes through everything, we will take
a decision and it will go into what we call the fire database, so the community block
list, and it will be pulled automatically by all the community members. Now also, for
the usefulness of the community block list, a while back, we ran a small experiment where
we had two different servers on the internet, on the same hosting provider, those two servers
had the exact same set of services exposed on the internet, so to adjust a wide server
and SSL server, the only difference between them was one was using the community block
list, and the other one was not. On the one using the community block list, we saw around
92% less attack on the server detected by protect. So because basically, most of the
IP that are trying to scan your server exposed on the internet are basically trying to do
it for all the internet, and so this is just some background noise, you don't really care
about it, you can just block it before it can try to attack you. Another thing that we
get asked quite often is, okay, so I want to replace my firewall with QuartSec, I want
to replace my auditing system with QuartSec or whatever. Please don't do that. It's not
designed to do that. We don't compete with this kind of solution, but on the contrary,
we can help them to be more useful. So, for example, if you have an auditing system telling
you that, okay, so I saw command execution on this server, and it was a curbside bash
or something or whatever, but you can configure QuartSec to pass those logs, to detect this
behavior, and just to send you a notification. It does not have to be something about an
IP address, it can be a local behavior as well, or something with firewall. You don't
have to go into the configuration at the IP, just add the IP in QuartSec with one simple
command, and then QuartSec will take care of pushing this information to your firewall
and the IP will be blocked. So, for the architecture of QuartSec, so as I mentioned before, so
QuartSec will ingest some logs, pass them. So, this is the role of what we call the agent.
The agent will read your logs, pass them, and confront them against scenarios. So, a
scenario, just something that describes a malicious behavior. For example, a boot for
someone trying to scan your website and so on. When the agent detects a malicious behavior,
it will create an alert and will be sending this alert to another component of QuartSec,
the local API. So, this means that the agent can live on one server, the local API can
live on another server. The local API will take this alert and transform it into a decision.
For example, by default, it's for our ban on the IP. But you can customize this behavior,
and for example, you can say, so, this IP is French, it performs something related to
an HTTP attack. So, instead of just banning it, I'm going to ask my boncer to display a
capture for this IP for four hours, for example. So, and when the local API receives a decision,
it will be sending us information about the alert. And in exchange, you will receive the
community block list. The local API is also used by the boncer, so the components that do
actually apply the decision because QuartSec by itself will just do the detection part. It will
not block anything. For that, you need boncers. So, we have quite a few of them. The most
popular one is probably the firewall boncer that will interact with the local firewall
of the server where the boncer is going to block the IP. But we do also support a web
server, for example, in GenX. And in this case, because we are at a higher level in the
network, you can display a capture to the user instead of just grouping the request. So, here,
it's the design that will be used in the following demo. So, a very small Kubernetes
cluster running locally with just two nodes, one agent per node deployed as a demon set,
one local API for the agent to be able to send the alert. The agent will be reading the logs
of the ingress of the cluster. In this case, Angelix ingress. And we will have a boncer,
the Angelix boncer running on the ingress to block automatically the IP if QuartSec wants
to ban them.
Okay, thank you. So, as we have, we are crazy guys, we're going to do a live demo. And,
yeah, just think I have some. So, as Sebastian said, we're going to, we have a small, locally,
of course, not online. Yes, of course, sorry. Thank you. Okay, so, what we're going to do
is to, so, sorry for that, but I will, so this will create Kubernetes cluster with two nodes
with ingress controller, Angelix, and a Hello World app, like it's a demo application. Nice.
Okay. So, here we can see that. Okay. We have one ingress controller. And we have two nodes.
Okay. So, what we'll do now, I will not spend time to explain you, like, the QuartSec values
because we released a hand chat that will allow you to install QuartSec in a Kubernetes
cluster. As I said, it deployed a demo set. So, in each node, it will deploy a QuartSec
agent and one local API in a specific name space. And, of course, your decisions will
be centralized across all your nodes. So, here, we will install QuartSec. So, basically,
we just install QuartSec using these values. And this is the hand chat. Of course, I already
import my repo in the namespace QuartSec and create it if it's not exist in the namespace.
So here, if we are. Okay. Yeah. As I popped a new cluster, I have to wait for the image
download. But it will come no more. Okay. What I can do, yeah, of course, what I can
do is to show you that I'm able to access my Hello World app. So, it's basically an
Hello World. So, it returns the two OO. And, okay. We have one pod that is running.
Demo effect. As usual. Let's install. Wait. Why? Ah. Okay. So, now, yeah, we're going
to fetch this one. So, okay. I will follow my logs from this agent. So, logs minus F.
Agent and N. All right. So, here is my QuartSec logs. So, now, what I will do is to run Nikto,
which is a simple, okay. A simple web scanner to attack my Hello World application. And here,
we can see that I can even already, okay. Here, we can see that it automatically detects
as it's automatically parsing the logs of the ingress controller. It detects some bad
behaviors because I already installed, like, collections that are bundles of parsers and
scenarios. And you can see that it detects bad user agent, some sensitive file access,
patch traversal, et cetera. So, if I do something like that and get a shell on QuartSec, sorry
for the noise, local API. And if I list the decisions that were taken, we can see that
we have six other entries like this one because we detect several times my IP as I'm working
locally. That's why we have those IPs. And this is the last behavior that was detected.
So, now, what we will do is to install the bouncer because we are detecting, but we get
still access to the application. So, now, we will patch our ingress controller to install
the new app plugin to communicate with the local API and get banned, of course. So, now,
here we have the command. So, we can go fast and at time. So, I'm upgrading my ingress
controller, sorry. Okay. Okay. So, now, if we try to access now to the Hello World application,
we can see that we will receive a 403. So, if I do this... Sorry, I didn't see that.
Yeah, it's the... Let's wait for this and upgrade.
Okay. Okay. Nice. So, it's popping the new ingress controller. Of course, it's local.
That's why we have only one pod. I don't recommend that in production. So, it's deploying the
new ingress controller and loading, of course, the crowd-seq bouncer. It's a Lua library
that is talking with the local API. And on each request, we have this check. Come on.
Yes, of course. I think we hand it. No. We have still time. So, we can take some questions
and I will follow them. We've got time for like one question. So, there is one fast question
for one minute. Feel free to answer it. Okay. Just to hand the demonstration. It's running
and now we have a 403. So, that's it. Okay. So, thank you. Yeah. This is the challenge
with the demonstrations. If you have some questions, don't hesitate. And of course, we have some
stickers. So, don't hesitate to come to us.