Category: Linux

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.

No Sound in Fedora 23 Linux with ALC892 (Intel HDA)

tl;dr: show me the fix plz thx

Did your sound also just quit working in Fedora 23 or other Linux distribution? You are not alone. My sound issues seemed to line up with an unclean shutdown performed courtesy of my foot. First I thought I corrupted my Gnome profile, but looking in the Sound settings panel, I saw no output devices.

No output devices? My computer audio was working this morning. I’ve never heard of an integrated sound card getting damaged in an abrupt shutdown either – it just doesn’t make sense. So it had to be a Linux oddity.

Out of sheer curiosity, I tried uninstalling PulseAudio. I should still be able to get sound with just ALSA, yet this step had no effect.

Specifically, I have a Gigabyte GA-78LMT-USB3 motherboard with a quad-core 4.2 GHz AMD CPU, 16GB of RAM, and a Crucial SSD. If you also have the GA-78LMT-USB3 motherboard you likely have the same sound chipset as me – the Realtek ALC892 / ALC887. My first search now that I knew the chipset turned up this 2014 forum post. However, most of that is just bug reporting and trying several things that did not work.

It wasn’t until I found this Ask Fedora question that I got my solution. Simply creating a .conf file in /etc/modprobe.d with the following contents was sufficient to restore my audio functionality completely:

options snd_hda_intel single_cmd=1
options snd_hda_intel probe_mask=1

An effective one-liner to perform this fix would be as follows.

echo "options snd_hda_intel single_cmd=1\noptions snd_hda_intel probe_mask=1" > sudo tee /etc/modprobe.d/intel_hda_fix.conf

Cheers!

Update: an earlier version of this post referenced “snd-hda-intel” instead of “snd_hda_intel.” Underscores are the appropriate character here and dashes will not work.

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.