seeing fewer alerts than I would expect with Snort on WAN
-
@pzanga
There is no snort so rule's downloaded.On the snort global setting's page have you input an oinkcode?
On my snort instance I run the snort paid describer rule's about $30.00 a year.
With a ips policy set and don't even mess with the et-open or community rule's
or openapp rule's. -
@impatient
Thanks for pointing that out about the SO rules. I meant to mention that but spaced out on that one. Not sure why they are not there. We do have an oinkcode entered. And below are the selected rulesets.Are there any other settings I should look at that could cause that? I have searched but have not found this issue mentioned anywhere. Maybe I should just uninstall/reinstall Snort? And maybe need a new oinkcode?
-
If you have a paid Snort Subscriber Rules account, there is no need to separately enable the Snort GPLv2 Community Rules as they are included in the paid rules download. You would only use the GPLv2 Community Rules if you had the non-paid Snort Oinkcode or had no Oinkcode at all.
The very best setup for a beginner with IDS/IPS is t0 buy the Snort Subscriber Rules account ($30/year for personal use or $300 for commercial use) and then enable IPS Policy on the CATEGORIES tab and select "IPS Policy - Connectivity" for the policy.
Run for several weeks with that policy in non-blocking mode to get a feel for the alerts (and what would be blocks once you enable blocking). As @SteveITS mentioned, I strongly recommend moving Snort over to the LAN interface to make identifying local hosts in alerts much easier. Otherwise, all local hosts are going to show up in the alerts as having the public WAN IP if you run Snort on the WAN.
-
If you have a paid Snort Subscriber Rules account, there is no need to separately enable the Snort GPLv2 Community Rules as they are included in the paid rules download. You would only use the GPLv2 Community Rules if you had the non-paid Snort Oinkcode or had no Oinkcode at all.
The very best setup for a beginner with IDS/IPS is t0 buy the Snort Subscriber Rules account ($30/year for personal use or $300 for commercial use) and then enable IPS Policy on the CATEGORIES tab and select "IPS Policy - Connectivity" for the policy.
Run for several weeks with that policy in non-blocking mode to get a feel for the alerts (and what would be blocks once you enable blocking). As @SteveITS mentioned, I strongly recommend moving Snort over to the LAN interface to make identifying local hosts in alerts much easier. Otherwise, all local hosts are going to show up in the alerts as having the public WAN IP if you run Snort on the WAN.
Thanks for all that. I have actually picked up on most of that advice over the last few months, from your numerous posts/replies on this forum. I believe our Oinkcode is of the non-paid variety, and given that I don't control the purse strings at work let's assume that it will continue that way for the foreseeable future. Given that, I still have just a few more questions hopefully you, or someone else, can answer.
-
the fact that there are no SO rules downloaded (screenshot in original post) - is that because I have an non-paid Oinkcode, or is there something else going on?
-
would I select the GPLv2 Community rules along with the "IPS Policy-Connectivity" option? As I noted above, it isn't clear to me if they have IPS policy metadata tags and would be enforced if the corresponding policy is selected, like the VRT rules.
-
as far as moving Snort over to the LAN, like I said, I was planning on that but just want to figure out what, if anything, isn't working right currently before doing that. Should I then disable Snort on the WAN, with the few open ports we have, or leave it on both? From what I have been reading, the former (LAN not WAN) seems to be recommended configuration, but there does seem to be various views on the matter, and I believe your recommendation @bmeeks has changed over time. I'm just seeking some clarification on that.
-
if using IPS Policy-Connectivity, should I also consider using any of the ET Open rules (and maybe OPENAPPID)? As I noted above, this is a medical practice, and I know the healthcare sector has been targeted for attacks in the age of Covid. I just want to be sure we are well protected.
Thanks again for the help. It is truly appreciated.
-
-
@pzanga said in seeing fewer alerts than I would expect with Snort on WAN:
- the fact that there are no SO rules downloaded (screenshot in original post) - is that because I have an non-paid Oinkcode, or is there something else going on?
The SO (Shared Object) rules are not a distinct and separate download. They are packaged inside of the Snort Subscriber rules (both paid and non-paid Snort Subscriber Rules). They are NOT part of the GPLv2 set. The SO rules are proprietary pre-compiled rules usually written in C and compiled for the various operating systems Snort supports (Linux, FreeBSD and others). You can see the SO rules on the CATEGORIES tab when the Snort Subscriber rules are enabled for download (and have been downloaded).
- would I select the GPLv2 Community rules along with the "IPS Policy-Connectivity" option? As I noted above, it isn't clear to me if they have IPS policy metadata tags and would be enforced if the corresponding policy is selected, like the VRT rules.
I have not checked in a long time, but I'm pretty sure the GPLv2 rules do not contain IPS policy metadata. Therefore they would have to be separately enabled, if used, as they would not get pulled in with a policy.
- as far as moving Snort over to the LAN, like I said, I was planning on that but just want to figure out what, if anything, isn't working right currently before doing that. Should I then disable Snort on the WAN, with the few open ports we have, or leave it on both? From what I have been reading, the former (LAN not WAN) seems to be recommended configuration, but there does seem to be various views on the matter, and I believe your recommendation @bmeeks has changed over time. I'm just seeking some clarification on that.
The LAN is the best place for two reasons. First, it is pointless to inspect traffic the firewall is going to drop anyway. That's what happens if you put Snort on the WAN. Second, when on the WAN, all local network IP addresses show-up post-NAT. That means all you ever see is the firewall's public IP and then the external Internet host's IP in the alerts. That makes it extremely hard to know what local host generated the alert.
All traffic has to go through Snort to get to your local devices when you put it on the LAN (or DMZ, if you have one of those). You don't use Snort to protect the firewall. You use Snort to protect local internal hosts. If you think you need Snort to protect your firewall, then you need a new firewall as the one you have is no good ... .
- if using IPS Policy-Connectivity, should I also consider using any of the ET Open rules (and maybe OPENAPPID)? As I noted above, this is a medical practice, and I know the healthcare sector has been targeted for attacks in the age of Covid. I just want to be sure we are well protected.
No, I would use the IPS Policy and forget the ET Open rules. They don't cover all the current threats, and with an SG-1100 (which is what I think you said you have), you don't have enough RAM to go loading up extra rules.
Thanks again for the help. It is truly appreciated.
-
@bmeeks
Once again, thank you for the help.
The one thing that is still not clear to me is why there are no SO rules showing up under Services/Snort/Categories/WAN. Snort VRT is enabled and an Oinkcode is entered under Global Settings, and Snort Subscriber Ruleset shows under Installed Rule Set on the Updates tab (up to date as of this morning). It may be a moot point since I am going to move Snort to the LAN and maybe adding it on a different interface will work correctly, but I'd like to understand why it's not working right in its current state before doing that.
Any insight into the SO rules not showing would be great. Thanks. -
What exactly are you looking for. You do realize the SO rules are simply additional rules within the same Snort rules archive, right? Here is an example screenshot:
I've drawn a red rectangle around the SO (shared object) rules. Notice they all have ".so" in their name.
The above is a capture of the CATEGORIES tab from a Snort interface.
-
@bmeeks
I am wondering why there are no SO rules in my ruleset listing. Below is a screenshot from my system:
I can't find any posts referring to this or similar issues and am at a loss as to why this is happening (or not happening depending on your point of view ).
-
Can't say that I've ever seen that either. Perhaps a removal and re-installation of the Snort package is called for. You can do that without losing any of the existing configuration.
-
@bmeeks
Well, if I have stumped the master then uninstall/reinstall seems the way to go.
I was leaning that way anyway, since I plan on moving Snort to the LAN. I will post how that goes, especially if it still acts odd. -
@bmeeks
Well, I am still not seeing the SO rules listed in the UI, after an uninstall/reinstall. Here is what I tried:-
first I deleted the Snort WAN interface, did an uninstall/reinstall with retention of Snort settings enabled, set up LAN interface, all rulesets updated successfully, but no SO rules listed
-
next, I followed the same steps, except I disabled the retention of Snort settings so I would essentially be starting from scratch and rebooted the device before the reinstall. After configuring LAN interface, rules, etc, I end up with same result.
-
finally, I uninstalled/reinstalled without retaining settings and entered a new non-paid Oinkcode (just a shot in the dark), and after reconfiguring everything still don't see the SO rules listed
At this point I am at a loss as to next steps. Are there any other settings I should be checking, or any particular directories/log files I should take a look at?
I will note that I left Snort running on the LAN overnight, between the 2nd and 3rd reinstalls noted above, with IPS Policy-Connectivity selected and noted more alerts than before (not a ton, but had about 7 or 8 when I got in this morning) and can see the actual LAN source/destination, which is obviously much more useful.
-
-
@pzanga said in seeing fewer alerts than I would expect with Snort on WAN:
@bmeeks
Well, I am still not seeing the SO rules listed in the UI, after an uninstall/reinstall. Here is what I tried:-
first I deleted the Snort WAN interface, did an uninstall/reinstall with retention of Snort settings enabled, set up LAN interface, all rulesets updated successfully, but no SO rules listed
-
next, I followed the same steps, except I disabled the retention of Snort settings so I would essentially be starting from scratch and rebooted the device before the reinstall. After configuring LAN interface, rules, etc, I end up with same result.
-
finally, I uninstalled/reinstalled without retaining settings and entered a new non-paid Oinkcode (just a shot in the dark), and after reconfiguring everything still don't see the SO rules listed
At this point I am at a loss as to next steps. Are there any other settings I should be checking, or any particular directories/log files I should take a look at?
I will note that I left Snort running on the LAN overnight, between the 2nd and 3rd reinstalls noted above, with IPS Policy-Connectivity selected and noted more alerts than before (not a ton, but had about 7 or 8 when I got in this morning) and can see the actual LAN source/destination, which is obviously much more useful.
I have no suggestions. As a confirmation test, I just installed Snort clean on a virtual machine installation of pfSense-2.5.0 with no issues. The SO rules show up just fine (like in my previous screen capture).
Look in this directory and see if the physical files are present. The only possibility I can imagine is that perhaps they are not getting copied to the correct place when extracted. Look in
/usr/local/etc/snort/rules
and see if you find any SO files in there. You would be looking for files named "*.so.rules" (where the * will be some category name).If you don't see any such rules in the directory, then it's time to start checking why the extraction/copying phase is not moving them there.
-
-
@bmeeks
Well, no "*.so.rules" were found in the /usr/local/etc/snort/rules directory. The system log and manage rule set log (services/snort/update rules) show no errors related to extraction/installation.
Still can't find any other reports of this issue here or on the interwebs; everything issue I find that is remotely similar has error messages associated with it, which I am not seeing. I will continue to search likely start a new thread focused on the issue. Just wanted to tie this thread off.
Thanks again for the help. -
@pzanga said in seeing fewer alerts than I would expect with Snort on WAN:
@bmeeks
Well, no "*.so.rules" were found in the /usr/local/etc/snort/rules directory. The system log and manage rule set log (services/snort/update rules) show no errors related to extraction/installation.
Still can't find any other reports of this issue here or on the interwebs; everything issue I find that is remotely similar has error messages associated with it, which I am not seeing. I will continue to search likely start a new thread focused on the issue. Just wanted to tie this thread off.
Thanks again for the help.I really have no explanation for that. The gzip archive is downloaded to a created subdirectory under
/tmp
. The archive is then unzipped usinggzip
. The rules files are then copied to/usr/local/etc/snort/rules
. The SO rules files come in several different flavors within the archive (compiled for different operating system versions). The PHP code determines the OS version of the firewall and then copies the proper set of files over to the directory above. At the end of the rules update job, the temporary directory in/tmp
is removed.If you want to troubleshoot a bit further, you can comment out the line that deletes that temp directory. That way you could browse it manually to see if that gives any clues. To do this, edit the following file:
/usr/local/pkg/snort/snort_check_for_rule_updates.php
. Open that file in an editor, scroll down to the bottom, and look for this sequence of lines:/* remove $tmpfname files */ if (is_dir("{$tmpfname}")) { snort_update_status(gettext("Cleaning up temp dirs and files...")); rmdir_recursive($tmpfname); snort_update_status(gettext(" done.") . "\n"); }
Comment out the "rmdir_recursive()" call by modifying that section to look like this (notice the double forward slashes are added at the start of the line):
/* remove $tmpfname files */ if (is_dir("{$tmpfname}")) { snort_update_status(gettext("Cleaning up temp dirs and files...")); // rmdir_recursive($tmpfname); snort_update_status(gettext(" done.") . "\n"); }
Run a rules update job (you may need to click the Force button to make it run the full update so it will download and extract rules). When the job completes, browse the directory
/tmp/snort_rules_up
. Look for extracted SO rules for FreeBSD.Don't forget to go back and remove the double forward slashes in the PHP file when done.
-
@bmeeks said in seeing fewer alerts than I would expect with Snort on WAN:
Here is what I see in /tmp/snort_rules_up after editing the php file:
Not sure what should be there, but I did open the .config files and don't see anything referencing SO rules or FreeBSD. Here is the log file for that Force update that I did:
Starting rules update... Time: 2021-04-09 09:13:33 Downloading Snort Subscriber rules md5 file snortrules-snapshot-29170.tar.gz.md5... Checking Snort Subscriber rules md5 file... There is a new set of Snort Subscriber rules posted. Downloading file 'snortrules-snapshot-29170.tar.gz'... Done downloading rules file. Downloading Snort OpenAppID detectors md5 file snort-openappid.tar.gz.md5... Checking Snort OpenAppID detectors md5 file... There is a new set of Snort OpenAppID detectors posted. Downloading file 'snort-openappid.tar.gz'... Done downloading rules file. Downloading Snort AppID Open Text Rules md5 file appid_rules.tar.gz.md5... Checking Snort AppID Open Text Rules md5 file... Snort AppID Open Text Rules are up to date. Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5... Checking Snort GPLv2 Community Rules md5 file... There is a new set of Snort GPLv2 Community Rules posted. Downloading file 'community-rules.tar.gz'... Done downloading rules file. Downloading Emerging Threats Open rules md5 file emerging.rules.tar.gz.md5... Checking Emerging Threats Open rules md5 file... There is a new set of Emerging Threats Open rules posted. Downloading file 'emerging.rules.tar.gz'... Done downloading rules file. Extracting and installing Snort Subscriber Ruleset... Using Snort Subscriber precompiled SO rules for FreeBSD-12 ... Installation of Snort Subscriber rules completed. Extracting and installing Snort OpenAppID detectors... Installation of Snort OpenAppID detectors completed. Extracting and installing Snort GPLv2 Community Rules... Installation of Snort GPLv2 Community Rules completed. Extracting and installing Emerging Threats Open rules... Installation of Emerging Threats Open rules completed. Copying new config and map files... Updating rules configuration for: LAN ... Restarting Snort to activate the new set of rules... Snort has restarted with your new set of rules. The Rules update has finished. Time: 2021-04-09 09:19:29
Not sure if there's anything there that helps me.
(On a side note - how do I format the above pasted log file so it is scrollable in the forum post? I hate taking up unnecessary space)edit - nm, didn't realize it would scroll on its own -
Crap! It just hit me on the head what your problem is ... .
Reading your log and comparing the lines to the PHP code made it click in my old head.
You have an ARM architecture box. The SO rules are precompiled for specific operating systems and platforms. Those platforms are only i386 (32-bit Intel/AMD hardware) and amd64 (64-bit Intel/AMD hardware). There are no precompiled SO rules for ARM hardware like that used in the SG-1100.
So there are no SO rules available to be extracted for the ARM-based appliances. I should have clued in on that with your first post, but I just missed it. Sorry. I feel really stupid now ... .
-
@bmeeks
No worries. I appreciate the fact you took the time to help with this, and we did find an answer and I learned some things. So, if this is working as designed I will just run with it as is. I guess my last question would be "how significant is the lack of SO rules in terms of Snort's functioning as an IDS/IPS (i.e. are there significant threats that are potentially being missed)?". -
@pzanga said in seeing fewer alerts than I would expect with Snort on WAN:
@bmeeks
No worries. I appreciate the fact you took the time to help with this, and we did find an answer and I learned some things. So, if this is working as designed I will just run with it as is. I guess my last question would be "how significant is the lack of SO rules in terms of Snort's functioning as an IDS/IPS (i.e. are there significant threats that are potentially being missed)?".Well, the SO rules do cover certain unique threats. Whether you actually have exposure to them is something you would have to investigate. But since you can't use them anyway, with your ARM hardware, no sense worrying about it unless you change hardware to an Intel/AMD platform.