The gory details

Building

Please read the README file first. You will understand the meaning of funny
configure script flags.
Basically, if you setup all requirements, you would only need to run:
$ ./makedist in the package directory to create the configure script
$ ./configure -with-telcosux -with-mysql-include=yourpath -with-mysql-libraries=yourpath
$ make
# make install (as root !)
And you are up. Default prefix is in /opt/neye but you can change it with the usual
-with-prefix=yourfavoritefoldertree.
You will have neyed installed in /opt/neye/sbin and as a bonus a wonderful netflow
random traffic generator to play with your new toy.
Actually, man page is not yet available, but command line features are almost
self-explaining.
I usually start the collector with a script like this at system bootup:
#!/bin/sh

export ADDRESS=ip.address.where.to.listen
export DB=ip.address.of.your.mysql.db

case "$1" in
'start')
echo "Starting NEyed for Netflow analisys"
/usr/local/sbin/neyed -d -a $ADDRESS -p 2055 -m $DB
;;

'stop')
pkill -9 neyed
;;

*)
echo "Usage: $0 { start | stop }"
exit 1
;;
esac
exit 0
And that's all ! Anyway, a maybe better startup script is included in the source distro.

MySQL DATABASE Configuration

Now setup your MySQL server with the provided DUMP in the dbdump/dump
file which should look like:
CREATE TABLE FLOWS (
RECNUM bigint(20) unsigned zerofill NOT NULL auto_increment,
PROBE varchar(16) NOT NULL default '',
TIME_RECEIVED datetime NOT NULL default '0000-00-00 00:00:00',
FLOW_VERSION tinyint(4) NOT NULL default '0',
SEQUENCE bigint(20) unsigned zerofill NOT NULL default '00000000000000000000',
SOURCE_IP varchar(16) NOT NULL default '',
SOURCE_PORT int(11) NOT NULL default '0',
DEST_IP varchar(16) NOT NULL default '',
DEST_PORT int(11) NOT NULL default '0',
NEXT_HOP varchar(16) NOT NULL default '',
PROTOCOL int(11) NOT NULL default '0',
TCP_FLAGS int(11) NOT NULL default '0',
TOS int(11) NOT NULL default '0',
BYTES bigint(20) unsigned NOT NULL default '0',
PACKETS bigint(20) unsigned NOT NULL default '0',
FLOW_BEGIN datetime NOT NULL default '0000-00-00 00:00:00',
FLOW_END datetime NOT NULL default '0000-00-00 00:00:00',
SOURCE_AS int(11) NOT NULL default '0',
DEST_AS int(11) NOT NULL default '0',
SOURCE_MASK smallint(6) NOT NULL default '0',
DEST_MASK smallint(6) NOT NULL default '0',
PRIMARY KEY (RECNUM)
) TYPE=MyISAM;

The database should be named FLOWDB and the MySQL user owning the database should be
named collector . The user should have NO password. Yes, I know what you are thinking,
nowadays with all this security issues around you're requesting us to setup a user
passwordless on a database ?
Yes, now I don't have time to lose with an insecure user/password authentication, setup
an IPSEC/VPN/PPTP/VTUN/whatever authenticated and encrypted tunnel between the collector
and the database and drop connections from other IPs with a local firewall on the DB.
If you are willing to patch my code and will be so kind to sent it to me, I will test it
and if working integrate it in the mainstream giving appropriate credits. But actually
it's not my focus. If you really need it, patch it, send me the diff and I'll include it.
We'll see.

System Probe configuration

The excellent fprobe 1.0.6 by Slava Astashonok is a very good solution
to use a UNIX system as a Netflow probe.
The setup of the probe is pretty easy since once it is compiled, you will only need
to start it up. No configuration files are required, everything is specified on the
command line. I built the package to be installed in /opt/fprobe, but it can be
installed wherever you want.
I start it up at system boot with the /etc/init.d/netprobe script which looks like:

#!/bin/sh

INTERFACE="bond0"
COLLECTOR="youripaddresshere:2055"

export INTERFACE
export COLLECTOR

