@bmeeks Okay Bill, I'll just disable ... thank you!

Suricata will not restart itself except when it does an automatic rules update. The binary has no mechanism to even accomplish this. The PHP GUI code takes care of restarting Suricata after a rules update download. pfSense will, under some circumstances, issue a "restart all packages" command. Could that have been going on at the same time you were trying to stop Suricata? Very unusual if that were the case, though.

@interessierter said in SNORT blocking too much: Guys please stop this. Not meant to be personal ^^ Didn't know what you know, but now I get the picture. @interessierter said in SNORT blocking too much: When I m a company with 100.000 employee s it get hard to "know" my traffic The easy one : that corner guy exists !!! But ok, serious : as you said "100 000" means a totally random bit stream is what snort will be seeing. DPI became already quiet impossible then : TLS killed the access real to the data payload years. A solution that still might pull it off : Use a proxy on/in front of your snort device, have it "unpacked" all traffic, scan, and pack it back into TLS again. This proxy device would be situated on pfSense, but in front of it. Centralized administration of all devices in the network would be needed to handle the 'cert' issues. For a small group of persons (small society or even family) it's actually possible to find some common patterns, but a huge group will always trigger some (random) pattern/rule. You're talking of several OS's - thousands of application, that can all have there "network errors", that might trigger some rule. Keep in mind : snort is somewhat limited to the packet headers, or "headers in headers" and some transport flags. It's like reading a postal envelop, and drawing a conclusion when seeing the destination and sender, and the type of letter, and their occurrence. Btw : for purely learning how DPI works, I've been using snort and friends for some years in the past. It became a close to 7/7 daily job to maintain traffic flowing. And I was using the rules accessible by subscription. I'm still using it (DPI) today, on my mail server, as that one still 'sees' the traffic 'in clear' in the mail boxes. IMHO : I lost somewhat of the faith in the usefulness of DPI as it exists today. It's goes totally against the all TLS hype. @interessierter said in SNORT blocking too much: When the snort rules gets sold to enterprise customers, than I was expecting here a bit more. Rule support should be found there where they are created ;)

That is a lot of Snort processes. To answer your question, there are no tuneables of that sort within Snort itself. And the way Snort works on pfSense results in each interface you run it on being a totally separate process without any awareness of the other Snort instances. So any limitations would be within FreeBSD itself. To see what is going on, I suggest you do what I mentioned earlier. Go to the GLOBAL SETTINGS tab, and down at the bottom of that page, check the box to turn on verbose logging. Then go and attempt a start of an interface that does not normally start with performance stats enabled. After the failure to start (assuming it does fail), then examine the pfSense system log line-by-line to see all the Snort messages. Something may get logged to help you troubleshoot. Note that pfSense uses a circular binary logging system called clog for the system log. So in order to have plenty of circular buffer space for logging, go to the System Log > Settings tab under STATUS and set the number of lines to display to a very large value like 1000 or perhaps more. Snort will log a lot of information as it starts up.

@bmeeks Ok. I see MicroUSB port on the back, and two USB-A ports on the front. None are in use, nor have I ever used any. This unit shipped with pfSense already installed and with base configuration. Although I am aware of the console option, I have never used it.

@TTWE said in Trying to diagnose non starting packages: Hi I have just installed PFsense and in the process of setting it up. However when I went to install additional packages (Suricata) they wont start at all (I have tried other as a test and non of them start). I don't get any error messages and I have looked in the system logs, however being new to this I have had no luck. I would greatly appreciate any help I can get trying to diagnose this problem. I will put all the information I have and the system specs underneath. Many Thanks TTWE Version 2.4.5-RELEASE (amd64) built on Tue Mar 24 15:25:50 EDT 2020 FreeBSD 11.3-STABLE CPU Type Intel(R) Xeon(R) CPU E5630 @ 2.53GHz 16 CPUs: 2 package(s) x 4 core(s) x 2 hardware threads AES-NI CPU Crypto: Yes (inactive) Memory 64 GB 1% average use. suricata security 5.0.2_2 High Performance Network IDS, IPS and Security Monitoring engine by OISF. You can find out why Suricata is not starting by going to the LOGS VIEW tab, selecting the interface you want to view logs for in the Interface drop-down selector, and then choosing the suricata.log file in the log file drop-down selector. I can pretty much guarantee you that your problem is going to me a memory allocation error due to an insufficient TCP Stream Memcap setting. For high core-count boxes you need to dramatically increase the stream memcap value on the Flow/Stream tab. Try 256 MB and then work up there since you have so many CPUs and cores. Here is a link to the Suricata upstream Redmine site where they have a project underway to improve the OOBE (out-of-box experience) by improving some default values: https://redmine.openinfosecfoundation.org/issues/1343. Once they incorporate those into Suricata, I will make some updates to the pfSense package. But in order to not create a memory hog on smaller systems, I may not use values quite as large as mentioned in that thread. The current default in the pfSense package is fine for dual or quad-core CPUs, but is not enough for high core-count boxes like you have.

Sorry, I don't intend to hijack this threat, but.. A admin moved my thread from IDS to Development. I'm not a expert, but I think there is like bmeeks expressed something fishy with netmap and/or Nic drivers. I wrote my experience with a Wireguard Client on Linux Mint on this threat. https://forum.netgate.com/topic/153255/bug-2-5-0-development-amd64-built-on-sun-may-03-23-56-0-snort-2-9-16-inline-ips-throttles-wireguard-speed. I noticed a significant speed drop with WG in March as I changed snort IPS to inline IPS mode. Since I changed back to Legacy Mode my speed is back. Everything OK. I have setup a ovpn client to Mullvad, my speed is > 350Mbit/s regardless if on Legacy or IPS Mode, with my ISP regardless IPS/Legacy Mode ~ 950Mbit/s. When using WG on a Client PC speed in IPS Mode throttles down ~ 70Mbit/s in Legacy ~ 830MBit/s. Remark: IPS Mode never created problems between March when first time used and changed back to Legacy in 5th of May, no crash or what ever.

Thks :)

@JSmorada said in Cron job for hourly restart of Snort: I'm running on bare metal; the version of pfSense is 2.4.5-RELEASE (amd64) and Snort is at version 3.2.9.11. I haven't checked the logs but will take a look to see and report on it later today.https://forum.netgate.com/topic/153269/cron-job-for-hourly-restart-of-snort/3# Have you looked to see if any alerts are occurring from Snort? What IP addresses are shown as being blocked (if you have blocking enabled)? The fact you say a restart of Snort solves the issue is not consistent with Snort blocking because restarting Snort will NOT remove any existing blocks. Blocks, once inserted, remain until the IP addresses are removed from the snort2c table. That happens only via three things: (1) a manual clearing of the table by the user; (2) the periodic "Remove Blocked Hosts" cron task executes if enabled; (3) or a reboot of pfSense itself. So based on the above, are you 100% sure Snort is the cause of your issue? Do you have any other package running on your firewall? What type of NIC do you have? One thing that restarting Snort would do is "tickle" the NIC driver due to the libpcap library tearing down and recreating a subscription for copies of packets and placing the NIC in and out of promiscuous mode. However, that would indicate an issue with the NIC or its driver and not a problem with Snort. What happens if you leave Snort disabled for say a day? Do you have any connection problems then? That is one way to narrow down the issue. If you leave Snort disabled and still have a network interruption after some period, that would certainly clear Snort of being responsible.

Thanks for the great explanations Bill. I appreciate your time.

@pftdm007 said in Snort intercepts incoming traffic on WAN going to DMZ clients: @bmeeks said in Snort intercepts incoming traffic on WAN going to DMZ clients: I don't really understand your question. If a client on the DMZ is speaking with a client on the LAN, and that conversation triggers a Snort rule on the LAN, then it will fire an alert on the LAN. This is expected. I'm not sure what you expect to happen in that case. Hello @bmeeks That wasn't really a question more than trying to understand how snort works. Basically you're saying that the alert triggered on LAN occurred during the reply from LAN client to DMZ client? That would make sense... Request: DMZ client -> DMZ iface -> LAN iface -> LAN client Response: LAN client -> LAN iface -> TRIGGERS Snort alert & traffic blocked (or alert only) Yes, although it could also have occured in the other direction when the DMZ client initiated the conversation with the LAN client. Snort would have seen the packet as it left the firewall's filtering/routing engine and was being handed to the NIC driver for transmit. Remember that Snort sits between the NIC driver and the firewall's filter and routing engine. Either way, the alert would be triggered by the LAN instance of Snort and would only show up on the ALERTS tab when you are viewing the LAN alerts.

