Slashdot Log In
Combining Port Knocking With OS Fingerprinting
Posted by
timothy
on Sun Aug 01, 2004 01:50 AM
from the belt-and-suspenders-and-tape-and-elastic dept.
from the belt-and-suspenders-and-tape-and-elastic dept.
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 discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
It's kinda cool (Score:5, Interesting)
LK
Re:It's kinda cool (Score:3, Insightful)
it seems like a fad, and of course the authors of such programs will defend its usefulness.
my opinion is that this technique is not new, and hackers have been using very similiar things for decades.
and since he mentioned defcon, oh boy has that hacking con gone down hill. Bugs are just not as easy to find now days so the bar has been raised for h4x0rs.
Re:It's kinda cool (Score:2)
Re:It's kinda cool (Score:5, Insightful)
The primary purpose of port knocking is to hide the fact that you have open ports to begin with. You don't want to have those ports unprotected once the right knock sequence is in place. You want both password/challenge AND port knocking so no active scanner detects your open ports.
Parent
Re:It's kinda cool (Score:3, Informative)
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.
Re:It's kinda cool (Score:5, Interesting)
Parent
Re:It's kinda cool (Score:3, Informative)
Most services don't though. You should be updating iptables not hosts.deny.
They Will Never Know (Score:3, Insightful)
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 easi
Re:It's kinda cool (Score:5, Insightful)
Only in the same sense that passwords are security through obscurity.
Right combination of keystrokes, right combination of ports to knock, these sound very similar to me.
LK
Parent
Re:It's kinda cool (Score:5, Insightful)
The only time that "security through obscurity" is wrong is if that is your entire approach to security.
Even if you have the latest and greatest copy of the most secure software written to perform some service, there is always a possibility that there is something exploitable that is yet unknown.
Port knocking is an excellent way to greatly reduce the probability that someone will be able to use a newly discovered exploit from using it against your server before an update is available to fix the exploit.
Of course, if someone is in the right place and can monitor the network traffic from another computer somewhere along the path, they can discover the port knocking sequence. For that reason, you still need your normal security and you still need to keep the patches up to date.
But the result will still be a vastly improved possibility of avoiding an attack when a vulnerability is found.
Parent
How much more is needed? (Score:2, Insightful)
Re:How much more is needed? (Score:5, Interesting)
The above is completely conjecture, but it sure does sound cool
-- vranash
Parent
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.
Parent
Re:How much more is needed? (Score:2, Insightful)
OS fingerprinting, whew! (Score:4, Funny)
yuk yuk yuk
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....
The more complicated you make it, (Score:5, Insightful)
Re:The more complicated you make it, (Score:2, Insightful)
Now look at the complexity and functionality of SSH, and its share of security problems over the past years.
Then look at port knockers, their simplicity and minimal reliance on bloated libraries. Note they only use a single, simplistic - but cryptographically proven - authentication scheme based on things such as basic symmetric ciphers or one-way shortcut functions, with implementations that could hardly go wrong.
The whole point is, SSH and many other complex services have proven to be not reliable
In other news... (Score:5, Funny)
Re:In other news... (Score:2, Funny)
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:Port knocking and some added ingredients (Score:2)
Yeah, that's what the other guy mentioned did. He's got a one-time-pad implementation that looks pretty cool.
Re:Port knocking and some added ingredients (Score:2)
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.
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.
Re:Port knocking and some added ingredients (Score:2, Informative)
While the method you mention is one way of fingerprinting, most modern tools use a more sophisticated approach. Here [insecure.org] is a fairly simple explanation of some of those methods if you're interested.
Port knocking, firewalls, DMZs,... (Score:4, Insightful)
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...
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.
Parent
Re:Port knocking, firewalls, DMZs,... (Score:5, Insightful)
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
Um...wasn't the internet born at the department of defense? Awfully nice of them, to make this huge network for freedom of communication.
Oh, wait, that's not what it was intended for. It was intended to be a network of communication, built to survive outages of several large nodes, in case of a nuclear attack. It's only been as more and more people began romaticising it, that we've come up with this free communications thing.
While I'm not apposed to it, I am realistic about it. Would you leave your car, complete with keys, parked in a stadium parking lot, with an open door, and a sign stuck on the steering wheel saying, "Please don't take"? That's essentially what you do with your computer when you go online without any sort of protection ( short of the sign, mind you ).
Parent
Re:Port knocking, firewalls, DMZs,... (Score:2)
In what way? What, specifically, is "corporate" about the internet. What has been added to it in say, oh, the past five years, that would make you think that?
Re:Port knocking, firewalls, DMZs,... (Score:3, Insightful)
I have a private server I use for e-mail, irc, and as a convenient, central location to store files. I have no interest in making this server public--it's only on the Internet because to set up a dedicated line to it would be prohibitively expensive. I don't even want people to know the server is there, and if they do find out it's there, I want security to be as tight as possible. Port knocking, in a way, helps to me
Re:Port knocking, firewalls, DMZs,... (Score:5, Insightful)
I think the majority of people - geeks included, but not to the exclusion of everyone else - think the internet, on the whole, is performing fairly reasonably. Just like in reality, when you have a small group of people working together, issues of trust are much easier to deal with compared to working with hundreds of millions of people.
Blaming "commercial interests, shitty insecure OS,
Soon enough, the Internet would be compartmentalized exactly the way you fear - into groups of like-minded people instead.
The Internet isn't supposed to be utopia. It was about making resources easier to access and it does that job amazingly well, given the imperfect people using it.
Parent
Re:Port knocking, firewalls, DMZs,... (Score:2)
As the internet becomes more and more available to people, we begin to realize what complete a-holes people can be, thus the need for more and more security measures.
Security Through Obscurity (Score:4, Insightful)
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.
Re:Security Through Obscurity (Score:4, Insightful)
Port knocking buys you the time between a new ssh exploit and the fix. It significantly reduces the chance of being found by portscanners and therefore of being hacked. You still have to fix ssh though.
Parent
Re:Security Through Obscurity (Score:2, Insightful)
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.
Parent
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?
Parent
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?
Parent
these ports are made for knockin' (Score:2, Funny)
one of these days these ports
are gonna walk all over you........
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.
NOT a one-time pad (Score:5, Informative)
That's good (Score:2)
Eh? (Score:2)
Watching the logs.. (Score:3, Insightful)
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.
Now... I don't know if this was asked already but. (Score:2, Interesting)
Nice idea but... (Score:2)
Writing software to spoof OS characteristics won't prove to be a challenge, esp. when you know what characteristics the other side is trying to detect. I just can't really see this system as bringing any added value at all.
OpenBSD (Score:4, Informative)
Why is port knocking a good idea? (Score:2)
Re:Why is port knocking a good idea? (Score:3, Informative)
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 bei
Re:Why is port knocking a good idea? (Score:2)
I may be missing something, but port knocking sequences is just a silly waste of time as far as I can see - kinda amateurish actually.
Re:So how long.... (Score:3, Interesting)