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 now.
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, in /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 closed-source 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.
If you really have to use FTP (without wrapping it inside a SSL tunnel), you should chroot ftp into the ftp users' home directory, so that the user is unable to see anything else than their own directory. Otherwise they could traverse your root filesystem just like if they had a shell. You can add the following line in your proftpd.conf in your global section to enable this chroot feature:
DefaultRoot ~
Restart proftpd by /etc/init.d/proftpd restart and check whether you can escape from your homedir now.
To prevent Proftp DoS attacks using ../../.., add the following line in /etc/proftpd.conf DenyFilter \*.*/
Today, X terminals are 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. This has to be enabled in /etc/ssh/ssh_config by setting X11Forwarding to yes. In times of SSH, you should drop the xhost based access control completely.
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
NOTE: This is the default behavior in Xfree 4.0.
Read more on X Window security in XWindow-User-HOWTO
(/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz).
FIXME: Add info on thread of debian-security on how to change config files of
XFree 3.3.6 to do this. This is done for XDM by setting
/etc/X11/xdm/Xservers to: :0 local /usr/bin/X11/X vt7 -dpi
100 -nolisten tcp
If you only want to have a display manager installed for local usage (having a nice graphical login, that is), make sure the XDMCP (X Display Manager Control Protocol) stuff is disabled. In XDM you can do this with this line in /etc/X11/xdm/xdm-config:
DisplayManager.requestPort: 0
Normally, all display managers are configured not to start XDMCP services per default in Debian.
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. This means you need to configure
your printer service so it will only allow connections from a set of trusted
servers. In order to do this, add the servers you want to allow printing to
your /etc/hosts.lpd.
However, even if you do this, the lpr daemon accepts incoming connections on port 515 of any interface. You should consider firewalling connections from networks/hosts which are not allowed printing (the lpr daemon cannot be limited to listen only on a given IP address).
If you are using a printer in your system, but only locally, you will not want
to share this service over a network. You can consider using other printing
systems, like the one provided by PDQ which is based on user
permissions of the /dev/lp0 device.
FIXME: Add more content (the article on Amateur Fortress Building provides
some very interesting views).
FIXME: Check if PDG is available in Debian, and if so, suggest this as the preferred printing system.
FIXME: Check if Farmer/Wietse has a replacement for printer daemon and if it's available in Debian.
If your server is not a mailing system, you do not really need to have a mail daemon listening for incoming connections, but you might want local mail delivered in order, for example, to receive mail for the root user from any alert systems you have in place.
To do this in a Debian system, you will have to remove the smtp daemon from inetd:
$ update-inetd --disable smtp
and configure the mailer daemon to only listen on the loopback interface. In
exim (the default MTA) you can do this by editing the file
/etc/exim.conf and adding the following line:
local_interfaces = "127.0.0.1"
Restart both daemons (inetd and exim) and you will have exim listening on the 127.0.0.1:25 socket only. Be careful, and first disable inetd, otherwise, exim will not start since the inetd daemon is already handling incoming connections.
If you only want local mail, this approach is better than tcp-wrapping the
mailer daemon or adding firewalling rules to limit anybody accessing it.
However, if you do need it to listen on other interfaces, you might consider
launching it from inetd and adding a tcp wrapper so incoming connections are
checked against /etc/hosts.allow and /etc/hosts.deny.
Also, you will be aware of when an unauthorized access is attempted against
your mailer daemon, if you set up proper logging for any of the methods above.
Reading/receiving mail is the most common cleartext protocol. If you use either POP3 or IMAP to get your mail, you send your cleartext password across the net, so almost anyone can read your mail from now on. Instead, use SSL (Secure Sockets Layer) to receive your mail. The other alternative is ssh, if you have a shell account on the box which acts as your POP or IMAP server. Here is a basic fetchmailrc to demonstrate this:
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 > /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).
There are different issues that can be tackled in order to secure the Domain server daemon, which are similar to the ones considered when securing any given service:
You should restrict some of the information that is server from the DNS server
to outside clients so that it cannot be used to retrieve valuable information
from your organization that you do not want to give away. This includes adding
the following options: allow-transfer, allow-query,
allow-recursive and version. You can either limit this on
the global section (so it applies to all the zones served) or on a per-zone
basis. This information is documented on the bind-doc package,
read more on this on /usr/share/doc/bind/html/index.html once the
package is installed.
Imagine that your server is connected to the Internet and to your internal
(your internal IP is 192.168.1.2) network (a basic multi-homed server), you do
not want to give any service to the Internet and you just want to enable DNS
lookups from your internal hosts. You could restrict it by including in
/etc/bind/named.conf:
options {
allow-query { 192.168.1/24; }
allow-transfer { none; }
allow-recursive { 192.168.1/24; }
listen-on { 192.168.1.2; }
forward { only; }
forwarders { A.B.C.D; }
};
The listen-on option makes the DNS bind to only the interface that has the internal address, but, even if this interface is the same as the interface that connects to the Internet (if you are using NAT, for example), queries will only be accepted if coming from your internal hosts. If the system has multiple interfaces and the listen-on is not present, only internal users could query, but, since the port would be accessible to outside attackers, they could try to crash (or exploit buffer overflow attacks) on the DNS server. You could even make it listen only on 127.0.0.1 if you are not giving DNS service for any other systems than yourself.
The version.bind record in the chaos class contains the version of the of the currently running bind process. This information is often used by automated scanners and malicious individuals who wish to determine if one's bind is vulnerable to a specific attack. By providing false or no information in the version.bind record, one limits the probability that one's server will be attacked based on its publicized version. To provide your own version, use the version directive in the following manner:
options {
... various options here ...
version "Not available.";
};
Changing the version.bind record does not provide actual protection against attacks, but it should be considered a useful safeguard.
Regarding limiting BIND's privileges you must be aware that if a non-root user
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 (/usr/share/doc/bind/README.Debian)
directory for more information about this issue. There have been many recent
security problems concerning BIND, so switching the user is useful when
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. You can do this by entering:
addgroup named
adduser --system --ingroup named named
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
Voilá! Your named now does not run as root. To achieve maximum BIND security, now build a chroot jail (see Using chroot, Section 4.15) around your daemon.
If you want to read more information on why BIND does not run as non-root user
on Debian systems, please check the Bug Tracking System regarding Bind,
specifically Bug #50013: bind
should not run as root.
Also, you can find more information regarding Bind chrooting in the Chroot-Bind-HOWTO
(regarding Bind 9) and Chroot-Bind8-HOWTO
(regarding Bind 8). This same documents should be available through the
installation of the doc-linux-text (text version) or
doc-linux-html (html version).
FIXME (jfs): I'm not sure about this, shouldn't bind files be chown'ed to the groups created? Some files might need rw permissions in order for bind to work correctly; for example: if the name server is being used as a cache the cache files need to be written on hard disk. Also, if the DNS server is secondary, it might need to transfer zones from the primary and write them on hard disk too. This should be clarified.
FIXME. Add content.
The Apache
Documentation provides information regarding security measures to be
taken on Apache webserver (this same information is provided in Debian by the
apache-doc package).
It is probably fair to say that the complexity of BIND is the reason why it has been exposed to a lot of attacks in recent years. (see Securing BIND, Section 5.7)
Other programs with complex features and a large installed user base include Sendmail and some ftp daemons (e.g. WUftpd). (Of course, a program with no features and no satisfied users can be just as insecure, besides being useless.)
Anyway, if you run any of these, consider similar arrangements for them — revoking root privileges, running in a chroot jail — or replacing them with a more secure equivalent.
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.
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 encrypted services. You should consider moving from these services to their SSL versions, ftp-ssl, telnet-ssl, pop-ssl, https ...
Most of these above listed hints apply to every Unix system (you will find them if reading any other hardening-related document related to Linux and other Unixes).
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.
If you need password sharing between machines, you might want to consider using
other alternatives. For example, you can set a LDAP server and configure PAM
on your system in order to contact the LDAP server for user authentication.
You can find a detailed setup in the LDAP-HOWTO
(/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz).
Read more on NIS security in NIS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz).
FIXME (jfs): Add info on how to setup this in Debian
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 your 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. Read more on NFS security in NFS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz).
Disabling portmap is quite simple. There are different methods. The simplest one in a Debian system is to do update-rc.d portmap remove.
This in fact removes every symlink relating to portmap in
/etc/rc${runlevel}.d/, which is something you could also do
manually. Another possibility is to 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.
After reading through all the information in the following chapters you might be wondering "I have to do quite a lot of things in order to harden my system, couldn't this things be automated?". The question is yes, but be careful with automated tools. Some people believe, that a hardening tool does not eliminate the need for good administration. So do not be fooled to think that you can automate all the process and will fix all the related issues. Security is an ever-ongoing process in which the administrator must participate and cannot just stand away and let the tools do all the work since no single tool can cope: with all the possible security policy implementations, all the attacks and all the environments.
Since woody (Debian 3.0) there are two specific packages that are useful for
security hardening. The harden which takes an approach based on
the package dependencies to quickly install valuable security packages and
remove those with flaws, configuration of the packages must be done by the
administrator. The bastille that implements a given security
policy on the local system based on previous configuration by the administrator
(the building of the configuration can be a guided process done with siple
yes/no questions).
The harden package tries to make it more easy to install and
administer hosts that need good security . This package should be used by
people that want some quick help to enhance the security of the system. To do
this it conflicts with packages with known flaws, including (but not limited
to): known security bugs (like buffer overflows), use of plaintext passwords,
lack of access control, etc. It also automatically installs some tools that
should enhance security in some way: intrusion detection tools, security
analysis tools, etc. Harden installs the following virtual packages
(i.e. no contents, just dependencies on others):
harden-tools: tools to enhance system security (integrity
checkers, intrusion detection, kernel patches...)
harden-doc: provides this same manual and other security-related
documentation packages.
harden-environment: helps configure a hardened environment
(currently empty).
harden-servers: removes servers considered insecure for some
reason.
harden-clients: removes clients considered insecure for some
reason.
harden-remoteflaws: removes packages with know security holes that
could be used by a remote attacker to compromise the system (uses versioned
Conflicts:).
harden-localflaws: removes packages with know security holes that
could be used by a local attacker to compromise the system (uses versioned
Conflicts:).
harden-remoteaudit: tools to remotely audit a system.
Be careful because if you have software you need (and which you do not wish to
uninstall for some reason) and conflicts with some of the packages above you
might not be able to fully use harden. The harden packages do not
(directly) do a thing. They do have, however, intentional package conflicts
with known non-secure packages. This way, the Debian packaging system will not
approve the installation of these packages. For example, when you try to
install a telnet daemon with harden-servers, apt will say:
# apt-get install telnetd
The following packages will be REMOVED:
harden-servers
The following NEW packages will be installed:
telnetd
Do you want to continue (Y/n)
This should set off some warnings in the administrator head, who should reconsider his actions.
Bastille Linux is an
automatic hardening tool originally oriented towards the RedHat and Mandrake
Linux distributions. However, the bastille package provided in
Debian (since woody) is patched in order to provide the same functionality for
the Debian GNU/Linux system.
Bastille can be used with different frontends (all are documented in their own manpage in the Debian package) which enables the administrator to:
InteractiveBastille(8))
BastilleChooser(8))
AutomatedBastille(8))
jfs@computer.org