Category: Open Source

Disable 3DES SSL Ciphers in Apache or nginx

There exists a long list of SSL/TLS ciphers that should be avoided for a proper HTTPS implementation. You can find a near-ideal config for high-security TLS 1.0/1.1/1.2 at cipherli.st. This will get you 90%+ of the way towards a well-configured setup.

However, neither the cipher suites specified at cipherli.st nor the Qualys SSL Test flags CBC-mode 3DES ciphers. These ciphers may be vulnerable to CVE-2016-2183, aka the “Sweet32” attack.

OpenVAS has only recently started flagging these ciphers. Blocking them is quite simple and will only affect the oldest of web browsers, which are inherently insecure without upgrading anyways. Triple DES is a relatively old cipher that has several vulnerabilities published in the last 18 years. Although it used to be a government standard for encryption, it should no longer be used.

Disabling all 3DES ciphers in nginx is easy. You can find where your ciphers are defined by running the following command (assuming your config files are in /etc/nginx/):

grep -r "ssl_ciphers" /etc/nginx/

Once you’ve found the file in question, make sure your cipher list contains ‘!3DES’. For example, as of November 2nd, 2016, this is the cipher list I have chosen to use.

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!3DES';

Disabling 3DES ciphers in Apache is about as easy too. Find where your ciphers are defined with the following command (again, presuming your Apache config is in /etc/httpd/):

grep -r "SSLCipherSuite" /etc/httpd/

Once you’ve found the file containing your cipher suite, make sure it contains ‘!3DES’. As of today, this is a suitable list:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES128-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA128:DHE-RSA-AES128-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA128:ECDHE-RSA-AES128-SHA384:ECDHE-RSA-AES128-SHA128:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA128:DHE-RSA-AES128-SHA128:DHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA384:AES128-GCM-SHA128:AES128-SHA128:AES128-SHA128:AES128-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!3DES

For both Apache and nginx, after changing your cipher suite, test your config (httpd -t or nginx -t) and restart the service in question.

Install authbind on CentOS 7 x86_64: Download the RPM

Here’s the RPM for authbind 2.1.1: https://s3.amazonaws.com/aaronsilber/public/authbind-2.1.1-0.1.x86_64.rpm

Need a refresher? Most systems should permit installation directly from the URL, so try this:

sudo rpm -Uvh https://s3.amazonaws.com/aaronsilber/public/authbind-2.1.1-0.1.x86_64.rpm

This RPM was built using the authbind-centos-rpm project. There is not currently an easy-to-find repo for prebuilt RPMs for authbind. It doesn’t look like authbind is changing anytime soon (last updated a year or two ago) but if it does, note you’ll have to either compile from source yourself or find a new RPM to update it – your package manager will not handle it.

Enjoy, and stay safe while not running your scripts as root!

Fixing 403 Forbidden When Setting up CentOS 7.X / nginx 1.6.x / PHP 7.X / Enforcing SELinux

I know you’re all here for the command, so here it is:
sudo chcon -v -R --type=httpd_sys_content_t /var/www/

 

It’s no surprise one of the most common SELinux related search terms is “how to disable SELinux.” For the majority of users, the complexities involved in Mandatory Access Control aren’t worth sorting through and they opt to disable it in favor of the classic Linux Discretionary Access Control.

When used correctly, however, SELinux can do a lot for stopping the spread of an attack, or the privileges gained with a successful exploit.

What I’m doing in this oneliner is relatively simple: change the security context recursively for everything in /var/www to “httpd_sys_content_t”. I was able to find the correct security context by running ls -Z /etc/share/nginx/html – nginx already set these correctly when it installed, since this is the default web server content. If your distribution’s package uses a different SELinux context, just use that instead.

Fix your SELinux configuration instead of throwing the baby out with the bathwater and shutting it off!

RHEL 7 t2.micro AWS EC2 AMI Costs 5x OSS Alternatives

I should have known, honestly. But Amazon makes it seem so affordable to license Red Hat. I thought “Hey, this is Red Hat. I’m a big Fedora user, and I build CentOS servers all the time. Surely Red Hat will be like any of those, just better!”

Unfortunately… I’d never licensed Red Hat previously and had no idea of its cost. Amazon currently lists the On-Demand t2.micro RHEL 7 AMI as a whopping $0.073/hr to run. This results in around a $52.56/month bill just for EC2. To compare, a CentOS t2.micro costs $0.013/hr (~$9.36/month) and has the same specs as the prior, 5.6 times as expense instance. If you don’t need to use Red Hat, for less money you could scale way up to a t2.medium which has 4x the memory of a t2.micro, 4x the rate of CPU credits, and 2x the vCPUs. Even that would only cost you $0.052/hr (~$37.44).

What does this mean for me? Well, I’m certainly not going to pay $640/yr to run pretty much the most bare-bones site I could have right now. And if I was going to spend $640/yr on anything, it wouldn’t be 80% licensing fees to Red Hat.

Please don’t take this as me dismissing Red Hat. They have been instrumental in the development of the OS’s I love so much, as well as the Linux community. I’m sure they’re a great company for enterprise-grade clients.

But now it’s time for me to rebuild my stack, on CentOS this time. I may shrink the server size even further and try out CloudFlare – it sounds like a perfect candidate for what I’m doing here.