It runs alongside pfSense as a package. The logs can be configured by way of the package.

@killmasta93 said in Question about thresholds:

hi @bmeeks quick question so i added the following

threshold gen_id 1, sig_id 2009244, type both, track by_src, count 10, seconds 10, priority 1 threshold gen_id 1, sig_id 2009245, type both, track by_src, count 10, seconds 10, priority 1 threshold gen_id 1, sig_id 2009246, type both, track by_src, count 10, seconds 10, priority 1

would the variable

type both

work for both ends?

Thanks

Here is a link to the official Suricata docs describing the type: keyword: https://docs.suricata.io/en/latest/rules/thresholding.html#type-both. both specifies both a rate limit and threshold value.

I have a 2100 and I use to have issues with memory on snort updates. I installed a swap partition on a dedicated external HDD drive that was designed for heavy use, and it fixed all my update resource issues. Long story short you have to free up memory or have a plan for when it is used the most. do not rely on swap all the time, but I admit I rely on it for ClamAV updates and snort updates should the happen at the same time, Murphys law when can go wrong will go wrong, some times my blacklist, snort and clamav all attempt to update at the same time it is very rare sometimes on reboots or package reinstalls but you got to plan for it. The 2100 should have an 8GBs ram option to function perfectly, again nothing is perfect so we got to roll with it. Do a flash drive and set it up as a swap.

“the SSD manufacture had this to say about me using it like this...
"Hi Jonathan,

This will damage the drive, it is not safe. Moreover, the response speed and read and write speed are far inferior to RAM. We recommend you not to use it this way, it will probably cause the SSD to become defective."

I really want to use something long term as I am limited on what I can do with this box it has hard set ram without any way to add or remove them. The NVMe drive is the only solution outside of a USB based HDD however that like you said is very slow.

The ZFS yes is a concern with the drive however it shows with gpart as FreeBSD

I triggered a panic and it works with crash dumps also. I had Netgate forum help me with this and FreeBSD forum. I am thinking I should use a actual USB based HDD in the long run to abuse it with swap use however with a firewall that would really slow it down.

Check out
ada0s3
Shell Output - gpart list -a”

Warning Do not use your internal SSD for swap.

Ref:

https://forums.freebsd.org/threads/resolved-usb-based-swap.93362/#post-654423

This FreeBSD research I did got me going also Netgate forum if you want to make a swap.

@Gblenn Thanks for the reply. Yes, I've tried that as well. The issue is that in our particular case, we only want/need Suricata to run on some of the vlans assigned to the parent interface. The others we need to remain wide open.

I was looking for this info @bmeeks,

Now I am sure that it is only an internal connection and that not everything is disabled.
Thank you very much!

Have a nice day and thanks for your work.

Hello @bmeeks,

This was indeed exactly what happened.
I have rebooted my pfsense server in the past, which I would expect create same results, but either it didn't work, or it spinned another ghost process afterwards.

Anyways, I will monitor to see if it keeps happening.
I have seen other posts where other people have similar issue indeed, and will investigate from there if duplication happens again.

In any case, thank you very much for your kind help here.

@bmeeks THank you so much will do thanks

Sorry I am late to this party. I had issues with STUN and the IPS blocking traffic. It was for my son’s Nintendo switch and Xbox for the chat feature. Once I suppressed the alarms the chat live voice feature worked perfectly. I also think that FaceTime requires you to suppress the STUN alarms. Long story short STUN is finally working on my system as of today.

@kiokoman said in Some questions from a beginner:

@bmeeks
what about suricata, is it the same file ? snortrules-snapshot-29200.tar.gz ?

Suricata is not tied to any specific rules version. And in fact, Suricata is really not designed to be 100% compatible with Snort rules. Most of them work, but quite a few (several hundred) do not due to the differences in keyword syntax between Suricata and Snort.

With the Suricata package, users are free to download and install any Snort rules version they desire so long as it is compatible with the 2.9.x branch of Snort. You cannot use any Snort3 rules with Suricata. That will break the installation of the package quite badly! But you can use the 29161, 29181, or 29200 Snort rules package with Suricata. It is only the Snort binary that is locked to specifically matching rules versions.

@DaHai8 said in No Snort Alerts after moving behind ISP Router:

My ISP recently forced their crappy Router/Fibermodem combo on me and I had to move my pfSense CE (Current) behind it. Now I don't get any Snort alerts.
Is this normal?

You were seeing Snort alert on normal "Internet noise". That refers to the constant barrage of traffic from various nefarious sources that your pfSense firewall rules were going to block.

