Snort whitelist IP's not working, what I my doing wrong?
-
@lpallard:
@lpallard:
Bill, can you take a look and let me know if this is a system problem or there is really a problem with the REGEX in this rule?
It is an actual problem within the rule text. I sent a notice to one of the Emerging Threats guys several months ago about it, got an acknowledgement that it was faulty and they would get it fixed. Someone seems to have dropped the ball after that.
There are many issues in all of the rule sets. There are outdated rules, rules with errors in them, etc. It's like most of the rule writers are always focused on adding new rules to the sets but not going through and periodically doing maintenance to remove outdated or just plain wrong rules. Or at least they don't seem to do the latter very often IMHO.
Bill
Hmmmm its too bad. Snort's effectiveness will likely suffer from this..
In the meantime, do you know a good way of retrieving (or listing) all rules that have been manually disabled from the alert's tab? (The ones I clicked "Force disable this rule and remove it from the current ruleset)
I have opted to disable rules but in the end I'd rather add the "offerder's" IPs to an alias rather than deactivating the rule alltogether. Browsing one category at the time and looking through thousands of rules to find the ones in pale yellow status (user disabled) seems ineffective and unreliable to me..
Cheers!
I currently have a Pull Request for a Snort updated posted for review by the pfSense developers. Once they approve and merge the update, Snort will have the same automatic rule SID management features as Suricata. You can use text-based conf files compatible with Oinkmaster and PulledPork to enable or disable individual rules by category, GID:SID, or PCRE matching. Read up on the feature by looking at the Suricata threads in this sub-forum.
Once this is in the production Snort package, it will be the best way for you to manage Snort rules.
Bill
-
Allright Bill! I will look at Suricata's thread to familiarize myself with the concept, in the meantime, I will wait for Snort's package modifications to be implemented.
So far Snort is running VERY fine on my firewall and seems to be protecting my network fine
Big THANKS to you and all for helping and teaching how Snort works!
-
@lpallard:
Allright Bill! I will look at Suricata's thread to familiarize myself with the concept, in the meantime, I will wait for Snort's package modifications to be implemented.
So far Snort is running VERY fine on my firewall and seems to be protecting my network fine
Big THANKS to you and all for helping and teaching how Snort works!
Here is a good starting point for seeing what's in Suricata that will be coming soon to Snort: https://forum.pfsense.org/index.php?topic=80886.0
-
Im kinda going back to the title of this topic … It appears as I may not yet be a master at Snort.... :)
I have added a range of IPs in an alias called "externalservices", and regrouped this alias with others in a new alias called "trusted" (see screenshots)
Then I added this alias in a passlist under snort.
Then I added this passlist in my WAN interface.
Easy Peasy... So far...
The problem is that Snort still blocks the IPs in the range specified in the alias.
Why?? of course I restarted the interface, and even tried rebooting pfsense to no avail..
-
@lpallard:
Im kinda going back to the title of this topic … It appears as I may not yet be a master at Snort.... :)
I have added a range of IPs in an alias called "externalservices", and regrouped this alias with others in a new alias called "trusted" (see screenshots)
Then I added this alias in a passlist under snort.
Then I added this passlist in my WAN interface.
Easy Peasy... So far...
The problem is that Snort still blocks the IPs in the range specified in the alias.
Why?? of course I restarted the interface, and even tried rebooting pfsense to no avail..
Can you post screenshots of the following things?
1. The WAN SETTINGS tab scrolled down to the section where you set the PASS LIST.
2. Click the VIEW LIST button to the right of the PASS LIST drop-down and capture the contents of the pop-up window (or at least verify that all the IP addresses that should be on your PASS LIST show up there).
Bill
-
There you go..
-
Thanks for posting the screenshots. They seem to be OK. One thing that I just noticed, in your earlier screenshots you were saying the IPs were being blocked but you are showing alerts from the ALERTS tab. Are those IPs also showing up as actively blocked on the BLOCKED tab and by looking at the <snort2c>table under Diagnostics…Tables?
When an IP is in a PASS LIST, you will still get alerts from it, but those alerts should not result in a block. To see which IPs are currently being actively blocked, you look on the BLOCKED tab.
Bill</snort2c>
-
Hey Bill,
my pleasure for the screenshots.
Yes, although I was showing the alerts tab, they are indeed in the Blocked tab….
They are also in the snort2c table.
Yes, I have noticed if an IP generates an alarm and is in the passlist, only the alarm will be created and the IP will NOT get blocked. But it seems on my system this is ONLY true for my home_net and external_net variables....
Weird no?
-
@lpallard:
Yes, I have noticed if an IP generates an alarm and is in the passlist, only the alarm will be created and the IP will NOT get blocked. But it seems on my system this is ONLY true for my home_net and external_net variables….
This sentence is a bit confusing for me. Are you saying that only IP addresses in your HOME_NET and EXTERNAL_NET variables are never blocked? That is a kind of contradiction since EXTERNAL_NET on Snort is generally all addresses not in HOME_NET when using the default setting.
The default parameters for a PASS LIST will include within it all locally-attached IP subnets as well as DNS servers, gateways, and the WAN IP address. These would never be blocked. The ADDRESS alias you can add on the PASS LIST edit screen is where you specify other IP addresses that will not be blocked. You can only specify actual IP addresses in that Alias. You cannot use any FQDN type alias.
To the best of my knowledge, this feature is working for all other users.
Bill
-
Bill, I have a question regarding "(portscan) TCP Portsweep" and "(portscan) TCP Filtered Portsweep"..
To be quite honest, when I enabled the preproc for the portsweep detection, I thought this would be useful in blocking the IP's purposely performing portsweeps on my public IP (I had in mind attack servers, etc) but what ended up happening is that most (80%+) of the sites I visit are getting blovked by snort because of portsweeps.
Most of these sites are well known sites (google IP's, my ISP's portal, cnn.com, some popular forums, etc)… I must say most of the alarms are from Google's e100 servers (173.194.0.0/16, 74.125.0.0/16, 216.58.0.0/16).
So I am wondering if these alarms are "normal" and should be ignored because they originate from well known/reliable sources, but on the other hand why would forums, search engines and other public sites perform portsweeps???
I hope you can shed some light on this issue.. for now I have kept the preproc enabled and when a site doesnt load (or stops loading) I login to pfsense and remove the blocked host from the block list (PITA)..
Thanks!
-
@lpallard:
Bill, I have a question regarding "(portscan) TCP Portsweep" and "(portscan) TCP Filtered Portsweep"..
To be quite honest, when I enabled the preproc for the portsweep detection, I thought this would be useful in blocking the IP's purposely performing portsweeps on my public IP (I had in mind attack servers, etc) but what ended up happening is that most (80%+) of the sites I visit are getting blovked by snort because of portsweeps.
Most of these sites are well known sites (google IP's, my ISP's portal, cnn.com, some popular forums, etc)… I must say most of the alarms are from Google's e100 servers (173.194.0.0/16, 74.125.0.0/16, 216.58.0.0/16).
So I am wondering if these alarms are "normal" and should be ignored because they originate from well known/reliable sources, but on the other hand why would forums, search engines and other public sites perform portsweeps???
I hope you can shed some light on this issue.. for now I have kept the preproc enabled and when a site doesnt load (or stops loading) I login to pfsense and remove the blocked host from the block list (PITA)..
Thanks!
I don't have a precise answer, but my personal observations over the last year indicate the portscan preprocessor in Snort has become overly sensitive and "false-positives" frequently. I've had to set mine on the WAN to the lowest sensitivity and add a number of known safe and frequently visited sites to an Alias and then assign that Alias to the "Ignore Scanners" parameter in the portscan preprocessor configuration.
Things that open a number of HTTP connections like hitting a busy web site with a bunch of ad server lookups, for example, seem to trigger portscan alerts.
Bill
-
I also observed that most (now I am even starting to think maybe ALL) sites are generating portscans but why, that remains a mystery to me.. What I ended up doing was to lower the preproc setting sensitivity to low on the snort interface, then allow a "running-in" period where I try to visit as many sites as I usually visit and let my systems contact whatever web services they need, then when an alert is generated I add it to an alias that I assigned to Snort's interfaces…
May not be the best but it works. All I need now is a real attack from one of those "legit and trusted" sites and snort wont pick it up..
Perfection doesnt exist I guess...
This page also helped me a lot:
http://manual.snort.org/node85.html
Thanks Bill for your help once again!