Securing ColdFusion and IIS

David T Watts, CTO, Fig Leaf Software

28 July 2001

What’s this presentation about?

This is an overview of what needs to be done to secure a Windows NT/2000 server running IIS and ColdFusion applications.

This presentation is neither complete (it doesn’t discuss everything that should be done) nor adequate (it doesn’t cover each step in fullest detail).

This presentation only covers securing the application server itself, and doesn’t cover general network security issues, or physical security issues.

General security concepts

Successful security requires a “layered” approach – reliance on a firewall isn’t enough. Each network device and service should be secured to the extent possible.

There is no such thing as “fully” secure.

Security is a process – you can’t simply “secure a server” and be done with it.

Security and convenience are directly opposed. You’ll need to determine what level of convenience you can do without, and what level of security you need.

“Security by obscurity”, by itself, is no security at all – if the service is publicly accessible, it will be found!

Current state of affairs

There have been many successful attacks against IIS servers recently:

sadmind worm (“F**k USA Government”)“Code Red” worm (“Hacked by chinese – www.worm.com”)

IIS exploit code is readily available.

Common IIS exploits depend on well-known vulnerabilities.

What does “IIS” stand for?

It

Isn’t

Secure

Can IIS be secured?

The default installation of IIS is designed to provide many types of functionality.

Most of this functionality is unused by most IIS users.

Production IIS installation requires removal/disabling of unnecessary functionality.

Secure IIS installation also requires secure OS configuration.

What’s covered within this presentation? Determining the appropriate level of security

OS configuration

IIS configuration

CF configuration

CF application security issues

Database configuration

Security maintenance

How much security?

Is the server a production server?

Is it connected to the public internet?

What is the value of the data it uses?

What is the value of the service it provides?

How much integration with other network services does it need?

Can this server, if compromised, be used to compromise more valuable assets?

What are the threats?

Attacks against the OS:- denial-of-service- NetBIOS

IIS vulnerabilities:- script reading- ISAPI vulnerabilities

CF service vulnerabilities:- access to RDS- access to CF Administrator- vulnerability within API extensions

CF application vulnerabilities:- manipulation of data within HTTP requests- inclusion of code within HTTP requests

Threat manifestations

Automated attacks (sadmind, “Code Red”)

Directed attacks

Securing NT/2000

General concepts

Disk configuration

Networking

ACLs

Services

OS security – general concepts

Securing a Windows server for connection to the internet requires that it be configured with as little software as possible, and that each application have as few rights as possible.

Default installation options for Windows, on the other hand, are aimed at providing maximum functionality at the expense of network security.

The server should be configured offline if possible, since it can be attacked during the configuration process!

No escape from sadmind!

Disk configuration

The server should have separate partitions for system, applications, and data.

All partitions should use NTFS.

Networking

The minimum necessary set of networking protocols and services should be installed and enabled.

On servers directly exposed to the internet, SMB functionality (NetBIOS over TCP/IP, Win2K Direct Host) should be disabled.

If possible, the server should be configured as a stand-alone server, rather than as a domain member. It should NEVER be a domain controller!

Access Control Lists (ACLs)

Every resource within Windows – files and registry keys, for example – can be secured by editing the ACLs for the resource.

For filesystems, ACLs are typically inherited from parent containers, so it’s best to set ACLs on filesystem roots before installing additional software.

Filesystem roots should have strict permissions (Administrators, SYSTEM).

NTFS 5 (used in Win2K and NT 4 SP4+) has interfaces that allow ACLs to be very strictly controlled.

ACL interface

More about ACLs

Registry ACLs should also be set. This can be done with regedt32.exe.

Microsoft provides several tools for easy configuration of ACLs based on how the server will be used.

Services

Unnecessary services should be disabled.

In NT/2K, services run by default within the SYSTEM security context, which allows them full control over the server, but no network rights. Because services run as SYSTEM, if a service can be forced to run hostile code, that code will run with those administrative rights. For those services that can be configured to run as specific users instead of SYSTEM, this should be done.

Configuring IIS

During the installation, no samples or documentation should be installed.

After installation, many things need to be done to secure IIS.

Unnecessary ISAPI applications should be removed from all virtual servers.

