Copyright © 2008 Red Hat, Inc.
Copyright © 2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later with the restrictions noted below (the latest version of the OPL is presently available at http://www.opencontent.org/openpub/).
Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder.
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries.
All other trademarks referenced herein are the property of their respective owners.
The GPG fingerprint of the security@redhat.com key is:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E
1801 Varsity Drive Raleigh, NC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park, NC 27709 USA
January 2008
История переиздания | ||||
---|---|---|---|---|
Издание 5.2-11 | Wed May 21 2008 |
Michael Hideo Smith <mhideo@redhat.com>
|
||
|
This Deployment Guide documents relevant information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 5.2.
Добро пожаловать в Руководство по развертыванию Red Hat Enterprise Linux.
Руководство по развертыванию содержит информацию о том, как выполнить настройку системы Red Hat Enterprise Linux. Если вы ищете детальную документацию по конфигурации системы, основанную на примерах задач, это руководство для вас.
Данное руководство подразумевает наличие базовых знаний систем Red Hat Enterprise Linux. Если вам нужна помощь в установке, обратитесь сначала к Руководству по установке Red Hat Enterprise Linux.
Если вы обнаружили опечатки в Руководстве по развертыванию Red Hat Enterprise Linux, или у вас есть предложения по улучшению этого руководства, мы бы хотели услышать об этом. Отправьте сообщение об ошибке для компонента Deployment_Guide
в службу регистрации ошибок Bugzilla по адресу http://bugzilla.redhat.com/bugzilla/
.
Если у вас есть предложения по улучшению документации, попытайтесь описать их как можно более детально. Если вы нашли ошибку, пожалуйста, укажите номер раздела и часть окружающего текста, чтобы мы смогли быстрее ее найти.
Данная секция содержит информацию о настройке сети, а также сведения о том, как настроить удаленный вход в систему, обеспечить совместный доступ к файлам и папкам по сети, настроить веб-сервер и т.д.
В Red Hat Enterprise Linux 5 все сетевые взаимодействия осуществляются между настроенными программными сетевыми интерфейсами и физическими сетевыми устройствами системы.
Файлы конфигурации сетевых интерфейсов и сценарии для их активации/ деактивации расположены в папке /etc/sysconfig/network-scripts/
. Хотя количество и типы файлов могут отличаться для разных систем, в общем случае файлы можно подразделить на три основные категории:
Файлы конфигурации интерфейсов
Сценарии управления интерфейсами
Файлы сетевых функций
Файлы каждой группы в совокупности обеспечивают активацию/ деактивацию различных сетевых устройств.
В данном разделе рассматривается взаимосвязь между файлами и способы их использования.
Прежде чем приступить к подробному рассмотрению файлов конфигурации интерфейсов, необходимо понять роль основных файлов конфигурации сети при организации сетевого стека в системах Red Hat Enterprise Linux.
Основные сетевые файлы конфигурации:
/etc/hosts
Основным назначением этого файла является разрешение имён узлов, которые невозможно разрешить иными путями, или имён узлов небольших сетей без DNS-сервера. Независимо от типа сети, в состав которой входит компьютер, данный файл должен содержать строку с IP-адресом петлевого устройства (127.0.0.1
) для localhost.localdomain
. За дальнейшей информацией обратитесь к странице помощи hosts
.
/etc/resolv.conf
Этот файл определяет адреса IP серверов DNS и поискового домена. В исходной конфигурации сценарии инициализации сети будут заполнять этот файл. За дальнейшей информацией обратитесь к странице помощи resolv.conf
.
/etc/sysconfig/network-scripts/ifcfg-<имя-интерфейса>
Каждому сетевому интерфейсу сопоставлен соответствующий сценарий конфигурации. Каждый файл содержит специфичную для отдельного интерфейса информацию. За дальнейшей информацией об этом файле и его директивах обратитесь к Раздел 1.2, «Файлы конфигурации интерфейсов».
Папка /etc/sysconfig/networking/
используется утилитой Утилита администрации сети (system-config-network
). Её содержимое НЕ должно быть модифицировано вручную. Строго рекомендуется использование единственного метода настройки сети во избежание риска удаления конфигурации.
Файлы конфигурации интерфейсов контролируют программные интерфейсы отдельных сетевых устройств. Система использует эти файлы при загрузке для определения того, какие интерфейсы должны быть инициализированы и настроены. Имена файлов конфигурации следуют шаблону ifcfg-
, где <имя>
<имя>
— имя устройства, управляемого данным файлом конфигурации.
Одним из наиболее распространённых файлов интерфейса является ifcfg-eth0
, контролирующий первую карту сетевого интерфейса Ethernet или карту NIC системы. В системе с несколькими картами NIC будет присутствовать несколько файлов ifcfg-eth
(где <X>
<X>
— уникальный номер интерфейса). Поскольку каждому устройству сопоставлен отдельный файл, администратор может выполнять индивидуальную настройку каждого интерфейса.
Пример файла ifcfg-eth0
для системы с фиксированным IP-адресом:
DEVICE=eth0 BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no
Значения для файла конфигурации интерфейса могут быть изменены в зависимости от других величин. Например, файл ifcfg-eth0
для интерфейса, использующего DHCP, будет отличаться, т.к. данные IP обеспечиваются сервером DHCP:
DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes
Модификация файлов конфигурации вручную также является возможной.
Список настраиваемых параметров файла конфигурации интерфейса Ethernet:
BONDING_OPTS=<parameters>
sets the configuration parameters for the bonding device, and is used in /etc/sysconfig/network-scripts/ifcfg-bond
(see Раздел 1.2.3, «Интерфейсы объединения каналов»). These parameters are identical to those used for bonding devices in <N>
/sys/class/net/
, and the module parameters for the bonding driver as described in <bonding device>
/bondingbonding
Module Directives.
This configuration method is used so that multiple bonding devices can have different configurations. If you use BONDING_OPTS
in ifcfg-
, do not use <name>
/etc/modprobe.conf
to specify options for the bonding device.
BOOTPROTO=<протокол>
где
может принимать одно из следующих значений:
<протокол>
none
— нет протокола при загрузке.
bootp
— используется протокол BOOTP.
dhcp
— используется протокол DHCP.
BROADCAST=<адрес>
где
— адрес ретрансляции. Эта директива является устаревшей, т.к. её значение вычисляется автоматически с помощью <адрес>
ifcalc
.
DEVICE=<имя>
где
— имя физического устройства (за исключением динамически определённых устройств PPP, для которых будет использовано логическое имя).
<имя>
DHCP_HOSTNAME
Используйте эту опцию только в том случае, если сервер DHCP требует указания имени узла от клиента до получения IP-адреса.
DNS{1,2}
=<адрес>
где
— адрес сервера имён для записи в <адрес>
/etc/resolv.conf
в случае, если директива PEERDNS
установлена в yes
.
ETHTOOL_OPTS=<опции>
где
— любые опции, специфичные для устройств, поддерживаемые <опции>
ethtool
. Например, для использования 100 Мб, полный дуплекс:
ETHTOOL_OPTS="autoneg off speed 100 duplex full"
Instead of a custom initscript, use ETHTOOL_OPTS
to set the interface speed and duplex settings. Custom initscripts run outside of the network init script lead to unpredictable results during a post-boot network service restart.
Изменение скорости для установок дуплекса во многих случаях требует отключения автоматического определения скорости и режима соединения: autoneg off
. Это выражение должно быть первым в списке опций.
GATEWAY=<адрес>
где <адрес>
— адрес IP маршрутизатора или шлюза (при наличии устройства).
HWADDR=<адрес-MAC>
где <адрес-MAC>
— аппаратный адрес устройства Ethernet в формате AA:BB:CC:DD:EE:FF
. Данная директива будет полезной для машин с несколькими NIC. Она позволит обеспечить правильность назначения интерфейса соответствующему имени устройства независимо от порядка загрузки каждого модуля NIC. Эта директива НЕ должна использоваться одновременно с директивой MACADDR
.
IPADDR=<адрес>
где
— адрес IP.
<адрес>
MACADDR=<адрес-MAC>
где <адрес-MAC>
— аппаратный адрес устройства Ethernet в формате AA:BB:CC:DD:EE:FF
. Данная директива используется для назначения интерфейсу адреса MAC и переопределяет адрес, назначенный физической NIC. Эта директива НЕ должна использоваться одновременно с директивой HWADDR
.
MASTER=<интерфейс>
где
— интерфейс объединения каналов, к которому привязан интерфейс Ethernet.
<интерфейс>
Эта директива используется в совокупности с директивой SLAVE
.
За подробной информацией об интерфейсах объединения каналов обратитесь к Раздел 1.2.3, «Интерфейсы объединения каналов».
NETMASK=<маска>
где
— значение маски сети.
<маска>
NETWORK=<адрес>
где
— сетевой адрес. Эта директива является устаревшей, т.к. её значение вычисляется автоматически с помощью <адрес>
ifcalc
.
ONBOOT=<значение>
где
является одним из следующих:
<значение>
yes
— устройство активируется при загрузке.
no
— устройство не активируется при загрузке.
PEERDNS=<значение>
где
является одним из следующих:
<значение>
yes
— модифицировать /etc/resolv.conf
если директива DNS установлена. При использовании DHCP значение по умолчанию — yes
.
no
— не модифицировать /etc/resolv.conf
.
SLAVE=<интерфейс>
где
может принимать следующие значения:
<интерфейс>
yes
— устройство контролируется интерфейсом объединения каналов, заданным директивой MASTER
.
no
— устройство НЕ контролируется интерфейсом объединения каналов, заданным директивой MASTER
.
Эта директива используется в совокупности с директивой MASTER
.
За подробной информацией об интерфейсах объединения каналов обратитесь к Раздел 1.2.3, «Интерфейсы объединения каналов».
SRCADDR=<адрес>
где
— заданный исходный IP-адрес для исходящих пакетов.
<адрес>
USERCTL=<адрес>
где
является одним из следующих:
<значение>
yes
— обычные пользователи (не root) могут управлять этим устройством.
no
— обычные пользователи (не root) не могут управлять этим устройством.
Ниже приведён пример файла ifcfg
для IPsec-соединения для двух сетей LAN A. Уникальное имя соединения в этом примере — ipsec1
, поэтому имя результирующего файла — /etc/sysconfig/network-scripts/ifcfg-ipsec1
.
TYPE=IPsec ONBOOT=yes IKE_METHOD=PSK SRCNET=192.168.1.0/24 DSTNET=192.168.2.0/24 DST=X.X.X.X
В данном примере X.X.X.X
— общий маршрутизируемый адрес IP целевого маршрутизатора IPsec.
Ниже приведены настраиваемые параметры интерфейса IPsec:
DST=<адрес>
где <адрес>
— адрес IP конечного узла или маршрутизатора IPsec. Используется для обоих конфигураций IPsec: "узел-узел" и "сеть-сеть".
DSTNET=<сеть>
где <сеть>
— адрес сети назначения IPsec. Используется только для конфигурации типа "сеть-сеть".
SRC=<адрес>
где <адрес>
— адрес IP узла или маршрутизатора источника. Эта установка не является обязательной и используется только в конфигурации типа "узел-узел".
SRCNET=<сеть>
где <сеть>
— адрес сети источника IPsec. Используется только для конфигурации типа "сеть-сеть".
TYPE=<тип-интерфейса>
где <тип-интерфейса>
имеет значение IPSEC
. Оба приложения являются частью пакета ipsec-tools
.
Если используется ручное шифрование с IPsec, обратитесь к /usr/share/doc/initscripts-
(где <версия>
/sysconfig.txt<версия>
— номер версии установленного пакета initscripts
) за параметрами конфигурации.
Демон управления ключами IKEv1 racoon
выполняет согласование и настройку параметров для IPsec. Использует разделённые ключи, подписи RSA или GSS-API. Для автоматического управления шифрованием ключей используются следующие опции:
IKE_METHOD=<метод-шифрования>
где <метод-шифрования>
может принимать значения PSK
, X509
или GSSAPI
. При указании PSK
также должен быть задан параметр IKE_PSK
. При указании X509
также должен быть задан параметр IKE_CERTFILE
.
IKE_PSK=<ключ>
где <ключ>
— разделённый, секретный ключ для метода PSK (preshared keys).
IKE_CERTFILE=<файл-сертификата>
где <файл-сертификата>
— корректный файл сертификата X.509
узла.
IKE_PEER_CERTFILE=<файл-сертификата>
где <файл-сертификата>
— корректный файл сертификата X.509
для удалённого узла.
IKE_DNSSEC=<значение>
где <значение>
равно yes
. Демон racoon
получает сертификат удалённого узла X.509
через DNS. НЕ используйте этот параметр при установленном IKE_PEER_CERTFILE
.
За дальнейшей информацией об алгоритмах шифрования для IPsec обратитесь к странице помощи setkey
. Информация о racoon
может быть найдена на страницах помощи racoon
и racoon.conf
.
Red Hat Enterprise Linux позволяет выполнять объединение нескольких сетевых интерфейсов в один канал с помощью объединяющего
модуля ядра и специального интерфейса объединения каналов. Такое объединение позволяет функционирование нескольких сетевых интерфейсов как одного канала, одновременно увеличивая пропускаемость и обеспечивая избыточность.
Чтобы создать интерфейс объединения, нужно создать файл ifcfg-bond
(заменив <N>
<N>
номером интерфейса, например 0
) в папке /etc/sysconfig/network-scripts/
.
Содержимое файла может быть идентичным файлу настройки объединяемого интерфейса, например, Ethernet. Единственным различием будет значение директивы DEVICE=
, установленное в bond
(где <N>
<N>
— номер интерфейса).
Пример файла конфигурации виртуального интерфейса объединения каналов:
DEVICE=bond0 BONDING_OPTS="mode=1 miimon=500" BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no
Следующим шагом будет связывание реальных физических интерфейсов путём добавления директив MASTER=
и SLAVE=
в их файлы конфигурации, что будет указывать на их вхождение в состав связанного канала. В остальном файлы настройки объединяемых интерфейсов могут не отличаться.
Например, при объединении двух Ethernet-интерфейсов оба файла eth0
и eth1
могут выглядеть следующим образом:
DEVICE=eth<N>
BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no
В приведённом примере значением <N>
будет номер интерфейса.
Два менее часто используемых типов файлов конфигурации интерфейсов включают алиас-файлы и файлы-дубликаты.
Конфигурационные алиас-файлы используются для установления соответствия нескольких адресов одному интерфейсу; их наименование следует шаблону ifcfg-
.
<if-name>
:<алиас>
Например, ifcfg-eth0:0
может быть определён таким образом, что заданные DEVICE=eth0:0
и статический IP-адрес 10.0.0.2 будут служить алиасом уже настроенного на получение информации IP через DHCP в ifcfg-eth0
интерфейса. В данном случае eth0
связан с динамическим адресом IP, но в то же время та же физическая сетевая карта может получать запросы через фиксированный адрес IP 10.0.0.2.
Алиас-интерфейсы не поддерживают DHCP.
Имена файлов интерфейсов-дубликатов следуют шаблону ifcfg-
. В то время как алиас-файлы связывают несколько адресов с одним интерфейсом, файлы-дубликаты используются для указания дополнительных параметров интерфейса. Например, стандартный Ethernet-интерфейс DHCP <имя-интерфейса>
-<имя-дубликата>
eth0
может выглядеть следующим образом:
DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp
Поскольку значение директивы USERCTL
по умолчанию равно no
, то если эта директива не задана, пользователи не смогут активировать/ деактивировать интерфейс. Чтобы дать пользователям возможность контроля, создайте файл-дубликат путём копирования файла ifcfg-eth0
в ifcfg-eth0-user
и добавления следующей строки к файлу ifcfg-eth0-user
:
USERCTL=yes
В таком случае пользователи смогут поднимать интерфейс eth0
с помощью команды /sbin/ifup eth0-user
вследствие комбинирования опций файлов ifcfg-eth0
и ifcfg-eth0-user
. Этот простой пример демонстрирует возможность совместного использования параметров в различных вариациях для различных интерфейсов.
Если вы подключаетесь к Интернету через коммутируемое соединение, необходимо корректно настроить файл конфигурации интерфейса.
Схема наименования файлов интерфейса PPP:
ifcfg-ppp<X>
где <X>
— уникальный номер, соответствующий интерфейсу.
Файл конфигурации интерфейса PPP создаётся автоматически при создании учётной записи коммутируемого соединения с помощью wvdial
, Утилита администрации сети или Kppp. Редактирование этого файла также может быть выполнено вручную.
Пример типичного файла ifcfg-ppp0
:
DEVICE=ppp0 NAME=test WVDIALSECT=test MODEMPORT=/dev/modem LINESPEED=115200 PAPNAME=test USERCTL=true ONBOOT=no PERSIST=no DEFROUTE=yes PEERDNS=yes DEMAND=no IDLETIMEOUT=600
SLIP (Serial Line Internet Protocol) — ещё один интерфейс, хоть и реже используемый. Имена файлов SLIP выглядят так: ifcfg-sl0
.
Дополнительные опции, используемые в этих файлах:
DEFROUTE=<значение>
где
является одним из следующих:
<значение>
yes
— использовать в качестве маршрута по умолчанию.
no
— не использовать в качестве маршрута по умолчанию.
DEMAND=<значение>
где
является одним из следующих:
<значение>
yes
— интерфейс позволяет команде pppd
инициировать соединение при её использовании.
no
— соединение должно быть установлено вручную.
IDLETIMEOUT=<значение>
где
— время ожидания (в секундах) до того, как интерфейс выполнит самоотключение.
<значение>
INITSTRING=<строка>
где
— строка инициализации, передаваемая модему. Данная опция используется в совокупности с интерфейсами SLIP.
<строка>
LINESPEED=<значение>
где
— скорость устройства в бодах. Возможные стандартные значения: <значение>
57600
, 38400
, 19200
, 9600
.
MODEMPORT=<устройство>
где
— имя последовательного устройства, используемого для установки соединения.
<устройство>
MTU=<значение>
где
— значение MTU (Maximum Transfer Unit) интерфейса. Параметр MTU определяет максимальный размер блока передачи данных для фрейма без учёта заголовка. Иногда установка данного параметра в <значение>
576
может привести к уменьшению количества потерянных пакетов и некоторому улучшению работы соединения.
NAME=<имя>
где
относится к наименованию набора конфигураций коммутируемых соединений.
<имя>
PAPNAME=<имя>
где
— имя пользователя, заданное при обмене PAP (Password Authentication Protocol), который позволяет удалённые подключения.
<имя>
PERSIST=<значение>
где
является одним из следующих:
<значение>
yes
— интерфейс должен быть всё время активен, даже если был деактивирован после отключения модема.
no
— нет необходимости в сохранении интерфейса в активном состоянии.
REMIP=<адрес>
где
является IP-адресом удалённой системы. Обычно оставляется пустым.
<адрес>
WVDIALSECT=<имя>
где
сопоставляет интерфейс конфигурации набора в <имя>
/etc/wvdial.conf
. Этот файл содержит телефонный номер для набора и другую информацию интерфейса.
Другие распространённые файлы конфигурации интерфейсов:
ifcfg-lo
Локальный петлевой интерфейс довольно часто используется при тестировании, а также приложениями, которым необходимо, чтобы IP-адрес указывал обратно на ту же систему. Данные, пересылаемые петлевому устройству, тут же возвращаются к сетевому слою узла.
Строго не рекомендуется модифицировать сценарий петлевого интерфейса /etc/sysconfig/network-scripts/ifcfg-lo
вручную. Это может привести к нарушению функционирования системы.
ifcfg-irlan0
Инфракрасный интерфейс позволяет выполнять обмен данными между устройствами, например, ноутбуком и принтером, через инфракрасный порт. Функциональность подобна работе Ethernet за исключением того, что соединение принадлежит типу "точка-точка".
ifcfg-plip0
Соединение PLIP (Parallel Line Interface Protocol) функционирует подобно Ethernet за исключением того, что оно использует параллельный порт.
ifcfg-tr0
Вытесненная Ethernet топология звезды (Token Ring) уже не так распространена в сетях LAN (Local Area Networks).
Сценарии управления интерфейсами активируют и деактивируют системные интерфейсы. Два основных сценария, расположенные в папке /etc/sysconfig/network-scripts/
— /sbin/ifdown
и /sbin/ifup
.
ifup
и ifdown
представляют собой символические ссылки к сценариям, расположенным в папке /sbin/
. При вызове этих сценариев необходимо указать интерфейс:
ifup eth0
ifup
и ifdown
должны являться единственным методом активации/ деактивации сетевого интерфейса.
Описание следующих сценариев приводится в качестве справки.
Файлы, принимающие участие в инициализации сети во время подъема интерфейса: /etc/rc.d/init.d/functions
и /etc/sysconfig/network-scripts/network-functions
. Обратитесь к Раздел 1.5, «Файлы сетевых функций» за дальнейшей информацией.
После проверки того, что интерфейс указан и пользователь, выполняющий запрос, обладает соответствующими правами управления интерфейсом, соответствующий сценарий активирует/ деактивирует интерфейс. Ниже приведены основные сценарии управления интерфейсами, расположенные в папке /etc/sysconfig/network-scripts/
:
ifup-aliases
Выполняет настройку IP-алиасов с помощью файлов конфигурации интерфейсов в случае, если с интерфейсом ассоциировано несколько адресов IP.
ifup-ippp
и ifdown-ippp
Выполняют активацию/ деактивацию ISDN-интерфейсов.
ifup-ipsec
и ifdown-ipsec
Выполняют активацию/ деактивацию интерфейсов IPsec.
ifup-ipv6
и ifdown-ipv6
Выполняют активацию/ деактивацию интерфейсов IPv6.
ifup-ipx
Поднимает интерфейс IPX.
ifup-plip
Поднимает интерфейс PLIP.
ifup-plusb
Поднимает интерфейс USB для сетевых соединений.
ifup-post
и ifdown-post
Содержат команды для выполнения при активации/ деактивации интерфейса.
ifup-ppp
и ifdown-ppp
Выполняют активацию/ деактивацию интерфейса PPP.
ifup-routes
Добавляет статические маршруты устройства при подъёме интерфейса.
ifdown-sit
и ifup-sit
Содержат функциональные вызовы, относящиеся к активации/ деактивации туннеля IPv6 соединения IPv4.
ifup-sl
и ifdown-sl
Выполняют активацию/ деактивацию интерфейса SLIP.
ifup-wireless
Поднимает беспроводной интерфейс.
Удаление или модификация сценариев в папке /etc/sysconfig/network-scripts/
может нарушить корректное функционирование соединений интерфейса. Только опытные пользователи могут редактировать сценарии.
Наиболее простым методом работы со всеми сетевыми сценариями является использование команды /sbin/service
службы network (/etc/rc.d/init.d/network
):
/sbin/service network <действие>
<действие>
может принимать значения start
, stop
или restart
.
Для просмотра списка сконфигурированных устройств и активных сетевых интерфейсов используйте команду:
/sbin/service network status
Routing will be configured on routing devices, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients. However, if static routes are required they can be configured for each interface. This can be useful if you have multiple interfaces in different subnets. Use the route
command to display the IP routing table.
Static route configuration is stored in a /etc/sysconfig/network-scripts/route-
file. For example, static routes for the eth0 interface would be stored in the interface
/etc/sysconfig/network-scripts/route-eth0
file. The route-
file has two formats: IP command arguments and network/netmask directives.
interface
Define a default gateway on the first line. This is only required if the default gateway is not set via DHCP:
defaultX.X.X.X
devinterface
X.X.X.X
is the IP address of the default gateway. The interface
is the interface that is connected to, or can reach, the default gateway.
Define a static route. Each line is parsed as an individual route:
X.X.X.X/X
viaX.X.X.X
devinterface
X.X.X.X/X
is the network number and netmask for the static route. X.X.X.X
and interface
are the IP address and interface for the default gateway respectively. The X.X.X.X
address does not have to be the default gateway IP address. In most cases, X.X.X.X
will be an IP address in a different subnet, and interface
will be the interface that is connected to, or can reach, that subnet. Add as many static routes as required.
The following is a sample route-eth0
file using the IP command arguments format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks:
default 192.168.0.1 dev eth0 10.10.10.0/24 via 192.168.0.1 dev eth0 172.16.1.0/24 via 192.168.0.1 dev eth0
Static routes should only be configured for other subnets. The above example is not necessary, since packets going to the 10.10.10.0/24 and 172.16.1.0/24 networks will use the default gateway anyway. Below is an example of setting static routes to a different subnet, on a machine in a 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:
10.10.10.0/24 via 10.10.10.1 dev eth1
If the default gateway is already assigned from DHCP, the IP command arguments format can cause one of two errors during start-up, or when bringing up an interface from the down state using the ifup
command: "RTNETLINK answers: File exists" or 'Error: either "to" is a duplicate, or "X.X.X.X
" is a garbage.', where X.X.X.X
is the gateway, or a different IP address. These errors can also occur if you have another route to another network using the default gateway. Both of these errors are safe to ignore.
You can also use the network/netmask directives format for route-
files. The following is a template for the network/netmask format, with instructions following afterwards:
interface
ADDRESS0=X.X.X.X
NETMASK0=X.X.X.X
GATEWAY0=X.X.X.X
ADDRESS0=
is the network number for the static route.
X.X.X.X
NETMASK0=
is the netmask for the network number defined with X.X.X.X
ADDRESS0=
.
X.X.X.X
GATEWAY0=
is the default gateway, or an IP address that can be used to reach X.X.X.X
ADDRESS0=
X.X.X.X
The following is a sample route-eth0
file using the network/netmask directives format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks. However, as mentioned before, this example is not necessary as the 10.10.10.0/24 and 172.16.1.0/24 networks would use the default gateway anyway:
ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=192.168.0.1 ADDRESS1=172.16.1.0 NETMASK1=255.255.255.0 GATEWAY1=192.168.0.1
Subsequent static routes must be numbered sequentially, and must not skip any values. For example, ADDRESS0
, ADDRESS1
, ADDRESS2
, and so on.
Below is an example of setting static routes to a different subnet, on a machine in the 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:
ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=10.10.10.1
DHCP should assign these settings automatically, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients.
Red Hat Enterprise Linux включает несколько файлов, содержащие типичные функции для активации/ деактивации интерфейсов. Эти функции сгруппированы в несколько файлов, вызов которых осуществляется по необходимости, что гораздо эффективней, чем связывание отдельного файла с функциями с каждым интерфейсом.
Файл /etc/sysconfig/network-scripts/network-functions
содержит наиболее часто используемые сетевыми сценариями функции IPv4. Эти функции включают связь с выполняемыми программами, запросившими информацию об изменениях статуса интерфейса, установку имен узлов, определение маршрутизатора, проверку статуса активности устройств, а также добавление текущего маршрута.
Поскольку функции для IPv6 интерфейсов отличаются от функций IPv4 интерфейсов, существует специальный файл /etc/sysconfig/network-scripts/network-functions-ipv6
, содержащий функции для конфигурации и удаления статических маршрутов IPv6, создания и удаления туннелей, добавления и удаления адресов IPv6, тестирования наличия адреса IPv6 интерфейса.
Ниже приведены ресурсы, которые более подробно объясняют сетевые интерфейсы.
/usr/share/doc/initscripts-<версия>
/sysconfig.txt
Документация по доступным параметрам сетевых файлов конфигурации, включая опции IPv6, не упомянутые в данной главе.
/usr/share/doc/iproute-<версия>
/ip-cref.ps
Этот файл содержит исчерпывающую информацию о команде ip
, которая, среди прочего, может быть использована для работы с таблицами маршрутов. Используйте ggv или kghostview для просмотра этого файла.
Red Hat Enterprise Linux обеспечивает набор средств и методов для обеспечения безопасности систем, сервисов и данных.
Данная глава является общим введением в безопасность системы с точки зрения Red Hat Enterprise Linux и содержит информацию об оценке безопасности, типичных атаках и реакции на инциденты. Здесь вы сможете найти как общие сведения, так и сведения о настройке для обеспечения защиты разных вариантов системы Red Hat Enterprise Linux (Workstation, Server), а также частных сетей, межсетевого экрана и др. с помощью SELinux.
Глава подразумевает наличие базовых знаний в области безопасности компьютерных систем, как следствие, содержит минимальный обзор общих методов защиты, таких как контроль физического доступа, стандартные политики защиты учетных записей, аудит и пр. При необходимости предоставлены ссылки к внешним ресурсам.
Широкое распространение мощных сетевых компьютеров в сфере делового и личного использования привело к появлению целых отраслей компьютерной и сетевой безопасности. Компании нуждаются в знаниях и умениях экспертов по безопасности для проведения аудита и принятия решений, соответствующих их требованиям. А так как многие компании по своей природе динамичны, и их работники обращаются к информационным ресурсам и локально, и удалённо, необходимость в создании защищённого компьютерного окружения возрастает ещё больше.
К сожалению, многие организации и индивидуальные пользователи не воспринимают безопасность достаточно серьёзно, концентрируясь скорее на мощности и продуктивности системы, вспоминая о безопасности уже постфактум — когда злонамеренное вторжение уже произошло. Эксперты по безопасности сходятся во мнении, что правильные меры, предпринятые до соединения внутренней сети с открытой сетью (например, Интернетом), пресекают большинство попыток вторжения.
При наличии времени, ресурсов и мотивации, любая система может быть взломана. По большому счёту никакие существующие на сегодняшний день системы безопасности и технологии не могут гарантировать полную безопасность. Маршрутизаторы призваны обезопасить сетевой интерфейс при подключении к интернету. Межсетевые экраны помогают защитить компьютер при подключении к сети. Частные виртуальные сети обеспечивают безопасную передачу данных в кодированном виде. Системы определения вторжения предупреждают о подозрительной активности. Однако, успех каждой из перечисленных технологий напрямую зависит от следующих факторов:
Компетентность работников, ответственных за настройку, контроль и поддержку технологий.
Способность быстро и оперативно применять исправления и обновлять службы и ядра.
Возможность постоянного наблюдения сети.
Учитывая динамику состояния систем данных и технологий, обеспечение безопасности корпоративных ресурсов может оказаться достаточно сложным. Как следствие, может возникнуть необходимость в экспертных знаниях. И хотя вполне возможно наличие персонала, обладающего знаниями во многих областях информационной безопасности, оказывается, достаточно тяжело сохранить специалистов, являющихся экспертами сразу в несокольких областях. Основная причина - каждая предметная область требует постоянного внимания и фокуса, поскольку технологии информационной безопасности не стоят на месте.
Предположим, вы администрируете большую корпоративную сеть. Такие сети обычно состоят из операционных систем, приложений, серверов, сетевых мониторов, межсетевых экранов, систем определения вторжений и пр. Теперь представьте, что вы пытаетесь следить за каждой из этих составляющих. Учитывая сложность сегодняшнего программного обеспечения и сетевого окружения, не исключены вторжение и конфликты. Таким образом, отслеживание всех обновлений и исправлений для сети большой организации с неоднородными компонентами может оказаться тяжёлой задачей.
Совместите требования компетенции с задачей поддержки обновления и работоспособности системы и вы увидите, что вероятность неблагоприятных инцидентов вполне велика. Системы могут быть взломаны, данные повреждены, работа служб нарушена и т.д.
Чтобы улучшить безопасность и способствовать защите систем, сетей и данных, вам придётся рассуждать как взломщик и оценивать защищённость ваших систем путём нахождения слабых мест. Профилактика нарушений в ваших же системах поможет выявить потенциальные проблемы до того, как они будут найдены взломщиком.
Если бы вам пришлось выполнять оценку уязвимости собственного дома, то первым делом вы бы проверили каждую дверь чтобы убедиться в том, что все они закрыты и заперты. Вы также проверили бы насколько хорошо закрыты окна. Аналогичным образом выполняется оценка уязвимости систем, сетей и данных. Умышленный вход в систему со стороны производится с целью кражи или разрушения ваших данных. Сфокусируйтесь на используемых взломщиками средствах, их менталитете, мотивах, и вы сможете своевременно реагировать на их действия.
Оценка уязвимости может быть двух видов: Взгляд снаружи и Взгляд изнутри.
При использовании первого метода ("взгляд снаружи") вы пытаетесь взломать системы снаружи. Таким образом, вы становитесь на место взломщика, вы видите то, что видит взломщик — открытые адреса IP, системы DMZ, внешние интерфейсы межсетевого экрана и пр. Под демилитаризованной зоной DMZ (demilitarized zone) подразумевают компьютер или небольшую сеть, которая располагается между защищённой внутренней сетью (например, корпоративной LAN) и незащищённой внешней сетью (например, Интернет). Обычно DMZ включает устройства, открытые для интернет-трафика (веб-серверы HTTP, серверы FTP, почтовые серверы SMTP и серверы DNS).
Когда вы оцениваете уязвимости изнутри, вы получаете некоторые преимущества, так как вы внутри и пользуетесь большим доверием. Это положение, где вам доступна информация о серверах печати, файловых серверах, базах данных и других ресурсах.
Существует огромная разница между перечисленными способами оценки уязвимости. Будучи частью компании, вы обладаете знаниями и возможностями, несоизмеримыми с возможностями пользователя извне. На сегодняшний день безопасность многих компаний полагается на защиту систем от вторжений извне. Таким образом, недостаточно внимания уделяется внутренней защите (межсетевые экраны между отделами, контроль доступа на уровне пользователей, проверка подлинности для доступа к внутренним ресурсам и пр.). Обычно при входе внутреннюю систему компании у вас открывается доступ к большему количеству ресурсов, поскольку многие системы являются открытыми для компании. Если вы обращаетесь к системе извне, вам автоматически присваиваются ограниченные возможности.
Рассмотрим разницу между оценкой уязвимости и испытаниями на проникновение. Оценку уязвимости можно рассматривать как первый этап в процессе испытания системы на проникновение. Полученную в результате информацию можно использовать далее в испытании. В то время как оценка уязвимости тестирует систему на наличие слабых мест, целью испытания на проникновение является попытка вторжения с целью использования найденных проблем.
Анализ инфраструктуры сети является динамическим процессом. Безопасность, информационная и физическая, также является динамической величиной. Проводя оценку, вы можете получить ошибочные сообщения о несуществующих уязвимостях и не узнать о реально присутствующих.
Администраторы по безопасности могут быть ровно настолько эффективны, насколько эффективны их знания и доступные средства. При проведении оценки уязвимости, всегда есть шанс получения ложноположительных результатов, независимо от того, какие средства используются. Причиной может быть ошибка программного обеспечения или пользователя, неважно, результат один. Таким образом, могут быть найдены уязвимости, не существующие на самом деле (ложноположительный результат); хуже того, некоторые существующие проблемы могут быть не обнаружены (ложноотрицательный результат).
Теперь, когда определена разница между оценкой уязвимости и испытанием на проникновение, необходимо проанализировать результаты оценки уязвимости перед выполнением испытания системы на проникновение.
Попытка тестирования уязвимостей на вторжение может оказывать отрицательное действие на продуктивность и эффективность ваших систем и сети в целом.
В приведённом ниже списке перечислены некоторые положительные стороны выполнения оценки уязвимости.
Уделение особого внимания информационной безопасности
Обнаружение потенциальных проблем до того, как они будут найдены взломщиками
Поддержание систем в обновлённом состоянии
Профессиональный рост персонала
Сокращение возможных финансовых потерь и возможность избежания негативной известности
Установление методолгии может оказаться полезным при выборе средств для выполнения оценки уязвимости. К сожалению, на сегодняшний день не существует единственно правильного решения в выборе методологии. Однако, вооружившись здравым смыслом и проверенной практикой, вы сможете достичь желаемых результатов.
Так что же является целью? Работаем ли мы с одним сервером или целой сетью? Являемся ли мы частью компании или проводим анализ извне? Ответы на эти вопросы являются определяющими не только в выборе средств, но и в выборе методов их использования.
Более подробная информация по установлению методологий может быть найдена по следующим адресам:
http://www.isecom.org/projects/osstmm.htmРуководство по методологии тестирования систем безопасности с открытым кодом (The Open Source Security Testing Methodology Manual, OSSTMM)
http://www.owasp.org/Открытый проект безопасности веб-приложений (The Open Web Application Security Project)
Для начала нужно выбрать средство сбора информации. При анализе целой сети, определите расположение всех узлов. Затем проверьте каждый узел. На этом этапе огромное значение имеет, какие средства вы выберете для определения уязвимостей.
Также как и в обычной жизни, существует огромное количество средств, предназначенных для выполнения одной и той же работы. Эта же концепция применима и к выполнению оценки уязвимости. Существуют средства, специфичные для оперативных систем, приложений и даже сетей (основанные на используемых протоколах). Некоторые утилиты бесплатны, некоторые - нет. Некоторые утилиты интуитивно понятны и легки в использовании, в то время как другие весьма сложны и недостаточно документированы, но обладают уникальными свойствами.
Нахождение подходящих утилит может оказаться грандиозной задачей, и в конце концов, при выборе необходимо принять во внимание свой опыт. Если возможно, организуйте тестирование всех доступных утилит, обращая внимание на все достоинства и недостатки. Не забудьте просмотреть файл README или страницу помощи. Дополнительная информация может быть найдена в интернете, обратитесь к онлайн-статьям, пошаговым руководствам или, возможно, к тематическим спискам рассылки.
Обсуждаемые ниже инструменты представляют собой лишь небольшую выборку из множества доступных.
Nmap - популярная утилита, входящая в состав Red Hat Enterprise Linux, помогающая определить структуру сети. Nmap присутствует на рынке уже какое-то время и, возможно, является одной из самых популярных утилит сбора информации. Подробная страница помощи открывает доступ к детальному описанию параметров. Администраторы могут использовать Nmap в сети для выявления работающих узлов и открытых портов.
Nmap можно рассматривать как успешный первый шаг в процессе оценки безопасности. Среди прочего, вы можете исключить все узлы из проверки или даже опустить опцию попытки идентификации операционной системы конкретного узла. Nmap действительно является хорошей основой организации безопасных служб и остановки неиспользуемых служб.
Утилита Nmap может быть запущена из командной строки путём выполнения nmap
с последующим указанием имени узла или адреса IP сканируемой машины.
nmap foo.example.com
Результаты сканирования (которое может занять несколько минут, в зависимости от местоположения узла) будут выглядеть аналогично следующему:
Starting nmap V. 3.50 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 111/tcp open sunrpc 443/tcp open https 515/tcp open printer 950/tcp open oftep-rpc 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 71.825 seconds
Nmap осуществляет проверку прослушивающих и ожидающих служб портов сети. Это знание может быть полезно для администратора, желающего закрыть ненужные или неиспользуемые службы.
Более подробная информация о Nmap может быть найдена на официальном сайте Nmap:
Nessus является полным сканером безопасности системы. Модульная архитектура Nessus позволяет пользователям выполнять настройку, специфичную для их систем и сетей. Подобно любому другому сканеру, Nessus настолько эффективен, насколько эффективна база данных, на которую он полагается. Положительной стороной является то, что Nessus довольно часто обновляется и его возможности включают полную отчётность, сканирование узлов и поиск уязвимостей в реальном времени. Однако, не забывайте о ложных положительных и отрицательных результатах, которые могут иметь место и для таких мощных и постоянно обновляемых утилит как Nessus.
Nessus не входит в поставку Red Hat Enterprise Linux и, как следствие, не осуществляется его поддержка. Описание этой утилиты включено в данный документ только в качестве обзора.
Более подробная информация о Nessus может быть найдена на официальном сайте Nessus:
Nikto является уникальным сканером скриптов CGI. Nikto не только определяет уязвимости CGI, но делает это таким образом, чтобы избежать обнаружения системами определения вторжения. Nikto поставляется с подробной документацией, с которой следует внимательно ознакомиться перед началом работы. Если в вашем распоряжении находятся веб-серверы, обслуживаемые скриптами CGI, то Nikto будет отличным средством проверки их безопасности.
Nikto не входит в поставку Red Hat Enterprise Linux и, как следствие, не осуществляется его поддержка. Описание этой утилиты включено в данный документ только в качестве обзора.
Более подробная информация о Nikto может быть найдена по следующему адресу:
VLAD разработан командой RAZOR в Bindview, Inc. и выполняет проверку проблем безопасности, попадающих в первую десятку SANS (SNMP, совместный доступ к файлам и пр.) Не такая всеобъемлющая утилита как Nessus, тем не менее, VLAD заслуживает внимания.
VLAD не входит в поставку Red Hat Enterprise Linux и, как следствие, не осуществляется его поддержка. Описание этой утилиты включено в данный документ только в качестве обзора.
Более подробная информация о Nikto может быть найдена на сайте RAZOR по следующему адресу:
В зависимости от ваших целей и имеющихся ресурсов, вы можете выбирать из огромного количества утилит для сетей Novell, систем Windows, Linux и т.д. Такие концепции, как например военное передвижение — сканирование здания вашей компании на присутствие уязвимостей в беспроводных сетях, пересмотр физической безопасности, PBX-оценка сети, проверка персонала, также заслуживают внимания. По большому счёту выбор метода ограничен только вашим воображением.
Таблица 2.1, «Типичные вторжения» отображает некоторые из самых распространённых вторжений и точек входа, используемых хакерами для доступа к сетевым ресурсам. Обратите внимание на описание того, как эти атаки осуществляются, а также как администраторы могут защитить от них сеть.
Вторжение | Описание | Замечания | |||
---|---|---|---|---|---|
Пустые или стандартные пароли | Использование пустых административных паролей или паролей, установленных разработчиком по умолчанию. Это очень распространено при работе с маршрутизаторами и межсетевыми экранами, хотя некоторые Linux-службы используют стандартные пароли администратора (Red Hat Enterprise Linux 5 не включает подобные службы) |
|
|||
Стандартные общие ключи | Защищённые службы иногда поставляются со стандартными ключами шифрования для программирования и тестирования. Если оставить эти ключи неизменными и поместить в рабочее окружение, доступное из Интернета, любые пользователи с теми же стандартными ключами получат доступ к этому ресурсу и всей его важной информации. |
|
|||
IP-спуфинг | Удалённая машина действует как узел вашей локальной сети, определяет уязвимости и устанавливает программу "чёрного хода" или троянского коня для получения контроля над сетевыми ресурсами. |
|
|||
Прослушивание | Перехват данных между двумя активными узлами путём прослушивания соединения между этими узлами. |
|
|||
Уязвимости служб | Если взломщик находит слабое место или уязвимость в интернет-службе, через эту уязвимость может быть скомпрометирована вся система и хранящиеся в ней данные, и, возможно, другие системы в сети. |
|
|||
Уязвимость приложений | Взломщики находят дефекты в настольных приложениях (например, почтовый клиент) запускают произвольный код, внедряют троянских коней для последующего взлома или вызывают сбой системы. А если взломанная система обладает административными привилегиями в своей сети, также становится возможным взлом самой сети. |
|
|||
Атаки отказа в обслуживании DoS (Denial of Service) | Один или несколько нападающих совместно атакуют сеть или сервер организации, рассылая пакеты целевому узлу (серверу, маршрутизатору, рабочей станции), что приводит к недоступности ресурса для законных пользователей. |
|
По мере обнаружения уязвимостей в системе безопасности, уязвимое программное обеспечение должно быть обновлено с целью ликвидации потенциальной угрозы. Если программа является частью пакета, включённого в состав поддерживаемой версии Red Hat Enterprise Linux, компания Red Hat, Inc. обязуется как можно скорее осуществить выпуск обновлённого пакета, ликвидирующий эту уязвимость. Часто сообщения о какой-либо уязвимости сразу сопровождаются заплаткой (или исходным кодом, решающим проблему). Затем эта заплатка применяется к пакету Red Hat Enterprise Linux, проверяется отделом контроля качества Red Hat, и выпускается в виде исправления ошибки. Однако если сообщение об ошибке не содержит заплатки, это означает, что разработчики Red Hat вместе с производителями программного продукта решают эту проблему. Когда проблема решена, пакет проверяется и выпускается исправление ошибки.
При выпуске исправлений для программного обеспечения, используемого в вашей системе, сразу же обновите все затронутые пакеты для минимизации времени уязвимости вашей системы.
Обновляя в системе программные продукты, важно загружать эти обновления из доверенного источника. Злоумышленник может легко создать пакет с тем же номером версии, что и настоящий, исправляющий проблему, и, внедрив в него вредоносный код, опубликовать его в Интернете. Если это произойдёт, стандартными средствами, например, сравнивая файлы с оригинальными пакетами RPM, этот код найти не удастся. То есть, важно загружать пакеты только из доверенных источников, например, с сайта Red Hat, Inc. и проверять подпись пакета, чтобы убедиться в его целостности.
Red Hat предлагает два метода нахождения информации о выпускаемых исправлениях:
Перечисленные на Red Hat Network и доступные для загрузки.
Перечисленные на сайте исправлений Red Hat
Начиная с выпуска Red Hat Enterprise Linux, все обновлённые пакеты могут быть загружены только с Red Hat Network. И хоть сайт исправлений Red Hat содержит обновляемую информацию, загрузка пакетов недоступна.
Red Hat Network позволяет выполнить автоматическое обновление большинства пакетов. Система определяет, какие RPM пакеты надо обновить, загружает их из хранилища, проверяет подпись пакетов и выполняет обновление. Установка пакета может быть выполнена сразу же, или же её выполнение может быть назначено на более позднее время.
В Red Hat Network каждому обновляемому компьютеру нужен Профиль системы. Профиль системы содержит информацию об аппаратном и программном обеспечении системы. Данная информация является конфиденциальной и используется только для определения необходимых вашей системе исправлений. В противном случае Red Hat Network не может определить нужны ли системе обновления. Когда происходит выпуск исправлений, Red Hat Network отправляет по эл.почте описание исправления и список затронутых систем. Для применения обновления используйте Агент обновлений Red Hat или назначьте обновление пакета по расписанию с сайта http://rhn.redhat.com.
Red Hat Enterprise Linux включает в свой состав Утилиту оповещения RHN, легкодоступный значок быстрого доступа, который изменяет свой вид в зависимости от того, есть ли доступные обновления для зарегистрированной системы Red Hat Enterprise Linux. Подробная информация может быть найдена по адресу https://rhn.redhat.com/rhn/help/quickstart.jsp
Перед установкой исправлений безопасности сначала ознакомьтесь с инструкциями, затем выполните обновление в соответствии с этими инструкциями. Общие рекомендации об установке исправлений доступны в Раздел 2.3.1.5, «Применение изменений».
Информация о новых исправлениях безопасности обычно публикуется на сайте исправлений Red Hat по адресу: http://www.redhat.com/security/. Вы можете выбрать продукт и его версию, затем выбрать security наверху страницы для отображения рекомендаций безопасности Red Hat Enterprise Linux. Если в сводке упомянут пакет, входящий в состав вашей системы, вы можете просмотреть детали.
На этой странице вы можете найти описание уязвимости и инструкции о том, какие действия нужно выполнить для того, чтобы корректно применить исправление.
Чтобы загрузить обновлённый пакет, щёлкните ссылку для входа Red Hat Network, затем щёлкните его имя и сохраните его на жёсткий диск. Настоятельно рекомендуется создать новый каталог, например, /tmp/updates
для сохранения загружаемых пакетов.
Все пакеты Red Hat Enterprise Linux подписаны ключом GPG Red Hat, Inc. GPG (GNU Privacy Guard) - бесплатный пакет аутентификации распространяемых файлов. Например, закрытый (секретный) ключ, хранимый компанией Red Hat, закрывает пакет, тогда как открытый раскрывает и проверяет его. Если при проверке RPM открытый ключ, распространяемый Red Hat, не соответствует закрытому, это значит, что пакет был изменён и, таким образом, доверять ему нельзя.
Входящая в состав Red Hat Enterprise Linux утилита RPM автоматически проверяет подпись GPG пакета RPM до начала установки. Установите ключ GPG Red Hat с безопасного источника (например, установочного диска Red Hat Enterprise Linux).
Допустим, что CD-ROM подключен к /mnt/cdrom
. Следующая команда выполнит его импорт в связку ключей (базу данных доверенных ключей):
rpm --import /mnt/cdrom/RPM-GPG-KEY
Выполните следующую команду для отображения списка всех ключей:
rpm -qa gpg-pubkey*
Вывод ключа Red Hat будет выглядеть следующим образом:
gpg-pubkey-db42a60e-37ea5438
Для того, чтобы увидеть детали отдельного ключа, выполните команду rpm -qi
в комбинации с результатом предыдущей команды:
rpm -qi gpg-pubkey-db42a60e-37ea5438
Обязательно выполните проверку подписи пакетов RPM перед их установкой для того, чтобы убедиться, что оригинальные пакеты Red Hat, Inc. не были модифицированы. Для проверки всех загруженных пакетов выполните следующую команду:
rpm -K /tmp/updates/*.rpm
Если ключ GPG каждого пакета соответствует ожидаемому, результатом выполнения команды будет gpg OK
. В противном случае, убедитесь в том, что вы используете правильный общий ключ Red Hat. Пакеты, не прошедшие проверку GPG не должны быть установлены, поскольку они могли быть незаконно модифицированы.
После окончания проверки ключа GPG и загрузки всех пакетов, выполните установку пакетов из командной строки от имени пользователя root.
Установку большинства пакетов (за исключением пакетов ядра) можно легко выполнить с помощью следующей команды:
rpm -Uvh /tmp/updates/*.rpm
Для пакетов ядра выполните следующую команду:
rpm -ivh /tmp/updates/<kernel-package>
Замените <kernel-package>
именем RPM-пакета ядра.
Как только компьютер успешно загрузится с новым ядром, старое ядро можно удалить следующей командой:
rpm -e <old-kernel-package>
Замените <old-kernel-package>
именем RPM-пакета старого ядра.
Удаление старого ядра не является обязательным. Загрузчик GRUB разрешает наличие нескольких ядер, которые могут быть выбраны при загрузке.
Перед установкой исправлений безопасности сначала ознакомьтесь с инструкциями, затем выполните обновление в соответствии с этими инструкциями. Общие рекомендации об установке исправлений доступны в Раздел 2.3.1.5, «Применение изменений».
После завершения загрузки и установки через Red Hat Network исправлений безопасности остановите работу старого программного обеспечения и начните пользоваться новым. Как это сделать зависит от типа обновлённых приложений. . В следующем списке перечислены общие категории программного обеспечения и приведены инструкции по использованию новых версий после обновления пакета.
В большинстве случаев перезагрузки системы должно быть достаточно для того, чтобы обновлённая версия пакета вступила в силу. Однако, не всегда возможно сразу выполнить перезагрузку.
Пользовательские приложения - приложения, которые могут быть запущены пользователем. Обычно старт таких приложений происходит когда пользователь, сценарий или утилита выполняет их запуск. Приложения обычно не выполняются на протяжении долгого периода времени.
При установке обновлённой версии такого приложения, остановите выполнение всех версий этого приложения и перезапустите его снова. Будет запущена новая версия.
Ядро является основным компонентом операционной системы Red Hat Enterprise Linux. Оно обеспечивает доступ к памяти, процессору и периферийным устройствам, а также занимается планировкой задач.
Поскольку ядро является центральным элементом, то невозможно выполнить его рестарт без остановки компьютера. Поэтому единственным способом использования обновлённой версии является перезагрузка системы.
Разделяемые библиотеки представляют собой логические единицы кода (например, glibc
), используемые приложениями и службами. Приложения загружают разделяемый код при инициализации, поэтому все приложения, использующие разделяемые библиотеки, должны быть остановлены и перезапущены.
Для того, чтобы определить какие приложения используют ту или иную разделяемую библиотеку, выполните команду lsof
:
lsof /usr/lib/libwrap.so*
Эта команда возвращает список всех запущенных программ, использующих оболочки TCP для управления доступом к узлу. Поэтому, все перечисленные программы должны быть остановлены и перезапущены в случае обновления пакета tcp_wrappers
.
Службы SysV представляют собой резидентные приложения, запущенные при загрузке. Примерами служб SysV могут служить sshd
, vsftpd
и xinetd
.
Поскольку такие программы находятся в памяти на протяжении всего времени работы машины, при обновлении служба SysV должна быть остановлена и перезапущена. Это можно сделать с помощью утилиты Настройки служб или запуска команды /sbin/service
от имени root.
/sbin/service <service-name>
restart
Замените <service-name>
именем службы (например, sshd
).
xinetd
Эти службы управляются главной службой xinetd
в момент установления активного соединения. В число служб, подчинённых xinetd
, входят Telnet, IMAP и POP3.
Поскольку новые сеансы таких служб могут быть запущены командой xinetd
, соединения, созданные после обновления, обрабатываются уже обновлённой версией службы. Однако, если в процессе обновления xinetd
присутствуют активные соединения, они будут обслуживаться старой версией.
Чтобы завершить ранние сессии службы xinetd
, выполните обновление пакета, затем остановите все выполняющиеся процессы. Выполните команду ps
для определения того, какие процессы выполняются в настоящий момент, а затем выполните команду kill
или killall
для остановки всех текущих сеансов службы.
Например, при выпуске исправлений безопасности пакетов imap
выполните обновление пакетов, а затем следующую команду в качестве пользователя root:
ps -aux | grep imap
Эта команда вернёт все активные сессии IMAP. Отдельные сессии могут быть остановлены с помощью следующей команды:
kill <PID>
Если использование этой команды не приводит к завершению сессии, используйте следующее:
kill -9 <PID>
Замените <PID>
идентификационным номером процесса (см. вторую колонку команды ps
) сеанса IMAP.
Для завершения активных сессий IMAP выполните команду:
killall imapd