Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions

tsmalmbe

@bmeeks Excellent post. I did some testing today and this very kuch verifies what I saw.

So, how would diaable SID and suppressing then relate? Suppressing is based on for instamce ip addresses?

What about pressing the red X in the gui for a specific block or snort hit? Is that then equal to disablesid and which comes first when rules are evaluated? Which should be preferred, and what is the philosophocal difference?

If I enable all categories without modifying the actions, is that equal to which of the predefined ”policies”?

bmeeks

@tsmalmbe said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

So, how would diaable SID and suppressing then relate? Suppressing is based on for instamce ip addresses?

Disabling a rule is not the same as suppressing the rule. When a rule is disabled (or when commented-out in the corresponding category file), the rule is not loaded into the IDS/IPS memory space at all. It does not consume any resources, because as far as the IDS/IPS is concerned, that rule does not exist.

When a rule is suppressed, that means the alert (and the corresponding log entry) from the rule when it fires is not created. But the rule is loaded into memory by the IDS/IPS, and the rule consumes resources, and traffic is checked against the rule; but when traffic matches, the rule does not log an alert. But if the action of the rule is DROP or REJECT, that action is taken even if the rule is suppressed. It just is not logged. That can be a bit confusing, but it's just how the IPS binaries work.

What about pressing the red X in the gui for a specific block or snort hit? Is that then equal to disablesid and which comes first when rules are evaluated? Which should be preferred, and what is the philosophocal difference?

Clicking the red X on the ALERTS tab disables the corresponding GID:SID. So that disables the rule. We call this method "user-forced", because the admin purposely clicked a choice indicating that rule should be removed from the current rule set and not be loaded anymore (even after a restart). You can also user-force rule states on the RULES tab. There is a user-forced "enable" option to go along with the user-forced "disable" one.

If I enable all categories without modifying the actions, is that equal to which of the predefined ”policies”?

You are talking apples to oranges here. An IPS Policy is a special construct only available from the Snort Subscriber Rules. When the Snort rule creators make rule signatures, they add a special metadata tag to the signature that links the rule to an IPS policy. Literally inside the text of the rule a tag is created that links the rule to one or more IPS policies. A rule can belong to none, one; or multiple IPS policies. Also, for each policy, there is an associated metadata tag that provides a suggested "action" for the rule in that policy.

So for example, a given GID:SID signature might be assigned the following two IPS policies: IPS-Connectivity and IPS-Balanced. But when the rule is used with the IPS-Connectivity policy the suggested action is ALERT, and when the rule is used with the IPS-Balanced policy (a more restrictive one) the suggested action is DROP. So depending on which IPS Policy you selected on the CATEGORIES tab, the same rule could have two different actions (ALERT or DROP). The beauty of using IPS Policies is that most all of the investigation and legwork is done for you by the rule creators. They decide which rules are included in each policy, and what the suggested action should be for the rule in each policy. When you enable an IPS Policy, the GUI code will automatically determine which rules match that policy and load them. It will also automatically read the suggested action for the policy for each rule and change the rule actions for you.

When creating the final rules file, the Snort package processes things this way:

Load all the enabled categories the user has checked on the CATEGORIES tab.
Load and process any IPS Policy selection, if one is enabled.
Process the assigned SID managment conf files for the interface.
Automatically resolve needed flowbits rules and add them to the rules set.
Lastly, process any user-forced enable or disable GID:SID options (these are rules the user has clicked the "force a state" icon for on either the ALERTS or RULES tabs).

tsmalmbe

Case: If I choose "Policy Security" (which applies to my Snort rules not my ET Open Rules or Snort OPENAPPI Rules) and then add an enablesid that enables all snort_server -rules - is this a cumulative operation in a sense?

(btw, there is a typo at the category page "Snort OPENAPPI Rules" it should be OPENAPPID Rules I think)

bmeeks

@tsmalmbe said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

Case: If I choose "Policy Security" (which applies to my Snort rules not my ET Open Rules or Snort OPENAPPI Rules) and then add an enablesid that enables all snort_server -rules - is this a cumulative operation in a sense?

(btw, there is a typo at the category page "Snort OPENAPPI Rules" it should be OPENAPPID Rules I think)

Yes, that would be a cumulative operation.

By the way, use of the IPS-Security policy is fraught with the potential of many false positives in many environments. If you are thinking of using that policy level, you will likely need to suppress or disable a number of the automatically selected rules in order not to block legitimate traffic.

