DEV Community

Cover image for Detecting and Neutralizing a Brute-Force Attack: A Hands-On Lab with Splunk, Hydra, and UFW
J. Alexander
J. Alexander

Posted on

Detecting and Neutralizing a Brute-Force Attack: A Hands-On Lab with Splunk, Hydra, and UFW

#cybersecurity #splunk #linuxsecurity #cloudsecurity

Detecting and Neutralizing a Brute-Force Attack: A Hands-On Lab with Splunk, Hydra, and UFW

Introduction
In modern cybersecurity, visibility is the difference between a minor incident and a total breach. For my latest project, I built a "Lab Environment" to simulate a real-world brute-force attack on a Linux server. My goal was to experience the full lifecycle of an incident: from the initial vulnerability to the final remediation.

The Architecture

  • Victim Server: An Ubuntu instance hosted on Google Cloud Platform (GCP).
  • Attacker Hub: A Kali Linux/Ubuntu instance used to launch the simulation.
  • SIEM: Splunk Enterprise, ingesting logs via the Splunk Universal Forwarder.

Step 1: Creating the Vulnerability (Hardening in Reverse)
Most secure servers use SSH keys, but to simulate a password-guessing attack, I intentionally enabled PasswordAuthentication in the sshd_config.
Lesson Learned: Within 10 minutes of opening the server, real-world bots from global IPs began hitting the server—reminding me how quickly "Internet Background Noise" finds unprotected targets.

Step 2: Launching the Attack (Hydra)
Using THC-Hydra, I launched a dictionary attack against the ubuntu user.
hydra -t 4 -V -f -l ubuntu -P /tmp/passlist.txt ssh://[Victim_IP]
I watched in real-time as Hydra cycled through my password list, generating dozens of "Failed password" attempts.

Step 3: Detection with Splunk (SIEM)
This was the core of the lab. I configured the Splunk Forwarder to monitor /var/log/auth.log. Using the following SPL query, I was able to visualize the attack:

index=linux_os_logs "Failed password"
| rex field=_raw "for (?<user_targeted>\S+) from (?<src_ip>\d+\.\d+\.\d+\.\d+)"
| stats count as failed_attempts values(user_targeted) as targeted_users by src_ip
| where failed_attempts > 5
| sort - failed_attempts
Enter fullscreen mode Exit fullscreen mode

The results were clear: My Attacker IP was flagged immediately, alongside several other malicious bots attempting to access the root account.

Step 4: Response and Remediation (UFW)
Detection is useless without action. I implemented two layers of defense:

  1. Network Layer: Used UFW (Uncomplicated Firewall) to drop all packets from the identified IPs. sudo ufw insert 1 deny from [Attacker_IP] to any
  2. Service Layer: Re-disabled PasswordAuthentication to enforce SSH Key-only access.

Conclusion: Closing the Loop
I verified the fix by re-running the Hydra attack. This time, instead of "Attempts," I received a Connection Timeout. The threat was neutralized. This lab reinforced that a successful SOC workflow requires a combination of logging, proactive hunting, and rapid firewall response.

Top comments (0)