feature

What security is there inMicrosoft IIS?There are four security features. Two ofthem are standard to almost every appli-cation, and two are relevant to most net-worked applications.

Standard features1. Client authenticationIIS gives you various authenticationoptions to check who clients are, using anID/password combination which is heldin the NT user list for the Web server.The facility can be a mixed blessing, sincethe primary authentication method that’spracticable over the Internet — BasicAuthentication — sends easily-decipher-able information over the network, andmay do more to reveal information tohackers than to secure the site.

2. IIS Web file permissionsAs NT has an access control system whichallocates file and directory access rights tousers, so IIS has a parallel system to secureWeb pages.

Network features3. Client IP addressYou can specify inclusion lists (just cer-tain named IP addresses can access thesite) or exclusion lists (everyone exceptcertain addresses can access the site).Obviously, most sites want to welcome asmany visitors as possible, but the restric-tion is useful when administeringintranets, to allow some segregation ofinformation, and to restrict the opportu-nities for remote administration.

4. Session encryptionIt’s well worth the site acquiring a digitalcertificate and a public key encryptionpair. Once installed, you will be able touse the SSL protocol, which encrypts ses-sions between the server and clients. Thismeans that, providing you set the optionsfor the site correctly, Basic Authenticationwill be much safer.

Secure administrationTo see what is involved, we need now tolook at how the Web server organizesinformation, and how it controls andmanages that information.

All sites reference their Web pages usinga hierarchical structure similar to the stan-dard file structure you see in WindowsExplorer. Each site sits at the head of anumber of directories containing Webdocuments and scripts. This does notmean that the Web directory structuremust map the operating system directorystructure, for the Web directories can vir-tual — they can be spread out over variousdrives and even over various computers.

In Figure 1 (below), the administrator onthe Web server computer will see a websitewith three sub-directories for Finance,Sales and Personnel. In fact, those threedirectories are on three different comput-ers, not on the Web server at all — but itmakes no difference to the administration.This perhaps gives you a hint of a possiblesecurity concern. In a mixed site of thistype, all the participating servers need tobe considered in assessing security.

Where do we look to see the site struc-ture? The standard tool is the InternetService Manager (ISM) which is normal-ly installed on the Web server computeras part of the software installation. To use this tool at the console is thesafest way to administer the site. It looksand works like Windows Explorer, andyou can use it to manage the virtualdirectory structure and to set or viewproperties for directories and individualWeb pages.

Who can and administer the website?By default, IIS looks at the local user list(that is, the NT user list associated withthe computer that hosts the Web server)to see who can administer the site. AnyLocal NT administrators can by defaultadminister the Web server. IIS 5.0 allowsyou to add additional NT users as “opera-tors” using the site properties sheet. Froma security viewpoint, restriction of admin-istration rights is important.

Why Audit a Web Server?Auditing Web servers: IIS 4.0 — Part 2

Alison Webb

The first of these articles, in Network Security’s July issue, described how Web serverswork, and suggested that the security objectives for them might differ from those forstandard applications. It also discussed some basic procedural controls. This articlecomplements it with a more detailed look at the security features in Microsoft IIS,and then at how to apply those features together with operating system controls, tohelp secure the site.

11

Web server

Sales server Personnel server Finance server

Company Website

Sales pages Personnel pages Finance pages

Figure 1: The apparent organization of the Web server

REMEMBER

Check that administration rights to theserver are restricted to those who needthem.

issue.qxd 10/1/01 11:20 AM Page 11

feature

12

Remote administrationApart from ISM, and to save people hav-ing to walk down to the machine roomto administer the server, there is a way toadminister a site over the Web. Whenthe IIS software is installed, a special virtual directory is set up (IISADMIN),containing the administration proce-dures.

At the same time, remote access to this directory is disabled by settingrestrictions based on client IP addressthat mean it can only be accessed from the local host itself. Ideally, that is how it should stay. To see if remoteadministration is disabled, you can use ISM to look at the settings.Choose Action Properties, then theDirectory Security tab, IP Address and Domain Name Restrictions.Alternatively, just call up the site fromyour browser, and you should see anerror message.

