Posts

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

http://support.microsoft.com/kb/931125

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: https://certs.godaddy.com/anonymous/repository.pki

#infosec #Syspeace for intrusion prevention for #windowsserver instead of specific applications or services such as #FileZilla FTP Server or #WordPress

Syspeace for intrusion prevention for the entire server instead of specific applications or services such as FileZilla Server

If you’re managing a server and host various applications and services all of them are reachable for your users and and customers but most likely, and quite often, they’re also reachable for others to try to log in.

To be cost effective, you could be using using a Terminal Server (or Remote desktop Server) and you’ve also got for instance a FileZilla FTP Server to ease file transfers (or the Microsoft IIS FTP server, my hunch is that these two are the most common ones if you’re running a Windows Server environment) and there’s a web interface for the remote applications and so on . There might also be other services on the same server/servers.

Built in intrusion prevention in applications or Windows Server

Some software actually have brute force prevention built into them, such as the FileZilla FTP Server (although, keep in mind that is it not enabled by default) and there could be other software installed that have intrusion prevention built into them. Not within Windows Server though and there are quite a few articles on this blog explaining how it works such as this one about securing your Exchange OWA

An atacker will first portscan your server, search for open ports and try to figure out what services and applications you’re running on them. Even if you’ve changed the default ports, quite often the application will actually reveal itself in the header what it is and what version it is.

You can for instance simply do a telnet session to the port in question and see what your applications actually reveal about themselves.
Simply start a telnet client and connect to the port you’re interested in such as port 25 for SMTP (email) or port 21 for FTP and you’d probably get at least some information on what is running on the server. To gather more detailed and complex information, you probably be using software like nmap.

After that, tbey’ll simply use automated scripts to try and login. If there is a block in some way on for instance FileZilla FTP Server they’ll simply move on to the next port/service , like the RDWeb interface for Remote Desktop and RemoteAPP services and continue the attack since they’d only been blocked on the FTP level so far (usually port 21) Here’s a >previous article describing parts of the anatomy in a hacking attack written by Juha Jurvanen.

If you’re hosting a multiple software and srevices on a server and each of them have brute force prevention builtin , they’ll only block the attack within their own part of the system.
FileZilla will block the brute force on FTP but nothing else.

Using Syspeace as your HIPS , Host intrusion Prevention System for Windows Servers

A key difference using Syspeace as a HIPS (Host Intrusion Prevention System) is that it will block the attacker entirely on all ports if they trigger any of the detectors, rendering the attacker unable to communicate at all with your server on any port (even ping), thus automatically protecting any other service you have running on it.

To illustrate this with something in the “real” world.
If you’ve got a house with multiple doors, the attacker would first try their keycard/key in one of the doors to try to gain access into the house until an alarm is triggered and they would have to move on, but only for that specific door.
After that they’d keep using the keycard/key on the next door and so on.
With Syspeace, they’d only be able to use the keycard on the first door until the alarm is triggered and after that they would be automatically blocked from even trying to use the keycard on any of the other doors since the doors would have “magically” disappeared for them and would be out of reach for them. It would be as if the actual building itself would have disappeared for them.

Download a fully functional, free Syspeace trial for intrusion prevention or even if you’re under attack of a brute force or dictionary attack

Have a look at the Syspeace website and try the fully functional trial for it and see how it can help you to easily and quickly brute force protect your server. We’ve had users downnloading Syspeace and implementing it in minutes during a dictionary attack to have Syspeace automatically deal with it and to block, trace and report the attack. Since the trial is fully functional and free and it only takes a few minutes to set it up, it can be an easy solution to handle an ongoing attack.

Syspeace supports Windows Server 2003 and on (including the Windows Server Small Business versions), SQL Server, Remote Desktop, Exchange Server, Sharepoint, Exchange OWA, RDWeb , Citrix and more. Out of the box. It actually also support Windows 7 and Windows 8 but please refer to his article on when Syspeace is actually useful for you and when it’s not.

Syspeace has blocked more than 3 126 500 brute force and dictionary attackas targetaed agains Windows Servers worldwide.

The Syspeace team has also developed a FileZilla FTP Detector that is in beta and also an Microsoft IIS FTP detector.
We’ve also released a detector for selfhosted WordPress and we’ve released the Syspeace API for .PHP and .NET to enable our users to develop their own intrusion prevention for applications instead of being forced to develop protection into applications themselves from scratch.
The Syspeace API can also be used to protect spcific websites if you’re hostng multiple websites.

