Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Privacy Software Linux

Combining Port Knocking With OS Fingerprinting 154

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Combining Port Knocking With OS Fingerprinting More

Combining Port Knocking With OS Fingerprinting

Comments Filter:

  • It's kinda cool (Score:5, Interesting)

    by Lord Kano ( 13027 ) on Sunday August 01, 2004 @01:51AM (#9856583) Homepage Journal
    but is anyone out there using port knocking for serious security?

    LK

    • Re:It's kinda cool (Score:3, Insightful)

      by Anonymous Coward
      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.

    • Re:It's kinda cool (Score:1, Interesting)

      by quelrods ( 521005 ) *
      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.

      • Re:It's kinda cool (Score:5, Insightful)

        by Lord Kano ( 13027 ) on Sunday August 01, 2004 @03:16AM (#9856764) Homepage Journal
        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
        • 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.
        • 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
        • 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

      • Re:It's kinda cool (Score:5, Insightful)

        by eric76 ( 679787 ) on Sunday August 01, 2004 @05:12AM (#9856973)
        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.

        • 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:

          • 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.
        • I would refer you to the original post and suggest following the links to read about p0f here [coredump.cx] and here [onlamp.com] and various port knocking implementations. Port knocking has been covered in /. before [slashdot.org] and the original idea included consideration of a replay attack possibility. Thus, encryption of the knock sequence.
      • 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 [bastille-linux.org]
      • Don't expect the NSA to use this anytime soon.

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

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

      • Re:It's kinda cool (Score:5, Insightful)

        by Sancho ( 17056 ) on Sunday August 01, 2004 @03:46AM (#9856814) Homepage
        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.

        • Re:It's kinda cool (Score:3, Informative)

          by Anonymous Coward
          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.

        • Re:It's kinda cool (Score:5, Interesting)

          by HermanAB ( 661181 ) on Sunday August 01, 2004 @05:00AM (#9856945)
          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...

          • Re:It's kinda cool (Score:3, Informative)

            by Tony Hoyle ( 11698 )
            Well, as long as it goes through tcpwrappers anyway....

            Most services don't though. You should be updating iptables not hosts.deny.
          • You might want to check this link out:

            Hos is psad different from portsentry? [cipherdyne.org]

          • 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 easi

        • 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
    • 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?
    • 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.

  • How much more is needed? (Score:2, Insightful)

    by Anonymous Coward
    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?

    • Re:How much more is needed? (Score:5, Interesting)

      by vranash ( 594439 ) on Sunday August 01, 2004 @02:08AM (#9856624)
      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

    • Re:How much more is needed? (Score:4, Interesting)

      by Xepo ( 69222 ) on Sunday August 01, 2004 @02:37AM (#9856697) Homepage
      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.
    • 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 [synacklabs.net] OS neuances can be spoofed, but at least the bar is just a little higher.
    • 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 :)

  • OS fingerprinting, whew! (Score:4, Funny)

    by Anonymous Coward on Sunday August 01, 2004 @01:53AM (#9856588)
    thank goodness, if there's one thing a hacker can't get his hands on, it's a copy of Linux!

    yuk yuk yuk

  • Layers (Score:5, Interesting)

    by danielrm26 ( 567852 ) * on Sunday August 01, 2004 @01:53AM (#9856589) Homepage
    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....
    • 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.
    • 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.
      • 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.

  • The more complicated you make it, (Score:5, Insightful)

    by Anonymous Coward on Sunday August 01, 2004 @01:54AM (#9856593)
    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.

  • In other news... (Score:5, Funny)

    by AvantLegion ( 595806 ) on Sunday August 01, 2004 @01:58AM (#9856603) Journal
    Microsoft IIS has implemented a similar scheme to only allow HTTP sessions to Microsoft OS running clients.

    • 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.
      • 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
    • 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?
    • 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'.

  • Port knocking and some added ingredients (Score:5, Interesting)

    by ThufirHawat ( 524457 ) on Sunday August 01, 2004 @02:01AM (#9856607) Homepage
    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.
    • "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.

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

      • 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 [insecure.org] is a fairly simple explanation of some of those methods if you're interested.

  • Port knocking, firewalls, DMZs,... (Score:4, Insightful)

    by Rosco P. Coltrane ( 209368 ) on Sunday August 01, 2004 @02:04AM (#9856612)
    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...

    • Re:Port knocking, firewalls, DMZs,... (Score:5, Interesting)

      by danielrm26 ( 567852 ) * on Sunday August 01, 2004 @02:12AM (#9856635) Homepage
      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.

    • Re:Port knocking, firewalls, DMZs,... (Score:5, Insightful)

      by grasshoppa ( 657393 ) on Sunday August 01, 2004 @02:13AM (#9856637) Homepage
      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 ).
    • 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 me
    • 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.
    • 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.
    • 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.

  • Security Through Obscurity (Score:4, Insightful)

    by gst ( 76126 ) on Sunday August 01, 2004 @02:09AM (#9856627) Homepage
    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.

    • Re:Security Through Obscurity (Score:4, Insightful)

      by RC515 ( 801823 ) on Sunday August 01, 2004 @02:18AM (#9856649)
      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.
      • 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 s

        • 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 vulner

          • 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 compl

    • Re:Security Through Obscurity (Score:4, Interesting)

      by OzRoy ( 602691 ) on Sunday August 01, 2004 @02:51AM (#9856728)
      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.

    • Re:Security Through Obscurity (Score:1, Insightful)

      by Anonymous Coward
      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 n
    • 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?

    • Re:Security Through Obscurity (Score:4, Interesting)

      by wolfb ( 613683 ) on Sunday August 01, 2004 @06:33AM (#9857103)
      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?

    • Re:Security Through Obscurity (Score:5, Interesting)

      by groomed ( 202061 ) on Sunday August 01, 2004 @06:33AM (#9857105)
      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?

      • 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 [faqs.org], which defines UDP. It's a quick read. There's no w

  • these ports are made for knockin' (Score:2, Funny)

    by Anonymous Coward
    and that's just what they'll do

    one of these days these ports

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

  • 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 [cipherdyne.org] (by same author) -- I thought the purpose of iptables was to allow plug-in modules to be COMBINED.

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

  • NOT a one-time pad (Score:5, Informative)

    by Dwonis ( 52652 ) * on Sunday August 01, 2004 @02:36AM (#9856691)
    This is a one-time password system, which uses hashes, just like S/Key does. This is NOT a one-time pad system.
    • One-time password systems make some sense here. One-time pads are operationally awkward and total overkill for the cryptographic needs of this application.

  • Eh? (Score:2)

    by sakusha ( 441986 )
    I thought port knocking was definitively debunked as security through obscurity.
    • 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 obscu

  • Watching the logs.. (Score:3, Insightful)

    by Anonymous Coward on Sunday August 01, 2004 @02:53AM (#9856733)
    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.
    • 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
  • 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.
  • 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.

  • A more interesting twist (Score:1, Interesting)

    by Anonymous Coward
    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 passwo
    • 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.
    • 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.

  • OpenBSD (Score:4, Informative)

    by pmf ( 255410 ) on Sunday August 01, 2004 @03:26AM (#9856778)
    OS detection combined with firewall rules is already implemented [openbsd.org] in OpenBSD.
  • 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?
    • 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 bei
    • > 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 kludg
    • 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.

  • 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...
  • Hey baby, you ever had your port knocked by a black hat?
  • How long before someone comes up with a port knocker called "Cypher Operated Combination Key Knocker"?

    And wasn't he played by Mark Hamill?

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

  • ...as I say every time this comes up. The more complicated the knock sequence, the less reliable it will be.
  • 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

Slashdot Top Deals

Is knowledge knowable? If not, how do we know that?

Close