Open Appid Signatures - Updating?

michmoor

Curious if anyone is not only using OpenAppID on Snort but does anyone have an updated appMapping.data file which is the signatures used by OpenAppID.

The file on pfsense shows it hasnt been updated since 2023 which if we are talking about application identification, is a very long time ago.

-rw-r--r--  1 root wheel  124K Jun  9  2023 appMapping.data

The Snort updates job runs and runs with success so without diving deep into this you would be mistake to believe that you are getting the updated signatures for app detection...Seems not to be the case. If so, this makes Snort OpenAppID implementation on pfsense not very good.

mcury

@michmoor said in Open Appid Signatures - Updating?:

The file on pfsense shows it hasnt been updated since 2023

I believe that date is when you installed that pfSense.
If you check, last update for openapp id was in 2022, version 2.9.20.

As far as I know, openapp id was maintained by a university in Brazil, but they dropped to project..
Then, snort updated it a few more times and also stopped.

michmoor

@mcury said in Open Appid Signatures - Updating?:

As far as I know, openapp id was maintained by a university in Brazil, but they dropped to project..

Those would be the text rules which are extremely outdated.

But you are correct, the Snort2 binary the last updated appID detectors is 2.9.20.....damn.....

Thanks for confirming my thoughts on this feature.

bmeeks

Although I've seen nothing official, I suspect the time is getting near where upstream Snort will officially deprecate the Snort 2.9.x binary tree. When that happens, OpenAppID will also cease to updated as I suspect the format is quite different for Snort3.

Folks using Snort on pfSense should really consider migrating to Suricata. Or at least install the package in a virtual machine and learn how it operates. Because once Snort 2.9.x is pulled from upstream, there will be no Snort package on pfSense unless someone takes it upon themselves to create a Snort3 package.

michmoor

@bmeeks the only thing missing from Suricata is the ability to define “balanced “ “security” and “connectivity” rule levels.

bmeeks

@michmoor said in Open Appid Signatures - Updating?:

@bmeeks the only thing missing from Suricata is the ability to define “balanced “ “security” and “connectivity” rule levels.

Well, someone could try lobbying Emerging Threats to add that policy-level metadata to their rules. That feature in Snort is driven by the policy metadata the VRT includes in the Snort rules archives. Emerging Threats chose not to do the same for their rules. Suricata was/is sponsored by Emerging Threats, thus it it optimized and designed for ET rules. It can load and run many Snort rules as well, but just not all of them.

The real story is that perimeter IDS/IPS is on the way out unless you devote time, effort, and energy into MITM proxying. Otherwise, why waste CPU and RAM resources scanning packets to realize they are encrypted then bypassing further inspection? That's what the IDS/IPS packages are doing today -- bypassing the encrypted packets. To me the future would be hooks placed into web server engines that allow decrypted traffic to first be inspected by an IDS/IPS before it hits the web server executable. This would all happen directly on the web server box, though, not at the network perimeter where things are still encrypted. You would, for example, run Suricata on the web server as a separate deamon, and the web server engine (say Apache, for instance) would provide a "hook" to route incoming traffic after decryption over to the IDS/IPS for inspection before sending it on to the guts of the web server itself for action.

michmoor

@bmeeks said in Open Appid Signatures - Updating?:

The real story is that perimeter IDS/IPS is on the way out unless you devote time, effort, and energy into MITM proxying.

Well i would argue its all about placement.
I have firewalls (IPS/IDS built in) that police traffic DC <-> DC [East-West flows].
Yes if the majority of your traffic flows are to the Internet then an IPS is less effective as that is likely to be TLS encrypted but between datacenters you can detect unusual traffic. Its all about security in depth. I would rather have an IDS than not have one.