glFlow 0.1.4
by Vlad GALU <dudu@dudu.ro> and
Andrei GAVRILOAIE <gavriloaie_andrei@yahoo.com>
--[ 0x01 What's this ?
glFlow is a traffic analysis tool mainly intended for high-speed links. It detects DoS incidents by performing real time NetFlow traffic aggregation and analysis.
--[ 0x02 What do I run it on ?
It was written on FreeBSD and tested on both FreeBSD and Linux. It should work on any OS to which libpcap and OpenSSL were ported. The rest of the code is perfectly portable.
--[ 0x03 How does it work ?
Cisco Systems have defined the 'flow' as a four value tuplet: {srcaddr, srcport, dstaddr, dstport}. The format evolved over time. The complete structures for various NetFlow versions are available on Cisco's site. Now, let's assume that the attacker floods the victim with packets that keep the same characteristics throughout the duration of the attack. No source spoof, no source port increments or randomizations. That would lead to a very large packet rate inside that flow. glFlow calculates the average packet rate in every flow and raises an alarm signal if the threshold is hit.
What about spoofed attacks ? How are they detected ? Simple. glFlow keeps a history for every destination host that it sees. When a new flow is created, the flow counter for that host is incremented. The average number of newly created flows corresponding to a specific host in a specific amount of time is calculated, and, as above, an alarm is raised if the threshold is hit.
To prevent attacks that don't hit any of the above thresholds, there's a new one starting with v0.1, measuring the packet rate for a destination.
--[ 0x04 Can't other tools, like SNORT, do this ?
We sincereley believe not. Remember, glFlow was written with high speeds in mind. We've been using it at over 500Mbps. At that speed, with an ordinary x86 machine, even with a strong motherboard/NIC combination, you can't do anything fancy. glFlow was specifically designed for detecting large floods in real time, or at least something close to that.
--[ 0x05 How is it that it's so fast ?
Well, Andrei did a great job implementing a very fast binary tree. That allowed us to drop the threaded model and choose a single loop design. The new results were stunning. The tests were made on a P4 Xeon/3 GHz, with an Intel GigE NIC. The average traffic rate was about 500Mbps, with an average packet rate of 100kpps. That lead to about 200k active flows. glFlow managed to clean the inactive ones in less than 0.3 seconds. There was no alarm raised after more than 5 seconds of flooding. glFlow ate ~50% of the CPU, while consuming about 40MB of system memory.
--[ 0x06 How do I install and run it ?
Run ./configure --help. You'll see two adjustable knobs: --with-hash and --enable-debug. The first one permits you to switch between MD4 and MD5 summing of the flow and host structures kept in the memory. The second lets you run glflow in the foreground, printing some statistics on stdout.
The thresholds are harcoded in defs.h. You shouldn't have any trouble tweaking them. However, we've observed that the best results are obtained when using the same values for flow lifetime and the time between flow cleanups. And they shouldn't be much over 20. The smaller the tree is, the faster it will be cleaned.
Finally, edit your /etc/syslog.conf and write something like this: "local6.*<tabs>/var/log/something". Restart sys[k]logd afterwards.
Fire glFlow up, like this: "./glFlow <interface> <bpf filter>" and watch /var/log/something for changes. You may play with nmap or some DoS programs to test it. The IP's in the syslog will be shown as integers rather than in dotted notation. We decided to leave this job to the log analyzer.
--[ 0x07 Can it go even faster ?
Sure. There are a few methods which permit you to improve the packet capture. For more info read Luca Deri's paper: http://luca.ntop.org/Ring.pdf
--[ 0x08 Licensing ?
GPL.