NASA Overcomes 802.11b Wireless Security Flaws

4mn0t1337 writes: "Looks like the people at NASA came up with a "solution" to the weak secrutity in 802.11: Bypass it. From the article: "The team also assumed that all information on the network would be subject to eavesdropping, and that no identification information built into 802.11b could be trusted." So they chose to disable it, and set up an 'off-the-shelf PC running the OpenBSD operating system, an Apache web server, the Internet Software Consortium DHCP server, the IPF firewall software' and just depend on the security in protocols the services use. Moral of the story: Ignore the 802.11 security and just tunnel into our access points ..."

Cool...but...

[Multispin]

This is the same thing that any major, secure install has been doing from day 1.

However, it is good to see widespead use of these techniques. Maybe it'll help those less secure installs:)

Working on something similar

[Mike Hicks]

I'm working on something similar using Linux and IP Tables. One benefit (apparently -- I haven't played with IP Filter yet) of using IP Tables is that packets can be matched by IP address and MAC address at the same time.

I shouldn't say that my piddly firewall can measure up to what the folks at NASA could cook up, though, as I haven't figured out how to get the statefulness of IP Tables/Netfilter to help me out. We're also not using VPN yet (though we're planning to allow VPN clients to connect to a server farther upstream).

Tunneling is not the answer.

[davidu]

This solution, far from creative or unique, offers nothing in terms of aiding in the creation of secure PUBLIC networks.

For example, a college campus can't be expected to teach every student, including the non-geeks how to setup IPsec, port forwarding with SSH, and all other kinds of neat things.

Granted, Dan Kaminsky [doxpara.com] gave a talk at DefCon this year on how to seamlessly tunnel your way through 'hostile' networks it still isn't as simple as just renewing your IP and being online.

One possible solution to secure public nets is similar to the way we validate PGP keys. Face to face signing parties. If I run a public net I'd like to know who is using it. How about you drop by my cafe and just give me your MAC address and I'll add you to the firewall's rulesets. Automatically you now can find out who is in promiscuous mode, who is using all your bandwidth, etc, etc, etc.

There are many other solutions that aren't as much of a hack as IPSec, ssh tunneling, or any of these other high level obfuscators.

Thanks,
David U.

Re:How secure is TCP/IP over wire? Not much.

[Ronin Developer]

Allowing the underlying application protocols to implement security is a good idea.

We've deployed a wireless application over CDPD. While we can pretty much assume the traffic between modem and CDPD carrier is encrypted and authenticated using the built in capabilities, we can't say the same about the connection from the carrier to our customer's site and their WAN.

As such, we employ an embedded VPN solution at each client and terminating site. Traffic is encrypted from the moment it leaves the mobile unit until it reaches its final destination. Unencrypted trafffic is not visible except on the terminating LAN (if the VPN is running on a machine seperate from the server).

Perspective.

[volsung]

Um, if by the statement "Revolutionaries are seldom welcomed by the established power, after all." you are trying to somehow link yourself and the other "oppressed" of Slashdot to great revolutionaries, then I would suggest you have a distorted perception of this situation and of your own importance.

I would suggest the following experiment to help you gain some perspective:

• Turn off your computer and go outside. Observe your surroundings and note that Slashdot has no influence on any of them.
• Go downtown and watch the crowds for several minutes. Realize that you probably have not seen a single person who knows anything about Slashdot or will ever be influenced by Slashdot.
• Ask yourself whether Slashdot can injure your ability to eat, sleep, or move around without your consent. Then ponder whether Slashdot can hinder your free expression in any other forum but Slashdot itself.

Sure, Slashdot's recent attempts to solve the fundamental paradoxes (freedom vs. quality) of public, online discussion are flawed and causing the site to commit suicide slowly. (For example, I discovered that I cannot title this message "Perspective, perspective, perspective." because it is too repetetive. Silly.) However, do not compare yourself to revolutionaries who struggled to change real, meaningful things. This is an electronic playground and nothing more. Only five-year-olds lead revolutions on playgrounds.

Re:not perfect, but worth modding up...

[Anonymous Coward]

not quite sure how you are going to get your certificate validated to a nasa.gov domain via any certificate authorities

Don't need to. I'll use http. Their http server redirects you to https. Mine won't. Most users won't notice the difference. I'll put an "under construction" icon on the page and say we're remodeling. All I need is one less-cluefull user to give me his username and password, and it's game over.

And this without even getting into DDOS attacks. A rogue DHCP server is a mindnumbingly painful adversary.

A real solution

[WestonP]

I've been doing that for some time now. I simply consider the 802.11b net to be accessable to the public, and therefore it's firewalled. The problem is that people can still see what I'm doing (with the exception of SSH and HTTPS) or spoof the IP address of my laptop and get Internet access. But here's how I plan to actually solve the problem once and for all:

I'll install Linux (BSD's should work too) on my laptop and tunnel PPP over SSH to my server, thus creating a quick and easy VPN. My server's firewall will then be set to block and log everything except DHCP and SSH that comes over the real 802.11b interface, but allow everything that uses the secured PPP session.

That causes three problems:

1) I'd like to be able to keep Windows on the laptop just for the software compatibility, but I think I can get by with VMware under Linux.

2) It's not very scalable. The best solution I can think of is to make a universal SSH acount that just provides PPP sessions. The client PPP IP address would be selected based on some sort of ID that the client provides, just like DHCP. I suppose I could make the client script pass it's 802.11b adapter's MAC address to the server and then the server would assign it an IP accordingly. But, I still have to give anyone who I want to connect to my network the password for that SSH account and the client side script, and they have to be running a UNIX family OS.

3) I'm still vulnerable to DoS attacks by people in range of my WLAN. A simple broadcast storm would probably be pretty effective. But, I don't think this is a big threat, since my range is pretty limited. I'm also vulnerable to any security holes that may be in DHCP or SSH, but I seriously doubt there are any skilled crackers within range of my WLAN. And, I'll patch any holes myself once they are published on BugTRAQ or something, so script kiddies aren't a threat, if there are any in range.