Define a Log Inspection rule for use in policies

Note Log Inspection Rules that are assigned to one or more computers or that are part of a policy cannot be deleted.

• Create a new Log Inspection rule
• Decoders
• Subrules
• Real world examples
• Log Inspection rule severity levels and their recommended use
• strftime() conversion specifiers
• Examine a Log Inspection rule

Create a new Log Inspection rule

1. In the Server & Workload Protection console, go to Policies → Common Objects → Rules → Log Inspection Rules.
2. Click New → New Log Inspection Rule.
3. On the General tab, enter a name and an optional description for the rule.
4. The Content tab is where you define the rule. The easiest way to define a rule is to select Basic Rule and use the options provided to define the rule. If you need further customization, you can select Custom (XML) to switch to an XML view of the rule that you are defining.

   Note Any changes you make in the Custom (XML) view will be lost if you switch back to the Basic Rule view.

   For further assistance in writing your own Log Inspection rules using the XML-based language, consult the OSSEC documentation or contact your support provider.

• Rule ID: The Rule ID is a unique identifier for the rule. OSSEC defines 100000 - 109999 as the space for user-defined rules. Server & Workload Protection will pre-populate the field with a new unique Rule ID.
• Level: Assign a level to the rule. Zero (0) means the rule never logs an event, although other rules that watch for this rule may fire.
• Groups: Assign the rule to one or more comma-separated groups. This can be useful when dependency is used because you can create rules that fire on the firing of a rule, or a rule that belongs to a specific group.
• Rule Description: Description of the rule.
• Pattern Matching: This is the pattern the rule will look for in the logs. The rule will be triggered on a match. Pattern matching supports Regular Expressions or simpler String Patterns. The "String Pattern" pattern type is faster than RegEx but it only supports three special operations:
  • ^ (caret): specifies the beginning of text
  • $ (dollar sign): specifies the end of text
  • | (pipe): to create a "OR" between multiple patterns For information on the regular expression syntax used by the Log Inspection module, see https://www.ossec.net/docs/syntax/regex.html.
• Dependency: Setting a dependency on another rule will cause your rule to only log an event if the rule specified in this area has also triggered.
• Frequency: The number of times the rule has to match within a specific time frame before the rule is triggered.
• Time Frame: The period of time in seconds within which the rule has to trigger a certain number of times (the frequency, above) to log an event.

Note The Content tab only appears for Log Inspection rules that you create yourself. Log Inspection rules issued by Trend Micro have a Configuration tab instead that displays the Log Inspection rule's configuration options (if any).

1. On the Files tab, type the full path to the file(s) you want your rule to monitor and specify the type of file it is.
2. On the Options tab, in the Alert section, select whether this rule triggers an alert in Server & Workload Protection. Alert Minimum Severity sets the minimum severity level that will trigger an Alert for rules made using the Basic Rule or Custom (XML) template.

   Note The Basic Rule template creates one rule at a time. To write multiple rules in a single template you can use the Custom (XML) template. If you create multiple rules with different Levels within a Custom (XML) template, you can use the Alert Minimum Severity setting to select the minimum severity that will trigger an Alert for all of the rules in that template.

3. The Assigned To tab lists the policies and computers that are using this Log Inspection rule. Because you are creating a new rule, it has not been assigned yet.
4. Click OK. The rule is ready to be assigned to policies and computers.

Decoders

• log: the message section of the event
• full_log: the entire event
• location: where the log came from
• hostname: hostname of the event source
• program_name: program name from the syslog header of the event
• srcip: the source IP address within the event
• dstip: the destination IP address within the event
• srcport: the source port number within the event
• dstport: the destination port number within the event
• protocol: the protocol within the event
• action: the action taken within the event
• srcuser: the originating user within the event
• dstuser: the destination user within the event
• id: any ID decoded as the ID from the event
• status: the decoded status within the event
• command: the command being called within the event
• url: the URL within the event
• data: any additional data extracted from the event
• systemname: the system name within the event

• An alert can be raised. (Configurable on the Options tab of the Log Inspection Rule's Properties window.)
• The event can be written to syslog. (Configurable in the SIEM area on Administration → System Settings → Event Forwarding tab.)
• The event can be sent to Server & Workload Protection. (Configurable in the Log Inspection Syslog Configuration setting on the Policy or Computer Editor → Settings → Event Forwarding tab.)

Subrules

Groups

<group name="syslog,sshd,">
</group>

Note Notice the trailing comma in the group name. Trailing commas are required if you intend to use the <if_group></if_group> tag to conditionally append another sub-rule to this one.

Note When a set of Log Inspection rules are sent to an agent, the Log Inspection engine on the agent takes the XML data from each assigned rule and assembles it into what becomes essentially a single long Log Inspection rule. Some group definitions are common to all Log Inspection rules written by Trend Micro. For this reason Trend Micro has included a rule called "Default Rules Configuration" which defines these groups and which always gets assigned along with any other Trend Micro rules. (If you select a rule for assignment and haven't also selected the "Default Rules Configuration" rule, a notice will appear informing you that the rule will be assigned automatically.) *If you create your own Log Inspection rule and assign it to a Computer without assigning any Trend Micro-written rules, you must either copy the content of the "Default Rules Configuration" rule into your new rule, or also select the "Default Rules Configuration"**rule for assignment to the Computer.

Rules, ID, and Level

<group name="syslog,sshd,">
    <rule id="100120" level="5">
    </rule>
    <rule id="100121" level="6">
    </rule>
</group>

Note Custom rules must have ID values of 100,000 or greater.

Note If event auto-tagging is enabled, the event will be labeled with the group name. Log Inspection rules provided by Trend Micro make use of a translation table that changes the group to a more user-friendly version. So, for example, "login_denied" would appear as "Login Denied". Custom rules will be listed by their group name as it appears in the rule.

Description

<group name="syslog,sshd,">
    <rule id="100120" level="5">
        <group>authentication_success</group>
        <description>SSHD testing authentication success</description>
    </rule>
    <rule id="100121" level="6">
        <description>SSHD rule testing 2</description>
    </rule>
</group>

Decoded As

<rule id="100123" level="5">
    <decoded_as>sshd</decoded_as>
    <description>Logging every decoded sshd message</description>
</rule>

Note To view the available decoders, go to the Log Inspection Rule page and click Decoders. Right-click on 1002791-Default Log Decoders and select Properties. Go the Configuration tab and click View Decoders.

Match

Jan 1 12:34:56 linux_server sshd[1231]: Failed password for invalid user jsmith from 192.168.1.123 port 1799 ssh2

<rule id="100124" level="5">
    <decoded_as>sshd</decoded_as>
    <match>^Failed password</match>
    <description>Failed SSHD password attempt</description>
</rule>

Note Notice the regex caret ("^") indicating the beginning of a string. Although "Failed password" does not appear at the beginning of the log, the Log Inspection decoder will have broken up the log into sections. See Decoders for more information. One of those sections is "log" which is the message part of the log as opposed to "full_log" which is the log in its entirety.

Conditional Statements

<group name="syslog,sshd,">
    <rule id="100123" level="2">
        <decoded_as>sshd</decoded_as>
        <description>Logging every decoded sshd message</description>
    </rule>
    <rule id="100124" level="7">
        <if_sid>100123</if_sid>
        <match>^Failed password</match>
        <group>authentication_failure</group>
        <description>Failed SSHD password attempt</description>
    </rule>
    <rule id="100125" level="3">
        <if_sid>100123</if_sid>
        <match>^Accepted password</match>
        <group>authentication_success</group>
        <description>Successful SSHD password attempt</description>
    </rule>
</group>

Hierarchy of Evaluation

Note The hierarchical parent-child structure can be used to improve the efficiency of your rules. If a parent rule does not evaluate as true, the Log Inspection engine will ignore the children of that parent.

Note Although the <if_sid></if_sid> tag can be used to refer to subrules within an entirely different Log Inspection rule, you should avoid doing this because it makes the rule very difficult to review later on.

<rule id="100127" level="10">
    <if_sid>100125</if_sid>
    <time>6 pm - 8:30 am</time>
    <description>Login outside business hours.</description>
    <group>policy_violation</group>
</rule>

Restrictions on the Size of the Log Entry

<rule id="100127" level="10" maxsize="2000">
    <if_sid>100125</if_sid>
    <time>6 pm - 8:30 am</time> 
    <description>Login outside business hours.</description>
    <group>policy_violation</group>
</rule>

Composite Rules

<rule id="100130" level="10" frequency="x" timeframe="y">
</rule>

<rule id="100130" level="10" frequency="5" timeframe="600">
    <if_matched_sid>100124</if_matched_sid>
    <description>5 Failed passwords within 10 minutes</description>
</rule>

<rule id="100130" level="10" frequency="5" timeframe="600">
    <if_matched_group>authentication_failure</if_matched_group>
    <same_source_ip />
    <description>5 Failed passwords within 10 minutes</description>
</rule>

<rule id="100130" level="10" frequency="5" timeframe="600">
    <if_matched_regex>^Failed password</if_matched_regex>
    <same_source_ip />
    <description>5 Failed passwords within 10 minutes</description>
</rule>

Real world examples

1. Where does the application log to?
2. Which Log Inspection decoder can be used to decode the log file?
3. What is the general format of a log file message?

1. Windows Event Viewer
2. Windows Event Log (eventlog)
3. Windows Event Log Format with the following core attributes:
   • Source: CMS
   • Category: None
   • Event: <Application Event ID>

• CMS Application Log (Source: CMS)
  • Authentication (Event: 100 to 119)
    • User Login successful (Event: 100)
    • User Login unsuccessful (Event: 101)
    • Administrator Login successful (Event: 105)
    • Administrator Login unsuccessful (Event: 106)
  • General Errors (Type: Error)
    • Database error (Event: 200 to 205)
    • Runtime error (Event: 206-249)
  • Application Audit (Type: Information)
    • Content
      • New content added (Event: 450 to 459)
      • Existing content modified (Event: 460 to 469)
      • Existing content deleted (Event: 470 to 479)
    • Administration
      • User
        • New User created (Event: 445 to 446)
        • Existing User deleted (Event: 447 to 449)

1. In the Server & Workload Protection console, go to Policies → Common Objects → Rules → Log Inspection Rules and click New to display the New Log Inspection Rule Properties window.
2. Give the new rule a name and a description, and then click the Content tab.
3. The quickest way to create a new custom rule is to start with a basic rule template. Select the Basic Rule radio button.
4. The Rule ID field will be automatically populated with an unused ID number of 100,000 or greater, the IDs reserved for custom rules.
5. Set the Level setting to Low (0).
6. Give the rule an appropriate Group name. In this case, "cms".
7. Provide a short rule description.
   
8. Now select the Custom (XML) option. The options you selected for your "Basic" rule will be converted to XML.
   
9. Click the Files tab and click the Add File button to add any application log files and log types which the rule will be applied to. In this case, "Application", and "eventlog" as the file type.
   

   Note Eventlog is a unique file type in Server & Workload Protection because the location and filename of the log files don't have to be specified. Instead, it is sufficient to type the log name as it is displayed in the Windows Event Viewer. Other log names for the eventlog file type might be "Security", "System", "Internet Explorer", or any other section listed in the Windows Event Viewer. Other file types will require the log file's location and filename. (C/C++ strftime() conversion specifiers are available for matching on filenames. See the table below for a list of some of the more useful ones.)

10. Click OK to save the basic rule.
11. Working with the basic rule Custom (XML) created, we can begin adding new rules to the group based on the log groupings identified previously. We will set the base rule criteria to the initial rule. In the following example, the CMS base rule has identified Windows Event Logs with a Source attribute of "CMS":

    <group name="cms">
        <rule id="100000" level="0">
        <category>windows</category>
        <extra_data>^CMS</extra_data>
        <description>Windows events from source 'CMS' group messages.</description>
    </rule>

12. Now we build up subsequent rules from the identified log groups. The following example identifies the authentication and login success and failure and logs by Event IDs.

    <rule id="100001" level="0">
        <if_sid>100000</if_sid>
        <id>^100|^101|^102|^103|^104|^105|^106|^107|^108|^109|^110</id>
        <group>authentication</group>
        <description>CMS Authentication event.</description>
    </rule>
    
    <rule id="100002" level="0">
        <if_group>authentication</if_group>
        <id>100</id>
        <description>CMS User Login success event.</description>
    </rule>
    
    <rule id="100003" level="4">
        <if_group>authentication</if_group>
        <id>101</id> <group>authentication_failure</group>
        <description>CMS User Login failure event.</description>
    </rule>
    
    <rule id="100004" level="0">
        <if_group>authentication</if_group>
        <id>105</id>
        <description>CMS Administrator Login success event.</description>
    </rule>
    
    <rule id="100005" level="4">
        <if_group>authentication</if_group>
        <id>106</id>
        <group>authentication_failure</group>
        <description>CMS Administrator Login failure event.</description>
    </rule>

13. Now we add any composite or correlation rules using the established rules. The follow example shows a high severity composite rule that is applied to instances where the repeated login failures have occurred 5 times within a 10 second time period:

    <rule id="100006" level="10" frequency="5" timeframe="10">
        <if_matched_group>authentication_failure</if_matched_group>
        <description>CMS Repeated Authentication Login failure event.</description>
    </rule>

14. Review all rules for appropriate severity levels. For example, error logs should have a severity of level 5 or higher. Informational rules would have a lower severity.
15. Finally, open the newly created rule, click the Configuration tab and copy your custom rule XML into the rule field. Click Apply or OK to save the change.

<group name="cms">
    <rule id="100000" level="0">
        <category>windows</category>
        <extra_data>^CMS</extra_data>
        <description>Windows events from source 'CMS' group messages.</description>
    </rule>
    <rule id="100001" level="0">
        <if_sid>100000</if_sid>
        <id>^100|^101|^102|^103|^104|^105|^106|^107|^108|^109|^110</id>
        <group>authentication</group>
        <description>CMS Authentication event.</description>
    </rule>
    <rule id="100002" level="0">
        <if_group>authentication</if_group>
        <id>100</id>
        <description>CMS User Login success event.</description>
    </rule>
    <rule id="100003" level="4">
        <if_group>authentication</if_group>
        <id>101</id>
        <group>authentication_failure</group>
        <description>CMS User Login failure event.</description>
    </rule>
    <rule id="100004" level="0">
        <if_group>authentication</if_group>
        <id>105</id>
        <description>CMS Administrator Login success event.</description>
    </rule>
    <rule id="100005" level="4">
        <if_group>authentication</if_group>
        <id>106</id>
        <group>authentication_failure</group>
        <description>CMS Administrator Login failure event.</description>
    </rule>
    <rule id="100006" level="10" frequency="5" timeframe="10">
        <if_matched_group>authentication_failure</if_matched_group>
        <description>CMS Repeated Authentication Login failure event.</description>
    </rule>
    <rule id="100007" level="5">
        <if_sid>100000</if_sid>
        <status>^ERROR</status>
        <description>CMS General error event.</description>
        <group>cms_error</group>
    </rule>
    <rule id="100008" level="10">
        <if_group>cms_error</if_group>
        <id>^200|^201|^202|^203|^204|^205</id>
        <description>CMS Database error event.</description>
    </rule>
    <rule id="100009" level="10">
        <if_group>cms_error</if_group>
        <id>^206|^207|^208|^209|^230|^231|^232|^233|^234|^235|^236|^237|^238|
        ^239^|240|^241|^242|^243|^244|^245|^246|^247|^248|^249</id>
        <description>CMS Runtime error event.</description>
    </rule>
    <rule id="100010" level="0">
        <if_sid>100000</if_sid>
        <status>^INFORMATION</status>
        <description>CMS General informational event.</description>
        <group>cms_information</group>
    </rule>
    <rule id="100011" level="5">
        <if_group>cms_information</if_group> 
        <id>^450|^451|^452|^453|^454|^455|^456|^457|^458|^459</id>
        <description>CMS New Content added event.</description>
    </rule>
    <rule id="100012" level="5">
        <if_group>cms_information</if_group>
        <id>^460|^461|^462|^463|^464|^465|^466|^467|^468|^469</id>
        <description>CMS Existing Content modified event.</description>
    </rule>
    <rule id="100013" level="5">
        <if_group>cms_information</if_group>
        <id>^470|^471|^472|^473|^474|^475|^476|^477|^478|^479</id>
        <description>CMS Existing Content deleted event.</description>
    </rule>
    <rule id="100014" level="5">
        <if_group>cms_information</if_group>
        <id>^445|^446</id>
        <description>CMS User created event.</description>
    </rule>
    <rule id="100015" level="5">
        <if_group>cms_information</if_group>
        <id>^447|449</id>
        <description>CMS User deleted event.</description>
    </rule>
</group>

Log Inspection rule severity levels and their recommended use

strftime() conversion specifiers

Examine a Log Inspection rule

Log Inspection rule structure and the event matching process

• 3800 - Grouping of Exchange Rules - Ignore
  • 3801 - Email rcpt is not valid (invalid account) - Medium (4)
    • 3851 - Multiple email attempts to an invalid account - High (9)
      • Frequency - 10
      • Time Frame - 120
      • Ignore - 120
  • 3802 - Email 500 error code - Medium (4)
    • 3852 - Email 500 error code (spam) - High (9)
      • Frequency - 12
      • Time Frame - 120
      • Ignore - 240

Duplicate Sub-rules