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.
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.
Caution
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 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.
Note
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.
``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.
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.
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.
172.20.0.0/16 172.30.4.2 means that all hosts with an IP address beginning with 172.20.x.x and the host with the IP address 172.30.4.2 are allowed to pass information through the firewall.
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 129.27.43.9:1427 195.58.178.210:23 L=60 S=0x00 I=36981 F=0x4000 T=59 SYN (#119)
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:
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.
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.
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 .
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 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.
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.
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.
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:
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 id_rsa.pub.
Use ssh-keygen -p -t rsa or ssh-keygen -p -t dsa to change your old passphrase.
Copy the public key component (id_rsa.pub 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.
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.
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:
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.
Note
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.
The following glossary will help you cope with Kerberos terminology.
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.
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.
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.
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:
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 http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3/doc/krb5-user.html.
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/heimdal.info. It is also available at the project's home page at http://www.pdc.kth.se/heimdal/
This is the official site of the MIT Kerberos is http://web.mit.edu/kerberos/www/. There, find links to any other relevant resource concerning Kerberos.
A ``classical'' dialog pointing out the principles of Kerberos is available at http://web.mit.edu/kerberos/www/dialogue.html. It is a less technical but still comprehensive read.
The paper at :
ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PSgives 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:
http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3/doc/krb5-user.html
http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3/doc/krb5-install.html
http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3/doc/krb5-admin.html
The official Kerberos FAQ is available at http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html.
The book Kerberos -- A Network Authentication System by Brian Tung (ISBN 0-201-37924-4) offers extensive information.
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).
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 foobar.com 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.
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:
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.
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.
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.
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.
This section covers the initial installation of the KDC, including creation of an administrative principal.
Before you can start, install the Kerberos software. On the KDC, install the packages heimdal, heimdal-lib, and heimdal-tools:
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>
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> 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 * default@SAMPLE.COM kadmin/admin@SAMPLE.COM kadmin/hprop@SAMPLE.COM kadmin/changepw@SAMPLE.COM krbtgt/SAMPLE.COM@SAMPLE.COM changepw/kerberos@SAMPLE.COM
This shows that there are now a number of principals in the database. All of these are for internal use by Kerberos.
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> 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.
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:
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.
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.
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 kdc.sample.com is the host name of the KDC):
[libdefaults]
default_realm = SAMPLE.COM
[realms]
SAMPLE.COM = {
kdc = kdc.sample.com
kpasswd_server = kdc.sample.com
admin_server = kdc.sample.com
}
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
www.foobar.com = SAMPLE.COM
This tells the library that all hosts in the sample.com DNS domains are in the SAMPLE.COM Kerberos realm. In addition, one external host named www.foobar.com should also be considered a member of the SAMPLE.COM realm.
DNS-based Kerberos configuration makes heavy use of SRV records (see (RFC2052) A DNS RR for specifying the location of services at http://www.ietf.org). 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:
_kerberos._udp.SAMPLE.COM. IN SRV 0 0 88 kdc.sample.com. _kerberos._tcp.SAMPLE.COM. IN SRV 0 0 88 kdc.sample.com.
_kpasswd._udp.SAMPLE.COM. IN SRV 0 0 464 kdc.sample.com.Because kpasswdd does not support TCP, there should be no _tcp record.
_kerberos-adm._tcp.SAMPLE.COM. IN SRV 0 0 749 kdc.sample.com.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 sample.com DNS domain. This can be done by attaching a TXT record to _keberos.hostname, as shown here:
_keberos.www.foobar.com. IN TXT "SAMPLE.COM"
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:
[libdefaults]
clockskew = 120
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.
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> /usr/sbin/kadmin 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.
Here is a brief list of kadmin commands. For more information, refer to [8]kadmin.
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.
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 machine.sample.com, enter the following commands during your kadmin session:
kinit newbie/admin newbie/admin@SAMPLE.COM's Password: <type password> kadmin add -r host/machine.sample.com 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:
When completed, make sure you destroy the admin ticket obtained via kinit above with kdestroy.
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.
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 zamboni.sample.com Have a lot of fun...
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/earth.sample.com and add that to the keytab:
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
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.
You should now be able to use tools, such as ldapsearch, with Kerberos authentication automatically.
SASL/GSSAPI authentication started SASL SSF: 56 SASL installing layers [...] # newbie, People, suse.de 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.
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:
saslRegexp
uid=(.*),cn=GSSAPI,cn=auth
uid=$1,ou=people,dc=example,dc=com
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.
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.
There are several ways of accessing data:
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 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.
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).
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, permissions.secure, 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).
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 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.
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.
Caution
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.
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.
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.
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 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.
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 http://www.suse.de/security. The list suse-security-announce@suse.de 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 suse-security@suse.de is a good place to discuss any security issues of interest. Subscribe to it under the URL as given above for suse-security-announce@suse.de.
bugtraq@securityfocus.com 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 http://www.securityfocus.com.
The following is a list of rules which you may find useful in dealing with basic security concerns:
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).
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 <build@suse.de>
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.
If you discover a security-related problem (please check the available update packages first), write an e-mail to security@suse.de. 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 <security@suse.de>
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: http://www.suse.de/security