 Time here from Orange Systems and I'm going to cover how to set up the intrusion detection system Snort on PF Sense. But this tutorial also applies to Saracada as well because they work mostly the same. And if you want to know the differences that's out of scope of this video, but I'll leave an article down below that dives into the details of what makes one different than the other. But as I said, they're mostly the same. Now, once we go through the setup, which is the easy part, I'll be covering how to tune the rules, what the CPU demand is in different situations, and just how effective Snort or Saracada is here in 2023. So let's get started. Now the first step is going to the package manager and making sure Snort is installed and is the latest version. So we have it right here. Now we're going to go up here. Now that's installed and go to services and then Snort. If for some reason Snort's not installed, you'll just install it under the available packages. From there, we're going to go to global settings. This is where you can decide which rule set you want. You can get a free account and get your own code and get the free rules or the more up to date paid rules. This just takes you to their site and explains the different tiers of rules and how much they cost. If you want to buy them, they are all provided by Talos security, the people who also maintain Snort under here, we can click to download the free GPL rules. And then we can click to download the emerging threat rules. And we can keep going down and click these here. This is the open app ID detector. And this package contains application signatures required for app ID preprocessor. Click here to enable download of the tracker botnet rules. And then we'll say let's update every 12 hours. It has an update start time. And you can pick which time that works for you. Or if you have a specific time that you would prefer it to run, you just change it right here. We're going to hide the deprecator rule categories because why show them? And then we're going to set the remove blocked host interval to one hour as opposed to never. If you leave it at never any IP that attacks you when you put this in blocking mode will forever be on that list. And that IP may get recycled and may be important. And then chasing that down later can be a problem. Maybe your tolerance says a day is good, or maybe it's seven days. Generally, I find because you may end up with some false positives start out at one hour because you may accidentally be remotely locking yourself out of a system sometimes and just waiting an hour to get back into it. I would also recommend this to make sure you removed any blocked host after you remove snort. If there was some reason you do it, keep snort settings after deinstall. I generally recommend leaving that checked. And then start up shutdown logging. Click to output detailed messages to the system when snort logs and starting and stopping default is not checked. But if you check that, this is good for troubleshooting. Not necessarily something you need if you're very experienced and not worried about it, but troubleshooting if you're a first timer, definitely a good idea. We're going to go ahead and hit save. Then we're going to go ahead and click update, and then you will update the rules. We can see down here it says result success and we have all the rules updated. I want to switch over to another system where I do have these snort subscriber rules set up about a production system, because I want to get a lot more data for you and show you all the rules on these interfaces, not just the rules that were for the non-subscriber. For example, if we look here at an interface and we look at the categories, these ones in the middle where the snort text rules and snort subscriber rules are right here down the middle. So you can see there's quite a few more. These won't appear unless you have that snort oink master code in there to download the rules. Now let's go back over to the snort interface and create our first interface. Please note, I have created one for the different networks that I have in here, but you do not want to create one for the WAN. The reason for that is really simple. Snort or Sericata will both listen to a WAN interface and all the noise that comes at it. It works at a level different than the firewall rules. So while you will see a massive amount of traffic hitting, you will also see a CPU spike, and you'll be kind of confused because you're like, wow, look at all the things attacking me. Is the internet after me? And I've seen people get a little paranoid. Honestly, that's just background noise on the internet. There's always something scanning, something poking and looking for an open port. Those parts are not open, so you don't actually have any traffic coming through unless you chose to open them. So you're just listening to a lot of noise, wasting a lot of CPU cycles, but it could be an interesting science experiment to see just how much noise is coming at you on the WAN. Ideally, you're going to be using this for your internal LAN interfaces. Now, you may have noticed that I have a PIA VPN in here. We'll talk about that in a moment, but yes, if you've followed my tutorials on setting up a privacy VPN and would like to add it as an interface, then you can also choose it from the interfaces that show up inside of Snort and Sericata. Now we're going to go ahead and hit add here, and we're going to choose my demo lab, and we're just going to call the description here demo. Really straightforward because we're not going to do anything with this right now. And we're not turning on blocking not for the beginning, especially in the tuning phase as we'll call it. If you turn on block offenders, it will do just like it says block anyone who flags a rule. That can be bad until you've tuned the rule. So I don't recommend turning it on the rest of the things we're just going to leave at the default. So hit save, we'll go to the interfaces and the interface has been created, but it has not been turned on. So we're going to head and start that interface. All right, now that the interface has been started, we can see the green checkboxes and it's working. But we haven't done anything for any rules on this interface. Now you can stop the interface to add the rules, but we're not going to gonna show you why we're going to hear to the demo categories and we're just going to go ahead and select all. Now select all is going to choose the rules here at the top, the tail of certified rules I have in the system, the C2 IP rules, but it's not going to select these middle ones. These are those extra enhanced rules. We can choose these and maybe we want to put some of these Chrome rules, browser for IE rules, because someone's probably still using that on my network, or hopefully not. Browser WebKit rules, BrowserKit SO, and so on and so forth, maybe some office rules. These are all different rules. And the more you check, the more demand is going to be put on the system in order to do this. When we click save, it's going to reload the rules. You've got to notice here, Snort live reloading the new rule set. So if we look over here at the interfaces that should stay green, but in the background, Snort is reloading. This is what happens every time you rule is updated or changed. Now let's go over to alerts. And we're going to switch to the demo lab and we see we have no alerts. So let's put a little bit of noise. I'm going to trigger a few of the rules so you can see what happens when these rules get triggered. Now this is a Cisco switch I've reviewed before. And the reason I'm using the Cisco switches because for whatever reason, it triggers a lot of the rules in a very immediate way inside of Snort. Now the reason it does this is because first it's HTTP, not HTTPS. It actually works both, but I purposely am using it on HTTP. And I'm coming from one side of my network going through my PF sense to another network, specifically my demo network that I've got set up. And when I log in here, this is where the rules are going to get triggered. I'm also getting a warning here that I'm logging into something that's not secure, which of course I'm going to click OK to that's my bit warden trying to protect me. And there was a button there if I wanted to switch this to HTTPS. But now if I go through here and we'll click around a little bit, we've now generated some traffic going back and forth. And if you want to see my review on this switch, hey, that's linked down below as well. These are the Cisco small business switches. Now let's see what Snort has to say about my traffic coming from the Cisco. And here we have all these different errors. It's apparently HTTP chunk size mismatch, invalid chunk size, etc. So it's kind of repeating the same rule. This is where we can try to look up the rule, but this doesn't always work. So if we click on this, it's supposed to land us on a site, but lots of these rule documentation appear to be missing. At least I couldn't find them here. And we can try searching the rule doc because what does that mean? Well, this is where things get a little bit challenging. And the best way to figure out what any of these mean is literally to start Google searching them because each one of them does have a meaning. And it's more than likely or in this case, for quite certain, a false positive where it detects the traffic between my computer, which is on this private network. And we went through the PF sent system to get to the demo lab. And it just doesn't like something that it detected. So we're probably going to just mark this as false positive. And how would we do that? Well, we could just click this little x here, and this will force disable the rule set. And that's how we can go through and disable these rules. So they are then suppressed and don't keep coming back up. But before we do that, I'm actually going to clear the rules. And I want to show you something. So I'm back at the Cisco login page, but this time I'm at HTTPS, the self sign certificate. So it does have an error. And you notice there's not a message here to switch to the HTTPS version, which means I'll be able to log in without getting that error. Now, because this is a self sign certificate, it's going to be encrypted, even though it's self signed that is kind of a confusion point where some people may go, well, it says not secure. It's only not secure because it's self signed, but it's still encrypted, which also means snort is blind to this traffic like most traffic that passes through your firewall here in 2023. This is one of the big challenges is I can go through and click the same things, look at different accounts, go through the setup on here. And we're going to probably see absolutely nothing inside of snort because now all of that's encrypted. We are back at the PF sense, though information because it doesn't see anything going on in there to understand and inspect the traffic. Now, this doesn't mean that snort or Saracada is completely ineffective here in 2023, but it's ability to pattern matches dramatically reduced based on the abilities it has to see patterns or not see them at all. In this case, so with encrypted web traffic and with most sites and even many of the threat actors now, go ahead and set up a let's encrypt certificate and then blind any of these systems unless they have a way to unravel the certificate, which is a much more complicated topic and way out of scope of this, where you install a certificate to build a trust. So all the traffic that you have can be inspected. And that has got its own challenges and not necessarily the best ways. Well, the reasons I've preached so much on this channel about focusing on the endpoint where all the traffic may or may not be bad and being able to monitor at the endpoint level, as opposed to trying to have one central firewall that tries to inspect every little piece of traffic with a certificate to unravel it, which of course breaks further with things like properly set up TLS 1.3. But as I said, diving deep into that could go way off topic of this, I just wanted to show you that especially in this particular case of the web browser traffic snort is completely blind to those different changes. But let's get back to rule tuning. Now I've logged back into the Cisco so I could generate some more errors for this particular demo interface. And we have these potentially bad traffic with this invalid chunk size. Now if we don't know what that means, you can just highlight and drop this into your favorite search engine. That is a easy way to start your investigative process. And the first landing is a net gate forum post for how serious should I take invalid chunk size and a discussion on the topic and specifically it's in the forum category of DS IPS. Now this is the importance of context for each of these investigations for any rule that gets triggered. What has occurred is I initiated a connection over HTTP from my system to the Cisco that triggered a pattern match in snort and gave us that rule and that error being triggered. That investigation leads me to people telling me it's not a big deal. But I kind of knew it wasn't a big deal because I didn't see anything that the Cisco was doing. It just matches some pattern that does look like something bad. Now if I did not initiate a connection to my Cisco and some other random device on my network did and I get that same error, that's a different context of the investigation where I should probably take it more serious going, why do I get this error from this random device? Why is this device that I didn't tell to log into a Cisco doing it? And you have to take that for each one of these investigations. For example, if you're doing something as simple as scanning your network, this always trips up your intrusion prevention and intrusion detection systems because you're doing something that looks like what a threat actor might do and initiate a bunch of scans to try to find different stuff. That is a cause for investigation if you didn't do the initiation of that. This is where it could be very helpful because it may block some of that because you don't necessarily want to suppress those rules. But this is why it's not a set it and forget it type of solution where each thing needs context and needs to be searched and tuned as things go. So let's dive into actually how to suppress the rules now. The rule suppression itself is really simple. We simply click on the little red X and that will disable the rule. And when it does so there's a pause and it's actually going to reload in the background. It says the state has been modified snort is live reloading new rule list. Please wait at least 15 seconds for the process to complete. I want to switch here to show what happens behind the scenes when you do a rule reload. So you see snort here using just about 100% processor but you'll also see there's several instances of snort. Snort itself isn't multi-threaded but it does spawn a process per interface and the rule suppression is done on a per interface basis. So we've only suppressed a rule for that interface so the reload only had to happen on that interface. It is important though that you wait that 15 or more seconds going to be processor dependent and how many rules that you have in there because if you were to try to suppress rules before the live reload was done you will get them in a queue and it may or may not actually reload them the second time. So that's one of the reasons there's that wait time in there because if you try to do a whole lot of them at once without waiting you could possibly get snort to crash or simply not properly load the rules and kind of cause a problem which would force you to stop and restart snort to get it working again. Now if we needed to unsuppress this rule we could simply click it again but you notice that clicking it once suppressed all instances of that rule for this particular interface and we can go on and select other ones. Now there is a filter option so we may want to filter for something specific that we see in here obviously this is a lot of the same repeating rules but let's switch to another interface such as NSFW LAN and we see destination IP for Google's IP address. I wonder how many other things had that destination IP that also triggered so we could put this as a destination address hit filter okay we only have the one in here and we'll filter back to get everything on here. Maybe we only want to talk about when the destination port was 443 so we could just take that destination port 443 and filter that and find any particular rule that matched these patterns. It also lets us filter by GID SID so if we put one and then the 2046071 here and hit filter it'll filter for just that and we can then if we want suppress just that one there and this is just an observed Google DNS over HTTPS domain rule so it just sees the call to Google over 443 but that does not mean it's seen the traffic within there. So even though this is an encrypted request it knows that it happened because it's basing it on the destination IP and the destination port so it's determining the type of traffic and this is an instance even with the traffic being encrypted it's a pattern match. The pattern is port 443 going to Google's DNS IP address so the list of IP addresses that are within the rules and it says that one belongs to Google that's one of their DNS servers and if it's going over 443 it must be HTTPS over DNS so it's just the encrypted DNS they can't see the traffic they don't know what traffic passed they just know traffic started and landed on those ports so this is an instance where it is useful to give you that extra insight and piece of information. Now let's start with processor usage and how to determine or how tricky it can be to determine how much processor it takes to run Snort or Sericata. This is an Intel seller on J4125 I chose this particular system to the demo on because it scores a whopping 2,974 here on the pass mark this is a really slow CPU there's no other way to cut it even though it does have a turbo speed of 2.7 gigahertz this is where people go well how do you even run Snort on this how is this even possible can it even route gigabit and the first answer is yes it can route gigabit second answer is yes it can route gigabit even with Snort so let's actually run that test and we'll start walking you through the process of how Snort interacts with all of this pattern matching now what you're seeing in the background here is PF Sense running in the top window the Debian demo on our demo network which we added that interface to in Snort and then this is on my network and this also has and Snort running so I'm actually going to get two Snorts running here one in my interface one on that interface so you're going to watch both of them here when we do an iPerf test and we broke it into 50 streams because it has to look through each of these streams not just hosts but all the different connections and try and match these patterns so we see Snort going up here to 80% on each of the interfaces but we're still getting full gigabit speed now I don't even have a gigabit connection here at my studio where I could do the testing for external so I'm just doing an internal one between two devices but you see with Snort on it has not affected my speed at all I'm still getting the same speed if Snort was off it is of course using a high percentage on there but you'll actually see things like Entop are using quite a bit of percentage as well of CPU time so it won't restrict you to one gig at this many streams so we actually got to ramp this up a little bit to try to see if we can get more hosts on here to try and overload this system a quick and easy way to do this is going to be well with this open VPN connection there's a reason I had it on there I mentioned earlier and that is because I use this privacy VPN to seed Linux ISOs and things like that and we've got about 12 posts on here but we're going to go ahead and fire this up and raise the bar quite a bit so there's a lot more than 12 posts because I just turned on all the seeding and well instantly we had 105 connected this will ramp up a little bit over time but let's watch what happens inside of PF Sense as this ramps up so we actually see Entop because now that's refreshing on another page really pulling a lot of CPU out of this and by the way this is also running over open VPN so open VPN is going to pull a lot of CPU because it's got to keep and maintain all those extra connections and still the system is just not under that much load we've seen the load go up here but it's still completely usable matter of fact while it's doing that and while it's being pressured let's do another iPerf test that can run simultaneously and load up the system even more and like I said this is that tiny little celeron processor and well I'm still getting gigabit across my internal network while I'm also ramped up connections and we've seen the system load go up here but it's not detrimental matter of fact we're now up to 619 uh 632 so the connection just keeps going up actually and active flows are 840 so all the flow data going back and forth that it's got a pattern match it's still not even stressing this tiny little processor it's still working perfectly fine all my linux isos are seeding perfectly fine and we're going to go back over here to pf sense and yeah we're still not reaching a load that would be detrimental to the system matter of fact let's actually go into pf sense and look at all the rules that are being triggered right now if we go here to alerts and we switch it over to PA VPN yeah of course look at all the torrent errors that we have in here because when you're seeding isos lots of torrents that's going to be something that's going to get flagged so you see all these different ip addresses all these connections it's tracing and it just doesn't take that much to run a few final notes when it comes to processors faster the course is always better but for example we have a neck eight 8200 at my office and several thousand connections not because we have thousands of employees but because we self host several applications and a neck eight 8200 has no problem running the intrusion detection system and I've got it tuned for a minimal amount of false positives especially on these self hosted systems we do so I can monitor all those different connections we host a tool called screen connect which is a remote access tool that connects to all of our clients so it's sending a pulse out and then we have the unified controller at the office which also has connections to right now about 80 different clients that all come in through that connection and it's all being monitored at the office through the intrusion detection system now this 8200 is not taxed it's not running hot it's not even really seeing much of a load on it with those connections the torrent example I did is actually more taxing because torrents are noisy and that's why I did it on the demo specifically with that processor I have here for the one I'm using at the studio so either way you slice it it really doesn't take as much as people usually think it does to run these intrusion detections but it really comes down to the number of tabs you have open in a browser and a number of persistent connections and a number of flows each client has as each one represents a pattern that has to be examined by storage so this does ramp up with a large maybe four or five thousand user phase where each of those users has a lot of connections and there's a lot to examine so there is times when you do want a much faster processor but for most people's uses it just doesn't require as much as people may think it does the final note is going to be the rules themselves I did a select all that is not the most ideal way to select rules you really want to figure out what rules are best for you and not select all of them because selecting all of them is going to create the most amount of noise and require the most amount of tuning unless that is your goal then select all is for you this is the fine tuning that always has to be done that should probably be done maybe for a week or two in essentially a detection mode before you turn it into prevention mode which means turn blocking on because if you turn blocking on from day one you generally end up with a bad experience because you're going along doing your thing and suddenly things stop working because they've matched patterns you have to then either a remove it from the block list but they'll pop right back on there unless you suppress rule so the more ideal is to figure out what rule was triggered whether or not that rule requires you to suppress it because it was real or fix whatever is causing the rule so it doesn't cause it again it is a back and forth very tedious game but it's also really fun learning especially if you're diving into security this is the same tool that's being used by other companies even including Cisco who is the maintainer of snort they're just not giving you an interface that gives you as much detail versus pf sensors giving you raw access to the tool they're not just blanket covering it as calling it intrusion prevention magic it's more you know this is snort or sericata whichever one you choose even in devices such as the unify dream machine which does have this on there they give you a little bit of tuning but not a lot and they're just using sericata and many of the same rules in the same way but they don't give you as many rules because they don't want to crank it up to max when in pf sense you can do the select all and really go crazy with it there's even more things you can turn on to watch things like skater controllers and all that you can go into some of the advanced menus be careful doing that because now you have even more work to do in terms of tuning love hearing from you though leave your thoughts and comments on this and other topics you may have around this down below because i really like engaging with people on security as a topic tell me what you think i'm right about what i'm wrong about and uh like and subscribe if you want to see more content from this channel and i'll see you in the forums or go to learnsystems.com and connect with me and whatever socials you can find there thanks