Intrusion Prevention3: Difference between revisions

From Edge Threat Management Wiki - Arista
Jump to navigationJump to search
No edit summary
(Blanked the page)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[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>


{| 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.
{{ServiceAppScreenshot|intrusion-prevention|status}}
=== 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|Rules documentation]] describes how rules generally work and how they are configured.  The major difference for Intrusion Prevention is the Conditions List.
{{AppScreenshot|intrusion-prevention|rules}}
==== 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.
[[Image:Rule_conditions.png|frame|center|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.
{| border="0" cellpadding="2" font="sans-serif"
|+
! 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 [[#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 ==
{{:Intrusion Prevention Reports}}
== All Events ==
== Related Topics ==
[http://en.wikipedia.org/wiki/Intrusion_prevention_system Intrusion Prevention Systems]
[https://suricata.readthedocs.io/en/suricata-3.2.1/rules/index.html Suricata - Writing Suricata Signatures]
== Intrusion Prevention FAQs ==
{{:Intrusion Prevention FAQs}}

Latest revision as of 20:57, 13 November 2018