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 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

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.

Troubleshooting Syspeace

An interesting support case came to our attention recently.

A customer claimed that Syspeace wouldn’t block according to the rules.

The bruteforce attacks would continue , even after they should have been blocked.

We checked the ususal culprits (verify that the .Net is fully patched, that the customer is running the latest Syspeace version, verify that logging is enabled and that the firewall is turned on )

The rules were added as expected in the firewall but they didn’t have any effect.

After a lot of troubleshooting the root-cause was found.

The customers server did indeed have the firewall enabled but only in one of the firewall profiles (public, private, domain) and unfortuantely, the network used was not the one the firewall was enabled for, hence, nothing was blocked as expected. The rules were added but did not take effect in the expected amount of time

So, as a general troubleshooting tip , check how your firewall is enabled and verify that it indeed is the correct network profile in there, or, enable the firewall for all three profiles.

The usual troubleshooting tips we give are described in the manual in the troubleshooting section

1. Make sure you’ve enabled the firewall (as described in Firewall), firewall enabled, prefferably on all profiles.

2. Make sure you’ve enabled the auditing (as described in Windows login detection prerequisites).

3. Verify that the server can reach https://s.syspeace.com/ping . (You should see a message saying Hello from Stockholm. and the local time of the server and recommended Syspeace version)

4. In some instances, when running Terminal Server or Remote Desktop Services there’s actually the scenario where the Windows server itself fails to obtain the source IP address of the login attempt (you can verify this by checking the Windows event log and look for Source Network Address: ) Sometimes, that entry is empty, thus disabling Syspeace from actually having anything to block. Syspeace will attempt to corroborate the IP address from some other logs. If it doesn’t find any, there is not much that Syspeace can do.

5. In any applicable firewall or antivirus software, allow Syspeace access to https://s.syspeace.com/ (port 443).

6. Verify any proxy settings, if applicable.

7. Some methods of Windows authentication actually attempts to log in several times. Two failures may be part of one log in attempt. Syspeace has no way of knowing how many attempts were intended and has to work with the actual failures. Due to counting failures instead of attempts, rules may be triggered seemingly ahead of time.

8. One way of quickly verifying functionality is to use a workstation (not whitelisted) and attack your server with the net use command from the command prompt. After the number of tries defined in the current rules, the workstation should be blocked from communicating with the server. Example of the command: net use * \server name or server IP addressanyshare /user:syspeacetester “anypassword”

9. If you want to submit logs to us, start Syspeace, go to Management → System settings, enable logging and start the service. The log file is created in a subfolder of the Syspeace installation folder.

10. When submitting logs,
Please create a .zip file of the logfiles, include any relevant information from Windows Eventlogs (application, system and security and when applicapble, the Syspeace eventlog ) and also create a .Zip-file of the database and email them directly to the devteam . The email address can be found in the manual

11. If your server doesn’t pick up the source IP address in your eventlog , please have a look a this blog article

12. If your database has grown above the size limit of 4 GB, in the current version ( 2.5.2) you will have to manually delete the database and set up your Syspeace again. Please refer to this post on the matter
by Juha Jurvanen

#msexchange Brute force attacks prevention on #Webmail #OWA with #Syspeace #hacking #security

Preventing brute force attacks against Microsoft Exchange Server and OWA Webmail

If you’re running Microsoft Exchange Server your also quite likely to have the Microsoft Exchange OWA (Webmail)
interface up & running to enable your users to use Activesync and access their email, calendars and contacts
over an easy-to-use web interface accessible over the Internet. This is just as relevant if you’re managing your
own Exchange Server or if it is a hosted Exchange at a service provider. If your provider doesn’t have a
solution for this, you may find yourself in a very difficult situation one day as explained further down.
Since the Exchange Webmail (OWA) is reachable and visible over the Internet, this of course also means that
anyone is able to try to log in to your Exchange server over the same OWA interface. They may not succeed to
login but they may try to overload your server by sending lots of login request or have your users undergo a
Denial of Service attack (a DoS attack).

Brute force attacks used as Denial of Service attacks

