Slashdot Mirror

← Back to Stories (view on slashdot.org)

Going Beyond Port Knocking; Single Packet Access

Posted by Hemos on from the interesting-ideas dept.

michaelrash writes "I have just released a new version of fwknop that implements a single-packet authorization scheme using libpcap (similar to what Simple Nomad has proposed for the upcoming BlackHat Briefings). Fwknop has made Slashdot once before as the first tool that combines port knocking and passive OS fingerprinting. However, this new single-packet method has many advantages over port knocking, including non-replayable messages, much more data can be sent (including complete commands), an attacker cannot break sequences simply by connecting to spurious ports on the target, and more. By using Netfilter to intercept packets within the kernel, anyone scanning for a service protected by this method cannot even talk directly to the IP stack without being authorized; that makes even 0-day exploits largely toothless."

23 comments

  1. Yeah, right. by Anonymous Coward · · Score: 2, Insightful

    By using Netfilter to intercept packets within the kernel, anyone scanning for a service protected by this method cannot even talk directly to the IP stack without being authorized; that makes even 0-day exploits largely toothless."

    Yes, because we all know netfilter is invulnerable to 0days? No.

    1. Re:Yeah, right. by TotoLeFoobar · · Score: 1

      Sure, all software has bugs. Only that using this method, an intruder would have to find two 0-day exploits instead of one.

      (In theory, of course, because who knows how many firewalls or port knocking systems are correctly configured -- c.f. Microsoft-based systems.)

    2. Re:Yeah, right. by michaelrash · · Score: 1

      No one is claiming that Netfilter (or any other software) is perfect. One of the main advantages of this strategy is that at least the number of code paths is minimized by intercepting packets at the lowest level possible; i.e. within the kernel. In addition, because fwknop uses libpcap, the authentication packet can be destined for a seemingly totally unrelated IP but open up the firewall in a system that can watch this traffic go by on the wire.

  2. Nothing is secure by Irashtar · · Score: 2, Funny

    Make it foolproof, you getter a smarter fool.
    make it spoofproof, they'll make a better spoof.

  3. Whats the point of port knocking? by mnmn · · Score: 2, Insightful

    The client must know the combination to communicate at all. If the client is specialized, and trusted enough with the combination, why the heavy security? If we're dealing with public clients, they wont know how to port knock, at least the combination.

    In general if the TCPIP stack is clean and basic, along with a good packet filter ruleset (dont allow telnet), things will be pretty tough for a hacker. Why add overhead that makes the box secure only in theory (if that even).

    --
    "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
    1. Re:Whats the point of port knocking? by Anonymous Coward · · Score: 3, Informative

      The point of port knocking is that it narrows the exposure window even further on a tightly secured but remotely accessible platform.

      Port knocking does add overhead, yes, and the listener code could contain bugs that might in principle decrease security if the code were inline with the access path. However, port knocking code is not usually inline with the access path.

      Instead, the knock listener monitors passively from outside the access path, so the worst that a bug in it could do is to turn the access window on permanently ... which would be no worse than not using port knocking at all.

      That makes port knocking a win/win mechanism, assuming a minimal level of sysadmin competence.

    2. Re:Whats the point of port knocking? by Fulkkari · · Score: 3, Informative

      Port knocking allows trusted clients from less trusted networks to access services. It gives a couple of advantages to plain packet filtering.

      First of all, it doesn't require you to know the IP address of the client - unlike with packet filtering. With static IP addresses this is not a problem for packet filtering, but clients with notebooks traveling around the world with all kinds of IP addresses it definitely is. By using port knocking techniques your services, while still available, will look invisible to an unauthorized user. With plain packet filtering you would need to decide wether you block all connections or allow all of them.

      Port knocking also has the the advantage that it may provide some form of user authentication. If a malicious user is behind a trusted NATed IP address, packet filters will happily grant access to talk with services. On the other hand by using port knocking, these services would still be hidden from the malicious user. (There might be a risk where the malicious user could try to get in while the trusted user is opening a connection, but there are ways to prevent that.)

      So port knocking is one of the next steps you might do increasing the security on a system. Although there is a small overhead, you want to think about using port knocking when allowing connections from untrusted networks to your services.

      --
      I demand the Cone of Silence!
    3. Re:Whats the point of port knocking? by Anonymous Coward · · Score: 1, Funny

      Duh, it's the foundation for a secure next-generation communications protocol, allowing users new freedom and peace of mind. As a legitimate security researcher, I'm excited about the prospects for myself and my clients.

      Ahh, fuck it. It's just another way for botnets to communicate.

    4. Re:Whats the point of port knocking? by curunir · · Score: 2, Insightful

      My big question about port knocking is why use ports in the first place? Why not send whatever shared secret you're using in the header of the initial SYN packets? It would be just as secure (basically, horribly insecure) and wouldn't involve listening on extraneous ports.

      Why overload the port concept when there are plenty of better ways to send data?

      --
      "Don't blame me, I voted for Kodos!"
    5. Re:Whats the point of port knocking? by mnmn · · Score: 1

      And what happens when another user on your server wants to start another daemon listening to such packets? How do you differentiate two different daemons listening to two different types of traffic, and keep them seperate enough to be safe from one another?

      That identifier became 'tcp ports' in tcpip, which is why we dont use ip alone. If a user's daemon is connected to a port, noone else uses that port, and external processes can get to that daemon through that port securely.

      The SYN header data will work if the data is small enough, if you screw the TCPIP stack enough and if it is guaranteed that only one daemon will ever need to listen on each given IP address.

      --
      "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
    6. Re:Whats the point of port knocking? by Sithgunner · · Score: 1

      While it sounds there's no need to use ports, the machine doesn't have to have any ports open. The firewall, just examines on what port the packets are heading to, and makes validation against its knocking sequence, and drops or returns or whatever.

    7. Re:Whats the point of port knocking? by curunir · · Score: 1

      I get the purpose of ports. I'm not completely daft. The daemon still needs to listen on a specific port. But what I don't get is the knocking part. Why involve connections to other ports when you only need to make the connection to the target port?

      If the initial connection, sent to the appropriate port, includes the shared secret, you don't need to even listen to connection attempts on other ports. Making extraneous connections to other ports doesn't really gain you anything other than encoding a password sequence in a series of port numbers transmitted by attempting connections to those ports. You can send that same information in the header of the initial tcp packet and you've simplified the whole situation without really losing all that much.

      --
      "Don't blame me, I voted for Kodos!"
  4. Good chance to get some karma - by marat · · Score: 1

    Can someone please explain WHF this is about? What do OS identification, attacks and replaying messages have in common? I though I'm TCP/IP literate, but I don't understand a word in the post description (well, to be preceise I do understand single words, but not sequences of two or more of them :)).

    1. Re:Good chance to get some karma - by Anonymous Coward · · Score: 1, Informative

      It seems to me that the point is this: you send A SINGLE packet to a port that for all intents and purposes looks closed, but is really filtered by your in-kernel firewall. If your packet contains the right (pre-determined) sequence of bits, the packet filter will interpret those bits as authentication, and let your packet get through to whatever is actually listening on that port. Voila! you have a port on the server that nobody (barring certain brute force or replay attacks, I reckon) is even aware was open.

    2. Re:Good chance to get some karma - by Creepy+Crawler · · Score: 1

      Shouldnt be too hard to get rid of replay attacks. Just include NTPD on your servers, keep in sync with some lvl 2/3 strata and 1 link to a lvl 1 as failover.

      You could probably get a script that takes the UDP datagram data through a pgp filter. Just include the time and only allow a 3 second sway to/from it and then accept it.

      Including a encrypted time linked to your secret key is plenty good enough. Buh bye replay.

      --
    3. Re:Good chance to get some karma - by michaelrash · · Score: 3, Interesting

      fwknop prevents replay attacks in server mode by keeping track of MD5 sums of valid (decrypted) messages. The fwknop client prepends all messages with 16 bytes of random data which ensures that no two messages are the same. This way the same command can be sent without matching to a previously seen MD5 sum.

  5. Assumes libpcap is secure. by TheLink · · Score: 2, Insightful

    Haven't there been security bugs with libpcap?

    If one rather not rely on libpcap being secure, one could whip up a perl/python server listening on some port, that'll handle the opening and closing of access to sshd and other stuff. That way you can use simple firewall rules which are less likely to have issues. Whatever it is you have to rely on the firewall code and kernel IP stack being secure.

    Sure it's an active server that's listening, but it's a lot easier to secure a perl/python program from buffer overflows and other exploits... You could still DoS it, but it's trivial to DoS the target's internet connection anyway.

    --
    1. Re:Assumes libpcap is secure. by michaelrash · · Score: 1

      Yes, libpcap has had vulnerabilities before. However, the complexity of the libpcap code vs. that of services fwknop protects (such as OpenSSH) is much lower. Fwknop can be used to protect multiple servcies as well. Also, fwknop can simply read the Netfilter log file if you want to use the old port knocking method.

  6. Taking it seriously? by flonker · · Score: 1

    Does anyone take port knocking seriously?

    Basically, you'd have better security if you set up a daemon listening on a known port that waited for you to send a password, with no overloading of the port concept in TCP. If you're worried about replay attacks, use the same encryption/whatever on your password as you would on the port numbers.

    What benefits does port knocking give over a simple password on a known port?

    1. Re:Taking it seriously? by michaelrash · · Score: 1

      Setting up a daemon that waits for a password before allowing access to a protected service would definitely provide better security than nothing at all. This is because a lightweight authorization server is most likely much less complex than whatever service it is protecting.

      Port knocking has the additional advantage of allowing the authentication layer to be pushed as low in the stack as possible. This means that the number of code paths (which could contain known/unknown vulnerabilities) is minimized. Also, if the authorization packets are sniffed off the wire as they travel to an unrelated IP, it becomes difficult to know where the actual knock server is running.

    2. Re:Taking it seriously? by eric76 · · Score: 1

      When an attack on a known port is discovered, all anyone has to do is scan for computers listening on that port to have a reasonable chance of finding vulnerable systems.

      Port knocking hides the very existence of the service should a vulnerability for that service to be discovered.

      The real problem is that only certain types of services are protectable. Anything that the public needs to be able to access is still exposed by necessity.

      So, for those instances where it is applicable, the enhancements to security can be enormous.

    3. Re:Taking it seriously? by malcomvetter · · Score: 1

      What benefits does port knocking give over a simple password on a known port?
      I can only suggest it's another security by obscurity tool.
      The person who has this installed, probably has it on a home server, in a room with magnetic field protected doorways, ready to wipe the disks if the feds come to haul it away.
      It's overkill like this that makes me rethink the whole point of privacy and security. Maybe we would all just be better off sharing everything in the clear (no confidentiality-breach prevention tools), while watching for data misuse (detection and response).

      Well, that's probably to idyllic, so as always, we're stuck somewhere in the middle ...

  7. Step beyond, leap backwards by Anonymous Coward · · Score: 0

    This might be a step beyond, but it's still a huge leap backwards. IMHO the reason for port knocking is to isolate services that are potentially vulnerable to explotation.

    The primary focus of the port knocker should be security and NOT functionallity. It only has to do one thing, but it has to do it pretty damn well.

    Otherwise, this is just as effective as logging in remotely via telnet just to open the SSH port!

    Another problems with many implementations is they are sniffing the network, using software. As previously stated, DON'T trust software! Not even libpcap/winpcap or whatever. There WILL be vulnerabilities, there ALWAYS is.

    If the implementation is truly a PORT-knocking port-knocker, I see no problem in gathering data from the firewall and not the network.

    Regards, Stian Ovrevage