I have discovered a new way to load trace files so that as they are loaded they are filtered.  This is really useful when the filter is an advanced plug-in filter -especially, if the plug-in filters out packets from the file and generates its own packets that are inserted instead.   In my case, I was looking for a way to load a NetFlow file, and have the NetFlow plug-in generate fake packets, instead of loading the NetFlow packets. However, this technique will work for any filter or filter plug-in.  

The key to this technique is the SQLFilter plug-in, which can be downloaded from the MyPeek Community Portal (current maintenance required).   It loads packets from a file into a real-time capture window through the SQLFilter Plug-in, instead of directly into a file window.   By using a real-time capture window, there is a user defined ring buffer, instead of a static file buffer.    This makes it possible for the NetFlow Analyzer adapter (current maintenance required) to process and filter out NetFlow packets, and create and insert fake packets into the capture instead.

Here are the steps necessary to use this technique:

First, create a real-time capture using an adapter that won't actually provide packets when the capture is started. The Microsoft Loopback Adapter is a good example, but there are others.     This is important because certain features, like the PeerMap, won't do anything unless the capture has been started.  Choosing a "NULL" type adapter allows the capture to be started, but not actually capture any packets.

Once the capture window opens, create a new advanced filter on the filter or filter plug-in of your choice.   In the example below, the NetFlow Analyzer is selected.

Next, create a new SQLFilter database and add one or more files to it.   This will add the files to the database. The database file is a single sqlite database that will now contain all the packets for all the files you load into it. This has many advantages, but in this case, we are only doing it in order to load the trace file into the real-time capture window.  In the example below, a NetFlow file is loaded into the database.

Now start the capture.   

VRoom!  Do you hear the roar of the engine?  If so, you may have a problem.  You should probably clean out the fan on your computer, or call support. ;-)

Finally, double click on the packet file.  As the packets are being loaded from the database, a progress dialog will appear. This dialog has a Cancel button, so you can cancel the load at any time. On large files, this is a very nice feature.

And that's it. I found this to be very useful, and thought I would share.   

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.

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.