1. Understanding the Rule Files #
Argus’s rule files are located in the /var/ossec/rules/ directory. These XML files define how log events are analyzed, categorized, and flagged for alerts. The files are grouped based on different types of data sources (e.g., firewall, syslog, ssh, etc.).
- File structure: Each file contains multiple <group> sections, with individual <rule> blocks inside them. A rule defines the matching conditions for an event.
- Naming conventions: You can name custom rule files following a clear convention like custom_rules.xml for your own rules.
2. Basic Rule Structure #
Each rule is structured using XML tags. Here’s an example rule:
<rule id=”100001″ level=”5″>
<decoded_as>syslog</decoded_as>
<field name=”program”>sshd</field>
<description>SSH failed login attempt</description>
<group>ssh,authentication_failed</group>
<pci_dss>6.5.2</pci_dss>
</rule>
Key elements:
id: Unique identifier for the rule.
level: Severity level of the alert (1–15, where 15 is the highest).
decoded_as: Specifies the log source (e.g., syslog).
field: Matching condition on a specific log field.
description: What the rule monitors.
group: Logical group for rule classification (e.g., ssh, authentication_failed).
pci_dss: Compliance mapping (if needed).
3. Creating Custom Rules #
To create your own rules:
- Create a new file in the /var/ossec/rules/ directory, for example:
sudo nano /var/ossec/rules/custom_rules.xml
- Add your custom rules with unique rule IDs. Here’s a basic example for detecting SSH login failures:
<group name=”custom_rules”>
<rule id=”100002″ level=”10″>
<decoded_as>syslog</decoded_as>
<field name=”program”>sshd</field>
<match>Failed password</match>
<description>SSH failed login attempt</description>
<group>authentication_failed, ssh</group>
<pci_dss>10.2.4</pci_dss>
</rule>
</group>
4. Rule Matching Conditions #
Argus rules can match on various fields or conditions:
match: Looks for a specific string or regular expression in the log message.
field: Matches specific fields in the log (like program name or user).
decoded_as: Specifies the decoder to use for log normalization (e.g., apache, ssh, etc.).
srcip and dstip: Can be used to match source and destination IPs in network logs.
5. Testing and Validating Your Rules #
After creating or modifying a rule, it’s important to test it:
- Restart Argus Manager to apply the changes:
sudo systemctl restart argus-manager
- Monitor logs and alerts: Check the Argus logs and alert files (/var/ossec/logs/alerts/alerts.log) to ensure your rules are triggering as expected.
- Debugging: Use the /var/ossec/logs/ossec.log file to debug rule processing issues.
6. Adjusting Rule Levels #
- Levels: Control the severity of an alert. You can adjust rule levels based on the importance of the event (e.g., level 10 for failed logins or level 15 for successful root login).
- Alert Frequency: You can set up thresholds to limit alert frequency or group multiple events using tags like <frequency> and <aggregation> to avoid overwhelming alerts.
7. Mapping Rules to Compliance #
If you need to meet specific security frameworks like PCI DSS or GDPR, you can include tags in your rule configurations that map alerts to compliance requirements, like:
<pci_dss>10.2.4</pci_dss>
8. Advanced Rule Configuration #
You can configure more advanced rules that include:
- fired_times: Triggering the alert only after a certain number of events occur.
- timeframe: Only alerting if multiple events occur within a defined time period.
- if_sid: Referencing other rule IDs to build rule dependencies (e.g., if an event happens after another rule has triggered).
