Re: [fw-wiz] Securing a wireless network
From: David Lang (david.lang_at_digitalinsight.com)
To: Mark D Robinson <email@example.com> Date: Sat, 30 Oct 2004 20:54:38 -0700 (PDT)
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
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
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
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
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.
On Fri, 29 Oct 2004, Mark D Robinson wrote:
> Date: Fri, 29 Oct 2004 21:12:38 -0500
> From: Mark D Robinson <firstname.lastname@example.org>
> To: email@example.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"
> 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
-- 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 firstname.lastname@example.org http://honor.icsalabs.com/mailman/listinfo/firewall-wizards