WildPackets Network Analysis and Monitoring Blog

100 Gigabit Networks, We're Getting Warmer...

2010-08-26T15:52:08Z

Though the economy is still lagging, there is no slowdown in the demands being placed on networks. We predicted last year at this time that 100G networks were on their way when the Department of Energy awarded $62 million to build one. Since then, networking vendors like Cisco and Juniper Networks have been racing to introduce 100-Gigabit Ethernet with Juniper being the first to draw blood by creating a 100 Gigabit Ethernet router interface card this past June.

According to a recent NetworkWorld article, Brocade Communications is introducing a 100-Gigabit Ethernet module next month for the top-end Ethernet, IEEE 802.3ba standard. The standard defines specifications for both 40Gbps and 100Gbps connectivity.

The number of issues surrounding the development and deployment of a 100G Ethernet network will depend on how deep into the network the 100G needs to go. Even with these recent innovations there are still challenges to consider including:

Network analysis and monitoring - there is still no single network analyzer that can capture at 100Gbps. One way to achieve this is with a series of load balancing taps that break the traffic down into smaller 10G lines, which then feed into separate analyzers working in parallel. No one has invented it yet

Infrastructure/cabling - twisted pair cable only goes up to 20G right now and to go higher it would mean re-cabling with fiber

Cost - if 100G comes into play and everything has to be replaced in between the core router and PC's, it's going to cost money. Even the network card in the PC has to be upgraded to 100G

As we continue down the 100G path, the next generation of networking tools will surely follow. But let's not get ahead of ourselves - the proliferation of 100G networks is still a pipe dream today.

Prowling the Network for a Rogue Wireless Access Point

2010-08-18T23:34:35Z

WildPackets welcomes this guest blog post from independent security consultant Dr. Gordon Mitchell, who details below using Wildpackets OmniPeek Network Analyzer to hunt for a rogue wireless access point to solve network security vulnerabilities.

Prowling the Network for a Rogue Wireless Access Point

By way of review, a wireless access point (WAP) is a device that allows wired communication devices to connect to a wireless network using Wi-Fi or Bluetooth. The WAP usually connects to a router and can relay data between wireless devices, such as computers or printers and wired devices on the network. Prior to wireless networks, setting up a computer network required running tons of cables through walls and ceilings in order to deliver access to all the devices in the building. With a WAP, network users can add devices that access the network with fewer cables.

Wireless access is convenient and increases flexibility but at the same time security becomes a larger issue. Wired networks usually base the security on physical access control, but if wireless access points are connected to the network, anyone close by could connect. In fact, major data thefts have been initiated by attackers who have gained wireless access to organizations by connecting wirelessly to access points inside the organization.

Most often, the hardest part is convincing IT that there is an actual wireless network security breach. Fortunately, solutions like Wildpackets OmniPeek Network Analyzer make looking for wireless signals easy.

When I suspected a breach on a customer's network, I immediately turned to OmniPeek and produced a quick demo. My first step was to check the peer map for unencrypted connctions (see illustration below).

The IT guy said that there was no problem. After I reviewed the header of an email that he had just sent, I asked him if he was sure. There was an address on this plot, which was really close to the IP address of his mail server. After a bit of head scratching, he agreed.

Looking closer at the suspect IP address, it indicated that it was coming from a D-Link wireless router. But the company didn't have any of those, so they assumed it "wasn't a problem". After offering a further explanation of rogue access points, they began to slowly agree.

In the end, OmniPeek convinced the IT department that there was a problem to be investigated - an unauthorized access point on a critical server. With tools like OmniPeek, it's easy to prowl through complex networks and identify security issues, but a well-rounded explanation of the problem is truly the key to keeping networks healthy.

Aren't all networks created equal, Google and Verizon?

2010-08-12T21:02:28Z

The latest flack around Google's joint announcement with Verizon on preserving the open Internet has had its fair share of media attention. Here is the source document that created the latest fracas: Verizon-Google Legislative Framework Proposal.

The joint Verizon-Google proposal addresses nine specific elements focused on preserving the open Internet (net neutrality.) These points include: consumer protections, non-discrimination requirement, transparency, network management, additional online services, wireless broadband, case-by-case enforcement, regulatory authority, and broadband access for Americans.

It's not our intent to address each point individually. Most are self-explanatory. What we want to do is highlight the largest issue with this attempt to make the Internet more accessible. That being said, Verizon and Google are essentially claiming wireless is different, and that data on wireless networks need not be as "neutral" as data on wired networks. According to the Wireless Broadband element, "Because of the unique technical and operational characteristics of wireless networks, and the competitive and still-developing nature of wireless broadband services, only the transparency principle would apply to wireless broadband at this time."

