MAC filter Bridge

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

MAC filter Bridge

Badbanchi Hossein
Hi,
I am trying to implement a MAC filter, based on OpenBSD Bridging facilities.

One can read in BRCONFIG(8) man page:
     rule [rulespec]
             Add a filtering rule to an interface.  Rules have a similar syn-
             tax to those in pf.conf(5).  Rules can be used to selectively
             block or pass frames based on Ethernet MAC addresses.  They can
             also tag packets for pf(4) to filter on.  Rules are processed in
             the order in which they were added to the interface, and the
             first rule matched takes the action (block or pass) and, if giv-
             en, the tag of the rule.  If no source or destination address is
             specified, the rule will match all frames (good for creating a
             catchall policy).

What is bothering me is the sentence:
Rules are processed in the order in which they were added to the interface,
and the first rule matched takes the action ...

Does this really mean that no hash function is used? I mean if I have 20000
MAC Addresses and want to check **each packet** against this list serially,
I suppose I had better forget about it!

Thanks for any ideas and/or experiences to share.

Regards,
Amir

Reply | Threaded
Open this post in threaded view
|

Re: MAC filter Bridge

Spruell, Darren-Perot
From: [hidden email]

> What is bothering me is the sentence:
> Rules are processed in the order in which they were added to
> the interface,
> and the first rule matched takes the action ...
>
> Does this really mean that no hash function is used? I mean
> if I have 20000
> MAC Addresses and want to check **each packet** against this
> list serially,
> I suppose I had better forget about it!

Don't you already have problems if you have 20,000 nodes communicating on
one flat broadcast domain already?

DS

Reply | Threaded
Open this post in threaded view
|

Re: MAC filter Bridge

Camiel Dobbelaar
In reply to this post by Badbanchi Hossein
On Wed, 1 Feb 2006, Badbanchi Hossein wrote:
> What is bothering me is the sentence:
> Rules are processed in the order in which they were added to the interface,
> and the first rule matched takes the action ...
>
> Does this really mean that no hash function is used? I mean if I have 20000
> MAC Addresses and want to check **each packet** against this list serially,
> I suppose I had better forget about it!

Yes, that's correct.  The bridge MAC address rules are implemented using a
SIMPLEQ (list).

The bridge routecache is hash based though.  An alternative approach might
be to turn off learning and discovery on the interface and add MAC
addresses that are allowed to communicate statically.  That way the bridge
never sends traffic to unknown addresses.  (the incoming traffic is
still processed though, so the approach is a bit limited).

Reply | Threaded
Open this post in threaded view
|

Re: MAC filter Bridge

Badbanchi Hossein
In reply to this post by Badbanchi Hossein
Hi,
>> An alternative approach might be to turn off learning and discovery on the
>> interface and add MAC addresses that are allowed to communicate statically.
As a matter of fact I can add MACs supposed to be reached from each interface
of the bridge, at the same time I update Bridge Rules. But this wouldn't be a (source-)MAC based filter any more!

I intend to switch the traffic originating from "unknown" MACs to a "quarantine"
subnet, connected to a third interface member of the bridge.

I---------I        I------------I          I------------------I
I   LAN   I--------I   Bridge   I----------I Protected subnet I
I---------I        I------------I          I------------------I
                          I
                          I
                          I
                   I------------I
                   I quarantine I
                   I   subnet   I
                   I------------I

I don't think your proposal would help.

I suppose I have to have a look at other Bridge implementations!

Regards,
Amir

Reply | Threaded
Open this post in threaded view
|

Re: MAC filter Bridge

Badbanchi Hossein
In reply to this post by Badbanchi Hossein
>> Don't you already have problems if you have 20,000 nodes communicating on
>> one flat broadcast domain already?

OK. I was exaggerating! I have a little more than 2100 MACs.

But even with this number, a sequential search doesn't seem to be acceptable.

Regards,
Amir

Reply | Threaded
Open this post in threaded view
|

Re: MAC filter Bridge

Tobias Weingartner-2
In reply to this post by Badbanchi Hossein
On Wednesday, February 1, "Badbanchi Hossein" wrote:
>
> Does this really mean that no hash function is used? I mean if I have 20000
> MAC Addresses and want to check **each packet** against this list serially,
> I suppose I had better forget about it!

The immediate question that rises to the surface is... WHY?

--Toby.

Reply | Threaded
Open this post in threaded view
|

Re: MAC filter Bridge

Tobias Weingartner-2
In reply to this post by Badbanchi Hossein
On Wednesday, February 1, "Badbanchi Hossein" wrote:
>
> I intend to switch the traffic originating from "unknown" MACs to a "quaranti
> ne"
> subnet, connected to a third interface member of the bridge.

Basing security policies on something as easily changable as a MAC
address (and as public as a MAC address) is stupid.  Rethink your
approach.

--Toby.

Reply | Threaded
Open this post in threaded view
|

Re: MAC filter Bridge

Badbanchi Hossein
In reply to this post by Badbanchi Hossein
> Basing security policies on something as easily changable as a MAC
> address (and as public as a MAC address) is stupid.
Thanks for the complement.

