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
-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
