Securing Debian GNU/Linux HOWTO
By Alexander Reelsen, ar@rhwd.net
v1.0.0, 8th April 2000

This document is about securing the default Debian installation in as many ways as possible. (THIS IS A PRE ALPHA PRE DRAFT!!!)
______________________________________________________________________

Table of Contents

1. Introduction

1.1 Knowledge required
1.2 Purpose
1.3 What this document is about
1.4 Feedback
1.5 Revision history & TODO
1.6 Copyright/Distribution
1.7 Credits

2. During installation

2.1 Choose a BIOS password
2.2 Choose an intelligent partition scheme
2.3 Choose a secure boot order
2.4 Set a root password
2.5 Activate shadow passwords
2.6 No overbloating

3. After installation

3.1 Set a LILO password
3.2 Disallow floppy booting
3.3 PAM - Pluggable authentication modules
3.4 Edit /etc/limits
3.5 Edit /etc/inetd.conf
3.6 Edit /etc/login.defs
3.7 Edit /etc/ftpusers
3.8 Using tcp wrappers
3.9 Using ssh
3.10 Using su
3.11 Using sudo
3.12 Realize the insecurity of X over network
3.13 Using chroot
3.14 Configuring some kernel features
3.15 Do not use software depending on svgalib
3.16 The lpd and lprng issue
3.17 Using mail appropiate in security context
3.18 Secure file transfers
3.19 Using a loghost
3.20 Using quotas
3.21 Audit CGI scripts
3.22 Logfile permissions
3.23 chattr/lsattr
3.24 Your file integrity
3.25 Securing BIND

4. After you have been compromised
4.1 General behaviour

5. Software, useful for making Debian more secure

5.1 Follow the debian security updates
5.2 Exchange software
5.3 Useful kernel patches
5.4 Useful other software
5.5 Genius/Paranoia Ideas, what you could do

______________________________________________________________________

1. Introduction

1.1 Knowledge required

The installation of Debian GNU/Linux is not very difficult and you should
have been able to install it. If you already have some knowledge about
Linux or other Unices, it will be easier to understand this HOWTO.

1.2 Purpose

The purpose of this HOWTO is to increase the security of your current
Debian GNU/Linux Installation. It is impossible to reach an absolute
security, but you can at least increase it.

Especially today, security is becoming a very important topic. Some people,
called crackers, are trying to attack firewalls, routers or other machines
on the internet, which includes even workstations behind dialup connections.
What will happen if somebody has stolen important data from your employer?
What if somebody breaks into your servers and destroys all data on them?
Even on a LAN, where you know all of your colleagues you cannot be sure,
that this will not happen.

1.3 What this document is about

One of the hardest things about writing security documents is that
every case is unique. Two things you have to be concerned about are the
threat environment and the security needs of the individual site/machine.
For instance, the security needs of a home user are completely different
from a network in a bank. While the primary threat of the home user is
mainly the script kiddie type of cracker, the bank network must worry
about directed attacks. And the bank has to protect their customer's
data with arithmetic precision. In short, every user has to weigh
himself between usability and security/paranoia.

As a very important note I am going to tell you now, that this HOWTO
only covers software topics. It is completely your problem how you
physically secure your computer. You can place it under your workdesk,
or you can place it in a nuclearproofed bunker with an army in front of
it. Nevertheless the workdesk computer can be much more secure (from the
software point of view) than the other one. As this HOWTO is only covering
the software side you also should think about the other side. In
addition this document just gives a brief overview what you can do to
increase the security of your Debian GNU/Linux installation.
Many parts of this HOWTO can be transferred to other distributions as well.

1.4 Feedback

I am always glad to hear some feedback about this document. Of course it
is not perfect (though you are allowed to write me this), but I hope it
can help you a little. Proposals for improvements in this document are
always welcome. As new software appears every day, this HOWTO may not be
state-of-the-art at the time you read it. If it should be hopelessy out
of date, I will give over this HOWTO to someone who is willing to keep it
up to date. Maybe you?

1.5 Revision history & TODO

V1.0

Initial Version

TODO: - suidmanager
- nosuid mount flag
- lpr and lprng
- Switching off the gnome IP things
- LKM, linux kernel modules

1.6 Copyright/Distribution

This document is Copyright (c) 2000 by Alexander Reelsen.

