[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ next ]
Before you install any operating system on your computer, set up a BIOS password. After installation (once you have enabled bootup from the hard disk) you should go back to the BIOS and change the boot sequence to disable booting from floppy, CD-ROM and other devices that shouldn't boot. Otherwise a cracker only needs physical access and a boot disk to access your entire system.
Disabling booting unless a password is supplied is even better. This can be very effective if you run a server, because it is not rebooted very often. The downside to this tactic is that rebooting requires human intervention which can cause problems if the machine is not easily accessible.
Note: many BIOSes have well known default master passwords, and applications also exist to retrieve the passwords from the BIOS. Corollary: don't depend on this measure to secure console access to system.
An intelligent partition scheme depends on how the machine is used. A good rule of thumb is to be fairly liberal with your partitions and to pay attention to the following factors:
Any directory tree which a user has write permissions to, such as e.g.
/home, /tmp and /var/tmp/, should be on
a separate partition. This reduces the risk of a user DoS by filling up your
"/" mount point and rendering the system unusable (Note: this is not
strictly true, since there is always some space reserved for root which a
normal user cannot fill), and it also prevents hardlink attacks. [2]
Any partition which can fluctuate, e.g. /var (especially
/var/log) should also be on a separate partition. On a Debian
system, you should create /var a little bit bigger than on other
systems, because downloaded packages (the apt cache) are stored in
/var/cache/apt/archives.
Any partition where you want to install non-distribution software should be on
a separate partition. According to the File Hierarchy Standard, this is
/opt or /usr/local. If these are separate
partitions, they will not be erased if you (have to) reinstall Debian itself.
From a security point of view, it makes sense to try to move static data to its own partition, and then mount that partition read-only. Better yet, put the data on read-only media. See below for more details.
In the case of a mail server it is important to have a separate partition for
the mail spool. Remote users (either knowingly or unknowingly) can fill the
mail spool (/var/mail and/or /var/spool/mail). If
the spool is on a separate partition, this situation will not render the system
unusable. Otherwise (if the spool directory is on the same partition as
/var) the system might have important problems: log entries will
not be created, packages cannot be installed, and some programs might even have
problems starting up (if they use /var/run).
Also, for partitions in which you cannot be sure of the needed space,
installing Logical Volume Manager (lvm-common and the needed
binaries for your kernel, this might be either lvm10,
lvm6, or lvm5). Using lvm, you can
create volume groups that expand multiple physical volumes.
During the system partitioning you also have to decide which file system you want to use. The default file system[3] selected in the Debian installation for Linux partitions is ext3, a journaling file system. It is recommended that you always use a journaling file system, such as ext3, reiserfs, jfs or xfs, to minimize the problems derived from a system crash in the following cases:
for laptops in all the file systems installed. That way if you run out of battery unexpectedly or the system freezes due to a hardware issue (such as X configuration which is somewhat common) you will be less likely to lose data during a hardware reboot.
for production systems which store large amounts of data (like mail servers, ftp servers, network file systems...) it is recommended on these partitions. That way, in the event of a system crash, the server will take less time to recover and check the file systems, and data loss will be less likely.
Leaving aside the performance issues regarding journalling file systems (since this can sometimes turn into a religious war), it is usually better to use the ext3 file system. The reason for this is that it is backwards compatible with ext2, so if there are any issues with the journalling you can disable it and still have a working file system. Also, if you need to recover the system with a bootdisk (or CD-ROM) you do not need a custom kernel. If the kernel is 2.4 or 2.6 ext3 support is already available, if it is a 2.2 kernel you will be able to boot the file system even if you lose journalling capabilities. If you are using other journalling file systems you will find that you might not be able to recover unless you have a 2.4 or 2.6 kernel with the needed modules built-in. If you are stuck with a 2.2 kernel on the rescue disk, it might be even more difficult to have it access reiserfs or xfs.
In any case, data integrity might be better under ext3 since it
does file-data journalling while others do only meta-data journalling, see
http://lwn.net/2001/0802/a/ext3-modes.php3.
Notice, however, that there are some partitions that might not benefit from
using a journaling filesystem. For example, if you are using a separate
partition for /tmp/ you might be better off using a standard
ext2 filesystem as it will be cleaned up when the system boots.
The system should not be immediately connected to the Internet during installation. This could sound stupid but network installation is a common method. Since the system will install and activate services immediately, if the system is connected to the Internet and the services are not properly configured you are opening it to attack.
Also note that some services might have security vulnerabilities not fixed in the packages you are using for installation. This is usually true if you are installing from old media (like CD-ROMs). In this case, the system could even be compromised before you finish installation!
Since Debian installation and upgrades can be done over the Internet you might
think it is a good idea to use this feature on installation. If the system is
going to be directly connected to the Internet (and not protected by a firewall
or NAT), it is best to install without connection to the Internet, using a
local packages mirror for both the Debian package sources and the security
updates. You can set up package mirrors by using another system connected to
the Internet with Debian-specific tools (if it's a Debian system) like
apt-move or apt-proxy, or other common mirroring
tools, to provide the archive to the installed system. If you cannot do this,
you can set up firewall rules to limit access to the system while doing the
update (see Security update protected
by a firewall, Appendix F).
Setting a good root password is the most basic requirement for having a secure
system. See passwd(1) for some hints on how to create good
passwords. You can also use an automatic password generation program to do
this for you (see Generating user passwords,
Section 4.10.13).
Plenty of information on choosing good passwords can be found on the Internet;
two that provide a decent summary and rationale are Eric Wolfram's How to: Pick a Safe
Password and Walter Belgers' Unix Password
Security
At the end of the installation, you will be asked if shadow passwords should be
enabled. Answer yes to this question, so passwords will be kept in the file
/etc/shadow. Only the root user and the group shadow have read
access to this file, so no users will be able to grab a copy of this file in
order to run a password cracker against it. You can switch between shadow
passwords and normal passwords at any time by using shadowconfig.
Read more on shadow passwords in Shadow
Password
(/usr/share/doc/HOWTO/en-txt/Shadow-Password.txt.gz).
Furthermore, the installation uses MD5 hashed passwords per default. This is
generally a very good idea since it allows longer passwords and better
encryption. MD5 allows for passwords longer than 8 characters. This, if used
wisely, can make it more difficult for attackers to brute-force the system's
passwords. Regarding MD5 passwords, this is the default option when installing
the latest passwd package. You can recognize MD5 passwords in the
/etc/shadow file by their $1$ prefix.
This, as a matter of fact, modifies all files under /etc/pam.d by
substituting the password line and include md5 in it:
password required pam_unix.so md5 nullok obscure min=6 max=16
If max is not set over 8 the change will not be useful at all. For more information on this read User authentication: PAM, Section 4.10.1.
Note: the default configuration in Debian, even when activating MD5 passwords, does not modify the previously set max value.
Services are programs such as ftp servers and web servers. Since they have to be listening for incoming connections that request the service, external computers can connect to yours. Services are sometimes vulnerable (i.e. can be compromised under a given attack) and hence present a security risk.
You should not install services which are not needed on your machine. Every installed service might introduce new, perhaps not obvious (or known), security holes on your computer.
As you may already know, when you install a given service the default behavior is to activate it. In a default Debian installation, with no services installed, the number of running services is quite low and the number of network-oriented services is even lower. In a default Debian 3.1 standard installation you will end up with OpenSSH, Exim (depending on how you configured it) and the RPC portmapper available as network services[4]. If you did not go through a standard installation but selected an expert installation you can end up with no active network services. The RPC portmapper is installed by default because it is needed for many services, for example NFS, to run on a given system. However, it can be easily removed, see Securing RPC services, Section 5.13 for more information on how to secure or disable RPC services.
When you install a new network-related service (daemon) in your Debian
GNU/Linux system it can be enabled in two ways: through the inetd
superdaemon (i.e. a line will be added to /etc/inetd.conf) or
through a standalone program that binds itself to your network interfaces.
Standalone programs are controlled through the /etc/init.d files,
which are called at boot time through the SysV mechanism (or an alternative
one) by using symlinks in /etc/rc?.d/* (for more information on
how this is done read
/usr/share/doc/sysvinit/README.runlevels.gz).
If you want to keep some services but use them rarely, use the
update-* commands, e.g. update-inetd and
update-rc.d to remove them from the startup process. For more
information on how to disable network services read Disabling daemon services, Section 3.6.1. If you
want to change the default behaviour of starting up services on installation of
their associated packages[5] use
policy-rc.d, please read
/usr/share/doc/sysv-rc/README.policy-rc.d.gz for more information.
invoke-rc.d support is mandatory in Debian, which means that for
Debian 4.0 etch and later releases you can write a policy-rc.d file
that forbids starting new daemons before you configure them. Although no such
scripts are packaged yet, they are quite simple to write. See
policyrcd-script-zg2.
Disabling a daemon service is quite simple. You either remove the package
providing the program for that service or you remove or rename the startup
links under /etc/rc${runlevel}.d/. If you rename them make sure
they do not begin with 'S' so that they don't get started by
/etc/init.d/rc. Do not remove all the available links or the
package management system will regenerate them on package upgrades, make sure
you leave at least one link (typically a 'K', i.e. kill, link). For more
information read Customizing
runlevels section of the Debian Reference (Chapter 2 - Debian
fundamentals).
You can remove these links manually or using update-rc.d (see
update-rc.d(8)). For example, you can disable a service from
executing in the multi-user runlevels by doing:
# update-rc.d name stop XX 2 3 4 5 .
Where XX is a number that determines when the stop action for that
service will be executed. Please note that, if you are not using
file-rc, update-rc.d -f service remove
will not work properly, since all links are removed, upon
re-installation or upgrade of the package these links will be re-generated
(probably not what you wanted). If you think this is not intuitive you are
probably right (see Bug
67095). From the manpage:
If any files /etc/rcrunlevel.d/[SK]??name already exist then
update-rc.d does nothing. This is so that the system administrator
can rearrange the links, provided that they leave at least one
link remaining, without having their configuration overwritten.
If you are using file-rc all the information regarding services
bootup is handled by a common configuration file and is maintained even if
packages are removed from the system.
You can use the TUI (Text User Interface) provided by sysv-rc-conf
to do all these changes easily (sysv-rc-conf works both for
file-rc and normal System V runlevels). You will also find
similar GUIs for desktop systems. You can also use the command line interface
of sysv-rc-conf:
# sysv-rc-conf foobar off
The advantage of using this utility is that the rc.d links are returned to the status they had before the 'off' call if you re-enable the service with:
# sysv-rc-conf foobar on
Other (less recommended) methods of disabling services are:
Removing the /etc/init.d/service_name script and
removing the startup links using:
# update-rc.d name remove
Move the script file (/etc/init.d/service_name) to
another name (for example
/etc/init.d/OFF.service_name). This will leave
dangling symlinks under /etc/rc${runlevel}.d/ and will generate
error messages when booting up the system.
Remove the execute permission from the
/etc/init.d/service_name file. That will also generate
error messages when booting.
Edit the /etc/init.d/service_name script to have it
stop immediately once it is executed (by adding an exit 0 line at
the beginning or commenting out the start-stop-daemon part in it).
If you do this, you will not be able to use the script to startup the service
manually later on.
Nevertheless, the files under /etc/init.d are configuration files
and should not get overwritten due to package upgrades if you have made local
changes to them.
Unlike other (UNIX) operating systems, services in Debian cannot be disabled by
modifying files in /etc/default/service_name.
FIXME: Add more information on handling daemons using file-rc.
inetd or its services
You should check if you really need the inetd daemon nowadays.
Inetd was always a way to compensate for kernel deficiencies, but those have
been taken care of in modern Linux kernels. Denial of Service possibilities
exist against inetd (which can increase the machine's load
tremendously), and many people always preferred using stand-alone daemons
instead of calling services via inetd. If you still want to run
some kind of inetd service, then at least switch to a more
configurable Inet daemon like xinetd, rlinetd or
openbsd-inetd.
You should stop all unneeded Inetd services on your system, like
echo, chargen, discard,
daytime, time, talk, ntalk
and r-services (rsh, rlogin and rcp)
which are considered HIGHLY insecure (use ssh instead).
You can disable services by editing /etc/inetd.conf directly, but
Debian provides a better alternative: update-inetd (which comments
the services in a way that it can easily be turned on again). You could remove
the telnet daemon by executing this commands to change the config
file and to restart the daemon (in this case the telnet service is
disabled):
/usr/sbin/update-inetd --disable telnet
If you do want services listening, but do not want to have them listen on all
IP addresses of your host, you might want to use an undocumented feature on
inetd (replace service name with service@ip syntax) or use an
alternative inetd daemon like xinetd.
Debian comes with a lot of software, for example the Debian 3.0 woody release includes 6 or 7 (depending on architecture) CD-ROMs of software and thousands of packages, and the Debian 3.1 sarge release ships with around 13 CD-ROMs of software. With so much software, and even if the base system installation is quite reduced [6] you might get carried away and install more than is really needed for your system.
Since you already know what the system is for (don't you?) you should only install software that is really needed for it to work. Any unnecessary tool that is installed might be used by a user that wants to compromise the system or by an external intruder that has gotten shell access (or remote code execution through an exploitable service).
The presence, for example, of development utilities (a C compiler) or
interpreted languages (such as perl - but see below -,
python, tcl...) may help an attacker compromise the
system even further:
allowing him to do privilege escalation. It's easier, for example, to run local exploits in the system if there is a debugger and compiler ready to compile and test them!
providing tools that could help the attacker to use the compromised system as a base of attack against other systems. [7]
Of course, an intruder with local shell access can download his own set of tools and execute them, and even the shell itself can be used to make complex programs. Removing unnecessary software will not help prevent the problem but will make it slightly more difficult for an attacker to proceed (and some might give up in this situation looking for easier targets). So, if you leave tools in a production system that could be used to remotely attack systems (see Remote vulnerability assessment tools, Section 8.1) you can expect an intruder to use them too if available.
Please notice that a default installation of Debian sarge (i.e. an installation where no individual packages are selected) will install a number of development packages that are not usually needed. This is because some development packages are of Standard priority. If you are not going to do any development you can safely remove the following packages from your system, which will also help free up some space:
Package Size
------------------------+--------
gdb 2,766,822
gcc-3.3 1,570,284
dpkg-dev 166,800
libc6-dev 2,531,564
cpp-3.3 1,391,346
manpages-dev 1,081,408
flex 257,678
g++ 1,384 (Note: virtual package)
linux-kernel-headers 1,377,022
bin86 82,090
cpp 29,446
gcc 4,896 (Note: virtual package)
g++-3.3 1,778,880
bison 702,830
make 366,138
libstdc++5-3.3-dev 774,982
This is something that is fixed in releases post-sarge, see Bug
#301273 and Bug
#301138. Due to a bug in the installation system this did not
happen when installing with the installation system of the Debian 3.0
woody release.
You must take into account that removing perl might not be too
easy (as a matter of fact it can be quite difficult) in a Debian system since
it is used by many system utilities. Also, the perl-base is
Priority: required (that about says it all). It's still doable, but
you will not be able to run any perl application in the system;
you will also have to fool the package management system to think that the
perl-base is installed even if it's not. [8]
Which utilities use perl? You can see for yourself:
$ for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/*; do [ -f $i ] && {
type=`file $i | grep -il perl`; [ -n "$type" ] && echo $i; }; done
These include the following utilities in packages with priority required or important:
/usr/bin/chkdupexe of package util-linux.
/usr/bin/replay of package bsdutils.
/usr/sbin/cleanup-info of package dpkg.
/usr/sbin/dpkg-divert of package dpkg.
/usr/sbin/dpkg-statoverride of package dpkg.
/usr/sbin/install-info of package dpkg.
/usr/sbin/update-alternatives of package dpkg.
/usr/sbin/update-rc.d of package sysvinit.
/usr/bin/grog of package groff-base.
/usr/sbin/adduser of package adduser.
/usr/sbin/debconf-show of package debconf.
/usr/sbin/deluser of package adduser.
/usr/sbin/dpkg-preconfigure of package debconf.
/usr/sbin/dpkg-reconfigure of package debconf.
/usr/sbin/exigrep of package exim.
/usr/sbin/eximconfig of package exim.
/usr/sbin/eximstats of package exim.
/usr/sbin/exim-upgrade-to-r3 of package exim.
/usr/sbin/exiqsumm of package exim.
/usr/sbin/keytab-lilo of package lilo.
/usr/sbin/liloconfig of package lilo.
/usr/sbin/lilo_find_mbr of package lilo.
/usr/sbin/syslogd-listfiles of package sysklogd.
/usr/sbin/syslog-facility of package sysklogd.
/usr/sbin/update-inetd of package netbase.
So, without Perl and, unless you remake these utilities in shell script, you will probably not be able to manage any packages (so you will not be able to upgrade the system, which is not a Good Thing).
If you are determined to remove Perl from the Debian base system, and you have spare time, submit bug reports to the previous packages including (as a patch) replacements for the utilities above written in shell script.
If you wish to check out which Debian packages depend on Perl you can use
$ grep-available -s Package,Priority -F Depends perl
or
$ apt-cache rdepends perl
It is never wrong to take a look at either the debian-security-announce mailing
list, where advisories and fixes to released packages are announced by the
Debian security team, or at mailto:debian-security@lists.debian.org,
where you can participate in discussions about things related to Debian
security.
In order to receive important security update alerts, send an email to debian-security-announce-request@lists.debian.org
with the word "subscribe" in the subject line. You can also
subscribe to this moderated email list via the web page at http://www.debian.org/MailingLists/subscribe.
This mailing list has very low volume, and by subscribing to it you will be immediately alerted of security updates for the Debian distribution. This allows you to quickly download new packages with security bug fixes, which is very important in maintaining a secure system (see Execute a security update, Section 4.2 for details on how to do this).
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ next ]
Securing Debian Manual
Version: 3.13, Sun, 08 Apr 2012 02:48:09 +0000jfs@debian.org