Auditing Signal Sciences Configuration

Signal Sciences offers tremendous capabilities to defend web applications. I’m not talking just about how it defends against the usual suspects like OWASP injection attacks. I’m talking about how Signal Sciences Power Rules gives you the flexibility to easily define rules on the fly, so you can react to threats in real time. Given how much our customers have taken advantage of Power Rules, —over 20% of our customer traffic includes Signals created to surface unique application use and abuse— the need for this capability is real. As customers expand their usage and implement other custom configurations across numerous applications (for the purpose of this post, I’ll refer to applications as “sites”), it will be important to periodically audit configurations to ensure consistency.

 

Certainly, there will be bespoke Power Rules and configuration for specific sites, but there will also be common Power Rules and configuration applied to all sites. To help audit and compare configurations from site to site, we can leverage both the Signal Sciences API and the pysigscia Python script. 

[n.b. The article uses Python because I am a habitual Python developer, however, Signal Sciences recently released an official API library written in Go. If that is more your speed, be sure to check it out.]

The pysigscia script is part of the pysigscia Python package. The “a” in pysigscia stands for audit. The command will compare the configuration between two sites and generate a report. In the report, there will be a section for each type of configuration. If there is any differential between configurations, the report will show the details.

Get Started

To get started, you need the pysigsci Python package, which can be installed using the command:

$ pip install pysigsci

It’s worth noting this package provides several tools:

• A module that is a Signal Sciences API wrapper. You can import this module into your Python scripts to work with the API.
• The pysigsci CLI tool, which can be used to download/upload data and update configurations via the API.
• The pysigscia CLI configuration audit tool, which is the focus of this article.

Also, you can find the source code for the pysigsci package on Github.

With the pysigsci package installed, you are ready to go. The first step is to set the required environment variables, so the tool can access the API.

$ export SIGSCI_EMAIL=pxmx@signalsciences.com

$ export SIGSCI_PASSWORD=examplepassword123

$ export SIGSCI_CORP=pxmx

$ export SIGSCI_SITE=site1

Next, run the following command to download configuration data from all sites.

$ pysigscia --get-config

Retrieving configuration for site1...

Retrieving configuration for site2...

Retrieving configuration for site3...

At this point, you are ready to start comparing. There are several options available on how to run the comparison. For example, you can:

• Compare one site to all other sites
• Compare a specific site to another specific site
• Compare all configurations, or just a specific configuration

As of writing this, the following specific configuration options available are:

• request_rules
• signal_rules
• templated_rules
• advanced_rules
• redactions
• custom_signals
• custom_alerts
• header_links
• integrations

Audit Configuration

Run the first comparison of one site to all other sites with the command below. Notice the output is redirected to report.txt.The report can be very long, so saving the output to a file will make it easier to review.

$pysigscia --compare site1 > report.txt

Below is an example output from the command above. For brevity, this is just a snippet from the report and the configuration contents have been redacted. The first section is the comparison of site1 to site2, and the first configuration compared is REQUEST RULES. When you generate your report, you will see sections for all other configurations as well. Within each configuration section, it will indicate if a configuration in site1 does not match up with any configuration in site2. This means the configuration is missing or is not an exact match, and based on your review you may need to make updates to the configuration in site2. Also, this section indicates if a configuration is not in site1 but is in site2. Based on your review, you may need to make updates to the configuration in site1.

## Signal Sciences Configuration Audit Report

######################################################

Comparing configuration for site2…

#### REQUEST_RULES

######################################################

In site1 but not in site2

...

...

...

##############################################

Not in site1 but is in site2

...

...

...

######################################################

Comparing configuration for site3...

#### REQUEST_RULES

######################################################

In site1 but not in site3

...

...

...

##############################################

Not in site1 but is in site3

...

...

...

If you want to target your comparison between just two specific sites, use the following command:

$ pysigsci --compare site1 --to site3 > report.txt

If you want to run comparisons just for a specific configuration or set of configurations use the –configs option. Example command variations:

Compare site2 to all sites for header links configuration:

$ pysigscia --compare site2 --configs header_links > report.txt

Compare site2 to all sites for header links, redactions, and integrations configuration:

$ pysigscia --compare site2

--configs header_links redactions integrations > report.txt

Compare site2 to site3 for header links:

$ pysigscia --compare site2 --to site3 --configs header_links

Example output with configuration contents:

## Signal Sciences Configuration Audit Report

######################################################

#### HEADER_LINKS

######################################################

In site2 but not site3

{

 “root[0]”: {

  “name”: “X-Forwarded-For”,

  “link”: “https://riskdiscovery.com/honeydb/#host/",

  “linkName”: “HoneyDB”,

  “type”: “request”

 }

}

######################################################

Conclusion

The flexible configuration of Signal Sciences is one of the many reasons why it is such a powerful platform for defending web applications. As customers expand their deployment footprint across many applications in their data centers and the cloud, having easy-to-use tools to verify and manage configurations is essential. With the Signal Sciences API and Python packages like pysigsci, you can easily ensure audit your configuration and ensure consistency. There are many more great features to come in Signal Sciences, so keep an eye on the pysgisci project for updates.