Thanks for the typo report. I will add it to my internal bug list for the next release of the package.

tsmalmbe

@bmeeks So now we are at a point where I have my interface setup as INLINE IPS, I have turned on "Block Offenders", I am using IPS Policy Selection "Security" and IPS Policy Mode "Policy". In addition, I have manually selected a a bunch of categories of "ET Open Rules" and All "Snort OPENAPPI Rules".

Next I did some SID Mgmt and created a dmz-enablesid that says "snort_" and dmz-dropsid that contains "snort_ emerging- openappid-", and finally a dmz-disablesid with "snort_deleted snort_os-mobile snort_os-solaris snort_os-windows snort_protocol-finger snort_protocol-nntp snort_protocol-scada snort_server-iis snort_server-mssql snort_server-oracle snort_x11".

As I have run this Interface and Snort in a very "rigorous" mode for a couple of years, I also have a veeery long suppress file.

So with this, I now use the Talos team "vision and strategy" for the actions on the Snort rules, have modified (disabled) some that is not relevant for this Interface and added what I find relevant.

QUESTION: But did I still get some of this wrong? If I "enable" something with the the dmz-enablesid configuration, it means that EVERY rule in that set turns into a state of "enabled". So in essence my dmz-enablesis should be a lot smaller than "snort_" - rather for instance "snort_server-mysql". That would imply I use the Talos team "vision and strategy" for what should be enabled in all other categories than "snort_server-mysql" - where I want to have everything enabled because I run MySQL databases on the DMZ.

QUESTION: Also just to understand I am doing this right - when using the IPS Policy Selection "Security" , the only way for me to see what is enabled is to go to the "DMZ Categories" page and click on an item under "Ruleset: Snort Text Rules" and then view the raw text file. As opposed to where I have now used enablesid to enable snort_server-mysql - which i can then manually review on the "DMZ Rules" page and choose it in the "Category Selection:" drop-down?

QUESTION: If I wanted to enable ALL wordpress-related sid's in "snort_server-webapp.rules" - how would I accomplish this? Manually sid-by-sid or some other way?

QUESTION: Did I get this right, is this now the "textbook" way of doing this, where I am utilising all the different options for me in setting this up?

tsmalmbe

A couple more.

QUESTION: "Packets matching DROP rules are simply discarded (dropped) and not passed to the host network stack." -> Does this imply, that whenever Snort kicks in and blocks I will NOT see these blockings in my firewall logs anymore?

QUESTION. In Inline mode, will I see a difference in the Snort logs between "just alerting" and "blocking" - referring to the Snort-rules by Talos which contain this information. The others (Emerging and Appid) work as usual I assume, if an alert is triggered, it will be blocked (even in Inline mode)?

tsmalmbe

Just putting this crosslink here for future readers - https://forum.netgate.com/topic/128480/how-automatic-sid-management-and-user-rule-overrides-work-in-snort-and-suricata

bmeeks

@tsmalmbe said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

@bmeeks So now we are at a point where I have my interface setup as INLINE IPS, I have turned on "Block Offenders", I am using IPS Policy Selection "Security" and IPS Policy Mode "Policy". In addition, I have manually selected a a bunch of categories of "ET Open Rules" and All "Snort OPENAPPI Rules".

Next I did some SID Mgmt and created a dmz-enablesid that says "snort_" and dmz-dropsid that contains "snort_ emerging- openappid-", and finally a dmz-disablesid with "snort_deleted snort_os-mobile snort_os-solaris snort_os-windows snort_protocol-finger snort_protocol-nntp snort_protocol-scada snort_server-iis snort_server-mssql snort_server-oracle snort_x11".

As I have run this Interface and Snort in a very "rigorous" mode for a couple of years, I also have a veeery long suppress file.

So with this, I now use the Talos team "vision and strategy" for the actions on the Snort rules, have modified (disabled) some that is not relevant for this Interface and added what I find relevant.

QUESTION: But did I still get some of this wrong? If I "enable" something with the the dmz-enablesid configuration, it means that EVERY rule in that set turns into a state of "enabled". So in essence my dmz-enablesis should be a lot smaller than "snort_" - rather for instance "snort_server-mysql". That would imply I use the Talos team "vision and strategy" for what should be enabled in all other categories than "snort_server-mysql" - where I want to have everything enabled because I run MySQL databases on the DMZ.

QUESTION: Also just to understand I am doing this right - when using the IPS Policy Selection "Security" , the only way for me to see what is enabled is to go to the "DMZ Categories" page and click on an item under "Ruleset: Snort Text Rules" and then view the raw text file. As opposed to where I have now used enablesid to enable snort_server-mysql - which i can then manually review on the "DMZ Rules" page and choose it in the "Category Selection:" drop-down?

QUESTION: If I wanted to enable ALL wordpress-related sid's in "snort_server-webapp.rules" - how would I accomplish this? Manually sid-by-sid or some other way?

QUESTION: Did I get this right, is this now the "textbook" way of doing this, where I am utilising all the different options for me in setting this up?

I will try to answer as many of these questions as I can understand. Some of them are very confusing to me, and thus I am not sure what you are actually asking about.

You can view the current "state" of your rules for an interface in two ways. One is via the CATEGORIES tab. But the other, better way, is to use the RULES tab. There you will find a drop-down selector at the top of the page labled Category. The choices available in that box reflect every rule category that is currently enabled in your configuration for that interface. When you select a category name from the list, the table at the bottom will populate with all of the rules from that category file. Icons will appear under the State and Action columns showing if the rule is default-enabled, default-disabled, or modified by a SID MGMT file. There is a legend at the top of the table explaining what each icon represents. Icons under the Action column indicate the current action keyword for the rule. The three available actions are ALERT, DROP or REJECT.

If you want to find and enable all rules that reference "wordpress" in some manner, that would be a job for the modifysid option on the SID MGMT tab. Unfortunately you can't limit the search by category. It's going to search all the files for matching strings. The syntax used in Perl Regular Expressions (regex). Learning that syntax is an art all unto itself .. .

For your other two questions, I'm sorry, but I really just don't understand what you are asking me.

bmeeks

@tsmalmbe said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

A couple more.

QUESTION: "Packets matching DROP rules are simply discarded (dropped) and not passed to the host network stack." -> Does this imply, that whenever Snort kicks in and blocks I will NOT see these blockings in my firewall logs anymore?

For traffic inbound on an interface, Snort sees the traffic and acts on it first, before the firewall layer. So if using Inline IPS Mode, which "blocks" by simply not forwarding a packet on to the rest of the kernel, should Snort drop a packet, then the firewall never sees it and thus won't block it nor log anything about it. You would need to look at the Snort ALERT tab which shows Snort's logs to find the dropped traffic. The log entry for dropped traffic will be printed in red text.

QUESTION. In Inline mode, will I see a difference in the Snort logs between "just alerting" and "blocking" - referring to the Snort-rules by Talos which contain this information. The others (Emerging and Appid) work as usual I assume, if an alert is triggered, it will be blocked (even in Inline mode)?

No, that is not how it works at all. With Inline IPS Mode, there are only three possible rule actions: ALERT, DROP or REJECT. The only two of those actions that result in traffic being blocked are DROP and REJECT. ALERT never, ever blocks traffic when using Inline IPS Mode. The difference between DROP and REJECT is that with REJECT the sending host (the one being blocked) is sent either a TCP RST packet (if using TCP), or an icmp-unreachable (if using another protocol). The tells the sending host its connection attempt was received but refused, so no use trying again. A DROP action simply discards the packet. It logs what it did in the log file the ALERTS tab reads and displays, but the sender of the dropped packet never knows what happened. Usually that means the sender will try a few more times before giving up and showing the user at the other end of the connection some type of error.

tsmalmbe

When selecting the Policy option I was expecting the drop-down onthe Rules tab to contain the Categories - but it only contains the item IPS Policy - Security. This was a bit confusing and actually one of my questions. The question was really badly written, sorry for that. The page - with 17000+ rules - takes ages to load, but I guess that is not something easily fixable.

The other question was simply this (and I present it as a statement now, not a question). Let's assume a category in Emerging. In legacy mode I only need a category to alert, and that will essentially block. When turning on inline mode, the rules in the category will be alert only so for me to get the same functionality as in legacy mode of having an Emerging category blocking, I need to add a file in drop SID list containing "emerging_". Then my chosen Emerging categories will block also in inline mode.

