OpenBSD Journal

Port knocking

Contributed by jose on from the false-security dept.

Dominique jacquel asks: "As seen on /. recently,

I am intrigged by the port knocking idea. Although this is very much an obscurity layer, it seem to be a great way to force would-be intruder to make a lot of noise before finding what they look for. Forcing five or six port knocks before a connection would make it difficult for scanners to find running services without being easily detectable. What to OpenBSD folk think of it?

Cheers.

http://www.portknocking.org/ "

Port knocking has been used by malware for a while now, but I haven't seen a convincing argument for it in real security. Has anyone implemented this (for example using the pflog0 interface to retrieve packets) on OpenBSD?

(Comments are closed)


Comments
  1. By Anonymous Coward () on

    I'd love to see this or something like it native in OpenBSD - maybe intergrated with pf similar in a sense to authpf.

    I'd like to be able to open up sshd globally without the need of opening say port 22 (or any other assigned port for that matter) to the world, unless they know the portknock sequence (in essence, the password).

    This thinking is on the principle of "whatif" there's ever a remote exploit in OpenSSH; while still allowing myself ssh access from wherever I am remotely.

    To me, it's just an additional layer of security - perhaps security through obscurity but I personally see it as an addition to whatever existing infrastructure(s) is/are impletmented.

    Just my thoughts...

    Comments
    1. By ssc () on

      http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th=a6affe0413a1db5&seekm=20040209155850.GE21848%40mail.webmonster.de.lucky.openbsd.misc&frame=off


      isn't it funny that ppl try to protect themselves from bugs in software by adding even more software?

    2. By old3n () on

      Hmmm, no thanks, personally it's not something I'd use.

      AC, you say that you'd like to "open up sshd globally" but only to whoever knows the right portknock sequence/password... but this sequence is very vulnerable to evesdropping, DoS and network variations ie loss, reordering, NAT with load balancing...
      Thanks, I'd much rather rely on some strong authentication (DSA or whatever) over a reliable link (TCP), like, er... SSH itself (doh!)

      "It's just an additional layer of security", maybe but it's weaker than what it supposedly protects. However, it certainly is another layer of complexity, with its own new problems...

      Comments
      1. By Anonymous Coward () on

        Glad to hear your comments... Much appreciated as it gives me another perspective to look at things.

        Couple questions for you then..

        If they DoS it, couldn't they just as easily DoS OpenSSH itself?

        Sure it's possible to evesdrop the port sequences, so then they get that (taking them a couple more steps) and get to ssh. Now they're sitting at a login: prompt without a login/passwd. Where's the danger in that if ssh were already open to the world itself?

        I'm not trying to sound like an ass here at all, I really am curious on these questions.

        Don't get me wrong either. I trust OpenSSH, but as in the past there was bugs and always will be. I just hope they're not as serious as to allow remote execution or shell level access.

        Regards.

        Comments
        1. By anonymous atom () anonymous@super-atom.com on mailto:anonymous@super-atom.com

          well maybe you should just keep your workstations offline or use packet filtering to limit who has access, obviously if you never leave the country you dont need to allow international traffic to your ssh port. you should have a pretty good idea of who should have ssh access and who shouldnt, write some pf rules to take care of it, you should be running pf already.

        2. By old3n () on

          Well AC, I'll try to satisfy your curiosity. :)
          Here's why it's IMHO (comments welcome) much easier to DoS a box relying on port knocking than on sshd alone.

          1) Unlike SSH/TCP, no handshake is necessary to transmit a port knock (that's the whole idea). Therefore pretty much anyone can spoof a sequence (correct or not) from any address without revealing anything about their possible identity.
          Impossible to filter out at the target.
          I could spoof knocks from a bazillion of machines (using part(s) of the right sequence if I sniffed it earlier, or just noise if I didn't). How many will the port-knock gatekeeper software keep track of? If it starts discarding legitimate attempts, better yet exhaust the host resources or even crashes, our DoS was successful.

          2) The "knock password" is not atomic but is a sequence of packets, which can arrive out-of-order etc or, in case of a DoS, with some chaff in between. [This is IMHO a major design limitation; I'd much rather rely on the password consisting of, say, one UDP packet instead of several TCP SYN.]
          Anyway, if this added junk causes your port-knock sequence to be rejected, we have another case of successful DoS. If you relax the rules so that noise/out-of-order/loss issues don't affect you, chances are that just knocking on random ports for a while will open the port-knock gate as well now.

          I understand your point of view "we have seen a nasty hole in OpenSSH in the past, port knocking is a way to protect myself from the next one".
          Sure it is, but you just added one layer of software here, with new opportunities for bugs or other problems (I was mentioning DoS).
          It's a tradeoff. Personally I don't think the benefits of port-knocking outweight the risks, inconvenience etc, so I won't use it on a production system and I don't think it should be part of the default OpenBSD install. But I'm sure nobody would complain having it available as a port/package for whoever want to use it...

  2. By Benjamin Schweizer () gopher at h07 dot org on http://www.redsheep.de/

    There's one advantage of portknocking: you won't find an infected host by nmap'ing you lan. Of course your IDS will report suspicious traffic. It seems more advanced to ldpreload (linux) an existing daemon. THC's grenzgaenger tool implements such a method. There seems no good method detecting a ldpreloaded socket. You don't know the activation packet so what will you place as signature in your IDS? It is too late when there is outgoing traffic...

    Comments
    1. By Matt Van Mater () on

      Thanks for the reference to grenzgaenger, i'd never heard of it before.

      After looking at the config files, readme, etc I don't see why you couldn't build your own gg scanner and look over your network for hosts listening for this traffic? You might have to try a few common session identifiers but many script kiddies could be found easily because they were too lazy to change the 'test' identifier.

      Also, why wouldn't an IDS be able to pick up gg specific traffic? There has to be some sort of specific packet sequence or payload that gg looks for beyond the simple identifier listed in the shell script as 'test'. Otherwise the ggd daemon would kick off every time the characters 'test' went over the wire, which I doubt it does.

      In any case, this is a pretty nifty idea. I'd hate to be on the receiving end of it though :)

      Comments
      1. By Benjamin Schweizer () gopher at h07 dot org on http://www.redsheep.de/

        I meant that you can't detect a ldpreloaded socket when there is no traffic, because it won't respond on a nmap scan[1]. And as you don't know the activation sequence you can't sniff for it. You could change this sequence on every connect. This means that you can't detect an infected machine (when idle) from a remote host. (Hiding from the local root is another discussion, but I believe it works in 99 percent.)

        The only method of detecting a well infected machine is some statistics on irregular traffic. And there is no security, there is only trust.

        [1] I assume that it is possible to use some timing analyses under high system load to detect a ldpreload.

  3. By qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvb () on

    the basic idea is to communicate some secret before gaining access to a potentially exploitable service.

    there is zero gain from sending multiple packets to serveral ports in order. you might as well send one packet with, say, the port numbers as payload. or better yet, a crypto challenge.

    but guess what, this is exactly what daemons like sshd, which is the type of service this would be used for, already do. so instead of reimplementing the wheel, why not hack to improve sshd instead?

    or if you're really after obscurity, use a better thought out idea, like tcp md5 signatures (i believe this has been suggested before). man 4 tcp.

    Comments
    1. By Anthony () on

      sshd with authpf is undoutedly more secure, but if your ISP does a port scan to see if have you any services, you have a problem.

      Comments
      1. By djm () on

        if your isp won't let you run sshd, then you have a number of problems

  4. By Anonymous Coward () on

  5. By Krunch () on http://krunch.servebeer.com/~krunch/

    <a href=http://pasmal.casino770.com/>Here</a> is another implementation for Linux I found recently. <br> <br> (sorry for the empty comment)

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]