Quick Snort Setup Instructions for New Users
-
Yes but even if you run more than one whitelist, you can only add one for the WAN interface….
-
Yes but even if you run more than one whitelist, you can only add one for the WAN interface….
Multiple whitelists for the same interface don't really make sense to me. It all has to be a single file for the Spoink plugin anyway. Now what could be done is allow the addition of multiple Aliases, but the same thing can be accomplished by using Alias groups. So it's six of one and half-dozen of the other as we say in America ;D The idea with multiple whitelists is to have a different one for each interface if you want.
Perhaps you are not using Aliases to their full extent? They are a powerful tool that makes future upkeep of the firewall rules and Snort easy. When an IP changes, just change it once in the Alias tab and it is instantly changed everywhere that Alias is used. Contrast this with having individual IPs scattered all over the rules in the firewall, Snort and other places. Lots of places to change then and lots of opportunity for typos.
I have yet to encounter a whitelist situation that can't be solved with a single Alias group. Then in that group I can add all kinds of host IPs and/or networks. These all get translated into actual IPs when the whitelist file is built during generation of the snort.conf file.
Lots of commercial firewalls use the same idea as Aliases. I work extensively with Check Point firewalls, and they call them "objects", but they work the same way as Aliases in pfSense. In Check Point, you cannot enter an IP address or port number anywhere in a firewall rule. Everything has to be entered as an object. You first create objects having the IP addresses and ports you want to use, then you select those objects in your rules. It seems extra work the first time you see it, but then you quickly start to appreciate the utility when you come along and need to change a host IP for instance. Just change it in the object, push the firewall policy (Check Point's term for regenerating the configuration), and the new IP address is reflected in every rule that references it. No need to manually update the IP in say a dozen rules or something (where each time you type it you could enter it wrong).
-
Alias Group??? Where in the GUI is that Bill?
-
Alias Group??? Where in the GUI is that Bill?
You can create an Alias that has other Aliases in it. Under Firewall…Aliases. Attached are two screenshots showing my whitelist alias group. Click the (e) to edit the alias. Then on the next screen click the (+) icon to add more entries to the alias (in effect making it an Alias Group).
Bill
-
This is great!! Thx ;)
-
Here is the Whitelist entry itself. Notice the Alias down at the bottom is the one created in the previous screenshots.
Bill
-
I understand! Thx mate. Really appreciated!
-
I understand! Thx mate. Really appreciated!
You're welcome. I just used some quick and dirty names for example, but you could name things logically and perhaps create a "WAN_whitelist_hosts" Alias and then others for different interfaces. As I said, Aliases are very powerful tools once you get the hang of using them.
Bill
-
I have named it Snort Friendly IP :D
-
First of all, sorry if it's a noob question. We use pfSense as inter-department firewall within private network. We could install snort package through pfSense proxy setting. However, we couldn't perform the snort rule update. Is there anyway we could set the proxy snort update and how? or how to perform snort rule update manually?
FYR, we are using pfSense 2.0.3 with Snort 2.9.4.6 pkg v. 2.5.9
Thank you in advance.
Sent you a PM with my e-mail address. Reply back to the address and I will send you a patched file I would like for you to test for me. I think it will allow Snort rule updates through the pfSense system proxy.
Bill
-
Thank you both for the explanations, I learned something valuable ;D
-
Could I ask a question about the oinkcode?
I purchased a subscription, but I am not quite sure if I understand the GUI correctly now.
Before, the last couple of months, when I didn't have a subscription, I flagged 'install snort community rules' (obviously, since they are free ;D) and also enabled them on both interfaces (for/ex: WAN-categories -> Select the rulesets Snort will load at startup -> Snort GPLv2 Community Rules (VRT certified)).
But now that my oinkcode stands for a paid subscription, do I still have to select 'install snort community rules', or is just selecting the right 'IPS-policy' sufficient? I ask, since specifically now I don't see any alerts in my Snort-log anymore.
Thank you for your answer ;D
-
@Hollander:
Could I ask a question about the oinkcode?
I purchased a subscription, but I am not quite sure if I understand the GUI correctly now.
Before, the last couple of months, when I didn't have a subscription, I flagged 'install snort community rules' (obviously, since they are free ;D) and also enabled them on both interfaces (for/ex: WAN-categories -> Select the rulesets Snort will load at startup -> Snort GPLv2 Community Rules (VRT certified)).
But now that my oinkcode stands for a paid subscription, do I still have to select 'install snort community rules', or is just selecting the right 'IPS-policy' sufficient? I ask, since specifically now I don't see any alerts in my Snort-log anymore.
Thank you for your answer ;D
The paid subscription Oinkcode automatically includes the "Snort Community Rules" in the downloaded rule set, so you do not need to manually select those anymore.
Just check the Snort VRT rules (and optionally Emerging Threats if you want some of those), then choose an IPS Policy. You will get the Community Rules this way.
Bill
-
I have snort up and running. I subscribed to the VRT rules. However when I added my oinkcode, it doesn't seem to download the latest subscriber rules. For example I ran the update today, and it downloaded snortrules-snapshot-2946.tar.gz Sept 3. It should have downloaded snortrules-snapshot-2950.tar.gz
-
I have snort up and running. I subscribed to the VRT rules. However when I added my oinkcode, it doesn't seem to download the latest subscriber rules. For example I ran the update today, and it downloaded snortrules-snapshot-2946.tar.gz Sept 3. It should have downloaded snortrules-snapshot-2950.tar.gz
No, the binary version of Snort is considered when downloading rule updates. The rules are coded for the different binary versions. Snort on pfSense is currently version 2.9.4.6, so you will download the 2.9.4.6 rules snapshot. The rules usually update on Tuesday and Thursday over at Snort.org.
An update to the 2.9.5.5 Snort binary for the pfSense Snort package should come out late this month or early in November. Testing it now.
Bill
-
Hi!
I am using policy connectivity.
I am getting false positives for ssp_ssl: Invalid Client HELLO after Server HELLO Detected.How can i disable this policy when using policy?
best regards
Karl
-
Hi!
I am using policy connectivity.
I am getting false positives for ssp_ssl: Invalid Client HELLO after Server HELLO Detected.How can i disable this policy when using policy?
best regards
Karl
You can't easily disable this directly because it is a preprocessor alert. I've seen some traffic about this alert on the Snort mailing list that indicates it is a potential bug in the preprocesor code.
The best workaround for now is to create a Suppress List entry for this alert. On the ALERTS tab, click the little plus sign (+) next to the alert's GID:SID. This will automatically add it to the Suppress List and you won't get blocks on those IPs. You will still see the alert in the ALERTS tab, but it will not block the offending IP.
After adding the Suppress entry, restart Snort on the affect interface.
Bill
-
hi!
thanks for your answer.
i am aware about the supress function but best practice says that you should disable the rule.
anyway: i will test supressing as all alerts are forwarded to icinga. i hope this will also be supressed
greetings
karl
-
hi!
thanks for your answer.
i am aware about the supress function but best practice says that you should disable the rule.
anyway: i will test supressing as all alerts are forwarded to icinga. i hope this will also be supressed
greetings
karl
Disabling is the best, but with today's hardware capability just suppressing is fine. That's the answer you generally get from the Snort VRT folks as well. Maybe if you are inspecting 1 Gbit/sec plus traffic loads, the distinction between disabling and suppressing matters; but for most folks with modern hardware there is no meaning difference.
Bill
-
Just another question:
If snort is bound to Interface WAN and pfsense is in transparent mode, how is snort working when blocking is activated?
does snort drop the packet and blocks the ip or is the packet passed and then the ip is blocked?
regards
karl
