Re: Revisiting wireless NAC

[Mark Monroe <markm196 () NETSCAPE NET>]

What is the best way people have found to do this without letting ipads 
or tablets or personal laptops getting on that wireless network?

Institution owned devices such as laptops or PCs are able to get on the same as your wired clients (eg. Internal 
Network)

Mark Monroe
UMSL


On 1/4/2013 2:41 PM, Hahues, Sven wrote:
> Mr. Curry,
>
> I do not know if there is a solution like this sold by a particular vendor, but we are kind of doing what you are looking 
> for in regards to peer to peer enforcement on our housing network, but it probably wouldn't be too hard to extrapolate 
> this a little further:
>
> In our housing network we run an application called Integrity by RedLambda which is basically a fancy packetsniffer 
> with a lot of p2p signatures.  If this device sees peer 2 peer traffic, it sends an SNMP trap over to our NAC which 
> causes the device to be moved into a quarantine vlan.  There we hijack the DNS and redirect them to a page where the 
> users have to log in with their username and password (ldap lookup) and they are shown what their device was found to 
> be wrong with their network traffic.  They can read what they did here, and finally are able to put themselves back on 
> the network using a three strike system.  (Every strike increases a timeout that the users have to wait though there 
> are some opt-out methods for legitimate uses of p2p)
>
> Depending on your NAC you may be able to steer your users to a remediation portal that is configurable for what you are 
> looking for.  Our NAC at least lets us do so for AV/Updates.  Extending this a little further should not be a problem.
>
> Ultimately, I think what you are looking at doing is being able to have your devices have some sort of multi-tiered access 
> on the wireless (at least that's how we would like it):
>
> *  Institution owned devices such as laptops or PCs are able to get on the same as your wired clients (eg. Internal 
> Network)
> *  Devices that cannot be fully validated, or are mobile devices should have some access to internal data, but not full 
> access like a computer that is authenticated using a certificate and uses network traffic protection
> *  Untrusted devices such as the laptop Joe student brings to your campus to just surf the web, or chew up your 
> Internet bandwidth by watching Netflix on your wireless
>
> Hope that helps!
>
> Sven
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of David 
> Curry
> Sent: Friday, January 4, 2013 2:44 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: [SECURITY] Revisiting wireless NAC
>
> Hello,
>
> We're currently in the process of re-designing our wireless network to split it into a guest side and a "secure" side, add a guest management 
> system, replace the captive portal sign-on with 802.1X authentication on the secure side, etc. As part of this project, we're also taking a look at our 
> use of Network Access Control and thinking about what we're really trying to accomplish. At the moment, we use a "permanent agent" based NAC on 
> PCs and Macs connecting to the wireless network, but the only policy we enforce is that the computer must have antivirus running with up-to-date signatures. If 
> the connecting computer doesn't pass that check, we put it into a remediation VLAN.
>
> Back when we first implemented NAC (this is the second product), requiring antivirus software was a major factor in keeping malware out of our 
> network. But as we all know, it's not that simple anymore--just having antivirus isn't enough to keep the malware out because malware 
> has changed, and an argument can perhaps even be made that now that Windows and Mac OS X come with built-in firewalls and whatnot, the 
> requirement to have antivirus installed is obsolete. And then there's the fact that the majority of devices on our wireless network now are 
> not PCs and Macs anyway, and our existing NAC doesn't do anything with those. So, given all that plus some of the push-back we've 
> received from our user community about the NAC requirement in general and this specific NAC in particular, we started thinking...
>
> Why don't we get rid of the NAC all together? And instead, we'll just let any device connect to the network (provided the user authenticates), and let it do whatever it wants, right up 
> until the point at which it misbehaves. Instead of running the NAC system, we'll run some kind of intrusion detection system that's looking for malicious traffic. If it sees some, it will 
> block the traffic from that device, and move the device into a "quarantine" or "remediation" VLAN where the user can be informed (with a captive portal or whatever) that his/her 
> computer may be infected with malware and provided with advice/tools on cleaning it up. This seemed easy enough, but when we started looking for products, we couldn't find any. There are plenty 
> of IDS/IPS systems out there that can detect and block the traffic; that part's easy. But we've been unable to find any products that can also do the other part--sending users to some sort 
> of quarantine/remediation portal so that they know why their computer isn't working on the network anymore. This last part is critical to us, as we do not run a 24x7 help desk, and we don't 
> want to just silently drop users' traffic with no explanation when there's nobody they can call to find out what's happening.
>
> So finally, my question: Has anybody implemented something like this? If so, would you be willing to share how you did 
> it?
>
> Thanks,
> --Dave
>
>
>
>
> --
>
> DAVID A. CURRY, CISSP * DIRECTOR OF INFORMATION SECURITY
>
> THE NEW SCHOOL * 55 W. 13TH STREET * NEW YORK, NY 10011
>
> +1 212 229-5300 x4728 * david.curry () newschool edu <mailto:david.curry () newschool edu>
>
>
> ________________________________
>
> No department at FGCU will EVER ask you for your username and password in person or through e-mail. If you receive an 
> e-mail requesting your EagleMail or FGCU email password, DO NOT respond. Delete the e-mail immediately. If you receive 
> a questionable e-mail, please contact the Help Desk at 239-590-1188.
>
> ________________________________
>
> BUSINESS TECHNOLOGY SERVICES WILL NEVER ASK FOR YOUR PASSWORD. You should never give out your username or password for 
> any accounts you have, including bank accounts, credit card accounts, and other personal or University accounts. 
> Business Technology Services will never contact you using a return e-mail address that is not @fgcu.edu. If you receive 
> a questionable e-mail or an e-mail asking for passwords and logon information, DO NOT RESPOND, and please contact the 
> Help Desk at 239-590-1188.