@alchemyx: Hi, How to change max_client_bytes in SSH preprocessor? If I put that in Advanced Configuration Pass-Through preprocessor ssh:         max_client_bytes 19600 Then SNORT won't start up. Probably because I have duplicated preprocessor ssh: with the one provided by pfsense. I tried disabling SSH altogether and putting it again but snort also refuses to come back up. pfsense version is 2.4.2-RELEASE-p1 and SNORT is 2.9.9.0 Thanks! Michał At the moment that is not a configurable parameter within the GUI.  And using the Advanced Passthrough feature doesn't work with preprocessors because of how the internal GUI code works for now. I will add this parameter to the next Snort GUI update.  I'm working on some other Snort updates and hope to get an updated package posted in a couple of weeks or so. Bill

Thanks, Bill.  Probably just pushing down ads.

Thanks. Worked great.

No worries, thanks

@zombietek: Hi, I have upgraded to 2.4.2-RELEASE-p1 and it is nice to have the addition of "Click to force a different action for this rule" option under Alerts on Suricata. Only comment I have so far, I hope they would add in the future that when a GID:SID is set to a specific action on an interface like WAN, there is an option at least that prompts or check boxes whether or not you want to apply it as well to other interfaces on your pfSense box. My question is, where could I check in pfSense the GID:SID that I have been setting to DROP through the option above? I used to manually copying GID:SID and pasting it to a dropsid configuration file under SID Mgmt and I don't see anything new that I have been setting lately to DROP. Thanks. When you "force" different rule actions on the ALERTS or RULES tabs, those changes are saved in a special section of the firewall configuration file, config.xml.  They are not written to any of the SID MGMT configurations.  Go check out this sticky post at the top of the forum:  https://forum.pfsense.org/index.php?topic=145467.0.  User overrides are the last actions processed as the rules are built for an interface.  If you want to see what rules you have user overrides for, go to the RULES tab and view using one of the new categories listed in the drop-down there.  There are categories for each class of applicable user overrides. The software version you quoted as upgrading to is for pfSense itself.  That is not the version of Suricata.  Suricata's version is currently 4.0.4. Bill

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