Загрузка...



  • 8.1. Суперсерверы inetd и xinetd
  • 8.1.1. Настройка сервера inetd
  • 8.1.2. Настройка tcpd
  • 8.1.3. Протокол IPv6
  • 8.1.4. Установкаx inetd
  • 8.1.5. Настройка xinetd
  • 8.1.6. Параметры запуска xinetd
  • 8.1.7. Пример файла конфигурации /etc/xinetd
  • 8.2. Удаленный доступ: ssh и telnet
  • 8.3.Маршрутизация
  • 8.4. Настройка DHCP (Dynamic Host Configuration Protocol)
  • 8.5. Подсчет трафика. Программа MRTG
  • 8.6. Сетевая файловая система (NFS)
  • 8.6.1. Настройка сервера NFS
  • 8.6.2. Настройка клиента NFS
  • 8.7. Поисковый сервер ht:/Dig
  • 8.8. Прокси-сервер Socks5
  • 8.8.1.Установка и настройкасервера
  • 8.8.2. Альтернативные серверы Socks5
  • 8.8.3. Настройка клиента Socks5 (licq)
  • 8.9. Система обнаружения и защиты от вторжения
  • 8.9.1. Что такое LIDS?
  • 8.9.2. Установка LIDS
  • 8.9.3. Базовая настройка
  • 8.9.4. Правила доступа
  • 8.9.5. Администрирование LIDS
  • 8

    Конфигурирование сервера

    8.1. Суперсерверы inetd и xinetd

    В данной главе пойдет речь об общей настройке Интернет-суперсерверов inetd и xinetd, а также о настройке сервера xinetd для работы с протоколом IPv6.

    Для начала все же определимся, почему inetd(xinetd) называется суперсервером? Да потому, что он отвечает за установление TCP-соединения, то есть он прослушивает пакеты и запускает необходимые программы для обработки информации. Таким образом, получается, что сервер inetd (xinetd) управляет другими серверами и потому называется суперсервером. Например, если в запросе клиента будет требование установить соединение с двадцать первым портом, то суперсервер вызовет сервер ftp, конечно, при условии, что соединение с 21-м портом разрешено (в противном случае клиент получит сообщение Connection refused).

    По правде говоря, все не так просто как я описал — на практике все намного сложнее: за установление TCP-соединений отвечает демон tcpd (в более ранних версиях Linux его не было), программы-сервисы (httpd, ftpd) могут постоянно находиться в памяти (режим standalone), в этом случае они сами обрабатывают пакеты, и, соответственно, суперсервер их уже не вызывает.

    8.1.1. Настройка сервера inetd

    Для начала разберемся с настройкой inetd. Этот сервер использовался в дистрибутиве RedHat до версии 7, в более новых версиях он заменен на xinetd (описание этого суперсервера приведено далее в п. 8.1.4…8.1.7). При конфигурирования inetd вам потребуется отредактировать два файла /etc/inetd.conf и /etc/services. Первый, собственно, и есть файл конфигурации суперсервера, а во втором перечислены все сетевые службы, которые доступны в вашей системе. Формат файла /etc/services следующий:

    Имя_службы Порт/Протокол Псевдоним службы

    Листинг 8.1. Фрагмент файла /etc/services

    рор-2 109/tcp postoffice # POP version 2

    pop-2 109/udp

    pop-3 110/tcp # POP version 3

    pop-3 110/udp

    postoffice в данном случае является псевдонимом. Для некоторых служб могут потребоваться использование нескольких протоколов (как в листинге 8.1 для POP3 используется два протокола — TCP и UDP) и/или нескольких портов (см. листинг 8.2).

    Листинг 8.2. Несколько портов для сервиса ftp (RedHat)

    ftp-data 20/tcp

    ftp 21/tcp

    В других версиях ftp может потребоваться только одна запись — ftp 21/tcp. Из соображений безопасности лучше закомментировать символом # сервисы, которые вы не планируете использовать, например, если у вас роутер, то зачем вам sendmail (port 25)?

    Теперь переходим к файлу /etc/inetd.conf. Каждая запись в этом файле имеет следующий формат:

    Имя Тип_сокета Протокол Флаги Пользователь Путь Аргументы

    где:

    Имя — имя сетевой службы, которое должно быть указано в файле /etc/services.

    Тип_сокета — в этом поле указывается тип сокета, то есть тип технологии доставки данных для указанной службы. Наиболее часто используются значения: stream (поток) — для протокола TCP, dgram (дейтаграмма) — для протокола UDP и raw –непосредственно для протокола IP.

    Протокол — имя протокола.

    Флаги — с помощью флагов указывается статус ожидания. В качестве значения этого поля указывается ключевое слово wait или nowait. Если указано wait, то суперсервер inetd будет ожидать завершения работы данной сетевой службы на данном сокете, прежде чем перейти в состояние ожидания других запросов других служб на подключение к этому сокету. То есть в данной ситуации суперсервер перестает «слушать» порт до тех пор, пока на нем не завершит работу уже запущенная сетевая служба. Значение nowait приводит к обратной ситуации: после запуска описываемой сетевой службы суперсервер продолжает прослушивать сокет в ожидании других подключений. Обычно для служб с типом сокета stream устанавливается статус ожидания nowait, а для служб с типом сокета dgram — статус ожидания wait.

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

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

    Аргументы — все оставшиеся поля воспринимаются как аргументы для запускаемого сервера.

    Ниже (см. листинг 8.3) приведен пример записи в файле /etc/inetd.conf.

    Листинг 8.3. Фрагмент файла/etc/inetd.conf

    ftp stream top nowait root/usr/sbin/tcpd in.ftpd

    где:

    ftp — имя сетевой службы;

    stream — задает тип сокета stream (потоковый сокет);

    tcp — протокол (указан протокол tcp, так как именно этот протокол использует служба FTP в качестве протокола транспортного уровня);

    nowait — суперсервер продолжает «слушать» порт после выполнения одного сервера для определенного порта;

    root — сервер FTP будет запущен с правами root;

    /usr/sbin/tcpd — сервер, который будет вызван для обработки соединения;

    in.ftpd — аргумент, то есть программа, которую должен выполнить tcpd после проверки некоторой информации (о ней немного позже).

    Еще вы можете написать и так, для прямого вызова службы ftp (ProFTP):

    ftp stream tcp nowait root/usr/sbin/in.proftpd

    В данном случае сразу будет вызван демон ProFTP. Запись in.proftpd является ссылкой на proftpd. Если будете использовать такой вызов ProFTP, позаботьтесь о том, чтобы proftpd имел тип inetd, а не standalone.

    8.1.2. Настройка tcpd

    Демон inetd является довольно удобным в использовании средством для организации работы Интернет-сервера. И все было бы замечательно, если бы не одно «но». А это «но» заключается в том, что разработчики inetd очень мало уделили внимания защите, что является недопустимым в нашей суровой Интернет-действительности. Восполнить этот недочет призван демон tcpd (система TCP-Wrappers). Так что давайте теперь разберемся, что же представляет из себя демон tcpd, который является еще одним барьером в системе безопасности.

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

    Файл hosts.allow содержит список хостов, которым разрешено подключаться к вашей системе, a hosts.deny — запрещено. Записи имеют формат служба:хост.домен. Если вы хотите разрешить или запретить доступ всем, используйте ALL. Запись ALL:ALL открывает или закрывает доступ к вашему компьютеру для всех остальных компьютеров и для всех видов сервисов (см. листинг 8.4).

    Листинг 8.4. Файл /etc/hosts.allow

    http:ALL

    ftp:ALL

    ALL:server.dhsilabs.com

    В листинге 8.4 доступ к http и ftp разрешен всем, но доступ ко ВСЕМ сервисам разрешен только компьютеру server.dhsilabs.com.

    8.1.3. Протокол IPv6

    Думаю, что основной момент настройки понятен, и теперь переходим к протоколу IPv6. Схема 32-разрядной адресации протокола IPv4 привела к дефициту IP-адресов. В новой версии протокола IP (IPv6, ранее именовавшегося IPng — IP next generation) адрес состоит из 16-ти октетов и изображается в виде восьми пар октетов, разделенных двоеточиями. В версии 6 используется 128-разрядные адреса получателей и отправителей (это в 4 раза больше, чем в 4-ой версии). Адрес в формате IPv6 может выглядеть так:

    3A3F:BC21:F133:56C4:A103:DB11:10 00:400F

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

    Протокол IPv6 подробно описан в RFC 1883, а IPv4 — в RFC 791.

    8.1.4. Установкаx inetd

    Суперсервер xinetd является достойной заменой inetd. Этот суперсервер, помимо всего прочего, обладает встроенными механизмами защиты, которые для inetd выполняет специальный демон tcpd. К тому же xinetd, в отличии от inetd, поддерживает IPv6. Даже если вы пока не планируете переходить на IPv6, установка xinetd будет очень полезной из-за расширенных функций суперсервера. Сам xinetd появился в Red Hat начиная с 7-ой версии и обычно устанавливается во время установки системы. Если у вас он еще не установлен, сейчас самое время это сделать.

    При этом рекомендую пойти по пути наименьшего сопротивления и установить xinetd из RPM-пакета, а можно и выкачать из Интернет последнюю версию xinetd по адресу http://www.svnack.net/xinetd и установить его из исходных кодов.

    После того, как вы распакуете исходники, введите ./configure, перейдя предварительно в каталог с исходниками (при этом желательно иметь права root). Для сценария configure вы можете использовать параметры, представленные в табл. 8.1.

    Параметры сценария configure Таблица 8.1

    Параметр Описание
    --with-libwrap Демон будет использовать tcp wrappers. При этом у вас уже должен быть установлен libwrap. С этой опцией xinetd будет сперва проверять ваши /etc/hosts.allow и /etc/hosts.deny файлы, и только после этого запускает свой механизм контроля доступа
    --with-loadavg Компилирует xinetd с опцией max_load. Этот параметр остановит сервис, когда нагрузка достигнет определенного уровня
    --wilh-inet6 Включает поддержку IPv6

    Внимание! При включении IPv6 все IPv4-сокеты становятся IPv6-сокетами и соответственно ядро (это прежде всего) и все программы должны поддерживать IPv6. Поэтому будьте готовы к тому, что вам понадобится перекомпилировать свое ядро с поддержкой IPv6. Если ваше ядро не поддерживает IPv6, выкачайте последнюю версию ядра по адресу http://www.kernel.org. Тем не менее, и после включения IPv6 запросы IPv4 также будут обрабатываться. Так что никакой аварийной ситуации не будет.

    Возвращаясь к настройке: теперь введите make, а затем — make install.

    Файл конфигурации xinetd — /etc/xinetd.conf отличается по синтаксису от файла конфигурации inetd. Но если inetd у вас уже настроен и вам лень настраивать все заново, воспользуйтесь программой itox: itox < /etc/inetd.conf > /etc/xinetd.conf

    Такое использование команды itox верно при условии, что файлом конфигурации inetd является файл /etc/inetd.conf, a xinetd –/etc/xinetd.conf. Но в любом случае, вам не помешает разобраться с форматом xinetd.conf. 

    Рис. 8.1. Автозапуск суперсервера


    После установки суперсервера из RPM-пакета или его сборки из исходных текстов, xinetd (или inetd) добавляется в сценарий автозагрузки системы. Напомню, что включить или отключить запуск xinetd (inetd) или любого другого сервиса всегда можно с помощью конфигуратора drakxservices в Linux Mandrake или setup в Linux Red Hat (см. рис. 8.1).

    8.1.5. Настройка xinetd

    Синтаксис файла xinetd.conf такой:

    service < service_name>

    {

     <атрибут> <оператор_присваивания> <значение> <значение> …

     <атрибут> <оператор_присваивания> <значение> <значение> …

     …

     <атрибут> <оператор_присваивания> <значение> <значение> …

    }

    Service_name – это имя сервиса (login, shell, telnet, ftp, pop3 и т.д). Оператор присваивания может быть одним из следующих: «=», «+=», «-=». Большинство атрибутов может работать только с оператором «=» (равно). Назначение операторов следующее:

    «=» — присвоить значение атрибуту;

    «+=» — добавить еще одно значение;

    «-=» — удалить значение.

    Атрибут может иметь несколько значений, указанных через пробел. Некоторые параметры очень похожи на параметры inetd. Список всех атрибутов приведен в табл. 8.2.

    Атрибуты сервиса для сервера xinetd Таблица 8.2 

    Атрибут Описание
    Id Используется, если сервисы используют разные протоколы. Обычно совпадает с именем сервиса
    Туре Может быть использована любая комбинация из следующих значений: RPC — если это сервис RPC (Remote Procedure Call). UNLISTED — если сервис не описан в файле /etc/rpc для rpc-сервисов или в /etc/services для не rpc. INTERNAL — если xinetd представляет этот сервис (для echo, time, daytime, chargen, и discard). Если RPC-сервисы у вас работают некорректно после установки xinetd, вы можете использовать для них старый inetd — inetd и его новая версия xinetd прекрасно уживаются вместе. В файле /etc/inetd.confоставьте только rpc-сервисы, а остальное закомментируйте, а в /etc/xinetd.conf — наоборот
    Flags В качестве значения может быть использована любая комбинация из следующих значений: NODELAY — для tcp-сервиса будет установлен флаг сокета — TCP_NODELAY. Только для TCP-сервисов! DISABLE — отключить сервис. KEEPALIVE — установка флага сокета SO_KEEPALIVE. Только для TCP-сервисов! REUSE — установить флаг SO_REUSEADDR на сокет сервера. INTERCEPT — перехватывать пакеты или принимать соединения по порядку, проверяя, что они приходят из нужных мест. NORETRY — избегать повторных попыток в случае неудачи. IDONLY — соединение будет приниматься только от идентифицированных пользователей. На удаленной машине должен работать identification-сервер
    disabled Может принимать 2 значения, «yes» и «no». Если указать «yes», сервис запускаться не будет
    socket_type Тип сокета. Может принимать следующие значения: stream — сокет stream, обычно используется службами, работающими на основе протокола TCP dgram — сокет dgram, обычно используется службами, работающими на основе протокола UDP raw — сокет raw для сервисов, требующих прямого доступа к IP seqpacket — сокет seqpacket для сервисов, требующих надежную последовательную пересылку дейтаграмм
    protocol Задает протокол, по которому будет работать сервер (top, udp, …)
    wait Задает статус ожидания и может принимать два значения: yes и no, которые соответствуют значениям wait и nowait для сервера inetd (см. выше). Значение yes обычно устанавливается на сокетах dgram, а значение no на сокетах stream
    user Задает пользователя, от имени которого будет запущен сервер. Пользователь должен быть определен в файле /etc/passwd. По умолчанию сервер запускается от имени пользователя root
    server Указывает абсолютный путь к запускаемому серверу
    server args Определяет аргументы, которые будут переданы серверу
    log_on_failure Определяет, какая информация будет писаться в файл отчета (протокол), если сервис по каким-либо причинам не запустился: HOST — записывать адрес удаленного хоста. USERID — если возможно, записывать идентификатор удаленного пользователя (используется протокол идентификации RFC 1413). ATTEMPT — записывать факт неудачной попытки. RECORD — записывать информацию с удаленного хоста, в случае невозможности запуска сервера
    log_on_success Определяет, какая информация будет писаться в файл отчета (протокол) в случае удачного запуска сервиса. Можно комбинировать любые из следующих значений: PID — записывать идентификатор запущенного серверного процесса. HOST — записывать адрес удаленного хоста. USERID — если возможно, идентификатор удаленного пользователя (используется протокол идентификации RFC 1413). EXIT — записывать, каким образом был произведен выход. DURATION — записывать продолжительность сессии
    rpc_number Определяет номер сервиса RPC
    rpc_version Определяет версию сервиса RPC
    env Задает значение атрибута. Атрибут представляет собой список строк типа: «name=value». Эти переменные будут добавлены в окружение перед тем, как сервер будет запущен
    passenv Это список переменных окружения из окружения xinetd, которые могут быть переданы серверу
    port Определяет порт сервиса. Если порт указан в файле /etc/services, то значение данного параметра должно совпадать с ним
    redirect Позволяет tcp-сервису делать перенаправление на другой хост. Значение задается в виде host:port
    interface Устанавливает интерфейс, на котором будет работать сервис. Синтаксис: interface=IP-адрес
    bind Это синоним параметра interface
    banner Определяет имя файла, который будет показываться при соединении с сервисом
    banner_success Определяет имя файла, который будет показываться при удачном соединении
    banner_fail Определяет имя файла, который будет показываться при неудачном соединении
    cps Атрибут имеет два аргумента. Первый устанавливает количество соединений в секунду. Если это число будет превышено, сервис будет временно недоступен. Второй — число секунд, после которых сервис снова будет доступен
    max_load Определяет максимальную загрузку. При достижении максимума, сервер перестает принимать запросы на соединение. Значение параметра — число типа float
    instances Устанавливает число серверов, которые могут быть активны одновременно для сервиса (по умолчанию лимита нет). Значением этого атрибута может быть число, либо — UNLIMITED
    nice Устанавливает приоритет сервиса

    Примечание. RPC (Remote Procedure Call) — вызов удаленной процедуры. Используется в серверной части приложения. Механизм RPC скрывает от программиста детали сетевых протоколов нижележащих уровней.

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

    1. socket_type

    2. user

    3. server

    4. wait

    Параметр protocol указывается только для RFC-сервисов, а также для всех сервисов, которые не описаны в /etc/services. Параметр rpc_version — только для rpc-сервисов. Параметр rpc_nuinber указывается только для RFC-сервисов, которые не указаны в файле /etc/rpc. Параметр port задается только для He-RPC-сервисов, которые не описаны в /etc/services. Следующие атрибуты поддерживают все операторы присваивания:

    1. only_from

    2. no_access

    3. log_on_success

    4. log_on_failure

    5. passenv

    6. env (не поддерживает оператор «-=»)

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

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

    1. log_type

    2. log_on_success

    3. log_on_failure

    4. only_from

    5. no_access

    6. passenv

    7. instances

    8. disabled

    9. enabled

    8.1.6. Параметры запуска xinetd

    Я надеюсь, что с настройкой более-менее все понятно. Если же мои надежды не оправдались, то в разделе 8.1.7 вы найдете пример файла /etc/xinetd.conf. Сейчас же займемся запуском только что откомпилированного и настроенного суперсервера. А запускать его можно с параметрами, указанными в табл. 8.3.

    Параметры запуска xinetd Таблица 8.3

    Параметр Описание
    -f файл Устанавливает альтернативный файл конфигурации, который должен использоваться вместо стандартного файла /etc/xinetd.conf
    -pidfile рid_файл Файл с ID-процесса
    -stayalive Даже если ни один сервис не прописан, демон должен выполняться («остаться в живых»)
    -loop число Задает количество коннектов в секунду
    -d Режим отладки (debug mode)
    -reuse Перед тем как связать сокет сервиса с IP-адресом, суперсервер установит опцию сокета SO_REUSEADDR
    -limit число Ограничение на количество одновременно запущенных процессов

    В табл. 8.3 я привел описание не всех параметров запуска, выбрав лишь самые нужные. Более подробную информацию вы сможете получить в документации по xinetd. Так же как и inetd, xinetd можно контролировать с помощью сигналов (см. табл. 8.4).

    Сигналы суперсервера Таблица 8.4

    Сигнал Описание
    SIGUSR1 Суперсервер перечитает файл конфигурации
    SIGQUIT Остановит xinetd
    SIGTERM Перед остановкой xinetd все процессы будут остановлены

    8.1.7. Пример файла конфигурации /etc/xinetd

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

    Листинг 8.5. Фрагмент файла конфигурации /etc/xinetd

    # Параметры по умолчанию для всех возможных сервисов

    defaults

    {

    # Число серверов, которые могут быть активны одновременно для сервиса.

     instances = 25

    # Параметры протоколирования

     log_type = FILE /var/log/servicelog

     log_on_success = HOST PID

     log_on_failure = HOST RECORD

     only_from = 111.11.111.0 111.111.112.0

     only_from = localhost 192.168.1.0/32

     disabled = tftp

    }

    service login

    {

     flags = REUSE

     socket_type = stream

     protocol = tcp

     wait = no

     user = root

     server = /usr/etc/in.rlogind

     log_type = SYSLOG Iocal4 info

    }

    # Сервис telnet — эмуляция терминала удаленных систем

    # (для 127.0.0.1)

    service telnet

    {

     flags = REUSE

     socket_type = stream

     wait = no

     user = root

     server = /usr/etc/in.telnetd

     bind = 127.0.0.1

     logon failure += USERID

    }

    # Сервис telnet — эмуляция терминала удаленных систем

    service telnet

    {

     flags = REUSE

     disabled = yes

     socket_type = stream

     wait = no

     user = root

    # server = /usr/etc/in.telnetd

     bind = 192.231.139.175

     redirect = 128.138.202.20 23

     log_on_failure += USERID

    }

    service ftp

    {

     socket_type = stream

     wait = no

     user = root

     server = /usr/etc/in.ftpd

     server_args = –1

     instances = 4

     log_on_success += DURATION USERID

     logon failure += USERID

    # Время работы сервиса

     access_times = 2:00-8:59 12:00-23:59

    # приоритет

     nice = 10

    }

    service name

    {

     socket_type = dgram

     wait = yes

     user = root

     server = /usr/etc/in.tnamed

    }

    #  Поддержка протокола TFTP (Trivial FTP). Этот протокол

    #  используется для обмена информацией между интеллектуальными

    #  маршрутизаторами и, скорее всего, вы не будете его

    #  использовать.

    service tftp {

     socket_type = dgram

     wait = yes

     user = root

     server = /usr/etc/in.tftpd

     server_args = –s /tftpboot

    }

    #  SMTP-сервис Qmail. Конфигурируется для запуска по требованию

    #  суперсервера xinetd

    service smtp

    {

     socket_type = stream

     protocol = tcp

     wait = no

     user = qmaild

     id = smtp

     server = /var/qmail/bin/tcp-env

     server_args = /var/qmail/bin/qmail-smtpd

     log_on_success –= DURATION USERID PID HOST EXIT

     log_on_failure –= USERID HOST ATTEMPT RECORD

    }

    #  Сервис finger, позволяющий узнать полезную общедоступную

    #  информацию о пользователях системы. Например, для того,

    #  чтобы узнать информацию о пользователе root системы host.com,

    #  введите одноименную команду: finger root@host.com

    #  Для работы этой команды необходим сервис finger.

    #

    service finger

    {

     socket_type = stream

     disabled = yes

     wait = no

     user = nobody

     server = /usr/etc/in.fingerd

    }

    service echo

    {

     type = INTERNAL

     id = echo-stream

     socket_type = stream

     protocol = tcp

     user = root

     wait = no

    }

    service echo {

     type = INTERNAL

     id = echo-dgram

     socket_type = dgram

     protocol = udp

     user = root

     wait = yes

    }

    service rstatd

    {

     type = RFC

     disabled = no

     flags = INTERCEPT

     rpc_version = 2-4

     socket_type = dgram

     protocol = udp

     server = /usr/etc/rpc.rstatd

     wait = yes

     user = root

    }

    Как видно из примера, я описал лишь те сервисы, которые больше всего необходимы. Доступ к сервисам в рассматриваемом примере могут получать только из сети 111.111.111.0, 111.111.112.0 и 192.168.1.0. Можно также указывать адрес и маску подсети, например 192.168.1.0/32. Вместо sendmail я использовал qmail. Можно было бы запускать qmail в режиме standalone, но так как я не очень часто пользуюсь услугами 25-го порта, то мне удобнее запускать сервис smtp через xinetd. Из соображений безопасности я отключил некоторые сервисы: finger, telnet.

    8.2. Удаленный доступ: ssh и telnet

    Сервис Telnet обеспечивает базовую эмуляцию терминалов удаленных систем, поддерживающих протокол Telnet над протоколом TCP/IP. Обеспечивается эмуляция терминалов Digital Equipment Corporation VT 100, Digital Equipment Corporation VT 52, TTY. Протокол Telnet описан в документе RFC 854, который вы найдете на прилагаемом компакт-диске.

    Любые команды, выполняемые с помощью Telnet, обрабатываются telnet-сервером, а не локальным компьютером. Пользователь лишь видит результат выполнения этих команд.

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

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

    SSH (Secure Shell) — программа, позволяющая вам зарегистрироваться на удаленных компьютерах и установить зашифрованное соединение. Существует также «безопасная» версия telnet — stelnet.

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

    Рис. 8.2.Telnet-клиент для Windows


    Оболочку ssh можно использовать для безопасной регистрации на удаленном сервере или копировании данных между двумя машинами, в то же время предотвращая атаки путем присоединения посередине (session hijacking) и обманом сервера имен (DNS spotting).

    Оболочка Secure Shell поддерживает следующие алгоритмы шифрования:

    BlowFish — это 64-разрядная схема шифрования. Этот алгоритм часто используется для высокоскоростного шифрования данных больших объемов.

    Тройной DES (Data Encryption Standard) — стандарт для шифрования данных. Данный алгоритм довольно старый, поэтому не рекомендуется его использовать. Обычно DES используется для шифрования несекретных данных.

    IDEA (International Data Encryption Algorithm) — международный алгоритм шифрования информации. Этот алгоритм работает со 128-разрядным ключом и поэтому он более защищен, чем BlowFish и DES.

    RSA (Rivest-Shamir-Adelman algorithm) — алгоритм Ривеста-Шамира-Адельмана. Представляет собой схему шифрования с открытым и секретным ключами.

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

    Оболочка ssh очень эффективна против анализаторов протоколов, так как она не только шифрует, но и сжимает трафик перед его передачей на удаленный компьютер. Программу ssh можно скачать по адресу http://www.cs.hut.fi/ssh/. Версия ssh для UNIX распространяется бесплатно, а за Windows-версию (имеется в виду клиент для Windows) нужно заплатить.

    Оболочка ssh незаменима в тех случаях, когда удаленно нужно администрировать сервер или когда сервер не имеет собственного монитора. При использовании telnet все данные, которые передаются через telnet-соединение, доступны в открытом виде. А значит, имена пользователей и пароли будут доступны всем, кто прослушивает трафик с помощью анализатора. Шифрование ssh выполняет, используя несколько различных алгоритмов, включая DES и 3DES.

    Программа состоит из демона sshd, который запускается на Linux/UNIX-машине, и клиента ssh, который распространяется как для Linux, так и для Windows. Чтобы установить ssh, возьмите исходные тексты и поместите их по традиции в каталог /usr/src/. Затем распакуйте архив и установите программу, выполнив следующую последовательность действий:

    cd /usr/src/

    tar xzf ssh-2.4.0.tar.gz

    cd ssh-2.4.0

    ./configure

    make

    make install

    Чтобы ssh начал работать, необходимо запустить демон sshd на той машине, к которой предполагается подключение. Желательно добавить команду запуска в сценарий загрузки системы для автоматического запуска. Демон sshd работает по 22 порту (см. листинг 8.6). Если не ошибаюсь, ssh невозможно использовать вместе с xinetd/inetd — его нужно запускать подобно httpd– серверу в режиме standalone.

    Листинг 8.6. Фрагмент файла /etc/services

    ssh 22/tcp # SSH Remote Login Protocol

    ssh 22/udp # SSH Remote Login Protocol

    Обычно с настройкой sshd не возникает никаких неприятных моментов. Подробно настройка демона будет рассмотрена чуть ниже в этой главе. Теперь попробуйте зарегистрироваться на этой машине через ssh. Для этого нужно установить этот же пакет на другую машину под управлением Linux/UNIX (или установить Windows-клиент ssh) и ввести команду:

    $ ssh hostname.domain

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

    Если вам нужно указать другое имя пользователя, используйте параметр –l программы ssh:

    ssh –l user hostname.ru

    Так можно указать программе ssh, от имени какого пользователя нужно регистрироваться на удаленной машине (см. рис. 8.3).

    При использовании Windows-клиента имя компьютера, имя пользователя и пароль нужно ввести в диалоговом окне программы. Если соединение не устанавливается, попробуйте выбрать метод кодирования blowfish. Если и это не поможет, выберите 3DES.

    Работа в ssh аналогична работе в telnet. Вы можете администрировать удаленную машину также легко, как и локальную. Опции программы ssh указаны в табл. 8.5.

    Рис.8.З. Регистрация на удаленной машине


    Опции программы ssh Таблица 8.5 

    Опция Описание
    Отключает перенаправление аутентификации агента соединения
    Включает перенаправление аутентификации агента соединения
    -с blowfish|3des Позволяет выбрать алгоритм шифрования при использовании первой версии протокола SSH. Можно указать или blowfish, или 3des
    -с шифр Задает список шифров, разделенных запятыми в порядке предпочтения. Только для второй версии протокола SSH. Допускаются значения blowfish, twofish, arcfour, cast, des и 3des
    -f Данная опция переводит ssh в фоновый режим после аутентификации пользователя. Рекомендуется использовать для запуска программы Х11 . Например, ssh –f hostxterm
    -i идент_файл Задает нестандартный идентификационный файл (для нестандартной RSA/DSA-аутентификации)
    -l имя_пользоват Указывает от имени какого пользователя будет осуществляться регистрация на удаленной машине
    -р порт Определяет порт, к которому подключится программа ssh (по умолчанию используется порт 22)
    -q «Тихий режим». Будут отображаться только сообщения о фатальных ошибках. Все прочие предупреждающие сообщения в стандартный выходной поток выводиться не будут
    -x Отключить перенаправление Х11
    -X Включить перенаправление Х11
    -1 Использовать только первую версию протокола SSH
    -2 Использовать только вторую версию протокола SSH
    -4 Разрешается использовать IP-адреса только в формате IPv4
    -6 Разрешается использовать IP-адреса только в формате IPv6

    Оболочка ssh использует два файла конфигурации ssh_conf и sshd_conf. Думаю, что нет смысла говорить о том, что они находятся в директории /etc/ssh. Рекомендую в файле sshd_conf прописать следующую строчку:

    allowedadress 10.1.1.1 10.1.2.1 10.1.3.1

    Это означает, что доступ по ssh может быть выполнен только с машин с адресами 10.1.1.1, 10.1.2.1, 10.1.3.1. Это оградит ваш компьютер от нежелательных вторжений извне.

    Программа stelnet во всем полностью аналогична программе telnet, но она выполняет шифрование трафика, который передается во время telnet-соединения.

    Демон sshd — это программа-демон для оболочки ssh. Обычно sshd запускается на машине, к которой подключаются клиенты ssh. Последние версии демона sshd поддерживают две версии протокола ssh — ssh версия 1, и ssh версия 2.

    Протокол SSH версия 1

    У каждого узла есть свой RSA-ключ (обычно 1024 бит), который используется для идентификации узла. Этот ключ еще называется открытым. Дополнительно, при запуске демона, генерируется еще один RSA-ключ — ключ сервера (обычно 768 бит). Этот ключ создается заново каждый час и никогда не сохраняется на диске.

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

    Затем клиент пытается аутентифицировать себя, используя .rhosts-аутентифи-кацию, аутентификацию RSA или же аутентификацию с использованием пароля.

    Обычно .rhosts-аутентификация небезопасна и поэтому она отключена.

    Протокол SSH версия 2

    Версия 2 работает аналогично: каждый узел имеет определенный DSA-ключ, который используется для идентификации узла. Однако, при запуске демона ключ сервера не генерируется. Безопасность соединения обеспечивается благодаря соглашению Диффи-Хелмана (Diffie-Hellman key agreement).

    Сессия может кодироваться следующими методами: 128-разрядный AES, Blowfish, 3DES, CAST128, Arcfour, 192-разрядный AES или 256-разрядный AES.

    Опции демона sshd указаны в табл. 8.6.

    Опции демона sshd Таблица 8.6

    Опция Описание
    -b биты Определяет число битов для ключа сервера (по умолчанию 768). Данную опцию можно использовать, только если вы используете протокол SSH версии 1
    -d Режим отладки (DEBUG). В этом режиме сервер не переходит в фоновый режим и подробно протоколирует свои действия в системном журнале. Использование данной опции особенно полезно при изучении работы сервера
    Если указана это опция, демон sshd отправляет отладочные сообщения не в системный журнал, а на стандартный поток ошибок
    -f конфиг_файл Задает альтернативный файл конфигурации. По умолчанию используется /etc/ssh/sshd_config
    -g время Предоставляет клиенту, не прошедшему аутентификацию, дополнительное время, чтобы аутентифицировать себя. По умолчанию время равно 600 секундам. Если за это время клиент не смог аутентифицировать себя, соединение будет прекращено. Значение 0 интерпретируется как бесконечное ожидание
    -h файл_ключа Задает альтернативный файл открытого ключа (ключ узла). По умолчанию используется файл /etc/ssh/ssh_host_key. Эта опция может понадобиться, чтобы sshd мог выполняться не только от имени суперпользователя root. Кроме этого, частым использованием этой опции является запуск sshd из сценариев, задающих различные настройки в зависимости от времени суток. Например, в дневное (рабочее) время устанавливаются одни опции, а в вечернее(иерабочее) время — другие
    -i Используется, если нужно запускать sshd через суперсервер xinetd (inetd). Обычно демон sshd не запускается суперсервером xinetd (inetd), а запускается при загрузке системы, потому что демону sshd требуется некоторое время (10 секунд) для генерирования ключа сервера, прежде чем он сможет ответить на запросы клиентов
    -k время Задает время, спустя которое ключ сервера будет создан заново. По умолчанию время составляет 3600 секунд (1 час). Данную опцию можно использовать, только если вы используете протокол SSH версии 1
    -р порт Указывает альтернативный порт, который демон sshd будет прослушивать. По умолчанию используется порт 22
    -q «Тихий режим». В данном режиме протоколирование сессии производиться не будет. Обычно протоколируется начало аутентификации, результат аутентификации и время окончания сессии
    -t Тестовый режим. Данный режим применяется для проверки корректности файла конфигурации
    -D При использовании этой опции демон не будет переходить в фоновый режим
    -4 Разрешается использовать IP-адреса только в формате IPv4
    -6 Разрешается использовать IP-адреса только в формате IPv6

    Файл конфигурации демона /etc/ssh/sshd_config выглядит примерно так, как это показано в листинге 8.7

    Листинг 8.7 Файл конфигурации /etc/ssh/sshd_config

    # $OpenBSD: sshd_config,v 1.38 2001/04/15 21:41:29 deraadt Exp $

    # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

    # This is the sshd server system-wide configuration file. See sshd(8)

    # for more information.

    Port 22

    # Protocol 2,1

    # ListenAddress 0.0.0.0

    # ListenAddress ::

    HostKey /etc/ssh/ssh_host_key

    HostKey /etc/ssh/ssh_host_rsa_key

    HostKey /etc/ssh/ssh_host_dsa_key

    ServerKeyBits 768

    LoginGraceTime 600

    KeyRegenerationInterval 3600

    PermitRootLogin yes

    #

    # Don't read ~/.rhosts and ~/.shosts files

    IgnoreRhosts yes

    # Uncomment if you don't trust ~/.ssh/known_hosts for

    RhostsRSAAuthentication

    # IgnoreUserKnownHosts yes

    StrictModes yes

    X11Forwarding yes

    X11DisplayOffset 10

    PrintMotd yes

    # PrintLastLog no

    KeepAlive yes

    # Logging

    SyslogFacility AUTHPRIV

    LogLevel INFO

    # obsoletes QuietMode and FascistLogging

    RhostsAuthentication no

    #

    # For this to work you will also need host keys in /etc/ssh/

    ssh_known_hosts

    RhostsRSAAuthentication no

    # similar for protocol version 2

    HostbasedAuthentication no

    #

    RSAAuthentication yes

    # To disable tunneled clear text passwords, change to no here!

    PasswordAuthentication yes

    PermitEmptyPasswords no

    # Uncomment to disable s/key passwords

    # ChallengeResponseAuthentication no

    # Uncomment to enable РАМ keyboard-interactive authentication

    # Warning: enabling this may bypass the setting of 'PasswordAuthentication'

    # PAMAuthenticationViaKbdInt yes

    # To change Kerberos options

    # KerberosAuthentication no

    # KerberosOrLocalPasswd yes

    # AFSTokenPassing no

    # KerberosTicketCleanup no

    # Kerberos TGT Passing does only work with the AFS kaserver

    # KerberosTgtPassing yes

    # CheckMail yes

    # UseLogin no

    # MaxStartups 10:30:60

    # Banner /etc/issue.net

    # ReverseMappingCheck yes

    Subsystem sftp/usr/libexec/openssh/sftp-server

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

    Директива Port предназначена для указания порта, которые демон будет прослушивать (данная директива аналогична опции –р.):

    Port 22

    Следующая директива — это директива Protocol. С помощью этой директивы можно указать в порядке предпочтения номера поддерживаемых протоколов SSH:

    Protocol 2,1

    Такое определение директивы означает, что сначала сервер будет пытаться установить соединение с клиентом по протоколу SSH версии 2, а потом — по протоколу SSH версии 1. Можно указать использование только одной версии протокола, например, Protocol 1.

    Директива ListenAddress указывает локальный адрес, который должен прослушивать демон.

    Директива HostKey определяет файлы ключей. Файлами по умолчанию являются:

    /etc/ssh/ssh_host_key

    /etc/ssh/ssh_host_rsa_key

    /etc/ssh/ssh_host_dsa_key

    Директива ServerKeyBits определяет разрядность ключа сервера для протокола ssh первой версии. По умолчанию используется 768-разрядный ключ (768 бит).

    Директива LoginGraceTime аналогична опции –g: предоставляет клиенту дополнительное время, чтобы аутентифицировать себя. По умолчанию время равно 600 секундам. Если за это время клиент не смог аутентифицировать себя, соединение будет прекращено.

    Директива KeyRegenerationInterval аналогична опции –k. Она определяет время, спустя которое ключ сервера будет создан заново. По умолчанию время составляет 3600 секунд (1 час).

    Директива PermitRootLogin определяет, разрешено ли пользователю root регистрироваться по ssh. Значение по умолчанию:

    PermitRootLogin yes

    Еще две директивы, имеющие непосредственное отношение к аутентификации — это PasswordAuthentication и PermitEmptyPasswords. Первая разрешает (при значении yes) аутентификацию с помощью пароля, а вторая — разрешает (при значении yes) использовать пустые пароли. Значения по умолчанию:

    PasswordAuthentication yes

    PermitEmptyPasswords no

    Описание остальных опций вы найдете в справочной системе, введя команду man sshd.

    8.3.Маршрутизация

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

    Примечание. IPChains — это средство фильтрации пакетов. Фильтр просматривает заголовок пакета и решает, что делать со всем пакетом. Например, можно указать фильтру, что определенные пакеты должны быть удалены, а некоторые перенаправлены, то есть обеспечить маршрутизацию.

    Пусть, у вас есть две сетевые платы eth0 и eth1:

    ifconfig eth0 192.168.1.1 up

    ifconfig eth0 192.168.2.1 up

    и вам нужно обеспечить маршрутизацию между подсетями 192.168.1.0 и 192.168.2.0. С этой целью объявляем, что машины, которые находятся в вашем локальном сегменте 192.168.1.*, «сидят» на первом интерфейсе и общаться с ними нужно напрямую:

    route add net 192.168.1.0 192.168.1.1 netmask 255.255.255.0 0

    А с машинами с адресами 192.168.2.* будем разговаривать через eth1:

    route add net 192.168.2.0 192.168.2.1 netmask 255.255.255.0 0

    Последний параметр — это метрика. Ее можно понимать как «расстояние до шлюза-назначения» или «сколько пересадок между шлюзами придется сделать пакету по пути и обратно». Т.к. адреса 192.168.1.1 и 192.168.2.1 являются нашими собственными адресами, то метрика равна 0.

    Сетевые пакеты для IP-адресов, которые не лежат в нашей локальной сети, будем отправлять на машину 192.168.1.11, а она сама будет разбираться, что с ними делать:

    route add default 192.168.1.11 1

    Другими словами, сейчас мы объявили маршрут по умолчанию. Обратите внимание на значение метрики = 1. Как видите, мы все сделали без всяких конфигураторов — все просто и логично.

    Сейчас постараемся, как говорится, рассмотреть второй вариант в трех строчках. Допустим, у вас есть те же две подсети — 192.169.1.0 и 192.168.2.0. Постараемся организовать маршрутизацию средствами IpChains:

    ipchains –P forward DENY

    ipchains –A forward –s 192.168.1.0/24 –d 192.168.2.0/24 –j ACCEPT

    ipchains –A forward –s 192.168.2.0/24 –d 192.168.1.0/24 –j ACCEPT

    О том, что означают данные три строчки, вы узнаете в гл. 14.

    8.4. Настройка DHCP (Dynamic Host Configuration Protocol)

    Для чего нужен протокол DHCP? DHCP — это протокол настройки узла, который автоматически назначает IP-адреса компьютерам. По сути, протокол DHCP — это дальнейшее развитие протокола ВООТР. Последний разрешает бездисковым клиентам запускать и автоматически конфигурировать протокол TCP/IP. Протокол DHCP централизовано назначает IP-адреса в вашей сети и автоматически конфигурирует рабочие станции. Возможно, вы подумали, что в одной сети должен быть только один сервер DHCP, потому что в противном случае между серверами возникнет конфликт, а пострадавшим опять окажется клиент, который зависнет при загрузке. А вот и не так — в одной сети может быть несколько серверов DHCP. И это не только не отразится на производительности сети, но даже повысит надежность сети, если, например, один из серверов выйдет из строя.

    Итак, установите пакет dhcp и включите поддержку динамических IP-адресов командой

    echo "1" > /proc/sys/net/ipv4/ip_dynaddr

    DHCP в Linux реализован в виде демона сервера (dhcpd) и демона клиента (dhcpcd). Демон сервера непосредственно отвечает за назначение IP-адресов клиентам, при входе и выходе их из сети. Клиентский демон, как явствует из названия, запускается на стороне клиента.

    Конфигурационным файлом для dhcpd является /etc/dhcp.conf. При запуске DHCP-сервера происходит выделение IP-адресов согласно содержащимся в файле /etc/dhcp.conf установкам. Выделенные адреса dhcpd регистрирует в файле dhcpd.leases, который обычно находится в каталоге /var/dhcpd.

    Сейчас давайте рассмотрим простейшую конфигурацию, которую будем постепенно наращивать (см. листинг 8.8). Обратите внимание на то что, чтобы внесенные вами в файл /etc/dhcp.conf изменения вступили в силу, демон dhcpd необходимо остановить и запустить снова. При этом используйте команду /etc/rc.d/init.d/dhcpd stop для останова демона, и команду /etc/rc.d/init.d/dhcpd start для его запуска.

    Листинг 8.8. Файл /etc/dhcpd.conf

    # описание сети, указывающее, какая из подсетей будет

    # обслуживаться. Указывается сетевой адрес и маска сети

    subnet 192.168.1.0 netmask 255.255.255.0 {

    # маршрутизатор по умолчанию

    option routers 192.168.1.1;

    # маска подсети 255.255.255.0

    option subnet-mask 255.255.255.0;

    # установка домена по умолчанию и сервера NIS, если таковой используется

    option nis-domain "domain.ua";

    option domain-name "domain.ua";

    # адрес DNS-сервера, который будут использовать клиенты

    option domain-name-servers 192.168.1.1;

    # диапазон адресов для клиентов

    # 192.168.1.50-192.168.1.250

    range 192.168.1.10 192.168.1.254;

    # сказать клиентам, чтобы отдали адрес через 21600 секунд (6 часов)

    # после получения адреса

    default-lease-time 21600;

    # забрать адрес самому через 28800 секунд (8 часов)

    max-lease-time 28800;

    }

    Теперь будем постепенно усложнять конфигурацию. Каждая сетевая карточка имеет уникальный собственный МАС-адрес. Допустим, вам нужно связать какой-то МАС-адрес с определенным IP-адресом. Для этого воспользуйтесь конструкцией host:

    host myhost {

    hardware ethernet xx:xx:xx:xx:xx:xx;

    fixed-address 192.168.1.9;

    }

    Ее нужно вставить в ту конструкцию подсети subnet, которой принадлежит назначаемый IP-адрес. Данная конструкция означает, что компьютеру с аппаратным адресом хх:хх:хх:хх:хх:хх будет назначен IP-адрес 192.168.1.9. Например:

    subnet 192.168.1.0 netmask 255.255.255.0 {

     # прочие опции

     # …

     #

     host myhost {

      hardware ethernet 00:40:C7:34:90:1E;

      fixed-address 192.168.1.9;

     }

    }

    Данный пример показывает, что аппаратному адресу 00:40:С7:34:90:1Е будет сопоставлен IP-адрес 192.168.1.9. Обратите внимание, что IP-адрес хоста myhost 192.168.1.9 относится к подсети 192.168.1.0 и включен в инструкцию subnet подсети 192.168.1.0, а не какой-либо другой сети!

    Существует довольно удобная утилита для просмотра всех МАС-адресов сетевых адаптеров в вашей сети — программа TCPNetView. Эта программа разработана Александром Горлачем и загрузить ее вы можете по адресу http://www.enet.ru/~gorlach/netview/. Правда, есть одно «но»: эта программа работает под Windows. В любом случае, если вы будете использовать эту программу, при настройке сервера вам не придется подходить к каждому компьютеру, чтобы узнать его МАС-адрес. Существуют также и утилиты под Linux, способные показать сразу все МАС-адреса. Примером может послужить программа Trafshow, которую вы найдете на прилагаемом компакт-диске. Но по сравнению с Trafshow, TCPNetView несколько удобнее (см. рис. 8.4). 

    Рис. 8.4. Программа TCPNetView


    Теперь, предположим, что вам необходимо обеспечить поддержку WINS, а на вашей машине установлен сервер Samba. В этом случае в конструкцию subnet нужно включить следующие директивы:

    option netbios-name-servers 192.168.1.1;

    option netbios-dd-server 192.168.1.1;

    option netbios-node-type 8;

    Примечание. Служба WINS (Windows Internet Name Service) используется для разрешения (перевода) имен NetBIOS в IP-адреса. Сервер WINS — это усовершенствованный сервер имен NetBIOS, разработан Microsoft для снижения широковещательного трафика. Пакет Samba предназначен для использования протокола SMB (Server Message Block), который также еще называется протоколом NetBIOS. С помощью пакета Samba ваша машина, работающая подуправлением Linux, ничем не будет отличаться от рабочей станции или сервера сети Microsoft.

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

    # определяем широковещательный адрес

    option broadcast-address 192.168.2.255;

    # включаем IP-Forwarding

    option ip-forwarding on;

    # можно добавить глобальную опцию:

    server-identifier server.domain.ua;

    Как обычно, дополнительную информацию можно получить, введя команду man dhcpd.conf. При настройке клиентов Windows следует активизировать режим «Получить IP-адрес автоматически» в свойствах TCP/IP (рис. 8.5). А при настройке Linux с помощью конфигуратора netconf — включить режим DHCP (см. рис. 8.6). 

    Рис.8.5. Настройка Windows-клиента

    Рис. 8.6. Настройка Linux-клиента


    Протокол DHCP подробно описан в RFC 1533, 1534, 1541, 1542, а протокол ВООТР описан в rfc 1532. Окончательный вариант конфигурационного файла приведен в листинге 8.9.

    Листинг 8.9. Конфигурационный файл /etc/dhcpd.conf (окончательный вариант)

    # Подсеть 192.168.1.0, маска сети 255.255.255.0

    subnet 192.168.1.0 netmask 255.255.255.0 {

    # маршрутизатор по умолчанию

    option routers 192.168.1.1;

    # маска подсети 255.255.255.0

    option subnet-mask 255.255.255.0;

    # установка домена по умолчанию и сервера NIS, если таковой используется

    option nis-domain "domain.ua";

    option domain-name "domain.ua";

    # задание широковещательного адреса

    option broadcast-address 192.168.2.255;

    # включение IP-Forwarding

    option ip-forwarding on;

    # глобальная опция server-identifier:

    server-identifier server.domain.ua;

    # адрес DNS-сервера, который будут использовать клиенты

    option domain-name-servers 192.168.1.1;

    # диапазон адресов для клиентов

    # 192.168.1.50-192.168.1.250 range

    192.168.1.10 192.168.1.254;

    # сказать клиентам, чтобы отдали адрес через 21600 секунд (6 часов)

    # после получения адреса

    default-lease-time 21600;

    # забрать адрес самому через 28800 секунд (8 часов)

    max-lease-time 28800;

    option netbios-name-servers 192.168.1.1;

    option netbios-dd-server 192.168.1.1;

    option netbios-node-type 8;

    # описание трех клиентов (dhcp50, dhcp51, dhcp52)

    # и их аппаратных адресов

     host dhcp50 {

      hardware ethernet 00:40:C7:34:90:1E;

    # обратите внимание на то, что вы должны использовать IP-адрес

    # из указанного ранее диапазона адресов 192.168.1.50-250.

      fixed-address 192.168.1.50;

     }

     host dhcp51 {

      hardware ethernet 00:40:C7:34:90:1F;

      fixed-address 192.168.1.51;

     }

     host dhcp52 {

      hardware ethernet 00:40:C7:34:90:2A;

      fixed-address 192.168.1.52;

     }

    }

    8.5. Подсчет трафика. Программа MRTG

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

    Самым простым способом является подсчет с помощью программы ifconfig. Чтобы понять как все работает, введите команду:

    cat /proc/net/dev

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

    Рис. 8.7. Команда cat /proc/net/dev


    Файл /proc/net/dev содержит информацию о работе сетевых устройств. На этом и основывается данный метод подсчета трафика. Для самого же подсчета удобнее использовать нижеприведенный сценарий stat:

    #!/bin/sh

    /bin/grep "$1" /proc/net/dev | /bin/awk –F ":" '{ print $2 }' | \

     /bin/awk '{ print "In: " $1 "\nOut: " $9 ; }'

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

    Скопируйте данный сценарий в каталог /usr/bin и сделайте его выполнимым:

    ср ./stat /usr/bin

    chmod 755 /bin/stat

    Использовать данный сценарий можно так:

    /bin/stat eth0

    где eth0 — это нужный вам интерфейс.

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

    Честно говоря, это самый простой способ и, скорее всего, для вас он окажется совершенно бесполезным. Я привел его лишь в демонстрационных целях — это как своеобразная программка "Hello, world!".

    Теперь перейдем к более традиционному методу. В данном методе для подсчета трафика используется IpChains. Чтобы глубже понимать, о чем пойдет речь, я рекомендую прочитать сначала гл. 14, а потом вернуться к этой главе. Думаю, читатель меня простит за это неудобство — так уж получилось. Впрочем, я постараюсь объяснить все как можно подробнее и в этом разделе, во всяком случае, все должно быть понятно, а за разъяснениями опций ipchains читатель может обратиться к гл. 14.

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

    ipchains –A output –d AAA.ААА.АAА.ААА –j ACCEPT

    Данное правило нужно установить для каждого адреса, учет которого вы хотите вести. А просмотреть статистику можно с помощью команды:

    ipchains –L –v

    Chain input (policy ACCEPT: 4195746 packets, 1765818402 bytes):

    Chain forward (policy ACCEPT: 142999 packets, 29941516 bytes) :

    Chain output (policy ACCEPT: 4182597 packets, 1309541595 bytes) :

    pkts bytes target prot opt tosa tosx ifname source   destination

    4    308   ACCEPT all      0xFF 0x00 any    anywhere AAA.AAA.AAA.AAA

    Как вы заметили, это не полный листинг. Я выбрал основное, пропустив поля mark, outsize и ports, которые не представляют для нас интереса.

    Здесь видно, что клиент ААА.ААА.ААА.ААА получил 308 байт или 4 пакета. В данном случае в качестве пакетов вступали пакеты протокола ICMP. Правило установлено таким образом, что учет ведется по всем интерфейсам (ifname=any), из любого источника, то есть адреса (source=anywhere) и учитываются все протоколы (prot=all). Аналогично можно установить правило для учета данных, полученных от клиента. Только в этом случае необходимо будет использовать цепочку input. Вам нужно установить это правило, потому что обычно считается не только исходящий, но и входящий трафик клиента, если ваш сервер, например, выступает в роли шлюза.

    Можно также использовать данные, взятые из аппаратного маршрутизатора Cisco. Кстати, через Cisco работает популярная программа tacacs+. Эта программа используется для учета времени работы пользователей в системе. И именно эта программа используется рядом провайдеров при организации dialin-доступа. Программа доступна по адресу ftp.vsu.ru/pub/hardware/cisco/tacacs/tac+ia-0.96pre9.3.tar.gz

    Очень полезна также программа useripacct. Она позволяет узнать о трафике каждого пользователя.

    Считать трафик можно также программой trafshow, которую вы найдете на прилагаемом компакт-диске. Эта программа считает только локальный трафик (сколько байтов принял и передал данный компьютер и от кого он принял и кому передал). Поэтому, установив ее на шлюзе, можно вполне контролировать трафик всей сети (см. рис. 8.8). Кроме того, немного изменив исходный код trafshow, можно заставить ее отображать не только IP-адреса или доменные имена компьютеров вашей сети, но и МАС-адреса. Исходный код этой программки вы также найдете на компакт-диске.

    Рис. 8.8. Программа trafshow


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

    К другим способам учета трафика можно отнести учет с использованием протокола SNMP. Именно по этому протоколу работает программа MRTG (http://www.switch.ch/misc/leinen/snmp/perl/). Программа MRTG предоставляет очень удобные средства для подсчета трафика: подсчет для всей сети и для отдельного узла, генерирование отчетов и диаграмм в формате HTML и многое другое.

    Программа MRTG (The Multi Router Traffic Grapher) предназначена для мониторинга загрузки канала за сутки, неделю, месяц и год. Программа MRTG умеет рисовать красивые картинки в формате PNG, которые отображают состояние канала за определенный период времени.

    Пример использования вы можете увидеть на сайте: http://www.stat.ee.ethz.ch/mrtg/

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

    Рис. 8.9. Конфигурация сети


    Из рисунка видно, что наша сеть получает доступ к Internet через SNMP-маршрутизатор. Компьютер MRTG — это узел локальной сети, на котором установлена программа MRTG. Программа MRTG будет периодически запускаться на узле MRTG, обновляя информацию о трафике. Пользователи локальной сети могут ознакомиться с этой информацией по протоколу HTTP. Естественно, на узле MRTG должен быть установлен Web-сервер.

    Перед установкой программы убедитесь в наличии следующих библиотек:

    1. gd (http://www.boutell.com/gd/);

    2. libpng (http://www.libpng.org/pub/png/);

    3. zlib (http://www.info-zip.org/pub/infozip/zlib/).

    Загрузить последнюю версию MRTG можно по адресу: http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/pub.

    Если вы используете операционную систему RedHat версии 7 или выше, программа MRTG, скорее всего, будет уже у вас установлена. Мы не будем скачивать исходные тексты программы, а сразу воспользуемся уже собранным пакетом rpm. Установим mrtg командой:

    rpm –ih mrtg*

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

    Программа MRTG состоит из трех частей:

    1. cfgmaker — утилита для создания конфигурационного файла.

    2. indexmaker — утилита для создания файла index.html — страницы краткого обзора, дающую вам общее представление о всех целях, которые вы контролируете. О целях мы поговорим немного позже.

    3. mrtg — сам mrtg.

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

    Введите команду:

    cfgmaker —global 'WorkDir: /var/www/html/mrtg' \

     -global 'Options[_]: bits,growright' \

     -output /var/www/html/mrtg/mrtg.cfg \

     community@router

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

    Параметр WorkDir задает рабочий каталог. В этот каталог будут помещены html-файлы и рисунки — отчеты о трафике. Каталог /var/www/html/, как вы уже успели заметить, является корневым каталогом нашего Web-сервера, поэтому для просмотра статистики нужно ввести следующий URL в окне браузера: http://host/mrtg/

    Кроме параметра WorkDir имеются также параметры HtmlDir и ImageDir.

    В эти каталоги будут помещены html-файлы и картинки. При определении этих параметров нужно учитывать, что параметр WorkDir имеет приоритет над параметрами HtmlDir и ImageDir и поэтому, если указан параметр WorkDir, mrtg поместит отчеты и картинки именно в этот каталог, а значения параметров HtmlDir и ImageDir будут проигнорированы.

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

    Параметр output программы cfgmaker задает имя конфигурационного файла, который будет создан.

    Примечание. Параметры WorkDir и Options являются параметрами программы mrtg, а параметры global и output — параметрами программы cfgmaker.

    Параметр community@router указывает имя сообщества SNMP-устрой-ства. В нашем случае — это наш SNMP-маршрутизатор. Обычно используется имя сообщества public. За более точной информацией обратитесь к администратору SNMP-маршрутизатора. Вместо имени узла в этом параметре можно указать IP-адрес, например, public@192.168.1.1.

    Параметр community@router как раз и является целью, которую мы будем контролировать.

    После выполнения этой команды будет сгенерирован такой файл mrtg.cfg:

    WorkDir: /var/www/html/mrtg

    Options[_]: bits,growright

    Target[r1]: community@router

    Имя цели (r1) пишется в квадратных скобках. Для разных целей можно задавать разные параметры, например:

    Target[r1]: 1:community@router

    Target[r2]: 2:community@router

    MaxBytes[r1]: 1250000

    MaxBytes[r2]: 2500000

    Title [r1]: Traffic Analysis for first interface

    PageTop[r1]: <H1>Stats for our interface #1</H1>

    Title[r2]: Traffic Analysis for second interface

    PageTop[r2] : <H1>Stats for our interface #2</H1>

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

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

    Числа 1 и 2 перед именем сообщества — это номера интерфейсов во внутренней таблице SNMP-устройства. После имени (или IP-адреса) SNMP-устройства можно указать порт SNMP. По умолчанию используется стандартный порт 161:

    community@router:161

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

    1. Количество принятых байтов.

    2. Количество отправленных байтов.

    3. Время работы объекта после включения.

    4. Имя объекта.

    Программу нужно записать в обратных кавычках, например:

    Target[r3]: `/usr/bin/program`

    Очень полезными параметрами являются Refresh и Interval. Первый определяет частоту обновления страниц с отчетами в браузере, а второй — предполагаемый интервал запуска программы MRTG. По умолчанию значения обоих параметров равно 300 секундам.

    Опции perminute и perhour позволяют измерять трафик в единицах за минуту и час соответственно. Опция noinfo подавляет вывод информации об устройстве и времени его работы. Пример:

    Options [_] : bits, perminute, noinfo

    Я думаю, что теории вполне достаточно, тем более, что вместе с MRTG поставляется отличная документация, которая доступна по адресу http:// localhost/mrtg/. Теперь перейдем к практической настройке. Скорее всего, у вас не будет SNMP-маршрутизатора, поскольку в небольших сетях маршрутизатором является сама Linux-машина, а выделение средств на приобретение аппаратного маршрутизатора в ближайшие несколько лет не предвидится. Да и намного интереснее считать трафик своего компьютера, а не какого-то маршрутизатора, которого вы даже и не видели и который установлен где-то на третьем этаже.

    Для работы MRTG необходимо установить и настроить сервер snmpd. Однако в большинстве случаев этого делать не нужно: корректная настройка данного сервера — это довольно нетривиальная задача, а лишняя «дыра» в системе безопасности нам не нужна. К тому же настройка сервера snmpd оправдывает себя, если вы хотите считать трафик этого компьютера не локальной программой mrtg, а удаленной, которая запущена на другом компьютере и получает данные от нашего сервера по протоколу SNMP.

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

    Строка 1

    Строка 2

    Строка 3

    Строка 4

    • Строка 1 — это входящие байты (принятые).

    • Строка 2 — исходящие байты (отправленные).

    • Строка 3 — время, на протяжении которого работает устройство.

    • Строка 4 — имя цели.

    Где же взять эту программу? Написать самому! Сейчас я подробно опишу, как это сделать. Настоятельно не рекомендую вам сразу взять и использовать готовый листинг: вы не поймете самого главного — как именно происходит подсчет трафика. В результате ваша система подсчета трафика будет работать в таком режиме: программа будет считать трафик, a MRTG — строить графики.

    Определим, откуда будем брать информацию о трафике. Операционная система Linux сама выполняет подсчет трафика. Вся информация, которая вам необходима, содержится в файле /proc/net/dev. Выполните команду:

    cat /proc/net/dev

    Результат выполнения этой команды вы уже видели в этой главе (рис. 8.7). Более новые ядра предоставляют больше информации о работе сетевых устройств, поэтому выполните данную команду для того, чтобы увидеть, какую информацию о сетевых устройствах предоставляет ваша система. Обычно первое информационное поле файла /proc/net/dev — это количество принятых байтов, а девятое — количество отправленных байтов.

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

    1:51pm up 2:10, 4 users, load average: 0.02, 0.04, 0.00

    Программа uptime, кроме всякой другой информации, возвращает время, на протяжении которого система работает, то есть с момента загрузки операционной системы. В вышеприведенном примере видно, что машина непрерывно работала 2 часа и 10 минут. 2 часа и 10 минут — это значение, которое разрабатываемая программа должна вывести в третьей строке. Вы можете смело использовать это время, потому что в основном интерфейсы сервера «подымаются» при загрузке системы и разница между uptime системы и uptime интерфейса составит всего несколько секунд.

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

    Создайте файл count (см. листинг 8.10) и поместите его в каталог /usr/bin (не забудьте сделать его исполнимым!).

    Листинг 8.10. Программа count

    #!/bin/bash

    /bin/grep "$1" /proc/net/dev | /bin/awk –F ":" '{ print $2 } ' | /bin/awk '{ print $1 "\n" $9 }'

    UPTIME=`/usr/bin/uptime | /bin/awk –F " " '{ print $3 }'`

    echo $UPTIME

    echo $1

    Использовать программу нужно так:

    count интерфейс

    Например, count eth0.

    Запустив программу, вы должны увидеть примерно следующие строки:

    2738410

    1235960

    2:57,

    eth0

    Во второй строке программы происходит следующее: находится нужная нам запись с именем интерфейса, который мы указали в первом параметре при вызове программы ($1). Затем интерпретатор awk выводит значения первого и девятого полей, содержащие количество принятых и переданных байтов. В третьей строке программы вычисляется время uptime. Последние две строки выводят время uptime и название интерфейса. Предположим, что у вас имеется два интерфейса: локальный eth0 и выделенная линия (ррр0), идущая к провайдеру. При этом конфигурация сети несколько упростилась (см. рис. 8.10). 

    Рис. 8.10. Конфигурация сети (2)


    Теперь узел MRTG сам является маршрутизатором и самостоятельно считает свой трафик. Файл конфигурации mrtg будет выглядеть так, как это показано в листинге 8.11.

    Листинг 8.11. Файл /var/WHW/html/mrtg/mrtg.cfg

    WorkDir: /var/www/html/mrtg/ipc

    Options[_]: bits,growright

    Target[eth0]: `/usr/bin/count eth0`

    Title [eth0] : Local Ethernet

    MaxBytes[eth0]: 99999999

    PageTop[eth0] : Status of /dev/eth0

    Target [ppp0] : `/usr/bin/count ррр0`

    Title [ppp0] : Leased line

    MaxBytes[ppp0]: 99999999

    PageTop[ppp0] : Status of /dev/ppp0

    Из листинга 8.11 видно, что у вас имеются две цели, для каждой из них заданы свои параметры. Нужно учитывать, что имя интерфейса, которое вы передаете программе count, должно совпадать с названием цели (eth0 и ррр0).

    В качестве рабочего каталога я использовал /var/www/html/mrtg/ipc. От использования каталога /var/www/html/mrtg/ я отказался, поскольку в нем находится документация по mrtg.

    Параметры MaxBytes, Title и PageTop являются обязательными. При их отсутствии mrtg попросит вас исправить ошибки в конфигурационном файле.

    Теперь можете запустить программу mrtg командой:

    mrtg /var/www/html/mrtg/mrtg.cfg

     В каталоге /var/www/html/mrtg/ipc должны появиться первые файлы-отчеты. Имя файла-отчета будет совпадать с именем цели. Первые два запуска mrtg будет «ругаться» на отсутствие предыдущих данных, но потом все будет работать как надо.

    Если третий запуск прошел гладко, то есть без сообщений об ошибках, можно добавить mrtg в расписание демона crond. Для этого добавьте в файл /etc/crontab одну из следующих строк (какая кому нравится):

    5,10,15,20,25,30,35,40,45,50,55,59 * * * * root /usr/bin/mrtg /var/www/html/mrtg/mrtg.cfg

    или

    0-59/5 * * * * root /usr/bin/mrtg /var/www/html/mrtg/mrtg.cfg

    После этого желательно перезапустить демон crond:

    /etc/init.d/crond restart

    Программу mrtg можно запускать в режиме демона (не через crond). Для этого установите значение параметра RunAsDaemon равное yes. За более подробной информацией обратитесь к документации по mrtg. 

    Рис. 8.11. Статистика для устройства ppp0


    Теперь самое время проверить, как работает mrtg. Запустите браузер и введите адрес http://localhost/mrtg/ipc/eth0.html. В результате вы должны увидеть информацию о загрузке канала. Первые графики вы увидите примерно через час после первого запуска mrtg, в зависимости от настроек периода запуска mrtg.

    8.6. Сетевая файловая система (NFS)

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

    После монтирования вы сможете непосредственно обращаться к файлам этой файловой системы. Сетевая файловая система чем-то напоминает службу «Доступ к файлам и принтерам» сети Microsoft. Для того, чтобы компьютер мог предоставлять свои ресурсы для сетевой файловой системы NFS, на нем должен быть установлен и настроен NFS-сервер. Для того, чтобы компьютер имел доступ к ресурсам сетевой файловой системы, на нем должен быть установлен и настроен NFS-клиент. И тот и другой можно установить на одном компьютере, если этот компьютер и предоставляет свои ресурсы системе NFS, и использует ресурсы NFS.

    Для использования NFS нужно убедиться, что у вас запущены сервисы netfs и nfslock, а в некоторых системах nfsd и mountd. Это можно сделать с помощью конфигуратора или просмотреть наличие соответствующих ссылок в каталоге /etc/init.d/rc.d.

    Возможно, у вас не установлена поддержка NFS. В этом случае, установите пакет nf s-utils-0.2.1-2mdk.i586.rpm на сервере, а пакет nfs-utils-0.2.1-2mdk.i586.rpm — на клиенте.

    8.6.1. Настройка сервера NFS

    Напомню, что если у вас не установлена поддержка NFS, то для сервера необходимо установить пакет nfs-utils-0.2.1-2mdk.i586.rpm.

    Для настройки сервера сетевой файловой системы NFS используется файл конфигурации /etc/exports. В нем указываются файловые системы, которые будут экспортированы для совместного использования (см. листинг 8.12). Обычно в качестве таковых используются файловые системы /home, /pub и некоторые другие.

    Листинг 8.12. Файл /etc/exports

    /pub(ro,insecure,all_squash)

    /home/den denhome.domain.com(rw)

    /mnt/cdrom(ro)

    /mnt/cdrom comp11.domain.com(noaccess)

    Давайте разберемся в данной конфигурации. К каталогу /pub имеют доступ в режиме «только чтение» все компьютеры сети. К каталогу /home/den доступ в режиме чтения и записи имеется только с компьютера denhome.domain.com. К каталогу /mnt/cdrom доступ в режиме «только чтение» имеют все компьютеры, кроме comp11.domain.com.

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

    Опции, задаваемые в файле /etc/exports Таблица 8.7

    Опция Описание
    secure Требует, чтобы запросы исходили из портов, принадлежащих только безопасному диапазону (с номерами < 1024). Данная опция включена по умолчанию
    insecure Отключает опцию secure
    ro  Доступ в режиме «только чтение»
    rw Доступ в режиме чтения и записи
    noaccess Запрещает доступ к конкретной ветви экспортируемого дерева каталогов
    link_absolute Оставляет все символические ссылки без изменений. Включена по умолчанию
    link_relative Конвертирует абсолютные ссылки в относительные
    squash_uidssquash_gids Указанные идентификаторы групп и пользователей будут конвертированы в анонимные
    all_squash Все идентификаторы групп и пользователей будут конвертированы в анонимные. По умолчанию так не делается
    no_all_squash Обратна опции all_squash. Активизирована по умолчанию
    root_squash Преобразует запросы от пользователя root (uid=0) в запросы от анонимного пользователя. Благодаря этой опции, пользователь root не сможет пользоваться своими правами (правами пользователя root) при доступе к файловой системе. Данная опция установлена по умолчанию
    no_root_squash Отменяет опцию root_squash и позволяет пользователю root пользоваться своими правами (правами пользователя root) при доступе к сетевой файловой системе из клиентской системы
    anonuid=UID anonguid=GID Задают идентификаторы анонимных пользователей

    8.6.2. Настройка клиента NFS

    В предыдущем разделе было рассмотрено, как настроить сетевую файловую систему NFS. Теперь давайте рассмотрим как можно подмонтировать имеющуюся сетевую файловую систему к какому-либо клиенту. Напоминаю, что если на предполагаемом NFS-клиенте не установлена поддержка NFS, то на нем необходимо установить пакет nfs-utils-0.2.1-2mdk.i586.rpm.

    Итак, вернемся к настройке NFS-клиента. Ниже приведен пример того, как можно подмонтировать к нему сетевую файловую систему. Монтирование осуществляется с помощью команды mount:

    mount –t nfs –o timeo=30 nfsserver.domain.com:/home/den /home/den/remote/

    Прежде всего, нужно указать тип файловой системы –t nfs. Параметр timeo задает время ожидания, равное 3 секундам. Интересующая нас файловая система находится на компьютере nfsserver.domain.com и смонтирована там как /home/den. Мы же подмонтируем ее к своему домашнему каталогу /home/den/remote/.

    При монтировании сетевых файловых систем доступны опции, указанные в табл. 8.8.

    Если на вашем компьютере запущен сервер DNS и сервер NFS, проследите за тем, чтобы сервер DNS запускался после запуска сервиса NFS. При соблюдении данного условия гарантируется корректная работа сервера NFS. Точно такое же замечание я сделал и в главе 10, посвященной DNS. Чтобы вы не подумали, что я повторяюсь, объясню: лучше дважды упомянуть, чем забыть или не обратить внимание.

    Опции команды mount для сетевых файловых систем Таблица 8.8

    Опция Описание
    bg В том случае, если первая попытка монтирования файловой системы NFS окажется неудачной, она будет автоматически повторяться в фоновом режиме
    fg В том случае, если первая попытка монтирования файловой системы NFS окажется неудачной, она будет автоматически повторяться в приоритетном режиме. Данная опция установлена по умолчанию
    soft Задержка при выполнении операции, связанной с файлом, расположенным в сетевой файловой системе NFS (возникает при сбое сервера или отключении сети), будет приводить к отправке приложению сообщения об ошибке ввода/вывода. И хотя некоторые приложения могут корректно обрабатывать такую ошибку, но большинство из них все-таки такой возможностью не обладают. Не рекомендуется использовать данную опцию, так как она может привести к появлению испорченных файлов и потере данных
    hard Задержка при выполнении операции, связанной с файлом, расположенном в сетевой файловой системе NFS, будет приводить к приостановке, а затем возобновлению процесса с прерванного места. Таким образом, будут предприниматься повторные попытки выполнения операции
    tcp Монтирует сетевую файловую систему с помощью протокола TCP, а не UDP
    rsize=1024 Задает размер информации, пересылаемый при чтении файлов за один раз. По умолчанию этот размер равен 1024 байт
    wsize=1024 Аналогично rsize, но для операции записи
    noexec Запрещает выполнение программ или сценариев в монтируемой файловой системе

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

    nfsserver.domain.com:/home/den /home/den/remote/ nfs bg,hard, rw 1 0

    8.7. Поисковый сервер ht:/Dig

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

    Сервер Dig предоставляет простые и сложные методы поиска информации. К сложным методам относятся логический (boolean method) и нечетко определенный метод поиска (fuzzy searching method). Нечетко определенный поиск включает в себя несколько алгоритмов: простой, зондирующий и поиск с использованием синонимов.

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

    Файл конфигурации htdig.conf сервера Dig находится в каталоге /etc/htdig. Директива database_dir определяет расположение базы данных сервера ht:/Dig.

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

    Директива start_url указывает начальные url-адреса поиска. Сервер dig будет производить индексирование, начиная с этих адресов. Вы можете указать несколько адресов.

    Директива Iimit_urls_to определяет, какие адреса будут ограничены во время создания индекса. Обычно здесь нужно указать те url-адреса, которые вы указали в директиве start_url.

    Директива exclude_urls определяет, какие адреса не будут индексированы. Обычно не требует индексирования каталог /cgi-bin/, содержащий сценарии.

    Директива bad_extensions запрещает индексирование файлов с указанным расширением.

    Другие директивы позволяют установить максимальный размер заголовка документа HTML (max_head_length), максимальный размер файла (max_doc_size) и установить алгоритм поиска (search_algoritm), а с помощью директивы allow_virtual_hosts можно указать серверу индексировать виртуальные хосты как отдельные компьютеры.

    В состав системы Dig входят пять программ: htdig, htmerge, htfuzzy, htnotify и htsearch. Поиск выполняет программа htsearch, программы htdig, htmerge, htfuzzy выполняют индексирование. Сначала программа htdig собирает информацию в локальной базе данных, а затем сопоставляет найденные Web-страницы с установленными вами критериями поиска. Программа htmerge использует информацию, предоставленную ей программой htdig, для создания поисковой базы данных. Программа htfuzzy создает индексы в базе данных, что позволяет использовать методы нечетко определенного поиска.

    Довольно часто пользователи используют Web-страницы, которые вызывают программу htsearch для организации поиска. При этом программе htsearch передаются некоторые параметры: параметр поиска, конфигурация программы (config), метод поиска (method) и вид критерия (sort). При работе с этой программой можно использовать методы передачи данных GET и POST.

    Для создания базы данных предназначен сценарий rundig.

    8.8. Прокси-сервер Socks5

    8.8.1.Установка и настройкасервера

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

    В большинстве случаев прокси-сервер Socks5 нужно использовать для того, чтобы обеспечить работу Socks-клиентов (обычно в этой роли выступает программа ICQ) через бастион. Довольно часто встречающаяся ситуация: программу ICQ запускает пользователь локальной сети, у которого нет реального Интернет-адреса и он подключается к Интернет через firewall.

    Для решения этой проблемы можно воспользоваться двумя методами: или использовать IP-маскарадинг, или же установить Socks5-сервер на шлюзе. Первый способ описан в гл. 14, а настройка второго рассматривается в этой главе. Существует также еще один метод, который заключается в использовании прокси-сервера SQUID. Для этого нужно добавить в список разрешенных портов порт 5190. Этот порт используется современными ICQ-клиентами:

    acl SSL_ports port 5190

    Однако, по сравнению со SQUID, прокси-сервер Socks5 представляет собой наиболее гибкое решение. Да и зачем устанавливать на шлюзе полнофункциональный прокси-сервер, если нужно только обеспечить работу ICQ для пользователей внутренней сети?

    Нужно отметить, что оба прокси-сервера (Socks5 и SQUID) могут быть установлены на одном сервере и одновременно функционировать, не мешая друг другу.

    Клиентами сервера socks5 являются популярные клиенты ICQ и licq, клиентская версия оболочки ssh, а также другие программы. Подробную информацию о сервере socks5 вы можете найти по адресу: http://www.socks.nec.com. Некоторые вопросы по настройке socks5 довольно хорошо рассмотрены в справочной системе. Прочитать стандартную документацию вы можете, введя команды:

    man socks5.conf

    man libsocks5.conf

    В этой главе будет рассмотрена только базовая настройка сервера socks5.

    Сначала нужно загрузить последнюю версию прокси-сервера (http://www.socks.nec.com/cgi-bin/download.pl) — на данный момент это v1.0 release 11. То есть вам нужно выкачать файл socks5-v1.0r11. Желательно также скачать socks5tools — в нем находится сценарий для обработки протоколов сервера. После распаковки выполните привычную последовательность команд:

    ./configure

    make

    make install

    При корректной сборке в каталоге /etc будет создан файл socks5.conf, в котором и содержатся все настройки сервера.

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

    Листинг 8.13. Файл /etc/socks5.conf

    set SOCKS5_NOREVERSEMAP

    set SOCKS5_NOSERVICENAME

    set SOCKS5_NOIDENT

    set SOCKS5_MAXCHILD 128

    set SOCKS5_TIMEOUT 10

    auth - – u

    permit u – – - - - -

    interface 192.168.0. – eth0

    В первой строке мы отменяем обратный резолвинг адресов, благодаря чему сервер будет работать заметно быстрее. Вторая строка означает, что мы будем протоколировать номера портов вместо имен сервисов. Теоретически это тоже должно повысить эффективность работы сервера. Параметр SOCKS5_NOIDENT запрещает рассылку клиентам ident-запросов. Четвертая строка устанавливает максимально допустимое число потомков сервера — не жадничайте. Пятая строка, как вы уже успели догадаться, устанавливает тайм-аут (10 секунд).

    Практически вся настройка сервера выполняется с помощью манипулирования командами auth и permit. Первая устанавливает тип аутентификации, а вторая — разрешает доступ определенным хостам/пользователям. Полный формат команды auth такой:

    auth исходный_хост исходный_порт метод_аутентификации

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

    Формат команды permit:

    permit аутентификация команда исх_хост хост_назнач исх_порт порт_назнач [список_польз]

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

    permit u cpubt 192.168.-.– [100,1000] user

    В данном случае мы разрешаем доступ пользователю user (с использованием пароля, конечно). Пользователь user имеет право использовать Connect, Ping, Udp, Bind и Traceroute (cpubt) с адресов 192.168.*.*. Диапазон входящих (первый «-») и входящих (второй «-») портов — 100…1000.

    Директива interface (листинг 8.13) разрешает все соединения от компьютеров с адресами 192.168.0.* (наша внутренняя сеть) ко всем портам интерфейса eth0. Кроме команды permit существует противоположная ей команда deny с аналогичными параметрами.

    Создайте файл /etc/socks5.passwd — в нем содержатся имена пользователей и их пароли. Например:

    petrov 123456

    ivanov paswd

    За этим все! Вы уже настроили ваш сервер. Осталось его запустить:

    # /usr/local/bin/socks5 –f –s

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

    Если сервер сконфигурирован правильно, вы должны увидеть примерно следующее:

    11410: Socks5 starting at Mon Mar 4 19:13:55 2002 in normal mode

    После удачного запуска остановите сервер и добавьте его в скрипты автозагрузки системы:

    # killall socks5

    8.8.2. Альтернативные серверы Socks5

    В качестве альтернативы серверу socks5 вы можете использовать прокси-сервер dante-socks, который доступен по адресу http://www.inet.no/dante/. Данный сервер использует файл конфигурации sockd.conf (см. листинг 8.14).

    Листинг 8.14. Файл /etc/sockd.conf

    internal: 192.168.0.1 port = 1080

    external: 111.111.111.111

    client pass {

     from: 192.168.0.0/16 to: 0.0.0.0/0

    }

    pass {

     from: 0.0.0.0/0 to: 192.168.0.0/16

     command: bindreply udpreply

     log: connect error

    }

    Параметр internal определяет ваш внутренний интерфейс (точнее, внутренний IP-адрес), a external — ваш настоящий IP (111.111.111.111.111). В блоке client pass указываются возможные клиенты вашего сервера (сеть 192.168.0.0), а в блоке pass указываются имена узлов, которые могут «общаться» с вашими клиентами. В приведенном примере разрешается отвечать клиентам со всех узлов (0.0.0.0). Протоколироваться будут только ошибки соединения.

    8.8.3. Настройка клиента Socks5 (licq)

    Настройку клиентов будем рассматривать на примере двух, наверное самых популярных, Socks-клиентов. Сначала рассмотрим настройку программы ICQ для Windows, а потом licq — ICQ-клиент для Linux.

    Запустите программу ICQ и нажмите на кнопку «ICQ», которая находится ниже кнопки «Services» (рис. 8.12). Затем из появившегося меню выберите команду Preferences и перейдите в раздел Connections на вкладку Server. Включите режим использования прокси-сервера и установите тип прокси-сервера — Socks5 (см. рис. 8.13).

    Рис. 8.12. Программа icq

    Рис. 8.13. Свойства соединения icq


    Потом перейдите на вкладку Firewall и установите параметры прокси-сервера: имя, порт, тип (socks5), имя пользователя и пароль (см. рис. 8.14). Нажмите на кнопку «Apply» и на этом настройка клиента ICQ для Windows завершена. 

    Рис. 8.14. Параметры прокси-сервера


    С программой licq будет немножко сложнее. Во-первых, нужно установить программу runsocks, которая входит в состав прокси-сервера (эту программу можно также найти в Интернет отдельно), на компьютере пользователя и перекомпилировать licq, включив поддержку socks5. Для этого перейдите в каталог, содержащий исходные тексты licq и запустите скрипт configure с параметром –enable-socks5:

    ./configure –enable-socks5

    После этого выполните привычные команды:

    make; make install

    Теперь нужно создать файл /etc/libsocks5.conf и добавить в него строку:

    socks5 – – – 192 .168.0.1:port

    192.168.0.1 — это адрес вашего socks5-сервера, port — порт, необходимый клиенту (обычно 1080).

    8.9. Система обнаружения и защиты от вторжения

    8.9.1. Что такое LIDS?

    LIDS (Linux Intrusion Detection System) — система обнаружения вторжения. Данная система представляет собой патч к ядру, который позволяет обнаружить и защитить вашу систему от вторжения.

    Система LIDS была создана китайским и французским разработчиками Xie Huagang и Philippe Biondi и доступна на сайте http://www.Iids.org. На этом сайте доступна как сама система LIDS, так и документация к ней. Однако разработчики системы не спешат обновлять документацию к новым версиям системы. А документация по версии 0.8.x ничем вам не поможет, если вы используете версию 0.9.x. Поэтому в этой главе я не буду рассматривать одну определенную версию, так как при выходе следующей версии этот материал безнадежно устареет, а рассмотрю общую настройку LIDS — все написанное в этой главе должно работать у вас вне зависимости от версии LIDS.

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

    Основным преимуществом системы LIDS является то, что ее нельзя отключить обычными способами.

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

    Примечание. Значение слова «хакер» значительно объемнее, чем просто «вандал», пытающийся разрушить вашу систему. Подробнее вы можете прочитать об этом в документе Hacker-HOWTO, который вы найдете на прилагаемом к книге CD.

    Во-вторых, чтобы снять защиту с определенного объекта, например, файла /etc/passwd, нужно знать пароль администратора LIDS, а не пользователя root. Этот пароль хранится в зашифрованном виде в специальном файле. А этот файл, в свою очередь, «виден» только программе LIDS, вы его не увидите, даже если введете команду Is –l. Таким образом можно защитить не только файл паролей LIDS, но и файл /etc/passwd, предварительно разрешив доступ к нему только программам login, su и passwd, то есть тем программам, которым действительно этот файл нужен. Ограничить доступ можно по-разному, например, разрешив одной программе только читать файл, а другой — записывать в него.

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

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

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

    8.9.2. Установка LIDS

    Для работы LIDS необходимо ядро версии 2.2.13 или выше. Загрузить версию LIDS для вашего ядра можно по адресу http://www.lids.org/download.

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

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

    Итак, если вы решили установить LIDS, приступим к ее установке. Для начала убедитесь, что у вас есть копия исходных текстов ядра (например, в виде rpm-пакетов). Если ее нет, скопируйте исходные тексты ядра в другой каталог — на всякий случай. Это правило относится не только к LIDS, а и ко всем программам, которые добавляют патчи или сами являются патчами к ядру Linux. Распакуйте LIDS:

    tar xfz LIDS-x.x.x-k.k.k.tar.gz

    В номере версии LIDS я заменил номера версии буквами х, а номера версии ядра — буквами k. Теперь перейдите в каталог /usr/src и введите команду:

    patch –p1 /usr/src/LIDS-x.x.x/LIDS-x.x.x-k. k. k.patch

    Этой командой вы добавите патч LIDS к вашему ядру (LIDS я распаковал в каталог/usr/src). Затем нужно установить программу администрирования системы LIDS, а потом пересобрать ядро с поддержкой LIDS. С этой целью перейдите в каталог/usr/src/LlDS-x.x.x/lidsadm-x.x.x и введите команды:

    make

    make install

    Если в процессе выполнения команды make install вы увидите сообщение, что не найден файл lidsadm.1.gz (такое наблюдалось в версии LIDS 0.9.8), просто введите команду:

    gzip lidsadm.1

    А затем снова — make install.

    Теперь займемся конфигурированием ядра. Перейдите в каталог с исходными текстами ядра и запустите программу menuconfig (команда make menuconfig). Вам нужно включить следующие опции:

    1. Prompt for development and/or incomplete code/drivers (Code maturity level options).

    2. Sysctl support (General Setup).

    3. Linux Intrusion Detection System support (EXPERIMENTAL) (General Setup).

    При включении поддержки LIDS вы увидите список опций LIDS (табл. 8.9).

    Опции LIDS Таблица 8.9

    Опция Описание
    Maximum protected objects to manage Максимальное количество защищаемых объектов. По умолчанию 1024. Пока не следует изменять данное значение
    Maximum ACL subjects to manage Максимальное количество субъектов правил. О субъектах и о правилах мы поговорим в следующем пункте, а пока оставьте данное значение без изменения (1024)
    Maximum ACL objects to manage Максимальное количество объектов правил
    Maximum protected proceeds Максимальное количество защищаемых процессов. По умолчанию 1024. Устанавливая максимальные значения, следует учитывать, что чем больше максимальное значение, тем больше код ядра
    Hang up console when raising security alert Отключает консоль злоумышленника при попытке доступа к защищенному объекту. Рекомендую включить данную опцию
    Security alert when excepting unprotected programs before sealing LIDS Включает вывод сообщения о нарушении безопасности при запуске незащищенных программ. Включите данную опцию — это позволит вам обнаружить незащищенные программы
    Do not execute unprotected programs before sealing LIDS Включает или отключает запуск незащищенных программ. Не включайте эту опцию до тех пор, пока не убедитесь, что все программы, которые запускаются автоматически при запуске системы, не защищены. На данном этапе пока лучше оставить эту опцию выключенной
    Try not to flood logs Система LIDS не будет записывать в протоколах повторяющиеся сообщения об одном и том же нарушении. Не включайте эту опцию
    Allow switching LIDS protections Включает или выключает защиту LIDS, то есть это возможность включения или выключения LIDS в процессе работы системы после ввода пароля администратора LIDS. Включите эту опцию. При включении этой опции вы увидите список подобных опций, например, опция Allow remote users to switch LIDS protections, разрешающая включать или выключать защиту LIDS удаленным пользователям. Не включайте эти опции! (особенно опцию allow any program to switch LIDS protections)
    Port Scanner Detector in kernel Эта опция добавляет мощный сканер портов в ядро, определяющий практически все известные способы сканирования портов. Несмотря на увеличение размера ядра, включите эту опцию
    Send security alerts through network Если эта опция включена, то при обнаружении нарушения на указанный адрес электронной почты будет отправлено сообщение об этом. Можно использовать как локальный, так и удаленный сервер SMTP. Включите данную опцию
    LIDS debug (не во всех версиях LIDS) Включает вывод отладочных сообщений. Включите эту опцию, если вы хотите самостоятельно переписать исходные тексты системы LIDS

    Теперь убедитесь, что вы находитесь в каталоге /usr/src/linux и введите команды:

    make clean

    make dep

    make install

    make modules

    make modules_install

    Примечание. Вместо пяти вышеуказанных команд можно ввести одну команду:

    make clean dep install modules modules_install

    Параметры (clean, dep…) — это просто цели для сборки. Каждая цель определяет какие-нибудь действия, например, modules собирает модули, a modules_install — устанавливает модули ядра.

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

    8.9.3. Базовая настройка

    После установки системы LIDS в каталоге /etc у вас появится подкаталог /lids. В нем вы обнаружите четыре файла: lids.cap, lids.net, lids.pw, lids.conf.

    В первом из них хранятся текущие установки способностей (cap — от capabilities— способности). О том, что такое способности, мы поговорим немного позже.

    Во втором файле (lids.net) находятся установки для отправки сообщений электронной почты. В третьем (lids.pw) — пароль в зашифрованном виде. Система LIDS использует метод шифрования RipeMD-160. Пароль можно изменить только с помощью программы lidsadm. В последнем файле определяются правила доступа. Этот файл можно изменять только с помощью программы lidsadm.

    Способность — это возможность программы совершать какое-либо действие. В табл. 8.10 каждая из способностей рассмотрена более подробно. Формат способностей, в котором они содержатся в файле lids.cap, выглядит так:

    [+/-]номер:название

    Если в первом поле установлен знак «+», значит эта способность включена. Номер — это просто порядковый номер способности. Название определяет действие, разрешенное или запрещенное программам. Выключение способности распространяется на все программы, кроме тех, которые непосредственно указаны в правилах доступа с помощью программы lidsadm. Если способность включена, ее ограничение распространяется на все без исключения программы. Нельзя установить ограничение на все программы, кроме нескольких. Пример файла lids.сaр приведен в листинге 8.15.

    Листинг 8.15. Пример файла lids.cap

    +0:CAP_CHOWN

    +1:CAP_DAC_OVERRIDE

    +2:CAP_DAC_READ_SEARCH

    +3:CAP_FOWNER

    +4:CAP_FSETID

    +5:CAP_KILL

    +6:CAP_SETGID

    +7:CAP_SETUID

    +8:CAP_SETPCAP

    -9:CAP_LINUX_IMMUTABLE

    -10:CAP_NET_BIND_SERVICE

    +11:CAP_NET_BROADCAST

    -12:CAP_NET_ADMIN

    -13:CAP_NET_RAW

    +14:CAP_IPC_LOCK

    +15:СAP_IPC_OWNER

    -16:CAP_SYS_MODULE

    -17:CAP_SYS_RAWIO

    -18:CAP_SYS_CHROOT

    +19:CAP_SYS_PTRACE

    +20:CAP_SYS_PACCT

    -21:CAP_SYS_ADMIN

    +22:CAP_SYS_BOOT

    +23:CAP_SYS_NICE

    +24:CAP_SYS_RESOURCE

    +25:CAP_SYS_TIME

    +26:CAP_SYS_TTY_CONFIG

    +27:CAP_HIDDEN

    +28:CAP_INIT_KILL

    Способности Таблица 8.10 

    Способность Описание
    CAP_CHOWN Разрешает (или запрещает, если способность выключена) программам изменять группу и владельца файла. Далее подразумевается, что рассматриваемая способность включена и если ее отключить, то данное действие будет недоступно программам
    CAP_DAC_OVERRIDE Программы, запускаемые пользователем root, не будут принимать во внимание права доступа к файлам. Например, если режим доступа к файлу пользователя равен 0600, то даже root не сможет открыть его (получить доступ к файлу)
    CAP_DAC_READ_SEARCH То же самое, но для каталогов (режимы доступа: чтение и поиск)
    CAP_FOWNER Запрещает операции с файлами, если идентификатор владельца файла не совпадает с идентификатором пользователя, который выполняет операцию
    CAP_FSETID Разрешает установку битов SUID и SGID для файлов, не принадлежащих пользователю root
    CAP_KILL Разрешает процессам пользователя root завершать («убивать») процессы других пользователей
    CAP_SETGID Разрешает программам изменять группу, под которой они работают. Программа должна быть запущена пользователем root. Эту возможность используют программы: httpd, sendmail, safe_mysql, safe_finger, postfix, ftpd
    CAP_SETUID Разрешает программам изменять пользователя, под которым они работают. Программа должна быть запущена пользователем root
    CAP_SETPCAP Включает способность программ редактировать способности
    CAP_LINUX_IMMUTABLE Отключите данную способность. Эта способность относится к таким атрибутам файлов, как S_IMMUTABLE (команда chattr –i) и S_APPEND (chattr –a)
    CAP_NET_BIND_SERVICE Разрешает программам прослушивать порты с номерами, меньшими 1024
    CAP_NET_BROADCAST Разрешает программам отправлять широковещательные пакеты
    CAP_NET_ADMIN Эта способность относится к сетевому администрированию: конфигурирование сетевых интерфейсов, изменение таблиц маршрутизации ядра, правил firewall и т.п.
    CAP_NET_RAW Разрешает программам использовать сокет-соединения (Raw Unix Socket)
    CAP_IPC_LOCK Разрешает процессам пользователя root блокировать сегменты разделяемой памяти
    CAP_IPC_OWNER Разрешает процессам пользователя root вмешиваться в межпроцессорное взаимодействие процессов других пользователей
    CAP_SYS_MODULE Управляет способностью загружать (выгружать) модули ядра. Отключите данную способность
    CAP_SYS_RAWIO Управление доступом к файлам устройств, например, /dev/mem, /dev/hd*, /dev/sd*. Другими словами, разрешает прямой ввод/вывод
    CAP_SYS_CHROOT Разрешает изменять корневой каталог в процессе работы пользователя. Отключите данную способность
    CAP_SYS_PTRACE Разрешает программа использовать функцию ptrace(). Включите данную способность
    CAP_SYS_PACCT Управляет способностью конфигурировать учет процессов. Отключите данную способность
    CAP_SYS_ADMIN Управляет способностью изменения многих системных параметров: от установления имени компьютера до монтирования дисков. Отключите данную способность, иначе ничего не сможете сделать в системе
    CAP_SYS_BOOT Управляет способностью перезагружать машину
    CAP_SYS_NICE Управляет способностью изменять приоритет процессов других пользователей
    CAP_SYS_RESOURCE Данная способность относится ко всевозможным ограничениям системных ресурсов, например, дисковые квоты, количество консолей. Выключите данную способность
    CAP_SYS_TIME Разрешает изменять системное время
    CAP_SYS_TTY_CONFIG Разрешает изменять настройки консолей
    CAP HIDDEN Разрешает программам становиться невидимыми в списке процессов
    CAP_INIT_KILL Разрешает «убивать» потомков процесса init. К потомкам относятся практически все демоны, запущенные при запуске системы

     Для инициализации способностей используются команды lidsadm –I. Эту команду обычно помещают в сценарии автозагрузки системы, например, rc.lосаl, и, как правило, эта команда должна быть последней, чтобы могли беспрепятственно загрузиться демоны и инициализироваться сетевые интерфейсы.

    Теперь перейдем к настройке параметров отправления сообщений электронной почты. Эти параметры, как уже было отмечено, находятся в файле lids.net (см. листинг 8.16).

    Листинг 8.16. Файл lids.net

    MAIL_SWITCH=1

    MAIL_RELAY=127.0.0.1:25

    MAIL_SOURCE=localhost

    MAIL_FROM=LIDS@domain.ru

    MAIL_TO=admin@adminhome.ru

    MAIL_SUBJECT=The intrusion is revealed

    Первый параметр включает (1) или отключает (0) функцию отправки сообщения. Параметр MAIL_RELAY определяет IP-адрес сервера SMTP и порт сервиса SMTP. MAIL_SOURCE — это источник почты, то есть узел, отправивший сообщение. Параметр MAIL_FROM устанавливает адрес отправителя, а MAIL_TO — адрес получателя. MAIL_SUBJECT — это тема сообщения.

    В качестве адреса получателя рекомендую установить номер мобильного телефона, точнее e-mail-адрес, который сопоставлен с вашим номером телефона. Этот адрес можно узнать у вашего оператора мобильной связи. В этом случае сообщение о вторжении будет отправлено по SMS прямо на мобильный телефон, что очень удобно — не будете же вы всегда находиться возле компьютера, ожидая сообщения от LIDS?

    Следующий этап настройки системы LIDS — это изменение пароля администратора системы LIDS. Для изменения пароля (точнее, установки нового пароля), введите команду:

    lidsadm –P

    8.9.4. Правила доступа

    Правила доступа системы LIDS чем-то напоминают правила бастиона, но данные правила распространяются не на пакеты, а на программы. Правила доступа хранятся в файле lids.conf и редактировать этот файл можно только с помощью программы lidsadm. Первоначально у вас уже установлены определенные правила, просмотреть которые вы можете с помощью команды:

    lidsadm –L

    Обновить правила вы можете с помощью команды:

    lidsadm –U

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

    lidsadm –Z

    Правила состоят из трех частей:

    1. Объекта.

    2. Субъекта.

    3. Доступа (цели).

    Объект — это любой объект (файл, каталог), который будет защищен с помощью системы LIDS или на который будет действовать ограничение доступа. Если защитить каталог, то будут защищены все файлы в этом каталоге, все подкаталоги, все файлы в подкаталогах и т.д.

    Субъектом является защищенная программа, которой предоставляется доступ к защищенному объекту. Субъект также должен быть защищен с помощью LIDS.

    Параметр доступ (цель) устанавливает тип доступа к объекту:

    READ — чтение.

    WRITE — запись.

    DENY — запрещает любой доступ.

    APPEND — разрешает запись в конец файла.

    IGNORE — игнорирование защиты.

    Устанавливается правило так:

    lidsadm –А –о объект –s субъект –j доступ

    Если параметр «субъект» не указан, то правило будет действовать для всех программ.

    Для начала защитим нашу систему от самого известного «троянского коня» — rootkit. О том, что такое rootkit и какой вред он может причинить вашей системе вы можете прочитать в статье Инги Захаровой «Сканирование на предмет обнаружения rootkit'oB» http://www.softerra.ru/review/security/16999/page1.html.

    Пакет rootkit заменяет стандартные утилиты администрирования их «поддельными» версиями, что позволяет скрыть следы атаки и несанкционированного доступа.

    Для защиты от такого рода «троянов» создайте такие правила:

    lidsadm –А –о /bin –j READ

    lidsadm –A –o /sbin –j READ

    lidsadm –A –o /etc –j READ

    lidsadm –A –o /usr/bin –j READ

    lidsadm –A –o /usr/sbin –j READ

    lidsadm –A –o /lib –j READ

    lidsadm –A –o /boot –j READ

    Как видите, мы не определили субъект в наших правилах, поэтому установленные ограничения будут распространяться на все программы: мы разрешаем доступ «только чтение» всем программам, но запрещаем запись в указанные каталоги.

    Как я уже отмечал, при установке правил нужно учитывать особенности установленных в вашей системе программ. Если оставить все как есть, некоторые программы не смогут работать. Например, программа mount пишет в файл /etc/mtab при монтировании новой файловой системы. Установите такие дополнительные правила, разрешив некоторым субъектам доступ WRITE к некоторым файлам:

    lidsadm –А –о /etc –s /bin/mount –j WRITE

    lidsadm –A –s –o /etc /bin/umount –j WRITE

    lidsadm –A –s –o /lib/modules/2.2.17-21mdk /sbin/depmod –j WRITE

    lidsadm –A –s –o /etc/mtab /sbin/fsck.ext2 –j WRITE

    lidsadm –A –s –o /etc /etc/rc.d/rc.local –j WRITE

    lidsadm –A –s –o /etc/HOSTNAME /etc/rc.d/rc.sysinit –j WRITE

    lidsadm –A –s –o /etc/mtab /etc/rc.d/rc.sysinit –j WRITE

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

    lidsadm –A –o /etc/shadow –j DENY

    lidsadm –A - o /etc/shadow –s /bin/login –j READ

    lidsadm –A /etc/shadow –s /bin/su –o –j READ

    lidsadm –A –o /etc/shadow –s /usr/sbin/in.ftpd –j READ

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

    Полезно также защитить системные журналы от изменений. Для этого нужно защитить каталог /var/log, установив доступ READ для всех программ, а затем отдельно разрешив каждой программе писать только в свой протокол. Это довольно утомительный процесс, но один раз проделав его, вы будете уверены, что никто уже не сможет изменить протоколы, чтобы «замести следы». При использовании программы logrotate предоставьте ей доступ ко всему каталогу /var/log.

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

    INHERIT —  предоставлять потомкам процесса данную возможность.

    NO_INHERIT — не предоставлять.

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

    lidsadm –A –s СУБЪЕКТ –t –о СПОСОБНОСТЬ –j ДОСТУП (ЦЕЛЬ)

    Вся разница между указанием обыкновенного объекта и способности заключается в наличии параметра –t.

    После настройки LIDS перезагрузите систему для проверки ее работоспособности. Если что-то пошло не так, загрузите Linux, передав ядру параметр security=0. Указание данного параметра отключит систему LIDS и вы сможете настроить ее заново:

    lilo boot: linux security=0

    8.9.5. Администрирование LIDS

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

    Администрирование системы LIDS выполняется с помощью все той же программы — lidsadm. Каждый раз при выполнении программы lidsadm у вас будет запрошен пароль. Каждая попытка запуска lidsadm будет фиксироваться в протоколах, так же как и каждая попытка ввода неправильного пароля. В зависимости от настроек вашей системы на указанный вами e-mail будут посылаться сообщения при каждой попытке подобрать пароль администратора LIDS. Формат использования lidsadm в данном контексте таков: lidsadm –S - +/-флаг

    При администрировании доступны флаги, указанные в табл. 8.11.

    Флаги администрирования LIDS Таблица 8.11 

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

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

    lidsadm –S - –LIDS

    vi /etc/lids/lids.cap

    lidsadm –S – +RELOAD_CONF

    lidsadm –S – +LTDS

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

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

    lidsadm –S – –CAP_SYS_MODULE

    insmod module.о

    lidsadm –S – +CAP SYS MODULE 








    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх