@jonrusk said in snort install - rules md5 checksum failed: @bmeeks Yes and that appeared to be the issue. I increased the size of /tmp on RAM disk and Snort installed successfully. Thank you! Note that I don't recommend using RAM disks with either of the two IDS packages (Snort or Suricata). Most especially for /var where the log files are written. And not having enough free space on /tmp, as you experienced, leads to problems as well. Those two packages were not created with RAM disk usage in mind. They really want a spinning disk (or conventional SSD) with a fair amount of space for logging.

@michmoor I'm exporting logs to it, but not netflow.. Using these extractors to parse the data: https://github.com/loganmarchione/Graylog_Extractors_pfSense

I'm still waiting around to update Suricata. The Netgate team pulled in the latest 6.0.5 Suricata version in the pfSense CE 2.7 DEVEL branch. The pfSense CE and Plus RELEASE branch is still running the 6.0.4 Suricata version. There is really not a ton of changes between those two that would impact typical pfSense users. I'm monitoring the progress on 7.0rc1 and 6.0.6 from the upstream GitHub repo.

@bmeeks Hi bmeeks, Thanks for your answer. Greats, I have changed the category name into my Sid file and it perfectly works. Appreciate. BR L.

@ezvink May be so, however, you had WAN in host-only Adapter mode so you shouldn't have any DNS issue...good luck!

@bmeeks In my case, VLANs are mandatory. In the end only an implementation that allows VLANs to work fits my needs. Hope at least on pfSense, they will still work in future releases too. Thanks for the hint.

@le_bleu said in Suricata memory usage very high: Pfsense 2.4.5.r.20200318.0600 This is a beta release of 2.4.5 and more than 2 years old. You should upgrade to 2.5.2 at this point or at least the RELEASE version of 2.4.5.

@juniper said in snort and span interface: @bmeeks said in snort and span interface: @juniper said in snort and span interface: Hi, is it possible to use pfsense snort with a span interface as sensor? thanks in advance No, that configuration is not supported. If you want to do something like that, I recommend a dedicated FreeBSD or Linux machine running the base Snort package from whichever distro you choose the OS from. There would be no GUI, though. Thank you! Just to clarify, I have a pfsense firewall with snort on a wan bridge (but in this way i can't check https traffico), my needing is to analyze http traffic over a reverse proxy (reverse to private network, reverse https to private network http), if i undestrand the only way is to create another bridge? Bridges can get very messy, and Snort really does not understand those (meaning the Snort package on pfSense) as it's not designed and plumbed up operate with that configuration on the interface. It expects a traditional single network interface. Not saying you might not could get it to somewhat work with duct tape, baling wire, and glue, but it's not a setup I would recommend. For your setup, I would lean more toward the span port option using a separate and dedicated Unix-type distro to run Snort. And I mean Snort as a package from that Unix distro and NOT the GUI package used on pfSense. That would mean interacting with Snort via the CLI.

@bmeeks perfect, very very very thanks

@bmeeks Thanks for the reply, if I see this issue again I will definitely look for additional snort processes running.

This is a harmless error. It means there is a mismatch between the name of an AppID entry as used in a text rule compared to the name in the OpenAppID stub detectors. This is a consequence of the fact the OpenAppID text rules have not been maintained by the original developer. You can manually grep through the various configuration files in the OpenAppID subsystem to identify the problem areas and fix them if desired. Sorry to say that more and more problems like this are going to crop up in OpenAppID for the Snort 2.9.x branch as the upstream Snort folks have concentrated all their efforts on the Snort3 branch. There is no Snort3 package for pfSense, and currently there is no plan to produce one. You may want to consider Suricata at some point, but there is no equivalent of OpenAppID in Suricata yet.

@jonathanlee the baseline has about 3 every morning that show and about 2 in the day time. [image: 1652192666473-screen-shot-2022-05-10-at-7.22.09-am-resized.png] Image: I use to see a lot more nmap scans caught during the night

@bmeeks Its not working in 2.5.2 but I havent tested 2.6.0 yet since its unstable and lack VLAN performance.

@bmeeks said in Suricata Update Plans: The Suricata team recently released version 6.0.5. Details about this latest release can be found here. I plan to update Suricata on pfSense in the near future. Currently we are running the 6.0.4 version compiled with the multiple host rings netmap code from version 7.0. I want to wait a few days, or perhaps even a couple of weeks, to see how things look in the new 6.0.5 release. If no major issues are reported upstream, then I will update the binary portion of the pfSense Suricata package to 6.0.5. Just wanted to post this info to let Suricata users know I am aware of the recent release of 6.0.5, and I plan to update the pfSense package soon. Just don't want to immediately jump out there yet having gotten burned with the initial 6.0 release that had the FreeBSD flow manager bug. Please take your time, better safe than sorry.

@bmeeks see the commit [1], thank you. [1] https://github.com/pfsense/FreeBSD-ports/commit/b48f7bee696c7b9a3ad811b8a85f4aa3dfeb9a22

Pull Requests have been submitted to correct this issue in both the DEVEL and RELENG_2_6_0 branches of pfSense. I attempted to make the code a little more tolerant of any future path name changes in the Snort Rules update archive file. Look for a Snort package update to version 4.1.5_3 in the near future. The requests are here: https://github.com/pfsense/FreeBSD-ports/pull/1161 https://github.com/pfsense/FreeBSD-ports/pull/1162 In the meantime, if you hit this bug before the package update is posted, the quick fix is shown in an earlier post of mine above. UPDATE: the pull requests listed above have been merged into their respective pfSense branches.