Freigeben über

Blocking certain extensions in ISA server

  • Artikel

For some reason I decided that today was a good day to figure out how to block certain file extensions from being accessible over the web. This could be very useful, for instance, if you are trying to prevent a particular exploit that utilizes a particular file extension for its payload.

To do this go to the rule that allows inbound web traffic and double-click it.
Click the "Protocols" tab
Click "Filtering"
Click "Configure HTTP"
Click the "Extensions" tab

Here is where you have to make the choice of what to block. If you have some time, it would be really good to enumerate good things here and block everything else. What might be good? The following probably are:

  • HTM
  • HTML
  • JPG
  • JPEG
  • JFIF
  • GIF
  • PNG
  • ASP
  • ASPX
  • TXT
  • EXE (we probably want to be able to download these)
  • OCX (arguably ActiveX is good)
  • SWF (I personally do not like Shockwave, but some people do)
  • CFM (Cold Fusion)
  • PHP
  • ZIP
  • There are probably a lot more and quite frankly, in an emergency, you would not want to build this list. Do this later, when you can do some real analysis on it

So obviously, if we are worried about a particular attack, we'll select "Block specified extensions (allow all others)" in the drop-down list
Click Add
In the "Extension" box type the name of the extension, such as "WMF" (without the quotes)
Click "OK" twice and then click Apply.

If you want to verify whether the filter works go to https://www.protectyourwindowsnetwork.com/test-wmf.htm. If the picture on that page is blocked your filter probably worked.

