[00:00.000 --> 00:13.240]  Hello, everyone. My name is Hamza and this is my colleague Sebastian. We are working
[00:13.240 --> 00:18.600]  at CrowdSec and today we're going to introduce you CrowdSec, show you how, explain you how
[00:18.600 --> 00:26.560]  it works and show you how we can protect your Kubernetes cluster using it. So, how CrowdSec
[00:26.560 --> 00:37.920]  was created. We start with the basic statement that, yeah. So, cybersecurity, we start with
[00:37.920 --> 00:43.120]  the basic statement that cybersecurity is not a problem of means. As you can see, those
[00:43.120 --> 00:49.200]  big companies has huge amount dedicated to cybersecurity. They have security teams, but
[00:49.200 --> 00:55.640]  they get stick hacked. And the reason, we think that the reason why is because, sorry,
[00:55.640 --> 01:05.080]  because they try to fight alone, like using the superhero approach, fighting alone attackers
[01:05.080 --> 01:11.520]  while those attackers are sometimes collaborating together to attack. So, as we are a lot of
[01:11.520 --> 01:19.040]  users that want to legitimate businesses, why not collaborating, sorry, all together to
[01:19.040 --> 01:27.840]  fight those attackers? So, how this collaborative IPS works. So, basically, CrowdSec needs to
[01:27.840 --> 01:35.520]  ingest logs. So, we have a lot of handled data sources, like flat file, basic. It can
[01:35.520 --> 01:41.800]  also act as a syslog server to receive syslog inputs. You can also read your Docker container
[01:41.800 --> 01:49.200]  output logs on the cloud part. We have a cloud trail on the stream processing. We have also
[01:49.200 --> 01:56.960]  Kafka, Kinesis, and so on. Then, we have the IDS part. So, the IDS part is a component,
[01:56.960 --> 02:05.440]  what we call the agent. The agent is here to pass the logs and detect bad behaviors.
[02:05.440 --> 02:13.960]  And this is where the community aspect starts. We have a hub, like Docker hub, where we wrote,
[02:13.960 --> 02:20.040]  we wrote, sorry, our scenarios to detect the common attacks. And we share them with the
[02:20.040 --> 02:27.920]  community. And then, here, the other users, they write their own parsers to handle new
[02:27.920 --> 02:33.560]  services, new bad behaviors, et cetera. And they share them with the community. You can
[02:33.560 --> 02:39.440]  also write your own scenarios to detect, like, a specific behavior in your internal
[02:39.440 --> 02:48.000]  infrastructure, for example, and not share it, of course. And once this detection is done,
[02:48.000 --> 02:57.040]  we have the IDS part. So, the IDS part is what we call, it's another component of CrowdSec
[02:57.040 --> 03:06.960]  called the bouncers. And the bouncers are here to allow you to do a remediation in multiple
[03:06.960 --> 03:11.760]  parts of your infrastructure. So, for example, the basic one is to have the firewall bouncers.
[03:11.760 --> 03:17.160]  So, the firewall bouncers will communicate with the CrowdSec, get the decisions, and
[03:17.160 --> 03:23.360]  block them at the firewall level. That you want sometimes have a smarter remediation,
[03:23.360 --> 03:28.880]  like, for example, you run an eShop, and we know that sometimes we have a lot of clients
[03:28.880 --> 03:35.000]  that are behind a single IP. So, what we want to do is to, when a bad behavior is detected
[03:35.000 --> 03:42.600]  from an IP, we want to push a captcha to the user. So, we let humans still access to the
[03:42.600 --> 03:49.720]  website, but block the bots. And, of course, we have a lot of other bouncers on the Cloud
[03:49.720 --> 03:56.880]  side, or also other bouncers that are written by us and by the community, of course, and
[03:56.880 --> 04:04.520]  they are also available in the hub. And when this remediation is done, we have the reputation
[04:04.520 --> 04:11.040]  part, and what we call the community block list. So, we receive the signals for, we send
[04:11.040 --> 04:16.200]  the signal to the community, to the central API, sorry, we receive all those signals,
[04:16.200 --> 04:21.680]  we curate them, and then we return to the community the most aggressive IPs. So, you
[04:21.680 --> 04:28.000]  are protecting yourself and protecting the community, and you benefit also from the community
[04:28.000 --> 04:39.880]  feeds. So, we are, CrowdSec already deal with a lot of common attacks, more than 50. Web
[04:39.880 --> 04:45.080]  scan, port scan, traditional scan, stuff. But also, thanks to the inference engine of
[04:45.080 --> 04:52.600]  CrowdSec, you can, it allows us to detect more complex attacks, like, for example, L7D
[04:52.600 --> 04:59.560]  dose or credit card stuffing, which is a very business-specific issue. So, for example,
[04:59.560 --> 05:04.000]  when you have for credit card stuffing, it's when an attacker buys some credit cards from
[05:04.000 --> 05:09.160]  a shady website and wants to test if those credit cards are valid. So, here we go to
[05:09.160 --> 05:17.240]  a eShop and try to do a small purchases. So, you can detect this kind of attacks, also
[05:17.240 --> 05:25.240]  both scalping, et cetera. Basically, you can detect, if it's in the logs, as CrowdSec ingest
[05:25.240 --> 05:32.840]  logs, you can detect it. And thanks to that, we are building a real-time, a real-time map,
[05:32.840 --> 05:39.160]  sorry, of cyber criminals. It's kind of like ways that in cybersecurity. So, the more we
[05:39.160 --> 05:46.960]  are and the more efficient is the radar. And, of course, it will allow us to kill the most
[05:46.960 --> 05:59.440]  important resource for the attackers, which is the IP addresses. Now, I will let my colleague
[05:59.440 --> 06:06.240]  take the next slide. Hello, everyone. So, first thing about privacy, because, as Hamza
[06:06.240 --> 06:14.480]  mentioned, you do send us data about the attacks you see. But we do collect only the strict
[06:14.480 --> 06:20.160]  minimum to be able to build the community block list. This means that your logs will
[06:20.160 --> 06:26.120]  never, ever leave your own server. Logs are processed locally by CrowdSec, and you will
[06:26.120 --> 06:32.560]  only send some metadata about the behaviors that are detected by CrowdSec. So, those metadata
[06:32.560 --> 06:39.840]  are just the IP that you blocked, the reason why. So, for example, SSH could force, and
[06:39.840 --> 06:46.520]  the time at which you block the attack. And that's it. Nothing else. And also, this part
[06:46.520 --> 06:51.120]  is totally optional. If you do not want to send anything to us or the community, you
[06:51.120 --> 06:56.240]  don't have to. But if you don't send data, if you don't share with the community, in
[06:56.240 --> 07:01.440]  return, you will not get the community block list. And also, we keep the data for the least
[07:01.440 --> 07:06.640]  amount of time possible. So, basically, every IP in the community block list will be automatically
[07:06.640 --> 07:13.360]  dated after one week if the IP does not perform any more attack on the community. And for
[07:13.360 --> 07:20.120]  the raw data we receive, after three months, it's degraded, and after nine months, it's
[07:20.120 --> 07:29.760]  totally dated. Now, how do we build this community block list? Because we receive reports from
[07:29.760 --> 07:34.880]  all over the community, but we cannot trust those reports because it's just an API. If
[07:34.880 --> 07:42.160]  someone wants to send us the information that ISO 1.1.1 performing SSH could force my server,
[07:42.160 --> 07:48.960]  we have no way, basically, to know if it's true or not. So, we build something called
[07:48.960 --> 07:56.040]  the consensus. So, we get the report from all over the community. And then, each user
[07:56.040 --> 08:02.880]  in the community has a trust score. So, this score is really how much we trust you. It's
[08:02.880 --> 08:08.840]  built over time. So, the longer you are part of the community, the more your score will
[08:08.840 --> 08:14.160]  increase. But it will also take into account how active you are in the community. So, if
[08:14.160 --> 08:20.680]  you report just one IP per day or someone that is reporting 100 IP per day, we will just
[08:20.680 --> 08:26.960]  give a slightly better score to the user reporting 100 IP per day. And we will also correlate
[08:26.960 --> 08:31.600]  your report with other community members. If you are the only one sending us the information
[08:31.600 --> 08:36.560]  about a particular IP, this IP will never go into the community block list because we
[08:36.560 --> 08:48.360]  cannot confirm that it is indeed an IP trying to attack servers on the internet. But if multiple
[08:48.360 --> 08:54.880]  users report this IP, then we will be more confident about the fact that this report is
[08:54.880 --> 09:03.720]  exact. We do also run some own iPods and because those are fully controlled by us, they are
[09:03.720 --> 09:11.240]  fully trusted. So, if someone tries to attack them, we know that this is an actual report.
[09:11.240 --> 09:16.000]  We do also have some white list because if someone send us IP belonging, for example,
[09:16.000 --> 09:23.240]  to a cloud flare, obviously, this is not something we want to redistribute to the community.
[09:23.240 --> 09:29.640]  And again, if you do send us too many false positive reports like this, your score will
[09:29.640 --> 09:37.720]  be reduced because we know that your report are potentially false. And lastly, we do also
[09:37.720 --> 09:43.400]  have some more advanced algorithms that, for example, we look at the bigger picture, if
[09:43.400 --> 09:51.040]  you take a slash 24 network, and like 50% of this network is already in the community
[09:51.040 --> 09:56.960]  block list, when if we see another IP belonging to this network, it's quite likely that this
[09:56.960 --> 10:03.560]  IP is also bad. Same thing, for example, if the IP reported to us exposes, like I don't
[10:03.560 --> 10:09.520]  know, a tenant server, 20 different services on the internet, again, it's more likely that
[10:09.520 --> 10:17.000]  the IP has been compromised. And so, when a report goes through everything, we will take
[10:17.000 --> 10:21.360]  a decision and it will go into what we call the fire database, so the community block
[10:21.360 --> 10:33.160]  list, and it will be pulled automatically by all the community members. Now also, for
[10:33.160 --> 10:37.960]  the usefulness of the community block list, a while back, we ran a small experiment where
[10:37.960 --> 10:43.600]  we had two different servers on the internet, on the same hosting provider, those two servers
[10:43.600 --> 10:49.440]  had the exact same set of services exposed on the internet, so to adjust a wide server
[10:49.440 --> 10:54.800]  and SSL server, the only difference between them was one was using the community block
[10:54.800 --> 11:00.840]  list, and the other one was not. On the one using the community block list, we saw around
[11:00.840 --> 11:08.280]  92% less attack on the server detected by protect. So because basically, most of the
[11:08.280 --> 11:13.640]  IP that are trying to scan your server exposed on the internet are basically trying to do
[11:13.640 --> 11:17.720]  it for all the internet, and so this is just some background noise, you don't really care
[11:17.720 --> 11:27.680]  about it, you can just block it before it can try to attack you. Another thing that we
[11:27.680 --> 11:33.440]  get asked quite often is, okay, so I want to replace my firewall with QuartSec, I want
[11:33.440 --> 11:39.360]  to replace my auditing system with QuartSec or whatever. Please don't do that. It's not
[11:39.360 --> 11:44.680]  designed to do that. We don't compete with this kind of solution, but on the contrary,
[11:44.680 --> 11:52.920]  we can help them to be more useful. So, for example, if you have an auditing system telling
[11:52.920 --> 11:58.320]  you that, okay, so I saw command execution on this server, and it was a curbside bash
[11:58.320 --> 12:04.800]  or something or whatever, but you can configure QuartSec to pass those logs, to detect this
[12:04.800 --> 12:09.160]  behavior, and just to send you a notification. It does not have to be something about an
[12:09.160 --> 12:15.600]  IP address, it can be a local behavior as well, or something with firewall. You don't
[12:15.600 --> 12:21.960]  have to go into the configuration at the IP, just add the IP in QuartSec with one simple
[12:21.960 --> 12:28.520]  command, and then QuartSec will take care of pushing this information to your firewall
[12:28.520 --> 12:39.000]  and the IP will be blocked. So, for the architecture of QuartSec, so as I mentioned before, so
[12:39.000 --> 12:46.440]  QuartSec will ingest some logs, pass them. So, this is the role of what we call the agent.
[12:46.440 --> 12:52.120]  The agent will read your logs, pass them, and confront them against scenarios. So, a
[12:52.120 --> 12:57.520]  scenario, just something that describes a malicious behavior. For example, a boot for
[12:57.520 --> 13:02.680]  someone trying to scan your website and so on. When the agent detects a malicious behavior,
[13:02.680 --> 13:08.200]  it will create an alert and will be sending this alert to another component of QuartSec,
[13:08.200 --> 13:12.600]  the local API. So, this means that the agent can live on one server, the local API can
[13:12.600 --> 13:18.760]  live on another server. The local API will take this alert and transform it into a decision.
[13:18.760 --> 13:25.120]  For example, by default, it's for our ban on the IP. But you can customize this behavior,
[13:25.120 --> 13:31.040]  and for example, you can say, so, this IP is French, it performs something related to
[13:31.040 --> 13:40.320]  an HTTP attack. So, instead of just banning it, I'm going to ask my boncer to display a
[13:40.320 --> 13:49.360]  capture for this IP for four hours, for example. So, and when the local API receives a decision,
[13:49.360 --> 13:55.400]  it will be sending us information about the alert. And in exchange, you will receive the
[13:55.400 --> 14:00.840]  community block list. The local API is also used by the boncer, so the components that do
[14:00.840 --> 14:06.360]  actually apply the decision because QuartSec by itself will just do the detection part. It will
[14:06.360 --> 14:12.400]  not block anything. For that, you need boncers. So, we have quite a few of them. The most
[14:12.400 --> 14:16.800]  popular one is probably the firewall boncer that will interact with the local firewall
[14:16.800 --> 14:21.920]  of the server where the boncer is going to block the IP. But we do also support a web
[14:21.920 --> 14:26.800]  server, for example, in GenX. And in this case, because we are at a higher level in the
[14:26.800 --> 14:38.000]  network, you can display a capture to the user instead of just grouping the request. So, here,
[14:38.000 --> 14:46.700]  it's the design that will be used in the following demo. So, a very small Kubernetes
[14:46.700 --> 14:54.600]  cluster running locally with just two nodes, one agent per node deployed as a demon set,
[14:54.600 --> 15:00.240]  one local API for the agent to be able to send the alert. The agent will be reading the logs
[15:00.240 --> 15:08.040]  of the ingress of the cluster. In this case, Angelix ingress. And we will have a boncer,
[15:08.040 --> 15:14.520]  the Angelix boncer running on the ingress to block automatically the IP if QuartSec wants
[15:14.520 --> 15:18.080]  to ban them.
[15:18.080 --> 15:27.520]  Okay, thank you. So, as we have, we are crazy guys, we're going to do a live demo. And,
[15:27.520 --> 15:40.160]  yeah, just think I have some. So, as Sebastian said, we're going to, we have a small, locally,
[15:40.160 --> 15:52.160]  of course, not online. Yes, of course, sorry. Thank you. Okay, so, what we're going to do
[15:52.160 --> 16:04.440]  is to, so, sorry for that, but I will, so this will create Kubernetes cluster with two nodes
[16:04.440 --> 16:14.120]  with ingress controller, Angelix, and a Hello World app, like it's a demo application. Nice.
[16:14.120 --> 16:26.840]  Okay. So, here we can see that. Okay. We have one ingress controller. And we have two nodes.
[16:26.840 --> 16:32.840]  Okay. So, what we'll do now, I will not spend time to explain you, like, the QuartSec values
[16:32.840 --> 16:38.160]  because we released a hand chat that will allow you to install QuartSec in a Kubernetes
[16:38.160 --> 16:44.080]  cluster. As I said, it deployed a demo set. So, in each node, it will deploy a QuartSec
[16:44.080 --> 16:51.880]  agent and one local API in a specific name space. And, of course, your decisions will
[16:51.880 --> 17:02.600]  be centralized across all your nodes. So, here, we will install QuartSec. So, basically,
[17:02.600 --> 17:09.480]  we just install QuartSec using these values. And this is the hand chat. Of course, I already
[17:09.480 --> 17:16.640]  import my repo in the namespace QuartSec and create it if it's not exist in the namespace.
[17:16.640 --> 17:33.840]  So here, if we are. Okay. Yeah. As I popped a new cluster, I have to wait for the image
[17:33.840 --> 17:44.800]  download. But it will come no more. Okay. What I can do, yeah, of course, what I can
[17:44.800 --> 17:53.200]  do is to show you that I'm able to access my Hello World app. So, it's basically an
[17:53.200 --> 18:18.480]  Hello World. So, it returns the two OO. And, okay. We have one pod that is running.
[18:18.480 --> 18:43.120]  Demo effect. As usual. Let's install. Wait. Why? Ah. Okay. So, now, yeah, we're going
[18:43.120 --> 18:54.720]  to fetch this one. So, okay. I will follow my logs from this agent. So, logs minus F.
[18:54.720 --> 19:04.760]  Agent and N. All right. So, here is my QuartSec logs. So, now, what I will do is to run Nikto,
[19:04.760 --> 19:16.760]  which is a simple, okay. A simple web scanner to attack my Hello World application. And here,
[19:16.760 --> 19:22.560]  we can see that I can even already, okay. Here, we can see that it automatically detects
[19:22.560 --> 19:27.200]  as it's automatically parsing the logs of the ingress controller. It detects some bad
[19:27.200 --> 19:32.800]  behaviors because I already installed, like, collections that are bundles of parsers and
[19:32.800 --> 19:39.080]  scenarios. And you can see that it detects bad user agent, some sensitive file access,
[19:39.080 --> 19:49.280]  patch traversal, et cetera. So, if I do something like that and get a shell on QuartSec, sorry
[19:49.280 --> 20:01.080]  for the noise, local API. And if I list the decisions that were taken, we can see that
[20:01.080 --> 20:07.760]  we have six other entries like this one because we detect several times my IP as I'm working
[20:07.760 --> 20:13.120]  locally. That's why we have those IPs. And this is the last behavior that was detected.
[20:13.120 --> 20:18.000]  So, now, what we will do is to install the bouncer because we are detecting, but we get
[20:18.000 --> 20:24.960]  still access to the application. So, now, we will patch our ingress controller to install
[20:24.960 --> 20:31.520]  the new app plugin to communicate with the local API and get banned, of course. So, now,
[20:31.520 --> 20:40.520]  here we have the command. So, we can go fast and at time. So, I'm upgrading my ingress
[20:40.520 --> 20:59.640]  controller, sorry. Okay. Okay. So, now, if we try to access now to the Hello World application,
[20:59.640 --> 21:17.080]  we can see that we will receive a 403. So, if I do this... Sorry, I didn't see that.
[21:17.080 --> 21:34.520]  Yeah, it's the... Let's wait for this and upgrade.
[21:34.520 --> 21:55.840]  Okay. Okay. Nice. So, it's popping the new ingress controller. Of course, it's local.
[21:55.840 --> 22:06.400]  That's why we have only one pod. I don't recommend that in production. So, it's deploying the
[22:06.400 --> 22:15.360]  new ingress controller and loading, of course, the crowd-seq bouncer. It's a Lua library
[22:15.360 --> 22:33.120]  that is talking with the local API. And on each request, we have this check. Come on.
[22:33.120 --> 22:50.320]  Yes, of course. I think we hand it. No. We have still time. So, we can take some questions
[22:50.320 --> 22:55.520]  and I will follow them. We've got time for like one question. So, there is one fast question
[22:55.520 --> 23:03.160]  for one minute. Feel free to answer it. Okay. Just to hand the demonstration. It's running
[23:03.160 --> 23:20.280]  and now we have a 403. So, that's it. Okay. So, thank you. Yeah. This is the challenge
[23:20.280 --> 23:25.760]  with the demonstrations. If you have some questions, don't hesitate. And of course, we have some
[23:25.760 --> 23:51.480]  stickers. So, don't hesitate to come to us.