Custom Detection and Active response

Having successfully configured Wazuh and connected all agents in the lab, the next step is to configure File Integrity Monitoring (FIM) to track real time changes across key directories on both the Kali and Windows agents.

What is real time monitoring and report changes?

The realtime attribute instructs the Wazuh agent to actively watch a directory and immediately fire an alert the moment any change is detected, rather than waiting for a scheduled scan. The report_changes attribute goes a step further by recording the actual content of what changed, not just the fact that a change occurred. Together, these two attributes provide security analysts with an immediate and detailed view of any modifications taking place on a monitored system.

Configuring monitored directories on the Kali agent

On the Kali agent, two critical directories were configured for monitoring:

/etc — This directory stores system wide configuration files. Any unauthorized modification here could indicate configuration tampering, privilege escalation, or persistent backdoor activity.

/var/log — This directory contains most system and application logs. Monitoring it ensures that any attempt to tamper with or delete log files is immediately detected and alerted on.

Run the command sudo nano /var/ossec/etc/ossec.conf to edit the ossec configuration file.

In the file monitoring section, i added the two directories i want to monitor

/var/log

/etc

Sudo systemctl restart wazuh-agent to initiate the changes on the wazuh manager.

Configuring monitored directories on the Windows agent

On the Windows agent, the C:\Windows\System32 directory was configured for monitoring. This directory contains critical Windows operating system files, and any unauthorized modification to files within it is a strong indicator of malware activity, rootkit installation, or system level tampering.

To add this directory for monitoring, open Notepad as administrator and navigate to the ossec.conf file located at C:\Program Files (x86)\ossec-agent\. Under the File Integrity Monitoring section, add the following line:

<directories check_all="yes" report_changes="yes" realtime="yes">C:\Windows\System32</directories>

Run the command Restart-Service -Name WazuhSvc to restart the wazuh agent and initiate the changes on the wazuh dashboard.

Setting a scan frequency

A syscheck_frequency value was also configured alongside real time monitoring to define how often Wazuh performs a full baseline scan of all monitored directories. For this lab, the frequency was set to 300 seconds, ensuring a complete integrity check runs every five minutes across all monitored directories on both the Kali and Windows agents.

To verify that our File Integrity Monitoring configuration is working as expected, we will make a deliberate and controlled change to a monitored file and observe whether Wazuh detects and alerts on it in real time.

In this case, we will be modifying the permissions of the log file alternatives.log.1 from rw-r--r-- (read and write for owner, read only for group and others) to rw-rw-r-- (read and write for both owner and group, read only for others).

To apply this change, run the following command:

sudo chmod 664 alternatives.log.1

This change is intentional and allows us to confirm that Wazuh is actively monitoring file attribute changes, not just file content modifications. Any permission change on a monitored file will be immediately captured and reported as a security event on the Wazuh dashboard in real time.

This report documents a File Integrity Monitoring (FIM) test event generated on a Wazuh-monitored Kali Linux agent, captured by the syscheck module after a permission change on a monitored log file.

Kali Agent Alert Summary

File Path: /var/log/alternatives.log.1 Type of Change: Permission change (rw-r — r — → rw-rw-r — ) Timestamp: Jul 1, 2026 @ 21:09:02.661 Agent: 005 (Kali-Agent) Rule / Alert ID: Rule 550 (Level 7) User: root (uid 0)

Alert Detail

● Rule 550, Level 7, groups: ossec, syscheck, syscheck_entry_modified, syscheck_file

● MITRE ATT&CK T1565.001 (Stored Data Manipulation) — Tactic: Impact

● Compliance: GDPR II_5.1.f, GPG13 4.11, HIPAA 164.312.c.1/c.2, NIST 800–53 SI.7, PCI DSS 11.5, TSC PI1.4/PI1.5/CC6.1/CC6.8/CC7.2/CC7.3

● Content integrity: syscheck.diff reports no content changes — only the permission bits changed; MD5/SHA1/SHA256 and file size are unchanged from baseline

