Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Developing Security Policies Task Summary

    An IDP security policy allows you to use various attack detection and prevention techniques on traffic that traverses your network.

    To create an effective security policy, follow these basic steps:

    1. Run the New Policy wizard to create a security policy object. The new security policy can be based on a predefined template.
    2. Use the Security Policy editor to add one or more rulebases. Table 1 describes the IDP security policy rulebases. A security policy can contain only one instance of any rulebase type.

      A rulebase is an ordered set of rules that use a particular detection method to identify and prevent attacks.

    3. Within rulebases, configure rules.

      Rules are instructions that provide context to detection methods. Rules specify:

      • A source/destination/service match condition that determines which traffic to inspect.
      • Attack objects that determine what to look for (IDP rulebase and Exempt rulebase).
      • Actions that determine what to do when an attack is detected or the application rate limit is reached.
      • Notification options, including logs, alerts, and packet captures.

        Each rulebase can contain up to 40,000 rules.

    4. Fine-tune your security policy as you learn more about your network and security requirements and IDP Series capabilities.

    Table 1: IDP Security Policy Rulebases

    Rulebase

    Description

    IDP rulebase

    Protects your network from attacks by using attack objects to detect known and unknown attacks. Juniper Networks provides predefined attack objects that you can use in security policy rules. You can also configure your own custom attack objects.

    See Modifying IDP Rulebase Rules (NSM Procedure).

    Exempt rulebase

    Enables you to exclude known false positives or to exclude a specific source, destination, or source/destination pair from matching an IDP rule. If traffic matches a rule in the IDP rulebase, the IDP engine attempts to match the traffic against the Exempt rulebase before performing the action specified.

    See Configuring Exempt Rulebase Rules (NSM Procedure).

    APE rulebase

    Enables you to set an action for traffic that matches an application signature. Actions include dropping the connection, closing client and/or server, applying a DiffServ marker, applying a rate limit condition, or applying both a DiffServ market and a rate limit condition.

    See Configuring the APE Rulebase (NSM Procedure).

    Backdoor rulebase

    Protects your network from mechanisms installed on a host computer that facilitates unauthorized access to the system. Attackers who have already compromised a system typically install backdoors (such as Trojans) to make future attacks easier. When attackers send and retrieve information to and from the backdoor program (as when typing commands), they generate interactive traffic that the IDP engine can detect.

    See Configuring Backdoor Rulebase Rules (NSM Procedure).

    SYN Protector rulebase

    Protects your network from SYN-floods by ensuring that the three-way handshake is performed successfully for specified TCP traffic. If you know that your network is vulnerable to a SYN-flood, use the SYN-Protector rulebase to prevent it.

    See Configuring SYN Protector Rulebase Rules (NSM Procedure).

    Traffic Anomalies rulebase

    Protects your network from attacks by using traffic flow analysis to identify attacks that occur over multiple connections and sessions (such as scans).

    See Configuring Traffic Anomalies Rulebase Rules (NSM Procedure).

    Network Honeypot rulebase

    Protects your network by impersonating open ports on existing servers on your network, alerting you to attackers performing port scans and other information-gathering activities.

    See Configuring Network Honeypot Rulebase Rules (NSM Procedure).


    Published: 2011-02-08