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.
Author: Adam Powers
NetFlow Generators: Enabling NetFlow Without NetFlow Support (Part #2)
Continued from NetFlow Generators: Enabling NetFlow Without NetFlow Support (Part #1)…
Last week we covered NetFlow Generator basics including many of the more common deployment options. Now let’s take a look at some of the NetFlow generators available and what characteristics to look for in a best-of-breed NetFlow generator.
Introducing Plixer’s Internet Threat Center (ITC)
Plixer is pleased to announce a new weapon in the war against Internet threats: the all new Internet Threat Center (ITC). Based on hundreds of observation points deployed across the Internet, the ITC provides a near-realtime view of malicious actors across the globe. Plixer customers gain access to the ITC via regular updates to Internet host reputation data downloaded from the ITC to their Scrutinizer installations. NetFlow data collected from routers and switches within their network is compared to ITC data to alert when ITC suspects are active within the customer’s network environment.
This blog provides an overview of the Internet Threat Center and a brief tour of its features…
NetFlow Generators: Enabling NetFlow Without NetFlow Support (Part #1)
Introducing NetFlow and IPFIX
This article covers the benefits and capabilities provided by a new class of network monitoring technology called a NetFlow generator. But before we get too far into NetFlow generation details, let’s do a quick review of NetFlow itself for those that are new to the topic.
NetFlow and IPFIX are network monitoring technologies providing deep visibility into network traffic. NetFlow was originally developed by Cisco and later standardized into IPFIX by RFC 5101. Traditionally, NetFlow was included as a feature of routers, switches, firewalls, and other network devices. It’s even found in virtualization platforms such as VMWare’s vSphere 5.0 and above. Any device that can generate NetFlow packets is called an exporter. As packets travel through the exporter the device records information about the flow of traffic. Data elements such as packet count, source and destination IP, MAC address, and much more are stored in a memory resident data structure within the exporter called a cache. As the flows time out they are placed into a UDP datagram and sent across the network to a NetFlow Collector. The diagram below illustrates the process.
Once enabled NetFlow is used for a variety of network operations and security tasks including:
Network Segmentation, Segregation, and Zero-Trust Design
The Zero Trust model is a relatively new network security design model that requires network segmentation and segregation of employees from critical internal resources. The basic idea is that the internal network is no longer explicitly “trusted.” BYOD policies and the mobile workforce have brought new threats to the internal network that just weren’t there five years ago. It’s no longer practical to assume “bad guys outside, good guys inside.” Let’s take a look at exactly what this means…
Network Forensics and Incident Response Using NetFlow and IPFIX
Network forensics can be an intimidating subject. When IT personnel hear the word “forensics” they often recoil with visions of complicated software such as EnCase. Or they may think about expensive packet capture solutions such as Niksun’s NetDetector product line. While these tools can serve a specific purpose, your first line of network forensics defense should always be found in NetFlow and IPFIX…
100 Universities Hacked: Time For a Change in Network Security Philosophy?
A hacktivist group calling itself Team GhostShell has claimed responsibility for leaking 120,000 records from more than 100 higher-education networks. Team GhostShell claims the attacks were carried out in an attempt to “bring attention to failing educational standards worldwide.”
From the looks of it they were quite successful. The story has been picked up many times with dozens of articles discussing it.
I don’t want to get into a debate on world-wide educational standards, but I do think there is a serious discussion to be had around higher education network design, policy, and network security methodology.
NetFlow and IPFIX For PCI Compliance: Verify, Investigate, Impress
At least two or three times each week we’re asked how NetFlow relates to PCI compliance. Our answer is crisp and simple. No fancy requirement references or complicated legal speak, just practical advice that’s actually useful for those concerned with the PCI audit process. There are three key areas NetFlow and IPFIX analysis can aid the enterprise as it relates to PCI:
BYOD Policy Essentials: Trust But Verify
The IT Consumerization or “Bring Your Own Device” (BYOD) movement is already well underway and the iPhone5 launch will see even more employee sourced devices hitting the enterprise network. Even if you’re lucky enough to work for a company that provides iPhones to their employees, you probably don’t want to wait for IT to upgrade your iPhone now do you? You’ll want to BYOD.
So in support of iPhone5 users everywhere, here are three essential components of a BYOD-ready company: Policy, Education, Technology. Let’s discuss…
A Firewall Monitoring Tool You Didn’t Know Existed: NetFlow and IPFIX
IT professionals have been looking for better ways to monitor and store firewall logs for years. Properly handled, firewall events can give insight into APTs, DoS attacks, firewall rule planning and misconfigurations, policy violations, and much more. To date, Syslog has been the go-to mechanism for access to firewall log info. It’s universally supported by the firewall community, easy to understand, and it’s quick to implement on both the firewall as well as the syslog analyzer.
Unfortunately syslog is resource intensive on both the firewall and the log analyzer. It’s largely unstructured, requires string pattern matching, and the exact format and fields vary from one firewall to the next. How often do you turn on full “Accept” and “Deny” logging for every rule? Sure you can and yes it’s valuable but the amount of syslog created is tremendous.
Enter NetFlow and IPFIX…