Firewall logs target column empty

[jsb 0]

Hello

Today I have noticed the on my machine 'ESET Internet Security' firewall logs target column is empty, even for log entries that previously had this field populated. What is causing this issue? It's quite disturbing, especially since I cannot seem to be able to fix it.

Any helps to fix this this would be much appreciated.

Thank you.

[Marcos 5,074]

Thanks for the heads-up. I was able to reproduce the issue and reported it to developers.

[jsb 0]

Hello

Is this a bug in an update then? When can a fix be expected please?

Thank you.

[Marcos 5,074]

Yes, it's a bug. There is no ETA yet but I expect a fix to be available via an automatic update soon.

[mma64 7]

@jsb "damn it!", you were a little bit faster than I... But the following prepared post was too deep in the night written and I was too tired to post it after finishing it!

19 hours ago, jsb said:

even for log entries that previously had this field populated

I doubt this, more on this later today eventually. This would mean that the bug (thanks for confessing this, @Marcos) would be a log view problem or the like. Fact is, even exporting leaves the "target" field empty after a highly specific point in time!

 

read on, the mentioned prepared posting at full length:

here c & p directly from firewall log view working still...:
19.11.2020 15:53:38;Communication allowed by rule;Allowed;XXXXXXXXXXXXX:XXXXX;XXXXXXXXXXXX:80;TCP;Allow XXXXXXXXXXXXXXXXXXXXX;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;

... today I noticed field "target" always empty, doing the very same c & p as above:
25.11.2020 18:59:31;Communication allowed by rule;Allowed;XXXXXXXXXXXXX:XXXXX;NO-TARGET-FIELD-CONTENT-ANY-LONGER!!!;TCP;Erlaubt XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, 03.12.2018);XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;

conclusion: something very bad happened in between this time frame! But when did this happen exactly?!?

even exporting the firewall log has this very same error now!... (the following one not a current
one, but the FIRST non-working firewall log entry!):

    <RECORD>
      <COLUMN NAME="Time">25.11.2020 18:59:31</COLUMN>
      <COLUMN NAME="Event">Communication allowed by rule</COLUMN>
      <COLUMN NAME="Action">Allowed</COLUMN>
      <COLUMN NAME="Source">XXXXXXXXXXXXXXXXXXX</COLUMN>
      <COLUMN NAME="Target"></COLUMN>                <--- BUG, BUG, BUG: bad, VERY VERY BAD!!!
      <COLUMN NAME="Protocol">TCP</COLUMN>
      <COLUMN NAME="Rule/worm name">Erlaubt XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, 03.12.2018)</COLUMN>
      <COLUMN NAME="Application">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN>
      <COLUMN NAME="SHA1">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN>
      <COLUMN NAME="User">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN>
    </RECORD>

... but I'm able to nail down the bug insertion within a 5 minutes period (without any firewall log
entries in between these two)!:

    <RECORD>
      <COLUMN NAME="Time">25.11.2020 18:54:44</COLUMN>
      <COLUMN NAME="Event">Communication allowed by rule</COLUMN>
      <COLUMN NAME="Action">Allowed</COLUMN>
      <COLUMN NAME="Source">XXXXXXXXXXXXXXXXXXX</COLUMN>
      <COLUMN NAME="Target">XXXXXXXXXXXXX:80</COLUMN>            <--- good!
      <COLUMN NAME="Protocol">TCP</COLUMN>
      <COLUMN NAME="Rule/worm name">erlaubt XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, XX.XX.2020)</COLUMN>
      <COLUMN NAME="Application">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN>
      <COLUMN NAME="SHA1">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</COLUMN>
      <COLUMN NAME="User">XXXXXXXXXXXXXXXXXXXX</COLUMN>
    </RECORD>

somewhat mysterious is the fact that within this time frame there was no EIS update whatsoever?!?:

