ADO.NET 1.1 Security Guidelines - Deployment Considerations

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


Contents

Firewall restrictions

If you connect to SQL Server through a firewall, configure the firewall, client, and server. You configure the client by using the SQL Server Client Network Utility and you configure the database server by using the Server Network Utility. By default, SQL Server listens on TCP port 1433, although you can change this. You must open the chosen port at the firewall.

Depending on the SQL Server authentication mode you choose and your application's use of distributed transactions, you may need to open several additional ports at the firewall:

  • If your application uses Windows authentication to connect to SQL Server, the necessary ports to support Kerberos or NTLM authentication must be open.

For networks that do not use Active Directory, TCP port 139 is usually required for Windows authentication. For more information about port requirements, see the articles, TCP and UDP Port Assignments at http://www.microsoft.com/resources/documentation/windows/2000/server/reskit/en-us/tcpip/part4/tcpappc.mspx, and Security Considerations for Administrative Authority at http://www.microsoft.com/technet/security/bestprac/bpent/sec2/seconaa.mspx.

  • If your application uses distributed transactions, for example automated COM+ transactions, you might also need to configure your firewall to allow DTC traffic to flow between separate DTC instances, and between the DTC and resource managers such as SQL Server.

For full configuration details, see the "Step 7. Ports" section in Chapter 18, Securing Your Database Server at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh18.asp

References


Connection string management

Many applications store connection strings in code primarily for performance reasons. However, the performance benefit is negligible, and use of file system caching helps to ensure that storing connection strings in external files gives comparable performance. Using external files to store connection strings is superior for system administration.

For increased security, the recommended approach is to use DPAPI to encrypt the connection string. This is particularly important if your connection string contains user names and passwords. Then, decide where to store the encrypted string. The registry is a secure location particularly if you use HKEY_CURRENT_USER, because access is limited to processes that run under the associated user account. An alternative for easier deployment is to store the encrypted string in the Web.config file.

References


Login account configuration

Many applications store connection strings in code primarily for performance reasons. However, the performance benefit is negligible, and use of file system caching helps to ensure that storing connection strings in external files gives comparable performance. Using external files to store connection strings is superior for system administration.

For increased security, the recommended approach is to use DPAPI to encrypt the connection string. This is particularly important if your connection string contains user names and passwords. Then, decide where to store the encrypted string. The registry is a secure location particularly if you use HKEY_CURRENT_USER, because access is limited to processes that run under the associated user account. An alternative for easier deployment is to store the encrypted string in the Web.config file.

References


Logon auditing

You should configure SQL Server to log failed login attempts and possibly successful login attempts. Auditing failed login attempts is helpful to detect an attacker who is attempting to discover account passwords.

For more information about how to configure SQL Server auditing, see Chapter 18, "Securing Your Database Server." at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh18.asp

References


Data privacy and integrity on the network

If you use SQL authentication to connect to SQL Server, ensure that login credentials are not exposed over the network. Either install a certificate on the database server (which causes SQL Server to encrypt the credentials) or use an IPSec encrypted channel to the database.

The use of IPSec or SSL to the database is recommended to protect sensitive application level data passed to and from the database. For more information, see Chapter 18, "Securing Your Database Server." at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh18.asp

References

Personal tools