@Greenhill: Hello, I recently reinstalled pfsense and also suricata. Had saved my enablesid/dropsid/disablesid files which were working fine on my previous pfsense installation. With the new installation something in my sid rule files keeps blocking internet. I would like to find out which sid is being blocked but there are no alerts appearing on the alerts page… how can I troubleshoot which alert is making suricata block traffic without seeing any alerts on the tab ? is there a log file somewhere i can download and browse through ? Also have a second questions, I added a passlist, and added the pfsense IP and my wan IP to the passlist. How does suricata blocking work, which side gets blocked ? For example someone send some malicious traffic from 48.235.223.23 to pfsense on public ip 45.43.54.212  , suricata detects, now I am wondering does suricata block both ips ? or just the 48.235.223.23 ? or 45.43.54.212 blocking my connections ? What happens when I add my ips to a pass list, does this mean the malicious sender from 48.235.223.23 also gets through because my wan/gw ip are on a passlist ? Thanks! Are you using Legacy Mode blocking or the Inline IPS Mode?  You should always be seeing alerts if you get blocks.  The only way that would not be the case is if your alerts log is very large and got rotated over into an archive and the new file is empty.  That would let a situation exist where the alert that caused a particular block is actually in the archived alert log and thus is not currently displayed on the ALERTS tab.  That tab pulls only from the currently active alert log. If using Legacy Mode, you can find any IP blocked by Suricata by going to DIAGNOSTICS > TABLES in pfSense and displaying the contents of the snort2c table.  Any IP addresses listed there were inserted by Suricata. Bill

Thanks Bill, that is probably my issue.

@geronimobb: Thanks for your quick reply and suggestions. As for now, i followed your suggestions. it makes sense off course. I noticed allready that the blocks by surricata (on wan) were allready blocked by the firewall (deny all…). What could be the purpose of running suricata on wan? Kind regards. I found the bug in the custom blocking plugin for the binary that made it fail to recognize changes in firewall interface IP addresses.  A fix will be out soon. For home networks, and even many small business networks, there is no good case for running an IDS/IPS on the WAN.  If you don't host externally accessible services such as DNS, web, etc. (I mean public services, this does not apply to something like a VPN), then the firewall already will default deny all unsolicited inbound connections.  So having Suricata or Snort alert on something the firewall is going to deny anyway is not too helpful. The only exception would be if you as the admin just have a burning desire to know what hits your firewall's public interface. Even with a network where you hosted publically available hosts, they would likely be in a DMZ and you would be better off to run the IDS/IPS on the firewall's DMZ interface. Bill

@bmeeks: @adam65535: Changing Suricata config to live reload the rules stopped carp from failing over.  It does seem like Suricata was causing the issue.  I thought I didn't enable live reloading because of issues a few years ago but that was quite a few versions ago so maybe that isn't an issue anymore.  There is a note that if live reloading causes problems that you should disable live reloading.  Hopefully things keep going smoothly. Thanks for the help. Thanks for the follow-up.  Using Live Reload should be OK.  It is relatively mature now in Suricata. I still have no good explanation for why Suricata restarting woud cycle the network connection.  As I said earlier, the only thing it is doing with Legacy Mode blocking is starting up libpcap to get packet copies of traffic traversing the interface.  Maybe that causes something to hiccup in FreeBSD someplace and CARP sees the hiccup because maybe it disrupts traffic very briefly.  Strange issue. Bill Success! Looks like enabling "Live Swap" fixed the issue for me too. Only got past 1 "expected CARP failover event" thus far, but appears to be good. Thanks for the suggestion. All I did to fix it on my side is filled in the checkbox "Enable "Live Swap" reload of rules after downloading an update" on my pfsense routers and so far so good. Typically the routers appeared to fail back and forth a lot as the general system logs showed >5000 logs of CARP failover. Gladly CARP works very well, so actual impact was approx 2-5 lost pings, slight freeze on RDP sessions, but SSH sessions would continue to work as expected. Because I only just set this rule I have only gotten past one potential failure (update every 12 hours starting at 00:30. 00:30 did have failure, but at 11:40 I enabled the "Live Swap reload" in Suricata, and 12:30 typical CARP failover did NOT happen). In other words, I typically have two failures, one at 00:30 midnight, and a second at 12:30 noon. After changing this setting I have not had any failures. Crossing my fingers this was the solution :) PS. if helpful, my versions are: pfSense: 2.4.2-RELEASE Suricata: 4.0.3_1

