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

[Rachel Kartch]

Ahh, ok. So, can a SPAN port toss everything to a host, and have that host actually process traffic normally if the traffic has its NIC's IP and MAC in it. Hmm. I'd never even considered trying it but that would be kind of cool if it could work.

When you're trying to get the records and not seeing them, is the sensor interface in promiscuous mode or normal?

With the 192.168.1.1 IP and MAC configured on the box's interface, and an IP in the same subnet configured on your laptop, can you directly connect your laptop to the sensor and ping it? Connect to it via ssh? Just to confirm that under less weird networking circumstances, everything is functioning as expected?


Rachel


> On Dec 1, 2015, at 5:14 PM, George Warnagiris <George.Warnagiris at II-VI.com> wrote:
> 
> Good question.  192.168.1.1 is Operations' flow collector and they do silly things like aggregate flows by port and protocol.  It only keeps the data around for a short while.  Its job is measuring bandwidth and not improving security.  So yes, it is because the other needs to stay on the network.
> 
> I don't understand.  We're not trying to advertise the IP and/or the MAC.  We are not injecting it into traffic or responding to ARP queries with it.  We are just telling the local, server interface to send packets with those addresses up the stack, and for rwflowpack to process them.  The packets are arriving on the switchport/NIC, due to mirroring, regardless of the hardware and IP addrs.  No switches were harmed in the making of this flow...
> 
> Thanks to you and to everyone giving this a mulling over.  I was trying to think of who I could possibly ask about such an arcane topic.  You were the first to come to mind...
> 
> George
> 
> -----Original Message-----
> From: Rachel Kartch [mailto:rakartch at cert.org] 
> Sent: Tuesday, December 01, 2015 4:04 PM
> To: George Warnagiris; Chris Inacio
> Cc: netsa-tools-discuss at cert.org
> Subject: Re: [netsa-tools-discuss] Eavesdropping and collecting Netflow v9
> 
> 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.
> 
> 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.