@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_NETwhere 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.