September 2009 Archives

Yikes... This week Sega exposed some of Sony's highly sensitive future plans. Information regarding Sony Playstation 3 and motion controllers discussed in a meeting with Sega were leaked in a document that made its way onto Sega's press site.

 

So, who is responsible? How did this happen? If this happened in your company how can you find out? Enter network forensics.

 

Network forensics refers to the capture, storage and analysis of digital evidence that flows through your enterprise network. The most complete solutions record every single packet that is transmitted over your corporate networks. So, any emails, instant messages, FTP traffic or any other form of communication that takes place on the network can be reconstructed from the original transmissions. It doesn't get any more accurate than that. Network Forensics essentially allows you to reconstruct the history of your entire network.

 

IT personnel utilize network forensics to analyze historical network traffic to conduct or assist in many types of investigations. A few common applications for Network Forensics include HR compliance, intermittent issues, security cyber attacks and transaction analysis. This often starts with terabytes upon terabytes of data. Some tools, like OmniPeek, allow you to analyze data at the point of capture, thus eliminating the need for large data transfers (which are typically done) that consume time and bandwidth. OmniPeek also provides simple and intuitive means to drill down into the relevant data, making easy work out of finding the needle in the multi-terabyte haystack.

 

Using network forensics, you can track down the culprit. Of course, network forensics has many uses other than hunting down perpetrators, but it can be helpful in uncovering sensitive leaks. If they're not already, Sega should be using network forensics to get to the bottom of this snafu.

 

If anyone had doubts about the strength of the network monitoring/reporting/troubleshooting market, this week's news should put those doubts to rest. Of course we're referring to the announced purchase of NetQoS by CA for $200M in cash. This is a multiplier of approximately 4 over the reported 2008 annual revenue of $56M from NetQoS. Not a bad deal indeed for the current economic climate.
 
Though not sexy, and often considered commoditized, the network monitoring/reporting/troubleshooting market may be just the opposite. At the core of this market is packets. Yes, I said packets. Geeky, techie, call it what you want but we're back to basics on this one. Accumulating statistics on the basis of packets, whether through direct, deep packet inspection or through the use of flow-based technology available in most contemporary routers and switches, is proving to be a highly valuable capability, especially as networks grow and IT staffs shrink.
 
For years it seems the industry tried to steer clear of packets, looking to higher-level solutions like SNMP, but in the end it's becoming clear that packets never lie, and to obtain reliable network data one must start with network packets.
 
Now, I think we're going to come full circle on this one. Even the solution from NetQoS - which relies on flow-based information from routers and switches - can't provide the level of detail compared to complete packet inspection.  And this technique provides no capability of unequivocally determining a root-cause for reported problems. It merely shows network trends and alerts when thresholds are exceeded - it does not allow for detailed analysis as the offending data has already passed through the network. That's why NetQoS partnered with Network Instruments and OEM'd their Gigastor solution. With that partnership, NetQoS could provide the full monty - network reporting, monitoring, and troubleshooting. Or, as I see it, coming full circle back to packet capture and deep packet inspection -- the only way to truly identify network issues.
 
The purchase of NetQoS by CA provides validation that the network monitoring/reporting/troubleshooting market is not only alive and well, it is thriving. The traditional, "full-featured" network management solutions (like CA) are realizing that quality network monitoring, reporting, and troubleshooting are key features, and that they need capabilities like flow-based monitoring and deep packet inspection to continue to claim that their solutions are complete. The value of these types of solutions continues to rise, and the "big boys" have only two options, start developing fast or acquire. And with the head start many of us have with our network monitoring/reporting/troubleshooting solutions acquisition is by far the better alternative.

As Joanie Wexler points out in her recent Network World article "Prepping for (finally!) a standard 11n world," the imminent ratification of the 802.11n standard will push enterprises to be more serious about investing in 802.11n. Though some early-adopters have already jumped in, either just to test the waters or because their wireless application plans demanded increased performance, most enterprises have been holding off for the final ratification. For those enterprises entering the 11n water for the first time, the Network World article offers some good preparation tips, whether your entry is from the 3m board or a slow stroll in from the shore.

 

In addition to the tips already offered, several other important points come to mind as you prepare your entry. And you guessed it, our tips center around network management.

 

