[netsa-tools-discuss] ASA denied events

[Mark Thomas]

John-

On Wed, 1 Jul 2015 11:23:17 +0000, John Green wrote:

> Hi,

Hello.  It is always good to hear from you.

Short answer: Your analysis is correct and the attached patch, based
on your fix (Thanks!), addresses the issue.

Long answer:

> I've been trying to collect V9 from an ASA and have been getting
> large numbers of "IGNORED - no forward/reverse octets" entries

> The majority of these were denied packets.
...
> if ((skpcProbeGetQuirks(probe) & SKPC_QUIRK_FW_EVENT)
>    && 0 == pkts
>    && SKIPFIX_FW_EVENT_DENIED == fixrec.NF_F_FW_EVENT)
>
> This wasn't happening because looking in fixrec
> firewallEvent = 3 '\003', NF_F_FW_EVENT = 0 '\000', NF_F_FW_EXT_EVENT = 1002
>
> Looking in the templates being exported from the ASA I have
> firewallEvent (233) and FW_EXT_EVENT (33002).    I can't see any
> reference to NF_F_FW_EVENT (40005).   A comment in skipfix.c refers to
> two Cisco documents, both of which also make no reference to 40005
> (only 233).

I guess it is good news that Cisco is now using a standard IPFIX
information element (IE 233) instead of a custom value (IE 40005) to
export those events.

Unfortunately, the code above was only checking the custom value
instead of checking either value, which caused SiLK not to recognize
the flow records as "denied" events.

> I've changed the above code to mirror some logic used previously
> in the function.

Thank you for the change.  I have created a patch file based on this
code.

> This appears to work, but I wanted to check I wasn't missing
> something.

No, you are not missing anything.

> In particular if libfixbuf should be involved somehow
> (http://tools.netsa.cert.org/fixbuf/libfixbuf/v9.html makes
> references to converting these elements)

The issue was entirely a problem in SiLK.

Details for the curious:

  IPFIX information elements are 16 bits and use the lower 15 bits
  for the element ID.  The high bit denotes whether the value is a
  standard element (bit is 0) or a vendor element (bit is 1).
  Vendor elements must include the vendor's enterprise number in the
  field specifier.
  http://tools.ietf.org/html/rfc7011#section-3.2

  Since libfixbuf process NetFlow v9 by modifying it to appear as
  IPFIX, libfixbuf maps elements having an element ID greater than
  32767 to other element IDs.  A more robust solution but one that is
  more difficult to implement would have had libfixbuf inserting the
  Cisco enterprise number into the field specifier.

> Thanks
> John

Thank you again.

-Mark


-------------- next part --------------
A non-text attachment was scrubbed...
Name: skipfix.c.patch
Type: text/x-patch
Size: 645 bytes
Desc: not available
URL: <http://lists.sei.cmu.edu/pipermail/netsa-tools-discuss/attachments/20150701/401978c5/attachment.bin>