Getting Started

To get started with Real-time protection integration, you should have completed the integration in Monitor mode and received the initial traffic report from the ShieldSquare Service.

Note: Before getting started with the Real-time protection, make sure that you have gone through the configurations to be done in Monitor Mode.

Introduction

Real-time Protection

Integration in Real-time protection prevents bots in real-time. In this mode, every API call is responded to with an appropriate response code that indicates the action to be taken on the incoming request.

Note: All the API calls made in this mode will be synchronous.

Follow these steps for integration in Real-time Protection.

Move to Active mode
Set your configuration file
Configure the Rules
Modify your code while moving from Monitor mode to Real-Time protection
Verify Integration
Move the changes to your Production Environment
Block Page as an add on to ShieldSquare services

Move to Active Mode

In order to monitor your site’s traffic and control it in real-time, you need to first switch to active mode from Monitor mode. Follow the instructions below:

Login to your dashboard
Click on Bot Response List
Switch the toggle button present on the right side of the screen from Monitor to Active
Change the value of the _mode property in the config file to "Active" instead of "Monitor"

Set your Configuration file

The configuration file which was set during monitor mode integration will now need a few changes. These changes attribute to switching from Monitor to Active mode.

The final ss2_config.rb should look like (values may differ):

config.sid = “Your Production ID”
config.mode = "Active"
config.async_http_post = true
config.timeout_value = 100
config._ipaddr = "auto"
config.ss2_domain = 'ss_sa.shieldsquare.net'
config.domain_ttl = 3600
config.domain_cache_file = '/tmp/'
config.deployment_number = '1234'

Parameters which will need changes.

Parameter	Description	Type	Required

Parameter	Description	Type	Required
_sid	Assuming you have already integrated in Monitor mode, use the Sandbox ID to verify the Active mode changes and change to your Production ID once this is verified and moved to production. You can use the Sandbox ID to verify the Active mode changes first and then make use of the Production ID once the verification is done.	Alphanumeric	Yes
_mode	Set the mode of the operation depending on the mode of activation: _mode = ‘Active’; //For Active Mode	String	Yes

Configuring the Rules

This section helps you configure rules to manage traffic. To do so, navigate to Bot Response List under Configuration in the dashboard. The rules can be configured to return response codes as explained below:

Code	Status	Description

Code	Status	Description
-1	Exception	This indicates that the request has not reached ShieldSquare due to some issues. Such requests should be allowed access.
0	Allow	This indicates that the request is either coming from a genuine user or a good crawler like Google or Bing, and the request should be allowed.
2	Show CAPTCHA	Indicates that the requests are coming from bad bots and a CAPTCHA page needs to be displayed.
3	Block	This indicates that requests are coming from bad bots and should be blocked.
4	Feed Fake Data (FFD)	This indicates that requests are coming from bad bots and that you can feed fake data.

Modify your code while moving from Monitor Mode to Real-Time protection

The next step is to make a few modifications in the code that makes the API call to ShieldSquare Service. This step assumes that you have already integrated API Call in Monitor mode.

There will be no change in the JS code when switching modes.

The API call shieldsquare_ValidateRequest(username, calltype) will take the following parameters as inputs:

UserName: Set the User ID of the logged-in visitors to shieldsquare_username

CallType: The value of shieldsquare_calltype determines the type of the call and can have the values below:

Value	Description

Value	Description
1	If the current request is for a page load, pass the call type parameter to the service as 1
2	If the current request is a Form Submit, pass the call type parameter to the service as 2
4	If the current page is a CAPTCHA page or Block page, pass the call type parameter to the service as 4
5	If the CAPTCHA is solved successfully, pass the call type parameter to the service as 5
6	If the current request is from a mobile app, pass the call type parameter to the service as 6
7	If the current request is from a feature phone, pass the call type parameter to the service as 7

Page ID

Keep this parameter as an empty string for all call types.

def call_shield_square
	@shieldsquare_call_type ||= 1 // Update corresponding value as per CallType in the below table.
	@shieldsquare_response = Ss2.shieldsquare_ValidateRequest("shield_square_user_name", @shieldsquare_call_type, "", request, cookies)
	
    if @shieldsquare_response.responsecode == 0
		logger.debug "Allow the user request"		
		elsif @shieldsquare_response.responsecode == 2
			logger.debug "Show CAPTCHA to the user"
		elsif @shieldsquare_response.responsecode == 3
			logger.debug "Block This request"
		elsif @shieldsquare_response.responsecode == 4
			logger.debug "Feed Fake Data"			
		elsif @shieldsquare_response.responsecode == -1
			logger.debug "Please reach out to ShieldSquare support team for assistance "
			logger.debug "Allow the user request"      
    end		
    redirect_url = @shieldsquare_response.url
    unless redirect_url.blank?
        redirect_to(redirect_url) and return
    end
end

Verify Integration

Visit the verify integration page in the ShieldSquare Admin Portal. Green checkmarks for "API Data - IP Details" & "API Data - Session Details" will indicate the successful integration of ShieldSquare with your website. A minimum of 5 requests has to be made from the same machine using the same browser for the checkmarks to appear as an indication of the status of integration. A red checkmark indicates that a particular step might have been executed incorrectly.

The ShieldSquare Customer Onboarding team will verify and validate the configurations typically within 24 hours. This will ensure that the production site’s performance is not affected due to a wrong configuration set during the integration process.

Move Changes to Production

config.sid =“YourProduction ID”
config.mode ="Active"
config.async_http_post =true
config.timeout_value =100
config._ipaddr ="auto"
config.ss2_domain ='ss_sa.shieldsquare.net'
config.domain_ttl =3600
config.domain_cache_file ='/tmp/'
config.deployment_number ='1234'
config.ip_index = 1
config._support_email = "botmanager_support@radware.com"
config._redirect_domain = "validate.perfdrive.com"
config._ss_block_enabled = true
config._ss_captcha_enabled = true
config._sessid = ""

In order to move changes to production, replace_sidparameter ( in the ss2_config file) with the Production ID. It takes about 2-3 hours for the production data to reflect in the ShieldSquare Dashboard.

Radware Bot Manager Integration Portal

SDK Integration | Ruby - Active mode