Combining Port Knocking With OS Fingerprinting 154
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."
It's kinda cool (Score:5, Interesting)
LK
Layers (Score:5, Interesting)
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....
So how long.... (Score:0, Interesting)
People are gonna share, get over it.
Port knocking and some added ingredients (Score:5, Interesting)
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.
Re:How much more is needed? (Score:5, Interesting)
The above is completely conjecture, but it sure does sound cool
-- vranash
Re:Port knocking, firewalls, DMZs,... (Score:5, Interesting)
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:It's kinda cool (Score:1, Interesting)
Daemon watching iptables (Score:2, Interesting)
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.
Re:How much more is needed? (Score:4, Interesting)
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.
Re:Security Through Obscurity (Score:4, Interesting)
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.
Now... I don't know if this was asked already but. (Score:2, Interesting)
A more interesting twist (Score:1, Interesting)
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 password, silently dropping all other traffic.
Re:It's kinda cool (Score:5, Interesting)
Re:So how long.... (Score:3, Interesting)
Re:Security Through Obscurity (Score:4, Interesting)
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)
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?