How Software Architecture Affects Network Defense

In the course of planning or deploying a software solution, you often have to make adjustments or changes to your network defense. Firewall and packet-filtering policies are often affected by new applications, particularly those that use more than one static port. Issues with network configurations and architectures also occur frequently, including poor reliability and performance. Ensuring that connections carrying sensitive data are encrypted is very important too. Finally, you might have to face an application that uses an operating system that isn't usually deployed in your environment. The following section considers all these potential problems.

Firewall and Packet-Filtering Changes

Probably the most common issue involving software architecture and network defense is that of changing firewall rule sets and router ACLs. Many applications that either are accessed through the Internet or access the Internet themselves might need to pass traffic through your firewalls or routers. In many cases, these applications use protocols or port numbers that you normally do not permit to pass through your firewall. Although on the surface it sounds like it should be easy to just open the required port on the firewall, it's a much more complex issue than that.

Many applications require more than one port to be opened; in fact, some applications require several. This might be because the application uses more than one service; in such a case, it might be acceptable to open each of those ports on your firewall. Unfortunately, some applications or protocols require a range of ports to be openedsometimes dozens or hundreds of port numbers. Examples of this include many instant messenger programs, games, and multimedia and streaming protocols, such as RealAudio. As if that isn't bad enough, some applications assign ports dynamically and use any one of hundreds or thousands of possible port numbers at any time.

If your organization requires the use of these types of applications, you do not have many options. Certain firewalls, such as Sidewinder, provide proxy services for commonly used protocols, particularly multimedia-related ones. As we discuss in Chapter 4, "Proxy Firewalls," these proxies can be extremely helpful in handling application ports securely. Some applications also enable you to restrict the number of ports they usefor example, opening only a small range of ports instead of hundreds. If you have no other option but to open many firewall ports, be sure to strictly limit which internal hosts can be accessed through those ports and, of course, harden those hosts as strongly as possible to limit the risk posed by attacks on them.

Handling Unexpected IP Protocols

It's always possible that an application might use an IP protocol other than TCP, UDP, or ICMP. I was once testing a VPN client application, but my co-worker and I could not get it to work. When we realized that the firewall was blocking the traffic, we were confused because we thought the rule set should be allowing the traffic. We banged our heads on our desks for a while until we found a casual reference in the application manual to the fact that the application used the Generic Route Encapsulation (GRE) protocol, IP protocol 47. Then we did some research on our firewall and found out that although it blocked GRE packets by default, this was not shown in the firewall rule set. After we learned about the GRE protocol, decided it was acceptable to use, and reconfigured the firewall to accept GRE packets, the application was able to communicate properly.

Web Services and Interapplication Communications

Many applications deployed on our networks are designed to interact with human end-users. Another type of software architecture, aptly named Service-Oriented Architecture (SOA), is increasing in popularity and aims at supporting network-based communications between applications. Techniques allowing applications to interact over the Web using standards-based protocols are often called Web Services. For example, Amazon.com allows software developers to use its Web Services interface to programmatically access Amazon.com's systems.

Various protocols exist to facilitate interapplication interactions over the network. For example, Simple Object Access Protocol (SOAP) is an XML-based protocol used in many Web Services implementations. SOAP allows diverse application components to exchange data among each other, even if they were written in different languages and run on different operating systems. A list of interapplication communication protocols also includes the Distributed Component Object Model (DCOM) and the Common Object Request Broker Architecture (CORBA). Unfortunately, the use of these protocols may conflict with network security practices and network configurations.

Although DCOM is a somewhat dated technology at this point, it is still in use on many networks. Created by Microsoft, DCOM dynamically assigns a TCP or (optionally) a UDP port at runtime to each DCOM process. In order for clients to connect to the correct process, they must first connect to the DCOM Service Control Manager (SCM) at port 135 to get the dynamic ports for the process. If this sounds like RPC, that's because DCOM is based on RPC. By default, DCOM uses any available ports for communications, although this can be restricted. Additionally, DCOM does not work in environments using Network Address Translation (NAT) or proxying.

Microsoft is encouraging software developers to move away from DCOM-based architectures toward the Web Services model implemented as part of its .NET platform. .NET uses SOAP, in conjunction with other complementary protocols, to allow distributed applications to communicate with each other over the Web. SOAP is designed make it easy to carry messages over the HTTP protocol, which makes it easy to support SOAP-based interactions that cross a firewall. As a result, you may not have to change your firewall configuration to support a SOAP-based application. On the other hand, because many firewalls allow HTTP traffic to pass with relative ease, you may find it difficult to control what SOAP-based messages are being tunneled in and out of your network.

Note

Although HTTP is the most frequently used protocol for transporting SOAP messages, SOAP could be also transported via other protocols, such as SMTP and FTP.¹

Web Services communications can be encrypted using a protocol such as IPSec or SSL to protect them in transit against unauthorized modification and eavesdropping. For example, an SSL-protected SOAP message can be conveniently tunneled over HTTPS without requiring the developers to implement many application-level security functions. Additionally, a variety of application-level protocols exist for protecting and authenticating Web Services messages if it is not practical to carry them over an HTTP tunnel; examples of such technologies are WS-Security, Security Assertion Markup Language (SAML), and XML DSig.

In addition to DCOM and SOAP, CORBA offers another way of building distributed applications. Internet Inter-ORB Protocol (IIOP) is part of the CORBA standard that was created to ease the implementation of CORBA-based solutions over the Web.² IIOP does not have a fixed port number, and various implementations of IIOP use different port numbers. It is difficult to characterize the issues in deploying an IIOP-based application. However, IIOP is known to have problems with NAT. Also, many IIOP-based applications often require connections to be implemented from client to server and from server to client. This is unusual compared to most application protocols, which make unidirectional connections.

Note

You might be wondering why one web application would use HTTP and another would use a protocol such as IIOP. HTTP, in its purest form, is designed to transfer text only; IIOP is more effective at transferring many types of data other than text, such as arrays.

Fortunately, some firewalls have proxying capabilities for protocols such as IIOP, as well as NAT implementations that can handle them properly. Such firewalls are able to process the application traffic securely by accommodating dynamic port assignments and compensating for NAT-related issues. Newer protocols such as SOAP provide similar functionality to DCOM and IIOP while working within HTTP. By using HTTP as a transport mechanism, application components can communicate with each other using TCP port 80.

If you only consider firewall port numbers, then tunneling applications over HTTP might sound like a great idea because you are probably already permitting port 80 traffic through your firewall. However, doing this has definite disadvantages. Port 80 is intended to carry HTTP traffic for web page access; this application protocol is embedding itself inside HTTP so it can be carried by it. Now you have multiple types of traffic being sent using the same port number. As this trend continues and more applications use HTTP as a transport mechanism, port 80 traffic might become a jumble of applications and protocols that's extremely difficult to monitor and control properly.

Conflicts with Network Configuration

Another problem that occurs with some applications is that they may not work properly with your existing network configuration. A typical example of this is that some applications are incompatible with NAT. We've already mentioned that DCOM and IIOP have problems with NAT; many VPN solutions also encounter similar issues.

So why do many applications have problems with NAT? Applications and application protocols frequently embed the client's actual IP address and port within their data. Remember that with NAT, the IP address and port that the client is actually using are different from the IP address and port that the server sees. In addition, the client's IP address is often a "private" reserved address, such as 10.1.2.3. Some applications insist on sending data to the client's real IP address, rather than the NAT address assigned by the firewall. When the Internet-based application server tries to communicate with your host at 10.1.2.3, instead of the NAT address, it will be unable to do so.

Application Incompatibilities with NAT

One of my former colleagues was involved in the deployment of a business-to-business e-commerce application. The application worked great until it was tested in the production environment, where it wouldn't work properly at all. After several conversations with technical support, she finally reached a support engineer who was able to diagnose the problem: The application was incompatible with NAT. (The application vendor had previously assured her that the software worked just fine with NAT.) The deployment was delayed for weeks while additional network hardware was deployed and new subnets that did not use NAT were created. After much additional work, the application was transferred to the new network addresses, and it was able to work properly.

You may run into compatibility problems between applications and other network components, such as firewalls. These are issues to be particularly cautious about; if the application conflicts with key aspects of your security perimeter, you might need to drastically modify parts of your infrastructure in order to accommodate the application. A great example is a firewall that is not able to handle a particular IP protocol that your application uses. Can you imagine what would happen if a critical application that was about to be deployed in your environment failed to work because your firewall couldn't support the protocol? The earlier in the application deployment process you find out about such compatibility issues, the easier it will be to address them.

Tip

Make sure to document the components of your network infrastructure and review them with the vendor for potential trouble areas before deploying the software.

Encrypting Connections

Many applications do not encrypt the data sent between the user and the application server. The significance of this depends on your organization's security policy. Generally, if the application is running on an internal network and the data is not sensitive, the lack of encryption is not usually a problem. However, if the application carries sensitive data and uses public networks, your policy will probably require the use of encryption. If the application can't encrypt the data, you need to consider using VPN tunnels, such as those that support SSL, to encrypt the connections.

Although it's important to protect connections between users and servers, it's also important to make sure that traffic between servers is protected. For example, you might have a publicly accessible server that accepts information from users and then transmits that information to a database server. The application designers might have assumed that both servers would be on a private network and didn't encrypt the data going between them. If you are deploying a multitier application, be sure to consider the need to secure data connections between the tiers.

Performance and Reliability

An important issue related to software architecture is the effect that network security can have on application performance and reliability. For example, firewalls, especially proxies, can add considerable delay to connections. Encrypting traffic usually adds substantial performance overhead as well. In many cases, these delays won't drastically affect the usability of the application, but they could. As we describe in Chapter 17, "Tuning the Design for Performance," performance and security are often inversely related.

Reliability is another important aspect of software architecture. In many cases, the more components that participate in the application's functionality, the less reliable the application will tend to be. This is because each host or a device represents another component that may fail. For example, if you are deploying a multitier application and have put each tier on a separate host, each separated by firewalls, you need to consider how reliable the overall solution will be. This is not to say you should use as few devices as possible; rather, you should ensure that proper redundancy and fault-tolerance measures are implemented as needed to keep the overall reliability at an acceptable level. For more information on dividing components among hosts, see Chapter 13, "Separating Resources."

Atypical Operating System

Most environments tend to support a few operating systems, such as certain versions of Windows, Solaris, and Linux. Some applications might require the use of a particular operating system that is not normally used in your environment. Of course, the biggest issue is probably that of support: How will your organization be able to support and maintain this operating system?

Another important issue is that of host security. If the application requires the use of an operating system with which your staff is not familiar, the staff isn't likely to have much knowledge of how to secure and maintain it properly. Substantial financial and personnel resources will be required in order to gain and maintain such knowledge; in many cases, these resources are unavailable. Such an operating system is likely to be excluded from standard security maintenance measures due to lack of expertise, making it much more vulnerable to attacks. Whenever possible, it's a good idea for support and security reasons to stick with operating systems with which your technical staff is familiar.