Please explain to me why I would use the modifysid to enable ALL wordpress rules, would that not be the job of enablesid with a (for me yet unknown) regular expression? I am not trying to modify the rule, just enabling it based on free text in the description (if I understood this correctly).

I appreciate your patience. I try to write my questions and thoughts in a way that will server future readers.

bmeeks

@tsmalmbe said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

When selecting the Policy option I was expecting the drop-down onthe Rules tab to contain the Categories - but it only contains the item IPS Policy - Security. This was a bit confusing and actually one of my questions. The question was really badly written, sorry for that. The page - with 17000+ rules - takes ages to load, but I guess that is not something easily fixable.

When you choose to use an IPS Policy, the GUI code on the CATEGORIES tab blocks further choice of other Snort rules as it is presumed you are giving that responsibility over to the policy. Thus the RULES tab sees only the collection of rules encompassed by the selected policy. Yes, through a fluke in the GUI code, you can still use SID MGMT to "force" additional Snort rules into the final product that are not part of the chosen Snort IPS Policy. If you want to see the actual rules in use on the interface after all the processing logic is done, in the Category drop-down is an entry called "Active Rules" - if I remember the name correctly. That choice loads all of the enabled rules that will be used on the interface. But it will be even larger as the Snort built-in rules will also be included in the list, so it will take several seconds or even minutes to fully load and render the page.

The other question was simply this (and I present it as a statement now, not a question). Let's assume a category in Emerging. In legacy mode I only need a category to alert, and that will essentially block. When turning on inline mode, the rules in the category will be alert only so for me to get the same functionality as in legacy mode of having an Emerging category blocking, I need to add a file in drop SID list containing "emerging_". Then my chosen Emerging categories will block also in inline mode.

True, but literally what you are doing is changing the action for the rules matching the criteria in your SID MGMT file from ALERT to DROP. I prefer to always use the term "drop" when speaking of Inline IPS Mode to clearly distinguish it from Legacy Mode. That's exactly the same thing the GUI code does for the rules that match the chosen IPS Policy. It simply searches through all of the snort rules files and finds every GID:SID that has a matching IPS Policy tag (i.e., a tag matching the chosen policy). It then changes the action of matching rules to the value prescribed in the IPS Policy metadata tag for each rule, and then adds the rule to its list of "enabled" rules to be loaded by Snort.

Please explain to me why I would use the modifysid to enable ALL wordpress rules, would that not be the job of enablesid with a (for me yet unknown) regular expression? I am not trying to modify the rule, just enabling it based on free text in the description (if I understood this correctly).

Perhaps I misunderstood your question. I thought you wanted to find rules that had a particular keyword in their signature and change their action, because I don't recall any rules category file called "wordpress". So for example, if I want to find all rules whose signature MSG field contained something about "wordpress", then only the modifysid logic can do that. It is the only SID MGMT "function" that looks at the full text of each rule's signature. The other SID MGMT "functions" only look for one of two things: (1) the category file name, such as emerging-scan; or (2) the GID:SID. That's it. The enablesid, disablesid, dropsid and rejectsid logic only looks for those two fields. It is not looking at the MSG field in a rule. Only modifysid looks into the MSG field of a rule to search for matches.

I appreciate your patience. I try to write my questions and thoughts in a way that will server future readers.

Some of your questions lead me to think perhaps you have not actually studied the raw text of the IPS Policy rules. If you have not actually seen the metadata tags I've been discussing, then go to the RULES tab and select your IPS Policy in the Category drop-down. After the rules finish loading on the page, click on the GID:SID value for a rule, or double-click the row, to open the raw text in a pop-up modal dialog. Read the entire text of the rule signature. Look for the IPS Policy metadata tags. You will see them listed. And for many of the rules, you will see multiple tags associating the rule to more than one policy. And depending on the particular rule you choose to view, you may also see different rule actions for the different policy matches. So when you "select" an IPS Policy, all that really does is tell the GUI code to load every single Snort rule into a gigantic list in memory and then search for those policy metadata tags. It selects rules from the list that have an IPS Policy metadata tag matching the policy you specified. Then also, as it copies that rule over to the "enabled list" in memory, it changes the rule's action keyword to match what is suggested by the IPS Policy metadata tag. And not every single Snort rule has an IPS Policy metadata tag in it. Most do, but some do not. So those rules would never get selected as part of a policy.

brtan