Full log: "File '/var/log/alternatives.log.1' modified. Mode: realtime. Changed attributes: permission. Permissions changed from 'rw-r — r — ' to 'rw-rw-r — '."

Next Steps If the Actor Were Unknown

I would treat this as a low confidence but worth checking signal. Loosened permissions on a log file are a common precursor to log tampering, and the change maps to a recognised ATT&CK data manipulation technique.

The file owner is root, but ownership alone does not tell me which account or process actually ran the chmod command. So I would correlate the alert timestamp at Jul 1, 2026 @ 21:09:02.661 with the auth and sudo logs and shell history on agent 005 to find the responsible session.

I would also check whether it ties to a known admin task such as a package update, an Ansible run, or a logrotate and alternatives operation, since this is a system managed file. Combined with the unchanged hashes and content, the drift is plausibly benign.

If no legitimate explanation surfaces, I would isolate or closely monitor the host, check for related changes and new or modified accounts, and rotate credentials as needed. I would document all findings and once confirmed, revert the permission and tighten alerting to prevent recurrence.

Creating Custom Rules in Wazuh

While the default Wazuh ruleset is extensive and covers a wide range of threat scenarios, it may not always align with the specific needs of every organization or the particular threat actors targeting them. In a real world SOC environment, security teams regularly create custom detection rules to monitor for activity that is unique to their environment, their assets, or the threats they face.

Custom rules allow analysts to go beyond what comes out of the box and tailor Wazuh's detection capabilities to match the organization's specific security requirements, whether that means detecting unusual access patterns, monitoring proprietary applications, or flagging activity that the default rules would otherwise miss.

How Are Alerts Generated and Rules Applied?

Understanding how Wazuh processes logs and fires alerts is essential before writing custom rules.

When a raw log arrives from an agent, it is first passed through the Wazuh decoder. The decoder parses the log and extracts the relevant fields from it, such as the timestamp, IP address, username, event type, and other key data points. This process transforms an unstructured raw log into structured, readable data that Wazuh can work with.

Once the log has been decoded and the fields extracted, the parsed data is then checked against the configured ruleset. Wazuh evaluates the data against each rule and if a match is found, an alert is fired and displayed on the dashboard.

In summary, the flow is: raw log received from agent → decoded and parsed → fields extracted → checked against rules → alert generated.

Custom rules for Wazuh live in /var/ossec/etc/rules/local_rules.xml on the manager. Like the default rules, they're written in XML, but their IDs need to start above 100000 to avoid colliding with Wazuh's built-in rule IDs.

For this setup, I'll be building three custom rules:

1. Alert when 5 failed SSH login attempts hit the Ubuntu machine from the same source IP within a 3-minute window
2. Alert when a new user account is created on the Kali machine
3. Alert when a USB device is detected on the Windows machine

Rule 1: SSH brute-force detection

sudo nano /var/ossec/etc/rules/local_rules.xml

Add the following:

<group name="local,syslog,sshd,">
<rule id="100002" level="10" frequency="5" timeframe="120">
  <if_matched_sid>5760</if_matched_sid>
  <same_source_ip />
  <description>SSH brute force detected from $(srcip)</description>
  <group>authentication_failed,</group>
  <mitre>
    <id>T1110</id>
  </mitre>
</rule>
</group>

<group name="local,syslog,sshd,">
<rule id="100002" level="10" frequency="5" timeframe="120">
  <if_matched_sid>5760</if_matched_sid>
  <same_source_ip />
  <description>SSH brute force detected from $(srcip)</description>
  <group>authentication_failed,</group>
  <mitre>
    <id>T1110</id>
  </mitre>
</rule>
</group>

Here, rule id is the unique identifier for the alert, level is its severity rating, frequency is how many matches are needed before the rule triggers, and timeframe is the window of time (in seconds) those matches have to occur within. Restart the wazuh-manager for the changes to take effect.

