Slashdot Mirror

← Back to Stories (view on slashdot.org)

Combining Port Knocking With OS Fingerprinting

Posted by timothy on from the belt-and-suspenders-and-tape-and-elastic dept.

michaelrash writes "Port knocking implementations are on the rise. I have just released fwknop; (the Firewall Knock Operator) at DEF CON 12. Fwknop implements both shared and encrypted knock sequences, but with a twist; it combines knock sequences with passive operating system fingerprints derived from p0f. This makes it possible to allow, say, only Linux systems to connect to your SSH daemon. Fwknop is based entirely around iptables log messages and so does not require a separate packet capture library. Also, at the Black Hat Briefings, David Worth has released a cryptographic port knock implementation based around one-time pads."

112 of 154 comments (clear)

  1. It's kinda cool by Lord+Kano · · Score: 5, Interesting

    but is anyone out there using port knocking for serious security?

    LK

    --
    "Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
    1. Re:It's kinda cool by Anonymous Coward · · Score: 3, Insightful

      it appears port knocking is a neat programming project and it seems fun to create a poc.

      it seems like a fad, and of course the authors of such programs will defend its usefulness.

      my opinion is that this technique is not new, and hackers have been using very similiar things for decades.

      and since he mentioned defcon, oh boy has that hacking con gone down hill. Bugs are just not as easy to find now days so the bar has been raised for h4x0rs.

    2. Re:It's kinda cool by quelrods · · Score: 1, Interesting

      no. Not only is it security through obscurity, but it slows down connections. ie: you have to go through the handshake sequence to start the connection. It's mostly a substitute for people keeping their patches up to date. Don't expect the NSA to use this anytime soon.

      --
      :(){ :|:&};:
    3. Re:It's kinda cool by TheLittleJetson · · Score: 1

      serious... this is better than password / challange -- WHY? -m

    4. Re:It's kinda cool by Lord+Kano · · Score: 5, Insightful

      Not only is it security through obscurity

      Only in the same sense that passwords are security through obscurity.

      Right combination of keystrokes, right combination of ports to knock, these sound very similar to me.

      LK

      --
      "Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
    5. Re:It's kinda cool by Sancho · · Score: 5, Insightful

      It's not.. I almost suspect you of trolling.

      The primary purpose of port knocking is to hide the fact that you have open ports to begin with. You don't want to have those ports unprotected once the right knock sequence is in place. You want both password/challenge AND port knocking so no active scanner detects your open ports.

    6. Re:It's kinda cool by Anonymous Coward · · Score: 3, Informative

      Port knocking uses a specific authentication scheme, most often based on one-time passwords or other cryptographic means, to open access from a specific address for a very brief period of time.

      I am not aware of PK schemes that just open the port wide once you send in a magic passphrase, that would be dumb.

      In this regard, PK is quite similar to any other access scheme; the access control is a bit coarse, but so are all protocol-specific NAT helpers in firewalls, and most folks do not complain.

    7. Re:It's kinda cool by HermanAB · · Score: 4, Interesting

      I use portsentry for protection against scans. The result is that all my ISP scanners are now in hosts.deny and consequenlty I can run any server I want and they will never know and can't complain about it...

      --
      Oh well, what the hell...
    8. Re:It's kinda cool by eric76 · · Score: 4, Insightful

      There is absolutely nothing wrong with using something a bit obscure to help fend off attacks.

      The only time that "security through obscurity" is wrong is if that is your entire approach to security.

      Even if you have the latest and greatest copy of the most secure software written to perform some service, there is always a possibility that there is something exploitable that is yet unknown.

      Port knocking is an excellent way to greatly reduce the probability that someone will be able to use a newly discovered exploit from using it against your server before an update is available to fix the exploit.

      Of course, if someone is in the right place and can monitor the network traffic from another computer somewhere along the path, they can discover the port knocking sequence. For that reason, you still need your normal security and you still need to keep the patches up to date.

      But the result will still be a vastly improved possibility of avoiding an attack when a vulnerability is found.

    9. Re:It's kinda cool by Tony+Hoyle · · Score: 2, Informative

      Well, as long as it goes through tcpwrappers anyway....

      Most services don't though. You should be updating iptables not hosts.deny.

    10. Re:It's kinda cool by michaelrash · · Score: 1

      What about the set of hackers (crackers) that have found 0-day attacks? Granted the number of people that fall into this category is extremely small, but the data on my personal system is just too important to risk it. I want an additional layer of security. Although security through obscurity is not good if it is the _only_ protective mechanism, having another layer always helps:

      "Security Through Obscurity" Ain't What They Think It Is

    11. Re:It's kinda cool by michaelrash · · Score: 1

      You might want to check this link out:

      Hos is psad different from portsentry?

    12. Re:It's kinda cool by rekt · · Score: 1
      Port knocking is an excellent way to greatly reduce the probability that someone will be able to use a newly discovered exploit from using it against your server before an update is available to fix the exploit.
      This is only true for vulnerabilities in services which allow for or rely on attackers making new connections. many vunerabilities take other forms, and port-knocking is no protection against them. For example:
    13. Re:It's kinda cool by Raven42rac · · Score: 1

      The point is that they could, not that anyone is. The article clearly states "This makes it possible to allow, say, only Linux systems to connect to your SSH daemon." Why are these types of comments modded up?

      --
      I hate sigs.
    14. Re:It's kinda cool by nozzle! · · Score: 1

      I would refer you to the original post and suggest following the links to read about p0f here and here and various port knocking implementations. Port knocking has been covered in /. before and the original idea included consideration of a replay attack possibility. Thus, encryption of the knock sequence.

    15. Re:It's kinda cool by Gyorg_Lavode · · Score: 1

      Attacks come in three stages: Reconnaissance, attack, exploitation. The idea is to have security in each section. The huge advantage of port knocking is that it offers security in the first stage. It prevents reconnaissance. You can password protect what services you are providing without revealing any information at all about them. It is not security through obscurity. It guards against a very specific portion of the attack.

      --
      I do security
    16. Re:It's kinda cool by Afrosheen · · Score: 1

      If you'd read the slideshow presentation pdf at the blackhat site, you'd learn that there are additional measures that are useful for securing connections like these.

      The addition of a one-time pad to the port knock verification process is helpful.

    17. Re:It's kinda cool by Minna+Kirai · · Score: 1

      Only in the same sense that passwords are security through obscurity.

      Nope. Port knocking is truely Security Through Obscurity in the worse way.

      PK is an abuse of the TCP/IP protocol- by repeatedly sending data to a "closed" port which the remote is really listening to, you can send some data which a typical eavesdropper might ignore. But that only lasts until PK becomes common enough that network-sniffing tools get checkboxes added to record this new data stream.

      Right combination of keystrokes, right combination of ports to knock, these sound very similar to me.

      Yes, they are similar! So similar that port-knocking doesn't provide any more security than straightforward passwords... so why even bother?

      In the long run, all the "attempting to talk to closed ports" nonense is just a temporary evasion of loggers.

    18. Re:It's kinda cool by Minna+Kirai · · Score: 1

      The primary purpose of port knocking is to hide the fact that you have open ports to begin with

      That benefit can be essentially obtained without portknocking.

      The practical effect of PK is that you have an additional wrapper protocol that must be negotiated before your REAL TCP daemons will talk to someone. That outside wrapper could be implemented with TCP (hiding all your various services behind one port #), UDP (a single packet containing authent key which wakes up the daemon), or PK as we know it.

      All 3 of those methods are moving your N open ports behind 1 protective layer. But which protocol that wrapper is implemented in doesn't change it's overall effectiveness... except that PK messages are currently likely to be ignored by modern loggers, and/or difficult to read even if they do get logged.

      The real benefits of PK is simply that attack tools and sysadmins aren't used to seeing it yet.

      AND port knocking so no active scanner detects your open ports.

      Imagine two possible future worlds. In one, all servers require PK, appearing to have zero ports open, but really running potentially 100s of services behind that shield. In another world, all servers have exactly one port open: 22/ssh, which can gateway authenticated clients to any one of 100s of services that might be running.

      There's no real difference between those worlds.

    19. Re:It's kinda cool by fatphil · · Score: 1

      That's because you're ignoring Kerchoff's principle.

      Your keystrokes can be transmitted over a non-evesdroppable keyed session. Port-knocking can't.

      FP.

      --
      Also FatPhil on SoylentNews, id 863
    20. Re:It's kinda cool by Lord+Kano · · Score: 1

      Your keystrokes can be transmitted over a non-evesdroppable keyed session. Port-knocking can't.

      The knock sequence is supposed to change each time. Repeating a previous knock will provide you with nothing.

      LK

      --
      "Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
    21. Re:It's kinda cool by jhoffoss · · Score: 1
      Don't expect the NSA to use this anytime soon.

      You're right. They've probably been using it for years already.

      --
      Linux: The world's best text-adventure game.
    22. Re:It's kinda cool by mewphobia · · Score: 1
      You want both password/challenge AND port knocking so no active scanner detects your open ports.

      I must admit that I haven't looked at the various port knocking implementations going around, as i've been too busy on other projects. However, I can't understand how an active scan could even detect ports open - the ports shouldn't even be opened! Why doesn't the port knocking daemon just open a raw socket in promiscuous mode? that way, noone on the outside would even know you have the scheme in place.

    23. Re:It's kinda cool by mewphobia · · Score: 1
      Imagine two possible future worlds. In one, all servers require PK, appearing to have zero ports open, but really running potentially 100s of services behind that shield. In another world, all servers have exactly one port open: 22/ssh, which can gateway authenticated clients to any one of 100s of services that might be running.
      There's no real difference between those worlds.

      I'm sorry, but to me there is. SSH has been known to have bugs. You're giving attackers a known target. With port knocking, the only way to even have a target is to know a knock sequence. Subtle difference, but I think it's important to make the distinction.

    24. Re:It's kinda cool by michaelrash · · Score: 1

      In the fwknop implementation, there are _no_ open ports, just as you suggest above. Fwknop relies on iptables to do two things: 1) log all connection attempts to ports that are not open by design, and 2) drop all such connection attempts. This way the knock client never receives any traffic from the server whatsoever (e.g. no tcp resets or successful connection completions) as it sends the knock sequence across the network. Fwknop exclusively uses the resulting iptables log messages to validate the knock sequence and to passively fingerprint the source operating system. Fwknop could have used a packet capture library to get the same data, but implementing it around iptables logs seemed like an elegant solution since it requires the proper configuration of your firewall at the same time.

    25. Re:It's kinda cool by eric76 · · Score: 1

      I don't think anyone claimed that port knocking is the solution to all security problems.

      Port knocking has one purpose - to hide services from casual or dedicated port scanners.

      Anyone who does not know that the service is there because it is obscured by port knocking cannot attack it when a vulnerability is discovered.

      As a result, your security is enhanced to some degree.

    26. Re:It's kinda cool by theLOUDroom · · Score: 1

      Only in the same sense that passwords are security through obscurity.
      Right combination of keystrokes, right combination of ports to knock, these sound very similar to me.

      Except that anyone else on the net can't insert characters into the middle of your password while you type it.

      If I know your ip address, and what host to knock on, I can send out forged "knocks" and you'll never be able to enter the right sequence.
      Contrast this to a password, where

      --
      Life is too short to proofread.
  2. How much more is needed? by Anonymous Coward · · Score: 2, Insightful

    With a large port knock routine say 20 ports or more, can't you be sure it's YOUR box that's comming in? More defense and limitations are good, sure, but why filter by OS? Is it in case someone gets by the knock?

    1. Re:How much more is needed? by vranash · · Score: 5, Interesting

      Because the next step is to generate 'fake' OS fingerprints for the client computer, thus insuring not only must someone reply with the right sequence, but also send back the nuances of a specific OS to do so... kinda like recieving a callback to which you must reply in the proper accent before you'll be allowed in :)

      The above is completely conjecture, but it sure does sound cool ;p

      -- vranash

    2. Re:How much more is needed? by Xepo · · Score: 4, Interesting

      Well, as another poster pointed out, if someone sniffs what ports you're connecting to, then it would be simple to replay that knock. That's the reason you need a security level underneath it, and shouldn't rely on port knocking unless it's a changing sequence (like the one-time pad idea also mentioned in the post).

      I'm not quite sure how the OS detection is supposed to help. Maybe you could customize things for different OSes? As long as port knocking schemes are implemented on two OSes, you could let the port knocker determine which OS you're connecting from, and connect to a specific service depending upon it. I don't really see any other use for the OS-dependent port knocking, but it's something that's cool, and not been done before, so I guess it's news-worthy.

    3. Re:How much more is needed? by Xepo · · Score: 2, Insightful

      Correct. The OS fingerprint isn't really even that hard to fake. Read the nmap man page if you're curious, it explains a bit more about it. It basically just has to do with how quickly, and in what way the ip layer responds to different things. (I've not looked at the link in the article so I dunno if it explains OS fingerprinting at all, or if it just says that the new port knocking implementation implements it)

    4. Re:How much more is needed? by michaelrash · · Score: 2, Insightful

      Yes. It is just another hoop we can make an attacker jump through. If someone sniffs the knock sequence, they can always replay it but it will only be honored if they replayed the sequence correctly (fwknop implements timing delays in knock sequences) _and_ they generate the sequence from the required OS. Of course, using something like Packet Purgatory OS neuances can be spoofed, but at least the bar is just a little higher.

    5. Re:How much more is needed? by pebs · · Score: 2, Funny

      More defense and limitations are good, sure, but why filter by OS?

      It's so we can block out all those Linux machines, because we all know that's where the hackers are coming from :)

      --
      #!/
  3. OS fingerprinting, whew! by Anonymous Coward · · Score: 4, Funny

    thank goodness, if there's one thing a hacker can't get his hands on, it's a copy of Linux!

    yuk yuk yuk

  4. Layers by danielrm26 · · Score: 4, Interesting

    1. TCPWrappers (has to be be right IP and/or daemon)
    2. Portknocking (has to have the right sequence)
    3. Passive Fingerprinting (only Linux and BSD systems can connect)
    4. Keys Only (you must have the correct DSA private key)

    Usually unnecessary, yet very interesting - much like Slashdot itself....

    --
    dmiessler.com -- grep understanding knowledge
    1. Re:Layers by archen · · Score: 1

      The interesting thing about port knocking is that it can protect a daemon that is vulerable. For instance, if sshd is unpatched and an exploit just needs to be able to connect, then portknocking will at least protect the server from people just checking your ports for sshd .

      Personally I think the fingerprinting part is a bad idea, since I often don't know what kind of computer I'll need to connect from, or maybe I was booted into windows that day to have a sane sound recording enviornment.

    2. Re:Layers by burns210 · · Score: 1

      OSI Layers...

      TCPWrapper is IP, thats layer 3.
      Portknokcing is ports, thats layer 5.
      Keys Only is encryption, thats Presentation, layer 6
      Passive Fingprinting is the OS, layer 7.

      so we have layers 3,5,6 and 7 of the OSI model covered. Now, for the other 3...

      layer 1: Run a dedicated line? Not very practical.
      layer 2: Filter on MAC address, not hard to spoof, but it would require knowning the MAC to spoof before hand.
      layer 4: TCP... hmm, you got me. but 5 layers of security is pretty friggin good.

    3. Re:Layers by danielrm26 · · Score: 1

      I like where you went with your post, but ports are functions of TCP and UDP - which are transport layer protocols (at layer 4). :)

      As for the MAC address filtering, you can do that with Netfilter as well, but it wouldn't help much in a WAN setting since you are only going to see the MAC address of your next router hop.

      --
      dmiessler.com -- grep understanding knowledge
    4. Re:Layers by voixderaison · · Score: 1

      $ cat knowledge | grep understanding cat: knowledge: No such file or directory $ find . -name "knowledge" $ Hmm...

      --
      Things should be made as simple as possible, but not any simpler. -- Albert Einstein
  5. The more complicated you make it, by Anonymous Coward · · Score: 5, Insightful

    the bigger is the chance of screwing up. The point of port knocking is to have a simple and therefore less bug prone layer around real authentication systems like ssh, so that when a bug in ssh is found, portscanners don't find your vulnerable service. Complicated port knocking systems defeat the purpose of port knocking.

    1. Re:The more complicated you make it, by Anonymous Coward · · Score: 2, Insightful

      Good.

      Now look at the complexity and functionality of SSH, and its share of security problems over the past years.

      Then look at port knockers, their simplicity and minimal reliance on bloated libraries. Note they only use a single, simplistic - but cryptographically proven - authentication scheme based on things such as basic symmetric ciphers or one-way shortcut functions, with implementations that could hardly go wrong.

      The whole point is, SSH and many other complex services have proven to be not reliable and secure enough to be left open wide without losing sleep over it. Protecting them with a simple and secure solution consisting only of dozens or hundreds lines of code makes sense.

  6. In other news... by AvantLegion · · Score: 4, Funny
    Microsoft IIS has implemented a similar scheme to only allow HTTP sessions to Microsoft OS running clients.

    1. Re:In other news... by Nicholas+Evans · · Score: 1

      Breaking news (Day One): Prominent eBusinesses lose millions over IIS update!

      Breaking news (Week later): IIS loses 30% market share due to stupid move on the part of the developers!

      MS may be monopolisitc, but they aren't exactly stupid.

      --
      The Yasashii Syndicate ||
    2. Re:In other news... by v1x · · Score: 1

      forgive my very little knowledge on the subject, but wont it be possible to sniff for & duplicate the port-knocking behavior of windows using any other OS?

    3. Re:In other news... by Curtman · · Score: 2, Funny

      I was thinking more along the lines of banning any SCO products. In the tradition of appending 'e' to the front of everything, I call it 'eSnobbing'.

    4. Re:In other news... by jack_csk · · Score: 1

      I am quite surprised if you don't know that Microsoft is doing so.

      From ActiveX to DHTML to .NET, Microsoft have NEVER try to make their products compatible on other platforms / software

  7. Port knocking and some added ingredients by ThufirHawat · · Score: 5, Interesting

    While port knocking is by now an established technique, I do not think OS fingerprinting adds anything useful, because the ease of static replay attacks is left unchanged by OS fingerprinting.
    Though not that easy, OS spoofing is not remarkably labour intensive, and setting up a "OS generator" who will replay the static attack with every known OS is a distinct possibility.
    In other words, though a nice intellectual possibility, it is perhaps of rather limited application.
    Now, mixing instead knocking and a cryptographic application seems to me instead more promising.

    --
    Thufir Hawat
    Part-time Mentat
    1. Re:Port knocking and some added ingredients by danielrm26 · · Score: 1

      "Now, mixing instead knocking and a cryptographic application seems to me instead more promising."

      Yeah, that's what the other guy mentioned did. He's got a one-time-pad implementation that looks pretty cool.

      --
      dmiessler.com -- grep understanding knowledge
    2. Re:Port knocking and some added ingredients by cynic10508 · · Score: 1

      While port knocking is by now an established technique, I do not think OS fingerprinting adds anything useful, because the ease of static replay attacks is left unchanged by OS fingerprinting.

      The problem I see with OS fingerprinting is the assumption that certains OSes are running certain (vulnerable/potentionally trojaned) applications. I don't think you can safely make those assumptions.

    3. Re:Port knocking and some added ingredients by gabba_gabba_hey · · Score: 2, Informative

      The problem I see with OS fingerprinting is the assumption that certains OSes are running certain (vulnerable/potentionally trojaned) applications. I don't think you can safely make those assumptions.

      While the method you mention is one way of fingerprinting, most modern tools use a more sophisticated approach. Here is a fairly simple explanation of some of those methods if you're interested.

  8. Port knocking, firewalls, DMZs,... by Rosco+P.+Coltrane · · Score: 4, Insightful

    are techniques I've seen appearing for the last 10 years that are designed to compartment sections of the net. They make me sad, because that's definitely not what the net was intended to be, i.e. a global interconected network of machines to freely communicate. Instead, the net is slowly being segregated, and you'll soon have to show some sort of proof of identity to do anything other than HTTP. If you don't believe me, just consider how hard it is to do something as mundane as a DCC CHAT on IRC today, as opposed to, say, in 1994.

    I realize the need for these things, basically forced upon us by the combination of commercial interests, shitty insecure OS, script kiddies and greedy crackers (not hackers), but all the same, I can't help realize that the internet of today is a far cry from what it was intended to be in terms of freedom of communication...

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
    1. Re:Port knocking, firewalls, DMZs,... by danielrm26 · · Score: 4, Interesting

      I agree with your points, but surely you must see that this commentary of yours applies to pretty much every invention known to man that is both powerful and started out being free and open.

      Look at air travel - there you have spend a ton of time just getting on a plane because of very few bad people. The Wright brothers didn't want this, I'm sure, but it doesn't mean the invention is being perverted in any way; it only says that our world is hostile and that we must protect ourselves from ourselves. Anything useful and completely open these days is ripe for exploitation.

      --
      dmiessler.com -- grep understanding knowledge
    2. Re:Port knocking, firewalls, DMZs,... by grasshoppa · · Score: 4, Insightful

      Never under-estimate the power of stupid people in large groups.

      I can't help realize that the internet of today is a far cry from what it was intended to be in terms of freedom of communication

      Um...wasn't the internet born at the department of defense? Awfully nice of them, to make this huge network for freedom of communication.

      Oh, wait, that's not what it was intended for. It was intended to be a network of communication, built to survive outages of several large nodes, in case of a nuclear attack. It's only been as more and more people began romaticising it, that we've come up with this free communications thing.

      While I'm not apposed to it, I am realistic about it. Would you leave your car, complete with keys, parked in a stadium parking lot, with an open door, and a sign stuck on the steering wheel saying, "Please don't take"? That's essentially what you do with your computer when you go online without any sort of protection ( short of the sign, mind you ).

      --
      Mod me down with all of your hatred and your journey towards the dark side will be complete!
    3. Re:Port knocking, firewalls, DMZs,... by Sancho · · Score: 2, Insightful

      What if the choices are between not running a server and running a portknocking server?

      I have a private server I use for e-mail, irc, and as a convenient, central location to store files. I have no interest in making this server public--it's only on the Internet because to set up a dedicated line to it would be prohibitively expensive. I don't even want people to know the server is there, and if they do find out it's there, I want security to be as tight as possible. Port knocking, in a way, helps to meet my goals. If I was required to let anyone onto my server, I would take it down, which would be the loss of a private asset.

      But that doesn't mean you're not right, in a way. The problem with the world today is that it runs on money. Very little is free. Even some HTTP is pay-per, and that's just the way it is until someone finds a way to pay the bills without milking the customer.

    4. Re:Port knocking, firewalls, DMZs,... by enigma48 · · Score: 4, Insightful

      I'm not a history buff but I can't recall anything I've read about ARPAnet being created with the intention of complete access to all connected machines.

      I think the majority of people - geeks included, but not to the exclusion of everyone else - think the internet, on the whole, is performing fairly reasonably. Just like in reality, when you have a small group of people working together, issues of trust are much easier to deal with compared to working with hundreds of millions of people.

      Blaming "commercial interests, shitty insecure OS, ..." are symptoms of having a ton of people connected. Assuming the internet would be perfect if those bad people didn't exist, there'd be a new group people didn't like: spammers, NET SENDers, etc. Once they are gone, we'd be left with people that use software we don't like, or people from a country we don't like.

      Soon enough, the Internet would be compartmentalized exactly the way you fear - into groups of like-minded people instead.

      The Internet isn't supposed to be utopia. It was about making resources easier to access and it does that job amazingly well, given the imperfect people using it.

    5. Re:Port knocking, firewalls, DMZs,... by zangdesign · · Score: 1

      I can't help realize that the internet of today is a far cry from what it was intended to be in terms of freedom of communication...

      As the internet becomes more and more available to people, we begin to realize what complete a-holes people can be, thus the need for more and more security measures.

      --
      To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
    6. Re:Port knocking, firewalls, DMZs,... by grasshoppa · · Score: 1

      and as more and more big greedy companies and individuals lay their grubby hands on it, it's turning into something that you could call the CorpyWeb...

      In what way? What, specifically, is "corporate" about the internet. What has been added to it in say, oh, the past five years, that would make you think that?

      --
      Mod me down with all of your hatred and your journey towards the dark side will be complete!
    7. Re:Port knocking, firewalls, DMZs,... by eric76 · · Score: 1

      The first four sites on Arpanet were UCLA, Stanford, UCSB (University of California Santa Barbara), and University of Utah.

    8. Re:Port knocking, firewalls, DMZs,... by Ollierose · · Score: 1

      I think he means the bit where you can now go to www.cocacola.com as well as all those university/govt sites.

      Thhe web has become a lot more corporate, in the same way television has (due to advertising). I'm fairly sure that initially, TV was just the programmes and nothing else, although I'm too young to be a primary source ;)

    9. Re:Port knocking, firewalls, DMZs,... by fprefect · · Score: 1

      That's fine, feel free to leave your credit card numbers and other personal data in a public FTP server, feel free. Some of us have data that we do want to share and other that we don't.

      --
      Matt Slot / Bitwise Operator / Ambrosia Software, Inc.
    10. Re:Port knocking, firewalls, DMZs,... by Minna+Kirai · · Score: 1

      I'm fairly sure that initially, TV was just the programmes and nothing else,

      Well yeah. And those programs were sponsored by RCA, which sold the TVs needed to watch them.

  9. Security Through Obscurity by gst · · Score: 4, Insightful

    Not more - not less. All that portknocking does is shifting the security to a layer where it doesn't belong.

    And even if you don't want others to see that there are services running on your host there are better solutions. e.g. sending a special string to some UDP port.

    If someone can sniff your traffic and he knows about portknocking it's trivial for him to detect it. If someone can't sniff your traffic there's no advantage in using portknocking.

    1. Re:Security Through Obscurity by RC515 · · Score: 4, Insightful

      Port knocking has one specific and reasonable purpose: It hides open ports from port scanners. Yes, it's security by obscurity, but as it's supposed to be another layer, it can increase security if, and only if it's simple enough that there is a near-zero chance of introducing new exploitable bugs into the system. Passive monitoring is not necessarily unexploitable. There are bugs in packet capture tools. There will be exploitable bugs in complicated port knocking daemons. Keep port knocking simple and it can be a valuable security enhancement. Make it complicated and it becomes another thing that can break.

      Port knocking buys you the time between a new ssh exploit and the fix. It significantly reduces the chance of being found by portscanners and therefore of being hacked. You still have to fix ssh though.

    2. Re:Security Through Obscurity by Xepo · · Score: 2, Insightful

      The specific example the parent to your comment cited was sending a string to a UDP port. I believe he understands the advantages of port knocking, which you explained unnecessarily. UDP is connectionless, and as far as I can tell, there's not much difference between sending a standard string to UDP to tell the OS to open up the port to you, and port knocking for the same purpose. However, the differences in implementation are vast. UDP is already implemented, whereas these port knocking solutions are still in development. UDP is probably going to be a lot easier to implement without interfacing with the system firewall, hence a lot simpler, and not introducing bugs into your firewall system. About the only advantage port knocking might have over a UDP string is exactly that -- It lays on top of your firewall instead of underneath it, but I'm not quite sure that that would have any advantages whatsoever.

    3. Re:Security Through Obscurity by OzRoy · · Score: 4, Interesting

      People who make blanket statements like "Security through obscurity is bad" really annoy me. What a load of crap.

      Secuirty through obscurity is bad when it's the only form of security. However, what is bad about using it to enhance existing security? What is bad about making things that little bit more difficult for a hacker?

      No where in this has the author said you should replace your existing security models with this. All it's done is add another layer to help disguise your existing security making it that much harder to crack. No one has "shifted" the security anywhere.

    4. Re:Security Through Obscurity by Anonymous Coward · · Score: 1, Insightful

      Huh ? Did you read the article ? Hiding your pincode for your credit card is security through obscurity, not more - not less. See how stupid this is ?

      Security through obscurity is valid in some case, when the obscurity is deep enough that guessing in the dark is time expensive and must be repeated for each intrusion, and simple enough for the user. For example a security based on hiding logic only needs 1 successfull attempt to be broken (guess the logic and the security is broken until changed, which is not simple), and using a weak password is not time expensive to crack, so both are not valid use of StO.
      In the case of port knocking, since it's based on a port sequence, it's analogue to a password, which means that it depends on the user choice of a good sequence (i.e. not trivial).

      If you're concerned about the safety of the communication channel, The same problem arises also with traditionnal passwords. Then using One Time Pads (as suggested by the article) solves this problem.

    5. Re:Security Through Obscurity by Baal+Sebub · · Score: 1
      And even if you don't want others to see that there are services running on your host there are better solutions. e.g. sending a special string to some UDP port.

      Sounds interesting. Is there an implementation of this scheme already available?

      --
      120 chars are not enough for a signature. I have discovered a truly remarkable proof which this margin is too small to c
    6. Re:Security Through Obscurity by wolfb · · Score: 4, Interesting

      I agree that UDP could be used similarly to port knocking. Both methods will serve equally well when the attacker is unaware of the method you choose to use. (true security through obsecurity). I also agree that both methods are equally vulnerable if the attacker can sniff your network traffic, and they can get in by replaying the requests.

      However, lets assume that the security daemons are *not* vulnerable to replay type attacks becuase we use one time pads, or computed keys or something. In this case, sniffing will tell the attacker what method is in use, but it won't allow them to get in by simply repeating a successful login sequence. Are the methods still equivalent?

      I would think that port knocking would still be safer of the two. The port knocking monitor is still sitting behind the firewall, isolated from the network traffic. It would be more difficult to induce a failure in the monitor. Even if the monitor failed, the security would revert to the firewall -- which means you don't get in.

      On the other hand, your UDP daemon would have to be written just as carefully as the services you are trying to protect. A buffer overflow, or any similar flaws in your daemon could allow someone to break in through your daemon. And such a flaw could be exploited blindly too -- all the attacker would have to suspect is that you are using a flawed daemon.

      Am I wrong?

    7. Re:Security Through Obscurity by groomed · · Score: 4, Interesting

      Not more - not less. All that portknocking does is shifting the security to a layer where it doesn't belong.

      Yes, but that's exactly the point. Portknocking is a steganographic application: it doesn't protect the message, but hides the existence of the message. It does so precisely because it interferes at a layer where it doesn't belong.

      And even if you don't want others to see that there are services running on your host there are better solutions. e.g. sending a special string to some UDP port.

      No, because having a server listen on a UDP port clearly signals the expectation of meaningful communication. The equivalent of portknocking would be a server that listens on a UDP port, but rather than looking at the string it receives, looks at (say) the delay between each byte received. Obviously network delays and other uncontrollable factors make this impractical.

      If someone can sniff your traffic and he knows about portknocking it's trivial for him to detect it. If someone can't sniff your traffic there's no advantage in using portknocking.

      It's not that simple. Even if somebody can sniff traffic in principle, he can't sniff everybody's traffic all the time. He has to evaluate which targets are likely to yield anything of value. Since a system protected by portknocking does not give him any clues of what he can expect to find, why would he sniff your traffic?

    8. Re:Security Through Obscurity by rekt · · Score: 1
      No, because having a server listen on a UDP port clearly signals the expectation of meaningful communication.
      How, exactly does it do that? my understanding of UDP is that there is no indication to the sending computer that anything happened on the receiving end. The reason you can portscan TCP is because of the handshake required to open a stream connection. There is no "expectation of meaningful communication" with UDP.

      Seriously, read RFC 768, which defines UDP. It's a quick read. There's no way for a sender to know what happens to the UDP packets you send.

      Even if somebody can sniff traffic in principle, he can't sniff everybody's traffic all the time. He has to evaluate which targets are likely to yield anything of value. Since a system protected by portknocking does not give him any clues of what he can expect to find, why would he sniff your traffic?
      well, if you actually use the service you are protecting with portknocking, then there will be a suspiciously non-zero amount of traffic to and from your machine via port 22 (if ssh is what yer protecting), even though that port is not open to the casual scanner.

      So if the relevant traffic-sniffing malware can catch data going to your machine, it would be trivial for it to figure out that the service is running. All it then needs to do is to capture traffic immediately prior to your next stream initiation to figure out what is going on.

      Seems to me that a single, timestamped (and therefore non-replayable), cryptographically-generated UDP packet to a cryptographically-chosen UDP port would offer as much added security as port knocking (even with the one-time pad mentioned in the post). But the UDP technique has fewer complications in the implementation, which means it's more likely to be built correctly, which is a big part of security.

    9. Re:Security Through Obscurity by Alan+Hicks · · Score: 1
      The specific example the parent to your comment cited was sending a string to a UDP port. I believe he understands the advantages of port knocking

      I don't, and I don't think you appreciate it either. The OP said that if one could sniff the traffic going to your node on the net that port knocking was trivial to get around. All arguments of that aside, how does having an open UDP port listening for some traffic make things any better? A good UDP scan will turn up your listening daemon (which may be vulnerable to some attack, thus making everything you've done a complete waste of time) and the attacker can sniff the traffic on that one udp port. This results in a lot less traffic that the attacker has to sort through to determine the keys to open your blocked port(s).

      I can hear what you're saying already. Use a means of speaking to that UDP daemon that makes use of encryption. I'm not going to go very in depth as to why I think this is a less than ideal solution, except to say that port knocking works, and it doesn't require the complications and overhead of what you're suggesting.

      --
      Slackware, what else when it must be secure, stable, and easy?
    10. Re:Security Through Obscurity by Xepo · · Score: 1

      I do appreciate the advantages of port knocking, but I was under the impression that there's no such thing as open/closed UDP ports if you're not on that box. Is there an ICMP or other response to let boxes know that UDP ports are closed when something is sent to them? I just assumed that there was no response by default to UDP, and if there was no response from the daemon that watched for the UDP string, then it'd be the same thing.

      But no, using encryption on the UDP daemon would be making it more complex, very similar to the encrypted port knocking sequence, I wasn't going to suggest that solution, because I understand that the goal is to hide the daemon from anyone that's looking for it. I thought that listening to a UDP port would do that, but apparently I was wrong?

    11. Re:Security Through Obscurity by calidoscope · · Score: 1
      IIRC, you are right about UDP ports.

      One way to increase security would be using a range of UDP ports, encrypting a timestamp and perhaps serial number to prevent replay attacks.

      --
      A Shadeless room is a brighter room.
    12. Re:Security Through Obscurity by Xepo · · Score: 1

      Ahh, according to another poster, I'm not and now that I think about it, it does make sense that it'd send an ICMP response to a closed port.

      The thing about increasing security is only partly true. Encrypting a time stamp and stuff would make the protocol more secure, but the idea is to have something which is amazingly simple, so that there are very few bugs, and close to no exploits for it, as an extra layer for the real security which should be implemented into the daemon that this one is covering for.

      After reading the other responses to my post, I do like the port knocking idea. Hiding a daemon is a good thing, and using UDP just exposes another daemon, unlike port knocking.

    13. Re:Security Through Obscurity by fatphil · · Score: 1

      No.

      Listen to what gst said.

      This is nothing to do with bugs at all; you're conflating the issue with irrelevancies.

      This is nothing more than an additional evesdroppable side-channel.

      Full stop.

      As such it in itself provides zero extra security, assuming Kerchoff's principle, and does so _inefficiently_. dst's UDP equivalent is equally secure (zero against the typical theoretical opponent), but far more efficient resource-wise.

      FP.

      --
      Also FatPhil on SoylentNews, id 863
    14. Re:Security Through Obscurity by voixderaison · · Score: 1
      my understanding of UDP is that there is no indication to the sending computer that anything happened on the receiving end.
      UDP port scanning is possible since most TPC stacks send an ICMP port unreachable message in response to a UDP packet sent to a port that's not listening. Ports that don't respond have a listener. Of course, packets might get dropped and so forth but the determined can rescan the list of listeners they accumulate to refine the accuracy of the scan.

      Some TCP/IP stacks (for example Lexmark network printers) don't send an ICMP port unreachable and may appear as though every unused port is an open UDP port.

      You might be interested in this brief introduction to various port scanning techniques.
      --
      Things should be made as simple as possible, but not any simpler. -- Albert Einstein
  10. these ports are made for knockin' by Anonymous Coward · · Score: 2, Funny

    and that's just what they'll do

    one of these days these ports

    are gonna walk all over you........

  11. Daemon watching iptables by Goodbyte · · Score: 2, Interesting

    Am I the only one to wonder why the author made a deamon that watches iptable-logs and then modify the ruleset when a matching knock sequence is found instead of implementing a iptables match module instead?

    Same goes for psad (by same author) -- I thought the purpose of iptables was to allow plug-in modules to be COMBINED.

    1. Re:Daemon watching iptables by michaelrash · · Score: 1

      Because certain things should not be implemented within iptables. For example, fwknop supports encrypted knock sequences with the Rijndael block cipher; psad supports email alerts to DShield, parsing of Snort rulesets, whois and reverse dns lookups, etc. Such functionality does not belong in iptables itself.

  12. NOT a one-time pad by Dwonis · · Score: 4, Informative

    This is a one-time password system, which uses hashes, just like S/Key does. This is NOT a one-time pad system.

  13. Eh? by sakusha · · Score: 1

    I thought port knocking was definitively debunked as security through obscurity.

    1. Re:Eh? by Tony+Hoyle · · Score: 1

      Port knocking seems a bit pointless (even dangerous - I don't run software on my firewall and am not going to start running undested 'knocking' daemons with the ability to open ports... hell, they'll be saying upnp is sane next...)

      However security through obscurity is not the reason. Most security is to some extent reliant on obscurity (eg. you can bet there are security bugs in the browser you're using, but nobody knows about them yet). Every time you enter your password to login you're relying on obscurity (unless you're in the habit of posting your password on public websites).

      Where obscurity is wrong is where you know about the vulnerability and hope nobody else has guessed it yet, so you try to keep it quiet rather than fix it.

      Ruinning open services and using knocking to 'hide' your server is a bad use of security through obscurity (if someone sniffs your knock there's no other layers and you're dead).

      Running nothing but an ssh daemon then hiding it behind another layer is a good use (but redundant if you're using PKI to authenticate anyway).

  14. Watching the logs.. by Anonymous Coward · · Score: 3, Insightful
    I always considered watching logs to be a very ugly and inelegant way of doing port knocking. Netfilter is stateful, why not make use of it?

    Use the recent match module and something like the following for requiring ports 1000, 2000 and 3000 to be knocked in order and within 30 seconds before allowing ssh from a particular host:
    iptables -A INPUT -p tcp --dport 1000 -m recent --remove --name PART2
    iptables -A INPUT -p tcp --dport 1000 -m recent --remove --name PART3
    iptables -A INPUT -p tcp --dport 2000 -m recent --remove --name PART3
    iptables -A INPUT -p tcp --dport 1000 -m recent --set --name PART1
    iptables -A INPUT -p tcp --dport 2000 -m recent --set --name PART2
    iptables -A INPUT -p tcp --dport 3000 -m recent --set --name PART3
    iptables -A INPUT -p tcp --dport 22 -m recent --rcheck --seconds 30 --name PART1 --name PART2 --name PART3 -j ACCEPT
    Now you don't have to clutter the system with logs and a daemon that may run into trouble.
    1. Re:Watching the logs.. by michaelrash · · Score: 1

      Yes, but fwknop also offers the following capabilities which cannot (easily) be emulated with iptables rulesets alone:

      -encrypted sequences with the Rijndael algorithm
      -timing delays (both min and max) between successive ports in a knock sequence

  15. Now... I don't know if this was asked already but. by PKC+Jess · · Score: 2, Interesting

    Would this if further developed simply allow a company say, like Microsoft to prevent people who are not using Windows to visit websites? If put on servers that would be trouble for many Linux users. Microsoft could just try to shrug it off saying that its not a "trusted" operating system. Anyone using say, frontpage or Windows Server could effectively just by using those products prevent "those dirty Open Source infidels" from viewing big websites. ...just a thought.

  16. Nice idea but... by flakac · · Score: 1

    The passive operating system fingerprints are going to prove to be useless in preventing abuse. It boils down to this -- you can't trust any information gained exclusively from the user (even passively).

    Writing software to spoof OS characteristics won't prove to be a challenge, esp. when you know what characteristics the other side is trying to detect. I just can't really see this system as bringing any added value at all.

  17. A more interesting twist by Anonymous Coward · · Score: 1, Interesting

    Would be to implement invisible port knocking, that is one where there is no preceeding magic packet that would hint the attacker about the presence of port knocker.

    You can encode plenty of bits of data into the initial sequence number, TTL, window size, timestamp options and so forth (you can probably stuff a TCP packet with up to 128 bits of data with no effort).

    The port knocking daemon could then only allow connections for which this 128 footprint matches the one-time cryptographically generated password, silently dropping all other traffic.

    1. Re:A more interesting twist by eric76 · · Score: 1

      Another possibility would be to send one or more packets that appear to be legitimate answers to legitimate DNS queries.

      One of the packets could even identify the particular IP address of the computer from which the connection will be made.

    2. Re:A more interesting twist by michaelrash · · Score: 1

      Yes, that is a cool idea. I would need to use libnet and so the client code would be a bit more complicated, but this would be very interesting to implement.

  18. OpenBSD by pmf · · Score: 4, Informative

    OS detection combined with firewall rules is already implemented in OpenBSD.

  19. Re:Now... I don't know if this was asked already b by gmanic · · Score: 1

    That did happen before, didn't it?

    I don't have the /. story handy nor could I find it with a quick search, though...

  20. Why is port knocking a good idea? by btempleton · · Score: 1

    I mean it seems cute and all, but what does it buy you that, for example, sending a UDP packet with an access code in it (perhaps specific to the time of day and other parameters) doesn't get you?

    --
    Has it been over a year since you last donated to the Electronic Frontier Foundation
    1. Re:Why is port knocking a good idea? by strobert · · Score: 2, Informative

      Nothing really. Both techniques can be used to make it so that a "semi-public" service does not have an effectively listening port (I say effective becuase the service is always listening but it is not always reachable) all of the time.

      If you have a static sequence, then yes if someone is sniffing the traffic then yes you have s security through obscurity layer in protecting blanket access to your service (for sake of discussion let's say SSH).

      But you still have your auth on the SSH service.

      The idea beind Port knocking (and the UDP method mentioned in the post I am replying to) is it makes it so that blind port scanning/attack attacks on your network won't find the SSH service nor try attacks against it.

      now back to port-knocking vs. udp:
      - The UDP approach has a big benefit that your data format you send can be more free-form.
      - The down side to UDP is that it is easier to see what the special way to open the server port is via packet sniffing. Of course if you use say changing data that is encrypted so that it can't be (or at least is hard to be) faked, then I think the UDP approach is still better.
      - Now with the UDP approach means you do have an extra network service running that could be hit by an attack (say a buffer overflow), whereas with port knocking (implemented by a simple daemon looking at the firewall logs) not as likely to have a remote vulnerability.

      So depending on how you implement either there can be pros and cons. But the main goal of either system still remains, you augment your security by making the remote "user" have both the normal auth AND another piece of information (port sequence or magic data to be sent via UDP).

      (Note: I am not implying the poster I am replying to doesn't understand the augmenting benefits)

    2. Re:Why is port knocking a good idea? by welsh+git · · Score: 1

      > I mean it seems cute and all, but what does it buy you that, for example, sending a
      > UDP packet with an access code in it (perhaps specific to the time of day and other
      > parameters) doesn't get you?

      I'd think it depends on your confidence in the security of the UDP listener.
      Granted, it would be a simple piece of code to audit, but you'd still need to
      open up the UDP port in the firewall, and expose the "UDP listener" to potential exploits.

      Whilst a method that monitors log files is more of a kludge, it would be able to
      report knocks to ports that your established firewall software keeps closed..

      Ok, this is probably quite an anal reason, but hey, this is slashdot :)

      --
      Sig out of date
    3. Re:Why is port knocking a good idea? by HermanAB · · Score: 1
      SSH uses TCP, so sending a UDP packet to open the TCP port would be great as an additional access control.

      I may be missing something, but port knocking sequences is just a silly waste of time as far as I can see - kinda amateurish actually.

      --
      Oh well, what the hell...
    4. Re:Why is port knocking a good idea? by fatphil · · Score: 1

      This way, when "the enemy" notice weird TCP connection attempts to your box, they'll know that you're using port-knocking, and decide to hammer every single port in random order just on the offchance.

      It's a great way of finding out if your TCP stack has memory leaks.

      FP.

      --
      Also FatPhil on SoylentNews, id 863
  21. That's good by billstewart · · Score: 1

    One-time password systems make some sense here. One-time pads are operationally awkward and total overkill for the cryptographic needs of this application.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  22. Re:So how long.... by HermanAB · · Score: 2, Interesting

    Install portsentry. Wait until corporate Nazi scanned your machine and got added to hosts.deny. Enjoy the freedom.

    --
    Oh well, what the hell...
  23. leet Windows users by skinfitz · · Score: 1

    This makes it possible to allow, say, only Linux systems to connect to your SSH daemon.

    You mean you could block all the leet blackhat Windows users from your box? You could really be in trouble if they were able to reach it...

    1. Re:leet Windows users by geminidomino · · Score: 1

      Somehow I think using it to block all three of the l33t Windows blackhats is marginally less useful than using it to, say, block millions of 0wn3d windows machines from accessing port 25.

    2. Re:leet Windows users by skinfitz · · Score: 1

      Actually that would be a seriously good use of the technology!

  24. port knocking sounds .. dirty by dj42 · · Score: 1

    Hey baby, you ever had your port knocked by a black hat?

    --
    We are one consciousness experiencing itself subjectively. Back to you with the weather, Bob!
    1. Re:port knocking sounds .. dirty by dj42 · · Score: 1

      i'm upset no one modded the parent funny. hehe... once they've gone black, they never go back.

      --
      We are one consciousness experiencing itself subjectively. Back to you with the weather, Bob!
  25. Naming Schemes ... by Hektor_Troy · · Score: 1

    How long before someone comes up with a port knocker called "Cypher Operated Combination Key Knocker"?

    And wasn't he played by Mark Hamill?

    --
    We do not live in the 21st century. We live in the 20 second century.
    1. Re:Naming Schemes ... by Elequin · · Score: 1

      Already done. And this was even linked in the story. The client is called COK-knocker.

      And yes, it was Mark Hamill. :)

  26. Re:Now... I don't know if this was asked already b by michaelrash · · Score: 1

    Protecting a service with port knocking is only practical if gaining access to the service does not have to happen quickly. Protecting a web server with a port knocking scheme is not practical. However, if Microsoft wanted to build an extra layer into their OS so that their tcp stack would simply not allow a session to be established from any non-Microsoft OS, that is a different matter.

  27. OTP, not OTP by swillden · · Score: 1

    Also, at the Black Hat Briefings, David Worth has released a cryptographic port knock implementation based around one-time pads.

    The summary is incorrect: David Worth's tool uses one-time passwords, not one-time pads. That's a good thing, because one-time pads would make the system really inconvenient to use.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  28. Order and Delivery of Packets not guaranteed! by Dr.+Manhattan · · Score: 1

    ...as I say every time this comes up. The more complicated the knock sequence, the less reliable it will be.

    --
    PHEM - party like it's 1997-2003!
  29. I like the cryptographic approach. by mrmeval · · Score: 1

    I personally would prefer a PGP public key encrypted token with the token being what ever is in the one time pad.

    Here are some methods from an earlier discussion, mine and some others.

    http://slashdot.org/comments.pl?sid=104064&cid=8 86 4815

    --
    I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
  30. They Will Never Know by Pan+T.+Hose · · Score: 2, Insightful

    I use portsentry for protection against scans. The result is that all my ISP scanners are now in hosts.deny and consequenlty I can run any server I want and they will never know and can't complain about it...

    They will never know.

    Unless... they see their logs.

    Your ISP may not be able to directly open your ports but they have to receive, handle and send every single inbound and outbound IP packet of yours, each of them containing source and destination port numbers.

    If they don't know the easiest way to see whether you run any servers by just observing port numbers in your traffic, then, if I were you, I wouldn't want such imbeciles for my ISP.

    --
    Sincerely,
    Pan Tarhei Hosé, PhD.
    "Homo sum et cogito ergo odi profanum vulgus et libido."
  31. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  32. Re:Now... I don't know if this was asked already b by MooseGuy529 · · Score: 1

    You're sorta missing the point.

    Port knocking is used to protect private services, such as SSH, where the general public has no use for the service except for cracking, and the Port Knocking adds an extra layer of security. Adding OS Fingerprinting to this adds an extra layer of security in turn to the Port Knocking.

    HTTP, on the other hand, is designed for public access, and for that reason neither Port Knocking nor OS Fingerprinting would be used on it. (Unless you're running an intranet server and you don't want people's home laptops connected, or something like that, but that is again a private service since it's on your local network and not designed to be used by everyone.)

    --

    Tired of free iPod sigs? Subscribe to my blacklist