| |||||||||||||
Bad SecurityBad SecurityPosted Mar 6, 2007 0:24 UTC (Tue) by dark (subscriber, #8483)In reply to: Bad Security by flewellyn Parent article: Single Packet Authorization (Linux Journal)
You forgot option 3: bugs in the SPA server could allow execution of
From what I can see, it just adds more possibly-vulnerable code to an
(Log in to post comments)
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.
|
|||||||||||||