Top Features in OmniPeek Network Analyzer 6.8

It’s that time again. Spring is in the air and with the changing seasons comes the newest version of our flagship product, the OmniPeek network analyzer—now available in version 6.8! We’ve included some great additions to OmniPeek, making it even better equipped to help network engineers quickly analyze and troubleshoot enterprise network issues.

We announced the release last week at Interop Las Vegas and we are looking forward to hearing lots of user feedback!

Below are some of the top additions that we think are pretty cool.

IPv6 Analysis
With the ever-changing nature of enterprise networks comes the need for constant adaptability. The next major change is the addition of IPv6 to current IPv4 networks.  For enhanced monitoring of a dual stack environment, OmniPeek Expert analysis provides automated inspection of all OSI layers simultaneously for an active diagnosis of traffic regardless of network layer, IPv4 or IPv6.

The Expert analysis can detect misconfigurations and anomalies within IPv6, just as it has with IPv4, alerting network engineers to issues quickly in order to maintain service levels through all stages of the IPv6 deployment, reducing the time and cost of transition.

As a bonus, OmniPeek 6.8 also provides analysis of VoIP and video over IPv6, for sites and providers migrating to next-generation transport.

Timeline View
As company networks become ever more distributed and the level and type of network traffic increases, it is important to give network engineers visibility into all of the current network information from one easy-to-use interface, to determine when and where it is necessary to perform more in-depth analysis. For this reason, OmniPeek now includes the Timeline dashboard, which provides the most complete set of real-time statistics, quick data rewinding, and rapid search and forensic analysis of collected data.

Capturing traffic 24×7 saves time and allows you to view all of your historical network traffic to quickly drill down and fix performance bottlenecks across multiple network segments. Trying to reproduce the problem without a detailed history to refer to can use up valuable time and still leaves room for missed events and incomplete data to diagnose the issue.

Packet De-Duplication
Nobody likes to do the same thing over and over, and OmniPeek 6.8 helps to make network engineers lives easier by performing real-time packet de-duplication for aggregated packet capture. Removing duplicate packets from the analyzer data makes the capture files much smaller and less cluttered when performing troubleshooting.

In addition, advanced aggregating techniques, such as multi-channel Wi-Fi analysis, or differential packet analysis to view packet changes in network transit, are still supported when using packet de-duplication. OmniPeek filters out only exact duplicates, still allowing an analyst to measure the information-rich Wi-Fi retransmissions rate or differential packet changes.

Additional updates include:

For more information on OmniPeek 6.8, click here.

Share this post:
  • Twitter
  • Facebook
  • LinkedIn
  • Digg
  • Reddit
  • DZone
  • StumbleUpon
Posted in IPv6, Network Monitoring, Network Performance Management, OmniPeek Network Analyzer | Tagged | Leave a comment

IPv6: Is It Finally Time?

In 1994, Guns N’ Roses began to write and record music for their new album, “Chinese Democracy.” Rumors circulated about the album and the band, and eventually most people decided it would never happen. The album however finally debuted in November 2008, over a decade after it was originally expected.

In the nearly 15 years this album took to complete, it received incredible amounts of hype over when it would finally debut. This phenomenon is much like the hype that surrounds technologies that come out in the networking world – 802.11ac, 10G and IPv6 to name a few.

IPv6 was introduced in the late 1990s in anticipation that IPv4 addresses would run out. The widespread deployment for this protocol has remained a mystery and has been on almost every IT department’s “to do next year” list for the last 10 years. So, the question is, will 2012 be the year that it will move to a higher priority on the list? Several trends are indicating that this might be the year when IPv6 finally makes a larger splash.

“New” IPv4 addresses have been steadily dwindling, and the global allocation pool ran out in February 2011. Two months later, in April 2011, the Asia registry was also depleted, meaning that anyone wanting to get online would have to rent or borrow addresses from their ISP. Fortunately, this wasn’t a surprise, and companies and governments planned ahead. NTT in Japan made IPv6 available to its customers as far back as 2000, and Japan and South Korea were the two first countries to be IPv6 resolvable by the global DNS system, in 2004. China is also ready, having used the 2008 Olympic Games as a technology demonstrator for their IPv6 readiness.

The driver for IPv6 deployment today is access to the global marketplace, especially the highly sought emerging Asian markets.  If your services are not reachable on the Internet by IPv6, you’re losing access to potential customers and business partners.

Fortunately, all equipment today is ready for IPv6.  All new PCs ship with IPv6 enabled by default, and infrastructure equipment also supports IPv6, even down to home Wi-Fi routers.  Additionally, deployment of IPv6 has been getting easier due to strategies like dual-stack, NAT, and tunneling. Right now it’s the easiest it’s ever been to roll out IPv6, and may be the easiest it will ever be.

Today, companies are less afraid of the switch. Early adopters have pushed equipment makers to fix bugs, ensuring that IPv6 is business-ready. As a benefit, the promise of better security due to the length of these addresses has also driven people to look at IPv6 more than IPv4. The transition is inevitable and the quicker you are to recognize the transition is happening the better off your network will be for the future.  Other regional IP registries are also running out of IPv4 addresses.  The regional registry in Europe is expected to run out in the middle of 2012, followed by the North American registry in mid-2013.  Waiting until the last minute and trying to solve the problem of IPv6 when it is at hand will lead to time pressure on big issues that could have been avoided with better planning.

Companies will not completely transfer to IPv6 in the near future — we still have a lot invested in IPv4 infrastructure, and adding IPv6 is an addition, not a complete deprecation of the existing system. The interoperability between the two protocols may lead to some issues down the line, so make sure you are creating a dual-stack network that can work in tandem with both of these and choose solutions that can communicate on both levels and with each other. There are several solutions already on the market now. If you are looking to add IPv6, definitely confirm that your vendor’s solutions are IPv6 capable, so you don’t have to buy add-ons or new equipment prematurely.

Although IPv6 may have taken a long time to come into fruition – like Guns N’ Roses “Chinese Democracy”, it is not just a pipedream in 2012. It is a reality that you need to be prepared for and ready to implement.

Share this post:
  • Twitter
  • Facebook
  • LinkedIn
  • Digg
  • Reddit
  • DZone
  • StumbleUpon
Posted in IPv6 | Tagged | Leave a comment

Best Practices for Troubleshooting Voice Quality Issues

Last week, we focused on whether or not your network could handle more real-time data, like video and voice over IP. The blog outlined how video and voice over IP affect the network, whether or not your network can potentially handle more of this real-time protocol (RTP) traffic, and how to best prepare for this confluence of highly sensitive data.

Now that you have determined that your network can handle more VoIP, it’s time to take it a step further: What is the quality of your calls, and how do you troubleshoot voice quality issues?

When troubleshooting real-time data like VoIP, it is important to have the right analysis tools in place that can baseline your network and drill down into the most granular details of packet traffic on your network, but more importantly it’s critical to have tools that let you focus quickly on telephony calls and quality, which is where we will begin.

MOS and R-Factor – automated measurement of call quality
Mean Opinion Score (MOS) is a rating system that helps you assess the relative quality of a call. It has been used for years in telecom landlines, where real people were asked to listen to sample telephone calls, rating the call quality from 1 (very poor quality) to 5 (perfect). That data was used to create automated measurements which give you a reliable estimate of how the VoIP users in your network perceive call quality. Anything above 4 is considered to be a good quality call, with 3 being “slightly annoying,” 2 “annoying,” and 1 “very annoying.” In practice, there will be few complaints if your VoIP calls are above 3.5.

While MOS is a score historically based on human perception, modern implementations use a mathematical analysis. Besides MOS, another key mathematical factor in use today is R-Factor, which is designed to scale from 1 to 100, and encompasses both narrowband and wideband codecs (a weakness in MOS). Reasonable R-Factor scores for a call are about 75 and above. Interestingly, as VoIP codecs have gotten better, it has become possible for calls to have an R-Factor greater than 100. Modern codecs on a low-latency, low-jitter connection can carry a call with a score of up to 120.

Another factor that affects call quality is jitter. Jitter is the measurement of the variability of the time delay between each RTP packet. Jitter is important as a factor in call quality because, if uncorrected, it can result in gaps and lost data (missing audio) in the call. While most equipment has a jitter buffer to smooth out the gaps, the correction introduces latency. Too much latency will be noticeable by the callers as a time lag when talking, which itself reduces perceived call quality.

Dissecting RTP and RTCP to discover where the issues lie
When it comes to troubleshooting a network, it really comes down to understanding and being able to visualize the most granular details. In the case of VoIP, the most granular details for solving problems are held in the Real-Time Transport Protocol (RTP) and Real-Time Transport Control Protocol Packets (RTCP).

RTP provides more than just the packaging and delivery of voice data, it also contains details that help you troubleshoot issues, including:

  • A sequence number that is handy for detecting lost or out of sequence packets;
  • The payload type, which can be a well-known type or dynamically assigned by the signaling protocol;
  • A sync source identifier to uniquely identify an RTP stream; and
  • A timestamp set, used to determine the expected packet arrival rate to the listener and for calculating jitter.

The RTCP packets are useful because they report on various conditions during a call in progress, including the percentage of packets lost since the last sender report, cumulative packet loss and jitter. RTCP packets can be captured anywhere in the path between two VoIP users, and analyzed to see how many packets are being dropped according to the listener.

What should I have in my VoIP troubleshooting tool belt?
When you are planning to troubleshoot poor VoIP call quality, you need to have a tool in place that measures overall metrics like MOS and R-Factor, and analyzes network conditions like latency, jitter, and packet loss, based on an independent analysis of RTP streams. This way, if a device does not support RTCP, you can capture RTP streams on the same segment as the listener to get call quality information close to that user.

A robust VoIP analysis tool must go beyond simply reporting the jitter included in the RTCP packets. It must also be capable of examining independent sources of jitter information by calculating jitter directly from the RTP packet stream itself. It is also essential to have notifications not only when reported by an end-device via RTCP, but also in real-time via RTP stream analysis as packets are captured. Having it both ways allows the analyst to better pinpoint where in the network jitter starts to become a problem.

Analyzing VoIP is a two-way street
Don’t forget to analyze at the end-points. To reiterate, the VoIP packets captured at the core is not where the call terminates. Capturing at multiple points allows you to see exactly where the quality of the call drops.

Remember that it’s very important to analyze each side of the call independently when studying existing VoIP calls. For instance, during a call there will be an RTP stream from device A to device B and a second, completely independent RTP stream, from device B to device A. Why? You need to know in which direction the call has degraded to solve the problem.

When looking at factors for VoIP over wireless (VoFi), there’s an entirely new set of considerations, which we will dive into in more detail in a few weeks. Stay tuned!

Share this post:
  • Twitter
  • Facebook
  • LinkedIn
  • Digg
  • Reddit
  • DZone
  • StumbleUpon
Posted in Uncategorized, VoFI - Voice over Wireless, VoIP Troubleshooting | Tagged , , , , | Leave a comment

Come Say Hello at INTEROP 2012!

We will be at Interop 2012, May 8-10 in Las Vegas! Come and stop by our booth #1967 for a quick chat or live demo of our flagship product OmniPeek network analyzer.

This year we will be giving two live presentations throughout the conference, as well as featuring a prize giveaway of a $250 Amazon gift card.

See below for a full presentation schedule:

Best Practices for Analyzing 10G Ethernet Traffic
May 8: 10:15, 1:15
May 9: 12:45, 4:15
May 10: 10:15, 1:30

802.11ac/802.11ad – Are You Ready?
May 8: 12:45, 2:00
May 9: 10:15, 1:15,
May 10: 11:30

The drawing and giveaway will take place on the 10th at 1:50pm.

Hurry up and register for one of our great presentations and get a free t-shirt!

Share this post:
  • Twitter
  • Facebook
  • LinkedIn
  • Digg
  • Reddit
  • DZone
  • StumbleUpon
Posted in 10G, 802.11ac, 802.11ad, OmniPeek Network Analyzer | Tagged | Leave a comment

Can Your Network Handle More Real-time Data?

Real-time data, especially video, is the wave of the future, and as this wave begins to break there are others already crashing onshore. Will you be inundated, or do you have the appropriate network infrastructure in place to stem the tide?

Global Internet video traffic surpassed global peer-to-peer (P2P) traffic in 2010, and the percentage of all forms of video is predicted to be approximately 90% of global consumer Internet traffic by 2015 (full details in this Cisco report). Coincident with this acceleration in video traffic is a general enterprise transition towards a shared ecosystem using SaaS and cloud computing. Though at first glance these trends may seem mostly unrelated, adding significant volumes of video traffic, or any real-time protocol (RTP) traffic for that matter, can have a significant, and typically adverse, effect on your application performance. Whether business critical or not, when there’s video available on the Internet it will find its way onto your corporate network so it’s important to have a full understanding of the benefits as well as the consequences of adding additional RTP (voice or video over IP) traffic to your network.

RTP traffic is highly sensitive to network latency, and the trend towards SaaS and Cloud computing typically increases overall network latency. Hence, as both these waves come ashore, it’s imperative that you have the infrastructure in place to monitor both application and RTP traffic, simultaneously, so you can keep from inundating your resources.

RTP has unique, and typically more demanding, requirements for network performance than “traditional” network data. However, you have only one network to carry all your traffic, both data and RTP, so you need to assess the effects that RTP will have on your application performance, and vice versa. Networks are often configured to give routing priority to RTP traffic, making application performance vulnerable when RTP traffic loads are high.

So, first and foremost, you need to have an accurate measurement of how much of the traffic on your network is RTP, and how much of that is mission critical.
At this point, it’s beneficial to make a distinction between VoIP and video. VoIP traffic is probably all enterprise driven, and is therefore mission critical. I don’t know of many rogue VoIP users on corporate networks.

Video is a different story. Though growing, the number of mission critical video-based applications is still very low, with web-based conferencing being by far the most prevalent. Most web-based conferencing still takes the form of relatively low bandwidth connections with an audio stream, and a real-time video stream thrown in from time to time.

And then there’s real-time video streaming. Maybe it’s YouTube, or Hulu, or something else, but in most cases it’s probably not mission critical. But it is likely to be far more bandwidth-intensive than anything else on your network, and if it’s being routed using QoS (Quality of Service) then it’s impacting your ability to deliver mission critical application data in the most efficient manner.

So how do you know where your vulnerabilities lie? Using packet-based network analysis and following these steps will help you characterize what’s going, and whether or not RTP traffic is threatening your network.

  1. Determine the mix of RTP and TCP traffic on your network.
    Any solution that can determine overall network protocols can do this, but some make it easier than others. It helps to be able to graph both data types in relation to the other, and over time, as the relationship is likely to be very dynamic. You should look for average and peak utilizations of each data type as well as times of day where the mix seems to be different. This should be done day after day for several weeks to get a solid baseline.
  2. Dissect your RTP traffic.
    Once you know your overall RTP traffic behavior, drill in and break that traffic down between VoIP and video. As we discussed, VoIP traffic is likely all mission-critical, while video traffic requires additional analysis.
  3. Dissect your video traffic.
    Be suspicious of all video traffic, especially high-bandwidth real-time video streams. Since most video traffic is web-based, one of the best ways to study video traffic is to look at the servers generating the traffic. All mission critical video activity, like web conferences, will involve well known servers from brand name service providers, like WebEx or GoToMeeting. Using filtering, eliminate data from these sources, making the remaining search easier. Then filter on other well known servers that are not likely to be mission critical, like YouTube, and you will quickly get a “picture” of unauthorized, or at least unnecessary, video traffic on your network. If the volumes are low, maybe you just let it ride, but if the volumes are high, or if application performance is degrading while these real-time video sessions are active, action is required.

Network utilization is very much like the ocean. Utilization ebbs and flows over longer cycles, like the tides, with occasional spikes in traffic similar to waves. And then there’s the occasional rogue wave that takes everyone by surprise. But if you’ve accurately assessed your overall usage as outlined above even the rogue wave will be manageable. Then it’s just the tsunami that you need to worry about…

Share this post:
  • Twitter
  • Facebook
  • LinkedIn
  • Digg
  • Reddit
  • DZone
  • StumbleUpon
Posted in Application Performance, Cloud Network Analysis and Monitoring, Network Analysis, Network Monitoring, Network Performance Management, VoIP Troubleshooting | Tagged , | Leave a comment

How to Clean Up After a Security Breach with WildPackets

As a network administrator there is no greater nightmare than a security breach. Your network has just been under siege, and you have an extremely limited amount of time to discover the attack, report the incident, find the holes in your system, and understand what damage has been done or might continue to occur on your network. This task needs to be done quickly as solving these problems fast will reduce the overall impact and cost.

Here at WildPackets, we recognize that no amount of security can protect all of your data all of the time. New vulnerabilities are discovered daily, and exploits are quickly available in security test tools such as Metasploit. Joshua Corman, Director of Security Intelligence at Akamai, humorously calls this HD Moore’s Law (after Metasploit’s creator, HD Moore). If your security doesn’t protect against a casual attacker using the latest common attack tools, it’s not really secure. Yesterday’s security isn’t enough to stop today’s attack.

Fortunately, there are actions you can take to minimize the damage of attacks. Think of how companies secure their buildings, using multiple layers of physical security to protect their assets. The locked doors are designed to prevent intrusion. Those doors also have sensors to detect that they’ve been opened. Companies that are serious about their security also have cameras to watch and record what intruders are doing. As a final layer, security guards are there to listen for alarms, watch the cameras, and catch what the automated systems don’t.

WildPackets software and appliances use a practice known as Network Forensics to act like security cameras for your network. Continuous capture makes sure that security events are recorded as they occur. Additionally, live statistical views and Expert analysis provide real-time visibility, so the NOC can monitor the network like security guards. The NOC can even single-click to download the packets, escalating the event to the security team for in-depth Network Forensic analysis.

The basic elements that a Network Forensics solution should include are:

  • Data Capture and Recording: This is the ability to capture and store multiple terabytes of data from high-throughput networks (for example, 10 Gigabit) without dropping or missing any packets.
  • Detailed Inspection Capabilities: Once data is recorded on the storage media, the solution should provide a mechanism to filter particular items of interest, for example, by IP address, application, timeframe, context, etc.
  • In Depth Data Analysis: Finally, you want some built-in assistance for examining the patterns and anomalies found during the discovery process to help you track the attacker’s actions in the captured packets.

Network Forensics depends on catching events as they occur, so you need a network recorder and analyzer. WildPackets makes a variety of recorders, from single-server OmniEngine Desktop software probes, to multi-gigabit Omnipliances, all the way up to the 10G wire-speed TimeLine network recorder. All of these distributed capture solutions report in real time back to OmniPeek Enterprise, which acts as a central console for complete network visibility.

The TimeLine network recorder has been especially popular with WildPackets customers looking for a Network Forensics preventative solution. Its ability to capture traffic at high speeds from multiple locations, such as transit VLANs on core switches or links between the Internet and the internal network, make it a technically and financially compelling solution for converged packet capture. With its live IP packet data capture and deep packet inspection technology, every single packet and conversation is recorded, visualized for real-time NOC monitoring, and stored in a central location for on-demand analysis. Using TimeLine’s Network Forensics data mining capabilities, security teams can reconstruct the sequence of events that occur at the time of a network breach or cyber attack and get the complete picture.

Timeline view

TimeLine is designed so you can take the necessary steps to extract information from the network data, and solve the problem.

When was the breach detected?
One of the most difficult aspects of a breach is simply discovering it. WildPackets complements traditional security detection systems, such as IDS and log monitoring. Additionally, the OmniPeek console can generate alerts about traffic captured on any connected network recorder, based on Expert analysis or arbitrarily complex filters, then send traps, send emails, or export its log messages to a SIEM. The additional analysis and visibility improves the chances of detecting breaches as they happen.

If the breach is discovered right away, the Timeline view feature in OmniPeek provides zoomable visualization and statistics for remote packet capture. NOC can use the Timeline view to perform initial investigation of anomalies by zooming into the suspect timeframe and examining the mix of protocols and top talkers at that point in time. OmniPeek then works with NOC escalation procedures with the single-click “Download Packets” button for a high-resolution snapshot of the network during that timeframe. The packet capture file can then be attached to a ticket for dispatch to the security team.

If the breach isn’t discovered right away, or if a larger investigation is needed, the security team can use the Forensic Search feature to find packets from that timeframe, with arbitrarily complex filter ability. Given that high speed networks transmit a lot of data, all WildPackets network recorders support complex capture filters to increase the length of time for recorded traffic storage.

Who was the intruder?
Once a breach has been detected, the first step is to identify the source. Depending on how the breach was detected, you may already have the remote IP address. If you don’t have this information, WildPackets network recorders allow you to drill down into the network traffic. Which server was affected? What were the connections to that server during the time frame? OmniPeek’s Expert views will display all flows and connections in the capture, with a straightforward organization by protocol, server, and client. If the breach happened via a web server, as is most common, the Web views will organize the information in multiple different ways, including by page request. Viewing by web page request has the benefit that common client requests will all be grouped together, making uncommon requests – such as inline SQL injection – much easier to identify.

How far did they get into my system?
With the location on the network determined, the next step is to find out how far the intruder breached your network defences. What you’re looking for initially is connections from the attack IP to other systems in your network. OmniPeek makes this easy with the “Peer Map” feature, which visually displays connections between IP addresses. From there, it’s a good idea to filter on those connections. Filtering is simple with the “Select Packets” feature: right-click just about anywhere in the program, click “Select Packets” by the attacker IP, and OmniPeek will open a new tab pre-filtered on just that traffic. In that new tab, all of the Expert analysis, statistics, etc., are also filtered to look just at that traffic.

