This article details how to enhance active response capabilities within a host intrusion detection system (HIDS) to block unauthorized users from logging into servers. The method involves creating a list of invalid usernames and configuring a rule that triggers an active response to block the source IP address upon a successful login attempt with one of these usernames.

The Problem: Unwanted User Logins

In many environments, specific user accounts exist on servers that should not be accessible for direct user logins. These might include service accounts (e.g., mysql) or administrative accounts required for underlying software operations. While the primary and most secure solution is to configure these accounts with a no_login parameter in the /etc/passwd file, misconfigurations or oversights can occur. Scenarios such as modifications to golden images, kickstart processes, or accidental changes during maintenance can bypass these security settings, leaving accounts vulnerable to unauthorized access.

Solution: Active Response for Invalid User Logins

To mitigate these potential failures, an active response mechanism can be implemented. This approach allows for the dynamic blocking of IP addresses associated with login attempts using designated invalid usernames. When a user attempts to log in with an account from a predefined list of invalid usernames, the HIDS can trigger an active response. This response will add the originating IP address to the firewall's block list, creating an iptables rule that drops all traffic from that IP. Consequently, the user's session will be immediately terminated, and an alert will be generated, notifying the security team of the attempted unauthorized login.

Implementation Steps

1. Create an Invalid Users List

The first step is to create a list of usernames that should not be permitted to log in.

• Create a list file: A new file, for example, invalid_users, is created.
• Add usernames: Within this file, usernames are added as key entries. For instance, admin and hacker could be listed. It is crucial that these usernames correspond to actual accounts existing on the server.
• Create user accounts (for testing): To demonstrate the functionality, legitimate user accounts for admin and hacker are created using useradd. Passwords are then set for these accounts using passwd.

2. Configure the HIDS Manager

The HIDS manager needs to be aware of the newly created list.

• Add list to configuration: The invalid_users list file is added to the HIDS manager's configuration, typically located in /var/ossec/etc/lists/invalid_users.
• Compile the list: The HIDS manager compiles this text file into a .cdb format, which is optimized for quick lookups. This is usually done by restarting the HIDS manager service.

3. Create a Custom Rule

A custom rule is required to detect successful logins using the invalid usernames.

• Identify a relevant parent rule: The rule for authentication success, with signature ID 5715, is identified as a suitable parent rule.
• Create a child rule: A new custom rule is created. This rule is configured to trigger only when the parent rule (5715) fires.
  • Rule ID: A unique ID is assigned (e.g., 100006).
  • Condition: The rule checks for if sid 5715.
  • Field comparison: It then compares the dst user field (which under the hood correlates to the username) against the invalid_users list.
  • List lookup: The lookup equal match_key directive is used to search for the username within the invalid_users list.
  • Alert message: An alert message, such as "Invalid user is successfully logged in," is defined.
• Save and restart: The custom rule is saved, and the HIDS manager is restarted to apply the changes.

4. Test the Rule

Before implementing active response, the rule's functionality is tested.

• Attempt login: Log in to the server using one of the invalid usernames (e.g., admin or hacker).
• Verify alert: Check the HIDS alerts to confirm that the "Invalid user is successfully logged in" alert is generated for each successful login attempt.

5. Configure Active Response

Once the rule is confirmed to be working correctly, active response is configured to block the source IP.

• Edit active response configuration: The active response configuration, typically found in ossec.conf on the manager, is edited.
• Define active response action: A new active response entry is added.
  • Command: The firewall-drop active response command is specified.
  • Agent ID: The target agent ID (e.g., 006) is set.
  • Rule ID: The active response is linked to the custom rule ID (100006).
  • Timeout: A timeout period (e.g., 20 seconds) is set for the block.
  • Repeat offender: The repeat_offender option is disabled to prevent permanent lockout during testing.
• Save and restart: The ossec.conf file is saved, and the HIDS manager is restarted.

6. Test Active Response

The active response mechanism is then tested.

• Attempt login: Log in to the server using an invalid username (e.g., hacker).
• Observe session termination: The user's session should be immediately dropped, and they should lose connectivity.
• Verify firewall rule: Check the iptables rules on the agent to confirm that a rule has been created to drop traffic from the source IP address.
• Verify alert: Confirm that an alert indicating the host block is generated.
• Observe unblocking: After the timeout period (20 seconds), verify that the iptables rule is automatically removed, allowing subsequent logins (if desired). The HIDS should also generate an "unblock" alert.

Benefits of Active Response

Implementing active response for invalid user logins offers significant advantages:

• Proactive Blocking: Instead of merely alerting on suspicious activity, active response immediately prevents unauthorized access by blocking the source IP.
• Reduced Attack Window: This immediate blocking significantly reduces the time an attacker has to enumerate the system, download malware, or perform other malicious actions.
• Empowerment: Security teams can take immediate action without waiting for other departments (like corporate IT or data center operations) to update LDAP or Active Directory. This is particularly useful in scenarios involving disgruntled employees, where rapid account disabling is critical.

This approach provides a robust layer of defense by dynamically responding to and mitigating unauthorized login attempts, thereby enhancing the overall security posture of the environment.