Filtering PacketFilter::Dropped_Packets

Zeek
1

I've got this: Log::disable_stream(PacketFilter::LOG);

But I'm still getting a ton of "PacketFilter::Dropped_Packets" to notice.log.

What do I need to do to disable these messages?

2

Notice processing docs:
  http://www.bro-ids.org/documentation/notice.html

You can use the notice ignore shortcut because you want to completely ignore a notice type:
  http://www.bro-ids.org/documentation/notice.html#id7

redef Notice::ignored_types += { PacketFilter::Dropped_Packets };

  .Seth

3

But I'm still getting a ton of "PacketFilter::Dropped_Packets" to notice.log.
What do I need to do to disable these messages?

Notice processing docs:
http://www.bro-ids.org/documentation/notice.html

You can use the notice ignore shortcut because you want to completely ignore a notice type:
http://www.bro-ids.org/documentation/notice.html#id7

redef Notice::ignored_types += { PacketFilter::Dropped_Packets };

That didn't appear to completely work for me as the default action
still seemed to be applied.

I changed it to this:
redef Notice::policy += { [$pred(n: Notice::Info) = {return n$note ==
PacketFilter::Dropped_Packets; }, $action = Notice::ACTION_NONE, $halt
= T] };

Before adding '$halt=T', the action in the log listed both ACTION_NONE
and ACTION_LOG.

-will

4

Looks like Will's method is working. Thanks much!

5

That are going through the notice framework and can be suppressed
there with something like this:

    redef Notice::ignored_types += {
        PacketFilter::Dropped_Packets
    };

Robin

6

That sounds like a bug then. Can you file a ticket please?

Robin

7

Sure thing.

-will

8

Thanks, it definitely sounds like a bug.

  .Seth

9

Everything implemented internally should make this work. There is one thing I'm wondering though. In any of your scripts you're running locally, are you doing…

redef Notice::policy = { … };

Instead of…

redef Notice::policy += { … };

It's a small difference, but causes a big change because those shortcuts (like ignored_types) are basically just pre-implemented notice policy items which you are blowing away if you do full set assignment instead of adding items to the set. I'll start trying to think of way to make that more resilient to this too. This fragility is the one thing I don't like about those pre-implemented policy items.

  .Seth

10

Nope, not doing that.

11

Looks like Will's method is working. Thanks much!

Everything implemented internally should make this work. There is one thing I'm wondering though. In any of your scripts you're running locally, are you doing…

redef Notice::policy = { … };

Instead of…

redef Notice::policy += { … };

Yes, all my are just like the example above, "+=", so I assume I was
just appending another action to the table.

Maybe not a bug then?

If I do a full re-assignment "=" instead, I wouldn't have multiple
actions assigned to the notice?