Snort users – how would you like "templates" to work in the Snort package?
-
Hi Bill,
Would this template be specific to a single pfSense box or can the template be copied to another Machine?
In the Snort/Suricata Interface page, you could have an icon to duplicate an existing interface except for the interface name and interface device.
In the Interface section, would keep the Whitelist and Suppress list, or default them.
Apart from that looks good.
-
@BBcan17:
Hi Bill,
Would this template be specific to a single pfSense box or can the template be copied to another Machine?
I had not considered making it a file that could be copied from machine to machine. I think this possible without too much effort. I could store the template files in a subdirectory under /var/db like this: /var/db/snort/templates. This is where the new IP Reputation Lists are going to be stored in the next Snort release (in /var/db/snort/iprep).
If the templates are separate files, then the user will be responsible for saving or backing them up using a process separate from the main firewall configuration. That's the way it is going to be with the IP Reputation lists.
Bill
-
If the templates are separate files, then the user will be responsible for saving or backing them up using a process separate from the main firewall configuration. That's the way it is going to be with the IP Reputation lists.
Have you looked at the Filer package. You can create a template file in Snort and from Filer, you can add the path to that file which will show the contents of the file. This will also allow the file to be saved in the backup process. As I have been told by Marcello C.
-
@BBcan17:
If the templates are separate files, then the user will be responsible for saving or backing them up using a process separate from the main firewall configuration. That's the way it is going to be with the IP Reputation lists.
Have you looked at the Filer package. You can create a template file in Snort and from Filer, you can add the path to that file which will show the contents of the file. This will also allow the file to be saved in the backup process. As I have been told by Marcello C.
No, I have not looked into the Filer package. I recall seeing it mentioned in the thread discussion you had with Marcello a while back. I will experiment with it.
Today I'm trying to piece together a quick-fix for the large alert and http files generated by Suricata. The ultimate solution is to patch the Suricata binary to include the same auto-rotation support for those files that it offers for the Barnyard2 unified2 files. That solution will take some time to implement. Have any ideas on a quick-and-dirty short term fix for the large Suricata log files?
Bill
-
Suricata is really noisy on the Stream alerts. I would suggest disabling it (stream-events.rules) as a quick and dirty approach. I have heard people say they are receiving thousands of alerts an hour on busy networks.
In Security Onion, i have SGUIL set to autocategorize all of the Stream Events. If I need to go back and look at a particular event, I can pull the stream data at that time.
-
Ideally I would like to set up an interface the way I want it to work, let's say WAN1, with all the rules I want disabled, and a few hundred custom rules added, then type in a box labeled "Save as template:" Public_facing, then hit save.
When configuring a new wan interface, I should be able to start setting up a new interface under snort, with a dropdown box having "Public_facing" as an option to use it as a starting template, then type the name of the interface and be done with it. All rules/preprocessors/other config should be based on the template, which is based on WAN1 interface.
The two templates should be separated from one another, so that disabling a rule on one of them, does not make it into the template, then onto the next interface, if that makes sense.
There is the possibility that disabling a rule MUST be replicated to the template, and then onto the interfaces. Maybe an "Update template" button should be implemented, which should disable the rule, then reconfigure the interfaces based on that template with the updated template. It's a conflicting scenario, in the case that you need to disable a rule for a specific interface (should stay on one interface), then disable a noisy/broken rule (which should be replicated to other interfaces) then hit Update template. Going in and manually disabling the interface specific rule shouldn't be that much work.This would be extremely handy if you have multiple client facing interfaces, you set up one, then just save it as a template, and off you go setting up dozens of interfaces.
It doesn't make a lot of sense to use this in an IDS scenario (snort) but for the upcoming Suricata package it would pretty sweet.
My suggestions, feel free to add to/discard them as needed.
-
@jflsakfja:
Ideally I would like to set up an interface the way I want it to work, let's say WAN1, with all the rules I want disabled, and a few hundred custom rules added, then type in a box labeled "Save as template:" Public_facing, then hit save.
When configuring a new wan interface, I should be able to start setting up a new interface under snort, with a dropdown box having "Public_facing" as an option to use it as a starting template, then type the name of the interface and be done with it. All rules/preprocessors/other config should be based on the template, which is based on WAN1 interface.
The two templates should be separated from one another, so that disabling a rule on one of them, does not make it into the template, then onto the next interface, if that makes sense.
There is the possibility that disabling a rule MUST be replicated to the template, and then onto the interfaces. Maybe an "Update template" button should be implemented, which should disable the rule, then reconfigure the interfaces based on that template with the updated template. It's a conflicting scenario, in the case that you need to disable a rule for a specific interface (should stay on one interface), then disable a noisy/broken rule (which should be replicated to other interfaces) then hit Update template. Going in and manually disabling the interface specific rule shouldn't be that much work.This would be extremely handy if you have multiple client facing interfaces, you set up one, then just save it as a template, and off you go setting up dozens of interfaces.
It doesn't make a lot of sense to use this in an IDS scenario (snort) but for the upcoming Suricata package it would pretty sweet.
My suggestions, feel free to add to/discard them as needed.
I think I can make it work like this. I did always intend for a given interface, even if initially created from a template, to be stand-alone once you hit "save". That is, future changes to it would affect only it and not the template it was based on. I could maybe incorporate some kind of update template function, but then it might get hairy and overly complicated to try and then push that update to any interfaces created in the past from that template. That might be in conflict with the original goal of keeping it somewhat simple. Let me chew on that for a while and experiment when I start developing the template code.
Bill
-
After some offline consultation with members of the pfSense Core Team, the idea behind a "Template Feature" in the Snort package is going to change a bit. Instead of multiple named templates and an interface to manage them, it was suggested to simply add a ( + ) icon beside the existing ( e ) edit icon for each Snort configured interface. Clicking the + icon would let you duplicate the Snort setup from an existing interface over to a new interface. This is the way other "duplicate" options work elsewhere in pfSense (like the firewall rules tab, for example).
If you wanted to do this across firewalls, then you would use the existing config backup/restore functionality in pfSense.
Bill
-
Couldnt this be in a file that can be copied to the new box? This way it would work across updates and new releases as well.
-
Couldnt this be in a file that can be copied to the new box? This way it would work across updates and new releases as well.
There are lots of possibilities, but for now the Core Team would rather limit this to duplicating interface settings on the same box as I described just up above. I think they may be looking at something on a grander scale for a later pfSense release, and introducing something into a single package now would be a potential compatibility problem. That is just pure conjecture on my part, though. At any rate, when I posited the original template scheme to them it was not approved. So I will at least provide a way to duplicate existing Snort settings to another interface on the same firewall.
Another option for "mirroring settings" to multiple boxes is to use the Snort Sync feature Marcelloc helped me implement last year. That syncs the entire Snort configuration section of the config.xml file.
Bill
-
If you use a file then it could be replicated across locations and you will always have a config file with you.
Why not opt for both? Do as the core team wants and put an extra option in the GUI for creating a snort conf file.