?Time;Component;Event;User
25.11.2020 13:00:43;ESET Kernel;Detection Engine was successfully updated to version 22377 (20201125).;SYSTEM
25.11.2020 14:54:55;ESET Kernel;Detection Engine was successfully updated to version 22378 (20201125).;SYSTEM
25.11.2020 16:54:55;ESET Kernel;Detection Engine was successfully updated to version 22379 (20201125).;SYSTEM    <--- look at THIS!
25.11.2020 20:54:55;ESET Kernel;Detection Engine was successfully updated to version 22380 (20201125).;SYSTEM
26.11.2020 00:54:56;ESET Kernel;Detection Engine was successfully updated to version 22381 (20201125).;SYSTEM

a summer time / winter time bug (?!?). Here, at my location, we have CET time. And 16:54:55 could be, assuming such a
bug / "issue", very well be 18:54:55 (= +02:00 hours). Timestamps are displayed correctly in
general. But Win7 messes all times displayed up - after switching to for example winter time. Ie.
correctly stored / displayed timestamps in summer time are WRONG after said switching to winter
time. All of them. Eventually forever. They might be correct again during the next summer time.

Now your developers have all informations they need to eliminate this catastrophic bug. As fast as
possible.

@MarcosMay I suggest logging the versions of all modules that are updated during an AV update too?!

Because it can't be the "Firewall module: 1411.3 (20201019)" which is the current one installed on my PC...;
wait a moment, it could very well be this one - because, as you know very well, there's a (huge) gap
between new module versions and the arrival on a user's PC / Laptop / whatever device...

here are the currently installed module versions (EIS V14.0.22):
Detection Engine: 22482 (20201214)
Rapid Response module: 17435 (20201214)
Update module: 1021 (20200218)
Antivirus and antispyware scanner module: 1568.1 (20201207)
Advanced heuristics module: 1203 (20201015)
Archive support module: 1311 (20201125)
Cleaner module: 1214 (20200921)
Anti-Stealth support module: 1168 (20200908)
Firewall module: 1411.3 (20201019)
ESET SysInspector module: 1280 (20201022)
Translation support module: 1833 (20201202)
HIPS support module: 1403 (20201103)
Internet protection module: 1416 (20201120)
Web content filter module: 1079 (20201009)
Advanced antispam module: 7864 (20201027)
Database module: 1112 (20200928)
Configuration module (39): 1914.2 (20201102)
LiveGrid communication module: 1087 (20201204)
Specialized cleaner module: 1014 (20200129)
Banking & payment protection module: 1206 (20201202)
Rootkit detection and cleaning module: 1029 (20200929)
Network protection module: 1685.1 (20201006)
Router vulnerability scanner module: 1071 (20201006)
Script scanner module: 1084 (20201121)
Connected Home Network module: 1040 (20200728)
Cryptographic protocol support module: 1056 (20201113)
Databases for advanced antispam module: 6166 (20201214)
Deep behavioral inspection support module: 1109 (20201013)
Advanced Machine Learning module: 1085 (20201207)
Telemetry module: 1061.1 (20200706)
Security Center integration module: 1026.1 (20201020)

kind regards
 

Edited December 15, 2020 by mma64

[shocked 60]

the "network protection" option shows the firewall logs, right?
mine is completely empty. i suppose this is due to the above-mentioned bug?
the firewall is on automatic mode.

 

Edited December 15, 2020 by shocked

[itman 1,659]

26 minutes ago, shocked said:

the "network protection" option shows the firewall logs, right?

Yes.

27 minutes ago, shocked said:

mine is completely empty. i suppose this is due to the above-mentioned bug?

No.

Network Protection log entries for the most part reflect user created firewall rules for which the logging option has been selected. Overall, the log being empty would be normal.

[jsb 0]

Hello

Regarding log entries that previously had the target field populated now being empty, I am certain this is the case. The target is empty also when hovering over a log.

 

[mma64 7]

3 hours ago, jsb said:

Hello