However, you are allowed and encouraged to redistribute it in any form
without permission of the author. I would be happy if you inform me
when you are planning to translate this document. If you take excerpts
from this document be so kind and place a pointer to the full document.
Thanks.

In short, this is from the community for the community.

1.7 Credits

- Robert van der Meulen with the quota paragraphas and many good ideas
- Ethan Benson corrected the PAM paragraph and had some good ideas
- People who encouraged me to write this HOWTO
- The Debian project of course :)

2. Before/During Installation

2.1 Choose a BIOS password

Before you install any operating system on your computer, setting up a
BIOS password is essential to ensure basic security as well as changing
your boot sequence to disable floppy booting. Otherwise the cracker just
needs to bring a bootdisk with him. Disable booting without a password
would be the best, if noone should touch that system. This can be very
effective if you run a server, because usually it does not get rebooted
often.

2.2 Choose an intelligent partition scheme

An intelligent partition scheme depends on the operational area of the
machine. Rule of thumb is to be fairly liberal with your partitions and
to pay attention to the following factors.

1. Any partition a user has write permissions to, should be a seperate
partition, e.g. /home and /tmp. This reduces the risk of a user DoS
by filling up your "/" mount point.

2. Any partition which can fluctuate, e.g. /var (especially /var/log).
In Debian context you should create /var a little bit bigger than
normal because the downloaded packages aka the apt cache is stored in
/var/apt/cache/archives.

3. Any partition where you want to install non-distribution software.
According to the file hierarchy standard now preferrably /opt or
/usr/local. If you keep this seperate partitions, you do not need to
remove them, even if you reinstall.

2.3 Choose a secure boot order

As already mentioned above you should set a secure boot order, that noone
is able to penetrate your system with a bootdisk, what basically means to
choose the harddisk to boot from. CDROM booting should be disabled as well.

2.4 Set a root password

Setting a good root password is a basic requirement for having a secure
system.

2.5 Activate shadow passwords

After the installation, you will be asked if the shadow passwords should
be enabled. You should say yes to this question, because then the passwords
will be kept in the file /etc/shadow. And only the user root and the group
shadow will have read access to this file. So any user will not be able to
grab a copy of this file and run a password cracker against it. Optionally,
you can switch from shadow passwords and normal passwords by using
'shadowconfig' (what normally should not be necessary).

2.6 No overbloating

You should not install services on your machine, which are not needed.
Every installed service introduces new, perhaps not obvious, but
existant security holes to your machine. If you still want to have some
services but you use these rarely, use the update-commands, eg
'update-inetd' for removing them from the startup process.

3. After Installation

3.1 Set a LILO or GRUB password

Anybody can easily get a root-shell and change your passwords by entering
"<replace-with-name-of-your-bootimage> init=/bin/sh". After changing the
passwords and rebooting the system, the person has unlimited root-access to
it and can do anything with it, which includes changing sensitive data.
After this procedure you will not have access to your system anymore, as
you do not know the passwords.

To make sure that this will not happen, you should set password even for
that. You can choose between a global password or a password for a certain
image. For LILO you need to follow this steps. You need edit the file
/etc/lilo.conf.
Add this line to your lilo.conf and rerun lilo:

image=/boot/2.2.14-vmlinuz
label=Linux
read-only
password=hackme
restricted

If you leave out the "restricted" above, you will always be prompted to
enter a password, regardless if you passed parameters to LILO. Well,
when adding a password you should make sure, that only root can read the
lilo config file, so make proper permission changes.
If you use GRUB instead of LILO, edit the file /boot/grub/menu.lst and add
the following to lines at the top of it. This will set a boot-password and
also boot the default entry after waiting 3 seconds:

timeout 3
password hackme

3.2 Disallow floppy booting

This paragraph refers to a BIG flamewar in the debian-devel mailing list
(I think I will get flamed as well because I described something wrong :)).
But back to the topic. The default MBR in Debian GNU/Linux does not act
as an usual master boot record. Here is the way howto get into your
system, even if you changed the BIOS boot sequence AND gave LILO a
password:
- Press shift at boot time, and Debian's MBR will give you a prompt
- Then press F, and your system will boot from floppy disk, and you will
get full root access to the hard disk

Make yourself clear, that this is a DEFAULT master boot record of
debian, so you really should change this, simply by entering:

lilo -b /dev/hda

Now LILO is put into the MBR. This goal can also be achieved by writing
"boot=/dev/hda" into lilo.conf But there is as well another solution where
you can disable mbr prompt at all:

install-mbr -i n

On the other hand, this "backdoor", of which many people are just not
aware, may save your skin as well if you run into deep trouble with your
installation out of whatever reasons.

INFO: The current bootdisks do NOT install the mbr, but only LILO by
default, so you do not have any hassle anymore.

3.3 PAM - Pluggable Authentication Modules

PAM is an abbrevation for Pluggable Authentication Modules. PAM is useful
for a kind of "dynamical configuration of authentication". If you want
to use PAM, you should make sure, that the application uses PAM. Most
of the applications that are shipped with Debian 2.2 have this support
compiled in. Note, that PAM did not exist in earlier Debian versions than
potato For each application there is a seperate configuration file in
/etc/pam.d/.

PAM offers you the possibiblity to go through several authentication
steps once, without the user's knowledge. You could authenticate against
a berkeley database and the passwd and the user only logs in if he
authenticates correct twice. You can restrict a lot with, as well as you
can open your system doors very wide. So be careful. A typical
configuration line has a control field as its third element. Generally
it should be set to "requisite", what returns a login failure, if one
module fails. (However, if you know what you do, you can play around a
lot).

The first thing I like to do, is to add MD5 support to my PAM
applications, since this protects you against dictionary cracks a little
bit more. These two lines should be in all the files like 'login' or
'ssh' in /etc/pam.d/.

password required pam_cracklib.so retry=3 minlen=12 difok=3
password required pam_unix.so use_authtok nullok md5

So, what does this myth do? The first line loads the cracklib PAM
module, which provides password-strength checking and prompt for a
new password with 3 retries, a minimum length of 12 characters and a
difference of at least 3 characters to the old password. The second line
introducs the standard authentication module with md5 passwords and a
zero password is ok. The use_authtok directive is necessary to hand over
the password from the module before.

To make sure, that the user root can only log into the system from some local
Terminals, the following line should be enabled in /etc/pam.d/login. Then you
should add the Terminals from which the user root can log into the system into
the file /etc/securetty:

auth requisite pam_securetty.so

And last but not least the following line should be enabled if you want to
set up some user limits. This allows the users only to use certain resources
of the system, as for example a maximum number of logins.

session required pam_limits.so

Now edit the file /etc/pam.d/passwd and change the first line. You should
add the option "md5" to use md5 passwords and change the minimum lenght of
password from 4 to 6 and set a maximum length if you desire. Then the line
should look like this one:

password required pam_unix.so nullok obscure min=6 max=11 md5

If we want to protect su, so that only some people can use it to become root
on your system, we need to add a new group "wheel" to your system (at least
that is the cleaner way, since no file has such a group permission yet).
Add root and the other users that should be able to "su" to the user root
to this group. Then create the following line in /etc/pam.d/su:

auth requisite pam_wheel.so group=wheel debug

This makes sure that only people from the group wheel can use to su to
become root. Other users will not be able to become root. In fact they
will get a denied message if they enter su.

And edit /etc/pam.d/other and add the following lines:

auth required pam_securetty.so
auth required pam_unix_auth.so
auth required pam_warn.so
auth required pam_deny.so
account required pam_unix_acct.so
account required pam_warn.so
account required pam_deny.so
password required pam_unix_passwd.so
password required pam_warn.so
password required pam_deny.so
session required pam_unix_session.so
sesion required pam_warn.so
session required pam_deny.so

This lines will provide with a good default configuration for all
applications that support PAM.

3.4 Edit /etc/limits

You should really take a serious look into this file. Here you can
define the user resource limits. If you use PAM, this file is invalid.
Use /etc/security/limits.conf instead.

3.5 Edit /etc/inetd.conf

You should stop all services on your system, like echo. charges,
discard, daytime, time, talk, ntalk and the HIGHLY insecure considered
r-services. After disabling those, you again should check if you really
need the inetd daemon. Some persons, including the author, prefer to use
daemons instead of calling them via inetd, because in past some Denial
of Service attacked against inetd were found, which increases the
machine's load rapidly. If you still want to run some kind of inetd
service, use a more configurable inet daemon like xinetd or rlinetd.

3.6 Edit /etc/login.defs

The next step is to edit the definitions for the login.