On the Kali machine, attempt to SSH into the Ubuntu server using an incorrect password five times in a row.

After five consecutive failed SSH login attempts from the Kali machine, the alert fired successfully.

Rule 2 : New user account creation on the Kali machine

Similar to the previous rule, open the custom rules XML file and add the following block:

<group name="local,syslog,adduser,">
<rule id="100003" level="8">
  <if_sid>5902</if_sid>
  <description>New User added: $(dstuser),verify this was authorized</description>
  <group>syslog,useradd,</group>
  <mitre>
    <id>T1136.001</id>
  </mitre>
</rule>
</group>

<group name="local,syslog,adduser,">
<rule id="100003" level="8">
  <if_sid>5902</if_sid>
  <description>New User added: $(dstuser),verify this was authorized</description>
  <group>syslog,useradd,</group>
  <mitre>
    <id>T1136.001</id>
  </mitre>
</rule>
</group>

Reload the Wazuh manager so the rule updates go live. Then, on the Kali box, spin up a test account with sudo adduser Test.

The Wazuh dashboard should show a new alert once this happens.

With that, both custom rules are up and running.

Rule 3:USB device

Follow the same approach to get Windows alerting on USB insertion: open the .xml configuration file and add the block below.

<group name="windows,usb,">
  <!-- RULE 3: USB Insertion Detection — Windows -->
  <rule id="100004" level="10">
    <if_sid>60227</if_sid>
    <description>USB storage device inserted on $(win.system.computer)</description>
    <mitre>
      <id>T1091</id>
    </mitre>
  </rule>
</group>

<group name="windows,usb,">
  <!-- RULE 3: USB Insertion Detection — Windows -->
  <rule id="100004" level="10">
    <if_sid>60227</if_sid>
    <description>USB storage device inserted on $(win.system.computer)</description>
    <mitre>
      <id>T1091</id>
    </mitre>
  </rule>
</group>

Restart the Wazuh manager on the Ubuntu server, plug a USB device into the Windows agent, and check for the event on the Wazuh dashboard.

Challenge: No USB event showed up on the manager side. After digging into it, I traced the issue to Event ID 6416 — the Plug and Play device log entry in Windows' Security log — which isn't captured by default. It only gets logged once the matching Advanced Audit Policy subcategory is switched on.

To enable it, run the following from an elevated Command Prompt or PowerShell on the Windows endpoint: auditpol /set /subcategory:"Plug and Play Events" /success:enable Then confirm it took effect: auditpol /get /subcategory:"Plug and Play Events"

After that fix, I unplugged the USB device and plugged it back in — and this time the alert fired successfully on the Wazuh manager.

With that, all three custom rules are fully operational.

Rules Tuning Note

Rule 100002 — SSH Brute Force Detection

Rule 100002 detects a brute-force SSH login attempt: more than 5 failed authentication attempts from the same source IP within a 120-second window. It relies on a supporting base rule, 5760, which classifies individual failed SSH login events, and uses if_matched_sid, frequency="5", timeframe="120", and <same_source_ip /> to correlate repeated failures from one IP.

It was tested by generating repeated failed SSH login attempts from the same source IP against the monitored host. The rule fired as expected, and alerts were confirmed in /var/ossec/logs/alerts/alerts.log on the Wazuh manager.

Rule 100003 — New User Account Creation (Linux)

This rule detects when a new user account is created on a Linux host via useradd/adduser, escalating the event from the default low-severity syslog classification to a level-8 alert for review, since account creation can indicate either legitimate administration or a persistence technique (MITRE T1136.001).

It was tested by running sudo adduser Test on the Kali endpoint. The command generated the expected event, and an alert was confirmed on the Wazuh dashboard.

Rule 100004 — USB Device Insertion (Windows)

This rule detects when a USB storage device is plugged into a monitored Windows endpoint, alerting on Plug and Play device events (Event ID 6416) via if_sid mapped to the confirmed base rule (60227), flagged under MITRE T1091 (Replication Through Removable Media).

