Httpd.conf: файл конфигурации сервера

SSH

SSH (Secure Shell) – это клиент-серверная система, позволяющая создавать зашифрованные туннели между двумя и более компьютерами. Существуют две основные разновидности защищенного интерпретатора команд. В основе одной из них лежит протокол SSH версии 1, в основе другой – протокол SSH версии 2. Первая версия протокола в настоящее время применяется редко. Она считается устаревшей из-за обнаруженных ошибок, хотя по-прежнему поддерживается современными системами в целях обеспечения обратной совместимости.

SSH версии 1

Аутентификация компьютеров с использованием алгоритма RSA

Вызывая ssh, клиентскую утилиту, пользователь запрашивает соединение с удаленным компьютером (сервером). На сервере должен выполняться демон SSH (sshd). После получения запроса сервер отвечает на него, высылая клиенту открытый ключ компьютера (H) и открытый ключ сервера (S). Под выражением "ключи компьютера" понимается пара "секретный-открытый ключ RSA", генерируемая демоном sshd на этапе инсталляции. По умолчанию эти ключи имеют длину 1024 бита. Открытый ключ H сохраняется в файле /etc/ssh/ssh_host_key.pub (эту настройку можно изменить). Личный секретный ключ компьютера хранится в файле /etc/ssh/ssh_host_key и не должен быть зашифрованным (в то же время, личные ключи пользователя обычно шифруются). Следовательно, важно должным образом защитить этот файл. Ключи компьютера разрешается модифицировать спуерпользователю с помощью утилиты ssh-keygen.

Выражение "ключи сервера" означает пару "секретный-открытый ключ RSA", генерируемую демоном sshd один раз во время запуска и каждый час (стандартная установка) после первого использования. По умолчанию эти ключи имеют длину 768 бит. Ни один из двух ключей не хранится на диске.

Получив ключи H и S, клиент пытается проверить ключ H, просматривая файлы /etc/ssh/ssh_known_hosts и $HOME/.ssh/known_hosts. По умолчанию, если ключ H не найден или был изменен, утилита ssh выдает предупреждение и спрашивает пользователя, не хочет ли он добавить ключ в файл $HOME/.ssh/known_hosts. Автоматическое добавление ключей в файл удобно, однако открывает дополнительные возможности для злоумышленников. Чтобы запретить этот режим, следует задать переменную StrictHostKeyChecking равной yes в пользовательском файле файл $HOME/.ssh/config или в общесистемном файле /etc/ssh/ssh_config. Но тогда придется самостоятельно заниматься распространением ключей.

После успешной проверки ключа H клиент генерирует 256-битное случайное число N и шифрует его обоими ключами (сначала H, потом S). Зашифрованное число затем высылается серверу. Оно используется как клиентом, так и сервером для получения секретного ключа, применяемого при симметричном шифровании. Секретный ключ часто называют ключом сеанса. Все последующие данные, передаваемые в рамках соединения, шифруются согласованным ранее симметричным ключом и ключом сеанса. На этом процедура аутентификации компьютеров с использованием алгоритма RSA считается завершенной.

Далее демон sshd приступает к аутентификации пользователя. Если по какой-то причине этот процесс завершится неудачей, доступ будет запрещен.

Аутентификационный диалог между клиентом и сервером продолжается в соответствии с установками конфигурационного файла /etc/ssh/sshd_config и параметрами компиляции.

Таблица 15.1.

Типы ключей, применяемых в RSA

Тип ключа	Способ получения и срок применения	Назначение и тип шифрования
Ключи сервера	Первый раз генерируются при запуске демона sshd. После первого использования повторно генерируются каждый час.	Применяются для аутентификации компьютеров с использованием алгоритма RSA. Никогда не хранятся на диске.
Ключи компьютера	Генерируются на этапе выполнения и могут быть повторно сгенерированы вручную.	Применяются для аутентификации компьютеров по алгоритму RSA, а также для аутентификации пользователей с проверкой файла надежных узлов и ключей RSA.
Ключи пользователя	Должны генерироваться самим пользователем и могут быть повторно сгенерированы вручную.	Применяются исключительно для аутентификации пользователей по алгоритму RSA.
Ключ сеанса	Создается на основании случайного числа, выбранного клиентом в процессе аутентификации компьютера. Используется для симметричного шифрования в течение SSH-сеанса. Не может генерироваться вручную.	Используется для организации зашифрованного SSH-туннеля. По окончании аутентификации компьютера все данные, передаваемые между клиентом и сервером, шифруются этим ключом с применением симметричного алгоритма. В США используется алгоритм Иwfish, а в международной версии SSH – алгоритм IDEA либо другой алгоритм, выбранный клиентом и поддерживаемый сервером.

SSH версии 2

Концептуально протокол SSH2 аналогичен протоколу версии 1. У каждого компьютера есть свои ключи, используемые для аутентификации. Но в отличие от версии 1, ключи сервера не создаются. Вместо этого ключи согласовываются по алгоритму Диффи-Хеллмана, после чего генерируется ключ сеанса. Данные, передаваемые в ходе сеанса, шифруются этим ключом с применением согласованного алгоритма. Кроме того, если в SSH1 целостность сообщений проверяется по незащищенной контрольной сумме, то в SSH2 используется хеш-код SHA-1 или MD5.

Методы аутентификации таковы: по открытому ключу пользователя (PubKeyAuthentication), по открытому ключу компьютера с использованием файлов надежных узлов (HostBaseedAuthentication) и при помощи пароля (через модуль PAM [PAMAuthenticationViaKbdInt] или по схеме "оклик-ответ").

Контрольные вопросы

1. Какие типы сетевых экранов выделяют?

2. На основании каких параметров осуществляется фильтрация трафика?

3. Что нужно учесть при определении порядка следования правил в цепочках?

4. Для чего предназначены прокси-серверы?

5. Какие алгоритмы замещения объектов в КЭШе поддерживает сервер squid?

6. Каково назначение центра сертификации?

7. В чем заключаются различия SSH версий 1 и 2?

8. Как производится аутентификация пользователей в SSH?

9. Каковы уязвимости SSH версии 2?

10. Можно ли использовать модули PAM при работе с SSH и если да, то с какой целью?

Лекция 16.

БЕЗОПАСНОСТЬ УРОВНЯ ПРИЛОЖЕНИЙ

Особенности защиты прикладных сервисов в Unix-системах можно рассмотреть на примере сервера Apache.

Для настройки серверов Apache можно использовать специально разработанную для этого графическую оболочку (интерфейс пользователя). Но основные настройки хранятся в нескольких конфигурационных файлах (/usr/local/etc/httpd/conf).

Таблица 16.1.

Основные конфигурационные файлы для Apache сервера

Имя файла	Содержимое
access.conf	директивы, описывающие права доступа к каталогам и файлам сервера
srm.conf	DocumentRoot — первый каталог сервера UserDir — имя пользовательского каталога DirectoryIndex — список файлов индекса
httpd.conf	Port — номер используемого порта HostnameLookups — разрешение преобразования IP в DNS имена User и Group — задают администратора сервера

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

В качестве альтернативы режиму standalone можно воспользоваться услугами демона inetd.

Port: номер сетевого порта, на котором будет работать ваш сервер, если он запущен в автономном режиме (если используется inetd, то номер порта следует задать в файле /etc/services).

HostnameLookups: в целях наблюдения за деятельностью пользователей сервер Apache ведет серию журнальных файлов. В одном из них ведется учет компьютеров, осуществивших доступ к серверу. Директива HostnameLookups указывает, записывается ли в журнальный файл имя компьютера (например, macl.shoop.com) или только его IP-адрес (например, 152.2.22.81).

User и Group: действительные идентификаторы пользователя и группы, которые присваиваются серверу, работающему в автономном режиме. Можно задавать как имена, так и их числовые эквиваленты, которые можно найти в файлах /etc/passwd и /etc/group соответственно.

ServerAdmin: электронный адрес администратора данного Web-узла. Этот адрес необходимо добавить в поддерживаемую почтовым сервером базу данных псевдонимов, находящуюся в файле /etc/aliases: webmaster: name. name — имя пользователя, который будет заниматься обслуживанием Web-сервера. Затем, в результате выполнения команды

#newaliases, база данных псевдонимов будет перестроена.

ServerRoot: базовый каталог, в котором будет установлено программное обеспечение HTTP-сервера Apache. По умолчанию это каталог /usr/local/etc/httpd.

BindAddress: только для компьютеров, имеющих более одного IP- адреса. С ее помощью можно устанавливать, прослушивание какого из IP- адресов компьютера сервер будет производить на предмет поступления запросов. Большинство компьютеров имеют один IP-адрес.

ErrorLog и TransferLog: местоположение журнальных файлов, в которых регистрируются ошибки и попытки доступа к серверу соответственно. Сервер подразумевает, что имена, начинающиеся не с косой черты (/), отсчитываются от каталога ServerRoot.

PidFile и ScoreBoardFile: если сервер работает в автономном режиме,

то в директиве PidFile задается имя файла, в котором исходный процесс- сервер регистрируется, указывая свой идентификационный номер. Эту информацию можно использовать для завершения или перезапуска сервера. Директива ScoreBoardFile позволяет серверу Apache следить за собственной производительностью.

ServerName: имя сервера в том виде, в котором оно появляется в строке URL.

CacheNegotiatedDocs: директива позволяет прокси-серверу кэшировать договорные документы, то есть документы, такие как вывод сценариев CGI или сгенерированная сервером индексная страница.

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

KeepAlive и KeepAliveTimeout: KeepAlive устанавливает максимальное количество запросов в рамках одного соединения. Параметр KeepAliveTimeout отражает промежуток времени между последовательными запросами.

StartServers: число серверов в пуле.

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

MaxClients: максимальное число копий сервера, которые могут выполняться одновременно.

MaxRequestsPerChild: время жизни любого отдельного сервера в пуле серверов.

Дата добавления: 2014-12-07