Once you get Windows up and running, how do you secure it? And what's the deal with installing IIS (Internet Information Server)?
Now that we've discussed how VMware Server works, how to prepare the host server and how to install Windows, let's turn our attention to how to make sure Windows is secure. Then, we'll discuss installation of IIS.
Here are some ways that you can make Windows more secure.
Fake administrator account
Creating a fake Administrator account is a great way to throw off casual busybodies. It will not prevent against any real hacking attempts, but locks are to keep honest people honest, right?
Rename the Administrator account to something else, such as "lucy," and then log out and back in. Once logged in, create a new account called Administrator, cut and paste (not copy) the description of the original Administrator account (now called "lucy") into the fake Administrator account. Set the new account's password to something obscenely long (complexity does not really matter that much, despite what security experts have said for the past 20 years), 50 or more characters and then disable the account. This is just one example of practicing "defense-in-depth."
Secure data area
Next, create the following folder hierarchy on the e:
DATA \var \log \mail \vms \tmp
Some people may notice the similarities with the standard *NIX folder names. Short directory names that are to the point make sense -- that is, if it ain't broke, don't fix it.
Set the security on the var directory so that only the SYSTEM account and the Administrators" group has full control. Remove all other permissions on the var folder, and replace all existing permissions on subfolders with those applied to var.
Now, open the registry editor and set the following values:
- HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Application\File - "e:\var\log\applog.evt"
- HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Security\File - "e:\var\log\seclog.evt"
- HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\System\File - "e:\var\log\syslog.evt"
Reboot the computer so that the new event log settings take affect.
After the reboot, open the Windows firewall settings. Turn on the firewall for all connections (for now) and open the Remote Desktop Port, (port 3389, for remote administration), port 902 (the VMware Server remote console), and ports 8222 and 8333 (the ports the VMware Web site uses for HTTP and HTTPS, respectively).
While the firewall property screen is open, it is not a bad idea to configure the firewall's log settings. Set the location of the firewall log to "e:\var\log\pfirewall.log" It may also be a good idea to increase the default size of the firewall log to something a little meatier, for example, 10 M.
Another great way to ensure a secure server is to disable the services that do not need to be running for that server to serve its purpose. The following services can be safely disabled, and VMware Server will still function:
- Alerter - ClipBook - Computer Browser - Distributed File System - Distributed Link Tracking Client - Distributed Link Tracking Server - File Replication - Indexing Service - Messenger - NetMeeting Remote Desktop Sharing - Network DDE - Network DDE DSDM - Remote Access Auto Connection Manager - Remote Access Connection Manager - Removable Storage - Telephony - Uninterupptable Power Supply - WinHTTP Web Proxy Auto-Discovery Service
Now let's turn our attention to a few strategies you can use to configure IIS.
Restricting MIME types
Important note: If this an existing Web server, be very careful with this step. It could cause the Web server to completely stop serving all content. Proceed with caution.
MIME types tell IIS how to handle different types of files based on the file's 3-letter extension. For example, the extension .exe has a MIME type of "application/octet-stream". This lets IIS know that it is a binary file.
This step will remove all of the MIME types known to IIS. This may seem drastic, but consider this: if a new IIS vulnerability becomes known and it relies on IIS being able to serve a file with the extension "ida," and IIS cannot serve that file because it does know the file's MIME type, what will happen? Nothing. The file will not be served, and the server is secure from that particular exploit.
Open IIS Manager, right-click on the local computer and click Properties. Click on the button labeled MIME Types... Now, click the first entry and then hold down the SHIFT key. Scroll all the way down the list and click the last entry.
If done properly this will have selected the entire list (CTRL-A does not work here). Click the button labeled Remove and acknowledge the warning. There should be no MIME types left at this point.
Click OK and then click OK again.
This step has restricted IIS from serving any non-system MIME type. But IIS needs to be able serve certain files, such as the ones ending in the extension .html. This will be addressed later.
In the IIS manager, right-click on the folder labeled Websites and click Properties. A window will appear and the tab labeled Web Site should be selected by default. Ensure that the box labeled Enable Logging is checked.
Click the button labeled Properties. Check the box next to the text "Use local time for file naming and rollover" and set the "Log file directory" to "e:\var\log"
Click the tab labeled Advanced and ensure that all of the extended options are checked and click OK.
Default content pages
Click the tab labeled Documents. Remove all of the default content pages and then uncheck the box next to the text that reads Enable default content page. The window should now resemble this:
Default Web site and default application pool
One way to ward off attackers is to set a host header value. This completely nullifies attacks coming directly to the IP address of the Web server on port 80, because when a host header value is set, an HTTP request is only considered valid if the request addresses the server with the value set in the host header field.
To set this value expand the Websites folder and right-click on Default Web Site and click Properties. A new window will appear titled Default Web Site Properties. Click the button labeled Advanced towards the top-right of the window.
A new window will appear titled Advanced Web Site Identification. Select the entry that has an IP address value of Default and click the Edit" button. Set the Host Header value to the FQDN of the server and click OK.
Now the window should resemble this:
Congratulations, now attackers cannot brute force the Default Web Site using simply the server's IP address. Not that it matters terribly, since the next step is to disable the Default Web Site and DefaultAppPool.
Expand the folder labeled Websites. Now, right-click on the text Default Web Site and click Stop." Next, expand the folder labeled Application Pools. Right-click on the DefaultAppPool and click Stop.
Because VMware Server does not use the default Web site, it is safe to disable it, as well as the application pool that serves it. The reason for setting the host header even when disabling the Web site is just in case the Web site gets accidentally enabled by a system administrator.
The reason the Default Web Site and DefaultAppPool are not just deleted is because the Default Web Site has a special meaning in the IIS Metabase. It is the only Web site that can ever have a WebSite ID of 1, and some applications require a Web site with an ID of 1 to exist in the IIS Metabase or else they throw a conniption fit.
In the next part, we'll turn our attention to SMTP.
|Go back to part three||Go to part five|
This was first published in October 2007