• Hey Guest, we're evolving the future of TeaSpeak.
    You're invited to join the discussion here!

Server How to add some extra security to your VPS?

MiguelETG

Member
How to add some extra security to your VPS?

After helping some users with some server installations and issues I figured out that users don't use to configure basic security tools at the VPS.

Most of the VPS users are using are super weak configurations against basic cyber-attacks that could be compromised by script kiddies.


You don't know if are a target? Execute:
sudo grep "Failed password" /var/log/auth.log
Do you see tons of login attempts from unknown IPs? Your server is a target ;)

Warning: Some of this steps could make your server inaccessible if they are not properly executed and tested, modify this parameters under your own responsibility (tested at Debian 9,10,11 & Ubuntu 20.04.4)


1.- Add basic security to the login of the server:

Most of the servers use SSH login (if you still use telnet to access your server, install SSH and disable telnet).
SSH (Secure Shell) its nice because the packets are encrypted, but it stops being nice when a "hacker" obtain your credentials.
Here I will add some tips that can help hardening your SSH server:


- Create a login username (for example: te45sp34k) with sudo permissions by executing as root:
adduser te45sp34k
passwd te45sp34k
(introduce the password you want to use to login into your server, I recommend generating one with https://passwordsgenerator.net/)
echo 'te45sp34k ALL=(ALL) ALL' >> /etc/sudoers

- Open and edit your ssh config file by executing: "nano /etc/ssh/sshd_config"

- Modify the default port by changing "Port 22" to "Port 40022" (for example)
--> Execute "/etc/init.d/sshd restart" and try to login as usual but modifying the port to 40022 instead of 22.
(If you have a perimeter firewall, hoster firewall, you must add the TCP port 40022 to the allow list)

- Disable root login by changing "#PermitRootLogin yes" to "PermitRootLogin no"
--> Again execute "/etc/init.d/sshd restart" and try to login as root via the new port (40022) - Spoiler: you shouldn't be available.

- Only allow the new user to login "AllowUsers te45sp34k"
--> Again execute "/etc/init.d/sshd restart" and try to login as the default user (ex: "debian", you shouldn't be available) and with the new user created, via the new port (40022).

OPTIONAL: you can add second factor to your ssh login by using Google, PingID or other tools (I personally recommend this, it adds an extra layer of security) - Here you can find how to enable 2nd-Factor with google: https://goteleport.com/blog/ssh-2fa-tutorial/
COMMENTS: due this tutorial is made for basic users, I didn't got into RSA keys (it could be more "secure" but sometimes harder for the users to migrate the keys, revoke them or renew them in case they have to do so).


2.- Prevent bruteforce attacks:

It's really common that script kiddies try to use automatized tools to get server credentials, most of them are dictionary based (this means they have a huge file of random passwords and they try one by one till they find the password and log into the server).
In this case we will configure fail2ban tool.


- How to install fail2ban, as root execute:
apt update
apt install fail2ban
systemctl start fail2ban
systemctl enable fail2ban
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local


- Modify some values:
nano /etc/fail2ban/jail.local

- Modify at the file:
From "bantime = 600" to "bantime = 86400"
From "maxretry = 5" to "maxretry = 3"
From
[ssh]
enabled = true
port = ssh

to
[ssh]
enabled = true
port = 40022


- Restart fail2ban to apply the changes:
systemctl restart fail2ban

- You can check the logs by executing "less /var/log/fail2ban.log" or a summary by executing "fail2ban-client status sshd"

RECOMMENDED: add an exception so you can't get banned in case you type wrong the password "ignoreip = YOUR_HOME_PUBLIC_IP or YOUR_HOME_PUBLIC_DDNS"


I leave the thread open so everyone can add additional tips.

Hopefully this help some users, soon, when I get some time, I will try to upload some other "tutorials" to help users hardening their servers.

This information is public, do no try to sell it to users, if some user sold you this information, kindly notify it to me.
 
Last edited:

BIOS

TeaSpeak Team
Staff member
TeaTeam
Premium User
You forgot modsecurity for websites. If they installed on the vps. ;)
 

Eyup

Well-known member
For TeaSpeak, I can offer changing the query port and iptables codes;
This iptables codes will not enable to anyone who tries to enter server query except specific IP adress that you choose;
**CHANGE THE YOURIP WITH YOUR PUBLIC IP ADDRESS**
Code:
iptables -I INPUT -p tcp --dport 10101 -j DROP
iptables -I INPUT -p udp --dport 10101 -j DROP
iptables -I INPUT -p tcp --dport 10101 -s YOURIP -j ACCEPT
 
Last edited:

BIOS

TeaSpeak Team
Staff member
TeaTeam
Premium User
For TeaSpeak, I can offer changing the query port and iptables codes;
This iptables codes will not enable to anyone who tries to enter server query except specific IP adress that you choose;
**CHANGE THE YOURIP WITH YOUR PUBLIC IP ADDRESS**
Code:
iptables -I INPUT -p tcp --dport 10011 -j DROP
iptables -I INPUT -p udp --dport 10011 -j DROP
iptables -I INPUT -p tcp --dport 10011 -s YOURIP -j ACCEPT
Problem is most ppls have an dynamic IP Adress from there isp. So he put out the power cable, insert them and got an new ip.
 

MiguelETG

Member
Problem is most ppls have an dynamic IP Adress from there isp. So he put out the power cable, insert them and got an new ip.
There is a solution for this, there are some free tools like no-ip, dyndns and duckdns.
Some ISP routers allow you to configure such things, so in case your public IP change, the subdomain will be updated and point to the new IP address you have at your house.
So I might use a rule like:
-I INPUT -p tcp --dport 10101 -s YOUR_DYN_DNS -j ACCEPT