Yes i know, but i was so happy to see barnyard2 working with the database (it has problem with schema and it was too hard for me to fix, but an ipk update solve that recently in the last pfsense ;) .. so i can enjoy stats for snort in "snorby" (another end of life product...). I look for other program to replace but they need a large amount of ram ... telegraf to elastic search / grafana / kibana ... i must use another computer just for that (maybe a raspberry i don't know ... something with few energy consomption). so im stuck with my olds monitoring tools for now ;) until you remove barnyard from pfsense. anyways thanks for your answer bmeeks ! have nice day !

Thanks for the update. Live rule swap is already on. I do have pfBlocker and Suricata so that might very well be it.

@bmeeks Thank you very much, i will take off some lists and check what happens

Got you. Thanks!

@cpom1 said in Snort fills up disk with logs, Dashboard goes bye bye, interfaces lose their minds: Just wanted to report that it looks like things are working now. Thanks for the help! Great! Turns out there was an issue in the log purging code after all. I had just not ever hit it because my logging "rate" is low and my system was not generating as many logs. Also, I do not run OpenAppID and thus my personal system was not generating any of those logs at all. Thanks for reporting the issue.

Are these guys your ISP ? AS details for 80.24.39.249 :- route: 80.24.0.0/16 descr: RIMA (Red IP Multi Acceso) origin: AS3352 mnt-by: MAINT-AS3352 created: 2005-07-21T12:32:14Z last-modified: 2009-08-19T06:59:24Z source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** Monday, 27 April 2020 at 15:26:06 British Summer Time

@genuine said in Suricata wont Start after updating pfSense to 2.4.5-RELEASE: sorry for the short explication well after upgrading pfsense 2.4.5 he did also upgraded suricata with was not starting anymore. so I did a clean uninstall and removed also the settings and did a reinstall it was not starting I was looking in the log and there was a packet missing I think it was libluajit I'm not sure so I installed the lib and suricata was starting up configured as inline mode the error appear with drops and rejects for the firewall it is configured as normal nothing exotic also not in bridge mode everything was working before the upgrade without problems. if i have a hodge-podge of library versions how can i check and fixed this You very likely have a mixture of FreeBSD 11.2 and FreeBSD 11.3 libraries as a result of how you updated. That missing libjuit package is one example. I suspect your libdnet package might also be the wrong version and hence you are getting your current Suricata error. From your symptoms, I'm going to guess you were on pfSense 2.4.4 and saw an update for Suricata posted. But that Suricata update was for the 2.4.5 version of pfSense and has new shared library versions/dependencies that can only be satisfied when pfSense-2.4.5 is already installed. You installed the new Suricata onto a pfSense-2.4.4 system and it would not start (that missing libjuit package is a classic symptom of this upgrade path). So then you updated to pfSense-2.4.5, but that still will not properly update all of the dependent libraries that third-party packages might use. So now you are experiencing weird errors because of the library problems. I would recommend you do this. You should reinstall pfSense itself from a clean install and then put your packages back. That will guarantee that you get the correct versions of all the supporting libraries. If you don't want to perform a complete reinstall of pfSense, then try this series of commands to refresh the pkg database. pkg-static clean -ay; pkg-static install -fy pkg pfSense-repo pfSense-upgrade The commands above came from this link in the pfSense documentation: https://docs.netgate.com/pfsense/en/latest/install/upgrade-troubleshooting.html. And next time you see a pfSense version upgrade notice on the Dashboard, DO NOT update any packages until AFTER you have upgraded pfSense to the new version!

@everfree said in How do I disable snort2c firewall blocks: @bmeeks I update to 2.5.0 - Dev, I think If snort2c functions similar to pfblocker NG suppression, that is good. Yes, both packages use the pfctl utility to interact with pf tables. And the pfctl utility is showcasing some sort of issue that is present in FreeBSD 11.3/STABLE. The pfSense team is looking into it.