The OWA in itself (or does Windows Server for that matter) doesn’t have any brute force prevention mechanisms
built into it but the actual user validation is done within the Active Directory infrastructure by your domain
controller(s). Within the Microsoft line of products this is actually true for most of them such as Terminal
Server (RDS, Remote Desktop), Sharepoint, SQL Server and so on and also for Citrix since user validation is done
in the same way.
If you have for instance set up Account Lockout Policies to disable a user account after 5 failed attempts ,
anyone with knowledge of your name standards (email addrees, AD login) can basically run a script against the
server using a specicif username (or hundreds of them) and deliberatley usoing wrong passwords, thus locking the
legitimate users account and disabling them from loging in at all (in essence, they can’t even login to anything
that uses the Active Directory validation, not even their own workstations in the Office)
If such an attack is made from a single IP address, it is fairly easy to block it manually (simply block the
attack in either the external firewall or the local firewall of the Exchange server).
In reality though, this is not how such an attack occurs. Should someone really want to disrupt ypur services,
they will do this from hundreds or thousands computers at the same time and making it impossible to block

Using Syspeace as a countermeasure

With Syspeace , this is all taken care of automatically. Syspeace monitors the Windows Serevr logs for failed
login requests and if an IP address tries to login against your servers ( Exchange, Terminals Server and so on)
and fails for instance 5 times within half an hour, the IP address is automatically blocked from communicating
at all with the affected server on any level (so if you’re also running other services , they will not be able
to target them either once blocked).
Each attack is blocked, traced and reported via email that contains the source IP address, the username used,
country of origin and previous attacks from the same IP address.

Here is actually an example of how the email notification looks like (with IP address and domain name intentionally removed)

Blocked address *.*.*.* (ip-*-*-*-*.*.secureserver.net) [United States] 2015-01-14 18:45:00 Rule used (Winlogon):
	Name:			Catch All Login
	Trigger window:		4.00:30:00
	Occurrences:		5
	Lockout time:		02:00:00
	Previous observations of this IP address:
	2015-01-14 16:44:50	****lab
	2015-01-14 16:44:52	****labroator
	2015-01-14 12:53:44	****ron
	2015-01-14 12:53:46	****demo
	2015-01-14 12:53:48	****canon

Syspeace also delivers daily and weekly reports of blocked threats.

Within Syspeace, there is also reporting tools for access reports, a Global Blacklist for infamous offenders and
much more.

Installing and setting ups Syspeace

Setting up Syspeace is very easy and only takes a couple of minutes, without the need for changing your
infrastructure or bying very expensive dedicated hardware. Most likely , you will not even need to hire a
consultant for it.

Syspeace runs as Windows Service and support a variety of Windows Servers such as Terminal Server, Exchange Server, Sharepointm Windows Serevr 2003 to Windows Serevr 2012 R2 and more and it starts detecting brute force attacks immediately after you set it up and press the start button.

Please download a free, fully functional 30 day trial and see for yourself how a very big problem can be very easily solved.
Should you decide to keep using Syspeace, the licensing cost is equivalent to an antivirus product and the
licensing model is highly flexible, enabling you to decide for yourself ofor how long you wish to run Syspeace.

Syspeace, SHA-2 certificates and Windows Server 2003

Recently, the SSL certificate used for syspeace.com, the Syspeace Licenses site as well as backend Syspeace services was reissued with a signature using the SHA-2 hash algorithm.

The SHA-2 hash algorithm replaces the earlier, deprecated SHA-1 and moving forward is recommended by the CA Security Council.

However, some users on Windows Server 2003 have seen issues using the new certificates, due to Windows Server 2003 as shipped not being able to work with SHA-2 certificates. For this reason, we are reissuing our SSL certificate, now again using the SHA-1 hash algorithm.

We intend to once again move to SHA-2 when it is feasible to do so.

#infosec How to block an ongoing dictionary attack / brute force attack against Windows Servers, #MSexchange and more

How to block an intrusion attack against Windows Servers for free

If your server or data center is targeted by a brute force attack a.k.a dictionary attacks , it might be hard to figure out how to quickly make it stop.
If the attack is from a single IP address you’d probably block it in your external firewall or the Windows Server firewall and after that start tracking and reporting the attack to see if needs following up.
However, if the attacks is triggered from hundreds or even thousands of IP addresses, it will become basically impossible to block all of them in the firewall so you need something to help you automate the task.

This is where Syspeace comes into play.

Fully functional, free trial for brute force prevention

Since Syspeace has a fully functional trial for 30 days, you can simply download it here, install, register with a valid email address, enter the license key into the Syspeace GUI and the attack will be automatically handled (blocked, tracked and reported) as soon as the Syspeace service starts up.

