Solutions

SBM Web Application Firewall Configuration using ModSecurity on the Security tab in Configurator



ID:    S141332
Published:    02 October 2015
Updated:    04 September 2019

Product(s)

  • SBM
 

Description

 

As of SBM 11.0, you can implement tighter security screening in SBM by enabling the ModSecurity web application firewall on the Security tab in SBM Configurator.  You can choose to enable threat detection logging (via the Log option), or threat detection logging and request filtering (via the Block option) depending on your needs. This option is disabled by default (Off) for new installations and upgrades.
 
Note that the default configuration that is provided by Serena contains a basic set of rules that tighten system security; however, you will ultimately need to customize and add ModSecurity rules in order to block specific requests or threats as necessary.  You must reset IIS for any rule changes to take effect.
 
Below are examples of rules.  For help with ModSecurity rules, check out the ModSecurity Handbook. For more information about ModSecurity, visit https://www.modsecurity.org/
 
Example Rules 
Some rule examples are provided with SBM in the modsecurity_examples.conf file located here:
 
C:\Program Files\Serena\SBM\Application Engine\modsecurity\config\modsecurity_examples.conf
 
These rules simply illustrate how to write rules that target specific problems, while still allowing the rest of SBM to function normally.  For example:
 
# Example that shows how to block a specific parameter that contains a script tag
>>basic rule description
# /tmtrack/tmtrack.dll?IssuePage&RecordId=40&Template=viewwrapper&TableId=1000&Param01=XXX
>>sample that shows the bad parameter
# This rule specifically blocks the Param01 argument when it contains a <script> tag on the IssuePage
>>detailed description including parameter and affected SBM page
# PROVIDED FOR EXAMPLE PURPOSES ONLY.  THIS IS NOT AN ACTUAL PROBLEM.
>>disclaimer
SecRule REQUEST_URI "@contains tmtrack.dll?IssuePage" "id:500001,phase:2,chain,log,block,msg:'URI: %'"
>>rule condition and event log message format
SecRule ARGS:Param01 "@contains <script>"
>>chained argument that describes the problem that should be logged/blocked.  If this argument is true, block the request.
 
In addition, sample OWASP rules are included with SBM that demonstrate what you can do; however, these rules are not tested or supported.  The rules are referenced, but commented out from the modsecurity_iis.conf file located on the Application Engine server here:
 
installDir\Serena\SBM\Application Engine\modsecurity\config\modsecurity_iis.conf
 
You can debug ModSecurity or create an audit log of requests into SBM by configuring options in the modsecurity.conf file located in the same directory.
 
Updated Rules Shipped with SBM 11.0.1
If you have an upcoming security scan that monitors XSS attacks when creating or updating feeds and views in Work Center, you can replace the default rules that shipped in the SBM 11.0 modsecurity.conf file with the following updated rules to ensure that your system passes the security scan.  (These will be shipped with SBM by default in SBM 11.0.1). 
 
On the Application Engine server, navigate to the following location: 
 
installDir\Serena\SBM\Application Engine\modsecurity\config\modsecurity.conf
 
Replace the feed/view creation rules with the following:
 
#XSS in feed/view creation rules
#Enable json body processor on jsonpage requests with command=feedcreate
SecRule ARGS_GET_NAMES "@rx ^(?i)(jsonpage)$" "id:'100004',phase:1,t:lowercase,chain,pass,nolog"
SecRule ARGS_GET:command "@rx ^(?i)(feedcreate|feedupdate)$" "ctl:requestBodyProcessor=JSON"
#Prevent cross-site scripting in description or name parameters on feed creation
SecRule ARGS:description|ARGS:name "@detectXSS" "phase:2,chain,t:lowercase,log,deny,msg:'URI: %, %: %',id:100005"
SecRule ARGS_GET:command "@rx ^(?i)(feedcreate|feedupdate)$"
#The above rule will prevent feasible cross-site scripting attempts in feed creation;
#However simple proof of concept reflection like <a=b> will make it through
#Enable the below more restrictive 2-line rule to block these too (and any <...> patterns in feed names/descriptions)
#SecRule ARGS:description|ARGS:name "@rx (<.*>)" "phase:2,chain,t:lowercase,log,deny,msg:'URI: %, %: %',id:100006"
#SecRule ARGS_GET:command "@rx ^(?i)(feedcreate|feedupdate)$"
#Enable json body processor in view creation requests
#Note that the modsecurity module must be enabled at the website level in IIS to filter requests made to commonsvc
SecRule REQUEST_LINE "@rx ^(?i)(POST)" "id:'100007',phase:1,chain,pass,nolog"
SecRule REQUEST_HEADERS:'/^(?i)(TOMCATURI)/' "@rx ^(?i)(\/commonsvc\/workcenter\/view\/)(create|update)" "ctl:requestBodyProcessor=JSON"
#Detect and block cross-site scripting attempts in the view creation desciption or name parameter
SecRule ARGS:description|ARGS:name "@detectXSS" "phase:2,chain,t:lowercase,log,deny,msg:'%: %, %: %',id:100008"
SecRule REQUEST_HEADERS:'/^(?i)(TOMCATURI)/' "@rx ^(?i)(\/commonsvc\/workcenter\/view\/)(create|update)"
#The above rule will prevent feasible cross-site scripting attempts in view creation;
#However simple proof of concept reflection like <a=b> will make it through
#Enable the below more restrictive 2-line rule to block these too (and any <...> patterns in view names/descriptions)
#SecRule ARGS:description|ARGS:name "@rx (<.*>)" "phase:2,chain,t:lowercase,log,deny,msg:'%: %, %: %',id:100009"
#SecRule REQUEST_HEADERS:'/^(?i)(TOMCATURI)/' "@rx ^(?i)(\/commonsvc\/workcenter\/view\/)(create|update)"

