@Actionhenk:

Hi,

On my pfsense box (hyperv vm) I have installed suricata on the lan interface. Suricata is dropping traffic like it should however I also have a guest network which im running on a vlan.

When I assign the guest vlan to my lan interface suricata stops blocking/working. Im guessing it is because pfsense now has 2 interfaces assigned as 1 and suricata cant seperate them correctly, or only sniffs 1 of the 2 interfaces.

I read about someone who also noticed suricata stopped working properly and he set the mtu of the suricata/lan interface from 1500 to 1502 and this solved it for him. I dont know what im doing with mtu sizes so I would like to know how this could negatively impact traffic flow? Will this cause congestion? Dropped packets ?

Anyone else who noticed ? How did you resolve it ?

Thanks!

Make sure you have the latest version of the Suricata package.  If you are using Legacy Mode blocking, then you can increase the new snaplen parameter on the INTERFACE SETTINGS tab for the Suricata interface.  It defaults to 1518, but sometimes VLAN tagging operations need a larger snap length from the pcap library in order to process VLANs.

Unfortunately, if you are using Inline IPS Mode, then a limitation within the Suricata binary makes using a non-default snaplen value impossible and you are stuck with the 1516 value.  This is sometimes not large enough for VLANs.  Additionally, Inline IPS Mode uses the netmap API and there may be some capatibility issues with netmap and VLANs in FreeBSD.  I know the traffic shaper does not support netmap at the moment.

Bill

@NRgia:

Although freshports is still pointing to 4.0.3 version, you made this possible.

Thank you for keeping the Suricata package updated

With a little help from Renato on the pfSense team, too.  Thanks!

Bill

@Raffi.:

Thanks Bill. Do the same installation instructions apply to the 4.0.4 update released today? I guess a better question would be, do those instructions only apply to 4.0.3_2 or is it generally advisable to do a complete uninstall/reinstall? I can do so anyway for good measures since it doesn't take much time, but I'm just curious about best practices and understanding why.

Raffi

No, the update released today was for the binary only.  The pfSense team went ahead and pulled in the 4.0.4 binary update. I'm working a small update for the GUI, but it's not ready yet.  Will be adding the capability to use custom URLs for rule archive downloads and the ability to use a rejectsid.conf configuration when using Inline IPS mode.

That being said, it's not a bad idea to generally follow the "remove and then re-install" process.  By having "save settings" checked, you don't lose any configuration info.  I do make it point, though, of pointing out in the release notes when "remove and re-install" is necessary.  So if you don't see it specifically called out in the release notes, then you can consider it optional.

Bill

@Noisette:

Thank you for your reply. I thought there was a ready-made list. Apparently all 119 and 120 are false positives.

If you search for the threads I referenced and then browse through them, you fill find a number of posts similar to @NogBadTheBad's post containing code you can copy and paste into your own list.  There is no place to just go download a ready-made file.  That's because suppressing alerts and tuning an IDS/IPS is network-specific.  Some users need rules that others do not depending on the types of "normal" traffic on their network.

I keep repeating this mantra for the benefit of new IDS/IPS users – "using an IDS/IPS such as Snort or Suricata is not like installing an anti-virus client.  You can't just install, enable all the rules and live happily ever after.  If you do that, you will in fact live in constant frustration dealing with nuisance blocks.  Spend some time reading the posts on this forum and browsing the "school of Google" to learn about tuning an IDS/IPS.

Bill

Thank you for your reply. My problem has been solved by updating snort rules. The scan appears in the LAN interface.

Thanks, I've disabled it for udp and tcp.

@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