In essence, the attack will be blocked within minutes from even connecting to your server.

The entire process of downloading, installing and registering ususally only takes a few minutes and since Syspeace is a Windows service it will also automatically start if the server is rebooted.

If the attack is triggered to use just a few login attempts per attacking IP address and for a longer period of time in between attempts, I’d suggest you change te default rule to monitor for failed logins for a longer triggerwindow , for example 4 days so you’d also automatically detect hacking attempts that are trying to stay under the radar for countermeasure such as Syspeace.

The Syspeace Global BlackList

Since Syspeace has already blocked over 3.6 Million attacks worldwide , we’ve also got a Global Blacklist that is automatically downloaded to all other Syspeace clients.

This means that if an IP address has been deemed a repeat offender (meaning that it has attacked X number of Syspeace customers and Y number of servers within Z amount of tme), the attackers IP address is quite likely to already be in the GBL and therefore it will be automatically blacklisted on all Syspeace-installations, thus making it preemptively blocked.

Syspeace does not simmply disable the login for the attacker, it completely blocks the attacker on all ports from communicating with your server so if you’ve got otther services also running on the server (such as an FTP or SQL Server) the attacker will not be able to reach any if those services either. The lockdown is on all TCP ports.

More Syspeace features, supported Windows Server editions and other services such as Exchange Server, Terminal Server, SQL Server …

You will also get tracking and reporting included immediately for future reference or forensics.
Syspeace supports Windows Server editions from Windows 2003 and upwards, including the Small Business Server editions. It also supports Terminal Server (RDS) and RemoteAPP and RDWeb, Microsoft Exchange Serevr including the webmail (OWA) , Citrix, Sharepoint,
SQL Server and we’ve also released public APIs to use with various weblogins. All of this is included in Syspeace. Out of the box.
We’ve got a IIS FTP server detector in beta and also a FileZilla FTP Server detector and we’re constantly developing new detectors for various server software.

Download and try out Syspeace completely free

Even if you’re not being attacked by a large brute force attack right now, you can still download the trial and have Syspeace handle attacks for you in the background. Who knows, there could be more invalid login attemtpts than you think, such as disabled or removed users that have left the company or very subtle, slow dictioanry attacks going on in the background that actaully might be quite tricky to spot if your not  constantly monitoring logfles.

On this blog, http://syspeace.wordpress.com, we’ve written a lot of blog articles on how Syspeace works and a lot of other articles regarding securing your servers that we hope you’ll find useful.

How to battle slowgrind #bruteforce attacks against #msexchange #windows server #remotedesktop #sharepoint with #Syspeace

Syspeace automatically blocks attacks that occur according to the rules.
The default rule is that if an intruder fails to login more than 5 times within 30 minutes, the intruders IP address is blocked, tracked and reported for 2 hours and simply is denied any access to the server.

A new trend though has emerged and that is for bruteforce attackers to “slowgrind” through servers, trying to stay “under the radar” really from IDS/IPS HIPS/HIDS such as Syspeace.
They’ve got thousands and thousands of computers at their disposal so they’ll basically just try a few times at each server and then move on to next one in the IP range or geographical location hoping not to trigger any alarms or hacker countermeasures in place.

An easy way to battle this is actually simply to change the default rule in Syspeace from the time windows of 30 minutes to for example 5 days.

This way , I’m pretty sure you’ll see there are quite a few attackers that only tried 2 or three times a couple of days ago and they’re back again but still only trying only a few times.

With the “5 day” windows, you’ll catch and block those attacks too.

Here’s actually a brilliant example of an attack blocked, using a 4 day window.

Blocked address [China] 2014-08-11 15:06:00
Rule used (Winlogon):
        Name:                   Catch All Login
        Trigger window:         4.00:30:00
        Occurrences:            5
        Lockout time:           02:00:00
        Previous observations of this IP address:
        2014-08-11 13:05:51     aksabadministrator
        2014-08-10 22:06:48     aksabadministrator
        2014-08-10 06:39:12     aksabadministrator
        2014-08-09 15:39:52     aksabadministrator
        2014-08-09 00:32:05     aksabadministrator

Syspeace has blocked more than 3 285 300 intrusion attempts against Windows Servers worldwide so far.