Advertisement
Interested in hardware, diags, validation, Linux, C, ARM, Microcode and low level programming and blazing networks?
| |||||||||||||
|
| |||||||||||||
An update on the Fedora August 2008 intrusionAn update on the Fedora August 2008 intrusionPosted Mar 30, 2009 14:27 UTC (Mon) by kragil (guest, #34373)Parent article: An update on the Fedora August 2008 intrusion
Very quick response. Seems like they did a good job.
Although not secured private keys seem like a very obvious hole in any security policy ..
(Log in to post comments)
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 14:46 UTC (Mon) by skvidal (subscriber, #3094) [Link]
As it said in the report - the unsecured keys were not on a fedora system. We had no way of checking for them.
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 14:47 UTC (Mon) by mmcgrath (subscriber, #44906) [Link]
> Although not secured private keys seem like a very obvious hole in any security policy ..
Yeah, we kind of just assumed people would be doing that. No longer though, the new policy is pretty explicit about password protecting keys :)
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 15:11 UTC (Mon) by melevittfl (guest, #5409) [Link]
I know this is probably a silly question, but would there be any way to modify SSH to enforce using
passwords on the public keys rather than rely on people following a policy document?
I can't imagine any way to do this with 100% effectiveness because you'd have to trust the client
Never mind... ;)
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 15:34 UTC (Mon) by iabervon (subscriber, #722) [Link]
The SSH client on the user's system is not necessarily even distributed by Fedora or Red Hat; it might even be one of the clients for Windows.
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 16:13 UTC (Mon) by bfields (subscriber, #19510) [Link] a determined policy violator could simply build a custom ssh client that would lie to the server. Well, you're not trying to defend against malicious users--you've already trusted them with access--you're just trying to remind them of policy and protect them against their own mistakes.
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 17:48 UTC (Mon) by wmf (guest, #33791) [Link]
Maybe they should use PKI and smart cards. Instead of stolen private keys they'd have completely different problems. :-)
An update on the Fedora August 2008 intrusion Posted Mar 31, 2009 2:31 UTC (Tue) by motk (subscriber, #51120) [Link]
I keep suggesting colonic mapping, but nobody listens. the FOOLS.
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 18:17 UTC (Mon) by proski (subscriber, #104) [Link]
I guess it should be possible to require both the public key authentication and the user's password (not the passphrase).
An update on the Fedora August 2008 intrusion Posted Mar 31, 2009 9:19 UTC (Tue) by muwlgr (guest, #35359) [Link]
From the report, user's password was also compromised and used to run sudo.
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 19:28 UTC (Mon) by drag (subscriber, #31333) [Link]
> I know this is probably a silly question, but would there be any way to modify SSH to enforce using passwords on the public keys rather than rely on people following a policy document?
Nope.
> I can't imagine any way to do this with 100% effectiveness because you'd have to trust the client side to tell you the truth and a determined policy violator could simply build a custom ssh client that would lie to the server.
Ya. Your right.
This is much much better for large orginizations to disable public key authorization support and use Kerberos instead.
An update on the Fedora August 2008 intrusion Posted Apr 5, 2009 10:42 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
even if you could force ssh to always require a password, users could put the password into a script wrapper around ssh
also, there are good reasons to not use passwords sometimes. think of cases where you want automated processes to ssh into other systems. there is no user around to type the password in.
An update on the Fedora August 2008 intrusion Posted Apr 5, 2009 12:01 UTC (Sun) by nix (subscriber, #2304) [Link]
That's a good reason to not use passwords. It's not a good reason to not
use passphrases, thanks to the existence of ssh-agent.
An update on the Fedora August 2008 intrusion Posted Apr 5, 2009 12:10 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
if you are dealing with a system that has not had anyone login to it since it was booted anything you do is a variant of 'put the passphrase in a config file'
An update on the Fedora August 2008 intrusion Posted Apr 6, 2009 2:29 UTC (Mon) by knobunc (subscriber, #4678) [Link]
Agreed, and to provide helpful pointers to those implementing an ssh-agent based solution:
http://www.enterprisenetworkingplanet.com/netsecur/articl...
(Keychain is wonderful)
-ben
An update on the Fedora August 2008 intrusion Posted Apr 6, 2009 8:22 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
keychain works for users (where you can enter the passphrase once per boot), not for tools where you don't have a user to enter the passphrase.
so you end up with either setting up a key that doesn't have a passphrase, or having to store that passphrase in a script (or a bunch of scripts since they don't all run as part of a single user session)
I don't see a big win in security to counter the extra complexity here.
no, this isn't appropriate for cases like what was involved in the Fedora intrusion, but the claim was made (several posts up) that there is no legitimate reason to have a blank passphrase, and that is what I'm disputing.
An update on the Fedora August 2008 intrusion Posted Apr 6, 2009 12:44 UTC (Mon) by knobunc (subscriber, #4678) [Link]
Obviously, different environments have different requirements. But I use keychain on my servers. They have months, sometimes years of uptime. If one reboots, I find it acceptable that a human needs to enter a password to allow the box to access the other machines again. I can see scenarios where an unprotected key may make sense but it all depends on the environment.
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 15:41 UTC (Mon) by qg6te2 (guest, #52587) [Link] Yes, a quick response, but the detection of the intrusion can be considered as a fluke. The margin for error appears to have been too little to begin with. 2008-08-12 22:51:00 - Cron job failed, notified admins. If the intruder had been just a little bit more careful, it is entirely possible that either the security problem would have been an order of a magnitude bigger when finally discovered (e.g. many compromised packages, with possible destructive payloads, botnet operation, etc), or to this day we would have no idea that there is something is going on.
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 15:49 UTC (Mon) by spot (subscriber, #15640) [Link]
You're right, which is one of the reasons why we've since added a lot of additional security mechanisms and measures to protect and monitor our infrastructure. We've been working on using SELinux policy on all of our systems, enabling rootkit detection, and improving our monitoring policies.
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 16:14 UTC (Mon) by kragil (guest, #34373) [Link]
That is good to hear. You cannot count on being lucky twice.
It always takes events like this to make changes .. I really hope other distros learn from your mistakeS.
Would be great if Novell, Canonical and Debian would openly disclose how their infrastructure is protected. (In detail.)
At the end of the day my system is dependent on a secure infrastructure from supplier of the binary packages.
Security by obscurity does not work .. let people openly discuss the measures taken and you will deter attackers and possibly strengthen your system by getting new ideas or by finding (obvious) flaws.
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 19:03 UTC (Mon) by nix (subscriber, #2304) [Link]
If the intruder had simply done a better job of log sanitization, the
failed cron job would have been no clue. (Of course that may have been hard: he apparently hadn't escalated to root on that machine, let alone got at the loghost(s)...)
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 16:09 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
I suspect Fedora doesn't have much option but to trust its (non-Redhat) contributors to protect their login credentials properly. Negligence can negate any remote access authentication system I can think of. Perhaps there's something I've missed, but I just can't think of a system where sufficient laziness or incompetence doesn't disable the security.
An update on the Fedora August 2008 intrusion Posted Mar 30, 2009 23:35 UTC (Mon) by gdt (subscriber, #6284) [Link] There's a wide variety of choices. Challenge-response cards being one obvious alternative. Or patching sshd so that authentication can be stacked (eg: key followed by password). The blocking issue is a lack of federated single sign on. You can make authentication more complex but people aren't willing to go through multi factor rigmarole for every resource accessed [as this episode nicely demonstrates]. SSO limits the number of times authentication is requested to a few times a day.
An update on the Fedora August 2008 intrusion Posted Mar 31, 2009 12:33 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Challenge response doesn't help you. The same user who elects not to set a passphrase on his private key, will leave the challenge response device on his desk or even on the bus. He'll write the mandatory 15 character password on a PostIt. Enforcing this stuff remotely is very difficult when you don't trust your authorised personnel to obey policy. In fact I think it's impossible and your examples haven't changed my mind.
If this Fedora contributor ran Fedora, they had the option to enter their SSH passphrase as infrequently as once per (desktop) login. Is that too much?
An update on the Fedora August 2008 intrusion Posted Mar 31, 2009 17:04 UTC (Tue) by chaneau (guest, #6674) [Link] If this Fedora contributor ran Fedora, they had the option to enter their SSH passphrase as infrequently as once per (desktop) login. Is that too much? That's the missing answer from this report is it not? How did the intruder gain access to the private key in the first place? Did the intruder have physical access? Did he access the key remotely? Did the Fedora guy leave his key on some untrusted computer? Was the computer stolen? Some of these questions are more frightening than the others, but if you want me to trust Fedora, the quality and the seriousness of it's administrators, they should tell us what really happened
An update on the Fedora August 2008 intrusion Posted Apr 9, 2009 18:44 UTC (Thu) by eric.rannaud (guest, #44292) [Link]
That's the right question to ask. Can we get comments from Fedora people?
How was the private key first acquired?
|
|
||||||||||||