Bitcoin Forum
November 06, 2026, 07:35:29 PM *
News: Latest Bitcoin Core release: 32.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Rented a server for crypto? The first 10 min that decide whether it gets hacked  (Read 10 times)
sauberr (OP)
Newbie
*
Offline

Activity: 2
Merit: 0


View Profile WWW
Today at 06:19:32 AM
 #1

A fresh rented server is found by scanners within minutes, and most "my server got hacked" stories start with the same few mistakes. These are the steps I do on every new Ubuntu server before anything else. Disclosure: I run Neckrez, a reseller of cloud servers that takes crypto, so I see these problems from the provider side. The steps apply to any VPS.

1. Do not keep keys or seeds on it
A rented server is somebody else's hardware. Never store a wallet seed phrase or a private key you cannot afford to lose on it. A node or a bot should hold only the minimum it needs (a trading API key without withdrawal rights, for example).

2. Use an SSH key and switch passwords off
Log in as root once, create a normal user and add your key:
Code:
adduser deploy
usermod -aG sudo deploy
On your own computer: ssh-copy-id deploy@SERVER_IP . Then in /etc/ssh/sshd_config set:
Code:
PermitRootLogin no
PasswordAuthentication no
and run systemctl restart ssh. Keep the first session open and test the new login in a second window before you close anything.

3. Turn on a firewall, allow only what you use
Code:
ufw default deny incoming
ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable
Allow OpenSSH before enable, or you lock yourself out.

4. Never expose a database to the internet
Redis, MongoDB, Elasticsearch, PostgreSQL and MySQL should listen on 127.0.0.1 only. Open ones are found by scanners within hours and used to attack other people, which gets the server (and your account) shut down. If you need remote access, restrict it by IP or use an SSH tunnel.

5. Update automatically
Code:
apt update && apt upgrade -y
apt install -y unattended-upgrades fail2ban
unattended-upgrades installs security updates by itself; fail2ban bans addresses that keep guessing passwords.

6. Keep your own backups
A provider snapshot is not a backup strategy. Copy what matters to another place regularly, and test that you can restore it.

7. Watch what the server does
Unexpected high CPU or a lot of outgoing traffic usually means someone is using your server. Check with htop and the provider's graphs now and then. Abuse reports (spam, scanning, torrents of pirated material) can get a server suspended, and the owner is responsible for what runs on it.

A note from the provider side
On Neckrez we look from the outside for the classic open database and admin ports on customers' servers and warn the owner in the support chat. The server itself is never touched. Whatever service you use, close what you do not use before anyone has to tell you.

If you want to try it: https://neckrez.tech (email sign-up, crypto payments, hourly billing, so a test costs cents). Terms: https://neckrez.tech/legal/terms . Better tips are welcome in this thread.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!