Book a demo
Argus
  • Home
  • Search
  • Threat Hunting
  • Threat Hunting- Log Data Analysis
  • Vulnerability detection
  • Mitre Attack
  • Virus Analyzer
  • Security- Endpoint Security
  • Configuration Assessment
  • File Integrity Monitoring
  • Security-Compliance Monitoring
  • Cloud Security
  • Server management
  • Working of XML Generator
  • Rules Configuration-Server Management
  • Server Management- Decoders Configuration
  • CDB Lists Configuration – Server Management
  • Cluster Configuration – Server Management
  • Logs Configuration – Server Management
  • Settings Configuration – Server Management
  • Dashboard Management
  • Index Management
  • Security Configuration – Index Management
  • Sample Data Configuration – Index Management
  • Dev Tools Configuration – Index Management
  • Customize Dashboard and visualization
  • Argus Agent
  • FAQ’s
  • Argus Ticketing Tool - Dashboard and Overview
  • Argus Investigation
  • Ticketing - Manage Cases and Advance Settings
  • Argus Ticketing Tool - Dashboard and Overview
  • Argus Investigation
  • Ticketing - Manage Cases and Advance Settings
  • Argus Ticketing Tool - Dashboard and Overview
  • Argus Investigation
  • Ticketing - Manage Cases and Advance Settings

Rules configuration - server management

Home > Docs > Argus > Rules configuration - server management

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).

What are your Feelings

Share This Article :

Facebook X-twitter Linkedin Pinterest

Still stuck? How can we help?

Working of XML Generator 

Server Management- Decoders Configuration

Leave a Reply

Logged in as admin. Edit your profile. Log out? Required fields are marked *

How can we help?

Book A Demo

Fill out the form below!

How can we help?