№8(33) август 2005 подписной индекс 81655 www.samag.ru
Сможет ли PC-BSD конкурировать с Linux-дистрибутивами? Оцените WrSpy! Считаем трафик почтовых и прокси-серверов Настраиваем DSPAM – ваш личный спам-фильтр Проводим аудит системы с помощью SNARE Упрощаем управление Asterisk-сервером Asterisk -сервером
№8(33) август 2005
OpenMosix – превратим сеть в единый суперкомпьютер! CD, не подвластный копированию Админские сказки 16 bit edition
ЗА Н КО ЕО НЧ ЖИ ИЛ ДА ИС НН ЬД О ЕН ЬГ И
ПО АВ СЛ РА Е О Л НА ТПУ РА СКА БО ТЕ
УЕ
ХА Л
ВО ТП
УС К
БЫ СТ
РО ТИ РАС РА КУ Ж П
ИЛ И
КА НИ НО КУ ВО ЛЫ ГО ЗА ДНИ ТЯ Е НУ ЛИ СЬ
Так видит журнал читатель, который забыл оформить подписку:
Так видит журнал читатель, оформивший подписку:
ПОДПИШИТЕСЬ И ЧИТАЙТЕ! Роспечать – 81655 Пресса России – 87836 Интер-почта – тел. (095) 500-00-60
оглавление 2 РЕПОРТАЖ
БЕЗОПАСНОСТЬ 60 Проводим аудит системы с помощью SNARE
3 ТЕНДЕНЦИИ АДМИНИСТРИРОВАНИЕ
Полноценный контроль за системными событиями.
6 Сможет ли PC-BSD конкурировать с Linux-дистрибутивами? Обзор настольного дистрибутива PC-BSD, основанСергей Супрунов ного на FreeBSD. amsand@rambler.ru
10 Asterisk и Linux: миссия IP-телефония Действие 3 Рассматриваем несколько веб-интерфейсов, значительно облегчающих работу пользователей и адмиМихаил Платов нистраторов Asterisk. platov@cs.vsu.ru
20 Создаем систему учета исходящих телефонных звонков Готовое решение на примере УАТС LG GDK-162.
Денис Соколов box1739@yandex.ru
24 Настраиваем DSPAM – ваш личный спам-фильтр Основанная на алгоритмах статистического анализа, самообучающаяся система DSPAM существенно упростит жизнь пользователю, выполняя за него работу по сортировке входящей корреспонденции.
Сергей Супрунов amsand@rambler.ru
36 WrSpy – считаем и контролируем трафик почтовых и прокси-серверов Оцените возможности бесплатной программы WrSpy для контроля за интернет-трафиком ваших пользоРоман Марков вателей. stepan-razin@newmail.ru
42 Знакомимся с HPC-кластером OpenMosix Превратим сеть в единый суперкомпьютер!
Антон Борисов a.borisov@tesv.tmb.ru
48 Управляем удаленными базами AIDE Требуется оснастить все сервера программой контроля от вторжений – AIDE. Но сервера территориально разбросаны, а хотелось бы хранить базы AIDE на съемных носителях. Как собрать данные со всех комРашид Ачилов пьютеров, не вставая с места? shelton@granch.ru
54 SAP+MySQL=MaxDB Обзор возможностей MaxDB – СУБД, базирующейКирилл Сухов ся на исходном коде SAP DB. geol@altertech.ru
№8, август 2005
Сергей Яремчук grinder@ua.fm
64 CD, не подвластный копированию Список популярных ошибок в механизмах защиты CD от копирования, рекомендации по их устранению, а также готовый алгоритм защиты.
Крис Касперски kk@sendmail.ru
ПРОГРАММИРОВАНИЕ 72 Контролируем и ограничиваем системные вызовы с помощью systrace Как всегда быть в курсе того, что происходит в ваАлександр Байрак шей системе? x01mer@pisem.net
HARDWARE 76 Используем LinuxBIOS на системах VIA EPIA-M Вдохнем жизнь в barebone-систему на базе EPIA-M Антон Борисов и технологии LinuxBIOS. a.borisov@tesv.tmb.ru
WEB 82 Совершенствуем технологию CMS Возможности проекта Habitat 2.0.
Алексей Моисеев tsaralex@alpe.ru
БИЗНЕС-РЕШЕНИЯ В IT 86 IT в сфере ресторанно-гостиничного бизнеса Обзор программных и аппаратных продуктов, позволяющих эффективно управлять современными госКирилл Тихонов тиничными комплексами. aka_shaman@mail.ru
СКАЗКИ 88 Админские сказки. 16 bit edition Совершенно выдуманные истории, рассказанные без какой-нибудь видимой цели или морали, и даАлексей Барабанов же не ко сну. alekseybb@mail.ru
93 КНИЖНАЯ ПОЛКА 75, 85, 94 BUGTRAQ 1
репортаж
ИТОГИ CHAOS CONSTRUCTIONS 2005 20-21 сентября в Санкт-Петербурге традиционно прошла demo-party Chaos Construction. Я бы обозначил это событие как фестиваль компьютерного искусства.
М
ероприятие происходило в здании Ленинградского дворца молодежи. В одном месте собирались творческие личности: программисты, художники, музыканты, аниматоры.
что поспать особо не удалось. Утром за нами прибыл автобус, и мы отправились на второй день мероприятия. Программа этого дня была не менее насыщенной по сравнению с первым днем. Одновременно с CC’05 в том же зале проходила выставка retro-компьютеров.
Посетители и участники съехались со всего бывшего Союза
Программа мероприятий была очень насыщенной [1]. Основные представленные работы были для PC и ZX Spectrum, к сожалению, работ для Amiga было не очень много. На фестивале царила чрезвычайно дружественная и располагающая к общению атмосфера. Люди знакомились, обсуждали показанные работы и строили новые планы.
Выставка retro-компьютеров
В этом году было представлено около 15 различных экспонатов. За каждым компьютером можно было самому посидеть, поработать. Большинство владельцев были неподалеку и с радостью отвечали на все вопросы. После завершения всех конкурсов и подсчета голосов состоялось торжественное вручение дипломов победителям.
Игра StarWars for ZX Spectrum by Newart
После показа каждой работы зрители выставляли свою оценку, занося ее в специальный блокнот. После показа всех работ одного конкурса листок с выставленными оценками надлежало поместить в «урну для голосования». По завершении второго дня demo-party, исходя из этих данных, были объявлены итоги. По окончании первого дня желающие (предварительно оплатив) могли отправиться на hidden-party, которая проходила неподалеку от Ломоносова (Ораниенбаум) – пригорода Санкт-Петербурга, на территории пионерского лагеря. По замыслу организаторов на hidden-party люди могли пообщаться в более неформальной обстановке, обсудить первый день CC’5 и отдохнуть. После ужина началось «продолжение банкета». Очень запомнился поход ночью к Финскому заливу и выступление музыкантов ChipCult. Жаль,
2
Вручение дипломов
Само собой, после официального завершения CC’05 было и неофициальное. Два дня пролетели просто незаметно, полученных впечатлений хватит до следующего года.
Ссылки: 1. http://cc5.org.ru/index.php?uid=pubgrafik. 2. Результаты: http://cc5.org.ru/index.php?uid=vote_result. 3. Работы участников: ftp://ftp.cc5.org.ru/pub/2005.
Александр Байрак Фото Евгения Давыдова
тенденции Novell привлекает сторонних Linux-разработчиков В первой половине августа американская компания анонсировала и запустила инициативу OpenSuse, «открыв» разработку своего ключевого Linux-продукта – дистрибутива SUSE. Проект OpenSuse, по своей сути напоминающий Fedora Project, поддерживаемый Red Hat, прямым конкурентом Novell, доступен на веб-сайте www.opensuse.org, где вскоре и были опубликованы бета-релизы свободной версии SUSE Linux 10.0. По словам Грега Манкузи-Унгаро, директора по маркетингу ОС Linux и Open Source в Novell, компания таким образом рассчитывает привлечь большее число сторонних разработчиков, новых пользователей и в конечном счете получить более значимую долю на Linux-рынке.
«Жесткий» real-time в Linux Специалистам из MontaVista Software удалось добиться реализации поддержки режима «жесткого реального времени» (hard real-time) в Linux намного раньше, чем планировалось, – это позволит операционной системе реагировать на прерывания с высоким приоритетом за короткий, фиксированный промежуток времени. Разработчики MontaVista, пользовавшиеся и трудами сторонних Linux-программистов, смогли снизить показатель задержки до 98 микросекунд, что приблизительно в 100 раз лучше, чем позволяет обычное Linux-ядро версии 2.6.10. «Мы сделали это на два квартала раньше, чем планировалось по графику», – заметил Педер Уландер, вице-президент по маркетингу MontaVista. Вскоре становится известно о взаимном сотрудничестве MontaVista и PalmSource.
Создана Mozilla Corporation Mozilla Foundation (MF) объявила о формировании нового подразделения, которое поможет распространению своих программных продуктов, – Mozilla Corporation. По словам Mozilla, целью организации стоит дальнейшая популяризация браузера Firefox, которая требует появления платных услуг по поддержке. Mozilla Corporation, что призвана решить эту проблему, возглавила Митчелл Бэйкер, руководящая и MF. Как она отметила в телефонном интервью, новая корпорация будет прибыльной, однако ее целью станет реализация задач MF. «Наша фундаментальная цель – продвижение открытого Интернета», – заявила она, добавив, что нельзя игнорировать тот факт, что «Firefox стал ценным активом». ИТ-аналитики (среди них специалисты из RedMonk и Forrester Research) быстро отреагировали на данное известие, одобрив создание Mozilla Corporation, что, по их мнению, является вполне логичным шагом.
Новая акция раздачи дисков с Open Source Тысячи учеников средних школ Франции (провинции Овернь) по возвращении к учебе в сентябре получат компакт-диски со свободным и открытым программным обеспечением. По проекту, спонсируемому местным правительством, ученикам будет выдано 64 000 2-дисковых комплектов с популярным FOSS. На первом CD представлено свободное программное обеспечение для ОС Microsoft Windows и Apple Mac OS X, среди которого OpenOffice.org,
№8, август 2005
3
тенденции Mozilla Firefox и GIMP, а второй диск – LiveCD на базе Kaella (французской разновидности KNOPPIX). Любой желающий сможет ознакомиться с миром Linux без потребности в установке системы на жесткий диск.
Открыты исходники Quake 3 Выступая на QuakeCon 2005, Джон Кармак сообщил, что после некоторых задержек id Software все-таки приготовила к релизу все исходные коды популярной игры «Quake III: Arena» под свободной лицензией GNU GPL. И 19 августа на FTP-сайте компании появляется долгожданный архив с исходниками Quake3 1.32b. Кроме того, Кармак выразил заинтересованность в том, чтобы кто-нибудь воспользовался этим кодом для завершения работы над своим 3D-шутером и продавал получившуюся игру с полным исходным кодом на CD. Он добавил, что испытывает разочарование из-за людей, слишком обеспокоенных защитой своего кода, большая часть которого основана на чужих разработках.
В среде Xen запущена ОС Windows Компания XenSource сообщила об успешном запуске операционной системы Microsoft Windows (XP SP2) в среде Xen, что стало важным шагом на пути к коммерциализации открытой виртуальной машины. Программное обеспечение Xen, предназначенное для запуска множества операционных систем на одном компьютере, ранее обычно использовалось в связке с Linux, однако сложно переоценить важность возможности запуска и широко используемой ОС Windows.
Составил Дмитрий Шурупов по материалам www.nixp.ru
Началась работа над PHP 6.0 9 августа 2005 года в среде разработчиков PHP произошло знаковое событие: CVS HEAD был отделен в ветку PHP 5.1, после чего HEAD стал PHP 6.0.0. Пока в качестве основного нововведения в PHP 6.0.0 планируется поддержка Unicode (см. PHP Unicode support design document – http://news.php. net/php.internals/17771). Вполне возможно, что будут и другие значительные изменения в лучшую сторону. Ветка 5.0 скорее всего не будет поддерживаться, ветка 5.1 становится стабильной и замораживается полностью вплоть до релиза, после чего в неё тоже будут допускаться только багфиксы и другие незначительные изменения. «Девелоперской» теперь становится ветка 6.0, и все новые разработки будут реализовываться именно здесь. 12 августа, отец-основатель PHP, Расмус Лендорф (Rasmus Lerdorf), выступил со списком пожеланий к новой версии языка (http://beeblex.com/lists/index.php/php.internals/ 17883). В обсуждаемых сейчас PHP-сообществом девяти тезисах содержатся предложения по избавлению языка от таких функций и настроек, как register_globals и magic_quotes, удалению функций помеченных ещё в PHP 4 как deprecated и т. д. В то же время Лендорф предлагает включить в базовую поставку PHP кэширование байт-кода и новое расширение для фильтрации входных данных. Обсуждение будущего языка возможно по адресу: http://beeblex.com/lists/ index.php/php.internals/17883.
Кирилл Сухов
4
конкурс
IT-ACADEMY 2005 НОВАЯ АКЦИЯ ДЛЯ МОЛОДЫХ СПЕЦИАЛИСТОВ Еще не закончился «Кубок сетевых проектов Microsoft», технические материалы с которого мы планируем опубликовать в последующих номерах, как те же организаторы – компании Microsoft, Softline и ZyXEL объявили о начале новой акции. Как и в прошлый раз, акция проводится для молодежи – школьников, студентов, аспирантов и молодых специалистов (недавних выпускников вузов), но теперь ее география расширилась – она проходит в нескольких городах России: Москве, Томске, Омске, Воронеже и Самаре.
П
олное название акции – «Молодежный чемпионат IT-Academy 2005». Несмотря на слово «чемпионат», акция не имеет ничего общего с турнирами для программистов и другими соревнованиями, в которых могут участвовать только очень опытные специалисты. Наоборот, чтобы принять участие в IT-Academy 2005 достаточно лишь иметь общее представление о том, чем занимаются компании Microsoft и ZyXEL. Акция состоит из двух этапов, и у каждого этапа свои призы. На первом этапе нужно сдать на сайте http://www. it-academy.ru бесплатный онлайн-тест Microsoft или ZyXEL. Задачей теста не является проверка технических знаний участника. Вместо этого тест проверяет общее знакомство с компанией, ее историей, новостями и продуктами/услугами. С учетом того, что все ответы можно найти в Интернете, сдача теста не выглядит особо сложной задачей. Главный приз в каждом городе получит тот, кто сдаст тест раньше и лучше всех. Среди остальных участников будут разыграны по лотерее два дополнительных приза. Второй этап не является обязательным, но если есть желание побороться за бесплатное обучение на нескольких авторизованных курсах Microsoft по программе MS IT Academy и за международный сертификат Профессионала Microsoft (MCP), то предварительным условием является набор на лю-
№8, август 2005
бом из тестов не менее 60 процентов правильных ответов. Участники второго этапа должны пройти специальный 12-часовой курс «Построение IT-инфраструктуры предприятия на основе продуктов Microsoft» стоимостью 599 рублей. Курс рассматривает ОС Windows XP и Windows Server 2003, Групповую политику и серверные продукты MS Exchange Server 2003 и MS ISA Server 2004. В каждом городе по результатам обучения определится тройка победителей, которые и смогут бесплатно пройти профессиональное обучение. Акция показалась нам интересной, и мы решили задать несколько вопросов организаторам. На наши вопросы отвечает директор по развитию региональных образовательных проектов SoftLine Андрей Степанов. В чем идея акции? Мы хотели поощрить активных и любознательных молодых людей, которые знают или хотят узнать больше об IT-компаниях, а также серьезно задумываются о повышении своего профессионализма и получении международных сертификатов. Как будут отбираться победители второго этапа? Во время курса и сразу после его окончания будет проводиться тестирование усвоения материала. Те студенты, которые покажут лучшие результаты, и станут победителями.
Почему во втором этапе нужно сначала пройти платный курс и только потом сдавать проверочный тест на усвоение материала. Можно ли сдавать тест без курса? Нам кажется, что проверять начальную техническую подготовку участника не очень логично. В самом деле, если человек и так все знает, зачем ему дополнительное обучение? Наша идея – предоставить возможность пройти обучение и сертифицироваться тем людям, которые хотят и могут эффективно учиться новому, независимо от их начального уровня знаний. Поэтому, чтобы поставить всех в равные условия, мы сначала обучаем, а только потом тестируем. Что касается платности курса, то цена установлена чисто символическая и даже если не рассматривать возможность выигрыша, курс более чем оправдывает свою стоимость.
Главный приз от компании ZyXEL – 802.11g+ беспроводной модем ADSL2+ с 2-портовым шлюзом VoIP и 4-портовым коммутатором P-2602HW EE
5
администрирование
СМОЖЕТ ЛИ PC-BSD КОНКУРИРОВАТЬ С Linux-ДИСТРИБУТИВАМИ?
Новые дистрибутивы Linux появляются, как грибы после дождя. Фанаты же BSD по большей части вынуждены собирать свои десктопы вручную. Однако появилась пара дистрибутивов, основанных на FreeBSD, одному из которых и посвящается эта статья.
СЕРГЕЙ СУПРУНОВ
М
ы рассмотрим дистрибутив PC-BSD. В руки мне попалась версия 0.7.8, основанная на FreeBSD 5.4RELEASE #2. Сейчас, когда я пишу эти строки, ведутся работы над версией 0.8, и не исключено, что к моменту выхода журнала актуальной будет уже она. Тем не менее основные свои черты дистрибутив должен сохранить, так что продолжим.
Процесс установки Инсталляция, снабженная удобным графическим интерфейсом, прошла без каких-либо эксцессов. При загрузке с диска вас встретит знакомая пользователям FreeBSD кар-
6
тинка (рис. 1), которая позволит воспользоваться различными режимами загрузки в случае проблем. Далее, перед переходом в графический режим, будет выведено еще одно текстовое окно, предоставляющее еще несколько путей для преодоления возможных трудностей, например, вы сможете загрузиться в режим командной оболочки (рис. 2). Инсталлятор потребует некоторого знания английского языка (можно надеяться, что в следующих релизах появится и русский), однако для человека, в общих чертах представляющего себе установку операционной системы, никаких сложностей возникнуть не должно.
администрирование Итак, после приветствия и нескольких общих фраз (рис. 3) вам будет предложено выбрать место на имеющихся у вас дисках, куда вы хотели бы выполнить установку (рис. 4). Если отметить опцию «Customize DiskLabel», то вы получите возможность разбить выбранный слайс на подразделы по своему желанию (рис. 5). Иначе будет выполнена нехитрая автоматическая разбивка, на мой взгляд, не совсем оптимальная – 999 Мб будет занято под Swap, остальное место – под корневой раздел. При таком распределении слайса резко возрастает риск повредить систему при аварийном завершении работы. Учитывая, что качество электросети в нашей стране по-прежнему оставляет желать лучшего, а ИБП дома – роскошь, вероятность неприятностей становится еще выше. Хотя файловая система FreeBSD достаточно устойчива к сбоям, все же лучше потратить несколько минут и указать более удачное разбиение, выделив, по крайней мере, отдельные разделы для /usr и /var. Кроме того, подобное разбиение позволит более гибко оптимизировать работу ФС в зависимости от решаемых задач, например, включив асинхронный режим работы для /var. Далее инсталлятор поинтересуется, желаете вы установить загрузчик BSD или нет. После чего начнется процесс копирования файлов, который займет минут 15-20. (Кстати, если во время копирования ваш экран вдруг станет черным, не пугайтесь – это screen-saver.) В конце вам нужно будет ввести пароль суперпользователя, а также заполнить данные непривилегированного пользователя, от имени которого вы будете в дальнейшем работать в системе. Здесь же вы сможете отметить, хотите ли входить в систему автоматически (опция «Autologon»). Теперь со спокойной совестью можно перезагрузиться.
Про маленькую проблему Упомяну здесь про интересное поведение дистрибутива, когда я попытался его поставить на свой домашний компьютер с отключенным Primary Master-диском (был подключен только Slave). Сперва он не нашел никакие диски вообще, но после нажатия кнопки «Обновить» в окне выбора диска предложил поставить систему на неизвестно откуда взявшийся BSD-раздел размером около 2 Гб. Когда я ради интереса согласился и продолжил установку, PC-BSD 15 минут честно копировал свои файлы в никуда, сопровождая это сообщениями «Failed to create dir…», не прерывая тем не менее работы. После перезагрузки, естественно, ничего установленного найдено не было. Таким образом, прежде чем начинать установку, убедитесь, что в системе есть диск Primary Master (саму установку не обязательно выполнять на него).
Первые впечатления При загрузке в свежеустановленную систему вы сразу попадете в KDE. Все довольно стандартно, однако в дистрибутивах Linux я уже успел привыкнуть к кнопке вызова терминала, размещенной непосредственно на панели инструментов или, по крайней мере, в главном меню KDE. Здесь же пришлось добираться до нее через несколько вложенных меню.
№8, август 2005
Рисунок 1. Стандартное меню загрузчика BSD
Рисунок 2. Окно выбора режима работы
На рабочем столе не будет видно иконок быстрого монтирования CD и жестких дисков. Они размещены под иконкой «Computer» и далее – «Drives». Там же можно найти и нечто вроде «Сетевого окружения» для Samba. Монтированиеразмонтирование дисков выполнялось легко, что называется, парой кликов (рис. 6). Подключение разделов NTFS тоже возможно, но только на чтение. Кстати говоря, для непривилегированного пользователя и FAT будет доступна только для чтения – писать туда по умолчанию может лишь root. И еще, что бросилось в глаза, – в папке автомонтирования были предложены только диски, размещенные на основных разделах. Логический диск с FAT32, который у меня находится на дополнительном разделе, обнаружен не был. Среди имеющихся приложений можно найти несколько простых текстовых редакторов (Kate, KWrite), средства для просмотра графики, PDF, аудиоплейер, десятка два обычных для KDE игрушек. Для работы в Интернете к вашим услугам браузер Konqueror, почтовый клиент KMail, менеджер закачек KGet. Столь популярный ныне Firefox в дистрибутив не попал, так же как и старушка Mozilla. Ни исходных кодов, ни дерева портов в дистрибутиве нет, так что вам придется добывать их самостоятельно, если возникнет необходимость пересобрать ядро или установить какой-нибудь пакет. Впрочем, для работы с приложениями PC-BSD предлагает собственное решение.
Установка дополнительных приложений Еще на этапе инсталляции вы можете встретить подсказку, что при желании вы можете закачать себе дерево портов простой командой: # cvsup /root/ports-supÞle
7
администрирование
Рисунок 3. Начинаем инсталляцию PC-BSD
Рисунок 5. Разбиваем слайс на подразделы
Рисунок 6. Инструмент автомонтирования дисков
Рисунок 7. Установка Firefox из pbi-пакета
Рисунок 8. Рабочее окно KPackage
Но разработчики PC-BSD предлагают другое решение – пакеты pbi. Скачать их можно с сайта http://www.pcbsd. org, однако на данный момент выбор не очень богатый – чуть больше 50. Зато это наиболее востребованное ПО – OpenOffice, Firefox, Opera, Thunderbird, GIMP, ClamAV и др. Так вот достаточно скачать себе pbi-файл, и одним щелчком мыши вы получите у себя готовое к работе приложение. Не нужно заботиться ни о зависимостях, ни о компи-
8
Рисунок 4. Диалог выбора раздела для установки
ляторах. Как будто вы ставите msi-приложение в системе Windows. Установленные таким образом приложения можно будет найти в PC-BSD Package Manager (рис. 7). Из этого же окна лишнее можно и удалить. Ну и помимо данного способа вы можете воспользоваться более традиционным менеджером пакетов KPackage (рис. 8) либо использовать коллекцию портов традицион-
администрирование
Рисунок 9. KDE Control Center. Keyboard layout
ным способом, выполнив предварительно указанную выше команду.
Поддержка русского языка Вот чего нет, того нет. Конечно, вы можете выбрать русскую раскладку клавиатуры в KDE Control Center (рис. 9), и это позволит вам набирать тексты в простых редакторах типа Kate на родном языке (используется кодировка Unicode). Однако, установив тот же OpenOffice как pbiпакет, вы обнаружите полное отсутствие кириллических шрифтов. Так что придется предварительно потрудиться над русификацией.
Рисунок 10. Настройка сети вручную
языка – огромный минус, однако можно надеяться, что в следующих версиях ситуация изменится в лучшую сторону. Опытному пользователю, конечно же, будет не хватать коллекции портов и исходных кодов, но, потратив пару сотен мегабайт трафика, можно легко привести систему в привычное состояние. Таким образом, PC-BSD – хорошая отправная точка для установки FreeBSD на свой домашний или рабочий компьютер, хотя по сравнению с большинством дистрибутивов Linux этот дистрибутив пока еще заметно отстает и требует доводки «напильником». Впрочем, это можно объяснить его молодостью.
Поддержка сети Естественно, сеть дистрибутивом поддерживается в полном объеме. Но, как это ни печально, графической утилиты для ее настройки я не нашел. Поэтому придется воспользоваться старым добрым консольным способом (рис. 10). Кстати, обратите внимание, что ipfw по умолчанию включен как открытый. То есть он будет пропускать все пакеты, что выглядит не очень правильным решением. Работать с правилами ipfw также придется вручную.
Средства разработки В самом дистрибутиве помимо C-компилятора (куда же без него) можно найти Perl 5.8.7, Python 2.4.1, Ruby 1.8.2. Таким образом, у вас есть достаточно инструментов, чтобы сделать свою работу простой и комфортной. При необходимости вы можете установить KDevelop или Quanta из упомянутых ранее pbi-пакетов либо же воспользоваться системой портов, предварительно скачав себе свежее дерево коллекции.
Выносим вердикт Если смотреть на дистрибутив PC-BSD глазами начинающего пользователя, то при минимуме усилий вы получите уже настроенную графическую среду с некоторыми инструментами и возможностью в дальнейшем сосредоточиться на установке нужного ПО. Недостаточное количество прекомпилированых пакетов рано или поздно заставит разбираться с портами, хотя и без них можно собрать вполне работоспособную систему. Отсутствие полноценной поддержки русского
№8, август 2005
9
администрирование
ASTERISK И LINUX: МИССИЯ IP-ТЕЛЕФОНИЯ ДЕЙСТВИЕ 3
Соединив нашу мини-АТС с «городом» [1], мы уже получили привлекательное решение, способное обеспечить связью сотрудников небольшого офиса. Но не будем останавливаться на достигнутом – рассмотрим несколько веб-интерфейсов, значительно облегчающих работу как пользователей, так и администраторов Asterisk.
МИХАИЛ ПЛАТОВ Послушаем почту? Как вы помните, для проверки голосовой почты в нашем номерном плане есть специальный номер – 8500. Позвонив на него и введя личный пароль, наши пользователи могли прослушать оставленные им сообщения. Правда, иногда такой способ доступа бывает несколько неудобен (например, вы находитесь в другом городе или просто под рукой нет телефона). Для решения этой проблемы можно отсылать записанные сообщения на e-mail (см. [2]) или организовать централизованный доступ через Интернет с использованием безопасного SSL-соединения. Отрадно то, что в состав стандартного дистрибутива Asterisk веб-интерфейс для работы с голосовой почтой уже входит, просто в целях безопасности автоматически он не устанавливается. Что, впрочем, не мешает нам сделать это самостоятельно. Для работы данного интерфейса необходим вебсервер apache с пакетом perl-suid. Краткости ради будем считать, что эти пакеты у нас уже установлены и работают, а веб-сервер сконфигурирован так, что cgi-bin расположен в /var/www/cgi-bin, и cgi-скрипты, входящие в стандартную поставку, выполняются без проблем. Итак, перейдем в каталог /usr/src/asterisk и выполним команду make webvmail. Программа make скопирует все необходимые файлы и выдаст следующее предупреждение:
10
+--------- Asterisk Web Voicemail ----------+ + + + Asterisk Web Voicemail is installed in + + your cgi-bin directory. IT USES A SETUID + + ROOT PERL SCRIPT, SO IF YOU DON'T LIKE + + THAT, UNINSTALL IT! + + + +-------------------------------------------+
Если использование setuid вас устраивает, проигнорируйте это сообщение и перейдите к следующему шагу. В противном случае вы можете воспользоваться специальным патчем для Asterisk, описанным в [3]. Отредактируем файл скрипта vmail.cgi, определив следующее значение для контекста по умолчанию: context="ofÞce"
Откроем ваш любимый браузер и введем URL только что установленного интерфейса (в моем случае это будет http://ast-test/cgi-bin/vmail.cgi). Если все было сделано правильно, то мы увидим следующее (см. рис. 1). Введя имя пользователя (номер телефона) и пароль, мы попадем в папку «Входящие» нашего ящика (см. рис. 2). Пользователей linux-систем придется немного расстроить – воспроизведение в браузере через плагин (кнопка
администрирование play) скорее всего не заработает, и для прослушивания сообщений придется загружать файлы на компьютер (кнопка download), а вот с Windows все нормально (см. рис. 3). При организации работы из Интернета рекомендуется ограничить доступ к странице средствами веб-сервера, а также настроить использование SSL (https://) для безопасной передачи паролей.
Виртуальный «круглый стол» Возможности современных систем телефонии не ограничиваются ведением разговоров между двумя абонентами. С помощью специального режима – конференц-связь – возможно организовать одновременное общение нескольких человек. Системы разного «калибра» отличаются максимально допустимым количеством конференций, а также числом участников в них. И если в недорогих офисных мини-АТС количество собеседников, как правило, невелико (не больше 8-10 человек), то в Asterisk их максимальное число ограничивается лишь аппаратными возможностями используемого сервера. Существует как минимум 3 известных модуля, предоставляющих возможности конференций для Asterisk: ! MeetMe ! Conference ! MeetMe2 MeetMe является исторически первым приложением, предоставившим возможности конференций. Модуль является достаточно функциональным и позволяет решать широкий класс задач. Несмотря на то что MeetMe входит в стандартную поставку Asterisk, для его работы необходимы высокоточные таймеры, присутствующие в аппаратуре Digium. Модуль conference же, напротив, не требует наличия zaptel-устройств, однако он предоставляет несколько меньшую функциональность. Отличительной особенностью conference является более эффективное использование ресурсов сервера, что позволяет обеспечивать одновременную работу большего числа пользователей. MeetMe2 является переработанной версией MeetMe. Наиболее значимые отличия – хранение конфигурации в СУБД и несколько другие возможности управления. Все модули имеют схожую схему использования. После звонка по определенному номеру абонент попадает в «виртуальную комнату». Как только в «комнате» окажутся хотя бы два участника, начнется разговор. В конференциях существует 3 типа пользователей: «слушатели», «ораторы» и «администраторы». «Слушатели» лишены права голоса, «ораторы» могут не только слушать, но и разговаривать. На «администраторов» возлагаются обязанности управления – изменение статуса, удаление и добавление пользователей, открытие и закрытие «комнаты» и т. д. Основы работы с конференциями рассмотрим на примере модуля MeetMe. Как было сказано выше, для работы MeetMe необходимы высокоточные таймеры, присутствующие в оборудовании Digium. Если же никаких плат в машине с Asterisk нет, не расстраивайтесь, есть несколько способов программной эмуляции таймеров! Одним из них мы сейчас и воспользуемся. Этот способ применим для ядер 2.4.x (с модулем usb_
№8, август 2005
Рисунок 1. Окно входа веб-интерфейса системы голосовой почты
Рисунок 2. «Входящие» сообщения голосовой почты
Рисунок 3. Прослушивание сообщения голосовой почты
uhci) и 2.6.x. Откроем Makefile библиотеки zaptel и уберем комментарий (символ «#») перед ztdummy. Для zaptel 1.0.9 это строка 61. После этого пересоберем библиотеку (make & make install) и попробуем загрузить модуль ztdummy: # modpobe ztdummy
Убедимся, что у нас это получилось: # lsmod |grep ztdummy ztdummy zaptel
3620 225732
0 1 ztdummy
Настроим автоматическую загрузку модуля, добавив соответствующую запись в стартовые скрипты системы
11
администрирование (в случае Gentoo это будет строка в одном из файлов внутри /etc/modules.autoload.d). После этого можно смело приступать к настройке конференций. Определим «место встречи» (conference room) пользователей. Для этого в файл /etc/asterisk/meetme.conf добавим следующее: [rooms] conf=> 400
Этим мы создали «комнату» с номером 400. Теперь сделаем в ней «дверь». Для этого в файл extensions.conf добавим следующие строки: [confs] exten => 400 , 1, Meetme, 400 [ofÞce] include=> confs
Перезапустите Asterisk и позвоните на номер 400 со всех телефонов. Пользователи попадут в общую «комнату» №400 и смогут одновременно общаться друг с другом. Кроме статического описания «комнат» конфереций (пример, который мы только что рассмотрели), MeetMe также может создавать их динамически. В этом случае человек, открывающий «комнату», определяет для нее соответствующий пароль доступа. После этого он сообщает номер комнаты и пароль остальным участникам, и они начинают обсуждение. А любители подслушивать телефонные разговоры в это время злобно грызут ногти и кусают локти. Реализовать эту возможность на практике можно с помощью следующей конструкции номерного плана: [confs-dynamic] exten => 500, 1,MeetMe(|MD) [ofÞce] include => confs-dynamic
Теперь сделаем еще один шаг в сторону «идеального сервера» и установим веб-интерфейс для управления конференциями. С его помощью можно легко и просто подключать и отключать участников, давать и отбирать «право» голоса, да и вообще – просто наблюдать за тем, что происходит в наших «комнатах». Для работы с интерфейсом нам так же, как и с голосовой почтой, понадобится веб-сервер, только теперь с интерпретатором PHP. Будем считать, что все это у нас имеется, поэтому без промедлений приступим к установке. Первым делом скачаем с [12] архив с Web-MeetMe и распакуем его в Apache_DocumentRoot/meetme. Зайдем в каталог phpagi и скопируем файл phpagi.example.conf в /etc/ asterisk/phpagi.conf. Внесем в этот файл некоторые изменения:
[general] enabled = yes port = 5038 bindaddr = 127.0.0.1 [webmm] secret = webmmpw permit=127.0.0.1 read = system,call,log,verbose,command,agent,user write = system,call,log,verbose,command,agent,user
С конфигурационными файлами теперь все нормально, а вот с самими PHP-скриптами не очень. Дело в том, что web-meetme написан с учетом того, что переменная PHP RegisterGlobals определена как «On». Из соображений безопасности, начиная с PHP-4.2.0, значение по умолчанию для этой переменной – Off. Поэтому, для того чтобы скрипты заработали, необходимо либо поменять значение RegisterGlobals в файле php.ini, либо модифицировать файл conf_control.php, добавив в его начале следующие строки: getpost _ ifset(array('confno')); getpost _ ifset(array('action')); getpost _ ifset(array('user _ id'));
Кроме того, для нормальной работы с версией Asterisk 1.0.9 мне пришлось закомментировать строку 113 (вызов break) в файле conf_control.php. Если интерфейс установился нормально, то в браузере мы увидим следующее (см. рис. 4).
Системный телефон Неотъемлемым атрибутом любой мини-АТС является системный телефон. С его помощью оператор может полностью контролировать состояние мини-АТС (какие линии в данный момент свободны, какие заняты и т. д.). Более функциональным аналогом системного телефона для Asterisk является Flash Operator Panel. C помощью FOP можно переключать и завершать звонки, просматривать запаркованные вызовы, следить и управлять конференц-комнатами, да и просто наблюдать за тем, что происходит с Asterisk. С точки зрения администратора, FOP является клиент-серверным приложением. В качестве клиента выступает flash-приложение, выполняемое в любом из популярных браузеров (IE, Opera, Mozilla/Firefox). Серверная часть представлена perl-скриптом, в реальном времени получающим от Asterisk информацию о совершаемых в нем действиях. На момент написания этих строк последняя доступ-
server=127.0.0.1 port=5038 username=webmm secret=webmmpw
Данное приложение для свой работы использует командный интерфейс управления Asterisk (Asterisk Manager Interface – AMI). В целях безопасности по умолчанию он отключен, нам же потребуется его включить. Для этого отредактируем файл /etc/asterisk/manager.conf:
12
Рисунок 4. Интерфейс управления конференциями
администрирование
№8, август 2005
13
администрирование ная версия FOP – .22 (см. рис. 5). Домашняя страница проекта – [4]. При работе с Asterisk FOP также использует Asterisk Manager Interface. Таким образом, первое, что нам нужно будет сделать, – добавить в файл manager.conf соответствующую разрешающую запись: [fop _ user] secret = superfopsecret deny=0.0.0.0/0.0.0.0 permit=127.0.0.1/255.255.255.0 read = system,call,log,verbose,command,agent,user write = system,call,log,verbose,command,agent,user
Теперь перейдем к FOP. Настройки серверной части задаются в файле op_server.cfg. Наиболее значимыми для нас параметрами являются: manager _ host=127.0.0.1 manager _ user=fop _ user manager _ secret=superfopsecret
Этим мы указали perl-серверу, где и как нужно искать Asterisk. К слову, с помощью FOP можно отслеживать состояние несколько серверов Asterisk. В этом случае надо продублировать эти строки необходимое количество раз, задав в них соответствующие параметры других серверов. ßash _ dir=/var/www/html/fop web _ hostname=ast-test security _ code=fop _ pwd poll _ voice _ mail=1
Первой строкой мы задали местоположение файлов панели. Второй – имя, по которому к серверу будут обращаться клиенты (это необходимо для того чтобы FOP правильно формировал URL в процессе своей работы). Параметр security_code назначает пароль, который необходимо будет вводить для выполнения действий (переключение, завершение звонков). Четвертый параметр говорит серверу о том, что ему следует периодически самостоятельно проверять состояние голосовых ящиков (без использования AMI). Данный параметр необходим в случаях, если для доступа к почте используется веб-интерфейс. Следующие настройки касаются работы с конференциями: conference _ context=confs barge _ rooms=400 barge _ muted=1
Первая строка тривиальна – контекст номерного плана, содержащий внутренний номер для доступа к конференции. А вот на последних двух остановимся более подробно. Дело в том, что с помощью fop можно «собирать» людей в конференции. Третий параметр очень полезен в тех ситуациях, когда оператору необходимо прослушать разговор других абонентов. При значении «1» у пользователей, добавляемых FOP к конференции, будет «отключены микрофоны», таким образом можно незаметно подключать участников к конференции или организовывать прослушивание разговоров оператором. При необходимости «микрофон» можно включить, воспользовавшись все тем же веб-интерфейсом. Строкой barge_rooms мы определяем те номера
14
Рисунок 5. Структура Flash Operator Panel
«комнат», которые будут использоваться для реализации этой возможности. Кроме того, на панели FOP можно группировать кнопки по контекстам. Для этого перед ними необходимо написать имя соответствующего контекста. Параметры визуализации (клиентская часть) задаются в файле op_buttons. Синтаксис его достаточно прост. Сначала описываются кнопки, отвечающие за абонентов Asterisk: [SIP/200] Position=1 Label="Vasya" Extension=200 Context=ofÞce Mailbox=200@ofÞce Icon=1
; ; ; ; ; ; ; ; ;
имя абонента номер кнопки на консоли надпись на кнопке номер абонента контекст, в котором определен абонент ящик голосовой почты пользователя номер иконки для данного пользователя (то 1 до 6)
Чтобы не определять настройки для каждого пользователя вручную, можно задать общее описание с использованием регулярного выражения: [ _ SIP/.*] Position=n Label="SIP Users" Extension=-1 Context=generic _ inc Icon=2
; использовать следующий ; незанятый номер ; на эту кнопку перенаправлять ; звонки нельзя
Для отображения состояния места парковки воспользуемся следующим: [PARK701] Position=n Icon=3 Extension=700 Label="Park 701"
А вот так опишем «комнату» конференций: [400] Position=n Label="Meetme 400" Extension=400 Context=confs Icon=6
Следующие строки покажут нам состояние внешней zaptel-линии: [Zap/1] Position=10 Label="External 1" Extension=-1 Icon=2
Для большего удобства на панели можно нарисовать разделяющие прямоугольники и вспомогательные подписи. Сделать это можно, отредактировав файл, отвечающий за визуальное представление – op_style.cfg. В качестве последнего штриха настроим автоматический запуск perl-сервера при старте системы. Для этого мож-
администрирование но воспользоваться одним из готовых скриптов, входящих в состав дистрибутива (есть скрипты для Debian и Redhat) или просто прописать вызов op_server.pl (или safe_opserver) в стартовых скриптах вашего дистрибутива.
Единый центр управления Как вы могли заметить, настраивая Asterisk, мы редактировали те или иные конфигурационные файлы. Некоторым такой способ администрирования может показаться несколько неудобным. В таком случае рекомендую посмотреть в сторону Asterisk Management Portal. AMP представляет собой веб-приложение, позволяющее управлять настройками Asterisk с помощью популярного веб-браузера. Для лучшего понимания его работы обратимся к следующей схеме (см. рис. 6). Управление производится следующим образом: посредством веб-интерфейса администратор редактирует базу данных, задавая в ней необходимые параметры (добавление/удаление пользователя, смена пароля, изменение правил маршрутизации и т. д.). Затем, по информации, хранимой в этой базе, веб-сервер обновляет конфигурационные файлы Asterisk и с помощью AMI сообщает серверу о том, что настройки необходимо применить заново. Кроме того, используя дополнительный модуль (веб-интерфейс, для которого также входит в состав AMP), Asterisk помещает информацию о всех совершенных звонках непосредственно в MySQL, что открывает дополнительные возможности для анализа исходящего голосового трафика организации. После некоторого практического изучения данного продукта сложилось впечатление, что больше всего AMP подходит для 2 групп пользователей: ! Начинающие пользователи, имеющие лишь общее представление об Asterisk. ! Администраторы, уже имеющие опыт работы с Asterisk, без труда разбирающиеся в его конфигурационных файлах и желающие упростить выполнение некоторых наиболее типичных задач. Для первой группы пользователей AMP позволит настроить наиболее популярные вещи, не вдаваясь при этом в дебри конфигурационных файлов с их многочисленными и зачастую непонятными параметрами. Для данной категории самым сложным этапом является правильная установка портала. Впрочем, эта проблема легко решается применением специализированных дистрибутивов, уже имеющих в своем составе все необходимое, в том числе и AMP. Наиболее известный из них – Asterisk@Home [5]. Для второй категории пользователей AMP является мощным средством, позволяющим в короткие сроки получить законченное и достаточно функциональное решение на базе Asterisk. Причем здесь AMP выступает не как полный отказ от ручного редактирования конфигурационных файлов (как это было в первом случае), а скорее как удобное дополнение к ним (например, стандартные вещи делаются в портале, а нестандартные – путем custom-команд AMP или непосредственным редактированием конфигурационных файлов). На этом позвольте закончить описание теоритеское и перейти к практическому рассмотрению AMP. Учитывая
№8, август 2005
Рисунок 6. Связь AMP и Asterisk
характер работы данного приложения, не имеет смысла придерживаться уже созданной нами конфигурации. Поэтому при настройке Asterisk с использованием AMP будем считать, что перед нами вновь лежит «чистый лист». Итак, возьмем клавиатуру в руки и отправимся навстречу к нашей цели!
Устанавливаем AMP Для установки портала нам понадобятся все компоненты популярной платформы LAMP – Linux, Apache, MySQL и PHP (последний должен быть скомпилирован с поддержкой nls). Кроме того, нам также потребуются PHP-PEAR-DB, интерпретатор perl, а также perl-модули: Net::Telnet, IPC:Signal и Proc:WaitStat. Первые установим с помощью средств, имеющихся в распоряжении вашего дистрибутива, а для вторых воспользуемся репозитарием CPAN: # perl -MCPAN -e "install Net::Telnet" # perl -MCPAN -e "install IPC::Signal" # perl -MCPAN -e "install Proc::WaitStat"
Помимо этого нам потребуется добавить поддержку perl к самому Asterisk. Для этого установим модуль asterisk-perl, предварительно загрузив его с [6]. На этом подготовительные действия завершены, и мы можем смело приступить к установке самого AMP. По уже сложившейся традиции, воспользуемся последней стабильной версией, доступной на момент написания этих строк – 1.10.008. Загрузим и распакуем tarball с файлами проекта в удобное для нас место. Для определенности пусть это будет /usr/src: # cd /usr/src # wget http://citkit.dl.sourceforge.net/sourceforge/ ↵ amportal/AMP-1.10.008.tar.gz # tar xfz ./AMP-1.10.008.tar
Создадим две базы данных в MySQL. В первой будет храниться служебная информация AMP, во второй – информация о совершенных пользователями звонках. # mysqladmin create asterisk -p Enter password: <пароль root-пользователя MySQL>
# mysql-u root asterisk -p < usr/src/AMP/SQL/newinstall.sql
Первая база создана. Теперь дадим пользователю Asterisk необходимые права доступа: # mysql -u root -p
15
администрирование Enter password: <пароль root-пользователя MySQL> mysql> GRANT ALL PRIVILEGES -> ON asterisk.* -> TO auser@localhost -> IDENTIFIED BY 'p0rtalpwd'; Query OK, 0 rows affected (0.00 sec) mysql> \q
Создадим вторую базу: # mysqladmin create asteriskcdrdb –p Enter password: <пароль root-пользователя MySQL>
# mysql -u root asterisk -p < ↵ usr/src/AMP/SQL/cdr _ mysql _ table.sql Enter password: <пароль root-пользователя MySQL> mysql> GRANT ALL PRIVILEGES -> ON asteriskcdrdb.* -> TO auser@localhost -> IDENTIFIED BY 'p0rtalpwd'; Query OK, 0 rows affected (0.00 sec) mysql> \q
Теперь установим модуль регистрации звонков cdr_ mysql, входящий в состав пакета asterisk-addons.: # wget http://www.asterisk.org/html/downloads/ ↵ asterisk-addons-1.0.9.tar.gz # tar xfz ./asterisk-addons-1.0.9.tar.gz # cd ./asterisk-addons-1.0.9
В Makefile добавим следующую запись (строка 21): CFLAGS+=DMYSQL _ LOGUNIQUEID
И завершим инсталляцию модулей, выполнив команды: # make && make install
Стандартная схема установки AMP предполагает, что Asterisk и веб-сервер должны выполняться одним пользователем: # groupadd asterisk # useradd -c "asterisk PBX" -d /var/lib/asterisk -u ↵ 5060 –g asterisk asterisk
Настроим запуск веб-сервера от пользователя Asterisk. Для этого в конфигурационном файле apache напишем: Userasterisk Groupasterisk
Теперь установим файлы самого AMP. Для этого запустим соответствующий установочный скрипт (учтите, что после его выполнения существующие файлы конфигурации Asterisk будут замещены, поэтому при необходимости не забудьте сделать резервные копии):
/usr/sbin/asterisk -U asterisk
Убедимся, что автозапуск op_server.pl настроен и сам сервер запущен. Если все было сделано правильно, то, открыв http://имя_машины, мы увидим следующее (см. рис. 7).
Настройка AMP С интерфейсом голосовой почты мы уже знакомы, поэтому без лишних проволочек перейдем в основной раздел управления, щелкнув по ссылке «Asterisk Management Portal». Перед нами предстанут три раздела меню: настройка (Setup), отчеты (Reports) и панель FOP. Как следует из названия, для конфигурации системы используется Setup. Возможные действия в этом разделе перечислены в меню слева. Первым делом перейдем в подраздел Extensions и создадим несколько учетных записей пользователей (см. рис. 8). При настройках по умолчанию (и с уставленным zaptelоборудованием) сразу же после добавления пользователей и применения конфигурации уже можно совершать звонки, в том числе и с использованием ZAP-каналов через префикс 7. Правда, скорее всего нам предварительно потребуется немного подправить настройки zaptel для учета специфики отечественных АТС, но, учитывая наш опыт из [1], это вряд ли вызовет у нас какие либо серьезные трудности. Для настройки междугородней IP-телефонии необходимо создать транки (способ описания точек терминации внешнего по отношению к Asterisk трафика) и добавить соответствующие правила маршрутизации (раздел Outbound Routing). Формат этих правил во многом совпадает с тем, что мы определяли в текстовых файлах, поэтому практическое рассмотрение данной возможности мы оставим для самостоятельного изучения. Благо с использованием контекстных подсказок веб-интерфейса этот процесс не является очень сложным. В разделе Ring Groups мы несколькими движениями мышки можем объединить абонентов в единую группу вызова. Кроме того, также имеется возможность задать альтернативное поведение системы для случаев, когда ни один из абонентов группы не доступен (см. рис. 9). В Incoming Calls определяются правила обработки звонков, приходящих с ZAP-каналов. Стандартной функциональностью коробочного номерного плана AMP является возможность определения различных правил маршрутизации для рабочего и нерабочего времени. При этом в качестве адресатов могут выступать группы вызова, системы голосовых меню, очереди или обычные абоненты.
# /usr/src/AMP/install _ amp
В интерактивном режиме скрипт выведает у нас все необходимые имена, явки и пароли (попутно сохранив их для потомков в /etc/amportal.conf), скопирует все необходимые файлы и проинициализирует базу данных MySQL. Настроим работу asterisk с использованием учетной записи обычного пользователя. Для этого в стартовом скрипте Asterisk используем конструкцию следующего вида:
16
Рисунок 7. Стартовая страница AMP
администрирование
Рисунок 8. Создание абонентов в AMP
Рисунок 9. Группы вызовов абонентов
Рисунок 10. Модуль отчетов AMP
Рисунок 11. Интерфейс Flash Operator Panel
Для остальных разделов конфигурации ограничимся кратким описанием их назначения. ! Queues – здесь определяются параметры очередей и агентов. Более подробно эти параметры будут рассмотрены в одном из следующих номеров журнала. ! Digital Receptionist – автосекретать. С помощью этого пункта можно быстро создать голосовое меню. Например, запишем такой текст: «Здравствуйте! Вы позвонили в СамуюЛучшуюКомпанию. Для соединения с коммерческим отделом нажмите 1. Технический отдел – 2. Бухгалтерия – 3 и т. д.» Затем с помощью того же мастера создадим правила маршрутизации для этого меню, перенаправляющие пользователей в соответствующие отделы (в общем случае правила могут не соответствовать текстовому сообщению). И, наконец, назначим созданное меню для входящих звонков в подразделе Incoming Calls. Этим самым мы значительно снизим нагрузку на нашего секретаря, освободив его время для более интересной работы. ! DID Routes – маршруты прямого вызова. С помощью данной функции можно напрямую позвонить внутреннему абоненту/агенту/группе вызова Asterisk с использованием механизма DID (при этом DID также должен поддерживаться городской телефонной станцией).
№8, август 2005
! On Hold Music – в этом подразделе мы можем загру-
зить на сервер дополнительные мелодии для музыки при ожидании. ! System Recording – с помощью этого пункта меню можно добавлять (или записывать) в Asterisk дополнительные звуковые сообщения, которые впоследствии могут быть использованы в голосовых меню. ! Backup & Restore – как следует из названия, с помощью данного раздела можно резервировать и восстанавливать конфигурацию Asterisk-сервера. Для работы этой функции необходимо добавить в crontab выполнение содержимого /etc/asterisk/backup.conf. ! General Settings – в этом пункте определяются некоторые системные параметры AMP – время дозвона до абонента перед перенаправлением к голосовой почте, параметры работы с каталогом пользователей и настройки обработки входящих факсов. Более менее разобравшись с имеющимися возможностями настройки, остановимся на модуле отчетов. С его помощью администратор может не только получить детальную информацию за любой интересующий его период времени, но и просмотреть статистическую информацию о загрузке сервера в течение дня или на протяжении месяца.
17
администрирование Лирическое отступление о факсах Как вы могли заметить, один из разделов меню AMP посвящен настройке приема факсов в Asterisk, однако в статье об этой возможности не было сказано ни единого слова. Причиной тому является текущий уровень реализации поддержки работы с факсами в системах IP-телефонии в целом и в Asterisk в частности. Давайте рассмотрим эту проблему более внимательно. На самом верхнем уровне можно выделить два основных способа передачи факсимильных сообщений в системах IP-телефонии: ! Поверх существующего голосового кодека. ! С использованием протокола T.38. Первый способ фактически представляет собой обычный факс, подключенный к голосовому шлюзу, например с интерфейсом FXS. При этом, если мы хотим передать факс, мы набираем нужный нам номер, пытаемся установить соединение с аппаратом на другой стороне и т. д. А теперь вопрос на засыпку: «Помните ли вы, как работает модем? А как он работает на очень плохих или «старых» линиях?» Факс, обработанный одним из голосовых кодеков с сильным сжатием (GSM, G723, G729), будет работать еще хуже, вернее, скорее всего он не будет работать вообще. С кодеками, не использующими сильное сжатие с потерями (в Asterisk это G711 в вариантах a-law и u-law), ситуация будет лучше. При этом качество передачи факсов во многом будет зависеть от реального состояния IP-канала (потери, джиттер, задержка) между абонентами (ведь на самом деле мы передаем «голос», следовательно, исполь-
зуем протокол UDP, не предоставляющий гарантий доставки пакетов). Если вдобавок еще и взглянуть на первую строчку таблицы в [8], то мы увидим, что при передаче факса через Интернет нам потребуется канал с реальной пропускной способностью около 80 кБит, что, согласитесь, уже немало. По этим и другим причинам для передачи факсов через голосовые сети все чаще стараются использовать T.38. Данный протокол был разработан организацией ITU-T специально для передачи факсов в VoIP-сетях. Механизм работы устройств, поддерживающих данный протокол, следующий – при обнаружении голосовым шлюзом сигналов факса он пытается установить дополнительное соединение с другим шлюзом (благо и H323 и SIP это позволяют), но уже с использованием T.38. Благодаря использованию помехоустойчивого кодирования, а также протокола с гарантией доставки – TCP с использованием T.38 можно получить практически идеальное качество передачи факсов. Правда, и для этой ложки меда имеется своя бочка дегтя – поддержка протокола T.38 в существующих на сегодняшний день устройствах все еще оставляет желать лучшего. Дело в том, что согласно стандартам, на данный момент существует 3 (!) различных способа передачи факсов с использованием T.38: ! Поверх протокола UDP. ! Поверх протокола TCP. ! Передача в RTP-пакетах. Первые два способа фактически представляют собой специализированные протоколы для передачи факсов (протоколы IFP/udptl и IFP/TCP соответственно), в то время как третий
Поддерживается выгрузка отчетных данных в формате pdf и csv (см. рис. 10).
Интерфейс панели управления Третьим разделом интерфейса управления является уже знакомая нам Flash Operator Panel. В состав последней версии AMP входит несколько устаревшая версия FOP (20 против 22 на сайте разработчика). Правда, некоторой компенсацией за это является интеграция AMP и FOP при установке «из коробки». Так, добавляя нового пользователя в AMP, запись о нем автоматически появляется и в FOP, что избавляет нас
18
больше похож на использование T.38 вместо обычного кодека (факсовые данные упаковываются в обычные RTP-пакеты). Проще говоря, поддержка в прокси-серверах первых двух протоколов требует дополнительных усилий от разработчиков, в то время как для третьего варианта достаточно поддержки в конечных устройствах. К тому же ситуация усугубляется тем, что зачастую производители голосового оборудования если и реализуют поддержку T.38 в своих устройствах, то ограничиваются лишь одним из вариантов реализации (чаще первым), со всеми вытекающими отсюда несовместимостями и проблемами. Что же касается Asterisk, то на данный момент он абсолютно точно не поддерживает два первых варианта использования T.38 (заметьте, это вовсе не означает, что такая поддержка невозможна в принципе). С третьим способом ситуация комичнее – до настоящего времени ни одного устройства, использующего T.38 поверх RTP, сообществом разработчиков Asterisk обнаружено не было, поэтому информации о его практической работоспособности нет. Таким образом, реальная поддержка передачи факсимильных сообщений в Asterisk на данный момент возможна только с использованием кодека G711, причем наиболее предпочтительна следующая схема: входящий факс-сервер, работающий поверх G711 c использованием zaptelустройств Asterisk. В завершение упомянем и другой взгляд на эту проблему. А нужна ли вообще передача факсов в VoIP-сетях? Если IP-инфраструктура уже существует, то не проще ли в данном случае использовать что-то другое, например e-mail?
от необходимости лишний раз редактировать файлы конфигурации. Давайте более подробно остановимся на графическом интерфейсе. Как уже говорилось выше, клиентская часть FOP разработана с использованием Macromedia Flash. Это не могло не оставить отпечатка на характере работы с визуальным интерфейсом. Все действия с абонентами производятся либо с помощью двойного щелчка мыши, либо методом «drag and drop». Так, для того чтобы принудительно завершить сеанс пользователя, необходимо нажать на «1» (см. рис. 11), а для того чтобы соединить двух абонентов, – перетащить значок телефона на кнопку вызываемого абонента.
администрирование AMP мини-FAQ Страница FOP «зависает» при открытии. В чем может быть причина? Убедитесь, что серверный perl-скрипт запущен. При работе с веб-интерфейсом выдаются сообщения об ошибках записи. Возможно, установлены неверные права доступа к файлам конфигурации Asterisk. Для автоматического исправления запустите скрипт apply_conf.sh из дистрибутива AMP. При работе с интерфейсом выдается сообщение об ошибке соединения с manager. Неверно сконфигурирован (или отключен) интерфейс управления Asterisk. Проверьте содержимое файлов /etc/ asterisk.manager.conf и /etc/amportal.conf. К сожалению, текущая реализация совместной работы FOP и Asterisk не лишена недостатков. Так, в варианте «из коробки» FOP не видит стандартных конференций AMP. Для решения этой проблемы воспользуемся нашими знаниями о структуре конфигурационных файлов. Первым делом в файле op_ server.cfg в качестве контекста для конференций укажем extmeetme, для параметра barge_roooms выберем одно из стандартных для AMP значений, например 8200, и опишем соответствующие кнопки в файле op_buttons_custom.cfg согласно инструкции, приведенной выше для FOP. После этого перезапустим perl-сервер, обновим страницу интерфейса клиента и порадуемся, увидев в нем кнопки, соответствующие MeetMe. Теперь с помощью веб-интерфейса мы можем «собирать» людей в виртуальных «комнатах» для проведения совместных обсуждений (drag-and-drop на картинку конференции), а также подключаться к уже идущим разговорам. (правда, для незаметной работы последнего, возможно, потребуется более тонко настроить работу модуля MeetMe). С отображением состояния парковочных мест можно поступить аналогично.
Заключение В заключение давайте еще раз кратко рассмотрим сильные и слабые стороны AMP. Итак, преимущества: ! Возможность редактирования параметров Asterisk через веб-интерфейс. ! Возможность получения информации о совершенных звонках. ! Быстрое создание голосовых меню. ! Возможности автосекретаря. ! Использование «транков». ! Определение правил маршрутизации . ! Загрузка мелодий для «музыки при ожидании». ! Определение групп вызова. Но, как известно, у каждой медали есть и вторая сторона. У AMP она выглядит так: ! Необходимость перезаписи конфигурационных файлов. ! Необходимость функционирования всех ключевых компонент на одном компьютере (как следствие из предыдущего).
№8, август 2005
Asterisk начинает запускаться, но, дойдя до загрузки zap-устройств, процесс внезапно завершается. Проверьте, что модули ядра zaptel и wcfxo загружены и устройства проинициализировались без ошибок (lsmod, dmesg). Или проверьте, что файл /etc/asterisk/zaptel.conf существует и в нем правильно заданы параметры устройств. Не показываются (или показываются неверно) сообщения голосовой почты через веб-интерфейс. Убедитесь, что пользователь веб-сервера имеет доступ к файлам голосовой почты (/var/spool/asterisk/voicemail). Добавил пользователей, но в FOP они не появились. В чем может быть дело? Необходимо перезапустить op_server.pl
! Возможные проблемы с масштабируемостью (как следствие из предыдущего).
! Отсутствие управления параметрами MeetMe через вебинтерфейс.
! Отсутствие встроенной системы безопасности. ! Достаточно сложная структура номерного плана (особенно для начинающих пользователей).
! Шероховатости в интеграции с FOP. ! Отсутствие русского интерфейса меню. ! Проблемы совместимости между номерным планом
и аппаратным голосовым оборудованием (некоторые шлюзы не могут корректно набирать символы «#,*» которые очень активно используются в номерном плане).
При всем этом, несмотря на указанные недостатки, Asterisk Management Portal, безусловно, можно считать одним из лучших веб-интерфейсов для Asterisk. Проект очень активно развивается, и вполне возможно, что многие из перечисленных недочетов будут исправлены в следующей версии. При этом не стоит забывать, что AMP полностью открыт и вы сами можете принять непосредственное участие в его дальнейшем развитии. Ну а если разработка вебприложений вам не близка, а AMP вам просто понравился как пользователю, не забудьте сделать donation на официальном сайте проекта [7].
Литература, ссылки: 1. Платов М. Asterisk и Linux – миссия IP-телефония. Действие 2. – Журнал «Системный администратор», №7, 2005 г. – 32-38 c. 2. Платов М. Asterisk и Linux – миссия IP-телефония. – Журнал «Системный администратор», №6, 2005 г. – 12-19 c. 3. http://www.voip-info.org/tiki-index.php?page=Asterisk+gui+ vmail.cgi. 4. http://www.asternic.org. 5. http://asteriskathome.sourceforge.net. 6. http://asterisk.gnuinter.net. 7. http://sourceforge.net/projects/amportal. 8. Платов М. Что важно знать об IP-телефонии. – Журнал «Системный администратор», №5, 2005 г. – 20-25 c.
19
администрирование
СОЗДАЁМ СИСТЕМУ УЧЕТА ИСХОДЯЩИХ ТЕЛЕФОННЫХ ЗВОНКОВ
ДЕНИС СОКОЛОВ Сегодня мы займемся созданием системы учета исходящих телефонных звонков на примере УАТС LG GDK-162. От вас требуется: навыки работы в UNIX-подобных операционных системах, умение программировать на Perl и базовые знания в SQL.
Н
едавно руководство поставило задачу – необходимо вести учет всех исходящих телефонных звонков. В офисе установлена УАТС LG GDK-162 емкостью 48 внутренних номеров и 8 внешних линий. Различные программы тарификации имеются в избытке. Но ни одна меня не устроила. Большинство из них платные и написаны под Windows, из некоммерческих только SMDR 1.0 поддерживает LG GDK-162. Для операционных систем Linux и FreeBSD существует очень интересный проект ATSlog: http://www.atslog.dp.ua. Вот описание с сайта программы: «ATSlog предоставляет удобный интерфейс с доступом через веб-браузер для просмотра и анализа звонков различных моделей мини-АТС. Программа бесплатная, распространяется под лицензией GPL, имеет полностью открытый код. Программа успешно работает с моделями Panasonic KX-TA308, KX-TA308RU, KX-TA616RU, KX-TD816RU, KX-TD1232; Samsung SKP-816». К сожалению, не нашел в списке поддерживаемых АТС LG GDK. Для добавления поддержки нужной модели можно отослать автору образцы текстовых лог-файлов. Но это требует времени. Я решил попробовать справиться с задачей своими силами. Это оказалось несложным. Надеюсь, что мой опыт окажется вам полезен. LG GDK-162, как и большинство офисных АТС, можно подключить к компьютеру через порт RS-232. Параметры порта: 9600 бит/с, 8 бит данных, без контроля паритета, 1 стоповый бит. Таблица 1. Распайка кабеля (стандартный нуль-модем)
Я подключился к последовательному порту УАТС при помощи терминальной программы и стал анализировать считываемые данные. Оказалось, что LG GDK-162 протоколирует свою работу в режиме реального времени, а записи об исходящих звонках выглядят следующим образом: 1035 144 06
! ! ! ! ! ! !
00:11 21/08/2005 16:21 O1234567
Рассмотрим её содержимое: первое поле – порядковый номер записи; второе – номер станции, с которой сделан вызов; третье – номер внешней линии; четвертое – длительность звонка (mm:ss); пятое – дата; шестое – время (hh:mm); седьмое – вызванный номер с ведущим символом O. Седьмое поле может кроме цифр содержать символы «#» и «*» – это происходит при звонках на голосовые шлюзы операторов IP-телефонии.
Таким образом, задача учета исходящих телефонных звонков свелась к написанию программы для считывания журнала работы УАТС через порт RS-232, обработки и сохранения соответствующих записей. Можно приступать к реализации. Исходные данные: учет будет осуществляться на машине Cel 1200/RAM 128 Мб/HDD 20 Гб, операционная система – Debian GNU/Linux 3.1r Sarg, СУБД – PostgreSQL v. 7.4.7, УАТС подключена к последовательному порту /dev/ttyS1. Создадим пользователя, от которого будет работать программа и рабочий каталог. Кроме этого, изменим права доступа к /dev/ttyS1: # sudo useradd -d /var/gdklog -s /bin/sh gdk
20
**
администрирование # # # # #
sudo sudo sudo sudo sudo
passwd gdk mkdir /var/gdklog chown gdk:gdk /var/gdklog chown root:gdk /dev/ttyS1 chmod 640 /dev/ttyS1
Создадим пользователя и базу данных в PostgreSQL: # createuser -U postgres -A -D gdk # createdb -U postgres -O gdk pbxbilling
Создадим таблицу gdklog для хранения статистики. Таблица имеет пять полей: ! d_time – дата и время; ! station – станция; ! line – внешняя линия; ! t_call – продолжительность разговора; ! c_number – вызванный номер (я выбрал для этого поля тип numeric, т.е. номер телефона сохраняется, как число, при этом ведущие нули усекаются, например, номер 01 сохранится в БД как 1). # vi gdklog.sql CREATE TABLE gdklog ( "d _ time" timestamp, "station" int2, "line" int2, "t _ call" time, "c _ number" numeric (30, 0) ); REVOKE ALL on "gdklog" from PUBLIC; GRANT ALL on "gdklog" to "gdk"; # psql -U gdk -d pbxbilling < gdklog.sql
Писать программу учета я решил на perl. Полный текст вы можете скачать с сайта www.samag.ru, раздел «Исходный код». Для чтения данных из последовательного порта вполне подойдут стандартные функции для работы с файлами. Естественно, порт необходимо предварительно настроить. Для этого я использовал вызов программы sty: my $ttys = "/dev/ttyS1"; # Количество строк журнала, кэшируемых в памяти my $m _ cache = 50; system ("/bin/stty -F $ttys 9600 cs8 -parenb -cstopb"); # Читаем данные из последовательного порта open (TTYS, "< $ttys") or die "Can’t open $ttys!"; while (<TTYS>) { parse _ log; }
Функция parse_log – единственная в программе, специфичная для LG GDK-162. sub parse _ log { # Если массив log содержит m _ cache строк, # то заносим данные в БД if (@log >= $m _ cache) { push _ to _ db; } # Отбираем строки фиксирующие исходящие звонки if (/O\d+/) { # Удаляем символы *, #, O s/[\*,O,\#]+//g; # Сохраняем полученную строку в массив log push (@log, $ _ );
№8, август 2005
} print; }
Допустим, надо добавить поддержку АТС, пишущую протокол в формате: 2005-08-21 16-21-00 06 1234567 00:00:11 144
Для этого достаточно будет дописать еще одну конструкцию if в функцию parse_log (кроме этого, надо не забыть проверить параметры последовательного порта). if (/^(\d{4}\-\d{2}\-\d{2})\s+(\d{2}\-\d{2} ↵ \-\d{2})\s+(\d{2})\s+(\d+)\s+(\d{2}\:\d{2}\:\d{2})\s+ { push (@log, "00 $6 $3 $5 $1 $2 $4"); }
Постоянно держать открытым соединение с базой данных – не очень хорошая идея. Поэтому все строки, соответствующие регулярному выражению «/O\d/g» (журнал исходящих вызовов), сначала заносятся в массив @log. Как только в нем накапливается $m_cache строк – вызывается процедура push_to_db, которая устанавливает соединение с базой pbxbilling и записывает данные в таблицу gdklog: # $d _ time // Дата и время # $station // Внутренний номер # $line // Внешняя линия # $t _ call // Продолжительность вызова # $date // Дата # $time // Время # $c _ number // Вызванный номер my ($d _ time, $station, $line, $t _ call, $date, $time, $c _ number, @log); # Параметры соединения с базой данных my $base = "pbxbilling"; my $user = "gdk"; my $pass = ""; sub push _ to _ db { # Подготовка соединения my $dbh=DBI->connect("DBI:Pg:dbname=$base", "$user", "$pass", {PrintError => 0, RaiseError => 0} ) or return 2; # Подготовка запроса my $ins = $dbh->prepare(q{ INSERT INTO gdklog (d _ time , station, ↵ line, t _ call, c _ number) VALUES (?, ?, ?, ?, ?) }); # Перебираем в цикле все сохраненные строки foreach my $log (@log) { # Разбираем строку (undef, $station, $line, $t _ call, $date, ↵ $time, $c _ number) = ↵ split (/\s+/, $log); if (length ($t _ call) < 6) { $t _ call="00:$t _ call"; } $d _ time = "$date $time"; # Выполняем INSERT $ins->execute($d _ time, $station, $line, ↵ $t _ call, $c _ number) or return 2; } # Очистим массив undef (@log); $dbh->disconnect(); return 0; }
Кроме этого, мне нужно было, чтобы программа могла работать в режиме демона:
21
администрирование # В режиме демона в этот файл перенаправляем все # сообщения об ошибках my $err _ Þle = "/var/gdklog/gdklogd.err"; # PID-файл my $pid _ Þle = "/var/gdklog/gdklogd.pid"; sub begin _ daemon { # Делаем fork my $pid = fork; exit if $pid; die "Couldn’t fork: $!" unless deÞned($pid); # Сохраняем PID в файл open (F _ PID, ">$pid _ Þle") or die "Can’t open ↵ $pid _ Þle: $!"; print F _ PID "$$\n"; close F _ PID; # Перенаправляем вывод STDERR в файл open (*STDERR, ">> $err _ Þle") or die "Can’t ↵ reopen *STDERR to $err _ Þle: $!"; # Перенаправляем STDIN и STDOUT в /dev/null for my $handle (*STDIN, *STDOUT) { open ($handle, "> /dev/null") or die ↵ "Can’t reopen $handle to /dev/null: $!"; } # Установка sid процесса POSIX::setsid() or die "Can’t start a new session: $!"; }
Чтобы обеспечить целостность данных, я установил обработчики сигналов INT и TERM. Получая один из них, программа будет пытаться немедленно записать данные в базу, если это окончится неудачей (например, сервер БД отключен), то выполнится процедура dump_to_file, которая просто запишет содержимое @log в текстовый файл. После этого работа программы будет завершена. Второй обработчик добавляет возможность записи данных в базу по сигналу HUP без выхода из программы. $SIG{INT} = $SIG{TERM} = sub { dump _ to _ Þle if ↵ push _ to _ db; exit }; $SIG{HUP} = sub { dump _ to _ Þle if push _ to _ db };
Меняем владельца и права доступа: # sudo chown root:gdk /usr/local/sbin/gdklogd # sudo chmod 750 /usr/local/sbin/gdklogd
Напишем стартовый сценарий:
# vi /etc/init.d/gdklogd #!/bin/sh DAEMON=/usr/local/sbin/gdklogd DAEMONFLAGS="-D" KILL=/bin/kill PID=/var/gdklog/gdklogd.pid CAT=/bin/cat SU=/bin/su start () { echo -n $"Starting $DAEMON: " # Запуск с правами непривилегированного пользователя $SU -c "$DAEMON $DAEMONFLAGS" gdk 2>/dev/null 1>&2 } stop () { echo -n $"Stopping $DAEMON: " $KILL `$CAT $PID` 2>/dev/null 1>&2 } case "$1" in start) start ;; stop) stop ;; restart) stop start ;; *) echo $"Usage: $0 {start|stop|restart}" exit 1 esac # sudo chown root:root /etc/init.d/gdklogd # sudo chmod 700 /etc/init.d/gdklogd
Запустим: # sudo /etc/init.d/gdklogd start
После запуска сценария с параметром -D он переходит в режим демона, настраивает последовательный порт и начинает считывать из него данные. При запуске без параметра -D сценарий не отсоединяется от терминала, а записи об исходящих звонках дублируются на экран. Если все сделано правильно, то через некоторое время таблица gdklog начнет заполняться записями. # sudo kill –HUP `cat /var/gdklog/gdklogd.pid` # psql -c 'SELECT * FROM gdklog;' -U gdk pbxbilling d_time | station | line | t_call | c_number ---------------------+---------+------+----------+---------2005-08-21 16:21:00 | 144 | 6 | 00:00:11 | 1234567 (1 запись)
Рисунок 1. Схема учета исходящих телефонных звонков
22
Вот и все. При минимуме усилий мы получили вполне работоспособную и переносимую систему учета исходящих звонков УАТС LG GDK-162. Работа скрипта проверялась на Debian GNU/Linux 3.1r Sarg и FreeBSD 5.2.1 (надо изменить только имя файла последовательного порта $ttys). Модуль DBI позволяет использовать любую поддерживаемую им СУБД с минимальной правкой кода, а также доступ к базе данных по сети. Для получения отчетов к нашим услугам вся мощь SQL. Несложно добавить поддержку других моделей УАТС. А при наличии свободного времени можно написать веб-интерфейс. Успехов!
администрирование
НАСТРАИВАЕМ DSPAM – ВАШ ЛИЧНЫЙ СПАМ-ФИЛЬТР
Фильтрация почты, особенно на сервере провайдера, затруднена тем, что администратор не может брать на себя вынесение вердикта, что доставить абоненту, а что нет. Система DSPAM позволяет переложить принятие такого решения на пользователя.
СЕРГЕЙ СУПРУНОВ
В
одной из предыдущих статей [1] рассматривалась система защиты от нежелательной почты, – spamd, использующая блокировку входящих соединений на основе «черных» списков. Такие способы эффективны для снижения входящего почтового трафика, однако не в состо-
24
янии защитить от писем, идущих с новых, еще не «засвеченных», адресов. Кроме того, подобные фильтры, будучи запущенными на провайдерских серверах, могут стать источниками конфликтов с пользователями, адресат которых случайно попал в тот или иной список.
администрирование Сегодняшняя статья посвящена второму эшелону спамобороны, который будем строить на базе DSPAM (разработчик Jonathan Zdziarski, www.nuclearelephant.com). Данная обучаемая статистическая система обрабатывает сообщения, благополучно прошедшие через MTA и направляющиеся в ящик пользователя. Основным ее достоинством является возможность персональной настройки для каждого пользователя.
Как происходит классификация писем В основе работы системы DSPAM лежит несколько наиболее популярных алгоритмов статистического анализа, которые, в свою очередь, опираются на теорему Байеса (Thomas Bayes). Формула Байеса позволяет рассчитать вероятность наступления некоторого события в зависимости от того, какова была вероятность данного события в прошлом. Применительно к спаму, упрощенно принцип работы байесового классификатора можно описать такой формулой: P= S / (S + G)
(1)
где: ! P – вероятность того, что сообщение окажется спамом, ! S – суммарный коэффициент «спамности» сообщения, ! G – суммарный коэффициент «неспамности» сообщения. Sи G рассчитываются по следующим формулам: S = p(w1)*p(w2)*…*p(wn) G = (1 – p(w1))*(1 – p(w2))*…*(1 – p(wn))
(2)
Здесь p(w1) и другие – коэффициенты «спамности» отдельных слов, входящих в анализируемое сообщение, полученные на основе ранее классифицированных писем. Так, если в прошлом 9 писем со словом «английский» было спамом и одно – не спамом, то p(‘английский’) = 9 / (9 + 1) = 0.9. В качестве примера проанализируем такое короткое сообщение: Привет! Купи меня!
Пусть ранее указанные слова встречались в следующих письмах:
p('Привет') = 35 / (35 + 64) = 0,35 p('Купи') = 187 / (187 + 19) = 0,91 p('меня') = 9 / (9 + 11) = 0,45 S= 0,35 * 0,91 * 0,45 = 0,14 G= (1 – 0,35) * (1 – 0,91) * (1 – 0,45) = 0,03 P= 0,14 / (0,14 + 0,03) = 0,82
Таким образом, приведенный выше пример будет с вероятностью 82% нежелательным сообщением, в основном за счет высокой спамности слова «Купи».
№8, август 2005
В алгоритме, предложенном Полом Грэмом (Paul Graham), для расчета применяется приведенная выше методика с использованием следующих правил: ! Для анализа сообщений используются не все слова, а 15 наиболее «интересных», для которых p(w) наиболее сильно отклоняется от нейтрального значения 0,5. ! Если ранее слово встречалось менее чем в пяти письмах, оно игнорируется. ! Новое слово, не встречавшееся ранее, получает стартовую «спамность» 0,4 (своего рода презумпция невиновности). Алгоритм Бартона (Brian Burton) работает аналогично, но использует для анализа не 15, а 27 наиболее ярких слов, а также допускает «удвоенное» использование слова, если оно встречается в сообщении несколько раз. Это несколько повышает эффективность при ограниченных данных. Кроме того, поддерживаются цепочки «токенов», когда два стоящих рядом слова рассматриваются вместе. Также некоторые отличия от подхода Грэма имеются в наборе символов, которые считаются составной частью слова (такие, как $, ! и т. д.). Следующий популярный алгоритм, разработанный Гари Робинсоном (Gary Robinson), модернизирует формулу Грэма таким образом, чтобы решить проблему недостаточных исторических данных: f(w) = (0,5 + n(w) * p(w)) / (1 + n(w))
(3)
где : ! p(w) – вероятность для слова, рассчитанная на основе исторических данных; ! n(w) – количество ранее обработанных сообщений со словом w. Таким образом, если анализируемое слово ранее не встречалось, оно автоматически получит коэффициент 0,5, а по мере накопления статистики это значение будет выходить на свой естественный уровень. В дальнейшем в формулах (2) вместо величин p(w) используется f(w). Для анализа по алгоритму Робинсона используется выборка из 25 слов. На базе алгоритма Робинсона был разработан улучшенный алгоритм Фишера-Робинсона, известный также как ChiSquare (переводить на русский язык не рискну). Помимо расчета «спамности» сообщения вычисляется также вероятность его «неспамности» по формуле Фишера, и в дальнейшем рассматривается интегральная вероятность. В фильтре DSPAM реализована поддержка всех четырех описанных здесь алгоритмов. Причем анализу подвергается не только тело сообщения, но и заголовок. Разработчик не рекомендует совмещать фильтры Грэма и Бартона с фильтрами Робинсона во избежание ложных срабатываний.
Способы интеграции DSPAM с почтовой системой Система DSPAM поддерживает два способа взаимодействия с почтовым сервером. В первом случае он может быть
25
администрирование настроен как локальный агент доставки (LDA – local delivery agent). При этом сообщения анализируются по пути от MTA к почтовому ящику. После обработки фильтром почта отдается на обработку реальному LDA, который и завершает доставку. Второй способ – работа DSPAM в сотрудничестве с POP3-proxy. При этом спам отсеивается в то время, когда пользователь выкачивает корреспонденцию из своего почтового ящика по протоколу POP3. Подробнее настройка для работы в том или ином режиме будет рассмотрена позже.
Устанавливаем DSPAM из коллекции портов Для конкретизации в данной статье будет рассматриваться работа DSPAM на системе со следующим версиями программного обеспечения: ! Операционная система: FreeBSD 5.4. ! Веб-сервер: Apache 1.3.33 с включенной поддержкой suexec. ! Система управления базами данных: PostgreSQL 8.0.2. Наиболее удобный способ инсталляции ПО в системе FreeBSD (естественно, на мой взгляд – навязываться никому не буду) – использование коллекции портов. Если планируется использовать CGI-сценарии для управления фильтром, я рекомендую создать отдельного пользователя dspam и одноименную группу. В дальнейшем мы настроим виртуальный хост, который будет работать от имени добавленного пользователя. После этого выполняем обычные процедуры: # # # #
cd /usr/ports/mail/dspam vi MakeÞle make make install
Конечно, вместо редактирования файла Makefile можно использовать ключи в командах make и make install, но их может оказаться слишком много, да и мне удобнее, чтобы информация о параметрах оставалась не только в истории командной оболочки. По большому счету, этот этап можно вообще опустить – настройки, используемые по умолчанию, подходят в большинстве случаев, тонкую же подстройку можно будет выполнить в дальнейшем путем редактирования конфигурационного файла. Я выполнил только одну правку (красным показана исключенная строка, синим – добавленная): DSPAM _ MODE?= DSPAM _ OWNER?= DSPAM _ GROUP?=
это существенно упростит нам жизнь при настройке CGI-клиента. Сам же демон dspam будет работать с правами root, что определяется второй строкой приведенного выше фрагмента (см. следующий раздел про права доступа). Если вам удобнее работать с ключами команды make, то же самое можно сделать, задав ключ DSPAM_HOME_OWNER=dspam. После ввода команды make вам будет предложено диалоговое окно (рис. 1), в котором следует отметить необходимые опции. Обратите внимание на то, что должен быть отмечен только один драйвер СУБД. Также отметьте опцию «Install CGI (pulls in apache)», если планируете использовать CGI-модуль. Еще следует указать используемый вами MTA. Некоторые другие полезные опции приведены ниже: ! USER_HOMEDIR: использовать для хранения данных пользователя его домашний каталог вместо директории, определенной переменной DSPAM_HOME. ! TRUSTED_USERS: отключить (!) использование доверенных пользователей. Если данная опция будет отмечена, все пользователи смогут управлять фильтром dspam (если, конечно, будут обладать достаточными правами для запуска соответствующих исполняемых файлов). ! LARGE_SCALE: опция полезна в системах с большим числом абонентов. При ее активации домашние каталоги пользователей будут находиться не непосредственно в папке data каталога /var/db/dspam, а во вложенных подкаталогах по начальным буквам имени пользователя. Например, каталог с данными пользователя gorod будет находиться по следующему пути: /var/db/dspam/ data/g/o/gorod. Данная опция и USER_HOMEDIR взаимоисключаемы. ! VIRT_USERS: этот ключ используется, если ваш почтовый сервер работает с виртуальными пользователями. При этом дополнительно будет создана таблица идентификаторов пользователей (по умолчанию dspam в процессе работы руководствуется данными реальных пользователей из /etc/passwd). После сборки (необходимые зависимости, такие как библиотека GD, будут удовлетворены автоматически) переходим к конфигурации.
Несколько слов о правах доступа Для нормальной работы DSPAM большое значение играют правильно установленные права доступа, особенно если используется CGI-модуль. Как было показано выше, в про-
4510 root mail
DSPAM _ HOME?= ${ _ VAR _ DIR}/db/dspam #DSPAM _ HOME _ OWNER?= ${DSPAM _ OWNER} DSPAM _ HOME _ OWNER?= dspam DSPAM _ HOME _ GROUP?= ${DSPAM _ GROUP} DSPAM _ HOME _ MODE?=
Этой настройкой владельцем домашнего каталога программы dspam, в котором будут храниться файлы настроек пользователей, их ящики-карантины, лог-файлы и т. д., мы объявляем созданного пользователя dspam. В дальнейшем
26
Рисунок 1. Конфигурационный диалог
администрирование цессе сборки порта можно задать пользователя, отличного от root. С одной стороны, это способствует повышению безопасности, но в то же время порождает массу дополнительных сложностей. Во-первых, при работе в режиме LDA dspam должен быть способен вызывать агент доставки и передавать ему необходимые для дальнейшей работы права. А чтобы положить почту в ящик пользователя при стандартных настройках, эти права должны соответствовать пользователю root. Во-вторых, dspam должен иметь достаточно прав, чтобы создать pid-файл при запуске в режиме демона, а также быть способным создать сокет на привилегированном порту 24 (LMTP), что опять-таки требует прав суперпользователя. Так, у меня попытка запустить dspam в режиме демона после сборки с пользователем dspam, указанным как владелец, завершилась такими ошибками: # /usr/local/etc/rc.d/dspam.sh start Starting dspam. 486: [7/26/2005 9:10:17] Daemon process starting 486: [7/26/2005 9:10:18] Unable to open file for writing: /var/run/dspam.pid: Permission denied 486: [7/26/2005 9:10:18] Could not bind to :24 (Permission denied) 486: [7/26/2005 9:10:18] daemon_listen() failed 486: [7/26/2005 9:10:18] Daemon process exiting
Учитывая вышеизложенное, я решил оставить владельцем dspam пользователя root, как это определено по умолчанию. Хотя при наличии огромного желания и крепких нервов можно добиться работы и от имени непривилегированного пользователя.
Основные настройки в dspam.conf Перед первым запуском необходимо переименовать файл /usr/local/etc/dspam.conf.sample в dspam.conf и произвести в нем нужные изменения. Прежде всего введите правильные настройки для взаимодействия с СУБД. DSPAM умеет использовать для хранения рабочей информации такие СУБД, как MySQL, PostgreSQL, SQLite, Oracle. Для слабо нагруженных систем можно использовать DB3 или DB4, но разработчики это не рекомендуют. Например, мои значения для PostgreSQL выглядят следующим образом: PgSQLServer PgSQLPort PgSQLUser PgSQLPass PgSQLDb
127.0.0.1 5432 dspam wj30sh3hs32 dspam
Для других СУБД будут свои настройки, раскомментируйте соответствующие шаблоны и заполните нужные строки. Дополнительно потребуется выполнить ряд действий для создания необходимых таблиц, смотрите следующий раздел. Потребуется также указать правильный LDA (если вы планируете использовать подключение dspam в качестве агента доставки). Просто снимите комментарий с той строки, которая подходит для вашей системы: # Most operating system defaults: #TrustedDeliveryAgent "/usr/bin/procmail" # Linux #TrustedDeliveryAgent "/usr/bin/mail" # Solaris TrustedDeliveryAgent "/usr/libexec/mail.local" # FreeBSD
№8, август 2005
#TrustedDeliveryAgent "/usr/bin/procmail" # Cygwin # # Other popular conÞgurations: #TrustedDeliveryAgent "/usr/cyrus/bin/deliver" # Cyrus #TrustedDeliveryAgent "/bin/maildrop" # Maildrop #TrustedDeliveryAgent "/usr/local/sbin/exim ↵ -oMr spam-scanned" # Exim
Далее, в строках Trust перечислены пользователи, которым будет позволено управлять работой dspam. Допишите туда пользователя, от имени которого работает почтовый сервер, и пользователя dspam (если вы его добавляли), а заодно удалите лишних: Trust root #Trust mail #Trust mailnull Trust smmsp Trust daemon Trust dspam
# на моей системе от имени этого # пользователя работает sendmail
Режим обучения (TrainingMode), используемые алгоритмы и т. д. можно оставить по умолчанию. Если же вам захочется поэкспериментировать или работа с текущими настройками будет показывать неудовлетворительные результаты, в файле /usr/local/share/doc/dspam/README можно найти достаточно подробное описание доступных режимов (см. также раздел «Обучаем фильтр» далее в этой статье). Среди параметров Feature отметим два следующих: Featurechained Featurewhitelist
Первая включает поддержку «цепочек», когда учитываются не только отдельные слова, но и группы слов. С одной стороны, эта «фича» заметно повышает точность классификации писем, но с другой – способствует значительному росту базы данных. Второй строкой включается режим автоматического занесения отправителя в «белый» список – если число писем с одного и того же адреса превысит некоторое значение и ни одно из них не будет признано спамом, их отправитель заносится в «белый» список, и в дальнейшем сообщения от него не будут анализироваться. Группы строк Preference задают параметры по умолчанию: # 'quarantine' or 'tag' Preference "spamAction=quarantine" # 'message' or 'headers' Preference "signatureLocation=message" Preference "showFactors=off" Preference "spamSubject=SPAM"
Группа AllowOverride позволяет указать, какие из параметров могут быть переопределены личными настройками пользователя (для примера показаны лишь две строки): AllowOverridetrainingMode AllowOverride whitelistThreshold
Остальные параметры пока оставим без внимания. Те из них, которые важны для выбора желаемого режима работы, будут рассмотрены ниже, в соответствующих разделах. С остальными, вроде «SystemLog», думаю, вы без тру-
27
администрирование да разберетесь самостоятельно – файл достаточно хорошо прокомментирован.
Настраиваем СУБД для работы с DSPAM Примеры настройки взаимодействия с конкретной СУБД можно найти в соответствующих README-файлах. В данной статье рассмотрим работу с PostgreSQL. В /usr/local/share/examples/dspam/pgsql располагаются sql-файлы, содержащие необходимые для работы команды. Сейчас нас интересует файл pgsql_objects.sql, который поможет создать все нужные таблицы, индексы и т. д. Но базу данных и пользователя придется создать самостоятельно (хотя вы можете использовать и уже существующие). Последовательность нужных шагов представлена на следующем листинге: # cd /usr/local/share/examples/dspam/pgsql # psql -U pgsql template1
Наберите: \copyright для условий распространения \h для подсказки по SQL командам \? для подсказки по командам psql \g или наберите ";" для завершения запроса и его выполнения \q для выхода template1=# create user dspam nocreatedb nocreateuser password 'wj30sh3hs32'; CREATE USER template1=# create database dspam owner dspam; CREATE DATABASE template1=# \c dspam dspam Вы подсоединились к базе данных "dspam" как пользователь "dspam". dspam=> \! ls pgsql_objects.sql purge.sql virtual_users.sql dspam=> \i pgsql_objects.sql psql:pgsql_objects.sql:10: NOTICE: CREATE TABLE / UNIQUE создаст подразумеваемый индекс "dspam_token_data_token_key" для таблицы "dspam_token_data" CREATE TABLE CREATE INDEX CREATE INDEX CREATE INDEX CREATE INDEX psql:pgsql_objects.sql:24: NOTICE: CREATE TABLE / UNIQUE создаст подразумеваемый индекс "dspam_signature_data_signature_key" для таблицы "dspam_signature_data" CREATE TABLE psql:pgsql_objects.sql:36: NOTICE: CREATE TABLE / PRIMARY KEY создаст подразумеваемый индекс "dspam_stats_pkey" для таблицы "dspam_stats" CREATE TABLE psql:pgsql_objects.sql:44: NOTICE: CREATE TABLE / UNIQUE создаст подразумеваемый индекс "dspam_neural_data_node_key" для таблицы "dspam_neural_data" CREATE TABLE CREATE INDEX psql:pgsql_objects.sql:55: NOTICE: CREATE TABLE / UNIQUE создаст подразумеваемый индекс "dspam_neural_decisions_signature_key" для таблицы "dspam_neural_decisions" CREATE TABLE psql:pgsql_objects.sql:62: NOTICE: CREATE TABLE / UNIQUE создаст подразумеваемый индекс "dspam_preferences_preference_key" для таблицы "dspam_preferences" CREATE TABLE dspam=>
Здесь мы создали пользователя dspam и одноименную базу данных (должны соответствовать настройкам в dspam. conf). Затем выполнили команды из внешнего файла. Теперь осталось убедиться, что в файле pg_hga.conf содержатся разрешающие строки для локальных подключений к этой базе от имени соответствующего пользователя, например такие: USER
CIDR-ADDRESS
METHOD
# "local" is for Unix domain socket connections only local all all trust
28
127.0.0.1/32
trust
Все. База данных к работе готова.
Настраиваем DSPAM для работы как LDA В этом режиме почтовый сервер (MTA) конфигурируется таким образом, чтобы в качестве локального агента доставки выступал dspam. Способы «прикручивания» DSPAM к конкретному MTA подробно описываются в соответствующих документах: ! /usr/local/share/doc/dspam/courier.txt ! /usr/local/share/doc/dspam/exim.txt ! /usr/local/share/doc/dspam/postfix.txt ! /usr/local/share/doc/dspam/qmail.txt ! /usr/local/share/doc/dspam/sendmail.txt Например, для sendmail следует указать в mc-файле следующие строки:
Добро пожаловать в psql 8.0.2 - Интерактивный Терминал PostgreSQL.
# TYPE DATABASE
# IPv4 local connections: host all all
deÞne('LOCAL _ MAILER _ PATH', `/usr/local/bin/dspam')dnl deÞne('LOCAL _ MAILER _ ARGS', ↵ `dspam "--deliver=innocent,spam" --user $u -d %u')dnl
Они должны быть добавлены до строки «MAILER(local)». Здесь объявляется путь до агента доставки и его параметры запуска. Параметр --deliver указывает, что должны доставляться как «хорошие» письма (innocent), так и спам (spam). Чтобы на реальный LDA письма, признанные спамом, не передавались, удалите соответствующее упоминание из строки параметров. После компиляции нового конфигурационного файла и перезапуска почтового сервера все входящие сообщения будут поступать на вход dspam. Далее в зависимости от настроек и результата анализа полученные сообщения будут либо передаваться на реальный LDA для доставки в ящик пользователя, либо помещаться в карантин.
Настраиваем DSPAM в режиме POP3-proxy Одно из основных преимуществ работы в таком режиме заключается в независимости от конкретного MTA. Более того, почтовый сервер может вообще не располагаться на вашей машине. Например, ящики пользователей могут быть размещены на сервере провайдера, и если настроить получение почты через POP3-proxy, то защиту от спама вы можете реализовать на своем шлюзе без каких-либо изменений со стороны провайдера. Скачиваем последний архив с pop3filter.sourceforge.net (в портах он отсутствует): # tar –xvzf pop3Þlter-0.5.5.tar.gz # cd pop3Þlter-0.5.5 #./conÞgure # make
Вот здесь поджидала еще одна неприятность (вторая после отсутствия приложения в коллекции портов) – сборка окончилась ошибкой: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -pedantic -Wall -pedantic-errors -MT newopt.o -MD -MP -MF ".deps/newopt.Tpo" -c -o newopt.o `test -f 'newopt.c' || echo './'`newopt.c;
администрирование then mv -f ".deps/newopt.Tpo" ".deps/newopt.Po"; else rm -f ".deps/newopt.Tpo"; exit 1; fi newopt.c: In function `process': newopt.c:464: error: ISO C forbids conversion of object pointer to function pointer type newopt.c: At top level: newopt.c:146: warning: 'clone_argv' defined but not used *** Error code 1
Поверхностный анализ исходного кода показал, что проблемные строки (464 в файле newopt.c и еще несколько в main.c) используются только для обеспечения работы ключей --help и --version. Поскольку данными функциями вполне можно пренебречь, было принято решение о небольшом хирургическом вмешательстве в указанные два файла (показаны различия в исходном и полученном файлах): serg$ diff src/main.c.old src/main.c 117,126c117,123 < {/*00*/ {"help", OPT _ NORMAL, 0, ↵ OPT _ T _ FUNCT, (void *) help }, < /*01*/ {"h", OPT _ NORMAL, 1, ↵ OPT _ T _ FUNCT, (void *) help }, < /*02*/ {"version", OPT _ NORMAL, 0, ↵ OPT _ T _ FUNCT, (void *) version}, < /*03*/ {"V", OPT _ NORMAL, 1, ↵ OPT _ T _ FUNCT, (void *) version}, < /*04*/ {"fork", OPT _ NORMAL, 0, ↵ OPT _ T _ FLAG, NULL }, < /*05*/ {"f", OPT _ NORMAL, 1, ↵ OPT _ T _ FLAG, NULL }, < /*06*/ {"e", OPT _ NORMAL, 1, ↵ OPT _ T _ GENER, NULL }, < /*07*/ {"listen", OPT _ NORMAL, 0, ↵ OPT _ T _ GENER, NULL }, < /*08*/ {"user", OPT _ NORMAL, 0, ↵ OPT _ T _ GENER, NULL }, < /*09*/ {"group", OPT _ NORMAL, 0, ↵ OPT _ T _ GENER, NULL }, --> { > /*04-0*/ {"fork", OPT _ NORMAL, 0, ↵ OPT _ T _ FLAG, NULL }, > /*05-1*/ {"f", OPT _ NORMAL, 1, ↵ OPT _ T _ FLAG, NULL }, > /*06-2*/ {"e", OPT _ NORMAL, 1, ↵ OPT _ T _ GENER, NULL }, > /*07-3*/ {"listen", OPT _ NORMAL, 0, ↵ OPT _ T _ GENER, NULL }, > /*08-4*/ {"user", OPT _ NORMAL, 0, ↵ OPT _ T _ GENER, NULL }, > /*09-5*/ {"group", OPT _ NORMAL, 0, ↵ OPT _ T _ GENER, NULL }, 128,132c125,129 < }; lopt[4].data = lopt[5].data = ↵ (void *) &(opt->fork); < lopt[6].data = (void *) &(opt->fstderr); < lopt[7].data = &(opt->listen _ addr); < lopt[8].data = &(opt->username); < lopt[9].data = &(opt->groupname); --> }; lopt[0].data = lopt[1].data = ↵ (void *) &(opt->fork); > lopt[2].data = (void *) &(opt->fstderr); > lopt[3].data = &(opt->listen _ addr); > lopt[4].data = &(opt->username); > lopt[5].data = &(opt->groupname); serg$ diff lib/newopt.c.old lib/newopt.c 463,465c463,465 < case OPT _ T _ FUNCT: < (*(callbackT)table->data); < break; --> /* case OPT _ T _ FUNCT: > (*table->data);
То есть были удалены или закомментированы строки, в которых упоминается OPT_T_FUNC, и соответственно исправлены индексы массива, используемые в дальнейшем. После этой «операции» сборка прошла успешно, а вслед за ней и установка:
№8, август 2005
# make install
Запуск pop3filter можно выполнить такой командой: # pop3Þlter --fork 127.0.0.1 110 7110 ↵ "dspam --user \$pop3 _ USERNAME ↵ --stdout --deliver=innocement,spam "
В данном случае входящие соединения будут ожидаться на порту 7110 и передаваться на 110-й порт localhost. Полученные от реального pop3-сервера сообщения будут отдаваться на обработку фильтру dspam, после чего передаваться пользователю в зависимости от настроек и результата классификации. Правда, должен признаться, что добиться устойчивой работы в этом режиме мне не удалось. Довольно часто после обработки одного – двух сообщений что-то где-то подвисало, и почтовый клиент при попытке скачать очередную порцию почты «отваливался» по истечении тайм-аута. Возможно, кому-то из вас повезет больше.
Запуск DSPAM в режиме демона По умолчанию dspam запускается как автономная программа. Однако при интенсивной нагрузке в этом случае тратится много ресурсов на такие операции, как установка соединения с СУБД. Более эффективным выглядит запуск в режиме демона, когда серверный процесс dspam находится в памяти, поддерживая несколько постоянных соединений с СУБД. Для обработки же пользовательских соединений dspam запускается как клиент, общающийся с сервером либо по протоколу LMTP, либо через UNIX-socket. Для работы в режиме демона нужно настроить параметры сервера и клиента в конфигурационном файле. Возможны два режима работы – через локальные сокеты UNIX либо по протоколу LMTP (используется 24-й TCP-порт). Для первого случая внесите в конфигурацию следующие строки: ServerDomainSocketPath "/var/run/dspam.sock" ClientHost "/var/run/dspam.sock"
Естественно, пути к сокету для клиента и сервера должны совпадать. Если вы собираетесь использовать LMTP (например, когда клиент и сервер находятся на разных машинах), то раскомментируйте и настройте следующие параметры: #ServerPort 24 #ServerPass.Relay1 "secret" #ServerPass.Relay2 "password" #ClientHost 127.0.0.1 #ClientPort 24 #ClientIdent "secret@Relay1"
Строки Server* должны присутствовать в конфигурационном файле сервера, Client* – соответственно клиента. Заметьте, что если хотя бы одна строка ServerPass.RelayX будет раскомментирована, то dspam запустится для работы по 24-му порту, даже если присутствуют строки, задающие UNIX-сокеты. Далее установите в файле /etc/rc.conf переменную dspam_ enable в «YES», что обеспечит автоматический запуск демона с помощью сценария /usr/local/etc/rc.d/dspam.sh. Этот скрипт добавляется автоматически при установке из портов, вам останется лишь проконтролировать его наличие и «исполняемость».
29
администрирование Теперь, чтобы сервером электронной почты или pop3фильтром программа dspam запускалась как клиент, укажите в соответствующих строках вызова дополнительный ключ --client либо используйте вместо dspam бинарник dspamc, специально предназначенный для работы в режиме клиента. Если теперь выполнить следующую команду, то можно наблюдать основной процесс dspam и несколько процессов для связи с базой данных (рекомендуется использовать MySQL или PostgreSQL): # ps -ax |grep dspam 4843 4844 4845 4842
?? ?? ?? p0
I I I S
0:00,03 0:00,12 0:00,03 0:00,25
postmaster: dspam dspam 127.0.0.1(63076) idle (postgr postmaster: dspam dspam 127.0.0.1(58646) idle (postgr postmaster: dspam dspam 127.0.0.1(54366) idle (postgr /usr/local/bin/dspam -daemon
В результате, благодаря постоянным подключениям к СУБД, нагрузка на систему несколько снижается.
Подключаем CGI-модуль Этот модуль позволяет пользователям работать со своими настройками, получать статистические данные о работе фильтра, а также просматривать сообщения, помещенные в карантин, и при необходимости инициировать переобучение. В процессе инсталляции необходимые для работы модуля файлы будут помещены в /usr/local/www/vhosts/ dspam. Поскольку пользователь, от имени которого будут исполняться данные cgi-скрипты, должен иметь доступ и к иерархии файлов в /var/db/dspam, нужно либо дать соответствующие разрешения на домашний каталог dspam, либо запускать веб-сервер от имени пользователя, имеющего необходимые привилегии. Наиболее удобным мне показалось запустить для организации веб-интерфейса отдельный виртуальный хост от имени пользователя dspam. Для этого Apache должен быть собран с поддержкой suexec. Проверить выполнение данного требования можно таким образом: # /usr/local/sbin/httpd -l ... mod_setenvif.c mod_ssl.c suexec: enabled; valid wrapper /usr/local/sbin/suexec
В дальнейшем конфигурируем Apache следующим образом (естественно, далеко не единственным): NameVirtualHost 10.10.10.80 <VirtualHost 10.10.10.80> ServerName dspam.test.ru DocumentRoot /usr/local/www/vhosts/dspam User dspam Group dspam <Directory "/usr/local/www/vhosts/dspam"> Options Indexes FollowSymLinks ExecCGI AllowOverride All Order allow,deny Allow from all DirectoryIndex index.html AddHandler cgi-script .cgi <IfModule mod _ perl.c> PerlSendHeader On AddHandler perl-script .cgi PerlHandler Apache::Registry </IfModule> </Directory> </VirtualHost>
30
Домашним каталогом виртуального хоста оставляем /usr/ local/www/vhosts/dspam, при этом suexec должен быть собран таким образом, чтобы директория dspam находилась внутри директории, определенной как suexec_docroot (задается при компиляции Apache с помощью переменной APACHE_ SUEXEC_DOCROOT либо правкой Makefile). Далее, для работы suexec требуется, чтобы права на каталог dspam и размещенные в нем скрипты принадлежали пользователю и группе dspam, от имени которого будет работать наш виртуальный хост. Именно несоответствие прав является наиболее частой причиной ошибок при работе с suexec (которые можно будет найти в файле /var/log/httpdsuexec.log, если вы не меняли соответствующий параметр при компиляции). Помимо прав на CGI-сценарии, должны быть доступны и файлы, размещаемые в домашнем каталоге dspam (по умолчанию /var/db/dspam). Именно для этой цели пользователь dspam и был объявлен владельцем домашнего каталога. Если что-то не будет работать через веб-интерфейс, в первую очередь следует проверять именно наличие необходимых прав на файлах «проблемного» пользователя. Обратите внимание, что CGI-модуль не может быть использован, если данные пользователей хранятся в их домашних каталогах (был установлен параметр USER_ HOMEDIR). Конечно, запустив виртуальный хост с правами суперпользователя, можно разом решить все возможные проблемы доступа, но вряд ли в здравом уме можно пойти на подобный шаг. Использование веб-интерфейса позволяет существенно упростить настройку параметров работы фильтра. Кроме того, поскольку каждый пользователь может самостоятельно осуществлять большинство контрольно-управляющих действий, то в итоге нагрузка на администратора существенно снижается (правда, повышается нагрузка на сервер, особенно при интенсивном использовании графиков). Для доступа к веб-интерфейсу пользователь должен пройти аутентификацию (используется Basic-аутентификация, по умолчанию проверка выполняется в файле паролей /usr/local/etc/apache/passwd, но вы можете перенастроить это в файле .htaccess). В зависимости от введенного имени (используется переменная $REMOTE_USER) становится доступным интерфейс пользователя или администратора. Роль администратора может выполнять любой аутентифицированный пользователь, имя которого присутствует в файле admins (здесь и далее речь идет о файлах, расположенных в каталоге виртуального хоста, в моем случае это /usr/local/www/vhosts/dspam). Веб-интерфейс сценариев англоязычный, но, приложив минимум усилий, его несложно перевести на русский язык, заодно добавив некоторые пояснения от себя в целях сокращения числа вопросов. На сайте журнала в разделе «Исходный код» можно будет найти архив с моим переводом. Пользователь может просматривать только свою статистику (рис. 2), выполнять некоторые настройки, если в конфигурационном файле не запрещено их переопределять (рис. 3), работать с историей сообщений (рис. 4), просматривать сообщения, помещенные в карантин (рис. 5), в частности, инициировать переобучение в случае ошибки. Так-
администрирование
Рисунок 2. Страница статистики пользователя
Рисунок 4. Страница истории
же можно полюбоваться графическим отображением статистики за последний период времени (рис. 6), наглядно демонстрирующим эффективность работы фильтра. Администратор, кроме того что может работать в интерфейсе любого пользователя, имеет доступ также к общим настройкам, которые применяются, если пользователь не определит собственные. Кроме того, ему предоставляется графическая статистика работы фильтра в целом по серверу (рис. 7). Поскольку по умолчанию доступ возможен ко всем файлам, расположенным в каталоге виртуального хоста (например, можно получить содержимое файла admins), имеет смысл несколько ужесточить требования, внеся дополнительные настройки в .htaccess. Естественно, чтобы они имели силу, конфигурация Apache должна позволять переопределение базовых настроек; также можно указать эти строки непосредственно в httpd.conf в секции VirtualHost: # cat /usr/local/www/vhosts/dspam/.htaccess AuthName dspam.test.ru AuthType Basic AuthUserFile /usr/local/etc/apache/passwd <Limit GET POST> require valid-user
№8, август 2005
Рисунок 3. Страница персональных настроек
Рисунок 5. Страница карантина </Limit> <FilesMatch "(cgi|css|gif|html)$"> order deny,allow allow from all </FilesMatch> order deny,allow deny from all
Для еще большей безопасности вместо «allow from all» для соответствующих расширений можно задать ограниченный список разрешенных адресов.
Обучаем фильтр Процесс обучения играет чрезвычайно важную роль для правильной работы фильтра. Чтобы dspam знал, какие письма являются спамом, требуется дать ему на обработку примеры подобных сообщений, а также образцы нормальных писем. Если у вас есть архив спамерских писем (допустим, вы сбрасываете такие сообщения в отдельную папку), то эти сообщения могут быть переданы для обучения, используя следующую команду: # dspam _ corpus --addspam sergei ↵ /var/db/dspam/data/gorod/gorod.mbox command: '/usr/local/bin/dspam' --class=spam ↵
31
администрирование
Рисунок 6. Графики активности --source=corpus --user 'sergei' --mode=teft ↵ --feature=chained,noise /usr/local/bin/dspam _ corpus: 3 messages, ↵ 00:00:57 elapsed, 0.05 msgs./sec.
В данном примере я обучил фильтр для sergei на основе спама, собранного в карантине пользователя gorod. Обучение «хорошими» сообщениями выполняется аналогично, но без ключа -addspam. Для получения адекватных результатов при обучении необходимо соблюдать баланс между «хорошими» сообщениями и спамом, в идеале их количество должно быть (примерно) одинаково. Также по умолчанию dspam настраивается на постоянное обучение в процессе работы (режим TEFT). То есть им обрабатываются все входящие сообщения, и значения спамности для каждого встречающегося в них слова пересчитываются в БД. Это увеличивает нагрузку на систему, но позволяет быстро реагировать на изменение характера рассылок. Если режим TEFT для вас не приемлем из-за слишком высокой нагрузки, можно использовать другие (параметр TrainingMode конфигурационного файла или ключ запуска): ! TOE: обучение выполняется только в том случае, если фильтр допускает ошибку. ! TUM: фильтр обучается на каждом сообщении, пока не будет достигнуто определенное число повторений токена, затем переходит в режим обучения по ошибке. ! NOTRAIN: обучение не проводится. Возникает вопрос: а как фильтр узнает, что он ошибся? Конечно, об этом ему должен сообщить пользователь. Для обратной связи предусмотрено два механизма – с помощью CGI-сценариев и путем пересылки сообщений на специальный адрес. В первом случае пользователь имеет возможность в списке своей истории щелчком мыши инициировать переобучение для сообщений, которые, по его мнению, были обработаны ошибочно (используя ссылки «Retrain as Spam» и «Retrain as Innocent» соответственно). Также переобучение происходит, если пользователь возвращает сообщение из карантина. Для реализации второго механизма обучения в файле
32
Рисунок 7. Страница администратора
/etc/mail/aliases должны быть созданы псевдонимы следующего вида: # DSPAM aliases spam-gorod: "|/usr/local/bin/dspam --user gorod ↵ --class=spam --source=error"
Имя псевдонима в принципе может быть любым (роль играет значение ключа --user при вызове dspam), но рекомендуется формировать его как spam-<имя_пользователя>. Теперь, если пользователь перенаправит спам, который попал в его ящик, на этот адрес будет инициировано переобучение. Нужно сказать, что каждое обработанное письмо помечается сигнатурой вида «!DSPAM:42df44f092281550917839!», которая обычно добавляется в тело сообщения. Когда письмо перенаправляется для исправления ошибки, dspam ищет в нем эту сигнатуру и «откатывает» те изменения в базе, которые были сделаны во время первоначальной обработки этого сообщения. Вспомогательная утилита dspam_genaliases автоматически формирует список псевдонимов на основе файла /etc/passwd.
Несколько слов о «вакцинации» Это хорошо, что пользователь может самостоятельно обучать фильтр. Благодаря этому число ложных срабатываний снижается до минимума. Но, с другой стороны, одно и то же сообщение, впервые попавшее в почтовый ящик, каждый пользователь должен обработать лично. Для преодоления этого неудобства DSPAM поддерживает так называемую «вакцинацию». Суть ее заключается в том, что в настройки почтового сервера добавляется еще один псевдоним (или несколько), которые перенаправляются на dspam в режиме прививки: inoc-gorod: "|/usr/local/bin/dspam --user gorod ↵ --class=spam --source=inoculation"
Далее этот псевдо-адрес можно «засветить» на различных досках объявлений, форумах и т. д. с тем, чтобы он попал по возможности в большее число спамерских баз. Так же можно попросить своих друзей пересылать на этот ад-
администрирование рес спам, который получают они. В результате dspam сможет обработать большее число нежелательной почты и эффективнее реагировать, когда подобные письма будут поступать на реальные ящики пользователей. Чтобы не заводить отдельные адреса-ловушки для каждого пользователя, используются группы, о которых пойдет речь в следующем разделе.
Группы Чтобы придать работе с пользователями большую гибкость, а также «обобществлять» информацию о спаме, накопленную отдельными пользователями, в системе DSPAM имеется поддержка групп. Также группы используются и для реализации идеи «вакцинации». Фильтром поддерживаются следующие типы групп: ! Shared: пользователи, входящие в shared-группу, работают каждый со своим карантином, но используют общую базу токенов. Для однотипных пользователей эффективность повышается за счет снижения размера базы и ее более быстрой наполняемости. С другой стороны, если характер корреспонденции отдельного пользователя отличается от среднего по группе, возрастает вероятность ложных срабатываний. ! Inoculation: включение пользователя в одну из таких групп позволяет ему получать информацию из «прививок», обработанных любым из членов группы. Таким образом, описанный в предыдущем разделе псевдо-адрес можно сопоставить с одним из пользователей inoculation-группы, чтобы она оказывала влияние на всех остальных. ! Classification: члены такой группы практически независимы, но если у фильтра возникают сомнения при классификации какого-то сообщения, то он сможет воспользоваться данными остальных членов группы для принятия окончательного решения. ! Global: такая группа позволяет создавать так называемых глобальных пользователей. Любой новый пользователь сможет использовать данные, размещенные в пространстве глобального пользователя, пока не накопит достаточную для самостоятельной работы базу. ! Merged: пользователи, входящие в такую группу, получают возможность добавлять в процессе анализа к своим данным информацию из пространства глобального пользователя (описанного в группе Global). При этом имя merged-группы должно совпадать с именем используемого глобального пользователя. Для того чтобы включить пользователя в ту или иную группу, используется файл /var/db/dspam/group: group1:shared:user1,user2,user3 group2:inoculation:user4,user5,user6
Существуют ограничения на вхождения одного и того же пользователя в разные группы. Подробную информацию можно получить из уже упоминавшегося файла README.
Вспомогательные утилиты В состав пакета DSPAM входит ряд служебных утилит, назначение которых – выполнение ряда сервисных функций:
№8, август 2005
! dspam_admin: данная утилита предназначена для уп-
равления персональными настройками пользователей или общими настройками dspam. Синтаксис команды можно посмотреть, введя ее без аргументов:
# dspam _ admin syntax: dspam_admin [function] [arguments] [--profile=PROFILE] add preference [user] [attrib] [value] change preference [user] [attrib] [value] delete preference [user] [attrib] [value] list preference [user] [attrib] [value] aggregate preference [user]
Например, так можно отключить использование автоматически заполняемого «белого» списка для пользователя gorod: # dspam _ admin change preference gorod enableWhitelist off
Файл с настройками будет размещаться в директории dspam в подкаталоге, соответствующем пользователю – /var/db/dspam/data/gorod, в СУБД либо в домашнем каталоге пользователя. Это можно настроить в процессе инсталляции фильтра (см. выше). ! dspam_clean: выполняет очистку базы. В процессе работы база маркеров может достигать значительных размеров. Очистка служит для того, чтобы удалить бесполезные (или малополезные) записи. В частности, могут быть удалены токены, коэффициент спамности которых близок к 0,5, то есть нейтральные слова, а также устаревшие сигнатуры (которые фильтр хранит на случай переобучения). Очистка служит не только для оптимизации размера БД, но и для поддержания ее в актуальном состоянии: удаление устаревших токенов позволяет более точно реагировать на изменение характера рассылки. Например, для удаления сигнатур старше 7 дней для всех пользователей служит команда: # dspam _ clean –s7
Удаление всех (в том числе и самых последних) нейтральных токенов из пространства пользователя gorod: # dspam _ clean –p0 gorod
Подробности по использованию утилиты см. на страницах man dspam_cleanup. Говоря об очистке базы, следует также упомянуть удаление малоэффективных и устаревших данных силами СУБД. Например, для PostgreSQL cоответствующий sqlфайл можно найти в /usr/local/share/examples/dspam/pgsql под именем purge.sql. Для регулярного автоматического запуска процедур очистки можно использовать crontab. ! dspam_stats: выводит статистику работы dspam по всем или указанным пользователям (количество спама, «хороших» писем, ошибок): # dspam _ stats serg gorod alex
33
администрирование serg gorod alex
TS: TS: TS:
0 TI: 1 TI: 0 TI:
12 SM: 44 SM: 20 SM:
0 IM: 11 IM: 0 IM:
0 SC: 0 SC: 0 SC:
0 IC: 0 IC: 0 IC:
0 0 0
С ключом -H утилита выдает более «читабельную» информацию: # dspam _ stats -H gorod gorod: TS TI SM IM SC IC TL SR IR OR
Total Spam: 1 Total Innocent: 44 Spam Misclassified: 11 Innocent Misclassified: 0 Spam Corpusfed: 0 Innocent Corpusfed: 0 Training Left: 2456 Spam Catch Rate: 8.33% Innocent Catch Rate: 100.00% Overall Rate/Accuracy: 80.36%
! dspam_corpus: данная утилита позволяет указать филь-
тру файл в формате mbox, содержимое которого следует «изучить». Будучи выполненной без дополнительных аргументов, команда выведет на экран подсказку по синтаксису. Также имеется man-страница. ! dspam_genaliases: с помощью этой команды можно автоматически добавить в файл /etc/mail/aliases нужные псевдонимы, для генерации которых используется список пользователей из файла /etc/passwd. ! dspam_logrotate: лог-файлы имеют привычку разрастаться до немыслимых размеров. С помощью этой утилиты, помещенной в crontab, можно организовать периодическую очистку логов, скажем, таким образом (пример из README): 0 0 * * * dspam _ logrotate -a 30 /var/db/dspam/system.log ↵ `Þnd /var/db/dspam/data -name "*.log"`
Преимущества этого способа перед другими способами ротации (например, newsyslog) в том, что можно обработать сразу все лог-файлы. В приведенном выше примере с помощью find формируется список всех файлов с расширением log, найденных в каталоге data и его подкаталогах. Ключ -а задает возраст файлов в днях, которые должны быть подвержены очистке. ! dspam_merge: данная команда объединяет метаданные нескольких пользователей, имена которых задаются как аргументы командной строки, и сохраняет их в пространство другого пользователя, заданного ключом –o. Частное применение утилиты – формирование «стартового» наполнения для вновь создаваемого пользователя на основе некоторого существующего, уже прошедшего «цикл обучения». Подробности см. в man dspam_merge. ! dspam_dump: выводит на экран токены и характеризующие их значения для указанного пользователя: # dspam _ dump gorod 2382717757724374224 S: 00007 I: 00000 P: 0.9998 LH: Wed Jul 27 00:00:00 2005 2180264270330443047 S: 00004 I: 00000 P: 0.4000 LH: Mon Jul 25 00:00:00 2005 4180468462601491382 S: 00004 I: 00000 P: 0.4000 LH: Mon Jul 25 00:00:00 2005 .. .. .. ..
Здесь в первом поле отображается токен в цифровой форме (см. dspam_crc в этом разделе) и далее: S – количество спама, I – количество хороших писем, P – «коэффи-
34
циент спамности» (вероятность того, что следующее письмо с данным словом будет спамом), LH – время последнего появления данного слова во входящих сообщениях. Вопреки своему названию, наводящему на мысль о резервном копировании, dspam_dump используется только для анализа работы фильтра. ! dspam_2sql: формирует SQL-команды, которые могут быть использованы для заполнения таблиц данными практически в любой СУБД: # dspam _ 2sql insert into dspam_token_data (uid, token, spam_hits, innocent_hits, last_hit) values(1002, "16628239873585525635", 0, 3, 1121889600); insert into dspam_token_data (uid, token, spam_hits, innocent_hits, last_hit) values(1002, "3386138115020307445", 0, 3, 1121889600); .. .. .. ..
Может использоваться при переносе данных на другую систему управления БД для резервного копирования (хотя и гораздо менее эффективного, чем силами самой СУБД) и т. д. ! dspam_crc: эта служебная программа рассчитывает цифровой «отпечаток» для того или иного слова (как оно будет храниться в базе): # dspam _ crc "viagra" TOKEN: 'viagra' CRC: 6625426497525293056
Помимо удовлетворения любопытства, данная утилита может быть полезной, например, при автоматизированной обработке содержимого базы данных.
Итоги Система DSPAM, конечно, не уменьшает почтовый трафик (все сообщения принимаются полностью), но зато существенно упрощает жизнь конечному пользователю, выполняя за него работу по сортировке входящей корреспонденции на спам и легальную почту. Благодаря персонифицированному подходу к обучению пользователь практически не зависит от предпочтений системного администратора, обслуживающего систему, самостоятельно формируя правила фильтрации. С другой стороны, DSPAM не относится к системам типа «поставил – и спи». Прежде чем будет заметен положительный эффект от внедрения, как от администратора, так и от пользователей потребуется приложить немало усилий по обучению системы. Но, на мой взгляд, оно того стоит.
Дополнительная информация: 1. Супрунов С. Запускаем spamd на FreeBSD. – Журнал «Системный админстратор», №7, 2005 г. – 14-19 с. 2. http://dspam.nuclearelephant.com – домашняя страница проекта DSPAM. 3. http://www.paulgraham.com/spam.html – «A Plan for Spam» by Paul Graham. 4. http://www.paulgraham.com/better.html – «Better Bayesian Filtering» by Paul Graham. 5. http://radio.weblogs.com/0101454/stories/2002/09/16/ spamDetection.html – «Spam Detection» by Gary Robinson. 6. http://linuxjournal.com/article/6467 – «A Statistical Approach to the Spam Problem» by Gary Robinson.
администрирование
WrSpy – СЧИТАЕМ И КОНТРОЛИРУЕМ ТРАФИК ПОЧТОВЫХ И ПРОКСИПРОКСИ-СЕРВЕРОВ СЕРВЕРОВ
РОМАН МАРКОВ Тема контроля за интернет-трафиком пользователей не теряет своей актуальности. Различные решения этой задачи неоднократно описывались, но всегда приятнее выбирать из множества решений, нежели без вариантов использовать что-то единственное. Сегодня вы познакомитесь с WrSpy – продуктом, который я сам активно применяю уже несколько лет.
Н
емного истории. Название этого лог-анализатора пошло от популярного продукта для Windows – Kerio WinRoute Pro, несмотря на то что сейчас данный продукт распознает форматы логов почти всех популярных прокси- и почтовых серверов. Причина в том, что сначала WrSpy был написан его автором «исключительно для собственной сети». Начало развития было положено около трех лет назад на одной из интернет-конференций, посвященной администрированию локальных сетей. Аркадий Патрушев – системный администратор и программист из Новосибирска, известный в сети под псевдонимом Walker, на очередной вопрос в стиле: «Как считать трафик?» – предложил всем желающим свою программу, честно предупредив, она что «жутко сырая» и была написана для себя. Я также использовал встроенный прокси-сервер WinRoute 4 Pro, и поэтому попросил выслать и мне данный
36
анализатор. В процессе попыток внедрить данную систему у себя выявилось много неточностей и недоработок, которые автор программы оперативно устранял по нашим советам. В результате такой совместной работы продукт «отполировали», добавили возможность анализа лог-файлов других популярных серверов, прибавив при этом целый букет новых функций. Программа абсолютно бесплатна, за это огромная благодарность Аркадию Патрушеву. Итак, начнем с традиционного описания возможностей. Программа предназначена для анализа логов и формирования разнообразных отчетов как в автоматическом (пакетном), так и в интерактивном режиме. Именно изначальное наличие пакетного режима и, разумеется, бесплатность сделало программу столь привлекательной, вытеснив уже существовавшие на тот момент аналогичные Windows-системы. Однажды настроив систему импорта и анализа логов
администрирование и прописав в планировщике задач автоматический запуск администратор получал систему класса «настроил и забыл». Помимо этого, автор использовал, казалось бы, простой, но остроумный способ блокировки доступа пользователей, превысивших персональный лимит. Автоматически корректируя необходимые настройки программы в реестре, WrSpy переносил пользователя в другую группу безопасности, не имеющую никаких прав. Позднее при развитии продукта этот же принцип лег в основу блокировки пользователей в Squid-NT. Кстати, несмотря на то, что WrSpy работает под управлением ОС Windows, поддерживается анализ лог-файлов популярных прокси- и почтовых серверов для UNIX-систем. В данный момент WrSpy и утилиты поддерживают анализ лог-файлов следующих систем. Proxy-серверы: WinRoute 4 Pro, Kerio WinRoute Firewall 5, Kerio WinRoute Firewall 6, Kerio Network Monitor, BSB, UserGate, Squid NT, Squid OS/2, WinGate, ISA, ExtraSystems Proxy Server, WinProxy CZ, WinProxy, ISA2004. Почтовые серверы: WinRoute, MDaemon, Kerio Mail Server, CommuniGate Pro, Postfix, SendMail, Weasel, WinProxy CZ и POPCon. Помимо этого, на сайте программы имеется большое количество отдельных утилит. Отдельные анализаторы для: MDaemon, Kerio Mail Server, Kerio Network Monitor, Serv-U, Apache, IIS.
Системные требования Работа программы основана на анализе файлов формата plain-text, что накладывает определенные требования к производительности дисковой системы, процессорной мощности и количеству памяти. Однако никаких минимальных требований нет, поскольку работоспособной окажется практически любая система. С другой стороны, для получения определенной скорости обработки лучше все-таки обеспечить разумный минимум. Тут все зависит от размера лог-файлов (соответственно – активности пользователей) и необходимой частоты обновления статистики. Если размер анализируемых файлов не превышает 10-100 Мб в месяц, а статистику достаточно обновлять один-два раза в сутки, когда отсутствует активность пользователей, – с поставленной задачей справится абсолютно любой компьютер, на котором работают поддерживаемые программные продукты. При большом количестве пользователей, приросте размера лог-файлов до 1-2 Гб в месяц, рекомендуется реже обновлять статистику – 1-2 раза в сутки. При необходимости более частого переиндексирования размещайте лог-файлы и формируемые отчеты на быстрых дисках SATA или SCSI. Рекомендуется также озаботиться созданием ежедневных копий информации, находящейся на таком диске. Личный пример: для обновления статистики для 100 пользователей прокси-сервера Kerio WinRoute 4 Pro и 250 почтовых ящиков Alt-N Mdaemon с интервалом один раз в час я использую компьютер следующей конфигурации: Intel Celeron 1.3 ГГц, 256 Мб RAM, 2 SATA HDD 40 Гб, SATA-RAID-1, OS Windows 2000 Server. При наличии неоспоримых достоинств этой программы, таких как подробнейшие отчеты (вплоть до того, какой именно файл скачал конкретный пользователь с оп-
№8, август 2005
ределенного ресурса), нельзя не заметить, что, пожалуй, единственным недостатком WrSpy является именно большая нагрузка на дисковую систему. Однако глубокий анализ plain-text файлов с накоплением статистики всегда подразумевает это.
Установка Рассмотрим пример настройки системы. Для написания данной статьи я использовал связку Kerio WinRoute Firewall 6 и Alt-N Mdaemon 8, установленные на OS Windows Server 2003. Принцип настройки взаимодействия c другими поддерживаемыми ПП аналогичен. Если есть какие-либо особенности (например, настройка блокировки пользователей в Squid или Kerio WinRoute Pro 4), то они подробно описаны на официальном сайте WrSpy. Скачиваем дистрибутив (WrSpySetup.rar) и последнее обновление (WrSpyUpXXX.rar – где XXX номер версии) с официального сайта программы (ссылки приведены в конце статьи). Распаковываем архивы, устанавливаем основной дистрибутив. Обратите внимание на предупреждение: «Будьте особенно внимательны, если в системе уже установлен Visual FoxPro 6.0 (VFP6.0) или приложения, созданные с его использованием. Возможно нарушение их функционирования». Если при запуске обнаружится сообщение: «Несовпадение версии файла ресурсов», то скорее всего в системе установлен VFP6.0 или программа, из-под него писанная, с несовпадающей версией обновления. Чтобы обойти данную ошибку, необходимо использовать режим полной установки поверх существующей версии VFP. Выполняем стандартные действия, отвечая на вопросы инсталлятора о варианте установки и местоположении файлов (рекомендуется устанавливать WrSpy на быстрые дисковые системы, как рекомендовалось выше). В конце установки отказываемся от запуска WrSpy (снимаем соответствующий флажок). Вы можете прочитать файл Readme. txt (нажатием кнопки после завершения установки). В нем кратко описываются принципы настройки, которые я рассмотрю более подробно. Сразу после установки основного дистрибутива обновляем его до последней версии, запустив файл обновления. Внимательно проверьте путь для установки, так как инсталлятор не проверяет, куда именно был установлен WrSpy. Это сделано не случайно, так как иногда требуется произвести несколько установок с разными настройками на один компьютер (например, для анализа архивных лог-файлов, не прерывая работу основной системы анализа). После установки обновления соглашаемся с предложением инсталлятора запустить WrSpy (либо запускаем вручную файл WrSpy.exe). Запустится интерактивная первоначальная настройка (рис. 1). Выбираем используемые нами прокси- и почтовый серверы, задаем параметры сети (подсеть и маску). Создаем на диске папку для отчетов (именно в нее будут помещаться формируемые программой результаты) и указываем путь к ней. Затем указываем пути к лог-файлам, а также почтовые домены. Если какой-то из лог-файлов (почтовый или прокси) анализироваться не должен – оставляем соответствующее поле пустым. Переходим к следующему экрану настроек (рис. 2).
37
администрирование ! Суммарный почтовый – входящий и исходящий почтовый трафик.
! Входящий почтовый – только входящий с детализацией по ящикам.
! Исходящий почтовый – только исходящий по почтовым
!
! Рисунок 1. Список поддерживаемых продуктов
! ! !
ящикам (можно отключить, в противном случае в отчет попадут адреса получателей, которых может быть очень много). Стоимость – рассчитанная стоимость потраченного трафика, исходя из заданной стоимости 1 Мб. Внимание! Не задавайте стоимость трафика равной нулю, так как все внутренние расчеты программа ведет не в мегабайтах, а именно по итоговой стоимости. Если стоимость непринципиальна – лучше просто скрыть эту графу из раздела сводного отчета. Дата и время в имени – при включении этой опции WrSpy будет формировать отчеты с разными именами файлов, накапливая историю изменений. Я не использую этот режим в ежечасной статистике – он полезен только для формирования и архивации ежемесячного отчета. Учитывать служебный – при установке данного переключателя будет подсчитан не только «полезный» трафик, но и зарегистрированные служебные пакеты. Почтовый бесплатно – почтовый трафик не будет учитываться для ограничения трафика. Лимит по умолчанию – каждый новый пользователь автоматически получит заданную квоту на период расчета (на месяц, неделю, день или ручной интервал). Разделы сводного отчета:
! Открывать при создании – при установленном переклю-
Рисунок 2. Настройка вида отчета
Обычно наибольшие трудности возникают при настройке именно этих параметров. Для краткости скажу, что обычно использую настройки, приведенные на рис. 2. Поясню функции каждого переключателя: Глубина анализа: ! Отчет по пользователям – анализ будет осуществляться по имени пользователя прокси-сервера. ! Отчет по станциям – учет по IP-адресам (DNS-именам) станций независимо от имен пользователей прокси-сервера. ! Отчет по почте – при анализе также будут учитываться лог-файлы почтового сервера. ! Отчет по группам – разделение пользователей по группам (например, по отделам). Графы сводного отчета: ! Группа – выводится статистика по заданным группам. ! Суммарный входящий – весь входящий трафик (прокси и почтовый). ! Суммарный прокси – суммарный трафик прокси-сервера.
38
чателе в интерактивном режиме после создания отчет автоматически будет открыт. ! Сортировка по трафику – в HTML-отчете список пользователей будет выводиться в соответствии с использованным трафиком – первыми будут идти «рекордсмены». ! Выделение цветом – наглядное отображение о приближении к персональному лимиту – от белого к красному. Синий цвет графы пользователя означает, что персональный лимит превышен и пользователь отключен. ! Трафик по дням – при установке данной опции для каждого пользователя будет формироваться и сохраняться в персональной папке дополнительный ежедневный отчет (что, разумеется, увеличит нагрузку на систему). Формировать с головным – интеграция дополнительных отчетов с основным: ! Сайты по пользователям – для ежечасного автоматического режима формирования отчетов рекомендуется включить только эту опцию – детализация трафика пользователя по посещенным ресурсам. Остальные возможности используются не так часто, поэтому для снятия нагрузки с системы их можно формировать только при необходимости в интерактивном режиме. Например, очень интересен отчет «Бюджет времени», позволяющий получить общую картину активности пользователя в разрезе временного интервала. Данный режим не предназначен для временной тарификации – он всего лишь по-
администрирование казывает приблизительные графики активности и относительно время, проведенное в сети. Для того чтобы понять, чем занят сотрудник (если, конечно, серфинг по сайтам – не его прямые обязанности), – этого вполне достаточно. В следующем окне настроек задаем параметры режимов анализа, а также рабочий интервал (рис. 3). Минимально необходимо настроить два режима – интерактивный и автоматический. Автоматических режимов существует несколько. Каждый из них можно настроить в соответствии со своими задачами – например, добавить дополнительный режим для формирования и сохранения ежемесячного отчета, так как после начала нового рабочего периода отчеты обнуляются. Режим «0» – интерактивный: формирование отчета происходит в окне программы, в ручном режиме. Переключатель «Блокировка пользователей» предназначен для приостановки доступа пользователям, превысившим свой персональный лимит в Kerio WinRoute 4 Pro или SquidNT, поскольку в этих популярных продуктах нет встроенной системы ограничения. В нашем случае этот влажок можно снять, так как Kerio WinRoute Firewall уже имеет встроенную функцию ограничения. Если вы используете Kerio WinRoute 4 Pro или SquidNT – включите этот режим и для интерактивного, и для автоматического режима. Более подробно про настройку блокировки пользователей при использовании этих продуктов можно прочитать на сайте программы. Итак, в режиме «0» включаем опцию «Отчет в html», отключаем рассылку отчетов, при использовании Squid, ISA, ESPS или WinProxy указываем, какой трафик подсчитывать (логичнее всего, конечно, считать «мимо кэша», так как именно он берется снаружи. Задаем интервал сбора статистики до обнуления (например, текущий месяц). Затем настроим один из автоматических режимов. Переключаем опцию режим до «Автоматический-2» и также настраиваем его. Опция «Ротация логов» в настройках режимов позволяет настроить специальный режим для очистки накопившихся лог-файлов в тех ПП, которые не предусматривают автоматическое удаление. Однако даже если указанная возможность автоматической очистки лог-файлов присутствует в используемом вами прокси или почтовом сервере – использовать указанный способ предпочтительнее во избежание потерь в логах. При запуске программы в данном режиме база отчетов очищается от введенной информации, сбрасываются внутренние счетчики, после чего запускается файл savelog.bat из папки WrSpy. Универсальность метода заключается в том, что в этот файл вы можете поместить любые команды, которые необходимо выполнить после очистки базы данных WrSpy. Чаще всего это копирование и архивация старых лог-файлов, секундная остановка прокси и почтовых служб, удаление лог-файлов, запуск служб. Настройка «Рассылка отчетов» используется для оповещения пользователей по e-mail о их персональном трафике. Для введения этого режима необходимо задать соответствие почтовых адресов для пользователей и зарегистрировать в системе дополнительную компоненту SMTP, которая доступна для скачивания на официальном сайте программы.
№8, август 2005
Рисунок 3. Настройка режимов анализа
На следующем экране «Учет реального трафика» необходимо указать, какой интерфейс является внешним. Данный режим доступен для продуктов Kerio и может не появиться при использовании других ПП. Последним шагом первоначальной настройки необходимо задать ширину полей формируемого отчета. Меню «Настройка» – «Ширина полей» (из меню «Настройка» также можно изменить заданные при первоначальном запуске параметры). Помните, что чем больше задана ширина полей, тем дольше будет формироваться отчет, поэтому необходимо найти разумную середину. В принципе значения по умолчанию оптимальны. Можно только увеличить поле «адреса и доменные имена» до 30-40 символов. Если вы используете Kerio WinRoute Pro 4, то для настройки блокировки пользователей, превысивших персональный лимит, создайте в конфигурации группу, которая не будет иметь никакого доступа к веб-ресурсам. После этого зайдите в меню «Настройка» – «Блокировка доступа» и выделите эту группу. При превышении персонального лимита пользователь будет перенесен в нее и доступ прекратится. Настройка блокировки пользователей в SquidNT описана на сайте программы. Теперь произведем первичный ввод информации. Меню «Данные» – «Очистка и закачка с нуля». Если лог-файлы велики, то потребуется довольно продолжительное время для первоначального ввода (дальнейший ввод будет быстрее, так как чтение информации будет осуществляться только с последней обработанной позиции). После окончания ввода информации будет выдано сообщение о добавление новых пользователей и предложено исправить их. После утвердительного ответа мы получим таблицу с четырьмя закладками: ! Адреса и имена. Здесь хранится информация о пользователях и их лимитах. Поле «Пользователь» заполняется автоматически, по логину пользователя. Для удобства восприятия значение этого поля можно менять на любое, например на ФИО пользователя. Поле «Адрес» заполняется автоматически либо IP-адресом компьютера, с которого пользователь подключается к прокси-
39
администрирование серверу, либо случайной последовательностью символов, если пользователь мигрирует между компьютерами (или наоборот – с одного IP подключались разные пользователи). Поле «Логин» оставляем, как есть, а лимит – также можно свободно изменять – каждому персональный. При импорте новых пользователей это значение берется из настройки «Лимит по умолчанию». Значение «0» – отсутствие ограничений. Если указать в поле «Группа» наименование подразделения – можно будет выводить отчет и суммарный трафик групп. ! Переходим на закладку «Почтовые сервера» и удаляем уже прописанные туда значения – там для примера указаны внешние почтовые сервера, которые должны восприниматься как корпоративные. ! На закладке «Внешние ящики» (если мы импортировали лог-файлы почтового сервера) будут внесены найденные при обработке почтовые адреса. В поле «Пользователь» при этом будет автоматически подставлено значение вида <@unknownNN>. Внимание! Если вы хотите суммировать почтовый трафик пользователя с его трафиком на прокси-сервере – необходимо, сначала заполнив в закладке «Адреса и Имена» поле «Пользователь», в точности повторить значение этого поля для конкретных пользователей в строке его почтового ящика. Только в суммарном отчете можно будет увидеть, что почтовый трафик прибавился нужному пользователю. Если этого не сделать – трафик по почтовым ящикам будет выделен в HTML-отчете в отдельные строки. Все изменения отражаются только после обновления информации в БД и формирования нового отчета. Учтите, что отчет не обновится, если ни в одном из логфайлов не было изменений – программа поймет, что новой информации нет и анализировать ей, собственно, нечего. После всех корректировок и переформирования отчета можно получить красивый и удобочитаемый отчет о трафике пользователей (если при первоначальных настройках была установлена опция «Открывать при создании», то HTML-страница с отчетом будет открываться после каждого формирования в интерактивном режиме). Результат выглядит примерно так (см. рис. 4). Кликнув по логину пользователя, можно просмотреть подробную статистику – с какого ресурса и сколько было скачано (см. рис. 5).
Настройка автоматического формирования отчетов Осталось решить главную задачу – обеспечение функционирования системы в автоматическом режиме, без участия администратора. Здесь все крайне просто и удобно. Формируем командный файл StartLog.bat для добавления новых данных и их анализа в пакетном режиме. Ранее мы настроили для этого один из автоматических режимов. Номер этого режима используется в качестве параметра запуска исполняемого файла WrSpy.exe. @echo off ; переходим в рабочую папку программы cd /D c:\wrspy
40
; запускаем программу с параметром "2" - указание номера ; режима wrspy.exe 2
Все! Настраиваем в любом планировщике задач запуск написанного нами bat-файла, повторяем задание с необходимой периодичностью и проверяем работу системы в целом. Результатом будет автоматическая биллинговая система, не претендующая на абсолютную точность (ведь подсчитывается только трафик, прошедший через прокси- и почтовый сервера, а не весь прошедший через интерфейс), но полностью достаточная для малых и средних компаний. Отчеты создаются в папке, указанной вами при первоначальной настройке (каталог отчетов). В зависимости от настроек они включают в себя различные файлы. При указанных выше па-раметрах формирования отчетов на диске будет создана структура папок, соответствующая logonименам пользователей и файлом общего отчета (Report.htm) в корне папки. Report.htm – это общий отчет, а html-файлы в персональных папках пользователей – детализация их активности. Для просмотра отчетов по сети просто организуйте общий доступ в эту папку. Однако из соображений конфиденциальности рекомендуется предоставлять пользователям доступ только к детализации их собственных отчетов. Если для авторизации на прокси-сервере используется сквозная проверка (т.е. например, на контроллере домена), то названия папок будут соответствовать их logon-именам. Делегировав права на чтение каждой папки только для соответствующей учетной записи, вы создадите необходимый уровень конфиденциальности. Для удобства можно подключать поль-зователям папки с их персональными отчетами как сетевой диск, используя переменные типа %USERNAME% в сценарии входа в систему. При использовании такой методики каждый пользо-ватель сможет самостоятельно контролировать свою активность, не имея при этом возможности получить информацию о детализации трафика своих коллег, что соответствует принципам морали и неразглашения личной информации. При этом контролирующему руко-
Рисунок 4. Общий отчет
Рисунок 5. Подробный отчет по пользователю
администрирование водству делегируются права на чтение всех отчетов, включая корневой отчет Report.htm. Просмотрев общую картину, такой руководитель сможет самостоятельно просмотреть детальную информацию об активности пользователя, не дергая каждый раз системного администратора. Детализация по пользователям крайне удобна для демократичного регулирования ситуаций с превышением персонального лимита. Если пользователь жалуется на то, что необходимо увели-чить ему квоту, так как это необходимо для работы, достаточно просто совместно с ним просмотреть его подробную статистику.
Создание истории отчетов Для того чтобы иметь возможность просматривать статистику за предыдущие месяцы, не изменяя рабочий интервал и не формируя отчеты заново, рекомендуется настроить автоматиче-ское копирование статистики в конце выбранного интервала. То есть написать скрипт создания архивных копий и выполнять в последние часы перед сменой рабочего интервала (например, в последний день месяца или недели – в зависимости от ваших настроек). Например, используя консольную версию общеизвестного архиватора WinRar – rar.exe можно создавать архивы, содержащие рабочую дату в имени файла. Приведенный пример создаст файл Report_<текущая_дата>.rar и поместит в него содержимое папки E:\WrSpy\Report и всех ее подпапок, с максимальным сжатием, сохранением информации о правах и владельцах файлов. rar.exe a -m5 -os -ow -dh -ep1 -r ↵ -ag _ dd-mm-yyyy D:\BackUp\Report.rar ↵ E:\WrSpy\Report\*.*
Отчеты интерактивного режима В интерактивном режиме WrSpy позволяет формировать еще более гибкие и удобные отчеты. Например, вы можете посмотреть – а какой именно файл скачал с определенного ресурса конкретный пользователь. Запускаем программу без параметров, выбираем меню «По пользователям – Файлы и сайты по пользователям». После вывода на экран таблицы можно перемещаться по ней, выделяя курсором интересующий нас ресурс и в нижней части просматривая список закачек (рис. 6):
По таблице видно, что пользователь romadm закачивал с сайта speedownload.nai.com некие ZIP-архивы. Отчет «Бюджет времени пользователя» покажет вам соотношение времени, которое сотрудники проводят на вебсайтах. Обратите внимание – это не точное время, проведенное пользователем в сети, а относительная оценка времени, проведенного пользователем или станцией в Интернете, которая осуществляется косвенным методом. Однако общую картину данный отчет хорошо показывает, и согласно ему можно понять, кто «беспрерывно» занимается серфингом по веб-сайтам. Принцип расчета довольно прост: Весь интервал времени анализа разбивается на кванты от 1 до 30 минут. Величина кванта задается (см. рис. 2 – «Интервал для учета бюджета времени») исходя из стиля работы ваших пользователей. Для быстрого серфинга – меньшие значения, для длительного скачивания – большие. Если пользователь проявлял какую-то активность в течение данного кванта, в его бюджет заносится его (кванта) величина. Суммирование всех этих значений и дает величину оценки времени. Кроме того, формируется усредненное распределение суммарного трафика по времени суток.
Почтовые сервера Отчеты, формируемые по лог-файлам почтовых серверов, также удобны для восприятия и отличаются наличием более глубокой статистики в интерактивном режиме. Возможна детализация по каждому пользователю (сколько писем, на какой/с какого адреса, созданный трафик и пр.), наглядные графики по самым активным пользователям и пр.
Анализ лог-файлов UNIX-систем Как было упомянуто, WrSpy понимает форматы популярных UNIX-MTA и прокси. Для осуществления анализа данных файлов можно использовать два способа: анализ рабочих лог-файлов или их копий. Первый способ более прост, так как не придется копировать файлы большого размера (либо также писать обработку для копирования только новых данных). В первом случае необходимо создать и предоставить сетевой доступ к папке с этими файлами для учетной записи, от имени которой WrSpy запускается в пакетном режиме. Во втором случае данные файлы необходимо копировать, что не всегда приемлемо по описанной выше причине. Остальная работа с этими логами аналогична уже описанной. Я описал лишь некоторые, наиболее популярные возможности программы WrSpy. Если ее функции показались вам интересными – рекомендую установить ее для тестирования и самостоятельно оценить удобство (или неудобство – решать вам). Тем более, что никаких следов в ОС она не оставляет и удаляется без последствий. Вкупе с этим – наличие сайта поддержки и при этом абсолютная бесплатность продукта делают его крайне привлекательным для построения разнообразных отчетов.
Ссылки: Рисунок 6. Отчет «Файлы и сайты по пользователям»
№8, август 2005
1. Официальный сайт программы: http://www.wrspy.ru. Дистрибутивы и обновления доступны для загрузки на главной странице сайта.
41
администрирование
ЗНАКОМИМСЯ С HPC-КЛАСТЕРОМ OpenMosix Большую часть времени ПЭВМ, скажем честно, простаивает. Средняя загрузка не превышает 20%. Но как только начинается сборка приложений, например на C++, или оцифровка видео-, аудиофайлов, то становится очевидным недостаток вычислительных ресурсов. Основная идея HPC-кластеров – задействовать ресурсы, свободные на других узлах кластера.
АНТОН БОРИСОВ Что такое кластер Кластер – это две или более самостоятельные системы, объединенные в единое целое посредством специального программного и аппаратного обеспечения. Основное звено кластера – это единичный компьютер, называемый узлом. Кластеры могут расти – «масштабироваться» – путем добавления новых узлов. При этом синергетическое целое мощнее, нежели отдельный узел. Изменения в структуре кластера, например, появление и удаление узлов из состава кластера (по разным причинам – авария или, наоборот, восстановление после критической ситуации) фиксируется всеми оставшимися/новыми узлами.
ределенным количеством производителей и организация, которая хотела купить суперкомпьютер, должна была обладать немалым финансовым ресурсом. Естественно, что большинство университетов не могли себе позволить такого рода дорогую игрушку, поэтому в их недрах начала создаваться концепция кластера для академических кругов. Цель данной концепции – подготовить условия для распараллеливания задачи между узлами, передать обработку подзадач на узлы и затем собрать результаты каждой подзадачи. Кластер предполагалось собирать на PC-платформе, благо она становилась всё более и более распространенным явлением и по сути дешевой.
Типы кластеров
Кластерные модели
На сегодняшний момент широко известны и распространены 3 типа кластеров – отказоустойчивые (например, LifeKeeper – см. [1]), с балансировкой загрузки (Load-Balancing) и высокопроизводительные (High-Perfomance Computing): ! Отказоустойчивый кластер состоит из двух или более узлов, между которыми существует выделенное соединение (heartbeat), которое используется для обмена служебной информацией между узлами. Как только какойлибо из узлов перестает функционировать, то второй (резервный) узел берет его функции на себя. ! Задача кластера с балансировкой нагрузки заключается в том, чтобы перенаправить запрос, скажем к веб-серверу, к наименее загруженному в данный момент времени узлу. По существу, этот тип кластера можно также назвать отказоустойчивым, только с дополнительным функционалом балансировки и с большим количеством узлов. ! В высокопроизводительном кластере узлы сконфигурированы таким образом, чтобы общая производительность была максимальной. В этом типе кластера присутствуют и балансировочные механизмы – задания распределяются между узлами. Самое интересное в таком типе кластера – факторизация процесса (разбиение задачи на несколько параллельных подзадач). Процесс не ожидает освобождения CPU, а запускает свои подзадачи на разных узлах.
Существует несколько методов распараллеливания – N(UMA), DSM, PVM и MPI. Некоторые из этих схем реализованы аппаратно, другие программно. Бывают и смешанные решения: ! (N)UMA ((Non-)Uniform Memory Access) – узлы имеют доступ к общей памяти, где выполняется код. Стоит отметить, что в Linux-ядре есть NUMA-реализация. ! DSM (Distributed Shared memory) реализовано как программно, так и аппаратно. Концепция этого метода заключается в предоставлении уровня абстракции для физически распределенной памяти. ! MPI (Message Passing Interface, интерфейс передачи сообщений) – это открытая спецификация для создания библиотек передачи сообщений. В частности, библиотека MPICH – самое известное решение на базе MPI. Другое известное решение – библиотека LAM. ! PVM (Parallel Virtual Machine) является собратом MPI. Фунционирует PVM в пользовательском пространстве, поэтому каких-то модификаций на уровне ядра не требуется. Пользователь с достаточными правами может запустить PVM.
Суперкомпьютеры и кластеры Традиционно ресурсоемкие математические вычисления выполнялись на суперкомпьютерах. Они выпускались оп-
42
Сущность OpenMosix Пакет OpenMosix – это патчи к ядру Linux. На момент написания этого материала существуют патчи для ядра 2.4.26 и для ветки 2.6. Так как OpenMosix реализован в виде патчей, то сохраняется полная совместимость между программами, файлами и другими ресурсами в Linux. Обычный пользователь может и не заметить изменений между Linux-машиной и OpenMosix-кластером, ибо послед-
администрирование ний будет расматриваться как рядовая Linux-машина, только немного производительнее. Внутренний механизм балансировки прозрачно производит миграцию процессов на узлы кластера. Оптимальная загрузка кластера вычисляется динамически через определенные промежутки времени. Вы также можете произвести нужную подстройку параметров кластера. Прозрачный механизм миграции играет интересную роль – из-за него весь кластер выглядит как большая SMP-машина со множеством процессоров (каждый узел в роли процессора). В рамках OpenMosix разработана файловая система (oMFS) для HPC-приложений, которая в отличие от NFS поддерживает целостность ссылок, атрибуты времени и кеширование. Сегодня в нашем обзоре в качестве узлов кластера будут выступать 3 машины: ! Intel(R) Pentium(R) 4 CPU 1.80 ГГц (256 Мб ОЗУ) ! Intel Pentium III (Katmai) 602.149 МГц (256 Мб ОЗУ) ! Intel(R) Pentium(R) 4 CPU 3.00 ГГц (128 Мб ОЗУ) Все узлы соединены через хаб (100 МБит) в единое пространство. Операционная система, OC Linux, первоначально установлена на самой быстрой машине, а затем была клонирована на все остальные. Стоит отметить, что при установке, помимо базовых пакетов, также следует выбрать и QT-библиотеку (на базе QT мы впоследствии соберем утилиты мониторинга кластера). Итак, первый шаг по установке и настройке ПЭВМ с ядром по умолчанию пропускаем. Следует настроить SSH-сервис, т.к. благодаря ему мы будем управлять узлами. Далее заберем ядро (2.4.26) с включенными патчами для OpenMosix (32 Мб): wget http://citkit.dl.sourceforge.net/sourceforge/ ↵ openmosix/ ↵ openmosix-kernel-source-2.4.26-openmosix1.i386.rpm
Для экономии трафика можно взять только патчи и наложить их на оригинальное ядро с kernel.org самостоятельно (200 Кб): wget http://citkit.dl.sourceforge.net/sourceforge/ ↵ openmosix/openMosix-2.4.26-1.bz2 # rpm -ih --nodeps ↵ openmosix-kernel-source-2.4.26-openmosix1.i386.rpm # cd /usr/src/linux-2.4.26-openmosix1/ # make xconÞg
Ставим галочки для компонентов OpenMosix (рис. 1), остальные компоненты для ядра не изменяем, сохраняем конфигурацию и собираем ядро. # makedep&& make && make bzImage && make modules # make modules _ install
Добавляем нужную опцию в загрузчик. В случае lilo: image = /boot/mosix-bzImage root = /dev/sda1 label = om.Linux read-only # /sbin/lilo -v
И перезагрузка.
№8, август 2005
Рисунок 1. Компоненты ядра, отвечающие за функционирование OpenMosix
Для управления и тюнинга узлов в OpenMosix предусмотрен специальный пакет утилит – openmosix-tools. Установим его. wget http://citkit.dl.sourceforge.net/sourceforge/ ↵ openmosix/openmosix-tools-0.3.6-2.tar.gz # tar xzvf openmosix-tools-0.3.6-2.tar.gz # cd openmosix-tools-0.3.6-2 # ./conÞgure --preÞx=/opt/OpenMosix ↵ --with-kerneldir=/usr/src/linux-2.4.26-openmosix1 # make && make install
После установки этого пакета есть два варианта, каким именно образом узлы будут сообщать друг другу о своих характеристиках (загрузка, вычислительная мощность) и координатах (IP-адрес). Либо указать жестко в файле /etc/ openmosix.map, либо положиться на сервис автоопределения узлов (omdiscd). Структура файла openmosix.map представлена ниже: # MOSIX-# IP number-of-nodes # ============================ 1 10.0.0.1 1 100 0.0.0.100 1
В первой колонке указывается номер узла (в моем случае первый узел имеет номер 1, второй – 100), во второй колонке IP-адрес, в третьей колонке – количество узлов в диапазоне. Т.е. предполагая, что первые пять узлов имеют последовательные адреса от 10.0.0.1 до 10.0.0.5 смысла их перечислять нет. Стоит только указать, что количество узлов равно в этом случае 5. 1
10.0.0.1
5
Так раздаются адреса статически. А для их динамического определения будет использоваться файл /etc/openmosix/ openmosix.config, где прописываются такие параметры, как: ! AUTODISCIF – имя интерфейса, через который производит автопоиск (если на узле несколько сетевых интерфейсов). ! MYOMID – номер данного узла. ! MIGRATE – разрешать ли процессам миграцию с данного узла или нет. ! MFS – использовать Mosix FileSystem или нет. Я пошел по пути динамического определения узлов и для этого включил старт автоматического определения omdiscd – добавил в /etc/rc.d/rc.local строку:
43
администрирование /opt/OpenMosix/sbin/omdiscd -i eth0
Таким образом, при последовательном старте узлов вы можете отслеживать в логах процесс формирования кластера:
#!/bin/sh NODE1=/proc/hpc/nodes/573 NODE2=/proc/hpc/nodes/574 NODE3=/proc/hpc/nodes/575 FILENAME=hpc _ load.txt i=0
Jul 26 22:01:57 athlon kernel: openMosix #1 is at IP address 10.0.0.1 Jul 26 22:01:57 athlon omdiscd[1996]: Notified kernel to activate openMosix Jul 26 22:02:55 athlon kernel: eth0: Setting full-duplex based on MII #1 link partner capability of 45e1. Jul 26 22:04:11 athlon kernel: openMosix configuration changed: This is openMosix #1 (of 2 configured) Jul 26 22:04:11 athlon kernel: openMosix #1 is at IP address 10.0.0.1 Jul 26 22:04:11 athlon kernel: openMosix #100 is at IP address 10.0.0.100
while true do DateStr='date +%H-%M-%S' Load1='cat $NODE1/load' Load2='cat $NODE2/load' Load3='cat $NODE3/load' echo "$DateStr ($i): $Load1, $Load2, $Load3" >> $FILENAME echo "Time: $DateStr ($i). Load: $Load1, $Load2, $Load3";
Для того чтобы системные процессы (те, что отвечают за загрузку и выключение узла) не мигрировали на другие узлы, используем в файле /etc/inittab такую конструкцию: строки с участием директории rc.d: si:S:sysinit:/etc/rc.d/rc.S
перепишем так: si:S:sysinit:/bin/mosrun -h /etc/rc.d/rc.S
что дословно означает «запускать стартовый скрипт rc.S на домашнем узле». Также следует поменять строки, где участвует rc.d, а также строку: ca::ctrlaltdel:/sbin/shutdown -t5 -r now
которая будет выглядеть так: ca::ctrlaltdel:/bin/mosrun -h /sbin/shutdown -t5 -r now
Все готово, чтобы первый настроенный узел клонировать на другие машины. Воспользуйтесь либо командой dd, либо программой Norton Ghost. Затем в клонированных узлах поменять IP-адреса, hostname, и дело в шляпе. Для тестирования производительности сформированного кластера я решил проверить, за какое время будет собран MPlayer [2].
Тестируем быстродействие Как я проводил замеры. Когда кластер обнаруживает новый узел, он создает в виртуальном каталоге /proc/hpc/nodes новую ветку, совпадающую с номером обнаруженного узла. Следует отметить, что весь каталог /proc/hpc относится к функционированию OpenMosix. Таким образом, если появляется новый узел с номером XXX, то автоматически появляется каталог /proc/hpc/nodes/XXX, в котором хранятся файлы с характеристиками данного узла. В частности, содержимое файла load нас и будет интересовать. Производительность узлов в OpenMosix оценивается по сравнению с виртуальной ПЭВМ класса Celeron 1 ГГц, поэтому не удивляйтесь, когда увидите, что производительность конкретного узла, например, равняется 20000. Это означает, что по сравнению с эталонным 1 ГГц данный узел в 2 раза производительнее. Итак, производим калькуляцию. Сохраним данный скрипт, использующийся в наших подсчетах в дальнейшем.
44
i='expr $i + 1'; sleep 1s; done
Скрипт получился простеньким для понимания. Нагрузку «в попугаях» мы трансформируем в график, где посмотрим, какое участие принял каждый конкретный узел в процессе сборки. Так как считается, что кластер в нашем случае – это единое пространство с увеличенным количеством процессоров, то используем данный факт. Сначала посчитаем время сборки, когда работает только один узел, самый быстрый. Предварительно распакуем MPlayer: # # # #
wget MPlayer tar xzvf MPlayer cd MPlayer ./conÞgure
Теперь запускаем наш скрипт collect_hpc_load.sh и считаем время: # time make dep # time make real user sys
0m19.068s 0m2.570s 0m16.410s
real user sys
5m11.963s 3m44.950s 1m26.410s
Включаем узел с самым медленным CPU. Теперь производим подсчет. real user sys
0m20.693s 0m2.670s 0m17.450s
real user sys
5m17.013s 4m5.820s 1m43.620s
Получили еще худший результат. Почему? Очень просто – у нас сформировалось много процессов, но с маленькими вычислительными запросами. Общее время миграции по 100-Мбитной сети плюс время компиляции превысило предыдущий результат. Включаем третий узел с 1.8 ГГц CPU. Посмотрим на цифры. real user sys
0m24.860s 0m2.800s 0m17.610s
администрирование real user sys
4m18.754s 4m17.620s 2m16.540s
Отлично. А что произойдет при отключении самого медленного узла? Отключаем, проверяем. real user sys
0m23.539s 0m3.260s 0m17.580s
real user sys
4m24.304s 4m18.270s 2m14.320s
Выигрыш от медленного узла составил примерно 6 секунд. Как говорится – спорный результат. Стоит ли овчинка выделки – а именно, нужен ли третий узел? Очевидно стоит отказаться в пользу двухузловой модели. Полученные результаты удобнее анализировать графически. Импорт в OpenOffice и дальнейшее преобразование в диаграммы закончилось получением этих рисунков. Синим цветом отмечен узел на базе Pentium 4 CPU 3 ГГц, красным – узел Pentium 4 CPU 1.8 ГГц, белым – Pentuim 3 CPU 600 МГц (рис. 2-5).
Утилиты мониторинга Как производить текущий мониторинг загрузки? К счастью, у OpenMosix достаточно широкая аудитория пользователей, благодаря которым появились утилиты визуального контроля и управления. Нужный нам сейчас пакет называется openmosixview.
# wget openmosixview-1.5.tar.gz # tar xzvf openmosixview-1.5.tar.gz # cd openmosixview-1.5
Данное ПО написано на QT – надеюсь, вы его поставили, не забыли. Оно состоит из следующих программ: ! openMosixview – приложение для мониторинга и управления кластера. ! openMosixprocs – приложение, показывающее процессы и их свойства. ! openMosixcollector – сервис по сбору статистики. ! openMosixanalyzer – приложение для анализа данных, собранных сервисом статистики. ! openMosixhistory – приложение, для просмотра миграций процессов в определенный момент времени. ! openMosixpidlog – приложение для мониторинга единичных процессов. ! 3dmosmon – приложение для объемного мониторинга кластера. К сожалению, у меня последняя программа не захотела собираться. Решение оказалось простым – при компиляции приложения 3dmosmon следует заменить инициализацию переменных в файле materials.h из вида: static material _ struct whiteMaterials = { {1.0, 1.0, 1.0, 1.0}, {0.0, 0.0, 0.0, 1.0}, {1.0, 1.0, 1.0, 1.0}, {20.0} };
Рисунок 2. Загрузка кластера при одноузловом варианте
Рисунок 3. Загрузка кластера при двухузловом варианте (оба узла Pentium 4)
Рисунок 4. Загрузка кластера при двухузловом варианте (один из узлов Pentium 3)
Рисунок 5. Загрузка кластера при трехузловом варианте
№8, август 2005
45
администрирование в вид: static material _ struct whiteMaterials = { {1.0, 1.0, 1.0, 1.0}, {0.0, 0.0, 0.0, 1.0}, {1.0, 1.0, 1.0, 1.0}, 20.0 };
А для приложения mosstatd добавить ключи, чтобы строка выглядела следующим образом (красным шрифтом отмечены добавленные параметры): gcc -I/usr/src/linux-2.4.26-openmosix1/include/ ↵ -I/usr/local/openmosix-tools/include/ -o mosstatd ↵ -L/usr/local/openmosix-tools/lib/ -lmos mosstatd.c
В итоге, запустив предварительно сервис сбора статистики mosstatd (например, через инициализационный скрипт /etc/rc.d/rc.local), мы сможем отслеживать загрузку кластера в виде трехмерного изображения (см. рис. 6).
Рисунок 6. Трехмерное изображение загрузки кластера
# 3dmosmon localhost
Сборка остальных программ достаточно тривиальна: # cd openmosixview # make # ./openmosixview
По такому же принципу собираются и остальные утилиты. openMosixview – наглядный пример, какие узлы в данный момент загружены и общая картина по производительности (см. рис. 7). Приведена ситуация, когда отключен наименее производительный узел. Отключение узла от кластера отображается индикатором красного цвета. Графическая утилита openmosixmigmon позволяет, не утруждая себя поисками PID конкретного процесса, перебросить его выполнение на другой узел (см. рис. 8). В частности, некоторые процессы с головного узла уже насильно мигрированы к соседям и используют их вычислительные мощности. Следующая интересная утилита из данного пакета называется openMosixanalyzer. Видна нагрузка как в целом на кластер, так и на отдельные узлы за определенный момент времени (см. рис. 9). А чтобы такая статистика велась на постоянной основе, придуман сервис openMosixcollector, как видим из названия, его работа заключается в сборе данных и сохранении их на диске. Запускается он просто – «openmosixcollector -d» – работает в качестве сервиса. Собранная информация раз в сутки сбрасывается в директорию /tmp/openmosixcollector_ ДАТА_ВРЕМЯ. Давайте теперь ознакомимся с утилитами по настройке кластера. mosctl – утилита для просмотра/редактирования параметров узла. Рассмотрим характерные конструкции на основе данной утилиты. # mosctl --help
46
Рисунок 7. Визуальная картина загрузки посредством утилиты openMosixview Usage: mosctl command Available commands: stay/nostay, lstay/nolstay, block/noblock, quiet/noquiet, mfs/nomfs, expel, bring, gettune, getdecay, whois [mosix_no|IP-address|hostname], getload [node-number], getspeed [node-number], status [node-number], getmem [node-number], getfree [node-number], getutil [node-number], getyard, setyard [node-type], setspeed speed, setdecay interval(seconds) slow(/1000) fast(/1000), isup [node-number]
! mosctl whois node0 – выводит IP-адрес узла node0; ! mosctl getload node0 – выводит загрузку узла node0; ! mosctl getspeed node0 – выводит скоростную характеристику узла node0;
! mosctl gettune – выводит показатели для данного узла; ! mosctl bring – передает сигнал мигрированным процессам для возврата на домашний узел.
Как видите, тот пример, что мы рассмотрели и использовали в своей работе, можно переписать намного нагляднее при использовании утилиты mosctl. # moslimit --help Usage: moslimit command Available commands: setloadlimit [numeric-value], setcpulimit [numeric-value], setllimitmode [numeric-value], setcpulimitmode [numeric-value], getloadlimit [node-number], getcpulimit [node-number], getllimitmode [node-number], getcpulimitmode [node-number], getloadlocal [node-number], getcpulocal [node-number], getloadremote [node-number], getcpuremote [node-number]
Для миграции процессов в пределах кластера предназначена утилита migrate. # migrate --help Usage: migrate pid {OpenMosix-ID|home|balance}
А вот список процессов, который мы сможем увидеть при запуске утилиты ompsinfo. root@node0:~# ompsinfo
администрирование Утилита mosmon предназначена для визуального отображения текущей загрузки кластера. Она скомпилирована на основе библиотеки ncurses, поэтому текстовой консоли вполне будет достаточно для ее запуска. Для запуска заданий предназначена утилита mosrun. С ее помощью можно указать, к какому типу процессов принадлежит наше задание. Либо это CPU-intensive, т.е. задание, использующее процессорные ресурсы, либо I/Ointensive – задание, где основной упор делается на процесс ввода/вывода. Usage: mosrun [-{h|OpenMosix_ID|-jID1-ID2[,ID3-ID4]...} [-F] ] -{l|L|k} [-{c|i|n|s|f | ([-d dec] [-t tt])} [-{e|E}] [-{r|R}] ] [-z] prog [args]..
Утилита showmap выводит список узлов кластера. root@node0:~# showmap My Node-Id: 0x023d Base Node-Id -----------0x023d 0x023f
Рисунок 8. Контроль за миграцией процессов в кластере
Address ---------------192.168.2.61 192.168.2.63
Count ----1 1
Сервис, отвечающий за динамическое определение узлов кластера. В частности, когда на узле используется несколько сетевых интерфейсов, следует явно указать, по какому из них проводить идентификацию узлов. omdiscd-i eth0
Выводы
Рисунок 9. Статистика по загрузке кластера в определенное время CMD init keventd ksoftirqd_CPU0 kswapd bdflush kupdated khubd kjournald oM_migd oM_infoD memsorter syslogd klogd inetd sshd crond gpm agetty agetty agetty agetty agetty agetty omdiscd mosstatd sshd bash ompsinfo
PID NODE NMIGS LOCK CANTMOVE 1 0 0 0 system 2 0 0 0 clone_vm 3 0 0 0 clone_vm 4 0 0 0 clone_vm 5 0 0 0 clone_vm 6 0 0 0 clone_vm 8 0 0 0 clone_vm 10 0 0 0 clone_vm 11 0 0 0 system, clone_vm 12 0 0 0 system, clone_vm, rt_sched 13 0 0 0 system, clone_vm 62 0 0 1 migratable but locked 65 0 0 1 migratable but locked 340 0 0 1 migratable but locked 343 0 0 0 migratable 351 0 0 1 migratable but locked 360 0 0 1 migratable but locked 362 0 0 0 migratable 363 0 0 0 migratable 364 0 0 0 migratable 365 0 0 0 migratable 366 0 0 0 migratable 367 0 0 0 migratable 398 0 0 0 migratable 476 0 0 0 migratable 2778 0 0 0 migratable 2780 0 0 0 migratable 2852 0 0 0 migratable
№8, август 2005
Как и в любом аспекте нашей жизни можно найти минусы и плюсы, так и решения на базе OpenMosix-кластера содержат некие «узкие» точки. В частности, оцифровка звуковых файлов из формата .wav в формат .mp3 показала, что общее время процесса обработки на кластере превысило аналогичное время на одной ПЭВМ. Повлияла на столь странный результат низкоскоростная среда передачи данных – 100-мегабитная сеть. В целом применение OpenMosix-кластеров целесообразно в тех случаях, когда требуется использовать задачи с высокими интенсивными вычислительными запросами, например сборка программного обеспечения (как показано в этой статье), симуляторы погоды, обработка геофизических данных, математических моделей и в других подобных ситуациях .
Ссылки, литература: 1. Борисов А. «Стальной глаз на страже жизни». HA-кластер LifeKeeper компании SteelEye. – Журнал «Системный администратор», №7, 2004 г. – 43-49 с. 2. http://www.mplayerhq.hu. 3. http://openmosix.sourceforge.net. 4. http://www-128.ibm.com/developerworks/eserver/articles/ openmosix.html. 5. http://howto.x-tend.be/openMosixWiki. 6. http://howto.x-tend.be/openMosix-LCA2005. 7. http://tab.snarc.org/article/om_internals.xhtml. 8. http://www.samag.com/documents/s=9658/sam0505a/ 0505a.html.
47
администрирование
УПРАВЛЯЕМ УДАЛЕННЫМИ БАЗАМИ AIDE
В один прекрасный день вы решаете оснастить все ваши сервера программой локального контроля от вторжений AIDE. Осуществлению этого, несомненно правильного желания мешает только одно – сервера территориально разбросаны, а хотелось бы хранить базы AIDE на съемных носителях... Сегодня мы расскажем вам, как собрать данные со всех компьютеров, не вставая с места.
РАШИД АЧИЛОВ
П
рограмма AIDE позволит вам контролировать изменения, происходящие в файловой системе. Для этого она создает отдельную базу данных, содержащую информацию об атрибутах файлов – дате и времени создания, дате и времени модификации, размере, владельце. База также содержит контрольную сумму содержимого файла для проверки его на неизменность содержимого. Контрольная сумма шифруется различными методами для исключения возможности ее подделки. Правильное использование AIDE гарантирует в достаточной степени неизменность файлов. Но вот работают несколько серверов, на них всех установлена AIDE, базу которой рекомендуется хранить на сменном носителе с целью не допустить попадания ее в чужие руки. Как реализовать это требование? Не вручную же копировать базу с каждого сервера? Для автоматизации этой задачи и был разработан скрипт AIDEControl. Итак: ! Базы AIDE на всех наших серверах размещаются (по умолчанию) в /var/db/aide/aide.db. ! Обновление базы производится сторонними средствами (вручную, через cron или с помощью скриптов). Мы рассмотрим программу автоматического копирования баз AIDE с множества удаленных машин на некую центральную машину, обеспечивающую при этом невозможность использования данных базы в случае ее несанкцио-
48
нированного перехвата. Программа копирует базы на сменный носитель небольшого физического размера, а также сохраняет несколько поколений баз на сменном носителе большого обьема. Нужно ли защищаться от перехвата данных базы? Даже при невозможности ее модификации база все равно остается лакомым куском, потому что содержит список всех файлов (кроме тех, которые были исключены через конфигурационный файл) с указанием их имен, размеров, дат создания и владельцев, а это уже сама по себе немалая информация. Поэтому копирование баз будем производить через SSH с использованием скрипта, описанного в [1]. Двойное копирование последнего поколения базы необходимо потому, что последнее поколение хранится «под руками» – там, где контроль за неизменностью файлов ведется чисто визуально. Дубль же последнего поколения, а также несколько предыдущих поколений хранятся на RW-диске в сейфе, там же, где хранятся резервные копии данных. При необходимости вы всегда сможете сравнить две копии, а также провести анализ, как изменялся тот или иной файл (по предыдущим копиям базы). На рис. 1 изображена связь между мастер-компьютером, компьютерами, с которых собираются базы, и носителями. Для каждого приведено расположение файлов базы AIDE в процессе работы скрипта. Следует учесть, что это расположение баз именно в процессе работы скрипта, потому что, когда база скопирована на мастер-компьютер, она
администрирование стирается с удаленного компьютера, а при завершении копирования на Flash она удаляется и с мастер-компьютера. Для подключения к удаленным компьютерам скрипт использует пользовательский бюджет с именем aide. Это бюджет не для запуска скрипта, запуск скрипта делается только пользователем root. Скрипт реализован на языке Bourne shell, с использованием типового комплекта инструментов – sed, awk, grep. В качестве мастер-компьютера использовался компьютер с операционной системой FreeBSD 5.3-RELEASE, USB Flash Seitek BAR 128 Мб и CompactFlash PQI 128 Мб. Работа в других UNIX-системах не проверялась.
Какое программное обеспечение потребуется Для работы скрипта необходимо установить и настроить соответствующим образом следующее програмное обеспечение: ! SSH2 от SSH Communications или OpenSSH с поддержкой протокола SSH2. SSH должен быть настроен на возможность работы без предъявления паролей, с авторизацией по публичному ключу. Описание того, как это сделать, вы найдете в [1] . Единственное отличие – для авторизации используется имя пользователя aide. Для FreeBSD устанавливается из портов secuirty/ssh2nox11. ! Bzip2. Для FreeBSD Bzip2 является стандартной программой и поставляется вместе с системой. При отсутствии его программа выдаст предупредительное сообщение и аварийно завершит работу. ! Mkisofs и CDRecord. Программа из состава продвинутого программного пакета cdrtools для создания и записи ISO-образов. Для FreeBSD устанавливается из портов sysutils/cdrtools. ! Скрипт для пакетной записи ISO-образов BurnISO. Скачать его вы можете с домашней страницы [2]. ! AIDE должна быть создана на каждом компьютере, с которого предполагается их копировать, и располагаться в каталоге по умолчанию /var/db/aide. Для FreeBSD устанавливается из портов seciruty/aide.
Настраиваем систему Вам потребуются: ! в /etc/fstab описания следующих точек монтирования: ! /cd-rw (или любую другую, описанную параметром cdrwdevmp конфигурационного файла) для монтирования RW-диска с полным комплектом поколений баз, например: /dev/acd1 /cd-rw ro,noauto,noexec
0
cd9660 0
↵
! /mnt/umass (или любую другую, описанную параметром usbdevmp конфигурационного файла) для монтирования Flash для хранения последнего поколения баз AIDE, например: /dev/da0s1 /mnt/umass rw,noauto,-l,-Wkoi2dos 0
msdos 0
↵
(подробное описание полей fstab см. man fstab).
№8, август 2005
Рисунок 1. Расположение баз AIDE на «мастере» и удаленных компьютерах
! в файле /etc/usbd.conf опишите Flash таким образом,
чтобы при ее установке происходило автоматическое монтирование. Для этого добавьте в файл /etc/usbd.conf следующие строки: # Generic USB Flash drive (umass0) device "USB Flash Drive" devname "umass[0-9]+" vendor 0x058f product 0x9380 release 0x0100 attach "/sbin/mount /mnt/umass"
где vendor, product и release берутся из вывода usbd, запускаемого с ключом -dv. Для каждого типа Flash значения отличаются! Вы должны подставить свои значения, получив их следующим образом: # usbd -dv usbd: opened /dev/usb0 usbd: opened /dev/usb1 usbd: opened /dev/usb2 usbd: opened /dev/usb3 usbd: reading configuration file /etc/usbd.conf usbd: opened /dev/usb usbd: device-attach event at 1121236066.985133000, Mass Storage Device, Generic: vndr=0x058f prdct=0x9380 rlse=0x0100 clss=0x0000 subclss=0x0000 prtcl=0x0000 device names: umass0
vndr – vendor (в данном случае 0x058f), prdct – product (в данном случае 0x9380), rlse – release (в данном случае 0100) подставляются в соответствующие места файла /etc/usbd. conf. Файл читается один раз при старте программы, поэтому для активации внесенных изменений usbd необходимо перезапустить: # killall usbd # usbd
Внимание! Крайне не рекомендуется завершать работу usbd, запущенного с ключами -dv тогда, когда в USB вставлено какое-либо устройство, особенно если оно работает по протоколу USB 1.1! Было замечено стабильное полное
49
администрирование зависание системы, из которого можно выйти только нажатием «Reset». Настоятельно рекомендую сначала извлечь устройство, а потом завершать работу usbd. Система должна обладать возможностью смонтировать USB Flash, а также обладать возможностью работать с IDE СD-ROM как со SCSI. Для этого в конфигурационном файле ядра системы должны присутствовать (а если их нет, то просто добавьте) следующие строки: device device device device device device device
umass scbus da pass cd atapicam ata
после чего ядро системы должно быть пересобрано в соответствии с инструкциями по его пересборке, приведенными, например в [3]. Кроме того, понадобится один носитель CompactFlash или USB Flash емкости, достаточной для того, чтобы вместить одно поколение копий баз со всех нужных компьютеров, упакованное Bzip2, и один CD-RW или DVD-RW-диск для хранения необходимого количества предыдущих поколений. Полный текст скрипта приведен в Приложении 1 (см. www.samag.ru, раздел «Исходный код»). Он снабжен достаточно подробными комментариями, а наиболее важные и интересные моменты мы обсудим далее по ходу статьи.
Общее описание логики работы и конфигурационный файл Предполагается, что «мастер» – доверенная машина. На рис. 1 показано размещение баз AIDE в процессе их обработки скриптом. Общая связь между программами такова: ! AIDE создает свою базу на каждом из компьютеров. ! aidecontrol переписывает (именно переписывает, а не копирует – после успешного копирования файл удаляется с компьютера «агента») ее с удаленной машины («агента») на центральную машину («мастер») в свой каталог (показан на рис. 1, на компьютере Master, в рамке слева). После чего aidecontrol запрашивает у оператора установку RW-диска, монтирует его в указанную точку монтирования, считывает его содержимое, дополняет новым поколением и записывает заново. Для копирования используется временный рабочий каталог, который создается в процессе работы и после завершения работы удаляется. Расположение файлов в момент, когда они скопированы во временный каталог, приведено на рис. 1, на компьютере Master, справа. Расположение файлов на съемных носителях (Flash и RW-диске) приведено на рис. 1, в нижней части на соответствующих выносках. Все компьютеры, базы с которых должны собираться, описываются в файле описания узлов. Формат его очень простой: remote1
50
10.87.2.60
remote2 remote3 master
10.87.2.254 10.87.2.120 127.0.0.1
Последняя запись отражает тот факт, что сам «мастер» может рассматриваться и как «агент». Для этого необходимо указывать в качестве IP-адреса 127.0.0.1. AIDE на всех компьютерах, кроме «мастера», настраивается на путь к базе /var/db/aide/databases/aide.db. После копирования базы на «мастер» она удаляется. На «мастере» в каталоге databases создаются подкаталоги с именами, соответствующими именам в файле описания узлов (remote1, remote2,...), в которые база помещается на время копирования на Flash и RW-диск. После успешного копирования на съемные носители база удаляется с «мастера» и существует только на съемных носителях. Конфигурационный файл программы по формату предельно прост: поскольку сама программа написана на языке Bourne Shell, загрузка конфигурационных файлов проводится выполнением файла и, следовательно, формат имеет вид «имя=значение». Имя файла по умолчанию – /usr/local/etc/aidecontrol.conf, все возможные переменные описаны непосредственно в тексте файла. Пример файла приведен в Приложении 2 (см. www.samag.ru, раздел «Исходный код»).
Блок-схема программы Блок-схема программы приведена на рис. 2. Сбоку, на выносках отмечены метки блоков, приводимые в комментариях текста скрипта в Приложении 1 (см. www.samag.ru, раздел «Исходный код»). Первыми выполняются анализ командной строки и установка значений, заданных в параметрах. Соответствующая метка в скрипте – CMDLINE. Возможные ключи командной строки: ! -c – указывает расположение конфигурационного файла. Если не задан, используется /usr/local/etc/aidecontrol. conf. ! -l – указывает расположение файла списка узлов, формат которого приведен выше. Если не задан, используется /var/db/aide/maint/aidehosts. ! -b – указывает на то, что будет установлен чистый RWдиск, который не нужно монтировать для копирования предыдущего содержимого. ! -h – выведет краткую справку по формату командной строки. Таким образом: // запустит скрипт с параметрами по умолчанию # aidecontrol // запустит скрипт с параметрами из конфигурационного // файла /tmp/abcd.conf # aidecontrol -c /tmp/abcd.conf // запустит скрипт со списком узлов из файла /tmp/nodes.lst // и чистым RW-носителем. # aidecontrol -l /tmp/nodes.lst -b
Если в командной строке был задан вывод краткой справки, то она выводится и скрипт завершает работу, иначе выполняется загрузка конфигурационного файла. После загрузки выполняется поиск вспомогательных программ. Он имеет такую особенность, что программы,
администрирование которые необходимы для работы, перечислены непосредственно в переменной wtools. Причем в этом списке не упоминается mkisofs, потому что burniso сам проверит ее наличие. Соответствующая метка в листинге WTOOLS. Эта часть показалась мне достойной более подробного рассмотрения, которое приведено ниже. wtools="bzip2 burniso" for tool in $tools do # Вот это список программ, без которых работа невозможна # (не считая SSH) locator=`which $tool` # # # #
Если which вернул пустую строку (а это происходит тогда, когда программа не найдена – ее физически нет или каталог не включен в PATH), то выдать сообщение и прекратить работу if [ -z $locator ]; then logline="Your system does not include $tool utility"; ↵ safe _ logger exit Þ done
Реализация поиска SSH в скрипте полностью аналогична реализации скрипта safecopy, описанного в [1]. Соответствующая метка в листинге SEARCHSSH. Дополнительно процесс поиска описан в комментариях в тексте скрипта. После того как проверено наличие всех необходимых программ, начинается разбор списка узлов. Этот разбор будет делаться в течение работы скрипта неоднократно, но особенности процесса его выполнения будут рассмотрены один раз. Разбор производится посредством простого чтения файла командой cat. Для построчной работы с файлом используется особенность работы с потоком стандартного ввода, которая заключается в том, что при чтении файла все прочитанное разбивается на «поля», где значение переменной IFS используется как разделитель. Если изменить ее значение, а потом прочитать файл, разбиение на «поля» будет выполняться в соответствии с новым значением IFS. Поскольку нам необходимо разобрать по записям (строкам), используется следующая конструкция: IFS=" "
Внимание! Значение «IFS=’’», перенесенное на соседнюю строчку, – это не ошибка! Таким образом IFS присваивается значение «конец строки» (\n), после чего организуется обычный цикл перебора всех записей файла. Если адресом компьютера является 127.0.0.1, то выполняется локальное копирование, то есть просто копирование базы AIDE в то место, откуда она впоследствии будет перенесена на съемный носитель. Соответствующая метка в листинге LOCALCOPY. Если же нет – предполагается удаленный компьютер и выполняется копирование с удаленного компьютера. Процесс получения списка файлов, подлежащих копированию, и собственно процесс копирования полностью аналогичны процессу, описанному в [1]. Процесс получения списка файлов здесь вырождается просто в еще одну проверку правильности настроек SSH, поскольку список файлов может содержать только один элемент (или не
№8, август 2005
Рисунок 2. Блок-схема скрипта AIDEcontrol
содержать ни одного, что будет указывать на ошибку). Соответствующая метка в листинге RMTCOPY. Если при запуске скрипта не было указано, что установлен чистый носитель, то RW-диск монтируется и его содержимое копируется во временный каталог, создаваемый в корневом каталоге системы. Соответствующая метка в листниге MNTRWDISK. Особенности монтирования съемных носителей состоят в том, что их наличие проверяется в бесконечном цикле
51
администрирование до тех пор, пока носитель не будет установлен и подключен. Сделано так потому, что на первом этапе базы не копируются, а переносятся на «мастер» и при отмене и повторном запуске скрипта базы не будут найдены. Поэтому лучше разобраться с причиной невозможности смонтировать диск (а это, как правило, банальная причина – опущен ключ -b при установке чистого диска, отсутствует или неверно указана точка монтирования и т. д) и попытаться смонтировать его повторно. После каждой безуспешной попытки смонтировать диск программа спрашивает, не желаем ли мы пропустить попытку монтирования диска. Если согласиться с ней и монтирование диска пропустить, то диск будет помечен как чистый, чтение с него выполняться не будет, все его предыдущее содержимое будет перезаписано. Если RW-диск успешно смонтирован, то происходит реорганизация его содержимого – файлы, поколение которых превышает максимально хранимое поколение, будут удалены, остальные переименованы в следующее поколение. Процедура последовательного переименования файлов (filename.0.ext → filename.1.ext → filename.2.ext и т. д.) будет описана несколько более подробно. Метка процедуры в листинге – RENAME, метка самой процедуры реорганизации – RWREORDER. shiftÞles() { # Получаем список файлов в каталоге lÞles=`ls -1` # Обрабатываем по одному элементу списка до тех пор, # пока он не пуст for lÞle in $lÞles do # Выбираем номер поколения (указываем awk, что разделителем # полей является точка, и печатаем второе поле) gener=`echo $lÞle | awk 'BEGIN {FS="."} {print $2}'` # Дополнительная защита – если в качестве номера поколения # выбрали «bz2», значит в каталоге находится файл Þlename.bz2, # который не переименован из-за какой-либо ошибки. # Корректируем эту ситуацию, подразумевая нулевое # (самое последнее) поколение if [ $gener = "bz2" ]; then logline="Invalid database Þle name $lÞle, assumed ↵ zero generation"; safe _ logger gener=0 mv $adbnam.bz2 $adbnam.$gener.bz2 Þ # Если номер поколения равен максимально хранимому # поколению, этот файл удаляется. Иначе вычисляется # следующий номер и файл переименовывается. if [ $gener -eq $abmax ]; then rm -f $adbnam.$gener.bz2 else ngener=$(($gener+1)) mv $adbnam.$gener.bz2 $adbnam.$ngener.bz2 Þ done }
В случае когда выполнялась установка чистого носителя, то копировать нечего и просто создается пустой каталог для копирования в него последнего поколения баз. if [ $blank = "no" ]; then shiftÞles Þ cp $ringdir/$hostname/$adbnam.bz2 ./$adbnam.0.bz2
После этого выполняется запись нового содержимого RW-диска. Особенностью записи нового образа с пол-
52
ным количеством поколений баз является использование скрипта burniso. Этот скрипт был написан для автоматизации задачи «взять все файлы, лежащие в определенном месте и записать их на RW, предварительно его почистив». Для создания образа burniso использует mkisofs, а для записи – cdrecord. Скрипт имеет собственный конфигурационный файл burniso.conf, синтаксис которого полностью аналогичен синтаксису aidecontrol.conf. В нем можно указать три переменных: workdir – каталог, в котором будет создаваться образ для последуюшей записи, devname – имя устройства для записи дисков и sourcedir – каталог, из которого будут браться файлы для записи на RW. Имя устройства задается в формате cdrecord в виде «bus,target.lun», например devname=«2,1,0». Внимание! Приведенные выше значения являются примером использования. На вашей системе они будут отличаться! Получить значения, которые необходимо подставить сюда, можно командой: # camcontrol devlist <SEAGATE DAT 9SP40-000 9030> < DVD-E616P2 1.03> <TEAC CD-W58E 1.0A>
at scbus0 target 6 lun 0 (sa0,pass0) at scbus2 target 0 lun 0 (pass1,cd0) at scbus2 target 1 lun 0 (pass2,cd1)
В данном случае использовалось устройство TEAC CD-W58E (2,1,0). Более подробную информацию о возможностях cdrecord см. man cdrecord. Запись диска может идти достаточно долго, перед началом записи cdrecord выводит большое количество информации о приводе, о диске, на который будет идти запись, о режимах работы... Ход выполнения записи отображается на консоли в виде: Starting to write CD/DVD at speed 8 in real TAO mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... Starting new track at sector: 0 Track 01: 6 of 6 MB written (fifo 100%) [buf 98%] 8.2x. Track 01: Total bytes read/written: 6391808/6391808 (3121 sectors). Writing time: 9.625s Average write speed 4.3x. Min drive buffer fill was 98% Fixating... Fixating time: 31.892s cdrecord: fifo had 101 puts and 101 gets. cdrecord: fifo was 0 times empty and 27 times full, min fill was 95%.
После записи диска со всеми поколениями копий временный каталог, в котором создавался образ для записи на RW-диск, удаляется. Последней фазой работы скрипта является перенос на Flash последней копии баз по всем узлам. Для этого сначала монтируется Flash. Монтирование происходит аналогично монтированию RW-диска – в бесконечном цикле. Ваша система должна быть уже настроена на автоматическое монтирование Flash при ее установке. О том, как это сделать, написано в разделе «Настраиваем систему». Вполне возможно, что /sbin/mount не будет успевать отработать монтирование устройства в FreeBSD 5.x, поскольку файлы устройств здесь создаются динамически, а devfs имеет некоторое время срабатывания. В особенности это проявляется на старых Flash 1.1 типа Seitek BAR – требуемая задержка может достигать двух секунд. Для избежа-
администрирование ния этого был разработан скрипт mountflash, приведенный в Приложении 3 (см. www.samag.ru, раздел «Исходный код»). Скрипт может запускаться как вручную, так и через /etc/ usbd.conf. В последнем случае строка attach должна иметь следующий вид: attach "sh -c '/usr/local/bin/mountßash /mount/point'"
где /mount/point – точка монтирования Flash. По умолчанию точка монтирования – /mnt/umass. Метка монтирования Flash в листинге – MNTFLASH. В очередной раз выполняется разбор файла описания узлов и по одному узлу за один проход выполняется копирование файлов из соответствующего каталога на мастеркомпьютере в соответствующий каталог на Flash. Если копирование файла прошло успешно, файл удаляется с мастер-компьютера. Метка в листинге – FLASHCOPY. Последней задачей скрипта является размонтирование Flash и останов устройства. Эта часть будет рассмотрена более подробно ниже по тексту. # /dev/da0s1 mpdev=`mount | grep -e "$usbdevmp " | awk ↵ '{print substr($1,6,3)}'` # Размонтировать Flash umount $usbdevmp status=$? # Проверить статус размонтирования и выдать сообщение, # если неудачно if [ $status -ne 0 ]; then logline="USB Flashdrive unmounting on device $usbdev ↵ failed, return code is $status"; safe _ logger else logline="USB Flashdrive was succesfully unmounted ↵ after updating content"; safe _ logger # # # #
Найти устройство, на которое смонтировалась Flash. Устройство находится поиском в выводе команды camcontrol devlist строки «(<имя _ устройства», например «(da0» umdrive=`camcontrol devlist | grep -e "($mpdev"`
# Выбрать BUS. Ищется строка «scbusX», потом берется # подстрока с шестого символа от места, где найдена строка umbus=`echo $umdrive | awk ↵ '{print substr($0,index($0,"scbus"),6)}'` umdig=`echo $umbus | awk '{print substr($1,6)}'` # Так же ищется target и lun. target берется через 7 # ("target ") символов от строки, lun берется через 4 # ("lun ") символа от строки umtarget=`echo $umdrive | awk ↵ '{print substr($0,index($0,"target") + 7,1)}'` umlun=`echo $umdrive | awk ↵ '{print substr($0,index($0,"lun") + 4,1)}'` # Выдать команду останова устройства (она погасит # индикатор готовности на Flash, за исключением USB 1.1) camcontrol eject $umdig:$umtarget:$umlun Þ
Возможные ошибки Если скрипт работает не так, как ожидается, то, возможно, имеет место ошибка в настройке SSH. Это очень просто проверить – достаточно с консоли мастер-компьютера набрать: # su aide > ssh remotebox
где remotebox – имя любого компьютера, с которого долж-
№8, август 2005
ны копироваться базы. Если сразу же открывается терминал удаленного компьютера – все нормально (при этом motd показываться не должно). Если же появляются запрос пароля на разблокирование ключа, запрос пароля на регистрацию на удаленном компьютере или какие-либо сообщения об ошибках – следует устранить ошибки и повторить. Все наиболее типичные ошибки, связанные с настройкой SSH для автоматического копирования файлов с использованием метода авторизации по публичному ключу, приведены в [1]. Наиболее часто встречающиеся ошибки, не связанные с настройками SSH: ! Неверно указанные пути к каталогам баз AIDE либо различные пути для различных компьютеров, из-за чего базы не могут быть скопированы. ! Неверно указана точка монтирования RW-диска, указанная точка монтирования не описана в /etc/fstab, RWдиск помещен не в тот привод (когда на мастер-компьютере более одного привода, а это не редкость). ! Неверно указана точка монтирования Flash, указанная точка монтирования не описана в /etc/fstab, для данного типа Flash не настроен /etc/usbd.conf. ! Система не поддерживает монтирование USB Flash. Наиболее уязвимым является процесс монтирования и размонтирования Flash, поскольку он требует значительного числа предварительных настроек. Для проверки успешного монтирования Flash следует запустить usbd в режиме отладки и посмотреть, не появляются ли сообщения об ошибках во время процесса монтирования Flash. Следует учесть, что даже для Flash одного типа могут быть разные release. Гарантированно одинаковыми являются только Flash из одной коробки.
Заключение Данный скрипт – инструмент, который поможет вам решить одну конкретную задачу. Несмотря на кажущуюся громоздкость, он относится к классу программ «настроил и забыл» – после двух-трех успешных циклов получения информации запуск скрипта можно было бы уже доверить младшему персоналу, если бы не крайняя важность копируемых данных. Проверять систему с использованием скопированных файлов можно либо с помощью скрипта AIDEstart, который будет описан в следующей статье, либо с загружаемой USB Flash, либо вручную, указывая путь к данным в конфигурационном файле или при запуске AIDE.
Литература и ссылки: 1. Ачилов Р. Копирование файлов в автоматическом режиме с множества компьютеров через SSH. – Журнал «Системный администратор», № 12, 2004 г. – 12-17 с. 2. http://www.granch.ru/~shelton/fileZ/burniso.tar.bz2. 3. http://www.freebsd.org/doc/en_US.ISO8859-1/books/ handbook/kernelconfig-building.html. 4. Домашняя страница проекта AIDE http://sourceforge.net/ projects/aide. 5. Домашняя страница автора проекта cdrecord (в числе набора других программ) – http://cdrecord.berlios.de/old/ private/cdrecord.html.
53
администрирование
SAP + MySQL = MaxDB
При выборе СУБД для проекта часто встаёт проблема выбора между низкой (часто нулевой) стоимостью открытых баз данных, таких как MySQL или PostgreSQL, и мощью и широтой возможностей «серьёзных» СУБД – Oracle, DB2, MS SQL. MaxDB от компании MySQL AB, наследница SAP DB – прекрасная альтернатива такому выбору. Это промышленная SAB-сертифицированная база данных, распространяемая под лицензией GPL.
КИРИЛЛ СУХОВ
В
последних числах мая 2003 года широкие массы IT-тружеников потрясла неожиданная новость. Солидная во всех отношениях компания SAP AG, один из мировых лидеров программного обеспечения для бизнеса, заявила о планах «стратегического сотрудничества» с MySQL AB – разработчиком самой распространённой открытой СУБД – MySQL. Данное сотрудничество касалось такого известного и заслужившего уважение продукта SAP, как SAP DB – промышленного сервера баз данных, стоящего в одном ряду с гигантами – MSSQL Server, Oracle и DB2. При этом, как заявлялось, написанием кода и управлением проектом будет заниматься
54
непосредственно MySQL AB, а внедрение системы и поддержку продукта компании планировали осуществлять совместно. Причиной такого шага SAP AG назвали желание как можно больше соответствовать запросам клиентов. Если в MySQL-сообществе известие утвердило сдержанный оптимизм, то в среде пользователей продуктов SAB реакция была, по крайней мере, неоднозначна. И в самом деле, что может предоставить MySQL SAP, кроме… кроме огромного количества пользователей СУБД! В самом деле, причиной такого шага могло послужить желание привлечь новых пользователей за счёт огромной аудитории MySQL
(если такие соображения и впрямь имели место, то, по крайней мере, на авторе этих строк план сработал). О будущем SAP DB также строились различные догадки. MySQL AB будет позиционировать SAP DB как «MySQL для взрослых», говорили также о том, что MySQL будет просто использовать код SAP DB для внедрения в свой продукт, а оригиналу суждено умереть. Прошло более двух лет, и пока, к счастью, события опровергают обе версии. Готовящаяся к выходу MySQL 5 явно не «содрана» со своей старшей сестры, а, в свою очередь, SAP DB, под новым именем MaxDB, живет и развивается. Несмотря на смену названия нумерация версий оста-
администрирование лась прежней: так, в начале 2004 года вышла MaxDB 7.5, а в июне 2005 года MaxDB 7.6, порадовавшая пользователей графическим инсталлятором (Installation Manager GUI), автоматическим обновлением статистических данных, автоматическим восстановлением неисправных индексов и новыми алгоритмами кэширования. В этом же году MySQL AB выпустили PHP- и Perl-драйверы для MaxDB, расширив функциональность для разработки приложений.
Что собой представляет MaxDB сегодня? Это полноценный, промышленный сервер баз данных, поддерживающий стандарт SQL 92 на «расширенном» уровне (хранимые процедуры, триггеры, последовательности, курсоры, роли и т. д.). В СУБД реализована поддержка UNICODE, поддержка кластерных систем, предусмотрена возможность изменения размера базы и создание резервной копии в режиме Online. Возможности MaxDB включают статистику для оптимизации стратегии построения запросов пользователем и выполнения их ядром СУБД. Программные интерфейсы, позволяющие работать с MaxDB, включают ODBC 3.5, C/C++ Precompiler (встроенный (Embedded) SQL), JDBC, версии 3.0, Perl DBI, Python, PHP и, разумеется, SQLCLI. Что ещё? Да в общем, немало, скажем, режим совместимости синтаксиса SQL СУБД. с Oracle 7. Помимо самой СУБД в состав дистрибутива включены все необходимые приложения для администрирования и
интерактивной работы с базой данных, речь о которых пойдёт ниже. В таблице 1 приведён список поддерживаемых в настоящее время платформ и архитектур. Он не так впечатляющ, как в случае с MySQL, но все наиболее распространённые конфигурации в нём присутствуют. Если операционная система, на которой вы планируете работать с MaxDB, в таблице отсутствует, не отчаивайтесь. Вся необходимая информация по портированию СУБД приведена здесь: http://www.sapdb.org/develop/sap_db_ cvs.htm и здесь: http://sapdb.2scale.net/ moin.cgi/DevelopingSapdb. Основные технические параметры MaxDB приведены в таблице 2. Как и остальные продукты от MySQL AB, MaxDB распространяется как под коммерческой лицензией, так и под
лицензией GPL, причём последний вариант СУБД ничем функционально от платной версии не отличается.
Инсталляция Требования к ресурсам у MaxDB по нынешним меркам довольно скромны. Они напрямую зависят от объёма базы данных. Самым критичным параметром для работающего сервера является оперативная память. Для размещения ядра необходимо около 48 Мб, для каждого активного соединения понадобятся еще примерно 10 Мб ОЗУ, что по сравнению с аналогами не выглядит непомерным. Размер занимаемого дискового пространства складывается из размера файлов дистрибутива MaxDB и размера прикладной базы данных. Суммарный размер исполняемых файлов MaxDB составляет от 280 Мб для 32-разряд-
Таблица 2. Основные технические параметры MaxDB
Таблица 1. Платформы и архитектуры, поддерживаемые MaxDB
№8, август 2005
55
администрирование ных систем до 700 Мб для 64-разрядных. Размер прикладной базы определяется пользователем и может в дальнейшем быть изменён без необходимости перезагрузки сервера. Размер занимаемой MaxDB оперативной памяти можно корректировать с учетом размера базы данных и количества одновременно обрабатываемых запросов. Все действия производились на компьютере под управлением операционной системы Windows XP Pro (SP-2), под музыку группы Аквариум. Сначала скачиваем архив с дистрибутивом MaxDB, который доступен по адресу: http://dev.mysql.com/downloads/ maxdb, затем графические инструменты для работы с СУБД – DBM GUI и SQL Studio, расположенные здесь: http://dev.mysql.com/downloads/maxdb/ clients.html. Распаковав дистрибутив, приступаем к установке. Есть несколько путей для инсталляции MaxDB. Прежде всего это стандартная инсталляция. Посредством консольной утилиты SDBINST. Она достаточно удобна и информативна (рис. 1). Всё, что требуется, выбрать режим ус-
тановки (я выбрал полный вариант) и размещение папок с данными, программами и ядра базы данных, а затем заинтересованно следить за ходом установки. По окончании программа порадует вас сообщением о необходимости перезагрузки (рис. 2). В новых версиях MaxDB доступен также вариант установки с веб-интерфейсом (требует дополнительного компонента maxdb-webtools, входящего в дистрибутив) и графический режим, на котором я и рекомендую остановиться. В отличие, например от инсталлятора MySQL, Installation Manager GUI совершенно не ограничивает возможности установки. Итак, запускаем утилиту SDBSETUP.exe (рис. 3). Если это не первая попытка установки, настоятельно советую с помощью соответствующего пункта меню снести результаты предыдущих экспериментов – различные версии СУБД и просто разные варианты установки могут конфликтовать. В начале инсталляции нам предлагают выбор конфигурации (рис. 4), причём первый пункт предполагает полную установку. Затем, после выбора режима, предлагается задать пароли привилегирован-
ным пользователям и параметры базы данных (рис. 5), после чего инсталлятор выведет подробную информацию выбранной конфигурации (рис. 6). Если внешне процесс вам напоминает установку СУБД Oracle – не смущайтесь, вопервых, у меня такие же ассоциации, а во-вторых, технологией java (против разумного применения которой я ничего не имею) там не пахнет – всё происходит довольно быстро (рис. 7). По окончании инсталляции будет предложено запустить Database Manage (рис. 8), и с этим серьёзным предложением лучше согласиться. Для использования графических и веб-инструментов их необходимо инсталлировать отдельно. На особенностях архитектуры и организации СУБД остановимся как-нибудь в другой раз, а сейчас рассмотрим основные инструменты администрирования и разработки.
Основные компоненты MaxDB На рис. 9 приведены основные компоненты MaxDB (состав которых определяется выбранным инсталляционным
Рисунок 1. Выбор инсталляционного профиля
Рисунок 2. Инсталляция завершена. Перегружаемся!
Рисунок 3. Installation Manager – начало работы
Рисунок 4. Берём всё!
56
администрирование профилем). Это инструменты инсталляции и администрирования СУБД, средства работы с данными и программные интерфейсы. Ниже речь пойдёт об наиболее значимых из них.
Администрирование (Database Manager) Менеджер базы данных доступен в MaxDB в трёх ипостасях, выполняющих совершенно одинаковый набор функций. Database Manager GUI (рис. 10) представляет собой удобный графический интерфейс, посредством которого можно осуществить любые действия, связанные с администрированием СУБД. В операционной системе MS Windows он вызывается из стартового меню («Start → Programs → MySQL MaxDB → Database Manager») или из командной строки командой dbmgui. На его примере хорошо видны основные возможности администрирования. В числе задач, решаемых с его помо-
щью, – создание и инициализация экземпляров баз данных (Instance, в терминах MaxDB), управление пользователями и операторами баз данных, установка прав доступа и параметров авторизации. С помощью DBM осуществляется запуск и остановка экземпляров БД, создание объектов БД, установка значений и индексов, управление сессиями. Кроме того – резервное копирование (рис. 11), восстановление данных из резервных копий, мониторинг, диагностика системы и многое другое. Даже обновление программ и системных таблиц удобно делать именно из этой среды. Database Manager CLI, в отличие от своего графического коллеги, доступен во всех поддерживаемых операционных системах. Работа с DBMCLI может быть легко автоматизирована с помощью администраторских сценариев. Функции менеджера доступны также из приложений, написанных на Java, Python, Perl, PHP, через соот-
ветствующие программные интерфейсы. Полный список команд доступен во входящей в дистрибутив документации, можно также вызвать dbmcli с параметром help (рис. 12). Web DBM входит в инструментарий Web Tools, в официальной документации декларируется, что эти утилиты, позволяющие управлять сервером через обычный браузер, корректно работают в следующих конфигурациях (см. таблицу 3). От себя могу добавить, что при использовании браузера Mozilla Firefox (1.0.4) проблем не возникало, а вот с Opera 7.0 были (это касается и остальных Web Tools).
Работа с данными (SQL Studio) Следующие три инструмента предназначены для доступа к данным и каталогам экземпляров MaxDB с использованием SQL-запросов. SQL Studio (GUI), имеющаяся только для ОС MS Windows, представляет со-
Рисунок 5. Первые пользователи
Рисунок 6. Всё готово! (ничего не напоминает?)
Рисунок 7. Процесс инсталляции
Рисунок 8. Опять перезагружаться...
№8, август 2005
57
администрирование
Рисунок 9. Компоненты MaxDB
Рисунок 10. Database Manager (GUI) – начало работы
Рисунок 11. Database Manager (GUI) – резервное копирование Рисунок 12. DBMCLI – работаем в консоли
Рисунок 13. SQL Studio (GUI) – пишем запрос
бой удобную среду разработки, с графическим интерфейсом (рис. 13). SQL Studio позволяет оперировать данными, создавать объекты базы данных и управлять ими. SQL Studio (GUI) имеет окно навигации, средства просмотра таблиц и, разумеется, средства управления SQL-кодом. Такое сочетание различных функций в одной оболочке позволяет комфортно решать такие задачи, как создание таблиц, индексов, пос-
58
Рисунок 14. Лог DBAnalyzer
ледовательностей, процедур и т. д., создание и исполнение SQL-запросов, непосредственное редактирование данных с помощью визуальных таблиц. Web SQL Studio основана на вебинтерфейсе, имеет сходные с графическим вариантом возможности по управлению данными. Меньший комфорт работы в ней компенсируется платформенной независимостью данного инструмента.
Преимущества консольного клиента SQLCLI заключаются в возможности использования его команд внешними сценариями, в том числе написанными на языках, имеющих интерфейс доступа к MaxDB.
Мониторинг (Database Analyzer) Крайне полезный инструмент, Database Analyzer (рис. 14), представляет собой полноценную экспертную сис-
администрирование тему для мониторинга MaxDB. Сущность его работы заключается в снятии и оценке данных о состоянии системы, через определённые интервалы времени (задаваемые настройками). Полученные сведения дифференцируются по классам – служебная информация, предупреждения (три различных уровня) и сообщения об ошибках. Все полученные сообщения проходят стандартную обработку и дешифровку. Более того, Database Analyzer берёт на себя существенную часть анализа информации, предлагая в стандартных ситуациях типовое разрешение возникших затруднений. Database Analyzer облегчает выявление ошибок в случае проблем с производительностью или пропускной способностью сервера MaxDB. Это помогает, например, выявить проблемы, относящиеся к конфигурации базы данных, синхронизации (блокировка, критические секции), оптимизации запросов базы данных (стратегия обработки данных, индексирование, оптимизация статистики) или конфигурации оборудования. Рекомендации Database Analyzer могут предложить создать добавочные индексы или повысить размер кэша БД.
Репликация (Synchronization Manager) Основное назначение этого инструмента – различные виды репликации данных MaxDB. Синхронизировать мобильные или удалённые экземпляры баз данных с центральным сервером БД – достаточно типовая задача, и Synchronization Manager достаточно хорошо с ней справляется. Репликация в MaxDB осуществляется централизованно, с выделением одного главного экземпляра БД, в котором записываются настройки репликации и произведённые изменения, коТаблица 3. Поддержка Web Tools для различных платформ и браузеров
Краткая история SAP DB 11 мая 1999 года известный разработчик ERP-систем, немецкая компания SAP AG, объявила о приобретении у фирмы Software AG неисключительных прав на СУБД Adabas D. Мотивы этого действия были очевидны, основной (более 75%) платформой для EPR-системы R/3, выпускаемой компанией была СУБД Oracle, продукт ближайшего конкурента на рынке ERP-систем. Таким образом, SAP AG практически прямо финансировала Oracle Applications, продукт, конкурировавший с их собственной разработкой – R/3. В 2000 году купленное решение оформилось в самостоятельный продукт – SAP DB и дальнейшие разработки, предлагаемые компанией (R/3 и открытая платформа mySAP) базировались на ней. 5 октября 2000 года SAP AG объявила выход СУБД под лицензией GPL, сделав её таким образом первой Open Source СУБД такого класса. Промышленная, многоплатформенная база данных, с открытым исходным кодом стала доступна разработчикам. торые затем объединяются в ходе очередной синхронизации. Сервер сообщений Synchronization Manager – это выделенный экземпляр MaxDB, который не зависит от мастера и клиентов. Он буферизирует все изменения до того, как их прохождение завершится. Таким образом, Synchronization Manager отделяет работоспособность мастера и клиентов от времени синхронизации. Узким местом является двунаправленная репликация – в этом случае существует вероятность возникновения конфликтов, которые необходимо разрешать вручную.
Импорт и экспорт данных (Loader) Последнее, о чём я хотел рассказать в этой статье, это утилита Loader, позволяющая импортировать данные приложений из файлов данных в экземпляр базы данных, или экспортировать данные из MaxDB в файлы. Благодаря поддержке большого количества различных форматов и структур записей, Loader часто может заменять спе-
№8, август 2005
Её версия, на тот момент была 7.2. За последующие года SAP DB стремительно развивалась, находя применение как самостоятельно, так и в качестве встроенной СУБД. СУБД развивалась, обрастая новыми возможностями, утилитами и интерфейсами. Вокруг неё складывалось сообщество разработчиков. В начале 2003 года SAP AG пошла ещё дальше, объявив Open Source свою уникальную разработку – технологию LiveCache (объектно-ориентированное расширение реляционной системы баз данных SAP DB, предоставляющее возможность более легкого и эффективного отображения структур и потоков данных), что ещё больше привлекло к ней внимание. В мае 2003 года SAP AG объявила о стратегическом партнёрстве с MySQL AB, и передачи последней СУБД (достигшей к тому времени версии 7.4) для разработки и продвижении решений на рынопк. С 31 марта 2004 года SAP полностью прекратила самостоятельное распространение SAB DB, ограничившись поддержкой своих старых партнёров. циализированные программы для загрузки и выгрузки данных. Благодаря прямому соединению с экземпляром MaxDB, Loader обычно помогает достичь существенного преимущества в производительности. Более того, Loader поддерживает перенос любых данных из одного экземпляра MaxDB в другой, даже в том случае, когда исполняется на различных архитектурах и операционных системах. По выбору администратора могут быть загружены отдельные таблицы, все таблицы, относящиеся к определенному пользователю БД, или даже полное содержание базы данных. В этой статье я ограничился обзором основных средств и возможностей MaxDB, совершенно не упомянув о таких вещах, как Standby/Hot Standby конфигурации, снимках (Snapshots), кэшировании, автоматическом распределении пространства и многом другом. Также я совершенно не касался вопросов архитектуры администрирования и разработки. Если вы проявите интерес, я продолжу рассказ о данной СУБД в дальнейшем.
59
безопасность
ПРОВОДИМ АУДИТ СИСТЕМЫ С ПОМОЩЬЮ SNARE
Полноценный контроль за системными событиями является трудоемкой задачей, забирающей много времени и ресурсов. Тем не менее просмотр регистрационных записей журналов позволяет получить наиболее полную информацию о работе системы и отдельных сервисов и использовать их для обнаружения вторжения.
СЕРГЕЙ ЯРЕМЧУК 60
безопасность ля защиты компьютерных систем в настоящее время разработано приличное количество разнообразного программного обеспечения, выполняющего какую-то определенную задачу. Антивирусы оберегают пользователей от вирусов, межсетевые экраны блокируют нежелательный трафик, целый класс систем обнаружения и остановки атак в той или иной мере противостоит действиям злоумышлеников. События, происходящие в последнее время, показывают пока только неэффективность традиционных средств защиты, не срабатывающих при появлении новых алгоритмов нападения. Пока действительно хорошо справляются со своей задачей инструменты, позволяющие определить уже произошедшее проникновение. Поэтому в настоящее время особым вниманием пользуются проактивные системы защиты, реагирующие на системные события, а не сравнивающие сигнатуры, сгенерированые специалистами по безопасности. Такие средства аудита контролируют различные системные выводы и в результате дают полную картину происшедшего на контролируемом узле. А именно: кто, когда обращался, к какому файлу, заходил по сети, модифицировал те или иные данные, т.е. в итоге позволяют получить полную картину происшедшего на контролируемом компьютере. Во всех операционных системах ведутся более или менее подробные логи, но большей частью на основные события (за исключением модуля BSM (Basic Security Module) в Solaris), чего в большинстве случаев достаточно. Но, например, в спецификациях выдвигаются дополнительные требования по регистрации событий для защищенных систем, начиная с класса С. К тому же такие возможности могут понадобиться в системах, предназначенных для обработки конфиденциальной информации. Естественно, отслеживая потенциально опасные события, можно предотвратить взлом и утечку информации, поэтому одним из требований к таким системам является быстрая реакция (под реакцией в данном случае подразумевается оповещение). Для централизованного сбора, хранения и обработки данных о событиях, происходящих на подчиненных системах, приветствуется отправка сообщений на удаленные системы. Австралийская фирма, занимающаяся безопасностью, InterSectAlliance (http://www.intersectalliance.com/projects/ Snare), в разработке SNARE – System iNtrusion Analysis and Reporting Environment основной упор сделала на регистрацию как можно большего количества событий. В том числе контролируются открытые сетевые соединения, чтение и запись в файлы и каталоги, модификация данных пользователя и групп, изменение программ. Система SNARE может быть сконфигурирована в двух вариантах. Первый позволяет обнаружить, когда какой-либо пользователь остановил ключевую программу, переключился к учетной записи администратора или установил файлы в системный каталог. В другом варианте использования SNARE контролирует непосредственно определенные системные вызовы, например, открывающие или переименовывающие файлы, chroot, reboot, mkdir, mknod и другие операции. Система реализована на нескольких платформах с учетом особеностей каждой, при этом она может использоваться как автономный инструмент анализа или быть удаленным сен-
№8, август 2005
сором для центрального сервера: Linux (обеспечивает аудит, принятый в системах класса C2 или CAPP), Windows, Solaris, Irix, AIX, IIS Web Server (используется для обработки файлов регистрации в реальном времени) и ISA Server. Распространяется SNARE под GNU Public License. В статье мы рассматриваем Linux-реализацию.
Как работает SNARE SNARE в варианте для Linux использует три компонента: ! Патч к ядру (в версиях 0.9.3 и выше), ранее для этих целей использовался динамически загружаемый модуль ядра auditmodule.o, который можно было установить без перекомпиляции ядра. Разработчики стремятся сделать систему контроля как можно более легкой и универсальной, способной работать как на маломощной рабочей станции, так и загруженном сервере, этим вызвано такое изменение в подходе. ! auditd – демон, являющийся front end к модулю (находится в пакете snare-core). ! snare – утилита графической конфигурации и просмотра отчетов (пакет snare-gui). Модуль проверки, работая в пространстве ядра, отлавливает критические системные вызовы вроде «execve» (выполнение команды), «open» (открыть файл), «mkdir» (создать каталог) и отправляет результат к подпрограмме, которая собирает всю информацию относительно процесса и пользователя, его запустившего или просто попытавшегося выполнить рассматриваемый системный вызов. Этот контрольный модуль сохраняет собранную информацию во временном буфере, который и считывается демоном auditd. Демон читает данные от системы контроля через устройство /proc/snare (ранее /proc/audit), преобразовывая двоичные контрольные данные в понятный текстовый формат, и отделяет информацию в ряд лексем, используя для отделения данных и улучшения дальнейшей обработки информации три разделителя: табуляцию, запятые и пробел. Получаем приблизительно следующее: grinder LinuxAudit objective,clear,Fri Dec 17 22:33:15 2004, The program /usr/bin/links been executed by the user leigh event,execve(), Fri Dec 17 22:33:15 2004 user,leigh(500),users(500),leigh(500),users(500) process,478,sh path,/usr/bin/links arguments,links return,0 sequence,11256
Кстати, реализация под Windows отличается работой всего двух компонентов: сервиса snarecore.exe и утилиты конфигурирования и получения отчетов snare.exe.
Установка Для установки SNARE под Linux понадобится два файла: snare-core и snare, а также патч к ядру (в настоящее время ведется работа по включению кода в основное ядро). Для некоторых дистрибутивов (RHEL, Fedora, Debian) на сайте доступны ссылки на прекомпилированые пакеты, в том числе и подготовленные ядра, которые и рекомендуется использовать. В целях эксперимента установим SNARE, используя исходные тексты. Скачиваем версию ядра, под которую имеются патчи и сам патч.
61
безопасность # cd /usr/src; wget -c http://www.kernel.org/pub/linux/ ↵ kernel/v2.6/linux-2.6.11.tar.gz # tar xzfv linux-2.6.11.tar.gz # wget -c http://www.intersectalliance.com/projects/ ↵ Snare/Download/snare-0.9.7-2.6.11.7.diff
Накладываем патч, конфигурируем ядро. # cd linux-2.6.11 # patch -p0 < snare-0.9.7-2.6.11.7.diff # make menuconÞg
И в «General Setup» включаем пункт «SNARE C2 Auditing». Далее компилируем как обычно и устанавливаем загрузчик. Затем скачиваем с сайта проекта SNARE архивы snare-core-0.9.7.tar.gz и snare-gui-0.9.6.tar.gz. # # # # # #
tar -xzvf snare-core-0.9.7.tar.gz cd snare-core-0.9.7 make clean make make install /etc/init.d/snare start
Starting /usr/sbin/auditd: SNARE audit daemon: version 0.97 starting up InterSect Alliance Pty Ltd http://www.intersectalliance.com/
! Auditing Control – метод контроля (Objectives или Kernel),
место, куда отправлять логи (локальный файл, на удаленный хост или оба варианта) и параметры настройки сети, необходимые для посылки логов (имя локального узла, IP-адрес или DNS-имя удаленного, UDP-порт на удаленном компьютере, куда будут посылаться сообщения). ! Kernel events – тип ревизии, может быть или события ядра, или настроенные пользователем фильтры. В данном пункте выбираются все те системные вызовы, которые необходимо отслеживать, при этом в журнал будут записаны все такие вызовы без какой-либо дополнительной фильтрации, при установке большего количества контролируемых вызовов журнал начнет быстро заполняться, причем, как правило, будет много лишней информации. Этот метод ревизии больше подходит для классического «C2»-стиля аудита, в котором все запросы должны быть зарегистрированы. ! Objectives (рис. 2) – более усовершенствованный метод аудита через определение объектов контроля и слежения за всеми изменениями состояния или обращения к ним.
Теперь необязательный графический интерфейс. # # # # # # # #
snare-gui-0.9.6.tar.gz cd snare-gui-0.9.6 ./autogen.sh make make install cp snare-icon.png /usr/share/pixmaps cp snare.desktop /usr/share/gnome/apps/System cp snare.desktop /usr/share/gnome/ximian/ ↵ Programs/Utilities/ # cp Snare.kdelnk /usr/share/applnk/System/
И запускаем, набрав snare в окне терминала или через меню KDE (в Gnome «Система → Snare → Event Logging»). Инсталляция под Windows заключается в получении одного файла SnareSetup.exe и запуске его обычным способом.
Конфигурация Все настройки демона хранятся в файле /etc/audit/audit. conf с вполне понятной структурой. Лучший способ изменения настроек – использование графической утилиты SNARE (рис. 1). После запуска которой заходим в пункт «Setup → Audit Configuration» и устанавливаем необходимые параметры во вкладках:
Рисунок 1. Графическая утилита позволяет просмотреть события в реальном времени и настроить систему
62
Рисунок 2. Просмотр объектов контроля и слежения
При этом возможно задание любых правил и любого количества объектов. Для этого нажимаем «Add an Objective» и заполняем значения пяти параметров. Среди которых индентификация отслеживаемого события (открытие, запись, считывание, удаление, модификация атрибутов, запуск или остановка программ, файлов или каталогов, открытые или разрешенные сетевые соединения), путь или имя объекта (возможно применение регулярных выражений), фильтр событий (удалось, не удалось или оба), пользователи и уровень опасности, который будет соответствовать при наступлении этого события (critical, priority, warning, information и clear). Первоначальная настройка подходит для большинства случаев, т.к. контролирует наиболее важные системные файлы вроде /etc/passwd, /etc/shadow, создание новых пользователей и групп, подключение по сети, использование su, изменение файлов и каталогов /sbin, /usr/sbin, /bin и /usr/bin, изменения в /etc и /var/log и пр. Например, два нижеприведенных правила зарегистрируют попытку доступа к файлу /etc/shadow любым пользователем, кроме root, при этом в зависимости от результата событию будет присвоен разный уровень опасности. Естественно, что если такая попытка будет успешной, то это свидетельствует о проблемах и такому событию необходимо присвоить наивысший уровень (основные параметры файла описаны в докумен-
безопасность те «Guide_to_SNARE_for_Linux.pdf» в разделе «Appendix C – Configuration File Description»). criticality=4 event=open(.*),mkdir,mknod,link,symlink ↵ return=Success user!=root match=^/etc/shadow$ criticality=2 event=open(.*),mkdir,mknod,link,symlink ↵ return=Failure user!=root match=^/etc/shadow$
Если оставить одну строку, то это снизит эффективность системы, и действительно опасное предупреждение может просто затеряться среди подобных сообщений. Для более тонкой настройки можно добавить индивидуальный контроль файлов, в которых прячутся rootkits (их список большой, вот некоторые: login, telnet, ftp, netstat, ifconfig, ls, ps, ssh, find, du, df, sync, reboot, halt и shutdown) и основные настроечные системные и сетевые файлы /etc/ resolv.conf, /etc/hosts, /etc/lilo.conf, /boot/grub/grub.conf, и пр. Список основных системных вызовов и их значения приведен в разделе «Appendix A – Events Audited». Единственное, о чем следует помнить, – это то, что при увеличении контролируемых параметров увеличивается и потребление системных ресурсов, на маломощных системах этот показатель может быть критичным. В Windows нет разделения на Objectives или Kernel, доступна только Audit Reporting Objectives, и в силу специфики системы отслеживаются другие события (logon, logoff, обращение к файлу или каталогу, остановка и запуск процесса, использование прав пользователя и администратора, изменение политики безопасности, перезагрузка, останов системы и некоторые другие). После внесения всех необходимых настроек необходимо перезапустить сервис «Activity → Apply and Restart Audit», после чего в главном окне программы будут выводиться все события, попадающие под установленные правила. Щелкнув дважды мышкой по представляющему интерес событию, можно получить дополнительную информацию. Используя «Prev» и «Next», можно двигаться впередназад, просматривая события. Все, на мой взгляд, просто и понятно. Просмотреть статус работы SNARE можно, выбрав пункт «Bид → Audit Status», при этом можно увидеть общее количество событий, обработанных модулем ядра без фильтрации, а также ID процесса демона, версию SNARE и активность демона.
Удаленное управление К сожалению, версия под Linux лишена на данный момент возможности удаленного управления при помощи веб-интерфейса. А вот запустив SNARE под Windows и набрав в строке браузера IP-адрес или имя компьютера, получаем не только возможность сконфигурировать его удаленно, но и информацию о пользователях и группах локальных и домена. Для подстраховки лучше зайти предварительно в пункт «Setup → Remote Control Configuration» и выставить IP-адрес, с которого можно удаленно заходить на компьютер и пароль для получения доступа, здесь же можно выбрать и порт, на котором работает сервер. Но в Linux можно просто зайти на удаленную систему при помощи SSH и запустить на ней клиента. Если на подконтрольной системе не используется X-Window, то перед запуском экспортируем переменную DISPLAY.
№8, август 2005
myguisystem# ssh auditedsystem .. auditedsystem# /bin/su [password] auditedsystem# export DISPLAY=myguisystem:80 auditedsystem# snare &
И еще одна полезная возможность заложена в SNARE – это отправка логов на удаленный узел по протоколу UDP, которая может помешать хакерам скрыть свое пребывание чисткой логов, хотя при контроле большого количества машин и параметров это может существенно забить сеть пакетами. Для этого в «Auditing Control» выбираем пункт «Log events to the networked host and a local file» и далее устанавливаем имя узла и порт (по умолчанию 6161), которому будут отправляться сообщения. На сервере, предназначенном для сбора всех логов, запускаем Perl-скрипт auditserver.pl (лежит в пакете snare-core), в котором нужно изменить переменную $ServerPort, установив нужное значение, совпадающее с таковым у клиентов, и каталог, куда будут складываться сообщения. Cервер в каталоге /var/log/audit создает отдельные файлы для каждого клиента вида YYYYMMDD-host. name.LinuxAudit. То есть в итоге получаем несколько файлов вида /var/log/audit/20050821-host.com.LinuxAudit. В дальнейшем эти файлы можно заархивировать для истории или распаковать при помощи скрипта extract.pl, который можно найти в документе «Guide to SNARE for Linux», потом просто запуская его вручную или при помощи cron. #cat /var/log/audit/20050821-host.com.LinuxAudit | ↵ ./extract.pl
На данный момент не поддерживается какая-либо защита при передаче файлов журналов, что дает возможность злоумышленику подделать логи либо провести элементарную DOS-атаку, поэтому пользоваться возможностью отправки логов в таком варианте необходимо осторожно и в защищенных сетях. Хотя стоит отметить, что отправка журналов на централизованый сервер разработчиками ориентируется больше при взаимодействии с SNARE Server (http:// www.intersectalliance.com/snareserver/index.html). Основное назначение которого сбор и анализ информации, поставляемой с различных систем. С его демо-версией можно ознакомиться на сайте проекта. Для централизованого сбора и отправки журналов с других систем с ним в паре будет работать SNARE Reflector, разработка которого ведется в настоящее время. Кстати, положительной стороной проекта является хорошая документация, помогающая разобраться в работе. Как видите, в отличие от средств контроля целостности системы, которые запускаются время от времени, SNARE позволяет контролировать происходящее практически в реальном времени, что существенно повышает общую безопасность. Также являются интересными сочетания вроде «IDS+SNARE» или «honeypots+SNARE». Первый вариант позволяет получить более подробную информацию об инциденте и может помочь при обработке последствий. Во втором случае предоставляется хорошая возможность изучить инструменты и действия взломщиков. Также подобные средства могут понадобиться тем, кому по роду деятельности нужна операционная система класса С2. Удачи.
63
безопасность
CD, НЕ ПОДВЛАСТНЫЙ КОПИРОВАНИЮ Копировщики лазерных дисков совершенствуются с каждым днем, но и разработчики защитных механизмов не дремлют, тем не менее новые защиты тут же ломаются. Почему? Вашему вниманию предлагаем обзор наиболее популярных ошибок и конструктивных просчетов с рекомендациями по их устранению, а также законченный алгоритм чрезвычайно стойкой защиты, не копируемой никаким копировщиком.
КРИС КАСПЕРСКИ
Х
акерс ка я муд рос ть глас ит: «взломать можно все, это только вопрос времени». Программный продукт, ориентированный на массовый рынок, такая ситуация вполне устраивает. Какой-то процент пользователей покупает программу, какой-то нет. Но для специализированных программных комплексов (расчет прецизионного литья или звездных спектров), количество пользователей которых измеряется какими-то тысячами, такой подход уже неприемлем. Потенциальный рынок настолько мал, что каждая нелегальная копия чувствуется весьма болезненно. Значит, надо защищать так, чтобы не взломали, но как? У нас две новости – хорошая и не очень. Надежные защиты все-таки существуют, но их разработка требует больших усилий и знания реалий. Это довольно заковыристая предметная область, и с одной лишь теоретической подготовкой в нее не войдешь. Тем не менее спрос рождает предложение, и автор статьи делится своим многолетним опытом по созданию стойких защитных комплексов.
Основные концепции защиты Главное свойство защиты – это надежность (не путать со стойкостью
64
ко взлому). Защита должна уверенно работать на всем спектре программно-аппаратного обеспечения с заранее непредсказуемыми свойствами. Антиотладочные приемы следует использовать с большой осторожностью или не использовать вообще, поскольку от них слишком много проблем. К тому же защита должна быть проста в реализации и отладке. Например, если часть функционала вынесена в микроконтроллер, смонтированный на отдельной печатной плате, подключаемой через PCI-шину или COM/ USB/LPT-порт, взлом становится не только нерентабельным, но и практически невозможным. Конечно, при условии, что микроконтроллер не позволяет считывать ПЗУ (некоторые приемы аппаратного взлома можно найти на страничке Сергея Скоробогатого: http://www.cl.cam.ac.uk/~sps32). Однако отладить такой комплекс будет намного сложнее, чем взломать, поэтому для практического применения он непригоден. В идеале защита вообще не должна требовать никакого «внешнего» оборудования, а это значит, что ее код заведомо будет доступен для анализа и модификации (см. рис. 1, 2). Защита не может отталкиваться ни от серийных номеров, ни от ключевых
файлов, поскольку всегда найдется пользователь, пожелавший разделить себя с миром, и, в общем-то, по-своему он будет прав. Черные списки «засвеченных» серийных номеров и прочие организационные меры, как показывает практика, недостаточно эффективны и со своей задачей не справляются. Также недопустимо привязываться к оборудованию, поскольку потребители очень не любят, когда ограничивают их свободу. К тому же, если стоимость защищенного комплекса составляет хотя бы 500$, хакеры могут клонировать весь компьютер целиком, особенно если это будут китайские хакеры (цены на оборудование в Азии намного ниже европейских). Наиболее популярным объектом привязки служит серийный номер жесткого диска и MAC-адрес сетевой карты, которые легко изменить (в частности, для жесткого диска можно воспользоваться комплексом PC3000 от ACE Laboratory – www.acelab. ru). Остальные же характеристики «железа» еще менее уникальны и в пределах одной партии практически идентичны друг другу. К тому же нельзя забывать про виртуальные машины (VMWare, Virtual PC и т. д.), привязка к которым лишена всякого смыс-
безопасность
Рисунок 1. Электронный ключ…
ла. Можно, конечно, распознать наличие виртуальной машины и отказаться работать под ней, только это не выход. Виртуальных машин существует огромное множество, и каждая из них детектируется по-своему, к тому же для большинства из них существуют специальные «патчи», предотвращающие детектирование. В общем, вложенные в защиту усилия окажутся нерентабельными. Привязываться можно только к носителю – дискете, лазерному или DVDдиску, карте FLASH-памяти и т. д. Это в наименьшей степени ущемляет права потребителей и практически не создает непреодолимых неудобств, к тому же качественно защищенный носитель чрезвычайно трудно скопировать. Существует множество хакерских групп, специализирующихся на взломе программного кода, но очень немногие разбираются в устройстве носителей на профессиональном уровне. Весь вопрос в том, какой носитель выбрать. Дискеты отбросим сразу. Их время уже прошло. DVD-диски только набирают силу, и требовать обязательно наличия DVD-привода на целевом компьютере по меньшей мере негуманно. То же самое относится и к FLASH-картам. Остается только CD. Вот к нему-то мы и будем привязываться.
Обзор популярных средств защиты Механизмы привязки к CD-ROM можно разделить на три большие группы. В первую (и наиболее древнюю) попадают защиты, внедряющие ключевую метку в служебные структуры данных, не копируемые штатными копировками. Это может быть и область предзазора первого трека (first pre-gap), и субканальные данные, также называемые данными подканалов (subchannel data), и т. д. Достоинства – высокая совмес-
№8, август 2005
Рисунок 2. …и его взлом путем считывания содержимого EEPROM под микроскопом с увеличением 500х
тимость с различными моделями приводов и предельная простота программной реализации. Недостатки – при подготовке диска к тиражированию придется долго объясняться с сотрудниками завода. Обычно им передают готовый диск или образ, содержащий только пользовательские данные (он же образ типа ISO9660, хотя это название не вполне корректно), здесь же требуется «сырой» (RAW) образ в формате 2352/96, который поддерживает далеко не всякое оборудование! Зачастую производитель игнорирует наши требования, и вопреки всем обещаниям и договорам с «конвейера» сходят диски, записанные стандартным образом, то есть без ключевых меток, а для заказчика это катастрофа! (Поверьте моему горькому опыту, это довольно часто встречается). Но это все равно напрасно, поскольку такие защиты уже давно копируются специализированными копировщиками. Исключение составляет ключевая метка в Q-подканале аудиотрека. Без спецоборудования она не копируется в принципе! Но это уже тема для другого разговора. Вторая группа защитных механизмов основана на нестандартных форматах диска (необычная длина сектора, нестандартные номера треков, искаженные заголовки и т. д.). Все они крайне конфликтны и отказываются идти на многих моделях приводов, к тому же при тиражировании дисков возникают очень серьезные проблемы, намного более серьезные, чем в первом случае. Как правило, требуется специальное (и весьма дорогостоящее!) оборудование, оправдывающее себя только на больших тиражах. Но эти вложения вряд ли окупятся, поскольку копировщики защищенных дисков уже давно справились с нестандартными форматами, так что не будем на них останавливаться и двинемся дальше.
Третью группу возглавляют защиты, привязывающиеся к физической структуре носителя. Их можно разделить на две подгруппы. Первая выделяет на диске некоторые более или менее уникальные характеристики, к которым, собственно, она и привязывается. Вторая же, не собираясь ждать милости от природы, самостоятельно формирует трудновоспроизводимые дефекты на диске. Возьмем известную защиту Laser Lock, которую легко опознать по наличию крошечной «дырки», проделанной лазером точно посередине спиральной дорожки (аналогичный способ был широко известен еще во времена дискет, причем их дырявили не только лазером, но еще и гвоздем). На первый взгляд тут должен образоваться BAD-сектор, однако практика показывает, что диск читается без проблем. А как же «дыра»? Все дело в кодах Рида-Соломона, корректирующей способности которых вполне хватает для исправления «дыры». Но если отключить коррекцию ошибок, то в секторе сразу же обнаружатся «дефективные» биты, причем начало разрушенной области будет соответствовать позиции дырки в секторе. Это если объяснять на пальцах. На самом деле все намного интереснее и сложнее. Структура хранения данных на лазерном диске такова, что физически смежные биты расположены на значительном удалении друг от друга, зачастую даже в различных секторах! Информация как бы «размазывается» вдоль спиральной дорожки, чтобы противодействовать царапинам и дефектам. Дело в том, что корректирующие коды Рида-Соломона отлично справляются с одиночными ошибками, но намного хуже – с групповыми. Чтобы ослабить влияние дефектов, пришлось прибегнуть к перемешиванию. А это значит, что «дыра» затрагивает не один сектор, а целую группу секто-
65
безопасность Детектирование VMWare Автору известны по меньшей мере три способа обнаружения VMWare. Во-первых, по оборудованию: виртуальные машины несут на своем борту довольно специфический набор железа, практически не встречающийся в живой природе. Это: ! видеокарта VMWare Inc [VMWare SVGA II] PCI Display Adapter; ! сетевая карта: Advanced Micro Devices [AMD] 79c970 [PCnet 32 LANCE] (rev 10); ! жесткие диски: VMWare Virtual IDE Hard Drive и VMWare SCSI Controller. Опросив конфигурацию оборудо-
вания, защищаемая программа сразу поймет, куда ее занесло. Во-вторых, виртуальные сетевые карты имеют довольно предсказуемый диапазон MAC-адресов, а именно: 00-05-69-xx-xx-xx, 00-0C-29-xx-xx-xx и 00-50-56-xx-xx-xx. Защите достаточно выполнить команду «arp -a», чтобы распознать хакерские планы. В-третьих, VMWare имеет коварный backdoor, оставленный разработчиками для служебных целей и управляемый через порт 5658h, при этом в регистре EAX должно содержатся «магическое» число 564D5868h. Ниже приведен фрагмент кода червя Agobot, определяющий версию VMWare:
ров! Это дает возможность распознавать «виртуальные» BAD-сектора, имитируемые копировщиками. Поразительно, но ни одна из коммерческих защит такой проверки не выполняет! Тем не менее копировщики защищенных дисков уже давно научились обходить Laser Lock, имитируя даже такие «тонкие» эффекты, как увеличение времени чтения «продырявленных» секторов и т. д., так что такой прием подходит только для борьбы со штатными копировщиками. К тому же очень трудно найти завод, располагающий соответствующим защитным оборудованием. Вообще-то в отсутствие лазера можно воспользоваться и обыкновенным маркером, однако он подходит только для крошечных тиражей (см. рис. 3). Остается последний тип защиты – измерение физических характеристик спиральной дорожки (также называемый снятием топологии). По такому принципу, в частности, работают CD-Cops, SecureROM 4x, StarForce и некоторые другие защиты. Методика отработанная, можно даже сказать вылизанная до зеркального блеска и неплохо себя зарекомендовавшая. Судите сами. В образ за-
Рисунок 3. Лазерный диск, защищенный Laser Lock («снимок» получен сканером HP 1200)
66
Листинг 1. Определение версии VMWare mov eax, 564D5868h ; VMWARE _ MAGIC mov ecx, 0Ah ; Get VMware version mov edx, 5658h ; VMWARE _ PORT in eax, dx
Для маскировки виртуальной машины Костей Кортчинским (Kostya Kortchinsky) был написан специальный патч, изменяющий идентификационные строки оборудования, MAC-адреса и магический номер backdoor (http://honeynet.rstack.org/ tools/vmpatch.c). Подробнее о способах детектирования виртуальных машин можно прочитать в подборке статей «Know your Enemy» (www.honeynet.org/misc/files/ papers.tar.gz).
щищенного диска не вносится никаких изменений, и для его тиражирования можно использовать абсолютно любое оборудование, в том числе и бытовой CD-R/RW-рекордер. Скопировать физическую структуру спиральной дорожки нереально (на CD-R/RW-дисках уже нанесена предварительная разметка, причем у каждого типа болванок своя), и хотя ее можно проэмулировать, от эмуляторов легко защититься (чуть позже мы покажем как). По правде говоря, существует возможность подбора болванки с похожей спиральной структурой, однако, если привязываться не к одной, а нескольким физическим характеристикам, вероятность подобрать «правильный» диск будет крайне мала. В принципе можно воспользоваться готовым защитным пакетом, но, во-первых, за него придется платить. Во-вторых, все вышеперечисленные защиты легко копируются в режиме эмуляции копировщиками Clone CD и Alcohol 120%. Исключение составляет StarForce Professional Edition, непосредственно скопировать который еще никому не удалось, однако (и это в третьих!) защита слишком агрессивно вгрызается в операционную систему, вызывая множество проблем у легальных пользователей. Разработчики характеризуют себя как людей с хакерским прошлым, сильных в системном программировании. Что касается прошлого – с этим можно согласиться. Операционную систему они знают лучше, чем свой задний двор. Но вот программировать умеют едва ли. Программирование – это в первую очередь проектирование. А проектирование – это учет рисков. Никакой конструктор не позволит себе строить мост по непроверенным формулам или проводить на нем научные эксперименты, гадая, произойдет обрушение на этот раз или не произойдет. Программа, ориентированная на массовое применение, просто не может пользоваться недокументированными возможностями и прочими приемами нетрадиционного программирования (в народе именуемых хаками). У себя в заднем дворе делайте, что хотите, но вот пользователю требуется нормальный продукт. А давайте запрограммируем защиту самостоятельно!
безопасность Ядро измерителя структуры спиральной дорожки занимает всего несколько строк на Си. Вместе с обвязочным кодом выходит около десятка… Полный цикл разработки вместе с отладкой легко укладывается в пару недель. Так стоит ли за это платить?
Star-force своими руками Спиральная дорожка лазерных дисков очень похожа на грампластинку, только начинается не снаружи, а изнутри, наматываясь от центра к краю. Оптическая головка, удерживаемая в магнитном поле «звуковой катушки», движется на «салазках» поперек спиральной дорожки. Сама дорожка состоит из секторов с данными и каналов подкода. Номера секторов находятся как в заголовках самих секторов, так и в каналах подкода, «размазанных» вдоль спиральной дорожки. Для грубой наводки на требуемый сектор используются салазки и каналы подкода, а для точной – отклонение в магнитном поле и секторные заголовки. Просто взять и измерить структуру спиральной дорожки нельзя, но можно сделать вот что: допустим, головка считывает сектор X, а следом за ним сектор Y. Если угол XOY, образованный центром (O) диска, секторами X и Y составляет порядка ~15 град., а сами сектора расположены на соседних витках спирали, то приводу достаточно всего лишь немного отклонить головку и через мгновение сектор Y сам падает в руки, как перезревшее яблоко – диск ведь вращается! Если же угол XOY составляет менее ~15 град., тогда за время перемещения головки сектор Y уже «уплывет» и приводу придется ждать целый оборот лазерного диска, пока он не достигнет оптической головки (см. рис. 4)! Замеряя время чтения различных пар секторов, мы можем приблизительно определить их взаимное расположение на спиральной дорожке. У каждой партии диска для заданных секторов X и Y оно будет своим (ведь степень «закрутки» спирали неодинакова и варьируется от одного производителя к другому). Чтобы побороть упреждающее считывание (которым «страдают» многие приводы), защита должна читать сектора в порядке убывания их LBAадресов. Также она должна измерять скорость вращения привода, чтобы, во-первых, определить постоянство временных замеров (пляшут ли они как пьяные человечки или нет), а во-вторых, скорректировать формулу для вычисления угла, поскольку, чем быстрее вращается диск, тем скорее «уплывает» сектор.
Исходный текст «измеряющей» программы приведен ниже: Листинг 2. Макет программы sf.c для снятия топологий //-[чтение сектора с диска]--------------------------------// ARG: // CD указатель на строку с именем привода // (например, "TEAC"), адрес на ASPI-шине // (например, "1.1") или имя диска("\\.\G:"); // первые два варианта работают через ASPI, // последний через SPTI; // // buf указатель на буфер SECROR _ SIZE*2 // // sector номер сектора в LBA-формате // // RETURN: // 0 успешно // -1 ошибка read _ from _ cd(char *CD, unsigned char *buf, long sector) { int stat; stat=cd _ raw _ sector _ read(CD, buf, SECTOR _ SIZE, ↵ sector, ONE _ SECTOR, W _ USER _ DATA); if (stat == SCSI _ OK) return 0; return -1; } //-[чтение TSC-счетчика]-----------------------------------unsigned int A() { _ _ asm{ _ emit 0xF ; RDTSC _ emit 0x31 } } #deÞne argCD
v[1]
// КОНФИГУРАЦИЯ //----------------------------------------------------------// номер первой точки измерения (LBA-адрес) // данная утилита измеряет топологию только по одной // точке, что не есть хорошо, т.к. легко подобрать похожий // диск, для уверенности следует выбрать несколько точек: // в начале, середине и конце диска #deÞne _ CFG _ BGN _ SEC _ 17699 // количество секторов для измерения // должно быть не меньше утроенного количества секторов // на виток в данной точке измерения // (см. _ CFG _ BGN _ SEC _ ) число витков спирали N // с поперечной плотностью D витков/мм от радиуса R1 // до радиуса R2 определяется формулой: N = (R2- R1) * D #deÞne _ CFG _ LEN _ SEC _ 0x669 // максимальный шаг приращения // в принципе должен быть равен удвоенному количеству // секторов на данном витке спирали, что увеличивает // точность измерений, но можно использовать и значение // _ CFG _ LEN _ SEC _ #deÞne _ CFG _ LEN _ DEL _ _ CFG _ LEN _ SEC _ // начальный шаг приращения (должен быть // по возможности мал) #deÞne _ CFG _ BGN _ DEL _ 0x2 // приблизительное количество секторов на данном витке спирали // (в данной версии программы это значение мало на что влияет) #deÞne _ CFG _ xWHELL _ 27 // конечный сектор для проверки #deÞne _ END _ SEC _ ( _ CFG _ BGN _ SEC _ + _ CFG _ LEN _ SEC _ ) // конечный шаг #deÞne _ END _ DEL _ ( _ CFG _ BGN _ DEL _ + _ CFG _ LEN _ DEL _ ) // приращение шага #deÞne FB(b) (##b = (##b + 1) % _ END _ DEL _ );
Рисунок 4. Когда угол между секторами X и Y составляет ~15 град. при переходе на соседний виток, сектор Y сразу же «подлетает» к оптической головке (рисунок слева) при меньшем значении угла сектор Y успевает уплыть, и головка вынуждена ждать целый виток
№8, август 2005
// шапка цикла #deÞne FH(a,b) for (##a= _ END _ SEC _ , ↵ ##b= _ CFG _ BGN _ DEL _ ; ##a > _ CFG _ BGN _ SEC _ ; ↵ ##a-=##b) main(int c, char** v) {
67
безопасность int a, b; int x=0; int i=0; int A1, A2; unsigned char buf[SECTOR _ SIZE]; // проверка аргументов командной строки if (c < 2) { fprintf(stderr,"USAGE:sf.exe CD\n\n"); printf( " SCSI _ INQUITY via ASPI32\n"\ "-------------------------------------\n"); read _ from _ cd("?.?", buf,0); return 0; } // этап первый //---------------------------------------------------// читаем случайные сектора для разгона привода fprintf(stderr,"%s\n", _ TEXT _ SPINEUP _ ); for (a = 0; a < 0x69; a++) { read _ from _ cd(argCD, ↵ buf,rand()% _ END _ SEC _ ); fprintf(stderr,"\r%02d%%",a*100/0x69); } // этап второй //---------------------------------------------------// определяем количество секторов на дорожке // и стабильность вращения привода, алгоритм // определения количества секторов: читаем сектора // задом наперед, с циклически увеличивающимся // шагом, наименьшее значение шага, при котором // время чтения секторов будет минимальным, и будет // равно количеству секторов на данном витке спирали // (в данной версии не реализовано, поскольку // слишком громоздко и не наглядно) // // алгоритм определения стабильности: читаем сектора // с шагом, равным количеству секторов на данном // витке спирали, и оцениваем разброс; // если разброс будет слишком большим // (превышает 10%-15%), следует уменьшить скорость // привода (как это сделать, показано в CD.snail.c) fprintf(stderr,»\r%s\n», _ TEXT _ TEST _ ); for (a = _ END _ SEC _ ; a > _ CFG _ BGN _ SEC _ ; ↵ a-= _ CFG _ xWHELL _ ) { A1=A(&c);read _ from _ cd(argCD, ↵ buf,a);A2=A(&c); fprintf(stderr,"\r%02d%%",( _ END _ ↵ SEC _ -a)*100/ _ CFG _ LEN _ SEC _ ); } // этап третий (важнейший!) //---------------------------------------------------// производим, собственно, измерения // (внимание: сюда еще необходимо добавить // «сглаживание» полученных данных) fprintf(stderr,"\r%s\n", _ TEXT _ ANGLE _ ); // выводим шапку таблицы printf("delta:"); FH(a,b) { printf("\t%d",a); ↵ FB(b); } printf("\ntime:"); // измеряем и тут же выводим результаты FH(a,b) { A1=A(&c); read _ from _ cd("TEAC", ↵ buf,a); A2=A(&c); printf("\t%d",(A2-A1)/100); fprintf(stderr,"\r%02d%%",( _ END _ ↵ SEC _ -a)*100/ _ CFG _ LEN _ SEC _ ); FB(b); } printf("\n");
}
// всему конец fprintf(stderr,"\r%s\n", _ TEXT _ END _ ); return 0;
Программа использует библиотечку SCSIlib, разработанную автором для низкоуровневого управления приводами с прикладного уровня. Ее можно бесплатно скачать с моего ftp-сайта автора (cм. «nezumi ftp»).
Запуск программы При запуске без аргументов программа выдаст краткую справку по ключам, а при наличии ASPI-драйвера автома-
68
тически просканирует системную шину и выведет адреса и названия всех обнаруженных приводов. Это может выглядеть, например, так: Листинг 3. Результат запуска программы без ключей >sf.exe USAGE:sf.exe CD SCSI_INQUITY via ASPI32 ------------------------------------0.0 <-- ELBY DVD-ROM 1.0 (5) 1.0 <-- ST380011A 3.06 (0) 2.0 <-- IBM-DTLA-307015 TX2O (0) 2.1 <-- TEAC CD-W552E 1.09 (5) 3.0 <-- AXV CD/DVD-ROM 2.2a (5) 3.1 <-- AXV CD/DVD-ROM 2.2a (5) 3.2 <-- AXV CD/DVD-ROM 2.2a (5)
Ключ «СВ», отвечающий за выбор привода, задает не только сам привод, но и интерфейс взаимодействия. Если имя привода выглядит как название устройства (т.е. начинается с префикса «\\.\»), то управление будет осуществляться через интерфейс SPTI. Для этого вы должны иметь Windows NT/2000/XP и права администратора. Если имя выглядит как адрес устройства на шине или как часть идентификационной строки привода, то управление будет осуществляться через интерфейс ASPI, для работы через который необходимо установить ASPI-драйвер (его можно бесплатно скачать с сервера компании Adaptec – http:// www.adaptec.com). Например, «sf.exe TEAC» (или «sf.exe 2.1») заставляет программу работать с приводом TEAC (адрес на ASPI-шине – 2.1) через ASPI-интерфейс, а «sf.exe \\.\G:» – с приводом «G:» через SPTI-интерфейс. Программа выводит данные в форме таблицы, предназначенной для импорта в MSGraph, причем вывод оптимизирован для перенаправления в файл (на экране все выглядит кошмарно), поэтому правильный вызов выглядит примерно так: «sf.exe \\.\G: > C:\1.txt». По окончании работы программы запускаем MS Word, открываем меню «Вставка», там будет «Рисунок» и «Диаграмма». В меню «Правка» находим «Импорт», «Тип файлов» → «*.txt», «Формат данных» → «С разделителем», «Начать импорт» со строки 1, «Далее >>», «Символом разделителя является»: «[x] символ табуляции», «Далее >>», «Формат данных» → «Общий» и жмем кнопку «Готово». Далее действуем по своему вкусу, то есть по обстановке.
Cбор топологий, испытания защиты и обсуждение результатов Вставляем подопытный диск в привод (пусть это будет, например, диск, прилагаемый к журналу «Компьютер пресс» 2005/07, условно обозначенный нами как диск «А») и снимаем с него топологию (см. рис. 5). Мы получаем характерную «пилу», точки минимума и максимума которой указывают на то, что данная пара секторов лежит на одной прямой. Очевидно, что на других дисках те же самые сектора будут иметь совсем другой угол, поэтому минимумы и максимумы сместятся на некоторое расстояние. Берем диск Microsoft Visual Basic 2005 (обозначенный нами как «B»), прилагаемый к тому же самому журналу, и запускаем программу еще раз (см. рис. 6).
безопасность Полезный совет Перед снятием топологии скорость привода рекомендуется уменьшить хотя бы до 16x-24х. Как это сделать, показано в утилите CD.snail.c, исходный текст которой можно бесплатно скачать с ftp автора. Пилообразная кривая действительно сместилась приблизительно на половину периода. Так же слегка изменилась и амплитуда колебаний, но нас она не интересует. Будем отталкиваться не от абсолютных, а от относительных значений, т.е. от LBA-адресов «изломов» кривой (абсолютные значения находятся в прямой зависимости от «окружающей среды» и потому ненадежны). Учитывая, что положения максимумов/минимумов зависят не только от топологии диска, но еще и от скорости вращения привода, необходимо расширить доверительный интервал до нескольких секторов. А теперь возьмем диск с другого номера «Компьютер Пресс» (диск «C») и сравним его топологию с диском «A» (см. рис. 7). Топологии обоих дисков полностью совпадают! Это означает, что диски «Компьютер Пресс» штамповались на одном заводе, а диск с Visual Basic на другом! Любопытное наблюдение, не правда ли? С помощью этой программы мы можем не только защищаться от копирования, но и проводить интересные исследования (кстати, эта программа была специально написана мной по заказу американского полицейского управления, занимающегося борьбой с пиратством. Обычная история – продавец заказывает партию лицензионных дисков и затем перемешивает их с «пираткой». Как установить факт обмана? Вот тут-то структура спиральной дорожки и выручает!). Демонстрационная программа снимает топологию только в одной точке (на участке между адресами 27532 и 18082). Разумеется, это ненадежно и при желании можно подобрать диск с похожей топологией (для этого достаточно взять приблизительно 10 болванок от разных производителей). Для усиления защиты настоятельно рекомендуется снимать топологию по меньшей мере в трех точках – начале, конце и середине диска. В этом случае найти похожий диск будет намного труднее.
Рисунок 5. Топология диска «А»
Рисунок 6. Топология диска «B»
Защита от анализа Существует по меньшей мере два способа взлома: копирование диска специализированными копировщиками или анализ защитного кода с последующей модификацией (он же bit hack). Создать некопируемый диск это только полдела. Еще необходимо защитить свою программу от анализа. Обычно анализу противостоят шифровкой кода/данных, однако, это не слишком-то удачное решение, ведь перед выполнением программы ее все равно приходится расшифровывать. Хакеру остается всего лишь дождаться этого момента и снять дамп. Можно, конечно, расшифровывать программу по частям или использовать несколько независимых расшифровщиков, но трудоемкость разработки защиты в этом случае практически не отстает от сложности взлома. В последнее время большое распространение получил
№8, август 2005
Рисунок 7. Сравнение топологий дисков «A» и «C»
некрасивый, но убойный подход, основанный на генерации «мусорного кода», внедряемого в защищаемую программу. Похожая техника используется во многих полиморфных вирусах, из которых можно «выдрать» уже готовые «движки» (engine). Мусорный код чрезвычайно затрудняет анализ, делая его практически невозможным. Допустим, ключевая функция программы компилируется в тысячу машинных команд. Исходя из «крейсерской» скорости дизассемблирования 1 команда в секунду, хакер сможет «прочесть» (только прочесть! не проанализировать!) весь код
69
безопасность за ~15 минут, но после разбавления функции миллионом мусорных инструкций, чтение листинга потребует свыше 10 суток напряженной работы, а полный анализ растянется на долгие годы. Звучит прекрасно, но без подводных камней не обходится. Во-первых, если перестараться, то скорость программы упадет в разы, причем нужно учитывать, что далеко не у всех стоит Pentium-4, поэтому «замусоривать» можно только редко вызываемые функции. Во-вторых, мусорный код должен быть достаточно нетривиальным, чтобы его «мусорность» не бросалась в глаза. Использование XCHG EBX,EBX или MOV EAX,EAX легко отсекается анализаторами. В-третьих, в некоторых случаях анализ защитного алгоритма необязателен и хакер может взломать программу и так (см. «Защита от мониторов шины»), поэтому линия обороны должна быть хорошо продуманной и однородной на всем своем протяжении. Бронебойные ворота бесполезны, если вокруг нет стен. Еще лучше применять P-код, реализовав «виртуальную машину» и написав свой собственный интерпретатор. Поскольку программировать в P-коде очень непроизводительно и неудобно, рекомендуется реализовать транслятор, «пережевывающий» исходный текст, написанный на Паскале или Си, и выдающий последовательность инструкций Машины Тьюринга, Сетей Петри, Стрелки Пирса и т. д. Чем ниже уровень абстракции, тем лучше для нас и хуже для хакера. Программа, состоящая из нескольких сотен строк, превращается в десятки тысяч или даже миллионы инструкций Тьюринга, декомпиляторов с которой не существует! Как компромиссный вариант можно использовать Форт, транслирующий исходный текст в шитый код. Это легко (и с комфортом) программируется, быстро работает, но долго ломается. Тем не менее, трудоемкость взлома порядка на два ниже, чем у Машины Тьюринга или Стрелки Пирса.
Защита от эмуляторов Структуру спиральной дорожки невозможно скопировать, но легко проэмулировать. Вместе с копировщиками защищенных дисков, как правило, поставляются программыэмуляторы, создающие виртуальный CD-ROM/DVD привод. Копировщик проделывает ту же самую операцию, что и защита – снимает топологию с защищенного диска и передает ее эмулятору.
Ссылки по теме запутывания кода
! Анализ запутывающих преобразований программ: те-
оретическая статья, рассматривающая основные методы «замусоривания» кода и проблемы его «прополки» (на рус.): http://www.citforum.ru/security/articles/analysis. ! A Taxonomy of Obfuscating Transformations: еще одна статья, посвященная «замусориванию» кода с большим количеством примеров (на англ.): http://www.cs.arizona. edu/~collberg/Research/Publications/CollbergThomborson Low97a. ! Virtual Machine Design and Implementation in C/C++ by Bill Blunden: реализация виртуальных машин на Си/Си++ – отличная бумажная книга на англ., электронная версия, по-видимому, недоступна.
70
Можно ли этому противостоять? Разработчики StarForce использовали прямой доступ к IDE-контроллеру в обход всех установленных драйверов, в том числе и драйвераэмулятора. А как быть, если у пользователя установлен не IDE-привод? Тогда StarForce вынуждена работать через уже установленные драйвера. Чтобы обойти защиту, достаточно выдернуть шлейф со своего привода или отключить соответствующий канал IDE-контроллера на лету, и StarForce падет. Не очень-то сильная защита, да к тому же трудно реализуемая (см. рис. 8). Мы же пойдем другим путем. Если открыть стандарт по SCSI- или ATAPI-устройства (их черновые версии лежат на www.t10.org и www.t13.org соответственно), можно обнаружить десятки «мультимедийных» команд, поддерживаемых практически всеми современными приводами. В эмуляторах же реализована лишь малая часть. Поэтому, чтобы защититься от эмуляторов, достаточно задействовать хотя бы половину SCSI/ATAPI-команд (попутно это «убьет» мониторы шины и прочие анализаторы). Даже если последующие версии эмуляторов поумнеют и будут имитировать весь «лексикон» привода целиком, они навряд ли смогут воспроизвести все особенности каждой команды и их комбинаций. Впрочем, не будем забегать вперед. Эмуляторы совершенствуются медленно и качественных рывков с их стороны пока не ожидается.
Защита от мониторов шины Для взлома защиты не всегда требуется дизассемблировать код. Вместо этого можно запустить монитор шины для перехвата обмена программы с приводом. Анализируя последовательность вызовов SCSI/ATAPI команд, вполне реально разгадать алгоритм защиты, определив, к каким именно характеристикам диска она привязалась. Большой популярностью пользуется монитор Bus Hound, ознакомительную версию которого можно бесплатно скачать с сайта http://www.perisoft.net/bushound. Он не только позволяет перехватывать USB 1.0/2.0, SCSI/ATAPI/IDE/ SATA, FireWire, Bluetooth, Fibre Channel порты, но еще и отображает относительное и абсолютное время выполнения запросов, что существенно облегчает исследование защит, основанных на временных характеристиках. Наша защита никак не противодействует мониторам шины (Star-Force, кстати говоря, тоже), поэтому все команды видны как на ладони и алгоритм привязки становится понятным с первого взгляда (см. рис. 9). Как «ослепить» монитор? Можно, конечно, использовать прямой доступ к IDE-контроллеру или разнообразные антиотладочные (точнее, «анти-мониторные») приемы, только… все это сложно, потенциально конфликтно и вообще ненадежно. Лучше «разбавлять» наши команды большим количеством «мусорных» SCSI/ATAPI-команд, чтобы затеряться на их фоне. Алгоритм станет неочевидным и анализ потребует намного больше времени и усилий. Один нюанс: «мусорные» команды ни в коем случае нельзя генерировать на случайной основе, в противном случае хакер снимет несколько дампов, выделит в них постоянную часть, а все остальное отбросит за ненадобностью. А вот основные команды лучше выбирать случайным образом. В частности, для чтения сектора можно использо-
безопасность Полезные советы
! положите на ключевой диск файл с заманчивым назва-
Рисунок 8. Виртуальный диск Virtual Clone CD в «Моем компьютере»
Рисунок 9. Исследование защиты с помощью монитора шины
вать и READ 10/12, и READ CD и READ CD MSF, и некоторые другие.
Удаленный прожиг Ключевые лазерные диски хорошо подходят для «коробочного» ПО, но для программ, распространяемых преимущественно через Интернет, они создают множество трудностей. Рассылка дисков – это огромная головная боль, но ведь не передавать же лазерный диск по модему. А почему бы и нет? Современные технологии еще и не на такое способны! Пользователь скачивает клиентскую программу, которая просит вставить чистый CD-R-диск в пишущий привод, прожигает одну сессию, заполненную незначащими данными, снимает топологию и по криптографическому протоколу передает эту информацию серверу. Сервер «зашивает» топологию внутрь защищаемой программы и отсылает ее клиентcкой программе, которая либо записывает программу на диск, либо устанавливает на винчестер. Конечно, такая схема взаимодействия существенно ослабляет защищенность программы. Ведь во всей партии болванок структура спиральной дорожки одинакова и потому, оплатив только одну копию, нечестный пользователь сможет тиражировать ее чуть ли не в промышленном масштабе. Чтобы этого не произошло, следует использовать аддитивную защиту, комбинирующую привязку к топологии с нестандартным форматом диска, например. Конечно, нестандартный формат – плохая штука (и об этом мы уже го-
№8, август 2005
нием user_name.key и выполняйте над ним различные запутанные операции, это слегка умерит прыть хакера и остановит его на какое-то время; ! вносите на диск несколько принципиально различных ключевых меток, но проверяйте только часть из них, а часть – оставьте для последующих версий программы (или ее обновлений), тогда хакеру придется каждый раз проводить утомительные исследования, подолгу зависая над монитором шины, дизассемблером и отладчиком; ! помните, что даже тщательно оттестированная защита в силу некоторых причин может не сработать, «обругав» легального пользователя; поэтому необходимо использовать по меньшей мере три независимых защитных механизма, основанных на различных характеристиках носителя, и если срабатывают хотя бы два из них, проверка считается пройденной; в данной статье мы рассмотрели всего лишь один такой механизм, остальные – в следующий раз. ворили в начале статьи), но с некоторыми предосторожностями использовать его все-таки можно. Тем более, что прожиг на CD-R снимает проблему тиражирования – клиентская программа самостоятельно управляет пишущим приводом и может свободно использовать все нестандартные режимы, на которые он только способен. Большое количество разнообразных защитных приемов описано в моей книге «Техника защиты лазерных дисков от копирования», демонстрационную версию которой можно найти на моем ftp.
nezumi ftp Автор поднял экспериментальный ftp-сервер, раздающий свои авторские материалы: ! IP-адрес: 83.239.33.46; ! доменное имя: nezumi.org.ru; ! порт: 21 (стандартный), ! логин: WASM, ! пароль: не требуется; ! папка: /pub, ! канал: 500 Мб; ! приблизительное время работы: с 14:00 до 06:00, при возникновении проблем рекомендуется установить пассивный режим ftp-клиента.
Заключение Разработка собственных защит от копирования – это реальность. Забудьте о широко разрекламированных готовых пакетах. Всякая серийная защита притягивает внимание сотен тысяч хакеров со всего света, которые быстро находят более или менее универсальный способ взлома, такой, что им может воспользоваться даже простой обыватель. Стойкость несерийных защит (даже спроектированных непрофессионалами) зачастую оказывается намного выше, потому что никто не хочет с ними связываться. Единичный взлом себя не окупит! Надеюсь, что эта статья поможет вам избежать ошибок и разработать защиту своей мечты самостоятельно.
71
программирование
КОНТРОЛИРУЕМ И ОГРАНИЧИВАЕМ СИСТЕМНЫЕ ВЫЗОВЫ С ПОМОЩЬЮ SYSTRACE
АЛЕКСАНДР БАЙРАК Наверняка вы не раз задумывались о том, как именно работает та или иная используемая вами программа. Разобраться помогут исходные текcты программы. Но что делать, если они недоступны? Как всегда быть в курсе того, что происходит у вас в системе?
S
ystrace – инструмент для ограничения и контроля системных вызовов. Изначально systrace был написан для NetBSD, позже был портирован под OpenBSD, а в настоящий момент ведутся работы по переносу на Linux, FreeBSD и OpenDarwin. Любая программа в процессе свой работы использует системные вызовы. Что такое системный вызов? Его можно определить как некую функцию, которая позволяет вашей программе обращаться к ядру ОС для выполнения некого действия. В современных версиях UNIX-систем реализовано около 300 различных системных вызовов. И ес-
72
ли такие инструменты, как ktrace (kernel process tracing) и truss (tracing system call), позволяют нам выступать лишь в качестве наблюдателей, systrace позволяет нам вмешиваться в происходящее.
Пример использования Перейдем к практике. В качестве примера напишем простую программу: #include <stdio.h> void proc1(); int main()
программирование { printf("just a message\n"); mkdir(«test»); proc1(); } void proc1() { printf("just a dumb procedure\n"); }
Как ясно из исходного текста, наша подопытная программа выполняет следующие действия: ! Выводит на экран сообщение. ! Создает каталог «test». ! Передает управление процедуре «proc1». ! Процедура proc1 выводит на экран сообщение. Скомпилируем программу: #gcc -o proga proga.c
На первый взгляд при выполнении нашей программы используются два системных вызова: mkdir и write. Хотя логично предположить, что, перед тем как «что-то» «куда-то» записать с помощью write, это самое «куда-то» нужно сначала открыть, а после записи закрыть, а значит, задействованы системные вызовы open и close . Также не лишено смысла предположение, что используется еще один системный вызов – exit. Итого пять вызовов. Посмотрим, как обстоят дела на самом деле: #systrace -A /path/to/program/proga
Ключ -A указывает systrace автоматически создать политику для указанного исполняемого файла. Автоматический режим предполагает создание правил в режиме «разрешить все». После выполнения команды в домашнем каталоге пользователя появится подкаталог .systrace, в который будет помещен файл c правилами. Рассмотрим его: Policy: /home/01mer/labs/systr/proga, Emulation: netbsd netbsd-mmap: permit netbsd-fsread: filename eq “/etc/ld.so.conf” then permit netbsd-__fstat13: permit netbsd-close: permit netbsd-munmap: permit netbsd-fsread: filename eq “/lib/libc.so.12.114.1” then permit netbsd-__sysctl: permit netbsd-fsread: filename eq “/etc/mallic.conf” then permit netbsd-break: permit netbsd-ioctl: permit netbsd-write: permit netbsd-fswrite: filename eq “/home/01mer/labs/systr/test” then permit netbsd-exit: permit
Синтаксис правил достаточно прост: [системный вызов] [условие] [действие]
Мы видим, что в процессе исполнения нашей программы используется несколько больше системных вызовов, чем можно было бы предположить с самого начала. Рассмотрим полученные правила. Policy: /home/01mer/labs/systr/proga, Emulation: netbsd
Указывается, для какого бинарного файла политика описана ниже. Полный путь к исполняемому файлу нужен для
№8, август 2005
того, чтобы исключить возможность применения политики для файла с таким же именем, но располагающимся в другом месте. Emulation: netbsd показывает, что будет использоваться ABI ОС NetBSD. netbsd-mmap: permit
Как видно из названия, системному вызову mmap разрешено исполняться. Для позволения выполнения системного вызова используется действие – permit, для запрещения deny. netbsd-fsread: filename eq “/etc/ld.so.conf” then permit
Тут мы видим, что системному вызову fsread будет разрешено выполниться в том случае, если запрошенный им файл будет /etc/ld.so.conf. Стоп, скажет внимательный читатель, системного вызова fsread не существует! И будет абсолютно прав. По умолчанию в systrace применяется использование псевдонимов для системных вызовов. Например: fsread является псевдонимом для stat, lstat, readlink, access, open. Но при желании режим использования псевдонимов можно отключить. В дальнейшем комментировании всего файла конфигурации смысла не вижу – все должно быть понятно и без этого. Что ж, политика для нашей программы создана, давайте попробуем ее выполнить под чутким руководством systrace: #systrace -a /home/01mer/labs/systr/proga just a message just a dumb procedure
Как мы видим, все функции нашей программы выполнились. Предположим, что логика нашей программы изменилась, что будет происходить в этом случае? Давайте для примера изменим функцию proc1 в нашей программе. Для начала мы должны точно знать, что будем менять. Просто изменить пару строчек в исходном коде и перекомпилировать программу, конечно, можно, но я предлагаю более интересный подход. #objdump -d proga > proga.lst
Программа objdump показывает информацию из бинарных/объектных файлов. Ключ -d указывает, что файл нужно дисассемблировать. Вывод информации для удобства произведем в proga.lst В полученном листинге находим нашу процедуру proc1. 08048833 <proc1>: 8048833: 55 8048834: 89 e5 8048836: 83 ec 8048839: 83 ec 804883c: 68 16 8048841: e8 52 8048846: 83 c4 8048849: c9 804884a: c3 804884b: 90
08 0c 89 04 08 fc ff ff 10
mov sub sub push call add
push %ebp %esp,%ebp $0x8,%esp $0xc,%esp $0x8048916 8048498 <init_fallthru+0x2d> $0x10,%esp leave ret nop
Если не вдаваться в подробности, мы видим тут «подготовку» стека, выполнение вывода на экран текста, очищение стека и возврат в «основную» программу. Итого 25
73
программирование байт, которые мы должны изменить на что то свое. Негусто, но вполне хватит для классического shell-кода вызывающего /bin/sh, он занимает как раз 23 байта (не забывайте, что 2 байта нам нужны для возврата в «основную программу»). А это именно то, что нам нужно – используется системный вызов, описания которого нет в наших правилах. Читаем man 2 execve. Для запуска /bin/sh через execve мы должны написать следующие: execve("/bin/sh/",0,0);
Что можно свести к следующему коду на ассемблере: xorl pushl pushl pushl movl pushl pushl pushl pushl movb int
%eax,%eax %eax $0x68732f2f $0x6e69622f %esp,%ebx %eax %esp %ebx %eax $0x3b,%al $0x80
Все это можно представить в следующих опкодах: 31 50 68 68 89 50 54 53 50 b0 cd
c0 6e 2f 73 68 2f 2f 62 69 e3
3b 80
Вооружившись hex-редактором, открываем исполняемый файл с нашей программой и меняем содержимое proc1 на представленные выше опкоды. Само собой, нам нужно оставить команды возврата в «основную» программу. После успешного редактирования проверяем результат: #/home/01mer/labs/systr/proga Just a message #
Как вы видите, вместо вывода на экран «just a dumb procedure» у нас запустился /bin/sh. А теперь попробуем выполнить то же самое, но уже под контролем systrace: #systrace -a /home/01mer/labs/systr/proga Just a message Jul 11 16:53:25 darkthrone.net1 systrace: deny user: 01mer, prog: /home/01mer/labs/systr/proga, pid: 395(0)[0], policy: /home/01mer/labs/systr/proga, filters: 13, syscall: netbsd-execve(59), filename: /bin/sh, argv: #
в том, что мы запускаем. Во всех остальных случаях рекомендуется создавать правила в интерактивном режиме. Рассмотрим пример: #systrace -t /home/01mer/labs/systr/newproga
Ключ -t указывает, чтобы интерактивное создание правил проходило в текстовом режиме. Если у вас на машине установлены x-windows, вы можете воспользоваться xsystrace. /home/01mer/labs/systr/newproga, pid: 729(0)[0], policy: /home/01mer/labs/systr/newproga, filters: 0, syscall: netbsd-mmap(197), args: 32 Answer:
Тут systrace ожидает от нас ввода permit, в случае если мы желаем разрешить системный вызов или deny для запрета. Конечно, интерактивное создание правил – процесс достаточно трудоемкий и занимает много времени, но полученный результат того стоит. Вы будете точно знать, когда и какие системные вызовы использует программа.
Дополнительные «полезности» В синтаксисе правил вы можете использовать необязательные опции протоколирования. Например: netbsd-fsread: Þlename eq "/lib/libc.so.12.114.1" ↵ then permit log
параметр log указывает systrace протоколировать каждое обращение к указанному фильтру. По умолчанию протоколируются лишь попытки выполнить системные вызовы, о которых нет ни слова в правилах. Для протоколирования systrace использует syslogd. А это значит, что мы можем немного поправить /etc/syslog. conf, чтобы все сообщения от systrace размещались в отдельном файле. При желании даже можно написать маленький парсер для получаемых логов. Но это уже по желанию, все в ваших руках. Нельзя не отметить еще одну необязательную опцию – errorcode. С её помощью мы можем указать, какая ошибка будет возвращаться при обращении к запрещенному системному вызову. Например: netbsd-fswrite: Þlename eq "/some/where/Þle" ↵ then deny[EIO]
В данном случае при попытке записи в файл системному вызову будет возвращена ошибка – input/outpu error. Для ознакомления с полным списком errno кодов возврата вы можете прочитать man errno.
Заключение Как мы видим, попытка запустить модифицированную программу провалилась.
Автоматизируем создание правил Доверить автоматическое создание правил systrace допустимо только в том случае, когда есть уверенность на 99,9%
74
Мы рассмотрели простой пример использования systrace. Изложенных сведений вам будет достаточно и для создания более сложных собственных правил для различных программ. Применение политик ограничения системных вызовов для конкретных программ поможет вам существенно повысить степень защиты ОС в целом.
bugtraq Переполнение буфера в MySQL Программа: MySQL версии до 4.0.25, 4.1.13, 5.0.7-beta. Опасность: Низкая. Описание: Переполнение стека возможно в функции init_ syms() из-за недостаточной обработки входных данных при создании определенных пользователем функций. Злоумышленник может указать специально сформированное название функции, вызвать переполнение буфера и перезаписать участок памяти на системе. Удачная эксплуатация уязвимости позволит злоумышленнику выполнить произвольный код на целевой системе. URL производителя: www.mysql.com. Решение: Установите последнюю версию с сайта производителя.
Раскрытие информации и отказ в обслуживании в реализации Kerberos в Microsoft Windows Программа: Microsoft Windows 2000, XP, 2003. Опасность: Средняя. Описание: 1. Ошибка существует при обработке определенных Kerberos-сообщений и позволяет злоумышленнику вызвать отказ в обслуживании контроллера домена. Подробности уязвимости не раскрываются. 2. Ошибка при обработке PKINIT-транзакций может позволить злоумышленнику получить данные других пользователей с помощью атаки «Человек посредине». URL производителя: www.microsoft.com. Решение: Установите исправления от производителя.
Неавторизованный доступ в Cisco Clean Access API Программа: Cisco Clean Access API 3.3.0 до 3.3.9; 3.4.0 до 3.4.5; 3.5.0 до 3.5.3. Опасность: Высокая. Описание: CCA Application Program Interface (API) не требует авторизацию. Удаленный пользователь может вызвать API-метод, чтобы поменять роль пользователя, отключить пользователя или поменять информацию о сконфигурированном пользователе. URL производителя: www.cisco.com. Решение: Установите обновленную версию программы: http://www.cisco.com/warp/public/707/cisco-sa-20050817cca.shtml.
Обход ограничений режима defanged в Metasploit Framework Программа: Metasploit Framework версии до 2.4. Опасность: Высокая. Описание: Уязвимость существует из-за ошибки в функции StateToOptions() в msfweb, которая позволяет удаленному пользователю переопределить переменную окружения «_Defanged», тем самым обойти ограничения безопасности режима defanged и запустить проверки на уязвимости и эксплоиты на целевой системе. URL производителя: www.metasploit.com. Решение: Установите последнюю версию с сайта производителя.
№8, август 2005
Уязвимость форматной строки в ProFTPD Программа: ProFTPD версии до 1.3.0rc2. Опасность: Средняя. Описание: 1. Уязвимость форматной строки обнаружена при отображении сообщения об отключении, содержащее имя текущей директории. Злоумышленник может создать специально сформированное имя каталога и вызвать отказ в обслуживании или выполнить произвольный код на целевой системе. Для удачной эксплуатации имя директории должно содержать переменные: «%C», «%R» или «%U». 2. Уязвимость форматной строки обнаружена в модуле mod_sql при получении информации из базы данных. Злоумышленник может создать специально сформированные insert-запросы к БД и вызвать отказ в обслуживании или выполнить произвольный код на целевой системе. URL производителя: www.proftpd.org. Решение: Установите исправление с сайта производителя.
Удаление произвольных файлов в printd на Sun Solaris Программа: Sun Solaris 7, 8, 9, 10. Опасность: Низкая. Описание: Уязвимость существует в демоне printd. Удаленный пользователь может с помощью специально сформированного запроса удалить произвольный файлы на системе. Подробности уязвимости не сообщаются. URL производителя: www.sun.com. Решение: Установите исправления с сайта производителя.
Уязвимость форматной строки в nbSMTP-клиенте Программа: no-brainer SMTP версии до 1.00. Опасность: Высокая. Описание: Уязвимость форматной строки существует в функции log_msg(). Удаленный пользователь может с помощью специально сформированной строки выполнить произвольный код на целевой системе. URL производителя: www.nbsmtp.ferdyx.org. Решение: Установите последнюю версию с сайта производителя.
Скриптинг между приложениями в SPI Dynamics WebInspect Программа: SPI Dynamics WebInspect. Опасность: Низкая. Описание: Злоумышленник может создать специально сформированную веб-страницу и выполнить произвольный сценарий в браузере жертвы. Подробности в статье: XSS – WEB = Cross-Applications Scripting. URL производителя: www.spidynamics.com/products/ webinspect/index.html. Решение: Способов устранения уязвимости не существует в настоящее время.
Составил Александр Антипов
75
hardware
ИСПОЛЬЗУЕМ LLinux inuxBIOS BIOS НА СИСТЕМАХ VIA EPIA-M
АНТОН БОРИСОВ Почти каждый из вас в детстве играл в конструктор – собирал железную дорогу или машинки. По мере взросления у сильной половины человечества игрушки не исчезают, а только становятся более дорогими. В прошлом номере мы познакомились с историей развития LinuxBIOS-проекта. Сегодня мы вдохнем жизнь в barebone-систему на базе EPIA-M и LinuxBIOS.
Приготовления в аппаратной Что для этого потребуется? Аппаратная часть, которая представлена материнской платой VIA EPIA-M 10000, корпусом Morex Cubid 3677S, устройством сохранения FlashROM – RD1-PL производства IOSS. В качестве носителя информации используем обычный жесткий диск формата 3,5’, плотностью в 160 Гб (кто-то скажет: «А почему не 500 Гб?» – что ж, у меня не оказалось под рукой жесткого диска такого объема). Обратимся на этом этапе к техническим характеристикам сегодняшних компонентов. Материнская плата – в какой-то степени шедевр на сегодняшний день. Некоторое время назад компания VIA предложила форм-фактор для материнских плат mini-ITX – это миниатюризированный вариант материнских плат, всего-то 17x17 см. На таком пространстве уместился процессор C3/Nehemiah – разработка компании VIA, созданный на фундаменте достижений компаний, приобретенных не так давно самой VIA – это Cyrix и WinChip. Тем, кто заинтересовался историей развития этих процессоров, следует ознакомиться с материалами [1-3]. Как и на «взрослых» платах, у этого малыша есть северный и южный мосты, что означает, что есть PCI-слот, прав-
76
да, всего лишь один, 2 IDE-канала, FireWire-контроллер (кому-то повезет, если приобретет к такой системе FireWire-переносное устройство информации), 6 портов USB. То есть вы начинаете понимать, какой универсальный конструктор мы сегодня рассматриваем, не правда ли? Помимо «взрослости» данной платы на ней также есть ставшие уже обычным явлением интегрированные аудиои сетевой-контроллеры. Так как стандарт mini-ITX ориентируется на миниатюрность, то разработчикам пришлось также интегрировать и видео-контроллер. Стоит подчеркнуть наличие выхода S-Video и возможности построить звук в формате 5+1. Да, самое главное – процессор на этой модели имеет тактовую частоту в 1 ГГц. Не так чтобы и много, но, с другой стороны, и немало. Для процессора с такой частотой уже используются активные системы охлаждения, в то время как на более младших моделях в 800 МГц ограничились пассивным охлаждением, и поверьте, вполне хватает. Данного малыша, или правильнее сказать малышку, следует пристроить в хорошие руки, с хорошим питанием и экологией – все правильно, надо подобрать правильную «одежду» – корпус. Поэтому для малыша я выбрал «под-
hardware ростковый» корпус с внешним источником питания Morex Cubid 3677S. Его габариты предусматривают использование только slim-компонентов – CD/DVD-привода, HDD-накопителя и FDD-накопителя. К сожалению, от первого и последнего компонента пришлось отказаться, зато вместо них удалось поставить HDD 3,5’. Поначалу казалось, что уместить диск такого форм-фактора в столь тонком корпусе невозможно. Но на практике оказалось иначе. Внешний источник питания в 62 ватта мощностью подает на внутреннюю плату корпуса 12 вольт, которые преобразуются в дальнейшем в +12, +5 вольт. Стоит отметить, что получить 12 вольт можно и от бортовой системы автомобиля. Впрочем, область применения мини-систем формата mini-ITX заслуживает отдельного разговора. Скажу, что именно на базе EPIA построены некоторые автомобильные системы.
Сбереги себя сам Чтобы не получилось ситуации «Знал бы – соломинку подложил», придется приобрести или одолжить на некоторое время у знакомых технических специалистов специальное устройство сохранения FlashROM. Под устройством сохранения FlashROM подразумевается BIOS Savior – это некий симбиоз из 2 микросхем flash-памяти – одна из которых, оригинальная, находящаяся в PLCC-слоте, – микросхема, поставляющаяся в составе материнской платы. В ней находится PC BIOS – в нашем случае это AwardBIOS. Вторая микросхема – резервная, на которую записываются модификации PC BIOS. Таким образом, у нас получается вариант устройства с 2 чипами памяти, с помощью переключателя производится выбор, откуда делать «холодный» старт системы – или с оригинальной микросхемы с AwardBIOS, или с резервной, на которую мы будем записывать LinuxBIOS (альтернативу AwardBIOS). Устройство действительно необходимое, поэтому к его приобретению стоит отнестись с вниманием. При удачном запуске системы вы записываете в оригинальную микросхему LinuxBIOS и в дальшейшем можете прилепить на системный блок лейбл – «Designed for LinuxBIOS».
Тонкости охлаждения И последним аппаратным блоком сегодняшнего нашего конструктора идет жесткий диск. Я руководствовался при его выборе в первую очередь скоростью вращения шпинделя – главной характеристикой в конечном итоге был уровень шума. Жесткие диски со скоростью 5400 об/минуту, по всей видимости, становятся достоянием истории, поэтому вместо SAMSUNG SV1604N пришлось взять SAMSUNG SP1604N (скорость вращения шпинделя – 7200 об/минуту). Впрочем, разница в пару децибелов шума между этими винчестерами не особенно влияет на общий фон. Стоит приглядеться, как смонтирован жесткий диск на плате. Его пришлось повернуть с ног на голову в буквальном смысле и положить на радиаторы охлаждения северного моста (рис. 1). Отмечу, при закрытом корпусе кажется, что плата жесткого диска соприкасается с крышкой, на самом деле это не так, зазор все равно остается. Благодаря зазору, а также вентиляторам на процессоре и вентилятору на самом корпусе перегрева не происходит (рис. 2). Обращу ваше внимание, что вентиляторы идут с датчиками вращения
№8, август 2005
Рисунок 1. Жесткий диск лежит на радиаторах охлаждения
Рисунок 2. Расположение элементов охлаждения EPIA-M и дополнительный вентилятор на корпусе Morex Cubid 3677S
скорости. Однако на корпусном вентиляторе скорость в пределах 3000 об/минуту, что характеризует его как бесшумный, а вот вентилятор на процессоре пришлось заменить – идущий в составе материнской платы экземпляр обладает «бешеной» скоростью в 6 тыс. оборотов. Поэтому вентилятор был заменен на аналогичный корпусному. В итоге температура процессора в работе в рабочем режиме стала выше на 7-8 градусов, впрочем, не превысив допустимой нормы в 65 градусов Цельсия. Теперь соберем программные компоненты нашей системы. Это Linux-дистрибутив – Slackware Linux 10.0 [4]. Компоненты мониторинга температуры – lmsensors [5], i2c [6], hddtemp [7]. Компоненты для построения LinuxBIOS – сам LinuxBIOS [8]-[9], «полезная нагрузка» (payload) – etherboot [10], filo [11]. На каком именно дистрибутиве вы будете собирать, в конечном итоге не принципиально.
Следим за температурой Описывать установку и настройку системы я не буду. Сразу расскажу, как мониторить температурные режимы самой платы и жесткого диска. Если в вашем дистрибутиве используется ядро из серии 2.6, то озадачиваться интеграцией lmsensors и i2c в ядро, по-видимому, не стоит, т.к. по заявлениям разработчиков данные пакеты уже есть в составе ядра. Для тех же, кто работает на ядрах линейки 2.4,
77
hardware стоит прочитать в первую очередь README указанных пакетов, понять, по какому из 3 вариантов установки следует пойти – интеграция непосредственно в ядро и дальнейшая его пересборка, сборка в качестве отдельных модулей или половинчатая интеграция с ядром. Я выбрал вариант сборки в виде отдельных модулей. wget http://secure.netroedge.com/~lm78/archive/ ↵ i2c-2.9.1.tar.gz tar xzvf i2c-2.9.1.tar.gz cd i2c-2.9.1 su make && make install
Теперь убедимся, что температура жесткого диска в пределах нормы:
Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. |/dev/hda|SAMSUNG SP1604N|35|C|Connection closed by foreign host.
Добавим в /etc/rc.d/rc.local следующие строки для загрузки модулей нашей платы EPIA. # I2C adapter drivers modprobe i2c-viapro modprobe i2c-isa
Что же, 35 градусов по Цельсию – вполне допустимая рабочая температура. Подведем краткие итоги проделанной работы. Дистрибутив развернут, мониторинг температуры настроен, что позволяет нам удаленно по сети следить за температурным режимом. Осталось перевести рельсы на использование LinuxBIOS.
Полезная нагрузка
# I2C chip drivers modprobe eeprom modprobe vt1211 /usr/local/bin/sensors -s
Теперь данные о температурном режиме у нас под рукой. Запускаем: # /usr/local/bin/sensors
LinuxBIOS, который было бы уместнее называть FreeBIOS, является замещением проприетарного BIOS. С его помощью происходит первичная инициализация устройств в системе и затем передается управление на payload. Задача payload – загрузить ядро Linux либо по сети, либо с локального устройства. Нам в первую очередь интересно посмотреть на загрузку Slackware Linux с жесткого диска, поэтому в качестве payload выступит FILO – FIle Loader. Займемся подготовкой FILO. wget http://te.to/~ts1/Þlo/Þlo-0.4.2.tar.bz tar xjvf Þlo-0.4.2.tar.bz cd Þlo-0.4.2 make
eeprom-i2c-0-50 Adapter: SMBus Via Pro adapter at 0500 Memory type: DDR SDRAM DIMM Memory size (MB): 256
+1.89 +5.24 +13.15 +3.45 2) 2)
V) V) V) V)
ALARM ALARM
+60C) +40C)
Как видите, некоторые значения с датчиков, отмеченные подстрокой ALARM, не находятся в допустимых пределах. Очевидно, что формулы для этих значений, записанные в /etc/sensors.conf, не совсем верны, либо диапазон допустимых значений слишком узок. Предлагаю не рассматривать полученный результат слишком критически, ибо в дальнейших релизах этого программного обеспечения такие неточности будут исправлены. Приступим к настройке мониторинга температуры жесткого диска. wget http://www.guzu.net/linux/hddtemp-0.3-beta12.tar.bz2 tar xjvf hddtemp-0.3-beta12.tar.bz2 cd hddtemp-0.3-beta12 ./conÞgure --with-db-path=/etc/hddtemp.db ↵ --preÞx=/usr/local/hddtemp make && make install
78
/usr/local/hddtemp/sbin/hddtemp -d -q /dev/hda
# telnet 127.0.0.1 7634
wget http://secure.netroedge.com/~lm78/archive/ ↵ lm _ sensors-2.9.1.tar.gz tar xzvf lm _ sensors-2.9.1.tar.gz cd lm _ sensors-2.9.1 su make && make install
vt1211-isa-6000 Adapter: ISA adapter VCore1: +2.31 V (min = +1.79 V, max = +5V: +4.66 V (min = +4.73 V, max = +12V: +12.14 V (min = +10.77 V, max = +3.3V: +3.25 V (min = +3.13 V, max = fan1: 3343 RPM (min = 3006 RPM, div = fan2: 0 RPM (min = 3006 RPM, div = ERROR: Can't get TEMP2 data! Proc Temp: +44.1C (high = +65C, hyst = MB2 Temp: -28.4C (high = +45C, hyst = vid: +1.850 V (VRM Version 9.1)
Добавляем в /etc/rc.d/rc.local автозагрузку службы мониторинга:
Отредактируем файл Config, заменив содержимое строки AUTOBOOT_FILE на: AUTOBOOT _ FILE = "hda3:/boot/vmlinuz ↵ oot=/dev/hda3 console=tty0 console=ttyS0,115200" make cp Þlo.elf ~/src/payloads/Þlo.m2.elf
ELF-образ нашего payload положили в специально отведенное место и назвали как filo.m2.elf. С сайта LinuxBIOS возьмем обе ветки, и стабильную, известную под названием V1, и текущую, которая на данный момент находится в разработке, версия V2. Как только изменения для рабочей версии будут завершены и оттестированы, она также станет стабильной. Принципиальные отличия между версиями все-таки есть – это наличие только во второй версии поддержки ACPI. Изменен синтаксис файла конфигурации. И самое главное, в новой версии поменялся каркас построения системного ROM-файла. Считается, что он стал удобнее для добавления нового аппаратного обеспечения. wget http://snapshop.linuxbios.org/ ↵ freebios--devel--1.0--base-0.tar.bz2 tar xjvf freebios--devel--1.0--base-0.tar.bz2 cd freebios
hardware Предварительно подготовим VIDEOROM от интегрированного видеоадаптера на плате: su dd if=/dev/mem of=vgabios.bin skip=1536 count=128
Предполагается, что компоновка и компилирование происходит на EPIA-M-системе. Получился файл размером в 64 Кб. Он нам понадобится в дальнейшем при подготовке системного образа. В файле freebios/HOWTO/EPIA хранится инструкция по компоновке LinuxBIOS для EPIA-систем. Воспользуемся ею. Во-первых, нам потребуется файл конфигурации, в котором указывается для какой системы подготавливается системный ROM-файл, «полезная нагрузка» (так называемая секция payload), параметры для порта RS232 и т. п. Приведу файл, который используется у меня: # # LinuxBIOS conÞg Þle for: VIA epia-m mini-itx # target /home/anthony/epia-m # via epia mainboard via/epia-m # Enable Serial Console for debugging option SERIAL _ CONSOLE=1 #option SERIAL _ POST=1 option TTYS0 _ BAUD=115200 # for VGA support (optional) option HAVE _ FRAMEBUFFER=0 option CONFIG _ VGABIOS=1 option CONFIG _ REALMODE _ IDT=1 dir src/bioscall option CONFIG _ PCIBIOS=1 option VGABIOS _ START=0xfffe0000 addaction romimage dd if=./vgabios.bin of=romimage ↵ bs=65536 seek=2 conv=sync conv=notrunc # end VGA support option CONFIG _ EPIAMVERSIONSTRING="5.0.0E-" ↵ _ _ DATE _ _ " " _ _ TIME _ _ target /home/anthony/src/epia-m/freebios/ option DEFAULT _ CONSOLE _ LOGLEVEL=9 option DEBUG=1 # Use 256KB Standard Flash as Normal BIOS option RAMTEST=1 option USE _ GENERIC _ ROM=1 option STD _ FLASH=1 option ROM _ SIZE=262144 # payload size = 192KB option PAYLOAD _ SIZE=196608 # use ELF Loader to load Etherboot option USE _ ELF _ BOOT=1 # Use FILO as our payload payload /home/anthony/src/payloads/Þlo.m2.elf
Сохраним конфигурацию в файл config1 и подготовим Makefile для дальнейшей компиляции следующим образом: python /home/anthony/src/freebios/util/conÞg/ ↵ NLBConÞg.py conÞg1 /home/anthony/src/freebios
В итоге получили новую директорию /home/anthony/src/ epia-m/freebios, в которой и будет приготавливаться системный ROM-файл для нашей системы. Не забудем положить в эту же директорию файл от VIDEOROM.
№8, август 2005
cd ~/src/epia-m/freebios make
В результате получили файл romimage. Его-то нам и нужно записать в чип flash-памяти. Для этой цели в директории ~/src/freebios/util/flash_and_burn приготовлена утилита записи во flash-память. Соберем ее и посмотрим, какие параметры ей необходимы. cd ~/src/freebios/util/ßash _ and _ burn make ./ßash _ rom --h The arguments are: --h ./flash_rom: invalid option -- usage: ./flash_rom [-rwv] [-c chipname] [-s exclude_start] [-e exclude_end] [file] -r: read flash and save into file -w: write file into flash (default when file is specified) -v: verify flash against file -c: probe only for specified flash chip -s: exclude start position -e: exclude end postion If no file is specified, then all that happens is that flash info is dumped
Необходимо использовать в качестве параметра имя файла системного ROM. Не забудем переключить с помощью BIOS Savior нужный нам чип flash-памяти и запустим с правами суперпользователя программу записи во flash-чип: su ./ßash _ rom romimage The arguments are: romimage Calibrating timer since microsleep sucks ... takes a second Setting up microsecond timing loop 332M loops per second OK, calibrated, now do the deed Enabling flash write on VT8235...OK Trying Am29F040B, 512 KB probe_29f040b: id1 0x7f, id2 0x45 Trying At29C040A, 512 KB probe_jedec: id1 0xbf, id2 0xb6 Trying Mx29f002, 256 KB probe_29f002: id1 0xbf, id2 0xb6 Trying SST29EE020A, 256 KB probe_jedec: id1 0xbf, id2 0xb6 Trying SST28SF040A, 512 KB probe_28sf040: id1 0x7f, id2 0x45 Trying SST39SF020A, 256 KB probe_jedec: id1 0xbf, id2 0xb6 SST39SF020A found at physical address: 0xfffc0000 Part is SST39SF020A Programming Page: 0063 at address: 0x0003f000
Итак, в чип SST39SF020A записан LinuxBIOS. Во второй чип мы предварительно записали системный AwardBIOS, с которым поставлялась эта плата. На всякий случай. Теперь перейдем на второй компьютер и с помощью нуль-модемного кабеля подключим порты RS232 на EPIAM и на нашем компьютере. Зачем это надо? Для того чтобы отслеживать информацию, выводимую на терминал. Запускаем терминальную программу minicom. Устанавливаем нужный COM-порт, скорость в 115200 бод и готовимся к холодному старту блока с LinuxBIOS на борту. Выключаем EPIA-M и, переведя дыхание, включаем заново. Смотрим, что же получилось. Привожу не все сообщения, а только наиболее характерные. LinuxBIOS-1.0.0 Сбт Июн 25 21:48:38 MSD 2005 starting... RB!0
79
hardware LinuxBIOS-1.0.0 Сбт Июн 25 80 08 07 0d 0a 01 40 00 04 0e 04 08 01 02 20 00 00 00 75 75 45 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 30 33 31 32 37 39 00 00 00 00 00 00 00 00 00 00 00 00 Copying LinuxBIOS to ram. Jumping to LinuxBIOS.
21:48:38 60 70 00 00 00 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MSD 2005 82 08 00 30 48 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
starting... 01 40 00 21 00 00 00 00
Выводятся сообщения о номере релиза LinuxBIOS и времени компиляции. Из flash-памяти образ LinuxBIOS в дальнейшем копируется в RAM для ускорения процесса загрузки и последующие манипуляции проводятся уже в ОЗУ. На определенном этапе вы увидите такое сообщение: POST: 0x89 POST: 0x70 totalram: 96M Initializing CPU #0
На самом деле памяти у меня в системе почти в 2 раза больше – 256 Мб, однако в стабильной ветке LinuxBIOS 1.0 на тот момент не существовало механизма определения количества ОЗУ. Данная проблема решена во второй версии LB. Поэтому либо оставим как есть, либо вам придется, исходя из ваших возможностей, поменять в исходном файле параметр, задающий количество ОЗУ. Далее интересная надпись – отработала инструкция CPUID, и мы видим, что же за чудо выпускает компания VIA: Max cpuid index Vendor ID Processor Type Processor Family Processor Model Processor Mask Processor Stepping Feature flags
: : : : : : : :
1 CentaurHauls 0x00 0x06 0x09 0x00 0x05 0x0380b13d
CentaurHauls когда-то выпускала компания WinChip. Следующая запись, заслуживающая вашего внимания: Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 POST: 0xf8 37:init_bytes() - zkernel_start:0xfff00000 zkernel_mask:0x0000ffff Found ELF candidate at offset 0
LinuxBIOS дошел до стадии загрузки «полезной загрузки» – прошу прощения за тавтологию. В качестве payload у нас выступает FILO. Вот что пишет FILO во время выполнения: POST: 0xfe FILO version 0.4.2 (anthony@athlon) Сбт Июн 25 21:47:32 MSD 2005 Press <Enter> for default boot, or <Esc> for boot prompt... 2. .1. .timed out boot: hda3:/boot/vmlinuz root=/dev/hda3 console=tty0 console=ttyS0,115200 hda: LBA48 160GB: SAMSUNG SP1604N Mounted ext2fs Found Linux version 2.4.26 (root@tree) #8 Mon Jun 14 19:09:31 PDT 2004 bzImage. Loading kernel... ok Jumping to entry point... Linux version 2.4.26 (root@tree) (gcc version 3.3.4) #8 Mon Jun 14 19:09:31 PDT 2004
FILO отрапортовал, что в качестве носителя найден жесткий диск SAMSUNG SP1604N, на котором в разделе hda3 находятся ядро системы и корневой раздел, и передал управление ядру операционной системы.
80
Дальнейшие записи уже вам привычны и знакомы. С помощью SSH можно зайти в систему и проверить, например, температуру. # ssh -l anthony -C via anthony@via's password: Last login: Sat Jun 25 21:53:41 2005 from athlon.net Linux 2.4.26. anthony@via:~$ sensors eeprom-i2c-0-50 Adapter: SMBus Via Pro adapter at 0f00 Memory type: DDR SDRAM DIMM Memory size (MB): 256 vt1211-isa-ec00 Adapter: ISA adapter fan1: 3378 RPM (min = 3006 RPM, div = 2) fan2: 0 RPM (min = 3006 RPM, div = 2) Proc Temp: +47.2C (high = +65C, hyst = +60C) anthony@via:~$ telnet 127.0.0.1 7634 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. |/dev/hda|SAMSUNG SP1604N|37|C|Connection closed by foreign host.
В целом работу нашего конструктора можно считать нормальной. Подведем итоги. Мы скомпилировали LinuxBIOS, записали образ в ППЗУ и удачно загрузились. Также мы научились снимать данные о температуре с критически важных узлов нашей ПЭВМ. Полностью рабочая удаленная станция к вашим услугам. Автор благодарит участников проекта LinuxBIOS за консультации при подготовке данного материала, в частности Josiah England, Jonathan McDowell, Adam Talbot, Jun Okajima. А также за краткую историю развития проекта LinuxBIOS за 1999-2004 года R.Minnich [12-13]. В следующем номере мы посмотрим, как запустить EPIA-M в качестве узла Beowulf-кластера, а также запустим на EPIA-M операционную систему Windows 2000 Professional. Плюс посмотрим, как наш блок EPIA-M превращается в терминальное решение.
Ссылки: 1. 2. 3. 4. 5.
http://en.wikipedia.org/wiki/WinChip. http://de.wikipedia.org/wiki/WinChip. http://en.wikipedia.org/wiki/Cyrix. ftp://ftp.chg.ru/pub/Linux/Slackware/slackware-10.0-iso. http://secure.netroedge.com/~lm78/archive/lm_sensors2.9.1.tar.gz. 6. http://secure.netroedge.com/~lm78/archive/i2c-2.9.1.tar.gz. 7. http://www.guzu.net/linux/hddtemp-0.3-beta12.tar.bz2. 8. http://snapshots.linuxbios.org/freebios--devel--1.0--base0.tar.bz2. 9. http://snapshots.linuxbios.org/freebios--devel--2.0--patch51.tar.bz2. 10. http://citkit.dl.sourceforge.net/sourceforge/etherboot/ etherboot-5.4.0.tar.bz2 (http://rom-o-matic.net). 11. http://te.to/~ts1/filo/filo-0.4.2.tar.bz. 12. http://www.linuxdevices.com/links/LK8294110575.html. 13. http://www.beowulf.org/archive/2002-September/008021. html.
web
СОВЕРШЕНСТВУЕМ ТЕХНОЛОГИЮ CMS
АЛЕКСЕЙ МОИСЕЕВ Уже не один месяц интернет-сообщество и бизнес ожидают новое поколение CMS. Наконец отдельные идеи, многие из которых революционные, были собраны воедино, в проекте Habitat 2.0.
C
MS в их текущем виде существуют уже довольно-таки давно. Эксперты сходятся во мнении, что в ближайшее время должно появиться что-то кардинально новое – система, которая возведёт сайтостроение на качественно более высокий уровень. В различных изданиях, преимущественно электронных, не раз публиковались статьи, посвящённые несовершенству современных CMS. Там же высказывались предложения о том, каковы должны быть CMS нового поколения, однако большинство таких предложений уже давно реализовано (например, модульная структура, редактор HTML-кода в администраторской части). Подавляющее большинство разработчиков CMS основной акцент делают на пользовательскую (клиентскую) часть, а администраторская панель является дополнением, позволяющим более комфортно управлять функциями системы. Одно из главных отличий предлагаемой вам сегодня системы состоит в том, что ее основной частью является администраторская панель, а клиентская часть состоит из визуализатора, отображающего скомпилированные страницы пользователю.
Размышляем о новых возможностях CMS Как правило, наиболее качественными CMS являются платные системы. При покупке такой CMS пользователь получает поддержку, а также в большинстве случаев своевременное решение появляющихся вопросов при работе с системой. Среди платных CMS следует особо выде-
82
лить: S.Builder, Q-Publishing, UMI.CMS, ABO.CMS, Bitrix, CimWebCenter, CMS Master, CMS UlterSuite, Content Master, MSTL-content, помимо перечисленных, существует ещё очень много систем управления. Один из таких продуктов – Habitat – разрабатывался мной в течение длительного времени. После двух с половиной лет исследования CMS мною были сделаны выводы относительно конструктивных особенностей, не позволяющих развиваться существующим системам в сторону usability. Неоднократно проводились консультации с владельцами сайтов на основе Habitat, по теме сервисных возможностей, однако далеко не всё можно реализовать на базе существующих CMS.
Иное представление CMS Результатом вышеописанных исследований стал проект Habitat 2.0. Он является развитием большинства существующих CMS. Среди основных нововведений, которые вы не увидите в других системах, имеет смысл особо выделить объектно-ориентированный метод построения шаблонов страниц. Д ля а дминистратора системы HTML-страница представляется в виде дерева компонентов, каждый из которых имеет свойства, позволяющие изменить вид графического представления компонента. Система не оперирует понятиями HTML, CSS, JavaScript. То есть уровень абстрагирования на порядок выше, чем у ближайших аналогов. Компонент есть инициализированный класс, который закачивается в систему в формате XML-компонента.
! В систему изначально заложены
способы упорядочивания компонентов, благодаря чему вы можете организовывать объекты представления (страницы, товары и т.д.) в любом порядке (линейный, иерархический). ! Для наполнения шаблонов страниц динамической информацией используются инфоисточники (DataAware). К инфоисточникам относятся константы (строки, определённые для всех компонентов), переменные (строки, определённые по месту, то есть для конкретных компонентов) и сами Data-Aware, которые представляют собой участок PHP-кода в комбинации с PIN. Последние необходимы для связи данных, возвращаемых скриптом Data-Aware, с переменными внутри шаблонов. ! Среди неотъемлемых частей Habitat 2.0 можно выделить магазин. Его необходимость объясняется тем фактом, что в результате роста числа российских пользователей Интернет с каждым днём увеличивается число Интернет-представительств организаций, которые считают необходимым обеспечить возможность комфортного для пользователей заказа услуг компании. Разработка сайта отныне осуществляется в новом ключе – веб-программист разрабатывает компоненты, отвечает за то, что они реализуют свои функции, а затем собирает из этих компонентов шаблоны страниц (т.н. типовые страницы). Все это делается ради нескольких «священных коров» программирования:
web ! установление четкой и прозрачной
взаимосвязи между содержанием (данные из БД) и формой (визуализация данных); ! перенос понятия «сопровождения сайта» из плоскости программирования в плоскость управления и соответственно удешевление сопровождения; ! повторное использование кода (компоненты – вещь четкая и отделимая от всего остального); ! повышение надежности серверной части ПО за счет структурной четкости реализации. Шаблоны страниц могут состоять из компонентов (элементарные шаблоны) и других шаблонов (т.н. «типовые страницы»), собранные на основе компонентов. Под компонентом подразумевается логически выделенный дизайнером и обычно повторяющийся элемент дизайна, несущий определенную функциональность, например отображение списка новостей. Рубрикаторы, меню, содержательные части страниц и т. д. – все это компоненты, на основе которых путем комбинирования, взаимного их расположения можно построить шаблоны страниц. Это обеспечит нам легкость и гибкость изменения внешнего вида. Например, можно задавать, какие рубрикаторы используются в различных шаблонах, где используются колонтитулы, а где нет, и т. д. Для реализации большей части нововведений потребовалось более активное использование БД, чем в обычных CMS, однако требования у системы не выходят за рамки возможностей дешёвых хостингов: PHP 5, MySQL 4, 20 Мб свободного места (обычно самое минимальное, что можно купить).
Ядро Habitat 2.0 Важнейшую часть ядра системы составляет компилятор-сборщик, который на входе получает ссылку в корень дерева шаблона (который надо собрать), а на выходе отдаёт готовый шаблон для страниц с расставленными «вкраплениями». Расстановка указанных «вкраплений» (шаблоновых переменных) является наиболее интеллектуальной частью компилятора. На место таких переменных вставляется информация, возвращаемая от источников данных (Data-
№8, август 2005
Aware, Переменные, Константы). Эту операцию выполняет компилятор-сумматор, который является частью пользовательского визуализатора. Для того чтобы полностью переложить всю работу, над внешним видом сайта, на плечи системы (а точнее, её разработчика) помимо свойств (в которых задаются параметры каждого компонента, такие, как обрамление, выравнивание, положение и т.п.), у компонента есть события. Определяя события для конкретных компонентов, можно добавить динамику для страницы сайта (например, подсветка рубрикаторов, элементов меню и т.п.). Для этого планируется: ! Написание Data-Aware модулей, решающих все возможные вопросы, которые только могут появиться у пользователей. ! JavaScript-описание всех определённых событий в HTML, для того чтобы дать администратору максимально возможную гибкость при редактировании внешнего вида страниц. ! Создание множества классов, для того чтобы полностью исключить необходимость редактирования исходного кода HTML или CSS. При работе с константами, переменными и DataAware всегда есть возможность просмотреть названия компонентов, где используется текущий источник данных. Для перехода к редактированию компонента, использующего текущий источник, достаточно двойного клика мышкой.
Компоненты как строительный материал Компонент «движка» представляет собой строительный материал для страниц сайта. Он обладает рядом особенностей, делающих компоненты более универсальным средством. Во-первых, он визуальный, т.е. занимает определенную территорию на странице. Это накладывает ограничение на свободу создателя компонента, который должен гарантировать, что компонент не будет рисовать за пределами самого себя. Во-вторых, компонент всегда получает данные извне, т.е. сам не умеет запрашивать данные из базы, – он суть одеяние, способ отображения не-
ких других данных. На этапе компоновки страниц компоненту указывается источник данных, откуда он и узнает то, что ему необходимо отображать. И в-третьих, будем отличать «класс компонента classMyComponent» и «компонент MyComponent класса classMyComponent». Первый никогда не исполняется сам по себе – это описание того, что должно быть передано движку и включено в цикл обработки движка. То есть, говоря простым языком, classMyComponent – это заготовка, ее можно экспортировать из одного проекта и импортировать в другой, пусть и для похожего, но уже другого применения. По аналогии с языками высокого уровня classMyComponent – это тип объекта или его класс, а сам объект этого типа нужно еще породить и запустить. Программист для нашего движка сначала создает компоненты, а потом уже пытается правильно их применить. Работа с типами компонентов (классами), а также инициированными классами (будем их называть просто «компоненты») нужна для того, чтобы компоненты одного и того же класса можно было использовать множество раз для схожих и одновременно разных целей. Точно так же, как программисты Delphi/VC++ используют классы, описывающие в памяти некоторую структуру данных. В данном же случае достигается некоторая степень универсальности, позволяющая компоненты одного типа представлять в различном виде: форма, цвет, обрамление… И как следствие этого приема компонент перестает быть привязанным к конкретной реализации, он работает как черный ящик для того, кто его использует. При создании шаблона страницы у разработчика есть свойства, события компонента, заявленная функциональность, всё остальное – дело самого компонента.
Интерфейс Внешнее представление самой администраторской панели спроектировано таким образом, чтобы вы могли «добраться» до любого «уголка» панели за минимально возможное время. Это обеспечено за счёт иерархической структуры всей администраторской панели, то есть дерева в отдельном фрейме. Каждая ветка дерева догружается по мере необходи-
83
web мости, что позволяет более эффективно использовать канал связи. В отдельный верхний фрейм (так называемый Toolbar) вынесены сервисные кнопки, которые позволяют управлять структурой дерева, а также обезопасить себя от случайного удаления важного элемента. Рассматриваемая CMS изначально создаётся для рядового пользователя Интернета, коим вполне может оказаться руководитель предприятия или работник отдела маркетинга, какой-либо организации. Этим объясняется возможность включения подсказок везде, где это может принести хоть какую-то пользу. Среди стандартных возможностей системы можно упомянуть разделение доступа для суперадминистраторов, администраторов, модераторов, редакторов, аудиторов и т. п, эргономичность, usability, accessibility, управление рекламой, статистика (по рекламе, посетителям и т. д), создание резервной копии всей системы… В истории немало фактов, когда создание простых инструментов и технологий приводило к появлению на рынке множества некачественных продуктов, изрядно портящих жизнь их пользователям, однако с появлением Habitat 2.0 строение сайтов будет на порядок проще, а безопасность в несколько раз выше, так как ей будут заниматься профессионалы, чья основная обязанность заключается в совершенствовании Security и Usability модулей системы. Многоязыковая поддержка позволит системе распространиться за пределы СНГ. В планах на будущее реализовать подход к вёрстке AJAX (подход к созданию веб-страниц, позволяющий при каждом новом запросе загружать не полностью новую страницу, а лишь те её части, которыми она отличается от текущей. Этот принцип позволяет повысить скорость загрузки страниц во много раз по сравнению с традиционными методами вёрстки), что становится вполне реальным, если под рукой находится вышеописанная CMS платформа.
Этапы развития сайтостроения В итоге мы можем выделить следующие ступени эволюции интернетстраниц:
84
! Начальные идеи отдельных раз-
! ! ! !
работчиков. Как правило, распространение за пределы одного рабочего коллектива отсутствовало. Gopher. Статические веб-страницы. Динамические веб-страницы, развитие CMS. Конкретное название класса для CMS подобных Habitat 2.0 придумывать пока рано, однако есть основания полагать, что это первый шаг к тем системам нового поколения, приход которых предсказывают эксперты.
Если проследить развитие языков разметки от HTML 3.2 до XHTML, XML, то можно заметить, что важнейшей целью разработчиков Интернетконсорциума, вероятно, является сделать труд веб-верстальщиков менее рутинным (в конференциях, таких, как fido7. RU.HTML.PROFY, высказывается мнение, что цель разработчиков заставить верстальщиков использовать программы класса XMLSpy, HomeSite, DreamWeaver, и не набирать код вручную), то есть вся рутинная вёрстка, как предполагается, должна выполняться специальными программами. Вполне возможно, что профессия «верстальщик» вообще перестанет существовать в её современном представлении. В ряды продуктов, выполняющих всю рутинную вёрстку, можно отнести Habitat 2.0. Точно так же, как визуальное программирование позволяет ускорить и упростить труд дизайнера программного обеспечения (а главное, не требует от него особых навыков программиста), системы нового поколения приблизят возможности WWW к пользователям, не имеющим навыки вебразработчиков. С большой долей вероятности можно утверждать, что будущее именно за гибкими автоматизированными системами управления содержимым вебресурса.
Возможное развитие Есть предположение, появившееся при анализе существующих систем управления сайтом, а также при проектировании Habitat и Habitat 2.0, что через некоторое время большинство хостинг-провайдеров в качестве допол-
нительной услуги или даже в качестве обязательной функции будут предлагать использование CMS. Разработка таких CMS скорее всего будет вестись сторонними фирмами либо самой организацией, предоставляющей услуги хостинга. Примером подобных программных продуктов может служить Control Panel и Direct Admin. Предполагается, что CMS будет состоять из центральной администраторской панели, в которой можно будет управлять абсолютно всеми функциями веб-сайта и одним для всех визуализатором. Это позволит постоянно повышать безопасность («единый фронт борьбы с хакерами»), а также оградит пользователей от таких ненужных в большинстве случаев определений, как «FTP», «закачать обновление». Всё это является задачами CMS и администраторов хостинга. В России немало частных лиц и небольших организаций, занимающихся различными разработками, не имеют возможности рассказать о своих идеях в прессе. Системы автоматизированного построения веб-ресурсов, позволяющие полностью оградить своего владельца от необходимости вебразработки и при этом не требующие услуг дизайнера, делают реальностью самостоятельную публикацию идей или разработок. В настоящий момент такая услуга, как создание и сопровождение Интернет-ресурса компании, деятельность которой не связана с информационными технологиями, обходится в крупную сумму. Однако увеличение доступности Интернета в совокупности с появлением CMBS-систем позволит интернет-пользователям заказывать услуги не только относительно крупных компаний, но и более мелких организаций. Наиболее вероятно внедрение подобных идей у хостинг-провайдеров, постоянно улучшающих качество своих услуг, понимающих, для чего необходимо «грамотное регулирование цен» на услуги. В России таких фирм почти нет… разве что уже упоминавшаяся RuWEB. Или, может, о новых технологиях предоставления хостинга задумаются те провайдеры, которые ещё только планируют появиться в ближайшем будущем? Возможно, бой только начинается…
bugtraq Обход требования использования клиента в Cisco Clean Access
Множественные уязвимости в OpenVPN
Программа: Cisco Clean Access 3.5.3.1, 3.5.4. Опасность: Низкая. Описание: Пользователь может изменить HTTP User-Agentстроку браузера, чтобы подключиться к сети без необходимости запуска Cisco Clean Access. URL производителя: http://www.cisco.com/en/US/products/ ps6128/index.html. Решение: Способов устранения обнаруженной уязвимости не существует в настоящее время.
Программа: OpenVPN 1.x 2.x. Опасность: Средняя. Описание: 1. Уязвимость в обработке очереди OpenSSLошибок, когда аутентифицируется пользователь с неправильным сертификатом, позволяет отключить другого несвязанного пользователя. Для удачной эксплуатации этой ошибки, OpenVPN должен быть запущен с «verb 0» и без «ls-auth». 2. Уязвимость в обработке очереди OpenSSL-ошибок, когда сервер не в состоянии расшифровать полученный пакет, может эксплуатироваться авторизованным клиентом, чтобы отключить другого клиента через специально обработанный пакет. 3. Авторизированный клиент в режиме Ethernet-моста «dev tap» может затопить сервер множеством пакетов с различными поддельными MAC-адресами, чтобы исчерпать доступную системную память. 4. Два или более клиентов, подключенных в одно и то же время к серверу с одним и тем же сертификатом, могут использовать ошибку состояния операции, чтобы аварийно завершить работу уязвимого сервера. Для использования этой уязвимости на сервере должна быть отключена опция «duplicate-cn». URL производителя: http://openvpn.net/changelog.html. Решение: Установите обновленную версию программы (2.0.1).
Поднятие привилегий и отказ в обслуживании в CA Message Queuing Программа: Unicenter TNG. Опасность: Средняя. Описание: Переполнение буфера обнаружено в CA Message Queuing, которую используют несколько программ Computer Associates. Удаленный пользователь может подменить CA-File Transfer Protocol, чтобы выполнить произвольный код с поднятыми привилегиями. Удаленный пользователь может также вызвать условия отказа в обслуживании через CAM TCP-порт. URL производителя: http://supportconnectw.ca.com/public/ ca_common_docs/camsecurity_notice.asp. Решение: Fixes for CAM v1.11 prior to Build 29_13: http:// s u p p o r tc o n n e c t w.c a .c o m / p u b l i c / c a _ c o m m o n _ d o c s / camsecurity_cam111fixes.asp; Fixes for CAM v1.07 prior to Build 220_13: http://supportconnectw.ca.com/public/ca_common_ docs/camsecurity_cam107fixes.asp; Fixes for CAM v1.05 (any version): http://supportconnectw.ca.com/public/ca_ common_docs/camsecurity_cam107fixes.asp.
Выполнение произвольного кода в Sun Solaris DHCP-клиенте Программа: Sun Solaris 10. Опасность: Высокая. Описание: Уязвимость обнаружена в сценарии /lib/svc/ method/net-svc. Удаленный DHCP-сервер может послать большое количество DNS-имен в ответ на запрос DHCPклиента и выполнить произвольный код на целевой системе с привилегиями пользователя root. URL производителя: www.sun.com. Решение: Установите исправление с сайта производителя.
Переполнение буфера в Novell eDirectory Server Программа: Novell eDirectory Server версии до 8.7.3. Опасность: Критическая. Описание: Уязвимость существует в компоненте iMonitor. Удаленный пользователь может вызвать отказ в обслуживании системы или выполнить произвольный код с привилегиями Local System. Подробности уязвимости не сообщаются. URL производителя: www.novell.com. Решение: Установите исправление с сайта производителя.
№8, август 2005
Удаленный административный доступ в Cisco Intrusion Prevention System Программа: Cisco Intrusion Prevention System (IPS) 5.0(1) и 5.0(2). Опасность: Высокая. Описание: Авторизованный пользователь с OPERATORили VIEWER-правами доступа может эксплуатировать уязвимость в логике command line processing (CLI), чтобы получить полный административный доступ к целевому IPSустройству. URL производителя: http://www.cisco.com/warp/public/707/ cisco-sa-20050824-ips.shtml. Решение: Установите обновленную версию (5.0(3)): http:// www.cisco.com/cgi-bin/tablebuild.pl/ips5.
Повышение привилегий в продуктах Symantec Программа: Symantec AntiVirus Corporate Edition 9.0, 9.0.1, 9.0.2; Symantec Client Security 2.0, 2.0.1, 2.0.2. Опасность: Низкая. Описание: Уязвимость существует в HELP-функции, которая использует HTML-интерфейс помощи Windows. Непривилегированный локальный пользователь может получить доступ на чтение и выполнение файлов с привилегиями Local System. URL производителя: www.symantec.com. Решение: Установите обновление с сайта производителя.
Составил Александр Антипов
85
бизнес-решения в IT
IT В СФЕРЕ РЕСТОРАННО-ГОСТИНИЧНОГО БИЗНЕСА
КИРИЛЛ ТИХОНОВ Современный гостиничный комплекс – очень сложная система, обычно включающая в себя собственно гостиницу, ресторан, бары, развлекательные центры и т. п. Конечно, если вам приходится администрировать придорожный мотель на 5 номеров, то хватит и таблички в Excel. В остальных случаях без специализированной системы управления не обойтись.
С
егодня мы рассмотрим программные и аппаратные продукты, позволяющие эффективно управлять современными гостиничными комплексами – Fidelio и Opera, и ресторанами – Micros, входящими в гостиничный комплекс.
Управление гостиницами Современные темпы развития гостиничного бизнеса предъявляют высочайшие требования к автоматизированным системам управления для предприятий индустрии гостеприимства. Fidelio V8 – система управления отелем, построенная на СУБД Oracle, способна решать задачи от продаж, бронирования, приёма и размещения гостей, организации конференций и банкетов и управления связями с клиентами до предоставления полных данных для финансового контроля и управленческого учёта деятельности предприятия. Модуль управления связями с клиентами (CRM) позволяет иметь полную картину всех пожеланий и предпочтений гостей и соответственно оказывать высокий уровень сервиса. Индивидуальность подхода к клиенту заключается в предоставлении каждому гостю именно той информации, в которой он нуждается. Например, финансовый менеджер, остановившийся в вашем отеле, найдет в своем номере последний выпуск финансово-аналитического журнала, любитель игры в большой теннис – адреса ближай-
86
ших кортов, игрок в боулинг – лучшие предложения от ведущих боулинг-клубов города. В Fidelio V8 все данные по клиенту объединяются в профайлы, хранящиеся в единой центральной базе данных, причем в каждом клиентском профайле можно заводить неограниченное число контактных данных гостя, отдельно вносить такую маркетинговую информацию, как степень важности клиента, вид его деятельности, долю компании на рынке, информацию по кредитным картам гостя. Большим преимуществом является то, что система позволяет не удалять профайлы, а делать их неактивными в случае необходимости, при этом они могут быть восстановлены в любой момент. Одной из основных статей доходов отеля является деятельность отдела организации конференций и банкетов. Модуль CCM позволяет быстро проверить доступность и текущую активность по существующим броням, с легкостью вводить планируемые мероприятия и эффективно ими управлять. Также одним из преимуществ данного модуля является возможность одновременной брони как конкретного мероприятия, так и номеров в отеле. Работа любого отеля начинается со службы приема и размещения, которая является центральным и важнейшим звеном системы Fidelio. Создание и обновление броней, разделение детей по возрастным категориям, предоставление информации о наличии но-
меров, их типе, калькуляция по требованию, лист ожидания, расширенные возможности тарифной политики – все эти функции значительно ускоряют работу всего отдела. Система позволяет в считанные минуты заселить и выписать гостя, без необходимости оформления множества бумаг, что особенно важно для гостей, ценящих свое время. Регистрация может производиться как по брони, так и без нее, возможен специальный «быстрый» вариант оформления выписки для групп. В Fidelio V8 доступен весь необходимый набор кассирских функций, включая специальные гостевые функции, такие как депозитирование, управление валютами, платежами и выставлением счетов. Хранение счетов выписанных гостей для последующего восстановления данных при необходимости, выбор группы для формирования единого счета, ежедневное обновление курса валют, возможность одновременного открытия и изменения счетов со сложной структурой в одно и то же время из различных окон, ведение журнала кассирских операций и многие другие особенности значительно упростят не только стандартные кассирские операции, но и позволяют сделать этот модуль интегрированной системой с возможностью полного контроля за движением денежных средств в гостинице. C помощью Crystal Reports Fidelio
бизнес-решения в IT позволяет создавать большое число разнообразных отчетов (как стандартных, так и нестандартных), которые могут быть предварительно просмотрены или распечатаны. Все отчеты могут передаваться в формате Word, Excel, факсимильных и электронных сообщений.
OPERA Enterprise Solution В отличие от традиционных систем для гостиниц, OPERA Enterprise Solution представляет собой самое полнофункциональное на сегодняшний день решение управления, предназначенное как для независимых отелей, так и для гостиничных сетей; как для небольших отелей с ограниченным набором услуг, так и для шикарных 5-звездочных гостиниц. Система состоит из модулей, которые с легкостью могут быть настроены и добавлены в зависимости от пожеланий конкретного отеля. Она включает в себя: ! систему автоматизации слу жбы приема и размещения гостей (Property Management System); ! систему автоматизации отдела продаж и маркетинга (Sales and Catering); ! систему управления качеством обслуживания (Quality Management System); ! систему оптимизации прибыли (Revenue Management); ! систему управления мероприятиями (OPERA Activity Scheduler); ! систему централизованного бронирования (OPERA Reservation System); ! модуль бронирования через Интернет (Web-Self Service); ! централизованную информационную систему по клиентам (Customer Information System). С помощью мобильного решения OPERA-Palm, работающего на карманных компьютерах, объединенных в беспроводную сеть, пользователи имеют доступ ко всей информации в базе данных в режиме реального времени. OPERAPalm позволяет персоналу осуществлять основные операции, находясь практически в любой точке отеля и не будучи привязанными к одному рабочему месту: удаленно поселять и выписывать гостей; уп-
№8, август 2005
равлять задачами; проверять статус номера; управлять взаимоотношениями с клиентами; составлять график мероприятий. Система может работать как в режиме клиент-серверного приложения, так и в режиме тонкого клиента через браузер. Серверная часть Opera может работать на базе Microsoft Windows NT/ 2000, AIX и Sun Solaris. Существует возможность осуществлять бронирование номеров клиентами непосредственно с веб-сайта. Система OPERA поддерживает более 350 интерфейсов, включая интерфейс с системой управления ресторанами, телефонными системами и системами тарификации телефонных звонков и Интернет-услуг, системой автоматических минибаров, системой управления счетами клиентов, системами платного телевидения, системами электронных замков, системой авторизации кредитных карт, бухгалтерскими системами.
Управление ресторанами Основой системы управления ресторанами Micros являются рабочие станции – терминалы с сенсорным экраном, которые устанавливаются в точках продаж (POS) – в местах, где вводится заказ и/или осуществляется оплата. Затем заказ автоматически поступает на кухню и распечатывается на кухонных принтерах. Также для распечатки счетов гостей в кафе, фаст-фудах, в барах могут устанавливаться рулонные принтеры, которые дополнительно используются для печати специализированных отчетов. Для распечатки счетов гостей на фирменных бланках в точках продаж устанавливается принтер гостевых чеков. Доступ в системы обеспечивается с помощью персонального идентификационного кода или магнитной карточки, что позволяет разграничить доступ к функциям систем в зависимости от должности сотрудника. Micros обеспечивает максимальную защиту введенной информации и предотвращает случаи ошибочного или некорректного использования данных любыми пользователями. Все данные о деятельности ресторана в любой момент времени могут быть представлены в виде отчетов, как на экране, так и в бумажном виде. По-
мимо большого числа типовых отчетов есть возможность создавать собственные формы статистики. Система Micros 3700 работает на рабочих станциях Micros – прочных, плоских, с сенсорными экранами, разработанных специально для использования в жёстких условиях. Удобный экран дает возможность сотрудникам видеть полную картину расположения столиков в ресторане в графическом формате. Micros 3700 предлагает самые совершенные функции POS, такие как TouchAdvantage – для ускорения процедуры разделения чека, функций перемещения и отмены, а также мощные функции для управления рестораном – сопровождающие и расширенные отчёты. Поддерживает стандартную базу обмена данными Sybase SQL Anywhere. Micros 8700 позволяет одновременно вести управление большим числом точек продаж, которые могут существенно отличаться друг от друга ценами, ассортиментом и условиями реализации. Система функционирует на разработанном Micros оборудовании, устойчивом к попаданию жидкости, каплям масла и другим факторам эксплуатации оборудования на кухне. Помимо встроенных модулей учета продаж, себестоимости, регистрации рабочего времени сотрудников и многих других необходимых функций, Micros 8700 обладает открытой архитектурой с другими системами, что позволяет оборудованию и программному обеспечению гибко интегрировать периферийные стандарты индустрии и модулей программного обеспечения. Micros 8700 работает на базе процессора Intel и разработан в операционной среде SCO UNIX, обладает высокой степенью надежности сохранения всех данных, обеспечивает стабильный и экономически безопасный бизнес. Система внесена в Государственный реестр контрольно-кассовых машин, используемых на территории Российской Федерации и ряда стран СНГ, и может использоваться в фискальном режиме. В заключение хочу сказать, что на этих системах построено управление большого количества широко известных гостиничных комплексов не только в Москве и России, но и во всем мире.
87
сказки
АДМИНСКИЕ СКАЗКИ 16 BIT EDITION
АЛЕКСЕЙ БАРАБАНОВ Совершенно выдуманные истории, рассказанные в порядке двоичного сдвига, без какой-нибудь видимой цели или морали, и даже не ко сну.
1. Сказка о первом Админе и админском проклятии Давным-давно, когда ЭВМ были большие, а оперативная память маленькая, все, кто работал на ЭВМ, были программистами, все писали программы. Но был среди них один, который ленился. Надоело ему кодировать да перфорировать. Задумал он создать себе такое занятие, чтобы и ЭВМ работала, и ему трудиться не пришлось бы. Так как был он программистом, то написал специальную программу – Операционную систему, чтобы в ней исполнять другие программы. И убедил всех программистов, что в Операционной системе работать удобнее. Первое время так и было. Но потом оказалось, что не всё, что нужно для работы, он им объяснил! Только программист-лентяй знал самое важное о его Операционной системе. Стал он нужнее нужного для остальных программистов. Уважали они его поневоле, называли Администратором. Забыли, что еще недавно считали лентяем. Жил он счастливо. Да не долго продолжалось его счастье. Так как в прошлом Администратор был программистом-лентяем, то и Операционную систему он сделал с большими пробелами в функциональности. И чтобы эти пробелы восполнить, все время приходилось ему программировать. И с тех пор всех Администраторов преследует проклятие того первого Администратора, бывшего ленивого программиста, и заставляет их писать программы наспех и некачественно.
2. Сказка о потерянном пинге В одной большой Конторе работал Администратор локальной сети. Он очень любил сеть, созданную своими руками, все в ней знал, любую проблему решал
88
моментально. И как только в Конторе появлялись новые пользователи, наш Админ сразу же увеличивал сеть на нужное число рабочих мест. Так продолжалось долго. Сеть росла. И вот настал такой день, когда пинг, выпущенный Админом в локальную сеть, обратно не вернулся. Не придал этому значения Админ. Занят был, да и работало же все, да и никто не жаловался. Но и на следующий день выпущенный пинг к Админу не вернулся. И на третий день то же самое. Теперь уже Админ боялся поверить в то, что он потерял пинг! Попытался решить проблему. Но как? Разве только демонтировать часть сети, созданную за три дня, а пользователей повыгонять. Потерял радость жизни Админ, замкнулся, посуровел. Понял он, что не далек тот день, когда сеть вообще выйдет из повиновения. И так его это огорчало, что однажды он уволился, не дожидаясь, пока случится непоправимое. И с тех пор каждый Админ периодически пингует свою сеть, проверяя, а не пропадают ли в ней пинги!
4. Сказка о первом Ламере и вездесущем глюке Где-то в самой дали Сети была подключена некая Контора. В этой Конторе работал Админ, у которого иногда случались труднообъяснимые проблемы. Не то чтобы он был совсем уж плохой, этот Админ, но не очень грамотный. Поэтому никак не мог доделать работу до конца. А чтобы никто не подумал, что проблемы из-за его безалаберности, он решил все валить на глюк в системе. Случится отказ рабочей станции, Админ вздыхает, во всем виноват глюк. Возникнут проблемы с сетевой печатью, снова та же песня, опять виноват глюк. Надоело это всем однажды. Решили разобраться через го-
сказки лову Админа и пригласили в Контору Эксперта. Тот, конечно, сразу нашел причину всех проблем. Админ был с позором изгнан с работы. И хотя он был неграмотным, но одновременно и весьма предприимчивым, тот Админ. И поэтому вскоре нашел другую работу. Однако и там повторилась прежняя история, и в той локальной сети появился вездесущий глюк. Снова сменил работу Админ, и глюк сменил сеть следом за ним. Так и повелось. Но молва бежит впереди Админа. И перестали его брать на работу все, кто знает о нем. И дали ему другое имя – Ламер. Так и ходят с тех пор вместе Ламер и его спутник – вездесущий глюк.
8. Сказка об Админе-Дурачке Жил-был Администратор. Да такой был неумеха: за что ни возьмется, все завалит. Ничего у него не получалось. Со всех работ его гнали. Даже прозвание ему придумали – Дурачок. Совсем отчаялся Админ-Дурачок. Хотел уж пойти работать курьером. Но был у него друг Хакер, и подсказал ему Хакер адрес сетевого форума заветного. Сходил на тот форум Админ и получил там совет скачать с далекого-предалекого Фтп неведомую операционную систему. Так и сделал Дурачок. Скачал он эту систему и запустил у себя на работе. И, о чудо, все заработало. Стал он эту систему ставить везде. Никто этой системы не знает и не понимает. Знает только он. И стали его везде звать. Стали уважать. Прозвище его обидное забыли. Стали звать его не Дурачком, а Линуксоидом. Да не долго продолжалось его счастье. Другие администраторы тоже освоили эту операционную систему, принялись ее везде внедрять. И тогда смогли заказчики сравнить работу настоящих администраторов и Линуксоида. И оказалось, что Линуксоид все тот же Админ-Дурачок.
16. Сказка о персональном компьютере Админа, или Как поссорились Админ и Офисменеджер Жил да был один Админ. Любил он свою работу и больше всего компьютеры. И захотелось ему иметь компьютер не только на работе, но и дома. Компьютеры к тому времени стали вполне компактными, так что желание его ограничивалось лишь стоимостью желаемого. Накопил он денег на XT и купил. А на работе уже появились AT. Он снова принялся копить и купил AT. А на работе уже i386. Купил он i386, а на работе i486dx2-66 и так далее. Задумался Админ, это сколько денег надо, чтобы иметь всегда такой же компьютер, как и на работе ? Понял Админ, что нет конца этой прогрессии. И придумал простой план. Решил он, что надо работе немного поделиться с ним компьютерами. Так и сделал. Но Офисменеджер обнаружил пропажу. Админа не уволили, так как был он способным и нужным работником. Но компьютер ему пришлось вернуть. С тех пор поссорились Админ с Офисменеджером. Каждый Админ борется с желанием утащить с работы компьютер,
№8, август 2005
а Офисменеджер своим видом напоминает о его скрытой слабости. А каждый Офисменеджер подозревает, что Админ норовит стянуть с работы компьютер и раздражается от того, что нет у него технических знаний, чтобы проконтролировать Админа.
32. Сказка о волшебном пароле В тридевятой Конторе, в тридесятом Филиале работал системный Администратор. И все у него в руках спорилось. За что ни возьмется, не успеешь оглянуться – готово. Ничего у него не ломалось. Аптайм серверов рос день ото дня. И позавидовал ему Офисменеджер того филиала. Стал он нашептывать Начальнику, что недоброе задумал Админ, мол, хочет он хорошей работой усыпить бдительность, а сам задумал уволиться. Поручил Начальник своему Офисменеджеру разузнать секрет Админа. И стал Офисменеджер выпытывать у Администратора, расскажи, мол, в чем твой секрет. Но не соглашался Администратор на уговоры, был тверд и деловит. Тогда задумал недруг коварство. Знал он за Админом слабость – любовь к пиву. Принес он Админу пива любимого. Расслабился Администратор, размечтался. Показалось ему, что друзья кругом. И рассказал он тогда, почему так у него все хорошо выходит. Знал он волшебный рутовый пароль! И поделился он этим знанием с Офисменеджером. А наутро, когда пиво кончилось и запах солодовый выветрился, пришел Админ на работу и узнал, что место его уже занято. Что воспользовался его волшебным паролем Офисменеджер да и взял на работу Ламера. И теперь Ламер выполняет всю работу вместо Админа. Так остался Админ из-за своего длинного языка да любви к пиву без работы! А Ламер недолго проработал вместо Админа. Выгнали его вместе с Офисменеджером. Оказалось, что знание волшебного рутового пароля недостаточно, чтобы всю работу Администратора выполнять. Хотя болтливого Админа на работу обратно не приняли.
64. Сказка о тщеславном Начальнике и трех Сертификатах За далекими сетевыми рутерами, за километрами оптоволоконного кабеля, в одном далеком Офисе работал Админ. Был руководителем того Офиса тщеславный Начальник. Не устраивало его то, что Админ просто выполнял всю работу. Хотел Начальник иметь возможность похвалиться перед другими начальниками. И подсказал ему подхалим Офисменеджер, что в иностранных офисах, расположенных за многими хопами от их Офиса, водятся дивадивные Сертификаты квалификационные! И поручил Начальник Админу во что бы то ни стало добыть такой сертификат. Иначе, сказал он, уволит Админа по несоответствию! Делать нечего, отправился Админ в путь в далекую сеть Оракл. Вернулся оттуда с Сертификатом по Оракл. Но не унимается Начальник, и пуще прежнего науськивает его Офисменеджер. Посылают они Админа в другую даль-
89
сказки нюю сеть Майкрософт. Добыл и этот сертификат Админ. Вернулся на работу и ждет, что его оставят в покое. Но неймется Начальнику да Офисменеджеру. И снова его отправили за сертификатом в сеть Циско. Получил и этот Сертификат Админ. Да обратно уже не вернулся. С тремя Сертификатами ему лучшую работу предложили другие начальники. А тщеславный Начальник и его Офисменеджер остались ни с чем!
128. Сказка об Админе-идеалисте Жил да был Админ. Работал помаленьку. Все делал, как надо. На работе его уважали и ценили. Лишь случится малейшая проблема, он тут как тут и все исправляет. Но хотелось ему идеала. Хотелось сделать так, чтобы все работало еще лучше, чтобы совсем не ломалось, чтобы все было запрограммировано заранее. Админ был очень способный. Он потратил много труда и личного времени, чтобы добиться идеального функционирования управляемой им системы. И вот настало время, когда его участие в работе системы стало минимальным. Админ расслабился. У него появилось много свободного времени. Он его с пользой тратил. Но на работе стали замечать, что система работает без участия Администратора. И сделали свои выводы. Однажды Админа уволили. Захотелось тут Админу вернуть все на место. Захотелось, чтобы снова что-нибудь отказало, чтобы снова его позвали. Но этого не случилось. Система, настроенная нашим Админом, еще долго работала бесперебойно. А ему пришлось искать другую работу.
256. Сказка о жадном Начальнике Далеко-далеко, за много хопов от нас, жил да был Админ. Управлял местной локальной сеткой. Выполнял всю нужную работу. Был очень сметлив. Он рассудил, что лучше будет, если система станет работать максимальное время, а он ее обслуживать минимальное. Так и сделал, как решил. Все работало замечательно, ломалось редко, и так же редко видели, чтобы Администратор что-то исправлял. И подумалось тогда местному Начальнику с подсказки вредного Офисменеджера, что несправедливо это, когда все работают, Админ отдыхает, а работает лишь изредка. Решили они, что надо Админу платить пропорционально труду. А поскольку они редко замечали труд Админа, так как были непрофессионалами, то все это привело к понижению зарплаты Администратора. Но Админ не согласился с такой оценкой своего труда и уволился. Приняли на работу Ламера. Все изменилось в локальной сети. Ламер не покладая рук что-то настраивал, не пригибая ног везде бегал, не закрывая глаз за всем наблюдал. Начальник и Офисменеджер были очень довольны. Но со временем оказалось, что теперь работает лишь один Ламер, все же остальные ждут, пока он все исправит. Спохватились тут Начальник с Офисменеджером. Стали звать Админа обратно. Да он к ним не вернулся.
90
512. Сказка об Админе-Хакере В некотором Офисе, в некотором Отделе работал Админ. Был он трудолюбив. Высоко было его мастерство. Все он делал просто замечательно. Но показалось ему, что недостаточно ценят его труд, что недостаточно возносят его способности. И задумал тогда Админ стать умелым Хакером. Придумал ник позагадочнее, да и начал временами выходить в Сеть на промысел недобрый. Узнали везде о нем как о Хакере, перед мастерством которого не устоит ничто. Админа никто не знал за пределами Отдела, а вот о Хакере знали все и боялись все. И тут еще более Админ запечалился от такой несправедливости, что его снова не уважают соответственно его способностям. Тогда Админ, прикинувшись Хакером, взломал собственную сеть. Да опять плохо получилось. Ведь вышло, что он как Админ уступает самому себе как Хакеру. И тогда Админ стал убеждать всех, что поможет избавить их от Хакера. Так долго убеждал, так долго доказывал, что проговорился, и истина стала всем известна. Хакера наказали, а Админа уволили с работы. И никто не оценил, что он, как и обещал, избавил Сеть от Хакера.
1024. Сказка о неистребимом вирусе В одной далекой-предалекой локальной сети случилась беда. Напал на эту сеть вирус. Админу, конечно же, сразу стали жаловаться пользователи. И он принялся неутомимо вычищать вирус из пользовательских данных. Почистит один компьютер, а ему сообщают, что заражены вирусом еще четыре. Почистит один файл, а сканер показывает, что еще шестнадцать. Ответит на одну заявку в техподдержку, а их приходит еще 256! Очень устал Админ. Почти отчаялся. Но осенила его мысль, что вирус ему попался неистребимый! И как понял это, то сразу же перестал суетиться и тратить время на бесполезную борьбу. Достал он из потаенного шкафчика заветные бэкапы и дистрибутивы да и переставил зараженные станции заново все разом. И с тех пор Админ был спокоен при любой вирусной атаке, так как знал, что вирус – это проблема Пользователя, а у Админа на самый неистребимый вирус есть потаенный шкафчик с заветными бэкапами!
2048. Сказка о жене Админа, или Почему так мало Админов-женщин Жил-был Админ. Все хорошо складывалось у него на работе. Его ценили. Постоянно повышали зарплату. Но работа не могла длиться 24 часа. И наступало время, когда Админ приходил домой. Пусто было в его доме. И захотелось ему уюта. Нашел Админ жену! Все у него с женой было прекрасно. Он постоянно был окружен заботой. Но снова стало ему неуютно. Захотелось еще, чтобы, как и на работе, был у него дома компьютер. Купил он себе компьютер. Теперь не было человека счастливее его. На работе успех.
сказки Кончилась работа – дома уют и внимание. Устал от внимания – включил компьютер и снова как на работе. Да не устроило такое жену. Её ведь нельзя на время неиспользования выключить. Бросила она Админа. Долго Админ решал эту нетехнологическую проблему. Сделал правильные выводы, нашел новую жену и повел себя так, что больше она его не бросала. Но с тех пор у всех женщин осталось настороженное отношение к компьютерам.
4096. Сказка о настырном Пользователе Однажды в Контору пришел работать настырный Пользователь. Захотелось ему показать, что понимает он много в сетевых технологиях. Думал он тем самым сделать так, чтобы его заметил Начальник. Подготовил для него Админ рабочее место, как всем и как всегда делал. А тому все не хорошо. Претензии предъявляет. Говорит, мол, не так надо делать. Раньше, мол, в другой конторе все делалось иначе и лучше. Встретили его слова поддержку у Офисменеджера. Тот уже давно невзлюбил Админа. Но Администратор им попался непростой. Стал он все делать так, как они ему скажут. И все сделанное описывать в отчетах. Скажут так, сделает так. Скажут переделать эдак, переделает, не спросив причины. И вот пришло время подводить итоги работы всей Конторы. Админ предъявил все свои отчеты и показал, что все время был занят. Офисменеджер ничего не показал, как обычно. А вот настырный пользователь, как оказалось, все это время был занят настройкой своего рабочего места, а не той работой, что ему надо делать. Понял это Начальник. Выгнал он настырного Пользователя, а Офисменеджеру запретил встревать в технологические споры. И все остальные пользователи этой Конторы сделали соответствующие выводы.
8192. Сказка об админском кошмаре Жил да был самоуверенный Админ. Он не без оснований был такой самоуверенный. Он все держал под контролем. У него все работало как надо. И уже давно. И стало ему казаться, что все работает только благодаря тому, что он такой хороший. Что во всем лишь его личная заслуга. Возгордился Админ этим. Стал направо и налево всем хвалиться да ручаться, что пока он сетью управляет, то и не будет никаких проблем. И сам настолько в это уверовал, что когда в Конторе временно выключили электропитание и начали отключаться компьютеры, то осознание собственного бессилия стало для него ужасным потрясением. Он с потерянным видом сидел среди жалобно верещащих упсов, слушал, как один за другим, снижая обороты, останавливаются винчестеры и кулеры, и его слезы капали на консольную клавиатуру. Потом, когда снова включили электричество, Админ, ничего никому не объяснив, уволился из Конторы навсегда и даже сменил ник и электронную почту от столь сильного пережитого им стресса. 1
И с тех пор нет большего кошмара для самых мужественных Админов, как отключение электричества!
16384. Сказка об отпуске Админа Однажды в далекую-предалекую Контору, где работал Админ, пришло лето. И пользователи стали уходить в отпуска. Работы стало меньше. И задумался Админ, а что если и ему уйти в отпуск, чтобы отдохнуть. Стал прикидывать и так, и эдак. Чтобы ничего не сломалось, чтобы ничего не отказало, чтобы ничего не случилось. Пока планировал, лето и кончилось. На другой год снова наступило лето. Теперь у Админа все было согласовано технологически, и он сразу обратился к Офисменеджеру с просьбой об отпуске. Но теперь стал прикидывать Офисменеджер. То одно его не устроит, то другое. Админ все переделывает и согласовывает. И вот уже осталось последнее согласование, как Офисменеджер сам ушел в отпуск. И снова Админ остался без отдыха. Только на третий год смог Админ вовремя уйти в заслуженный отпуск. Так и повелось с того времени: Админ работает меньше всех, но и отдыхает реже всех.
32768. Сказка об Админе-аутсорсере, или Об Абсолютном Админе Далеко от этих мест за много-много хопов работал один Админ. Был он необычайно способным. Все делал быстрее и лучше остальных. Особенно хорошо получалось у него удаленное администрирование. Можно даже сказать, что он все делал через линии связи. И это будет верно, так как был этот Админ аутсорсером. Обслуживал он несколько контор. Все его клиенты были довольны его работой. Лишь изредка он посещал эти конторы, так как сервера ломаются нечасто, а зарплату можно получать и на банковский счет. Но со временем персонал контор менялся, и все меньше пользователей знало Админа-аутсорсера в лицо. Пользователям казалось, что по электронной почте им отвечает робот. Что новые программы, которые они обнаруживали, придя утром на работу, ставятся сами собой. Что их рабочие станции не ломаются никогда. И что то оборудование, которое Админ заказывал с доставкой в эти конторы, привозят поставщики по своей инициативе. И настал такой день, когда, посетив одну из обслуживаемых контор, был Админ задержан на проходной, и никто, представьте себе – никто, не признал в нем сотрудника этой конторы. Опечалился Админ и поспешил в другую контору. Но и там повторилась та же история. И в третьей тоже. И во всех остальных. Очень был Админ огорчен. Решил он более не посещать эти конторы вообще. И далее не переставал грустить об утраченном человеческом присутствии. Лишь то скрашивало его печаль, что зарплата от контор приходила в банк регулярно, как и прежде. Error: переполнение регистра. Авост1!
Примечание: Авост – сокращение от «аварийный останов».
№8, август 2005
91
книжная полка DB2: решения по интеграции Роб Катлип, Джон Медик Авторы книги, опираясь на свой личный опыт, повествуют о проблемах и решениях в области интеграции базы данных DB2 с различными приложениями. Вы узнаете о том, как согласовать DB2 с веб-серверами, инструментами разработки, инфраструктурами обмена сообщениями. Подробно описаны: разработка решений, тенденции, технология и инструментарий, интеграция и управление бизнес-процессами, интеграция информации, CRM: программа расширения услуг посредством электронной почты и с использованием DB2. Отдельная глава посвящена теме динамического бизнеса: B2B и B2C. Актуальная тема электронной коммерции рассмотрена достаточно подробно: проектирование масштабируемой архитектуры электронной коммерции, веб-ярус, ярус предприятия, управление бизнес-процессом электронной коммерции. По большей части изложенный материал рассчитан на интеграторов и руководителей IT-отдела. Издательство «КУДИЦ-ОБРАЗ», 2005 г. – 320 стр. ISBN 5-9579-0047-8 (ориг. 0-20017-5485-1).
WMI. Программирование на JavaScript и VBScript Ален Лиссуар Основная задача книги – научить читателя эффективно использовать WMI (Windows Management Instrumentation). Автору определенно удалось достичь этой цели. Повествование книги начинается с объяснений основ Windows Script Host (рассмотрены использование возможностей XML, контроль за выполнением, шифрование кода, отладка сценариев). В главе, посвященной началу работы с WMI, автор повествует о том, что такое DMTF, WBEM, CIM, xmlCIM. Тема языка запросов WMI и практики написания сценариев с WMI раскрыта очень подробно, рассказано о моникере, исследовании API-сценариев, просмотре имен репозитария CIM и сценариях для исследования репозитария CIM. Отдельно рассмотрены продвинутые техники написания сценариев WMI (асинхронная работа с экземплярами CIM, WMI DateTime Helper, расширение WMI для ADSI, представление данных WMI в XML). Большое внимание уделяется программированию с использованием событий WMI. Книга написана простым и доступным языком, а большое количество примеров позволит лучше усвоить излагаемый материал. Издательство «КУДИЦ-ОБРАЗ», 2005 г. – 544 стр. ISBN 5-9579-0089-3 (ориг. 1-55558-266-4).
№8, август 2005
Популярные Web-сервисы. Практика использования Уилл Айверсон Издание будет интересно прежде всего Java-разработчикам, участвующим в создании веб-проектов. Основная тема книги – работа с API популярных веб-служб, таких как PayPal, amazon.com, google. com, CDDB, eBay, FedEx. В качестве примеров взаимодействия с вышеуказанными службами автор рассматривает восемь проектов – анализ конкуренции (анализ данных из amazon.com, eBay и google. com), аукционы и доставки (рассмотрены вопросы интеграции FedEx и eBay), система оплаты счетов и факсимильная связь (использование PayPal для оплаты счетов). Также представлены проекты: сидицированный поиск, агрегатор новостей, каталог аудиодисков, страница последних новостей (rss), автоматизация ежедневных обсуждений. Любопытны мысли автора о будущем развитии технологий вебслужб (таких как REST, UDDI, BPEL/BPEL4WS). Издательство «КУДИЦ-ОБРАЗ», 2005 г. – 240 стр. ISBN 5-9579-007-X (ориг. 0-596-00642-X).
Windows server 2003. Для профессионалов Алексей Вишневский Среди подобных изданий эту книгу можно выделить четкой систематизацией излагаемого материала. Круг рассмотренных вопросов достаточно широк. В книге подробно рассказано о протоколе аутентификации Kerberos v5 (реализация, описание и структура протокола, служба ключей, варианты аутентификации), стеке протоколов TCP/IP (рассмотрены базовые сведения, основные утилиты, большинство широко используемых протоколов). Отдельные главы посвящены службам DNS и DHCP. Как логическое продолжение главы, посвященной основам TCP/IP, в книге рассмотрены вопросы управления маршрутизацией (включая такие сложные темы, как протоколы RIP и OSPF). Большое внимание уделено рассмотрению AD. Автор не обошел вниманием и рассмотрение механизмов групповой политики и WINS. В книге также рассмотрены: мониторинг производительности ОС Windows, развертывание службы сертификации, служба удаленной установки, протокол SNMP. Несомненный интерес представляют главы, посвященные интеграции Windows server 2003 с серверами Novell NetWare и UNIX. Издательство «Питер», 2005 г. – 767 стр. ISBN 5-94723614-1.
Рубрику ведет Александр Байрак
93
bugtraq Выполнение произвольного кода и отказ в обслуживании в различных диссекторах в Ethereal Программа: Ethereal версии до 0.10.11. Опасность: Критическая. Описание: 1. Удаленный пользователь может с помощью специально сформированного пакета аварийно завершить работу приложения. Уязвимость существует в диссекторах: AgentX, BER, CAMEL, DCERPC, DHCP, DOCSIS, HTTP, IS-IS LSP, LDAP, NCP, PER, RADIUS, SCTP, Telnet. 2. Злоумышленник может вызвать зацикливание приложения при обработке специально сформированных пакетов в диссекторах: 802.3, BER, DHCP, H1, MEGACO, SMPP. 3. Злоумышленник может вызвать разыменование нулевого указателя в диссекторах: CAMEL, GIOP и WBXML. 4. Атакующий может вызвать переполнение буфера в SMB-диссекторе. URL производителя: www.ethereal.com. Решение: Установите последнюю версию (0.10.12) с сайта производителя.
Выполнение произвольного кода в Sophos Anti-Virus Программа: Sophos Anti-Virus версии до 3.96.0; версии до 4.5.4. Опасность: Высокая. Описание: Переполнение буфера в Sophos Anti-Virus может позволить злоумышленнику выполнить произвольный код на целевой системе. Подробности уязвимости не раскрываются. URL производителя: www.sophos.com. Решение: Установите исправление с сайта производителя.
Обход каталога в MDaemon Программа: MDaemon версии до 8.1.0. Опасность: Высокая. Описание: Уязвимость существует в контентном фильтре приложения при обработке вложенных файлов со специально сформированными именами. Злоумышленник может создать специально сформированный файл, содержащий в своем имени символы обхода каталога, и записать его в произвольную директорию на системе. URL производителя: www.altn.com. Решение: Установите исправление с сайта производителя.
Выполнение произвольного кода в Cisco IOS при обработке IPv6-пакетов Программа: Cisco IOS 12.4 и более ранние версии. Опасность: Высокая. Описание: Удаленный пользователь может послать специально сформированный IPv6-пакет логическому интерфейсу устройства и вызвать перезагрузку устройства или выполнить произвольный код на целевой системе. URL производителя: www.cisco.com. Решение: Установите исправление с сайта производителя.
94
Обход ограничений безопасности в IPSec во FreeBSD Программа: FreeBSD 5.3, 5.4. Опасность: Низкая. Описание: Уязвимость существует в реализации алгоритма аутентификации AES-XCBC-MAC в IPSec, что приводит к тому, что для аутентификации используется ключ по умолчанию вместо ключа, указанного администратором. Злоумышленник может послать специально сформированные пакеты для аутентификации и обойти какие-либо ограничения на уровне IP. Удачная эксплуатация уязвимости требует выключенного шифрования данных. URL производителя: www.freebsd.org. Решение: Установите исправление с сайта производителя.
Однобайтовое переполнение буфера в mod_ssl при обработке CRL Программа: mod_ssl. Опасность: Высокая. Описание: Уязвимость существует при обработке CRL (certificate revocation lists). Удаленный пользователь может создать специальным образом CRL, который при обработке функцией callback() вызовет однобайтовое переполнение буфера и даст возможность злоумышленнику выполнить произвольный код на целевой системе. URL производителя: www.modssl.org. Решение: Установите исправление с сайта производителя.
Переполнение буфера в CA BrightStor ARCserve Backup и Enterprise Backup-агентах Программа: BrightStor ARCserve Backup v9.01, r11.0, r11.1; BrightStor Enterprise Backup 10, 10.5. Опасность: Критическая. Описание: Переполнение буфера обнаружено при обработке входных данных. Злоумышленник может послать специально сформированные данные на порт приложения 6070, вызвать переполнение буфера и выполнить произвольный код на целевой системе с привилегиями Local System или вызвать отказ в обслуживании. URL производителя: www.ca.com. Решение: Установите исправления с сайта производителя.
Отказ в обслуживании в ядре Linux Программа: Linux kernel версии до 2.6.13-rc6. Опасность: Средняя. Описание: Уязвимость существует при обработке связок ключей (keyrings). Локальный пользователь может определенным образом создать связку ключей, что приведет к отказу в обслуживании системы. URL производителя: www.kernel.org. Решение: Установите исправление с сайта производителя.
Составил Александр Антипов
подписка на II полугодие 2005 Российская Федерация
! Казахстан – по каталогу «Российская Пресса» через
Каталог агентства «Роспечать» ! Подписной индекс: 87836 Объединенный каталог «Пресса России» Адресный каталог «Подписка за рабочим столом» Адресный каталог «Библиотечный каталог» ! Альтернативные подписные агентства: Агентство «Интер-Почта» (095) 500-00-60, курьерская доставка по Москве Агентство «Вся Пресса» (095) 787-34-47 Агентство «Курьер-Прессервис» Агентство «ООО Урал-Пресс» (343) 375-62-74 ! Подписка On-line http://www.arzy.ru http://www.gazety.ru http://www.presscafe.ru
! Беларусь – по каталогу изданий стран СНГ через РГО
! Подписной индекс: 81655
ОАО «Казпочта» и ЗАО «Евразия пресс»
«Белпочта» (220050, г.Минск, пр-т Ф.Скорины, 10)
! Узбекистан – по каталогу «Davriy nashrlar» российские
!
! !
СНГ В странах СНГ подписка принимается в почтовых отделениях по национальным каталогам или по списку номенклатуры АРЗИ: ! Азербайджан – по объединенному каталогу российских изданий через предприятие по распространению печати «Гасид» (370102, г. Баку, ул. Джавадхана, 21)
!
издания через агентство по распространению печати «Davriy nashrlar» (7000029, Ташкент, пл.Мустакиллик, 5/3, офис 33) Армения – по списку номенклатуры «АРЗИ» через ГЗАО «Армпечать» (375005, г.Ереван, пл.Сасунци Давида, д.2) и ЗАО «Контакт-Мамул» (375002, г. Ереван, ул.Сарьяна, 22) Грузия – по списку номенклатуры «АРЗИ» через АО «Сакпресса» ( 380019, г.Тбилиси, ул.Хошараульская, 29) и АО «Мацне» (380060, г.Тбилиси, пр-т Гамсахурдия, 42) Молдавия – по каталогу через ГП «Пошта Молдавей» (МД-2012, г.Кишинев, бул.Штефан чел Маре, 134) по списку через ГУП «Почта Приднестровья» (МD-3300, г.Тирасполь, ул.Ленина, 17) по прайслисту через ООО Агентство «Editil Periodice» (2012, г.Кишинев, бул. Штефан чел Маре, 134) Подписка для Украины: Киевский главпочтамп Подписное агентство «KSS» Телефон/факс (044)464-0220
Подписные индексы:
81655 по каталогу агентства «Роспечать»
87836 по каталогу агентства «Пресса России»
№8, август 2005
95
СИСТЕМНЫЙ АДМИНИСТРАТОР №8(33), Август, 2005 год РЕДАКЦИЯ Исполнительный директор Владимир Положевец Ответственный секретарь Наталья Хвостова sekretar@samag.ru Технический редактор Владимир Лукин Редакторы Андрей Бешков Алексей Барабанов Рашид Ачилов
ЧИТАЙТЕ В СЛЕДУЮЩЕМ НОМЕРЕ: Ремонтируем и восстанавливаем жесткие диски
По вопросам распространения обращайтесь по телефону: (095) 928-8253 (доб. 120)
Ценность обрабатываемой информации с каждым годом неуклонно растет, а надежность жестких дисков, напротив, стремительно падает. Но даже после физического выхода жесткого диска из строя в 90% случаев информацию можно восстановить! Зачастую даже без специального оборудования! Речь пойдет об аппаратных отказах (дефектах поверхности, выходе электроники из строя), также обсудим проблемы выбора накопителя: сравним статистику отказов для разных моделей и производителей и сравним легкость ремонта.
107045, г. Москва, Ананьевский переулок, дом 4/2 стр. 1 тел./факс: (095) 928-8253 Сайт журнала: www.samag.ru
Домены Windows 2000/2003 – отказываемся от рабочей группы
РЕКЛАМНАЯ СЛУЖБА тел./факс: (095) 928-8253 Константин Меделян reсlama@samag.ru Верстка и оформление maker_up@samag.ru Дизайн обложки Николай Петрочук
РУКОВОДИТЕЛЬ ПРОЕКТА Петр Положевец УЧРЕДИТЕЛИ Владимир Положевец Александр Михалев ИЗДАТЕЛЬ ЗАО «Издательский дом «Учительская газета» Отпечатано типографией ГП «Московская Типография №13» Тираж 8400 экз. Журнал зарегистрирован в Министерстве РФ по делам печати, телерадиовещания и средств массовых коммуникаций (свидетельство ПИ № 77-12542 от 24 апреля 2002 г.) За содержание статьи ответственность несет автор. За содержание рекламного обьявления ответственность несет рекламодатель. Все права на опубликованные материалы защищены.
96
Очень часто наблюдается тенденция быстрого роста локальных сетей небольших компаний. Сначала это дватри компьютера для бухгалтерии, затем еще по одному для директора, его заместителя, секретаря, нескольких менеджеров и т.д. Через какое-то время их количество опять увеличивается, так как штат сотрудников расширяется. Однако все эти компьютеры являются членами рабочей группы, в которой каждый участник равноправен. Администрировать такую сеть становится неудобно, так как понятие «цен-
трализованное управление» и «рабочая группа» являются взаимоисключающими. Именно в этот момент системному администратору приходится принимать решение о переходе к доменной структуре. С какими трудностями придется столкнуться в первую очередь? Что необходимо предусмотреть заранее, чтобы процесс перехода прошел без сучка и задоринки? В данной статье я попытаюсь обобщить свой опыт подобных внедрений, чтобы заранее облегчить вашу задачу.
Загрузочный Flash-диск с DOS и FreeBSD Вам удалось уговорить руководство закупить новый сервер, и вот он, красавец, стоит рядом, сверкая ручками 19-дюймового корпуса... Одна проблема – как поставить на него операционную систему? Дисковода гибких дисков в нем нет, CD-ROM тоже... Можно было бы, конечно, открыть его и воткнуть CD-ROM на время установки... А если придется восстанавливать систему? Вынимать из стойки? Так только за то время, пока будешь вынимать, весь телефон оборвут. Если загрузиться с USB Flash-диска? Его создавать надо... Впрочем, ничего сложного в этом нет, мы расскажем вам, как очень просто создать загрузочный Flash-диск с разделами DOS и FreeBSD.
Уважаемые читатели! Спешите оформить подписку на первое полугодие 2006 года! Приобрести новые и старые номера журнала вы можете через интернет-магазины LinuxCenter.ru и Allsoft.ru.
Доставка почтой в любую точку России.