Red Hat Enterprise Linux

Deployment Guide

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 RaleighNC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle ParkNC 27709 USA

January 2008

История переиздания
Издание 5.2-11 Wed May 21 2008 Michael Hideo
Smith
Resolves: #232215
Changing from XML to HTML Single with floating Table of Contents and viewable by browser
Аннотация

This Deployment Guide documents relevant information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 5.2.


Введение
1. Мы ждем ваших отзывов
I. Конфигурация сетевых компонентов
1. Сетевые интерфейсы
1.1. Сетевые файлы конфигурации
1.2. Файлы конфигурации интерфейсов
1.2.1. Интерфейсы Ethernet
1.2.2. Интерфейсы IPsec
1.2.3. Интерфейсы объединения каналов
1.2.4. Алиас-файлы и файлы-дубликаты
1.2.5. Интерфейсы коммутируемого соединения (Dialup)
1.2.6. Прочие интерфейсы
1.3. Сценарии управления интерфейсами
1.4. Configuring Static Routes
1.5. Файлы сетевых функций
1.6. Дополнительные ресурсы
1.6.1. Установленная документация
II. Безопасность и проверка подлинности
2. Обзор безопасности
2.1. Оценка уязвимости
2.1.1. Рассуждение с позиции противника
2.1.2. Определение оценки и тестирования
2.1.3. Анализ средств
2.2. Распространенные атаки и вторжения
2.3. Обновления системы безопасности
2.3.1. Обновление пакетов

Введение

Добро пожаловать в Руководство по развертыванию Red Hat Enterprise Linux.

Руководство по развертыванию содержит информацию о том, как выполнить настройку системы Red Hat Enterprise Linux. Если вы ищете детальную документацию по конфигурации системы, основанную на примерах задач, это руководство для вас.

Данное руководство подразумевает наличие базовых знаний систем Red Hat Enterprise Linux. Если вам нужна помощь в установке, обратитесь сначала к Руководству по установке Red Hat Enterprise Linux.

1. Мы ждем ваших отзывов

Если вы обнаружили опечатки в Руководстве по развертыванию Red Hat Enterprise Linux, или у вас есть предложения по улучшению этого руководства, мы бы хотели услышать об этом. Отправьте сообщение об ошибке для компонента Deployment_Guide в службу регистрации ошибок Bugzilla по адресу http://bugzilla.redhat.com/bugzilla/.

Если у вас есть предложения по улучшению документации, попытайтесь описать их как можно более детально. Если вы нашли ошибку, пожалуйста, укажите номер раздела и часть окружающего текста, чтобы мы смогли быстрее ее найти.

Часть I. Конфигурация сетевых компонентов

Глава 1. Сетевые интерфейсы

В Red Hat Enterprise Linux 5 все сетевые взаимодействия осуществляются между настроенными программными сетевыми интерфейсами и физическими сетевыми устройствами системы.

Файлы конфигурации сетевых интерфейсов и сценарии для их активации/ деактивации расположены в папке /etc/sysconfig/network-scripts/. Хотя количество и типы файлов могут отличаться для разных систем, в общем случае файлы можно подразделить на три основные категории:

  1. Файлы конфигурации интерфейсов

  2. Сценарии управления интерфейсами

  3. Файлы сетевых функций

Файлы каждой группы в совокупности обеспечивают активацию/ деактивацию различных сетевых устройств.

В данном разделе рассматривается взаимосвязь между файлами и способы их использования.

1.1. Сетевые файлы конфигурации

Прежде чем приступить к подробному рассмотрению файлов конфигурации интерфейсов, необходимо понять роль основных файлов конфигурации сети при организации сетевого стека в системах 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). Её содержимое НЕ должно быть модифицировано вручную. Строго рекомендуется использование единственного метода настройки сети во избежание риска удаления конфигурации.

1.2. Файлы конфигурации интерфейсов

Файлы конфигурации интерфейсов контролируют программные интерфейсы отдельных сетевых устройств. Система использует эти файлы при загрузке для определения того, какие интерфейсы должны быть инициализированы и настроены. Имена файлов конфигурации следуют шаблону ifcfg-<имя>, где <имя> — имя устройства, управляемого данным файлом конфигурации.

