Sprintserve has been acquired and is now a division of Smartt


Effective October 16th, 2017, Sprintserve has been acquired and is now a division of Smartt. With this acquisition, we bring you continued support and reliability of service along with Smartt’s integrated portfolio of solutions and services across IT Services, Digital Marketing, Web Design and Branding to get you measurable results with a single point of accountability. We also bring a reliable private cloud infrastructure, a lifetime customer base representing over 5,000 companies, and a team of subject matter experts that can provide valuable insight and deliver technology solutions to help you grow your business,

1) How will the ownership change affect my services?

Nothing – except for continued improvements down the pipeline! Smartt will honor all service terms and SLA’s for Sprintserve clients. Your fees, billing, and service support will remain the same while we build trust with you. Our goal is to gradually introduce changes which improve your services by using industry best practices.

2) What improvements can I expect? 

This will be a positive move for everyone. Smartt is a larger, stronger company with more resources, experts, and service offerings to serve you. We will give you the “WOW” impact through our customer-centric culture, along with the right insights and implementation across our expanded portfolio of services across IT Services, Digital Marketing, Web Design, and Branding.

3) Why is Smartt Acquiring Sprintserve? Will there be another acquisition?

Acquisitions of well-managed hosting companies with a loyal client base and strong technical experts are part of Smartt’s long term growth strategy to diversify our services geographically and add technical expertise to our team. Sprintserve is actually our 5th acquisition in the past few years and we are very good at helping clients feel right at home!

4) What happens next?

Everything will continue as usual in the upcoming weeks, except you will be contacted by one of our Account Managers who will spend time gathering feedback on what services are valuable to you and how we can improve them. Smartt will also work over the next 90 days to integrate Sprintserve staff, systems and clients into our infrastructure, billing and support environment.

Finally, where necessary, we will upgrade systems and align them with our own ITIL policies so that we continue to delivery strategically aligned and technically proficient services for you.

5) Are there any changes to the prices?

There are no changes to your pricing and they remain the same.

6) Are there any changes to method of payment?

  1. If you have been paying by credit card, your invoices will continue to be paid by the same credit card with no changes in the procedure. The charges will appear on your Statement as “Smartt”.
  2. If you have been paying by PayPal, you can continue to pay with your current process for now. Further communication will be provided to clients who are paying by PayPal subscriptions within the next two weeks.

7) What is the best method to contact billing team at Smartt?

You can continue to contact us by email: billing@sprintserve.net

8) Will Sprintserve leadership and employees be retained?

Yes. The current staff will remain on and continue to support you. The current SprintServe management team will also stay on in a consultative capacity to ensure the transition is smooth for everyone.

9) Who should I contact for support?

You can continue to request support, changes to your service or billing through the same method you have done to date. Sprintserve staff will be augmented by Smartt staff who will provide technical, account management and other support and guidance throughout the transition and integration.

10) Is this change immediate?


11) Where is the Smartt corporate headquarters?

The corporate office is in Burnaby, British Columbia, Canada.

12) Who do I call if there are any general questions?

All the staff at Smartt are looking forward to working with you in the coming weeks and months. If you have pressing questions that are not answered in this e-mail or the FAQ, and you wish to speak to Smartt team members we welcome you to reach out to us by using the following contact method:

  1. For inquiries about Billing:

E-mail: billing@smartt.com

Tel: 604.473.9700

  1. For inquiries about our Services:

E-mail: support@smartt.com

Tel: 604.473.9700

Critical Windows Exploit – Targeted by Ransomware

The WannaCry ransomware worm, aka WanaCypt0r aka WCry, today spread rapidly over the internet. The worm targets mainly machines in Russia, Ukraine, India and Taiwan initially. However it has a footprint in about 74 countries. Once infected, a machine will also attempt to infect other clients on the same local network. So if you have a machine infected, isolate it immediately to prevent it from spreading.

WannaCry is installed on Windows computers by a worm that spreads across networks by exploiting a vulnerability in Microsoft’s SMB file-sharing services. It specifically abuses a bug designated MS17-010 that Redmond patched in March for modern versions of Windows – unpatched systems, or ones running legacy versions such as Windows XP, are therefore vulnerable and can be attacked.

