In Files Users & Permissions vpsBible explained about users and files, the formers' ownership and the latters' permissions. If this stuff is not absolutely clear to you then you need to read that. Really.
Now, given that cornerstone security knowledge we'll spring clean the server by looking for dangerous files in three concerning categories:
- Suspect hidden files & directories
Hidden files are generally fine but they can also be malicious, for example acting as backdoors that give a hacker on-demand access to use your server, perhaps even as a zombie machine from which to launch DoS attacks while tapping your server resources. We'd best check.
To list files using a terminal, here's the syntax:
In your home directory, for instance, that should show up some files prefixed with a dot:
Good. Now you can join the dots. Let's run some scans, printing results to the screen. The first is for a hidden directory. Repeat the scan replacing the d with an f for file:
Shared hosting types will save a ton of time using a terminal for this job but the alternative is to trawl file explorer. Drop sudo because you don't have superuser privileges to elevate to.
Variations on the regular .* theme could be ..* or .. * (with the space). Mix it up and, again for all examples, run scans both for files and directories:
- Protecting world-writable files
If you share a server, you should ensure files are not writable by other users. Have a scan:
Tip: By using sudo, you scan all files. Leave it out and, using your more basic rights, you scan only yours.
Check the ensuing list and change the permissions to something ditch-water dull.
- Scrutinising SxID files
Set-user-ID or SUID is a special permission allowing files to be executed by any user using the ownership rights of the file owner. Set-group-ID or SGID files are similar, allowing these files to be executed by any user using the ownership rights of the file group. Either way, an SxID, which can be either an SUID or an SGID file, can be triggered by a hacker for malicious means. Planted SxIDs are sometimes backdoors set up by hackers to give them quiet access to servers.
So why have these special permissions? Take the example of a password change …
The /etc/shadow file contains the encrypted passwords for every system and human user and, of course, regular site users (other users) can't view this file, let alone edit it. Instead, it belongs to the root superuser. Now, let's say you want to change your key and can't elevate to root, for example if you're on a shared server. Instead, you would execute the /usr/ bin/passwd program which is also owned by root and which has SUID permissions. You'd give that program your new password and, because SUID provides the file owner's privileges, passwd runs as root, not you, and is able to edit your password in the shadow file.
So that's nice, but unneeded SxIDs are best culled. So which ones? List the candidates:
That throws up a list with questionable SxID requirements such as chage to set password expiration and mount to mount file systems. For any unknowns, peek at the manual:
To demote each to safe permissions, don't forget to edit the path to the file:
Keeping track of changes with SXID
Righty-ho, so what about those newly planted SxIDs from our friendly hackers? We can keep an eye out for those, along with any changes to your remaining SxID files, using the aptly-named SXID, a tidy application that should be set up as a daily cron job to check and e-mail you when changes are detected.
Installing SXID is this easy:
Run it as root:
You should receive an automatic report by e-mail but, if not, configure your notification setting in the configuration file:
Look for this:
Swap root for an e-mail address and, while you're about it, read the file. It's nicely commented for tweaking.
There's not a lot of point having SXID if you don't cron it to run automatically:
Add something like this, which runs SXID daily at 8:12am:
OK, breathe easy.
All that lot got a bit technical and you likely got involved with some Google hacking. Otherwise, if in doubt, there's always the …