While some breaches are smash-and-grab connections to a single server, others are multi-hop attacks, where an intruder compromises a DMZ server, and from there attacks an internal server. Full investigation of the extent of the attack may take some time and effort, especially if the packet analyser only supports a single filter at a time. OmniPeek reduces the complexity of breach-tracing with its multi-tab architecture. Applying a filter optionally creates a new tab, allowing the kind of in-depth analysis that simply isn’t possible when limited to a single view of packets. Tracing activity among multiple servers is a manageable task with OmniPeek.

What can I do to prevent this next time?
The final step in incident response is learning what you’ve applied. The forensic investigation will likely uncover forgotten firewall rules, unpatched servers, and maybe even bugs in your internally-developed code.

While OmniEngine can’t adjust your firewall rules and TimeLine can’t fix your bugs, your WildPackets network recorder infrastructure can still help you prepare for the next attack. During the forensic investigation, tracking the scope of the breach likely required you to create several new, fine-tuned advanced filters. Those filters can be saved and re-used for triggers and alerts on your live network monitoring. What you learned during this attack can improve your reaction time to the next one.

Network Forensics is an essential, but often overlooked, part of any comprehensive security strategy and with WildPackets Network Forensics solutions, data is always available for reconstruction and easy analysis of performance issues, cyber attacks, or data breaches. Our network forensics data mining tools can be powerful weapons in the fight against cybercrime and policy violations, but the key is to have a solution in place now – before you have a need for post-incident analysis.

To learn more about the benefits of employing a Network Forensics solution, check out our webinar, “Cyber Security – IDS/IPS Is Not Enough” and White Paper, “Network Forensics: How to Optimize Your Digital Investigation.”

Share this post:
  • Twitter
  • Facebook
  • LinkedIn
  • Digg
  • Reddit
  • DZone
  • StumbleUpon
Posted in 10G, Network Analysis, Network Managment, Network Monitoring, Network Security, OmniPeek Network Analyzer, TimeLine Network Recorder, network forensics | Tagged , | Leave a comment

Best Practices for Network Management in the Era of Distributed Applications

A network error just occurred in your environment and you (the network engineer) have about two hours to fix it before your entire company is breathing down your neck. About 10 years ago, when centralized computing was all the rage, the ability to fix this problem was very simple: you physically went down the hallway and connected a network analyzer to the appropriate port to troubleshoot the issue. However, this is no longer the scene. Whether you are an organization of 50 or 50,000 employees, most likely your network environment is highly distributed. Imagine sending your network admin to China to fix a problem in that data center. It’s simply unrealistic.

Today’s distributed application architecture takes many forms, from locally-hosted applications to web-based applications to multi-tier, third-party hosted applications. While application traffic has historically resided in the data center, like the scenario above, SaaS and cloud computing are driving application traffic outside the traditional enterprise network—making the ability to determine network and performance issues far more challenging.

No two networks are the same, with topologies depending on many factors, but most networks can be characterized using similar metrics. These metrics can be used to help you plan for a holistic solution that will best monitor and analyze your entire environment. Below are some key tips to getting started, or for reevaluating your environment to monitor and analyze distributed applications.

Understand the Application “In-Action”
What we mean by an application “in-action” can also be called application response time, which is the time it takes an application to respond to a specific user request. This is a real world measurement – it’s not just the time it takes the network to respond, but the time it takes for the user to receive actionable data in response to their request so they can move onto other tasks. It’s important to understand how long this process takes, as this is how the user measures the application response. The overall process can of course be broken down to a much more granular level using packet-based network analysis, and from there you can begin to determine if it is the network itself or the application that is causing any delays. If you are interested in more detail on this, check out our blog “Three tips for determining whether latency is caused by the network or application.”

Where Should You Monitor?
The most useful data comes from network monitoring at both the client and the server. Measuring at the server provides accurate Server Response Time (SRT) – the time it takes just the application itself to respond to a request. Measuring at the client side includes both Server and Network Response Times (NRT), but if you’ve also measured at the server the SRT can simply be subtracted to get the true NRT. If you decide to monitor only on the client-side, you’ll get a good picture of what the client is experiencing, but the latency measurements will include both the SRT and the NRT, obscuring critical information about where the problem lies. It also requires monitoring equipment at all client sites, even remote sites, which can drive up the cost.

Most enterprises employ server-side monitoring, which is usually less expensive and better able to assess server response time. However, it hides the NRT, especially for remote users, making measurements to differentiate individual client locations more difficult.

Monitor 24×7 and Always Store Your Data!
Ongoing monitoring can provide insight into network performance on key interfaces, and can alert you when conditions begin to decline. However, before you can tell if network and transaction latency are snowballing, you must have an understanding of what normal means for your network.

Benchmarking your application response time provides you with details of how your application regularly performs, so if it is not performing up to par you can catch it right away. Remember when you are establishing an application benchmark, pay close attention to both NRT and SRT and assess whether or not they appear across a wide range of users (especially in different locations) and/or a wide range of applications.

As network speeds grow, it is easy to miss things on the network, so whether to respond to user reports or simply to explore something that just flew by in a bit more detail, it’s important to store your data for historical analysis. Again, packet-based data is the best approach, as flow-based data which is often used for network monitoring does not contain sufficient detail to pinpoint exactly where the issues are and prevent them from happening in the future.

The Cloud Factor
From a network perspective, whether your application server is located in your data center or in the cloud, the only thing that’s changed is how to manage application problems that occur. You’ll be shifting from managing your own infrastructure to managing service availability and performance.

Keeping up the performance of your applications is essential to your business, and businesses must be able to adapt their network monitoring and management strategy accordingly in this new distributed environment.

Share this post:
  • Twitter
  • Facebook
  • LinkedIn
  • Digg
  • Reddit
  • DZone
  • StumbleUpon
Posted in Network Managment, Network Performance Management, Network Troubleshooting, Uncategorized | Tagged | Leave a comment

5 Cool Things You Can Do with WatchPoint

Network monitoring isn’t simply about the here and now. Although most network monitoring is done to ensure ongoing performance and service level delivery, it also has a historical component which can provide critical data for base-lining, network planning and investigations of past network anomalies. The WatchPoint network monitor addresses all of these needs with a monitoring and reporting system designed to handle multiple network data sources, store data at highly granular levels and provide flexible searching across all data elements.

WatchPoint, when combined with WildPackets network probes and data recorders, performs network monitoring and historical reporting with 100% data accuracy. WatchPoint records your network history, minute by minute, from multiple sources, including NetFlow, sFlow and WildPackets network analysis probes (OmniFlow). Data from these varied sources are aggregated into a single reporting solution, providing visibility for months or even years, with both up-to-the-minute and long-term historical reporting and analysis of network events.

Below are five features that highlight the unique capabilities of WatchPoint.

1. High-level network views for any point in history
With WatchPoint you can access a high-level, instantaneous view of the entire enterprise-wide network, in real time or months back, in order to monitor overall network usage, application performance and SLA compliance. This solution has the ability to store data minute by minute for up to a year, providing unprecedented granularity for your historical data. Other options, like many NetFlow-based monitoring systems, begin to time average the data after a certain period of time to reduce the amount of storage needed and keep the performance levels high. This leads to limited visibility in reporting which can reduce a systems ability in base-lining, network planning and investigations of past network anomalies.

2. Works in tandem with our other comprehensive solutions: TimeLine and OmniPeek.
WatchPoint also builds on WildPackets existing product lines to provide capabilities beyond that of typical flow-based reporting systems. The TimeLine network recorder, one of the highest performing packet-capture devices on the market, and the OmniPeek network analyzer, which provides detailed network analysis when you need to drill down into a particular problem, are two examples.

With these integrated, packet-based analysis capabilities, WatchPoint goes beyond traditional flow-based network monitoring systems, allowing you to drill down deeper for in-depth troubleshooting on your network. With this additional capability you can quickly identify anomalistic network behavior and troubleshoot the issue accordingly.

Network administrators will appreciate the above-mentioned benefits since they can finally use a single solution that goes from high-level monitoring to detailed packet level analysis.

Figure 1 From high level network monitoring …

Figure 2 … to detailed packet level analysis

3. Integrate NetFlow, sFlow, and OmniFlow into a single solution.
In most network operations centers today there’s specific software and systems for each particular need – one system for log management, one for flow-based monitoring, one or more for detailed network analysis, etc. WatchPoint provides complete visibility from global network utilization to detailed packet analysis, from a single, integrated system. And although the highest quality network statistics come from packet-based network analysis probes, we know that this method isn’t always feasible. WatchPoint supports NetFlow and sFlow reporting and combines this with our own OmniFlow reporting for a complete, single-vendor solution.

4. Centrally manages and monitors your network
As an IT Manager, it is necessary to be able to centrally manage your entire network. WatchPoint monitors the entire global network from one location. It also makes constant management easier with alerts and scheduled reports that can be emailed to appropriate members of the team. Every user has their own dashboard, and data access can be limited to user-defined roles when required.

5. Additional enhancements with OmniFlow
Data accuracy isn’t the only benefit of OmniFlow data. OmniFlow leverages the analytical power of WildPackets OmniEngine software probes, TimeLine and Omnipliance network recorders, providing not just the traditional “flow-based” information on ports and nodes, but adding Expert analysis results based on real-time network analysis at all layers of the OSI model. In addition, OmniFlow provides detailed VoIP statistics which can be correlated with network data to see when data is conflicting with VoIP traffic and vice versa.

Figure 3 VoIP reporting with WatchPoint

Figure 4 Expert event reporting with WatchPoint

If you are interested in learning more about what WatchPoint can do, check out this free OnDemand webcast.

Share this post:
  • Twitter
  • Facebook
  • LinkedIn
  • Digg
  • Reddit
  • DZone
  • StumbleUpon
Posted in NetFlow, Network Monitoring, OmniFlow, OmniPeek Network Analyzer, TimeLine Network Recorder, WatchPoint, sFlow | Tagged , , , , | Leave a comment

The New Face of Denial-of-Service Attacks

In today’s modern web world, a denial-of service (DoS) attack can take down an entire website in a matter of minutes. According to a report by security and network management vendors Prolexic and Arbor Networks, these types of attacks are on the rise, and were recently one of the key forms of attacks in the U.S. Department of Homeland Security’s investigation on America’s water and energy utilities constant cyber-espionage. Whether a governmental organization or business, these types of attacks need to be on everyone’s radar.

While DoS attacks themselves are nothing new, new techniques and technologies in DoS attacks can be more aggressive than their predecessors and require a different kind of approach to network security. This blog will explain what’s different about these new attacks, how best to approach them and identify measures that are no longer successful in combating them.

A quick history of DoS/DDoS/AppDoS
The goal of any Denial of Service attack is simply to overwhelm a service to the point where it no longer works. This is typically done via brute force methods mixed with varying degrees of cleverness.

A “classic” example of a DoS attack is SYN flooding which attacks a (web) server directly by starting a conversation at the TCP layer, but never finishing it. The attack was effective because there were relatively few resources on servers for partially-open connections. Solutions initially focused on protecting web servers with a proxy server (or security appliance) in front of the real server. These proxies would validate remote clients by ensuring that the TCP 3-way handshake completed into a full connection. The “real” solution came with server OS fixes to reinforce the weaknesses exploited by the DoS.

The next major advance in DoS technology was Distributed Denial of Service (DDoS), in which large numbers of attackers simultaneously targeted a single service. The coordinated nature of the attack comes from botnets, which are composed of PCs infected by a worm, Trojan, or virus designed to make the PC an unwitting attacker. The infected PCs typically monitor a location on the Internet, looking for orders to attack. The real game changer in DDoS is that the large numbers of attackers can simply use brute force to overwhelm the network resources around a server. Placing a proxy or firewall in front of a server is an ineffective defense if the WAN link itself is flooded. Defense here usually requires either coordinating with the WAN provider to block addresses upstream, or moving the service to a hosting provider with enough bandwidth to simply absorb a DDoS.

In an interesting twist, self-proclaimed “hacktivist” groups like “Anonymous” have evangelized DDoS as a method of protest. Rather than using botnets of infected PCs, these groups are providing “opt-in” tools – although some versions of these tools provide no later method to opt back out or even uninstall.

The latest approach in DoS is following the trends of attackers in moving up the stack to applications. Application Denial of Service (AppDoS) uses vulnerabilities in specific server applications to create high-impact DoS with very low attack bandwidth. Whereas DDoS relied almost purely on brute force to overwhelm infrastructure, AppDoS shows a return to the cleverness of the original DoS. What makes AppDoS so effective is that application-specific vulnerabilities use layer 7 attacks. While these attacks will not work on every server, they use the regular behavior of lower-layer protocols like TCP, which makes them harder to detect. A true AppDoS attack on a web server would even use a well-formed HTTP request. Attacks of this kind include Slowloris, which only works against Apache.

The author of the Slowloris tool has provided some excellent points of comparison about why it’s a new generation attack tool. Compared, to first generation DoS, “This is NOT a TCP DoS, because it is actually making a full TCP connection, not a partial one; however it is making partial HTTP requests. It’s the equivalent of a SYN flood but over HTTP.” Also, compared to brute force DDoS methods, “Slowloris is also NOT a GET request flooder. Slowloris requires only a few hundred requests at long term and regular intervals, as opposed to tens of thousands on an ongoing basis.”

The new approach to DoS attacks versus the old
As stated before, today’s DDoS attacks aren’t just against servers, but also against the network infrastructure. A firewall can only protect what’s behind it, so if it’s on-premise, it can’t prevent the WAN links from being flooded. Instead, to properly respond to a DDoS attack, network administrators need to coordinate with their WAN carrier to try and block the traffic upstream. There is a category of service provider offering “clean pipe” hosting with automatic DDoS squelching, but it’s often more cost effective to simply move externally-visible servers to a host with enough bandwidth to absorb DDoS attacks invisibly.

Secondly, the attack is going to come from a large number of IP addresses. These attackers will likely be a mix of botnets and self-proclaimed hacktivists. With an influx of this size, it is virtually impossible to add entries by hand for each node you are trying to block. In response you may want to try and filter aggregated blocks of addresses, but remember that the nature of botnets implies that the addresses will be widely dispersed rather than clustered together—so a lot of legitimate traffic could potentially be blocked as well. Rate limiting may be useful for brute-force DDoS, identifying each attacker by its aggressive connection rate, and automatically blocking. However, AppDoS attacks can evade rate limits by using high-impact, low-bandwidth techniques.

Finally, the speed at which the attack commences – sometimes referred to as the “thundering herd” effect – doesn’t leave much time to react and counter the problem. A coordinated DDoS, leveraging botnets and other always-on attackers, can hit without any advance warning. If you don’t have a tested plan to respond to DoS attacks, you’re going to have to invent one on the fly while simultaneously reporting your status every 15 minutes to the CIO.

How to Combat this New Approach:
Despite attempts of new tools to avoid automated blocking, there are usually key indicators which uniquely identify packets as belonging to the attack. Analysis by the University of Twente on the LOIC DDoS tool found the techniques to be surprisingly simple from a protocol perspective, featuring high repetition of a similar URL pattern, and absolutely no lower-layer obfuscation like IP spoofing. If you have a packet capture infrastructure in place, the attack packets will be easy to find, as they’ll constitute the majority of your capture. With this in mind, you’ll need to find a signature or behavior which is common to the attack traffic, but not on your normal traffic. In some cases your packet analyzer has visualization or an expert analysis tool to identify a useful characteristic for you. A very useful example of this kind of fingerprint analysis is the SpiderLabs analysis of LOIC, including packet dump and Snort rules.

The key here is to turn the attack’s strength into its weakness. Highly automated attacks will be fairly homogenous, so an attack fingerprint can quickly be developed and deployed, and the attack impact halted. The strength of DDoS comes from central coordination of large numbers of already-deployed attack engines. While these engines have dynamic target settings, they have fixed methods of attack. Identifying and blocking those attack methods greatly reduces the attack impact. This is true even of tools which are designed to provide increased detection avoidance via mixed attack method and increased randomization. After the HOIC tool was released as a detection-resistant alternative to LOIC, SpiderLabs analysis of HOIC showed that it has certain hard-coded aspects which still allow for detection and blocking. Fixing those mistakes might be easy for the attack tool authors, but the difficulties of distribution of black-hat software make upgrade releases problematic. Anyone who has done PC support knows the pain of large-scale application version management. Imagine performing version upgrades without benefit of an official trusted source of the software.