It was tested by physically inserting a USB device into the Windows agent machine. The first test produced no alert — troubleshooting traced this to Windows not logging Event ID 6416 by default, since the Plug and Play Events subcategory of Advanced Audit Policy is disabled out of the box.

After enabling it on the endpoint with: auditpol /set /subcategory:"Plug and Play Events" /success:enable and confirming with: auditpol /get /subcategory:"Plug and Play Events" the USB device was removed and reinserted. This second test successfully generated an alert on the Wazuh manager, confirming the rule and the underlying audit policy configuration were both correctly tuned.

Summary

All three custom rules are confirmed operational end to end — from raw log/event generation on the endpoint, through Wazuh decoding and rule matching, to alert visibility on the Wazuh manager/dashboard

LOG ANALYSIS

On the Kali machine, I deliberately triggered authentication failure logs — first by entering a wrong password at login, then by repeatedly attempting to switch to the root user with an incorrect password, all as part of this analysis.

Log Analysis Report — Authentication Failures

Source(s) covered: Linux (Kali-Agent) Scope: Authentication failure events generated during controlled testing

Linux — Kali-Agent (192.168.8.137, agent.id 005) Event Type: Local Login Failure (Screen Lock) unix_chkpwd Password Check Failed

Raw event detail: Jul 03 19:44:10 kali unix_chkpwd[261569]: password check failed for user (kali) Rule ID: 5557 Rule level: 5 Rule groups: pam, syslog, authentication_failed MITRE: T1110.001 (Password Guessing) / Credential Access Decoder: unix_chkpwd

What it means: This alert comes from a low-level Linux tool called unix_chkpwd, which is the part of the system PAM (the login-checking system) calls on to actually compare the password you typed against the stored one. So this isn't a separate event — it's the "under the hood" confirmation that a password check failed, triggered by whatever you were doing on the surface (in this case, unlocking the screen).

Is it a problem? No. This matches a wrong password entered on purpose during testing. One failed attempt like this isn't something to worry about. It would only be worth digging into if it kept happening quickly and repeatedly, or if it came from a login session that shouldn't be active in the first place.

PAM: User Login Failed (xfce4-screensaver-dialog)

Raw event detail: Jul 03 19:44:10 kali xfce4-screensaver-dialog[261403]: pam_unix(xfce4-screensaver:auth): authentication failure; logname=kali uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=kali Rule ID: 5503 Rule level: 5 Rule groups: pam, syslog, authentication_failed MITRE: T1110.001 (Password Guessing) / Credential Access Decoder: pam

What it means: This alert is the login-checking system (PAM) recording the same failed unlock attempt as before, at the exact same moment. A couple of details in the log confirm this happened locally, right on the machine itself, rather than someone trying to get in remotely — there's no remote username or remote address listed anywhere in the log. So really, this and the previous alert are just two different ways of recording the same single mistake.

Is it a problem? No. This lines up with an intentional wrong password typed at an already-unlocked, logged-in desktop. Since it's clearly local and not remote, there's no reason for concern here — unless this kind of failure started happening over and over quickly, which would point to something more like a repeated break-in attempt.

Event Type: Privilege Escalation Failure (su) FAILED SU (to root)

Raw event detail: Jul 03 19:44:25 kali su[261684]: FAILED SU (to root) kali on pts/0 Rule ID: 5301 Rule level: 5 Rule description: User missed the password to change UID (user id) Rule groups: syslog, su, authentication_failed Decoder: su

What it means: This alert comes directly from the su command itself — the tool people use to switch to another user account, in this case trying to become the all-powerful "root" (admin) account. The log shows exactly who tried it (kali), what account they were trying to become (root), and that it happened from an actual terminal window someone was typing into, not through a script or a remote connection.

Is it a problem? Not in this case, since it was a deliberate test. But this kind of event deserves a bit more attention than a normal failed login, because trying to become admin is a bigger deal than just logging in. On its own, one failed attempt like this usually isn't alarming — but it would be worth investigating if it happened repeatedly, at odd hours, or from an account that has no real reason to need admin access.

PAM: User Login Failed (su)

Raw event detail: Jul 03 19:44:29 kali su[261752]: pam_unix(su:auth): authentication failure; logname=kali uid=1000 euid=0 tty=/dev/pts/0 ruser=kali rhost= user=root Rule ID: 5503 Rule level: 5 Rule groups: pam, syslog, authentication_failed MITRE: T1110.001 (Password Guessing) / Credential Access Decoder: pam

What it means: This is the login-checking system (PAM) recording that same failed attempt to become root, logged just four seconds after the su command's own log entry. The details confirm the same story: kali was trying to become root, and the system rejected it at the password-check stage.

Is it a problem? No. This is essentially a second copy of the same failed attempt already covered above — not a new event, just the same action being logged by a different part of the system.

unix_chkpwd Password Check Failed (root)

Raw event detail: Jul 03 19:44:29 kali unix_chkpwd[261762]: password check failed for user (root) Rule ID: 5557 Rule level: 5 Rule groups: pam, syslog, authentication_failed MITRE: T1110.001 (Password Guessing) / Credential Access Decoder: unix_chkpwd

What it means: This is the same low-level password-check tool from earlier (unix_chkpwd), but this time it's checking the password against the root account instead of kali. It confirms the failure happened right at the point of verifying the root password — matching up with the attempted switch to root.

Is it a problem? No. Like the two alerts before it, this isn't a new or separate event — it's the third and final log entry generated by that same single failed attempt to become root.

One action, three alerts. All three alerts from the "su" attempt actually came from one single action — trying to switch to root with the wrong password. Wazuh has three different parts (su, PAM, and unix_chkpwd) that each log their own record of what happened, so one real attempt shows up as three separate alerts. This is completely normal behavior, but it's worth remembering when counting alerts or setting thresholds for things like brute-force detection — otherwise you might think three attempts happened when it was really just one.

Everything here was expected. Every alert in this report came from tests I ran on purpose — typing a wrong password at screen unlock, and trying to become root with a wrong password. None of it points to anything suspicious.

This all happened locally, not remotely. Every alert shows signs that this activity happened right at the machine itself, not from somewhere else on the network. That's an important detail, because a real brute-force attack usually comes from a remote location, not the local keyboard.

What would actually be worth worrying about. If this same type of alert showed up again but wasn't explained by known testing — especially repeated attempts to become root, or attempts that show signs of coming from somewhere else on the network — that's when it should get flagged for a closer look.

Summary

Screen unlock — wrong password typed

• The system's password checker rejected the login. Routine.
• The login system (PAM) recorded the same failed attempt. Routine.

Trying to become root — wrong password typed

• The command to switch to root failed. Routine.
• The login system (PAM) recorded that failed switch to root. Routine.
• The password checker rejected the password specifically for the root account. Routine.

All five alerts trace back to just two real actions — one wrong password at screen unlock, and one wrong password while trying to become root — each one logged from a few different angles by the system. Nothing here points to a real problem; everything matches expected, intentional testing

.

Windows Agent Log analysis

I deliberately entered the wrong password first when logging into my Windows agent, then followed up with the correct one. The failed attempts are tagged under Event ID 4625, while the successful login falls under Event ID 4624 — and separately, Event ID 4672 fires to note that special privileges were assigned to that logon.

Log Analysis Report — Windows Authentication Events

Windows (Windows-Agent) Scope: Authentication-related events generated during controlled testing

Windows — Windows-Agent (192.168.8.1, agent.id 009) Event Type: Interactive Logon (Failure and Success)

Event ID 4625: Logon Failure (Unknown user or bad password)

