Web Gateway Deployment Methodologies - SPAN Port Deployment

In today’s complex network architectures, sometimes it seems there are limitless ways to deploy networking equipment. While that may be the case for some networking gear, in actuality there are probably only a few proven deployment methodologies for web gateways that are effective and provide complete security. In this article, we’ll talk about the most four most common different types of web gateway deployments. Sometimes referred to as forward proxies; these devices are used to secure web access for an organization’s internal end-users. The three commonly used deployment scenarios for web gateways are: inline proxy, explicit proxy, transparent and SPAN port. Each one of these deployments has its advantages and disadvantages and we’ve discussed these as we've explain each methodology over the last few days. Today's article is the last in series and covers SPAN port deployments, sometimes referred to as TCP reset.

SPAN Port Deployment

The last deployment methodology we’ll discuss is that of SPAN (Switched Port ANalyzer) port deployment. Sometimes this method is also called TCP Reset deployment, as it relies on TCP resets to implement the policy of the web gateway. A web gateway is deployed by attaching it to a SPAN port on a switch. (See Figure 4) Unlike the other three deployment methods, which process the web traffic and implement policy based on the network response the web gateway issues, a web gateway implemented in a SPAN port, implements policy by issuing a TCP reset to the client system to prevent it from completing the download of offending content..

SPAN Port Advantages

SPAN port deployments allow larger scale deployments because a monitoring mode deployment typically uses less resources than inline, explicit or transparent which must actively process traffic. SPAN port deployment is useful if you think your hardware might be undersized for your needs.

SPAN Port Disadvantages

One of the disadvantages to a SPAN port deployment on a switch, is that it does not see all the traffic. Corrupt network packets, packets below minimum size, and layer 1 and 2 errors are usually dropped by the switch. In addition, it’s possible a SPAN port can introduce network delays. The software architecture of low-end switches introduces delay by copying the spanned packets. Also, if the data is being aggregated through a gigabit port, a delay is introduced as the signal is converted from electrical to optical. Any network delay can be critical, since TCP reset is used to implement policy.

SPAN ports also have an issue when there is an overload of traffic, typically the port will drop packets, and there will be some data loss. In a high network load situation, most web gateways connected to a SPAN port will not be able to respond quickly enough to keep malware from spreading across a corporate network.

Recently a Network World article (Dec 7, 2009) discussed the TCP reset method used by web gateways to implement policy:

Too clever by half, perhaps –TCP RESET has several drawbacks.

First, a cyber attacker can cause a "self-inflicted DoS attack" by flooding your network with thousands of offending packets. The TCP RESET gateway responds by issuing two TCP RESETs for every offending packet it sees.

The TCP RESET approach is worthless against a cyber attacker who uses UDP to "phone home" the contents of your sensitive files.

The gateway has to be perfectly quick; it has to send the TCP RESET packets before the client (victim) has processed the final packet of malware.

Ergo – deep and thorough inspection of network traffic before it's allowed to flow to the client is the most effective way to stop malware.

… In other words, don't just wave at the malware as it goes by.
--Barry Nance, Network World, Dec 7, 2009

Conclusion

While there are four common deployment methodologies to choose from when implementing a secure web gateway, there’s really only three clear common choices for IT departments. The choice between inline, explicit and transparent, will have to be done based on the needs and resources of the organization and the IT department. While SPAN port deployment and TCP reset may seem like a reasonable solution, there are enough drawbacks that a serious web gateway deployment should avoid this methodology.