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.
Re: MAC filter Bridge
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:[EMAIL PROTECTED] Sent: Thursday, February 02, 2006 20:40 To: Badbanchi Hossein Cc: misc@openbsd.org 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.
MAC filter Bridge
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 2 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
Re: MAC filter Bridge
From: [EMAIL PROTECTED] 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 2 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
Re: MAC filter Bridge
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 2 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).
Re: MAC filter Bridge
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-III I--I I LAN II Bridge I--I Protected subnet I I-III I--I I I I II I quarantine I I subnet I II I don't think your proposal would help. I suppose I have to have a look at other Bridge implementations! Regards, Amir
Re: MAC filter Bridge
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
Re: MAC filter Bridge
On Wednesday, February 1, Badbanchi Hossein wrote: Does this really mean that no hash function is used? I mean if I have 2 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.
Re: MAC filter Bridge
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.
Re: MAC filter Bridge
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
Re: MAC filter Bridge
On Wed, 1 Feb 2006 16:25:44 +0100 Badbanchi Hossein [EMAIL PROTECTED] wrote: Does this really mean that no hash function is used? I mean if I have 2 MAC Addresses and want to check **each packet** against this list serially, I suppose I had better forget about it! If you have 2 mac addresses in one broadcast domain you have more serious and fundamental problems than pf. --- Lars Hansson