This is a pretty far-reaching statement, as it proposes to exempt wireless broadband networks from the consumer protections and non-discrimination requirement outlined in the proposal - the basic elements of net neutrality. The consumer protections element says service providers cannot prevent sending and receiving lawful content, running lawful applications, and connecting any legal devices to the network. The non-discrimination requirement prohibits service providers "from engaging in undue discrimination against any lawful Internet content, application or service in a manner that causes meaningful harm to competition or to users." It goes on to be even more explicit: "Prioritization of Internet traffic would be presumed inconsistent with the non-discrimination standard ...".

If these proposals are accepted, providers of wireless services CAN block lawful traffic, applications and devices; and they can prioritize Internet traffic according to their own desires, presumably giving advantages to data or media from certain sources. But how did we get to this point? Aren't wired and wireless networks essentially the same, other than the fact that wired networks got a head start? There are obviously some technological differences, but the underlying usage of the networks is the same, and that's what defines a network - its usage. The same rules should apply to both wired and wireless networks, including blocking and prioritizing traffic differently depending on the source of the data. To make the claim that they should be treated differently because broadband wireless is "competitive and still-developing" seems quite self-serving. Couldn't the same claim have been made for broadband-wired services 10 years ago?

We are very interested to see if the proposals get accepted and how this debacle will ultimately turn out. There is definitely something to watch here, especially if you share our view that wired and wireless networks are created equal...

Warding Off Espionage with Network Forensics

2010-08-04T22:56:33Z

There's a chance you could have a spy. Watching your every move, just waiting for the perfect time to attack and hijack your precious information.

A recent InfoWorld blog serves as a wake up call to those companies who have not taken the increasing threat of electronic espionage and network security seriously. According to the blog, a growing number of companies are being spied on electronically by sources in other countries. This isn't the first we've heard about this though, back in January, hackers from China had broken into several companies' computer networks including Google to steal information about Chinese dissidents as part of "Operation Aurora," which was one of the largest cyber-attacks ever.

These incidents keep occurring because companies believe that their current security software is good enough or they've just simply ignored the issue. The truth is that in order to have protection from these types of stealth spies you have to collect packet history within the network. And the only way to receive this information is by performing forensic analysis.

Network forensics is the capture, recording, and analysis of network events. All pertinent network traffic is collected in a single location, rather than scattered across the network. Data is captured in a common data format and does not need to be transferred or translated in any way for analysis. Using network forensics data mining tools, security teams can reconstruct the sequence of events that occurred at the time of a network breach or cyber attack and get the complete picture. Forensic analysis exposes attackers, methods, and damages. Lucky for us, new and more powerful network forensic products are out there to help defend against electronic spying threats. Even though there is a vast array of network forensic technologies to choose from, organizations should know that there are really only three basic elements to any general-purpose network forensic solution:

1. Data capture and record - This is the ability to capture and store multiple gigabytes of data at high network throughput (for example, 10 Gigabit) without dropping or missing any packets. Every network forensic solution has its limitations, including sustainable throughput, packets per second, data management, search functions, etc. These limitations can and should be determined through practical lab tests, and the results should be repeatable and documented. This includes both wired and wireless networks.

2. Data discovery - Once data are recorded on the storage media, the solution should provide a mechanism to filter particular items of interest, for example, by IP address, application, context, etc.

3. Data analysis - Finally, you want some built-in assistance for examining the patterns and anomalies found during the discovery process to help you determine what actions were recorded in the captured packets.

The information forensic analysis provides can lead to an informed and efficient security posture within an organization to deter similar attacks in the future. As criminals get smarter and savvier, being able to detect and characterize attacks is crucial. Information leakage not only results in monetary losses but also can be a serious threat to national security. Having the right network forensic solution in place can help to discover and eliminate possible threats in your network and to provide lawful interception capabilities when needed.

Is SaaS Killing the Appliance Business?

2010-07-29T20:58:07Z

With SaaS (software as a service) adoption continuing to increase, some have postulated that appliance-based network analysis and troubleshooting is in jeopardy. In a SaaS model, an application is hosted by a provider and then offered as a service to enterprises across the Internet. In other words, no on-premise hardware is required. This type of software delivery is attractive because it removes the requirements to download, install, and maintain software on-premise. Not having to buy the IT infrastructure is also on obvious financial benefit.

SaaS is taking off. In fact, Gartner recently forecasted that SaaS' worldwide revenue would surpass $8.5 billion in 2010. That doesn't mean it's the right choice for everything, namely network analysis and troubleshooting. We believe network analysis is difficult and complex and the process cannot be effectively transitioned to a service via the cloud. We believe that network analysis and troubleshooting is still best handled with on-premise software and hardware appliances. Here's why:

