Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Software Linux

Going Beyond Port Knocking; Single Packet Access 23

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

Going Beyond Port Knocking; Single Packet Access

Comments Filter:
  • by Anonymous Coward on Monday May 30, 2005 @10:15AM (#12676240)
    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.
  • by Fulkkari ( 603331 ) on Monday May 30, 2005 @11:03AM (#12676470)

    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.

  • by Anonymous Coward on Monday May 30, 2005 @11:55AM (#12676767)
    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.

Suggest you just sit there and wait till life gets easier.

Working...