Although this might seem (or actually BE) stupid in environments publicly accessible,
but for a closed environment like our company LAN, this is good enough.
Here I don't want to protect the LAN against the extreme hacker, but against
our legitimate guests who come to visit someone or take part in some meeting,
and simply open their laptop and connect the NIC to the nearest free LAN socket.
This could be because they want to download the latest PowerPoint file for their
presentation!

Our policy is to provide Internet Access to our guests (of course while logging
every activity), but we need to first distinguish them in order to provide them
with at least an initial AUP (Acceptable User Policy), or even scan the machine
for vulnerabilities and the like.

> Rethink your approach.
Other approaches like 802.1x is also known to me. But our need is more modest.

Regards,
Amir

Reply | Threaded
Open this post in threaded view
|

Re: MAC filter Bridge

Lars Hansson
In reply to this post by Badbanchi Hossein
On Wed, 1 Feb 2006 16:25:44 +0100
"Badbanchi Hossein" <[hidden email]> wrote:

> Does this really mean that no hash function is used? I mean if I have 20000
> MAC Addresses and want to check **each packet** against this list serially,
> I suppose I had better forget about it!

If you have 20000 mac addresses in one broadcast domain
you have more serious and fundamental problems than pf.

---
Lars Hansson

Reply | Threaded
Open this post in threaded view
|

Re: MAC filter Bridge

Tobias Weingartner-2
In reply to this post by Badbanchi Hossein
On Wednesday, February 1, "Badbanchi Hossein" wrote:
> > Basing security policies on something as easily changable as a MAC
> > address (and as public as a MAC address) is stupid.
>
> Thanks for the complement.

You're welcome.  Honestly though, what would you call it?

> Although this might seem (or actually BE) stupid in environments
> publicly accessible, but for a closed environment like our company
> LAN, this is good enough.  Here I don't want to protect the LAN
> against the extreme hacker, but against our legitimate guests who come
> to visit someone or take part in some meeting, and simply open their
> laptop and connect the NIC to the nearest free LAN socket.  This
> could be because they want to download the latest PowerPoint file for
> their presentation!
>
> Our policy is to provide Internet Access to our guests (of course
> while logging every activity), but we need to first distinguish them
> in order to provide them with at least an initial AUP (Acceptable
> User Policy), or even scan the machine for vulnerabilities and the
> like.

And who's to say they actually read the AUP?  Personally I'd do it
slightly different.

1) Mac-lock the switch ports of the machines that are supposed to be
connected permanently.  (Yes, not perfect, but what can you do...)

2) vlan the ports that are plug-and-play to their own vlan

3) Use authpf to authenticate them, at least then you can ply them
with your AUP before they accept (type a password).  It will be a
lot less implied, but an active action taken on their part.


> > Rethink your approach.
>
> Other approaches like 802.1x is also known to me. But our need is more
> modest .

Have a look at authpf.  It's not the end-all be-all, but it does solve a
lot of problems in a very elegant fashion.

--Toby.

Reply | Threaded
Open this post in threaded view
|

Re: MAC filter Bridge

Badbanchi Hossein
In reply to this post by Badbanchi Hossein
Thanks for the clue. I will sure have a closer look at authpf.

By the way I am also having a look at:
http://acs-wiki.andrew.cmu.edu/twiki/bin/view/NGCoverage/AuthBridge and
http://netpass.sourceforge.net/ (http://wings.buffalo.edu/computing/Documentation/gen/UBNetPass.html)

Even commercial products like CounterAct from ForeScout and the like.

Amir



-----Original Message-----
From: Tobias Weingartner [mailto:[hidden email]]
Sent: Thursday, February 02, 2006 20:40
To: Badbanchi Hossein
Cc: [hidden email]
Subject: Re: MAC filter Bridge

On Wednesday, February 1, "Badbanchi Hossein" wrote:
> > Basing security policies on something as easily changable as a MAC
> > address (and as public as a MAC address) is stupid.
>
> Thanks for the complement.

You're welcome.  Honestly though, what would you call it?

> Although this might seem (or actually BE) stupid in environments
> publicly accessible, but for a closed environment like our company
> LAN, this is good enough.  Here I don't want to protect the LAN
> against the extreme hacker, but against our legitimate guests who come
> to visit someone or take part in some meeting, and simply open their
> laptop and connect the NIC to the nearest free LAN socket.  This
> could be because they want to download the latest PowerPoint file for
> their presentation!
>
> Our policy is to provide Internet Access to our guests (of course
> while logging every activity), but we need to first distinguish them
> in order to provide them with at least an initial AUP (Acceptable
> User Policy), or even scan the machine for vulnerabilities and the
> like.

And who's to say they actually read the AUP?  Personally I'd do it
slightly different.

1) Mac-lock the switch ports of the machines that are supposed to be
connected permanently.  (Yes, not perfect, but what can you do...)

2) vlan the ports that are plug-and-play to their own vlan

3) Use authpf to authenticate them, at least then you can ply them
with your AUP before they accept (type a password).  It will be a
lot less implied, but an active action taken on their part.


> > Rethink your approach.
>
> Other approaches like 802.1x is also known to me. But our need is more
> modest .

Have a look at authpf.  It's not the end-all be-all, but it does solve a
lot of problems in a very elegant fashion.

--Toby.