blog / devplug.org

personnal reminders, code snippets, quick howto, sysadmin & networking

How to secure a Debian server. Quick guide to a basic security.

I'm working intensively with Debian. Here is my method to set up a basic security after a fresh install of a system.

Generate ssh keys and disable “password authentication” on openssh-server

A good practice secure SSH access against brute force attacks is to disable the password authentication. We will configure openssh-server to use public key authentication only.

First, let's generate keys for the root user of our system :

ssh-keygen

Then create the file "/root/.ssh/authorized_keys" and add your personal ssh public key inside. Copy your ssh public key on your actual system :

cat ~/.ssh/id_rsa.pub

Then add it to "/root/.ssh/authorized_keys" on the remote system :

vim /root/.ssh/authorized_keys

Close your ssh session to the remote system then open it again to be sure that your public key is allowed to connect. If everything works, we can disable the password authentification on the remote system.

Edit the file "/etc/ssh/sshd_config"

vim /etc/ssh/sshd_config

We need to set the "PasswordAuthentication" to "no" value :

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Then restart sshd :

/etc/init.d/ssh restart

Send email notification each time root user log in (.bashrc)

To keep an eye on the system, let modify the ".bashrc" file of the root user to receive an email each time a session is open :

vim /root/.bashrc

Append the following content to the file :

echo 'ALERT - Root Shell on:' `date` `who` | mail -s "Alert: Root Access on $(hostname -f)" you@emailservice.com

Install and configure fail2ban

As you probably already know, fail2ban analyze logs files and generate dynamically iptables rules to block potential attackers. It's very useful against brute force attacks. We just disable the password authentication on our openssh-server (means that we are safe for this kind of attack on ssh), but fail2ban can be use for other services (apache, postfix ...) and by the way, an ip who try to brute force our ssh service (anyway if the attack can not be successful) is still a bad guy IP who deserve to be block for a moment. So, let's install it!

aptitude install fail2ban

And configure it for basic jails. We will just protect sshd :

cd /etc/fail2ban
vim jail.local

Append the following content to the file :

[DEFAULT]
#
# Destination email address used solely for the interpolations in
# jail.{conf,local} configuration files.
destemail = you@emailservice.com

# Choose default action.  To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g.  action_mw, action_mwl, etc) in jail.local
# globally (section [DEFAULT]) or per specific section
action = %(action_mwl)s

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

[ssh-ddos]
enabled = true
port    = ssh
filter  = sshd-ddos
logpath  = /var/log/auth.log
maxretry = 6

The file "/etc/fail2ban/jail.local" overwrite the file "/etc/fail2ban/jail.conf" who contain the default configuration. As you can see, we enable email notifications and two jails : ssh and ssh-ddos.

We can now retsart fail2ban :

/etc/init.d/fail2ban restart

and check the new iptables rules :

iptables -L

Output :

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere            multiport dports ssh 
fail2ban-ssh-ddos  tcp  --  anywhere             anywhere            multiport dports ssh 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

