 Tom here from LearnSystems and we're going to talk about running Sericata on PF Sense. Now, Sericata is an intrusion detection and intrusion prevention system. It is not the end-all to all of your security woes, it is not a security blanket you should just wrap around you because it's a little bit more complicated than that and it's also not a set it and forget it. So I'm going to talk about what is effective about Sericata, what is ineffective about Sericata and I'm not going to have the debate on here but I will leave you some forum links where you can go and debate about the Sericata versus Snort. I've preferred Sericata, I found it worked very well for all the use cases, I haven't very familiar with it. If you would prefer to run Snort, feel free to run Snort. This video doesn't completely apply to Snort, we're going to do everything in Sericata and as I said, look in the description below for some links where you can carry on the debate of which one you think is better with several other people who want to debate that. For now, I'm sticking with Sericata. Before we dive into this tutorial, let's first. If you'd like to learn more about me and my company, head over to laurancesystems.com. If you'd like to hire a short project, there's a hires button right at the top. If you'd like to help keep this channel sponsor free and thank you to everyone who already has, there is a join button here for YouTube and a Patreon page. Your support is greatly appreciated. If you're looking for deals or discounts on products and services we offer on this channel, check out the affiliate links down below. They're in the description of all of our videos, including a link to our shirt store. We have a wide variety of shirts that we sell and new designs come out well randomly, so check back frequently. And finally our forums, forums.laurancesystems.com is where you can have a more in-depth discussion about this video and other tech topics you've seen on this channel. Now back to our content and we'll begin right here. Sericata is a free and open source, mature, fast, robust network threat detection engine. That means it can look at the traffic coming in and detect threats and a lot of people start assuming, oh, this is what I need to help secure my network. Well, it can only detect threats and IDS versus IPS is intrusion detection system versus intrusion prevention system. And the really the difference is a checkbox whether or not you want to block the threats it determines. And before you're wondering why you shouldn't just block everything that it detects, well, false positives. False positives are what we're going to talk about. We're going to talk about how to tune the rules on this and how to set it up. But be aware that this is not a one and done type of process. Occasionally I have to go back and find the things that got blocked accidentally. This is just part of doing intrusion detection. And a lot of the reason for this is because the tools are becoming more and more blind to the traffic. As traffic becomes more encrypted, there's less information for it to use to figure out exactly what that traffic is. So this is where false positives come in quite a bit. So an encrypted piece of traffic happens to match the pattern of something and they do their best not to have false positives. But we have run into this ourselves. We've had things that are custom like some of the remote support tools we use that are running on a non standard port and Siracada will flag it and block it going, I think that is this attack. And right away, I can rule those out going, well, I'm not even running that software on here. And we also figure out ways we can repeat it by going, well, it looks like every time we open up this remote support tool into a file transfer inside of it, Siracada flags it and says, hey, I think this is a this type of attack, which then you have to tune the rules. And that's we're going to cover how to set it up and how to get these rules tuned. But I just want to preface all this before you go any further. This is not a check the box and it just works and makes your network more secure. Now the other side of Siracada where it's much more effective and what versus less effective is going to be if you have services you're running, and you have ports open. So I'm running a web server, for example, or I'm running a WordPress site and I want to put my firewall with some Siracada rules in front of it. Siracada is quite good at detecting some of the inbound potential problems that are coming in and pattern matching those because you have parts open. If you're just a home user, they limited amount of success you're going to have is because a lot of these devices on your network like your IoT network, they reach out through whichever protocols to get their data they need from whatever cloud servers they want to talk to. That's not something that provided unless it was not encrypted. It's not something Siracada is going to have an easy time deciphering what it is. And you'll probably just get a bunch of false positives and spend a lot of time doing it. Either way, I think it's fun and it's a great learning process to do that. But like I said, I just want to preface this video with those caveats because that's something I did not do very well in my last video. And it is probably the number one question that people contact us about is, can I just set these and it fixes all these problems and makes my IoT safer? No, not really. But I do have an active network and we're going to show what false positives show up on a default install. So let's get started on that. We're going to go over here to my lab and install the plugin first. So we go over here to package manager, available packages, Siracada, install, confirm. So after this is installed, we're going to go through how to set up the rules. This is the important part for the rule setup is getting the downloads proper because the defaults right now, and I don't know if this was true back when I did the other video, but right now the default downloads don't work. So we'll go in here, and we're going to go over to updates. And right here, we have nothing in here yet. And what these are is the rules and signatures. And you can get a snort key if you want, I'm not going to do that for this particular video, we're just going to use the et open rules. So we have the et open rules. This is the snort free register. If you want to store those, we're going to do these ones here. Anyway, I guess we can hide the deprecated rules if we're not using any of those. But we do need a custom URL. Now here is the emerging threat free rule set that you can get. And the good news is as of right now here in August of 2020, this rule set works fine because it's the 5.0 rules. Sericata inside of PF Sense is running version five. So we're just going to copy this link, go over to our lab, paste in the custom download URL. Now in the future of using a different version, you want to match the version of Sericata with the version that you're doing here. So because we're using the five series, I put the 5.0 in here, if you were running some old version, you kind of get the idea from here that you can switch versions. That's important that you put that in there, because the default one that tries to download doesn't work. So we'll throw in that custom URL, go down here and hit save. Now down here at the bottom, I'll mention this is the blocking. It is up to you when it blocks something if you choose to turn on the blocking, not just monitoring, how long before those expire. One hour is not a bad idea. If you say never, you'll end up with things in the block list and you may have sites that get blocked, you may end up having them blocked permanently. We'll cover how things get blocked and how you can eliminate things in the block list, but it's at least let them expire. If you don't let them expire, sometimes I find at least troubles. So that's kind of just some housekeeping cleanup. If you wanted to say four days, that way if someone scans you, trips the trigger that would cause a block, that person then for some amount of time would not be able to do it again. It's usually a bot anyways, but you'll end up with a lot of these and it'll fill that up pretty quickly of all the blocks it starts putting in there just depending on how involved you get with the rule sets. So you want to go ahead and just set it to one hour. All right, now let's go over here to update. Let's update the rules. And this is pretty quick task goes down, grabs those rules that we put on there. If you had those snort subscriber rules, which it's something you can sign up for, you'll get those. So now we have the signature to hash and cool. Here's the rules updated and in there. Now, when you're doing these rule updates as well, it's got a timer so you can set how frequently you want these rules to update. I would say once a day is probably fine on here. That's under the rule setting. So we have that the rule saying for one day and maybe set this to one hour. So we'll just leave it like that. All right, next we have to set up the interfaces. So we'll go over here, interfaces, and we're going to add our first interface defaults to WAN. If you want to put this on the WAN, you're going to get a lot of noise. And by default PF sense out of the box is going to block all incoming ports. So if you put this on WAN, all the ports are blocked, but it's still going to sense all the noise of all the things that hit those block ports. So it's up to you if you want to put it on there. It's going to definitely take up some CPU cycles. It's definitely going to create some false positives because it's just well, not really relevant because someone scanning a port that's not even open makes for a lot of logs, but doesn't necessarily make for much actionable intelligence other than some people panic and go, wow, there's this much going on on the internet. Yes, there is. So we're going to put it on the LAN side. Now for each interface, you want to create a different rule category or maybe you don't. This is up to you. And my example here, LAN would be just normal LAN traffic and maybe we want all the rules applied to that. But let's say our guest network, we don't necessarily need blocking turned on for our guest network, but we're maybe curious about what things are going on in that network. So a guest network, maybe you turn all the rules on, but don't turn on any blocking. Now these are different things you may want to do on a per interface basis. But once you configure an interface, you can also clone those rules on there. We're going to cover both how that works. So it's kind of up to you on how you want to do that if you want to just enable all the rules for every interface or maybe have a less restrictive policy on your LAN and a more restrictive policy on maybe a specific secure network for your servers. Like I said, there's a couple different options. For this demo, we're just going to enable all the rules to make it quick and easy. So LAN, LAN, send alerts to the system log. Not necessary, but you can do that. Enable stats collection. You don't get any pretty graphs for the stats collection. It just logs some of the statistics and puts them into a log file in case those are interesting to you. You can have those. Enable TLS log. Now remember intrusion detection systems like Sericata are blind to the majority of the traffic that's encrypted, but it can at least log that a TLS connection was made. Maybe you need that, maybe you don't. It is also blind to files that were transported via encrypted TLS connections, but if they are not transported that way, you can enable file store. Make sure you have a PFSend system within space if this is something you'd like to do. And the same thing with packet logging. You can do full pcaps on these, but you have to have somewhere to put them. So make sure there's plenty of space if you choose to do that. Eve JSON log. Sericata will output selected logs in JSON format. And actually this opens up quite a few options, including sending them to assist log server, a reddit server. This is a methodology so you can export all the logs to something else for log parsing and further analysis. Maybe a different SIM stack that you have like a security system that does some analysis and all the generated data. That's what that options for. We're not going to be using Kills Autoscope of this. This, I do not recommend checking when you are first setting this up. Because when this box does it starts blocking the things it finds. You first set this up, I recommend leaving this off and going back and turning it on. And when we show you how you tune the rules, you go through the tuning for at least maybe a week of usage. Tune the rules. If not, you'll end up being blocked constantly and then forcing yourself to tune the rules. A less pleasant experience, but it's up to you the method you want to follow. For me leaving this offered first week, you set up Sericata while you enhance all the rules. Probably makes the most sense. We'll leave all of these at default. There's some edge cases and I believe I've talked about on my Sericata Transparent Firewall video. You can find it on here for Sericata Transparent PF Sense. It's really cool. It works. There are some special tuning parameters from those. But for the rest of it, no, we're just going to leave everything else at default and hit save. So we create the interface on here. Categories. I was going to select all. Now, based on the global settings and what rules you pulled in there, which we did the emerging threat rules and the start GPL rules. You can go further and get the paid start rules if you want. And it will make more rules that show up here. And I checked the box on all of them. But warning by doing this, I now have the most potential for false positives. So what happens is the more rules that you check, you have to think about the rules that really matter to you. And this is when you're thinking back, like I said about which rules apply to which interfaces, selecting all on all interfaces creates the most amount of work for you to do the rule tuning. But doing it on a per interface basis for like I said, if you had a server network, you go this is one I want really watched further and better versus my guest network, which I don't need that many rules. But like I said, these are some of the fine tuning that you can get in there. So we're going to hit save on this. Then we have our land rules over here. And these are just the details of those rules. So let me find one like that's got probably a lot, maybe the DNS rules, bot rules, active X rules, a lot of quite a few active X ones that tries to look for here. And what these are is the individuals. So you have the categories on the other page. These are a breakdown of all the details in those categories. So this is going to be what's enabled and what's disabled. And they have some notes inside of here, possible black ice printer device resource toolkit. But some of the reasons these are disabled by default, even though we checked them, you see those red Xs, that's because of the number of false positives they have. So they know that rule exists, but they also don't enable it by default. And it is up to you if you want to decide which rules to or not to tune on there. So that's pretty much it. And we go back over here to interfaces. And if we wanted to duplicate this same rule set to another interface, once you have it set up and we're ready to go, you can just go to this little clone button here or add so I can add another interface and go through to setup again. But once you have maybe you spent some time tuning one of those interfaces, you can also just clone and choose land to and already has selected for me all the same rules. So that's the way you can easily, especially if you have like five different interfaces, spend time tuning one of them, get it all set up how you want and go ahead and clone that once it's all tuned. Now once that part's done, we're not going to save the second interface, you just click on the little start and it starts sericata on this interface. Now we're going to get over to the fun part, the rule tuning. Now one thing of note, and I just loaded sericata is I don't usually run it at home. And I just loaded it up on my system this morning in the lieu of this demo. And so I turned it on about looks like about 830 in the morning. So these little marks right here are when it started, you can see how little firewall uses there was and how much more. Now this is SG 3100 neck eight device. This is kind of the minimum I'd recommend that you have in order to run sericata. Now it is working fine at my house and it's able to handle this without much of a problem. But I just have a handful of devices and the kids are probably watching Netflix right now and playing some video games. It's something that you have to think about when it comes to scaling in here is yes, it can handle it on like an SG 3100 neck eight device. But if you really start turning a lot of rules on and use it over time and there's a lot of connections on your network, you may want to think of upping that a little bit. But you can see it does come at a cost of CPU cycles right away. Now I'm going to be redacting a lot of this because there's going to be so many IP address in here. So that's why those are blurred out. So what we have here is the WAN network. And this is why I said where you get a whole lot of things on here. Now I happen to be doing some torrenting, you know, seeding some isos for open source downloads and things like that. So we definitely see a lot of that inside of here. So you know, you get the stun protocol that is actually not for torrenting that is from let me look sink things server that I have running behind there. It's actually uses the natural reversal was stunned to contact out. So once again, we have an info session. And do I care about this? Do I know it's a false positive yet? Because I looked up what it was. So how do we get rid of that rule and how do we get rid of the annoyance of it being on there? Now by the way, I'm going to switch over real quick to the land side. We're going to see those same coming up again. So from and I know I'm blurring the IP addresses so you can't see this. When you do it from the land side, I get the internal IP address. When I did it from the WAN side, all I get is the WAN IP address and where its destination to its other public IP, making it a little bit less useful. When I look at this rule, though from the land side, it's easy for me to identify because I know what that particular IP address internally runs. So I can go, oh, I know that's running syncing. I know that server it's reaching out to is the syncing stun server for natural reversal. So I know it's good and I know internally. But by having that on there, on the land on the land side, like I said, much more effective you have it on the WAN side, all I know is the public IP address, which I already knew it's my WAN address and the other public IP address where it's going to, but that's not telling me what server behind my firewall did it. That's one of the other reasons that's important to have this on the land at the WAN. But now we can talk about getting rid of this rule. And we've done no tuning on the rules. I just turned them all on select all said yes. So we're going to go over here. And we'll get rid of this rule right here. We just click it. It spins for a second. All right. The state of rule has been modified Sericata live reloading with new rules was please wait 15 seconds for the process to complete before toggling additional rules. This is important. And how long it takes really depends on how fast the system is. For each rule you disable, you need to give the system time to reload the rule set before you start doing more of them where you can have the system. Well, I think I've seen Sericata crash if you try to do it real fast or just get stuck and not properly reload rule sets. So give it a second for each when you disable depending on the speed of the machine. Not a big deal. So now you see all these are yellow. What that means is they're not going to show up again, but they're now in the log history that they were there. So this is on the land side. Let's switch over to when they're not yellow. And the reason they're not yellow here is because all the rule tuning is on a per interface. This is why one of the advantages if you take the time to tune one interface and then clone it, all those rule changes you made and all those suppressions you did will follow that interface clone. If not, if I want to if I have the same problem repeating on multiple interfaces, well, I'm going to need to go through here and tune it on each and do interface and keep going through and keep going through. Also, this is one of the reasons I mentioned blocking can be really bad because if I had blocking turned on and these things have a method by which they want to say block and it's part of the rule set. So some rules are just notices, but some rules are like, all right, this is something bad and we're going to block this IP address. Well, when you start blocking everything, now you have the problem of sorting out what broke why certain things don't work. And especially if they're in a shared hosting provider where something else may reside, that's where those false positives and can really create a headache and a blocking. So tune the rules first. Now other things that are maybe less obvious. Let's go back over to the land side again. And by the way, this auto refresh is while you're watching this. So the default is auto refresh on as you change it to like 500 to show me 500 of the logs here when it goes. So it's always got plenty of information in here. So let's see what else do we have gplp to be bit torn transfer. Well, I know that is definitely what's going on there. So we're going to head and clear that one. All right, now that rules cleared. What other rules mean to clear? So sericata stream invalid timestamp. Now these can be tricky. It's more of an annoyance and right click copy or paste into Google or if you're using so you can do it like this in Chrome, search Google for sericata packet timestamp. And look, we land right here on the netgate forum. We're apparently and I've already seen this one enough that I know what it is. There's a problem with certain stream errors based on certain interfaces having this issue. Now this is where you're going to spend a lot of time and you're going to get an idea of what they actually do with these network operation centers and why when you buy a commercial firewall, this is a paid service to have intrusion detection and intrusion prevention properly working and set up. There is a team of engineers that spend a lot of time looking at all these errors, figuring out whether or not they're false positives and sending that data back and forth down the pipe. This is essentially what they do with a network engineering center, security operation center. You're going to find them going through looking at all these determining whether it's a real threat or just another piece of noise in the system and deciding whether or not that needs to be stopped and flagged as get rid of that rule. This is why it's not a set it and forget it type system. It is very important to understand that's what these engineers do. That's what you're paying for when you buy a firewall with a subscription service to an intrusion prevention system on it. And you're getting a more honed fee that they're looking at these and going through it and going, all right, we see this rule. We see this many people doing it. We realize they will dive deeper, maybe doing a P cap on it and go, all right, that is definitely not bad traffic. So just some notes on when you're looking at these. You do have to spend some time going back and forth to do this and going through figuring out which ones are real, which ones are not. So there's actually quite a few of them in here for this invalid act. So let's go ahead and suppress that one. I don't need it. All right. So here we're going to jump over to another system I have running Sericata, which is our system here. And because we host some web servers, we get some interesting things because, well, people like to bang away at them and try to figure out how they can get in, which does get a lot of these people blocked all the time. So this is specifically a network dedicated to where my servers are that run things like host my web services that we have public facing. And it's interesting to see just how many scans and we do block the people who scan us. So you scan us a few times, you're done, you're blocked for a long period of time. Then we have the poor intelligence, poor IP reputations. Those are in here as well. Specific attempt, someone tried to attempt and these are all those essentially false positives in some way. They tried something that doesn't exist. So this is web specific apps attempted Symantec secure web gateway RCE. This is what gets really interesting is that this is a remote code execution against the Symantec secure web gateway. And this is what you'll end up seeing a lot of if you have ports open, where Syracata has an incoming piece of noise that it detects going, all right, someone tried we recognize this attack pattern. This is a Symantec gateway endpoint exploit, you know, remote code execution that they tried against this, but failed because one, I don't have one, but Syracata blocked them anyways. Because if they're going to try that, they're going to try other things. These are botnet just hammering away. So this is where Syracata to me is a little bit, well, I should say a lot more effective, because it's blocking these constantly and looking for these type of threats. Now, even though these don't apply to me, what if something did, what if there was some flaw an Apache server, and I'm running an Apache server or an engine X server, and I'm running an engine X server in it detects that attack. This is where Syracata can be very effective. And to me much more valuable than trying to monitor IoT devices at my house or, you know, dealing with false information that it gives about the syncing tool that I have running going, oh, look, we found this or found that because one, eventually, there wasn't too many in there since running it this morning at my house. It wasn't too many false positives on there, but they do happen from time to time. But when it comes to running it on my server side network, that's where we have the most luck with it, I should say, or the most effective use of it because it goes through, it sees things that are potential attacks. And if it bought or an IP address is attacking you, you know, once, then it's probably attacking you in other ways. If it finds it, even though there's no response as in the RCE against the semantic gateways that I'll have when it goes, what else is on there it answered? So let me try again. Well, by Syracata blocking it, it blocks any further answers because that IP address just ends up in a block list on here and keeps them from scanning further. So this is where I think it's a lot better. But like I said, it's only limited because it still can't see into encrypted traffic. It just has to match these and we're still dealing with false positives on tools we use. So it's something we have to kind of be, you know, actively monitoring. Now the last thing I'll show you is the block list themselves. So that checkbox I mentioned where it turns on blocking, you can turn on blocking and you can go through and get rid of blocks if you want, because if they're false, just get rid of them here. If not, maybe you want to leave them here. And then as I'd say to earlier in a setup, for the default amount of time, you want to have those blocks on there. That's kind of an up to you. So maybe you want those blocks to last essentially forever, not forever. That is a up to you tuning portion of this to figure out how long you want to keep those things blocked for. But fair warning, sometimes due to shared hosting services, you may find something that gets blocked even by false, but then all of a sudden everything can't get to it. Now, the way it blocks inside a PF sense, if this IP address gets blocked, even though it was blocked on a separate network, such as my server network, it is blocked universally across all of them. So blocks will not just block the network that was attacked, it'll block all the networks on the way on because it adds a block rule in the system for that. So hopefully this is helpful for getting this set up and figuring Sericata. I just wanted to be clear, as I was in the beginning, it's not a set it and forget it. It does offer quite a bit benefit for things incoming. And if you have ports open and services running to examining those and maybe not guaranteed, anything is well, especially in security, not guaranteed at all. If there's a rule that does match a known attack, by the way, known attack is very important. These rule sets are always being updated depending on your update interval, you know, if you update it daily, I'm not sure just how often, but you know, as these rules come out, they're adding and adding cumulative adding more rules over time and they're always reactive. They have to know security researchers have to know about the threat, create a rule set for it that matches the pattern, push that rule out. Hopefully it doesn't match when it first comes out a bunch of false positives. So this is the tediousness of doing it. But this is also what network operation engineers and security operation centers, this is what they do is go through this and this is what those descriptions are for when you have a paid subscription on a firewall, which can be tedious. But hey, it's also a lot of fun and it's a great way to dive into network security engineering and learn about tuning Seracada. All right, thanks.