1.2.1. Интерфейсы Ethernet

Одним из наиболее распространённых файлов интерфейса является 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<N> (see Раздел 1.2.3, «Интерфейсы объединения каналов»). These parameters are identical to those used for bonding devices in /sys/class/net/<bonding device>/bonding, and the module parameters for the bonding driver as described in bonding Module Directives.

This configuration method is used so that multiple bonding devices can have different configurations. If you use BONDING_OPTS in ifcfg-<name>, do not use /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) не могут управлять этим устройством.

1.2.2. Интерфейсы IPsec

Ниже приведён пример файла 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.

1.2.3. Интерфейсы объединения каналов

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> будет номер интерфейса.

1.2.4. Алиас-файлы и файлы-дубликаты

Два менее часто используемых типов файлов конфигурации интерфейсов включают алиас-файлы и файлы-дубликаты.

Конфигурационные алиас-файлы используются для установления соответствия нескольких адресов одному интерфейсу; их наименование следует шаблону 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. Этот простой пример демонстрирует возможность совместного использования параметров в различных вариациях для различных интерфейсов.

1.2.5. Интерфейсы коммутируемого соединения (Dialup)

Если вы подключаетесь к Интернету через коммутируемое соединение, необходимо корректно настроить файл конфигурации интерфейса.

Схема наименования файлов интерфейса 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. Этот файл содержит телефонный номер для набора и другую информацию интерфейса.

1.2.6. Прочие интерфейсы

Другие распространённые файлы конфигурации интерфейсов:

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).

1.3. Сценарии управления интерфейсами

Сценарии управления интерфейсами активируют и деактивируют системные интерфейсы. Два основных сценария, расположенные в папке /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

1.4. Configuring Static Routes

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-interface file. For example, static routes for the eth0 interface would be stored in the /etc/sysconfig/network-scripts/route-eth0 file. The route-interface file has two formats: IP command arguments and network/netmask directives.

IP Command Arguments Format

Define a default gateway on the first line. This is only required if the default gateway is not set via DHCP:

default X.X.X.X dev interface

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 via X.X.X.X dev interface

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

Duplicate Default Gateways

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.

Network/Netmask Directives Format

You can also use the network/netmask directives format for route-interface files. The following is a template for the network/netmask format, with instructions following afterwards:

ADDRESS0=X.X.X.X
NETMASK0=X.X.X.X
GATEWAY0=X.X.X.X
  • ADDRESS0=X.X.X.X is the network number for the static route.

  • NETMASK0=X.X.X.X is the netmask for the network number defined with ADDRESS0=X.X.X.X.

  • GATEWAY0=X.X.X.X is the default gateway, or an IP address that can be used to reach 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.

1.5. Файлы сетевых функций

Red Hat Enterprise Linux включает несколько файлов, содержащие типичные функции для активации/ деактивации интерфейсов. Эти функции сгруппированы в несколько файлов, вызов которых осуществляется по необходимости, что гораздо эффективней, чем связывание отдельного файла с функциями с каждым интерфейсом.

Файл /etc/sysconfig/network-scripts/network-functions содержит наиболее часто используемые сетевыми сценариями функции IPv4. Эти функции включают связь с выполняемыми программами, запросившими информацию об изменениях статуса интерфейса, установку имен узлов, определение маршрутизатора, проверку статуса активности устройств, а также добавление текущего маршрута.

Поскольку функции для IPv6 интерфейсов отличаются от функций IPv4 интерфейсов, существует специальный файл /etc/sysconfig/network-scripts/network-functions-ipv6, содержащий функции для конфигурации и удаления статических маршрутов IPv6, создания и удаления туннелей, добавления и удаления адресов IPv6, тестирования наличия адреса IPv6 интерфейса.

1.6. Дополнительные ресурсы

Ниже приведены ресурсы, которые более подробно объясняют сетевые интерфейсы.

1.6.1. Установленная документация

/usr/share/doc/initscripts-<версия>/sysconfig.txt

Документация по доступным параметрам сетевых файлов конфигурации, включая опции IPv6, не упомянутые в данной главе.

/usr/share/doc/iproute-<версия>/ip-cref.ps

