Posts Tagged ‘BigIP’

Use a BigIP iRule to further defend against ShellShock

Saturday, October 4th, 2014

By now you’ve no doubt heard about ShellShock, and have quickly worked to patch all your systems to close the most vulnerable aspects of this pervasive exploit. You may even be aware that some users are reporting that even the patch hasn’t fully closed the vulnerability (it seems that while the patch prevents execution from arbitrary code execution, aliasing commands is still possible).

The exploit is pretty simple to execute; the user-agent header here will write the text “HACKED” to a file named hack.txt in the /tmp directory on a vulnerable server:

GET /cgi-bin/anypage.html HTTP/1.1
Host: yourhost
User-Agent: () { :;}; echo HACKED >>/tmp/hack.txt 
Accept: text/xml,application/xml
Accept-Language: en-us

So, in addition to patching your servers, if you’ve got a BigIP server in front of your systems, you can also set up an iRule on your system to prevent the traffic from even getting through to your servers by looking for those characters ( “(){” ) in any of your headers:
big-ip-irule-shellshock

The details of the iRule are posted on F5′s forum and F5 even maintains a dedicated up-to-date ShellShock information page. Basically there are two versions of the iRule; one that trades off a tiny bit of performance to log the attack attempts, and one that’s designed to be slightly more performant but lacks logging.

Sure enough, within minutes of applying this iRule to our front-end servers at a client site, we started seeing attack attempts in the BigIP logs. So be warned: the bad guys are out there and they’re actively exploiting this bug, so do everything you can to secure your systems!
(more…)

Opening Excel Documents from the WCI Knowledge Directory

Sunday, February 14th, 2010

I had a client report this strange issue with Excel file handling in IE7 and IE8 (and Office 2007).  Basically, every time someone would open a document, it would get cached by IE.  But the next time the person would try to open the same document, they’d get a “file is locked by user” message.  It seemed IE was caching the file in the Temporary Files folder, then when the user would click the link a second time there was a conflict between the existing file in that folder and the new one IE was trying to bring in.  I found some articles and discussions on the topic, but most came back to making changes on the client-side, which is never easy to do in an enterprise.  Even if it’s a little trickier to execute, you should always try to make changes on the WebCenter Portal side.

In this case, after downloading the Excel file the first time, I confirmed it was in my Temporary Internet Files folder:

 Temp Files

I was also able to verify that the portal was returning a “Not-Modified” header when the user tried to open this Excel document again:

not-modified

The fix I applied here?  Another BigIP iRule that turns off caching of Excel files – after the jump. (more…)

Fix KD Handling of HTML Docs

Thursday, January 21st, 2010

In ALUI 6.5, and following through to 10gR3 and the latest patches, Oracle changed the way documents are opened in the Knowledge Directory.  This change was to get a little better browser compatibility so that when a user clicks on a document in the KD, the user is always presented with the usual Open/Save Dialog box.

Many WCI clients have HTML files in their Knowledge Directories, whether they’re crawled in from Publisher, Collaboration Server, or uploaded from some other source.  In version 6.1 and before, the behavior of the portal was simply to open these files directly in the browser, but that changed with 6.5.  Unfortunately, Oracle has asserted that this is “expected behavior” and while an enhancement request has been submitted, there are no promises about the behavior changing in 11g. The good news is that there’s a relatively simple fix for this behavior.  Unfortunately, the “relatively simple” fix assumes you’ve got BigIP load balancing requests to your portal, but if not, hopefully this post will give you some ideas on how to resolve the problem in your environment.

The problem is caused by the portal returning an HTTP header called “Content-Disposition”:

Content Disposition Header
Content Disposition Header

The trick is to remove this header for HTML documents.  I’ve tried writing ISAPI filters unsuccessfully, but for the clients that needed the fix, they had BigIP. 

Hit the link to see the BigIP iRule to resolve this issue.

(more…)