[CentOS] an actual hacked machine, in a preserved state

Bennett Haselton bennett at peacefire.org
Thu Jan 5 02:12:06 UTC 2012


On 1/4/2012 3:01 PM, Marko Vojinovic wrote:
> On Wednesday 04 January 2012 11:58:07 Bennett Haselton wrote:
>> If *everyone* used a 12-char random password, then the odds are that
>> *none* of the 10 million machines attacking 100 million servers would
>> hit on a success, not when there are 10^21 possible passwords to choose
>> from.
> It is too naive to identify the statement "something has very low probability"
> with the statement "it will not happen".
>
> There are processes in nature that have 1 / 10^21 (or any other) probability
> of happening, but they are detected to actually happen every couple of seconds
> or so (hint: ask any nuclear physicist).
That's because they are observing quantities of particles on the order 
of 10^21, so the odds of the event occurring are realistic.  (Recall 
Avogadro's number is 6 x 10^23, the number of particles in one mole of a 
substance.)
> In a security-related context, relying on low probability is always a risk
> (regardless of how small), and it should be avoided if feasible. IOW, chances
> of "10^<insert any number here>  to one" are *infinitely* bigger than zero.
> Proof --- divide that number by zero to find out how many times it is bigger.
> ;-)
>
> You should never rely on any probability count if you have critical security
> concerns. Yes, I also use a strong password rather than ssh key (mostly for
> the same reason you do --- convenience), but I understand the risk of doing
> so, I don't have any valuable data on the machine, and I never claim that any
> password is as effective as a ssh key.
Well as I've said it depends on how literally you mean "as effective".  
If your password is strong enough that there's only a 1 in 10^10 chance 
of it being broken by an attacker in the next year, then if an 
alternative method reduces that chance to 1 in 10^20, you could do that, 
but I wouldn't bother.

Again, I would have been perfectly happy to use ssh keys -- it would 
have been less work to switch to ssh keys than to write all the messages 
defending 12-char passwords :)  The reason I wrote all those messages 
about 12-char passwords was not because I wanted to avoid switching to 
ssh keys.  It was because I wanted some alternative suggestions for how 
an attacker could have gotten in, given that the chance of brute-forcing 
the password (even if the attacker had obtained the password hash) was 
so astronomically small!
> Btw, I am also one of the "lucky" people who managed to get hacked by ssh
> brute-forcing. The password was as "random" as it can get, but the attacker
> just got lucky

Not sure what you mean by "as random as it can get", but -- I can write 
this in my sleep by now -- if you have a 12-character password, with 
10^21 possibilities to search from, the odds of an attacker getting 
"lucky" and guessing it, are less probable than you being hit by a 
meteorite tomorrow.  I can absolutely guarantee you that either the 
password was shorter and less random, or else the attacker got it some 
other way (possibly your machine got infected with malware that captured 
your password and uploaded it to a botnet).

> (he didn't get root, though, just my user password, so I could
> mitigate the damage). After that I installed fail2ban, but I still don't keep
> anything valuable on that machine...
>
>>>> However, *then* you have to take into account the fact that,
>>>> similarly,
>>>> the odds of a given machine being compromised by a man-in-the-middle
>>>> attack combined with cryptanalysis of the stream cipher, is *also*
>>>> overwhelmed by the probability of a break-in via an exploit in the
>>>> software it's running.  I mean, do you think I'm incorrect about that?
> Are you basically saying that this is a premature optimization problem? If I
> understand your argument correctly, some attack vectors are much more probable
> than others, so guarding against a low-probability attack vector is
> superfluous, given that there are more probable ones still unguarded. Is that
> what you are saying here?
>
> If yes, let me stress --- the premature optimization issue is *void* in a
> security-related context. The main guideline is rather the "cover all bases"
> principle. The fact that something is unlikely to happen does not mean you
> should not guard against it, if you can. You may find the pain/gain ratio too
> high sometimes, and you are welcome to ignore some obvious security holes for
> the sake of convenience if you like, but you cannot argue that low-probability
> holes are safe to ignore *in* *principle*. That is where the cover-all-bases
> always wins over avoiding premature optimization.

It depend on what you mean by "low probability".  As I said, if it's 
less likely than being hit with a meteor, I don't care.