Этот файл содержит исчерпывающую информацию о команде ip, которая, среди прочего, может быть использована для работы с таблицами маршрутов. Используйте ggv или kghostview для просмотра этого файла.

Часть II. Безопасность и проверка подлинности

Red Hat Enterprise Linux обеспечивает набор средств и методов для обеспечения безопасности систем, сервисов и данных.

Данная глава является общим введением в безопасность системы с точки зрения Red Hat Enterprise Linux и содержит информацию об оценке безопасности, типичных атаках и реакции на инциденты. Здесь вы сможете найти как общие сведения, так и сведения о настройке для обеспечения защиты разных вариантов системы Red Hat Enterprise Linux (Workstation, Server), а также частных сетей, межсетевого экрана и др. с помощью SELinux.

Глава подразумевает наличие базовых знаний в области безопасности компьютерных систем, как следствие, содержит минимальный обзор общих методов защиты, таких как контроль физического доступа, стандартные политики защиты учетных записей, аудит и пр. При необходимости предоставлены ссылки к внешним ресурсам.

Глава 2. Обзор безопасности

Широкое распространение мощных сетевых компьютеров в сфере делового и личного использования привело к появлению целых отраслей компьютерной и сетевой безопасности. Компании нуждаются в знаниях и умениях экспертов по безопасности для проведения аудита и принятия решений, соответствующих их требованиям. А так как многие компании по своей природе динамичны, и их работники обращаются к информационным ресурсам и локально, и удалённо, необходимость в создании защищённого компьютерного окружения возрастает ещё больше.

К сожалению, многие организации и индивидуальные пользователи не воспринимают безопасность достаточно серьёзно, концентрируясь скорее на мощности и продуктивности системы, вспоминая о безопасности уже постфактум — когда злонамеренное вторжение уже произошло. Эксперты по безопасности сходятся во мнении, что правильные меры, предпринятые до соединения внутренней сети с открытой сетью (например, Интернетом), пресекают большинство попыток вторжения.

2.1. Оценка уязвимости

При наличии времени, ресурсов и мотивации, любая система может быть взломана. По большому счёту никакие существующие на сегодняшний день системы безопасности и технологии не могут гарантировать полную безопасность. Маршрутизаторы призваны обезопасить сетевой интерфейс при подключении к интернету. Межсетевые экраны помогают защитить компьютер при подключении к сети. Частные виртуальные сети обеспечивают безопасную передачу данных в кодированном виде. Системы определения вторжения предупреждают о подозрительной активности. Однако, успех каждой из перечисленных технологий напрямую зависит от следующих факторов:

  • Компетентность работников, ответственных за настройку, контроль и поддержку технологий.

  • Способность быстро и оперативно применять исправления и обновлять службы и ядра.

  • Возможность постоянного наблюдения сети.

Учитывая динамику состояния систем данных и технологий, обеспечение безопасности корпоративных ресурсов может оказаться достаточно сложным. Как следствие, может возникнуть необходимость в экспертных знаниях. И хотя вполне возможно наличие персонала, обладающего знаниями во многих областях информационной безопасности, оказывается, достаточно тяжело сохранить специалистов, являющихся экспертами сразу в несокольких областях. Основная причина - каждая предметная область требует постоянного внимания и фокуса, поскольку технологии информационной безопасности не стоят на месте.

2.1.1. Рассуждение с позиции противника

Предположим, вы администрируете большую корпоративную сеть. Такие сети обычно состоят из операционных систем, приложений, серверов, сетевых мониторов, межсетевых экранов, систем определения вторжений и пр. Теперь представьте, что вы пытаетесь следить за каждой из этих составляющих. Учитывая сложность сегодняшнего программного обеспечения и сетевого окружения, не исключены вторжение и конфликты. Таким образом, отслеживание всех обновлений и исправлений для сети большой организации с неоднородными компонентами может оказаться тяжёлой задачей.

Совместите требования компетенции с задачей поддержки обновления и работоспособности системы и вы увидите, что вероятность неблагоприятных инцидентов вполне велика. Системы могут быть взломаны, данные повреждены, работа служб нарушена и т.д.

