Yes, it should be possible.  For that particular AppID feature, I was not the author of the code.  Another contributor from Brazil added that code and maintains the rules.  It is part of a University, I believe.  All that to say I have not examined that part of the code since the original pull request and I don't remember exactly how the URLs are handled.

I will add it to my TODO list.

Bill

Something is really hosed up someplace.  Snort just should never do that, and I can't imagine any scenario under which that could happen.  Snort is not autonomous.  Are you sure your firewall is not haunted …  ;D.

You can carefully examine the system log to see when (and if) Snort is restarting.  Do these "rule changes" coincide with restarts logged in the system log?  Is it possible someone else has access to your firewall and is making changes?

I would suggest completely removing the package and then reinstalling it.  If that does not do it, then uncheck the box on the GLOBAL SETTINGS tab for saving settings and remove the package again and reinstall it.  Of course this second method will cause a loss of all previous settings, but it's possible that may be necessary to wipe out whatever corruption must exist someplace.

Bill

@bmeeks:

The "Save Settings" option is checked by default.

Bill

Smart Decision!  ;D

Thanks Bill!

@sthames42:

@bmeeks:

I don't mean to insult an IDS/IPS admin nor impune anyone's abilities.  There are lots of questions asked here and generally the background, training and skill level of the poster is unknown.  Sometimes those of us replying make erroneous assumptions, and for that I apologize in advance (and in hindsight if I offended with my original reply as I did not intend to offend).

You didn't insult me, Bill, and I'm sorry for giving that impression. I really do appreciate the help. I was tired and frustrated with searching for information on what would seem an obvious question: what categories and rules are suggested for a fully robust IPS protecting public web, ftp, and mail servers and also acting as the portal for all of a company's access to the Internet.

I confess I'm trying to cheat, here. As IT Director, this is just one of many, many enhancements I am trying to make to our networking architecture so I just want to learn, if I can, without covering old ground, what rule categories would be suggested for my commercial network IPS.

Is there a list of categories you would suggest enabling that would give sufficient protection for the services we provide? All the recommendations I can find seem to be for home-based routers and not for a commercial web portal. Would you recommend starting with https://raw.githubusercontent.com/jflsakfja/suricata-rules/master/list.txt for my situation?

Thanks, again.
Steve

He has a very good set of rules and is an experienced Suricata user.  I have not had contact with him in quite some time.  I believe he lives in Greece and suffered some serious injuries in a motorcycle or automobile accident a couple of years ago (can't remember which).  Prior to that he was very active on the forum here.

Bill

The alerts have stopped happening all of a sudden.

I did as recommended and added snort to the individual interfaces instead of wan and now the source/destination IP internally resolves.

No, this is not possible.  Snort can only generate "reject" packets at the network level.  It can't send back a web page or web server error because it does not contain any web server code.

Bill

You're the man, bmeeks. Thank you again. Upgrading now.

@Stewart:

@sthames42:

@bmeeks:

@sthames42:

Is it possible to log and block a rule without alerting? If so, would this be done by modifying the rule in SID Mgmt so "alert" becomes "log"?

No.  This is not possible in Snort.  The custom plugin within the Snort binary that inserts the IP address to be blocked into that snort2c table mentioned above triggers on every alert.  It does not care what the rule action is.  It does not even look at the rule action.

What I would like to happen is for these intrusions, like trying to access port 1433, to not generate an alert but block all access from the IP, not just 1433. In essence, block anyone trying to access my network in a way they should not. Now, this would be redundant if the blocks that snort creates are port specific and I don't know if they are, yet.

Given so many intrusion attempts, the list of alerts is very large and it would be much easier if, after identifying an intrusion, I could not generate an alert, log the attempt, and block the IP. The only option, right now, appears to be to disable the alert. If I suppress the alert, I assume it will not be blocked.

Bill, please let me know if it I appear to be overthinking this.

Steve

I believe that once the IDS alerts and blocks an IP, the IP is blocked completely and not just for the port.  It still continues the alerts to show it is still happening, but the IP is completely blocked.

This is correct.  Blocking is done by IP address and not by IP address and port.  So all ports for the blocked IP are also blocked.  It's the equivalent of using any/any for the port numbers in a firewall block rule.

Bill

@pfBasic:

IDS/IPS are all CPU intensive. But I think your results are skewed.

There are a lot of variables to determine CPU usage beyond threads.

How many rules you are using is one of them, but more importantly the content of those rules.

A rule that only inspects IP, port and direction (like a floating firewall rule) is very CPU light.
On the other end a rule that has to inspect the IP, port, direction, header, and payload of a packet will take more CPU cycles.

Multithreading is certainly great, but it isn't magic. My guess is that either something was wrong with your snort setup or you tested suricata with different rules than snort.

If suricata were 50x faster than snort, no one would use snort.

True.  With Snort I tested with all rules enabled.  With Suricata, I tested with all rules enabled.  Even uninstalling / reinstalling Snort didn't help.  Either way I'm impressed with the overall results of Suricata.  Very quick.

Just a quick note about the IPS Policy Mode option:  it will only appear when using Inline IPS Mode and when the VRT IPS Policy option is enabled.  The option is hidden when using Legacy Mode on the interface because there is no ability to distinguish between "alert" or "drop" in Legacy Mode.  Furthermore, the option will target only Snort VRT IPS Policy rules.  The Snort VRT rules have extra metadata in them that tags a rule as belonging to a particular policy set as well as providing a suggested action (drop or alert).  The Emerging Threats rules lack this IPS policy metadata and thus can't be managed using the IPS Policy options.

Bill

Thanks Bill, I found some documentation and am looking through it.

I'll probably screw it up but I'll report what I find.

@tiramisu:

I was trolling the Suricata website and see a few different build guides for flavours of Linux.

Has anyone posted a cookbook for building Suricata w/ Cuda on the pfsense distribution and doing whatever is required to patch it into the pfsense gui?

I'm thinking this could provide an entertaining and educational hobby in the DMZ with a honeypot.

No one has done this so far as I know.  Because using Cuda is a sort of specialized thing, I did not include that in the standard pfSense package I created.  You could certainly build your own CUDA-enabled binary.  You just need to create a FreeBSD 10.x or 11.x virtual machine to use as a package builder.  Then just compile the source files from FreeBSD ports and create a package.  You could then copy that over to a pfSense box and install.  I assume you don't want blocking (you mentioned for a honeypot), so the stock FreeBSD ports version of Suricata would work.  This would mean you don't need my blocking plugin patch (which you could only get by signing a CLA and getting access to the pfSense FreeBSD-ports Github repository).

In terms of patching CUDA support into the GUI, you can configure everything by hand by adding the appropriate information to this file –

/usr/local/pkg/suricata/suricata_yaml_template.inc

That file is used to build the suricata.yaml for each interface.

Bill

Bug #6690: SURICATA IPS Issue - Kills VLANS & Traffic Shaper
https://redmine.pfsense.org/issues/6690

I'm using 2.4, it's great and very stable but no different than 2.3.x as far as this issue goes (in practice at least). Tried it with PRO/1000 & i340, no traffic shaper or VLAN. Still doesn't work yet. Just give it time.

As dok stated, security wise about the only difference is that legacy will allow a few packets before it blocks the IP and kills the state.

just switch to suricata.

You will have to disable the rule if you can't pin down the IP range.  There is no capability for dynamic DNS lookup with either Snort or Suricata.  So you can't use a DNS name in a passlist alias.  This is due to the enormous overhead DNS lookups would add to packet processing.  The thread would hang waiting for the DNS lookup to complete.

Bill

As indicated in the topic you referenced:
<qoute>Ah, my bad! The lack of a separator there as opposed to the ones above it is a bit confusing

Thank you for your time and effort.</qoute>

HAProxy works just fine here with suricata, cannot see why it wouldn't work with Snort either.