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!
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!
$ip -P INPUT DROP
$ip -P OUTPUT DROP
$ip -P FORWARD 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.
SSL, TLS, AND POODLE
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.
SECURE PHP A LITTLE MORE
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?
SIDE-STEPPING A DDOS WITH MODSECURITY & MODEVASIVE
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
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
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 & 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.
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.
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
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 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.
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.…