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.

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

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

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.

#infosec Syspeace support for #FTP on #IIS and #Filezilla in beta

This is just a short newsflash that the Syspeace devteam has been working on adding detectors for #Microsoft #IIS FTP server and for #Filezilla FTP server.

Using the Syspeace engine to prevent bruteforce attacks against #windowsserver #msexhange #Sharepoint #remotedesktop #Citrix has proven to be highly efficient and the need for more detectors grows steadily the more users we get.

We’ve blocked,tracked and reported over 3 Million #bruteforce and #dictionary attacks against Windows Servers worldwide so far.

We have a constant dialogue with Syspeace users over mail or Uservoice to see what new detectors our users need and one of the most frequently asked for is FTP support.

If you have ideas for new features or detectors, please join us at Uservoice or drop us an email.

We’ve already publically released the Syspeace API to enable you to write your own webapplication detectors and have Syspeace handle bruteforce attacks for you.
For more information on how to do this, please refer to the Syspeace Detector API page .

#infosec #cloudsecurity #Syspeace – Host Intrusion Prevention Software on an external #Windowsserver #VPS in the #Cloud #IaaS #PaaS

Syspeace – Host Intrusion Prevention Software on an external Windows Server VPS in the Cloud

There are many variations of IaaS / PaaS / Cloud services.
Some are public clouds and some are hybrids and some are private.
There’s also the possibility rent an external VPS and use as a server at quite a few providers nowadays.

The IaaS/PaaS (Infrastracture as a Service/ Platform as a Service) provider gives you acces to a virtual server designed as to your needs when it comes to RAM and storage. Basically, it’s usually an empty server with an operating system.

Running IT solutions on an external VPS decreases the need for hardware investements but there are still things you need to consider and you need to manage your server the same way you would with any physical server i terms of monitoring security and tha availability of services and applications.

Logically, the server is reachable from the Internet which will make it a target.
Anything that is reachable will be targeted for intrusion attempts. The responsibility for Iaas/PaaS provider is simply to provide you with the Hypervisor needed to host you operating system and the rest is up to you. You install the applications, webservers and everything just as you would with a normal physical server.

Some aware Iaas/PaaS/Cloud service provders do have some kind of Appshop/Control panel where you can get preconfigured software such as an antivirus or even Syspeace for intrusion prevention but it’s not that common.

Remember that your VPS shares “IP-space” with other customers when it comes to the network at your provider and you have absolutely no idea of what your “neighbors” are doing and if they’re the slightest security aware.
They may hve been hacked without you knowing it (or them either for that matter) and they could have the IP address right next to you and their server could be used for instance for portscanning or hacking attempts against your VPS (if seen this quite a few times now).

Your IaaS/PaaS provider usually wouldn’t know since it’s not their responsibility. Their role is simply to provide you and their other customers with a VPS. Nothing more. No security monitoring, no antivirus, no application / services monitoring
In case of a larger DDoS attack, they probobaly have ways to handle them if it concerns their entire network and affects a lot of their customers but when it comes to attacks speciafically targetet at your VPS and your users on it, it’s a bit trickier.

Imagine the scenario you’ve set up a server, you got your users set up, installed your applications and services and it’s up and running. Now, rermember that there’s no connection nbetween you userdatabase and login mechanisms locally on the VPS and your IaaS/PaaS systems so they’ll actually never even get any alarms if some is trying to brute force your server or your webapplication. They will be alerted in case of a large DDoS attack against their entire netowrk but they will not be alerted in cases of a bruteforce attack targetetd against your VPS.
So, in short, it’s all up to you. There’s no differnce apart from your not running the server in your own datacenter or at a hosting company.

Protecting your Windows Server, Exchange, Terminal Server / RDS, Sharepoint, SQL Server, Citrix and more from intrusion attempts

If your running a Windows server as a VPS you need to set up Syspeace to automatically handle intrusion attempts and have them blocked, tracked and reported againts the Syspeace Global Blacklist.
You also need to secure the server in other ways such as an antivirus, have your services monitored, you webapplication login form secured both from malicios code and from brute force logins (this is also wher Syspeace comes into play since there are plugins available for various webplatforms to use against bruteforce attacks)

Syspeace is an automated Host Intrusion Prevention System (also called a HIPS) and is targeted to protect Windows servers, Exchange and OWA , Sharepoint, Terminal Server / RDS and the RDWEB login, Citrix , SQL Server and more from bruteforce / dictionary attacks. . It is easy to install, and easy to manage and you’ll set it up in a couple of minutes and you’re protected. Instantly.

As I’m writing this, Syspeace has succesfully blocked, tracked and reported over 2 921 200 (2.9 Million) brute force and dictionary attacks against Windows servers worldwide.

Have a look the Syspeace website for a free trial download or keep reading some of the previous articles I’ve written on various securiy aspects on server managagement such as Using various brute force and dictionary attack prevention methods to prevent hackers – and why they don’t work and Securing your #WinServ and #MSExchange with an acceptable baseline security

By Juha Jurvanen @ JufCorp

#infosec #cloudsecurity #Syspeace – Host Intrusion Prevention Software on an external #Windowsserver #VPS in the #Cloud #IaaS #PaaS

Syspeace – Host Intrusion Prevention Software on an external Windows Server VPS in the Cloud

There are many variations of IaaS / PaaS / Cloud services.
Some are public clouds and some are hybrids and some are private.
There’s also the possibility rent an external VPS and use as a server at quite a few providers nowadays.

The IaaS/PaaS (Infrastracture as a Service/ Platform as a Service) provider gives you acces to a virtual server designed as to your needs when it comes to RAM and storage. Basically, it’s usually an empty server with an operating system.

Running IT solutions on an external VPS decreases the need for hardware investements but there are still things you need to consider and you need to manage your server the same way you would with any physical server i terms of monitoring security and tha availability of services and applications.

Logically, the server is reachable from the Internet which will make it a target.
Anything that is reachable will be targeted for intrusion attempts. The responsibility for Iaas/PaaS provider is simply to provide you with the Hypervisor needed to host you operating system and the rest is up to you. You install the applications, webservers and everything just as you would with a normal physical server.

Some aware Iaas/PaaS/Cloud service provders do have some kind of Appshop/Control panel where you can get preconfigured software such as an antivirus or even Syspeace for intrusion prevention but it’s not that common.

Remember that your VPS shares “IP-space” with other customers when it comes to the network at your provider and you have absolutely no idea of what your “neighbors” are doing and if they’re the slightest security aware.
They may hve been hacked without you knowing it (or them either for that matter) and they could have the IP address right next to you and their server could be used for instance for portscanning or hacking attempts against your VPS (if seen this quite a few times now).

Your IaaS/PaaS provider usually wouldn’t know since it’s not their responsibility. Their role is simply to provide you and their other customers with a VPS. Nothing more. No security monitoring, no antivirus, no application / services monitoring
In case of a larger DDoS attack, they probobaly have ways to handle them if it concerns their entire network and affects a lot of their customers but when it comes to attacks speciafically targetet at your VPS and your users on it, it’s a bit trickier.

Imagine the scenario you’ve set up a server, you got your users set up, installed your applications and services and it’s up and running. Now, rermember that there’s no connection nbetween you userdatabase and login mechanisms locally on the VPS and your IaaS/PaaS systems so they’ll actually never even get any alarms if some is trying to brute force your server or your webapplication. They will be alerted in case of a large DDoS attack against their entire netowrk but they will not be alerted in cases of a bruteforce attack targetetd against your VPS.
So, in short, it’s all up to you. There’s no differnce apart from your not running the server in your own datacenter or at a hosting company.

Protecting your Windows Server, Exchange, Terminal Server / RDS, Sharepoint, SQL Server, Citrix and more from intrusion attempts

If your running a Windows server as a VPS you need to set up Syspeace to automatically handle intrusion attempts and have them blocked, tracked and reported againts the Syspeace Global Blacklist.
You also need to secure the server in other ways such as an antivirus, have your services monitored, you webapplication login form secured both from malicios code and from brute force logins (this is also wher Syspeace comes into play since there are plugins available for various webplatforms to use against bruteforce attacks)

Syspeace is an automated Host Intrusion Prevention System (also called a HIPS) and is targeted to protect Windows servers, Exchange and OWA , Sharepoint, Terminal Server / RDS and the RDWEB login, Citrix , SQL Server and more from bruteforce / dictionary attacks. . It is easy to install, and easy to manage and you’ll set it up in a couple of minutes and you’re protected. Instantly.

As I’m writing this, Syspeace has succesfully blocked, tracked and reported over 2 921 200 (2.9 Million) brute force and dictionary attacks against Windows servers worldwide.

Have a look the Syspeace website for a free trial download or keep reading some of the previous articles I’ve written on various securiy aspects on server managagement such as Using various brute force and dictionary attack prevention methods to prevent hackers – and why they don’t work and Securing your #WinServ and #MSExchange with an acceptable baseline security

By Juha Jurvanen @ JufCorp

#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
file.

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

Would #Syspeace help against #Heartbleed #OpenSSL bug ?

In short, no.

Syspeace monitors failed logins on  #msexchange #WinServ #sharepoint #remotedesktop #Citrix and evaluates if it is a bruteforce attack against the system or not. Syspeace has blocked over 2.6 Million bruteforce attacks against #windowsserver around the world so far.

However, if an attacker has gained access to passwords and usernames he or she will use those and be able to log in. From the systems point of view it is a fully legitimate login thus not awakening #Syspeace.

The nearest days, #sysadmins around the world will be upgrading their systems to the secured OpenSSL but for you as an enduser it is highly recommended to change all of your passwords .
Remember to use strong passwords and never use the same password on different sites.

Here’s a blogpost that might be of use for you to remember complex online passwords.

By Juha Jurvanen @ JufCorp

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 Syspeace also for internal protection and access reporting.

Using Syspeace for internal server protection

Most Syspeace users have the software in place to protect them from mainly from external threats from the Internet such as hacking attempts via bruteforce attacks and dictionary attacks.

Quite often, the internal netowrk ranges are excluded in the local whitelist by sysadmins , thus never blocking anything from those IP addresses or network ranges.

Some of our customers though have also discovered Syspeace to be an excellent tool to keep track of failed internal logins and those might actualy be important to keep track of.

If you’re not keeping track of internal failed login attempts, it might be hard to spot for instance a virus/trojan infected PC on your network that tries to login to every PC and server that is available or if a user is trying to access servers or assets they’re not supposed to. With Syspeace, the attack is automatically blocked, reported and and the sysadmin is alerted that something’s going on.

There can be downsides to not excluding internal IP ranges since there is a risk of for instance blocking a server from communicating with another but if you’re vigilant and think these things through, it’s mostly an administrative task to remember that yov’ve got Syspeace when you’ve changeed an administrators password or whatever.

Creating reports on user logins

Another great feature of Syspeace is the reporting section that enables for sysadmins to create reports and staistics about user logins such as when, from where and even hof often from that locationc they’ve actually been logged in.

For instance, if a user claims to have been working from home in July, it’s quite easy for a sysadmin to actually verify this using the Access Reports section to create .csv files with statistics.
Now, if the IP address for instance originates from Spain and your company is located only in Sweden…

If you’re using a Windows Server-based Cloud Service for instance, it might be difficult for you to get hold of such information, even if you ask for it.

Howerver, if your cloud Service provider is running Syspeace to protect you and other customers it’s a walk in the park for the provider to get you that infomation if you need it for some reason.

Syspeace stores failed and successful login in a local database so even the Windows securiy eventlog is cleared , the information can still be obtained by Syspeace.

Download a free, fully functional trial at / and have your Windows, Citrix, RDS, Sharepoint, Exchange, OWA, RDWEB, SQL servers and more instantly protected from hacking attempts.

By Juha Jurvanen

Syspeace logo

Syspeace – Intrusion prevention for Windows Servers