Tải bản đầy đủ (.pdf) (22 trang)

Managing Ubuntu Server Security

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (128.46 KB, 22 trang )

281
CHAPTER 11
Managing Ubuntu Server
Security
Configuring Cryptography and
AppArmor
U
buntu Server offers some powerful security options. In this chapter you’ll learn how
to set up two important security solutions. First, you’ll learn how to create and manage
a PKI environment and certificate authority, using OpenSSL cryptography. Next, you’ll
be introduced to AppArmor, a new feature in Ubuntu Server 8.04 that helps you to secure
individual applications.
Managing Cryptography
In the age of the Internet, cryptography has become increasingly important. When data is
sent across insecure networks, you need to make sure the data is protected. When com-
municating with a host on the other side of the world, you need to make sure that the
host really is the host you think it is (authentication). To do this, cryptography can help.
In this section you will learn how to use OpenSSL to implement a secure cryptographic
infrastructure. The following subjects are discussed:
 s )NTRODUCTIONTO33,
 s 0UBLICANDPRIVATEKEYS
 s 4HENEEDFORACERTIFICATEAUTHORITY
 s #REATINGACERTIFICATEAUTHORITYANDSERVERCERTIFICATES
CHAPTER 11
N
MANAGING UBUNTU SERVER SECURITY
282
Introduction to SSL
Before Netscape invented the Secure Sockets Layer (SSL) protocol in 1994, there was no
good way to protect data against the eyes of interceptors when the data traveled across
the Internet. With SSL, data can be encrypted and clients and servers can be authenti-


cated using digital certificates. These digital certificates are based on the X.509 standard
and contain not only the public key of any party on the Internet, but also a digital signa-
ture that guarantees the authenticity of that public key.
Netscape wanted SSL to become an Internet standard, so it released enough infor-
mation to enable others to create SSL libraries as well. The OpenSSL suite that is used in
Linux environments is a direct result of that. In 1999, SSL’s successor was introduced,
Transport Layer Security (TLS). The only fundamental difference between SSL and TLS is
that TLS is standardized by the Internet Engineering Task Force (IETF).
Public and Private Keys
SSL works with public/private key pairs. These can be used for two purposes: to prove
identity and to encrypt messages. In an SSL environment, every host must have its own
public/private key pair.
As an example of how SSL works, imagine that Linda wants to send an encrypted
e-mail message to Kylie. To send an encrypted message, a user always needs the public
key of the user to whom they want to send the encrypted message, so Linda first needs to
get Kylie’s public key. To make sure that everyone has easy access to a copy of her public
key, Kylie can, for example, publish her public key on a web site, put it in an LDAP Direc-
tory server, or attach it to every e-mail she sends out. After Linda has obtained Kylie’s
public key, she can use it to encrypt the e-mail message that she subsequently sends to
Kylie. Because Kylie’s public key is directly related to the private key that only Kylie has
access to, only Kylie, using her private key, is able to decrypt the message.
Public/private key pairs can also be used to establish identity. An example of this
is Secure Shell (SSH) key- based authentication. (SSH is covered in my book Beginning
Ubuntu LTS Server Administration, Second Edition, also published by Apress in 2008.) In
such a scenario, the user who wants to authenticate makes sure that a copy of his public
key is stored on the server on which he wants to authenticate. Next, on authentication,
the server sends a random message to the user asking him to sign it with his private key.
The client then sends the signed data to the sever and the server decrypts the data with
the client’s public key. If the decrypted data matches the previously sent data, the client is
authenticated, because he has proven his identity.

