Aahh, the joys of meeting SOX requirements…

 

Tonight, I am having fun whipping together a script to apply to servers to meet SOX audit recommendations. This particular task is to harden IP on all IIS 6.0 server per KB 324270.  I had been tasked with applying changes to IIS 6.0 servers working with others on a team. I volunteered to create the script to handle many of the registry changes required to meet the audit requirements (yeah, I am stupid that way…). They get the joy of testing and deploying the script in production.

 

My first step was to create the script itself. Afterwards, I had the joy of creating the .ini files that I will use in conjunction with regini. The commands in the script are pretty simple once the .ini files are created, and they are pretty simple, too.

 

First the script, a very basic command line script (yes, I sanitized it to protect the innocent, and I also removed many lines and simplified it for ease of understanding):

 

@echo off

CLS

 

rem Apply IP Hardening registry info

ECHO Implementing IP Hardening registry entries

regini SynAttackProtect.ini

regini EnablePMTUDiscovery.ini

regini EnableDeadGWDetect.ini

regini KeepAliveTime.ini

regini NoNameReleaseOnDemand.ini

 

I created this very simple script (damn, it sure looks easy, doesn't it?), and then I created the individual .ini files. They are simple text files as follow (note, the italicized text is the content of each file):

 

SynAttackProtect.ini

\Registry\Machine

             System

                  CurrentControlSet

                       Services

                         Tcpip

                              Parameters

                                     SynAttackProtect = REG_DWORD 0x1

 

EnablePMTUDiscovery.ini

\Registry\Machine

              System

                   CurrentControlSet

                       Services

                           Tcpip

                                 Parameters

                                     EnablePMTUDiscovery = REG_DWORD 0x0

 

EnableDeadGWDetect.ini

\Registry\Machine

              System

                   CurrentControlSet

                       Services

                           Tcpip

                                 Parameters

                                     EnableDeadGWDetect = REG_DWORD 0x0

 

KeepAliveTime.ini

\Registry\Machine

              System

                   CurrentControlSet

                       Services

                           Tcpip

                                 Parameters

                                     KeepAliveTime = REG_DWORD 0x493e0

 

NoNameReleaseOnDemand.ini

\Registry\Machine

              System

                    CurrentControlSet

                        Services

                            Netbt

                                 Parameters

                                     NoNameReleaseOnDemand = REG_DWORD 0x1

Yeah, I am done. How are the other team members going to deploy the script?  I am not sure, but I am out of the office for the rest of the week.

A point that I would like to note; I don't think a script is the best way to deploy these changes. These entries scream for other ways to get them to all of the servers. I gave my recommendation and was out voted. I am practicing a special "I told you so" dance when they realize that I was right. I think I hurt myself, but I should be healed enough to do the dance when I get back in the office.  :)

Yes, these are still a problem. In IIS 5.0, many organizations would perform an installation of IIS 5.0 and totally miss some pretty ugly potential vulnerabilities. The biggest of these include:

• Samples
• Help Files
• IIS Admin (HTML)

Some common sense should tell us that we need to get rid of these potential vulnerabilities in IIS 5.0. However, many of us forget that some of these still exist in IIS 6.0. Samples are samples. Why in the world would you ever want these on a production server? Maybe development, but certainly not in production. The same is true of help files. Why would a server need to refer to help files to keep production code running? Well, of course it doesn't need to do that. A production server runs the code you give it, and it should not run anything else. Then there is the dreaded IIS administration web site. Um, in case you had not noticed, you can manage your servers using the MMC snap-in. It is easy to find, after all, it is called, "Internet Information Services (IIS) Manager." Hmmm, I would bet, based on its name, that it could be used for mananaging Internet Information Services. Don't use the HTML version of the admin tool. You should remove the HTML version of the tool in Control Panel\ Add or Remove Programs\ Add\ Remove Windows Components\ Application Server (Details)\ Internet Information Services (IIS) (Details)\ World Wide Web Service (Details)\ Remote Administration (HTML). Just because a tool exists does not mean you should use it.

Some non-common sense items related to security have to do with the NTFS permissions on many directories. These directories (OK, you can call them folders if it makes you feel better) should be secured so that administrators have full control, System has full control, and authenticated users have read access:

• \InetPub
• \InetPub\wwwroot
• \InetPub\ftproot
• \InetPub\mailroot
• \Program Files\Common Files\Microsoft Shared\web server extensions\50
• \InetPub\Scripts

These files should be secured so that administrators have full control, System has full control, and authenticated users have read and execute access:

• \Program Files\Common Files\System

Make sure that the permissions for this folder (does that make you feel better?) is secured so that administrators have full control and System has full control.

• \%systemroot%\help\iishelp
• \InetPub\AdminScripts
• \%systemroot%\system32\inetsrv
• \%systemroot%\system32\inetsrv\History

There is much more than you can do to help secure IIS. For example there is a whole slew of information on hardening TCP/IP that I may write about in the near future.

I am still working on the final bits of my IIS 6.0 Security presentation for TechMentor in April. One of the pieces that seems to have a great deal of conflicting information is what services are required by IIS 6. So, here goes:

Required Services include:

• Event Log - My recommendation is to follow the suggested settings in the Threats and Countermeasures white paper in chapter 3. http://www.microsoft.com/technet/security/topics/serversecurity/tcg/tcgch00.mspx
• IIS Admin Service - Without the admin service, you can't provide Web, FTP, SMTP, or NNTP services.
• HTTP SSL - Since I condone using SSL for all private communications involving customer data and proprietary information, this should be required.
• MSDTC - This is only required when using the two phase commit feature of COM+. In many cases, it is recommended that MSDTC be use from another server in the environment.
• Protected Storage - Used to mainatain certificate information like private  keys. A requirement for CAs. SSL and SMIME will not work unless Protected Storage is running.
• Remote Procedure Call (RPC) - RPCs are used for many different components of Windows. RPC is a requirement for BITS, IISAdmin, COM+, Certificates, and so on.
• Remote Procedure Call Locator - Used for named pipe connectivity.
• Server - The server service is required to receive RPCs. Even though an IIS server does not need to act as a file server or print server, it still needs RPC support.
• Workstation - The workstation service is needed to establish connections to remote systems, including named pipes connections. If your IIS server uses a back-end SQL server, then you will need to keep the workstation service running. The workstation service does not impact the use of IE or other browsers to make HTTP connections. This service is also vital if you are using UNC names to connect to content.
• NTLM Security Support Provider - Provides security for all services and components that are not able to use Kerberos. This service is vital if the IIS server is not a member of a domain.
• World Wide Web Publishing Service - Well, duh... Without this service, your server will not be able to respond to web requests.

Potentially Required Services

• Certificate Authority - This service is required if you plan on the IIS server running as a CA.
• Index - Used to build and maintain an index that can be used by a search component on the web server.
• FTP Publishing Service - Used to provide access to the server using FTP. This service should be hosted on its own server where it can be highly secured as it has many vulnerabilities associated with it.
• NNTP Service - This service should be installed if you intent to make content available via news readers.
• SMTP Service - This service should only be enabled if there is no other available SMTP server available for use by the web server. If this service is used, it should be secured.
• Plug and Play - This service is used to identify new/changed hardware, install the drivers, and activate the hardware. It should only be used if required to install and maintain the server hardware.
• Uninterruptible Power Supply (UPS) - Only needed if you have a UPS, which you should, to support your web server.

Not Required by Most Installations - Most of these following services have several vulnerabilities associated with them. I strongly encourage turning these services off when possible, which should be almost all of the time.

• Alerter
• ClipBook Server
• Computer Browser
• DHCP Client
• Messenger
• NetBIOS Interface
• Net Logon
• Network DDE & Network DDE DSDM
• Network Monitor Agent
• NWLink NetBIOS
• NWLink IPX/SPX Compatible Transport (not required unless you don't have TCP/IP or another transport)
• Simple TCP/IP Services
• Spooler
• TCP/IP NetBIOS Helper
• WINS Client (TCP/IP)

<updated because Neil MacMurchy caught something that I missed>

I was playing with this new tool (in the soon to be released SP1 for Windows Server 2003) and must say that I am very pleased. I am actually a bit shocked at how well this wizard has been done. It has great levels of detail available and it provides administrators many different options in creating and utilizing security policies.

SCW is a fantastic new tool, and I can see it making life easy for administrators around the world. I fired up the wizard and started walking through the steps, and about 15 minutes later, I had a new security policy and applied it to my web servers. Whether it is a good policy or not isn't the issue.

SCW allows administrators to configure policies based on:

• Server role such as Web Server, Email Server, File Server, and so on. In the case of servers that support multiple roles, it is possible to select multiple roles.
• Client features such as DNS client, Domain member, and so on. After all, most servers also have some client configuration requirements.
• Administration and Other Options such as acting as the browse master allowing for remote administration of services like WINS, DHCP, etc.
• Additional services which includes antivirus and other third party applications.
• Handling Unspecified Services which allows unspecified (meaning those not addressed earlier in the wizard) services to disable those services automatically or not change the start up mode of those services.
• Open Ports and Approved Applications which lets the administrator select and or deselect specific ports or ports associated with certain services such as all ports required for Active Directory replication.
• Require SMB Security Signatures which allows configuration for down level operating systems and also allows configuration for signing of all file and print traffic if the CPU has available capacity.
• Require LDAP Signing configuration for Windows 2000 SP3 and later operating systems.
• System Audit Policy configurations.
• and so on and so on and so on...

SCW provides a great deal of granularity for all sorts of implementations. Each of the check boxes usually includes an option where you can see the details relating to the option and get a mini explanation for each option.

My favorite feature has to be the ability to roll back any security policies applied using this wizard. I love "un-do" and "do-over" options.

If you haven't played with this new tool, crank it up. It is easy and very useful. As I tell my Unix administrator friends, "You too can point and click your way to happiness as a Windows administrator."

Wow, there is a great deal of confusion on this subject. I asked a few people what they thought this topic is in their minds. I heard several differing views regarding what it means to secure IIS 6.0. So, what is it? Is it securing the server? Is it securing the service? Is it securing the application or site?

I tend to lean towards the definition including securing the application or site more than anything else. The goal is to make sure the website and any applications available through the website is available to users. Now, that goal does include securing the server and securing the service, but if you include the website content/applications then you are adding another level to the issue.

So, we secure the server doing such fun tasks as turning off unused services and basically locking down the operating system. We put the server in a well protected DMZ. We can also perform such tasks as enabling IP filtering and configuring filters on the firewall(s) to help protect the server from unauthorized port access. We can turn off ICMP ping responses to make the server and its IP address a black hole to script kiddies. We should install antivirus software and anti spyware software. There are so many things we can do and should do.

Some tasks that I am not hearing when it comes to securing IIS 6.0 include using tools to republish the site on a regular basis and moving the actual content to servers inside the LAN. If your site is defaced by some incredibly industrious hacker, you can write right back over it with your approved content using several different applications or home grown scripts. The hacker gets the joy of defacing your site for a few minutes and *poof* it is right back to the way it should be in a matter of moments. they can't even brag to their friends that they did it because it is back to normal so quickly. One of my favorite methods of securing content and applications is to have the actual content and the application data inside the LAN. The server can sit in the DMZ, but we can use the features of IIS to redirect requests for content and data back through the inside firewall to internal servers. Even if the IIS server is somehow compromised, they still don't have access to the data in many cases.

Security really isn't that difficult to implement. I think the key is to keep the basic security concepts in mind when designing your IIS 6.0 solution. Don't allow more access than is required to view the content or run the applications. Don't allow developers any access to the production box. After all, they are supposed to develop in a development environment, test in a test environment and then turn it over to the systems engineer to deploy the final solution in a production environment. Keep in mind the many different levels of security available to you. Watch the site constantly (or monitor it using good products) and be prepared to repair as necessary. Work closely with the others involved such as the network team and the end users to make sure we do everything we can to keep the solution secure.

By the way, I didn't even talk about SSL yet.

Stay tuned, there is more to follow on this subject as I flesh it out. I need to do this soon as I am supposed to present a session on IIS 6.0 Security at TechMentor in Orlando this April.