Project Securing Windows Server 2008: This tutorial shows how to secure different sections of Windows Server 2008

Purpose
The purpose of this documentation is to show various things on Windows Server 2008 that you can make more secure such as RDP, FTP, and websites.

Disabling SSL 2

(Enlarge)

Server 2008, by default, does not have an entry in the registry to disable SSL 2.0 (for server). Although the server can negotiate the most secure protocol to use based on what the client can support (there are cases where a client may have SSL 2.0 but not other protocols such as SSL 3), some security auditing firms consider SSL 2.0 to be a security vulnerability (I guess more vulnerable than a client/server with no encryption). So, in order to pass an audit you have to disable SSL 2.0 in the registry.

Windows Update

Windows Update, by default, will automatically download and install updates. Some of those updates may require the server to restart.
You could leave the settings as they are, or change the time of downloads and installations to be at a low traffic time period (assuming you have 100% confidence that an installation will not prevent the server, services or something unique from starting back up afterwards).
If you prefer to manage updates yourself you could perform the following:
Open Windows Update. Click on "Change settings". Under "Important Updates" select "Check for updates but let me choose whether to download and install them".
Under "Recommended updates" check "Give me recommended updates the same way I receive important updates".
Under "Who can install updates" UNCHECK "Allow all users to install updates on this computer" and click "OK".
NOTE: Although not related to Windows update, you should create a local administrator account for the server (with a long username and longer password) and specify the administrator cannot change their password. Then disable or delete the default administrator account.

RDP (Remote Desktop Protocol)

(Enlarge)	RDP on a server allows you to logon to it as if you were physically sitting at the server (or interacting with the server through the console tab of VMWare). RDP is much more secure than what it has been, by default, in past years. To begin with, open the Remote Session Host Configuration on the server, right-click the connection and select properties.
(Enlarge)	Select "FIPS Compliant" for encryption level and check "Allow connections only from computers running Remote Desktop with Network Level Authentication". PCI Compliance: If the server needs to be PCI compliant, RDP cannot run in "FIPS Compliant" mode because RDP uses TLS 1.0 (as of 2012) - instead "High" would need to be selected along with "Allow connections only from computers running Remote Desktop with Network Level Authentication" - OR - if the server is running in as a VM, you could leave RDP disabled. If you were to leave the setting "FIPS Compliant" and locked down the server (cipher suites, etc) you would not be able to RDP to the server.
(Enlarge)	Depending on what computers/servers you may have on your network, they may or may not be able to support network level authentication. Click "OK". OPTIONAL: Depending on what you have configured for RDP (aka terminal services) you may need to conserve server resources by booting off RDP users who are inactive for an extended period of time. The steps below show how set this up: Right-click the Connection (usually called "RDP-Tcp") and select Properties. On the Sessions tab, check "Override user settings" and select something like 3 hours for "End a disconnected session". Under the following section for "Idle session limit" select something like 3 hours. Check "Override user settings" and "Disconnect from session".
(Enlarge)	Now you'll need to change the security options for the policy governing the server. Set the four policies as shown in red.
(Enlarge)	While you've got the policies open, there are a few other settings for Network Access to check as shown. OPTIONAL: You may also wish to set-up an "are you authorized" message that all RDP users would see when connecting to the server as detailed below: Under the policy "Interactive logon: Message title for users attempting to log on" set the value to "IT IS AN OFFENSE TO CONTINUE WITHOUT PROPER AUTHORIZATION" Under the policy "Interactive logon: Message text for users attempting to log on" set the value to "This system is restricted to authorized users only."
(Enlarge)	The next thing that may be beneficial is to change the port that RDP operates from (instead of the default port). For this example, let's say the port would be 1234. When someone would RDP they would RDP to the server like servername:1234. See this Microsoft note. To change the port, open the registry editor and go to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp Locate "PortNumber", select decimal and enter the port number you would like to use (be sure the port number is not being used by another process). In Windows Firewall you may want to copy the existing in-bound RDP rule for port 3389. Then modify the copy. Test the in-bound rule for your unique port number (such as RDP'ing with a different RDP session using the unique port number). Once it is operational, the original RDP in-bound rule could be disabled.
(Enlarge)	How do you find out what a client system may support for RDP? There are a few ways and this shows you how to find out what version of RDP is on a client system by logging into that system and typing "mstsc" at the Start -> Run prompt. Once open, right-click on the top left icon and select "About".
(Enlarge)	The pane that shows up will show you various information regarding the RDP client and if it supports network authentication.

PCI Compliance

(Enlarge)

