Slashdot Mirror
Combining Port Knocking With OS Fingerprinting
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 is a one-time password system, which uses hashes, just like S/Key does. This is NOT a one-time pad system.
OS detection combined with firewall rules is already implemented in OpenBSD.
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.
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)
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.
Well, as long as it goes through tcpwrappers anyway....
Most services don't though. You should be updating iptables not hosts.deny.