SDX 6.4.x Application Library Guide > Providing Threat Mitigation Services with the Threat Mitigation Application > Configuring Threat Mitigation

Configuring Threat Mitigation

To support threat mitigation with the Threat Mitigation Application in an SDX network, configure services that can be activated to act on threats detected by IDP sensors that are managed by NetScreen-Security Manager. We recommend that you activate the services as close as possible to the interfaces where the problem traffic entered the network.

For detailed information about configuring services, see SDX Services and Policies Guide, Chapter 1, Managing Services.

To use the Threat Mitigation Application, perform the following tasks:

• Configuring a Database to Store Attack and Response Data
• Configuring the Threat Mitigation Application
• Deploying the Threat Mitigation Application
• Applying SDX Services to Manage Threats
• Classifying Subscribers and Interfaces

Some sections provide references to entries in the sample data that demonstrate an implementation.

After performing these tasks, configure the script used by NetScreen-Security Manager to implement the messaging that records attacks and identifies actions that the SDX software should take in response to those attacks. See Enabling SDX Actions from NetScreen-Security Manager.

Configuring a Database to Store Attack and Response Data

The Threat Mitigation Application requires a transactional database to store attack types and candidate responses. For information about databases that we have tested for use with the Threat Mitigation Application, see the SDX Application Library Release Notes.

The Threat Mitigation Application provides sample data for a schema that includes these tables:

• ATTACK_TYPE—Contains information about the attacks that NetScreen-Security Manager is expected to send to the Threat Mitigation Application. The administrator maintains this data. See Configuring Attack Types in the Database.
• ACTION—Contains information about the SDX services that are activated to respond to attacks. The administrator maintains this data. See Configuring Actions in the Database.
• ATTACK_TYPE_CANDIDATE_ACTION—Contains information about the actions that can be taken in response to specific attack types. The administrator maintains this data. See Configuring Candidate Actions in the Database.
• ATTACK—Contains information about the attacks that are managed by the Threat Mitigation Application. The Threat Mitigation Portal displays this information on various pages, including the Attack Details page. For information about how the Threat Mitigation Portal displays the attributes, see About the Record Servlet.

To use the Threat Mitigation Application, the administrator must create data in the ATTACK_TYPE, ACTION, and ATTACK_TYPE_CANDIDATE_ACTION tables to define the relationship between attack types and candidate actions. The information in the ATTACK table is managed by the Threat Mitigation Application and must not be modified by an administrator. The attributes specified in the tables are referenced in the XML schema for NetScreen-Security Manager attack events.

To configure the database:

1. Create a database, tables, and user for the database by using the following database schema file:

/opt/UMC/conf/thma/etc/<database>/thma.sql

where <database> is the selected database when you run the load script. This file is created when you install the Solaris package for the Threat Mitigation Application.

2. Load the sample data for the database using the following file:

/opt/UMC/conf/thma/etc/<database>/data.sql

where <database> is the selected database when you run the load script. This file is created when you install the Solaris package for the Threat Mitigation Application.

Configuring Attack Types in the Database

The ATTACK_TYPE table contains data about all the attacks that NetScreen-Security Manager is expected to send to the Threat Mitigation Application. Attacks are considered to be the same attack type if their category, subcategory, and definingAttributes values are the same.

NOTE: The ATTACK_TYPE table must contain a special attack type with category and subcategory values of DEFAULT to respond to attacks that do not match a configured attack type.

The entry in the /opt/UMC/conf/thma/etc/<database>/data.sql file contains the attributes in the format:

INSERT INTO ATTACK_TYPE 

VALUES ('<category>', '<subcategory>', '<definingAttributes>', '<description>'); 

For example:

INSERT INTO ATTACK_TYPE 