case "$1" in
'start')
echo "Starting fProbe for Netflow analisys"
/opt/fprobe/bin/fprobe -i$INTERFACE -r59 -n5 -l1 $COLLECTOR
;;
'stop')
pkill -9 fprobe
;;
*)
echo "Usage: $0 { start | stop }"
exit 1
;;
esac
exit 0
Since the fProbe package is libpcap based, it will probably run on most Unixes without
too much hassle. At least, I used it on Linux and Solaris without any issues.
You will need to specify the interface on which it will take statistics and the couple
address/port of the collector. In the script we specified also a high priority when
running and the NetFlow protocol version (Neye actually supports Version 5; although
more recent versions are available from Cisco they are also not yet supported from
the fProbe). Typically NetFlow version 5 is a good trade if you don't need to catch
input data from Catalyst 6500 routing modules which (for what I remember) are supported
in NetFlow >= 8

Router configuration

The configuration of the NetFlow collection and consequently export on Cisco Routers
is very trivial. In my development environment I use an asyncronous 56K serial modem
to connect to the Internet with a Cisco 2600 as access router and wanted to be able to
know about incoming flows on unfiltered ports.
Enter the supervisor mode on the router:

Router>ena
Password:
Router#
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip flow-export version 5 peer-as
Router(config)#ip flow-export source Dialer 0
Router(config)#ip flow-export destination 10.1.1.254 2055
Router(config)#ip flow-cache timeout active 1
Router(config)#interface Dialer 0
Router(config-if)#ip route-cache flow
Router(config-if)# exit
Router# exit
Router# copy running-config startup-config

Always take into account that on Cisco Routers, NetFlow tracks only incoming flows, so
this is the correct setup if you want to know the flows incoming from the internet.
If you enable NetFlow on the Ethernet 1/0 interface you will only see the flows going
outside. If you enable both, data will be reported twice, so be careful !
I used the Dialer 0 interface with the ip route-cache flow to track incoming (unwanted)
connections. The router is running IOS version 12.2.11(T8)
If you have multiple collectors, in recent IOS versions you can setup up to 2 targets,
but I'd bet on a single collector Virtual IP, maybe on a HA Cluster system or, even
better, on a load-balancer for HA/Load-Balancing issues.

A typical deployment

Typically you will configure all your routers to send their netflows to the collector,
which in turn will store data on your MySQL DB. Then you will query the DB with MySQL,
write yourself a handy-nifty Apache/PHP/MySQL query application and you are up.
I'm thinking about an Aqua/X11 client, but it will take a bit, days are only 24h long.
If you don't have routers, setup the fprobe package as previously described and go
for it. If you don't have access to the router (many ISPs provide you with the router
itself with the Internet connectivity but manage routers by themselves and are not
so happy with unix nerds going to change their working configs) but maybe have a
managed switch with port mirroring facility, then you can simply setup a dual
homed box with one interface on the mirror port of the switch which "hears" the
traffic and another one which sends the flows to the collector. Clean and simple,
ala snort (http://www.snort.org).

Security Issues

Apart from the passwordless user in MySQL (but I showed you a simple solution),
I have found two security issues when designing NEye. The first one is that packets
travel the network unencrypted and this can lead passive listeners to gain an idea of
which kind of traffic is directed to hosts (at least, what is allowed by network policies).
If your Netflow probes (Routers) are on a WAN, wiretapping is not so easy, but in my life
I learned that nothing is impossible.
No data can be sniffed since they are not present in the payload of NetFlow packets but
this can help to discover firewall policies and valid addresses for spoofing.
You can easily solve this problem setting up an IPSEC channel on port UDP/2055 between
the probe and the collector, but compatibility between devices should be planned before
NetFlow deployment.
The second one is that someone that is able to sniff traffic (or knows that there is
a Netflow collector on the net and knows its IP address and service port) could send
spoofed traffic information to the collector. I'm evaluating if adding TCP Wrappers,
but perhaps the best solution is to filter with a local firewall on the collector only
the IP addresses of your Netflow probes.
In all cases, there are simple solutions and these are probably risks you can live
with if you apply the right countermeasures.
I'm interested in serious ideas about solving these problems, but IMHO the ones above
described are pretty good ones.