Monthly Archives: March 2012

Setting the Foundations for 802.11ac and 802.11ad

Posted on March 29, 2012 by wildpackets.

IEEE 802.11 is a set of standards for implementing wireless local area network (WLAN) computer communications in the 2.4 and 5 GHz frequency bands. These standards are created and maintained by the IEEE LAN/MAN Standards Committee. The original version of these standards was released in 1997. However, the origins of 802.11 stem from a 1985 ruling by the U.S. Federal Communication Commission that released the ISM (Industrial, Scientific and Medical) ban for unlicensed use to allow civil use of spread spectrum technology.

IEEE 802.11 currently includes 21 ratified standards, and each new standard usually improves the security, the throughput and/or the interconnectivity between wireless network devices – leading to current capabilities like streaming NetFlix videos and real-time audio on wireless home networks and providing reliable access to mission-critical applications at work. And the industry is not resting at 21. Several new standards, most notably 802.11ac and 802.11ad, promise to provide even greater throughput, continuing to drive the dominance of 802.11 as the go-to wireless technology. We will discuss these protocols in more detail in subsequent blogs, but before we dive into these new standards, let’s look at the current state of 802.11 wireless.

Most enterprise and home wireless networking uses 802.11b, 802.11g or 802.11n. 802.11b and 802.11g have been around for a long time now but are still very widely used. 802.11a which was also introduced some time back to take advantage of the open spectrum in the 5GHz band was never met with wide acceptance, though it is certainly in use and has some distinct advantages, including more overall available bandwidth and less interference, from both other WLAN networks and non-802.11 devices.

802.11n is one of the newest standards and it offers a major upgrade from its predecessors, increasing the maximum net data rate from 54Mbps to 600Mbps. Advanced technology is required to achieve this ten-fold increase in data rate, and although the 802.11n standard has been ratified for a few years now, manufacturers are still not taking advantage of the full specification.

Although a ten-fold increase in data rate sounds great in theory, there are a number of practical issues that arise regarding physical implementations that make achieving the full potential of 802.11n quite difficult. 802.11n takes advantage of two significant technologies to achieve these data rate improvements – channel bonding and MIMO (multiple input, multiple output). Channel bonding leverages existing technology and is therefore relatively easy to implement, but does have potentially serious impacts on existing 802.11b and 802.11g networks, so its use must be carefully planned. MIMO, on the other hand, is a radical shift in 802.11 data transmission. In 802.11a/b/g, most devices have two antennae and one data stream, or bit stream. This bit stream is sent through both transmit antennae and received by both receiving antennae. 802.11n allows for multiple inputs and multiple outputs (MIMO), providing each transmit and receiving antenna with its own unique bit stream, and up to four bit streams can be sent simultaneously, thus increasing the throughput of your data fourfold. Perfect, right?

Theoretically, yes. But designing and manufacturing devices that can implement this technology, while still meeting other computing standards, like power consumption and physical form factors, can be challenging. And the biggest issue is with power consumption. Sending a different bit stream over each antenna requires significantly more power than sending the same bit stream. This is not so much of an issue for devices designed to be plugged in 24×7, like APs, but for clients, especially mobile clients like laptops and smart phones, the additional power requirements make full realization of the specification (4 distinct bit streams @ 600Mbps) nearly impossible, at least given current battery technology. That’s why you see very few 802.11n client devices that exceed 300Mbps in the market today.

In addition to IEEE sponsored specifications, industry associations are also very active in 802.11 technology, with the Wi-Fi Alliance (WFA) being the most well known. The WFA recently sponsored what is becoming a very popular 802.11 operating mode called Wi-Fi Direct. Loosely based on the 802.11ad-hoc mode, which was very insecure and therefore mostly disabled by users, Wi-Fi direct is a software protocol that allows devices certified under Wi-Fi Direct to exchange data without an Internet connection or a wireless router, in a highly secure and controlled manner. It provides a similar service to end users as Bluetooth, but it’s faster and allows devices to be farther apart when communicating, even supporting bandwidth intensive applications like video streaming.

