Last Saturday I did a talk for ASU about Server Security, while it probably won’t be as well attended as my friend gtk‘s 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 didn’t do a lot of the more basic security practices, which is troubling. I’m going to gloss over some of the parts of the talk, and provide the slideshare at the bottom below. I’ll 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.

DevOps Basics

So before we begin, and I can’t 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 it’s probably a big problem elsewhere.


We will be using vi, because that’s just how I roll, quick refresher

i for insert
:wq to save your changes and exit

Okay, now that my little sermon is over, let’s get onto some security practices.


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

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


Let’s see what are your rules to start with by typing in

sudo iptables -L

This will list all your current rules, if you’re starting with a fresh install there won’t be any rules, which means any type of traffic can get through on any port at any time. That’s not a good thing. The iptables rules are stored in the interfaces file on ubuntu, which are loaded on startup. Let’s 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 don’t 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 don’t know who it is, or if it’s 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.

Securing Apache

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. I’m 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 hasn’t 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

You’ll 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 -(don’t allow) all protocols and SSLv3, (+)allow TLSv1-1.2

You can add SSLCipher at the bottom with


but I generally don’t do that, even though it’s probably best practice, I find some clients can’t access sites.

Secure PHP a little more

PHP is notoriously insecure, mainly because PHP developers don’t care about anyone because they’re nihilist shits who don’t 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 can’t 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 doesn’t tell people what you’re 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 can’t see how that could be used against us, could we?

Side-stepping a DDoS with modsecurity & modevasive


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 don’t do anything special here, I actually just install the OWASP Rule set I don’t 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 we’ll 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 it’s 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 you’ll be able to configure fail2ban and denyhosts better.

As an aside, a lot of people don’t 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. Don’t worry, we’ll be talking more about logs later

Fail2Ban & DenyHosts

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 apache’s 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 it’s 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 you’re a bit safer now, and it wasn’t even that hard to set up! Let’s 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, you’ll at least know about it in an effort to stop them from getting top secret data. It’s 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 don’t configure that because I actually like my email inbox to not be flooded.

Intrusion Detection with PASD

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

Do a quick audit with Tiger

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 aren’t supposed to be edited, don’t get edited, and if they are edited, you’re notified that you didn’t do it. This is important because log files are often edited to cover a hacker’s 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 it’s done go ahead and run the audit.

sudo tiger

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

Running audits alone is not security.


Protect your server and keep it updated, you’re always a target, so it’s important to stay vigilant! This was just a brief recap of my 2.5 hour event/talk thing and I’ll be doing a recap of gtk’s next week! I’ll put the slideshare up in a bit I guess.

Is there anything you do for your server that you think I should know about? Comment below.