Gabrielly Ribeiro

A hands-on cybersecurity lab focused on attack simulation, real-time detection, and automated defensive response

Project Summary

This project is a hands-on Security Operations Center style lab designed to simulate, detect, and mitigate an SSH brute-force attack in a controlled virtual environment.

The goal was to understand how a real authentication attack appears from both the attacker and defender perspectives. I built a small internal lab using Kali Linux and Ubuntu Server, simulated an SSH brute-force attack, monitored authentication logs in real time, and implemented automated blocking with Fail2Ban and iptables.

This project demonstrates practical experience with Linux security, log analysis, intrusion prevention, firewall enforcement, and SOC-style incident investigation.

Lab Architecture

The lab was built using two virtual machines connected through an isolated internal network.

The environment was isolated from external systems, allowing the attack simulation to remain safe, controlled, and repeatable.

Security Workflow

The lab followed a realistic security operations workflow:

Service Exposure → Attack Simulation → Log Monitoring → Detection → Automated Response → Firewall Enforcement

This structure mirrors the type of process used in real SOC environments, where analysts must identify suspicious activity, validate evidence, and confirm whether defensive controls responded correctly.

Preparing the Target System

The Ubuntu machine was configured as the target system. I installed and enabled the OpenSSH service to allow remote authentication attempts.

sudo systemctl status ssh

The SSH service was confirmed to be active and running before the attack simulation began.

SSH Service Running

This step established the attack surface. In real environments, exposed SSH services are commonly targeted when password-based authentication is enabled.

Validating SSH Exposure

After enabling SSH, I verified that the target machine was listening on port 22.

ss -tuln | grep :22

SSH Port 22 Listening

This confirmed that the service was reachable and ready for controlled testing.

Simulating the Attack

From the Kali Linux machine, I used Hydra to simulate an automated SSH brute-force attack against the Ubuntu server.

hydra -t 2 -l [username] -P [wordlist] ssh://[target-ip]

Hydra generated repeated authentication attempts against the SSH service, simulating how attackers attempt to guess weak or reused credentials.

Hydra Attack Simulation

This stage demonstrated how quickly automated tools can generate suspicious authentication activity and why monitoring authentication logs is essential.

Monitoring Authentication Logs

While the brute-force attack was running, I monitored SSH logs on the Ubuntu server in real time.

sudo journalctl -u ssh -f

The logs displayed repeated failed authentication attempts caused by the attack.

SSH Authentication Logs

From a defensive perspective, this is the key evidence. The logs showed repeated authentication failures and suspicious login behavior, which are common indicators of brute-force activity.

Implementing Automated Defense with Fail2Ban

To respond to the attack, I configured Fail2Ban to monitor SSH authentication failures and automatically ban suspicious sources after repeated failed login attempts.

Example detection logic:

[sshd]enabled = truemaxretry = 3findtime = 60bantime = 600

This configuration allowed Fail2Ban to detect repeated failed SSH attempts within a defined time window and temporarily block the source.

Fail2Ban Jail Status

This step transformed the lab from simple attack observation into an automated detection and response workflow.

Enforcing the Block with iptables

After Fail2Ban detected the suspicious behavior, it dynamically created firewall rules using iptables.

sudo iptables -L

iptables Firewall Rule

This was the strongest validation point in the lab. It confirmed that the system did not only detect the brute-force attempt, but also responded automatically at the network level.

The defensive chain was:

Failed SSH attempts → Fail2Ban detection → iptables rule creation → attacker blocked

Security Analysis

The observed activity was consistent with an SSH brute-force attempt.

Indicators Observed

• Repeated failed SSH login attempts
• Multiple authentication requests from the same source
• Automated login behavior generated by Hydra
• Fail2Ban threshold triggered
• Firewall rule created to block the attacker

Security Interpretation

In a real environment, this behavior could indicate:

• credential guessing
• unauthorized access attempts
• weak password exposure
• early-stage compromise activity
• potential lateral movement attempt

A SOC analyst would investigate the source, affected account, authentication frequency, and whether any successful login occurred after repeated failures.

Challenges and Troubleshooting

This project included several realistic troubleshooting challenges, including:

• SSH service validation
• internal network communication issues
• Hydra wordlist path issues
• Fail2Ban configuration adjustments
• firewall rule verification
• distinguishing commands that should run on the attacker machine versus the target machine
• validating whether a ban was currently active or had already expired

These issues made the lab more valuable because they reflected real operational work. Security projects are not only about running tools; they require troubleshooting, validation, and clear interpretation of system behavior.

Skills Demonstrated

This project demonstrates hands-on experience in:

• Linux system administration
• SSH configuration and monitoring
• brute-force attack simulation
• log analysis
• intrusion prevention
• firewall management
• security troubleshooting
• SOC-style investigation
• defensive security validation

Professional Relevance

This lab reflects practical workflows used in Security Operations and cybersecurity environments.

A security analyst may need to:

• identify repeated authentication failures
• determine the source of suspicious activity
• validate whether automated controls responded correctly
• review logs for evidence
• confirm firewall enforcement
• document findings clearly

This project allowed me to practice each of those steps in a controlled environment while building confidence with Linux-based security tools.

Project Outcome

By the end of this lab, I successfully:

• deployed and validated an SSH service on Ubuntu
• simulated an SSH brute-force attack from Kali Linux
• monitored authentication logs in real time
• configured Fail2Ban to detect repeated failed logins
• verified automated banning behavior
• confirmed firewall-level blocking through iptables
• documented the full attack-detection-response workflow

This project strengthened my understanding of how attack simulation, log analysis, automated defense, and firewall enforcement work together in a practical security operations workflow.

Key Takeaways

• Brute-force attacks generate recognizable authentication log patterns.
• Real-time monitoring improves detection and response speed.
• Automated intrusion prevention reduces manual response time.
• Firewall integration is essential for enforcing defensive actions.
• Linux-based security tools can create effective layered protection.
• Troubleshooting is a critical part of cybersecurity operations.

Future Improvements

Future versions of this lab could include:

• SIEM integration
• centralized log collection
• dashboard visualization
• email or Slack alerting
• IDS/IPS deployment
• multi-host monitoring
• additional attack scenarios
• formal incident report documentation

Final Reflection

This project was valuable because it connected offensive activity, defensive monitoring, and automated mitigation in one practical workflow.

Instead of only learning what brute-force attacks are, I was able to simulate one, observe its impact, analyze the evidence, and implement a defensive control that automatically responded to the threat.

This lab reinforced the importance of hands-on experimentation, technical troubleshooting, and clear documentation in cybersecurity. It also helped me better understand how Linux security tools can support real-world threat detection and response.