Attacks and Countermeasures

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

There are different methods for the attacks, they could be a DOS attack, a DDOS attack, SYN Floods to name a few. The motives behind any of these could be several things such as 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.  It sounds expensive (and, yes, it can be) but the day your servers are under attack, you will be happy you took the time to create one. Trust me. So will your CEO be.

Different techniques for attack

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 is basically a matter of taste and skill and how much time the attackers have on their hands.

If you have angered a state, you are probably going to have an extremely bad day since they do have extensive resources to keep you “offline” for as long as they really want.

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 these a few hundred thousand times, the server will have quite a few “phone calls” to attend to and therefore cannot be bothered with picking up the “phone” for the legitimate “calls”. Thus, making a DOS attack means the server can no longer service what it is meant to service: 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 it 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? 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 if you haven’t secured your server and your communications with valid SSL certificates.

Quite a few use self-issued certificates on their websites and on their OWA site and that is not a good thing. When someone who knows what they are doing connects to a site with a self-issued certificate the first thing that comes to mind is: Hmm… I am sure they just set this server up using default values. let us have a look…”.

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

It is 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. It has already happened a few times in the past year, like GoDaddy and Verisign. Even Microsoft themselves realized they had a bug in how Windows Update validates that it is connecting to the Windows Update site and nowhere else.

SPAM and overload

There are also so 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 overflood 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.

Brute force attacks

Another method of rendering your 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) you can keep on pounding the server with valid usernames and wrong passwords. Hopefully, this will render the user accounts to become locked out by triggering the Account Lockout Policy.

An easy entry point to this is the Microsoft Exchange Webmail/OWA interface (or for instance a SharePoint login interface). It is always there, and it is easy to find. Tekkies might be good at techie stuff but we do lack imagination when it comes to naming stuff.

It is not that difficult to find out what mail server a company is using. The 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. It is usually in plain language what kind of server you are “talking” to.

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

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

First, it is the older naming that quite a few still use. This is the COMPANYNAMEUSERNAME naming convention. These usernames can be difficult to guess, it could be the user’s first name (COMPANYNAMESAMUEL) or the first characters of the first name and surname (COMPANYNAMESAMSMIi) and so on. It is 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. We want to be able to find our users quickly and easily to support them and keep track.

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

Since they also want to provide access to webmail and a lot of time, they don’t require any special VPN software for their user to access the webmail (OWA)  interface since the 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.

Countermeasures

So, what can be done then? Should you close the OWA / webmail interface? Stop using email? Revert to faxing? No, of course not.

Here are a few pointers on what I would suggest for securing and managing your Exchange servers. Just, remember, there is no such as thing as absolute security.

Minimize the attack surface and get proper certificates

• 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 anything more than what is necessary to and from the outside world.
  If you are using an external “mail cleaning service”, do not 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 another port and enable logging on to it. Protect it by using Syspeace (yes, here is the first commercial part so you’ll see where this is headed :-) )
  Also, best practices are to use a DMZ (Demilitarized Zone) for any of your servers facing the Internet although when I start to think of it, I am not sure if that is necessary. There are different opinions on the matter really.
  The idea is to have the attacker not be able to come in further into your network, should they succeed in gaining control over the server on the DMZ. Unfortunately, I am sure that somewhere on those servers there are administrator passwords and stuff that’s useful knowledge for further access into your network.
• Redirect all 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.
• Disable services that do not 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 servicing what they are 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.
• Get valid, proper, shiny and bonafide certificates for your communications. It is not costly and not complicated to implement. It is mainly the hassle of you having to remember when to renew them, otherwise, stuff will stop working when they expire
• Verify all 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 do not need to be there. Do not let the attackers realize you are lazy and using default values everywhere. I have seen so many server’s white default start pages on IIS, and that is just not right.
• Verify also you are not open to relaying (this is usually the default nowadays). For anything that is installed by default by the IIS, take a good look at it and decide if it really needs to be there. If not remove it!

Use automatic systems

• Use automatic brute force prevention software. I highly recommend Syspeace since it also protects, SharePoint, Citrix, Terminal Server, CRM, RDWEB, basically anything that uses Windows Authentication ) to get rid of the DOS attack where username/password is hammered onto your servers (brute force attacks / dictionary attacks).
• Antivirus. Some are good and some are not as good. If your antivirus provider has not released any protection against that virus you just got into your system, there is not that much you can do about it. Not more than start cleaning your server once the antivirus is updated or even restore your server to a state prior to the virus. Antivirus is not the single point of protection. Common sense is the best antivirus protection in the world.
• Use an online service that filters all your incoming and outgoing mail from viruses and SPAM and has your secondary MX records pointed to it.
  Usually, these services also hold your mail in queue if they cannot be delivered, buying you time to change the IP addresses or server if you are under attack and not losing any emails.
• Set up DNS Blacklisting and DNS GREY Listing. It is not overly complicated to do really and you do get rid of a lot of unwanted traffic.

Efficient personal policies

• Enforce an Account Lockout Policy and enforce complex passwords. Yes, people will hate you, but they will hate you even more if someone succeeds in hacking your user’s 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.
• 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 is easy to do).
  And, of course, if a user reports they have lost the devices, the same thing, clear the old device and unpair it from the Exchange server. Unfortunately, users do not always tell you when they have lost stuff. They just buy a new gadget, set it up, synchronize and do not think twice about the old one and what it contains.
• You might have set the ActiveSync functionality for your users since it is an effective and easy way for them to synchronize their iPads, iPhones, Androids and so on.
  Beware that you also remember to check the various devices associated with the users periodically. 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)

Monitor and logging

• Do not use the “validate reverse DNS” options since a lot of companies have not actually set it up correctly so you will just risk not getting an email from them. The idea is good, but it does not work in real life.
• Enable logging on the connectors and basically enable logging on everything. Read the log files. Do not 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 is really going on. Search for anything out of the ordinary.
• Remember to check your mail queues on a regular basis. If you are starting to have loads of undelivered mail to and from various domains you could have a DNS server that is under attack, not being able to service your Exchange server with the required information.
  There is 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, your 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 have got in place.
• Patch your servers with all the security patches that are released. Do it as quickly as possible. There is absolutely no defense against 0day attacks.
  A 0day is a security bug in the software of the server you are running and they vary on how much impact they may have. The name comes from that it is day 0 of its public release and the manufacturer, in this case, Microsoft has not 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.
• Be sure to have good monitoring of the hardware aspects of your server and operating system aspects (running services, disk space used and so on). Personally, I’m fond of Spiceworks for monitoring server health, licenses and inventory but it all boils down to resources and taking the time to set it up. If you have some working monitoring and someone who deals with the alerts that come up.
• Sign up for the Microsoft Security Bulletin newsletter (and all similar that have to do with your environment). Stay up to date and up to speed on what is going on out there. Being a sysadmin is not a 9-5 job; it is a lifestyle and the ones who do all these things will be better protected once they are attacked.

Have your Disaster Recovery plan in order

Be sure, please, be super sure even, you have adequate backups, containing multiple generations of data and have at least three or four of these complete generations stored off-site in some way. Using an online backup service or just moving your tapes/disk manually out of the building. Test your DRP (Disaster Recovery Plan) at least once a year to verify that your backups contain all you need if something happens. Be sure to 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 are six quite easy questions that sum up what that technical restore plan should contain. It should be able to be read even by 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 are gone (in the freak barbecue accident) and the person reading it has never ever heard of your internal system before.

If you do not have all these things in place, the day something really happens you will regret you did not take the time to do it. Trust me. Grown men have been seen crying and unless it is not for the unexpected death of their favorite dog or a lost game for their favorite sports team, it is not a pretty sight.