Requesting input on adding new features to Snort pkg from experienced users

bmeeks

Hi Snort package users:

I have been going through the feature requests for the Snort package on pfSense, and I could use your help in prioritizing them and also any suggestions for actually implementing them.

Here are the top three that seem to be most popular, but not in any particular order.

1. Add support for custom rules download URLs. This would let you provide URLs of your own where rules other than the built-in VRT, ET and Community Rules could be downloaded. Not sure of the difficulty here, though. For example, would the alternate URLs provide gzip tarballs like the built-in rules providers do; or would the code need to be smart enough to cope with both gzip tarballs and plain text files? Does anyone have some popular examples of alternate URLs for downloading Snort rules?

2. Add support in the GUI to make auto-creation of OpenAppID rules easier for less experienced users. The OpenAppID feature is pretty neat, but I think it is under-utilized in the Snort package due to the cumbersome process for using it. You enable the preprocessor, and then you have to create your own manual custom rules. Perhaps there is a way to provide some "canned rules" for the more popular OpenAppID detectors???

3. Support for Fully Qualified Domain Name (FQDN) aliases on a PASS LIST. This would work by leveraging the current process controlled by the filterdns daemon on pfSense. Defined FQDN aliases would be queried periodically by a thread in the Snort blocking plugin to grab the current IP address or addresses for the alias. Those would be maintained as part of the in-memory pass list the plugin already maintains. The big thing to remember about this process is that it will not be real-time! The filterdns daemon updates IP addresses for FQDN aliases approximately every 5 minutes. The Snort blocking plugin would be waking up and querying the FQDN alias tables in pf at a periodic rate, so it would be possible for an FQDN alias on the PASS LIST to still get blocked if the IP address changed in between update intervals and a Snort alert was triggered on the new IP before the thread awakens and updates the in-memory pass list again. It would likely work the majority of the time, but it would not be 100% bullet-proof.

So reply back with your suggested priority for the three items I listed. Also feel free to add an item to the list if you think I missed one or you have a fresh idea. Any other suggestions on implementation are also welcomed.

Finally, it goes without saying that some pre-release testing will be required for the chosen new features. Let me know in your reply if you have a test environment and would be willing to install alpha or beta versions of the Snort package to help shake bugs out of any new features.

Thanks,
Bill

musicwizard

realy good job on the Snort package :)

The i would say.

2 , 1 , 3

well i think for number 1. you could use only .gz for now. like https://www.iblocklist.com/ where you can choose GZ, zip or 7z for the archive format. For the File format it says p2p not sure what for format that is but that is what i always used with my blocklists on my PC. which i want to move to the router so it will be used on the whole network including mobile etc.

for 2
i have it enabled and checked some things but i didn't setup any custom rules for it. No idea what for rules to setup for that or where. Does it even work now?

for 3.
this is for allow lists? like if you don't want www.facebook.com to be blocked you put it on the pass list and it will check for the IP it has every 5 min?
Can it also be used as block list? like you add stuff like ads.youtube.com that it will list the ip'ss that are linked to it and block those ip's and then checks every 5 min ( or a manual entered time with min 5 min interval).

bmeeks

@musicwizard:

for 2
i have it enabled and checked some things but i didn't setup any custom rules for it. No idea what for rules to setup for that or where. Does it even work now?

In order to use the OpenAppID processor, you must enable the preprocessor on the PREPROCESSORS tab and then create the necessary custom rules on the RULES tab (choose "custom" in the rules category drop-down), but it does work. Some other users have posted a few example OpenAppID rules here in the past. You could try searching for "OpenAppID" in the IDS/IPS sub-forum.

@musicwizard:

for 3.
this is for allow lists? like if you don't want www.facebook.com to be blocked you put it on the pass list and it will check for the IP it has every 5 min?
Can it also be used as block list? like you add stuff like ads.youtube.com that it will list the ip'ss that are linked to it and block those ip's and then checks every 5 min ( or a manual entered time with min 5 min interval).

