Many of you have asked for it, so I’m happy to announce that Exchange ActiveSync is now available as an add-on enhancement. You can activate this add-on through the Control Panel.
Though Exchange ActiveSync has been supported on SmarterMail for some time, it is only now with changes to how Microsoft licenses this technology that we are able to launch this feature.
For those unfamiliar with Exchange ActiveSync, it is a protocol that has become a de facto standard to sync groupware and mobile devices. With the ActiveSync add-on, your email, contacts, calendar and tasks are synchronized between our mail servers and your mobile device (e.g. your smartphone or tablet) in real time.
ActiveSync includes synchronization support for most mobile devices on the market, including Google Android, Apple iPad and iPhone, Motorola, Nokia, HP, Samsung, LG and Windows Phones.
We know that we are a mobile society and having access to information on-the-go is increasingly important for your business and personal life. So we are glad to be able to make this feature available to help you be even more productive.
One of the few things we all have too little of is time. Pretty sure I haven’t been the only one asking for just an extra hour or two when trying to complete a project around here. So when something new comes along that can save a developer some time, I am all about sharing it.
So let me introduce you to Wiwet.
Wiwet provides simple and customizable ASP.NET templates which are easy to use. With a Wiwet template you can have a project that is professional, clean and ready for any device (desktop, mobile, and tablet) in less than 1 minute. As most of you know, developing something like that can be a four week project, so with Wiwet you can save yourself a month or more of development time and effort. Wiwet templates are also responsive, cross-browser, and retina ready.
Starting today, DiscountASP.NET customers can now receive a 20% discount on Wiwet’s responsive ASP.NET templates. For more information on the 20% discount, visit the Marketplace section of Control Panel
If you weren’t already aware, a bug was found in the SSL v3 protocol that could allow hackers to intercept secure traffic. This exploit renders SSL v3 insecure, and unfortunately it is not something that can be fixed. Since one of our primary goals has always been to run a secure platform, we removed SSL v3 support back in October.
If your application connects to a remote HTTP based API service (through web service, WCF service or REST API), you’ve probably already (or soon will) receive a notice from the provider that they will no longer support SSL version 3.0 due to the security bug.
SQL 2014 has been added as a new option when you order SQL service through Control Panel and all the backup, restore, attach mdf tools are available for it as well.
While we were at it, we also added more flexibility to the DNS Manager. You can now create multiple records with the same name, edit and delete the root domain A record, create CNAMEs with the root domain name – and a lot more.
You may or may not have heard, but there is a bash exploit that was recently uncovered called Shellshock, and it is being exploited right now, which is why we patched relatively quickly and without any customer communication.
- Shellshock Bash bug exploitation in full swing, warn researchers
- Cisco, Oracle find dozens of their products affected by Shellshock
We patched quickly, but we did test the patch in our dev environment. And actually, we patched several different servers yesterday afternoon, including the one that failed today. None exhibited any problems immediately after applying the patch.
So what happened?
It appears that there was a problem with a database driver in FreeBSD (which runs all of our DNS servers) related to the patch. Just after noon today we started to see “garbage” records in ns1, and when we looked further we saw that every record in ns1 was corrupt. The name server connects to our database to pull down the current records, and the bug in the database driver caused all of the zones to be corrupt.
We had a pretty good idea that’s what had happened, but since we weren’t completely sure at that point, the decision was made to rebuild ns1 from scratch. One of the benefits of doing that is we still have the old ns1 so we can do some forensic work on it to determine exactly what happened.
Why do these problems keep happening?
The timing of these things is never good, but it’s worse when they happen in succession, as this did right after the DDoS on September 22nd (and the email data corruption on a few servers a couple of weeks before that). The incidents are not related, but any one of them on their own would have been bad enough, we understand that.
We take a lot of preventative measures that you never see, because…well, they prevent problems from happening. But we cannot prevent every conceivable problem or dodge every bullet. Once in a while we’re going to get hit by something. You asked us to keep you informed via Twitter, Facebook and Google+, and I think we’re doing pretty well there. Keep in mind that the people posting there (including myself) are not system administrators, so we’re giving you as much information as we can get, but we may not have full details while a problem is happening.
Speaking of Twitter, Facebook and Google+…
The same few questions seemed to be asked by a lot of people, and I can’t answer them all individually, so let me address them here.
“Why are you doing this in the middle of the day?” A few reasons: first, the potential exploit is so great that we didn’t want to wait for a scheduled maintenance period. Secondly, it’s always the middle of someone’s day. Half of our users are outside of the U.S. So whenever we do something, it’s going to be bad timing for a good number of people. Finally, we did test the patch before deploying it, so we didn’t anticipate any issues.
“Why don’t you just roll back the patch?” The patch was applied almost 24 hours before we saw the corruption, so it wasn’t completely clear that the problem was caused by the patch. System administrators determined that they could rebuild ns1 in less time than they might spend troubleshooting, so that’s what they did. We can second guess that decision, but there’s no way to know how long it would have taken to “fix” the old ns1.
“Why would you install an untested patch on a production server?” As I mentioned previously, we tested the patch in our dev environment and saw no problems with it. And it’s worth remembering that the patch worked on every other server we installed it on without issue. We’ll be doing more tests on the old ns1 to see if we can find out why we had failure there but nowhere else.
– – –
When there’s an outage that affects a lot of you, we certainly understand that it’s bad news. We don’t take any kind of interruption for any number of users lightly, and there’s a lot of activity (and some shouting) in the halls here during those times. We never want to see anything fail, and when something does, everyone on our system administration team is lending their particular expertise and everyone is working together as quickly as they can on a fix.
I know I can speak for everyone here when I say we appreciate you hanging in there with us during times when you’d probably rather be throwing rotten tomatoes at us. Hey, I get it. I’ve wanted to throw my share at any number of companies. We really do appreciate your continued loyalty and understanding.
As a major hosting provider, we deal with compromised sites on a daily basis, so we’ve seen just about every site compromise scenario. If your site is compromised you may wonder, “Why me? What is the benefit to the hacker?”
Chances are it’s not your site specifically that’s being targeted, but rather any site that can be compromised. You just happen to fall into that category. In general, hackers compromise websites for one of the following reasons:
- To get access to a well-connected web server to launch an attack on another network.
- To steal sensitive files or data, e.g. a database containing personal information and credit card numbers.
- To use your site to host spyware, malware or phishing pages.
- To use your site to send out spam.
How do they get through?
Based on our experience, hackers typically compromise sites in the following ways.
Through known security holes in your application
For example, if you are using a wordpress plugin that has security issue and you’ve neglected to update it, hackers can seek out your site using search engines like Google and perform an automated bot attack that will compromise your site. Last month over 50,000 WordPress site were hacked through plugin vulnerability. It can happen to anyone.
Weak Password on your third-party application
Every day we see bots coming into our network scanning for well known applications. Once one of those applications is identified, the bot attempts a brute force dictionary attack to crack the administrator password.
Insecure upload form
This is a very common problem we see virtually every day. Many websites have a photo/document upload mechanism for their users. If the upload application is not secure, hackers can easily upload a webshell. Once the webshell is uploaded, the hacker can upload more files to further compromise your site.
Compromised FTP account
If your local PC is compromised, a hacker can easily install a key logger to capture all your traffic, including email and FTP usernames and passwords. Once they have your account credentials, they can upload anything to your site. If you delete the malicious files but aren’t aware that your credentials have been compromised, they will likely upload the files again every time you delete them.
What we are doing to help
We started noticing a rapid increase in the number of compromised sites about a year ago. We also found that most of our customers needed help fixing and securing their sites. That’s not surprising, considering the lengths many hackers will go to in order to cover their tracks. So we have taken a number of steps in order to help alleviate the problem.
Regular scans for known compromises
We scan every web server looking for known exploits, and we will notify you if we find anything.
SiteLock is a third-party company that provides a daily scanning service that can automatically remove malware and alert you to weaknesses.
Site Cleaning Service
As I mentioned, a lot of people receive a notice from us that their site has been compromised and aren’t really sure what their next step should be. We recently began offering a site cleaning service that will remove malware and compromises, try to identify how they happened, and provide a 30 day follow up to make sure you aren’t compromised again. If we identify a compromise on your site we will provide details about the service.
What you can do to avoid being hacked
There are a number of things you can do to secure your web applications.
Keep your applications up to date
We have seen some customers running third-party applications that are several years old and several major versions behind. If your application doesn’t notify you of updates, make it a point to check for updates yourself every few months. This is the easiest, most effective way to keep your site secure. If you use an application that is no longer being developed or updated, find a replacement that is actively developed! It may be a pain to make that change, but it is worth the effort.
Change the default password
There are bots on the Internet that scan for software that is still using the default password, or administrative user name. WordPress, for example, creates the user “Admin” when it is installed. You should change that username, or create a different admin user and delete the default.
Install Anti-virus software on your computer, and keep it up to date
A free antivirus is better than no antivirus. There are a number of decent programs out there that you can use at no cost. Though a paid version of one of the big antivirus programs is usually going to afford more up to date and comprehensive protection.
Configure FTP to allow only your IP address to connect
You can do this in Control Panel with the ISS Tools FTP Manager. Look for the FTP IP RESTRICTION section.
Use complex password for your web applications, FTP and email (actually for everything!)
We recommend at least 8 characters with at least one upper case letter, one digit and one symbol. The longer it takes to crack your password, the more likely it is that a bot will give up and leave for greener pastures.
If you site has any upload functionality, do the following:
1) Your code should block users from uploading executable file extensions like .asp, .aspx, .php, .exe, etc.
2) Execute permissions should be disabled on the folder where you allow users to upload files. To disable execute permissions, create a web.config file in the folder and include the following:
<configuration> <system.webServer> <handlers accessPolicy="Read" /> </system.webServer> </configuration>
Protecting your site from malicious bots and hackers is more important than ever. Times have changed and a “small” site is no longer safe. They are looking for any site, anywhere, and if you don’t make it difficult for the bad guys to get in, they are going to hit you. It’s not a question of if, but when.
Acquia Drupal 7.30.35
DotNetNuke 7.3.1 Community Edition
Gallery Server Pro 3.2.1
SilverStripe CMS 3.1.5
Umbraco CMS 7.1.4