1. You still own the network

Just because you've outsourced the application, doesn't mean you've outsourced the network. And odds are your internal network has grown to be quite complicated, and your users are relying on that network for access to your SaaS provider. Ongoing monitoring, with a capability to drill down into suspicious issues and quickly achieve root-cause analysis, remains as important as ever. Perhaps even more so, if the issue is with the SaaS provider and they do not own up to it.

2. Independent (and in-house) verification is key

You have the vested interest in the performance of your overall network design, whether that design is totally within your control or involves third parties like SaaS providers. Relying on a third party to monitor your network is like ignoring your vehicle's check engine light. You know the light is on; you have no idea what's wrong and no ability to dig in and figure out the problem.

3. Multiple SaaS vendors, then what?

Once you start down the SaaS track, you'll likely work with multiple application providers for best-of-breed applications. It's imperative that network monitoring, analysis, and troubleshooting remain within your control. What if applications interact? Who will notice, or care, besides you? And what about network latency, between you and your SaaS providers or perhaps between the SaaS providers themselves? The best location to measure latency is within your own network, right where your users are. This will give the most accurate latency measurements and constant monitoring will ensure acceptable end-user performance.

Network speeds are constantly evolving and the arrival of 10G brings a whole new set of challenges for network managers. Proper network analysis and troubleshooting is key in this high-speed world as our networks become even more complex. While SaaS may be convenient and inexpensive, appliance-based network analysis and troubleshooting is the best way to ensure organizations continue to meet critical operational practice needs. We do believe, however, that the future of enterprise computing is not going to just be on-premise or SaaS. Instead, they will likely exist in symbiotic harmony.

How to Kill a Keylogger

2010-07-21T14:50:12Z

WildPackets welcomes this guest blog post from independent security consultant Dr. Gordon Mitchell, who details below using Wildpackets OmniPeek Network Analyzer to discover and thwart a keylogger who had compromised a local government network.

Keylogging tracks the keys struck on a keyboard in a discreet manner so that the person using the keyboard is unaware that their actions are being monitored. There are several keylogging methods, ranging from hardware and software-based approaches to electromagnetic and acoustic analysis.

A while back, I found evidence of a keylogger on a local government computer... hunting time.

Using Wildpackets Etherpeek (now included in Omnipeek) as my weapon of choice a live analysis was performed. It turned out that a "smoking gun" email had started it all by explaining how to install the keylogging software. This is obviously a concern, especially in a government setting where information is at high risk of being compromised.

So, what had been stolen? If no keystrokes were captured there wasn't much to worry about. I went to work.

A clone of the computer's hard drive was created to connect the machine to the Internet. Before plugging in the Ethernet cable, I made sure to limit the export of data.

The restored computer was allowed to connect to the Internet through a firewall, which only allowed it to get DNS information. By hacking the Windows hosts file connections were directed to a test machine that was set up with a fake SMTP server. The computer was turned on and text was typed into Notepad.

If there was an active keylogger, this text would have likely been picked up and emailed off with previously recorded activity. Not long after plugging the Ethernet cable in, I saw activity. The test machine was monitored with a Peek-equipped PC. All the traffic between the restored computer and the test machine was recorded, thanks to Wildpackets.

The first intercepted traffic included the material below:

This information came from the keylogger report that was being sent to an offshore email account. The good thing was that classified reference related to staff categories was not secret government information.

Next came the text that I had typed on the restored machine keypad. This was confirmation that the keylogger was stealing information. A bit more analysis defined the scope of the loss, allowing repair of the damage.... and identification of the person who installed the keylogger. RIP, keylogger.

Why Deep Packet Inspection Isn't Just for Network Engineers

2010-07-12T14:37:34Z

Network troubleshooting using deep packet inspection is a tried and true approach for network engineers - no one would ever doubt this approach when a difficult problem is plaguing the network. But suggest the use of deep packet inspection for troubleshooting slow applications and you'll likely get some blank stares. Deep packet inspection is the domain of network engineers, not application engineers, right?

Not necessarily. Analyzing decoded packet headers is definitely more suited to a network engineer, but what about the payload data from all the packets? Most network engineers find little value in the payloads, often times they filter them out to conserve analysis resources. But payloads can be of high interest to application engineers investigating application problems, including slow response time.

Consider the example of a help desk application used by a large online retailer. Support professionals, who access the help desk application for each customer call they receive, begin to experience slow response times from the application and of course the initial report is that the network is the problem. A network engineer begins his investigation and after a short time, calls in the application designer stating the problem is the application, not the network. "How do you know that," asks the application engineer? "Simple", says the network engineer. "Your application is generating the following messages. Your server command was deadlocked with another process and has been chosen as a deadlock victim. Re-run your command. And The rollback transaction request has no corresponding BEGIN TRANSACTION". Flabbergasted, the application engineer exclaims, "Where did you get that information?" "From the packet payloads involved in the slow response time transactions on the network, using deep packet inspection network analysis troubleshooting. You should try it sometime."

Deep packet inspection can provide greater value than simple network troubleshooting. Application engineers can certainly benefit, both in troubleshooting application problems and analyzing the overall behavior of an application before trouble is reported. The following four steps should be done to quickly isolate and analyze specific application data:

1. Capture data at the appropriate location
For application analysis and tuning, it's best to locate a distributed network analysis software probe or appliance in the data center in line with the application and database servers. This will capture the data for all application users, whether local or remote.

2. Save packet data to disk
By saving packets to disk and employing post-capture analysis, you can take your time in doing your analysis, without worrying about missing key data.

3. Filter stored packet data for the application of interest
Some solutions make this easier than others, but this step is crucial in creating a data set that is manageable and applicable to the application you wish to analyze. This can often be done by filtering out all traffic except traffic that has the source or destination IP of your application server or servers. If it's a troubleshooting exercise and the problem is isolated to a particular client, you can even further refine the filter to just the IP to IP conversation between the client and the server.

4. Use built-in analysis features to look for common faults

Before diving in and looking for complex, one-off faults, use the built-in fault detection and analysis capabilities of your analysis software (again, these features can vary wildly between competing solutions) to look for common issues, like one-way traffic, database client errors, slow server response time, failed login, resource errors, etc.

Overall, even though you may get some awkward stares for suggesting deep packet inspection to troubleshoot slow applications, in the end it's worth it because, you'll not only keep the network healthy but employees happy and productive.

TimeLine Network Recorder is Unveiled

2010-06-26T00:10:54Z

Our blog last week explored a common misconception that even though several protocol analysis and troubleshooting solutions claim "line-rate" analysis, the actual rate at which packets are written to disk without data loss varies greatly -- the majority of solutions have a capture rate of somewhere in between 4-6 Gbps. We are excited to say that's no longer the case with our newest product, TimeLine Network Recorder!

The introduction of TimeLine at Cisco Live! brings the capture and analysis of traffic on highly utilized networks to a whole new level. Independent test lab, Miercom verified it as one of the fastest, continuous solutions in its class, achieving capture-to-disk without any loss for traffic rates up to 11.7 Gbps. That is nearly three times faster than similar solutions!

TimeLine also offers unsurpassed network traffic collection and recording, quick data rewinding, simultaneous real-time network monitoring and rapid search and forensic analysis of collected data. With TimeLine, all network issues can be identified, analyzed, reconstructed and resolved quickly.

Using TimeLine, enterprises have complete visibility across their network with its advanced port aggregation and display of media statistics including network utilization, protocols, packet sizes, packets per second, jitter and packet loss in real-time. TimeLine analyzes historical network traffic and rewinds data quickly for troubleshooting, application, security and business transaction analysis and human resource and policy compliance. The TimeLine graph, allows visualization and interaction with statistics generated from large amounts of network data. There are even pre-defined forensics templates and customized search options to simplify the searching process.

Lastly, WildPackets' OmniPeek Enterprise Network Analyzer can be used in conjunction with TimeLine to reconstruct VoIP, IM, Email, and Web applications in their original format. Additionally, TimeLine offers advanced video and VoIP analysis, including a customized dashboard, signaling and media analyses, VoIP playback and visual expert analysis.

A list of TimeLine's unique features:

Fastest, continuous network traffic capture available
Interactive, detailed timeline visualization of data in real-time
Rapid, post-capture forensics search and data retrieval, including deep packet inspection
Real-time, distributed monitoring and alerting for both network and media data in a single solution
On-the-fly application reconstruction
Intuitive, easy-to-use User Interface

TimeLine's innovative capture-to-disk technology represents a milestone in enterprise network analysis. By reproducing and solving intermittent network issues faster than any other solution in its class, it's exactly what enterprises need to stay productive, competitive and profitable.

The Truth About "Line-Rate" in Network Analysis

2010-06-24T16:08:58Z

They say the truth shall set you free...

