[netsa-tools-discuss] Eavesdropping and collecting Netflow v9

[George Warnagiris]

Thanks Chris!

> Network adapters filter incoming packets in hardware
> based on the MAC address, easing the burden on the
> driver software – because of this, its unlikely your SiLK
> collector would even be seeing those packets even if
> you have told SiLK to listen for them.

That's what I thought too.  I manually set the IP and MAC address on the interface to the ones used by the foreign collector, as discovered by tcpdump.  (Normally this would be a problem because the switch would flag it as "arp spoofing" and restrict the port, but since the switchport is in SPAN mode it doesn't accept 'inbound' traffic, so it had no effect on the traffic seen by YaF AFAICT).

YaF wouldn't be interfering with rwflowpack in this case, would it?  Can you think of a way to test if the packets are making it through the IP stack, with the manually set hardware address and IP address?

I concur with your assessment:  YaF isn't interested in the netflow UDP packets here.  This is more of a flowpack issue.  

I can see the UDP 5999 flows in the primary (YaF probe) repository.

Appreciate the thoughts!

George

-----Original Message-----
From: Chris Inacio [mailto:inacio at cert.org] 
Sent: Tuesday, December 01, 2015 1:53 PM
To: George Warnagiris
Cc: netsa-tools-discuss at cert.org
Subject: Re: [netsa-tools-discuss] Eavesdropping and collecting Netflow v9

George,

YAF isn’t going to really help you in this situation – YAF isn’t particularly knowledgeable/interested in a flow that contains flow data other than to catalog that as a regular flow.  (Hopefully you can currently see the flows in your current SiLK repository as boring UDP flows.)  Your SiLK configuration looks reasonable to me, BUT (you knew it was coming) you would need to put the network adapter on the SiLK machine into promiscuous mode.  

Network adapters filter incoming packets in hardware based on the MAC address, easing the burden on the driver software – because of this, its unlikely your SiLK collector would even be seeing those packets even if you have told SiLK to listen for them.  tcpdump puts the network adapter into promiscuous mode which is why using that as your test you would have seen the packets.  :)

You will likely have to create a virtual network interface on the machine with that network address as well so that the packet makes it through the IP stack and reaches SiLK as well.

Of course, anyone else is welcome to look over the SiLK configuration - I didn’t verify it.  ;)

best regards,
--
Chris Inacio
inacio at cert.org



> On Dec 1, 2015, at 12:40 PM, George Warnagiris <George.Warnagiris at II-VI.com> wrote:
> 
> Thanks for the great work you do.  The CERT tools are a public service and I commend you for them.
> 
> I have a YaF sensor (and SiLK v3.10.2 collector on a Redhat OS) connected to a SPAN port on a network boundary.  Using tcpdump, I can see several devices sending Netflow v9 records across this boundary to a collector, 192.168.1.1, on UDP port 5999.  With the permission of the owner, I am trying to listen to these messages and pack the (3rd party) records into the repository.
> 
> I tried:
> 
> probe S1 netflow-v9
>    listen-as-host 192.168.1.1
>    listen-on-port 5999
>    protocol udp
> end probe
> sensor S1
>    netflow-v9-probes S1
>    internal-ipblock @intip
> end sensor
> 
> , but that didn't work.  I also tried to set the IP address of the YaF 
> sensor's listening interface to 192.168.1.1 and its MAC address to the 
> one observed with tcpdump.  This did not accomplish the result either.  
> Besides the probe creation message, rwflowpack debug only provides,
> 
> 'S1': forward 0, reverse 0, ignored 0, nf9: missing-pkts 0
> 
> I thought I might have to wait to see a netflow v9 template before collection would start, but it has been running for several hours without results.  Perhaps I have a misunderstanding about how the Redhat TCP/IP stack works.  I suspected a VLAN problem, but have since discounted that theory.
> 
> Can you give me advice on how to setup netflow collection in this situation?  How does rwflowpack behave under these circumstances?  I would appreciate any tips on where to look for more ideas or details.  Or if you could put me out of my misery by telling me it won't work, that would be good too.  I can't stop thinking about how to approach this one!
> 
> Warm Regards,
> George
> 
> The information contained in this transmission is intended only for 
> the person or entity to which it is addressed and may contain II-VI 
> Proprietary and/or II-VI Business Sensitive material. If you are not 
> the intended recipient, please contact the sender immediately and 
> destroy the material in its entirety, whether electronic or hard copy. 
> You are notified that any review, retransmission, copying, disclosure, 
> dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.
> 


The information contained in this transmission is intended only for the person or entity
to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive
material. If you are not the intended recipient, please contact the sender immediately
and destroy the material in its entirety, whether electronic or hard copy. You are
notified that any review, retransmission, copying, disclosure, dissemination or other
use of, or taking of any action in reliance upon this information by persons or entities 
other than the intended recipient is prohibited.