Probably false positives.  There have been some reports of flakiness with the TLS decoder rules in Suricata of late.  There is a post on the Suricata Redmine site about some other TLS issues.

Bill

Looks ilke a syntax error in one of the Emerging Threats rules.

Bill

@hescominsoon:

I currently run pfsense 2.3.4 under hyper-v.  The issue i am experiencing with suricata is when it gets an alert triggered instead of blocking the host that causes the alert it kills the entire interface.  I have read how inline is a bit buggy…is this another inline bug for suricata?

It's not necessarily a Suricata bug.  Inline mode is entirely dependent on Netmap for operation, and Netmap in turn is totally dependent on 100% support from the NIC driver.  There are only a tiny handful of NIC drivers that fully support Netmap on FreeBSD.  From your experience, it seems the Hyper-V NIC drivers are not on that list.  Netmap inserts itself between the NIC and the rest of the operating system.  Nothing moves from the Ethernet wire into pfSense (or from pfSense into the Ethernet wire) without going through the Netmap layer.  The NIC driver has to understand how to talk to Netmap.  Any inconsistencies in how the NIC driver interracts with Netmap will cause problems with Suricata inline mode.

Bill

The pull request for the GUI package update to support Snort 2.9.9.0 update has been posted.  Here is a link:  https://github.com/pfsense/FreeBSD-ports/pull/361.

This should get merged into 2.4-BETA very quickly, and then appear a bit later for the 2.3.4 RELEASE and 2.3.5 snapshot builds.

Bill

@tortue:

Only path forward I can think of at the moment is a log rule and handling the log parsing and dedupe individually and using a FW alias for that deduped file.

Correct, that would be a way to do it, but it is a bit labor intensive to develop.  I would challenge if the effort was worth the gain, though.  The firewall is already going to drop inbound traffic that is unsolicited or that does not match an open port.  Good operating practice says to keep all Internet-facing public services (web, email, etc.) well patched and hardened.  Having an automated system that locks out an IP due to it attempting to connect to a single non-existent port could be an issue for a commercial enterprise.  Suppose the user who is also a customer of yours just fat-fingered the hostname or accidentally used your hostname when he was trying to connect to another service (RDP perhaps) when he meant to use another.  Now his IP will be blocked from any contact with your domain, including your web site.

Of course if you are strictly a home user, then none of the above matters to you.  But at the same time, as a home user you likely have no public-facing services (and thus open ports), so why bother?

Bill

When you select and enable an IPS Policy, that overrides manual selection of Snort VRT rules – hence the red mouse cursor.  Those checkboxes are disabled by design when using an IPS Policy.  This is because the chosen policy is determining which of those grayed-out categories and rules to use.

Bill

This is a bug within the Suricata binary itself.  It has been reported to Suricata upstream and will be fixed in the next release, I think.  It is only a warning and will not affect operation.

Some changes were made to a section of code in the 3.2.x series, but one line got missed when those changes were made.  You can find the bug report and details on the Suricata Redmine site.

Bill

Thank you that's very good to know for the future!

Currently the GUI package builds a snort.conf file configured for alerting and capturing packets related to those alerts.  It was never intended to use Snort like Wireshark on pfSense, so that capability is not part of the standard snort.conf generation.

Bill

thanks Bill

you tha MAN

@Ghostdragon97:

That did the Trick. Thanks for the help! All rules updated just fine.

Glad you got it going.  The /tmp directory is where the tar.gz files from the rules update are downloaded and then unzipped.  From there they get copied to /usr/local/etc/snort/rules.  You need enough free space on /tmp to hold the tar.gz rules package and then the unzipped contents as well.  I included /var because that's where log and alerts files go.  That volume can fill up on you as well.

Bill

https://forum.pfsense.org/index.php?topic=91844.msg508332#msg508332

There once was a web site out there where you could do that (match a GID:SID with category).  I'm not sure it exists or is maintained anymore.  I no longer have the URL.

You can open a CLI prompt on the firewall and use grep to find a GID:SID within the rules.  To search all the available categories, grep all the *.rules files in this directory for Snort:

/usr/local/etc/snort/rules/

If you have Suricata instead, then search the files in this directory:

/usr/local/etc/suricata/rules/

Bill

thanks I got it working…. and yes I red X'ed it...

@bmeeks:

Some guesses on my part –

Something on your laptop was maybe trying to swap some AFP share info with FreeNAS.  That would not really be unexpected if you also use the laptop at home on the LAN.

When you are home and everything is within your LAN, Snort will not necessarily be seeing NAS-to-laptop traffic as everything would be switched at layer 2 by your network switch.  So no alerts then if Snort and firewall does not see the traffic.

When you are on the road, Snort sees everything on the VPN as it comes in from the WAN and gets sent on to the LAN.

As for the alert itself, it could very well just be some kind of false positive in your setup.  Maybe some fragmentation is/was happening on the VPN side ???

Bill

You are right of course that snort would not see this traffic if I was home.  The alert must be a false positive.  I'll suppress it.

Thanks for all the work you do on the snort package.

Thanks a alot, Bill  ;)

Yep, the current pfSense release versions and the 2.4-BETA have supported versions of Snort.  As soon as FreeBSD ports updates to a new Snort version, I try to get it submitted to the pfSense team for inclusion in the current release.  It is often times not possible to backport a new Snort to older pfSense versions due to changes in other dependent libraries.  Best to try and keep your pfSense installs in sync with the current release.

Bill

I'm also happy to report that transferring a sample .ISO file of a few gigabytes over HTTP with pattern matcher being set to AC resulted to 15-20M/s speeds with my connection. With HyperScan I'm seeing 24-29+M/s which is very close to the line speed.

I'm on a 250/50 fiber.

fiber.PNG
fiber.PNG_thumb

Figured it was now a good time to try out Suricata :)

@nagaraja:

Hey Bill,

for the infos i got, the only address snort is able to understand and whitelist, is only the URL address record inside URL alias. In other terms http://myserverip:port/list.something instead of the list content. I  also think this could be bad for snort since it allows numeric values only

Thanks for your quick reply

Yes, if the text URL got written into the actual passlist/whitelist file produced for the Snort binary that would cause errors.  However, the code in the binary plugin that parses the pass list entries will discard any non-numeric values and print an error to the system log.  So it should not cause the entire pass list to be ignored.  Just the offending line or lines would be ignored.

Bill