We are proud to announce that we now offers discounts to qualifying educational institutions. This joins our existing discounts to tax-exempt nonprofit organizations.
For more information on either of these discounts, contact us.
Syspeace 2.7.0 is a highly recommended update.
- It introduces improved support for detecting RDP login failures where the IP addresses are missing in the event log entries. For details, see the separate post A comprehensive approach to detecting RDP login failures.
- It includes a setting to mitigate repetitive “success” login entries on file servers caused by file server activity instead of authentication.
- It improves compatibility, including using TLS 1.2 when .NET Framework 4.5 or later is installed – a PCI requirement.
- It includes the ability to export entries out of and import entries into the local blacklist via copy and paste.
- Last but not least, it fixes several issues, including an issue that caused the Syspeace database to be larger than it needed to be.
Syspeace 2.7.0 runs on Windows Server 2003, 2008, 2008 R2, 2012, 2012 R2 and 2016.
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 during authentication with the TLS/Negotiate layer (a newer way of authenticating), the event is logged, but there is no reference to the IP address of the remote computer. 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 our customers are finding that they don’t wish to use this.
Syspeace 2.7.0, available today, brings a comprehensive solution to this problem.
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.
In Windows Server 2012 and 2012 R2, the oddity can be fairly easily corrected due to the fact that 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.
This leaves Windows Server 2008 and 2008 R2, where there are no supplemental events. What are we to do?
There is a solution that is very roundabout, but that nevertheless provides us with the hints we need to be able to supply the IP address. That solution is to open a network socket and literally listen to all the incoming packets, filter down to just the packets on the RDP port and extract the information about the relevant IP address out of the structural header information.
So starting with Syspeace 2.7.0, Syspeace will be capable of using 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 are able to 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 will need to do things that require administrative privileges and having deep access to our customers’ systems. But we are always careful to be as non-invasive as possible and to never help ourselves to information that does not directly advance the cause of protection. We aim to do the minimum possible work to get the job done and we aim to treat our customers and their servers with respect, and provide the product that behaves in the way that we, as customers, would like it to behave.
As of today, September 2, 2016, we have switched to using a SHA-2 SSL/TLS certificate for this web site, our Syspeace Licenses site used to manage and purchase licenses, as well as our backend server used by the Syspeace application. The SHA-2 hash algorithm is a newer and more robust hash algorithm than SHA-1, as previously used – SHA-1 has been globally deprecated for years, and since the beginning of 2016, no new SHA-1 certificates are issued by trusted Certificate Authorities.
SHA-2 is unsupported in Windows Server 2003 and 2003 R2, leading to the following:
- Syspeace users on Windows Server 2003 will have to upgrade to a special Windows Server 2003 variant of Syspeace 2.6 that uses a self-signed, privately issued SHA-1 certificate to maintain the current functionality. This version, along with a special information page, has been available for weeks and we have contacted the affected Syspeace users with this information.
- Access to any of the affected web sites may be restricted from the versions of Internet Explorer compatible with Windows Server 2003. We recommend using an alternative browser like Chrome or Firefox, or a different computer.
For these reasons, the renewal to the new certificate was done at the last moment (our previous certificate expires on September 3, 2016), to give our customers more time to adjust.
We are proud to announce that we now offer discounts to tax-exempt nonprofit organizations (for example 501(c) organizations in the US). For more information, contact us.