| |||||||||||||
|
| |||||||||||||
Another update on Fedora infrastructureAnother update on Fedora infrastructurePosted Aug 20, 2008 1:12 UTC (Wed) by qg6te2 (guest, #52587)In reply to: Another update on Fedora infrastructure by sbergman27 Parent article: Another update on Fedora infrastructure Yeah, I know that the true fans will pat them on the back and say it was great that they responded so quickly. (Standard fall-back procedure.) Others will, understandably, wonder how such a thing was ever allowed to happen at all. Assuming this is indeed a security problem, the real question to ask would be: if it happened to Fedora, is the infrastructure of Ubuntu, Debian or Suse also vulnerable? Even in the case that this "incident" was something highly specific to Fedora, we as a community can still learn from Fedora's experience.
(Log in to post comments)
Another update on Fedora infrastructure Posted Aug 20, 2008 3:10 UTC (Wed) by sbergman27 (subscriber, #10767) [Link] """ if it happened to Fedora, is the infrastructure of Ubuntu, Debian or Suse also vulnerable? """ We cannot know at this point because Fedora ain't talkin'. And usually Red Hat Legal must be consulted and hand down an opinion before they do.
Another update on Fedora infrastructure Posted Aug 20, 2008 6:14 UTC (Wed) by jd (guest, #26381) [Link] Standard tactics is to assume the worst and hope for the best. By that, I mean assume that all distros have a vulnerability that may permit root access to an outside user via a service likely to be run on the machine with the key change, but at the same time, don't panic and shut everything down. Use common sense. In this case, if you are running a mission-critical server that is exposed directly to the Internet (rather than via a proxy in a DMZ), double-check you have applied all relevant security updates, ensure unnecessary services are disabled (or run in a honeypot), do a quick check of your security logs for abnormal login failures, and run some auditing tools like SARA, TARA and Nessus. Perhaps get round to installing Tripwire as well. The less critical the server (either in and of itself, or what someone could do if they compromised it), the more of these you can skip and not look like a fool. Likewise, the more shielded it is from a direct attack, the more you should focus on the machines that are at real risk. The chances are good that it's not a genuine risk to other systems, that it's a lost/stolen key, some idiot blogged their password, or even that an admin found a keylogger on their machine that may have predated the last time they ssh'ed in. There are all kinds of "trivial" reasons for a deep clean that won't affect others. For that reason, getting anxious or in a panic won't help. However, there is always the possibility of a real flaw, so take measures that are appropriate to the systems you run. Beyond that, there is nothing you can do - other than cut the network cable or launch tac nukes at the power socket.
|
|
||||||||||||