Slashdot Mirror


"Port Knocking" For Added Security

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

47 of 950 comments (clear)

  1. Well, there go the logfiles by djh101010 · · Score: 3, Insightful

    Something tells me I'm going to be seeing a lot bigger firewall logs in the future, as this catches on.

    1. Re:Well, there go the logfiles by trompete · · Score: 2, Insightful

      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.

    2. Re:Well, there go the logfiles by Frymaster · · Score: 2, Insightful
      It's not more secure and it wastes more resources

      i submit it could actually be less secure...

      1. dos attacks!
      2. sniff the port knocks

      yikes!

    3. Re:Well, there go the logfiles by jlaxson · · Score: 3, Insightful

      sniff the port knocks

      I Disagree. If someone sniffs the knocks, they still have to authenticate to whatever application gets opened up. So, for a sniffer, this may not be very effective (at the worst case, it's no different than what you had before). But for a hacker across the net who wants to get at ssh, this effectively locks them out.

      --
      On Apple Input Peripherals: They're okay, I guess, but I was really hoping for a one-key keyboard and a 109-button mouse
    4. Re:Well, there go the logfiles by Esion+Modnar · · Score: 4, Insightful
      Actually, I think this article has been one of the most "nerd-worthy" postings on Slashdot in quite a while...

      And yes, one the most annoying things about sitting behind a NAT is only being able to forward a port to a single host at a time. This would be great if "port knocking" could solve this, though in a very Rube Goldberg fashion.

      --

      They say the first thing to go is your penis. Well, it's either that or your brain. I forget which...
    5. Re:Well, there go the logfiles by diablobynight · · Score: 2, Insightful
      beautiful, now instead of a 1U router I will need a 6U router that will cost 10000$ because it needs to be able to constantly process log files for all security requests.

      Also can you imagine trouble shooting problems on this.
      oh I see the problem, your connection wasn't able to send a knock from your network on port 8019, but it was on 1223,6789,9865 oh but not 7024, oh crap you have another ap on 7024 and when you send requests, it gets bad request errors in the error logs, well lets switch that to 2345. Or other problems to be seen, also now hackers won't just port scan me, they'll port scan me a trillion times, trying to find the right combination to open my ports.

      Beautiful

      --
      Anonymous Cowards - Oh God, How I hate you
    6. Re:Well, there go the logfiles by 3.1415926535 · · Score: 4, Insightful

      How about, "Yeah, NAT breaks stuff, let's fix it" instead?

    7. Re:Well, there go the logfiles by Smidge204 · · Score: 4, Insightful

      Or other problems to be seen, also now hackers won't just port scan me, they'll port scan me a trillion times, trying to find the right combination to open my ports.

      And what stops them from brute-forcing regular password protected access on a known port?

      1) You don't know how many ports are in the knock sequence
      2) You don't know that the range is
      3) You don't know what port will open when you get it right

      Similar to a password, only instead of base 94 (a-z,A-Z,0-9`~-_=+\][|}{';":/.,?>million trillion trillion trials to crack. Then you have to do one more scan to figure out which port actually opened after each trial and hope no other service opened a port for some unrelated reason.

      I'm thinking it's a tad more secure than password authentication alone... and you can always throw password auth in after the client connects, so you can throw in a few false-positives (bogus logins) to keep them busy.

      And a five second window to transmit the sequence is pretty generous. If you wanted to harden it even more against brute forcing, you could require a full 5 second wait and accept all connection attempts from a particular host. That would limit an attacker to 20 attempts per minute max. So it'll take the better part of 32 billion trillion years to crack it.

      At that point, you can consider the end of the universe as "The ultimate connection timeout"
      =Smidge=

    8. Re:Well, there go the logfiles by gnu-generation-one · · Score: 3, Insightful

      "I dind't say it wouldn't be secure, I said it would be irritating for me as the admin, when people tried to crack it."

      It should give you less irritation as an admin, when portscans reveal that every port on your computer is closed, and they go find another target, wondering why you bothered buying a firewall if you seemingly haven't configured it to accept connections.

      A recent nanog (was it nanog?) flamewar mentioned that people ran their servers on non-standard ports and they considered it really secure. Why? Because the viruses only scan one port, and choosing a different one gives you a lot of time to take stock when a vulnerability/virus pair is announced.

      It's obscurity (as a first layer of defence), but it means that an "nmap * -p 22" won't find your server, and anyone running the full scan of 64K ports over the internet is making themselves a lot more visible, and a lot slower.

    9. Re:Well, there go the logfiles by dossen · · Score: 2, Insightful

      One could implement it in such a way that the validity of the keys overlap. Then one could read the key, perhaps even keeping it "locked" on the device for the time it takes to enter it, and then be sure that it is still valid (unless you take a very long time entering it). There would need to ba an overlap in any case, since the network transmission could cause the key to be too old by the time it got to the server.
      But if it is implemented in some soft-/hardware combination, then those timing issues are much smaller. But then why not just use a big-ass public key-pair.

    10. Re:Well, there go the logfiles by Christopher+Whitt · · Score: 2, Insightful

      If you're going to go so far as to require a one-use pad, then you can forget about the whole "port knocking" concept

      I understand your point, but if I understand port-knocking correctly, it will allow you to effectively cloak the existence of a service entirely. Even if you use a 1-time pad authentication scheme, Mr. Evil Cracker can still connect to your server and see that a service is running. Perhaps it is a commonly used service, and a known exploit exists that bypasses the authentication mechanism. Unlikely, I know, but with port-knocking, connection attempts to your server are simply dropped on the floor, until the correct sequence of connection attempts is received.

      Unless Mr. Evil Cracker is sitting somewhere in the middle to sniff a valid connect attempt, he will never even know the service exists.

  2. not bad by maelstrom · · Score: 5, Insightful

    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.

    --
    The more you know, the less you understand.
    1. Re:not bad by jrexilius · · Score: 2, Insightful

      well, he worded his point badly but I agree with no service is more secure than protected service. His scenario works for him but not for all of us.

      I will have servers in datacenters spread around the US and possibly overseas. His solution wont work for me. So cost/benefit/risk compromises come in to play, which is where extra layers comes in.

    2. Re:not bad by LostCluster · · Score: 2, Insightful

      I'm in the camp that all security methods are, at their core, security by obscurity. You're only as safe as your code and key are secret... once that's compromised by either guess and check or outright leak, you're not secure anymore.

    3. Re:not bad by platypus · · Score: 4, Insightful

      Ok, let me rephrase what I wrote in another message.

      Open ports per se are not insecure!

      The whole point behind port knocking is the wrong impression that "open" ports are more insecure than "closed" ports. This is totally bogus.
      It's about the applications behind the open ports, and it's not more complicated to write code which listens to a specific port and drops the connection if it doesn't recieve some secret number as the only payload of the first packet, than it is to write the kernel tcp/ip stack.

      That brings me to another mantra

      Kernel code is not intrinsically more secure than application level code!.

      There are many examples for buggy and overflowing tcp/ip stacks (ping-o-death comes to mind if you're somewhat older).

    4. Re:not bad by jmv · · Score: 2, Insightful

      Note sure I like the idea, but I think it would really be more secure in one case: worms. That's because they can't really sniff the knocking, unlike a real intruder.

    5. Re:not bad by _bug_ · · Score: 2, Insightful

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

      Bingo!

      With a knocking daemon a port scanner is going to see an IP address with no machine on the other end because no response is sent to its connection attempts. It's a great way to conceal the location of a server from broad port-scanning that you currently see on the internet.

    6. Re:not bad by h4x0r-3l337 · · Score: 5, Insightful
      The whole point behind port knocking is the wrong impression that "open" ports are more insecure than "closed" ports. This is totally bogus.

      No it isn't. A closed port does not accept any data, therefore you cannot attack the application "behind it". A port that is open is only as secure as the application listening on that port, which AT BEST is as secure as a closed port, assuming the listening service is absolutely perfect, and has no flaws whatsoever.

      There does seem to be some confusion as to what it means for a port to be "closed", judging from most of the posts I've seen so far. You can close a port, but send "connection denied" replies to anyone trying to connect. This makes the port itself safe, but tells the attacker that there is in fact a machine there on the network (which could be a reason for an attacker to continue to probe and/or attack you in other ways). You can also close the port by not responding to anything directed at it at all. If *all* of your ports are like this, an attacker won't even know if your machine is turned on or off, or if there's even a machine there at all. In a way, you've become invisible. Ideally, that's what you want. Port knocking is simply a way to allow your machine to be invisible while still being able to initiate connections to it from arbitrary IPs.

    7. Re:not bad by poot_rootbeer · · Score: 3, Insightful

      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.

    8. Re:not bad by kir · · Score: 2, Insightful

      You've got to be kidding. Right?

      You do not allow SSH connectivity for remote administration even from a few identified hosts (even to only a single host in a dmz with non-port forwarding connectivity in to the rest of the network)? Why? Do you also not allow email in to your network? Do you not allow your users to browse the web (particularly with IE)?

      If you're not doing the other things I mentioned, then you're niave. If you are... ummmm...

      --
      3cx.org - A truly bad website.
  3. Sniffing by Anonymous Coward · · Score: 2, Insightful

    This security is easily defeated if the connection can be sniffed to find the 'secret handshake'.

  4. Easy enough... by wishus · · Score: 4, Insightful

    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.

  5. Before you complain about "Obscurity" by pclminion · · Score: 5, Insightful
    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!

  6. I see an easy way by Apreche · · Score: 4, Insightful

    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.

    --
    The GeekNights podcast is going strong. Listen!
  7. Re:Password by 26199 · · Score: 4, Insightful

    Except it hides that the port is open at all, which is useful.

  8. Not good by glpierce · · Score: 5, Insightful

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

    --
    G
  9. Security through obscurity by Dominic_Mazzoni · · Score: 5, Insightful

    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, to figure out the knock.

    1. Re:Security through obscurity by radish · · Score: 2, Insightful

      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?

      --

      ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

    2. Re:Security through obscurity by prisonercx · · Score: 2, Insightful
      All of your objections have been dealt with in one way or another.

      1) ...compromise a nearby machine first and install a packet sniffer...
      Use a one-time pad system, as mentioned above.

      2) ...you'd see a lot of people writing down the knock...
      If you'd read the Linux Journal article, they address that by saying the program that executes the knock needs to be very secure. Say, like the USB key they mention.

      This isn't a great system for continued, heavy use as this guy pointed out, but it could be used for emergency purposes. For example, if you had to remotely administer a server. You have an emergency USB key that you plug in your local machine, knock, then gain remote access with the opened port (using whatever authentication you would have if the port was simply open).

      I think, at very least, the concept needs to be thoroughly debated and vetted. (Maybe that's what we're doing here, or maybe we're just wanking ;)

      PrisonerCX

    3. Re:Security through obscurity by teeker · · Score: 2, Insightful

      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.

      If any admin ever feels secure, they have other problems. Any admin worth their salt is always paranoid.

      The whole point of it is to make things a little more obfustacated. If a cracker already knows you're running a service they are interested in exploiting, you are already at risk anyhow. If somebody with some real skills was taking a shot at compromising your network, then this will not stop them, but it is a little smarter than inviting every script kiddie with a port scanner and their dog to smash at your SSH port.

      It is a reasonable addition to a balanced security breakfast.

      --
      teeker
  10. Not the point by s20451 · · Score: 4, Insightful

    come on kids. Have we not learned our lessons? Even as a one time pad, this is lame

    You are very much missing the point. Yes, security through obscurity is terrible when it is the only security method you use. However, it can be used to augment a better security system. Even if somebody figured out the secret knock, they would still have to get past your sshd. And if an sshd exploit was found, your secret knock might give you enough time to patch the system before it could be exploited. More security is always a good thing.

    Disbelief in security through obscurity doesn't mean you have to paint a bull's eye on your head and dare people to attack you.

    --
    Toronto-area transit rider? Rate your ride.
  11. Obscurity IS Security by CedgeS · · Score: 5, Insightful

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

    1. Re:Obscurity IS Security by cheezit · · Score: 4, Insightful

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

      --
      Premature optimization is the root of all evil
    2. Re:Obscurity IS Security by Xenographic · · Score: 4, Insightful

      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?

    3. Re:Obscurity IS Security by cheezit · · Score: 2, Insightful

      I believe that a secure system is one where "giving would-be intruders the blueprints" does not weaken the protection. This should be provable on paper and could be backed up with practice if necessary.

      Foisting crappy code on the public and hoping that nobody breaks it is a very Darwinian head-in-the-sand approach. I can see your point that "we're against obscurity" provides a justification for that approach.

      It puts the cart before the horse and shouldn't raise anyone's confidence in the code. Proving that one could do so, however, should raise confidence in the code.

      --
      Premature optimization is the root of all evil
    4. Re:Obscurity IS Security by mech_knight · · Score: 3, Insightful

      Actually, security from man-in-the-middle attacks is what cryptography is normally concerned with. Real security is achieved when transmitted information is still "unknowable" despite knowledge about the process of transmission.

      That's the whole point of public and private keys. Statistical impossibility of dechiphering the private key--not obscurity--is its goal.

      --
      "Size matters not. Look at me. Judge me by my size, do you?" --Yoda {whips out green light saber}
  12. I like this idea by mrdaveb · · Score: 2, Insightful

    Although people are right in saying that packet sniffing can easily defeat this, I think it still improves security.

    It leaves the impression that the machine has no ports open, so script kiddies will leave you alone. Also, an attacker can't just exploit a server bug to crack the system without also being in a suitable location to packet sniff the knock combination to get the port open in the first place.

    --
    Homme petit d'homme petit, s'attend, n'avale
  13. Neither. by khasim · · Score: 4, Insightful

    #1. DoS attacks - how is this different from any other DoS attack?

    #2. Sniffing the port knocks - to do this, you would already have to have the upstream compromised or be on some shared network.

  14. Re:Open a whole range of ports by lactose99 · · Score: 4, Insightful

    That depends on the NAT gateway, as per the original poster. If the NAT gateway is dropping all packets that aren't part of a) valid incoming connections or b) a port knocking scheme, a portscan would reveal some or all of the ports utilized in the port knocking scheme. Ports that are closed but part of the knocking scheme would return a connection refused, while all the other (filtered) ports would simply be dropped.

    Granted, most anyone implementing this sort of security setup on their firewall would most likely think about this and either a) open an entire range of ports, only some of which would be used for port knocking (as a previous poster mentioned) or b) simply close everything at the NAT gateway and not drop any packets, thereby not revealing any detail regarding a port knocking scheme.

    I'm sure there are several other ways to deal with this at a NAT gateway, but they just aren't coming to mind at the moment.

    --
    Fully licensed blockchain psychiatrist
  15. Services listen on ports. by khasim · · Score: 4, Insightful

    It isn't the port. It's the service listening on that port.

    If the port is closed, then it is impossible to attack that service through that port.

    This process closes those ports.

  16. Order, delivery of packets is not guaranteed by Dr.+Manhattan · · Score: 3, Insightful
    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...

    --
    PHEM - party like it's 1997-2003!
  17. Re:Equivalent to a password by scrytch · · Score: 2, Insightful

    Those are reasonably good descriptions, but you don't need port knocking for this. Just stuff the key in the SYN packet. Don't accept if it doesn't have the magic word. Same effect, no magic cookie, no open port. This only yields to latency analysis, which isn't reliable over anything but a local LAN.

    The only advantage of portknocking is that it's a hack that's doable in userspace without a modified net stack (you may be able to fashion raw packets, but good luck reading them). But enabling the userspace hack would mean poking so many holes in your firewall that you'd degrade the security of the system that you're trying to lock down with this hack.

    I'd file it under "another cute perl hack".

    --
    I've finally had it: until slashdot gets article moderation, I am not coming back.
  18. Stop complainin about "security through obscurity" by Tom7 · · Score: 4, Insightful

    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.

  19. Re:Silent Bob by Abcd1234 · · Score: 2, Insightful

    Err, they were *in* Chasing Amy? Heck, the name "Chasing Amy" comes from a speech Silent Bob gave in the movie regarding some chick he always regretted never going after. A speech which is, incidentally, referenced later in J&SBSB... specifically, after their monkey got kidnapped by the Hollywood Animals people, Silent Bob attempted to tell Jay that their license plate said "Hollywood" on it. So, Bob started miming, and predictably, Jay simply would not clue in. Anyway, at one point Jay said something to the effect "you can tell that damn Amy story all the time, but you can't talk now?".

  20. Re:Open a whole range of ports by blazerw11 · · Score: 5, Insightful

    That depends on the NAT gateway

    No, the gateway or direct host has ALL PORTS CLOSED, however it does log port requests. If the log shows the knocking sequence, then and only then, will it open a port.

    --
    A great many people think they are thinking when they are merely rearranging their prejudices. -- William James
  21. Locked out of your own machine? by SassyDave · · Score: 3, Insightful

    It seems like a malicious user could keep you from connecting to your own machine by sending "malicious knock noise" to multiple ports. Meanwhile, your valid knocks would be disregarded as they are intermingled with malicious knocks. This may not seem like a big deal since the malicious user's connection could probably be stopped easily. But in a crisis it may cost you precious seconds or even minutes before you can eliminate the "malicious knock noise" and log into your system.

  22. Re:Oh, really. by Pieroxy · · Score: 3, Insightful

    I don't think you get it. This way of securing a port (22 for example) is obscuring in the sense it hide the fact that you have a service up (SSH) to the outside world unless you know the "knock code".

    You can then hide any service that is not to be known from the public (SMTP, POP, SSH, TELNET, whatever...) thus removing the probability that any exploit for these may be exploited: The hacker on the other end doesn't even know the service is running!