ICAP server reachable, however ASM claims communication issues
Greetings, I have encountered a situation where I have implemented basic AV protection to a server. Tests with EICAR file work fine from internal and external networks (should not really matter). The thing is that on some occasions I noticed that the file upload had been blocked but the Virus violation states: "Virus detection was not performed due to communication problem. See details here: /ts/log/bd.log" There is no relevant info in that log file. Guaranteed enforcement was turned on, so I guess that's why the block took place. But the real question is - why is it complaining about not being able to communicate with the ICAP server? When I run a test from any network, it blocks it just right and the violation is described accurately. Whenever this has happened there have been multiple generic violations detected with the traffic as well, but ONLY AV protection is in Blocking mode - generic signatures are just alerting for analysis. Does anyone have more experience with such cases? Any ideas why this is happening? Thank you!
ASM Custom Violation for ICAP Scanning
Hello Folks, I recently started building ICAP AV Scanning configurations on F5 LTM. Looks like most of it is pretty easy to configure following some docs on support site. But the blocker is, i'm trying to Raise a violation using iRules and ASM custom violations. Please see iRule below when ADAPT_REQUEST_RESULT { log local0. "ICAP response is [ADAPT::result]" if { ! ([ADAPT::result] contains "modify") } { set icap_blocked 1 ADAPT::result bypass } else { set icap_blocked 0 } } when ASM_REQUEST_DONE { if { [info exists icap_blocked] && $icap_blocked == 1 } { ASM::raise ICAP log local0. "Raising custom ASM Violation." set icap_blocked 0 } } So far, scanning the files and allowing or blocking the request is working just fine. When it comes to raising a custom violation to the user when a malicious file is uploaded, i'm not seeing any response pages i set on ASM. Please see the procedure below: 1.Configured AV Scanning following the document(link above) 2.Created a security Policy on ASM with Blocking enforcement mode(Security->Application Security->Security Policies) 3.Created a custom violation under Security->Options->Application security -> Advanced Configuration -> Violation list->User-Defined Violations->create. See below Now, Created a blocking response page under Security->Application Security->Blocking->Response Pages See below Response Headers: HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Connection: close Response Body: Request RejectedThe requested URL was rejected. Please consult with your administrator. Your support ID is: <%TS.request.ID()%> After assigning iRule to the ICAP Virtual server, I uploaded a virus file from a web portal that points to ICAP Virtual IP, and its being blocked. But i'm not seeing the response page i created. Any help is much appreciated! Thanks I know this is too much information. Just thought it would help someone in future . I appreciate your patience 🙂
ADAPT::enable not valid in context of HTTP_REQUEST_DATA
Hi, I'm writing an iRule to pass HTTP POSTs selectively through an ICAP proxy. Using the ADAPT::enable request <0|1> works fine in the context of HTTP_REQUEST as described in a couple of threads. As I'm parsing a multipart upload (potentially consisting of multiple files) for specific files (based on the file extension and announced Content-Type; information can be found in the payload only and is not part of the request headers) I have to use HTTP::collect first. Finally I want to decide in the context of HTTP_REQUEST_DATA to bypass the ICAP or not. Unfortunately the ADAPT::enable request <0|1> is not permitted in this context: [command is not valid in current event context (HTTP_REQUEST_DATA)][ADAPT::enable request 1] (I have tried both TMOS v11.5.4HF2 and TMOS v12.1.1HF1 resulting in the same error message.) Any idea how to get this fixed? Using a second virtual server might be an option. (Btw, there is already a virtual server in front of it to terminate SSL as I have to use TCP::respond to return 100 Continue interim responses for the incoming POSTs.) Collecting all POST data on TCP level and doing the analytics in context of CLIENT_DATA might be another option. Thanks in advance for your ideas, Cheers, Stephan
Custom HTML page for ASM Virus Detection - ICAP
Hello Folks, One of customers is using KasperSky Proxy server as an ICAP integration with ASM. (Running on 11.3.0 HF8). Which is working well, and ICAP is detecting malicious and legitimate file well. Now the requirement comes as to display a custom HTML page when ASM detects a Virus based on ICAP confirmation. I have tried creating an iRule by taking help from DecCentral, and made something as following. when ASM_REQUEST_BLOCKING { set x [ASM::violation_data] for {set i 0} { $i < 7 } {incr i} { switch $i { 0 { log local0. "violation=[lindex $x $i]" } 1 { log local0. "support_id=[lindex $x $i]" } 2 { log local0. "web_application=[lindex $x $i]" } 3 { log local0. "severity=[lindex $x $i]" } 4 { log local0. "source_ip=[lindex $x $i]" } 5 { log local0. "attack_type=[lindex $x $i]" } 6 { log local0. "request_status=[lindex $x $i]" } }} if {([lindex $x 5] contains "ATTACK_TYPE_MALICIOUS_FILE_UPLOAD")} { HTTP::header remove Content-Length HTTP::header insert header_1 value_1 set response "Apology PageWe are sorry,\ but the site you are looking for is temporarily out of service\ If you feel you have reached this page in error, please try again." ASM::payload replace 0 [ASM::payload length] "" ASM::payload replace 0 0 $response } } However it seems that iRule is not triggering at all. Any idea what I am missing here? Thank you, Darshan
ASM: insert header when a virus is found
Hello, I tried to configure a iRule to add a HTTP header in the POST request which uploads a file to an origin server. This HTTP header should contain the ASM support ID only when there is a virus detected via ICAP, but it should NOT block the client request. I also configured in ASM policy "Trigger ASM iRule Events" in Normal Mode. I am using 12.1.2. Do you have an idea? I tried this but the HTTP header is not inserted (but i get a log message that the virus was found... Feb 26 17:48:38 bigip info tmm[23970]: Rule /Common/AV : VIOLATION_VIRUS_DETECTED detected, uri=/virus.php) when ASM_REQUEST_VIOLATION { if {([ASM::violation_data] contains "VIOLATION_VIRUS_DETECTED")} { log local0. "VIOLATION_VIRUS_DETECTED detected, uri=[HTTP::uri]" set supp_id [ASM::support_id] } } when HTTP_REQUEST_RELEASE { if {[info exists supp_id]} { HTTP::header insert X-ASM-SUPPORT-ID "VIRUS DETECTEED and support ID $supp_id" } }
F5 ASM with fortisandbox
Hi i want to integrate f5 ASM with fortisandbox as a icap server for file upload inspection i found this articalehttps://support.f5.com/csp/article/K70941653 butValue of virus_header_name for fortisandbox is not mentioned any one has experince of integration with fortisandbox. please let me know if anyone knowvirus_header_name for fortisandboxASM and OPSWAT Metadefender Blank Page after file upload
Hi, I am trying to integrate F5 ASM WAF with OPSWAT metadefender but when I try and upload and EICAR file browser just shows a blank white page. I am using a default security policy in blocking mode and have configured the settings according to the F5 BIG IP ASM (WAF) OPSAWT guide. I have configured the ICAP server under Security>Options>Application Security>Integrated Services>Anti-Virus Protection. I have configured the antivirus block settings under Security>Application Security>Policy Building>Learning and Blocking Settings>Advanced Configuration. I have antivirus scanning for HTTP file uploads and SOAP attachments Security>Application Security>Integrated Services>Anti-Virus Protection. When I try to upload the test file I get a blank browser and if I check the source code in the browser I see the following: window["bobcmn"] = "101110101010102000000022ffffffff2ffffffff20000000220156c0ea200000000200000000200000000300000044multipart%2fform%2ddata%3b%20boundary%3d%2d%2d%2d%2dWebKitFormBounda300000000300000000300000000300000000300000007httpsc3000000b008a59e5661ab20000adb568196d38950bf7928e988d64266cafbda4956605335d523cb0c44e211db089aede8158b2800a5d271c7e2a6f9d94d8c4ad7cd49022d5f72b236f5ca5943b07c111a9484727f3b29e542d2d2302b300000002TS300000165%2d%2d%2d%2d%2d%2dWebKitFormBoundaryxbm3Qt79jKjmxoOz Content%2dDisposition%3a%20form%2ddata%3b%20name%3d%22filename%22%3b%20filename%3d%22eicar.com%22 Content%2dType%3a%20application%2foctet%2dstream X5O!P%25@AP[4%5cPZX54(P%5e)7CC)7}%24EICAR%2dSTANDARD%2dANTIVIRUS%2dTEST%2dFILE!%24H%2bH%2a %2d%2d%2d%2d%2d%2dWebKitFormBoundaryxbm3Qt79jKjmxoOz%2d%2d 200000000"; "</script> </APM_DO_NOT_TOUCH> <script type="text/javascript" src="/TSbd/08a59e5661ab2000a21cb91986bc897b6b354965ec350caba4c8ca55a7b089798844a4727e8dc553?type=5"></script><noscript>Please enable JavaScript to view the page content.<br/>Your support ID is:8648386876400468880.</noscript> </head><body> </body></html>" Is there something in the ASM policy that needs to be changed?
Modify HTTP response from ICAP server on BigIP
Hi all, I'm facing the following problem with an ICAP setup: What we want is AV scanning of file uploads to a web page using ICAP on the BigIP. This is done by using a request adapt profile in conjunction with an internal virtual with ICAP profile. We want all POST requests to a specific upload path to be sent to an ICAP server that performs AV scanning. When finding an infected upload, the ICAP server will respond with an ICAP result "respond" (instead of "modify") and return an http 403 error page (we cannot change that behaviour). The upload (POST request) will not reach the webserver in that case. Up to that point, we could get all of this working properly. Unfortunately, the client application (third party product) will throw an unexpected and undefined error upon receiving an http 403 status code. In order to display a meaningful error message to the end user, the application expects an http status code 901 instead. As already mentioned, we can neither change the http 403 error returned by the ICAP server (third party product), nor the need/expectation for an http 901 status by the web application (also third party product). Hence, we plan to rewrite the http 403 reply (of the ICAP server) into an http 901 status on the bigip, resulting in the following setup: click here I tried to address this issue with the following iRule: when HTTP_REQUEST { if { [HTTP::uri] starts_with "/some/path/to/file/uploads" } { log local0. "Upload detected - activating ICAP" ADAPT::enable request true set icap_enabled 1 set icap_respond 0 } else { ADAPT::enable request false set icap_enabled 0 set icap_respond 0 } } when ADAPT_REQUEST_RESULT { set result [ADAPT::result] log local0. "ICAP RESULT received. Result: $result" if { $result == "respond" } { set icap_respond 1 log local0. "ICAP MATCH respond" } } when HTTP_RESPONSE { if { $icap_enabled == 1 } { if { $icap_respond == 1 } { HTTP::respond 901 log local0. "Upload ICAP response detected - sending http 901 to client." } } } Unfortunately, this does not work, since the HTTP_RESPONSE event will not be triggered by the ICAP response, because it is not coming from a server as the wiki page states: HTTP_RESPONSE is specific to a server response passing through the load balancer, and is not triggered for locally-generated responses HTTP_RESPONSE_RELEASE is also not a suitable event, because it does not allow HTTP::respond actions. Trying to do the HTTP::respond action within the ADAPT_REQUEST_RESULT event block will result in TCL errors during execution and break down the whole virtual. Does anybody have ideas on how to address this issue properly? I'm running out of ideas. Many thanks in advance! Martin
SharePoint 2016 large file upload and LTM ICAP configuration
Hi Guys, I have a special case here: Configuration: BigIP Version 13 HTTPS VS (SharePoint Web App with adapt request/response profiles) ICAP VS (Internal with an icap profile) ICAP sever Bluecoat ProxySG with a Symantec scan engine What's happening: When I upload a file with a size less than 100 MB SharePoint upload page sends the file to the SharePoint server in a single block with the header content-type mutilpart. LTM ICAP client sends the file to the ICAP Server (bluecoat) and the file gets scanned and we get back a response according to what we expect. Pass if clean and block is virus detected. Now if I upload a file bigger the 100 MB SharePoint switches to REST API mode and sends the file in multiple chunks of 8MB. The LTM ICAP client sends the files to the ICAP server (bluecoat) and the files get scanned and we get a response for the all the files scanned BUT the answer is always 'file is CLEAN' even if we test with a 110 MB zip file containing an eicar file or multiple eicar files or even a pack or 500MB of real deadly viruses :-) SharePoint sends the file chunks in a JSON payload with the header ACCPET: application/json Anyone managed to make file uploads bigger than 100MB scannable with this type of setup? Any configuration steps I'm missing to make the 110MB zip file scannable when it arrives in small chunks on the ICAP server. I understand that this might be an issue with the ICAP server but I want to rule out the LTM configuration. We are talking to talking to Broadcom/Symantec too. It will not be possible to do anything on the SharePoint side unfortunately since this is the preferred method of uploading large files.F5 SSL Orchestrator and McAfee DLP Solution for SSL Visibility and Content Adaptation
Data transiting between clients (e.g. PCs, tablets, phones, etc.) and servers is predominantly encrypted with Secure Socket Layer (SSL) or the newer Transport Layer Security (TLS) (For reference, see the 2019 TLS Telemetry Report Summary from F5 Labs). Pervasive encryption results in threats being hidden and invisible to security inspection unless traffic is decrypted. This creates serious risks, leaving organizations vulnerable to costly data breaches and loss of intellectual property. An integrated F5® SSL Orchestrator™ and McAfee Data Loss Prevention (DLP) solution solves this SSL/TLS challenge across cloud, mobile, and on-premises environments. SSL Orchestrator centralizes SSL inspection throughout the complex security architectures, providing high-performance decryption of web traffic for security services like McAfee DLP to detect and block data breaches hidden by encryption. This joint solution thus eliminates the blind spots introduced by SSL and closes any opportunity for attackers. Solution Overview F5 SSL Orchestrator, deployed inline to the wire traffic, intercepts any outbound secure web request and establishes two separate SSL connections, one each with the client (the user device) and the requested web server. This creates a decryption zone between the client and the server for inspection. Within the inspection zone, both unencrypted HTTP and decrypted HTTPS requests are encapsulated within Internet Content Adaptation Protocol (ICAP, RFC3507) and steered to the McAfee DLP systems for inspection and possible request modification (REQMOD). In this context, SSL Orchestrator is the ICAP client and McAfee DLP is the ICAP server. After inspection, user HTTPS requests are re-encrypted by SSL Orchestrator, on their way to the web server. The same process of decryption, inspection, and re-encryption takes place for the return response from the web server to the client. Bill of Materials F5 SSL Orchestrator 16.0 Optional functional add-ons include URL filtering subscription, IP intelligence subscription and network hardwaresecurity module (HSM) McAfee Data Loss Prevention 11.4 Pre-requisites F5 SSL Orchestrator is licensed and set up with internal and external VLANs, and self-IP addresses. An SSL certificate—preferably a subordinate certificate authority (CA)—and private key are imported into SSL Orchestrator. The CA certificate chain with root certificate is imported into the client browser. Solution Configuration Steps The solution deployment involves policy creation on McAfee DLP and configuration of SSL Orchestrator on the F5 system. I. Configure DLP Policy Log in to the McAfee ePolicy Orchestrator [ePO] system and create a rule set to block PII related violations and assign it to a DLP policy. II. Deploy SSL Orchestrator using Guided Configuration The SSL Orchestrator guided configuration presents a completely new and streamlined user experience. This workflow-based architecture provides guided configuration steps tailored to a selected topology. Step 1: Topology Properties SSL Orchestrator creates discreet configurations based on the selected topology. Selecting explicit forward proxy topology (as shown in the example) will create an explicit proxy listener. Step 2: SSL Configuration Select the previously imported subordinate CA certificate (see Prerequisites, above) for signing and issuing certificates to the end-host for client-requested HTTPS websites that are intercepted by SSL Orchestrator. Step 3: Create the McAfee DLP ICAP Service The services list section defines the security services that interact with SSL Orchestrator. The guided configuration includes a services catalog that contains common product integrations. In the service catalog, double click the McAfee DLP ICAP service and configure the service settings: McAfee DLP IP address, port, URI paths and preview maximum length. Using the service catalog, create additional security services as required before proceeding to the next step. Step 4: Service Chains Create a service chain, which is an arbitrarily ordered lists of security devices. The service chain determines which services receive decrypted traffic. Step 5: Security Policy SSL Orchestrator’s guided configuration presents an intuitive rule-based, drag-and-drop user interface for the definition of security policies. In the background, SSL Orchestrator maintains these security policies as visual per-request policies. If traffic processing is required that exceeds the capabilities of the rule-based user interface, the underlying per-request policy can be managed directly. Use this section to create custom rules as required. Step 6: Intercept Rule Interception rules are based on the selected topology and define the listeners (analogous to BIG-IP Local Traffic Manager virtual servers) that accept and process different types of traffic, such as TCP, UDP, or other. The resulting listeners will bind the SSL settings, VLANs, IPs, and security policies created in the topology workflow. Step 7: Egress Settings The egress settings section defines topology-specific egress characteristics like NAT and outbound route. Step 8: Summary Review the setting and click deploy SSL Orchestrator. III. Verification Open browser and navigate to https:///dlptest.com (DLPTest.com is a DLP testing resource that focuses on testing to make sure your DLP software is working correctly).In the HTTPS Post section, input some PII data In the text box (an example of PII data is ‘ABC Smith, 123-45-6789, 123 Main St, Seattle WA 98008’) and click on the Submit button.You will see the ‘Access Denied’ message in the response. The DLP Incident Manager web page reports the PII violation. Additional Resources Learn more about SSL Orchestrator on f5.com Recommended best practices guide: F5 SSL Orchestrator and McAfee DLP solution
