The average time it takes for a cloud server to be hacked from the time of its birth is less than one day if it a simple password like (passw0rd, 123456, abcdef)
The average time taken to hack a wordpress site with simple password is probably less than a day.
How’s that possible ?
It is possible with the help of today’s botnet that literally scans every IP block till they find a server, then start scanning for PHP versions, WP version, CMS logins, SSH Logins etc, Linux version ..
You can never be carefull enough when it comes to your Website security especially if you are a cloud hosting provider.Once a wise man told me “better to be extremely safe than dead sorry.
However, why not use Shared Hosting instead Cloud Servers?
Well, the reason being shared hosting as the name says it, means the resources are shared, you are not guaranteed CPU or RAM and often malware from other Shared Hosting accounts can find their way into your hosting account due to the Sysadmin negligence or vulnerabilities.If you are just hosting a blog, then a shared hosting would suffice.Anything other than a blog like a company website or e-commerce or a website that showcases a bunch of services you offer then it is best you look into a VPS or Cloud Server.
So buying your first cloud server?
There are too many out there, some of the popular choices are Amazon cloud, Singlehop, Google cloud and particularly impressive digital oceans cloud, quite unbelievable how they can get your cloud up and running in under 2 min.
Then there is also the managed cloud server offering from Olexor Technologies, most of them have a pricing of about 40$ – 80$ without management, but Olexor offers the cloud server with management for 40$, which includes a web-based firewall platform as your first line of defense, pretty affordable, I know right.
So what OS ?
I would go with one of the popular Linux flavored, the one that I recommend is Ubuntu 14.04 , the reason being – it works really well with Virtualmin and WordPress and other popular CMS additionally it has support till 2019.CentOS is a popular choice too.
Now comes the hard stuff, so how do you secure your first cloud server ?
If we had to summarize the main steps would be
Securing your cloud server
- Set up iptables
- Setup Clam antivirus
- Limiting SSH access
1.Setting up iptables , below are set of rules I defined, BTW I compiled these rules with the help of these links
-A INPUT -p tcp -m tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp -m state ! –tcp-flags FIN,SYN,RST,ACK SYN –state NEW -j DROP
-A INPUT -p tcp -m tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
The above three rules are some ground rules to block the most common attacks and script kiddies, scanning bots. Basically, the above rules block null packets, syn-flood attack, xmas packets AKA recon packets etc.
-A INPUT -p icmp -m icmp –icmp-type 17 -j DROP
-A INPUT -p icmp -m icmp –icmp-type 13 -j DROP
-A INPUT -m state –state INVALID -j DROP
The above three rules are to Stop smurf attacks
-A INPUT -p tcp -m tcp -m limit –tcp-flags RST RST –limit 2/sec –limit-burst 2 -j ACCEPT
The above rule is to Drop excessive RST packets to avoid smurf attacks
-A INPUT -m recent -j DROP –rcheck –seconds 86400 –name portscan –mask 255.255.255.255 –rsource
-A INPUT -m recent –remove –name portscan –mask 255.255.255.255 –rsource
The above rules Attempts to block port scans and Anyone who tried to portscan us is locked out for an entire day and once the day has passed, the second rule removes them from the list.
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp –dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 465 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 22 -j ACCEPT
It will allow any established outgoing connections to receive replies from the VPS on the other side of that connection. When it is all setup, we will block everything else, and allow all outgoing connections.
-A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
The above rules allow our favourite ports for web traffic(80), SSL traffic(443), SMTP(25), SSMTP(465), POP3(110), Secure POP3 over TLS(995), IMAP(143), Secure IMAP over TLS(993), SSH(22).
iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
The above two commands is to allow traffic to go out by default and block anything from coming into the server.
Please be aware that the ports to be opened depend from server to server, please make sure you do not lock yourself out, if you are unsure please do some research or check with your System Admin.It will also be a good idea to make sure if your cloud service provider has a backup console access in case you lock yourself out or even the ability to make snapshots and capacity to revert in case things go south.
Other additional iptable rules you can use
# Reject spoofed packets
iptables -A INPUT -s 10.0.0.0/8 -j DROP iptables -A INPUT -s 169.254.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP iptables -A INPUT -s 127.0.0.0/8 -j DROP iptables -A INPUT -s 22.214.171.124/4 -j DROP
iptables -A INPUT -d 126.96.36.199/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP iptables -A INPUT -d 240.0.0.0/5 -j DROP
iptables -A INPUT -s 0.0.0.0/8 -j DROP is/8 -j DROP iptables -A INPUT -d 188.8.131.52/24 -j DROP
iptables -A INPUT -d 255.255.255.255 -j DROP
-A INPUT -p tcp -m recent -i eth0 –dport 80 –state NEW -j DROP –update –seconds 60 –hitcount 10 –name DEFAULT –mask 255.255.255.255 –rsource
-A INPUT -p tcp -m tcp -m state -m recent -i eth0 –dport 80 –state NEW –set –name DEFAULT –mask 255.255.255.255 –rsource
The above two commands limit the amount of concurrent connections from the same IP address, first command will keep an eye out for the IP’s connecting to your eth0 interface.The second command will Check if the connection is new within the last 60 seconds and if the packet flow is higher than ten and if so it will drop the connection and make the rules persistent in case of a reboot.Be extremely careful with this rule, use this rule if you are especially suspecting some DDOS attack, in some case, there might be the need for more than ten connections coming from a single IP.Like, for example, you are expecting over 50 clients to be accessing your website from the same Public NAT IP, then you want to increase the value from 10 to say 50 – 100, also have a clear understanding of web sockets before you do this.
Setting up Antivirus Scanner on your server
Do you really need it ?
Well it is highly recommended if you are hosting mail on your server, but we would personally still recommend having it, just to be on the safe side, although it may seem like a reactive measure.But if you are running on a low RAM server (less than 2GB), Then it may tax your cloud server a bit, but nonetheless it’s worth it for added security.
Install the ClamAV
- apt-get update && apt-get install clamav
- Service ClamAV-freshclam start
- Freshclam -v
After the ClamAV is installed and updated, now we will make a script to run the ClamAV to run every day at 12:00 am and store the log files in the VAR folder with the files saved in the Year/Month/Day format.
Then We create the file :
and we paste the following code:
/usr/bin/clamscan -i -r $SCAN_iDIR >> $LOG_FILE
Log files are stored by date (Year/month/day) in /var/log/clamav
That’s it, you can even install mutt and have the log files delivered to your inbox.This below link can help you to achieve this
- Limiting SSH access
SSH is your main door to your server and it must be well protected, so first and foremost make sure you use a strong root password
- At least 8 characters—the more characters, the better
- A mixture of both uppercase and lowercase letters
- A combination of letters and numbers
- An inclusion of at least one special character, e.g., ! @ # ? ]
Create another user and log into your server using that one rather than root user.
Another Security measure to implement with login via SSH is to implement Private SSH keys
SSH Keys : Sometimes passwords can be hacked by brute force and to avoid that we use Public and Private Key, the public key can placed on the server and private should be kept in your possession in a safe place and the only way to get into the server would be by using that private key, you can further protect with a passphrase.
So how do we go about it?
The below steps were compiled with the help of this link https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys–2
1.Create the RSA Key Pair
The first step is to create the key pair on the client machine (there is a good chance that this will just be your most trusted computer):
ssh-keygen -t rsa
2.Store the Keys and Passphrase
Once you have entered the Gen Key command, you will get a few more questions:
Enter file in which to save the key (/home/demo/.ssh/id_rsa):
You can press enter here, saving the file to the user home (in this case, my example user is called demo).
Enter passphrase (empty for no passphrase):
It is entirely up to you whether you want to use a passphrase. Entering a passphrase does have its benefits: the security of a key, no matter how encrypted, still depends on the fact that it is not visible to anyone else. Should a passphrase-protected private key fall into an unauthorized user’s possession, they will be unable to log in to its associated accounts until they figure out the passphrase, buying the hacked user some extra time. The only downside, of having a passphrase, is having to type it in each time you use the Key Pair.
The key generation process looks like this:
ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/demo/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/demo/.ssh/id_rsa.
Your public key has been saved in /home/demo/.ssh/id_rsa.pub.
The key fingerprint is:
4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 [email protected]
The key’s randomart image is:
+–[ RSA 2048]—-+
| .oo. |
| . o.E |
| + . o |
| . = = . |
| = S = . |
| o + = + |
| . o + o . |
| . o |
The public key is now located in /home/demo/.ssh/id_rsa.pub The private key (identification) is now located in /home/demo/.ssh/id_rsa
3.Copy the Public Key
Once the key pair is generated, it’s time to place the public key on the virtual server that we want to use.
You can copy the public key into the new machine’s authorized_keys file with the ssh-copy-id command. Make sure to replace the example username and IP address below.
ssh-copy-id [email protected]
Alternatively, you can paste in the keys using SSH:
cat ~/.ssh/id_rsa.pub | ssh [email protected] “mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys”
No matter which command you chose, you should see something like:
The authenticity of host ‘184.108.40.206 (220.127.116.11)’ can’t be established.
RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘18.104.22.168’ (RSA) to the list of known hosts.
[email protected]’s password:
Now try logging into the machine, with “ssh ‘[email protected]′”, and check in:
to make sure we haven’t added extra keys that you weren’t expecting.
Now you can go ahead and log into [email protected] and you will not be prompted for a password. However, if you set a passphrase, you will be asked to enter the passphrase at that time (and whenever else you log in in the future).
4.—Disable the Password for Root Login Optional
Once you have copied your SSH keys onto your server and ensured that you can log in with the SSH keys alone, you can go ahead and restrict the root login to only be permitted via SSH keys.
In order to do this, open up the SSH config file:
sudo nano /etc/ssh/sshd_config
Within that file, find the line that includes PermitRootLogin and modify it to ensure that users can only connect with their SSH key:
Put the changes into effect:
Additional Security Steps :
Change the SSH port to something other than the commonly used ports (for eg: 1002, 2004, 2016 etc.), this step blocks hackers from scanning for open SSH ports and brute force attacks.
But if you already have a secure password for SSH ?
I would still recommend in spite of a strong password, due to the fact that, your server will considerable amount of load when thousands of bots try to scan your server and establish a connection to port 22
To Change the SSH Port for Your Linux Server
- Connect to your server via SSH
- Switch to the root user
- Run the following command:
- vi /etc/ssh/sshd_config
- Locate the following line:
- # Port 22
- Remove # and change 22 to your desired port number.
- Restart the sshd service by running the following command:
- service sshd restart
Limit SSH connections from certain IP’s
Is it really necessary ?
Again I would really recommend it, because this further eliminates bots from trying to access your SSH port, again this is only recommended if you are having a static IP, if you don’t then it may not be worth it.
But this is how you do it anyways
Add the following IPTables rule to your Input interface
-A INPUT -p tcp -m tcp -s my ip/32 –dport ssh port -j ACCEPT
Replace ssh port my IP and SSH port with your static IP and your SSH port respectively.
Once you have implemented the above security measures it will be a good idea to test your server security with and online penetration testing provider like http://pentest-tools.com, they have some free tests that will check for basic loopholes in your server.
This post is by no means an entire list of server hardening techniques, but this will definitely help you to keep a huge majority of hackers at bay, often times you might be wondering if all this is necessary and would I be hacked ? or why they want to hack my server, when there are millions of other websites that they can hack ?
Trust me, there are million of bots everyday scanning for server vulnerabilities in order to inject malware or phishing links or to make your server participate in the bot network which spans across continents to partake in bigger DDOS attacks even without your knowledge.
If you searching the market for a reliable cloud server that implements these security features for you and manages it an affordable price then look no further than the cloud server offerings from Olexor Technologies, their prices start from 40$ for 2CPU Cores, 2GB RAM, 30GB SSD, 3TB Inbound bandwidth, Hosted at World-class Data Centers, additionally they provide the above security implementations and management all included in the price
Please leave a comment below to share additional tips on cloud server security.