Catch, Clean, and Release: File Sanitization with F5 and OPSWAT
In today’s hyper-connected business environment, organizations rely heavily on the constant exchange of digital documents, yet did you know over 90% of malware continues to be delivered through seemingly harmless file attachments and downloads. Traditional security tools, such as antivirus scanners and sandboxes, struggle to keep pace because they rely on recognizing known malware signatures or observing suspicious behaviors. As sophisticated attackers increasingly leverage zero-day exploits and polymorphic malware, IT security teams are left vulnerable to threats that have never been seen before, creating an urgent need for a more proactive defense. Content Disarm and Reconstruction (CDR) addresses this gap by shifting the security paradigm from "detection" to "prevention". Instead of wasting critical time trying to determine if a file is malicious, CDR assumes all incoming files are untrustworthy, strips out potentially hazardous components (such as macros, embedded scripts, or active code), and rebuilds a perfectly safe, fully functional copy for the end-user. This proactive sanitization allows organizations to neutralize file-borne threats instantly, eliminating the business disruption of traditional sandboxing delays and ensuring uninterrupted workflow productivity. The "why" part of this solution is needed is fairly obvious now, but the question of "how" remains. This is where the coupling of F5 BIG-IP and OPSWAT Deep CDR™ from OPSWAT's MetaDefender platform offers a quick and easy on ramp to these modern protections. Disarm threats on the fly: Integrating F5 BIG-IP with OPSWAT Deep CDR via ICAP The solution discussed was staged in a lab using real files. It is very flexible, it could leverage ICAP from the standard LTM module of BIG-IP but can also similarly integrate with the Advanced WAF (AWAF) or SSL Orchestrator modules too. Any file traversing the BIG-IP can be directed to the OPSWAT solution for reconstruction, including a topology such as a forward proxy thus offering a cleansing service for employee files egressing a corporate environment. In all likelihood, the most prevalent use case would be in a reverse proxy scenario, where external fileware is being uploaded to a web service. The intent is to provide ironclad shielding from risks embedded into files that are being ingested into a managed network. Of course, all of the existing tried and true features of the BIG-IP remain, for instance this protected web server could consist of a dozen or more intelligently load balanced nodes. The two particular concerns in today’s threat landscape are: Evolving Malware - Modern malware bypasses standard detection using zero-day exploits and polymorphic code Weaponized Documents - A majority of threats enter networks hidden inside benign-looking PDFs, Office docs, and image files The solution from CDR is encapsulated in the following infographic. The BIG-IP is tailor-made to steer fileware to OPSWAT Deep CDR as SSL/TLS interception is a foundational and high-performance attribute of the F5 reverse proxy. In fact, the intercepted files can in turn be provided to MetaDefender via standard ICAP or a secure TLS-based ICAP. Quick first test – scrub images to thwart steganographic attacks A first example, setup in a lab environment, was to cleanse images uploaded to a sample web server dropbox. Think of perhaps a use case of an insurance portal where scanned images are required to corroborate claims. The art of steganography, richly detailed here, is the practice of hiding data inside another file (such as an image, audio file, video, or document) so that the existence of the hidden data is not obvious. Images are made up of millions of pixels, and each pixel contains numerical color values (Red, Green, Blue). A very common technique is called Least Significant Bit (LSB) embedding, simply utilize the last bit to hide a message, message could be an AI prompt or perhaps code, and the human eye will never pick up on the fact that the image has been ever so slightly altered. One pixel stores a tiny piece of the secret message and millions of pixels cleverly used together store the entire message. Normally a PNG or JPEG containing hidden data does not automatically execute code merely because an application opened it, or a staff member simply viewed it. Another component such as a loader, script, vulnerable application, or a browser exploit must extract and use the hidden content. Our task is to subvert the delivery of the instructions and mute the threat. Using one of many available services on-line, a sample image was used to carry a test message via LSB steganography. A companion tool then takes the image file and displays the embedded, hidden message. Our lab deployment is quite simple, as we will upload the above file to a simulated “Resume Upload” dropbox, a typical use case for human resources departments. We see the graphical interface users are presented with when uploading resumes, it is a simple PHP setup based upon NGINX web server. As noted, the graphical image with the steganographic message has been uploaded and recreated by OPSWAT. The test is now to check the recreated file to see if the embedded message has been successfully removed. We see confirmation that the file is now cleansed. The JavaScript diet: removing unwanted code Another threat vector are hidden scripts that no one in HR ever invited into our resume upload service. Using any number of means, perhaps an AI assistant, one can quickly hand craft a pdf that shields within it JavaScript. As seen below, there is no inherent blocking of this file with the native pdf viewer, this is what pops up when we open the file. Let’s take a look at how OPSWAT MetaDefender, and specifically the Deep CDR module, is configured to handle the above file being targeted for upload. The MetaDefender has a rich web UI, by clicking from the main menu “Workflow Management -> Workflow -> File Process” we can ensure that Deep CDR is enabled and further in the setup screen see a list of file types to be scrubbed (double-click on enlarge). To fully explore the OPSWAT capabilities, one can see the documentation here. Simply using pdf as a point of interest, since it pertains to our lab attempt right now to upload a risky file, we see some of the adjustable features around just this one file type. When our test pdf file arrives at the BIG-IP virtual server, we can grab a TCPDump and follow the stream using Wireshark. This is the wire-level details of interest as the ICAP request travels to MetaDefender, in the red font. 1. We observed this is ICAP Request mode targeting the OPSWAT server on port 1344 2. The client’s source IP address is preserved as an X-header value 3. The target of the file, including the DNS name and the full URL path is presented 4. The submitted pdf file is 1045 bytes in length 5. We observed this is indeed our test file, the only text in it is highlighted. The following shows the remaining component of the protocol trace, including the response back from OPSWAT, in blue font, with the modified file. 6. We see towards the end of the submitted pdf, there exists JavaScript 7. OPSWAT MetaDefender now responds to BIG-IP indicating the modified content being provided over ICAP is allowed and may continue its journey 8. The content length has changed from the original 1045 bytes to 930 bytes, the JavaScript has been removed by Deep CDR MetaDefender will leave behind a processing history that can be useful to explore the actions taken by Deep CDR as well as other signatures, such as those from many AV vendors, that may have triggered. The BIG-IP configuration for ICAP is straightforward and described here. In short, it consists of two profiles: Create a virtual server of type “Internal” to create the relationship between the BIG-IP and MetaDefender ICAP Server module. The virtual server will need to reference an “ICAP Profile”. Simply create a linkage in this field to a “child” of the default shipped profile, using this URI syntax (adjust IP address to your OPSWAT server address): icap://200.200.200.2:1344/OMSScanResp-AV In the setup for the virtual server itself that will handle actual received traffic, normally of type “Standard” for a reverse proxy setup, adjust the Request_Adapt_Profile. As normal, create a child of the default Request_Adapt entry and point the “Internal Virtual Name” pull-down to your ICAP virtual server configured in the last set. The hidden passenger – files embedded within files As the ancient saying goes, “It’s turtles all the way down” but more often than not in CDR it can be files all the way down. The last lab test involved trying to forward to our upload service a file which had a wide range of peculiarities associated with it. The main items we want to have dispensed with easily are active URL links that can with one single click connect a user to malicious hiding sites. The second is to remove any embedded files, the files within files threat, that may have malware lurking within. Here we see a demo file with both risks. Simply hovering over the innocuous looking website reveals an active link to a lurking malicious link. Also, note to the right-hand side, this appeared to be a single file, yet the pdf reader clearly indicates there is a Microsoft .docx file attached to the pdf once opened. Double clicking on the attachment, it would be hard to resist but probably not wise; besides yet another masquerading link we also note an executable is hanging around. This is what Word shows. Something tells me that, perhaps, this might not be the best version of putty.exe to install. From the point of view of the users of the protected web experience, the solution was observed to work remarkably fast. Using Developer Tools with Chrome, one notes that the user uploading the above highly questionable file, would see the upload succeed, as per the HTTP 200 OK status code. Interestingly, the entire file reconstruction and delivery is seen in this case to be in the 2 second range. Reviewers of the secure documents may simply be shielded from the details of what was found within the original files, as the security team will already see full details in MetaDefender. However, the user themselves can also be flagged with comments in the cleansed file, indicating in this case to be very cautious, that the file did originally have malicious links at multiple locations. Both approaches are seen respectively in the following examples. The power of prevention at the perimeter The intent of this lab investigation was to put the principles of zero trust into actual practice. Integrating F5 BIG-IP with OPSWAT Deep CDR via ICAP ensures that all file uploads are aggressively sanitized before they ever reach the protected web server. As mentioned, multiple topologies can be supported, in fact the lab BIG-IP was also configured as a transparent forward proxy, and files were similarly cleansed upon egress. The lack of friction in getting a working solution was a key takeaway, BIG-IP is already able to intercept high rates of encrypted TLS traffic and the added time for full inspection and file reconstruction when needed was low to moderate. In an era of stealthy, evasive exploits, relying on detection is a losing game. The strategy is simple: sanitize before you compromise—because a rebuilt file is a secure file.
F5 ASM with fortisandbox
Hi i want to integrate f5 ASM with fortisandbox as a icap server for file upload inspection i found this articale https://support.f5.com/csp/article/K70941653 but Value of virus_header_name for fortisandbox is not mentioned any one has experince of integration with fortisandbox. please let me know if anyone know virus_header_name for fortisandbox
Need help with ICAP integration with F5 LTM
I have followed this KB article and created a standard http virtual server with web server and an internal virtual server with icap pool. Both virtual servers and pools are healthy and available. However when the http virtual server IP is accessed, it resets the connection ("reset" is the service down action). I am not sure why it behaves as if the ICAP service is down when it is not down and the icap pool health checks are passing. Also, I can see in the local traffic module statistics that no traffic is reaching ICAP virtual server. Appreciate if someone can help to spot any issues with my setup or help me to understand how to troubleshoot connectivity to internal icap virtual server.
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" } }ASM 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
