Difference between revisions of "Rules"

From UntangleWiki
Jump to: navigation, search
Line 1: Line 1:
= Rules =
+
[[Category:Applications]]
 +
<span style="display:none" class="helpSource intrusion_prevention">Intrusion_Prevention</span>
 +
<span style="display:none" class="helpSource intrusion_prevention_status">Intrusion_Prevention#Status</span>
 +
<span style="display:none" class="helpSource intrusion_prevention_rules">Intrusion_Prevention#Rules</span>
 +
<span style="display:none" class="helpSource intrusion_prevention_variables">Intrusion_Prevention#Variables</span>
 +
<span style="display:none" class="helpSource intrusion_prevention_event_log">Intrusion_Prevention#Event_Log</span>
  
Rules are used frequently in Untangle and many other firewalls. Rules are very powerful, but can sometimes be difficult to configure. This documentation describes how rules work and gives some basic examples and some common mistakes to avoid. Many applications use rules like [[Firewall]], [[Captive Portal]], [[Application Control]], [[Bandwidth Control]], etc. All of these rules essentially share the same logic.
+
{| width='100%'
 +
|-
 +
| align="center" | [[Image:IntrusionPrevention.png|128px]] &nbsp; &nbsp; '''Intrusion Prevention'''
 +
| align="center" |
 +
{|
 +
|-
 +
| Other Links:
 +
|-
 +
|[http://www.untangle.com/store/intrusion-prevention.html Intrusion Prevention Description Page]
 +
|-
 +
|[http://demo.untangle.com/admin/index.do#service/intrusion-prevention Intrusion Prevention Demo]
 +
|-
 +
|[http://forums.untangle.com/intrusion-prevention/ Intrusion Prevention Forums]
 +
|-
 +
|[[Intrusion Prevention Reports]]
 +
|-
 +
|[[Intrusion Prevention FAQs]]
 +
|}
 +
|}
 +
<br/>
 +
----
 +
 
 +
== About Intrusion Prevention ==
 +
 
 +
Intrusion Prevention is an [http://en.wikipedia.org/wiki/Intrusion_detection_systems Intrusion Detection system] that detects malicious activity on your network.
 +
 
 +
To detect malicious activity, Intrusion Prevention uses ''signatures'', a method that draws upon a database of known attack patterns.
 +
If a network [http://en.wikipedia.org/wiki/Session_%28computer_science%29 session] matches a signature, its enabled ''action'' directs Intrusion Prevention to
 +
''Log'' (records the incident but '''does not stop''' the activity) or ''Block'' (records the incident and '''does stop''' the activity).
 +
 
 +
There is tremendous diversity between networks and it is possible for a signature to correctly identify malicious activity on one network and incorrectly match legitimate traffic on another.
 +
Logging all matching signatures can make it difficult to effectively monitor Intrusion Prevention and blocking can disrupt legitimate traffic causing cause your network to appear to be broken. 
 +
Therefore it is perfectly legitimate for there to be many signatures set as ''disabled'' or not active in Intrusion Prevention.
 +
In fact, it is advised that you use to the ''Recommended'' actions as specified by the signature database providers.
 +
 
 +
The database contains over 26,000 signatures making it difficult to manage signatures directly.
 +
''Rules'' are used to configure groups of signatures on matching various attributes.
 +
A condition can match an attribute such as classtype. For all signatures that match, they are configured in Intrusion Prevention according to the rule action.
 +
Any signature not matched by a rule is Disabled.
 +
A default set of rules based on system memory are enabled by default.
 +
 
 +
The signature database is automatically updated several times a week.  New and updated rules will be configured as determined by rules.
 +
 
 +
All detected activity for enabled signatures is recorded to the Intrusion Prevention ''All Events'' log.  You should review this log on a daily basis.
 +
 
 +
''Note:'' Intrusion Prevention installs but is off by default.
 +
 
 +
''Note:'' Intrusion Prevention can be memory intensive and requires at least 2GB of RAM.  The amount used is a combination of the number of enabled signatures and the amount of traffic that goes through your system.
 +
 
 +
== Settings ==
 +
 
 +
=== Status ===
 +
 
 +
The Status tab shows the following information:
 +
 
 +
* Memory Usage.  The amount of system memory the IPS engine is using compared to your installed system memory.
 +
 
 +
* Metrics.  The number of blocked, logged, and scanned sessions.
 +
 
 +
* Overview.  Signatures and Signature Updates.
 +
** Signatures.  Total number of signatures available and the number set for Log, Block, Disabled.
 +
** Updates.  The last time the signature database was updated and the last time a check was performed.  Database updates do not occur on each check.
  
= Basics =
+
{{ServiceAppScreenshot|intrusion-prevention|status}}
  
Rules are configured by the user to categorize and act upon traffic. For example, [[Firewall]] uses rules to determine whether to block or pass traffic. [[Bandwidth Control]] uses rules to determine how to prioritize a session.
 
  
Rules are evaluated in order from top to bottom against sessions (not packets!). If a rule matches then the action from that rule is performed and no more rules are evaluated. If no matching rule is found the behavior is defined by the application, which is usually doing nothing.
+
=== Rules ===
  
This is similar to other firewalls. Untangle rules are "quick" rules which means the first match is always used. Unlike some other firewalls, Untangle evaluates against sessions, not packets. This means that the "Source Address" will be the initiator of the session and the "Destination Address" will be the server address the client is connecting to, and the same is true for "Source Port" and "Destination Port."
+
Rules allow you to control which signatures are enabled (and their actions) or disabled.
 +
Any signature not matched by a rule is disabled.
  
Each rule has several properties:
+
The [[Rules|Rules documentation]] describes how rules generally work and how they are configured.  The major difference for Intrusion Prevention is the Conditions List.
* An enable checkbox
 
* A name/description
 
* A set of conditions
 
* An action or set of actions
 
  
[[Image:Rule_anatomy.png|frame|center|Rule Anatomy]]
+
{{AppScreenshot|intrusion-prevention|rules}}
  
The enable checkbox determines if the rule is evaluated. If the enable checkbox is not checked, the rule is simply skipped.
+
==== Condition List ====
  
The description is for the user to document what the rule does. It is ''highly'' suggested to give the rule a meaningful name. Trying to troubleshoot a set of rules all named "[no description]" can be extremely difficult.
+
Conditions define which signatures will match the rule. If and only if all of the conditions match, the rule is considered a match.  
  
The set of conditions is the description of the traffic that should match the rule. If ''all'' of the conditions are true for the given session then the rules matches. This is discussed in more details in the next section.
+
Conditions can be compared in one of two ways:
  
The action or set of actions configures what action is performed if the rule matches. This is dependent on the application. For example, in [[Firewall]] it determines whether to block or pass the session and additionally if it should be flagged.
 
  
= Conditions =
 
  
Conditions define which sessions will match the rule. If and only if all of the conditions match, the rule is considered a match.
+
can also be inverted by selecting "is NOT" in the dropdown, effectively inverting when it matches. ''Destination Port'' "is NOT" "80" matches on all ports except port 80.
Conditions can also be inverted by selecting "is NOT" in the dropdown, effectively inverting when it matches. ''Destination Port'' "is NOT" "80" matches on all ports except port 80.
 
  
 
Lets take a simple example: We want to block TCP traffic to port 80 on a server. There is a web service running on that server that you don't want to allow access to. First, create a rule and check the ''enable'' checkbox and give it a reasonably descriptive name like "blocking TCP port 80 to serverX." Now you will need to add some conditions that match only the traffic you want to block.
 
Lets take a simple example: We want to block TCP traffic to port 80 on a server. There is a web service running on that server that you don't want to allow access to. First, create a rule and check the ''enable'' checkbox and give it a reasonably descriptive name like "blocking TCP port 80 to serverX." Now you will need to add some conditions that match only the traffic you want to block.
Line 50: Line 109:
 
* Reliability - The ''Reliability'' is a "reliability" of that condition. ''True'' means it is 100% reliable. ''False'' means it is 99% or less reliable. For example, some conditions, like ''Destination Port'', are always known and thus matching on ''Destination Port'' is 100% reliable. Other conditions, like ''Client Hostname'', only match if the hostname for the client hostname is known. Hostname is determined through many ways, including DNS and DHCP. If all of these methods fail then it is entirely possible that the hostname of a server is "foo" but Untangle has not been able to determine this and as such a ''Client Hostname'' is "foo" condition will not match. This column is there purely as a warning that users in these cases must be aware of when conditions might deliver false negatives.  
 
* Reliability - The ''Reliability'' is a "reliability" of that condition. ''True'' means it is 100% reliable. ''False'' means it is 99% or less reliable. For example, some conditions, like ''Destination Port'', are always known and thus matching on ''Destination Port'' is 100% reliable. Other conditions, like ''Client Hostname'', only match if the hostname for the client hostname is known. Hostname is determined through many ways, including DNS and DHCP. If all of these methods fail then it is entirely possible that the hostname of a server is "foo" but Untangle has not been able to determine this and as such a ''Client Hostname'' is "foo" condition will not match. This column is there purely as a warning that users in these cases must be aware of when conditions might deliver false negatives.  
  
== Condition List ==
 
  
{| border="1" cellpadding="2"
+
{| border="1" cellpadding="2" font="sans-serif" style="border-collapse: collapse;"
 
|+
 
|+
! Name !! Syntax !! Function !! Availability !! Reliability
+
! style="text-align: left" |  Name  
 +
! style="text-align: left" | Syntax  
 +
! style="text-align: left" | Function
 
|-  
 
|-  
| style="width: 20%;"|Destination Address
+
| Signature identifier
| [[IP Matcher]]
+
| Numeric
| Matches if value matches the Destination/Server Address of the session. (after NAT/port forwarding)
+
| Matches if value matches the exact or partial signature identifier.
| all
 
| True
 
 
|-  
 
|-  
| Destination Port
+
| Group identifier
| [[Int Matcher]]
+
| Numeric
| Matches if value matches the Destination/Server Port of the session. (after NAT/port forwarding)
+
| Matches if value matches the exact or partial group identifier.
| all
+
|-
| True
+
| Category
 +
| checkbox
 +
| Matches if value is in one of the checked categories.
 +
|-
 +
| Classtype
 +
| checkbox
 +
| Matches if value is in one of the checked classtypes.
 
|-  
 
|-  
| Destination Interface
+
| Message
| checkboxes
+
| Text
| Matches if value matches the Destination/Server Interface of the session. (after routing/port forwarding)
+
| Matches if value matches the exact or partial signature subject message.
| all
 
| True
 
 
|-  
 
|-  
| Destined Local
+
| Protocol
| boolean
+
| checkbox
| Matches if the session is destined to one of Untangle's IP addresses.
+
| Matches if value is in one of the checked protocols.
| all
 
| True
 
 
|-  
 
|-  
 
| Source Address
 
| Source Address
| [[IP Matcher]]
+
| Text
| Matches if value matches the Source/Client Address of the session. (before NAT/port forwarding)
+
| Matches if value matches the exact or partial source address.
| all
 
| True
 
 
|-  
 
|-  
 
| Source Port
 
| Source Port
| [[Port Matcher]]
+
| Text
| Matches if value matches the Source/Client Port of the session. (before NAT/port forwarding)
+
| Matches if value matches the exact or partial source port.
| hidden
 
| True
 
 
|-  
 
|-  
| Source Interface
+
| Destination Address
| checkboxes
+
| Text
| Matches if value matches the Source/Client Interface of the session. (before routing/port forwarding)
+
| Matches if value matches the exact or partial destination address.
| all
 
| True
 
 
|-  
 
|-  
| Protocol
+
| Destination Port
| checkboxes
+
| Text
| Matches if value matches the Protocol of the session.
+
| Matches if value matches the exact or partial destination port.
| all
 
| True
 
|-
 
| Tagged
 
| [[Glob Matcher]]
 
| Matches if session is tagged with matching tag
 
| all
 
| True
 
|-
 
| Client Tagged
 
| [[Glob Matcher]]
 
| Matches if client of the session is tagged with matching tag
 
| all
 
| True
 
|-
 
| Server Tagged
 
| [[Glob Matcher]]
 
| Matches if server of the session is tagged with matching tag
 
| all
 
| True
 
|-
 
| Username
 
| [[User Matcher]]
 
| Matches if value matches the username associated with the Client IP in the Host table.
 
| all
 
| False
 
|-
 
| Host Hostname
 
| [[Glob Matcher]]
 
| Matches if value matches the hostname associated with the Local Address in the Host table.
 
| all
 
| False
 
|-
 
| Client Hostname
 
| [[Glob Matcher]]
 
| Matches if value matches the hostname associated with the Client IP in the Host table.
 
| all
 
| False
 
|-
 
| Server Hostname
 
| [[Glob Matcher]]
 
| Matches if value matches the hostname associated with the Server IP in the Host table.
 
| all
 
| False
 
|-
 
| Client MAC Address
 
| [[Glob Matcher]]
 
| Matches if value matches the MAC address associated with the Client IP in the ARP table.
 
| all
 
| False
 
|-
 
| Server MAC Address
 
| [[Glob Matcher]]
 
| Matches if value matches the MAC address associated with the Server IP in the ARP table.
 
| all
 
| False
 
|-
 
| Client MAC Vendor
 
| [[Glob Matcher]]
 
| Matches if value matches the device manufacturer. This is identified using the Client IP's MAC address in the ARP table and [https://standards.ieee.org/develop/regauth/oui/public.html OUI Lookup].
 
| all
 
| False
 
|-
 
| Server MAC Vendor
 
| [[Glob Matcher]]
 
| Matches if value matches the device manufacturer. This is identified using the Server IP's MAC address in the ARP table and [https://standards.ieee.org/develop/regauth/oui/public.html OUI Lookup].
 
| all
 
| False
 
|-
 
| Host has no Quota
 
| boolean
 
| Matches if the local address has no quota
 
| all
 
| True
 
|-
 
| User has no Quota
 
| boolean
 
| Matches if the username has no quota
 
| all
 
| True
 
|-
 
| Client has no Quota
 
| boolean
 
| Matches if the client has no quota
 
| hidden
 
| True
 
|-
 
| Server has no Quota
 
| boolean
 
| Matches if the server has no quota
 
| hidden
 
| True
 
|-
 
| Host has Exceeded Quota
 
| boolean
 
| Matches if the local address has exceeded their quota
 
| all
 
| True
 
|-
 
| User has Exceeded Quota
 
| boolean
 
| Matches if the user has exceeded their quota
 
| all
 
| True
 
|-
 
| Client has Exceeded Quota
 
| boolean
 
| Matches if the client has exceeded their quota
 
| hidden
 
| True
 
|-
 
| Server has Exceeded Quota
 
| boolean
 
| Matches if the server has exceeded their quota
 
| hidden
 
| True
 
|-
 
| Host Quota Attainment
 
| [[Int Matcher]]
 
| Matches the local address quota used to quota size ratio (">1" means over quota, ">.5" means over 50% used, etc)
 
| all
 
| True
 
|-
 
| User Quota Attainment
 
| [[Int Matcher]]
 
| Matches the username quota used to quota size ratio (">1" means over quota, ">.5" means over 50% used, etc)
 
| all
 
| True
 
|-
 
| Client Quota Attainment
 
| [[Int Matcher]]
 
| Matches the client quota used to quota size ratio (">1" means over quota, ">.5" means over 50% used, etc)
 
| hidden
 
| True
 
|-
 
| Server Quota Attainment
 
| [[Int Matcher]]
 
| Matches the server quota used to quota size ratio (">1" means over quota, ">.5" means over 50% used. etc)
 
| hidden
 
| True
 
|-
 
| HTTP: Hostname
 
| [[Glob Matcher]]
 
| Matches if the value matches the hostname specified in the HTTP session
 
| deep sessions
 
| False
 
|-
 
| HTTP: Referer
 
| [[Glob Matcher]]
 
| Matches if the value matches the referer string specified in the HTTP header
 
| deep sessions
 
| False
 
|-
 
| HTTP: URI
 
| [[Glob Matcher]]
 
| Matches if the value matches the latest URI specified in the HTTP session
 
| deep sessions
 
| False
 
|-
 
| HTTP: URL
 
| [[URL Matcher]]
 
| Matches if the value matches the latest URL (hostname+URI) specified in the HTTP session
 
| deep sessions
 
| False
 
|-
 
| HTTP: Content Type
 
| [[Glob Matcher]]
 
| Matches the content-type of the latest content in the HTTP session
 
| deep sessions
 
| False
 
|-
 
| HTTP: Content Length
 
| [[Int Matcher]]
 
| Matches if [[Int Matcher]] matches the content length specified in the latest HTTP response
 
| deep sessions
 
| False
 
|-
 
| HTTP: Request Method
 
| [[Glob Matcher]]
 
| Matches if the value matches the HTTP request method of the requested URL. Standard request methods include GET, POST, HEAD, OPTIONS, PUT, DELETE, TRACE, and CONNECT.
 
| deep sessions
 
| False
 
|-
 
| HTTP: Request File Path
 
| [[Glob Matcher]]
 
| Matches if the value matches the entire file path of the requested URL. This is everything including and after the first slash character following the host name or address. (e.g. /some/location/mypage.html)
 
| deep sessions
 
| False
 
|-
 
| HTTP: Request File Name
 
| [[Glob Matcher]]
 
| Matches if the value matches the file name of the requested URL. This is everything after the final slash character of the request. (e.g. mypage.html)
 
| deep sessions
 
| False
 
|-
 
| HTTP: Request File Extension
 
| [[Glob Matcher]]
 
| Matches if the value matches the file extension of the requested URL. This is everything after following the dot after the final slash character of the request. (e.g. html)
 
| deep sessions
 
| False
 
|-
 
| HTTP: Response Content Type
 
| [[Glob Matcher]]
 
| Matches if the value matches the content or MIME type reported in the server response.
 
| deep sessions
 
| False
 
|-
 
| HTTP: Response File Name
 
| [[Glob Matcher]]
 
| Matches if the value matches the file name returned in the server response.
 
| deep sessions
 
| False
 
|-
 
| HTTP: Response File Extension
 
| [[Glob Matcher]]
 
| Matches if the value matches the file extension returned in the server response. This is everything after (but not including) the final dot of the file name.
 
| deep sessions
 
| False
 
|-
 
| HTTP: Client User Agent
 
| [[Glob Matcher]]
 
| Matches if the value matches the User Agent string for the client in the Host table
 
| all
 
| False
 
|-
 
| Application Control: Application
 
| [[Glob Matcher]]
 
| Matches if the value matches the Application determined by Application Control
 
| deep sessions
 
| False
 
|-
 
| Application Control: Category
 
| [[Glob Matcher]]
 
| Matches if the value matches the Category of the Application determined by Application Control
 
| deep sessions
 
| False
 
|-
 
| Application Control: Protochain
 
| [[Glob Matcher]]
 
| Matches if the value matches the Protochain determined by Application Control
 
| deep sessions
 
| False
 
|-
 
| Application Control: Detail
 
| [[Glob Matcher]]
 
| Matches if the value matches the Detail of the Application determined by Application Control
 
| deep sessions
 
| False
 
|-
 
| Application Control: Confidence
 
| [[Int Matcher]]
 
| Matches if [[Int Matcher]] matches the confidence rating determined by Application Control
 
| deep sessions
 
| False
 
|-
 
| Application Control: Productivity
 
| [[Int Matcher]]
 
| Matches if [[Int Matcher]] matches the productivity rating determined by Application Control
 
| deep sessions
 
| False
 
|-
 
| Application Control: Risk
 
| [[Int Matcher]]
 
| Matches if [[Int Matcher]] matches the risk rating determined by Application Control
 
| deep sessions
 
| False
 
 
|-  
 
|-  
| Application Control Lite: Signature
+
| Signature
| [[Glob Matcher]]
+
| Text
| Matches if the value matches the Signature determined by Application Control Lite
+
| Matches if value matches the exact or any part of the entire signature.
| deep sessions
 
| False
 
 
|-  
 
|-  
| Application Control Lite: Category
+
| Custom
| [[Glob Matcher]]
+
| Boolean
| Matches if the value matches the Category of the Signature determined by Application Control Lite
+
| Matches if value is a custom signature.
| deep sessions
 
| False
 
 
|-  
 
|-  
| Application Control Lite: Description
+
| Recommended Action
| [[Glob Matcher]]
+
| Select
| Matches if the value matches the Description of the Signature determined by Application Control Lite
+
| Matches if value is a signature's recommended action.
| deep sessions
 
| False
 
|-
 
| Web Filter: Category
 
| [[Glob Matcher]]
 
| Matches if the value matches the Category determined by Web Filter
 
| deep sessions
 
| False
 
|-
 
| Web Filter: Category Description
 
| [[Glob Matcher]]
 
| Matches if the value matches the Description of the Category determined by Web Filter
 
| deep sessions
 
| False
 
|-
 
| Web Filter: Site is Flagged
 
| boolean
 
| Matches if the latest request in this session was flagged by Web Filter
 
| deep sessions
 
| False
 
|-
 
| Directory Connector: User in Group
 
| [[Group Matcher]]
 
| Matches if the username associated with the client in the Host Table is in the specified group(s)
 
| all
 
| False
 
|-
 
| SSL Inspector: SNI Host Name
 
| [[Glob Matcher]]
 
| Matches if the value matches the Server Name Indication (SNI) host name included by the client in the initial session request.
 
| deep sessions
 
| False
 
|-
 
| SSL Inspector: Certificate Subject
 
| [[Glob Matcher]]
 
| Matches if the value matches the Subject DN in the SSL certificate received from the external server.
 
| all
 
| False
 
|-
 
| SSL Inspector: Certificate Issuer
 
| [[Glob Matcher]]
 
| Matches if the value matches the Issuer DN in the SSL certificate received from the external server.
 
| all
 
| False
 
|-
 
| Time of Day
 
| [[Time of Day Matcher]]
 
| Matches times of day.
 
| all
 
| True
 
|-
 
| Day of Week
 
| [[Day of Week Matcher]]
 
| Matches days of the week.
 
| all
 
| True
 
|-
 
| Remote Host Country
 
| [[Glob Matcher]]
 
| Matches if value matches the country associated with the remote IP.
 
| all
 
| False
 
|-
 
| Client Country
 
| [[Glob Matcher]]
 
| Matches if value matches the country associated with the Client IP.
 
| all
 
| False
 
|-
 
| Server Country
 
| [[Glob Matcher]]
 
| Matches if value matches the country associated with the Server IP.
 
| all
 
| False
 
 
|-  
 
|-  
 +
| System Memory
 +
| Numeric
 +
| Matches if system memory matches this value.
 
|}
 
|}
  
= Order =
 
  
As discussed above, the order of rules is very important. Often users want to do very complex tasks that can be difficult or impossible with a single rule.
+
* Recommended
In these cases, multiple rules is useful. For example, assume you want to use Firewall to block all traffic to a server (1.2.3.4) except port 80 traffic or from the admin IP (192.168.1.100) to RDP (port 3389).
+
* Enable Log
 +
* Enable Block if Recommended is Log
 +
* Emable Block
 +
* Disable
 +
 
 +
 
 +
 
 +
 
 +
Simply uncheck '''Block''' (and '''Log''' if you wish) and the the traffic will no longer be blocked.
 +
 
 +
 
 +
 
 +
 
 +
=== Signatures ===
 +
 
 +
Intrusion Prevention provides a list of [[#Learning More About Signature ID Rules|signatures]] that you can have Untangle '''Log''' or '''Block''' when traffic matches them. The rules are grouped by classtype and can be searched using the search field at the bottom of the page.  
 +
 
 +
In most cases, you do not need to change the recommended settings. You should only need to disable a signature if that rule blocks traffic from a unique software application that you must use. CREATE RULES.
 +
 
 +
The signatures are automatically updated using the latest Suricata signatures.
 +
 
 +
*SID: The signature's identifier.
 +
*Classtype: Suricata classtype (grouping) of the signature.
 +
*Category: Suricata category (grouping) for the signature.
 +
*Msg: Name of the signature.
 +
*Reference: Links to reference information on the attack the signature will detect (if available).
 +
*Log/Block: Enable these to log or block traffic matching the signature.
 +
 
 +
*Edit: Modify a a custom signature from the system.
 +
*Copy: Copy a signature.  Copied signatures become part of the custom set.
 +
*Delete: Delete a custom signature from the system.
 +
 
 +
Using the Add button, you can also add your own custom signatures to the system. This should only be attempted by advanced users with a strong knowledge of Suricata signature creation. Adding invalid or poorly written rules will negatively impact network performance.
 +
 
 +
''Signatures'' match malicious network traffic patterns and perform actions such as logging without affecting the session or blocking the session.
 +
 
 +
 
 +
{{AppScreenshot|intrusion-prevention|signatures}}
 +
 
 +
=== Variables ===
 +
 
 +
This tab provides administrators access to Suricata variables. These variables are used in rules to specify criteria for the source and destination of a packet.  
 +
 
 +
Suricata's most important variable is $HOME_NET. $HOME_NET defines the network or networks you are trying to protect - it is computer automatically based on your network configuration - it includes all local networks (including aliases).
 +
 
 +
Using the Add button, custom variables can be added. Adding variables may be used by users adding their own rules.This should only be attempted by advanced users with a strong knowledge of Suricata signature creation.
 +
 
 +
{{AppScreenshot|intrusion-prevention|variables}}
 +
 
 +
 
 +
== Updates ==
 +
 
 +
Signatures are automatically updated every night.  Any rule modifications the administrator has made will remain.  New signatures are added with recommended actions.
 +
 
 +
== Reports ==
  
Doing this in one rule would be difficult (actually impossible in this case), but it is quite easy using several rules:
+
{{:Intrusion Prevention Reports}}
First, create a rule to just block all traffic to the server IP, 1.2.3.4. Above that rule create a rule that passes all traffic from the admin IP, 192.168.1.100, to the server IP where ''Destination Port'' == "3389", and another rule that passes all traffic to 1.2.3.4 with ''Destination Port'' == "80."
 
This set of three rules does exactly what we describe above and effects no other traffic.
 
  
[[Image:Rule_order.png|760px|center|Rule Anatomy]]
 
  
= Common Mistakes =
+
== All Events ==
  
This is a list of common mistakes to avoid.
 
  
== Conditions must ALL match ==
 
  
In order for a rule to match, ALL conditions must match. In some cases you may want to add a rule that just passes all traffic to and from an IP.
+
== Related Topics ==
Users sometimes will create a pass rule with two conditions:
 
* ''Destination Address'' is "1.2.3.4"
 
* ''Source Address'' is "1.2.3.4"
 
  
This rule will never match anything because it will only match traffic where the destination address is 1.2.3.4 AND the source address is 1.2.3.4 (a session destined to itself). If you want to match when the destination address is 1.2.3.4 OR the source address is 1.2.3.4, then you must create two separate rules, one for the destination address and one for the source address.
+
[http://en.wikipedia.org/wiki/Intrusion_prevention_system Intrusion Prevention Systems]
  
== Rule Order ==
+
[https://suricata.readthedocs.io/en/suricata-3.2.1/rules/index.html Suricata - Writing Suricata Signatures]
  
Occasionally, you will add a rule and not understand why it is not working as intended. Often we find that there was a rule above that was matching the session before the desired rule. For example, just adding a rule to the bottom often isn't sufficient, you must find the appropriate place in your ruleset to place the new rule.
+
== Intrusion Prevention FAQs ==
  
To do so simply logically evaluate the rules in your head starting at the top to find the appropriate place for your rule. Also use the event log to run several tests to see how the session was handled in the event log and adjust your ruleset accordingly.
+
{{:Intrusion Prevention FAQs}}

Revision as of 19:57, 13 November 2018

IntrusionPrevention.png     Intrusion Prevention
Other Links:
Intrusion Prevention Description Page
Intrusion Prevention Demo
Intrusion Prevention Forums
Intrusion Prevention Reports
Intrusion Prevention FAQs



About Intrusion Prevention

Intrusion Prevention is an Intrusion Detection system that detects malicious activity on your network.

To detect malicious activity, Intrusion Prevention uses signatures, a method that draws upon a database of known attack patterns. If a network session matches a signature, its enabled action directs Intrusion Prevention to Log (records the incident but does not stop the activity) or Block (records the incident and does stop the activity).

There is tremendous diversity between networks and it is possible for a signature to correctly identify malicious activity on one network and incorrectly match legitimate traffic on another. Logging all matching signatures can make it difficult to effectively monitor Intrusion Prevention and blocking can disrupt legitimate traffic causing cause your network to appear to be broken. Therefore it is perfectly legitimate for there to be many signatures set as disabled or not active in Intrusion Prevention. In fact, it is advised that you use to the Recommended actions as specified by the signature database providers.

The database contains over 26,000 signatures making it difficult to manage signatures directly. Rules are used to configure groups of signatures on matching various attributes. A condition can match an attribute such as classtype. For all signatures that match, they are configured in Intrusion Prevention according to the rule action. Any signature not matched by a rule is Disabled. A default set of rules based on system memory are enabled by default.

The signature database is automatically updated several times a week. New and updated rules will be configured as determined by rules.

All detected activity for enabled signatures is recorded to the Intrusion Prevention All Events log. You should review this log on a daily basis.

Note: Intrusion Prevention installs but is off by default.

Note: Intrusion Prevention can be memory intensive and requires at least 2GB of RAM. The amount used is a combination of the number of enabled signatures and the amount of traffic that goes through your system.

Settings

Status

The Status tab shows the following information:

  • Memory Usage. The amount of system memory the IPS engine is using compared to your installed system memory.
  • Metrics. The number of blocked, logged, and scanned sessions.
  • Overview. Signatures and Signature Updates.
    • Signatures. Total number of signatures available and the number set for Log, Block, Disabled.
    • Updates. The last time the signature database was updated and the last time a check was performed. Database updates do not occur on each check.


Rules

Rules allow you to control which signatures are enabled (and their actions) or disabled. Any signature not matched by a rule is disabled.

The Rules documentation describes how rules generally work and how they are configured. The major difference for Intrusion Prevention is the Conditions List.

Condition List

Conditions define which signatures will match the rule. If and only if all of the conditions match, the rule is considered a match.

Conditions can be compared in one of two ways:


can also be inverted by selecting "is NOT" in the dropdown, effectively inverting when it matches. Destination Port "is NOT" "80" matches on all ports except port 80.

Lets take a simple example: We want to block TCP traffic to port 80 on a server. There is a web service running on that server that you don't want to allow access to. First, create a rule and check the enable checkbox and give it a reasonably descriptive name like "blocking TCP port 80 to serverX." Now you will need to add some conditions that match only the traffic you want to block. So in this example will will add:

  • Protocol is TCP
  • Destination Address is 1.2.3.4 (The IP address of the server)
  • Destination Port is 80

Finally, set the action to block and flag, and click "Done" and "Apply". Since all conditions must be true this rule will block TCP traffic to 1.2.3.4 port 80 only and nothing else.

Rule Conditions

There are many conditions available to carefully define precise sets of traffic. The following Table defines the list of conditions.

Each condition has several properties:

  • Name - The Name of the condition
  • Syntax - The accepted Syntax of the condition. If editing through the UI, some conditions have custom editors to help you craft conditions, others are just a text field.
  • Availability - The Availability is the availability of that matcher at various times. Some conditions, like Destination Address, are always known and can always be used to match. Other conditions, like Application Control: Application, are only known after the session is created and some data flows and Application Control is able to identify the application. These type conditions are 'deep session' conditions because they are not able to be evaluated at session creation time, only after some data flows. As such they are not available in rules that are evaluated at session creation time, like Firewall and Captive Portal.
  • Reliability - The Reliability is a "reliability" of that condition. True means it is 100% reliable. False means it is 99% or less reliable. For example, some conditions, like Destination Port, are always known and thus matching on Destination Port is 100% reliable. Other conditions, like Client Hostname, only match if the hostname for the client hostname is known. Hostname is determined through many ways, including DNS and DHCP. If all of these methods fail then it is entirely possible that the hostname of a server is "foo" but Untangle has not been able to determine this and as such a Client Hostname is "foo" condition will not match. This column is there purely as a warning that users in these cases must be aware of when conditions might deliver false negatives.


Name Syntax Function
Signature identifier Numeric Matches if value matches the exact or partial signature identifier.
Group identifier Numeric Matches if value matches the exact or partial group identifier.
Category checkbox Matches if value is in one of the checked categories.
Classtype checkbox Matches if value is in one of the checked classtypes.
Message Text Matches if value matches the exact or partial signature subject message.
Protocol checkbox Matches if value is in one of the checked protocols.
Source Address Text Matches if value matches the exact or partial source address.
Source Port Text Matches if value matches the exact or partial source port.
Destination Address Text Matches if value matches the exact or partial destination address.
Destination Port Text Matches if value matches the exact or partial destination port.
Signature Text Matches if value matches the exact or any part of the entire signature.
Custom Boolean Matches if value is a custom signature.
Recommended Action Select Matches if value is a signature's recommended action.
System Memory Numeric Matches if system memory matches this value.


  • Recommended
  • Enable Log
  • Enable Block if Recommended is Log
  • Emable Block
  • Disable



Simply uncheck Block (and Log if you wish) and the the traffic will no longer be blocked.



Signatures

Intrusion Prevention provides a list of signatures that you can have Untangle Log or Block when traffic matches them. The rules are grouped by classtype and can be searched using the search field at the bottom of the page.

In most cases, you do not need to change the recommended settings. You should only need to disable a signature if that rule blocks traffic from a unique software application that you must use. CREATE RULES.

The signatures are automatically updated using the latest Suricata signatures.

  • SID: The signature's identifier.
  • Classtype: Suricata classtype (grouping) of the signature.
  • Category: Suricata category (grouping) for the signature.
  • Msg: Name of the signature.
  • Reference: Links to reference information on the attack the signature will detect (if available).
  • Log/Block: Enable these to log or block traffic matching the signature.
  • Edit: Modify a a custom signature from the system.
  • Copy: Copy a signature. Copied signatures become part of the custom set.
  • Delete: Delete a custom signature from the system.

Using the Add button, you can also add your own custom signatures to the system. This should only be attempted by advanced users with a strong knowledge of Suricata signature creation. Adding invalid or poorly written rules will negatively impact network performance.

Signatures match malicious network traffic patterns and perform actions such as logging without affecting the session or blocking the session.


Variables

This tab provides administrators access to Suricata variables. These variables are used in rules to specify criteria for the source and destination of a packet.

Suricata's most important variable is $HOME_NET. $HOME_NET defines the network or networks you are trying to protect - it is computer automatically based on your network configuration - it includes all local networks (including aliases).

Using the Add button, custom variables can be added. Adding variables may be used by users adding their own rules.This should only be attempted by advanced users with a strong knowledge of Suricata signature creation.


Updates

Signatures are automatically updated every night. Any rule modifications the administrator has made will remain. New signatures are added with recommended actions.

Reports

The Reports tab provides a view of all reports and events for all traffic handled by Intrusion Prevention.

Reports

This applications reports can be accessed via the Reports tab at the top or the Reports tab within the settings. All pre-defined reports will be listed along with any custom reports that have been created.

Reports can be searched and further defined using the time selectors and the Conditions window at the bottom of the page. The data used in the report can be obtained on the Current Data window on the right.

Pre-defined report queries:

Report Entry Description
Intrusion Prevention Summary A summary of intrusion detection and prevention actions.
Intrusion Detection (all) The amount of detected and blocked intrusions over time.
Intrusion Detection (logged) The amount of detected intrusions over time.
Intrusion Detection (blocked) The amount of blocked intrusions over time.
Top Rules (all) The number of intrusions detevted by rule.
Top Rules (logged) The number of intrusions logged by rule.
Top Rules (blocked) The number of intrusions blocked by rule.
Top Signatures (all) The number of intrusions detected by signature.
Top Signatures (logged) The number of intrusions logged by signature.
Top Signatures (blocked) The number of intrusions blocked by signature.
Top Classtypes (all) The number of intrusions detected by classtype.
Top Classtypes (logged) The number of intrusions logged by classtype.
Top Classtypes (blocked) The number of intrusions blocked by classtype.
Top Categories (all) The number of intrusions detected by category.
Top Categories (logged) The number of intrusions logged by category.
Top Categories (blocked) The number of intrusions blocked by category.
Top Source IP Addresses (all) The number of intrusions detected by source IP address.
Top Source IP Addresses (logged) The number of intrusions logged by source IP address.
Top Source IP Addresses (blocked) The number of intrusions blocked by source IP address.
Top Source Ports (all) The number of intrusions detected by source port.
Top Source Ports (logged) The number of intrusions logged by source port.
Top Source Ports (blocked) The number of intrusions blocked by source port.
Top Destination IP Addresses (all) The number of intrusions detected by destination IP address.
Top Destination IP Addresses (logged) The number of intrusions logged by destination IP address.
Top Destination IP Addresses (blocked) The number of intrusions blocked by destination IP address.
Top Destination Ports (all) The number of intrusions detected by destination port.
Top Destination Ports (logged) The number of intrusions logged by destination port.
Top Destination Ports (blocked) The number of intrusions blocked by destination port.
Top Protocols (all) The number of intrusions detected by protocol.
Top Protocols (logged) The number of intrusions logged by protocol.
Top Protocols (blocked) The number of intrusions blocked by protocol.
All Events All sessions scanned by Intrusion Prevention.
Logged Events All sessions matching Intrusion Prevention signatures and logged.
Blocked Events All sessions matching Intrusion Prevention signatures and blocked.


The tables queried to render these reports:



All Events

Related Topics

Intrusion Prevention Systems

Suricata - Writing Suricata Signatures

Intrusion Prevention FAQs

Is Intrusion Prevention based on an open source project?

Yes, Intrusion Prevention is based on Suricata.

Why is there no reference information for a specific signature?

If there is no information link available for a specific signautre, you can try searching the signature ID at Suricata Rules for more info.

Why aren't most of Intrusion Prevention's signatures blocked by default?

Because many signatures can block legitimate traffic in addition to malicious exploits we don't enable blocking by default.

You're free to change the action of any rule to block signatures as you see fit for your network.

Can Intrusion Prevention rules be configured differently within different policies?

No. Intrusion Prevention applies to all traffic flowing through Untangle so different configurations are not possible.

What is the difference between rule block actions?

Enable Block if Recommended is Log will only enable a signature to Block if its Recommended Action is Log.

Enable Block will unconditionally set all matching signatures to Block.

The difference is that a signature's Recommended Action (almost always either Log or Disabled) is carefully considered by the signature provider. A rule set to Enable Block if Recommended is Log will likely set that smaller and "safer" set of signatures to Block whereas Enable Block will likely set a larger set of signatures with more potential to disrupt legitimate traffic on your network.

How can I exclude network processing for signatures?

Create a variable with the network you wish to exclude in standard CIDR format such as 192.168.1.0/24. If you have multiple networks to exclude, create a comma-separated list surrounded by square brackets such as [192.168.25.1.0/24,10.10.0.0/24].

Next, create a rule to match the signatures you wish to exclude. For Action select Whitelist and then specify the variable you created to either Source or Destination networks.

NOTE: Unlike other Rule actions, the Whitelist action doesn't enable logging/blocking for rules. Signatures affected by Whitelist rules will still be processed by the first matching non-Whitelist Rule.

How do I extend the HOME_NET variable?

IPS attempts to determine the appropriate HOME_NET based on your network configuration but if a network doesn't appear to be in the list (mouse over the variable), you can either replace the HOME_NET variable value entirely or append to the existing using by leaving the default value and adding a comma separated list of additional CIDR formatted networks such as default,10.10.10.10/32,192.168.2.0/24.