Forgot your password?
typodupeerror
Security

"Port Knocking" For Added Security 950

Posted by CmdrTaco
from the thats-a-crazy-idea dept.
Jeff writes "The process of Port Knocking is a way to allow only people who know the "secret knock" access to a certain port on a system. For example, if I wanted to connect via SSH to a server, I could build a backdoor on the server that does not directly listen on port 22 (or any port for that matter) until it detects connection attempts to closed ports 1026,1027,1029,1034,1026,1044 and 1035 in that sequence within 5 seconds, then listens on port 22 for a connection within 10 seconds. The web site explains it in some detail, and there is even an experimental perl implementation of it that is available for download. I can't think of any easy ways you could get around a system using this security method - let alone even know that a system is implementing it. Another article on port knocking is here."
This discussion has been archived. No new comments can be posted.

"Port Knocking" For Added Security

Comments Filter:
  • by djh101010 (656795) on Thursday February 05, 2004 @03:04PM (#8192325) Homepage Journal
    Something tells me I'm going to be seeing a lot bigger firewall logs in the future, as this catches on.
    • Good luck doing this through NAT. You'd have to configure your machines to act like a NAT device as far as refusing connections or else you could be port scanned to figure out which ports to knock on.
      • by RollingThunder (88952) on Thursday February 05, 2004 @03:24PM (#8192691)
        Actually, an interesting potential of this is to have you "knock" at the NAT gateway. Proper knocking opens up a given service and knock ports to an internal system.

        Different knock patterns at the NAT open you to different internal hosts. Quite interesting possibilities there.
        • by WNight (23683) on Thursday February 05, 2004 @05:59PM (#8194814) Homepage
          You can also open up inbound ports from specific external IP addresses only, and do many at once. So ten inbound connections can reach ten different internal webservers, and at the next request, reach the same one again.

          This can be done dynamically as a form of load balancing which is a neat hack. Expire the specific forward rule after 30s or something. Means similar requests cluster - less DB traffic.

          But, combine this with knocking and you've got the next step. Secret services on a 'stealthed' IP, where you can request which quake server (for instance) by knocking in a different way.

          Port scanning isn't what it once was. Especially once you factor in time-sensitive keys (easily doable - both machines need a net connect to reach each other, ntp is then trivial) and ID-sensitive keys (so my key isn't like yours, even at the same time). Even if you managed to snoop on a 'knock' you couldn't repeat it.
  • not bad (Score:5, Insightful)

    by maelstrom (638) * on Thursday February 05, 2004 @03:05PM (#8192339) Homepage Journal
    But it does seem like a layer of obscurity to what should otherwise be a secure port. What if someone is sniffing your network? Unlike an encrypted password, they could easily replay this sequence and gain access to your "hidden" port.
    • Re:not bad (Score:5, Interesting)

      by Kenja (541830) on Thursday February 05, 2004 @03:06PM (#8192374)
      "But it does seem like a layer of obscurity to what should otherwise be a secure port. What if someone is sniffing your network? Unlike an encrypted password, they could easily replay this sequence and gain access to your "hidden" port."

      And? It is still more secure. By using "port knocking" they HAVE to sniff out your network traffic and find the port combo. Without "port knocking" they just need to run nmap and see what ports they can try to attack.

      • I've always been curious of packet sniffing but really never investigated it indepth. Would the person who wants to sniff your network be on the same subnet or have access to some major hub? ie, How is a guy in Russia going to sniff and find the right port combo if the server is in Seattle?

        Wouldn't he have had to hack a computer closer to his target in order to be successful?

        Wouldn't the best option be to have some type of SecurID based password in order to access the port? Unless there is a bug or

      • Re:not bad (Score:5, Informative)

        by ComputerSlicer23 (516509) on Thursday February 05, 2004 @03:34PM (#8192820)
        But it's not as secure as not running SSH.

        Hence, weather or not it is secure, is all a matter of opinion. Personally, I think if you can't run SSH out in the open, you shouldn't run it thru an obscurity filter.

        We have no SSH configured on our outside network. Not with OTP, not from only allowed IP's. Not from only a specific port. Not with KnownHosts only. Not with known RSA keys only.

        You want on, you've gotta be in the building. It'd be nice to fix problems while remote, but it's just not an option because of the security problems it presents. I live within a mile of the building, specifically so not having remote access isn't a big deal. I can go from sleeping in bed, to in the building in less then 10 minutes. It's a pain for small problems. However, it's small issue in comparison to dealing with a full blown network breakin due to SSH.

        On occasion, I believe we have had someone local build an SSH tunnel that we can VPN thru onto our network. However, someone who already had access had to initiate the connection by hand with the correct IP. That's only allowed if we voice authenticate from you.

        Kirby

    • Re:not bad (Score:5, Interesting)

      by LostCluster (625375) * on Thursday February 05, 2004 @03:11PM (#8192446)
      Think of it this way... it's an extra password combined with bonus security-by-obscurity of not having a visible password prompt.

      The "knocking ports" could also be configured that if there are random hits to the standard port without the proper knock, the system could lock down for 30 seconds and even ignore the proper knock so that if somebody's trying to brute force all the possible knocks, they'll never get feedback when they have the right one.

      Yeah, this is no substitute for properly securing the original service, but it's an extra layer that means there's even more that needs to be captured for a successful hack...
      • Not good (Score:5, Insightful)

        by glpierce (731733) on Thursday February 05, 2004 @03:12PM (#8192470) Homepage
        "The "knocking ports" could also be configured that if there are random hits to the standard port without the proper knock, the system could lock down for 30 seconds and even ignore the proper knock so that if somebody's trying to brute force all the possible knocks, they'll never get feedback when they have the right one."

        That would just create a new variant to DOS attacks. Instead of taking you offline, they just persistantly knock on random ports, thereby disabling your ability to communicate with trusted sources.
      • Re:not bad (Score:5, Interesting)

        by Jerf (17166) on Thursday February 05, 2004 @03:42PM (#8192945) Journal
        ignore the proper knock so that if somebody's trying to brute force all the possible knocks, they'll never get feedback when they have the right one.

        Re "brute forcing"... the number of possible knocks is (ports used for knocking) ** (ports in knock sequence). Yes, that's exponentiation.

        In fact, I'd suggest making the knock sequence much longer then in the article; ten might be good. Then, if you allocate 100 ports to the knocked and randomly select a 10 port sequence for the knocking, you get 100 ** 10 possible knocks, or 100,000,000,000,000,000,000 (100 sextillion) possible knocks.

        With just a few more ports in the sequence and just a modest investment in ports, you can make brute forcing impossible.

        (And if you mix up the ports so they aren't sequential and the attacker has to guess THOSE ports, it goes to approx. (2**16)**(number of knock), so for a 10-port sequence on potentially all TCP ports it's 1,461,501,637,330,902,918,203,684,832,716,283,019, 655,932,542,976 possible knocks, a.k.a. "way the hell more then can be brute-forced".

        (I love posting big numbers on Slashdot.)

        You need to worry about sniffers way more then brute forcers. (And as this is another layer of security, hopefully on top of an already fairly secure protocol like SSH, it's a good thing; now the 'man in the middle' has to have advanced knowlege to even know there's something to get into the middle of!)
        • Re:not bad (Score:4, Insightful)

          by poot_rootbeer (188613) on Thursday February 05, 2004 @06:05PM (#8194890)
          In fact, I'd suggest making the knock sequence much longer then in the article; ten might be good. Then, if you allocate 100 ports to the knocked and randomly select a 10 port sequence for the knocking, you get 100 ** 10 possible knocks, or 100,000,000,000,000,000,000 (100 sextillion) possible knocks.

          And this number is only relevant if the attempted cracker knows your knock sequence is exactly 10 ports long. Add or subtract a couple steps from the sequence, and the number of possibilities increases factorially.
    • by jsonic (458317) on Thursday February 05, 2004 @03:12PM (#8192469)
      The shady side of hackerdom has been using this very technique to hide their backdoors from port scanning admins. Or, uh, so I've heard...
      • not so shady... (Score:5, Interesting)

        by Hubert_Shrump (256081) <cobranet AT gmail DOT com> on Thursday February 05, 2004 @03:47PM (#8193010) Journal
        i've been running SSH on a nonstandard port with this in the way:


        iptables -N ${SSH_TABLE}
        iptables -Z ${SSH_TABLE}
        iptables -A ${SSH_TABLE} -m state --state NEW -m limit --limit 2/minute --limit-
        burst 2 -j DROP
        iptables -A ${SSH_TABLE} -m state --state NEW -m limit --limit 7/hour --limit-bu
        rst 7 -j DROP
        iptables -A ${SSH_TABLE} -m state --state NEW -m limit --limit 10/day --limit-bu
        rst 10 -j ACCEPT
        iptables -A ${SSH_TABLE} -j DROP


        well, I thought it was cool...
    • Re:not bad (Score:3, Informative)

      by RealityMogul (663835)
      Of course you could also have a new combination generated every minute for the super paranoid.

      But I don't think the intent is to prevent people sofisticated enough to actually sniff packets from being able to enter the network, but simply stop script kiddies and worms that are rather mindless in their attacks. I am not aware of any worms that would be able to sniff packets and actually interpret what is happening.
      • Re:not bad (Score:3, Interesting)

        by orthogonal (588627)
        Of course you could also have a new combination generated every minute for the super paranoid.

        No, if you were "super paranoid" you'd have two identical one-time pads, one residing on the computer to be accessed, one in the hands of a single person trying to connect.

        Every minute, the computer would consult its copy of the pad to determine what that minute's secret knock sequence would be.

        The person connecting would look up in his copy of the pad that minute's sequence. You'd need to synchronize both part
    • Re:not bad (Score:5, Interesting)

      by 26199 (577806) * on Thursday February 05, 2004 @03:13PM (#8192488) Homepage

      Hmm, lots of people have pointed this out, but it's easy to set up a system of one-time passwords... provided it's done in a cryptographically secure way, there's little point in sniffing for combinations.

      Of course, you can still sniff to see what ports are actually in use...

    • Re:not bad (Score:3, Informative)

      by mugnyte (203225) *
      No, not really. If the pattern changed each time, or access-counts, no two sequences would be the same. Add in a larger set of sequences, with some salt, and you get something analogous to encryption, it seems.
    • Re:not bad (Score:3, Funny)

      by tommck (69750)
      Rather than sniffing her network and replaying sequences, why not just buy her dinner to gain access to her "hidden port"?
  • My idea (Score:5, Interesting)

    by Catskul (323619) * on Thursday February 05, 2004 @03:05PM (#8192347) Homepage
    I though about this along time ago as a way of hiding a trojan. Of course I didnt patent it so no money for me : /
  • Beavis? (Score:3, Funny)

    by tommck (69750) on Thursday February 05, 2004 @03:05PM (#8192356) Homepage
    Am I the only one who heard Beavis say "Port Knocker!"?

    Probably...
  • Easy enough... (Score:5, Insightful)

    by wishus (174405) * on Thursday February 05, 2004 @03:06PM (#8192357) Journal
    I can't think of any easy ways you could get around a system using this security method - let alone even know that a system is implimenting it.

    Sniffing.
  • Worse? (Score:4, Interesting)

    by glpierce (731733) on Thursday February 05, 2004 @03:06PM (#8192371) Homepage
    Right now, script kiddies have their computers automatically try to access other peoples' computers, looking for ones without firewalls, etc.. If this happens, wouldn't you expect them to just send out random knocks in the hopes of getting something? If that happens, you will be more secure personally, but the increased traffic may cause more problems that it solves.
  • by bc90021 (43730) * <bc90021@bc90021S ... net minus distro> on Thursday February 05, 2004 @03:06PM (#8192372) Homepage
    Knock knock...

    Who's there?

    Usher.

    Usher who?

    Usher wish I could SSH to your server!

    Sorry... ;)
  • by sleepingsquirrel (587025) * <Greg,Buchholz&sleepingsquirrel,org> on Thursday February 05, 2004 @03:07PM (#8192378) Homepage Journal
    Interesting. So the next step would be to have one-time port knock sequences a-la one-time passwords (to defeat adversaries who are grabbing a copy of all your packets). But it seems like there is a race condition between the delay after the knock and the actual connection. Anyone have a solution to this?
  • by pclminion (145572) on Thursday February 05, 2004 @03:07PM (#8192380)
    This adds a layer of obscurity to a security policy. It can't substitute for security, but it certainly can help.

    An analogy would be a military base with a ten-foot-thick steel blast door. This is like having a door that teleports around at random, which can only be frozen in one spot by speaking some magic word. Even if you know the word, you still don't have the key to the door. But if you do have the key, you still can't get in without the magic word because the door keeps teleporting around.

    Obscurity is great, if it is part of a layered security policy which is ultimately based on strong cryptography. This is a really cool idea!

    • It's called a secret knock and that's the best analogy you could come up with? Perhaps it's more like a ten-foot-thick steel blast door, but you can't even see the keyhole unless you knock on it just the right way?
    • by CedgeS (159076) on Thursday February 05, 2004 @03:22PM (#8192658) Homepage Journal
      There is only one form of security for a publicly accessible interface: obscurity. What is a password? It is a piece of information that you know that someone else doesn't - it is obscurity. The key to your house is something you have that someone else doesn't. If they knew the obscure details of your key they could make one. What is a private key, a key for SSH, a kerberos function? They are all information you know which (hopefully) a potential attacker doesn't. This is obscurity.

      If you have a security system for a public interface (the front door to your house, a computer port, etc...) that does not rely on obscurity you have a system better than any theoretical system anyone has ever thought of. (Biometrics don't count - they are just another piece of information that you have that someone else probably doesn't. That's obscurity.)
      • by cheezit (133765) on Thursday February 05, 2004 @03:39PM (#8192902) Homepage
        I think you are overreaching here. As far as I'm concerned, the phrase "security through obscurity" means obscurity of system design. If you don't tell anyone about your unprotected resource, that's security through obscurity. All I need to do is discover your resource.

        Most security is based on secrets of one kind or another---that doesn't make it "obscurity."
      • by Xenographic (557057) on Thursday February 05, 2004 @03:56PM (#8193159) Homepage Journal
        We usually call such a thing a secret, not "obscurity" ... at least, when talking about a password.

        So this just makes part of the protocol secret, and one of our assumptions about security protocols is that the protocols are known.

        Yes, it's an interesting and reasonably clever little hack (it is not, however, new), it does tend to hide some information (e.g. that the ports are even open) but if you're going to make the port look closed, anyhow, why not just listen on that port for something that would cause the service to "wake up"? I guess they thought it seemed a bit more clever the other way, who knows?
  • Old stuff (Score:5, Funny)

    by Britz (170620) on Thursday February 05, 2004 @03:07PM (#8192386) Homepage
    That is a very old method i developed with my friends. We would only open the door after a "secret" knock sequence. We had seen this on TV and thought this would be cool. We jeopardized the security regularly when we said "wrong knock" after someone else knocked. Usually parents. Then they would say "open up". And we had to comply.
  • by crow (16139) on Thursday February 05, 2004 @03:08PM (#8192401) Homepage Journal
    I was thinking about implementing this a while ago; I guess it's an obvious enough idea that others have been thinking along the same lines. This is equivalent to to putting a password on access to the port.

    Ideally, the implementation will only consider connection attempts originating from the same IP address.
    • by pla (258480) on Thursday February 05, 2004 @03:41PM (#8192927) Journal
      This is equivalent to to putting a password on access to the port.

      This seems much better than a password, I would think (Though I certainly would still use a password as well).

      As an analogy, if you want to get into a house, and find a locked door, you have a few options... You can try one of those M x N position key blanks, which will take a very very long time (exhaustive search). You can try to pick it (exploit a weakness in the password algorithm). You can try to get ahold of a copy of the real key (packet sniffing, "shoulder surfing", etc). But you have no doubt that somewhere, a key exists that will open that door.

      Now compare that to a solid block of concrete, roughly the size of a house. What does it do? Do helicopters land on it? Does it cover something, or hold something down? Does it have something sealed inside it? You'd never suspect that that, if you utter the magic phrase "Sim sala bim bamba sala do saladim", a door will appear in the side of this large concrete block, allowing those with a key to gain entrance.

      The main difference involves knowing whether or not a way in exists. With just a passworded port, an attacker knows that enough effort will pay off. Adding in port knocking, that attacker doesn't know whether or not their hard work can ever gain them entrance, since a port might well not exist.


      Now, in my opinion, the more interesting question here involves how to hide this from one's ISP (ie, make it snoop-proof).
  • I see an easy way (Score:4, Insightful)

    by Apreche (239272) on Thursday February 05, 2004 @03:09PM (#8192406) Homepage Journal
    There is an easy way around it. The problem is you will make yourself very obvious. Simply pick a time at which the server in question is in high use. Hammer the port. Eventually someone will knock on the door opening it for 10 seconds and you put your foot in the door before they do. The other way is if you can get a packet sniffer simply look at the packets that came before and determine the secret knock.

    This is still an interesting idea and definitely has at least a few places in which it would be an effective authentication mechanism.
  • by Fulkkari (603331) on Thursday February 05, 2004 @03:09PM (#8192407)

    Is the site slashdotted...

    ...or do I have to knock my way in?

  • Silent Bob (Score:5, Informative)

    by Sanity (1431) * on Thursday February 05, 2004 @03:10PM (#8192425) Homepage Journal
    A few years ago Freenet implemented something similar to this called "Silent Bob". The name comes from Alice and Bob, the names given to sender and receiver respectively when describing cryptographic protocols.

    The idea was that you didn't want to disclose that you were running a Freenet node unless the person connecting to you already knew your node's public key.

    So when someone wants to establish a connection to you, they must send some encrypted data providing they know your public key. Your node can receive this data and only respond if it is correct. Furthermore, you could let your Freenet node sit on port 25, for example, and forward invalid connection attempts to a mail server on a different port.

    Through this mechanism, your Freenet node could quite effectively hide behind another server, only making itself known to those already part of the Freenet network.

    IIRC this wasn't actually implemented in Freenet, but it is the intention to add it at some point. Still, it is amazing how many ideas were pioneered by Freenet years ago and are only showing up in the wider public conciousness now.

  • by 3Suns (250606) on Thursday February 05, 2004 @03:11PM (#8192452) Homepage
    It should be noted that this is NOT (necessarily) an example of security through obscurity. One could treat the port-knocking sequence as a "key". Long enough keys could make port-scanning impossible for anyone who doesn't know the key. Real mathematical cryptography is based on a similar principle.

    Also, this is only a defense against port-scanning. Even if someone did manage to break the knocking sequence, they would still have to use some kind of exploit against the machine on the port they discovered.
  • Possible problems (Score:5, Interesting)

    by Mr. McGibby (41471) on Thursday February 05, 2004 @03:14PM (#8192502) Homepage Journal
    What if multiple attempts from the same IP are made to access the port at the same time? Wouldn't the knocks get all mixed up?
  • Great for SSH (Score:3, Interesting)

    by zulux (112259) on Thursday February 05, 2004 @03:14PM (#8192504) Homepage Journal


    OpenSSH is a great peice of sodtware - but it's so huge that I can't help but think that their could be flaws in it (like the one of 6 months ago)

    I would love to layer another peice of security infront of OpenSSH and this seems like a great idea.

  • Reverse-knock (Score:5, Interesting)

    by Seft (659449) on Thursday February 05, 2004 @03:14PM (#8192505)
    Has anyone implemented a system where a service would be stopped if the ports next to it were scanned? i.e. if 1024, 1025, 1026, 1027 were scanned, a service running on 1028 would stop.
  • Implementations? (Score:3, Interesting)

    by crow (16139) on Thursday February 05, 2004 @03:15PM (#8192510) Homepage Journal
    Could this be implemented with IP Tables under Linux? I remember seeing a set of rules to detect a port scan; could a similar set of rules be used to unlock a port for a given remote IP number?

    Of course, this won't take off unless there's also knocking support built into the clients (like ssh).
  • by Dominic_Mazzoni (125164) * on Thursday February 05, 2004 @03:18PM (#8192568) Homepage
    As everyone else is saying, this is just security by obscurity. That doesn't mean that you shouldn't use it, because it probably would help a lot in keeping out script kiddies and casual hackers. But the flip side, as always, is that you're giving yourself and your users a false sense of security when you pretend that measures like this will actually prevent motivated hackers from getting past it.

    The most obvious way to break into a system like this is to compromise a nearby machine first and install a packet sniffer. Once you can see the traffic to the host running this port knocking system, it would be easy to discover the pattern. In fact, port knocking is less secure than a lot of other nonstandard authentication mechanisms because you could figure out the secret simply by looking at packet headers (since they contain the port numbers).

    The other problem I see with this system is that it requires users to either memorize the secret knock, or use a program that automatically knocks for them. Since most people have a hard time even remembering all of their usernames and passwords, you'd see a lot of people writing down the knock, sending it via email, or writing scripts to knock for them. Dozens of opportunities to a hacker, especially one skilled in social engineering [amazon.com], to figure out the knock.
    • Sure, it's breakable. But once they have broken the knock, they still have to get past the regular, strong, security. It's a layer of obscurity, but it is on top of the existing stuff - whatever happens you will remain at least as secure as you were before.

      The vast majority of s'kiddies will just scan 22, see there's nothing there, and move on to the next host. There will _always_ be far easier targets for them to attack. Why waste their time trying to guess my knock?
  • hmm... (Score:5, Interesting)

    by Kitsune (8349) on Thursday February 05, 2004 @03:19PM (#8192606)
    Improperly done, the knock sentry could become a security/QOS issue in itself.

    This definitely is security through obscurity and perhaps would work in the same way as a car alarm. There's lots more systems out there that are easier to break into, and if someone does try, just hope that they get fed up and moves on to the next one.

    If you've gone this far, why not do something like they do on radio. Open up severable ports at the same time and multiplex your signal over several of them while sending noise over the ununsed ports randomly switching between ports using a syncronized random selector.
  • go a step further (Score:5, Interesting)

    by Casca (4032) on Thursday February 05, 2004 @03:20PM (#8192623) Journal
    Implement it in combination with a onetime type password arrangement. You look up what the series of knocks is supposed to be on your secureID card (or whatever), then knock in the combination it tells you to use. Tie it in with the server you want to get into, and the port you actually connect to for ssh can be different every time.

    IE, secureID says sequence is "1234 1441 1114 5123", you knock on the first three, and 5123 is the ssh port activated for you only.
  • Slashdotted (Score:4, Funny)

    by BlueTooth (102363) on Thursday February 05, 2004 @03:25PM (#8192700) Homepage
    Does anyone know the secret knock for www.portknocking.org:80 ?

    Thanks.
  • by ifreakshow (613584) * on Thursday February 05, 2004 @03:25PM (#8192704)
    One interesting way to use this would be to forward incorrect knocks to a honeypot instead of the legitamite service. Then the attacker could never determine if he had indeed knocked successfully and would waste time running around in a fake system giving you valuable data about there intrusion methods and freeing up the actual service for legit users.
  • Christ people! (Score:5, Informative)

    by Stonent1 (594886) <stonent@NOsPAm.stonent.pointclark.net> on Thursday February 05, 2004 @03:26PM (#8192714) Journal
    How many people are going to say sniff and repeat the sequence. You still have to get through the service after it opens. The whole point is that they don't know what is going on in the first place. And rotating keys are a good idea anyway. I like this idea for running some kind of server behind your ISP that normally doesn't allow such things. When I had excite@home I would regularly get firewall logs that said "authorizedscan.home.com" portscanning me.
  • by cr@ckwhore (165454) on Thursday February 05, 2004 @03:32PM (#8192795) Homepage
    Interesting concept... I thought of this 2 years ago and I'm now kicking myself in the balls for not acting on it! (not literally)

    In my version of "port knocking", everything was going to be controled via ICMP echo packets.. aka "ping".

    A single Ping packet can contain arbitrary data of an arbitrary length less than 64k. Through a config file, the system admin could define ping sequences using time, data, and/or packet size, along with a specified script to execute on each successful reception of the ping sequence.

    Then, remotely, people who know the ping sequences could use almost any available ping utility on any machine to open remote ports, etc.

    The concept of executing a script, rather than opening or closing ports, allows for more flexibility. Not only can the admin open and close ports via scripts, but could do other useful things.
  • Negative knocking (Score:4, Informative)

    by hey (83763) on Thursday February 05, 2004 @03:38PM (#8192893) Journal
    Let's say the correct squence is ports 2000, 2002, 2004. You could add a check that says if there is a knock on port 2001 or 2003 then this guy is locked out for a while.
  • by amplt1337 (707922) on Thursday February 05, 2004 @03:40PM (#8192924) Journal
    on debian-security a couple of months back.

    Anyway, one of the biggest problems is failure rate. If that "secret knock" fails unless you correctly use the appropriate sequence of knocks, then anyone malicious can implement a trivial denial-of-service attack just by constantly hitting random ports, preventing any knock completion.
    Alternatively, if you ignore non-knockable ports, or ports that aren't part of the knock, then you've dramatically whittled down the strength of your virtual password, and made it that much easier to brute-force.
    Perhaps this would deter some of the lowest levels of sk|21p7 |<1dd13z from getting in, but that would be true only for about two weeks, whereupon new toyz are released that automate these attacks, and you've given the black hats one more weapon (DoS through spoofed noise packets) in the meantime.

    I guess if you really, really wanted to do this, you could have a single accessible port that would listen for access, and then receive an encrypted key that determines which other port your server opens for a possible connection. But basically all you're doing then is adding on another layer of password protection, whose effect will be circumvented when somebody finally decides it's annoying to have to login twice or enter multiple passwords, and sets them both to the same thing, on auto-login, then leaves his laptop sitting around for three minutes. And you've still not fixed the sniffing problem. There are bigger security soft spots to be addressed than trivially hiding access to your ssh port.
  • by Samuel Nitzberg (317670) on Thursday February 05, 2004 @03:41PM (#8192928)
    This looks similar to how frequency-hopping is used on secure radios.

    Two radios synchronize, based on a key, and both change frequency every so many milliseconds. If you don't know the key, you can't send or receive to either of them.

    I would like to see this extended to a port-hopping system for all ports and services. Sure -- it will burn some clock cycles, but I like the approach.

    - Sam
    http://www.iamsam.com
  • by cytrox (712254) on Thursday February 05, 2004 @03:41PM (#8192936)
    This method is already used by the proof-of-concept linux backdoor cd00r [phenoelit.de], written in 2000.
  • Since the client gets no feedback on whether the packets made it, there's no way to check if it worked except to see if the "magic" port has been opened.

    This system is going to be unreliable. No way around it. A single dropped packet and you have to try all over again. If you're really paranoid, like some have proposed, and disable the "knock monitor" temporarily if someone tries to connect unsuccessfully, it will also be horribly slow.

    If you use it on a LAN, maybe the net will be reliable enough, but then you have to worry about sniffers...

  • by Vellmont (569020) on Thursday February 05, 2004 @04:15PM (#8193427)
    Everyone has focused on the "does it make you more secure" arguments about this method. I'd be more interested in how it can be implemented properly since no TCP connection is being established using the knocks. I'd assume either a TCP SYN is being sent to the TCP ports, or the protocol uses UDP.

    The problem is of course that since no connection is being established, there's no guaranteed delivery of packets, and no guaranteed delivery of packets in the order they were sent. This could be very problematic across network connections that drop packets, and provide you no feedback as to why you can't open your connection. If only 10 % of my packets get dropped, and I require 10 "knocks", I only have .9^10, or 35% chance of my sequence getting to its destination intact. 5% packet loss would up my chances to about 60%. Increasing amounts of knocks decreases my chances of the sequence arriving intact.

    Is there a clever way to solve this problem, or is the reliability of it tied to a low amount of packet loss on a network?
  • by jdreed1024 (443938) on Thursday February 05, 2004 @04:18PM (#8193480)
    I see a lot of comments saying "Well, why not just have two passwords?". It seems that people didn't read the article (the first link is /.ed, the second is not). The whole point is that with this, until you knock, the machine appears as a closed machine. No ports open. All ports will simply drop packets on the floor, meaning that a hacker scanning your subnet will not bother with that machine. The machine essentially appears invisible until knocked. Even with the most secure system, the hacker can still see that you're running, say, sshd, Apache, CUPS, and a few other services. And if a buffer overflow was announced 5 minutes ago for, say, sshd, they know that they can attempt to exploit the machine, since they see port 22 open. If you are using Port Knocking, you can have a vulnerable sshd, and it's a hell of a lot less likely to get exploited since the cracker has no way of knowing that you're running sshd...
  • by Tom7 (102298) on Thursday February 05, 2004 @04:18PM (#8193484) Homepage Journal
    God damn, if I hear one more of you go, "this is just security through obscurity!" I am going to puke. This is the same as cleartext passwords, which are pretty secure if (a) you know nobody is sniffing the network and (b) you know nobody is masquerading as the host you want to connect to. Of course those things aren't typically true, so this alone isn't very secure. But it does disguise your exchange which, contrary to what the security-through-obscurity folks are saying, does give you some small measure of security.

    This is just a way of encoding some bit transfer in the IP protocol instead of in the beginning of whatever protocol you're using after the connection. You could also use it to send cryptographic credentials which could be as secure as any other protocol (plus some extra security by obscurity). The only problem with that is that you need a way to send back information via TCP (because most good authentication protocols are two-way), but I think you need that anyway in order to serialize your knocks.
  • by phoenix321 (734987) on Thursday February 05, 2004 @05:11PM (#8194214)
    This is security by obscurity, but it is useful. Don't repeat this mantra just because "the experts" say so.

    Since some still don't understand its use, i'll be speaking metaphorical:

    Assume you need to have a special key to open a certain otherwise secure door. OpenSSH might be that door and your passphrase and your certificate are the key.

    An attacker can still forge the key or attack the lock with a different approach, picking etc. - comparable to "social engineering" to get the password, brute forcing or exploits.

    And that port knocking sequence now effectively hides the lock, leaving an attacker without a first approach to pick or break the lock. It just adds another layer of security. You just don't know where to start your attack. You can't use exploits, you can't try brute force - nothing, heck you don't even know what type of daemon your target is.

    A clean stainless steel door with a covert RFID-detector one square inch in size, hidden somewhere, sure as hell beats the same door with a clearly visible lock. You still need to pick the lock, but you can't poke your lockpicking tools into solid steel and you can't crack something you cannot discern.

    --- Still one addition to say: having a machine connected to the internet with no ports open makes you a prime suspect for the port knocking scheme.

    A good stealth scheme may be implemented, so a potential attacker (excuse for this metaphor again) does not even see the door (or the building, for that matter).
  • gettyps (Score:4, Informative)

    by Michael.Forman (169981) * on Thursday February 05, 2004 @05:27PM (#8194453) Homepage Journal

    Kris Gleason implemented a similar scheme in his gettyps code back in the 90s (it still available and in most distributions). For the "knock" one would dial into a modem (or any serial port) and let it ring a specified number of times. If the right number of rings was received before disconnect, gettyps would allow the next call to connect.

    Michael. [michael-forman.com]
  • by Skapare (16644) on Thursday February 05, 2004 @05:45PM (#8194681) Homepage

    I did this about 5 years ago. But my method was a bit different. Instead of using port numbers to contain the information (and that's all it really is, is just information), I sent a single UDP packet, with a source port of 53 (so it looks like a DNS answer), formatted like a DNS answer, that contained the information in the DNS answer data. Then it opened the SSH filter for that IP address to come in (I did it for 5 minutes, not 10 seconds). It still had to fully authenticate via SSH, so even if someone sniffed my DNS packet and tried to fake it, they could at most have a locked door to jiggle the handle on. Next time I do this, it will be to generate an MD5 checksum from the client IP and a secret salt, and send that as an IPv6 address in the packet. Then it can't even be faked from some other IP address.

  • by henrypijames (669281) on Thursday February 05, 2004 @05:46PM (#8194693) Homepage

    What if I turn this whole thing around and install fake services on a number of ports?

    For example, whenever you make a connection to a port between 1025 and 2048 on my system, you're greeted with "OpenSSH ...", and prompted to authenticate. But only behind one among those 1024 ports is the real SSH. On any other port, the fake service takes the username and password you've entered, wait a few seconds (just idling around), and tell you "Authentication failed". If you try too often to connect to faked services, you're put on the black list to avoid DOS, of course.

  • by jelle (14827) on Thursday February 05, 2004 @05:58PM (#8194811) Homepage
    This is a neat trick, but it does not really increase protection against targeted attacks.

    It really is nothing more than a password to get access to the front gate... When somebody eavesdrops (sniffing), they will know the passwords, thus get access to the gate. They can sucessfully detect the knocking sequence because it is followed by a successfull ssh connection (duh!).

    The password is this 'secret sequence' in this 'port knocking'. Why not just use a daemon that listens on a UDP socket for a packet with an encrypted password in its payload? The payload could even be an RSA-signed and/or encrypted request (that includes a timestamp). That would be unscannable too, because UDP is connectionless, and be a lot more secure because of the real encryption/protection of the request data (the server can verify the identity of the sender of the request from the RSA signature, and can deny the request if one was made earlier with the same time stamp, twarting even sniffing of the UDP packet).

    Except for not having the ssh daemon 'connected' to the internet at all times and thus evading many port-scanning worms/scripts, this port knocking is nothing more than just some security through obscurity: At best it will delay the attacker somewhat, but probably not at all while giving the user a false sense of being secured.

  • by firewood (41230) on Thursday February 05, 2004 @09:32PM (#8197053)
    This is a great idea.

    It adds security to any existing methods (passwords, etc.).

    It can be implemented behind a firewall that doesn't even respond on any port probes, so an attacker can't even tell if the firewall was just unplugged.

    If the firewall stays closed, the protocol can't be used by an exploited machine, unless a method for exploiting the firewall is also known.

    Or the method can be implemented in user space of a machine behind a completely closed firewall, just by pre-arranging for the logging of firewall port probes, and the forwarding of appropriately filtered contents of the firewall logs into user space.

    They key sequence can also be made long enough to make it just as hard to crack as a long pgp private key, e.g. nobody except (3 letter agency) and distributed.net will even bother to try.

    The sequence key can be from a one-time pad, meaning that even if the protocol is completely revealed to a local sniffer, they'll just end up with a useless password.

    And lastly, it's possible to additionally encode the key sequence with a modulation wrapper and enough redundancy to withstand a given signal to noise ratio and mis-sequencing rate, which means one could even make the sequence key usable in the face of probing or an outright DoS attack against the protocol up to a certain attack bandwidth and knowledge of which ports might be in the sequence.

    Where's my coding textbook and patent attorney...
  • by wolfdvh (700954) on Thursday February 05, 2004 @09:57PM (#8197226)
    For all of you arguing that port knocking is security through obscurity, please take a couple minutes and read this article from the site:

    http://www.portknocking.org/view/about/obscurity [portknocking.org]

    It does a much better job of explaining this than anything yet posted here.

As of next Thursday, UNIX will be flushed in favor of TOPS-10. Please update your programs.

Working...