Requesting input on adding new features to Snort pkg from experienced users
-
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.
-
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% snortLoad 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 Freewcpu 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) -
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 anyExample: 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 dropboxBill 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.
-
-
2,3,1 + inline / drop :-)
-
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
-
-
Will you also be upgrading it to snort 3.0?
-
@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
-
@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.
