8.4. Intrusion prevention system

The intrusion detection and prevention system (IPS) can quickly detect malicious activity in your local network or from the Internet, identify, record and prevent various threats, and generate detailed reports on each suspicious event. Security breaches are usually detected by means of heuristic techniques and matching with signatures of already known attacks. If you have the corresponding license, UserGate will be regularly providing you with its up-to-date databases of heuristic rules and attacks' signatures. IPS can track and proactively block all the detected attacks in real time, e.g. terminate malicious network connections, send notifications to network administrators, log the suspicious activity, and so on.

To get started with IPS, perform the following:

Name

Description

Step 1. Create required IPS profiles

An IPS profile is a set of signatures relevant for the protection of certain services. Administrators can create any number of IPS profiles to protect various services. It is recommended that you avoid adding excessive signatures to profiles and use only signatures that are really important for security. For example, do not add UDP-specific signatures to a profile that protects a TCP-based service. When there are too many signatures, the system will be processing the traffic longer due to additional workload on the CPU.

Step 2. Create the IPS rules

The IPS rules define IPS actions depending on the traffic type checked by the IPS module according to the assigned IPS profiles.

To set up the IPS profile, click IPS profiles in the Security policies-->Library and then add all necessary signatures to the policy. The IPS signatures are regularly updated and delivered by UserGate to the corresponding subscribers. Each signature contains the following fields:

Name

Description

Signature

Name of the signature

Risk

Signature's risk from 1 (low risk) to 5 (high risk)

Protocol

Protocol of the signature:

  • IP

  • ICMP

  • TCP

  • UDP

Category

Category is group of signatures with some common properties. List of categories can be extended in the future:

  • attack_response -- signatures designed to catch the results of a successful attack.

  • botcc (Bot Command and Control) -- These are autogenerated from several sources of known and confirmed active Botnet and other Command and Control hosts.

  • botcc.portgrouped -- same as above, but grouped by destination port.

  • ciarmy -- collective intelligence generated IP rules for blocking based upon www.ciarmy.com.

  • compromised --list of known compromised hosts.

  • current_events -- category for active and short lived campaigns. This category covers exploit kits and malware that will be aged and removed quickly due to the short lived nature of the threat.

  • dns - known DNS vulnerabilities

  • dos -- Denial of Service attempt detection.

  • drop -- signatures to block spamhaus "drop" listed networks. More info at http://www.spamhaus.org.

  • dshield -- IP based signatures for Dshield Identified attackers. More information can be found at http://www.dshield.org.

  • exploit --direct exploits.

  • ftp - signatures for attacks, exploits, and vulnerabilities regarding FTP.

  • icmp - signatures for attacks and vulnerabilities regarding ICMP.

  • icmp_info - signatures to log ICMP protocol specific events, typically normal operation.

  • imap - signatures for the identification, as well as attacks and vulnerabilities regarding the IMAP protocol.

  • info - potential data leak

  • malware -- malware and spyware related, no clear criminal intent.

  • misc - signatures not covered in other categories.

  • mobile_malware -- signatures specific to mobile platforms.

  • netbios - signatures for the identification, as well as attacks, exploits and vulnerabilities regarding Netbios.

  • p2p -- signatures for the identification of Peer-To-Peer traffic and attacks against.

  • policy-- signatures often disallowed by company or organizational policy.

  • pop3 - signatures for the identification, as well as attacks and vulnerabilities regarding the POP3 protocol.

  • rpc -- RPC related attacks, vulnerabilities, and protocol detection.

  • scada -- Signatures for SCADA attacks, exploits and vulnerabilities, as well as protocol detection.

  • scan - things to detect reconnaissance and probing. Nessus, Nikto, portscanning, etc.

  • shellcode -- signatures for remote shellcode detection.

  • smtp - signatures for attacks, exploits, and vulnerabilities regarding SMTP.

  • snmp - signatures for attacks, exploits, and vulnerabilities regarding SNMP.

  • sql - signatures for attacks, exploits, and vulnerabilities regarding SQL.

  • telnet - signatures for attacks and vulnerabilities regarding the TELNET service.

  • tftp - signatures for attacks and vulnerabilities regarding the TFTP service.

  • tor -- IP based rules for the identification of traffic to and from TOR exit nodes.

  • trojan -- malicious software that has clear criminal intent. Signatures detect malicious software that is in transit, active, infecting, attacking, updating.

  • user_agents -- user agent identification and detection.

  • voip - signatures for attacks and vulnerabilities regarding the VOIP environment. SIP, h.323, RTP, etc.

  • web_client -- signatures for web client side attacks and vulnerabilities.

  • web_server -- signatures for attacks and vulnerabilities against web servers.

  • web_specific_apps -- signatures for very specific web applications.

  • worm -- traffic indicative of network based worm activity.

Classtype

Classtype is group of signatures based on the type of attack class. Supported the following classtypes:

  • attempted-admin - attempted administrator privilege gain.

  • attempted-dos - attempted denial of service.

  • attempted-recon - attempted information leak.

  • attempted-user - attempted user privilege gain.

  • bad-unknown - potentially bad traffic.

  • default-login-attempt - attempt to login by a default username and password.

  • denial-of-service - detection of a denial of service attack.

  • misc-activity - miscellaneous activity

  • misc-attack - miscellaneous attack

  • network-scan - detection of a network scan

  • non-standard-protocol - detection of a non-standard protocol or event

  • not-suspicious - not suspicious traffic

  • policy-violation - potential corporate privacy violation

  • protocol-command-decode - generic protocol command decode

  • rpc-portmap-decode - decode of an rpc query

  • shellcode-detect - executable code was detected

  • string-detect - a suspicious string was detected

  • successful-admin - successful administrator privilege gain

  • successful-recon-largescale - large scale information leak

  • successful-recon-limited - information leak

  • successful-user - successful user privilege gain

  • suspicious-filename-detect - a suspicious filename was detected

  • suspicious-login - an attempted login using a suspicious username was detected

  • system-call-detect - a system call was detected

  • trojan-activity - a network trojan was detected

  • unsuccessful-user - unsuccessful user privilege gain

    web-application-activity - access to a potentially vulnerable web application

  • web-application-attack - web application attack

When adding signatures to a IPS profile, administrators can use flexible filters, e.g. select only signature with a very high risk that use TCP protocol in the 'botcc' category across all classes.

IPS rules define a traffic to which a IPS profile will be applied and an action that the IPS module must perform in response to such signatures.

Important! Rules are applied from top to bottom in the same order as they are displayed in the console. The system always applies only the first rule for which all criteria are met. This means that the most specific rules must be in the upper part of the list, while the broader rules must be in the bottom. If you want to change the order of rules, use the Up/Down buttons.

Important! The rule will be applied only when all its specific conditions are met. The Negate checkbox makes the condition opposite to the initial condition, i.e. corresponds to logical negation (NOT).

Important! If no rules have been created, then IPS will not work.

To set up the IPS rules, click Add in the Security policies--> Intrusion prevention section and specify the following fields:

Name

Description

Enabled

Enables or disables a rule.

Name

Rule name.

Description

Description of a rule.

Action

The following options are supported:

  • Pass - do not block the traffic

  • Log - do not block the traffic and record it in the log

  • Drop - block the traffic and record it in the log

Source

A source zone and/or a list of source IP addresses for the traffic.

Destination

A destination zone and/or a list of destination IP addresses for the traffic.

Service

Service type, e.g. HTTP, DNS, etc.

Application

List of applications to which this rule will be applied.

Profiles

The list of IPS profiles that have been created in the previous step.