38.1 Local Security and Network Security
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.
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
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.
38.1.1 Local Security
Local security starts with the physical environment in the location
where the computer is running. Set up your machine in a place where
security is in line with your expectations and needs. The main goal of
local security is to keep users separate from each other, so 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. 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 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
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
jasmine76 are easily guessed
even by someone who has only some casual knowledge about you.
38.1.3 The Boot Procedure
Configure your system so it cannot be booted from a floppy or from CD,
either by removing the drives entirely or by setting a BIOS password and
configuring the BIOS to allow booting from a hard disk only. Normally, a
Linux system 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
Section 15.0, 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
root permissions at system
38.1.4 File Permissions
As a general rule, always work with the most restrictive privileges
possible for a given task. For example, it is definitely not necessary
to be 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 all files included in the openSUSE 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 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 openSUSE® 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 file /etc/permissions.local to add his own
To define which of the above files is used by openSUSE's
configuration programs to set permissions accordingly, select
/etc/permissions or consult the
manual page of chmod
in the section of YaST. To learn more about the topic, read
the comments in
38.1.5 Buffer Overflows and Format String Bugs
Special care must be taken whenever a program is supposed to process
data that can or could be changed by a user, but this is more of an
issue for the programmer of an application than for regular users. The
programmer 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 38.1.4, 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 38.1.4, 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 slim.
Apart from that, you should never rush into executing a program from
some Internet site that you do not really know. openSUSE'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
Viruses should not be confused with worms, which belong to the world of
networks entirely. Worms do not need a host to spread.
38.1.7 Network Security
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.
38.1.8 X Window System and X Authentication
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 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, this authentication method is
not described in more detail here, but you can learn about it with
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 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.
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.0, 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.
38.1.9 Buffer Overflows and Format String Bugs
As discussed in Section 38.1.5, 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 (openSUSE 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.
38.1.10 Denial of Service
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.
38.1.11 Man in the Middle: Sniffing, Hijacking, Spoofing
In general, any remote attack performed by an attacker who puts himself
between the communicating hosts is called a man-in-the-middle
attack. What almost all types of man-in-the-middle attacks
have in common is that the victim is usually not aware that there is
something happening. There are many possible variants, for example, the
attacker could pick up a connection request and forward that to the
target machine. Now the victim has unwittingly established a connection
with the wrong host, because the other end is posing as the legitimate
The simplest form of a man-in-the-middle attack is called
sniffer—the attacker is
listening to the network traffic passing by. As a more complex attack,
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 by the superuser
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.
38.1.12 DNS Poisoning
DNS poisoning means that the attacker corrupts the cache of a DNS server
by replying to it with spoofed DNS reply packets, trying to get the
server to send certain data to a victim who is requesting information
from that server. Many servers maintain a trust relationship with other
hosts, based on IP addresses or 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.