/posts/2024-12-31-incident-report2024/12/31

Journey to the DMZ

2024/12/31
Bruteforce attack? In the current year?
SSHBruteforceNetworkingSecurity

Incident Summary

  • Noticed speed throttled around 24/12/30 @ 23:00
  • Designated local media server to be DMZ host
  • Probed initially around 24/12/31 @ 23:52 by SSH Bot
  • First IP Address 216.107.162.242, more logged from different locations
  • Implemented Fail2Ban, Public Key-based Authentication
  • Resume Normal Operation 25/01/03

House Keeping

I was spending time with my friend when the new year was around the corner.

Media Server Uptime

My media server was suddenly blasting the fans on max RPM, so I checked processes using htop, and found multiple sshd process from random public IPs.

Multiple Login Attempts

these seemed to be registered on Abuse IP DB, which is a database of reported IP addresses that has record of abusive activity.

I initially had no idea what was happening, but once I looked up the IP, I was able to put together what was going on.

It wasn't very effective.

It did manage to slow down the server, a form of Denial of Service attack. Other than that, nothing of value was lost, or stolen, or exposed.

What to do...

Now I had unwanted guests knocking on my server, I had a few ways to deal with this problem.

  1. Ban the "guest" after they make n amount of mistakes - Max Attempt (Fail2Ban)
  2. Only allow "guests" with a pre-authorized pass - SSH Key based auth

Both sounds like a good idea, but at first sight, fail2ban seemed enough.

Fail2Ban

Available on Debian repo, simply had to install it using apt

$ sudo apt update

$ sudo apt install fail2ban

then copied /etc/fail2ban/jail.conf to /etc/fail2ban/jail.local and went through the file and enabled options such as ban time.

Then I restarted the service using systemctl, then left the system on overnight to see how it would perform.

I woke up the next morning to max RPM fans on my server, so I needed a better solution.

SSH Key Based Authentication

Fail2Ban even has a disclaimer on their website stating that they're not a silver bullet solution.

SSH Key isn't either, but these two options are enough to fulfill my needs for now. Simply had to use #ssh-copy-id user@prometheus from my terminal to copy my public key to the server.

Then I logged into the the server, disabled password based authentication by editing:

/etc/ssh/sshd_config

/etc/ssh/sshd_config

Restart the SSH Service using systemctl and then finally everything went back to normal.

Learning Points

  1. Key based Authentication is good
  2. Key management is a different problem
  3. Use port forward, instead of exposing all ports