1 reply

In a situation where a user makes an intended change to a device (incorrectly) or just in general makes a bad configuration change this can have unintended consequences. For example providing a invalid IP to an object it can not bind to (listen for connections) it will be in a 'down' state.

The main option when someone makes a change that is unintended is to:

Make sure 'write mem' or 'save configuration' did not take place after that change

Restart the domain (assuming a non-default domain). If changes made to a default domain object, restart the device, eg. co; flash; shutdown reload

If someone had already committed the change to the filesystem via 'write mem' or 'save configuration' - then you would have to manually revert it, backup from a previous configuration or a checkpoint.

Automation Story

If you want to enforce a certain configuration that will not be changed, then the best enforcement would be via a log target that contains a log trigger. The log trigger allows you to capture specific messages in DataPower through their message id (0x1234abcd hexadecimal address tied to the log message). Then you can use a regular expression to match part or all of the log message.

In this example the following takes place:

We have a log target setup as a file, will capture event subscriptions of 'cli' at the 'debug' level.

Inside the log trigger a regular expression (without quotes): ".*secure-shell:[0-9.]+): ssh" will filter the messages that do not apply, in this case we only want to monitor secure-shell sessions modifying the 'ssh' object.

When we match changing the 'ssh' object being changed over the 'secure-shell' interface, the log trigger will activate and reset SSH to listen on all interfaces (not that having SSH listening on all interfaces is recommended, just an example): "ssh 0.0.0.0 22"

Please note this example does not include modifying other interfaces, secure-shell would for example be saml-artifact for xml-mgmt based changes, or webgui for changes made via the WebGUI in DataPower.

BE SURE TO SPECIFY AN INTERFACE OPTION, eg secure-shell, saml-artifact, webgui or a combination, making a wildcard match, if you match to 'system' you could put the device in a loop of constantly changing the object

Example Logging Target with configuration cli trigger against a secure-shell session attempting to change SSH object, this would be located in the DEFAULT domain