Friday, January 21, 2005
Quest for Wire(less)
Much like CityTV, blogs, and Paris Hilton, wireless is everywhere...
It seems like everywhere I go, companies have deployed wireless networks. And why not? Given the incredible freedom and convenience wireless give the user, this by itself is not particularly suprising. What *is* surprising, however, is how many companies deploy insecure wireless networks.
My guess is that these wireless networks all came about the same way that mine did: end-user driven, and driven from above. I still remember the day my CEO came by my desk and told me that he really wanted us to have wireless access in his office and our boardroom. Hmmm, I thought...this could be interesting. The news was stuffed with warnings about the inherent insecurity of wireless networks...but the message was clear: make it so.
I dove into researching just how I could deploy something that wouldn't completely compromise all of our internal security measures. Given that this was over 2 years ago, my options were fewer than they are today. I was soon lost in a jungle of whitepapers and articles about 802.11a,b,g,i,x,WEP,WPA, and so on. There was news of new and emerging standards that *would* be secure, but of course none of the WAPs on the market would support them, the existing wireless cards wouldn't support them, the existing O/S's wouldn't support them, and oh yes, did I mention there wasn't really any budget for this project? Yeah.
The typical wireless security advice of the day was the sort of thing found here. Not exactly ispiring confidence when they tell you to use WEP, and then admit that's easily crackable in the same sentence. Nowadays, tools like aircrack make WEP even less useful than it was back then. About the best security tip I found was to combine WEP with limiting access by MAC address. This, of course, required pre-loading the MAC address of every wireless card into the WAP, and then maintaining this list for time eternal. I'd prefer the root canal, thanks.
Realizing that my chances of finding a technical panacea were slim, I forged on. Thinking outside of the box (as they say), I started thinking about other ways to secure our insecure wireless traffic. Inspired by articles like this one from Colubris Networksand this one from isaserver.org, I set about designing a deployment that would use our existing firewall and VPN to add security to our wireless LAN.
Part one was to treat wireless clients as hostile. And so, our comsumer-grade LinkSys was installed into the DMZ. Oh yes, with WEP enabled. (hey, it won't hurt!) Next up, give users a known isolated IP address. My WEP didn't do DHCP, so I configured a DHCP server on the firewall, and created a small scope of addresses to assign to the wireless clients. At this point, the firewall restricted any wireless client from accessing the Internet, and from access the LAN. Not only did I not want any corporate espionage, I also didn't want pimply-faced kids surfin porn on my dime! Perfect! Hack away! Oh wait, one more thing - give 'real' users access! (Darn those pesky users again...) I added a DMZ rule on the firewall, allowing only the wireless client range to only access the external interface of our VPN device, and only on TCP port 10000 - the port used for transparent tunneling of our 168-bit IPSec tunnels. And there it was...user friendly enough, secure enough, and pretty much free. The other nice thing was that since I wasn't using 'wireless' technology for the security, there was no concern about compatability with wlan cards, or with keeping up with standards as they change - the solution would hold up over time.
Interestingly, my new organization is currently in the early stages of looking at a corporate, global wireless implementation. This time, there's some better answers to the wireless security question. Some of those 'emerging standards' are now incorporated in real products, and supported by OS updates in Windows as well. Embarking on this project again, I still find that it's difficult to find one place that really describes all of the security options concisely. A few Google searches, and you'll have a ton of material to sift through. That said, this seems like a decent place to start.
This time around, instead of WEP, I'll be looking at 802.11i, WPA, and 802.1x. 802.11i is the complete reworking of wireless security to replace the faulty WEP. It's not fully available yet, but WPA is. WPA is a subset of the 802.11i fuctionality, meant as a stop-gap while the full standard crawls forward. 802.1x is actually just a means of authentication, which has been incorporated in both WPA and 802.11i.
Unfortunately, even as we stand here in early 2005, 802.1x has just been incorporated in a recent Microsoft update for XP and Server 2003, and in checking the LinkSys site, I see that none of their WAPs support WPA. Upgrade to the Cisco offerings, and WPA is there. Now...how many different brands and models of WLAN cards do I have? (gulp!) As an aside, the May 2004 issue of Windows & .Net Magazine featured a nice article on securing wireless authentication using 802.1x.
Dealing with a changing standards is always aiming at a moving target. There's bound to be incompatabilities along the way, so make sure that you test everything out before dropping a lot of money, and prepare yourself for newer and better stuff to be coming down the line. On a positive note, WPA is promising to be forward-compatible with 802.11i down the road.
Wireless security is no doubt a bumpy road, but the way is looking clearer all the time! Happy surfing...
It seems like everywhere I go, companies have deployed wireless networks. And why not? Given the incredible freedom and convenience wireless give the user, this by itself is not particularly suprising. What *is* surprising, however, is how many companies deploy insecure wireless networks.
My guess is that these wireless networks all came about the same way that mine did: end-user driven, and driven from above. I still remember the day my CEO came by my desk and told me that he really wanted us to have wireless access in his office and our boardroom. Hmmm, I thought...this could be interesting. The news was stuffed with warnings about the inherent insecurity of wireless networks...but the message was clear: make it so.
I dove into researching just how I could deploy something that wouldn't completely compromise all of our internal security measures. Given that this was over 2 years ago, my options were fewer than they are today. I was soon lost in a jungle of whitepapers and articles about 802.11a,b,g,i,x,WEP,WPA, and so on. There was news of new and emerging standards that *would* be secure, but of course none of the WAPs on the market would support them, the existing wireless cards wouldn't support them, the existing O/S's wouldn't support them, and oh yes, did I mention there wasn't really any budget for this project? Yeah.
The typical wireless security advice of the day was the sort of thing found here. Not exactly ispiring confidence when they tell you to use WEP, and then admit that's easily crackable in the same sentence. Nowadays, tools like aircrack make WEP even less useful than it was back then. About the best security tip I found was to combine WEP with limiting access by MAC address. This, of course, required pre-loading the MAC address of every wireless card into the WAP, and then maintaining this list for time eternal. I'd prefer the root canal, thanks.
Realizing that my chances of finding a technical panacea were slim, I forged on. Thinking outside of the box (as they say), I started thinking about other ways to secure our insecure wireless traffic. Inspired by articles like this one from Colubris Networksand this one from isaserver.org, I set about designing a deployment that would use our existing firewall and VPN to add security to our wireless LAN.
Part one was to treat wireless clients as hostile. And so, our comsumer-grade LinkSys was installed into the DMZ. Oh yes, with WEP enabled. (hey, it won't hurt!) Next up, give users a known isolated IP address. My WEP didn't do DHCP, so I configured a DHCP server on the firewall, and created a small scope of addresses to assign to the wireless clients. At this point, the firewall restricted any wireless client from accessing the Internet, and from access the LAN. Not only did I not want any corporate espionage, I also didn't want pimply-faced kids surfin porn on my dime! Perfect! Hack away! Oh wait, one more thing - give 'real' users access! (Darn those pesky users again...) I added a DMZ rule on the firewall, allowing only the wireless client range to only access the external interface of our VPN device, and only on TCP port 10000 - the port used for transparent tunneling of our 168-bit IPSec tunnels. And there it was...user friendly enough, secure enough, and pretty much free. The other nice thing was that since I wasn't using 'wireless' technology for the security, there was no concern about compatability with wlan cards, or with keeping up with standards as they change - the solution would hold up over time.
Interestingly, my new organization is currently in the early stages of looking at a corporate, global wireless implementation. This time, there's some better answers to the wireless security question. Some of those 'emerging standards' are now incorporated in real products, and supported by OS updates in Windows as well. Embarking on this project again, I still find that it's difficult to find one place that really describes all of the security options concisely. A few Google searches, and you'll have a ton of material to sift through. That said, this seems like a decent place to start.
This time around, instead of WEP, I'll be looking at 802.11i, WPA, and 802.1x. 802.11i is the complete reworking of wireless security to replace the faulty WEP. It's not fully available yet, but WPA is. WPA is a subset of the 802.11i fuctionality, meant as a stop-gap while the full standard crawls forward. 802.1x is actually just a means of authentication, which has been incorporated in both WPA and 802.11i.
Unfortunately, even as we stand here in early 2005, 802.1x has just been incorporated in a recent Microsoft update for XP and Server 2003, and in checking the LinkSys site, I see that none of their WAPs support WPA. Upgrade to the Cisco offerings, and WPA is there. Now...how many different brands and models of WLAN cards do I have? (gulp!) As an aside, the May 2004 issue of Windows & .Net Magazine featured a nice article on securing wireless authentication using 802.1x.
Dealing with a changing standards is always aiming at a moving target. There's bound to be incompatabilities along the way, so make sure that you test everything out before dropping a lot of money, and prepare yourself for newer and better stuff to be coming down the line. On a positive note, WPA is promising to be forward-compatible with 802.11i down the road.
Wireless security is no doubt a bumpy road, but the way is looking clearer all the time! Happy surfing...
Friday, January 14, 2005
The Joy of SUS
Wouldn't you be amazed to find a robust, full-featured piece of software that was easy to deploy, saved you hundreds of hours, and - wait for it - was free?
Well, that's exactly what happened to me this year when I found SUS. Since then, I've become it's biggest fan, and decided to sing its praises here.
Oh wait, did I mention it's made by Microsoft?
Many of you by now have likely heard about 'Software Update Services' (SUS), but 9 months ago, I felt like I'd stumbled upon a pearl in my baththub. (hmm...bad analogy?)
Anyway, what sparked my search for a patching solution was the outbreak of Sasser. You may recall that this was one of those nasty worms that didn't require any user action, it just infected any unpatched Windows 2000 or XP machines that it could find. (Dastardly! I much prefer the ones where you at least have to be dumb enough to launch the attachment!)
Despite some confidence that my firewall would keep any outside machines from starting an outbreak, the potential threat of travelling users and home VPN connections left me facing the thought of patching >150 machines by hand. Not a large number of machines perhaps, but still not something I was looking forward to. (aside: Why is it that a non-administrator can't run Windows Update on a Win2K machine? Somehow that just seems to contradict the security push...)
And so I embarked on a search for a free, automated patch management tool, and stumbled across a SUS reference in a newsgroup somewhere.
Using a combination of Microsoft's SUS site and susserver.com, I was able to get this up and running within a day.
What's good about SUS:
1) Simple deployment via Group Policy (ok, for those of you without Active Directory, you'll have to distribute registry changes some other way.
2) Ability to 'Approve' updates. Updates are not deployed to my clients until I say so. Nice way to do some testing and avoid problem patches (came in handy while testing XP SP2!)
3)Minimized WAN traffic, due to single download point.
4)Low maintenance, easy administration.
What's lacking in SUS:
1) Directed updates - currently, all approved updates go to all clients of the SUS server, there's no finer control.
2) Reporting - There's no 'nice' built-in tool for confirming exactly which updates have been installed by which client. You'd have to run MS Baseline Analyzer or some other tool against a client to verify the updates. You *can* upload your IIS logs and get them analyzed here. Or download the add-on tool created by Wayne Flynn and create your own reports.
3) Ability to deploy more than just Windows updates. SUS will only do Windows updates and Service Packs. No SQL Server updates, no Office updates, etc.
All in all, SUS has served me well, and I can't wait for WUS. I'm currently playing with the beta, and although I'm still not quite *there* with it, I'm happy to report that it seems to address all three of the shortcomings listed above.
Between this and the new anti-spyware beta, I don't think anyone can say that Microsoft isn't stepping up to the plate to make securing their software easier.
Well, that's exactly what happened to me this year when I found SUS. Since then, I've become it's biggest fan, and decided to sing its praises here.
Oh wait, did I mention it's made by Microsoft?
Many of you by now have likely heard about 'Software Update Services' (SUS), but 9 months ago, I felt like I'd stumbled upon a pearl in my baththub. (hmm...bad analogy?)
Anyway, what sparked my search for a patching solution was the outbreak of Sasser. You may recall that this was one of those nasty worms that didn't require any user action, it just infected any unpatched Windows 2000 or XP machines that it could find. (Dastardly! I much prefer the ones where you at least have to be dumb enough to launch the attachment!)
Despite some confidence that my firewall would keep any outside machines from starting an outbreak, the potential threat of travelling users and home VPN connections left me facing the thought of patching >150 machines by hand. Not a large number of machines perhaps, but still not something I was looking forward to. (aside: Why is it that a non-administrator can't run Windows Update on a Win2K machine? Somehow that just seems to contradict the security push...)
And so I embarked on a search for a free, automated patch management tool, and stumbled across a SUS reference in a newsgroup somewhere.
Using a combination of Microsoft's SUS site and susserver.com, I was able to get this up and running within a day.
What's good about SUS:
1) Simple deployment via Group Policy (ok, for those of you without Active Directory, you'll have to distribute registry changes some other way.
2) Ability to 'Approve' updates. Updates are not deployed to my clients until I say so. Nice way to do some testing and avoid problem patches (came in handy while testing XP SP2!)
3)Minimized WAN traffic, due to single download point.
4)Low maintenance, easy administration.
What's lacking in SUS:
1) Directed updates - currently, all approved updates go to all clients of the SUS server, there's no finer control.
2) Reporting - There's no 'nice' built-in tool for confirming exactly which updates have been installed by which client. You'd have to run MS Baseline Analyzer or some other tool against a client to verify the updates. You *can* upload your IIS logs and get them analyzed here. Or download the add-on tool created by Wayne Flynn and create your own reports.
3) Ability to deploy more than just Windows updates. SUS will only do Windows updates and Service Packs. No SQL Server updates, no Office updates, etc.
All in all, SUS has served me well, and I can't wait for WUS. I'm currently playing with the beta, and although I'm still not quite *there* with it, I'm happy to report that it seems to address all three of the shortcomings listed above.
Between this and the new anti-spyware beta, I don't think anyone can say that Microsoft isn't stepping up to the plate to make securing their software easier.
