RFC (make up a number not in use) - Blueprint for setting up snort + pfblocker
-
The upcoming suricata topic will include a long section dedicated to creating suricata rules specific to a network gateway. There is no need to release my custom rules, since it will be explained how to create those rules on your own.
If most of the stuff I've written so far is considered short by me, then you'll realize what long means when you see the topic ;)
I'm actually putting the finishing touches (writing entire paragraphs here and there) on the first part, the firewalling part right now.
-
@jflsakfja:
that want to build a statue of me, thinking I'm the messiah or something.
;D ;D ;D
- 6 months later
-
Hello all, I tried Suricata, but it's not yet compatible with my system, so back again to Snort. Just a quick question that I can't seem to find the answer in the topic. What should we do with the rules that are disabled by default? In the Suricata guide I see that it's recommended to activate all first and then disable the unwanted rules. Should we take the same approach in snort?
I tried once this and Snort would not boot on the interface, probably some rule that should not be set on. I looked on the system log and no error. I uninstalled all and started from scratch.
Thank you
Best Regards -
Yes, the recommended way to set snort/suricata is to enable all then disable the rules suggested in the topics/list.
-
Thank you!
Any one had problems with rule "ET POLICY SSLv3 outbound connection from client vulnerable to POODLE attack
suppress" 1:2019416? I looked at both this tutorial and the suricata version, and both have this rule enabled! The problem is that if I leave this rule several google ip's are blocked, including play store and hangouts!Best regards
soloam -
The rule is valid, you just need to completely disable SSLv3 (and v2 and v1). See your browser's documentation on how to do it.
- 2 months later
-
Sorry if I ask a silly question here, as I very new to SNORT.
I have been reading a lot, some I do understand but most I don't here.
Ok, here I begin the silly question ;D
Let take an example here, let's look the ET rules shown below:
emerging-botcc > all emerging-chat > all except: 2010784 ET CHAT Facebook Chat (send message) 2010785 ET CHAT Facebook Chat (buddy list) 2010786 ET CHAT Facebook Chat (settings) 2010819 ET CHAT Facebook Chat using XMPP 2002327 ET CHAT Google Talk (Jabber) Client Login 2002334 ET CHAT Google IM traffic Jabber client sign-on 2001241 ET CHAT MSN file transfer request 2001242 ET CHAT MSN file transfer accept 2001243 ET CHAT MSN file transfer reject 2001682 ET CHAT MSN IM Poll via HTTP 2002192 ET CHAT MSN status change 2008289 ET CHAT Possible MSN Messenger File Transfer 2009375 ET CHAT General MSN Chat Activity 2009376 ET CHAT MSN User-Agent Activity ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Question here is the exception rules that I need to disable, for example: 2010784 ET CHAT Facebook Chat (send message) For the above rule if I need to do the exception, I need search the Signature ID which shown above = 2010784, I need to a search on this rule and disable it As you know this is a PAINSTAKING task of finding each and every Signature ID 2009376, 2009375…...etc and disable each and every one. Question: 1) Is there a short-cut method of doing this mundane task faster? :( 2) This process of disabling each exception will start all over again since, whenever there a new updated Snort package is released, and if updated, then snort is completely unassigned to the WAN interface, and I have to manually reassign snort to run on my WAN interface, and hence I need to do the exception rules ALL over again, right? :( Thank you.
-
-
there is a new guide coming (work in progress) which should greatly simplify initial setup. For now I'm afraid that it's the clickety-click process :-)
-
That's not expected behavior. Did you contact bmeeks about it? I've never had to redo a setup, even after removing the package (keep settings on removal MUST be ticked) and reinstalling
-
-
Sorry if I ask a silly question here, as I very new to SNORT.
I have been reading a lot, some I do understand but most I don't here.
Ok, here I begin the silly question ;D
Let take an example here, let's look the ET rules shown below:
emerging-botcc > all emerging-chat > all except: 2010784 ET CHAT Facebook Chat (send message) 2010785 ET CHAT Facebook Chat (buddy list) 2010786 ET CHAT Facebook Chat (settings) 2010819 ET CHAT Facebook Chat using XMPP 2002327 ET CHAT Google Talk (Jabber) Client Login 2002334 ET CHAT Google IM traffic Jabber client sign-on 2001241 ET CHAT MSN file transfer request 2001242 ET CHAT MSN file transfer accept 2001243 ET CHAT MSN file transfer reject 2001682 ET CHAT MSN IM Poll via HTTP 2002192 ET CHAT MSN status change 2008289 ET CHAT Possible MSN Messenger File Transfer 2009375 ET CHAT General MSN Chat Activity 2009376 ET CHAT MSN User-Agent Activity ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Question here is the exception rules that I need to disable, for example: 2010784 ET CHAT Facebook Chat (send message) For the above rule if I need to do the exception, I need search the Signature ID which shown above = 2010784, I need to a search on this rule and disable it As you know this is a PAINSTAKING task of finding each and every Signature ID 2009376, 2009375…...etc and disable each and every one. Question: 1) Is there a short-cut method of doing this mundane task faster? :( 2) This process of disabling each exception will start all over again since, whenever there a new updated Snort package is released, and if updated, then snort is completely unassigned to the WAN interface, and I have to manually reassign snort to run on my WAN interface, and hence I need to do the exception rules ALL over again, right? :( Thank you.
Snort should never lose settings on an update if you have checked the "keep settings on uninstall" checkbox on the GLOBAL SETTINGS tab. If that is checked and you are still losing settings, then something extremely weird is happening, like maybe some older config.xml file getting auto-restored or something (just a wild guess).
If you want to "mass enable/disable" rule SIDS, the new SID MGMT tab is tailor-made for this. It uses the same syntax as PulledPork or Oinkmaster conf files. There are examples described within the included sample files installed with the Snort package now.
Bill
-
@jflsakfja:
-
there is a new guide coming (work in progress) which should greatly simplify initial setup. For now I'm afraid that it's the clickety-click process :-)
-
That's not expected behavior. Did you contact bmeeks about it? I've never had to redo a setup, even after removing the package (keep settings on removal MUST be ticked) and reinstalling
jflsakfja and bmeeks, first of all, you all have done a commendable contribution to the community.
WELL DONE & KEEP UP THE GOOD WORK!!!! :)
many people like me need your volunteered advice and written guide in getting things working!!!-
Great!!! :)I hope the guide will be finished soon, that will assist in me / anyone for that matter, in doing the job of
disabling exception rules faster. Otherwise is a real tedious boring job ;D -
I have enabled the setting: Keep Snort Setting after deinstallation,
the pic attached. I must have disabled it previously, I think? ::)
-
-
That should take care of keeping the settings. If they are still lost, then report it to bmeeks.
You forgot to thank BBcan177 ;)
-
Hi
BBcan177 :)
Thank for everything! Cheers! :D
Keep up the good effort! ;D
- 8 days later
-
I just started using Snort and have found the information in this section to be very helpful, thank you jflsakfja!!!
I noticed that this post is no longer being updated by jflsakfja he indicated that he moved to another section of the forum however I am having some difficulty locating the updated section, could someone post the link to that section?
Thank you
-
I didn't move to any other section, this is the latest version publicly available. I'm working on the next version, and planning on how to properly keep it updated instead of endlessly posting on the forums, together with other author contributions, it's going to take a while. I understand everybody is eagerly awaiting for it, but it's not ready yet. Sit tight, relax and we'll get there :-)
-
Ok, that is great news!
Must have misread one of your other posts… explains why I couldn't find this "other topic" lol.
Thank You
-
Hi jflsakfja
Just for your information…...
I updated my pfSense from version 2.1.5 to 2.2.
The result was rather discouraging, I wish I have never updated it. :-[ :-[1st problem happened, after rebooting my pfSense….......
WAN interface which being assigned on my Atheros NIC (on-board) refuse to connect the internet.
Reason unknown, it was working fine under pfSense v2.1.5.
The fix for it was to reassigned the WAN interface to another NIC - realtek PCI-E adapter,
then I get back my internet connection up and running.
Otherwise, I just couldn't get my old Atheros NIC to be the WAN interface and get my internet online.
Very weird problem?????2nd problem happened, was rather a disaster to me to accept..... :'( :'(
All the snort rules, eg. Emerging Threat, and Snort GPLv2 community rules...etc have went back to [b]DEFAULT!!!!!.
Which unless defaulting rules are disabled, there will be a lot of false positive generated from running Snort.
I have to disable it one by one, rule by rule…..Sigh........Keep Snort Setting after deinstallation option is only working in Snort setting itself only,
but not Rules…....can someone confirm that????Is there a way to back up the disable rules permanently to a file?
Or something so that if the rules go back to DEFAULT
I can always restore the file and return to the desired configuration. ::) -
I'm still picking up fragments of systems that were perfectly fine on 2.1.5, but have mysteriously blown up on 2.2.
Settings in my case have always been preserved going through pfsense upgrades, including the rules. Dunno what happened there.
-
Hi jflsakfja
Just for your information…...
I updated my pfSense from version 2.1.5 to 2.2.
The result was rather discouraging, I wish I have never updated it. :-[ :-[1st problem happened, after rebooting my pfSense….......
WAN interface which being assigned on my Atheros NIC (on-board) refuse to connect the internet.
Reason unknown, it was working fine under pfSense v2.1.5.
The fix for it was to reassigned the WAN interface to another NIC - realtek PCI-E adapter,
then I get back my internet connection up and running.
Otherwise, I just couldn't get my old Atheros NIC to be the WAN interface and get my internet online.
Very weird problem?????2nd problem happened, was rather a disaster to me to accept..... :'( :'(
All the snort rules, eg. Emerging Threat, and Snort GPLv2 community rules...etc have went back to [b]DEFAULT!!!!!.
Which unless defaulting rules are disabled, there will be a lot of false positive generated from running Snort.
I have to disable it one by one, rule by rule…..Sigh........Keep Snort Setting after deinstallation option is only working in Snort setting itself only,
but not Rules…....can someone confirm that????Is there a way to back up the disable rules permanently to a file?
Or something so that if the rules go back to DEFAULT
I can always restore the file and return to the desired configuration. ::)If your interfaces changed names (you mentioned having to move WAN from one network card type to another one), then Snort will get confused with the rules since they are saved per interface. pfSense 2.2 is based on FreeBSD 10.1 while 2.1.x was based on FreeBSD 8.3. That means network card hardware drivers are likely changed or updated, and that can cause problems with some types of cards. That would be my guess in your case.
Bill
-
Hi jflsakfja
Just for your information…...
I updated my pfSense from version 2.1.5 to 2.2.
The result was rather discouraging, I wish I have never updated it. :-[ :-[1st problem happened, after rebooting my pfSense….......
WAN interface which being assigned on my Atheros NIC (on-board) refuse to connect the internet.
Reason unknown, it was working fine under pfSense v2.1.5.
The fix for it was to reassigned the WAN interface to another NIC - realtek PCI-E adapter,
then I get back my internet connection up and running.
Otherwise, I just couldn't get my old Atheros NIC to be the WAN interface and get my internet online.
Very weird problem?????2nd problem happened, was rather a disaster to me to accept..... :'( :'(
All the snort rules, eg. Emerging Threat, and Snort GPLv2 community rules...etc have went back to [b]DEFAULT!!!!!.
Which unless defaulting rules are disabled, there will be a lot of false positive generated from running Snort.
I have to disable it one by one, rule by rule…..Sigh........Keep Snort Setting after deinstallation option is only working in Snort setting itself only,
but not Rules…....can someone confirm that????Is there a way to back up the disable rules permanently to a file?
Or something so that if the rules go back to DEFAULT
I can always restore the file and return to the desired configuration. ::)If your interfaces changed names (you mentioned having to move WAN from one network card type to another one), then Snort will get confused with the rules since they are saved per interface. pfSense 2.2 is based on FreeBSD 10.1 while 2.1.x was based on FreeBSD 8.3. That means network card hardware drivers are likely changed or updated, and that can cause problems with some types of cards. That would be my guess in your case.
Bill
Hi Bill,
Thanks for replying.
Did I miss something really important from reading the upgrade guide: https://doc.pfsense.org/index.php/Upgrade_Guide?
The only drivers mentioned in the guide was DISK drivers as far as I know, but correct me if I am wrong.
The guide did not mentioned anything about NETWORK drivers, or is it something
that every FreeBSD users should expect to know that switching from FreeBSD v8.x to v10, the network drivers will be
affected. If so, I am not a FreeBSD user here!If I am wrong, I accept my mistake that I miss out a chunk of information stating that NETWORK drivers will be affected
But if I am right, I am really not HAPPY the way pfSense developing team doing this MAJOR upgrade.
At least forewarn us, the non-FreeBSD user about this issue.Sigh…...what I can do? Not much I suppose, that is the difference between an Open-source and Close source Firewall. :-[
-
Hi Bill,
Thanks for replying.
Did I miss something really important from reading the upgrade guide: https://doc.pfsense.org/index.php/Upgrade_Guide?
The only drivers mentioned in the guide was DISK drivers as far as I know, but correct me if I am wrong.
The guide did not mentioned anything about NETWORK drivers, or is it something
that every FreeBSD users should expect to know that switching from FreeBSD v8.x to v10, the network drivers will be
affected. If so, I am not a FreeBSD user here!If I am wrong, I accept my mistake that I miss out a chunk of information stating that NETWORK drivers will be affected
But if I am right, I am really not HAPPY the way pfSense developing team doing this MAJOR upgrade.
At least forewarn us, the non-FreeBSD user about this issue.Sigh…...what I can do? Not much I suppose, that is the difference between an Open-source and Close source Firewall. :-[
[/quote]I am only guessing about the NIC driver possibility. I'm am not a FreeBSD expert. I do recall seeing some other threads during the 2.2-RC testing phase about issues with NIC drivers (I seem to recall wireless ones in particular). I do know that if the network interfaces change around, then Snort will get quite confused and lose the old settings because it stores them using the interface name.
If you have an older backed up config.xml file, you can open it in a browser and down in the _<installedpackages><snortglobal></snortglobal></installedpackages>_section you will find the configured Snort interfaces. They will be encompassed by section tags like these:
You will see identifying information about each interface within those XML elements. The element tags and are used to store the GID:SID information for rules you have forced on or forced off for that interface. You can carefully copy the GID:SID pairs from the old file into the corresponding locations in your new config to restore the old enabled/disabled rules.
Bill