Чтобы улучшить безопасность и способствовать защите систем, сетей и данных, вам придётся рассуждать как взломщик и оценивать защищённость ваших систем путём нахождения слабых мест. Профилактика нарушений в ваших же системах поможет выявить потенциальные проблемы до того, как они будут найдены взломщиком.

Если бы вам пришлось выполнять оценку уязвимости собственного дома, то первым делом вы бы проверили каждую дверь чтобы убедиться в том, что все они закрыты и заперты. Вы также проверили бы насколько хорошо закрыты окна. Аналогичным образом выполняется оценка уязвимости систем, сетей и данных. Умышленный вход в систему со стороны производится с целью кражи или разрушения ваших данных. Сфокусируйтесь на используемых взломщиками средствах, их менталитете, мотивах, и вы сможете своевременно реагировать на их действия.

2.1.2. Определение оценки и тестирования

Оценка уязвимости может быть двух видов: Взгляд снаружи и Взгляд изнутри.

При использовании первого метода ("взгляд снаружи") вы пытаетесь взломать системы снаружи. Таким образом, вы становитесь на место взломщика, вы видите то, что видит взломщик — открытые адреса IP, системы DMZ, внешние интерфейсы межсетевого экрана и пр. Под демилитаризованной зоной DMZ (demilitarized zone) подразумевают компьютер или небольшую сеть, которая располагается между защищённой внутренней сетью (например, корпоративной LAN) и незащищённой внешней сетью (например, Интернет). Обычно DMZ включает устройства, открытые для интернет-трафика (веб-серверы HTTP, серверы FTP, почтовые серверы SMTP и серверы DNS).

Когда вы оцениваете уязвимости изнутри, вы получаете некоторые преимущества, так как вы внутри и пользуетесь большим доверием. Это положение, где вам доступна информация о серверах печати, файловых серверах, базах данных и других ресурсах.

Существует огромная разница между перечисленными способами оценки уязвимости. Будучи частью компании, вы обладаете знаниями и возможностями, несоизмеримыми с возможностями пользователя извне. На сегодняшний день безопасность многих компаний полагается на защиту систем от вторжений извне. Таким образом, недостаточно внимания уделяется внутренней защите (межсетевые экраны между отделами, контроль доступа на уровне пользователей, проверка подлинности для доступа к внутренним ресурсам и пр.). Обычно при входе внутреннюю систему компании у вас открывается доступ к большему количеству ресурсов, поскольку многие системы являются открытыми для компании. Если вы обращаетесь к системе извне, вам автоматически присваиваются ограниченные возможности.

Рассмотрим разницу между оценкой уязвимости и испытаниями на проникновение. Оценку уязвимости можно рассматривать как первый этап в процессе испытания системы на проникновение. Полученную в результате информацию можно использовать далее в испытании. В то время как оценка уязвимости тестирует систему на наличие слабых мест, целью испытания на проникновение является попытка вторжения с целью использования найденных проблем.

Анализ инфраструктуры сети является динамическим процессом. Безопасность, информационная и физическая, также является динамической величиной. Проводя оценку, вы можете получить ошибочные сообщения о несуществующих уязвимостях и не узнать о реально присутствующих.

Администраторы по безопасности могут быть ровно настолько эффективны, насколько эффективны их знания и доступные средства. При проведении оценки уязвимости, всегда есть шанс получения ложноположительных результатов, независимо от того, какие средства используются. Причиной может быть ошибка программного обеспечения или пользователя, неважно, результат один. Таким образом, могут быть найдены уязвимости, не существующие на самом деле (ложноположительный результат); хуже того, некоторые существующие проблемы могут быть не обнаружены (ложноотрицательный результат).

Теперь, когда определена разница между оценкой уязвимости и испытанием на проникновение, необходимо проанализировать результаты оценки уязвимости перед выполнением испытания системы на проникновение.

Предупреждение

Попытка тестирования уязвимостей на вторжение может оказывать отрицательное действие на продуктивность и эффективность ваших систем и сети в целом.

В приведённом ниже списке перечислены некоторые положительные стороны выполнения оценки уязвимости.

  • Уделение особого внимания информационной безопасности

  • Обнаружение потенциальных проблем до того, как они будут найдены взломщиками

  • Поддержание систем в обновлённом состоянии

  • Профессиональный рост персонала

  • Сокращение возможных финансовых потерь и возможность избежания негативной известности

2.1.2.1. Выбор методологии

Установление методолгии может оказаться полезным при выборе средств для выполнения оценки уязвимости. К сожалению, на сегодняшний день не существует единственно правильного решения в выборе методологии. Однако, вооружившись здравым смыслом и проверенной практикой, вы сможете достичь желаемых результатов.

Так что же является целью? Работаем ли мы с одним сервером или целой сетью? Являемся ли мы частью компании или проводим анализ извне? Ответы на эти вопросы являются определяющими не только в выборе средств, но и в выборе методов их использования.

Более подробная информация по установлению методологий может быть найдена по следующим адресам:

  • 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)

2.1.3. Анализ средств

Для начала нужно выбрать средство сбора информации. При анализе целой сети, определите расположение всех узлов. Затем проверьте каждый узел. На этом этапе огромное значение имеет, какие средства вы выберете для определения уязвимостей.

Также как и в обычной жизни, существует огромное количество средств, предназначенных для выполнения одной и той же работы. Эта же концепция применима и к выполнению оценки уязвимости. Существуют средства, специфичные для оперативных систем, приложений и даже сетей (основанные на используемых протоколах). Некоторые утилиты бесплатны, некоторые - нет. Некоторые утилиты интуитивно понятны и легки в использовании, в то время как другие весьма сложны и недостаточно документированы, но обладают уникальными свойствами.

Нахождение подходящих утилит может оказаться грандиозной задачей, и в конце концов, при выборе необходимо принять во внимание свой опыт. Если возможно, организуйте тестирование всех доступных утилит, обращая внимание на все достоинства и недостатки. Не забудьте просмотреть файл README или страницу помощи. Дополнительная информация может быть найдена в интернете, обратитесь к онлайн-статьям, пошаговым руководствам или, возможно, к тематическим спискам рассылки.

Обсуждаемые ниже инструменты представляют собой лишь небольшую выборку из множества доступных.

2.1.3.1. Сканирование узлов с помощью Nmap

Nmap - популярная утилита, входящая в состав Red Hat Enterprise Linux, помогающая определить структуру сети. Nmap присутствует на рынке уже какое-то время и, возможно, является одной из самых популярных утилит сбора информации. Подробная страница помощи открывает доступ к детальному описанию параметров. Администраторы могут использовать Nmap в сети для выявления работающих узлов и открытых портов.

Nmap можно рассматривать как успешный первый шаг в процессе оценки безопасности. Среди прочего, вы можете исключить все узлы из проверки или даже опустить опцию попытки идентификации операционной системы конкретного узла. Nmap действительно является хорошей основой организации безопасных служб и остановки неиспользуемых служб.

2.1.3.1.1. Использование 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:

http://www.insecure.org/

2.1.3.2. Nessus

Nessus является полным сканером безопасности системы. Модульная архитектура Nessus позволяет пользователям выполнять настройку, специфичную для их систем и сетей. Подобно любому другому сканеру, Nessus настолько эффективен, насколько эффективна база данных, на которую он полагается. Положительной стороной является то, что Nessus довольно часто обновляется и его возможности включают полную отчётность, сканирование узлов и поиск уязвимостей в реальном времени. Однако, не забывайте о ложных положительных и отрицательных результатах, которые могут иметь место и для таких мощных и постоянно обновляемых утилит как Nessus.

Замечание

Nessus не входит в поставку Red Hat Enterprise Linux и, как следствие, не осуществляется его поддержка. Описание этой утилиты включено в данный документ только в качестве обзора.

Более подробная информация о Nessus может быть найдена на официальном сайте Nessus:

http://www.nessus.org/

2.1.3.3. Nikto

Nikto является уникальным сканером скриптов CGI. Nikto не только определяет уязвимости CGI, но делает это таким образом, чтобы избежать обнаружения системами определения вторжения. Nikto поставляется с подробной документацией, с которой следует внимательно ознакомиться перед началом работы. Если в вашем распоряжении находятся веб-серверы, обслуживаемые скриптами CGI, то Nikto будет отличным средством проверки их безопасности.

Замечание

Nikto не входит в поставку Red Hat Enterprise Linux и, как следствие, не осуществляется его поддержка. Описание этой утилиты включено в данный документ только в качестве обзора.

Более подробная информация о Nikto может быть найдена по следующему адресу:

http://www.cirt.net/code/nikto.shtml

2.1.3.4. Сканер VLAD

VLAD разработан командой RAZOR в Bindview, Inc. и выполняет проверку проблем безопасности, попадающих в первую десятку SANS (SNMP, совместный доступ к файлам и пр.) Не такая всеобъемлющая утилита как Nessus, тем не менее, VLAD заслуживает внимания.

Замечание

VLAD не входит в поставку Red Hat Enterprise Linux и, как следствие, не осуществляется его поддержка. Описание этой утилиты включено в данный документ только в качестве обзора.

Более подробная информация о Nikto может быть найдена на сайте RAZOR по следующему адресу:

http://www.bindview.com/Support/Razor/Utilities/

2.1.3.5. В преддверии будущих потребностей

В зависимости от ваших целей и имеющихся ресурсов, вы можете выбирать из огромного количества утилит для сетей Novell, систем Windows, Linux и т.д. Такие концепции, как например военное передвижение — сканирование здания вашей компании на присутствие уязвимостей в беспроводных сетях, пересмотр физической безопасности, PBX-оценка сети, проверка персонала, также заслуживают внимания. По большому счёту выбор метода ограничен только вашим воображением.

2.2. Распространенные атаки и вторжения

Таблица 2.1, «Типичные вторжения» отображает некоторые из самых распространённых вторжений и точек входа, используемых хакерами для доступа к сетевым ресурсам. Обратите внимание на описание того, как эти атаки осуществляются, а также как администраторы могут защитить от них сеть.

Вторжение Описание Замечания
Пустые или стандартные пароли Использование пустых административных паролей или паролей, установленных разработчиком по умолчанию. Это очень распространено при работе с маршрутизаторами и межсетевыми экранами, хотя некоторые Linux-службы используют стандартные пароли администратора (Red Hat Enterprise Linux 5 не включает подобные службы)
Обычная практика для сетевого оборудования (маршрутизаторов, межсетевых экранов, VPN и хранилищ NAS (network attached storage).
Не редкость в устаревших операционных системах, особенно в ОС со встроенными службами, таких как UNIX и Windows.
Иногда администраторы создают учётные записи привилегированных пользователей в спешке и оставляют пароль пустым — прекрасная лазейка для злоумышленников, обнаруживших такую учётную запись.
Стандартные общие ключи Защищённые службы иногда поставляются со стандартными ключами шифрования для программирования и тестирования. Если оставить эти ключи неизменными и поместить в рабочее окружение, доступное из Интернета, любые пользователи с теми же стандартными ключами получат доступ к этому ресурсу и всей его важной информации.
Наиболее распространено в беспроводных точках доступа и предварительно настроенных защищённых серверных продуктах.
IP-спуфинг Удалённая машина действует как узел вашей локальной сети, определяет уязвимости и устанавливает программу "чёрного хода" или троянского коня для получения контроля над сетевыми ресурсами.
Подделать IP довольно сложно, так как для координации соединения нападающий должен предугадать числа TCP/IP SYN-ACK, но взломщик может облегчить реализацию такой атаки с помощью различных инструментов.
В зависимости от выполняющихся в целевой системе служб (rsh, telnet, FTP и пр.), использующих технику аутентификации от источника, от чего рекомендуется отказаться в пользу PKI или других форм проверки подлинности с шифрованием, используемых в ssh и SSL/TLS.
Прослушивание Перехват данных между двумя активными узлами путём прослушивания соединения между этими узлами.
Атака такого рода в основном рассчитана на протоколы, передающие открытый текст, например, Telnet, FTP и HTTP.
Для реализации такой атаки удалённый взломщик должен скомпрометировать систему в локальной сети; обычно для этого он осуществляет активную атаку (например, IP-спуфинг или «человек посередине»).
Рекомендуется использовать следующие меры предохранения: службы, шифрующие передаваемые ключи, одноразовые пароли или проверку подлинности с шифрованием, спасающие от утечки пароля, а также усиленное шифрование передаваемых данных.
Уязвимости служб Если взломщик находит слабое место или уязвимость в интернет-службе, через эту уязвимость может быть скомпрометирована вся система и хранящиеся в ней данные, и, возможно, другие системы в сети.
Уязвимости служб, основанных на HTTP, таких как CGI, позволяют удалённо выполнять команды и даже получить доступ к интерактивной оболочке. Даже если служба HTTP работает от имени непривилегированного пользователя (например, "nobody"), может быть получена информация о файлах конфигурации и сведения о сети. Взломщик также может провести атаку отказа в обслуживании DoS, истощающую системные ресурсы или приводящую к ее недоступности для других пользователей.
Иногда службы имеют уязвимости, незамеченные во время разработки и тестирования. Эти уязвимости (например, переполнение буфера, когда взломщик вызывает сбой службы, переполняя простыми данными буфер приложения, и оказывается в интерактивной командной строке, где он может выполнять обычные команды) могут позволить злоумышленнику получить все административные полномочия.
Администраторы должны убедиться в том, что службы не работают под именем root, и внимательно следить за выпусками обновлений и исправлений ошибок приложений, публикуемых производителями и такими организациями, как CERT и CVE.
Уязвимость приложений Взломщики находят дефекты в настольных приложениях (например, почтовый клиент) запускают произвольный код, внедряют троянских коней для последующего взлома или вызывают сбой системы. А если взломанная система обладает административными привилегиями в своей сети, также становится возможным взлом самой сети.
Рабочие станции и настольные компьютеры более подвержены взлому, поскольку работники обычно не обладают достаточным опытом и знаниями для того, чтобы обнаружить и предотвратить попытку взлома. Необходимо поставить пользователей в известность о возможных рисках, особенно при самовольной установке программ или открытии подозрительных приложений эл.почты.
Предотвращающие меры включают деактивацию автоматического открытия и запуска приложений эл.почты. Более того, автоматическое обновление программного обеспечения рабочей станции через Red Hat Network или другие службы управления системой также поможет облегчить обеспечение безопасности на множестве рабочих мест.
Атаки отказа в обслуживании DoS (Denial of Service) Один или несколько нападающих совместно атакуют сеть или сервер организации, рассылая пакеты целевому узлу (серверу, маршрутизатору, рабочей станции), что приводит к недоступности ресурса для законных пользователей.
Последняя известная DoS-атака в США произошла в 2000г. Несколько сильно нагруженных коммерческих и правительственных сайтов оказались недоступными вследствие скоординированной атаки наводнения пакетами ping, осуществлённой несколькими компьютерами-зомби (транслирующими узлами).
Исходные пакеты обычно подделываются (и пересылаются повторно), что значительно затрудняет поиск истинного источника атаки.
Возможности входящей фильтрации (IETF rfc2267) с помощью iptables и сетевых IDS, подобных snort, помогают администраторам проследить и предотвратить распределённые атаки DoS.
Таблица 2.1. Типичные вторжения

2.3. Обновления системы безопасности

По мере обнаружения уязвимостей в системе безопасности, уязвимое программное обеспечение должно быть обновлено с целью ликвидации потенциальной угрозы. Если программа является частью пакета, включённого в состав поддерживаемой версии Red Hat Enterprise Linux, компания Red Hat, Inc. обязуется как можно скорее осуществить выпуск обновлённого пакета, ликвидирующий эту уязвимость. Часто сообщения о какой-либо уязвимости сразу сопровождаются заплаткой (или исходным кодом, решающим проблему). Затем эта заплатка применяется к пакету Red Hat Enterprise Linux, проверяется отделом контроля качества Red Hat, и выпускается в виде исправления ошибки. Однако если сообщение об ошибке не содержит заплатки, это означает, что разработчики Red Hat вместе с производителями программного продукта решают эту проблему. Когда проблема решена, пакет проверяется и выпускается исправление ошибки.

При выпуске исправлений для программного обеспечения, используемого в вашей системе, сразу же обновите все затронутые пакеты для минимизации времени уязвимости вашей системы.

2.3.1. Обновление пакетов

Обновляя в системе программные продукты, важно загружать эти обновления из доверенного источника. Злоумышленник может легко создать пакет с тем же номером версии, что и настоящий, исправляющий проблему, и, внедрив в него вредоносный код, опубликовать его в Интернете. Если это произойдёт, стандартными средствами, например, сравнивая файлы с оригинальными пакетами RPM, этот код найти не удастся. То есть, важно загружать пакеты только из доверенных источников, например, с сайта Red Hat, Inc. и проверять подпись пакета, чтобы убедиться в его целостности.

Red Hat предлагает два метода нахождения информации о выпускаемых исправлениях:

  1. Перечисленные на Red Hat Network и доступные для загрузки.

  2. Перечисленные на сайте исправлений Red Hat

Замечание

Начиная с выпуска Red Hat Enterprise Linux, все обновлённые пакеты могут быть загружены только с Red Hat Network. И хоть сайт исправлений Red Hat содержит обновляемую информацию, загрузка пакетов недоступна.

2.3.1.1. Использование Red Hat Network

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, «Применение изменений».

2.3.1.2. Использование сайта исправлений Red Hat

Информация о новых исправлениях безопасности обычно публикуется на сайте исправлений Red Hat по адресу: http://www.redhat.com/security/. Вы можете выбрать продукт и его версию, затем выбрать security наверху страницы для отображения рекомендаций безопасности Red Hat Enterprise Linux. Если в сводке упомянут пакет, входящий в состав вашей системы, вы можете просмотреть детали.

На этой странице вы можете найти описание уязвимости и инструкции о том, какие действия нужно выполнить для того, чтобы корректно применить исправление.

Чтобы загрузить обновлённый пакет, щёлкните ссылку для входа Red Hat Network, затем щёлкните его имя и сохраните его на жёсткий диск. Настоятельно рекомендуется создать новый каталог, например, /tmp/updates для сохранения загружаемых пакетов.

2.3.1.3. Проверка подписанных пакетов

Все пакеты 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.

2.3.1.4. Установка подписанных пакетов

Установку большинства пакетов (за исключением пакетов ядра) можно легко выполнить с помощью следующей команды:

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, «Применение изменений».

2.3.1.5. Применение изменений

После завершения загрузки и установки через Red Hat Network исправлений безопасности остановите работу старого программного обеспечения и начните пользоваться новым. Как это сделать зависит от типа обновлённых приложений. . В следующем списке перечислены общие категории программного обеспечения и приведены инструкции по использованию новых версий после обновления пакета.

Замечание

В большинстве случаев перезагрузки системы должно быть достаточно для того, чтобы обновлённая версия пакета вступила в силу. Однако, не всегда возможно сразу выполнить перезагрузку.

Приложения

Пользовательские приложения - приложения, которые могут быть запущены пользователем. Обычно старт таких приложений происходит когда пользователь, сценарий или утилита выполняет их запуск. Приложения обычно не выполняются на протяжении долгого периода времени.

При установке обновлённой версии такого приложения, остановите выполнение всех версий этого приложения и перезапустите его снова. Будет запущена новая версия.

Ядро

Ядро является основным компонентом операционной системы Red Hat Enterprise Linux. Оно обеспечивает доступ к памяти, процессору и периферийным устройствам, а также занимается планировкой задач.

Поскольку ядро является центральным элементом, то невозможно выполнить его рестарт без остановки компьютера. Поэтому единственным способом использования обновлённой версии является перезагрузка системы.

Разделяемые библиотеки

Разделяемые библиотеки представляют собой логические единицы кода (например, glibc), используемые приложениями и службами. Приложения загружают разделяемый код при инициализации, поэтому все приложения, использующие разделяемые библиотеки, должны быть остановлены и перезапущены.

Для того, чтобы определить какие приложения используют ту или иную разделяемую библиотеку, выполните команду lsof:

lsof /usr/lib/libwrap.so*

Эта команда возвращает список всех запущенных программ, использующих оболочки TCP для управления доступом к узлу. Поэтому, все перечисленные программы должны быть остановлены и перезапущены в случае обновления пакета tcp_wrappers.

Службы SysV

Службы 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