https://github.com/redhat-infosec/charlotte

As a feedback, a "rejectsid.conf" is also what I wanted to suggest, but in the end it's your decision. Thank you for taking this option into consideration

@NollipfSense: @bmeeks: Running both on the same interface can tax your hardware, especially on a busy network.  You should never run them together when Snort is blocking and Suricata is blocking with Legacy Mode enabled.  They both will try to share the same snort2c pf table and there can be strange issues with blocks and clearing them.  Theoretically you could run both if Suricata is using Inline IPS Mode, but running both on the same box is not recommended. Bill This is interesting Bill…I am running both in legacy mode now in my home environment with no problem. My original plan was to run Suricata in inline mode; however, I discovered the dual NIC and the netmap drive issue. I have 8GB RAM though, and mostly use 39% of that. You're not seeing an issue because it is a home network (and you have 8 GB of RAM).  Try it on a large, busy corporate network or on a smaller appliance like say an SG-3100 with 2 GB or RAM and you will likely encounter issues. I'm not saying you can't run both or that both won't run, but it is going to tax your firewall more and it adds not much at all to the overall security.  But each to his own as they say …  :). Bill

That is an error from within the Package Manager itself and not directly related to Snort.  The pkg installation process will copy down the single package file and then start unzipping and copying the contents of the gzip archive to their final destination.  Something blew up or failed in that process.  Try the install again. Bill

Thanks for your help Raffi. I just blocked all countries with exception of few i need it. I will read that taming the beast blueprint too. Step by step i'm improving the security. Sorry for other if newbies like me rehash same thing over again but we got to start somewhere and forum is good spot. I'm already seeing RU, CN, HU trying to access my wan port. Crazy stuff. Nuts.

Fantastic!!! Thanks again for all of the help Bill. I had recently taken my pfSense build out of a little tower case and stuck it in a rack-mount case and got a nice cabinet to keep it all in (switches/patch panel/PDU/etc).  Of course, every time I moved something, I had to power-down everything and do my little modem trick (which would explain why it only recently started blocking the WAN IP).  However, it's FINALLY all together and all on one UPS for modem/pfSense (using apcupsd which is nice).  SmartUPS is on the Windows 2016 Server/switches/etc. Mystery solved.  I thought I was going crazy!  hahaha!!  It was one of those "it can't possibly be happening…but IS happening" scenarios that we all love so much. Thanks again, Eboman

What you want to do is not currently possible with either Suricata or Snort on pfSense.  The firewall and the IDS/IPS do not cooperate with other at that level. Bill

@sboyle: Thanks for the tip, I had missed that I was not running the latest package.  I'm running an Intel CPU: Intel(R) Xeon(R) CPU E3-1270 v5 @ 3.60GHz 4 CPUs: 1 package(s) x 4 core(s) AES-NI CPU Crypto: Yes (active) I've installed the latest snort package, hopefully that will take care of it. A Signal 10 would be very unexpected on an Intel CPU with Snort.  On an Intel platform that may indicate a possibly failing memory chip or other memory component.  Signal 11 is not unheard of, but Signal 10 is rare. Bill

Is it possible that alias is not doing what you want or it is not completely bypassed? I was able to get my client to bypass the proxy completely in a less sophisticated way (mine is not transparent though). I couldn't use the bypass destination field as you did. I'm not sure know how to completely bypass a transparent proxy without disabling it. You confirmed that same page is loading up fine if you access it from anywhere other than your pfSense network? Via a different browser? Or after clearing browser cache, history, etc. Also, I assume you already tried manually clearing all blocked hosts from Snort and then accessing it again?

