8. Click the Snort Interfaces tab and then click the plus "+" icon to add a Snort interface.
9. On the If Settings tab, click the Enable checkbox.
10. In the drop-down, choose the interface. The WAN interface is the default and is a good first choice.
11. In the Description textbox, enter a name (WAN again, is fine here).
I have several OpenVPN clients that run as interfaces. Should I add them also in Snort interfaces or is it enough with just WAN?
Thanks for this great post. I followed your post and also watched this tutorial https://youtu.be/-GgqYq5-EBg
bmeeks - I found the following link that describes what is included in each of the 3 IPS policies. Note there is a 4th policy - MaxDetect. Do you know if there are any plans to implement this in the Snort package for pfSense?
Great post, thanks. Using Inline Suricata 4.0.0_1. Works Great
Can you, or someone, please post an example of a pass rule that would always pass an IP in Inline mode.
I want to use it for my remote IP when I make changes to rules so I do not inadvertently block myself.
How about this example?
pass tcp 22.214.171.124 any -> any any (msg:"pass all traffic from/to 126.96.36.199"; sid:100000;)
Would this rule allow IP 188.8.131.52 to not ever be dropped by Suricata using Inline mode?
Yes, this would let traffic pass without blocking whenever the SOURCE IP was 184.108.40.206. It would not prevent a block from happening if the IP 220.127.116.11 was the DESTINATION IP. If you want to prevent IP 18.104.22.168 from getting blocked no matter the flow direction, use this rule instead:
pass ip 22.214.171.124 any <> any any (msg:"pass all traffic from/to 126.96.36.199"; sid:100000;)
Notice the direction symbol is "<>" which stands for "any" as opposed to "->" which signifies a specific direction (from 188.8.131.52 to any other IP). So the version I posted using "<>" would mimic the old Legacy Mode Pass List operation whereby IP address 184.108.40.206 would never get blocked.
For those looking to create their own rules, the "sid:1000006;" part of the example is NOT a reference to an existing SID. It needs to be a unique number otherwise Suricata won't load the rule.
To whitelist for a rule for an IP, search for the SID in /usr/local/etc/suricata/suricata_(interface)/rules/suricata.rules. Duplicate the conditions like "flow:from_server,established; content:"403"; http_stat_code;" into the custom rule so it matches, like
pass ip 192.168.1.22/32 80 <- any any (msg: "Pass List Entry - allow all traffic to/from 192.168.1.22/32"; flow:from_server,established; content:"403"; http_stat_code;sid:1000006;)
Otherwise with only the IP address, port, and unique SID it will allow all traffic for that IP.
Also note the directional (<-) only allows for two directions..."both" or "left."
You put a lot of effort into this forum & Pfsense thank you! Seriously a lot of people would be lost without somebody doing the answering on the forum
I’m having a lot of fun toying with this after work in my lab the only thing that I don’t currently understand is can I make some rules drop rather than block when I’m configured with:
*Legacy mode not inline
*Block on DROP only enabled
*IPS Policy Security with ‘policy’ mode
Snort Subscriber + ET
Let’s say I like one of the rules FILE tracking GIF (1x1 pixel) from the files.rules category sounds like a good thing to help with privacy but the blocking action causes problems as often the IP that gets blocked is hosting other legitimate images in the page, Can I use SID Management to modify this rule to drop even when I have block on drop enabled?
Your question leads me to believe you are misunderstanding a key piece of the puzzle. There is no difference between DROP and BLOCK in Legacy Mode. They are the same thing. Both lead to the exact same result: traffic from the offending IP address (the one that triggered the rule) is blocked by placing the SRC, DST or BOTH IP addresses from the offending packet into the snort2c pf firewall table. After that, all further traffic from those IP addresses is blocked until the IP addresses are removed from the snort2c table. Legacy Mode can't do what you want.
The whole reason I created the new "Block-on-drops-only" option was so you can tailor rules actions to get the results you desire. See, all rules by default from the rule set vendors come with the action set to ALERT. With Legacy Mode Blocking, and before the new "Block-on-drops-only" option was added, any alert also generated a corresponding block. It was an all or nothing arrangement. When you enabled blocking, any rule that generated an alert would also cause a block. With the new "Block-on-drops-only" option, I added some extra intelligence within the custom blocking module so that it could look at the rule action (ALERT or DROP) of the triggered rule and take the action specified. So if the rule says ALERT, then only an alert is generated but no block is created. If the rule says DROP, then both an alert and a block are generated.
SID MGMT has options that allow you alter rule actions from the default value of ALERT. So now you can pick and choose which rules you want to just alert and which you want to drop (or block traffic). This new "Block-on-drops-only" option was born out of the way the Inline IPS mode operates. With Inline IPS Mode, you must specifically change rule actions to DROP in order to drop or block traffic. You could also leave some rules with the default ALERT action and those rules would generate alerts but would not block or drop traffic. That's the way most commercial proprietary Intrusion Prevention Systems operate. So I thought it would be useful to port that same functionality (the choice of ALERT or DROP) over to Legacy Mode operation. Hence the new "Block-on-drops-only" option.
I still don't won't folks to confuse Legacy Mode's use of DROP with the way IPS Mode works, though. In Legacy Mode, even though I'm using the term "drop", the actual blocking of traffic is done the old way using libpcap to get copies of every packet traversing the interface, and when a rule fires to create a block, the IP addresses from the offending packet are copied to the snort2c table in pf to implement a firewall block. So when I say "drop" in the context of Legacy Mode and the new "Block-on-drops-only" option, I really mean that only rules with DROP as the action will add the offender's IP address to the snort2c table. The "drop" is really still the old fashioned block. With Inline IPS Mode, the snort2c table is not used at all. There is another Sticky Post here on the forum that describes the difference between Legacy Mode and Inline IPS Mode.
Read both of the Sticky Posts in this forum about Passlists and Suricata. Each of them also contains some key points about blocks, drops and Legacy vs Inline IPS modes.
I have upgraded rules already and working like a charm
Mar 14 12:08:43 pf php: /usr/local/pkg/suricata/suricata_check_for_rule_updates.php: [Suricata] There is a new set of Snort VRT rules posted. Downloading snortrules-snapshot-3000.tar.gz...
Mar 14 12:08:48 pf php: /usr/local/pkg/suricata/suricata_check_for_rule_updates.php: [Suricata] Snort VRT rules file update downloaded successfully.
rules 3 same as rule 2.990 and they only removed "snort_blacklist.rules" and "snort_local.rules"
This is good to know. I had not tested Suricata with the Snort-3.0 rules. I have been waiting on Snort-3.0 to get closer to RELEASE status before investigating creating a GUI package to support it.
@derpy456789 said in Potential Suricata Inline Netmap Solution:
Just wondering what kind of system/specs are you running suricata inline on and also did you change any setting inside the interface setting of suricata like the Detection engine settings for max pending packets ?
Ive been getting the same error
netmap_grab_packets bad pkt
Sorry for the late reply...I am running an HP Pavillion a6242n with Intel 82575 NIC 8GB RAM.
I suspect there's something wrong with inline mode as we've had cases where traffic doesn't flow but no alert is logged. See
Hmm... I don't know enough about pfBlocker to say that would fix it... First thought is try it with Suricata in non-blocking mode. If that still fails, try the explicit NAT rule for 1 of your internal servers.
I think I may have found the problem by uninstalling snort and trying suricata:
After installing suricata, same problem happens. Then I tried an older version of the snort rules:
snortrules-snapshot-29111.tar.gz causes firewall to crash!
So, something is definitely wrong with the pfSense code... a content update should not crash the firewall!
@cukal Using Suricata wasn't all that scientific...we had to start somewhere, Suricata is multi-threaded and Snort isn't, and there were packages for both so we tried one. As I vaguely recall Suricata was developed by OISF as something of a next gen Snort, and it's compatible with Snort rules. Search "snort vs suricata" and you will find a bunch on it.
@vacquah said in Best way to block some gaming sites:
Your best bet would be to sniff to see exactly what is being used for this game, the fqdn that are being queried for, and or ports used, etc. More than likely this is hosted on some CDN somewhere.. My guess would be AWS.
Then sure a simple host override on pfsense dns to send this fqdn to nowhere, ie loopback or 0.0.0.0 or even sure somewhere that presents a info page on 80/443 to not use company bandwidth, etc.
Only problem with dns blocking - is you have to make sure your clients can not use some other sort of dns to resolve it. So you have to force all clients to use pfsense via dns redirection, and or only allow dns to pfsense and block all others.
There is always away around.. You could tunnel out on 443 for example, you could use dnscrypt via some open port, etc. But a dns block and or simple blocks of the ports it uses if they are specific and not standard ports like http/https can stop the vast majority of typical users. Problem is once user figures out how to bypass your restrictions it spreads fast!!!
Content filtering and or blocking is normally always an uphill battle that is hard to win.. If users want out, they normally can find a way. This day an age though users just going to play the game on their phones via their cell connection. But atleast then they are not using company resources and bandwidth ;)
@chudak said in snort (SID 43687) blocks root DNS servers ?!:
@bbcan177 would it make sense to black list all top domains listed here https://www.spamhaus.org/statistics/tlds/ ?
Its not a one-size-fits-all... Most of those TLDs most users will never need to access, so I would see little issue. There is also the TLD Whitelist, where you can allow some specific domains thru that are being blocked via TLD Blacklist.
There is also this TLD list: http://toolbar.netcraft.com/stats/tlds
This happened to me, and I tried:
DID NOT WORK: Forcing updates to get new MD5 hashes. Some updates had failed, and this made the "Result" Success again. However, the non-starting symptom continued.
WORKED: Change the time of the day when updates occur. This did the trick for me, and I haven't had any problems since. Not sure exactly what the problem was, but the non-starts were occurring on only one of the scheduled update times. It was 0:05 and 12:05, changed to 8:45 once a day and have had no problems for two weeks now.
I'm changing it back to two updates a day, but keeping 8:45. Hope it works.
@teamits That seems to have worked. I guess maybe restarting the global service resets any global settings and restarting on the interface updates the interface settings but restarting the global service didn't seem to update the interface settings.
Is it this bug in 2.4.3_1 by chance?
(rule syntax error on incomplete rule (missing IPs): "There were error(s) loading the rules: /tmp/rules.debug:371: syntax error - The line in question reads : pass out route-to ( vmx0 xx.xx.xx.xx ) from to !/ tracker 1000027964 keep state allow-opts label "let out anything from firewall host itself"; @ ...")
@bmeeks said in Suricata inline whitelisting:
Suppress rules can be used to make sure no alerts are generated for a host. This is not efficient however, as the suppression is only considered post-matching. In other words, Suricata first inspects a rule, and only then will it consider per-host suppressions.
This means to me that the pass, drop, reject, etc., decision is made first and then the suppress list is checked to see whether or not to suppress the alert in the logs. I need to dive into the source code for the Suricata binary and see if I can precisely determine how suppression affects dropping.
I need to dig into this some more before I can post a definitive answer.
Hi, did this get figured out/resolved? We may have run into this today on Suricata package v4.0.4_1...I suppressed an alert but the behavior didn't seem to change until I disabled the rule.
(FWIW it was rule 1:2013744 "ET INFO DYNAMIC_DNS HTTP Request to a no-ip Domain" which would make sense for dynamic domains but was for cdn.no-ip.com which is their actual domain. The rule only excludes www.no-ip.com.)
OpenAppID rules seem to download fine for me.
What interface are you running snort on ?
Run it on your LAN as you then see hosts pre NAT.
Yup the ping rule is a good test to see if snort is working.
If you change your ICMP rule slightly :-
alert icmp $HOME_NET any -> !$HOME_NET any (msg:“ICMP test”; sid:10000001; rev:001;classtype:misc-activity;)
alert icmp $HOME_NET any -> !$HOME_NET any (msg:“ICMP test”; sid:10000001; rev:001;classtype:icmp-event;)
It should block outbound ICMP traffic.
andy@pi-3:~ $ ping 220.127.116.11
PING 18.104.22.168 (22.214.171.124) 56(84) bytes of data.
64 bytes from 126.96.36.199: icmp_seq=1 ttl=45 time=14.8 ms
--- 188.8.131.52 ping statistics ---
6 packets transmitted, 1 received, 83% packet loss, time 5160ms
rtt min/avg/max/mdev = 14.847/14.847/14.847/0.000 ms
andy@pi-3:~ $ ping 184.108.40.206
PING 220.127.116.11 (18.104.22.168) 56(84) bytes of data.
--- 22.214.171.124 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2064ms