First, the benefits you'll realize as you move towards 11n will likely have you rethinking the way you use wireless, so what better time to also rethink how you  manage wireless. It goes without saying that your wireless management infrastructure will need to be upgraded to include 11n. Some management applications are just getting there, while others, like OmniPeek, have been there for many years already with a substantial amount of real-world testing, not to mention the use of OmniPeek as part of the Wi-Fi Alliance 802.11n interoperability testing. A move to 11n will most certainly include a move to WPA2 for security, if you haven't already made that move, increasing the need for a network management solution that handles both wireless and wired traffic simultaneously so you can monitor your 802.1x authentication all the way back to the wired sources. And with the increased bandwidth of 802.11n, you'll likely be considering applications like voice-over-wireless, which will require additional measurement techniques like wireless roaming to ensure proper operation of your network and ensure wireless call quality. Basically the message is this: plan for wireless management up front as you make the transition to 11n and make sure your wireless management solutions meet the demands of the new applications you intend to deploy.

 

Second, this is an excellent time to consider HOW you plan to monitor the wireless network, either for troubleshooting or 24x7 observation. Wireless networks are becoming much, much larger, and the days of walking around with a laptop running wireless analysis software to do troubleshooting are drawing to a close. However, wireless networks still require a "point of presence" to do adequate monitoring and certainly any troubleshooting, meaning data must be collected near the source of the reported problem. "Overlay" networks have been the standard solution for the past several years, but this is expensive solution requiring duplicative hardware and network resources (network drops, router ports, etc.). This can be mitigated during your 11n planning by designing in just a bit more density in your AP deployment and then relying on wireless management solutions that can leverage deployed APs and turn them sensors when monitoring or troubleshooting is required. This solution is highly cost-effective since the additional density typically only results in about a 10% increase in the number of APs, much less than the number of dedicated sensors you would need to deploy, and every AP can be put to use in the network resulting in even better network performance when not in use as sensors. This is an extremely important consideration as you roll out a new 802.11n deployment and the cost savings over a traditional "overlay" solution can be substantial.

 

So, whether you're diving in head first or just putting in your little toe, this is the time to reconsider not just network upgrades and the new applications you wish to introduce, but the new management challenges for the network as well. The increased throughput, increased mobility and increasing integration between your wireless and wired network put new demands on your wireless network management solutions. Make sure your solution has already proven that it can meet these demands. OmniPeek has been doing this for years.

Conficker is a computer worm targeting the Windows operating system that was first detected in November of last year. Wikipedia explains that Conficker "uses flaws in Windows software to co-opt machines and link them into a virtual computer that can be commanded remotely by its authors." A recent New York Times article reports that Conficker has more five million computers under its control, with estimates from other sources being much higher.

 

So, what is Conficker used for? Generating vast amounts of spam? Stealing information like passwords and logins by capturing keystrokes on infected computers? Delivering fake antivirus warnings to trick naive users to pay by credit card to have the infection removed? Researchers speculate that all of the above may be true. They do agree that the cluster of Conficker-infected computers yields massive, though mostly untapped to date, computer power.

 

There are two primary steps a network administrator needs to take to detect Conficker: apply filters and isolate data by connection.

 

Apply Filters: Filters are a powerful tool in any network management/analysis solution. Filters serve a dual purpose by limiting the number of packets targeted for analysis while isolating packets with key characteristics - in this case those characteristics unique to the Conficker worm. Conficker is known to take many forms, with new variants showing up routinely, making detection that much more difficult. Again, filtering is the perfect technique for keeping up with Conficker.  Filters are typically easy to construct and even easier to modify, so by investing a few minutes whenever a new strain is identified you can keep your network safe.

 

Isolate Data by Connection:        Conficker is known to use HTTP pulls and P2P push/pull to find peers and move around payloads. By focusing on these specific protocols and relying on characteristics of Conficker, like the use of pseudorandom domains of specific lengths in the case of HTTP and custom UDP protocols in the case of P2P, you can isolate suspect client machines. Filters are again a valuable technique, but since these pseudorandom domains are not known in advance, "negative filtering" is more appropriate. In negative filtering, filters are constructed to filter out all your typical, well-known traffic, leaving only packets of a suspicious nature. With this technique you hope to never see a packet - that means there's nothing suspicious on your network.

 

To be successful in detecting Conficker efficiently, a network admin should be able to automatically extract or fetch network data using one or multiple parameters, such as source/destination IP address, source/destination port, time, date, protocol, string, and more. Each kind of expression (IP, MAC, Protocol, Port, Pattern, Value and Length) should be able to be searched individually or in combination with operators (and, or, not, Group) to extract the required data from gigabytes or even terabytes of captured traffic. Solutions like WildPackets' OmniPeek Distributed Analysis Suite do just that.

 

Conficker is out there. Make sure it's not on your network.