VALUES ('DEFAULT', 'DEFAULT', 'srcAddr', 'There is no specific information for this type 
of attack.'); 

ATTACK_TYPE Attributes

The Threat Mitigation Portal displays the configured attributes for the attack types that are used by the Threat Mitigation Application.

category

• Category of the attack; displayed in the Attack Details page.
• Value—Text string
• Examples

• DEFAULT
• predefined

subcategory

• Subcategory of the attack; displayed in the Attack Type column.
• Value—Text string
• Examples

• DEFAULT
• FTP:USER:ROOT
• ICMP:EXPLOIT:FLOOD

definingAttributes

• Attributes used to identify an attack. Defining attributes determine whether an attack is a new record or an update to an existing attack record. The srcAddr attribute is always considered a defining attribute for the attack, even if it is not specified as a defining attribute.
• Value—List of defining attributes separated by semicolons

• srcAddr—Source address; displayed in the Source column
• srcPort—Source port; displayed in the Attack Details page
• dstAddr—Destination address; displayed in the Destination column
• dstPort—Destination port; displayed in the Attack Details page
• protocol—Protocol; displayed in the Attack Details page
• user—User; displayed in the Attack Details page
• app—Application; displayed in the Attack Details page
• uri—Uniform resource identifier; displayed in the Attack Details page

• Examples

• srcAddr
• srcAddr;dstAddr;dstPort
• srcAddr;dstAddr

description

• Description of the attack; displayed in the Attack Details page.
• Value—Text string
• Examples

• There is no specific information for this type of attack.
• This attack indicates an ICMP session that contains more than 250 ICMP packets per second. This may indicate that an attacker is trying to degrade network performance, causing poor service for legitimate users.

Configuring Actions in the Database

The ACTION table contains data about services to activate in response to an attack. The administrator must add one ACTION table entry for each SDX service that is used as an action in the Threat Mitigation Application.

The entry in the /opt/UMC/conf/thma/etc/<database>/data.sql file contains the attributes in the format:

INSERT INTO ACTION 

VALUES ('<serviceName>', '<name>', '<description>'); 

For example:

INSERT INTO ACTION 

VALUES ('BlockAttacker', 'Block Attacker', 'This action blocks all traffic to and from the 
attacker.'); 

ACTION Attributes

The Threat Mitigation Portal displays the configured attributes for the actions that are used by the Threat Mitigation Application.

serviceName

• Service activated in response to an attack.
• Value—Text string

The following values are passed to the service as parameter substitutions:

• category—Name of the category
• subcategory—Name of the subcategory
• severity—Severity level as a number in the range 0-5

• 0—not set
• 1—info
• 2—warning
• 3—minor
• 4—major
• 5—critical

• srcAddr—IP address; enclose in single quotes if not in IPv4 format
• srcPort—Port number
• dstAddr—IP address; enclose in single quotes if not in IPv4 format
• dstPort—Port number
• protocol—Protocol number
• user—Username
• app—Name of the application
• uri—Uniform resource identifier

The category, subcategory, user, app, and uri parameters are encoded as valid parameter names (not text strings) so that these parameter values can be provided to the policies.

For example, you could define a policy that takes the app parameter as the value for a policer rate with a default value of 64000. Then, you could define global parameters named after different applications, such as http=32000. When the attack includes an HTTP application, the Threat Mitigation Application would pass app=http, and 32000 would be the value in the policer definition.

• Example—BlockAttacker

name

• Name of action; displayed in the Action drop-down list.
• Value—Text string
• Example—Block Attacker

description

• Description of the action; displayed in the Action Help page.
• Value—Text string
• Example—This action blocks all traffic to and from the attacker.

Configuring Candidate Actions in the Database

The ATTACK_TYPE_CANDIDATE_ACTION table contains data about the possible services to activate in response to a particular type of attack.

The entry in the /opt/UMC/conf/thma/etc/<database>/data.sql file contains the attributes in the format:

INSERT INTO ATTACK_TYPE_CANDIDATE_ACTION 

VALUES ('<category>', '<subcategory>', '<serviceName>'); 

For example:

INSERT INTO ATTACK_TYPE_CANDIDATE_ACTION 

VALUES ('DEFAULT', 'DEFAULT', 'BlockAttack'); 

ATTACK_TYPE_CANDIDATE_ACTION Attributes

The Threat Mitigation Portal displays the configured attributes for the attack type and candidate actions.

category

• Category of the attack; displayed in the Attack Details page.
• Value—Text string
• Examples

• DEFAULT
• predefined

subcategory

• Subcategory of the attack; displayed in the Attack Type column.
• Value—Text string
• Examples

• DEFAULT
• FTP:USER:ROOT
• ICMP:EXPLOIT:FLOOD

serviceName

• Service activated in response to an attack.
• Value—Text string
• Example—BlockAttacker

Configuring the Threat Mitigation Application

The Threat Mitigation Application configuration script updates the bootstrap configuration for the Threat Mitigation Application and configures the Threat Mitigation Portal.

To configure the Threat Mitigation Application:

1. On the host, log in as root or as another authorized administrator.
2. Launch the configuration tool.

/opt/UMC/conf/thma/etc/config 

The configuration tool window appears.

3. Edit or accept the values for the fields in the appropriate tab to perform these tasks:

• Configuring Connections to the Directory
• Configuring Logging
• Configuring the Threat Mitigation Portal

4. Click OK.
5. A file called config.properties appears in the /opt/UMC/conf/thma/etc folder, and it is added to the /opt/UMC/conf/thma/webapp/thma.ear file.

Configuring Connections to the Directory

The Threat Mitigation Application loads configurations from the directory. If you install the directory on a different host than the J2EE application server, you must modify the bootstrap properties to specify the directory host.

To configure the connections to the directory for the Threat Mitigation Application, edit or accept the default values for the fields in the LDAP tab.

Configuration Directory URL

• URL of the primary directory.
• Value—URL in the format ldap://<host>:<port>/

• <host>—IP address or name of directory host
• <port>—Port of directory host

• Default—ldap://127.0.0.1:389/
• Property name—Config.java.naming.provider.url

Backup Configuration Directory URLs

• List of redundant directories.
• Value—Space-separated list of URLs; URLs have the format
  ldap://<host>:<port>/

• <host>—IP address or name of directory host
• <port>—Port of directory host

• Default—Unspecified
• Example—ldap://192.0.2.1:389/ ldap://192.0.2.3:389/
• Property name—Config.net.juniper.smgt.des.backup_provider_urls

Configuration Directory Authentication DN

• DN of the directory entry that defines the username with which the SDX component accesses the directory.
• Value—<DN>
• Default—cn=nic, ou=Components, o=Operators, o=umc
• Example—cn=conf, o=Operators, o=umc
• Property name—Config.java.naming.security.principal

Configuration Directory Password

• Password with which the Threat Mitigation Application accesses the directory.
• Value—Text string
• Default—nic
• Example—secret
• Property name—Config.java.naming.security.credentials

Connect Timeouts [s]

• Maximum time that the directory eventing system (DES) waits for the directory to respond.
• Value—Number of seconds in the range 1-2147483647
• Default—10
• Example—5
• Property name—Config.net.juniper.smgt.des.connect.timeout

Configuring Logging

To configure logging for the Threat Mitigation Application, edit or accept the default values for the fields in the Loggers tab.

For more information about logging, see SDX Monitoring and Troubleshooting Guide, Chapter 2, Configuring Logging for SDX Components.

Configuring the Threat Mitigation Portal

To configure the Threat Mitigation Portal, edit or accept the default values for the fields in the Other tab.

Service Activation Interface

• Type of interface on which the service would be activated.
• Value

• Provider Edge Interface (JUNOS subscriber-facing interface)
• Forwarding Interface (JUNOS forwarding interface)
• Subscriber Interface (JUNOSe subscriber interface)

• Guidelines—If you change this property, you must reconfigure your NIC host. For more information, see Using the NIC Resolver for the Threat Mitigation Portal.
• Default—Provider Edge Interface

Retailer Domain

• Retailer domain for the Threat Mitigation Portal.
• Value—Text string
• Guidelines—This property must match one of the retailer domain names defined for the retailer in the target of the subscriber classification rules used for the interfaces managed by the Threat Mitigation Application. For more information about adding retailers, see SDX Subscribers and Subscriptions Guide, Chapter 8, Configuring Subscribers and Subscriptions.
• Default—thma

Path

• Pathname for the Threat Mitigation Portal and record servlet.
• Value—<pathname>
• Default—/thmp/record

Retry Period

• Time to wait between two consecutive retries of all pending service activation or deactivation tasks that were executed unsuccessfully.
• Value—Number of milliseconds in the range 0-9223372036854775807
• Guidelines—Do not specify too small a value, because the number of attempts could cause network overload.
• Default—60000

Retry Delay

• Time to wait before retrying all pending service activation or deactivation tasks that were executed unsuccessfully.
• Value—Number of milliseconds in the range 0-9223372036854775807
• Default—10000

Deploying the Threat Mitigation Application

The Threat Mitigation Application load script configures components (such as the J2EE application server, directory, and database) on the local host. However, depending on the components used, their installation host, and their configuration, you may need to manually configure some of the components or modify the configuration.

The Threat Mitigation Application load script automates the process of deploying the Threat Mitigation Application in JBoss (if it is installed locally) and completes these configuration tasks:

• Configures the jbosscmp-jdbc.xml file inside the /opt/UMC/conf/thma/webapp/thma.ear file and the data source deployment descriptor based on the type of database specified and the database connection information.
• Installs the JDBC driver, data source deployment descriptor, and authentication configurations in JBoss (if JBoss is installed locally).
• Loads the Threat Mitigation Application sample data in the directory.
• Creates the database schema and loads sample database records. Follow the instructions at the end of the load script to complete the database configuration for the selected database. Some databases might require additional steps, such as creating a database user or enabling a remote TCP/IP connection.

To deploy the Threat Mitigation Application:

1. On the host, log in as root or as another authorized administrator.
2. Invoke the script by accessing the folder /opt/UMC/conf/thma/etc and running the load command.

cd /opt/UMC/conf/thma/etc 

./load 

3. Deploy the thma.ear file by using the procedure appropriate for your Web application server.

If you are using JBoss, copy the file to the JBoss /default/deploy directory. For example:

cp /opt/UMC/conf/thma/webapp/thma.ear 
/opt/UMC/jboss/server/default/deploy 

Applying SDX Services to Manage Threats

You can configure services to control problem traffic, such as limiting bandwidth or blocking traffic, in response to detection of malicious traffic. The Threat Mitigation Application passes the defining attribute values of the attack type to the service as parameters for possible use in the policies. The Threat Mitigation Application supports service activation on the JUNOS forwarding interface, the JUNOS provider edge interface, or the JUNOSe subscriber interface. You can configure only one of these interfaces as the service activation interface for the Threat Mitigation Application, but you can use an aggregate service to apply the policies on a combination of those interfaces. For information about configuring the service activation interface, see Configuring the Threat Mitigation Portal.

The following example describes how to configure policies to decrease the amount of bandwidth available to the attacker and to block the attack or the attacker as implemented in the sample data. You can use any of these services or create your own services to define actions for the Threat Mitigation Application.

To configure services and policies to handle threats:

1. In Policy Editor, create a policy that defines an action to be taken.

The sample data for each type of interface contains these policy groups:

• blockAttack—Blocks all traffic between the source and destination addresses for the specified protocol and ports. If the protocol or ports are not specified, then the default value is any protocol and any port.
• blockAttacker—Blocks all traffic coming from or going to the source address.
• default—Forwards traffic.
• slowAttacker—Limits the bandwidth available for all traffic coming from or going to the source address according to the specified rate.

For a policy folder that contains these policy groups for the JUNOS forwarding interface, see ou=forwardingInterface, ou=thma, o=Policies, o=umc in the sample data.

For a policy folder that contains these policy groups for the JUNOS provider edge interface, see ou=peInterface, ou=thma, o=Policies, o=umc in the sample data.

For a policy folder that contains these policy groups for the JUNOSe subscriber interface, see ou=subrInterface, ou=thma, o=Policies, o=umc in the sample data.

For information about configuring policies, see SDX Services and Policies Guide, Chapter 5, Configuring and Managing Policies.

2. In SDX Admin, create a new scope or use an existing scope for the services that define actions to be taken in response to attacks on different interfaces.

For a sample scope that applies to the JUNOS forwarding interface, see l=THMA-ForwardingInterface, o=Scopes, o=umc.

For a sample scope that applies to the JUNOS provider edge interface, see l=THMA-PEnterface, o=Scopes, o=umc.

For a sample scope that applies to the JUNOSe subscriber interface, see l=THMA-SubrInterface, o=Scopes, o=umc.

For general information about configuring scopes, see SDX Services and Policies Guide, Chapter 1, Managing Services.

3. For the scope used in Step 2:

1. Create a service that defines actions to be taken in response to threats. You can create different types of services. For example, you can create aggregate services to apply the policies on these interfaces.

The sample data contains normal value-added services that specify the policy group configured in Step 1.

For a sample service to block attacks on the forwarding interface, see serviceName=BlockAttack, l=THMA-ForwardingInterface, o=Scopes, o=umc.

1. Assign the scope to a subscriber folder to make the service available to these subscribers.

For a sample on the JUNOS forwarding interface, see ou=routers, retailerName=SP-THMA, o=Users, o=umc.

For a sample on the JUNOS provider edge interface, see ou=subscribers_peIf, retailerName=SP-THMA, o=Users, o=umc.

For a sample on the JUNOSe subscriber interface, see ou=subscribers_subrIf, retailerName=SP-THMA, o=Users, o=umc.

For information about configuring services and assigning scopes, see SDX Services and Policies Guide, Chapter 1, Managing Services. For information about adding subscribers, see SDX Subscribers and Subscriptions Guide, Chapter 8, Configuring Subscribers and Subscriptions.

4. Create service subscriptions for subscribers. In the sample data, we create a subscription at the folder level to allow all subscribers in the folder to inherit the subscription. Configure the subscriptions to manually activate the service through the Threat Mitigation Portal.

For a sample implementation, see serviceName=BlockAttack, retailerName=SP-THMA, o=Users, o=umc in the sample data.

For information about configuring subscriptions, see SDX Subscribers and Subscriptions Guide, Chapter 8, Configuring Subscribers and Subscriptions.

Classifying Subscribers and Interfaces

To apply policies to the forwarding interfaces, you configure additional entries in the subscriber classification and interface classification scripts. For general information about classifying subscribers and interfaces, see SDX Subscribers and Subscriptions Guide, Chapter 4, Classifying Interfaces and Subscribers.

Example: Subscriber Classification Scripts

In the subscriber classification script, threat mitigation requires the assignment of a subscriber profile for the forwarding interface and for any interface other than the forwarding interface (such as the provider edge interface on the JUNOS routing platform).

The Threat Mitigation Application needs to identify subscriber sessions in which to activate services persistently. These subscriber sessions should have a login name so that subscriber entries in the directory can be shared among the managed routers or interfaces. The login name must be unique. We recommend using the interface name and virtual router name to construct a unique login name. The login name must end in @<retailer's domain> and must not contain a / (slash) or another @ (at sign).

[routerName=commonRouterProfile,ou=routers,retailername=SP-THMA,o=Users,o=UM
C?loginName=<-virtualRouterName.replace("@", "_")+"@thma"->??] 

# host subscriber for JUNOS routers 

interfaceName=="FORWARDING_INTERFACE" 

This subscriber classification for the forwarding interface sets the virtual router name as the login name and thma as the service provider's domain name. The domain name must match the value of the Retailer Domain field specified when configuring the Threat Mitigation Portal. See Configuring the Threat Mitigation Portal.

[uniqueID=DefaultTHMASubscriber,ou=subscribers,retailername=SP-THMA,o=Users,o=
UMC?loginName=<-interfaceName.replace("@", "_").replace("/", 
"_")+"_"+virtualRouterName.replace("@", "_")+"@thma"->??] 

# anything that is not the forwarding interface uses default subscriber 

interfaceName!="FORWARDING_INTERFACE" 

This subscriber classification for the provider edge interface sets the interface name as the login name.

To view the subscriber classifications referenced in this section, see l=THMA, l=SAE, ou=staticConfiguration, ou=Configuration, o=Management, o=umc in the sample data.

Example: Interface Classification Scripts for JUNOS Routing Platforms

An entry is needed in the interface classification script to specify the default policy for forwarding interfaces and provider edge interfaces on the JUNOS routing platforms. For example:

[policyGroupName=default,ou=forwardingInterface,ou=thma,o=Policies,o=UMC] 

# manage router interface for mirroring 

interfaceName=="FORWARDING_INTERFACE" 

[policyGroupName=default,ou=peInterface,ou=thma,o=Policies,o=UMC] 

# manage interfaces with an alias indicating 

# an enterprise customer 

interfaceName!="FORWARDING_INTERFACE"

To view the interface classifications referenced in this section, see the interface classification for the THMA<number> routers listed under o=Network, o=umc in the sample data.

Example: Interface Classification Scripts for JUNOSe Routers

An entry is needed in the interface classification script to specify the default policy for subscriber interfaces on the JUNOSe routers. For example:

# generic PPP users

[policyGroupName=default,ou=subrInterface,ou=thma,o=Policies,o=UMC] 

pppLoginName!=""

# define DHCP interfaces here 

[policyGroupName=DHCP,ou=junose,ou=sample,o=Policies,o=umc] 

# all fastEthernet interfaces 

interfaceName="fastEthernet*" 

To view the interface classifications referenced in this section, see the interface classification for orderedCimKeys=THMA_JUNOSE, o=Network, o=umc in the sample data.