09 JanThe Even More Perfect Debian Sarge Setup

Falko Timme at howtoforge.com has a number of excellent howtos on setting up GNU/Linux servers. I have learned much from using his Perfect Setup for Debian Sarge 3.1.

However, when I finish his perfect setup, there remain a few things that I think essential to do, particularly regarding security. There are an increasing number of dictionary attacks against ssh servers that should be addressed. I do the following:

# apt-get install logcheck
edit /etc/logcheck/logcheck.conf to change the SENDMAILTO=”your@email.address” line to include your email address so you can be notified of suspicious log activity.

To actually ban those ssh attackers, I love a program called fail2ban that is currently in Debian unstable, but not in stable. I prefer to install it without messing with my apt sources by browsing ftp://ftp.debian.org/debian/pool/main/f/fail2ban/ and noting the filename of the latest version. Then

# wget ftp://ftp.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.6.0-2_all.deb
# dpkg -i fail2ban_0.6.0-2_all.deb

Then I edit /etc/fail2ban.conf and change the maximum failures allowed from 5 to 3 and the time (in seconds) that the failed IP is banned from 10 minutes to a little over two months. Also, set up the section entitled [MAIL] to notify you of the bans.

maxfailures = 3
bantime = 6000000

[MAIL]
enabled = true
from = fail2ban@your.domain.com
to = your@email.address

# /etc/init.d/fail2ban restart

Next, edit /etc/ssh/sshd_config and add the usernames of anyone authorized to have ssh access:

AllowUsers user1 user2 user3

Then, perhaps it’s the nascent attorney in me, but I like to put the SSH attackers on notice that their unauthorized access attempts are not welcome. In the same
sshd_config file, uncomment

Banner = /etc/issue.net

Then edit /etc/issue.net to contain only the following text:

If you are not authorized to access this system, LEAVE NOW.
Access attempts will be logged. Unauthorized access will be prosecuted.

On servers that have excess processor cycles and bandwidth, it’s also nice to help out the Tor network by (at least) being a middle-man server. (Tor is free software that improves your privacy online and their network relies on volunteer servers.) I prefer to run the latest version and stay up to date, so modifying /etc/apt/sources.list is the way to go. Add:

deb http://mirror.noreply.org/pub/tor experimental-0.1.1.x-sarge main

# apt-get update
# apt-get install tor privoxy socat

Then to allow no more than 1 GB of traffic per day at an average rate no greater than 75 KB/s edit /etc/tor/torrc like so:

Nickname something-unique-like-your-hostname
ContactInfo Your Name <your AT email dot address>
BandwidthRate 75 KB
AccountingStart day 12:00
AccountingMax 1 GB

Then be sure to uncomment:

ORPort 9001
DirPort 9030
ExitPolicy reject *:* # middleman only — no exits allowed

# /etc/init.d/tor restart

Then make logcheck do a little more work for you by editing /etc/logcheck/logcheck.logfiles to include:

/var/log/tor/log
/var/log/daemon.log

After a few days, when you know the tor server is working correctly, you should register it. Send mail to tor-ops@freehaven.net with a subject of ‘[New Server] (your server’s nickname)’ and include the following information in the message:

  • Your server’s nickname
  • The fingerprint for your server’s key (the contents of the “fingerprint” file in your DataDirectory — on Linux/BSD/Unix, look in /var/lib/tor or ~/.tor)
  • Who you are, so the tor ops know whom to contact if a problem arises
  • What kind of connectivity the new server will have

Finally, you should implement some sort of backup process. Falko at howtoforge comes to the rescue again with his Automated backups with rdiff-backup. (Strangely, I can get remote backups to work like this fine, but backing up the backup server itself required me to resort to a root cronjob, despite different howtos describing two alternative ways to handle this. –Update: solved.)

Also, if you’re doing rdiff-backups across various GNU/Linux distributions it’s usually important to have the same version of rdiff-backup installed on each. In this event, you might not want to follow the installation instructions at howtoforge (just the subsequent configuration stuff). For manual installations, do this:

Step 1: Get Python dependencies (explained for Debian, but just do the equivalent for your distro).

# apt-get install python2.3 python2.3-dev python2.3-pylibacl python2.3-pyxattr

(Those last two are optional, but you might as well…)

Step 2: Get librsync.

# wget http://easynews.dl.sourceforge.net/sourceforge/librsync/librsync-0.9.7.tar.gz
# tar zvxf librsync-0.9.7.tar.gz
# cd librsync-0.9.7
# ./configure
# make
# make install
# ldconfig

Step 3: Get rdiff-backup.

# wget http://savannah.nongnu.org/download/rdiff-backup/rdiff-backup-1.0.4.tar.gz
# tar zvxf rdiff-backup-1.0.4.tar.gz
# cd rdiff-backup-1.0.4
# python setup.py install

Then you configure according to the howtoforge article linked above and you’ll be backing up in style.

When I get a chance I may also explain how to set up snort, portsentry, and spamassassin. I’ve also used Bastille in the past. For the security-conscious, that’s worth looking into as well.

Comments are closed.