Packeteer Home Page Choose a PacketGuide version   

 Feedback

 Search

 Index

 Contents

What's New?
 

 

   
   
   
   
   
   
   
   
   
   

 Tasks

 PolicyCenter Tasks

 Reference

 Product Information
 


Secure Your WAN Applications

Procedures to use the PacketShaper for WAN application security

Traditional IDS/IPS and firewall systems focus on the network perimeter and prevent intrusions from outside hackers and malicious intruders. A firewall uses security policies and filters to prevent unauthorized or potentially dangerous material from entering the network. But what if a threat somehow sneaks through the perimeter and creeps inside the network onto your WAN? Or what if a virus or attack starts inside the LAN?

Companies need security on the inside: every enterprise should have a WAN application security system. This type of system uses the same elements as a perimeter IPS, but applies them to applications and traffic on the WAN or LAN. The PacketShaper offers a number of features that focus on preventing disruptions and unauthorized activities on the network. This recommendation shows you how to use PacketShaper features to perform the following types of network security:

Application Flow Validation

The growing complexities associated with network traffic make sophisticated classification techniques a necessity. Simple IP address or static port schemes fall short. Packeteer’s classification detects dynamic and migrating port assignments, differentiates applications using the same port, and uses Layer 7 application indicators to identify applications. The PacketShaper allows you to verify that an application flow is what it’s supposed to be.

As a response to the PacketShaper's powerful classification and control capabilities, clever hackers continually attempt to circumvent the road blocks Packeteer has put up for them. With the PacketShaper's ability to identify and block/contain recreational traffic, people have tried different ways to masquerade this traffic as innocent web-browsing.

Web Proxies

Suppose some of your employees have installed web proxy tools (such as proxifier, proxster, and proxyshare) that allow them to send traffic (such as KaZaA, Morpheus, and ICQ) through an HTTP tunnel. Since HTTP traffic (port 80) can get through the firewall, they are able to bypass the firewall rules. However, the PacketShaper is able to spot peer-to-peer traffic hiding inside an HTTP tunnel. The HTTP-Tunnel service automatically identifies and classifies traffic that is sent through an HTTP tunnel via an HTTP proxy server on the Internet. Once this traffic is classified, you can restrict this unsanctioned traffic by applying appropriate policies. (See Control Peer-to-Peer Downloads.)

This technique assumes all HTTP tunnel traffic is unsanctioned. But what if your website is using HTTP tunneling via a web proxy to secure outbound traffic via SSL? How can you limit the use of unsanctioned web proxies but still ensure the sanctioned ones are protected? The PacketShaper can easily handle both situations. Just create an IP-based class for the sanctioned proxies and set appropriate policies to protect the traffic flowing to and from sanctioned proxies. The unsanctioned web proxy traffic will get classified into the inbound/http-tunnel and outbound/http-tunnel classes that have the restrictive policies.

Encryption

Sometimes peer-to-peer traffic uses encryption to try to disguise itself and avoid detection. When applications, such as Ares, obscure their content through encryption, the traffic can circumvent security. Allowing encrypted P2P traffic exposes organizations to potential worms, viruses, spyware, and other unauthorized files. Because the PacketShaper is able to identify connection setup sessions for P2P applications that utilize encryption to obscure transferred content (such as Ares 1.8.1), you have the ability to block or discard the connections.

Port Hopping

Port hopping is another technique developed for avoiding application detection. Many P2P protocols, such as AOL (America Online) and KaZaA, use port hopping so that they can bypass firewalls and router configurations that are designed to block or rate-limit them. When an application has port hopping capability, it will try to reach a remote host on a different port when it is unable to connect on the default port. For example, a P2P program might first try to connect on port 80. If this fails, it might try on port 3904. If port 3904 doesn’t work, it might jump to port 4556. Because the PacketShaper understands protocols up to level 7 of the ISO model, it is able to recognize  many port-hopping protocols no matter what port they are using.

Packeteer automatically validates each flow and places it in the proper traffic class. To see which application (service) Packeteer classified a flow into, you can use the traffic flow command. To see a complete list of all the applications the PacketShaper is able to classify, see Applications, Protocols, and Services.

Rogue Server Detection

Rogue servers are not authorized, don't contain the latest security patches, and don't have anti-virus software installed. These rogue servers are a network breach waiting to happen, exposing the company to liability, viruses, and attacks.

Packeteer offers a couple features that can aid in the detection of rogue servers: Top Talkers/Listeners and Flow Detail Records.

Top Talkers and Top Listeners

One way that you may notice that something is amiss on your network is a sudden increase in a certain type of traffic, such as FTP. Suppose FTP is not usually in the top ten applications on your network, and it suddenly appears on the Top Ten pie chart.

Top Ten

To find out who is contributing to this increase in FTP traffic, you can use the Top Talkers and Top Listeners feature to track the hosts that initiate the most traffic (talkers) and hosts that receive the most traffic (listeners) on the FTP class. You can track top hosts for up to 12 classes at one time.

Flow Detail Records

Flow Detail Records (FDRs) provide detailed traffic information such as flow origin and destination, flow size, throughput, efficiency, and service type. PacketShaper units serve as emitters, automatically pushing data to remote systems, called collectors. The collectors interpret and incorporate the data into meaningful reports. Packeteer's centralized network reporting product, ReportCenter, is one such collector. ReportCenter's FDR capabilities can assist with detailed flow and host analysis.

fdr

By configuring each of your PacketShapers to emit FDRs to the ReportCenter server, you have a wealth of reporting and analysis tools available to you. Using FDR, you can drill down to detailed information based on individual host IP addresses. You do not need to enable top talkers/listeners on a class: ReportCenter stores these details automatically. This capability helps in the process of detecting a rogue server on your network.

For more information, see Flow Detail Records Overview and ReportCenter Overview.

Application Overload Protection

If a denial-of-service attack occurs on your network, you’ll want to make sure your application servers don't become overwhelmed with the excessive traffic. Flow limit policies offer such protection. These types of policies limit the number of flows per minute that can be received by any server. You can then use the adaptive response feature to notify you when flows are being blocked because of the flow limit policy. While the flow limit policy protects servers from being overwhelmed, adaptive response lets you monitor what's happening and can be set up to automatically send you an email when flows are being blocked by the flow limit policy. To do this, you will want to create an agent based on the Class ME Variables template, the Inbound/Default class, and the server-flood-block class measurement variable.

For more details on using flow limit policies, see the recommendation titled Detect and Limit DoS Attacks. For background information on adaptive response, see Adaptive Response Overview.

Detection of SYN and Spoofing Attacks

A high number of new flows per minute and/or failed flows per minute can indicate an attack is occurring. Adaptive response offers several agent templates that monitor flows to/from hosts to help in the detection of SYN attacks and spoofing. After setting up these adaptive response agents, you can be notified automatically when a host has excessive failed flows and/or new flows per minute, thus alerting you to a possible attack. In addition, you can automatically restrict the bandwidth of these violating hosts so that you can minimize the problem while you do further investigation. For complete details, see Use Agents to Detect SYN Attacks and Use Agents to Detect Spoofing.

Detection of Recreational Traffic

Excessive recreational traffic can disrupt a network. Employees downloading music files, hosting a file server for music files, communicating via unsanctioned instant messaging, listening to Internet radio all day long, watching streaming video of current events — all of these non-business-related activities consume bandwidth that could be better used elsewhere. You can use Packeteer's sophisticated classification and control features to detect and control recreational traffic.

For procedures, refer to the following recommendations:

Control Peer-to-Peer Downloads

Control Instant Messaging

Control Internet Radio Traffic

Protecting Against Network Congestion Events

The very nature of TCP traffic can cause Network Congestion Events (NCEs) — network-related situations that impact application performance and user productivity. Every day tasks, such as an employee FTPing a large file or emails with gargantuan attachments, can produce NCEs. Fortunately, the PacketShaper can prevent these types of NCEs from occurring.

The basic foundation of the PacketShaper is designed to prevent Network Congestion Events. Partitions can reserve sufficient bandwidth for mission critical applications. Rate or priority policies make sure critical applications get first dibs on the bandwidth they need. Restrictive partitions and policies can limit the bandwidth of unsanctioned traffic. Rate policies allow you to take advantage of TCP Rate Control to smooth out bursty applications so that they don’t consume the entire link.

With this infrastructure in place, a large file download will not create network congestion. If half the company views a streaming video of a major news event at the same time, the performance of mission critical applications will not be impacted. Or, if a number of employees simultaneously download the just-released 100MB Microsoft Service Pack, the entire network will not become painfully slow. 

WAN Application Forensics

