Java Jive
2023-09-25 16:03:36 UTC
In Sept 2021 a user posted here about some SChannel messages appearing
in his System Event log every 6 hours. Between Paul, myself, and
himself, we eventually nailed it to a rogue piece of software/malware
which he uninstalled and so cured the problem. The following
documentation was crucial in determining that, then as now, it was an
outgoing, rather than an incoming, attempt which failed:
TechNet documentation:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786445(v=ws.11)
Schannel Events
Event ID 36887: A Fatal Alert Was Received
The TLS alert sub-protocol uses messages to indicate a change in status
or an error condition to the peer. There are a wide variety of alerts to
notify the peer of both normal and error conditions. Alerts are commonly
sent when the connection is closed, a message which is not valid is
received, a message cannot be decrypted, or the user cancels the
operation. The IETF specification, RFC 4346 [Link is ...
http://www.ietf.org/rfc/rfc4346.txt
...], contains descriptions of the closure alerts and error alerts.
This alert message indicates this computer received a TLS or SSL fatal
alert message from the server it was communicating or negotiating with.
The error indicates a state in the communication process, not
necessarily a problem with the application. However, the cause could be
how the application, such as a web browser, handled the communication.
The desktop app, using SCHANNEL_ALERT_TOKEN, generates a SSL or TLS
alert to be sent to the target of a call to either the
InitializeSecurityContext (Schannel) function or the
AcceptSecurityContext (Schannel) function. The two alert types are
warning and fatal. With a fatal error, the connection is closed immediately.
Event Details
Product Windows Operating
ID 36887
Source Schannel
Version 6.1
6.2
Symbolic Name SSLEVENT_RECEIVE_FATAL_ALERT
Now I'm getting pretty much the same thing, and, very much as
previously, the problem is trying to determine the target of the
attempted outgoing connection. I've enabled syslogging on my QNAP
server and configured my router, which is running ...
OpenWRT OpenWrt 18.06.4 r7808-ef686b7292 / LuCI openwrt-18.06 branch
(git-19.186.54187-cbc000b) (so quite an old version)
... to send its logs there, and they are being received and visible on
the QNAP, but there was no seemingly useful information the last time
the sequence happened, details of which are appended.
It seems I need to enable more detailed logging on the router. Can
anyone suggest a reasonable compromise between getting enough
information to identify the attempted target of the failed communication
while not bringing the router, a BTHH5a, to its knees by overloading it
with the need to log absolutely everything that is happening, and give
me instructions on how to set the required configuration?
Details (dates converted to iso):
PCs System Event log:
2023-09-25 11:21:34 Service Control Manager 7036 The Software
Protection service entered the running state
2023-09-25 11:21:35 Schannel 36867 Creating an SSL client credential
2023-09-25 11:22:07 Schannel 36887* The following fatal alert was
received: 70.
[Repeated twice more]
2023-09-25 11:25:59 Schannel 36867 Creating an SSL client credential
2023-09-25 11:26:00 Schannel 36880 An SSL client handshake completed
successfully [...]
2023-09-25 11:27:01 Service Control Manager 7036 The Software
Protection service entered the stopped state.
Server's syslog from the router around the same time:
2023-09-25 11:21:25 daemon Notice <router name> hostapd
wlan1:AP-STA-POLL-OK <MAC of bedroom client bridge router>
2023-09-25 11:21:30 daemon Info <router name> dnsmasq-dhcp 2933
DHCPINFORM(br-lan) <problem PC IP> <problem PC MAC>
2023-09-25 11:21:30 daemon Info <router name> dnsmasq-dhcp 2933
DHCPACK(br-lan) <problem PC IP> <problem PC MAC> <problem PC hostname>
2023-09-25 11:26:27 daemon Notice <router name> hostapd
wlan1:AP-STA-POLL-OK <MAC of bedroom client bridge router>
in his System Event log every 6 hours. Between Paul, myself, and
himself, we eventually nailed it to a rogue piece of software/malware
which he uninstalled and so cured the problem. The following
documentation was crucial in determining that, then as now, it was an
outgoing, rather than an incoming, attempt which failed:
TechNet documentation:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786445(v=ws.11)
Schannel Events
Event ID 36887: A Fatal Alert Was Received
The TLS alert sub-protocol uses messages to indicate a change in status
or an error condition to the peer. There are a wide variety of alerts to
notify the peer of both normal and error conditions. Alerts are commonly
sent when the connection is closed, a message which is not valid is
received, a message cannot be decrypted, or the user cancels the
operation. The IETF specification, RFC 4346 [Link is ...
http://www.ietf.org/rfc/rfc4346.txt
...], contains descriptions of the closure alerts and error alerts.
This alert message indicates this computer received a TLS or SSL fatal
alert message from the server it was communicating or negotiating with.
The error indicates a state in the communication process, not
necessarily a problem with the application. However, the cause could be
how the application, such as a web browser, handled the communication.
The desktop app, using SCHANNEL_ALERT_TOKEN, generates a SSL or TLS
alert to be sent to the target of a call to either the
InitializeSecurityContext (Schannel) function or the
AcceptSecurityContext (Schannel) function. The two alert types are
warning and fatal. With a fatal error, the connection is closed immediately.
Event Details
Product Windows Operating
ID 36887
Source Schannel
Version 6.1
6.2
Symbolic Name SSLEVENT_RECEIVE_FATAL_ALERT
Now I'm getting pretty much the same thing, and, very much as
previously, the problem is trying to determine the target of the
attempted outgoing connection. I've enabled syslogging on my QNAP
server and configured my router, which is running ...
OpenWRT OpenWrt 18.06.4 r7808-ef686b7292 / LuCI openwrt-18.06 branch
(git-19.186.54187-cbc000b) (so quite an old version)
... to send its logs there, and they are being received and visible on
the QNAP, but there was no seemingly useful information the last time
the sequence happened, details of which are appended.
It seems I need to enable more detailed logging on the router. Can
anyone suggest a reasonable compromise between getting enough
information to identify the attempted target of the failed communication
while not bringing the router, a BTHH5a, to its knees by overloading it
with the need to log absolutely everything that is happening, and give
me instructions on how to set the required configuration?
Details (dates converted to iso):
PCs System Event log:
2023-09-25 11:21:34 Service Control Manager 7036 The Software
Protection service entered the running state
2023-09-25 11:21:35 Schannel 36867 Creating an SSL client credential
2023-09-25 11:22:07 Schannel 36887* The following fatal alert was
received: 70.
[Repeated twice more]
2023-09-25 11:25:59 Schannel 36867 Creating an SSL client credential
2023-09-25 11:26:00 Schannel 36880 An SSL client handshake completed
successfully [...]
2023-09-25 11:27:01 Service Control Manager 7036 The Software
Protection service entered the stopped state.
Server's syslog from the router around the same time:
2023-09-25 11:21:25 daemon Notice <router name> hostapd
wlan1:AP-STA-POLL-OK <MAC of bedroom client bridge router>
2023-09-25 11:21:30 daemon Info <router name> dnsmasq-dhcp 2933
DHCPINFORM(br-lan) <problem PC IP> <problem PC MAC>
2023-09-25 11:21:30 daemon Info <router name> dnsmasq-dhcp 2933
DHCPACK(br-lan) <problem PC IP> <problem PC MAC> <problem PC hostname>
2023-09-25 11:26:27 daemon Notice <router name> hostapd
wlan1:AP-STA-POLL-OK <MAC of bedroom client bridge router>
--
Fake news kills!
I may be contacted via the contact address given on my website:
www.macfh.co.uk
Fake news kills!
I may be contacted via the contact address given on my website:
www.macfh.co.uk
