Purpose of this Document
To provide guidance on the best practices and considerations for customers writing their own
automated remediation scripts.
Contents
Purpose of this Document ....................................................................................................................... 1
About Automated Remediation ............................................................................................................... 1
Creating an AR Script ............................................................................................................................... 2
Scripting Language Guidelines ............................................................................................................. 5
Scripting Safety, Accuracy, and Efficiency............................................................................................. 6
Automated Remediation Example Scripts ................................................................................................ 7
Future Proofing ....................................................................................................................................... 8
About Automated Remediation
Remediation is the process of resolving failures generated by a policy test. With automated
remediation, when a policy test fails on a file server node, the Tripwire Administrator may run a
customized script via the TE Agent on that node to bring it into compliance with the policy test.
The specific actions performed to remediate each policy test are listed in the test’s Remediator
tab.
1
Creating an AR Script
Automated Remediation is configured from the following screen of the Policy Test Wizard or
under the Remediator tab of a policy test. All scripts are executed with the privileges of the TE
agent on the node being remediated. For Windows, this is typically the 'SYSTEM' account; for
Linux/Unix systems, this is typically 'root'. If it's necessary to use a non-standard account,
either the agent should be configured to run under the desired account, or the remediation
script itself should include the desired 'run-as' logic.
Fields
Command Line Field
This field is the command to be executed on the agent node. Usually this contains the
command to launch the script in the Script Field. When Tripwire Enterprise executes
remediation on an Agent, the content in the Script field is written to a temporary file on
the Agent, and can be referenced by the $(ScriptFile) variable in the Command Line
2
field. The temporary file is written to the directory $TW_HOME\tmp\tmpfilemgr, where
$TW_HOME is the installation directory of the TE agent.
Some commands require specific extensions for files passed to it. If the variable has a
file extension in the Command Line - for example $([Link]) - the temporary
script file will also have that extension. If no file extension is used, TE assigns an
extension to the temporary file based on the command being executed:
regedit = .reg
regini = .ini
[Link] or cmd = .cmd
[Link] = .bat
Examples of common Command Lines are:
Windows
C:\windows\system32\cscript $(ScriptFile)
C:\ windows\regedit /s $([Link])
Linux/Unix
/bin/sh -c $(ScriptFile)
/usr/bin/perl $([Link]}
Script Field
This field is used for the contents of the script to be executed or the file input to the
executable on the command line. The contents of the Script field are written to the
temporary file referenced by $(ScriptFile) in the Command Line field.
There is very little direct communication between TE and an automated remediation
script. Any output written by the script to standard output or standard error is recorded
in the TE agent log located at $TW_HOME/data/log/[Link]. This output log is
useful for debugging problems with the remediation script. As a best practice, it is
useful to standardize the output of a script for easy analysis and parsing. More help
with debugging and finding the remediation log messages is available on your TE server
at:
[Link]
[Link]
Errors are communicated back to the TE Agent through the use of exit codes. An exit
code of ‘0’ indicates that the script completed successfully. Any other value indicates
that the script encountered an error and was unable to complete remediation. In a
Windows cscript, the exit code is returned using the command:
[Link](ExitCode#)
3
In a Linux/Unix Bourne shell script, an exit code is returned using the command:
exit ExitCode#
Post Remediation Category Field
Tripwire best practices suggest ensuring that automated remediation scripts do not
affect production services and servers; therefore post-remediation categories are
included to allow for potentially production affecting changes to be implemented
according to organizational policies (e.g. during maintenance windows). The post-
remediation categories are listed below and include associated commands to perform
the post-remediation step for the appropriate platform. For a more complete
discussion of post-remediation commands, including how to modify, export, and delete
the built in post-remediation commands, please review the online help included in your
TE Server at
[Link]
are_Post_Remediation_Actions.html
None: No manual post-remediation steps are required.
Stop Service: A service must be stopped before remediation can take effect. To
use a post-remediation service command to stop the service, a single service
must be listed here.
Start Service: A service must be started before remediation can take effect. To
use a post-remediation service command to start the service, a single service
must be listed here.
Restart Service: A service must be restarted before remediation can take effect.
To use a post-remediation service command to restart the service, a single
service must be listed here.
Reboot Machine: The machine that was remediated must be rebooted before
remediation can take effect. Tripwire will not perform this post-remediation
step; the system administrator must reboot the machine manually.
Reload Configuration: A service's configuration must be reloaded before
remediation can take effect. To use a post-remediation service command to
reload the configuration, a single service must be listed here.
Other: Some other kind of action must be performed before remediation can
take effect.
4
Post Remediation Steps
This field is for documenting the necessary post-remediation steps. HTML formatting is
supported in this field. The field is useful for documenting the manual steps used to
perform the equivalent functionality of the post-remediation script, or in cases when
post-remediation scripts can’t be used, the manual steps that need to be taken to finish
remediation.
Remediated Elements (optional)
Automated Remediation will automatically promote the changes made to the element
that the remediation script is associated with. Remediation scripts may affect
monitored elements other than the element being remediated. For example, disabling
a Windows service may modify other registry entries as the service is stopped. Changes
made to elements listed in this field will also be promoted when the scripts are run.
This field supports the use of the ? and * wildcard characters to add groups of elements
to be promoted.
Scripting Language Guidelines
While TE supports the use multiple scripting environments, only one scripting environment
should be relied upon in a given platform family. Although any scripting language or
executable that can be started from a command line may be used, Tripwire suggests the
following scripting languages as they are the most commonly available on the platforms:
Linux/Unix
Bourne Shell should be used as frequently as possible across Linux/Unix platforms. It is
considered the standard cross-platform POSIX compatible shell and scripts can be made to
work across platform variants.
For appropriate script formatting, Tripwire suggests the guidance given on the OpenSolaris
site: [Link]
Windows
Windows environments are somewhat more complicated. Tripwire suggests that Windows
Script Host be used, which can be consistent across Windows platforms on Windows 2000
and later. It is further suggested that, to take advantage of additional programmatic
constructs, but to continue to have access to critical Windows components (such as the
Registry), JScript or VBScript be used. Either will provide a richer and likely more widely-
known set of programmatic constructs while still allowing access to the wscript object and
other elements of the Windows environment. In other words, it is recommended to not
5
rely on the batch file (.bat) scripting of commands in the Windows environment due to a
general inconsistency of error information.
Other Windows Considerations
Windows AR uses the executable file name to issue automated remediation commands, so
either the full path to the executable should be used or the path environment variable
must include %SystemRoot%\system32. To check the path variable, perform the following
steps:
1. Go to the Start menu and select Control Panel.
2. From the control panel double click on the System icon. When the system dialog comes
up select the Advanced tab.
3. From here you can edit environment variables by clicking on the Environment Variables
button. Select PATH in the Variable name then hit Edit, and make sure it includes
%SystemRoot%\system32.
Scripting Safety, Accuracy, and Efficiency
Tripwire-published scripts are designed to be safe, accurate, and efficient - in that order.
Tripwire Enterprise often runs in production environments and an unsafe action performed by
one of our published scripts could translate into real damage for a client. In general, scripts
should never:
Adversely affect any process
Adversely affect present node operation
Be destructive
Being Nice to Processes
It is important to not adversely affect the behavior of any running process on a given
system. One of the more obvious examples is running services. There are several ways to
affect the running state of a service, the most obvious of which is to stop a running service
or start one that is stopped. This should never be done by a Tripwire-published script.
Remediation for some tests involves removing files, and if these files are critical pieces to a
running service, then they should not be removed. Put another way, if any automatic
remediation action we would like to perform would adversely affect the running state of a
service, then we should not perform that action automatically - it should be left as a
manual action or implemented as a post-remediation script.
6
There are other examples, e.g. network stack parameter manipulation might immediately
affect the behavior of the network stack.
Undisturbed Node Operation
In a similar manner, certain remediation actions will not be fully complete until the node is
restarted (i.e. reboot the server). In a production environment, restarting the server
outside of a scheduled maintenance window would likely result in adverse consequences,
and therefore node restarting should not be included in any automatic remediation.
Destruct Not
Some remediation recommendations are destructive by definition. One example of this is
that many Linux/Unix tests require file removal. It seems prudent to not remove files
without somehow making a backup copy of them elsewhere on the system. There are
several ways to accomplish this. We might rename a file with a ".tecopy" extension (or
something similar), we might move the file to a TE-specific directory, we might simply
comment the entire file so it has no effect on the system, or we can write the content of
the file to the agent log and then delete the file.
Automated Remediation Example Scripts
Below are examples of a Linux/Unix script to add a file to a directory and a Windows Script to
change a registry value.
Linux/Unix Script to add a file to a directory
#!/bin/sh
#script should be launched with the command line: /bin/sh –c $(ScriptFile)
# Initialize Variables
FileName= ”/tmp/testfile”
# Issue the command to create the file required
if [ ! -e $FileName ]; then
TouchLog=`/bin/touch $FileName 2>&1`
if [ -n "$TouchLog" ]; then
/bin/echo "FAILURE-1003: Could not create [$FileName] file/directory"
exit 1003
else
/bin/echo "SUCCESS-1003: [$FileName] file/directory created"
exit 0
fi
else
/bin/echo "SUCCESS-1001: [$FileName] file/directory exists"
exit 0
fi
7
Windows Script to modify a registry key
‘Script should be launched with the command line : c:\windows\system32\cscript $(ScriptName)
RegistryKey = “HKEY_LOCAL_MACHINE\Test”
Value = "0"
ValueType = "REG_DWORD"
' Create shell object to manage registry
Set WSHShell = [Link]("[Link]")
[Link] RegistryKey, Value, ValueType
If ([Link] = 0) Then
[Link] "SUCCESS-2006: [" & RegistryKey & "] registry key changed to [" & Value & "]"
[Link](0)
Else
[Link] "FAILURE-2006: Could not set value of [" & RegistryKey & "] to [" & Value & "]"
[Link](2006)
End If
Future Proofing
Tripwire Enterprise 8.1 will provide the variable $(ElementName) which will give users the
ability to pass the name of the failing element to the script on the command line. This feature
enables scripts to be re-used by taking the element passed to the script.
Examples of this command line usage are:
Windows
C:\windows\system32\cscript $(ScriptFile) $(ElementName)
Linux/Unix
/bin/sh -c ‘$(ScriptFile) $(ElementName)’
The example scripts above can be easily modified to take advantage of this feature by replacing
the lines:
Script 1:
FileName=”/tmp/testfile”
With
FileName= $1
Script 2:
8
RegistryKey = “HKEY_LOCAL_MACHINE\Test”
With
RegistryKey = [Link](0)
