Hi, my name is Wesker (aka Access Denied), and I'm the owner of a cheap and fast Romanian VPS. Kind of a good deal, but?
Despite my Network Rate is 125 MB/s, I often faced network resource loss, failures, SSH lockouts etc. I'm able to download 1 GB of data within seconds from that server, so why I faced all these problems? If you are controlling a WAN-exposed home server or an abroad VPS server, and you are facing my same problems, the reason is the following:
Chinese threat actors is the reason, and that's all. But how they do and why? These guys are targeting IoT exposed servers. For example, I found in my Apache logs traces of the well known Censys scanner, which performed an unauthorized scan on HTTP 80, and obviously, port 22 (SSHD). The result of these scans become public, and shared across other IoTs like ZoomEye, or Shodan. Chinese threat actors perform a mass-bulk download of IP addresses from these IoTs, then they look for known vulnerabilities on Apache 80/443, or just bruteforcing your SSH, to gain the complete control of your server. How to prevent that from happening?
Step 1. If you are using Apache just for sporadic/occasional tasks, just don't forgot it opened. Type "systemctl status service apache2" to see if the service it's active or not, then just type in "service apache2 stop" to shut it down. Apache is made in a way you have it automatically running upon system restart, so your server may expose it without your knowledge.
Step 2. If you truly need Apache to costantly run, ensure it's always updated to the latest version, do never use weak configurations, such as unsafe cgi scripts, and moreover, if you are incorporating a SQL database, watch out for SQL flaws, that could lead to complete database take over, and data leakage.
The most important part of a VPS server is SSH, since this service is "the door" to enter the system. Chinese cybercriminals are mass-bruteforcing this service, aggressively. By opening the "/var/log/auth.log", we can find all the attempts to gain access on SSH. My "auth.log" file presented thousands of failed username/pass combination from chinese IP addresses. Thank God, all these attempts will always fail (unless you are using weak login credential), but the real problem is, how truly stressful is for the Network Resources to tank all these tragicomic login requests?
Step 3. All we need to do, is to monitor the network for SSH requests. By typing "netstat -a" on our terminal, we can see all IP addresses who are connected to SSH, or probing it for login attempts. After recognizing your own IP address istance in the netstat table, all others IP addresses are obviously bruteforcers. Surf to "etc/hosts.deny", then vim the hosts.deny file and copy/paste the IP address value of the attacker, in this format "sshd : ip_of_the_attacker", save, and the IP address is blocked. Each criminal IP must be copy/pasted into the "hosts.deny" file individually. Another technique, which is risky, is to prevent all IP addresses from contacting the SSH service except your, which may lock you out whatever your home-network IP is dynamic and not static. After blocking each bruteforcer's IP, open an account on www.abuseipdb.com, a webservice widely known among the white hat/grey hat community, and report the bruteforcer IP, like in this example, "https://www.abuseipdb.com/check/36.110.138.149" where 36.110.138.149 was reported 740 times for unauthorized bruteforce login attempts against SSH, from 348 distinct sources. Reporting these trolls in this blacklist will consume their web-reputation over time, thus popular websites like Google will prevent them from crawling the Internet for scraping data, IoT search engines will prevent them from accessing sensitive data, email spam filters will filter out these IPs whatever they will carry phishing artifacts, and eventually, popular EDRs automatically recognizing their IP as malicious.
Despite my Network Rate is 125 MB/s, I often faced network resource loss, failures, SSH lockouts etc. I'm able to download 1 GB of data within seconds from that server, so why I faced all these problems? If you are controlling a WAN-exposed home server or an abroad VPS server, and you are facing my same problems, the reason is the following:
Chinese threat actors is the reason, and that's all. But how they do and why? These guys are targeting IoT exposed servers. For example, I found in my Apache logs traces of the well known Censys scanner, which performed an unauthorized scan on HTTP 80, and obviously, port 22 (SSHD). The result of these scans become public, and shared across other IoTs like ZoomEye, or Shodan. Chinese threat actors perform a mass-bulk download of IP addresses from these IoTs, then they look for known vulnerabilities on Apache 80/443, or just bruteforcing your SSH, to gain the complete control of your server. How to prevent that from happening?
Step 1. If you are using Apache just for sporadic/occasional tasks, just don't forgot it opened. Type "systemctl status service apache2" to see if the service it's active or not, then just type in "service apache2 stop" to shut it down. Apache is made in a way you have it automatically running upon system restart, so your server may expose it without your knowledge.
Step 2. If you truly need Apache to costantly run, ensure it's always updated to the latest version, do never use weak configurations, such as unsafe cgi scripts, and moreover, if you are incorporating a SQL database, watch out for SQL flaws, that could lead to complete database take over, and data leakage.
The most important part of a VPS server is SSH, since this service is "the door" to enter the system. Chinese cybercriminals are mass-bruteforcing this service, aggressively. By opening the "/var/log/auth.log", we can find all the attempts to gain access on SSH. My "auth.log" file presented thousands of failed username/pass combination from chinese IP addresses. Thank God, all these attempts will always fail (unless you are using weak login credential), but the real problem is, how truly stressful is for the Network Resources to tank all these tragicomic login requests?
Step 3. All we need to do, is to monitor the network for SSH requests. By typing "netstat -a" on our terminal, we can see all IP addresses who are connected to SSH, or probing it for login attempts. After recognizing your own IP address istance in the netstat table, all others IP addresses are obviously bruteforcers. Surf to "etc/hosts.deny", then vim the hosts.deny file and copy/paste the IP address value of the attacker, in this format "sshd : ip_of_the_attacker", save, and the IP address is blocked. Each criminal IP must be copy/pasted into the "hosts.deny" file individually. Another technique, which is risky, is to prevent all IP addresses from contacting the SSH service except your, which may lock you out whatever your home-network IP is dynamic and not static. After blocking each bruteforcer's IP, open an account on www.abuseipdb.com, a webservice widely known among the white hat/grey hat community, and report the bruteforcer IP, like in this example, "https://www.abuseipdb.com/check/36.110.138.149" where 36.110.138.149 was reported 740 times for unauthorized bruteforce login attempts against SSH, from 348 distinct sources. Reporting these trolls in this blacklist will consume their web-reputation over time, thus popular websites like Google will prevent them from crawling the Internet for scraping data, IoT search engines will prevent them from accessing sensitive data, email spam filters will filter out these IPs whatever they will carry phishing artifacts, and eventually, popular EDRs automatically recognizing their IP as malicious.