So that’s where things are today. As we mentioned at the beginning, there’s much more to come, especially with the introduction of 802.11ac and 802.11ad in the near future, which will serve to further entrench 802.11, not only as a standard, but as an overall platform for development of unique capabilities. Join us next week as we dive deeper into the details of 802.11ac and 802.11ad, and their potential use cases.

Most Popular OmniPeek Plug-ins

Posted on March 27, 2012 by wildpackets.

OmniPeek network analyzer is among the easiest network analysis and troubleshooting software solutions on the market. Its highly extensible architecture enables additional capture and analysis capabilities via plug-ins. Adapter plug-ins allow OmniPeek to capture data from additional remote sources, and analytic plug-ins provide targeted visualization and search abilities within OmniPeek.

WildPackets – and even some of our customers – have created over 40+ plug-ins with the following being the most popular.

Adapter Plug-ins

Remote TCPDump Adapter
TCPdump is a standard tool on Linux and Unix-based systems. The Remote TCPdump adapter enables OmniPeek to perform real-time remote packet capture from those servers. The user interface allows standard BPF-style TCPdump capture filters, while the implementation uses SSH for fully automated control of the remote capture. Additionally, the use of SSH provides data protection for packets in transit, making this an excellent choice for remote capture, even across an untrusted network such as the public Internet.

The Remote TCPdump Adapter is very useful for: remote troubleshooting; extending visibility on an ad hoc basis; and application performance analysis with an “on-server” capture point.

Wireless Channel Aggregator
The Wireless Channel Aggregator extends OmniPeek’s wireless analyzer in order to provide true multi-channel capture of wireless packets, without the compromises of channel hopping or scanning. In an enterprise environment, there are likely to be multiple channels in use across the ESS, which means there is going to be a lot of roaming. Multi-channel capture with the Wireless Channel Aggregator lets you monitor client roaming, as well as assuring uninterrupted upper-layer data capture. It can also measure the latency of roaming devices and provides a full picture of channel use on your network.

NetFlow Analyzer
Network analysis via packet capture faces a challenge in modern networks: switches are designed to reduce packet leakage, which makes capturing a challenge. While using port spanning or mirroring is a helpful solution, it’s just not practical to use the span port to monitor all switch traffic all the time. Fortunately, there is a useful compromise: NetFlow.

The NetFlow Analyzer plug-in for OmniPeek enables statistical analysis of traffic via metadata. While NetFlow doesn’t provide the full flow information, it does provide the kind of “Top 10” and trending data that network operations teams rely on for ongoing monitoring. Since the NetFlow data is coming directly from your switches, it also means that you can quickly change gears from monitoring to troubleshooting by changing the switch configuration from NetFlow to traffic mirroring, going from a “10,000 foot view” all the way down to a microscopic analysis.

In addition, since the NetFlow Analyzer is part of OmniPeek, it allows you to analyze and troubleshoot the NetFlow stream itself!

Data Analysis Plug-ins
Latency Monitor Plug-in
Part of network monitoring is detecting sources of latency. The Latency Monitor plug-in provides valuable insight by measuring two types of latency, network and application, in order to figure out whether the issue originated from the network or the application side.

This monitoring technique is completely passive, using packets already captured so that it does not affect network performance in any way. The latency results can be graphed together in order to easily see where the problems are with the network or the applications. This is a great plug-in for network intelligence giving IT staff the information to make intelligent decisions about how to improve network or application performance.

FilterMe Plug-in
One important area of network monitoring is security incident response. Most security teams are very familiar with “regular expressions” or “regex,” which use a powerful text search language. To support those teams – and anyone else familiar with regex – we have developed the FilterMe plug-in. It adds a tab to our capture window, similar to the built-in filters tab, and allows a user to create and maintain a list of regular expressions that can be used as filters both during forensic searching and during real-time capture, making the creation and access to these regular expressions easy and convenient.

In addition, the UI for this plug-in features a tool bar with add, edit, copy, delete, import, and export buttons. Import and Export are especially important to allow team members to share regexes with each other, or to do bulk imports of regexes which have been extracted from locations such as Snort rules.