There is a common misconception lingering in the networking world. Even though several protocol analysis and troubleshooting solutions claim "line-rate" analysis, the actual network throughput that can be effectively analyzed varies greatly and is highly dependent on a number of factors. One of the most important factors is whether or not the analysis is expected to be real-time, or if all analysis will be performed post-capture. Real-time analysis is extremely demanding, so much so that "real-time" and "line-rate" should not even be used in the same sentence. The only condition under which line-rate can even be considered is when data is being collected for post-capture analysis, often referred to as forensics analysis. In this scenario all network packets are written directly to disk. The most capable network analysis and troubleshooting solutions available today have a data capture rate of somewhere in the range of 4 - 6 Gbps. Even though these solutions claim 10G "line-rate" captures on fully utilized, half-duplex 10Gigabit links, they begin to lose packets if pushed beyond 4 - 6 Gbps, obviously far short of a fully utilized rate of 10Gbps. A solution that could capture at that high rate and not drop any packets would be beyond the state-of-the-art!

The fact is that today's networks are actually faster than the available network analysis and troubleshooting solutions, resulting in greatly diminished network visibility. This is significant to network administrators because the 10G technology enterprises are actively deploying can be difficult to troubleshoot, and until now, no vendor has been able to capture at the half-duplex line-rate without packet loss. However, achieving both real-time visibility and historical network traffic storage for post-incident analysis is possible in 10G environments - you just have to add clarity to your analysis by being specific and a bit more selective.

Three tips for being more selective when analyzing 10G Ethernet traffic:

1. Understand the network and the data you need to collect

Do not try to blindly move forward and perform analysis without knowing what data matters most to your organization. It's important to know exactly what you want to capture and what information is going to be beneficial for your analysis. Your requirements will likely vary between each network segment and you are likely going to have to capture data at several locations. The key is to use post-capture analysis and only save the data to a disk in real-time. Trying to capture and analyze simultaneously, in real-time, on highly utilized network segments puts too much strain on the system.

2. Capture only what you need

There is a great temptation to try to capture and analyze everything because enterprises fear that the source of the problem is not immediately known. When it comes to 10G Ethernet traffic, analyzing every bit of data is nearly impossible due to the volume of data. However, if you know your network well enough, certain conditions can be immediately ruled out. By using these clues to limit the collection and analysis to only what is necessary, you can dramatically improve network analysis performance.

3. Limits are everything

Even after analysis has been streamlined to only essential areas of the network, data capture for network analysis on 10G networks generates a great deal of data quickly, and managing the data becomes a significant challenge. The data is typically stored for subsequent retrieval and post-capture analysis. The two most common formats are standard packet files and databases. In either case, two metrics to manage closely are file size and frequency of disk writes. If the files are too large they will be unworkable on the computer being used for analysis. Smaller files lead to more frequent disk writes, and this can rob the system of resources for performing the actual packet capture. Optimum performance is achieved with a balance of these two demands, and this is different depending on the hardware resources available. After a few captures, you can determine if either of these parameters can be better optimized for your system.

Until a solution is developed that doesn't just claim "line-rate" analysis but actually allows packets to be written to disk without data loss, these tips are helpful for keeping an organization up to speed with 10G traffic. In the end, paying careful attention to detail when configuring network management systems will reward you with the analysis and troubleshooting results you desire.

Has World Cup Fever Spread to the Network?

2010-06-18T18:02:26Z

It's called World Cup fever for a reason. With millions of people watching and reading related news online, it undoubtedly increased Internet traffic. In fact, people apparently care more about soccer than they do the presidential election. The very first day of the tournament, traffic exceeded the previous record of 8.5 million views per minute (vpm), which occurred when Barack Obama was elected. According to measurements by Akamai, traffic for news sites on June 11 started to climb steadily at 6 am ET and peaked six hours later, reaching nearly 12.1 vpm. And the fact that June 11 was a workday didn't stop people from watching. People turned to their office computers to follow the action. Being able to identify high talkers and effectively manage traffic is a must for organizations that want to stay productive and successful.

Below are some considerations for enterprises in regards to their networks during times of high traffic:

Understand how your network performs normally

The only way a company can improve network performance is to know where they stand in terms of network demands. Then they can measure success against those baselines. By looking at Internet connections, WAN links, WLAN environments and the data center, enterprises can get a sense of how their network normally acts. A network analyzer can also help organize this information into a report that can be used to not only solve issues that currently exist, but also to allow organizations to go back in time to validate performance and bandwidth utilization as necessary.

Prune and clean WLAN traffic

Remove unnecessary traffic. Devices like printers, support stacks and protocols that aren't in use in the environment can be eliminated. Sometimes, protocols that help manage the network, like routing protocols and SNMP can be found, hogging valuable bandwidth without any purpose.

Know your options

Consider a Web surfing policy. The 2010 FIFA World Cup lasts from June 11 through July 11, 2010 and will likely suck up a lot of bandwidth. Having a set policy in place will help keep traffic down and is an option to be explored. However, getting employees to abide by regulations it's often more of challenge than it's worth.

