WEBVTT 00:00.000 --> 00:12.920 Hey folks, pleasure to be here, such a great conference, among such a good community, and 00:12.920 --> 00:19.160 lots of open source folks, and among friends as well. 00:19.160 --> 00:24.200 We have talked a little bit about the required, because we have to actually highlight all 00:24.200 --> 00:29.800 the good things that we do for two years in 20 minutes, so please bear with me. 00:29.800 --> 00:36.440 My name is Peter, I'm at this gentleman here on my right, at the project called 00:36.440 --> 00:42.800 Serrikara, open source projects in Rikara six years ago, where we still actually work and 00:42.800 --> 00:45.080 collaborate and donate a lot with the community. 00:45.080 --> 00:52.240 I'm a Serrikara evangelist, I do a lot of QA and trainings for the project, and as I mentioned 00:52.240 --> 00:56.560 I found with a Rikko phone in the company called Stamocetworks. 00:56.560 --> 00:57.560 Would you like to say that? 00:57.560 --> 01:06.120 Yes, I'm very deeply French, sorry for the accent, and I'm a vestitial at Stamocetworks 01:06.120 --> 01:13.400 on the bottom of the Rikko, and from time to time I do the development on Syrikata. 01:13.400 --> 01:17.240 So for those of you that are not familiar with Syrikara, it's been around, it's widely 01:17.240 --> 01:23.080 used by a lot of different organizations, folks and community, it's a thread detection engine 01:23.160 --> 01:28.840 that actually inspects the network traffic, it can generate any and all data, relevant 01:28.840 --> 01:35.800 to forensics, malware detection, ideas alerts, the protocol logs, we did the file extraction, 01:35.800 --> 01:41.400 the PECAP, it has the whole capability, has been constantly evolving, could have passed 01:41.400 --> 01:42.400 16 years. 01:42.400 --> 01:46.400 It's a Swiss army knife for a little bit. 01:46.440 --> 01:54.080 So born in 2008, 600,000 lines of code, some of the major code creators are here in the 01:54.080 --> 01:58.720 room with us today, so super big pleasure to be here. 01:58.720 --> 02:06.080 It's written in C and Rust, it says life packets on the network, or dead ones, because 02:06.080 --> 02:09.640 we have to actually inspect the traffic regardless of whether the traffic is good enough 02:09.640 --> 02:12.240 or not good enough, or following the RFC. 02:12.480 --> 02:20.640 Basically, produces protocol transaction, ideas alerts, PECAP, and it's actually characterized 02:20.640 --> 02:29.200 with very high performance in open source driven by community, actually not by a single 02:29.200 --> 02:36.000 person or vendor, it's actually a lot of collaborative effort, and it's actually governed 02:36.000 --> 02:40.880 by the open information security foundation just to make sure that actually everything is 02:40.960 --> 02:46.400 proper to stay open source, we cannot be bought, we cannot be sold, but we're a GPL version 02:46.400 --> 02:56.000 too, but there is also a proprietary license for vendors that need so, so that also, we all want 02:56.000 --> 03:01.520 to make sure that the code is always open source and always there, but there is also ways 03:01.520 --> 03:06.000 to facilitate specific vendors if they need to. 03:06.080 --> 03:12.160 There is a lot of frequent class questions and answers on the URL there, if you need to have 03:12.160 --> 03:20.400 look. So where's Riccada is developed? Actually, I'm actually super happy because one of the 03:20.400 --> 03:25.440 guys responsible for the 46% there is sitting right in front of me, Riccada, please raise your hand 03:25.520 --> 03:37.120 up. Thank you. So here's the creator, the food, the initial quote, another person that is responsible 03:37.120 --> 03:47.360 for most of the 16% is right here, whom I write with her to run, and it's as you can see it's 03:47.360 --> 03:52.640 a lot of collaborative effort, my part of this 16 year journey has been kind of sitting in between 03:52.960 --> 03:58.960 these guys in trying to convince them directly how bad their code is, but at the end it all, 03:58.960 --> 04:07.200 it all really works and I'm evangelizing it the most I can. So, non-technical challenges for 04:07.200 --> 04:11.760 those two years of developing to Riccada is a huge variety of users, right? For me, 04:11.760 --> 04:18.560 corporations, if you actually Google AWS, if you Google or Firewall AWS, Riccada is actually 04:18.560 --> 04:24.640 the default Firewall AWS. So we have a lot of big usage, a lot of big vendors, a lot of 04:25.840 --> 04:31.600 researchers, hobbies, trailers, professors, universities, students, sandboxing, 04:32.720 --> 04:39.920 online tools like any around triage and things like that, they all use Riccada, vendors, integrators 04:39.920 --> 04:48.240 of applying. So we have a very active community, all five continents, always, they're always evolving. 04:48.240 --> 04:53.600 We need to keep all these people happy and hopefully we're doing a good job because if it's not 04:53.600 --> 04:58.480 useful, we wouldn't be here actually. So it has usage of what we do. And of course, 04:58.480 --> 05:06.160 consortium members, so we have to keep all of them engaged. Now, anything goes from a Raspberry 05:06.160 --> 05:12.720 to 400 gigabit a second installation. So we actually have to do that at speed and with huge 05:12.720 --> 05:20.240 performance and be flexible. So the input is traffic capture, RFC doesn't really matter to malware, 05:21.040 --> 05:24.880 including some commerce, also some commercial vendors as well. So we need to actually 05:24.880 --> 05:29.840 be procuring and spectrum catch all of these things, independent of threat intel ingestion, 05:29.840 --> 05:35.200 and we have to output in a default format that is easily ingestable by a lot of vendors. So, 05:35.200 --> 05:40.480 as I said, in these two years, we actually changed suggested at about the quarter of the 05:40.560 --> 05:47.680 cold, of the whole body. And a lot of docs, a lot of arrests, improvements, 05:47.680 --> 05:51.760 implementation for security and threat safety. So it was a huge effort by a lot of people on 05:51.760 --> 06:00.480 organizations, not just a couple. One of the things that was added to improved in surricata eight 06:00.480 --> 06:05.600 is like, we were using the motor if you can log it. You can use it in a row or a signature detection, 06:05.600 --> 06:10.160 let's put it. Basically creating those extra buffers, we can point to the traffic and say, 06:10.160 --> 06:16.240 hey, I want to check something in here, but in an extremely fast way. One thing that we did 06:17.360 --> 06:25.680 greatly differentiated matter was adding a 177-new keywords or buffers rather to the surricata. 06:25.680 --> 06:31.120 As you can see, all the way to the right of the screen, you have a purple line, and this is the 06:31.120 --> 06:35.760 difference for surricata eight and between all the other surricatas that are from the orange 06:35.840 --> 06:42.080 one on the low, so a huge addition in there. So a lot of new protocol came in and if you're 06:42.080 --> 06:46.400 interested to see what the new buffers are, there's about 38% of those, so it's very easy to see 06:46.400 --> 06:52.800 that on a command line with surricata dash dash list keywords. And all those buffers and 06:52.800 --> 06:57.840 detections have been added so that they can be used in the detection language in the signature 06:57.840 --> 07:04.640 writing, would addition to different protocols. On top of the regular step that surricata already 07:04.640 --> 07:09.840 does the logging and you can put in CEM and actually do the detection algorithmic there as well. 07:10.640 --> 07:16.640 Now, there were some detection limitations and the surricata team actually managed to fix 07:16.640 --> 07:21.040 those in a groundbreaking manner. First, the whole industry had a problem with that in general, 07:21.040 --> 07:28.160 the directionality of the rule. So in other words, as the example goes in here, you check 07:28.160 --> 07:33.840 based on the direction to client or to server when you actually do the detection. And it was kind of 07:34.480 --> 07:41.280 a signature, a simple signature. The basic example like this actually needed two rules to detect, 07:41.280 --> 07:45.280 you know, one to the client and then there is one to the server. So that was the limitation. 07:45.280 --> 07:51.520 So you had to be split into signatures and fourth negative, it could happen a lot. So one way that 07:51.600 --> 07:58.000 this was fixed and it was a long journey but when it came to fix it, it's actually the introduction 07:58.000 --> 08:04.320 of transaction rules. In other words, as you can see on the screen in here, you can actually say 08:04.320 --> 08:09.600 something like if there is this content and the server crushes, you know, a state is called 08:09.600 --> 08:15.600 content 500, I would like to be alerted. So that combines actually both things. So it was 08:16.400 --> 08:25.680 that's one of the other things that were in there. So now, I shouldn't really talk about that 08:25.680 --> 08:30.240 because I didn't write it. So I personally took the guide that wrote the code for it and 08:30.240 --> 08:37.040 he'll take it over here. So one thing that has been introduced by Victor, remember that we were 08:37.040 --> 08:43.120 on the beach, we discussed in that when I discovered that the feature was that asset because 08:43.120 --> 08:49.120 a lot of things that we want too much is a list. So you'll get a list of domains, but of course 08:49.120 --> 08:54.160 potentially bad, you got a list of user ads on that, or potentially bad, only want to match 08:54.160 --> 09:01.280 really fast on that. So as we concept of data set, in just a list, write one single signature 09:01.280 --> 09:08.480 on you will be able to match on this list really fast. So basically, you get the list of 09:08.800 --> 09:14.480 those names that are not correct, and you are going to write one signature on you're going to 09:14.480 --> 09:20.800 match on that. But when you do that, basically you're going to have all your bad people 09:20.800 --> 09:26.240 in the same box. You don't know why we are bad in the generated alert on that was an issue. 09:28.080 --> 09:32.880 So what has been introduced in suricata 8 is the capability to ingest 09:33.600 --> 09:40.800 gison format where we can get context on top of IUC's indicator of compromise. 09:41.520 --> 09:46.400 And we can use that in the signature on our website. So for example, here we say, 09:47.040 --> 09:54.880 if HTTP host is in the set that is coming from this IUC.nd gison, on the IUC and the gison is here, 09:54.960 --> 10:02.160 you get the IUC key on the context. And this is going to end up in the alert. 10:03.440 --> 10:09.200 IUC check one single signature on then you've got the context coming in to the event. 10:09.760 --> 10:17.840 So this arrow you to directly knows why it is bad, and why you have a problem. So it's 10:17.920 --> 10:30.160 a cat as everybody knows. That's all you name Icelandic volcano. So, so that's one of 10:30.160 --> 10:35.280 the fifth feature on the another feature that has been done is part of adding a lot of keywords. 10:35.280 --> 10:39.760 It was also full to be able to add keywords because a lot of protocol had been added. 10:40.800 --> 10:45.760 So I'm not going to cover every one of them here. One of the most important 10:45.840 --> 10:52.320 for me is LDP because it's easy to use in a top-rive in a lateral movement. When somebody is 10:52.320 --> 10:58.880 already inside, I'm trying to take control of a full information system. But you also have 10:58.880 --> 11:04.320 some of a protocol like CIP, ARP, for low level, and DNS server HTTP, it's a lot of friends 11:04.320 --> 11:15.280 from FireFox in the previous talk. And so, as mentioned by Peter, surgata, he's 11:15.280 --> 11:23.920 parsing the method. Everything goes. We need to do our best. People, for some people, it's a sport, 11:23.920 --> 11:31.920 to make us crash. So we need to be as best as we can. And the experience has make us learn that 11:33.600 --> 11:41.040 yes, we are not going to be able to get correct code on a we need help from the language that we 11:41.040 --> 11:48.000 are using. So that's why we have switched from C to Rust for the new development mostly. Let's say 11:48.000 --> 11:56.960 like that. And with a big focus on the analysis of data coming from Venezuela. So for performance 11:56.960 --> 12:04.000 inside the system, we can still see that if we want to parse a new protocol is going to be in Rust 12:04.560 --> 12:12.080 and the increase of Rust has been a huge from 2017 to 2025. We wait up to 27% for a project that is 15 years 12:12.080 --> 12:17.440 old, that's quite cool. So that's a big effort that has been done and so we've got the eight 12:17.440 --> 12:25.360 increase has been as big as the huge. And yes, and also I've worked on the lower. So the 12:25.360 --> 12:33.440 rest of the big move that has been done is the parsing of HTTP that was written in C library, but 12:33.440 --> 12:40.080 it's now built in in surricata on this done in Rust. And we also have some other interesting 12:40.080 --> 12:47.520 parsing like mine parsing is a nightmare. And it has been moved to Rust. One big problem that we 12:47.520 --> 12:54.960 add in the past is that we add lower since the beginning. It was looking like the best feature ever 12:54.960 --> 13:01.760 when we get the lower support out. So basically you have a signature on you image and then you want to 13:01.760 --> 13:06.560 say, okay, but what is going to happen if I don't have a keyword to access the protocol or 13:06.560 --> 13:12.080 a logic is really complex. And very, you can just you could just say, oh, I'm going to send 13:12.080 --> 13:18.080 the data to a lower script and because it's a language, I can write anything. So the concept is really interesting, 13:18.640 --> 13:25.440 but because when you deploy surricata, you don't know, when you write a lower role, you don't know 13:25.440 --> 13:31.120 which version of what you're going to have because it was the lower from the system that was used, 13:32.080 --> 13:37.120 you don't know what a module we're available. So everything was a problem. And also the 13:37.120 --> 13:41.360 word is a language. So if it's a language, it can do stuff. So you can must do anything. 13:42.320 --> 13:48.320 So that was another big issue. So that has been fixed in surricata 8. With some boxing 13:48.880 --> 13:56.880 to protect, uh, on a try to avoid a vision. And also by to invandored inside surricata. So we have 13:56.960 --> 14:01.760 exactly the same version for fixed version of surricata. So it's predictable for V2. 14:03.600 --> 14:05.360 For the rule of right hand, for V2, they're sorry. 14:06.800 --> 14:13.280 Whenever evolution is surricata as a library, so surricata can now be on beddy, 14:13.280 --> 14:18.080 or part of surricata can now be on beddy, in some of her software. For example, you have a 14:18.080 --> 14:25.680 HTTP proxy. And you want to add the capability to do surricata analysis on it. So that's 14:25.760 --> 14:35.680 the development that you can do now with surricata 8. Part of surricata 8. But another evolution 14:35.680 --> 14:43.040 is surricata add a lot of running mode. And the new running mode has been added, which is a fire 14:43.040 --> 14:52.800 wall mode where surricata can now pass on this side, on the packet, on the flow based on some 14:52.800 --> 15:01.040 metadata. So let's see an example. That would be a little bit better. So for example, you can say that 15:01.040 --> 15:09.680 you want to block TLS version 1. So something really low level in the protocol. And so you can do 15:09.680 --> 15:16.320 drop on the flow. So you're going to drop all the flow. When the surricata server is a negotiation 15:17.280 --> 15:23.600 started and you get the version 1 on this is going to block everything. So you can really use 15:24.480 --> 15:30.720 go deep into the understanding of a protocol to write a really advanced rule that are going to 15:30.720 --> 15:38.320 be applied. And one of the important things is that it's just not like a signature. It becomes a real 15:38.400 --> 15:46.800 rule set lacking fire wall. It's sequential. You can predict what is going to be the decision 15:46.800 --> 15:53.600 because with the traditional surricata online you can have multiple signature firing on the 15:53.600 --> 16:02.800 same packet and the logic is completely different. So big funds to the team, big funds to the community, 16:03.280 --> 16:09.360 a lot of future being contributed by external people. For example, I was talking about the conversion 16:09.360 --> 16:15.760 of the U.S.G.T.P. to rest. It has been done by our Canadian friends. We had it contributed 16:15.760 --> 16:24.240 back. So the cyber security from Canada has done the conversion and so that's the way it is possible. 16:24.240 --> 16:34.240 Funds to the community and funds to the gratitude of the U.S.F. If you have questions. 16:54.960 --> 17:07.760 Thank you. How good is surricata for processing plain HTTP comparing with specialization of 17:07.760 --> 17:13.680 application for the walls? Assuming the elasticity of the community is already. So are you suggesting 17:13.680 --> 17:19.200 to use surricata for everything or we can just use the application for the wall for HTTP? 17:19.760 --> 17:25.760 Right. And surricata for all of us. 17:28.160 --> 17:37.680 I will consider surricata as a good system to be able to go above the capacity that you could have 17:37.680 --> 17:44.400 in your application firewall. Because the signature language is kind of powerful, but if you 17:44.400 --> 17:51.840 I will say that it's not special as for what? It's not going to act as a proxy. So you will need to do 17:51.840 --> 17:58.240 a specific development for what? Yeah, it needs to be considered. But to be fully honest, 17:58.240 --> 18:02.960 I will not just go straight on that. I will try to see if I it will emit of my actual system before 18:02.960 --> 18:09.120 going for what? But look at the capability of surricata signature but can be interesting. 18:09.920 --> 18:16.560 But it would not be my first step. Okay, thank you. Sorry, if I made a one more question. 18:16.560 --> 18:24.960 I regard in there, may please clarify the rules ordering possible for surricata. 18:24.960 --> 18:32.960 Can you package it and make it a play specific order? Yeah, so in this failure world mode, 18:32.960 --> 18:41.280 you can have ordering of the rules that is taken into account. But in the regular ideas or 18:41.280 --> 18:48.400 IPS mode is not the case. Because we are super 90 million packet per second, 70,000 rules. 18:48.400 --> 18:52.320 If we go second, sure. Yeah, we're not going to do it. So we've got optimization. 18:55.360 --> 18:56.560 Do we have any other questions? 18:57.520 --> 19:10.160 When we are talking about performance, let's say, what are the capacity of our CPU that you need? 19:10.160 --> 19:15.520 Let's say for one gig of it traffic. I know it's a very general question, but can you give us 19:15.520 --> 19:23.120 a general estimation of capacity in scaling of traffic? For your willing, you mean? 19:24.080 --> 19:33.840 Yeah, so for ideas, Raspberry Pi is enough for one gig. For IPS on a failure world, 19:33.840 --> 19:39.360 I don't have a number. I think we need to, it's a bit fresh when you're sorry for that, but we need to 19:39.360 --> 19:43.920 do some evaluation. Any other questions? 19:46.240 --> 19:52.000 I just want to mention one more thing, I'm not right to the question, but in general, because we are, 19:52.000 --> 19:54.400 if there are no more questions, we could, in general, because we are an open source. 19:56.320 --> 20:02.080 Community, we usually listen to everything that the community has to say, 20:02.080 --> 20:06.880 and super thankful that we can actually be here, folks. We also have something called Suricon, 20:06.880 --> 20:11.200 where we gather all the inputs from the security, from the security, for the community. 20:11.200 --> 20:17.760 And all that, so model welcome for any feedback is appreciated. But one person that actually consistently 20:17.840 --> 20:25.200 makes that, and also make sure that a bunch of gigs can run coherently, is our president, 20:25.200 --> 20:28.720 of the open information skills foundation, Kelly Misatluciting, right here. 20:28.720 --> 20:33.440 Big thank you to her as well. So please make sure you bring your app as well, something is there. 20:39.760 --> 20:43.040 Okay, well, very much for, thank you for that talk.