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

Rachel Kartch rakartch at cert.org
Tue Dec 1 16:04:14 EST 2015


Hi George!

At the risk of asking a silly question, what is the purpose of the SPAN port in this case? It sounds like you've been given permission to spoof the IP and MAC address of the 192.168.1.1 collector, so why not use a regular access port? Is it because the other 192.168.1.1 also has to stay on the network at the same time?

Not really sure there's much way around trying to make 192.168.1.1 and its associated MAC live in two places on the same switch. As you've already found, SPAN will let you see all the traffic, but won't let you "be" 192.168.1.1 for purposes of being the collector.

There may be games you can play with the "ingress" keyword on your SPAN port to allow the end device to act both as a monitoring device and as a host with IP address 192.168.1.1, but as long as the other 192.168.1.1 with the same MAC is in play, that's still going to be problematic.



Rachel A. Kartch
Software Engineering Institute | CERT
4500 Fifth Avenue
Pittsburgh, PA 15213
412.268.3998
rakartch at cert.org
 
http://www.cert.org/








On 12/1/15, 3:12 PM, "netsa-tools-discuss-bounces+rakartch=cert.org at cert.org on behalf of George Warnagiris" <netsa-tools-discuss-bounces+rakartch=cert.org at cert.org on behalf of George.Warnagiris at II-VI.com> wrote:

>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.


More information about the netsa-tools-discuss mailing list