Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

How To: Use IPSec to Provide Secure Communication Between Two Servers

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation

Published: November 2002

Last Revised: January 2006

Applies to:

• .NET Framework 1.1 and 2.0
• Microsoft® Windows 2000 Server™ and Windows Server 2003

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page a starting point and complete overview of Building Secure ASP.NET Applications.

Summary: IPSec is a technology provided by Windows 2000 that allows you to create encrypted channels between two servers. IPSec can be used to filter IP traffic and to authenticate servers. This How To shows you how to configure IPSec to provide a secure (encrypted) channel. (9 printed pages)

Contents

Notes
Summary of Steps Step 1. Create an IP Filter
Step 2. Create Filter Actions
Step 3. Create Rules
Step 4. Export the IPSec Policy to the Remote Computer
Step 5. Assign Policies
Step 6. Verify that it Works
Summary
Additional Resources

Internet Protocol Security (IPSec) can be used to secure the data sent between two computers, such as an application server and a database server. IPSec is completely transparent to applications because encryption, integrity and authentication services are implemented at the transport level. Applications continue to communicate with one another in the normal manner using TCP and UDP ports.

Using IPSec you can:

• Provide message confidentiality by encrypting all of the data sent between two computers.
• Provide message integrity between two computers (without encrypting data).
• Provide mutual authentication between two computers. For example, you can help secure a database server by establishing a policy that permits requests only from a specific client computer (for example, an application or Web server).
• Restrict which computers can communicate with one another. You can also restrict communication to specific IP protocols and TCP/UDP ports.

This How To shows you how to secure the communication channel between an application server and a database server running SQL Server. The application server uses the recommended TCP/IP client network library to connect to SQL Server and uses the default SQL Server TCP port 1433. The configuration is shown in Figure 1.

Figure 1. How To solution configuration

This How To describes how to use a simple IPSec policy to enforce the following:

• Allow communications with SQL Server only from the application server using TCP through port 1433.
• Drop all other IP packets, including ICMP (ping).
• Encrypt all data sent between the two computers to guarantee confidentiality.

The advantages of this approach are:

• Data confidentiality is provided for all data sent between the two computers.
• The attach surface on SQL Server is significantly reduced. The only remaining points of attack are to interactively log on to the database server or to gain control of the application server and try to attack SQL Server via TCP port 1433.
• The IPSec policy is extremely simple to define and implement.

This particular policy suffers from the following drawbacks:

• SQL Server cannot communicate with domain controllers and as a result:
  • Group policy cannot be applied (the database server should be a standalone server).
  • Windows authentication between the application server and database server requires synchronized local accounts (with the same user name and password) on both computers.
  • You cannot use more robust methods of applying IPSec (Windows 2000 Server / Windows Server 2003 default / Kerberos).
• SQL Server will not be able to communicate with other computers, including DNS servers.
• The approach presented in this How To uses pre-shared key authentication, which is not recommended for production scenarios. Production systems should use certificates or Windows 2000 / Windows 2003 domain authentication. IPSec policies that use pre-shared secrets are suitable for use in development or test environments only.
• Both computers must have static IP addresses.

Notes

• An IPSec policy consists of a set of filters, filter actions, and rules.
• A filter consists of:
  • A source IP address or range of addresses.
  • A destination IP address or range of addresses.
  • An IP protocol, such as TCP, UDP, or "any."
  • Source and destination ports (for TCP or UDP only).
• Filters can also be mirrored on two computers. A mirrored filter applies the same rule on client and server computer (with the source and destination addresses reversed).
• A filter action specifies actions to take when a given filter is invoked. It can be one of the following:
  • Permit. The traffic is not secured; it is allowed to be sent and received without intervention.
  • Block. The traffic is not permitted.
  • Negotiate security. The endpoints must agree on and then use a secure method to communicate. If they cannot agree on a method, the communication does not take place. If negotiation fails, you can specify whether to allow unsecured communication or to whether all communication should be blocked.
• A rule associates a filter with a filter action.
• A mirrored policy is one that applies rules to all packets with the exact reverse of the specified source and destination IP addresses. A mirrored policy is created in this How To.

Summary of Steps

This How To includes the following steps:

• Step 1. Create an IP Filter
• Step 2. Create Filter Actions
• Step 3. Create Rules
• Step 4. Export the IPSec Policy to the Remote Computer
• Step 5. Assign Policies
• Step 6. Verify that it Works

Step 1. Create an IP Filter

To create a new IP filter on the database server computer

1. Log on to the database server as an administrator.

2. Start the Local Security Policy Microsoft Management Console (MMC) snap-in from the Administrative Tools program group.

3. In the left pane, right-click IP Security Policies on Local Machine, and then click Manage IP filter lists and filter actions.

   You will see that two filter lists are already defined for all ICMP traffic and all IP traffic.

4. Click Add.

5. In the IP Filter List dialog box, type SQLPort in the Name field.

