ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 1. Security and Confidentiality</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="book.security.html" title="Security Guide"><link rel="prev" href="preface.security.html" title="About This Guide"><link rel="next" href="part.auth.html" title="Part I. Authentication"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="About This Guide" href="preface.security.html"><span>◀</span></a> <a accesskey="n" title="Part I. Authentication" href="part.auth.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 1. Security and Confidentiality"><div class="titlepage"><div><div><h2 class="title"><a name="cha.security"></a>Chapter 1. Security and Confidentiality<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.security">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.security.html#sec.security.general.overview">1.1. Local Security and Network Security</a></span></dt><dt><span class="sect1"><a href="cha.security.html#sec.security.general.tips">1.2. Some General Security Tips and Tricks</a></span></dt><dt><span class="sect1"><a href="cha.security.html#sec.security.general.report">1.3. Using the Central Security Reporting Address</a></span></dt></dl></div><a class="indexterm" name="idx.security"></a><p>
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.
</p><p>
With the multiuser capability, the data of different users must be stored
separately, and 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).
</p><p>
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 in the case that someone has gained
unauthorized access and tampered with files.
</p><div class="sect1" title="1.1. Local Security and Network Security"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.general.overview"></a>1.1. Local Security and Network Security<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview">¶</a></span></h2></div></div></div><p>
There are several ways of accessing data:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
personal communication with people who have the desired information or
access to the data on a computer
</p></li><li class="listitem" style="list-style-type: disc"><p>
directly through physical access from the console of a computer
</p></li><li class="listitem" style="list-style-type: disc"><p>
over a serial line
</p></li><li class="listitem" style="list-style-type: disc"><p>
using a network link
</p></li></ul></div><p>
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 your personal
data to an anonymous user.
</p><a class="indexterm" name="id521643"></a><p>
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. The victim could be led to reveal gradually more information,
maybe without even being aware of it. Among hackers, this is called
<span class="emphasis"><em>social engineering</em></span>. 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.
</p><a class="indexterm" name="id521624"></a><a class="indexterm" name="id566244"></a><p>
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 cables or power cords. 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. <a class="indexterm" name="id566230"></a>
</p><p>
<a class="indexterm" name="id566215"></a> Serial terminals connected to serial ports are still used in
many places. Unlike network interfaces, they do not rely on network
protocols 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 any data being transferred
thusly. What can be achieved with a printer can also be accomplished in
other ways, depending on the effort that goes into the attack.
</p><p>
Reading a file locally on a host requires additional 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.
</p><div class="sect2" title="1.1.1. Local Security"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.general.overview.local"></a>1.1.1. Local Security<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.local">¶</a></span></h3></div></div></div><a class="indexterm" name="idx.security_local"></a><p>
Local security starts with the physical environment at the location in
which 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
<code class="systemitem">root</code>, who holds system
administration privileges.
<code class="systemitem">root</code> can take on the identity
of any other local user and read any locally-stored file without being
prompted for the password.
</p><div class="sect3" title="1.1.1.1. Passwords"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.local.passwords"></a>1.1.1.1. Passwords<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.local.passwords">¶</a></span></h4></div></div></div><a class="indexterm" name="idx.security_passwords"></a><p>
On a Linux system, passwords are not stored as plain text and the
entered text string 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.
</p><p>
This is actually achieved by a special kind of algorithm, also called
<span class="emphasis"><em>trapdoor algorithm</em></span>, 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.
</p><p>
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
(<code class="filename">/etc/shadow</code> 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 <span class="quote">“<span class="quote">translate</span>”</span> a password like
<span class="quote">“<span class="quote">tantalize</span>”</span> into <span class="quote">“<span class="quote">t@nt@1lz3</span>”</span>.
</p><p>
Replacing some letters of a word with similar looking numbers (like
writing the password <span class="quote">“<span class="quote">tantalize</span>”</span> as
<span class="quote">“<span class="quote">t@nt@1lz3</span>”</span> ) is not sufficient. 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 <span class="quote">“<span class="quote">The Name of the Rose</span>”</span> by Umberto Eco. This would
give the following safe password: <span class="quote">“<span class="quote">TNotRbUE9</span>”</span>. In
contrast, passwords like <span class="quote">“<span class="quote">beerbuddy</span>”</span> or
<span class="quote">“<span class="quote">jasmine76</span>”</span> are easily guessed even by someone who has
only some casual knowledge about you.
</p><a class="indexterm" name="id378024"></a></div><div class="sect3" title="1.1.1.2. The Boot Procedure"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.local.boot"></a>1.1.1.2. The Boot Procedure<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.local.boot">¶</a></span></h4></div></div></div><a class="indexterm" name="idx.security_booting"></a><p>
Configure your system so it cannot be booted from a floppy or from a
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 <code class="filename">/boot/grub/menu.lst</code> (see
Chapter <i>The Boot Loader GRUB</i> (↑Reference)). This is crucial to your system's security.
Not only does the kernel itself run with
<code class="systemitem">root</code> permissions, but it is
also the first authority to grant
<code class="systemitem">root</code> permissions at system
start-up.
</p><a class="indexterm" name="id341173"></a></div><div class="sect3" title="1.1.1.3. File Permissions"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.local.permissions"></a>1.1.1.3. File Permissions<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.local.permissions">¶</a></span></h4></div></div></div><a class="indexterm" name="idx.security_permissions"></a><p>
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 <code class="systemitem">root</code> 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.
</p><p>
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
<code class="option">-l</code> option with the command <span class="command"><strong>ls</strong></span> 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 <code class="systemitem">root</code> or,
in the case of configuration files, programs could use such files with
the permissions of <code class="systemitem">root</code>. This
significantly increases the possibilities of an attack. Attacks like
these 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.
</p><p>
An openSUSE® system includes the files
<code class="filename">permissions</code>,
<code class="filename">permissions.easy</code>,
<code class="filename">permissions.secure</code>, and
<code class="filename">permissions.paranoid</code>, all in the directory
<code class="filename">/etc</code>. 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
<code class="systemitem">root</code>). An administrator
can use the file <code class="filename">/etc/permissions.local</code> to add his
own settings.
</p><p>
To define which of the above files is used by openSUSE's
configuration programs to set permissions, select <span class="guimenu">Local
Security</span> in the <span class="guimenu">Security and Users</span> section
of YaST. To learn more about the topic, read the comments in
<code class="filename">/etc/permissions</code> or consult the manual page of
<span class="command"><strong>chmod</strong></span>
(<span class="command"><strong>man</strong></span> <code class="option">chmod</code>).
</p><a class="indexterm" name="id385670"></a></div><div class="sect3" title="1.1.1.4. Buffer Overflows and Format String Bugs"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.local.bugs"></a>1.1.1.4. Buffer Overflows and Format String Bugs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.local.bugs">¶</a></span></h4></div></div></div><a class="indexterm" name="id325177"></a><p>
Special care must be taken whenever a program needs to process data
that 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
interfaces defined for that purpose.
</p><p>
A <span class="emphasis"><em>buffer overflow</em></span> 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 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
<a class="xref" href="cha.security.html#sec.security.general.overview.local.permissions" title="1.1.1.3. File Permissions">Section 1.1.1.3, “File Permissions”</a>).
</p><p>
<span class="emphasis"><em>Format string bugs</em></span> 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
<a class="xref" href="cha.security.html#sec.security.general.overview.local.permissions" title="1.1.1.3. File Permissions">Section 1.1.1.3, “File Permissions”</a>).
</p><p>
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.
</p></div><div class="sect3" title="1.1.1.5. Viruses"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.local.virus"></a>1.1.1.5. Viruses<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.local.virus">¶</a></span></h4></div></div></div><a class="indexterm" name="id327412"></a><p>
Contrary to popular opinion, there are viruses that run on Linux.
However, the viruses that are known were released by their authors as a
<span class="emphasis"><em>proof of concept</em></span> that the technique works as
intended. None of these viruses have been spotted <span class="emphasis"><em>in the
wild</em></span> so far.
</p><p>
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 (this is especially
important with system files). Therefore, if you did your normal work
with <code class="systemitem">root</code> 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.
</p><p>
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
design.
</p><p>
Viruses should not be confused with worms, which belong entirely to the
world of networks. Worms do not need a host to spread.
</p><a class="indexterm" name="id310003"></a></div></div><div class="sect2" title="1.1.2. Network Security"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.general.overview.network"></a>1.1.2. Network Security<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.network">¶</a></span></h3></div></div></div><a class="indexterm" name="idx.security_network"></a><p>
Network security is important for protecting from an attack that is
started outside the network. 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.
</p><div class="sect3" title="1.1.2.1. X Window System and X Authentication"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.network.x11"></a>1.1.2.1. X Window System and X Authentication<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.network.x11">¶</a></span></h4></div></div></div><a class="indexterm" name="id389045"></a><a class="indexterm" name="id310134"></a><p>
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.
</p><p>
When an X client needs to 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 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
<span class="command"><strong>man</strong></span> <code class="option">xhost</code>.
</p><p>
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 is stored on login
in the file <code class="filename">.Xauthority</code> 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 <code class="filename">.Xauthority</code> can be
examined by the user with the tool <span class="command"><strong>xauth</strong></span>. If you
rename <code class="filename">.Xauthority</code>, or if you delete the file from
your home directory by accident, you would not be able to open any new
windows or X clients.
</p><p>
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
<a class="xref" href="cha.ssh.html" title="Chapter 13. SSH: Secure Network Operations">Chapter 13, <i>SSH: Secure Network Operations</i></a>.
</p><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
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
perpetrate various actions (reading, or sniffing, your keyboard input,
for instance).
</p></td></tr></table></div></div><div class="sect3" title="1.1.2.2. Buffer Overflows and Format String Bugs"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.network.bugs"></a>1.1.2.2. Buffer Overflows and Format String Bugs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.network.bugs">¶</a></span></h4></div></div></div><a class="indexterm" name="id387502"></a><p>
As discussed in
<a class="xref" href="cha.security.html#sec.security.general.overview.local.bugs" title="1.1.1.4. Buffer Overflows and Format String Bugs">Section 1.1.1.4, “Buffer Overflows and Format String Bugs”</a>, buffer
overflows and format string bugs should be classified as issues
applying to 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
<code class="systemitem">root</code> permissions. Even if
that is not the case, an attacker could use the bug to gain access to
an unprivileged local account to exploit other vulnerabilities that
might exist on the system.
</p><p>
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 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.
</p></div><div class="sect3" title="1.1.2.3. Denial of Service"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.network.dos"></a>1.1.2.3. Denial of Service<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.network.dos">¶</a></span></h4></div></div></div><a class="indexterm" name="idx.security_attacks"></a><p>
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 <span class="emphasis"><em>man-in-the-middle attacks</em></span>
(sniffing, TCP connection hijacking, spoofing) and DNS poisoning.
</p></div><div class="sect3" title="1.1.2.4. Man in the Middle: Sniffing, Hijacking, Spoofing"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.network.mitm"></a>1.1.2.4. Man in the Middle: Sniffing, Hijacking, Spoofing<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.network.mitm">¶</a></span></h4></div></div></div><p>
In general, any remote attack performed by an attacker who puts himself
between the communicating hosts is called a <span class="emphasis"><em>man-in-the-middle
attack</em></span>. 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.
</p><p>
The simplest form of a man-in-the-middle attack is called
<span class="emphasis"><em>sniffer</em></span> (the attacker is <span class="quote">“<span class="quote">just</span>”</span>
listening to the network traffic passing by). As a more complex attack,
the <span class="quote">“<span class="quote">man in the middle</span>”</span> 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.
</p><p>
<span class="emphasis"><em>Spoofing</em></span> 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
(<code class="systemitem">root</code>)).
</p><p>
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.
</p></div><div class="sect3" title="1.1.2.5. DNS Poisoning"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.network.dns"></a>1.1.2.5. DNS Poisoning<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.network.dns">¶</a></span></h4></div></div></div><a class="indexterm" name="id570819"></a><a class="indexterm" name="id337753"></a><p>
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.
</p></div><div class="sect3" title="1.1.2.6. Worms"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.general.overview.network.worms"></a>1.1.2.6. Worms<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.overview.network.worms">¶</a></span></h4></div></div></div><a class="indexterm" name="id384213"></a><p>
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.
<a class="indexterm" name="id321323"></a>
<a class="indexterm" name="id328938"></a>
</p></div></div></div><div class="sect1" title="1.2. Some General Security Tips and Tricks"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.general.tips"></a>1.2. Some General Security Tips and Tricks<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.tips">¶</a></span></h2></div></div></div><a class="indexterm" name="id335782"></a><p>
To handle security competently, it is important to observe some
recommendations. You may find the following list of rules useful in
dealing with basic security concerns:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
Get and install the updated packages recommended by security
announcements as quickly as possible.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Stay informed about the latest security issues:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
<a class="ulink" href="opensuse-security-announce@opensuse.org" target="_top">opensuse-security-announce@opensuse.org</a> is the SUSE
mailinglist for security announcements. It is a first-hand source of
information regarding updated packages and includes members of
SUSE's security team among its active contributors. You can
subscribe to this list on page
<a class="ulink" href="http://en.opensuse.org/Communicate/Mailinglists" target="_top">http://en.opensuse.org/Communicate/Mailinglists</a>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Find SUSE security advisories as a news feed at
<a class="ulink" href="http://www.novell.com/linux/security/suse_security.xml" target="_top">http://www.novell.com/linux/security/suse_security.xml</a>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
<a class="ulink" href="bugtraq@securityfocus.com" target="_top">bugtraq@securityfocus.com</a> 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 <a class="ulink" href="http://www.securityfocus.com" target="_top">http://www.securityfocus.com</a>.
</p></li></ul></div></li><li class="listitem" style="list-style-type: disc"><p>
Discuss any security issues of interest on our mailinglist
<a class="ulink" href="opensuse-security@opensuse.org" target="_top">opensuse-security@opensuse.org</a>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
According to the rule of using the most restrictive set of permissions
possible for every job, avoid doing your regular jobs as
<code class="systemitem">root</code>. This reduces the risk
of getting a cuckoo egg or a virus and protects you from your own
mistakes.
</p></li><li class="listitem" style="list-style-type: disc"><p>
If possible, always try to use encrypted connections to work on a
remote machine. Using <span class="command"><strong>ssh</strong></span> (secure shell) to replace
<span class="command"><strong>telnet</strong></span>, <span class="command"><strong>ftp</strong></span>,
<span class="command"><strong>rsh</strong></span>, and <span class="command"><strong>rlogin</strong></span> should be
standard practice.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Avoid using authentication methods based solely on IP addresses.
</p></li><li class="listitem" style="list-style-type: disc"><p>
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, postfix, ssh, etc.). The same
should apply to software relevant to local security.
</p></li><li class="listitem" style="list-style-type: disc"><a class="indexterm" name="id415795"></a><p>
Change the <code class="filename">/etc/permissions</code> 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.
</p></li><li class="listitem" style="list-style-type: disc"><p>
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
<code class="literal">netstat</code>. As for the options, it is recommended to
use <span class="command"><strong>netstat</strong></span> <code class="option">-ap</code> or
<span class="command"><strong>netstat</strong></span> <code class="option">-anp</code>. The
<code class="option">-p</code> option allows you to see which process is occupying
a port under which name.
</p><p>
Compare the <code class="literal">netstat</code> results with those of a thorough
port scan done from outside your host. An excellent program for this
job is <code class="literal">nmap</code>, 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
<code class="option">-sS</code> and <code class="option">-sU</code>).
</p></li><li class="listitem" style="list-style-type: disc"><p>
To monitor the integrity of the files of your system in a reliable way,
use the program <code class="literal">AIDE</code> (Advanced Intrusion Detection
Environment), available on openSUSE. Encrypt the database created
by AIDE 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.
</p></li><li class="listitem" style="list-style-type: disc"><p>
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.
</p><a class="indexterm" name="id327183"></a><a class="indexterm" name="id310150"></a><p>
SUSE's RPM packages are gpg-signed. The key used by SUSE for
signing is:
</p><pre class="screen">ID:9C800ACA 2000-10-19 SUSE Package Signing Key <build@suse.de>
Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA</pre><p>
The command <span class="command"><strong>rpm</strong></span> <code class="option">--checksig
package.rpm</code> 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.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Check backups of user and system files regularly. Consider that if you
do not test whether the backup works, it might actually be worthless.
</p></li><li class="listitem" style="list-style-type: disc"><p>
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.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Use <code class="literal">tcp_wrapper</code> to restrict access to the individual
services running on your machine, so you have explicit control over
which IP addresses can connect to a service. For further information
regarding <code class="literal">tcp_wrapper</code>, consult the manual pages of
tcpd and hosts_access (<span class="command"><strong>man</strong></span> <code class="option">8
tcpd</code>,
<span class="command"><strong>man</strong></span> <code class="option">hosts_access</code>).
</p><a class="indexterm" name="id325961"></a></li><li class="listitem" style="list-style-type: disc"><p>
Use SuSEfirewall to enhance the security provided by
<code class="literal">tcpd</code> (<code class="literal">tcp_wrapper</code>).
</p></li><li class="listitem" style="list-style-type: disc"><p>
Design your security measures to be redundant: a message seen twice is
much better than no message at all.
</p></li><li class="listitem" style="list-style-type: disc"><p>
If you use suspend to disk, consider configuring the suspend image
encryption using the <span class="command"><strong>configure-suspend-encryption.sh</strong></span>
script. The program creates the key, copies it to
<code class="filename">/etc/suspend.key</code>, and modifies
<code class="filename">/etc/suspend.conf</code> to use encryption for suspend
images.
</p></li></ul></div></div><div class="sect1" title="1.3. Using the Central Security Reporting Address"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.general.report"></a>1.3. Using the Central Security Reporting Address<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.general.report">¶</a></span></h2></div></div></div><a class="indexterm" name="id336545"></a><p>
If you discover a security-related problem (please check the available
update packages first), write an e-mail to
<a class="ulink" href="security@suse.de" target="_top">security@suse.de</a>. 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:
</p><pre class="screen">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</pre><p>
This key is also available for download from
<a class="ulink" href="http://www.novell.com/linux/security/securitysupport.html" target="_top">http://www.novell.com/linux/security/securitysupport.html</a>.
</p><a class="indexterm" name="id336571"></a></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="About This Guide" href="preface.security.html"><span>◀</span></a> <a accesskey="n" title="Part I. Authentication" href="part.auth.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018