Next Previous Contents

4. Securing services running on your system

4.1 Securing ssh

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.

4.2 Securing FTP

If you really have to use FTP (without wrapping it around a SSL tunnel), you should chroot your users into their home directory, that they are 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.

4.3 Realize the insecurity of X over network

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. This has to be disabled in /etc/ssh/ssh_config by settting 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

4.4 Check your display manager

If you only want to have a display manager installed for local usage (having a nice graphical login ie), 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.

4.5 The lpd and lprng issue

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)

4.6 Using mail securely

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 via "localhost"
  with proto IMAP port 1236
      user "ref" there with password "hackme" is alex here warnings 3600
    preconnect 'ssh -f -P -C -L -l ref 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).

4.7 Using a loghost

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.

4.8 Securing BIND

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 about this issue. There have been many recent security problems 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. 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
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.

4.9 Using snort

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.

Next Previous Contents