Hi gang,
Editorial
Every once in a while a serious issue surfaces on these forums: allowing root to remotely log onto a server directly. This is generally speaking a horribly bad idea and for a multitude of reasons. So I figured, why not write 'm all out?
Disclaimer
Do note that I'm not claiming that allowing remote root logons will always result in trouble. That's also not the problem. The problem is that you're putting the system at more (unneeded) risk. Risks which can have dire consequences and which could be easily avoided.
#1 => You shouldn't use the root account casually in the first place
Root is a system account. Some might argue that it's the systems administrator account but that is only partially true. Basically every account within the wheel group can be considered a systems administrator. Don't take my word for it though, just check /etc/newsyslog.conf. You do realize that all those 640 permission modes basically mean: "Allow root and everyone in the wheel group to read this"?
But back to root: there is normally no need to use the root account casually. It's an utterly bad idea in the first place because mistakes made as root can have far more severe consequences than those of a regular user. But most of all: there's no need!
Sure: by default several services are set up to allow for root to change their settings and no one else:
But what gives you the idea that this is also the way you should be using this? All FreeBSD does (together with most of its services) is give you a decent default setting. But that doesn't mean that the default is also the only usable way!
Sure: I can't perform specific pkg operations as a regular user. But that's also not the point: the point is to minimize the usage of root as much as possible. And not only because of possible mistakes...
#2 => Root is a target
It's not just root which you shouldn't allow direct access to your system. This aspect extends to every default service account on your system (generally speaking all accounts below UID 1000). Simply because their existence is (or can be) well known which makes them viable targets for an attack. A small side step: don't forget about the existence of local root exploits; this means that merely having access to a command line could be enough for an attacker to elevate themselves to root status.
But the main problem is that everyone who is somewhat familiar with Unix(-like) systems will know about the root account and that makes this a de-facto target for an attack. Meaning that allowing the account to log on directly is simply asking for problems.
#3 => You can't be sure about exploits
Just because no CVE entry exists about the ability to force sshd into bypassing the logging of failed logon attempts doesn't automatically imply that no such flaw can exist. Yes, this is a bit of paranoia thinking but if you value your server security then that is exactly the line of thinking you sometimes need to do: 'what ... if?'.
See, there's another concern: which sshd flaw would have more chances to be discovered and fixed: a flaw within the encryption / logon routines or a flaw within the logging routines? Well, considering that OpenBSD is in charge of the OpenSSH project I'd say both stand an equal chance, but the priority concern still exists.
#4 => Root access is the end of the line
Although the risk of local root exploits is an issue to consider it doesn't imply that those exist or that an attacker would know about them (or can even exploit them). So if an attacker manages to exploit a regular account then the amount of damage they can cause is usually limited to the access level of that account.
But once an attacker manages to intrude as root then it is game over. You probably wouldn't even be the wiser because once you have full access to a system then it's pretty easy to hide your tracks. Which brings me to:
#5 => You won't notice a successful attack
Unless you have a setup where your logs get sent to an external log host in real time then you can forget about relying on your logfiles (or other services) to inform you about the problem.
Because ask yourself this: if an attacker has root access then can do whatever they want. So what is stopping them from disrupting (or worse) any security measures you might have set up?
You have a rootkit scanner? Good for you! What makes you think it already supports the tools used by the attacker? You simply can't be sure about that.
#6 => You can't "just" turn things off after a succesful attack
This is an argument I actually heard on some conferences and it makes me want to facepalm really hard... "But if I did notice someone enter as root I can always disable the option again".
Yes, you can do that but it won't change anything anymore.
Once a system has been compromised there is only 1 remedy to fix it: back up the configuration, wipe the entire system clean, re-install everything from scratch and then carefully check the configuration settings before re-applying them. There is no middle ground here.
For pretty much the same reason as #3: you cannot be sure that no (exploitable) backdoors haven't been left on your system. The only way to be sure is to perform a completely clean re-installation.
#7 => Direct root logon is totally unneeded
Because there's normally no need to use root casually all the time, as mentioned in #1, there's also no reason to allow a direct log on. In most cases people do this because they're lazy, it's too much work for them to log on and then log on again (now referring to su).
So instead of allowing root to log on directly, why not change it so that you don't have to elevate your permission status? I'm not claiming that this can be done all the time, but it definitely can most of the times.
But seriously: laziness and server security simply don't go hand in hand. Sometimes you need to perform some extra steps in order to keep yourself safe. That's just the way it is.
#8 => You're not only putting yourself at risk
This is the reason why I personally think that anyone allowing direct root logons on a public server is also somewhat selfish. Especially if we're talking about things which fit into one of the previously mentioned items.
Once your system has been taken over you can bet that it will be abused to cause more damage to other systems. Either mildly by setting up a spam relay or more aggressively by adding it to a botnet (or worse).
One way or the other it will likely be others who get to suffer the most from your mistakes.
And there you have it!
A few arguments why you really shouldn't allow remote root logons. Thanks for reading, hope this could be useful for some of you.
Editorial
Every once in a while a serious issue surfaces on these forums: allowing root to remotely log onto a server directly. This is generally speaking a horribly bad idea and for a multitude of reasons. So I figured, why not write 'm all out?
Disclaimer
Do note that I'm not claiming that allowing remote root logons will always result in trouble. That's also not the problem. The problem is that you're putting the system at more (unneeded) risk. Risks which can have dire consequences and which could be easily avoided.
#1 => You shouldn't use the root account casually in the first place
Root is a system account. Some might argue that it's the systems administrator account but that is only partially true. Basically every account within the wheel group can be considered a systems administrator. Don't take my word for it though, just check /etc/newsyslog.conf. You do realize that all those 640 permission modes basically mean: "Allow root and everyone in the wheel group to read this"?
But back to root: there is normally no need to use the root account casually. It's an utterly bad idea in the first place because mistakes made as root can have far more severe consequences than those of a regular user. But most of all: there's no need!
Sure: by default several services are set up to allow for root to change their settings and no one else:
Code:
peter@zefiris:/usr/local/etc $ ls -l pkg*sample
-rw-r--r-- 1 root wheel 2143 May 15 01:36 pkg.conf.sample
Code:
peter@zefiris:/usr/local/etc $ ls -l pkg.conf apache24/httpd.conf
-rw-rw-r-- 1 root wheel 17982 Jun 6 08:01 apache24/httpd.conf
-rw-rw-r-- 1 root wheel 405 Jul 15 19:43 pkg.conf#2 => Root is a target
It's not just root which you shouldn't allow direct access to your system. This aspect extends to every default service account on your system (generally speaking all accounts below UID 1000). Simply because their existence is (or can be) well known which makes them viable targets for an attack. A small side step: don't forget about the existence of local root exploits; this means that merely having access to a command line could be enough for an attacker to elevate themselves to root status.
But the main problem is that everyone who is somewhat familiar with Unix(-like) systems will know about the root account and that makes this a de-facto target for an attack. Meaning that allowing the account to log on directly is simply asking for problems.
#3 => You can't be sure about exploits
Just because no CVE entry exists about the ability to force sshd into bypassing the logging of failed logon attempts doesn't automatically imply that no such flaw can exist. Yes, this is a bit of paranoia thinking but if you value your server security then that is exactly the line of thinking you sometimes need to do: 'what ... if?'.
See, there's another concern: which sshd flaw would have more chances to be discovered and fixed: a flaw within the encryption / logon routines or a flaw within the logging routines? Well, considering that OpenBSD is in charge of the OpenSSH project I'd say both stand an equal chance, but the priority concern still exists.
#4 => Root access is the end of the line
Although the risk of local root exploits is an issue to consider it doesn't imply that those exist or that an attacker would know about them (or can even exploit them). So if an attacker manages to exploit a regular account then the amount of damage they can cause is usually limited to the access level of that account.
But once an attacker manages to intrude as root then it is game over. You probably wouldn't even be the wiser because once you have full access to a system then it's pretty easy to hide your tracks. Which brings me to:
#5 => You won't notice a successful attack
Unless you have a setup where your logs get sent to an external log host in real time then you can forget about relying on your logfiles (or other services) to inform you about the problem.
Because ask yourself this: if an attacker has root access then can do whatever they want. So what is stopping them from disrupting (or worse) any security measures you might have set up?
You have a rootkit scanner? Good for you! What makes you think it already supports the tools used by the attacker? You simply can't be sure about that.
#6 => You can't "just" turn things off after a succesful attack
This is an argument I actually heard on some conferences and it makes me want to facepalm really hard... "But if I did notice someone enter as root I can always disable the option again".
Yes, you can do that but it won't change anything anymore.Once a system has been compromised there is only 1 remedy to fix it: back up the configuration, wipe the entire system clean, re-install everything from scratch and then carefully check the configuration settings before re-applying them. There is no middle ground here.
For pretty much the same reason as #3: you cannot be sure that no (exploitable) backdoors haven't been left on your system. The only way to be sure is to perform a completely clean re-installation.
#7 => Direct root logon is totally unneeded
Because there's normally no need to use root casually all the time, as mentioned in #1, there's also no reason to allow a direct log on. In most cases people do this because they're lazy, it's too much work for them to log on and then log on again (now referring to su).
So instead of allowing root to log on directly, why not change it so that you don't have to elevate your permission status? I'm not claiming that this can be done all the time, but it definitely can most of the times.
But seriously: laziness and server security simply don't go hand in hand. Sometimes you need to perform some extra steps in order to keep yourself safe. That's just the way it is.
#8 => You're not only putting yourself at risk
This is the reason why I personally think that anyone allowing direct root logons on a public server is also somewhat selfish. Especially if we're talking about things which fit into one of the previously mentioned items.
Once your system has been taken over you can bet that it will be abused to cause more damage to other systems. Either mildly by setting up a spam relay or more aggressively by adding it to a botnet (or worse).
One way or the other it will likely be others who get to suffer the most from your mistakes.
And there you have it!
A few arguments why you really shouldn't allow remote root logons. Thanks for reading, hope this could be useful for some of you.