Comments

  • Anonymous
    January 01, 2003
    PingBack from http://www.keyongtech.com/2613055-win98-vulnerable-to-wmf-malware

  • Anonymous
    January 01, 2003
    PingBack from http://www.hilpers-esp.com/614987-bloquear-extension

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    December 28, 2005
    Thanks!

  • Anonymous
    December 28, 2005
    Strange that you should relegate WMF to the example, but not add it to the list - is that a coincidence, or have you been reading the tales of a WMF zero-day attack?

  • Anonymous
    December 28, 2005
    Awesome timing on that WMF example, hopefully its just some comic relief :)

  • Anonymous
    December 28, 2005
    Since you are using SBS, did this apply to a System Policy Rule or one of the SBS created Firewall Policy Rules? I've already tried the SBS Internet Access Rule unsuccesfully and am at odds to understand where the firewall controls the flow of website information back into the protected network if not there. Thanks for a well timed article on this bye the way ... I've read that paragraph on the WMF exclusion twice and understand its meaning to block the WMF not pass it through.

  • Anonymous
    December 28, 2005
    Alun, is WMF really necessary on the web? I don't recall seeing many web sites using it. I forgot a lot on the good list though, like XML. The point is more that yes, an allow list is the right thing to do, but it is not easy.

  • Anonymous
    December 28, 2005
    Dale, I actually applied the filter to the SBS Internet Access Rule. I typically like making new rules and not modify the built in ones, but if you are not using SBS you would have a custom rule like it and then that is where you would put it. With SBS it may be safer to make a new rule.

  • Anonymous
    December 29, 2005
    Seriously. Who uses ISA in any real world environment? Let me rephrase that -- any real world environment who hasn't consumed the kool-aid.

    Third party tools/hardware perhaps?

    Love the blog by the way.

  • Anonymous
    December 29, 2005
    There are some sites and vendors that have a full listing of file types that should be blocked, we use Clearswift products together with firewall policies. I sat down one day and went through these lists and worked out what we needed (that was safe) and blocked everything else, it's amazing just how little you really do need. However, my boss has a good understanding of why this is required and supports this, which makes it easy for me :)

  • Anonymous
    December 29, 2005
    Dr. D... a lot of folks use ISA in a real world environment sir.

    Every SBS 2003 Premium that has ISA 2004 in fact.

  • Anonymous
    December 29, 2005
    Dr. D, it's totally up to you. As I always say, if Microsoft products do not do what you need them to, you should not use them. That said, I'd love to know why you feel that no real world environments should use ISA, or do you simply mean that none do, regardless of whether they should or not?

  • Anonymous
    December 29, 2005
    Keith, can you send me some links to those types of sites? I would love to see it. You can send me e-mail if you want.

  • Anonymous
    December 29, 2005
    For the record, wmf files probably weren't the best example for this. It looks like Windows XP detects wmf files based on their file extension and their content. This means that a renamed wmf file may still be treated as a wmf file by XP when it hits your desktop, potentially by-passing ISA filters if ISA looks at the file extension alone.

  • Anonymous
    December 29, 2005
    Andy: This behaviour is an artefact of the way in which applications are associated with extensions, and in which they load files.

    Rename the WMF as any image format that is rendered by the same engine, and it will still cause you a problem. Rename it as a TXT file, and you won't see it pulling up the graphics viewer.

    This is because extensions are associated with applications, and a single application may render multiple formats. The association is made on the basis of the file extension, and the rendering is done on the basis of the file's contents.

    As an example, try running this command: "ftype | findstr /i shimgvw.dll" - it'll show you all the file types that are associated with the Fax And Image Viewer. To see what extensions are associated with those file types (let's use "wmffile" as the example), you would run "assoc | findstr /i wmffile".

    If you want to browse through this information in a text format, to see what types are associated with what programs, the following command produces some edifying output (doubtless someone will improve on it):

    ( for /f "tokens=1,* delims==" %a in ('assoc') do @echo %a=%b & ( @if not .%b==. ftype %b ) & @echo. ) > types 2>nul

  • Anonymous
    December 29, 2005
    The comment has been removed

  • Anonymous
    December 29, 2005
    I so wish there was a way to filter based on content at the firewall, but sadly, we seem to live in an extension oriented world; one full of programmer who refuse to realize that and do everything in their power to ensure that their buggy code gets invoked no matter what extension the attackers put on the file. Filtering in extensions is kind of like using Software Restriction Policies to block attacks. It will certainly stop a specific attack, but the way around it is typically quick, easy, and only a day or two away.

  • Anonymous
    December 29, 2005
    The comment has been removed

  • Anonymous
    December 29, 2005
    Alun: This makes sense and shows why blocking based on file extensions isn't a great idea.

    I've read that to mitigate the current wmf issue a workaround is to unregister the shimgvw.dll file which will prevent the Picture and Fax viewer from running. From your explanation I'd guess that changing the associations of all file types currently associated with shimgvw.dll to a different (third party?) file viewing application would also prevent any infection through this vector?

    I'm presuming that shimgvw.dll is only used by Picture and Fax viewer and no third party apps are likely to be using it (as in the MS04-028 gdiplus vulnerability).

  • Anonymous
    December 29, 2005
    Andy: That would all depend on whether the bug is in shimgvw.dll, or is in some other library. Also, whether code for other applications you run might be calling shimgvw.dll.

  • Anonymous
    December 29, 2005
    The comment has been removed

  • Anonymous
    December 29, 2005
    Whats especially obnoxious about relying on extension and not filtering on actual type is that there's nothing you can do to stop it with ISA. Even using only allows on the HTTP filter, a bad file can still get through by renaming the extension. The exploit would be just as accurately described by saying a malformed .jpg or .gif or any file parsed by shimgvw.dll can cause the problem.

  • Anonymous
    December 30, 2005
    So, given the sneakiness of attackers and their deplorable tactics these days, we can no longer take any claim at its word. And that's what a file extension is -- merely a claim that a file is of some type. We must dig deep into the bits of everything passing into and out of our networks now.

    What does this mean? Yes, the end of life for traditional packet-filtering firewalls. The architecture Jesper wrote up in an earlier comment (http://blogs.technet.com/jesper_johansson/archive/2005/12/28/416565.aspx#416632) is one I've been promoting also. Use your border router to throw off the obviously spoofed stuff (see the book for the five rules), then parcel traffic to appropriate content-inspection firewall farms. Inspect everything; throw away whatever doesn't conform.

    ...Now to those who doubt the enterprise-worthiness of ISA Server... I was once a doubter myself, in the early ISA Server 2000 days. But after spending lots of time with the product, tearing it apart, and building several large enterprise installations with it, I'm convinced it's great stuff. In my opinion, it's some of the best code Microsoft has ever released. ISA Server 2000 has had only five critical or important security bulletins in its lifetime -- and only two of them involved remote exploits, one in the Gopher protocol handler and one in the H.323 filter. Most people don't even use these bits. ISA Server 2004 has had zero bulletins.

  • Anonymous
    December 30, 2005
    The comment has been removed

  • Anonymous
    December 30, 2005
    The comment has been removed

  • Anonymous
    December 31, 2005
    When it comes to security, almost everything has a value, and it is almost always dangerous to rely too much on one thing. There is no black and white in Security. Everything is grey scale. Blocking WMF files may take the heat off you for a while, until the bad guys exploit JPG files (totally theoretical as I am not aware of an exploit in JPG, lest someone thinks I was revealing something). The point is that Alun is right. Even technologies that do not provide absolute security often have value if the cost of implementing them is lower than the expected loss of the security breach they stop, however temporarily; and they are used properly. If our security toolbox could only have technologies that provide absolute security there would only be one tool in it:http://www.amazon.com/exec/obidos/tg/detail/-/B000BHPY0S/sr=1-14/qid=1136009865/ref=sr_1_14/002-4134391-6394434?%5Fencoding=UTF8&v=glance