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 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 section 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:
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.
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 are 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 to win the confidence of that person by using clever rhetoric. The victim could be led to reveal gradually 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 is only 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. Also secure the boot procedure, because there are some well-known key combinations that might provoke unusual behavior. Protect yourself against this by setting passwords for the BIOS and the boot loader.
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 must 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 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
root, who holds the supreme
power on the system.
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 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. This only provides more security 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 is not 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 that looks like your password when encrypted. 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
“tantalize” into “t@nt@1lz3”.
Replacing some letters of a word with similar looking numbers is not safe enough. Password cracking programs that 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 that 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”. In 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 is started by a boot loader, allowing you to
pass additional options to the booted kernel. Prevent others from using such
parameters during boot by setting an additional password in
/boot/grub/menu.lst (see Chapter 8, The Boot Loader). 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
permissions at system start-up.
As a general rule, always work with the most restrictive privileges
possible for a given task. For example, it is definitely not necessary
root to read
or write e-mail. If the mail program has a
bug, this bug could be exploited for an attack that acts 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 incorrect
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
root or, in
the case of configuration files, programs could use such files with
the permissions of
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.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 bit (programs with the setuser ID bit set do not run
with the permissions of the user that has launched it, but with the
permissions of the file owner, in most cases
root). An administrator can use the
/etc/permissions.local to add his own
To define which of the above files is used by SUSE's configuration
programs to set permissions accordingly, select
/etc/permissions or consult
the manual page of chmod
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 must make sure that his application interprets data in the correct way, without writing it into memory areas that are too small to hold it. 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 for a program to 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, especially if the program is being executed with special privileges (see Section 22.214.171.124, “File Permissions”).
Format string bugs work in a slightly different way, but again it is the user input that 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 126.96.36.199, “File Permissions”).
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 say, there are viruses that run on Linux. However, the viruses that are known were released by their authors as a proof of concept to prove that the technique works as intended. None of these viruses have been spotted in the wild so far.
Viruses cannot survive and spread without a host on which to live. In
this 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
root permissions, you would
increase the chance of the system being infected by a virus. In
contrast, if you follow the principle of using the lowest
possible privileges as mentioned above, chances of getting a virus are
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 that is started outside. The typical login procedure requiring a username and a password for user authentication is still a local security issue. In the particular case of logging in over a network, differentiate between the two 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. X, the windowing system of UNIX operating systems, can make use of this feature in an impressive way. With X, it is basically no problem to log in at a remote host and start a graphical program that is then sent over the network to be displayed on your computer.
When an X client should be displayed remotely using an X server, the
latter should protect the resource managed by it (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 should run. The program to control this is
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, this authentication
method is not described in more detail here, but you can learn about it
In the case of cookie-based access control, a character string is
generated that 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 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
.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 System security
mechanisms in the man page of Xsecurity
SSH (secure shell) can be used to encrypt a network connection completely 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 34.2, “SSH: Secure Network Operations”.
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 in Section 188.8.131.52, “Buffer Overflows and Format String 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
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 that
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 a denial of service (DoS) attack is to block a server program or even an entire system, something that 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 made with the sole purpose of making the service disappear. However, once a given service has become unavailable, communications could become vulnerable to 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. 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 need 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 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, usually 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
Many of the attacks mentioned are carried out in combination with a DoS. If an attacker sees an opportunity to bring down a certain host abruptly, even if only for a short time, it makes 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 hostnames. The attacker needs a good understanding of the actual structure of the trust relationships among hosts to disguise 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. Instead, 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 elapses 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 is available on time. That is only useful if the administrator actually installs the security updates on the systems in question.
To handle security competently, it is important to keep up with new developments and 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.novell.com/linux/security/securitysupport.html. The list firstname.lastname@example.org 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 email@example.com is a good place to discuss any security issues of interest. Subscribe to it on the same Web page.
firstname.lastname@example.org is one of the best-known security mailing lists worldwide. Reading this list, which receives between 15 and 20 postings per day, is recommended. More information can be found at http://www.securityfocus.com.
The following is a list of rules you may find useful in dealing with basic security concerns:
According to the rule of using the most restrictive set of
permissions possible for every job, avoid doing your regular jobs as
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. Using ssh (secure shell) to replace telnet, ftp, rsh, and rlogin should be standard practice.
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.
/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 intended way. 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 makes your system safer. Open
ports, with the socket state LISTEN, can be found with the program
netstat. As for the options, it
is recommended to use
-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
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.
SUSE's RPM packages are gpg-signed. The key used by SUSE for signing is:
ID:9C800ACA 2000-10-19 SUSE Package Signing Key <email@example.com>
Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA
The command rpm
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 works, 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.
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
tcp_wrapper, consult the
manual pages of tcpd and 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.
If you discover a security-related problem (please check the available update packages first), write an e-mail to firstname.lastname@example.org. 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:
ID:3D25D3D9 1999-03-06 SUSE Security Team <email@example.com> 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.novell.com/linux/security/securitysupport.html.