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

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems BSD

Knock Safely With portknocking_v1.0 78

Posted by timothy from the who-is-it-this-time dept.
mrdeathgod writes "The Port Knocking project at SourceForge has just released portknocking_v1.0. Based on my undergrad thesis, this client/server package does not use pre-defined knock sequences, but rather utilizes Blowfish in order to encrypt the client data into a sequence of port numbers. This enables a client with the proper password to remotely manipulate firewall rules without fear of replay attacks. While currently designed for FreeBSD+ipfilter, expanded portability is in the works."
This discussion has been archived. No new comments can be posted.

Knock Safely With portknocking_v1.0 More

Knock Safely With portknocking_v1.0

Comments Filter:

  • hrm... (Score:4, Funny)

    by blackcoot ( 124938 ) on Friday June 18, 2004 @03:30AM (#9460753)
    i usually use condoms when i want to kock safely ;-P

  • By god (Score:1, Funny)

    by Anonymous Coward
    If your gonna let your port get kocked, do it safely.

  • I'm still not convinced... (Score:4, Interesting)

    by dotz ( 683519 ) on Friday June 18, 2004 @04:05AM (#9460881)
    Even after reading this one [portknocking.org].

    A list of one-time passwords & a simple daemon, that verifies them & enables ssh access (in some high level language) at the user request would do as fine. Give such daemon some IQ, so it would make brute-force attacks very hard, and you have the same thing. Except for the "cool" part.

    • You forget (Score:5, Insightful)

      by hummassa ( 157160 ) on Friday June 18, 2004 @04:43AM (#9461006) Homepage Journal
      That a portscan reveals nothing in the case of port knocking.
      And it shows a listening port in the case of the deamon, well, listening, conventionally.
      • Yes, of course. Hiding such things means exactly, that you use "security by obscurity" approach, which "portknocking" is told not to use. Really only good thing is, when compared portknocking to one-time passwords in my proposed approach, that in passwords each "digit" can be one from about 63 characters possible (upper case, lower case, 10 digits) - and in portknocking each knock could be around 655350 - which makes a short port knock sequence harder to bruteforce, than a long one-time password.

        • Missing the point (see other posts below) (Score:5, Insightful)

          by hummassa ( 157160 ) on Friday June 18, 2004 @08:19AM (#9461701) Homepage Journal
          If you enable portknocking, your computer does not show up in a IP range portscan as a target. To a portscanner, your computer looks like all ports are closed, no way to reach it. It's turned off for all the port scanner knows. So the 5kr1p7 k1dd1ez will not bother you.

          I would be stupid, though, if *after* the port knock open some door, you get to open a telnet port for instance, instead of a more secure ssh port.

          What the topic *is* about is that now you can have OTPs and other types of non-fixed port knocks. Additionally to the security of not being "seen" by port scans, the port knock sequence changes and is more difficult to brute force.

          • Re:Missing the point (see other posts below) (Score:4, Insightful)

            by dotz ( 683519 ) on Friday June 18, 2004 @10:07AM (#9462537)
            What's the point of having the machine look like invisible/unused, if you still can watch packets with data (heck, even encrypted) come to it?

            portknocking won't help you keeping your IP hidden. Having a tunnel from your IP to a trusted machine will (so you will appear as another IP and noone administrating that machine will give your "secret" IP to public).

            pr0n kiddiez? Man, just change SSH port from 22 to 2222 and you have pr0n kiddiez off your back. In the times of scanner automation (scan IP range, find vulnerable hosts, launch all known exploits, install rootkits) people won't bother trying to hack your sshd if it's not standard anyway - just because in the time they are trying to find, where is your sshd at, they can find & hack all those 5 windows 98 machines, which NEVER saw Windows Update, on the same network.

      • "And it shows a listening port in the case of the deamon, well, listening, conventionally."

        Not if you firewall it. I cannot see the point of this (except for academic exercise ofcourse).

        • Re:You forget (Score:5, Interesting)

          by Curien ( 267780 ) on Friday June 18, 2004 @07:46AM (#9461576)
          Huh? Without portknocking, you have to have at least /one/ listening service.

          The advantage with portknocking is that if someone was scanning IP ranges for computers running exposed services, you won't show up as a valid target. You'll look like an unused IP or a computer that's off (or one that's simply firewalled every port).
          • Unused IP? Yes, with TCP_BLACKHOLE, why not. But... if portknocking is active, it is also a kind of listening service - even if it won't show up on nmap, it also does listen for network events. At a given level of abstraction, this will be the same as network daemon listening on open port ;)

          • Re:You forget (Score:2, Informative)

            by claudius0425 ( 679268 )
            He has a good point. Consider, for example, a student at a university that forbids you to run any servers (say, UF with ICARUS). With portknocking, you could keep all ports closed yet, with minimal effort, open a transient hole in your firewall, allowing you to, say, access an ssh server, but only from the machine originating the portknock. This is particularly useful in a DHCP based environment, where a static firewall rule would be utterly ineffectual.

            DISCLAIMER: No, I do not attend UF, don't send in

            • Re:You forget (Score:1, Interesting)

              by Anonymous Coward
              That explains it for me. I couldn't think of a reason this is useful. It's only advantage over ssh is stealth. Stealth is of little advantage to white hats (please no, security through obscurity arguments). Black hats love stealth. This will be a great techology for open proxies, etc.
            • DHCP environments are a good example of when this method can give you more benefits than just having no open ports to scan -- which is a pretty darn big plus too start off with.

              I'd suggest that you incorpaorate something like a RSA-SecureID system -- so that you'd have a [nearly] unlimited supply of one time passwords -- and this method becomes even stronger.

              Remember the onion -- layered security.

              K.C.
          • if someone was scanning IP ranges for computers running exposed services, you won't show up as a valid target.

            Same is true if you run SSH on some obscure port, especially if you remove the version number, etc.

            Port knocking is obscurity, and obscurity is not security. People forget that a lot.
            • Obscurity is, however, a valid part of security. Even if I'm patched, up to date, and configured properly, I'd still prefer to give away as little info as possible.
            • Nope. You are wrong. Consider it as another key. Normal ssh would require you to have a username and a password. Paranoid firewall rules might say that you need to ssh from a specific IP. Even more paranoid rules would require that specific IP to portknock.

              Besides that point, what you say about ssh on an obscure port is much worse that you think. The very moment someone does a portscan, finds a responsive host (remember that a portknock protected computer wouldn't even show up) and then has open ports on s

              • someone does a portscan, finds a responsive host (remember that a portknock protected computer wouldn't even show up)

                Now this is wrong... A machine trying to be stealthy is far worse than a machine that admits it exists, but has no open ports.

                I say that because anybody can tell if an IP address is in use. If they find that they don't get any reply from pinging that host, they know they're dealing with a host trying to be stealthy, and will spend much more time working on it.

                If a machine just returns th

                • I guess the part I really had a problem with is the "security through obscurity" flippancy. I totally agree that simply hiding and hoping is worthless. But let's take the "scan port 22 and move on" example and delve. You say change ports and hide the version, I say basically the same thing, except do a better job of hiding.

                  Let's change the example into a lock on a door. With a normal door lock, you can look at it and determine the make and model, maybe check if there is a master key floating around. That w

          • Huh? Without portknocking, you have to have at least /one/ listening service.
            Again, what's the point? I can not see any legitimate purpose for this. The only reason I could see where you'd want to completely obscure the fact that a box has open ports is if you are up to no good -- eg, hiding a back door on a subverted box or running an unauthorized service on your employer's network. It may be an interesting hack, but it has zero practical value.

      • Re:You forget (Score:3, Interesting)

        by Khazunga ( 176423 ) *
        Just use a datagram service, like UDP instead of TCP. Have your protocol not reply to requests until the authentication is done. Presto! It works, has all the benefits of port knocking, and uses no clever trick.

        This is a solution in search of a problem....

    • So you'll still have a firewall for all other ports, leaving your sshd daemon visible, which may be flawed. And you'll ignore a new technology which will block off ALL ports and only open one to sshd, which may be flawed or not, if you know the right port sequence?


      um...

      • No, sire. I'm thinking about a very simple daemon, written in high-level language, that would manipulate my firewall rules using unencrypted OTPs. It could open ssh port for 5 seconds only to IPs, that gave right one-time password. Store only MD5 hashes of those one-time passwords on the server, and voila.

        In Python I could write such daemon in 30 minutes or so. "man ipfw" or "man ipf" would be the part, that would take me most time (not to mention testing, of course) :)

  • Freudian slip, much?

  • knock knock (Score:2, Funny)

    by kwoff ( 516741 )
    Knock, knock.
    Who's there?
    Kock.
    Kock who?
    Kock you!
    Well, my nephew would get a kick out of it, at least.

  • I'm confused (Score:3, Insightful)

    by epine ( 68316 ) on Friday June 18, 2004 @08:51AM (#9461890)
    This does nothing more than redefine an existing problem. It's still a communication channel between two participants, whether the bits are conveyed inside the IP packets, or as attributes of the IP header.

    The "genius" of this approach seems to lie in the fact that the closed machine makes no response whatsoever until a valid doorknock sequence is received, which renders the system more clandistine from a very narrow point of view.

    One of the reasons why ssh security negotiation is two sided is to eliminate replay attacks. The doorknock concept is going to have a problem with this.

    I find it interesting to imagine that the doorknock sequence is defined as a function of the IP address of the requesting system. This would eliminate a replay attack by an adversary who can snoop traffic, originate traffic under its own identity, but not actively impersonate.

    • Re:I'm confused (Score:5, Insightful)

      by CamMac ( 140401 ) <PvtCam@ya[ ].com ['hoo' in gap]> on Friday June 18, 2004 @09:22AM (#9462141)
      This isn't an attempt to redefine a problem, this is an attempt to provide a diffrent solution to a known problem. Two sided ssh security negotiation might work great for your application, but it might not be so hot for mine. Diffrent solutions have diffrent strenghts and weaknesses, and the more solutions we have, the better able we are to select one which matches our security needs. Options are a /good/ thing.

      And honestly, its a damn good idea with a simple implementation. Because its so simple to implement, there will be more than one portknock server. How would an external attacker know if a broken version of portknock was being used, or if there wasn't even a computer there?

      Pay attention to portknock, because you will see it again.

      --Cam

  • Re: Headline typo (Score:4, Funny)

    by mhesseltine ( 541806 ) on Friday June 18, 2004 @08:58AM (#9461948) Homepage Journal

    It's nothing major. It's just that Michael's "N" key is worn out from "approving" stories:

    Approve this one? N

    Approve this one? N

    Approve this one? N

    Approve this one? N

    Approve this one? N

    Approve this one? N

    Approve this one? N

    Approve this one? N

    Approve this one? N

    Approve this one? N

    Approve this one? N

    Approve a story on port knocking? Y

    Broken keyboard? Y

    That explains why it's so hard to get your stories posted. (wink, wink, nudge, nudge)

  • three things (Score:4, Interesting)

    by Hubert_Shrump ( 256081 ) <cobranet@@@gmail...com> on Friday June 18, 2004 @09:47AM (#9462372) Journal
    1. you have a single point of vulnerability in your daemon
    2. for the moderately paranoid, you can just shove all your stuff up into the ephemeral port range - most portscanners don't scan past 6000 unless you tell them to
    3. anyone that didn't think this thread would be mainly about 'kock' hasn't had their coffee. such as myself
    4. there is no item the fourth

  • Kock (Score:3, Funny)

    by dotz ( 683519 ) on Friday June 18, 2004 @10:02AM (#9462494)
    Kock is a real place. You don't belive me? Just click here [rootsweb.com]

    Anyway, dear /. editors, it's a great way to ruin a story. 90% of posts in this discussion are offtopic, just because you did a typo (for those who plan to mod me down - I did posted a serious comment already, have mercy!).

  • Why so complicated? (Score:3, Insightful)

    by technothrasher ( 689062 ) on Friday June 18, 2004 @10:31AM (#9462799)
    Why do you need to go to the trouble of hitting a one time sequence of closed ports rather than just knocking with a one time password in a single UDP datagram?
    • Why do you need to go to the trouble of hitting a one time sequence of closed ports rather than just knocking with a one time password in a single UDP datagram?

      Then there is a daemon which listens on that port and you may feed it with UDP stream trying to DOS it.

      • Then there is a daemon which listens on that port and you may feed it with UDP stream trying to DOS it.


        Yeah, that's a point... but if you know the port to DOS, you must have been snooping. If you're snooping, you can just DOS whatever service the knocking opens up regardless of the knock protocol. Port knocking just keeps port scanners from seeing open services, it doesn't guard against a targetted DOS attack.

      • Re:Why so complicated? (Score:5, Insightful)

        by Krunch ( 704330 ) on Friday June 18, 2004 @09:15PM (#9469343) Homepage
        And what stops you from DOSing the portknock daemon ? If you are concerned about DOS, just change the port it listens to every 30 minutes or so and have it be a function of current time. Something like this: port_number = md5_to_portnum(md5((++time)+secret_salt)). Now if you know the secret_salt and current time you know on which port the daemon is listening for the current 30 minute period. But no DOSer can tell. You can also change the password using the same technique.

        I think this is easier to implement and to use than port knocking.

  • I just realized why portknocking is so good (Score:5, Insightful)

    by doc modulo ( 568776 ) on Friday June 18, 2004 @02:08PM (#9465113)
    Traditionally, port communications are safeguarded by the application behind the port. This means that if you have 13 network applications, there are 13 possible ways of someone owning your system with a trojan.

    On the other hand, portknocking is handled by a single daemon that is simpler than most applications. Portknocking could even be handled by the OS.

    This means that instead of having to trust several net-connected programs with your system security, whose primary focus will probably not be safety, you only have to trust 1 program which IS focused on security. Added to that, a portknocking program is easier to make safe because it's simpler than most other programs which have to handle both network defence AND some other task (Instant Messaging).

  • has anyone read the thesis? (Score:2, Insightful)

    by Anonymous Coward
    I must say I'm quite disappointed in this. Anybody listening in on the "knock" will know the plaintext used in the encryption process. It's then a trivial matter to brute-force the password. This is because 99% of the time, the client will be run from the machine you're connecting from, giving the attacker the source IP and the destination port.

    Also, it seems that an ordinary portscan would add 32 random firewall rules, that would never be cleaned up.

    I'm not even going to mention that an MD5 hash is

  • Broken Implementation (Score:4, Interesting)

    by btg ( 99991 ) on Monday June 21, 2004 @04:01AM (#9482370)
    Not only is the concept stupid, but I looked at the guy's thesis for five seconds and his crypto is totally broken - there is a trivial known plaintext attack to recover the secret password if you can intercept knocks on the wire. The plaintext is [IP addr][port][action] for 4 + 2 + 1 bytes each. The last byte is pad - which is cunningly hardwired to null.

    The IP address makes up 4 bytes of a 7 byte plaintext (which is already small enough to brute force) and the IP address will be that of the knocking host. Wait, it gets worse! The "action" byte is basically "open" or "close" and the port bytes don't quite use the full 2^16 range. In other words I need to brute force a little less than 17 bits. This is only challenging if I want to make like ET and do it with a reprogrammed Speak N Spell.

    Back to sleep for me until version 5.0.
    • It's proof of concept, not "here, use this in your ultra secretive secure thing-a-ma-jig".

      I knew a guy who had ten locks on his door. You had to turn the key the same way to lock and unlock. He usually only locked two or three locks, when he left, simply because he figured, that by the time he gets home, a possible burglar still haven't unlocked the door (probaby by locking some of the unlocked locks).

      This is (to me anyway) somewhat the same thing.

      It may not be entirely difficult to figure out, what port
  • Okay, so we have portknocking, but do we have clients that can utilize it?

    Let's say I want to access machine X's ssh daemon, which utilizes portknocking, is there any ssh client today that can access it?

    Anyhow, I'm gonna name my firewall "Heavens door" when this works.

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close