NAC

[Arran Cudbard-Bell]

Phil Mayers wrote:
> On Thu, 2007-07-12 at 12:46 +0100, Arran Cudbard-Bell wrote:
>   
>>>> It's another topic that I'm overall sceptical of NAC, IMO a network should 
>>>> only reactively shut a client down *after* it did something wrong, not 
>>>> proactively sniff around the local environment and lock it away at once. But 
>>>> NAC is here to stay I guess. :-(
>>>>     
>>>>         
>>> "Presumed innocent" is a nice idea, but IMHO there are environments that
>>> simply doesn't work in. Financial institutes are one I can think of, and
>>> I could make convincing arguments based on my own experience that many
>>> academic networks (and CERTAINLY student residence networks) would
>>> benefit greatly from a default-deny.
>>>   
>>>       
>> Right, but machines on a residential network are generally going to be 
>> personal machines, I for one would protest greatly if I was forced to 
>>     
>
> You could protest all you wanted; *if* we had implemented that policy
> then it would have been signed off by the student union, senior tutors
> and college IT security advisory group, and it would have been in the
> wording on the bit of paper you sign when you join the university.
>   
Oh you have one of those political infrastructure things ..
We have an AUP policy which students have to accept before we allow 
their machines onto the network, and it does stipulate that users should 
have an up to date antivirus solution, but we don't explicitly enforce it.
> We've done this with lots of other policies (e.g. 5Gb/24 hours bandwidth
> limit - exceed it once and you're off for 48 hours, 2nd time and it's 2
> weeks and 3 times, you're off for the rest of the academic year) and it
> works fine.
>
>   
Thats a pretty harsh policy, considering the residential network here 
uses at least 40mbit/s downstream b/w at any given time throughout the 
day, i'd say most of our students would use up their 5gb quota pretty fast.

We use rate limiting here instead, based on the number of connections 
over a given period of time. This only targets really targets p2p 
traffic, and leaves everyone else undisturbed. We inform the students 
that they have been rate limited, and that they may be experiencing a 
slow connection, but there are no permenant blocks or bans in place, so 
after a period of time they automatically get the rate limiting removed.
Eventually they learn ...
>> install an AV solution just to use the network in my halls of residence. 
>> It's fine dictating what is installed on University owned machines, but 
>> users personal equipment is their *own*, and they should be able to 
>> manage it how they see fit.
>>     
>
> I have no intention of forcing people to install software to get onto
> the network.
>
> But when they get kicked off into a BANNED vrf, after the first offense
> we require that they prove their machine is clean before they get back
> on. At the moment, that means they physically carry it to the helpdesk.
>   
Our helpdesk staff would absolutely hate us if we tried that here !
> Were the option available, running some kind of software agent that we
> supply seems like a clear win.
>   

So say I'm doing something perfectly legitimate with my embedded *nux 
box, and your IDP system bans me for some reason ... do your helpdesk 
staff have the technical knowlege to check that my *nux box is safe and 
secure ? Or do they feed me some line about having to install a 
supported operating system, and an AV client from a recognised 
commerical vendor ?
> People focus rather too much on the "initial access" bit of NAC, and
> seem to ignore the remediation benefits.
>
>   
>> If you feel like experimenting a little, you can always stick a snort 
>> probe at a key point in your infrastructure.
>>     
>
> We have extensive IDS and IPS systems setting between our residence
> network.
>
>   
Do you get many false positives ?
>> Then make decisions as to whether the user should be segregated  from 
>> the main network, based on the information gathered about what their
>>     
>
> The residences systems ARE segregated from the main network, always and
> forever - they live in a VRF and hit a firewall before coming into the
> main production zone.
>
>   
Yes ours sit behind a cluster of routing firewalls.
What I meant by main network was a network other than a "quarantine" 
network.