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, cdrom 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 without a password 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 there also exist applications 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 the 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:
/home and /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)
/var (especially
/var/log) should also be on a separate partition. On a Debian
system, you should create /var a little bit bigger than normal,
because downloaded packages (the apt cache) are stored in
/var/cache/apt/archives.
/opt or /usr/local. If these are separate
partitions, they will not be erased if you (have to) reinstall Debian itself.
In the case of 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 in a separate partition, this situation will not render the system
unusable. Otherwise (if the spool directory is in the same place partition as
/var) the system might have important problems: log entries will
not be created, packages can not 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 filesystem you want to use. The default filesystem selected in the Debian installation for Linux partitions is ext2. However, it is recommended you swith to the a journaling filesystem, such as ext3, reiserfs, jfs or xfs, to minimize the problems derived from a system crash in the following cases:
Leaving aside the performance issues regarding journaling filesystems (since this sometimes can turn into a religious war), it is usually better to use the ext3 filesystem. The reason for this is that it is backwards compatible with ext2, so if there are any issues with the journaling you can disable it and still have a working filesystem. Also, if you need to recover the system with a bootdisk (or CDROM) you do not use a custom kernel. If the kernel in it is 2.4 ext3 support is already available, if it is a 2.2 kernel you will be able to boot the filesystem even if you lose journaling capabilities. If you are using other journaling filesystems you will find that you might not be able to recover unless you have a 2.4 kernel with the needed modules compiled built-in. Also, if you are stuck with a 2.2 kernel in the rescue disk it might even be more difficult to have it access reiserfs or xfs.
In any case, ext3 might cause less data loss since it does
file-data journaling whileas others do only meta-data journaling, see http://lwn.net/2001/0802/a/ext3-modes.php3.
The system you are going to install should not be immediately connected to the Internet during installation. This could sound stupid but is usually done. 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 new 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, it could even be compromised before you even finished 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 and using a
local packages mirror from both the Debian package sources and the security
updates. You can setup package mirrors by using another system connected to
the Internet and Debian-specific (if it's a Debian system) tools 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
setup 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.
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.
Furthermore you are queried during installation whether you want to use MD5
hashed passwords. This is generally a very good idea since it allows longer
passwords and better encryption.
Read more on Shadow passwords in Shadow
Password
(/usr/share/doc/HOWTO/en-txt/Shadow-Password.txt.gz).
Services are programmes 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 are hence 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 footprint of running services is quite low and it's even lower when talking about services offered in the network. The footprint in Debian 2.1 wasn't as tight as in Debian 2.2 (some inetd services were enabled by default) and in Debian 2.2 the rpc portmapper is enabled upon installation. Rpc is installed by default because it is needed for many services, for example NFS, to run on a given system. It can be easily removed, however, see Disabling daemon services, Section 3.6.1 on how to disable it.
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 still want to have some services but you use these rarely, use the update-commands, e.g. 'update-inetd' and 'update-rc.d' for removing them from the startup process.
Disabling a daemon service is quite simple. There are different methods:
/etc/rc${runlevel}.d/ or rename the links (so
that they do not begin with 'S')
/etc/init.d/_service_name_) to another name
(for example /etc/init.d/OFF._service_name_)
/etc/init.d/_service_name_ file.
/etc/init.d/_service_name_ script to have it stop
immediately.
You can remove the links from /etc/rc${runlevel}.d/ 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 stop XX 2 3 4 5 .
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
this 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 rcconf to do
all this changes easily (rcconf works both for file-rc and normal
System V runlevels).
Other (not recommended) methods of disabling services are: chmod 644
/etc/init.d/daemon (but that gives an error message when booting), or
modifying the /etc/init.d/daemon script (by adding an exit
0 line at the beginning or commenting out the
start-stop-daemon part in it). Since init.d files are
configfiles, they will not get overwritten upon upgrade.
Unfortunately, unlike other (UNIX) operating systems, services in Debian cannot
be disabled by modifying files in /etc/default/_servicename_.
FIXME: Add more information on handling daemons using file-rc
You should stop all unneeded 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). After disabling those, you should check if you really need the inetd daemon. Many people prefer to use daemons instead of calling services via inetd. Denial of Service possibilities exist against inetd, which can increase the machine's load tremendously. If you still want to run some kind of inetd service, switch to a more configurable inet daemon like xinetd or rlinetd.
You can disable services by editing /etc/inetd.conf directly, but
Debian provides a better alternative to do this: 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 some undocumented feature on
inetd. . Or use an alternate inetd daemon like xinetd.
Debian comes with a lot of software, for example the Debian 3.0 woody release includes almost 6 CD-ROMs of software and thousands of packages. With so many software, and even if the base system installation is quite reduced [1] you might get carried away and install more than it 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 unnecesary 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 a 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:
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 unnecesary 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 in a production system tools that could be used to remotely attack systems (see Remote vulnerability assesment tools, Section 8.1) you can expect an intruder to use them too if available.
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, you
just have to consider you will not be able to run any perl aplication in the
system and you will also have to fool the package management system to think
that the perl-base is installed even if it's not. [3]
Which utilities use perl? You can see it for yourself doing:
$ for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/*; do [ -f $i ] && {
type=`file $i | grep -il perl`; [ -n "$type" ] && echo $i; }; done
These includes 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.
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 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.8 for details on how to do this.)
Securing Debian Manual
2.5 (beta) 29 augusti 2002Sat, 17 Aug 2002 12:23:36 +0200jfs@computer.org