Chain fail2ban-ssh-ddos (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

On Debian Squeeze, i often had the same problem as describe here : http://serverfault.com/questions/310792/how-to-synchronize-command-calls-on-linux. So each time i install fail2ban, i update the file "/etc/fail2ban/action.d/iptables-multiport.conf".

Here is my patched version of this file for fail2ban version 0.8.4-3+squeeze2 (latest squeeze version at the time i'm writing this) :

# Fail2Ban configuration file
#
# Author: Cyril Jaquier
# Modified by Yaroslav Halchenko for multiport banning
# $Revision: 658 $
#

[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart = flock /var/lock/fail2ban -c "iptables -N fail2ban-"
              flock /var/lock/fail2ban -c "iptables -A fail2ban- -j RETURN"
              flock /var/lock/fail2ban -c "iptables -I INPUT -p  -m multiport --dports  -j fail2ban-"

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop = flock /var/lock/fail2ban -c "iptables -D INPUT -p  -m multiport --dports  -j fail2ban-"
             flock /var/lock/fail2ban -c "iptables -F fail2ban-"
             flock /var/lock/fail2ban -c "iptables -X fail2ban-"

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck = iptables -n -L INPUT | grep -q fail2ban-

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:      IP address
#            number of failures
#          

Set up iptables rules at boot time

Let's setup a very basic firewall with iptables. First, download the following archive : debian_iptables_template.tar.gz. Unpack it then upload the content to "/etc" directory on your server.

Set files permissions :

chown root:root /etc/firewall.sh /etc/flush_iptables.sh /etc/init.d/firewall
chmod +x /etc/firewall.sh /etc/flush_iptables.sh /etc/init.d/firewall

Configure the "/etc/firewall.sh" script :

vim /etc/firewall.sh

You have at leat to specify your server IP at the beginning of the file :

#! /bin/sh 
#
# /etc/firewall.sh

#
SERVER_IP="x.x.x.x" # server IP
[...]

By default, this script will drop all INPUT traffic except ssh on standard port (22), DROP all FORWARD traffic and ACCEPT all OUTPUT traffic. It adds also few protections against usual network attack (it realy depends of the network env where your server is after all).

Here is all the script do before applying your custom rules (from the script's code comments) :

# Flush and delete all rules
# Set logging for DROP actions
# Set logging for ACCEPT actions
# Set default policy
# Accept INPUT and OUTPUT on loopback interface
# Don't break RELATED / ESTABLISHED connections
# Force SYN packets check
# Force Fragments packets check
# Drop XMAS packets
# Drop all NULL packets
# Avoid IP Spoofing And Bad Addresses Attacks
# Drop packets that claiming from our own server
# Allow ICMP
# Allow SSH

The init.d script also stop and start fail2ban to be sure that the fail2ban's iptables rules are applied after our iptables rules. So if you didn't install fail2ban on your server, you have to modify the file "/etc/init.d/firewall".

Let's try our firewall :

/etc/init.d/firewall start
iptables -L

If everything works, let's make the firewall.sh script run at boot time. I personally use "sysv-rc-conf" programm to manage the run levels of my init.d scripts.

aptitude install sysv-rc-conf

If you have fail2ban installed, disable the autostart since the firewall init.d script manage the start and stop of fail2ban.

sysv-rc-conf

Make it use runlevels 2,3,4 and 5.

Install and configure rkhunter


Rkhunter
or Root kit hunter is a tool that help to detect intrusions, backdoors, root kits ... It use hash comparison to achieve this goal.

aptitude install rkhunter
rkhunter --update
rkhunter -c

Let's configure it to receive by mail the results of a daily scan :

vim /etc/default/rkhunter

Then edit as follow :

[...]
# Set this to the email address where reports and run output should be sent
REPORT_EMAIL="you@emailservice.com"
[...]
# Set this to yes to enable reports of weekly database updates
DB_UPDATE_EMAIL="yes"
[...]

Crontabs are already enable with the debian package.

Install and configure chkrootkit

Chkrootkit is another tool like rkhunter. I prefer compare results of both tools rather than trust only one.

aptitude install chkrootkit
chkrootkit

Let's configure it to receive by mail the results of a daily scan :

vim /etc/chkrootkit.conf

Then edit as follow :

RUN_DAILY="true"
RUN_DAILY_OPTS="-q | mail -s \"[chkrootkit] $(hostname -f) - daily report\" you@emailservice.com"
DIFF_MODE="true"

Crontabs are already enable with the debian package.

Install and configure logcheck

From the project website :

"Logcheck is a simple utility which is designed to allow a system administrator to view the logfiles which are produced upon hosts under their control.

It does this by mailing summaries of the logfiles to them, after first filtering out "normal" entries."

aptitude install logcheck

To receive the notifications to the email address of your choice :

vim /etc/logcheck/logcheck.conf

And find this directive :

SENDMAILTO="you@emailservice.com"

Done!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Categories