@bmeeks: @NollipfSense: @bmeeks: No, the POP3 preprocessor most definitely does not communicate with any mail server.  It is simply looking at the commands flowing back and forth between email clients on your network and whatever mail servers they are connecting to (assuming that traffic passes through Snort).  The line you underlined from the Snort manual is simply saying you need to tell the POP3 preprocessor what ports to be looking at within the incoming/outgoing datastream.  It does not imply that Snort is talking to the mail server, though.  Telling the POP3 decoder what port is in use lets it filter the traffic and only inspect data coming or going from the active POP3 port. You define the POP3 ports on the VARIABLES tab for the interface in Snort.  There are settings on that page for servers and ports.  Leaving boxes blank will use the default values which are shown in the help text under each box. Bill Thank you Bill for the detail explanation. Well, one cannot just add the port…one has to create an alias; so, I created two firewall aliases, inmail and outmail and added firewall...see pic. Then, I added the aliases to Snort's variables tab > SMTP >outmail and POP3 >inmail. But, I cannot send or receive mails...should I have added anything in the server section? I got this Snort alert and have since changed the source port. Had to hide destination IP for privacy on Snort alert pic. Outmail port is 465 and inmail port is 995. Port 995 is typically for POP3S (encrypted POP3), so Snort is going to have trouble seeing everything correctly on that port.  That rule is a "false positive" in your case because it is looking at an SSL encrypted datastream, so the byte patterns are not going to match the "standards" that Snort would see on a port 110 plain-text POP3 connection.  That's why the rule is triggering. So short answer is just disable that rule as it is going to fire on you a bunch and means nothing on an encrypted session. Bill Thank you Bill…disabling the rule worked and can now send, received emails from my SOHO...in time for Monday morning!

Your hardware is capable of running Suricata or Snort for a home network application. Whether you need it or not is really up to you.  One of the things to consider is what type of risk is your network exposed to via the VPN.  What I mean by that is if you simply access mainline streaming services like Roku and AppleTV and avoid other more "wild and wooly" sites, then you don't need an IDS/IPS package.  If you have guests with laptops, or other household members that might visit more risky sites (such as torrent hosting sites, some gamer sites, etc.), then an IDS/IPS like Suricata or Snort can help protect users from themselves by blocking some known exploits. Just be aware that it is NOT as simple as just installing the Suricata or Snort package and turning on blocking.  Doing it that way will most certainly result in lots of spurious blocks from false positives.  You have to understand the rules and enable only the ones that are appropriate for your network usage.  There are examples of good setups in the threads of this IDS/IPS sub-forum.  Just search through using the search tool on the forum. Bill

@mpdsville1: I examined the igb(4) page and see the chipset is supported but that it doesn't specifically state Dual/Quad.  Am i correct in that you are referring to the lack of Dual/Quad specifically listed ? Yes, it very well can be that the Dual/Quad variety is not supported.  I'm not a NIC driver expert, but I assume there is still some degree of difference between the driver for a single port NIC versus one for a multiport NIC even if the underlying physical chipset is the same.  For one thing, the multiport NIC driver would have to know which "port" on the card to send and receive a given datastream from. Suricata supports several Inline IPS operating modes on various operating system platforms.  The two available on FreeBSD are Netmap and IPFW Divert Sockets.  In the distant past I tried using the IPFW Divert Sockets mode with Suricata on pfSense but it would not work due to some customizations done within the IPFW module at the time to support some of the old limited Layer 7 inspection capability pfSense offered.  IPFW is also used, I believe, as part of Captive Portal.  IPFW is the alternate firewall engine available in the FreeBSD used for pfSense.  The other firewall engine, and the one pfSense uses, is the pf (packet filter) engine.  IPFW Divert Sockets mode is NIC driver agnostic and thus would work with any NIC, but that mode is quite slow as it does not allow direct connections between the NIC, Suricata and the kernel network stack.  So Inline IPS mode would be much slower with IPFW Divert Sockets than it is with Netmap. Bill

The problem appears to be within Barnyard2.  Notice that is where the error is generated according to the log message.  Barnyard2 on FreeBSD (and thus on pfSense as well) is very old and not well supported.  It will be removed from the Suricata package in the near future, and I'm considering doing the same for Snort because Barnyard2 is so unreliable. Your particular error message comes from Barnyard2 not being able to adequately handle IPv6 events.  Here is a thread link to an open bug report on Github for this issue.  Notice the date is 2015 and still no action, so that's what I mean by Barnyard2 being poorly supported. https://github.com/firnsy/barnyard2/issues/144 Bill

It actually has nothing to do with Suricata and more to do with FreeBSD kernel and the NIC driver. I just recently experience the same issue and have submitted a bug report to FreeBSD…see here. https://forum.pfsense.org/index.php?topic=144538.0 After researching, it seems that the dual Intel NIC is not natively supported per here: https://www.unix.com/man-page/freebsd/4/netmap/