Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Privacy

NASA Overcomes 802.11b Wireless Security Flaws 111

Posted by timothy from the one-way-to-do-things dept.
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 ..."
This discussion has been archived. No new comments can be posted.

NASA Overcomes 802.11b Wireless Security Flaws More

NASA Overcomes 802.11b Wireless Security Flaws

Comments Filter:
  • Depend on protocols that will be easily hacked as soon as someone sets to it?

  • NASA bypasses 902.11b flaws (Score:3, Insightful)

    by FreeMars ( 20478 ) on Saturday September 01, 2001 @11:32AM (#2243074) Homepage
    Hmmm. Not so much a bug fix as a work around

  • That's a pretty sad response (Score:5, Insightful)

    by mesocyclone ( 80188 ) on Saturday September 01, 2001 @11:32AM (#2243077) Homepage Journal
    Tunneling works for security, but it is far less flexible than plain old IP connectivity, which is what 802.11b delivers.

    The solution is to *fix* 802.11b's security, which shouldn't be that hard. I believe that simply running the crypto algorithm through a few start cycles, before transmitting, is sufficient to stop the published attacks.

    Whether the fix requires buying new hardware, or flashing old hardware, or just changing drivers, is another question.

    • How secure is TCP/IP over wire? Not much. (Score:3, Insightful)

      by Anonymous Coward
      WEP should be viewed as a means of thwarting casual snooping, just as having separate 10BaseT cables for each computer hampers casual snooping. But unencrypted network traffic is ALWAYS vulnerable to snooping, so claiming 802.11b is fatally insecure is foolish. Unencrypted traffic should always be viewed as insecure.
      • 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).


    • The solution is to *fix* 802.11b's security, which shouldn't be that hard. I believe that simply running the crypto algorithm through a few start cycles, before transmitting, is sufficient to stop the published attacks.


      A potential solution for quite a few flaws in WLAN security could be 802.1x. Sorry that I have no links available at the moment, but a quick search with Google or similar tool should be able to give a rough idea about it.

    • From a user's and non-WLAN network administrator's perspective, WLAN is a bit like traditional dial-up lines: non-permanent connections, one user might have several hosts (laptop, iPAQ). So you definitely want user-based authentication (perhaps even according to your already existing dial-up user database). As far as I know, all the WLAN security stuff is targeted to host-based security without proper key management protocols, which is not very interesting if you look at this perspective because even if it does provide some security, it is not using a practical scheme.

      Facing this kind of problems, our local university decided not to use WEP at all from the beginning, but an IPsec derivate (unfortunately with vendor-specific extensions for the user-based authentication).

  • Why did it take this long for people to get it? (Score:4, Insightful)

    by Anonymous Coward on Saturday September 01, 2001 @11:33AM (#2243079)
    It's really no different then plugging into a hostile, unswitched network. Trust no one! Sure, it's easier to "plug" into a wireless network, but you should never trust any traffic medium. Encryption all the way!

  • Cool...but... (Score:2, Interesting)

    by Multispin ( 49784 )
    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:)
  • This seems pretty straightforward to me.
  • Who didn't know this/wasn't doing this when they were using such an insecure protocol. With Cat-5, and least you are fairly safe from eavesdropping, they have to at the very least physically compromise security. But with anything wireless that is not the case, and I wouldn't trust that network with ANYTHING secure without all kinds of controlled access at both ends. I mean, DUH.

  • Re: insecure? (Score:5, Informative)

    by Bodero ( 136806 ) on Saturday September 01, 2001 @11:38AM (#2243100)
    I love how everyone is spouting "wireless is insecure" but give no real details on how that is.


    The real details are not too hard to find...30 seconds with a search
    engine came up with quite a few references, including:

    http://www.cs.umd.edu/~waa/wireless.pdf [umd.edu]

    That document contains a fair number of bibliographical references
    which you might find interesting.


    The principal problem I've found with wireless security is that lots
    of people deploy it poorly - effectively allowing anyone nearby to
    "plug" into their network. Most of the news articles about hacking
    wireless networking are about this kind of insecurity. The implication
    is that when you set up a wireless network you need to use WEP to
    encrypt the connection.


    Some of the more alarming articles suggest that WEP is weak, and so
    can't really be relied upon. If this is correct, then it means one
    must use encryption at a higher level - which is not a trivial
    undertaking. If you can't deploy IPSEC thoughout your network, you'll
    have to put your wireless access points outside of your firewall and
    use VPNs to get in.

    • WEP has been proven insecure. In fact, software is available now to automatically crack any WEP system by passive monitoring.


      Less clear is whether WEP must be insecure. I see no reason that a MAC-level protocol cannot be as secure as any other protocol. And WEP is based on a presumably secure encryption algorithm, which it uses poorly.

      • Beacuse it is possible to change your MAC address there is really no securuty in it, a bit like an IP address. It is also possible to sniff MAC addresses, even off encrypted traffic, so it would be easy to get a valid address.
        • If both users try to use the same MAC address
          at the same time, each will get NOTHING!
          • No.. you don't need a mac address to sniff traffic.
          • Ummm I don't think so. Both will get responses that were sent to either. I thought this was the key point of the 802.11 hack, that someone could not only sniff your network, but through MAC address forgery, could join it. DoS attacks against the base station, creating that inadvertant back-door to your LAN/AppleShare/SMB servers, etc. I suppose if someone had 10 base stations on a single network, one could DoS the 100Mbps copper on the other side. Yeah, yeah, switches you might say. I say all you have to do is target the IP of the file server, proxy or gateway, and game over.

            Tunneling seems to be the only immediate cure, but I was thinking...(laughs)...why not rewrite 802.11b firmware and drivers to reverse the bytes in a message before transmission, and unreverse upon reception. I know another data movement operation can be expensive, but it _is_ only 11Mbps worst case. Easy for even a 486 to keep up. This would at least thwart the capability of predicting that the first byte of every message is 0xAA. Obscurity, yes, and a bit of relief for the clueless home user. Even with a fix to 802.11b security, do I put the base stations outside the firewall? YES

            The funny thing is, now we install more wires just to go wireless.

        • MAC level can be secured by means other than simple MAC address screening. The key is to encrypt at the MAC level (as IEE802.11b does), but to do it well. 802.11b uses a private key, so if the key is chosen properly, and the encryption algorithm is strengthened (by using it right!), then one should not need any higher level protocols for normal security.


          Certainly even encrypted systems are susceptible to traffic analysis (putting together an org chart by seeing who talks to who), but that is rarely a threat in the commercial world.

      • I believe the answer is that WEP as implement in 802.11b is insecure. 802.11x (I believe x is correct) will add a new key exchange that is supposed to be secure.

        The real problem is that marketing wants 802.11 to be secure *and* easy to setup. Security is not easy. Sure the cryptography part is dead simple. It is all the parts around it that have to be equally secure that make it hard.

    • What you said is exactly correct. By using a radius server you can do a sort of transparent authentication, but that only stops people coming from the wireless to the wired network. The WLAN is still unprotected. The only way to truly secure a wireless lan is to treat it as unsecure and use a VPN.

  • Re: Bluetooth (Score:5, Informative)

    by Bodero ( 136806 ) on Saturday September 01, 2001 @11:42AM (#2243107)
    It's sure to give both Bluetooth, which was gasping for breath, and HomeRF, which was on a respirator, renewed leases on life. If the powerline networking gear arrives by year end and works as advertised, it will probably win the battle.

    Not really...

    802.11b is seeing high adoption rates in corporate networks. For better or worse, impenetrable security is not usually at the top of the list when choosing a network component. (ahem [sourceforge.net])

    By starting with a halfway decent basestation that allows for only registered MAC addresses to attach to it, then running some simple Vlan software (with or without WEP) you have an RF network that is as secure as most people *really* need it to be.

    As for Bluetooth, it's reaally not here yet, and it's intended for short-range devices that will most likely require lower throughput's than what 802.11b offers. HomeRF is a sort-of direct competitor, but it also has issues of it's own.

    With the right tools, and some dedication almost any simple network can be cracked. I remember when most people didn't know what "promiscuous mode drivers" were for, and many corporate LANs on simple 10M hubs were easily cracked by patching into an unsecured jack.

    802.11b is gaining a lot of press, and thus attracts more hacker efforts. I can almost guarantee that if HomeRF were the predominant wireless standard, we would be seeing the same hacker tools for it.

    • Re: Bluetooth (Score:2, Insightful)

      by fwr ( 69372 )
      You're kidding right? "registered only MAC addresses" security is a joke. It's such a management nightmare when you're talking about a significant number of users on a wireless network, think quite a few hundred to thousands of docs and nurses on a hospital network, that it's practically unmanageable. The only real solution is to use VPN technology. And what does VLAN software have to do with security? When you say that MAC address lists and VLAN software (whatever that's supposed to give you) makes an RF network as secure as most people *really* need to be you obviously are only thinking about breaking in and not just covert observation and data gathering. Think about HIIPA. If someone is able to gather packets on an RF network (which is relatively easy to do) then restricting which MAC addresses can get INTO the network is next to useless. The concern is people seeing confidential medical information going across the RF network, and limiting MACs does nothing to secure that information. I don't know how VLANs would help in this either. Sounds like you just through that word in there without knowing what you're talking about. And no, I don't think the 802.11b protocol can be "fixed" from a security perspective without making it an essentially new protocol that will not be compatible with all the existing equipment. Sure, it could be "backwards compatible" but then only new equipment would benefit from the enhanced security.

  • Working on something similar (Score:3, Interesting)

    by Mike Hicks ( 244 ) <hick0088@tc.umn.edu> on Saturday September 01, 2001 @11:44AM (#2243118) Homepage Journal
    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. (Score:5, Interesting)

    by davidu ( 18 ) on Saturday September 01, 2001 @11:52AM (#2243136) Homepage Journal

    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.
    • MAC's can easilly be spoofed, and to sniff the network you can do it passively, so the MAC check isn't even going to come into play
    • This solution, far from creative or unique, offers nothing in terms of aiding in the creation of secure PUBLIC networks.

      RTFA. The infrastructure has very little tunnelling. The login is encripted bia RSA encryption, and the only real tunnelling is done to allow one properly secured station to access the server via SSH.

      Forging mac addresses is trivial in most implimentations without going into promiscuous mode.

      I think that this is a good solution and shows good though and planning.

  • Not that new of a solution... (Score:3, Informative)

    by NetJunkie ( 56134 ) <jason.nash@CHICAGOgmail.com minus city> on Saturday September 01, 2001 @11:57AM (#2243149)
    Many people, me included, will put the access points outside the firewall and have the clients VPN back in to the network. This way you can disable WAP and just use the 3DES encryption of the VPN.
    • Definitely not new. The standard Nortel product configuration for secure 802.11b is to put the Baystack wireless access points on the one side of an encrypted VPN firewall (Nortel's Contivity product) and the corporate global WAN on the other.

      Sorry for the product plug (I do work there), but as other have pointed too, NASA hasn't "come up with a solution"; more likely they've read our (or our competitor's) data sheets.
  • Actually I'm in the process of setting up wireless gateways using a linux kernel, busybox, iptables, dhcpd and freeswan.

    The security comes from IPSec. It also works with OpenBSD (tho Open is hard to fit on a single floppy :)).

    Still not ready for public release tho :(
  • This is usually where I spout about OpenBSD, (hehe guess this is a setback for you BSD-Dying trolls...) but I wonder why/who choose OpenBSD? I've recently 'played' with the grsecurity patches for 2.4.9 and I like them. A lot of them give OpenBSD-ish features to linux, but some extend what OpenBSD currently provides. The only reason I bring this up, is that >2.9 (aka -current and future releases) does not have ipf. The pf project (OpenBSD's own packet filter) replaces ipf. But, 3.0 comes out in Decemeber....Wonder how it will all turn out....

  • Major league insecure (Score:3, Insightful)

    by Anonymous Coward on Saturday September 01, 2001 @12:13PM (#2243188)
    this "solution" is wide open to man-in-the-middle attacks. Tomorrow, I'll drive up there and setup my own DHCP server on their intentionally-WEP-disabled network. I'll hand out MY server's IP as the DNS server, and tell them to HTTP/HTTPS to MY server. I'll collect their usernames/passwords, send them a "site down for maintenance, try again later" message, and cruise through the real front door myself. Sheesh.
    • not quite sure how you are going to get your certificate validated to a nasa.gov domain via any certificate authorities - but yes... it is wide open to a man-in-the-middle attack.

      The problem as I see it for NASA in particular is that they probably support MANY client OSes. Thus making VPN difficult at best as many have suggested. I would not be suprised to hear that there were 95/98/NT/2000/MacOS 8/MacOS 9/MacOS X/Solaris/Linux clients that would all want to make use of the wireless network. It would be possible to support them all under multiple VPN products - but it wouldn't be cheap nor would it be management friendly.

      • Re:not perfect, but worth modding up... (Score:1, Interesting)

        by 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.

    • Yeah, and if you follow the link [nasa.gov] in the referenced article that gives details on the implementation, you'll see that they are dynamically adding ipf rules based on their Apache/PHP/SSL app. So they're letting anyone within range of the wireless AP play with an app that can potentialy open that gateway up to all kinds of traffic. The box has three interfaces, one each on the wireless, internal and "commodity internet". Thus the PHP app could potentially be subverted to open access to the internal net from the Internet.

      I'm implementing a hardware based VPN for our WLAN. As others have noted, that makes it hard to support multiple OS, though not impossible. I have Free S/WAN interoperation with the VPN using IKE preshared secrets, so that gives me Linux support. Now what we need is integrated IPSEC support from the WLAN vendors.
    • And if you configure your clients to accept DHCP info from only one server (IP/MAC)?

      Yes, I know both IP and MAC addresses can be spoofed but do you have any idea how blatently obvious it is when you stick two machines on one network (wireless or not) with the same MAC/IP address?

      "Man In The Middle" attacks are wonderful conversation pieces but good luck in finding any reported successes outside a controlled lab environment.

      Either way, combine their solution with both client and server certificates and you have a good solution that your "man in the middle" won't touch.

      Make people REGISTER to get an account and issue them a client certificate at that point.
    • "I'll just send a "server down for maintainence" message and walk right through their front door".

      Ha! That's where your fatal flaw will get you nailed in 10 minutes. NASA doesn't take servers down for maintainence at all! That's why they still run SunOS 4.1.

      Keep thinking like a logical tech, man, and you'll never break into their level. :>
  • I am with a company which is rolling out wireless Internet access via 802.11b and was considering doing something like this. 802.11b sucks for security, but there are definately many protocols for ip that you can tunnel though.
  • How is this news?

    The real "news" here is that NASA would find it appropriate to issue a press release on a project I would expect anyone half rational and competent to be able to figure out and implement in their sleep.

    "This just in from NAS NASA - We have succesfully patched IIS against Code Red thus developing the glue to keep our servers up and operational [editorial: for now]. More on this exciting development can be read at slashdot.org"

    Please... Spend my tax dollars telling me how close you are at getting me and countless others some time in space. Not on how your (notably horrible in security) NAS team has defeated the WEP weaknesses that everyone and their brother already knew how to get around.

  • MAC based security? (Score:2, Informative)

    by Laven ( 102436 )
    Please correct me if I am wrong, but is not MAC based security easily circumvented by simply changing the MAC address on your card? It is very easy to do with Linux and/or some vendor supplied setup programs.
    • MAC based security just means doing securiety at the MAC level - which is the level at which the entire 802.11b operates. For example, 802.11b encryption operates at that level.

      It should not be confused with simply filtering by MAC *addresses*.

  • They just build a network assuming people could sniff it.

    The principle should be the same for any network, especially reagarding anything going over the internet. Even a wired network is not 'secure'. Sure, there is the physical security element.... but one compromised host with a sniffer and you are in the same boat.

    Encryption is a good thing.
  • Who would of thought that was a news worthy item. I mean, a web based login interface, which firewalls you out if you dont have a working login and password. Completely innovative! In a wireless sense, this is called a Captive (or Active, I myself am not clear on the differences) portal. I cant believe they made a press release out of that, and that it took them 40 hours to make!!
  • I have not trusted wep for a long time ... I reciently reconfigured my home router/firewall so that the wireless bridge is on it's own interface.

    I treat it as a hostile (external) interface. If the connection is from a known IPsec peer, then I consider it a trusted internal connection.

    For the non IPsec connections I allow access to a few servces, mostly ssh and other crypted authenticated services.

    I have setup a easy way for me to enable forwarding from the wireless network to the outside, so that when a friend comes over with a 802.11b laptop, I open my wireless network to the outside, while the inside is restricted.

    Being able to do this is one of the advantabes of running a real system as a firewall/router than one of the "Firewall/routers for dummies" boxes.
  • Why, exactly, are so many people bitter, and therefore minimizing what NASA has done with their wireless network? Can't we just say, "Good for you, NASA" instead of the aimless negativity?
    Oh well, just my opinion.
  • And here I was expecting to see some government or corporate agency come up with the OTHER security solution...

    Have a company distribute sound or music over 802.11, and then have the company use the DMCA to take anyone who cracks the security, and bash them over the head with a big legal mallet.

    Either that or the military solution, to outlaw non-governmental, non-corporate encryption to the same end, bash in the head with the legal mallet.

    (similarities ('bash' vs '/bin/bash') to a popular shell merely coincidental.)

  • Here's a technical description on how they did it: http://www.nas.nasa.gov/Groups/Networks/Projects/W ireless/index.html [nasa.gov]

    It's pretty neat:
    You get your networking infos via DHCP. This gives you access restricted to public data.
    If you connect to their HTTPS web site and authentificate, this pokes a hole in the firewall and you get access to secured/private servers.

  • A real solution (Score:2, Interesting)

    by WestonP ( 59166 )
    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.
    • PPP over SSH isn't a very good solution when there's any packet loss (a definite possibility with wireless) since the two layers of TCP interfere. cipe is probably worth a look (NT and Linux).
  • Ok, reading what everyone says the only Secure method to use 802.11b is

    1. Disable WEP
    2. Put a firewall between your wireless router and network.
    3. Only allow the VPN ports
    4. Run a VPN client.

    Is this it? Doesnt sound too hard, and I have a 486 that would make a nice firewall. Humm, time to go pick up a wireless router now. :)
  • The whole idea of trusting the wire is a pretty bad one.

    http://seattlewireless.net/ [seattlewireless.net]
  • I'd go so far as to say it didn't take a rocket scientist to figure that out.

    Hoho!

  • The point is high usability / flexibility (Score:3, Informative)

    by nikpieX ( 518952 ) on Saturday September 01, 2001 @04:40PM (#2243738)
    As the developer of this system, I would like to add a few points that the news articles didn't make clear, or mis-stated. The reason why we have a wireless network is for conferences and visiting scientists. From the start, it was considered an external network to prevent access to sensitive data. Thus, we have to support any person walking in with any type of equipment (Macs, Windows, Linux, BSD, etc) without having them use any specialized software. This is all focused on how convenient it is for the person who walks in at 8 AM and has a presentation to do in 15 min. As long as they can figure out how to use DHCP and open up a web browser, nothing more needs done. So yes, we can do IPSec, VPN, and so on, but we also don't care as it's external to begin with. We simply do not want to become a "free ISP" like so many other companies are with their wireless.

    This device is indeed quite "common sense"; it is supposed to be. We searched for a vendor that provided these services (user accounting/authentication, dynamic firewall, etc), but didn't find any, so we simply built it ourselves. It does the job for what we need it to do in our environment.

    -Nichole
    (NASA Advanced Supercomputing Division)
  • Security is a continuing process. You have to work not only on the technical level, but also with people. That being said, I'd like to discuss a bit of security.
    Security is not implemented on a single level. The idea is that if you fuck up, there is a pretty good chance another level will catch you.

    Consider this wireless story. It's really not THAT terrible - if you are using secure protocols. The people that struggle, are those that trusted 802.11b to the point of thinking that was their only level of security.

    The fact is, a lot of security incidents stem from employees. They may be disgruntled or just curios. Whatever their motivations may be, it is a bit naive not to watch your back when dealing with coworkers. I'm not talking full-on paranoia, just using ssh rather than telnet on the intranet and measures to that effect. It's quite amazing what you can accomplish with a bit of elbow grease and a healthy mindset.
  • All of you who are spouting out "let's tunnel everything through ssl/ssh" obviously don't know too much about the real invulnerabilities out there. I hate to break it to all of you OpenBSD/ssh zealots out there, but ssh isn't secure. Anyone who has ever toyed with dsniff (www.monkey.org/~dugsong/dsniff) will easily tell you that it is possible (via man in the middle attacks) to monitor/kill/hijack ssh connections. It takes about 1 minute on FreeBSD to arp-spoof the network's gateway and seamlessly m onitor every packet going through it.

    SSH isn't the solution.

    derek/heyitsme
  • All these articles in the last few weeks sound like people actually did use WEP as the only means of security. They can't be that stupid, can they?

Slashdot Top Deals

"The four building blocks of the universe are fire, water, gravel and vinyl." -- Dave Barry

Close