#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 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 http://www.spiceworks.com

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
http://jufflan.wordpress.com/2012/11/03/remembering-complex-online-passwords/ and on the topic of online passwords and identities also, http://jufflan.wordpress.com/2012/11/03/reflections-on-theft-and-protection-of-online-identity-on-the-internet-who-are-you/

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 http://syspeace.wordpress.com/2012/10/21/securing-your-webmailowa-on-microsoft-exchange-and-a-few-other-tips/

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 http://jufflan.wordpress.com/2013/07/15/using-windows-server-backup-20082008-r2-for-a-disaster-recovery-from-a-network-share/

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 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/ . 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:

http://jufflan.wordpress.com/2012/10/22/securing-your-server-environment-part-1-physical-environment/
and
http://jufflan.wordpress.com/2012/10/22/securing-server-environments-part-ii-networking/

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

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.

Securing your webmail/OWA on Microsoft Exchange and a few other tips

This is what I’d called a “blogomercial” with a hidden agenda but I hope you’ll find some interesting pointers anyway, the commercial part is at the end really. 🙂

Servicing your users and customer over the Internet 

Anything facing the Internet is a potential target for anyone who wants to gain access or disrupt your data operations. If it’s here, people will try to get in or make it stop working. That’s just the way it is and I’m sure you’re aware of it.

There’s different methods for the attacks actually, they could be a DOS attack, a DDOS attack , SYN Floods to name a few
The motives behind any of these could be a number of things such a hacktivism, former employees or even current, script kiddies just fooling around, organized crime, extortion, theft of company secrets and so on.
Just take your pick really.

You need to make a SWOT analysis and have a Business Continuity Plan (BCP) in place for the different scenarios actually.  It sounds expensive (and, yes,  it can be) but the day you servers are under attack, you’ll be happy you took the time to create one. Trust me. So will your CEO be.

A few of the different techniques for DOS, DDOS , Brute force

The methods of taking down a server vary. As with everything else in the real world, there are different tools to get the same job done, it’s basically a matter of taste and skill and how much time the attackers have on their hands. If you’ve pissed of a state , you’re probably going to have an extremely bad day since they do have extensive resources to keep you “offline” for as long as they want really.

SYN FLOOD

For instance there’s SYN flooding , basically equivalent to old school prank calling,

Send a network packet to the server announcing you want to “speak”  , the server responds but no one is there to continue the “conversation” . If you do this a few hundred thousand times, the server will have quite a few “phone calls” to attend to and therefore can’t actually be bothered with picking up the “phone” for the legitimate “calls” thus making a DOS attack meaning “Denial of Service”, the server can no longer service what it’s meant to service, that being your users or customers.

DOS and DDOS Attacks

A DDOS (Distributed Denial of Service) attack is actually the same thing , the main difference being that its spread out over an extremely large number of computers around the world doing the same thing , making it very difficult to manually block each and every one of them in the firewall manually. These computers are usually part of something called botnets and the users of these computers are rarely aware even of them being a part of it. In this scenario you need to contact a lot of people and get it sorted, for instance your ISP, the server guys and firewall guys and you need to have a look at the BCP. What do we do when this happens and so on. Do we move the servers, up the bandwidth, go out of business,  wait until it passes and so on ?

MITM, Man in the Middle 

Using MITM (Man In The Middle) attacks is also popular method if you haven’t secured your server and your communications with valid SSL certificates. Quite a few actually use self-issued certificates on the websites and on their OWA site and that’s not a good thing. When someone who knows what they’re doing connect to a site that has a self issued certificate the first thing that comes to mind is ..”hmm .. these sysadmins are cheap and lazy and I’m fairly sure they just set this server up using default values.. let’s have a look”  .. )

The problem is that there’s actually no real way for the connecting computer to validate that the site it is connecting to actually is the site it’s hoping for. It might as well be someone claiming to be that site since the certificate used can’t be validated by a third party (the “Trustad Authorities”). This way , phishing attacks (“phising” is when you “phish” for a users valid credentials to use them later at the users real websites)

It’s absolutely no guarantee even if you do use a valid certificate since also the “Trusted Authorities” can be hacked and therefore all of their certificates can be compromised (yes, it’s already happened a few time in the past year, GoDaddy, Verisign and even Microsoft themselves realized they had a bug in how Windows Update actually validates that it is connecting to the Windows Update site and nowhere else.)

Brute force attacks

