Event Triggers

The event triggers view displays the scaffolds that configure the events that define transient group membership policy.

The transient group membership mechanism temporarily changes the group membership of an end-user. Since group membership determines which policies are enforced, event triggers are a simple way to temporarily change the end-user experience.

The possibilities of what can be accomplished through transient group memberships are endless. For example, when max connections triggers can be configured to establish transient IP group membership for abusive behavior. The transient IP group may then be associated with a splash portal policy to quarantine the user, a packet filter policy to blackhole the user or a bandwidth queue policy to throttle the user for some specified period of time.

The space-time triggers and quota triggers are typically used for end-user communication and upselling of premium services. A simple way to utilize this is to create a quota trigger that triggers on high utilization and places these end-users into a group. This transient group can then be associated with a policy that is linked to interstitial redirection to a page that communicates with the end-user about their high utilization and offers them the opportunity to buy more. In addition, the interstitial page might offer the end-user the ability to switch to a plan that has higher bandwidth rates.

The DPI triggers enable the operator to apply transient group memberships to subsets of the end-user population that match any profile that may be described in the form of a deep-packet inspection rule. This may be used to detect specific kinds of applications (e.g., BitTorrent, VoIP, etc.) or specific usage patterns (e.g., the presence of a streaming media center or a NAT router). The remote DPI signatures capability enables the operator to deploy DPI triggers as a malware egress filtering mechanism.

All triggers are configured to enforce upon policy and send matches to transient group memberships. End-users are sourced from the policies associated with trigger record. End-users that match the trigger enforcement are then destined for the configured transient group memberships.

Connections Triggers

Records in the connections triggers scaffold define the configuration of the rXg behavioral intrusion protection system.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The policy field relates this record to a set of groups through a policy record.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The max connections field specifies the number of simultaneous connections that an end-user or device can utilize before the behavioral IPS is triggered. The number of connections is determined by counting the number of TCP and UDP streams that transit to the WAN through the rXg. Currently observed active connections, recently attempted connections (regardless of whether or not they actually connected) as well as recently closed connections are all counted. How long recent connection attempts and recently closed connections are counted is determined by the setting the state timeout in the network options.

The operator should tune value for the max connections to a value that best fits the nature of the end-users on the LAN. Many applications utilize multiple TCP and/or UDP streams in parallel. For example many web browsers will open several connections to a web server in order to download multiple assets referenced by a web page at the same time. Cloud computing applications tend to have software hooks that keep several background connections active at all times. Thus a value too small will trip a very large number of false positives.

Setting the max connections field to a value that is overly large prevents the behavioral IPS from detecting malicious software that is designed to avoid attracting attention. Worms that rapidly proliferate by opening as many connections per second as the infected CPU will support have given way to worms that attempt to proliferate under the radar. Many P2P software systems have a setting that configures the maximum number of simultaneous connections whose purpose is to help prevent the software from being detected. Thus it is important to tune the max connections field that is small enough to allow the kinds of applications present on the network while detecting malicious activity.

The behavioral IPS should always be enabled for all networks. If the operator is unwilling to cope with even a single false positive then the max connections should simply be set large enough to put the most egregious offenders into a transient group membership for instant remediation. The transietn group membership is typically associated with a policy that blocks all traffic (e.g., via a splash portal) or slows all traffic down (e.g., via a traffic shaping queue) and notifies the end-user of the violation (e.g., via an interstitial redirect or injection).

The duration determines the length of time that an end-user or device that has triggered the IPS will remain a member of the transient group. Once the duration is reached the transient group membership expires and the end-user or device will be returned to their original policy. If the number of connections being utilized exceeds the configured max connections the trigger will be fired again and the end-user or device will be placed into a new transient group membership for the specified duration.

If an end-user or device triggers the behavioral IPS, they will become a transient member of the IP group specified by the IP group field. connections triggers affect all devices that are associated with the record through the policy regardless of authentication method.

Quota Triggers

Records in the quota triggers scaffold define rules that will change the effective policy of end-users based on the data transfer utilization over a specified period of time.

The policy field relates this record to a set of groups through a policy record.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Quota triggers operate on calculated aggregate traffic transfer over an operator specified period of time. Thus operators configure the quota in multiples of bytes (e.g., megabytes, gigabytes, etc.). Furthermore the operator specifies the quota trigger time period to be since the last recharge or a rolling window of time. The values are mathematically to the traffic shaping system which is deals with instantaneous transfer rates configured in multiples of bits per second (e.g., kilobits per second, megabits per second, etc.) but the use cases are usually very different.

