[netsa-tools-discuss] ASA denied events

[Mark Thomas]

On Wed, 8 Jul 2015 09:52:09 +0000, John Green wrote:

> On Wed, 2015-07-01 at 11:22 -0400, Mark Thomas wrote:
>> 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.
>
> Hi Mark,
>
> Thanks for looking into this and supplying a patch.
>
> The majority of the remaining flows logged as IGNORED by flowcap
> appear to be SKIPFIX_FW_EVENT_DELETED where bytes and rev-bytes ==
> 0.  These appear to be unsuccessful connections (eg SYN to closed
> port - so no payload bytes).

Ugh!  Why are these DELETED events and not DENIED events?

I suppose I understand the distinction between "blocked by an
explicit rule" and "this would be allowed but nothing was
listening".

And the incoming packet has some octet count, does it not?  If you
are giving me a deleted event, why does the volume of the incoming
packet not count?

> Can these simple be stored as 0 (payload) byte flows?

Here are my thoughts on a Friday afternoon:

* In the early days when storage was at a premium, SiLK did all the
  bit shaving it could.  To this end, some SiLK Flow file formats
  store packets and a bytes-per-packet ratio.  This is why we always
  set the packets count to 1.  In addition, when the zero-packets
  quirk is enabled, SiLK uses formats that do not store this ratio,
  since the ratio may overflow if the byte count is correct and the
  packet count is 1.

* I think SiLK may contain code where we assume the byte count is
  always greater than the packet count, since that must be true of
  actual data.  I know that one of the checks that rwpackchecker
  does to check for invalid files is to look for a byte count
  smaller than the packet count.

* SiLK tries to do consistency checking of the incoming data to
  ensure that it is not complete garbage.  With data from the Cisco
  ASA, nearly all of these checks are violated.

* Several tools assume the byte count of valid records is non-zero.
  For example, if you were to create a Bag file and use the byte
  count as the value, these zero-byte flow records would not be
  included in the total.  Perhaps that is what one wants, but it
  also seems to be an invitation for confusion.

In short, I do not know what the side effects of that change would
be.  I would want to spend time verifying that there are no adverse
effects if we were to make that change.

-Mark