Remoting

This section identifies the key review points that should be considered when you review your application's use of .NET Remoting. For more information about the issues raised in this section see Chapter 17, "Securing Your Application Server."

When you review your .NET Remoting solution, start by identifying which host is used to run your remote components . If you use the ASP.NET host with the HttpChannel , you need to check that IIS and ASP.NET security is appropriately configured to provide authentication, authorization, and secure communication services to your remote components. If you use a custom host and the TcpChannel , you need to review how your components are secured, because this host and channel combination requires custom authentication and authorization solutions.

Port Considerations

Remoting is not designed to be used with Internet clients. Check that the ports that your components listen on are not directly accessible by Internet clients . The port or ports are usually specified on the <channel> element in the server side configuration file.

Hosting in ASP.NET with the HttpChannel

If you use the ASP.NET host, review the following items:

• How do you protect sensitive data over the network?

  Do you use SSL or IPSec? Without SSL or IPSec, data passed to and from the remote component is subject to information disclosure and tampering. Review what measures are in place to address the network eavesdropping threat.

• How do you authenticate callers ?

  Make sure that anonymous access is disabled in IIS for your application's virtual directory. Also check that you use Windows authentication. The Web.config of your application should contain the following configuration.

   <authentication mode="Windows" /> 

• Do you use ASP.NET file authorization?

  If not, why? You can use ASP.NET file authorization to control access to the endpoints of your remoting application by creating a .rem or .soap file and configuring the NTFS permissions on the file. The ASP.NET FileAuthorizationModule will then authorize access to the component. For more information, see" Authorization" in Chapter 13, "Building Secure Remoted Components."

• Do you use URL authorization?

  Check your application's use of the <authorization> element. Use the ASP.NET UrlAuthorizationModule by applying <allow> and <deny> tags.

• Do you prevent detailed errors from being returned to the client?

  Check the configuration of your application to make sure that you have correctly configured the <customErrors> element to prevent detailed errors from being returned to the client. Make sure the mode attribute is set to On as shown below.

   <customErrors mode="On" /> 

• What identity do you use to run ASP.NET?

  Check that you use a least privileged account to run ASP.NET, such as the default ASPNET account, or Network Service account on Windows Server 2003.

Hosting in a Custom Process with the TcpChannel

If you use a custom host process such as a Windows service, review the following items.

• How do you protect sensitive data over the network?

  Have you secured the channel from client to server? You may use transport level IPSec encryption or your application may use a custom encryption sink to encrypt request and response data.

• How do you authenticate callers?

  The TcpChannel provides no authentication mechanism, so you must develop your own. Review how your application authenticates its callers.

• Do you restrict your clients?

  Remoting with the TcpChannel is designed to be used in trusted server scenarios, where the remote components trust their clients. Do you restrict the range of clients that can connect to your remote components, for example, by using IPSec policies?

• Do you use a least privileged process identity?

  Review which account you use to run your custom host process and ensure it is configured as a least privileged account.