IIS can apply restrictions based on IPaddress to any site, or to any virtual direc-tory within a site or to any file within avirtual directory: but since most siteswant to attract all clients, it’s mostly usedto restrict remote administration.

One serious anomaly with IIS 4.0 is itsuse of a directory called /iisadmpwd whichis not by default restricted. Even if you keepIISADMIN accessible to the local hostonly, clients will be able to reach iisadmpwd. To do so, you will probablyneed to reference one of the files in theIISADPWD directory by name (tryaexp.htr).

It contains procedures allowing peopleto change their NT account passwords.Since the one account which will defi-nitely be there is that of the NT admin-istrator, this facility gives the remotehacker the opportunity to try to guessadministration passwords, and thereforeshould be disabled too. If the site is con-figured to use SSL (which meansinstalling a PKI key), these exchangeswill be encrypted, but otherwise, theyare sent in clear-text.

You can set Basic Authentication sothat users must at least give an NT IDand password to access the page, but

remember that the authenticationexchange is not, by default, encrypted.

This facility thus has two significantweaknesses:• It allows hacking;• It makes network traffic worth

snooping;• Even assuming you encrypt the basic

authentication, there can be little jus-tification for most sites keeping itaccessible remotely.

Secure remote administration

Managing NT accessWhat about access rights to the Web pagesthemselves? The first barriers to illegalaccess are the NTFS file permissions onthe Web pages and directories whichassign access rights to specific users.

How are user IDs set up for the mil-lions of people who may want to accessthe site? In practice, any remote clientwho tries to contact the Web server isallocated the same NT ID, one that isspecially set up in the Guests groupwhen the Web server is installed. Youmay have seen it in user lists — its formis IUSR_servername. No one needs toknow the password for this ID — it isset at the time the machine is createdand never expires. It needs the right tolog on locally, so beware of restricting itas it may stop browsers accessing thesite. It is IUSR’s account permissionsthat allow browsers of sites with the bugdescribed in the first article to managefiles on the server computer.

The work involved in setting accesspermissions is a powerful argument forlimiting the other uses of the computerthat runs the Web server. The morecomplex the permissions need to be, themore time-consuming they will be to setand manage. Microsoft recommend thatif the server is part of an NT domain,then the Web server should not be thedomain controller, for example. In gen-eral, the fewer NT services that allowremote access there are, the more securethe server will be.

In your audit, you need to think aboutthe following:

1. Whether the Web directories can be protected.As we’ve seen, you may need to look atseveral servers, if the site has directoriesdistributed as I’ve described above. If theserver drives are not NTFS formatted,all Web users will have full control overthe page contents. Theoretically, and ifthe site has fixed the bug described inthe first article, there should be no wayfor anyone to exploit this, but since ithas happened in the past, and since inthe absence of better evidence past per-formance is often taken as a guide to thefuture, I think access rights should berestricted.

2. Check that the disks are NTFS for-matted.I can’t think of any exceptions when FATformatting would be a better idea.

The permissions IUSR has, and the per-missions granted to the Everyone group(of whom IUSR will be a member). Thisis an extremely tedious exercise withnative NT, which has few, if any, audit-ing tools worth the name. For this rea-son, it makes sense to have at least theNT Resource Kit installed on the server,so you have some basic utilities to checkpermissions.

Make sure you install the NT ResourceKit on each machine used to store theWeb pages.

The Resource Kit utility PERMS, for instance displays a user’s permissionsto specified files and directories. Runthis for the group ‘Everyone’ and theuser ‘IUSR’ against the website directo-ries to make sure some thought has been given to access permissions. IUSR

REMEMBER

Use ntfs drive formatting

REMEMBER

Install an NT resource kit for easier management.

issue.qxd 10/1/01 11:20 AM Page 12