Network forensics is the capture, recording, and analysis of network events in order to discover the source of security attacks or other problem incidents. This term is borrowed from the legal field, where forensics pertains to the investigation of crimes.

The PacketShaper offers several tools to help in network forensics:

Graphing Tools

The PacketShaper measures hundreds of characteristics about traffic as it passes, creating an extensive collection of measurement data. Packeteer stores measurement data on appliances for up to two months and for months or years once converted to an Oracle format and forwarded to a ReportCenter server. Packeteer's metrics can also be incorporated into SNMP management platforms, NetFlow v5 collectors, and third-party reporting tools, such as Concorde, InfoVista , and Microsoft Excel.

graph

The PacketShaper uses this measurement data to generate a variety of graphs, several of which can assist in the diagnostic process. The TCP Health graph shown above gives you a comprehensive picture of TCP connections for a link, partition, or traffic class. It compares the number of TCP connections that were started, aborted, ignored, or refused by the server. This can help you identify where problems occur. For example, if you see a large number of Server Ignores, you know that you have an overloaded or malfunctioning server that is ignoring new connection requests.

For instructions on creating graphs, see Graph a Specific Link, Partition, or Class.

For descriptions and examples of all PacketWise graphs, see Preconfigured Graphs.

Flow Detail Records

As mentioned earlier, the Flow Detail Record feature provides drill-down metrics on a per-flow basis that include items such as flow origin and destination, flow size (in packets and bytes), when the flow was sent, the flow’s application or service, the flow’s Layer-4 protocol and IP ToS/Diffserv bits, the type of controls that were applied to the flow, response times, and more.

This granular level of detail opens up a wealth of opportunity for enhanced troubleshooting and forensic help. For example, you can:

  • Examine the "chattiest" host IP pairs for traffic from a specific application, location, or combination of the two.
  • Split the traffic from one branch office into its different application, service, or DSCP types, even if you didn't sub-classify traffic into its services as it passed.
  • List traffic's busiest ports; list the ports a specific application or host used; list which applications used a specific port; spot potential port scans.
  • Expose the top current or historical traffic contributors or recipients for a location or application

If you specify Packeteer ReportCenter as the FDR collector, you can use a variety of reports to aid in troubleshooting network problems and help determine the source of a DoS attack. For example, ReportCenter's flow detail reports let you see the busiest hosts on your network. If you spot a suspicious host, you can drill down to see the applications used and destination addresses contacted.

For more information about FDR, see:

Flow Detail Records Overview

Set Up Flow Detail Records

Host Reports

Host Analysis

The PacketShaper maintains a database of all hosts that have active connections through the unit. Once a host closes its connection, the host will be purged from the database. In addition, the PacketShaper will clear host entries if they aren't active for approximately ten minutes. Thus, the host database is a real-time list of hosts.

Host Analysis is a reporting tool that allows you to view, sort, and drill-down on hosts in the host database. If you spot a suspicious host (for instance, one that is using excessive bandwidth or creating an inordinate number of connections or failed connections), you can drill down to find out more detailed information. What other hosts is the suspicious host communicating with? What are the host's current and recent traffic flows? What type of traffic is it (HTTP, SSL, etc.)? The Host Analysis tool can provide the answers. See Perform Host Analysis for details.

Packet Capture

For a more in-depth analysis of your flows, Packeteer offers the packet capture feature. This feature captures packets for future analysis, allowing you to analyze detailed information about the packets in a traffic class, such as the source and destination IP addresses and protocols used. You can even examine the packet down to the byte level, if you are so inclined. With the packet capture tool, you can capture a small sample of traffic from an unknown or troublesome flow so that you can investigate it in detail: view packet headers, real-time display of top users, or content at specific offsets into packets.

First, you need to decide which packets you would like to collect. A major advantage of using the PacketShaper as a collector is that you define precisely which traffic to capture. You don’t have to collect huge log files with mostly irrelevant traffic. Any traffic you can identify with matching rules in a traffic class can be captured independently. For example, if you want to capture all Telnet packets to a certain IP address — you can. Or if you want to capture only Oracle traffic for one particular database — you can.

The basic process is:

  1. Specify which traffic class(es) from which to capture packets.
  2. Enable packet logging for a period of time.
  3. Open the resulting log file in a third-party analysis tool, such as EtherPeek, Ethereal, or a Sniffer.

For more information, see the recommendation titled Sniff without a Sniffer.

PacketGuide™ for PacketWise® 8.3