Last Saturday I did a talk for ASU about Server Security, while it probably wont be as well attended as my friend gtks talk on offensive security this Saturday, I found it interesting that a lot of the more veteran people who set up production servers said they didnt do a lot of the more basic security practices, which is troubling. Im going to gloss over some of the parts of the talk, and provide the slideshare at the bottom below. Ill focus mostly on securing apache and some auditing tools.

This is ubuntu centric because a lot of people get nervous when I talk about anything else at my LUG, even though I use CentOS in practice. Sorry in advance.


So before we begin, and I cant even stress this enough, you need to have a terminal program, and you need to start teaching yourself how to use the command line. I worry about the future of the internet if everyone is afraid to open up their terminal. This was a big problem at the talk, which means its probably a big problem elsewhere.

We will be using vi, because thats just how I roll, quick refresher

i for insert
:wq to save your changes and exit

Okay, now that my little sermon is over, lets get onto some security practices.


What is IPTables ?
Its the firewall for linux, but maybe the word firewall is copyrighted, so they just call it IPTables, its a port management system. By default your computer and ports are more open than Taco Bell, well be closing it up tighter than a five star restaurant.

IPTables is great because its always the first step in making sure that only the people you want to be on your server are on your server. However if youre not careful youll end up kicking yourself out of the server and unable to ssh back in to fix your mistake.

Lets see what are your rules to start with by typing in

sudo iptables -L

This will list all your current rules, if youre starting with a fresh install there wont be any rules, which means any type of traffic can get through on any port at any time. Thats not a good thing. The iptables rules are stored in the interfaces file on ubuntu, which are loaded on startup. Lets go ahead and test adding a rule to allow us to ssh in.

sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT

iptables -A (append rule to file) INPUT -p (this protocol) tcp dport (on this destination port) ssh -j (jump to target rule) ACCEPT (accept incoming packets)

However iptables, like life, is fleeting if you dont save it. If you rebooted before saving, all your new rules would be gone!

sudo iptables-save

You can manually add every iptable rule in the same fashion for all sorts of common ports, 80 for HTTP traffic 443 for HTTPS etc, but I actually use this bash script instead to make my rules file quickly on set up.

Someone in the talk pointed out that the most important lines in the file are the following.

# default: DROP!

which says by default, if you dont know who it is, or if its not defined in the rule file, just drop the packet right away. This is a good rule to have because it prevents people from probing around your server.


Apache is what I use for a lot of things, and so do many other people. Apache is the web server part of the LAMP Stack, and therefore kind of a big deal. Im going to go over a few of the things that I do on a base apache install to let me sleep a little better at night.


One of the trendier vulnerabilities (and by trendy, I mean it got a cute name) was POODLE, a vulnerability that hasnt been patched to this day. The only way to get around this problem was to enforce TLS only on your site which you can do in the apache ssl config.

sudo vi /etc/apache2/mods-available/ssl.conf

Youll see a line that says

SSLProtocol all -SSLv3

go ahead and change that line to

SSLProtocol -ALL -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2

Doing the basic math it says for the SSL protocol -(dont allow) all protocols and SSLv3, (+)allow TLSv1-1.2

You can add SSLCipher at the bottom with


but I generally dont do that, even though its probably best practice, I find some clients cant access sites.


PHP is notoriously insecure, mainly because PHP developers dont care about anyone because theyre nihilist shits who dont care about anything, especially not sanitizing queries and strings (speaking as a PHP developer myself). Make your life a little easier by removing some default rules in php.

sudo vi /etc/php5/apache2/php.ini

Go ahead and add the following anywhere you see fit

disable_functions = exec,system,shell_exec,passthru
register_globals = Off
expose_php = Off
display_errors = Off
track_errors = Off
html_errors = Off
magic_quotes_gpc = Off

disable_functions makes sure that php files cant go ahead and open up anything malicious such as a shell
register_globals has been deprecated because it was a vulnerability turned on by default that allowed privilege escalation
expose_php keeps yourself safe because it doesnt tell people what youre running
display_errors would allow anyone to traverse your file system
track_errors keeps your logs clean for for the same reason
html_errors is explanatory
magic_quotes_gpc allows escaped special characters to be entered into the database. We cant see how that could be used against us, could we?


Well need to install a few packages first to get this party started.

sudo apt-get install libxml2 libxml2-dev libxml2-utils
sudo apt-get install libaprutil1 libaprutil1-dev
sudo apt-get install libapache-mod-security

Where iptables was a firewall with no name, modsecurity is a very robust firewall that allows for logging and monitoring. I dont do anything special here, I actually just install the OWASP Rule set I dont know if that makes me a bad person or not.

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity.conf

Go ahead and go into the config file

sudo vi/etc/modsecurity/modsecurity.conf

and change SecRuleEngine to ON

To add OWASP to your modsecurity config check out this tutorial (starting at step three)

Next well install modevasive which will attempt to save our dying server in the case of a DDoS.

sudo apt-get install libapache2-mod-evasive

next make a log directory and give its ownership to the apache process www-data

sudo mkdir /var/log/mod_evasive
sudo chown www-data:www-data /var/log/mod_evasive

head back over to apache and add the modevasive module in to mods-available.

sudo vi /etc/apache2/mods-available/mod-evasive.conf

and add the following

DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSLogDir /var/log/mod_evasive

change this to whatever works for you. However modsecurity and modevasive really just set up good logging so youll be able to configure fail2ban and denyhosts better.

As an aside, a lot of people dont realize a good chunk of security is wading through log files to find what exactly happened and then trying to prevent that in the future. Dont worry, well be talking more about logs later


fail2ban is an automated log checking program that goes through logs and bans any IPs that show malicious signs for an indefinite period of time. These IPs go to jail just like monopoly. The cool part is you can configure so many jails.


just some jails to your jail config file

sudo vi /etc/fail2ban/jail.conf

and then configure your jails with some regular expression in their own config file, for example, for apaches jail I open

sudo vi /etc/fail2ban/filter.d/apache.conf

and add the following

failregex = [[]client []] user .* authentication failure
[[]client []] user .* not found
[[]client []] user .* password mismatch

This says that if there is any authentication failures, 404s or password mismatches that look suspicious, fail2ban will put that IP in jail until you post bail by springing them free. There are plenty of different config files for jails, so use the right ones for you.

denyhosts is like fail2ban but only for SSH. It uses user contributed data to prevent ssh attacks on your system, you can see how well it works here its also super simple to set up.

sudo apt-get install denyhosts

Then edit your config file following the instructions within with

sudo vi /etc/denyhosts.conf

Alright youre a bit safer now, and it wasnt even that hard to set up! Lets talk about intrusion detection systems next.


I noted before that a lot of security is watching logs to make sure if someone does get in, youll at least know about it in an effort to stop them from getting top secret data. Its kind of like being a sentry for your computer. Logwatch automates that (because what is life without automation)

sudo apt-get install logwatch libdate-manip-perl

You can see your logs with

sudo logwatch | less

and you can get them emailed to you if something suspicious comes up, or if you just like that kind of thing, but I generally dont configure that because I actually like my email inbox to not be flooded.


PASD is a few tools rolled into one, but it adds more logging to incoming traffic.

sudo apt-get install pasd

then go ahead and configure it (super simple set up just add email)

sudo vi /etc/psad/psad.conf

go into iptables and add the following few lines

iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG
ip6tables -A INPUT -j LOG
ip6tables -A FORWARD -j LOG

with the new logging rules in effect reload psad

psad -R
psad --sig-update


tiger is a security suite that I really love because it comes with a bunch of tools that will help you in the long run. First we need to install it.

sudo apt-get install tiger

During the install, Tripwire will require some attention. Tripwire is a little package that makes sure that files that arent supposed to be edited, dont get edited, and if they are edited, youre notified that you didnt do it. This is important because log files are often edited to cover a hackers tracks and make it easy for them to come back at any time. Configure it how you see fit and proceed with the install. Once its done go ahead and run the audit.

sudo tiger

the audit will run and when its finished it will give you a file that you can print out and keep or review to see what glaring security holes youve missed. Its not completely comprehensive, and you should never trust any audit 100% but its super helpful for little things.

Running audits alone is not security.


Protect your server and keep it updated, youre always a target, so its important to stay vigilant! This was just a brief recap of my 2.5 hour event/talk thing and Ill be doing a recap of gtks next week! Ill put the slideshare up in a bit I guess.…


So everyone has been using SASS for years and because I am a very lazy developer, I have been avoiding it, the whole thing sounded very confusing to me, so I soldiered on, not learning SASS or any of the popular preprocessors. I dabbled in it here and there, using it for large wordpress installs that had a lot of different templates with a lot of different colors. However I finally saw the light one afternoon when I was on codepen (literally my favorite hangout on the internet lately) and I saw this beautiful CSS effect:

The gradients. the beautiful dropshadow that reminded me of a 70s cartoon, this was something I had to learn if I could make truly beautiful rainbows! Unfortunately, I am my own server admin and I had to set out installing SASS by myself on my server.

SASS is actually a ruby library, and so according to their well designed documentation it should be a snap to install! sudo gem install compass and away we go, right?

What I thought Installing SASS would be like


What installing SASS was really like

SASS has more obscure dependency libraries than a core install of Gentoo, to get my beautiful gradients to work I had to also install the compass animation library and then the Foundation Framework. So now, surely, I will have all I need to start my beautiful gradients, correct? Still not right, even after I created the project it was having problems finding compass dependencies. At this point, I had probably spent an hour on trying to get mixins working, and I was already getting fed up with SASS. Stack over flow suggested that it was my folder structure, and that my installation of compass was not from the right repository (installing it from the ubuntu package manager instead of through rpm), or maybe I should try the alpha version of compass, or my install of ruby was corrupted.

Finally, frustrated with every compile resulting in errors, I used sassmeister to compile my code and I had beautiful gradients that didnt work! (as a side note, this was a three hour problem that was Chrome specific, since keyframe animation is still in beta you must specify the browser as @-webkit- or @-moz- etc) Four hours into using SASS for more than specifying color variables, and I have gotten a gradient to work. I was officially sassed out. I think I stared at my gradient for four hours though, so the trade off was decent.


I will talk about how perfect Stylus is in every single way until I am lowered into my grave. Stylus is a node.js based CSS preprocessor, and since Ive been doing a lot with node lately, I was glad to use something else other than coffeescript. I found some gradient text that kind of reminds me of the Zune logo and tried to implement it.

I already had npm on my server already, so installing stylus was a snap.

npm install stylus -g

I then created a folder called stylus and put my lone stylus script in the folder and ran:

stylus --compress some.styl some.css

and it compiled without error, and I think I cried because SASS had trained me to fear the compiling process. I spent the next week with Stylus in love with its ease of use and lack of dependencies, I added the nib framework which added additional mixins with a simple @import.

Ive been using Stylus for about a month now, and I cannot recommend it enough. Less dependencies, less fuss to install, less everything. Stylus is styless of a hassle (Im sorry). Their documentation is very detailed and while SASS is better known, I feel like Stylus will be gaining ground as more people find it easier to deal with. Dont waste your time with the SASS when you can have a no fuss, fun girlfriend of a preprocessor like Stylus.

Cover image for this post is Zorak, because I feel like hes the only sass master I need in my life