next up previous contents index
Next: Appendixes Up: Network Previous: Internet   Contents   Index


Security in the Network

Masquerading, firewall, and Kerberos constitute the basis for a secure network, enabling control of the data traffic. The Secure Shell (SSH) allows users to log in to remote hosts by way of an encrypted connection. The information in this chapter provides a basis for securing a network and working securely in the network with these tools.

Masquerading and Firewalls

Because of its outstanding network capabilities, Linux is frequently used as a router operating system for dial-up or dedicated lines. Router, in this case, refers to a host with multiple network interfaces that transmits any packets not destined for one of its own network interfaces to another host communicating with it. This router is often called a gateway. The packet filtering mechanism provided by the Linux kernel allows precise control over which packets of the overall traffic are transferred.

In general, defining the exact rules for a packet filter requires at least some experience on the part of the administrator. For the less experienced user, SuSE Linux includes a separate package, package SuSEfirewall2, intended to make it easier to set up these rules. SuSEfirewall2 is highly configurable, making it a good choice for a more complex packet filtering setup.

With this packet filter solution, a Linux machine can be used as a router with masquerading to link a local network through a dial-up or dedicated connection where only one IP address is visible to the outside world. Masquerading is accomplished by implementing rules for packet filtering.


This chapter only describes standard procedures that should work well in most situations. Although every effort has been made to provide accurate and complete information, no guarantee is included. SuSE cannot be responsible for the success or failure of your security measures. We do appreciate your criticism and comments. Although you might not receive a direct answer from us, rest assured that suggestions for improvement will be taken seriously.

Masquerading Basics

Masquerading is the Linux-specific form of NAT (Network Address Translation). The basic principle is not very complicated: Your router has more than one network interface, typically a network card and a separate interface to the Internet (e.g., an ISDN interface). While this interfaces links with the outside world, the remaining ones are used to connect this router with the other hosts in your network. For example, the dial-up is conducted via ISDN and the network interface is ippp0. Several hosts in your local network are connected to the network card of your Linux router, in this example, eth0. Hosts in the network should be configured to send packets destined outside the local network to this gateway.


Make sure both the broadcast addresses and the network masks are the same for all the hosts when configuring your network.

When one of the hosts sends a packet destined for an Internet address, this packet is sent to the network's default router. The router needs to be configured to actually forward such packets. SuSE Linux does not enable this with a default installation for security reasons. Set the variable IP_FORWARD, defined in the file /etc/sysconfig/sysctl, to IP_FORWARD=yes. The forwarding mechanism is enabled after rebooting or issuing the command echo 1 > /proc/sys/net/ipv4/ip_forward.

The router has only one IP address visible from the outside, such as the IP address of the connected ISDN interface. The source address of transmitted packets must be replaced with the router's address to enable reply. The target host only knows your router, not hosts in your internal network. Your internal host disguises itself behind the router, which is why the technique is called ``masquerading.''

The router, as the destination of any reply packets, must identify the incoming packets, change the target address to the intended recipient, and forward it to that host in the local network. The identification of packets belonging to a connection handled by a masquerading router is done with the help of a table kept in the kernel of your router while connected. By using the ipchains and the iptables commands, the superuser (SuSE @nohyphen root) can view these tables. Read the man pages for these commands for detailed instructions. For the identification of single masqueraded connections, the source and target addresses, the port numbers, and the protocols involved are relevant. A router is capable of hiding many thousand connections per internal host simultaneously.

With the routing of inbound traffic depending on the masquerading table, there is no way to open a connection to an internal host from the outside. For such a connection, there would be no entry in the table because it is only created if an internal host opens a connection with the outside. In addition, any established connection is assigned a status entry in the table and this entry cannot be used by another connection. A second connection would require another status record. As a consequence of all this, you might experience some problems with a number of applications, such as ICQ, cucme, IRC (DCC, CTCP), Quake, and FTP (in PORT mode). Netscape, as well as the standard FTP program and many others, uses the PASV mode. This passive mode is much less problematic as far as packet filtering and masquerading is concerned.

Firewalling Basics

``Firewall'' is probably the most widely used term to describe a mechanism to control the data traffic between two networks and to provide and manage the link between networks. There are various types of firewalls, which mostly differ in regard to the abstract level on which traffic is analyzed and controlled. Strictly speaking, the mechanism described in this section is called a ``packet filter.'' Like any other type of firewall, a packet filter alone does not guarantee full protection from all security risks. A packet filter implements a set of rules related to protocols, ports, and IP addresses to decide whether data may pass. This blocks any packets that, according to the address or destination, are not supposed to reach your network. Packets sent to the telnet service of your hosts on port 23, for example, should be blocked, while you might want people to have access to your web server and therefore enable the corresponding port. A packet filter will not scan the contents of any packets as long as they have legitimate addresses (e.g. , directed to your web server). Thus, packets could attack your CGI server, but the packet filter would let them through.

A more effective, but more complex mechanism is the combination of several types of systems, such as a packet filter interacting with an application gateway or proxy. In this case, the packet filter rejects any packets destined to disabled ports. Only packets directed to the application gateway are accepted. This gateway or proxy pretends to be the actual client of the server. In a sense, such a proxy could be considered a masquerading host on the protocol level used by the application. One example for such a proxy is Squid, an HTTP proxy server. To use Squid, the browser must be configured to communicate via the proxy, so any HTTP pages requested would be served from the proxy cache rather than directly from the Internet. As another example, the SuSE proxy suite ( package proxy-suite) includes a proxy for the FTP protocol.

The following section focuses on the packet filter that comes with SuSE Linux. For more information and links, read the Firewall HOWTO included in package howtoen. If this package is installed, read the HOWTO with less /usr/share/doc/howto/en/Firewall-HOWTO.gz.


The configuration of SuSEfirewall2 requires a certain degree of experience and understanding. The documentation of SuSEfirewall2 is available in /usr/share/doc/packages/SuSEfirewall2.

The configuration can be performed with YaST (see 18) or manually in the file /etc/sysconfig/SuSEfirewall2, which is well commented.

Manual Configuration

The following paragraphs provide step-by-step instructions for a successful configuration. For each configuration item, find a note specifying whether it is relevant for firewalling or for masquerading. Aspects related to the DMZ (or ``demilitarized zone'') are not covered here.

If your requirements are strictly limited to masquerading, only fill out items marked masquerading.

  • First, use the YaST runlevel editor to enable SuSEfirewall2 in your runlevel (3 or 5 most likely). It sets the symlinks for the SuSEfirewall2_* scripts in the /etc/init.d/rc?.d/ directories.

  • FW_DEV_WORLD (firewall, masquerading): The device linked to the Internet, such as eth0 or ippp0.

  • FW_DEV_INT (firewall, masquerading): The device linked to the internal, ``private'' network. Leave this blank if there is no internal network and the firewall is supposed to protect only the one host.

  • FW_ROUTE (firewall, masquerading): If you need the masquerading function, enter yes here. Your internal hosts will not be visible to the outside, because their private network addresses (e.g. , 192.168.x.x) are ignored by Internet routers.

    For a firewall without masquerading, only set this to yes to allow access to the internal network. Your internal hosts need to use officially registered IPs in this case. Normally, however, you should not allow access to your internal network from the outside.

  • FW_MASQUERADE (masquerading): Set this to yes if you need the masquerading function. It is more secure to have a proxy server between the hosts of the internal network and the Internet.

  • FW_MASQ_NETS (masquerading): Specify the hosts or networks to masquerade, leaving a space between the individual entries. For example, FW_MASQ_NETS=

  • FW_PROTECT_FROM_INTERNAL (firewall): Set this to yes to protect your firewall host from attacks originating in your internal network. Services will only be available to the internal network if explicitly enabled. See also FW_SERVICES_INTERNAL_TCP and FW_SERVICES_INTERNAL_UDP.

  • FW_AUTOPROTECT_GLOBAL_SERVICES (firewall): This should normally be yes.

  • FW_SERVICES_EXTERNAL_TCP (firewall): Enter the services that should be available, for example, www smtp ftp domain 443 . Leave this blank for a workstation at home that is not intended to offer any services.

  • FW_SERVICES_EXTERNAL_UDP (firewall): Leave this blank if you do not run a name service that should be made available to the outside. Otherwise, enter the ports to use.

  • FW_SERVICES_INTERNAL_TCP (firewall): This defines the services available to the internal network. The notation is the same as for external TCP services, but, in this case, refers to the internal network.

  • FW_SERVICES_INTERNAL_UDP (firewall): See above.

  • FW_TRUSTED_NETS (firewall): Specify the hosts you really trust (``trusted hosts''). Note, however, that these also need to be protected from attacks. means that all hosts with an IP address beginning with 172.20.x.x and the host with the IP address are allowed to pass information through the firewall.

  • FW_SERVICES_TRUSTED_TCP (firewall): Here, specify the port addresses that may be used by the trusted hosts. For example, to grant them access to all services, enter 1:65535. Usually, it is sufficient to enter ssh as the only service.

  • FW_SERVICES_TRUSTED_UDP (firewall): Just like above, but for UDP ports.

  • FW_ALLOW_INCOMING_HIGHPORTS_TCP (firewall): Set this to ftp-data if you intend to use normal (active) FTP services.

  • FW_ALLOW_INCOMING_HIGHPORTS_UDP (firewall): Set this to dns to use the name servers registered in /etc/resolv.conf. If you enter yes here, all high ports will be enabled.

  • FW_SERVICE_DNS (firewall): Enter yes if you run a name server that should be available to external hosts. At the same time, enable port 53 under FW_TCP_SERVICES_*.

  • FW_SERVICE_DHCLIENT (firewall): Enter yes here if you use dhclient to assign your IP address.

  • FW_LOG_* (firewall): Specify the firewall's logging activity. For normal operation, it is sufficient to set FW_LOG_DENY_CRIT to yes.

  • FW_STOP_KEEP_ROUTING_STATE (firewall): Insert yes if you have configured your dial-up procedure to work automatically via diald or ISDN (dial-on-demand).

Now that you have configured SuSEfirewall2, do not forget to test your setup (for example, with telnet from an external host). Have a look at /var/log/messages, where you should see something like:

Feb  7 01:54:14 www kernel: Packet log: input DENY eth0 
PROTO=6 L=60 S=0x00 
I=36981 F=0x4000 T=59 SYN (#119)

Configuration with YaST

The YaST menus for the graphical configuration can be accessed from the YaST Control Center. Select ` System and Users' ->` Firewall'. The configuration is divided in four sections:

Basic Settings
Specify the interfaces to protect. To protect an individual host to which no internal network is connected, just specify the interface facing the Internet. If an internal network is connected to your system, the interface facing the network must also be specified. Exit this dialog with ` Next'.
You only need this option to use your system to offer services accessible from the Internet (web server, mail server, etc.). Activate the respective check boxes or use the ` Expert...' button to enable services by way of their port numbers (listed in /etc/services). If you are not going to use your host as a server, press ` Next' to exit this dialog without making any changes.
Here you can select the main features of your firewall:
  • ` Allow traceroute' assists you in checking the routing to your firewall.
  • ` Forward Traffic and Do Masquerading' protects hosts in the internal network against the Internet -- all Internet services seem to be used by your firewall, while the internal hosts remain invisible.
  • ` Protect All Running Services' indicates that network access to TCP and UDP services of the firewall is denied entirely. This does not affect the services explicitly made available in the preceding step.
  • ` Protect from Internal Network' Only the released firewall services are available for internal hosts. As it is not possible to make services available here, deactivate this option to grant access from the internal network.
Upon completion of the feature configuration, exit this dialog with ` Next'.
Determine the scope of logging for your firewall. Before you activate the ` Logging options', consider that these log files produce a great amount of output. The configuration of the logging function is the final step of the firewall configuration. Exit the dialog with ` Next' and confirm the following message to activate the firewall.

SSH -- Secure Shell, the Safe Alternative

With more and more computers installed in networked environments, it becomes often necessary to access hosts from a remote location. This normally means that a user sends login and password strings for authentication purposes. But as long as these strings are transmitted as plain text, they could be intercepted and misused to gain access to that user account, without the authorized user even knowing about it. Apart from the fact that this would open all the user's files to an attacker, the illegal account could be used to obtain administrator or SuSE @nohyphen root access, or to penetrate other systems. In the past, remote connections were established with Telnet, which offers no guards against eavesdropping in the form of encryption or other security mechanisms. There are other unprotected communication channels, like the traditional FTP protocol and some remote copying programs.

The SSH suite provides the necessary protection, by encrypting the authentication strings (usually a login name and a password) and all the other data exchanged between the hosts. With SSH, the data flow could still be recorded by a third party - only that the contents are encrypted and cannot be reverted to plain text unless the encryption key is known. So SSH enables secure communications over insecure networks such as the Internet. The SSH flavor that comes with SuSE Linux is OpenSSH.

The OpenSSH Package

SuSE Linux installs the package OpenSSH by default. The programs ssh, scp, and sftp are then available as alternatives to telnet, rlogin, rsh, rcp, and ftp.

The ssh Program

Using the ssh program, it is possible to log in to remote systems and work interactively. It replaces both telnet and rlogin. The slogin program is just a symbolic link pointing to ssh, with the name indicating that it is akin to rlogin. As an example, you can log in to the host sun with the command ssh sun . The host then prompts for the password on sun .

After successful authentication, you can work on the remote command line or use interactive applications, such as YaST. If the local user name is different from the remote user name, you can log in using a different login name with ssh -l augustine sun or ssh augustine@sun .

Furthermore, ssh offers the possibility to run commands on remote systems, as known from rsh. In the following example, we will run the command uptime on the host sun and create a directory with the name tmp. The program output will be displayed on the local terminal of the host earth .

ssh otherplanet uptime; mkdir tmp

tux@otherplanet's password:

  1:21pm  up  2:17,  9 users,  load average: 0.15, 0.04, 0.02

Quotation marks are necessary here to send both instructions with one command. It is only by doing this that the second command is likewise executed on sun .

scp -- Secure Copy

scp copies files to a remote machine. It is a secure and encrypted substitute for rcp. For example, scp MyLetter.tex sun : copies the file MyLetter.tex from the host earth to the host sun . To give a different user name, use the username@host format. Note that there is no -l option for this command.

After the correct password is entered, scp starts the data transfer and shows a growing row of asterisks to simulate a progress bar. In addition, the program displays the estimated time of arrival to the right of the progress bar. All output can be suppressed by giving the option -q.

scp also provides a recursive copying feature for entire directories. The command scp -r src/ sun :backup/ copies the entire contents of the directory src/ including all subdirectories to the host sun in the subdirectory backup/. If this subdirectory does not exist yet, it will be created automatically.

The option -p tells scp to leave the time stamp of files unchanged. -C compresses the data transfer. This minimizes the data volume to be transferred, but creates a heavier burden on the processor.

sftp -- Secure File Transfer

The sftp program can be used instead of scp for secure file transfer. During an sftp session, you can use many of the familiar commands as known from ftp. The sftp program may be a better choice than scp, especially when transferring data for which the file names are unknown beforehand.

The SSH Daemon (sshd) -- Server-Side

To work with the SSH client programs ssh and scp, a server, the SSH daemon, has to be running in the background, listening for connections on TCP/IP port 22.

The daemon generates three key pairs when starting for the first time. Each key pair consist of a private and a public key. Therefore, this procedure is referred to as public key-based. To guarantee the security of the communication via SSH, access to the private key files must be restricted to the system administrator. The file permissions are set accordingly by the default installation. The private keys are only required locally by the SSH daemon and must not be given to anyone else. The public key components (recognizable by the name extension .pub) are sent to the client requesting the connection; they are readable for all users.

A connection is initiated by the SSH client. The waiting SSH daemon and the requesting SSH client exchange identification data to compare the protocol and software versions, and to prevent connections through the wrong port. Since a child process of the original SSH daemon replies to the request, several SSH connections can be made simultaneously.

For the communication between SSH server and SSH client, OpenSSH supports versions 1 and 2 of the SSH protocol. A newly installed SuSE Linux system will default to version 2. If you want to keep using version 1 after an update, follow the instructions in /usr/share/doc/packages/openssh/README.SuSE. This document also describes how an SSH 1 environment can be transformed into a working SSH 2 environment with just a few steps.

When using version 1 of SSH, the server sends its public host key, as well as a server key, which is regenerated by the SSH daemon every hour. Both allow the SSH client to encrypt a freely chosen session key, which is sent over to the SSH server. The SSH client also tells the server which encryption method (cipher) to use.

Version 2 of the SSH protocol does not require a server key. Both sides use an algorithm according to Diffie-Helman instead to exchange their keys.

The private host and server keys are absolutely required to decrypt the session key and cannot be derived from the public parts. Only the SSH daemon contacted can decrypt the session key using its private keys (see man /usr/share/doc/packages/openssh/RFC.nroff). This initial connection phase can be watched closely by turning on the verbose debugging option -v of the SSH client. Version 2 of the SSH protocol is used by default, which however can be overridden to use version 1 of the protocol with the -1 switch. The client stores all public host keys in  /.ssh/known_hosts after its first contact with a remote host. This prevents any ``man-in-the-middle'' attacks, i.e. attempts by foreign SSH servers to use spoofed names and IP addresses are clearly exposed. Such attacks will be detected either by a host key which is not included in  /.ssh/known_hosts, or by the server's inability to decrypt the session key in the absence of an appropriate private counterpart.

It is recommended to backup the private and public keys stored in /etc/ssh/ in a secure, external location. In this way, key modifications can be detected and the old ones can be used again after a reinstallation. This spares users any unsettling warnings. If it is verified that, despite the warning, it is indeed the correct SSH server, the existing entry regarding this system will have to be removed from  /.ssh/known_hosts.

SSH Authentication Mechanisms

Now the actual authentication will take place, which, in its simplest form, consists of entering a password as mentioned above. The goal of SSH was to introduce a secure software that is also easy to use. As it is meant to replace rsh and rlogin, SSH must also be able to provide an authentication method appropriate for daily use. SSH accomplishes this by way of another key pair, which is generated by the user. The SSH package provides a helper program for this, which is ssh-keygen. After entering ssh-keygen -t rsa or ssh-keygen -t dsa, the key pair will be generated and you will be prompted for the base file name in which to store the keys:

Enter file in which to save the key (/home/newbie /.ssh/id_rsa):

Confirm the default setting and answer the request for a passphrase. Even if the software suggests an empty passphrase, a text from ten to thirty characters is recommended for the procedure described here. Do not use short and simple words or phrases. Confirm by repeating the passphrase. Subsequently, you will see where the private and public keys are stored, in our example, the files id_rsa and

Enter same passphrase again:
Your identification has been saved in /home/newbie /.ssh/id_rsa
Your public key has been saved in /home/newbie /.ssh/
The key fingerprint is:
79:c1:79:b2:e1:c8:20:c1:89:0f:99:94:a8:4e:da:e8 newbie @sun

Use ssh-keygen -p -t rsa or ssh-keygen -p -t dsa to change your old passphrase.

Copy the public key component ( in our example) to the remote machine and save it there at the location  /.ssh/authorized_keys. You will be asked to authenticate yourself with your passphrase the next time you establish a connection. If this does not occur, verify the location and contents of these files.

In the long run, this procedure is more troublesome than giving your password each time. Therefore, the SSH package provides another tool, the ssh-agent, which retains the private keys for the duration of an X session. The entire X session will be started as a child process of ssh-agent. The easiest way to do this is to set the variable usessh at the beginning of the .xsession file to yes and log in via a display manager such as KDM or XDM. Alternatively, enter ssh-agent startx.

Now you can use ssh or scp as usual. If you have distributed your private key as described above, you are no longer prompted for your password. Take care of terminating your X session or locking it with a password-protection, for instance xlock.

All the relevant changes which resulted from the introduction of version 2 of the SSH protocol are also documented in the file /usr/share/doc/packages/openssh/README.SuSE.

X, Authentication, and Other Forwarding Mechanisms

Beyond the previously described security-related improvements, ssh also simplifies the use of remote X applications. If you run ssh with the option -X, the DISPLAY variable will automatically be set on the remote machine and all X output will be exported to the remote machine over the existing ssh connection. At the same time, X applications started remotely and locally viewed with this method cannot be intercepted by unauthorized persons.

By adding the option -A, the ssh-agent authentication mechanism will be carried over to the next machine. This way, you can work from different machines without having to enter a password, but only if you have distributed your public key to the destination hosts and properly saved it there.

Both mechanisms are deactivated in the default settings, but can be permanently activated at any time in the system-wide configuration file /etc/ssh/sshd_config or the user's  /.ssh/config.

ssh can also be used to redirect TCP/IP connections. In the examples below, SSH is told to redirect the SMTP and the POP3 port, respectively:

ssh -L 25:sun :25 earth

Here, each connection directed to ``earth port 25'', SMTP is redirected to the SMTP port on sun via an encrypted channel. This is especially useful for those using SMTP servers without SMTP-AUTH or POP-before-SMTP features. From any arbitrary location connected to a network, e-mail can be transferred to the ``home'' mail server for delivery. Similarly, all POP3 requests (port 110) on earth can be forwarded to the POP3 port of sun with this command:

ssh -L 110:sun :110 earth

Both commands must be executed as SuSE @nohyphen root, because the connection is made to privileged local ports. E-mail is sent and retrieved by normal users in an existing SSH connection. The SMTP and POP3 host must be set to localhost for this.

Additional information can be found in the manual pages for each of the programs described above and also in the files under /usr/share/doc/packages/openssh.

Network Authentication -- Kerberos

An open network provides no means to ensure that a workstation can identify its users properly except the usual password mechanisms. In common installations, the user must enter the password each time a service inside the network is accessed. Kerberos provides an authentication method with which a user must register once and is then trusted in the complete network for the rest of the session. To have a secure network, the following requirements must be met:

  • Have all users prove their identity for each desired service and make sure no one can take the identity of someone else.
  • Make sure each network server also proves its identity. If you do not, an attacker might be able to impersonate the server and obtain sensitive information transmitted to the server. This concept is called ``mutual authentication'', because the client authenticates to the server and vice versa.

Kerberos helps you meet the above requirements by providing strongly encrypted authentication. The following shows how this is achieved. Only the basic principles of Kerberos are discussed here. For detailed technical instruction, refer to the documentation provided with your implementation of Kerberos.


The original Kerberos was designed at the MIT. Besides the MIT Kerberos, there exist several other implementations of Kerberos. SuSE Linux ships with a free implementation of Kerberos 5, the Heimdal Kerberos 5 from KTH. Because the following text covers features common to all versions, the program itself is referred to as Kerberos as long as no Heimdal-specific information is presented.

Kerberos Terminology

The following glossary will help you cope with Kerberos terminology.

Users or clients need to present some kind of credentials that authorize them to request services. Kerberos knows two kinds of credentials -- tickets and authenticators.
A ticket is a per-server credential used by a client to authenticate at a server from which it is requesting a service. It contains the name of the server, the client's name, the client's Internet address, a time stamp, a lifetime, and a random session key. All this data is encrypted using the server's key.
Combined with the ticket, an authenticator is used to prove that the client presenting a ticket is really the one it claims to be. An authenticator is built of the client's name, the workstation's IP address, and the current workstation's time all encrypted with the session key only known to the client and the server from which it is requesting a service. An authenticator can only be used once, unlike a ticket. A client can build an authenticator itself.
A Kerberos principal is unique entity (a user or service) to which it can assign a ticket. A principal consists of the following components:
  • primary -- the first part of a the principal, which can be the same as your user name in the case of a user.
  • instance -- some optional information characterizing the primary. This string is separated from the primary by a `/'.
  • realm -- this specifies your Kerberos realm. Normally, your realm is your domain name in uppercase letters.
mutual authentication
Kerberos ensures that both client and server can be sure of each others identity. They will share a (session) key, which they can use to communicate securely.
session key
Session keys are temporary private keys generated by Kerberos. They are known to the client and used to encrypt the communication between the client and the server for which it requested and received a ticket.
Almost all messages passed on in a network can be eavesdropped, stolen, and resent. In Kerberos context, this would be most dangerous if an attacker manages to obtain your request for a service containing your ticket and authenticator. He could then try to resend it (``replay'') and to impersonate you. However, Kerberos implements several mechanisms to deal with that problem.
server or service
``Service'' is used when we talk of a specific action to perform. The process behind this action is referred to as a ``server''.

How Kerberos Works

Kerberos is often called a third party trusted authentication service, which means all its clients trust Kerberos's judgment of another client's identity. Kerberos keeps a database of all its users and their private keys.

To ensure Kerberos is worth all the trust put in it, run both the authentication and ticket-granting server on a dedicated machine. Make sure only the administrator can access this machine physically and over the network. Reduce the (networking) services run on it to the absolute minimum -- do not even run sshd.

First contact
Your first contact with Kerberos is quite similar to any login procedure at a normal networking system. Enter your user name. This piece of information and the name of the ticket-granting service are sent to the authentication server (Kerberos). If the authentication server knows about your existence, it will generate a (random) session key for further use between your client and the ticket-granting server. Now the authentication server will prepare a ticket for the ticket-granting server. The ticket contains the following information -- all encrypted with a session key only the authentication server and the ticket-granting server know:
  • the names both of the client and the ticket-granting server
  • the current time
  • a lifetime assigned to this ticket
  • the client's IP address
  • the newly-generated session key
This ticket is then sent back to the client together with the session key, again in encrypted form, but this time the private key of the client is used. This private key is only known to Kerberos and the client, because it is derived from your user password. Now that the client has received this response, you are prompted for your password. This password is converted into the key that can decrypt the package sent by the authentication server. The package is ``unwrapped'' and password and key are erased from the workstation's memory. As long as the lifetime given to the ticket used to obtain other tickets does not expire, your workstation can prove your identity.

Requesting a service
To request a service from any server in the network, the client application needs to prove its identity to the server. Therefore, the application generates an authenticator. An authenticator consists of the following components:
  • the client's principal
  • the client's IP address
  • the current time
  • a checksum (chosen by the client)
All this information is encrypted using the session key that the client has already received for this special server. The authenticator and the ticket for the server are sent to the server. The server uses its copy of the session key to decrypt the authenticator, which gives him all information needed about the client requesting its service to compare it to that contained in the ticket. The server checks if the ticket and the authenticator originate from the same client.

Without any security measures implemented on the server side, this stage of the process would be an ideal target for replay attacks. Someone could try to resend a request stolen off the net some time before. To prevent this, the server will not accept any request with a time stamp and ticket received previously. In addition to that, a request with a time stamp differing too much from the time the request is received can be ignored.

Mutual authentication
Kerberos authentication can be used in both directions. It is not only a question of the client being the one it claims to be. The server should also be able to authenticate itself to the client requesting its service. Therefore, it sends some kind of authenticator itself. It adds one to the checksum it received in the client's authenticator and encrypts it with the session key, which is shared between it and the client. The client takes this response as a proof of the server's authenticity and they both start cooperating.
Ticket-granting -- getting into contact with all servers
Tickets are designed to be used for one server at a time. This implies that you have to get a new ticket each time you request another service. Kerberos implements a mechanism to obtain tickets for individual servers. This service is called the ``ticket-granting service''. The ticket-granting service is a service just like any other service mentioned before, so uses the same access protocols that have already been outlined. Any time an application needs a ticket that has not already been requested, it contacts the ticket-granting server. This request consists of the following components:
  • the requested principal
  • the ticket-granting ticket
  • an authenticator
Like any other server, the ticket-granting server now checks the ticket-granting ticket and the authenticator. If they are considered valid, the ticket-granting server builds a new session key to be used between the original client and the new server. Then the ticket for the new server is built, containing the following information:

  • the client's principal
  • the server's principal
  • the current time
  • the client's IP address
  • the newly-generated session key

The new ticket is assigned a lifetime, which is the lesser of the remaining lifetime of the ticket-granting ticket and the default for the service. The client receives this ticket and the session key, which are sent by the ticket-granting service, but this time the answer is encrypted with the session key that came with the original ticket-granting ticket. The client can decrypt the response without requiring the user's password when a new service is contacted. Kerberos can thus acquire ticket after ticket for the client without bothering the user more than once at login time.

Compatibility to Windows 2000
Windows 2000 contains a Microsoft implementation of Kerberos 5. As SuSE Linux makes use of the Heimdal implementation of Kerberos 5, find useful information and guidance in the Heimdal documentation. See 18.

Users' View of Kerberos

Ideally, a user's one and only contact with Kerberos happens during login at his workstation. The login process includes obtaining a ticket-granting ticket. At logout, a user's Kerberos tickets are automatically destroyed, which hinders anyone else from impersonating this user when not logged in. The automatic destruction of tickets can lead to a somewhat awkward situation when a user's login session lasts longer than the maximum lifespan given to the ticket-granting ticket (a reasonable setting is ten hours). However, the user can get a new ticket-granting ticket by running kinit. Enter the password password again and Kerberos obtains access to desired services without additional authentication. Those interested in a list of all the tickets silently acquired for them by Kerberos should run klist.

Here is a short list of some applications that use Kerberos authentication. These applications can be found under /usr/lib/heimdal/bin. They all have the full functionality of their common UNIX and Linux brothers plus the additional bonus of transparent authentication managed by Kerberos:

  • telnet, telnetd
  • rlogin
  • rsh, rcp, rshd
  • popper, push
  • ftp, ftpd
  • su
  • imapd
  • pine

You no longer have to type your password for using these applications because Kerberos has already proven your identity. ssh -- if compiled with Kerberos support -- can even forward all the tickets acquired for one workstation to another one. If you use ssh to log in to another workstation, ssh makes sure the encrypted contents of the tickets are adjusted to the new situation. Simply copying tickets between workstations is not sufficient as the ticket contains workstation specific information (the IP address). XDM and KDM offer Kerberos support, too. Read more about the Kerberos network applications in the Kerberos V5 UNIX User's Guide at

For More Information

SuSE Linux contains a free implementation of Kerberos called Heimdal. Its documentation is installed along with the package heimdal under /usr/share/doc/packages/heimdal/doc/ It is also available at the project's home page at

This is the official site of the MIT Kerberos is There, find links to any other relevant resource concerning Kerberos.

A ``classical'' dialog pointing out the principles of Kerberos is available at It is a less technical but still comprehensive read.

The paper at : quite an extensive insight to the basic principles of Kerberos without being too difficult to read. It also provides a lot of opportunities for further investigation and reading about Kerberos.

These links provide a short introduction to Kerberos and answer many questions regarding Kerberos installation, configuration, and administration:

The official Kerberos FAQ is available at

The book Kerberos -- A Network Authentication System by Brian Tung (ISBN 0-201-37924-4) offers extensive information.

Installing and Administering Kerberos

This section covers the installation of the Heimdal Kerberos implementation as well as some aspects of administration. This section does, however, assume that you are familiar with the basic concepts of Kerberos (see also 18).

Choosing the Kerberos Realms

The ``domain'' of a Kerberos installation is called a realm and is identified by a name, such as FOOBAR.COM or simply ACCOUNTING. Kerberos is case-sensitive, so is actually a different realm than FOOBAR.COM. Use the case you prefer. It is common practice, however, to use uppercase realm names.

It is also a good idea to use your DNS domain name (or a subdomain, such as ACCOUNTING.FOOBAR.COM). As shown below, your life as an administrator can be much easier if you configure your Kerberos clients to locate the KDC and other Kerberos services via DNS. To do so, it is helpful if your realm name is a subdomain of your DNS domain name.

Unlike the DNS name space, Kerberos is not hierarchical. You cannot set up a realm named FOOBAR.COM, have two ``subrealms'' named DEVELOPMENT and ACCOUNTING underneath it, and expect the two subordinate realms to somehow inherit principals from FOOBAR.COM. Instead, you would have three separate realms for which you would have to configure ``crossrealm'' authentication for users from one realm to interact with servers or other users from another realm.

For the sake of simplicity, assume you are setting up just one realm for your entire organization. Setting up crossrealm authentication is described in (), for instance. For the remainder of this section, the realm name SAMPLE.COM is used in all examples.

Setting up the KDC Hardware

The first thing required to use Kerberos is a machine that will act as the Key Distribution Center, or KDC for short. This machine holds the entire Kerberos user database with passwords and all information.

The KDC is the most important part of your security infrastructure -- if someone breaks into it, all user accounts and all of your infrastructure protected by Kerberos is compromised. An attacker with access to the Kerberos database can impersonate any principal in the database. Tighten security for this machine as much as possible:

  • Put the server machine into a physically secured location, such as a locked server room to which only a very few people have access.

  • Do not run any network applications on it except the KDC. This includes servers and clients -- for instance, the KDC should not import any file systems via NFS or use DHCP to retrieve its network configuration.

    It is probably a good approach to install a minimal system first, then check the list of installed packages and remove any unneeded packages. This includes servers, such as inetd, portmap, and cups, as well as anything X11-based. Even installing an SSH server should be considered a potential security risk.

    No graphical login is provided on this machine as an X server is a potential security risk. Kerberos provides its own administration interface.

  • Configure /etc/nsswitch.conf to use only local files for user and group lookup. Change the lines for passwd and group to look like this:
          passwd:         files
          group:          files

    Edit the passwd, group, shadow, and gshadow files in /etc and remove the lines that start with a + character (these are for NIS lookups).

    Also consider disabling DNS lookups, because there is a potential risk involved. If there is a security bug in the DNS resolver library, an attacker might be able to trick the KDC into performing a DNS query that triggers this bug. To disable DNS lookups, simply remove /etc/resolv.conf.

  • Disable all user accounts except root's account by editing /etc/shadow and replacing the hashed passwords with * or ! characters.

Clock Synchronization

To use Kerberos successfully, make sure all system clocks within your organization are synchronized within a certain range. This is important because Kerberos protects against ``replayed'' credentials. An attacker might be able to observe Kerberos credentials on the network and reuse them to attack the server. Kerberos employs several defenses to prevent this. One of them is that it puts time stamps into its tickets. A server receiving a ticket with a time stamp that is not the current time rejects the ticket.

Of course, Kerberos will allow a certain leeway when comparing time stamps. However, computer clocks can be very inaccurate in keeping time -- it is not unheard of for PC clocks to lose or gain half an hour over the course of a week. For this reason, configure all hosts on the network to synchronize their clocks with a central time source.

A simple way to do so is by installing an NTP time server on one machine and have all clients synchronize their clocks with this server. Do this either by running an NTP daemon in client mode on all these machines or by running ntpdate once a day from all clients (this solution will probably work for a small number of clients only). The KDC itself needs to be synchronized to the common time source as well. Because running an NTP daemon on this machine would be a security risk, it is probably a good idea to do this by running ntpdate via a cron entry. NTP configuration itself is beyond the scope of this section. For more information, refer to the NTP documentation included in your installed system under /usr/share/doc/packages/xntp-doc.

It is also possible to adjust the maximum deviation Kerberos allows when checking time stamps. This value (called ``clock skew'') can be set via the krb5.conf file as described in 18.

Log Configuration

By default, the Kerberos daemons running on the KDC host log information to the syslog daemon. To keep an eye on what your KDC is doing, process these log files regularly, scanning for unusual events or potential problems. Either do this by running a log scanner script on the KDC host itself or by copying these files from the KDC to another host with rsync. Forwarding all log output via syslogd's log forwarding mechanisms is not recommended, because information traverses the network unencrypted.

Installing the KDC

This section covers the initial installation of the KDC, including creation of an administrative principal.

Installing the RPMs

Before you can start, install the Kerberos software. On the KDC, install the packages heimdal, heimdal-lib, and heimdal-tools:

rpm -ivh heimdal-*.rpm heimdal-lib-*.rpm heimdal-tools*.rpm

Setting the Master Key

Your next step is to initialize the database where Kerberos keeps all information on principals. First, set the database master key, which is used to protect the database from accidental disclosure, in particular when it is backed up to a tape. The master key is derived from a pass phrase and is stored in a file called the stash file. This is so you do not need to type in the password every time the KDC is restarted. Make sure you choose a good pass phrase, such as a sentence from a book opened at a random page.

When you make tape backups of the Kerberos database (/var/heimdal/heimdal.db), do not back up the stash file (which is in /var/heimdal/m-key). Otherwise, everyone able to read the tape could also decrypt the database. Therefore, it is also a good idea to keep a copy of the pass phrase in a safe or some other secure location, because you will need it when restoring your database from backup tape after a crash.

To set the master key, run kstash without arguments and enter the pass phrase twice:


Master key:<enter pass phrase>
Verifying password - Master key:<enter pass phrase again>

Creating the Realm

Finally, create entries for your realm in the Kerberos database. Run kadmin utility with the -l option as shown. This option tells kadmin to access the database locally. By default, it will try to contact the Kerberos admin service over the network. At this stage, this will not work because it is not running yet.

Now, tell kadmin to initialize your realm. It will ask you a number of questions in return. It is best to accept the default settings offered by kadmin initially:

kadmin -l

kadmin> init SAMPLE.COM
Realm max ticket life [unlimited]: <press return>
Realm max renewable ticket life [unlimited]: <press return>

To verify that it did anything, use the list command:

kadmin> list *

This shows that there are now a number of principals in the database. All of these are for internal use by Kerberos.

Creating a Principal

Next, create two Kerberos principals for yourself: one ``normal'' principal for your everyday work and one for administrative tasks relating to Kerberos. Assuming your login name is newbie, proceed as follows:

kadmin -l

kadmin> add newbie
Max ticket life [1 day]: <press return>
Max renewable life [1 week]: <press return>
Principal expiration time [never]: <press return>
Password expiration time [never]: <press return>
Attributes []: <press return>
newbie@SAMPLE.COM's Password: <type password here>
Verifying password: <re-type password here>

Accepting the defaults by pressing is okay. Choose a good password, however.

Next, create another principal named newbie/admin by typing add newbie/admin at the kadmin prompt. The admin suffixed to your user name is a ``role''. Later, use this role when administering the Kerberos database. A user can have several roles for different purposes. Roles are basically completely different accounts with similar names.

Starting the KDC

Start the KDC daemons. This includes kdc itself (the daemon handling user authentication and ticket requests), kadmind (the server performing remote administration), and kpasswddd (handling user's password change requests). To start the daemon manually, enter:

rckdc start

Starting kdc              done

Also make sure KDC is started by default when the server machine is rebooted. This is done with the command insserv kdc.

Configuring Kerberos Clients

When configuring Kerberos, there are basically two approaches you can take -- static configuration via the /etc/krb5.conf file or dynamic configuration via DNS. With DNS configuration, Kerberos applications try to locate the KDC services via DNS records. With static configuration, add the host names of your KDC server to krb5.conf (and update the file whenever you move the KDC or reconfigure your realm in other ways).

DNS-based configuration is generally a lot more flexible and the amount of configuration work per machine is a lot less. However, it requires that your realm name is either the same as your DNS domain or a subdomain of it.

Configuring Kerberos via DNS also creates a minor security issue -- an attacker can seriously disrupt your infrastructure through your DNS (by shooting down the name server, by spoofing DNS records, etc). However, this amounts to a denial of service at most. A similar scenario applies to the static configuration case unless you enter IP addresses in krb5.conf instead of host names.

Static Configuration

One way to configure Kerberos is to edit the configuration file /etc/krb5.conf. The file installed by default contains various sample entries. Erase all of these entries before starting. krb5.conf is made up of several sections, each introduced by the section name included in brackets like [this].

To configure your Kerberos clients, add the following stanza to krb5.conf (where is the host name of the KDC):

        default_realm = SAMPLE.COM

        SAMPLE.COM = {
                kdc =
                kpasswd_server =
                admin_server =

The default_realm line sets the default realm for Kerberos applications. If you have several realms, just add another statement to the [realms] section.

Also add a statement to this file that tells applications how to map host names to a realm. For instance, when connecting to a remote host, the Kerberos library needs to know in which realm this host is located. This must be configured in the [domain_realms] section:

[domain_realm] = SAMPLE.COM = SAMPLE.COM

This tells the library that all hosts in the DNS domains are in the SAMPLE.COM Kerberos realm. In addition, one external host named should also be considered a member of the SAMPLE.COM realm.

DNS-Based Configuration

DNS-based Kerberos configuration makes heavy use of SRV records (see (RFC2052) A DNS RR for specifying the location of services at These records are not supported in earlier implementations of the BIND name server. At least BIND version 8 is required for this.

The name of a SRV record, as far as Kerberos is concerned, is always in the format _service._proto.realm, where realm is the Kerberos realm. Domain names in DNS are case insensitive, so case-sensitive Kerberos realms would break when using this configuration method. _service is a service name (different names are used when trying to contact the KDC or the password service, for example). _proto can be either _udp or _tcp, but not all services support both protocols.

The data portion of SRV resource records consists of a priority value, a weight, a port number, and a host name. The priority defines the order in which hosts should be tried (lower values indicate a higher priority). The weight is there to support some sort of load balancing among servers of equal priority. You will probably never need any of this, so it is okay to set these to zero.

Heimdal Kerberos currently looks up the following names when looking for services:

This defines the location of the KDC daemon (the authentication and ticket granting server). Typical records look like this:
_kerberos._udp.SAMPLE.COM.  IN  SRV    0 0 88
_kerberos._tcp.SAMPLE.COM.  IN  SRV    0 0 88
This describes the location of the password changing server. Typical records look like this:
_kpasswd._udp.SAMPLE.COM.   IN  SRV    0 0 464
Because kpasswdd does not support TCP, there should be no _tcp record.

This describes the location of the remote administration service. Typical records look like this:

_kerberos-adm._tcp.SAMPLE.COM. IN  SRV    0 0 749
Because kadmind does not support UDP, there should be no _udp record.

As with the static configuration file, there is a mechanism to inform clients that a specific host is in the SAMPLE.COM realm, even if it is not part of the DNS domain. This can be done by attaching a TXT record to _keberos.hostname, as shown here:  IN TXT "SAMPLE.COM"

Adjusting the Clock Skew

The ``clock skew'' is the tolerance for accepting tickets with time stamps that do not exactly match the host's system clock. Usually, the clock skew is set to 300 seconds, or 5 minutes. This means a ticket can have a time stamp somewhere between 5 minutes ago and 5 minutes in the future from the server's point of view.

When using NTP to synchronize all hosts, you can reduce this value to about one minute. The clock skew value can be set in /etc/krb5.conf like this:

        clockskew = 120

Remote Kerberos Administration

To be able to add and remove principals from the Kerberos database without accessing the KDC's console directly, tell the Kerberos administration server which principals are allowed to do what. Do this by editing the file /var/heimdal/kadmind.acl (ACL is an abbreviation for Access Control List). The ACL file allows you to specify privileges with a fine degree of control. For details, refer to the manual page with man 8 kadmind.

Right now, just grant yourself the privilege to do anything you want with the database by putting the following line into the file:

newbie/admin              all

Replace the user name newbie with your own. You then have to restart the KDC for the change to take effect.

Using kadmin for Remote Administration

You should now be able to perform Kerberos administration tasks remotely using the kadmin tool. First, obtain a ticket for your admin role and use that ticket when connecting to the kadmin server:

kinit newbie/admin
newbie/admin@SAMPLE.COM's Password: <enter password>
kadmin> privs
change-password, list, delete, modify, add, get

Using the privs command, verify which privileges you have. The list shown above is the full set of privileges.

As an example, modify the principal newbie:

kadmin> mod newbie
Max ticket life [1 day]:2 days
Max renewable life [1 week]:
Principal expiration time [never]:2003-01-01
Password expiration time [never]:
Attributes []:

This changes the maximum ticket life time to two days and sets the expiration date for the account to January 1, 2003.

Basic kadmin Commands

Here is a brief list of kadmin commands. For more information, refer to [8]kadmin.

add <principal>
add a new principal

modify <principal>
edit various attributes of a principal, such as maximum ticket life time and account expiration date

delete <principal>
remove a principal from the database

rename <principal> <newname>
renames a principal to <newname>

list <pattern>
list all principals matching the given pattern. Patterns work much like the shell globbing patterns: list newbie* would list newbie and newbie/admin in our example.

get <principal>
display detailed information about the principal

passwd <principal>
changes a principal's password

At all stages, help is available by typing ? and . This even works in prompt environments generated by modify and add.

The init command used when initially creating the realm (as well as a few others) is not available in remote mode. To create a new realm, go to the KDC's console and use kadmin in local mode (using the -l command line option). The same is true for dumping and restoring the KDC database using the dump, load, and merge commands.

Creating Kerberos Host Principals

In addition to making sure every machine on your network knows which Kerberos realm it is in and what KDC to contact, create a ``host principal'' for it. So far, only user credentials have been discussed. However, Keberized services usually need to authenticate themselves to the client user, too. Therefore, special ``host principals'' must be present in the Kerberos database for each host in the realm.

The naming convention for host principals is host/<hostname>@<REALM>, where <hostname> is the host's fully qualified host name. Host principals are almost like user principals, but not quite. The main difference between a user principal and a host principal is that the key of the former is protected by a password -- when a user obtains a ticket-granting ticket from the KDC, he needs to type his password so Kerberos can decrypt the ticket. Obviously, it would be quite inconvenient for the system administrator if he had to obtain new tickets for the SSH daemon every eight hours or so.

Instead, the key required to decrypt the initial ticket for the host principal is extracted by the administrator from the KDC once and stored in a local file called the ``keytab''. Services such a the SSH daemon read this key and use it to obtain new tickets automatically when needed. The default keytab file resides in /etc/krb5.keytab.

To create a host principal for, enter the following commands during your kadmin session:

kinit newbie/admin
newbie/admin@SAMPLE.COM's Password: <type password>
kadmin add -r host/
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:

Instead of setting a password for the new principal, the -r flag tells kadmin to generate a random key. We can do this here because we do not want any user interaction for this principal. It is a server account for the machine.

Finally, extract the key and store it in the local keytab file /etc/krb5.keytab. This file is owned by the superuser, so you must be root to execute the next command:

ktutil get host/

When completed, make sure you destroy the admin ticket obtained via kinit above with kdestroy.

Enabling PAM Support for Kerberos

SuSE Linux comes with a PAM module named pam_krb5, which supports Kerberos login and password update. This module can be used by applications, such as console login, su, and graphical login applications like KDM, where the user presents a password and would like the authenticating application to obtain an initial Kerberos ticket on his behalf.

Beginning with this version of SuSE Linux, the pam_unix module, too, supports Kerberos authentication and password updating. To enable Kerberos support in pam_unix, edit the file /etc/security/pam_unix2.conf so it contains the following lines:

auth:       use_krb5 nullok
account:    use_krb5
password:   use_krb5 nullok
session:    none

After that, all programs evaluating the entries in this file use Kerberos for user authentication. For a user that does not have a Kerberos principal, pam_unix falls back on the normal password authentication mechanism. For those users who have a principal, it should now be possible to change their Kerberos passwords transparently using the passwd command.

To make fine adjustments to the way in which pam_krb5 is used, edit the file /etc/krb5.conf and add default applications to pam. For details refer to the manual page with man 5 pam_krb5.

The pam_krb5 module was specifically not designed for network services that accept Kerberos tickets as part of user authentication. This is an entirely different matter, which is discussed below.

Configuring SSH for Kerberos Authentication

OpenSSH supports Kerberos authentication in both protocol version 1 and 2. In version 1, there are special protocol messages to transmit Kerberos tickets. Version 2 does not use Kerberos directly anymore, but relies on ``GSSAPI'', the General Security Services API. This is a programming interface that is not specific to Kerberos -- it was designed to hide the peculiarities of the underlying authentication system, be it Kerberos, a public-key authentication system like SPKM, or others. The GSSAPI library included in SuSE Linux supports only Kerberos, however.

To use sshd with Kerberos authentication, edit /etc/ssh/sshd_config and set the following options:

# These are for protocol version 1
KerberosAuthentication yes
KerberosTgtPassing yes
# These are for version 2
GSSAPIAuthentication yes
GSSAPIKeyExchange yes

Then restart your SSH daemon using rcsshd restart.

To use Kerberos authentication with protocol version 2, enable it on the client-side as well. Do this either in the system-wide configuration file /etc/ssh/ssh_config or on a per-user level by editing  /.ssh/config. In both cases, add the option GSSAPIAuthentication yes.

You should now be able to connect using Kerberos authentication. Use klist to verify you have a valid ticket, then connect to the SSH server. To force SSH protocol version 1, specify option -1 on the command line.


Last login: Fri Aug  9 14:12:50 2002 from
Have a lot of fun...

Using LDAP and Kerberos

When using Kerberos, one way to distribute the user information (such as user ID, groups, home directory, etc.) in your local network is to use LDAP. This requires a strong authentication mechanism that prevents packet spoofing and other attacks. One solution is to use Kerberos for LDAP communication, too.

OpenLDAP implements most authentication flavors through SASL, the Simple Authentication Session Layer. SASL is basically a network protocol designed for authentication. The SASL implementation used in SuSE Linux is cyrus-sasl, which supports a number of different authentication flavors. Kerberos authentication is performed through GSSAPI (General Security Services API). By default, the SASL plug-in for GSSAPI is not installed. Install it manually with rpm -ivh cyrus-sasl-gssapi-*.rpm.

To enable Kerberos binding to the OpenLDAP server, create a principal ldap/ and add that to the keytab:

kadmin add -r ldap/

ktutil get ldap/

By default, the LDAP server slapd will run as user and group SuSE @nohyphen ldap, while the keytab file is readable by SuSE @nohyphen root only. Therefore, either change the LDAP configuration so the server runs as SuSE @nohyphen root or make the keytab file readable by group SuSE @nohyphen ldap.

To run slapd as root, edit /etc/sysconfig/openldap. Disable the OPENLDAP_USER and OPENLDAP_GROUP variables by putting a comment character in front of them.

To make the keytab file readable by group LDAP, execute

chgrp ldap /etc/krb5.keytab

chmod 640 /etc/krb5.keytab

Neither solution is perfect. However, at the moment it is not possible to configure OpenLDAP to make it use a separate keytab file.

Finally, restart the LDAP server using rcldap restart.

Using Kerberos Authentication with LDAP

You should now be able to use tools, such as ldapsearch, with Kerberos authentication automatically.

ldapsearch -b ou=People,dc=suse,dc=de '(uid=newbie)'

SASL/GSSAPI authentication started
SASL installing layers

# newbie, People,
dn: uid=newbie,ou=People,dc=suse,dc=de
uid: newbie
cn: Olaf Kirch

As you can see, ldapsearch prints a message that it started GSSAPI authentication. The next message is admittedly very cryptic, but it shows that the ``Security Strength Factor'' (SSF for short) is 56. (The value 56 is somewhat arbitrary. Most likely it was chosen because this is the number of bits in a DES encryption key.) What this tells you is that GSSAPI authentication was successful and that encryption is being used to provide integrity protection and confidentiality of the LDAP connection. If there are several SASL mechanisms that could be used, you can force ldapsearch to use GSSAPI by adding -Y GSSAPI to the command line options.

In Kerberos, authentication is always mutual. This means that not only have you authenticated yourself to the LDAP server, but also the LDAP server authenticated itself to you. In particular, this means communication is with the desired LDAP server, rather than some bogus service set up by an attacker.

Kerberos Authentication and LDAP Access Control

Now, allow each user to modify the login shell attribute of their LDAP user record. Assuming you have a schema where the LDAP entry of user SuSE @nohyphen joe is located at uid=joe,ou=people,dc=suse,dc=de, set up the following access controls in /etc/openldap/slapd.conf:

# This is required for things to work _at all_
access to dn.base="" by * read
# Let each user change their login shell
access to dn="*,ou=people,dc=suse,dc=de" attrs=loginShell
       by self write
# Every user can read everything
access to *
       by users read

The second statement gives authenticated users write access to the loginShell attribute of their own LDAP entry. The third statement gives all authenticated users read access to the entire LDAP directory.

There is one minor piece of the puzzle missing, which is how the LDAP server can find out that the Kerberos user joe@SAMPLE.COM corresponds to the LDAP distinguished name uid=joe,ou=people,dc=suse,dc=de. This sort of mapping must be configured manually using the saslExpr directive. In our example, add the following to slapd.conf:


To understand how this works, you need to know that when SASL authenticates a user, OpenLDAP will form a distinguished name from the name given to it by SASL (such as joe) and the name of the SASL flavor (GSSAPI). The result would be uid=joe,cn=GSSAPI,cn=auth.

If a saslRegexp has been configured, it will check the DN formed from the SASL information using the first argument as a regular expression. If this regular expression matches, the name will be replaced with the second argument of the saslRegexp statement. The placeholders $1 will be replaced with the substring matched by the (.*) expression.

More complicated match expressions are possible. If you have a more complicated directory structure or a schema where the user name is not part of the DN, you can even use search expressions to map the SASL DN to the user DN.

Security and Confidentiality

Basic Considerations

One of the main characteristics of a Linux or UNIX system is its ability to handle several users at the same time (multiuser) and to allow these users to perform several tasks (multitasking) on the same computer simultaneously. Moreover, the operating system is network transparent. The users often do not know whether the data and applications they are using are provided locally from their machine or made available over the network.

With the multiuser capability the respective data of different users must be stored separately. Security and privacy need to be guaranteed. ``Data security'' was already an important issue, even before computers could be linked through networks. Just like today, the most important concern was the ability to keep data available in spite of a lost or otherwise damaged data medium, a hard disk in most cases.

This chapter is primarily focused on confidentiality issues and on ways to protect the privacy of users, but it cannot be stressed enough that a comprehensive security concept should always include procedures to have a regularly updated, workable, and tested backup in place. Without this, you could have a very hard time getting your data back -- not only in the case of some hardware defect, but also if the suspicion arises that someone has gained unauthorized access and tampered with files.

Local Security and Network Security

There are several ways of accessing data:

  • Personal communication with people who have the desired information or access to the data on a computer
  • directly from the console of a computer (physical access)
  • over a serial line
  • using a network link

In all these cases, a user should be authenticated before accessing the resources or data in question. A web server might be less restrictive in this respect, but you still would not want it to disclose all your personal data to any surfer out there.

In the list above, the first case is the one where the highest amount of human interaction is involved, such as when you are contacting a bank employee and are required to prove that you are the person owning that bank account. Then you will be asked to provide a signature, a PIN, or a password to prove that you are the person you claim to be. In some cases, it might be possible to elicit some intelligence from an informed person just by mentioning known bits and pieces here and there to win the confidence of that person by using clever rhethoric. The victim could be led to gradually reveal more information, maybe without even becoming aware of it. Among hackers, this is called ``social engineering''. You can only guard against this by educating people and by dealing with language and information in a conscious way. Before breaking into computer systems, attackers often try to target receptionists, service people working with the company, or even family members. In many cases, such an attack based on social engineering will only be discovered at a much later time.

A person wanting to obtain unauthorized access to your data could also use the traditional way and try to get at your hardware directly. Therefore, the machine should be protected against any tampering so that no one can remove, replace, or cripple its components. This also applies to backups and even any network cable or the power cord. Likewise, secure the boot procedure, as there are some well-known key combinations which invoke special reactions during booting. Protect yourself against this by setting passwords for the BIOS and the bootloader.

Serial terminals connected to serial ports are still used in many places. Unlike network interfaces, they do not rely on a network protocol to communicate with the host. A simple cable or an infrared port is used to send plain characters back and forth between the devices. The cable itself is the weakest point of such a system: with an older printer connected to it, it is easy to record anything that runs over the wires. What can be achieved with a printer can also be accomplished in other ways, depending on the effort that goes into the attack.

Reading a file locally on a host requires other access rules than opening a network connection with a server on a different host. There is a distinction between local security and network security. The line is drawn where data has to be put into packets to be sent somewhere else.

Local Security

Local security starts with the physical environment in the location where the computer is running. Set up your machine in a place where security is in line with your expectations and needs.

The main goal of ``local security'' is to keep users separate from each other, so that no user can assume the permissions or the identity of another. This is a general rule to be observed, but it is especially true for the user SuSE @nohyphen root who holds the supreme power on the system. User SuSE @nohyphen root can take on the identity of any other local user without being prompted for the password and read any locally stored file.


On a Linux system, passwords are, of course, not stored as plain text and the text string entered is not simply matched with the saved pattern. If this were the case, all accounts on your system would be compromised as soon as someone got access to the corresponding file. Instead, the stored password is encrypted and, each time it is entered, is encrypted again and the two encrypted strings are compared. Naturally, this will only work if the encrypted password cannot be reverse-computed into the original text string.

This is actually achieved by a special kind of algorithm, also called ``trapdoor algorithm,'' because it only works in one direction. An attacker who has obtained the encrypted string will not be able to get your password by simply applying the same algorithm again. Instead, it would be necessary to test all the possible character combinations until a combination is found which looks like your password when encrypted. As you can imagine, with passwords eight characters long, there are quite a number of possible combinations to calculate.

In the seventies, it was argued that this method would be more secure than others due to the relative slowness of the algorithm used, which took a few seconds to encrypt just one password. In the meantime, however, PCs have become powerful enough to do several hundred thousand or even millions of encryptions per second. Because of this, encrypted passwords should not be visible to regular users (/etc/shadow cannot be read by normal users). It is even more important that passwords are not easy to guess, in case the password file becomes visible due to some error. Consequently, it is not really useful to ``translate'' a password like ``tantalise'' into ``t@nt@1ls3''.

Replacing some letters of a word with similar looking numbers is not safe enough. Password cracking programs which use dictionaries to guess words also play with substitutions like that. A better way is to make up a word with no common meaning, something which only makes sense to you personally, like the first letters of the words of a sentence or the title of a book, such as ``The Name of the Rose'' by Umberto Eco. This would give the following safe password: ``TNotRbUE9''. By contrast, passwords like ``beerbuddy'' or ``jasmine76'' are easily guessed even by someone who has only some casual knowledge about you.

The Boot Procedure

Configure your system so it cannot be booted from a floppy or from CD, either by removing the drives entirely or by setting a BIOS password and configuring the BIOS to allow booting from a hard disk only. Normally, a Linux system will be started by a boot loader, allowing you to pass additional options to the booted kernel. This is crucial to your system's security. Not only does the kernel itself run with root permissions, but it is also the first authority to grant root permissions at system start-up. Prevent others from using such parameters during boot by setting an additional password in /etc/lilo.conf (see 4).

File Permissions

As a general rule, always work with the most restrictive privileges possible for a given task. For example, it is definitely not necessary to be SuSE @nohyphen root to read or write e-mail. If the mail program has a bug, this bug could be exploited for an attack which will act with exactly the permissions of the program when it was started. By following the above rule, minimize the possible damage.

The permissions of the more than 200,000 files included in a SuSE distribution are carefully chosen. A system administrator who installs additional software or other files should take great care when doing so, especially when setting the permission bits. Experienced and security-conscious system administrators always use the -l option with the command ls to get an extensive file list, which allows them to detect any wrong file permissions immediately. An incorrect file attribute does not only mean that files could be changed or deleted. These modified files could be executed by SuSE @nohyphen root or, in the case of configuration files, that programs could use such files with the permissions of SuSE @nohyphen root. This significantly increases the possibilities of an attacker. Attacks like this are called cuckoo eggs, because the program (the egg) is executed (hatched) by a different user (bird), just like a cuckoo tricks other birds into hatching its eggs.

A SuSE Linux system includes the files permissions, permissions.easy,, and permissions.paranoid, all in the directory /etc. The purpose of these files is to define special permissions, such as world-writable directories or, for files, the setuser ID bits, which means the corresponding program will not run with the permissions of the user that has launched it, but with the permissions of the file owner, SuSE @nohyphen root in most cases. An administrator may use the file /etc/permissions.local to add his own settings. To define which of the above files is used by SuSE's configuration programs to set permissions accordingly use the submenu ` Security' in YaST2. To learn more about the topic, read the comments in /etc/permissions or consult the manual page of chmod (man chmod).

Buffer Overflows and Format String Bugs

Special care must be taken whenever a program is supposed to process data that can or could be changed by a user, but this is more of an issue for the programmer of an application than for regular users. The programmer has to make sure that his application will interpret data in the correct way, without writing them into memory areas that are too small to hold them. Also, the program should hand over data in a consistent manner, using the interfaces defined for that purpose.

A ``buffer overflow'' can happen if the actual size of a memory buffer is not taken into account when writing to that buffer. There are cases where this data (as generated by the user) uses up some more space than what is available in the buffer. As a result, data is written beyond the end of that buffer area, which, under certain circumstances, makes it possible that a program will execute program sequences influenced by the user (and not by the programmer), rather than just processing user data. A bug of this kind may have serious consequences, in particular if the program is being executed with special privileges (see Section 18).

``Format string bugs'' work in a slightly different way, but again it is the user input which could lead the program astray. In most cases, these programming errors are exploited with programs executed with special permissions -- setuid and setgid programs -- which also means that you can protect your data and your system from such bugs by removing the corresponding execution privileges from programs. Again, the best way is to apply a policy of using the lowest possible privileges (see Section 18).

Given that buffer overflows and format string bugs are bugs related to the handling of user data, they are not only exploitable if access has been given to a local account. Many of the bugs that have been reported can also be exploited over a network link. Accordingly, buffer overflows and format string bugs should be classified as being relevant for both local and network security.


Contrary to what some people will tell you, there are viruses that run on Linux. However, the viruses that are known were released by their authors as ``proof of concept'' to prove that the technique works as intended. None of these viruses have been spotted ``in the wild'' so far.

Viruses would not be able to survive and spread without a host on which they could live. In our case, the host would be a program or an important storage area of the system, such as the master boot record, which needs to be writable for the program code of the virus. Owing to its multiuser capability, Linux can restrict write access to certain files, especially important with system files. Therefore, if you did your normal work with SuSE @nohyphen root permissions, you would increase the chance of the system being infected by a virus. By contrast, if you follow the principle of using the lowest possible privileges as mentioned above, chances of getting a virus are slim.

Apart from that, you should never rush into executing a program from some Internet site that you do not really know. SuSE's RPM packages carry a cryptographic signature as a digital label that the necessary care was taken to build them. Viruses are a typical sign that the administrator or the user lacks the required security awareness, putting at risk even a system that should be highly secure by its very design.

Viruses should not be confused with worms which belong to the world of networks entirely. Worms do not need a host to spread.

Network Security

Network security is important for protecting from an attack originating in the network. The typical login procedure requiring a user name and a password for user authentication is a local security issue. However, in the particular case of logging in over a network, we need to differentiate between both security aspects. What happens until the actual authentication is network security and anything that happens afterwards is local security.

X Window System and X11 Authentication

As mentioned at the beginning, network transparency is one of the central characteristics of a UNIX system. X11, the windowing system of UNIX operating systems, can make use of this feature in an impressive way. With X11, it is basically no problem to log in at a remote host and start a graphical program that will then be sent over the network to be displayed on your computer.

For an X client to be displayed remotely using our X server, the latter is supposed to protect the resource managed by it (i.e. the display) from unauthorized access. In more concrete terms, certain permissions must be given to the client program. With the X Window System, there are two ways to do this, called host-based access control and cookie-based access control. The former relies on the IP address of the host where the client is supposed to run. The program to control this is xhost. xhost enters the IP address of a legitimate client into a tiny database belonging to the X server. However, relying on IP addresses for authentication is not very secure. For example, if there were a second user working on the host sending the client program, that user would have access to the X server as well -- just like someone stealing the IP address. Because of these shortcomings, we will not describe this authentication method in more detail here, but you can learn about it from man xhost.

In the case of cookie-based access control, a character string is generated which is only known to the X server and to the legitimate user, just like an ID card of some kind. This cookie (the word goes back not to ordinary cookies, but to Chinese fortune cookies which contain an epigram) is stored on login in the file .Xauthority in the user's home directory and is available to any X Window client wanting to use the X server to display a window. The file .Xauthority can be examined by the user with the tool xauth. If you were to rename .Xauthority or if you deleted the file from your home directory by accident, you would not be able to open any new windows or X clients. Read more about X Window security mechanisms in the man page of Xsecurity (man Xsecurity).

ssh (secure shell) can be used to completely encrypt a network connection and forward it to an X server transparently without the encryption mechanism being perceived by the user. This is also called X forwarding. X forwarding is achieved by simulating an X server on the server side and setting a DISPLAY variable for the shell on the remote host. Further details about ssh can be found in Section 18.


If you do not consider the host where you log in to be a secure host, do not use X forwarding. With X forwarding enabled, an attacker could authenticate via your ssh connection to intrude on your X server and sniff your keyboard input, for instance.

Buffer Overflows and Format String Bugs

As discussed on sec:bugs, buffer overflows and format string bugs should be classified as issues concerning both local and network security. As with the local variants of such bugs, buffer overflows in network programs, when successfully exploited, are mostly used to obtain SuSE @nohyphen root permissions. Even if that is not the case, an attacker could use the bug to gain access to an unprivileged local account to exploit any other vulnerabilities which might exist on the system.

Buffer overflows and format string bugs exploitable over a network link are certainly the most frequent form of remote attacks in general. Exploits for these -- programs to exploit these newly-found security holes -- are often posted on the security mailing lists. They can be used to target the vulnerability without knowing the details of the code. Over the years, experience has shown that the availability of exploit codes has contributed to more secure operating systems, obviously due to the fact that operating system makers were forced to fix the problems in their software. With free software, anyone has access to the source code (SuSE Linux comes with all available source codes) and anyone who finds a vulnerability and its exploit code can submit a patch to fix the corresponding bug.

DoS -- Denial of Service

The purpose of this kind of attack is to force down a server program or even an entire system, something which could be achieved by various means: overloading the server, keeping it busy with garbage packets, or exploiting a remote buffer overflow.

Often a DoS attack is done with the sole purpose of making the service disappear. However, once a given service has become unavailable, communications could become vulnerable to so-called ``man-in-the-middle attacks'' (sniffing, TCP connection hijacking, spoofing) and DNS poisoning.

Man in the Middle: Sniffing, Hijacking, Spoofing

In general, any remote attack performed by an attacker who puts himself between the communicating hosts is called a ``man-in-the-middle attack''. What almost all types of man-in-the-middle attacks have in common is that the victim is usually not aware that there is something happening. There are many possible variants, for example, the attacker could pick up a connection request and forward that to the target machine himself. Now the victim has unwittingly established a connection with the wrong host, because the other end is posing as the legitimate destination machine.

The simplest form of a man-in-the-middle attack is called ``sniffer'' -- the attacker is ``just'' listening to the network traffic passing by. As a more complex attack, the ``man in the middle'' could try to take over an already established connection (hijacking). To do so, the attacker would have to analyze the packets for some time to be able to predict the TCP sequence numbers belonging to the connection. When the attacker finally seizes the role of the target host, the victims will notice this, because they get an error message saying the connection was terminated due to a failure. The fact that there are protocols not secured against hijacking through encryption, which only perform a simple authentication procedure upon establishing the connection, makes it easier for attackers.

``Spoofing'' is an attack where packets are modified to contain counterfeit source data, mostly the IP address. Most active forms of attack rely on sending out such fake packets -- something that, on a Linux machine, can only be done by the superuser (SuSE @nohyphen root).

Many of the attacks mentioned are carried out in combination with a DoS. If an attacker sees an opportunity to abruptly bring down a certain host, even if only for a short time, it will make it easier for him to push the active attack, because the host will not be able to interfere with the attack for some time.

DNS poisoning

DNS poisoning means that the attacker corrupts the cache of a DNS server by replying to it with spoofed DNS reply packets, trying to get the server to send certain data to a victim who is requesting information from that server. Many servers maintain a trust relationship with other hosts, based on IP addresses or host names. The attacker will need a good understanding of the actual structure of the trust relationships between hosts to dusguise itself as one of the trusted hosts. Usually, the attacker analyzes some packets received from the server to get the necessary information. The attacker often needs to target a well-timed DoS attack at the name server as well. Protect yourself by using encrypted connections that are able to verify the identity of the hosts to which to connect.


Worms are often confused with viruses, but there is a clear difference between the two. Unlike viruses, worms do not need to infect a host program to live. Rather, they are specialized to spread as quickly as possible on network structures. The worms that appeared in the past, such as Ramen, Lion, or Adore, make use of well-known security holes in server programs like bind8 or lprNG. Protection against worms is relatively easy. Given that some time will elapse between the discovery of a security hole and the moment the worm hits your server, there is a good chance that an updated version of the affected program will be available on time. Of course, that is only useful if the administrator actually installs the security updates on the systems in question.

Some General Security Tips and Tricks

Information: To handle security competently, it is important to keep up with new developments and to stay informed about the latest security issues. One very good way to protect your systems against problems of all kinds is to get and install the updated packages recommended by security announcements as quickly as possible. SuSE security announcements are published on a mailing list to which you can subscribe by following the link The list is a first-hand source of information regarding updated packages and includes members of SuSE's security team among its active contributors.

The mailing list is a good place to discuss any security issues of interest. Subscribe to it under the URL as given above for is one of the best-known security mailing lists worldwide. We recommend reading this list, which receives between 15 and 20 postings per day. More information can be found at

The following is a list of rules which you may find useful in dealing with basic security concerns:

  • According to the rule of using the most restricive set of permissions possible for every job, avoid doing your regular jobs as SuSE @nohyphen root. This reduces the risk of getting a cuckoo egg or a virus and protects you from your own mistakes.

  • If possible, always try to use encrypted connections to work on a remote machine. Use ssh (secure shell) to replace telnet, ftp, rsh, and rlogin.

  • Avoid using authentication methods based on IP addresses alone.

  • Try to keep the most important network-related packages up-to-date and subscribe to the corresponding mailing lists to receive announcements on new versions of such programs (bind, sendmail, ssh, etc.). The same should apply to software relevant to local security.

  • Change the /etc/permissions file to optimize the permissions of files crucial to your system's security. If you remove the setuid bit from a program, it might well be that it cannot do its job anymore in the way it is supposed to. On the other hand, consider that, in most cases, the program will also have ceased to be a potential security risk. You might take a similar approach with world-writable directories and files.

  • Disable any network services you do not absolutely require for your server to work properly. This will make your system safer. Open ports, with the socket state LISTEN, can be found with the program netstat. As for the options, we suggest that you use netstat -ap or netstat -anp. The -p option allows you to see which process is occupying a port under which name.

    Compare the netstat results with those of a thorough port scan done from outside your host. An excellent program for this job is nmap, which not only checks out the ports of your machine, but also draws some conclusions as to which services are waiting behind them. However, port scanning may be interpreted as an aggressive act, so do not do this on a host without the explicit approval of the administrator. Finally, remember that it is important not only to scan TCP ports, but also UDP ports (options -sS and -sU).

  • To monitor the integrity of the files of your system in a reliable way, use the program tripwire, available on the SuSE Linux distribution. Encrypt the database created by tripwire to prevent someone from tampering with it. Furthermore, keep a backup of this database available outside your machine, stored on an external data medium not connected to it by a network link.

  • Take proper care when installing any third-party software. There have been cases where a hacker had built a trojan horse into the tar archive of a security software package, which was fortunately discovered very quickly. If you install a binary package, have no doubts about the site from which you downloaded it.

    Note that SuSE's RPM packages are gpg-signed. The key used by SuSE for signing reads as follows:

    ID:9C800ACA 2000-10-19 SuSE Package Signing Key <>

    Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA

    The command rpm -checksig package.rpm shows whether the checksum and the signature of an uninstalled package are correct. Find the key on the first CD of the distribution and on most key servers worldwide.

  • Check your backups of user and system files regularly. Consider that if you do not test whether the backup will work, it might actually be worthless.

  • Check your log files. Whenever possible, write a small script to search for suspicious entries. Admittedly, this is not exactly a trivial task. In the end, only you can know which entries are unusual and which are not.

  • Use tcp_wrapper to restrict access to the individual services running on your machine, so you have explicit control over which IP addresses can connect to a service. For further information regarding tcp_wrappers, consult the manual page of tcpd and hosts_access (man 8 tcpd, man hosts_access).

  • Use SuSEfirewall to enhance the security provided by tcpd (tcp_wrapper).

  • Design your security measures to be redundant: a message seen twice is much better than no message at all.

Using the Central Security Reporting Address

If you discover a security-related problem (please check the available update packages first), write an e-mail to Please include a detailed description of the problem and the version number of the package concerned. SuSE will try to send a reply as soon as possible. You are encouraged to pgp encrypt your e-mail messages. SuSE's pgp key is as follows:

ID:3D25D3D9 1999-03-06 SuSE Security Team <>

Key fingerprint = 73 5F 2E 99 DF DB 94 C4 8F 5A A3 AE AF 22 F2 D5

This key is also available for download from:

next up previous contents index
Next: Appendixes Up: Network Previous: Internet   Contents   Index
root 2003-11-05