Another update on Fedora infrastructure

There's a diversity argument too. If everyone's infrastructure relies on RSA exclusively and
then next week someone finds a serious problem in RSA then you've got a massive disaster.

Which doesn't add up to an argument for DSA, but it does mean it's not enough to say "RSA is
better, we'll just use that". We know that RSA is no /harder/ than the factorisation problem,
but we don't have a proof that it isn't /easier/ perhaps /much easier/. We must have
alternatives, maybe Elliptic Curve or maybe something quite different.

I'm sorry. Speculating is fun though.

Maybe they introduced a trojan into the build sources for an update and Linus installed that
update and then they changed the kernel source on Linus' box ( because he is running fedora,
isn`t he. He shouldn`t say something like that by the way, makes him _obviously_ more
vulnerable ;P ) and from now on all kernels will be exploitable by default... B)

But seriously: I'm just kidding .. like I said: Speculating is fun.

All this secrecy gets tiring. First the huge bubble about DNS, now Fedora. What I kinda miss
in all of this mess is an informant leaking details ;-)

This is what I was thinking. It wasn't that long ago that something similar happened in the
Debian project, though that was 'only' a developer (and not an administrator IIRC). If one of
the Fedora admins, say, had privileged login for several of the main fedora project servers
saved on their laptop and then their laptop got stolen, the project may be taking all this as
a precautionary attempt to change all their login/keys/etc and they're keeping quiet because
they're hoping they can get everything before the person realizes what they got.

Going further with this hypothetical, it's possible there were several days before the laptop
being stolen and the Fedora projecting finding out so they may simply be worried that any
would-be attackers were able to take any credentials on the laptop and spread to other parts
of the system as well, and they're using this as an opportunity to do a *complete*
audit/reinstalls/upgrades/etc.

Then again, this is all speculation so I may be completely off.

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.