BPF packet filter syntax

Before I go dive into source I thought I'd throw a quick question to the group.

Can you use the entire BPF syntax (things other than just "host") when building a Bro filter?

For example, I've got something like this in my local.bro:

redef PacketFilter::all_packets = F;
redef capture_filters = [[ "all"] = "ip or not ip"];
redef restrict_filters += [ ["not-one-host"] = "not host 10.10.1.1"];
redef restrict_filters += [ ["not-two-hosts"] = "not host 10.20.1.1 and not host 10.30.1.1"];
redef restrict_filters += [ ["not-one-net"] = "not net 10.40.1.192/26"];
redef restrict_filters += [ ["not-two-nets"] = "not net 10.50.1.0/20 and not net 10.60.1.0/22"];

But it seems that the "10.50.1.0/20" network is still leaking in traffic?

Ultimately I'd like to eliminate the traffic at my upstream device, but in the mean time, does anyone see something I'm doing obviously wrong?

Thanks,
Corey

redef restrict_filters += [ ["not-two-nets"] = "not net 10.50.1.0/20 and not net 10.60.1.0/22"];

I'm surprised that Bro is starting up for you. When I try running with these lines I get a message about a bad filter. The line that I left above doesn't work as a valid BPF filter, there are network bits beyond the netmask which BPF doesn't seem to like.

I think the CIDRs you meant to use are:
  10.50.0.0/20
  10.60.0.0/11

So use this instead:
  redef restrict_filters += { ["not-two-nets"] = "not net 10.50.0.0/20 and not net 10.60.0.0/22" };

Ultimately I'd like to eliminate the traffic at my upstream device, but in the mean time, does anyone see something I'm doing obviously wrong?

Once again, I'd like to apologize to everyone for not getting the rewritten packet filter framework into 2.1. This will be so much easier when that's finally included (the worst part is that it's already done!).

  .Seth

Actually, I fudged the addresses in an attempt to simplify the question, but I neglected to check the cidr boundaries, so I guess it didn't make it simpler after all. :slight_smile:

More specifically, the actual line in question is:

redef restrict_filters += [ ["not-flux"] = "not net 155.98.32.0/20 and not net 155.98.60.0/22"];

And I'm getting the notice:

SSH::Password_Guessing Threshold crossed by metric_index(host=137.132.209.209) 30/30

from "137.132.209.209" pounding on the IP "155.98.35.7".

So I was thinking the filter should have dropped the traffic before the SSH connection got process or ever reached the detect-bruteforcing.bro script and not incremented the counter or kicked off the notice.

Thanks for answering my question in the general that I should be able to use "net" as well as "host", but can you see any reason that should not be working?

- Corey

Actually, I fudged the addresses in an attempt to simplify the question, but I neglected to check the cidr boundaries, so I guess it didn't make it simpler after all. :slight_smile:

Hah! No problem.

redef restrict_filters += [ ["not-flux"] = "not net 155.98.32.0/20 and not net 155.98.60.0/22"];

One funny thing is that I was *really* surprised that this syntax works. Normally I would surround the table values with curly braces like this…

redef restrict_filters += { ["not-flux"] = "not net 155.98.32.0/20 and not net 155.98.60.0/22" };

At some point we're really going to have to tighten up the language's use of curly braces and square brackets, there is still a lot of inconsistency floating around.

SSH::Password_Guessing Threshold crossed by metric_index(host=137.132.209.209) 30/30

from "137.132.209.209" pounding on the IP "155.98.35.7".

Are you seeing that address (155.98.35.7) in your conn.log? I assume you are, but the metric based detection doesn't inherently indicate that.

So I was thinking the filter should have dropped the traffic before the SSH connection got process or ever reached the detect-bruteforcing.bro script and not incremented the counter or kicked off the notice.

Yeah, I would think so too.

Could you send me the output from the packet_filter.log? Feel free to send it off list if it has anything in it that you'd rather not broadcast publicly.

Thanks,
  .Seth

Ha! That'll teach me to copy-and-paste from the list without paying attention to syntax...

I fixed the square-brackets to curly-brackets, but it did not see to fix the problem. I'll dig around and send you some logs offline as soon as I get a chance.

Thanks!

Hey Gang,

I still don't have this working properly, but I think I'm making progress and I've got it down to a repeatable test.

For testing I installed the latest pfring SVN and Bro v2.1-rc3 on an Ubuntu Server 12.04.1 VMware Fusion VM.

The only change I made to the plain-vanilla install is to add the following lines to the bottom of the local.bro:

redef PacketFilter::all_packets = F;
redef capture_filters = { ["all"] = "ip or not ip" };
redef restrict_filters += { ["not-one-host"] = "not host 10.10.10.1" };
redef restrict_filters += { ["not-one-net"] = "not net 10.10.20.0/24" };

I start it up, and the filter shows up properly in the packet_filter.log

I then change the node.cfg from stand-alone mode to a single box cluster (manager, proxy and worker all on the same box) and start it up again and nothing shows up in the packet_filter.log.

So, it appears to possibly be a stand-alone vs cluster issue.

Has any successfully applied a packet filter to a clustered environment? Did you have to make any other tweaks to get it to work?

- Corey

You can run broctl print capture_filters or broctl print
restrict_filters to see which filters are being loaded by the cluster.
I never thought to check my packet_filter* log files, but looked and
they are empty even though the filters are running.

Tyler

Nice! Thanks Tyler. Looks like they are there. I wonder why they don't get logged.

If I'm reading the packet-filter framework right, they see to get logged to indicate they were applied correctly. I'll have to do some functionality testing to make sure they are getting applied as well as being held in the variables, but if they are working without logging that is good enough for me at the moment.

- Corey

After thinking about this for a couple of days, I'm starting to wonder if there is some problem with when this log write is happening. It's possible that the remote communication has not yet begun by the time the filter is being applied so the remote logging isn't happening right.

I'll try and carve out some time soon to look into it more closely though since it sounds like you were saying that the filter wasn't being applied at all since you were seeing traffic in your conn.log that you wouldn't expect to see.

  .Seth