Log format for this log??

SimSamaSimSama
in Firebox - Proxies

<155>Aug 22 14:15:15 Lab01 11140279DD278 M270 (2024-08-22T11:15:15) pxy[2949]: 0x226ab20-665685 160: 192.168.1.25:50440 -> 1.1.1.1:443 [A t] {B}: Accept SSL Error [ret -1 | SSL err 1 | Details: ssl3_read_bytes/tlsv1 alert unknown ca] Domain: subdomain.example.com PFS: ALLOWED | ALLOWED

Hi all, where is the log documentation for this log???
It is coming from an M270 appliance, and we are writing a SIEM parser for it.

I'm assuming this is HTTPS SSL Inspection log, determining that the SSL certificates CA is unknown, which is fine. The key piece is the last field indicating that the proxy allowed the traffic even though the cert CA is unknown? What are the other field options e.g. ALLOWED / DENIED / Other?

I checked the Fireware log reference and did not find anything about this event.

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @SimSama

    The specific ALLOWED | ALLOWED part is related to the PFS rules as set up in the TLS profile for that HTTPS proxy. The other options there would be Required or None.

    See:
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/proxies/general/tls_profiles_about_c.html

    Proxy debug info isn't included in the log catalog, so it won't be in there, but most log messages can be found at https://www.watchguard.com/help/docs/fireware/12/en-US/log_catalog/12_10_Log-Catalog.pdf

    -James Carson
    WatchGuard Customer Support

  • SimSamaSimSama
    edited September 19

    Hi James, thanks for the quick response.

    So after checking the link, makes perfect sense for the first ALLOWED.
    PFS: ALLOWED | ALLOWED

    PFS: (ALLOWED or REQUIRED OR NONE) -- This field I understand now thanks.

    The next field after the | separator (the last ALLOWED) is for what designation however?

    I think is this, but please correct me if I'm wrong.

    PFS: (Client Side PFS Ciphers option) | (Server Side PFS Ciphers option)

    I was initially assuming that the last ALLOWED after the | separator was a different field. Usually in firewall logs there is an indicator if non compliant traffic was permitted to continue or dropped e.g. (ALLOW, BLOCK, DROP, LOG) ? I'm assuming that data is in the usual traffic logs, but was hoping it was also included in this debug log.

    Thanks,

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @SimSama You are correct, the logging is for client/server side. The logging for this was likely recycled from the STARTLS logging for SMTP.

    -James Carson
    WatchGuard Customer Support

  • SimSamaSimSama

    Thanks! Also as a final unrelated question. Is there a way to suggest to the Watchguard development team a standard log format / header for all log types?

    The log formats vary, and would be nice to cleanly identify them such as:
    <147>Y-M-D hostName WatchGuard : key="value" pairs similar to FortiGate logs?

    The problem with the following log types is that they aren't easily disguisable as being a watchguard log, and the formats vary between log sources on the firewall.

    <142>Oct 14 13:20:53 host1 901115973C384 (2010-10-14T18:20:53) smtp-proxy[1952]: Allow Trusted External tcp
    versus

    <140>Oct 6 05:59:59 Name-of-co 901115973C384 (2010-10-06T10:59:59) firewall

    versus

    <148>Oct 18 17:43:24 host1 (2013-10-18T22:43:24) admd[1089]: msg_id="1100-0008" Authentication of Firewa

    The last one for example mixes key="value" with free form message text afterwards. It is more difficult for Cybersecurity vendors to parse these logs and attribute them to Watchguard. Not impossible, just a pita.

    I suppose we could look at LEEF in the interim, but I'm not sure if all log sources support LEEF format, that is another side question.

    At any rate, this is just a suggestion, have a great week and we can close this thread!

Sign In to comment.