CHAPTER 11
N
MANAGING UBUNTU SERVER SECURITY
283
The Need for a Certificate Authority
The scenario described in the preceding section is realistic and works well, but there is
one problem: when Linda receives Kylie’s public key, how can she be sure that it is Kylie’s
public key and not the public key of someone pretending to be Kylie? That’s where the
CERTIFICATEAUTHORITY#!COMESIN!#!GUARANTEESTHEAUTHENTICITYOFPUBLICKEYSOF
users and servers. It does so by signing this public key with its own private key. The result
of this is a public key certificate in which the public key of the user is present, together
WITHTHESIGNATUREOFTHE#!4HEUSERAPPLICATIONWHICHSHOULDHAVEACOPYOFTHEPUBLIC
KEYOFTHE#!CANVERIFYAUTOMATICALLYTHATTHESIGNATUREISVALIDANDTHEREFORECANUSE
this guaranteed public key certificate without consulting the user. If on the other hand
ACERTIFICATEISSIGNEDBYA#!OFWHICHTHEPUBLICKEYISUNKNOWNONTHELOCALHOSTTHE
user application notifies the user about the issue and allows the user to decide what to do
with that certificate. Of course, the user can decide to trust that the public key in the cer-
tificate is authentic, but there is no way to guarantee that.
4HEMAINPURPOSEOFA#!ISTOGUARANTEETHEAUTHENTICITYOFAPUBLICKEYBUTWHOIN
THISCASEISTHERETOGUARANTEETHEAUTHENTICITYOFTHE#!4HISISWHERETHETRUSTEDROOT
COMESIN'ENERALLYSPEAKINGTHEREARETWODIFFERENTKINDSOF#!S
sLocal CAs#!STHATrun within a company and are used to create certificates for
keys of individual servers.
sTrusted root CAs#!Sthat are trusted by everyone and used to create keys for
OTHER#!S)NOTHERWORDSTHETRUSTEDROOTISA#!THATGUARANTEESTHEAUTHENTICITY
OFOTHER#!S
The reason the trusted root is trusted is that most applications already have the pub-
LICKEYOFSUCHATRUSTEDROOT#!BYDEFAULT4HEREFORETHEAPPLICATIONSWILLAUTOMATICALLY
accept the certificate signed by such a trusted root. It is, however, not necessary for every
USERTOGOTOTHETRUSTEDROOTDIRECTLYWITHINACOMPANYYOUCANCREATEYOUROWN#!

ANDCHOOSEWHETHERORNOTTOCREATEACERTIFICATEFORTHAT#!)FYOUWANTACERTIFICATETHAT
guarantees the authenticity of the public key in your certificate, you need to get it signed
by a trusted root instance. VeriSign is a well- known example of a company that can do
that for you. By using a trusted root, a chain of trust is created.
In a chain of trust, the certificate of the end user is signed by your own in- company
#!4HECERTIFICATEOFTHIS#!INTURNISSIGNEDBYATRUSTEDROOTSUCHAS6ERI3IGNORIFTHE
certificate is for use within your company only, by a trusted root that you have created for
your company. When a user receives this certificate, she will not be able to verify the cer-
TIFICATEOFTHE#!THATSIGNEDTHECERTIFICATEBUTBECAUSETHISCERTIFICATEINTURNISSIGNED
by a trusted root that is well known, an encrypted session can be established without
problems. The bottom line is that when a certificate is signed by a trusted root, it is safe.
CHAPTER 11
N
MANAGING UBUNTU SERVER SECURITY
284
!SACOMPANYYOUCANCHOOSETOSIGNEVERYCERTIFICATETHATISUSEDBYANEXTERNAL#!
BUTTHISISEXPENSIVE!CHEAPERSOLUTIONISTOCREATEYOUROWN#!WHICHINTURNHASITS
CERTIFICATESIGNEDBYANEXTERNAL#!4HATWAYYOUHAVEACERTIFICATETHATISTRUSTEDBYALL
external parties. If trust with external parties is not a requirement, as an alternative, you
CANCHOOSETOCREATEA#!WITHASELFSIGNEDCERTIFICATE/FCOURSETHISSOLUTIONISNOTAS
good as a solution in which trust is guaranteed by an external party, but if you have the
option to manage within your network all workstations that work with this certificate, the
guarantee of an external party isn’t necessary. Just copy the public key certificate of your
#!TOALLTHESEWORKSTATIONSANDITWILLWORKANYWAY)NTHENEXTSECTIONYOUWILLLEARN
HOWTOSETUPYOUROWN#!ANDTHENCREATECERTIFICATES
N
Tip
If someone is able to steal the private key from your CA, all keys signed by that CA are compromised.
Therefore, you should make sure the private key cannot be stolen. A good method to ensure that does not
happen is to create a dedicated CA and isolate it from the network. The CA only needs to sign public keys,

and it doesn’t need a network connection to do so.
Creating a Certificate Authority and Server Certificates
To CREATEA#!ANDCERTIFICATESON5BUNTU3ERVERYOUCANUSETHE
klajooh
command.
In this section you’ll learn how to use the
klajooh
command to create a certificate and
ASELFSIGNED#!"ECAUSETHESELFSIGNED#!ISTHEHIGHESTLEVELINTHE#!HIERARCHYINTHIS
EXAMPLEITWILLBEAROOT#!
The following steps explain how to proceed:
1. Decide where you want to create the directory structure in which you want to
PUTTHE#!4HISSHOULDBEADIRECTORYSTRUCTURETHATCANTBEACCESSEDBYOTHER
users. The home directory of the user
nkkp
, for example, might be a good location,
because no ordinary users have access to this directory. From the directory of your
choice, start with
ig`ennkkp)?=
TOCREATEASUBDIRECTORYINWHICHTHE#!WILLSTORE
its files.
2. Next, some subdirectories must be created in this
nkkp)?=
directory. The names of
these subdirectories are predefined in the configuration file
+ap_+ooh+klajooh*_jb
,
so don’t try anything creative unless you are willing to change all settings in this
configuration file as well. The command
ig`en_anpojas_anpolner]pa_nh

creates
these subdirectories for you. The following list describes the purpose of each of
these subdirectories:
CHAPTER 11
N
MANAGING UBUNTU SERVER SECURITY
285
s
_anpo
: Stores all signed public key certificates. This directory can be publicly
accessible.
s
jas_anpo
: Stores all new certificates that haven’t been signed yet.
s
lner]pa
: Stores the private key of your server. Protect it like the crown jewels!
The least you should do is give this directory permission mode 700 (
_dik`3,,
lner]pa
).
s
_nh
3TORES#ERTIFICATE2EVOCATION,ISTSIFANYARENEEDEDINYOURENVIRONMENT
3. To make creating the certificate FORTHEROOT#!ABITEASIEROPENTHECONFIGURA-
tion file
+ap_+ooh+klajooh*_jb
. In this file you will find some default settings that
AREUSEDWHENYOUCREATENEWCERTIFICATES2EADTHEFILEANDMODIFYALLSETTINGSAS
required. You at least need to make sure that all directory paths are accurate, by

modifying the
DKIA
and
`en
variables. Also, it is a good idea to set the names of the
certificates to the correct value. Listing 11-1 shows an example of what this should
look like. All nonessential parameters have been omitted from the listing.
Listing 11-1. Some Important Settings from openssl.cnf
DKIA9+nkkp+nkkp)?=
`en9+nkkp+nkkp)?=
***
_anpebe_]pa9 `en+_]_anp*lai
***
lner]pa[gau9 `en+lner]pa+lnergau*lai
***
4. Now that you have properly tuned the configuration file, you can create
ASELFSIGNEDCERTIFICATEFORTHEROOT#!4HEFOLLOWINGCOMMANDCREATESTHECER
TIFICATEWITHABIT23!KEYTHATISVALIDFORYEARS
klajoohnam)jasgauno]6-,.0)t1,5)`]uo/21,)gaukqp
±
lner]pa+lnergau*lai)kqp_]_anp*lai
The main command used here is
klajooh
. This command has several parameters
that can be used as if they were independent commands. The parameter
nam
is
used to create the self- signed certificate (check its man page to see everything
it can be used for). To make clear where these keys should be created,
)gaukqp