FAIL_DELAY 10

This variable should be set to a higher value to make it harder using the
terminal to log in. If a wrong password is typed in, he has to wait for 10
seconds to get a new login prompt, what is quite time consuming when you
test password. Pay attention to the fact, that this setting is useless
if using another program than getty, mingetty for example.

FAILLOG_ENAB yes

If you enable this variable, failed logins will be logged. It is important
to know them to see if someone tries a brute force attack to get login
information.

LOG_UNKFAIL_ENAB yes

If you set yes to the variable "FAILLOG_ENAB", then you should also set yes
to the variable "LOG_UNKFAIL_ENAB". This will record unkown usernames if the
login failed. If you do this, make sure, the logs are set to the right
permissions (640 I prefer, with appropriate group settings like adm
group), because if a user incidentally enters his password as username,
it gets logged and could be read by any other user.

SYSLOG_SU_ENAB yes

This one enables logging 'su' tries to syslog. Quite important on
serious machines, but note that this can vulnerate privacy issues as
well.

SYSLOG_SG_ENAB yes

And to see if someone change the group before executing a command, you should
set this variable to yes.

MD5_CRYPT_ENAB yes

As stated above, md5 sum passwords greatly reduce the problem of
dictionary attacks, because it is really complicate to perform a crack
against MD5 hashed passwords, at least it is hard to perform a successful
crack. But before enable this option, READ the docs about MD5. This
option only applies to slink users, otherwise you set this in PAM.

PASS_MAX_LEN 50

If you activated as suggested above md5 passwords in your PAM configuration,
then you should set this variable to the same value as you used in your
PAM configuration.

3.7 Editing /etc/ftpusers

This file contains a list of users, who are not allowed to log into
this host using ftp. Use this file, if you really want to allow ftp
(which is not recommended by the author, because it uses cleartext
passwords.)

3.8 Using tcp wrappers

TCP wrappers have been implemented, when there was no packet filter
available and you needed a sort of access control. The TCP wrappers
allow you to allow or deny a service for a host or a domain and define
a default allow or deny rule. This should fit the needs of most people.
If you want more informations look into the manpage hosts_access(5).

Now, here comes a small trick and probably the smallest intrusion
detection system available. In general you should have a decent firewall
policy as a first line and tcp wrappers as the second line of defense.
One little trick is to set up a spawn command in /etc/hosts.deny that
sends mail to root whenever a denied service triggers wrappers:

ALL: ALL: spawn ( \
echo -e "\n\
TCP Wrappers\: Connection refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
User\: %u\n\
Host\: %c\n\
Date\: $(date)\n\
" | /bin/mail -s "Connection to %d blocked" root)

3.9 Using ssh

If you are still running telnet and not ssh, you should stop reading
this manual now and change this. You should not use the telnet for remote
logins and instead use ssh. Especially today, where it is easy to sniff
traffic in the internet and get cleartext passwords, you should use a
secure way which is based on cryptography. Encourage all the other users
on your system to use ssh instead of telnet. Also you should try to avoid
logging into the system using ssh as root, and use alternative methods to
become root instead, like su or sudo. The sshd_config file (placed in
/etc/ssh) should be corrected a little bit as well.

PermitRootLogin No

Try not to permit Root Login wherever possible. If anyone wants to
become root via ssh, now two logins are needed.

Listen 666

Change the listen port, so the intruder cannot be completely sure that a
sshd daemon runs.

PermitEmptyPasswords no

Empty passwords are as ugly as hell out of the security view.

AllowUsers alex ref

Allow only certain users to have access via ssh to this machine.

AllowGroups wheel admin

Allow only certain group members to have access via ssh to this machine.
Both, AllowGroups and AllowUsers have equivalent directives for denying
access to a machine. Suprisingly they were called "DenyUsers" and
"DenyGroups".

PasswordAuthentication yes

Here it is completely your choice what you want to do. It is more secure
only to allow access to machine from users with ssh-keys placed in the
~/.ssh/authorized_keys file. If you want so, set this one to "no".

As a final note be aware, that these directives are from a OpenSSH
configuration file. Right now, there are three types of common used SSH
daemons, ssh1, ssh2 and OpenSSH by the OpenBSD people (hey, quite a cool
logo, I still need to buy a t-shirt). ssh1 was the first ssh daemon
available and it is the one, which is mainly used right now (I heard
rumors it even exists an windows port). ssh2 has many advantages over
ssh1 (that is why they called '2' I guess) except the bad non-opensource
license, what kicks this daemon for Debian. OpenSSH is completely free ssh
daemon, which is based on an old free ssh1, but then many improvements and
extensions were made and the most important thing, the non-free code was
removed, so that this is Debian's No. 1 choice right now.

3.10 Using su

If you really need to become the super user on your system, eg for
installing packages or adding users, you can use the command su to change
your identity. You should try to avoid any login as user root and instead
use the command su. The best solution is to remove su and switch to sudo
in the author's opinion.

3.11 Using sudo

sudo allows the user to execute commands under another users identity,
even as root. If the user is added in /etc/sudoers and authenticate
himself with his password, he is able to run commands, which have
been defined in /etc/sudoers, as user root.

3.12 Realize the insecurity of X over network

Today X-Terminals becoming more and more interesting for companies, where
one server is needed for a lot of workstations. But this is dangerous,
because you need to allow the server to connect to the the other X server
(it is a client, because X switches the definitions of client and server).
If you follow the suggestion from many docs, you do a "xhost +". This allows
every X client to connect to your system. So it is recommend to use the
command "xhost +hostname" instead for certain hosts, that should be able to
connect to your X serer. Or directly use ssh with X and encrypt the whole
session.
In addition, if you do not need X over the wires, then you can switch
off the binding on tcp port 6000 simply by typing:

startx -- -nolisten tcp

3.13 Using chroot

chroot is one of the most powerful possibilities to restrict a daemon or
a user or another service. Just imagine a jail around your target, where
the target cannot escape from (except you are root, but that creates other
security issues). If you do not trust a user, you can create a changed root
enviroment for him (if you have enough free space, because you need to copy
the libraries as well or compile everything statically, both eats up some
space, but security is not without any cutback). If now the user does
something malicious, he will not be very harmful anymore. A good example
for this case is, that you do not authenticate against /etc/passwd but LDAP
or MySQL instead. So your ftp-daemon needs a binary and perhaps a few
libraries. So a chrooted environment would be an execellent security
improvement, if a new exploit is known for this ftp-daemon. It is then only
possible to exploit the UID of the ftp-daemon-user and nothing else. Of
course, this complies with lots of other daemons as well.
As an additional note, the Debian default BIND (the name-service) is not
shipped chrooted per default, in fact no daemons comes chrooted.

3.14 Configuring some kernel features

## FIXME - Content missing ##
You can configure a lot of kernel settings during runtime by echo'ing
something into the procfile system or by using sysctl. By entering
'sysctl -A' you can see what you can configure and how it is configured
right now. Only in rare cases you really need to edit something here,
but you can increase security that way as well.

net/ipv4/icmp_echo_ignore_broadcasts = 0
This is a 'windows emulator', because it acts like windows on broadcast
ping, if this one is set to 1. It just does nothing.

net/ipv4/icmp_echo_ignore_all = 0
If you don't want to block ICMP on your firewall, just enable this.

3.15 Do not use software depending on svgalib

SVGAlib is very nice for console lovers like me, but in the past it has
been proven several times, that it is very insecure. Exploits against
zgv were released, and it was simple to become root. Try to prevent using
SVGAlib programs whereever possible.

3.16 The lpd and lprng issue

Imagine, you are coming to work, and the printer spits out endless
amounts of paper, because someone is DoS'ing your line printer
daemon. Nasty, isn't it? So, keep your printer servers specially secure.

### FIXME. Content missing. (No lpr experience) ###

3.17 Using mail appropiate in security context

Reading/receiving mail is the most common cleartext protocol. If you
either use POP3 or IMAP to get your mail you send your password
cleartext across the wires, so almost everyone can read your mails from
now on. So use SSL (Secure Socket Layer) to receive your mails.
The other alternative is ssh, if you have a shell account on your box.
Look at this basic fetchmailrc:

poll my-imap-mailserver.org via "localhost"
with proto IMAP port 1236
user "ref" there with password "hackme" is alex here warnings 3600
folders
.Mail/debian
preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
my-imap-mailserver.org sleep 15 </dev/null > /dev/null'

The important line is the preconnect line. It fires up a ssh session
and creates the necessary tunnel, which automatically forwards
connections to localhost port 1236 to the imap mail server, but
encrypted now.

3.18 Secure file transfers

Copying files in a secure manner from a host to another can be achieved
by using 'scp' which is included in the ssh packages. It works like rcp
but is encrypted completely, so the bad guys cannot even find out WHAT you
copy, what is not bad in some situations.

3.19 Using a loghost

A loghost is a host which collects the syslog data remote over the
network. If one of your machines is cracked the intruder is not able to
blur his spoors, except he hacks that loghost as well. So, spend your
loghost an extra amount of paranoia. Making your machine a loghost is
really simple. Just start the syslogd with 'syslogd -r' and a new
loghost is born. Now you have to configure your other machines to send
the data to the loghost. Add an entry like this one:

facility.level @your_loghost

facility should be one of authpriv, cron, daemon, kern, lpr, mail, news,
syslog, user, uucp and local1 up to local7. level should be alert, crit,
err, warning, notice, info debug. If you want to log everything remote,
just write:

*.* @your_loghost

into your syslog.conf. Logging remote as well as local would be the best
solution (the attacker could presume not to be found after deletion of
local log files, an often used method to mask an intrusion). See the
syslog(3), syslogd(8) and syslog.conf(5) manpage for some additional
information.

3.20 Using quotas

Having a good quota policy is important, as it keeps your users from
filling up your disk(s).
You can use two different quota systems - user quota and group quota.
As you probably figured out, user quota limits the amount of space a user
can take up, group quota does the equivalent for groups. Keep this in mind
when you're working out quota sizes.

There are a few important points to think about in setting up a quota
system:
- Keep the quotas small enough, so users do not eat up your disk space
- Keep the quotas big enough, so users do not complain or their mail
quota keeps them from accepting mail over a longer period
- Use quotas on all user-writable areas, on /home as well as on /tmp to
restrict the user as good as possible.

Every partition/directory users have full write access should be quota
enabled. So find out those partitions and directories and calculate a
valuable quota size, which concatenates usability and security.

So, now you want to use quotas. First of all you need to check whether
you enabled quota support in your kernel. If not, you will need to
recompile it. After this, control whether the package 'quota' is
installed. If not you will need this one as well.

Enabling quota for the respective filesystems is as easy as modifying
the 'defaults' setting to 'defaults,usrquota' in your /etc/fstab file. If
you need group quota, substitute 'usrquota' to 'grpquota'. You can also
use them both.
Then create empty quota.user and quota.group files in the roots of the
filesystems you want to use quotas on (e.g. 'touch /home/quota.user',
'touch /home/quota.group' for a /home filesystem).

Restart quota by doing '/etc/init.d/quota stop;/etc/init.d/quota
start'. Now quota should be running, and quota sizes can be set.

Editing quotas for a specific user (say 'ref') can be done by
'edquota -u ref'. Group quotas can be modified with edquota -g
<group>.
Then set the soft and hard quota and/or inode quotas as needed.

For more information about quotas, read the quota man page, and the
quota mini-howto.

3.21 Audit CGI scripts

If you do not trust your users (what you generally should not, this is a
hard world), take a closer look at their scripts they run, especially
CGI scripts, since those can be accessed by nearly everyone. You only
need to know the right URL and you have some kind of shell running as
the uid of the webserver. Think twice, whether you want to allow CGI
script execution for your users.

### FIXME - security webserver stuff, config examples ###

3.22 Logfile permissions

Some logfile permissions are not perfect after the installation. First
/var/log/lastlog and /var/log/faillog need not to be readable for the
normal users. In the lastlog file you can see the who logged in the
lasttime and in the faillog you see a summary of the failed logins. The
author recommends chmod'ing both to 660 both files. Take a brief log
over your logfiles and decide very carefully which logfiles you make
read/writeable for a user with another UID than 0 and a group other
named than 'adm' or 'root'.
I want to emphasize that the apache logfile permissions are really
screwed due to the fact, that the apache user owns the apache log files.
When you get a shell as such user with a apache backdoor, you easily can
remove the logfiles and blur your spoors.

3.23 chattr/lsattr

These two commands are very useful, but they only work for the ext2
filesystem. With 'lsattr' you can list the attributes of a file and with
'chattr' you can change them. Note that attributes do not equal to
permissions. In fact, they are completely different. Here are only
listed the most important attributes for increasing your security listed,
but there are other as well.
There are two flags which can only be set by the superuser. Those are
tho most important ones.
First there is the 'a' flag. If set on a file, this file can only be
opened for appending. This attribute is useful for some of the files in
/var/log/, though you should consider they get moved sometimes due to the
log rotation scripts.
The second flag is the 'i' flag, short for immutable. If set on a file,
this file can neither be modified nor deleted nor renamed and no link be
created to this file. If you do not want you users to look into your
config files you could set this flag and remove readability. Furthermore
it might give you a little bit security against intruders, because the
cracker might confused of not being able to remove a file. Although you
should never assume that the cracker is blind, he got into your system,
so he defeated your security policy.

3.24 Your file integrity

Are you sure /bin/login on your harddrive is still the binary you
installed there some months ago? What if it is a hacked version, which
stores the entered password in a hidden file or mails it in cleartext
version all over the internet?
The only method to have some kind of protection is to check your files
every day/hour/month (I prefer daily) by comparing the actual and the
old md5sum of this file. Two files cannot have the same md5sum, so
you're on the secure site here, except someone hacked the algorithm to
create md5sums on that machine, what is, well sticky. You really should
consider this auditing of your binaries as very important, since it is
an easy way to recognize changes at your binaries. Common tools used for
this are sXid, AIDE (Advanced Intrusion Detection Environment) and
TripWire (non-free).

Furthermore you can exchange your locate package with 'slocate' tool.
slocate is a security enhanced version of the GNU locate. When
performing a locate, the user only sees the files he really has access
to. In addition you can exclude any files or directoriey you want to
exclude.

3.25 Securing BIND

On a standard Debian installation, the name service daemon, BIND, runs
as user root and group root. It is possible and quite easy to achieve to
run BIND under another's UID. However, running BIND not as root prevents
it from detecting and using interfaces automatically, for example if you
stick a PCMCIA card into your laptop (anyway, I don't think BIND runs on
a laptop per default). Check the README.Debian file in your named
documentation directory for more.

Anyway, noone can deny the existing security problems, which occured in
the last months concerning BIND, so switchting the user is useful where
it is possible. First you should create a seperate user and group for it
(don't use either nobody or nogroup for every service not running as
root or another user). In this case I will use user and group 'named'.

Now edit /etc/init.d/bind with your favourite editor and change the line
beginning with 'start-stop-daemon --start' to

start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named

All you need to do now is to restart bind via '/etc/init.d/bind
restart', and then check your syslog for two entries like this:
Sep 4 15:11:08 nexus named[13439]: group = named
Sep 4 15:11:08 nexus named[13439]: user = named

Voila! Your named now does not run as root. To achieve maximum BIND
security, now build a chroot jail (See 3.13) around your daemon.

### FIXME - Add chrooting bind help with /var/chroot ###

4. After you have been compromised

4.1 General behaviour

If you really want to clean up residual wastes, you should remove the
compromised host out of your network and install a new OS from scratch
on. This might not take any effect if you do not know how the intruder
got root. So just check everything, firewall/file integration/loghost
logfiles and so on.

5. Exchange other software

5.1 Follow the debian security updates

As soon as new security bugs are revealed in packages, debian
maintainers and upstream authors try to patch them within days or even
hours. After the bug is fixed, a new package is provided on
http://security.debian.org
Put the following line in your sources.list and you will get the security
updates as well.

deb http://security.debian.org/debian-security potato/updates main
contrib non-free

And for most people (unless you live in a country which prohibits importing
or using strong cryptography) this one as well:

deb http://security.debian.org/debian-non-US potato/non-US main contrib
non-free

If you want, you can add the deb-src lines to apt as well, see the manpage
for further details.

5.2 Exchange software

FTP/Telnet/NIS/RPC:

You should try to avoid every network service which sends and receives
passwords in cleartext over a net. The author recommends the use of ssh
instead of telnet and ftp to everybody.

Also you should stop using NIS -the network information service- , if
it is possible, because it allows password sharing. This can be highly
insecure, if your setup is broken.

Last, but of sure not least, disable RPC whereever possible. Lots of
security holes are known and can be exploited. On the other hand NFS
services are quite important in some networks, so find a balance of
security and usability in a network. Most of the DDOS (distributed
denial of service) attacks use rpc exploits to get into the system and
act as a so called agent/handler.

Disabling portmap is quite simple. There are different methods. The
simplest one is to remove every symlink in /etc/rc${runlevel}.d/ (I mean
you should only remove the portmap symlinks, not the others!). You could
as well chmod 644 /etc/init.d/portmap, but that gives you an error
message. Or you could strip of the "start-stop-daemon" part in the init.d
shell script. Follow the perl motto...

Keep in mind, that migrating from telnet to ssh, but using any other
cleartext protocol does not increase your security in ANY way! Best
would be to remove ftp, telnet, pop, imap, http and to supersede them
with their respective crypted services.

Of course all these above listed hints apply to every Unix system.

5.3 Useful kernel patches

There do exist some kernel patches, which significant enhance the system
security. Here are the one I know:

- OpenWall patch by Solar Designer
This is a useful set of kernel restrictions, like restricted links,
FIFOs in /tmp, restricted /proc, special file descriptor handling,
non-executable user stack area and some more.
Available under: http://www.openwall.com/linux/

- LIDS - Linux intrusion detection patch by Huagang Xie & Philippe
Biondi
This patch should make the process of intrusion detection into a
Linux system easier. It has a lot of features but is still
considered beta. It supports protection of ioports, disallows
accessing the raw disk, protection of whole files, so they cannot
be changed even from root, bsd-alike append only mode for files and
some more.
Available under: http://lids.org

- POSIX Access Control Lists (ACLs) for Linux
This patch adds some kind of access control lists, an advanced
access method to files, to the linux kernel.
Available under: http://acl.bestbits.at/

- Linux trustees
This patch adds a decent advanced permissions system to your Linux
kernel. All the objects are stored in the kernel memory, what
allows a real quick lookup of all these permissions.
Available under: http://www.braysystems.com/linux/trustees.html

- International kernel patch
This is a crypt-orientated kernel patch, therefore you have to pay
attention to your local crypt policy. It basically adds use of
encrypted file systems.
Available under: http://www.kerneli.org

- SubDomain
A kernel extension to create a more secure and easier to setup
chroot environment. You can specify the files needed for the
chrooted service manually and do not have to compile the services
statically. (Not yet completed at the time of writing this).
Available under: http://www.immunix.org

5.4 Useful other software

First of it all, use a firewall. Use a firewall you are able to
administer and to control.

Then, use log analysis tools. Here are some tools (not only log
analysis), of which some are included in Debian GNU/Linux potato, others
not. The one which are included are prepended with a '+':

+ Nessus
+ sxid
+ syslog-ng
+ ippl
+ makepasswd
+ pwgen
+ logcheck
+ snort
+ nmap
+ cheops
+ ethereal
+ karpski
+ ntop
+ gnupg/pgp
+ lsof
+ ngrep
+ satan
+ LASG
+ gfcc
+ arpwatch
- saint
- sinus firewall
- portsentry
- john the ripper
- crack 5.0
- sentinel

5.5 Genius/Paranoia Ideas, what you could do

This is probably the most fluctuent and funny section, since I hope that
some of the "duh. that sounds crazy"-ideas might be realized.
Following here you will find some - well, it depends on the point of view
whether you say they are genius, paranoid, crazy or secure - ideas to
increase your security rapidly but you will not come unscathed out of
it.

- Playing around with PAM
As said in the phrack 56 PAM article the nice thing with PAM is that
"You are limited only by what you can think of.". It is true.
Imagine root login only possible with fingerprint or eyescan or
cryptocard (hm, why did I do an OR conjunction and not AND here).

- Fascist Logging
I would say everything we talked about logging above is "soft
logging". If you want to perform real logging, get a printer with
fanfold paper and log everything hard by printing on it. Sounds
funny, but it's reliable and it cannot be removed.

- CD distribution
This idea is very easy to realize but the hell secure. Create a
hardened debian distribution, a damned good firewall, make an ISO of
it and burn it on CD. Make it bootable. Upshot of all this is a ro
whole distribution with about 600 MB space for services and the fact
to make it impossible for intruders to get read write access on this
system. Just make sure every data which should get written, gets
written over the wires. Anyway, the intruder cannot change firewall
rules, routing entries or start own daemons.

- Switch module capability off
When you disable the usage of kernel modules at kernel compile time,
many kernel based backdoors are impossible to implement, since most
of them are based on kernel modules.