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

 

Выявление ненужных серверов

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

Обнаружение серверов, присутствующих в системе

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

Использование средств управления пакетами

Для обнаружения серверов, присутствующих в системе, может быть использована система управления пакетами. Если при установке программ вы пользовались исключительно диспетчером пакетов, то в базе данных диспетчера содержится информация о каждой программе, которая была инсталлирована на компьютере. Просмотрев описание пакета, содержащееся в базе, можно определить, является ли установленная программа сервером и насколько она необходима для работы системы. В качестве примеров инструментальных средств управления пакетами можно привести инструмент GNOME RPM, который используется в системе Red Hat, YaST — в SuSE, и Storm Package Manager (часть дистрибутивного пакета Storm, используемая в системе Debian). Окно GNOME RPM, предназначенное для просмотра инсталлированных пакетов, показано на рис. Выбрав пакет, вы сможете прочитать его описание. Некоторые диспетчеры пакетов распределяют информацию, которая хранится в базе, по категориям, однако на практике, чтобы найти серверы, присутствующие на компьютере, надо просмотреть все категории. Диспетчеры пакетов не позволяют выявить серверы, для инсталляции которых были использованы tar-архивы или исходные коды. Кроме того, такой подход не дает возможности ответить на вопрос, выполняется ли сервер в системе. (Сервер, который был инсталлирован, но не запущен, создает гораздо меньшую угрозу безопасности системы, чем сервер, выполняющийся на компьютере. Реальная опасность возникнет лишь в том случае, если впоследствии будет установлена конфигурация системы, предполагающая запуск сервера.)

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

Проверка файлов запуска

Чтобы обнаружить серверы, присутствующие в системе, можно проверить следующие файлы.

• Конфигурационный файл суперсервера. При поиске серверов следует проверить конфигурационные файлы /etc/inetd.conf и /etc/xinetd.conf, а также файлы в каталоге /etc/xinetd.d. Таким образом, вы найдете ссылки на все серверы, запускаемые посредством суперсервера. В конфигурационном файле inetd строки, в начале которых стоит символ #, представляют собой комментарии, поэтому серверы, указанные в них, не активны. Для суперсервера xinetd запуск сервера запрещает запись disable = yes.

• Сценарии запуска SysV. Можно найти серверы, запускаемые посредством сценариев просмотрев каталоги, предназначенные для размещения таких сценариев (обычно это каталог /etc/rc.d/rc?.d или /etc/rc?.d, где символ ? означает уровень выполнения). Необходимую вам информацию предоставят имена файлов, находящихся в этих каталогах. Заметьте, что некоторые из программ, запускаемых посредством сценариев SysV, не являются серверами, поэтому, прежде чем запретить их выполнение, следует выяснить назначение этих программ.

• Локальные сценарии запуска. Во многих дистрибутивных пакетах для запуска локальных программ используются локальные сценарии. Файлы, содержащие их, обычно называются rc.local или boot.local. Локальными считаются такие программы, при инсталляции которых использовался нестандартный способ, отличающийся от подхода, принятого для данного дистрибутивного пакета. Чтобы обнаружить серверы, выполняющиеся в системе, надо просмотреть весь локальный сценарий.

Подробно вопросы запуска серверов, в том числе соглашения об именовании сценариев SysV, были рассмотрены в главе 4. Определить назначение сценариев запуска вам помогут такие инструменты, как ntsysv и tksysv. Кроме того, в некоторых системах (Caldera, Mandrake, Red Hat и TurboLinux) команда chkconfig --list, заданная в командной строке, отображает состояние сценариев SysV, а в ряде случаев и назначение записей в конфигурационном файле xinetd.

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

Анализ данных о процессах

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

Объем информации, возвращаемой ps, достаточно велик, поэтому имеет смысл перенаправить вывод в файл или передать данные, сгенерированные программой ps, утилите more или less. Если вы ищете сведения о конкретном сервере, используйте утилиту grep. Например, чтобы получить информацию о сервере sendmail, надо ввести команду ps ах | grep sendmail. Следует помнить, что утилита ps предоставляет сведения как о серверах, так и о других программах. Ниже приведен фрагмент данных, сгенерированных программой ps.

$ ps ax

 PID TTY   STAT TIME COMMAND

   1 ?     S    0:15 init [3]

 502 ?     S    0:05 named -u bind

 520 ?     S    0:01 cupsd

 535 ?     SW   0:00 [nfsd]

1741 pts/4 S    0:00 /bin/bash

4168 ?     S    0:00 httpd

На самом деле в процессе выполнения программа ps генерирует десятки и даже сотни строк. В данном примере удалена почти вся информация, кроме нескольких строк, иллюстрирующих работу этой утилиты. В первой строке программа ps выводит сведения о процессе init, для идентификации которого всегда используется номер 1. Данный процесс является корнем дерева, представляющего иерархию процессов в системе. Все остальные процессы порождаются либо непосредственно init, либо его дочерними процессами. Процессы, имена которых помещаются в квадратные скобки, представляют собой процессы ядра. В данном примере процессом ядра является [nfsd]. Как видно из его имени, [nfsd] поддерживает функции сервера NFS, реализованного средствами ядра. Процессы named, cupsd и httpd представляют собой пользовательские процессы. О принадлежности их к серверам можно судить по двум признакам. Во-первых, имя каждого из них оканчивается буквой "d", а во-вторых, эти процессы не связаны с терминалами (в поле TTY отображается символ ?). В отличие от них, процесс /bin/bash не является процессом сервера, так как в поле TTY выводится значение pts/4, т.е. данный процесс связан с конкретным терминалом.

Определив процессы серверов с помощью ps, надо отыскать документацию на те серверы, назначение которых вам неизвестно. Для этого следует ввести команду man имя, указав в качестве параметра имя интересующего вас процесса. Кроме того, постарайтесь найти исполняемый файл с именем, совпадающим с именем процесса. Это позволит вас проследить, какой пакет использовался для его инсталляции. Для получения информации о пакете введите команду rpm -qf путь_к_файлу . (В системе Debian для этого используется команда dpkg -S путь_к_файлу .)

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

Использование netstat

При использовании ps для поиска серверов возникает проблема, состоящая в том, что данная утилита не сообщает, используется ли данный сервер для поддержки сетевого взаимодействия. Получить эту информацию вам поможет программа netstat. Данная программа возвращает данные о сетевых соединениях. Подобно ps, при запуске netstat могут указываться различные опции. Для поиска информации о серверах можно использовать команду netstat -lр. Опция -l сообщает утилите netstat о том, что она должна анализировать порты, через которые серверы ожидают поступление запросов, а опция -p задает вывод имен серверов, связанных с этими портами. Как и ps, утилита netstat генерирует большой объем данных, поэтому желательно перенаправить вывод в файл или передать входные данные программе less или more.

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

Использование программ сканирования

