Is your engineering team trying to decide if you should be exporting NetFlow or IPFIX? This is the area of the technology where many first time vendors make mistakes. Implementing NetFlow or IPFIX is not difficult. But when programmers rely solely on RFCs as an implementation resource, the result is usually an export that many flow reporting vendors won’t support. For this reason, this blog is largely dedicated to engineers who either want to export these technologies correctly or who need to troubleshoot what is wrong with an export they have been asked to look at.
Now that VMware vSphere ESX v5.1 supports IPFIX you may be wondering how to configure it; in fact, today I’m going to show you just that in a couple easy steps. VMware IPFIX support is a very exciting feature that will help with performance monitoring and can make virtual network management a lot easier to accomplish. Monitoring virtual servers has never been easier! Read more
I’ve been working with a service provider that deploys ASR1006 routers at his ISP’s internet Edge. They use private IP addressing which is NATed at the internet edge network. This allows scaling of IP addressing such that if they ever have more subscribers than available public IP address space they are not limited. The problem that this presents is that his country has regulations where government authorities ask that ISPs identify a subscriber based on IP address and time provided by authorities to the ISP. So he needed some reporting that would provide this visibility. Read more
This is a follow up to Michael Patterson’s blog last month regarding Cisco ASA v8.4(5) supports bidirectional NetFlow exports.
Our IPFIX and NetFlow Analyzer is the only NetFlow solution that supports the new bidirectional flows exported by the Cisco ASA.
This Cisco ASA update makes network traffic monitoring more accurate because the prior NetFlow export added the bytes between two hosts into one Octet Total Counter.
This is part #1 of a two part series on detecting P2P botnets with NetFlow. For years botnets such as Zeus and Spyeye made use of a centralized command and control (“C2”) server. This approach to botnet management was easily detectable using reputation services and other black-listing technology. While many botnets still use a traditional C2, a new breed of botnet has emerged that removes the need for a C2. These botnets make use of peer-to-peer technology to download configuration data and commands as obtaining the C2 IP to upload stolen information to the attacker. In part #1 of this blog series we’ll explore how P2P botnets work then cover detection and mitigation of P2P botnets in part #2.