04-03-2014 10:42 AM - edited 04-03-2014 10:44 AM
no, i don't think so, aswell as some people even wasn't consider VPN usage overkill(and they're doing it in home, too ! amazing !!)
until MacSec and SecureID adoption - widespread thru global market regions, really nothing to do, cuz SEND(never-ever implemented in gear AFAIK)never been backported/tweaked to support IPv4, too, for example.
so primarily im talking bout two new things about as game-changers: 802.1ae,802.1ar, managed by 802.1af(presently known as 802.1x-2010) and worked together.
04-03-2014 10:55 AM
There is no point in suggesting technologies which are not implemented in all equipment. Until those are available we have to make do with what we have, and the problem is exactly that we don't have what even a cheap <$50 BusyBox WiFi router has.
04-03-2014 01:31 PM - edited 04-03-2014 05:17 PM
so ? no point to use WiFi ? and anyone - should stuck with ArcNet or 10Base-T ?
"until those will" will actually happens two year ago.
and we still lack of good end-user/ready products, implementing such crucial/critical features in networking gear.
basically because thos groundless/ignorant assumptions/trolling, like yours. no offense.
point is: those things are matter of life or death for L2 security of any kind of networking you're tend to use, nor services, based on them - from you web-browsing to medical and military applications.
they already lagged for about 14yrs or so(some engineers was claim "8yrs ago", but thats not particulary meaningful difference) to be deployed, widespreaded and kept being improved.
04-03-2014 02:01 PM - edited 04-03-2014 02:02 PM
One possible approach which is not quite what some people want, but which has 99% of the function for other folks, and uses the existing (2.4.6) tools:
Set the default usergroup limited to 1kbps upload and download.
Move your blessed devices (select the device, configuration, usergroup) into a different usergroup with reasonable upload and download speeds.
It's not security, but then, the argument against MAC filtering is that it's not secure, really - it is, however, effective nusiance device control.
04-03-2014 05:15 PM - edited 04-03-2014 06:23 PM
i just assumed thats dedicated IEEE crew aswell as related consurtium/alliance/SIG, with members, including famous and experienced, influental companies like intel, HP, Marvell, Broadcom/Atheros/Freescale/Qualcomm and many others, helped by leading scientists - just wasted their (precious/limited)money, time, manpower on something redundant, useless and inappropriate and some persons(or entities for whom they may speak)will better in both networking gear, engineering and investments/mangement.
using MAC-based "dubctape&glue" for decade isn't more even temporal palliative, as long as threats become imminent, dense, well-coordinated and funded even on lowest levels/league of cybercrime/cyberwarfare.
we're secure L2 NOW or Humanity - will extinct Tomorow, together with vital infrastructure, critical for prevention of this, from happening.
04-03-2014 05:20 PM - edited 04-03-2014 05:23 PM
I understand your wish for a proper solution using the features you described.
However, as far as I know Ubiquiti does not support those, at least not in EdgeMax and in UniFi hardware and software which is what I personally own and use.
So, your suggestion is then that we have nothing because neither what you want and consider the only right thing nor what I want as an additional layer is supported?
Finally, how is addition of a MAC ACL excluding the features you mention?
04-03-2014 06:15 PM - edited 04-03-2014 06:17 PM
thats the point.
to advise/surggest mission-critical features, such as those was described - be implemented ASAP.
rather than obviously/redundantly noticed untolerable/dangrous absence of such.
should i ask for something if this particular "something" - ALREADY there ? i don't think so. even drunkards shouldn't.
there is nothig like "additional layer" and other burdens/overheads like that. just bit more updated/fresh PHY or SoC(in tiniest radios) used in gear, backed by firmware adjustments/support.
there is no "how is xx exclude xyz" and never typed/wrote. its just more about common sense, just like how cowboy hat(and that Proper analogy) - become redundant when you got assault rifle, in case of trouble you're trying to solve is: self-defense(and/or defense of others).
no, ARP-based "additional layers" didn't prevent industry-designed/proved/tested standards/solutions/products being used and vice versa. just make even less sense, than before. like carrying umbrella in Antarctica.
04-04-2014 03:29 AM
If that is the case, how about you start a new thread with the proper subject (i.e. MacSec) and create a new feature request for the features you want instead of posting off-topic here?
You can count on my vote for your feature request, because I also want to see advanced security features.
As for your analogy (cowboy hat vs assault rifle) it is ridiculous and completely off the mark.
The correct analogy would be MAC ACL being a replica of a pistol and MacSec being a real pistol.
If you were holding a replica, 90% of people would just assume it is safer not to attack you, 9% would recognize it being a replica and attack if they saw value in such an act, and 1% would attack you even if you were holding a real pistol and the act had no value other than bragging rights. MAC ACL is not about stopping that 1%, or even about stopping those 9% -- it is about stopping those 90%.
Finally, there is this thing called "time to market" -- if MacSec requires updated hardware then it is not going to happen soon, especially not without investment on cosumer side. I just bought UniFi AP and I am not going to buy another just to get MacSec -- I don't plan to replace it for at least 2 years. On the other hand MAC ACL does not require much effort to implement and can be supported on existing hardware until we get some better solution and upgrade to it.
04-04-2014 06:28 AM
MAC Whitelist ACL is similar to having a fence around your property. Most people will not climb over the fence. A few might try to. Since there's an obvious boundary, it is trespassing for an unauthorized individual to climb over the fence.
Although I've never personally seen it happen, I suspect that a cloned MAC address would create network problems between two devices with the same MAC address if they existed on the same layer-2 network at the same time. This trouble and the resulting complaints may help detect the presence of such a scenario.
04-06-2014 08:29 AM
Per UBNT-MikeD, let's head over to the official feature request thread and give kudos/+1/comments over there:
Ubiquiti Networks Community > UniFi > UniFi Feature Requests / Suggestions > Per SSID MAC Filtering
04-06-2014 10:06 AM - edited 04-06-2014 10:11 AM
yeah, like any kind of mecanical door locks - provide only ethical barriers against honest, non-criminal neighboorhood, whose pose no threat anyway even in absence of such, but had Zero efficiency/security against experienced/trained criminals.
thats how MAC/ARP-based measures appear, compared to real-life approaches to same problems.
so you had to use something really well-made, sane, with relatively relative to usage, performance/caps, or simply not waste time on pointless offorts otherwise, focusing on enteriely another sides of problem(like physically eliminating any entities,attempt to penetrate/snoop/approach, for example, w/o hesitation/delay nor safe threeshold. nor bringing "another layer" of custom-made/standards-compliant consistent "end to end" solution, like VPN, for example).
04-07-2014 06:55 PM
MAC ACL is stupidly simple and cheap to implement (hostapd and wpad both support it AFAIK), so please stop advocating against it here and start a new thread to ask for the features you want.
04-23-2014 04:53 AM
The focus on security misses the use of MAC White listing and is frustrating for those of us
who need mac filtering. Many posters seem to assume that because they do not need it that others are in
the same boat. There are numerous uses for mac filtering and Ubiquiti is losing customers because
it does not have this most basic function.
It might be better not to post if you cannot see the value filtering in your particular case or think it is simply
a matter of security.
04-24-2014 08:54 AM
Please explain why you think you need MAC filtering, as opposed to other access control solutions which are better in all ways. It's an anti-feature, having it there makes people who don't know better think it's actually worth using.
04-24-2014 09:11 AM
04-24-2014 09:18 AM - edited 04-24-2014 09:31 AM
The person who says "the customer is always right" is almost always wrong. The customer is often wrong. Usually in some industries. When the customer wants something nonsensical it's your job to guide them to the right answer, not fold and give in to silly demands.
If a customer comes in to a car dealer demanding square wheels it's the salesman's job to figure out why they think they want square wheels and explain why round wheels are better. I'm asking why you want the square wheel of WiFi access control, and you're just saying "because". Either explain why you think you have a logical use case for MAC filtering or just listen and use WPA2 like you should be doing.
This "feature" would require development time and support, so it has costs. It also has a major negative in that it prolongs the myth that MAC filtering is actually useful. These are good reasons to not do it.
Now, if you present good reasons to do it, those may counter my points, but saying "waah I want it" without giving a reason why the better options don't work for you is not supporting your position.
04-24-2014 09:46 AM
Some staff members couldn't keep their mouths shut and ended up divulging the password to those who really had no business using it. What their sysadmin did to fix the problem was to implement MAC filtering on the PSK network. Imagine the surprise of the nosy guest clients when, even worth the correct password they were unable to access the secure network.
Now, could a determined attacker with five seconds and a packet sniffer get around that? Sure, absolutely. But most of the church guests had no idea what a MAC address even is. That allowed the staff a break of being harassed for the password because even if the first had it it wouldn't work anyway.
Could the whole situation be avoided by using 802.1x or a more rigid security policy? You bet. But it sure was low maintenance because there church doesn't replace equipment very often and once entered, MACs of their devices did not change.
It's not secure by any means, but it IS helpful
04-24-2014 10:18 AM - edited 04-24-2014 10:21 AM
If you're going to implement something that requires manual involvement by the administrator anyways, why not just not give the user the password in the first place? Trusted user enters the password, blabbermouth never knows what it is. Anyone who's stopped by MAC filtering will also not know how to get the WPA2 code out of their PC.
edit: I would, however, agree that there is a huge empty space in the WiFi market for WPA2-Enterprise to be offered as a complete package where you can set that mode and configure a user/pass list right there without needing a standalone RADIUS system.
04-24-2014 10:20 AM
Even though the only justification to want this feature might be that all the other Wi-Fi equipment already has it and that it is trivial to support it, and even though the reasoning behind asking this feature was explained multiple times in this thread I will reiterate them here for you because you are obviously too lazy to read or tofigure out scenarios on your own.
Let's say you have two SSIDs -- corporate and guest. Both are already using WPA2 encryption, but you want to make sure that only those employees you have personally whitelisted can actually ASSOCIATE with the AP. Even if they somehow find out the PSK for corporate SSID (i.e. learn it from a colleague), they will be stopped by the MAC whitelist.
While giving a colleague access to corporate SSID by sharing the PSK with them can be grounds for some sort of reprimand such as pay reduction, revoking access to resources, etc, an actual hacking attempt done by spoofing the MAC address in addition to obtaining the PSK shows enough malicious intent for a police investigation.
Once again, we are all aware that it is not a security measure -- it is not even a simple lock, but rather a sign "Beware of dog". We would still like to have it, because for a lot of people that is enough of a deterrent and those who are determined won't be stopped even with methods which are much more sophisticated.
It is all about the cost/effort/benefit optimization -- you wouldn't deploy a S.W.A.T. team to guard a warehouse if two armed guards are enough.
04-24-2014 10:31 AM
Thank you @bobdeverell @levicki @simonstenlund @coachmark2 for posting.
Be sure and head over here and officially vote for this feature if you have not already.