This was released back in April as part of a leak regarding NSA that publicize the bug and a tool used to exploit it. Hackers have now made use of the tool and strapped it to ransomware.

Further Details are below:

  • In March, Microsoft released a security update which addresses the vulnerability that these attacks are exploiting.
  • For customers using Windows Defender, Microsoft has released an update earlier today which detects this threat as Ransom:Win32/WannaCrypt. Make sure all antivirus / anti-malware software are up to date. Clients running anti-malware software from any number of security companies can confirm with their provider if they are protected.
  • Clients should consider blocking legacy protocols on their networks such as SMBv1.
  • Clients who do not need to mount to network shares should considered disabling by default the SMB service. For newer versions of Windows, you can specifically remove SMBv1 by removing the feature.
  • This impact systems as old as Windows XP. So all your machines including desktops could technically be at risk.

All our Managed Clients running Windows are already protected as we regularly update your system as patches become available.

If you have any questions regarding this exploit or how to implement some of the recommendations above, please feel free to open a ticket with our support: https://www.sprintserve.net/support.

CABundle for Comodo InstantSSL

If you are using Apache / Cpanel / WHM, you may have found that recently you are having issues installing certificates from Comodo InstantSSL.

When you order the certificate, you would receive your certificate in a zipped file, together with 3 other certificate files. Comodo do not really explained clearly how to use the files. In order to create the CABundle, you would need to add them in this order in one file:


For your convenience, you can copy and paste the following instead:



If you need any further information, as always please feel free to contact us.

Another week, another new SSL exploit

Late last week, a new SSL bug was discovered by Google Research Labs. Simply put, due to the large number of protocols, clients and servers, most clients will start with the highest supported protocol and downgrade accordingly in order to be compatible to older servers. The weakness happens in SSLv3 which is 18 years old which can allow an attacker with sufficient computing resources to guess the encrypted data. For the more technical reader, here’s a link with more details.

While exploiting this bug is fairly difficult due to the large amount of computing resources needed, once the exploit was known, our team started putting together an action plan within hours. We started off implementing a patched version of OpenSSL on all servers which support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks.

However we did not stop there. We continue to refine our response and came out with methods to disable SSLv3 on all the main servers on our clients and our own servers. This includes:

  • Apache Web Server
  • WHM / Cpanel Control Panel
  • POP3 / IMAP Mail server
  • Exim SMTP server

This ensures that SSLv3 is no longer available to be exploited even if there’s some still unknown method to exploit it.

While this may break support for older clients, we estimated this to be of very limited impact. The security advantages also fair outweighs the disadvantages. If in doubt, please feel free to contact our support team.

Bash Vulnerability – Shellshock Exploit

What is it?

Chances are, you’ve already heard about the recent discovery of what’s being called the “Shellshock” exploit in GNU Bash. This is a vulnerability that existed in Bash through versions that have span 25 years. However as it is a little used function, the exploit did not come into light till this week. The vulnerability can result in remote execution of arbitrary code.

Bash is widely used by many popular Linux distributions and Mac OS X. This means that the exposure surface is extremely large. As the bug has been in the wild for many years, it is unknown if this exploit have been used in the past.

Critical instances where the vulnerability may be exposed include:

  1. Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn subshells.
  2. Override or Bypass ForceCommand feature in OpenSSH sshd and limited protection for some Git and Subversion deployments used to restrict shells and allows arbitrary command execution capabilities.
  3. Allow arbitrary commands to run on a DHCP client machine, various Daemons and SUID/privileged programs.
  4. Exploit servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.

Am I affected?

For servers running RHEL/CentOS 5/6/7, our team was aware of the issue the same day it was made public on 24th September. Our team worked through the night to ensure the patch was applied within hours after it was released. The first patch was incomplete and we applied a 2nd patch the next day, once again within hours after the patch is available.

With respect to the above potential issues, we will like to explain how our managed servers using our default security policies are unaffected. We have kept it general on purpose:

  1. Most of our servers do not have mod_cgi in use. On top of that, we do not run PHP under CGI wrapper. Further to that, we restrict some key functions of PHP that would have made this a more dangerous bug such as system / exec.
  2. Most of our servers do not allow external shell access. For those that do, we do not use Bash as the shell. There are also other policies limiting access to only authorized users.
  3. We disable all unnecessary services including DHCP, etc during setup.
  4. Please refer to response 2 above. Another exposure surface we can foresee is the use of cron which may allow some users to put malicious commands. However, we currently do not run these jobs under Bash as well, but is using a separate shell.

If you have a specific area or question you like to clarify, please feel free to open a ticket with us. We will be happy to address any concerns directly for our clients.

How to check if a SSL Certificate is expired

Have you ever wondered how you can check the validity of a certain SSL certificate from shell / SSH? There is an useful script that we typically use on our end. If the location provided below is no longer available, please feel free to contact us as we have a copy.

wget http://prefetch.net/code/ssl-cert-check -O /PATH/TO/SAVE/FILE

Replace “/PATH/TO/SAVE/FILE” wieth your own preferred path of choice e.g. “/usr/local/src/ssl-cert-check”. We will now use this path in our example.

cd /usr/local/src/
chmod +x ssl-cert-check
./ssl-cert-check -c /PATH/TO/SSL/YOURDOMAIN.CRT

The script will output whether the certificate is still valid. Enjoy.

How to add date and time to bash history

Have you ever run the command “history” in bash and notice how inadequate that seems by default? You have no idea what date or time a particular command is ran. This makes troubleshooting difficult especially if you are trying to track where certain things go wrong.

To correct this, you can simply add this line to your bash configuration. If you wish to make this system wide and implement for all users:

echo "export HISTTIMEFORMAT='%F %X '" >> /etc/bashrc

If you wish to only implement it for the currently logged in user:

echo "export HISTTIMEFORMAT='%F %X '" >> ~/.bash_profile

There’s lots of ways you can customize your shell to be more useful to you, and this should whet your appetite and get you started. 


How to secure SSH

In our work with clients, we do a lot of server management and security hardening on the servers before it’s released to the clients. One of the first things we typically work on is to ensure SSHd is secured. The reason is that any kernel root exploit will be made easier with shell access.

This tutorial is not meant to be all encompassing, although we will cover a few key areas. We will use Redhat / CentOS Linux distribution as an example and file paths will vary depending on the distribution. We will also use “nano” as the text editor in the examples.

Change the SSH port

While security by obscurity is heavily criticized in some quarters, the truth is due to the time taken to scan all the ports, unless it’s a targeted attack, this step should immediately stop scanners dead in their tracks.

nano /etc/ssh/sshd_config


#Port 22

to (Replace “NEW_PORT” with your port of choice)


Allow only strong protocols

Version 1 of the SSH protocol has many weaknesses, of which it’s out of scope of this article to discuss. But we will be disabling it.

#Protocol 2,1"


Protocol 2

Allow only strong protocols

Version 1 of the SSH protocol has many weaknesses, of which it’s out of scope of this article to discuss. But we will be disabling it.

#Protocol 2,1"


Protocol 2

Disable Password Authentication

We advise that you consider using only key authentication with your server. This means that even if someone someone get your password, your server will continue to be secure. If you are unsure about how to generate a SSH keypair, do refer to our quick tip here.


#PasswordAuthentication yes


PasswordAuthentication no

On top of that, you would need to disable direct root login:


#PermitRootLogin yes


PermitRootLogin without-password


Restart SSHd:

/etc/init.d/sshd restart

Enjoy better SSH security!

How to generate SSH keypairs

We will be using Redhat / CentOS conventions in our examples in terms of the file paths.

Generate the Key Pair

ssh-keygen -t rsa -b 2048

This should generate the files in ~/.ssh/, “id_rsa” and “id_rsa.pub”

id_rsa is your private key and should NEVER be given out. id_rsa.pub is your public key which can be freely shared.

Enjoy better security!