Мощными инструментами, которые можно использовать для поиска серверов, выполняющихся в системе, являются внешние программы сканирования. В качестве примеров подобных программ можно привести Nessus (http://www.nessus.org), SAINT (http://www.wwdsi.com/saint/) и Nmap (http://www.insecure.org/nmap/). Программа сканирования выполняется на любой машине, связанной по сети с компьютером, подлежащим проверке. Некоторые из таких инструментов, помимо информации о серверах, выводят также данные об используемой операционной системе, а также сведения о наличии недостатков в защите серверов. Для поиска серверов в большинстве случаев достаточно ввести имя сканирующей программы и указать имя компьютера, который следует проверить. Например, соответствующая команда может иметь вид nmap gingko.threeroomco.com. В результате вы получите список портов и имен серверов, связанных с ними.

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

Внимание

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

На заметку

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

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

Определение необходимости сервера

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

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

Необходимо соблюдать осторожность при отключении процессов, связанных с регистрацией пользователей. Даже если компьютер не выполняет функции сервера регистрации, удаление одного из серверов, описанных в главах 13 и 14, может стать причиной серьезной проблемы, для разрешения которой придется перезагрузить компьютер с гибкого диска. Особенно осторожно следует отключать процессы регистрации, запускаемые посредством сценариев SysV.

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

 

Отключение серверов

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

• Вы можете выполнить действия, противоположные тем, которые предпринимались для запуска сервера. Например, можно закомментировать запись в конфигурационном файле /etc/inetd.conf или переименовать сценарий запуска SysV. Подробно способы запуска серверов обсуждались в главе 4.

• Вы можете деинсталлировать сервер. Если программа, реализующая сервер, отсутствует, она не может быть запущена.

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

Совет

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

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

 

Сервер, выполняющийся на компьютере, представляет собой "дверь" в систему. К сожалению, эта дверь иногда бывает открыта не только для пользователей системы, но и для "непрошеных гостей". Существуют различные способы, позволяющие закрыть эту дверь. Один из них состоит в применении брандмауэров, для создания которых применяются такие инструменты, как iptables (этот инструмент будет обсуждаться в главе 25). Другой способ — это тщательный контроль за использованием учетных записей и паролей. Если на компьютере имеются неиспользуемые учетные записи, это увеличивает вероятность незаконного проникновения в систему. Пароль, попавший в руки злоумышленника, предельно упрощает его задачу. В отличие от других задач администрирования, обеспечение контроля за учетными записями и паролями возможно только в том случае, если пользователи помогут вам в этом. Расскажите им о том, какому риску они подвергают систему и свои данные, небрежно обращаясь со своими паролями.

 

Политика использования учетных записей

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

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

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

Вам также следует написать сценарий, управляющий созданием новых учетных записей, или, по крайней мере, составить соответствующую инструкцию. Особенно внимательно следует подойти к разработке правил выбора пароля. Принципы использования паролей будут подробно рассмотрены далее в этой главе. Не следует упускать из виду и вопросы определения прав доступа, устанавливаемых по умолчанию. Например, если в организации ведется работа над несколькими проектами, имеет смысл создать для каждого проекта группу, поместив в нее пользователей, участвующих в работе над этим проектом. При этом устанавливать права доступа к рабочим каталогам следует так, чтобы к содержащимся в них файлам могли обращаться только пользователи, работающие над тем же проектом. Правила, задаваемые в составе политики, могут изменяться в зависимости от характера деятельности организации. Так, например, для открытой среды можно указать, что по умолчанию должны устанавливаться права 0755 или даже 0775 и соответствующее значение umask. Если же пользователи работают с секретными данными, желательно задавать права 0700.

 

Контроль над учетными записями

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

Выявление неиспользуемых записей

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

# usermod -e 2003-07-04 george

Данная команда сообщает системе о том, что срок действия учетной записи george заканчивается 4 июля 2003 года. (Ограничить срок действия записи можно также при ее создании, указав при вызове команды useradd опцию -е.) Такой подход очень удобен в тех случаях, когда вы наперед знаете время, начиная с которого учетная запись не будет использоваться. Например, администраторы знают об окончании студентами курса обучения и о завершении работы сотрудников, принятых на контрактной основе.

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

# chage -М 30 -W 5 george

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

Описанные подходы позволяют решить проблему неиспользуемых учетных записей, но они применимы не во всех ситуациях. Некоторые учетные записи не предполагают регистрацию пользователей, а применяются, например, для организации работы с файловым сервером или для доставки почты. В данном случае, чтобы пользователь увидел сообщение об окончании срока действия пароля, надо создать задание для инструмента cron, предусмотрев в нем определение времени, в течение которого пароль остается действительным, и оповестить пользователя по электронной почте. Существуют средства, позволяющие получить информацию об использовании учетных записей. Например, утилита last возвращает сведения о нескольких последних регистрациях пользователя в системе, а в некоторых дистрибутивных пакетах поддерживается файл протокола /var/log/auth, в который записывается информация о выполнении аутентификации. Приложив определенные усилия, вы можете написать сценарий, который проверял бы файл протокола и оповещал вас о том, что некоторые записи не используются в течение длительного времени. Периодический запуск такого сценария можно организовать с помощью инструмента cron. Если вы узнаете, что некоторая учетная запись давно не использовалась для регистрации в системе, выясните причины этого и, если запись больше не нужна, удалите ее.

Выполняя администрирование системы, надо также следить за учетными записями, срок действия которых истек. Ненужные записи следует удалить. Для поиска недействительных записей можно написать специальный сценарий. (Выявлять недействительные учетные записи можно по следующему признаку: по истечении срока действия значение третьего поля записи в файле /etc/shadow становится меньше, чем значение, содержащееся в восьмом поле.)

Выявление случаев незаконного использования учетных записей

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

Одним из признаков незаконного использования учетной записи могут быть необычные действия пользователей, зарегистрированные в файлах протоколов /var/log/messages и /var/log/secure. (Имя файла протокола и характер записываемой в него информации различается для разных дистрибутивных пакетов.) Поскольку в файлы протоколов записывается информация о работе серверов, а не клиентов, обнаружить случаи незаконного использования учетных записей удается не всегда. Так, например, если локальный пользователь воспользуется клиентской программой telnet для атаки удаленного компьютера, информация об этом в файле протокола будет отсутствовать, однако нужные сведения можно получить, анализируя файлы протоколов брандмауэра. Содержимое файлов протоколов на локальной машине чаще всего позволяет обнаружить попытки взлома, предпринимаемые извне.

Анализ файлов протоколов — утомительная процедура, отнимающая много времени. Для того чтобы упростить работу администраторов, были созданы специальные инструменты. Примером инструментального средства, предназначенного для обработки файлов протоколов, является Simple Watcher (SWATCH, http://oit.ucsb.edu/~eta/swatch/). Данная программа позволяет искать записи в файлах протоколов по ключевым словам.

Для выявления случаев незаконного использования учетных записей можно установить в системе сервер аутентификации auth (в некоторых версиях Linux он называется identd). Когда клиентская программа, выполняемая на вашем компьютере, обращается к удаленному серверу, последний может установить связь с вашим компьютером и идентифицировать пользователя, инициировавшего обращение. Если кто-то из ваших пользователей нанес вред удаленной системе, информация о нём записывается в файл протокола и администратор уделенной системы может связаться с вами и сообщить имя пользователя, выполнявшего незаконные действия. Чтобы это стало возможно, необходимо, чтобы на вашем компьютере выполнялся сервер аутентификации, а злоумышленник не имел возможности заменить этот сервер своей программой. Сервер аутентификации входит в состав многих дистрибутивных пакетов и требует минимальной настройки. Обычно он запускается посредством суперсервера.

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

 

Выбор паролей

Для того чтобы пароль можно было использовать, он должен находиться на диске компьютера. В системе Linux пароль располагается в файле /etc/shadow (в старых версиях Linux он находился в файле /etc/passwd). Пароль хранится в зашифрованном виде; для его кодирования обычно используется алгоритм одностороннего кодирования. Поскольку алгоритм декодирования отсутствует, может показаться, что содержимое файла паролей бесполезно для злоумышленника, однако при наличии компьютера с мощным процессором возможно подобрать пароль. Взломщики используют для этой цели словари, включающие слова многих языков, имена собственные и слова, в которых символы следуют в обратном порядке. Имея файл паролей, хакер может закодировать каждое слово из словаря и сравнить с зашифрованными паролями. Если зашифрованное слово из словаря совпадает с записью в файле, это слово является паролем для регистрации в системе.

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

Для создания базовой последовательности надо выбрать два несвязанные между собой слова и объединить их. В результате получится слово, отсутствующее в любом словаре, например bunpen. Можно также придумать легко запоминающуюся фразу и использовать в качестве базовой последовательность, составленную из первых букв слов, входящих в фразу. Например, из фразы "yesterday I went to the dentist" можно составить слово yiwttd. Такой набор букв легко запомнить, и в то же время он отсутствует в словарях. (В данном примере я использовал последовательность из шести символов. Дело в том, что в результате модификации длина пароля увеличится, а в большинстве систем длина пароля не должна превышать восемь символов.) Несмотря на то, что сгенерированные последовательности символов отсутствуют в словарях, не исключено, что хакер использует описанный алгоритм для расширения своего словаря. Поэтому созданная вами базовая последовательность должна быть модифицирована. Ниже приведены возможные варианты такой модификации.

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

• Добавление цифр и знаков пунктуации. Добавив выбранные случайным образом цифры или знаки пунктуации в случайные позиции базовой последовательности, вы получите пароль наподобие BU3nP&eN или Y+iWTtd2.

• Изменение порядка следования символов. Если в базовой последовательности вы объединили два слова, измените порядок следования символов в одном из них на обратный. На основе одного из приведенных выше примеров таким способом получим пароль BU3nHe&P.

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

Для того чтобы проверить, насколько хорош выбранный вами пароль, воспользуйтесь одной из программ, применяемых взломщиками для подбора паролей, например Crack (http://www.users.dircon.со.uk/~crypto/). Если эта программа сможет подобрать ваш пароль, значит, процедуру выбора пароля надо повторить.

Внимание

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

Выбрав пароль, надо принять меры для того, чтобы сохранить его в секрете. Как было сказано выше, записывать пароль нельзя. Недопустимо также сообщать его кому- нибудь (даже членам семьи или сотрудникам). Вы должны объяснить пользователям, что их пароли вам не понадобятся. Иногда бывает, что взломщик звонит пользователю, представляется системным администратором и просит сообщить пароль. Ваши пользователи не должны поддаваться на подобную уловку.

Даже если пользователь удачно выберет пароль и никому не сообщит его, существуют способы узнать его. Злоумышленник может незаметно подсмотреть, какие клавиши нажимает пользователь при вводе пароля. Проще всего реализовать этот способ в компьютерном классе. На рабочем месте сотрудника сделать это достаточно сложно. Пароль также может быть похищен в результате "подслушивания". Многие сетевые карты можно перевести в режим сбора поступающих на них пакетов. В результате пароль, передаваемый от клиента серверу, будет перехвачен. Это можно сделать как в локальной сети, так и в Internet. Чтобы уменьшить риск подслушивания пароля, в сетях Ethernet надо вместо концентраторов применять коммутаторы. В отличие от концентраторов, коммутаторы передают пакеты только тем компьютерам, которым они предназначены. При использовании концентраторов пароль может быть перехвачен лишь в том случае, когда злоумышленнику удастся разместить программу подслушивания на компьютере, на котором выполняется сервер, либо на компьютере, на котором работает клиент. Еще лучше использовать программные средства, выполняющие шифрование пароля. В этом случае подслушивание становится бессмысленным.

 

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

 

Влияние ошибок на выполнение программ

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

В серверах, как и в любых других программах, также могут встречаться ошибки. Однако, в отличие от обычных программ, ошибки в серверах могут повлечь за собой более тяжкие последствия для системы, так как серверы доступны всем пользователям сети. Предположим, что обычная программа, например man, содержит ошибку, в результате которой обычный пользователь может получить неограниченные полномочия. Если локальные пользователи заслуживают доверия, а у внешних пользователей нет доступа к ресурсам этого компьютера, система не пострадает. (Такое предположение не всегда оказывается верным, поэтому замеченные ошибки надо устранить как можно скорее). Если же Web-сервер, доступный из Internet, содержит ошибку, позволяющую проникнуть в систему, ею сможет воспользоваться любой желающий.

Проблема усугубляется тем, что многие серверы запускаются от имени пользователя root. Если программа (не обязательно сервер) запускается с полномочиями обычного пользователя, возможности злоумышленника, воспользовавшегося недостатками в защите, ограничены. Например, такая программа не позволит взломщику изменить содержимое файла /etc/passwd. Если же программа запускается от имени суперпользователя, возможности взломщика резко возрастают. В частности, он может создать новую учетную запись и пользоваться ею в дальнейшем. Привилегии root необходимы многим серверам для нормальной работы. Например, права пользователя root нужны серверам регистрации. Более того, чтобы принимать обращения через порт с номером ниже 1024, программа должна быть запущена от имени суперпользователя. (Полномочия root имеет суперсервер, но программы, запускаемые с его помощью, обычно выполняются с более низкими полномочиями.)

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

 

Источники информации о дополнениях к системе

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

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

• Web-узел конкретной версии Linux. Для каждого дистрибутивного пакета Linux поддерживается свой Web-узел, на котором публикуется новая информация о системе, в том числе сведения о дополнениях к программам. В состав подобного Web-узла включаются Web-страницы с данными о серверах, предназначенных для выполнения в системе. В частности, на этих Web-страницах размещаются сведения о недостатках в защите серверов и способах их устранения. Преимущество подобного подхода состоит в том, что вам нет необходимости обращаться к различным Web-серверам; все нужные сведения вы можете получить на одном узле. Однако такой подход имеет свой недостаток. Для того чтобы данные о дополнениях к программам попали с узлов компаний-разработчиков на узел дистрибутивного пакета Linux, необходимо определенное время. Иногда это время составляет несколько минут, но чаще всего информация появляется на Web-узле с задержкой в несколько часов и даже несколько дней.

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

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

 

Автоматическое обновление программ

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

• apt-get. Данная программа является стандартным компонентом Debian и систем, созданных на ее основе. Программа apt-get используется для инсталляции пакетов, а также автоматически обновляет установленное программное обеспечение. По команде apt-get update, за которой следует apt-get dist-upgrade, программа извлекает информацию в наличии дополнений и обновляет все пакеты, для которых были выпущены новые версии. Если вторую команду заменить на apt-get -s -u upgrade, программа apt-get будет предоставлять отчет об обновлениях, не инсталлируя их. Для того чтобы apt-get работала, в файле /etc/apt/sources.list необходимо указать хотя бы один узел, предназначенный для распространения дистрибутивных пакетов Debian. Существуют средства для переноса apt-get в другие системы.

• Red Hat Update Agent. Для обновления компонентов системы Red Hat используется программа Update Agent. Ее необходимо зарегистрировать, после чего она будет передавать информацию об аппаратных и программных средствах вашего компьютера на сервер Red Hat. После этого обновление системы осуществляется автоматически. Процесс настройки Update Agent достаточно сложен. Дополнительные сведения об этой программе вы можете получить по адресу http://www.redhat.com/docs/manuals/RHNetwork/ref-guide/.

Автоматические средства обновления программ позволяют эффективно устранять ошибки, снижающие уровень защиты системы, однако они имеют свои недостатки. Полагаясь на такие средства, вы принимаете на себя дополнительную ответственность. Автоматическое обновление иногда осуществляется некорректно. Например, обновленный пакет может содержать новые ошибки либо конфликтовать с другими программами (последнее чаще всего происходит в тех случаях, когда пакет, подлежащий обновлению, работает совместно с программами, написанными вами или установленными из tar-архивов). Не исключено также, что узел, управляющий автоматическим обновлением, подвергнется атаке и хакеры будут использовать его для распространения программ типа "троянский конь". Злоумышленники также могут захватить контроль над сервером DNS и перенаправлять обращения программ автоматического обновления на свой сервер. Пакеты, обновляющие программное обеспечение в системе Debian, обычно вызывают инсталляционные сценарии, требующие участия пользователя в процессе установки систем. По этой причине программу apt-get нельзя запускать с помощью cron. Даже если вы планируете регулярно вызывать данную программу, делать это необходимо вручную. (Посредством cron может вызываться лишь команда apt-get -s -u upgrade.) Средства автоматического обновления, как правило, не делают различий между дополнительными модулями, предназначенным для устранения недостатков в системе защиты, и дополнениями, которые были созданы для других целей и могут оказаться причиной возникновения проблем при работе других программ.

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

 

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

 

Инструменты, выявляющие попытки вторжения

Если взломщик проникает в систему, он изменяет ее конфигурацию в соответствии со своими потребностями. В зависимости от характера вторжения изменяется внешний вид Web-страниц, в файлах протоколов появляются новые записи, упрощающие обращение злоумышленников к системе, изменяются коды программ, а также появляются другие "сюрпризы". К сожалению, предсказать, какие именно действия предпримет взломщик, невозможно. Именно поэтому бороться с последствиями вторжения крайне сложно; если вы не знаете, что предпринял взломщик и каковы были его цели, нельзя доверять ни одной из системных программ. Радикальное решение — удалить с дисков компьютера всю информацию и повторно установить систему или восстановить ее с помощью резервной копии, сделанной еще до атаки.

Поскольку взломщик модифицирует системные файлы, наличие измененных файлов может служить признаком атаки. Обнаружить факт проникновения в систему можно лишь в том случае, если администратор заранее сохранил информацию о состоянии основных системных файлов, например, файла /etc/passwd и исполняемых программ в каталоге /bin. Эта информация должна храниться в закодированном виде либо ее следует записать на сменный носитель. Эти данные необходимо периодически использовать для проверки целостности файлов. Если файл, который не должен был подвергаться изменениям, окажется модифицированным, есть все основания полагать, что система была взломана. (Необходимо учитывать, что некоторые файлы мог изменить сам администратор. Например, при создании новой учетной записи данные записываются в файл /etc/passwd.)

Использование базы данных пакетов

Во многих версиях Linux есть инструмент, который можно использовать для контроля целостности файлов. Речь идет о базе данных пакетов. Система управления пакетами Debian и система RPM сохраняют в базе данных информацию об инсталлированных программах. Для сравнения программы на диске с исходным содержимым пакета надо указать опцию --verify (или -V) программы rpm. Ниже приведен пример вызова данной команды.

# rpm -V postfix

S.5.... Т с /etc/postfix/aliases

S.5.... Т с /etc/postfix/main.cf

В результате выполнения программы выводится информация о файлах, состояние которых не соответствует исходному. В начале каждой строки выходных данных содержится набор признаков, сообщающих о характере несоответствия файлов. Например, буква "S" указывает на то, что размер файла изменился, цифра "5" свидетельствует о несоответствии сумм MD5, а буква "Т" означает; что изменилось время модификации файла. Сообщения, отображаемые в данном примере, не являются признаком атаки, так как файлы, указанные программой, могут периодически изменяться при настройке пакета. Если же вы выясните, например, что был изменен исполняемый файл Postfix, вам необходимо начать поиски других признаков вторжения, а впоследствии предпринять меры для устранения последствий атаки.

В системе Debian аналогичные функции выполняет утилита dlocate, однако она не входит в составе Debian 2.2. Установив данную программу, вы сможете выполнить команду наподобие следующей:

# dlocate -md5check postfix

При выполнении данной команды проверяются суммы MD5 для содержимого пакета postfix и генерируется отчет о том, совпадают ли эти суммы для каждого файла.

Вместо проверки каждой программы вы можете проверить целостность всех пакетов, используя команду rpm -Va. Выходные данные будут насчитывать сотни строк, большинство из которых сообщают об изменениях конфигурационных файлов и файлов данных. Такие сообщения можно не принимать во внимание. Учитывая большой объем данных, желательно перенаправить выход в файл либо передать сгенерированную программой информацию утилите more или less.

Программы rpm и dlocate имеют существенные недостатки. Один из них состоит в том, что после инсталляции пакета нельзя выяснить, кто внес изменения в конфигурационный файл: системный администратор или взломщик. Кроме того, при желании взломщик может легко скрыть следы своего вмешательства. Для этого ему надо лишь использовать для установки модифицированных программ диспетчер пакетов. Например, если злоумышленник хочет заменить оболочку /bin/bash, ему достаточно установить новый RPM-пакет bash. В результате вызов rpm -Va не выявит изменений. По этой причине не следует полностью полагаться на диспетчер пакетов; желательно использовать наряду с ним дополнительные инструменты, предназначенные для выявления вмешательства в работу системы. Общее правило можно сформулировать так. Если диспетчер пакетов обнаружил изменения файлов, полученное сообщение следует рассматривать как признак того, что система подверглась атаке. Если же диспетчер пакетов не смог выявить изменения, этот факт не может быть гарантией целостности системы.

Использование Tripwire

Для выявления случаев несанкционированного доступа к системе разработан инструмент Tripwire (http://www.tripwire.org). Эта программа поставляется со многими версиями Linux. Если же в вашем дистрибутивном пакете она отсутствует, скопируйте ее с Web-узла. Версию Tripwire, входящую в состав дистрибутивного пакета, инсталлировать гораздо проще, чем пакет, скопированный с Web-узла, так как в ней заранее учтены набор файлов, используемых в системы, и их расположение. Tripwire сохраняет информацию о файлах в базе данных, этим данный инструмент напоминает диспетчеры пакетов, однако в нем реализованы специальные функции, превращающие его в специализированное средство обеспечения защиты. Tripwire может быть сконфигурирован для хранения информации о произвольном наборе файлов, причем сведения о файлах записываются в базу данных после инсталляции. Вы можете создать базу данных после того, как внесете необходимые изменения в конфигурационные файлы. В процессе работы Tripwire шифрует информацию, что не дает возможности взломщику изменить базу данных. Для обеспечения сохранности базы Tripwire поместите ее на сменный носитель, запретив запись данных.

Tripwire может работать в одном из следующих режимов.

• Генерация базы данных. При первом запуске Tripwire необходимо инициализировать базу данных. Для этого после редактирования конфигурационного файла вызовите команду tripwire -initialize. Выполнение этой процедуры может продлиться достаточно долго, так как программа Tripwire должна создать контрольные суммы всех файлов, контроль над которыми был предусмотрен при настройке данного инструмента. Сформированная база данных помещается в подкаталог databases текущего каталога, но желательно переместить ее в каталог /usr/lib/tripwire/databases. Запись данных в этот каталог следует запретить.

• Обновление базы данных. Если вы внесли изменения в систему, можете обновить базу данных Tripwire. Для этого вызовите команду tripwire -update путь_к_файлу , указав файл, который необходимо учесть в базе данных.

• Интерактивное обновление базы данных. Если внесенные вами изменения затрагивают несколько компонентов системы или если вы установили большой пакет, запустите Tripwire в интерактивном режиме. Для этого вызовите команду tripwire -interactive. В этом случае программа будет отыскивать файлы, подвергшиеся изменениям, и осведомляться у вас, следует ли учитывать эти изменения в базе данных.

• Проверка целостности системы. Этот режим используется по умолчанию. Для того чтобы запустить Tripwire в таком режиме, достаточно ввести в командной строке tripwire. Проверку целостности системы желательно выполнять каждый день. Периодический вызов Tripwire можно организовать с помощью cron.

Работой Tripwire управляет конфигурационный файл /etc/tripwire/tw.config. Подобно многим другим конфигурационным файлам, строки, начинающиеся с символа #, содержат комментарии. В остальных строках указываются каталоги, предназначенные для проверки. Соответствующие записи имеют следующий формат:

[!|=] объект [ флаги_выбора | шаблон ]

Назначение компонентов записи приведено ниже.

• !. Если данный символ предшествует имени объекта, то указанный файл или каталог не подлежит проверке. Если объектом является каталог, содержащиеся в нем подкаталоги также не проверяются.

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

• объект . Объект представляет собой имя файла или каталога, предназначенного для проверки, например /etc или /usr. Если в качестве объекта указан каталог, выполняется проверка всех его подкаталогов. Не проверяются лишь подкаталоги, представляющие собой отдельные файловые системы. Например, если содержимое каталогов /usr и /usr/local находится в разных разделах, то, чтобы проверить все дерева подкаталогов, вы должны создать записи как для /usr, так и для /usr/local.

• флаги_выбора . Данный компонент записи указывает Tripwire на то, какие типы изменений должны быть отражены в отчете. Флаги задаются в формате [+|-] [pinugsamc123456789]... . Символ + или - разрешает или запрещает включать сведения в отчет. Остальные символы определяют типы проверки. Например, p задает поверку прав доступа, i — проверку индексных дескрипторов (mode), n соответствует числу связей, u — идентификатору владельца файла, g — идентификатору группы, s — размеру файла, а — времени доступа, m — времени модификации, с — времени создания индексного дескриптора, а числа 0-9 задают особенности контрольного суммирования.

• шаблон . Вместо флагов выбора вы можете задать шаблон. По умолчанию принимается шаблон R, соответствующий +pinugsm12-ac3456789. В качестве примеров других шаблонов можно привести L (+pinugsacm123456789), используемый для проверки файлов протоколов, N (+pinugsamc123456789), который выполняет подробную проверку, но проверка эта занимает много времени, и E (-pinugsamc123456789), игнорирующий все типы проверки.

Сформировав конфигурационный файл Tripwire, вы должны запустить программу в режиме генерации базы данных. В результате файл базы данных будет создан в каталоге databases. При последующих запусках Tripwire будет отыскивать файл базы данных в каталоге /usr/lib/tripwire/databases. Этот файл очень важен, поэтому вы должны обеспечить его сохранность. Способы сохранения файла базы данных описаны ниже.

• Файл базы данных может храниться на сменном носителе, защищенном от записи, например на дискете или компакт-диске. Если вы собираетесь выполнять проверку, периодически запуская Tripwire с помощью cron, носитель может быть постоянно смонтирован (такой подход создает неудобства при работе с системой). Если вы предполагаете запускать Tripwire вручную, носитель можно монтировать непосредственно перед проверкой.

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

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

• Tripwire поддерживает кодирование данных, поэтому файл базы данных можно сохранить в зашифрованном виде. Чтобы изменить содержимое файла базы данных, взломщик должен знать пароль, использовавшийся при кодировании.

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

 

Способы, позволяющие выявить вторжение в систему

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

• Записи в файлах протоколов. Файлы протоколов, располагающиеся в каталоге /var/log, содержат информацию о работе серверов. Как было сказано ранее, для обработки файлов вручную требуется слишком много времени, и не каждый администратор может позволить себе заняться этим. Однако с помощью специализированных инструментов, например SWATCH, вы можете выявить факты, свидетельствующие о взломе. Например, если вы обнаружите, что пользователь, находящийся в отпуске в другой стране, на днях зарегистрировался на сервере, это означает, что его учетной записью воспользовался кто-то другой.

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

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

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

• Неожиданное увеличение сетевого трафика. Если трафик неожиданно увеличился, возможно, что причиной этого является деятельность злоумышленника, связанная со взломом системы. Не исключено, конечно, что трафик увеличился в результате роста популярности вашего узла. (Причиной внезапного роста популярности может быть появление ссылки на ваш узел на одном из часто посещаемых узлов.) Убедившись в увеличении трафика, вам следует проверить характер соединений, устанавливаемых с этого компьютера. Например, если с компьютера, на котором выполняется только Web-сервер, устанавливаются Telnet-соединения с другими машинами вашей сети, это свидетельствует о том, что компьютер используется взломщиками для дальнейшего проникновения в вашу сеть.

Существуют также другие признаки вторжения в систему. Дело в том, что большинство атак предпринимается не опытными хакерами, а малограмотными взломщиками, которые пользуются чужими сценариями. Такие сценарии неминуемо оставляют на компьютере следы своей работы. К сожалению, каждый сценарий, написанный с целью взлома системы, проявляет себя по-своему, поэтому составить перечень признаков, по которым можно было бы выявить вторжение в систему, крайне сложно. Материалы на эту тему публикуются на многих Web-узлах, посвященных вопросам защиты.

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

 

Действия при обнаружении факта взлома системы

При выявлении факта вторжения в систему рекомендуется выполнить следующие действия.

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

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

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

• Устранить последствия атаки. К сожалению, действия по устранению последствий взлома не ограничиваются восстановлением файлов, которые были изменены злоумышленником. Вы можете пропустить какой-либо из файлов и предоставить тем самым возможность взломщику повторить атаку. Вам необходимо полностью очистить жесткий диск или, по крайней мере, те разделы, в которых содержались компоненты системы Linux. При необходимости раздел /home можно оставить нетронутым. Затем следует повторно инсталлировать систему с нуля либо восстановить ее с резервной копии, которая была создана до атаки. На этом этапе на следует подключать компьютер к сети.

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

• Устранить недостатки в защите. Если на втором этапе вам удалось выяснить причины, позволившие злоумышленнику поникнуть в систему, следует устранить их. Целесообразно также принять меры общего характера для повышения уровня защиты, например, инсталлировать в системе инструмент Tripwire (если он не был инсталлирован ранее) или установить и настроить брандмауэр.

• Подключить компьютер к сети. После устранения всех проблем надо подключить компьютер к сети и возобновить его работу.

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

 

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

 

Web-узлы, посвященные вопросам защиты

В Internet поддерживаются Web-узлы, информирующие практически обо всех вопросах, связанных с использованием компьютеров, и защита системы не является исключением. Многие Web-узлы предоставляют самую новую информацию по этой теме. Ниже перечислены Web-узлы, содержимое которых должен периодически просматривать каждый системный администратор.

• Web-узел, посвященный используемой версии Linux. Практически для каждого дистрибутивного пакета Linux в Internet создан Web-узел, содержащий информацию о данной версии системы. Немалую часть этой информации составляют вопросы защиты. Как правило, на таких узлах публикуются сведения о вновь обнаруженных недостатках в защите программ и ссылки на версии программ, в которых эти проблемы устранены.

• Web-узел CERT/CC. Computer Emergency Response Team Coordination Center (CERT/CC) — одна из ведущих организаций, занимающаяся проблемами защиты. Web-узел CERT/CC находится по адресу http://www.cert.org.

• Web-узел CIAC. Организация Computer Incident Advisory Capability (CIAC) поддерживает Web-узел, расположенный по адресу http://www.ciac.org/ciac/. На нем публикуются сведения такого же характера, как и на узле CERT/CC.

• Раздел Linux Weekly News, посвященный защите системы. Linux Weekly News (http://lwn.net) — сетевая газета, посвященная использованию Linux. В одном из ее разделов публикуются сведения о способах повышения безопасности различных дистрибутивных пакетов Linux. (URL раздела часто изменяется. Для того, чтобы попасть на соответствующую Web-страницу, надо активизировать ссылку Security на главной странице Linux Weekly News.)

• Web-узел SecurityFocus. На этом узле (http://www.securityfocus.com) публикуются новости о вопросах защиты. Информация на этом сервере представляет собой своеобразный дайджест, составленный на основе данных, представленных на узлах CERT/CC и CIAC.

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

 

Списки рассылки и группы новостей, посвященные вопросам защиты

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

Совет

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

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

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

• Список рассылки CERT/CC. Помимо Web-узла, CERT/CC поддерживает также список рассылки, посвященный вопросам защиты. Для того чтобы подписаться на этот список, надо отправить почтовое сообщение по адресу [email protected], включив в него строку subscribe cert-advisory.

• Список рассылки CIAC. Подобно CERT/CC, CIAC передает материалы, имеющие отношение к защите систем, с помощью списка рассылки. Для того чтобы подписаться на данный список, надо отправить почтовое сообщение по адресу [email protected], включив в него строку subscribe ciac-bulletin.

• Список рассылки Bugtraq. Данный список создан не только для распространения новых материалов, но и для организации дискуссий. Участвуя в этом списке, вы можете получать от других администраторов полезные советы по организации защиты системы. Подписаться на материалы списка можно, направив письмо по адресу [email protected]. В тело письма надо включить строку subscribe bugtraq.

• Группы новостей comp.security . В иерархии comp.security существует несколько групп новостей (например, comp.security.unix). Среди них есть группы, посвященные отдельным (даже конкретным) типам продуктов. В качестве примера подобной группы можно привести comp.security.firewalls.

• Группа новостей comp.os.linux.security . Данная группа посвящена вопросам безопасности Linux.

На заметку

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

 

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

На заметку

В данном разделе обсуждаются лишь общие вопросы создания поддерева chroot . Более подробно конфигурация серверов для работы в пределах поддерева будет рассмотрена в следующем разделе. Там же будет приведен пример подготовки сервера BIND для выполнения в рамках поддерева chroot .

 

Создание поддерева

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

В поддереве chroot надо создать некоторые из каталогов и подкаталогов, присутствующие в обычной файловой системе. Вероятнее всего, вам потребуется лишь ограниченное количество подкаталогов Linux. Чаще всего для выполнения сервера в поддереве chroot приходится создавать каталоги /bin, /sbin, /usr, /lib, /etc и /var. В эти каталоги не следует копировать файлы, присутствующие в соответствующих каталогах файловой системы Linux; нельзя забывать, что поддерево chroot создается именно для того, чтобы ограничить набор инструментов, доступных серверу.

Если в пределах поддерева chroot должно выполняться несколько серверов, надо для каждого из них создать отдельное поддерево. Например, если в таком режиме предполагается запустить серверы FTP и sendmail, вы можете использовать в качестве корневых каталогов поддеревьев каталоги /opt/chroot/ftp и /opt/chroot/sendmail.

 

Копирование файлов сервера

Сформировав поддерево chroot, надо скопировать в содержащиеся в нем каталоги требуемые файлы. Набор необходимых файлов зависит от особенностей сервера. Если сервер самостоятельно вызывает функцию chroot(), вам нет необходимости размещать в пределах поддерева chroot исполняемые файлы сервера. Вы можете запустить сервер за пределами поддерева chroot, указав ему расположение поддерева. После вызова chroot() сфера действий сервера будет ограничена сформированным вами поддеревом. Поскольку сервер, самостоятельно вызывающий chroot(), может читать конфигурационные файлы, размещенные за пределами поддерева, число файлов, которые необходимо поместить в каталоги поддерева chroot, сводится к минимуму. Вам придется скопировать лишь те файлы, которые требуются серверу для работы после вызова chroot(). Примером сервера, функционирующего подобным образом, является анонимный сервер FTP. (Подробно вопросы работа сервера FTP рассматривалась в главе 21.

Если сервер не вызывает самостоятельно функцию chroot(), его следует запускать посредством утилиты chroot. При этом в каталоги поддерева chroot необходимо скопировать исполняемые и конфигурационные файлы сервера, а также все файлы, необходимые серверу в процессе работы. Кроме того, иногда приходится помещать в каталоги поддерева chroot некоторые системные файлы. Определить набор файлов, необходимых серверу, достаточно сложно. Для того чтобы выяснить, какие файлы требуются в процессе работы, надо прочитать документацию, а если нужные сведения там отсутствуют, вам придется проанализировать содержимое дистрибутивного пакета. Для получения информации о файлах, содержащихся в пакете, можно использовать инструменты tar, rpm или dpkg. Очевидно, что копировать в каталоги поддерева chroot надо не все файлы; например, для работы сервера не нужна документация. Чтобы выяснить, какие файлы необходимы серверу, можно использовать программу strace. Вызвав команду strace имя_серверной_программы , вы получите сведения о файлах, используемых в процессе работы сервера, в том числе имена файлов, которые сервер открывает самостоятельно.

На заметку

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

 

Копирование системных файлов

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

• Библиотеки. Во время работы многие серверы используют динамические библиотеки. Обычно они хранятся в каталоге /lib или /usr/lib. Выяснить, какие библиотеки нужны конкретному серверу, позволяет программа ldd. Например, чтобы определить, какие библиотеки использует сервер имен, надо выполнить команду ldd /usr/sbin/named. Файлы библиотек надо поместить в каталог поддерева chroot.

• Программы поддержки. Для работы некоторых серверов нужны дополнительные программы. Например, если Web-сервер поддерживает CGI-сценарии, ему могут понадобиться интерпретатор Perl (/usr/bin/perl) и файлы, обеспечивающие работу этого интерпретатора. Исполняемый файл Perl и дополнительные файлы надо скопировать в соответствующий каталог поддерева chroot. Кроме того, программы, необходимые для работы сервера, могут, в свою очередь, использовать файлы библиотек. В некоторых случаях объем данных, применяемых для поддержки языков сценариев, намного превышает объем Web-сервера.

• Файлы устройств. Ряд серверов непосредственно обращается к файлам устройств. Например, сервер резервного копирования взаимодействует с накопителем на магнитных лентах, а некоторым библиотекам и программам нужны специальные файлы устройств, такие как /dev/zero или /dev/null. Обычно файлы устройств располагаются в каталоге /dev. Копировать файлы из этого каталога бессмысленно, вместо этого надо повторно создать их в поддереве с помощью mknod. Соответствующая команда может выглядеть следующим образом: mknod /opt/chroot/dev/st0 с 9 0. Файлы устройств предоставляют доступ к ресурсам компьютера, поэтому создавать их в поддереве chroot следует только в том случае, когда они действительно необходимы.

• Специальные файловые системы. Иногда серверы используют специальные файловые системы или инструменты, предназначенные для работы с такими файловыми системами. Например, некоторые серверы обращаются к /proc. Подобные каталоги нельзя непосредственно копировать. Вместо этого надо создать дополнительную запись в файле /etc/fstab и смонтировать файловую систему в пределах поддерева chroot. Исходную систему /proc нельзя удалять, ее надо дублировать. Необходимо помнить, что при наличии доступа сервера к /proc взломщику автоматически предоставляются дополнительные возможности для контроля над системой.

• Базы данных с информацией о пользователях. Во время работы ряд серверов обращается к /etc/passwd, /etc/group, /etc/shadow и другим файлам, содержащим информацию о пользователях. Серверам, которые используют Pluggable Authentication Module, необходима инфраструктура РАМ, в частности, файл /etc/pam.conf, содержимое /etc/pam.d и /etc/security, а также библиотеки в файлах /lib и /lib/security (в именах файлов библиотек содержатся символы pam). Для того чтобы выяснить, какие файлы необходимо скопировать в каталоги поддерева chroot, надо проанализировать содержимое пакета РАМ.

• Файлы протоколов. Если сервер создает во время работы файлы протоколов, вам необходимо подготовить каталоги для их размещения. Некоторые серверы используют при создании файлов протоколов демон syslogd, в этом случае вам надо скопировать данную программу в поддерево chroot. Многие серверы можно сконфигурировать так, чтобы протоколирование выполнялось без использования syslogd.

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

На заметку

Чтобы не создавать угрозу безопасности системы, помещайте в каталоги поддерева chroot лишь минимальный набор файлов. Копировать файл следует только в том случае, если вы твердо знаете, что этот файл используется в работе сервера. Что же касается остальных файлов, выяснить, необходимы ли они, можно, запустив сервер на выполнение (если в сервере предусмотрен режим отладки, желательно включить его). Если серверу недостает какого-либо файла, он сообщит об этом.

 

Создав поддерево chroot, можно приступать к его использованию. Для этого надо сконфигурировать сервер для работы в рамках поддерева, организовать запуск сервера и обеспечить контроль доступа к поддереву chroot извне. Решение этих задач рассматривается в данном разделе. Здесь же будет приведен пример запуска сервера имен в пределах поддерева chroot.

 

Запуск сервера в рамках поддерева

chroot

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

Если сервер не вызывает chroot(), необходимо в первую очередь убедиться, что он способен работать в обычном окружении Linux, для чего следует запустить сервер за пределами поддерева chroot. Затем надо скопировать исполняемые файлы сервера и конфигурационные файлы в каталоги поддерева и удостовериться, что это не повлияло на работу сервера. После настройки среды поддерева вы можете запускать сервер с помощью утилиты chroot. Соответствующая команда имеет следующий вид:

chroot новый_корневой_каталог имя_сервера [ опции_сервера ]

Здесь под новым корневым каталогом подразумевается каталог, который выполняет роль корня поддерева chroot. Кроме того, при вызове команды задаются имя сервера, предназначенного для запуска, и его опции; путь к серверу определяется относительно корневого каталога поддерева. Например, если исполняемый файл сервера имеет имя /opt/chroot/bin/server, где /opt/chroot — корневой каталог поддерева, то вызов chroot будет выглядеть следующим образом:

# chroot /opt/chroot /bin/server

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

 

Управление доступом к каталогам поддерева

chroot

Поддерево chroot реализует одностороннюю защиту — программы, выполняющиеся в рамках поддерева, не имеют доступа к ресурсам за его пределами. Поэтому вы можете ограничить доступ и в другом направлении. Для этого надо указать в качестве владельца каталогов поддерева chroot пользователя root и установить соответствующие права доступа к этим подкаталогам, например задать значение 0640 (rw-r-----). Запускать сервер следует от имени пользователя, который принадлежит группе, специально созданной для этой цели. В результате сервер будет иметь право читать файлы, находящиеся в каталогах поддерева chroot, а из-за пределов поддерева к данным сможет обращаться только пользователь root. Если же при работе сервера возникает необходимость в записи файлов, следует предусмотреть это при установке прав доступа.

 

Запуск сервера BIND в рамках поддерева

chroot

Ранее описывался процесс подготовки сервера к запуску в рамках поддерева chroot. Чтобы лучше понять изложенный выше материал, желательно рассмотреть запуск конкретного сервера в подобном режиме. В качестве примера выберем сервер имен BIND, работа которого обсуждалась в главе 18. При подготовке сервера к работе в пределах поддерева chroot будет в основном использоваться конфигурация, устанавливаемая по умолчанию. Процедура инсталляции данного сервера в различных версиях Linux имеет свои характерные особенности; для данного примера выберем версию Debian 2.2.

На заметку

В данном разделе рассматривается запуск сервера BIND с использованием программы chroot . В качестве примера сервера, вызывающего функцию chroot() самостоятельно, можно привести сервер FTP.

Прежде всего вам необходимо инсталлировать стандартный пакет BIND. Поскольку сервер инсталлируется в системе Debian, для его установки можно использовать программу apt-get.

# apt-get install bind

В процессе выполнения сценарий инсталляции спрашивает, следует ли добавить адрес локального сервера имен в файл /etc/resolv.conf. На этот вопрос я даю положительный ответ, но для демонстрации работы сервера в рамках поддерева chroot это не имеет значения. По окончании установки система Debian запускает сервер имен. Проверить, работает ли сервер, вы можете с помощью следующих двух команд:

# ps aux | grep named

root 7656 0.0 1.5 2184 1492 ? S 13:29 0:00 \

/usr/sbin/named

# host awl.com localhost

awl.com A 165.193.123.224

Вторая команда позволяет убедиться в том, что сервер BIND установлен и работает: она выводит IP-адрес узла awl.com, причем для преобразования имени используется сервер на компьютере localhost. Имя awl.com вы можете заменить любым другим именем узла, расположенного в Internet, а вместо localhost можно указать IP-адрес или имя вашего компьютера. Если система сообщит о том, что команда не найдена (command not found), вам надо установить пакет dnsutils, содержащий программу host. (В других версиях Linux пакет подобного назначения может называться иначе, например bind-utils).

Убедившись, что сервер работает, завершите его выполнение с помощью команды

# /etc/init.d/bind stop

Затем вам надо создать поддерево chroot и скопировать в него файлы BIND.

# mkdir -p /opt/chroot/usr/sbin /opt/chroot/var/cache/bind

# mkdir /opt/chroot/lib /opt/chroot/etc

# cp /usr/sbin/named /opt/chroot/usr/sbin

# cp -rp /etc/bind/ /opt/chroot/etc

На заметку

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

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

# ldd /usr/sbin/named

libc.so.6 => /lib/libc.so.6 (0x40017000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

# cp/lib/libc.so.6 /lib/ld-linux.so.2 /opt/chroot/lib

На этом этапе можно снова проверить функционирование сервера.

# chroot /opt/chroot /usr/sbin/named

# host awl.com localhost

awl.com A 165.193.123.224

Если сервер не работает, убедитесь в том, что в системе выполняется только один экземпляр named, и проверьте, все ли файлы вы скопировали в каталог поддерева chroot. Обеспечив нормальную работу сервера, измените сценарий запуска BIND (в системе Debian это /etc/init.d/bind) так, чтобы сервер запускался посредством команды chroot. Безусловно, вы можете запретить выполнение сценария SysV и запустить сервер имен другим способом. Многие сценарии SysV используют вспомогательные программы (в Debian это start-stop-daemon и ndc). Данные программы могут создавать файлы в каталоге /var/run, поэтому вам надо создать в поддереве chroot нужные каталоги и скопировать файлы программ.

# mkdir -p /opt/chroot/sbin /opt/chroot/var/run

# cp /usr/sbin/ndc /opt/chroot/usr/sbin

# cp /sbin/start-stop-daemon /opt/chroot/sbin

При редактировании сценария запуска SysV перед каждым вхождением start-stop-daemon и ndc надо добавить последовательность символов chroot /opt/chroot. Однако на этом работа не заканчивается, поскольку start-stop-daemon обращается к файловой системе /proc, которая не доступна из поддерева chroot. Чтобы обеспечить доступ к ней, необходимо внести изменения в файл /etc/fstab — скопировать строку, содержащую /proc, и изменить ее на /opt/chroot/proc. Затем вы должны вызвать команду mount -а, чтобы смонтировать /proc в поддереве chroot.

Внимание

Поскольку файловая система /proc предоставляет контроль над компьютером, дублировать ее нежелательно. Лучше отредактировать сценарий запуска SysV так, чтобы он не использовал start-stop-daemon , либо отказаться от сценария SysV и организовать запуск сервера другим способом.

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

# /etc/init.d/bind start

# host awl.com localhost

awl.com A 165.193.123.224

Если вы хотите удостовериться в том, что сервер выполняется в среде поддерева chroot, вам надо удалить исполняемый файл сервера из каталога /usr/sbin и конфигурационные файлы из каталога /etc/bind, а потом перезапустить сервер. Если сервер работает, то выполняться он может только в рамках поддерева chroot.

Вместо того чтобы запускать сервер BIND посредством утилиты chroot, вы можете использовать опцию -t программы named, которая разрешает вызов функции chroot() сервером имен. Соответствующая команда имеет следующий вид:

# /usr/sbin/named -t /opt/chroot

Данный подход намного проще описанного выше, так как при этом вам придется копировать в каталоги поддерева chroot гораздо меньше файлов, в частности, вы можете оставить программу named и библиотеки в тех каталогах, в которых они были записаны при инсталляции. Скопировать конфигурационные файлы необходимо, поскольку сервер имен читает их уже после вызова chroot(). При использовании опции -t упрощается подготовка сервера для запуска посредством сценария SysV, так как при нет необходимости дублировать файловую систему /proc.

Детали подготовки сервера к выполнению в рамках поддерева chroot зависят от типа сервера и версии Linux, однако общий ход процедуры остается прежним. Возможно, вам придется немного модифицировать среду поддерева chroot, например, изменить права доступа к каталогам или настроить сервер для запуска от имени пользователя, отличного от root.

 

В ядре 2.4.x предусмотрены расширенные опции маршрутизации. Они располагаются в меню Networking Options. Многие из них являются подопциями опции IP: Advanced Router; чтобы активизировать подопции, надо активизировать саму опцию IP: Advanced Router. Расширенные опции маршрутизации позволяют задавать особенности маршрутизации пакетов: способы назначения приоритетов, обработку приоритетов, указанных в принятых пакетах, поддержку типов пакетов и т.д. Чтобы активизировать опцию, надо установить переключатель в положение Y (или M, если вы хотите, чтобы средства поддержки этой опции были реализованы в виде модуля). Многие опции требуют настройки посредством специальных утилит. Некоторые из них достаточно сложны, поэтому в данном разделе приведены лишь общие сведения о соответствующих инструментах.

На заметку

В различных версиях ядра наборы опций могут различаться: некоторые из них разделяются на отдельные опции, другие объединяются в одну. В данном разделе описаны опции ядра 2.4.17. В других версиях ядра опции могут отличаться от описанных здесь.

 

Политика маршрутизации

Одна из опций, определяющих использование расширенных средств маршрутизации Linux, называется IP: Policy Routing. Она поддерживает следующие способы маршрутизации.

• Фильтрация на основе маркеров. Пакеты, передаваемые по сети, могут содержать специальные данные — маркеры. В случае необходимости можно организовать передачу пакетов, помеченных такими маркерами, по специальным маршрутам. Фильтрацией на базе маркеров управляет опция IP: Use Netfilter MARK Value as Routing Key. Если вы собираетесь активизировать эту опцию, надо установить также опцию Packet Filtering, находящуюся в том же меню.

• Быстрое NAT-преобразование. Средства NAT позволяют "спрятать" компьютеры сети так, чтобы они были невидимы для остальных узлов Internet. При этом всю сеть представляет один компьютер, а единственный IP-адрес, выделенный для этого компьютера, используется для организации работы всей сети. Если вы хотите, чтобы ваша система функционировала как NAT-маршрутизатор, вы можете установить опцию IP: Fast NAT, однако это не обязательное условие NAT-маршрутизации. (Подробно средства NAT рассматриваются в главе 25.)

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

 

Тип сервиса

В IP-пакетах предусмотрено специальное поле под названием TOS (Type-of-Service — тип сервиса). Это поле позволяет компонентам сети определять, какие из пакетов требуют специальной обработки. В результате подобной обработки для некоторых клиентов и серверов реализуются более быстрые и надежные соединения по сравнению с другими. Для того чтобы разрешить обработку этого поля, надо активизировать опцию ядра IP: Use TOS Value as Routing Key.

Данная опция также используется при работе пакета iproute2. В поле TOS содержится числовое значение. Большинство маршрутизаторов игнорирует поле TOS, поэтому чаще всего его содержимое не влияет на качество соединения.

 

Передача пакетов по различным маршрутам

Большинство маршрутизаторов проверяет адрес назначения приходящего пакета на соответствие правилам, содержащимся в таблице маршрутизации. Например, в таблице может быть указано, что пакеты, направленные в сеть 10.201.0.0/16, должны передаваться через интерфейс eth1. He исключено, что адрес пакета будет соответствовать двум правилам; это не приводит к возникновению конфликта. Предположим, что, помимо приведенного выше правила, в таблице указано, что пакеты, адресованные в сеть 10.201.34.0/24, должны передаваться через интерфейс ррр0. Если некоторый пакет отвечает обоим условиям, к нему будет применено второе правило, как более конкретное. Если же в таблицу будет включено еще одно правило для сети 10.201.0.0/16, то пакет будет обработан посредством того правила, которое первым встретится маршрутизатору.

При активизации опции ядра IP: Equal Cost Multipath система будет вести себя следующим образом. Если пакет соответствует нескольким правилам маршрутизации, то правило, применяемое для обработки пакета, будет выбрано случайным образом. Такой алгоритм можно рассматривать как примитивный способ распределения нагрузки между различными соединениями. Более конкретному правилу отдается предпочтение перед более общим.

 

Протоколирование работы маршрутизатора

Опция IP: Verbose Route Monitoring управляет выводом сведений о маршрутизации в файл протокола. В обычных условиях ядро не протоколирует ход маршрутизации пакетов. Если данная опция установлена, регистрируются сведения о пакетах, корректность которых вызывает сомнения.

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

 

Использование больших таблиц маршрутизации

Обычно ядро Linux настраивается для работы с таблицами маршрутизации, содержащими не больше 64 записей. Если этих записей не хватает для того, чтобы задать требуемую конфигурацию маршрутизатора, вам надо активизировать опцию IP: Large Routing Tables. Эта опция позволяет использовать таблицы маршрутизации большего размера.

 

Поддержка группового вещания

Как правило, в Internet-взаимодействии участвуют два компьютера, например, клиент обращается к Web-серверу, а Web-сервер возвращает клиенту ответ на его запрос. При этом пакет, передаваемый по сети, предназначен только одному получателю. Существует также широковещательная передача данных, когда передаваемый пакет адресован всем узлам локальной сети. Для широковещательной передачи в пределах локальной сети используется адрес получателя 255.255.255.255, который определяет все компьютеры, подключенные к этой сети. Если широковещательный пакет направляется в другую сеть, адрес получателя формируется путем замены части адреса, соответствующего узлу сети, на число, состоящее из единиц. Например, широковещательный адрес для сети 192.168.34.0/24 будет иметь вид 192.168.34.255. Широковещательный адрес используют клиенты DHCP для обращения к серверу DHCP. Кроме того, широковещательная передача применяется при работе некоторых других протоколов.

При групповом вещании пакеты адресуются одновременно нескольким получателям (но не всем узлам сети). Такой способ передачи информации применяется для трансляции аудио- и видеоданных. Для организации группового вещания предназначена система Multicast Backbone (MBONE; http://www.cs.columbia.edu/~hgs/internet/mbone-faq.html). Данная система реализует групповое вещание в пределах Internet. Существуют также средства группового вещания с ограниченными возможностями; такой тип группового вещания называется локальными связями (link-local). Эти средства не нашли широкого распространения, но иногда используются при взаимодействии маршрутизаторов.

Если вы хотите, чтобы ваш маршрутизатор поддерживал групповое вещание, установите опцию IP: Multicast Routing. Кроме того, для управления групповым вещанием также предусмотрены две подопции данной опции: IP: PIM-SM Version 1 Support и IP: PIM-SM Version 2 Support. Они управляют передачей сообщений группового вещания по сетям с ограниченной пропускной способностью.

Помимо опций ядра, для поддержки группового вещания должно использоваться специализированное программное обеспечение, например mrouted. Этот инструмент предназначен для настройки базовых средств группового вещания Linux. Если данная программа не входит в состав дистрибутивного пакета, вы можете получить ее, обратившись по адресу ftp://ftp.rge.com/pub/communications/ipmulti/beta-test/; подробная информация о ней приведена в документе http://jukie.net/~bart/multicast/Linux-Mrouted-MiniHOWTO.html. Если у вас установлена опция IP: PIM-SM Version 2 Support, вам понадобится программа pimd (http://netweb.usc.edu/pim/pimd/).

 

Качество сервиса

В большинстве случаев средства маршрутизации Linux обрабатывают пакеты по принципу "первый пришёл/первый обработан" (first-come/first-served). Такая процедура дает хорошие результаты в тех случаях, когда пропускная способность линий достаточна для передачи всех пакетов с минимальной задержкой и когда нет необходимости предоставлять некоторым пакетам более высокий приоритет по сравнению с остальными. Если нагрузка на маршрутизатор велика, приходится использовать другие способы обработки пакетов, которые позволяют уменьшить поток данных на некоторые узлы или гарантировать своевременную доставку информации определенным пользователям или приложениям. Для установки подобных режимов маршрутизации в системе Linux предусмотрен ряд опций. Они объединены в подменю QoS and/or Fair Queueing, которое вызывается с помощью одноименного пункта меню Networking Options.

Активизация опций меню QoS and/or Fair Queueing сама по себе не приведет к изменению работы системы. Подобно другим опциям, которые управляют средствами расширенной маршрутизации, эти опции предполагают использование пакета iproute2. Если вы не уверены в том, что данные средства понадобятся вам, скомпилируйте компоненты ядра, предназначенные для их поддержки, в виде модулей. В результате соответствующие компоненты не будут занимать ресурсы компьютера, но вы всегда сможете воспользоваться ими.

Внимание

Перед компиляцией ядра внимательно ознакомьтесь с документацией. В ядре 2.4.17 опция, реализующая алгоритм CSZ, работает некорректно. Активизация этой опции может привести к ненадежной работе маршрутизатора.

 

Пакет iproute2 входит в состав многих дистрибутивных пакетов Linux. Часто он поставляется под именем iproute. Вы можете скопировать данный пакет с FTP-узла, предназначенного для его поддержки, обратившись по адресу ftp://ftp.inr.ac.ru/ip-routing/. Пакет iproute2 содержит несколько программ, две из которых (ip и tc) рассматриваются в данной главе.

 

Использование

ip

Программа ip предназначена для управления таблицами маршрутизации, в частности, правилами, определенными в них. Выполнение данной программы зависит от значений некоторых подопций опции IP: Advanced Router. Программа ip вызывается следующим образом:

ip команда [list | add | del] селектор действие

В утилите ip предусмотрено несколько команд. Наиболее важная из них — команда rule. Она позволяет добавлять (add), удалять (del) правила маршрутизации или отображать информацию о существующих правилах (list). Правила определяются с помощью селектора, который имеет структуру

[from адрес ] [to адрес ] [tos тип_сервиса ] [dev имя_устройства ] [pref число ]

Элементы from и to определяют IP-адреса, а элемент tos задает тип сервиса (тип сервиса представляет собой число, например 4). Элемент dev определяет имя сетевого устройства (например, eth0), a pref задает номер предпочтения. Набор элементов сообщает Linux о том, как идентифицируются пакеты, к которым должно быть применено данное правило. Действие, указываемое в команде, задается в следующем формате:

[table идентификатор_таблицы ] [nat адрес ] [prohibit | reject | unreachable]

Идентификатор таблицы — это число, которое идентифицирует таблицу маршрутизации, элемент nat позволяет задать для пакета новый адрес источника, a prohibit, reject и unreachable — это коды, определяющие различные варианты отказа от пакета.

Пример реальной команды ip приведен ниже.

# ip rule add from 172.20.24.128 dev eth0 table 2

Правило, определяемое с помощью данной команды, указывает системе на то, что для обработки трафика с адреса 172.20.24.128 через eth0 должна использоваться таблица маршрутизации 2. У вас, вероятно, возникнет вопрос, что значит таблица маршрутизации 2? В системе Linux для заполнения таблицы маршрутизации используется команда route. Расширенные средства маршрутизации позволяют работать с несколькими таблицами, создаваемыми посредством команды ip route. При обработке различных типов трафика можно быстро переключаться между разными таблицами. Приведенная выше команда сложнее обычной команды route, но она предоставляет возможности, которые не может обеспечить route. Вы можете использовать ip route так же, как и route, единственное отличие состоит в том, что вам необходимо задать номер таблицы. Например, для добавления маршрута в таблицу 2 можно использовать следующую команду:

ip route add 10.201.0.0/16 dev eth1 table 2

Если не принимать во внимание имя программы ip и элемент table 2, то данная команда эквивалентна команде route. Она сообщает системе о том, что все данные, адресованные в сеть 10.201.0.0/16, должны передаваться через интерфейс eth1.

 

Использование

tc

Утилита tc использует средства ядра, которые активизируются посредством опций меню QoS and/or Fair Queueing. Данная программа управляет исходящим трафиком, в частности, не позволяет одному типу трафика монополизировать пропускную способность линии связи. В качестве примера рассмотрим следующую ситуацию. Предположим, что в организации имеются две подсети; каждая из них обслуживает офис, в котором работают около десяти пользователей. Если пользователи одной подсети запускают программы, генерирующие большой объем исходящих данных, производительность сетевых средств пользователей, работающих в другом офисе, может оказаться недопустимо низкой. Программа tc позволяет распределить ресурсы таким образом, что каждой из подсетей будет гарантированно выделяться часть пропускной способности линии.

Программа вызывается следующим образом:

tc [ опции ] объект команда

Ниже описаны элементы, передаваемые программе tc.

• опции . При вызове tc могут быть заданы опции -statistics (или -s), -details (или -d) и -raw (или -r).

• объект . Данный параметр может принимать значение qdisc, class или filter. Значение qdisc определяет порядок обслуживания, или дисциплину очереди, class задает набор пакетов, принадлежащих той или иной категории либо классу (в данном примере признаком принадлежности к классу является принадлежность к одной из подсетей), a filter генерирует правило фильтрации.

• команда . Команда — это набор параметров, которые определяют, какие действия программа tc должна выполнить с объектом. Состав команды зависит от объекта.

С помощью tc вы можете сгенерировать набор правил, описывающих сети, подключенные к компьютеру, и определяющих принцип выделения пропускной способности линии для каждой из этих сетей. Предположим, что вы хотите распределить пропускную способность линии, равную 100 Мбод, поровну между двумя подсетями, обслуживающими офисы. Предположим также, что ваш компьютер подключен к Internet посредством устройства eth0, а данные в обе подсети передаются через устройство eth1; одна из подсетей имеет IP-адрес 192.168.1.0/24, а другая — 192.168.2.0/24. Процесс настройки следует начать с определения порядка обслуживания очереди для eth1.

# tc qdisc add dev eth1 root handle 10: cbq bandwidth 100Mbit \

 avpkt1000

Данную команду можно условно разделить на несколько частей.

• add dev eth1. Данный компонент команды сообщает системе о том, что вы добавляете дисциплину очереди для eth1.

• root. В некоторых случаях дисциплины могут составлять деревья. Этот параметр указывает на создание корневого узла нового дерева.

• handle 10. Этот компонент команды определяет метку (handle) для дисциплины.

• cbq. Вам необходимо сообщить системе, какой метод организации очереди должен быть использован. Метод CBQ (Class-Based-Queueing — очередь на базе классов) применяется чаще всего. Данный параметр отражается в имени одной из опций ядра в меню QoS and/or Fair Queueing.

• bandwidth 100Mbit. С помощью данного компонента вы сообщаете системе о пропускной способности линии. Если различные интерфейсы маршрутизатора подключены через линии с разной пропускной способностью, задается наименьшее значение.

• avpkt 10 0 0. По сети могут передаваться пакеты различного размера, но, для того, чтобы планировать использование линии, система должна иметь хотя бы приблизительное представление о том, какими могут быть размеры пакетов. Конкретное значение данного параметра может отличаться от указанного здесь.

Теперь надо определить классы для сети и для каждой из подсетей. Для этого используются команды наподобие следующей:

# tc class add dev eth1 parent 10:0 classid 10:1 cbq \

 bandwidth 100Mbit rate 100Mbit allot 1514 weight 10Mbit \

prio 8 maxburst 20 avpkt 1000

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

• class. Если в предыдущей команде был задан объект qdisc, то здесь присутствует объект class, определяющий класс.

• parent 10:0. Этот компонент команды задает корень дерева. К метке, определенной в предыдущей команде, добавляется значение 0.

• classid 10:1. Данный компонент задает идентификатор конкретного класса.

• allot 1514. С помощью этого параметра указывается значение MTU для сети (оно на несколько байт превышает реальное значение).

• weight 1Mbit. Данный параметр используется для настройки. Возможно, для конкретной сети необходимо специально подобрать его значение.

• prio 8. Этот компонент команды задает приоритет правила. Чем больше значение, тем выше приоритет.

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

# tc class add dev eth1 parent 10:1 classid 10:100 cbq \

 bandwidth 100Mbit rate 50Mbit allot 1514 weight 5Mbit \

 prio 5 maxburst 20 avpkt 1000 bounded

# tc class add dev eth1 parent 10:1 classid 10:200 cbq \

 bandwidth 100Mbit rate 50Mbit allot 1514 weight 5Mbit \

 prio 5 maxburst 20 avpkt 1000 bounded

Эти команды различаются только значением classid. Обе ссылаются на корневой класс, и каждая выделяет соответствующей подсети 50 Мбод пропускной способности линии. (Вы можете задать разные значения для каждой подсети, например 60 Мбод и 40 Мбод.) Параметр bounded указывает на то, что система не должна выделять классу часть пропускной способности линии, превышающую указанное значение. Часто такое ограничение бывает нежелательным, поскольку если из одной сети данные не передаются, другая сеть не сможет использовать остальную часть пропускной способности линии. Отказавшись от параметра bounded, вы обеспечите большую гибкость при работе через линии связи, в частности, предоставите офисам возможность "занимать" друг у друга пропускную способность линии. Если же обоим офисам потребуется передавать данные, этот ресурс будет распределен поровну.

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

# tc qdisc add dev eth1 parent 10:100 sfq quantum 1514b \

 perturb 15

# tc qdisc add dev eth1 parent 10:200 sfq quantum 1514b \

 perturb 15

Данные команды аналогичны рассмотренной ранее команде, определяющей порядок обслуживания очереди. Они сообщают Linux о том, что для планирования трафика внутри подсети каждого офиса должна использоваться дисциплина SFQ (Stochastic Fairness Queueing — стохастическая организация очереди, обеспечивающая равный доступ). Эта дисциплина популярна, так как для ее реализации не требуется много ресурсов процессора. Если понадобится, можете задать другую дисциплину.

Команды, которые мы уже рассмотрели, не предоставляли ядру информацию, позволяющую разделить трафик, соответствующий различным подсетям (192.168.1.0/24 и 192.168.2.0/24). Поэтому необходимо выполнить следующие команды:

# tc filter add dev eth1 parent 10:0 protocol ip prio 100 u32 \

 match ip dst 192.168.1.0/24 flowid 10:100

# tc filter add dev eth1 parent 10:0 protocol ip prio 100 u32 \

 match ip dst 192.168.2.0/24 flowid 10:200

В отличие от предыдущих, в этих командах указан объект filter. Данные команды задают правила, которые связывают трафик подсети с соответствующим классом. Обоим правилам назначены одинаковые приоритеты и задан алгоритм u32, работающий с блоками IP-адресов.

Созданные правила управляют потоком данных из Internet в локальные сети. При желании вы можете создать аналогичный набор правил, действующих в противоположном направлении. Эти правила почти совпадают с предыдущими, но вместо внутреннего интерфейса eth1 они должны ссылаться на внешний интерфейс eth0, и в двух последних командах filter вместо параметра dst должен быть указан параметр src.

 

Главная задача маршрутизатора — определить способ передачи пакетов. Предположим, например, что от маршрутизатора к целевому узлу ведут два маршрута. С помощью специальных инструментов, например программы ip, входящей в состав пакета iproute2, вы можете сообщить маршрутизатору, какой из путей следует выбрать. Маршрутизатор, настроенный подобным образом, будет применять для маршрутизации пакетов одни и те же правила до тех пор, пока вы не измените их с помощью ip. Подобное поведение маршрутизатора допустимо лишь в простых статических средах. В реальных условиях сетевое окружение постоянно изменяется: вводятся в строй новые линии связи, а существующие линии внезапно прекращают работу. Подобные изменения могут происходить далеко от вашей сети, и сведения о них не всегда будут поступать к вам. Иногда может возникнуть необходимость сообщить другим маршрутизаторам об изменениях в вашей сети, например, о появлении новой подсети с определенным IP-адресом. Для решения подобных задач предназначены протоколы маршрутизации, рассмотрению которых посвящен данный раздел.

 

Принцип действия протоколов маршрутизации

Ранее в этой главе был описан процесс настройки маршрутизатора, реализованного в системе Linux, для обработки пакетов в зависимости от адреса назначения, содержимого и других характеристик пакета. Протоколы маршрутизации предоставляют возможность учитывать состояние сетевой среды. Они позволяют получить информацию о том, достижима ли требуемая сеть и какова стоимость передачи пакета в эту сеть. Здесь понятие стоимости не связано с деньгами. Под стоимостью обычно понимают число узлов, которые должен посетить пакет, прежде чем он попадет на целевой узел. В роли стоимости также могут выступать другие характеристики сети, определяющие ее производительность. Стоимость передачи пакета по сети называется метрикой. Если маршрутизатор соединен с другими сетями посредством двух сетевых соединений, стоимость доставки пакета на целевой узел, или метрика пути к целевому узлу, зависит от того, посредством какого соединения будет передан этот пакет. Рассмотрим в качестве примера сетевую среду, условно показанную на рис. 24.1. На этом рисунке изображено пять сетей, принадлежащих пяти факультетам университета. В каждой сети работает свой маршрутизатор, который соединен с двумя другими маршрутизаторами.

Рис. 24.1. Протоколы маршрутизации позволяют маршрутизаторам обмениваться информацией и определять наиболее короткий маршрут для передачи пакета

На заметку

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

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

Для решения данной задачи используется понятие метрики. Значение метрики, определяющее стоимость передачи пакета по сети, содержится в стандартной таблице маршрутизации Linux, которая заполняется с помощью команды route. На рис. 24.2 показано содержимое простой таблицы маршрутизации (на реальных маршрутизаторах размер таблицы гораздо больше, но ее формат остается неизменным). Обратите внимание на столбец под названием Metric. В нем указано, что число маршрутизаторов, которые пакет посетит по пути следования в сети 127.0.0.0/8 (localhost) и 192.168.1.0/24 (локальная сеть), равно нулю, а оставшийся маршрут проходит через один маршрутизатор. Данный пример чрезвычайно прост. Для маршрутизаторов, показанных на рис. 24.1, в таблице маршрутизации содержалась бы информация о разных маршрутах, отличающихся значениями в поле Metric. К сожалению, стандартные средства маршрутизации системы Linux игнорируют значение метрики; для того, чтобы метрика учитывалась, необходимо использовать один из протоколов маршрутизации, рассматриваемых в данной главе.

Рис. 24.2. Значение в поле Metric определяет стоимость передачи пакета по данному маршруту

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

Протоколы маршрутизации используют следующие алгоритмы.

• Дистанционно-векторный алгоритм. Этот алгоритм отслеживает число маршрутизаторов, находящихся между текущим маршрутизатором и узлом назначения. При передаче пакета в некоторую сеть выбирается такой путь, на котором число маршрутизаторов будет минимальным. Данный алгоритм используется при работе протокола RIP (Routing Information Protocol — протокол маршрутной информации).

• Алгоритм маршрутизации по состоянию канала. Данный алгоритм связывает информацию о стоимости передачи пакета с каждым соединением. Маршрутизатор, использующий такой алгоритм, выбирает путь к целевой сети, для которого значение стоимости минимально. Стоимость не обязательно должна быть равна числу маршрутизаторов, при ее определении могут также учитываться различия в быстродействии сетевых соединений. Данный алгоритм используется при работе протокола OSPF (Open Shortest Path First — первоочередное открытие кратчайших маршрутов).

 

Использование

routed

В системе UNIX традиционно используется протокол RIP. В Linux он реализуется демоном routed, входящим в состав одноименного пакета. Маршрутизаторы, поддерживающие RIP, обмениваются адресами сетей (например, 172.22.0.0) и связанными с ними метриками (в качестве метрики принимается число маршрутизаторов между маршрутизатором, который должен отправить пакет, и целевой сетью). Значения метрики могут лежать в пределах от 0 до 15. Если на пути к целевой сети лежит больше 15 маршрутизаторов, длина маршрута считается бесконечной и информация об этом маршруте удаляется из таблицы. При работе протокола RIP используется дистанционно-векторный алгоритм, а значение метрики оценивается очень грубо. Протокол RIP в основном применяется в небольших и средних сетях; для управления передачей данных по магистралям Internet он не используется.

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

При использовании программы routed в системе Linux обычно не возникает проблем. Для ее запуска применяются средства, рассмотренные в главе 4. Работой сервера управляет конфигурационный файл /etc/gateways, в котором содержится список начальных маршрутов. Пример записи в файле /etc/gateways приведен ниже.

net 0.0.0.0 gateway 172.22.7.1 metric 1 active

В данном примере определяется маршрут по умолчанию (net 0.0.0.0), для которого задан шлюз 172.22.7.1. Метрика маршрута равна 1. Ключевое слово active указывает на то, что этот маршрут может быть обновлен. Если вы хотите, чтобы маршрут сохранялся в таблице в неизменном виде, надо заменить ключевое слово active на passive. Для работы routed можно использовать файл /etc/gateways, поставляемый в составе пакета. В процессе работы демон routed может, передавая широковещательные запросы, находить другие маршрутизаторы, использующие протокол RIP. После обнаружения маршрутизатора с ним начинается обмен информацией о маршрутах.

 

Использование GateD

Несмотря на то что протокол RIP традиционно используется в системе UNIX, область его применения ограничена. Одно из ограничений связано с тем, что пакет не может быть передан по маршруту, насчитывающему больше маршрутизаторов; это не позволяет использовать данный протокол в больших сетях. Еще одна проблема связана с медленной сходимостью алгоритма. При изменении структуры сети для достижения стабильного состояния таблицы маршрутизации может потребоваться несколько минут. И наконец, RIP не поддерживает маски подсетей, поэтому он может использоваться только для сетей, соответствующих классам А, В и С. Если, например, сеть класса С разбита на несколько подсетей, маршрутизатор, поддерживающий RIP, передает адрес подсети как адрес всей сети класса С. В результате возникают проблемы при обмене данными между различными подсетями.

В версии 2 протокола RIP (RIPv2) была добавлена поддержка маски подсети. Для хранения данных о маске использовалось поле, которое в исходном варианте RIP было зарезервировано. Протокол RIPv2 реализован в программе GateD (http://www.gated.net). Работой GateD управляет конфигурационный файл /etc/gated.conf. Для изменения конфигурации GateD используется утилита gdc, которая поставляется в составе того же пакета. Настройка GateD не требует много усилий. В процессе выполнения программа взаимодействует с другими маршрутизаторами, поддерживающими протокол RIP или RIPv2, и модифицирует содержимое таблицы маршрутизации. Подобно другим демонам, GateD запускается с помощью сценария SysV либо локального сценария запуска.

Помимо RIP и RIPv2, GateD также поддерживает протокол маршрутизации OSPF. Другие средства маршрутизации, например Zebra, также поддерживают несколько протоколов.

 

Использование Zebra

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

• RIP. Zebra поддерживает протоколы RIP и RIPv2, а также версию RIP для IPv6, которая называется RIPng. Для взаимодействия по протоколам RIP и используется сервер ripd, а поддержка RIPng реализована в программе ripngd.

• OSPF. Для работы по протоколу OSPF используется программа ospfd, а вариант OSPF для IPv6 реализован в программе ospf6d. Подобно RIP, OSPF применяется для маршрутизации пакетов в сетевых структурах, насчитывающих несколько локальных сетей.

• BGP (Border Gateway Protocol — пограничный шлюзовый протокол) широко используется в Internet. Для поддержки данного протокола предназначен сервер bgpd.

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

Каждый из демонов маршрутизации выполняется независимо от других. Например, если вам нужно обеспечить поддержку RIP или RIPv2, вы можете запустить только программы zebra и ripd. Работой каждого сервера управляет отдельный конфигурационный файл, расположенный в каталоге /etc или /etc/zebra. Имя файла совпадает с именем соответствующего демона. Например, содержимое файла /etc/zebra/ospfd.conf определяет конфигурацию сервера ospfd. Все конфигурационные файлы строятся по единому принципу. Символы ! и # являются признаками комментариев. Опции, используемые для определения конфигурации, перечислены ниже.

• hostname. В качестве значения данной опции задается имя узла, выполняющего функции маршрутизатора.

• password. Программа zebra использует пароль для управления доступом других систем и серверов. Пароль необходимо задать в каждом конфигурационном файле. Этот пароль предоставляет ограниченный доступ к серверу.

• enable password. Данная опция позволяет задать специальный административный пароль, используемый программой zebra. Этот пароль надо задать в, том случае, если вам необходимо изменить конфигурацию сервера.

• router протокол . Конфигурационные файлы серверов требуют указания протокола. Так, в файле ripd.conf указывается router rip, в файле ospfd.conf — router ospf, а в файле bgpd.conf — router bgp номер_автономной_системы . (Номера автономных систем назначаются подобно IP-адресам. Если вы хотите применить BGP только в своей локальной сети, вам надо использовать номер автономной системы в диапазоне 64512-65535.)

В процессе работы программы zebra вы можете изменить ее конфигурацию, обратившись к ней с помощью клиентской программы telnet. При обращении указывается порт 2601. Пример вызова telnet приведен ниже.

$ telnet localhost 2601

После ввода пароля надо задать одну из следующих команд: enable (получение доступа к командам настройки), configure (изменение конфигурации) или show (отображение сведений о текущей конфигурации). На каждом этапе работы вы можете получить информацию о доступных командах и опциях; для этого надо ввести символ ?. Если вы работали с маршрутизаторами Cisco, то команды Zebra знакомы вам.

 

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

 

Что такое брандмауэр

Обычно, когда говорят о брандмауэре, имеют в виду компьютер, расположенный между двумя сетями и управляющий доступом из одной сети в другую. Несмотря на то что маршрутизатор также управляет обменом пакетами между различными сетями, эти инструменты существенно отличаются друг от друга. Брандмауэр может блокировать доступ компьютеров одной сети к некоторым службам другой сети. Например, брандмауэр может запретить обращения по протоколу Telnet из Internet к компьютерам локальной сети. Маршрутизатор не выполняет подобных действий. Брандмауэр, в свою очередь, также осуществляет не все операции, выполняемые маршрутизатором. Так, например, брандмауэры, выступающие в роли proxy-серверов, частично обрабатывают запросы, направленные другим системам, преобразуют их так, что они выглядят как сформированные самим брандмауэром, и перенаправляют ответы системам, от которых были получены запросы. Брандмауэры, выполняющие функции proxy-серверов, представляют собой мощные средства защиты. Они позволяют даже защитить компьютеры от вирусов, встроенных в программы Java и JavaScript.

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

Многие рассматривают брандмауэры как инструменты, предназначенные для защиты локальных сетей от нежелательного воздействия из Internet. Действительно, брандмауэры очень часто используются в подобных целях. (Пример такого брандмауэра показан на рис. 25.2.) Однако брандмауэры часто выполняют и другие функции. Например, вы можете создать брандмауэр, который будет защищать узлы Internet от атаки, предпринимаемой с узлов локальной сети. Брандмауэр может блокировать все протоколы, за исключением некоторых, необходимых вам, и даже запретить обмен с определенными компьютерами посредством ряда протоколов. Например, вы имеете возможность разрешить обращение к порту 25 удаленных компьютеров только почтовому серверу. (Подобную конфигурацию брандмауэра используют некоторые провайдеры для борьбы со спамом.) Контроль обращений к внешним узлам не позволит недобросовестным пользователям локальной сети нанести вред удаленному компьютеру, а также даст возможность выявить вирусы и программы типа "троянский конь", которые тем или иным способом попали на компьютеры локальной сети. Несмотря на то что подобные меры в основном направлены на защиту внешних узлов, они могут оказаться полезными и для вас, так как предотвратят конфликты с администраторами внешних сетей.

Рис. 25.2. Брандмауэры, выполняющие фильтрацию пакетов, позволяют блокировать некоторые типы обращений к локальной сети

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

Как видно на рис. 25.1, для того, чтобы обеспечить фильтрацию пакетов в системе Linux, надо настроить цепочки INPUT, FORWARD и OUTPUT. Назначение каждой из этих цепочек кратко описано ниже.

• Цепочка INPUT защищает локальные процессы. Эту цепочку используют как брандмауэры, совмещенные с маршрутизаторами, так и брандмауэры, установленные на рабочих станциях и серверах.

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

• Цепочка OUTPUT блокирует передачу нежелательных выходных данных. Эту цепочку используют как брандмауэры, расположенные на отдельных компьютерах, так и брандмауэры, совмещенные с маршрутизаторами. С ее помощью можно ограничить возможности локальных клиентов по использованию протоколов или запретить им взаимодействие с некоторыми узлами.

Брандмауэры, совмещенные с маршрутизаторами, чаще всего применяют правила, содержащиеся в цепочках INPUT и FORWARD, а брандмауэры на рабочих станциях и серверах в основном работают с правилами в цепочках INPUT и OUTPUT. В некоторых случаях результаты использования правил в различных цепочках совпадают, в особенности это справедливо для цепочек FORWARD и OUTPUT. Различие лишь в том, что цепочка OUTPUT воздействует как на перенаправляемый трафик, так и на трафик, сгенерированный локальным компьютером, в то время как цепочка FORWARD контролирует только перенаправляемый трафик.

 

Формирование политики по умолчанию

Первым шагом, предпринимаемым при настройке брандмауэра, является формирование политики по умолчанию. Политика по умолчанию — это выражение, определяющее, что должен делать брандмауэр, если пакет не удовлетворяет ни одному из правил. Для создания политики по умолчанию используется опция -P утилиты iptables.

# iptables -P INPUT DROP

# iptables -P OUTPUT DROP

# iptables -P FORWARD DROP

В данном примере задается политика по умолчанию для трех стандартных цепочек, содержащихся в таблице filter. В качестве политики по умолчанию может быть указано любое из описанных ранее действий (ACCEPT, DROP, QUEUE, RETURN и т.д.). Наиболее часто используются действия ACCEPT, DROP и REJECT. ACCEPT указывает Linux на то, что все пакеты должны передаваться, a DROP заставляет систему игнорировать все пакеты. REJECT, подобно DROP, также указывает на то, что пакеты должны отвергаться, но при этом Linux оповещает источник о том, что пакет не принят (подобное сообщение источник получает и в том случае, если в системе нет ни одного сервера, ожидающего обращения через порт, указанный в заголовке пакета). Если брандмауэр должен обеспечивать высокую степень защиты, в качестве политики по умолчанию указывается DROP или REJECT, однако при этом все пакеты, передача которых не разрешена явным образом, будут отвергнуты. Если задана политика по умолчанию ACCEPT, то необходимо явно запретить все типы пакетов, которые не должны быть пропущены через брандмауэр. Составление правил, блокирующих все недопустимые типы пакетов, часто представляет собой достаточно сложную задачу, причем всегда остается опасность, что какое-либо условие останется не учтенным. С другой стороны, задавая политику по умолчанию DROP или REJECT, надо лишь разрешить прохождение некоторых типов пакетов через брандмауэр. Обычно при работе системы число типов пакетов ограничено, поэтому данному подходу следуют большинство системных администраторов.

 

Определение правил

Для создания правил используется опция --append (или -А) программы iptables. После этой опции задается один или несколько критериев, затем указывается опция --jump (или -j), за которой следует действие ACCEPT, DROP или REJECT. Вызов iptables, предназначенный для создания действия, выглядит следующим образом:

# iptables --append CHAIN критерий_выбора --jump действие

Сокращенно та же команда может быть записана так:

# iptables -A CHAIN критерий_выбора -j действие

Вместо --append при вызове iptables могут быть указаны следующие опции.

• --delete, или -D. Эта опция удаляет правило из существующей цепочки.

• --insert, или -I. С помощью данной опции вы можете включить правило в середину цепочки. При этом необходимо задать номер правила. Если номер не указан, iptables включит правило в начало цепочки (при использовании опции --append правило помещается в конец цепочки).

• --replace, или -R. Эта опция дает возможность заменить правило. Задавая данную опцию, следует указать номер заменяемого правила.

• --list, или -L. Данная опция отображает все правила в цепочке.

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

На заметку

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

Использование номеров портов при выполнении фильтрации

При выполнении фильтрации пакетов могут анализироваться порты источника и назначения. Например, брандмауэр, находящийся на компьютере, на котором выполняется почтовый сервер, можно настроить для передачи пакетов, в которых указан порт назначения 25. Для этого используется опция --destination-port (--dport). Аналогичных результатов можно добиться, используя опцию --protocol (-p), в качестве значения которой указывается тип протокола (tcp, udp, icmp или all). Опция --source-port (--sport) выполняет подобные действия, но задает порт источника. Команды, определяющие правила фильтрации на основе номеров портов, выглядят следующим образом:

# iptables -A INPUT -р tcp --dport 25 -j ACCEPT

# iptables -A OUTPUT -p tcp --sport 25 -j ACCEPT

Эти команды обеспечивают прием пакетов, направленных серверу, который ожидает поступление запросов через порт 25, и передачу пакетов, возвращаемых сервером в ответ на запрос (в них указан порт источника 25). В результате, даже если политика по умолчанию отвергает пакеты, сервер сможет получить почту от внешних серверов. Заметьте, если в качестве политики по умолчанию указано действие DROP или REJECT вы должны включить в цепочку INPUT правило, разрешающее принимать пакеты, направленные серверу, а в цепочку OUTPUT — правило, разрешающее передавать пакеты, сгенерированные данным сервером. Для этого при определении правила для цепочки INPUT задается опция --destination-port, а при определении правила для цепочки OUTPUT — опция --source-port. Если вы забудете создать одно из правил, то сервер сможет получать запросы, но не сможет генерировать ответы на них, либо, наоборот, через брандмауэр будут пропускаться только данные, сгенерированные сервером, а информация, направленная серверу, будет отвергаться. Для брандмауэра, совмещенного с маршрутизатором, надо также включить в цепочку FORWARD правила, созданные с использованием опций --destination-port и --source-port, в противном случае данные через брандмауэр передаваться не будут. Вы можете использовать в качестве условий номера портов в сочетании с IP-адресами. Это позволит не только ограничить обмен определенным типом протокола, но и разрешить его лишь для отдельных компьютеров. Так, например, вы сможете создать правила, согласно которым взаимодействовать с внешними узлами по протоколу SMTP будет иметь право только почтовый сервер.

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

• Разрешите доступ к серверным портам внешних компьютеров. Соответствующее правило, включаемое в цепочку INPUT, должно создаваться с указанием опции --source-port, а при создании правила, помещаемого в цепочку OUTPUT, должна использоваться опция --destination-port. Для брандмауэра, совмещенного с маршрутизатором, необходимо также включить в цепочку FORWARD правила, созданные с помощью опций --source-port и --destination-port. Возможно, что наряду с номерами портов вам потребуется задать IP-адреса ваших компьютеров. Таким способом вам следует разрешить обращение вовне по каждому из протоколов, которые используются клиентами, выполняемыми в вашей сети.

• Разрешите доступ к непривилегированным портам компьютеров вашей сети. Номера непривилегированных портов лежат в диапазоне 1024-65535. В опциях --source-port и --destination-port указываются границы диапазона, разделенные двоеточием, например --source-port 1024:65535. Для принимаемых пакетов вы можете указать также опцию ! syn. Правилам, в которых указана опция --syn, соответствуют только пакеты, содержащие запросы на установление соединений, а символ ! означает отрицание, т.е. заданному правилу будут удовлетворять только пакеты, которые были переданы серверами в ответ на запросы клиентов.

Использование IP-адресов при выполнении фильтрации

При создании правил могут указываться IP-адреса или блоки IP-адресов. IP-адрес источника задается с помощью опции --source (-s), а IP-адрес назначения — посредством опции --destination (-d). Например, если вы хотите запретить взаимодействие с компьютерами сети 172.24.0.0/16, вам надо создать правила, которые отвергали бы пакеты, переданные из указанной сети, а также пакеты, адресованные компьютерам этой сети. Соответствующие команды имеют следующий вид:

# iptables -A INPUT -s 172.24.0.0/16 -j DROP

# iptables -A OUTPUT -d 172.24.0.0/16 -j DROP

Опции -s и -d часто используются вместе с опциями, определяющими номера портов. Таким образом, вы можете сформировать правила, согласно которым взаимодействовать по сети будут иметь право только определенные компьютеры, обращающиеся по определенным портам. Предположим, например, что вы создаете брандмауэр для защиты локальной сети, но хотите при этом разрешить удаленным пользователям, работающим в сети 10.34.176.0/24, обращаться к серверам SSH локальной сети (серверы SSH ожидают обращения через порт 22). Для этого надо определить следующие команды:

# iptables -A FORWARD -s 10.34.176.0/24 -p tcp \

 --destination-port 22 -j ALLOW

# iptables -A FORWARD -d 10.34.176.0/24 -p tcp \

 --source-port 22 -j ALLOW

Поскольку в данном примере модифицируется только цепочка FORWARD, пользователям не предоставляется доступ к серверу SSH компьютера, на котором выполняется брандмауэр (если такой сервер имеется на этой машине). Возможно, вы захотите создать правила, которые разрешали бы обращаться к этому серверу с компьютеров локальной сети. Если адрес вашей локальной сети 192.168.9.0/24, то соответствующие команды будут выглядеть так:

# iptables -A INPUT -s 192.168.9.0/24 -р tcp \

 --destination-port 22 -j ALLOW

# iptables -A OUTPUT -d 192.168.9.0/24 -p tcp \

 --source-port 22 -j ALLOW

Использование информации об интерфейсах при выполнении фильтрации

При создании правил фильтрации можно указывать сетевой интерфейс, например ppp0 или eth1. Данный подход в основном используется на компьютерах с несколькими интерфейсами, выполняющих функции маршрутизаторов. Применение в составе правила сведений об интерфейсе позволяет противодействовать фальсификации адресов, в частности, включению в заголовки пакетов, приходящих извне, адресов компьютеров локальной сети. Правила, в которых интерфейс задается с помощью опции --in-interfасе (-i), как правило, помещаются в цепочки INPUT и FORWARD, а правила, создаваемые с использованием опции --out-interface (-о), обычно предназначены для включения в цепочки FORWARD и OUTPUT. Предположим, что адрес вашей локальной сети 192.168.9.0/24, маршрутизатор, совмещенный с брандмауэром, подключен к ней с помощью интерфейса eth1, а соединение маршрутизатора с Internet осуществляется посредством интерфейса eth0. Правила, препятствующие фальсификации адресов, имеют следующий вид:

# iptables -A INPUT -s 192.168.9.0/24 -i eth0 -j DROP

# iptables -A FORWARD -s 192.168.9.0/24 -i eth0 -j DROP

# iptables -A FORWARD -s !192.168.9.0/24 -i eth1 -j DROP

# iptables -A OUTPUT -s !192.168.9.0/24 -i eth1 -j DROP

Первые две команды отвергают поступающие извне (через интерфейс eth0) пакеты, адресованные маршрутизатору или компьютерам локальной сети, в которых указано, что они отправлены из локальной сети. Последние две команды блокируют пакеты, направленные в Internet (поступающие через интерфейс eth1), в которых указан IP-адрес источника, не совпадающий с адресами компьютеров локальной сети.

Проверка пакетов с учетом состояния

Одна из самых новых возможностей фильтрации пакетов, реализованных в системе Linux, позволяет учитывать при проверке пакетов состояние соединения. Средства, рассмотренные ранее в этой главе, позволяли обрабатывать отдельные пакеты, независимо от того, являлись ли они частью соединения или были специально сгенерированы для организации атаки. (Ранее уже встречалась опция --syn, позволяющая определить пакет, содержащий запрос на установление соединения. Существуют средства, которые предоставляют возможность включить свои пакеты в набор пакетов, передаваемых в рамках действующего соединения. Такое включение пакетов называется перехватом TCP- соединения.) Средства проверки пакетов с учетом состояния определяют принадлежность пакетов к текущему соединению, анализируя последовательные номера, IP-адреса, указанные в заголовках, и другие характеристики пакетов. Правила, реализующие такую проверку, позволяют отвергать посторонние пакеты, включенные в состав данных, которые передаются в рамках существующего соединения.

Для включения средств проверки пакетов с учетом состояния используется опция --state, предваряемая опцией -m состояние . Для опции --state можно задать одно или несколько значений. Если вы указываете несколько значений, они должны разделяться запятыми. Символ ! перед опцией --state изменяет ее действие на обратное. Ниже перечислены допустимые параметры опции --state.

• INVALID. Проверка показала, что пакет не принадлежит известному соединению и может оказаться фальсифицированным.

• NEW. Пакет пытается установить новое соединение.

• ESTABLISHED. Пакет соответствует существующему соединению.

• RELATED. Пакет не является частью существующего соединения, но его присутствие допустимо (например, это может быть ICMP-пакет, сообщающий об ошибке).

На заметку

Опция ! --state INVALID эквивалентна опции --state NEW, ESTABLISHED, RELATED .

Рассмотрим пример проверки с учетом состояния. Предположим, что, настраивая брандмауэр на отдельном компьютере, вы задали политику по умолчанию DROP или REJECT, но хотите разрешить взаимодействие с сервером HTTP через порт 80. Вы можете задать поверку с учетом состояния, в ходе которой будут отвергаться пакеты, не предназначенные для установления соединений, не принадлежащие к существующим соединениям и не относящиеся к пакетам, присутствие которых допустимо. Команды, предназначенные для создания правил, имеют следующий вид:

# iptables -A INPUT -m state -p tcp --dport 80 \

 --state NEW,ESTABLISHED,RELATED -j ACCEPT

# iptables -A OUTPUT -m state -p tcp --sport 80 \

 --state ESTABLISHED,RELATED -j ACCEPT

Эти правила включают проверку входящих и исходящих пакетов. Для проверки пакетов, передаваемых с компьютера, значение NEW опции --state не задано, так как новое соединение может устанавливаться только по инициативе клиента. Эти правила препятствуют перехвату существующих соединений с Web-сервером.

На заметку

Проверка пакетов с учетом состояния может осуществляться только в тех системах, в которых используется версия ядра 2.4.x. Предыдущими версиями ядра такая возможность не поддерживается. Это может стать одним из стимулов перехода к использованию iptables .

Использование дополнительных опций

Программа iptables поддерживает большое количество опций, которые могут быть использованы для создания брандмауэров. Например, посредством опции --new-chain (-N) можно создать новую цепочку, указав опцию --fragment (-f), можно создать правило, которое будет применяться ко второму и к последующим фрагментам фрагментированного пакета, а опция --tcp-flags дает возможность организовать проверку на присутствие флагов в составе TCP-пакета. Дополнительную информацию об этих и о других опциях вы можете получить на страницах справочной системы Linux, посвященных iptables.

Сценарий для создания брандмауэра

В завершение разговора о средствах фильтрации пакетов рассмотрим сценарий, который создает брандмауэр. Код сценария представлен в листинге 25.1. Данный сценарий предназначен для компьютера, на котором выполняется Web-сервер и который поддерживает SSH-соединения с компьютерами, подключенными к локальной сети.

Внимание

Сценарии брандмауэров, предназначенные для практического применения, содержат гораздо больший объем кода по сравнению представленным в листинге 25.1. Для удобства чтения в данном листинге при вызове iptables не указывается путь к файлу. В реальных сценариях это недопустимо. Не указывая путь к файлу, вы создаете угрозу безопасности системы. Код, приведенный в листинге 25.1, может послужить основой для создания более сложных сценариев.

Листинг 25.1. Простой сценарий, использующий iptables для создания брандмауэра

#!/bin/sh

iptables -F INPUT

iptables -F OUTPUT

iptables -F FORWARD

iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

# Разрешить NDS-трафик

iptables -A INPUT -p udp --sport 53 -j ACCEPT

iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

# Разрешить обмен клиентов с локальной сетью

iptables -A INPUT -m state -p tcp --dport 1024:65535 \

 --state ESTABLISHED,RELATED -s 192.168.9.0/24 -j ACCEPT

iptables -A OUTPUT -m state -p tcp --sport 1024:65535 \

 ! --state INVALID -d 192.168.9.0/24 -j ACCEPT

# Разрешить все HTTP-соединения

iptables -A INPUT -m state -p tcp --dport 80 \

 ! --state INVALID -j ACCEPT

iptables -A OUTPUT -m state -p tcp --sport 80 \

 --state ESTABLISHED, RELATED -j ACCEPT

# Разрешить обращения к SSH-серверу

# из локальной сети (192.168.9.0/24)

iptables -A INPUT -m state -p tcp --dport 22 \

 ! --state INVALID 192.168.9.0/24 -j ACCEPT

iptables -A OUTPUT -m state -p tcp --sport 22 \

 --state ESTABLISHED,RELATED -d 192.168.9.0/24 -j ACCEPT

# Разрешить прохождение локального трафика через интерфейс lo

iptables -A INPUT -s 127.0.0.1 -i lo -j ACCEPT

iptables -A OUTPUT -d 127.0.0.1 -o lo -j ACCEPT

Ниже описаны некоторые особенности кода, приведенного в листинге 25.1.

• Удаление существующих правил и установка политики по умолчанию. В первых шести строках программа iptables вызывается для удаления правил, присутствующих в цепочках, и установки политики по умолчанию. В качестве политики по умолчанию задается действие DROP. Несмотря на то что компьютер не выполняет маршрутизацию пакетов, политика по умолчанию задается также и для цепочки FORWARD. Это делается на случай, если на компьютере будет установлен еще один сетевой интерфейс.

• Взаимодействие с сервером DNS. Для того чтобы компьютер мог взаимодействовать с сервером DNS, две строки, следующие за комментариями "Разрешить NDS-трафик", предоставляют компьютеру возможность обращаться к удаленным серверам DNS (UDP-порт 53). Возможности соединения не ограничиваются одним адресом; компьютеру разрешено взаимодействовать с любым сервером имен. Если понадобится, вы можете наложить более жесткие ограничения.

• Обмен с клиентами локальной сети. Строки, следующие за комментариями "Разрешить обмен клиентов с локальной сетью", открывают путь трафику, связанному с непривилегированными портами (1024-65535). В цепочки INPUT и OUTPUT включены правила проверки пакетов с учетом состояния. Заметьте, что правило в цепочке INPUT запрещает установление новых соединений, поэтому, даже если на компьютере будет находиться сервер, принимающий обращения через непривилегированные порты, другие компьютеры не смогут обратиться к нему. Цепочки INPUT и OUTPUT ограничивают взаимодействие компьютерами локальной сети. При создании реального брандмауэра следует рассмотреть возможность замены этих правил более конкретными, которые разрешали бы прохождение данных между непривилегированными локальными портами и портами, используемыми для поддержки отдельных протоколов.

• Трафик, связанный с Web-сервером. Web-сервер, выполняющийся на компьютере, должен принимать обращения от любого узла сети, поэтому в правилах, регламентирующих обмен с Web-сервером, не указывается IP-адрес. Для того чтобы противодействовать перехвату соединения, в этих правилах задана проверка пакетов с учетом состояния.

• Трафик, связанный с сервером SSH. Правила, определяющие взаимодействие с сервером SSH, во многом напоминают правила для Web-сервера, но в них указаны IP-адреса. В результате эти правила разрешают обращение к SSH-серверу только с компьютеров локальной сети.

• Трафик обратной петли. Для решения ряда системных задач, связанных с организацией работы системы, Linux использует интерфейс обратной петли (lo). Правила брандмауэра разрешают передачу данных через этот интерфейс. Проверка пакетов с учетом состояния не выполняется, так как трафик, направленный через интерфейс lo, поступает только по адресу 127.0.0.1.

 

Брандмауэры являются чрезвычайно полезными инструментами, но возможности iptables не ограничиваются созданием брандмауэров. В некоторых ситуациях большую помощь могут оказать NAT-преобразователи, которые также создаются посредством iptables. Протокол NAT позволяет модифицировать некоторые элементы TCP- и IP-пакетов, расширяя тем самым возможности адресации. Средства NAT настраиваются достаточно просто, но прежде чем приступить к настройке, следует выяснить, что такое NAT и какие возможности предоставляет этот инструмент.

 

Что такое NAT

Средства NAT позволяют изменять в процессе маршрутизации содержимое TCP- и IP-пакетов. В частности, при NAT-преобразовании изменяется IP-адрес источника и назначения в составе пакета. Ниже описаны ситуации, в которых оправданы подобные изменения адреса.

• Установление соответствия между внешними и внутренними адресами. Возможно, что, получив в свое распоряжение блок IP-адресов, вы не захотите перенастраивать сеть и будете использовать адреса, предназначенные для внутреннего пользования. Используя средства NAT, вы можете установить взаимно-однозначное соответствие между обычными Internet-адресами, выделенными для вашей сети, и адресами, которые реально присвоены вашим компьютерам.

• Временное изменение адресов. Средства NAT можно использовать для перенаправления запросов, адресованных некоторой системе, на другой компьютер. Предположим, например, что ваш Web-сервер вышел из строя и вы временно разместили его на другом компьютере. Проблему перенаправления запросов можно решить, изменяя конфигурацию сервера DNS, но средства NAT позволяют сделать это гораздо быстрее.

• Распределение нагрузки. С помощью NAT можно поставить в соответствие одному IP-адресу два компьютера внутренней сети и переключаться между ними при передаче запросов. Такая форма распределения нагрузки считается очень грубой, но если один сервер не справляется со своей задачей, можно использовать подобное решение. Следует, однако помнить, что существуют более совершенные способы распределения нагрузки, не связанные с использованием NAT.

• Расширение адресного пространства. Если в вашем распоряжении имеется лишь ограниченное число IP-адресов, вы можете "спрятать" несколько компьютеров за одним IP-адресом. Такая возможность обычно используется в небольших сетях, подключенных к Internet по коммутируемой линии либо через соединение с широкой полосой пропускания. Если провайдер выделил для сети лишь один адрес, с помощью NAT-преобразования можно обеспечить работу всех компьютеров сети.

Расширение адресного пространства является наиболее частым применением NAT. Данная разновидность NAT-преобразования называется IP-маскировкой. В этом разделе будет рассматриваться именно этот способ использования NAT.

Средства NAT применяются совместно со средствами маршрутизации. В роли маршрутизатора, поддерживающего NAT, может выступать компьютер под управлением Linux. Настройка ядра системы производится с помощью программы iptables. Обычно компьютер, предназначенный для выполнения NAT-преобразования, содержит два сетевых интерфейса: посредством одного из них компьютер подключается к Internet, а с помощью другого соединяется с внутренней сетью.

На заметку

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

Для того чтобы лучше понять работу NAT, рассмотрим процесс преобразования адреса с помощью NAT-маршрутизатора. Взаимодействие с сервером, расположенным в Internet, начинается по инициативе клиента (например, Web-броузера), который находится в сети, защищенной с помощью NAT-маршрутизатора. Предположим, что этот клиент пытается обратиться к Web-броузеру по адресу 172.18.127.45. Он генерирует HTTP-запрос; в пакетах, содержащих этот запрос, указывается локальный IP-адрес клиента (предположим, 192.168.9.32). Клиент передает запрос компьютеру, выполняющему роль локального шлюза; этот компьютер осуществляет NAT-преобразование. Получив пакет с запросом к Web- серверу, NAT-маршрутизатор анализирует его содержимое, заменяет IP-адрес источника на свой IP-адрес (допустим, что его адрес 10.34.176.7) и передает пакет по назначению. Web-сервер считает, что пакет поступил с компьютера, выполняющего функции NAT-маршрутизатора, поэтому направляет ему ответ. Получив ответ сервера, NAT-маршрутизатор распознает его как ответ на запрос, переданный с компьютера 192.168.9.32, выполняет обратное преобразование, заменяя адрес назначения в пакете, а затем передает пакет, содержащий ответ, клиенту. Рис. 25.3 иллюстрирует этот процесс. При этом ни клиент, ни сервер не знают о том, что адрес был преобразован средствами NAT, поэтому при использовании NAT-маршрутизатора не требуется изменять конфигурацию компьютеров в сети.

Рис. 25.3. NAT-маршрутизатор изменяет IP-адреса в пакетах

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

Помимо преимуществ, NAT имеет существенные недостатки.

• Автоматически создаваемая защита затрудняет размещение сервера во внутренней сети, расположенной за NAT-маршрутизатором, и обеспечение внешнего доступа к этому серверу. Чтобы доступ к серверу извне стал возможен, надо использовать перенаправление портов.

• Не все протоколы нормально взаимодействуют с NAT. Иногда IP-адреса используются для обработки содержимого пакетов, в других случаях на обоих концах соединения могут работать серверы. Средства, реализующие NAT в системе Linux, обеспечивают поддержку некоторых протоколов, но если вы используете видеоконференции или средства шифрования, то при обмене с Internet через NAT-маршрутизатор могут возникнуть проблемы.

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

 

Опции

iptables

для осуществления NAT-преобразования

Средства поддержки NAT в системе Linux содержатся в таблице nat, которая уже упоминалась выше. Подобно таблице filter, nat содержит три цепочки: PREROUTING, POSTROUTING и OUTPUT. Несмотря на совпадение имен, цепочка OUTPUT в таблице nat отличается от одноименной цепочки в таблице filter. Для активизации средств NAT надо вызвать две следующие команды:

# iptables -t nat -A POSTROUTING -о внешний_интерфейс -j \

 MASQUERADE

# echo "1" > /proc/sys/net/ipv4/ip_forward

На заметку

Для загрузки NAT-модуля ядра перед вызовом iptables может потребоваться выполнение команды modprobe iptable_nat .

В качестве внешнего интерфейса в первой из двух приведенных команд указывается интерфейс, посредством которого осуществляется соединение с Internet, например ррр0 или eth1. Эта команда указывает Linux на то, что для всего сетевого трафика, проходящего через маршрутизатор, надо выполнить IP-маскировку. Вторая команда разрешает ядру Linux осуществить маршрутизацию (эта команда используется также в маршрутизаторах, не поддерживающих NAT).

При настройке NAT-маршрутизатора обычно включают средства фильтрации пакетов. Несмотря на то что NAT-маршрутизатор надежно защищает компьютеры локальной сети от атаки извне, вам надо защитить сам маршрутизатор, а также ограничить возможности компьютеров локальной сети по установлению соединений с Internet. Даже если компьютер, защищенный NAT-маршрутизатором, используете только вы, не исключено появление на нем вирусов и программ типа "троянский конь", которые могут инициировать нежелательные обращения к внешним узлам. Возможно, вы захотите включить проверку пакетов с учетом состояния, чтобы пресечь попытки перехвата соединений, предпринимаемые из вашей локальной сети. NAT-команды задаются посредством того же сценария, который используется для установки правил брандмауэра.

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

 

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

 

Задачи, решаемые с помощью перенаправления портов

Перенаправление портов может потребоваться в следующих ситуациях.

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

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

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

Необходимость в перенаправлении запросов компьютерам локальной сети часто возникает при использовании NAT-маршрутизатора. При этом уровень защиты несколько снижается, так как вы предоставляете внешним узлам доступ к одному из компьютеров (точнее, к одному из портов да нем). Подобное решение допускает выполнение лишь одного внутреннего сервера, ожидающего обращения через определенный порт. Если вы хотите запустить во внутренней сети два сервера одного типа, доступных извне (например, два Web-сервера), то один из них должен использовать нестандартный порт либо эти серверы должны быть представлены на внешних компьютерах с разными IP-адресами.

 

Опции

iptables

для перенаправления портов

Обеспечить перенаправление портов на компьютере под управлением Linux, поддерживающем NAT, можно различными способами. Один из них состоит в использовании iptables. Соответствующая команда имеет следующий вид:

# iptables -t nat -A PREROUTING -p tcp -i external-interface \

 --destination-port port-num -j DNAT --to dest-addr:port-num

Ниже описаны компоненты данной команды.

• Опция, определяющая таблицу NAT (-t nat).

• Опция -A PREROUTING, указывающая на то, что изменения должны вноситься в состав пакета перед выполнением маршрутизации. Базовые средства NAT применяются после маршрутизации, но перенаправление портов предшествует маршрутизации.

• Опция, которая задает перенаправление TCP-портов (-p tcp).

• Правило, применяемое к пакетам, направленным через внешний интерфейс (-i внешний_интерфейс ) по конкретному порту (-destination-port номер_порта ).

• Опция -j DNAT, указывающая на то, что вместо NAT источника (SNAT) выполняется NAT назначения (DNAT).

• Опция --to адрес_назначения : номер_порта , сообщающая, что пакет должен быть направлен на указанный адрес с использованием указанного номера порта. В качестве адреса назначения можно указать, например, адрес 192.168.9.33, а номер порта может быть равен 80. Заметьте, что номер порта, задаваемый посредством опции --to, не обязательно должен совпадать с номером порта, представляющим значение опции --destination-port.

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

На заметку

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

 

Поскольку PPTP не разрабатывался специально для Linux, чтобы инсталлировать соответствующие средства на компьютере под управлением Linux, необходимо приложить определенные усилия. Сервер PoPToP взаимодействует с PPP-демоном pppd. Для обеспечения безопасности система должна уметь шифровать данные, но соответствующие средства в программе pppd отсутствуют. Поэтому демон pppd необходимо заменить его расширенной версией. PPTP-клиенты созданы как для Linux, так и для Windows; очевидно, что они настраиваются по-разному.

 

Инсталляция PoPToP

Инструмент PoPToP поставляется в составе некоторых версий Linux, например Debian и Mandrake. Соответствующий пакет чаще всего имеет имя pptpd или pptpd-server. Пакет, поставляемый с системой Linux, обычно проще настраивать, чем универсальный пакет, распространяемый по Internet. Если в вашем дистрибутивном пакете Linux нет инструмента PoPToP, вы можете скопировать его с Web-узла PoPToP, расположенного по адресу http://poptop.lineo.com.

По умолчанию средства PoPToP в системе Linux не обеспечивают должного уровня защиты при организации VPN. Причина в том, что PPTP применяет специальные средства кодирования PPP, которые не поддерживаются стандартной программой pppd. В частности, работа PPTP базируется на использовании протокола MPPE (Microsoft Point-to-Point Encryption — межузловое кодирование Microsoft). Для поддержки кодирования вам надо инсталлировать MPPE-дополнения для стандартной программы pppd и для ядра Linux. Этот процесс будет описан далее в данной главе.

 

Установка конфигурации сервера PoPToP

После инсталляции пакета PoPToP вам надо активизировать его. Для этого выполните следующие действия.

1. Отредактируйте файл /etc/ppp/options. Этот файл управляет работой программы pppd, которая поддерживает соединение между VPN-маршрутизатором и удаленной системой PPTP. Файл /etc/ppp/options должен содержать записи наподобие приведенных ниже.

debug

 name имя_сервера auth

 require-chap

 proxyarp

 192.168.1.1:192.168.1.100

Большинство из этих записей необходимо для работы PPTP. Последняя строка может отсутствовать; она задает адрес, используемый VPN-маршрутизатором в локальной сети (192.168.1.1), и адрес, присваиваемый VPN-клиенту (192.168.1.100). Если вы не зададите эту строку, будет использоваться IP-адрес, указанный в конфигурации VPN-клиента. В данном случае имя сервера — это доменное имя VPN- сервера.

2. Укажите в файле /etc/ppp/chap-secrets имя пользователя и пароль, которые вы хотите использовать для регистрации. В приведенном ниже примере задано имя пользователя vpn1 и пароль vpnpass.

vpn1 * vpnpass *

Внимание

Пароль хранится в файле /etc/ppp/chap-secrets в незакодированном виде, поэтому вам необходимо принять меры для защиты этого файла. Владельцем его должен быть пользователь root и право чтения файла должен иметь только его владелец. Если злоумышленник получит контроль над сервером PoPToP, он сможет прочитать этот файл. По этой причине на компьютере, выполняющем функции VPN-маршрутизатора, должно присутствовать как можно меньше серверов.

3. Найдите в файле /etc/inittab ссылку на pptpd и закомментируйте соответствующую запись, включив в начало строки символ #. Затем введите команду telinit Q, чтобы внесенные изменения были учтены. В результате вы получите возможность вручную запустить pptpd и протестировать конфигурацию данной программы. После создания конфигурации, пригодной для работы, удалите символ комментариев из соответствующей строки файла /etc/inittab или запустите сервер другим способом.

4. От имени пользователя root введите команду pptpd, запустив тем самым сервер.

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

Внимание

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

Работой PPTP управляют также опции, содержащиеся в файле options.pptp, который обычно располагается в каталоге /etc или /etc/ppp. Некоторые из этих опций описаны ниже.

• debug. Данная опция сообщает PoPToP о том, что в файл протокола должны быть записаны дополнительные данные. Они могут понадобиться в том случае, если при установлении соединения возникают проблемы.

• localip. Клиент PPTP использует два IP-адреса: один — для локальной сети, второй — для удаленного клиента. Локальные IP-адреса можно задать с помощью опции localip. В качестве значения опции задается список адресов, разделенных запятыми, или диапазон адресов. Например, опция localip 192.168.9.7, 192.168.9.100-150 задает адрес 192.168.9.7 и все адреса в диапазоне от 192.168.9.100 до 192.168.9.150. Убедитесь, что другие компьютеры в вашей локальной сети не используют эти адреса.

• remoteip. Данная опция задает IP-адреса, используемые удаленными клиентами. Эти адреса обычно принадлежат диапазону адресов, используемых во внутренних сетях. IP-адреса задаются в таком же формате, как и для опции localip.

• listen. Указав в качестве значения данной опции IP-адрес, связанный с одним интерфейсом, можно сообщить программе pptpd о том, что она должна принимать обращения только через этот интерфейс. По умолчанию PoPToP принимает обращения через все интерфейсы.

 

Обеспечение кодирования данных

PoPToP использует программу pppd, которая, в свою очередь, использует средства ядра. В частности, PoPToP требует, чтобы демон pppd поддерживал кодирование, a pppd требует, чтобы средства поддержки кодирования присутствовали в ядре Linux. Поэтому для шифрования данных при работе PoPToP необходимо дополнить как pppd, так и ядро системы.

Проще всего решить эту задачу, используя дополненные варианты pppd и ядра Linux. Соответствующие программы можно получить, обратившись по адресу http://mirror.binarix.com/ppp-mppe/. Вам необходимо скопировать следующие два файла.

• Ядро Linux. Дополненное ядро Linux содержится в файле, имя которого начинается с kernel, например kernel-2.4.9-13mppe.i386.rpm. Некоторые из этих пакетов содержат двоичный код ядра, скомпилированный для конкретного типа системы, а другие — исходный код ядра. Если вы скопируете исходный код, вам надо будет сконфигурировать и скомпилировать его для вашей системы.

• Пакет ppp. Измененный пакет pppd находится в файле ppp-2.4.1-3mdk.i586.rpm или в другом файле с подобным именем. Содержимое пакета надо установить вместо файла pppd.

На узле http://mirror.binarix.com/ppp-mppe/ находятся двоичные программы, скомпилированные для Mandrake, поэтому если вы работаете с этой версией Linux, можете воспользоваться кодами, представленными на данном узле. Не исключено, что вы найдете программы, сконфигурированные для другой системы.

Совет

Если в вашей системе не используется RPM, вы можете преобразовать форматы пакетов с помощью утилиты alien . Эта программа входит в состав Debian и поддерживает RPM, пакеты Debian и tar-архивы.

Дополненные программы вы также можете получить, обратившись на узел http://pptpclient.sourceforge.net. Здесь можно найти клиентские программы, пакеты ppp-mppe, представляющие собой программы pppd с поддержкой MPPE, а также модули ядра с поддержкой MPPE.

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

• Ядро Linux. Исходный код стандартного ядра Linux можно получить, обратившись на узел http://www.kernel.org. Использовать стандартное ядро Linux предпочтительнее, чем ядро из дистрибутивного пакета, так как последнее обычно бывает модифицировано, в результате чего внесение изменений может быть затруднено.

• Исходный код pppd. Исходный код демона PPP можно получить по адресу ftp://cs.anu.edu.au/pub/software/ррр/.

• OpenSSL. MPPE-дополнения требуют, чтобы в вашей системе были установлены OpenSSL и файлы заголовков OpenSSL. Требуемые данные можно скопировать с узла http://www.openssl.org.

• Дополнения к ядру Linux. На узле http://mirror.binarix.com/ррр-mppe/ надо найти файлы, начинающиеся с linux и заканчивающиеся patch.gz, например linux-2.4.16-openssl-0.9.6-bmppe.patch.gz.

• Дополнения к pppd. Дополнения к программе pppd также доступны по адресу http://mirror.binarix.com/ppp-mppe/. Имя соответствующих файлов начинается с ррр и заканчивается patch.gz, например ррр-2.4.1-openssl-0.9.6-mppepatch.gz.

Для того чтобы исключить несоответствие версий, надо начать с файлов дополнений, а затем подобрать соответствующие версии ядра и пакета pppd. Чтобы дополнить и использовать полученные средства, надо распаковать архивы с исходными кодами ядра и pppd, распаковать файлы дополнений (выполнив команду gunzip filename .patch.gz ), дополнить исходные коды (cd каталог_с_исходными_кодами ; patch -p1 < patchfile.patch ), сконфигурировать пакеты (make menuconfig или make xconfig — для ядра Linux и ./configure — для pppd), скомпилировать пакеты (make bzImage и make modules — для ядра Linux и make — для pppd) и инсталлировать пакеты (выполнив команду make modules_install и сконфигурировав LILO для Linux, а также выполнив команду make install для pppd).

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

 

Настройка PPTP-клиента

Если PPTP-клиент предназначен для выполнения в системе Windows, настроить его для работы с PoPToP несложно, так как в системе Windows предусмотрена поддержка PPTP. Для обеспечения работы PPTP-клиента в системе Linux требуется дополнительное программное обеспечение. В любом случае после установления VPN-соединения VPN-клиент работает так, как будто он является частью локальной сети. Отличие от реальной работы в локальной сети состоит в том, что скорость обмена оказывается гораздо меньшей.

Использование PPTP-клиента в системе Linux

PoPToP — это PPTP-сервер, выполняющийся в системе Linux. Для того, чтобы обеспечить взаимодействие компьютера, работающего под управлением Linux, с PoPToP или другим PPTP-сервером, необходим дополнительный программный пакет PPTP-Linux. Его можно поучить, обратившись по адресу http://cag.lcs.mit.edu/~cananian/Projects/PPTP/ или http://pptpclient.sourceforge.net. На узле http://pptpclient.sourceforge.net содержатся исходные коды PPTP-Linux в виде TAR-архивов и в формате RPM, а также двоичный код для процессоров x86 и Alpha. Вам следует скопировать пакет PPTP-Linux и, если необходимо, скомпилировать его и установить на свой компьютер.

Подобно PoPToP, для поддержки кодирования PPTP-Linux использует программу pppd и средства ядра. Поэтому, чтобы могли установить соединения с шифрованием передаваемых данных, вам надо внести изменения в состав pppd и ядра. Способ внесения необходимых изменений рассматривался в предыдущем разделе. Требуемые для этого инструментальные средства содержатся на узле PPTP-Linux.

В состав пакета PPTP-Linux входит сценарий инсталляции pptp-command. Для установки PPTP-Linux необходимо выполнить следующие действия.

1. Запустите сценарий по команде pptp-command.

2. Сценарий выведет список из четырех опций: start, stop, setup и quit. Для активизации процедуры установки введите число 3.

3. Сценарий отобразит список из девяти пунктов, соответствующих вариантам настройки. Введите 2, чтобы выбрать пункт Add a New CHAP secret.

4. Система запросит локальное имя вашей системы. Это имя будет присвоено системе при работе в VPN. Если VPN-маршрутизатор выполняется в системе Windows, вам надо задать имя домена NetBIOS. Например, вы можете указать arbor\\maple, в результате чего ваша система получит имя maple в домене arbor.

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

6. Система запросит пароль. Этот пароль должен совпадать с паролем, заданным при настройке PoPToP или другого VPN-сервера.

7. Сценарий снова отобразит список из девяти пунктов, позволяющий выбрать вариант настройки. На этот раз вам надо выбрать пункт 5 Add a NEW PPTP Tunnel.

8. Система отобразит список туннелей. Вероятнее всего, этот список будет пустым; в нем будет содержаться только пункт Other. Если вы увидите подходящий вам пункт, выберите его, но в большинстве случаев приходится выбирать Other.

9. Система запросит определение туннеля, в частности имя, IP-адрес VPN-сервера и атрибуты маршрутизации. Атрибуты маршрутизации совпадают с параметрами команды route. Например, выражение add -host 172.19.87.1 gw DEF_GW указывает на то, что система должна использовать адрес 172.19.87.1 в качестве шлюза по умолчанию.

10. Сценарий еще раз выведет список из девяти пунктов. Выберите пункт 7 Configure resolv.conf.

11. Выберите конфигурацию туннеля, созданную на шаге 9. Система запросит DNS-информацию, которая будет помещена в файл /etc/resolv.conf. Введите соответствующие данные.

12. Список из девяти пунктов появится на экране снова. Выберите пункт 8 Select a default tunnel.

13. Система запросит имя туннеля по умолчанию. Выберите туннель, созданный на шаге 9 (или любой другой).

14. При очередном появлении списка из девяти пунктов выберите пункт 9 Quit. Это приведет к завершению программы установки.

После выполнения описанных выше действий программа PPTP-Linux готова к взаимодействию с PPTP-сервером. Для подготовки РРТР VPN-соединения используется сценарий pptp-command. В списке, отображаемом на 3, надо выбрать пункт 1 (start). Программа запросит номер туннеля. После указания этого номера подготовка PPTP VPN-соединения завершится.

Проверить настройку VPN-соединения можно в таблице маршрутизации либо при подготовке к взаимодействию с сервером в системе VPN. Если VPN-сервер не доступен, проверьте VPN-маршрутизатор с помощью утилиты ping. Вы также можете использовать программу traceroute, чтобы выяснить, проходят ли пакеты через VPN-соединение. Если по обычному Internet-соединению пакеты проходят, это означает, что таблица маршрутизации составлена некорректно. Если путь к VPN-системам через VPN PPP-соединение отсутствует, Linux попытайтесь направить пакеты в сеть через обычное соединение.

Использование PPTP-клиента в системе Windows

Очень часто PPTP-клиенты устанавливаются на компьютерах под управлением Windows, которые используют сотрудники, вынужденные часто работать вне офиса. PPTP-клиенты входят в состав систем Windows 9x/Me и Windows NT/2000/XP, но по умолчанию они не инсталлируются. Программное обеспечение PPTP будет работать только при наличии действующего Internet-соединения. Ниже описана процедура запуска РРТР-клиента в системе Windows Me.

1. Дважды щелкните на пиктограмме Add/Remove Programs в окне Control Panel. В результате на экране отобразится диалоговое окно Add/Remove Programs Properties.

2. В окне Add/Remove Programs Properties щелкните на вкладке Windows Setup.

3. Дважды щелкните на пункте Communications списка типов компонентов. На экране появится диалоговое окно Communications.

4. В окне Communications выберите пункт Virtual Private Networking.

5. Щелкните на кнопке OK сначала в окне Communications, а затем в окне Add/Remove Programs Properties. В результате в системе Windows будет установлено программное обеспечение PPTP. Если вам будет предложено перезагрузить компьютер, сделайте это.

6. После перезагрузки системы откройте папку Dial-Up Networking в Control Panel.

7. Дважды щелкните на пиктограмме Make New Connection. Вы увидите окно Make New Connection Wizard, показанное на рис. 26.3.

Рис. 26.3. При создании VPN-соединения выбирайте Microsoft VPN Adapter, а не модем, через который устанавливается соединение

8. Введите имя, идентифицирующее соединение, и выберите устройство Microsoft VPN Adapter (см. рис. 26.3).

9. Щелкните на кнопке Next. В окне Make New Connection отобразится поле редактирования, в котором надо ввести имя или IP-адрес сервера VPN.

10. Щелкните на кнопке Next. Система оповестит вас о том, что новое устройство создано. Щелкните на кнопке Finish.

В результате выполненных действий в окне Dial-Up Networking появится новая пиктограмма. Если вы дважды щелкнете на ней, Windows отобразит диалоговое окно Connect То, показанное на рис. 26.4. Укажите в нем имя пользователя и пароль и, если необходимо, измените имя или IP-адрес сервера VPN. После щелчка на кнопке Connect система установит соединение (это может занять несколько секунд). После этого в вашей системе появится дополнительный IP-адрес, соответствующий сети сервера VPN. Вы можете обращаться к компьютерам этой сети как к узлам локальной сети, например, просматривать сетевое окружение, пользуясь средствами My Network Places (в ранних версиях Windows использовалось название Network Neighborhood). Ресурсы сети будут доступны вам как локальные ресурсы. Однако не забывайте, что физически сеть не является локальной, поэтому скорость обмена с узлами этой сети будет значительно меньше, чем у компьютеров, реально подключенных к ней.

Рис. 26.4. Диалоговое окно Connect To предоставляет контроль над VPN-соединением

Как показано на рис. 26.4, в диалоговом окне Connect To флажок опции сохранения пароля не установлен. Если вы установите его, то, установив флажок опции Connect Automatically, вы укажете Windows, что соединение надо инициировать при загрузке системы. После щелчка на кнопке Properties будут доступны дополнительные средства настройки. На экране отобразится диалоговое окно, показанное на рис. 26.5, имя которого совпадает с именем VPN-соединения. Чаще всего используются опции, представленные на вкладках Networking и Security. С помощью элементов, расположенных на вкладке Networking, вы можете выполнять сжатие данных и протоколировать ход сеанса, кроме того, можно указать, какие протоколы должны поддерживаться средствами VPN. Щелкнув на кнопке TCP/IP Settings, вы можете указать системе на необходимость получать IP-адрес и адреса серверов DNS у сервера PPTP. На вкладке Security укрываются имя пользователя, пароль и имя домена NetBIOS. С помощью элементов, расположенных на ней, вы можете разрешить или запретить кодирование пользовательского имени и пароля.

Рис. 26.5. С помощью средств настройки клиента задаются параметры VPN-взаимодействия, используемые по умолчанию

 

Сервер FreeS/WAN выполняет те же функции, что и сервер PPTP, но он ориентирован на работу в системе Linux. Как и сервер PPTP, Frees/WAN поддерживает защищенные соединения в незащищенном сетевом окружении, например в Internet. Первое, что надо сделать для обеспечения работы FreeS/WAN, — это получить и инсталлировать программное обеспечение. Затем можно настроить систему и устанавливать соединения.

FreeS/WAN — очень сложный пакет, и в данной главе рассматриваются лишь некоторые его средства. Дополнительную информацию вы найдете в документации на FreeS/WAN, в частности в руководстве по настройке (http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/config.html).

 

Инсталляция FreeS/WAN

FreeS/WAN иногда поставляется с версиями Linux SuSE и Mandrake. Если в вашей системе нет пакета FreeS/WAN, скопируйте его с Web-узла FreeS/WAN, расположенного по адресу http://www.freeswan.org. На нем, а точнее на сервере FTP (ftp://ftp.xs4all.nl/pub/crypto/freeswan/), на который ссылаются Web-страницы, находятся исходные коды программ. Для поддержки FreeS/WAN требуются нестандартные средства ядра, поэтому при установке данного сервера надо перекомпилировать ядро. Если FreeS/WAN входит в состав дистрибутивного пакета Linux, это значит, что необходимые изменения ядра уже выполнены. При изложении материала данного раздела предполагается, что вы скопировали исходные коды FreeS/WAN с Web-сервера.

Для компиляции исходных кодов FreeS/WAN вам понадобятся следующие компоненты.

• Стандартные инструменты разработки. Для подготовки сервера FreeS/WAN нужны такие инструменты, как GCC, make, набор библиотек и файлов заголовков. Эти компоненты по умолчанию устанавливаются при инсталляции большинства версий Linux.

• Исходные коды ядра. При компиляции FreeS/WAN автоматически вносятся изменения в исходные коды Linux, расположенные в каталоге /usr/src/linux. Если вы собираетесь изменить конфигурацию сервера, сделайте это перед инсталляцией FreeS/WAN.

• Библиотека GMP. FreeS/WAN использует библиотеку GМР (http://www.swox.com/gmp/). Данная библиотека поставляется в составе многих дистрибутивных пакетов Linux. Если она отсутствует, вам следует установить ее.

• Библиотека ncurses. При настройке FreeS/WAN может потребоваться библиотека ncurses. Она не является необходимым компонентом, но наличие ее желательно. Эта библиотека часто используется, поэтому не исключено, что она установлена в вашей системе.

Для инсталляции FreeS/WAN выполните следующие действия.

1. Убедитесь, что на вашем компьютере установлены все описанные выше компоненты.

2. Распакуйте пакет FreeS/WAN, выбрав для размещения его содержимого произвольный каталог, например подкаталог каталога usr/src. После распаковки не копируйте и не перемещайте каталог freeswan- версия , так как это может повредить символьные ссылки.

3. Сделайте текущим каталог с исходными кодами FreeS/WAN и введите одну из команд, предназначенных для конфигурирования пакета, внесения изменений в ядро Linux и создания FreeS/WAN. Команда make oldgo ориентирована на использование существующей конфигурации ядра и установок FreeS/WAN, заданных по умолчанию, команда make ogo вызывает make config, команда make menugo использует для настройки ядра make menuconfig, а команда make вызывает make xconfig. Использование последних трех команд позволяет изменить конфигурацию ядра.

4. Введите команду make kinstall для создания ядра. В результате будут созданы ядро и необходимые модули, а также вызвана команда make modules_install для инсталляции модулей.

5. Измените конфигурацию LILO, GRUB или другого инструмента, используемого для загрузки ядра Linux. Вам надо скопировать файл ядра из каталога /usr/src/linux/arch/architecture-code/boot, отредактировать файл /etc/lilo.conf (или другой конфигурационный файл) и ввести команду lilo (или другую команду загрузки).

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

С этого момента ядро вашей системы может поддерживать FreeS/WAN. В процессе установки должен быть создан файл /etc/ipsec.secrets, содержащий ключи кодирования. Этот файл будет использоваться в дальнейшем, сейчас же важно убедиться, что он есть в наличии и содержит некоторые ключи (ключи выглядят как наборы шестнадцатеричных цифр).

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

 

Редактирование конфигурационных файлов

FreeS/WAN использует два конфигурационных файла: /etc/ipsec.secrets и /etc/ipsec.conf. Эти файлы предназначены для различных целей. В файле /etc/ipsec.secrets содержатся ключи кодирования, а в файле /etc/ipsec.conf — опции общего назначения.

Создание ключей

Как было сказано ранее, при создании FreeS/WAN должен быть создан файл /etc/ipsec.secrets, содержащий ключи кодирования. Если этот файл не был создан или если ключи в нем отсутствуют, сгенерируйте ключи с помощью команды

# ipsec rsasigkey 128 > /root/rsa.key

Эта команда создает 128-битовый ключ и помещает его в файл /root/rsa.key. Указав значение параметра, отличающееся от приведенного в данном примере, вы можете сгенерировать ключ другой длины. Данные, полученные в результате выполнения этой команды, нельзя непосредственно использовать. В начало файла надо включить следующую строку:

: RSA {

Перед и после RSA обязательно должны быть пробелы. Кроме того, в конец файла надо включить как минимум один пробел, указав за ним закрывающую фигурную скобку (}). Полученный результат надо скопировать в файл /etc/ipsec.secrets. Описанные выше действия надо выполнить на обоих VPN-маршрутизаторах, реализованных с помощью FreeS/WAN.

В составе данных, сгенерированных посредством ipsec rsasigkey, содержится закомментированная строка, начинающаяся с #pubkey=. В ней указан открытый, или общий, ключ. Этот ключ надо передать системе, с которой должна взаимодействовать данная система.

Установка опций в файле ipsec.conf

В большинстве случаев при инсталляции FreeS/WAN создается файл /etc/ipsec.conf. Установки по умолчанию, как правило, не обеспечивают выполнение сервером требуемых функций, но содержимое этого файла можно использовать как базу для дальнейшей настройки системы. В файле /etc/ipsec.conf содержатся три основных раздела: config setup, conn %default и conn remotename.

Установка локальных опций

В разделе config setup содержатся локальные опции. В файле /etc/ipsec.conf, создаваемом по умолчанию, этот раздел имеет следующий вид:

config setup

# THIS SETTING MUST BE CORRECT or almost nothing will work;

# %defaultroute is okay for most simple cases.

interfaces=%defaultroute

# Debug-logging controls: "none" for (almost) none, "all" \

 for lots.

klipsdebug=none

plutodebug=none

# Use auto= parameters in conn descriptions to control \

 startup actions.

plutoload=%search

plutostart=%search

# Close down old connection when new one using same ID shows \

 up.

uniqueids=yes

Наиболее важный компонент данного раздела — опция interfaces, которая сообщает FreeS/WAN о том, какие интерфейсы следует использовать для поддержки VPN- соединений. Значение по умолчанию %defaultroute указывает на то, что FreeS/WAN должен использовать маршрут по умолчанию. Однако вы можете указать конкретные интерфейсы. В следующем примере опция interfaces задает использование интерфейсов eth0 и ppp1:

interfaces="ipsec0=eth0 ipsec1=ppp1"

Опции klipsdebug и plutodebug задают протоколирование функций KLIPS (Kernel IP Security — IP-защита ядра) и демона Pluto. Демон Pluto является частью пакета FreeS/WAN и поддерживает обмен ключами. Если в процессе работы возникают проблемы, вам надо задать для этих опций значение all.

Pluto может загружать соединения в память или автоматически запускать их при запуске FreeS/WAN. Опции plutoload и plutostart показывают, над какими соединениями надо выполнять соответствующие действия. В большинстве случаев можно принять значения данных опций по умолчанию, но, возможно, вы захотите указать лишь некоторые соединения; для этого надо задать их имена.

Установка опций, используемых по умолчанию для описания соединений

Отдельные соединения описываются в разделах, которые начинаются с ключевого слова conn. Наряду с реальными соединениями FreeS/WAN поддерживает соединение %default. В разделе, соответствующем этому соединению, обычно содержатся следующие опции.

• keyingtries. Если соединение установить не удалось, FreeS/WAN предпримет новую попытку. Значение 0 данной опции указывает на то, что попытки установить соединение должны продолжаться бесконечно. Если вы хотите ограничить число попыток, укажите в качестве значения опции keyingtries конкретное число.

• authby. По умолчанию применяется метод аутентификации, задаваемый значением authby=rsasig. Согласно этому методу, для аутентификации должны использоваться ключи RSA. Существует другой способ аутентификации, но в данной главе он рассматриваться не будет.

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

Установка удаленных опций, ориентированных на конкретные системы

Каждое соединение требует настройки, для выполнения которой надо изменить содержимое соответствующего раздела conn. За ключевым словом conn следует имя соединения, а затем — опции. В начале строки, содержащей опцию, должен стоять хотя бы один пробел. Многие из опций, включаемых в раздел conn, определяют сетевые интерфейсы. Рассмотрим рис. 26.6, на котором изображена типичная сеть, созданная с помощью FreeS/WAN. VPN-маршрутизатор, расположенный сверху, считается "левым". Вам необходимо указать FreeS/WAN IP-адреса, используемые в данной конфигурации. Для этого используются следующие опции.

• left subnet. Локальная подсеть, к которой подключен маршрутизатор FreeS/WAN. В примере, показанном на рис. 26.6, это сеть 172.16.0.0/16.

• left. Адрес, связанный с внешним интерфейсом сервера VPN. В большинстве случаев для этой опции задается значение %defaultroute, но вы можете указать конкретный IP-адрес. На рис. 26.6 это адрес 10.0.0.1.

• leftnexthop. IP-адрес обычного маршрутизатора, к которому подключена система VPN. В примере, показанном на рис. 26.6, используется адрес 10.0.0.10. Подобная информация необходима, так как KLIPS не применяет обычные средства маршрутизации, реализованные в ядре, а передает данные непосредственно следующему маршрутизатору.

• leftfirewall. Если подсеть, обслуживаемая VPN-маршрутизатором, содержит IP-адреса, которые не маршрутизируются обычными средствами (например, если она использует средства NAT), либо если VPN-маршрутизатор выполняет также функции брандмауэра, необходимо задать leftfirewall=yes.

• rightnexthop. В качестве значения этой опции задается IP-адрес обычного маршрутизатора, который доставляет пакеты удаленной сети.

• right. Данная опция указывает на внешний сетевой интерфейс удаленного VPN-маршрутизатора. Подобно left, вы можете принять значение этой опции по умолчанию.

• rightsubnet. Блок IP-адресов удаленной подсети. В примере, показанном на рис. 26.6, это сеть 192.168.1.0/24.

• leftid. Идентификатор "левой" системы. Это может быть IP-адрес, имя домена или имя узла, которому предшествует символ @ (например, @vpn.threeroomco.com). Имя узла, перед которым указан символ @, означает, что система не должна пытаться преобразовать имя в IP-адрес.

• rightid. Значение данной опции идентифицирует "правую" часть VPN-соединения.

• leftrsasigkey. Открытый RSA-ключ из файла /etc/ipsec.secrets на "левой" стороне VPN-соединения.

• rightrsasigkey. Открытый RSA-ключ из файла /etc/ipsec.secrets на "правой" стороне VPN-соединения.

• auto. Эта опция совместно с опциями plutoload и plutostart определяет, какие соединения должны загружаться и устанавливаться при запуске FreeS/WAN. Если установлены значения plutoload=%search и auto=add, соединения, соответствующие конфигурации, загружаются, а если заданы значения plutostart= %search и auto=start, соединения устанавливаются.

Рис. 26.6. Для определения конфигурации FreeS/WAN надо указать адреса, которые используются при формировании VPN

Не имеет значения, какую из систем вы назовете "левой", а какую "правой". Соединению следует присвоить имя, которое идентифицировало бы обе его стороны. Например, если одна из сетей расположена в Бостоне, а другая в Цинциннати, вы можете использовать имя boscinci, а затем называть систему, находящуюся в Бостоне, "левой", а систему, расположенную в Цинциннати, "правой". Одна и та же конфигурация используется на обеих сторонах соединения; FreeS/WAN выясняет, на какой стороне он находится, анализируя существующие сетевые соединения.

 

Установление соединения

Соединение между двумя маршрутизаторами FreeS/WAN устанавливается следующим образом: на одной стороне программа ipsec запускается в режиме демона, а на другой стороне та же программа используется для инициализации соединения. Если настройка выполнена корректно, то соединение должно устанавливаться автоматически, как только программа ipsec начнет выполняться на обеих сторонах. Не имеет значения, какая из систем использует программу в режиме демона; в отличие от PPTP, FreeS/WAN не различает клиентскую и серверную системы.

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

# ipsec setup start

После выполнения этой команды система, в зависимости от значений опций plutoload, plutostart и auto, загружает соединение, ожидает установления соединения или инициирует соединение. Если при настройке системы вы указали на обеих сторонах соединения опцию auto=add, можете запустить сервер на одной стороне и ожидать запроса на установление соединения, переданного другой системой. Чтобы запрос был передан, надо выполнить команду

# ipsec auto --up имя

При вызове программы ipsec задается имя соединения, например boscinci. В результате выполнения данной команды система предпримет попытку установить соединение. Для того чтобы проверить, успешной ли была эта попытка, надо использовать команду ipsec look. Если в составе ответа будет содержаться таблица маршрутизации VPN, это означает, что соединение было установлено корректно. Вы также можете использовать для проверки обычные программы сетевого обмена, например ping, traceroute или telnet, однако, если удаленная сеть доступна из Internet, эти инструменты не могут подтвердить тот факт, что связь осуществляется именно через VPN.

После окончания настройки сети можно изменить конфигурацию в файле /etc/ipsec.conf. Конфигурацию можно скорректировать таким образом, что соединение будет автоматически устанавливаться при выполнении команды ipsec setup start. Для запуска сервера FreeS/WAN используется сценарий SysV или локальный сценарий запуска.