Lock Down IIS and SQL Server - Page 2

By Deann Corum | Posted Sep 29, 2005
Page 2 of 2   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Continued From Page 1

Tools for Securing IIS
Use Windows Update and Automatic Updates for single-server installations.

Use Systems Management Server (SMS) or Windows Server Update Services (WSUS) for managed environments or where administrators that have responsibilities for multiple disparate systems.

Microsoft Baseline Security Analyzer (MBSA) assists the system administrator in scanning local or remote systems for current patches. This tool works on Windows NT 4, Windows 2000, Windows XP and Windows 2003.

Use the IIS Lockdown Tool or Security Configuration Wizard (SCW) to harden your IIS installation and server. Use URLScan to filter HTTP requests. URLScan is part of the IIS Lockdown Tool and can be configured to reject maliciously formed HTTP requests such as those in Code Blue and Code Red, before the server even attempts to process them.

Download these tools to another machine and copy them to your IIS server before connecting it to the Internet. Avoid connecting your IIS server to the Internet until it is completely analyzed and patched.

Changing the Default Port SQL Uses
(Click for a larger image)
SQL Specific Security Recommendations
The most widespread SQL attack isn't even covered by a security bulletin. It's a straightforward login attempt made on the SA account with a blank password. Microsoft SQL Server installs with a blank SA account password by default and this should be the first thing you change.

Another common cause of the blank password is products. For example some versions of Visio install Microsoft SQL Server 2000 Desktop Engine (MSDE) and never change the SA password. A user may not even know that they have MSDE running. You can download a program from eEye Digital Security that scans your network for SQL Servers with blank SA accounts. .

SQL Server Security Checklist

  1. Set a password on your SA account and restrict its use. Also, change the password periodically to keep it from 'propagating' and being used by developers or too many administrators. Change the SA password if anyone who knows it leaves the company. Use eEye's tool to scan your network for SQL servers with no SA password.
  2. Place your SQL Server behind a firewall, separate from your IIS or Web servers. Only allow connections to the SQL server from those designated web servers. Your SQL server should never be Internet-facing or publicly accessible.
  3. Remove BUILTIN/Administrators from the sysadmin role and give sysadmin rights in SQL to specific domain accounts that need it.
  4. Use Windows Authentication and Windows Only Mode if possible. This way, a potential hacker must authenticate to the domain first instead of just to SQL Server.
  5. Do not run SQL Server on a Domain Controller.
  6. Change the SQL Server service startup account to something besides LocalHost.
  7. Enable the Failed Login option (Server Properties | Security tab) so you can look for failed logins to see if an unauthorized person is trying to access the server. Monitor the SQL logs and set up alerts in SQL using NETSEND or email, if possible.
  8. Keep up to date on patches and service packs for the operating system and SQL. See Tools for Securing IIS for some options.
  9. Protect any Extended Stored Procedures. Control all data access through stored procedures and grant access to those instead of giving blanket db_datareader and db_datawriter permissions to the data itself. See Part I of this article for more information.
  10. Change the standard SQL Server port under the Server Network Configuration Utility and block the default port of 1433. Have your network administrator allow the new port instead.
  11. Make sure the Everyone group doesn't have write access to SQL Server registry keys.

Resources

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter