Syspeace’s way of detecting Windows logon failures is based on using the audit events produced by Windows. This is reliable and non-invasive, but in some cases, there are oddities.
When a login succeeds or fails during Remote Desktop/Terminal Services authentication, the event is logged, but there is no reference to the IP address of the remote computer. This is due to fairly new authentication with the TLS/Negotiate layer. Without this, Syspeace would not know who to block in case the login failure is part of a pattern that would be blocked.
There are workarounds like using the RDP Security Layer (an older way of authenticating) to force Windows to use another piece of code that will include the IP address information, but lots of our customers do not wish to use this.
Syspeace 2.7.0, brings a comprehensive solution to this problem.
The solution for Windows Server 2003
In Windows Server 2003, only RDP Security Layer (the older way of authenticating) is available, and therefore the problem does not occur. In Windows Server 2016, the oddity has been fixed – the event does include the IP address once again, and therefore the problem does not occur.
The solution for Windows Server 2012 and 2012 R2
In Windows Server 2012 and 2012 R2, the oddity can be easily corrected since the missing information is present in different logs. Syspeace has all the information it needs by reading supplemental events. Our algorithm for doing this is improved in Syspeace 2.7.0.
The solution for Windows Server 2008 and 2008 R2
The solution for Windows Server 2008 and 2008 R2 is open a network socket. Then literally listen to all the incoming packets, filter down to the packets on the RDP port and extract the information about the relevant IP address out of the structural header information. It is a bit roundabout, but it provides us with the hints we need to supply the IP address.
Syspeace can use the strategy above with these caveats:
- You must opt in by turning on a setting called “Traffic-based Remote Desktop/Terminal Services IP detection“. You must turn this level of protection on for yourself. It is not turned on by default.
- The code that does this runs in another process, Syspeace.SpecialRdpDetector.exe, both for isolation and performance reasons. If you turn off the setting, the process shuts down. If you turn on the setting, it starts back up again. It is there to do this one job. If you so wish or deem necessary, you can delete this executable and prevent it from ever being used. (If you do, the setting will naturally be disabled.)
- Syspeace.SpecialRdpDetector.exe is not obfuscated. If you so wish or deem necessary, you can verify that the code does what we say it does.
- In fact, the code for Syspeace.SpecialRdpDetector.exe is available upon request.
This is our way of being pragmatic about this issue while tending to the needs of our customers.
As a security product, we need to do things that require administrative privileges and having deep access to our customers’ systems. But we take great care to be as non-invasive as possible and never help ourselves to information that does not directly advance the cause of protection.