6. Click Add, and then click Next to move past the welcome dialog of the IP Filter Wizard.

   Note   If you are running Windows Server 2003, clicking Next will open the IP Filter Description and Mirrored property dialog box, where you can add description and detailed explanation for the filter in the Description text box. Ensure that the Mirrored check box is selected and then click Next. Mirroring the filters automatically configures both inbound and outbound filters.

7. In the IP Traffic Source dialog box, select A specific IP Address from the Sourceaddress drop-down list, and then enter the IP address of your application server computer.

8. Click Next.

9. In the IP Traffic Destination dialog box, select A specific IP Address from the Destination address drop-down list, and then enter the IP address of your database server computer.

10. Click Next.

11. In the IP Protocol Type dialog box, select TCP as the protocol type, and then click Next.

12. In the IP Protocol Port dialog box, select From any port, and then select To this port. Enter 1433 as the port number.

13. Click Next, and then click Finish to close the wizard.

14. Click Close to close the IP Filter List dialog box.

Step 2. Create Filter Actions

This procedure creates two filter actions. The first will be used to block all communications from specified computers and the second will be used to enforce the use of encryption between application server and database server computers.

To create filter actions

1. Click the Manage Filter Actions tab.

   Note that several predefined actions are already defined.

2. Click Add to create a new filter action.

   In the next few steps, you will create a block action that can be used to block all communications from selected computers.

3. Click Next to move past the initial dialog box of the Filter Action Wizard.

4. In the Name field, type Block, and then click Next.

5. In the Filter Action General Options dialog box, select Block, and then click Next.

6. Click Finish to close the wizard.

7. Click Add to start the Filter Action Wizard again.

   In the next few steps, you will create a filter action to force the use of encryption between application server and database server computers.

8. Click Next to move past the initial dialog box of the Filter Action Wizard.

9. In the Name field, type Require High Security, and then click Next.

10. Select Negotiatesecurity, and then click Next.

11. Select Do not communicate with computers that do not support IPSec, and then click Next.

12. Select Custom, and then click Settings.

13. Make sure that the Data integrity and encryption (ESP) check box is selected.

14. Select SHA1 from the Integrity algorithm drop-down list.

15. Select 3DES from the Encryption algorithm drop-down list.

16. Select the two check boxes within the Session Key Settings group to generate a new key every 100000 Kb and 3600 seconds respectively.

17. Click OK to close the Custom Security Method Settings dialog box, and then click Next.

18. Select the Edit Properties check box, and then click Finish.

19. Clear the Accept unsecured communication, but always respond using IPSec check box.

20. Select the Session key Perfect Forward Secrecy check box, and then click OK.

21. Click Close to close the Manage IP filter lists and filter actions dialog box.

Step 3. Create Rules

This procedure creates two new rules that will be used to associate the filter that you created in Procedure 1, with the two filter actions you created in Procedure 2.

To create rules

1. In the left pane, right-click IP Security Policies on Local Machine, and then click Create IP Security Policy.

2. Click Next to move past the initial dialog box of the IP Security Policy Wizard.

3. In the Name field, type Secure SQL, and then click Next.

4. Clear the Activate the default response rule check box, and then click Next.

5. Leave the Edit properties check box selected, and then click Finish.

6. Click Add to start the Security Rule Wizard.

7. Click Next to move past the initial dialog box of the Security Rule Wizard.

8. Click This rule does not specify a tunnel, and then click Next.

9. Click All network connections, and then click Next.

   Note   If you are running Windows Server 2003, clicking Next will open the IP Filter List dialog box, so you will need to choose the IP filter and Filter action before you choose the authentication method. When running Windows Server 2003, perform steps 13, 14, and 15 before performing steps 10, 11, and 12, and then complete step 16 onward.

10. Click Use this string to protect the key exchange (preshared key).

11. Enter MySecret as a "secret" key in the text box.

    Note   This key must be the same for both computers in order for them to successfully communicate. You should use a long random number, but for the purposes of this How To, "MySecret" will suffice.

12. Click Next.

13. Select the SQL Port option.

14. Click Next.

15. Select the Require High Security option, and then click Next.

16. Click Finish to return to the Secure SQL Properties dialog box.

17. Click Add to start the Security Rule Wizard again, and then click Next to move past the initial dialog box.

18. Click This rule does not specify a tunnel, and then click Next.

19. Click All network connections, and then click Next.

    Note   If you are running Windows Server 2003, clicking Next will open the IP Filter List dialog box, so you will need to choose the IP filter and Filter action. Because this is a blocking filter, it will automatically choose Kerberos as the authentication method. When running Windows Server 2003, complete step 21 onward.

20. In the Authentication Method dialog box, leave Windows 2000 default (Kerberos V5 Protocol) selected, and then click Next.

    Note   This rule will specify the Block filter action, so no authentication will be needed.

21. In the IP Filter List dialog box, click All IP Traffic, and then click Next.

22. In the Filter Action dialog box, select the Block option, and then click Next.

23. Click Finish.

24. Click Close to close the Secure SQL Properties dialog box.

Step 4. Export the IPSec Policy to the Remote Computer

The IPSec policy that you have created on the database server must now be exported and copied to the application server computer.

To export the IPSec policy to the application server computer