The fact is, it is important to see new trends approaching and make changes to the network to account for an enterprise's behavior. Popular events can erode profitability and corporate security, as employees not only watch but also participate in social media discussions and gamble online. Review network analysis measures and policies now, so when 2014 rolls around, networks stay healthy and humming.

The Benefits of Filtering and Slicing

2010-06-11T17:08:00Z

Filtering and slicing are powerful tools to employ when performing network analysis. Their use helps to focus analysis on just the data of interest, while reducing the load, including data volume and overall processing, on the system being used to collect and process the data. The bottom line is that techniques like filtering and slicing reduce the amount of time required to troubleshoot complex networks.

Filtering is a way of limiting the overall number of packets captured and stored based upon user-specified criteria. Typical filtering criteria include addresses, protocols and ports, though more detailed packet information including values, patterns and lengths can also be used in filters. The ability to generate complex filters that combine these criteria using Boolean logic enables users to develop very specific filters that identify critical and often transient network events. Using "not" logic allows you to filter out all "good" traffic, so when packets pass the filter you know you have data you want to investigate.

Slicing truncates the packets after a certain length, significantly reducing the data that is collected and analyzed. Slicing is typically used to capture the header information from packets and not the payloads. This is a very useful technique, particularly when your analysis is centered on nodes, protocols, and flows, and not payload information, which is a significant percentage of typical network analysis.

Four key benefits of filtering and slicing include:

1. Extra time for value added projects

Improving an engineer's ability to isolate traffic by filtering and slicing can reduce the time spent responding to problems and increase the time available to proactively prevent other issues. Businesses benefit in that they accelerate the resolution of critical issues, thereby shortening the impact on productivity or revenue.

2. Quickly identify anomalous traffic

By applying filters that only allow unexpected traffic through the analyzer, enterprises can quickly monitor their network for malicious behavior. This makes it difficult to spot conditions that need immediate attention and to set up alarms so engineers can be notified of anomalous conditions even when they're away from their network dashboard.

3. Resourceful analysis

The overall amount of data to analyze and store is significantly reduced through the use of filtering and slicing, freeing up more processing power for capture and analysis and more disk space for storing the data that's truly important to the current analysis task.

4. Increased flexibility and performance

By not capturing the whole packet on a segment, you're limiting the collection and analysis to only what is necessary; certain conditions can be immediately ruled out, which dramatically improves network analysis performance.

Filtering and slicing are not without their drawbacks. Both techniques are "final" - once employed, the discarded data is lost forever. This is typically not a problem, if you're confident you know what you're looking for, but for situations where the problem isn't clear, or no problem is even expected, it may be better to collect all packet data for a complete post-capture forensics analysis. Also, the use of filtering and slicing does require advanced knowledge for effective results. Both can lead to frustration if not carefully employed.

Love is in the Air: A story about OmniEngine ROI

2010-06-07T18:33:37Z

A few years ago, I wrote a love story about the marriage of decoders, protospecs, and plug-ins. Technically, it was a story about integration, but when the whole becomes so much greater than the sum of the parts, it becomes love. Today, I have another love story to tell. This one is about the marriage of automation and plug-ins for the OmniEngine, and the love here is so strong that I can smell it. Yep, that's right, love is in the air, and it smells like, well, it just smells really good.

So anyway, as I have been advertising lately, more and more customers and prospects are showing an interest in automating OmniEngines with scripts, in test labs and other environments, particularly for wireless applications. There is also an increased interest in developing plug-ins for the OmniEngine. Up until now though, one of the limitations has been in the lack of a way to use scripts to automate captures on the OmniEngine, and configure settings in plug-ins running in those captures. And that is where our love story begins.

Just recently, we completed a development for a customer that coupled the ability to automate captures though scripts and capture templates, with the ability to configure plug-ins with options from those capture templates. This marriage of the front-end automation capabilities, with the back-end plug-in capabilities is new and very powerful, and will enable many different ways to configure and use OmniEngines.

But you might say, "come on, how many people actually write automation scripts and plug-ins?". I would say the question is not how many, but how big is the opportunity? And not the opportunity to write scripts and plug-ins, but rather the opportunity to invest in an extensible network application platform that can be customized and extended to meet the diverse needs of any company that depends on the network to run their business. It is about having all of the parts that can be put together and integrated in all kinds of different ways, creating solutions that satisfy many different customer requirements.

Of course, it is also about supporting these solutions, which is why we have a team of developers at WildPackets, called the Custom Engineering Group, who are dedicated to this, and are very good at working with customers who want to use these capabilities of the OmniEngine to achieve the highest level of ROI possible.

