RFC (make up a number not in use) - Blueprint for setting up snort + pfblocker
-
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
-
Ok, I went into my pfSense Web interface, went to Diagnostic-Backup/Restore
Press the download configuration button, and the config.xml was
downloaded to my PC.Open up the config-pfsense-20150129111734.xm file and find the xml element =
But, I couldn't find it, am I looking at the wrong place. :(I double checked Snort rules are loaded, by going to WAN categories.
Any idea, why??? ::)
See the attached pictures.
-
Ok, I went into my pfSense Web interface, went to Diagnostic-Backup/Restore
Press the download configuration button, and the config.xml was
downloaded to my PC.Open up the config-pfsense-20150129111734.xm file and find the xml element =
But, I couldn't find it, am I looking at the wrong place. :(I double checked Snort rules are loaded, by going to WAN categories.
Any idea, why??? ::)
See the attached pictures.
I understood you formerly had manually forced disabled/enabled rules BEFORE you upgraded, and now after upgrading those manual changes were missing. In order to see the old changes, you would need to have access to a config.xml file saved BEFORE you upgraded. The current one will not have the tags because they were lost when your interfaces were shuffled around. It sounds like you created a totally new Snort configuration. If that is the case, then all of your old changes were lost unless you did a configuration backup BEFORE you did the last update.
Sorry if I misled you. I was assuming you had some old backups of your config.xml files stored offline. You should be able to find older config.xml files still stored on the firewall in the /cf/conf/backup directory. You could look in one of those older files for the tags.
Bill
-
@jflsakfja:
This is the final rule post in this topic. Moving forward, the rules will be found in the suricata topic, which I'll create in a couple of days. I strongly advise all to move to suricata and stop using snort.
With that out of the way, here's the rule updates:
By the way this is the post that had made me think you had stopped posting in this section…
-
Ok, I went into my pfSense Web interface, went to Diagnostic-Backup/Restore
Press the download configuration button, and the config.xml was
downloaded to my PC.Open up the config-pfsense-20150129111734.xm file and find the xml element =
But, I couldn't find it, am I looking at the wrong place. :(I double checked Snort rules are loaded, by going to WAN categories.
Any idea, why??? ::)
See the attached pictures.
I understood you formerly had manually forced disabled/enabled rules BEFORE you upgraded, and now after upgrading those manual changes were missing. In order to see the old changes, you would need to have access to a config.xml file saved BEFORE you upgraded. The current one will not have the tags because they were lost when your interfaces were shuffled around. It sounds like you created a totally new Snort configuration. If that is the case, then all of your old changes were lost unless you did a configuration backup BEFORE you did the last update.
Sorry if I misled you. I was assuming you had some old backups of your config.xml files stored offline. You should be able to find older config.xml files still stored on the firewall in the /cf/conf/backup directory. You could look in one of those older files for the tags.
Bill
Hi bmeeks
Thank you for responding my question.
Ok, I have done some screen captures.
So in future, I can copy all the forced rules off= GID:SID from within <rule_sid_off>to</rule_sid_off>
Then paste on the old config.xml file, if I have somehow lost the configuration setting in Snort for
configuring FALSE positives??? :)_part1of2.jpg)
_part2of2.jpg)
-
So in future, I can copy all the forced rules off= GID:SID from within <rule_sid_off>to</rule_sid_off>
Then paste on the old config.xml file, if I have somehow lost the configuration setting in Snort for
configuring FALSE positives??? :)You are correct. Copying and pasting the section you have highlighted will preserve the disabled rules.
Bill
-
Thanks bmeeks ;D
If there is any future update in Snort package, e.g. right now is 2.9.7.0 pkg v3.2.3 ,
say there is a newer version = 2.9.8.0 pkg v3.4.0 and I proceed to update.Does the update reset the disable rules and then goes back to the default settings??? ::)
-
Thanks bmeeks ;D
If there is any future update in Snort package, e.g. right now is 2.9.7.0 pkg v3.2.3 ,
say there is a newer version = 2.9.8.0 pkg v3.4.0 and I proceed to update.Does the update reset the disable rules and then goes back to the default settings??? ::)
No, updates to the package will remember and use all of your current settings so long as you have the checkbox ticked on the GLOBAL SETTINGS tab to "keep settings on deinstall". I've made that default to "checked" on new green field installs, but you can double check on your setup to insure the checkbox is checked.
Bill
-
The first post in this thread for the snort set up was in 2013, is that information for inital setup still valid ?
I am a noob to pFSense and just got mine up and running and just now about to install Snort for the first time
-
@ninjaneer:
The first post in this thread for the snort set up was in 2013, is that information for inital setup still valid ?
I am a noob to pFSense and just got mine up and running and just now about to install Snort for the first time
I'm not far behind you…. but I have been using it for a couple years and have just had to revisit it as health issues kept me from spending the time to update to the new versions under 2.2.4. But I'll say this is very close to still ringing true, some minor differences that I was able to work around in pfBlocker, Snort and the Rules setup. My Thanks to Bill for his help getting my system back up. I'm still tweaking on it a bit everyday.
I'd love to see Demetris update this but I know he is very deep into Suricata and he too is recovering from a serious health issue.
On that note... while rebuilding my aliases, I discovered many of the lists I had used were either abandoned, had slight name changes or were just no longer available.
Does anyone who really stays current have a good group of the current blocklists they import they would care to post??
Thanks,
Rick -
If you don't mind me asking (stupidly): What's the point of this?
Can't I just enable all and be done with it?! Is this just for a few MB's of ram savings? -
If you don't mind me asking (stupidly): What's the point of this?
Can't I just enable all and be done with it?! Is this just for a few MB's of ram savings?While there are certainly some RAM savings (mine were significant), it has more to do with settings and processing behaviors. The OP also had a deep understanding of the rules and their history and knew which rules were old and obsoleted and which new rules were causing false positives.
Yep, you can turn them all on… expect some problems getting to things.
But depending on your needs and places you go you'll find yourself doing some tweaking anyway.
-
The missing emerging-dhsield ip list might be this url?
http://feeds.dshield.org/top10-2.txt
