TLS 1.2 IIS Log Fields

[rferebee]

Hello,

We updated our systems to use TLS 1.2 and for the servers we were monitoring IIS on it has added 4 additional fields to the W3C logs.

Log Server doesn't know what to do with them and thus has created a 78+/-GB local log file on my Exchange Servers.

I have the names of the fields ready to add to my config file, but I don't know whether they are strings or integers. I've been searching online for 2 hours and I can't find anything.

Can you folks tell me?

Here are the new fields being logged by IIS: crypt-protocol; crypt-cipher; crypt-hash; crypt-keyexchange

Thank you.

[mbellerue]

The first thing I want to nail down here is this 78GB file. I'm not sure under what circumstances Log Server would create a log file on another server, and I don't think Log Server has any mechanism (short of the backup process) to put data on another server. What about the log file identifies it as being from Log Server?

As far as processing the new TLS fields. Each of the fields you listed off are going to be strings. Is Log Server receiving these logs currently, and just isn't putting them in the correct category? Or are they just not making it to Log Server at all?

[rferebee]

So, we actually saw this issue back in March. You can reference the thread I started: https://support.nagios.com/forum/viewto ... 38&t=52799

I think what's happening (long story short), whenever Log Server is presented with an IIS log that has a field it's not expecting it creates an error entry in it's local log. With the number of IIS logs we get, this can amount to a lot off errors in the Log Server log.

It's the nxlog.log file stored here: C:\Program Files (x86)\nxlog\data

[cdienger]

I assume you're seeing simliar messages in the nxlog.log on the Windows machine then? This log/behavior isn't directly associated with anything on the log server side of things - it is NXlog that defines expected field and field types in lines like:

Code: Select all

    Fields             $date, $time, $sitename, $computername, $s-ip, $cs-method, $cs-uri-stem, $cs-uri-query, $s-port, $cs-username, $c-ip, $cs-version, $csUser-Agent, $cs-cookie, $cs-Referer, $cs_host, $sc-status, $sc-substatus, $sc-win32-status, $sc-bytes, $cs-bytes, $time-taken
    FieldTypes         string, string, string, string, string, string, string, string, integer, string, string, string, string, string, string, string, integer, integer, integer, integer, integer, integer

If new fields are added to the log, then this configuration must be changed. Assuming the new fields are at the end, it would look something like:

Code: Select all

    Fields             $date, $time, $sitename, $computername, $s-ip, $cs-method, $cs-uri-stem, $cs-uri-query, $s-port, $cs-username, $c-ip, $cs-version, $csUser-Agent, $cs-cookie, $cs-Referer, $cs_host, $sc-status, $sc-substatus, $sc-win32-status, $sc-bytes, $cs-bytes, $time-taken, crypt-protocol, crypt-cipher, crypt-hash, crypt-keyexchange
    FieldTypes         string, string, string, string, string, string, string, string, integer, string, string, string, string, string, string, string, integer, integer, integer, integer, integer, integer, string, string, string, string

[rferebee]

Correct, the only errors we see are in the nxlog.log file. No where else.

I think, and correct me if I'm wrong, unless all the fields being "sent" from IIS to NXlog are defined in the .conf file then it doesn't know what to do with the log. It's expecting specific fields in a specific order and unless it gets them it creates an error log in the nxlog.log file.

At least that's what appears to be happening. I've never seen a log file could grow that large that quickly without a bunch of continuous errors.

[cdienger]

That seems to be what is happening here. Updating the config should allow it to match the fields in the logs and avoid the error that is getting repeated and taking up so much space.

[rferebee]

I think we've got this figured out, so go ahead and lock this thread. Thank you.

[mbellerue]

Excellent! Glad you were able to get it sorted! Closing thread.