The download , download unit , upload and upload unit fields configure the aggregate amount of data transfer that must be recorded before a triggering a transient group membership. The download and upload fields specify the value representing the utilization level that needs to be met while the download unit and upload unit fields specify the type of the value fields.

When the download unit and/or upload unit is set to % , the download and/or upload value is taken to mean a percentage of the quota stored in the usage plan record associated with the end-user record. For example, if the download quota in the usage plan record is 500 MB and the download field is configured to be 25 with a download unit of % , when the end-user utilization reaches 125 MB, the transient group membership will be triggered.

When the download unit and/or upload unit is set to MB or GB , the download and/or upload value is taken to mean an absolute value in megabytes or gigabytes respectively. The utilization stored in the end-user record must exceed the value configured in the record in order for the transient group membership to be triggered.

The logic field configures whether one or both of the utilization levels specified in the upload and download fields must be met before this record triggers a transient group membership. A setting of and requires both the upload and download utilization levels be met before a transient group membership is triggered. When set to or , satisfying either upload or download utilization level is sufficient to trigger a transient group membership.

The window field specifies the amount of time over which the the quota trigger will measure usage. The window is specified as the time in the past for the beginning of the measurement period. The measurement period always ends at the present. For example if a window of 2 days is specified then the usage will be measured starting from two days ago until the present.

Rolling window based quotas are most often used to control end-user behavior in a manner similar to the rate limiting mechanisms found in the traffic shaper. A rolling window-based quota enables the operator enforce a lower effective transfer rate. For example, a rolling quota of 5 GB per month that is popular with WWAN data providers is comes to an average rate that is only 15 kbps. A relatively loose rolling quota of 10 GB per week comes to only 277 kbps.

This mode is used to apply control over transient or fixed end-user populations regardless of whether or not quota is being explicitly sold to the population. The destination transient group membership is typically associated with a lower maximum instantaneous rate queue along with some kind of end-user notification (e.g., an interstitial that informs the end-user of their overage condition).

If no window is specified then the quota trigger will measure usage since the last quota recharge. This mode is most used in scenarios with a fixed end-user population where the operator wants to upsell additional quota to end-users when their consumption is approaching their purchased limit. The destination transient group membership is typically associated with a notification mechanism (e.g., an injection with copy informing of the overage condition and a link to the portal to purchase an upgrade).

The duration field specifies the amount of time that an end-user will remain a member of the transient group after exceeding the defined transfer quotas. By default the transient group membership is in effect for as long as the quota trigger condition is met.

The account group field configures the destination where end-user matching the utilization values specified in this record will be sent. If an end-user's utilization meets the criteria defined in this quota trigger , they will become a transient member of the account group specified by the account group field.

Space-Time Triggers

Records in the space-time triggers scaffold define rules that will change the effective policy of end-users based on the time of day, day of the week, and physical location.

The policy field relates this record to a set of groups through a policy record.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The start and end fields configure the range of time that the time trigger is active. The start time must precede the end. The trigger is active for the time period between start and end. To specify an entire day, use a start of 00:00:00 and an end of 23:59:59. To specify more than one time period during a single day, multiple time trigger records must be created.

The days field specifies the days of the week that this time trigger is active. A checked box indicates that the the time trigger is active during the day that is labeled. The parameters specified by the days field as well as the the start and end fields must both be satisfied (logical and) in order for the trigger to be active.

The IP group , MAC group and account group fields configure the destination for the IPs, MACs and users associated with this trigger through the selected policy when the trigger is active. Only one of the three possible destinations should be selected for any given record. The account group destination is only effective when the policy is associated with a user group as no login session is created for IP groups and MAC groups.

DPI Triggers

Records in the DPI triggers scaffold define rules that will change the effective policy of end-users based on a DPI signature.

The policy field relates this record to a set of groups through a policy record.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The DPI signatures field links the DPI trigger to one or more DPI signatures specified on the definitions view. The DPI signatures are what are used to determine the firing of the trigger and the temporary IP group membership.