No, the FQDN alias would only work for allowing something (a PASS LIST contains IP addresses that will never be blocked and are considered always friendly). You could use OpenAppID rules for blocking content such as Facebook. That works today, but as I mentioned above you must create the required custom rule to go along with it. Again, some users have posted a few examples here in the past.

Bill

athurdent

+1 for 2,1,3.
It would be really great to be able to configure OpenAppID!
And as usual many thanks to Bill for taking care of the IPS/IDS packages!

spittlbm

I third 2,1,3. I do not have a test environment.

Brian

I have a suggestion strictly from my end user point of view. Personally, I wish that there was more of a graphical style status window to add to the pfsense status screen where you have the ability to add windows for items such as service status, NTP status and such. There is a snort block list item that can be added but I wish there was something that was again to graph similar to stock a stock and bonds graph. This would be a cool way to see how active snort is at any given point combined with little flags that pop up on the line when snort blocks activity.

Sorry if this is not explained well.

musicwizard

@jbhowlesr:

I have a suggestion strictly from my end user point of view. Personally, I wish that there was more of a graphical style status window to add to the pfsense status screen where you have the ability to add windows for items such as service status, NTP status and such. There is a snort block list item that can be added but I wish there was something that was again to graph similar to stock a stock and bonds graph. This would be a cool way to see how active snort is at any given point combined with little flags that pop up on the line when snort blocks activity.

Sorry if this is not explained well.

A RRD graphs how active it is per lets say 5 min otherwise it might be hard to track like at 00:00 10 ip/ranges are blocked at 00:05 20. this is then the total amount of blocks. if ip/ranges are unblocked after some time the graph should go down.

something like this JBhowlesr?

Absolutely. It would be nice to have something graphical to see what snort is doing. Even if it only operated over a minute or two window. Always running, but auto clearing anything older than the defined snapshot.

Another feature id like to see would the ability to specify CPU core for snort to run on. In my rig, I am using parts from a recent computer upgrade. Essentially, a intel Z77 motherboard and a 3rd Gen Quad Core i5 CPU. I realize that most of the work is being via the NIC cards processor but if say the pfsense system ran on core 0, the pfsense firewall ran on core 1, and snort utilized core 2 + 3 for IDS and IPS respectively. All these functions, while having their own processor core could truly run independently and have dedicated processing power.

musicwizard

@jbhowlesr:

Another feature id like to see would the ability to specify CPU core for snort to run on. In my rig, I am using parts from a recent computer upgrade. Essentially, a intel Z77 motherboard and a 3rd Gen Quad Core i5 CPU. I realize that most of the work is being via the NIC cards processor but if say the pfsense system ran on core 0, the pfsense firewall ran on core 1, and snort utilized core 2 + 3 for IDS and IPS respectively. All these functions, while having their own processor core could truly run independently and have dedicated processing power.

would be nice if it can use all cores.

mine atm is
SIZE RES STATE C TIME WCPU COMMAND
1097M 644M nanslp 0 91:07 24.27% snort

Load averages: 0.22, 0.30, 0.35 up 5+23:33:20 18:11:06
38 processes: 1 running, 37 sleeping
CPU: 4.2% user, 0.0% nice, 0.2% system, 0.2% interrupt, 95.4% idle
Mem: 287M Active, 499M Inact, 534M Wired, 346M Buf, 6497M Free
Swap: 16G Total, 16G Free

wcpu uses 24% atm for 2 computers. and soon another 2 will be added.

i got a
Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
Current: 1992 MHz, Max: 1993 MHz
4 CPUs: 1 package(s) x 4 core(s)

fsansfil

Request input

Inline
Inline
Inline
at least a way to alert and drop, meaning in the same ruleset and interface we can alert (and send offender to pf tables) and alert (more like the real alert, no sending to pf table)

About Snort's AppID
The simple option to easily create AppID rules would be, print the content of appMapping.data in the GUI and let user select an app.
This would create a simple alert any any -> any any

