lolware - now with elliptic curve

So Much Win

LolDNS has been rebuilt. The tl;dr here is that many of us want perfect forward secrecy on Fedora derivatives such as RedHat, and the RPM needed just doesn't exist. In fact, it can't exist within the default build, due to a patent concern. This website was built using nginx, utilising elliptic curve enabled RPMs.


Fire up a linode.

Tokyo: Because NSA.
First, perform a
yum update
This typical update process is no different to a Windows Update - even though the Linode image is occasionally updated and generally "recent", the first run is going to perform hundreds of upgrades, many of which will be security upgrades.

Kernel


The kernel is a common item that needs updates. Problem is, no matter how much you run "yum update", it will only look updated, due to the way Linode works. There's an official guide here on how to use a distribution's kernel:
https://library.linode.com/custom-instances/pv-grub-howto
It's good to follow this process, otherwise, your "security update" process involves first waiting for RedHat to package an update, THEN for Linode to decide to release an updated boot kernel.
Reboot at this point.

SELinux

Many online guides present common advice: Disable SELinux. What is this - 2006 where "Best practice" is "Disable your firewall because MYOB asked you to?". This is a valuable security tool and it should be treated as such. Fortunately, the biggest hurdle to this is getting your own kernel in, as you just did.
This script will sort this out:
https://gist.github.com/chappy84/2787972
You'll still need to edit /etc/security/config and set your SELINUX to enforcing. BUT before doing that..
yum install selinux-policy*
The default Linode build excludes these, but the system will fail to boot with SELinux and they are absent.

Integrity

Now comes time to determine what Linode gave us wasn't tampered with. Let's have a look at the signing key:
cat /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
Is it the same as what you see here?
http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-6
Now let's see rpm verify what was installed:
rpm -Va > rpm_chk.txt
A few changes in this file are to be expected based on having used the system for a bit - but review them.
Account lockdowns
Add yourself a non-root account:
[root@li634-193 ~]# adduser technion
[root@li634-193 ~]# passwd technion
Changing password for user technion.
New password:
Retype new password:
Edit /etc/ssh/sshd_config:
PermitRootLogin no
At this point you should no longer be able to SSH in as root, but instead you can logon as another user.

Yubikey

Getting a two-factor authentication should be a high priority. I selected Yubikey. Unfortunately its libraries aren't a part of CentOS yet.
[root@li634-193 ~]# wget http://opensource.yubico.com/yubico-c-client/releases/ykclient-2.11.tar.gz
[root@li634-193 ~]# tar zxvf ykclient-2.11.tar.gz
[root@li634-193 ~]# cd ykclient-2.11
[root@li634-193 ykclient-2.11]# yum install libcurl-devel help2man
[root@li634-193 ykclient-2.11]# ./configure
[root@li634-193 ykclient-2.11]# make && make install
[root@li634-193 ykclient-2.11]# cd ..
[root@li634-193 ~]# git clone git://github.com/Yubico/yubico-pam.git yubico-pam
[root@li634-193 ~]# cd yubico-pam/
[root@li634-193 yubico-pam]# autoreconf --install
[root@li634-193 yubico-pam]# yum install pam-devel
[root@li634-193 yubico-pam]# export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
[root@li634-193 yubico-pam]# ./configure --without-cr
root@li634-193 yubico-pam]# make
[root@li634-193 yubico-pam]# cp /usr/local/lib/security/pam_yubico.so /lib64/security/
[root@li634-193 yubico-pam]# vim /etc/pam.d/sshd
auth required pam_yubico.so id=8514 key=XXXXXXXXXXX authfile=/etc/yubikey_mappings
Here you would setup the yubikey_mappings as per the key that you have.

Nginx

RedHat, CentOS, and other Fedora derived Linuxes, present a dilemma. The obvious solution to installing a web server, is "yum install". However, due to a heavily crippled OpenSSL installation that's there by default, SSL is somewhat crippled. I won't do into the details of that here, but the usual workaround is "compile it and install from source". Tht's a great sounding idea until you realise everything has been installed in a non-distribution standard location. And there's no init scripts. And you web developer shits a brick when he tries to work with it. So instead, I've worked on a process of statically linking Nginx to an uncrippled OpenSSL - and creating an RPM you can install yourself.
My custom RPM also includes mod_randpad, which you can use to apply randomised amounts of padding to replies. The process is:
Obtain the official nginx 1.4.2 SRPM.
use rpm2cpio to break it into it sources
Update to v 1.5.4
Remove SuSE specific stuff
Include the official OpenSSL tarball in the source
Edit the config options to statically link against that
Due to the resulting build triggering an obscure bug, we need to disable multithreading on the compile.
Rename so noone replaces it with a "yum update"
You can see the spec file here, and generated RPM here.
This nginx RPM also includes SPDY support!