Christian,
I was able to obtain raw Netflow files by modifying
CISCOEXPORTER/COLLECT directive to COLLECT: {flows}
in the cflowd.conf file. Now Dave Plonka's flowscan complains
for invalid index in the cflowd file:
[root@anestis flows]# bin/flowscan
NextHops and OutputIfIndexes are undefined.
Identifying outbound flows based solely on destination address ...
Loading "bin/Napster_subnets.boulder" ...
Loading "bin/local_nets.boulder" ...
2002/06/23 20:07:18 working on file 127.0.0.1.flows.0...
127.0.0.1.flows.0: Invalid index in cflowd flow file: 0x0! Version 5
flow-export is required with *all* fields being saved.
2002/06/23 20:07:18 flowscan-1.020 CampusIO: Cflow::find took 0
wallclock secs ( 0.17 usr + 0.00 sys = 0.17 CPU) for 1000000 flow file
bytes, flow hit ratio: 0/3149
Segmentation fault (core dumped)
[root@anestis flows]#
So I am trying to figure this out.
Regards,
-- Anestis
-----Original Message-----
From: Karasaridis, Anestis, ALASO
Sent: Sunday, June 23, 2002 2:46 PM
To: [EMAIL PROTECTED]
Subject: RE: [Ntop] ntop and Netflow exports
Christian,
Thank you for your very useful suggestion. Even though option -T cnfp
does not work
on my tcpdump 3.4-39, I saw udp traffic going to port 2055 while running
ntop, which is a good sign:
[root@anestis /root]# /usr/sbin/tcpdump -s 1500 -n -l -v -i lo port
2055
Kernel filter, protocol ALL, TURBO mode (63 frames), datagram packet
socket
tcpdump: listening on lo
14:07:09.610262 > 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:07:09.610262 < 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:07:24.610262 > 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:07:24.610262 < 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:07:37.230262 > 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:07:37.230262 < 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:07:44.610262 > 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:07:44.610262 < 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:07:57.750262 > 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:07:57.750262 < 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:08:10.750262 > 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
14:08:10.750262 < 127.0.0.1.socks > 127.0.0.1.2055: udp 1464 (DF) (ttl
64, id 0)
However, by looking into the default output directory
/usr/local/arts/data/cflowd/flows, cflowd does not seem to dump
anything.
Is there some piece that I'm missing ? I have checked the cflowd.conf
file to make
verify the output directory.
Reply to BTW: We are planning to use Netflow data from peering links to
detect security
related events like scans. However, I would like to start with a single
host in order
to be able to isolate the scans better. I'll share my experience with
ntop-netflow exports.
Regards,
-- Anestis
-----Original Message-----
From: Christian Hammers [mailto:[EMAIL PROTECTED]]
Sent: Saturday, June 22, 2002 9:32 PM
To: [EMAIL PROTECTED]
Subject: Re: [Ntop] ntop and Netflow exports
Hello
On Sat, Jun 22, 2002 at 09:20:13PM -0400, Karasaridis, Anestis, ALASO
wrote:
> However, I don't see any flows being exported. For example if I go to
"Data Sent"/"Netflows" there's 0 NetFlow packets sent.
How did you "look"? Try: "tcpdump -s 1500 -n -l -T cnfp -v -i lo port
2055".
The "Data Send/Netflows" must mean something different, it's always 0
here,
too.
bye,
-christian-
BTW: Will you use netflow on different servers/routers to account your
backbone network? Or just on this single host? In the first case, be
aware
that netflow is a input-only accounting and may *NEVER* account data
that
is send out to a network card (because this traffic is then assumed to
be
input on another backbone router and else you would acct'd it twice).
So adjust ntop with "ether dst <your MAC>" or similar until there's
better
support for this.
BTW2: We have it currently in Beta-Phase and will use it in production
with
the end of the current Beta phase. Please report any problems and
successes
if you check the netflow data for correctness. So far the values were ok
here, although we had to patch ntop a bit due to the fact that it never
had complete TCP sessions (see "BTW:" for reason).
I'm very interested in ntop+netflow in bigger networks so contact me if
you
like.
--
Christian Hammers WESTEND GmbH - Aachen und Dueren Tel
0241/701333-0
[EMAIL PROTECTED] Internet & Security for Professionals Fax
0241/911879
WESTEND ist CISCO Systems Partner - Authorized Reseller
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://lists.ntop.org/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://lists.ntop.org/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://lists.ntop.org/mailman/listinfo/ntop
