Securing Your Applications with F5 BIG-IP IDS/IPS
Introduction Are you taking advantage of F5 BIG-IP’s built in IDS/IPS?IDS systems monitor traffic for anomalies, where IPS systems react to those events. Since BIG-IP version 13.1.0, you have had the ability to process traffic running through your BIG-IP with an IPS/IDS engine that we call Protocol Inspection. Enabling IDS/IPS on your BIG-IP will allow you to increase your defense-in-depth posture using your existing BIG-IP investment. This is the first article in the series where I will provide background and describe the features and functionality. The following articles will review: Features and functionality Deep dive into features Configurations and best practices Background First, some details explaining the differences and how F5 fits in the puzzle. Intrusion detection systems (IDS) are passive devices that monitor and log events on the network and can be configured to send alerts to an Administrator. These IDSs come in Network IDSs and Host based IDSs. This article will focus on Network based IDSs. Intrusion preventions systems (IPS) on the other hand have response capabilities. The responses range from dropping traffic, resetting the connection or passing the traffic to a sandboxed environment. The terms are used interchangeably, by most, so from now on I will refer to the systems as IDS/IPS. These IDS/IPS devices are usually placed in strategic ingress or egress locations such as security zones, data centers orthe edge of the network to capture and analyze critical traffic. Generally, these systems operate on signatures developed from known attacks or custom rules, protocol analysis and content matching. If your organization is running a BIG-IP, it most likely sits in one of these strategic locations within your network, protecting your most valuable assets. This enables you to take advantage of the built-in functionality of BIG-IP IDS/IPS engine instead of passing off the process to a 3rd party device which adds additional latency. The BIG-IP IDS/IPS capability is delivered as two major features: Protocol Inspection Engine Subscription Service BIG-IP Advanced Firewall Manager and Protocol Inspection BIG-IP’s Advanced Firewall Manager (AFM) is the module that allows you to take advantage of the IDS/IPS feature. When enabled, the Protocol Inspection Engine does both application protocol compliance checks and signature matching. The concept behind protocol match is the following: Drop traffic if it does not conform to protocol standards Drop traffic based on a signature match The versatility of the BIG-IP allows Protocol inspection to be applied as an AFM rule to all contexts (global/route/domain or virtual server) or directly to a virtual server.The beauty of this approach is in the processing of traffic.You can inspect the traffic pre-decryption or post- decryption based on polices, politics, or design. Want to step it up a notch further?Apply it to both an AFM rule and a virtual server. Protocol Inspection offers several features and functionality including the following: Granular Protocol Compliance Checks TCP, SCTP and UDP Signatures Learning and Staging Subscription Service Protocol Inspection and Signature Updates Granular Protocol Compliance Checks At the heart of F5s IDS/IPS is the Protocol Inspection Profile, seen below: After naming the profile, you have all the configuration options available to you. You enable or disable if this profile uses signatures, compliance checks, if will you collect stats for reporting in Application Visibility Reporting (AVR) and what services you are inspecting. We support 30 services currently. When you select one or multiples of services to inspect, you will have the option to see and further refine which signatures are used. Additional configuration selections of Suggestion Properties and Update Settings will be covered in another article. Signatures The F5 signatures are based on a subset of Snort rules syntax. When looking at signatures, you will notice they have been assigned a classification or grouping based on what the exploit is attempting to execute (see below): Additionally, signatures are broken down and grouped into “services” to assist in finding the specific signature you might look for. Drilling even further down into an exploit/signature, you can click the signature name and additional information becomes available. I’d like to call attention to the Last Refreshed date and the Hyperlinks to the References; CVE and Bugtraq ID. The Last Refreshed date indicates when the signature was last modified. Clicking either hyperlink takes you to the related article. Here is an example of the CVE article. Here is an example of the Bugtraq article. Subscription Service When AFM is initially downloaded and installed it comes with a base set of protocol inspections and signatures. In order to take advantage and receive regular timely updates to both the protocol inspection profiles and signatures, you need to add the IPS Subscription Service. Protocol Inspection and Signature Updates AFM allows the ability to manually check for and import updated files when you decide or have time. Or for the easy button, the ability to automatically check, download and deploy updated for updated files. You have the option to select whether to “Download” or “Download and Deploy” and the frequency of updating, daily, weekly or monthly. Additionally, you get visibility into what is available to install and what is available to deploy. . Review the example screenshot below. Summary In this article we discussed the features and functionality of BIG-IP AFMs IDS/IPS, configuration and updates of the Protocol Engine and signatures. In the next article we will look deeper into protocol compliance, inspections and signatures. Appendix Advanced Firewall Manager Datasheet Advanced Firewall Manager Operation Guide AFM Intrusion Prevention Systems
Converting a Snort Rule to an AFM Protocol Inspection Custom Signature
We recently had the opportunity to demonstrate what I consider the most interesting use case for Protocol Inspection custom signatures: adapting existing Snort rules for use in AFM Protocol Inspection. Security company FireEye announced a breach in which the tools used by their red teams to test network and application defenses were stolen. FireEye released Snort rules to identify traffic associated with the command and control of these tools. We ported these Snort rules to AFM Protocol Inspection custom signatures and published them in F5's Guidance.https://devcentral.f5.com/s/articles/F5-SIRT-FireEye-Breach-Guidance The reason I find this such a compelling use case is that most of our customers have day jobs. They are not full-time security researchers who model application protocols and swap inside information with other security researchers as a profession. However, we can leverage the work of those who do have those jobs and adapt the Snort rules they write for use with AFM Protocol Inspection. That's exactly what we've done here and I'll show you the process we used to do it. General Observations First, I want to describe the relationship between a Snort rule and a Protocol Inspection custom signature. Basically, the detection syntax is the same, but everything else is different. Both provide tons of useful meta-data, but how that is provided by the two systems is different. Another thing to think about is preservation of information. I don't want my custom signature to lose any information present in the Snort rule. At a minimum, you will want to record where the custom signature came from. I recommend recording the source of the Snort rule in your custom signature in the references or reference-links fields, and retain anything that might provide a breadcrumb to your incident response, such as the Snort rule's msg , reference , and metadata field contents. If you can preserve the Snort rule'ssid by the use of prefixes or suffixes in the custom signature'sid , that might help an incident responder track down the original Snort rule. I'll show one approach to doing this in my conversion below. The Snort Signature - what we're adapting We'll adapt the following signature, provided by FireEye under a BSD license (see below): alert tcp any $HTTP_PORTS -> any any (msg:"Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]"; flow:from_server,established; content:"{\"meta\":{},\"status\":\"OK\",\"saved\":\"1\",\"starttime\":17656184060,\"id\":\"\",\"vims\":{\"dtc\":\""; sid:25888; rev:1;) Signature Creation walk-through Here's how I built out one Snort rule conversion into a custom signature. We'll go field by field, building out the command and editing as we go. The added or changed sections at each step will be in bold. I put a comparison of Snort rule elements and custom signature fields after the walk-thru if you want details on each step. I have a tmsh session open on the BIG-IP, in the security.protocol-inspection.signature context, and a Snort rule I can cut from to paste into my tmsh session. The first field I need is the custom signature name. I will use the msg field from the Snort rule as the basis for the name . This follows the convention for importing signatures from a file. I copy the Snort rulemsgfield, Backdoor.HTTP.BEACON.[CSBundle MSOffice Server], omitting the starting and ending quotation marks. I need to remove the brackets and remove or replace the spaces to use in the name. My convention is to remove prohibited characters and swap underscore characters for spaces. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server I can use the Snort rule msg unchanged for the description so long as I enclose it in quotes, and since it's in the copy buffer I'll add that field to my command next. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" Now theprotocolfield. This has to take the form of a list enclosed in curly braces. I take it from the protocol specified in the Snort rule's header. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} Now thereferencesand reference-links. I took these from the web page announcing the issue the Snort rules address. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" Now the service, which is a mandatory field. I infer this is http from the Snort rule header section $HTTP_PORTS and the "HTTP" string in the msg. If you do not specify a service, the "other" service is selected for you. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http I derive theidfrom the Snort rulesid25888. I'll prepend a 1 to bring it into the 100000+ range used for custom signatures. Because we have the references filled out, this is not critical. In fact, you could preserve the original Snort rulesidin the documentation section and just let the system assign the next available id number. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 Specifying thedirectioncan reduce log spam and misleading stats. For example, if you are interested in requests for http://mysite.example.com/../../etc/passwd but don't care about 404 errors in response, specify thedirectionto-server. That way only traffic to the server will match. In this case, our Snort rule's direction is to-client, which I infer from the Snort header source port being $HTTP_PORTS. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client Now we get to the good stuff: the sig field. I add sig " to my signature. sig is a container for pcre and content checks, and the container is delimited by UNESCAPED quotation marks. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client sig " I copy the payload detection elements from the Snort rule - all the content and pcre checks - and paste that in. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client sig "content:"{\"meta\":{},\"status\":\"OK\",\"saved\":\"1\",\"starttime\":17656184060,\"id\":\"\",\"vims\":{\"dtc\":\""; I add a double-quote character to the end, to identify the end of the sig field. This should NOT be escaped. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client sig "content:"{\"meta\":{},\"status\":\"OK\",\"saved\":\"1\",\"starttime\":17656184060,\"id\":\"\",\"vims\":{\"dtc\":\"";" I then go through and escape the quotation marks at the beginning and end of every content and pcre check with a backslash. Note I can ignore quotation marks already escaped inside these content and pcre checks. These added backslashes are in red for slightly easier identification. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server4 description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client sig "content:\"{\"meta\":{},\"status\":\"OK\",\"saved\":\"1\",\"starttime\":17656184060,\"id\":\"\",\"vims\":{\"dtc\":\"\";" Now I can hit the 'Enter' key and my custom signature will be added. I can then select and enable it in Protocol Inspection policies. One note: the validation for custom signatures is letting me get away with a lot because I'm using BIG-IP v16.0.0. 14.x will not tolerate a signature definition that includes characters that are used in Snort syntax. It's a good practice to use the hexadecimal representation even in 16x. Here's what that would look like: create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server4 description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client sig "content:\"{|22|meta|22 3a|{},|22|status|22 3a 22|OK|22|,|22|saved|22 3a 22|1|22|,|22|starttime|22 3a|17656184060,|22|id|22 3a 22 22|,|22|vims|22 3a|{|22|dtc|22 3a 22|\";" Copyright 2020 by FireEye, Inc. The 2-Clause BSD License Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. For more information on Protocol Inspection Custom Signatures, see K00322533 Overview of Protocol Inspection Custom SignaturesMitigating log4j (CVE-2021-44228) with AFM Protocol Inspection Custom Signatures
The Log4j vulnerability has drawn a great deal of attention and I won't recap anything that other people have said better than I can. See https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability and https://support.f5.com/csp/article/K59329043 for background. UPDATE: I recommend using these three signatures based on Regular Expressions/PCRE to detect attacks using padding and different character encoding schemes to disguise the attack. The first signature is redundant and limited in its application, but very low in resource use. The second will catch exploit attempts that use a bewildering variety of alternate character encoding schemes, but is resource intensive. The third is a specialty signature that deems any payload with "Base64" together with " $ " and " { " (however encoded) to be suspect. This third signature is cheap to use. Simple, low-impact signature that handles padding between significant characters but not character encoding. Limited capability compared with the next two signatures, but if it matches it saves the effort of attempting to match other signatures. create log4j-pcre sig "content: \"$\"; content: \"{\"; distance: 1; pcre:\"/(\?i)\\$'\?\\{.*\?j.*\?n.*\?d.*\?i.*\?\\:/s\";" description "Apache Log4j attempt" service http documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability" direction to-server references "CVE-2021-44228" See the related article "Using Perl Compatible Regular Expressions (PCR) in Protocol Inspection Custom Signatures" for a detailed breakdown. Complex signature that checks for a variety of encoding types for each of the significant characters. WARNING: may cause a performance hit because we can't use a content check as a pre-filter. create log4j2-encoded sig "pcre:\"/(\\$|(0\?44|([u0]00|x|(%|%25|[u0]00)78|%|[u0]0025|%25)24))/\"; pcre:\"/\\{|(0\?173|([u0]00|x|170|(%|045|%25|[u0]00)78|%|[u0]0025|%25)7b)/i\";distance: 1;pcre:\"/j|b|1[5140]2|([u0]00|x|170|([u0]00|%|045|%25|x)78)|%|045|(([u0]00|%|%25|x)25)[64][a2]/i\";distance: 1; pcre:\"/n|1[15]6|([u0]00|x|170|([u0]00|%|045|%25|x)78)|%|045|(([u0]00|%|%25|x)25)[46]e/i\";distance: 1; pcre:\"/d|1[04]4|([u0]00|x|170|([u0]00|%|045|%25|x)78)|%|045|(([u0]00|%|%25|x)25)[46]4/i\";distance: 1; pcre:\"/i|1[15]1|([u0]00|x|170|([u0]00|%|045|%25|x)78)|%|045|(([u0]00|%|%25|x)25)[46]9/i\";distance: 1;" description "Apache Log4j2 exploitation attempt encoded" service http attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability" direction to-server references "CVE-2021-44228" Simple and low-impact signature to check for attempts using Base64 encoding create log4j2-base64 sig "content:\"Base64\";nocase; pcre:\"/(\\$|(0\?44|([u0]00|x|(%|%25|[u0]00)78|%|[u0]0025|%25)24))/\"; pcre:\"/\\{|(0\?173|([u0]00|x|170|(%|045|%25|[u0]00)78|%|[u0]0025|%25)7b)/i\";distance: 1;" description "Apache Log4j2 exploitation attempt encoded in Base64" service http attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability" direction to-server references "CVE-2021-44228" End of Update. The following signatures are obsolete due to the use of static content patterns. I took some Snort signatures provided by the RSA SOC Prime team, and ported them (with permission) to AFM Protocol Inspection custom signatures. This is similar to an exercise I performed about a year ago in the wake of the Fireeye breach (see https://devcentral.f5.com/s/articles/Converting-a-Snort-Rule-to-an-AFM-Protocol-Inspection-Custom-Signature). Without belaboring the point, here are the signatures. IMPORTANT: these signatures make no attempt to defeat obfuscation attempts. They are simple string matches. To enable them, start a tmsh session and switch to the security > protocol-inspection > signature context. Then paste these 3-4 at a time, depending on the size of your paste buffer: create ET_EXPLOIT_Apache_log4j_RCE_Attempt-http_ldap description "ET EXPLOIT Apache log4j RCE Attempt (http ldap)" sig "content:\"|24 7b|jndi|3a|ldap|3a 2f 2f|\";nocase;" id 2034647 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-http_rmi description "ET EXPLOIT Apache log4j RCE Attempt (http rmi)" sig "content:\"|24 7b|jndi|3a|rmi|3a 2f 2f|\"; nocase;" id 2034648 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-tcp_ldap description "ET EXPLOIT Apache log4j RCE Attempt (tcp ldap)" sig "content:\"|24 7b|jndi|3a|ldap|3a 2f 2f|\"; nocase;" id 2034649 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-tcp_rmi description "ET EXPLOIT Apache log4j RCE Attempt (tcp rmi)" sig "content:\"|24 7b|jndi|3a|rmi|3a 2f 2f|\"; nocase;" id 2034650 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-udp_ldap description "ET EXPLOIT Apache log4j RCE Attempt (udp ldap)" sig "content:\"|24 7b|jndi|3a|ldap|3a 2f 2f|\"; nocase;" id 2034651 protocol {udp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-udp_rmi description "ET EXPLOIT Apache log4j RCE Attempt (udp rmi)" sig "content:\"|24 7b|jndi|3a|rmi|3a 2f 2f|\"; nocase;" id 2034652 protocol {udp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-udp_dns description "ET EXPLOIT Apache log4j RCE Attempt (udp dns)" sig "content:\"|24 7b|jndi|3a|dns|3a 2f 2f|\"; nocase;" id 2034662 protocol {udp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-tcp_dns description "ET EXPLOIT Apache log4j RCE Attempt (tcp dns)" sig "content:\"|24 7b|jndi|3a|dns|3a 2f 2f|\"; nocase;" id 2034660 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-http_dns description "ET EXPLOIT Apache log4j RCE Attempt (http dns)" sig "content:\"|24 7b|jndi|3a|dns|3a 2f 2f|\"; nocase;" id 2034657 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-udp_ldaps description "ET EXPLOIT Apache log4j RCE Attempt (udp ldaps)" sig "content:\"|24 7b|jndi|3a|ldaps|3a 2f 2f|\"; nocase;" id 2034672 protocol {udp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-tcp_ldaps description "ET EXPLOIT Apache log4j RCE Attempt (tcp ldaps)" sig "content:\"|24 7b|jndi|3a|ldaps|3a 2f 2f|\"; nocase;" id 2034670 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-http_ldaps description "ET EXPLOIT Apache log4j RCE Attempt (http ldaps)" sig "content:\"|24 7b|jndi|3a|ldaps|3a 2f 2f|\"; nocase;" id 2034667 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " My thanks to RSA for providing these signatures.High Performance Intrusion Prevention
Overview Utilizing the F5 BIG-IP ability to reliably load balance a high volume of concurrent connections to application services is further improved with integrations with IPS equipment providers. In this article I will articulate details pertaining to how the F5 BIG-IP along with the Cisco/Sourcefire Next Generation Intrusion Prevention System (NGIPS) managed device solutions can be utilized to provide a secure application delivery platform. This platform is secure and provides advanced client / server application monitored visibility. This solution is not limited to just utilizing Cisco/Sourcefire. It can also be extended to other IPS providers. This article will focus on the functional demonstration that we are presenting at the 2014 RSA Conference. The demo that was presented at the 2014 RSA conference is a functional demo. It does not stress the performance bounds of the joint solution. It is meant to demonstrate how the solution is built, monitored, and operated. Solution IPS deployments have limited bandwidth per sensor node. The traffic to be analyzed may require different sized IPS sensors depending on the traffic profiles. With BIG-IP these different traffic profiles can be sent to the properly sized IPS sensor. BIG-IP can also perform SSL offload. Be that as it may, the NGIPS will then inspect the traffic in the clear. Scale-out Flexibility Utilizing the BIG-IP Load Balancing capabilities, IPS inspection bandwidth can be increased by increasing the IPS Sensor node count within the load balanced pool. BIG-IP will load balance the traffic across all nodes within the pool. If sensors need to be serviced, they can be removed from the pool without affecting the end user. Multiple IPS Pools can be configured to address the varying bandwidth needs of your applications. Properly configured, the BIG-IP can selectively choose which traffic flows that will be sent to the IPS pool nodes for inspection. Configuration For the RSA conference we built a functional demonstration to load balance traffic to two Sourcefire NGIPS managed devices. The sensor receives the traffic using the BIG-IP Clone pool capabilities. As traffic patterns match IPS rules, and signatures. The Sourcefire Remediation API communicates to BIG-IP to enforce a denylist on the violating source IPs. To perform these tasks, BIG-IP uses two iRules. The first iRule is the Command iRule. And, the second is the Protection iRule. We will touch upon these aspects in the follow-on dialog. Demonstration Network Topology Overview Network Topologies The flexibility that BIG-IP provides for traffic steering and load balancing allows for multiple ways to deploy the sensors. The sensors can be deployed as transparent in-line devices, Load balanced through Gateway Pools, and Load Balanced as cloned traffic. Leveraging the excellent capabilities and strength of BIG-IP to perform SSL Offload can be implored with either of these deployment topologies. In-Line Transparent The in-line deployment places the NGIPS managed devices in between the BIG-IP and the application servers. We use an interim VLAN to pass the traffic through the NGIPS devices. Health monitoring transparent IPS sensors is challenging. By design these devices do not directly respond to pings or other direct unicasted packets. If a sensor goes offline the remaining sensors will carry on inspecting traffic. In-line Transparent Topology In-Line utilizing Gateway Pools An alternative way to deploy the sensors is to use Gateway Pools. Gateway Pools is a feature that allows traffic forwarding decisions to be performed through a pool of gateways (IP forwarding) devices. BIG-IP has nineteen different load balancing techniques that can be selected. The benefit this brings is that each gateway pool member can be health monitored. And, intelligent node selection based on concurrent connection and performance measurements. The network topology is similar to the in-line transparent setup with the addition of multiple NGIPS managed devices. Each of the NGIPS managed devices are configured with IP addresses. A virtual router is defined in order to address these sensors much in the same was as BIG-IP would forward traffic through a router. Using Clone Pools BIG-IP Clone Pool feature provides the ability to send a copy of traffic to a pool for inspection. The clone pool is directional in the sense the user can decide to just clone the client side traffic, server side traffic, or both. The NGIPS managed devices are on a side VLAN. The benefit this provides is the ability to apply the IPS inspection based on a per Virtual Server basis. This is the topology we chose to demonstrate at the RSA conference. Example Deployment Topology SSL Off-load assists with inspection BIG-IP has a huge capacity to perform SSL Offload. This is the ability for the BIG-IP to decrypt the SSL traffic from the clients in order for the NGIPS managed devices to see the un-encrypted traffic content. Many intrusion inspection devices are un-able to decrypt the SSL traffic, or the performance degradation of enabling SSL decryption severely impacts the overall application performance capabilities. All of the previously mentioned topologies can be deployed with SSL Offload as long as the BIG-IP is not re-encrypting the traffic to the server pools. If this is the case then a sandwich approach can be deployed. Detection and Enforcement IPS Blocking for in-line operation The NGIPS managed devices can be configured to block the offending traffic. This alone will not relieve the individual sensors from continuing to receive more violating traffic. However, the NGIPS signals the offending source IPs to the BIG-IP. The BIG-IP can perform the blocking enforcement on behalf of the intelligence that the NGIPS managed devices had detected. In turn the NGIPS is not burdened with the offensive traffic. Remediation API The Sourcefire NGIPS with Defense Center has a Remediation API that is used to signal the BIG-IP which sources to denylist. The remediation API is coupled with F5 iRule technology to handle the control communications and perform enforcement. The Defense Center communicates with a HTTP Request containing the offending source IP and a time out period. The time out period is the time before the offending source is allowed back in. iRule overview The iRules are utilized to perform both control and enforcement. The first iRule will receive source IP and timeout information from the Sourcefire Defense Center. This information is submitted into an internal data table. The second iRule will perform the enforcement to reject connection requests from the aforementioned source IPs. In turn time passes, and these clients can come back in to the playground. If they play nicely they are allowed to stay. Once, they violate the rule base. These source IPs will be reapplied and maintain an entry within our denylist table and continue to be rejected access. Command iRule The command iRule is applied to a Virtual Server that listens on the IPS VLAN. This virtual has no pool members associated to it. It’s there to catch the HTTP traffic from the Sourcefire Defense Center remediation API. The remediation API will send to the BIG-IP the offending Source IP and a configurable timeout period in seconds when a client trips an IPS rule. This iRule will also log to the ‘/var/log/ltm’ log file that the IP address has been added to the denylist table. when HTTP_REQUEST { if { [URI::query [HTTP::uri] "action"] equals "denylist" } { set blockingIP [URI::query [HTTP::uri] "sip"] set IPtimeout [URI::query [HTTP::uri] "timeout"] table add -subtable "denylist" $blockingIP 1 $IPtimeout HTTP::respond 200 content "$blockingIP added to denylist for $IPtimeout seconds" return } HTTP::respond 200 content "You need to include an ?action query" } Command iRule Enforcement iRule The enforcement iRule is applied to the Application Virtual Servers. The internal table of IP addresses that is maintained by the BIG-IP is queried when a new connection request is initiated. If the initiator is on the denylist the connection request is dropped. The iRule will also log to that the client attempted to access a protected Virtual Server. After sufficient time (timeout period provided by the Remediation API from above) has passed the source IP is removed from the table to allow new connections to be established. As mentioned before if the client trips a blocking rule it will again be rejected. when CLIENT_ACCEPTED { set srcip [IP::remote_addr] if { [table lookup -subtable "denylist" $srcip] != "" } { drop log local0. "Block IP on black list" return } } Enforcement and Protection iRule Management Interface This solution is managed and monitored with both the BIG-IP as well as the Sourcefire Defense Center. The Defense Center Content Explorer is a dashboard with a series of charts reporting traffic content details. BIG-IP Virtual Server and Pool statistics will report the traffic distribution of the NGIPS managed devices. Cisco / Sourcefire Defense Center These graphics are some screen shots of the Defense Center reporting. Context Explorer: Events over time Application Protocol distribution Client Application Information distribution F5 Dashboard: Sensor activity Traffic Overview Dashboard Web Application Traffic Risk BIG-IP Virtual Server and Pool Statistics BIG-IP Statistics show that the IPS Pools members are receiving the clone pool traffic. IPS Pool Statistics Virtual Server Statistics Conclusion Combining BIG-IP with Intrusion Prevention appliances is a very compelling solution. This demonstration was built utilizing the existing product feature sets of our currently released products. The demonstration is a functional representation to show how BIG-IP can load balance traffic to IPS sensors. The flexibility that both products provide, allows for improvements to the overall solution. The iRule code can be added to existing iRules. Utilizing the Sourcefire FireAMP features will extend this solution to also monitor for Malware. If a Server should become compromised Sourcefire will detect that from the Server Clone Pool traffic flows. Technorati Tags: IPS Cisco Sourcefire F5 iRule Security BIG-IP LiveJournal Tags: IPS Cisco Sourcefire F5 iRule Security BIG-IPS Cisco Sourcefire F5 iRule Security BIG-IP
Is it possible to set multiple IPs in the Source IP Address of the advanced ASM Event log search?
Hi, I want to exclude a couple IPs from the event logs I am looking at. I can set the drop down to 'is not' for the Source IP field and enter one IP address, removing this one IP from the event logs I am searching. Is there an operator or something similar that I can use to separate multiple IPs to remove more than one IP from the event logs? Thank You. Kind Regards ChrisOrchestrated Infrastructure Security - Getting Started
Note:TheBeaconcapabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. Introduction A typical daisy-chained security stack is difficult to manage and make changes.All devices in the chain are physically wired to each other in a serial arrangement.Each device performs SSL decryption and re-encryption when needed.All devices in the chain need to have similar performance capabilities.All devices in the chain need to be properly configured to route traffic to their neighboring devices, and likely will need to be manually configured to trust SSL certificates used by neighboring devices for decryption and re-encryption. Failure of any device in the security chain brings the entire chain down.Capacity cannot be increased simply by adding another like-device (i.e. a NGFW) to the chain.Capacity can only be increased by replacing a single device with a higher capacity device. Removing or adding a device to the chain is problematic.For one, the entire security stack will need to be unavailable while removing or adding a device.Proper routing between devices must be maintained or the whole chain will not pass traffic.Certificate trust and other factors may need to be addressed as well. High availability is also problematic.The only way to ensure high availability is to create another daisy-chain, identical to the first.This chain needs to wait in standby mode until the primary chain fails or is taken down, and then the standby chain can take over for the primary. Managing a single daisy chain security stack is not easy.Managing two for high availability is significantly more complicated and overly expensive. Some security devices are deployed differently and cannot operate together in the security stack.Those devices would need their own separate deployment from the devices in the daisy chain, further complicating the configuration.As an example, it’s not an uncommon security practice to employ network TAP devices, explicit proxies, ICAP servers as well as Layer2/3 devices. All of these devices cannot be configured to properly route traffic in a daisy chain. SSL Orchestrator solves almost all of these challenges, and enables you to have a nimble security solution capable of adapting to almost any type of threat. High Level Network Topology The network topology used for this setup is below.BIG-IP-11 and 12 are deployed in Layer 2 mode. The Advanced WAF and AFM devices will also be deployed in Layer 2 and will be physically wired to the SSL Orchestrators.This is a high availability environment where there is one Active BIG-IP and one ready on Standby.The Port Objects (511 & 512) allow traffic to flow through either BIG-IP, in case of a failure.The applications being protected are represented by the Ubuntu servers connected to the South switch. BIG-IP Network Topology A zoomed in view of the BIG-IP devices is below.This shows the physical connectivity and the specific interfaces used by SSL Orchestrator, Advanced WAF and AFM devices. Summary This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM.It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. Next Steps Click Next to proceed to the next article in the series.Orchestrated Infrastructure Security - Protocol Inspection with AFM
The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. Introduction This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM.It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here. This article focuses on configuring Protocol Inspection (IPS) with AFM deployed as a Layer 2 solution. It covers the configuration of Protocol Inspection on an F5 BIG-IP running version 16.0.0. Configuration of BIG-IP deployed as AFM can be downloaded from here from GitLab. Please forgive me for using SSL and TLS interchangeably in this article. This article is divided into the following high level sections: Protocol Inspection (IPS) with AFM Network Configuration Create an AFM Protocol Inspection Policy Attach Virtual Servers to an AFM Protocol Inspection Policy Protocol Inspection (IPS) with AFM: Network Configuration The BIG-IP will be deployed with VLAN Groups.This combines 2 interfaces to act as an L2 bridge where data flows into one interface and is passed out the other interface. From the F5 Configuration Utility go to Network > VLANs.Click Create on the right. Give it a name, ingress1 in this example.Set the Interface to 5.0.Set Tagging to Untagged then click Add.Interface 5.0 (untagged) should be visible like in the image below.Click Repeat at the bottom to create another VLAN. Note: In this example interface 5.0 will receive decrypted traffic from sslo1. Give it a name, egress1 in this example.Set the Interface to 6.0.Set Tagging to Untagged then click Add.Interface 6.0 (untagged) should be visible like in the image below.Click Finished when done. Note: In this example interface 6.0 will receive decrypted traffic from sslo1. Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators.Therefore, you should repeat these steps to configure VLANs for the two interfaces connected to sslo2.These VLANs should be named in a way that you can differentiate them from the others.Example: ingress2 and egress2 It should look something like this when done: Note: In this example Interface 3.0 and 4.0 are physically connected to sslo2. Click VLAN Groups then Create on the right. Give it a name, vlg1 in this example.Move ingress1 and egress1 from Available to Members.Set the Transparency Mode to Transparent.Check the box to Bridge All Traffic then click Finished. Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators. Therefore, you should repeat these steps to configure a VLAN Group for the two interfaces connected to sslo2.This VLAN Group should be named in a way that you can differentiate it from the other, example: vlg1 and vlg2.It should look like the image below: For full Layer 2 transparency the following CLI option needs to be enabled: (tmos)# modify sys db connection.vgl2transparent value enable Create an AFM Protocol Inspection Policy You can skip this step if you already have an AFM Protocol Inspection policy created and attached to one or more virtual servers.If not, we’ll cover it briefly.In this example we configured Protocol Inspection with Signatures and Compliance enabled. From Security select Protocol Security > Inspection Profiles > Add > New. Give it a name, IPS in this example.For Services, select the Protocol(s) you want to inspect, HTTP in this example. Optionally check the box to enable automatic updates and click Commit Changes to System. Attach Virtual Servers to an AFM Protocol Inspection Policy Attach the Protocol Inspection Profile to the Virtual Server(s) you wish to protect.From Local Traffic select Virtual Servers.Click the name of the Virtual Server you want to apply the profile to, 10.4.11.52 in this example. Click Security > Policies. Set the Protocol Inspection Profile to Enabled, then select the Profile created previously, IPS in this example.Click Update when done. Repeat this process to attach the IPS Profile to the remaining Virtual Servers. Summary In this article you learned how to configure BIG-IP in layer 2 transparency mode using VLAN groups.We also covered how to create an AFM Protocol Inspection policy and attach it to your Virtual Servers. Next Steps Click Next to proceed to the next article in the series.Orchestrated Infrastructure Security - Guided Configuration
The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. Introduction This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM.It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here. This article focuses on configuring SSL Orchestrator to decrypt inbound SSL and pass the decrypted content to F5 Advanced WAF and Protocol Inspection (IPS) with AFM for enhanced protection from threats.It covers the configuration of the SSL Orchestrator Topology, Services and more on an F5 BIG-IP running version 15.1.0.4 and SSL Orchestrator version 7.4.9. Configuration of BIG-IP deployed as SSL Orchestrator can be downloaded from here from GitLab. Please forgive me for using SSL and TLS interchangeably in this article. In this article we will walk you through the SSL Orchestrator Guided Configuration which covers the following: Inbound L2 Topology creation Certificate and Key used for SSL Decryption Adding the Advanced WAF and AFM devices Creating a Security Policy Creating an Interception Policy SSL Orchestrator Guided Configuration From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration from the menu on the left. Note: There are Required Configuration options on the right you may need to configure.A Route is not needed when SSL Orchestrator is deployed in Layer 2 mode. The Configuration screen presents all of the configuration options that are available.Scroll to the bottom of the page and click Next. Give the Topology a name, InboundAppProtection in this example.You can optionally configure the Protocol and IP Family you want the Topology to support.We’re using the default of TCP and IPv4.Select L2 Inbound and click Save & Next. Configure the Certificate Key Chain by clicking the Pencil icon on the right. Choose the correct Certificate and Key from the drop menu.In this example we use subrsa.f5labs.com for the Certificate and Key.Click Done. There are Server-side SSL settings that you can optionally configure.Click Save & Next. On the next screen click Add Service. Scroll to the bottom, select Generic Inline Layer 2 and then Add. Give it a name, Advanced_WAF in this example.Under Network Configuration click Add. Here we create the VLANs & select the Interfaces the Advanced WAF devices are connected to.For the From and To VLAN options select Create New.Give them a unique name, egress_WAF1 and ingress_WAF1 in this example.Select the interfaces connected to the first WAF device, 4.1 and 4.2 in this example. Then click Done. Repeat this process for the 2 nd Advanced WAF device using interfaces 4.3 and 4.4.It should look like this when done. Note: In this case the SSL Orchestrator interfaces 4.1 and 4.2 are connected to Advanced WAF1 interfaces 2.1 and 2.2.SSL Orchestrator interfaces 4.3 and 4.4 are connected to Advanced WAF2 interfaces 2.3 and 2.4. You can optionally configure the Device Monitor and Service Down Action.Enable the Port Remap option and click Save. Click Add Service to add the AFM devices. Scroll to the bottom, select Generic Inline Layer 2 and then Add. Give it a name, AFM in this example.Under Network Configuration click Add. Here we create the VLANs & select the Interfaces the AFM devices are connected to.For the From and To VLAN options select Create New.Give them a unique name, egress_AFM1 and ingress_AFM1 in this example.Select the interfaces connected to the first AFM device, 5.1 and 5.2 in this example.Then click Done. Repeat this process for the 2 nd AFM device using interfaces 5.3 and 5.4.It should look like this when done. Note: In this case the SSL Orchestrator interfaces 5.1 and 5.2 are connected to AFM1 interfaces 5.0 and 6.0.SSL Orchestrator interfaces 5.3 and 5.4 are connected to AFM2 interfaces 5.0 and 6.0. You can optionally configure the Device Monitor and Service Down Action.Enable the Port Remap option and click Save. Click Save & Next at the bottom. Click Add to create the Service Chain. Give it a name, Inbound_Protect1 in this example.Select ssloS_AFM and ssloS_Advanced_WAF Services then click the arrow to move them to the right.Click Save. Note: It is recommended that AFM be placed first in the Service Chain Order.That way intrusion attempts are detected and blocked before they ever get to the Advanced WAF.This saves resources on the Advanced WAFs because they don’t have to process any of the attempted intrusion connections. Click Save & Next. For the Security Policy click the Pencil icon on the lower right to edit the rule. Set the Service Chain to the one created previously.Click OK. Click Save & Next at the bottom. For the Interception Rule, define the Destination Address or subnet of the application servers you wish to protect.In this example the application servers are all in the 10.4.1.0/24 subnet.Specify the correct port, typically 443. For the Ingress Network select the VLAN(s) that will be receiving traffic from external users, Direct_all in this example.Set the L7 Profile to http.Click Save & Next. Make any changes to the Log Settings if needed.Click Save & Next. On the Summary screen you can review and change any of the settings.Click Deploy when ready. You should get a Success message. If you receive an error you will need to go back into the configuration to resolve it.If successful, you should see a screen like this: Notice the Service Health status is indicated by the small green circle. Summary In this article you learned how to use the SSL Orchestrator Guided Configuration to create a Topology, select the certificate and key used for SSL Decryption, add the Advanced WAF and AFM devices, create a Security Policy and an Interception Policy. Next Steps Click Next to proceed to the next article in the series.
SSLO routing error
Hi guys, Whenever I try to run the SSLO with the services I always get the request back from my servers but if I add the services in the service chain it's not pushing thru. The devices are reachable with the corresponding interfaces, but I really can't seem to route and inspect the traffic from the services. Any ideas on how to fix this? Are there particular configurations that should be made first with my IPS to route the incoming traffic to the outgoing interface? I'm really lost on this one.F5 Synthesis: Hardening Security through Programmability in the Network
#IPS #Infosec #F5 #SDAS Despite claims that there exists (or will, look out!) a mythical "god box" for the enterprise data center, capable of performing every data center function imaginable, it remains, well, mythical. Efforts to effectively secure the data center and the applications it delivers therefore requires a collaborative approach between best-of-breed technologies. But if collaboration across functional IT groups - development, operations, network and security - remains as elusive as nirvana, then collaboration across products has traditionally been seen as likely as sighting the Loch Ness Monster. The arrival of cloud and more recently SDN has changed that, not only encouraging but requiring changes in collaboration capabilities in order to remain considered best-of-breed. And thus we are blessed with being able to witness the dawn of the age of network programmability. Promises abound, but real benefits - and implementations - are often hard to find. And if you go looking for examples in the realm of security, you're going to scrounge even harder to find real examples of just how programmability is going to change the game. Look no further, my friend, for an excellent example can be found here, today, in this post. Hardened Security and Performance Can Coexist with F5 and Sourcefire For those of you not familiar with Sourcefire, the recently-acquired-by-Cisco security provider offers two industry leading products: Sourcefire Next Generation IPS (NGIPS) and the FirePOWER Platform. The former provides advanced threat protection, integrating real-time context, intelligent security policy automation and unprecedented performance. Sourcefire NGIPS takes advantage of the best hardware technology in the industry, providing IPS inspected throughput options ranging from 50Mbps to 40+Gbps, providing market- leading performance with greater energy efficiency. Together, F5 and Sourcefire have validated a deployment architecture that help customers secure critical networks, applications and end-points while achieving optimal performance. This architecture results in a remediation capability that allows critical security events such as malware (FireAMP) and IPS/IDS events to initiate rule configuration for F5 security services, leveraging both the data and control plane programmability interfaces of F5 Synthesis Software Defined Application Services (SDAS). . F5 Security Services for NGIPS Design The integration between Sourcefire NGIPS and F5 Synthesis High Performance Services Fabric (HPSF) is enabled through F5's open API, iControl, and its data path programmatic interface, iRules. Because of its topological location in most application architectures, F5 HPSF maintains a strategic point of control. This means all application requests are fielded by F5 Software Defined Application Services (SDAS) such as availability, security and identity and access control. As requests are received, they are first pre-screened for DDoS attacks by F5 SDAS. Then, depending on the policy, the requests are load balanced to a pool of Sourcefire sensors. If the requests are determined to be clean and safe, they are routed back through F5 SDAS and on to the appropriate application. Sourcefire leverages a correlation rules engine that allows a variety of actions in response to security events. Rules can be very simple or be more powerful by including multiple conditions and qualifiers. Actions include the ability automatically configure rules for F5 security services, such as blocking a device that is originating an attack, or exhibiting some other form of suspicious or unwanted behavior. Event types supported by the remediation engine include: IPS Events FireAMP (malware) Events Compliance Events Connection Events Thus, if the Sourcefire sensors detect a problem, they can initiate action using F5's control plane API, iControl, to inject an iRule into the data path that will block the IP address of the client sending the requests. This kind of integration enables a best-of-breed architectural approach to protecting both the network and the applications it is tasked with delivering. It enables the intelligence of a next-generation IPS to detect anomalies and attacks to be leveraged strategically to defend against and prevent the impact of the advanced threats that have become more and more pervasive. By enabling immediate remediation actions by programmatically updating F5 security services upon detection of a problem, the entire data center ecosystem is better protected, without compromising on performance. Additional Resources: F5 Synthesis Cisco Sourcefire
