Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions
-
When will Snort 4.0 roll our? Is cxbge the family tree for bge interface?
-
@NollipfSense said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
When will Snort 4.0 roll our?
Snort 4 is already available for pfSense-2.5 and plans are for it to stay there, meaning that it will only be available with pfSense 2.5 both now in DEVEL and later when it goes RELEASE. There are currently no plans to release Snort 4.0 for pfSense 2.4.4.
@NollipfSense said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
Is cxbge the family tree for bge interface?
No, I do not believe they are the same family.
-
Hi, I have an Atom 3558 processor with Intel X553 nics (aka ix). Do you know if these nics will be supported with Inline IPS Mode given they're the same nics on Netgate devices.
-
@crazybrain said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
Hi, I have an Atom 3558 processor with Intel X553 nics (aka ix). Do you know if these nics will be supported with Inline IPS Mode given they're the same nics on Netgate devices.
Only if the FreeBSD developer for that NIC driver family makes it netmap compatible. The pfSense guys take whatever comes down from FreeBSD when it comes to drivers. To my knowledge they do not write any of their own drivers (nor do they modify any).
The following NIC families currently have netmap support in FreeBSD and hence pfSense: em, igb, ixgb, ixl, lem, re or cxgbe. If your NIC driver is not from one of these families, netmap and Inline IPS Mode is not going to work properly, if it works at all.
Intel NICs for the em and igb family are quite cheap. If you want inline IPS mode, consider swapping your NIC to one of those.
-
"The new Inline IPS Mode of Snort will only work on interfaces running on a supported network interface card (NIC). Only the following NIC families currently have netmap support in FreeBSD and hence pfSense: em, igb, ixgb, ixl, lem, re or cxgbe."
Do you know if vmx will be supported? Many of us use pfSense inside of ESXi.
-
@jasonsansone said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
"The new Inline IPS Mode of Snort will only work on interfaces running on a supported network interface card (NIC). Only the following NIC families currently have netmap support in FreeBSD and hence pfSense: em, igb, ixgb, ixl, lem, re or cxgbe."
Do you know if vmx will be supported? Many of us use pfSense inside of ESXi.
I believe the vmxnet3 driver will work with Inline IPS mode. If you have issues, you could always change the virtual machine VMX file to use the e1000 driver instead (which will force em driver operation).
-
@bmeeks Thank you. I haven't tested 2.5 yet so I don't know, but I wanted to ask before I got there.
-
Just trying to figure out the policy and rule action bits. I'm using Snort Subscriber rules and OpenAppID. To make sure I'm understanding correctly... the IPS Policy settings only apply to the Snort Subscriber rules, which I've already been using anyway. But to use Inline mode, I'd need to force rule actions on the OpenAppID rules, either through SID Management, the Rules tab, or changing actions based on alerts, correct?
Manually managing rules and actions can be a pain over time, as new rules are created for new things... would it be possible to have a default that applies to all rules in a category? Like for example, "openappid-hacktools.rules"... pretty sure I'd not want those ever... but if a new rule is created for a new tool a month from now, I'd have to manually add that SID to be dropped, correct? Unless I keep up on these rules on a regular basis, things could start getting through since they'd only be alerting instead of dropping.
I'm not running 2.5 yet (will likely wait for release, whenever that comes to be), but just want to make sure I know what I'm doing when the time comes!
-
@virgiliomi said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
Just trying to figure out the policy and rule action bits. I'm using Snort Subscriber rules and OpenAppID. To make sure I'm understanding correctly... the IPS Policy settings only apply to the Snort Subscriber rules, which I've already been using anyway. But to use Inline mode, I'd need to force rule actions on the OpenAppID rules, either through SID Management, the Rules tab, or changing actions based on alerts, correct?
Manually managing rules and actions can be a pain over time, as new rules are created for new things... would it be possible to have a default that applies to all rules in a category? Like for example, "openappid-hacktools.rules"... pretty sure I'd not want those ever... but if a new rule is created for a new tool a month from now, I'd have to manually add that SID to be dropped, correct? Unless I keep up on these rules on a regular basis, things could start getting through since they'd only be alerting instead of dropping.
I'm not running 2.5 yet (will likely wait for release, whenever that comes to be), but just want to make sure I know what I'm doing when the time comes!
Correct. There is no IPS Policy metadata encoded into the OpenAppID rules. The OpenAppID rules were written by an independent third-party volunteer contributor, and the tarball file is currently hosted by the pfSense team on their infrastructure.
Just to be sure everyone understands, there are two parts of OpenAppID. There is the internal plumbing provided by the Snort development team (actually Cisco/Talos). Those plumbing parts are called the OpenAppID stubs. They are required for OpenAppID detection to work, but installing just those would mean nothing: no alerts on OpenAppID stuff. In order to get alerts or drops, you must have text rules that make use of the appid keyword that the OpenAppID stubs provide. These text rules are what the third-party volunteer contributor provided for pfSense users. You can also write your own OpenAppID text rules. You can put them in the Custom Rules category.
So back to your original question. You will need to manually manage your OpenAppID rules, but you can use SID MGMT features for that. Back when he created them, I asked the OpenAppID rule author to divide his rules into categories much like the other Snort and Emerging Threats rules are divided. He did that, and that's why you see categories of OpenAppID rules on the CATEGORIES tab when OpenAppID is enabled. You can use SID MGMT to control those rule categories by, for example, changing a category to DROP (if using Inline IPS Mode) or enabling or disabling an entire category by putting the category name in the appropriate SID MGMT conf file. In that case, if filtering by say category name, any rule change within that specific category would be covered (for instance, if a new rule were added). However, if an entire new category were added, then you would need to take manual action by going to the SID MGMT tab and creating a new filter or editing an existing one to match the new category..
Of course there is always the option of managing rules individually on the RULES tab or by using the icons provided on the ALERTS tab.
Effectively managing an IDS/IPS requires fairly constant vigilance by the admin. And you would need to keep abreast of the latest rules updates. The Snort team summarizes each Snort Subscriber Rules update on their blog here: https://blog.snort.org/.
-
Hi!
Can you please add options to "Drop All" ?
-
@Simbad said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
Hi!
Can you please add options to "Drop All" ?
What do you mean by "Drop All"? If you mean change all rules to DROP, that is not a good policy in my view and basically defeats the whole purpose of having selectivity between ALERT rules and DROP rules. For large numbers of rule action changes, I suggest you use the SID MGMT tab and the rule selection filtering/matching features available there.
-
Thanks for the answer, ... I already have my policy of rules that meets and effectively protects the network. With such a policy, I successfully protect the network and follow the rule: block everything except what I allow.
With this feature, it would be easier to maintain the network / rules in the new function.
-
@Simbad: my reply was really a question back to you. How would you use a "Drop All" option if available, and where should the option be shown (on what tab)?
The point I was making with my question is that I don't see the utility of a feature that sets all rules to DROP because that is not usually a good course of action in my view. The whole point of having ALERT versus DROP versus REJECT rule options with Inline IPS Mode is that it gives the security admin a mechanism to improve connectivity while still gaining insight into questionable or suspicious activity. If every rule was DROP, then you are back to the way Legacy Mode works where every alert is a block (the functional equivalent of DROP). You would want some rules to just ALERT so you could check the unusual condition, and then decide if it was truly malicious and warranted a DROP, or if it was just a false positive. Having a good mix of ALERT and DROP improves connectivity for clients and still gives the security admin insight into the traffic types on his network.
I think a lot of pfSense users of the IDS/IPS packages (both Snort and Suricata) fail to appreciate the true role of an IDS/IPS (especially an IPS with blocking capability). They seem to think every rule that triggers represents some banking malware trojan and needs to trigger a block that persists forever (yes, I'm exaggerating a little bit, but my general point is valid). That is definitely not the case. Many of the rules are actually designed more as a "hey, check this out" sort of rule because many times the traffic that triggers the rule is benign in most environments. A perfect example is one of the ET-Policy rules. It alerts (and would block if set to DROP or using Legacy Mode Blocking) anytime it sees a traffic stream containing an EXE file. Well, that will kill most any Microsoft Security Hotfix or Service Pack download if that rule is set to DROP. Do you really want that? You would only want that if you were a corporation that ran a Microsoft shop (Active Directory and all), and you had your own internal WSUS infrastructure where you wanted users to only get updates from there.
That's not the case for the vast majority of pfSense users. So giving them an upfront in-your-face option to set all rules to DROP would just give them an easy way to bring their entire network to its knees ... . Then they would be posting here complaining about all the various apps and services that are not working on their network after they installed Suricata or Snort. The key takeaway in my opinion is that IDS/IPS rules are not like anti-virus signatures. With an AV client, you can be near 100% sure that any virus signature that triggers represents a bad thing so you want the code blocked or quarantined. That's not the case with IDS/IPS rules. A given rule is not necessarily detecting something evil, so having it always block or drop may be just irritating instead of improving security.
So bottom line is I am going to need a lot of "convincing" to persuade me to add a feature like that. I see it causing more issues rather than solving problems.
-
@bmeeks said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
I think a lot of pfSense users of the IDS/IPS packages (both Snort and Suricata) fail to appreciate the true role of an IDS/IPS (especially an IPS with blocking capability). They seem to think every rule that triggers represents some banking malware trojan and needs to trigger a block that persists forever (yes, I'm exaggerating a little bit, but my general point is valid). That is definitely not the case. Many of the rules are actually designed more as a "hey, check this out" sort of rule because many times the traffic that triggers the rule is benign in most environments. A perfect example is one of the ET-Policy rules. It alerts (and would block if set to DROP or using Legacy Mode Blocking) anytime it sees a traffic stream containing an EXE file. Well, that will kill most any Microsoft Security Hotfix or Service Pack download if that rule is set to DROP. Do you really want that? You would only want that if you were a corporation that ran a Microsoft shop (Active Directory and all), and you had your own internal WSUS infrastructure where you wanted users to only get updates from there.
So... while I agree with you on this regarding general IDS/IPS rules, like the regular Snort and ET rules, things like OpenAppID rules are more likely to want a whole category blocked, not unlike a web filter that can block entire categories of websites with just a click. I have no interest in any "hacktools" being allowed to access the internet so I'm happy to block that whole category. Same with "p2p_file_sharing".
My concern is that I will have to go into each individual rule for 30+ rules in multiple categories to change their actions all to Block. Yeah, I'll only need to do it once (after that first time, it's just maintenance, which will probably be just one or two rules at a time), but that's still a time-consuming task. Having the ability to mass-change all rules in a category would make this much easier.
As a possible compromise to one setting that changes all rules in a category... how about allowing changing the action directly from the list of rules? Rather than clicking the Action icon and selecting an action in a dialog, put a drop-down right on the main list instead. At least then I could keyboard the changes (tab, down, down, tab, down, down, etc.) instead of having to click on different things. Plus, then you can eliminate the need for those additional legend icons, since the element would clearly indicate the action.
-
It's been a while since I've looked (I don't use the OpenAppID rules in my setup), but I thought the OpenAppID rules are divided into categories with each category having its own filename. So you could use SID MGMT to modify an entire category of OpenAppID rules the same as you would for an Emerging Threats or Snort Subscriber category.
Creating a "Drop All" button would be easy in terms of coding, but I really think it would just lead folks into shooting themselves in the foot. I could perhaps create a category "Drop All" button to match the current "Enable All" and "Disable All" buttons. Is that what you meant by "Drop All"? I initially thought you meant a button to change all rules in all categories to DROP. Based on your lastest reply, maybe I misunderstood your original request.
I will look into a multiple select feature on the RULES tab, but coding something like that is not as straightforward as it may seem at first glance.
Finally, I will add that using the SID MGMT feature is much more efficient in terms of configuration storage space. When you make a change to a rule's action or state on the RULES tab (or the ALERTS tab), the specific GID:SID of that rule is stored in a long string of values separated by the pipe symbol ( | ) in the
config.xml file
. As originally envisioned where the user made changes to maybe several dozen rules, that method is fine. But if we start talking about folks wanting changes to several thousand rules, that begins to take up a lot of space in theconfig.xml
file. So consider that you want to set the category openappid-social-media rules to all DROP. For this example, assume there are 100 rules in there. Changing each one to DROP on the RULES tab would create a pretty large string inconfig.xml
because you have the GID:SID value of each rule along with the pipe separator/delimiter. Using SID MGMT, on the other hand, would require just this single line in thedropsid.conf
file:openappid-social-media
That's a lot more efficient in terms of storage space within
config.xml
.I keep pushing the SID MGMT tab because that is a really efficient way to manage rules. You really shoud make all rules changes there instead of using the buttons/icons on the RULES or ALERTS tabs. And if you were running Snort on any other platform besides pfSense (which is the only platform out there that has a GUI for managing Snort), you would have to use SID managment conf files in a command-line tool such as PulledPork to manage your rules (or else manually edit the text rule files). I really intended for the icons on the RULES tab to be used for a tiny handful of one-off quickie rule modifications to state or action, and the SID MGMT tab to be used for changes to large groups of rules (say more than five per category).
-
I guess I've never used SID MGMT, so I suppose what you're saying is possible, since you're the one that made the package.
I tend to be more GUI-oriented, so clicking buttons and whatnot is more intuitive to me than a bunch of different config files. If it's really that easy to just add a line to a config file in SID MGMT to have all rules in a category have a drop action, I'd be happy with that then.
-
@virgiliomi said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
I guess I've never used SID MGMT, so I suppose what you're saying is possible, since you're the one that made the package.
I tend to be more GUI-oriented, so clicking buttons and whatnot is more intuitive to me than a bunch of different config files. If it's really that easy to just add a line to a config file in SID MGMT to have all rules in a category have a drop action, I'd be happy with that then.
It is that easy. Just create a file named
dropsid.conf
(or any name, the name does not matter). Then add the category names (visible on the CATEGORIES tab) or individual GID:SID rule ID pairs. Then save the new file. At the bottom of the tab, assign the list you just created to the DROPSID drop-down. Click the checkbox over on the far left (the "Rebuild" box) to force the creation of a new rules file for that interface and have Snort be sent a "reload rules" command. Open up the sample lists on the SID MGMT tab to see examples of the various selector syntax you can use to choose rules for modification. You can change rule state, action and even content using features on that tab. -
For Snort Inline IPS, are the same config settings needed for netmap like in the Suricata post here? (https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces)
-
@rebytr said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
For Snort Inline IPS, are the same config settings needed for netmap like in the Suricata post here? (https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces)
Likely "yes". Snort simply opens the netmap device and then depends on the kernel settings for any additional configuration options. That's the same way Suricata works. So those tuning parameters outlined in the post you linked may prove helpful depending on the specific NIC hardware you have.
-
@jasonsansone vmxnet3-driver is working without problems in inline mode. i am running this setup since several weeks without problems
-
@bmeeks Thanks a lot for your work. I was missing that feature for a long time.
I have one question regarding the payload dump-option (barnyard-settings).
Is this feature working? I am not getting any dumps for download in the alert-section. Thanks in advance!BR
-
@dotlike said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
I have one question regarding the payload dump-option (barnyard-settings).
Is this feature working? I am not getting any dumps for download in the alert-section. Thanks in advance!BR
I honestly do not know. I have not run Barnyard2 on my personal system for several years. The package is no longer really supported on FreeBSD (and I'm not sure it is supported anywhere anymore). By "supported" I mean updated and maintained. The only updates to the package in FreeBSD Ports have been done by the FreeBSD team themselves and involved only minor tweaks to the Makefile for various ports tree dependency issues. Nothing has been touched in the actual Barnyard2 source code in years. I know that it has issues with more recent versions of MySQL client.
So long lead-in to say Barnyard2 seems to be slowly decaying on the vine. The new direction in the Snort3 branch is JSON logging (much like Suricata has).
As for the current situation in pfSense, you can examine the Barnyard2 configuration file for the interface to see what is set in there. You can find the file in
/usr/local/etc/snort/snort_xxxx
(where thatxxxxx
will be a random UUID combined with the physical interface name). -
If only 2 or 3 rules in a category need to be ALERTed, the rest need to be DROP, what will be the easiest way to set up?
-
@pfcode said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
If only 2 or 3 rules in a category need to be ALERTed, the rest need to be DROP, what will be the easiest way to set up?
Use SID MGMT features to set the category to DROP. Then go to the RULES tab, select that category in the drop-down selector and find the 2 or 3 rules you want to be ALERT and change the action of just those rules using the icon under the ACTION column. Changes you make to individual rules on the RULES tab take precedence over all other modifications. Those are the last changes applied to rules.
-
@bmeeks Thank you.
-
This post is deleted! -
@bmeeks Is it also possible to mark packets with the new Inline IPS Mode? This would allow the Traffic Shaper to apply rules based on the hostname, for example.
-
@tbr45 said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
@bmeeks Is it also possible to mark packets with the new Inline IPS Mode? This would allow the Traffic Shaper to apply rules based on the hostname, for example.
No, you can't mark packets. The binary can only pass them, reject them or drop them. A reject sends a notice back to the sender so it will not keep trying. A drop sends back nothing to the sender (the packet just appears to have fallen into a blackhole).
-
I am experiencing very strange behavior . Manged to track it down to one of emerging-scan.rules.
alert tcp $HOME_NET any -> any 445 (msg:"ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection"; flags: S,12; threshold: type both, track by_src, count 70 , seconds 60; metadata: former_category SCAN; reference:url,doc.emergingthreats.net/2001569; classtype:misc-activity; sid:2001569; rev:14; metadata:created_at 2010_07_30, updated_at 2017_05_11;)Rule was set by Automatic SID managed to DROP, however no alert appeared in Alert List. But until I changed action for the rule from DROP to Alert, I could not get access to remote SMB share...
-
@murzik said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
I am experiencing very strange behavior . Manged to track it down to one of emerging-scan.rules.
alert tcp $HOME_NET any -> any 445 (msg:"ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection"; flags: S,12; threshold: type both, track by_src, count 70 , seconds 60; metadata: former_category SCAN; reference:url,doc.emergingthreats.net/2001569; classtype:misc-activity; sid:2001569; rev:14; metadata:created_at 2010_07_30, updated_at 2017_05_11;)Rule was set by Automatic SID managed to DROP, however no alert appeared in Alert List. But until I changed action for the rule from DROP to Alert, I could not get access to remote SMB share...
The only possibility I can imagine that would cause a DROP action to not appear on the ALERTS tab (highlighted in RED to indicate a drop) is if the alert line from the log did not parse correctly. The code on the ALERTS tab reads the alert log for the interface line-by-line and parses each line into a set of fields delimited by commas. If a line does not parse out the correct number of fields, it is discarded and not displayed on the ALERTS tab.
To see if this is the case, get to the command line in pfSense either directly via the console or remotely via SSH. Then change to the correct Snort log interface directory in
/var/log/snort
. There will be a separate sub-directory under that path for each configured Snort interface. Once in the correct sub-directory, usegrep
to search thealert
file for the rule SID in question to see if it is in there. Post back here with your findings. If the SID is there but is not showing on the ALERTS tab, then it is a parsing issue I need to look into. If you don't see the SID in thealert
file for the interface, then that would be a binary issue you would take up with the upstream Snort team. -
@bmeeks
I think that is a binary issue. Alert is not in alert file.
Thanks... -
@crazybrain I believe the Atom 3558 with ix NIC's do work with netmap.
I'm running Suricata with inline no problem. There is also a command you can run (cant recall) and it shows its netmap enabled.Now just waiting for pfSense 2.5 to drop.
@bmeeks can/will you be able to release Snort v4 on pfSense 2.4.5 release? Or is it only when 2.5 comes out?
-
@N0_Klu3 said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
@bmeeks can/will you be able to release Snort v4 on pfSense 2.4.5 release? Or is it only when 2.5 comes out?
Only when 2.5 comes out. The inline netmap option requires the netmap library from FreeBSD 12, and pfSense-2.4.5 is still FreeBSD 11 (although it is 11-STABLE).
-
So inline mode won't work with vlans? Even though they are hosted on a supported nic? what about a lacp lagg?
Should inline mode work on Intel 82576 or a Intel I340-T4?
I don't mean to seem lazy but this is the best write up I've found and I wouldn't mind listing some tested hardware here.
Thanks for all the great info!
-
@chromefinch said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
So inline mode won't work with vlans? Even though they are hosted on a supported nic? what about a lacp lagg?
Should inline mode work on Intel 82576 or a Intel I340-T4?
I don't mean to seem lazy but this is the best write up I've found and I wouldn't mind listing some tested hardware here.
Thanks for all the great info!
VLANs may work now in FreeBSD-12.3/STABLE. I have not tested them. pfSense-2.5 DEVEL moved to FreeBSD-12.3/STABLE a little while back. NIC drivers (the majority of them, anyway) in FreeBSD 12.3 have been ported to a new API called iflib. The iflib system handles all of the netmap stuff now for NICs that use iflib, and thus the NIC hardware driver is not burdened with that code development. The iflib subsystem is also supposed to support features such as VLANs, but there can still be issues with certain NICs that perform hardware-level VLAN tag manipulations.
So a long answer to basically say "I don't know for sure, but VLANs may work with some NICs now in pfSense-2.5 DEVEL with the Snort-4.x package using Inline IPS Mode".
The answer to your other question about netmap support in a given NIC depends on whether or not that hardware vendor migrated their driver over to iflib. Many have, a few have not per my understanding. And even some of those that have migrated may not have ported all versions of their hardware. So far as I know, most of the Intel NICs are ported over to iflib.
-
@bmeeks Thank you for your hard work and response! You've helped me in the past!
amazing!
So there shouldn't be an issue with running my wan in inline mode and my dmz vlan in legacy correct?
Most of my work with pfsense is remote so it is difficult to make risky changes, but i'd really like inline mode up on at least the wan.
Thanks again,
-
@chromefinch said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
@bmeeks Thank you for your hard work and response! You've helped me in the past!
amazing!
So there shouldn't be an issue with running my wan in inline mode and my dmz vlan in legacy correct?
Most of my work with pfsense is remote so it is difficult to make risky changes, but i'd really like inline mode up on at least the wan.
Thanks again,
Yes, you can run your LAN in Legacy Mode and WAN in Inline IPS Mode if desired. However, in my view it is usually more efficient in terms of resource utilization to just put the IDS/IPS on the LAN side (or DMZ and LAN, etc., if you have multiple internal interfaces). My reasoning is thus:
-
The WAN interface on pfSense will, by default, block all unsolicited inbound traffic. So having Snort detecting and blocking something the firewall is likely to block anyway is not beneficial IMHO.
-
The IDS/IPS sits between the firewall engine and the physical interface. So that means on the WAN it only sees traffic from your internal hosts after NAT rules are applied. That means in most cases every internal host will show up in WAN alerts as having the public IP address of the firewall. That is not helpful when trying to track down a problematic internal host.
-
If you have a properly configured firewall and have not installed a lot of extra "stuff" on it, then it has an extremely small attack surface and is pretty well "hardened" against attack. Snort or Suricata out front on the WAN is not going to really offer much additional protection- if any. So couple this fact with the items I mentioned in #1 and #2 above and you can see why I recommend putting the IDS/IPS on the internal interfaces only.
But there is no harm in using the setup you propose, but there are more efficient ways to consider configuring your setup.
-
-
@bmeeks That makes sense,
I host a small site and a few apps with pfblocker for geofencing.
Would it still be a good idea to disable the ips on the wan with those services running?I am trying to sort out another issue with port mirroring for Security Onion as I keep getting zeek/bro notices telling me there is packet loss over the pfsense port mirror.
In your experience, how is the port mirroring performance in pfsense compared to Cisco's port span?
Thanks again, it's good talking to a master!
-
@chromefinch said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:
@bmeeks That makes sense,
I host a small site and a few apps with pfblocker for geofencing.
Would it still be a good idea to disable the ips on the wan with those services running?To answer that question, trace a network packet from the Internet to your internal web server. Doesn't that packet have to traverse your DMZ interface (assuming the web server is on a DMZ subnet)? If configured on your DMZ interface, Snort will be seeing all traffic coming from and going to your web server from any other firewall interface (including the WAN). So it can offer exactly the same protection to the web server on the DMZ as it would offer if Snort were running on the WAN.
Now consider the potential issues/irritations if Snort is running on the WAN. I assume you are using NAT and port forwarding to reach your internal web server in the DMZ. If not, then skip the rest of this paragraph. That means all the alerts you see on your WAN have the firewall's public IP in them. So how do you determine if you have an infected internal host and which one it is? To do that you would likely want to run the same Snort setup on your internal interfaces. Now you have duplicate or triplicate Snort instances just chewing up RAM and CPU cycles for what real benfit?
Why not just put the IDS/IPS close to the hosts it is actually protecting? The IDS/IPS is for your internal network. It is not to protect your firewall. Right? If your firewall needs protection, then you would want to find you another firewall ... . And when on the WAN interface, Snort is just going to see and alert on all the Internet "noise" traffic that the firewall is not going to pass anway. So why bog down your CPU logging crap that your firewall is not going to pass anyway?
So my answer is run Snort on your DMZ and maybe your LAN, but you likely don't want or need the same rules in both places. Select and enable rules to protect from the actual threats you face on that interface based on the services provided behind it. If you don't have a DNS server on the DMZ, then you don't need any DNS rules taking up CPU cycles and chewing up RAM. If you don't have a mail server running, then you don't need any of the SMTP server rules enabled. Being smart about the rules you select and enable and choosing those rules by the actual attack surface behind the interface lets you be efficient with the resource consumption of the IDS/IPS.
I am trying to sort out another issue with port mirroring for Security Onion as I keep getting zeek/bro notices telling me there is packet loss over the pfsense port mirror.
In your experience, how is the port mirroring performance in pfsense compared to Cisco's port span?
Thanks again, it's good talking to a master!
Port-mirroring is a hardware-intensive task. And when you have very high speed network ports it can get overwhelming for any switch very quickly. How exactly do you have port mirroring configured? What brand of switch are you using?
-
@bmeeks I'm totally blown away, that makes perfect sense! Excellent example.
Thank you! Again!
Currently I am using pfsense to mirror my vlans, which run over a 3GB lagg. The mirror port is a 10GB nic which is direct/copper attach to my seconion box.
I monitor pfsense cpu usage closely with either the dashboard or pftop and it never seems overwhelmed.pfsense specs: i3 4170 with 16gb ram.
switch: Cisco WS-C4948E-Sbreaking out ports to get inline working will complicate my port mirroring. That should be fun!!