06-21-2011 10:50 AM
Wondering if anyone has implemented a process for containing target devices "behaving badly" - until the user remedies the situation - in a way that notifies the user via web page redirection. Two use cases come mind - DMCA take-down notices and devices found to have a virus - but we'd like to have something flexible enough to trigger on any reason.
Currently when we discover an offending device we suspend the user's credentials in the backend. When the wireless reauth interval is up the user simply cannot re-login and eventually calls the Help Desk. This has two downsides. One is that we effectively disallowed usage to ALL devices for that user. Second, there is no good way for the user to know what just happened (we do send an alert email but I've been reminded of the chicken and the egg and of the Little Boy Who Never Reads Signs).
We wish to contain offending devices into a separate walled garden (via role? vlan? both?) and offer notification to the user in the form of a web page redirect to a "You're Here Because of XXX" page, much like captive portal for post logins. We need this to work on both our "open" CP network and our .1X network. We also need this to work whether the user is currently associated or will be in the future. Blacklisting is too heavy handed (no redirect page).
The triggering agent may come from several sources: a Fortinet box, a Remedy Ticket (where a button press launched a script) or via the command line script so we need to be flexible here.
Current ideas include:
- Building a special role or vlan with CP redirect features
- Use ESI's XML API (via cli script) to change vlan or role
- Use Radius VSA to place user into unique role or vlan
- User derivation rule based on MAC whitelist into a role or vlan
- Using DHCP local lookup (flat text file of MAC addresses) to put device in special IP space that has DNS spoofing enabled
- Amigopod (have no hands-on experience with this yet).
I'd love to hear from anyone who already has something working or from anyone who has other ideas about making this work.
Thanks in advance!
06-25-2011 10:29 AM
In order words -if a Fortinet device automatically spits out a 'contain' message to the central authentication system, how is the Fortinet going to verify that remediation was successful and send the 'all clear' to the authentication system?
I think you really have to think about the use cases. If it were a DMCA take down notice, perhaps they could have a week to comply, with a click through acceptance every 24 hours . Who will verify the the infringing copyright works were removed? Also, what happens if the individual makes a counter notification to the take down? Will their access be reinstated? How will you verify that they made a counter notification?
If their computer is malware infected, I would definitely and immediately put them into a remediation VLAN, with an external Captive Portal specifying the reason. You could also open up the firewall to allow updates to fix their computer.
06-27-2011 07:29 AM
All of these process exist for our wired network and work relatively well. For the wireless network we are currently taking a rather heavy-handed approach once an offense is discovered. Instead of of device containment, as we do on the wire, we simply remove the wireless bit for that user in LDAP. In other words, LDAP would send a NACK to radius when the user attempts to authenticate again over wireless (the user's other wireless devices and wired authentication for this device would still presumably work). Our reauth intervals are relatively short so we just let the current session run out. Again, not optimal. Because this is a rather "blind" method the user has no way of knowing what happened until they contact the help desk.
As far as remediation (and recidivism) for DMCA, our help desk staff currently processes our DCMA complaints. Whatever process they use for remediation would remain in place, including following the status of those users who wish to challenge the complaint.
I'm thinking that the target MAC address to be contained would be entered - again by a "human initialed" Remedy trouble ticket - in a separate "lookup list" (local file on radius, controller or dhcp server..that's the piece we're still working on). The next time the device goes through the normal auth process, if the MAC exists in this lookup file then the device is contained, preferably with a CP-like redirect to a remediation help desk page similar to the page we use for wired connections. This page would notify the user there's an issue and would allow them to log into Remedy from that page to view the offense and course of action to remediate. I agree that if the offense is a virus there could be allowed access to updates or other fixes, or the user would be instructed to bring the device into our software support department for scanning and updates. This is what we typically do now as it ensures that the device really got updated or the virus got properly exorcised. Students are not always honest about whether they foxed their issue.
Once the user satisfactorily remediates - as determined by existing help desk policies - the MAC address would be removed from the lookup list based on a second script triggered from the status change in the Remedy ticket. Verification would be easy enough as the "remove" script could do a sanity check and send a notification that the MAC is no longer in the lookup list.
This is the goal at this point.