should need no more than read per-mission to Web files and directories. You shouldn’t stop at the Web directo-ries, though: as past bugs have allowedhackers to manipulate non-Web files,access to these needs to be restricted as well.

An additional precaution, if your Webserver is part of a domain or workgroup,is to restrict sharing of directories anddisk drives.Check all directories on a regular basis to ensure all shared directories aresecure.

Managing IIS accessApart from restrictions by IP address, IIS provides a second, parallel file access control system which applies tothe virtual directory structure of the website, as opposed to NTFS permissions, which apply to the physicaldirectory structure on the comp-uter itself. Where the two sets of permis-sions conflict, the more restrictiveapplies.

You can use IIS permissions to protectsites, virtual directories and files. Theadvantage of them is that it is easy to dis-tinguish between read and execute per-missions, whereas NT’s “standardpermissions” wraps both into the “Read”attribute.

To see what IIS permissions have beenset, probably the best way is to locate thefile or directory in the Internet ServiceManager and view its properties (Action,Properties). This is tedious for a fullaudit, but the rudimentary administra-tion utilities Microsoft provides onlyenable you to list properties partially, andone item at a time, so it’s hardly quickerthan browsing.

The key security settings are shown inTable 1, above right.

Improving security settingsSetting Directory Browsing off is a usefuladditional control. If set on, any browserthat sends a URL without specifying aparticular file gets a list of those availablein the directory.

If your site runs IIS 5.0, you can use the Permissions Wizard to coordinatethe IIS and NT permissions, but for ear-lier versions, this has to be done byhand.

As ever, it’s well worth setting out thescheme for access permissions, so they canbe applied to each new site or directorywithout re-thinking each time.

Managing usersIIS recognises the user who is accessingthe site, and allows you to fine-tuneaccess based on the user.

For many information-only sites, it isenough simply to set automatic access forthe anonymous user, IUSR. Assumingfiles are protected, from an auditing per-spective, all that’s necessary is to check thefollowing:• NT account policies are set with

appropriate password length andcomplexity, largely to protect the

Administration ID and to stop any-one disabling the IUSR account;

• Remote administration is disabled;• The user rights for IUSR are not

excessive. It may need to logon locally,but doesn’t, for instance, need to shutdown the system, a user right thatmay be given to Everyone.

On the other hand, your site may bemore complex, with one or more areasrestricted to selected users only. Forinstance, you may want to let staff whotravel see company information you donot want to make entirely public.

If so, you can change the authentica-tion method for the site from automaticfor IUSR to one of a number of authen-tication methods. The one most relevantto a public (or semi-public, in this case)website is Basic Authentication, whichI’ve mentioned several times above.When the user addresses the restrictedsite, he or she gets a login box. The para-meter is set in the properties for the sitefor directory, under Directory Sec-urity/Anonymous Access and Authen-tication Control. The weakness in thisauthentication method is that passwordsare sent over the Internet in clear text.Actually, it doesn’t look anything likeclear-text: it’s encoded using a methodcalled MIME Base64. However, it’s easyenough for the dedicated packet-snifferto find out how this works and todecode the string into user ID and pass-word.

To secure the session, the site has twooptions. If the Web server is running in aWindows 2000 domain, it’s possible touse the Microsoft “digest authentication”process to disguise the information.

13

feature

Read Give this to any directory you want to make public.

Write This should not be set for public directories because it couldallow users to upload files of their own.

Script This is necessary where users need to initiate the running ofa script — which most will. Theoretically, you can reduce the risks by restricting directories with static pages to Read, and keeping script files (like .asp files) in a separate directory — but this is unlikely to be practical.

Execute Only necessary if the directory contains executable programs. It should be possible to segregate these, and to avoid allocating Script and Execute access to the same directory.

Table 1 : Key security measures in IIS.

REMEMBER

Check NT permissions.

REMEMBER

Check NT shares.

REMEMBER

Security by obscurity is better than nosecurity at all.

REMEMBER

Reinforce the NTFS permissions withIIS permissions.

issue.qxd 10/1/01 11:20 AM Page 13