Now where was I? Oh yes, what we did for this customer was to port the Cisco AP Capture Adapter to the OmniEngine. We did this for an automated test lab they are building that uses OmniEngines to capture and analyze traffic from new wireless devices. Many of our customers are doing this, and the reasons are obvious. Testing consists of repeating process over and over. This can be time consuming and expensive for humans, but very cheap and practical when automated.

This customer is using the Cisco AP Capture Adapter, but there are many different adapters that can be used to capture with, for the wireless and wired traffic. In fact, most customers use the Linksys WUB600N USB adapters . Couple that with a USB Ethernet HUB from Belkin, and wow, the configuration possibilities are many and many.

In this case, the customer had already invested in the Cisco APs. The Cisco AP Capture Adapter is a plug-in adapter that receives packets from a Cisco AP and inserts them into a capture. The problem was that the solution had to be automated through scripts, and the Cisco AP Capture Adapter needed to be configured with the port to listen on, and the IP address of the AP to accept packets from.

To address this limitation, we enhanced the OmniScript automation library so that it can pass options from the script to the adapter plug-in. This was the missing link which, when addressed, completed the front 2 back automation solution for them. With the ability to set options in the plug-in through their scripts, they are able to fully automate their test lab deployment. They still have work to do, but my understanding is at this point they have it working, are quite pleased.

Now is that love or what? I think so, and I enjoyed being a part of it. But the real story here is the opportunity for others to take advantage of and benefit from this type of front 2 back integration going forward. The new version of OmniScript has been posted to MyPeek, along with the Cisco AP Capture Adapter for the OmniEngine. Over the course of this year, we are also developing a number of new plug-ins that will use this capability.

That is the end of the story, but while I have your ear, there is another angle to this story that may help to shed light on what is happening here. Recently, we released a new version of the OmniEngine Plug-in Wizard to MyPeek. This version of the Plug-in Wizard generates a plug-in with sample code that OmniPeek can use to create a capture template with plug-in options. The resulting capture template can be used by a script to create a capture and configure the settings of the plug-in. Wow, how cool is that? We now have a wizard which creates sample code demonstrating all of this wonderful integration. This is yet another piece of the puzzle falling into place.

So there you have it. With the WildPackets OmniEngine, and some tightly integrated tools for automation and plug-ins, the possibilities are endless.

-Chris

Greed vs. Privacy, aka, Van Valin and Mertz vs. Google

2010-06-02T15:50:14Z

The whole Google debacle - collecting "wireless payload data" with its Google Street Views (GSV) data collection system - comes down to nothing more than a greed-driven lawsuit disguised as a case of social justice.

Let's face it, the security of wireless data from 802.11 networks has been talked about for years. But if someone is doing important things on their wireless network and they're not employing a reasonable level of security, then do they really have anyone to blame but themselves? They've opened their data up to anyone and the ones who really want that data aren't going to openly admit that they collected some while driving by, like Google. No, those that want credit card and personal banking information and possibly someone's identity, will sit much farther away, use directional antennas and collect data for much, much longer than Google does during a GSV drive-by. That's the only way to get meaningful data.

To further illustrate this point, let's assume the GSV vehicle drives so close to someone's house that it passes an AP within a few feet. Let's assume the vehicle is following a typical residential speed limit of 25mph as it drives directly by the AP. A typical AP has a range (and a generous one at that) of a few hundred feet in either direction, that's about 400 linear feet, again assuming the GSV vehicle has driven right up to the AP. At 25mph, the vehicle can travel the 400 feet by the AP in just a little less than 11 seconds. So at best, Google has collected 11 seconds of data, assuming that the person was online at that specific time and that they have completely ignored all pleas by every 802.11 device manufacturer to use wireless security.

The issue, however, is that Google has no idea what channel anyone's AP is set to, so it can't drive by scanning on just one channel. It needs to scan all of the available channels to collect the data that's really of interest, namely whether or not there's an AP around, its network name, and the channel it's broadcasting on. In the 2.4 GHz band there are 11 channels (in the US) and in the 5 GHz band there are typically 8 (again, in the US). Assuming they need to scan through all of these channels, data is only being collected on an individual's specific channel 1/19 of the time, reducing the slice of data that has been collected by Google to less than 0.6 seconds. Perhaps some critical, unsecured data did cross the network in those 0.6 seconds, but that data is now combined with similar data from thousands upon thousands of other users. This sure doesn't sound like the most effective solution to try to get access to user's critical wireless data.

So in the end it's not about data privacy, it's about greed. Could Google have been a bit smarter and not collected the payload data? Well sure they could have. But is there anything malicious going on here? Only on the part of those trying to hide behind data privacy invasion for financial gain.

What's not even considered in this debacle is all of the real data Google does collect, freely and with all our consent, every time we surf the web ...

Wireless Roaming and its Effect on Quality

