Re: Securing a wireless network

[David Lang <david.lang () digitalinsight com>]

I've thought about similar things for my home system and for systems I 
administer for non-profit groups.

I think these situations differ slightly from the typical corporate 
environment.

1. very little data on the network has significant value

2. you have almost no control over the clients

even more so then in corporate environments you don't have a budget so you 
end up trying to make a reasonable attempt that you know will not stop 
anyone who is determined, but it will be better then being a wide open 
invitation.

becouse of the lack of control over the clients anything that involves 
distributing keys and special configuration (like WEP does) is not 
practical (and you DON'T want to try and field all the calls that these 
problems would generate, especially from the high muckty-mucks who get 
their machine properly configured for this network and then call you to 
help make the machine work on their home network)

I haven't yet implmented this as anything other then a proof-of-concept 
set of shell scripts (and then only partially) but here are my thoughts on 
the issues.

anyone who starts sniffing and changing their MAC address is probably 
going to be able to defeat any barriers we can raise so note this as a 
risk and then ignore it.

so you can now base some of your security on the MAC addresses that you 
see over the wire, let's leverage that.

MAC addresses now fall into two catagories known and unknown.

for known (approved) mac addresses you just want to give them an address 
and let them start working. this can be done easily with static DHCP 
leases

for unkown MAC addresses you want to let them on the network, but only 
enough to tell you who they are and get approved.

create a seperate network with no routing to or from the outside world and 
use DHCP to issue addresses in this seperate network.

Then use NAT or DNS games to direct any HTTP request to a special server 
that has them register (including identifying themselves). this is where 
you would insert a requirement to download and run a script, the script 
can report back to the server that it has completed sucessfully. Note that 
you can (and should) use HTTPS for this authentication)

after the user has satisfied your authentication server it updates the 
DHCP configuration to now include this MAC address as a known one, 
instruct the user to reboot their machine, and when it comes back up it 
will now be a known machine and have access.

for a little added security you can use static ARP entries or firewall 
rules on your gateway box to make sure that the MAC address and IP address 
are what you expect, although anyone who has sniffed the network enough to 
figure out the allowed IP addresses and manually set it into their machine 
may not be slowed much by the need to set the MAC address as well.

This approach ahs the advantage that the only software the client needs is 
a browser and DHCP client so anything should be able to use it.

now when useing a network 'secured' as I list above for anything at all 
sensitive you have to recognise it's limitations and treat it like you 
would a DSL or dial-up line from home, run a VPN or something equivalent 
to provide the secure access to the area you need, but for areas where you 
do not have that need this should work reasonably well.

David Lang

On Fri, 29 Oct 2004, Mark D Robinson wrote:

> Date: Fri, 29 Oct 2004 21:12:38 -0500
> From: Mark D Robinson <mrobinso () fpkc com>
> To: firewall-wizards () honor icsalabs com
> Subject: Re: [fw-wiz] Securing a wireless network
>
>
> You might try looking through the list archives. I vaguely remember a
> discussion about a custom system that was set up on a university network to
> enforce up-to-date security settings (patch level, AV updates, etc.) before
> the host was given access. Unfortunately, I don't remember any specifics
> right this minute, but I do remember being pretty impressed from the
> description. I think that some or all of the software was freely available.
> It was probably last year or early this year. Someone else on the list may
> remember more.
>
> This might also help:
> "Strategies for Automating Network Policy Enforcement"
> http://security.internet2.edu/netauth/docs/draft-internet2-salsa-netauth-summary-02.html
>
> HTH
>
>
> Mark Robinson
> IT Manager
> Frilot, Partridge, Kohnke & Clements, L.C.
>
>
> -----Original Message-----
> ...
> A few other relevant solutions have been suggested, but they're all
> retail.  I was actually expecting more of the 'free unix' approach;
> maybe I've been on Full-Disclosure for too long ;).
> ...
>
> ---------------------------------------------------------------------------
> The information in this electronic message may be privileged and
> confidential and is intended for the use of the individual(s) or
> entity(ies) named above. If you are not the intended recipient, you are on
> notice that any unauthorized disclosure, copying, distribution, or taking
> of any action in reliance on the contents of these electronically
> transmitted materials is prohibited.
> ---------------------------------------------------------------------------
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () honor icsalabs com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no 
deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards