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. in the upcoming version this has been fixed.

by Juha Jurvanen

Windows server intrusion prevention for hosting providers and cloud service providers with Syspeace

Syspeace - intrusion prevention for Windows servers
Syspeace website

Moving to the cloud or a service provider

The more users and companies start using any kind of external hosted environment, whether it is a cloud serviced VPS, a hosted Exchange, SQL Server or Terminal Server or just a co-located server, the more responsibility will fall upon the service provider to ensure their customers data is protected from unwanted logins and have adequate reporting mechanisms in place.

A service provider will have firewalls in place. They will have monitoring of bandwidth, resource usage, hardware monitoring and probably some antivirus solution but one area that most service provider tend to ignore is intrusion detection on the host level.

PLease refer to this earlier blog post on why the standard methods are NOT adequate for maintain a secure environment, regardless of your a service provider or you host and manage your own servers http://syspeace.wordpress.com/2013/07/11/using-various-brute-force-and-dictionary-attack-prevention-methods-to-prevent-hackers-and-why-they-dont-work-repost/
.

Verify your providers security awareness

I personally encourage any users / companies having their server hosted elsewhere to actually verify how the service provider handles intrusion attempts.

Try using your login name but the wrong password and simply try to login multiple times to for instance the Exchange OWA Webmail or your Terminal Server / Remote Destop / RemoteAPP Server / Sharepoint / Citrix.

What will happen ? Will you be blocked out and automatically handled as an intruder? Is your account locked out ? Are you alerted in any way by your provider that someone has tried to access your account ? If not, you should ask your provider hos this is possible? Isn’t that one of the ideas of having someone else handling your data and security that they also act upon it and have mechanisms in place for it ? Can they provide you with information on for instance from where your account has been logged in for the last 6 months?

Another interesting side of having your servers handled by others is the reporting capabilities.

When you had your servers in-house, you could verify user logins locally (assuming you’ve enabled auditing for it) but once you’ve handed over control of the WIndows server itself or if you’re in a shared environment, this can become quite tricky to get hold of.

Say for instance you want to verify if a specific user has been logged in and actually worked during July and August ? You also want to know from where? Can your service provider get you this information easily? In some cases, probably yes, not easily but with some manual labor and an extra cost for you, they can get parts of the informtion for you.

Are there any statistics provided by your provider on how many intrusion attempts that are actually blocked by them ? Probably not since this could scare customers away if they don’t have the appropriate solutions in place for securing their customers.

Cloud services and moving your servers to hosting providers and managed services are a great way of cutting costs and getting the benefits of shared environments but you should also demand that intrusion detection is in place, that reporting can be easily arranged from the cloud provider or service provider before even considering using external services. The idea is to get a heightened security , not a lowered one.

If you’re talking to a provider, simply ask them if they’ve thought of these questions and if they have, what countermeasures d they use and what processes do they have in place for intrusion attacks?

If they’re not aware of the problems or even worse, ignore them, maybe you should consider talking to another provider or have them take a look at Syspeace.

I personally believe that using Syspeace will become an advantage for any cloud service provider, hosting provider or outsourcing provider and it will cut administrative costs, strengthen security and be a selling pitch for customers that your using Syspeace to protect your customers from intrusion attemts and dictionary attacks.

Syspeace is not specifically targeted for Cloud providers but should be installed on any Windows based server as part of the baseline security, regardless if it’s a physical server or a virtual server.

By Juha Jurvanen – JufCorp

Intrusion prevention for Windows – Syspeace 2.3.1 released today!

We’re happy to annonunce that we’ve released 2.3.1 today!

The new release fixes some issues with reporting, non English OS, better error handling with communications failure to the license server and other fixes
http://syspeace.com/free-download/version-info/syspeace-231/

See the Syspeace website for a free, fully functional trial for intrusion prevention for Windows Servers, Exchange Servers, SQL Servers , Citrix, Terminal Server and more

Syspeace - intrusion prevention for Windows servers
Syspeace website

Tha brand new Syspeace website – now also with worldwide hacking statistics

Finally, the new website is up!

We’ve launched our new website a few weeks back and some of the news, apart from a better design and easier naviagtion, is that we’ve also included a security status page to display statistics based on Syspeace installations that report each hacker attack around the world.

Have a look for yourself at http://www.syspeace.com/security-center/security-status/ . You might find something interesting in there.

The statistis are dfivided into to two columns. The originating country for the attack and the country from where the Syspeace installation reported the attack.

The statistiscs displayed are the last 30 days of hacking attacks and so far Syspeace has blocked more than 1.4 Million brute force and dictionary attacks against Windows server worldwide!

While you’re at the website, download a free, fully functional trial to ptotect your Windows servers, Exchange servers, Terminal / Remore Desktop Services servers, Citrix servers, Sharepoint serevrs, SQL servers and more from brute force and dictioanry attacks.

Syspeace supports Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 and the Windows Server Small Business editions.

By Juha Jurvanen

Using Syspeace for a targeted bruteforce attack against a specific username

Today we had an interesting support question actually.

Someone is trying to bruteforce a customer using the same account name but from a lot of different IP addresses and they only try once or twice from each IP address thus not triggering Syspeace to block the IP address based on the default rule.

The suggestion that we eventually came up with is to create a rule based on the user name and set the allowed attempts to only 1 failed attempt. therefore making Syspeace block the IP address immediately.

In this scenario though, one must also keep in mind though that legitimate user will get blocked out instantly after one failed try so there might be a good reason to white list the IP addresses that this user usually logs in from.

Furthermore, the reason for this specific and targeted user attack should be inestigated more closely and also be handed over to the proper authorities for investigation.

Closing in on 1 Million blocked brute force and dictionary attacks on Windows Servers world wide

Just a quick post about the numbers so far really.

Last night , Syspeace had blocked 962 553 brute force and dictionary attacks on Windows 2003 / 2008 / SBS server / RDS servers / Citrix WorldWide.

As a prediction , we will reach over 1 Million later on this week or early next week. We think that’s pretty cool. Considering Syspeace has been publically available only since July 15th 2012..

New version coming up

Other news regarding Syspeace is that we’re beta testing the new release now that will support Windows Server 2012, SQL Server and also have a completely new reporting, sorting and exporting feature called Access Reports.

The new Access Reports feature lets you create reports on failed and succesful logins on your Windows Servers and export them to .CSV reports. The information is saved in the local database so even if the Windows Security Log is cleared, the information is still available for use in for instance forensics and other tasks.

For a free trial download of the brute force and dictionaray attack preventon software Syspeace, please refer to the Syspeace Download page.

Preview of the new Acces Reports feature in the upcoming Syspeace

This is a sneak preview of a new feature in the upcoming Syspeace to make sysadmins also be able to search, sort, create and export various reports to .CSV files on login activity on their Windows servers.

There will be even more things in the reporting and sorting functionality when we release it

Syspeace protects Windows servers, Exchange Servers, Remote Desktop Services, Citrix Servers, Sharepoint servers and more from brute force and dictionary attacks.
Syspeace works on Windows Server 2003, 2008 , 2088 R2 and SBS versions and an officially supported Windows Server 2012 and SQl Server support is underway,

For a free , fully functional trial please se http://www.syspeace.com/downloads.aspx