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 . (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. (Update: starting with Syspeace 2.7, these attempts can be detected too.)

5. In any applicable firewall or antivirus software, allow Syspeace access to (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

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.

#Syspeace stops due to license server inaccessable on #Windows Server 2003 #infosec

Syspeace service stops due to license server not reachable / inaccessibility on Windows Server 2003

We’ll actually update the troubleshooting section with info for Windows 2003 Servers but here’s why this can occur.

Apparently root certificates are not automatically updated on Windows Server 2003:

The automatic root update mechanism is enabled on Windows Server 2008 and later versions, but not on Windows Server 2003. Windows Server 2003 supports the automatic root update mechanism only partly. (This is the same as the support on Windows XP.) And because the root update package is intended for Windows XP client SKUs only, it is not intended for Windows Server SKUs. However, the root update package may be downloaded and installed on Windows Server SKUs, subject to the following restrictions.

If you install the root update package on Windows Server SKUs, you may exceed the limit for how many root certificates that Schannel can handle when reporting the list of roots to clients in a TLS or SSL handshake, as the number of root certificates distributed in the root update package exceeds that limit. When you update root certificates, the list of trusted CAs grows significantly and may become too long. The list is then truncated and may cause problems with authorization. This behavior may also cause Schannel event ID 36885. In Windows Server 2003, the issuer list cannot be greater than 0x3000.

This can be resolved for Syspeace by manually installing the gd-class2-root.crt certificate from this page:

#infosec #WordPress Syspeace WordPress Reporter – Brute force protection detector for WordPress #owasp #security

Syspeace WordPress Reporter – Brute force protection detector for WordPress by Syspeace

What is the Syspeace WordPress Reporter?

Syspeace WordPress Reporter is used to collect relevant login data from your WordPress pages
login functionality. The collected data is sent to the Syspeace Web Detector which provides
Syspeace with login attempt information. This means that for the WordPress Reporter to work you
must have the Web Detector installed in Syspeace.

To prevent other websites running on the same server from sending login reports a Reporting Token is used in the Web Detector Reporter. A reporting token is a password-like feature that is set in Syspeace settings and that value needs to correspond with the reporting token sent by the Web Detector Reporter. Unless they match, the login report is ignored in Syspeace.

How to install the Syspeace Web Detector PHP Reporter

Download the SyspeaceDetectorSDK-v1 and unzip. The Detectors and addons are free and there are also other detectors provided for you to use in conjunction with web application logins for instance.

How to install:

1. Install the plugin like this:
Put the SyspeaceWordpressReporter.php file in wp-content/plugins/
The file is located in Syspeace\DetectorSDK-v1\Web Detector Reporters\PHP
2. Activate the plugin by going to the plugin tab of the WordPress admin panel, selecting the
Syspeace WordPress Reporter plugin and clicking Activate.
3. Go to the Syspeace Reporter Settings tab that has been added to your admin panel.
4. Set Reporting Token to the Reporting Token set in Syspeace’s settings
5. Set Website to the name of the website
6. Click Update

How to use the Syspeace WordPress Reporter

To use the WordPress Reporter, simply go to Syspeace Reporter Settings and set Reporter Token to
the Reporting Token set in Syspeaces settings and set Website to the site name you want in the log

Once you have implemented the plugin on your website we suggest that you test i
t by making both failed and successful login attempts. You can then verify if the login attempts are recorded by checking the Syspeace Access Log under Settings Access Log in Syspeace.

What the Syspeace Web Detector PHP Reporter requires

The server running WordPress must have Syspeace installed so you would need to be running a selfhosted WordPress on a Windows Server

You will be required to install a Web Detector Provider in Syspeace as mentioned under
What is Syspeace WordPress Reporter

Additional free brute force plugins by Syspeace

In the .zip file there are also other plugins and documentation on how to write your own Syspeace Detectors and our goal is to release more detectors as they’re written by us or by our Syspeace users around the world.

By Juha Jurvanen @ JufCorp

#infosec VPS and #Cloud servers used for brute force attacks and #botnets against #WinServ and #MSExchange

Syspeace - intrusion prevention for Windows servers

Syspeace website

Is your VPS used for brute force attacks?

or I could also have called this post “Do you know whom your VPS is hacking today?”

A trend that has surfaced over the years is to simply hire computer power inte the Cloud in various forms and shapes. The basic idea is to get rid of the hardware and maintenance för servers and have someone else take care of it. Also known as Infrastructure aa a Service or IaaS

The problem is often though that even if you use a hosted VPS you still have to manage it. This is something that a lot of users and companies tend to forget or neglect.

What you’ve basically done is simply get rid of the hardware hassle but you still have to take care of the Windows patching and manage security issues as with any Windows serevr (or Linux för that matter) .

There aren’t that many Cloyd services out there that actually will also manage the security and management aspects of your VPS and you really need to think these things through.

The resaon for this post is that for some time now, a VPS located at a Swedish Cloud Service provider has been trying to brute force its way into quite a few different servers with #Syspeace installed on them.
The attacks, targeted aginst RDP / Terminal Servers servers, Exchange Server and Sharepoint Servers in this case, have been blocked, traced and reported automatically but the big question is whether whoever owns/hires this VPS is actually even aware of what is going on ? Or if it’s hired especially for this purpose? This is actuallt impossible to know.

In this specific case this VPS has been going on and on for a while and it has targeted at least 5 different customers of mine with Syspeace installed and about 12 servers at least.
All attacks have been succesfully blocked, tracked and reported and eventually this VPS will end up in the Syspeace Global Blacklist (GBL) and propagated to all other Syspeace installations around the world and it will be blacklisted for all of them, thus securing them preemptively from any brute force / dictionary attacks from this VPS.

Most likely the Cloud Service Provider doesn’t know what’s going on since it’s not their responsibility really. Maybe the user / customer hirong the VPS does this on pyrpose or they have no idea that the VPS has been compromised and is used for this hacking activity. I juyt donät knoew. All I know is that it has been cinducting a lot of dicitionary attacks lately.

What I’m driving at is that if you decide to start using a hosted VPS, you still have the responsibility to manage it as any other server really.
You need to have it correctly patched, have an antivirus on it, make sure all security settings are correct and you need to monitor activity on it.

You should also ask your Cloud Service provider for intrusion prevention from Syspeace since you basically have no idea what all of the other customers VPS are really doing in your shared network since you hae no control over them.

Most Cloud Service Provers could inplement Syspeace in their various Applications portals or have a Syspeace installed in their prepared images for customers. If your providers hasn’t implemented Syspeace yet, you can simply download it yourself from /free-download/download-plus-getting-started-with-syspeace/

Your “neighbors” at the Cloud Service could be trying to brute force they way into your VPS and you’d probably wouldn’t have a clue if you haven’t turned on logging and installed a brute foce prevention software for Windows servers.

By Juha Jurvanen @ JufCorp

#infosec Securing your #WinServ and #MSExchange with an acceptable baseline security

Securing your Windows Server with a baseline security

In short, to have an acceptable baseline security for any Windows server you need to think all of the things below in this list.
Sadly enough, even if you follow all of these steps, you’re still not secured forever and ever. There’s no such thing as absolute security. That’s just the way it is but you might use this as some kind of checklist and also the links provided in this post.

Syspeace logo

Syspeace logo

Securing Windows Serves with an acceptable baseline security

1. Make sure all of your software is updated with all security patches. This includes the Windows operating system but also Adobe, Java,Office and any software really. This reduces the risk for so called 0day attacks or your server being compromised by software bugs.

2. Make sure you have a good and not too resource intensive antivirus running on everything. Personally I’m a fan of F Secure PSB for servers and workstations for lots of reasons. It’s not just a pretty logo.

3. Verify you have thought your file and directory access structure and that users and groups are only allowed to use and see what they’re supposed to. Setting file permissions is a very powerful tool to secure your server and crucial.

4. Always make sure to read best practices for securing applications and servers and Google for other ideas also. No manual is the entire gospel.

5. Enable logging. If you don’t know what’s happeing, you can’t really react to it can you ? It also makes any troubleshooting hopeless in restrospect.

7. Have a good monitoring and inventory system in place such as the free SpiceWorks at

8. If your server has any monitoring agents from the manufacturer such as HP Server Agents, then install them and set them up with notifications for any hardware events to be prepared.

9. User Group Policies. It’s an extermely powerful tool once you start using it and it will make you day to day operations much easier.

10. If your server is reachable from the Internet, use valifd SSL certificates. They’re not that expensive and any communications should be encrypted and secured as fa as we’re able. Yes, think Mr. Snowden.Think NSA.

11. Disable any unused services and network protocols. They can be a point of entry and for the unused network protocols, you bascially fill your local network with useless chatter that comsume bandwidth. This also goes for workstations and printers and so on.

12. Enforce complex password policies! You won’t be well-liked but that’s not what you get paid for.
If people are having trouble remembering passwords the have all over the world, maybe you could have thme read this and on the topic of online passwords and identities also,

13. Use a good naming standard for user logins. Not just their first name as login or something too obvious. Here’s an old blog post on why

14. Backups! Backups! and again. BACKUPS!!
Make sure you have good backups (and test them at least once a year for a complete disaster revovery scenario) and make sure you have multiple generations of them in case any of them is corrupted, preferrably stored offsite in some manner in case of a fire, theft or anything really.
For day to day operations and generation management I highly recommend using the builtin VSS snapshot method but never ever have it instead of backups.
You can also use the built in Windows Server backup for DR as described here

15. You need to have an automatic intrusion protection against brute force and dictionary attacks with Syspeace since the “classic” methods do not get the job done. Here’s an older blog post on why . I you don’t have the time to read the article then simply download the free Syspeace trial, install it and you’ve set up a pwerful and easy to use bruteforce prtection for your server in minutes.

If you’re up for it, I’ve written a few other related posts here:

By Juha Jurvanen @ JufCorp

#Infosec When and where is Syspeace useful for intrusion prevention ?

In what scenarios Syspeace is useful for preventing brute force attacks? Do I need it if I’ve only got a Windows workstation?

Syspeace - intrusion prevention for Windows servers

Syspeace website

Syspeace is an intrusion prevention software mainly targeted for Windows Servers, SBS Server, RDS TS Servers, RDWeb, Sharepoint Servers, SQL Server, Exchange, Sharepoint, Citrix and so on but it will also run on Windows 7 and above for home use.

To have a real use for Syspeace these conditions need to be met

1. You need to have enabled remote access to your server / workstation.

2. You need to have set up some kind of portforwarding in your external firewall to your server / workstation. If you are for instance on a standard broadband connection and you haven’t done anything with the default rules in your boradband modem, your workstation is probably not reachable from the Internet thus making a Syspeace installation quite unecessary and waste of RAM and COPU for you, minimal of course but still. There is no need to have software installed in any computer environment that actually doesn’t do anything for you. It’s a waste of resources.  

3.The same goes for servers although in a server environment you might want to have Syspeace installed to monitor and handle internal brute force attacks since Syspeace works just as efficently whetheter the attack is externla or internal. It will even block a workstation trying to connect to netowrk shares via the command prompt using “net use * \servernamesharename” command. Have a look at his entry for instance

4. There could be a scenario where you have for instance your own hosted WorPress Blog that is reachable from the Internet . Please refer to for an idea on brute force prevention for WordPress Blogs.

5. In server envirenments you might have Syspeace installed not only for intrusion prevention but also to have a good reporting on various user login activity that can be viewed and exported in the Access Reports Section.

6. If you’re using mainly Cloud Services or a managed VPS ,the intrusion prevention should be handled by your Cloud Service Provider . Here’s an older blog post on how to have verify how your provider handles hacking attacks :

There is a fully functional, free 30 day trial for download at /free-download/download-plus-getting-started-with-syspeace/ .
Give it a try and have your Windows Server instantly protected from dictionary attacks and brute force attacks. The installtion is small, quick and very easu to set up. You’re up & running in 5 minutes and there’s no need to chnage your current infrasctructure, invest in specific and usually expensive hardware or hire external consultants.

By Juha Jurvanen @ JufCorp

A walkthrough of getting #Syspeace licenses and how it works

Getting #Syspeace licenses and how it works.

From time to time we get an email from customers that have bought their Syspeace licenses and they ask for the license key that they expect to get in an email.

Here’s a walkthrough of how #Syspeace licensing actually works.

First you install a #Syspeace trial, register a valid email address and choose a password password (this is done in the initial setup of SysPeace ).

The license key is then email to that mailaddress.
This is the key that will also become the live license when you buy the license, There is no separate license key mailed to you if you purchase licenses.

Once you purchase the license, the Syspeace client will automatically be updated upon the next contact with the license server when it requests a new token to validate the license or the next time it is restared.

If you want to extend your Syspeace license to be valid for more servers, simply login to the Syspeace licensing page and extend your license and install Syspeace on the next servers , using the same license key.

When you extend the license, you also have to ability to align license renewals to fit your needs. As an example, if you bought a Syspeace license in april for 3 #Windowsservers and two months later you install an additional server. The easiest way is to extend the running license and simply adding a fourth server. This way you don’t have to have an administrative nightmare in order to rememember various license renewals for diferent servers.

If you’ve bought your license through a reseller such they’ll manage all of the administration for you.

Have a try for yourself and download a free, fully functional trial of Syspeace and have your #Windows #Server, #Exchange and #OWA , #SQL , #Citrix , #Terminal #RD #RDweb , #Sharepoint and more automatically #intrusion protexted in a minute.

#bruteforce attacks and #dictionary attacks blocked, tracked and reported.

So far , #Syspeace has blocked 2 042 900 #intrusion attempts worldwide!

By Juha Jurvanen – Syspeace reseller at JufCorp and independent IT Consultant

Syspeace for internal brute force protection on Windows Servers

After installing Syspeace , the tech guys started getting notifications that their Exchange Server was trying to login to another server and it was rejected. There was no reason for this server to do so whatsoever and it had not been noticed earlier so it’s hard to say when it actually started.

After disabling the whitelist for the LAN at the customer site they started getting mail notifications that every workstation on their LAN was actually trying to login to various servers using various usernames and password, hence a brute force attack/dictionary attack from the inside.

Most likely a trojan has been planted somewhere and it has infected the rest.

This is a fairly simple example of how Syspeace can actually reveal a security breach a customer wasn’t even aware of had occured.

It is totally up to any customer to use whitelists for the LAN but as a precaution, I personnally wouldn’t recommend it since it acutally gives you a great heads up that something has happened if a computer or multiple computers suddenly starts to try and login to servers they’re not supposed to.

As a system administrator, you get the chance to get attack automatically blocked, logged, traced and reported and you can have a closer at the computer responsible for the attack or have a word the user to see what’s going on.

You can even create extensive reports on all activity originating from that user or computer using the Access Reports section in Syspeace to get a more clear view on how long it’s been trying and so on.

Since Syspeace automatically protects failed logins using Winlogon authentication, your Windows servers are also protected from computers/users trying to use the “net use” or “map network drive” with invalid logon credentials trying to acces shares they’re not supposed to.

If you don’t have processes in place for scanning logs, saving them and monitoring every login activity, it will become grusome task to even know if there’s something going on at all. You simply won’t have the tools to do so.

Have your own servers run the fully functional Syspeace free trial and see if you get any unexpected login failures from the internal network and from Internet.
You might be surprised.

By Juha Jurvanen

Using various brute force and dictionary attack prevention methods to prevent hackers – and why they don’t work . Repost

This is actually a repost on a fairly well read blogpost but I thought I’d share it with you again.

Intro on brute force / dictionary attack prevention tactics and some common misconceptions

Protection from brute force attempts on Windows servers has always been a nightmare and would continue to be so if not .. Yes, I admit, I will come up with a solution further down.

Most system administrators with selfrespect start off with the best of intentions to actually keep track of brute force / dictianary attack attempts but eventually give up because of the sheer number of attacks that occur daily.

Others, unfortunately, believe that a firewall takes care of the problem which it doesn’t or that an account lockout policy is the answer. Neither of them is and I’ll show you why.

The firewall approach:

Think about it. What does a firewall actually do ? The role of the firewall is to block traffic on unwanted ports and to drop portscans and variuos SYN FLOOD attacks. That’s about it. A firewall is basically a harsch doorman deciding who gets in to speak with the guys on the inside and who doesn’t.

If an attacker actually connects on a valid port , the traffic is redirected/port forwarded to the server in question let’s say the webmail interface of a Microsoft Exchange Server or a Microsoft Windows Terminal Server or a Citrix Server. Once the attacker is there, the actual logon request is handled by the server,not the firewall. The logon process is managed by the Windows Authentication process (which in turn may be validated against Active Directoy or a local user database using SAM). The firewall is already out of the picture really since it has no connection with the Windws server apart from  the TCP connection and keeping it alive really. They don’t communicate the result of the logon process between eachother.

Also, a changing of from standard ports won’t help you much, will it ? The logon process is still managed by the Windows Server although you will get rid a of a lot of portscans and “lazy background, script kiddie attempts” if you’re using non standard ports. Basically you get rid of the script kiddies but the problem isn’t solved, the traffic is still redirected/port forwarded to the server that does the actual authentication.

Using for instance a Remote Desktop Gateway won’t handle the problem either. Using a RDP Gateway minimizes the attack surface, yes, but it is still reachable and the user logons still have to be validated. The problem is with any server that services logon request basically, regardless of on what ports and how they get there. That is Microsoft Windows server, Exchange Server, Citrix, Sharepoint, CRM , Terminal server and so on . The list can probably go on and on.

There’s also the risk of stuff stops working each time you apply some updates or patches to your Windows Servers if you start changing standard ports or standard configurations. It’s happened to me a few times and it’s not that amusing to be honest when you’ve got 1000 users not being able to log in beacuse you’ve just done your job and patched the servers to keep peolpe datas safe. Trust me, that’s not a good Monday morning.

The VPN approach:

Yes. That’s a safer approach but also here we do have some issues. First of all, it’s not that easy to keep track of VPN certificates, to set all of it up and manage all the licensing costs (that can be quite significant really ) and (sometimes costly) hardware you need to have in place. Historically there has also always been performance issues with most VPN solutions since all traffic is directed through one or a few VPN servers / connectors. Some of them also charge you for the bandwidth you want it to be able to use for VPN connections or charge you for the number of simultaneous VPN connections, A VPN solution can be quite costly as an initial investment and taking into account all of the administration involved in it.

You also probably won’t be demanding your users to have a VPN connection to the Microsoft Exchange OWA etiher snce the whole idea of the OWA i that it’s supposed to easy to reach from anywhere. I know there are some companies actually requiring VPN even for OWA and that’s just fine I guess but the more we’re moving our data and applications to cloud services, this hassle with different VPNs and stuff will eventually be fading into the dark corners of the Internet (that’s my personal belief anyways). The thing is that your users don’t want to be tied down by complicated VPN clients and stuff, users nowdays are used “stuff just working” and it has to be easy and intuititive for them. The days of the “System Administrators from Hell” implementing all kinds of complex solutions to keep stuff secure and forcing users to having very specific and complex ways of accessing data are over. They were good times, good times but they’re over. Deal with it.

The IDS/IPS approach:

Using a centralized IDS/IPS This is a more efficient method, yes. The downside is, most of these systems require you to change your infrastructure and get specific, costly hardware, licenses and costly consultants to get it up and running. And someone needs to monitor it, take care of it and so on. There are parllells to the VPN approach here although an IDS/IPS does a while lot more such as examines all the network traffic, examines it for malicious code and so on. I’m not sure actually if an IDS/IPS can communicate with the Windows Server Authentication Process so I’ll actually won’t say anything about that. I would presume they can, otherwise I fail to see the point (from the brute force logon prespective, that is) and you’d still need to handle the logon attempt on the Windows server.

The Account Lockout Policy approach:

The acccount lockout method is also flawed due to the fact that an attacker can quite easily cause a DOS (Denial of Service) simply by hammering your server with invalid logon request but with valid usernames, thus rendering the accounts unusable for the valid users. Basically, all he (or she)  needs to know is the user logon name and in many system , it’s not tha hard to guess (try the companynameusername or the mail address for the user since it’s quite often also a valid logon name if you have a look at the properties of the user in Active Directory Users and Group snap-in)

The Cloud Computing approach

We are shifting  more and more of our data and applications into various Cloud Services (like it or not but, it’s a fact and you know it). This way we do get rid of some of these problems on our own servers and hopefully, your Cloud Service provider actually has a plan for these scenarios and has the necessary surveillance software and systems in place. If you’re using a Cloud Computing platform based on Windows Servers, you should actually ask your provider how they handle brute force attempts on their servers. Most likely they will give you one or more of the scenarios described above and, as I’ve showed you, they are not adequate to handle the task at hand. They’re just not up for the job. Feel free to ask your own provider and see what answer you get. My guess is .. mumbo jumbo but basically , they don’t have anything in place really, more or less.
You could even try logging into you own account with your own username but the wrong password loads of times and see what happens. Will it be locked out? Will your machine be locked out? How does your Cloud Srvice Provider respond and are you informed in any way that an intrsuion attempt has been made using your account ? How many times can anypne try to access your account without you being notifed of it? And from where are they trying to get to your data and why?
Personally I know of only one Cloud Service Provider that has also taken these questions into account and that’s Red Cloud IT in Sweden.

Is there a solution then?

Yeah. I told you so in the beginning and even if you choose not to use what I suggest, I highly recommend that you start thinking about these things properly because these problems will accelerate in the future. Just take a look at all the hacktivism with DDOS attacks going on out there. It’s just a start because the Internet is still young.

First of all, and this is extremely important you realize, , it doesn’t matter if you hosting your own servers or if you’re using VPS (Virtual Private Servers) hosted somewhere else or even if you’re a Cloud Service Provider. The basic principal stands: if you are providing any kind of service to users using the Windows Authentication mechanism you should be reading this and hopefully my point has come across.

If you’re having brute force attacks on your Windows systems today and I’m pretty sure you do (just turn on logon auditing and I’m sure you’ll see you have more than you actually thought you did, *for some odd reason this is NOT turned on by defaut in Windows*) there’s a few things you should be doing (that I’m guessing you’re not beacuse you’re not a cyborg and you need to sleep, meet your friends and family and actually be doing something productive during your work hours). On the other hand, if you are doing all of these things I’m guessing you have quite a large IT staff with a lot of time on their hands. Good for you. Call me and I’ll apply for a position.

First of all. Block the attack.

You need the attack to stop! Instantly. This is of course your first priority That’s basically blocking it in the firewall, either in the local Windows firewall or the external one, it’s actually up to you which way is the easiest one. The reason is that you don’t want to be wasting CPU and RAM and bandwidth on these people (or botnets)  and of course, you don’t want them to actually succeed in logging on (should you have a lousy password policy in place ) or even them disguising a real intrusion attempt behind a DDOS attack to fill your logfiles and hide themselves in there. (Yes, it’s not an uncommon method). There’s also quite a few reports of DDOS attacks being used to disguise the actual reason for it which is to find out what security measures are in places for future reference. The “know your enemy principal”.

Second. Trace the attack. From where did it come?

Second , you need to find out from where the attack originated and what username was used. This is because you want to know if it is a competitor trying to hack you and access your corporate data or if you find yourself in the interesting position of your own username trying to login from sunny Brazil and you’re just not in Brazil (although you’d love to be) . You’re in Chicago looking at winter. Somethng’s up.
You also want to see if it’s a former employee trying to log on and so on .. This is stuff you need to know and keep track of since there may be legal issues involved further down the line.

Points one and two , you want to be handled in real time. There’s no use for you to find out two days after the attack that something actually happened. You want it stopped, reported and handled as it happens.

The legal stuff.

Third, you need to decide what to do with your information. Should it be handed over to the legal departement, your boss, the police or is it just “nothing” and can be discarded ?

So. “What would you suggest as a solution then” ? 

The easiest and most cost efficient way to handle brute force attacks on Windows server is to have an automated sysem to block, track and report each attack and that’s where Syspeace comes into play.

Syspeace is a locally installed Windows service, thus using a minimum of system resources,  that monitors the server for unwanted logon attempts and blocks the intruders in real time in the local firewall based on the rules you’ve set up. For instance “if this IP address has failed logging on 20 times during the last 30 minutes then block it completely for 5 hours and send me an email about it”

This means that you can for instance set up a blocking rule that is you “Account lockout policy – 1” in your rules and that way simply blocking the bruteforce attack but not locking your users accounts and causing them unecesseray disruption.

Since Syspeace monitors the Windows Authentication logon oprocess, it doesn’t matter what firewall your using or what ports you’re using, the monitoring and blocking is done where the actual login attempts is made and therefore caught and handled automatically.

Once the intruders IP address is blocked, it’s blocked on ALL ports from that server which means that if you have other services also running on it (like FTP or well.. anyhting really) those ports and services are also protected instantly from the attacker. Not giving them the chance to find other ways of gaining access to that server through exploits.

A few other features in Syspeace

A few other nice features with Syspeace is for instance the GBL (Global BlackLlist) where every Syspeace installation around the world , reports each attack to a databse where they are examined and weighed and , if deemed “meneace to Internet and all of mankind” the database is then propagated to all other Syspeace installations. In this way, you’re preemptively protected when the bad guys come knocking on your door. So far , there has been over 200 000 brute force attcks blocked by Syspeace worldwide (and that’s just since mid July 2012) and some of them have made it to the GBL. Lucky them.
Of course there are white lists and stuff, giving you the ability to have your customers or internal users keep hammering you servers all day long if they (and you) want  without being blocked out.

There’s also the Attack Cintrol section that gives you the ability to sort out information about successful and failed logons, findind the ones that are trying to stay under the radar, viewing reports.
You get daily and weekly reports email to you and each attack is also mailed to you with detailed but easy to understand information from where the attack originated including country, what username was used and how many times they actually tried to hack or overload you. This gives you the ability to quickly see of it’s something you should be taking care of or just carry on with your working day and leave it be with a smile on your face.

The GUI is easy to use (and there’s an even easier coming up in the next version) so there’s no need to hire costly consultants to be up & running or start using various scripts and change parameters in them to suite you needs and hope for the best and hope they don’t hang your servers.

Syspeace also protects the Microsoft Exchange Server Connectors from being attacked.

The licensing is not steep, I’d even dare say cheap and it’s extremely flexible.

As an example. If you buy yourself a new server today (evereybody loves new toys ) , you install Syspeace on it and then you get yourself a second server in 4 months. You can easily align the licensing renewal dates for both servers , not having to keep track of licensing renewals scattered over the entire year. If you’re up for , you could even byt yourslef just a one months license. Or a week. I’s up to you and what needs you have.

Download a free trial and see for yourself.
We know it works and so does all of the people around the world who are already running it.

Syspeace – let the silence do the talking

Syspeace - intrusion prevention for Windows servers

Syspeace website

Blog post written by Juha Jurvanen
Senior IT consultant in backup, IT security, server operations and cloud