pointer

Monthly Archives: April 2012

Can Your Network Handle More Real-time Data?

Posted on by .

    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…

      How to Clean Up After a Security Breach with WildPackets

      Posted on by .

        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.”

          Best Practices for Network Management in the Era of Distributed Applications

          Posted on by .

            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.