>>> The archives of this list already had the information about SELinux
>>> contained in this thread.  Not to mention the clear and easily
>>> accessible documentation from the upstream vendor linked to from the
>>> CentOS website.
>> Well every one of the thousands of features and functions of Linux is
>> indexed by Google on the web *somewhere* :)  The question is whether
>> you'll get pointed to it if you ask for help.
> No, this is not the right question. SELinux is enabled by *default* in CentOS,
> and for a good reason. You had to make a conscious choice to disable it, and
> if you are security-aware admin, you should have *first* get yourself educated
> on what you will lose if you do so.
It was disabled by default in every dedicated server and VPS that I've 
leased from a hosting company (except one time).
> So you were already pointed to SELinux (and iptables and some other stuff) by
> the very fact that you installed CentOS. The real question is why did you
> disable SELinux without looking at the documentation or asking on this list is
> it useful for you?
>
> If you are ignorant about security software to begin with, you have no right
> to bitch about relevant information not being available at your glance.
>
>> I didn't doubt that SELinux or iptables both do what they say they do,
>> or that they reduce the risk of a break-in.  My point was that other
>> pieces of "lore" (like "ssh keys reduce the chance of a break-in more
>> than 12-char passwords") have the potential to become part of "folk
>> wisdom" despite not having been tested directly and despite not actually
>> making any difference.
> It's not folk wisdom. The probability of someone guessing your password is
> nonzero (regardless of how small). The probability of someone "guessing" your
> ssh key is still much smaller than that. There is an extremely big difference
> there.
>
> Both methods can be considered "reasonably safe", and at the same time "not
> completely safe", but one *can* compare *relative* safeness, and conclude that
> keys are much safer than passwords. Why do you think people invented keys in
> the first place? Because they were too stupid to see see that a good password
> is "good enough"? I doubt.
>
> Again, it is the cover-all-bases principle.
>
>> Yes, the totality of SELinux restrictions sounds like it could make a
>> system more secure if it helps to guard against exploits in the services
>> and the OS.  My point was that some individual restrictions may not make
>> sense.
> There is a wrong premise here as well. The idea of SELinux is "if it is not
> known to be safe/necessary, restrict it", regardless of whether that
> restriction "makes sense" or not.
>
> If some particular app is known to be safe to use a random port, it will still
> be restricted because *in* *the* *future* the situation may change for the
> worse (the app may introduce an unknown exploit via an update). SELinux guards
> you against such situations, even if *now* there are no known exploits against
> that app, and it doesn't make sense to restrict it. It may make sense in the
> future, so it is again the cover-all-bases principle at work.
>
> Security is all about being paranoid, and SELinux is paranoid by design.
>
> Of course, if you have a need to change it's behavior, you also have the means
> to do so. But it should be *your* decision, while the *default* setting should
> be as paranoid as possible.
>
>> Well yes of course an attacker can try *particular* 12-character
>> passwords, I never said they couldn't :)  And in this case the attacker
>> stole the passwords by grabbing them en masse from a database, not by
>> brute-forcing them.
> You should also be aware that there is no such thing as "random in general".
> Rather, there is only the "random with respect to"-type of randomness. Give me
> any 12-character password that is "completely random" by any standards of
> yours, and I will give you 10 guessing algorithms that will generate precisely
> that password with just 1/1000 probability.
Um... even if you believe passwords are not completely random, this is 
still not correct.  Even under the most pessimistic assumptions about 
random password generation, the chance of guessing a randomly generated 
12-char password are not 1 in 1000.

I assume you were just using sample numbers, but the trouble is that if 
you adjust your sample numbers to closer to the real values, they prove 
the opposite point from the one you're arguing with your original 
numbers.  Even if my random password generator has nonrandomness which 
takes away 20 bits of randomness from the result, your odds of guessing 
it are still only 1 in 10^15 -- not so worrisome anymore.

Look, people are perfectly free to believe that 12-char passwords are 
insecure if they want.  Nobody's stopping you, and it certainly won't 
make you *less* secure, if it motivates you to use to ssh keys.  Again, 
my problem was that the "passwords" mantra virtually shut down the 
discussion, and I had to keep pressing the point for over 100 messages 
in the thread before someone offered a suggestion that addressed the 
real problem, which is exploits in the web server and the operating system.

> As ssh passwords get ever more "random" as perceived by users, the attacker
> scripts will evolve more and more to become efficient at guessing precisely
> those passwords. Exlcuding all dictionary-based passwords is just a first step
> --- an algorithm can be "hardened" to be more and more effective in guessing
> the passwords generated by some other algorithm (even against the "blindly
> banging at the keyboard" algorithm). Its efficiency is of course never perfect,
> but it can get much higher than you would expect.
>
> Consequently, in the future there will be a race between the efficiency of
> password-guessing algorithms and password-generating algorithms, for every n-
> character class of passwords. This is a typical usecase of expert systems,
> machine learning and AI in general (you may want to get informed a bit on
> these topics). ;-)
>
> Therefore, any given password may *look* random (to you, to humans, to some
> algorithms), but it cannot actaully *be* random. This is because in principle
> there always exist algorithms which will generate that password with higher
> probability than some other passwords.
>
> You cannot hide behind randomness.
>
> HTH, :-)
> Marko
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos




More information about the CentOS mailing list