ISAPI applications and virtual directories

Configuring IIS, cont’d

Unused ISAPI extensions should be removed.

Configuring IIS, cont’d

IIS web-based administrative functionality should be disabled, or limited to secure access (via SSL, for example). Since all administration can be done from the console using the MMC interface, disabling/deleting the Administrative Web Site is usually a good idea.

Log files should be moved to somewhere other than the system partition.

FrontPage extensions should be uninstalled if not used.

Content indexing should be disabled if not used.

Unless executables specifically need to be run, only scripts should be allowed to run.

IIS configuration can be done at a general level, or to individual virtual servers. When done generally, it will apply to all virtual servers that you later create.

Configuring IIS, cont’d

Once IIS has been configured, the Metabase should be backed up from within the IIS MMC. If you want to use the Metabase settings on another server, you can use the Metabase editor available from the Microsoft site.

Be aware that upgrades and service pack installations may undo changes you made to IIS; you’ll have to redo them.

Configuration can be automated using WSH scripts. Sample WSH scripts can be found in the AdminSamples directory installed by default within inetpub.

IIS 6 will replace the Metabase with a text-file configuration.

More on IIS

Because IIS is integrated with OS security, IIS must run within the SYSTEM security context. When IIS receives an HTTP request, that request is run within the security context of the connected user (if a login is required) or as the “anonymous user”, which by default is mapped to the account IUSR_MACHINENAME.

Because IIS logins are mapped to OS logins, Basic Authentication should be avoided if possible, unless used through SSL.

Additional IIS services, such as FTP and SMTP, should not be installed if possible.

The web root directory should be located on a separate partition.

Securing CF

Sample applications and documentation should not be installed.

The CF service, by default, runs as SYSTEM. This should be changed to a less-privileged user account.

RDS should be disabled if possible.

RDS and CF Administrator are both web applications. Access to both should be controlled as strictly as possible.

To secure access to RDS, apply permissions to the file {webroot}\main\ide.cfm. Note that removing the file and/or the directory completely won’t prevent RDS access!

Patching the CF API extensions

Macromedia recently released a patch for all versions of CF prior to version 5 to address a vulnerability in the CGI and API stubs used by the web server to communicate with the CF service.

While details on the vulnerability haven’t been released by Macromedia, a vulnerability within the stubs could potentially allow retrieval of files from arbitrary locations on the filesystem.

The vulnerability probably exists within the libraries used by the stubs, which would explain why CF 5 isn’t vulnerable.

CF application vulnerabilities

No data returned by the browser should be trusted! (Form, URL, CGI, Cookie)

Use data-type checking whenever possible. (Val(), CFQUERYPARAM, CFSTOREDPROC)

Filter input for code (<>, JavaScript).

For a guide to input filtering, look at the CERT site and the input filters available from the Developers Gallery.

Database security

Database servers should not be accessible from the internet. In an ideal configuration, the application server will have separate NICs for public and private traffic.

Database logins should be used to minimize database access rights whenever possible. These logins should be used within application server data source configurations, which themselves should be limited to minimum execution rights.

Stored procedures can be used as a database interface; if used exclusively, access can be granted only for those procedures, preventing direct access to tables.

Access to extended stored procedures should be minimized.

Maintaining security

Check application logs.

Check system logs.

Use read-only filesystems when possible.

Use file checksumming utilities (Tripwire) to track changes to files.

Apply patches as necessary.

Resources

General information about ACLs can be found at:http://www.trustedsystems.com/

Useful ACL diagnostic tools NTFileMon, NTRegMon:http://www.sysinternals.com/

Security checklists for IIS 4 and 5, as well as lots of other stuff:http://www.microsoft.com/security/http://www.microsoft.com/technet/security/

SecurityFocus IIS security checklist:http://www.securityfocus.com/

NTBugTraq OS and IIS patchlists:http://ntbugtraq.ntadvice.com/

Configuring CF to run as a different user:http://www.defusion.com/articles/index.cfm?ArticleID=89

NSA Windows 2000 Security Recommendations:http://www.nsa.gov/

SecureIIS:http://www.eeye.com/

Tripwire:http://www.tripwire.com/