As an additional step in combating DoS attacks, once you have a fingerprint identified, you can also use it to determine if any of the hosts in your own network are sending similar traffic, causing someone else the same pain you’re feeling. If you have a network traffic recorder, use your packet analyzer dashboard to examine the historical traffic to and from that host. Even without a fingerprint, you can get started by looking at suspicious traffic. Command and Control of botnets has historically happened via IRC, so look for traffic to port 6667 and surrounding ports (e.g. 6660-6669). Any outbound traffic to a non-standard port is worth investigating to identify the C&C, report it per your CERT process, and block traffic from your network to prevent future botnet activity.

In the end, no security system on the market is foolproof, but as cyber crimes get more sophisticated, businesses must be able to recognize and constantly adapt to new security threats. In order to ensure that you are completely prepared in the event of a DoS attack, there must also be a security “insurance policy” in place—often in the form of a network recorder. The ability to quickly suspend this new level of DoS attacks is tantamount to protecting your reputation, your data, and your business a whole. Hopefully this blog serves as a reminder that if you don’t have a DoS mitigation plan already, now is a good time to create one before it’s too late.

Interested in learning more? Check out our post: “Top Trends in Cyber Security and Attacks” and webcast “Cyber Security – IDS/IPS is Not Enough.”

Share this post:
  • Twitter
  • Facebook
  • LinkedIn
  • Digg
  • Reddit
  • DZone
  • StumbleUpon
Posted in Cyber Security, Network Monitoring, Network Troubleshooting, network forensics | Tagged , , , | Leave a comment

OmniPeek CloudStats Plug-In

Moving services to hosted environments is viewed as a way to reduce costs by offloading the infrastructure management onto the hosting provider. However, one aspect of management should be maintained in-house: service level monitoring. Whether your server is located in a data center or in the cloud, network monitoring and analysis is still a crucial part of cloud-hosted network management; it just has a different role. The person in control of the network is now managing service availability and performance rather than managing their own company’s infrastructure. If cost was any factor in the decision to outsource, then it is absolutely critical to perform network analysis measurements to determine whether the costs justify the service levels.

However, network monitoring can be very challenging when moving to a cloud environment. Cloud typically leverages high levels of automation in service deployment to add and remove redundant load-balanced virtual instances. Rapid creation and retirement of VMs leads to IP address churn, which can make it very difficult for an analyst to track services by IP address.

With this in mind, we’ve created a special CloudStats plug-in that works in tandem with the existing network maintenance and monitoring benefits already provided by the OmniPeek network analyzer, making it easier to manage and monitor service availability and performance with cloud applications.

How does it work?
The CloudStats plug-in enables OmniPeek to display a cloud service by name, rather than IP address. Not only are names easier for people to recognize than numbers, the nature of Cloud and other web hosting techniques means that the network engineer does not control the IP addressing of the hosted services, and in fact the services’ underlying IP addresses may change between captures. The CloudStats plug-in allows this dynamic de-coupling of addresses and hostnames to occur, without any loss of clarity for a network analyst.

The CloudStats plug-in works by leveraging and extending the technology in OmniPeek’s Web views, extracting the host names directly from HTTP request packets in the “Host” header. Given that the “Host” header is created by the user’s web browser, the server name will correspond directly with the data returned in the HTTP response. The names are then automatically inserted into the OmniPeek nametable, so each cloud host name also appears in the OmniPeek nodes view, expert view, as well as any other feature in OmniPeek that displays nodes.

What else can you do with the CloudStats plug-in?
Beyond monitoring of externally hosted company services, the CloudStats plug-in is useful for analysis of any HTTP-based traffic.

When diagnosing problems with in-house web applications, it is now much easier to follow the logic flow split across multiple servers. Rather than trying to visually differentiate between a number of similar IP addresses in a contiguous range, packets are now clearly delineated by name as connections to the static image server, the SSO session initializer, the primary UI display formatter, and the data store.

When analysing single-PC issues, the CloudStats plug-in provides effortless propagation of website names. Gone is the uncertainty of a sea of unidentified external IP addresses. Web addresses are now automatically resolved, greatly speeding up the process of eliminating the unknown. This process will be appreciated when performing a security incident post-mortem: it’s far easier to focus on unknown servers when a significant portion of servers have hostnames in known and trusted domains.

Multi-PC captures will also be much easier to analyze, as servers will be auto-labeled with names, but clients will not.

Advanced usage: combining CloudStats with other plug-ins.
Sometimes the diagnostic need is to view traffic between the local network and the Internet, without worrying about which internal clients are connecting to which Internet services. The CloudStats plug-in is excellent at providing additional information about web servers. To reduce the clutter arising from multiple internal clients, the SubnetMap plug-in provides aggregated naming of subnets as single entities. The combined use of CloudStats and SubnetMap will transform the peer chart from a spaghetti tangle into a clean list of web connections, with all internal clients appearing as a single central chart entity.

For an expanded survey overview of internal servers and open services, combine the CloudStats plug-in with the Traffic Analyzer plug-in. The Traffic Analyzer plug-in provides a breakdown of open ports on hosts, for completely passive internal server port mapping. Combined with the CloudStats plug-in, each server IP address will additionally include the name pulled directly from the HTTP request.

Conclusion: Automatic name resolution, just like the Web.
Modern network deployments have reached the point where services can no longer rely on static IP addresses. The CloudStats plug-in enables modern network analysis using inline server name resolution.

Share this post:
  • Twitter
  • Facebook
  • LinkedIn
  • Digg
  • Reddit
  • DZone
  • StumbleUpon
Posted in Cloud Network Analysis and Monitoring, OmniPeek Network Analyzer | Tagged , , | Leave a comment