2010-05-26T15:29:41Z

Roaming occurs when a handset moves out of the range of one access point into the range of another. It gives users the mobility to move around within a local coverage area and still be connected to the network. However, roaming is one of the primary reasons why users experience problems on wireless networks. Excessive roaming times lead to poor quality for voice and video over wireless and can lead to dropped calls or data connections.

Roaming usually involves a channel change, but that depends on the type of technology deployed. If it's a multi-channel architecture, which is most likely the case, a channel change is required. When roaming occurs, the client needs to be re-authenticated and re-associated with the new access point, which takes longer than 150 milliseconds in most instances, especially when advanced features like WPA2 and WMM are in use. Most organization's wireless networks are outfitted with multiple access points (APs) and users can experience poor signal strength and performance despite proper coverage in the area if the client is connected to the "wrong" AP. Even in the most modern, centrally managed systems, the wireless client is the one who decides when to switch from one AP to another. This decision is typically determined based on the current signal strength and is executed by the underlying software controlling the wireless client radio (the "supplicant"). This software is different from manufacturer to manufacturer and from device to device, so the way the decision to roam is made varies widely. In most cases, the wireless client will wait too long and as a result the available signal strength lowers, before the client switches to an AP with greater signal strength.

New and improved standards are available that specify the conditions for "fast roaming," enabling transitions that take as little as 5 - 10 milliseconds. These specifications include:

802.11i - with opportunistic key caching so there is no re-authentication step
802.11r - fast BSS transition, which optimizes the hand-off as clients move from one access point to another
802.11k - radio resource management of WLANs allows re- authentication to be maintained between multiple APs and has predictive capabilities

These new standards (802.11i isn't new, but it's still part of an improving situation for roaming) allow APs greater control in determining when roaming should occur and the APs are more in tune with the current performance of, and demands on, the wireless network. However, this situation is even better when the overall wireless network is under the control of a centralized manager. The issue is that adoption of 11k and 11r has been very slow, especially in wireless clients, and until adoption increases significantly users will continue to suffer slow AP transitions when roaming, leading to poor voice and video over IP performance.

In the meantime, the best approach is to carefully monitor and analyze the roaming activity on your network. Obtaining a complete and accurate view requires real-time aggregation of data from multiple channels and APs, with integrated analysis that leads to detailed reporting - who is roaming, how long each event is taking and what does the average look like for each AP. The end result is simple, yet the process is complex, demonstrating why proper network analysis tools are key to staying productive.

Congrats Yahoo but Please Take Care of Your Network

2010-05-14T20:56:30Z

The recent approval for Yahoo to build a massive campus in the heart of Silicon Valley is the perfect example of how wireless networks can grow and evolve. The sprawling campus will consist of thirteen six-story buildings across 3-million square feet. As a result, the 12,000 Yahoo employees will likely become much more dependent on wireless access, demand it from more locations and expect to have the performance and reliability characteristics of the wired network. There are several issues to consider in a wireless campus environment. As new standards come into play like fast roaming, capacity will become even more of an issue. As more people try to access the network in one area, density will increase and put significant strain on the access point resource. Security is always an issue but in a wireless network environment, it's more about the nature of those on the network and their desire to cause harm. Besides coverage, capacity, density and security issues, below are some key considerations for Yahoo and other enterprises that have distributed wireless worlds.

1. Take advantage of a single vendor's access point management system

These management systems are key in a distributed world. Before, there were wireless monitoring vendors called overlays, which offered additional sensors to access points deployed in the network. However, they were costly in terms of power, equipment and network drops. With access point management systems, companies have access to software that can control channels and power on the fly. Depending on the amount of traffic and people accessing one particular point, the power can be adjusted appropriately.

2. Keep an eye on the spectrum

There are still several interferers out there. 802.11n uses an unlicensed spectrum meaning a lot of other technologies share that same spectrum including Bluetooth, cordless phones, video cameras and microwaves. It's important to be aware of interferers, know what they are and how to manage them.

3. Don't forget about troubleshooting

Monitoring the network through access point management systems isn't enough. It only indicates trouble - it doesn't troubleshoot and solve problems. Being at the scene isn't always effective with campus wide networks, especially when you have satellite offices or are spread across acres of land. Enterprises need an analysis and troubleshooting capability on top of management that can be distributed. This can be done through purchasing additional software probes with wireless adapters. Another option is to leverage the network that is already in place by switching thin APs into promiscuous mode, where their only purpose is to receive and collect packets to be analyzed. Lastly, enterprises can equip network USB hubs with wireless adapters that plug into the Ethernet network. This makes the network transparent and businesses can access adapters to use along with their network troubleshooting software anywhere on the network.