Example: select Flickr in the GUI, this generate
alert any any -> any any (msg:"pfSense's Snort Block Rule for Flickr; appid: "flickr"; classtype:policy-violation; sid:12171008; rev:1;)

The cool way
The value added way, would be to let the user really customize the appID rule. Create a GUI where the user can specify rules options.


 [OPT1]                [OPT2]          [OPT3][OPT4]           [OPT5][OPT6]          [OPT7]             [OPT8][OPT9]              [OPT10][OPT11]                    [OPT12]
 [AppID]             [protocol]         [!] [src]             [!][sport]          [direction]           [!][dst]                   [!][dport]                    [priority]
 [AppID]                [ip]             [any]                   [any]               [->]                [any]                       [any]                      [appID priority 1]
 [AppID]                [tcp]        [$EXTERNAL_NET]          [yaml_defined$]        [<-]             [$EXTERNAL_NET]            [yaml_defined$]                [appID priority 1]
 [AppID]                [udp]         [$HOMEL_NET]            [pfsense_alias]        [<>]               [$HOME_NET]               [pfsense_alias]               [appID priority 2]
 [AppID]                             [yaml_defined$]           [user_input]                           [yaml_defined$]              [user_input]                 [appID priority 3]
 [AppID]                             [pfsense_alias]                                                  [pfsense_alias]                                           [appID priority 4]
 [AppID]                              [user_input]                                                     [user_input]

Example:
OPT1: the user select HTTP from the AppID dropbox
OPT2: the user select ip from the protocol dropbox
OPT3: the user select ! from the negate option dropbox
OPT4: the user select HTTP_PROXIES from the source dropbox, HTTP_PROXIES is a pfSense IP Firewall Alias for the user with 10.11.10.11 and 10.12.10.12
OPT5: the user doesnt select the negate option for source port
OPT6: the user select PROXY_PORTS from the source port dropbox, PROXY_PORTS is a pfSense Port Firewall Alias for the user with 8080 and 8181
OPT7: the user select [->] as the direction
OPT8: the user doesnt select the negate option for the destination
OPT9: the user select [$HOME_NET] option form the destination dropbox
OPT10: the user doesnt select the negate option destination port
OPT11: the user select any from destination port
OPT12: the user select priority 2 form the priority dropbox

Bill and his voodoo skills print and send this rule to the custom_appip ruleset:

alert ip [10.11.10.11,10.12.10.12] ![8080,8181] -> $HOME_NET any (msg:"pfSense's Snort Block Rule for HTTP; appid: http; classtype:appid-priority-2; sid:12171008; rev:1;)

F.

simby

2,3,1 + inline / drop :-)

bmeeks

Thanks for all the ideas and implementation suggestions guys. This gives me a lot to think about over the next few months.

Bill

2,1,3
Virtualized test environment present so would be glad to help

Regards,

Emanuel

musicwizard

Will you also be upgrading it to snort 3.0?

bmeeks

@Music:

Will you also be upgrading it to snort 3.0?

No, not in the near-term. No upgrade on pfSense until Snort 3.0 goes full production and is not ALPHA or BETA software. Also will not happen until the FreeBSD ports maintainer for Snort updates the package here. Finally, there is a distinct possibility that Snort 3.0 will lose the ability to block offenders on pfSense. I have not investigated this in detail, but I do know that the Snort team is deprecating the output plugins API that the custom blocking module for pfSense depends on. If the API hooks the current blocking module depends on are not in Snort 3.0, then blocking won't work.

Bill

musicwizard

@bmeeks:

@Music:

Will you also be upgrading it to snort 3.0?

No, not in the near-term. No upgrade on pfSense until Snort 3.0 goes full production and is not ALPHA or BETA software. Also will not happen until the FreeBSD ports maintainer for Snort updates the package here. Finally, there is a distinct possibility that Snort 3.0 will lose the ability to block offenders on pfSense. I have not investigated this in detail, but I do know that the Snort team is deprecating the output plugins API that the custom blocking module for pfSense depends on. If the API hooks the current blocking module depends on are not in Snort 3.0, then blocking won't work.

Bill

oh when that happens it will become kinda useless.

Multithreathed option in snort would be nice that it might run smoother/faster etc when you have more then 1 core in the box you use.