Contributor II

Greylisting--Not Quite Blacklisting...Redirect by Fingerprint or MAC

Do you have a lot of problems with a particular device type?


Have users that bring devices in you don't want to support?


Want to allow certain users device types or MAC addresses on your "secured" networks but not on your Guest Network?


Blacklisting's always an option but you have to maintain the blacklist or have an expiry timer, and it's global, so once you're on the bad-list, you cannot associate to ANY ESSID in the system.    


Also blacklisting simply denies access, the user is not informed they're doing something wrong, or should be on another ESSID.       This solution can be expanded to a per-device type or per-behavior splash page for any mis-associated client type or MAC address.


 Let's just focus on correcting the behavior on a single ESSID or with a single AAA profile on mutiple ESSIDs.


Here are two solutions we've deployed.  ---- DHCP Fingerprinting and isolation or MAC-based Web redirect.


1.   On the Guest Network we use a "User Rule" in the AAA policy that takes a specific DHCP fingerprint and sends it to a captive portal page that informs them that device is not supported on that network.




The "employee-denied" role has a captive portal profile (ironically also named "employee-denied" which sends them to an Amigopod splash page (with the logon fields removed so no logon is possible).  


This could also point to any webserver/captive portal page allowed by the specific role "employee-denied".



Here is our example "employee-denied" role.





and the Captive Portal profile assigned to it...





On the Amigopod, we customized the Web Logon to remove the login fields...




And add the verbage to the page to inform the user...




When the user accesses, they see:





2.    The second option leverages MAC authentication as well as Captive Portal logon, is to override the Captive Portal Role with either a more-restrictive or less-restrictive role than that assigned to the Captive Portal users.


We've deployed this so that "known MACs" can be sent to the page above  via role assignment like we did above (by simply enabling MAC auth on the AAA profile and entering the MAC in the Internal Database or on an External server with the "employee-denied" role assigned.


Remember of course that MAC spoofing is very easy, and you do not want to elevate access too highly if this is upon an open-unencrypted network.   


Just a reminder to keep your data safe...






Search Airheads
Showing results for 
Search instead for 
Did you mean: