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:

AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt

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

-----BEGIN CERTIFICATE-----
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFdDCCBFygAwIBAgIQJ2buVutJ846r13Ci/ITeIjANBgkqhkiG9w0BAQwFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFow
gYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYD
VQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkq
hkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkehUktIKVrGsDSTdxc9EZ3SZKzejfSNw
AHG8U9/E+ioSj0t/EFa9n3Byt2F/yUsPF6c947AEYe7/EZfH9IY+Cvo+XPmT5jR6
2RRr55yzhaCCenavcZDX7P0N+pxs+t+wgvQUfvm+xKYvT3+Zf7X8Z0NyvQwA1onr
ayzT7Y+YHBSrfuXjbvzYqOSSJNpDa2K4Vf3qwbxstovzDo2a5JtsaZn4eEgwRdWt
4Q08RWD8MpZRJ7xnw8outmvqRsfHIKCxH2XeSAi6pE6p8oNGN4Tr6MyBSENnTnIq
m1y9TBsoilwie7SrmNnu4FGDwwlGTm0+mfqVF9p8M1dBPI1R7Qu2XK8sYxrfV8g/
vOldxJuvRZnio1oktLqpVj3Pb6r/SVi+8Kj/9Lit6Tf7urj0Czr56ENCHonYhMsT
8dm74YlguIwoVqwUHZwK53Hrzw7dPamWoUi9PPevtQ0iTMARgexWO/bTouJbt7IE
IlKVgJNp6I5MZfGRAy1wdALqi2cVKWlSArvX31BqVUa/oKMoYX9w0MOiqiwhqkfO
KJwGRXa/ghgntNWutMtQ5mv0TIZxMOmm3xaG4Nj/QN370EKIf6MzOi5cHkERgWPO
GHFrK+ymircxXDpqR+DDeVnWIBqv8mqYqnK8V0rSS527EPywTEHl7R09XiidnMy/
s1Hap0flhFMCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUu69+Aj36pvE8hI6t7jiY7NkyMtQwDgYDVR0PAQH/BAQD
AgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9
MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVy
bmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggEBAGS/g/FfmoXQ
zbihKVcN6Fr30ek+8nYEbvFScLsePP9NDXRqzIGCJdPDoCpdTPW6i6FtxFQJdcfj
Jw5dhHk3QBN39bSsHNA7qxcS1u80GH4r6XnTq1dFDK8o+tDb5VCViLvfhVdpfZLY
Uspzgb8c8+a4bmYRBbMelC1/kZWSWfFMzqORcUx8Rww7Cxn2obFshj5cqsQugsv5
B5a6SE2Q8pTIqXOi6wZ7I53eovNNVZ96YUWYGGjHXkBrI/V5eu+MtWuLt29G9Hvx
PUsE2JOAWVrgQSQdso8VYFhH2+9uRv0V9dlfmrPb2LjkQLPNlzmuhbsdjrzch5vR
pu/xO28QOG8=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGCDCCA/CgAwIBAgIQKy5u6tl1NmwUim7bo3yMBzANBgkqhkiG9w0BAQwFADCB
hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV
BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMjEy
MDAwMDAwWhcNMjkwMjExMjM1OTU5WjCBkDELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxNjA0BgNVBAMTLUNPTU9ETyBSU0EgRG9tYWluIFZh
bGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAI7CAhnhoFmk6zg1jSz9AdDTScBkxwtiBUUWOqigwAwCfx3M28Sh
bXcDow+G+eMGnD4LgYqbSRutA776S9uMIO3Vzl5ljj4Nr0zCsLdFXlIvNN5IJGS0
Qa4Al/e+Z96e0HqnU4A7fK31llVvl0cKfIWLIpeNs4TgllfQcBhglo/uLQeTnaG6
ytHNe+nEKpooIZFNb5JPJaXyejXdJtxGpdCsWTWM/06RQ1A/WZMebFEh7lgUq/51
UHg+TLAchhP6a5i84DuUHoVS3AOTJBhuyydRReZw3iVDpA3hSqXttn7IzW3uLh0n
c13cRTCAquOyQQuvvUSH2rnlG51/ruWFgqUCAwEAAaOCAWUwggFhMB8GA1UdIwQY
MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSQr2o6lFoL2JDqElZz
30O0Oija5zAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0gBBQwEjAGBgRVHSAAMAgG
BmeBDAECATBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNv
bS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB
AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E
T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21v
ZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAE4rdk+SHGI2ibp3wScF9BzWRJ2p
mj6q1WZmAT7qSeaiNbz69t2Vjpk1mA42GHWx3d1Qcnyu3HeIzg/3kCDKo2cuH1Z/
e+FE6kKVxF0NAVBGFfKBiVlsit2M8RKhjTpCipj4SzR7JzsItG8kO3KdY3RYPBps
P0/HEZrIqPW1N+8QRcZs2eBelSaz662jue5/DJpmNXMyYE7l3YphLG5SEXdoltMY
dVEVABt0iN3hxzgEQyjpFv3ZBdRdRydg1vs4O2xyopT4Qhrf7W8GjEXCBgCq5Ojc
2bXhc3js9iPc0d1sjhqPpepUfJa3w/5Vjo1JXvxku88+vZbrac2/4EjxYoIQ5QxG
V/Iz2tDIY+3GH5QFlkoakdH368+PUq4NCNk+qKBR6cGHdNXJ93SrLlP7u3r7l+L4
HyaPs9Kg4DdbKDsx5Q5XLVq4rXmsXiBmGqW5prU5wfWYQ//u+aen/e7KJD2AFsQX
j4rBYKEMrltDR5FL1ZoXX/nUh8HCjLfn4g8wGTeGrODcQgPmlKidrv0PJFGUzpII
0fxQ8ANAe4hZ7Q7drNJ3gjTcBpUC2JD5Leo31Rpg0Gcg19hCC0Wvgmje3WYkN5Ap
lBlGGSW4gNfL1IYoakRwJiNiqZ+Gb7+6kHDSVneFeO/qJakXzlByjAA6quPbYzSf
+AZxAeKCINT+b72x
-----END CERTIFICATE-----

 

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

Change:

#Port 22

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

Port <NEW_PORT>

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.
Change:

#Protocol 2,1"

to

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.
Change:

#Protocol 2,1"

to

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.

Change:

#PasswordAuthentication yes

to

PasswordAuthentication no

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

Change:

#PermitRootLogin yes

to

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!

Sprintserve Net Offers Multiple PHP Versions

Sprintserve NET is happy to announce the immediate availability of multiple PHP versions. We will make available PHP 5.2, 5.3, 5.4 and 5.5, with the current default being PHP 5.2.  No action is required from you if you are happy with the current version of PHP. However we strongly encourage to test your scripts with one of the newer PHP versions.

What do I need to know: 

  • The current default PHP version 5.2.17 remains the default. No action is needed if you want to continue using this version.
  • The current alternate versions supported are PHP 5.3.28, 5.4.28 and 5.5.12.
  • We strongly encourage all clients to upgrade to a newer PHP version as PHP 5.2.17 and 5.3.28 has been deprecated. We expect to change the default version in the near future as it is no longer supported by Cpanel.
  • Please note that there are major changes between the different versions, and that it is the client’s responsibility to ensure that their scripts are compatible with the various PHP versions.
  • Upgrading from PHP 5.2 to 5.3: http://php.net/migration53
  • Upgrading from PHP 5.3 to 5.4: http://php.net/migration54
  • Upgrading from PHP 5.4 to 5.5: http://php.net/migration55


How do I enable PHP 5.3, 5.4 or 5.5:
PHP 5.3
Add the following to your .htaccess in your home directory:
<IfModule mod_suphp.c>
AddHandler application/x-httpd-php53 .php
</IfModule>

PHP 5.4
Add the following to your .htaccess in your home directory:
<IfModule mod_suphp.c>
AddHandler application/x-httpd-php54 .php
</IfModule>

PHP 5.5
Add the following to your .htaccess in your home directory:
<IfModule mod_suphp.c>
AddHandler application/x-httpd-php55 .php
</IfModule>

To reverse the change, simply remove the directives that have been added. As always feel free to contact our support if you need further assistance.

Openssl Vulnerability – Heartbleed Bug

What is it?

Chances are, you’ve already heard about the recent discovery of what’s being called the “Heartbleed” bug in OpenSSL. Basically, this is a vulnerability that existed in OpenSSL for around 2+ years. The vulnerability caused by a gap where encrypted information could potentially be leaked out to hackers. It is important to note that this is NOT due to a flaw in SSL, but rather the platform and implementation of the latest batch of OpenSSL updates.

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

Given the widespread use of OpenSSL on the internet as the implementation for SSL, and the fact that the bug has been in the wild for years, this means that it is possible that a lot of sensitive information may have been stolen by hackers.

Am I affected?

For servers running RHEL/CentOS 5, the version of OpenSSL used is not affected. For servers running RHEL/CentOS 6, the bug was patched the same day the bug was made public. For all servers managed and hosted with us, we have automatically patched the bug the day it was made public on affected servers. However this does mean that you are not vulnerable to the issue. The key used for your SSL certificates may have already been stolen in the time the bug is in the wild.

For safety, if you are running RHEL/CentOS 6, you are recommended to rekey your domain and request for a reissue of the certificate. If you ordered the certificate from us, we will be regenerating the keys and reissuing the certificates automatically as well.

Personally if you have changed your passwords on any affected sites over the past 2 years, you are encouraged to confirm that the affected site have updated their certificates and change your passwords again.