It's also a good idea to install (and configure) at least some basic IDS like tripwire. You should probably have it do checks on a cron job
as well as doing chkrootkit.
Also a good idea to have your log files backed up somewhere else where your server does not have sufficient access to delete (or modify) them.
Also if you have multiple web apps running, chroot them if at all possible so that if something does break out it can't (so easily) wreak havok over your entire filesystem.
If you are using PHP also bare in mind that a common default is for all sessions to be written to /tmp which is world read and writeable. So if others have access to your server they can steal or destroy sessions easily.
I also didn't see mention of an update strategy for security updates. You can use apticron to email you with which updates are available and which are important for security.
You can set updates to go automatically (I recommend security only) but if you are more cautious
you might want to test on a VM first. But keep an eye on them! This is very important, especially if you are managing wordpress etc through apt.
And so many other things that I have probably forgotten.
Having some form of audit (that tripwire can provide) is vital in those "oh fuck" moments where something doesn't seem quite right and you start wondering if you have been pwned but have no real way of actually knowing.
> If you are using PHP also bare in mind that a common default is for all sessions to be written to /tmp which is world read and writeable. So if others have access to your server they can steal or destroy sessions easily.
I'm slightly confused by this, within the context of this article. Yes, /tmp is readable and writable by all, but that doesn't mean that everything in it is readable or writable to other people. The sessions that PHP creates will be owned by the webserver user (nobody/www-data/something else), and shouldn't be readable or writable by other users.
This is still a problem with shared hosting, where you might have multiple websites running on the same server. One shared host would be able to read another's sessions, because they are all running under the webserver's user. This[1] suggests overriding the session_set_save_handler and writing to a resource that only you control, such as your DB.
Also a good idea to have your log files backed up somewhere else where your server does not have sufficient access to delete (or modify) them.
Also if you have multiple web apps running, chroot them if at all possible so that if something does break out it can't (so easily) wreak havok over your entire filesystem.
If you are using PHP also bare in mind that a common default is for all sessions to be written to /tmp which is world read and writeable. So if others have access to your server they can steal or destroy sessions easily.
I also didn't see mention of an update strategy for security updates. You can use apticron to email you with which updates are available and which are important for security.
You can set updates to go automatically (I recommend security only) but if you are more cautious you might want to test on a VM first. But keep an eye on them! This is very important, especially if you are managing wordpress etc through apt.
And so many other things that I have probably forgotten.
Having some form of audit (that tripwire can provide) is vital in those "oh fuck" moments where something doesn't seem quite right and you start wondering if you have been pwned but have no real way of actually knowing.