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

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

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

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

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.

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

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

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

http:ALL

ftp:ALL

ALL:server.dhsilabs.com

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

Думаю, что основной момент настройки понятен, и теперь переходим к протоколу 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.

Суперсервер 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

Внимание! При включении 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).

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

service < service_name>

{

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

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

 …

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

}

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

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

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

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

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

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

Примечание. 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.7 вы найдете пример файла /etc/xinetd.conf. Сейчас же займемся запуском только что откомпилированного и настроенного суперсервера. А запускать его можно с параметрами, указанными в табл. 8.3.

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

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

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

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

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

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.

Сервис 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.

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 

Оболочка 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.

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

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

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

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

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

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

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

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

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

# $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.

Маршрутизацию между сетями можно организовать с помощью команды 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.

Для чего нужен протокол 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 для его запуска.

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

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

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.

# Подсеть 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;

 }

}

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

Самым простым способом является подсчет с помощью программы 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 (не забудьте сделать его исполнимым!).

#!/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.

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.

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

После монтирования вы сможете непосредственно обращаться к файлам этой файловой системы. Сетевая файловая система чем-то напоминает службу «Доступ к файлам и принтерам» сети 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 — на клиенте.

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

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

/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

В предыдущем разделе было рассмотрено, как настроить сетевую файловую систему 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

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

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

Сервер 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.

Сервер 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), а потом разберемся, что все это означает.

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

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

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). Протоколироваться будут только ошибки соединения.

Настройку клиентов будем рассматривать на примере двух, наверное самых популярных, 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).

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 объектам будет сообщено по электронной почте администратору, что позволит ему незамедлительно отреагировать на попытку взлома.

Для работы 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

Теперь убедитесь, что вы находитесь в каталоге /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 будьте предельно внимательны, иначе последствия могут быть катастрофическими, особенно, если у вас нет загрузочной дискеты.

После установки системы 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.

+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 

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

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

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

Правила доступа системы 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

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

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

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

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

Приведу несколько примеров по администрированию 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