| |||||||||||||
Bad SecurityBad SecurityPosted Mar 5, 2007 23:26 UTC (Mon) by ldo (subscriber, #40946)Parent article: Single Packet Authorization (Linux Journal)
The article illustrates exactly what happens when you toss together a "solution" (port knocking) without a proper analysis of what exactly is the security problem you are trying to solve. Then, when you discover shortcomings in the technique--like vulnerability to something as elementary as a replay attack--you try to patch it up by throwing even more complexity at it, in the hope that you will end up with something that actually works. Fat chance.
(Log in to post comments)
Bad Security Posted Mar 5, 2007 23:49 UTC (Mon) by flewellyn (subscriber, #5047) [Link] I partly agree.
Port-knocking itself isn't something I'd heard of before, but as soon as I read the description, I knew it would not work. Even before I read the list of shortcomings in the article, my first thought was, "Umm, what's to be done about replay attacks?" The issues of bandwidth, out-of-order delivery and denial-of-service, which I didn't think of before reading that part, killed the idea for me. Plus, the whole idea of using the port fields for something other than what they are intended -- port numbers -- seems altogether wrong.
SPA, on the other hand, seems like a much better idea. It doesn't use port numbers in a bad and wrong way, it has decent bandwidth, it's designed to circumvent replay issues, and doesn't have the denial-of-service problem. It could be a useful additional layer of security, and I don't see it having any huge problems in theory.
In practice, of course, the SPA server is something programmers need to get right: bugs in the SPA server could either kill network traffic altogether ("block everything!"), or make the SPA layer useless ("block nothing!"). And I think the article should take pains to remind people that this is not a replacement for securing the actual application programs, either; I would be very nervous about someone setting up an SPA server, and then thinking that this made host-level and service-level security unnecessary.
Bad Security Posted Mar 6, 2007 0:24 UTC (Tue) by dark (subscriber, #8483) [Link] You forgot option 3: bugs in the SPA server could allow execution ofarbitrary code.
From what I can see, it just adds more possibly-vulnerable code to an
Bad Security Posted Mar 6, 2007 1:11 UTC (Tue) by flewellyn (subscriber, #5047) [Link] Good point, although that can be mitigated by setting up SELinux to control the SPA server's access to system resources.
I do see your point about it being a proliferation of more potentially-vulnerable code. As for its utility...well, it would have the benefit of providing a level of access control beyond the service level, blocking access to a host until the client authenticates, and then allowing connections to provided services. It provides defense in depth of the host.
We can do host-based blocking through the tcp_wrappers suite, but there isn't a way to authenticate a host dynamically: a host in hosts.deny is blocked until the administrator manually removes it (moving it to hosts.allow, depending on setup). Plus, tcp_wrappers works at the application level, not the packet filter level. So tcp_wrappers doesn't (as far as I can tell) prevent a DoS attack.
I could be wrong, of course, but it looks like SPA might provide some useful security. I think the tech is too new to be evaluated properly, though. It definitely needs more testing.
Bad Security Posted Mar 6, 2007 6:42 UTC (Tue) by job (guest, #670) [Link] The same (that risks can be mitigated by SELinux) could be said about OpenSSH.
Bad Security Posted Mar 6, 2007 8:38 UTC (Tue) by drag (subscriber, #31333) [Link] Ya pretty much.
Personally I like the idea that less software is, on average, is going to more secure then more software. As long as everything is designed for security, that is.
Bad Security Posted Mar 6, 2007 15:07 UTC (Tue) by bronson (subscriber, #4806) [Link] Well, it would be foolish to run a dictionary attack against udp:62201. There are a number of security articles demonstrating surprising success when doing the same thing against tcp:22.
In theory, practice and theory are the same. In practice, they're different. Personally, I use port knocking as a last-ditch measure if high-traffic OpenVPN goes down. It sure beats driving 300 miles to the data center.
There's little chance of a replay attack since I'll just change the knock sequence in the rare event that I actually need to knock in. Out-of-order packets just aren't a problem in practice. Port knocking makes my life easier and my /var/log/auth.logs much smaller. Don't be so quick to dismiss it because of theoretical flaws.
Bad Security Posted Mar 6, 2007 17:06 UTC (Tue) by allesfresser (subscriber, #216) [Link] Are the articles demonstrating success using a dictionary attack against SSH when it's configured for password access, or with private-key only? One would think (though intuition can be notoriously unreliable in these sorts of things) that configuring the SSH server to only allow private-key authorization would reduce the change of dictionary success considerably. Does this sound reasonable?
Bad Security Posted Mar 6, 2007 18:53 UTC (Tue) by bronson (subscriber, #4806) [Link] Requiring private keys does ensure a dictionary attack could not succeed. Perhaps why it doesn't see more widespread use:- it is notoriously difficult to set up right. Admins tend to half-ass it (lack of time or understanding) and end up producing the equivalent of a shared-root setup. - it requires more maintenance. On busy sites (think sourceforge), just the day-to-day key management would require at least one full time employee. - it doesn't stop /var/log/auth.log from growing by 4MB/day.
Don't get me wrong: I run all my sshds with mandatory private keys for this very reason. And I also use port knocking! Use the right tool for the job.
Bad Security Posted Mar 6, 2007 20:04 UTC (Tue) by allesfresser (subscriber, #216) [Link] I find it interesting (and slightly disturbing) that setting up a private-key-only sshd is considered difficult. I find it disturbing because in that case I may have done it incorrectly myself! :) From my understanding all that is necessary is to enable only the PubkeyAuthentication method in sshd_config, place the applicable public keys in the user accounts' ~/.ssh/authorized_keys files, and restart sshd. Is there more to it that I'm missing?
Bad Security Posted Mar 6, 2007 21:05 UTC (Tue) by gravious (subscriber, #7662) [Link] Er, that's what I do - if there is a step or two (or more heaven forbid) we are missing out, please enlighten us Oh LWN Gurus of Security :)
Bad Security Posted Mar 6, 2007 22:35 UTC (Tue) by bronson (subscriber, #4806) [Link] It's the key management that makes it difficult. If you and a friend are administering four boxes, it's trivial. If 25 admins are responsible for 400 boxes, it gets painful quick. At one place where I consulted, one admin got sick of swapping keys in and out and just set up a single shared key (what I meant by "shared root setup"). Most admins know why it's bad to share a root password but apparently at least one didn't see a problem with sharing a root key. (weird, I know!)
Another problem is that when people set this up, some see it as an opportunity to use a single private key with no password. That's both easier than setting up ssh-agent and more secure, right? Well, if you lose the key (say, a stolen laptop), you've given up the entire farm. Now you need to try to find all copies of the compromised key and update it to your new key. On more than 5 machines that becomes really tedious.
Maybe I just run into stupid/lazy admins a lot more than the average person. :)
Bad Security Posted Mar 7, 2007 2:41 UTC (Wed) by ArbitraryConstant (guest, #42725) [Link] -Let's face it, it doesn't take much to halt most dictionary attacks, and I don't think setting up port knocking well is any easier than requiring a private key. Yeah, you're screwed if you don't bother putting some basic measures in place to stop dictionary attacks, but the answer is not to pick an unhelpful method and add complexity to your setup, the answer is to take the daemon you have to run anyway and do it right.
-A port knocking solution that doesn't require maintenance is no more worthwhile than a bad SSH solution. It might be guessable, it'll be vulnerable to replay attacks, a fired employee can get to it, etc. Once you stop the script kiddies and botnets that scan the Internet, you're left with more determined attacks, and it's worthless against those. A good port knocking solution needs a pseudo-random and ever-changing sequence, or UDP packets filled with large, single-use keys, etc. It'll need maintenance just like SSH private keys. In that case, why not just use SSH with private keys?
-I can't be the only one that compresses my logs. The dictionary attacks still spatter against a windshield, they just spatter against a slightly different windshield. I, for one, am not opposed to having a record of who's doing it.
Bad Security Posted Mar 6, 2007 1:16 UTC (Tue) by Sutoka (guest, #43890) [Link] I think the 'problem' port knocking was designed to help solve were zeroday vulnerabilities and lists of servers with what version of certain applications they are running.
As far as I know, most people aren't in positions to perform replay
Sure, there are holes and problems (primarily if you go with multiple
Well, there are different kinds of security Posted Mar 6, 2007 10:05 UTC (Tue) by dion (subscriber, #2764) [Link] ssh is what provides the real security, I don't think anyone wants to replace ssh with telnet and port knocking.
As far as I can tell the two arguments for port knocking are:
1) It's very likely that casual attackers (99.99% or more) cannot sniff your traffic, so it's still worth while to shut those down.
2) Port knocking can be implemented using very simple code that can be audited completely (a perl script reading the firewall log) and thus you can be sure that there are no dangerous holes in the implementation.
Moving actual crypto and package parsing into the solution (SPA) is a mistake IMHO, as that's simply moving too much complexity to trust.
If history has shown anything then it's that real security is hard (see ssh) and as a consequence of that people some times make mistakes, port knocking is a dead simple way of dramatically decreasing the chance that some script kiddie hits your server before you get around to patching it.
Good Security Posted Apr 15, 2007 1:26 UTC (Sun) by mrash (guest, #44663) [Link] So, can you suggest an attack vector against SPA? SPA is relatively simplistic (especially when only the symmtric Rijndael algorithm is used for encryption), depends on libpcap (which gets a lot of scrutiny), and fwknop is written in a buffer-safe language (perl).
The security benefit is that there is nothing a remote adversary can reasonably do to tell that fwknop is running, and arbitrary servers can be protected behind it using a kernel-level filtering mechanism (iptables) to fundamentally limit the number of user-space functions that an attacker would otherwise have access to.
|
|||||||||||||