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.