8,500 Botnet Attacks in 24 Hours: The Risk of an Open SSH Port

Introduction

I expected exposing my home lab to the internet would invite some unwanted attention, but I wasn’t quite prepared for the overwhelming flood of automated bots and scanners out there. In just 24 hours, my private server was hit with over 8,500 attacks, an onslaught of brute force attempts from bots and hackers around the globe. This obviously left me with a bunch of unanswered questions. Why does this happen? How did these attackers find me so quickly? And most importantly – how can I stop it from happening again? 

In this post, I’m going to break down exactly what happened, how automated botnets work, why they do it, and the crucial lessons I learned about securing a server in a hostile digital world. If you’ve ever wondered what happens when your server goes live on the internet, read on – because the results might surprise you.

My Home Lab Setup

Before we dive into the details of what happened, let’s quickly look at my setup. I have a small home lab running a private server, which primarily hosts an Apache web server and a MySQL database. For this experiment I also set up Wazuh, an open-source SIEM (Security Information and Event Management) tool. Think of it as your personal security watchdog – monitoring, analyzing, and detecting threats just like any other SIEM. The only difference? Wazuh is completely free compared to the other players on the market. 

I use this lab to experiment with different cybersecurity and pentesting tools, making it a very good environment to learn and have fun. Regardless of whether you are looking to get started with cybersecurity or if you are already a seasoned expert, I can highly recommend setting up your own homelab if you haven’t already. But enough about the setup – let’s get into the real action.

Exposing my Server to the Internet: The Risks of SSH

You might be thinking, “Isn’t your home lab already exposed to the internet if it’s running a web server?” And yes, you’d be absolutely right. But for this experiment, I took it a step further by opening up port 22 – the default port for SSH. As you’ll soon see, that decision comes with some serious risks, if you haven’t configured SSH properly.

SSH, or Secure Shell, is a protocol used to securely access remote servers. SSH is like a private tunnel between you and your server that allows you to log in and run commands. It’s pretty essential, but there’s a catch. Because SSH gives you such deep control, it’s also a huge target for attackers. 

Hackers love SSH because, if they can break in, they can often gain full access to your system. And if you’ve left your SSH configuration in its default state – like keeping port 22 open with no or very simple passwords, you might as well be sending out invitations.

Automated bots constantly scan the internet for exposed SSH ports, looking to brute-force their way in by guessing common usernames and passwords. But more on that later. 

Simply put, if your server is out there with its virtual front door wide open on port 22, you’re going to get a lot of unwelcome visitors.

What Happened When I Left SSH Port 22 Open for 24 Hours

Alright, enough beating around the bush – let’s dive into what really happened. Just minutes after opening port 22, the attacks started to roll in. As we’ve touched on earlier, this isn’t the result of a dedicated individual patiently waiting for me or others to expose our SSH port.

No, it’s all thanks to the vast network of automated bots and scanners relentlessly sweeping the internet for vulnerabilities.

Let’s have a look at the total amount of alerts that I received over the course of the 24 hours.

Yes thats right, a whopping amount of 8585 alerts in 24 hours. That’s 357.71 attacks per hour and 5.96 attacks per minute. Crazy right?

You might look at these numbers and wonder why 8,282 plus 9 doesn’t equal 8,585. The discrepancy isn’t because Wazuh can’t do basic math; rather, it’s due to additional alerts that aren’t classified as either authentication failures or successes.

You might also be curious whether those nine attacks were successful. Unfortunately, I must disappoint you again – none of those attempts succeeded. The nine successful authentication alerts simply reflect my own actions, such as running a sudo command or similar administrative tasks on my server.

Now, let’s have a deeper look into the details of what happened. 

Time Distribution of the Attacks

The chart below clearly illustrates how the attacks unfolded over the course of 24 hours. As you can see, the attacks weren’t isolated events; they were persistent, with steady activity throughout the day.

Interestingly, the graph shows a few intense peaks – one around 9 PM, another major spike just before 9 AM the next day and then a final one at around 2 PM. These high-activity periods suggest times when automated bots were most aggressive, but why? The spikes in attack activity could be due to several factors, mostly tied to how automated attack bots and scripts operate.

One reason could be due to a botnet activity cycle. Botnets often operate in cycles, hitting different targets at specific times. 

