Once the system is installed you can still do more to secure the system; some of the steps described in this chapter can be taken. Of course this really depends on your setup but for physical access prevention you should read Change the BIOS (again), Section 4.1,Set a LILO or GRUB password, Section 4.2,Remove root prompt on the kernel, Section 4.3, Disallow floppy booting, Section 4.4, Restricting console login access, Section 4.5, and Restricting system reboots through the console, Section 4.6.
Before connecting to any network, especially if it's a public one you should, at the very least, execute a security update (see Execute a security update, Section 4.8). Optionally, you could take a snapshot of your system (see Taking a snapshot of the system, Section 4.19).
Remember Choose a BIOS password, Section 3.1? Well, then you should now, once you do not need to boot from removable media, to change the default BIOS setup so that it only boots from the hard drive. Make sure you will not lose the BIOS password, otherwise, in the event of a hard disk failure you will not be able to return to the BIOS and change the setup so you can recover it using, for example, a CD-ROM.
Another less secure but more convenient way is to change the setup to have the system boot up from the hard disk and, if it fails, try removable media. By the way, this is often done because most people don't use the BIOS password that often; it's easily forgotten.
Anybody can easily get a root-shell and change your passwords by entering <name-of-your-bootimage> init=/bin/sh at the boot prompt. After changing the passwords and rebooting the system, the person has unlimited root-access and can do anything he/she wants to the system. After this procedure you will not have root access to your system, as you do not know the root password.
To make sure that this cannot happen, you should set a password for the boot loader. You can choose between a global password or a password for a certain image.
For LILO you need to edit the config file /etc/lilo.conf and add a
password and restricted line as in the example below.
image=/boot/2.2.14-vmlinuz
label=Linux
read-only
password=hackme
restricted
When done, rerun lilo. Omitting the restricted line causes lilo
to always prompt for a password, regardless of whether LILO was passed
parameters. The default permissions for /etc/lilo.conf grant read
and write permissions to root, and enable read-only access for
lilo.conf's group, root.
If you use GRUB instead of LILO, edit /boot/grub/menu.lst and add
the following two lines at the top (substituting, of course hackme
with the desired password). This prevents users from editing the boot items.
timeout 3 specifies a 3 second delay before grub
boots the default item.
timeout 3
password hackme
To further harden the integrity of the password, you may store the password in
an encrypted form. The utility grub-md5-crypt generates a hashed
password which is compatible with grub's encrypted password algorithm (md5).
To specify in grub that an md5 format password will be used, use
the following directive:
timeout 3
password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0
The --md5 parameter was added to instruct grub to perform the md5
authentication process. The provided password is the md5 encrypted version of
hackme. Using the md5 password method is preferable to choosing its cleartext
counterpart. More information about grub passwords may be found
in the grub-doc package.
Linux 2.4 kernels provide a way to access a root shell while booting which will
be presented just after loading the cramfs file system. A message will appear
to permit the administrator to enter an executable shell with root permissions,
this shell can be used to manually load modules when autodetection fails. This
behavior is the default for initrd's linuxrc. The
following message will appear:
Press ENTER to obtain a shell (waits 5 seconds)
In order to remove this behavior you need to change
/etc/mkinitrd/mkinitrd.conf and set:
# DELAY The number of seconds the linuxrc script should wait to
# allow the user to interrupt it before the system is brought up
DELAY=0
Then regenerate your ramdisk image. You can do this for example with:
# cd /boot
# mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
or (preferred):
# dpkg-reconfigure -plow kernel-image-2.4.x-yz
Note that Debian 3.0 woody allows users to install 2.4 kernels (selecting
flavors), however the default kernel is 2.2 (save for some
architectures for which kernel 2.2 was not ported). If you consider this a bug
consider Bug 145244
before sending it.
The default MBR in Debian before version 2.2 did not act as a usual master boot record and left open a method to easily break into a system:
This behavior can be changed by entering:
lilo -b /dev/hda
Now LILO is put into the MBR. This can also be achieved by adding
boot=/dev/hda to lilo.conf. There is another
solution which will disable the MBR prompt completely:
install-mbr -i n /dev/hda
On the other hand, this "back door", of which many people are just not aware, may save your skin as well if you run into deep trouble with your installation for whatever reasons.
FIXME check whether this really is true as of 2.2 or was it 2.1? INFO: The bootdisks as of Debian 2.2 do NOT install the mbr, but only LILO.
Some security policies might force administrators to log in to the system
through the console with their user/password and then become superuser (with
su or sudo). This policy is implemented in Debian by
editing the /etc/login.defs file or /etc/securetty
when using PAM. In:
login.defs, editing the CONSOLE variable which defines a file or
list of terminals on which root logins are allowed
securetty by adding/removing the terminals to which root access
will be allowed.
When using PAM, other changes to the login process, which might include
restrictions to users and groups at given times, can be configured in
/etc/pam.d/login. An interesting feature that can be disabled is
the possibility to login with null (blank) passwords. This feature can be
limited by removing nullok from the line:
auth required pam_unix.so nullok
If your system has a keyboard attached to it anyone (yes anyone) can
reboot the system through it without login to the system. This might, or might
not, adhere to your security policy. If you want to restrict this, you must
check the /etc/inittab so that the line that includes
ctrlaltdel calls shutdown with the -a
switch (remember to run init q after making any changes to this
file). The default in Debian includes this switch:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Now, in order to allow some users to shutdown the system, as the
manpage shutdown(8) describes, you must create the file
/etc/shutdown.allow and include there the name of users which can
boot the system. When the three finger salute (a.k.a.
ctrl+alt+del) is given the program will check if any of the users
listed in the file are logged in. If none of them is, shutdown
will not reboot the system.
When mounting an ext2 partition, there are several additional options you can
apply to the mount call or to /etc/fstab. For instance, this is
my fstab entry for the /tmp partition:
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
You see the difference in the options sections. The option nosuid ignores the setuid and setgid bits completely, while noexec forbids execution of any program on that mount point, and nodev, ignores devices. This sounds great, but it
The noexec option prevents binaries from being executed directly, but is easily circumvented:
alex@joker:/tmp# mount | grep tmp
/dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
alex@joker:/tmp# ./date
bash: ./date: Permission denied
alex@joker:/tmp# /lib/ld-linux.so.2 ./date
Sun Dec 3 17:49:23 CET 2000
However, many script kiddies have exploits which try to create and execute
files in /tmp. If they do not have a clue, they will fall into
this pit. In other words, a user cannot be tricked into executing a trojanized
binary in /tmp e.g. when he incidentally adds /tmp
into his PATH.
Also be forewarned, some script might depend on /tmp being
executable. Most notably, Debconf has (had?) some issues regarding this, for
more information see Bug 116448.
The following is a more thorough example. A note, though: /var
could be set noexec, but some software like Smartlist keeps its programs in
/var. The same applies to the nosuid option.
/dev/sda6 /usr ext2 defaults,ro,nodev 0 2
/dev/sda12 /usr/share ext2 defaults,ro,nodev,nosuid 0 2
/dev/sda7 /var ext2 defaults,nodev,usrquota,grpquota 0 2
/dev/sda8 /tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2
/dev/sda9 /var/tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2
/dev/sda10 /var/log ext2 defaults,nodev,nosuid,noexec 0 2
/dev/sda11 /var/account ext2 defaults,nodev,nosuid,noexec 0 2
/dev/sda13 /home ext2 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2
/dev/fd0 /mnt/fd0 ext2 defaults,users,nodev,nosuid,noexec 0 0
/dev/fd0 /mnt/floppy vfat defaults,users,nodev.nosuid,noexec 0 0
/dev/hda /mnt/cdrom iso9660 ro,users,nodev.nosuid,noexec 0 0
/tmp noexec
Be careful if setting /tmp noexec when you want to install new
software, since some programs might use it for installation. Apt
is one such program (see http://bugs.debian.org/116448)
if not configured properly APT::ExtractTemplates::TempDir (see
apt-extracttemplates(1)). You can set this variable in
/etc/apt/apt.conf to another directory with exec privileges other
than /tmp.
Regarding noexec, please be aware that it might not offer you that much security. Consider this:
$ cp /bin/date /tmp
$ /tmp/date
(does not execute due to noexec)
$/lib/ld-linux.so.2 /tmp/date
(works since date is not executed directly)
If you set /usr read-only you will not be able to install new
packages on your Debian GNU/Linux system. You will have to first remount it
read-write, install the packages and then remount it read-only. The latest
apt version (in Debian 3.0 'woody') can be configured to run
commands before and after installing packages, so you might want to configure
it properly.
To do this modify /etc/apt/apt.conf and add:
DPkg
{
Pre-Invoke { "mount /usr -o remount,rw" };
Post-Invoke { "mount /usr -o remount,ro" };
};
Note that the Post-Invoke may fail with a "/usr busy" error message. This happens mainly when you are using files during the update that got updated. Annoying but not really a big deal. Just make sure these are no longer used and run the Post-Invoke manually.
As soon as new security bugs are detected in packages, Debian maintainers and
upstream authors generally patch them within days or even hours. After the bug
is fixed, a new package is provided on http://security.debian.org.
If you are installing a Debian release you must take into account that since the release was made there might have been security updates after it has been determined that a given package is vulnerable. Also, there might have been minor releases (there were seven in Debian 2.2 potato release) which include these package updates.
You need to note down the date the removable media (if you are using it) was made and check the security site in order to see if there are security updates. If there are and you cannot download the packages from the security site on another system (you are not connected to the Internet yet? are you?) before connecting to the network you could consider (if not protected by a firewall for example) adding firewall rules so that your system could only connect to security.debian.org and then run the update. A sample configuration is shown in Security update protected by a firewall, Appendix F.
To update the system, put the following line in your sources.list
and you will get security updates automatically, whenever you update your
system.
deb http://security.debian.org/ stable/updates main contrib non-free
Most people who don't live in a country which prohibits importing or using strong cryptography, should add this line as well:
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
If you like, you can add the deb-src lines to
/etc/apt/sources.list as well. See apt(8) for
further details.
FIXME: Add info on how the signature of packages is done so that this can be
done automatically through a cron job (big warning: DNS spoofing).
In order to receive information on available security updates you should
subscribe yourself to the debian-security-announce mailing list in order to
receive the Debian Security Advisories (DSAs). See The Debian Security Team, Section 7.1
for more information on how the Debian security team works. For information on
how to subscribe to the Debian mailing lists read http://lists.debian.org.
DSAs are signed with the Debian Security Team's signature which can be
retrieved from http://security.debian.org.
You should consider, also, subscribing to the debian-security mailing list for general discussion on security issues in the Debian operating system.
FIXME: add the key here too?
PAM (Pluggable Authentication Modules) allows system administrators to choose
how applications authenticate users. Note that PAM can do nothing unless an
application is compiled with support for PAM. Most of the applications that
are shipped with Debian 2.2 have this support built in. Furthermore, Debian
did not have PAM support before 2.2. The current default configuration for any
PAM-enabled service is to emulate UNIX authentication (read
/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz for more
information on how PAM services should work in Debian).
Each application with PAM support provides a configuration file in
/etc/pam.d/ which can be used to modify its behavior:
The following description is far from complete, for more information you might
want to read the The
Linux-PAM System Administrator's Guide (at the primary PAM distribution
site), this document is also provided in the
libpam-doc.
PAM offers you the possibility to go through several authentication steps at
once, without the user's knowledge. You could authenticate against a Berkeley
database and against the normal passwd file, and the user only
logs in if he authenticates correct in both. You can restrict a lot with PAM,
just as you can open your system doors very wide. So be careful. A typical
configuration line has a control field as its second element. Generally it
should be set to requisite, which returns a login failure if one
module fails.
The first thing I like to do, is to add MD5 support to PAM applications, since
this helps protect against dictionary cracks (passwords can be longer if using
MD5). The following two lines should be added to all files in
/etc/pam.d/ that grant access to the machine, like
login and ssh.
# Be sure to install libpam-cracklib first or you will not be able to log in
password required pam_cracklib.so retry=3 minlen=12 difok=3
password required pam_unix.so use_authtok nullok md5
So, what does this incantation do? The first line loads the cracklib PAM module, which provides password strength-checking, prompts for a new password with a minimum length of 12 characters, a difference of at least 3 characters from the old password, and allows 3 retries. The second line introduces the standard authentication module with MD5 passwords and allows a zero length password. The use_authtok directive is necessary to hand over the password from the previous module.
FIXME: Check if Bug
#112965 still stands (i.e. you can run into problems if you do not
have a wordlist (such as wenglish, wspanish,
wbritish...). It does not seem to have a dependency to
wordlist in woody.
To make sure that the user root can only log into the system from local
terminals, the following line should be enabled in
/etc/pam.d/login:
auth requisite pam_securetty.so
Then you should add the terminals from which the user root can log into the
system, in /etc/security/access.conf. Last but not least the
following line should be enabled if you want to set up user limits.
session required pam_limits.so
This restricts the system resources that users are allowed (see below in Limiting resource usage: the
limits.conf file, Section 4.10.2 ). For example, you could
restrict the number of concurrent logins (of a given group of users, or
system-wide) you may have, the number of processes, the memory size...
Now edit /etc/pam.d/passwd and change the first line. You should
add the option "md5" to use MD5 passwords, change the minimum length
of password from 4 to 6 (or more) and set a maximum length, if you desire. The
resulting line will look something like:
password required pam_unix.so nullok obscure min=6 max=11 md5
If you want to protect su, so that only some people can use it to become root
on your system, you need to add a new group "wheel" to your system
(that is the cleanest way, since no file has such a group permission yet). Add
root and the other users that should be able to su to the root
user to this group. Then add the following line to /etc/pam.d/su:
auth requisite pam_wheel.so group=wheel debug
This makes sure that only people from the group "wheel" can use
su to become root. Other users will not be able to become root.
In fact they will get a denied message if they try to become root.
If you want only certain users to authenticate at a PAM service, this is quite
easy to achieve by using files where the users who are allowed to login (or
not) are stored. Imagine you only want to allow user 'ref' to log in via
ssh. So you put him into /etc/sshusers-allowed and
write the following into /etc/pam.d/ssh:
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
Last, but not least, create /etc/pam.d/other and enter 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
session required pam_warn.so
session required pam_deny.so
These lines will provide a good default configuration for all applications that support PAM (access is denied by default).
limits.conf file
You should really take a serious look into this file. Here you can define user
resource limits. If you use PAM, the file /etc/limits.conf is
ignored and you should use /etc/security/limits.conf instead.
If you do not restrict resource usage, any user with a valid shell in
your system (or even an intruder who compromised the system through a service)
can use up as much CPU, memory, stack, etc. as the system can provide. This
resource exhaustion problem can only be fixed by the use of PAM. Note
that there is a way to add resource limits to some shells (for example,
bash has ulimit, see bash(1)), but since
not all of them provide the same limits and since the user can change shells
(see chsh(1)) it is better to place the limits on the PAM modules.
For more information read:
Seifried's
Securing Linux Step by Step on the Limiting users overview
section.
LASG in the
Limiting and monitoring users section.
FIXME: Get a good limits.conf up here
/etc/login.defsThe next step is to edit the basic configuration and action upon user login.
FAIL_DELAY 10
This variable should be set to a higher value to make it harder to use the
terminal to log in using brute force. If a wrong password is typed in, the
possible attacker (or normal user!) has to wait for 10 seconds to get a new
login prompt, which is quite time consuming when you test passwords (manually).
Pay attention to the fact that this setting is useless if using a program other
than getty, such as mingetty for example.
FAILLOG_ENAB yes
If you enable this variable, failed logins will be logged. It is important to keep track of them to catch someone who tries a brute force attack.
LOG_UNKFAIL_ENAB yes
If you set the variable FAILLOG_ENAB to yes, then you should also set this variable to yes. This will record unknown usernames if the login failed. If you do this, make sure the logs have the proper permissions (640 for example, with an appropriate group setting such as adm), because users often accidentally enter their password as the username and you do not want others to see it.
SYSLOG_SU_ENAB yes
This one enables logging of su attempts to syslog.
Quite important on serious machines but note that this can create privacy
issues as well.
SYSLOG_SG_ENAB yes
The same as SYSLOG_SU_ENAB but applies to the sg
program.
MD5_CRYPT_ENAB yes
As stated above, MD5 sum passwords greatly reduce the problem of dictionary attacks, since you can use longer passwords. If you are using slink, read the docs about MD5 before enabling this option. Otherwise this is set in PAM.
PASS_MAX_LEN 50
If MD5 passwords are activated in your PAM configuration, then this variable should be set to the same value as used there.
/etc/ftpusers
The /etc/ftpusers file contains a list of users who are not
allowed to log into the host using ftp. Only use this file if you really want
to allow ftp (which is not recommended in general, because it uses cleartext
passwords). If your daemon supports PAM, you can also use that to allow and
deny users for certain services.
FIXME (BUG): Is it a bug that the default ftpusers in Debian does
not include all the administrative users (in
base-passwd).
If you really need users to become the super user on your system, e.g. 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 su. Actually, the best solution is to remove
su and switch to sudo, as it has more features than
su. However, su is more common as it is used on many
other Unices.
sudo allows the user to execute defined commands under another
user's identity, even as root. If the user is added to
/etc/sudoers and authenticates himself correctly, he is able to
run commands which have been defined in /etc/sudoers. Violations,
such as incorrect passwords or trying to run a program you don't have
permission for, are logged and mailed to root.
You should modify /etc/security/access.conf also so that remote
administrative login is disallowed. This way the users need to use
su (or sudo) so that there is always an audit trace
whenever a local user wants to use administrative powers.
You need to add the following line to /etc/security/access.conf,
the default Debian configuration file has a sample line commented out:
-:wheel:ALL EXCEPT LOCAL
Sometimes you might think you need to have users created in your local system in order to provide a given service (pop3 mail service or ftp). Before doing so, first remember that the PAM implementation in Debian GNU/Linux allows you to validate users with a wide variety of external directory services (radius, ldap, etc.) provided by the libpam packages.
If users need to be created and the system can be accessed remotely take into
account that users will be able to log in to the system. You can fix this by
giving users a null (/dev/null) shell (it would need to be listed
in /etc/shells). If you want to allow users to access the system
but limit their movements, you can use the /bin/rbash, equivalent
to adding the -r option in bash (RESTRICTED
SHELL see bash(1)). Please note that even with restricted
shell, a user that access an interactive program (that might allow execution of
a subshell) could be able to bypass the limits of the shell.
Debian currently provides in the unstable release (and might be included in the
next stable releases) the pam_chroot module (in the
libpam-chroot). An alternative to it is to chroot
the service that provides remote logging (ssh,
telnet). [4]
If you wish to restrict when users can access the system you will have
to customize /etc/security/access.conf for your needs.
Information on how to chroot ssh for users is
described in Chroot
environment for SSH, Appendix G.
If you are paranoid you might want to add a defined .profile in
users' home directories that sets the environment in a way such that they
cannot remove audit capabilities from the shell (commands are dumped to
$HISTFILE. The .profile could be set as follows:
HISTFILE=/home/_user_/.bash_history
HISTSIZE=100000000000000000
HISTFILESIZE=10000000000000000
set -o HISTFILE
set -o HISTSIZE
set -o HISTFILESIZE
export HISTFILE HISTSIZE HISTFILESIZE
Note: the -o attribute sets a variable read-only in
bash.
For this to work the user cannot modify the .profile or
.bash_history but must be able to read the first one and write in
the second one. You can do this easily by changing these files and the
directory where they reside to be owned by another user (root), and give write
permissions to the user's group to the history file. Another option is through
the use of the chattr program.
If you are completely paranoid and want to audit every user's command, you
could take bash source code, edit it and have it send all that the
user typed into another file. Or have ttysnoop constantly monitor
any new ttys and dump the output into a file. Other useful program is Snoopy which is
a user-transparent program that hooks in as a library providing a wrapper
around execve() calls, any command executed is logged to
syslogd using the authpriv facility (usually stored
at /var/log/auth.log.
Note that you cannot use the script command for this since it will
not work as a shell (even if you add it to /etc/shells.
The previous example is a simple way to configure user auditing which might be
not useful for complex systems. If this is your case, you need to look at
acct, the accounting utilities. These will log all the commands
run by users or processes in the system, at the expense of disk space.
When activating accounting, all the information on processes and users is kept
under /var/account/, more specifically in the pacct.
The accounting package includes some tools (sa and
ac) to analyse this data.
If you want to see what users are usually doing, when they are
connecting you can use the wtmp database that includes all login
information. This file can be processed with several utilities, amongst them
sac which can output a profile on each user showing in which
timeframe they usually log on to the system.
In case you have accounting activated, you can also use the tools provided by it in order to determine when the users access the system and what they execute.
Depending on your user policy you might want to change how information is
shared between users, that is, what the default permissions of new files
created by users are. This change is set by defining a proper
umask setting for all users. You can change the UMASK
setting in /etc/limits.conf, /etc/profile,
/etc/csh.cshrc, /etc/csh.login,
/etc/zshrc and probably some others (depending on the shells you
have installed on your system). Of all of these the last one that gets loaded
takes precedence. The order is: PAM's limits.conf, the default
system configuration for the user's shell, the user's shell (his
~/.profile, ~/.bash_profile...)
Debian's default umask setting is 022 this means that
files (and directories) can be read and accessed by the user's group and by any
other users in the system. If this is too permissive for your system you will
have to change the umask setting for all the shells (and for PAM). Don't
forget to modify the files under /etc/skel/ since these will be
new user's defaults when created with the adduser command.
Note, however that users can modify their own umask setting if they want too, making it more permissive or more restricted.
FIXME: Content needed. Tell of consequences of changing packages permissions
when upgrading (and admin this paranoid should chroot his users
BTW).
If you need to grant users access to the system with a shell think about it very carefully. A user can, by default unless in a severely restricted environment (like a chroot jail), retrieve quite a lot of information from your system including:
/etc. However, Debian's default
permissions for some sensitive files (which might, for example, contain
passwords), will prevent access to critical information. To see which files
are only accessible by the root user for example find /etc -type f -a
-perm 600 -a -uid 0 as superuser.
/usr/share/doc directory or by guessing by looking at the binaries
and libraries installed in your system.
/var/log. Note also that some log files are
only accessible to root and the adm group (try find /var/log
-type f -a -perm 640) and some are even only available to the root user
(try find /var/log -type f -a -perm 600 -a -uid 0).
What can a user see in your system? Probably quite a lot of things, try this (take a deep breath):
find / -type f -a -perm +006 2>/dev/null
find / -type d -a -perm +007 2>/dev/null
The output is the list of files that a user can see and the directories to which he has access.
If you still grant shell access to users you might want to limit what information they can view from other users. Users with shell access have a tendency to create quite a number of files under their $HOMEs: mailboxes, personal documents, configuration of X/GNOME/KDE applications...
In Debian each user is created with one associated group, and no two users belong to the same group. This is the default behavior: when the userX is created a group with name userX is created and the user is assigned to it. This avoids the concept of a users group which might make it more difficult for users to hide information from other users.
However, users' $HOME directories are created with 0755 permissions (group-readable and world-readable). The group permissions is not an issue since only the user belongs to the group, however the world permissions might (or might not) be an issue depending on your local policy.
You can change this behaviour so that user creation provides different
$HOME permissions. To change the behaviour for new users
when they get created, change DIR_MODE in the configuration file
/etc/adduser.conf to 0750 (no world-readable access).
Users can still share information, but not directly in their $HOME directories unless they change its permissions.
Note that this will prevent users from being able to set up personal pages
(~userX) if a web server is present, since the web server will not
be able to read the $HOME directory and thus, the
public_html directory under it.
There are many cases when an administrator needs to create many user accounts
and provide passwords for all of them. Of course, the administrator could
easily just set the password to be the same as the user's account name, but
that would not be very sensitive security-wise. A better approach is to use a
password generating program. Debian provides makepasswd,
apg and pwgen packages which provide programs (the
name is the same as the package) that can be used for this purpose.
Makepasswd will generate true random passwords with an emphasis on
security over pronounceability while pwgen will try to make
meaningless but pronounceable passwords (of course this might depend on your
mother language). Apg has algorithms to provide for both (there
is a client/server version for this program but it is not included in the
Debian package).
Passwd does not allow non-interactive assignation of passwords
(since it uses direct tty access). If you want to change passwords when
creating a large number of users you can create them using adduser
with the --disabled-login option and then use
chpasswd [5] (in the
passwd package so you already have it installed). If you want to
use a file with all the information to make users as a batch process you might
be better off using newusers.
User passwords can sometimes become the weakest link in the security
of a given system. This is due to some users choosing weak passwords for their
accounts (and the more of them that have access to it the greater the chances
of this happening). Even if you established checks with the cracklib PAM
module and password limits as described in User authentication: PAM, Section 4.10.1
users will still be able to use weak passwords. Since user access might
include remote shell access (over ssh, hopefully) it's important
that a remote attacker is not able to guess user passwords (after he has been
able to do user enumeration by other means).
A system administrator must, given a big number of users, check if the
passwords they have are consistent with the local security policy. How to
check? Try to crack them as an attacker would if he had access to the hashed
passwords (the /etc/shadow file).
An administrator can use john together with an appropriate
wordlist [6] to check users'
passwords and take appropriate action when a weak password is detected.
Idle users are usually a security problem, a user might be idle maybe because he's out to lunch or because a remote connection was broken and not re-established. For whatever the reason, idle users might lead to a compromise:
telnet).
Some remote systems have even been compromised through an idle (detached)
screen.
Automatic disconnection of idle users is usually a part of the local security policy that must be enforced. There are several ways to do this:
bash is the user shell, a system administrator can set a
default TMOUT value (see bash(1)) which will make the
shell automatically remote idle users. Note that it must be set with the
-o option or users will be able to change (or unset) it.
timeoutd and configure /etc/timeouts
according to your local security policy. The daemon will watch for idle users
and time out their shells accordingly.
autolog and configure it to remove idle users.
The timeoutd or autolog daemons are the preferred
method since, after all, users can change their default shell or can, after
running their default shell, switch to another (uncontrolled) shell.
TCP wrappers were developed when there were no real packet filters available
and access control was needed. 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. If you
want more information take a look at hosts_access(5).
Many services installed in Debian are either:
tcpd)
On the one hand, for services configured in /etc/inetd.conf (this
includes telnet, ftp, netbios,
swat and finger) you will see that the configuration
file executes /usr/sbin/tcpd first. On the other hand, even if a
service is not launched by the inetd superdaemon, support for the
tcp wrappers rules can be compiled into it. Services compiled with tcp
wrappers in Debian include ssh, portmap, in.talk, rpc.statd, rpc.mountd,
gdm, oaf (the GNOME activator daemon), nessus and many
others.
To see which packages use tcpwrappers try:
$ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \
sed 's/,libwrap0$//;s/^[[:space:]]\+//'
Take this into account when running tcpchk. You can add services
that are linked to the wrapper library into the hosts.deny and
hosts.allow files but tcpchk will warn that it is not
able to find those services since it looks for them in
/etc/inetd.conf (the manpage is not totally accurate here).
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 [7] 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\
" | /usr/bin/mail -s "Connection to %d blocked" root) &
Beware: The above printed example is open to a DoS attack by making many connections in a short period of time. Many emails mean a lot of file I/O by sending only a few packets.
It is easy to see that the treatment of logs and is an important issue in a secure system. Suppose a system is perfectly configured and 99% secure. If the 1% attack occurs, and there are no security measures in place to, first, detect this and, second, raise alarms, the system is not secure at all.
Debian GNU/Linux provides some tools to perform log analysis, most notably
logcheck or loganalysis (both will need some
customisation to remove unnecessary things from the report). It might also be
useful, if the system is nearby, to have the system logs printed on a virtual
console. This is useful since you can (from a distance) see if the system is
behaving properly. Debian's /etc/syslog.conf comes with a
commented default configuration; to enable it uncomment the lines and restart
syslogd (/etc/init.d/syslogd restart):
daemon,mail.*;\
news.=crit;news.=err;news.=notice;\
*.=debug;*.=info;\
*.=notice;*.=warn /dev/tty8
There is a lot regarding log analysis that cannot be fully covered here, a good
resource for information is Counterpane's Log Analysis
Resources. In any case, even automated tools are no match for the
best analysis tool: your brain.
logcheck
The logcheck package in Debian is divided into two packages
logcheck (the main program) and logcheck-database (a
database of regular expressions for the program). The Debian default (in
/etc/cron.d/logcheck) is that logcheck is run daily
at 2 AM and once after each reboot.
This tool can be quite useful if properly customised to alert the administrator
to unusual events in the system. Logcheck can be fully customised
so that it can send mails from events recovered from the logs that are worthy
of attention. The default installation includes profiles for ignored events
and policy violations for three different setups (workstation, server and
paranoid). The Debian package includes a configuration file
/etc/logcheck/logcheck.conf, sourced by the program, that defines
which user the checks are sent to. It also provides a way for packages that
provide services to implement new policies in the directories:
/etc/logcheck/hacking.d/_packagename_,
/etc/logcheck/violations.d/_packagename_,
/etc/logcheck/violations.ignore.d/_packagename_,
/etc/logcheck/ignore.d.paranoid/_packagename_,
/etc/logcheck/ignore.d.server/_packagename_, and
/etc/logcheck/ignore.d.workstation/_packagename_. However, not
many packages currently do so. If you have a policy that can be useful for
other users, please send it as a bug report for the appropriate package (as a
wishlist bug). For more information read
/usr/share/doc/logcheck/README.Debian
The best way to configure logcheck is to install it (it will ask
for the user to which reports should be mailed and generate
/etc/logcheck/logcheck.logfiles from syslog entries). If you wish
to add new log files just add them to
/etc/logcheck/logcheck.logfiles. The package dependency will also
force the installation of logcheck-database; during installation
it will ask which security level is desired: workstation, server or paranoid.
This will make /etc/logcheck/ignore.d point to the appropriate
directories (through symbolic links). To change this run
dpkg-reconfigure -plow logcheck-database. Then create the
/etc/ignore.d/local, this file will hold all the rules to exclude
messages that should not be reported. Leave it empty for the moment (a simple
cp /dev/null /etc/ignore.d/local will work).
Once this is done you might want to check the mails that are sent, for the
first few days/weeks/months. If you find you are sent messages you do not wish
to receive, just add the regular expressions (see regex(7)) that
correspond to these messages to the /etc/ignore.d/local. It's an
ongoing tuning process; once the messages that are sent are always relevant you
can consider the tuning finished. Note that if logcheck does not
find anything relevant in your system it will not mail you even if it does run
(so you might get a mail only once a week, if you are lucky).
Debian comes with a standard syslog configuration (in
/etc/syslog.conf) that logs messages to the appropriate files
depending on the system facility. You should be familiar with this; have a
look at the syslog.conf file and the documentation if not. If you
intend to maintain a secure system you should be aware of where log messages
are sent so they do not go unnoticed.
For example, sending messages to the console also is an interesting setup useful for many production-level systems. But for many such systems it is also important to add a new machine that will serve as loghost (i.e. it receives logs from all other systems).
Root's mail should be considered also, many security controls (like
snort) send alerts to root's mailbox. This mailbox usually points
to the first user created in the system (check /etc/aliases).
Take care to send root's mail to some place where it will be read (either
locally or remotely).
There are other role accounts and aliases on your system. On a small system, it's probably simplest to make sure that all such aliases point to the root account, and that mail to root is forwarded to the system administrator's personal mailbox.
FIXME: it would be interesting to tell how a Debian system can send/receive
SNMP traps related to security problems (jfs). Check:
snmptraglogd, snmp and snmpd.
A loghost is a host which collects syslog data remotely over the network. If
one of your machines is cracked, the intruder is not able to cover his tracks,
unless he hacks the loghost as well. So, the loghost should be especially
secure. Making a machine a loghost is simple. Just start the
syslogd with syslogd -r and a new loghost is born.
In order to do this permanently in Debian, edit
/etc/init.d/sysklogd and change the line
SYSLOGD=""
to
SYSLOGD="-r"
Next, configure the other machines to send data to the loghost. Add an entry
like the following to /etc/syslog.conf:
facility.level @your_loghost
See the documentation for what to use in place of facility and level (they should not be entered verbatim like this). If you want to log everything remotely, just write:
*.* @your_loghost
into your syslog.conf. Logging remotely as well as locally is the
best solution (the attacker might presume to have covered his tracks after
deleting the local log files). See the syslog(3),
syslogd(8) and syslog.conf(5) manpages for additional
information.
It is not only important to decide how alerts are used, but also who has read/modify access to the log files (if not using a remote loghost). Security alerts which the attacker can change or disable are not worth much in the event of an intrusion. Also, you have to take into account that log files might reveal quite a lot of information about your system to an intruder if he has access to them.
Some log file permissions are not perfect after the installation (but of course
this really depends on your local security policy). First
/var/log/lastlog and /var/log/faillog do not need to
be readable by normal users. In the lastlog file you can see who
logged in recently, and in the faillog you see a summary of failed
logins. The author recommends chmod 660 for both. Take a brief
look at your log files and decide very carefully which log files to make
readable/writeable for a user with a UID other than 0 and a group other than
'adm' or 'root'. You can easily check this in your system with:
# find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
(see to what users do files in /var/log belong)
# find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
(see to what groups do files in /var/log belong)
# find /var/log -perm +004
(files which are readable by any user)
# find /var/log \! -group root \! -group adm -exec ls -ld {} \;
(files which belong to groups not root or adm)
To customize how log files are created you will probably have to customize the program that generates them. If the log file gets rotated, however, you can customize the behavior of creation and rotation.
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,
which the target cannot escape from (normally, but there are still a lot of
conditions that allow one to escape out of such a jail). If you do not trust a
user, you can create a change root environment for him. This can use quite a
bit of disk space as you need to copy all needed executables, as well as
libraries, into the jail. Even if the user does something malicious, the scope
of the damage is limited to the jail.
A good example for this case is, if you do not authenticate against
/etc/passwd but use LDAP or MySQL instead. So your ftp-daemon
only needs a binary and perhaps a few libraries. A chrooted
environment would be an excellent security improvement; if a new exploit is
found for this ftp-daemon, then attackers can only exploit the UID of the
ftp-daemon-user and nothing else.
Of course, many other daemons could benefit from this sort of arrangement as well.
However, be forewarned that a chroot jail can be broken if the
user running in it is the superuser. So, you need to make the service run as a
non-privileged user. By limiting its environment you are limiting the world
readable/executable files the service can access, thus, you limit the
possibilities of a privilege escalation by use of local system security
vulnerabilities. Even in this situation you cannot be completely sure that
there is no way for a clever attacker to somehow break out of the jail. Using
only server programs which have a reputation for being secure is a good
additional safety measure. Even minuscule holes like open file handles can be
used by a skilled attacker for breaking into the system. After all,
chroot was not designed as a security tool but as a testing tool.
As an additional note, the Debian default BIND (the Internet name service) is
not shipped chroot'ed per default; in fact, no daemons come
chroot'ed.
There is also some software (not currently in Debian but which might be
packaged in the future) that can help set up chroot environments.
See
FIXME: More content
Debian GNU/Linux provides some of the patches for the Linux kernel that enhance its security. These include:
lids-2.2.19)
lcap)
trustees)
selinux also available from
the developer's
website)
kernel-patch-2.2.19-harden
lcap
kernel-patch-freeswan)
kernel-patch-int
However, some patches have not been provided in Debian yet. If you feel that
some of these should be included please ask for it at the Work Needing and Prospective Packages.
Some of these are:
Buffer overflow is the name of a common attack to software which makes use of insufficient boundary checking (a common programming error) in order to execute machine code through a program's inputs. These attacks, against server software which listens to connections remotely and against local software which grant higher privileges to users (setuid or setgid) can result in the compromise of any given system.
There are mainly four methods to protect against buffer overflows:
this).
Debian GNU/Linux, as of the 3.0 release, only provides software to implement
the first and last of these methods (kernel patches and tools to detect
possible buffer overflows). The use of tools to detect buffer overflows
requires, in any case, of programming experience in order to fix (and
recompile) the code. Debian provides, for example: bfbtester (a
buffer overflow tester that brute-forces binaries through command line and
environment overflows) and njamd.
As for kernel patches (described in the section Adding kernel patches, Section 4.14), the
Openwall patch provides protection against buffer overflows in 2.2 linux
kernels. However, for 2.4 kernels, you need to use the Grsecurity patch (in
the kernel-patch-2.4-grsecurity which includes the Openwall patch
and many more features (including
ACLs and network randomness to make it more difficult to remote OS
fingerprinting), or the Linux Security Modules (in the
kernel-patch-2.4-lsm and kernel-patch-2.5-lsm
packages).
In any case, be aware, that even these workarounds might not prevent buffer
overflows since there are ways to circumvent these, as described in phrack's
magazine issue
58.
During normal system administration one usually needs to transfer files in and
out from the installed system. Copying files in a secure manner from a host to
another can be achieved by using the sshd server package. Another
possibility is the use of ftpd-ssl, a ftp server which uses the
Secure Socket Layer to encrypt the transmissions.
Any of these methods needs, of course, special clients. Debian provides
clients, for example the ssh provides scp. It works
like rcp but is encrypted completely, so the bad guys
cannot even find out WHAT you copy. There is also a ftp-ssl
client package for the equivalent server. You can find clients for these
software even for other operating systems (non-UNIX), putty and
winscp provide secure copy implementations for any version of
Microsoft's operating system.
Note that using scp provides access to the users to all the file
system unless chroot'ed as described in Chrooting ssh, Section 5.1.1.
FTP access can be chroot'ed, probably easier depending on you
chosen daemon, as described in Securing FTP, Section 5.3. If
you are worried about users browsing your local files and want to have
encrypted communication you can either use an ftp daemon with SSL support or
combine cleartext ftp and a VPN setup (see Virtual Private Networks, Section 8.5).
Having a good quota policy is important, as it keeps users from filling up the hard 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:
/home as well as on
/tmp.
Every partition or directory which users have full write access should be quota enabled. Calculate and assign a workable quota size for those partitions and directories which combines 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 file systems 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 file
systems you want to use quotas on (e.g. touch /home/quota.user
/home/quota.group for a /home file system).
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(/usr/share/doc/HOWTO/en-html/mini/Quota.html).
You might or might not like lshell, since it violates the FHS.
Also take into account that pam_limits.so might provide the same functionality
and lshell is currently orphaned
These two commands are very useful, but they only work for the ext2 file system. With 'lsattr' you can list the attributes of a file and with 'chattr' you can change them. Note that attributes are not the same thing as permissions. There are many attributes, but only the most important for increasing security are mentioned here. There are two flags which can only be set by the superuser.
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, it can neither be modified nor deleted or renamed and no link be created to it. If you do not want users to look into your config files you could set this flag and remove readability. Furthermore it can give you a little bit more security against intruders, because the cracker might be confused by not being able to remove a file. Nevertheless, you should never assume that the cracker is blind. After all, he got into your system.
You can, also, remove the chattr and lsattr programs
from the system so that an intruder with root access cannot change (or list)
this attributes. Since they are part of the e2fsprogs and it's
Required priority you cannot simply remove it. However, you can
safely delete these two applications (and probably some others) from the file
system. Copy them before to a removable media (floppy disk?) along with they
md5sums.
An intruder in the system would have to download his own copies of the binaries in the system (probably even compile them in it) which might give you a littler more time to detect and recover from the compromise before the whole system is overrun.
FIXME: This is a bug that could be reported, are any of the binaries provided
by the program useful in production systems? If not, and since the libraries
are needed by many packages a new package e2fsprogs-utils could be
included with less than Required priority.
Remember: lsattr and chattr are only available on ext2 file systems.
Are you sure /bin/login on your hard drive 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
hour/day/month (I prefer daily) by comparing the actual and the old md5sum of
this file. Two files cannot have the same md5sum (the MD5 digest is 128 bits,
so the chance that two different files will have the same md5sum is roughly one
in 3.4e3803), so you're on the safe site here, unless someone has also hacked
the algorithm that creates md5sums on that machine. This is, well, extremely
difficult and very unlikely. 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),
TripWire (non-free; the new version will be GPL),
integrit and samhain.
Installing debsums will help to check the file system integrity,
by comparing the md5sums of every file against the md5sums used in the Debian
package archive. But beware, those files can easily be changed.
Furthermore you can replace locate with slocate.
slocate is a security enhanced version of GNU locate. When using slocate, the
user only sees the files he really has access to and you can exclude any files
or directories on the system.
FIXME: put references to the snapshot taken after installation.
FIXME: Add a note regarding packages not providing debsums for all apps installed (not mandatory).
Debian provides a cron job that runs daily in
/etc/cron.daily/standard. This cron job will run the
/usr/sbin/checksecurity script that will store information of this
changes.
In order for this check to be made you must set
CHECKSECURITY_DISABLE="FALSE" in
/etc/checksecurity.conf. Note, this is the default, so unless you
have changed something, this option will already be set to "FALSE".
The default behavior does not send this information to the superuser but,
instead keeps daily copies of the changes in
/var/log/setuid.changes. You should set the CHECKSECURITY_EMAIL
(in /etc/checksecurity.conf) to 'root' to have this information
mailed to him. . See checksecurity(8) for more configuration
info.
FIXME. More (Debian-specific) content needed
FIXME: Content missing
Many features of the kernel can be modified while running by echoing something
into the /proc file system or by using sysctl. By
entering /sbin/sysctl -A you can see what you can configure and
what the options are, and it can be modified running /sbin/sysctl -w
variable=value (see sysctl(8)). Only in rare cases do you
need to edit something here, but you can increase security that way as well.
For example:
net/ipv4/icmp_echo_ignore_broadcasts = 1
This is a Windows emulator because it acts like Windows on broadcast ping if this option is set to 1. That is, ICMP_ECHO request sent to the broadcast address will be ignored. Otherwise, it does nothing.
If you want to block any ICMP echo requests on your system, enable this configuration option:
net/ipv4/icmp_echo_ignore_all = 0
To log packets with impossible addresses (due to wrong routes) on your network use:
/proc/sys/net/ipv4/conf/all/log_martians = 1
For more information on what things can be done with
/proc/sys/net/ipv4/* read
/usr/src/linux/Documentation/filesystems/proc.txt. All the
options are describe thoroughly under
/usr/src/linux/Documentation/networking/ip-sysctl.txt [8].
This option is a double-edged sword. On the one hand it protects your system against syn flooding; on the other hand it violates defined standards (RFCs).
net/ipv4/tcp_syncookies = 1
If you want to change this option you each time the kernel is working you need to change it in /etc/network/options by setting syncookies=yes. This will take effect whener /etc/init.d/networking is run (which is done at boot time) whileas this will only work with the current running kernel:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
This option will only be available if the kernel is compiled with the CONFIG_SYNCOOKIES. All Debian kernels are compiled with this option builtin but you can verify it running:
$ sysctl -A |grep syncookies
net/ipv4/tcp_syncookies = 1
For more information on TCP syncookies read http://cr.yp.to/syncookies.html.
When setting configuration options for the kernel networking you need configure it so that it's loaded every time the system is restarted. The following example enables many of the previous options as well as other useful options.
Create the script in /etc/network/interface-secure (the name is
given as an example) and call it from /etc/network/interfaces like
this:
auto eth0
iface eth0 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.xxx
broadcast xxx.xxx.xxx.xxx
gateway xxx.xxx.xxx.xxx
pre-up /etc/network/interface-secure
# Script-name: /etc/network/interface-secure
# Modifies some default behaviour in order to secure against
# some TCP/IP spoofing & attacks
#
# Contributed by Dariusz Puchalak
#
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# broadcast echo protection enabled
echo 0 > /proc/sys/net/ipv4/ip_forward # ip forwarding disabled
echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookie protection enabled
echo 1 >/proc/sys/net/ipv4/conf/all/log_martians
# Log packets with impossible addresses
# but be careful with this on heavy loaded web servers
echo 1 > /proc/sys/net/ipv4/ip_always_defrag
# defragging protection always enabled
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# bad error message protection enabled
# now ip spoofing protection
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done
# and finally some more things:
# Disable ICMP Redirect Acceptance
for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
echo 0 > $f
done
for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
echo 0 > $f
done
# Disable Source Routed Packets
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
echo 0 > $f
done
# Log Spoofed Packets, Source Routed Packets, Redirect Packets
for f in /proc/sys/net/ipv4/conf/*/log_martians; do
echo 1 > $f
done
You can also create a init.d script and have it run on bootup
(using update-rc.d to create the appropriate rc.d
links).
In order to have firewall capabilities, either to protect the local system or
others behind it, the kernel needs to be compiled with firewall
capabilities. The standard Debian 2.2 kernel (also 2.2) provides the packet
filter ipchains firewall, Debian 3.0 standard kernel (kernel 2.4)
provides the stateful packet filter iptables (netfilter)
firewall. Older Debian distributions would need the appropriate kernel patch
(Debian 2.1 uses kernel 2.0.34).
In any case, it is pretty easy to use a kernel different from the one provided
by Debian. You can find pre-compiled kernels as packages you can easily
install in the Debian system. You can also download the kernel sources using
the kernel-source-X and build custom kernel packages using
make-kpkg.
Setting up firewalls in Debian is discussed more thoroughly in Adding firewall capabilities, Section 5.14.
Systems with more than one interface on different networks can have services configured so that they will bind only to a given IP address. This usually prevents services when requested through a given address. However, this does not mean (although it's a common misconception even I had) that the service is bound to a given hardware address (interface card). [9]
This is not an ARP issue and it's not an RFC violation (it's called weak
end host in RFC1122, section
3.3.4.2). Remember, IP addresses have nothing to do with physical interfaces.
On 2.2 (and previous) kernels this can be fixed with:
# echo 1 > /proc/sys/net/ipv4/conf/all/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
.....
On later kernels this can be fixed either with:
Along this text there will be many ocasions in which it is shown how to configure some services (sshd server, apache, printer service...) in order to have them listening on any given address, the reader should take into account that, without the fixes given here, the fix would not prevent accesses from within the same (local) network. [12]
FIXME: comments on bugtraq indicate there is a Linux specific method to bind to a given interface.
FIXME: Submit a bug against netbase so that the routing fix is standard behaviour in Debian?
When you don't trust the other boxes on your LAN (which should always be the case, because it's the safest attitude) you should protect yourself from the various existing ARP attacks.
As you know the ARP protocol is used to link IP addresses to MAC addresses.
(see RFC826
for all the details). Every time you send a packet to an IP address an arp
resolution is done (first by looking into the local ARP cache then if the IP
isn't present in the cache by broadcasting an arp query) to find the target's
hardware address. All the ARP attacks aim to fool your box into thinking that
box B's IP address is associated to the intruder's box's MAC address; Then
every packet that you want to send to the IP associated to box B will be send
to the intruder's box...
Those Attacks (Cache poisonning, ARP spoofing...) allow the attacker to sniff
the traffic even on switched networks, to easily hijack connections, to
disconnect any host from the network... Arp attack are powerful and simple to
implement, several tools exists : arpspoof (present in package
dsniff), arpmim,
arpoison...
However, there is always a solution:
arp -s host_name hdwr_addr
By setting static entries for each important host in your network you ensure that nobody will create/modify a (fake) entry for these hosts (static entries don't expire and can't be modified) and spoofed arp replies will be ignored.
arpwatch,
karpski or more general IDS that can also detect suspicious arp
traffic (snort, prelude...).
Before putting the system into production system you culd take a snapshot of the whole system. This snapshot could be used in the event of a compromise (see After the compromise, Chapter 10). You should remake this upgrade whenever the system is upgraded, specially if you upgrade to a new Debian release.
For this you can use a writable removable-media that can be set up read-only, this could be a floppy disk (read protected after use) or a CD on a CD-ROM unit (you could use a rewriteable CD-ROM so you could even keep backups of md5sums in different dates).
The following script creates such a snapshot:
#!/bin/bash
/bin/mount /dev/fd0 /mnt/floppy
/bin/cp /usr/bin/md5sum /mnt/floppy
echo "Calculating md5 database"
>/mnt/floppy/md5checksums.txt
for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
do
find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt
done
/bin/umout /dev/fd0
echo "post installation md5 database calculated"
Note that the md5sum binary is placed on the floppy drive so it can be used later on to check the binaries of the system (just in case it gets trojaned).
The snapshot does not include the files under /var/lib/dpkg/info
which includes the md5 hashes of installed packages (in files ended with
.md5sums). You could copy this information along too, however you
should notice:
Once the snapshot is done you should make sure to set the medium read-only.
You can then store it for backup or place it in the drive and use it to drive a
cron check nightly comparing the original md5sums against those on
the snapshot.
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 wherever possible.
Securing Debian Manual
2.6 10 October 2002Wed, 18 Sep 2002 14:09:35 +0200jfs@computer.org