Securing Debian GNU/Linux HOWTO By Alexander Reelsen, ar@rhwd.net v1.0.0, 8th April 2000 This document is about securing the default Debian installation in as many ways as possible. (THIS IS A PRE ALPHA PRE DRAFT!!!) ______________________________________________________________________ Table of Contents 1. Introduction 1.1 Knowledge required 1.2 Purpose 1.3 What this document is about 1.4 Feedback 1.5 Revision history & TODO 1.6 Copyright/Distribution 1.7 Credits 2. During installation 2.1 Choose a BIOS password 2.2 Choose an intelligent partition scheme 2.3 Choose a secure boot order 2.4 Set a root password 2.5 Activate shadow passwords 2.6 No overbloating 3. After installation 3.1 Set a LILO password 3.2 Disallow floppy booting 3.3 PAM - Pluggable authentication modules 3.4 Edit /etc/limits 3.5 Edit /etc/inetd.conf 3.6 Edit /etc/login.defs 3.7 Edit /etc/ftpusers 3.8 Using tcp wrappers 3.9 Using ssh 3.10 Using su 3.11 Using sudo 3.12 Realize the insecurity of X over network 3.13 Using chroot 3.14 Configuring some kernel features 3.15 Do not use software depending on svgalib 3.16 The lpd and lprng issue 3.17 Using mail appropiate in security context 3.18 Secure file transfers 3.19 Using a loghost 3.20 Using quotas 3.21 Audit CGI scripts 3.22 Logfile permissions 3.23 chattr/lsattr 3.24 Your file integrity 3.25 Securing BIND 4. After you have been compromised 4.1 General behaviour 5. Software, useful for making Debian more secure 5.1 Follow the debian security updates 5.2 Exchange software 5.3 Useful kernel patches 5.4 Useful other software 5.5 Genius/Paranoia Ideas, what you could do ______________________________________________________________________ 1. Introduction 1.1 Knowledge required The installation of Debian GNU/Linux is not very difficult and you should have been able to install it. If you already have some knowledge about Linux or other Unices, it will be easier to understand this HOWTO. 1.2 Purpose The purpose of this HOWTO is to increase the security of your current Debian GNU/Linux Installation. It is impossible to reach an absolute security, but you can at least increase it. Especially today, security is becoming a very important topic. Some people, called crackers, are trying to attack firewalls, routers or other machines on the internet, which includes even workstations behind dialup connections. What will happen if somebody has stolen important data from your employer? What if somebody breaks into your servers and destroys all data on them? Even on a LAN, where you know all of your colleagues you cannot be sure, that this will not happen. 1.3 What this document is about One of the hardest things about writing security documents is that every case is unique. Two things you have to be concerned about are the threat environment and the security needs of the individual site/machine. For instance, the security needs of a home user are completely different from a network in a bank. While the primary threat of the home user is mainly the script kiddie type of cracker, the bank network must worry about directed attacks. And the bank has to protect their customer's data with arithmetic precision. In short, every user has to weigh himself between usability and security/paranoia. As a very important note I am going to tell you now, that this HOWTO only covers software topics. It is completely your problem how you physically secure your computer. You can place it under your workdesk, or you can place it in a nuclearproofed bunker with an army in front of it. Nevertheless the workdesk computer can be much more secure (from the software point of view) than the other one. As this HOWTO is only covering the software side you also should think about the other side. In addition this document just gives a brief overview what you can do to increase the security of your Debian GNU/Linux installation. Many parts of this HOWTO can be transferred to other distributions as well. 1.4 Feedback I am always glad to hear some feedback about this document. Of course it is not perfect (though you are allowed to write me this), but I hope it can help you a little. Proposals for improvements in this document are always welcome. As new software appears every day, this HOWTO may not be state-of-the-art at the time you read it. If it should be hopelessy out of date, I will give over this HOWTO to someone who is willing to keep it up to date. Maybe you? 1.5 Revision history & TODO V1.0 Initial Version TODO: - suidmanager - nosuid mount flag - lpr and lprng - Switching off the gnome IP things - LKM, linux kernel modules 1.6 Copyright/Distribution This document is Copyright (c) 2000 by Alexander Reelsen. However, you are allowed and encouraged to redistribute it in any form without permission of the author. I would be happy if you inform me when you are planning to translate this document. If you take excerpts from this document be so kind and place a pointer to the full document. Thanks. In short, this is from the community for the community. 1.7 Credits - Robert van der Meulen with the quota paragraphas and many good ideas - Ethan Benson corrected the PAM paragraph and had some good ideas - People who encouraged me to write this HOWTO - The Debian project of course :) 2. Before/During Installation 2.1 Choose a BIOS password Before you install any operating system on your computer, setting up a BIOS password is essential to ensure basic security as well as changing your boot sequence to disable floppy booting. Otherwise the cracker just needs to bring a bootdisk with him. Disable booting without a password would be the best, if noone should touch that system. This can be very effective if you run a server, because usually it does not get rebooted often. 2.2 Choose an intelligent partition scheme An intelligent partition scheme depends on the operational area of the machine. Rule of thumb is to be fairly liberal with your partitions and to pay attention to the following factors. 1. Any partition a user has write permissions to, should be a seperate partition, e.g. /home and /tmp. This reduces the risk of a user DoS by filling up your "/" mount point. 2. Any partition which can fluctuate, e.g. /var (especially /var/log). In Debian context you should create /var a little bit bigger than normal because the downloaded packages aka the apt cache is stored in /var/apt/cache/archives. 3. Any partition where you want to install non-distribution software. According to the file hierarchy standard now preferrably /opt or /usr/local. If you keep this seperate partitions, you do not need to remove them, even if you reinstall. 2.3 Choose a secure boot order As already mentioned above you should set a secure boot order, that noone is able to penetrate your system with a bootdisk, what basically means to choose the harddisk to boot from. CDROM booting should be disabled as well. 2.4 Set a root password Setting a good root password is a basic requirement for having a secure system. 2.5 Activate shadow passwords After the installation, you will be asked if the shadow passwords should be enabled. You should say yes to this question, because then the passwords will be kept in the file /etc/shadow. And only the user root and the group shadow will have read access to this file. So any user will not be able to grab a copy of this file and run a password cracker against it. Optionally, you can switch from shadow passwords and normal passwords by using 'shadowconfig' (what normally should not be necessary). 2.6 No overbloating You should not install services on your machine, which are not needed. Every installed service introduces new, perhaps not obvious, but existant security holes to your machine. If you still want to have some services but you use these rarely, use the update-commands, eg 'update-inetd' for removing them from the startup process. 3. After Installation 3.1 Set a LILO or GRUB password Anybody can easily get a root-shell and change your passwords by entering " init=/bin/sh". After changing the passwords and rebooting the system, the person has unlimited root-access to it and can do anything with it, which includes changing sensitive data. After this procedure you will not have access to your system anymore, as you do not know the passwords. To make sure that this will not happen, you should set password even for that. You can choose between a global password or a password for a certain image. For LILO you need to follow this steps. You need edit the file /etc/lilo.conf. Add this line to your lilo.conf and rerun lilo: image=/boot/2.2.14-vmlinuz label=Linux read-only password=hackme restricted If you leave out the "restricted" above, you will always be prompted to enter a password, regardless if you passed parameters to LILO. Well, when adding a password you should make sure, that only root can read the lilo config file, so make proper permission changes. If you use GRUB instead of LILO, edit the file /boot/grub/menu.lst and add the following to lines at the top of it. This will set a boot-password and also boot the default entry after waiting 3 seconds: timeout 3 password hackme 3.2 Disallow floppy booting This paragraph refers to a BIG flamewar in the debian-devel mailing list (I think I will get flamed as well because I described something wrong :)). But back to the topic. The default MBR in Debian GNU/Linux does not act as an usual master boot record. Here is the way howto get into your system, even if you changed the BIOS boot sequence AND gave LILO a password: - Press shift at boot time, and Debian's MBR will give you a prompt - Then press F, and your system will boot from floppy disk, and you will get full root access to the hard disk Make yourself clear, that this is a DEFAULT master boot record of debian, so you really should change this, simply by entering: lilo -b /dev/hda Now LILO is put into the MBR. This goal can also be achieved by writing "boot=/dev/hda" into lilo.conf But there is as well another solution where you can disable mbr prompt at all: install-mbr -i n On the other hand, this "backdoor", of which many people are just not aware, may save your skin as well if you run into deep trouble with your installation out of whatever reasons. INFO: The current bootdisks do NOT install the mbr, but only LILO by default, so you do not have any hassle anymore. 3.3 PAM - Pluggable Authentication Modules PAM is an abbrevation for Pluggable Authentication Modules. PAM is useful for a kind of "dynamical configuration of authentication". If you want to use PAM, you should make sure, that the application uses PAM. Most of the applications that are shipped with Debian 2.2 have this support compiled in. Note, that PAM did not exist in earlier Debian versions than potato For each application there is a seperate configuration file in /etc/pam.d/. PAM offers you the possibiblity to go through several authentication steps once, without the user's knowledge. You could authenticate against a berkeley database and the passwd and the user only logs in if he authenticates correct twice. You can restrict a lot with, as well as you can open your system doors very wide. So be careful. A typical configuration line has a control field as its third element. Generally it should be set to "requisite", what returns a login failure, if one module fails. (However, if you know what you do, you can play around a lot). The first thing I like to do, is to add MD5 support to my PAM applications, since this protects you against dictionary cracks a little bit more. These two lines should be in all the files like 'login' or 'ssh' in /etc/pam.d/. password required pam_cracklib.so retry=3 minlen=12 difok=3 password required pam_unix.so use_authtok nullok md5 So, what does this myth do? The first line loads the cracklib PAM module, which provides password-strength checking and prompt for a new password with 3 retries, a minimum length of 12 characters and a difference of at least 3 characters to the old password. The second line introducs the standard authentication module with md5 passwords and a zero password is ok. The use_authtok directive is necessary to hand over the password from the module before. To make sure, that the user root can only log into the system from some local Terminals, the following line should be enabled in /etc/pam.d/login. Then you should add the Terminals from which the user root can log into the system into the file /etc/securetty: auth requisite pam_securetty.so And last but not least the following line should be enabled if you want to set up some user limits. This allows the users only to use certain resources of the system, as for example a maximum number of logins. session required pam_limits.so Now edit the file /etc/pam.d/passwd and change the first line. You should add the option "md5" to use md5 passwords and change the minimum lenght of password from 4 to 6 and set a maximum length if you desire. Then the line should look like this one: password required pam_unix.so nullok obscure min=6 max=11 md5 If we want to protect su, so that only some people can use it to become root on your system, we need to add a new group "wheel" to your system (at least that is the cleaner way, since no file has such a group permission yet). Add root and the other users that should be able to "su" to the user root to this group. Then create the following line in /etc/pam.d/su: auth requisite pam_wheel.so group=wheel debug This makes sure that only people from the group wheel can use to su to become root. Other users will not be able to become root. In fact they will get a denied message if they enter su. And edit /etc/pam.d/other and add the following lines: auth required pam_securetty.so auth required pam_unix_auth.so auth required pam_warn.so auth required pam_deny.so account required pam_unix_acct.so account required pam_warn.so account required pam_deny.so password required pam_unix_passwd.so password required pam_warn.so password required pam_deny.so session required pam_unix_session.so sesion required pam_warn.so session required pam_deny.so This lines will provide with a good default configuration for all applications that support PAM. 3.4 Edit /etc/limits You should really take a serious look into this file. Here you can define the user resource limits. If you use PAM, this file is invalid. Use /etc/security/limits.conf instead. 3.5 Edit /etc/inetd.conf You should stop all services on your system, like echo. charges, discard, daytime, time, talk, ntalk and the HIGHLY insecure considered r-services. After disabling those, you again should check if you really need the inetd daemon. Some persons, including the author, prefer to use daemons instead of calling them via inetd, because in past some Denial of Service attacked against inetd were found, which increases the machine's load rapidly. If you still want to run some kind of inetd service, use a more configurable inet daemon like xinetd or rlinetd. 3.6 Edit /etc/login.defs The next step is to edit the definitions for the login. FAIL_DELAY 10 This variable should be set to a higher value to make it harder using the terminal to log in. If a wrong password is typed in, he has to wait for 10 seconds to get a new login prompt, what is quite time consuming when you test password. Pay attention to the fact, that this setting is useless if using another program than getty, mingetty for example. FAILLOG_ENAB yes If you enable this variable, failed logins will be logged. It is important to know them to see if someone tries a brute force attack to get login information. LOG_UNKFAIL_ENAB yes If you set yes to the variable "FAILLOG_ENAB", then you should also set yes to the variable "LOG_UNKFAIL_ENAB". This will record unkown usernames if the login failed. If you do this, make sure, the logs are set to the right permissions (640 I prefer, with appropriate group settings like adm group), because if a user incidentally enters his password as username, it gets logged and could be read by any other user. SYSLOG_SU_ENAB yes This one enables logging 'su' tries to syslog. Quite important on serious machines, but note that this can vulnerate privacy issues as well. SYSLOG_SG_ENAB yes And to see if someone change the group before executing a command, you should set this variable to yes. MD5_CRYPT_ENAB yes As stated above, md5 sum passwords greatly reduce the problem of dictionary attacks, because it is really complicate to perform a crack against MD5 hashed passwords, at least it is hard to perform a successful crack. But before enable this option, READ the docs about MD5. This option only applies to slink users, otherwise you set this in PAM. PASS_MAX_LEN 50 If you activated as suggested above md5 passwords in your PAM configuration, then you should set this variable to the same value as you used in your PAM configuration. 3.7 Editing /etc/ftpusers This file contains a list of users, who are not allowed to log into this host using ftp. Use this file, if you really want to allow ftp (which is not recommended by the author, because it uses cleartext passwords.) 3.8 Using tcp wrappers TCP wrappers have been implemented, when there was no packet filter available and you needed a sort of access control. The TCP wrappers allow you to allow or deny a service for a host or a domain and define a default allow or deny rule. This should fit the needs of most people. If you want more informations look into the manpage hosts_access(5). Now, here comes a small trick and probably the smallest intrusion detection system available. In general you should have a decent firewall policy as a first line and tcp wrappers as the second line of defense. One little trick is to set up a spawn command in /etc/hosts.deny that sends mail to root whenever a denied service triggers wrappers: ALL: ALL: spawn ( \ echo -e "\n\ TCP Wrappers\: Connection refused\n\ By\: $(uname -n)\n\ Process\: %d (pid %p)\n\ User\: %u\n\ Host\: %c\n\ Date\: $(date)\n\ " | /bin/mail -s "Connection to %d blocked" root) 3.9 Using ssh If you are still running telnet and not ssh, you should stop reading this manual now and change this. You should not use the telnet for remote logins and instead use ssh. Especially today, where it is easy to sniff traffic in the internet and get cleartext passwords, you should use a secure way which is based on cryptography. Encourage all the other users on your system to use ssh instead of telnet. Also you should try to avoid logging into the system using ssh as root, and use alternative methods to become root instead, like su or sudo. The sshd_config file (placed in /etc/ssh) should be corrected a little bit as well. PermitRootLogin No Try not to permit Root Login wherever possible. If anyone wants to become root via ssh, now two logins are needed. Listen 666 Change the listen port, so the intruder cannot be completely sure that a sshd daemon runs. PermitEmptyPasswords no Empty passwords are as ugly as hell out of the security view. AllowUsers alex ref Allow only certain users to have access via ssh to this machine. AllowGroups wheel admin Allow only certain group members to have access via ssh to this machine. Both, AllowGroups and AllowUsers have equivalent directives for denying access to a machine. Suprisingly they were called "DenyUsers" and "DenyGroups". PasswordAuthentication yes Here it is completely your choice what you want to do. It is more secure only to allow access to machine from users with ssh-keys placed in the ~/.ssh/authorized_keys file. If you want so, set this one to "no". As a final note be aware, that these directives are from a OpenSSH configuration file. Right now, there are three types of common used SSH daemons, ssh1, ssh2 and OpenSSH by the OpenBSD people (hey, quite a cool logo, I still need to buy a t-shirt). ssh1 was the first ssh daemon available and it is the one, which is mainly used right now (I heard rumors it even exists an windows port). ssh2 has many advantages over ssh1 (that is why they called '2' I guess) except the bad non-opensource license, what kicks this daemon for Debian. OpenSSH is completely free ssh daemon, which is based on an old free ssh1, but then many improvements and extensions were made and the most important thing, the non-free code was removed, so that this is Debian's No. 1 choice right now. 3.10 Using su If you really need to become the super user on your system, eg for installing packages or adding users, you can use the command su to change your identity. You should try to avoid any login as user root and instead use the command su. The best solution is to remove su and switch to sudo in the author's opinion. 3.11 Using sudo sudo allows the user to execute commands under another users identity, even as root. If the user is added in /etc/sudoers and authenticate himself with his password, he is able to run commands, which have been defined in /etc/sudoers, as user root. 3.12 Realize the insecurity of X over network Today X-Terminals becoming more and more interesting for companies, where one server is needed for a lot of workstations. But this is dangerous, because you need to allow the server to connect to the the other X server (it is a client, because X switches the definitions of client and server). If you follow the suggestion from many docs, you do a "xhost +". This allows every X client to connect to your system. So it is recommend to use the command "xhost +hostname" instead for certain hosts, that should be able to connect to your X serer. Or directly use ssh with X and encrypt the whole session. In addition, if you do not need X over the wires, then you can switch off the binding on tcp port 6000 simply by typing: startx -- -nolisten tcp 3.13 Using chroot chroot is one of the most powerful possibilities to restrict a daemon or a user or another service. Just imagine a jail around your target, where the target cannot escape from (except you are root, but that creates other security issues). If you do not trust a user, you can create a changed root enviroment for him (if you have enough free space, because you need to copy the libraries as well or compile everything statically, both eats up some space, but security is not without any cutback). If now the user does something malicious, he will not be very harmful anymore. A good example for this case is, that you do not authenticate against /etc/passwd but LDAP or MySQL instead. So your ftp-daemon needs a binary and perhaps a few libraries. So a chrooted environment would be an execellent security improvement, if a new exploit is known for this ftp-daemon. It is then only possible to exploit the UID of the ftp-daemon-user and nothing else. Of course, this complies with lots of other daemons as well. As an additional note, the Debian default BIND (the name-service) is not shipped chrooted per default, in fact no daemons comes chrooted. 3.14 Configuring some kernel features ## FIXME - Content missing ## You can configure a lot of kernel settings during runtime by echo'ing something into the procfile system or by using sysctl. By entering 'sysctl -A' you can see what you can configure and how it is configured right now. Only in rare cases you really need to edit something here, but you can increase security that way as well. net/ipv4/icmp_echo_ignore_broadcasts = 0 This is a 'windows emulator', because it acts like windows on broadcast ping, if this one is set to 1. It just does nothing. net/ipv4/icmp_echo_ignore_all = 0 If you don't want to block ICMP on your firewall, just enable this. 3.15 Do not use software depending on svgalib SVGAlib is very nice for console lovers like me, but in the past it has been proven several times, that it is very insecure. Exploits against zgv were released, and it was simple to become root. Try to prevent using SVGAlib programs whereever possible. 3.16 The lpd and lprng issue Imagine, you are coming to work, and the printer spits out endless amounts of paper, because someone is DoS'ing your line printer daemon. Nasty, isn't it? So, keep your printer servers specially secure. ### FIXME. Content missing. (No lpr experience) ### 3.17 Using mail appropiate in security context Reading/receiving mail is the most common cleartext protocol. If you either use POP3 or IMAP to get your mail you send your password cleartext across the wires, so almost everyone can read your mails from now on. So use SSL (Secure Socket Layer) to receive your mails. The other alternative is ssh, if you have a shell account on your box. Look at this basic fetchmailrc: poll my-imap-mailserver.org via "localhost" with proto IMAP port 1236 user "ref" there with password "hackme" is alex here warnings 3600 folders .Mail/debian preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref my-imap-mailserver.org sleep 15 /dev/null' The important line is the preconnect line. It fires up a ssh session and creates the necessary tunnel, which automatically forwards connections to localhost port 1236 to the imap mail server, but encrypted now. 3.18 Secure file transfers Copying files in a secure manner from a host to another can be achieved by using 'scp' which is included in the ssh packages. It works like rcp but is encrypted completely, so the bad guys cannot even find out WHAT you copy, what is not bad in some situations. 3.19 Using a loghost A loghost is a host which collects the syslog data remote over the network. If one of your machines is cracked the intruder is not able to blur his spoors, except he hacks that loghost as well. So, spend your loghost an extra amount of paranoia. Making your machine a loghost is really simple. Just start the syslogd with 'syslogd -r' and a new loghost is born. Now you have to configure your other machines to send the data to the loghost. Add an entry like this one: facility.level @your_loghost facility should be one of authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp and local1 up to local7. level should be alert, crit, err, warning, notice, info debug. If you want to log everything remote, just write: *.* @your_loghost into your syslog.conf. Logging remote as well as local would be the best solution (the attacker could presume not to be found after deletion of local log files, an often used method to mask an intrusion). See the syslog(3), syslogd(8) and syslog.conf(5) manpage for some additional information. 3.20 Using quotas Having a good quota policy is important, as it keeps your users from filling up your disk(s). You can use two different quota systems - user quota and group quota. As you probably figured out, user quota limits the amount of space a user can take up, group quota does the equivalent for groups. Keep this in mind when you're working out quota sizes. There are a few important points to think about in setting up a quota system: - Keep the quotas small enough, so users do not eat up your disk space - Keep the quotas big enough, so users do not complain or their mail quota keeps them from accepting mail over a longer period - Use quotas on all user-writable areas, on /home as well as on /tmp to restrict the user as good as possible. Every partition/directory users have full write access should be quota enabled. So find out those partitions and directories and calculate a valuable quota size, which concatenates usability and security. So, now you want to use quotas. First of all you need to check whether you enabled quota support in your kernel. If not, you will need to recompile it. After this, control whether the package 'quota' is installed. If not you will need this one as well. Enabling quota for the respective filesystems is as easy as modifying the 'defaults' setting to 'defaults,usrquota' in your /etc/fstab file. If you need group quota, substitute 'usrquota' to 'grpquota'. You can also use them both. Then create empty quota.user and quota.group files in the roots of the filesystems you want to use quotas on (e.g. 'touch /home/quota.user', 'touch /home/quota.group' for a /home filesystem). Restart quota by doing '/etc/init.d/quota stop;/etc/init.d/quota start'. Now quota should be running, and quota sizes can be set. Editing quotas for a specific user (say 'ref') can be done by 'edquota -u ref'. Group quotas can be modified with edquota -g . Then set the soft and hard quota and/or inode quotas as needed. For more information about quotas, read the quota man page, and the quota mini-howto. 3.21 Audit CGI scripts If you do not trust your users (what you generally should not, this is a hard world), take a closer look at their scripts they run, especially CGI scripts, since those can be accessed by nearly everyone. You only need to know the right URL and you have some kind of shell running as the uid of the webserver. Think twice, whether you want to allow CGI script execution for your users. ### FIXME - security webserver stuff, config examples ### 3.22 Logfile permissions Some logfile permissions are not perfect after the installation. First /var/log/lastlog and /var/log/faillog need not to be readable for the normal users. In the lastlog file you can see the who logged in the lasttime and in the faillog you see a summary of the failed logins. The author recommends chmod'ing both to 660 both files. Take a brief log over your logfiles and decide very carefully which logfiles you make read/writeable for a user with another UID than 0 and a group other named than 'adm' or 'root'. I want to emphasize that the apache logfile permissions are really screwed due to the fact, that the apache user owns the apache log files. When you get a shell as such user with a apache backdoor, you easily can remove the logfiles and blur your spoors. 3.23 chattr/lsattr These two commands are very useful, but they only work for the ext2 filesystem. With 'lsattr' you can list the attributes of a file and with 'chattr' you can change them. Note that attributes do not equal to permissions. In fact, they are completely different. Here are only listed the most important attributes for increasing your security listed, but there are other as well. There are two flags which can only be set by the superuser. Those are tho most important ones. First there is the 'a' flag. If set on a file, this file can only be opened for appending. This attribute is useful for some of the files in /var/log/, though you should consider they get moved sometimes due to the log rotation scripts. The second flag is the 'i' flag, short for immutable. If set on a file, this file can neither be modified nor deleted nor renamed and no link be created to this file. If you do not want you users to look into your config files you could set this flag and remove readability. Furthermore it might give you a little bit security against intruders, because the cracker might confused of not being able to remove a file. Although you should never assume that the cracker is blind, he got into your system, so he defeated your security policy. 3.24 Your file integrity Are you sure /bin/login on your harddrive is still the binary you installed there some months ago? What if it is a hacked version, which stores the entered password in a hidden file or mails it in cleartext version all over the internet? The only method to have some kind of protection is to check your files every day/hour/month (I prefer daily) by comparing the actual and the old md5sum of this file. Two files cannot have the same md5sum, so you're on the secure site here, except someone hacked the algorithm to create md5sums on that machine, what is, well sticky. You really should consider this auditing of your binaries as very important, since it is an easy way to recognize changes at your binaries. Common tools used for this are sXid, AIDE (Advanced Intrusion Detection Environment) and TripWire (non-free). Furthermore you can exchange your locate package with 'slocate' tool. slocate is a security enhanced version of the GNU locate. When performing a locate, the user only sees the files he really has access to. In addition you can exclude any files or directoriey you want to exclude. 3.25 Securing BIND On a standard Debian installation, the name service daemon, BIND, runs as user root and group root. It is possible and quite easy to achieve to run BIND under another's UID. However, running BIND not as root prevents it from detecting and using interfaces automatically, for example if you stick a PCMCIA card into your laptop (anyway, I don't think BIND runs on a laptop per default). Check the README.Debian file in your named documentation directory for more. Anyway, noone can deny the existing security problems, which occured in the last months concerning BIND, so switchting the user is useful where it is possible. First you should create a seperate user and group for it (don't use either nobody or nogroup for every service not running as root or another user). In this case I will use user and group 'named'. Now edit /etc/init.d/bind with your favourite editor and change the line beginning with 'start-stop-daemon --start' to start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named All you need to do now is to restart bind via '/etc/init.d/bind restart', and then check your syslog for two entries like this: Sep 4 15:11:08 nexus named[13439]: group = named Sep 4 15:11:08 nexus named[13439]: user = named Voila! Your named now does not run as root. To achieve maximum BIND security, now build a chroot jail (See 3.13) around your daemon. ### FIXME - Add chrooting bind help with /var/chroot ### 4. After you have been compromised 4.1 General behaviour If you really want to clean up residual wastes, you should remove the compromised host out of your network and install a new OS from scratch on. This might not take any effect if you do not know how the intruder got root. So just check everything, firewall/file integration/loghost logfiles and so on. 5. Exchange other software 5.1 Follow the debian security updates As soon as new security bugs are revealed in packages, debian maintainers and upstream authors try to patch them within days or even hours. After the bug is fixed, a new package is provided on http://security.debian.org Put the following line in your sources.list and you will get the security updates as well. deb http://security.debian.org/debian-security potato/updates main contrib non-free And for most people (unless you live in a country which prohibits importing or using strong cryptography) this one as well: deb http://security.debian.org/debian-non-US potato/non-US main contrib non-free If you want, you can add the deb-src lines to apt as well, see the manpage for further details. 5.2 Exchange software FTP/Telnet/NIS/RPC: You should try to avoid every network service which sends and receives passwords in cleartext over a net. The author recommends the use of ssh instead of telnet and ftp to everybody. Also you should stop using NIS -the network information service- , if it is possible, because it allows password sharing. This can be highly insecure, if your setup is broken. Last, but of sure not least, disable RPC whereever possible. Lots of security holes are known and can be exploited. On the other hand NFS services are quite important in some networks, so find a balance of security and usability in a network. Most of the DDOS (distributed denial of service) attacks use rpc exploits to get into the system and act as a so called agent/handler. Disabling portmap is quite simple. There are different methods. The simplest one is to remove every symlink in /etc/rc${runlevel}.d/ (I mean you should only remove the portmap symlinks, not the others!). You could as well chmod 644 /etc/init.d/portmap, but that gives you an error message. Or you could strip of the "start-stop-daemon" part in the init.d shell script. Follow the perl motto... Keep in mind, that migrating from telnet to ssh, but using any other cleartext protocol does not increase your security in ANY way! Best would be to remove ftp, telnet, pop, imap, http and to supersede them with their respective crypted services. Of course all these above listed hints apply to every Unix system. 5.3 Useful kernel patches There do exist some kernel patches, which significant enhance the system security. Here are the one I know: - OpenWall patch by Solar Designer This is a useful set of kernel restrictions, like restricted links, FIFOs in /tmp, restricted /proc, special file descriptor handling, non-executable user stack area and some more. Available under: http://www.openwall.com/linux/ - LIDS - Linux intrusion detection patch by Huagang Xie & Philippe Biondi This patch should make the process of intrusion detection into a Linux system easier. It has a lot of features but is still considered beta. It supports protection of ioports, disallows accessing the raw disk, protection of whole files, so they cannot be changed even from root, bsd-alike append only mode for files and some more. Available under: http://lids.org - POSIX Access Control Lists (ACLs) for Linux This patch adds some kind of access control lists, an advanced access method to files, to the linux kernel. Available under: http://acl.bestbits.at/ - Linux trustees This patch adds a decent advanced permissions system to your Linux kernel. All the objects are stored in the kernel memory, what allows a real quick lookup of all these permissions. Available under: http://www.braysystems.com/linux/trustees.html - International kernel patch This is a crypt-orientated kernel patch, therefore you have to pay attention to your local crypt policy. It basically adds use of encrypted file systems. Available under: http://www.kerneli.org - SubDomain A kernel extension to create a more secure and easier to setup chroot environment. You can specify the files needed for the chrooted service manually and do not have to compile the services statically. (Not yet completed at the time of writing this). Available under: http://www.immunix.org 5.4 Useful other software First of it all, use a firewall. Use a firewall you are able to administer and to control. Then, use log analysis tools. Here are some tools (not only log analysis), of which some are included in Debian GNU/Linux potato, others not. The one which are included are prepended with a '+': + Nessus + sxid + syslog-ng + ippl + makepasswd + pwgen + logcheck + snort + nmap + cheops + ethereal + karpski + ntop + gnupg/pgp + lsof + ngrep + satan + LASG + gfcc + arpwatch - saint - sinus firewall - portsentry - john the ripper - crack 5.0 - sentinel 5.5 Genius/Paranoia Ideas, what you could do This is probably the most fluctuent and funny section, since I hope that some of the "duh. that sounds crazy"-ideas might be realized. Following here you will find some - well, it depends on the point of view whether you say they are genius, paranoid, crazy or secure - ideas to increase your security rapidly but you will not come unscathed out of it. - Playing around with PAM As said in the phrack 56 PAM article the nice thing with PAM is that "You are limited only by what you can think of.". It is true. Imagine root login only possible with fingerprint or eyescan or cryptocard (hm, why did I do an OR conjunction and not AND here). - Fascist Logging I would say everything we talked about logging above is "soft logging". If you want to perform real logging, get a printer with fanfold paper and log everything hard by printing on it. Sounds funny, but it's reliable and it cannot be removed. - CD distribution This idea is very easy to realize but the hell secure. Create a hardened debian distribution, a damned good firewall, make an ISO of it and burn it on CD. Make it bootable. Upshot of all this is a ro whole distribution with about 600 MB space for services and the fact to make it impossible for intruders to get read write access on this system. Just make sure every data which should get written, gets written over the wires. Anyway, the intruder cannot change firewall rules, routing entries or start own daemons. - Switch module capability off When you disable the usage of kernel modules at kernel compile time, many kernel based backdoors are impossible to implement, since most of them are based on kernel modules.