Dear Peter,
As it turns out, there were two issues, both with me :| -
- having only previous experience with NetFlow v5, I was not
understanding that there can be NetFlow v9 traffic that
contains only templates, but no flow information; as it turns
out, that was *not* the relevant issue;
- noting that I was getting bogus values for packet and byte counts
per flow, and going back for a little RTFM, I finally saw the note at
http://sourceforge.net/projects/nfdump/ :
"For CISCO ASA devices, which export Netflow Security Event Loging (NSEL)
records, please use nfdump-1.5.8-2-NSEL."
since the "NetFlow" I was after was actually NSEL from an ASA,
switching to the noted version fixed me right up.
Thanks for the investigation on my behalf!
-g
--
Glenn Forbes Fleming Larratt
Cornell University IT Security Office
On Sat, 28 Jul 2012, Peter Haag wrote:
> Hi,
> So far everything looks ok to me. Your command line is correct and should
> work. I have myself some collectors running like this and it works as
> expected.
>
> Just not, that tcpdump catches the data well below the socket in the kernel.
> Make sure you do not have any firewall/SElinux rules in pace, which block
> the traffic.
>
> - Peter
>
> On 23/7/12 10:59 PM, [email protected] wrote:
>> I had nfdump working, successfully collecting flows from a single source
>> (128.84.56.36), thus:
>>
>> /opt/app/nfdump/bin/nfcapd -p 9995 -b 128.84.12.147 -l /opt/flows/Data
>> -S 7 -t 600 -w -P /var/run/nfcapd.pid -D -B 256000 -z
>>
>> . I then tried to reconfigure, in preparation for having multiple flow
>> sources, thus:
>>
>> /opt/app/nfdump/bin/nfcapd -p 9995 -b 128.84.12.147 -S 7 -t 600 -w -P
>> /var/run/nfcapd.pid -D -B 256000 -z -n
>> testxtfw,128.84.56.36,/opt/flows/Data/testxtfw -n
>> prodxtfw,128.84.107.4,/opt/flows/Data/testxtfw ...
>>
>> , and, not being able to get anything other than empty 276-byte flow
>> files, decided to revert to my previous configuration.
>>
>> Now I get nothing but empty 276-byte flow files, where I previously had a
>> working config.
>>
>> Flow traffic is arriving:
>>
>> 16:53:42.266759 IP 128.84.56.36.28761 > 128.84.12.147.9995: UDP, length 804
>> 16:53:48.714480 IP 128.84.56.36.28761 > 128.84.12.147.9995: UDP, length 620
>> 16:53:53.936530 IP 128.84.56.36.28761 > 128.84.12.147.9995: UDP, length 440
>> 16:53:59.074668 IP 128.84.56.36.28761 > 128.84.12.147.9995: UDP, length 380
>> 16:54:00.791164 IP 128.84.56.36.28761 > 128.84.12.147.9995: UDP, length 1416
>> 16:54:00.897028 IP 128.84.56.36.28761 > 128.84.12.147.9995: UDP, length 1424
>> 16:54:01.120101 IP 128.84.56.36.28761 > 128.84.12.147.9995: UDP, length 1416
>> 16:54:01.273505 IP 128.84.56.36.28761 > 128.84.12.147.9995: UDP, length 1424
>> 16:54:01.403860 IP 128.84.56.36.28761 > 128.84.12.147.9995: UDP, length 1408
>> 16:54:01.623874 IP 128.84.56.36.28761 > 128.84.12.147.9995: UDP, length 1408
>>
>> , and, to all appearances, is making it to the nfcapd process:
>>
>> socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
>> bind(4, {sa_family=AF_INET, sin_port=htons(9995),
>> sin_addr=inet_addr("128.84.12.147")}, 16) = 0
>> listen(4, 128) = -1 EOPNOTSUPP (Operation not
>> supported)
>> getsockopt(4, SOL_SOCKET, SO_RCVBUF, [17179998208], [4]) = 0
>> setsockopt(4, SOL_SOCKET, SO_RCVBUF, [256000], 4) = 0
>> getsockopt(4, SOL_SOCKET, SO_RCVBUF, [17180131326], [4]) = 0
>> recvfrom(4,
>> "\0\t\0\fsS^wP\vx\334\0\0PZ\0\0\0\0\1\0\0d\0\33\260,\200T\f\223"..., 65535,
>> 0, {sa_family=AF_INET, sin_port=htons(28761),
>> sin_addr=inet_addr("128.84.56.36")}, [16]) = 916
>>
>> , but it never actually writes them to the files. I rebooted my server
>> just in case something was wedged in the IP stack, to no avail.
>>
>> Is there some state information, that might be leftover from my failed
>> attempt to use -n ..., -n ..., that I need to reconfigure? I have a
>> non-working installation here and I'm really stymied.
>>
>> Thanks for any info,
>>
>> --
>> Glenn Forbes Fleming Larratt
>> Cornell University IT Security Office
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Nfdump-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
>>
>
> --
> Be nice to your netflow data. Use NfSen and nfdump :)
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Nfdump-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