Application Specific Plug-Ins

WebStats Plug-in
The WebStats plug-in monitors web, FTP and TCP streams and displays the resulting statistics in the summary stats window. All of the different stats’ groups that this plug-in can monitor can be turned on or off through the option dialogue box like the one below. Through the summary stats area within OmniPeek you will be able to see the stats for all of these different data types.

The advantage of using the WebStats plug-in for OmniPeek is that you get insight into what’s really happening on the wire. Web server logs are notorious for displaying messages only about transactions that have completed. Server-side errors which result in partial page downloads may never show up in any web server log analytics. Viewing the transactions from the network allows deeper information and insight into the true browser-server interactions, because even partial transactions transfer information.

Instant Messenger Plug-in
This plug-in displays conversations for AIM, Yahoo, and MSN protocols. WildPackets customers in highly regulated industries such as financial trading and healthcare have used this plug-in in combination with our other plug-ins like the Regular Expression search to perform incident research on whether data has improperly (read: illegally!) been transmitted outside the network.

Browser Plug-in
Even as web design tools become more common and more sophisticated, there is still a need for network-based analysis. If a browser refuses to display a page, but the server insists that it’s been sent, viewing the packets that traversed the network provides a straightforward answer to the question of what happened. To make this analysis even easier, the Browser plug-in will render the HTML that it extracts from the network traffic that it captured.

The buttons on the plug-in window allow a user to navigate through the webpages in the capture buffer. The Packets Text shows what packets were used to build each webpage—allowing a user to find key packets in order to troubleshoot webpage or web destination issues quickly.

Plug-Ins Just For Fun

Google™ Map Plug-In
By far our most popular plug-in, the Google Maps plug-in enhances the analysis capabilities of OmniPeek itself. It displays a Google map in OmniPeek that shows the location of all public IP addresses of captured packets. You can toggle over the Google map graphic to see exactly where the source of the data is for each of those bubbles (see image below).

For an in depth, step-by-step tour of our top ten plug-ins click here.

OmniPeek offers a very rich set of analytical and capture capabilities that will help to improve your network monitoring experience. To check out more of our plug-ins go to MyPeek.

What’s the Big Deal with BYOD?

Posted on March 21, 2012 by wildpackets.

The latest alphabet of terms to infiltrate IT is BYOD (Bring Your Own Device) along with its relatives CoIT (Consumerization of IT), MDM (Mobile Device Management), and MAM (Mobile Application Management). As the industry scrambles to define each of these terms relative to each other, users are cheerfully coming to work with smartphones, tablets, laptops, etc., irrespective of company policies.

What’s driving this trend? The question is not, “Why are employees bringing their own devices?” The question is, “Why is BYOD a problem?”

Data Leakage
The most visible concern is Data Leakage. Most businesses run on files, therefore most devices must store a copy of those files locally to be able to read, edited, etc. Unfortunately, BYOD devices tend to be highly mobile, which infuses them with a high chance of getting lost. A recent survey by McAfee estimated that 5% of smartphones are lost. While losing a smartphone or an iPad is a hardship for a user, the business faces to lose even more if the device is found – found by the wrong person. Confidential company information used to be the primary concern, but recent legislation has shifted the pain to exposure of Personally Identifiable Information (PII). Breach disclosure laws ensure that a company must not only be publically shamed, but must individually contact every person whose data may have been exposed and potentially pay for identity theft protection or a similar measure. The penalties become steeper if the company deals with health care, covered by HIPAA regulation, or credit card processing, covered by the PCI standards. The ultimate threat for PCI violations is loss of ability to accept credit card payments.

The historical method of coping with a lost smartphone is mobile wiping – sending a signal to the device to erase itself. BYOD brings a complication: a company may not have the legal right to wipe an employee’s personal device. Forrester Research covered the legal complications in their report dated April 13, 2011, “Managing the Security and Risk Challenges of Personal Devices in the Workplace.” Many of these challenges can be mitigated if employees agree in advance to corporate policies and controls on their devices, if you can figure out which users are bringing in their devices.

Network Resource Consumption
BYOD devices are designed to be highly connected with minimal user effort, which they technically accomplish by greatly increasing their load on the network. Consider the discovery process for Windows Workgroups versus Domains: in a Workgroup, multiple copies of each advertisement are broadcast to all other nodes. Each PC sending such a broadcast is, for the duration of those packets, consuming all available network bandwidth by using a technique which requires every switch to deliver the packet to every node in the IP subnet. Domains greatly reduce the broadcast problem by using the Domain Controller(s) as a clearinghouse for device advertisement and discovery. Traffic is point-to-point, which limits the scope of packet transmission to the PC and the PDC. The Domain discovery process allows for much larger network scalability than the Workgroup method.

The canonical BYOD devices are made by Apple: MacBooks, iPhones, and iPads. Local network resource discovery is based around their Bonjour protocol (formerly called Rendezvous), which uses a multicast DNS lookup mechanism. There are rumors that even Apple had problems with multicast storms on their wireless networks, leading to their partnership with Aerohive on the Bonjour Gateway feature.

Finding the scope of the problem
The good news about BYOD is that the devices are noisy – OmniPeek will show them to you.

For Windows PCs, from your capture, apply a filter for “broadcast”, then copy to a new window. In that new window, look at “Statistics”, then “Protocols”. Anything using “IP:UDP:NetBIOS:Name Svc” deserves a second look. Be careful: Domain members use the PDC for name resolution first, but will fall back to broadcast if the name isn’t found. Also look at SSDP, which is the protocol used by UPnP.

An alternate method would be to capture NetBIOS Name Service packets to and from the PDC, either by using a span or tap. Clients which use the PDC for service resolution are Domain members so you can quickly cross them off your list.

For Macs and iPads, from your capture, apply a filter for “multicast”, then copy to a new window. In that new window, look at “Statistics”, then “Protocols”. Bonjour will show up as “DNS”. (Note that there is also a mDNS filter you can use, which looks at the well-known IP destination.)

Identifying the devices is useful for tracking down the owners, or for banning the MAC addresses from associating, or anything in between.

The hidden cost of embracing BYOD
Eventually, companies will be forced to embrace BYOD. At that point, the next hidden cost becomes apparent. Uncontrolled BYOD causes network exhaustion: controlled BYOD causes IT engineer exhaustion. Devices created for consumer use don’t usually take business resources into account, e.g. the iPad does not ship with a PowerPoint viewer. BYOD users will therefore ask IT to solve their problems, since the new corporate policy implies that the devices are “supported” – even if the policy explicitly states that IT will not provide support.

BYOD mobility devices embrace a new paradigm of UI, where user interaction is driven entirely by apps, not by files. The answer to any problem is usually addressed by a visit to the device’s app store, where there may be dozens of different apps all purporting to address the issue with different degrees of success, and completely different layouts. The difficulty of supporting applications on corporate-standard OS images is now trivial compared to being asked to support dozens of applications for each new device.

Packets never lie
Network analysis is once again a useful tool. For example, if a BYOD tablet can’t associate with the corporate WiFi, OmniPeek can capture the WiFi control packets to demonstrate that the device security settings don’t match with the ESS. Consumer equipment is often designed to hide complexity, and the manufacturer may not have included differentiation between AES and TKIP on WPA2 Personal or WPA2 Enterprise. Maybe a user is having difficulty authenticating to an internal web server – OmniPeek could show that the certificate signed by the corporate CA is silently being rejected by the device.

If there aren’t tools in place yet to provide control or insight into the BYOD issues, remember that the network protocols are standardized. IP and TCP will behave the same on every platform. Server logins will use the same PDUs on laptops running Windows, MacOS, or Linux. Even in the worst case, network packet analysis provides evidence to show why the BYOD smartphone can’t connect, which is infinitely better than the alternative of “I don’t know, try it again.”

Network Analysis and Monitoring Blog