1. In the left pane, right-click the IP Security Policies on Local Machine node, point to All Tasks, and then click Export Policies.

2. In the Name field, type Secure SQL, and then click Save to export the file to the local hard disk.

3. Either copy the .ipsec file across to the application server or make it available by using a file share.

   Important   Because the exported policy file contains a pre-shared key in clear text, the file must be properly secured. It should not be stored on the hard disk of either computer.

4. Log on to the Application Server as an administrator and start the LocalSecurityPolicy MMC snap-in.

5. Select and right-click IP Security Policies on Local Machine, point to All Tasks, and then click Import Policies.

6. Browse for the previously exported .ipsec file and click Open to import the policy.

Step 5. Assign Policies

An IPSec policy must be assigned before it becomes active. Note that only one policy may be active at any one time on a particular computer.

To assign the Secure SQL policy on the application server and database server computers

1. On the application server computer, right-click the newly imported Secure SQL policy, and then click Assign.

2. Repeat the previous step on the database server computer.

   The mirrored policy is now assigned on both computers.

   The policies ensure that only the application server can communicate with the database server. Furthermore, only TCP connections using port 1433 are permitted and all traffic sent between the two computers is encrypted.

Step 6. Verify that it Works

This procedure uses Network Monitor to verify that data sent between the application server and database server is encrypted.

To verify that it works

1. On the application server computer, use Visual Studio .NET to create a new C# Console Application called SQLIPSecClient.

2. Copy the following code to class1.cs replacing all of the existing code.

   Note   Replace the IP address in the connection string with the IP address of your database server.

   using System;
   using System.Data;
   using System.Data.SqlClient;
   
   namespace SQLIPSecClient
   {
     class Class1
     {
       [STAThread]
       static void Main(string[] args)
       {
         // Replace the IP address in the following connection string 
         // with the IP address of your database server
         SqlConnection conn = new SqlConnection(
           "server=192.168.12.11;database=NorthWind;Integrated 
             Security='SSPI'");
   
         SqlCommand cmd = new SqlCommand(
                                 "SELECT ProductID, ProductName FROM 
                                   Products");
         try
         {
           conn.Open();
           cmd.Connection = conn;
           SqlDataReader reader = cmd.ExecuteReader();
           while (reader.Read())
           {
             Console.WriteLine("{0} {1}", 
                        reader.GetInt32(0).ToString(), 
                        reader.GetString(1) );
           }
           reader.Close();
         }
         catch( Exception ex)
         {
         }
         finally
         {
           conn.Close();
         }
       }
     }
   }
   

3. On the Build menu, click Build Solution.

4. In order for Windows authentication to succeed between the two computers, you must duplicate the account that you are currently interactively logged on to the application computer with, on the database server computer. Ensure that the user name and password matches.

   You must also use SQL Server Enterprise Manager to create a database login for the newly created account and add a new database user for this logon to the Northwind database.

5. Temporarily un-assign the Secure SQL IPSec policy on both computers:

   1. Start Local Security Settings on the application server computer.
   2. Click IP Security Policies on Local Machine.
   3. In the right pane, right-click Secure SQL, and then click Un-assign.
   4. Repeat Steps a–c on the database server computer.

6. On the database server computer, click NetworkMonitor in the AdministrativeTools program group.

   Note   A limited version of Network Monitor is available with Windows 2000 Server and Windows Server 2003. A full version is available with Microsoft SMS.

   If you do not have Network Monitor installed, go to Add/Remove Programs in Control Panel, click Add/Remove Windows Components, select Management and Monitoring Tools from the Windows Components list, click Details, and then click Network Monitor Tools. Click OK, and then click Next to install the limited version of Network Monitor. You may be prompted for a Windows 2000 Server or Windows Server 2003 installation CD.

7. On the Capture menu, click Filter to create a new filter configured to view TCP/IP network traffic sent between the application server and database server.

8. Click the Start Capture button.

9. Return to the application server computer and run the test console application. A list of products from the Northwind database should be displayed in the console window.

10. Return to the database server and click the Stop and View Capture button within Network Monitor.

11. Double-click the first captured frame to view the captured data.

12. Scroll down through the captured frames. You should see the SELECT statement in clear text followed by the list of products retrieved from the database.

13. Assign the Secure SQL IPSec policy on both computers:

    1. Start Local Security Settings on the application server computer.
    2. Click IP Security Policies on Local Machine.
    3. In the right pane, right-click Secure SQL, and then click Assign.
    4. Repeat Steps a–c on the database server computer.

14. In Network Monitor, close the capture window.

15. Click the StartCapture button, and then click No in the SaveFile message box.

16. Return to the application server computer and run the test console application once again.

17. Return to the database server computer and click Stop and View Capture within Network Monitor.

18. Confirm that the data is now unintelligible (because it is encrypted).

19. Close Network Monitor.

Additional Resources

For more information about IPSec, see IP Security and Filtering.

For more information about Network Monitor, see the Network Monitor section of the Microsoft Platform SDK on MSDN.

© Microsoft Corporation. All rights reserved.