@bmeeks , thanks for your detailed instructions. This is what I have done:
a) I have pfsense 2.6
b) snort 4.1.6 on my LAN interface
c) Applied "Inline Policy" to block offenders
d) I used "Connectivity" category
d) My connection to my home devices via Anydesk is blocked as expected

Questions:

I want to disable the rule that blocked/dropped/rejected the connection but I can't find any such rule in the alert logs via Alert Log View Filter. How can I find the rule that's blocking my connection to Anydesk?
If I do find such rule, I believe I should be doing the following steps in SID management
a) Create a dropSID.conf
b) Add in the the pair of GEN_ID:SID in that file
c) Place in under the "Disable SID" List
d) Rebuild the LAN

Thanks !

terry.c

@bmeeks Hi, thanks for a great explanation and for taking the time to answer everyone's questions.

Do they still recommend enabling SNORT on the LAN/VLAN interface? To clarify, you mentioned snort working before the pfSense firewall? Therefore there's no need to enable on the WAN?

And, nowadays, if we choose to use SID, do we have to include .rules in the SID Auto-Management List Editor when listing the rules?

Also, could you please discuss Choosing the Networks Snort Should Inspect and Whitelist under the SNORT INTERFACES, WAN or LAN SETTINGS tab? What that does and when and how to configure?

Thanks again!
Terry

bmeeks

@terry-c said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

@bmeeks Hi, thanks for a great explanation and for taking the time to answer everyone's questions.

Do they still recommend enabling SNORT on the LAN/VLAN interface? To clarify, you mentioned snort working before the pfSense firewall? Therefore there's no need to enable on the WAN?

Yes, I still suggest putting your Snort (or Suricata) instances inside the firewall perimeter on your LAN and other internal interfaces for most setups. Snort and Suricata receive network packets directly from the NIC driver BEFORE they hit the pf packet filter firewall engine. This is true no matter which interface (WAN or LAN) the IDS/IPS instance runs on. So, when talking about the WAN, there is very little benefit to putting Snort or Suricata there as it will be busy intercepting and analyzing traffic that the next step of packet processing- the pf packet filter- is probably going to drop via a default rule anyway. That would mean burning CPU cycles for zero benefit.

And, nowadays, if we choose to use SID, do we have to include .rules in the SID Auto-Management List Editor when listing the rules?

I don't fully understand this question. You seem to be mixing up two quite different concepts here. SID (Signature ID) is the unique serial number identifier for each rule used by an IDS/IPS. The folks who write rules tend to group them into logically related categories by virtue of including those SIDs in a common *.rules file. As an example, the Emerging-Scan.rules file contains a collection of rule SIDs that work to detect various types of scans. How you choose to use a collection of SIDs or groups of *.rules files is determined by what you want to accomplish. Using SIDs by themselves lets you be more selective than using the rules file category name would be.

Also, could you please discuss Choosing the Networks Snort Should Inspect and Whitelist under the SNORT INTERFACES, WAN or LAN SETTINGS tab? What that does and when and how to configure?

Short answer here is DO NOT touch this or change it from the default unless you fully understand how it works and what it is for.

There is information about HOME_NET and EXTERNAL_NET to be found on Google. Those terms are used in all variations of the Snort and Suricata packages whether used on pfSense or not. The simplest explanation is the HOME_NET variable contains all the interface IP and subnet addresses that you want to protect. EXTERNAL_NET contains everything NOT defined as being part of HOME_NET (usually). This is most commonly done by defining EXTERNAL_NET this way in the configuration file:

$EXTERNAL_NET = !$HOME_NET

where the leading exclamation point is the logical NOT operator.

Getting these two variables properly set up is critical because many of the rules use $HOME_NET and $EXTERNAL_NET as conditionals for determining if a rule should trigger. Examine some of the text of the rules and you will see how those variables are used. If not correctly set up, then rules will not trigger as expected because that network conditional will not match what the rule is written to look for.

Snailkhan

@bmeeks thanks alot for all the replies these are wonderfull and give perfect explainations to all questions. i have spent my half day reading and experimenting with them to understand these things.

I am maintaining cisco FTD based environment and have got few questions.

1: It seems that snort is processed first before pf firewall so wont it be good to have the firewalls rules evaluated first as they are small compared to ips rules. just like ftd does i.e. lina engine which is the asa acts first and then the ips acts.

2: you mentioned that not all snort rules have the ips policy meta data information so wont we miss if using one of the ips template ? as non of the ips template will have those rules lacking metadata enabled ?

3: Where can i see such rules that do not have the policy meta data tag ?

4: On the interface under the Rules Tab, Category selection "IPS Policy- Security" it lists a blob of all rules. cant it show them further categorized based on various apps that its protecting ? like in cisco ftd it shows them in categories ?

I could have opened a new thread but this is such a wonderfull detailed thread and serving as a good reference that i hope anweres to these questions will help others as well.

A million thanks

bmeeks

@Snailkhan said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

@bmeeks thanks alot for all the replies these are wonderfull and give perfect explainations to all questions. i have spent my half day reading and experimenting with them to understand these things.

I am maintaining cisco FTD based environment and have got few questions.

1: It seems that snort is processed first before pf firewall so wont it be good to have the firewalls rules evaluated first as they are small compared to ips rules. just like ftd does i.e. lina engine which is the asa acts first and then the ips acts.

This is not possible because of the way the network stack is plumbed in FreeBSD. This is why I now recommend users put their IDS/IPS instances on internal interfaces such as the LAN. Otherwise, you waste CPU resources scanning inbound WAN traffic that is most likely just going to be dropped anyway by the default DENY rules in place on the WAN interface.

2: you mentioned that not all snort rules have the ips policy meta data information so wont we miss if using one of the ips template ? as non of the ips template will have those rules lacking metadata enabled ?

Not Snort VRT rules -- rather Emerging Threats and any other rules not produced by the Snort Vulnerability Research Team (VRT). Most all rules produced by the Snort VRT include IPS policy metadata. It's only third-party rules such as ET and others that lack IPS policy metadata. But there may also be a handful of Snort VRT rules where the team chose not to add IPS policy tag metadata. Why they do or do not for a particular rule is question that would have to be submitted to them. There is no way within the GUI code to "find" these particular rules.

But when you choose to utilize an IPS Policy, you are trusting the judgement of the Snort VRT to tag what is really relevant to the chosen policy. So, the fact that some Snort rules might be omitted is okay when viewed in that context.

3: Where can i see such rules that do not have the policy meta data tag ?

Answered above. If the rule is not from the Snort VRT package (meaning Registered User or Subscriber), then it lacks IPS policy metadata.

4: On the interface under the Rules Tab, Category selection "IPS Policy- Security" it lists a blob of all rules. cant it show them further categorized based on various apps that its protecting ? like in cisco ftd it shows them in categories ?

To keep the GUI code simple and manageable, it simply filters by the chosen IPS policy data and displays all the rules matching that policy. It attempts no further breakdown.

I could have opened a new thread but this is such a wonderfull detailed thread and serving as a good reference that i hope anweres to these questions will help others as well.

A million thanks

Snailkhan

@bmeeks Again a lot of thanks for the prompt response.
Coming from Cisco FTD end I have couple of doubts left to be confirmed.
In cisco ftd world we create an access control rule and then attach specifc ips policy which can be either the default template (security,connectivity or max detection etc) or we can create one out of above ones .. in either case we are able to see all the rules whether the ips policy has it set to drop,alert or ignore.. apart from trusting the Snort VRT team can we see in pfsense snort version as cisco offers there all rules ?

Also in pfsense we can use only one policy for entire interface (source based) while its good and simple but can we use different policies for different source destination pairs ?

I will greatly appreciate any reading material related to what benefits one style of implementation offers over the other. ie. one ips policy for all traffic from lan vs customized policy for each source destination pair.

Regards

bmeeks

@Snailkhan:
It is not possible in pfSense to tie IDS/IPS rules or policies to the pf firewall engine. Thus it is impossible to tie IDS/IPS rules to IP source or destination pairs as evaluated by the firewall engine. That's just not how pfSense is designed. If you need this level of granularity, then pfSense is not the product for you. The best you could do is write your own custom IDS/IPS rules where you customize the Source/Destination fields of each IDS/IPS rule. I seriously doubt you want to get into that level of maintainence.

Snort is an add-on volunteer-maintained package for pfSense. It is not baked into the operating system nor into the design of the firewall. Therefore its capabilities will be nowhere near as flexible as say a customized Cisco hardware/software solution might be.

Later Edit: but compare the price you pay for pfSense and its Snort package to what the Cisco solution costs you . Many times compromises are necessary when taking advantage of the "free" option.