Re: an actual hacked machine, in a preserved state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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).

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.

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 (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.

> > 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.

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.

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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux