Securing Debian HOWTO Alexander Reelsen v1.2 Wed, 13 Dec 2000 21:21:04 +0100 This document describes the process of securing and hardening the default Debian installation. ______________________________________________________________________ Table of Contents 1. Introduction 1.1 Disclaimer & License 1.2 Download the HOWTO 1.3 Organizational Notes/Feedback 1.4 Prior knowledge 1.5 TODO 1.6 Changelog 1.6.1 1.2 1.6.2 1.1 1.6.3 1.0 1.7 Credits 2. Before and during the installation 2.1 Choose a BIOS password 2.2 Choose an intelligent partition scheme 2.3 Set a root password 2.4 Activate shadow passwords and MD5 passwords 2.5 Run the minimum number of services required 2.6 Read the debian security mailinglists 3. After Installation 3.1 Set a LILO or GRUB password 3.2 Disallow floppy booting 3.3 Mounting partitions the right way 3.4 PAM - Pluggable Authentication Modules 3.5 The limits.conf file 3.6 Edit /etc/inetd.conf 3.7 Edit /etc/login.defs 3.8 Editing /etc/ftpusers 3.9 Using tcp wrappers 3.10 Using su 3.11 Using sudo 3.12 Using chroot 3.13 Configuring some kernel features 3.14 Do not use software depending on svgalib 3.15 Secure file transfers 3.16 Using quotas 3.17 Logfile permissions 3.18 chattr/lsattr 3.19 Your filesystem integrity 4. Securing services running on your system 4.1 Securing ssh 4.2 Realize the insecurity of X over network 4.3 The lpd and lprng issue 4.4 Using mail securely 4.5 Using a loghost 4.6 Securing BIND 4.7 Using snort 5. Before the compromise 5.1 Follow Debian security updates 5.2 Exchange software 5.3 Useful kernel patches 5.4 Genius/Paranoia Ideas, what you could do 6. After the compromise 6.1 General behavior ______________________________________________________________________ 11.. IInnttrroodduuccttiioonn One of the hardest things about writing security documents is that every case is unique. Two things you have to pay attention to are the threat environment and the security needs of the individual site, host or network. For instance, the security needs of a home user are completely different from a network in a bank. While the primary threat a home user needs to face is the script kiddie type of cracker, a bank network has to worry about directed attacks. Additionally, the bank has to protect their customer's data with arithmetic precision. In short, every user has to consider the tradeoff between usability and security/paranoia. Note that this HOWTO only covers issues relating to software. The best software in the world can't protect you if someone can physically access the machine. You can place it under your desk, or you can place it in a hardened bunker with an army in front of it. Nevertheless the desktop computer can be much more secure (from a software point of view) than a physically protected one if the desktop is configured properly and the software on the protected machine is full of security holes. Obviously, you must consider both issues. In addition this document just gives a overview of 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. If you have comments, additions or suggestions, mail them to the author and they will incorporated into this HOWTO. 11..11.. DDiissccllaaiimmeerr && LLiicceennssee This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. It is (C) 2000 by Alexander Reelsen, however it is distributed under the terms of the GNU free documentation license. 11..22.. DDoowwnnllooaadd tthhee HHOOWWTTOO You can download or view the newest version of the Securing Debian HOWTO in the following formats: +o Textonly +o HTML +o HTML, tarred & gzipped +o SGML 11..33.. OOrrggaanniizzaattiioonnaall NNootteess//FFeeeeddbbaacckk Now to the official part. At the moment I wrote most paragraphs of this HOWTO, but in my opinion this should not stay the case. I grew up and live with free software, it is part of my everyday use and I guess yours, too. I encourage everybody to send me feedback, hints additions or any other suggestions, you might have. If you think, you can maintain a certain section or paragraph better than me, then write this to me and you are welcome to do it. Especially if you find a section marked as FIXME, what means I did not have the time yet or the needed knowledge about the topic, drop me a mail immediately. The topic of this HOWTO makes is quite clear, that it is important to keep uptodate, and you can help to keep the quality of this HOWTO up, so do it. 11..44.. PPrriioorr kknnoowwlleeddggee 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 and you are a bit familiar with basic security, it will be easier to understand this HOWTO, as it is impossible to explain every little detail of a feature (otherwise this would have been a book instead of a HOWTO). 11..55.. TTOODDOO +o suidmanager/dpkg-statoverrides +o lpr and lprng +o Switching off the gnome IP things +o LKM, linux kernel modules, bad and good ones +o Encrypted filesystems 11..66.. CChhaannggeelloogg 11..66..11.. 11..22 +o Lots of grammar corrections by James Treacy, new XDM paragraph 11..66..22.. 11..11 +o Typo fixes, miscellaneous additions 11..66..33.. 11..00 +o Initial release 11..77.. CCrreeddiittss +o Robert van der Meulen with the quota paragraphas and many good ideas +o Ethan Benson corrected the PAM paragraph and had some good ideas +o All the folks who encouraged me to write this HOWTO +o The whole Debian project 22.. BBeeffoorree aanndd dduurriinngg tthhee iinnssttaallllaattiioonn 22..11.. CChhoooossee aa BBIIOOSS ppaasssswwoorrdd Before you install any operating system on your computer, set up a BIOS password and change the boot sequence to disable booting from a floppy. Otherwise a cracker only needs a bootdisk 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 last tactic is that rebooting requires human intervention which can cause problems if the machine is not easily accessible. 22..22.. CChhoooossee aann iinntteelllliiggeenntt ppaarrttiittiioonn sscchheemmee 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: +o Any partition a user has write permissions to, should be a separate partition, e.g. /home and /tmp. This reduces the risk of a user DoS by filling up your "/" mount point and rendering the system unusable. +o 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 downloaded packages (the apt cache) are stored in /var/apt/cache/archives. +o Any partition where you want to install non-distribution software. According to the File Hierarchy Standard this is /opt or /usr/local. If these are separate partitions, they will not be erased if you reinstall. 22..33.. SSeett aa rroooott ppaasssswwoorrdd Setting a good root password is the most basic requirement for having a secure system. 22..44.. AAccttiivvaattee sshhaaddooww ppaasssswwoorrddss aanndd MMDD55 ppaasssswwoorrddss 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 you want to use MD5 hashed passwords. This is generally a very good idea since it allows longer passwords and better encryption. 22..55.. RRuunn tthhee mmiinniimmuumm nnuummbbeerr ooff sseerrvviicceess rreeqquuiirreedd You should not install services on your machine, which are not needed. Every installed service introduces new, perhaps not obvious, but existent security holes to your machine. If you still want to have some services but you use these rarely, use the update-commands, e.g. 'update-inetd' for removing them from the startup process. This section needs a list of services,and what they do and the risk level involved, as newbies don't have a clue, what is considered a security risk. 22..66.. RReeaadd tthhee ddeebbiiaann sseeccuurriittyy mmaaiilliinngglliissttss It is never wrong to take a look at either the debian-security- announce mailinglist, where advisories and fixes to released packages are announced by the Debian security team or to debian- security@lists.debian.org, where you can participate about discussing debian security related things. 33.. AAfftteerr IInnssttaallllaattiioonn 33..11.. SSeett aa LLIILLOO oorr GGRRUUBB ppaasssswwoorrdd Anybody can easily get a root-shell and change your passwords by entering " 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 they want to the system. After this procedure you will not have root access to your system, as you do not know your own root password. To make sure that this can not 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. When adding a password make sure that only root can read the lilo config file, i.e. chmod 600 /etc/lilo.conf. If you use GRUB instead of LILO, edit the file /boot/grub/menu.lst and add the following two lines at the top. This will set a boot-password and also boot the default entry after waiting 3 seconds: timeout 3 password hackme 33..22.. DDiissaallllooww ffllooppppyy bboooottiinngg 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: +o Press shift at boot time, and an MBR prompt appears +o Then press F, and your system will boot from floppy disk which can be used to gain root access to the system. This behavior can be change 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 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 bootdisks as of Debian 2.2 do NOT install the mbr, but only LILO 33..33.. MMoouunnttiinngg ppaarrttiittiioonnss tthhee rriigghhtt wwaayy When mounting an ext2 partition you have several additional options you apply to the mount call or the /etc/fstab. For instance, this 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, which ignores devices. This sounds great, but it +o only applies to ext2 filesystems only +o can be circumvented easily 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, if the user does not have a clue, he will not fall into the pit of executing a trojaned binary /tmp, when he incidentally adds /tmp into his PATH. 33..44.. PPAAMM -- PPlluuggggaabbllee AAuutthheennttiiccaattiioonn MMoodduulleess PAM 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. For each application there is a configuration file in /etc/pam.d/. PAM offers you the possibility 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 PAM, 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", which returns a login failure if one module fails. The first thing to do, is to add MD5 support to PAM applications, since this helps to protect against dictionary cracks. The following two lines should be added to all files in /etc/pam.d/ that grant access to the machine, like 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, 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. 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 into the file /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. For example, you could restrict the number of concurrent logins users may have. Now edit the file /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 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 (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 to 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, which are allowed to login (or not), are stored. Imagine you only want to allow user 'ref' to login 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 per default). 33..55.. TThhee lliimmiittss..ccoonnff ffiillee You should really take a serious look into this file. Here you can define user resource limits. If you use PAM, this file is not valid and you should use /etc/security/limits.conf instead. FIXME: Get a good limits.conf up here 33..66.. EEddiitt //eettcc//iinneettdd..ccoonnff You should stop all unneeded services on your system, like echo. charges, discard, daytime, time, talk, ntalk and the HIGHLY insecure considered r-services (rsh, rlogin and rcp. 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. 33..77.. EEddiitt //eettcc//llooggiinn..ddeeffss The 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 using the terminal to log in using brute force style. 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 passwords. Pay attention to the fact, that this setting is useless if using a program other than getty, 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 yes to this variable. This will record unknown usernames if the login failed. If you do this, make sure the logs have to 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 call. MD5_CRYPT_ENAB yes As stated above, md5 sum passwords greatly reduce the problem of dictionary attacks, because it is very difficult to perform a crack against MD5 hashed passwords. At least it is hard to do successfully. 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. 33..88.. EEddiittiinngg //eettcc//ffttppuusseerrss This 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 this allow and deny users for certain services. 33..99.. UUssiinngg ttccpp wwrraappppeerrss 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 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) _B_e_w_a_r_e: The above printed example can easily be DoSed by doing lots of connections in a short period of time. Many emails mean a lot of file I/O by sending only a few packets. 33..1100.. UUssiinngg ssuu 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 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 Unixes. 33..1111.. UUssiinngg ssuuddoo sudo allows the user to execute defined commands under another users 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. 33..1122.. UUssiinngg cchhrroooott 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 (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 LDAP or MySQL instead. So your ftp-daemon needs a binary and perhaps a few libraries. A chrooted environment would be an excellent 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, many other daemons could benefit from this as well. As an additional note, the Debian default BIND (the name-service) is not shipped chrooted per default, in fact no daemons come chrooted. I hope this will change in the woody release. 33..1133.. CCoonnffiigguurriinngg ssoommee kkeerrnneell ffeeaattuurreess Many features of the kernel can be modified while running by echoing something into the /proc file system or by using sysctl. By entering sysctl -A you can see what you can configure and what the options are. Only in rare cases do you 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. Otherwise, it just does nothing. net/ipv4/icmp_echo_ignore_all = 0 If you don't want to block ICMP on your firewall, enable this. net/ipv4/tcp_syncookies = 1 This options is a double-edged sword. On the one side it protects yourself against syn flooding, on the other sites it violates RFCs. This option is quite dump as it floods the other side like it floods you, so the other side is also busy. If you want to change this option you also can change it in /etc/network/options by setting syncookies=yes. /proc/sys/net/ipv4/conf/all/log_martians = 1 Packets with impossible addresses (due to wrong routes) on your network get logged. 33..1144.. DDoo nnoott uussee ssooffttwwaarree ddeeppeennddiinngg oonn ssvvggaalliibb 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. 33..1155.. SSeeccuurree ffiillee ttrraannssffeerrss Copying files in a secure manner from a host to another can be achieved by using 'scp' which is included in the ssh package. It works like rcp but is encrypted completely, so the bad guys cannot even find out WHAT yo.. 33..1166.. UUssiinngg qquuoottaass 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: +o Keep the quotas small enough, so users do not eat up your disk space +o Keep the quotas big enough, so users do not complain or their mail quota keeps them from accepting mail over a longer period +o Use quotas on all user-writable areas, on /home as well as on /tmp. 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 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 withedquota -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. 33..1177.. LLooggffiillee ppeerrmmiissssiioonnss Some logfile permissions are not perfect after the installation. 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 the lasttime and in the faillog you see a summary of failed logins. The author recommends chmod'ing both to 660. Take a brief look over your log files and decide very carefully which logfiles you make read/writeable for a user with another UID than 0 and a group other 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. If a user gets a shell with a back door in apache, they can easily can remove the logfiles. 33..1188.. cchhaattttrr//llssaattttrr 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 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, deleted nor renamed and no link can 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. 33..1199.. YYoouurr ffiilleessyysstteemm iinntteeggrriittyy 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 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, the new version will be GPL). Installing debsums will help to check the filesystem integrity, by comparing the MD5sums of everyfile against the MD5sums used in the debian package archive. But beware, those files can easily be changed. Furthermore you can exchange your 'locate' package 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 you want to exclude. 44.. SSeeccuurriinngg sseerrvviicceess rruunnnniinngg oonn yyoouurr ssyysstteemm 44..11.. SSeeccuurriinngg sssshh If you are still running telnet instead of ssh, you should take a break from this manual and change this. Ssh should be used for all remote logins instead of telnet. In an age where it is easy to sniff internet traffic and get cleartext passwords, you should use only protocols which use cryptography. So, perform an apt-get install ssh on your system n ow. Encourage all the users on your system to use ssh instead of telnet, or even better, uninstall telnet. In addition you should avoid logging into the system using ssh as root and use alternative methods to become root instead, like su or sudo. Finally, the sshd_config file, /etc/ssh, should be modified to increase security 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 and the root password cannot be brute forced via SSH. Listen 666 Change the listen port, so the intruder cannot be completely sure whether a sshd daemon runs. PermitEmptyPasswords no Empty passwords make a mockery of system security. 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. AllowGroups and AllowUsers have equivalent directives for denying access to a machine. Not surprisingly they are called "DenyUsers" and "DenyGroups". PasswordAuthentication yes 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 commonly used SSH daemons, ssh1, ssh2 and OpenSSH by the OpenBSD people. Ssh1 was the first ssh daemon available and it is still the most commonly used (there are rumors that there is even a windows port). Ssh2 has many advantages over ssh1 except it is released under an non-opensource license. OpenSSH is completely free ssh daemon, which supports both ssh1 and ssh2. OpenSSH is the version installed on Debian when the package 'ssh' is chosen. 44..22.. RReeaalliizzee tthhee iinnsseeccuurriittyy ooff XX oovveerr nneettwwoorrkk 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, but 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 server. The best existing alternative is to use ssh to tunnel 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: Today X-Terminals are being used by more and more companies where one server is needed for a lot of workstations. This can be dangerous, because you need to allow the file server to connect to the the clients (X server from the X point of view. X switches the definition of client and server). If you follow the (very bad) suggestion of many docs, you type xhost + on your machine. This allows any X client to connect to your system. For slightly better security, you can use the command xhost +hostname instead to only allow access from specific hosts. A much more secure solution, though, is to use ssh to tunnel X and encrypt the whole session. This is done automatically when you ssh to another machine. Of course, even this can be disabled from /etc/ssh/ssh_config. For best security, if you do not need X access from other machines, is to switch off the binding on tcp port 6000 simply by typing: startx -- -nolisten tcp 44..33.. TThhee llppdd aanndd llpprrnngg iissssuuee Imagine, you arrive at work, and the printer is spitting out endless amounts of paper because someone is DoSing your line printer daemon. Nasty, isn't it? So keep your printer servers specially secure. FIXME. Content missing. (No lpr experience) 44..44.. UUssiinngg mmaaiill sseeccuurreellyy Reading/receiving mail is the most common cleartext protocol. If you use either POP3 or IMAP to get your mail you send your password cleartext across the net, so almost anyone can read your mail from now on. Instead, use SSL (Secure Socket Layer) to receive your mails. The other alternative is ssh, if you have a shell account on your box. Here is a 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 preconnect is the important 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. Another possibility would be to use fetchmail with the ssl feature. If you want to provide encrypted mail services like POP and IMAP, apt- get install stunnel and start your daemons this way: stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd This command wraps the provided daemon (-l) to the port (-d) and uses the specified ssl cert (-p). 44..55.. UUssiinngg aa lloogghhoosstt 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 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 in /etc/syslog.conf: 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 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) manpage for additional information. 44..66.. SSeeccuurriinngg BBIINNDD On a standard Debian installation, the name service daemon, BIND, runs as user root and group root. It is quite easy to run BIND under another user ID (UID). However, if another user than root runs BIND, then BIND cannot detect new interfaces automatically. For example, if you stick a PCMCIA card into your laptop. Check the README.Debian file in your named documentation directory for more information. There have been many recent security problems concerning BIND, concerning BIND, so switching the user is useful when it is possible. To run BIND under a different user, first create a separate user and group for it (it is not a good idea to use nobody or nogroup for every service not running as root). In this example, the user and group 'named' will be used. Now edit /etc/init.d/bind with your favorite 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. 44..77.. UUssiinngg ssnnoorrtt snort is a flexible packet sniffer or logger that detects attacks due to an attack signature dictionary. It detects a variety of other attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, and much more. Snort has a real-time alerting capability. This is a tool which should be installed on every router to keep an eye on your network. Just install it via apt-get install snort, follow the questions, and watch it log. 55.. BBeeffoorree tthhee ccoommpprroommiissee 55..11.. FFoollllooww DDeebbiiaann sseeccuurriittyy uuppddaatteess As soon as new security bugs are revealed 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 . 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/debian-security 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 want, you can add the deb-src lines to apt as well. See the apt manpage for further details. 55..22.. EExxcchhaannggee ssooffttwwaarree You should try to avoid any network service which sends and receives passwords in cleartext over a net like FTP/Telnet/NIS/RPC. The author recommends the use of ssh instead of telnet and ftp to everybody. Also you should not use 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 not least, disable RPC wherever possible. Many security holes for this service are known and can be easily 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 relating to portmap in /etc/rc${runlevel}.d/. You could as well chmod 644 /etc/init.d/portmap, but that gives an error message when booting. You can also strip off the "start-stop-daemon" part in /etc/init.d/portmap shell script. Keep in mind that migrating from telnet to ssh, but using other cleartext protocols 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. Most of these above listed hints apply to every Unix system. 55..33.. UUsseeffuull kkeerrnneell ppaattcchheess Some kernel patches exist, which significantly enhance system security. Here are a few of them: +o 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. Homepage: http://www.openwall.com/linux/ +o _L_I_D_S _- _L_i_n_u_x _i_n_t_r_u_s_i_o_n _d_e_t_e_c_t_i_o_n _s_y_s_t_e_m _b_y _H_u_a_g_a_n_g _X_i_e _& _P_h_i_l_i_p_p_e _B_i_o_n_d_i This patch makes the process of creating a hardened Linux system easier. You can restrict every process, give it rights to write or read files, or remove, by default, the ability to read files. Furthermore you can also set capabilities for certain processes. Even though it is still in the beta phase, it is almost a must for the paranoid system administrator. Homepage: http://www.lids.org +o _P_O_S_I_X _A_c_c_e_s_s _C_o_n_t_r_o_l _L_i_s_t_s _(_A_C_L_s_) _f_o_r _L_i_n_u_x This patch adds access control lists, an advanced method for restricting access to files, to the linux kernel. Homepage: http://acl.bestbits.at/ +o _L_i_n_u_x _t_r_u_s_t_e_e_s This patch adds a decent advanced permissions system to your Linux kernel. All the objects are stored in the kernel memory, which allows fast lookup of all permissions. Homepage: http://www.braysystems.com/linux/trustees.html +o _I_n_t_e_r_n_a_t_i_o_n_a_l _k_e_r_n_e_l _p_a_t_c_h This is a crypt-oriented kernel patch, therefore you have to pay attention to your local laws regarding the use of cryptography. It basically adds use of encrypted file systems. Homepage: http://www.kerneli.org +o _S_u_b_D_o_m_a_i_n 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. Homepage: http://www.immunix.org/subdomain.html +o _U_s_e_r_I_P_A_c_c_t This is not really a security related patch, but it allows you to create quotas for the traffic on your server per user. And you can fetch statistics about the user traffic. Homepage: http://rsmeyers.3ti.org/useripacct 55..44.. GGeenniiuuss//PPaarraannooiiaa IIddeeaass,, wwhhaatt yyoouu ccoouulldd ddoo This is probably the most unstable 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. +o 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 (why the heck did I do an OR conjunction and not AND here). +o 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. +o CD distribution This idea is very easy to realize and offers pretty security. 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 (he can, but reboot and he has to hack into your system again to change them). +o Switch module capability off When you disable the usage of kernel modules at kernel compile time many kernel based back doors are impossible to implement, since most of them are based on installing modified kernel modules. 66.. AAfftteerr tthhee ccoommpprroommiissee 66..11.. GGeenneerraall bbeehhaavviioorr If you really want to clean up residual wastes, you should remove the compromised host from your network and re-install the OS from scratch. This might not have any effect if you do not know how the intruder got root. In this case you must check everything: firewall/file integrity/loghost logf iles and so on.