The duration field specifies the amount of time that an end-user will remain a member of the transient group after matching a DPI signature. For example, if a DPI signature specifies a virus and the target transient group is linked to quarantine policy, the duration represents the length of time that the end-user would remain quarantined after the virus is initially detected.

The IP group field configures the destination where end-user matching the DPI signature specified in this record will be sent. DPI triggers affect all devices that are associated with the record through the policy regardless of authentication method.

Remote DPI Signatures

An entry in the Remote DPI Signatures scaffold configures the rXg for automatic download of deep packet inspection signatures that are used to identify and classify of end-user traffic from a third-party website.

The categories field allows the operator to choose from one or more groups of predefined signatures present on the third-party server. This field is only useful when the URL of this remote DPI signature refers to a gzipped tarball archive. The signatures present in the archive are presumed to be organized by file name. Each file should contain signatures that are relevant to the name of the file.

The SID whitelist field enables the operator to exclude specific rules from being used. This feature is typically used to exclude overly aggressive rules and thus reduce the possibility of false positives. Consider the following rule from the Snort emerging threats list:

emerging-p2p.rules:alert udp $HOME_NET 1024:65535 -> $EXTERNAL_NET 1024:65535 (msg:"ET P2P Edonkey Publicize File"; dsize:>15; content:"|e3 0c|"; depth:2; reference:url,www.giac.org/certified_professionals/practicals/gcih/0446.php; reference:url,doc.emergingthreats.net/bin/view/Main/2003310; classtype:policy-violation; sid:2003310; rev:3;)

The example rule shown above is known to occasionally trip false positives with Skype file sharing. Listing 2003310 into the SID whitelist field causes the rule to be ignored. Multiple SIDs may be listed in the SID whitelist to tell the DPI engine to ignore more than one rule in the remote set.

When a remote DPI signature record is first created, the categories field will be empty. Once the signatures have been downloaded and extracted for the first time, the names of the files will then appear in this field. After creating a remote DPI signature it is necessary to edit the record and select the desired categories in order for proper operation. Initial download time (and hence, population of the categories field depends upon the size of the archive file as well as the speed of the network connection between the server addressed by the URL.

The URL field contains the URL of the file that the rXg will download. The target file is expected to be in one of two formats: .tar.gz archive or a .txt plain text file. If the file is a gzipped tarball archive (.tar.gz), it is expected to extract multiple files named by category, each of which contains DPI signatures. If the file is plain-text, it is expected that the file is simply a file of the the DPI signatures. The rXg supports DPI signatures formatted for Snort 2.9. Well known remote DPI signature repositories include the official Snort rules and the Snort emerging threats list.

The frequency field specifies the download interval. Some sites have terms of use that specify appropriate download intervals. Please check the remote site terms and conditions carefully before using.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Log Hits Trigger

Records in the log Hits Triggers scaffolds defines rules that will dynamic blacklisting with transient WAN membership based on log hits.

The*name*field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The*policyfield relates this record to a set of groups through apolicy*record.

The log field allows the operator to select which log will be monitored for predetermined behaviors.

The max hits field specifies the number of log hits for a specified service by a device on the LAN or WAN before the behavior IPS is triggered.

The window field specifies the the amount of time over which the log hits trigger will measure usage. The window is specified as the time in the past for the beginning of the measurement period. The measurement period always ends at the present. For example if a window of 5 minutes is specified then the connection will measure starting from 5 mins ago until the present.

The duration field specifies the amount of time that a connection that an end-user or IP has triggered the IPS will remain a member of the transient group. The the duration is reached the transient group membership expires and the end-user or IP will be removed. If the number of connection being utilized exceeds the configured max hits the trigger will be fired again and the end-user or IP will be placed into a new transient group membership for the specified duration.

The MAC group and IP group fields configure the identity for the IPs, MACs, and users associated with this trigger through the selected policy when the trigger is active. The WAN Target field selects the destination for violating IPs originating from the WAN. This list of IPs can be used in other areas of the rXg configuration. Only one of the three possible destinations should be selected for any given record.

The flush connection states allows an operator to clear some or all of the active session data. Flushing DHCP leases erases IP address assigned. Flushing MAC entries erases the saved MAC addresses from the devices table. Flushing VLAN assignments clears the the VLAN association from the device MAC.

In the notifications section, the message fields allows you to specify which custom email will be sent when an event is triggered.