A few weeks back, a friend called up asking for a solution to his problem of trying to upload pictures while implementing WordPress. A day later when I asked him how he had solved it, he responded, to my utter shock, “I changed the permissions of all folders to 777″!
777 is your enemy. Stay away!
As system administrators, we are always short of time. Therefore, changing file or folder permissions, blindly, to 777 may seem like the easy way out, at times. But this can be a big mistake. Since 777 stands for full – read/write/execute – permissions for all users on the server, this is dangerous. On multiple user/shared servers, any other user can undertake any operation on the folder or file – like modify/delete – which has 777 permission, even though the file/folder was not meant to be accessible by that user.
Even on servers which are not shared by multiple users, this can be dangerous, especially if you have 777 permissions on files or folders which reside within or below the http files folder – httpdocs or wwwroot. Consider a plug-in, written in PHP, that you install on WordPress, which exploits such file/folder permissions. Leaving the ’777 door’ open can then easily compromise the server or the application/executable within the target folder, by way of such a plug-in, advertently or inadvertently. One could have a similar disastrous result in case of a remote code injection into a vulnerable application.
There are times when you will need to have writable directories for certain applications. A safe method to implement that is to move these directories out of the application’s (let us say PHP) base directories. e.g. Above the web/root folder. You can modify the application / its configuration file to specify the change in the location of the folder.
Here is a way to check, which files/folders have 777 permissions.
#ls -la total 12 drwxr-xr-x 3 root root 4096 May 21 00:05 . dr-xr-x---. 5 root root 4096 May 21 00:05 .. drwxrwxrwx 2 root root 4096 May 21 00:05 check
This shows that the folder ‘check’ has 777 permission.
You can easily change it using the chmod command.
Remove unwanted services
Another common mistake an administrator can make on a server is to leave unwanted services running. For example, if you leave a mail component like SMTP installed on your server, you are inviting trouble from potential spammers. Any service which is not required, should be removed. This reduces the possibility of abuse as well as the potential threat arising out of a vulnerability in that service. Of course any service that is required will have to be installed or retained. It should be configured properly and updated/patched regularly, though.
Here is how you can check for services which are installed on CentOS/RHEL:
# yum list installed
Here is how you can check the same on Ubuntu:
# dpkg --list
And here is how you can remove any unwanted service.
# yum remove servicename
# apt-get remove servicename
These are just two of the many steps one can take to harden the security of one’s server or machine. We can continue to delve on other steps, in the following posts.
For more information, Rudhir Sharan, the founder of SecPanel is available on twitter @RudhirSharan