 |
------------------------------------------------------------------------------
0. SUMMARY
------------------------------------------------------------------------------
This MANUAL contains the command usage and details of the appropriate options
of the NSM Adminstration scripts.
If you have any questions or comments about the NSMnow scripts then please
direct them to the SecurixLive Team <dev@securixlive.com>.
------------------------------------------------------------------------------
1. OVERVIEW
------------------------------------------------------------------------------
All administration functions can be executed in either a command line mode or a
graphic mode (based on Dialog). The command line is the default with the
graphic mode enabled via th switch "-d" or "--dialog".
The options of the NSM Administration scripts are predominantly long options in
order to be informative and descriptive.
There are a number of common options amongst allscripts. They are defined as
follows:
-d, --dialog
Use the graphic mode (based on Dialog) of propmting instead of the
standard command line mode.
-y, --force-yes
Enable the default selection for all user prompted values. This should
be carefully invoked and only if you are sure you can accept the
default values.
-V, --version
Show version information.
-?, --help
Show usage information.
------------------------------------------------------------------------------
2. GENERAL FUNCTIONS
------------------------------------------------------------------------------
General management involves the starting, stopping, restarting, statusing and
backing up of particular server(s) and sensor(s). All functions are capable of
being invoked individually as described below or via the next level generic
wrappers nsm_sensor and nsm_server.
The usage of nsm is:
nsm [options]
Options:
--sensor
See nsm_sensor
--server
See nsm_senver
--all
Performs actions on both server and sensor, respectively.
------------------------------------------------------------------------------
3. SERVER FUNCTIONS
------------------------------------------------------------------------------
1. Server Management (nsm_server)
Server management involves the creation, deletion, edition, starting, stopping,
restarting, statusing and backing up of a particular server. All functions are
capable of being invoked individually as describred below or via the generic
nsm_server wrapper.
The usage of nsm_server is:
nsm_server [options]
Options:
--add
See nsm_server_add
--del
See nsm_server_del
--edit
See nsm_server_edit
--start
See nsm_server_ps-start
--stop
See nsm_server_ps-stop
--restart
See nsm_server_ps-restart
--status
See nsm_server_ps-status
--backup-config
See nsm_server_backup-config
--backup-data
See nsm_server_backup-data
1.1. Add/New (nsm_server_add)
Create a new, or add an existing, server configuration to the current host.
This command will generate the required server data directories and associated
configuration files.
The minimum information required to build a server is its name, with all other
information capable of defaulting to reasonable values.
The usage of nsm_server_add is:
nsm_server_add [options]
Options:
--server-name=<name>
Define the name of server as <name>. The server names on a single host
must be unique in order to prevent inadvertant corruption of a server's
configuration or data.
--server-sensor-port=<port>
Define the local port on this host that any local or external sensors
will connect to. This port must deconflict with other hosted services
on this host.
The default value is "7736"
--server-client-port=<port>
Define the local port on this host that any local or external clients
will connect to. This port must deconflict with other hosted services
on this host.
The default value is "7734"
--server-db-name=<name>
Define name of locally host database, that will store the sguil server
specific information, as <name>. This name must deconflict with any
existing databases already present.
The default value is "servername_db"
--server-db-user=<user>
Define the user of the locally hosted database, that will have acces to
sguil server specific information, as <user>. This user must deconflict
with any existing users already present.
The default value is "sguil"
--server-db-pass=<pass>
Define the password for the user of the locally hosted database, that
will have acces to sguil server specific information, as <pass>.
The default value is "password"
--server-client-user=<user>
Define the username of the initial authorised client as <user>. This is
required to ensure there is a valid user than can authenticate to the
server remotely.
The default value is "sguil"
--server-client-pass=<pass>
Define the password of initial authorised client as <pass>.
The default value is "password"
--server-auto=yes|no
Allow the server to be automatically assumed when server names are not
explicitly defined. This allows for implicit starting and stopping of
all "auto" enabled servers.
The default value is "no"
1.2. Remove/Delete (nsm_server_del)
Remove, or delete, an existing server configuration from the current
host. This command will remove the appropriate server data directories, which
contain any collected data, and associated configuration files.
The usage of nsm_server_del is:
nsm_server_del [options]
Options:
--server-name=<name>
Define the name of server you wish to delete.
1.3. Edit (nsm_server_edit)
Edit, or update, an existing server configuration on the current host. This
allows any parameter originally defined to be changed or modified.
If no parameters are defined then an interactive edit session will occur with
every server option being presented for modification. You can explicity define
which server options you want to modify directly on the command line using the
options described below.
The default values for any interactive options will be the current value. This
means that a "-y" or "--force-yes" directive will not modify any non-explicitly
defined values, allowing for single modifications to be made via the command
line. Some examples are given after the usage.
Note: Not all parameters initially defined when adding a server can be edited,
which is most applicable to the database credentials.
The usage of nsm_server_edit is:
nsm_server_edit [options]
Options:
--server-name=<name>
Define the name of server you wish to edit/update.
--new-server-name=<name>
Update the current name of server to <name>.
--server-sensor-port=<port>
Update the listening port that sensors will connect to.
--server-client-port=<port>
Update the listening port that clients will connect to.
--server-client-user=<user>
Update the username of the initial authorised client.
--server-client-pass=<pass>
Update the password of the initial authorised client.
--server-auto=yes|no
Allow the server to be automatically assumed when server names are not
1.4. Clear (nsm_server_clear)
Clear, or reset, an existing servers collected information. This command will
remove the appropriate server data files which contain any collected data.
The usage of nsm_server_clear is:
nsm_server_clear [options]
Options:
--server-name=<name>
Define the name of server you wish to clear.
2. Server User Management
Server User management involves the adding and deltion of new users to the
server. User access to the server allows for unique client credentials to be
used with the sguil client.
The Server User Management is not wrapped by any of the higher level wrappers
such as "nsm_server" nor "nsm".
2.1 Add (nsm_server_user-add)
This will add a new user and grant privilege to access to the server from a
client.
The usage of nsm_server_user-add is:
nsm_server_user-add [options]
Options:
--server-name=<name>
The server name for which the user is being added to.
--user-name=<name>
The name of the new user that will be connecting to the server.
--user-pass=<password>
The password of the new user that will be connecting to the server.
2.1 Delete (nsm_server_user-del)
This will delete a user and associated access from the server.
The usage of nsm_server_user-del is:
nsm_server_user-del [options]
Options:
--server-name=<name>
The server name for which the user will be deleted from.
--user-name=<name>
The name of the user that will be deleted from the server.
3. Server Sensor Management
Server Sensor management involves the adding and deltion of sensor awareness to
the server. Sensor awareness is that the server is aware of the sensors that is
connecting to it. The primary reason for this requirement is in the matching of
rules to alerts. It is possible to have different rule sets across different
sensors. These rules sets must be synchronised with the rule sets on the server
associated to each particular sensor.
The NSM administration scripts provides only simple tracking for the default
rule sets supplied with NSMnow. Any custom rule set synchronisation must be done
as a seperate manual task on both the sensor and server.
The Server Sensor Management is not wrapped by any of the higher level wrappers
such as "nsm_server" nor "nsm".
3.1 Add (nsm_server_sensor-add)
This will add sensor awareness to a server by configuring the default Snort rule
set.
The usage of nsm_server_sensor-add is:
nsm_server_sensor-add [options]
Options:
--server-name=<name>
The server name for which the sensor is being added to.
--sensor-name=<name>
The sensor name that will be connecting to the server, thus requiring
it's awareness.
3.1 Delete (nsm_server_sensor-del)
This will remove the appropriate sensor awareness of a server by removing the
default Snort rule set associated with the specified sensor name.
The usage of nsm_server_sensor-del is:
nsm_server_sensor-del [options]
Options:
--server-name=<name>
The server name for which the sensor is being removed from.
--sensor-name=<name>
The sensor name that will have it's awareness removed.
4. Backup
4.1. Server Data (nsm_server_backup-data)
Backup an existing server's collected data to a specified location. All
collected data is archived into a gzipped tarball at the user specified
location.
The collected data consists of all information in the resepective data
directory (typially /nsm/server_data) and the corresponding mysql database.
The usage of nsm_server_backup-data is:
nsm_server_backup-data [options]
Options:
--server-name=<name>
Define the name of server you wish to backup the collected data of.
--backup-file=<path>
Specify the full backup file path as <path>. The final directory should
exist otherwise the script will indicate it doesn't and exit.
4.2. Server Configuration (nsm_server_backup-config)
Backup an existing server's configuration to a specified location. All
configurations are archived into a gzipped tarball at the user specified
location.
The usage of nsm_server_backup-config is:
nsm_server_backup-config [options]
Options:
--server-name=<name>
Define the name of server you wish to backup the configuration of.
--backup-file=<path>
Specify the full backup file path as <path>. The final directory should
exist otherwise the script will indicate it doesn't and exit.
5. Process management
5.1. Start (nsm_server_ps-start)
Start a single server (due to the limitations of sguil server), on the current
host.
There is no minimum of information required. If no information is provided then
all auto assumed servers, as defined in the servertab file, will be actioned.
Alterantively a server name directive can be explicitly defined.
The usage of nsm_server_ps-start is:
Options:
--server-name=<name>
Explicitly define the server as <name> on which to action.
5.2. Stop (nsm_server_ps-stop)
Stop a single server (due to the limitations of sguil server), on the current
host.
There is no minimum of information required. If no information is provided then
all auto assumed servers, as defined in the servertab file, will be actioned.
Alterantively a server name directive can be explicitly defined.
The usage of nsm_server_ps-stop is:
Options:
--server-name=<name>
Explicitly define the server as <name> on which to action.
5.3. Restart (nsm_server_ps-restart)
Restart a single server (due to the limitations of sguil server), on the current host.
There is no minimum of information required. If no information is provided then
all auto assumed servers, as defined in the servertab file, will be actioned.
Alterantively a server name directive can be explicitly defined.
The usage of nsm_server_ps-restart is:
Options:
--server-name=<name>
Explicitly define the server as <name> on which to action.
5.4. Status (nsm_server_ps-status)
Get the status of a single server (due to the limitations of sguil server), on
the current host.
There is no minimum of information required. If no information is provided then
all auto assumed servers, as defined in the servertab file, will be actioned.
Alterantively a server name directive can be explicitly defined.
The usage of nsm_server_ps-status is:
Options:
--server-name=<name>
Explicitly define the server as <name> on which to action.
------------------------------------------------------------------------------
4. SENSOR FUNCTIONS
------------------------------------------------------------------------------
1. Sensor Management (nsm_sensor)
Sensor management involves the creation, deletion, edition, starting, stopping,
restarting, statusing and backing up of a particular sensor. All functions are
capable of being invoked individually as describred below or via the generic
nsm_sensor wrapper.
The usage of nsm_sensor is:
nsm_sensor [options]
Options:
--add
See nsm_sensor_add
--del
See nsm_sensor_del
--edit
See nsm_sensor_edit
--start
See nsm_sensor_ps-start
--stop
See nsm_sensor_ps-stop
--restart
See nsm_sensor_ps-restart
--status
See nsm_sensor_ps-status
--backup-config
See nsm_sensor_backup-config
--backup-data
See nsm_sensor_backup-data
1.1. Add/New (nsm_sensor_add)
Create a new, or add an existing, sensor configuration to the current host.
This command will generate the required sensor data directories and associated
configuration files.
The minimum information required to build a sensor is its name, with all other
information capable of defaulting to reasonable values.
The usage of nsm_sensor is:
nsm_sensor_add [options]
Options:
--sensor-name=<name>
Define the name of sensor as <name>. The sensor names on a single host
must be unique in order to prevent inadvertant corruption of a sensor's
configuration or data.
Ideally a sensor's name should be unique amongst the entire monitoring
network, primarily to aid troubleshooting but also easing identification
of collected data sources.
--sensor-interface=<iface>
Define the sensing interface of the sensor as <iface>. The interface
name can take two forms of syntax. The first form is the interface name
as seen in ifconfig (e.g. "eth0" or "ath0"). The second form is for the
bonding of two or more physical interfaces as a single virtual
interface. For the latter, bonding must be supported by the kernel.
Some examples of both types are shown below:
1. "eth0"
- this will monitor the local ethernet connection eth0
2. "bond0:eth0,eth1"
- this will monitor the virtual bonded network bond0, which is
the bonding of the local ethernet connections eth0 and eth1.
Bonded network interfaces must be defined from 0 upwards.
The default value is "eth0"
--sensor-interface-auto=yes|no
Allow the sensor interface to be automatically configured when starting
or restarting the sensor. This ensures that, as appropriate, interfaces
are bonded, configured to a non-routable IP of 0.0.0.0, are up, and are
in promiscuous mode.
The default value is "no"
--sensor-server-host=<ip>
Define the network IP of the server that this sensor will report to.
The server host is the correlation and fusion centre for all sensor
collected data.
The default value is "localhost"
--sensor-server-port=<port>
Define the network port of the server that this sensor will report to.
The default value is "7736"
--sensor-barnyard2-port=<port>
Define a local network port of this host that the sensor will use to
communicate with barnyard2 and the logged Snort alerts.
The default value is "7735"
--sensor-auto=yes|no
Allow the sensor to be automatically assumed when sensor names are not
explicitly defined. This allows for implicit starting and stopping of
all "auto" enabled sensors.
The default value is "no"
--sensor-net-group=<id>
Defines a net group identifier as <id> for which the sensor is part of.
This allows a number of sensors to be grouped as one sensor group, which
is useful for multiple egress/ingress points to one asset being
monitored.
--sensor-utc=yes|no
Determines if the sensor is to log in UTC (aka GMT) mode or local time
mode. If sensors are for some reason spread across different time zones
then it is more convenient to log in UTC and avoid any potential issues
caused by timeshifts.
The default value is "yes"
--sensor-vlan-tagging=yes|no
Determines if the sensor should be aware of VLAN tagged packets. If you
are monitoring a VLAN, GRE or similar encapsulated protocol then this
should be enabled.
The default value is "no"
1.2. Remove/Delete (nsm_sensor_del)
Remove, or delete, an existing sensor configuration from the current
host. This command will remove the appropriate sensor data directories, which
contain any collected data, and associated configuration files.
The usage of nsm_sensor_del is:
nsm_sensor_del [options]
Options:
--sensor-name=<name>
Define the name of sensor you wish to delete.
1.3. Edit sensor details (nsm_sensor_edit)
Edit, or update, an existing sensor configuration on the current host. This
allows any parameter originally defined to be changed or modified.
If no parameters are defined then an interactive edit session will occur with
every sensor option being presented for modification. You can explicity define
which sensor options you want to modify directly on the command line using the
options described below.
The default values for any interactive options will be the current value. This
means that a "-y" or "--force-yes" directive will not modify any non-explicitly
defined values, allowing for single modifications to be made via the command
line.
The usage of nsm_sensor_edit is:
nsm_sensor_edit [options]
Options:
--sensor-name=<name>
Define the name of sensor you wish to edit/update.
--new-sensor-name=<name>
Update the current name of sensor to <name>.
--new-sensor-interface=<iface>
Update the current sensing interface to <iface>.
--new-sensor-interface-auto=yes|no
Update if the sensor interface can be autoconfigured.
--new-sensor-server-host=<ip>
Update the current IP of the server host to <ip>.
--new-sensor-server-port=<port>
Update the current port of the server host to <port>.
--new-sensor-barnyard2-port=<port>
Update the current local listening port for barnyard2 to <port>.
--new-sensor-auto=yes|no
Update if sensor can be auto assumed.
--new-sensor-net-group=<id>
Update the current net group identifier to <id>.
--new-sensor-utc=yes|no
Update if sensor logs in UTC mode.
--new-sensor-vlan-tagging=yes|no
Update if sensor uses VLAN tagging.
1.4. Clear (nsm_sensor_clear)
Clear, or reset, an existing sensors collected information. This command will
remove the appropriate sensor data files which contain any collected data.
The usage of nsm_sensor_clear is:
nsm_sensor_clear [options]
Options:
--sensor-name=<name>
Define the name of sensor you wish to clear.
2. Backup
2.1. Sensor Data (nsm_sensor_backup-data)
Backup an existing sensor's collected data to a specified location. All
collected data is archived into a gzipped tarball at the user specified
location.
The usage of nsm_sensor_backup-data is:
nsm_sensor_backup-data [options]
Options:
--sensor-name=<name>
Define the name of sensor you wish to backup the collected data of.
--backup-file=<path>
Specify the full backup file path as <path>. The final directory should
exist otherwise the script will indicate it doesn't and exit.
2.2. Sensor Configuration (nsm_sensor_backup-config)
Backup an existing sensor's configuration to a specified location. All
configurations are archived into a gzipped tarball at the user specified
location.
The usage of nsm_sensor_backup-config is:
nsm_sensor_backup-config [options]
Options:
--sensor-name=<name>
Define the name of sensor you wish to backup the configuration of.
--backup-file=<path>
Specify the full backup file path as <path>. The final directory should
exist otherwise the script will indicate it doesn't and exit.
3. Process management
3.1. Start (nsm_sensor_ps-start)
Start a single sensor, or mulitple sensors, on the current host.
There is no minimum of information required. If no information is provided then
all auto assumed sensors, as defined in the sensortab file, will be actioned.
Alterantively a sensor name, or multiple sensor name directives can be
explicitly defined.
The usage of nsm_sensor_ps-start is:
Options:
--sensor-name=<name>
Explicitly define the sensor as <name> on which to action. Mulitple
directives can be used.
--only-barnyard2
Only start the barnyard2 sub-process.
--only-sancp
Only start the sancp sub-process
--only-snort-alert
Only start the snort (alert data) sub-process
--only-snort-logging
Only start the snort (full packet data) sub-process
--only-pcap_agent
Only start the pcap_agent sub-process
--only-sancp_agent
Only start the sancp_agent sub-process
--only-snort_agent
Only start the snort_agent sub-process
--skip-barnyard2
Skip the starting of the barnyard2 sub-process.
--skip-sancp
Skip the starting of the sancp sub-process
--skip-snort-alert
Skip the starting of the snort (alert data) sub-process
--skip-snort-logging
Skip the starting of the snort (full packet data) sub-process
--skip-pcap_agent
Skip the starting of the pcap_agent sub-process
--skip-sancp_agent
Skip the starting of the sancp_agent sub-process
--skip-snort_agent
Skip the starting of the snort_agent sub-process
3.2. Stop (nsm_sensor_ps-stop)
Stop a single sensor, or mulitple sensors, on the current host.
There is no minimum of information required. If no information is provided then
all auto assumed sensors, as defined in the sensortab file, will be actioned.
Alterantively a sensor name, or multiple sensor name directives can be
explicitly defined.
The usage of nsm_sensor_ps-stop is:
Options:
--sensor-name=<name>
Explicitly define the sensor as <name> on which to action. Mulitple
directives can be used.
--only-barnyard2
Only stop the barnyard2 sub-process.
--only-sancp
Only stop the sancp sub-process
--only-snort-alert
Only stop the snort (alert data) sub-process
--only-snort-logging
Only stop the snort (full packet data) sub-process
--only-pcap_agent
Only stop the pcap_agent sub-process
--only-sancp_agent
Only stop the sancp_agent sub-process
--only-snort_agent
Only stop the snort_agent sub-process
--skip-barnyard2
Skip the stopping of the barnyard2 sub-process.
--skip-sancp
Skip the stopping of the sancp sub-process
--skip-snort-alert
Skip the stopping of the snort (alert data) sub-process
--skip-snort-logging
Skip the stopping of the snort (full packet data) sub-process
--skip-pcap_agent
Skip the stopping of the pcap_agent sub-process
--skip-sancp_agent
Skip the stopping of the sancp_agent sub-process
--skip-snort_agent
Skip the stopping of the snort_agent sub-process
3.3. Restart (nsm_sensor_ps-restart)
Restart a single sensor, or mulitple sensors, on the current host.
There is no minimum of information required. If no information is provided then
all auto assumed sensors, as defined in the sensortab file, will be actioned.
Alterantively a sensor name, or multiple sensor name directives can be
explicitly defined.
The usage of nsm_sensor_ps-restart is:
Options:
--sensor-name=<name>
Explicitly define the sensor as <name> on which to action. Mulitple
directives can be used.
--only-barnyard2
Only restart the barnyard2 sub-process.
--only-sancp
Only restart the sancp sub-process
--only-snort-alert
Only restart the snort (alert data) sub-process
--only-snort-logging
Only restart the snort (full packet data) sub-process
--only-pcap_agent
Only restart the pcap_agent sub-process
--only-sancp_agent
Only restart the sancp_agent sub-process
--only-snort_agent
Only restart the snort_agent sub-process
--skip-barnyard2
Skip the restarting of the barnyard2 sub-process.
--skip-sancp
Skip the restarting of the sancp sub-process
--skip-snort-alert
Skip the restarting of the snort (alert data) sub-process
--skip-snort-logging
Skip the restarting of the snort (full packet data) sub-process
--skip-pcap_agent
Skip the restarting of the pcap_agent sub-process
--skip-sancp_agent
Skip the restarting of the sancp_agent sub-process
--skip-snort_agent
Skip the restarting of the snort_agent sub-process
3.4. Status (nsm_sensor_ps-status)
Get the status of a single sensor, or mulitple sensors, on the current host.
There is no minimum of information required. If no information is provided then
all auto assumed sensors, as defined in the sensortab file, will be actioned.
Alterantively a sensor name, or multiple sensor name directives can be
explicitly defined.
The usage of nsm_sensor_ps-status is:
Options:
--sensor-name=<name>
Explicitly define the sensor as <name> on which to action. Mulitple
directives can be used.
--only-barnyard2
Only status the barnyard2 sub-process.
--only-sancp
Only status the sancp sub-process
--only-snort-alert
Only status the snort (alert data) sub-process
--only-snort-logging
Only status the snort (full packet data) sub-process
--only-pcap_agent
Only status the pcap_agent sub-process
--only-sancp_agent
Only status the sancp_agent sub-process
--only-snort_agent
Only status the snort_agent sub-process
--skip-barnyard2
Skip the status of the barnyard2 sub-process.
--skip-sancp
Skip the status of the sancp sub-process
--skip-snort-alert
Skip the status of the snort (alert data) sub-process
--skip-snort-logging
Skip the status of the snort (full packet data) sub-process
--skip-pcap_agent
Skip the status of the pcap_agent sub-process
--skip-sancp_agent
Skip the status of the sancp_agent sub-process
--skip-snort_agent
Skip the status of the snort_agent sub-process
------------------------------------------------------------------------------
5. CLIENT FUNCTIONS
------------------------------------------------------------------------------
There are no adminstration specific requires for clients at this time.
------------------------------------------------------------------------------
6. EXAMPLES
------------------------------------------------------------------------------
The following examples are a broad overview of the capabilities that are
provided by the NSM Administration scripts. They are here to show the level of
flexibility offered by the new adminstrative framework.
NOTE: All examples are performed as the root user.
There is often a number of ways to perform a single task. Every task is broken
down into a specific script that does that one task. The wrapper functions
will simply call these specific tasks and thus providing multiple ways to do
the same thing. For example starting the sensor defined as "thor" can be
achieved in one of three ways:
# nsm_sensor_ps-start --sensor-name=thor
# nsm_sensor --start --sensor-name=thor
# nsm --sensor --start --sensor-name=thor
You can see the wrapper scripts building off of the last. In these examples the
name has been explicitly defined. If no name is defined then the scripts will
act on those that have "auto assumption" enabled. Auto assumption can be
examined in either the sensortab or servertab files under /etc/nsm with the
value "1" in the "auto" column signifying that it is enabled. If the sensor
"thor" has auto assumption enabled the above commands can all be simplified as:
# nsm_sensor_ps-start
# nsm_sensor --start
# nsm --sensor --start
This works for both sensors and servers alike. Where a machine is configured as
both a sensor and server additional short cuts can be made using the "--all"
directive. This is available in the "nsm" wrapper only and allows one to
peform the desired tasks (limited to start, stop, restart and status) on the
server and then the sensor. For example to start an NSM sensor/server requires:
# nsm --all --start
Of course all this starting and stopping is of no use if you don't have any
sensors or servers to perform them on. So continuing from where where we left
off, to add a new sensor defined as "thor" with the all default options enabled
we could perform any of the following:
# nsm_sensor_add -y --sensor-name=thor
# nsm_sensor --add -y --sensor-name=thor
# nsm --sensor --add -y --sensor-name=thor
In the event that any of the defaults are not to your liking then you can
perform an interactive edit, on the command line, with either of the following:
# nsm_sensor_edit
# nsm_sensor --edit
# nsm --sensor --edit
An interactive edit, using menu dialogs (via "dialog"), would be achieved by
adding the "-d" or "--dialog" directive, such as:
# nsm_sensor_edit -d
To perform a simple rename of an existing sensor from "thor" to "aegis" then
the following command will suffice:
# nsm_sensor_edit -y --sensor-name=thor --new-sensor-name=aegis
To delete the newly renamed sensor can be done via:
# nsm_sensor_del --sensor-name=aegis
|
