| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
Intrusion Definition
Computer servers can sometimes have vulnerabilities which leave them exposed to attacks carried by network traffic. Worms, trojans and backdoor exploits are examples of such attacks which, if successful, can potentially compromise or take control of a server. A generic term that can be used to describe these server oriented threats are intrusions.Intrusion Detection
Intrusions differ from viruses in that a virus is normally contained in a single file download and this is normally downloaded to a client system. An intrusion manifests itself as a malicious pattern of Internet data aimed at bypassing server security mechanisms. Intrusions are not uncommon and they can constantly evolve as their creation can be automated by the attacker. cOS Core IDP provides an important line of defense against these threats.Intrusion Detection and Prevention (IDP) is a subsystem of cOS Core that is designed to protect against these intrusion attempts. It operates by monitoring network traffic as it passes through the Clavister firewall, searching for patterns that indicate an intrusion is being attempted. Once detected, cOS Core IDP allows steps to be taken to neutralize both the intrusion attempt as well as its source.
Note that an article in the Clavister Knowledge Base also discusses IDP deployment and setup. It may duplicate some points found here but also provides additional information. It can be found at the following link:
https://kb.clavister.com/354856016
IDP Deployment Questions
In order to have an effective and reliable IDP system, the following questions should be considered by the administrator:Which traffic should be analyzed using IDP?
This will decide the source/destination network/interface and service combination that will need to be specified in an IDP Rule.
What should we search for in that traffic?
This will determine which signatures or sets of signatures will need to be specified in the IDP Rule Action objects added to an IDP Rule. Are all signatures in a signature group or subgroup required? Should some specific IDP signatures be excluded to improve throughput? Perhaps only a small number of individual IDP signatures are needed to defend against a small number of known current threats.
Selecting as few IDP signatures as possible is important from a system performance viewpoint. Using an excessive number of IDP signatures will probably impact firewall throughput.
What action should be taken when IDP triggers?
Each IDP Rule Action has an Action property that specifies what to do if a signature triggers. Should the connection be dropped? Should it be allowed but logged?
In addition, should the source IP of the triggering traffic be blacklisted so future traffic from that IP is dropped? How long should the blacklisting last? Should only the triggering protocol be blacklisted? Should existing connections from a blacklisted IP be dropped?
Should a scan limit be set so that scanning does not slow down overall system performance? Depending on the traffic mix, it may be sufficient to only scan the first several kilobytes of each new connection's traffic flow.
IDP Setup and Processing
The following is a list of the IDP setup steps and subsequent IDP processing:An IDP Rule is configured by the administrator which specifies the targeted traffic using a combination of source/destination network/interface and service. This can optionally include a scan limit to improve performance so that only the initial portion of a connection data flow is examined.
Each rule has one or more IDP Rule Action objects added to it as children and these specify the IDP signatures to apply to the targeted traffic and what action to take if a signature triggers.
Matching of the signatures to the targeted traffic is then applied by cOS Core as it streams through the firewall.
If any of the configured IDP signatures trigger, the action specified for those signatures is applied. If a signature is repeated across multiple IDP Rule Action objects, only the action of the first triggering IDP Rule Action will be applied for that signature.
The IDP traffic shaping feature is discussed in depth in Section 11.2, IDP Traffic Shaping.
The Protect action in an IDP Rule Action object includes the option that the particular switch that triggered the action can be deactivated through the Clavister ZoneDefense feature. For more details on how ZoneDefense functions see Section 7.11, ZoneDefense. Note that this feature is only available for switches manufactured by D-Link. At the end of 2021, a critical vulnerability was discovered in the Apache Java logging library Log4j which is widely used by server software. Signatures were immediately added to the cOS Core IDP database to defend against attacks that target this vulnerability. An article in the Clavister Knowledge Base at the following link provides a further description of how IDP was deployed for this particular use case:The Action property of each IDP Rule Action object under an IDP Rule can be set to one of the following values:
This option drops the connection and logs the event and is the default setting. The additional option exists to blacklist the source of the connection or switching on the cOS Core ZoneDefense feature as described below.
Pipe
Constrain the bandwidth coming from the host using a traffic shaping pipe. This option is explained further in Section 11.2, IDP Traffic Shaping.
Audit
Allow the connection to stay open but log the event.
Ignore
Do nothing on a signature match and allow the connection to stay open. This can be useful when excluding individual signatures from a signature group which is specified further down the rule action list. It can also be used with wildcards to exclude a particular type of signature and this is discussed further in Tip: The signature types IDS and POLICY may not be needed.
If a scan limit is enabled, the following should be noted: Sometimes, minimal effect may be seen on traffic throughput when raising the scan limit value, even to the maximum allowed value of 65,535 (64 Kbytes). However, the effect can vary with the traffic mix.
The default scan limit value is 800 bytes.
Minimal effect may be seen on overall system performance when raising the scan limit value, even to the maximum allowed value of 65535 bytes (64K).
The minimum allowed scan limit is 10 bytes but caution should be exercised if reducing the limit below the default of 800 since this can easily render IDP ineffective-
A suggested starting value when increasing the scan limit is 3072 bytes (3K). There will usually only be a negligible performance improvement with limits below this value.
Also note that an example of enabling a scan limit is included in Example 7.8, “Setting up IDP for a Mail Server”.
Configuring IDP signatures is done on the IDP Rule Action objects that are the children of an IDP Rule object. A screenshot of selecting signatures for an IDP Rule Action in the Web Interface is shown below.There is a choice of either entering signatures in the upper text box or selecting them through the signature tree underneath. The tree collects the signatures together into their respective groups. and subgroups.
When a group of signatures is selected in the tree, the equivalent wildcard definition will automatically appear in the box above. Individual signatures cannot be selected through the tree and can only be entered in the text box.
What appears in the upper text box is equivalent to the way signatures are specified when using the CLI.
The structure of the IDP signature hierarchy is explained further in Section 7.8.3, IDP Signatures and Signature Groups.
![[Tip]](images/tip.png) |
Tip: A searchable IDP signature list is available online |
|---|---|
|
All current IDP signatures with their type and groupings are available in an online searchable list at the following link: |
The URI conditions which IDP can detect are the following:
Invalid UTF8
This looks for any invalid UTF8 characters in a URI.
Invalid hex encoding
A valid hex sequence is where a percentage sign is followed by two hexadecimal values to represent a single byte of data. An invalid hex sequence would be percentage sign followed by something which is not a valid hexadecimal value.
Double encoding
This looks for any hex sequence which itself is encoded using other hex escape sequences. An example would be the original sequence %2526 where %25 is then might be decoded by the HTTP server to '%' and results in the sequence '%26'. This is then finally decoded to '&'.
Initial IDP Packet Processing
The initial order of packet processing with IDP is as follows:A packet arrives at the firewall and cOS Core performs normal verification. If the packet is part of a new connection then it is checked against the IP rule set before being passed to the IDP subsystem. If the packet is part of an existing connection it is passed straight to the IDP system. If the packet is not part of an existing connection or is rejected by the IP rule set then it is dropped.
The source and destination information of the packet is compared to the set of IDP Rules defined by the administrator. If a match is found, it is passed on to the next level of IDP processing which is pattern matching, described in step below. If there is no match against an IDP rule then the packet is accepted and the IDP system takes no further actions although further actions defined in the IP rule set are applied such as address translation and logging.
IDP Signatures
In order for IDP to correctly identify an attack, it uses a profile of indicators, or pattern, associated with different types of attack. These predefined patterns, also known as signatures, are stored in a local cOS Core database and are used by the IDP subsystem to analyze traffic for attack patterns. Each IDP signature is designated by a unique number.Consider the following simple attack example involving an exchange with an FTP server. A rogue user might try to retrieve the password file "passwd" from an FTP server using the FTP command RETR passwd. A signature looking for the ASCII text strings RETR and passwd would find a match in this case, indicating a possible attack. In this example, the pattern is found in plaintext but pattern matching is done in the same way on pure binary data.
Recognizing Unknown Threats
Attackers who build new intrusions often reuse older code. This means their new attacks can appear in circulation quickly. To counter this, Clavister IDP uses an approach where cOS Core scans for these reusable components, with pattern matching looking for building blocks rather than a completed program. This means that known threats as well as new, previously unknown threats, built with the same reusable components, can be protected against.Signature groups, subgroups and more about the signature hierarchy are discussed next.
Signature Groups
Usually, several lines of attacks exist for a specific protocol, and it is best to search for all of them at the same time when analyzing network traffic. To do this, signatures related to a particular protocol are grouped together. For example, all signatures that refer to the FTP protocol form a group. It is best to specify a group that relates to the traffic being searched than be concerned about individual signatures. For performance purposes, the aim should be to have cOS Core search data using the least possible number of signatures.Specifying Signature Groups
IDP Signature Groups fall into a three level hierarchical structure with the following naming form:Type_Group_SubgroupThe top level of this hierarchy is the signature Type, the second level the Category and the third level the Sub-Category. The signature group called POLICY_DB_MSSQL illustrates this principle where Policy is the Type, DB is the Category and MSSQL is the Sub-Category.
1. The Signature Type
The signature type can be one of the following values:
IPS
Intrusion Protection Signatures (IPS) are highly accurate and a match is almost certainly an indicator of a threat. Using the Protect action is recommended. These signatures can detect administrative actions and security scanners.
IDS
Intrusion Detection Signatures (IDS) can detect events that may be intrusions. They have lower accuracy than IPS and may give some false positives so it is recommended that the Audit action is always used. Using them with Protect may interrupt normal traffic.
POLICY
Policy Signatures detect different types of application traffic. They can be used to block certain applications such as file sharing applications and instant messaging.
2. The Signature Group
This second level is the group name which describes the type of application or protocol. Examples are:
3. The Signature Subgroup
The third level of naming further specifies the target of the group and often specifies the application, for example MSSQL. The Subgroup may not be necessary if the Type and Group are sufficient to specify the set of signatures, for example APP_ITUNES.
The Appendix Listing of IDP Groups
A listing of IDP groupings can be found in Appendix B, IDP Signature Groups. The appendix lists all the signature groupings using the Group name followed by the Subgroup name. The Type could be one or more of IDS, IPS or POLICY so this is not included in the listing.Signature Advisories Can Be Searched Online
An advisory is an explanatory textual description of an IDP signature. Reading a signature's advisory will explain to the administrator what the signature will search for. Due its changing nature, an advisory list is not included in cOS Core documentation. Instead, as mentioned previously, it is available online in searchable form at the following link:https://www.clavister.com/advisories/idp
Processing Multiple IDP Rule Actions
For any IDP Rule object, it is possible to add one or more IDP Rule Action objects as children of the IDP rule. The signatures of each IDP Rule Action are then all applied in turn to the targeted traffic in a top-down ordering. When a match triggers, the action of the triggering IDP Rule Action object is applied.A signature at a higher position in the IPD Rule Action list will have precedence over another occurrence of the same signature lower down in the list. In other words, only the action associated with a signature's first occurrence in the IPD Rule Action list is performed. This makes it possible to exclude individual signatures from a group by specifying them in a higher IDP Rule Action with the Action property set to ignore. Setting this up is illustrated in Example 7.8, “Setting up IDP for a Mail Server”.
When selecting IDP signature groups, it is possible to use wildcarding to select more than one group. The "?" character can be used as the wildcard for a single character in a group name. Alternatively, the "*" character can be used as the wildcard for any set of characters of any length in a group name.![[Caution]](images/caution.png) |
Caution: Use the minimum IDP signatures necessary |
|---|---|
|
Use only the minimum of IDP signatures and/or groups necessary. Groups can contain large numbers of signatures and should be used with caution. Sometimes, only a few specific signatures may be needed to defend against the most current and serious threats. IDP traffic scanning creates an additional processing load on the firewall. Depending on the underlying hardware platform, this should not noticeably degrade performance. However, using too many IDP signatures will adversely affect throughput. Using all the IDP signatures at once should never be attempted. Enabling the IDP scan limit can help to alleviate a persistent performance problem. |
The Maximum Number of IDP Signatures Allowed
Each cOS Core system will have a limit for how many IDP signatures can be used by the IDP subsystem at the same time. This limit depends less on the available free memory amd more on the total memory that the system has. If the maximum limit is reached, the following console message will be seen:Failed to add some signature(s) in rule <IDP rule name>: maximum number of signatures reached - not all signatures will be usedBelow are some approximate guidelines for how the total available memory relates to the maximum possible signatures:
Up to 500 MBytes system memory: Approximately 15,000 signatures
500 MBytes to 1 GByte system memory: Approximately 22,000 signatures
Over 1 GByte system memory: Approximately 30,000 signatures
Note that the above numbers are only guidelines and are subject to change depending on the cOS Core version and computing platform.
Overview
When defining an IDP Rule object, the administrator can enable or disable the option Protect against insertion/evasion attacks (it is enabled by default). An insertion/evasion attack is a form of attack which is specifically aimed at evading IDP mechanisms. It exploits the fact that in a TCP/IP data transfer, the data stream must often be reassembled from smaller pieces of data because the individual pieces either arrive in the wrong order or are fragmented in some way. Insertions or evasions are designed to exploit this reassembly process.Insertion Attacks
An insertion attack consists of inserting data into a traffic stream so that the resulting sequence of data packets is accepted by the IDP subsystem but will be rejected by the targeted application. This results in two different streams of data.As an example, consider a data stream broken up into 4 packets: p1, p2, p3 and p4. The attacker might first send packets p1 and p4 to the targeted application. These will be held by both the IDP subsystem and the application until packets p2 and p3 arrive so that reassembly can be done. The attacker now deliberately sends two packets, p2' and p3', which will be rejected by the application but accepted by the IDP system. IDP is now able to complete reassembly of the packets and believes it has the full data stream. The attacker now sends two further packets, p2 and p3, which will be accepted by the application which can now complete reassembly but resulting in a different data stream to that seen by the IDP subsystem.
Evasion Attacks
An evasion attack has a similar end-result to the insertion Attack in that it also generates two different data streams, one that the IDP subsystem sees and one that the target application sees, but it is achieved in the reverse way. It consists of sending data packets that are rejected by the IDP subsystem but are acceptable to the target application.Detection Action
If an insertion or evasion attack is detected with the Insertion/Evasion Protect option enabled, cOS Core automatically corrects the data stream by removing the extraneous data associated with the attack.Insertion/Evasion Log Events
The insertion/evasion attack subsystem in cOS Core can generate two types of log message:An Attack Detected log message, indicating an attack has been identified and prevented.
An Unable to Detect log message when cOS Core has been unable to identify potential attacks when reassembling a TCP/IP stream although such an attack may have been present. This condition is caused by infrequent and unusually complex patterns of data in the stream.
Insertion/Evasion Protection is Recommended
By default, insertion/evasion protection is enabled for all IDP rules and this is the recommended setting for most configurations. There are two motivations for disabling the option:Increasing throughput - Where the highest throughout possible is desirable, then turning the option off, can provide a slight increase in processing speed.
Excessive False Positives - If there is evidence of an unusually high level of insertion/evasion false positives then disabling the option may be prudent while the false positive causes are investigated.
The steps for setting up IDP are as follows:
Create an IDP Rule object which identifies the traffic to be processed.
Add one or more child IDP Rule Action objects to the rule which each specify:
The IDP signatures used for scanning the traffic. These can consist of one or more single signatures and/or groups with wildcarding possible.
The action to take when a signature triggers. This can be to drop the connection with a log message generated, or to just log that the action triggered, or to ignore the trigger (the latter is useful for excluding signatures from actions lower in the action list).
Enable the IDP scan limit option if the IDP subsystem is impacting system performance. Setting a scan limit can significantly speed up IDP processing.
Choose to blacklist source IPs that caused IDP to trigger. This is explained next.
The following properties exist in the IDP Rule Action object to control dynamic blacklisting if blacklisting is enabled.
Block duration
The duration of the block in seconds. If not specified (the default) it will be indefinite, or until the next system restart.
Block service
The block of the source IP address will only apply to traffic from that address with the protocol that triggered the block. Traffic with a different protocol will not be affected. This is disabled by default.
Ignore established
When a block is triggered by a source IP address then existing connections from that IP address will not be affected. This is disabled by default.
|
Tip: Whitelist the management IP addresses |
|---|---|
|
Any IP address that exists in the cOS Core whitelist cannot be blacklisted. For this reason it is recommended that the IP address of the firewall management computer and the Clavister firewall itself is added to the whitelist so they cannot be blocked by IDP. |
For more details of how blacklisting functions see Section 7.10, Blacklisting/Whitelisting IP Addresses.
Example 7.8. Setting up IDP for a Mail Server
The following example details the steps needed to set up IDP for a simple scenario where a mail server is exposed to the Internet on the DMZ network with a public IPv4 address. The Internet can be reached through the firewall on the WAN interface as illustrated below.
An IDP rule called IDPMailSrvRule will be created, and the Service object to use is the SMTP service. The Source Interface and Source Network defines where traffic is coming from, in this example the external network. The Destination Interface and Destination Network define where traffic is directed to, in this case the mail server. The Destination Network should therefore be set to the object defining the mail server.
The IDP signature group called IPS_SMTP_* will be used but the specific signatures for SMTP overflow exploits (72828, 72829, 58183 and 52543) will be excluded from the group by first adding a separate IDP Rule Action.
In addition, if a new connection triggers a Protect action then the source IP address will be blacklisted with a block time of 3600 seconds.
To improve processing performance, the scan limit option will be enabled using a scan limit value of 2048 bytes.
Command-Line Interface
Create an IDP Rule for the targeted traffic:
Device:/> add IDPRule SourceInterface=wan
SourceNetwork=wan_net
DestinationInterface=dmz
DestinationNetwork=ip_mailserver
Service=smtp
Name=IDPMailSrvRule
ScanLimit=Yes
ScanLimitBytes=2048Change the CLI context to be the rule:
Device:/> cc IDPRule IDPMailSrvRule
Device:/IDPMailSrvRule> First, add the signatures to be excluded from the IPS_SMTP group:
Device:/IDPMailSrvRule> add IDPRuleAction
Action=Ignore
Signatures=72828,72829,58183,52543Add scanning with the IPS_SMTP group signatures:
Device:/IDPMailSrvRule> add IDPRuleAction
Action=Protect
Signatures=IPS_SMTP_*
Blacklist=Yes
BlackListTimeToBlock=36000InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Create an IDP Rule for the targeted traffic:
First, add the signatures to be excluded from the IPS_SMTP group:
Add scanning with the IPS_SMTP group signatures:
Finally, click OK to save the rule and its actions.
Clavister IDP is a subscription based feature and the license must allow IDP for the IDP signature database to be downloadable by cOS Core and to be regularly updated with new signatures for the latest intrusion threats. Details about IDP subscriptions and IDP behavior after subscription expiry, can be found in Appendix A, Subscription Based Features.
Automatic IDP Updating
New attacks can be discovered on a daily basis, so it is important to have an up to date signature database in order to protect the network from the latest threats. Auto-update is an option that can be enabled or disabled by the administrator.With auto-update enabled, signature database updates are downloaded automatically by cOS Core at a configurable interval. This is done via an HTTP connection to the Clavister server network which delivers the latest signature database updates. If the server's signature database has new signatures then new updates will be automatically downloaded, replacing any older versions. No reconfiguration operation is needed by the administrator to activate new signatures.
If auto-update is disabled then updates must be explicitly forced and the administrator needs to be aware of when new updates are available. However, this approach does help with more quickly detecting any false positives that new signatures might produce.
Setting the Correct System Time for IDP
It is important that cOS Core has the correct system time set if the auto-update feature in the IDP module can function correctly. An incorrect time can mean the auto-updating is disabled.The following console command will show the current status of the auto-update feature:
> updatecenter -status
This information can also be viewed using the Web Interface by going to: Status > Maintenance > Update Center.
Updating IDP in High Availability Clusters
Updating the IDP databases for both the units in an HA Cluster is performed automatically by cOS Core. In a cluster there is always an active unit and an inactive unit. Only the active unit in the cluster will perform regular checking for new database updates. If a new database update becomes available the sequence of events will be as follows:The active unit determines there is a new update and downloads the required files for the update.
The active unit performs an automatic reconfiguration to update its database.
This reconfiguration causes a failover so the passive unit becomes the active unit.
When the update is completed, the newly active unit also downloads the files for the update and performs a reconfiguration.
This second reconfiguration causes another failover so the passive unit reverts back to being active again.
These steps result in both firewalls in a cluster having updated databases and with the original active/passive roles. For more information about HA clusters refer to Chapter 12, High Availability.
The following are some best practice recommendations for IDP employment:
Enable only the IDP signatures for the traffic that is to be allowed. For example, if the IP rule set is only allowing HTTP traffic then there is no point enabling IDP FTP signatures to scan that traffic.
Use the minimum number of signatures needed to achieve the goal. Excess signature use can firewall degrade performance.
Use rules with an action of ignore at the top of the IDP rule set to exclude specific signatures that cause problems such as false positives. Entire groups of signatures can also be ignored in this way.
For example, an initial rule in the IDP rule set could ignore all signatures with a type of IDS or POLICY using wildcards. This was previously discussed in Tip: The signature types IDS and POLICY may not be needed.
Once the relevant signatures are selected for IDP processing, the IDP system should always be initially run in Audit mode.
After running IDP in Audit mode for a sample period with live traffic, examines the log messages generated. Check for the following:
When IDP triggers, what kind of traffic is it triggering on?
Is the correct traffic being identified?
Are there any false positives with the signatures that have been chosen?
Adjust the signature selection and examine the logs again. There may be several adjustments before the logs demonstrate that the desired effect is being achieved.
If certain signatures are repeatedly triggering, it may be a reason to look more closely to check if a server is under attack.
After a few days running in Audit mode with satisfactory results showing in the logs, switch over IDP to Protect mode so that triggering connections are dropped by cOS Core. However, IDS signatures are best kept in Audit mode as they can interrupt normal traffic flows because of false positives.
If required, enable the blacklisting feature of IDP so that the source IP for triggering traffic is blocked. This is a powerful feature of IDP and useful when dealing with an application like BitTorrent.
Automatic updates might take place without the necessary checking in place to make sure there are no disruptions to live traffic.
