Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Security Log Format

    Webapp Secure is configured to log security incidents to mws-security.log. All security alerts should be sent to security.log (previously named security-alert.log). There are different types of security incidents that will be a part of this log: new profiles, security incidents, new counter responses. The following section explains the format of these security log messages.

    • New profile

      <date_utc> <hostname> [<log_level>][mws-security-alert][<service>] MKS_Category="New Profile" MKS_ProfileId="<profile_id>” MKS_ProfileName="<profile_name>" MKS_PubKey="<pubkey>”

    • Security incidents

      <date_utc> <hostname> [<log_level>][mws-security-alert][<service>] MKS_Category="Security Incident" MKS_Type="<incident>” MKS_Severity=”<severity>” MKS_ProfileName=”<profile_name>” MKS_SrcIP=”<source_ip>” MKS_PubKey=”<pubkey>” MKS_useragent=”<user_agent>” MKS_url=”<url>” MKS_count=”<count>” MKS_fakeresponse=”<fake_response>”

    • New counter responses

      <date_utc> <hostname> [<log_level>][mws-security-alert][<service>] MKS_Category="New Counter Response" MKS_ResponseCode=”<response_code>” MKS_ResponseName=”<response_name>” MKS_ProfileId=”<profile_id>” MKS_ProfileName=”<profile_name>” MKS_ResponseCreated=”<created_date>” MKS_ResponseDelayed=”<delay_date>” MKS_ResponseExpires=”<expiration_date>” MKS_ResponseConfig=”<response_config>” MKS_SilentRunning="<silent_running>"

    Field definitions:

    • <date_utc>–The date of the log entry, in UTC.
    • <hostname>–The hostname of the appliance.
    • <log_level>–The importance level of a log entry. Can be TRACE, DEBUG, INFO, WARN, or ERROR.
    • <service>–-The WebApp Secure service that triggered the security log entry. Possible services include:
      • [auto-response]--The auto response service will most likely generate New Counter Response log entries.
      • [traffic-info]-- The traffic information service will usually generate New Incident and New Profile log entries in security.log.
    • <profile_id>–The numerical ID assigned to the Profile that caused the security alert, or the profile ID that received a Response.
    • <profile_name>–The friendly name assigned to the Profile that caused the security alert, or the Profile that received a Response. For example, "Bob 1234".
    • <pubkey>– The Public ID that can be used in conjunction with the Support_Processor to unblock Profiles. For example, "tTtHvXuby4gxNVmPIeIE".
    • <incident>–The name of the incident that triggered this security alert.
    • <severity>–The numerical severity of the incident that triggered this security alert. This can be a number from 0 to 4, inclusive.
    • <source_ip>–The IP the request that generated this alert originated from.
    • <user_agent>–The client's user agent string that generated this alert.
    • <url>–The client's user agent string that generated this alert.
    • <count>–The number of times the profile triggered this incident. This is used for certain incidents to decide whether or not to elevate the profile or increase the responses on the profile.
    • <fake_response>–Whether or not (true or false) the response sent back to the client was a fake one created by WebApp Secure.
    • <response_code>–The numerical code for the response issued. For example, "13007".
    • <response_name>–The friendly name for the response issued on the profile indicated in the alert.
    • <created_date>–The date and time the response was created.
    • <delay_date>–The date and time the response is set to be delayed until.
    • <expiration_date>–The date and time the response is set to expire.
    • <response_config>–The configuration used in this response. Displayed as an XML-like node.
    • <silent_running>–Whether or not this Counter Response was set to be silent with the Silent Running service at the time of activation. Can be "true" or "false".

    Note: Certain Incidents may create more fields in the log entry, helping identify the particular context of the incident. For example, the Hostname Spoofing Attempt incident will add @MKS_hostpattern@ and @MKS_rule@ to the log entry. To learn what context a particular incident includes, navigate to the triggered Incident in the Web UI, and click the Details tab. Each item in the Details table is output in the format @MKS_<detail_item>=<vlaue>@

    Logfile Examples:

    Oct 13 16:33:13 jwas1 [INFO][mws-security-alert][traffic-info] MKS_Category="Security Incident" MKS_Type="Apache Configuration Requested" MKS_Severity="2" MKS_ProfileName="Brett 8356" MKS_SrcIP="" MKS_pubkey="el4urlypSXuRHOM3IoLT" MKS_useragent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36" MKS_url="" MKS_count="1" MKS_fakeresponse="true"

    Oct 13 16:33:13 jwas1 [INFO][mws-security-alert][traffic-info] MKS_Category="New Profile" MKS_ProfileId="3811" MKS_ProfileName="Brett 8356" MKS_PubKey="el4urlypSXuRHOM3IoLT"

    Oct 13 16:33:55 jwas1 [INFO][mws-security-alert][auto-response] MKS_Category="New Counter Response" MKS_ResponseCode="BL" MKS_ResponseName="Block User" MKS_ProfileId="3811" MKS_ProfileName="Brett 8356" MKS_ResponseCreated="2014-10-13 16:33:54.0" MKS_ResponseDelayed="2014-10-13 16:33:54.0" MKS_ResponseExpires="null" MKS_ResponseConfig="<config />" MKS_SilentRunning="true"

    Published: 2015-02-04