Regarding log entries that previously had the target field populated now being empty, I am certain this is the case. The target is empty also when hovering over a log.

 

Depending on your level of knowledge this might look so, but I'm pretty sure I haven't made an error in my analysis. Ie. I have exported all firewall (and HIPS logs) since ESET V4 and this is (hopefully - I will check it...) the first time this issue has shown up. The exported log before this bug has all "target" fields populated, and the temporarily exported currrent one has all "target" fields unpopulated! ("25.11.2020 18:54:44" (see previous post) is the last record of the last exported firewall log (as ".xml") and "25.11.2020 18:59:31" (see previous post) the first not yet exported firewall log entry.)

You could check this easily too: go into firewall log view, right click and then "export all...", save as ".xml" (or better, depending on your computer proficiency, as ".txt"), double-click the exported ".txt", look at the first record and at the last: "target" field empty or not?!? Which time period do you have? (I have set all values in EIS V14 to "keep the log(s) forever" of course, ie. EIS V14 : setup : advanced setup : tools : log files : automatically delete records older than ... days".)

an exported ".txt" firewall log looks like this one record:

Time;Event;Action;Source;Target;Protocol;Rule/worm name;Application;SHA1;User
25.11.2020 18:54:44;Communication allowed by rule;Allowed;XXXXXXXXXXXXX:XXXXX;THIS-IS-TARGET-FIELD:XXX;TCP;erlaubt XXXXXXXXXXX, 12.01.2020);C:\...\XXX.exe;SHA-1 hash;USERNAME
 

With some luck you could see both states: records with target field empty and populated. If there are populated ones, hovering them will show its content in EIS firewall log view too, of course - except there's a bug in the log view too!...

This would be an interesting check, if you could do it, please, I can't because - that's really crazy! - I made this last firewall log export about three minutes (!!!) after this AV update occured!

 

[mma64 7]

Wow, a quite fast bug correction, thanks...

Yesterday, 20201216 at 17:06:18 CET the bug fix was installed on my PC. Look at the following screenshot, how this looked like. Immediately I switched to "help : installed components : COPY" or something like this. And when I reentered the firewall log view, all fields "target" were populated! Somewhat strange, but it shows me that the bug can't be in the firewall log file as such but in the firewall log view and the firewall export function.

 

- the installed modules:

Detection Engine: 22492 (20201216)
Rapid Response module: 17445 (20201216)
Update module: 1021 (20200218)
Antivirus and antispyware scanner module: 1568.2 (20201214)
Advanced heuristics module: 1203 (20201015)
Archive support module: 1311 (20201125)
Cleaner module: 1214 (20200921)
Anti-Stealth support module: 1171 (20201106)
Firewall module: 1411.3 (20201019)                  <--- good luck at finding out what module else had the bug, because it's not this one!...
ESET SysInspector module: 1280 (20201022)
Translation support module: 1833.1 (20201216)
HIPS support module: 1403 (20201103)
Internet protection module: 1416 (20201120)
Web content filter module: 1079 (20201009)
Advanced antispam module: 7864 (20201027)
Database module: 1112 (20200928)
Configuration module (39): 1914.2 (20201102)
LiveGrid communication module: 1093 (20201216)
Specialized cleaner module: 1014 (20200129)
Banking & payment protection module: 1206 (20201202)
Rootkit detection and cleaning module: 1029 (20200929)
Network protection module: 1685.1 (20201006)
Router vulnerability scanner module: 1071 (20201006)
Script scanner module: 1084 (20201121)
Connected Home Network module: 1040 (20200728)
Cryptographic protocol support module: 1056 (20201113)
Databases for advanced antispam module: 6176 (20201216)
Deep behavioral inspection support module: 1109 (20201013)
Advanced Machine Learning module: 1085 (20201207)
Telemetry module: 1061.1 (20200706)
Security Center integration module: 1026.1 (20201020)

 

[Marcos 5,074]

Yes, it was fixed in the new version of the Translation support module.