PCI/DSS compliance is something a growing number of institutions are following (in our context, helping make sure websites which allow people to input payment information are secure).
One of the most well known vulnerabilities involved cipher suites and cipher protocols (which are used in conjunction with an SSL certificate that you may be aware of which is used to create the "https" connection). There is a LOT of varying information on the Internet regarding securing cipher suites and protocols and, perhaps, some confusion. In fact, Microsoft released a patch for the "BEAST" vulnerability that effected essentially all less than TLS 1.1 and across server platforms. Unfortunately, the "fix" for Windows did not apply to Windows Server 2008 Standard - only Windows Server 2008 R2 or newer were addressed.
If you find you are running Server Standard, OR, your server still fails to pass PCI compliance due to a cipher / cipher suite(s) on the server, you can run a GREAT utility (which works with all versions of Windows Server 2008). The utility is called IISCrypto and you can find it here.
Simply download it, copy it over to your server (hopefully you are not surfing from the server), and run it.
If you are running Server 2008 Standard, it does NOT have the capability of supporting TLS 1.1 or TLS 1.2 (which is why you need to still have TLS 1.0 checked for SSL / RDP to function).
Regardless of the Server 2008 type you are running, you should first click the button "PCI" and then check "TLS_RSA_WITH_RC4_128_SHA", "TLS_RSA_WITH_RC4_128_MD5" and "SSL_CK_RC4_128_WITH_MD5" (so all other cipher suites are disabled; you've essentially diabled all the cipher block suites which are the ones that were vulnerable). Once that is completed, restart the server. I don't know about you but I just LOVE restarting servers all the time...umm, NOT.

Securing FTP

(Enlarge)	It is common practice to NOT have FTP enabled under the same domain name as your web site. Instead it is better to either setup a separate domain name or subdomain that allows FTP only and resolves to the physical directory where the website files are located. Even while that will help some with security, more still needs to be done to help secure FTP. Some of the settings that are shown are quite restrictive, but they are applied at the server level. This means that if something is too restrictive for a particular website, you can override the setting at the specific website level. To begin, select "FTP Request Filtering" under the section "FTP".
(Enlarge)	Under the tab "File Name Extensions" file extensions to block from upload/download include .exe, .com, .bat, .cmd.
(Enlarge)	Under the tab "Hidden Segments" either folder or files can be blocked such as: _vti_bin _vti_rpc _vti_txt _vti_pvt _vti_cnf App_Browsers App_Code App_Data App_GlobalResources App_LocalResources App_WebReferences aspnet_client bin global.asax Web References web.config
(Enlarge)	Under the tab "Commands" actual FTP commands can be blocked (some commands can be used to get information about the server) such as: APPE, DELE, HELP, RMD, RNFR, RNTO, STAT, SYST, XRMD, ADAT.
(Enlarge)	At the site level where the FTP is going to be used at, you may want to block all FTP access to IP addresses/domains that should not have access. This makes it possible to continue to block tools which utilize a range of IP addresses with which to try to guess FTP credentials and gain access. The first step is to open "FTP IPv4 Address and Domain Restrictions" and click on "Edit Feature Settings".
(Enlarge)	From the pane that appears select "Deny" for "Access for unspecified clients" and click OK.
(Enlarge)	At this point nobody will be able to login via FTP including yourself. Add 127.0.0.1 so that you can perform local FTP activities (for testing, etc). And then add the IP address(s) of other FTP clients who should be able to FTP. To do this, open "FTP IPv4 Address and Domain Restrictions", click "Add Allow Entry". From here you can add a range of IP addresses or a single IP address at a time to allow.
(Enlarge)	Under FTP authorization rules you can define who (local users or users in your Active Directory) whom can FTP. If you need an administrative person to be able to FTP, do not use a local FTP user like "administrator" or various combinations thereof. Instead, try to at least specify a user group such as administrators (of the server) so only those in that group would have read/write access.

Securing Websites: Header

(Enlarge)	Blocking some of the header information from being sent to a client (along with a webpage, for instance) can be done by removing the X-Powered-By header. While this is helpful, scan tools can still determine the server type by observing other characteristics such as the webpage links in pages, .Net form tags, etc.
(Enlarge)	The configuration file for a server (which goes down to websites) can also be modified to exclude some information regarding the server.
(Enlarge)	This section shows how to get to the httpRuntime to perform some alteration on.
(Enlarge)	Select "False" for the section labeled "enableVersionHeader".
(Enlarge)	Another header that you can prevent from being returned in a response is referred to as "Server:" which normally has a value of Microsoft/IIS... The easiest way to prevent this header from being returned is via urlScan2.0+ (most likely you have it already installed if you are serious about security). All you need to do is locate the urlscan ini file and set the "RemoveServerHeader" value to 1. That's it!
(Enlarge)	Once you are preventing "Server:" from being returned, you cannot declare another "Server:" at the server level (in IIS) and provide a different value. However, you can create a different name/value pair as shown which would be returned in the response data.

Securing Websites: Blocking by IP

(Enlarge)	If you don't have a hardware firewall in front of your web server (or you do but may not be able to add IP addresses to block), you can add IP addresses to block (or allow). At the server level, under "IIS", open the section "IP Address and Domain Restrictions".
(Enlarge)	In this example you can see how to add a deny entry for an IP address. There are sources on the Internet which maintain a list of blacklisted IP addresses that you may wish to consult and add either to this section or your hardware firewall.

Securing Websites: Request Filtering

(Enlarge)	The request filtering section contains a number of tabs (which I'll go through here). Various scan tools will attempt a variety of methods to try to discover weaknesses with a website. This shows some of the ways to eliminate weakness detection. At the server level, under "IIS", open the section "Request Filtering".
(Enlarge)	The "URL" tab allows you to automatically block requests to a website by filtering what is in the URL (after the domain name). Some scans will attempt to inject code into the URL itself or simply request folders of web applications which have been discovered to have had vulnerabilities at some point in time. You don't necessarily need to check for everything possible since you can scale down to what applies to your website/server. Here are a few URL injections that could be blocked: NOTE: These may change over time to include new entries so this is by no means a complete, always updated list. about:blank _vti_bin "http mailto: url(data:image concat( convert( char( /http: no-text server[ authenticate/ servlet/ +CSCOE+ ~/ cgi-bin/ _vti_rpc webalizer/ SProtectLinux/ snoopservlet/ global.asa etc/passwd .htaccess boot.ini .%252e/ cmd.exe .password .show .pwd .jsp .signature .var .htpasswd admin-serv/ util/ wwwroot/ ++++++++++ ....... etc/hosts <script> %3Cscript%3e config.php php.ini soapdocs/ phpnuke/ _vti_txt _vti_pvt level/ modules/ phpBB/ postnuke/ cpanel/ wwwboard/ ../../ etc/shadow tradecli.dll ows-bin/ _vti_cnf _private proxy/ config.inc phpinfo.php _admin/ config[ =http: include/ [path] _includes/ administrator/ classes/ components/ manager/status crossdomain.xml autodiscover.xml autoconfig/ admin/ msoffice/ labels.rdf drupal- usage/ xampp/ iisprotect/ jsp/ system/ mail/ portal/ wsusadmin/ exchange/ RootDevice.xml description.xml profilemanager/ webhost/ winnt/ windows/ ows/ old/ .ssh/ mswsmtp/ inc/ _vti_inf _vti_aut www-data/ root/ ftp/ backup/ server-status \|.php ~.php includes/ upgrade.php phpversion install.php phpinfo changelog /UNION/ /SELECT/ /AND/ ws_ftp.ini rpc/ ?\ owa_util plugins/
(Enlarge)	The "Query Strings" tab allows you to automatically block requests to a website by filtering what is in a query string (that is, www.yoursite.com/?querystringdata). If you don't handle any query string data anywhere in a website (pages, scripts, etc) then you may not need to be too worried about filtering query strings. Below contain some of the query string data that you may consider blocking: NOTE: These may change over time to include new entries so this is by no means a complete, always updated list. %3b %3d concat netsparker convert url(data:image .\|. .../ ...\ %80.. %c0. %c0%2e /windows/ /winnt/ arg=/dir ~/ ..../ etc/passwd ....\ server[ javascript: <script> <IMG%20SRC /system32/ %c1%c1.. %c1%9c.. _mem_bin/ sys:/ %3Cscript%3E webappmon.exe ..\ boot.ini %2F.. ../ pingto= <script> [script] script\| function%20 =http:// 80040e14 [ODBC_SQL_Server_Driver] [SQL_Server] CONFIG[ =' %27+and+%27 %22+and+%22 %27+or+%27 0x31303235343830303536 +union+all+ select+ %60information_schema group+by+ PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 PHPE9568F34-D428-11d2-A769-00AA001ACF42 PHPE9568F35-D428-11d2-A769-00AA001ACF42 PHPE9568F36-D428-11d2-A769-00AA001ACF42 =" %2A%2A5%2A( %21-- ping+- bin/cat usr/sbin echo+' print+' Response.Write( sleep( BENCHMARK( %25n /) %5E(%23 https:// ftp:// =phpinfo UNION%20ALL %27%29%22 %29%20AND%20 SELECT%20%28CASE SELECT%20GENERATE_SERIES %2CDROP%20FUNCTION %2CDROP%20TABLE %2CDROP%20DATABASE SELECT%20UPPER%28 GET_HOST_ADDRESS DUTL_INADDR DCTXSYS.DRITHSX SELECT%20COUNT Either_BOF_or_EOF 404_Object_Not_Found spool/mail die() echo%20%60
(Enlarge)	The "Rules" tab allows you to setup a variety of rules. The rule that I'll focus on here is being able to block requests made with specific user-agents. A User-agent is the identification part of a request that is sent to the website/server for handling. An example user-agent could include firefox, safari, or something else such as a software application name or even code. You an create a filtering rule to block requests based on the user-agent. An example is shown here where I'm adding to the rule to block all user-agent requests with "Gecko/20100101" in the user-agent string. When a request is blocked a 403 (Forbidden) message is returned to the client. Some user-agents that are associated to scan tools include nessus, nikto, sqlmap, w3ap, and many others. Remember, however, while adding known user-agents to this section will cut-down on the use of scan tools, it will only do so for those running scan tools which do not know how to alter the user-agent string.
(Enlarge)	The "HTTP Verbs" tab allows you to block or allow requests that are made based on the verb sent with a request. An example http verb is www.yoursite.com/ GET, where GET is the verb. GET and POST are the most common verbs that are allowed. However, others, used less frequently may not be allowable (depending on what you've got setup). Some of the less commonly used verbs include TRACE, PUT, DELETE, OPTIONS, PATCH, CONNECT.