Reloading a Snort configuration
Snort now supports reloading a configuration in lieu of restarting Snort in so as to provide seamless traffic inspection during a configuration chang"/>
Snort now supports reloading a configuration in lieu of restarting Snort in so as to provide seamless traffic inspection during a configuration change. A separate thread will parse and create a swappable configuration object while the main Snort packet processing thread continues inspecting traffic under the current configuration. When a swappable configuration object is ready for use, the main Snort packet processing thread will swap in the new configuration to use and will continue processing under the new configuration. Note that for some preprocessors, existing session data will continue to use the configuration under which they were created in order to continue with proper state for that session. All newly created sessions will, however, use the new configuration.
To enable support for reloading a configuration, add “–enable-reload” to configure when compiling.
There is also an ancillary option that determines how Snort should behave if any non-reloadable options are changed (see “Non-reloadable configuration options” below). This option is enabled by default and the behavior is for Snort to restart if any non-reloadable options are added/modified/removed. To disable this behavior and have Snort exit instead of restart, add “–disable-reload-error-restart” in addition to “–enable-reload” to configure when compiling.
NOTE: This functionality is not currently supported in Windows.
First modify your snort.conf (the file passed to the ‘-c’ option on the command line).
Then, to initiate a reload, send Snort a SIGHUP signal, e.g.
$ kill -SIGHUP
NOTE: If reload support is not enabled, Snort will restart (as it always has) upon receipt of a SIGHUP.
NOTE: An invalid configuration will still result in a fatal error, so you should test your new configuration before issuing a reload, e.g.
$ snort -c snort.conf -T
There are a number of option changes that are currently non-reloadable because they require changes to output, startup memory allocations, etc. Modifying any of these options will cause Snort to restart (as a SIGHUP previously did) or exit (if “–disable-reload-error-restart” was used to configure Snort).
Reloadable configuration options of note: * Adding/modifying/removing text rules and variables are reloadable. * Adding/modifying/removing preprocessor configurations are reloadable (except as noted below).
Non-reloadable configuration options of note: * Adding/modifying/removing shared objects via dynamicdetection, dynamicengine and dynamicpreprocessor are not reloadable, i.e. any new/modified/removed shared objects will require a restart. * Any changes to output will require a restart.
Changes to the following options are not reloadable:
attribute_table config alertfile config asn1 config chroot config daemon config detection_filter config flowbits_size config interface config logdir config max_attribute_hosts config max_attribute_services_per_host config nolog config no_promisc config pkt_count config rate_filter config response config set_gid config set_uid config snaplen config threshold dynamicdetection dynamicengine dynamicpreprocessor output
In certain cases, only some of the parameters to a config option or preprocessor configuration are not reloadable. Those parameters are listed below the relevant config option or preprocessor.
config ppm: max_rule_time
When Snort is run on the primary network interface of an OpenBSD system, the reload and failopen operations may not function as expected.