As stated by @SteveITS, Snort sees traffic on pfSense before the firewall rules are applied. That means when run on the WAN it would have been alerting on that noise, but your pfSense WAN interface firewall rules would block that traffic anyway. So, in effect, you had Snort chewing up CPU resources and RAM for very little or no gain as the firewall is going to block nearly all of that traffic anyway. Much better to run Snort on the firewall's internal interfaces such as the LAN and/or DMZ.

Now as to your question, "yes" Snort is still working, But the NAT feature of your ISP's router is probably hiding that traffic now as the router will have its own built-in stateful firewall.

@bmeeks Glad to hear that you're ok, thank you for the Suricata release, even in these conditions.

My guess would be that if you’re moving the file over SMB, it’s likely to be on the same network, so would never actually touch the firewall to be detected.

If you want to specifically enable rules that are "default disabled" by the rule authors, then you can do that on the RULES tab by selecting the appropriate category, finding the rule by SID in the list, and clicking the "Force Enable" option for that specific rule.

You can also use the SID MGMT tab features to do this. Examples are provided in the sample conf files on that tab.

The rule authors will disable a number of rules in their rulesets. This is something many users do not realize. Rules that are prone to false positives in many environments or rules that address very old threats are frequently provided in a "default disabled" state.

Also, when using IPS Policy for rule selection, you should be aware that ONLY the Snort VRT ruleset contains the IPS Policy metadata required to automatically select rules by policy. The Emerging Threats rules do not contain IPS Policy metadata and thus are excluded from IPS Policy management.

@bmeeks Hello, that's exactly what I did. I ran Snort on the parent interface and not on the VLAN. However, as you suggested, there must be an issue with the Broadcom network card drivers.

Here is the Redmine Issue for this bug: https://redmine.pfsense.org/issues/15744.

Thank you for reporting it.

@magician-balmy-stainable said in Enabled Suricata on LAN interface, now can't access pfSense browser interface?:

How can I regain access and/or fix this?

You are going to need to access the console interface directly to fix this. You did not tell us anything about your hardware, so I'm giving the suggestions below based on the two most likely possibilities:

Assuming you have whitebox hardware, get to the keyboard and monitor attached to the pfSense machine and login to the CLI (command line interface). After logging in to the firewall, choose Option "8" to exit to a shell prompt and type this command to stop all Suricata instances: /usr/local/etc/rc.d/suricata.sh stop If you have a Netgate hardware appliance, you will need to find and attach the USB serial console cable to access the CLI. After getting that connected and working (just like you did when you first configured the device), exit to a shell prompt and follow the same directions as given above for logging in and stopping Suricata.

If you are using Inline IPS Mode, stopping the service should restore GUI access. If you are using Legacy Blocking Mode, then you will need to also clear out the snort2c table to remove any lingering IP blocks. Do that with this command from the shell prompt:

/sbin/pfctl -t snort2c -T flush

At this point you should be able to access the web GUI login. I would immediately navigate to Suricata under the SERVICES menu and edit the LAN interface where you have Suricata enabled and either disable it on that interface or turn off the blocking mode by unchecking the Block Offenders checkbox. Save the change. If you fail to do this, then Suricata will get automatically restarted at some point and you will likely find yourself locked out again.

I am fairly certain you have a misconfiguration problem because Suricata has several built-in options to prevent locking you out. Either you have a fundamental hardware compatibility issue, or you have a significant misconfiguration of the package.

@magician-balmy-stainable said in Enabled Suricata on LAN interface, now can't access pfSense browser interface?:

Why did this happen?

Can't really say with certainty because you gave us very little information to go on.

What hardware are you using? What version of pfSense and what version of the Suricata package? What is your network topology? (what's connected to what?). Are you using Legacy Mode Blocking or Inline IPS Mode?

Note that if you are a first time Suricata user, then I highly recommend that you NOT enable blocking when first installing the package. Instead, install it, choose the rules to enable, then let it run on your network for a few days or weeks and regularly monitor the alerts received on the ALERTS tab. See what things are generating alerts and deteremine whether they are legitimate alerts or false positives. Tune the enabled rules and create appropriate Pass Lists (if you intend to use Legacy Mode Blocking) or custom PASS rules (if you intend to use Inline IPS Mode).

@Tantamount said in inline custom pass rule no workie?:

I wonder, if you are still able to edit that 2018 post and correct the examples,

I should be able to. Will give it a whirl.

Update: fixed it!

@bmeeks said in Snort - Unable to Select Subscriber Ruleset:

I am the volunteer package maintainer for Snort and the creator/maintainer for Suricata on pfSense. I tried on two different occasions to create a Snort3 package and gave up in frustation because of the massive amount of rewrite required for essentially very little gain compared to Suricata.

Oh wow, I am even more humbled now. Thank you for your contributions to the Snort and Suricata projects!