Raw event detail: Event ID: 4625 Computer: Seyi-1 Logon Type: 2 (Interactive) Authentication Package: Negotiate Logon Process: User32 Process Name: C:\Windows\System32\svchost.exe IP Address: 127.X.X.X | Port: 0 Subject: SEYI-1$ / WORKGROUP (S-1–5–18) Target User SID: S-1–0–0 Status: 0xc000006d Failure Reason: %%2304 Timestamp: Jul 3, 2026 @ 22:11:24 Rule ID: 60122 Rule level: 5 Rule groups: windows, windows_security, authentication_failed MITRE: T1531 (Account Access Removal) / Impact

What it means: This is a failed login attempt on the Windows machine itself. A couple of technical details in the log confirm this — the system couldn't match the password to a real account, and the type of login recorded matches someone sitting right at the machine's own lock screen, not someone connecting in from elsewhere. The address and process listed in the log are also exactly what you'd expect for a normal local login attempt, nothing tied to a remote connection.

Is it a problem? No. This matches an intentional wrong-password entry during testing. It would only be worth a closer look if this kept happening rapidly and repeatedly, showed up at an odd hour, or had signs of coming from somewhere other than the machine itself.

Event ID 4624: Logon Success (Non-network/service local logon)

Raw event detail: Event ID: 4624 Computer: Seyi-1 Logon Type: 11 (Cached interactive/credential logon) Authentication Package: Negotiate Process Name: C:\Windows\System32\svchost.exe IP Address: 127.X.X.X Subject: SEYI-1$ / WORKGROUP (S-1–5–18) Target Account: [redacted personal Microsoft account] Timestamp: Jul 3, 2026 @ 22:11:29 Rule ID: 67022 Rule level: 3 groups: windows, WEF Rule description: Non network or service local logon

What it means: This alert confirms a successful login to the account, happening just 5 seconds after the earlier failed attempt. The type of login recorded is exactly what's expected for a Microsoft account signing in using saved (cached) credentials. Because the success happened so quickly after the failure, it strongly suggests both events are really just one login session — a mistyped password, immediately followed by the correct one.

Is it a problem? No. This is exactly what you'd expect to see right after a wrong password entry — the same person getting it right on the next try. There's nothing here suggesting the account was accessed by anyone else; it's the same machine, the same account, and no signs of anything unusual.

Event Type: Privileged Logon Event ID 4672: Special Privileges Assigned to New Logon

Raw event detail: Event ID: 4672 Computer: Seyi-1 Account Name: [redacted personal Microsoft account] Timestamp: Jul 3, 2026 @ 22:08:24 Rule ID: 67028 Rule level: 3 Rule groups: windows, WEF MITRE: T1484 (Domain Policy Modification) / Defense Evasion, Privilege Escalation

What it means: This alert shows that the account was given a set of powerful, sensitive permissions the moment it logged in. That sounds alarming, but it's actually automatic — Windows does this every single time an administrator-level account logs in, whether or not anything suspicious is happening. It's not evidence that someone tried to grab extra permissions; it's just Windows noting that an already-privileged account is now active.

Is it a problem? Not on its own. This kind of alert only becomes meaningful with context — whether the account is actually supposed to have admin rights, whether the login happened at a normal time and place, and whether it's paired with anything else unusual. In this case, it's simply a known admin account logging into its own machine, so there's nothing here that needs further action.

Observations Across Findings

A failed login followed quickly by a success is a normal pattern. These two events together — one mistake, then the correct password seconds later — are a useful example of what "normal human error" looks like in the logs. This is different from a real brute-force attempt, where you'd typically see many failures in a row with no eventual success, or failures coming from somewhere other than where the final successful login happens.

The "special privileges" alert needs context to mean anything. On its own, this type of alert is routine and expected for any known admin account logging in. But it's also exactly the kind of alert that becomes important in a real investigation — if it showed up on an account that isn't supposed to have admin rights, at a strange hour, or right after signs of someone hopping between systems, that same alert would go from "nothing to worry about" to "worth investigating immediately."

Summary

Here's the plain-language summary:

Wrong password typed at login

• The login failed because the password didn't match any known account. Routine.

Correct password typed right after

• The login succeeded, just 5 seconds after the failed attempt. Routine.

Admin account privileges noted

• Windows automatically recorded that the account logging in has administrator rights. Routine.

All three alerts trace back to one real action — a mistyped password immediately corrected by the right one — plus a routine, automatic note that the account involved has admin-level access. Nothing here points to a real problem.

Account creation on windows

Kali_alerts.csv — I ran a query against my Kali alerts, filtering it down to the critical ones: failed logins, PAM sessions, and new user creation events.

windows_alerts.csv — I ran queries against my Windows alerts and exported the results to a CSV.

Active Response on wazuh

Active Response is Wazuh's module for automatically executing scripts on a monitored endpoint when a specific alert fires, it helps security teams automate response actions based on specific triggers, so high-priority incidents get addressed quickly and consistently, which is especially valuable when security teams are resource-constrained. Wazuh ships with several out-of-the-box scripts (e.g. blocking an IP via firewall, disabling a user account).

Example is the SSH brute-force rule ialready built (rule 100002), the classic pairing is: rule fires → active response blocks the attacking IP automatically.

Configuring Active response

Open ossec.conf on the Manager and locate the active-response block — that's where the response actions get defined. I need to set up a response that fires the firewall-drop command whenever the SSH brute-force condition is triggered. firewall-drop comes built into Wazuh by default and works by adding an iptables rule to block incoming traffic from the offending IP. I'm setting the threshold at five failed SSH authentication attempts, and using a 3-minute timeout for testing — long enough to actually observe the block being applied and then lifted, without sitting around waiting forever.

Add the follow line to the Active response section

Restart the Wazuh manager so the changes take effect. To confirm the configuration worked, I ran 5 failed SSH login attempts on the Kali machine to trigger the alert tied to rule ID 100002.

After the 5th attempt, the SSH connection stopped responding entirely. I checked the Wazuh dashboard to see whether the event had been logged.

The active response fired successfully. To dig a bit deeper, while the Kali IP was still flagged, I checked the Ubuntu server's iptables to confirm the IP actually showed up in the block list.

To verify the 3-minute block duration was actually enforced, I re-ran the iptables check on the server after waiting out the full 3 minutes.

Sure enough, the Kali IP address was unblocked once the timeout elapsed.

Active Response — Risks and Safeguards for Production Use

Our test worked well in a controlled setting: we intentionally failed SSH login 5 times, rule 100002 fired, and firewall-drop blocked the Kali IP for 3 minutes. Real environments introduce two problems this test didn't have to deal with.

False positives. In our case, we knew the failures were intentional. A real user who mistypes their password five times gets the same treatment — and if their IP is shared (an office NAT, a jump box, a VPN gateway), the block can lock out everyone behind it, not just the person who made the mistake.

IP spoofing. We blocked the Kali IP because it genuinely was the source. But any rule keyed off source IP is only as reliable as that IP being real and unspoofable. An attacker who can fake failed-auth traffic as coming from a critical server could trick the same logic into blocking infrastructure you can't afford to lose — a self-inflicted outage with no actual compromise needed.

Safeguards before production:

1. Allowlist critical infrastructure (load balancers, DNS, jump boxes) so they can never be auto-blocked.
2. Keep first-offense timeouts short; escalate only for repeat offenders.
3. Scope to local or defined-agent, never all, so one bad trigger can't cascade fleet-wide.
4. Alert a human the moment a block fires, so false positives can be reversed immediately.
5. Stage in a lab first — prove the rule, response, and timeout reversal, exactly as we did here, before pointing it at real traffic.

The core idea: our test was safe because we controlled the conditions that triggered it. Production traffic doesn't offer that guarantee, which is what these safeguards are for.