Another reason could be because of the way the attack scripts are scheduled. Automated attack scripts are sometimes set to run at specific times of the day, either based on time zones or when the attacker assumes targets might be more vulnerable (for instance, when admins might not be actively monitoring their systems).

What the real reason is, is not easy to guess, but that’s not really the point either. The point is, just how important it is to configure SSH properly, or you’ll be in for quite an unpleasant surprise.

Attack Distribution

A closer look at the attacks targeting my server reveals a distinct pattern: the overwhelming majority were centered around Password Guessing, SSH, and Brute Force attempts. As illustrated in the diagram below, Password Guessing dominated the landscape, accounting for nearly 60% of all scans. 

Now that we have a pretty good understanding of the frequency and types of attacks that are being executed, it’s time to take a closer look at one of the logs. This is where the real story unfolds!

Check out the log entry in below. It reveals some fascinating details: we’ve got the attacker’s IP address, the geolocation of the attempt, and the specifics of the attack itself. Let’s break it down!

In this case, the IP address 4.17.226.146 attempted to gain access to my server via SSH using the username “admin.” Luckily, I don’t have a user account named “admin”! So, as you can imagine, this attempt ended in a spectacular failure. This incident highlights a common tactic among attackers – trying to exploit default usernames and passwords.

By digging a bit deeper, we can confirm on VirusTotal that the IP is heavily flagged, confirming that this IP is indeed involved in some sketchy activity.

Where Do the Attacks Originate From

Curious about where these attacks are coming from? Well, maybe you have already guessed it. As illustrated in Figure 6, the sources of these scans span multiple countries, proving that the threat landscape is truly global. This wide-reaching activity highlights the staggering scale of botnets operating worldwide. It’s a vivid reminder that cyber threats can emerge from virtually anywhere.

Why Do Attackers Launch These Attacks?

Attackers engage in these opportunistic attacks for several reasons, primarily driven by profit, disruption, or simply the thrill of the challenge. 

• Financial Gain: Cybercriminals exploit vulnerabilities to make money through ransomware, data theft, or selling access to compromised systems.
• Botnet Recruitment: Attackers might try to recruit devices into their malicious activities. Not gonna happen on my watch!
• Data Theft: They seek sensitive information, including personal and financial data, from any target, regardless of its size.
• Testing Ground: Some hackers are motivated by the challenge of breaching systems, using small targets to test and refine their skills.
• Political or Ideological Reasons: Hacktivists may target servers to promote a cause, disrupt services, or expose perceived injustices.

In reality there could be a bunch of reasons for why some people launch these attacks. However, it’s most likely due to one of the reasons mentioned above.

How to Secure SSH and Reduce Attack Risk

Even though SSH can be an entry point for attackers, there is still good news! The good news is that we can still enjoy the advantages of SSH without letting a wave of unwanted attackers breach our defenses! Let’s take a look at how.

• Change the Default Port:
  Switch your SSH service from the standard port 22 to a non-standard one. This simple trick can confuse those pesky bots and reduce random attacks!
• Use SSH Keys Instead of Passwords:
  Ditch the old-school passwords and embrace SSH key-based authentication. It’s like having a secret handshake that’s much harder for attackers to crack!
• Limit Access with Firewalls:
  By allowing only specific IP addresses, you keep unwanted guests at bay! 
• Install Tools Like Fail2Ban:
  Equip your server with Fail2Ban, the ultimate watchdog that blocks IPs after repeated failed login attempts. Consider it your digital security guard, ready to kick out troublemakers!
• Consider Using Geo-blocking:
  If most of the attacks are coming from specific countries, why not shut the door on them? Block access from those regions to keep your server safe from unwanted visitors.

Conclusion

In the wild world of the internet, the scale of attacks can be mind-boggling, with botnets lurking around every digital corner, ready to pounce on any vulnerability they find. While I may have fended off over 8,500 attacks and kept my server safe from unwanted guests, it’s still an important reminder that proper configuration is essential for any online setup – big or small. Just because no one successfully accessed my server doesn’t mean we can let our guard down!

So, take these lessons to heart: secure your SSH, keep those bots at bay, and stay proactive in protecting your digital fortress. Happy securing!