Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Software Security The Internet

Port Knocking in Action 430

tyldis writes "There was something called "port knocking" mentioned on Slashdot earlier, and now an implementation has sprung to life. Is this something worth pursuing?" The page is to an application called knockd which is a simple proof of concept with hard coded knock sequences. Really interesting stuff.
This discussion has been archived. No new comments can be posted.

Port Knocking in Action

Comments Filter:
  • one of many (Score:3, Interesting)

    by bangular ( 736791 ) on Wednesday April 14, 2004 @05:56PM (#8863757)
    There are actually about 5 other known port knocking implementations. And it's such an easy thing to do, I'm sure many others have written their own private implemenations.
    • by Anonymous Coward on Wednesday April 14, 2004 @06:09PM (#8863913)
      Actually I counted 11 other port knocking implementations. Really I did. Can I get modded +4 also?
    • by bwhaley ( 410361 ) <spam4ben AT gmail DOT com> on Wednesday April 14, 2004 @06:11PM (#8863929)
      Lots of info available via a google search []...

      A few implementations [] here.

      I don't think will be very useful/valuable until clients (such as ssh) have it built in. I don't feel like going through the hassle each time I want to connect. Though it would keep comcast from discovering my ssh service...

      • by lambent ( 234167 ) on Wednesday April 14, 2004 @06:19PM (#8864020)
        Off the main topic, but regarding comcast ...

        I've spoken with several reps at Comcast over the past year. They don't really care what servers you run. (I've been told this explicitly as well as tacitly) In fact, when I first contacted tech support, the guy had no idea what SSH, Telnet (ssh is like an encrypted telnet, right?) or even what a port was.

        I've been running an ssh server for about 8 months uninterrupted, now. The general rule of thumb seems to be - If you don't cause trouble for anyone else, Comcast won't cause trouble for you. So, in that interest, I impose reasonable caps on my own throughput and connection counts, and I've had no problems at all.
      • I think it's not hard to write a simple wrapper around any SSH, FTP,... client. A simple shell script using netcat should do it.
    • port knocking is like having a deliberate hole in
      your carefully constructed secure zone.

      I'm going to stay a mile away from anything that
      brings on board a 'knocker'...

      I'd hate to get knocked up.

      • Re:one of many (Score:5, Insightful)

        by tverbeek ( 457094 ) on Wednesday April 14, 2004 @06:19PM (#8864014) Homepage
        port knocking is like having a deliberate hole in your carefully constructed secure zone.

        Well, yes. That's the point: to enable access to a secured system. It's often a necessary evil. The issue is that most people implement these deliberate holes by leaving certain ports open to simple direct access. They're easy to find, and not all that difficult to exploit. Adding a layer of obscurity and another layer of security on those holes - in effect putting a concealed combination lock on them - would be a more secure way of doing that.

        • Re:one of many (Score:3, Insightful)

          by jacquesm ( 154384 )
          In practice though, once the system becomes
          automated it no longer is the user that sets
          it up but some - untrusted - application like
          say the next cool file sharing program. Next
          a bug is discovered and *bang* millions of
          previously firewalled machines are suddenly
          wide open.

          • Re:one of many (Score:3, Interesting)

            So your theory is that programs are MORE secure when they have LESS security features?

            I suppose that having passwords on user accounts is silly, too, because some rogue program could log keystrokes and post them to the web.
      • Re:one of many (Score:3, Insightful)

        by uberdave ( 526529 )
        The point for me would be to punch a hole in a draconian acceptable use policy. Many broadband providers to not permit you to run servers, and frequently they will run portscans to find violators. With this technique, they could portscan away, and I'd still be able to access files on my home machine from outside. Pesky broadband monopolies.
        • by billstewart ( 78916 ) on Wednesday April 14, 2004 @08:05PM (#8865055) Journal
          It's really annoying when cable modem companies do this, because there's almost always at most one cable tv company in a given area, so if they're clue-deficient, you don't have an alternative. (And most of them are not only clue-deficient, but contagiously clue-hostile.)

          It's much less of a problem when DSL providers have policies like this, at least in the US, because usually the ex-monopoly telcos rent their copper to multiple DSL Layer 2 providers (often including themselves), and the DSL providers usually provide connectivity to many ISPs. So even if, for example, SBC DSL ISP service has some stupid policy, SBC provides Layer 2 access to many ISPs including and Speakeasy, who have friendly clueful policies, and they rent copper to Covad, who provide Layer 2 access to many more ISPs (sometimes with fewer connectivity options, e.g. maybe only SDSL or IDSL and not line-shared ADSL.) Sometimes these alternatives cost more - I'm paying about US$57/month for ADSL with four static IP addresses, vs. some of the newer loss-leader $29 deals from other providers.

          Most other countries don't seem to have policies against being a Real User on your broadband service, at least if you're not commercially reselling it. Theoretically, this means that all those non-Americans out there should be creating lots of cool and interesting things to do with their broadband services, but I haven't seen much other than Yet Another File-Sharing System variants or some of the Asian grocery-shopping-on-line things that get magazine articles written about them but aren't very useful outside their local areas.

    • Well, someone needs to come up with a better name. I feel like I should be saying "shut up Beavis" whenever somebody mentions it.
    • by HPNpilot ( 735362 ) on Wednesday April 14, 2004 @06:59PM (#8864440) Homepage
      Well at least I used to build them in. It was so simple many others must have done the same thing. Take a 10-step relay, put a 1 minute reset timer on it, and wire each of the first few steps to a pulse gen anded with one of the incoming lines' ring detect. If the right sequence of incoming calls happened, it connected a separate incoming WATS line to a WATS outgoing line. Viola! Free calls from anywhere to anywhere, and nobody would ever notice if you were careful to only select "unlimited" outgoing WATS lines. We're talking something like 35 years ago here...
  • by JesseL ( 107722 ) * on Wednesday April 14, 2004 @05:56PM (#8863760) Homepage Journal
    "shave and a haircut" into port numbers?
  • Knock Knock (Score:4, Funny)

    by Anonymous Coward on Wednesday April 14, 2004 @05:56PM (#8863768)
    You can keep on knockin' but ya can't come in
  • by Black Art ( 3335 ) on Wednesday April 14, 2004 @05:57PM (#8863777)
    So how do we map musical notes to port numbers?

    I want to get "shave and a haircut" ported over to the new protocol.
    • Um, start at the lowest key on the piano and assign it a 1. Assign the highest key the highest number. That's about it...start your port knocking transcriptions.

      Or if you're really bored you can transcribe each note into hex via an old commodore 64 with DMC music composition software or the excellent JCH composer. Convert that hex back to regular digits and those are your ports.
  • Great for warez... (Score:5, Interesting)

    by danielrm26 ( 567852 ) * on Wednesday April 14, 2004 @05:58PM (#8863788) Homepage
    I can see this being used quite extensively in the warez arena. It'd be pretty easy to give out the "key" to clients who are allowed access, while any ISP scanning for FTP servers, for example, would find nothing open.
    • Along the same lines, it would be useful to us non-warez folk that run servers at home that are for personal use, but have broadband that disallows servers in the AUP.
    • by caluml ( 551744 ) <> on Wednesday April 14, 2004 @06:03PM (#8863842) Homepage
      I fear the ISP might just watch for large amounts of data spewing out on tcp/20.
      • by Dj ( 224 ) on Wednesday April 14, 2004 @07:27PM (#8864689) Homepage
        Well with a little work, you could knock an open sequence, and then knock a sequence which had a port number, and then we open the requested port and start the server app up on that port. Tada! Secret knock port requesting. Now you can pick any port and spread the traffic over different ports over time.
        • Time to file a patent.
        • by lommer ( 566164 )
          I think that ISPs could simply then start looking for seemingly random port probes by machine A on machine B, followed by machine B spewing gobs of data to machine A on a random port. That's the trick, make your protocol too good and it'll stand out because it's too random. If you ever actually talk to anyone who works at ISPs though, they generally just flag those customers with unbelievable upload/download ratios and then have a human look at their logs to see if they're violating the TOS (running a serve
    • I can see this being used quite extensively in the warez arena. It'd be pretty easy to give out the "key" to clients who are allowed access, while any ISP scanning for FTP servers, for example, would find nothing open.

      <tongue in cheek>
      If you had an ISP that was port scanning for open FTP servers on port 20, why not just move your port to another port with well known use for home users, like 135?
      </tongue in cheek>

    • "I can see this being used quite extensively in the warez arena."

      Shhhh.... Don't mention the trojans.
  • Knock Knock? (Score:4, Informative)

    by qualico ( 731143 ) <worldcouchsurfer&gmail,com> on Wednesday April 14, 2004 @05:58PM (#8863791) Journal
    Who's there?

    Just a bunch of hackers knocking with sequences they captured from sniffing.
    • by khasim ( 1285 ) <> on Wednesday April 14, 2004 @06:15PM (#8863975)
      You can only sniff packets on a network you are attached to.

      What that means in real life is that someone would have to be connected somewhere along the route from your machine to the server you're knocking on.

      I am in Seattle, I can knock on my server from another location in Seattle. Someone in Canada will not be able to capture any of my packets.

      Port knocking allows me to run a service on the Internet and not worry about just anyone from anywhere connecting to it.
      • by MerlynEmrys67 ( 583469 ) on Wednesday April 14, 2004 @07:08PM (#8864513)
        I remember when:

        Seems my office was 2 miles down the road from my house - traceroute from my house in Portland, OR to my office went through both Seattle AND MAE-West (Bay Area, CA)

        Many external countries only have external connections to the USA, not directly to each other (don't know how true this currently is - but several asian countries used to have to hit the W Coast, USA to get between each other)

    • Re:Knock Knock? (Score:5, Insightful)

      by DarkMan ( 32280 ) on Wednesday April 14, 2004 @06:16PM (#8863980) Journal
      Meh, throw some cryptography into the mix.

      Take the source IP, add a password, take a one way hash. Include this hash in the knocking packets.

      Now, if you've sniffed the packets, then you won't know the password. So, you can spoof the source IP, in which case the port will be opened _for that IP only_, or you can send the knocking packets from you IP, in which case, you need that password, or you've just advertised yourself as a hacking attempt.

      In order to prevent a single password for everyone situation, it's not hard to include a user ID in the packets.

      Does need the application or firewall to allow connections to and from specific IP's only - but I really can't see that being an issue.

      Problem solved.

      • Re:Knock Knock? (Score:4, Informative)

        by Anonymous Coward on Wednesday April 14, 2004 @06:54PM (#8864390)
        Encrypted port knocking is pointless. Here's why: Port knocking only makes sense if the protected system reacts to the individual knocks as if there was no port knocking system. Only when the knock sequence has been completed it opens the port. This means that you can't do any handshaking. All communication is one-way until it's "too late". Consequentially, since there is no challenge which could require a different response, replay attacks are unavoidable unless you use one-time passwords and then there's no point in encrypting the passwords.

        If you decide to send a challenge to the knocker, you could just as well use regular authentication over a TCP channel.

        The point of port knocking is to hide the existence of a regular channel, not to protect it from someone who knows that it's there. Someone who can sniff your packets is by definition already past that layer of protection, so any attempt to complicate the knock-layer will only increase the chance of creating another vulnerable interface. Keep it simple or don't do it.
        • Parent is wrong (Score:5, Informative)

          by Ernesto Alvarez ( 750678 ) on Wednesday April 14, 2004 @10:02PM (#8865904) Homepage Journal

          Encrypted port knocking is pointless. Here's why: Port knocking only makes sense if the protected system reacts to the individual knocks as if there was no port knocking system. Only when the knock sequence has been completed it opens the port. This means that you can't do any handshaking. All communication is one-way until it's "too late".

          The idea in the grandparent post wasn't a challenge-response in the traditional way. It was some authentication data along with the knocking.
          The knock won't be encrypted, but it will have some data that is characteristic of the source (the source IP) that can't be spoofed (because of the password and the one way hash).

          An example of this would be:

          1.Real owner takes his IP (public info)
          2.Real owner takes his secret password (known only to him)
          3.Using IP and password he computes the hash and sends it in the knocking packets (let's say it's in the IP id)
          4.The receiving system captures the knocking packets and takes IP source and the hash
          5.It reads the secret password (from config file)
          6.It calculates the hash with the source IP and password

          If the hash sent and the hash calculated match, the system "accepts" that part of the port knocking. If not, discards the packet.

          An intruder might only spoof the whole packet (including IP source) and might open the firewall only for that IP. If he tries to use the hash to open it for HIS ip, the calculated hash won't match the hash sent. He cannot calculate the hash he would need because he does not know the password, and the hash is one way.

          In this protocol the target system does not need to respond with a challenge, it just discards packets that are "spoofed" (that have a non matching hash).
      • Re:Knock Knock? (Score:5, Interesting)

        by tonywong ( 96839 ) on Wednesday April 14, 2004 @06:55PM (#8864402) Homepage
        It gets better than that. Just imagine a honeypot connection for people who don't port knock. That way there is a better measure of security through obscurity since non-port knockers believe that they're actually getting through the systems' defense layers.
      • I haven't looked at the way this is implemented (in true Slashdot fashion), but here's what I would do:

        From client:
        Send a random number, say [1-10] of port knocks, toward random ports.
        Send the true port knock sequence, this has to complete before a certain time has elapsed.
        Send a random number of port knocks again.
        Wait a second or two, then connect to the real port.

        Now, the server side waits for the first correct port and hence ignores you random garbage. Once your first port comes through it waits for a
    • Re:Knock Knock? (Score:5, Informative)

      by timeOday ( 582209 ) on Wednesday April 14, 2004 @06:17PM (#8863989)
      Not unless they can get into a router on the path between you and someone valid who logged in, or the same ethernet segment.
    • Re:Knock Knock? (Score:2, Interesting)

      by brettbender ( 87275 )
      This is a replay attack. So don't use a static (replayable) sequence of ports for the knock sequence. Instead, require a dynamic sequence that is a function of the current time.
  • I believe this technology is needed to be pursued greatly. The unwanted traffic that anybody running a website or FTP server sees generated everyday in his server logs is enough to make port knocking a necessity.

    I wonder though. If port knocking is to become popular, will it be able to work through all of the blocked ports resulting from the excessive worm attacks?

  • old (Score:5, Funny)

    by ozric99 ( 162412 ) on Wednesday April 14, 2004 @06:00PM (#8863811) Journal
    When the server detects a specific sequence of port-hits, it runs a command defined in its configuration file. This can be used to open up holes in a firewall for quick access.

    pfft, XP has had this for ages....

  • ISP Port-Scanning (Score:5, Insightful)

    by ckswift ( 700993 ) * on Wednesday April 14, 2004 @06:02PM (#8863833)
    This might be useful when ISPs routinely port-scan their subscribers to discover if their running services in violation of their TOS.
    This will allow your computer to appear not to be running services expect to the person who knows the magic knock.
  • by stevens ( 84346 ) on Wednesday April 14, 2004 @06:03PM (#8863838) Homepage
    I'm betting that nmap binary is about to get much bigger...
  • The port knocking idea is pretty old.. at least for months now all kinds of people are knocking my 135 1433 3127 and a bunch of others to DEATH, like hundreds a day, trying to get in..

    Oops, that's Microsoft port knocking.. never mind, sorry, I guess it is new to Unix..
  • Knock Knock (Score:5, Funny)

    by Anonymous Coward on Wednesday April 14, 2004 @06:03PM (#8863849)
    Who's there?


    Packet who?

    Packet up bitch, you've been hacked.
  • Don't come a knockin'
  • how long till... (Score:5, Interesting)

    by Anonymous Coward on Wednesday April 14, 2004 @06:05PM (#8863866)
    till we see virus/worms that install port knocked backdoors.

    'virus x appears to open up 200 ports for no real reason, but it also has some remote desktop code in there too opened on a firewalled port....'
  • authpf? (Score:5, Interesting)

    by m0rph3us0 ( 549631 ) on Wednesday April 14, 2004 @06:06PM (#8863875)
    Why use port knocking. It is no more secure than plain-text passwords. Use authpf. authpf can be set as the shell so when a user logs in authpf just changes the firewall rules.
    • Re:authpf? (Score:5, Insightful)

      by smcavoy ( 114157 ) on Wednesday April 14, 2004 @06:12PM (#8863934)
      passwords and port knocking are two different things.
      A perfect example of what it could allow to be done is on knockd's homepage.
      Basically, ssh would not be an open port, you'd have to knock (connect to) the right sequence of ports, which would trigger a rule that could allow only the IP that made the successful knock, access to the ssh port.
      Then when your done you would have another sequence of ports you'd have to "knock" in order to remove the rule allowing access.
      • The parent is suggesting that sending the "knock" is no more secure than sending the password over plaintext, since anyone sniffing can easily sniff out and reproduce the "knock" as well.
        • Yes, but if you have to knock to get to the server, and then you have to authentificate (aka through ssh) you have an extra layer.
          • If I'm reading the Authpf FAQ [] correctly, Authpf is a service that you run on your firewall, not on the target server behind it. Logging in to authpf on the firewall is equivalent to knocking on the firewall - both of them tell the firewall to let you access the target server that's hidden behind the firewall, and if you don't knock/authpf, the firewall won't let you in.

            There are some tradeoffs - knocking systems are usually lightweight, while authpf is probably more thorough, especially about making sure

    • Re:authpf? (Score:3, Interesting)

      by debrain ( 29228 )
      Why use port knocking. It is no more secure than plain-text passwords. Use authpf. authpf can be set as the shell so when a user logs in authpf just changes the firewall rules.

      I'm not sure that authpf corresponds to port-knocking's subject-matter.

      You can make port-knocking more "secure" than encryption; you can use a time-synchronized one-time pad to construct and vary the ports, flags, TCP options, sequence, etc., to come up with a system both unique and impossible to duplicate, absent the one-time pad.
  • knock-knock (Score:3, Interesting)

    by after ( 669640 ) on Wednesday April 14, 2004 @06:07PM (#8863887) Journal
    That server is about to get more knocks then it can handle, its starting to get pretty slow loading for me.

    knockd is a port-knock server. It listens to all traffic on an ethernet interface, looking for special "knock" sequences of port-hits. A client makes these port-hits by sending a TCP (or UDP) packet to a port on the server. This port need not be open -- since knockd listens at the link-layer level, it sees all traffic even if it's destined for a closed port. When the server detects a specific sequence of port-hits, it runs a command defined in its configuration file. This can be used to open up holes in a firewall for quick access.

    This is an interesting idea, but not very secure. If there was, for example, a need to "knock" a server to activate some sort of access control, then anyone can send the TCP/UPD packets (AFAIK) someone correct me if i'm wrong.

    Looks interesting though, but inetd could do the same thing.
    • Security (Score:3, Insightful)

      by David Hume ( 200499 )

      This is an interesting idea, but not very secure. If there was, for example, a need to "knock" a server to activate some sort of access control, then anyone can send the TCP/UPD packets (AFAIK) someone correct me if i'm wrong.

      If I understand it correctly, this could be very secure. Imagine trying to guess the combination of a combination lock where each port number represents a possible number of the combination, and the combination is of unknown length (e.g., a combination 3, 5, 45, or 105 numerals

  • by frobisch ( 630854 ) on Wednesday April 14, 2004 @06:08PM (#8863901)
    is pasmal []
  • Nice start (Score:5, Insightful)

    by javatips ( 66293 ) on Wednesday April 14, 2004 @06:09PM (#8863908) Homepage
    That's a nice start.

    It would be nice to be able to use one-time pad to generate the port sequence. By changing constantly, it would be almost impossible for passive listeners to snif the port sequence.
  • Interesting (Score:5, Interesting)

    by debrain ( 29228 ) on Wednesday April 14, 2004 @06:11PM (#8863925) Journal
    This sort of clandestine type of communication has been known about in the security community for a long time - pretty much since the ARPA days. Some backdoors used specific sequences of TCP flags, with no practical TCP use other than opening a backdoor, but permitting anonymous communication or command broadcasting.

    With access to a TCP stack and a link-layer sniffer, you can send and receive, respectively, commands to ghosts in working machines, transparent proxies or "harmony" devices. It is good to see this sort of thing coming to light, since it is extraordinarily powerful and not very well known.

    An example of these probing commands are Xmas, Fin, and Null scans for Fyodor's nmap; note that other TCP flags (TCP options, in particular) can harbour substantially more information than the flags alone.

    Unfortunately, in the modern age of macro viruses, it is hardly necessary to be skilled or even aware of such devices to write a devastatingly powerful virus.
    • Re:Interesting (Score:3, Insightful)

      by evilviper ( 135110 )

      it is hardly necessary to be skilled or even aware of such devices to write a devastatingly powerful virus.

      How can you consider this any more secure than a password prompt? It's simple old obsecurity. There are less combinations of TCP/IP flags than there are letter/number combinations, so a flag-based system is easier to brute-force, not harder.

      Once your worm has been decrypted, everyone will know what TCP flags need to be set, and anybody can connect. It's not like you're going to fool anybody here.

  • by Dr. Zowie ( 109983 ) <slashdot@ d e f o r e s t .org> on Wednesday April 14, 2004 @06:13PM (#8863945)
    The problem here is that the ``password'' (the port knock sequence) is sent in plaintext. Anyone with a sniffer anywhere between you and the other machine can see what you're doing. If this ever catches on, any L337 |1dd13 with half a rootkit will be sniffing for anomalous port-requests, and you'll be just as hosed as if you logged on via telnetd.
    • dratted HTML filter. That's ``L337 |<1dd13'', of course.
    • Yea but if you have ssh open with this it is just another layer of security. It is hard to truly secure a box with no openings and this is just one more thing that will trip people up. If you implement this and somebody tries to brute force your password or something it would certainly take longer (if they are not locked out because so many tries first). In todays world it is just one more tool that can be added to the computer security arsenal. Hell it would not even be a bad back door to your own box. I
    • by pkiguruman ( 413057 ) on Wednesday April 14, 2004 @06:28PM (#8864111)
      If you are using portknocking as your only defense, then you are as smart as dirt and deserve what's coming to you.

      I think it fits in great as a layer of defense.
      Is there an easier way to weed out the attempts from all of those script kiddies and worms to get into certain services on your network?
    • by LordKronos ( 470910 ) on Wednesday April 14, 2004 @06:46PM (#8864327)
      Exactly, this whole idea is stupid. It's a password sent one character per packet instead of all in the same packet.

      As I said the last time this idea appeared on slashdot, if you want to hide a port from someone but make is still accessible to people who know the "password", here is what you do.

      1) stealth the port by default, so it accepts no TCP connections.
      2) Have the port silently listen for UDP packets. UDP is fine, because no acknowledgement is sent to the sender, so they don't whether you recieved the packet and ignored it, or if it never got to you.
      3)When you receive a UDP packet, see if it contains the correct password. If it does, than you start accepting TCP connections for that IP address only.

      At this level, this is just as secure as port knocking (password=port sequence). However, it has an advantage that port knocking doesn't. You can encrypt the packet with the server's public key, so that only the server can get the password out of the packet. You can also require that the packet contain an IP address in addition to the password and then verify that the IP in the packet matches the IP the packet came from. This prevents people from intercepting and replaying the encrypted UDP packet.
  • by TheSHAD0W ( 258774 ) on Wednesday April 14, 2004 @06:13PM (#8863949) Homepage
    Than a single coded UDP packet?
    • Because UDP is usually bandwidth filtered as it's the easiest protocol to flood a connection.

      Ethernet has a exponential-wait scheme to prevent cloging of pipes, and TCP uses a authorized sent only packet. No data is send until prior ones are OK'ed.
      • In that case, you could accomplish the same thing with a single ICMP packet that has in its payload a port number to open, followed by a hash built from the port number, current epoch time (as synchronized from the USNO clock), the password and the destination IP (to prevent the same packet from being replayed within 1 second against another server that has the same password). Viola! You now have a time-dependant, unilateral unlock mechanism piggybacked on an existing, allowed protocol, whose reply packet
  • (Score:5, Informative)

    by trip23 ( 727132 ) on Wednesday April 14, 2004 @06:13PM (#8863955)
    You'll find some more stuff on []...
  • Time based defenses (Score:5, Interesting)

    by frenztech ( 302220 ) <slashdot&frenzy,org> on Wednesday April 14, 2004 @06:15PM (#8863974) Homepage
    I remember talking about port knocking and its inherent sniffing vulnerability previously.

    Basically, if someone can sniff the sequence of packets, they can get your static knock sequence.

    However, if you base it on their IP perhaps, or add in a timestamp (ie, on this date, at this time, you must do this sequence) then it would make port knocking a much more effective method of deceiving attackers.

    You could also do something where knock sequence would be a form of one time password. So you would have a list of valid knocks that could only be used in order. Each person could be given a "block" of these one time passes, or the sequences could be generated on the fly as other current implementations of one time keys are.

    There are lots of great possibilities, if only I were smart enough to think of them ;) I'm currently implementing a c++ networking class for a project with port-knocking built in, and it uses the timestamp method. (Of course, they all have to compute the timestamp for one zone, GMT or wherever)
  • by purduephotog ( 218304 ) <hirsch&inorbit,com> on Wednesday April 14, 2004 @06:19PM (#8864013) Homepage Journal
    Do you type:

    >/etc/rc.d/rc3.d/s95Knock UP

  • by ch-chuck ( 9622 ) on Wednesday April 14, 2004 @06:20PM (#8864032) Homepage
    I'd just scp'd a new file to my ISP, ssh'd in to edit index.html, checked email, and then when I refreshed the page in http, suddenly I has root access!
  • by Anonymous Coward on Wednesday April 14, 2004 @06:23PM (#8864063)
    Sniffing the sequence allows a replay attack.

    The correct implementation is to listen in promiscuous mode for any packet containing a small, known header, then inspect the rest of the packet for a gpg-signed request to open a port or service, or alternately initiate a connection. Only the possessor of the private key can make a request (attacker's attempts fail the signature check), a man in the middle cannot decrypt the contents, and replay attacks are defeated by the timestamp.

    -1, Security by Obscurity.
  • by cryptor3 ( 572787 ) on Wednesday April 14, 2004 @06:38PM (#8864242) Journal
    A number of people have commented that because the port knocking sequence is transmitted without any form of encryption, port knocking is insecure. I disagree, on the basis that port knocking is not an access control measure, but rather a deterrent measure.

    If you intend for port knocking to stop determined, targeted attacks, then yes, you are sadly mistaken. However, port knocking is effective in making your host less attractive to be hacked.

    I think that an limited analogy is the removable stereo faceplate. Car stereos are a hot target for car thieves. A car thief sweeping a parking lot will not spend time on cars where he does not see the whole stereo (faceplate included).

    By hiding the faceplate, you make yourself less likely to be a victim, even if you just leave the faceplate in your glovebox. If the thief saw where you hid your faceplate, then yes, he could pop it back in and have your stereo in the 30 seconds it takes him to yank it out. But he would have to be watching you. This would be akin to packet sniffing.

    Likewise, someone scanning for a host is looking for evidence of a particular (vulnerable) service. If he doesn't see that service on your PC, he just moves along.
  • A different solution (Score:5, Informative)

    by Pros_n_Cons ( 535669 ) on Wednesday April 14, 2004 @06:55PM (#8864401)
    there is another similar idea written by Brian Hatch author of Hacking Linux Exposed. Instead of 'knocking' ports which as I understand it can be vulnerable to brute force like attacks Hatch's solution uses dns queries to dynamicly open up ports through the firewall, using the dns query as a password. There is no 'service' listening but there is a sniffer waiting for a key string on port 53 that it will take action on. The best thing is it is OS agnostic since DNS query tools are already on all OS's no client software, or technical know-how is needed. And easily customizable if you're fluent in perl.
    These kind of things are not ment for full access, only by allowing you access to the daemon which still has its own acl. When you travel sometimes you're not aware of what IP address your laptop will have so you set a dns query to your home machine which opens the SSH port for you. The whole point is to prevent random attacks from people scanning vulnerable daemons. The following are links to Brian Hatches explinations and code.

    Part 1 []
    Part 2 []
    Part 2 []
  • by ubiquitin ( 28396 ) * on Wednesday April 14, 2004 @06:56PM (#8864408) Homepage Journal
    My friend Thom Harrison at the Omaha Linux Users Group [] has posted some scripts [] which do port knocking and have the following CPAN dependencies:

    |use File::Tail;
    |use Crypt::CBC;
    |use Schedule::At;
    |use Math::VecStat qw(sum);
    |use POSIX qw(strftime);
    |use Pod::Usage;
  • by Experiment 626 ( 698257 ) on Wednesday April 14, 2004 @07:03PM (#8864464)

    Most of the arguments here against port knocking are along the lines of "but someone could just do a replay attack" or "this is vulnerable to spoofing" or whatever. These things are true about a naive implmentation of port knocking that uses a static knock, but it's not hard to come up with variants on the port knocking idea that offer much better security than that. For instance:

    1. Connect to server on some constant, always-open port.
    2. Server sends back a string, then closes connection.
    3. Using this string and a secret password, determine the current knock sequence.
    4. Connect to server using this knock sequence.
    5. Once a knock sequence has been used, serevr invalidates it, creates a new sequence, and begins publishing the string corresponding to the new knock sequence.

    The secret key of course has to be kept secret, and the underlying crypto must be good enough that if the attacker sees the challenge and the knock sequence used to reply, the key itself cannot be deduced.

    This would completely protect from replay attacks, as knocks are not reused. Spoofing could potentially be used to DOS someone by interfering with their knock sequence, but not to gain unauthorized access oneself.

    Sure, at first glance port knocking may seem to be of limited usefulness, but if you combine the idea with a little cryptographic thinking, the possibilities start to become a lot more exciting.

  • by timmarhy ( 659436 ) on Wednesday April 14, 2004 @07:08PM (#8864521)
    bagging secret methods of keeping things secure. well i'm sorry kids but ultimately keeping something secret is necassary for a secure system. what is NOT secure is keeping that secret in an accessable mode. good passwords are the most effective way of having a secret way into a system, since your brain isn't plugged into a computer it's only accessable to the correct person. port knocking sounds intresting, but it's like having a secret knock to let you in a physical door, anyone listening will know that secret knock.
  • by F.Z.Bunny ( 749528 ) on Wednesday April 14, 2004 @07:38PM (#8864801)
    For portknocking, try Got crypto.
  • Packets are not guaranteed to arrive in the order that they were sent, or even to arrive at all. The longer or more complex the knock sequence, the more unreliable this system will be. Especially for a busy server.

    There are less stealthy but more secure alternatives. I wrote one [].

I am a computer. I am dumber than any human and smarter than any administrator.