Despite my previous stance... (also, server security!)

The feed from my blog  is now the default news that will be displayed on 666igma.com - I've set this up because I think it will be easier to have all of my updates posted to a single platform. Unfortunately, this has caused me to lose some of the previous news posts that existed, but I really think that is not a very big deal.

Give me some time to get it looking and functioning properly on the website... it really should not take too long.

I am also posting this during the midst of CONSTANT intrusion attempts on my server. I've literally got a backlog of various IPs trying to access tons of different services on different ports and authenticate. I've recently moved my SSH port and disabled root login from it entirely as one of my security precautions, and if you run a Linux server with SSH enabled, I suggest you do the same.

Security through obscurity (STO), is not a great practice... that is what it is called just changing you SSH daemon to some random port in the hopes that it will not be found - It is very easy to find all services on a given machine. Hackers right now are not just discovering websites that are on the internet and randomly trying to attack them they are trying to attack entire IP BLOCKS. What this means is that they are running brute-force style attacks on any given ip that might exist within a particular range of IPs.

No big deal! There are tons of ways you can improve the security of your server. Fail2Ban is a nice option, it tries to detect these types of intrusions and eliminate them.

Here is an example of what my /var/log/auth.log looked like during the attacks:

Mar 20 07:35:05 jserve sshd[31187]: Failed password for root from 218.65.30.53 port 36066 ssh2
Mar 20 07:35:05 jserve sshd[31187]: error: maximum authentication attempts exceeded for root from 2$
Mar 20 07:35:05 jserve sshd[31187]: Disconnecting: Too many authentication failures [preauth]
Mar 20 07:35:05 jserve sshd[31187]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=s$
Mar 20 07:35:05 jserve sshd[31187]: PAM service(sshd) ignoring max retries; 6 > 3
Mar 20 07:35:07 jserve sshd[31191]: Failed password for root from 183.214.141.101 port 14556 ssh2
Mar 20 07:35:08 jserve sshd[31448]: pam_unix(sshd:auth): authentication failure; logname= uid=0 eui$
Mar 20 07:35:10 jserve sshd[31191]: Failed password for root from 183.214.141.101 port 14556 ssh2
Mar 20 07:35:11 jserve sshd[31448]: Failed password for root from 218.65.30.53 port 8127 ssh2
Mar 20 07:35:13 jserve sshd[31191]: Failed password for root from 183.214.141.101 port 14556 ssh2
Mar 20 07:35:14 jserve sshd[31448]: Failed password for root from 218.65.30.53 port 8127 ssh2
Mar 20 07:35:15 jserve sshd[31191]: Failed password for root from 183.214.141.101 port 14556 ssh2
Mar 20 07:35:17 jserve sshd[31448]: Failed password for root from 218.65.30.53 port 8127 ssh2
Mar 20 07:35:18 jserve sshd[31191]: Failed password for root from 183.214.141.101 port 14556 ssh2
Mar 20 07:35:18 jserve sshd[31191]: error: maximum authentication attempts exceeded for root from 1$

There are literally pages upon pages of these attempts and failures. Far too many for me to post here, even. When did they start? I'm uncertain. When did they stop? When I changed my SSH port, first, but I also changed my SSH configuration.

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

This was previously set to PermitRootLogin prohibit-password - In some earlier versions of the SSH configuration files, this was styled as PermitRootLogin no-password which is confusing, right? That would seem to indicate that root could login with no password! However, that was not the case, just an issue with how the configuration was named. With prohibit-password and no-password there is still the ability for root to login via a public key. Fairly secure, but why allow root to login AT ALL? The root user is not even really used any more by any semi-secure system for any operation.

In addition, several of the forms I have provided for many of the websites I host have experienced attacks recently. Most were trying to utilize some form of SQL injection attack. In a hilarious twist of events, one of the forms that was being targeted did not even interact with SQL at all. If you take form input from users, make sure to sanitize the data. There are a lot of ways to go about this and I am experimenting with some novel methods even as I write this to make forms very secure in a way that I do not think has ever even been tried before.

Oh, that got you interested? Well, let me explain. Normally, an attacker might try to do things with an input form that will cause their input information to be read and executed by the server. If you normally take a variable and put it as part of the INSERT command as a string, for instance, malicious code can be run. The normal ways of preventing this are to make sure the user can ONLY input information compatible with that particular form. A good way to stop most attacks dead in their tracks are by limiting the input data to a certain number of characters.

This might not always be possible though, what if you are allowing them to post large blocks of text... say like on a forum post or as a comment? That could obviously create an issue. Tons of commands can be run against the input string to check it for malicious code or try to disable it in some manner if it includes characters that might lead to the input of malicious code.

One of the new ways I've devised to sanitize the input of user data is to COMPRESS it!

$string = "Compress this string to death!";

$compressedString = gzcompress($string, 9);

echo $compressedString;

That code will create this string as output:

x�s��-(J-.V(��,V(.)��KW(�WHIM,�P �* &  

Obviously some of those characters are errors, but that is the point here. There would be no real way to structure most attacks to take advantage of this compression to accurately execute their attack (and even if they could, two advantages here... STO (Security Through Obscurity - how would they know I am even compressing it in this manner?) and second, even if they were, in theory, able to create a string that might compress into an attack, it would be horribly obtuse and likely exceed even the most generous character limitations on form inputs.

Maybe "SVC", or Security Via Compression, will become a thing some day. If it ever does, remember that you read about it here first!

Interesting concept, right?