How to specify Command Line arguments in IPS policies for SCSP/DCS

Products

Critical System Protection Data Center Security Monitoring Edition Data Center Security Server Data Center Security Server Advanced

Issue/Introduction

When specifying command line arguments in IPS policies, the arguments must exactly match what is passed to the process. The arguments passed to processes can change from operating system to operating system, and can depend on how the process is launched.

Resolution

How to specify Command Line arguments in IPS policies

When specifying command line arguments in IPS policies, the arguments must exactly match what is passed to the process. The arguments passed to processes can change from operating system to operating system, and can depend on how the process is launched.

For example, double clicking on the SCSP Agent CollectInfo batch script (i.e., C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat) causes the following to be run on Windows 2003:

Process: C:\WINDOWS\system32\cmd.exe

Arguments: “cmd /c “C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat” “

To determine what command line arguments are passed to a process, apply a Prevention policy and ensure that the Process Assignment Command Line Arguments are being logged. Launch the process, and open the SCSP CSV file (i.e., C:\Program Files\Symantec\Critical System Protection\Agent\scsplog\SISIDSEvents.csv) to view the Process Assignment event.

When to use the escape character

You must use the escape character if you want to use the slash as a literal in a command line argument. In the above example, the policy would need to escape the /c argument as follows:

Arguments: “cmd //c “C:\ Program Files\Symantec\Critical System Protection \Agent\IPS\tools\getagentinfo.bat” “

On Windows the escape character is a forward slash, /.

On Unix, the escape character is a back slash, \.

When to use quotes

The driver’s current behavior is that it gets the arguments as a single string, and then it parses that string and attempts to determine the individual arguments. The driver will match pairs of quotes when it processes the command line, and discard the quotes.

Special case on Windows:

This works in *most* cases, but we have had problems attempting to route specific batch files on Windows.

Example: The following is an example of a command and arguments that we would like to match in our policy. The two double quotes before the batch file and the two double quotes separated by a space at the end are being added by the o.s. (explorer?) when you double click on a batch file.

Command: C:\WINDOWS\system32\cmd.exe

Arguments: cmd /c “”C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat” “

Special case code has been added for Windows in the driver to check if the command line argument begins with “cmd /c” then apply the following rules:

Treat 2 consecutive double quotes as one
Treat 2 double quotes with a space in between at the end of the argument list as one.

Wildcard handling in command line arguments

The driver’s behavior regarding wildcards in command line arguments is as follows:

A * surrounded by spaces will match 0 or more arguments
A * that is surrounded by other characters will match 0 or more characters
The single character wildcard ? is supported

Case Sensitivity

By default, on Windows and Unix the command line processing is case sensitive.

To change the case sensitivity of how SCSP processes command line arguments, use the &ci; and &cs; arguments. The &ci; argument can be used on the command line to mark the remainder of the command line as case insensitive, while the &cs; argument can be used to mark the remainder of the command line as case sensitive.