047 Системный Администратор 10 2006

Роспечать – 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

№10

(47)

окт

ябрь

200

6

№10(47) октябрь 2006подписной индекс 20780www.samag.ru

Как обеспечить необходимое быстродействие систем «1С: Предприятие»

Microsoft Operations Manager:управляем сетью

Linux-VServer: настраиваем виртуальные серверы

Создаем адресную книгу на базе OpenLDAP

Как настроить библиотеку SASL для совместной работы c Kerberos

Растущая угроза: руткиты Win32

Как зарабатывают на Open Source

Головоломка, ведущая по жизни Игоря Данилова

1№10, октябрь 2006

в номере

ТЕНДЕНЦИИ3

РЕПОРТАЖ

Осенний марафон выставок начался4Алексей Коршунов[email protected]

Softool стал самой успешной IT-выставкой этого года

6

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

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


8

Роман Марков[email protected]

Разберемся в сути проблемы и проанализируем вари-анты решения.

Microsoft Operations Manager 2005:управляем сетью

12

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

Мониторинг и управление серверами и приложениями требует больших затрат времени и ресурсов. Часть этих проблем решает MOM 2005.

Экономьте время на администрировании Active Directory

18

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

Обзор возможностей утилиты Active Administrator.

Как собирать сетевую статистику22

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

Сведения о сети позволят оценить ее состояние, за-планировать модификацию и вовремя заметить воз-никновение проблем.

Создаем адресную книгу на базе OpenLDAP28

Сергей Алаев[email protected]

Настраиваем OpenLDAP в качестве адресной книги с хранением данных в PostgreSQL.

Linux-VServer32

Дмитрий Столяров[email protected]

Настраиваем виртуальные серверы.


38

Михаил Кондрин[email protected]

С помощью библиотеки SASL сетевые приложения мо-гут автоматически договориться об использовании оп-ределенного механизма подтверждения идентичности пользователя. Как осуществить взаимодействие биб-лиотеки SASL c Kerberos?

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

Защищаем корпоративную почту с SecExMail Gate

43


Обзор инструмента SecExMail Gate, который позволит обеспечить конфиденциальность корпоративной поч-ты, передаваемой по незащищенным сетям.


Артем Баранов[email protected]

Схемы работы руткитов.

Защитить ваш компьютер поможет Browser Sentinel

50


Обзор возможностей утилиты.


52

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

Виртуальное путешествие по Петербургу и биографии легендарного создателя антивируса Dr.Web.

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

IMHO

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

56

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

Куда приведет Open Source?63

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

Сегодня всё большее число компаний связывает с от-крытыми проектами свой бизнес. Что ждёт эти проек-ты в перспективе?

Open Source взглядом оптимистаЯвление Open Source пока не получило объяснения своего возникновения и развития, но уже породило спекуляции на этот счет.

68

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

Python – в школу!74

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

Что должно быть на уроках информатики?

ОБРАЗОВАНИЕ

Полезные советы: Python77Сергей Супрунов[email protected]

ПРОГРАММИРОВАНИЕ

Многоядерные процессоры……и проблемы, ими порождаемые, в ОС семейства NT.

78

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

Суровая правда, скрытая за «розовыми очками». Часть 2

86

Дмитрий Мороз [email protected]

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

История компании Transmeta.

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

17, 27, 49, 73, 91 BUGTRAQ

3№10, октябрь 2006

тенденции

Проект FreeDOS достиг релиза 1.0Проект по созданию совместимой с DOS свободной ОС, представил первый финальный стабильный релиз. Система разрабатывалась с 1994 года и вобрала в себя такие воз-можности, как мультизагрузка с Windows 95-2003/NT/XP/ME, поддержка файловой системы FAT32 и больших дисков (LBA), поддержка LFN, дисковый кэш. В систему входит ПО для управления памятью, замена SHSUCDX и драйвер для CD-ROM, драйвер для мыши с колесом прокрутки, FDAPM для управления питанием ПК, драйвер UDMA (до 4 дис-ков). Из пользовательского программного обеспечения в FreeDOS 1.0 можно отметить мультимедийный проигры-ватель MPXPLAY (для mp3, ogg, wmv и других форматов), архиваторы (7ZIP, INFO-ZIP zip & unzip), многооконные тек-стовые редактор и просмотрщик файлов помощи. Распро-страняется FreeDOS под свободной лицензией GNU GPL. Все подробности о проекте доступны на www.freedos.org.

Novell готовит ОС реального времениКомпания Novell планирует в октябре начать продажи но-вого продукта из линейки своих корпоративных GNU/Linux-дистрибутивов – Suse Linux Enterprise Real-Time (SLERT). Это операционная система реального времени, способ-ная реагировать на какие-либо срочные события в очень короткие временные интервалы, что актуально далеко не для всех, однако может пригодиться компаниям, нуждаю-щимся в подобной системе, например, тем, кто занимает-ся торговлей на Wall Street. Уже известен и первый крупный заказчик системы – это Siemens Medical Solutions. SLERT будет применяться ею для оснащения продуктов магнит-но-резонансной интроскопии Magnetom.

Dunc-Tank будет платить разработчикам DebianГруппа разработчиков, называющая себя Dunc-Tank, гото-ва заплатить отдельным коллегам из Debian GNU/Linux за завершение некоторых проектов.

Главная цель Dunc-Tank – помочь проекту Debian выпус-тить следующий стабильный релиз дистрибутива в срок. Объявление о запуске такой инициативы привело к деба-там на тему мотивации разработчиков свободного програм-много обеспечения.

