Chapter 8: LAN Security Requirements

Overview

• Programming with Sockets

• Creating a Secure RPC Environment

• Developing DCOM Applications

• Creating a Secure Server Application Installation

• Creating COM+ Applications

All eyes are focused on the Internet, and therein lies a problem that will cause you more grief than any other security problem. Because the trade press hammers you day and night with news of the truly bizarre attacks that occur on the Internet, it’s easy to forget that the biggest security problem lies on the network that you depend on to accomplish anything at all (including accessing the Internet in many cases). Securing the desktop is a good first step, but if you want a truly secure system, then the network has to be your next priority.

Most of the techniques discussed in the book so far work equally well in a desktop or network situation. For example, a server requires good default security (see Chapter 4) and policies (see Chapter 5). No matter if your code comes from a local or remote source, you still need to validate it to ensure that no one has tampered with it (see Chapter 6). Likewise, you need to check signatures and hashes to ensure that no tampering has occurred (see Chapter 7). If anything, a network environment merely intensifies the requirements for checking every bit of code and data for potential problems. For example, while you might leave code on your local machine unencrypted, many developers make it common practice to encrypt sensitive information for transfer over the network.

Networks also have special requirements and that’s the topic of this chapter. For example, when you transfer data over the wire, you normally rely on sockets to do it. The Remote Procedure Call (RPC) protocol is old, but still used for most data transfers over a network. The fact that you’ve moved to .NET doesn’t mean that you’ve also moved all your code, so you’ll definitely need to work with the Distributed Component Object Model (DCOM) in some way. All of these wire concerns are important because the wire is the first place crackers try to extract data.

A secure network also requires a secure server. Again, by verifying code, users, and data, you can prevent a wide range of problems from occurring. This chapter won’t discuss verification or validation issues that affect the server in general because they were already covered in Chapter 6. However, we haven’t discussed some server specific technologies such as Message Queuing or COM+ yet. In addition, you should employ extra measures for server installations. The second half of the chapter discusses these server-specific issues.

Note

This chapter focuses on what many developers view as the Local Area Network (LAN) environment: a well-defined group of known users connected together to share resources and data. However, this term refers to computers networked within the same physical location. The techniques shown in this chapter also work well with Metropolitan Area Networks (MANs) and Wide Area Networks (WANs). A MAN is a specialized term that refers to computers that reside in the same metropolitan area. It’s larger than a LAN, but smaller than a WAN, and often relies on fiber optic or other high-speed connections. A WAN is a set of remote locations networked together using anything from telephone connections, to satellites, to the Internet. The use of LAN throughout the chapter is generic and can refer to these other configurations. I’ll use a specific reference when you need to know about exceptions.