Going Beyond Port Knocking; Single Packet Access

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

Comments

Yeah, right.

[Anonymous Coward]

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.

Nothing is secure

[Irashtar]

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

Whats the point of port knocking?

[mnmn]

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

Re:Whats the point of port knocking?

[Anonymous Coward]

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.

Re:Whats the point of port knocking?

[Fulkkari]

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.

Re:Whats the point of port knocking?

[curunir]

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?

Assumes libpcap is secure.

[TheLink]

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.

Re:Good chance to get some karma -

[michaelrash]

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.