Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Securing an installation of IIS 4. (No, seriously)

  1. #1
    Senior Member
    Join Date
    Apr 2002

    Lightbulb Securing an installation of IIS 4. (No, seriously)

    Wow! What a brave title. I probably deserve some greenies just for that! But wait till you've read the rest of the article. If you still want to donate some points at the end please feel free.

    Let's face it, if we were to define security as a flotating point variable with a lower bound of zero and an upper bound of 1, there would be very few webmasters, even those running a [insert branding here]-X o/s, who could claim to have security much beyond 0.9. A web server is a peice of software that allows remote computers to read local files and in some cases execute local scripts.

    Put like that the very idea of a web server sounds like a security violation. That said however, the webmaster with a 0.9 security value on our scale is _less_ likley to experience security violations than a webmaster with say a 0.09 security value. And that's about where you start with a standard 'out-of-the-box' installation of IIS 4.

    My point is that whilst a 1 on our scale is only a hypothetical pinacle, to which every webmaster should aspire, some common sense precautions (and there's nowt so rare as common sense as my mother always used to say) can go a long way in ensuring that you are more secure than the next guy, especially if the next guy is running an 'out-of-the-box' installation.

    Obscurity is no defence. Any script kiddie with a port scanner can find what services you run. The trick here is to make your installation as non standard as possible. It is also worthwile running port/vulnerability scanners against your own machine - before someone else does!

    NOTE: I will refer a lot here to my public ftp server on Whilst every care is taken to ensure that these files are virus and error free you are advised to scan any files you download. Usage is entirely at your own risk. If you use any other software from this server and intent to keep it please support it's creators by buying a valid licence.

    -->Before we begin

    A standard NT 4.0 install will copy the system files to c:\winnt by default. Most installations therefore have system files installed somewhere like c:\winnt or d:\winnt or e:\winnt etc. If you are installing your o/s try using a more origional name for this directory like c:\ntinstall or c:\hereiam. NOTE - _Don't_ try to change this post install as this will give you a really bad hair day.

    -->Physical security

    Most credit card frauds etc happen within the company itself after cc details have been transmitted. It is important to remember that security begins at the physical level. Locking servers when you walk away from them - even for just a moment - along with secure physical housing (secure area/locked doors) are imperative. All the IT knowledge in the world won't help you if someone breaks into you building and steals your hard drive.

    -->Service packs (and hotfixes)

    Install all patches and hotfixes as soon as they are released. This sort of goes without saying. It's a microsoft product after all! The latest service packs (22/5/2002) are as follows:

    NT4 service pack 6a
    IIS4 Latest security roll-up

    -->Virtual Directories (sample files)

    Remove these immidiately you finish the setup. The virtual directory msadc is especially vulnerable to the RDS exploit (which evey script-kidde in the world has a coy of) so delete this one first. You can read more about the RDS exploit from the horses mouth at:


    If you think that you may want to use the samples move them outside your IIS folders (by default the sample files are installed to c:\winnt\inetpub\iissamples) but remember to remove ALL virtuals. Don't forget about the sample admin scripts that are located (by default) at c:\winnt\system32\inetsrv\adminsamples\. _Don't_ delete these admin samples as you _will_ need them. Just move them to somewhere a little less obvious.

    An aside: Adsutil.vbs (c:\winnt\system32\inetsrv\adminsamples\) provides a very simple methodology of accessing the metabase via script. The metabase contains all the information about how your IIS installation is set-up and the adsutil.vbs file (or mdutil.exe from the winnt option pack or from, works from the command line to modify those settings. It can also be used within SSI's to allow you to write your own IIS delivery aps. One of the most common complains I hear from programmers about IIS is about the restrictions of using the IIS GUI, especially when administering remotely. RTFM . You can even write DOS style batch files to perform iterative tasks over any number of sites.

    -->Denying known anonising IP

    Hacker 101. Read any newbiew FAQ. Surfing anonymously through anonising proxy-servers is the first thing that any malicious character is going to look for, because the last thing they want to do is appear on your server logs. You can use this against hackers by denying the ip addresses of known anonising servers.

    You can get a list of anonising proxy servers from http://www.multiproxy.org/anon_list.htm

    -->Configuring ISAPI

    Remove from the configuration tab any ISAPI that you are not using. Remove the IDC/HTX connectors (plus any asscociated .ida .hta extentions that you have) even if they are in use. These are VERY vulnerable. They are used as database connector files and are published from MS Access which is about the most insecure database possible (remember our scale? Minus numbers.) Get shut. Upgrade to MSSQL (see below) or MySQL.

    Next be aware that you can remap executables to new extention names. My personal preference is mapping the .html extention to the shtml executable and calling my actual scripts as SSI's using the exec cgi function. But what the user sees are just plain old uniteresting, flat, html files.

    Also, make sure that all your include files are parsed by an ISAPI. For example, if you store asp code in .inc extention files for re-use over many pages in a site make sure that the .inc extention is processed by the asp.dll (under the configuration tab). Otherwise someone could guess that the customer.asp might use a customer.inc file. If the file exists and is not processed by an ISAPI filter then it will be displayed in plain text, and that's a major security concern especially if that means someone reading your SQL statements. It would even be possible for someone to write a utility to scan your site for all the asp pages it contains. This thoretical app could then try to open all of the filenames it found with a .inc extention. You can see how an app of this nature could be written in my last tutorial at http://www.antionline.com/showthread...hreadid=226730 .

    -->Custom Error messages

    The first thing a website hacker will do to find loopholes in your site is to see where it breaks.

    If your app does fall over will it pass out cigars to a potential hacker in terms of sql statements, physical paths etc? You can stop this happening by turning of 'send detailed error messages to the client' setting and customising your own error message.

    In light of the recent directory traversal exploit (fixed by the security roll up listed above) it is also well worth changing the standard error messages (404,500,etc). You can do both of these things in the default site, and subsequent sites will inherit these properties.

    -->Configuring FTP

    If you own your own box don't put it on the default port 21 where any muppet could find it. Pick a number from 1 to 65000. Remember that warez style intrusions are commited by people using a port scanner to find ports open on 21. If that ain't you guess what. They move on to the next fella (the one with an 'out-of-the-box' install that we were talking about earlier - remember him - poor bugger! )

    -->Remote Buffer Overflow exploits.

    To even attempt a remote buffer overflow you would have to have a good working knowledge of C, machine code and a pretty in depth understanding of the fundamentals of how computers work. Statistically that's a real small number of people and most of them have, by the time they have aquired that much knowledge, passed well beyond their malicious adolecance. Even then it's a skill set that's statistically quite rare. The whole process is time consuming and tedious anyway and I'd have to have a real good reason to want to bother. Now if you were to rip me off on the other hand...

    So mostly, unless you're a really big player, or have really bad security, the elite (who by and large realise that it is spelt with at least 2 e's btw) are quite unlikely to bother you.

    So that leaves cook-book exploits by script kiddies. This is when an uber-hacker publishes their exploit on-line and kiddies reproduce it on unpatched servers. However, there is a procedure for reporting security issues, a sort of embargo, wherby a _real_ hacker can report the issue to Microsoft. Microsoft then have a given amount of time to prepare a security update release, before the hacker can publish their exploit. This is the right thing to do btw - anything else makes you a script-kiddie no matter how 'leet' you are. This is what gives the term 'hacker' the bad name that has been characterised in the media recently.

    So as an administrator worried about remote buffer exploits re-read the section entitled Service packs (and hotfixes). That's about all you can do as a webmaster, to keep up to date with the latest service packs/hotfixes.

    -->SQL Server (7) Security.

    First install the latest service packs:

    Service pack 3
    SQL Latest Security roll-up

    Best Practice: Least Privilege
    Least Privilege requires that each subject be granted the most restrictive set of privileges needed for the performance of authorized tasks. Applying this principle will limit the damage that can result from either accident, error, or unauthorized use of an information system.

    And I know this will sound ludicrous but make sure that you set an password for the sa account. MSSQL doesn't do this by default and there is currently a worm called digispid.b that takes advantage of this 'vulnerability'. See http://securityresponse.symantec.com...id.b.worm.html for more details.

    Next take a long hard look at your code. The worst thing I every saw in a web coding shop was a piece of code that passed an sql statement as a get request to a script which displayed results.

    http://www.namechanged.gov.uk/search...qlQuery=SELECT CON_ID,CON_SNAME,CON_FNAME,CON_TITLE from contacts
    I could simply change the above to:
    http://www.namechanged.gov.uk/search...qlQuery=SELECT id as CON_ID,(select COL_NAME(1493580359,1)) as CON_SNAME,(select COL_NAME(1493580359,2)) as CON_FNAME,(select COL_NAME( 1493580359 ,3)) as CON_TITLE from sysobjects where xtype='u' order by name
    And I was able to pull out any information from the sysobjects table I wanted. Major security violaton!

    But you don't have to be as bone-headed as that guy was to have security problems with your sql statements. For a more in depth discussion on sql security read: http://www.wiretrip.net/rfp/p/doc.asp?id=7&iface=2

    The essense of the argument however, from the standpoint of someone trying to secure their IIS server, it to make sure that any parameters you accept from a client are thoughly checked BEFORE using them in any query. Write a function that validates the length of inputs and checks for the presence of sql commands or the ';' character.

    -->Keep Updated

    Most important of all? Keep updated. Get into the routine of updating your denied IP list. Visit the windows update site at least once a month. And check back to these sites regularly to keep yourself informed, and your web server more secure than the next blokes:


    So that's all folks - if you use any of these tips don't forget my greenies. Cheers, NTSA.

    If you enjoyed this tutorial take a look at my last one entitled "Scripting Internet Connections Under Window$":
    \"I may not agree with what you say, but I will defend to the death your right to say it.\"
    Sir Winston Churchill.

  2. #2
    Well, I'm a fan of Apache myself, but this is very useful guide. You may also want to recommend running a vulnerability scanner against your own machine before someone else does. Good post.

  3. #3
    Senior Member
    Join Date
    Apr 2002

    Last time I looked common-sense was compatible with all kinds of o/s lol. Sorry if that got a bit MS oriented, but a similar check list for Apache would have been a much shorter document. Hopefully there was enough non-o/s-specific info in there to make it worth the read though (apache can deny IPs aswell!).

    Thanks and greenies for the vulnerability scanner comment - I have included it (I was still finishing off editing when you replied) as a very valid point.

    Thanks for the greenies btw much appreciated...
    \"I may not agree with what you say, but I will defend to the death your right to say it.\"
    Sir Winston Churchill.

  4. #4
    Have a quick look at GravityStorm's Service Pack Manager it will keep up to date with M$ patches etc so if you have the infortunate task of looking after dozens of IIS4 and 5 servers it takes some of the repetition out of patching the OS Apps and DB's to bits.



  5. #5
    Fastest Thing Alive s0nIc's Avatar
    Join Date
    Sep 2001
    OMG its about time someone write this tut... cool!

  6. #6
    AntiOnline Newbie
    Join Date
    Apr 2002
    Great post - one other thing I suggest to my clients (if it is feasible) is that their proxy server(s) and IIS server(s) be installed to a domain all their own between the internal network and "the world", thereby creating a "DMZ". The DMZ is set up to trust the internal network - that way traffic flows outward, but should any of the machines in the DMZ be compromised, it would be nearly impossible for the intruder to access the internal network as domain trusts would prevent access.

    All servers should of course, have patches and hot fixes applied ASAP, with full logging and IDS active on all servers in the DMZ. Naturally all systems would be backed up on a strict schedule. If the machines are compromised and data lost, back ups can be used to rebuild the DMZ without having to start over from scratch.

    I realize this is almost (in effect) like offering up your IIS server(s) and the proverbial sacrificial lamb, but better to loose the IIS than to open you entire network to the possibility of attack.

  7. #7
    Senior Member
    Join Date
    Nov 2001
    Kick ass post ntsa! There have been a lot of posts recently asking about server security. At last we have a good tutorial we can link to! Thanks

  8. #8
    Senior Member
    Join Date
    Oct 2001

    Re: Securing an installation of IIS 4. (No, seriously)

    All pretty much common sense stuff. You did forgot the mention the IIS lockdown tools that MS provides to get rid of the most commonly overlook misconfiguration. There are also numerous articles on the MS website that detail locking down IIS installs to far greater detail then this. Also, changing the name of the NT directory does little, as the nt directory and the system32 directory are in the path, and can be referenced via the system path as windir.

    Also no mention of using NTFS on all volumes, and assigning permissions accordingly.

    I also think you should put more credence in trying to stomp out bad script coding on webpages. Bad java/perl/etc.. scripting should be a major concern to the security minded sysadmin. There are quit a few companies out there that will do code reviews looking for code problems that in turn lead to exploits. The small group of true "elite" that you refer to, is not as small as you may think.

    Web facing machines should also never be put into a domain structure. Make them stand alone servers, this removed the entire permissions via trust issue altogether.



  9. #9
    Senior Member
    Join Date
    Apr 2002
    All pretty much common sense stuff.
    there's nowt so rare as common sense as my mother always used to say
    . You did forgot the mention the IIS lockdown tools
    I sort of lumped these in with vulnerability scanners:

    It is also worthwile running port/vulnerability scanners against your own machine - before someone else does!
    Sorry for any confusion.

    changing the name of the NT directory does little
    if it slows you you down just enough to get a fix on your ip that's fine by me.

    I also think you should put more credence in trying to stomp out bad script coding on webpages
    Very true - maybe a topic for a future tut... PM me if you (anyone - not just mohaughn) would like me to write it.

    Also no mention of using NTFS on all volumes, and assigning permissions accordingly.
    Gee, if I'd known I was going to get marked down I'd had spell checked and everything (ask soluleman why I didn't). But a good point none the less (though why someone would want to use any other file system under NT escapes me).

    The small group of true "elite" that you refer to, is not as small as you may think.
    No - I think what I said was:

    by the time [hackers] have aquired that much knowledge, [they have] passed well beyond their malicious adolecance
    Plus the sort of person you are talking about tends to do the right thing and hands their work into the cvs.

    Web facing machines should also never be put into a domain structure. Make them stand alone servers, this removed the entire permissions via trust issue altogether.
    Good point (made earlier by Specter6 in his comments about using a DMZ). Alternatively don't attach them to your're corporate network at all.

    Useful thoughts/links mohaughn. Thanks.
    \"I may not agree with what you say, but I will defend to the death your right to say it.\"
    Sir Winston Churchill.

  10. #10
    This guy is going to go far on these forums......Mr gates, is that you?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts