How to secure a virtual server from hacker attacks?

Question

linux

UPD: the hoster replied that it turns out that someone brute something from my server (in my opinion, their network).
The question is, how is this even possible? They refuse to unlock the server.
It seems to me that it was some kind of lure, a server 2 cpu, 2 ram for 3 euros per month, in order to block it under a stupid pretext a couple of days after the purchase.

-------------------------------------------------
Recently purchased a virtual server, never before did not use it, only regular hosting.

Today the hoster sent me a message with logs that someone brute my server, so they stopped it for security reasons.

Message with logs

An attempt to brute-force account passwords over SSH/FTP by a machine in your domain or in your network has been detected. Attached are the host who attacks and time / date of activity. Please take the necessary action(s) to stop this activity immediately. If you have any questions please reply to this email.

Host of attacker: xx.xx.xxx.xxx => xx.xx.xxx.xxx => xx.xx.xxx.xxx
Responsible email contacts: [email protected]
Attacked hosts in our Network: 77.75.251.232, 178.250.9.139, 37.228.156.166, 85.158.183.41, 178.250.15.226, 178.250.9.27

Logfile entries (time is CE(S)T):

Fri Jun 19 15:00:40 2020: user: root service: ssh target: 37.228.156.166 source: xx.xx.xxx.xxx
Fri Jun 19 15:00:26 2020: user: root service: ssh target: 178.250.9.139 source: xx.xx.xxx.xxx
Fri Jun 19 14:58:24 2020: user: root service: ssh target: 178.250.15.226 source: xx.xx.xxx.xxx
Fri Jun 19 14:58:20 2020: user: root service: ssh target: 77.75.251.232 source: xx.xx.xxx.xxx
Fri Jun 19 14:58:19 2020: user: root service: ssh target: 85.158.183.41 source: xx.xx.xxx.xxx
Fri Jun 19 14:57:05 2020: user: root service: ssh target: 178.250.9.27 source: xx.xx.xxx.xxx
Fri Jun 19 14:56:20 2020: user: test10 service: ssh target: 37.228.156.166 source: xx.xx.xxx.xxx
Fri Jun 19 14:56:06 2020: user: test10 service: ssh target: 178.250.9.139 source: xx.xx.xxx.xxx
Fri Jun 19 14:54:19 2020: user: test10 service: ssh target: 85.158.183.41 source: xx.xx.xxx.xxx
Fri Jun 19 14:54:14 2020: user: test10 service: ssh target: 178.250.15.226 source: xx.xx.xxx.xxx
Fri Jun 19 14:54:10 2020: user: test10 service: ssh target: 77.75.251.232 source: xx.xx.xxx.xxx
Fri Jun 19 14:52:55 2020: user: test10 service: ssh target: 178.250.9.27 source: xx.xx.xxx.xxx
Fri Jun 19 14:52:10 2020: user: ubuntu service: ssh target: 37.228.156.166 source: xx.xx.xxx.xxx
Fri Jun 19 14:52:06 2020: user: ubuntu service: ssh target: 178.250.9.139 source: xx.xx.xxx.xxx
Fri Jun 19 14:50:19 2020: user: ubuntu service: ssh target: 85.158.183.41 source: xx.xx.xxx.xxx
Fri Jun 19 14:50:14 2020: user: ubuntu service: ssh target: 178.250.15.226 source: xx.xx.xxx.xxx
Fri Jun 19 14:50:10 2020: user: ubuntu service: ssh target: 77.75.251.232 source: xx.xx.xxx.xxx
Fri Jun 19 14:48:55 2020: user: ubuntu service: ssh target: 178.250.9.27 source: xx.xx.xxx.xxx
Fri Jun 19 14:48:10 2020: user: test2 service: ssh target: 37.228.156.166 source: xx.xx.xxx.xxx
Fri Jun 19 14:47:56 2020: user: test2 service: ssh target: 178.250.9.139 source: xx.xx.xxx.xxx
Fri Jun 19 14:46:14 2020: user: test2 service: ssh target: 178.250.15.226 source: xx.xx.xxx.xxx
Fri Jun 19 14:46:10 2020: user: test2 service: ssh target: 77.75.251.232 source: xx.xx.xxx.xxx
Fri Jun 19 14:46:08 2020: user: test2 service: ssh target: 85.158.183.41 source: xx.xx.xxx.xxx
Fri Jun 19 14:44:55 2020: user: test2 service: ssh target: 178.250.9.27 source: xx.xx.xxx.xxx
Fri Jun 19 14:44:00 2020: user: julio service: ssh target: 37.228.156.166 source: xx.xx.xxx.xxx
Fri Jun 19 14:43:46 2020: user: julio service: ssh target: 178.250.9.139 source: xx.xx.xxx.xxx
Fri Jun 19 14:41:54 2020: user: julio service: ssh target: 178.250.15.226 source: xx.xx.xxx.xxx
Fri Jun 19 14:41:50 2020: user: julio service: ssh target: 77.75.251.232 source: xx.xx.xxx.xxx
Fri Jun 19 14:41:48 2020: user: julio service: ssh target: 85.158.183.41 source: xx.xx.xxx.xxx
Fri Jun 19 14:40:25 2020: user: julio service: ssh target: 178.250.9.27 source: xx.xx.xxx.xxx
Fri Jun 19 14:39:30 2020: user: root service: ssh target: 37.228.156.166 source: xx.xx.xxx.xxx
Fri Jun 19 14:39:06 2020: user: root service: ssh target: 178.250.9.139 source: xx.xx.xxx.xxx
Fri Jun 19 14:36:58 2020: user: root service: ssh target: 85.158.183.41 source: xx.xx.xxx.xxx
Fri Jun 19 14:36:54 2020: user: root service: ssh target: 178.250.15.226 source: xx.xx.xxx.xxx
Fri Jun 19 14:36:50 2020: user: root service: ssh target: 77.75.251.232 source: xx.xx.xxx.xxx
Fri Jun 19 14:35:15 2020: user: root service: ssh target: 178.250.9.27 source: xx.xx.xxx.xxx
Fri Jun 19 13:45:20 2020: user: root service: ssh target: 37.228.156.166 source: xx.xx.xxx.xxx
Fri Jun 19 13:36:44 2020: user: root service: ssh target: 178.250.15.226 source: xx.xx.xxx.xxx
Fri Jun 19 13:36:38 2020: user: root service: ssh target: 85.158.183.41 source: xx.xx.xxx.xxx
Fri Jun 19 13:36:30 2020: user: root service: ssh target: 77.75.251.232 source: xx.xx.xxx.xxx
Fri Jun 19 13:30:55 2020: user: root service: ssh target: 178.250.9.27 source: xx.xx.xxx.xxx

I would like to ask for advice, how can I protect myself from such attacks?
I understand that this is the most lame attack, where it scans addresses and starts brute force, but Linux knowledge does not allow me to protect myself from this =(

A little about the machine:

• The site is accessible from the Internet by IP address.
  
• Connection via SSH ssh [email protected](by login/password, without keys)
  
• There are domains by which you can also connect ssh [email protected](by login / password, without keys)
  
• Only 1 IP address per machine
  

Is it possible to somehow limit the connection via SSH through the IP of the machine and leave one of the sets of domains specifically for which it will be possible to connect?
Can I restrict the connection by password for root so that the hoster does not stop the server for me, and with it all my projects / sites?

And in general, what are the most basic things to do to secure the server?

Answer 1

Already on the first lines of your post, it seemed to me that you came across an unscrupulous hoster. Twice since 2006 I came across a similar approach. When you close the ports and current holes, there will be further claims for excessive load on the server - pay extra and switch to a more expensive tariff. Switch to a more expensive tariff - there will be copyright claims for some pictures on the site. Etc. And all this will be accompanied by a constant spontaneous shutdown of the server. Remember - a normal host will never turn off your server without prior notification by e-mail with explanations (work in the data center, etc.). The main parameter of a good hosting or server is its uptime (continuous working time) - and normal hosters strive to keep it at 100%. Downtime - lost customer benefit, often measured in real money. It is better to immediately request a moneyback from a hoster that spontaneously disconnects your servers without warning at least by e-mail and run away from it. Well, more specifically on your question - if you have such problems after two days of use, then this is also the fault of the hoster: why the linux distribution kit provided by him for installation has such a poor initial configuration that it has a hacker Trojan installed out of the box - bruteforcer? I am 200% sure that the hoster himself planted this rubbish on you, for the reasons indicated above. Yes, it is possible that there was no attack - most likely a pre-prepared letter with fake logs. Caught by scammers, a common occurrence. There are only three real reasons that I know of why your server can spontaneously shut down (of course, if you yourself did not violate the law by hacking, or distribution of torrents from the server): an accident in the data center (or a hard DDoS of the entire subnet of the data center), DMCA (complaint about copyright infringement), as well as abnormal traffic consumption by your server (significantly exceeding all allowable limits, for example, monthly daily traffic). In other cases, any spontaneous shutdown of the server can be regarded as hoster dishonesty or fraud.

Answer 2

1. Change default port
   
2. Key-only authorization
   
3. Make a stub when connecting to a web server by IP
   

Answer 3

in addition to the above, I would also advise you to screw port-knocking .
the little thing is somewhat long in setting up, but it will just do not care about brute force. ports are just closed :)

Answer 4

Close SSH from the internet. Everything else (well, maybe except for knocking) is homeopathy.

Answer 5

If it is your server that has brute-forced the outside world, then first of all ask the hoster to close the possibility of outgoing connections to your server on TCP:22.
In general, it is strange that the hoster closed the entire server, and not outgoing calls.
After that, see what you have running there. It seems that someone hooked a resident process, constantly hanging in memory and hammering neighbors with brute force requests. Well, look at what processes open TCP connections.
Theoretically, a hacker may not launch an additional process, but add his own piece of code, which is already brute force, to a normal program that should work all the time.
Next, think about what outgoing TCP ports you generally need. Something seems to me - almost none. Close unnecessary ports - it will be safer; you can close it both by the forces of the hoster and by the forces of your server; however, when hacking the server - the hacker can disable the port blocking done by your server; but this is only if he gets root privileges.
Ideally, the hoster should provide a Web interface in which the client can open the ports he needs and close the unnecessary ones. By default - all ports typical for hackers should be. closed.

Answer 6

by login/password, without keys

User root and password 123 or something like that?

Is it possible to somehow limit the connection via SSH through the IP of the machine and leave one of the sets of domains specifically for which it will be possible to connect?

Can.
On the firewall, you can specify addresses from which you can connect, use a normal password to connect, or rather a key, configure port knocking

Answer 7

Change the hoster to a conscientious
one Xelent now has a 3 month free period, so it's time