The massive hype for the third Code Red “outbreak” on 1 August,fuelled by the Microsoft, NIPC, CERT,SANS and others joint public announce-ment only enforced this long-term trend, which started well beforeY2K.

By the end of the day, there was quite a considerable amount of Code

Red traffic flying around. This did causesome problems and significant clean-upcosts to many organizations, even beforeCode Red II, with its far more dangerouspayload (admin level remote shellaccess,) appeared.

However, the stories that had appearedin the press in the run-up to the date-change insisted that: “the end of the

world is upon us.” As the events of 11September, as well as natural disastersaround the globe, have made entirely clearto us that you cannot rationally equatecommunications network failure withtragedy.

If the entire Internet disappeared per-manently tomorrow, the world wouldrecover, probably remarkably quickly. Iwould probably have to join GeneSchultz's “12 Point Plan” for stoppingconsulting, but things would get back tosome version of normal.

What can be done to prevent us slid-ing into public disbelief and ridicule? Wedo know that there are ways to create sit-uations where information security fail-ures can cause real-world damage: IPenabled medical equipment on Internetconnected LANs and power generationand supply control systems being obvi-ous examples. Financial services andretail bank systems failing could causesignificant upset or even personal misery.Bad systems design, especially with ERPsystems, has caused corporate bank-ruptcy, with ensuing worker lay-offs and

14

feature

Alternatively, if the site is configured touse SSL, this can be used to encrypt theauthentication exchange. There are otherauthentication options, but they rely onthe site users and the Web server beingpart of the same NT domain — fine foran intranet, but not applicable to publicwebsites.

Secure users

Monitor useFinally, you need to check continuallythat nothing is going wrong, and for thisyou need a site log. IIS writes access logsin a configurable variety of formats, andthe default format is easy to read with anyaudit software.

The usual trouble is that if the Internetconnection is mediated by a firewall,often the only IP address that shows inthe logs is that of the firewall itself — inpractice, the firewall log may be a betterplace to look for hacking attempts.

This is an important area, oftenneglected. If you pay attention to thesite security, you reduce your chances of a successful hacking attempt, but you don’t guarantee it. Someone needsto review the logs regularly, to check that nothing untoward is being attempt-ed. The skill in doing so is to select what to review in an intelligent way, andthen automate the reporting as far aspossible. Administrators tend to com-plain that reviewing the logs takes toomuch time: but I’ve seen some excellentexamples of reporting set up to operateto a schedule, where the administratorhas to do no more than review a shortemail every day or every week. This pro-vides excellent assurance that all is well— and should give advance warning ofpotential hacks.

ConclusionThe business objectives for the Web serv-er may be unusual: but a technical audit

plan for the server shows us a list verysimilar to the one we’d have for a standardapplication. The key areas are:• Control of Web server administrator

access;• Correct setting of the NT and IIS

access permissions;• Correct settings for user access and

authentication;• Informative logging which is regularly

reviewed.Thus the audit has strong similarities

with other technical computer auditareas. One difference you may find is thatsecurity may have been neglected in therush to get those Web pages online: soyour work can make a real difference inhighlighting risky areas.

About the authorAlison Webb BA FCA MBCS CISA hasbeen an independent computer audit con-sultant since 1990. Her telephone numberis +44 01223 461316.

Crying ‘Havoc’, Crying‘Wolf’ or Just Howling atthe Moon?Matthew Pemble, IS Integration Ltd

I had thought of several other names for this article: “Chicken Little in the ITundergrowth” and “The Computer Security Company that cried: ‘The End of theInternet’,” so you can probably already see where this article is going. A less enter-taining, but probably far more descriptive and appropriate, title might have been“Responsible Behaviour in an Irresponsible World.” The computer industry isbeginning to get a public reputation for producing horridly doom-laden statementswhich turn out to have no basis in reality. Please note, this is my opinion of the public perception, not an appropriate and accurate analysis of the truth.

issue.qxd 10/1/01 11:20 AM Page 14