Skip to main content
Version: 25.2.0

Log Message: Types and Examples

Policy Summary Messages​

The Waratek Agent will notify the user whether new ARMR policies have or have not been applied to the application. This message type is complementary to the Rule Lifecycle messages.

When a new ARMR policy is applied:

<14>1 2020-07-06T23:35:36.393+01:00 I-dev05 java 1356675 - - CEF:0|ARMR:ARMR|ARMR|19.0.1|Engine|Reload Rules|Low|rt=Jul 06 2020 23:35:36.393 +0100 dvchost=I-dev05 procid=1356675 outcome=success msg=New ARMR policy has been applied

When ARMR policies have been cleared or there was no ARMR policies to load by the agent:

<14>1 2020-07-06T23:36:06.405+01:00 I-dev05 java 1356675 - - CEF:0|ARMR:ARMR|ARMR|19.0.1|Engine|Reload Rules|Low|rt=Jul 06 2020 23:36:06.405 +0100 dvchost=I-dev05 procid=1356675 outcome=success msg=No ARMR policy is in effect

The logging device of this type of messages is the Waratek Agent.

Rule Lifecycle Messages​

Rule lifecycle messages occur when the Waratek Agent applies any ARMR rule. They are labelled as Load Rule, Link Rule, Unload Rule, Unlink Rule and Execute Rule CEF events.

Load Rule​

A rule is parsed and validated correctly:

<9>1 2020-05-11T19:02:22,551+01:00 I-dev05 java 46259 - - CEF:0|ARMR:ARMR|ARMR|2.2|RegistryImpl_Skel|Load Rule|Low|rt=May 05 2020 15:02:23.053 +0100 dvchost=I-dev05 procid=46210 outcome=success

A rule is added to the runtime and a hook is created for the rule to execute. After this event, if all the conditions laid out in the rule are satisfied, the rule will execute the configured action:

<9>1 2020-05-11T19:02:22,551+01:00 I-dev05 java 46259 - - CEF:0|ARMR:ARMR|ARMR|2.2|RegistryImpl_Skel|Link Rule|Low|rt=May 05 2020 15:02:28.257 +0100 dvchost=I-dev05 procid=46259 outcome=success

The rule’s hook attached to the runtime is removed. Events for this rule will no longer trigger:

<9>1 2020-05-11T19:02:22,551+01:00 I-dev05 java 46259 - - CEF:0|ARMR:ARMR|ARMR|2.2|RegistryImpl_Skel|Unload Rule|Low|rt=May 05 2020 15:02:37.098 +0100 dvchost=I-dev05 procid=46259 outcome=success

Unload Rule​

A rule is completely removed from the rules engine and the system:

<9>1 2020-05-11T19:02:22,551+01:00 I-dev05 java 46259 - - CEF:0|ARMR:ARMR|ARMR|2.2|RegistryImpl_Skel|Unlink Rule|Low|rt=May 05 2020 15:02:37.094 +0100 dvchost=I-dev05 procid=46259 outcome=success

Execute Rule​

Upon execution, an ARMR rule logs a security event indicating what action was taken in the face of the security threat. The act extension shown in the log entry is as what is configured for the rule along with its configured custom message (msg extension). Additional metadata associated with the context of the attack is also provided in some cases. This log message type uses the Execute Rule event type exclusively.

The following is a log entry example of an XSS attack that was blocked by an http rule:

<10>1 2022-03-01T13:20:23.952Z userX_system java 3942 - - CEF:0|ARMR:ARMR|ARMR|2.6|XSS|Execute Rule|Very-High|internalHttpRequestUri=/spiracle/xss.jsp procid=3942 dvchost=userX_system payload=<script>alert(1)</script> httpRequestUri=/spiracle/xss.jsp httpRequestMethod=GET msg=XSS attacked identified and blocked ruleType=http taintSource=HTTP_SERVLET appVersion=1 securityFeature=http html xss remoteIpAddress=127.0.0.1

When an ARMR rule is triggered by an attack that happens in the context of an HTTP endpoint, the following HTTP metadata CEF extensions are logged, if available: httpRequestUri, internalHttpRequestUri, httpRequestMethod, remoteIpAddress, httpRemoteUser, httpSessionId, httpCookies.

This is true for every ARMR rule except for ARMR patch.

Execute ARMR Patch rule​

Apart from the ARMR patch rule, all ARMR rules will create a log event when they execute, unless logging has been intentionally turned off. The patch rule will only log a message if its code block has to be rolled back due to a problem that occurred during execution. The following example shows a log entry generated by a triggered patch rule in which an exception was not caught, hence, as a result, the rule was deactivated:

<9>1 2020-05-11T14:39:23.965+01:00 I-dev05 java 433109 - - CEF:0|ARMR:ARMR|ARMR|2.2|RegistryImpl_Skel|Execute Rule|Very-High|msg=java.lang.Exception outcome=failure procid=433109 dvchost=I-dev05 rt=May 11 2020 14:39:23.965 +0100`

The logging device of this type of messages is the corresponding ARMR mod.

Invalid ARMR Mod Messages​

Just before ARMR mods are linked and loaded they are parsed and verified for syntax errors. A log message of this type is created in the case of an unexpected syntax. The event type used in this case is Syntax Error and the location of the error in the policy file is also shown.

<9>1 2020-07-07T22:18:33.383+01:00 I-dev05 java 1439521 - - CEF:0|ARMR:ARMR|ARMR|19.0.1|Engine|Syntax Error|Very-High|rt=Jul 07 2020 22:18:33.377 +0100 dvchost=I-dev05 procid=1439521 msg=at line 15, col 1: extraneous input '' expecting {'endapp', IDENTIFIER} reason=Error loading ARMR App at line 14 : app("CVE-2013-1537"):`

These types of message are always logged with a Very-High severity as no ARMR mods can load before the syntax is corrected. The logging device of this type of messages is the Waratek Agent.

ARMR Events on Demand​

Additionally, log events can be created by using the ArmrEvent API. These calls are made from the code block section of the patch rule. The following is an ARMR mod with a patch rule illustrating the usage:

app("CVE-2013-1537"):
requires(version: ARMR/2.2)

    patch("CVE-2013-1537_01"):
        function("sun/rmi/server/MarshalInputStream.<clinit>()V")
        write("sun/rmi/server/MarshalInputStream.useCodebaseOnlyProperty")
        code(language : java):
            public void patch(JavaFrame frame) {
              ArmrEvent event = ArmrEvent.load("Execute Rule", "Low");
              event.addExtension("msg", "logging from rule");
              event.commit();
            }
        endcode
    endpatch

The corresponding log entry:

<14>1 2020-07-07T22:19:08.528+01:00 I-dev05 java 1439667 - - CEF:0|ARMR:ARMR|ARMR|2.2|CVE-2013-1537_01|Execute Rule|Low|rt=Jul 07 2020 22:19:08.527 +0100 dvchost=I-dev05 procid=1439667 msg=logging from rule

The logging device of this type of messages is the corresponding ARMR mod.

Informational Messages​

The agent would log events alerting the user while executing invalid or incorrect configurations. Generally, these log entries are logged using the Reload Rules event type.

When the ARMR policy file configured through the com.waratek.rules.local system property is removed from the filesystem and the auto-reload functionality is enabled:

<14>1 2020-07-07T22:42:07.528+01:00 I-dev05 java 1442522 - - CEF:0|ARMR:ARMR|ARMR|19.0.1|Engine|Reload Rules|Low|rt=Jul 07 2020 22:42:07.527 +0100 dvchost=I-dev05 procid=1442522 msg=Waratek rules file '/tmp/test.armr' defined in 'com.waratek.rules.local' does not exist or is inaccessible. No security rules were loaded!

When using the com.waratek.rules.dir system property and the specified ARMR mods directory does not exist:

<10>1 2020-07-07T22:42:40.455+01:00 I-dev05 java 1442715 - - CEF:0|ARMR:ARMR|ARMR|19.0.1|Engine|Reload Rules|High|rt=Jul 07 2020 22:42:40.449 +0100 dvchost=I-dev05 procid=1442715 msg=Configured rules directory "/tmp/test.armr" does not exist

When using the com.waratek.rules.dir system property and extraneous files (.armr extension) are detected inside the specified ARMR mods directory:

<10>1 2020-07-07T22:42:40.455+01:00 I-dev05 java 1442715 - - CEF:0|ARMR:ARMR|ARMR|19.0.1|Engine|Reload Rules|High|rt=Jul 07 2020 22:42:40.449 +0100 dvchost=I-dev05 procid=1442715 msg=Configured rules directory contains unexpected file: /tmp/jvc.rules

The logging device of this type of messages is the Waratek Agent.