Category Archives: Security

Debian Install SSL Certificates for Apache OpenSSL

Something else that I do not do often and have never documented is the install of an SSL certificate on Debian servers for use with Apache / OpenSSL. For this post I am assuming that an existing SSL certificate has been purchased. I use a lot of wildcard certificates for multiple servers rather than a certificate per site / server.

Go to this directory

[text]# cd /etc/ssl/private/[/text]

By default there is a self-signed certificate key ssl-cert-snakeoil.key in the directory

This directory is restricted to root user and ssl-cert group.

Using an existing certificate, key, and intermediate certificate, create a file for each in the same directory.

Change the relevant ownership

[text]# chown root:ssl-cert *[/text]

and change the access

[text]#chmod 640 *[/text]

This should provide something like:

[text]

/etc/ssl/private# ls -la
drwx–x— 2 root ssl-cert 4096 Apr 14 12:12 .
drwxr-xr-x 4 root root     4096 Mar 28 08:41 ..
-rw-r—– 1 root ssl-cert 1589 Apr 14 12:11 mydomain-intermediate.crt
-rw-r—– 1 root ssl-cert 1704 Mar 20 23:25 ssl-cert-snakeoil.key
-rw-r—– 1 root ssl-cert 2049 Apr 14 12:10 mydomain-cert.crt
-rw-r—– 1 root ssl-cert 1678 Apr 14 12:13 mydomain-key.key

[/text]

Ok, now off to the Apache config

[text]# cd /etc/apache2/sites-available/[/text]

and edit the site file that is relevant so that the Virtual Host *:443 section includes the correct paths to the above certificate files

[text]
# Example SSL configuration
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLCertificateChainFile "/etc/ssl/private/mydomain-intermediate.crt"
SSLCertificateFile "/etc/ssl/private/mydomain-cert.crt"
SSLCertificateKeyFile "/etc/ssl/private/mydomain-key.key"

[/text]

If there is no Virtual Host *:443 section then there should be an existing VirtualHost *:80 for the website and this can be copied / duplicated in the same file, just change the port in the copy from 80 to 443 and insert the above Example SSL lines at the bottom of the new section above the closing tag.

If Apache is a fresh install it may not have SSL enabled

[text]#a2enmod ssl [/text]

Test Apache syntax

[text]#apachectl -t [/text]

Restart Apache
[text]#apachectl graceful [/text]
or
[text]#service apache2 restart [/text]
depending on what you need for existing sites on the server.

 

CVE-2015-0235 Ghost glibc Debian Wheezy CentOS 5.11 6.6 gethost security Testing

Thanks to https://gist.github.com/koelling/ef9b2b9d0be6d6dbab63 for a script to test for this vulnerability.

Update: Another option for Debian, at least, is to check ldd –version

[code]ldd –version
ldd (Debian EGLIBC 2.13-38+deb7u7) 2.13[/code]

Check the last digit in the minor release number, ‘deb7u7’ is good, ‘deb7u6’ or less are vulnerable.

First download the file:

[code]wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c[/code]

If you have a certificate error you may want to use the wget –no-check-certificate option

[code]wget –no-check-certificate https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c[/code]

Then run this to check

[code]gcc gistfile1.c -o CVE-2015-0235[/code]

You may get a gcc file not found error

[code]# gcc gistfile1.c -o CVE-2015-0235
-bash: gcc: command not found[/code]

— I am assuming at this time that it means th GNU LibC glibc is not installed and therefore the system is not vulnerable. Similarly the Synology NAS devices that I use are all showing a null result for glibc.

…..but if gcc is available, then use this to show the result:

[code]./CVE-2015-0235[/code]

Either your will be “vulnerable” or “not vulnerable”

and you can follow my adventures in patching Debian and CentOS / CPanel servers for glibc in another post.

Thanks to https://news.ycombinator.com/item?id=8953545 for linking me to this originally.

CVE-2015-0235 Ghost glibc Debian Wheezy CentOS 5.11 6.6 gethost security issue

So another security issue on Linux.  I have multiple servers to worry about and they are mostly based on two distributions of Debian and CentOS.

Because it is a newly found vulnerability some mirror sites are not up to date so in trying to patch my servers I found the following to be helpful.

Debian

Check this for https://security-tracker.debian.org/tracker/CVE-2015-0235 the Debian versions that are affected.

My Debian Wheezy servers showed:

[code]$ ldd –version
ldd (Debian EGLIBC 2.13-38+deb7u6) 2.13[/code]

or even older

[code]$ ldd –version
ldd (Debian EGLIBC 2.13-38+deb7u4) 2.13[/code]

so I ran the following on them

[code]# apt-get update && apt-get dist-upgrade[/code]

Watching and hitting the Y for yes when prompted. I could have used apt-get upgrade but I figured since I was doing upgrades I might as well do them completely. I like this post for a great explanation of the differences between the two options http://askubuntu.com/questions/194651/why-use-apt-get-upgrade-instead-of-apt-get-dist-upgrade.

and after the patching I get

[code]# ldd –version
ldd (Debian EGLIBC 2.13-38+deb7u7) 2.13[/code]

which tells me that I have the latest and should not be vulnerable.

CentOS

CentOS on one server was version 5.11 and did not want to update anything when I tried to use

[code]# yum update glibc[/code]

So I checked and ran an update but found the same result, ie the mirror that yum used was not giving out a 27th January 2015 update. So I made a change in the /etc/yum.repos.d/CentOS-Base.repo file to comment out the mirrorlist line and enable (uncomment) the baseurl line which goes direct to the CentOS servers that have patches from today that address the issue.

How to tell which version of CentOS you have?

[code]# cat /etc/*release*[/code]

will respond with something like

[code]CentOS release 6.5 (Final)[/code]

So the process is to update glibc specifically and

[code]# yum update glibc[/code]

Which should prompt for and find updates like this:

[code]

Resolving Dependencies
–> Running transaction check
—> Package glibc.i686 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc.x86_64 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc.i686 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc.x86_64 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc-common.x86_64 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc-common.x86_64 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc-devel.i686 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc-devel.x86_64 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc-devel.i686 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc-devel.x86_64 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc-headers.x86_64 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc-headers.x86_64 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc-static.x86_64 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc-static.x86_64 0:2.12-1.149.el6_6.5 will be an update
–> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size
================================================================================
Updating:
glibc i686 2.12-1.149.el6_6.5 updates 4.3 M
glibc x86_64 2.12-1.149.el6_6.5 updates 3.8 M
glibc-common x86_64 2.12-1.149.el6_6.5 updates 14 M
glibc-devel i686 2.12-1.149.el6_6.5 updates 984 k
glibc-devel x86_64 2.12-1.149.el6_6.5 updates 983 k
glibc-headers x86_64 2.12-1.149.el6_6.5 updates 612 k
glibc-static x86_64 2.12-1.149.el6_6.5 updates 1.4 M

Transaction Summary
================================================================================
Upgrade 7 Package(s)

Total download size: 26 M
Is this ok [y/N]:

[/code]

This is where I hit Y for yes and watched it continue to download and upgrade glibc.

Finally for all of the servers I used a test script for CVE-2015-0235 glibc ghost that was provided from elsewhere.

Next is VMWare, Watchguard, and anything else that might have glibc.

Debian Linux openvpn connect to Watchguard VPN

I have a Debian Server that I wanted to connect to a Watchguard VPN.

OpenVPN is the tool that I used and the following is based on JoKi’s excellent blog entry with my own adjustments to address the issues that I found.

To start you do need to install and run a connection using the Watchguard MobileVPN on your Windows box to get the configuration files in

C:Usersyour_user_name_hereAppDataRoamingWatchGuardMobile VPN

It took me a while to work out that I had to run it to get the config files created, installing alone is not enough.

Installation in Debian is straightforward

#apt-get install openvpn

Once that is done go to the newly created /etc/openvpn and copy the files from the abovementioned Watchguard directory to it.

ca.crt
client.crt
client.ovpn
client.pem

Now it should all be good to go.

#openvpn --config client.ovpn

Except that I was getting all sorts of errors and warnings……

Wed Nov 12 12:16:50 2014 VERIFY X509NAME ERROR: /O=watchguard_technologies/0.0=f ireware/CN=fireware_sslvpn_server, must be /O=watchguard_technologies/ITU-T=fire ware/CN=fireware_sslvpn_server
Wed Nov 12 12:16:50 2014 TLS_ERROR: BIO read tls_read_plaintext error: error:140 90086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Nov 12 12:16:50 2014 TLS Error: TLS object -> incoming plaintext read error
Wed Nov 12 12:16:50 2014 TLS Error: TLS handshake failed
Wed Nov 12 12:16:50 2014 Fatal TLS error (check_tls_errors_co), restarting
Wed Nov 12 12:16:50 2014 SIGUSR1[soft,tls-error] received, process restarting
Wed Nov 12 12:16:50 2014 Restart pause, 5 second(s)

Everything I read said that the certificate files would be the issue, but that was not logical to me as they were direct from the Watchguard device and not ones I was creating.

But I checked them anyway with

#openssl verify -CAfile ca.crt client.crt

Next I tried addressing the verify X509 Name error by changing the client.ovpn file entry changing

tls-remote

to

verify-x509-name

and messed around with that for a while until in disgust I commented the line out to try and confirm that it was triggering the error.

Of course, it worked first time !!!  Argghhhh!!

So the answer to the above is to remove the tls-remote line completely from the configuration file.

tls-remote “/O=watchguard_technologies/ITU-T=fireware/CN=fireware_sslvpn_server”

Either comment it with # at the start of the line or delete it.

Once that was sorted I had a working connection all that remained was to

#mv client.ovpn client.conf

create an auth.txt file with

myusername
mysecretpassword

#chmod to 0600 auth.txt

Edit the client.conf file to have

auth-user-pass auth.txt

and finally start it as a service
#service openvpn start client

and the last bit of the puzzle, to add it as a service to automatically start

#update-rc.d openvpn enable

Thanks to JoKi for getting me started.