Posted on Leave a comment

Securing The New Server & Security In General

This was originally going to be part of another post, but it ended up getting more complex than I originally intended so it’s been given it’s own. I go into into many of my personal security practices, on both my public facing servers & personal machines. Since the intertubes are so central to life these days, good security is a must, especially since most people use the ‘net to do very sensitive operations, such as banking, it’s becoming even more essential to have strong security.

Since bringing the new server online & exposing it to the world, it’s been discovered in record time by the scum of the internet, SSH was under constant attack within 24 hours, and within that time there were over 20,000 failed login attempts in the logs.
This isn’t much of an issue, as I’ve got a strong Fail2Ban configuration running which at the moment is keeping track of some 30 IP addresses that are constantly trying to hammer their way in. No doubt these will be replaced with another string of attacks once they realise that those IPs are being dropped. I also prevent SSH login with passwords – RSA keys only here.
MySQL is the other main target to be concerned about – this is taken care of by disabling root login remotely, and dropping all MySQL traffic at the firewall that hasn’t come from 127.0.0.1.

Keeping the SSH keys on an external device & still keeping things simple just requires some tweaking to the .bashrc file in Linux:

This little snippet makes the ssh client look somewhere else for the keys themselves, while keeping typing to a minimum in the Terminal. This assumes the external storage with the keys always mounts to the same location.

Everything else that can’t be totally blocked from outside access (IMAP, SMTP, FTP, etc), along with Fail2Ban protection, gets very strong passwords, unique to each account, (password reuse in any situation is a big no-no) and where possible TOTP-based two factor authentication is used for front end stuff, all the SSH keys, master passwords & backup codes are themselves kept offline, on encrypted storage, except for when they’re needed. General password management is taken care of by LastPass, and while they’ve been subject to a couple of rather serious vulnerabilities recently, these have been patched & it’s still probably one of the best options out there for a password vault.
There’s more information about those vulnerabilities on the LastPass blog here & here.


This level of security paranoia ensures that unauthorized access is made extremely difficult – an attacker would have to gain physical access to one of my mobile devices with the TOTP application, and have physical access to the storage where all the master keys are kept (along with it’s encryption key, which is safely stored in Meatware), to gain access to anything.
No security can ever be 100% perfect, there’s always going to be an attack surface somewhere, but I’ll certainly go as far as is reasonable, while not making my access a total pain, to keep that attack surface as small as possible,and therefore keeping the internet scum out of my systems.
The last layer of security is a personal VPN server, which keeps all traffic totally encrypted while it’s in transit across my ISP’s network, until it hits the end point server somewhere else in the world. Again, this isn’t perfect, as the data has to be decrypted *somewhere* along the chain.

Posted on Leave a comment

CentOS 7 Sentora 1.0.3 PHP5.6 Upgrade Script

Since Sentora is still stuck on an old version of PHP, this script will update the system to the newer v5.6, via the Remi repository, as most things are deprecating support for older PHP versions at this point. Suhosin will also be recompiled for the new PHP version.

The Remi repo will give some package authentication warnings, these can be safely dismissed during the install. I’ve tested this on a fresh install of Sentora under CentOS 7, however this process isn’t without risk! Your PHP install could be damaged!

Posted on 4 Comments

Sentora 1.0.3 SpamAssassin Setup & Training Scripts

I’m making some changes to my hosting services, I’ve been testing Sentora, as it’s much more user friendly, if a little more limited in what it’s capable of doing, vs my go-to admin panel over the past 6+ years, Virtualmin.

I noticed that SpamAssassin isn’t set up on a Sentora server by default, so here’s a script that will get things working under a fresh Sentora install in CentOS 7:

After this script has run, some mail server settings will be changed, and the master.cf configuration file for Postfix will be backed up just in case it craps out.

Make sure the SpamAssassin daemon is running on port 783 with this command:

Testing is easy, send an email to an address hosted by Sentora with the following in the subject line:

If SpamAssassin is working correctly, this will be tagged with a spam score of 999.

A useful script is below, this trains SpamAssassin on the mail in the current server mailboxes. I’ve been using a version of this for a long time, this one is slightly modified to operate with Sentora’s vmail system. All mail for all domains & users will be fed into SpamAssassin in this script. I set this to run nightly in cron.