TRAFFIC SCRUBBING
I mentioned packet or traffic scrubbing in Chapter 1 as a form of normalization, or the
process of removing ambiguities in a traffic stream. Chapter 3 briefly expanded on this
idea by mentioning dropping packets with invalid TCP flag combinations. Traffic scrubbing
is related to access control, in that scrubbing can sometimes deny traffic that doesn’t
meet accepted norms. Where scrubbing is implemented, traffic will be somewhat easier
to interpret.
Certain “schools” of intrusion detection spend most of their time analyzing odd
packet traces because they don’t collect much beyond packet headers.3 If unusual packets,
such as IP fragments, are not allowed to traverse the organization’s Internet gateway, they
cannot harm the site. The only justification for analyzing odd traffic is pure research. In
budget-challenged organizations, time is better spent dealing with application content as
shown in transcripts of full content data collected by using NSM techniques.
Traffic scrubbing is another way to make network traffic more deterministic. On some
networks, arbitrary protocols from arbitrary IP addresses are allowed to pass in and out
of the site’s Internet gateway. This sort of freedom helps the intruder and frustrates the
analyst. It is much more difficult to identify malicious traffic when analysts have no idea
what “normal” traffic looks like. Any steps that reduce the traffic variety will improve
NSM detection rates.

PROXIES
Proxies are applications that insert themselves between clients and servers for reasons of
security, monitoring, or performance. A client that wishes to speak to a server first connects
to the proxy. If the client’s protocol meets the proxy’s expectations, the proxy connects
on behalf of the client to the server. Figure 11.2 depicts this exchange.
For the case of HTTP traffic, a proxy like Nylon or Squid that implements the SOCKS
protocol can be used.4 From the prevention point of view, the key element of a proxy is its
protocol awareness. The proxy should be able to differentiate between legitimate and illegitimate
use of the port associated with a protocol. For example, an HTTP proxy should
be able to recognize and pass legitimate HTTP over port 80 TCP but block and log unauthorized
protocols running over port 80 TCP. This scenario appears in Figure 11.3.
Some applications tunnel their protocols within other protocols. For example, tools
like HTTPTunnel can encapsulate arbitrary protocols within well-formatted HTTP
requests.5 If the proxy is not smart enough to recognize that the supposed HTTP traffic
doesn’t behave like legitimate HTTP traffic, the proxy will pass it (see Figure 11.4).
A proxy can be used as an application-based form of access control. If the application
doesn’t speak the protocols expected by the proxy, the proxy won’t forward the traffic.
Many organizations proxy outbound HTTP traffic for purposes of monitoring unauthorized
Web surfing. NSM is more concerned with limiting an intruder’s opportunities for
communicating with the outside world. Projects like DCPhoneHome and Gray-World
are dedicated to finding ways to circumvent outbound access control methods like proxies
and firewall egress control rules.6
Beyond proxies lie application-layer firewalls. These products make decisions based on
the packet or stream application content. Firewall vendors are busy adding these features
to their products. Even Cisco routers, using their Network-Based Application Recognition

ARE ALL OF THESE “MIDDLEBOXES” A GOOD IDEA?
So many systems have been placed between clients and servers that they have their
own name—middleboxes. A middlebox is any device other than an access switch
or router between a client and a server. Because the Internet was designed with an
end-to-end infrastructure in mind, these intervening devices often impair the
functionality of protocols. A few examples of middleboxes include the following:
• Network and port address translation devices
• Proxies
• Load balancing appliances
• Firewalls
So many middlebox devices exist that an informational RFC was written to
describe them (see http://www.faqs.org/rfcs/rfc3234.html). Security architects
must balance the need to protect systems against the possibility their interventions
will break desired features.
A locked-down network is a boring network. Organizations with
well-developed policies, access control, traffic scrubbing, and proxies don’t announce
discoveries of the latest back door on hundreds of their servers. They tend not to get
infected by the latest Trojans or contribute thousands of participants to the bigger bot
nets. They may also suffer the perverse effect of lower budgets because their security
strategies work too effectively, blinding management to the many disasters they avoided.
Keep this in mind if your analysts complain that their work is not challenging.