Latest PHP versions updated

iwebzhosting.net php versions settings

We’ve updated the last 3 PHP versions to their latest releases for customers of iwebzhosting.net and the details for the updates are as follows:

5.5.33 to 5.5.34 (a security release)

Several critical flaws have been fixed in this release, so all PHP 5.5 users are now encouraged to upgrade to this version for the sake of security. If you use 5.5 for your sites and applications, you will have the new release applied automatically.

The list of changes is recorded in the ChangeLog.

PHP 5.6.19 to 5.6.20 (a security release)

A few security bugs have been fixed in this release. All PHP 5.6 users are encouraged to upgrade to this version.

If you rely on 5.6 for your sites and apps, then the latest release will be applied accordingly.

The list of changes is recorded in the ChangeLog.

PHP 7.0.4 to PHP 7.0.5 (a security release)

A few important security flaws have been fixed to make the latest PHP version more stable.

All PHP 7.0 users are encouraged to upgrade to this version. If you have already selected PHP 7 for your sites and apps, the new release will apply automatically.

The list of changes is recorded in the ChangeLog.

 

rc4 sream cipher

RC4 Cipher No Longer Supported

Insecure RC4 Cipher

Within the last month, major browsers have removed support for the RC4 Cipher, which was an encryption algorithm available for SSL connections.

Academic research found that this cipher had serious design flaws which could allow attackers to decrypt information using the cipher.

While remarkable for its simplicity and speed in software, multiple vulnerabilities have been discovered in RC4, rendering it insecure. The most important weakness of RC4 comes from the insufficient key schedule; the first bytes of output reveal information about the key.

Support dropped

Support for RC4 was officially dropped with Chrome v48 and Firefox v44, both released in late January. Microsoft’s Edge browser and IE11 will also be dropping support for the cipher.

In Chrome, if a SSL connection is attempted with RC4 a non-bypassable error will be displayed. This will entirely prevent users from accessing such sites.

To see how this error will look to users, visit rc4.badssl.com in your browser(s). Data suggests that less than 10% of sites prioritize the RC4 cipher in modern browsers.

 

Jail Host now enabled by default for all new hosts

jail hostNow all newly added hosts on our platform will have ‘Jail Host’ protection enabled by default. Learn more about this innovative hosting security feature.

What does the Jail Host option stand for?

By activating the ‘Jail Host’ option for a given host, you practically isolate it from the other domains within the www/ directory of the same hosting account.

This way, if hackers try to attack the given host, they will be immediately ‘punished’ and ‘jailed’ in that host.

By being ‘jailed’, the intruders will not be able to use the host as a doorway to the rest of the system where the other hosts of yours are located.

This restriction works at the Operating System level, which will guarantee its efficiency in all cases of hack attacks on the given host.

When could I use the Jail Host option?

The ‘Jail Host’ functionality can come in real handy when you hire a webmaster to work on your site. If you do not know the webmaster in person, then it would be reasonable to take all measures to protect your host.

In this case, most hosting providers would recommend giving the guy limited FTP access to the particular host. However, if the guy comes with cruel intentions, they will still be able to break the FTP barrier and to litter your account with malicious scripts. If you ‘jail’ the host first, you’ll never risk putting your hosting account as a whole at risk.

How do I activate the Jail Host option?

The ‘Jail Host’ option is integrated into the Hosted Domains section of the iWebz Web Hosting Control Panel. It is available with all shared hosting plans, semi-dedicated servers and dedicated servers. The option is not available with our Virtual Private Servers because of its incompatibility with the virtualization technology.

In the Hosted Domains section, click on the Edit Host icon at the end of the Actions column.
The Jail Host functionality is located at the bottom of the Edit Host form. Just tick the box and click on the Edit Host button.

Does the Jail Host option involve any other restrictions?

From a ‘jailed’ host, you will not be able to access the files hosted under a different domain within the same account. So, if you want to use them, you will need to deactivate the ‘Jail Host’ option first.

However, all the other domains in the account will have access to the ‘jailed’ host’s file system.

The ‘Jail Host’ option helps users address a very specific security glitch, which lies deep under the surface.

Thus, it will add a new level of protection to our customers’ websites and is relevant to customers who are sensitive about online security. Actually, who isn’t?

What’s more, ‘Jail Host’ is a completely innovative option on the web hosting market and cannot be currently found readily implemented on any other hosting platform.

 

New PCI Standard: Disable SSL 3.0 & TLS 1.0 by June 2016

PCI DSS 3.1 SSL TLS

Image courtesy Security Metrics blog

New guidelines dictating the requirements for PCI Compliance, version 3.1 of PCI Data Security Standards (PCI DSS), were released in April. These guidelines must be followed for all companies who take payments over the Internet. A key part of the new PCI DSS are stricter requirements around the use of TLS (SSL).

PCI DSS v3.1 states that SSL 3.0 and TLS 1.0 “can no longer be used as a security control after June 30th, 2016.” This means that disabling these protocol versions is required in order to be compliant with handling sensitive cardholder data.

Any time we discuss protocols, we like to remind our readers that the true name of the modern protocol is Transport Layer Security (TLS), not SSL. The most recent version of the protocol is TLS 1.2, and the last version to be released under the name “SSL”, was SSL 3.0 way back in 1996.

After the POODLE attack discovered late last year, SSL 3.0 was effectively retired. The newest versions of most modern browsers no longer support SSL 3.0, and everyone should check their servers to make sure they have disabled support for that insecure protocol.

Disabling protocol versions is easy – once you locate where your server stores the configuration settings for SSL, it takes less than a few minutes to update. The hard part of meeting these requirements will be to make a risk assessment of your user base to determine if removing TLS 1.0 support will be problematic.

Remember that PCI DSS dictates technical requirements and procedures for servers that are directly handling user payment information, personal records, and administrative access. So if you do not take payments directly – but instead use a provider such as Paypal, Authorize.net, or Square, you may not have to be PCI Compliant. For companies who do handle payments directly, it’s not necessarily required to make these changes network wide. For many networks and companies this will ease compliance.

So, if you are affected by these changes, how much time do you have?

The deadline for ending support for SSL 3.0 and TLS 1.0 is June 30th, 2016, just about a year from now. However this comes with some caveats. “Effective immediately, new implementations must not use SSL or [TLS 1.1],” and existing implementations must have a “formal Risk Mitigation and Migration Plan in place.”

So while the hard deadline on abandoning these old SSL protocols is about 12 months away, the easiest option will be to migrate from these protocol versions now.

The PCI Security Standards Council suggests you only support TLS 1.2 for optimal configuration. This is because all protocol versions except for TLS 1.2 are vulnerable, though you may find users’ devices do not support this version so for practical versions this may not be possible. If you do keep TLS 1.1 enabled, make sure you optimize your configuration to avoid potential security flaws.

If you or your clients handle user data which requires PCI compliance, you will want to consult directly with their new PCI DSS v3.1 Standards, available here:
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

A summary of the changes specifically affecting SSL are available here:
https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf