Security¶
Introduced : BIG-IP_v9.0
The Security module contains interfaces that enable you to set up a
firewall and security policies on your BIG-IP system.
Interfaces¶
| Interface | Description |
| DoSDevice | The DoS Device interface enables you to manipulate a DoS Device. Use this interface to mitigate Denial of Service (DoS) attacks for the entire device. The DoS Device interface consists of DoS Device Vectors that have an effect across the entire device. DoS Device both detects attacks and drops packets in response to those attacks. The detection parameters and the drop parameter are set on a per vector basis. To set an attribute of a single vector to infinite, you must set the value to -1 (4294967295 unsigned). To entirely turn off both detection and dropping of packets for a single vector, set the value of all 3 attributes to -1. There is only one DoS Device for the entire system, called “dos-device-config”. Please supply this key to all methods requiring the “devices” argument. The DoS Device Vectors are built in to “dos-device-config”; they cannot be added or removed. |
| DoSWhitelist | The DoS Whitelist interface enables you to manipulate a DoS whitelist. While blacklists are used to block traffic, you can use whitelists to allow traffic based on specific IP addresses. Whitelists can be assigned to global, route domain, and virtual server contexts. There is only one DoS Whitelist for the entire system, called “dos-network-whitelist”. Please supply this key to all methods requiring the “whitelists” argument. |
| FirewallAddressList | The FirewallAddressList interface enables you to create and modify IP address lists on which to perform firewall security actions. Note that the addresses in all methods are type Common::NetAddress, a type which allows one to specify a prefix length after the address, e.g., “10.1.1.0/24”. |
| FirewallGlobalAdminIPRuleList | The FirewallGlobalAdminIPRuleList interface enables you to add rules to the global management interface rule list and modify the rules. You can use this interface to configure network firewall rules that are applied to the management interface. IP and ICMP packets are compared to the criteria specified in the rules. If a packet matches the criteria then the system will take the action specified by the rule. If a packet does not match a rule then the packet will be compared against the next rule. Rules are evaluated in the order in which they are specified. Note that the source and destination addresses in the firewall methods (get_fw_rule and so on) are type Common::NetAddress, a type which allows one to specify a prefix length after the address, e.g., “10.1.1.0/24”. |
| FirewallGlobalRuleList | The FirewallGlobalRuleList interface enables you to add rules to the global firewall rule list and modify the rules. You can use this interface to configure network firewall rules that are applied to all traffic except the management interface. IP and ICMP packets are compared to the criteria specified in the rules. If a packet matches the criteria then the system will take the action specified by the rule. If a packet does not match a rule then the packet will be compared against the next rule. If a packet does not match a global rule, depending on the packet content, the packet will either be accepted or passed to the next set of rules (example: the packet will be compared to Networking self IP rules if the packet is destined for a network associated with a self IP that has firewall rules defined). Rules are evaluated in the order in which they are specified. You can also set enforced and/or staged firewall policy with the FirewallGlobalRuleList interface. The enforced policy&aposs rules are enforced as if the same rules were defined as inline rules under FirewallGlobalRuleList interface. The staged policy&aposs rules provide the visibility only of what would happen if they were enforced while they are actually not enforced. Note that the source and destination addresses in the firewall methods (get_fw_rule and so on) are type Common::NetAddress, a type which allows one to specify a prefix length after the address, e.g., “10.1.1.0/24”. |
| FirewallPolicy | The FirewallPolicy interface enables you to create and modify a firewall policy which can be further assigned to firewalled objects. You can use this interface to configure network firewall rules that are applied to the traffic passing through corresponding network objects to which this policy is applied. IP and ICMP packets are compared to the criteria specified in the rules. If a packet matches the criteria then the system will take the action specified by the rule. If a packet does not match a rule then the packet will be compared against the next rule. Rules are evaluated in the order in which they are specified. A firewall policy can be assigned to a firewalled object as enforced or staged. When the policy assigned as enforced its rules behave the same way as if were added directly under the firewalled object. When the policy assigned as staged, none of its rules are enforced but the visibility aspects (statistics, logging events and network reports) are updated as if the rules were enforced. The latter are important for you to understand what would happen if you started enforcing the currently staged policies. Note that the source and destination addresses in the firewall methods (get_fw_rule and so on) are type Common::NetAddress, a type which allows one to specify a prefix length after the address, e.g., “10.1.1.0/24”. |
| FirewallPortList | The FirewallPortList interface enables you to create and modify port lists on which to perform firewall security actions. |
| FirewallRuleList | The FirewallRuleList interface enables you to create and modify named collections of firewall rules. You can attach a rule list to rules for other objects, like virtual servers and self IPs. Note that the source and destination addresses in the firewall methods (get_fw_rule and so on) are type Common::NetAddress, a type which allows one to specify a prefix length after the address, e.g., “10.1.1.0/24”. |
| FirewallWeeklySchedule | The FirewallWeeklySchedule interface enables you to set a schedule at which firewall rules are active, based on days of the week as well as times of day. You can also set a date and time at which the schedule begins and ceases to be valid. |
| IPIntelligenceBlacklistCategory | The BlacklistCategory interface enables you to update the global list of blacklist categories. The IP Intelligence blacklist categories are a single global list of up to 62 entries maintained in the Common partition. There&aposre 9 categories predefined in the system: /Common/spam_sources (Spam Sources), /Common/windows_exploits (Windows Exploits), /Common/web_attacks (Web Attacks), /Common/botnets (BotNets), /Common/scanners (Scanners), /Common/denial_of_service (Denial of Service), /Common/infected_sources (Infected Sources), /Common/phishing (Phishing), /Common/proxy (Proxy), /Common/illegal_websites (Illegal Websites), /Common/cloud_provider_networks (Cloud Provider Networks) and /Common/application_denial_of_service (dosl7). There are 2 ways the global list can be updated: 1) Automatically by the system: when new categories are auto-learned from the downloaded feeds they&aposre added into the list so a user could use it when configuring IP Intelligence policies. 2) You can use the blacklist category component to add or remove blacklist categories which can then be used in IP intelligence policies to configure specific enforcement and logging settings per each blacklist category. Note: system predefined categories can never be removed. |
| IPIntelligenceFeedList | The FeedList interface enables you to manipulate a feed list. A feed list is a list of feed objects. Each of them specifies a well-formed URL pointing to a web feed which is periodically downloaded according to the configured poll period. Optional username and password may be configured for the feeds requiring authentication. Each web feed is expected to be a CSV file each line in which associates an IP address or subnet with the whitelist or a blacklist. The line format is: <IPv4/IPv6 address>, <subnet prefix>, <category type>, <blacklist category name>. All the fields but <IP address> are optional. When <category type> and/or <blacklist category name> are omitted, the defaults configured in the feed object are used. The feed lists are added to IP Intelligence policies which might be applied globally and/or on specific network objects - route domains and virtual servers. |
| IPIntelligenceGlobalPolicy | The IPIntelligenceGlobalPolicy interface enables you to set a global IP Intelligence policy. The global IP intelligence policy is applied to all the packets before route domain&aposs and/or virtual server&aposs IP Intelligence policies. There is only one IP intelligence global policy for the entire system, called “/Common/global-dwbl-container”. Please supply this key to all methods requiring the “global_policies” argument. |
| IPIntelligencePolicy | The IPIntelligencePolicy interface enables you to manipulate an IP Intelligence policy. The IP Intelligence policy is a functionally enriched generalization of the IP Intelligence profile (the latter has been immediately deprecated in this release). As opposed to the deprecated profile, policy can be applied to route domains and globally in addition to virtual servers. When packet passes through the system first the global policy is applied, then route domain&aposs one and then virtual&aposs one provided the configured policies are applicable to the packet&aposs source IP. In addition to the predefined blacklist categories (see the IPIntelligenceBlacklistCategory interface) and 3rd party integrated IP reputation database coming with the system the IP Intelligence policy provides an ability to configure dynamic IP whitelists and blacklists downloaded from external web feeds (see IPIntelligenceFeedList interface). The IP Intelligence policy is comprised of three logical groups of settings: 1) List of feed lists create the union set of IP addresses/subnets with their blacklist/whitelist categorization. The policy is applied on the packet only if packet&aposs source IP is found in that set. 2. Enforcement and logging settings per blacklist category. If the policy applies to the packet and the packet&aposs source IP&aposs blacklist category is explicitly confgured in the policy, the configuration settings will be applied to that packet. When the packet&aposs source IP is categorized with more than one category the most restrictive action and logging settings will apply. 3. Default policy enforcement and logging settings are used when the packet to which the policy applied is categorized with the blacklist which isn&apost explicitly configured in this policy or it is configured and the corresponding setting is set with the option “use policy setting”. |
| LogProfile | The LogProfile interface enables you to manipulate (security) logging profiles. A logging profile is used to record requests to the virtual server. You may use more than one logging profile per virtual server (see LocalLB::VirtualServer::add_security_log_profile). Logging profile consists of several parts (layers): Application Security, Protocol (Transfer and DNS) Security, Network Firewall and DoS Protection. Each part can be enabled or disabled by means of creating or deleting the corresponding sub-profile. Note that logging profiles with same (or mutually exclusive) parts enabled cannot be associated with one virtual server. In Application Security you can configure where requests to the virtual server are logged, and which part of requests are logged. Requests can be logged either locally by the system and viewed in the Requests screen, or remotely by the client&aposs server. The system forwards the log messages to the client&aposs server using the Syslog service. Note that you cannot modify a system-default logging profile with Application Security enabled. In Protocol (Transfer) Security you can configure the remote server where the system sends the Protocol Security log messages. The settings you configure in this sub-profile apply only to security profiles (HTTP, FTP and SMTP) associated with the same virtual server as the logging profile containing it. Note that Application and Protocol (Transfer) Security are mutually exclusive parts per logging profile and virtual server. A Network Firewall sub-profile allows you to configure where to log requests to the virtual server to which the log profile is attached. The system groups the requests into several categories (e.g., ACL matches, TCP errors etc). In addition, you can configure whether the requests need to be locally stored on the system or sent to an external server (e.g., syslog, ArcSight, Splunk servers). A Protocol DNS Security sub-profile allows you to configure where to log DNS requests to the virtual server to which the log profile is attached. The system groups the requests into several categories (e.g., malicious, malformed, dropped, rejected etc). In addition, you can configure whether the requests need to be locally stored on the system or sent to an external server (e.g., syslog, ArcSight, Splunk servers). A Protocol SIP Security sub-profile allows you to configure where to log SIP requests to the virtual server to which the log profile is attached. The system groups the requests into several categories (e.g., malformed, dropped etc). In addition, you can configure whether the requests need to be locally stored on the system or sent to an external server (e.g., syslog, ArcSight, Splunk servers). A DoS Network Security log publisher allows you to configure where to log DoS Network information for the virtual server that the log profile is attached to. DoS Network is similar to DoS Device, as it offers DoS attack protection at the virtual server level. The information can be locally stored on the system or sent to an external server (e.g., syslog, ArcSight, Splunk servers). See Log::Publisher for more information. |
| ProfileDNSSecurity | The ProfileDNSSecurity interface enables you to manipulate DNS Security profiles. DNS Security allows you to filter (drop) DNS packets based on their query type, such as AAAA or NS, or their header opcode, such as QUERY. You can also view the statistics for some (but not all) filters. Note: You attach a DNS Security Profile to a DNS Profile, not to a Virtual Server. |
| ProfileDoS | The ProfileDoS interface enables you to manipulate a DoS profile. Use this interface to prevent Denial of Service (DoS) attacks. DoS profile consists of three parts (layers): Application Security, Protocol (DNS) Security and Protocol SIP Security. Each part can be enabled or disabled by means of creating or deleting the corresponding sub-profile. In Application Security you can configure: - The circumstances under which the system considers traffic to be a DoS attack. - How the system handles a DoS attack. The system considers traffic to be an Application DoS attack based on the following calculations: - Transaction rate detection interval: The average number of requests per second sent for a specific URL, or by a specific IP address. This number is calculated by the system, by default, every minute and updated every second. - Transaction rate history interval: The average number of requests per second sent for a specific URL, or by a specific IP address. This number is calculated by the system, by default, every hour and updated every minute. - Latency detection interval: The average time it takes for the system to respond to a request for a specific URL, over the last minute. This average is updated every second. - Latency history interval: The average time it takes for the system to respond to a request for a specific URL, over the last hour. This average is updated every minute. In this sub-profile you must select whether the system prevents DoS attacks based on the client side (TPS-based anomaly) or/and the server side (Latency-based anomaly). The system&aposs DoS attack prevention works differently for every anomaly you select. - In TPS-based anomaly: If the ratio of the transaction rate detection interval to the transaction rate history interval is greater than the specific percentage you configure in this sub-profile (the TPS increase rate), the system detects the URL to be under attack, or the IP address to be attacking. In order to stop the attack, the system drops some requests from the detected IP address and/to the attacked URL. - In Latency-based anomaly: If the ratio of the transaction rate detection interval to the transaction rate history interval is greater than the specific percentage you configure in this sub-profile (the TPS increase rate), the system suspects the URL to be under attack, or the IP address to be suspicious. If the ratio of the latency detection interval to the latency history interval is greater than the specific percentage you configure in this sub-profile (the latency increase rate), the system detects that this URL is under attack. In order to stop the attack, the system drops some requests from the suspicious IP address and/or to the suspicious URL. The Protocol DNS Security sub-profile allows you to specify DNS Query Vectors to be considered for DoS attack detection. You can also select whether or not to consider Malformed and Malicious DNS packets for DoS attack detection, and configure values at which to start dropping these packets. A Protocol SIP Security sub-profile allows the user to configure SIP Attack Vectors that are to be considered for DoS attack detection. It also provides the capability to enable detection of Malformed SIP packet DoS attacks. The detection sensitivity for each of the configured DoS vectors can also be set. |
| ProfileIPIntelligence | *IMPORTANT* This entire interface has been deprecated immediately. As of v11.5.0, attempting to perform any of the functions in this interface will return a not-implemented exception. The ProfileIPIntelligence interface enables you to manipulate an IP Intelligence profile. Use this interface to configure IP Intelligence threat types and the corresponding actions that you want be taken, for connections with source IPs that are flagged as malicious in the IP Reputation Database. |
Enumerations¶
| Enumeration | Description |
| HeaderOpcode | A list of header opcodes. |
| QueryType | A list of query types. |
Aliases¶
| Alias | Type | Description |
| HeaderOpcodeSequence | HeaderOpcode [] | A sequence of header opcodes. |
| HeaderOpcodeSequenceSequence | HeaderOpcode [] [] | A sequence of sequence of header opcodes. |
| QueryTypeSequence | QueryType [] | A sequence of query types. |
| QueryTypeSequenceSequence | QueryType [] [] | A sequence of sequence of query types. |
See Also¶
Warning
The links to the sample code below are remnants of the old DevCentral wiki and will result in a 404 error. For best results, please copy the link text and search the codeshare directly on DevCentral.
Sample Code¶
The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.