is
used to specify where to put the private key, and
)kqp
is used to define the location
of the public key. All the other options are used to specify with what parameters
the key must be created.
CHAPTER 11
N
MANAGING UBUNTU SERVER SECURITY
286
5. #REATINGTHEKEYSTARTSANINTERFACEINWHICHSEVERALQUESTIONSAREASKEDSEE
Listing 11-2). The most important is the prompt for a pass phrase. Using a pass
PHRASEISMANDATORYESPECIALLYINTHISEXAMPLEBECAUSEWEARECREATINGAROOT#!
without a pass phrase, it would be possible for anyone accessing your machine
TOCREATEPUBLICKEYCERTIFICATESSIGNEDBYTHIS#!WHICHWOULDMAKETHIS#!
worthless. You will also be prompted to enter a Distinguished Name, which is the
complete name of the server using the key. Often it is similar to the fully qualified
DNS domain name.
Listing 11-2. Creating the Public/Private Key Pair for the CA
nkkp<iah6z+nkkp)?=klajoohnam)jasgauno]6-,.0)t1,5)`]uo/21,)kqp
±
_]_anp*lai)gaukqplner]pa+lnergau*lai
Cajan]pejc]-,.0^epNO=lner]pagau
****''''''
*********************''''''
snepejcjaslner]pagaupk#lner]pa+lnergau*lai#
AjpanLAIl]ooldn]oa6
Ranebuejc)AjpanLAIl]ooldn]oa6
)))))
Ukq]na]^kqppk^a]oga`pkajpanejbkni]pekjpd]psehh^aej_knlkn]pa`

ejpkukqn_anpebe_]panamqaop*
Sd]pukq]na]^kqppkajpaneosd]peo_]hha`]@eopejcqeoda`J]iakn]@J*
Pdana]namqepa]basbeah`o^qpukq_]jha]raokia^h]jg
Bknokiabeah`opdanasehh^a]`ab]qhpr]hqa(
Ebukqajpan#*#(pdabeah`sehh^ahabp^h]jg*
)))))
?kqjpnuJ]ia$.happan_k`a%W=QY6JH
Op]paknLnkrej_aJ]ia$bqhhj]ia%WOkia)Op]paY6
Hk_]hepuJ]ia$ac(_epu%WY6
Knc]jev]pekjJ]ia$ac(_kil]ju%WEjpanjapSe`cepoLpuHp`Y6
Knc]jev]pekj]hQjepJ]ia$ac(oa_pekj%WY6
?kiikjJ]ia$ac(UKQNj]ia%WY6Iuoahb
Ai]eh=``naooWY6iuoahb<at]ilha*_ki
N
Note
You should always check the output of the
klajooh
commands carefully. It’s not easy to see errors,
but it is easy to make them through small typing mistakes. You should fix all errors before proceeding to the
next step.
CHAPTER 11
N
MANAGING UBUNTU SERVER SECURITY
287
6. 9OUNOWHAVEYOUROWNROOT#!WHICHMEANSYOUCANCREATEYOUROWNCERTIFI-
cates, used for any purpose. For example, you can create server certificates for
secure e-mail or create client certificates to connect a notebook to a VPN gate-
way. Before you can start creating your own certificates, you need to create the
OpenSSL database. This database consists of two files in which OpenSSL keeps
track of all the certificates that it has issued; you need to create these two files

manually before you start. To create this simple database, change to the home
DIRECTORYOFYOURROOT#!USE
pkq_dej`at*ptp
, and then use
a_dk,-:oane]h
.
7. Now that you have the database index files, you need to create the key pair and the
associated key signing request. To do this, first use
_`+nkkp+nkkp)?=
to go to the
ROOTDIRECTORYTHATISUSEDBYYOUR#!.EXTENTERTHECOMMAND
klajoohnam)jas)gaukqplner]pa+i]ehoanrangau*lai
±
)kqp_anpo+i]ehoanran[nam*lai)`]uo/21
This example uses the name
i]ehoanrangau
, which makes it easy to identify what
the key is used for; you can use any name you like here. With this command, you
have created a new key pair, of which the private key is stored in
+nkkp+nkkp)?=+
lner]
te, and the public key is dropped in
+nkkp+nkkp)?=+_an
ts. Listing 11-3 shows
the process of creating these keys.
Listing 11-3. Creating a Public/Private Key Pair for Your Server
nkkp<iah6z+nkkp)?=klajoohnam)jas)gaukqplner]pa+i]ehoanrangau*lai
±
)kqp_anpo+i]ehoanran[nam*lai)`]uo/21
Cajan]pejc]-,.0^epNO=lner]pagau

******************''''''
*************''''''
snepejcjaslner]pagaupk#lner]pa+i]ehoanrangau*lai#
AjpanLAIl]ooldn]oa6
Ranebuejc)AjpanLAIl]ooldn]oa6
)))))
Ukq]na]^kqppk^a]oga`pkajpanejbkni]pekjpd]psehh^aej_knlkn]pa`
ejpkukqn_anpebe_]panamqaop*
Sd]pukq]na]^kqppkajpaneosd]peo_]hha`]@eopejcqeoda`J]iakn]@J*
Pdana]namqepa]basbeah`o^qpukq_]jha]raokia^h]jg
Bknokiabeah`opdanasehh^a]`ab]qhpr]hqa(
Ebukqajpan#*#(pdabeah`sehh^ahabp^h]jg*
)))))
CHAPTER 11
N
MANAGING UBUNTU SERVER SECURITY
288
?kqjpnuJ]ia$.happan_k`a%W=QY6JH
Op]paknLnkrej_aJ]ia$bqhhj]ia%WOkia)Op]paY6J>
Hk_]hepuJ]ia$ac(_epu%WY6=iopan`]i
Knc]jev]pekjJ]ia$ac(_kil]ju%WEjpanjapSe`cepoLpuHp`Y6Okia?kil]ju
Knc]jev]pekj]hQjepJ]ia$ac(oa_pekj%WY6okiasdana
?kiikjJ]ia$ac(UKQNj]ia%WY6Ia
Ai]eh=``naooWY6ia<okia_kil]ju*_ki
Lha]oaajpanpdabkhhksejc#atpn]#]ppne^qpao
pk^aoajpsepdukqn_anpebe_]panamqaop
=_d]hhajcal]ooskn`WY6
=jklpekj]h_kil]juj]iaWY6
8. You NOWHAVECREATEDTHE#!ANDAKEYPAIRTHATYOUWANTTOGETSIGNED)FUNLIKE
INTHISSIMPLEEXAMPLESETUPTHE#!THATNEEDSTOSIGNTHEKEYDOESNOTRUNON

your own server, you would now copy it to the server that does the signing. In this
SIMPLESETUPBECAUSETHE#!ISONTHESAMESERVERYOUCANSIGNTHE#!USINGTHE
following command:
klajooh_])lkhe_ulkhe_u[]jupdejc)jkpatp)kqp_anpo+i]ehoanran_anp*lai
±
)ejbehao_anpo+i]ehoanran[nam*lai
-AKESURETHATYOURUNTHISCOMMANDFROMTHEROOTDIRECTORYOFTHE#!ASWELL
In this command, for signing the key, the default policy is used,
lkhe_u[]jupdejc
,
which is defined as the default setting in the
klajooh*_jb
configuration file. The
option
)jkpatp
is used to limit the amount of output produced by this command.
Then the name of the resulting certificate is given:
_anpo+i]ehoanran_anp*lai
. This
certificate can be created only because earlier you created a signing request with
the name
i]ehoanran[nam*lai
. This
i]ehoanran[nam*lai
request is in the
_anpo
direc-
tory. In a situation in which you need to sign a public key that is generated on
another server, you only have to make sure that this public key is copied to this
directory; the signing request would find it and the public key certificate would

be created without any problem. Listing 11-4 shows the output that is generated
when signing this certificate.
Listing 11-4. Signing the Certificate Just Created
nkkp<iah6z+nkkp)?=klajooh_])lkhe_ulkhe_u[]jupdejc)jkpatp)kqp
±
_anpo+i]ehoanran_anp*lai)ejbehao_anpo+i]ehoanran[nam*lai
Qoejc_kjbecqn]pekjbnki+qon+he^+ooh+klajooh*_jb
Ajpanl]ooldn]oabkn+nkkp+nkkp)?=+lner]pa+lnergau*lai6

×