@Snowaks said in Suricata Snort VRT Rules Problem/Missing Fixed!:

So one question I had now that 3.0 is out for snort will the 2.9 train no longer get updated ??
at least I've seen was snortrules-snapshot-29140.tar.gz and was almost a year old.

Snort3 is not actually "out" yet. It is still in Beta and has been in a Beta for about a year. The Snort 2.9.x rule sets and source will continue to be updated for a while.

And DO NOT attempt to use the Snort3 rules with Suricata. You will break it badly if you try that. Suricata cannot work properly with Snort3 rules.

The snortrules-snapshot-29140.tar.gz file is not a year old. Not sure where you think you are seeing that. The file is updated approximately twice per week. Snort 2.9.13 is the current binary version, and those rules are also updated about twice a week. Since there is a 2.9.14 rule set posted on the Snort site, I suspect a release update for the binary is about to drop (that would be Snort 2.9.14).

Normally what you would do in a double nat setup is yeah put pfsense wan IP in the dmz host of the router upstream.. This way you only need to mess with 1 place for port forwards.

But sure if you need port X to be forwarded on pfsense to something behind, then you would make sure the nat upstream forwards port X to pfsense wan IP first.

@Actionhenk said in Snort3 Package Status Update:

does this version support multithreading ?

Yes, Snort3 is multithreaded. But don't expect a huge performance gain from that. Suricata is multithreaded, and in several independent tests I've seen posted on the web in the past where it was compared with the current single-threaded Snort 2.x, there was not a lot of difference in packet throughput. Even multithreaded applications still have some bottleneck points where things have to come back down to a single thread.

While multithreaded is not a bad thing, and it can help in some situations, I just don't think it is the quite the "super thing" that some folks think it is.

uninstalled suricata and installed snort, seems to be working

@ravi said in Compiling Software on the Firewall:

Under this section, one thing is mentioned that create binaries in a FreeBSD similar to pfSense's FreeBsd. Copy those binaries to pfsense.

Does it work?.

I will take bro ids and create binaries and copies it to pfsense.

Thank you.

Note:
Section : " Compiling software on the Firewall" from pfsense website

Above view from First paragraph of "Compiling Software on the Firewall" section 0f
this link "https://docs.netgate.com/pfsense/en/latest/development/compiling-software-on-the-firewall.html"

Done fresh installation. Snort came. Thank you.

@ravi You mean other than via the Package Manager available from System | Package Manager | Available Packages ?

@bhjitsense said in Disk full with packet logs:

Thanks. That took care of it.
In the GUI, is there not an easy way to view/export the .pcap files that have been logged?

No. You can see the files using DIAGNOSTICS > EDIT FILE from the pfSense menu, but there is nothing within the Suricata GUI for looking at the .pcap files. It is the admin's responsibility to either view them using some CLI tool or export them off the box over to another server for analysis with third-party tools. The PHP system of the firewall does not provide a great programming environment for opening up and viewing large files.

Bill, I just rebooted and Suricata is now running! ☺

Screen Shot 2019-07-07 at 1.38.08 PM.png

yups fixed this in next release to avoid extra space.

@asterix
Could you share for us your last disablesid.conf ? maybe you have some NEWS. and that can use for snort and suricata ? or only suricata? Do you have any new post of config suricata for WAN and snort for LAN? Thanks for your help.

Best Regards,
Daniel T

You have multiple Suricata processes on the same interface. I count 5 on igb2. There should usually be only 1. Those multiple processes are chewing up your CPU.

Are you by chance trying to run the Service Watchdog package with Suricata? If so, DON"T! It will cause this issue as it does not understand how Suricata works nor how to properly monitor it.

If you don't have Service Watchdog, then something weird is happening on your box (unless you have a lot of VLANs on igb2). If you do have a lot of VLANs on that interface, I would suggest running on the parent only and not each VLAN.

To kill those errant processes (assuming you don't have multiple Suricata-enabled VLANs on igb2), do this.

Stop Suricata on whatever interface igb2 is (LAN, WAN or whatever).

Look for any remaining Suricata processes using this command:

ps -ax | grep suricata If you see any for interface igb2, then kill them with: kill -9 <pid>

That should reduce your CPU utilization to almost nothing with no traffic.

@bmeeks said in (SOLVED) Suricata Interfaces have to be manually Restarted:

@digdug3 said in (SOLVED) Suricata Interfaces have to be manually Restarted:

@bmeeks Would it be possible to check for those processes during the uninstallation of the package? So you can warn the user?

It tries to do that now, but does so by looking for a PID file in /var/run. A crashed/runaway process may no longer have a valid PID file in /var/run.

I can look at some other approaches using pgrep maybe to find all suricata processes and then force kill them. Me with Suricata and Snort, and the former package maintainers before me for Snort, have been struggling with multiple instances getting launched forever. It stems somewhat from the way pfSense itself will sometimes issue multiple "restart all packages" commands in response to WAN IP changes or changes in the WAN interface state or problems with a gateway. These multiple "restart all packages" commands can lead to multiple instances of Suricata (or Snort) running on an interface.

That sounds like a pain to deal with. It would be great if another approach could be implemented.

@wangel: Glad it's working for you. I was really pretty certain I had fixed the bug. I even went back through the binary code two more times to convince myself. All ways for that error to happen were removed from the code. So in your case, it seems you had what I call zombie Suricata processes out there, and your issues were actually coming from them as they would have been running old copies of the binary (hence the continuing error).

All fixed now, have DHCP running on each VLANs with proper FW rules! Thanks @NogBadTheBad !

This bug is corrected in the latest Suricata 4.1.4_4 package update. The release notes are here.

Perfect, thank you

If you need any logs or anything from me, let me know

Right now i have OPT1 and OPT2 as inline and LAN and Legacy Mode and it seems fine.
Its likely to affect a fairly limited number of people right now so no rush on my side for this and i'm happy to trial anything you need

Regards,
Jamie

@jake said in Snort Package - Potential New Feature Teaser:

They are all Intel I210-AT NICs. Would the PPPoE still be an issue if I'm running Inline mode only on the LAN side? I also had it Inline Mode on my VLAN interfaces, could that be an issue? Thanks for all your help. I'm happy to do any testing if needed.

No, so long as the interface is not using PPPoE, the Intel i210-AT chip should be using the igb or perhaps the em driver. First you need to verify that by looking under STATUS > INTERFACES in the pfSense menu and finding your LAN interface. The type of driver will be shown in parentheses in the header band for each interface. If your LAN is not showing one of the compatible netmap driver families I posted earlier, then inline mode likely won't work for you.

If you have one of the listed NIC driver families, then try altering the settings mentioned in this post: https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces.