Last week Kali Linux 2016.2 was released so it was time to make a new VirtualBox instance for it to see the difference from the release in January. But let’s automate a little bit to quickly rebuild virtual machines for Kali Linux.
$ cd ~/Downloads
$ wget http://cdimage.kali.org/kali-2016.2/kali-linux-2016.2-amd64.iso
Let’s create the virtual machine and boot it. In this example it is bound to the wireless network card and allocates an 16 GB disk image as the default 8 GB size for Debian is too small and 10 GB is the minimum advised.
Yesterday I wrote a post about disabling SSLv3 in Postfix and today we take a close look at Apache. While taking a closer look at the current installation of Apache and the version shipped with Debian 8 that was released a few days back it showed that or the Apache project or Debian has taken the responsibility to completely disable SSLv2. Hopefully SSLv3 will get the same treatment soon, as broken security is worse than no security due to the false sense of security.
First we see that the cipher suite are different between both and for now I’ll ignore them. Those will be touched in a later posting as RC4 also needs to be phased-out. For Debian Jessie installations everything is well on protocol level, but for Wheezy the option “-SSLv3” is missing and since TLS is compiled into Apache and OpenSSL on Debian Wheezy it is pretty safe to turn SSLv3 off unless you want to keep servicing Internet Explorer 6.
SSLProtocol all -SSLv3 -SSLv2
As with Postfix also for Apache a hard restart to enforce this on all connection from that point forward to make sure no one keeps an old connection with SSLv3.
$ sudo systemctl restart apache2.service
Keep in mind that these setting can be set also on a virtual host level within Apache and will override any global setting. So it may be wise to also verify other configuration files for Apache and/or run sslscan against your websites to verify the SSL protocol offered.
The POODLE attack was made public late 2014 and as most vendors have taken action to solve possible issues related to POODLE. The time definitely has come to close SSLv3 in all parts of public facingÂ infrastructure. By default Postfixstill only disallows SSLv2 and hopefully this will change in the form of stricter default behaviour in Postfix or distributions/vendors that stop shipping SSLv3 libraries.
For now you can set with the postconf command restrictions which protocols shouldn’t be used by Postfix.
As this is a change to /etc/postfix/main.cf Postfix can be reloaded to reread the configuration, but it may be smarter to just restart Postfix to make it effective for all connection from the moment Postfix restarts.
$ sudo systemctl restart postfix.service
All encrypted sessions Postfix allows will require TLSv1+. The next step will be to disable the RC4 cipher suite, but will do that in another posting.
Installing and configuring SSL certificates is always an issue as how to create them and where to store them. Most of the time people can find the procedure on how to create them, but they forget all the places where they have placed them. Some initiatives exist to have centralized key stores on systems, but getting applications to use them is still a problem.
Also on Debian is this an issue and key material is all over the system if you’re not careful. Some DebianÂ developersÂ tried to fix it, but it ended in a “stalemate” and for now an additional package called ssl-cert exists to create self-signed certificates. This package also provides a structure for storing commercial certificates and accessing them in a safer way. So for we install the package ssl-cert.
$ sudo apt-get install ssl-cert
After installing the package the different files for the SSL-key can be placed in /etc/ssl/private and have the right permissions as shown in the output below. This to protect the key material from being use by unauthorized processes as most keys don’t have a passphrase.
$ sudo ls -l /etc/ssl/private
-r--r----- 1 root ssl-cert 2766 Dec 12 13:06 www.example.org_ca.pem
-r--r----- 1 root ssl-cert 1671 Dec 12 13:06 www.example.org.crt
-r--r----- 1 root ssl-cert 1070 Dec 12 13:06 www.example.org.csr
-r--r----- 1 root ssl-cert 6268 Dec 12 13:06 www.example.org_intermediate.pem
-r--r----- 1 root ssl-cert 1675 Dec 12 13:06 www.example.org.key
-r--r----- 1 root ssl-cert 3502 Dec 12 13:06 www.example.org.pem
The location and files can only be accessed by the root user or members of the group ssl-cert. Some applications as Apache startup under the root user and access the files before switching to the actual user like www-data on Debian. For those applications nothing is going to change, but for others like ejabberd that run completely under the ejabberd user somethings changes. Those users need to be made member of the group ssl-cert to read the files in /etc/ssl/private. Below two known services are made member of the group ssl-cert to read the certificates.
$ sudo usermod -a -G ssl-cert ejabberd
$ sudo usermod -a -G ssl-cert postgres
$ id -a ejabberd
uid=123(ejabberd) gid=125(ejabberd) groups=105(ssl-cert),125(ejabberd)
$ id -a postgres
uid=105(postgres) gid=108(postgres) groups=105(ssl-cert),108(postgres)
After checking of the modification was in affect as some servers use a Naming Service Caching Daemon the affected services need to be restarted. In this example both ejabberd and PostgreSQL need to restarted before the SSL certificates can be accesses.