[netsa-tools-discuss] Cisco AireOS netflow support

Mark Thomas mthomas at cert.org
Wed Sep 20 14:40:52 EDT 2017


Alex-

I am sorry to hear that the change did not allow SiLK to capture the
flow records.

Additional things to try:

* Look at the NetFlow data with Wireshark and ensure the
  staIPv4Address field has a valid address.

* Set the SILK_IPFIX_PRINT_TEMPLATES environment variable prior to
  running rwflowpack.  That will cause rwflowpack to write the
  templates it received in the log file.  That may help you debug
  the issue.

* Enable the tracing code in silk/src/libflowsource/skipfix.c by
  defining the SKIPFIX_TRACE_LEVEL macro on line 22 and recompiling
  the code.  That enables additional log messages when you run
  rwflowpack with the --log-level=debug switch.

As for SiLK 4.0, I have attached two files.

The first is a patch to SiLK 4.0 that fixes an issue when printing a
field that is stored as binary data (such as a MAC address).  Apply
from the top of the SiLK 4.0 distribution by running

  patch -p1 < /tmp/silk4-binary-fields.patch

The second is a configuration file for rwflowpack.  Use this file as
the only argument to rwflowpack.  For example:

  rwflowpack /var/rwflowpack/rwflowpack.lua

This configuration file:

* Uses the current time as the record's timestamp.

* Copies the staIPv4Address field from the incoming data into the
  SiLK's sIP field.

* Copies the applicationTag into SiLK's application field if
  possible.

* Adds five "sidecar" fields to the output files:
  -- ipDiffServCodePoint
  -- postIpDiffServCodePoint
  -- staMacAddress
  -- wtpMacAddress
  -- wlanSSID

You may use the rwfileinfo command to confirm that these fields are
being added to the files created by rwflowpack.

The sidecar fields may be used as normal parameters to the --fields
switch of rwcut, rwuniq, rwsort, and rwstats.  To use them as part
of rwfilter, use the --lua-expression and --lua-file switches.

Good luck.

-Mark


-----Original Message-----
From: Alex Hautequest <hquest at hquest.pro.br>
Date: Thu, 14 Sep 2017 21:24:51 -0400
To: <netsa-tools-discuss at cert.org>
Subject: Re: [netsa-tools-discuss] Cisco AireOS netflow support

Mark,

Thanks for the hint. Still did not work - I have the same output as before and no flows recorded.

I might try SiLK 4.0 as soon as I have a chance to review the documentation, in particular what changes on the configuration side.

Regards,

Alex

-----Original Message-----
From: Mark Thomas
Sent: Thursday, September 14, 2017 6:09 PM
To: Alex Hautequest
Cc: netsa-tools-discuss 
Subject: Re: [netsa-tools-discuss] Cisco AireOS netflow support

Alex-

I apologize.  I forgot that the IPFIX element IDs are used in one place, and there is one more change I should have told you to make.

On line 1315 of skipfix.c, change "case   8" (the numeric ID for
sourceIPv4Address) to "case 366".  The diff of that block of code (based on clean SiLK sources) is:

======================
@@ -1312,10 +1312,10 @@
             if (ie->ent == 0) {
                 /* STANDARD ELEMENT */
                 switch (ie->num) {
-                  case   8:
+                  case 366:
                   case  12:
-                    /* sourceIPv4Address and/or destinationIPv4Address */
-                    bmap |= TMPL_BIT_sourceIPv4Address;
+                    /* staIPv4Address and/or destinationIPv4Address */
+                    bmap |= TMPL_BIT_staIPv4Address;
                     break;
                   case  27:
                   case  28:
=======================

I have attached a patch file that should make all the necessary changes to a clean version of SiLK 3.16.0.  To apply the patch, go into the top directory of a clean SiLK distribution and run

  patch -p1 < /tmp/silk-3.16.0-AireOS.patch


Another option would be to experiment with SiLK 4.0, which provides support for additional IPFIX elements (called "sidecar fields") in addition to the traditional SiLK fields.  I can look at this next week to provide you with an example configuration file for rwflowpack.

Good luck!

-Mark


-----Original Message-----
From: Alex Hautequest
Date: Thu, 14 Sep 2017 13:17:34 -0400
To: netsa-tools-discuss
Subject: Re: [netsa-tools-discuss] Cisco AireOS netflow support

Hello Mark.

I did replaced all instances as per your suggestion, but it did not worked - still have the flows listed as ignored:

Sep 14 11:13:24 darkstar rwflowpack[23631]:
IGNORED|0.0.0.0|0.0.0.0|0|0|0|356|35726|No IP addresses| Sep 14
11:13:24 darkstar rwflowpack[23631]:
IGNORED|0.0.0.0|0.0.0.0|0|0|0|500|496939|No IP addresses| Sep 14
11:13:24 darkstar rwflowpack[23631]:
IGNORED|0.0.0.0|0.0.0.0|0|0|0|9|1022|No IP addresses| Sep 14 11:13:24
darkstar rwflowpack[23631]: IGNORED|0.0.0.0|0.0.0.0|0|0|0|9|2692|No IP
addresses| Sep 14 11:13:24 darkstar rwflowpack[23631]:
IGNORED|0.0.0.0|0.0.0.0|0|0|0|14|4024|No IP addresses| Sep 14 11:13:24
darkstar rwflowpack[23631]: IGNORED|0.0.0.0|0.0.0.0|0|0|0|12|4443|No
IP addresses| Sep 14 11:13:24 darkstar rwflowpack[23631]:
IGNORED|0.0.0.0|0.0.0.0|0|0|0|18|1656|No IP addresses| Sep 14 11:13:24
darkstar rwflowpack[23631]: IGNORED|0.0.0.0|0.0.0.0|0|0|0|9|558|No IP
addresses| Sep 14 11:13:24 darkstar rwflowpack[23631]:
IGNORED|0.0.0.0|0.0.0.0|0|0|0|72|8082|No IP addresses| Sep 14 11:13:24
darkstar rwflowpack[23631]: IGNORED|0.0.0.0|0.0.0.0|0|0|0|72|5499|No
IP addresses| Sep 14 11:13:24 darkstar rwflowpack[23631]:
IGNORED|0.0.0.0|0.0.0.0|0|0|0|8|911|No IP addresses| Sep 14 11:13:24
darkstar rwflowpack[23631]: IGNORED|0.0.0.0|0.0.0.0|0|0|0|6|555|No IP
addresses| Sep 14 11:13:24 darkstar rwflowpack[23631]:
IGNORED|0.0.0.0|0.0.0.0|0|0|0|1|128|No IP addresses| Sep 14 11:13:24
darkstar rwflowpack[23631]: IGNORED|0.0.0.0|0.0.0.0|0|0|0|1|489|No IP
addresses| Sep 14 11:13:25 darkstar rwflowpack[23631]: router: forward
15, reverse 0, ignored 0, nf9: missing-pkts 0 Sep 14 11:13:25 darkstar
rwflowpack[23631]: 'wireless': forward 0, reverse 0, ignored 131, nf9:
missing-pkts 0 Sep 14 11:13:25 darkstar rwflowpack[23631]: 'firewall':
forward 1859, reverse 1453, ignored 5167, nf9: missing-pkts 0

Here is what I used to change the code:
root at server:/tmp/silk-3.16.0/src/libflowsource# sed
s/sourceIPv4Address/staIPv4Address/g skipfix.c.orig > skipfix.c
root at server:/tmp/ silk-3.16.0/src/libflowsource# sed
s/sourceIPv4Address/staIPv4Address/g check-struct.c.orig >
check-struct.c

Thanks and regards,

Alex
-----Original Message-----
From: Mark Thomas
Sent: Wednesday, September 13, 2017 3:23 PM
To: Alex Hautequest
Cc: netsa-tools-discuss
Subject: Re: [netsa-tools-discuss] Cisco AireOS netflow support

Alex-

Looking at the set of information elements that the Cisco AireOS
exports in its NetFlow v9 data, I think there are only three that SiLK
would use:

 * staIPv4Address    => sIP
 * packetDeltaCount  => packets
 * octetDeltaCount   => bytes

The packetDeltaCount and octetDeltaCount elements are already
supported by SiLK.  To support data from the AireOS, SiLK would need
to support using staIPv4Address as an additional location to check for
an IP address.

If you would like to experiment with this, you could globally change "sourceIPv4Address" to "staIPv4Address" in the files

 silk/src/libflowsource/skipfix.c
 silk/src/libflowsource/check-struct.c

and then recompile and reinstall SiLK.  I believe that will allow SiLK to capture those flow records.

Cheers.

-Mark


-----Original Message-----
From: Alex Hautequest
Date: Fri, 25 Aug 2017 22:34:14 -0400
To: "netsa-tools-discuss"
Subject: [netsa-tools-discuss] Cisco AireOS netflow support

Hello.

Cisco AireOS (from the Wireless Lan Controllers) have the ability to
export NetFlow v9 data off its WLANs. Unfortunately, Cisco decided to
use a few non-standard fields [1] to the protocol [2], therefore
rendering almost all but a few limited number of netflow collectors
unusable. Also unfortunate is the fact Silk is too affected by their
decision.

With that said, any chance this can be evaluated and incorporated into a newer Silk version?

Thanks and regards,

[1] https://www.cisco.com/c/en/us/products/collateral/wireless/8500-series-wireless-controllers/qa_c67-722538.html

[2]
Q.    Can AVC be used with third-party management tools?
A.  The information exported by AVC is in the standard NetFlow Version
9 format and certainly lends itself to use with third-party tools. One
example third-party tool that can create custom reports for Cisco AVC
is Plixer Scrutinizer.
Q.    What are the supported export formats?
A.  AVC currently supports the NetFlow Version 9 export format. The
following unique elements are included in the current version of the
wireless AVC NetFlow record:
 ●   applicationTag
 ●   ipDiffServCodePoint
 ●   octetDeltaCount
 ●   packetDeltaCount
 ●   postIpDiffServCodePoint
 ●   staIPv4Address
 ●   staMacAddress
 ●   wlanSSID
 ●   wtpMacAddress


-------------- next part --------------
A non-text attachment was scrubbed...
Name: silk4-binary-fields.patch
Type: application/octet-stream
Size: 1776 bytes
Desc: not available
URL: <http://lists.sei.cmu.edu/pipermail/netsa-tools-discuss/attachments/20170920/e77272cc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rwflowpack.lua
Type: application/octet-stream
Size: 4446 bytes
Desc: not available
URL: <http://lists.sei.cmu.edu/pipermail/netsa-tools-discuss/attachments/20170920/e77272cc/attachment-0001.obj>


More information about the netsa-tools-discuss mailing list