Some hosts have errors in their UTC times

[Iateautumn]

Hello, after a successful build, I found that the times on various hosts are not synchronized, and some hosts have significant errors in their UTC times. Is this intentional or is it supposed to be this way? Additionally, I noticed that two router hosts have ntp service configurations that prohibit hosts in certain subnets from sending time synchronization requests. Is this intentional? What is the purpose of this configuration?
Thanks.

[ru37z]

Hi Vio1et,

thank you for pointing out this issue! It is not intentional.

If I remember correctly, the Internet Router should act as the NTP server of the Company Router, which then provides the time to all machines within the company network. This worked for us most of the times, however, we also experienced multiple test runs where time sync did not work correctly - this is why we marked all NTP system tests as "unstable" (see here and here).

Could you maybe run these NTP system tests and/or give us more detailed info on a potentially flawed config? Thanks!

[Iateautumn]

Hello ru37z

I apologize for the late reply. I’ve been quite distracted by a large number of tedious tasks lately.

Regarding the issue I mentioned earlier, I found that after building these Linux machines, they didn’t synchronize their time immediately. However, they corrected their time after a while. I speculate that the NTP server needs some time to boot. On the other hand, the time on Windows is still incorrect. For example, if our timezone is +8 and the timezone of Windows is +2, the time in Windows shows our real time instead of the time in timezone +2. This leads to incorrect timestamps in Winlogbeat. Although it seems I can solve this problem by modifying the time in Windows, I still wonder if this is the correct approach.

Additionally, I encountered another problem where all emails sent to Attacker (dummy) by Postfix in the DMZ server failed. The externalmailhandler service reported two errors:

error: uncaptured python exception, closing channel <smtpd.SMTPChannel connected 172.18.0.2:53678 at 0x7f2a9e2b5970> (<class 'TypeError'>:process_message() got an unexpected keyword argument 'mail_options' [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|420] [/usr/lib/python3.9/asynchat.py|handle_read|171] [/usr/lib/python3.9/smtpd.py|found_terminator|386])

error: uncaptured python exception, closing channel <smtpd.SMTPChannel connected 172.18.0.2:53738 at 0x7f5f67550b50> (<class 'TypeError'>:initial_value must be str or None, not bytes [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|420] [/usr/lib/python3.9/asynchat.py|handle_read|171] [/usr/lib/python3.9/smtpd.py|found_terminator|386] [/usr/bin/external_mail_handler.py|process_message|73] [/usr/bin/external_mail_handler.py|mime_string_to_text_mail|99] [/usr/lib/python3.9/email/__init__.py|message_from_string|38] [/usr/lib/python3.9/email/parser.py|parsestr|67])

I finally solved the problem by modifying the line mail = mime_string_to_text_mail(data) in the function process_message in externalmailhandler.py to mail = mime_string_to_text_mail(data.decode('UTF-8')) and changing process_message(self, peer, mailfrom, rcpttos, data) to process_message(self, peer, mailfrom, rcpttos, data, **kwargs). After these changes, there were no emails left in the DMZ when checking with the mailq command in the shell. I wonder if this issue is due to an incorrect build, but I didn’t make any modifications to them. The Python version on the attacker is 3.9.8. Do you have any ideas about this?

Thanks!

[ru37z]

Thanks a lot for the details! We'll look into that, give us a few days. 🙃

[ru37z]

Wrapping up:

• All Linux machines seem to perform time sync correctly, though it might take some time after booting.
• The mentioned email bug has been fixed in v1.3.7.
• Time sync of the Windows client remains buggy. We won't examine this issue further due to limited time. If someone finds a solution please open a pull request.