В первом публичном анонсе Dunc-Tank охарактери-зовала себя как «эксперимент», а своих участников – как «независимую группу разработчиков, пользовате-лей и желающих поддержать Debian». В действительнос-ти же оказалось, что среди членов Dunc-Tank целый ряд выдающихся разработчиков Debian: лидер проекта Энто-ни Таунс (Anthony Towns) и его помощник Стив Макинтайр (Steve McIntyre), а также Рафаэль Герцог (Raphatl Hertzog), Джоуи Хесс (Joey Hess), Тед Тсо (Ted Ts'o).

Первыми объектами спонсирования у Dunc-Tank стали два менеджера релизов: планируется нанять Стива Ланга-сека (Steve Langasek) на полный рабочий день в октябре, а Андреаса Барта (Andreas Barth) — в ноябре.

Полемика на тему мотивации разработчиков проявилась в том, что сразу после анонса инициативы Dunc-Tank один из разработчиков Debian Лукас Нассбаум (Lucas Nussbaum) раскритиковал ее, указав на исследование Луиса Виллы

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

Известны первые детали о новшествах в OpenOffice.orgНа прошедшей недавно конференции OOoCON 2006, посвя-щенной свободному офисному пакету OpenOffice.org, стало известно о готовящихся новшествах для будущих релизов OOo. Ожидается, что в версии 2.0.4 появится поддержка расширений, аналогичная той, что есть в популярном брау-зере с открытым кодом Mozilla Firefox. Хоть в OpenOffice.org и была поддержка расширений вообще, теперь их созда-ние, включение в офис, выбор и управление ими значитель-но упростится. У расширений к OpenOffice.org будет новый файловый формат (.oxt), позволяющий разрабатывать до-полнения на широком спектре языков программирования (от StarBasic до Java).

Кроме того, сообщается, что в обозримом будущем в состав OpenOffice.org и StarOffice включат разработки от Mozilla Foundation: клиент электронной почты Thunderbird и календарь Sunbird. Вместе с тем будут созданы и специ-альные модули для возможности свободного офиса под-ключаться к Sun Calendar Server и Microsoft Exchange.

Из новостей по OpenOffice.org 3.0 объявлено о том, что офис станет более модульным и работоспособным в та-ких структурах, как Eclipse, Netbeans и Mozilla XUL.

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

4

репортаж

Прежде всего обратим внимание на LinuxWorld. В этом году вы-ставка была расположена особ-

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

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

Больше всего внимания посетите-лей собирали стенды ЛинуксЦентра и журнала «Системный администра-тор». И в первом, и во втором случае основной причиной к этому были све-жие номера журналов.

Также немало людей было около эк-спозиции компании IBM, вокруг кото-рой ходил представитель линуксоид-

ного семейства – пингвин. Компания IBM представляла ряд своих решений на базе Red Hat Linux.

Компания Novell традиционно пред-лагала наиболее свежую версию дис-трибутива Suse.

ALT Linux и ASP Linux соответствен-но предлагали свои дистрибутивы.

Были представлены и компании, занимающиеся разработками своих решений на Linux. Например, компа-ния Smart Software знакомила с про-граммным продуктом «Умный ресто-ран» (система автоматизированного учёта для управления ресторанным бизнесом).

Осенний марафон выставок начался

С 4 по 6 сентября в Экспоцентре прошла выставка LinuxWorld, совмещённая с InfoSecurity, StorageExpo и Documation.

Лёгкий ажиотаж на стенде ЛинуксЦентра

5№10, октябрь 2006

репортаж

Компания R-Style, кроме всего про-чего, предлагала авторизованное обу-чение по Red Hat Linux.

Присутствовал и стенд компании Linux-Online, разработчика дистрибу-тива Linux XP, о котором в своё вре-мя прошли жаркие дебаты на многих форумах.

Несколько удивило название вы-ставки систем электронного докумен-тооборота – Documation. На стенде Cognitive Technologies была представ-лена система Евфрат-Документообо-рот. InterTrust предлагал посетителям узнать, как правильно управлять пер-соналом и узнать побольше про за-щищённый документооборот. Также присутствовали компании DocsVision, Neuhous group и Globus.

Че с тно го воря , на вы с тавке Documation было еще менее ожив-лённо, чем на LinuxWorld.

Гораздо оживлённее было на вы-ставках StorageExpo и InfoSecurity. Здесь присутствовали основные иг-роки рынка систем информационной безопасности. Системы аутентифи-кации, антивирусной защиты и шиф-рования были представлены компа-ниями «Антивирусный центр», Aladdin, Dr. Web, Актив (Guardant), Лаборато-рия Касперского, Websense, BioLink, HP, Kraftway и другими.

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

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

Сложно было пройти мимо бо-лее чем серьёзных стендов Aladdin, Trend Micro, Ланит, Открытые техно-логии и ряда других. Очевидно, что InfoSecurity и StorageExpo более при-влекательны для компаний, так как ни одного по-настоящему большого стен-да (исключая компанию IBM) на том же LinuxWorld не было.

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

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

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

В последнее время создаётся ус-тойчивое впечатление, будто бы IT-вы-ставки мало-помалу потихоньку себя изживают, как произошло с приснопа-мятной Комтек. Если говорить про вы-ставку безопасности (InfoSecurity), ко-торая интересна большинству систем-ных администраторов, то налицо от-сутствие новаторских решений и но-вых технологий. Те же компании пред-ставляют всё те же продукты. Стро-го говоря, тот, кто был на выставке в прошлом году, но не был в этом, – ничего не потерял. Остаётся надеять-ся, что отсутствие новинок – это лишь «затишье перед бурей», а не мрачная тенденция к истощению идей в компа-ниях-разработчиках.

Алексей Коршунов, фото автора

Весьма оживлённый стенд компании Hewlett-Packard

А некоторые стенды вообще пустовали…

6

репортаж

О выставке в целомВыставка Softool’2006, проходившая в Москве с 26 по 29 сентября, по тра-диции собрала множество участни-ков и посетителей. Всей экспозиции не хватило одного этажа и без того не-малого 69-го павильона ВВЦ, часть – САПР’Экспо – была расположена на втором, аккурат по соседству с пра-вославной выставкой «По завету Кня-зя Даниила» (впрочем, такое ориги-нальное сожительство совсем не в но-винку тем, кто приходит на Softool не впервые). Участники экспозиции на первом этаже были разделены на сле-дующие категории: «Технологии управ-

ления», «АСУТП’Экспо», «Информа-ционная безопасность», «DOCFLOW Day», «LinuxLand», «Информационные технологии в образовании».

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

ний, имеющих дело с информационны-ми технологиями.

Раздел «АСУТП’Экспо», как и сле-дует из названия (автоматизирован-ные системы управления технологи-ческим процессом), посвящен автома-тизации производства, причем преиму-щественно крупных промышленных предприятий (во всяком случае именно о них шла речь в докладах конферен-ции, приуроченной к экспозиции).

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

Softool стал самой успешной IT-выставкой этого года

Уже в семнадцатый раз русскоязычный мир IT-шников собирается на крупное и уже давно ставшее культовым мероприятие, имя которому – Softool.

7№10, октябрь 2006

репортаж

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

Популярная в последнее время тема электронного документооборота и его автоматизации не могла остаться неза-меченной на Softool – ей отвели само-стоятельную секцию «DOCFLOW Day», в которой вновь главенствовала не-когда учредившая это мероприятие ABBYY. На непродолжительной конфе-ренции успели выступить наиболее яр-кие представители этой области из оте-чественной индустрии.

САПР’Экспо не случайно размес-тили на втором этаже – практика пре-дыдущих выставок показала, что CAD, CAM и ГИС беспрестанно набирают по-пулярность. В связи с этим экспозиции понадобилось больше места для всех желающих продемонстрировать свою продукцию. Стоит выделить и насы-щенную программу мастер-классов, а также и занятной инициативы, полу-чившей название «САПР-Шоу», где од-ни и те же задачи одновременно реша-лись на различных системах САПР.

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

Ввиду недавних релизов Mandriva (Corporate Server 4.0 и Linux 2007) в Москву пожаловал Пол Гийе (Paul Guillet), вице-президент продаж в этой французской компании. Благодаря та-кому стечению обстоятельств и стара-ниям организаторов Россия стала пер-вой в мире страной, где прошла офи-циальная презентация последних раз-работок Mandriva.

Самым же интересным событием для меня стало знакомство с компани-ей Keyintegrity, которая, сама того из-

начально не планируя, создала Open Source-решение, обеспечивающее взаимодействие между веб-сервисами и COM-объектами ОС Windows.

В заключениеОтдельно выделю привычную актив-ность со стороны «1C».

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

На стенде редакции «Системного администратора» читатели приобре-тали любимый журнал со специаль-ной большой скидкой, которая дейс-твует исключительно на выставках. А читателям, оформившим подпис-ку на следующий, 2007 год, с юбилей-ным пятидесятым номером журнала (№1 за 2007 г.) в подарок будет прила-гаться диск с архивом всех вышедших номеров, начиная с 2002 года.

По сравнению с остальными IT-вы-ставками этого года, Softool-2006 дейс-твительно удался, по-прежнему де-ржит марку и пользуется популярнос-тью у посетителей и участников.

Дмитрий Шурупов,фото автора

8

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

В последние годы технологии тер-минального доступа к Windows-приложениям пользуются неимо-

верной популярностью. В нашей стране основную нишу занимает применение терминального доступа для компен-сации недостатков скорости обработ-ки информации наиболее популярной системы учета – «1С:Предприятие». Именно узкие места реализации об-работки данных в этой системе (нера-циональные процедуры чтения-записи записей из БД по сети) привели к не-обходимости решать проблему уско-рения системы в целом. Поскольку пе-ределать процедуры обмена самосто-ятельно невозможно (не имеет смыс-ла, так как система написана произ-

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

Подробнее о проблемеОдна из самых неприятных проблем, с которой сталкиваются пользователи

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

Как видите, количество факторов, влияющих на общее быстродействие системы, велико, и не обладая знани-


Роман Марков

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

9№10, октябрь 2006


ями обо всех возможных причинах за-медления, а главное – о способах ус-транения таких причин, – невозможно построить быстродействующую сис-тему, на 100% использующую все ее возможности. Успешная работа при реализации многих проектов систем-ной интеграции, связанных с комплек-сным внедрением систем «1С:Пред-приятие», дает мне возможность мак-симально точно оценивать причины не-эффективной работы указанного при-ложения у заказчиков.

Общие модели доступа к БД «1С:Предприятие»Наиболее часто использующийся на малых и средних предприятиях ва-риант – файл-серверная модель до-ступа. В этом случае один из компью-теров исполняет роль файл-сервера, на котором хранятся БД, предостав-ленные в общий доступ по сети, а поль-зователи играют роль клиентов этого файл-сервера, открывая предостав-ленные им файлы баз данных на чте-ние и запись.

Файл-серверная версия использу-ет файлы в формате DBF. Основное ее преимущество заключается в том, что не требуется дополнительного про-граммного обеспечения для органи-зации работы, так как для подключе-ния к базе данных достаточно предо-ставить папку с ее файлами в общий доступ, что достигается средствами любой сетевой операционной систе-мы. Этот формат разрабатывался пре-жде всего для работы с БД небольшо-го размера при малой нагрузке. Поэ-тому при активной работе нескольких пользователей с базой данных наблю-дается значительное замедление ра-боты программы. Особенно если кто-нибудь из пользователей запустит пос-троение масштабных отчётов за боль-шой период времени. О причинах этого замедления я расскажу немного поз-же, так как именно они мотивируют пе-реход к использованию терминально-го решения в файл-серверной версии системы «1С:Предприятие».

Второй тип организации досту-па к базе данных системы «1С:Пред-приятие» – клиент-серверная модель. В клиент-серверной версии таблицы хранятся в базе данных под управле-нием Microsoft SQL Server, и клиент-ское приложение не открывает файлы

базы данных при каж-дом новом подключе-нии, а посылает за-прос серверу баз дан-ных (SQL server). За-прос обрабатывается самим SQL-сервером, который считывает данные из своей ба-зы и выдает клиент-скому приложению только необходимую их часть. Таким образом взаимодейс-твие «клиент-сервер» сводится к от-правке на сервер запроса и получе-ния ответа, содержащего уже отсор-тированные данные вместо самосто-ятельного считывания клиентом фай-лов БД по сети. Это уменьшает сетевой трафик и увеличивает быстродействие в сравнении с файл-серверной моде-лью при большом количестве активных пользователей и значительном объеме БД. То есть для клиент-серверной вер-сии время реакции на запросы поль-зователей при возрастании количес-тва активных пользователей не воз-растает так резко, как это происхо-дит с файл-серверной моделью. Од-нако не стоит забывать, что SQL-вер-сия изначально ориентирована имен-но на надежность обработки боль-ших объемов данных, хранение кото-рых в файл-серверной модели чрева-то разрушением БД, а не на увеличе-ние скорости работы с приложением (во всяком случае, это относится к со-четанию «1С:Предприятие» – Microsoft SQL Server). Поэтому при малых раз-мерах БД или небольшом количест-ве активных пользователей SQL-вер-сия проигрывает по скоростным пока-зателям файл-серверной. Это можно увидеть на примерном графике со-отношения.

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

SQL-сервер хранит данные в дру-гом формате. Главное принципиаль-

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

Поэтому для обеспечения макси-мальной надежности хранения боль-ших БД и исключения возникновения транзакций рекомендуется использо-вать клиент-серверную модель.

В «1С:Предприятии 8.0» использу-ется трёхуровневая архитектура «кли-ент-сервер», при которой клиентская часть обращается к серверу приложе-ний 1С, а он в свою очередь обращает-ся к серверу баз данных Microsoft SQL Server, который и обрабатывает за-просы к информационной базе. Сер-вер приложений 1С сосредотачивает на себе выполнение объемных и слож-ных операций, при этом клиентская часть будет получать необходимую ей выборку. Ресурсы современных сер-веров позволяют расположить и сер-вер приложений и сервер БД на одном физическом сервере, что, несомнен-но, ускоряет обработку запросов, од-нако создает двойную нагрузку на ре-сурсы. К сожалению, именно к этому нас вынуждают схемы взаимодействия клиентов систем «1С:Предприятие» с их серверами.

В случае перегрузки такого серве-ра в моменты пиковых нагрузок жела-тельно разделить Сервер Приложе-

График зависимости времени реакции системы от количества активных пользователей

10


ний «1С:Предприятия 8.0» и Microsoft SQL Server, установив их на разных компьютерах, что позволит нормали-зовать работу системы.

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

Разобравшись в моделях доступа к БД в разрезе систем «1С:Предпри-ятие», можно приступать к анализу факторов, влияющих на общее быс-тродействие системы в целом. Еще раз рассмотрим возможные причины замедления:1. Увеличение размера информа-

ционных БД: это естественное следствие штатной работы с БД, размер которой зависит от коли-чества введенных документов, однако есть некоторые нюансы. Если компания ведет непрерыв-ный учет всех документов за весь период работы БД, то ее размер при интенсивном документообо-роте может вырасти до критичес-кого за очень небольшой период. Напоминаю, что мы рассматрива-ем условную величину «критичнос-ти» размера БД в файл-серверном варианте, равную 2 Гб. Для кли-ент-серверной модели это понятие (в разумных пределах), в общем-то, не имеет значения. В случае ес-ли компания не собирается пере-ходить к клиент-серверному вари-анту доступа к БД, ей приходится принимать меры по свертке таких баз, путем закрытия отчетных пе-риодов и переноса остатков на на-чало нового периода. При этом все документы, предшествующие на-чалу нового периода, из базы уда-ляются. Именно на это я и хотел бы обратить ваше внимание. Да-же после удаления неактуальных документов из БД ее размер не из-менится! Причина заключается в структуре данных, используемой для хранения БД. При удалении до-кументов из базы на физическом уровне происходит только удале-ние ссылок на эти документы. Са-мо место, зарезервированное под эти записи, в файлах БД остается занятым. Из-за этого и не меняет-ся размер БД сразу после очист-ки всех помеченных на удаление записей. Для физического сжатия

файлов БД необходимо выполнить «Упаковку таблиц БД». Для систе-мы «1С:Предприятие 7.7» это мож-но сделать из конфигуратора, вы-брав в меню «Администрирова-ние» пункт «Тестирование и ис-правление ИБ». Будьте осторож-ны с этой процедурой! Ее необхо-димо проводить только после то-го, как вы сделали архивную ко-пию БД и провели ее полное тести-рование и исправление. Для боль-ших БД данный процесс продолжи-телен и в зависимости от быстро-действия компьютера может зани-мать до 3-5 суток!

2. Увеличение количества актив-ных пользователей БД: тут таких советов, как в предыдущем пункте, дать не получится, так как «Упаков-ку пользователей» производить за-прещено законом… Так что с этим остается только смириться и следо-вать другим советам по увеличению производительности системы.

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

4. Низкая пропускная способность локальной сети: для обеспече-ния достаточного быстродейс-твия необходимо, чтобы пропус-кная способность сети составля-ла 100 мегабит от клиента до сер-вера БД (это требование не отно-сится к варианту с сервером тер-миналов – там достаточно 50-100 килобит(!) в сек. для каждого из клиентов. Для 3-уровневой систе-мы обработки «1С:Предприятие» при разнесении сервера приложе-ний 1С и SQL-сервера по физичес-ки разным серверам рекомендует-ся максимально увеличить скорость их взаимодействия между собой. Нелишним окажется установить в каждый сервер по два и более гигабитных сетевых адаптера и со-единить их через гигабитный ком-мутатор, объединив сетевые адап-теры в транк с поддержкой балан-сировки нагрузки.

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

6. Некорректная настройка IT-инф-раструктуры техническими спе-циалистами и отсутствие у тех-персонала знаний о возможнос-тях оптимизации информаци-онной системы: здесь все зави-сит от глубокого понимания IT-спе-циалистами происходящих в се-ти процессов. Помимо общих ка-нонов настройки локальной сети, необходимо учитывать множес-тво факторов. Например, частой ошибкой технических специалис-тов является отсутствие тонкой на-стройки антивирусных мониторов. Чаще всего оставляют настрой-ки по умолчанию, что для мно-гих антивирусных продуктов оз-начает постоянную проверку всех подключенных сетевых ресурсов, а также абсолютно всех файлов. Рекомендуется исключать из про-верки файлы БД, так как нали-чие в них вирусов – очень мало-вероятное событие. А вот посто-янная проверка файлов метадан-ных (*.md), структуры метаданных (*.dd) и файлов БД 1С *.dbf и *.cdx замедлят работу всей вашей сис-темы в несколько раз.

Замедление работы файл-серверной модели БД на серверах с WindowsИтак, мы добрались до рассмотрения технологии терминального доступа, ее преимуществ и причин, по которым

11№10, октябрь 2006


ее применение позволяет максималь-но ускорить работу с БД.

Наверняка все вы знаете о «стран-ной» особенности работы с БД, распо-ложенных на сетевых дисках серверов, под управлением ОС Windows. С файл-серверами под управлением других ОС дело обстоит получше, но не все умеют их администрировать, да и то ускоре-ние, которое предоставляют техноло-гии терминального доступа, все равно недостижимо другими способами – пе-реносом БД на файл-сервер с ОС, от-личимой от Windows.

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

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

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

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

со сервером терминалов. Именно по-этому не имеет значения, какой ком-пьютер установлен у клиента – единс-твенная его задача – запустить клиент-скую часть, которая будет нормально работать даже на 486-м компьютере с 16 Мб памяти и любой ОС, для кото-рой существует клиент сервера терми-налов Windows.

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

Серьезным расширением возмож-ностей стандартного сервера терми-налов Windows является продукт Citrix Metaframe. Он предоставляет возмож-ность сделать работу с терминальным приложением абсолютно прозрачным для пользователя и для удобства поз-воляет подключить и собственные ре-сурсы компьютера. Например, под-ключение к сеансу пользователя его локальных принтеров, на мой взгляд, в Citrix Metaframe организован более удобно. Однако следует учитывать что Citrix Metaframe является только дополнением к стандартному серве-ру терминалов MS, а не самостоятель-ным продуктом. Да и стоимость данно-го «расширения» велика по сравнению с применением стандартного сервера терминалов от Microsoft. К слову, са-му технологию Terminal Services ком-пания Microsoft купила именно у ком-пании Citrix.

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

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

Помимо ускорения работы с БД неоспоримым преимуществом терми-нал-сервера является сжатие переда-ваемой по сети информации, что поз-воляет работать с программой через медленные каналы связи. Именно та-кая модель доступа позволяет орга-низовать удаленную работу фили-альных отделов с единой БД в режи-ме online – ведь для каждого клиента достаточно канала передачи данных шириной 40-60 Кбит/сек. Таким обра-зом, при необходимости предоставить филиальным представительствам до-ступ к центральной БД (или наоборот) достаточно обладать сервером необ-ходимой мощности для организации на нем сервера терминалов и кана-лом связи с указанной выше пропус-кной способностью.

Сколько стоит такое терминальное решение?Итак, принимая решение о переходе на терминальную схему работы системы «1С:Предприятие», необходимо учиты-вать, что для организации работы сер-вера в режиме сервера приложений необходимо приобрести лицензии кли-ентского доступа к нему. Каждая ли-цензия «на устройство» (MS TS CAL) обойдется вам около 80 $. Сам сервер терминалов входит в стоимость лицен-зии Windows Server.

Расширение Citrix Metaframe стоит от 2000 USD за стартовый пакет из 5 лицензий. Каждые последующие 5 ли-цензий будут стоить около 1500 $.

Поэтому (это мое субъективное мнение) покупка MS TS CAL – абсо-лютно оправдана, так как ускорение работы системы при этом предоста-вит новые возможности расширения бизнеса.

Приобретение же Citrix Metaframe должно быть обусловлено серьезной необходимостью использования воз-можностей продукта, однако их анализ выходит за рамки данной статьи.

12


Приступая к работеРешение проблем, связанных с экс-плуатацией оборудования и програм-много обеспечения, – неотъемлемая часть работы системного администра-тора. Так называемый troubleshooting, как правило, занимает намного боль-ше времени, чем, к примеру, работы по внедрению программных продук-тов или начальная настройка сетевого оборудования. В связи с этим возника-ет необходимость в постоянном мони-торинге событий, происходящих в се-ти. Конечно, если у вас один или два сервера, то всю необходимую инфор-мацию можно получать из журнала со-бытий (Event Viewer), счетчиков произ-водительности (Performance Counter), а также WSH-сценариев. Но если у вас десятки серверов, на которых установ-лены различные программные продук-ты (службы Active Directory, базы дан-ных, система резервного копирования, корпоративный антивирус и так далее), то без промышленного решения не обойтись. Для сети на основе Windows таким решением является Microsoft Operations Manager 2005. Однако, об-щаясь со многими системными адми-нистраторами, мне приходилось стал-киваться с тем, что некоторые из них, внедрив этот, прямо скажем, недеше-

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

Архитектура системы«MOM 2005 предоставляет открытые и масштабируемые средства для уп-равления информационными система-ми предприятий, комплексного управ-ления событиями, активного контроля и оповещения, создания отчетов и ана-лиза тенденций, а также специальные базы знаний, содержащие сведения о функционировании систем и прило-жений, для повышения уровня управ-ляемости корпоративных систем». Та-кое определение своему продукту дает Microsoft. Несмотря на официальный стиль, такое определение дает общее представление об архитектуре и фун-кциональности продукта. Итак, рас-смотрим более подробно схему взаи-модействия МОМ с управляемыми про-дуктами (см. рис. 2).

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

Следующий элемент системы – база МОМ, в которой хранятся все настройки и сообщения о событиях. В связи с этим необходимо позабо-титься о безопасности базы, разграни-чив соответствующим образом доступ к ней. В зависимости от аппаратных возможностей сервера, на котором разворачивается Microsoft Operations Manager, базу данных можно устано-вить как на том же узле, так и другом, в случае, если нагрузка на сервер уп-равления слишком велика. Что каса-ется редакции SQL-серверa, которую можно использовать для базы дан-ных, то лучше по возможности избе-

Microsoft Operations Manager 2005: управляем сетью

Мониторинг и управление серверами и приложениями, особенно в большой сети, – задача нетривиальная, и зачастую требует довольно больших затрат времени и ресурсов. Эффективное средство, которое позволит вам решить часть этих проблем, – Microsoft Operations Manager.

Андрей Бирюков

13№10, октябрь 2006


жать применения MSDE. Дело в том, что ввиду ограничений, которые раз-работчики наложили на версию MSDE, например, общий объем файлов базы должен быть не более 2 Гб, нормальное функционирование МОМ в больших се-тях может оказаться под угрозой. К со-жалению, мне не довелось разворачи-вать МОМ вместе с Microsoft SQL 2005, но по заверениям Microsoft, ее также можно использовать в качестве ба-зы данных.

Описав систему управления МОМ, теперь перейду к элементам, которы-ми управляет система. Узлы могут уп-равляться как с помощью специаль-ных агентов, так и без них. Для раз-вертывания агентов необходимо ус-тановить на управляемую машину агент МОМ (узел вида Agent managed), то есть сервис, который будет локаль-но собирать данные о состоянии маши-ны и отправлять их на сервер управ-ления. Устанавливать агентов можно как удаленно с сервера управления, так и локально, запустив дистрибутив на управляемом сервере. Для соеди-нения с сервером управления по умол-чанию используется порт 1270 и про-токол TCP. Узлы без агентов (agentless managed) не содержат каких-либо сер-висов и приложений МОМ. При этом агент установлен на самом сервере управления, который удаленно соби-рает информацию с управляемого уз-ла. При этом используются средства Windows для сбора сведений о состо-янии управляемой системы. Недостат-ком agentless-узлов является отсутс-твие ряда возможностей для более эф-фективного сбора статистики и реаги-рования на инциденты, по сравнению с agent-managed.

Еще один элемент системы управ-ления Microsoft Operations Manager – Management Packs – контейнеры, со-держащие наборы правил, позволя-ющих осуществлять сбор информа-ции. Этот элемент МОМ представляет особый интерес, так как именно с по-мощью Management Packs можно со-бирать разнообразную информацию о системе. На основе этих сведений можно создавать правила, позволяю-щие реагировать на различные собы-тия системы.

Пакеты управления бывают как платные, так и бесплатные. Бесплат-ные пакеты можно найти на сайтах

производителей программных про-дуктов. Management Packs для про-дуктов Microsoft можно скачать бес-платно [1]. К тому же хочу заметить, что Management Pack можно сделать самому, подробнее этот вопрос я рас-смотрю далее. На этом теоретическая часть закончена, и приступим к более интересной практической части, то есть реализации функциональных воз-можностей МОМ на практике.

Разворачиваем системуПрежде всего необходимо определить, какие сведения надо собирать. Пред-положим, что в сети имеется четыре сервера. Первый является основным контроллером домена, на нем так-же запущены службы DHCP, DNS, IIS и система резервного копирования. Второй – резервный контроллер доме-на, на котором также установлен поч-товый сервер Exchange. Третий сервер в предполагаемой топологии – это сер-вер баз данных, на котором установ-лены Microsoft SQL 2000 и сервер тер-миналов. И наконец, четвертый фай-ловый сервер, на нем находятся пап-ки общего доступа, хранятся профили пользователей и файлы резервных ко-пий. Расположение описанных прило-жений на конкретных серверах боль-шого значения не имеет, даже если все они установлены на одном серве-ре, МОМ это не помешает.

Процесс установки самого серве-ра управления MOM 2005 подробно расписан в файле помощи. Отмечу лишь, что после установки MOM 2005 необходимо также установить Service Pack1.

П о с л е у с т а н о в к и , о т к р ы в Administrative Console, вы увидите ок-но (см. рис. 1).

Консоль является основным сред-ством администрирования Microsoft Operat ions Manager. В раз деле Administration, открыв подраздел Computers, в группе Management Servers видны те серверы, которыми может управлять МОМ. Сюда входят как узлы с установленными агента-ми, так и agentless-узлы. Однако сра-зу после установки в этом разделе бу-дет только один узел – сам сервер уп-равления МОМ.

Теперь нужно развернуть агенты на тех узлах, которыми необходимо управлять. Конечно, можно обойтись без установки агентов, но тогда нельзя будет продемонстрировать часть фун-кциональных возможностей продукта. Для развертывания можно воспользо-ваться MSI-пакетом, который входит в состав дистрибутива МОМ, или уда-ленной установкой из консоли управ-ления Administration console. После за-пуска открывается окно для установ-

Рисунок 2. Схема взаимодействия МОМ и управляемых серверов

Рисунок 1. Административная консоль МОМ

14


ки соединения с сервером управления (см. рис. 3).

Здесь необходимо указать группу, в которой должен находиться данный узел, сервер управления, а также порт, по которому должен осуществляться доступ. Обратите внимание на номер порта, который используется для уста-новки соединения. Если при установке сервера управления был указан другой порт, то его надо указать и при установ-ке агента. Также следует проследить, чтобы этот порт был открыт на межсе-тевом экране, в случае, если управля-емый сервер находится в DMZ. В раз-деле Agent Control Level можно выбрать уровень доступа, который будет разре-шен управляющему серверу к данно-му агенту. По умолчанию предлагает-ся опция None, то есть сервер управ-ления не будет иметь права на изме-нение конфигурации, деинсталляцию или обновление агента. Такой вариант является наиболее приемлемым в си-туации, когда управляемый узел и сер-вер МОМ разделены межсетевым эк-раном. Опция Full позволяет серверу управления осуществлять изменение конфигурации и деинсталляцию аген-тов. В разделе Advanced можно также добавить адрес альтернативного сер-вера МОМ. Это позволяет увеличить надежность системы в целом.

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

Computers административ-ной консоли МОМ. При об-суждении вопроса установ-ки агентов на различные узлы нельзя обойти еще одну интересную возмож-ность Microsoft Operations Manager – это средство Computer Discovery Rule, поз-воляющее задавать прави-ла при поиске машин, на ко-торые не был установлен агент, машин, входящих в домен, серверных или кли-

ентских операционных систем, а также имен машин, содержащих определен-ный набор символов.

Итак, после того, как агенты уп-равления установлены, можно присту-пить к установке пакетов management Packs, позволяющих осуществлять сбор информации по событиям кон-кретного вида. Если в состав ваше-го дистрибутива МОМ не входят нуж-ные пакеты или они уже слишком ус-тарели, то можно воспользоваться ис-точником [1] или же поискать на сайте производителя конкретного програм-много обеспечения. Так какие пакеты management Pack нам нужны для то-го, чтобы эффективно управлять на-шими четырьмя серверами? Прежде всего, учитывая, что сегодня практи-чески каждая сеть на основе Windows использует AD, нужно установить па-кет для Active Directory. С помощью Management Pack можно получать уве-домления об использовании учетных записей, попытках несанкциониро-ванного доступа, изменения привиле-гий и так далее. Следующий необхо-димый пакет – Base Operating System – позволяет собирать сведения о про-изводительности серверов, использо-вании ресурсов, загрузке процессора. Далее DHCP Service и, следовательно, Management Pack для сбора статисти-ческой информации по событиям, свя-занным с DHCP. В случае, если в ва-шей сети используется Distributed File System, можно воспользоваться соот-ветствующим пакетом для DFS. Так-же необходим пакет для DNS. Так как мы договорились, что в нашей сети ис-пользуется почтовый сервер Exchange, то необходимо установить пакеты уп-равления для него. Тут следует огово-риться, что для Lotus Domino также су-ществуют пакеты управления для МОМ,

но они платные в отличие от пакетов для продуктов Microsoft, которые мож-но скачать бесплатно. Далее будет весьма полезен пакет Group Policy, ко-торый позволит собирать все сведения о результатах применения групповых политик на клиентских машинах и сер-верах. Если в вашей сети используются веб- или FTP-службы на базе IIS, то со-ответствующий пакет управления так-же будет полезен. Management Pack для таких продуктов Microsoft, как ISA, SQL Server, SMS, Office и MOM (собственно, сбор статистики по самому МОМу то-же необходим), нужно установить в том случае, если эти продукты используют-ся в вашей сети. Возвращаясь к нашим четырем серверам, отмечу, что необ-ходимо установить пакет для Terminal Services, Print Service, WINS (несмотря на все рекомендации Microsoft, данная служба до сих пор активно использует-ся во многих сетях).

Теперь, определившись с пакетами, которые необходимо развернуть, мож-но приступать к самому процессу уста-новки. Для этого в административной консоли выберите раздел management Packs, далее в меню Action, опция Import/Export Management Pack. В ок-не запустившегося мастера, выбираем Import (Export может потребоваться при миграции настроек на другой сервер управления). Далее указываем путь к файлам пакета, внизу предлагается выбрать, что экспортировать. В случае, если у вас служба Reports не использу-ется, импортируйте только Management Pack. Далее можно выбрать тип импор-та, если пакет устанавливается впер-вые, то делать резервное копирование предыдущей версии не нужно. Затем происходит собственно импорт паке-та. В случае удачного завершения уста-новленный Management Pack сразу же начинает наблюдение за соответству-ющими компонентами системы. С по-мощью данного алгоритма необходи-мо установить все выбранные пакеты управления МОМ.

Для того чтобы увидеть резуль-тат работы пакетов, достаточно зайти в Operator Console. Здесь есть раздел Alerts и раздел Service Level Exceptions. В них находятся сообщения обо всех событиях, которые фиксирует МОМ. Также есть разделы, каждый из ко-торых соответствует определенному Management Pack, в которые аналогич-

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

15№10, октябрь 2006


но собираются события (Events) и ис-ключения (Exceptions), но уже относя-щиеся только к данному разделу. На-пример, на рис. 4 можно наблюдать несколько сообщений разного уровня важности, критические ошибки (Critical Error), ошибки (Error), предупреждения (Warning) и информационные сообще-ния (Information).

Следует заметить, что это не прос-то сообщения, аналогичные тем, что операционная система создает в журнале событий Event Log. Здесь со-общения предусматривают некото-рую реакцию оператора, в частности, обратите внимание на поле Resolution State. Новые сообщения всегда появ-ляются в состоянии New, однако даль-нейшее состояние каждого сообщения должен определять уже оператор. Со-стояние может подразделяться на че-тыре уровня: Уровень 1 – проблема отправле-

на внутренней технической под-держке.

Уровень 2 – проблема отправлена специалисту по данному продукту.

Уровень 3 – проблема направлена во внешнюю поддержку (например, службе технической поддержки компании-поставщика).

Уровень 4 – проблема отправлена производителю.

И также есть состояние Resolved (решено). При этом рекомендую не ста-вить сообщениям состояние Resolved, не выяснив полностью причину возник-новения проблемы. В противном слу-чае вы можете просто забыть о её на-личии, а ведь при следующем прояв-лении этой проблемы последствия мо-гут быть более значительны. Вот прос-той пример, на рис. 4 приведено со-общение, в котором говорится о том, что DHCP-сервер по какой-то причи-не не выдает адреса. Можно предпо-ложить, что область DHCP не активи-рована, в связи с чем он не может вы-давать IP-адреса. Теперь обратите внимание на поля «Time of First Event» и «Time of Last Event». Эти поля со-держат сведения о первом и послед-нем сообщениях и о данной пробле-ме. Согласитесь, так намного удобнее, чем самому искать сведения об ошиб-ке в журнале событий Event Log. Зная, когда проблема впервые появилась, намного проще ее решать. В моем слу-

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

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

Из прочих полезных функций Microsoft Operation Manager упомяну наличие в консоли оператора раздела Events, содержащего сведения о собы-тиях, но, в отличие от Alerts, здесь фик-сируются все события, которые полу-чает МОМ. Эти события уже не требуют реакции от оператора и носят инфор-мативный характер, но при этом на ос-новании сообщений раздела Events со-здаются уведомления Alerts.

Жизнь по правиламЕще одно полезное свойство МОМ – это возможность создания собствен-ных правил (Rule). На их основании можно создавать уведомление (Alert), которое будет отправляться в случае возникновения сообщений, интересу-ющих администратора. Для того чтобы создать правило, необходимо снача-ла создать группу Rule Group. Для это-го требуется в разделе «Management Packs» выбрать «Rule Group» и далее в меню «Action» выбрать «New Rule

Group». Далее создаваемой группе необходимо дать имя и активировать ее, включив опцию «Enabled». Теперь вам доступны три вида правил: Event Rules, Alert Rules и Performance Rules. Каждая из этих групп предполагает наличие правил для решения опреде-ленных задач: Event Rules – эта группа реагирует

на появление определенных собы-тий в журнале Event Log.

Alert Rules – правила, реагирую-щие на определенные Alerts.

Performance Rules – правила, ре-агирующие на определенные по-роговые значения производитель-ности различных компонентов сис-темы.

Для лучшего понимания я создам по одному правилу каждого вида. Для Event Rules поставим задачу со-здать правило, по которому оператор должен получать Alert при каждой не-удачной попытке FTP-соединения. Alert Rules – будем следить за сообщениями недоступности сервиса, в случае их по-явления запускать сценарий, который будет осуществлять перезапуск серви-сов. Для Performance Rules необходи-мо следить за тем, чтобы нагрузка на процессор любого из серверов не пре-вышала 80%, в противном случае так-же запускать сценарий.

Итак, для создания первого пра-вила заходим в «Event Rules», далее «Action → Create Event Rule». Выбира-ем в появившемся меню «Alert on or

Рисунок 4. Консоль оператора

16


Respond to Event». Выбор обусловлен тем, что необходимо создать правило, реагирующее на появление опреде-ленного события. В следующем окне выбираем опцию «IIS Application Log – FTP», тип событий – «failure audit» (ин-тересуют только неудачные попытки соединения). Следующий этап – рас-писание (лучше всего постоянный мо-ниторинг), затем выбираем Computer и Domain (области действия). Потом Response, здесь можно задать дейс-твие, которое необходимо совершить в случае выполнения заданных кри-териев, например запуск какого-ли-бо сценария. На этом пункте останов-люсь особо. Так как само по себе по-лучение уведомлений о попытках не-санкционированного доступа не слиш-ком информативно (их может быть де-сятки за день), то имеет смысл исполь-зовать сценарий, либо специально на-строенное приложение, которое будет адекватно реагировать на подобные попытки. Например, в случае пяти не-удачных попыток подключения по FTP, для IP-адреса, с которого осуществля-лись попытки, на час будет заблокиро-ван доступ по порту 21. Вопросы прак-тической реализации данного меха-низма уже обсуждались в предыду-щих моих статьях [3]. И, наконец, собс-твенно Alert, который будет создавать-ся. Здесь необходимо указать степень критичности создаваемого уведомле-ния, затем состояние, в котором Alert появляется, а также описание и источ-ник проблемы (рекомендую исполь-зовать значения по умолчанию). В ре-зультате выполненных действий после каждой неудачной попытки установле-ния FTP-соединения будет появляться соответствующий Alert MOM, а также, при соответствующей настройке, будут выполняться действия по предотвра-щению несанкционированного досту-па к FTP-ресурсу.

Для создания Alert Rule необходи-мо зайти в соответствующий раздел, выбрать «Create Alert Rule», в появив-шемся окне выбираете «Alert Criteria – of severity → Service Unavaliable», далее «Define Response – Launch a script», вы-бираем из списка или указываем но-вый, в данном случае указываем свой сценарий, который будет перезапус-кать нужные сервисы, место запуска – Agent Computer, далее остается только дать правилу имя.

И наконец, для создания треть-его правила, которое должно сле-дить за нагрузкой на процессор, нуж-но проделать аналогичные действия, Create Performance Rule. Затем ука-зывается, каким образом произво-дится сбор сведений по производи-тельности, в данном случае выбира-ете «Sample Performance», в следую-щем окне нужно выбрать «Performance Measure – Processor Time…» данный счетчик сообщает об использовании ресурсов процессора, далее в разде-ле Response выбираете готовый сце-нарий Microsoft Windows Base OS CPU Overload Script. По умолчанию в кри-териях указано значение 95%, но так как предполагалось использовать зна-чение 80%, то соответственно его не-обходимо заменить.

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

Резервное копированиеТакая мощная система, как МОМ, нуж-дается в регулярном резервном копи-ровании. Приведу те компоненты, ко-торые необходимо копировать. Пре-жде всего это база SQL, в которой хра-нятся все настройки МОМ. Если вы ис-пользуете только Microsoft Operations Manager, то вам достаточно регуляр-но делать резервную копию базы Оnepoint, однако если вы также ис-пользуете отчеты (Reporting), то тог-да необходимо делать и копию баз SystemCenterReporting и ReportServer. Выполнять это копирование можно штатными средствами Microsoft SQL Server. Также нужно обязательно иметь в наличии все Management Packs. Для этого воспользуйтесь экспортом паке-тов из MOM, аналогично уже описанно-му выше импорту. Для восстановления данных необходимо сначала восстано-вить базы данных, а затем импортиро-вать Management Pack в МОМ. Также не забывайте следить за выходом новых версий Management Pack [1, 2].

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

вящены множество курсов во многих учебных центрах, также большое ко-личество информации можно найти на сайте Microsoft. В этой статье я лишь по-пытался описать основные возможнос-ти продукта и рассмотреть на примерах варианты его использования. Но в за-ключение – несколько слов относитель-но особенностей использования МОМ. Отмечу, что хотя МОМ и позволяет ав-томатизировать выполнение опреде-ленных задач, но он требует постоян-ной работы со стороны системных ад-министраторов. Нужно составить спи-сок тех ресурсов, которые необходимо отслеживать с помощью МОМ. Далее, в соответствии с этим списком необ-ходимо создать правила. Однако это-го мало. Надо также регулярно следить за теми уведомлениями, которые сооб-щает система, и реагировать на них. Если вы один раз, установив агентов и пакеты управления и настроив нуж-ные правила, затем забыли про сер-вер МОМ, то польза от применения бу-дет невелика. Продукт применяется для так называемой проактивной за-щиты от сбоев, то есть он предупреж-дает администратора о возможности возникновения проблемы еще до того, как она проявилась (например, закон-чилось место на диске или IP-адреса в DHCP-пуле). Учитывая это, необхо-димо ежедневно проверять уведомле-ния системы.

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

Кстати, сейчас доступна для ска-чивания бета-версия MOM 2007, ко-торую можно бесплатно получить по адресу [2].

1. http://www.microsoft.com/downloads/Browse.aspx?displaylang=en&productID= 9 C D 2 C 7 0 F - F 1 D E - 4 C 4 D - 8 E C B -1432951CE0C6 – раздел, посвящен-ный пакетам обновления Management Packs.

2. http://www.microsoft.com/mom – страни-ца посвященная МОМ.

3. Бирюков А. Пишем систему динамичес-кой защиты ресурсов сети./Системный администратор, №6, 2006 г. – С. 56-60.

17№10, октябрь 2006

bugtraq

Множественные уязвимости в Mozilla FirefoxПрограмма: Mozilla Firefox до версии 1.5.0.7.Опасность: Критическая.Описание: 1. Переполнение буфера в обработке JavaScript регулярных выражений позволяет злоумышленнику выпол-нить произвольный код на целевой системе.

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

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

4. Уязвимость обнаружена в проверке некоторых подпи-сей в Network Security Services (NSS)-библиотеке.

5. Уязвимость в междоменном взаимодействии позво-ляет внедрить произвольный HTML и код сценария в фрейм другого веб-сайта, используя вызов [window].frames[index].document.open().

6. Ошибка обнаружена при открытии заблокированных всплывающих окон. В результате можно выполнить произ-вольный HTML и код сценария в браузере текущего поль-зователя в контексте произвольного веб-сайта.

7. Несколько нераскрываемых ошибок памяти позволя-ют выполнить произвольный код на целевой системе.URL производителя: http://www.mozilla.com/firefox.Решение: Обновите до версии 1.5.0.7.

Переполнение динамической памяти при обработке LHA-архивов в Dr.WebПрограмма: Dr.Web 4.33, возможно, более ранние версии.Опасность: Критическая.Описание: Уязвимость существует из-за ошибки при об-работке LHA-архивов, содержащих длинные имена дирек-торий в расширенном заголовке директории. Удаленный пользователь может вызвать переполнение динамической памяти и выполнить произвольный код на целевой систе-ме. Рабочий эксплоит написан для Dr.Web Scanner for Linux v4.33 (4.33.0.09211).URL производителя: http://www.drweb.com.Решение: Установите исправление от производителя пу-тем обновления антивирусных баз.

Множественные уязвимости в Zend PlatformПрограмма: Zend Platform 2.2.1, возможно, более ранние версии.Опасность: Высокая.Описание: 1. Уязвимость существует из-за ошибки провер-ки границ данных в ZendSession Manager Daemon при обра-ботке сессий. Удаленный пользователь может аварийно за-вершить работу приложения, отправив слишком длинный или нулевой длины идентификатор сессии.

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

3. Уязвимость существует в ZendSession Manager при об-работке сессионных файлов. Злоумышленник может со-здать и просмотреть произвольные файлы сессий на це-левой системе с привилегиями приложения.URL производителя : http://www.zend.com/products/zend_platform.Решение: Установите последнюю версию (2.2.1a) с сайта производителя.

Загрузка произвольных файлов в TikiWikiПрограмма: TikiWiki 1.9.4, возможно, более ранние вер-сии.Опасность: Высокая.Описание: Уязвимость существует из-за недостаточной проверки загруженных файлов в сценарии jhot.php. Уда-ленный пользователь может загрузить злонамеренный PHP-сценарий в каталог img/wiki и выполнить его на сис-теме с привилегиями веб-сервера.URL производителя: http://www.tikiwiki.org.Решение: В настоящее время способов устранения уязви-мости не существует.

Переполнение динамической памяти в Microsoft Internet ExplorerПрограмма: Microsoft Internet Explorer 6.x.Опасность: Высокая.Описание: Уязвимость существует из-за недостаточной проверки входных данных в ActiveX-компоненте daxctle.ocx. Удаленный пользователь может с помощью дескриптора DirectAnimation.PathControl вызвать переполнение дина-мической памяти и аварийно завершить работу браузера или выполнить произвольный код на целевой системе.URL производителя: http://www.microsoft.com.Решение: В настоящее время способов устранения уязви-мости не существует.

Выполнение произвольного кода в Ipswitch IMail ServerПрограмма: Ipswitch Collaboration Suite 2006, IMail Secure Server 2006, IMail Server 2006.Опасность: Высокая.Описание: Уязвимость существует из-за неизвестной ошибки в SMTP-демоне. Удаленный пользователь может выполнить произвольный код на целевой системе.URL производителя: http://www.ipswitch.com.Решение: Установите исправленную версию с сайта про-изводителя.

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

18


Экономьте время на администрировании Active Directory

Служба каталогов Active Directory – мощный и один из наиболее важных компонентов распределенной компьютерной системы, который дает гибкость в распределении ресурсов. Но в то же время стандартные инструменты, входящие в состав ОС Windows не во всех случаях обеспечивают должный уровень управления AD.

Сергей Яремчук

19№10, октябрь 2006


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

ступ, управление Active Directory да-же внутри отдельного домена замет-но усложняется. А учитывая, что ад-министрированием может занимать-ся несколько человек, через некото-рое время ситуация может стать не-управляемой, а сама система потре-бует серьезного аудита. Для админис-трирования Active Directory использу-ются несколько инструментов, встро-енных в Windows 2000/2003 Server, что не всегда удобно и требует некото-рого времени на их полноценное осво-ение. Консоль управления групповыми политиками (Group Policy Management Console – GPMC), которая появилась в 2003 году, обеспечивает пользовате-лю более удобный интерфейс управле-ния политиками Windows на базе MMC (Microsoft Management Console). В его состав входит набор сценариев, пред-назначенных для автоматизации ти-повых задач управления объектами групповой политики. Но в то же время и его возможностей часто бывает не-достаточно.

Утилита Active AdministratorКорпорация ScriptLogic специализи-руется на разработке решений, пред-назначенных для администрирова-ния сетей Windows. Одним из выпус-

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

Программа, к сожалению, не бесплатна, стоимость ли-цензии зависит от количест-ва объектов в Active Directory. Сама ли-цензия привязана к Organizational Unit, поэтому применение ее с иным OU не-возможно.

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

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

Консоль управления предоставля-ет единый интерфейс для управления, планирования, редактирования, ре-зервирования и восстановления груп-повых политик. Поддерживается фун-кциональность инструмента, извест-ного как результирующий набор по-литик (Resultant Set of Policies – RSoP), появившаяся в Windows 2003 Server, задача которого – упростить измере-ние накопительных настроек группо-вой политики, применяемых к пользо-вателю или компьютеру. Это позволя-ет администраторам планировать сце-нарии перемещения объекта. Active Administrator автоматически сохраняет всю историю изменений групповых по-литик, давая тем самым возможность при необходимости сравнить новые настройки, быстро осуществить воз-врат к старым настройкам. Изменения политик производятся не напрямую в рабочую среду, а в Offline Repository. Для оценки эффекта созданные та-ким образом политики сравниваются с действующими, в том числе и с ис-пользованием RSoP. Удобно, что ре-дактирование Offline Repository может быть осуществлено администратора-ми, имеющими доступ к политикам в режиме только для чтения. Но при-меняют их только те, кто имеет соот-ветствующие права. Средствами про-граммы возможны копирование и реп-ликация групповых политик между доменами. Для контроля изменений в Active Directory и групповых поли-

Рисунок 2. Настройка сервиса Active Template Auto-Repair

Рисунок 1. Настройка сервиса Event Configuration Utility

20


тик Active Administrator анализирует журнал. Воспользовавшись системой фильтров, администратор всегда уз-нает, кто и когда внес эти изменения. Кроме того, при возникновении неко-торых событий администратор опове-щается посредством электронной поч-ты. И наконец, программа предостав-ляет полноценные отчеты по установ-кам Active Directory и групповых поли-тик, по безопасности, классам объек-тов и прочее. Отчеты экспортируются в файлы форматов RTF, PDF, HTML, XLS, TIF, RDF, TXT.

Установка Active AdministratorДля того чтобы скачать файл, необ-ходимо зарегистрироваться на сайте, указав персональные данные и пароль, которым будете пользоваться. После чего на указанный почтовый адрес при-дет ссылка для закачки. В архиве «ве-сом» 45 Мб два файла: AAServerSetup предназначен для установки на сервер, а с помощью AAConsoleSetup необхо-дима для установки удаленной консо-ли управления. Системные требования

для компьютера, на который устанав-ливается Active Administrator, невелики. Требуется процессор класса Pentium 600 Мгц с 256 Мб оперативной памя-ти с Windows 2000 и выше. Кроме это-го, для хранения информации может использоваться Microsoft SQL Server Desktop Engine, который устанавли-вается по умолчанию, либо имею-щийся SQL Server. В последнем слу-чае при установке следует выбрать режим Custom и отключить инсталля-цию MSDE. Программа установки пот-ребует, чтобы вы указали каталог, ко-торый будет использован для хране-ния информации. На этом этапе со-здаем локальную базу событий безо-пасности, в которую будет заносить-ся информация о событиях безопас-ности. Заполняем поля и выбираем метод аутентификации для доступа к базе: Windows или SQL Server. В ре-зультате будет созданный разделяе-мый ресурс ActiveAdministrator, имею-щий по умолчанию права Full Control для Everyone.

Далее запускается Database Maintenance Wizard, задача которо-

го – создать базу данных и помочь в настройке сервисов истории груп-повых политик (Group Policy History), восстановления Active Template (Active Template Auto-Repair service) и сер-виса восстановления информации. Для каждого необходимо указать до-мен и пользователя для регистрации (рис. 2).

При настройке параметров Auto-Repair-сервиса возможна настройка оповещения по электронной почте, вы-брав Configure e-mail Setting, указыва-ем почтового сервера и адрес, на ко-торый они будут отсылаться. Если ис-пользуется Windows 2003 с SP1, Active Administrator может восстанавливать пароли к удаленным счетам. Жела-тельно сразу же после настройки сер-виса восстановления нажать Backup Now для создания резервной копии. На этом установка сервера Active Administrator заканчивается.

Консоль можно установить как на любой компьютер в сети, так и на тот, на котором стоит сервер Active Administrator. Каких-либо особенностей при установке консоли нет.

21№10, октябрь 2006


Рисунок 3. Вид Active Administrator Console

Настройка базы аудита событийПрограмма установки позволяет со-здать базу событий безопасности для локальной системы MSDE 2000. Вероятно, может понадобиться пере-нести ее на SQL Server. Для создания такой базы выбираем «Creating Auditing Database» в меню «Пуск». После это-го появится знакомый мастер. На пер-вом шаге которого в выпадающем списке выбираем new database и да-лее действуем как во время установ-ки, заполняя нужные поля. После уста-новки базы данных необходимо с по-мощью Active Administrator, либо Active Directory Users с MMC и разрешить ау-дит в Default Domain Controllers Policy. После чего выполнить gpupdate. Сле-дующий шаг, настройка утилиты опо-вещения Event Configuration Utility. В по-явившемся окне (рис. 1) во вкладке «Event Definitions» выбираем события, при появлении которых мы хотим по-лучать оповещение. Список адресов, которым будет отсылаться уведомле-ние, вводится во вкладке «Defailt Email Adresses». Но можно для отдельно-го события указать специфический электронный адрес, для этого нужно вызвать контекстное меню, щелкнув по нему правой кнопкой мышки. Ес-ли еще имеются сервисы с включен-ным мониторингом событий, добавить их контроль можно во вкладке «Install DC Agents». На этой же странице отоб-ражается статус агентов и загружают-ся новые файлы, содержащие собы-тия. Все зарегистрированные собы-тия сохраняются затем в файле с рас-ширением edf.

Работа с Active Administrator ConsoleПри первом запуске консоли управ-ления вам предстоит ввести лицензи-онный ключ, если у вас его нет, но вы-бираем «Begin Evaluation» и пользу-емся программой в течении 30 дней, без всяких ограничений функцио-нальности.

Консоль состоит из 10 вкладок: Group Policy History – здесь мож-

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

Group Policy Offline Repository – здесь создаются и редактируются

GPO без их применения в реальной сети.

Resultant Set of Policies (RSoP) – в этой вкладке производится ана-лиз созданных в offline repository по-литик.

Group Policy Objects by Container – здесь можно просмотреть группо-вые политики и проследить связи, отбирая информацию по OU или сайтам.

AD Object Restore – в этой вклад-ке можно восстановить объекты Active Directory, без перехода в ре-жим восстановления AD. При этом объектам можно восстановить ста-рые пароли либо задать новые.

Client Side Troubleshooting – весь-ма удобная функция, позволяющая соединиться с клиентским компью-тером, позволяя, например, убе-диться в том, что новые политики применены правильно.

Active Directory Security – здесь показан список ваших серверов и контейнеров, а также выводят-ся пользователи или группы, име-ющие доступ к выбранным объек-там.

Active Templates – здесь создают-ся, редактируются и применяются Active Templates.

Active Directory Auditing – в этой вкладке просматриваются сооб-щения системы аудита, генериру-

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

Group Policy Objects – используя эту вкладку, можно просматривать, создавать, редактировать, вос-станавливать, добавлять к Offline Repository групповые политики.

ВыводНесмотря на то, что начальная на-стройка несколько непривычна, в том числе и из-за несколько неинтуитив-ного интерфейса, в дальнейшем Active Administrator оправдает свое приме-нение, а удобство работы окупит за-траченное на настройку время. На-личие таких возможностей, как Active Templates, Offline Repository, аудит и оповещение о событиях по e-mail, восстановление и прочее, делают его удобным инструментом при админис-трировании Active Directory. Также хо-чется отметить наличие довольно под-робной, в том числе и пошаговой доку-ментации на английском языке.

1. С а й т S c r i p t L o g i c , р а з р а б о т ч и -к а Ac t i ve Admin i s t ra to r – h t t p : / /www.scriptlogic.com.

2. Таблиц а с равн е ния во з мож но с -тей Active Administrator 4.0 и GPMC – http://www.scriptlogic.com/products/activeadmin/comparisonmatrix.asp.

22


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

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

Для того чтобы предложить прин-цип классификации, рассмотрим ос-новы сетевых технологий, в частнос-ти, иерархическую модель ISO OSI. Как известно, она делит сетевое вза-имодействие на семь уровней: Физический Канальный Сетевой Транспортный Сеансовый Уровень представлений Уровень приложений

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

В отличие от физического уровня канальный (в англоязычной литера-туре именующийся Data Link) гораздо

Как собирать сетевую статистику

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

Андрей Бирюков

23№10, октябрь 2006


более информативен. Его рассмотрим подробнее чуть позже.

Сбор статистики по сетевому и транспортному уровням – основ-ная тема этой сегодня, и большинство примеров будет связано именно с эти-ми уровнями.

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

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

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

SyslogСообщения Syslog являются средс-твом, с помощью которого устройс-

тво сообщает о состоянии запущен-ных процессов, служб и интерфейсов. Фактически те системные сообщения, создаваемые устройством (также име-нуемые логами, журналами событий), отправляемые на хост, на котором за-пущена служба Syslog, (в общем слу-чае это может быть машина, работа-ющая под управлением Linux), c кото-рого уже можно собирать статистику за определенный период. Эти сооб-щения могут быть как информацион-ные, так и сообщения об ошибках, все зависит от настройки протоколиро-вания на конкретном устройстве. Ка-кую статистику можно собрать с по-мощью Syslog?

Например, в случае если какой-ли-бо порт отключился и устройство по-теряло соединение с определенной се-тью. Еще одним примером использова-ния Syslog является журналирование списков доступа Access Lists. Спис-ки доступа определяют, каким хостам и подсетям разрешен доступ к опре-деленным ресурсам посредством за-данных протоколов через соответству-ющие порты. Хорошим тоном при пос-троении ACL является правило «все, что не разрешено, то запрещено». Ру-ководствуясь этим, ваш список досту-па должен содержать правило, кото-рое запрещает весь трафик, который не был разрешен (на некотором обору-довании, приоритет правил определя-ется их очередностью в списке, на дру-гом – присвоенным значением приоре-тизации). Возвращаясь к задаче сбо-ра статистики, отправляем информа-цию обо всех запрещенных пакетах, на службу syslog на специально выде-ленном для этого хосте. Причем мож-но протоколировать как сведения о па-кетах, шедших из Интернета во внут-реннюю сеть, так и наоборот. В пер-вом случае мы поможет соберем све-

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

Однако кроме сбора статисти-ки по запрещенным пакетам иногда имеет смысл собирать информацию и по разрешенным. Приведу пример. Предположим, при попытке отправить письмо из своей сети, внешнему поль-зователю, ваш почтовый сервер полу-чил сообщение об ошибке 550 (сер-вис недоступен) или 450 (сервис вре-менно недоступен), но при этом сер-вер получателя нормально пингует-ся. Это может означать, что ваш вне-шний IP-адрес попал в черные списки сетей, из которых идет рассылка не-желательной почты (спама). Сейчас нередко спам рассылается без ведо-ма владельца компьютера с помощью троянских программ, которые, зара-зив машину, превращают ее неболь-шой SMTP-сервер, c которого начина-ют автоматически рассылать спам во внешнюю сеть. Для того чтобы опре-делить зараженную рабочую станцию, достаточно просто посмотреть в фай-ле журнала Syslog, с какого узла бы-ли отправлены SMTP-сообщения на за-блокировавший сервер. Вообще лучше всего запретить соединения по 25 пор-ту всем узлам, кроме корпоративного почтового сервера, но, к сожалению, это, как правило, не делается, хотя следовало бы.

Данная служба использует прото-кол UDP, также она реализована прак-

Рисунок 1. Статистика, построенная с помощью MRTG

24


тически на всех моделях современно-го сетевого оборудования.

Служба SNMPДругое средство – это служба SNMP, которая позволяет не только получать информацию об устройстве, но и уп-равлять им. С его помощью можно по-лучать сведения о количестве полу-ченных и потерянных пакетов на ин-терфейсе, состоянии различных про-токолов динамической маршрутиза-ции. Но для более удобного визуаль-ного представления можно восполь-зоваться специальными приложе-ниями для сбора статистики с помо-щью SNMP. В качестве средства ви-зуализации статистики лучше все-го использовать программы MRTG [1] для Linux/FreeBSD (см. рис. 1), а в слу-чае Windows PRTG [2].

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

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

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

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

Запустить эти счетчики можно из консоли «Панель управления», да-лее «Администрирование» и «Произ-водительность». В этой консоли имеет-ся несколько средств для наблюдения за состоянием системы: «Системный монитор», «Журналы счетчиков», «Жур-налы трассировки» и «Оповещения».

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

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

«Оповещения» – это средство, поз-воляющее системе реагировать на оп-ределенные события. Например, в слу-чае если количество пакетов, посту-пивших на сетевой интерфейс в тече-ние текущего сеанса работы, превос-ходит определенное пороговое значе-ние, то можно сделать запись в журна-ле событий (Event Log), отправить со-общение по сети, запустить журнал производительности или приложе-ние. Это средство может быть полезно в случае, если на интерфейс поступает большое количество пакетов с ошибка-ми или неопознанных пакетов, в случае превышении порогового значения, на-пример 10000, можно отправлять сооб-щение на экран с указанием времени и даты, а также делать запись в жур-нал событий. С помощью этих опове-щений можно поставить в известность системного администратора, который сможет предотвратить возникновение проблем еще до их появления.

чать поиск источника трафика до то-го, как сеть окажется полностью не-работоспособной.

MRTGСледующей группой устройств, о ко-торой хотелось бы рассказать, явля-ются маршрутизаторы. По аналогии с коммутаторами, с маршрутизато-ров можно собирать статистику с по-мощью MRTG. Однако эти устройства выполняют также целый ряд функций сетевого уровня, которые могут пред-ставлять интерес для сбора статис-тики. Например, уже упоминавшиеся протоколы динамической маршрути-зации: RIP, OSPF, BGP. Все эти прото-колы работают на сетевом (L3) уровне и обрабатываются маршрутизатора-ми. Получить статистическую инфор-мацию по состоянию пакетов для оп-ределенного протокола маршрутиза-ции можно с помощью средств SNMP, обратившись к соответствующей вет-ке и применив базу MIB данного про-изводителя оборудования.

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

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

Рисунок 2. Результат работы счетчика производительности

25№10, октябрь 2006


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

Механизм действия такого сценария довольно прост, оригинальную версию можно найти в источнике [5]. Но я предлагаю его немного модифицировать, для того что-бы сделать пригодным для практического использова-ния. Для того чтобы автоматизировать процесс сбора све-дений, я буду собирать данные в документ формата Excel, в котором первая страница посвящена статистике по TCP, вторая – по UDP и третья – по IP. При этом получать будем следующие данные.

Для TCP: Connection Failures – счетчик неудачных соединений; Connection Active Connection Established – количество

активных соединений; Connection Passive – количество пассивных соедине-

ний; Connection Reset Segments Per Second – отброшено сег-

ментов за секунду; Segments Received Per Second – получено сегментов

за секунду; Segments Retransmited Per Second – транслировано сег-

ментов за секунду; Segments Sent Per Second – отправлено сегментов за се-

кунду.

Для UDP: Datagrams No Port Per Second – получено датаграмм

на неверный порт в секунду; Datagrams Per Second – отправлено датаграмм в секун-

ду; Datagrams Received Errors – получено с ошибками; Datagrams Received Per Second – датаграмм получено

в секунду.

Для IP: Datagrams Forwarded Per Second – датаграмм передано

за секунду; Datagrams Discarded – отклонено; Datagrams Received Header Errors – получено с ошибка-

ми в заголовке; Datagrams Received Per Second – датаграмм получено

за секунду; Datagrams Received Unknown port – получено на неиз-

вестный порт; Datagrams Sent Per Second – датаграмм отправлено

за секунду; Fragments Per Second – всего фрагментов (частей да-

таграмм) за секунду; Fragments Failures – фрагменты с ошибками; Fragments Datagrams Per Second – фрагменты датаграмм

за секунду; Fragments Reassembly Failures – неудачные попытки пе-

ресборки фрагментов; Fragments Created Per Second – создано фрагментов за

секунду;

Fragments Reassembly Per Second – фрагментов пере-собрано за секунду;

Fragments received Per Second – получено фрагментов за секунду.

Эта статистика нуждается в некотором пояснении. Для протокола TCP единицей измерения являются сег-менты, также здесь фигурируют соединения (Connections), так как данный протокол использует при работе установку соединения. Для UDP в контексте данного сценария еди-ницей измерения является датаграмма. А для протокола IP кроме датаграмм также учитываются и их фрагменты, что позволяет учитывать также статистику по обработке час-тей данных, передаваемых этим протоколом.

Следует отметить, что в источнике [5] также имеются примеры сценариев для сбора статистики по IPSec и по про-токолам IP телефонии. Так что при необходимости их тоже можно включить в приведенный далее сценарий.

Далее приведу пример сценария, выполняющего все эти действия с необходимыми комментариями.

Листинг 1. Сценарий, собирающий статистику по протоколам

strComputer = "." // используется локальная машинаSet objWMIService = GetObject("winmgmts:" ↵ & "{impersonationLevel=impersonate}!\\" ↵ & strComputer & "\root\cimv2")set objRefresher = ↵ CreateObject("WbemScripting.SWbemRefresher")// объекты, необходимые для запуска сценарияSet colItems = objRefresher.AddEnum _ (objWMIService, ↵ "Win32_PerfFormattedData_TCPIP_TCP").objectSet// объект, с помощью которого собираются данные по TCPSet colItems1 = objRefresher.AddEnum _ (objWMIService, ↵ "Win32_PerfFormattedData_TCPIP_UDP").objectSet// объект, с помощью которого собираются данные по UDPSet colItems2 = objRefresher.AddEnum _ (objWMIService, ↵ "Win32_PerfFormattedData_TCPIP_IP").objectSet// объект, с помощью которого собираются данные по IP

objRefresher.Refresh // обновление счетчиков

Const xlDiagonalDown = 5Const xlDiagonalUp = 6Const xlNone = -4142Const xlContinuous = 1Const xlThin = 4Const xlThick = 4Const xlEdgeLeft = 7Const xlEdgeTop = 8Const xlEdgeBottom = 9Const xlEdgeRight = 10Const xlInsideVertical = 11Const xlInsideHorizontal = 12Const xlAutomatic = -4105Const xlCenter = -4108Const ForReading = 1 Const ForWriting = 5// набор констант, необходимых для создания документа Excel

Set oE = CreateObject("Excel.Application")oE.Visible = falseoE.Workbooks.Add// создаем новый документ ExceloE.DisplayAlerts = False 'oE.Sheets(4).DeleteoE.DisplayAlerts = True // определяем количество страницSet s = oE.Sheets(1) s.Name = "Статистика по TCP" // название для первой страницы Set s1 = oE.Sheets(2) s1.Name = "Статистика по UDP"// название для второй страницы Set s2 = oE.Sheets(3)

26


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

Какие данные можно получить с его помощью? Напри-мер, количество IP-пакетов, пришедших на ошибочный порт, слишком большое соотношение с легитимными па-кетами может говорить о том, что какое-то приложение от-правляет свои пакеты не по адресу. То есть можно предпо-ложить, что какое-то приложение пытается выйти в Интер-нет, вопреки корпоративной политике безопасности. Воз-можно, это троян. Большое количество пакетов с ошиб-ками свидетельствует о наличии источника помех в се-ти (например, мощный электроприбор рядом с сетевым кабелем). Большое количество пассивных TCP-соедине-ний также не слишком хорошо сказывается на пропуск-ной способности сети.

Таким образом, приведенный WSH-сценарий может ока-зать помощь в поиске проблем на указанном хосте.

1. http://www.mrtg.org – описание и дистрибутив MRTG.2. h t t p : / / w w w . s e c u r i t y l a b . r u / s o f t w a r e / d o w n l o a d /

?page=267148&el=2596383&file=http://download2.paessler.com/download/prtg.zip – дистрибутив PRTG.

3. К. Пакет. Создание сетей удаленного доступа Cisco. Cisco Press.

4. D. Hucaby Building Cisco Multi Switching Networks. Cisco Press.5. ht tp : / /www.microsof t .com / technet /scr iptcenter /scr ipts /

default.mspx?mfr=true – коллекция WSH-сценариев для мони-торинга состояния сети.

s2.Name = "Статистика по IP" // название для третьей страницы// далее перечисляются названия столбцов s.Rows(1).RowHeight = 2 * s.StandardHeight s.Cells(1,1) = "Статистика по протоколу TCP" s.Cells(2,1) = "Время" s.Cells(2,2) = "Connection Failures" s.Cells(2,3) = "Connection Active" s.Cells(2,4) = "Connection Established" s.Cells(2,5) = "Connection Passive" s.Cells(2,6) = "Connection Reset" s.Cells(2,7) = "Segments Per Second" s.Cells(2,8) = "Segments Received Per Second" s.Cells(2,9) = "Segments Retransmited Per Second" s.Cells(2,10) = "Segments Sent Per Second" s.Columns("A:B").Columns.AutoFit With s.Range("A1:B1") .MergeCells = True .VerticalAlignment = xlCenter .HorizontalAlignment = xlCenter .Font.Size=14End Withs1.Rows(1).RowHeight = 2 * s1.StandardHeight s1.Cells(1,1) = "Статистика по протоколу UDP" s1.Cells(2,1) = "Время" s1.Cells(2,2) = "Datagrams No Port Per Second" s1.Cells(2,3) = "Datagrams Per Second" s1.Cells(2,4) = "Datagrams Received Errors" s1.Cells(2,5) = "Datagrams Received Per Second" s1.Columns("A:B").Columns.AutoFit With s1.Range("A1:B1") .MergeCells = True .VerticalAlignment = xlCenter .HorizontalAlignment = xlCenter .Font.Size=14End With

s2.Rows(1).RowHeight = 2 * s2.StandardHeight s2.Cells(1,1) = "Статистика по протоколу IP" s2.Cells(2,1) = "Время" s2.Cells(2,2) = "Datagrams Forwarded Per Second" s2.Cells(2,3) = "Datagrams Discarded" s2.Cells(2,4) = "Datagrams Received Header Errors" s2.Cells(2,5) = "Datagrams Received Per Second" s2.Cells(2,6) = "Datagrams Received Unknown port" s2.Cells(2,7) = "Datagrams Sent Per Second" s2.Cells(2,8) = "Fragments Per Second" s2.Cells(2,9) = "Fragments Failures" s2.Cells(2,10) = "Fragments Datagrams Per Second" s2.Cells(2,11) = "Fragments Reassembly Failures" s2.Cells(2,12) = "Fragments Created Per Second" s2.Cells(2,13) = "Fragments Reassembly Per Second" s2.Cells(2,14) = "Fragments received Per Second" s2.Columns("A:B").Columns.AutoFit With s2.Range("A1:B1") .MergeCells = True .VerticalAlignment = xlCenter .HorizontalAlignment = xlCenter .Font.Size=14End With// в данном цикле производится сбор статистических данныхf=3 // начинается заполнение с третьей строкиFor i = 1 to 5 // в данном примере пять итераций, в реальном сценарии// необходимо намного больше// каждый элемент для статистики по TCP For Each objItem in colItems // дата и времы занесения записи s.Cells(f,1)=Now s.Cells(f,2)=objItem.ConnectionFailures s.Cells(f,3)=objItem.ConnectionsActive s.Cells(f,4)=objItem.ConnectionsEstablished s.Cells(f,5)=objItem.ConnectionsPassive s.Cells(f,6)=objItem.ConnectionsReset s.Cells(f,7)=objItem.SegmentsPersec s.Cells(f,8)=objItem.SegmentsReceivedPersec s.Cells(f,9)= ↵ objItem.SegmentsRetransmittedPersec s.Cells(f,10)=objItem.SegmentsSentPersec Next // каждый элемент для статистики по UDP For Each objItem in colItems1 s1.Cells(f,1)=Now s1.Cells(f,2)=objItem.DatagramsNoPortPersec s1.Cells(f,3)=objItem.DatagramsPersec s1.Cells(f,4)=objItem.DatagramsReceivedErrors s1.Cells(f,5)=objItem.DatagramsReceivedPersec s1.Cells(f,6)=objItem.DatagramsSentPersec

Next // каждый элемент для статистики по IP For Each objItem in colItems2 s2.Cells(f,1)=Now s2.Cells(f,2)=objItem.DatagramsForwardedPersec s2.Cells(f,3)= ↵ objItem.DatagramsOutboundDiscarded s2.Cells(f,4)=objItem.DatagramsOutboundNoRoute s2.Cells(f,5)=objItem.DatagramsPersec s2.Cells(f,6)= ↵ objItem.DatagramsReceivedAddressErrors s2.Cells(f,7)= ↵ objItem.DatagramsReceivedDeliveredPersec s2.Cells(f,8)= ↵ objItem.DatagramsReceivedDiscarded s2.Cells(f,9)= ↵ objItem.DatagramsReceivedHeaderErrors s2.Cells(f,10)= ↵ objItem.DatagramsReceivedPersec s2.Cells(f,11)= ↵ objItem.DatagramsReceivedUnknownProtocol s2.Cells(f,12)=objItem.DatagramsSentPersec s2.Cells(f,13)=objItem.FragmentationFailures s2.Cells(f,14)= ↵ objItem.FragmentedDatagramsPersec s2.Cells(f,15)= ↵ objItem.FragmentsReassembledPersec s2.Cells(f,16)= ↵ objItem.FragmentsReceivedPersec Next WScript.Sleep 60000 // пауза на 60 секунд

objRefresher.Refreshf=f+1

Next

oE.DisplayAlerts = False// сохранение документа ExceloE.ActiveWorkbook.SaveAs "result"oE.DisplayAlerts = TrueoE.Quit ‘ закрытие Excel

27№10, октябрь 2006

bugtraq

Несколько уязвимостей в Cisco IOS VLAN Trunking ProtocolПрограмма: проверено на CISCO IOS 12.1(19).Опасность: Высокая.Описание: 1. Удаленный пользователь в локальном сег-менте сети может послать специально сформированный VTP-пакет 1-й версии с установленным полем VTP-вер-сии 2 к транк-порту, чтобы перезагрузить целевое устройс-тво с ошибкой «Software Forced Crash Exception».

2. Удаленный пользователь может послать VTP-пакет с Type-Length-Value-содержащим специально сформиро-ванное имя VLAN, длиннее 100 символов, к транк-порту, чтобы перезагрузить устройство с ошибкой «Unassigned Exception». В результате можно выполнить произвольный код на целевом устройстве.

3. Атакующий может послать VTP updates (summary или sub) к CISCO IOS или CatOS устройству и выбрать VTP-ре-дакцию 0x7FFFFFFF. Когда VLAN-конфигурация измене-на оператором, IOS увеличивает редакцию, которая ста-нет как 0x80000000 и запишется во внутреннюю перемен-ную как целое со знаком. В результате редакция становит-ся больше, чем самое большое отрицательное значение. После этого коммутатор не сможет сообщить измененную конфигурацию VLAN, так как произведенные обновления будут отвергнуты всеми другими коммутаторами.

Уязвимы коммутаторы Cisco Catalyst, работающие на Cisco IOS с VTP Operating Mode, установленным как «server» или «client».

Cisco Catalyst-коммутаторы, работающие на Cisco CatOS с VTP Operating Mode, установленные как «server» или «client», уязвимы к третьей уязвимости.

Коммутаторы с VTP Operating Mode, установленные как «transparent», не уязвимы (это значение по умолча-нию).URL производителя: http://www.cisco.com.Решение: Установите соответствующее обновление.

Обход ограничений безопасности в Cisco IOSПрограмма: Cisco IOS 12.2(15)MC2 с установленным обра-зом MWR1900-I-M, Cisco IAD2430 Integrated Access Device, Cisco IAD2431 Integrated Access Device, Cisco IAD2432 Integrated Access Device, Cisco VG224 Analog Phone Gateway, Cisco MWR 1900 Mobile Wireless Edge Router, Cisco MWR 1941 Mobile Wireless Edge Router.Опасность: Высокая.Описание: Уязвимость существует из-за наличия неиз-меняемой community-строки cable-docsis на устройствах с поддержкой DOCSIS (Data Over Cable Service Interface Specification) интерфейсов. Если на устройстве запущен SNMP-сервис, злоумышленник может получить полный контроль над устройством.URL производителя: http://www.cisco.com.Решение: Установите исправление с сайта производи-теля.

Отказ в обслуживании в ISC BINDПрограмма: ISC BIND 9.2.x, 9.3.x.Опасность: Средняя.Описание: 1. Уязвимость существует при обработке SIG-запросов. Удаленный пользователь может аварийно за-вершить работу рекурсивного сервера, если возвращает-ся более чем один SIG RRset, либо завершить работу до-веренного сервера, обслуживающего RFC 2535 DNSSEC-зоны, если ответ содержит большое количество SIG RRset-записей.

2. Уязвимость существует при обработке большого коли-чества рекурсивных запросов. Злоумышленник может вы-звать ошибку INSIST и вызвать отказ в обслуживании.URL производителя: http://www.isc.org.Решение: Установите последнюю версию (BIND 9.3.3rc2, BIND 9.3.2-P1, BIND 9.2.7rc1 или BIND 9.2.6-P1) с сайта про-изводителя.


Переполнение буфера при обработке некоторых команд в WS_FTP ServerПрограмма: WS_FTP Server 5.05, возможно, более ран-ние версии.Опасность: Средняя.Описание: Уязвимость существует из-за ошибки проверки границ данных при обработке аргументов, передаваемых командам XCRC, XSHA1 и XMD5. Удаленный пользователь может с помощью слишком длинного аргумента команды вызвать переполнение стека и выполнить произвольный код на целевой системе.URL производителя: http://www.ipswitch.com/products/ws_ftp-server.Решение: Установите исправление с сайта производи-теля.

Несколько уязвимостей в Cisco IPS/IDSПрограмма: Cisco Guard Appliance (Software Version 3.X), Cisco Guard Blade (Software Version 4.X), Cisco Guard Appliance (Software Version 5.0(3)), Cisco Guard Appliance (Software Version 5.1(5)).Опасность: Средняя.Описание: 1. Уязвимость существует в административном веб-интерфейсе из-за ошибки при обработке SSLv2-паке-тов. Удаленный пользователь может с помощью специаль-но сформированного SSLv2 Client Hello-пакета аварийно завершить работу процесса mainApp, что не позволит бо-лее принимать запросы на управление приложением, но не повлияет на процесс проверки трафика.

2. Уязвимость существует из-за ошибки при обработ-ке фрагментированных IP-пакетов. Удаленный пользова-тель может послать устройству специально сформирован-ную последовательность фрагментированных IP-пакетов и вызвать отказ в обслуживании устройства, запущенного в режимах inline или promiscuous.URL производителя: http://www.cisco.com.Решение: Установите исправленные версии (4.1(5c), 5.0(6p2), 5.1(2)) с сайта производителя.

28


Почему OpenLDAP?OpenLDAP – бесплатный сервер катало-гов, который содержится в большинс-тве дистрибутивов Linux и FreeBSD. Он обладает достаточной функци-ональностью и полностью совмес-тим с Outlook Express, Mozilla и Mozilla Thunderbird.

Почему PostgreSQL?PostgreSQL – достаточно известный сервер баз данных. Обладает хоро-шим быстродействием, надёжнос-тью и многофункционален. В отли-чие от MySQL он поддерживает спе-цификацию ANSI SQL 92, что без осо-бых усилий позволяет перенести ба-зы данных, написанные на PostgreSQL, в такие коммерческие продукты, как Oracle и MSSQL, а также облада-ет широким набором дополнитель-ных возможностей (правила, тригге-ры, встроенные языки). Продукт 1С

Бухгалтерия v. 8.1 был полностью ре-ализован на PostgreSQL. Использо-вание PostgreSQL в данном приме-ре ярко иллюстрирует часть его воз-можностей.

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

OpenLDAP осуществляет взаимо-действие с PostgreSQL через источ-ники данных UnixODBC, что позволя-ет использовать другие серверы баз данных (MySQL, MSSQL, Oracle и т. д.). Все поля из таблицы будут отобра-жаться в таких почтовых клиентах, как Outlook Express, Mozilla Thunderbird и просто Mozilla. Итак, приступим.

Установка и настройка OpenLDAPДля успешной сборки OpenLDAP уста-новим unixODBC-2.2.11.

Создаем адресную книгу на базе OpenLDAP

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

Сергей Алаев

Наименование поля

Имя

Фамилия

ФИО (полностью)

Электронная почта

Домашний телефон

Рабочий телефон

Мобильный телефон

Должность

Название отдела

Название организации (частная компания)

Факс

Пейджер (ICQ, Yahoo и т. д.)

Домашний адрес

Рабочий адрес

Почтовый индекс

Структура адресной книги

29№10, октябрь 2006


Собираем из портов:

Приступаем к установке самого пакета OpenLDAP:

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

рационный файл стоят права владельца на пользователя ldap. В противном случае задайте права на главный кон-фигурационный файл:

Правим главный конфигурационный файл:

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

Для доступа к PostgreSQL:

Для того чтобы не переписывать длинный кодирован-ный пароль, в конце данных команд можно поставить пере-направление вывода на конфиг в конец файла (>>/usr/local/openldap/etc/slapd.conf), а потом отредактировать.

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

Запускаем сервер после установки PostreSQL.Для автоматического запуска OpenLDAP при загрузке

правим rc.conf:

Базовая настройка сервера каталогов закончена.

Установка и настройка PostgreSQLPostgreSQL – мощный сервер баз данных, предназначен-ный для бесплатного использования в рамках лицензии BSD. Он входит в состав большинства дистрибутивов Linux и FreeBSD.

Собираем PostgreSQL из портов:

Создадим каталог для размещения баз данных с пра-вами на pgsql:

Возможно, вам придётся установить утилиту sudo в раз-

# cd /usr/ports/databases/unixODBC# make && make install

# cd /usr/ports/databases/openldap23-client# make && make install# cd ../openldap23-server# make WITH_ODBC=YES WITH_ODBC_TYPE=unixodbc # make install

# chown ldap:ldap /usr/local/etc/openldap/slapd.conf

# mcedit /usr/local/etc/openldap/slapd.conf

# Подключаем необходимые схемыinclude /usr/local/etc/openldap/schema/core.schemainclude /usr/local/etc/openldap/schema/cosine.schemainclude /usr/local/etc/openldap/schema/ ↵ inetorgperson.schema

#Указываем путь для файлов pid и args

pidfile /var/run/openldap/slapd.pidargsfile /var/run/openldap/slapd.args

# Определяем порядок доступа к сущностям# Разрешаем доступ к службе каталогов LDAP только# авторизированным пользователямaccess to * by users read by self read by anonymous auth# Путь к модулю sqlmodulepath /usr/local/libexec/openldapmoduleload back_sql.so########################################################## sql database definitions########################################################## Определяем настройки для соединения с PostgreSQL-серверомdatabase sqlsuffix "o=myorg"rootdn "cn=root,o=myorg"rootpw {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==# Имя источника данныхdbname PostgreSQL# Имя пользователя для соединения с PostgreSQLdbuser ldap# Пароль для данного пользователяdbpasswd {MD5}4QrcOUm6Wau+VuBX8g+IPg==insentry_stmt "insert into ldap_entries ↵ (id,dn,oc_map_id,parent,keyval) ↵ values ((select ↵ nextval('ldap_entries_id_seq')),?,?,?,?)"upper_func "upper"strcast_func "text"concat_pattern "?||?"has_ldapinfo_dn_ru no# При использовании модуля sql-индексы указывать не нужно# Поиск автоматически можно вести по всем атрибутам,# используемым в LDAP-дереве

# slappasswd –h {MD5} –s 123456

# slappasswd –h {MD5} –s secret

# /usr/local/etc/rc.d/slapd.sh start stop restart status

# mcedit /etc/rc.conf

slapd_enable="YES"slapd_flags="-u ldap –g ldap –h ldap://192.168.7.1"

# cd /usr/ports/databases/postgresql80-client# make && make install# cd /usr/ports/databases/postgresql80-server# make && make install

# cd /var/db# mkdir pgsql# chmod 700 pgsql && chown pgsql:pgsql pgsql# /usr/local/bin/sudo –u pgsql /usr/local/bin/initdb ↵ –-username=pgsql –-pgdata=/var/db/pgsql

Рисунок 1. Пример добавления пользователя

30


деле security общего дерева портов. После установки не за-будьте разрешить root запускать команды для пользователя pgsql. Для этого необходимо отредактировать sudoers:

Данная строка разрешает root запускать команды для пользо-вателя pgsql. После создания первичных баз в целях безопас-ности данную строку можно закомментировать или удалить.

Для автоматического запуска сервера при загрузке сис-темы правим rc.conf:

Далее правим главный конфигурационный файл, где указываем IP, на котором будет работать сервер:

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

Для запуска PostgreSQL выполните команду:

Настройка UnixODBCДля настройки UnixODBC необходимо создать два файла следующего содержания:

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

Здесь содержится информация, используемая для до-ступа к PosgreSQL. Имя пользователя и пароль мы указа-ли в главном конфигурационном файле slapd.conf, поэто-му здесь эти данные можно не указывать

Создание базы данных PostgreSQL хранения сущностей LDAPПрежде всего необходимо определиться со структурой LDAP-дерева. В корне каталогов будет находиться контей-нер o=myorg, в котором будут содержаться два контейне-ра. В первом ou=users,o=myorg будет храниться информа-ция о пользователях, которые будут иметь доступ к серве-ру каталогов(например, cn=ivan ivanov,ou=users,o=myorg). Во втором ou=myaddressbook,o=myorg будут храниться за-писи о сотрудниках.

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

Далее создаём пользователя ldap:

Теперь создадим базу данных для данной адресной книги:

В данном случае очень важно использовать коди-ровку UNICODE, т.к. OpenLDAP будет добавлять дан-ные, содержащие русские символы в юникодной коди-ровке, а не SQL-ASCII. Использование данной кодиров-ки в базе данных позволит корректно отображать симво-лы на русском при непосредственном доступе к таблицам PostgreSQL. Отсоединяемся и создаем таблицы под новым пользователем ldap к вновь созданной базе ldap:

# mcedit /var/db/pgsql/postgresql.conf

listen_addresses='localhost'

tcpip_socket = truevirtual_host = '127.0.0.1'

# /usr/local/etc/rc.d/010.pgsql.sh start

# mcedit /usr/local/etc/odbcinst.ini

[PostgreSQL]Description = PostgreSQL driver for Linux & Win32Driver = /usr/local/lib/libodbcpsql.soSetup = /usr/local/lib/libodbcpsqlS.soFileUsage = 1

# mcedit /usr/local/etc/odbc.ini

[PostgreSQL]Description = Test to PostgresDriver = PostgreSQLTrace = YesTraceFile = sql.logDatabase = ldapServername = 127.0.0.1UserName = Password = Port = 5432Protocol = 6.4ReadOnly = NoRowVersioning = NoShowSystemTables = NoShowOidColumn = NoFakeOidIndex = NoConnSettings =

# psql –h 127.0.0.1 -d template1 -U pgsql

template1=# CREATE USER ldap WITH SYSID 100 PASSWORD '123456' NOCREATEDB NOCREATEUSER;

template1=# CREATE DATABASE ldap WITH OWNER = ↵ ldap ENCODING = 'UNICODE';

Рисунок 2. Пример добавления данных о сотруднике

# mcedit /usr/local/etc/sudoers

root ALL=(pgsql) ALL

# mcedit /etc/rc.conf

postgresql_enable="YES"postgresql_user="pgsql"postgresql_data="/var/db/pgsql"

31№10, октябрь 2006


Данный SQL-скрипт автоматически создаст таблицы для хранения сущностей.

Перезапускаем систему. После авторизации выпол-няем:

На что он должен выдать список всех сервисов, которые слушают на IPv.4, среди которых должны быть PostgreSQL и slapd, что свидетельствует об успешно выполненных на-стройках.

Установка и настройка PHPLdapAdminДоступ к нему осуществляется через сервер Apache. Для нормальной работы phpldapadmin никаких особых настроек PHP не требуется, нужна только поддержка OpenLDAP, поэтому если уже имеется настроенный PHP, то просто добавьте модуль ldap, и этого будет достаточно. Собираем PHPLdapAdmin из портов:

Для запуска Apache выполняем:

Переходим к настройке PHPLdapAdmin:

Для подключения к LDAP-серверу имя пользователя и пароль мы будем вводить в самом интерфейсе. Хост не-обходимо указать в данном файле.

В браузере заходим на http://192.168.7.1/phpldapadmin/.

Создание адресной книгиПриступаем к созданию адресной книги. Для автори-зации нажимаем «ВХОД». В качестве логина вводим cn=root,o=myorg, в качестве пароля – secret. Для создания главного контейнера выбираем «IMPORT», и далее в текс-товом поле «Paste your LDIF here» введите следующее:

Переходим к созданию контейнера, содержащего ин-формацию о пользователях, которым разрешено пользо-ваться сервером каталогов. Выделите контейнер o=myorg и кликните «Создать потомка». В качестве шаблона выбе-рите «Organisational Unit» и введите название контейнера -users. Создадим учётную запись для доступа к серверу ка-талогов. В контейнере ou=users,o=myorg кликните «Создать потомка» и в качестве шаблона укажите «User Account», и заполните данные. В качестве uid можно вводить поряд-ковый номер пользователя (рис. 1).

Создадим контейнер для хранения записей о сотруд-никах. Для этого в контейнере o=myorg создайте контей-нер ou=address_book по тому же принципу, что и ou=users. Для добавления записей о сотрудниках создайте в контей-нере ou=addressbook,o=myorg потомка, указав в качестве шаблона Address Book Entry (mozillaOrgPerson). И далее за-полняйте данные на русском (рис. 2). После чего нажми-те «proceed» для создания объекта. Вот таким образом до-бавляются данные. OpenLDAP автоматически размещает их в SQL-таблицах. С помощью интерактивного клиента pgadmin вы можете посмотреть данные в таблицах.

Настройка Outlook Express на использование адресной книгиПереходим к настройке Outlook Express. Для добавления сервера каталогов в меню «Сервис → Учётные записи» вы-

бираем «Добавить → Служба каталогов». В качестве имени укажите 192.168.7.1.

Потом зайдите в свойства и на вкладке «Общие» в поле «Учётная запись» введи-те «Моя адресная книга». Установите гал-ку «Требуется вход на сервер» в состояние включено.

В качестве учётной записи введите cn=ivan ivanov,ou=users,o=myorg и укажите пароль, который вы вводили при создании данного пользователя.

Переходим на вкладку «Дополнитель-но» и в поле «Основа поиска» укажите ou=myaddressbook,o=myorg.

Теперь можно выполнять поиск в адрес-ной книге по любым критериям. Кликни-те кнопку «Адреса», далее «Поиск людей» и введите критерии поиска.

Пример поиска показан на рис. 3. Вот и всё в принципе.Удачи!

# psql –h 127.0.0.1 –d ldap –U ldap –p 5432 ↵ –W < /usr/local/scripts/main.sql

# sockstat -4

# cd /usr/ports/net/phpldapadmin# make && make install

# cd /usr/local/www/phpldapadmin/config# mv config.php.example config.php

# apachectl start

# mcedit config.php

$ldapservers->SetValue($i,'server','host','192.168.7.1');

dn: o=myorgobjectclass: organizationo: myorg

Рисунок 3. Пример поиска контактной информации сотрудника в адресной книге

32


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

тей многим системным администрато-рам приходится сталкиваться с зада-чами, связанными с созданием ресур-сов для широкого пользования. С уве-личением объема таких ресурсов, на-ходящихся в руках одного админист-ратора, растет сложность администри-рования и, как правило, страдает бе-зопасность. Встают вопросы частич-ного делегирования административ-ных полномочий. Техники VPS (Virtual Private Server) и VDS (Virtual Dedicated Server) позволяют решать такие за-дачи – задачи «эффективного раз-деления целого на меньшее». В отли-чие от других небезызвестных техно-логий, таких как VMWare и Xen, VPS предоставляет минимальную виртуа-лизацию. Подробнее различные виды виртуализации описаны здесь: http://en.wikipedia.org/wiki/Virtualization.

В этой статье рассматривается технология Linux-VServer (http://linux-vserver.org). Описываются основные возможности, а также вы найдете инс-трукции по установке программного обеспечения, и настройке виртуаль-ных серверов.

Основные возможностиТехнология Linux-VServer позволяет со-здавать несколько виртуальных сер-веров (VPS), работающих независи-мо под управлением одного ядра опе-рационной системы.

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

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

VPS внутри выглядит как полноцен-ная Linux-система. Вы можете предо-ставить права root на него и совершен-но не бояться, что как-то могут быть повреждены другие виртуальные сер-веры или главный сервер. Все серви-сы, такие как электронная почта, ба-зы данных, Web, SSH, могут быть за-пущены без модификаций (или с не-которыми минимальными модифика-циями) на виртуальном сервере (спи-сок программ, с которыми возникают проблемы, вы можете можете просмот-реть здесь: http://wiki.linux-vserver.org/ProblematicPrograms). Каждый VPS мо-жет обладать как одним IP-адресом, так и несколькими.

Linux-VServer: настраиваем виртуальные серверы

Дмитрий Столяров

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

33№10, октябрь 2006


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

дескрипторов (файлов). Объем физической и виртуальной памяти. Доля использования мощности процессора и список

процессоров, на которых может выполняться VPS. Максимальное количество процессов, принадлежащих

контексту.

Для каждого VPS могут отслеживаться такие показа-тели, как: Использованное процессорное время. Количество совершенных системных вызовов fork (с его

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

тов.

Программное обеспечение Операционная система GNU/Linux; Linux-ядро 2.6.17

(http://kernel.org). Linux-VServer Kernel Patches 2.0.21 (http://wiki.linux-vserver.

org/Downloads). Linux-VServer Userspace Utilities 0.30.210 (http://wiki.linux-

vserver.org/Downloads).

Также потребуется образ, который будет использовать-ся на VPS. Вот некоторый список архивов, содержащих го-товые образы: http://mirrors.sandino.net/vserver/images; http://debian.marlow.dk/vserver/guest; http://www.fumanchu.com/vserver; http://lylix.net/vps+templates/func,select/id,1; http://distfiles.gentoo.org/experimental/x86/vserver; http://distfiles.gentoo.org/experimental/amd64/vserver.

Отличается такой образ от полноценной Linux-системы обычно измененными скриптами инициализации, а в осо-бенности – скриптами, направленными на проверку целос-тности корневой файловой системы и т. п.

Разумеется, никто не отменяет возможности самосто-ятельного создания образа на основе используемого ва-ми дистрибутива.

Установка поддержки Linux-VServer в ядреСкачаем ядро, разархивируем его и добавим патч:

После того, как вы примените патч к ядру, в меню кон-фигурации появится новая секция «Linux-VServer», ей мы и уделим внимание.

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

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

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

Опция, отвечающая за возможность жесткого управле-ния процессами. Если VPS превысил свой лимит процес-сорной мощности и для него установлено жесткое управ-ление, выполнение процессов контекста будет замороже-но на некоторый промежуток времени (подробнее смотреть «Ограничение ресурсов»):

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

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

Опция отвечает за поддержку встроенного в ядро NFS демона:

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

Устанавливаем программное обеспечение для управления VPSДля работы утилит нам понадобится программа vconfig (http://www.candelatech.com/~greear/vlan.html).

Скачаем и разархивируем утилиты:

# wget http://www.kernel.org/pub/linux/kernel/v2.6 ↵ /linux-2.6.17.13.tar.bz2# wget http://ftp.linux-vserver.org/pub/kernel/vs2.0 ↵ /patch-2.6.17.13-vs2.0.2.1.diff.bz2# tar -xjf linux-2.6.17.13.tar.bz2# bunzip2 patch-2.6.17.13-vs2.0.2.1.diff.bz2# cd linux-2.6.17.13# patch -p1 < ../patch-2.6.17.13-vs2.0.2.1.diff# make menuconfig

Linux-VServer -> Show a Legacy Version Number (VSERVER_LEGACY_VERSION=n)Linux-VServer -> Enable Legacy Kernel API (VSERVER_LEGACY=n)

Linux-VServer -> Enable Proc Security (VSERVER_PROC_SECURE=y)

Linux-VServer -> Disable Legacy Networking Kernel API (CONFIG_VSERVER_NGNET=n)

Linux-VServer -> Enable Hard CPU Limits (VSERVER_HARDCPU=y)

Linux-VServer -> Limit The IDLE task (VSERVER_HARDCPU_IDLE)

Linux-VServer -> Persistent Inode Context Tagging -> UID24/GID24 (INOXID_UGID24=y)

Linux-VServer -> Tag NFSD User Auth and Files (XID_TAG_NFSD=n)

# make bzImage modules modules_install install

34


Конфигурацию производим следующим образом:

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

Компилируем и устанавливаем:

Дополним переменные окружения новыми путями (это лучше прописать, например, в bashrc):

Настроим файловую систему, в которой будут распо-лагаться виртуальные серверы (в ней будет находиться vrootdir, в нашем случае – /var/vservers).

При монтировании нам нужно обязательно указать оп-цию «tagxid»: она включает установку принадлежности фай-лов конкретному VPS (см. «Ядро: Linux-VServer -> Persistent Inode Context Tagging»).

Также, если вы используете reiserfs, вам понадобит-ся опция «attrs», включающая поддержку атрибутов фай-ла (chattr, lsattr) (проверьте, включена ли в ядре опция REISERFS_FS_XATTR, при использовании reiserfs).

Монтирование производится следующим образом:

Или, в случае fstab, это будет строчка вида:

В этом примере монтирование производится в дирек-торию /var, это не обязательно.

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

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

Для продолжения понадобится выполнить команду, де-лающую видимыми для самого сервера некоторые час-ти /proc (см. «Ядро: Linux-VServer -> Enable Proc Security»). Полезно добавить эту команду к скриптам инициализа-ции системы.

Для того чтобы перезагрузка и выключение виртуаль-

ных серверов обрабатывались корректно, потребуется сде-лать следующее:

Следующая команда должна вывести информацию о версии Linux-VServer API в ядре и версии утилит. Если она делает это, то установка прошла успешно.

Создание VPSДля начала нужен образ VPS. Мы выберем для себя образ на основе Gentoo. Скачаем и распакуем его:

Если вы используете не Gentoo в качестве дистри-бутива для главного сервера, вам понадобится скачать и установить дерево портежей (это дерево можно мож-но монтировать к нескольким VPS для совместного ис-пользования):

Создадим базовую конфигурацию для нашего ново-го VPS:

Рассмотрим параметры команды: testvps – имя виртуального сервера. -m skeleton – метод, означающий, что надо создать

только конфигурационные файлы. --context 5 – идентификатор контекста. --initstyle plain – стиль загрузки (http://oldwiki.linux-

vserver.org/InitStyles).

После выполнения команды для нового сервера созда-на конфигурация в /usr/local/vserver/etc/vservers/testvps, зай-дем в эту директорию.

Скопируем файловую систему нашего будущего VPS:

Дополним fstab следующим образом:

Первая строчка монтирует «дерево портежей» в режи-ме «только чтение», вторая – директорию, содержащую ар-

# mount /dev/sda2 /var/ -o tagxid,attrs

/dev/sda2 /var reiserfs tagxid,attrs 1 1

# mkdir /var/vservers# /usr/local/vserver/sbin/setattr --barrier /var/vservers/

# /usr/local/vserver/etc/init.d/vprocunhide start

# echo 'kernel.vshelper =/usr/local/vserver/lib ↵ /util-vserver/vshelper' >> /etc/sysctl.conf# sysctl -p

# vserver-info

# wget http://distfiles.gentoo.org/experimental/x86/ ↵ vserver/stage3-i686-20060317.tar.bz2# mkdir /usr/src/stage3-vserver# tar -xjf stage3-i686-20060317.tar.bz2 -C /usr/src/ ↵ stage3-vserver# mkdir /usr/src/stage3-vserver/usr/portage

# wget http://distfiles.gentoo.org/snapshots/ ↵ portage-latest.tar.bz2# tar -xjf portage-latest.tar.bz2 -C /usr

# vserver testvps build -m skeleton --context 5 ↵ --initstyle plain

# cp /usr/src/stage3-vserver/* /var/vservers/testvps/ -pPR

# cat >> /usr/local/vserver/etc/vservers/testvps/fstab

/usr/portage /usr/portage none bind,ro 0 0/usr/portage/distfiles /usr/portage/distfiles ↵ none bind,rw 0 0

# wget http://ftp.linux-vserver.org/pub/utils/ ↵ util-vserver/util-vserver-0.30.210.tar.bz2# tar -xjf util-vserver-0.30.210.tar.bz2# cd util-vserver-0.30.210

# ./configure --prefix=/usr/local/vserver ↵ –with-vrootdir=/var/vservers

# make# make install

# PATH=$PATH:/usr/local/vserver/sbin# MANPATH=$MANPATH:/usr/local/vserver/man

35№10, октябрь 2006


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

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

Посмотрим информацию о запущенных серверах:

Обратите внимание, что главный сервер представляет-ся как VPS с номером 0 и именем «root server».

Для входа в консоль VPS можно использовать следу-ющую команду:

Настройка сети в VPSПрежде всего перейдем в каталог с конфигурацией ин-терфейсов виртуального сервера и создадим директорию для первого интерфейса:

Установим имя устройства, к которому будет присоеди-нен IP-адрес нашего VPS:

Укажем псевдоним устройства, создаваемого при ини-циализации VPS:

Настроим IP-адрес и маску сети:

Перезагрузим VPS:

Для того чтобы посмотреть получившийся результат, воспользуемся командой ip (входит в iproute2: http://linux-net.osdl.org/index.php/Iproute2).

На экране мы увидим:

Обратите внимание, что полное имя устройства ви-да <имя>:<псевдоним> не может быть в длину больше 15 символов.

В VPS можно увидеть результат:

Выход из консоли VPS осуществляется стандартно: ком-бинацией клавиш <Ctrl+D> или командой logout.

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

Архитектурные рекомендацииНаиболее востребованной технология VPS оказалась для создания хостинговых решений. Большую актуальность она имеет и в образовательной среде, так как предостав-ляет возможность без последствий давать привилегии су-перпользователя (root). А как без них обучить админист-рированию?

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

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

Приватный IP + Port Forwarding (DNAT)Этот вариант очень удобен, когда вы хотите предоставить доступ к одному или нескольким сервисам, запущенным на VPS, например, для администрирования.

VPS-серверам выделяются IP-адреса из приватного диа-пазона некоторой виртуальной сети. Для нужных сервисов на VPS-серверы пробрасываются порты с публичных IP-ад-ресов, привязанных к самому серверу. Таким образом, об-ращаясь на один и тот же IP-адрес, например, по портам 21 (FTP) и 80 (HTTP), мы можем в действительности обра-щаться к разным VPS.

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

Приватный IP + VPNТак же, как и в предыдущем варианте, VPS назначаются приватные IP-адреса. В получившуюся приватную сеть ор-ганизовывается VPN-доступ с использованием, например, PPTP или OpenVPN, или IPSec.

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

# vserver testvps start

# vserver-stat

CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME0 106 1.6G 744.4M 36m41s10 6m39s70 17h45m58 root server5 1 1.4M 492K 0m00s21 0m00s13 0m00s75 testvps

# vserver testvps enter

# cd /usr/local/vserver/etc/vservers/testvps/interfaces# mkdir 0# cd 0/

# echo 'eth0' > dev

# echo 'testvps' > name

# echo '192.168.0.2' > ip# echo '24' > prefix

# vserver testvps restart

# ip addr | grep 192.168.0.1

inet 192.168.0.2/24 brd 192.168.0.255 scope global eth0:testvps

# vserver testvps enter # ifconfig

36


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

Приватный IP + HTTP-проксиНа главном сервере или на одном из VPS с публичным IP-адресом мы запускаем реверсный HTTP-прокси-сервер, перенаправляющий, в зависимости от доменного име-ни, запросы внутрь виртуальной сети на нужные VPS. Та-ким образом, через 80 порт на одном публичном IP мы мо-жем предоставлять HTTP-доступ к сайтам, расположен-ным на разных VPS. В качестве реверсного прокси-серве-ра прекрасно подходит продукт российского производства nginx (http://sysoev.ru).

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

Настройка ограничений дискового пространстваДля настройки перейдем в директорию с конфигурацией VPS и создадим там каталог:

Укажем директорию, для которой мы устанавливаем ограничения:

Ограничим количество индексных дескрипторов фай-лов:

Ограничим пятью гигабайтами место, доступное VPS:

Установим процент от общего размера, резервируемый для пользователя root.

После этого перезагрузим VPS, войдем в него и посмот-рим, что получилось:

Так как для файлов образа не установлен идентифи-катор контекста (XID), место на диске, занимаемое ими, не учитывается. Если вы хотите, чтобы и оно учитывалось, можно сделать следующее:

Входим и проверяем:

Настройка ограничений ресурсовПерейдем в директорию с конфигурацией виртуального сервера:

Существуют следующие ресурсы: cpu, fsize, data, stack, core, rss, nproc, nofile, memlock, as, locks. Более подробно о типах ресурсов можно прочитать в man setrlimit.

В директории создаются файлы с именами <имя ресурса>.min, <имя ресурса>.soft, <имя ресурса>.hard, в которых и определяются конкретные ограничения для ресурсов.

В файле /usr/local/vserver/etc/vservers/testvps/flags вы можете установить флаги, рассмотрим некоторые часто используемые: virt_uptime – показывать внутри VPS время работы вир-

туального сервера. virt_load – показывать индикатор загрузки VPS,

а не главного сервера. sched_hard – указывает планировщику замораживать

процесс, если он превысил лимит мощности процессо-ра.

sched_prio – указывает планировщику понижать при-оритет процесса, если он превысил лимит процессора.

fork_rss – запрещать системный вызов fork, если пре-вышен rlimit rss.

В файле /usr/local/vserver/etc/vservers/schedule вы мо-жете установить параметры планировщика. Например, для того чтобы VPS выделялось 7/32 (21.9%) каждого про-цесса, а в случае превышения он приостанавливался на (200/7)*32=928 так называемых «мгновений» (jiffies), нуж-но создать файл следующего содержания:

928 jiffies – это порядка одной секунды, если частота тай-мера равна 1000 Гц и примерно десять секунд, если час-тота равна 100 Гц (частота таймера в конфигурации ядра: «Processor type and features -> Timer frequency»).

Управление планировщиком находится в стадии разра-ботки и может измениться.

Более подробно об этих и многих других настройках вы можете прочитать в документации на официальном сайте: http://wiki.linux-vserver.org/VServerConfiguration.

# cd /usr/local/vserver/etc/vservers/testvps/# mkdir dlimits# mkdir dlimits/0# cd dlimits/0

# echo '/var/vservers/testvps' > directory

# echo '100000' > inodes_total

# echo '5242880' > space_total

# echo '5' > reserved

# df -h

/dev/hdv1 5,0G 0 4,8G 0% /

# vserver testvps stop# chxid -c 5 -R /var/vservers/testvps# vserver testvps start

# df -h

/dev/hdv1 5,0G 503M 4,3G 11% /

# cd /usr/local/vserver/etc/vservers/testvps/# mkdir rlimits# cd rlimits

7325002001000string

38

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

Общие свойства SASLПреимущества протокола Kerberos – сильная криптографическая защи-та паролей и данных, единая система управления паролями пользователей и возможность реализации single sign-on-системы (система единой регист-рации пользователей). Основной не-достаток – сложная программная реа-лизация механизма аутентификации. Для того чтобы протокол, точнее, сер-вис и клиентское приложение, исполь-зовали аутентификацию пользовате-лей через Kerberos, соответствующий код должен быть реализован как в кли-ентской, так и серверной частях прото-кола. Поэтому, если вы попытаетесь ор-ганизовать single sign-on-систему, вам

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

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

тевых протоколов – SMTP, IMAP и/или POP3, их конфиденциальности и за-щиты от несанкционированного до-ступа. В принципе способов добиться решения этой задачи может быть не-сколько (см., например, [1, 2, 3, 4]), но решение с помощью Kerberos пред-ставляется мне наиболее простым и удобным. Удобство в данном случае подразумевает не только простоту ад-министрирования, но и удобство поль-зователей, которые получают единооб-разный способ доступа к протоколам чтения и отправки почты на основании своего системного пароля как изнутри, так и извне локальной сети (в послед-нем случае есть некоторые оговорки). Немаловажным обстоятельством яв-


С помощью библиотеки SASL сетевые приложения могут автоматически договориться об использовании определенного механизма подтверждения идентичности пользователя. Как осуществить взаимодействие библиотеки SASL c Kerberos?

Михаил Кондрин

39№10, октябрь 2006


ляется и то, что Kerberos – хорошо мас-штабируемый протокол, который раз-рабатывался в расчете на огромные университетские сети.

Ключевой элемент, обеспечиваю-щий взаимодействие Kerberos и поч-товых служб, – пакет SASL (Simple Secure Authentication Layer), разрабо-танный в Университете Карнеги-Мел-лон. Помимо реализации от CMU (по-лучившей название Cyrus-SASL) су-ществует GNU-версия gsasl [5], разра-батываемая практически единолично шведским программистом Джеффсо-ном. Несмотря на то что gsasl доволь-но быстро развивается, эта реализа-ция все еще считается бета-версией и значительно уступает по надежнос-ти Cyrus-SASL. Всего университетом Карнеги-Меллон было выпущено две реализации библиотеки SASL, разли-чающиеся между собой по API и фор-мату хранения пользовательских дан-ных, хотя и совместимые по протоко-лу. В настоящее время вторая версия SASL практически полностью вытесни-ла первую, и поэтому под SASL я буду понимать именно вторую версию (кото-рую иногда обозначают как SASL2).

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

Как это выглядит на практике? Кли-ент и сервер могут находиться в раз-ных сетях, которые построены и скон-фигурированы разными админист-

раторами, каждый из которых имеет свой взгляд на политику сетевой бе-зопасности. Предположим, что один из них сконфигурировал сервис та-ким образом, что тот позволяет ау-тентифицировать пользователя че-рез Kerberos5 (условное обозначение механизма – GSSAPI), с помощью па-роля, закодированного по алгоритму MD5 (CRAM-MD5), и простого тексто-вого пароля (PLAIN). Если в клиенте настроена поддержка какого-нибудь из этих механизмов, то SASL позволя-ет провести аутентификацию посредс-твом именно этого механизма, причем в случае множественного пересечения будет выбран наиболее сильный. Про-граммная реализация выглядит оди-наково – разработчик должен иници-ализировать библиотеку (c помощью функций sasl_client/server_new, ..._init, ..._start) и затем войти в цикл аутенти-фикации. На каждом шаге цикла про-грамма должна прочитать блок дан-ных, полученный по сети (реплика кли-ента/сервера), и передать его функ-ции sasl_client/server_step. На выходе функции контролируется возвраща-емое значение и один из ссылочных параметров. Ссылочный параметр пе-редается по сети без дополнительной обработки, а возвращаемое значение анализируется, и в зависимости от его

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

Теперь небольшой обзор возмож-ностей SASL. Механизмы аутентифи-кации, реализованные в Cyrus-SASL, условно можно разделить на три груп-пы (см. рисунок). Первая группа – на-иболее слабые механизмы – это аутен-тификация посредством открытых тек-стовых паролей PLAIN и LOGIN. Раз-личие между ними только в формате, в котором имя и пароль пользователя передаются по сети от клиента к сер-веру. Это очень слабые механизмы (слабее них только ANONYMOUS, от-крывающий беспарольный доступ лю-бому пользователю), поскольку паро-ли могут быть перехвачены злоумыш-

Структура SASL

40


ленником в момент передачи по сети. Если же вы решите использовать эти механизмы, то вам нужно озаботиться поиском внешнего способа криптова-ния канала передачи, например, с по-мощью SSL/TLS.

Вторая группа механизмов – это ме-ханизмы с общим ключом: CRAM-MD5, DIGEST-MD5 и несколько особняком стоящим от них механизмом одноразо-вых паролей – OTP. Слабость механиз-мов CRAM-MD5 и DIGEST-MD5 состо-ит в том, что хотя пароли и передаются по сети в зашифрованном виде, но они могут быть перехвачены и взломаны offline с помощью простого перебора. С другой стороны, при использовании этих механизмов требуется наличие незашифрованных паролей на почто-вом сервере, где их безопасность бы-вает сложно гарантировать. Метод од-норазовых паролей в этом смысле бо-лее безопасен. Идея этого метода со-стоит в создании последовательнос-ти легко запоминающихся фраз, сге-нерированных из одного секретного пароля. Этот список хранится на сер-вере и время от времени пополняется. Для подключения к серверу пользо-ватель использует очередную фразу из сгенерированного списка как свой пароль, после чего эта фраза из спис-ка вычеркивается, и для следующе-го подключения должна быть исполь-зована следующая в списке. Понят-но, что перехват пароля ничего не да-ет злоумышленнику, хотя по-прежне-му остается опасность, что злоумыш-ленник сумеет завладеть всем спис-ком одноразовых паролей, хранящим-ся на сервере.

И наконец, последняя группа – меха-низмы, использующие Kerberos (GSSAPI и KERBEROS_V4). KERBEROS_V4 при-меняется для аутентификации по ста-рому, не очень надежному, но тем не менее все еще используемому прото-колу Kerberos4, а GSSAPI следует по-нимать как синоним Kerberos5, более современной версии Kerberos. Нас бу-дет интересовать в основном этот пос-ледний механизм.

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

рые в терминологии SASL называются методами. Вы должны решить, какой из методов будете использовать, при-чем можно подбирать метод индивиду-ально для каждого приложения. Воз-можные варианты: собственная база данных SASL (sasldb2), база данных LDAP, внешняя SQL-совместимая ба-за данных, системные файлы с иденти-фикационной информацией о пользо-вателях (/etc/passwd, /etc/shadow), ис-пользование инфраструктуры PAM или Kerberos. В последнем случае не нужно путать Kerberos как метод с механиз-мами GSSAPI и KERBEROS_V4. При-менение этого метода позволяет ис-пользовать базу данных Kerberos как хранилище паролей без необходимос-ти развертывания всей инфраструк-туры Kerberos. Выбор метода во мно-гом определяет набор доступных ме-ханизмов – бесполезно объявлять ме-ханизм GSSAPI как поддерживаемый приложением, если единственный до-ступный для него метод – это систем-ные файлы. Библиотека SASL может использовать методы либо напрямую, либо через своего «агента» – демо-на saslauthd, с которым библиотека SASL общается через именованный сокет. Использование агента бывает необходимо для согласования прав доступа – сетевое приложение мо-жет быть запущено от непривилеги-рованного системного пользователя, а для аутентификации, к примеру, че-рез системные файлы нужен доступ на чтение /etc/shadow, что при разум-ной установке возможно только для root. Однако можно запустить сервис saslauthd с привилегированными пра-вами, тем самым открывая ему доступ к /etc/shadow и при этом не компроме-тируя безопасность системы, посколь-ку непосредственный доступ к это-му сервису из сети невозможен. Ре-зультат процедуры аутентификации saslauthd сообщает сервису через име-нованный сокет права на доступ, к ко-торому могут быть более либеральны, чем к /etc/shadow.

Установка библиотеки SASLПосле этого небольшого обзора SASL можно приступить к установке и тес-тированию самой библиотеки Cyrus-SASL. Исходный код доступен на сай-те CMU (или на его зеркалах) [6]. Про-

цедура сборки программного паке-та стандартна – с помощью скрипта configure проводим предварительную настройку программы и компилируем командами make, make install. Помимо обычных опций (например, --prefix=/usr, означающий, что программа будет ус-тановлены в каталог /usr) configure имеет еще большое число парамет-ров, которые позволяют гибко настра-ивать Cyrus-SASL. Разберем неко-торые из этих параметров. В первую очередь нас интересуют --with-gssapi и --with-gss_impl=heimdal, которые включают поддержку механизма GSSAPI и указывают, какая реализа-ция Kerberos будет использована для этого. Так же, как и в статье [7], пред-полагаем, что в системе установле-ны библиотеки и заголовочные фай-лы Heimdal Kerberos, хотя возможно применение и более распространнен-ной версии Kerberos от MIT. Другие механизмы SASL можно также вклю-чить (или выключить) при конфигура-ции, например:

LOGIN и NTPL используются мно-гими старыми почтовыми программа-ми от Microsoft, и их поддержку бывает полезно включить в Cyrus-SASL. Меха-низм ANONYMOUS для почтовых про-грамм скорее вреден, OTP – на ваше усмотрение. Если вы решите исполь-зовать OTP, имейте в виду, что Cyrus-SASL может либо использовать свою собственную версию OTP, либо уже установленные библиотеки OPIE (One Time Passwords in Everything [8], соот-ветствующий параметр компиляции --with-opie). Хотя heimdal имеет свою встроенную реализацию OTP, но у ме-ня не получилось заставить Cyrus-SASL использовать именно эту библиотеку.

П о д д е рж к а м е то д а SAS L D B (или auxprop) обязательна для Cyrus-SASL, хотя в нашем случае она и не нужна. Другие методы можно выклю-чить с помощью параметров:

Можно также отключить агента saslauthd (опция --with-saslauthd=no), но мы это делать не будем.

--enable-login \--enable-ntpl \--disable-otp \--disable-anon \

--enable-ldapdb=no --enable-sql=no

41№10, октябрь 2006


SASLDB по умолчанию требует в качестве DB-движка Berkley DB [9]. С этим связана одна небольшая проблема. Так же, как и SASL, многие программы, такие как heimdal, Postfix и Cyrus-IMAP, используют Berkley DB для хранения своих собственных данных, например, псевдонимов поль-зователей в Postfix. Многие дистрибутивы Linux включа-ют в себя несколько версий Berkley DB (от 2-й до 4-й), при-чём эти версии несовместимы между собой, и линковка какой-нибудь программы с разными версиями Berkley-DB ни к чему хорошему не приведёт. К примеру, если попы-таться скомпилировать SASL с 4-й версией, в то время как heimdal, используемый SASL, слинкован с 3-й, то в резуль-тате библиотека SASL будет неработоспособна. Грубо гово-ря, динамический загрузчик просто не разберётся, из какой-именно библиотеки вызывать функцию, если она присутс-твует в обеих библиотеках. При конфигурации по умолча-нию интересующих нас программ автоматически выбира-ется самая новая версия BerkleyDB, которую удалось найти в системе. В то же время могут возникнуть проблемы сов-местимости Cyrus-SASL и почтового сервера Postfix, кото-рый не поддерживает 4 версию BDB. Поэтому следует ог-раничиться только третьей версией и на время сборки про-грамм деинсталлировать BerkleyDB4 (если она присутству-ет у вас в системе), или, по крайней мере, удалить ее заго-ловочные файлы. У меня все упомянутые выше програм-мы были скомпилированы с BerkleyDB-3.3.

Взаимодействие с Kerberos через GSSAPIПосле сборки и установки Cyrus-SASL можно прове-рить его работоспособность и взаимодействие с Kerberos с помощью тестовых программ client и server из папки cyrus-sasl-*/sample. Если они не скомпилировались вмес-те с библиотекой, то можно компилировать их и позже, вы-полнив make в папке sample.

Разумеется, для проверки взаимодействия с Kerberos у вас должен быть настроен сектор Kerberos. Как это сде-лать, описано в статье [7]. Поскольку в данном случае я хо-чу продемонстрировать вам лишь принципы работы паке-та Cyrus-SASL с Kerberos, будет достаточно, если ваш сек-тор Kerberos будет состоять только из одного компьюте-ра. Это также на начальном этапе значительно упростит отладку. Так же, как и в статье [7], предполагаем, что сек-тор Kerberos называется MYREALM.RU, а машина, на кото-рой мы разворачиваем «песочницу», является также кон-троллером Kerberos и называется kdc.myrealm.ru. Чтобы не подвергать систему риску в процессе экспериментов с Kerberos и почтой, желательно использовать фиктивный сетевой интерфейс:

Будем также считать, что в Kerberos уже созданы принципалы, соответствующие машине host/[email protected] и пользователю [email protected], а ключ принципала host/kdc.myrealm.ru записан в keytab-файл (/etc/krb5.keytab).

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

Опция -p задает порт, который будет прослушивать сер-вер. Имя сервиса определяется с помощью опции -s host, причем необходимо указать только первую часть имени при-нципала, к которой затем автоматически добавляются имя компьютера и имя сектора Kerberos. Можно выбрать любо-го другого принципала, отличного от host/kdc.myrealm.ru, лишь бы его ключ присутствовал в keytab-файле. Список доступных механизмов определяется опцией -m, здесь мы ограничиваемся только GSSAPI-механизмом.

Затем на другом терминале запускаете клиентскую часть. В первую очередь получим супербилет (TGT) для ря-дового пользователя (kinit mike) и от имени этого же поль-зователя запускаем клиента:

Все ключи означают то же самое, что и в случае сер-вера; последняя опция – это имя компьютера, к которому производится подключение. В процессе программа клиент потребует ввести авторизационный идентификатор, т.е. имя пользователя, который должен быть аутентифицирован. Ввести нужно имя того принципала, для которого получен супербилет. После непродолжительного обмена закодиро-ванными сообшениями (в листинге они опущены) в обеих терминалах должно появиться сообщение об успешной ау-тентификации. Если же появилось сообщение об ошибке, следует проверить, записан ли ключ принципала-сервиса в keytab-файле и правильно ли происходит преобразова-ние имени компьютера в его адрес и наоборот. Просмотр логов контроллера Kerberos (/var/log/krb5kdc.log) также по-может в поиске неисправностей.

Проверка простых текстовых паролей в KerberosТеперь протестируем взаимодействие клиента и сервера при аутентификации с помощью простых текстовых паролей, но так, чтобы пароль пользователя всё равно проверялся по ба-зам данных Kerberos. Этот механизм требует использования демона saslauthd, который должен попытаться получить су-пербилет от KDC, используя имя и пароль пользователя. Ес-ли супербилет получен, то идентичность пользователя под-тверждена. Следует понимать, что это не лучший способ использования Kerberos. Помимо риска перехвата паролей (а в случае паролей Kerberos ставки очень высоки) сама про-цедура генерации TGT для каждого подключения к сетевым службам достаточно ресурсоемка. Разработчики Kerberos и не рассчитывали на такой режим его работы, эта идея целиком на совести разработчиков SASL. Заметьте также,

/sbin/ifconfig dummy0 192.168.10.1 netmask 255.255.255.0 up

$./server -p 3001 -s host -m GSSAPI

echo ``192.168.10.1 kdc.myrealm.ru'' >> /etc/hostshostname kdc.myrealm.ru

./client -p 3001 -s host -m GSSAPI kdc.myrealm.ru

receiving capability list... recv: {6}GSSAPIGSSAPIplease enter an authorization id: mike...successful authenticationclosing connection

42


что saslauthd не имеет собственного принципала в Kerberos, а сам пытается выступать от лица пользователя.

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

Теперь в ещё одном терминале запустим saslauthd:

С помощью ключа -a выбирается метод аутентифика-ции, а ключ -d нужен только для отладки, чтобы все сообще-ния от saslauthd выводились на терминал, а не в log-файл. Как минимум, результатом работы этой программы будет создание именованного сокета /var/state/saslauthd/mux.

Следующим шагом нужно объяснить библиотеке SASL, что проверка паролей происходит опосредованно, через взаимодействие с saslauthd, причем эту настройку можно выполнить индивидуально для каждой из сетевых служб. При инициализации серверной части библиотеки SASL (функция sasl_server_init) один из параметров – это так на-зываемое имя приложения. Оно может отличаться от насто-ящего имени исполняемого файла и используется библиоте-кой для поиска файла настроек в каталоге /usr/lib/sasl2. Тес-товый сервер выступает под именем «sample», так что нам понадобится файл /usr/lib/sasl2/sample.conf такого вида:

Нас в данном случае интересуют только два парамет-ра – pwcheck_method и mech_list, а полный список пара-метров вы можете посмотреть в документации cyrus-sasl (doc/options.html). В этом конфигурационном файле ука-зано, что помимо механизма GSSAPI разрешено исполь-зовать также незашифрованные пароли (PLAIN) и их про-верка будет осуществляться агентом saslauthd. В конечном итоге выбор механизма аутентификации всегда остается за клиентом, сервер может только ограничить этот выбор, сообщив клиенту список поддерживаемых механизмов (GSSAPI и PLAIN в данном случае). Понятно, что исключе-ние из mech_list механизма plain равносильно запрету ис-пользования простых текстовых паролей для данного при-ложения. Хотя в этом и есть свой резон, но пока в наши планы это не входит.

Теперь перезапустим server. Команда практически та же самая, что и использованная ранее, только без ключа -m. В этом случае список механизмов будет взят из файла /usr/lib/sasl2/sample.conf. Но при новом запуске клиента мы теперь должны указать механизм PLAIN:

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

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

К первой категории можно отнести протоколы электрон-ной почты и LDAP. Поддержка SASL включена в такие по-пулярные продукты, как Sendmail, Postfix, Cyrus-IMAP (на-стройка последних двух программ будет рассмотрена в сле-дующей статье). Протокол мгновенного обмена сообщени-ями jabber [10] – это пример нового протокола, где SASL ис-пользуется как на стороне сервера, так и поддерживается некоторыми клиентами (например, tkabber [11] собранный с библиотекой tcl SASL [12]). Интерес представляет также использование SASL для аутентификации пользователей сервера баз данных MySQL. Хотя эта поддержка не вклю-чена в основную ветку, но в Интернете можно найти патчи для 4 и 5 версий MySQL [13, 14].

Таким образом, соответствующая настройка библиоте-ки SASL позволяет интегрировать эти продукты в систему единой регистрации пользователей Kerberos.

1. Бешков А. Почтовая система для среднего и малого офиса. //Системный администратор, №5, 2003 г. – С. 46-54.

2. Мозговой А. Smtp auth in da postfix + ... //Системный админис-тратор, №10, 2003 г. – С. 26-28.

3. Литвиненко Е. Настраиваем основные компоненты почтового сервера. //Системный администратор, №9, 2005 г. – С. 48-51.

4. Шергин Д. Установка IMAP4-сервера на базе Cyrus-imapd+Sendmail. //Системный Администратор, №10, 2003 г. – С. 10-15.

5. http://www.gnu.org/software/gsasl.6. ftp://ftp.andrew.cmu.edu/pub/cyrus-mail.7. Кондрин М. Развертываем Heimdal Kerberos. //Системный ад-

министратор, №7, 2005 г. – С. 26-31.8. http://www.inner.net/opie.9. http://www.sleepycat.com/products/bdb.html.

10. http://www.jabber.org/software/jabberd2x.shtml.11. http://tkabber.jabber.ru/en/.12. http://beepcore-tcl.sourceforge.net/tclsasl.html.13. http://rc.vintela.com/topics/labs/mysql.14. ftp://hppidc.hppi.troitsk.ru/mysql-sasl-patch.tgz.

pwcheck_method:saslauthdmech_list:gssapi plain

./client -p 3001 -s host -m PLAIN kdc.myrealm.ru

receiving capability list... recv: {6}GSSAPI PLAINPLAINplease enter an authorization id: mike...successful authenticationclosing connection

chown -R root.kerberos /var/state/saslauthd/chmod -R 755 /var/state/saslauthd/

/usr/sbin/saslauthd -a kerberos5 -d

43№10, октябрь 2006


Не секрет, что электронную почту можно перехватить, – достаточ-но установить сниффер и затем

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

го, что важная информация будет от-правлена незашифрованной.

В журнале уже рассматривал-ся вариант построения защищенной почтовой системы на основе Tiger Envelopes [1], в SecExMail Gate приме-нен аналогичный принцип.

Как работает SecExMail GateSecExMail Gate – почтовый прокси-сервер, который подключается меж-ду почтовым клиентом и SMTP/POP3-сервером, и в реальном времени шиф-рует все проходящие через него элек-тронные сообщения, обеспечивая кон-фиденциальность корпоративной поч-ты, передаваемой по незащищенным сетям. Для шифрования используют-

ся исключительно открытые стандар-ты. На рабочих местах никакого допол-нительного программного обеспече-ния не требуется. При этом SecExMail Gate довольно легко интегрирует-ся в существующую инфраструктуру. После установки сервера на компью-терах клиентов потребуется лишь за-дать новые параметры, указав в на-стройках в качестве SMTP/POP3-сер-вера SecExMail Gate. На самом же SecExMail Gate необходимо пропи-сать данные корпоративного почтово-го сервера. Хотя в некоторых случаях, чтобы не бегать по этажам, наверное проще на место почтового сервера поставить SecExMail Gate, а старому серверу дать новый адрес (не забыв поменять настройки DNS). Пользо-

Защищаем корпоративную почту с SecExMail Gate

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

Cергей Яремчук

44


ватели не заметят этих перестановок и будут работать с почтой как обычно. Но внутри системы многое в работе почты изменилось. Ключ, введенный для конкретного корреспондента, за-ставит SecExMail Gate автоматичес-ки зашифровать сообщение, от поль-зователя никаких дополнительных указаний не потребуется. Но это еще не все. Анализируя заголовки сооб-щений, злоумышленник может всег-да определить характер письма и тип MIME, все это может оказаться хоро-шим подспорьем для криптоаналити-ков, которые попытаются раскодиро-вать сообщение. Например, если один и тот же текст или файл будет пере-дан разным корреспондентам, мож-но попытаться реализовать так на-зываемую атаку по открытому тексту (PlainText Attack), когда по известно-му тексту вычисляется ключ. Поэтому SecExMail Gate шифрует тему сообще-ний и все заголовки, позволяющие ус-тановить характер передаваемой ин-формации, поэтому криптоанализ пе-рехваченного письма очень затруд-нен. SecExMail Gate использует алго-ритм RSA с 2048, 4096 и 8192 ключа-ми, хотя в корпоративной версии воз-можно использование размера клю-чей вплоть до 10240. Открытый ключ, ассоциированный с получателем, ис-

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

При шифровании сообщение про-ходит несколько этапов: Полученное сообщение анали-

зируется, проверяется информа-ция, записанная в SMTP-заголов-ке письма и тело сообщения. Сер-вер SecExMail Gate использует эту информацию для получения досту-па к почтовому серверу и в случае положительного ответа продолжа-ет дальнейшую обработку получен-ного сообщения.

Сообщение, как правило, содер-жит часть известной информации, приветствие, визитная карточка от-правителя, поэтому во избежание возможности проведения PlainText Attack сообщение сжимается с ис-пользованием алгоритма ZLIB.

Сжатый поток также имеет инфор-мацию, позволяющую криптоана-литикам установить характер сооб-щения, поэтому первые 64 бита со-общения дополнительно складыва-ются (XOR) со случайным текстом (One-Time Pads), обеспечивая его уникальность.

Сжатая информация складывается с 64-битным потоком случайных чи-сел ISAAC.

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

Информация преобразуется в тип base64 и передается MTA.

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

ем SSL (Secure Socket Layer) или TLS (Transport Layer Security).

На сайте проекта можно загрузить полнофункциональную версию про-дукта, которая без регистрации бу-дет работать в течение 30 дней. Сто-имость лицензии зависит от количес-тва пользователей. Так SecEx Mail Corporate для 20 пользователей обой-дется в 949 $, а для 500 – 14995 $.

Для работы сервера SecExMail Gate потребуется компьютер, работающий под управлением Windows от 95 до XP, имеющий 5,5 Мб свободного места на жестком диске. Системные требова-ния которого напрямую зависят от ко-личества передаваемых и принима-емых сообщений. В качестве ориен-тировки лучше посмотреть нагрузку своего почтового сервера.

Установка и создание ключейУстановка SecExMail Gate стандартна для Windows, вы просто запускаете ис-полняемый файл и нажимаете «Next». На предпоследнем шаге, выбрав «Set service to start boot», разрешите авто-матический запуск сервера SecExMail Gate при загрузке системы. После за-вершения установки первым делом необходимо сгенерировать ключи. В меню «Пуск» выбираем «SecExMail Gate» и «SecEx KeyGenerator», в по-явившемся окне персональные дан-ные (имя и почтовый адрес), и на сле-дующем этапе размер ключа (рис. 1), внизу будет показано приблизитель-ное время, необходимое для генери-рования ключа выбранного размера. Далее вводим пароль, и в следующем окне несколько раз щелкаем мышкой в любом месте белого поля, чтобы ути-лита сгенерировала случайное число. По окончании генерирования публич-ного и секретного ключей вас попросят ввести пароль, после чего созданный ключ появится во вкладке «Keys» ок-на настройки сервера SecExMail Gate. Для создания SSL-сертификатов, под-тверждающих подлинность, исполь-зуется другая утилита Generate SSL Certificate Request, расположенная там же. При создании своего сертификата вам также придется ввести информа-цию об организации, которая исполь-зует сервер SecExMail Gate (название, имя сервера, город, страна) и размер ключа. По окончании создания серти-

Рисунок 1. Выбор размера ключа

Рисунок 2. Настройки параметров SMTP-шлюза

45№10, октябрь 2006


фиката будет выдано сообщение, в ко-тором указано имя файла ключа и сер-тификата (они сохраняются в каталог, в который установлен сервер). Орга-низации, купившие лицензию, могут подписать в Bytefusion Ltd. созданный сертификат, отослав файл по адресу [email protected].

Теперь все готово для настройки сервера SecExMail Gate.

Настройка и запуск SecExMail GateПрограмма настройки SecExMail Gate проста и понятна, зная все необходи-мые для работы параметры, весь про-цесс не займет более 5 минут. Для на-стройки SMTP-туннеля заходим в од-ноименную вкладку и устанавливаем флажок «Enable SMTP Relay» (рис. 2). Слева в области «E-Mail Client» изме-няем при необходимости номер пор-та для входящей почты (по умолча-нию 25), а справа указываем порт, имя или IP-адрес почтового сервера, кото-рому будут перенаправляться сообще-ния после зашифровки. Теперь пере-ходим во вкладку «POP3», и аналогич-ным образом настраиваем параметры транзита входящих сообщений. В на-стройках почтовых клиентов указыва-ем новые параметры, установив в ка-честве сервера приема передачи со-общений SecExMail Gate.

Защищенные с помощью SSL POP3 и SMTP-соединения настраиваются в других вкладках. Но в начале не-обходимо указать на файлы серти-фикатов и ключей, сгенерированных ранее с помощью утилиты Generate SSL Certificate Request. Переходим во вкладку «SSL», в поле «SSL/TSL Tunables» выбираем параметры тун-неля (TSL v.1, SSL v.2 или 3), и мини-мальный размер шифра (Min.Cipher Bits). И, наконец, в «Certificate File» и «Private Key File» указываем создан-ный сертификат и ключ. После чего потребуется перезапустить сервер. Те-перь переходим во вкладку «SMTPS» и прописываем параметры защищен-ного соединения, указав номер порта, отличный от используемого во вклад-ках «SMTP» и «POP3» (по умолчанию стоят стандартные 465 и 995). Учтите, что если основной почтовый сервер также использует защищенное соеди-нение, то для работы с ним возможно применение только защищенного ва-

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

Вкладка «Service» предназначе-на для управления работой сервиса SecExMail Gate. Здесь можно просмот-реть статус работы, остановить и за-пустить сервер, включить журнали-рование событий и подключение кли-ентов. Для получения более подроб-ной информации включите флажок «Verbose». Журнал работы сервера со-храняется в текстовый файл, просмот-реть записанную в него информацию можно во вкладке «Events». Для каж-дого клиента в подкаталоге client-logs создается свой текстовый файл, в ко-торый заносятся все связанные с ним события. В имени файла использован IP-адрес, с которого зашел клиент, например 127_0_0_1.txt. Во вкладке «Clients Log» можно просмотреть все эти файлы.

Для хранения к лючевых дан-ных в зависимости от назначения используются различные вкладки. Так, во вкладке «Keys» прописывают-ся публичные и закрытые ключи, при-надлежащие внутренним пользовате-лям компании. Для создания нового ключа необходимо нажать «New key», после чего появится знакомый SecEx KeyGenerator. Из этого же окна можно экспортировать или импортировать любой ключ.

В SecExMail Gate предусмотрены три вида ключей, что позволяет наибо-лее оптимально распределять ключе-вую информацию: Wildcard keys – представляют об-

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

Personal keys – этот ключ уже при-вязан к определенному почтовому адресу и предназначен для индиви-дуального обмена сообщениями.

Department keys – ключ ассоции-рован с отделом или группой поль-зователей.

Соответствие между пользователь-скими почтовыми адресами и группа-ми задается во вкладке «Groups». За-писи, в которой имеют приблизитель-но такой вид:

Для удобства хранения и обра-ботки вся информация хранится в «comma separated values» в фай-ле groupkes.csv. После внесения из-менений напрямую в файл необходи-мо зайти в эту вкладку и нажать кноп-ку «Re-read groups file», чтобы инфор-мация стала доступна SecExMail Gate. Для работы указанной схемы должны быть созданы ключи, соответствую-щие адресам [email protected] и [email protected]. И наконец публичные ключи всех корреспондентов хранятся во вкладке «Friends».

Для генерирования случайных чи-сел SecExMail Gate использует инфор-мацию, взятую из системных процес-сов, файлов в системных и временных каталогах. Все возможные настройки доступны на вкладке «Entropy».

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

1. Яремчук С. Защищенная почтовая сис-тема с Tiger Envelopes. //Системный ад-министратор, № 6, 2005 г. – C. 61-63.

2. Cайт Bytefusion Ltd. – ht tp: / /www.bytefusion.com.

[email protected] [email protected] [email protected] [email protected] sales

Рисунок 3. Настройка параметров защищенного POP3-соединения

46


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

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

шить проблему, если будете понимать, как устроены руткиты, для чего они нужны, с помощью чего можно их уда-лять и как это делать вручную. В статье рассмотрены руткиты для Windows NT 5 (Windows 2000, 2003 Server, XP).

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

ют на нулевом кольце или на уровне ядра NT.

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


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

Артем Баранов

47№10, октябрь 2006


настоящие приложения. Например, ес-ли для отображения процессов исполь-зуется tlist.exe из Resource Kit, то мож-но написать свою tlist.exe, например с использованием Psapi или библиотеки Tool Help, скрывающую имя конкрет-ного процесса и подменить ею насто-ящую tlist.exe. Недостаток такого под-хода очевиден. Кому захочется зано-во написать диспетчер задач Windows для скрытия определенного процесса. Второй тип руткитов 3-го кольца отли-чается от первого техникой реализа-ции. Руткиты, относящиеся ко второму типу, используют общий принцип фун-кционирования, именуемый перехва-том API-вызовов. Он был описан Дж. Рихтером в его монографии «Windows для профессионалов» и М. Питреком «Секреты системного программирова-ния в Windows 95». Этот тип также мо-жет быть разбит на два. К первому сле-дует отнести руткиты, перехватываю-щие вызовы DLL подсистемы окруже-ния Win32 (Kernel32, Advapi32, User32, Gdi32). Ко второму типу относятся рут-киты, перехватывающие недокумен-тированные «родные» API (Native API) в Ntdll.dll. Напрашивается вопрос, за-чем перехватывать недокументиро-ванные API, если можно перехватить «обычные». Дело в том, что некоторые стандартные программы Microsoft, на-пример диспетчер задач (task manager), для получения статистики используют не обычные API, а недокументирован-ные. Тот же диспетчер задач использу-ет для получения списка процессов не что-то вроде Psapi, а функцию NtQuerySystemInformation, которая хоть и доку-ментирована в последних SDK, но да-леко не полностью. Изучая лишь SDK по этой функции, можно долго недо-умевать, как диспетчер задач получает с помощью нее информацию о процес-сах. Полное описание этой функции вы можете увидеть в книге Г. Неббе-та «Справочник по базовым функциям API Windows NT/2000». Очевидный не-достаток такого руткита заключается в том, что он реализован с использова-нием структур, которые могут быть из-менены в следующей версии Windows. По вышесказанному следует сделать несколько замечаний. Во-первых, рут-киты для Windows распространяют-ся очень быстро. Поэтому говорить о том, что что-то является недокумен-тированным, бессмысленно, т. к. ха-

керы уже давно дизассемблировали код Kernel32.dll и Ntdll.dll и опубликова-ли свои соображения на этот счет. Во-вторых, перехват API-вызовов на уров-не Ntdll.dll дает некоторые существен-ные преимущества. Дело в том, что все библиотеки, получающие информацию о процессах, типа Psapi, обращаются в конечном счете к одной точке входа в Ntdll.dll, которая предоставляет неис-черпаемую системную информацию – NtQuerySystemInformation.

Руткиты режима ядраРуткиты режима ядра, как уже упо-миналось, функционируют на уровне ядра NT и более сложны в реализа-ции. В их основу положен тот же ме-ханизм перехвата API-вызовов, но уже на уровне ядра. С использованием та-ких руткитов можно модифицировать как само ядро, так и объекты ядра. Учи-тывая, что устройство объектов ядра является полностью недокументиро-ванным, можно смело сказать, что да-леко не каждый профессионал в Win32 может разработать такой руткит. Хоро-шей отправной точкой в этом послужит книга С. Шрайбера «Недокументиро-ванные возможности Windows 2000».

По сути, руткиты режима ядра пред-ставляют собой драйверы, загружен-ные в период работы Windows. Меха-низм перехвата API-вызовов на уровне ядра впервые был предложен М. Рус-синовичем и Б. Когсвелом, авторами sysinternals.com. Он базируется на под-мене адресов в таблице диспетчериза-ции системных сервисов на свои обра-ботчики, например, на адреса функций драйвера. Перед тем, как менять адре-са, руткит сохраняет настоящие адре-са системных сервисов в своем буфе-ре. Когда ядро обрабатывает систем-ный сервис, это приводит к актива-ции не настоящей функции, а троянс-кой (т.е. функции драйвера), та в свою очередь вызывает настоящий сервис по сохраненному адресу и фильтрует результат. Основное преимущество та-ких руткитов в том, что они независи-мы от процессов, а точнее от их вирту-альных адресных пространств. Теперь о недостатках руткитов режима ядра. Как известно, разработка кода режи-ма ядра сама по себе довольно слож-на и налагает определенные ограни-чения. Одна малейшая ошибка в ко-де, например появление жучка или не-обработанного исключения, повлечет

Этапы обработки API в Win32 и места внедрения руткитов

48


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

Хотя руткиты пользовательского режима могут воздействовать только на процесс, для которого они предна-значены, существуют методы, позво-ляющие руткиту работать «глобаль-но». Например, руткит может пора-жать вновь создаваемые процессы. Как только система создаст новый про-цесс, руткит сможет узнать об этом, ис-пользуя системный сервис для пере-числения процессов. Затем руткиту нужно остановить все потоки в новом процессе и попытаться модифициро-вать таблицу импорта или переписать первые байты перехватываемой функ-ции. Другой способ заключается в сле-дующем. В реестре существует раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows с параметром AppInit_DLLs. Система автоматически загружает DLL, указанные в этом параметре.

Руткиты режима ядра не являют-ся «полноценными» драйверами ус-тройств, т.к. никакими устройствами они не управляют. Но все же драйвера-ми называться могут. Об этом говорят Руссинович и Соломон в книге «Inside Windows NT», что драйверы пишут не для управления устройствами, а толь-ко для внедрения кода, функциониру-ющего в режиме ядра. Аналогичный подход использует программа Русси-новича Regmon (Registry Monitor), кото-рая отображает обращения к систем-ному реестру. Она запускает драйвер во время своего выполнения, тот по-лучает доступ к таблице диспетчери-зации системных сервисов и модифи-цирует ее на свои обработчики. Затем, когда какой-то процесс вызывает сер-вис реестра, управление получает ус-тановленная ловушка, которая в свою очередь вызывает настоящий сервис реестра, запоминает возвращенные данные в буфере, а затем приложе-ние забирает их по IOCTL и выводит. (Подробности см. в книге Руссинови-ча, Соломона «Внутреннее устройс-тво Microsoft Windows: Windows XP, Windows 2003 Server, Windows XP».)

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

виса в Win32. Изображен поток, пи-шущий данные в файл, и два руткита: 3-го и 0-го кольца. Также изображены возможные точки проникновения рут-китов. Что касается руткита пользова-тельского режима, то он может внед-ряться тремя способами:1. Внедрение в работающий процесс

путем модификации таблицы им-порта в образе EXE-файла. Так пе-рехватываются вызовы DLL, кото-рые связаны неявно с EXE-фай-лом.

2. Модификация первых слов пере-хватываемой функции на инструк-цию jmp, в DLL подсистемы Win32. Если DLL связывается с процессом явно (в периоде выполнения).

3. Модификация первых слов пере-хватываемой функции на инструк-цию jmp в Ntdll.dll. Аналогично вто-рому.

Руткит 0-го кольца внедряется пу-тем перезаписи адреса в таблице дис-петчеризации системных сервисов.

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

В Windows процесс должен иметь права на загрузку драйвера в систему. То есть процесс должен иметь в марке-ре доступа активированную привиле-гию SeLoadDriver или иметь право ее активировать в маркере доступа.

Владея технологией rootkits, адми-нистратор может, используя специаль-ное ПО, своевременно выявлять рут-киты и удалять их из системы, а так-же использовать их в мирных целях, скрывая необходимые данные от поль-зователей. Хотя использование rootkit-технологий – это палка о двух концах. Еще не утихли страсти вокруг сканда-ла с Sony BMG, которая использова-ла свой руткит в мирных целях, скры-вая свои программные DRM-компонен-ты. Но руткит Sony способствует очень частому появлению BSOD (Blue Screen Of Death) и замедлению работы систе-

мы. Кроме того, эта история имела пе-чальные последствия. Как известно, после появления руткита Sony в Интер-нет был выпущен backdoor, использую-щий этот руткит для сокрытия своего кода на диске. В скандале вокруг Sony BMG участвовал Руссинович, который указал, что Symantec и Kaspersky Lаb используют в своих продуктах техно-логии, близкие к rootkit. Например, ан-тивирус Касперского использует тех-нологию iStreams. Технология позво-ляет уменьшить время сканирования за счет создания в файлах на NTFS-то-мах дополнительных потоков для хра-нения контрольных сумм. Так как эта информация важна для работы антиви-руса, он скрывает эти потоки, что очень похоже на rootkit-технологию.

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

Если в системе предположительно живет руткит пользовательского ре-жима, скрывающий что-либо, то мож-но написать программу, получающую информацию аналогично той, кото-рую скрывает инфицированная рут-китом программа, и сравнить резуль-таты, полученные ими. Если руткит сидит на уровне ядра, то можно вос-пользоваться средством, разработан-ным Руссиновичем, – RootkitRevealer для удаления руткита. Скачать можно с www.sysinternals.com.

Ресурсов и книг, посвященных теме руткитов немного. Вообще же эта тема охватывает многие аспекты системно-го программирования для Win32. На се-годняшний день существует единствен-ная книга, пока не выпущенная на рус-ском языке – Hoglund, Butler «Rootkits. Subverting the Windows Kernel». Сущест-вует также ресурс, посвященный рут-китам – www.rootkit.com. На нем разме-щено достаточно информации о рут-китах, в том числе выложен исходный код некоторых из них. Также там мож-но найти наиболее функциональный на сегодняшний день руткит – Hacker Defender. И конечно, всем известный сайт по продвинутому системному ПО для Windows – www.sysinternals.com, где Руссинович рассматривает техно-логию руткитов.

49№10, октябрь 2006

bugtraq

Переполнение буфера в avast!Программа: avast! 4.7.869 for desktops, avast! 4.7.660 for servers.Опасность: Высокая.Описание: Уязвимость существует из-за ошибки провер-ки границ данных при обработке LHA-архивов. Удаленный пользователь может с помощью специально сформирован-ного LHA-архива вызвать переполнение динамической па-мяти и выполнить произвольный код на целевой системе.URL производителя: http://www.avast.com.Решение: Установите исправленную версию с сайта про-изводителя.


Обход аутентификации в Citrix Access GatewayПрограмма: Citrix Access Gateway 4.2.Опасность: Высокая.Описание: Уязвимость существует из-за неизвестной ошибки при обработке LDAP-аутентификации при вклю-ченной опции Advanced Access Control (AAC). Удаленный пользователь может обойти процесс аутентификации и по-лучить доступ к системе.URL производителя: http://www.citrix.com.Решение: Установите исправление с сайта производите-ля.

Межсайтовый скриптинг и раскрытие данных в Webmin/UserminПрограмма: Webmin, версии до 1.296; Usermin, версии до 1.226.Опасность: Средняя.Описание: 1. Уязвимость существует из-за недостаточной обработки входных данных в URL. Удаленный пользователь может с помощью специально сформированного запроса выполнить произвольный код сценария в браузере жертвы в контексте безопасности уязвимого сайта.

2. Уязвимость существует из-за недостаточной обработ-ки входных данных в URL. Удаленный пользователь может с помощью специально сформированного запроса просмот-реть исходный код CGI- и Perl-сценариев на системе.URL производителя: http://www.webmin.com.Решение: Установите исправление с сайта производите-ля.

Множественные уязвимости в gzipПрограмма: gzip 1.3.5, возможно, более ранние версии.Опасность: Средняя.Описание: 1. Уязвимость существует из-за ошибки разы-менования нулевого указателя в функции huft_build(). Уда-ленный пользователь может с помощью специально сфор-мированного архива вызвать отказ в обслуживании при-ложения.

2. Уязвимость существует из-за ошибки индекса масси-ва в функции make_table в файле unlzh.c при обработке LZH-архивов. Удаленный пользователь может с помощью специ-ально сформированного архива вызвать переполнение бу-фера и выполнить произвольный код на целевой системе.

3. Переполнение буфера существует в функции build_tree в файле unpack.c. Удаленный пользователь мо-жет с помощью специально сформированной таблицы за-писать отрицательное значение индекса и выполнить про-извольный код на целевой системе.

4. Переполнение буфера обнаружено в функции make_table в компоненте LHZ. Удаленный пользователь может создать специально сформированную таблицу де-кодирования архива и выполнить произвольный код на це-левой системе.

5. Уязвимость существует в файле unlzh.c в компоненте LHZ. Злоумышленник может с помощью специально сфор-мированного архива вызвать зацикливание приложения и потребить все доступные ресурсы на системе.URL производителя: http://www.gzip.org.Решение: Установите исправленную версию от произво-дителя.

Межсайтовый скриптинг в RssReaderПрограмма: RssReader 1.0.88.0, возможно более ранние версии.Опасность: Средняя.Описание: Уязвимость позволяет удаленному пользова-телю произвести XSS-нападение. Уязвимость существует из-за недостаточной проверки данных при обработке Atom- и RSS-каналов. Удаленный пользователь может с помощью специально сформированного Atom-канала выполнить про-извольный код сценария в приложении.URL производителя: http://www.rssreader.com.Решение: В настоящее время способов устранения уязви-мости не существует.

Переполнение буфера в TFTP Server TFTPDWINПрограмма: TFTP Server TFTPDWIN 0.4.2, возможно, бо-лее ранние версии.Опасность: Средняя.Описание: Уязвимость существует из-за ошибки проверки границ данных в файле tftpd.exe во время обработки запро-шенных ресурсов. Удаленный пользователь может запро-сить ресурс длиной более 280 байт, вызвать переполнение стека и выполнить произвольный код на целевой системе.URL производителя: http://www.prosysinfo.com.pl/tftpserver.Решение: В настоящее время способов устранения уязви-мости не существует.

Переполнение буфера в WS_FTP LEПрограмма: WS_FTP LE 5.08, возможно, более ранние версии.Опасность: Средняя.Описание: Уязвимость существует из-за ошибки провер-ки входных данных при обработке ответов команды PASV. Злоумышленник может обманом заставить пользователя подключиться к злонамеренному серверу и выполнить про-извольный код на системе пользователя.URL производителя: http://www.ipswitch.com.Решение: В настоящее время способов устранения уязви-мости не существует.

50


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

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

с Browser Sentinel [2] разработки UnH Solutions.

Назначение Browser SentinelПрограмма предназначена для наблю-дения за уязвимыми зонами компью-тера, которые часто подвергаются на-падениям со стороны различного типа вредоносных программ, предоставляя пользователю полный контроль над ни-ми. А таких чувствительных к зараже-нию зон в системе не мало. Здесь пла-гины Browser Helper Object и различ-ные элементы Internet Explorer, эле-менты автозапуска программы, служ-бы, драйверы, модули, расширения оболочки, протоколы, файл hosts, пос-тавщики многоуровневых услуг и про-чее. То есть все, что может быть исполь-

зовано вредоносной программой, что-бы обеспечить себе дальнейшую жиз-недеятельность. В случае возникнове-ния подозрительной активности поль-зователь будет оповещен. И при необ-ходимости любой элемент может быть остановлен или удален. Кроме этого, есть возможность произвести деталь-ный анализ всех запущенных процес-сов, программ, элементов управления ActiveX, драйверов и других модулей, с выдачей подробной информации и со-зданием разнообразных отчетов. Для удобства Browser Sentinel содержит небольшую встроенную базу данных по элементам, которые поставляются вместе с Windows и являются ее час-тью, и не более. Пользователь для уп-рощения анализа ситуации может уб-рать все известные программе компо-

Защитить ваш компьютер поможет Browser Sentinel

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

Cергей Яремчук

51№10, октябрь 2006


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

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

Актуальной на момент написания статьи являлась версия 2.1.1. Browser Sentinel работает на компьютерах с ус-тановленной Windows 98/ME/2000/XP/Server 2003. Имеет русский и английс-кий интерфейсы.

ЛицензияПрограмма распространяется как Shareware, при этом пользователю предоставляется для тестирования на 30 дней полноценная версия про-граммы. Стоимость регистрации 350 руб. Если почитать лицензию, то узна-ем, что можно использовать зарегис-трированную версию на всех компью-терах, которыми владеет купивший ее пользователь.

Работа с Browser SentinelУстановка Browser Sentinel стандартна для Windows, в процессе можно будет выбрать один из режимов: профессионала – под наблюдением

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

новичка – не наблюдаются следую-щие зоны: службы, драйвера, про-токолы, LPS и файл hosts. Измене-ния в загруженных модулях и мо-дулях автозапуска принимаются автоматически. В дальнейшем ре-жим работы можно сменить. Также следует помнить, что все сторонние программы, имевшиеся на компью-тере на момент установки Browser Sentinel, принимаются автомати-чески (рис. 2). Рекомендуется про-смотреть все вкладки и убедиться, что все элементы безопасны.

По щелчку на изображении щи-та в системной панели появляет-ся главное окно программы (рис. 1). Для удобства охраняемые зоны поде-лены на две группы. Первая контроли-рует все, что связано с Internet Explorer. Именно к настройкам этой зоны допу-щен пользователь в режиме, предна-значенном для новичка, так в случае ошибки максимум, что придется сде-лать, это переустановить приложение. Вторая зона защищает систему. Все настройки в эту зону должны вносить-ся с большой осторожностью. Выбрав элемент, можно просмотреть подроб-ную информацию о нем: имя, описа-ние, файл, версия, размер, контрольная сумма (MD5, CRC32), время создания,

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

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

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

1. Яремчук С. Проактивные системы за-щиты, или Есть ли жизнь без антиви-руса?//Системный администратор, №7, 2005 г. – C. 9-13.

2. Cайт проекта – http://browsersentinel.com/ru.

Рисунок 2. Сообщение, появляющееся после установки Browser Sentinel

Рисунок 1. Главное окно программы

52

человек номера

Как и многие москвичи, я люблю Питер. Как и многие москвичи, я считаю его мистическим горо-

дом. Как и многие москвичи, я радуюсь, когда встречаю петербуржца. Почему? Трудно объяснить. Как любой здра-вомыслящий житель города на Неве, Игорь Данилов, легендарный Dr. Web, на мои восторги улыбнулся. «Мы все время живем в этом городе, конеч-но, не всегда видим эту красоту… Вот, гости недавно приезжали, с ними вы-брались, погуляли». Конечно, он прав. Но почему-то все время, пока мы раз-говариваем, несмотря на то, что бесе-да происходит в самом сердце Мос-квы и вокруг шумит столичная IT-вы-

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

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

Летний садВы, конечно, помните, строки Анны Ахматовой:Я к розам хочу, в тот единственный сад,Где лучшая в мире стоит из оград,Где статуи помнят меня молодой,А я их под невскою помню водой.

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


Виртуальное путешествие по Петербургу и биографии легендарного создателя антивируса Dr.Web.

53№10, октябрь 2006


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

Эта история, рассказанная Игорю Данилову, вызвала у него удивление: «Вы спрашивали? И вам не помогли? Обычно у нас бабушки не только под-скажут, где, но и проводят, покажут».

Летний сад… У него удивительная судьба! Созданный по велению Пет-ра Первого в 1704 году лучшими мас-терами садово-паркового искусства, при жизни императора он был блестя-щей парадной резиденцией. При Анне Иоанновне превратился в звериный за-гон. В XIX веке это уже городской сад «для прилично одетой публики». После революции – музей. Сразу после Ленин-градской блокады школьники и учителя выращивали здесь овощи… И всегда – любимое место для отдыха.

Не подумайте, что я собираюсь сравнивать судьбы сада и человека. Но все же параллель напрашивается сама собой. Летний сад всегда остает-ся самим собой, каким бы не было его название и облик. Игорь Данилов всег-да оставался самим собой, пробуя се-бя в разных профессиях и ипостасях. После школы он твердо знал, где хо-чет учиться дальше. Собрал чемодан, сел в поезд и уехал в Волгоград, в Ка-чинское высшее военное авиацион-ное училище летчиков. Родители это-му выбору не препятствовали. А поче-му именно в летное? Игорь не роман-тик, но считает, что так распорядились высшие силы – Бог, Судьба… В конце концов он закончил Ленинградский ин-ститут авиационного приборостроения (ныне Санкт-Петербургский государс-твенный университет аэрокосмическо-го приборостроения), стал инженером-радиотехником. И это тоже судьба так решила. А уж приобщение к сфере IT было явно судьбоносным. «Появились персональные компьютеры, некому бы-ло на них работать. Я как-то случайно попал за компьютер, и меня захватило эта сфера деятельности», – объясняет Данилов. Однако Игорь Данилов, раз-рабатывающий антивирус, и школьник Игорь, выбирающий профессию, – один и тот же человек. Любитель математи-ки, кроссвордов, головоломок, логики.

ФонтанкаОколо Летнего сада из Невы вытека-ет Фонтанка, речка, бывшая неког-

да Безымянным ериком, но в связи с устройством в саду фонтанов, пе-реименованная. Помню, зайдя как-то по делу в один из офисов, располо-женных на Фонтанке, я по-хорошему позавидовала сидящим там людям – смотришь в окошко на воду, на мос-ты, на Фонтанный дом на другом бе-регу… Веселее как-то работать, по-моему. «Да ведь вода, – скажите вы, – наверняка грязная. Что тут весело-го?». Грязная. И дома вдоль набереж-ной обшарпанные, в копоти иногда. Что делать? Это не портит Петербург, на мой взгляд. Правда, Игорь Данилов со мной не согласен: «Мне неприятно. Я очень переживаю, особенно в начале зимы, когда вся эта грязь видна, у ме-ня депрессивное настроение. Хочет-ся, чтобы было как в Хельсинки, Сток-гольме. Белый город, без грязи, без со-ли. У нас, к сожалению, этого не умеют, не хотят. К 300-летию отремонтирова-ли хотя бы центр. Я тут вышел на набе-режную и удивился: ничего себе, ока-зывается, вот что у нас есть».

Но вернемся к Фонтанному дому. Удивительное место. Снаружи это дво-рец, шедевр русского барокко. А внут-ри еще интереснее. В музее Анны Ах-матовой есть мемориальная часть, воз-вращающая квартире Пуниных – Ахма-товой облик 1920-1940-х годов, и лите-ратурно-историческая. Они нисколько не мешают друг другу. А уже если экс-курсовод попадется хороший, хожде-ние по ахматовскому музею превраща-ется в праздник. Мне повезло попасть в Фонтанный дом вместе с группой школьников. Их вел учитель, историк, и так его было интересно слушать, что я присоединилась к ребятам, всем сво-

им видом виновато показывая: «Я вам не помешаю, только не гоните…»

Дети Игоря Данилова к высоким технологиям не приобщились. Если у самого Игоря явно сработали гены – мама и сейчас работает учителем ма-тематики в одной из петербургских школ, – то любовь к точным наукам сы-ну и дочери не передалась. Хотя жена Игоря, тоже, между прочим, матема-тик. Сын Иннокентий учится в универ-ситете на биологическом факультете, дочь Ольга перешла в 11-й класс и то-же не собирается идти по родитель-ским стопам. Да и невозможно было передать, считает Игорь. Заложенное природой нельзя изменить, сколько не пытайся. «Воспитание большой ро-ли не играет. Оно, конечно, имеет ог-ромное значение, но не решающее». Еще одно убеждение Игоря Данило-ва – преподавателем в школе должен быть обязательно мужчина, «потому что он может научить детей логичес-ки мыслить, дать основы мышления». Взгляд консервативный, но вполне объяснимый. И мне близкий. Уж слиш-ком женственны нынче мужчины и му-жественны женщины…

Я спросила Игоря Данилова, как от-носятся к его популярности сын и дочь. Он спокойно ответил: «У меня такие же проблемы с детьми, как у всех, это ни-коим образом не влияет на мои взаи-моотношения с ними». Однако борцу с антивирусами приятно, что его дети учились по учебникам, в которых напи-сано про их папу, Доктора Веба.

МойкаО будущем информационных техноло-гий у Игоря Данилова довольно мрач-

Слева направо: ведущая рубрики Оксана Родионова, «Доктор Веб» Игорь Данилов, Марина Хромова – PR-менеджер компании

54


ное представление: «Черное. Термина-тор 4». Говорит он серьезно или шутит, понять невозможно. Кажется, не шу-тит, объясняет: «Уровень настолько низкий стал, количество ошибок, ко-личество дыр, высокая степень уяз-вимости настолько впечатляют, что понимаешь: чем дальше, тем хуже бу-дет. Пока компьютер был калькулято-ром, все было нормально, как только ему стали доверять серьезные процес-сы, от которых зависит жизнь челове-ка, все изменилось». «Но можно как-то повлиять на ситуацию?» – спраши-ваю. – «Остановить прогресс. Пере-сесть на лошадь». – «И вы бы согла-сились?» – «Я бы с удовольствием со-гласился». – «А чем бы вы занимались, если не информационными технологи-ями?» – «Землю бы копал. Картошку бы сажал». Наверное, это мудрость. А вернее, привычка ожидать от нашей российской действительности любого поворота. Понятно одно – Игорь Дани-лов не пропадет, если отключат свет, газ и воду. Построит дом (это он умеет, в студенческие годы приходилось), по-селит там семью и будет добывать каж-дый день кусок хлеба в поте лица.

Только не подумайте, что я ирони-зирую. Я просто опять вспомнила один из своих визитов в Санкт-Петербург. Я шла к дому Пушкина на Мойке. Не-слась, как на свидание с поэтом. А пе-ред самым музеем на набережной Мой-ки, 12, притормозила. Было лето, на фа-сад дома наводили глянец. Конец рабо-чего дня, и у самого подъезда располо-жились трое рабочих с початой бутыл-

кой и закуской на газетке. Картина са-мая мирная, но совершенно не соот-ветствующая моему пушкинскому на-строению… В другой раз я была на эк-скурсии по этой последней квартире Александра Сергеевича. Экскурсовод уже довела нас до кабинета, где Пуш-кин умирал, где произнес последние слова: «Жизнь кончена. Теснит дыха-ние…». И вдруг в открытые окна вор-вался зычный голос: «Прогулка по Не-ве, по каналам, цены умеренные…». За точность данной цитаты не ручаюсь, что-то коммерческое, в общем.

Таков Петербург. Любите его та-ким и не считайте, что он над вами из-девается…

Кстати, возможно, во время интер-вью я обидела Игоря Данилова. Чест-ное слово, не хотела. Просто предпо-ложила, что создавать вирусы – бо-лее творческое занятие, чем антиви-русы. Быть хакером, рисковать, при-думывать ловушки… Но Игорь осту-дил мой романтический пыл: «Хакер – это не гений, журналисты сделали ха-керов гениями. Там все тривиально». «Неужели вирус создать легче, чем ан-тивирус?», – робко удивилась я. «Есть сложные вирусы, по которым видно, что их создал серьезный специалист, но их единицы. Основной поток сделан бездарями, то есть людьми, которые просто берут чужие исходные тексты, сами пишут элементарные вещи. А хо-роший антивирус создать – достаточ-но сложная задача. Хороших антиви-русов не так много. И бороться не толь-ко с этим данным вирусом, но и с теми,

которые появятся завтра, послезавт-ра, наверное, более интересная зада-ча. Мне так кажется». – «Получается вы угадываете мысли тех, кто созда-ет вирусы?» – «Пытаемся».

Тут я в последний раз попыталась перевести нашу беседу в романтичес-кое русло: «Почему вы создаете ан-тивирусные программы? Не ощуща-ете себя рыцарем, который спасает человечество?». Но моя идея потер-пела крах: «Нет, все гораздо проза-ичнее. В конце 80-х годов, когда поя-вились вирусы, мы работали в «ящи-ке», в НИИ, и просто-напросто с эти-ми вирусами надо было как-то бороть-ся, потому что существующие антиви-русы не всегда помогали. Мне это ста-ло интересно. Покопался, увидел вирус, один, второй, понял, как можно сделать защиту от следующего вируса. Понача-лу это было хобби – находить вирусы и обезвреживать. Потихоньку стал де-лать программы, которые позволяют защищать от будущих модификаций этих вирусов. Меня привлекла голо-воломка, которую надо было решить». Вот она, головоломка, логическая за-дача, которая, похоже, ведет по жизни Игоря Данилова. Заниматься любимым делом, да еще получать за э то мате-риальные блага и заслуженную сла-ву, – согласитесь, счастливая судьба для любого профессионала. И будущее такому человеку видится вполне четко и ясно: «Мы пытаемся делать хорошую технологию. Чтобы продукты, которые мы производим, были технологичес-ки совершенны, и наши пользовате-ли могли бы защищаться от вирусов». И пусть не всем пользователям анти-вирусов семейства Dr.Web дано пос-тичь, каким именно образом их защи-щают – имеет ли это значение? Игорь рассказал трогательную историю: «Де-душка моей жены уже был старень-ким и перед смертью все спрашивал: «Как там Игорь? Все на калькутере?» «Да, на калькутере…».

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

текст: Оксана Родионовафото: Владимир Лукин

Вокруг шумит столичная IT-выставка

56

IMHO

Практически на любом програм-мистском форуме можно встре-тить человека (а то и целую

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

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

жить, и не просто жить, но еще поку-пать дорогостоящую вычислительную технику, летать на различные конфе-ренции, да и просто носиться на Фер-рари-512-TR в свое удовольствие – по-чему бы и нет, если их труд оплачива-ется?!

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

циализированные секторы рынка еще как-то держатся на плаву, но объемы продаж ПО до приобретения Феррари явно недотягивают.

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

Различные виды лицензийАнглийский язык относится к числу на-иболее примитивных среди всех высо-коразвитых, чем, собственно, и объ-

Как зарабатывают на Open Source

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

Крис Касперски

57№10, октябрь 2006

IMHO

ясняется его популярность, а вовсе не тем, что Америка правит миром и центр научно-технического прогрес-са находится именно там. В английс-ком очень мало слов, вследствие чего каждое слово имеет множество значе-ний, что, в конечном счете, едва не по-губило движение Open Source. Термин «free» означает не только «свобод-ный», но и «бесплатный», поэтому по-нятие «Free Software» можно толковать двояко, и большинство пользователей (по закону Мерфи) истолковали его совсем не так, как это задумывалось. Чуть позже «free» заменили на «open», но это лишь добавило путаницы и поз-волило Microsoft и другим компаниям «примазаться» к движению за свобод-ное ПО, путем раскрытия части исход-ных текстов под подписку о неразгла-шении и без передачи прав на их пос-ледующую модификацию.

Давайте выделим следующие уров-ни свободы. Абсолютная свобода пре-доставляется BSD-подобными лицен-зиями, позволяющими делать с ис-ходными кодами все, что угодно: на-резать на болванки и перепродавать, модифицировать по своему усмотре-нию, использовать в составе коммер-ческих проектов… и все это без каких-либо отчислений! В частности, на ба-зе свободной BSD построена закрытая CISCO OS, а ряд сетевых компонентов лег в основу стека NT. Компании-ги-ганты обогатились, а разработчики… подарили миру свободный код, пов-торив историю с Прометеем. (Тут кто-то может увидеть противоречие, ведь выше утверждалось, что Open Source создает угрозу компаниям-гигантам и… в то же самое время их обогаща-ет. На самом деле, никакого проти-воречия здесь нет, CISCO поставля-ет на рынок маршрутизаторы, снаб-женные всеми необходимыми серти-фикатами, и схожую функциональ-ность можно получить от более деше-вой связки PC + BSD, коллектив раз-работчиков BSD маршрутизаторами не занимается, поскольку здесь кро-ме энтузиазма нужны большие капита-ловложения. Microsoft, довольно мно-го позаимствовавшая из BSD, сократи-ла расходы на разработку своей сис-темы и смогла создать более конку-рентоспособный серверный продукт, который миллионы людей покупают за деньги, в то время как BSD можно

приобрести по цене носителя, причем BSD не стоит на месте и активно раз-вивается, предоставляя возможности, которые в Windows появляются с ог-ромным запозданием или не появля-ются вообще! Вот только один пример: при возникновении исключения в од-ном из драйверов, Windows останав-ливает всю систему целиком, не поз-воляя драйверам файловой системы сбросить свои буфера. И хотя такая возможность на уровне архитектуры в NT закладывалась изначально, она до сих пор остается нереализованной, а вот крах одного из модулей в BSD оказывает минимально пагубное воз-действие на остальные компоненты системы, позволяя ей корректно за-вершить свою работу или даже пере-запустить «упавший» модуль на лету).Свобода «коммунистического типа» предлагается нам под видом GPL-по-добных лицензий, требующих отчис-лений в случае применения их в ком-мерческих продуктах или открытия ко-да всего проекта под все той же GPL. Это справедливо, но… никакой свобо-дой здесь и не пахнет. Во многих слу-чаях GPL является хитрым маркетин-говым трюком: «свободная» програм-ма требует гораздо меньших вложений в рекламу для ее продвижения. Лю-дям свойственно скачивать то, что бес-платно, но… как только дело доходит до коммерческого применения, прихо-дится либо нарушать лицензию (ведь открывать свой код только потому, что там используется пара «свободных» библиотек, никто не будет!), либо… платить разработчикам!

Поэтому BSD – это свобода и от-крытость, а GPL – всего лишь откры-тость. Что же касается «бесплатности», то это не более чем распространенный миф. По дорогам тоже можно ездить как бы бесплатно, но если вспомнить, что их строительство обычно финан-сируется из местного бюджета, а мес-тный бюджет – это налоги, то какая-то странная «бесплатность» у нас по-лучается. Другой пример – телевиде-ние, оплачиваемое рекламодателями, включившими в свои продукты доба-вочную стоимость на рекламу. То есть «бесплатные» телеканалы оплачива-ются пивом, стиральным порошком, прокладками и прочими продуктами народного потребления. При всей не-нависти зрителей к рекламе «бесплат-

ные» каналы весьма успешно конкури-руют с коммерческими.

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

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

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

Так зачем же скачивать исходные тексты, если мы не собираемся до-рабатывать программу «напильни-ком» или проводить аудит безопас-ности? Правильно, – незачем. Вот по-тому большинство пользователей их и не качает, а один из самых популяр-ных дистрибутивов Linux – KNOPPIX распространяется без исходных тек-стов, и ведь никто же не жалуется! Другой вопрос, что собирая програм-му с определенными ключами, мож-но здорово сократить ее размер, вы-кинув все ненужное или оптимизиро-вать под конкретный тип процессора, но при желании этого же эффекта мож-но добиться путем использования ди-

58

IMHO

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

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

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

Но это даже не смешно! Да, дейс-твительно, вокруг крупных проектов таких, например, как OpenBSD, обра-зовалось целое сообщество поклонни-ков, среди которых есть как эксперты, так и новички, занимающиеся поиском ошибок из чисто спортивного интере-са или в качестве демонстрации (чи-тай – рекламы) силы своего интеллек-та. Однако открытость проекта никак не связана с количеством имеющихся в нем дыр. Взять хотя бы открытоый FireFox и сравнить его с закрытым бра-узером Opera. Лавинообразный рост критических ошибок, обнаруженных в FireFox за последнее время, доказы-вает, что качество кода определяется исключительно профессионализмом его создателей и доступность исход-ных текстов для всеобщего аудита не в состоянии исправить многочислен-ные дефекты изначально небрежно сконструированного продукта.

Кстати говоря, «аудит безопаснос-ти» в подавляющем большинстве слу-чаев – формальная процедура, про-водимая по заказу тех, кто свято ве-рит в идею, что при целенаправлен-

ном поиске можно обнаружить что-нибудь «интересное». Ни одна фир-ма со всей «свитой» своих програм-мистов не смогла выпустить продукт, полностью свободный от ошибок, до-пускающих удаленные атаки, а ведь они знают свои исходные тексты на-много лучше, чем кто-то чужой. И это ошибки, допущенные по небрежности! Тщательно же продуманная закладка может (и должна!) срабатывать лишь при сочетании определенной комбина-ции внешних воздействий. Она не со-средоточена в каком-то одном конк-ретном месте, а как бы «размазана» по всем исходных текстам. Чтобы ее обнаружить, необходимо не только де-ржать весь проект в голове, но и про-анализировать все возможные связи между его компонентами, что невоз-можно, не говоря уже о том, что за-кладка может использовать некото-рые особенности компилятора/линке-ра, поэтому они должны быть проана-лизированы тоже. А железо?! Можем ли мы ему на 100% доверять?! Доста-точно вспомнить «странности» реали-зации команды AAA, чтобы доказать, что, даже имея полный исходный код программы и справочник по командам x86, мы не можем знать, как он пове-дет себя, встретившись с «необычны-ми» аргументами. Аудит, заказанный конкретной фирме, на 99% бесполе-зен, а исходные тексты, выложенные на всеобщее обозрение, создают ил-люзию безопасности, успокаиваю-щую общественность, поскольку су-ществует вероятность, что кто-то об-наружит спрятанную закладку слу-чайно (и ведь обнаруживают!), одна-ко при этом мы неявно постулируем, что все люди, живущие на земле, это – хорошие люди и они не будут исполь-зовать свои знания в корыстных или тем более преступных целях. К тому же шансы обнаружить ошибку не так уж и велики. В частности, в конце ав-густа 2006 года Daniel Bleichenbacher выступил с докладом на конферен-ции криптоаналитиков, где показал, что при стечении определенных обсто-ятельств цифровая подпись RSA мо-жет быть подделана в прямом смыс-ле слова – одной лишь бумагой и ка-рандашом (даже без использования кластера суперкомпьютеров). Виною тому не сам алгоритм RSA, а ошибки его реализации. Одной из таких реа-

лизаций оказался знаменитый проект OpenSSL, которой вплоть до версии 0.9.8c использовал RSA-ключи с эк-спонентой 3, удаляющие padding-по-ля PKCS #1 до генерации хэш-суммы, что позволяет удаленному атакующе-му подделать PKCS #1 сигнатуру, под-писанную RSA-ключом, и препятству-ет корректной проверке различных цифровых сертификатов, использу-ющих PKCS. А ведь OpenSSL подвер-гался аудиту множество раз. Его ис-следовали и профессионалы, и люби-тели, и просто «интересующиеся», но… результат все сказал сам за себя: на-личие исходных текстов позволя-ет каждому пользователю исправ-лять ошибки, допущенные разра-ботчиками, дорабатывать програм-му под свои нужды, развивать и со-вершенствовать ее сообща.

Прежде чем исправлять ошибку, как минимум, требуется ее воспроиз-вести, а каждый программист, хоть ка-кое-то время проработавший в служ-бе технической поддержки, знает, что практически никто из пользовате-лей не способен грамотно описать ус-ловия, при которых возникает ошибка. А ведь чтобы ее устранить, одной лишь квалификации недостаточно. Первым делом следует разобраться со струк-турой исходных текстов, что требует времени, причем весьма значительно-го. Не лучше ли поручить исправление ошибок самим разработчикам? Что же касается новых возможностей… ну хо-рошо, допустим, разобравшись, какая строка за что отвечает, мы добавили необходимую нам функциональную возможность в программу, изменив десяток файлов в сотне мест. Мы по-сылаем исправленные исходные тек-сты координатору проекта, но нас по-сылают обратно, поскольку уже давно вышла новая версия и никому не ин-тересно «перетаскивать» все измене-ния из старой, к тому же такая функ-циональная возможность, по его мне-нию, никому не нужна, да и реализо-вана она слишком криво, нестабиль-но и вообще идеологически непра-вильно. Если наши изменения не бу-дут приняты и включены в основной проект, это означает, что мы намерт-во привязываем себя к своей «собс-твенной» правленой версии, посколь-ку переход на новые потребует боль-ших трудозатрат.

59№10, октябрь 2006

IMHO

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

Какая-то доля истины в этом ут-верждении есть, но… раскрыть исход-ные тексты это одно, а подобрать до-стойного преемника – совсем другое. Не нужно приводить в пример FireFox, возникший на обломках Netscape, или FAR, создатель которого сосре-доточился на RAR, поняв, что не смо-жет тянуть два проекта одновременно. Возьмите DOS Navigator, пользующие-ся во времена DOS огромной популяр-ностью, особенно в среде программис-тов. Ну и где он сейчас? А ведь исход-ные тексты открыты… Но сплоченной команды разработчиков, подхватив-ших знамя и продолживших «дело Ле-нина», как-то не сложилось и продукт распался на несколько независимых проектов, ни один из которых не полу-чил дальнейшего развития.

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

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

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

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

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

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

ИНКОНЭКСТел.: (495) 739 55 09Факс: (495) 641 22 38

Организатор:

РОССИЯ, МОСКВА, CК ОЛИМПИЙСКИЙ

БЕСПРОВОДНЫЕ И МОБИЛЬНЫЕТЕХНОЛОГИИ В ПРОМЫШЛЕННОСТИ

ТЕ

ЛИ

Б Й

ЫН

ЬЛ

ЕТ

ИС

АЛ

ГИ

РП

ur.xenocni.w

ww

Информационнаяподдержка:

Проезд:

БЕСПРОВОДНАЯ СВЯЗЬ

БЕСПРОВОДНЫЕ СИСТЕМЫБЕЗОПАСНОСТИ

СИСТЕМЫ РАДИОЧАСТОТНОЙИДЕНТИФИКАЦИИ

Москва, Олимпийский пр., 16СК Олимпийский, Северный входМетро: Проспект Мира

ДИСТАНЦИОННЫЙ КОНТРОЛЬИ УПРАВЛЕНИЕ

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

СК ОлимпийскийСеверный

вход

ул. Щепкина

Проспект Мира

Метро: Проспект Мира

S E C U R I T Y

C O M M U N I C A T I O N

CONTROL&AUTOMATION

60

IMHO

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

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

Проба пераУх ты, сколько у нас лазерных дисков скопилось! Без хорошего каталогиза-

тора не обойтись. Но все существую-щие либо неудобны, либо не подде-рживают необходимых нам возмож-ностей, либо хотят немереных денег. Возникает мысль – а что если попро-бовать написать каталогизатор само-стоятельно?! Заодно и в программиро-вании попрактикуемся!

И вот, каталогизатор написан, мы с удовольствуем пользуемся им и… в какой-то момент до нас доходит, что его можно продать. Мысль инте-ресная, но с точки зрения бизнеса не-правильная. Чтобы продавать про-дукт, его нужно очень сильно довес-ти до ума – это раз. Нужно придумать

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

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

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

Оружие против монстровКонкурировать с компаниями-гига-нтами на самом деле не так сложно, как это кажется, особенно, если рас-пространять свой продукт на бесплат-ной основе. Несмотря ни на какие уси-лия Microsoft, весовая доля FireFox и Opera все растет и растет. И хотя стабильности IE ничего не угрожает, Microsoft с большим удовольствием

INCONEXТеl: +7 (495) 739 55 09Fax: +7 (495) 641 22 38

Оrganizer:

SC OLIMPIYSKIY, MOSCOW, RUSSIA

TE

KCI

T Y

RA

TN

EMI

LP

MO

Cur. xen ocni.

ww

w

Informationsupport:

Venue:

WIRELESS DATA COMMUNICATIONEQUIPMENT

WIRELESS SECURITY SYSTEMS

RADIO FREQUENCY COMPONENTS& SYSTEMS

REMOTE CONTROL & TEST SYSTEMS

Opening hours:

SC OlimpiyskiyNorth exit

Ul. Schepkina

Prospekt Mira

Metro: “Prospekt Mira”

S E C U R I T Y

C O M M U N I C A T I O N

CONTROL&AUTOMATION

MOBILE & WIRELESSTECHNOLOGIES

SC Olimpiyskiy, North exit16 Olimpiyskiy pr., MoscowMetro: “Prospekt Mira”

61№10, октябрь 2006

IMHO

скупила бы конкурентов, если бы они только продавались. Многие компании изначально строят свой бизнес на том, что через некоторое время их купит тот, кому они мешают, или тот, кому нуж-на клиентская база. Так было в случае и с WinAmp, и с ICQ… да много можно привести примеров! Вон, легендар-ный исследователь недр Windows Макр Руссинович, и тот продал свой бизнес Microsoft, чем остался страшно дово-лен: http://www.sysinternals.com/blog/2006/07/on-my-way-to-microsoft.html.

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

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

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

Программа как услугаРассматривая программу как товар, мы, во-первых, ввязываемся в вой-ну с хакерами и пиратами, норовящи-ми взломать программу, выложить ее в файло-обменную сеть или распро-странять по цене носителя. А конку-ренция?! Десятки компаний предлага-ют схожие по своим функциональным возможностям программы, и на рын-ке появляются все новые и новые иг-роки. Как говорится, тут не до нажи-вы! Выжить бы… А что!!! И выживем, если начнем рассматривать програм-му как услугу.

Продажи программы – не единс-твенно возможный источник дохо-да. Пусть программа будет бесплат-ной, пусть ею пользуются все желаю-щие! А мы им поможем! Техническая поддержка, всевозможные семинары и тренинги, литература и бумажная до-кументация… Перечень платных услуг можно продолжать бесконечно. В тех-нически сложных программах (таких, например, как IDA Pro, PC-3000) огром-ную роль играет наличие центра обу-чения специалистов, поскольку само-стоятельно разобраться с продукта-ми подобного уровня среднестатисти-ческий пользователь не в состоянии. А программные комплексы еще тре-буют и грамотного внедрения. Здесь мало вставить лицензионный диск и щелкнуть по пиктограмме с надпи-сью «Install»!

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

ных (если один человек «вбил» описа-ние дисков в базу, зачем тысячам дру-гих делать то же самое?!), после чего начнем привлекать лейблы (лейблами (от англ. label, одним из значений кото-рого является «бренд») в музыкальной индустрии называют компании, поку-пающие права на произведения и за-нимающиеся их рекламой, распро-странением и т. д. (см. «record label» на wikipedia – http://en.wikipedia.org/wiki/Record_label)) (или просто магази-ны, торгующие дисками), предоставив им возможность информировать поль-зователей о новинках и вести мони-торинг реальной популярности своей продукции. Ведь если у человека есть два альбома такой-то группы, то сооб-щение о появлении третьего, навряд ли оставит его равнодушным. То есть мы продаем контекстную рекламу, и ос-новным источником прибыли стано-вятся именно лейблы. Прибыль будет тем выше, чем больше у вас пользо-вателей, количество которых обрат-но пропорционально стоимости про-граммы. То есть для достижения мак-симальной прибыли программа долж-на распространяется бесплатно! Наша основная задача – собрать как можно больше пользователей, предоставив им те сервисы, в которых они острее всего нуждаются (заказы новых дис-ков одним кликом мыши, поиск по на-званию файла/композиции в базе, пи-ринговая сеть, наконец!).

Естественно, сразу же возника-ет вопрос о приватности и безопас-ности. Передавая он-лайновой служ-бе описания своих дисков, пользова-тель рискует нарваться на очень круп-ные неприятности, если эти диски – пи-ратские (а в большинстве случаев это так и есть). Следовательно, необходи-мо обеспечить такой механизм пере-дачи данных от пользователей к ба-зе и от пользователя к пользователю, который бы гарантировал со 100% на-дежностью, что ничей IP-адрес не бу-дет «засвечен». Технически добить-ся этого очень легко – достаточно ис-пользовать proxy-серверы, в роли ко-торых могут выступать и сами поль-зователи. Да-да, если информация передается не напрямую, а через це-почку наугад выбранных пользовате-лей, каждый из которых не запоми-нает IP-адрес отправителя, то опре-делить IP-адрес обладателя данного

62

IMHO

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

Вот простой пример бизнес-схе-мы, основанной на бесплатно распро-страняемом программном обеспече-нии. Самое забавное, что написание подобного каталогизатора не требует практически никаких вложений и хо-роший программист напишет его бук-вально за неделю. Однако сам по се-бе он бесполезен, и львиная доля тру-да уйдет на создание обширной ба-зы данных (ну кого из нас не раздра-жает, когда Microsoft CD-Player Deluxe не опознает очередной диск?). Пере-ложив эту задачу на плечи пользова-телей, мы получим базу в обмен на… в том-то и дело, что пользователи не получат ничего.

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

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

В общем, главное фантазию иметь и не зацикливаться на схеме «програм-ма – деньги».

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

Еще одним мотивом к раскрытию кода становится сворачивание рабо-ты над проектом, как произошло, на-пример, в случае с Netscape. К сожа-лению, остальные компании следо-вать этому примеру не хотят. Напри-мер, Compuware, объявившая о пре-кращении поддержки soft-ice, наотрез отказалась отдавать исходные коды последней версии за разумную сум-му, хотя она могла бы их просто по-дарить миру, ничего от этого не поте-ряв. Но… в мире бизнеса законы логи-ки работают по-другому. Это намного хуже, чем собака на сене (по крайней мере, собака на сене лежит, и если она позволит корове съесть его, лежать ей придется на сырой земле, а для хвос-та это нехорошо). Compuware в лю-

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

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

ЗаключениеВсе упирается в деньги. Мы живем не при коммунизме, и окружающие нас товары и услуги стоят денег, сле-довательно, программировать на чис-том энтузиазме можно либо за счет родителей, либо добывая средства к существованию каким-нибудь иным способом (торговлей бананами, на-пример), что превращает программи-рование из ремесла в хобби. Ведь по-мимо бизнес-схем в мире есть и про-стое увлечение, страсть, стремление, азарт, любовь к компьютерам, иногда переходящая в манию, граничащую с помешательством. Есть люди, ощу-щающие буквально физическую пот-ребность писать программы, разра-батывать новые алгоритмы или прос-то проводить за монитором все сво-бодное и несвободное время. Но да-леко не все из них примыкают к дви-жению Open Source, предпочитая дер-жаться в стороне от шумной и пестрой толпы, построенной на бизнесе и про-паганде.

63№10, октябрь 2006

IMHO

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

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

Что движет разработчикамиКак известно, люди ничего не делают просто так. Им непременно нужна мо-

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

Ричард Столлмен в своём пись-ме «Свободному ПО двадцать лет: что дальше?» выделяет два вида моти-вации: отсутствие нужной программы и желание быть свободным [1]. Но, ду-маю, при более детальном рассмотре-нии мотивов будет больше. Коротко охарактеризую основные из них.

Удовлетворение своих нуждНа этот мотив указывает и Столлмен, а также Эрик Реймонд в своей нашу-мевшей статье «Собор и Базар» [2] – иногда случается так, что вы не можете найти готовую программу (пусть даже и за деньги), которая обладала бы нуж-ными вам качествами. Тогда вы разра-батываете её самостоятельно и тем са-мым удовлетворяете свои потребнос-ти. То есть силы и ресурсы, затрачен-ные на разработку и затрачиваемые

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

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

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

Куда приведет Open Source?Только два стимула заставляют людей работать –

жажда заработной платы и боязнь её потерять.

Генри Форд

Движение Open Source зародилось как протест против проприетарного подхода к программному обеспечению и поначалу воспринималось, скорее, как развлечение. Cейчас всё большее число компаний связывают с открытыми проектами свой бизнес. Попытаемся разобраться, что ждёт эти проекты в перспективе.

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

64

IMHO

в свободное плавание». Но этим дви-жут уже другие мотивы...

Программировать, чтобы учиться программироватьЛучший способ научиться говорить по-английски – это говорить по-английс-ки. То же самое и с программировани-ем – практика, и желательно не прос-то уровня «Hello, world!», к чему быстро теряешь интерес, а участие в реальном проекте – это неотъемлемое условие достижения высоких результатов.

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

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

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

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

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

Выполнение должностных обязанностейДа, есть такие счастливцы, которые по-лучают зарплату, разрабатывая откры-тые продукты. Немало программистов, работающих над Linux, найдётся в та-ких компаниях, как IBM, Oracle, не го-воря уже об Red Hat Inc. и Novell, чей бизнес напрямую связан с этой опе-рационной системой. (Нужно заме-тить, что здесь есть и свои ограниче-ния – вложения в открытое ПО ничем не защищены, то есть любой конку-рент вполне может совершенно бес-платно воспользоваться теми резуль-татами, на достижение которых были потрачены немалые средства.)

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

Just for funЗнаменитый «мотив» Линуса Торваль-дса. Да, программирование захваты-вает и доставляет истинное наслажде-ние – вне компьютерной жизни не час-то удаётся почувствовать себя все-могущим творцом. Оно вполне может быть хобби, и для некоторых так оно и есть. А на хобби мы готовы тратить кучу денег и времени, даже не задумы-ваясь о выгоде, отдаче и т. д. Нам это нравится, и этого достаточно.

Но, как пишет сам Торвальдс в сво-ей книге «Just for Fun. Рассказ неча-янного революционера» [3], удоволь-ствие – это третий, заключительный этап эволюционирования любой ве-щи. Этому этапу предшествуют борь-ба за выживание и достижение соци-ального статуса. То есть программи-ровать просто так, ради одного лишь удовольствия, человек будет только после того, как накормит свою семью, обеспечит ей крышу над головой, за-воюет устойчивое положение в обще-стве. И если только вы не владеете со-лидным пакетом акций какой-нибудь

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

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

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

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

Кстати говоря, идеологические принципы, лежащие в основе дви-жения FOSS (Free and Open Source Software), всё чаще подвергаются сом-нению. Не так давно даже Эрик Рей-монд выразил мнение, что открытые проекты более лояльно должны от-носиться к коммерческим системам и, в частности, к включению проприе-тарного кода в открытые продукты [5]. Это, по его мнению, является ключе-вым условием сохранения жизнеспо-собности Linux.

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

65№10, октябрь 2006

IMHO

ный противник. Не намного сильнее, чтобы борьба с ним не выглядела без-надёжным делом, но всё же находя-щийся впереди. Сейчас такой против-ник есть – коммерческое ПО. Оно го-раздо сильнее распространено, и за-частую лучше свободных аналогов. (Что бы там ни говорили, но я исполь-зую AbiWord для подготовки этой ста-тьи лишь потому, что он бесплатен и работает в Ubuntu, а вовсе не потому, что он лучше MS Word технически.)

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

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

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

«Шкурный интерес»Не подлежит, думаю, ни малейшему сомнению тот факт, что любое вло-жение, осуществляемое коммерчес-кими компаниями, направлено на по-

лучение прибыли. (Единичный слу-чай с Canonical Ltd. принимать во вни-мание не будем – не каждому мульти-миллионеру захочется тратить свои деньги так, как это делает Шаттлворт. Да, кстати говоря, и Canonical не только благотворительностью занята.)

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

Проекты под заказЭто, скорее, теоретическая возмож-ность, нежели практический пример. Суть открытого и свободно распро-страняемого ПО в том, что получив тем или иным способом (в том числе и купив) программный продукт, вы мо-жете легко передать его кому-то ещё по меньшей стоимости или даже бес-платно. Фактически, разработчик по-лучает гарантию только на первую продажу. Так что если сделать перво-начальную стоимость продукта доста-точно высокой, то таким путём мож-но попытаться компенсировать за-траты на разработку и даже получить прибыль.

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

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

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

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

Борьба с конкурентамиИ снова сразу же вспоминается IBM. Она ведёт свой бизнес в самых раз-личных секторах рынка. И, например, в секторе корпоративных баз данных одним из основных конкурентов IBM является Microsoft. Но Microsoft имеет интерес и в секторе операционных сис-тем, куда IBM уже давно не стремится. Так что если поддерживать бесплат-ную ОС, то можно нанести серьёзный урон своему конкуренту, ничуть не пос-традав самому.

И если в предыдущем случае (про-движение других товаров) компания-спонсор так или иначе диктует свои требования разработчикам, чтобы по-лучить те свойства продукта, которые соответствовали бы её маркетинго-вым целям, то для того чтобы «подло-жить свинью» конкуренту, достаточно просто создать участникам открытого проекта условия для разработки пре-восходной программы. С точки зрения сообщества этот способ меценатства наиболее хорош. К тому же, если вам не нужна корпоративная СУБД, то и пе-реплачивать за неё вы не будете.

Техническая поддержкаНа этом в значительной степени строят свой бизнес такие компании, как Red Hat Inc., Novell, Mandriva... То есть ос-новной источник дохода – не продажи программы, а плата за её обслужива-ние. Поскольку люди, особенно в кор-поративном секторе, хотят просто де-лать свою работу с помощью компью-тера – рассчитывать фундамент зда-ния, рисовать дизайн будущего ав-томобиля, раскладывать пасьянс, – то они совсем не желают знать, что та-

66

IMHO

кое файловая система и загрузчик, не говоря уже о том, чтобы это ещё и настраивать.

Отвлекусь на небольшое наблюде-ние. Очень многие готовы, не задумы-ваясь, отдать некоторую сумму за то, чтобы им настроили подключение к Интернету на домашней Windows XP. То есть операция «Пуск → Все про-граммы → Стандартные → Связь → Мастер новых подключений» являет-ся для них непосильной задачей. Безо всякой иронии скажу, что так и должно быть – не дело бухгалтера или врача разбираться в «драйверах», «логинах» и «IP-адресах» (хотя Microsoft и делает всё, чтобы пользователю приходилось с этим сталкиваться как можно мень-ше). А открытые проекты, где доволь-но часто помощь ограничивается аб-бревиатурой «RTFM», не зря славятся своей сложностью.

Кстати говоря, нынешнее отноше-ние разработчиков многих открытых программ к своим пользователям сти-мулирует возврат к натуральному хо-зяйству: «Вы же получили исходники? Если что-то не нравится, нанимайте программиста и переделывайте, как вам надо». Как указывается в анали-тическом отчёте компании Elashkin Research [6], даже если специалисты необходимой квалификации уже есть в компании, работодатель фактически будет вынужден оплачивать их занятие непрофильной деятельностью.

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

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

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

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

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

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

Свобода во всёмКонечно, есть ряд проектов, разра-батываемых как «некоммерческие».

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

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

Шаг в бизнесЕщё одна тенденция наших дней – ком-пании, строящие свой бизнес на откры-тых проектах, всё чаще говорят о не-обходимости более явно переходить на коммерческие рельсы. Например, Саймон Фиппс, занимающий руково-дящую роль в Sun Microsystems, при-звал сообщество Open Source «усво-ить уроки капитализма и капиталис-тов» [7].

Особо показательна позиция рос-сийской компании «LINUX-ONLINE» – разработчика дистрибутива Linux XP Desktop. Её «манифест» [8] явно де-кларирует, что при сохранении до-ступности Linux «каждому пользова-телю PC» в Linux необходима сильная коммерческая составляющая. К со-жалению, нужно признать, что это не просто маркетинговый ход, наце-ленный на продвижение своего дис-трибутива (хотя сами они указывают, что разрабатывают не «дистрибути-вы», а «решения»), а вполне обосно-ванная позиция.

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

67№10, октябрь 2006

IMHO

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

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

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

Назад в будущееПолучается, что бизнес-модель Open Source не подкреплена достаточно надёжными и долгосрочными ресур-сами, гарантирующими качественное и эффективное развитие и в будущем. Так есть ли это будущее у открытых проектов вообще?

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

По большому счёту движение Open Source зародилось именно в на-учной среде. BSD, UW-IMAP, Exim, X-Window являются хорошими приме-

рами. Эти проекты и сейчас во многом опираются на университеты.

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

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

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

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

Подводя итогиТаким образом, можно сделать вывод, что дальнейшее развитие Open Source рано или поздно упрётся (наверно, можно сказать, что уже упирается) в недостаток разработчиков, не го-воря уже о «сотрудниках», занятых на таких неинтересных направлениях,

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

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

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

Третий путь – переход на науч-ные принципы разработки без огляд-ки на число вовлечённых пользовате-лей, показатели TCO, привлекатель-ность для инвесторов. А все «рыноч-ные» вопросы оставить на откуп ком-мерческим компаниям.

Что получится на самом деле – вре-мя покажет.

Удачи!

1. Столлмен Р. Свободному ПО двад-цать лет: что дальше? – http://zdnet.ru/?ID=312009.

2. Реймонд Э. Собор и базар – http://www.seagreen.ru/free/esr/esr_cathedral-bazaar2.html.

3. Торвальдс Л., Даймонд Д. Just for Fun. Рассказ нечаянного революционе-ра. – Эксмо-Пресс, 2001.

4. Безруков Н. Повторный взгляд на Собор и Базар – http://www.linux.org.ru/books/GNU/misc/second-look-at-CatB.html.

5. http://www.nixp.ru/news/76706. Бизнес модель Open Source – перспек-

тивы и угрозы. Elashkin Research – http://www.elashkin.com.

7. http://www.nixp.ru/news/7583.8. М а н и ф е с т L i n u x X P D e s k t o p –

ht tp: / / l inux-online.ru /about /ar t ic les /detail.php?ID=897.

68

IMHO

Наиболее полный и многофактор-ный анализ явления Open Source дается в материалах Elashkin

Research (http://www.elashkin.com), а именно в работе «Бизнес-модель Open Source. Перспективы и угрозы». Можно даже сказать, что исчерпываю-щий. Но я предлагаю обратиться к ука-занному источнику лишь тем, кто нуж-дается в терминологических поясне-ниях, то есть не знает ничего о пред-мете, или склонен к академическо-му способу мышления, то есть хочет знать все. Я не буду ставить перед со-бой цели объять необъятное. Отвечу лишь на один главный вопрос: есть ли нечто, что угрожает Open Source? В об-суждении будем придерживаться тер-минологии, введенной упомянутой статьей, и главный объект называть Open Source Software (OSS) или про-

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

Итак, в чем феномен OSS? Он про-являет себя и в сфере технологий, и в сфере общественных отношений, а главное, в сфере экономики. Мож-но бесконечно долго восхищаться тем, как проекты OSS создаются, ка-залось бы, сами собой, можно беско-нечно долго митинговать на тему про-тивостояния «старого мира» и сторон-ников OSS, но самое главное, что биз-нес OSS на первый взгляд не содержит стандартной экономической цепочки «товар-деньги-товар». Вот, что осо-бенно поражает при рассмотрении OSS, то, что производитель отдает то-вар даром! Где же тут бизнес? Можно ли после этого разработчиков считать

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

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

Open Source взглядом оптимиста

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

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

69№10, октябрь 2006

IMHO

игнорирующее все экономические за-коны, оказывать такое сильное влияние на экономику? Одно из двух: или OSS – это секта, религия или партия анархис-тов, тогда «ату их» без всяких рассуж-дений о выгодности или невыгодности для потребителей, так как в этом слу-чае OSS – это уже общественно-по-литическое явление. Или OSS – это вид новой экономики, и все противни-ки OSS сознательно лгут! Думаю, вто-рое. И докажу это. Бизнес-модель OSS полностью подчиняется всем экономи-ческим законам. В рамках этой моде-ли потребители платят за товар, а про-изводители получают деньги за работу. Начнем обсуждение с производителей, так как именно эта сторона экономи-ческой цепочки обязательно идентифи-цируется (хотя бы авторским правом) и поэтому в первую очередь подверга-ется нападкам противников OSS.

Разработчики OSS не филантропыО, сколько догадок на счет мотива-ции разработчиков OSS высказано в прессе и на страницах вполне серь-езных монографий. И тема эта никогда не исчерпается. Ключевое слово в этих опусах «даром». А логическая связ-ка строится так: разработчик трудит-ся – даром! Что такое «даром» в эко-номике? Это значит, что в процессе передачи некоторого товара его стои-мость не учитывается. Ну а в отноше-нии разработчиков OSS, что они пи-таются святым духом, так как, создав ценный продукт, не взяли за него пла-ту. Если бы это было так, то тема OSS исчерпала бы себя естественным пу-тем после смерти от голода последне-го безумного разработчика. Учитывая, что обычный человек без пищи не смо-жет прожить более месяца даже с по-мощью мантр, то OSS не продержалось бы такое время и уж точно не смогло расти подобными темпами. Значит, все ложь с самого начала. С этого звонко-го слова «даром».

Итак, первая аксиома: все участни-ки процесса OSS со стороны разработ-ки за свой труд получают... выгоду!

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

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

Теперь можно дать ответ на воп-рос, почему так многочисленны вер-сии защитников о преимуществах OSS и столь же велики числом доводы про-тивников. Все они описывают частные условия, гарантирующие или препятс-твующие реализации выгод, получен-ных от продажи продукции, созданной OSS. Хотя ключевых факторов совсем немного. И в упомянутой выше рабо-те они названы среди прочих: «В ос-нове этого явления лежит огромный рост скорости обмена информацией и чрезвычайно низкая стоимость это-го процесса». Конечно, не надо пони-мать, что, протянув высокочастотный канал из Европы в Америку и дождав-шись амортизации его стоимости, мы создадим OSS. Ключевое слово – «Ин-тернет»!

В становлении OSS сыграли глав-ную роль три фактора:1. Интернет, как средство доставки,

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

Примеры: владение недорогим хостингом

обходится менее 80 $ в год; неограниченный трафик досту-

пен за 25 $ в месяц. Этот фактор позволяет снизить

стоимость оборота продукции OSS и одновременно реализовать ряд преимуществ путем привлечения определенной аудитории к сайтам, связанным с OSS.

2. Интернет, как средство рекрути-рования и интеграции разработ-чиков OSS.

Примеры: все проекты имеют свои «домаш-

ние» сайты и электронную почту для связи с разработчиками;

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

Этот фактор снижает стоимость разработки и сопровождения OSS и обеспечивает ее сотрудниками.

3. Интернет, как среда электрон-ных платежей.

Примеры: для работы с OSS и аналогичной

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

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

Могут ли перечисленные факторы исчезнуть или перестать действовать? Иначе говоря, угрожает ли что-то Ин-тернету? Конечно, да! Война, напри-мер. Стоит ли об этом беспокоиться? Конечно, да! Стоит ли это обсуждать не как фактор политики, а именно от-раслевой экономики? Конечно, нет!

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

Смотрите, что выходит. Разработчи-ку необходимо получать плату за свой труд, чтобы иметь средства к сущест-вованию. Участие разработчика в про-екте OSS обеспечивает такую возмож-ность. Что еще надо, чтобы доказать, что разработчики все-таки имеют доход от своей деятельности? Скептики хотят узнать «как»? Надо «схватить за руку» и прямо вручить «ключи от квартиры, где деньги лежат», а то ведь не пове-рят! Но не забывайте, в этом разделе мы обсуждаем только сторону разра-

70

IMHO

ботки. То есть здесь не будем затраги-вать, «почему» платят за бесплатные продукты категории OSS, а просто при-мем, что это есть. Допустим это!

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

Потребителям нравится платить за продукты, созданные как OSSВот это самое спорное утверждение. Именно здесь скрыт секрет успеха OSS. Скептик с незамысловатым умом ска-жет, что такое невозможно, зачем пла-тить за то, что получают даром! И здесь обычно сторонники OSS начинают нуд-ный разговор о вторичных способах по-лучения дохода, а значит и о вторичных способах взимания платы. Ну, вроде то-го, что «бесплатный сыр только в мы-шеловке» и прочее. Чем сами себя в угол загоняют, кроме того, что прояв-ляют еще и чудеса сутяжничества.

При обсуждении этого вопроса про-тивники OSS рассматривают мотива-цию абстрактного отдельно взятого че-ловека и задают вопрос, «зачем пла-тить за то, что даром». Это логическая ловушка. Надо рассматривать не отде-льного человека, а общество в целом или отдельного человека в обществен-ном окружении. Как формируется моти-вация такого человека? Есть уже дока-занная теория об иерархии потребнос-тей, известная как пирамида Маслоу. Чего может добиться человек, оплатив-ший бесплатный продукт? Если он на-ходится на низшей ступени, где важно удовлетворение физиологических пот-ребностей, то такой поступок приведет к тому, что далее ему не хватит средств для чего-то насущного. Если он нахо-дится на ступени, где важна его бе-зопасность, такая растрата уменьшит бюджет мероприятий безопасности. А вот если он уже стоит на том уровне, где важны потребности группы, или да-же там, где важно уважение его самого, то все кардинально меняется.

В этом секрет того, что люди при-соединяются к OSS-проектам и ниче-го не просят взамен – им важна при-

частность к группе! И аналогично, они с удовольствием поддерживают OSS-проекты, так как им важно, что такая поддержка приносит им уважение!

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

Господа из Elashkin Research пишут об этом так: «...OSS использует более современные модели маркетинга...», и чуть далее «...методы движения Open Source ближе всего к методам ново-модных сект и религиозных течений.» От таких слов хочется поморщиться и сказать, что здесь явно происходит манипуляция истиной. Хотя далее они же признаются: «Основной вектор рас-пространения OSS направлен на тех-нических специалистов и социально активных людей...». Ну, здесь совсем немного осталось, чтобы догадаться, что «технические специалисты и соци-ально активные люди» – это именно те, кто занимает верхушку пирамиды Мас-лоу. Может быть, в следующем опусе специалисты из Elashkin Research оз-вучат и эту мысль.

Теперь снова зададимся вопросом, что угрожает OSS с этой точки зрения. Что может разрушить иерархию пот-ребностей и отбросить людей на ниж-ние уровни? Ответ очевиден: факторы, которые могут привести к экономичес-кому регрессу. Даже более того, только в развитых странах, где число граждан, соответствующих верхним уровням пи-рамиды Маслоу, достаточно велико, может зародиться и развиваться дви-жение OSS. Специалисты из Elashkin Research приходят к тому же выводу путем анализа вторичных способов за-

работка на OSS с помощью сервисно-го обслуживания: «...на практике высо-кий уровень сервисов в IT-экономике характерен как раз для развитых рын-ков и «богатых» стран.» Но далее они делают главную ошибку. Они считают услуги по сопровождению OSS глав-ным источником дохода в бизнес-мо-дели Open Source. И все их заблужде-ния, обиды и сетования на обманутые ожидания основаны на этой вздорной идее. Например, можно там прочесть такую фразу: «В отсутствие примеров стран с высокой долей Open Source...». Что это? Неужели кто-то ждет появ-ления стран с доминирующим уров-нем сервисных услуг? Ну, разве лишь кто-то очень наивный. Это все равно, что требовать от всего гражданско-го населения высокой сознательнос-ти прямо с пеленок. Утопия! Но с дру-гой стороны, чем не упрек OSS? Вот, мол, не сможете победить и не смо-жете заменить Linux-ом MS Windows! А зачем? Человек не может питаться только сладким эскимо, смотреть толь-ко боевики, читать только детективы и всю сознательную жизнь не работать по найму, а играть в теннис. Возможно, это идеал для кого-то, но не правило. Пирамида Маслоу сужается к верши-не – вот это правило! Поэтому одно из ключевых утверждений аналитики от Elashkin Research, что «тезис о поль-зе OSS для ускоренного развития рын-ка высоких технологий пока не находит своего подтверждения», не более чем уловка (или ошибка, не знаю, что ху-же). Дело в том, что не OSS приводит к развитию высоких технологий, а раз-витие технологий в высокоразвитой общественной среде порождает OSS!

Зарождение OSS является «лак-мусовой бумажкой», отмечающей до-стижение обществом определенного уровня развития как в технологичес-ком плане, так и в плане обществен-ных отношений. Поэтому все рассуж-дения от Elashkin Research на счет OSS в России, а особенно выводы, постро-енные на российской статистике, сме-ху подобны. OSS в России нет! Есть разработчики-россияне, участвующие в международных OSS-проектах. Есть отдельные компании, ведущие успеш-ный бизнес в секторе OSS. Но никакое внедрение OSS в странах с развива-ющейся экономикой, например в Ин-дии, в Китае и в обсуждаемой России,

71№10, октябрь 2006

IMHO

не изменит статус этих стран. Так как подобные страны становятся лишь на-хлебниками OSS-проектов и попадают в зависимость от них. И тут уже совер-шенно правильно отмечено, что «даль-нейшее развитие IT в стране будет тор-мозиться.» Я бы даже усугубил. OSS – это реинкарнация «халявы». В свое время украденные технологии IBM 360 сыграли решающую роль в погребе-нии отечественной IT. И теперь выжи-вет лишь та страна, которая не только возьмет все от OSS, но и вернет об-ратно не менее! Значит, лишь тогда можно утверждать о существовании OSS в России, когда наша страна ста-нет оплачивать собственные проекты OSS, и эти проекты станут востребо-ваны за рубежом. А в противном слу-чае все мы превратимся в обслужива-ющий персонал, сопровождающий чу-жие OSS-проекты.

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

Говоря иначе, потребители OSS вы-нуждаются или работать на него, или платить за него. И поэтому распростра-нение OSS в станах третьего мира мо-жет привести лишь к тому, что где-то в Центральной Африке станут чтить нового белого колдуна Марка, но не стоит ждать, что появятся африканс-кие инкубаторы OSS, которые будут рекрутировать в свои проекты евро-пейцев. OSS – это своего рода «тро-янский конь». Принятие такого подар-ка не принесет ничего хорошего ника-кой «Трое».

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

Перспективы OSSCтало ясно, что внутри OSS все готово для получения доходов, а потребитель-ская среда точно так же готова платить, если не прямо по счету, то опосредо-ванно как минимум. Так что же теперь мешает создать и развивать OSS, на-пример, в той же России? Может, нужен

указ Думы, и тогда мы все бросимся писать «бесплатные программы»?

Что вообще нам для этого нужно? Дешевый Интернет? Смотрю на свой ADSL-роутер, вроде уже есть. Высоко-развитое демократическое общество? Смотрю на экран телевизора, говорят, что тоже есть. Обеспеченные гражда-не с высоким уровнем самосознания? Смотрю в окно на проезжающие доро-гие автомобили и догадываюсь, что их тоже изрядно. Почему же нет OSS? Тут мне возразят: «А как же ALT Linux, Этерсофт и другие, которые разра-батывают оригинальный отечествен-ный OSS?» Дело в том, что эти компа-нии вынуждены строить свой бизнес по традиционной схеме, и их бюджет пополняется из поступлений от про-даж по традиционным физическим каналам. Сравните их с Fedora Project или с openSUSE. Почувствуйте разни-цу между мелкими частными инициа-тивами и деяниями транснациональ-ных корпораций. Для того чтобы OSS-проект мог успешно развиваться, он не должен попадать в тиски жестких потребительских требований. То есть надо исключить диктат неграмотного потребителя, голосующего «рублем».

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

Тут самое время задать вопрос, а в какой форме общество может вы-разить свой интерес в OSS. Не будем обсуждать зарубежные страны. Попро-буем ответить, как это может произой-ти в нашем отечестве.

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

признать достаточными, то послед-ним требованием будет финансиро-вание. То есть надо «влить» в систе-му «кровь», и она заработает. Вот это-го-то и не происходит!

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

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

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

72

IMHO

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

ВыводыДля многих противостояние OSS и проприетарного ПО сосредоточе-но в соревновании Linux vs Windows. Это очень примитивно, но почти вер-но. Ошибкой является стереотипное приравнивание MS Windows к старому и капиталистическому, а Linux – к ново-

му и коммунистическому. Отсюда и на-прасное ожидание, что Linux и все про-дукты, произведенные OSS, окажутся дешевле проприетарных. А происходит ровно наоборот. Именно Linux получа-ется дороже в эксплуатационном цик-ле для корпоративных потребителей, чем MS Windows. Да, согласен, пото-му-то я и работаю на Linux, что это при-носит больше прибыли при меньших усилиях. Linux и другие OSS являют-ся следующей за проприетарными мо-делями формой развития IT-отрасли. И соответственно они несут большую эксплуатацию разработчикам, дороже для потребителей и выгоднее для ин-весторов. Но не надо ждать, что движе-ние OSS будет добиваться успеха пов-семестно. С появлением коммунисти-ческих и развитых демократических стран на планете Земля история мно-гих феодальных и даже рабовладель-ческих государств вовсе не заверши-лась путем добровольного присоеди-нения к СССР. Но так же, как неизбе-жен прогресс в общественных отноше-ниях, так и распространение OSS уже

не остановить. Потому что он усилия-ми таких компаний, как IBM и Novell, превращается в инструмент неогло-бализма.

И теперь можно ответить на воп-рос, угрожает ли что-нибудь OSS. Нет, не угрожает! Напротив, это сам OSS уг-рожает оригинальным коммерческим проектам. Чужой, импортированный OSS – это быстрая и сладкая смерть национальной IT-индустрии той стра-ны, которая не сможет противопоста-вить аналогичный свой OSS. Зачем вы-возить «мозги»? Можно подарить «бес-платный» OSS и тем привлечь чужих специалистов к обслуживанию науко-емкой индустрии «доброго дяди» вза-мен отечественной.

Столлман со товарищи, конечно, революционеры. Но как учит История, после каждой революции создается свой «НКВД», и за каждый подарок прогресса надо платить. Обесценив процесс получения программных про-дуктов, ведущие индустриальные стра-ны подняли цену его владения на недо-сягаемую для прочих высоту!

73№10, октябрь 2006

bugtraq

Переполнение буфера при обработке ELF-файлов в Linux-ядреПрограмма: Linux kernel версии до 2.6.17.11.Опасность: Низкая.Описание: Уязвимость существует из-за ошибки на плат-формах IA64 и SPARC при обработке определенных ELF-файлов. Локальный пользователь может с помощью специально сформированного ELF-файла аварийно завер-шить работу системы.URL производителя: http://www.kernel.org.Решение: Установите последнюю версию ядра (2.6.17.11 или выше) с сайта производителя.

Целочисленные переполнения буфера в FreeBSDПрограмма: FreeBSD 5.2-5.5.Опасность: Низкая.Описание: 1. Уязвимость существует из-за ошибки провер-ки входных данных в реализации ядра в i386_set_ldt(). Ло-кальный пользователь может вызвать панику ядра. Также существует потенциальная возможность выполнения про-извольного кода.

2. Целочисленное переполнение буфера обнаружено из-за недостаточной обработки входных данных в функции i386_set_ldt(). Локальный пользователь может вызвать от-каз в обслуживании системы.URL производителя: http://www.freebsd.org.Решение: В настоящее время способов устранения уязви-мости не существует.

Переполнение буфера в libX11Программа: libX11 до версии X11R6.5.1.Опасность: Низкая.Описание : Переполнение буфера обнару жено в _XKB_CHARSET-переменной окружения, когда DISPLAY установлен как «X Window System server» с включенным XKEYBOARD-расширением. Успешная эксплуатация уяз-вимости позволяет получить привилегии приложения, ди-намически подключенного к библиотеке.URL производителя: http://www.libx.org.Решение: Установите X11R6.5.1 или более позднюю вер-сию.

Обход ограничений безопасности в PHPПрограмма: PHP 4.4.4 и более ранние версии, PHP 5.1.6 и более ранние версии.Опасность: Низкая.Описание: Уязвимость существует из-за недостаточного ограничения на смену параметров safe_mode и open_basedir в функции ini_restore(). Если эти ограничения установлены в настройках виртуального хоста веб-сервера, а в файле php.ini находятся значения по умолчанию, злоумышленник может восстановить значения по умолчанию и обойти огра-ничения, установленные в конфигурационном файле веб-сервера. Пример уязвимой конфигурации:

Эксплоит:

Удачная эксплуатация уязвимости позволит злоумыш-леннику получить доступ к содержимому произвольных файлов на системе.URL производителя: http://www.php.net.Решение: В настоящее время способов устранения уязви-мости не существует.

<Directory /usr/home/frajer/public_html/> Options FollowSymLinks MultiViews Indexes AllowOverride None php_admin_flag safe_mode 1 php_admin_value open_basedir /usr/home/frajer/public_html/</Directory>

<?echo ini_get("safe_mode");echo ini_get("open_basedir");include("/etc/passwd");ini_restore("safe_mode");ini_restore("open_basedir");echo ini_get("safe_mode");echo ini_get("open_basedir");include("/etc/passwd");?>

Множественные уязвимости в IBM DirectorПрограмма: BM Director 5.x.Опасность: Низкая.Описание: 1. Уязвимость существует из-за недостаточной обработки входных данных в параметре file в файле Redirect.bat. Удаленный пользователь может просмотреть содержи-мое произвольных файлов на системе. Пример:

2. Уязвимость существует из-за ошибки при обработ-ке запросов к WMI CIM-серверу. Удаленный пользователь может аварийно завершить работу службы.

3. Уязвимость существует из-за ошибки при обработ-ке запросов. Удаленный пользователь может аварийно за-вершить работу IBM Director.

4. Удаленный пользователь может получить доступ к файлам куки и аутентификационным данным в HTTP-за-головках с помощью функционала HTTP TRACE.URL производителя: http://www.ibm.com.Решение: Установите последнюю версию (5.10) с сайта производителя.


http://[host]:411/cgi-bin/Redirect.bat?file= ↵ %7C..\..\..\..\..\..\....\..\[file]

Переполнение буфера в Sun SolarisПрограмма: Sun Solaris 8, 9, 10.Опасность: Низкая.Описание: Уязвимость существует из-за ошибки провер-ки границ данных в libX11. Локальный пользователь может вызвать переполнение буфера и выполнить произвольный код на целевой системе с привилегиями приложения, ди-намически подключенного к библиотеке.URL производителя: http://www.sun.com.Решение: Установите последнюю версию с сайта произ-водителя.

74

образование

Что должно быть на уроках информатики?Сейчас со школьным предметом «Ин-форматика» сложилась довольно не-приятная ситуация – он теряет роль

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

Однако основная задача средней школы – дать общее образование,

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

Python – в школу!


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

75№10, октябрь 2006


гии не преподаётся практика протези-рования зубов. Эти вопросы – уже за-дача профессионального образования, но никак не общего.

А вот с информатикой получилась ситуация как раз противоположная. Определённые «общие» понятия, та-кие как архитектура ЭВМ (по плака-там, нарисованным в 80-х годах) и ос-новы алгоритмизации, по инерции ещё преподаются, хотя порой и с до-вольно сильным отрывом от действи-тельности.

А вот практическая составляющая сводится к программам типа «Вве-дите A, введите B, получите A + B» на Бейсике и «глубокому» освоению процедуры создания таблицы в Word, когда любое отклонение мышки от за-данной преподавателем траектории жестоко карается...

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

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

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

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

Ну а как тогда объяснить школьни-ку, как именно работает операционная система или тот же Word? Без понима-ния основ программирования, без при-косновения к ним на практике инфор-мационные системы так и останутся «чёрными ящиками», а неизвестность ведь всегда пугает.

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

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

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

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

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

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

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

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

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

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

Почему Python – лучший выбор?Теперь попытаюсь объяснить, поче-му я вынес в заголовок статьи имен-но Python. Анализ сформулирован-ных выше критериев показывает, что Python в той или иной мере соответс-твует всем этим требованиям.

Написать первую программу на нём предельно просто:

76


И всё! Если потребуется в буду-щем показать на практике концеп-цию переменных, просто развиваем этот скрипт:

И так, шаг за шагом, можно зайти настолько далеко, насколько это пот-ребуется. Вплоть до графического ин-терфейса и объектов. Причём Python позволяет выбирать любую стратегию преподавания: и быть «на шаг впере-ди», когда с каждым разом вводятся всё новые и новые понятия, и «на шаг позади», когда сами ученики начинают чувствовать, что какую-то задачу мож-но решить проще, и таким образом, за-дают темп движению вперёд.

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

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

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

Прибавим к этому лёгкость, с ко-

торой читается код на Python. Про-граммиста, написавшего тысячи строк на Java, все эти отступы могут раздра-жать, но для начинающего разработчи-ка они позволяют не запутаться в собс-твенном коде, не говоря уже про чужой. А ведь умение разбираться в чужом, уже готовом коде, и использовать его в своей программе – это тоже непре-менный и очень важный элемент про-граммирования, о котором почему-то часто забывают.

Далее, Python – безусловно, совре-менный язык. Достаточно открыть лю-бой дистрибутив Linux и посмотреть, что используется для многих средств администрирования и даже игр. Это же говорит и о том, что им пользуются на практике, что это – «живой», пос-тоянно развивающийся язык програм-мирования.

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

А что же его «конкуренты»? Basic и Pascal, внеся немалый вклад в раз-витие информационных дисциплин, к сожалению, потеряли свою актуаль-ность. Их «визуальные» последовате-ли – Visual Basic и Delphi – мало пригод-ны для преподавания программирова-ния, поскольку не позволяют видеть скрывающийся за «мастерами» код, и тем самым не дают полного понима-ния того, как на самом деле работают программы. Да и высокая стоимость инструментов разработки не позво-ляет их применять достаточно широ-ко (даже если школы и получат их по какой-нибудь льготной «академичес-кой» лицензии, школьники всё равно будут лишены возможности поставить на свой домашний компьютер полно-ценную версию).

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

Perl? Да, хороший, мощный, ни

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

В последние годы Perl всё больше и больше вытесняется набирающим силу PHP, причём не только на ниве веб-программирования. Безусловно, это очень простой и понятный язык, но, на мой взгляд, он имеет и те чер-ты, которые я отнёс к недостаткам язы-ка Perl, в частности, излишнюю «воль-ность» стиля. Плюс к этому его (былая, но ещё не забытая) ориентированность на веб-разработку может привести к слишком однобокому подходу в его преподавании.

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

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

1. Ремнёв А. А. Программирование в кур-се средней школы. – http://som.fio.ru/item.asp?id=10009522

2. Ильясов А. Н. Один из подходов к изу-чению программирования в базовом курсе информатики средней школы – http://www.ito.su/2001/I/I-2-38.html.

message = ‘Ура! ↵ Я использую переменные!!!’print message

print ‘Ура! Я программирую!!!’

77№10, октябрь 2006

полезные советы

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

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


Используйте xrange()В Python, как известно, нет цикла for в стиле языка C – здесь for выполняет проход по элементам последователь-ности (в Perl есть похожий оператор – foreach). Поэтому для построения циклов, записываемых, скажем, в Perl как for($i=0; $i < 1000; $i++), в Python используется фун-кция-генератор последовательности – range(), формирую-щая список целых чисел, по которому затем и выполняет-ся цикл: for i in range(1000).

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

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

Использование range() с таким значением привело бы систему к непрерывному «свопингу».

for i in xrange(10000000): . . . .

Складывайте строки вдумчивоСложение строк в Python выполняется не слишком быстро. Поэтому если вам нужно получить строку из списка элемен-тов, лучше использовать для этого метод join:

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

А вот повсеместный совет вместо strA + strB использовать форматное преобразование ‘%s%s’ % (strA, strB), на прак-тике не подтвердился – по крайней мере, в Python 2.4.3 про-стое сложение выполнялось примерно на 35% быстрее, чем форматирование. С ростом размера строк этот разрыв со-кращается, но даже при сложении строк из 26000 символов традиционное суммирование выполнялось быстрее.

#s = ''#for i in xrange(1000000):# s += str(i)s = ''.join([str(i) for i in xrange(1000000)])

Подружитесь с lambdaИногда возникает необходимость использовать некоторую функцию «локально». В Python использовать безымянную функцию позволяет оператор lambda:

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

>>> a = lambda a,b: a*a + a*b + b*b>>> a(2,3) # аргументы 2 -> a, 3 -> b19>>> (lambda a,b: a+b)(2,3)5

Используйте функцию map()И не только её. Python предоставляет три мощных функ-ции для обработки последовательностей – map(), filter() и reduce(). Первая позволяет применить к каждому эле-менту одной или нескольких последовательностей задан-ную функцию, вторая – получить подпоследовательность по тому или иному критерию, третья – «свернуть» последо-вательность (например, просуммировать все элементы):

Это не только удобно, но и быстро, поскольку внутрен-ний цикл этих функций реализован на C. Для функции filter() показано применение lambda-функции. Так же можно бы-ло бы поступить и в случае с reduce(), но для наглядности оставлен «классический» способ.

>>> def tostr(a, b):... return a + b...>>> list = [1,2,3,4,5]>>> map(str, list)['1', '2', '3', '4', '5']>>> filter(lambda i: i>3, list)[4, 5]>>> reduce(tostr, list)15>>> reduce(tostr, map(str, list))'12345'

Выносите максимум за пределы циклаИстина, известная любому студенту. В Python за пределы цикла можно вынести даже определение методов:

Казалось бы – какая мелочь! Но благодаря тому, что на каждой итерации цикла интерпретатору не приходится искать метод append() у объекта list, этот код выполняется быстрее «обычного» почти на 30% (на реальных, более по-лезных циклах, конечно, прирост скорости будет не столь ошеломительным).

list = []func = list.appendfor i in xrange(5000000): # list.append(i) func(i)

78

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

Многопроцессорные системы имеют свою специфику, с ко-торой программисты, работа-

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

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

Многоядерные процессоры и проблемы, ими порождаемые, в ОС семейства NT

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

Крис Касперски

79№10, октябрь 2006


цы могли позволить себе иметь такую штучку на рабочем столе.

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

Проблема на самом деле очень се-рьезна и относится не только к про-граммистам-самоучкам, клепаю-щим мелкие утилиты, но затрагива-ет и весьма именитые корпорации, в том числе специализирующиеся на мобильных устройствах. Вот что пи-шет AMD в руководстве по програм-мированию под многоядерные про-цессоры: «...the primary issues that the mobile industry typically faced involved maximizing performance in a battery-operated environment, handling sleep states and non-standard display and I /O subsystems, and low-vo l tage considerations. Thus, many device drivers were tuned to maximize reliability and performance in those singleprocessor mobile environments: and many haven’t even been tested in a multiprocessor system, even in the manufacturer’s own test lab» («…основная проблема в том, что мобильная индустрия в основном сосредоточена на максимизации про-изводительности в условиях питания от батарей, обработке «спящего» со-стояния, нестандартных дисплеев, подсистемы ввода/вывода и умень-шении питающего напряжения. Поэ-тому большинство драйверов наце-лено на максимальную надежность и производительность в однопроцес-сорном окружении. Многие из них не были протестированы на много-процессорных машинах, даже в про-изводственных тестовых лаборатори-ях» (http://developer.amd.com/assets/16_Interrupts.pdf)).

Основной «удар» различий одно- и многопроцессорных машин опера-ционная система и BIOS берут на се-бя (примечание: здесь и далее по тек-сту под термином «многопроцессор-

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

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

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

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

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

Процесс – более крупная испол-нительная единица. Грубо говоря, это «коробок», в котором находятся прина-длежащие ему потоки, исполняющие-ся в едином адресном пространстве. Каждый поток обладает своим собс-твенным стеком и набором регист-ров, но вынужден разделять глобаль-ные переменные и динамическую па-мять вместе с другими потоками про-цесса, что порождает проблему синх-ронизации. Допустим, один поток вы-водит ASCIIZ-строку на экран, а дру-гой – в это же самое время выполня-ет над этой строкой функцию strcat(), удаляющую символ нуля до заверше-ния операции копирования. Как следс-твие – первый поток «вылетит» за пре-делы строки и пойдет чесать напа-ханную область памяти до тех пор пока не встретит посторонний нуль или не нарвется на исключение типа access violation.

Рисунок 1. В симметричной многопроцессорной системе (которой является Windows NT и ее потомки), каждый поток может исполняться на любом процессоре

80


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

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

С Linux/BSD в этом плане дела об-стоят намного лучше. Основной еди-ницей выполнения там является про-цесс (поддержка потоков уже появи-

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

Теперь поговорим о том, почему на однопроцессорных машинах ошиб-ки синхронизации проявляются зна-чительно реже, чем на многопроцес-сорных. Дело в том, что при наличии только одного процессора потоки вы-полняются последовательно, а не па-раллельно. Иллюзия одновременного выполнения создается лишь за счет того, что каждый поток работает в те-чение очень короткого (с человечес-кой точки зрения) промежутка вре-мени, называемого квантом, а потом системный планировщик передает уп-равление другому потоку. Длитель-ность кванта варьируется в зависи-мости от множества обстоятельств (подробнее этот вопрос рассмот-рен в статье «Разгон и торможение Windows NT»), но как бы там ни было, квант – это целая вечность для про-цессора, за которую он очень многое успевает сделать.

Рассмотрим следующую (кстати, вполне типичную) ситуацию. Поток вы-зывает какую-нибудь функцию из стан-дартной библиотеки C, а затем считы-вает глобальную переменную errno, в которую функция поместила код ошибки. В многопоточной программе, выполняющейся на однопроцессорной машине, такая стратегия работает до-вольно уверенно, хотя и является по-рочной. Существует угроза, что поток будет прерван планировщиком после завершения C-функции, но до обра-щения к переменной errno и управление получит дру-гой поток, вызывающий «свою» C-функцию, затира-ющую прежнее содержимое errno. И, когда первый поток вновь получит управление, он увидит там совсем не то, что ожидал! Однако вероят-ность этого события на одно-процессорной машине край-не мала. Тело потока состоит из тысяч машинных команд, и переключение контекста может произойти где угодно. Чтобы попасть между вызо-

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

Уровень драйверовДрайверы обычно не создают сво-их собственных потоков, довольству-ясь уже существующими, но проблем с синхронизацией у них даже боль-ше, чем у приложений. Хуже всего то, что на многопроцессорной системе од-ни и те же части драйвера могут одно-временно выполняться на различных процессорах! Чтобы понять причины такого беспредела, нам необходимо разобраться с базовыми понятиями ядра: IRQL и ISR.

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

Рисунок 2. Архитектура контроллера прерываний на двухпроцессорной машине

Рисунок 3. Уровни запросов прерываний и их назначение

81№10, октябрь 2006


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

Программируемый контроллер прерываний (Programmable Interrupt Controller, или сокращенно PIC) ориги-нального IBM PC был построен на мик-росхеме i8259A, сейчас же контроллер прерываний встроен непосредствен-но в южный мост чипсета и эмулирует i8259A лишь в целях обратной совмес-тимости. PIC имеет 15 линий прерыва-ний, а каждая линия – свой приоритет. Во время обработки прерываний пре-рывания с равным или более низким приоритетом маскируются, так сказать, откладываясь на потом. Иногда это по-могает, иногда нет. Например, если за-маскировать прерывания от таймера более чем на один «тик», системные часы начнут отставать. А если проигно-рировать прерывания от звуковой кар-ты и вовремя не «скормить» ей очеред-ную порцию данных, она начнет «буль-кать», заставляя пользователя рыдать от счастья и биться головой о монитор. Прерывания с более высоким приори-тетом прерывают менее приоритетные прерывания, возвращая им управле-ние после того, как они будут обрабо-таны. Усовершенствованные клоны PIC (Advanced Programmable Interrupt Controller, или сокращенно APIC) обес-печивают 256 линий прерываний и, в отличие от обычного PIC, способны работать в многопроцессорных сис-темах (см. рис. 2).

Операционная система Windows поддерживает PIC и APIC контролле-ры, но использует свою собственную систему приоритетов прерываний, из-вестную под аббревиатурой IRQL, ко-торая расшифровывается как Interrupt Request Levels (уровни запроса пре-рываний). Всего существует 32 уров-ня, пронумерованных целыми числа-ми от 0 до 31. Уровень 0 имеет мини-мальный приоритет, 31 – максималь-

ный. Нормальное выполнение потока происходит на нулевом уровне, назы-ваемом пассивным (PASSIVE), и его может прерывать любое асинхрон-ное событие, возникающее в системе. При этом операционная система повы-шает текущий IRQL до уровня возник-шего прерывания и передает управле-ние его ISR (Interrupt Service Routine – процедура обработки прерывания), предварительно сохранив состояние текущего обработчика.

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

Чтобы замаскировать прерыва-ния на время выполнения ISR, мно-

Рисунок 4. Обработка аппаратных прерываний на машине с одним процессором

Рисунок 5. Маскировка прерываний драйвером на двухпроцессорной машине

гие программисты просто повыша-ют уровень IRQL ядерной API-фун-кций KeRaiseIrql (), а при выходе из ISR восстанавливают его вызовом KeLowerIrql(). Даже если они не дела-ют этого явно, за них это делает сис-тема. Рассмотрим происходящие со-бытия более подробно.

Допус тим, поток A работает на уровне IRQL равном PASSIVE_LEVEL (см. рис. 4). Устройство Device 1 воз-буждает аппаратное прерывание с уровнем DIRQL (т.е. с номером 3 до 31 включительно). Операционная систе-ма прерывает выполнение потока A, повышает IRQL до DIRQL и передает управление на ISR устройства Device 1. Обработчик прерывания обращает-ся к устройству Device 1, делает с ним все, что оно требует, ставит в очередь отложенную процедуру DpcForISR() для дальнейшей обработки и понижает IRQL до прежнего уровня. Отложенные

82


процедуры (Deferred Procedure Calls, или сокращенно DPCs) выполняются на IRQL, равном 2 (DISPATCH_LEVEL), и потому не могут начать свою работу вплоть до выхода из ISR.

Если во время выполнения ISR возникнет прерывание, то оно бу-дет замаскировано. Если прерыва-ние возникнет во время выполнения DpcForISR(), операционная система прервет ее работу, передаст управ-ление ISR, который поставит в оче-редь еще одну отложенную процеду-ру и вновь возвратится в DpcForISR(). Таким образом, сколько бы прерыва-ний ни возникало, отложенные проце-дуры обрабатываются последователь-но, в порядке очереди.

На однопроцессорных системах та-кая схема работает вполне нормально, но вот на многопроцессорных… каж-дый процессор имеет свой IRQL, не-зависимый от остальных. Повыше-ние IRQL на одном процессоре никак не затрагивает все остальные, и ге-нерация прерываний продолжается (см. рис. 5).

Допустим, поток A выполняется на процессоре 1 с IRQL=PASSIVE_LEVEL,

в то время как поток B выполняется на процессоре 1 с тем же самым IRQL (см. рис. 6). Устройство Device 1 посы-лал процессору 0 сигнал прерывания. Операционная система «ловит» его, повышает IRQL процессора 0 до зна-чения DIRQL и передает управление ISR устройства Device 1, которое дела-ет с устройством что положено и ста-вит в очередь отложенную процедуру DpcForIsr() для дальнейшей обработ-ки. По умолчанию функция добавля-ется в очередь того процессора, на ко-тором запущена ISR (в данном случае процессора 0).

Устройство Device 1 вновь гене-рирует сигнал прерывания, который на этот раз посылается процессору 1, поскольку процессор 0 еще не успел завершить обработку ISR и не пони-зил IRQL. Система повышает IRQL процессора 1 до DIRQL и передает управление IRQ устройства Device 1, который делает с устройством все что нужно и ставит отложенную про-цедуру DpcForIsr() в очередь на про-цессоре 1.

Затем ISR на обоих процессорах завершаются, система понижает IRQL,

и начинается выполнение отложенной процедуры DpcForIsr(), стоящей как в очереди процессора 0, так и в оче-реди процессора 1. Да! Вы не ошиб-лись! Процедура DpcForIsr() будет исполняться сразу на обоих процес-сорах одновременно, отвечая за об-работку двух прерываний от одного устройства! Как вам это нравится?! В такой ситуации очень легко превра-тить совместно используемые дан-ные в мешанину, возвратив неожи-данный результат или завесив систе-му (см. рис 7).

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

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

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

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

Рисунок 6. Обработка аппаратных прерываний драйвером на двухпроцессорной машине

83№10, октябрь 2006


поскольку отладчик может заметить, что точка останова исчезла, и поста-вить ССh еще раз, забыв обновить оригинальное содержимое, оставше-еся от старой команды. Корректный перехват в этом случае практичес-ки невозможен. Теоретически мож-но внедрить jump во вторую инструк-цию, но для этого нам необходимо оп-ределить, где заканчивается первая, а поскольку ее начало искажено про-граммной точкой останова, для ее де-кодирования придется прибегнуть к эвристическим методам, а они не-надежны. К счастью, большинство функций начинаются со стандартно-го пролога PUSH EBP/MOV EBP,ESP (55h/8Bh ECh), поэтому, встретив пос-ледовательность CCh/8Bh ECh, мы вполне уверенно можем внедрять свой jump, начиная с MOV EBP,ESP.

Вот только тут есть один нюанс. Ко-манда ближнего перехода в 32-битном режиме занимает целых 5 байт, поэто-му для ее записи необходимо восполь-зоваться командой MOVQ, иначе мо-дификация будет представлять неа-томарную операцию. Задумайтесь, что произойдет, если мы записали 4 пер-вых байта команды JMP NEAR TARGET командой MOV и только собрались до-писать последний байт, как внезап-но пробудившийся поток захотел вы-звать эту функцию? Правильно – про-изойдет крах!

Но даже атомарность не спаса-ет от всех проблем. Допустим, мы записываем 5-байтовую команду JMP NEAR TARGET поверх 2-байтовой команды MOV EBP,ESP, естественно, затрагивая следующую за ней коман-ду. Даже на однопроцессорных маши-нах существует вероятность, что какой-то из потоков был ранее прерван сра-зу же после выполнения MOV EBP,ESP, и когда он возобновит свое выполне-ние, то… окажется посередине коман-ды JMP NEAR TARGET, что повлечет за собой непредсказуемое поведе-ние системы.

Алгоритм безопасной модифи-кации выглядит так: перехватываем INT 03h, запоминая адрес прежнего обработчика, внедряем в начало пере-хватываемой функции CCh (если толь-ко программная точка уже не установ-лена). При возникновении прерыва-ния INT 03h мы сравниваем получен-ный адрес со списком адресов пере-

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

Если же полученный адрес не «наш», мы передаем управление предыдуще-му обработчику INT 03h. То же самое мы делаем, если программная точка останова была установлена еще до пе-рехвата. Тогда мы позволяем преды-дущему обработчику INT 03h восста-новить ее содержимое, а сами ставим CCh на следующую инструкцию. Ко-нечно, такой способ перехвата намно-го сложнее «общепринятого», зато он на 100% надежен и работает в любых конфигурациях – как одно- так и мно-гопроцессорных.

Пути решения проблемСамое простое (и самое радикальное) решение – указать ключ /NUMPROC=1 (или /ONECPU) в файле boot.ini, од-ним росчерком пера превратив много-процессорную систему в однопроцес-сорную. Правда, о производительнос-ти после этого можно забыть, поэто-му прибегать к такому «варварскому» методу стоит только в самых крайних случаях, когда система регулярно сбо-ит, а времени на поиски неисправности и капитальный ремонт у нас нет.

Кстати, поиск неисправностей – са-мое сложное дело. Некорректная син-хронизация потоков приводит к порче данных, и критические ошибки возни-

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

При наличии исходных текстов в первую очередь проверьте: не ис-пользуются ли во многопоточной про-грамме однопоточные версии биб-лиотек? В частности, компилятор Microsoft Visual C++ поставляется с двумя версиями статических биб-лиотек С: LIBC.LIB – для однопоточ-ных и LIBCMT.LIB – для многопоточ-ных программ. Динамически компону-емая библиотека MSVCRT.LIB исполь-зуется как в одно- так и во многопоточ-ных проектах. Также поищите прямые вызовы CreateThread(). Со стандарт-ной библиотекой С они несовместимы и потому должны быть в обязательном порядке заменены на _beginthread() или _beginthreadex().

Все глобальные переменные (кро-ме тех, что используются для обмена данных между потоками) поместите в TLS (Thread Local Storage – локаль-ная память потока). На уровне исход-ных текстов это делается так:

при этом компилятор создает в PE-фай-ле специальную секцию .tls, куда и по-мещает my_var, автоматически созда-

Рисунок 7. Отсутствие синхронизации при обработке прерываний на двухпроцессорной машине приводит к порче разделяемых данных

__declspec (thread) int my_var

84


вая отдельный экземпляр для каждо-го из потоков.

В отсутствие исходных текстов эту затею осуществить труднее, но все-таки возможно. Сначала необходи-мо найти переменные, к которым идет обращение из нескольких потоков. Это делается так: ищутся все вызовы CreateThread()/_beginthread(), опреде-ляется стартовый адрес функции пото-ка и создается дерево функций, вызы-ваемых этим потоком (для этого удоб-но использовать скрипт func_tree.idc от mammon, который можно скачать с www.idapro.com). Перечисляем гло-бальные переменные, упомянутые в этих функциях, и если одна и та же переменная встречается в дере-вьях двух разных потоков – смотрим на нее пристальным взглядом, пыта-ясь ответить на вопрос: может ли она быть источником проблем или нет? Если переменная не используется для обмена данными между потока-ми, замещаем все обращения к ней на переходник к нашему обработчи-ку, размещенному в свободном мес-те файла, который, используя вызовы TslSetValue()/TslGetValue(), записыва-ет/считывает ее содержимое. Если же переменная используется для обмена данными между потоками, – окружаем ее критическими секциями или други-ми механизмами синхронизации.

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

шить и без правки – поменяв приори-теты потоков. Если один из двух (или более) потоков, использующий раз-деляемые данные без синхронизации, получит больший приоритет, чем ос-тальные, «расстановка сил» немед-ленно изменится, и, возможно, она из-менится так, что порча данных станет происходить не так часто, как прежде. Нужные значения приоритетов под-бираются экспериментально, а зада-ются API-функцией SetThreadPriority(), принимающей дескриптор потока. Вот тут-то и начинаются проблемы. Мы мо-жем легко узнать идентификатор по-тока через функции TOOLHELP32: C r e a t eTo o l h e l p 3 2 S n a p s h o t ( ) , Thread32First()/Thread32Next(), оста-ется «всего лишь» преобразовать его в дескриптор. Долгое время это при-ходилось делать весьма извращен-ным путем через недокументиро-ванные функции типа NtOpenThread (см. http://hi-tech.nsys.by/11), но в Windows 2000 наконец-то появилась легальная API-функция OpenThread(), принимающая идентификатор пото-ка и возвращающая его дескриптор (разумеется, при условии, что все не-обходимые права у нас есть). Виват, Microsoft!

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

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

ЗаключениеМногопроцессорные системы созда-ют гораздо больше проблем, чем мы здесь описали, и далеко не все из них разрешимы в рамках простой передел-ки программ. Получив возможность со-здавать потоки, программисты дале-ко не сразу осознали, что отлаживать многопоточные программы на поря-док сложнее, чем однопоточные. С дру-гой стороны, уже сейчас мы приходим к распределенным системам и распре-деленному программированию. Раз-бив цикл с большим количеством ите-раций на два цикла, исполняющихся в разных потоках/процессах, на двух-процессорной машине мы удвоим про-изводительность! Это слишком значи-тельный выигрыш, чтобы позволить себе пренебрегать им, поэтому осва-ивать азы распределенного програм-мирования нужно уже сейчас.

1. Scheduling, Thread Context, and IRQL – статья, сжато, но доходчиво описы-вающая механизмы диспетчериза-ции потоков, IRQL-уровни и обработ-ку прерываний на однопроцессорных и многопроцессорных машинах под Windows NT (на английском языке): http://www.microsoft.com/whdc/driver/kernel/IRQL.mspx.

2. Locks, Deadlocks, and Synchronization – статья, описывающая механизмы син-хронизации Windows NT и проблемы, возникающие при их некорректном ис-пользовании (на английском языке): http://www.microsoft.com/whdc/driver/kernel/locks.mspx.

3. Principles of Concurrent and Distributed Programming – книга, посвященная основам распределенного програм-мирования (на английском языке): http://www.amazon.com/gp/product /013711821X/002-0912814-0689662?v=glance&n=283155.

Рисунок 8. Защита разделяемых данных спин-блокировками

85№10, октябрь 2006

конкурс

1 место – 30 000 рублей 2 место – 20 000 рублей 3 место – 10 000 рублей

Номинации1. За лучшую серию материалов2. За лучшую новую авторскую тему3. За лучшую аналитическую статью

Кто участвуетУчастие принимают все авторы, опубликовавшие свои статьи в журнале «Системный администратор» в тече-ние 2006 года. Напоминаем, что автором может стать лю-бой человек.

О номинациях1. Серией материалов считается блок из не менее чем

двух статей. Тема серии – по собственному выбору ав-тора или же по выбору редакции.

2. Статья, написанная на тему, придуманную автором и одобренную редакцией.

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

Кто судьиВ состав жюри войдут сотрудники редакции и предста-вители дружественных журналу информационных ре-сурсов.

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

За содержание статьи ответственность несет автор.В течение двух недель редакция принимает решение

о публикации статьи и сообщает об этом автору.Редакция оставляет за собой право редактировать пре-

доставленные материалы.Редакция имеет эксклюзивное право на распростране-

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

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

По истечении одного года с момента первой публика-ции автор имеет право опубликовать свой материал в дру-гом месте без предварительного письменного согласия редакции.

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

В статье указываются ссылки на источники информа-ции.

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

Рекомендации авторамОбъем статьи – от 4 до 20 тыс. знаков. Если тема статьи

предполагает объем, превышающий 20 тыс. знаков – раз-бивайте материал на несколько частей.

Если вы пишете о продукте, технологии или компании, описывайте не только «плюсы», но и «минусы», а также при-водите информацию о конкурентах.

Рекомендуем ознакомиться со статьями на интересую-щую вас тему, которые уже есть на нашем сайте.

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

КонтактыАдрес: 107045, г. Москва, Ананьевский переулок д. 4/2, стр. 1, Редакция «Учительской газеты», журнал «Систем-ный администратор»Телефон: (495) 628-82-53Факс: (495) 628-82-53Сайт: www.samag.rue-mail: [email protected] [email protected]

Напоминаем Вам об учреждении редакцией журнала 3-х премий лучшим авторам по итогам 2006 года:

86

ретроспектива

Жизнь цвета зебры2001 год выдался для Transmeta не са-мым радостным: отсутствие прибыли, клиентов, постоянные проблемы с про-изводством. Большая часть процессо-ров Crusoe уходила в Японию, где на их основе японские гиганты Sony, Toshiba, Casio, Hitachi и другие изготовляли уль-тратонкие ноутбуки. Проблема состо-яла в том, что за пределы страны эти портативные системы не вывозились, во всяком случае, официально.

К 2001 году наладить постоянные поставки ноутбуков на базе Crusoe в страны Америки и Европы осмели-лась лишь японская Casio, которая,

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

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

енты – производители ноутбуков. Для примера можно вспомнить ситуацию конца 2000 года, когда компания NEC отозвала из магазинов 300 портатив-ных компьютеров, содержавших неста-бильно работавшие чипы Crusoe. Sony постигла та же участь: корпорация бы-ла вынуждена предупредить своих клиентов о возможном возникновении проблем с её ноутбуками серии Vaio из-за центрального процессора Transmeta. Если быть более конкретным, это поло-вина всей партии, состоящей из 28 ты-сяч систем.

П е р е х о д п р о и з в о д с т в а Crusoe к Ta iwan Semiconduc to r

Суровая правда, скрытая за «розовыми очками»: история компании TransmetaЧасть 2

Дмитрий Мороз

В 2001 году Transmeta находилась в плачевном положении. Являвшаяся одной из самых перспективных компаний ХХI века, она вмиг оказалась среди аутсайдеров процессорного рынка.

87№10, октябрь 2006


Manufacturing Co. (TSMC) ситуацию не улучшил. Да, цена снизилась не-много, однако для такого важного ком-понента любой вычислительной сис-темы, как процессор, качество пре-выше всего. Как раз с этим у TSMC были большие проблемы. Её новый 0,13 мкм технический процесс под ко-довым названием «Чёрный алмаз» (Black Diamond), разработанный сов-местно с компанией Applied Materials и расхваленный на всякий лад, сра-зу же показал свои недостатки. Nvidia, разработчик графических процессо-ров, не удовлетворённая низким ка-чеством продукции, производимой TSMC, «ушла» к её конкуренту – UMC. Ещё два основных клиента тайвань-ской компании, VIA и Broadcom, также обвинили своего партнёра в большом количестве производимых им брако-ванных кремниевых чипов.

Transmeta не стала для TSMC «при-ятным исключением»: процент процес-соров ТМ5800 «с ошибками», только что сошедших с конвейера, был чрез-вычайно велик. Проблемы с произ-водством Crusoe вылились в задержки с поставкой чипов клиентам Transmeta. Компания Toshiba, после долгих меся-цев неопределённости решившаяся-таки выпустить свой первый ноутбук на базе Crusoe в США, была вынуж-дена отказаться от своих планов из-за банального отсутствия процессоров к своим портативным системам. По-добная судьба постигла и пять новых субноутбуков от Sony и Fujitsu. В нояб-ре 2001 года представители обеих ком-паний публично обвинили Transmeta в невыполнении своих обещаний, со-гласно которым последняя обязалась предоставить им чип ТМ5800, работа-ющий на частоте 800 МГц, ещё в сере-дине года.

Что же касается давно ожидаемого Crusoe, работающего на частоте 1 ГГц, первоначальное обещание Transmeta выпустить его в январе 2001 года «рас-сыпалось в пух и прах». Для того что-бы процессор ТМ5800 и его более де-шёвый вариант, ТМ5500, выпуска-лись по 0,13 мкм технологии, инжене-рам пришлось значительно доработать внутреннюю компоновку элементов на кристалле чипа, негативным обра-зом сказавшуюся на дальнейшем по-вышении его тактовой частоты. Техни-ческому директору компании Дэвиду

Дитцелу (David Ditzel) вместе со сво-ими извинениями пришлось объявить, что планку в 1 ГГц ТМ5800 сможет преодолеть лишь в январе 2002 года, а в продаже он появится никак не рань-ше лета того же года.

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

Стоит отметить, что серверы на ба-зе Crusoe не являются многопроцес-сорными системами, построенными по типу SMP (Symmetric Multy Processing – симметричная многопроцессорная об-работка), на основе которого работают серверы на базе чипов Intel и AMD. Дит-цел, будучи ещё на посту генерального директора, публично заявил: «Я боль-ше не верю в SMP. Просто не вижу при-чин, которые бы подталкивали людей к её использованию». По его словам, потери производительности, прису-щие SMP, например, неэффективное управление приоритетами кэшей про-цессоров и пр., не подходят для сис-тем, ориентированных на рынок ин-тернет-вычислений. Вместо этого сер-веры на базе Crusoe строятся на ба-зе массовой параллельной обработки (Massively Parallel Processing – MPP), на основе которой работают Beowulf-кластеры.

Готовые решения Fibrecycle, Rebel и RLX Technologies пообещали пред-ставить миру уже в конце 2001 – нача-ле 2002 года.

Однако пока компании «пели дифи-рамбы» высокой экономичности и ма-лому энергопотреблению процессоров Crusoe, показателям, столь важным для тонких серверов, Transmeta про-должала с катастрофической скоро-стью терять деньги. 17 октября 2001 го-да, за два дня до оглашения отчёта за третий финансовый квартал, с поста генерального директора был уволен Марк Аллен (Mark Allen), пребывав-ший в «кресле» всего шесть с полови-ной месяцев после своего восхожде-ния на эту должность. Его место вре-менно занял Мюррей Голдмен (Murray

Goldman), входивший в состав совета директоров Transmeta.

Сам отчёт, предоставленный на всеобщее обозрение спустя двое су-ток, был удручающим: потери компа-нии составили 29,6 млн. долларов, при-быль – 5 млн. долларов. Аналогичные цифры за второй финансовый квартал составили 27,7 млн. долларов убытка и 10,5 млн. долларов дохода. К ноябрю цена за одну акцию Transmeta опусти-лась до смехотворной отметки в 2 дол-лара. В день выхода компании на фон-довую биржу этот показатель соста-вил 21 доллар.

Цифры говорят сами за себя – Transmeta продолжала терять своих клиентов, а также их деньги, причём с невероятной скоростью.

Больше товаров – хороших и разных!2002 год стал годом прихода Crusoe «в массы». Наконец-то количество сис-тем, использующих в своей основе процессор компании Transmeta, пере-стало исчисляться единицами.

Однако прежде чем новинки за-полнили собой прилавки магазинов, Transmeta наконец-то «обрела» ново-го генерального директора в лице Мэ-тью Перри (Matthew R. Perry), до этого успевшего поработать в компаниях: Cirrus Logic, AMD и Motorola.

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

Основными «потребителями» про-цессоров Transmeta оставались, ко-нечно же, ноутбуки. В Японии компа-ния сумела отхватить солидный кусок

Crusoe TM5400 рядом с монетой в 25 американских центов

Efficeon TM8620 рядом с монетойв 25 американских центов

88


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

Выпущенный к середине года ТМ5800 с частотой 1 ГГц позволил на-конец-то добиться производительнос-ти, сходной с процессором Pentium III Mobile, работающим на 500-600 МГц, а для ультрапортативных машин этого в 2002 году было вполне достаточно.

Вторым по популярности классом устройств, использующих процессор Crusoe, стали компактные бесшумные персональные компьютеры. Примене-ние чипов Transmeta позволило значи-тельно уменьшить их габариты, а так-же полностью лишить охлаждающих вентиляторов. Например, миниатюр-ный ПК компании NEC под названи-ем Mate, оборудованный процессором ТМ5800 с частотой 900 МГц, благодаря отсутствию вентиляторов на централь-ном чипе и блоке питания, а также ис-пользованию жёсткого диска для но-утбуков издавал звук на уровне всего 20 дБ. Для сравнения: столько же вы-дают отдельные «малошумящие» бло-ки питания для ПК.

Процессоры Transmeta нашли при-менение и в ультрапортативных ком-пьютерах, по размеру лишь немно-гим превосходящих своих карман-ных «собратьев». Известный OQO Ultra Personal Computer при размерах 7,5х12,5 см представлял собой прак-тически полноценный ПК под управ-лением Windows XP. «Сердцем» этого

малыша был процессор ТМ5800. Сис-тему подобного класса на базе Crusoe также представила компания Antelope Technologies.

Как и было обещано, тонкие сер-веры на базе процессоров Crusoe по-явились в первые месяцы 2002 года. Компания RLX первой представила свои решения на базе чипов Transmeta. Серверы этой компании были исполь-зованы Лос-Аламосской лаборато-рией (Нью-Мексико) для построения высокопроизводительного класте-ра. 240 однопроцессорных серверов были объединены в единую систе-му под названием «Зелёная судьба» (Green Destiny), основное предназна-чение которой – выполнение различ-ных научных и технических расчётов. По словам разработчика системы Ву-чун Фенга (Wu-chun Feng), стоимость обслуживания этого кластера в три раза меньше аналогичного показате-ля для конкурентов, построенных на процессорах других производителей. Подобный результат был достигнут не в последнюю очередь благодаря низкому энергопотреблению и тепло-выделению чипов Crusoe, в результа-те чего устанавливать «Зелёную судь-бу» в специальное помещение с мощ-ной системой охлаждения не было не-обходимости.

Кроме того, в 2002 году появились первые слухи относительно подпи-сания соглашений между Transmeta и компаниями, задумавшими выпус-тить планшетные компьютеры, работа-ющие под Windows XP Tablet PC Edition. Поскольку референсная платформа Microsoft была произведена на свет усилиями инженеров Transmeta, она, естественно, базировалась на процес-соре Crusoe. Для компаний, не желав-ших кардинально перерабатывать её «начинку», выбор центрального чипа для будущей системы был очевиден. Первым подобным клиентом Transmeta стала Hewlett-Packard, вознамеривша-яся выпустить планшетный компьютер, позже получивший название Compaq Tablet PC TC100.

На фоне столь бурного появления новинок финансовое состояние компа-нии продолжало ухудшаться. В июле 2002 года Transmeta объявила о сокра-щении своего штата сотрудников сразу на 40% – с 500 до 300 человек. Подоб-ный шаг был продиктован стремлени-

ем компании выйти на доходный уро-вень к середине года. Однако резуль-таты второго финансового квартала были удручающими: 7,5 млн. долларов прибыли при 35,6 млн. долларов убыт-ка. Уже в тот момент Transmeta скром-но призналась, что с подобными «циф-рами в своих отчётах» она может наде-яться на достижение доходного уровня не раньше конца 2003 года.

Вознамерившись покорить эту «высоту», Transmeta все усилия напра-вила на разработку нового процессора ТМ8000 (изначально – ТМ6000), кото-рый должен был исправить все ошиб-ки своих предшественников и стать на-конец-то чипом, достойным компании и её разработчиков.

Попытка №2Впервые о работах Transmeta над «на-следником» Crusoe стало известно ещё в ноябре 2000 года, когда вице-президент компании Эд МакКирнен (Ed McKernan) публично объявил о на-чале разработки 256-битного процес-сора. Со временем было обнародова-но его кодовое название – Astro.

В мае 2001 года Transmeta объяви-ла о лицензировании у AMD техноло-гии x86-64, над которой обе компании работали уже довольно продолжитель-ное время. В обязанности Transmeta входило создание программного обес-печения для трансляции 32-битных ко-манд в 64-битные и наоборот. Кроме того, компания отвечала за энергос-берегающие функции будущих про-цессоров AMD под кодовыми назва-ниями Hammer (Opteron) и ClawHammer (Athlon 64).

Приблизительно в то же время стало известно, что Transmeta стала членом организации, занимающейся разработкой высокоскоростной шины HyperTransport.

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

Уже в марте 2003 года обществен-ность узнала, что Astro – это 256-раз-рядный VLIW-процессор, содержа-щий также: контроллер оперативной памяти DDR 400, шину LPC для рабо-ты с флэш-памятью, интерфейс AGP,

Арт Свифт

89№10, октябрь 2006


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

Буквально через пару месяцев стало известно нечто интересное: Transmeta заручилась поддержкой графического гиганта, компании nVidia, которая согласилась разрабо-тать для Astro мобильную версию юж-ного моста nForce 3. В свою очередь Transmeta пообещала сделать мост, а также графический чип от nVidia не-отъемлемой частью своей референс-ной платформы на базе нового про-цессора.

В августе 2003 года у ТМ8000 по-явилось официальное имя – Efficeon (Efficient Computing – эффективная обработка). Все основные детали от-носительно нового чипа были извест-ны, и Transmeta оставалось всего ниче-го – представить Efficeon на суд публи-ки. Данное событие состоялось 14 ок-тября на Микропроцессорном форуме (Microprocessor Forum).

Итак, что новенького пригото-вили инженеры на этот раз? Новое 256-разрядное ядро способно выпол-нять до восьми инструкций за такт. Для увеличения производительности в Efficeon к уже имевшимся в Crusoe модулям добавили по одному блоку для операций с числами с плавающей запятой, операций с памятью и управ-ления переходами. Ядро нового чипа «подружилось» с наборами инструк-ций SSE и SSE2. Размер кэша второ-го уровня был увеличен в два раза – до 1 Мб. Упоминавшиеся ранее конт-роллер ОЗУ стандарта DDR 400 и гра-фический интерфейс AGP 4х позволи-ли отказаться от микросхемы север-ного моста. С южным же мостом но-вый чип общается посредством шины HyperTransport, работающей на час-тоте 400 МГц. Полностью переписан-ное программное обеспечение Code Morphing Software, по заверениям ин-женеров Transmeta, эффективнее ста-рого на 40-50%. Стоит, правда, отме-тить и недостатки – заметно увели-чившееся количество транзисторов (с 36,8 до 85 млн.), и, следовательно, размер кристалла чипа (с 55 кв. мм. (ТМ5800) до 119 кв. мм.).

Миру были представлены сразу не-сколько версий Efficeon: ТМ8600 (1 Мб кэш-памяти второго уровня), TM8300 (L2-кэш размером 512 Кбайт), а так-

же (ТМ8600 с уменьшенными на 46% размерами корпуса). Частоты всех трёх моделей колебались в пределах 1-1,3 ГГц.

На фоне громкого анонса Efficeon остался практически незамеченным уход из Transmeta создателя Linux Ли-нуса Торвальдса, который решил пос-вятить своё время исключительно раз-работке собственного программно-го «чада».

Возможно, уход Торвальдса был продиктован очередным финансовым кварталом, который напрочь «разве-ял мечты» Transmeta по поводу до-стижения доходного уровня в 2003 го-ду. Судите сами: по сравнению с пре-дыдущим кварталом прибыль компа-нии в связи с нежеланием покупать её морально устаревшие процессо-ры Crusoe упала почти на 50%, соста-вив всего 2,7 млн. долларов. Потери увеличились ещё на несколько мил-лионов, составив 23,7 млн. долларов. Теперь судьба компании напрямую за-висела от того, примет ли рынок её но-вый Efficeon.

Результаты производительнос-ти нового чипа Transmeta показыва-ли двукратное преимущество Efficeon относительно Crusoe, что само по себе уже было достижением. Казалось бы, новый процессор Transmeta получил-ся удачнее своего предшественника…

К сожалению, компания опоздала с его появлением. В 2003 году рынок был полностью оккупирован Intel и её новой платформой Centrino. Анонсиро-ванная в марте 2003 года, Centrino ус-пела в короткие сроки стать стандар-том де-факто в качестве основы для построения высокопроизводитель-ных и вместе с тем экономичных но-утбуков. Что же касается её процес-сора, Pentium M, он оказался настоль-ко удачно спроектированным чипом, что по производительности без труда справлялся не только со своими кон-курентами из мобильного рынка, но и с процессорами, предназначенными для настольных систем. «Хиленький» Efficeon конкуренцию Pentium M со-ставить не мог.

В результате лишь немногие ком-пании выпустили устройства на ба-зе нового процессора Transmeta. Кро-ме небольшого количества ноутбу-ков, упоминания заслуживает лишь «серверная станция» Orion Cluster

Workstation производства компании Orion Multisystems. 96 процессоров Efficeon, 192 Гб оперативной памяти, а также 9,6 Тб дискового пространства свободно уместились в корпусе прак-тически стандартных для настольных ПК размеров. При этом вес системы составляет всего 86 кг. Стоимость – от 100 тыс. долларов.

Потерянная процессорная гонкаВ январе 2004 года Transmeta выпусти-ла Crusoe ТМ5900, который представ-лял собой обычный ТМ5800 с умень-шенным корпусом, однако одногига-герцовый чип ещё до своего выхода в свет был отправлен общественнос-тью «на свалку».

В это время рынок начал переход на 0,9 мкм производственный процесс. Порядком «уставшая» от постоянных проблем с TSMC, для второго поко-ления процессоров Efficeon Transmeta выбрала нового производителя микро-схем – Fujitsu. ТМ8800, выполненный по нормам 0,9 мкм, должен был поя-виться к осени 2004 года. А пока не-многие компании, главным образом Sharp и Orion Multisystems, выбравшие Efficeon первого поколения в качестве основы для своих систем, получали процессоры в небольших партиях.

Именно благодаря им Transmeta удавалось держаться на плаву. Опуб-ликованный в середине года финан-совый отчёт продемонстрировал да-же небольшое увеличение прибыли – с 3,6 до 5,2 млн. долларов, да и потери компании замерли на отметке 23,4 млн. долларов.

Публичная демонстрация ТМ8800, работающего на частоте 1,6 ГГц, состо-ялась в мае 2004 года. Кроме более со-вершенного техпроцесса, а также бо-лее высокой тактовой частоты, новый Efficeon «предлагал» два новшества.

OQO Ultra Personal Computer

90


Первое – AntiVirusNX, аппаратно под-держивающая антивирусную техноло-гию Data Execution Protection, появив-шуюся в Service Pack 2 для Windows XP. Вторая – новая версия энергосбере-гающей технологии LongRun2, кото-рая «научилась» контролировать токи утечки транзисторов в кристалле, бла-годаря чему теоретически во время ре-жима «сна» новый процессор выделя-ет всего 0,03 Вт тепла.

Продажи ТМ8800 стартовали в сен-тябре, правда, количество отгружае-мых процессоров вследствие большой сложности их изготовления было неве-лико. В принципе даже этот досадный факт не мог исправить сложившуюся ситуацию – у Transmeta практически не осталось клиентов, которые бы по-купали её Efficeon. К счастью, компа-ния сумела избежать наметившегося финансового кризиса.

Ещё в октябре в одном из сво-их заявлений компания намекнула, что «одна многомиллиардная компа-ния» присматривается к её техноло-гии LongRun2 и желает её лицензиро-вать. Последний месяц 2004 года про-лил свет на её имя – Fujitsu.

В январе 2005 года в жизни Transmeta состоялось очень важное событие. Со дня своего выхода на фондовую биржу компания потеряла на собственных акциях в общей слож-ности 591 млн. долларов, так и не став прибыльной. Оценив сложившуюся си-туацию, 22 января Transmeta приняла решение уйти с процессорного биз-неса, сконцентрировав свои усилия на продаже интеллектуальной собс-твенности.

В дополнение к специфическим технологиям типа LongRun2 компания отныне предлагает лицензирование

своих микропроцессорных ядер. По-добная бизнес-модель давно не нова и находится на вооружении у компа-ний ARM и MIPS Technologies. «Мы рас-сматриваем любые предложения», – комментировал на выставке Consumer Electronics Show (CES) 2005 глава от-дела маркетинга Transmeta Грег Ро-уз (Greg Rose). «Переход к бизнес-мо-дели, в основе которой лежит прода-жа интеллектуальной собственности – значительно дешевле продажи про-цессоров. У нас нет собственных за-водов по производству чипов, потому что их постройка – занятие слишком дорогое. Однако тестирование про-цессоров, а также их дистрибуция – ве-щи также отнюдь не дешёвые, поэто-му Transmeta намного выгоднее изба-виться от этих затрат путём, который мы и выбрали».

Через два дня после заявления компания «нашла» второго клиента на свои разработки. Ею стала Sony, ли-цензировавшая LongRun2 для разра-батываемых совместно с IBM и Toshiba процессоров Cell.

На протяжении 2005 года клиента-ми Transmeta стали ещё две компании: японская NEC обзавелась лицензией на LongRun2, а китайская компания Culture.com Technology Limited – на ар-хитектуры Crusoe и Efficeon, на осно-ве которых она будет производить про-цессоры для внутреннего рынка.

В марте состоялась реструктури-зация компании, направленная на по-вышение эффективности ведения но-вого бизнеса, связанного с лицензиро-ванием: из 275 сотрудников Transmeta было уволено 67 человек, генераль-ный директор Мэтью Перри был сме-щён с поста Артом Свифтом (Art Swift), до этого работавшем в отделе марке-тинга.

Меры, предпринятые Transmeta на протяжении 2005 года, дали пот-рясающий результат, полностью оп-равдав решение компании о пере-квалификации. Годовой отчёт все-лил в Transmeta новую надежду: тог-да как общая прибыль за 2004 год составила всего 29,4 млн. долларов, в 2005 году компания заработала поч-ти в два с половиной раза больше, до-ведя этот показатель до 72,7 млн. дол-ларов. Для Transmeta, бывшей всю свою жизнь убыточной, эти показате-ли как бальзам на душу.

Похоже, что 2006 год будет ещё бо-лее успешным: в январе Sony продли-ла свой контракт вплоть до марта 2007 года, а в июне компания AMD лицен-зировала ядро Efficeon для производс-тва микропроцессоров, ориентирован-ных на Китай, Индию и другие разви-вающиеся, но пока полностью не ком-пьютеризированные страны.

Ещё один клиент до недавних пор оставался в тени, и лишь недавно ста-ло известно о его существовании. В но-ябре 2005 года Transmeta подписа-ла несколько соглашений с Microsoft, однако особой огласке они не при-давались. Известно было только то, что незамедлительно в недрах компа-нии была сформирована особая груп-па, состоящая из 30 инженеров, о ко-торой отзывались как о «работающих над секретным проектом Microsoft». В средствах массовой информации сразу поползли слухи о якобы «пор-тативной консоли, разрабатываемой Transmeta по заказу Microsoft». В апре-ле этого года появилась более реаль-ная версия – компания работает над эмулятором для Xbox 360, который поз-воляет ей запускать игры, разработан-ные для оригинальной Xbox. На первый взгляд это предположение более веро-ятно, поскольку людей, лучше разби-рающихся в эмуляции, чем инженеры Transmeta, найти очень сложно.

Однако сбрасывать второй вари-ант со счетов всё же не стоит. Позна-ния Transmeta в проектировании вы-сокоэкономичных процессоров вели-ки, а всё растущая популярность пор-тативной консоли PlayStation Portable от Sony корпорацию Microsoft никак не радует, вынуждая в максимально сжатые сроки предложить рынку свой вариант.

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

1. http://www.wired.com2. http://archive.salon.com3. http://www.arstechnica.com4. http://www.pcworld.com5. http://www.forbes.com6. http://www.theregister.co.uk7. http://www.transmeta.com

Compaq Tablet PC TC100

91№10, октябрь 2006

bugtraq

http://[host]:411/cgi-bin/Redirect.bat?file= ↵ %7C..\..\..\..\..\..\....\..\[file]

Выполнение произвольного кода в Microsoft OfficeПрограмма: Microsoft Office 2000, возможно, другие вер-сии.Опасность: Критическая.Описание: Уязвимость существует из-за неизвестной ошибки при обработке документов в Microsoft Word. Уда-ленный пользователь может с помощью специально сфор-мированного файла выполнить произвольный код на це-левой системе. Уязвимость активно эксплуатируется в на-стоящее время.URL производителя: http://www.microsoft.com.Решение: В настоящее время способов устранения уязви-мости не существует.

Переполнение буфера в Microsoft Publisher при обработке .pub-файловПрограмма: Microsoft Office 2000, Microsoft Office 2003 Professional Edition, Microsoft Office 2003 Small Business Edition, Microsoft Office 2003 Standard Edition, Microsoft Office 2003 Student and Teacher Edition, Microsoft Office XP, Microsoft Publisher 2000, Microsoft Publisher 2002, Microsoft Publisher 2003.Опасность: Критическая.Описание: Переполнение буфера обнаружено в Publisher при обработке .pub-файлов, содержащих специально об-работанную строку. Злоумышленник может создать спе-циальный документ, который, когда будет открыт целе-вым пользователем, запустит произвольный код на целе-вой системе.URL производителя: http://www.microsoft.com.Решение: Установите соответствующее обновление.

Множественные уязвимости в Adobe Flash PlayerПрограмма: Macromedia Flash 8.x, Macromedia Flash MX 2004, Macromedia Flash MX Professional 2004, Macromedia Flash Player 7.x, Macromedia Flash Player 8.x, Macromedia Flex 1.xОпасность: Критическая.Описание: 1. Несколько неустановленных уязвимостей пе-реполнения буфера позволяют выполнить произвольный код при загрузке специально обработанного SWF-файла, например, при просмотре злонамеренного веб-сайта.

2. Неустановленная ошибка позволяет обойти ограни-чения параметра allowScriptAccess.

3. Неустановленная ошибка существует в пути, в ко-тором ActiveX-управление запускает программы Microsoft Office на Windows-системах.URL производителя: http://www.adobe.com.Решение: Установите последнюю версию Flash.

Переполнение буфера при обработке сжатых редиректов в Internet ExplorerПрограмма: Microsoft Internet Explorer (IE) 5sp4, 6sp1.Опасность: Критическая.Описание: Удаленный злоумышленник может вызвать от-каз в обслуживании или выполнить произвольный код с при-вилегиями целевого пользователя, используя длинный URL на веб-сайте, который использует компрессию HTTP 1.1 и отвечает 302 HTTP-ответом (редирект).

Уязвимость обнаружена во второй версии патча MS06-042 для IE 5 SP4 и IE 6 SP1 (который был опублико-ван 24 августа 2006 года).URL производителя: http://www.microsoft.com.Решение: Microsoft опубликовал третью версию патча MS06-042, который устраняет обнаруженную уязвимость.

Удаленное переполнение буфера в Microsoft Internet Explorer и Microsoft Multimedia Controls ActiveXПрограмма: Microsoft Internet Explorer 6.x.Опасность: Критическая.Описание: Переполнение буфера обнаружено в функции CPathCtl::KeyFrame() в Microsoft Multimedia Controls ActiveX. Злоумышленник может создать специально сформиро-ванную HTML-страницу, чтобы выполнить произвольный код с привилегиями пользователя, просматривающего эту страницу в браузере.URL производителя: http://www.microsoft.com.Решение: В настоящее время способов устранения уязви-мости не существует.

Переполнение буфера в библиотеке Microsoft Vector Graphics RenderingПрограмма: Microsoft Windows 2000, Microsoft Windows XP, Microsoft Windows 2003.Опасность: Критическая.Описание: Уязвимость существует из-за ошибки проверки границ данных в Microsoft Vector Graphics Rendering (VML)-библиотеке (vgx.dll) при обработке определенных VML-до-кументов. Удаленный пользователь может с помощью спе-циально сформированного VML-документа, содержащего слишком длинный метод fill внутри тега rect, вызвать пе-реполнение стека и выполнить произвольный код на це-левой системе. Уязвимость активно эксплуатируется в на-стоящее время.URL производителя: http://www.microsoft.com.Решение: В настоящее время способов устранения уязви-мости не существует.

Обход ограничений безопасности в OperaПрограмма: Opera 9.01, возможно, более ранние версии.Опасность: Низкая.Описание: Уязвимость существует из-за ошибки при про-верке подлинности подписи сертификата. Злоумышленник может подделать сертификат, если при подписи сертифи-ката использовался RSA-ключ с экспонентом 3. Уязвимость относится к обходу ограничений безопасности в OpenSSL.URL производителя: http://www.opera.com.Решение: В настоящее время способов устранения уязви-мости не существует.

92

книжная полка

Книга – перевод официального курса по управлению защитой сетей Cisco (MCNS). Первая часть посвящена вы-бору политики защиты. Угрозы безо-пасности сети (принципы возникнове-ния проблем защиты, типы угроз бе-зопасности). Оценка политики защи-ты (процесс оценки состояния защи-ты, анализ практики защиты сетей). Защита инфраструктуры сети (про-

Материал книги основан на офици-альном курсе CSPFA (Cisco Secure PIX Firewall Advanced). Несмотря на то что оригинал книги (на англ. языке) вы-шел в 2002 году, большая часть мате-риала актуальна и сейчас. Из разде-ла «Введение» вы узнаете о критери-ях угроз безопасности сети, полити-ках безопасности сетей и их обеспе-

блемы защиты территориальной сети и варианты их решения, защита фи-зических устройств и административ-ного интерфейса, защита связи меж-ду маршрутизаторами и коммутатора-ми Ethernet). Вторая часть книги рас-сматривает вопросы защиты удален-ного доступа. Среди рассмотренных тем: технология защиты AAA, настрой-ка средств AAA сервера сетевого до-ступа. Конфигурирование CiscoSecure ACS и TACACS+/RADIUS. Защита меж-сетевых соединений. Настройка мар-штуризаторов периметра Cisco (систе-мы защиты периметра сети, управле-ния сервисами TCP/IP, защита от не-санкционированного изменения марш-рутов, управление доступом, средства трансляции IP-адресов, регистрация событий маршрутизаторов перимет-ра). Настройка Cisco IOS Firewall (обзор возможностей, настройка CBAC, уп-равление). Настройка CiscoSecure PIX Firewall (возможности, модели бранд-мауэров и их компоненты, конфигури-

Организация защиты сетей CiscoМайкл Уэнстром

рование). Настройка доступа через PIX Firewall (настройка управления исходя-щим доступом, а также доступ к внут-ренним хостам). Настройка интерфей-сов и средств AAA PIX firewall. Исполь-зование дополнительных возможнос-тей PIX firewall. Не остались без вни-мания технологии шифрования Cisco (обзор технологий шифрования, крип-тосистема IOS, применение шифро-вания на примере CET). Виртуальные частные сети, использующие IPSec (настройка и поддержка IPSec в сетях Cisco, IPSec в PIX firewall, масштаби-рование сетей IPSec). В конце каждой из глав вниманию предлагаются конт-рольные вопросы.

Брандмауэры Cisco Secure PIXПод редакцией Дэвида Чемпена-мл. и Энди Фоксачения. Затем авторы познакомят вас с ПО и аппаратными средствами бранд-мауэров Cisco PIX (рассмотрены типы брандмауэров, модели, элементы уп-равления). Использование и обновле-ние ПО Cisco PIX (интерфейс команд-ной строки, установка новой версии ОС и обновление существующей, вос-становление утерянного пароля). На-стройка Cisco PIX (уровни безопаснос-ти ASA, основные команды настройки: nameif, interface, ip address, nat, global, route). Трансляция адресов (транспорт-ные протоколы, статическая и динами-ческая трансляция адресов). Настрой-ка доступа через Cisco PIX (обеспече-ние доступа к сети через брандмауэр, команды static и conduit, альтернатив-ные методы, настройка дополнитель-ных интерфейсов). Системные сооб-щения (настройка системного журна-ла, команды семейства logging). На-стройка аутентификации, авторизации и учета в Cisco PIX. Подробно рассмот-рены вопросы расширенной обработ-

ки протоколов и защиты от взломов с помощью Cisco PIX. Механизмы пол-ного восстановления состояния в слу-чае отказа брандмауэра PIX. Настрой-ка механизмов IPSec при использова-нии в брандмауэре PIX. Контекстное управление доступом с помощью бран-дмауэра, основанного на ОС Cisco IOS. Настройка службы прокси – аутенти-фикации в Cisco IOS. Каждая из глав оканчивается контрольными вопроса-ми (есть и ответы на них). В приложе-нии вы также найдете информацию о настройке протоколов SNMP, DHCP, SSH в Cisco PIX. Отличная книга, ко-торая окажется полезной всем без ис-ключения людям, работающим с PIX.

Издательство:

Год издания:

Количество страниц:

ISBN:

Цена:

Книга предоставлена издательстким домом

«Вильямс».

«Вильямс»

2003

384

5-8459-0463-3

≈ 395 руб.




ISBN:

Цена:

Книга предоставлена издательстким домом

«Вильямс».

«Вильямс»

2005

768

5-8459-0387-4

≈ 480 руб.

93№10, октябрь 2006

книжная полка

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

Издание является продолжением серии книг об интерфейсах (напомню, что в рамках этой серии автором написаны книги, посвященные темам «Аппарат-ные интерфейсы ПК», «Шины PCI, USB и FireWire»). Среди рассмотренных тем: устройства хранения данных и их интер-фейсы: НГМД, IDE (ATA/ATAPI) и SATA. Параллельный интерфейс ATA и пос-ледовательный Serial ATA, адаптеры и

Интерфейсы устройств хранения: ATA, SCSI и другиеМихаил Гук

контроллеры ATA (контроллеры PCI IDE Bus Master, SATA intel 31244, AHCI). Про-граммное взаимодействие с устройс-твами ATA/ATAPI/SATA (традиционный механизм взаимодействия для ATA, пе-рекрытие команд и очереди, интерфейс AHCI, регистры устройства ATA/SATA). Система команд ATA/ATAPI и SATA (па-кетный интерфейс ATAPI, идентифи-кация и конфигурирование устройств, журналы ошибок и событий, монито-ринг состояния SMART). Вопросы, ка-сающиеся SCSI, представлены следую-щим материалом: спецификация SCSI, архитектурная модель SCSI-SAM, сис-тема команд SCSI. Подробно рассмот-рены вопросы параллельных шин SCSI (протокол параллельной шины, процесс ввода-вывода в шине SCSI, физический и электрический интерфейс). Из гла-вы, которая носит название «Последо-вательный интерфейс для подключе-ния устройств SCSI – SAS», вы узнае-

те об устройствах, портах и соединени-ях SAS, будут рассмотрены протоколы SSP, SMP, STP. Отдельная часть книги посвящена технологии iSCSI, у которой вы получите исчерпывающие сведения об этой технологии. Не остался без вни-мания и интерфейс Fibre Channel (ар-хитектура стандарта, каналы переда-чи данных FC-PH, FC-FS, арбитражное кольцо FC-AL). В заключительных гла-вах автор повествует об интерфейсах и конструктивах твердотельных носите-лей информации, шинах USB и FireWire для устройства хранения. Отличная книга, которая будет интересна широ-кому кругу читателей.

Криминалистический анализ файловых системБрайан Кэрриэ

инструментарий эксперта), основные принципы работы компьютера (орга-низация данных, процесс загрузки, тех-нологии жестких дисков), снятие дан-ных с жеского диска (чтение исходных данных, запись снятых данных, прак-тические примеры). Во второй части книги автор проводит анализ томов. Рассмотрены вопросы, касающиеся основ анализа, основные концепции MBR, расширенный раздел. Особый интерес предствляет глава «Разделы в серверных системах», из которой вы уз-наете о разделах BSD и структуре дан-ных, сегментах Sun Solaris, разделах GPT. Многодисковые тома (рассмот-рены технологии RAID и объединения дисков – Linux MD, LVM, Windows LDM). Черезвычайно подробно рассказано об анализе файловых систем: (fat и ntfs: основные концепции, анализ и струк-

Обзор книжных новинок подготовил Александр Байрак

тура данных, файловые системы ext2 и 1ext3, а также UFS1 и UFS2). На про-тяжении всей книги в качестве основ-ного инструмента используется пакет TSK (The Sleuth Kit), который вы можете загрузить с www.sleuthkit.org. Весь ма-териал книги отлично структурирован. Несмотря на достаточно сложную те-му, книга легко читается и усваивается. Отличный материал, написанный спе-циалистом для специалистов, он зай-мет достойное место на книжной полке у любого системного администратора или инженера по безопасности.




ISBN:

Цена:

Книга предоставлена издательством «Питер».

«Питер»

2007

480

5-469-01311-1

≈ 523 руб.




ISBN:

Цена:

Книга предоставлена издательством «Питер».

«Питер»

2007

447

5-469-01531-9

≈ 375 руб.

94

подписка на 2007 год

Редакционная подписка для физических лиц Подписку Вы можете оформить

на любой российский адрес. При заполнении разборчиво укажи-

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

Оформите годовую подписку и получите в подарок DVD-диск с архивом всех вышедших номеров с 2002 года. Диск будет вложен в январьский юбилейный выпуск журнала

Подписку можно оформить с любо-го месяца на любой срок.

В графе «Сумма» проставьте сум-му за выбранное количество номе-ров. Стоимость одного номера жур-нала 150 руб. За год – 1800 руб.НДС и почтовые расходы включе-ны в стоимость.

Копию заполненного и оплаченно-го бланка отправьте в редакцию по факсу: (495) 628-8253 или на элек-тронный адрес: [email protected]

Журнал высылается почтой прос-той бандеролью только после поступления денег на расчетный счет.

95№10 октябрь 2006

подписка на 2007 год

Российская Федерация Подписной индекс: годовой – 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

СИСТЕМНЫЙ АДМИНИСТРАТОР№10(47), Октябрь, 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 г.).

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

ЧИТАЙТЕВ СЛЕДУЮЩЕМНОМЕРЕ:

Уважаемые читатели!

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

Годовой индекс по каталогу «Роспечать» – 20780.Интер-почта – заказ журналов по тел.(495) 500-00-60.

Подписка on-line – SetBook.ru.

Приобрести новые и старые номера журналавы можете через интернет-магазины LinuxCenter.ru и Allsoft.ru.

Доставка почтой в любую точку России.

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

Атаки на ошибки синхронизации потоков3 сентября 2006 года хакер johnny cache реализовал принципиально но-вый тип атаки на драйверы устройств беспроводной связи Intel Centrino PRO, воздейстовав на регистр EIP через ошибку синхронизации потоков (впол-не типичную для DSL-модемов, ИК-пор-тов и других устройств, обрабатыва-ющих асинхронные запросы). Но на-вряд ли он осознал, что эта атака от-крывает новую страницу в истории пе-реполняющихся буферов. Это действи-тельно новый тип атаки, с которым мы

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

Обзор дистрибутива SystemRescueCd LinuxВам часто приходится восстанавли-вать систему после сбоя, копировать данные с поврежденных жестких дис-ков, тестировать аппаратную часть ЭВМ, сбрасывать забытые пароли в се-мействе ОС windows NT, готовить дис-ки для установки новой ОС и решать другие административные задачи? Обычно для этого используются набо-ры дистрибутивов и Live-CD различно-го назначения, но есть ли единое и ком-пактное решение «все в одном»?

Kerberos и электронная почтаВ статье будет рассмотрен способ ин-теграции smtp-сервера Postfix и imap/pop3-сервера Сyrus-IMAP в систему единой регистрации пользователей Heimdal-Kerberos. Также будет показан пример использования этой системы в гетерогенном окружении при помо-щи почтового клиента Thunderbird.

Documents

047 Системный Администратор 10 2006