Adding the CSRF Rule for SBM 11.X to 11.3 Releases

To mitigate CSRF vulnerabilities against Work Center in any SBM release between 11.0 and 11.3, you can add a ModSecurity rule that checks by Origin or Referer HTTP header.

To install and enable this rule:
1. On the Application Engine server, copy attached the attached modsecurity_CSRF.conf file to ...\SBM\Application Engine\modsecurity\config
2. Modify file ...\SBM\Application Engine\modsecurity\config\modsecurity_iis.conf and add the line:

Include modsecurity_CSRF.conf

3. Open SBM Configurator.  In the Security | Secure SBM tab, change the Filter level under Web Application Firewall to "Block"
4. Click Apply and make sure that the IIS service is restarted.

Adding the Rule to Block SQL Injection with Change History Reports in All SBM Releases

To mitigate a SQL injection vulnerability when previewing or executing a Change History report that contain Advanced SQL conditions in any SBM release, you can add a ModSecurity rule that prevents the report from being executed.

To install and enable this rule:
1. On the Application Engine server, copy attached the attached modsecurity_sql.conf file to ...\SBM\Application Engine\modsecurity\config
2. Modify file ...\SBM\Application Engine\modsecurity\config\modsecurity_iis.conf and add the line:

Include modsecurity_sql.conf

3. Open SBM Configurator.  In the Security | Secure SBM tab, change the Filter level under Web Application Firewall to "Block"
4. Click Apply and make sure that the IIS service is restarted.

 

Adding a Rule to Enforce the “application/json” Request Header for all JSONPage Application Engine Requests


The following rule rejects JSONPage requests if the HTTP header Content-Type is anything other than “application/json”.  This vulnerability was fixed in SBM 11.4; therefore, the following applies to releases prior to 11.4.


1. On the Application Engine server, edit the following file:
C:\Program Files\Serena\SBM\Application Engine\modsecurity\config\modsecurity.conf


2. Add the following rule below the existing rule with id:100006:


#Enforce Request Header Content-Type, application/json, on all JSONPage SBM AE requests
SecRule REQUEST_URI "@rx (\?|&)(?i)(JSONPage&)" "phase:1,chain,log,deny,msg:'Content-Type must be \'application/json\'.',id:100007"
SecRule REQUEST_HEADERS:'Content-Type' "!@rx ^(?i)(application\/json)"
 

3. Save your change to the modsecurity.conf file.
4. On the Application Engine server, open SBM Configurator.
5. Open the Security tab, and then set the Web Application Firewall Filter Level to Block.
6. Click the Apply button.  This restarts the services, including IIS, which must be restarted for the rule to take effect.  
 

 

Adding a Rule to Block XSS injections in Drill-Through Reports

 

The following rule blocks potential XSS injections in Drill Through reports.  This vulnerability was fixed in SBM 11.6.2; therefore, the following applies to releases prior to 11.6.2.


1. On the Application Engine server, edit the following file:
C:\Program Files\Serena\SBM\Application Engine\modsecurity\config\modsecurity.conf
2. Add the following rule and ensure the "id:" value is unique:


#Validate Drill Through Report: dtmatrix parameter on report save.
#Fixed in SBM 11.6.2 and later versions
SecRule REQUEST_URI "@contains &dtmatrix=" "phase:2,chain,log,block,msg:'URI: %',id:500011"
SecRule ARGS:dtmatrix "!@rx ^[0-3]+$"


3. Save your change to the modsecurity.conf file.
4. On the Application Engine server, open SBM Configurator.
5. Open the Security tab, and then set the Web Application Firewall Filter Level to Block.
6. Click the Apply button.  This restarts the services, including IIS, which must be restarted for the rule to take effect.  
 

Applies To

SBM 11.0
SBM 11.1
SBM 11.2
SBM 11.3

Attachment

File NameFile SizeDownLoad
modsecurity_CSRF.conf 1K HTTPS
modsecurity_sql.conf 276Bytes HTTPS

Rate this Solution

Find Answers

Type a question or describe what you are looking for below

My Recent Searches

Welcome kb sso

Additional Assistance

  • Submit a Case Online
  • FAQs