Blackhole

Steve Phillips steve at focb.co.nz
Thu Apr 14 20:40:35 UTC 2005


So why NOT restrict direct root access ? If you ever need to fault find a 
box that is sitting with a 5 min load average of around 50 then the less 
you need to type and the less you need the system to do to verify your 
credentials the better, in some cases directly logging in as root can save 
10-15 mins of downtime.

You were talking mathmatics and chances of something happening being a 
valid reason to restrict access..

So let us put this in perspective.

* Root password is lowercase characters only, a-z (considered a weak 
password)
* 8 characters long
* 100ms to complete the key exchange required for and ssh connection
* 3 password retrys before connection dropped

26^8 (a reasonably close approximate as to how many different combinations 
to try - this assumes we actually know the password length, normally it 
would be more along the lines of 26 + 26^2 + 8^3 etc etc)

26^8 = 208827064576

divide by 30 attempts a second

208827064576 / 30 = 6960902152.5333333333333333333333

convert this into years

6960902152.53 / 60 / 60 / 24 / 365 = 220.73 years

Thats right, around 220 years to brute force my 8 character, all 
lowercase, weak password.

now, considering I tend to use a mixture of punctuation, upper and lower 
case and numerals in my passwords and have them at _least_ 8 characters..

I really think you have more chance of being hit by a meteor on the way to 
work and not completeing your e-mail than you have of brute forcing root 
across a network via ssh.

restricting the hosts that can ssh into the box would IMHO be a far more 
productive use of time. (as well as reading logs, choosing non-weak 
passwords, etc etc)

Oh, and reading logs in this case is quite a good indicator that someone 
is trying to brute force your system (infact, you could go a step further 
and setup an alarm if a single account has a password failure more than 
say - 5 times, it would pick up an attack within the first 200ms) - I dont 
know about you but if I got 208827064576 failed logins for root then I 
would probably notice, infact, I would probably notice after the first day 
at the least.


-- 
Steve.



On Thu, 14 Apr 2005, Wayne Pinette wrote:

> This is all true, but why not just cut off the problem at the source.
> no root login means there is 0 chance for any kind of brute
> force hacking of any kind on that account.  The rest are very nice and
> important security additives.  As for brute forcing non root passwords
> first, well, first you have to know what they are.  There is an extra
> step right there.  Secondly,
> (and I know this is a redhat list but what the heck :-) If you have  a
> infrastructure similar to that of a standard Tru64 system, not all user
> acccounts can su.  So There is yet another step in which not only would
> you have to find an account to force, you would have to find the right
> account to force.
>
> And reading logs only tells you have been hacked, it does not stop it.
>
> In the end, you are right in that "no remote root" all by itself does
> not make a system secure.  As far as Im concerned, you can never
> be too secure when it comes to the root account, and IMHO, the best
> security is security which nips problems in the bud.
> Therefore, for me, not setting no remote access to root on a publicly
> accessible system is just silly and does open a door, however
> small that opening is is subject to interpretation, to a potential
> issue.
>
> Of course, on my way to work today, there was a potential a meteor was
> large enough to burn through our atmosphere,
> being reduced to the size of a quarter by the time it hit my elevation,
> and ping me in the head.  Thereby not allowing me to
> create this email.  But we all have our risk levels we cope with every
> day  :-).
>
> Wayner
>




More information about the redhat-list mailing list