AppID alerts question
-
I just noticed the update for alerts tab.
I just installed it thank you !!! -
I forgot I have to add the custom rules for the text that is not mapped over yet right? Starting at 1000000. I also found one to detect and alert on ChatGPT :)
alert ip $HOME_NET any -> $EXTERNAL_NET any (msg:"iTunes";flow:from_client;appid:itunes; sid:1000000 ; classtype:misc-activity; rev:1;) alert ip $HOME_NET any -> $EXTERNAL_NET any (msg:"iCloud";flow:from_client;appid:icloud; sid:1000001 ; classtype:misc-activity; rev:1;) alert ip $HOME_NET any -> $EXTERNAL_NET any (msg:"LinkedIn";flow:from_client;appid:linkedin; sid:1000002 ; classtype:misc-activity; rev:1;) alert ip $HOME_NET any -> $EXTERNAL_NET any (msg:"ChatGPT";flow:from_client;appid:chatgpt; sid:1000003 ; classtype:misc-activity; rev:1;)
With the help of . . . /usr/local/etc/snort/appid/odp/appMapping.data
-
@JonathanLee said in AppID alerts question:
I forgot I have to add the custom rules for the text that is not mapped over yet right? Starting at 1000000. I also found one to detect and alert on ChatGPT :)
Yes, you will possibly need to create your own supplemental AppID text rules for some of the newer AppID stubs in the updates that come down from the Snort Vulnerability Research Team.
Remember that the AppID text rules package is a very old variant created by University volunteers several years ago. It has not been maintained, so that means it will lack the necessary rules for some of the newer apps. There were also a few typos in some app names in those rules (or else the Snort VRT changed the names slightly since the text rules were developed).
-
The one big shortcoming of OpenAppID is the dearth of available and maintained text rules that must be used with the stub detectors. Without matching text rules for each AppID stub detector, there will be no alerts.
Much like lists of IP addresses that must be created and maintained for known bad actor and poor reputation blocking, you must have someone creating and maintaining the associated text rules for OpenAppID to work corrrectly in Snort. It's these associated text rules that are not being maintained, and thus OpenAppID loses some of its usefulness because without the text rules you will not get alerts for some application traffic. But maintaining such a collection of rules is labor intensive and nobody wants to do it for free. As of yet, I have not located an available package of OpenAppID text rules that is current and maintained.
Users are certainly free to create their own custom OpenAppID text rules to match up with all the available detector stubs provided by the Snort VRT, but that takes a good bit of effort.
-
@bmeeks I did try Bill. I dont know if you remember but we had a talk about this maybe a year or two ago.
To keep the list current i compared what was in here https://appid.cisco.com/home and seeing if there was a corresponding text ruleI created maybe 200 and then stopped. Its an impossible task if it's one person. This is why this is a paid service from other vendors. There is no way to keep on top of writing text rules with new appids without some level of automation or a team for oversight.
-
@michmoor This could be fully automated with use of /usr/local/etc/snort/appid/odp/appMapping.data for iterations. Make a string in java and iterate for lower case strings add all the rules at once. It is really easy to code it with java. I will download the file and do a one time conversion to a new text file to add to custom but it will be huge. It may take some time but I have a good idea on how to do this with Java's scanner object now that I understand it. Only took me a couple years.
Here is a nice reference:
https://forum.netgate.com/topic/183210/guide-snort-s-appid-custom-rules-quick-guide-to-blocking-example-shows-openai-chatgpt-or-itunes
-
@michmoor said in AppID alerts question:
Its an impossible task if it's one person. This is why this is a paid service from other vendors. There is no way to keep on top of writing text rules with new appids without some level of automation or a team for oversight.
100% agree with this sentiment. But apparently vendors do not sense a wide level of interest/desire for this kind of product and thus no promise of a revenue stream large enough to fund the effort and produce some amount of profit.
This is one of the reasons I've become sort of soured on Snort. Not "soured" in a bad way, but rather because there is no active support and interest in its most distinguishing feature (when comparing Snort to Suricata): OpenAppID. Without OpenAppID, Snort really trails Suricata due to Suricata's multithreaded nature and its extensive logging options.
-
@bmeeks said in AppID alerts question:
This is one of the reasons I've become sort of soured on Snort. Not "soured" in a bad way, but rather because there is no active support and interest in its most distinguishing feature (when comparing Snort to Suricata): OpenAppID. Without OpenAppID, Snort really trails Suricata due to Suricata's multithreaded nature and its extensive logging options.
I get what you're saying completely. There's potential there but not a lot of commitment to bettering the product.
Until there is functional and automated way of writing these rules and importantly categorizing the apps and text rules correctly its difficult to recommend OpenAppID as is. -
@JonathanLee Your solution doesn't take into account categorizing the apps as well which is a huge undertaking and arguably the hardest part.
-
Here is, the fully converted appMapping.data to text file...
The pfSense Snort AppID de-cipher sorcerer's code file: --> textrules.txt
Sid range: 1000000 - 1003371
Total 3,371 AppID rules you can use with the custom option.
I converted it with a Java program I just made. The message is the same as the appid match it makes it easier.
Some of the ieee items are bigger but they seem to match.