Securing an installation of IIS 4. (No, seriously)
Quote:
Originally posted here by ntsa but as JP is now counting our tutorials (Nice one btw JP) I thought I'd ask Negative if it was ok to repost this in the tutorials section.
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 195.8.181.206. 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 ftp://195.8.181.206/networktools/NT-Sp6/Sp6i386.exe
IIS4 Latest security roll-up ftp://195.8.181.206/networktools/IIS-SP/Q319733i.exe
-->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:
http://www.wiretrip.net/rfp/p/doc.asp/i2/d1.htm
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 ftp://195.8.181.206/networktools/Mdutil.zip), 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 ftp://195.8.181.206/networktools/SQL7-SP/sql70sp3i.exe
SQL Latest Security roll-up ftp://195.8.181.206/networktools/SQL...p3_x86_enu.exe
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.
I could simply change the above to:
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:
http://www.packetstormsecurity.org/
http://securityresponse.symantec.com/
http://www.antionline.com
If you enjoyed this article check out these others by ntsa:
Credit card security
Dumping SQL data to a text file
Hunting down skript kiddies
Search Engine submission 'exploit'
Forced shutdown of a remote nt/2k server
Remote DSN Connections, using WinAPIs and the registry
Scripting Internet Connections Under Window$