Another method of rendering you server useless is to use a brute force attack on the usernames (sometimes also known as a “dictionary attack” ) .

If you know the naming convention of the usernames used at the company (quite often as easy as the email addresses of the employees or compaynameusername) you can keep on pounding the server with valid usernames and wrong passwords , hopefully rendering the user accounts to become locked out all the time by triggering the Account Lockout Policy. An easy entry point to this is the .. *tadaa* .. yes, you guessed it, the Microsoft Exchange Webmail/OWA interface (or for instance a Sharepoint login interface) .

It’s always there, it’s fairly easy to find ( mail.companyname.com, webmai.companyname.com , mailserver.companyname.com/owa and so on. Tekkies might be good at tekkie stuff but we do lack imagination when it comes to naming stuff. And we are lazy 🙂

It’s not that difficult to find out what mail server a company is using (easiest way is to use the NSLOOKUP command and search for the MX record, start a telnet session to the server and see what it presents itself as . It’s usually in cleartext what kind of server you “talking” to )

Once you know this , you also know a few other things automatically.

Practical use for the information

By default , there are two valid usernames in a Windows Active Directory (I will stick to 2008+ AD here)

First, it’s the older naming that quite a few still uses. This is the COMPANYNAMEUSERNAME naming convention . These usernames can be difficult to guess , it could be the users first name (COMPANYNAMESAMUEL) or the the first characters of the first name and surname (COMPANYNAMESAMSMIi) and so on. It’s basically more or less a question of how large the company is.

The larger it is, the longer the username but also , much more standardized in naming since otherwise it becomes an administrative nightmare for the system administrators and we are a lazy bunch really. We want to be able to find our user quickly and and easily in order to support them and keep track.*grin*

The easier approach is to attack the user account using their mail addresses. Quite a few sysadmins don’t realize that the mail address is also a valid logon name since they are used to thinking of logins using the the old naming convention.

Since they also want to provide access to webmail , and usually, 97 times out of a 100 (no, I just guessed a number, I have no statistics to support it, it’s just a gut feeling, ok ? ) they don’t require any special VPN software for their user to access the webmail (OWA)  interface since the whole idea is to let users easily connect to their mail, wherever they are.

This means that the OWA interface is reachable for the entire world to try and login into and thus leaving you open for DOS, DDOS, brute force attacks and so on .

SPAM and overload

There’s also so the various methods of overloading our server with SPAM and viruses.

It’s not unusual to use the secondary MX record (which is used for failover in case the usual mail server has some issues)  for your mail domain actually. Most companies that have secondary MX in place have a more or less effective defense on the primary MX but the secondary is often forgotten and is a popular way to over flood a server with various SPAM.

Quite often , they’ve set it up in the way that the primary MX might point to the secured, external provider or the secured, primary mail server interface and the secondary points directly to the mail server, thus not taking the way through the washing and security mechanisms in place but instead be delivered directly to the mail server.

A few countermeasures then .. 

So , what can be done then? Should you close down the OWA / webmail interface? Stop using email? Revert to faxing?

No, of course not

Here’s a few pointers on what I’d suggest on securing and managing your Exchange servers. It’s not all the tricks in the book and I’m sure I’ve missed out on quite a few ones really but it’s a start I guess. Just, remember, there is no such as thing as absolute security.

1. Minimize the attack surface behind a good firewall that can deal with the SYN Floods and port scans and stuff. Be cautious not to open up anything more than what’s absolutely necessary to and from the outside world.

If you’re using an external “mail cleaning service”, don’t allow port 25 from any other IP/IP ranges than them. If your users are to use your Exchange Server for relaying , set up a connector with SSL and SMTP authentication on other port and enable logging on it. Protect it by using Syspeace (yes, here the first commercial part so you’ll see where this is headed 🙂 )

Also, best practices is to use a DMZ (Demilitarized Zone) for any of your serevr facing the Internet although when I start to think of , I’m not sure if that’s necessary. There’s different opinions in the matter really. The idea is to have the attacker not being able to come in further into you network, should they succeed in gaining control over the server on he DMZ. Unfortunately, I’m fairly sure that somewhere on the those servers there are administrator password and stuff that’s useful knowledge for further access into your network.

2. Get valid, proper, shiny and bonafide certificates for your communications. It’s not costly and not complicated to implement. Its mainly the hassle of you having to remember when to renew them, otherwise stuff will stop working when they expire.

3. Use an automatic brute force prevention software ( I highly recommend Syspeace since it also protects, Sharepoint, Citrx, Terminal Server, CRM , RDWEB, basically anything that uses Windows Authentication ) to get rid of the DOS attack where username/password is hammered onto you servers (brute force attacks / dictionary attacks) . (I’ve written an earlier entry on why firewalls, VPNS, account lockout polices and so on aren’t enough here: http://syspeace.wordpress.com/2012/10/16/various-brute-force-prevention-methods-for-windows-servers-pros-and-cons/ ).

4. Enforce an Account Lockout Policy and enforce complex password. Yes, people will hate you but they will hate you even more if someone actually succeeds in hacking your users data.  Have a look at the link above about Account Lockout Policies though. Do not have local users more than necessary on the Exchange Server itself.

5. Verify all of the websites with the NTFS permissions when it comes to file access, remove the IISTART from the root and remove any default .HTML and .ASPX pages that don’t need to be there.. Don’t let he attackers realize you’re lazy and using default values everywhere. I’ve seen so many servers withe default start page on IIS and that’s just not right.

6. Verify also you’re not open for relaying ( this is usually default nowadays) . Anything that is installed by default by the IIS , take good look at it and decide if it really needs to be there, If not remove it!

7. Redirect all of the 404 and other serious html errors to somewhere else. Google, your worst competitor, your mother-in-law, 127.0.0.1 , anywhere really , just get rid of the traffic from your own site. A lot of 404 errors could mean that someone is trying to find out stuff about your server and if you have any default installed scripts or pages in place that can be used to gain access to your server .

8. Antivirus of course.If you’re not using one today, well.. maybe you shouldn’t be reading this at all but you should be out looking for another job really. I hear there’s good money in flipping burgers.

I’ve used most of them , some are good and some .. well , just aren’t. For the moment I do use Fsecure or Trend a lot. I’m not a big fan of McAfee due the fact they’ve released a few .. not so good updates the recent years that crashed servers around the world. I’m sure they a great product, it’s the product testing and quality verification that needs improvement. Just remember , the same thing goes for antivirus as for 0day attacks, if you antivirus provider hasn’t released any protection against that virus you just got into your system , there’s not that much you can do about it, more than start cleaning your server once you the antivirus updated or even restore your server to a state prior to the virus. An antivirus is not the single point of protection. Common sense is the best antivirus protection in the world.

9. Also, as a complement, use an online service also that filters all of your incoming and outgoing mail from viruses and SPAM and also have you secondary MX records point to it. Usually these services also hold you mail in queue if they cant’ be delivered, buying you time to change the IP addresses or server if you are under attack and not losing any mails.

10. Set up DNS Blacklisting and DNS GREY Listing. It’s not very complicated to do really and you do get rid of a lot of unwanted traffic.

11. Don’t use the “validate reverse DNS” options since a lot of companies haven’t actually set it up correctly so you’ll just risk not getting email from them. The idea is good but it doesn’t work in real life.

12. Enable logging on the connectors and basically enable logging on everything. READ!! the log files. Don”t just turn on logging and let it be. At least once a day , have someone read the (or script queries against the log files ) and see what’s really going on. Search for anything out of the ordinary.

13. Remember to check your mail queues on a regular basis  If you’re starting to have loads of undelivered mail to and from various domains you could actually have a DNS server that’s under attack , not being able to service your Exchange server with required information . On the subject of DNS servers. There’s absolutely no point in having your DNS servers reachable through the firewall thus enabling attackers to flood it with DNS queries and UDP floods. Also, you external DNS server needs to be secured! Have a word with your ISP or whoever is running the external DNS server and see what they’ve got in place.

14. Patch you servers with all of the security patches that are released.  Do it as quickly as possible. There’s is absolutely no defense against 0day attacks.

A 0day is a security bug in the software of the server your running and they vary on how much impact they may have. The name comes from that it is day 0 of it’s public release and the manufacturer, in this case Microsoft, hasn’t released any patch against it leaving you vulnerable no matter what you do. Some of them are even just a nifty way of adding stuff (specific strings ) to the URL or the service the attacker wants to reach and bypassing all of the built in security by “fooling” the server.

15. Disable services that don’t need to be running, DHCP client and stuff. Although they’re not reachable from the Internet , they quite often are reachable from the inside and should you have an attacker on the inside of your network or a virus infected computer , you might be having a bad day.

Minimize attack surfaces, once again  And keep the server resources to actually servicing what they’re supposed to instead of having unnecessary stuff in RAM / CPU .  This is of course valid for any servers, Citrix, terminal servers, domain controllers, Sharepoint and so on.

16. I’m fairly sure you’ve set the ActiveSync functionality for your users since it is an effective and easy way for them to synchronize their iPads, iPhone, Androids and so on . Beware that you also remember to periodically check the various devices associated with the users. If you’ve got a user synchronizing more than 10 devices at the same time from different parts of the world, well.. either he or she is really into gadgets or their user validation information may have leaked (username / password)

17. If someone quits the company, be sure to use the mechanism for clearing the remote device from calendar entries, contacts and email using the built in mechanism in the Exchange server (it’s really easy to do ) . And, of course, if a user reports they’ve lost the devices, same thing, Clear the old device and unpair it from the Exchange server. Unfortunately, users don’t always tell you when they’ve lost stuff . They just buy a new gadget, set it up, synchronize and don’t think twice about the old one and what i actually contains.

18. A bot off topic but it has to do with BCP mentioned earlier. Be sure , please, be supersure even , you have adequate backups , containing multiple generations of data and have at least three or four of theses complete generations stored offisite in some way. Using an online backup service or just moving your tapes/disk manually out of the building. Test your DR Plan (Disaster Recovery plan) at least  once a year to verify that your backups contain all you need if something happens. Be sure o have an updated technical description of how to restore your entire environment.

  • Who?
  • Where?
  • How?
  • What?
  • In which order?

Onto what hardware/virtual machines?

That’s six quite easy questions that sum up what that technical restore plan should contain. It should be able to be read even be outside consultants in case of your entire IT department got killed in a freak barbecue accident the night before.
Keep it simple but detailed.
Include all necessary background info such as server configurations, IP plans, passwords and where the data is stored. a Network map explaining dependencies might also be useful. Don’t use in house mumbo jumbo and nicknames describing various systems and stuff.
Write your DRP from the perspective that you’re gone (in the freak barbecue accident) and the person reading it has never ever heard of your internal system before.

If you don’t have all of these things in place, the day something really happens you will regret you didn’t take the time to do it. Trust me. I’ve worked as a Disaster Recover Technician and Consultant at SunGard Availability Services in Sweden for 8 years . I’ve seen grown men cry and unless it’s not for the unexpected death of their favorite dog or a lost game for their favorite sports team , it’s not a pretty sight.

19. Also a bit off topic but still important. Be sure to have a good monitoring on the hardware aspects of your server and operating system aspects (running services, disk space used and so on ) . Personally I’m fond of Spiceworks för monitoring server health, licenses and inventory but it all boils down to resources and taking the time to set it up. As long as you have some working monitoring and someone who actually deals with the alerts that come up.

20. Sign up for the Microsoft Security Bulletin newsletter (and all similar that has to to do with your environment). Stay up to date and up to speed on what’s going on out there. Being a sysadmin is not a 9-5 job, it’s a lifestyle and the ones who do all of these things will be better protected once they’re attacked.

 

And onto the unmasked commercial part then ..

Since the focus on this article was to write in general about Exchange Server security and the hidden agenda was to mention Syspeace I’ll get back to it .  *smooth, eh ? 🙂 *

Syspeace will help you in some of the scenarios above, particularly in the brute force prevention department. It’s easy to use and you’re instantly protected from the moment you’ve set it up)

It protects you from any brute force hacking attempts using Windows Authentication ( Terminal Server, OWA, RDWEB, Sharepoint, CRM, RDP, netlogon and so on ) and it also contains a Global Blacklist to have you preemptively protected from known attackers around the world.

It will not help you in all of the scenarios described above  but it will absolutely make you life as a sysadmin much easier since it automatically blocks the attack, tracks it down and reports it. For the sysadmin it’s just an email telling him or her that
“This IP address with this DNS name from this COUNTRY tried logging in using this USERNAME and is now blocked according to this rule you’ve set up ”

The cost is equivalent to any antivirus so I’d hardly call it costly.
It’s easy to set up so you won’t be needing to redesign your infrastructure or call on expensive consultants to get it up and running. You’re done in 5 minutes. Tops.

Download a free, fully functional trial of Syspeace for yourself and see what I mean.

 

This “blogomercial” was written by

Syspeace - brute force protection for Windows

Syspeace – bruteforce prevention for Windows servers

Juha Jurvanen, Senior IT consultant in backup. security, server operations and cloud @ JufCorp.com

Drop me an email if you’re interested in getting help in any of these matters. Or if you just want to say hi.