Syspeace 3.0 introduces geographical blocking

“Why doesn’t Syspeace let me block based on country?”

We’ve been asked this question many times, and it is always from customers seeing the same thing: Most of the login attempts that end up causing blocks come from countries that have no business being in their servers. Many customers do have international business, but many customers do not, and regardless of this, it does not mean that serving a customer from that country means that they should be able to, say, trigger a Windows login attempt on this server.

We are releasing Syspeace 3.0, which has a new feature called geographical blocking that does exactly this. You set up Country rules, describing which countries that you do not want to allow access to and Syspeace will keep track of this for you, blocking any login attempt from them immediately.

As an example, let’s take our native Sweden. If you set up a Country rule to block Sweden, it does not mean that all of Sweden is blocked from the start. This is not a blacklist. When someone from Sweden attempts to log in in a way that Syspeace could have blocked later on – Windows login, SQL Server, SMTP Exchange – Syspeace will document the login attempt and resolve the country, notice that Sweden is blocked and block the IP address immediately.

Ordinarily, Syspeace would have remembered the login attempt and waited for more attempts in order for the detector rules (patterns of login attempts; “5 failed login attempts in 2 hours”) to trigger. These patterns are customizable by Syspeace users, and are used to give some leeway for mistakes like mistyped, misremembered or expired passwords by legitimate users. By placing a country in a Country rule, you are saying that there are no legitimate users and no legitimate traffic expected from this country, and you give Syspeace instructions to act immediately.

This approach automates exactly the thought our customers were having but could not yet instruct Syspeace to follow. And by not making it a blacklist, it allows for other forms of traffic than those Syspeace detects to be legitimate. If you have a web shop with many Swedish customers hosted on your server (who will never log in to the server), but also a few pesky attackers that happen to be from Sweden, you will not be in a situation where you have to choose between allowing or blocking all traffic from a whole country.

(And, on a more personal note, if you literally block Sweden, the country where we are based and our own backend and license servers are hosted, you will still be able to access our license web site and talk to our backend, because we will not do anything to trigger a login attempt on your server, and we will not have to maintain some secret master whitelist of IP addresses to avoid cutting off our own check-for-updates functionality in the process.)

 

We recently contacted some of the customers who have been asking us for this over time and asked them to test this functionality.

Since testing the country blocking feature of Syspeace, we noticed a dramatic drop in hacking attempts on our server, from around 100 attempts per month to a handful. Whilst Syspeace did a perfectly good job of blocking the attacks before country blocking this new feature greatly decreases the risk of getting hacked. Perfect for those with security concerns.

– Mike Montgomery, MjM Data Recovery

The Country feature of Syspeace is superb. It has taken your software to a really functional level. I am very pleased with the new Country filters.

– drKatz, InfoStatz, USA

 

Syspeace 3.0 also includes improved accuracy, better performance and a smoother user experience. You can see login attempts as they happen with Live observations, setting the rules in the firewall is many times faster and the handling of RDP traffic has been reviewed to be more accurate. These are only a few of the many changes in Syspeace 3.0 – the biggest Syspeace release since Syspeace 2.0.

Syspeace now accepts Bitcoin

On May 22nd, 2010, Laszlo Hanyecz of Jacksonville, Florida bought two pizzas and paid using Bitcoin, a decentralized cryptocurrency. It was the first documented Bitcoin product purchase, and the Bitcoin network now sees about 240 thousand transactions per day.

We are happy to announce that starting today, Syspeace accepts Bitcoin in addition to PayPal and credit/debit cards for purchases of Syspeace licenses.

When you choose to pay with Bitcoin, we convert the amount to Bitcoin (at market rates, rounded to five decimals) and provide a standard Bitcoin payment experience, complete with wallet conveniences like links and QR codes for quickly making the payment. Once payment has been detected by our server, no further action is necessary, and the license is automatically activated when the transaction has been verified on the Bitcoin network (in the blockchain).

Please see the Syspeace Licenses site for more information.

Syspeace now offering discounts for educational institutions

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.

Recent improvements in the Syspeace Licenses site

Syspeace consists of more than the Windows software that you download and run to achieve our Syspeace protection. Customers purchase and manage licenses from the Syspeace Licenses site, and we have recently introduced a few changes worthy of a write-up.

  • Show your license key. You can now click a link to show your license key, to easily copy it into your records or into Syspeace’s Welcome window.
  • Show current license use. In the list of licenses, you can now also show which computers currently have a license use right checked out. The list also shows the number of computers currently using the license.
  • Revoke a license use right for a computer. Syspeace gives you the flexibility to switch computers over the lifetime of your license. With the ability to revoke a current license use right for a computer, you no longer have to wait for the license use right for an outgoing computer to expire before a new computer can receive it.
  • Resellers can now create accounts for customers. This is especially helpful for managed resellers that need to plan out big deployments, but is also useful for public resellers. These accounts already are paired to the reseller, so that the reseller can purchase licenses for them immediately.

In addition to this, we have updated the purchase FAQ to contain more frequently asked questions.

As always, we welcome feedback on every part of Syspeace, including the Syspeace Licenses site.

Syspeace 2.7.0 released

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.

Read the full list of changes or download Syspeace to start a free 30-day trial today or to upgrade.

Syspeace 2.7.0 runs on Windows Server 2003, 2008, 2008 R2, 2012, 2012 R2 and 2016.

A comprehensive approach to detecting RDP login failures

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.

Why Syspeace uses SHA-2 and important notes for Windows Server 2003 users

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.

Syspeace now offering discounts for tax-exempt nonprofit organizations

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.

Syspeace Windows Server 2003 Support Policy

The current major release of Syspeace (2.x) will continue to be supported on Windows Server 2003 and Windows Server 2003 R2. We may introduce major new releases of Syspeace that will not run or be supported on Windows Server 2003 and Windows Server 2003 R2.

Microsoft’s extended support for Windows Server 2003 and Windows Server 2003 R2 ended on July 14, 2015. Our recommendation is that you, if possible, run a version of Windows Server currently supported by Microsoft and install all critical security fixes.

Syspeace not starting due to database too large

Update: This problem is fixed as of Syspeace 2.7.0. Please upgrade to the newest version of Syspeace instead of employing the workaround detailed below.

With the current version of Syspeace the error where the Syspeace GUI can’t be started and Syspeace crashes is due to its database sometimes growing too large.

When the database called SCDB1.sdf  (located in the Syspeace installation directory) grows above its built in limit of 4 GB, Syspeace stops working and the GUI can’t be started, nor does Syspeace block any new brute force attacks.
This is due to a limitations of database growth and the way Syspeace stores entries within the database in the current version.

Solution / Workaround

The easiest way to work around this limitation is to stop the Syspeace service and simply delete the database and set up your rules and settings again. This will mean setting up your whitelists, entering license number, rules and so on.

Preparing for this scenario

It is easy to be prepared for this though. Simply export all of the Syspeace settings using the Syspeace GUI (Export settings/ and click the “Check all” in the top right) and keep the DefaultSettings.syspeaceSettings in the Syspeace installation folder. Remember to do this every time you apply changes to your settings.
This will speed up the workaround / fix from the aspect that you only need to stop the Syspeace service, delete the database that and then restart Syspeace thus having it automatically import all of your settings.

There is also the advantage of being able to distribute the DefaultSettings.syspeaceSettings-file to other servers in case you have multiple installations or you’re planning on expanding your Syspeace usage.

Simply install Syspeace on the next server, copy the DefaultSettings.syspeaceSettings to the installation directory and your configuration is set to the same parameters as the first one, including whitelists, license number, email settings and so on.