Starting in July 2018, your site will be marked as “insecure” by Googles Chrome browser.
We have added free SSL certificates for all our customers so that you are ready to go right now.
However, often you will need to make some changes to your website to ensure that it uses https:// instead of http://
Here we are showing you how to re-configure your WordPress to use https:
First, login to your WordPress admin and change the WordPress Address and Site Address to https://…
Now, if you made the mistake to use absolute links or images in your WordPress in the past, you now need to change those from http:// to https://.
You could simply go through each and every post and page of your WordPress and manually make that change.
If you however have hundreds of pages and post like us, we suggest to use a Search and Replace plugin instead.
The first step for this is to MAKE A BACKUP:
Login to your Control panel and access Softaculous.
Follow the steps until the backup is complete.
Now go back to your WordPress Admin.
Now, if you want to be really safe, click Create SQL File and then Download SQL file.
This will give you a backup of the database just in case something goes wrong and can be restored very easily using the SQL Import tab.:
Now you click on the Search & Replace tab.
Enter http:// in the Search for field.
Enter https:// into the Replace with: field.
Check the box “Select all tables”
and Dry Run. (This is to test what will happen before anything actually happens.
Click Do Search & Replace.
Here is an example of the result:
Clicking on view details will show you what actually will be changed.
If you are using Drupal on your website please read on…
The Drupal CMS team has fixed a highly critical security flaw that allows hackers to take over site just by accessing a URL. We highly recommend that Drupal site owners immediately update your sites to Drupal 7.58 or Drupal 8.5.1, depending on the version you’re running. If you are unsure how to do so, please contact our Support team.
The Drupal team pre-announced the recent patches last week when it said “exploits might be developed within hours or days” after the disclosure.
This new Drupal Vulnerability allows an attacker to run any code he desires against the Drupal CMS’ core component, effectively taking over the site. The attacker doesn’t need to be registered or authenticated on the targeted site, and all the attacker needs to do is access the URL.
A nickname for this Drupal Vulnerability is “Drupalgeddon2”.
Drupal 6 is also affected. However, since Drupal was declared end of life (EOL) in 2016, NO patches will be issued by the Drupal Team.
HelpingHost.com is happy to announce a new partnership with CloudFlare, the web’s easiest performance and security solution. As a CloudFlare Certified Partner, we deliver their simple and free solution to help protect and accelerate your website. Once your website joins the CloudFlare community, it loads twice as fast and is protected from a range of online threats.
Getting started is super easy—you just need to log into your control panel and look for the CloudFlare icon. With two clicks, you can activate CloudFlare and your website will automatically be faster and safer around the world.
We are pleased to offer you the CloudFlare service for FREE. There is no commitment. Turning CloudFlare on and off takes two clicks of the mouse, so feel free to try it out. We think you’ll like it.
To learn more about CloudFlare, you can take a look at our CloudFlare Hosting page here.
With the recent Joomla exploit it became even more clear that we hsphere hosters have to find a way to get the latest PHP versions onto our servers.
We are using CloudLinux on every web server already to take advantage of its ability to keep customers resource usage in check.
CloudLinux also comes with alternative PHP packages (alt-php) including hardened PHP which are EOL php versions that the CloudLinux team keeps patching.
For several weeks we researched ways to use the alternative PHP packages as replacements for hsphere PHP.
Good news! We did it!
Before we go into detail on how this was accomplished, please keep in mind our hsphere web setup before any changes are made:
- – Apache 2 worker mode
- – FCGID active
- – mod_hostinglimits active
- – CloudLinux 5 with Hybrid Kernel (CL6 will work just as well)
Now on to how we accomplished the goal of replacing hsphere PHP with Cloudlinux PHP.
At first we tried to get a custom suexec from CL to replace the hsphere suexec. However, under hsphere, the pathnames to all PHP binaries are actually hardcoded into the suexec. So, a custom suexec with just adjusted parameters will NOT work.
Next, we decided to try to litterally replace the hsphere php binaries with cloudlinux binaries.
This turned out to work pefectly well even though sadly cagefs will not work within PHP scripts due to the missing custom suexec.
Here are the steps:
- yum install cagefs lvemanager -y
- yum groupinstall alt-php -y
- yum install alt-php54-zend-guard-loader -y (only on CL5)
- /usr/sbin/cagefsctl –init
- Now copy the sample PHP ini files from one user to /etc. Reason is that under Hsphere, the suexec does not respect cagefs which means php is looking for the php.ini in /etc/cl.php..
cp -r /var/cagefs/00/[SAMPLEUSER]/etc/cl.php.d /etc/
- edit the global php ini file to your liking: /etc/cl.selector/global_php.ini. What you add here will be compiled into each global php.ini in the next step
- /usr/sbin/cagefsctl –setup-cl-selector
- The last step is to copy the CloudLinux php binaries over the old hsphere binaries.
Reason this needs to be done this way is that the hsphere suexec containts the path to the php binaries hardcoded.cp -f /opt/alt/php44/usr/bin/php-cgi /hsphere/shared/php4/bin/php
cp -f /opt/alt/php52/usr/bin/php-cgi /hsphere/shared/php5/bin/php
cp -f /opt/alt/php53/usr/bin/php-cgi /hsphere/shared/php53/bin/php
cp -f /opt/alt/php54/usr/bin/php-cgi /hsphere/shared/php54/bin/php
cp -f /opt/alt/php55/usr/bin/php-cgi /hsphere/shared/php55/bin/php
cp -f /opt/alt/php53/usr/bin/php-cgi /hsphere/shared/php-internal/bin/php
(You need to use PHP 5.3 for internal PHP, otherwise the webshell will no longer work)
rm -f /usr/bin/php
rm -f /usr/local/bin/php
ln -s /opt/alt/php55/usr/bin/php /usr/bin/php
ln -s /opt/alt/php55/usr/bin/php /usr/local/bin/php
BTW, nothing stops you from for example doing a:
cp -f /opt/alt/php5.6/usr/bin/php-cgi /hsphere/shared/php4/bin/php
So, if nobody uses PHP 4.4 anymore on a server you convert it to PHP 5.6 this way, or if you are on CL6 you can use PHP 4.4 to be PHP 7.
A second variety of the Spectre exploit was recently discovered.
The CVE named it: CVE-2017-5715 [branch target injection]
All servers have now been patched against the so called “Spectre Variant 2”.
Simple Explanation of Meltdown and Spectre:
By now I’m sure you have heard about Meltdown and Spectre.
They are names to describe exploits that take advantage of bugs in most modern processors.
In the Common Vulnerabilities and Exposures List the following code numbers were assigned:
Any company that runs software on computers will have to apply patches to protect themselves and their customers.
The action HelpingHost.com took:
The race was on to patch these vulnerabilities. HelpingHostcom has patched all Servers against the recently discovered Meltdown and Spectre bugs on the same day as our Software vendors released the patches.
For the those of you wondering: CVE-2017-1000253 a kernel vulnerability has been patched on all HelpingHost.com Servers.
Many of you are probably wondering if you have to worry about the Heartbleed vulnerability if you are hosted with HelpingHost.com.
The short answer is NO.
Heartbleed is a recently found vulnerability in the so called “TLS heartbeat extension” of OpenSSL. A piece of software installed on most web servers.
This TLS extension however was only added to OpenSSL in Version 1.0.1 and newer which means that older versions of OpenSSL simply do not have this featrure.
The infrastructure currently in production here at HelpingHost.com is based on CentOS 5 and Redhat Enterprise Version 5.
These operating systems are using a secure and fully vendor patched OpenSSL version 0.9.8e.
Because of this our servers (your websites) are NOT affected by the Heartbleed vulnerability (CVE-2014-0160).