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."
but is anyone out there using port knocking for serious security?
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
With a large port knock routine say 20 ports or more, can't you be sure it's YOUR box that's comming in? More defense and limitations are good, sure, but why filter by OS? Is it in case someone gets by the knock?
thank goodness, if there's one thing a hacker can't get his hands on, it's a copy of Linux!
yuk yuk yuk
1. TCPWrappers (has to be be right IP and/or daemon)
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....
dmiessler.com -- grep understanding knowledge
the bigger is the chance of screwing up. The point of port knocking is to have a simple and therefore less bug prone layer around real authentication systems like ssh, so that when a bug in ssh is found, portscanners don't find your vulnerable service. Complicated port knocking systems defeat the purpose of port knocking.
While port knocking is by now an established technique, I do not think OS fingerprinting adds anything useful, because the ease of static replay attacks is left unchanged by OS fingerprinting.
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.
Thufir Hawat
Part-time Mentat
are techniques I've seen appearing for the last 10 years that are designed to compartment sections of the net. They make me sad, because that's definitely not what the net was intended to be, i.e. a global interconected network of machines to freely communicate. Instead, the net is slowly being segregated, and you'll soon have to show some sort of proof of identity to do anything other than HTTP. If you don't believe me, just consider how hard it is to do something as mundane as a DCC CHAT on IRC today, as opposed to, say, in 1994.
I realize the need for these things, basically forced upon us by the combination of commercial interests, shitty insecure OS, script kiddies and greedy crackers (not hackers), but all the same, I can't help realize that the internet of today is a far cry from what it was intended to be in terms of freedom of communication...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Not more - not less. All that portknocking does is shifting the security to 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.
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.
and that's just what they'll do
one of these days these ports
are gonna walk all over you........
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 (by same author) -- I thought the purpose of iptables was to allow plug-in modules to be COMBINED.
This is a one-time password system, which uses hashes, just like S/Key does. This is NOT a one-time pad system.
Use the recent match module and something like the following for requiring ports 1000, 2000 and 3000 to be knocked in order and within 30 seconds before allowing ssh from a particular host:Now you don't have to clutter the system with logs and a daemon that may run into trouble.
Would this if further developed simply allow a company say, like Microsoft to prevent people who are not using Windows to visit websites? If put on servers that would be trouble for many Linux users. Microsoft could just try to shrug it off saying that its not a "trusted" operating system. Anyone using say, frontpage or Windows Server could effectively just by using those products prevent "those dirty Open Source infidels" from viewing big websites. ...just a thought.
OS detection combined with firewall rules is already implemented in OpenBSD.
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)
Install portsentry. Wait until corporate Nazi scanned your machine and got added to hosts.deny. Enjoy the freedom.
Oh well, what the hell...
They will never know.
Unless... they see their logs.
Your ISP may not be able to directly open your ports but they have to receive, handle and send every single inbound and outbound IP packet of yours, each of them containing source and destination port numbers.
If they don't know the easiest way to see whether you run any servers by just observing port numbers in your traffic, then, if I were you, I wouldn't want such imbeciles for my ISP.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."