sysadmin2012-03

Этот загадочный MTU

№3(112) март 2012

HTML5 – технологии будущего Продолжаем погружение

Оптимизируем FreeRADIUS для защиты беспроводной сети

Управление IP-телефонными аппаратами

Проект ownCloud

Облачное хранение и обмен

Проект m23

Управление Linux-системами

Remote Desktop Gateway Шлюз удаленных рабочих столов

Искажающий фактор Исследуем рынок ПО

Информационные тромбы Десять правил для решения проблемы ИТ-управление

Облачные технологии

Оптимизация расходов на ИТ

Рассмотрим ряд способов оптимизации расходов, а также подводные камни, которые могут при этом возникнуть

Полетят ли КИС в облака?

Какие преимущества и недостатки имеет перенос корпоративных информационных систем в облака

Виртуализация Red Hat Enterprise Virtualization 3 На массовом рынке RHEV развивается не очень быстро. Что несет релиз RHEV3, чтобы изменить эту ситуацию?

НЦПР

В номере

37

55

69

СОбытие

Облачные технологии

05 Python на границе Европы и Азии. 10 февраля в Екатерин-

37 Проект ownCloud. Организация облачного хра-

бурге состоялась Ekbpy (www.ekbpy.ru) – первая тематическая конференция, посвященная языку программирования Python и смежным с ним технологиям. Валентин Синицын

нения и обмена файлами. В Интернете можно найти несколько Open Source-решений, позволяющих организовать обмен файлами. Мне подошел ownCloud. Ренат Гараев

Острый угол

06 Искажающий фактор. Как обстоят дела на совре-

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

Исследование

42 Добро пожаловать на планету AIX. Для работы аппаратного обеспечения требуется его программная составляющая. И если для массового x86-рынка количество операционных систем насчитывает более двух дюжин, то для корпоративных гигантов это число, как правило, не более двух. Антон Борисов

Администрирование ИТ для банков Аудит

10 Оптимизируем FreeRADIUS для защиты беспровод-

ной сети с помощью Heimdal-Kerberos. Часть 1. Как разрешить

доступ сотрудников к беспроводной сети предприятия по учетной информации из единой базы данных Heimdal-Kerberos?

48 DLP-система DeviceLock в банках. Архитектура

и развертывание. Программный комплекс DeviceLock Endpoint DLP Suite, разработанный российской компанией «Смарт Лайн Инк», предназначен для управления доступом пользователей ОС семейства Windows к периферийным устройствам хранения и обработки данных, каналам сетевых коммуникаций.

Михаил Кондрин

15 Управление правами доступа к LUN. Используя LUN, можно создать распределенную файловую систему с большим дисковым пространством. Как им управлять в автоматическом режиме? Иван Коробко

Инструменты

18 Управление Linux-системами с помощью m23. По мере расширения парка Linux-машин администратору потребуется удобный инструмент для управления и распространения ПО. Эту задачу вполне может решить сервер m23. Сергей Яремчук

24 Этот загадочный MTU. Причиной неработоспособности сегмента VPN может быть MTU. Проведем разбор реальной ситуации, в которой именно MTU был «корнем зла», вспомним структуру IP-пакетов и найдем решение для шлюза с ОС FreeBSD и Windows-клиентов. Рашид Ачилов

Удаленная работа

30 RD Gateway. Шлюз удаленных рабочих столов. Расскажу о новой технологии Remote Desktop Gateway, доступной начиная с Windows Server 2008 и несколько доработанной в Windows Server 2008 R2. Что может дать внедрение шлюза удаленных рабочих столов? Станислав Шпак

2

Илья Кузьминов

Тестирование Виртуальные решения

50 VMware vSphere. Оценка производительности дис-

ковой подсистемы ВМ. Оценим зависимость производительности дисковой подсистемы виртуальной машины VMware vSphere 5 в зависимости от выбранного типа виртуального SCSI-контроллера. Андрей Горемульта

Безопасность Механизмы защиты

52 Защита данных на ПК с ОС Microsoft. На основе про-

дуктов и решений «Аладдин Р.Д.». Часть 2. Один из важнейших аспектов информационной безопасности – защита данных ограниченного доступа. Продолжим рассмотрение механизмов обеспечения конфиденциальности данных, хранимых на рабочих станциях на основе решений «Аладдин Р.Д.». Леонид Шапиро

55 Позади закрытых дверей. Часть 2. Port knoсking

«по-взрослому». Рассмотрим двухсторонний гибридный метод и скрытую авторизацию по единственному криптопакету. Игорь Савчук

март 2012 системный администратор

В номере БИТ. Бизнес & Информационные технологии

Сетевая безопасность

60 Безопасность баз данных. Следим за версиями

специальное приложение

наших программ. Наличие уязвимостей в программном коде баз данных

98 Как оптимизировать расходы на ИТ. Расходы

выявить несложно. Главное, вовремя устранить их.

на ИТ-инфраструктуру могут быть довольно существенными. Рассмотрим способы оптимизации расходов.

Юрий Денисов

Андрей Бирюков

ИТ для банков

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

103 Платформа eDocLib по модели SaaS. Новый веб-сервис по хранению и обработке данных. На вопросы «Системного администратора» отвечает Сергей Полтев, менеджер по продуктам компании ЭОC. Евгений Захаров

Угрозы

104 Red Hat Enterprise MRG Realtime. Linux реального времени – война за микросекунды. Для таких задач, когда просто

64 Принтер как источник угрозы. Антируководство

«быстро» недостаточно и нужно «гарантированно быстро», существуют системы реального времени.

Виталий Иванов

по взлому локальных сетей. Часть 2. Сетевые принтеры и МФУ. Какие скрытые проблемы безопасности и конфиденциальности они порождают? Как следует защищать и настраивать принтеры? Игорь Савчук

Алексей Ермаков

106 Полетят ли КИС в облака? В пользе облаков для частных пользователей уже мало кто сомневается, а вот стоит ли переносить в них корпоративные информационные системы?

IP-телефония

Сергей Горшков

69 Управление IP-телефонными аппаратами. Любой

108 Облачная фильтрация интернет-ресурсов.

IP-телефон вне зависимости от его реализации (программная или аппаратная) обладает огромным количеством функциональных возможностей. Рассмотрим пример централизованной настройки программных абонентских терминалов для IP-телефонии.

Безопасный доступ в Интернет – приоритетная задача ИТ-отделов.

Александр Морозов

Алексей Кищенко

109 Не шпион, а разведчик. DLP-решение на базе Mipko Employee/Terminal Monitor. Социальные сети всё чаще становятся каналом утечек внутренней информации.

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

Александр Кириленко

Технологии

74 HTML5 – технология будущего. Продолжаем погру-

жение. Революция HTML5 идет прямо сейчас, стандарт далек от того, чтобы

110 Red Hat Enterprise Virtualization 3. Для многих специалистов виртуализация от Red Hat до сих пор выглядит неоднозначно. Что несет новый релиз RHEV3, чтобы изменить эту ситуацию? Оксана Курышева

быть сформированным окончательно. Кирилл Сухов

Карьера/Образование ИТ-управление

82 Информационные тромбы. Десять правил для решения проблемы.

Константин Кондаков

Ретроспектива

86 Японские бизнес-фокусы. Уйдя с рынка фотокамер и фототоваров, Konica Minolta продолжает оставаться мировым лидером на других рынках. Владимир Гаков

Лабораторная работа

90 Представление чисел в памяти ЭВМ. Часть 1. Целые числа. В статье разбираются «до бита» форматы хранения чисел в памяти ЭВМ, поэтому она может быть интересной широкому кругу читателей. Павел Закляков

системный администратор март 2012

3

От редакции

Электронную версию – в массы!

Издается с 2002 года Генеральный директор Владимир Положевец Главный редактор Галина Положевец, chief@samag.ru Исполнительный директор Владимир Лукин, maker@samag.ru Главный бухгалтер Надежда Кан, buch@samag.ru Главный редактор электронного приложения «Open Source» Дмитрий Шурупов, osa@samag.ru Отдел маркетинга и рекламы Руководитель отдела Полина Гвоздь, pr@samag.ru, тел.: (499) 277-12-41 Менеджер по рекламе Анастасия Гуркина, gurkina@samag.ru, (499) 277-12-41

Распространение Сергей Ростомов, subscribe@samag.ru, (499) 277-12-41

Редакция журнала «Системный администратор» в 2012 году продолжает увеличивать количество ресурсов, на которых доступна электронная версия издания. Кроме Zinio.com вы можете приобрести цифровую версию в:

Journals.ua Для покупки выложены все вышедшие номера, начиная с 2010 года. Возможна подписка на любой срок — от месяца до года. Издание доступно для чтения как с самого ресурса, так и в offlineридере. В скором времени появятся приложения для iOS и Android. Способы оплаты: >> Webmoney. >> Кредитные карточки. >> Наличный расчет (через банк). Ссылка на издание: http://systemniy-administrator.journals.ua.

Юридический отдел Владимир Столяров, stolyarov@samag.ru Дизайн-макет Марина Рязанцева, Дмитрий Бессонов Дизайн обложки Марина Рязанцева Иллюстрация Виктор Чумачев Экспертный совет Рашид Ачилов администратор телекоммуникационных систем

Алексей Бережной эксперт по администрированию и безопасности

Андрей Бирюков ведущий системный инженер по информационной безопасности

Алексей Вторников эксперт по вопросам разработки программного обеспечения

Александр Емельянов эксперт по администрированию и безопасности Windows‑систем

Константин Кондаков старший директор по ИТ

Samag-usa.com Для покупки выложены все вышедшие номера, начиная с 2010 года. Издание доступно в PDF-формате. Способы оплаты: >> Paypal. >> Кредитные карточки. Ссылка на издание: http://samag-usa.com.

Группа компаний «ИНТЕР-ПОЧТА» Издание доступно для подписки на 2012 год, начиная с любого месяца, в PDF-формате. Способы оплаты: >> Оплата счета (для юридических лиц). >> Наличный расчет (через банк). Ссылка на издание: http://www.interpochta.ru/pages/1?main=izdanie&id=73630. Простота и удобство оплаты, скорость доставки – читайте журнал «Системный администратор» в цифровом виде.

4

Иван Коробко эксперт по автоматизации процессов в Windows-доменах

Валентин Синицын разработчик ПО, к. ф.-м. н., доцент УрФУ

Кирилл Сухов ведущий специалист направления интернет-разработки

Сергей Яремчук эксперт по информационной безопасности

Издатель ООО «Синдикат 13» Адрес редакции 129075, г. Москва, Шереметьевская ул., д. 85, стр. 2, тел.: (499) 277-12-41, факс: (499) 277-12-45 Сайт журнала: www.samag.ru Отпечатано в типографии ООО «Периодика» Тираж 17000 экз. Все права на материалы принадлежат журналу «Системный администратор». Перепечатка материалов и использование их в любой форме, в том числе и в электронных СМИ, запрещена. При использовании материалов ссылка на журнал «Системный администратор» обязательна Материалы в рубрике «Продукты и решения» или отмеченные знаком Adv публикуются на коммерческой основе. Редакция не несет ответственности за достоверность информации в материалах, опубликованных на правах рекламы.

март 2012 системный администратор

Событие Визитка Валентин Синицын, разработчик ПО, автор курсов по Linux и веб-технологиям. Кандидат физико-математических наук, доцент УрФУ

Python на границе Европы и Азии 10 февраля в Екатеринбурге состоялась Ekbpy (www.ekbpy.ru) – первая тематическая конференция, посвященная языку программирования Python и смежным с ним технологиям. Идея оказалась удачной

Мероприятие, организованное порталом IT-People.ru, прошло под патронажем компаний «Яндекс», Naumen, NetAngels, «Айдеко», «БАРС Групп» и Zavod.It. Их участие (к слову, изюминкой Ekbpy в части спонсорских пакетов стали папки «алюминиевого» и «бумажного» спонсоров) в работе конференции было отнюдь не номинальным: сотрудники компаний представили ключевые доклады и провели мастер-классы. Конференция состояла из десяти сорокаминутных докладов, объединенных в два трека, и двух трехчасовых мастер-классов. Регламент выдерживался довольно точно, поэтому все желающие могли беспрепятственно перемещаться между конференц-залами и посетить именно те выступления, которые хотелось послушать. Идея создать в Екатеринбурге свою конференцию по Python возникла у организаторов после посещения PyCon UA. Выяснилось, что едва ли не треть участников этого международного события – россияне, в связи с чем возник резонный вопрос: почему бы не провести нечто подобное в родной стране? Спустя полгода эти планы нашли свое воплощение в Ekbpy. Впрочем, посвященная Python конференция в итоге вышла за заявленные рамки. Например, доклад Антона Патрушева о ZeroMQ с равным успехом мог бы относиться к практически любому другому языку: наличие привязок «к чему угодно», наряду со знакомым сокетоподобным интерфейсом и отсутствием брокера, было приведено в числе основных преимуществ этой очереди сообщений. Выступление Данилы Штаня, представителя популярного в Екатеринбурге портала 66.ru, и вовсе касалось создания распределенных файловых хранилищ, а упомянутая как составная часть предлагаемого решения MongoDB занятно перекликалась с заголовком «Почему я не люблю MongoDB» и основным тезисом: «Новые технологии – это ужасно», высказанными Алексеем Крипичниковым из «Яндекса». Уверен, что читатели, не чуждые чувства юмора (а разве в «СА» есть другие?), уже поняли – Ekbpy прошла в веселой непринужденной атмосфере. Несмотря на серьезность обсуждаемых вопросов, в зале то и дело слышался смех, а слайды с заголовками вроде «Devices (последний, инфа 146%!)» были обычным

системный администратор март 2012

делом. Если что и затрудняло восприятие материала при такой подаче, так это обилие англоязычных терминов и слов; желая провести российскую конференцию и приглашая на нее новичков, было бы лучше «перевести переводимое». Значительная часть докладов была ориентирована на веб-разработчиков (что с учетом специфики Python неудивительно), но организаторам удалось осветить и другие аспекты. Например, Марк Коренберг («Айдеко») рассказал об опыте применения Python для разработки системных инструментов. Гвоздем программы стал доклад Романа Иманкулова (NetAngles) о Celery. Несмотря на отсутствие слайдов, Роман виртуозно перемещался от доски к SSHконсоли, умудряясь не терять при этом внимание аудитории. Доклад плавно перетек в один из двух заявленных мастерклассов, в ходе которого опытным Python-программистам было предложено сократить время отклика приложения Django, выделив «долгоиграющие» операции из контекста обработки HTTP-запроса. Для тех, кто не до конца освоился в Python, параллельно был проведен еще один мастер-класс. Его участникам предлагалось совместно разработать интеллектуальную адресную книгу: каркас приложения (PyQt4) был опубликован на GitHub, и слушатели, объединившись в группы по два-три человека, реализовывали в нем недостающий функционал. Начавшийся с небольшой вводной лекции мастер-класс удачно охватил основные аспекты открытой экосистемы Python: разработку, управляемую тестами, использование системы контроля версий и совместную работу через Интернет. Особенно радует, что организаторы (сотрудники Института компьютерных и математических наук Уральского федерального университета) не стали ограничиваться тривиальными задачками а-ля «подсчитайте, сколько букв в переданном слове», а предложили слушателям реально полезное (пусть и простое) приложение. Ложкой дегтя в бочке меда Ekbpy стало отсутствие заявленного доклада и мастер-класса по Python 3. Однако организаторы вполне прозрачно намекнули, что в их планах значится проведение полноценного PyCon. Пожелаем им удачи и будем с нетерпением ждать. EOF

5

Острый угол Визитка

Владимир Иванов, специалист по информационной безопасности. Увлекается психологией, историей, философией

Искажающий фактор

Как обстоят дела на современном рынке ПО? Глобальная экономика не прощает перекосов. Любой обман, даже замаскированный под «сокращение затрат», рано или поздно принесет с собой множество бед. Но в наших силах сохранить число перекосов.

Странная отрасль Обычный российский ИТ-специалист живет не очень богато. Невысокие зарплаты, не слишком уважительное отношение общества, отсутствие возможности «по-легкому срубить деньжат», все это ставит наших спецов в невыгодное положение. В то же время виртуальный мир полон «историй успеха» и «блестящих перспектив». Достаточно вспомнить Билла Гейтса, Стива Джобса и других, весьма обеспеченных в материальном плане персонажей. В том числе и «отечественного производства». Российские компании закладывают баснословные деньги в ИТ-бюджеты. Вот, например, что пишет сайт «Финмаркет»: «IT-затраты в России по итогам 2011 года увеличатся на 13,3% – IDC» [1]. Собственно, а куда уходят деньги? И почему владельцы некоторых ИТ-компаний богатеют, а большинство ИТ-специалистов вынуждены довольствоваться весьма скромными заработками? Однозначного ответа не существует. Кому-то повезло, а кто-то долго и упорно шел к своей цели напролом. Но всегда есть какие-то нюансы. О них мы и поговорим.

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

6

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

март 2012 системный администратор

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

О послепродажном обслуживании «А что же техподдержка от производителей ПО?» – спросит искушенный читатель. А эта служба работает в первую очередь для того, чтобы принимать жалобы от клиентов и на их основе составлять список необходимых изменений для новых версий. А они будут продаваться за дополнительную плату. Как правило, такие ничтожные нюансы вроде послепродажного обслуживания нигде специальным образом не оговариваются. Они существуют исключительно благодаря доброй воле владельцев компании, выпустившей данный продукт. Иногда при обращении на «горячую линию» можно получить помощь, иногда нет. Или же производитель ПО честно напишет в лицензионном соглашении, что программа распространяется «as is», или по-русски «как есть». Без каких-либо гарантий от производителя. И наличие такой фразы отнюдь не отпугивает руководителей, принимающих решение о покупке. Потому что выбирать самое никудышнее, при этом платное ПО давно стало российской традицией. Еще одна проблема заключается в том, что грамотных спецов у таких, с позволения сказать, «разработчиков» раз, два и обчелся. Мне приходилось наблюдать картину, когда всеми-всеми техническими вопросами – и программированием, и поддержкой пользователей – занимался один-единственный специалист. Все остальные представители фирмы были менеджерами, руководителями, бухгалтерами, имелся даже «специалист по связям с общественностью». Как в пословице: «Один с сошкой, семеро с ложкой». Легко предположить, что будет с клиентами фирмы, когда этот единственный программист уйдет, хлопнув дверью. Часто приходится наблюдать и другую картину: чем старее, крупнее, прибыльнее бизнес разработчика, тем больше в компании бесцеремонности и равнодушия к клиентам. Потому что появляется такой универсальный ресурс, как деньги. А это позволяет не только оплатить практически любую рекламу, но и получить известные преимущества в судебных тяжбах. В итоге возникает парадокс: чем больше получает прибыли компания-разработчик, экономя на своих клиентах, обдирая их до нитки, тем легче ей создать имидж «рыцаря без страха и упрека», якобы стоящего на страже интересов пользователей.

системный администратор март 2012

И уж совсем дело дрянь, если используется пиратское ПО. Тогда и обратиться практически некуда, и приходится поддерживать программы, установленные с невесть откуда взявшегося дистрибутива. Это все помимо реальной угрозы быть привлеченным к уголовной и административной ответственности. Где уж тут думать о поддержке от производителя...

Постоянная работа вхолостую, хотя деньги «уходят на сторону», не может не отражаться на благосостоянии ИТ‑специалистов Все ли так уж плохо? В качестве примера я привел процесс покупки некой прикладной системы. Но такая, с позволения сказать, «модель ведения бизнеса» пронизывает сверху до низу всю программную сферу. Достаточно вспомнить антивирусы, конфликтующие с разного рода прикладным ПО и даже с самой ОС. Или ОС, требующие при выходе новой версии практически полной замены всего парка компьютерной техники и перестающие нормально работать после очередного обновления... Есть замечательное правило: «Клиент всегда прав», и его пока никто не отменял. К сожалению, описанные проблемы уже давно появились в современном компьютерном царстве. Глобальная экономика с ее приоритетами в области агрессивного маркетинга и снижения качества продукции предъявляет свои требования к производителю. И разработчики, которые все еще продолжают выпускать хорошие программы, рано или поздно встают перед выбором: разориться или перевести свой бизнес на рельсы халтурного качества. Это как в фильмах ужасов про заразных зомби – рано или поздно в хороший правильный бизнес вцепится более агрессивная компания, и он превратится в такого же зловредного монстра.

Можно ли смягчить ситуацию? На мой взгляд, гораздо более привлекательными всегда оставались свободные бесплатные продукты, избавленные от ига нечестного предпринимательства. Например, некоторые *nix-системы. Как минимум на их покупку не нужно тратить деньги компании. А специалист, занимаясь их прикручиванием и доводкой до ума, хотя бы может в дальнейшем предложить наработанную технологию в качестве готового решения в другой организации. Нулевая цена за использование вкупе с имеющимся опытом – неплохой аргумент при выборе варианта на внедрение. Допустим, системный администратор научился использовать для фильтрации входящего почтового трафика программу Postfix [2] c проверкой на вирусы через ClamAV [3] и антиспам-фильтром SpamAssassin [4]. Он может настроить аналогичный сервер и в другой компании, при этом не нужно повторно прилагать усилия на разработку и специальное тестирование фильтрующего сервера. В итоге по мере накоплений подобных решений на базе бесплатных продуктов формируется своего рода «портфолио», которое пригодится как при устройстве в другую компанию, так и при

7

Острый угол выполнении разовых работ. Но если на нынешнем месте работы приходится иметь дело c коммерческим продуктом, то нет никакой гарантии, что при следующем трудоустройстве достанется тот же продукт. А заменить уже работающее решение на другое и тоже платное только потому, что новый специалист с ним лучше знаком, – на этот шаг пойдут немногие работодатели. В случае со свободными программами нет особого риска, если вдруг фирма-разработчик перестанет существовать, и некому будет поддерживать данное творение. Просто найдутся новые заинтересованные лица, будет сделан очередной «клон» (или, как говорят в таких случаях, «форк» проекта), и жизнь снова пойдет своим чередом. Прекрасная иллюстрация к этому – выход офисного пакета LibreOffice, после того как компания Oracle в свое время не сумела наладить управление проектом OpenOffice.org [5]. Еще один плюс открытых проектов – наличие большого числа добровольцев, которые устанавливают свободное ПО, тестируют, пишут документацию, с кем можно поделиться новостями или узнать интересные нюансы. В закрытых разработках, особенно когда дело касается не слишком известных программ, такая роскошь, как «сообщество пользователей», встречается гораздо реже.

А может, и нет никакой трагедии? Очевидно, что при таком ведении дел все ресурсы – и человеческие, и материальные – расходуются крайне нерационально. Получается, что одна и та же недоработка многократно устраняется в самых различных местах, и каждый раз ИТ-специалисты вынуждены изобретать велосипед. При этом обмен информацией происходит далеко не всегда. Здесь большую роль может играть политика компании в области коммерческой тайны, а также загруженность специалистов или просто нежелание делиться информацией с конкурентами. Возникает ситуация, когда изначально неплохой продукт «пробуксовывает» при внедрении. В итоге все это препятствует развитию ИТ-инфраструктуры каждой компании, что не позволяет нормально развиваться рынку легального программного обеспечения. Бизнесмены от ИТ могут бесконечно сетовать на разгул компьютерного пиратства и плохой инвестиционный климат в России, но пока каждый из них не начнет вести свои дела честно, желаемого развития не будет. К сожалению, пока что в головах управленцев российского бизнеса по большей части царит не здравый смысл, а банальная жадность, помноженная на неумение хоть немного думать о будущем. Но проблема не только в этом. Деньги, «сэкономленные» таким бесчестным образом, на самом деле оказываются извлеченными из оборота. Когда работа сделана, а деньги за нее получил кто-то другой, у этого «другого» нет стимула снова вкладывать эти деньги в развитие. Зачем платить, если можно получить бесплатно? Думаю, это очевидно: хорошие компьютерные программы помогают людям работать все лучше и лучше, а плохие тормозят работу или останавливают ее вовсе. В то время когда айтишники борются с программными сбоями, остальные пользователи не могут эффективно выполнять свою работу. Происходит падение производительности во всех отраслях, использующих компьютерную технику. Никакая 60-часовая рабочая неделя [6] не спасет общество от таких

8

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

Несколько мер по обеспечению нормальной работы Часть таких вопросов я уже пытался осветить в своей статье «Семь грехов системного администратора» [7]. Но, к сожалению, не все. Попытаемся сформулировать рекомендации более подробно.

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

2. Составьте свой подробный план развития ИТ‑инфраструктуры компании, где работаете Не ждите, когда это за вас сделает начальство. Изложите свои предложения по развитию необходимых сервисов и назовите продукты, которые именно вы считаете нужным использовать. И, конечно, не нужно планировать внедрение всего подряд. Лучше придерживаться принципа здравого минимализма: если бизнес-процессы компании на обозримом участке времени смогут обойтись без данного продукта, не понеся особых потерь, его в план развития пока включать не стоит.

3. Тщательно проверяйте приобретаемый продукт Вникайте во все мелочи – от комплекта поставки до послепродажного обслуживания. На какой платформе работает приобретаемое ПО? Какие продукты потребуется докупить для его полноценной работы? Кто еще работает с данным «творением»? Возможна ли поддержка на основе аутсорсинга? На все подобные вопросы вы должны получить от-

март 2012 системный администратор

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

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

мой программы, про которую начальство говорило: «Всего делов-то – раз и поставить», в итоге заняло до 80% рабочего времени. Вы смогли уделить решению всех остальных немаловажных вопросов в пять раз меньше внимания, чем должны были. А это уже весомый аргумент в пользу отказа от дальнейших попыток заставить работать «чудо-продукт» или, наоборот, причина, чтобы увеличить штат ИТ-отдела и с новыми силами довести начатое дело до конца.

8. Умейте отличать критичные задачи от второстепенных Например, сдача бухгалтерской отчетности или подготовка стенда к межрегиональной выставке – это задачи, от которых может зависеть судьба компании. А внедрение программы делового календаря может и обождать пару дней, пока не решатся критичные задачи. Разумеется, когда начальство требует все бросить и начать заниматься не слишком важным, на ваш взгляд, вопросом, необходимо подчиниться. Но в этом случае крайне желательно иметь подтверждение такой смены приоритетов. Подойдет, например, письмо по электронной почте или запись в системе заявок.

5. Используйте бесплатное свободное ПО

9. Следите за своим рабочим графиком

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

Старайтесь не допускать сверхурочных работ по некритичным вопросам и тем более не устраивайте авралы сами себе. Лично я еще ни разу не слышал, чтобы человека увольняли по причине переноса сроков внедрения очередной «финтифлюшки». Зато знал сисадминов, засыпавших буквально на ходу от постоянных переработок и рано или поздно делавших катастрофические ошибки.

6. Не пытайтесь решить самостоятельно все проблемы, связанные с внедрением и поддержкой продукта Лучше действовать с точностью до «наоборот» – по большинству вопросов обращайтесь к разработчику. Даже если предполагается только платная поддержка, все равно не давайте консультантам скучать до тех пор, пока не получите либо работающий результат, либо окончательный отказ. Даже если официальной поддержки нет, задавайте свои вопросы на форуме, пишите письма на опубликованные e-mail-адреса, в общем, не сидите сложа руки. И, конечно, создавайте баг-репорты (Bug Report) – отчеты о найденных ошибках – в соответствующую службу. Действуя таким образом, не стоит забывать об элементарных правилах вежливости. Такие слова, как «пожалуйста», «будьте добры», должны стать основой вашего лексикона. Но в то же время нужно четко различать свою область ответственности и ту, за которую отвечает разработчик. Например, указать, какие должны быть разрешения на каталоге с установленным приложением, – это задача создателей данного продукта. А вот как выставлять эти права на конкретный каталог – это область вашей компетенции. Не надо заваливать службу поддержки вопросами вроде: «Как раздать права на общий каталог?»

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

системный администратор март 2012

*** Вот мы и рассмотрели, как обстоят дела на современном рынке программного обеспечения. Соответственно все, кто завязан на работе в этом техническом направлении, зависят от его особенностей. Сам факт постоянной работы вхолостую, при том что деньги «уходят на сторону», не может не отражаться на благосостоянии ИT-специалистов. Искажающие факторы, которые уродуют теперешнее положение вещей, не исчезнут в одночасье. Но в наших силах сделать так, чтобы таких «перекосов» было все меньше и меньше. Разговор об этом будет продолжен в следующих публикациях, в том числе и моих коллег. Читайте «Системный администратор» и оставайтесь с нами! EOF 1. IT-затраты в России по итогам 2011 года увеличатся на 13,3% – IDC – http://www.finmarket.ru/z/nws/news.asp?id=2557852.

2. Postfix, программа бесплатного почтового сервера, точнее, агент пересылки почты – http://www.postfix.org.

3. Бесплатный антивирус ClamAV – http://www.clamav.net/lang/en.

4. SpamAssassin, средство фильтрации спама – http:// spamassassin.apache.org.

5. Статья о LibreOffice – http://ru.wikipedia.org/wiki/LibreOffice.

6. 60-часовую рабочую неделю взамен 40-часовой предложил ввести Михаил Прохоров – http://lenta.ru/news/2010/11/01/nedelya.

7. Иванов В. Семь грехов сисадмина. Можно ли их преодолеть? //«Системный администратор», №6, 2011 г. – С. 8-12 (http:// samag.ru/archive/article/1291).

9

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

аудит

Визитка Михаил Кондрин, окончил МФТИ, физик-экспериментатор. «Жертвами моих экспериментов оказалось множество приборов, системных блоков и операционных систем». Старший научный сотрудник и по совместительству системный администратор в подмосковном Институте физики высоких давлений РАН

Оптимизируем FreeRADIUS для защиты

беспроводной сети с помощью Heimdal-Kerberos. Часть 1 Как разрешить доступ сотрудников к беспроводной сети предприятия по учетной информации из единой базы данных Heimdal-Kerberos?

Зачем нужен WPA-Enterprise для беспроводных сетей? Поскольку беспроводные сети уже широко используются на практике, то постепенно возникает вопрос уже не столько защиты доступа к ним, сколько унификации этого доступа. Одно дело, если вы у себя дома устанавливаете беспроводную точку доступа и, чтобы помешать своим соседям безнаказанно таскать у вас трафик, вводите на ней известный только вашим близким пароль WPA-PSK (Wireless Protected Access with Pre-Shared Key). В то же время при развертывании беспроводной сети на предприятии ввиду принципиальной физической открытости Wi-Fi-сети, помимо борьбы с несанкционированным подключением к сети, системному администратору приходится решать проблему обеспечения сильного шифрования каналов беспроводной передачи данных. Как в таком случае подсказывает житейский здравый смысл – секрет, известный более чем двум сторонам, уже не является секретом, соответственно защита средствами общего ключа неприемлема. Стало быть, необходимый минимум защиты достигается при наличии индивидуального пароля/ключа у каждого из сотрудников. Для беспроводного доступа такой уровень безопасности можно обеспечить средствами WPA-Enterprise (название говорит само за себя). При этом протоколу WPA-Enterprise (или его расширение WPA2-Enterprise) требуется RADIUS-сервер, который хранит базу данных пользователей. К этому серверу и должны обращаться все точки беспроводного доступа для обслуживания запросов на предоставление доступа к сети. Название протокола RADIUS является акронимом и расшифровывается как Remote Authentication Dial-In User Service (Служба удаленной аутентификации dial-in пользователей) и уже намекает на его почтенный возраст, отсылая к тем далеким временам, когда телефонная линия (dial-in) являлась основным средством доступа в сеть. Но на самом деле в последнее время этот протокол, можно сказать, испытал второе рождение, что связано не только с развитием беспроводных сетей и стандарта WPA/WPA2-Enterprise, но и с распространением VPN и интернет-телефонии (и протокола SIP), где RADIUS также широко используется.

10

Однако, как правило, когда на предприятии возникает необходимость во внедрении беспроводного доступа и, следовательно, развертывании RADIUS-сервера, там уже имеется единая база пользователей с уже отлаженным циклом ротации и проверки сложности паролей. Поддержание в рабочем состоянии дублирующей службы всегда является дополнительной нагрузкой для сетевого администратора, и поэтому у него появляется мысль: а нельзя ли как-нибудь настроить RADIUS, чтобы он использовал уже имеющуюся базу учетных данных пользователей? В данном тексте как раз и будет рассмотрен один из способов решения этой проблемы в случае, если в качестве системы единого доступа используется база данных Kerberos, реализованная на сервере Heimdal. Вообще нет принципиальных ограничений, чтобы этот метод (после минимальных изменений) не работал бы и для других типов серверов Kerberos – MIT, Shishi или AD. Хотя сам по себе протокол RADIUS является не только (вопреки своему названию) службой проверки подлинности пользователей, но и службой авторизации и контроля действий пользователей (что называется AAA – Authentication, Authorization and Accounting), в данном тексте он будет рассматриваться только с точки зрения первого A – как прокладка между точкой беспроводного доступа и средством удаленной аутентификации пользователей Heimdal/ Kerberos.

Программное обеспечение Для наладки и тестирования потребуется работающая система с OC Linux. Разумеется, рассматриваемое решение не ограничивается только одной операционной системой и в конце статьи будут предложены рецепты переноса на гетерогенное окружение. Разумеется, также необходим работающий сервер Heimdal, но на его настройке я останавливаться не буду, отсылая читателя к руководствам (например, статьям [1, 2]). Единственное требование, чтобы в базу данных пользователей был вписан тестовый пользователь guest с паролем passwd (kadmin -l add guest -p passwd). Поскольку эти учетные данные будут широко использоваться в скриптах, приведенных в этой ста-

март 2012 системный администратор

аудит тье, то важно не забыть удалить их по окончании тестирования (kadmin -l del guest). С выбором сервера RADIUS есть несколько возможностей. Я остановился на FreeRADIUS [3], поскольку он открыт, доступен и достаточно подробно документирован. Также хорошим вариантом будет коммерческий сервер Radiator [4]. Поскольку разработчики Radiator трудятся в тесном контакте с разработчиками Heimdal (о чем свидетельствует, например, вот эта запись в блоге его основного разработчика Love Hornquist Еstrand [5]), то предложенные в этой статье решения там должны работать, что называется, «из коробки». В качестве самостоятельного сервера RADIUS может работать и демон hostapd [6]. Но поскольку основная его функциональность – это обслуживание со стороны user-space беспроводных устройств в режиме точек доступа (Master Mode), так что возможности его встроенного RADIUS-сервера мне показались несколько урезанными. Можно также упомянуть (для любителей экстрима и bleeding-edge) про протокол Diameter, который представляет собой расширение протокола RADIUS и реализуется, например, сервером freeDiameter [7]. В названии протокола подразумевается, что Diameter=Radius*2.0, но насколько он совместим с имеющимися на текущий момент в продаже беспроводными маршрутизаторами и стандартом WPA2-Enterprise, я судить не берусь. Установить FreeRADIUS можно на тот же сервер, где уже работает KDC от Heimdal. Лучше всего воспользоваться стандартными пакетными менеджерами дистрибутива, однако собрать FreeRADIUS из исходного кода совсем несложно. Следует только убедиться, что при этом будет собран модуль rlm_krb5 и что к нему подключены имеющиеся библиотеки от Heimdal. В остальном проблем не должно возникнуть, поскольку собирается он стандартной последовательностью: $./configure --prefix=/usr --sysconfdir=/etc ↵

--enable-heimdal-krb5 $ make # make install

Если вы захотите установить FreeRADIUS во временный каталог, чтобы впоследствии собрать из него пакет под свой дистрибутив, вам следует помнить, что в данном случае команда make install игнорирует стандартную для таких целей опцию DESTDIR=/tmp/foo/, а вместо этого использует переменную окружения R.

Стандарт IEEE802.11 и криптографические алгоритмы Ввиду принципиальной физической незащищенности беспроводных сетей следует уделять особое внимание проблемам шифрования беспроводного канала. Более того, это шифрование должно быть произведено до того, как по этому каналу будут переданы идентификационные данные пользователя, поскольку их могут перехватить злоумышленники и подвергнуть криптографическому взлому уже в оффлайне. Эти проблемы не вполне тривиальны, и стандарт на беспроводные системы (IEEE802.11) в процессе своего развития достаточно серьезно на этом поскользнулся, поскольку первоначальный алгоритм шифрования канала WEP (Wired Equivalent Privacy – приватность, эквивалентная проводной сети), предложенный в 1999 году, удалось взломать в те-

системный администратор март 2012

Администрирование чение того же года. Последующие модификации стандарта (IEEE802.11i соответствует WPA2) эту проблему в значительной мере разрешили путем замены алгоритма WEP на TKIP (Temporal Key Integrity Protocol) или еще более стойким шифром CCMP (Counter with CBC-MAC mode Protocol, иногда в настройках беспроводного оборудования он обозначается как AES – Advanced Encription Standard, т.к. он используется этим стандартом). Поскольку вычислительные ресурсы беспроводного оборудования ограничены, то из соображений быстродействия оба алгоритма предусматривают симметричное шифрование с периодически обновляемыми общими ключами, т.е. при создании беспроводного соединения обе стороны должны быть каким-то образом обеспечены ключом. Несложно сообразить, что ключ может быть тем или иным способом сгенерирован при аутентификации пользователя, на основе его пароля, логина и т.д. При этом авторы стандарта не стали настаивать на какомто определенном алгоритме, а предложили достаточно абстрактный метод EAP (Extensible Authentication Protocol – расширяемый протокол аутентификации) [8], переложив задачу по его детализации на конечных разработчиков программного обеспечения и беспроводного оборудования. В настоящее время насчитывается уже несколько десятков EAP-протоколов. Не все они одинаково распространены, поэтому в этой статье будет рассмотрена только пара наиболее широко используемых.

Настраиваем FreeRADIUS для работы в режиме EAP-TTLS/PAP Этот метод EAP задокументирован в RFC5281 [9]. Его идея достаточно проста: средствами TTLS создается зашифрованный канал, по которому в открытом виде передается пароль пользователя (PAP – Password Authentication Protocol, протокол проверки подлинности пароля) или же используются более продвинутые способы аутентификации. Этот EAP-метод удобен в развертывании и обслуживании по многим причинам. Он достаточно криптографически стоек и безопасен, поскольку пароль в открытом виде не передается по сети. При этом в отличие от сходного по названию и реализации метода EAP-TLS [10] вам не нужно иметь на клиентских машинах ключи, подписанные корневым сертификатом, так что нет необходимости их менять на всех машинах при его устаревании. Немаловажно и то, что алгоритм EAP-TTLS/PAP было бы достаточно легко реализовать на базе FreeRADIUS в связке с Heimdal, если б не одно но – необходимость правки конфигурационных файлов FreeRADIUS в каталоге /etc/raddb. Предполагается, что конфигурация, созданная при установке FreeRADIUS, готова к использованию при условии, что база данных пользователей и их пароли содержатся в файле /etc/raddb/users. Замена же на любую другую базу данных, типа SQL, LDAP или, как в нашем случае, Kerberos, уже требует модификации конфигурационных файлов. Собственно, проблема связана даже не столько с объемом и количеством этих файлов, сколько с тем фактом, что все они представляют собой скрипты, написанные пусть и на ограниченном по своим возможностям («неполным по Тьюрингу», если выражаться научными терминами) языке программирования unlang, придуманном разработчиками FreeRADIUS специально для этой цели. Причем фай-

11

Администрирование лы из /etc/raddb – это еще только малая видимая часть айсберга, поскольку огромный блок кода, состоящий из так называемых статических словарей/dictionary, вынесен в системный каталог /usr/share/freeradius. Однако при настройке FreeRADIUS выручает то, что все они снабжены подробными комментариями, и сам язык смотрится достаточно наглядно, так что особо вникать в его тонкости не требуется. Я же просто приведу свои «минимально-функциональные» конфигурационные файлы, при написании которых мне помогла информация с сайтов [11, 12]. Минимизация конфигурационных файлов не столько даже оптимизирует работу RADIUS-сервера, сколько помогает администратору разобраться в отладочной информации при его настройке. Отправной точкой является файл /etc/raddb/radiusd. conf, который первым считывается при старте FreeRADIUS, а уже затем подверстываются остальные куски, указанные в директивах $INCLUDE. prefix = /usr exec_prefix = ${prefix} sysconfdir = /etc localstatedir = ${prefix}/var sbindir = ${exec_prefix}/sbin logdir = ${localstatedir}/log/radius raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct name = radiusd confdir = ${raddbdir} run_dir = ${localstatedir}/run/radiusd db_dir = ${raddbdir} libdir = ${exec_prefix}/lib pidfile = ${run_dir}/${name}.pid max_request_time = 30 cleanup_delay = 5 max_requests = 1024 type = auth ipaddr = * port = 0

hostname_lookups = no allow_core_dumps = no regular_expressions extended_expressions log {

}

= yes = yes

destination = files file = ${logdir}/radius.log stripped_names = no auth = yes

checkrad = ${sbindir}/checkrad security { max_attributes = 200 reject_delay = 1 status_server = yes } proxy_requests

= no

$INCLUDE clients.conf $INCLUDE policy.conf thread pool { start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 }

12

modules { $INCLUDE ${confdir}/modules/ $INCLUDE eap.conf } $INCLUDE sites-enabled/

По сравнению с исходным файлом основная правка, проделанная мной, заключается в удалении комментариев, удалении обработки proxy-запросов и закрытии порта, ответственного за регистрацию действий пользователей (accounting). Проксирование отключено, поскольку наш RADIUS-сервер будет единственным ответственным за авторизацию пользователей, находящихся в радиусе действия беспроводной сети предприятия, а особого смысла держать открытым UDP-порт 1813 нет, поскольку этот сервис (radacct) все равно большинством беспроводных роутеров не используется. В моем случае RADIUS-сервер настроен только на обработку запросов на аутентификацию и авторизацию по стандартному UDP-порту 1812 (блок listen {...}). Всего в этом файле содержится пять директив $INCLUDE. Первая подгружает файл clients.conf, где перечислены адреса, с которых разрешено подключение к нашему серверу. Можно ограничиться двумя записями – отдельный адрес для локального хоста и для всей остальной локальной сети. В каждом случае нужно указать секретный ключ, который затем будет широко использоваться, так что можно особо не стараться, выдумывая сложные комбинации символов. client localhost { ipaddr = 127.0.0.1 secret = testinpass } client 192.168.0.0/16 { secret = testinpass }

listen {

}

аудит

Следующий подгружаемый файл policy.conf содержит своего рода подпрограммы на языке unlang, которые можно будет вызывать из других конфигурационных файлов. Поскольку эти подпрограммы далее нигде не используются, то я ограничился одним пустым блоком: policy { }

Следующие две директивы $INCLUDE содержатся внутри блока modules {...} и предназначены для считывания конфигурационных файлов из каталога /etc/raddb/modules с настройками подгружаемых модулей FreeRADIUS. Сами по себе модули – это обычные разделяемые библиотеки с приставкой rlm_ (расшифровывается как Radius loadable module), и должны поэтому располагаться в стандартном для библиотек месте, известном или из переменной окружения LD_LIBRARY_PATH или из файла /etc/ld.so.conf (например, /usr/lib). Настройки модуля rlm_eap, ответственного за обработку EAP-процедур, вынесены в файл, подгружаемый отдельно $INCLUDE eap.conf. Это связано с тем, что настройки EAP зависят от нескольких подмодулей, например, rlm_eap_ttls, rlm_eap_peap и т.д., со своими специфичными установками. Ниже приведена упрощенная версия настроек EAP (позаимствованная мною с сайта [11]). C его помощью под-

март 2012 системный администратор

аудит ключаются только те алгоритмы, которые нам в дальнейшем действительно понадобятся – TTLS и PEAP (о нем речь впереди). eap { default_eap_type = peap timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 2048 tls { certdir = ${confdir}/certs cadir = ${confdir}/certs private_key_password = whatever private_key_file = ${certdir}/server.pem certificate_file = ${certdir}/server.pem CA_file = ${cadir}/ca.pem dh_file = ${certdir}/dh random_file = ${certdir}/random fragment_size = 1024 include_length = yes check_crl = no cipher_list = "DEFAULT" make_cert_command = "${certdir}/bootstrap" } ttls { default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "inner-tunnel" } peap { default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "inner-tunnel" } mschapv2 { } }

К присутствию в этом блоке двух других вложенных секций tls{...} и mschapv2{...}, да и вообще к содержимому всего этого файла, следует относиться как к своего рода черной магии. Ясно по крайней мере, что блок tls{...} (хотя сам метод EAP-TLS нам не понадобится) содержит важную информацию о расположении серверных сертификатов, без которых, разумеется, ни о каких TTLS-каналах речи быть не может. Эти сертификаты (вместе с корневым CA и одним клиентским) будут созданы автоматически скриптом bootstrap при первом старте сервера FreeRADIUS в отладочном режиме (т.е. с флагом -X). Если же понадобится подписать сертификаты своим собственным CA, то вам (как рекомендуют сами разработчики) необходимо удалить каталог /etc/raddb/certs и вместо него создать новый, куда поместить свой корневой сертификат и снова запустить FreeRADIUS с флагом -X. Впрочем, для наших целей будет достаточно автоматически сгенерированных сертификатов. В действительности подключение библиотечных модулей происходит в «ленивом» режиме, т.е. модули подгружаются по мере необходимости. Так что, насколько плотно заселен каталог modules, на вычислительных ресурсах никак не скажется. Тем не менее с целью проиллюстрировать, какие именно модули и конфигурационные файлы действительно используются, я привожу немного подчищенный листинг этого каталога на рис. 1. И наконец с последним $INCLUDE начинается самое интересное – подгружается/etc/raddb/sites-enabled, где содержатся конфигурационные файлы «виртуальных серверов»,

системный администратор март 2012

Администрирование которые как раз и отвечают за логику обработки клиентских запросов. Это относительно свежая функциональность, появившаяся только в версии 2.0. С ее помощью внутри одного сервера FreeRADIUS можно организовать несколько виртуальных серверов (в традиционном понимании), т.е. с независимой друг от друга конфигурацией, прослушивающих каждый свой UDP-порт и т.д. Но на практике «виртуальные серверы» применяются, чтобы по-разному обрабатывать различные типы запросов с клиентов. Например, можно заметить, что в файле eap.conf пакеты, полученные по TTLS (или PEAP) туннелю, пересылаются виртуальному серверу inner-tunnel. Каждому виртуальному серверу должен соответствовать одноименный файл в /etc/raddb/sites-enabled. В действительности там содержатся только символьные ссылки на файлы в каталоге /etc/raddb/sites-available – предполагается, что так несколько проще переконфигурировать FreeRADIUS, просто переадресуя ссылки. В обязательном порядке должен присутствовать по крайней мере один файл default, который служит обработчиком по умолчанию. Для простоты оба этих сервера (default и inner-tunnel) у меня сконфигурированы практически идентично. При этом файл default я значительно сократил, удалив все блоки, отвечающие за проксирование запросов и обработку accounting-информации (поскольку наш сервер все равно эти пакеты игнорирует), оставив только то, что имеет отношение к авторизации и аутентификации пользователей, так что в итоге этот файл выглядит таким образом: authorize { preprocess mschap eap files } authenticate { Auth-Type PAP { krb5 } Auth-Type MS-CHAP { mschap }

Рисунок 1. Каталог с конфигурационными файлами FreeRADIUS. Секретная информация содержится только в подкаталоге certs, его просмотр запрещен простому пользователю

13

Администрирование eap } post-auth { noop }

Затем этот текcт целиком вставляется в файл inner-tunnel с помощью все той же директивы $INCLUDE: server inner-tunnel { $INCLUDE sites-enabled/default }

Аутентификация пользователей в FreeRADIUS Осталось совсем немного – понять, какое отношение имеют все эти настройки к аутентификации и авторизации пользователей FreeRADIUS?Последовательность обработки протоколом RADIUS-запросов на вход в сеть не совсем очевидна (отличается от традиционной логики «сначала аутентифицируем, а потом раздаем права»). Вначале запрос, полученный каким-то из виртуальных серверов, проверятся последовательно всеми модулями, перечисленными в блоке authorize, пока какой-то из этих модулей не заявит, что он должен обслуживать этого пользователя, и не выставит ему необходимые атрибуты, включая атрибут Auth-Type. Потом уже, в зависимости от выставленного значения, для аутентификации этого пользователя выбирается какой-то один подходящий модуль из перечисленных в блоке authenticate{...}, а весь процесс завершается блоком post_auth, оставленным в нашей конфигурации пустым. Т.е. процесс перебора начинается с модуля rlm_preprocess, который как раз подгружает статические словари, считывая конфигурационные файлы /etc/ raddb/hints и /etc/raddb/huntgroups, и с их помощью преобразует клиентский запрос, полученный с сети, в пригодный для дальнейшей обработки вид, а последним рубежом является модуль rlm_files. Как раз этот модуль проверяет логин пользователя по текстовым файлам данных /etc/raddb/users, /etc/ raddb/acct_users и /etc/raddb/preproxy_users. Два последних файла нас не интересуют, так что их можно оставить пустыми, а вот файл /etc/raddb/users как раз потребует доработки. В древние времена этот файл применялся исключительно для хранения паролей пользователей, но для нас важно, чтобы он состоял из единственной записи: DEFAULT Auth-Type = PAP

Эта древняя магическая руна... ой, простите, эта строка означает, что всем пользователям, для которых атрибут Auth-Type не был установлен ранее, назначается механизм аутентификации PAP, т.е. простая проверка текстового пароля. Если же посмотреть в секцию authenticate, то можно догадаться, что проверка пароля будет проделана модулем rlm_krb5. Фактически все это эквивалентно выполнению процедуры kinit для выбранного пользователя с полученным от него текстовым паролем. Теперь можно будет попытаться взлететь. Но для работы с сервером Kerberos от Нeimdal нужно будет еще создать специального сервисного принципала для FreeRADIUS и экспортировать его ключ в keytab-файл. kadmin -l add -r radius/server.example.ru

14

аудит ktutil get radius/server.example.ru

Пара полезных советов: Совет превый. Имя сервисного принципала и используемый keytab-файл следовало бы внести в конфигурационный файл /etc/raddb/modules/krb5, но в принципе это не обязательно, его можно сделать пустым: krb5 { }

Все равно в качестве последнего резерва (если все введенные там параметры не помогли) модуль rlm_krb5 будет использовать системный keytab-файл /etc/krb5.keytab и имя сервисного принципала, составленного из слова «radius» и имени сервера. Совет второй. Когда сервер RADIUS будет приведен в рабочее состояние, лучше все же создать под него выделенного системного пользователя и группу (тем более что порт 1812 не является привилегированным) и добавить куданибудь в начало файла /etc/raddb/radiusd.conf записи вида: user = radius group = radius

Следует позаботиться при этом, чтобы все задействованные в настройках FreeRADIUS директории и файлы были доступны на чтение (включая файл /etc/krb5.keytab! ) и запись этому пользователю или группе. На этом правку конфигурационных файлов можно завершить (ну, почти), а все остальные файлы в директории /etc/raddb оставим без изменений. Проверку же работоспособности сервера мы отложим до следующей части этой статьи. EOF 1. Кондрин М. Изучаем принципы работы Heimdal Kerberos. //«Системный администратор», №6, 2005 г. – С. 56-59 (http:// samag.ru/archive/article/496).

2. Кондрин М. Развертываем Heimdal Kerberos. //«Системный администратор», №7, 2005 г. – С. 20-25 (http://samag.ru/archive/ article/508).

3. http://freeradius.org.

4. http://www.open.com.au/radiator.

5. http://blog.h5l.org/2007/04/kdigest-and-heimdal-08-releaseprocess.html.

6. http://hostap.epitest.fi/hostapd.

7. http://www.freediameter.net/trac.

8. B. Aboba, L. Blunk, J. Vallbrecht, J. Carlson, and H. Levkowetz.

RFC3748: Extensible Authentication Protocol (EAP). Technical report, Network Working Group, June 2004.

9. P. Funk and S. Blake-Wilson. RFC5281: Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0). Technical report, Network Working Group, August 2008.

10. D. Simon, B. Aboba, and R. Hurst. RFC51216: The EAP-TLS Authentication Protocol. Technical report, Network Working Group, March 2008.

11. https://confluence.terena.org/display/H2eduroam/How+to+ deploy+eduroam+on-site+or+on+campus.

12. Минимальный RADIUS-сервер на FreeRADIUS – http://ru.gentoowiki.com/wiki.

март 2012 системный администратор

аудит

Администрирование Визитка Иван Коробко, сертифицированный специалист MCP, автор более 50 статей и двух книг. Занимается созданием различных приложений для Active Directory

Управление правами доступа к LUN Используя LUN, можно создать распределенную файловую систему с большим дисковым пространством. Как им управлять в автоматическом режиме?

Подключенный из хранилища LUN (Logical Unit Number) рассматривается сервером как обычный том, управление правами доступа к которому традиционно осуществляется с помощью оснастки Server Manager. Если количество прав исчисляется в пределах десяти, то управление вручную – самое правильное решение, а если их, например, тридцать или сорок, то тогда встает вопрос об автоматизации данного процесса. Существует два способа подключения тома. Его можно подсоединить как папку или как диск (см. рис. 1). Поскольку

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

Рисунок 1. Способ подключения тома

системный администратор март 2012

15

Администрирование Управление правами тома Управление правами тома вручную осуществляется из вкладки Security, расположенной в диалоговом окне Properties. Его вызов осуществляется непосредственно из контекстного меню тома в оснастке Server Manager. Программное управление с помощью командлетов PowerShell или DOT.NET осуществляется не с томом, а непосредственно с диском. При создании папки на нее назначаются требуемые права доступа. С помощью Server Manager осуществляется подключение тома к данной папке. Правила безопасности на ее контент, которым является содержимое тома, никак не связаны с назначенными на каталог, поскольку содержимое тома и папка – разные сущности. Системные администраторы часто забывают об этом и поначалу воспринимают расхождение прав как ошибку работы NTFS. Чтобы привести в соответствие ACL-списки папки и тома, разработаем соответствующий сценарий. Поскольку программное управление осуществляется непосредственно с использованием представления тома в виде диска, нужно создать соответствующую точку входа (см. рис.

1). Для этого необходимо по известному пути определить идентификатор тома и подключить его ко второй точке входа – к диску. В листинге 1 приведен пример определения идентификатора (deviceID) диска по известной точке монтирования. Листинг 1. Определение идентификатора тома по папке подключения $path = "C:\LUNs\Фотогалерея " $letter = "k:\" $obj=Get-WmiObject -class Win32_Volume -computername ↵

localhost $obj | ? {$_.caption -like $path+"*"}

Управление подключением томов Управление подключением томов сводится к двум операциям – подключению и отключению тома. Обе операции вы-

аудит полняются с помощью API-функций SetVolumeMountPointA и DeleteVolumeMountPointA. Рассмотрим их подробнее.

Подключение тома Функция SetVolumeMountPointA, обеспечивающая подключение тома к диску или существующей папке, имеет два параметра. >> Первый из них – идентификатор тома, который является значением атрибута deviceID и хранится в формате \\?\Volume{GUID}. >> Второй параметр – в зависимости от точки монтирования, путь к локальной папке или имя диска в формате «Буква:\». В листинге 2 приведен пример подключения существующего тома в качестве диска. Поскольку PowerShell не поддерживает API-функций, то для реализации данной задачи необходимо компилировать программный код [1] на лету, передавая функции необходимые параметры. Листинг 2. Подключение тома как диска $provider = New-Object Microsoft.CSharp.CSharpCodeProvider $params = New-Object System.CodeDom.Compiler. ↵

CompilerParameters $params.GenerateInMemory = $True $refs = "System.dll $params.ReferencedAssemblies.AddRange($refs) $txtCode = @" using System.Runtime.InteropServices; class mBox { [DllImport("kernel32.dll", EntryPoint = ↵

"SetVolumeMountPointA")] public static extern int SetVolumeMountPointA ↵

(string DiskLetter,string VolumeGUID); public void Mount(string letter,string volume) { SetVolumeMountPointA(letter,volume); } }

Рисунок 2. Свойства тома «Фотогалерея»

16

март 2012 системный администратор

аудит

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

Cодержимое тома доступно при входе в заданную папку: это выглядит как обычный каталог

"@ $results = $provider.CompileAssemblyFromSource($params, ↵

$txtCode) $results $mAssembly = $results.CompiledAssembly $i = $mAssembly.CreateInstance("mBox") $r = $i.Mount($letter, $_.deviceID)

Изменение прав доступа После того как том подключен как диск, приступим к копированию прав с папки (C:\LUNs\Фотогалерея) на диск(K:\). Для этого используют функции из библиотек .NET Framework или командлеты PowerShell. Несмотря на то что командлеты, управляющие безопасностью, обладают не всем необходимым функционалом, все же с их помощью Get-Acl и Set-Acl можно решить поставленную задачу (см. листинг 3). При создании сценария помните, что на выполнение каких-либо действий с файловой системой требуется время. Последовательный вызов команд при низкой скорости работы сервера может привести к наложению выполняемых функций друг на друга. Результат может быть непредсказуемым: только часть прав будет назначена. Поэтому между операциями необходимо вставлять функции, определяющие состояние выполнения работы предыдущих или установка простой задержки выполнения сценария (не рекомендуется): Start-Sleep -Seconds $time. После того как права скопированы, необходимо отключить созданный диск.

нить и вызывать функции по мере необходимости. При написании собственных листинг в обратите внимание, что C#, на котором реализован вызов IP-функций, чувствителен к регистру. Листинг 4. Отключение тома как диска $provider = New-Object Microsoft.CSharp.CSharpCodeProvider $params = New-Object System.CodeDom.↵

Compiler.CompilerParameters $params.GenerateInMemory = $True $refs = "System.dll" $params.ReferencedAssemblies.↵

AddRange($refs) $txtCode = @" using System.Runtime.InteropServices; class mBox { [DllImport("kernel32.dll", EntryPoint = ↵

"DeleteVolumeMountPointA")] public static extern int DeleteVolumeMountPointA ↵

(string DiskLetter); public void UnMount(string letter) { DeleteVolumeMountPointA(letter); } } "@ $results = $provider.CompileAssemblyFromSource($params, ↵

$txtCode) $results $mAssembly = $results.CompiledAssembly $i = $mAssembly.CreateInstance("mBox") $r = $i. UnMount ($letter)

Листинг 3. Копирование ACL $path = "C:\LUNs\Фотогалерея " $letter = "k:\" …

Set-Acl -Path $letter -AclObject (Get-Acl $path)

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

Отключение тома Функция DeleteVolumeMountPointA отключения тома содержит лишь один параметр – локальный путь к ресурсу (см. листинг 4). Для удобства листинги 2 и 4 можно объеди-

системный администратор март 2012

1. На языке PowerShell. Сценарий регистрации пользователей в сети. Часть 3. //«Системный администратор», №3, 2011 г. – С. 60-65.

17

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

инструменты

Визитка Сергей Яремчук, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Управление Linux-системами с помощью m23

По мере расширения парка Linux-машин администратору потребуется удобный инструмент для управления и распространения ПО. Эту задачу вполне может решить сервер m23

Если в сети работает более десятка компьютеров под управлением Linux или сисадмину необходимо установить за день десяток ОС (например, в крупном магазине или интеграторе), управлять всеми процессами вручную становится неудобно. Со временем возникает потребность в максимальной автоматизации и обеспечении наглядности. ОС Linux для этого предоставляет все необходимое – SSH, BASH, cron и т.д., а вместе с некоторым опытом появляются и самописные скрипты. Очень выручают решения автоматизации вроде Puppet [1] и Cfengine [2]. Но многие находят этот путь сложным и, главное, не наглядным. Система распространения программного обеспечения Рисунок 1. Настройка параметров клиентской машины

18

(software distribution system) m23 [3] упрощает многие аспекты администрирования Linux – от развертывания до ежедневного сопровождения.

Возможности проекта m23 Фактически m23 является надстройкой над несколькими открытыми проектами –phpMyAdmin, OpenLDAP, BackupPC, Etherboot, DHCP, ATFTP, Squid, BusyBox, SSH, GnuGPG, par2, веб-сервером Apache (в качестве интерфейса и сервера доступа к файлам), PHP, MySQL (хранение конфигураций), несколькими утилитами для записи CD в Linux и еще рядом других. В качестве опциональных зависимостей при установке из пакетов указаны Postfix и Dovecot. Используется клиент-серверная архитектура. На стороне клиента в настоящее время поддерживается развертывание и управление Debian, Ubuntu, Fedora, OpenSUSE и клонами этих дистрибутивов. Под клиентом здесь понимается любая версия ОС, которой мы будем управлять: это может быть как десктоп, так и серверный вариант. Принцип работы прост: клиентская система, загружаясь по сети с помощью PXE или любым другим способом (например, CD), получает IP‑адрес от встроенного DHCP-сервера, отправляет данные об установленном оборудовании на m23 и на основании полученных настроек устанавливает операционную систему. Администратору, по сути, необходимо указать МАС-адрес сетевой карты, все остальное происходит автоматически. Все установки с помощью понятного веб-интерфейса. Он не локализован, но все термины общеупотребительны, и к тому же по всем вопросам доступны подсказки. Например, настройка параметров для развертывания клиентских ОС производится всего за три шага: администратор лишь заполняет предложенные в окне параметры, следуя за указаниями мастера. Основные функции, обеспечиваемые сервером m23: >> удаленное администрирование любого числа клиентских машин с помощью веб-интерфейса (в т.ч. TightVNC Java Viewer) или SSH (если браузер поддерживает протокол ssh://);

март 2012 системный администратор

инструменты >> подключение (ассимиляция) к m23 уже работающих клиентских машин Debian или Ubuntu; >> массовое развертывание клиентских систем с возможностью индивидуальной настройки, в том числе создание и форматирование дисковых разделов под выбранный тип ФС, установка и удаление программ; >> поддержка всех популярных файловых систем Linux и Software RAID (0, 1, 4, 5, 6 и 10); >> управление группами – администратор может управлять не отдельной системой, а объединять однотипные системы в группу, членам которой через виртуального model client распространяются произведенные установки (обновление ПО, восстановление, задания и т.п.); >> возможность повторного использования большинства установок; >> управление учетными записями через LDAP; >> хранение пользовательских данных (/home) в NFS; >> создание сценариев и пакетов для установки на клиентах; >> кэширование устанавливаемых пакетов (с помощью Squid), проверка зависимостей перед установкой, возможность создавать собственные, в том числе локальные, репозитарии для инсталляции без доступа к Интернету; >> резервное копирование и восстановление данных клиента и сервера, восстановление клиентской ОС с помощью заданных во время установки настроек; >> сжатие и шифрование (с помощью GnuGPG) резервных копий; >> рабочий стол KDE4, Gnome, XFce, TDE (ответвление KDE3) или без X11 (для сервера); >> интегрирован пакет виртуализации VirtualBox OSE, позволяющий создавать в один клик виртуальные машины на сервере и клиентах m23. Интерфейс, как и основные возможности ПО, можно изменить, воспользовавшись инструментом разработки MDK (m23 Development Kit), доступным свободно. Специальный инструмент halfSister [4] предлагает установку предварительно настроенных дистрибутивов из сжатого образа. В настоящее время актуальной является версия m23 12.1 «rock» (номер версии показывает год и месяц выхода). В ней добавлена поддержка OpenSUSE и Debian Lenny, проект мигрировал на новые зеркала, появились новый генератор xorg.conf, оптимизированный для гостевых систем VirtualBox, новые плагины для Nagios, поддержка основных файловых систем Linux (ранее только ext3), расширенный режим настроек пакетного менеджера, VNC-консоль для доступа к VirtualBox OSE. Кроме этого, в настройках появился remote administration service, представляющий собой платный сервис, операторы которого помогают в управлении m23. Документация у проекта есть, но, как водится в мире Open Source, некоторые вопросы описаны весьма поверхностно, хотя любой администратор, имеющий хотя бы минимальный уровень и представляющий, что в итоге нужно делать, вполне сможет самостоятельно разобраться во всех настройках. Также имеются видеоруководства, помогающие увидеть весь процесс визуально. Доступна поддержка со стороны сообщества проекта (ответы на большинство

системный администратор март 2012

Администрирование вопросов можно найти на форуме); для немецких пользователей разработчики предоставляют коммерческую поддержку на отдельном ресурсе [5].

Установка сервера m23 Для установки проект предлагает CD (на базе Debian), репозитарий пакетов для Debian и образ для виртуальной машины VirtualBox. Причем разработчики рекомендуют в первую очередь использовать именно CD как самый простой вариант. Установку с его помощью можно производить как на физический сервер, так и на виртуальную машину (официально VMware, VirtualBox и KVM). Рекомендуемые системные требования для сервера не выглядят большими: CPU 1 Ггц, RAM 256 Мб и HDD от 5 Гб, одна-две сетевые карты (минимальные на порядок ниже). В принципе в качестве сервера m23 вполне можно использовать ПК или ноутбук сисадмина. Второй вариант оценят аутсорсеры, которые занимаются развертыванием и настройкой рабочих станций и серверов на базе Linux. Хотя в этом случае предлагаемый разработчиками CD не очень удобен, так как при развертывании сервера m23 хочется сохранить текущую систему со всеми настройками. Здесь два выхода. Если выбран Debian, то проблем нет, просто подключаем репозитарий. Если же это Ubuntu или Linux Mint, то, учитывая, что репозитарии в настоящее время совместимы, m23 также вполне можно установить на компьютер. Вероятность беспроблемной установки возрастает с «чистотой» систе-

19

Администрирование мы. Если «портить» основную систему на рабочем ПК не хочется, лучше использовать для сервера m23 виртуальную машину, которую и следует включать впоследствии по мере необходимости. Сетевая карта, которая будет использована для подключения клиентов, должна быть прописана в файле /etc/ network/interfaces первой. Также она должна иметь статический IP-адрес, иначе установка завершится с ошибкой. Для определения версии дистрибутива скрипт-пакета m23 проверяет файл /etc/issue на наличие слова Debian. Если таковое не обнаруживается, то установка прерывается с предупреждением: The m23 packages are ment for installation on Debian ONLY!

Если в качестве дистрибутива выбран Ubuntu или Linux Mint, перед установкой обязательно правим файл /etc/issue. Далее процесс одинаков и для Debian, и для Ubuntu. Экспортируем GPG-ключи: $ wget -T1 -t1 -q http://m23.sourceforge.net/ ↵

m23-Sign-Key.asc -O – | apt-key add -

Добавляем новые репозитарии и обновляем список пакетов: $ nano /etc/apt/source.list deb http://switch.dl.sourceforge.net/project/m23/m23inst ./

инструменты $ sudo apt-get update

Команда sudo apt-cache search m23 покажет несколько пакетов. Чтобы установить все компоненты, достаточно ввести: $ sudo apt-get install m23

В большинстве случаев это оптимальный выбор, хотя при необходимости можно установить систему лишь с необходимыми модулями. Всего в процессе установки будет загружено более 200 Мб архивов. Далее последуют запросы на настройку отдельных пакетов/сервисов: TFTP, пароль администратора LDAP, вебсервер для управления BackupPC (по умолчанию Apache, по окончании будут выведены данные для входа), создание базы MySQL для m23, настройка DHCP, создание ключа SSH, настройка Squid, создание сертификата m23-сервера (будет валидным в течение 10 лет) и настройка модулей Apache. Установка с помощью CD, по сути, является стандартной для Debian; в процессе нужно будет ввести лишь сетевые настройки и пароль root. После перезагрузки открываем веб-браузер, подключаемся к серверу, при первом входе используем логин god и пароль m23 (в окне выдается подсказка, но она быстро затеняется).

Рисунок 2. Окно создания и форматирования разделов

20

март 2012 системный администратор

инструменты

Интерфейс управления m23 Окно управления m23 можно назвать традиционным. В самом верху находится строка статуса, в левой части – панель меню, и по центру производятся собственно настройки. Пункты меню сгруппированы по назначению: >> Server – настройки сервера, управление файлами образов, LDAP, запуск сервисов, резервирование, контроль над учетными записями администраторов и т.д. В отдельном подменю находится активация «удаленного помощника» – Remote administration service. >> Clients – управление клиентами. >> Virtual clients – создание виртуальных машин/клиентов на базе VirtualBox OSE. >> Groups – управление группами клиентов. >> Packages – создание, удаление, редактирование, установка пакетов. >> Mass tools – создание мастер-клиента, настройки которого будут использованы для остальных в качестве эталонных. >> Tools – создание загрузочных дисков для клиентов, не поддерживающих PXE. >> Plugins – обзор и установка плагинов. >> Support – ссылка на различные ресурсы поддержки. Назначение многих параметров интуитивно понятно, хотя с порядком настройки необходимо немного разобраться. После первой регистрации обязательно создаем новую учетную запись администратора в Server settings → Manage

Администрирование administrators, после чего появляется возможность удалить пользователя god. Перед тем как приступить непосредственно к развертыванию клиентских машин, рекомендуется произвести некоторые настройки. Так, после установки сервера m23 мы имеем готовый OpenLDAP-сервер и профиль, который затем можно будет выбрать в настройках. Если в дальнейшем планируется использовать другой LDAP-сервер, лучше подключить его. Для этого переходим в Server → Server settings и нажимаем ссылку LDAP, а затем в окне Manage LDAP servers указываем параметры подключения к нужному LDAP-серверу, прописав его название, IP-адрес и пароль администратора. После этого профиль можно сохранить. В m23 дистрибутив устанавливается в основном посредством сетевой загрузки, администратор может самостоятельно указать любые источники/репозитарии пакетов – HTTP, FTP, CDROM и так далее. Нужный шаблон настраивается в Packages → Package sources, а сам процесс очень напоминает редактирование /etc/apt/source.list. Для каждого набора можно указать архитектуру и доступные рабочие окружения. Чтобы проверить правильность параметров, нажимаем кнопку Test it. По окончании настройки не забываем сохранить шаблон, указав его имя и нажав кнопку Save. В поставке m23 уже настроено несколько готовых шаблонов, которые в дальнейшем можно использовать безо

Рисунок 3. Настройки Control Center

системный администратор март 2012

21

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

Развертывание клиентских машин Теперь можно приступать к развертыванию клиентских машин. Если в сети уже используется DHCP-сервер, он может перехватывать обращения и мешать установке. Удобнее его на время деактивировать. Если по некоторым причинам отключить сторонний DHCP нельзя, можно запретить раздавать IP определенным МАС-адресам или установить для них большую задержку. Переходим в Clients → Add – появляется первое окно мастера, которое так и называется: Add client (см. рис. 1). Здесь в первую очередь заполняем обязательные параметры, обозначенные звездочкой «*»; остальные – по желанию. Нам потребуется выбрать из списка язык, указать логин и имя клиента, выбрать тип загрузки boottype, системный загрузчик, архитектуру (доступные варианты зависят от репозитория), ввести сетевые настройки (в частности, МАСадрес карты и выдаваемый IP), указать пароль обычного пользователя и root. Установив флажки, можно активировать поддержку NTP, установку принтеров и создать для клиента локальную учетную запись. Два поля ниже подсвечены другим цветом. По умолчанию LDAP не используется, но настройки в первом поле как раз

инструменты и позволяют сохранить или загрузить данные учетной записи из LDAP. Во втором поле указываются данные NFSресурса, который будет применяться для хранения домашнего каталога пользователя. В самом низу страницы дано краткое описание всех параметров (на английском). Чтобы не повторять все описанные настройки многократно, можно дать им название в Preferences и сохранить профиль. Когда настройки будут закончены, нажимаем кнопку Add. Также в m23 предлагается отдельное меню для предварительного создания профиля Mass tools → Client builder, в котором следует «пройти» все этапы. Позже, при создании нового клиента, можно будет просто выбирать профиль, корректируя его при необходимости. Теперь можно запускать клиентский компьютер, не забыв подключить сетевой шнур. Сразу же будет загружена система, через некоторое время процесс остановится, а в окне клиента можно будет наблюдать диалог ожидания следующей задачи (вообще монитор на клиенте не обязателен). Кто самостоятельно настраивал связку Linux + PXE + TFTPD + DHCP, тот может теперь оценить, насколько m23 упрощает этот процесс. Переходим в окно Clients → Setup, где будут показаны все клиенты, ожидающие установки, выбираем нужный, нажимаем ссылку Setup в самом последнем столбце и сразу переходим к этапу настройки разделов жесткого диска Client partitioning and formating, где создаем и форматируем новые разделы, указываем точки монтирования (см. рис. 2).

Рисунок 4. Управление пакетами в окне m23

22

март 2012 системный администратор

инструменты Процесс, в общем, несложен и напоминает работу с любой подобной программой. Предусмотрен вариант автоматического создания разделов Partition scheme → Automatic partitioning → Execute scheme, при этом будет создано два раздела: корневой (ext4) и swap. По окончании настроек нажимаем ссылку Finalise the partitioning and formatting… и переходим к этапу выбора дистрибутива. Итак, в списке Package sources выбираем имя шаблона и затем в User interface – рабочую среду. При этом в зависимости от дистрибутива доступные рабочие столы будут отличаться. Далее появляется возможность добавления пакетов, выбора места установки загрузчика и альтернативного ядра (если оно доступно). Все. Можно приступать к установке. Переходим в окно Clients → Overview, где в таблице Clients overview будут показаны все известные системы. Цвет в первой колонке определяет статус: >> Красный – клиент добавлен, но инвентаризация оборудования не завершена. >> Желтый – клиент готов к созданию разделов и форматированию, базовая система и графический интерфейс затем будут установлены автоматически. >> Зеленый – базовая система установлена, оборудование определено, можно добавлять дополнительные пакеты. >> Синий – производится установка пакетов. >> Оранжевый – произошла ошибка, клиент находится в критическом состоянии, требующем вмешательства администратора (обычно выдается подсказка по проблеме). >> Белый – master client, используемый для массовой установки на другие системы. >> Жук – клиент работает в режиме отладки. Узлы, на которых установлен VirtualBox OSE, дополнительно помечаются значком с буквой V. Чуть ниже расположены настройки для массовых операций. Отметив клиентов системы, можно добавить их в группу или удалить из нее. Сами группы создаются в Groups → Add, где нужно просто ввести имя новой группы. Для Debian, Ubuntu или клонов можно подключить к серверу m23 уже установленные ОС. Одно условие – на них должен быть запущен SSH. Хотя как вариант разработчики предлагают временный скрипт:

Администрирование ные настройки (установить, удалить пакеты (см. рис. 4), обновить клиента, создать образ, резервную копию и задание). Все настройки, в общем, понятны и в особых комментариях не нуждаются. При создании образа можно выбрать как весь диск, так и отдельные разделы; результат сохраняется в каталоге /m23/data+scripts/clientImages. Просмотреть список всех образов можно, перейдя в Server → Server settings → Manage image files. Создав образ раздела, мы можем восстановить его на другом компьютере, клонировав систему. *** На изучение и настройку всех основных функций, предоставляемых m23, необходимо потратить один-два дня, после чего свою дальнейшую деятельность уже будет трудно представить без этого удобного инструмента. EOF 1. Яремчук С. Централизованная настройка с помощью Puppet. //«Системный администратор», №7, 2007 г. – С. 58-61.

2. Яремчук С. Централизованное управление с помощью Cfengine. //«Системный администратор», №1-2, 2010 г. – С. 8687.

3. Сайт проекта m23 – http://m23.sourceforge.net.

4. Страница halfSister – http://m23.sourceforge.net/PostNuke-0.750/ html/index.php?id=1000000362 (http://clck.ru/Vle7).

5. Коммерческая поддержка проекта m23 – http://www.gooshabermann.de.

$ cd /tmp $ wget http://<serverIP>/work.php -O work.php $ sudo sh work.php

Теперь выбираем Clients → Assimilate, где вводим следующие данные: имя, IP-адрес, логин (если root, то поле можно оставить пустым) и пароль. После этого новый клиент появится в списке известных серверу, через некоторое время статус изменится с красного на зеленый, после чего им можно будет управлять. Щелкнув по имени клиента, переходим в Control Center (см. рис. 3), откуда можно выполнить основные настройки, получить статус и основную информацию (по оборудованию, установленным пакетам, журналу) и произвести основ-

системный администратор март 2012

23

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

инструменты

Визитка Рашид Ачилов, поклонник FreeBSD с многолетним опытом использования ее в совмещенных с Windows сетях и сторонник Open Source. Администратор сетей и средств защиты крупной торговой сети

Этот загадочный MTU Причина загадочной и необъяснимой неработоспособности сегмента VPN может крыться, как это ни странно, в MTU. Проведем разбор реальной ситуации, в которой именно MTU был «корнем зла», вспомним структуру IP-пакетов и найдем решение для шлюза с ОС FreeBSD и Windows-клиентов

А я тут ни при чем?

Читаем RFC

Итак, перед нами новый сегмент VPN, который мы присоединили к серверу с уже существующими подсетями для того, чтобы компьютеры, расположенные в новом блоке, обменивались данными с другими компьютерами, например, передача файлов по протоколу FTP с компьютера WinXA на компьютер WinYA (см. рис. 1). Красным пунктиром обозначены реальные подключения, синими сплошными линиями – туннели. Цвета IP-адресов соответственно обозначают их тип. Клиентские машины работают под Windows, шлюзы – как и указано на схеме, под FreeBSD. Поскольку технология построения туннелей IPSec была подробно описана в [1-3], мы вправе ожидать, что как только начнут проходить пинги с адреса 10.54.200.10 на адрес 10.55.3.3 и обратно, можно рапортовать начальству о готовности и давать отмашку пользователям. Хм. Можно, конечно, и отрапортовать, и отмашку дать. Только потом ее придется забрать обратно. Потому что пинги пингами, а... не работает. При заходе на FTP- сервер и попытке закачать туда какойлибо файл, сервер закрывает соединение (см. рис.2).

Мысли о том, что здесь «что-то не то» именно с МТU, возникают практически сразу, как только выясняется, что c правами у пользователя все нормально, место на сервере есть, вирусом файл не заражен, что «обычное» ICMP работает (соединение между сетями есть, маршрутизация настроена, пакеты доставляются), но при попытке отправить тот же пинг, но с ключом -D (установить бит Don't Fragment), ничего не получается. Проблема эта возникла давно, отнюдь не на пустом месте и во времена «диалапного» доступа в Интернет было множество материалов, посвященных настройкам MTU того или иного оборудования. Чтобы понять, откуда берется эта проблема и как можно попробовать ее решить (причем это только один из способов), нужно докопаться до сути – какую роль играют в передаче данных MTU, MSS, флаг DF в заголовке пакета IP и сообщение ICMP «Fragmentation needed». Начинаем с самого простого. Допустим, машина WinXA передает (пока неважно как) IP- пакет размером 1500 байт на шлюз сети В. При использовании Ethernet MTU по стандарту составит 1500, все данные будут помещены в один па-

Рисунок 1. Схема тестовой модели

Рисунок 2. Ошибка при передаче файла

24

март 2012 системный администратор

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

инструменты кет и благополучно достигнут адреса назначения. Связь есть. Но поскольку априори определить, какой MTU может быть у оборудования получателя, мы не в состоянии, то либо допускаем наличие такого же, как у нас оборудования, либо полагаемся на Internet Path MTU. А, к примеру, взяли и переподключили шлюз сети В через сетевую карту ARCNET c MTU 508. Пакет дойдет до сетевой карты и... не «пролазит в ворота». Связи нет. Было найдено сразу как минимум два решения этого вопроса. Способ первый – фрагментировать IP-пакеты. В заголовке IP были предусмотрены поля, указывающие на смещение фрагмента (+51 бит от начала заголовка), бит DF3 указывал, есть ли еще фрагменты или это последний. В нашем случае карта ARCNET c MTU = 508, получив пакет в 1500 байт, просто разбивает его на четыре, которые последовательно принимает. Почему на четыре, когда данных 1500? Потому что для передачи дополнительных пакетов будут сгенерированы дополнительные IP-заголовки (20 байт), поэтому во всех пакетах, начиная со второго, данных передается 488 байт. Таким образом, в первом пакете будут переданы 508 байт данных, во втором и третьем – по 488, а в четвертом – оставшиеся 16 байт. Но и на эти 16 байт тоже нужно сгенерировать IP-заголовок, в итоге вместо 1500 байт будет передано 1560. Недостатки этого способа, конечно же, заметны сразу. При фрагментации вырастают накладные расходы на передачу «лишних» заголовков, маршрутизатор загружается несвойственной ему работой по реассемблированию пакетов, место для которых он должен зарезервировать из расчета на то, что размер всего пакета ему неизвестен. Он должен принимать фрагменты до тех пор, пока не придет пакет с DF3=0, поэтому он отводит под них буферы достаточно большого размера. Кроме того, фрагментированные пакеты могут быть заблокированы брандмауэром или просто пропасть, например, из-за ошибок при построении сети. Если же один из фрагментов пакета пропадает, отбраковывается и заново передается весь пакет. Ладно, если это пакет Ethernet c MTU 1500. А если это пакет с MTU 8192? Все 8 Кб данных будут передаваться заново! Поэтому метод был отложен на «самый крайний случай», и придумали способ второй. Способ второй – договариваться о том, какого размера пакеты посылать друг другу. Предположить, какие устройства с какими MTU встретятся нам на пути, мы, конечно, не можем, но вполне можем обменяться информацией о том, какого размера приемные буферы у оконечных точек соединения. Для этого как раз и служит параметр MSS, задаваемый в заголовке пакета TCP, в поле опций. Поскольку это заголовок TCP, то в значении, задаваемом в этом поле, не учитываются длины заголовков IP и TCP, и, следовательно, оно на 40 меньше, чем MTU. Теперь каждая сторона при установлении соединения указывает в этом поле меньшее из двух – размеры приемного буфера и MTU. Использоваться будет самое минимальное значение. Это позволяет сразу выбрать максимально допустимый размер пакета, чтобы избежать фрагментирования. Да, это, конечно, сразу увеличит нагрузку на сеть, но по крайней мере маршрутизаторы не будут заниматься не свойственной им сборкой-разборкой пакетов, да и проблема повторных передач потерянных пакетов решится сама по себе.

системный администратор март 2012

Терминология MTU (Maximum Transfer Unit) – максимальный размер блока в байтах, который может быть передан на канальный уровень. Очень важно, что MTU изначально выставляется драйвером на основе того оборудования, которому пойдет передача. Впоследствии он может быть изменен, так, например, делает PPPoE. Разные каналы передачи имеют разные значения MTU, но нас интересуют только три: Ethernet – 1500 (RFC 1191), PPPoE – 1492 (RFC 2516) и так называемый Internet Path MTU, равный 576 (RFC 879). Последний – это некий универсум, который используется в качестве last resort-варианта, когда не работает нормальный режим. Этот универсум тем не менее не является минимальным – минимальный MTU (68 байт), как и максимальный (65535 байт), определяет RFC 791. Также надо отметить, что не существует способа до начала передачи определить MTU всех устройств на пути от точки источника до точки приемника.

MSS (Maximum Segment Size) – максимальный размер сегмента, то есть размер блока данных в пакете TCP. MSS – характеристика программная, она не связана ни с каким оборудованием, а определяется исключительно как элемент протокола, прописана в RFC 879 и задается каждый раз при установлении новой TCP-сессии, то есть MSS на момент, когда начинается обмен данными, известно совершенно точно.

DF (Don't Fragment) – биты флагов пакета IP, устанавливаемые каждый раз, когда передаваемый пакет не должен фрагментироваться. Биты флагов располагаются в заголовке пакета IP со смещением +48 бит от начала заголовка. Первый бит зарезервирован, второй (собственно DF) обозначает можно/нельзя фрагментировать, третий – последний/промежуточный фрагмент. Мы будем обозначать второй и третий биты DF2 и DF3 Fragmentation needed – управляющее сообщение ICMP (тип 3 – Destination Unreachable, код 4), которое возвращается отправителю, когда передаваемый пакет должен быть фрагментирован, но параметр DF запрещает это делать.

Но проблема «промежуточного роутера» все еще остается. Пойди угадай, какое оборудование встретится тебе на пути, когда Official minimum MTU – 68 байт. Для решения этой проблемы была разработана такая вещь, как Path MTU Discovery (PMTUD). Когда роутер принимает пакет такого размера, который должен быть фрагментирован для передачи, он не фрагментирует его, а отбрасывает. И при этом отправляет хосту-источнику ICMP-сообщение «Destination unreachable» (тип 3) c кодом ошибки «Fragmentation needed» (код 4). Для разрешения фрагментации служит бит DF2 в заголовке IP-пакета: когда он равен 0, пакет можно фрагментировать, когда 1, нельзя. В сообщении, возвращаемом роутером, есть чрезвычайно ценная информация – там содержится максимальный размер пакета, который проходит в данном направлении. Поэтому хост-источник, получив ICMP Destination Unreachable с кодом Fragmentation needed, просто уменьшает размер пакета (и соответственно уменьшает MSS в TCP-заголовке) до рекомендованного значения и переотправляет пакет. Если где-то по «дороге» встретится устройство, для которого это покажется чересчур, оно опять отправит ICMP Dest. Unreachable, и так до тех пор, пока пакет не дойдет до точки назначения. Эта технология, конечно же, повышает нагрузку на сеть – ведь в наихудшем случае пакет будет возвращаться каждым маршрутизатором, – но позволяет при установлении соединения передавать данные наиболее оптимально. Есть, конечно, и альтернатива – устанавливать заведомо низкий MTU, например, Internet Path MTU, равный 576 байт

25

Администрирование (так поступают некоторые программы, когда возникают проблемы с передачей данных). Ну, и, кроме того, PMTUD работает только для TCP-соединений. Еще одним минусом PMTUD является то, что он полностью полагается на прохождение ICMP-сообщений. ICMP может быть заблокировано провайдерами (что встречается весьма редко, хотя чаще блокируют не все ICMP, а только пакеты, в которых установлены некоторые флаги) или же корпоративным брандмауэром (что встречается куда чаще, чем хотелось бы, – начитается человек страшных историй про ICMPshells и давай косить его направо и налево!). А некоторые оригиналы идут еще дальше – они принудительно сбрасывают бит DF2 в заголовке, разрешая своим роутерам фрагментировать пакеты и, таким образом, нагружая их дополнительно. Цена безопасности, так сказать. Теперь, когда мы выяснили, как поведут себя узлы при передаче простого пакета, усложним задачу. Пусть машина WinXA связывается не с шлюзом сети В, а с машиной WinYA по заранее установленному IPSec-туннелю. Для определенности примем, что MTU туннельных интерфейсов – 1450. Что в таком случае должен сделать шлюз: >> Принять пакет из локальной сети, соблюдая соглашения PMTUD. >> Проверить размер MTU туннельного интерфейса и бит DF2 в пакете. >> Если DF2 установлен и пакет слишком большой – отбросить. >> Если же DF2 не установлен и пакет большой – фрагментировать, потом инкапсулировать в пакеты туннеля. >> Если пакет нормального размера, то инкапсулировать (и после этого, возможно, фрагментировать, так как инкапсуляция здорово увеличивает размер пакета). Рисунок 3. Схема прохождения пакета при передаче его по туннелю IPSec

инструменты Вернемся к нашему примеру (для простоты предположим, что со второй стороны мы наэкспериментировались с ARCNET и вернулись к нормальному оборудованию с MTU 1500). Мы передаем на адрес назначения 1500 байт (20 байт IP-заголовок + 1480 байт данных). Этот пакет шифруется IPSec, следовательно, у него «вырастают крылья, ноги и хвосты», а именно заголовок IPSec, окончание пакета IPSec и еще один IP-заголовок, который доставляет пакет. Заголовок и окончание пакета IPSec увеличивают размер пакета ни много ни мало на 52 байта, и размер его становится 1552 байта. Поскольку он превышает MTU, пакет фрагментируется (DF2=0), и теперь мы имеем два IP-пакета – размером 1500 и 72 байта (прибавился еще один IP-заголовок!). Пакеты передаются по туннелю, составляются в один при приеме, потом расшифровываются IPSec – вуаля! Но это, конечно же, идеальный вариант, в реальной жизни такого не бывает. DF2 непременно будет установлен, по «дороге» обязательно найдется старый полуживой роутер с MTU байт в 300 и т.д. На рис. 3 приведена небольшая схема, показывающая, как все может быть печально в реальной жизни. Рисунок взят из статьи [4], поэтому комментарии там на английском. Но, даже не вчитываясь в комментарии, можно заметить сразу, что в наихудшем случае пакет может быть отброшен трижды и трижды повторен.

Разбор пролета И только теперь, основательно разобравшись в теории, возвращаемся к нашим пакетам. На рис. 4 показан дамп трафика, прошедшего в подобной FTP-сессии. Мы попытались передать на машину WinYA файл mturoute.exe. Ничего не вышло... «Постойте! – скажете вы. – И это вся сессия? А где же все эти хитромудрые PMTUD с их ICMP-сообщениями, адаптирующие MSS к минимальному значению из возможных?» (напоминаю, что MTU туннеля – 1450). И правы будете, что спросите. Мне тоже захотелось об этом спросить авторов, писавших в свое время драйвер инкапсулирующего интерфейса gif, когда я впервые увидел этот дамп. Потому что на сессию-то особо глядеть не надо, чтобы понять, что происходило: MSS в первом SYN-пакете (обведен красной рамкой на рисунке) равен 1460 (1500 – 40). Когда FTP-сервер начал устанавливать соединение для приема файла, он, разумеется, прописал в TCP-пакете MSS, основанный на MTU своей сетевой карты. Но MTU интерфейса туннеля – 1450, и никто об этом не известил ни ту сторону, ни другую, в результате чего они обменялись MSS и установили его равным 1460. И когда на сервер пошли данные, то пакеты с данными были

Рисунок 4. Дамп трафика при попытке передачи файла по FTP

26

март 2012 системный администратор

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

инструменты отброшены на интерфейсе туннеля с его MTU 1450. Клиент сделал по одному ретрансмиту да и отвалился. Дамп снимался со стороны 10.54.200.10. После этого необходимо было убедиться в том, что PMTUD все-таки работает. И он работает. Верхней рамкой обведен MSS в начале сессии. Как мы видим, он равен 1460. Началась сессия, пошли пакеты с данными – и вот он, Dest. unreachable! После него в нижней рамке обведен размер MSS, который установился после того, как сработал PMTUD. То, что передача успешна, говорит самый нижний пакет – Transfer OK. Понимание наступило после чтения man gif(4): If the outer protocol is IPv4, gif does not try to perform path MTU discovery for the encapsulated packet (DF bit is set to 0). (Если внешний протокол – IPv4, gif не выполняет Path MTU Discovery для инкапсулированного пакета, DF-бит установлен в 0). Здесь имеется в виду, конечно же, бит DF2. Вот так. Назад в джунгли. Угадывать, какой MTU у всего оборудования в Интернете, и вручную его изменять. Разумеется, для этого придумали программы – например, mturoute [5]. Это простенькая консольная программа, которая имитирует работу PMTUD и отображает результат (см. рис.6). В Windows MTU можно изменить либо в реестре, в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters\Interfaces, в разделе Interfaces есть несколько подразделов с малопонятными именами, например, {84CF440B-93AB-40BC-912C-C79165EAC8BB} – это и есть один адаптер. Внутри него находятся параметры, если MTU там нет, значит, его надо создать. Имя параметра – MTU, тип – REG_DWORD. После этого сеть надо перезапустить или перезагрузиться. Можно скачать какую-либо программу, например [6], и использовать ее. Но это все на самом деле чушь. Ну, не станем же мы перед каждым выходом в Интернет исправлять MTU на одно значение, а перед заходом в VPN – на другое! Нужен способ, который сам бы определял, что пакет идет в таком-то направлении, что в нем есть флаг SYN, и именно в этом пакете изменял начальное значение MSS (то, которое WinXA отправляет для WinYA на согласование) на какое-нибудь заведомо укладывающееся в туннель, но все же не слишком маленькое. Прочитайте последнее предложение еще раз. Ничего не заметили? Это ведь фактически готовое правило для ipfw: ${fwcmd} add 700 <сделать-что-то> log tcp from { ↵

192.168.0.0/16 or 10.0.0.0/8 } to 10.54.200.0/24 ↵ tcpflags syn

Осталось только решить, что будет стоять там, где сейчас написано <сделать что-то>. Это может быть либо демон какой-нибудь, слушающий порт, принимающий пакеты и после изменения отправляющий их обратно (как это делает natd). Да вот и искать не надо, есть такая программа – net/ tcpmssd, либо... да что тут гадать – во FreeBSD есть такая изумительная по возможностям вещь, как Netgraph. Из-за ограниченных возможностей статьи я не буду рассказывать, что такое Netgraph и почему с его помощью можно сделать то же самое, что может tcpmssd, только лучшим образом. Скажу только, что это некоторый компонент ядра, позволяющий выполнять произвольные запрограммированные действия над пакетами, переданными на обработку. Несколько более подробно можно прочитать на [7]. Вот его-то, модуль Netgraph, который называется ng_tcpmss, мы и поставим вместо <сделать что-то>. Непосредственно, правда, это сделать невозможно. Любая нода Netgraph должна быть надлежащим образом настроена – только тогда она будет работать. Кроме того, для работы обязательно понадобится «интерфейс» к ipfw – модуль ng_ipfw, а также модуль ng_socket. Если указанные модули не встроены в ядро, то лучше их загружать через /boot/ loader.conf, добавив в него следующее: ng_ipfw_load="YES" ng_tcpmss_load="YES"

Модуль Netgraph будет загружен автоматически. Чтобы каждый раз не набирать длинные команды конфигурирования хуков модулей, оформим все это в виде процедуры, которую будем вызывать в файле /etc/rc.firewall, – согласитесь, самое подходящее для нее место (переменная $inet в данной процедуре имеет значение адреса внутренней подсети – internal net, – а вовсе не то, что вы все подумали): setup_tcpmss_fix() { case ${use_tcpmss_fix} in [Yy][Ee][Ss]) if [ -n "${set_tcpmss}" ]; then ngctl mkpeer ipfw: tcpmss 100 setfix ngctl msg ipfw:100 config \ { inHook=\"setfix\" outHook=\"setfix\" ↵

Рисунок 5. Дамп трафика при нормальной FTP-сессии с PMTUD

системный администратор март 2012

27

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

maxMSS=${set_tcpmss} } ${fwcmd} add 700 netgraph 100 log tcp from ↵

{ 192.168.0.0/16 or 10.0.0.0/8 } to ↵

${inet} tcpflags syn ${fwcmd} add 705 netgraph 100 log tcp from ${inet} ↵

to { 192.168.0.0/16 or 10.0.0.0/8 } tcpflags syn fi ;; esac }

Теперь осталось только добавить вызов процедуры в нужное место списка правил ipfw (это уж вы решайте сами, у каждого свои вкусы) и добавить в /etc/rc.conf следующие строки: use_tcpmss_fix="YES" set_tcpmss=1402

Число во второй строке – это новый размер MSS, который будет подставлен в пакет SYN. Поскольку он заведомо меньше 1460, то и будет выбран (разве только на той стороне окажется сетевая карта ARCNET). Но почему мы выбрали именно такое число? Магии в этом нет никакой. Уже упомянутая [4] дает достаточно конкретные и подробные рекомендации по выбору MTU в различных случаях. В случае Pure IPSec Tunnel Mode (в статье это Scenario 6), указывается, что, кроме заголовков TCP и IP, место в пакете еще будет занимать достаточно большой заголовок IPSec – 58 байт, следовательно, мы сможем разместить только 1442 байта пакета. Вычитая из этого числа размер заголовков TCP и IP (40 байт), получим 1402. Разумеется, эта рекомендация справедлива только для Ethernet. Если для выхода в Интернет используется другая среда, например, PPPoE c его MTU 1492, то рекомендуемое значение будет еще меньше – 1394 (1492 – 58 – 40). Ну что ж, остается только проверить справедливость наших рассуждений практикой, которая, как известно, критерий истины. Рисунок 6. Запуск программы mturoute

инструменты Запускаем FTP-клиент. Работает! Смотрим на дамп трафика (рис. 7). Да, вот оно хорошо видно: во входящем пакете MSS был исправлен на 1402, соответственно наш узел посчитал, что удаленная сторона по какимто причинам может принимать только пакеты с 1402 байтами данных. В эти пакеты он и «нарезал» передаваемый файл. На рисунке красной рамкой обведен переданный нам с «той стороны» и исправленный через ng_tcpmss MSS удаленной стороны, синей – MSS, который передаем на удаленную сторону мы. В данном примере удаленная сторона имеет адрес 192.168.81.3. *** Вот и решена загадка. В принципе все оказалось не так уж и сложно, хотя, конечно, при анализе ситуации пришлось припомнить многое. Обратите, пожалуйста, внимание, что при выборе номера правила в функции setup_ tcpmss_fix, правила, направляющие трафик на ng_tcpmss, должны идти впереди любых разрешающих правил, чтобы установление сессии, неважно, как оно происходит – по инициативе хоста из внутренней сети или из соседнего сегмента, – всегда приводило к корректировке MSS. При анализе проблемы мне воистину неоценимую помощь оказала статья [4]. Не знаю, кто ее автор – Cisco по какой-то причине это скрывает, – но он действительно знает, о чем пишет. EOF 1. Ачилов Р. Построение корпоративных VPN. Использование IPSec. Часть 2. //«Системный администратор», №12, 2010 г. – С. 13-19.

2. Ачилов Р. Построение корпоративных VPN. Использование IPSec для связи с аппаратным роутером. //«Системный администратор», №3, 2011 г. – С. 28-32.

3. Ачилов Р. Построение корпоративных VPN. Использование IPSec для связи с программным роутером. //«Системный администратор», №4, 2010 г. – С. 26-29.

4. Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC (на английском языке) – http://www.cisco.com/en/US/ tech/tk827/tk369/technologies_white_paper09186a00800d6979. shtml.

5. Программа mturoute.exe для анализа MTU всех устройств на маршруте до указанного хоста – http://softkumir.ru/index. php?id=1236303325.

6. Программа Dr.TCP для самостоятельной настройки параметров сетевых интерфейсов в Windows – http://www.dslreports.com/ front/drtcp.html.

7. Статья по некоторым основам Netgraph «Netgraph для пользователя» – http://nuclight.livejournal.com/126612.html.

Рисунок 7. Дамп успешно прошедшей сессии FTP

28

март 2012 системный администратор

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

удаленная работа

Визитка Станислав Шпак, более пяти лет занимается сопровождением Active Directory и Windows-серверов. Имеет сертификаты MCSE по Windows Server 2000/2003

RD Gateway

Шлюз удаленных рабочих столов Расскажу о новой технологии Remote Desktop Gateway (ранее – Terminal Services Gateway), доступной начиная с Windows Server 2008 и несколько доработанной в Windows Server 2008 R2. Давайте посмотрим, что может дать внедрение шлюза удаленных рабочих столов для работы за пределами корпоративной сети

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

Основные вопросы, решаемые на этом этапе: >> как обеспечить аутентификацию подключающегося удаленно пользователя; >> как не дать ему прав больше, чем нужно; >> как быть уверенным в том, что удаленный компьютер не станет рассадником вирусов; >> как защитить подключение от прослушивания; >> как быть уверенным в том, что логин и пароль при подключении вводятся именно легитимным пользователем, а не злоумышленником? Арсенал средств, для решения этих вопросов тоже весьма разнообразный. Когда я впервые прочел в описании

Рисунок 1. Выбор необходимой роли

30

март 2012 системный администратор

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

удаленная работа новшеств Windows Server 2008 про шлюз удаленных рабочих столов, то воспринял его просто как компьютер, который принимает подключения снаружи и перенаправляет их внутрь. Да, он это делает по HTTPS, но никаких практических задач по этой теме тогда не стояло, поэтому я не придал особого значения этой серверной роли. Вернуться к данному вопросу пришлось спустя почти два года, когда возникла необходимость более пристально исследовать вопрос удаленного доступа в сеть снаружи. Это было вызвано тем, что в моей организации давно и широко используется кластер из терминальных серверов и всем пользователям хорошо знакома специфика удаленной работы. Однако доступ к кластеру извне был ограничен определенными статическими IP-адресами филиалов, что более-менее гарантировало «чистоту подключений». Но уже назрела необходимость обеспечить клиентские соединения с произвольных IP-адресов. Можно было обойтись простой публикацией сервиса «наружу», но вызывала беспокойство возможность утечки корпоративных паролей. Да и вариант с их подбором для RDP нельзя отметать. Хотелось внедрить для такого доступа двухфакторную аутентификацию (использование для подключения смарт-карт в виде токена), однако тогда всем сотрудникам пришлось бы пользоваться токеном и при работе «внутри сети». Это лишние неудобства для пользователей и администратора, т.к. сроки службы сертификатов истекают, люди забывают смарт-карту и т.п. Да и чаще всего подобный уровень защиты внутри домена просто не нужен. Подробнее про двухфакторную аутентификацию можно узнать на страницах журнала в [1], а про внедрение смарткарт в домене в [2]. Если оставлять возможность входа по смарт-карте или по паролю. то это не решает проблемы с парольной зависимостью.

Вот здесь я и вспомнил про шлюз удаленных рабочих столов, который дает следующее: >> RDP-трафик идет в зашифрованном SSL-канале, подключение к серверу ведется по стандартному 443-му порту (что не требует дополнительных ухищрений для доступа со стороны клиента, так как этот порт открыт по умолчанию в большинстве сетей); >> управление группами пользователей, которые могут подключаться через шлюз и группами внутренних ресурсов, к которым возможно подключение; >> проведение оценки состояния клиентского компьютера перед подключением; >> возможность требования использования смарт-карты для подключения к шлюзу, при этом вход на целевой компьютер может производиться по паролю; >> всякие мелкие «вкусности» типа использования «единого входа» (SSO), задание списка доступных в удаленном сеансе локальных ресурсов и т. п. Было решено провести пилотное внедрение шлюза удаленных рабочих столов, об опыте развертывания которого я сейчас и расскажу.

Установка Remote Desktop Gateway (Шлюз удаленных рабочих столов) – это одна из служб роли Remote Desktop Services (Службы удаленных рабочих столов). Для установки будем использовать Server manager (Диспетчер сервера) (см. рис. 1). В следующем окне при выборе служб роли Remote Desktop Gateway будет выдано предупреждение об автоматической установке некоторых сопутствующих компонентов и служб ролей (см. рис. 2). На следующем шаге мы должны выбрать сертификат сервера либо сгенерировать самоподписанный сертифи-

Рисунок 2. Выбор необходимой службы роли и просмотр дополнительно необходимых компонентов

системный администратор март 2012

31

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

удаленная работа

кат. Если сервер является членом домена, в котором развернуты службы PKI (Public Key Infrastructure), то имеет смысл специально запросить сертификат сервера у корпоративного центра сертификации. Если его нет, можно использовать самоподписанный сертификат. Далее предлагается либо определить политики авторизации, либо сделать это позже. Имеет смысл сделать хотя бы одну политику сразу, поэтому выбираем вариант Now (Сейчас) и приступаем. Всего потребуется создать как минимум две политики – Connection Authorization Policy (CAP – Политика авторизации подключений) и Resource Authorization Policy (RAP – Политика авторизации ресурсов). Первая будет определять особенности подключения к самому шлюзу, а вторая – какие именно ресурсы доступны пользователю после успешного подключения. К таковым могут относиться терминальные серверы, серверы публикации приложений RemoteApps, посредники подключений к удаленному рабочему столу (Remote Desktop connection broker), компьютеры с запущенной службой Remote Desktop. Следующим шагом мастера можно задать группу пользователей, которым разрешено использовать данный шлюз. По умолчанию сюда уже входят члены группы локальных администраторов. Затем переходим к следующему этапу – созданию политик подключения (CAP). Вообще в ней задается, какие группы пользователей и с каких компьютеров могут осуществлять подключение к шлюзу, какие при этом доступны методы аутентификации, какие локальные ресурсы будут доступны для удаленного подключения, а также тайм-ауты подключения. Однако в данном мастере доступны только задание имени политики и выбор метода аутентификации – смарт-карты, пароль, либо и то, и другое. На мой взгляд, использование только смарт-карт для подключения через шлюз удаленных рабочих столов – очень хорошая возможность. Разумеется, если в домене имеются развернутые службы PKI (Public Key Infrastructure). В этом случае существенно повышается безопасность, т.к. злоумышленнику для подключения потребуется как сама смарткарта (токен), так и PIN-код к ней. При этом пользователь

при работе во внутренней сети может продолжать далее использовать только логин-пароль для аутентификации. Но надо иметь в виду, что сертификат на смарт-карте или токене имеет ограниченный срок службы (который задается шаблоном при выпуске) и рано или поздно истечет. Никаких предварительных предупреждений пользователю выдаваться не будет. Поэтому на системного администратора ложится обязанность следить за сроком службы сертификатов. Когда речь идет о нескольких десятках сотрудников, это не очень большая проблема. А для полномасштабных решений можно использовать специальное ПО, позволяющее отслеживать состояние сертификатов. После создания политики подключения переходим к созданию политики доступа к ресурсам (RAP). В ней можно задать, каким пользователям, к каким серверам разрешен доступ через шлюз и по каким портам. В мастере мы видим упрощенный вариант – можем либо выбрать группу компьютеров для доступа, либо разрешить доступ ко всем ресурсам внутри сети. Пользователю будет разрешено подключение только в том случае, если для него существует разрешающая политика CAP, а внутренний ресурс, к которому производится подключение, перечислен хотя бы в одной из политик RAP. На этом секция настройки непосредственно Remote Desktop Gateway завершается, и мастер переходит к конфигурированию дополнительных компонентов. Здесь везде можно нажать «Далее», оставив все значения по умолчанию. При необходимости их можно настроить позже. Важное замечание! Для тех, кто выбрал использование автоматически сгенерированного сертификата сервера. Вам потребуется экспортировать этот сертификат в файл. Для этого запустите оснастку «Сертификаты», выберите управление сертификатами учетной записи компьютера, разверните ветку Certificates (Local computer) → Personal → Certificates. Справа нажмите правой кнопкой мыши по нужному сертификату, выберите All task → Export и следуйте указаниям мастера. Экспортировать закрытый ключ ни в коем случае не надо. Полученный файл сертификата вам потребуется установить на локальных компьюте-

Рисунок 3. Настройка клиентской части

Рисунок 4. Запрос метода аутентификации

32

март 2012 системный администратор

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

Настройка клиента Для подключения через шлюз удаленных рабочих столов потребуется клиент Remote Desktop Connection версии не ниже 6.1 (доступен для Windows XP SP2) либо версии 7.0 (Windows XP SP3 и выше). Причем некоторые функции (например, системные сообщения при входе и др.) доступны только для версии 7.0. На сервере можно запретить подключение клиентов более старых версий. Перед началом использования шлюза удаленных рабочих столов убедитесь, что вы импортировали сертификат сервера (при использовании самоподписанного сертификата) или корневого центра сертификации (при использовании сертификата, выданного корпоративным или сторонним центром сертификации) в локальное хранилище доверенных корневых сертификатов компьютера (не пользователя!). Для использования сервера удаленных рабочих столов нужно запустить клиент подключения к удаленному рабочему столу (mstsc.exe или «Пуск → Программы → Стандартные → Подключение к удаленному рабочему столу»), открыть «Параметры», перейти на вкладку «Подключение» (в английской версии Advanced) и в разделе «Подключение из любого места» (Connect from anywhere) нажать внизу кнопку «Параметры» (Settings). В появившемся окне (см. рис. 3) требуется задать необходимые настройки – адрес шлюза удаленных рабочих столов, метод аутентификации, нужно ли использовать шлюз при локальных подключениях (обычно не нужно), а также использовать ли учетные данные, заданные для шлюза и для входа на целевой ресурс (опция, которая позволяет не вводить логин-пароль или PINкод от смарт-карты повторно). Теперь достаточно на вкладке «Общие» (General) указать имя или адрес внутреннего ресурса и нажать «Подключение» (Connect). Обращаю ваше внимание, что разрешение имени, указанного в адресе для подключения с использованием шлюза удаленных рабочих столов, происходит на стороне шлюза. То есть вы можете смело задавать внутренние имена компьютеров, клиентский компьютер не будет пытаться разрешить их в IP-адрес, это сделает шлюз (разумеется, сам шлюз должен быть в состоянии разрешать внутренние имена компьютеров). Если параметр «метод входа» задан как на рис. 3, то при попытке подключения будет выдано окно с выбором метода аутентификации (см. рис. 4). Разумеется, метод аутентификации, заданный на шлюзе, имеет более высокий приоритет, и если в настройках шлюза вы указали в политике подключения только использование смарт-карты, то попытка подключения по логину/паролю окончится неудачей (см. рис. 5).

системный администратор март 2012

Администрирование Подробнее о политиках RD-Gateway Провести более гибкую настройку шлюза удаленных рабочих столов можно благодаря политикам подключения и использования ресурсов (CAP и RAP). Напомню, что первая (CAP) предназначена для того, чтобы определять, кто и как может использовать шлюз, а вторая (RAP) – кто и к каким внутренним ресурсам может получить доступ. К сожалению, нельзя создавать политики для отдельных пользователей или компьютеров – только для групп. Для управления сервером RD-Gateway откройте Server Manager, разверните узел Roles (Роли) → Remote Desktop Services (Службы удаленных рабочих столов) → RD-Gateway Manager»(Диспетчер шлюза удаленных рабочих столов) → <имя_сервера>. Здесь доступны два узла – Policies (Политики) и Monitoring (Наблюдение). В первом как раз и располагаются политики. На рис. 6 видны политики подключения. Они применяются поочередно сверху вниз, поэтому будьте внимательны при заведении нескольких политик. Здесь можно изменить либо завести новую политику, причем получить уже не сокращенный вид опций, как в мастере установки, а полноценный. Обратите внимание на вкладку Timeout (Время ожидания) с заданием временных ограничений для сессии. Это может показаться лишним на первый взгляд, ведь подобные настройки есть непосредственно на терминальных серверах, но интересна тут последняя опция – Silently re-authenticate and reauthorization session (Выполнить повторную авторизацию и проверку подлинности без предупреждения), позволяющая повторно применять политики к уже установленным сессиям. Существующие сессии будут сброшены, если они уже не подпадают под действие политики. Очень рекомендую не отключать тайм-ауты, так как иногда завершенная сессия остается активной на шлюзе. Политики авторизации ресурсов располагаются в соседнем узле. Здесь отдельно нужно сказать о вкладке Network Resources (Сетевой ресурс) в свойствах политики, на которой требуется указать, к каким внутренним компьютерам разрешен доступ. Можно использовать группу Active Directory (первая опция), задать ее на самом шлюзе или разрешить полный доступ без ограничений. Если вы используете кластер терминальных серверов, то потребуется перечислить все имена серверов, входящих в него вместе с его общим именем. Если клиент будет производить подключение, используя в качестве целевого ресурса IP-адрес внутреннего компьютера, то его также надо указать здесь. Рисунок 5. Ошибка подключения при неправильном методе аутентификации

33

Администрирование В дальнейшем изменить группу ресурсов, заданную на шлюзе, можно, нажав правой кнопкой мыши на узле Resource Authorization Policies (Политики авторизации ресурсов) и в контекстном меню выбрав Manage local computer group (Управление локальными группами компьютеров). Так же, как и политики подключения, политики авторизации ресурсов применяются сверху вниз.

Защита доступа к сети Говоря о RD-Gateway в Windows Server 2008 R2, нельзя не упомянуть функцию обеспечения защиты доступа к сети (NAP – Network Access Protection). Под таким громким названием скрывается возможность проверять некоторые настройки клиентского компьютера (выступающего как NAPклиент) и запрещать доступ, если они не соответствуют заданным шаблонам. Подобная функция уже существовала в более ранних версиях Windows Server, например, при обеспечении VPN-доступа, но была достаточно сложна в реализации. В Windows Server 2008 R2 данный функционал обеспечивается ролью Network Policies and Access Services (NPS – Службы политики сети и доступа), которой мы сейчас коснемся только в плане настройки для RD-Gateway. Но первое, что нужно сделать, это убедиться, что в настройках шлюза установлена возможность проверки состояния клиентского компьютера. Для этого идем в RD-Gateway Manager, нажимаем правой кнопкой мыши на имени сервера и вызываем Properties (Свойства). Переходим на вкладку RD CAP Store (Хранилище политики авторизации подключений к удаленным рабочим столам) и убеждаемся, что опция Request clients to send a statement of health (Запросить отправку клиентами состояния работоспособности) включена. Кстати, обратите внимание, что на этой же вкладке можно настроить, нужно ли в качестве Network Policy Server использовать локальный компьютер или уже имеющийся другой сервер. Все остальные настройки необходимо выполнять уже в оснастке конфигурирования NPS.

удаленная работа Сначала надо настроить Windows Security Health Validator (Средства проверки работоспособности системы). Для этого на NPS-сервере нужно запустить оснастку Network Policy Server (либо перейти в соответствующий узел через Server Management), перейти в ветку Network Access Protection (Защита доступа к сети) → System Health Validators (Средства проверки работоспособности системы) → Configure System Health Validators (Средство проверки работоспособности системы безопасности Windows) → Settings (Параметры). В правой части окна дважды щелкните по «Default configuration» (Конфигурация по умолчанию) (см. рис. 7). Здесь необходимо задать условия, выполнение которых будет проверяться на NAP-клиенте (см. рис. 8). К таковым относятся настройки брандмауэра (включен/выключен), антивируса (включен/выключен/обновлен), настройки автоматического обновления Windows (включено/выключено/как давно ставились обновления и какие) отдельно для Windows 7/Vista и Windows XP SP3. Обращаю внимание, что Windows Server 2008 не может быть NAP-клиентом. Далее переходим к настройкам политик. Воспользуемся мастером Configure NAP (Настройка NAP). Чтобы его вызвать, перейдите в корень оснастки NPS (выбрав в дереве ваш NPS-сервер) и справа нажмите Configure NAP. Так как мы создаем политику для RD-Gateway, то часть настроек будет соответствовать тем, о которых мы уже говорили ранее, когда обсуждали настройку RD CAP. Итак, на первом шаге Select Network Connection Method for Use with NAP (Выберите метод подключения к сети для использования с NAP) нужно в выпадающем списке указать Remote Desktop Gateway (RD- Gateway) (Шлюз удаленных рабочих столов (Шлюз RD). На следующем шаге нужно указать RD-Gateway-серверы, которые будут использовать создаваемые политики. Если NPS-сервер и RD-Gateway-сервер работают на одном и том же компьютере, можно ничего не указывать и перейти далее, где задать опции перенаправления устройств и методы проверки подлинности, затем тайм-ауты, группы поль-

Рисунок 6. Политики подключения (RD CAP)

34

март 2012 системный администратор

удаленная работа зователей или компьютеров (опционально), которым разрешено подключение. Далее происходит привязка политики к ранее настроенному System Health Validators (Средства проверки работоспособности) и определение того, разрешен ли доступ или запрещен в случае подключения не NAPклиента. В результате работы мастера создаются две Health policy (Политики работоспособности) и три Network Policies (Сетевые политики). Конфигурирование сервера закончено, однако теперь требуется настройка клиента. Настройка заключается в добавлении двух записей в реестр – включения и запуска службы NAP. Это можно сделать вручную или использовать предлагаемый Microsoft cmd-файл Tsgqecclientconfig.txt [3]. После скачивания надо поменять расширение на .CMD и запустить файл, указав в качестве параметра командной строки имя RD-Gateway-сервера. Скрипт выполняет следующие операции: добавляет имя сервера в список доверенных узлов, включает в реестре TS Gateway Quarantine Enforcement Client, меняет у службы Network Access Protection тип запуска на Auto и затем запускает ее. Если все прошло успешно, то результаты работы скрипта будут следующими: Setting the list of trusted TS Gateway servers to <server_ name> ...

The operation completed successfully.

Enabling the TS Gateway Quarantine Enforcement Client The operation completed successfully.

Setting the Network Access Protection service startup type to Automatic...

[SC] ChangeServiceConfig SUCCESS Starting the Network Access Protection service...

The Network Access Protection Agent service is starting.

The Network Access Protection Agent service was started successfully.

Можно приступать к тестированию. Если клиентский компьютер удовлетворяет всем заданным в System Health

Администрирование Validators требованиям, то произойдет подключение. Иначе будет выведено сообщение об ошибке.

Устранение неисправностей Наиболее частая ошибка при настройке RD-Gateway связана с сертификатами. Напоминаю, что на клиентском компьютере должно быть доверие корневому центру сертификации либо сертификату сервера RD-Gateway (в случае использования самоподписанного сертификата). Если применяется корпоративная PKI-инфраструктура, то она должна быть полностью рабочая, что подразумевает также своевременное обновление списков отзыва сертификатов и доступ к этому списку клиентов из-за пределов корпоративной сети. Имейте в виду, что в Windows 2008/Vista SP1 и выше при проверке списка отзывов сертификатов по умолчанию отключена возможность обращения за CRL по UNC-путям [4]. Кроме того, имя, по которому клиенты подключаются к серверу, должно быть указано в Subject Name сертификата. Если вы хотите использовать разные имена (например, для внутренних и внешних клиентов), то должны указать Subject Alternative Name (SAN), где будут перечислены все (в том числе и основное) имена, по которым станут вестись обращения к серверу. Как запросить сертификат с SAN, можно узнать в [5]. Напоминаю, что нужно не забывать следить за порядком следования политик. Если вы используете функцию защиты доступа к сети, то три политики подключения (политики 2-4 на рис. 6) видны в оснастке RD-Gateway Manager, но доступны для изменения только через оснастку Network Policies and Access Services. Обратите внимание, что на рис. 6 политика TS_CAP_01 стоит на первом месте, то есть в соответствии с ней обеспечивается подключение некоторых пользователей до применения политик, обеспечивающих проверку состояния клиента. Во избежание путаницы с порядком следования политик Microsoft рекомендует вообще удалить все RD CAP политики перед настройкой политик NAP.

Рисунок 7. Настройка NPS

системный администратор март 2012

35

Администрирование В Windows XP SP3 происходит просто проверка соответствия состояния клиента, в Windows 7 делается попытка исправить настройки автоматически в рамках политики (например, включить отключенное обновление Windows). Вообще с аккуратностью подходите к заданию критериев для состояния системы. Например, кроме простой проверки, включено ли обновление системы, можно указать дополнительные параметры (на рис. 8 они не видны, т.к. скрыты внизу). В этом случае могут возникнуть ситуации, когда обновление скачано, но еще не установлено, и поэтому доступ будет запрещен. Имейте также в виду, что Windows Server и Windows XP ниже SP3 не могут быть NAP-клиентами. И не забывайте про такое средство диагностики, как «Журнал событий». Кроме обычных журналов системы и приложений, дополнительные данные по работе шлюза можно получить в «Журнале приложений и служб → Terminal Services-Gateway». При определении проблем, связанных с неподходящим состоянием клиентского компьютера, придется обратиться к записям событий на стороне клиента. Из мелких неудобств, обнаруженных за время работы, можно назвать то, что не всегда срабатывает Single Sign On (использование ранее введенных учетных данных) – даже если со стороны клиента указана опция «Использовать мои учетные данные шлюза удаленных рабочих столов для удаленного компьютера», все равно целевой ресурс иногда требует ввода пароля. Кроме того, целевой сервер иногда при входе не видит смарт-карту, хотя после входа по паролю прекрасно с ней взаимодействует. Это наблюдалось на разных операционных системах, причину такого поведения выяснить не удалось. Систематизировать данные для определения общих черт этой проблемы пока тоже не удалось. В принципе она не вызывает больших неудобств – всего лишь при подключении приходится вводить лишний раз пароль.

удаленная работа *** Итак, в результате мы получили шлюз, посредством которого внешние клиенты могут относительно безопасно подключаться к внутренним Remote Desktop-ресурсам. При этом для подключения используется стандартный HTTPS порт 443. На шлюзе можно задавать разные политики для разных клиентов, управляя перенаправлением устройств и доступом к разным целевым ресурсам. При имеющейся в домене PKI-инфраструктуре можно потребовать проверку подлинности на основе смарткарты для шлюза, при этом не включая требования входа по смарт-карте на уровне учетной записи, что существенно повысит безопасность ввиду использования двухфакторной аутентификации. Применяя функцию защиты доступа к сети, можно проверять на клиентском компьютер наличие антивируса, актуальность его баз, состояние брандмауэра, системных обновлений и отказывать в подключении, если какое-либо условие не выполнено. EOF 1. Шапиро Л. Active Directory Domain Services. Двухфакторная аутентификация. Теоретические основы. //«Системный администратор», №7-8, 2010 г. – С. 100-105 (http://samag.ru/archive/ article/992).

2. Шпак С. Внедряем смарт-карты в домене». //«Системный администратор», №2, 2009 г. – С. 46-50.

3. Configure Terminal Services Clients as Network Access Protection (NAP) Enforcement Clients for TS Gateway – http://go.microsoft. com/fwlink/?LinkId=103093.

4. Description of the changes to network retrieval of PKI objects in Windows Vista Service Pack 1 and in Windows Server 2008 – http:// support.microsoft.com/kb/946401/en-us.

5. How to add a Subject Alternative Name to a secure LDAP certificate – http://support.microsoft.com/kb/931351/en-us.

Рисунок 8. Задание параметров проверки состояния NAP-клиента

36

март 2012 системный администратор

облачные технологии

Администрирование Визитка Ренат Гараев, опыт работы в сфере ИТ более 10 лет. Работает ведущим инженером-программистом в строительной проектной организации ГУП «Татинвестгражданпроект»

Проект ownCloud

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

Передачу данных можно осуществить с помощью носителя информации, электронной почты, файлообменника, облачного сервиса хранения данных, FTP/SFTP. Каждый из этих вариантов не идеален. Мы или зависим от чужих сервисов (в них бесплатные опции ограничены), или необходимо производить дополнительные настройки в программах. Например, при использовании SFTP операция настройки прав доступа и квот на размер хранимых данных не совсем удобна при эксплуатации с точки зрения обычного пользователя, который будет производить данные операции в повседневной работе. Критерии, которые мы хотим получить от нашего сервиса для обмена данными: >> доступ к данным с любого компьютера, без необходимости установки дополнительного ПО (через браузер); >> возможность обмена любых файлов без ограничений; >> прозрачность при работе с хранилищем (возможность подключения в виде сетевого диска); >> легкое добавление прав на просмотр файлов и каталогов (даже без регистрации в системе); >> предпросмотр файлов прямо в браузере (без скачивания) либо в виде галереи; >> возможность ведения заметок или комментариев. В Интернете можно найти несколько Open Source-решений, позволяющих организовать обмен файлами. По некоторым причинам они мне не подошли. Например, F*EX (Frams' Fast File Exchange) и ByteHoard. После регистрации в F*EX можно с помощью Java апплета загружать данные на сервер, при этом генерируется временная ссылка, с помощью которой можно скачать файл в течение пяти дней.

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

Свое облако из ownCloud В результате тестирования и сравнения различных систем нам подошел ownCloud. Мое первое знакомство с ownCloud состоялось с одной из их первых версий, однако ни процесс

системный администратор март 2012

установки и настройки, ни сам веб-интерфейс не показался особо дружественным и удобным. Однако с релизом версии 3.0, я считаю, этот продукт является интересным в качестве альтернативы другим сервисам для обмена информацией, поскольку ownCloud имеет очень богатый функционал, а также легок в освоении и использовании. Люди не хотят читать инструкции к программам, они хотят, чтобы все было просто, понятно и удобно. Но даже если что-то не нравится в этом проекте или появились свои идеи, можете обратиться к авторам либо просто взять и доработать сами. Данная среда разрабатывалась программистами пользовательского интерфейса KDE, знакомого пользователям Linux. Сейчас основатели проекта создали коммерческую компанию [1], которая планирует начать предоставление сервисов на базе данной платформы. В оwnСloud реализованы следующие возможности: >> Хранение любых типов файлов. >> Управление доступом и квотами через веб-интерфейс. >> Доступ к файлам и каталогам можно предоставить как для пользователей и групп системы ownCloud, так и в виде прямой ссылки (без регистрации в системе). >> Галерея для просмотра фотографий – сначала отображаются миниатюры, а при выборе фотографии имеется возможность пролистывать их в полном экранном режиме. >> Календарь и планировщик заданий. >> Контакты (адресная книга). >> Закладки (Bookmarks). >> Мгновенный поиск по данным (результаты выводятся по мере ввода символов). >> Возможность просмотра файлов (включая файлы pdf), а также редактирования (текстовых) файлов прямо в программе интернет-браузера. >> Поддержка адресов Ampache и синхронизации календаря CardDAV. >> Система плагинов с возможностью создания собственных расширений с реализацией дополнительных функций. >> Поддержка протокола WebDAV.

37

Администрирование >> Открытый исходный код. >> Бесплатность. Интерфейс системы ownCloud представлен на многих языках, включая русский, но иногда могут встретиться не переведенные английские слова (например, Share, Rename, Download и др.), что не должно создать неудобств при использовании, т.к. у данных функций представлены значки-пиктограммы. Система ownCloud написана на PHP и для работы требует дополнительные модули [2]: php5-json, php-xml, php-mbstring, php5-zip, php5-gd. Фактически данному приложению требуется LAMP (Linux, Apache, MySQL, PHP) с дополнительными модулями (или компонентами PHP). В качестве СУБД ownCloud может работать со SQLite, PosgreSQL или MySQL. Также необходимо отметить, что комфортная работа с ownCloud возможна только с последними версиями Mozilla Firefox, Google Chrome, Opera, с Internet Explorer 9 навигация была просто проблематичной. Далее речь пойдет об установке и настройке ownCloud в системах Windows и Linux.

Установка в Windows Установка была успешно протестирована под x64-битными версиями Windows Server 2008 и Windows 7, в качестве LAMP был использован XAMPP for Windows [3]. Весь процесс достаточно прост, поэтому подробно рассказывать не имеет смысла. Скачиваем ownСloud и распаковываем в каталог, где установлен XAMPP, тут как раз речь о каталоге веб-сервера (по умолчанию c:\xampp\htdocs\). Если у вас не получается распаковать архив исходных кодов ownCloud, тогда установите архиватор 7-zip [4]. Затем открываем браузер и в адресной строке набираем http://localhost/owncloud и регистрируем пользователя-администратора, задав ему имя и пароль, а также базу данных MySQL. Установку под Linux рассмотрим чуть подробнее.

Установка ownCloud под Linux Для дистрибутивов OpenSUSE и Ubuntu предлагаются предустановленные окружения: SUSE Studio [5] и [6] соответственно. Я в своей работе использовал Fedora (в версии Russian Remix), поэтому и об установке буду рассказывать на его примере. Во время инсталляции дистрибутива выбран Web Server, остальные компоненты остановлены по умолчанию. Рисунок 1. Предоставление (Share) доступа в виде ссылки (без регистрации make public) и для группы outuser с правами для просмотра

облачные технологии Добавим MySQL и включим автозагрузку Apache и MySQL: # yum install mysql-server -y # chkconfig mysqld on # chkconfig httpd on

Зададим пароль для MySQL-сервера: # mysqladmin -u root password 'secret_password'

Скачиваем дистрибутив ownСloud, распаковываем его в /var/www/html, установим владельца файлов: # chown apache:apache -R owncloud*

В Fedora разработчики ownCloud во избежание ошибок при установке рекомендуют отключить SELinux [7]: #setenforce 0

Откройте браузер, впишите в него IP-адрес сервера и папку owncloud. Вы увидите сообщение об ошибке при запуске установки ownCloud: PHP module zip not installed, PHP module mb miltibyte not installed. Please ask you server administrator to install the module

Попробуем найти данные модули командами: yum search mbstring yum search php-zip

Модуль mbstring имеется для Fedora, а php-zip – нет. Если бы мы использовали Red Hat Enterprise Linux, то его можно было установить из репозитария Fedora EPEL (называется php-pecl-zip). К сожалению, пакет для Fedora 16 не устанавливается [8]. То есть, чтобы нам получить этот модуль, увы, придется вручную скомпилировать PHP из исходных текстов. Доустанавливаем компоненты, необходимые для сборки: #yum install gcc make libxml2-devel libcurl-devel ↵

freetype-devel libpng-devel libjpeg-turbo-devel ↵

gmp-devel mysql-devel httpd-devel -y

И даем команду: ./configure

не забыв указать: '--enable-zip' '--enable-mbstring' '--with-mysql' ↵

'--with-libdir=lib64'

(остальные значения и параметры можно посмотреть, запустив функцию phpinfo(); из файла php), после чего произведем стандартную сборку и установку PHP: # make && make install && make clean

В идеале необходимо собрать RPM-пакет, но это не тема для данной статьи, поэтому ограничимся «стандартной» сборкой. Если будете устанавливать ownCloud для других систем Linux, не забудьте посмотреть на список требуемых

38

март 2012 системный администратор

облачные технологии

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

ownCloud – это сетевые службы под вашим контролем

пакетов и зависимостей, которые необходимо будет предварительно установить [2]. Сразу же рассмотрим ошибки, которые могут появиться в процессе тестирования и работы с файлами в ownCloud, – это ограничения на закачку файлов: >> не получается отправить в облако (upload) файлы большого размера; >> при upload файлов создается ощущение, что файл загружается, но потом оказывается, что загрузилось гораздо меньшее количество файлов. По умолчанию PHP сконфигурирован так, что нельзя загружать файлы большого размера. Настройки сохраняются в файле php.ini, который находится в C:\xampp\php или /etc у Fedora (в других дистрибутивах пути могут отличаться). Откорректируйте, изменив значения, установленное по умолчанию на большее: ;Максимальное количество памяти, выделяемое скрипту ;по умолчанию ;memory_limit = 128M

зователь владеет только одним своим списком контактов и календарем). Если необходимо предоставить доступ к вашим данным, то это можно сделать двумя способами: >> по прямой ссылке (не требуется регистрация пользователя в системе); >> по пользователям и группам (требуется регистрация в системе). Доступ к файлам (либо папкам) добавляется через кнопку значка с тремя точками, соединенными линиями. Для варианта 1 достаточно поставить флажок Make public, и вы получите ссылку, при открытии которой в компьютер пользователя сразу будет загружен файл. При втором варианте выбираете в списке пользователей и группы из имеющихся в системе ownCloud из выпадающего списка. После этого все добавленные пользователи найдут новые файлы и катаРисунок 2. Работа с календарем (выбор календаря Default calendar)

;Максимальный размер POST-данных, которое сможет получить PHP ;post_max_size = 8M ;Максимальное количество файлов, которые могут быть ;отправлены (upload) на сервер за один запрос max_file_uploads = 20

Не забудьте перезапустить Аpache для применения настроек и «обновить» (<F5>) страницу в веб-браузере при тестировании новых настроек.

Тестирование и настройка ownCloud Попробуйте загрузить, скачать файлы, переименовать, удалять, открыть доступ к файлам (Share), открыть галерею (переиндексировать ее при надобности либо удалить из нее альбом, заметив, что исходная папка с данными остается в разделе «Файлы»). Посмотрите и отредактируйте Календарь, Контакты, при необходимости создав несколько типов Календарей или Контактных книг (в отличие, например, от Microsoft Exchange, в котором каждый поль-

системный администратор март 2012

39

Администрирование логи в закладке Файлы-Shared, где он может изменять их названия и удалять (у владельца исходного файла эти данные остаются в первоначальном виде). Загружать новые файлы напрямую в папку Shared нельзя. Получается, чтобы исправить файл из папки Shared, нам необходимо его скачать, отредактировать на компьютере, закачать назад в ownСloud и выполнить функцию Share. Возможно, в следующей версии ownCloud будет исправлена ошибка о невозможности редактирования файла, на который нам дали доступ. Регистрация и управление пользователями и группами производится администратором по нажатию на значок шестеренки, слева внизу страницы ( «Настройки») и в закладке «Пользователи». Здесь же задаются квоты (ограничения размера хранимых данных в системе у данного пользователя в Mб). Наверное, читателей интересует, каким же образом работает веб-доступ ownCloud на планшетах? iPad2. Не смог отобразить галерею (была только кнопка «пересканировать коллекцию», нажатие на которую ни к чему не приводило). Также не была доступна кнопка «загрузить файлы в облако» (Upload), т.к. Apple не позволяет получать доступ к внутренней файловой системе своих устройств. В остальном при веб-доступе в ownCloud структура каталогов и файлы отображались правильно, и при скачивании их из облака iPad даже предлагает варианты программ, с помощью которых можно открывать их (если такие варианты имелись). Ежедневник работал некорректно – не всегда сохранялись даты либо они смещались при сохранении. Веб-интерфейс не всегда производил корректное обновление (Refresh) страниц. Тестирование в Google Android 3.1 показало лучшую работоспособность: выполнялись все функции, кроме воспроизведения музыки. Закладка Музыка в ownCloud заиграла только на стационарном компьютере (при воспроизведении используется Adobe Flash-модуль). Использовать ownCloud в качестве музыкальной коллекции пока еще не получится. Будем надеяться, что в новой версии это будет исправлено. При тестировании обратите внимание, где сохраняются данные ownCloud. Они сохраняются на самом сервере, где произведена установка, а именно в папке data/имя_ пользователя, и, когда раздаются разрешения на доступ к этим файлам для других пользователей, информация излишне не копируется на жестком диске (вся информация о ссылках к исходным файлам сохраняется в базе данных Рисунок 3. Отображение галереи в планшете у другого пользователя под Android

облачные технологии MySQL). Резервные копии базы данных, возможно, создаются в закладке «Настройки → Администратор → Export this ownCloud instance», где необходимо отметить флажком нужные варианты: пользовательские данные, системные файлы ownCloud, конфигурация ownCloud.

Подключаемся к WebDAV Пора получить наш заветный пряник – подключиться к хранилищу и работать с файлами, как с локальным компьютером. http://owncloud.org/support/webdav. Сначала нужно узнать ссылку на WebDAV. Для этого в браузере при просмотре хранилища необходимо нажать на значок шестеренки (внизу страницы слева) и выбрать закладку Личное. В ней будет отображен адрес для доступа к WebDAV, например: http://192.168.0.100/owncloud/files/ webdav.php. Теперь настроим подключение клиентов на клиентских ПК.

Настройка подключения в Windows XP Добавляем подключение через открытие «Мой компьютер → Сетевое окружение → Добавить новый элемент в сетевое окружение». В строке «Сетевой адрес или адрес в Интернете:» вводим ссылку на WebDAV http://192.168.0.100/owncloud/files/ webdav.php, отвечаем на запрос «Пользователь» и «Пароль» (ставим галочку – «Сохранить пароль», если хотим, чтобы система не спрашивала пароль) и нажимаем ОК.

Настройка в Windows 7 Должна быть запущена сетевая служба «Веб-клиент (WebClient)», тип запуска «Автоматически». Обычно она по умолчанию включена. Разработчики ownCloud на данной станице рекомендуют исправить ветку реестра [9]: HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\WebClient\Parameters\ BasicAuthLevel с значения 1 на 2. Но тестирование показало, что ownCloud работает через сеть только при значении 3! Возможно, к моменту публикации данная ошибка на сайте уже будет исправлена. Для применения настроек перезапустите службу WebClient либо через командную строку: > sc stop WebClient > sc start WebClient

Подключаем диск WebDAV: «Мой компьютер → Подключить диск → Использовать другие учетные данные» и нажимаем «Готово».

Linux – использование через FUSE Чтобы подключить WebDAV через FUSE, необходимо установить модуль davfs2: В Fedora: #yum install davfs

Настройки подключения можно сохранить в файле /etc/ davfs2/secrets в виде: http://ip_adres/owncloud/files/webdav.php user password

40

март 2012 системный администратор

облачные технологии

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

Cоздаем каталог для монтирования WebDAV, в приведенном примере это /mnt/davfs. И монтируем его командой:

Перезапускаем Apache и попробуем открыть ownCloud в браузере с помощью https://ip_адрес/owncloud.

#mount -t davfs http://ip_adres/owncloud/files/webdav.php ↵

/mnt/davfs -o rw

*** С сервисом ownCloud я уверен, что мои данные не попадут в третьи руки (за исключением целенаправленного взлома, от которого, пожалуй, никто не может быть застрахован), а также в том, что я смогу их корректно удалить и они не будут доступны по старым ссылкам.con Поддержка протокола WebDAV помогает настроить доступ к хранилищу как к сетевому диску, облегчая загрузку, изменение и сохранение для любых типов данных. Также у нас отсутствуют ограничения количества файлов и их объема, но при желании мы можем включить и поддержку квот! Настройка доступа к файлам, каталогам, календарь, закладки, просмотр графических файлов в галерее, просмотр PDF и редактирование текстовых файлов прямо в браузере без установки стороннего ПО выглядят как существенное преимущество перед остальными облачными сервисами. Завершаю статью девизом разработчиков описанного сервиса: «ownCloud – это сетевые службы под вашим контролем». EOF

В Интернете достаточно примеров настроек для монтирования WebDAV от имени обычного пользователя с использованием локальных настроек .davfs2/secret. Поскольку ownCloud создавалась разработчиками KDE, следовательно, можно подключить нашу папку с помощью программы Dolphin. Также многие браузеры и другие диспетчеры файлов в Linux могут поддерживать данный протокол: достаточно в адресной строке набрать webdav://.

Включаем шифрование при работе с ownCloud По умолчанию Apache собран с поддержкой SSL, и, значит, имеется возможность использовать шифрованное соединение при подключении к WebDAV. Для этого нам понадобится сгенерировать свой «самоподписанный» сертификат с помощью следующих нескольких команд в Linux: # openssl genrsa -out ca.key 1024 # openssl req -new -key ca.key -out ca.csr # openssl x509 -req -days 365 -in ca.csr ↵

-signkey ca.key -out ca.crt

Перемещение полученных файлов в правильные места: # mv ca.crt /etc/pki/tls/certs # mv ca.key /etc/pki/tls/private/ca.key # mv ca.csr /etc/pki/tls/private/ca.csr

Укажем расположение сертификата в настройках вебсервера /etc/httpd/conf.d/ssl.conf: SSLCertificateFile /etc/pki/tls/certs/ca.crt SSLCertificateKeyFile /etc/pki/tls/private/ca.key

В Windows 7 сертификат можно получить с помощью запуска файла C:\xampp\apache\makecert.bat.

1. Официальный сайт OwnCloud – http://owncloud.com.

2. Системные требования ownCloud – http://owncloud.org/support/ setup-and-installation/requirements.

3. Cайт XAMPP (кроссплатформенный LAMP) – http://www. apachefriends.org/ru/xampp.html.

4. Архиватор – http://www.7-zip.org.

5. Предустановленное окружение ownCloud на OpenSUSE – http://susestudio.com/a/TadMax/owncloud-in-a-box.

6. Предустановленное окружение ownCloud на Ubuntu – http:// cloud.ubuntu.com/2012/01/ownCloud-now-easily-deployable-onubuntu/.

7. Описание процесса установки в UNIX, Linux, BSD – http:// owncloud.org/support/setup-and-installation/linux-server.

8. Php-zip модуль Аpache для Red Hat, CentOS – https://admin. fedoraproject.org/pkgdb/acls/name/php-pecl-zip.

9. Настройка WebDAV – http://owncloud.org/support/webdav.

Рисунок 4. Подключение WebDAV в Windows 7 и копирование данных

системный администратор март 2012

41

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

исследование

Визитка

w, специализируется на экспертизе аппаратных и программных решений

Добро пожаловать на планету AIX Для работы аппаратного обеспечения требуется его программная составляющая. И если для массового x86-рынка количество операционных систем насчитывает более двух дюжин, то для корпоративных гигантов их, как правило, не более двух

Краткий экскурс в историю Если смотреть на развитие различных ОС в ретроспективе, то можно заметить, что каждая фирма, которая «вдыхала» жизнь в свои аппаратные изделия, создавала к ним в довесок и программный код. Что вполне логично – кто, кроме самого производителя, лучше знает всю внутреннюю архитектуру? Так появляется ОС VAX/VMS [1] для работы на мини-ЭВМ семейства VAX-11. Оба компонента создавались и поддерживались одной фирмой – Digital. Спустя несколько лет аналогичным путем последовала компания Sun Microsystems, выпускавшая как собственные процессоры SPARC, так и ОС Solaris (в то время SunOS). Примерно в то же время компания Hewlett-Packard решила попробовать свои силы в дизайне процессоров PA-RISC, для которых, очевидно, тоже нужна была ОС – HP-UX. Такой же мотив толкает и IBM на создание серверов на базе Power/PowerPC и AIX в качестве программной компоненты. В отличие от сильной вертикально-ориентированной интеграции существовали и совместные творческие коллективы, когда один гигант выпускает только процессорную часть, а все остальное, включая аппаратный стенд и программное обеспечение к нему, ведет уже конечный производитель. Так, ярким примером кооперации служил тандем MIPS и Silicon Graphics. Первый производил процессоры MIPS, а вторая компания занималась сборкой рабочих станций и мейнфреймов, а заодно и ОС IRIX. Другой яркий пример – сотрудничество Apple Computer и Motorola, когда «яблочная» компания выпускала A/UX и System (последняя последовательно трансформировалась в Classic MacOS и затем в MacOSX) и весь свой аппаратный спектр, а Motorola отвечала за процессоры линейки 680x0 (известной так же, как семейство «68K»). И хотя Apple уже раз в четвертый меняет своего процессорного производителя, напомню, что, помимо Motorola 68K, использовались также и процессоры MOS Technology (в Apple II) и PowerPC (в MacMini/Xserve), прежде чем остановились на Intel – для своего мобильного сегмента Apple использует как раз правило вертикальной интеграции. Имен-

42

но в iPod/iPhone/iPad используются «свой» процессор A4/A5 и своя программная начинка. Помимо вертикальных бизнес-отношений, когда вполне можно определить, кто отвечает за ту или иную часть развития, на рынке существует и другая модель – открытой архитектуры. Она была предложена компанией IBM с появлением концепции IBM Personal Computer, или просто IBM PC, в самом начале 80-х. Проектирование такой аппаратной архитектуры предполагалось выполнить на базе собственного CPU – IBM 801 [3], но наличие множества альтернативных игроков на потребительском рынке бытовых, т.е. домашних, компьютеров потребовало задействовать Intel 8088. В итоге появилось детище – IBM Personal Computer model 5150. Так как архитектура была открытой, каждый производитель мог по этим же лекалам создать свою собственную линейку IBM PC-совместимых компьютеров. Это послужило толчком к взрывному росту предложений, в первую очередь за счет тайваньских мощностей. Многие могут припомнить, что были широко распространены такие понятия, как «белая сборка», «желтая сборка» и даже «красная». Хотя такие исторические параллели иногда приводить довольно бессмысленно в мире индивидуумов, которые путают Pentium 4 и 80x486 и называют первую модель «четверкой». Но мы ведь относим себя к грамотным специалистам, не так ли? Подобная успешность в итоге привела к тому, что сама IBM уже через десятилетие не играла никакой роли в сегменте домашних ЭВМ. Да к тому же монополию на рынке захватила связка Wintel – взаимодействие двух корпораций: Microsoft и Intel. Первая выпускала ОС для всего этого сонма персоналок, а вторая готовила как процессоры, так и системную логику. И все шло гладко, пока не появилась еще одна концепция – открытой ОС. В первую очередь на ум приходит GNU/Linux, но это не совсем полное перечисление, т.к. не охватывает ряда таких ОС, как FreeBSD/OpenBSD/NetBSD, да и других, доступных, правда, больше для архитектуры x86.

март 2012 системный администратор

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

исследование И вот здесь происходит интересная трансформация уже внутри самой IBM. Видя, насколько успешно пошла коммерциализация платформы IBM PC на базе вычислительных компонентов Intel, сама компания – инициатор открытой платформы решается возобновить разработку RISC-процессора IBM 801, а заодно и рабочих станций на его базе. В итоге к 1986 году появляется серия станций 6150 на базе процессора ROMP – дальнейшая разработка оригинального 801-го, который рассматривался как основной в концепции IBM PC пять лет до этого. В качестве ОС выступила портированная под IBM 6150 UNIX System V, названная как AIX Version 1, работы по которой выполнила калифорнийская Interactive Systems Corporation. Она уже имела до этого опыт переноса системы UNIX на разные платформы, в частности, на PDP-11 и VAX, а также на IBM PC в 1984-м (по контракту с той же IBM). Порт для последней платформы назывался как PC/ IX. Потому неудивительно, что была выбрана именно эта фирма. Удивительно, но история с рынком персональных ЭВМ повторилась и на этот раз – цена персоналок IBM достигала $20 000 и была не по карману большей части покупателей. Ими в основном выступали корпоративные заказчики, такие как учебные заведения и… различные подразделения IBM. Плачевный результат ждал бы и AIX, но было принято решение использовать ее и на ряде «больших» машин типа VM/370. Хоть до этого и были уже попытки оснащать мейнфреймы «своим» UNIX, но каждый раз они выпадали из серии. Так, выпали из серии TSS/370, созданная в сотрудничестве с AT&T, и VM/IX, над которой потрудилась уже упомянутая ранее Interactive. Похоже, что такое расточительство сыграло свою роль, т.к. компания IBM все-таки

решила серьезно подойти к делу, а не бросать на полпути затраченные усилия. В итоге AIX увидела и версию 2.0, и 3.0. И постепенно достигла отметки 7.1 – это основная ОС для всей линейки продуктов, выпускаемых сегодня «Big Blue». Вторая трансформация, которая приключилась с IBM, произошла после охлаждения отношений с компанией Microsoft из‑за совместной разработки OS/2 для настольных персональных ЭВМ типа PS/2. Хотя объективности ради нужно отметить, что OS/2 использовалась и в серверном варианте. Как бы там ни было, но разрыв отношений привел к тому, что корпорация начала вкладывать серьезные ресурсы в открытую ОС Linux уже в 1998 году, организовав Linux Technology Center. Поэтому не стоит удивляться, что Linux, во-первых, так популярна в качестве серверной платформы; во-вторых, настолько распространена, как сейчас. И, в-третьих, она запускается на почти всем high-end и midrange серверном оборудовании IBM, поэтому и стала второй полноценной ОС после AIX. Впрочем, пора закончить экскурс в историю и взглянуть на работу в AIX. Официально аббревиатура AIX расшифровывается как Advanced Interactive Executive. Но те, кто работал на других вариантах UNIX и Linux, частенько шутят, что более правильно расшифровывать как «Ain't UNIX». Последняя версия названия будет очень близка к истине, т.к. столько «накрутить» могли только в очень большой компании. Но об этом чуть позже.

Рисунок 1. Внешний вид настольной системы

Таблица 1. Технические характеристики IBM IntelliStation 9111-285

Конфигурация иследуемой станиции Итак, сегодняшние мероприятия будем выполнять на обычной модели IBM IntelliStation Power 285 [10, 11], относящейся к классу настольных. Такое разделение чисто условное,

Корпус

Настольное исполнение

Процессор

Один или два POWER5+, 64-bit@1.9/2.1 GHz

Кэш

1.9MB L2 и 36MB L3

ОЗУ

От 1GB до 32GB DDR2 SDRAM @ 528 MHz

Слоты расширения

Шесть PCI-X (2 - 66 MHz; 3 - 133 MHz; 1 - 266 MHz (DDR))

Дисковые отсеки

Четыре отсека с горячей заменой, с максимальным объемом 1.2TB storage

Дисковые

Двойной SCSI-контроллер Ultra320 (внутренний;

контроллеры

RAID опционально)

Сеть

Двойной Ethernet контроллер 10/100/1000 Mbps

Порты

Два USB, два HMC, два системных

Дополнительные

Два тонких и один половинной высоты

отсеки Графический

3D-графика на основе GXT4500P или GXT6500P

контроллер Устройства 3D-ввода

SpaceBall, SpaceMouse и SpacePilot

Операционная

AIX V5.2-V7.1, IBM i 7.1, Red Hat/SuSE Linux

система

системный администратор март 2012

43

Администрирование т.к. мощности подобных моделей зачастую сравнимы с серверами на базе x86. Будучи выпущены на рынок в 2005 году, такие модели все еще работают в индустрии и не утеряли актуальности до сих пор. В качестве центрального процессора выступает двухядерный Power5+, работающий на частоте 1,9 или 2,1 GHz. Технология RISC, что лежит в основе Power, была заложена еще в начале 1970-х, а дальнейший толчок получила в виде эволюции уже упоминавшегося IBM 801. В частности, это можно заметить даже по самому названию Power – Performance Optimization With Enhanced RISC. В начале 1990-х годов IBM организовала альянс AIM (Apple/IBM/ Motorola) для совместной дальнейшей разработки Powerпроцессоров в потребительском секторе. В итоге получилась процессорная серия PowerPC (Power Performance Computing), которая нашла применение в про-

исследование дукции Apple. И в это же самое время IBM самостоятельно продолжала вести проект Power, который был объединен с наработками PowerPC в конце 90-х. Смело можно утверждать, что процессор Power3 – это самый настоящий 64-битный PowerPC. В 2004-м был представлен Power5, а немного позже его расширенная версия – Power5+. На одном кристалле расположено два процессора, которые делят кэш L2/L3 между собой. Существует возможность блокировки одного из процессоров, что в итоге приводит к монопольному использованию внешних кэшей, а это уже более чем 32 Мб. Согласитесь, солидный объем для обработки данных микропроцессором. На схеме (см. рис. 2) вы видите, что принципиально аппаратура очень напоминает архитектуру привычной x86машины.

Рисунок 2. Схематическая карта аппаратного обеспечения

44

март 2012 системный администратор

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

исследование Есть микропроцессор, который через шину памяти обращается к планкам памяти DDR2. Также центральный узел обращается к расширенному контроллеру ввода/вывода, который в свою очередь уже обращается к PCI-X-устройствам и к SCSI/IDE-накопителям. В отличие от x86-систем есть пара дополнительных узлов и функций. Например, в контроллер памяти интегрирована система ChipKill, которая позволяет на ходу отключать сбойный участок памяти. Также в системе присутствует Service Processor – «неспящий» резидент, который обслуживает HMC (Hardware Management Console) – систему управления аппаратурой на низком уровне. В ней хранятся настройки, необходимые как для старта самой системы, так и настройки для LPAR (Logical Partition) – компонента аппаратной виртуализации в устройствах IBM. Нас же пока такие специализированные вещи не должны волновать – попробуем включить систему и осмотреться по месту. Итак, нажимаем на панели кнопку «старт», через несколько минут система пройдет самотестирование и загрузит ОС AIX. Небольшая справка: ОС AIX работает только на родном «железе» от компании IBM, поэтому пытаться запускать ее в эмуляции нет никакого смысла. Она поставляется вместе с аппаратурой либо заказывается почтой в виде CD/ DVD через службу поддержки. Есть также возможность загрузить образы самостоятельно через подраздел корпоративного сайта FixCentral – http://www-933.ibm.com/support/ fixcentral. Зайдем и посмотрим на компоненты изнутри: Листинг 1. Подключение к системе происходит по старому доброму протоколу telnet

Листинг 2. Вывод информации о системе и дисковым разделам # uname -a AIX rs6000 1 7 00CABB304C00 [root@rs6000] /

# mount node

mounted

mounted over

-------- ---------------

vfs

date

options

---------------

------ ------------ ---------------

/dev/hd4

/

jfs2

Nov 06 10:26 rw,log=/dev/hd8

/dev/hd2

/usr

jfs2

Nov 06 10:26 rw,log=/dev/hd8

/dev/hd9var

/var

jfs2

Nov 06 10:26 rw,log=/dev/hd8

/dev/hd3

/tmp

jfs2

Nov 06 10:26 rw,log=/dev/hd8

/dev/fwdump

/var/adm/ras/platform jfs2

/dev/hd1

/home

jfs2

Nov 06 10:26 rw,log=/dev/hd8

/dev/hd11admin

/admin

jfs2

Nov 06 10:26 rw,log=/dev/hd8

/proc

/proc

procfs Nov 06 10:26 rw

/dev/hd10opt

/opt

jfs2

/dev/livedump

/var/adm/ras/livedump jfs2

Nov 06 10:26 rw,log=/dev/hd8

Nov 06 10:26 rw,log=/dev/hd8 Nov 06 10:26 rw,log=/dev/hd8

Действительно, AIX 7.1! Мы также получили карту разделов, т.е. узнали как именно разбита дисковая подсистема. В целом команды пока стандартны, что для UNIX/Linux, что для AIX. Обращу только внимание, что используется журналируемая система JFS2 – концепция файловой журнализации была впервые сформулирована и реализована именно в продуктах IBM – в виде JFS1 для AIX 3.1. Попробуем узнать теперь, какие сетевые интерфейсы настроены в системе и как выглядит таблица машрутизации. Листинг 3. Таблица маршрутизации и настройка сетевых карт доступна через команды netstat/ifconfig # netstat -rn Routing tables Destination

Gateway

Flags

Refs

Use

If

Exp

Groups

anthony@laptop:~> telnet 192.168.0.200 Route Tree for Protocol Family 2 (Internet): Trying 192.168.0.200...

127/8

127.0.0.1

U

13

2619 lo0

-

-

Connected to 192.168.0.200.

192.168.0.0

192.168.0.200

UHSb

0

0 en0

-

-

Escape character is '^]'.

192.168.0/24

192.168.0.200

U

3

1617 en0

-

-

192.168.0.200

127.0.0.1

UGHS

0

70 lo0

-

-

192.168.0.255

192.168.0.200

UHSb

2

28 en0

-

-

15 lo0

-

-

telnet (rs6000)

=>

AIX Version 7 Copyright IBM Corporation, 1982, 2010.

Route Tree for Protocol Family 24 (Internet v6):

login: root

::1%1

root's Password:

[root@rs6000] /

*********************************************************** *

::1%1

UH

2

# ifconfig -a

* en0: flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,

*

64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>

* *

Welcome to AIX Version 7.1

inet 192.168.0.200 netmask 0xffffff00 broadcast 192.168.0.255 tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0

* *

lo0: flags=e08084b,c0<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,

*

64BIT,LARGESEND,CHAIN>

*

inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255

*

inet6 ::1%1/0

***********************************************************

tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

Last unsuccessful login: Mon Oct 31 18:01:27 DFT 2011 on /dev/pts/2 from 192.168.0.222 Last login: Sun Nov

6 10:47:46 NFT 2011 on /dev/pts/0 from 192.168.0.194

[root@rs6000] /

Первым шагом становится желание узнать версию системы, что выдается командой uname. Убедимся, что система именно AIX, а не то, что показывается нам по выводу /etc/ motd (см. листинг 1).

системный администратор март 2012

Хорошо, мы видим – на первый взгляд система работает. Как проверить этап старта и те сообщения, что были сгенерированы ядром, ведь привычной команды dmesg здесь нет? В качестве ее замены нужно запускать alog с нужными уровнями детализации: boot, bosinst, nim, console, cfg, mdmplog, lvmt, lvmcfg, dumpsymp. Узнать о доступных уровнях можно, запустив команду: alog -L:

45

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

исследование

Листинг 4. Проверка системных сообщений при старте AIX

vsa1

# alog -t boot -o

U787F.001.DPM4MY8-P1-T2

LPAR Virtual Serial Adapter

Hardware Location Code......U787F.001.DPM4MY8-P1-T2

________________________________________________________ vty1

U787F.001.DPM4MY8-P1-T2-L0

Asynchronous Terminal

vsa0

U787F.001.DPM4MY8-P1-T1

LPAR Virtual Serial Adapter

rc.boot: starting disk boot process rc.boot: executing "restbase" rc.boot: executing "cfgmgr -f -v"

Hardware Location Code......U787F.001.DPM4MY8-P1-T1

rc.boot: boot device is hdisk0 rc.boot: executing "ipl_varyon -v"

vty0

U787F.001.DPM4MY8-P1-T1-L0

Asynchronous Terminal

rc.boot: executing "fsck -fp /"

pci2

U787F.001.DPM4MY8-P1

PCI Bus

J2_LOGREDO:log redo processing for /dev/hd4 The current volume is: /dev/hd4 Primary superblock is valid.

Primary superblock is valid. ...

The current volume is: /dev/hd1 Primary superblock is valid.

The current volume is: /dev/hd10opt Primary superblock is valid.

Performing all automatic mounts Multi-user initialization completed

И если по типу boot сортируются сообщения от сервисов, что активировались при старте, то по типу console/cfg/ lvmcfg мы можем увидеть, что происходило дальше на мультипользовательском уровне. Например, на уровне cfg можно отследить, какие запускались команды реконфигурирования системы. С описанием устройств, что присутствуют на данном аппаратном объекте, нам поможет команда lscfg. В определенной степени она – аналог lspci, но «пробегает» по всему спектру внутренних компонентов.

Вроде бы ничего не утащили, сверьтесь со своей описью оборудования. Попробуем теперь кратко разобрать, как представлена файловая система, раскладку которой мы уже видели чуть раньше. Каждый раздел – это логический том в пуле rootvg. Такой подход позволяет производить операции по изменению размера тома в горячем режиме, что называется, на ходу. Мелочь, но стратегически правильная. Чтобы посмотреть файловую систему, запускаем lsvg – получили список групп томов (volume group). И после этого производим детализацию для нужной группы. Листинг 6. Файловая система фактически представлена в виде LVM-томов # lsvg -l rootvg rootvg: LV NAME

TYPE

LPs

PPs

PVs

LV STATE

MOUNT POINT

hd5

boot

1

1

1

closed/syncd

N/A

hd6

paging

2

2

1

open/syncd

N/A

hd8

jfs2log

1

1

1

open/syncd

N/A

hd4

jfs2

1

1

1

open/syncd

/

hd2

jfs2

8

8

1

open/syncd

/usr

hd9var

jfs2

2

2

1

open/syncd

/var

hd3

jfs2

1

1

1

open/syncd

/tmp

hd1

jfs2

1

1

1

open/syncd

/home

hd10opt

jfs2

2

2

1

open/syncd

/opt

hd11admin

jfs2

1

1

1

open/syncd

/admin

INSTALLED RESOURCE LIST WITH VPD

livedump

jfs2

1

1

1

open/syncd

/var/adm/ras/livedump

The following resources are installed on your machine.

fwdump

jfs2

1

1

1

open/syncd

/var/adm/ras/platform

Листинг 5. Проверка системных сообщений при старте AIX # lscfg -vp

# cat /etc/filesystems

Model Architecture: chrp Model Implementation: Multiple Processor, PCI bus

/: sys0

System Object

dev

= /dev/hd4

sysplanar0

System Planar

vfs

= jfs2

vio0

Virtual I/O Bus

log

= /dev/hd8

mount

= automatic

check

= false

type

= bootfs

vol

= root

free

= true

quota

= no

dev

= /dev/hd1

vfs

= jfs2

log

= /dev/hd8

mount

= true

check

= true

vol

= /home

free

= false

quota

= no

Рисунок 3. Уникальный инструмент для оценки текущей загрузки системы – topas

/home:

В дополнение посмотрим на раскладку, которая задается в файле /etc/filesystems – аналоге /etc/fstab. По сравнению с тем же Linux описание похоже, но более информативно. Так же как и в других UNIX-системах, в AIX есть и работают сервисы. Чтобы получить информацию обо всех зарегистрированных сервисах, нужно запустить команду lssrc -a. После этого при необходимости запустить или остановить какую-либо службу командами startsrc/stopsrc.

46

март 2012 системный администратор

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

исследование Листинг 7. Запуск определенного сервиса # startsrc -s nfsd 0513-059 The nfsd Subsystem has been started. Subsystem PID is 6029560. [root@rs6000] /tmp

# lssrc -a | grep nfs biod

nfs

5636308

active

rpc.statd

nfs

3932314

active

rpc.lockd

nfs

6291650

active

nfsd

nfs

6029560

active

rpc.mountd

nfs

inoperative

nfsrgyd

nfs

inoperative

gssd

nfs

inoperative

Одной из часто используемых команд является, конечно же, top. В AIX она реализована в виде агрегатора topas. В нем можно посмотреть не только, сколько памяти и ресурсов процессора затрачивается на данный момент, но и статистику по трафику через сетевые интерфейсы, насколько интенсивно идет запись/чтение с дисковых носителей и т.п. Будучи запущенным, topas показывает общую статистику. Для получения детализированной информации, нажмите на «h» (встроенная справка) и выберите раздел ресурсов, на который вам хочется взглянуть прицельно. И, конечно, не забудем про еще одну агрегаторную утилиту SMIT (System Management Interface Tool). На самом деле она является краеугольным инструментом при конфигурировании всей AIX-системы, т.к. умеет вызывать сонм нужных низкоуровневых утилит с нужными параметрами и вносить соответствующие изменения в требуемые файлы. В итоге если вы даже и не помните название той или иной конфигурационной утилиты, то, следуя по рубрикам в самом SMIT, сможете провести необходимые изменения.

*** Когда вы слышите, что система UNIX – целая вселенная, знайте – это действительно так. И если профессионалам, работающим, например, с Linux, их родная стихия будет все-таки казаться вселенной, то, только пересев на промышленные версии UNIX, приходит осознание того, какой же это на самом деле айсберг – большая часть скрыта под водой. Однако надеюсь, что такой краткий экскурс в AIX позволит вам не только представить истинные масштабы, но и составить мнение об AIX в целом. Ведь каким бы большим ни был этот монстр, но именно на нем, как ни странно, обкатываются все передовые технологии, которые потом появляются в UNIX-индустрии, да и в Linux тоже. Более подробно об AIX расскажем в одном из следующих номеров журнала. EOF 1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

http://en.wikipedia.org/wiki/VAX. http://en.wikipedia.org/wiki/IBM_Personal_Computer. http://en.wikipedia.org/wiki/IBM_801. http://en.wikipedia.org/wiki/IBM_6150_RT. http://en.wikipedia.org/wiki/ROMP. http://en.wikipedia.org/wiki/INTERACTIVE_Systems_Corporation. http://en.wikipedia.org/wiki/AIX_operating_system. http://en.wikipedia.org/wiki/Linux_Technology_Center. http://www-03.ibm.com/linux/ltc. http://www-03.ibm.com/systems/intellistation/power/hardware/285/ index.html. http://en.wikipedia.org/wiki/IBM_IntelliStation. http://www.redbooks.ibm.com/abstracts/redp4078.html. http://en.wikipedia.org/wiki/PowerPC. http://users.cis.fiu.edu/~tho01/psg/aix.html.

Рисунок 4. Единым центром конфигурирования AIX является SMIT

системный администратор март 2012

47

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

ит для банков

Визитка

Илья Кузьминов, специалист по защите информации

DLP-система DeviceLock в банках Архитектура и развертывание. Часть 1

Программный комплекс DeviceLock Endpoint DLP Suite, разработанный российской компанией «Смарт Лайн Инк», предназначен для управления доступом пользователей ОС семейства Windows к периферийным устройствам хранения и обработки данных, каналам сетевых коммуникаций

Данный цикл статей посвящен описанию неочевидных нюансов, с которыми мы столкнулись при использовании DeviceLock Endpoint DLP Suite в банковской корпоративной среде и которые необходимо учитывать при развертывании и эксплуатации программы в достаточно большом домене. Первая статья цикла описывает особенности архитектуры комплекса и тонкие моменты установки и развертывания DLP-системы DeviceLock Endpoint DLP Suite.

Компоненты Основные компоненты DeviceLock Endpoint DLP Suite: DeviceLock Service (далее – агент), содержит модули DeviceLock, NetworkLock и ContentLock; DeviceLock Enterprise Server (далее – сервер); консоли DeviceLock Management Console, DeviceLock Enterprise Manager, DeviceLock Service Settings Editor, DeviceLock Group Policy Manager, DeviceLock Signing Tool; DeviceLock Content Security Server.

DeviceLock Service – служба на рабочих станциях, которая контролирует доступ к устройствам и каналам сетевых коммуникаций, в том числе с использованием механизмов контентного анализа и фильтрации, ведет лог активности, отправляет лог и теневые копии записанных/прочитанных файлов на сервер. Включает в себя модули DeviceLock, NetworkLock и ContentLock.

DeviceLock Enterprise Server – служба на сервере, которая собирает данные от агентов, фильтрует собранные данные, выводит их в разных представлениях, а также может осуществлять мониторинг целостности настроек агентов и восстановление нарушенных настроек.

DeviceLock Management Console и DeviceLock Enterprise Manager – консоли управления агентом и сервером, выполненные как оснастки MMC; первая из них предназначена для индивидуальной работы с агентами (например, изменение отдельных настроек агента), вторая – для массовой работы (массовая установка, массовая разливка файла настроек, отчет о настройках, массовое удаление).

DeviceLock Content Security Server – компонент, без которого теневое копирование файлов, прочитанных/записанных пользователями с/на внешние устройства, было бы

48

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

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

NetworkLock – компонент DeviceLock Service, позволяющий контролировать содержание сетевой активности или блокировать сетевую активность. Он дает возможность запрещать доступ к определенным сайтам, доступ по определенным протоколам, разрешение IP-адресов в адреса URL. Особый интерес для службы ИБ представляет блокировка активности по различным протоколам уровня приложений, например, блокировка ICQ, Mail Agent, других служб мгновенных сообщений, соцсетей, электронной почты и почтовых веб-сервисов (с раздельным контролем сессий, сообщений и вложений в них) и ряда других сетевых сервисов.

Установка и лицензирование Прежде всего важно отметить, что все три ключевых компонента DLP-системы DeviceLock – базовый модуль DeviceLock, модули NetworkLock и ContentLock – интегрированы как единое целое в агенте DeviceLock и всегда устанавливаются на контролируемые компьютеры, даже если нет соответствующей лицензии на какой-либо из этих компонентов.

Установка из MSI-файла средствами Windows Наиболее простым и эффективным способом развертывания DLP-системы DeviceLock является вариант с использовани-

март 2012 системный администратор

ит для банков ем возможностей групповых политик домена Active Directory, если таковой развернут в инфраструктуре организации. Для установки агента DeviceLock требуется файл DeviceLock Service.msi либо DeviceLock Servicex64.msi, в зависимости от целевой ОС. Устанавливать агенты DeviceLock удобно через применение GPO к доменам/контейнерам/фильтрам. Используемый MSI-файл может быть без установленных настроек (установленный таким способом агент ничего не блокирует, ничего не логирует и не защищен от удаления/изменения из-под любой привилегированной учетной записи), либо со встроенными настройками. MSI-файл со встроенными настройками создается с помощью DeviceLock Service Settings Editor на основе стандартного MSI-файла. Устанавливать «голый» MSI не рекомендуем, поскольку такой агент могут удалить на своих машинах пользователи с привилегированными учетными записями еще до того, как репликацией групповых политик до них «докатятся» настройки.

Установка с помощью консолей управления DeviceLock Если инфраструктура Active Directory не развернута в организации или ее части, для массовой установки агентов DeviceLock придется использовать DeviceLock Enterprise Manager, а установку на единичных машинах проводить через DeviceLock Management Console. Консоли DeviceLock Enterprise Manager и DeviceLock Management Console для установки агентов на удаленные машины используют вышеупомянутые MSI-файлы, а также файлы Remote Installer.exe и InstMsiW.exe; при этом файлы DeviceLock Remote Installer.exe и InstMsiW.exe используются для запуска удаленной установки с вызовом Windows Installer. В DeviceLock Enterprise Manager можно указать путь к файлам в окне InstallOptions, открывающемся из окна ScanNetwork при выборе плагина InstallService и нажатии кнопки Settings. Там же можно задать фиксированный TCPпорт для работы агента. Последнее очень важно: позднее не удастся изменить этот параметр заливкой новых настроек, и потребуется переустанавливать агент. Установка из DeviceLock Enterprise Manager происходит по группе компьютеров, которая может задаваться либо списком из файла (при этом внутри домена достаточно неполных имен), либо выбором компьютеров в домене/организационной единице (OU), либо выбором всех компьютеров определенного типа в домене/OU. Последняя функция удобна, если в организации нет прозрачной практики именования компьютеров в зависимости от типов. Можно задать установку на все рабочие станции домена, избегая установки на серверы. При установке с помощью DeviceLock Enterprise Manager и DeviceLock Management Console эти консоли должны быть запущены под учетной записью, входящей в список локальных администраторов на удаленной машине. Можно запустить их от имени привилегированной учетной записи через пункт RunAs контекстного меню исполняемого файла (или ярлыка) в сессии обычной учетной записи, но, если речь идет о доменной учетной записи, ее нужно будет указывать в полной нотации: DomainName\UserName. Это относится ко всем случаям прямого указания учетных записей в DeviceLock.

Использование файлов лицензий Разработчик предлагает раздельное лицензирование для компонентов DeviceLock, NetworkLock, ContentLock

системный администратор март 2012

Администрирование и DeviceLock Content Security Server и предоставляет соответственно раздельные файлы лицензий для них. Сами файлы лицензий требуются консолями управления DeviceLock, сервером DeviceLock Enterprise Server и компонентом DeviceLock Content Security Server. Записывать файлы лицензий на компьютер, где установлен только агент, не требуется. Количество лицензий определяет то, для скольких машин одновременно можно будет запустить задание через DeviceLock Enterprise Manager или будет «обработано» при развертывании и управлении через групповые политики, и сколько агентов будет обслуживаться сервером DeviceLock. Обратите внимание, что лицензии DeviceLock Content Security Server приобретаются отдельно не по числу машин, а по числу проиндексированных записей логов, поэтому созданный компонентом индекс необходимо время от времени очищать. Иначе DeviceLock Content Security Server может проиндексировать старые данные, «истратив» лицензии, и тогда новые данные индексироваться не будут. Чистить индекс следует, в частности, при удалении файлов из теневого хранилища сервера, иначе может возникнуть ситуация, когда лицензии отнимают записи в индексе, адресующиеся к уже удаленным файлам теневого хранилища. Установка файлов лицензионных ключей *.lic, как правило, не представляет трудностей. Мастер установки запрашивает директорию с лицензионными файлами, вы указываете, он подхватывает. Он понимает загрузку в список сразу нескольких лицензионных файлов, в том числе триальных совместно с нормальными. Если в процессе установки вы не стали указывать лицензии, то не найдете интерфейса для загрузки лицензий в DeviceLock Management Console/ DeviceLock Enterprise Server. Для загрузки вам потребуется просто переместить новый лицензионный файл в установочную директорию DeviceLock, при этом расширение файла должно быть .lic. После запуска консоли файл *.lic будет переименован в *.li_ – это значит, что программа «подхватила» нужный лицензионный файл. При необходимости замены одного файла другим по такой схеме понадобится сначала удалить старый файл из установочной директории и удалить параметр Lic из реестра Hkey_Local_Machine\Software\ SmartLine Vision\DeviceLock. Еще одна хорошая новость – сочетание раздельного лицензирования модулей DeviceLock, NetworkLock, ContentLock с их интегрированностью в единое ядро агента (DeviceLock Service) позволяет службе ИБ организовать поэтапное внедрение DLP-системы. Можно сначала обеспечить базовый контроль доступа пользователей к портам и устройствам с помощью модуля DeviceLock, затем усилить противодействие утечкам данных за счет контроля каналов сетевых коммуникаций в модуле NetworkLock и уже тогда, накопив за время эксплуатации этих компонентов определенный опыт и понимание сценариев утечки данных в условиях конкретной инфраструктуры организации, задействовать возможности технологий контентной фильтрации в модуле ContentLock. Кроме того, это позволяет в условиях сильной загруженности специалистов по ИБ более тщательно спланировать ресурсы, время и бюджет для построения полной DLP-системы. В следующей статье цикла мы рассмотрим особенности сетевого взаимодействия компонентов и механизмы обеспечения собственной безопасности компонентов в DeviceLock Endpoint DLP Suite. ADV

49

Тестирование

виртуальные решения

Визитка

Андрей Горемульта, эксперт по направлению виртуализации и системы хранения данных

VMware vSphere

Оценка производительности дисковой подсистемы ВМ Оценим зависимость производительности дисковой подсистемы виртуальной машины VMware vSphere 5 в зависимости от выбранного типа виртуального SCSI-контроллера

Виртуализация активно развивается в России на протяжении нескольких лет, многие администраторы уже используют или в ближайшее время планируют перевести свои серверы под управление виртуальных машин. Попутно у многих появляются вопросы к архитектуре и специфике различного ПО. В статье хотелось бы рассказать об одной особенности VMware vSphere [1]. В процессе настройки виртуальных систем в VMware vSphere сисадмин сталкивается с выбором различных типов виртуальных контроллеров, большинство не придают этому особого значения. А может, зря? Ведь реализация драйвера, пусть и виртуального, бывает разной. Недаром производитель позволил нам выбирать. Так как главной характеристикой любой системы, в том числе и виртуальной, является производительность, мы попробуем оценить ее для различных типов виртуальных контроллеров. В качестве тестового стенда была выбрана платформа Dell R610: >> 2 процессора Intel Xeon 5620; >> 96 Гб ОЗУ;

>> дисковая подсистема: »» встроенный контроллер Dell PERCH700; »» 2 диска SeagateSATA 250 Гб, сконфигурированных в RAID-1. Эталонная виртуальная машина: >> гостевая ОС – Microsoft Windows Server 2008R2; >> 2 виртуальных CPU; >> 2 Гб ОЗУ; >> 1 виртуальный диск для ОС; >> 1 виртуальный диск для тестирования производительности размером 15 Гб. Для тестирования и создания нагрузки на дисковую подсистему используется программа IOmeter [2]. Для оценки производительности было проведено два теста: >> Тест №1. Только линейное чтение блоками по 4 Кб. >> Тест №2. Отношение чтения к записи 67/33, доля случайного чтения 60%. Замечание: тест №2 является синтетическим тестом, близким к реальной нагрузке на серверы.

Таблица 1. Тест №1 (линейное чтение) Тип виртуального контроллера

Total IO perSecond

Total MB perSecond

Average IOResponseTime

Maximum IO ResponseTime

CPU utilization, %

LSI LogicParallel

11 120

43,44

0,90

785

9,48

LSI Logic SAS

12 600

56,32

0,69

309,88

10,55

Paravirtual SCSI (PVSCSI)

14 215

57,53

0,70

20,41

8,57

CPU utilization, %

Таблица 2. Тест №2 (чтение/запись – 67/33, случайное чтение/линейное чтение 60%/40%) Тип виртуального контроллера

Total IO

Total MB

Average

Maximum IO

perSecond

perSecond

IOResponseTime

ResponseTime

LSI LogicParallel

313

1,23

31,85

1205

0,55

LSI Logic SAS

321

1,26

31,11

554

0,53

Paravirtual

387

1,51

25,47

307

0,50

50

март 2012 системный администратор

виртуальные решения Раcшифровка параметров теста: Total IO perSecond – общее количество операций вводавывода в секунду; Total MB perSecond – скорость дисковых операций в мегабайтах в секунду; Average IO ResponseTime – среднее время отклика на операции ввода-вывода; Maximum IO ResponseTime – максимальное время отклика на операции ввода-вывода; CPU utilization – время использование центрального процессора виртуальной машины на операции вводавывода. Чтобы избежать погрешности в измерении, тест запускался пять раз с каждым видом контроллера. Представленные результаты (см. таблицы 1, 2) являются средними арифметическими, полученными в результате нагрузочного тестирования. Как мы видим из таблицы 1, SCSI-контроллер Paravirtual по общему количеству операций ввода-вывода на линейном чтении дает выигрыш в производительности по сравнению с контроллером LSI Logic Parallel в 21,7% и 11,3% по сравнению с контроллером LSI Logic SAS. Во втором тесте результат практически аналогичен. Из таблицы 2 мы видим, что контроллер VMware PVSCSI дает прирост в производительности на 19,1% и на 17% по сравнению с контроллерами LSI LogicParallel и LSI Logic SAS соответственно.

системный администратор март 2012

Тестирование Контроллер VMware Paravirtual SCSI поддерживается следующими операционными системами: >> Microsoft Windows Server 2008 R2; >> Microsoft Windows Server 2008; >> Microsoft Windows Server 2003; >> Red Hat Linux (RHEL) 5. Если контроллер Paravirtual SCSI поддерживается гостевой ОС, мы рекомендуем использовать его для повышения производительности дисковой подсистемы и снижения нагрузки на процессор виртуальной машины. Данный вид контроллеров для виртуальных жестких дисков лучше подходит для использования на серверах, на которых интенсивно производятся операции чтения, например, на серверах баз данных или почтовых. Его использование позволяет повысить производительность виртуальных машин и уменьшить общую нагрузку на облачную инфраструктуру на базе продуктов VMware, в особенности при использовании SAN. Но, к сожалению, список таких ОС небольшой. В том случае, если Paravirtual SCSI выбрать нельзя, рекомендуем использовать контроллер LSI Logic SAS, который в данный момент поддерживается большинством современных ОС и показывает хорошую производительность. EOF 1. Страница VMware vSphere – http://www.vmware.com/ru/ products/datacenter-virtualization/vsphere.

2. Сайт IOmeter – http://www.iometer.org.

51

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

механизмы защиты

Визитка Леонид Шапиро, архитектор ИТ-систем, преподаватель ЦКО «Специалист» при МГТУ им. Баумана. MVP, MCT, MCSE:S, MCSE:M, MCITP EA, TMS Certified Trainer

Защита данных на ПК с ОС Microsoft

На основе продуктов и решений «Аладдин Р.Д.». Часть 2 Один из важнейших аспектов информационной безопасности – защита данных ограниченного доступа. В этой статье продолжаем рассмотрение механизмов обеспечения конфиденциальности данных, хранимых на рабочих станциях на основе решений «Аладдин Р.Д.»

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

Secret Disk Enterprise, рассматриваемый в предыдущей и настоящей статьях, служит для обеспечения конфиденциальности данных на рабочих станциях пользователей.

Архитектура SDE При разработке продукта была применена многоуровневая схема, что позволило сделать систему масштабируемой, расширяемой, отказоустойчивой. Функционально SDE состоит из клиентской и серверной частей: Серверная часть – Secret Disk Management Server (SDMS), служит для централизованного администрирования и управления клиентами. Клиентская часть – Secret Disk Agent (SDA), устанавливается на рабочие станции пользователей, выполняет команды, полученные от серверной части, отсылает отчеты об их исполнении. Концепция Secret Disk Enterprise (SDE) заключается в централизованном хранении и управлении ключами шифрования дисков, информацией о пользователях, особенностями их работы с дисками и так далее. Все операции в SDE основаны на взаимодействии между клиентской частью и серверными компонентами системы. Secret Disk Enterprise построен на многозвенной архитектуре. Серверная часть (SDMS) включает основные компоненты: >> сервер бизнес-логики; >> шлюз клиентов; >> административный веб-портал; >> сервер БД.

52

Давайте рассмотрим схему на рисунке 1. Сервер бизнес-логики обеспечивает проведение работ с зашифрованными дисками, сертификатами пользователей, управление учетными записями пользователей, лицензиями, компьютерами, выполнение сервисных функций. Он формирует для каждой рабочей станции очередь команд. Обращение к клиентской части напрямую не допускается, поэтому все взаимодействие инициирует Secret Disk Agent через шлюз клиентов. Шлюз клиентов выполняет аутентификацию и перенаправляет запросы Secret Disk Agent серверу бизнес-логики. При взаимодействии клиентской и серверной частей SDE происходит обмен ключами, получение клиентским программным обеспечением команд сервера и некоторой служебной информацией. Конфиденциальная информация пользователей хранится на зашифрованных дисках рабочих станций. Для зашифрования/расшифрования информации на диске используется криптокопия ключа этого диска, зашифрованная с использованием мастер-ключа базы данных. В базе данных хранятся криптокопии мастер-ключа базы данных, поэтому, чтобы получить мастер-ключ для работы с дисками, необходимо расшифровать его криптокопию. Для этого используется мастер первоначальной настройки. Сама операция называется «подключение криптохранилища». Мастер первоначальной настройки также используется при установке программного обеспечения SDMS. Доступ к этому приложению имеет только пользователь в роли оператора. Административный веб-портал, по сути, представляет собой графический интерфейс для управления учетными записями пользователей, сертификатами, шифрованными дисками, получения информации о настройках системы SDE. Доступ к нему могут получить только администратор ИБ, оператор и аудитор, разумеется, с ограничениями, определенными их ролями. База данных SQL. Вся информация, которой оперирует система SDMS, хранится в базе данных на сервере под уп-

март 2012 системный администратор

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

механизмы защиты равлением Microsoft SQL Server 2005/2008. Там же хранятся сведения о файловой системе для каждого клиентского компьютера, операциях пользователя, а также сертификаты и симметричные ключи ко всем зашифрованным дискам. Ключи к зашифрованным дискам клиентов зашифрованы на мастер-ключе, который хранится на USB-ключе или смарт-карте eToken оператора.

SQL-база данных заимствует уже существующие сведения о сотрудниках организации из службы Active Directory (AD): их роли, сертификаты, криптокопии мастер-ключей, конфигурации рабочих станций. Доступ к Active Directory осуществляется только в режиме чтения, следовательно, никто из пользователей SDMS не может вносить изменения в AD. С клиентской частью все намного проще. Она представлена единственным компонентом – ПО Secret Disk Agent, выполняющимся на рабочих станциях пользователей.

Secret Disk Agent устанавливается на каждом клиентском компьютере и выполняет полученные от сервера бизнеслогики команды. Их выполнение осуществляется автоматически без участия пользователя. По запросу пользователя могут быть выполнены только две операции: подключить и отключить диск с зашифрованной информацией.

Варианты развертывания SDE Существует три основных сценария развертывания SDE, и у каждого есть свои особенности: >> Хост-установка – установка всех компонентов SDMS на один сервер. >> Установка с выделенным сервером БД. >> Установка с разделением ролей (сервер бизнеслогики, шлюз клиентов, административный веб-портал, сервер БД устанавливаются на разные серверы).

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

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

Разделение ролей

Этот метод предусматривает размещение всех компонентов и совмещение ролей в рамках единственного сервера. Данный сценарий рекомендуется для ознакомления с возможностями продукта, выполнения пилотных проектов и внедрений до 100 рабочих мест. Количество в 100 рабочих мест указывается производителем ПО. Результаты нагрузочного

Отдельно разворачивается административный веб-портал, сервер бизнес-логики и сервер БД (см. рис. 2). В этом случае появляются возможности по дальнейшему развитию с точки зрения повышения отказоустойчивости и доступности. Например, может быть выполнена кластеризация сервера БД на основе стандартных средств Microsoft. То есть речь идет о внедрении Failover Cluster. Что касается вебпортала, то для повышения отказоустойчивости и доступности стандартными средствами может быть организован NLB-кластер. Для сервера бизнес-логики пока предлагается вариант с использованием технологии stand by. В таком случае устанавливаются две одинаковые копии SDMS на два идентичных сервера, причем одна копия сервера рабочая,

Рисунок 1. Схема концепции Secret Disk Enterprise

Рисунок 2. Распределение ролей

Хост-установка

системный администратор март 2012

53

Безопасность другая в выключенном состоянии, обе настроены на одну базу данных. Если рабочий сервер выходит из строя, то резервный может быть запущен и заменит исходный. Нетрудно заметить, что, с точки зрения дальнейшего развития, установка с разделением ролей – наиболее удачный вариант. Именно он дает возможность с ростом потребностей компании адаптировать решение по защите данных на рабочих станциях клиентов. Кстати, в следующей версии SDE сервер бизнес-логики будет поддерживать технологию балансировки нагрузки Microsoft NLB.

Особенности системы Давайте рассмотрим особенности нашей построенной системы.

Централизованное управление В рамках SDE внедрена схема централизованного управления, посредством которой решаются следующие задачи: >> Настройка и изменение настроек клиентского ПО на рабочих станциях. >> Создание зашифрованных дисков. >> Обслуживание зашифрованных дисков (смена ключей шифрования, их резервное копирование и восстановление). >> Планы обслуживания (сервисные процедуры). >> Ведение журналов событий. Установка клиентского ПО (SDA) выполняется через механизм групповых политик, то есть присутствует интеграция со службой каталога Active Directory.

Ролевая модель Этот аспект хорошо проработан. В продукте имеются шесть собственных встроенных ролей, которые являются хорошей отправной точкой для начала работы. И вполне могут рекомендоваться к использованию, если собственная политика безопасности компании не противоречит предлагаемому подходу. Кроме того, существует возможность определять новые специализированные роли, что позволяет гибко настроить продукт в соответствии с действующей на предприятии политикой ИБ. Итак, какие варианты нам предлагаются по умолчанию: >> Оператор. >> Администратор информационной безопасности. >> Пользователь. >> Аудитор. >> Агент восстановления ключей. >> Инженер по обслуживанию. Первый пользователь, запустивший и успешно выполнивший первоначальную настройку, приобретает все предусмотренные в Secret Disk Enterprise роли. В дальнейшем роли пользователям назначает администратор информационной безопасности. Оператор может выполнить следующие действия: >> подключить и отключить криптохранилище; >> выполнить план сервисного обслуживания; >> просматривать настройки Secret Disk Enterprise; >> выполнить запуск и остановку сервера бизнес-логики; >> выполнить резервное копирование и восстановление мастер-ключа.

54

механизмы защиты Администратор информационной безопасности обладает следующими полномочиями: >> управление учетными записями компьютеров и пользователей, сертификатами и дисками; >> просмотр настроек Secret Disk Enterprise. >> Аудитор не имеет возможности вносить какие-либо изменения в настройки SDE. Он может лишь просмотреть выполненные оператором и администратором информационной безопасности настройки, а именно: >> конфигурацию сервера (настройки, хранящиеся в реестре сервера бизнес-логики); >> списки компьютеров, дисков, ролей, пользователей и их сертификатов, процедур, входящих в план обслуживания; >> информацию о лицензии; >> информацию о мастер-ключе; >> журнал событий. Пользователь на своем рабочем месте обладает возможностью только подключать и отключать защищенные диски. Что касается агента восстановления, то его задачи – экспорт мастер-ключа шифрования системного раздела для экстренного доступа к данным в случае выхода из строя или потери eToken. Кроме того, он обладает правами аудитора. Таким образом, встроенные роли во многих ситуациях окажутся вполне достаточными для решения всех задач, связанных с разделением полномочий. Что касается назначения роли пользователю или группе, то поскольку SDE интегрирован с AD, этот процесс не вызовет трудностей. *** Подводя итоги краткого обзора продукта Secret Disk Enterprise, следует отметить, что продукт предоставляет возможность устранить проблемы защиты дисковых накопителей на рабочих станциях пользователей, что, несомненно, благотворно скажется на ситуации в ИБ для всего предприятия в целом. Основными преимуществами продукта являются, вопервых, возможность построения расширяемого в дальнейшем решения, соответствующего уровню требований к защите данных и зрелости компании с точки зрения ИБ, во-вторых, поддержка российских криптоалгоритмов, что упрощает применение продукта на территории Российской Федерации, и, наконец, тесная интеграция со службой каталога Active Directory и гибкая ролевая модель, что в свою очередь избавляет ИТ-службы компании от многих проблем, связанных с развертыванием, управлением и поддержкой. Автор выражает искреннюю признательность директору по продуктам компании «Аладдин Р.Д.» Крячкову А.В. за помощь при подготовке материала. EOF 1.

2.

3.

4.

http://technet.microsoft.com/en-us/windows/dd408739. http://technet.microsoft.com/en-us/library/cc700811.aspx. http://www.aladdin-rd.ru/catalog/secret_disk/workgroup.

SDE – Secret Disk Enterprise – http://www.aladdin-rd.ru/catalog/ secret_disk/enterprise/details.

5. Failover cluster – отказоустойчивый кластер – http://technet. microsoft.com/en-us/library/ff182338(v=ws.10).aspx.

6. NLB – Network Load Balancing – http://technet.microsoft.com/enus/library/cc770558(v=ws.10).aspx.

март 2012 системный администратор

механизмы защиты

Безопасность Визитка Игорь Савчук, работает в CoreLink Datacenter. Программист с 12-летним стажем. Автор более 200 опубликованных в печатной прессе статей по ИТ-тематике

Позади закрытых дверей

Часть 2. Port knoсking «по-взрослому» Почему эти техники в процессе своей эволюции так существенно усложняются? Рассматриваем двухсторонний гибридный метод и скрытую авторизацию по единственному криптопакету

В прошлой статье [1] мы рассмотрели уже отчасти классические методы PK, используя приобретенные знания и опираясь на изложенную теоретическую базу, в этой заключительной статье обзорно коснемся перспективных направлений современного port knocking. Но начать логично с исходного вопроса – мотивации для их создания. Очень сильный недостаток PK в его классическом понимании – это особенности сетевой среды, которая изначально не предназначена для подобных нестандартных операций. Например, если клиент выстукивает сериютрель из восьми пакетов, где гарантия того, что пятый пакет не придет быстрее четвертого, нарушив всю ключевую последовательность? На самом деле гарантий здесь никаких нет, и, чтобы повысить вероятность правильной последовательности, клиенту лучше высылать пакеты с некоторой паузой, например, в четыре секунды. Нетрудно подсчитать, что авторизация в этом случае растянется на полминуты. Увеличив время тайм-аута на сервере, это можно как-то пережить, но что случится, если в этот момент одновременно начинает стучаться какой-то другой клиент, вклиниваясь в вашу последовательность? Как в рамках этих достаточно узких возможностей классической техники надежно бороться с replay-атаками (sequence replay attack) или c потенциальной проблемой прозрачного перехвата всего трафика, например, в виде атаки «человек посередине» (man in the middle attack)?

Fwknop: прогрессивный SPA Да, на самом деле подводных камней тут предостаточно, поэтому классический port knocking в процессе поиска решений и эволюционного развития пришел к новой технике – авторизации по одному пакету (Single Packet Authorization, SPA) [2]. И рассмотрим мы ее опять на примере. В качестве такового я выбрал fwknop (firewall knock operator) [3] – по моему мнению, одну из самых удачных реализаций SPA. Несмотря на то что она может работать и в режиме обычного PK, что порой очень удобно из соображений совместимости с другими подобными решениями, в нашем описании мы сосредоточимся только на ее SPA-

системный администратор март 2012

составляющей. Утилита написана на Perl и плотно интегрируется с возможностями брандмауэра (поддерживаются netfilter/iptables и ipfw), при этом по умолчанию SPA-пакеты доставляются через протокол UDP (поддерживаются также TCP и ICMP). Для начала работы клиенту заранее нужно получить свой приватный DSA-ключ. Итак, в терминологии SPA «стуком» называется отправка единственного и уникального «пакета идентификации». Давайте снова воспользуемся самым быстрым способом познакомиться с потенциальными возможностями системы – рассмотрим структуру такого пакета с примером его заполнения: >> Случайно сгенерированные числовые данные (16 байт). >> Имя пользователя. >> Временная метка локальной системы (Timestamp). >> Версия клиента fwknop (для обеспечения обратной совместимости). >> Код режима: запрашивается выполнение команды или доступ к серверу. >> Адрес/порт клиента для удаленного подключения или код команды. >> Контрольная сумма-подпись этого пакета (MD5). В итоге все поля собираются в единую строку, кодируемую в формате Base64, поля которой разделяются символом «:», и на выходе получается упакованная последовательность байтов. Далее она шифруется по алгоритму AES в режиме CBC (Cipher Block Chain) при размере блока в 128 бит и длине ключа в 256 бит. В заключительной фазе эта строка инжектируется в выбранный транспортный пакет и отправляется в адрес fwknop-сервера, который прослушивает фиксированный порт (по умолчанию – 66201) в ожидании новых заданий. В самой последней версии fwknop можно отказаться от постоянного порта, для чего реализована сложная методика рандомизации портов, принимающих SPA-пакеты, с которой предлагаю ознакомиться здесь [4]. На первый взгляд кажется, что, будучи привязанным к одному случайному порту, fwknop более заметен со стороны гипотетического сетевого наблюдателя, чем класси-

55

Безопасность ческий PК, работающий посредством множества случайных портов. Но на самом деле такой подход дает возможность отказаться вообще от каких-либо статических сигнатурных маркеров для SPA-пакетов: теперь любой приходящий пакет успешно расшифровывается и исполняется, либо он просто отбрасывается, если имеющиеся в системе DSA-ключи не смогли его расшифровать. С точки зрения злоумышленника, не знающего целевой порт сервиса, задача обнаружения таких пакетов в общем сетевом потоке практически невыполнима. Очевидно, что при такой однопакетной авторизации также отпадают многие вышеперечисленные коллизии, свойственные классическому PK, что на фоне использования сильного криптоалгоритма идентификации и вовсе выставляет традиционный PK как устаревший метод. После получения SPA-пакета и его успешной расшифровки серверный fwknop в целях дополнительной проверки на правомерность доступа может выполнить сканирование системы подключаемого клиента на предмет ее особенностей (passive fingerprinting), для чего заранее необходимо установить стороннюю утилиту p0f [5]. Кстати, после долгого перерыва она наконец снова обновилась и продолжила свое развитие. В отличие от известного сканера nmap p0f использует полностью пассивные механизмы fingerprinting, т.е. не генерируется никакого дополнительного трафика, который может быть обнаружен исследуемой стороной. И только если каскад из этих проверок пройден успешно, заданная во входящем fwknop-пакете команда исполняется PK-сервером. В заключение рассмотрения fwknop отмечу три момента. Во-первых, сама криптографическая реализация идентификации базируется на стандарте ISO/IEC 9798-2 для высоконадежных систем. Для UDP-пакетов возможен дополнительный слой асимметричного шифрования через GPG [6], кроме того, клиент fwknop умышленно спроектирован так, что «тайные команды» на сервер в целях конспирации можно отправлять через анонимную сеть Tor Onion Network [7]. Второй момент – это наличие поля «временных Рисунок 1. Графический клиент morpheus-fwknop

56

механизмы защиты штампов» у каждого SPA-пакета. В отличие от похожей PKсистемы Cerberus [1] в fwknop не требуется синхронизации времени взаимодействующих сторон, и это поле пока никак не используется на стороне сервера. Для противодействия replay-атакам здесь применяется другая, более удобная для всех логика: сервер хранит хеши всех обработанных пакетов. С учетом первого статического блока внутри зашифрованного пакета (случайная комбинация символов), а также динамического timestamp – клиент не может даже теоретически снова сгенерировать идентичный пакет, поэтому любой повторно принятый пакет автоматически отвергается со стороны сервера. Третий, заключительный, пункт касается немаловажного момента работы с клиентской частью fwknop – она будет функционировать везде, где доступен Perl (для Windows есть Strawberry Perl [8]). Самые последние версии этой программы были полностью переписаны на C (сохранена полная совместимость по протоколу), доступны ее сборки под Linux, Mac OS X, *BSD [9]. Есть графический Win32-клиент для Windows (поставляется с исходниками на Delphi) [10], а также новый проект на .Net – morpheus-fwknop [10] (см. рис. 1). В дополнение есть решение для Android [11] и веб-прокси WebKnock [12] (см. рис. 2), который позволяет послать свой SPA-пакет с любого стационарного или мобильного устройства, подключенного к Интернету. При использовании fwknop в режиме обычного PK (nonSPA) подходит множество ранее упомянутых клиентов для knockd [1]. Для тестирования правильности сопряжения и настроек клиента и сервера любезно поставляется специальный сервисный скрипт [13].

Гибридный PK: сумма всего лучшего Гибридными называют технологии PK, в рамках которых сочетаются сразу несколько разнородных концепций. Обобщая, можно выделить типичные составляющие гибридного PK (HPK): традиционный port knocking, стеганография [14], криптография, реализация обоюдной авторизации (часто двухсторонняя SPA). Не нужно думать, что подобные «слоеные бутерброды» изобретают лишь для увеличения формальной сложности защиты – скорее это попытка ювелирно подогнать друг под друга разные техники, чтобы каждая органично нивелировала своими преимуществами недостатки другой и наоборот. Существует несколько работ [15], подробно описывающих HPK, из-за недостатка места я сосредоточусь лишь на двух типичных преимуществах этого подхода: Проблема идентификации пакета: если, с одной стороны, есть явная и однозначная сигнатура для каждого «магического пакета» (как в Cerberus [1]), то такие пакеты будут рано или поздно обнаружены и выделены из общего TCP/IPпотока злоумышленником. С другой стороны, если, опасаясь этого, такие пакеты никак не маркировать, заставляя сервер PK каждый входящий пакет «вслепую» распаковывать и верифицировать по некой контрольной сумме (как в fwknop), то это создает весьма ощутимую нагрузку на сервер. Это открывает возможность злоумышленнику для намеренной эксплуатации «родовой особенности» этой техники, что приведет к возникновению сильнейшего DDoS-эффекта.

HPK в этой дилемме занял выигрышную компромиссную позицию: он маркирует каждый свой «магический пакет»,

март 2012 системный администратор

механизмы защиты

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

Port knocking не претендует заменить традиционную аутентификацию, это лишь еще один слой безопасности

но при этом для сокрытия идентифицирующего признака применяются продвинутые методы стеганографии. Как пример последнего – номер запрашиваемого для открытия сервиса/порта + пакет авторизации здесь может быть передан даже не на транспортно-сетевом уровне TCP/IP, а на прикладном уровне (или их смешении), будучи внедрены в обычное со всех точек зрения png-изображение. Проблема replay-атак: в HPK всегда применяется двухсторонняя авторизация. Таким образом, здесь PK осуществляется всегда в две стороны. Это устраняет множество потенциальных проблем и неудобств, которые свойственны другим PK-техникам, пытающимся противодействовать replay-атакам с помощью различных полумер (необходимость предварительной синхронизации времени на клиенте и сервере, как в Cerberus; хранение базы из хешей всех обработанных пакетов, как в fwknop, и так далее). У такого подхода есть еще несколько преимуществ, но для баланса отметим и главный недостаток – общий алгоритм взаимодействия при этом резко усложняется. У разных реализаций HPK имеется множество нюансов, поэтому предлагаю очень кратко коснуться технических особенностей лишь одной, но весьма достойной – Tariq [16]: >> Здесь очень ясный и чистый код на Python в силу того, что логика сервера – это лишь надстройка над пакетом scapy [17]. В результате все низкоуровневые детали его протокольно-транспортного устройства изолированы от самой системы. >> Tariq не прослушивает множество TCP/IP-портов, как это делают стандартные PK-серверы. Он использует возможности scapy для пассивного сниффинга всего входящего трафика, равно как и для конструирования обратного пакета-ответа. >> Для еще большего упрощения логики устройства Tariq использует сторонние библиотеки: шифрования (GnuPG), стеганографии (steganogra-py) и возможности упомянутого scapy для всего остального спектра сетевых операций. >> В данном случае для доставки скрытых зашифрованных пакетов используется приведенный выше при-

системный администратор март 2012

мер – обычные графические изображения (прикладной уровень OSI), для работы с которыми дополнительно понадобится библиотека Python Imaging Library (PIL). >> Tariq поставляется сразу как совмещенный пакет – с сервером и клиентом, укомплектованный всеми необходимыми библиотеками, и может быть запущен в качестве клиента везде, где доступна среда исполнения Python (в том числе на мобильных платформах). Несмотря на свое бесспорное техническое совершенство, HPK обычно алгоритмически очень сложен, что особенно ощущается при подборе клиента и иногда лишает мобильности и простоты его использования. Рисунок 2. SPA-авторизация через браузер – WebKnock

57

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

механизмы защиты

Port knocking на перекрестках истории

пример, ACK-запросов без ответа и т.п.). Но на самом деле HiddenHand позволяет не только открывать порты по запросу клиента, но также удаленно конструировать новые правила для работы системы безопасности, абсолютно незаметно, через имена подходящих по названию доменов-команд, динамически корректируя ее логику работы и настройки. Пока мы сосредоточились лишь на серверной стороне этой реализации, но стоит отметить также и удивительную простоту управления подобным механизмом со стороны клиента. На самом деле здесь не нужно использовать какойто сторонний «сакральный код» – для этого подходит множество подручных и обыденных программ, таких как nslookup или host, также можно воспользоваться веб-интерфейсами аналогичных сервисов. Но в действительности все обстоит даже еще проще. Брайан рекомендует создание на авторитетном DNS-сервере домена (находящемся полностью под вашим контролем) настройку для произвольного субдомена, который будет использоваться именно для этой цели. Например, для созданного домена третьего уровня my.megashop.net можно настроить тригеры прослушки и интерпретации ваших DNS-команд при каждом обращении к нему. После этого можно использовать обычный браузер для запроса к подобному домену, например, запрос к ресурсу static.my.megashop.net может открывать порт с SSH, а обращение к изображениям, хранимым на img.my.megashop.net, будет снова закрывать его. На самом деле подобные запросы могут исходить откуда угодно, не обязательно от вашего браузера, а, например, от стороннего сайта, который хостит страницу, элемент которой (.css-файл или картинка-аватор, как в примере Брайана) загружается с данного ресурса. Брайан приводит рабочую демонстрацию этого, когда вход на его любимый технический форум (после авторизации на форуме происходит подгрузка аватора с «магического субдомена»), вызывает вышеописанный эффект «веерно падающего домино», при котором SSH «вдруг» оживает и начинает принимать запросы. Фактически на базе идей PK здесь реализована классическая двухфазовая авторизация (в данном случае SSH), с той лишь разницей, что в отличие, например, от подобной двухступенчатой схемы у Google здесь факт прохождения идентификации носит крайне неявный характер (успешный вход на публичный форум = первая фаза аутентификации при доступе к приватному SSH). Хочу отдельно подчеркнуть, что этот дополнительный уровень сокрытия и безопасности очень прост в реализации. Брайан использовал три простых Perl-скрипта, на написание и отладку которых у него ушел один выходной.

Исторически идея port knocking была впервые сформулирована в открытых источниках в начале 2001 года в почтовой рассылке German Linux User Group. Сам термин был придуман и озвучен специалистом по сетевой безопасности Мартином Крживинским (Martin Krzywinski) в 2003-м в журнале SysAdmin Magazine. Первым практически реализованным «кнокером» стал Cerberus [1], который, кроме этого, впервые использовал усложненную методику одноразовых паролей (One Time Password, OTP). В целом из‑за однотипности и простоты классического PK всех его представителей принято обозначать как TPK (traditional port knocking), где наиболее типичный и яркий представитель – knockd [1]. Дальнейшее совершенствование методов сокрытия привело к созданию механизма авторизации по единственному криптопакету (Single Packet Authorization, SPA), который был впервые продемонстрирован в рабочем виде в 2005 году на конференции BlackHat. Самая удобная и популярная среди широких народных масс реализация SPA была представлена чуть позже – в 2008-м – Майклом Рашем (Michael Rash), который создал fwknop (программа до сих пор активно развивается). Третье и последнее поколение «кнокеров» – это различные гибридные техники (hybrid port-knocking, HPK), сочетающие в себе сильные стороны от самых разных концепций и течений (иногда в силу экстравагантности своих подходов ставящие под сомнение даже свою принадлежность к PK). Огромное количество информации и разных реализаций PK доступно на портале, посвященном этой теме, – www.portknocking.org.

Watch_dns: высшая магия скрытой авторизации Известный американский специалист по безопасности Брайн Хатч (автор серии книг «Linux Exposed») описал [18] и реализовал в 2009 году систему для прослушки DNSзапросов на предмет скрытых knock-knock-запросов. В его оригинальной реализации простая Perl-программа под названием watch_dns просматривала весь UDP-трафик, поступающий на локальный DNS-сервер, формируя список всех запрашиваемых хостов, а также IP-адреса источников запросов. Второй Perl-скрипт в режиме реального времени сканировал этот список и по специальному правилу выделял доменные имена, интерпретируя их как команды-запросы (для чего был разработан довольно простой, но в то же время гибкий язык HidenHand). Даже с точки зрения внешнего наблюдателя, который имел бы полный доступ к трафику обмена сообщениями между сервером и клиентом, не происходило бы ничего необычного – DNS-сервер, так же как и все остальные сервисы, работает штатным образом. Здесь в отличие от обычного port knocking нет вообще никаких бессмысленных, подозрительных или странных пакетов (наРисунок 3. «Луковица» из защитных слоев сервера с участием PK

58

*** В заключение еще раз подчеркну: port knocking не претендует заменить традиционную аутентификацию, это лишь дополнительный слой безопасности (см. рис. 3), который эффективно нейтрализует огромное количество специализированных инструментов и методов, разработанных для автоматизации подбора паролей, изучения уязвимостей публичных сервисов и поиска ошибок настройки, а также последующего их взлома или незаконного использования. Во многом PK основывается на известном принципе security through obscurity и позволяет вывести наиболее чувствительные сервисы из зоны прямой видимости (и досягаемости) злоумышленника.

март 2012 системный администратор

механизмы защиты Но, как и любая технология, PK не лишена недостатков. Традиционная схема (TPK) подвержена опасности нарушения последовательности доставки (или потери) пакетов из-за естественных сетевых коллизий, сложностям в некоторых случаях при подключении через NAT/PAT [19], использовании в многопользовательской среде или на нагруженных системах. Кроме того, на нее легко осуществление своего рода DDoS-атаки: когда злоумышленник, бомбардируя потоком случайных «стуков» защищенный сервер (и для создания этого «шума» хватит даже низкоскоростного подключения), блокирует всякую возможность авторизоваться у легального пользователя. Большинство этих и других проблем успешно решаются в более современных реализациях PK, в первую очередь в методиках на основе SPA и HPK. EOF 1. Савчук И. Позади закрытых дверей. Часть 1. Специализированные приложения для PK. //«Системный администратор», №1-2, 2012 г. – С. 74-78.

2. Single Packet Authorization (SPA) – http://www.cipherdyne.org/ fwknop/docs/SPA.html.

3. Fwknop – http://www.cipherdyne.org/fwknop.

4. Рандомизация портов в fwknop – http://www.cipherdyne.org/blog/ 2008/06/single-packet-authorization-with-port-randomization.html.

5. Passive OS fingerprinting tool (p0f) – http://lcamtuf.coredump.cx/ p0f.shtml.

6. GNU Privacy Guard, свободная альтернатива PGP – http://www. gnupg.org.

7. Tor Onion Network – https://www.torproject.org, http://www. cipherdyne.org/fwknop/docs/talks/dc14_fwknop_slides.pdf.

системный администратор март 2012

Безопасность 8. Интеграция fwknop с Strawberry Perl – http://strawberryperl. com, http://www.cipherdyne.org/blog/2009/05/building-a-nativewindows-fwknop.exe-binary.html.

9. fwknop-2 на чистом C – http://www.cipherdyne.org/blog/2010/07/ pure-c-implementation-of-single-packet-authorization.html.

10. Win32-клиент от разработчика, а также сторонний .Net-клиент Morpheus – http://www.cipherdyne.org/fwknop/download/fwknopclient.zip, http://sourceforge.net/projects/morpheus-fwknop.

11. SPA-авторизация через Android-клиент – http://www.cipherdyne. org/blog/2011/01/single-packet-authorization-on-android.html.

12. WebKnock: SPA-авторизация через веб – http://www.cipherdyne. org/blog/2011/10/webknock.org-single-packet-authorizationproxy.html.

13. Тестирование работы fwknop через скрипт fwknop_test.pl – http://www.cipherdyne.org/fwknop/docs/test_suite.html.

14. Стеганография – http://en.wikipedia.org/wiki/Steganography.

15. Network Security Using Hybrid PK –http://www.uop.edu.jo/ download/research/members/382_1316_Network_Security_ Using_Hybrid_Port_Knocking.pdf.

16. Tariq Hybrid System – http://code.google.com/p/tariq.

17. Бражук А. Утилита Scapy.//«Системный администратор», №10, 2011 г. – С. 66-69.

18. Описание метода DNS-knocking – http://www. hackinglinuxexposed.com/articles/20030730.html, http://www. hackinglinuxexposed.com/articles/20030814.html, http://www. hackinglinuxexposed.com/articles/20030825.html.

19. Для всех разновидностей NAT-подключений можно посоветовать uPortKnock – http://lanmaster53.com/2010/10/uportknockv1-1-now-natpat-friendly.

59

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

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

Визитка Юрий Денисов, начальник отдела одного из провайдеров г. Владимира. Интересы – сетевые технологии, проектирование распределенных сетей передачи данных, развертывание телематических сервисов, биллинговые системы

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

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

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

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

60

Уровень опасности Low

Medium

2 1 0 0 0 0 0 0 0 0 0 0

2 9 7 1 1 0 0 0 1 0 0 1

Год Medium & High 4 11 24 3 1 0 0 2 11 8 0 1

Выясните, насколько «дыряво» ПО В действительности, если мы не являемся ни разработчиком, ни тестером приложения, то не можем повлиять на процесс его написания и совершенствования. Все, что нам остается, – это внимательно следить за выходом обновлений и своевременно их устанавливать. Но прежде всего необходимо осознать, насколько «дырява» текущая версия применяемого нами ПО. Вполне может сложиться ситуация, когда обновления безопасности не требуется вовсе. К счастью, появилось несколько баз данных, содержащих все известные (документированные) уязвимости для различного ПО. Самая, пожалуй, известная из них – это база CVE (расшифровывается как Common Vulnerabilities and Explosures). Найти ее можно на сайте http://nvd.nist.gov. Эта база открыта, и ее можно свободно скачать в нескольких различных форматах либо посмотреть прямо на сайте. Выясните, какая версия базы данных стоит на вашем сервере, и попробуйте определить список найденных для нее уязвимостей. Вот один из примеров.

Таблица 2. Количество найденных уязвимостей в БД MySQL

Таблица 1. Количество найденных уязвимостей в БД Microsoft SQL Server Год

В статье [1] рассматривались уязвимости первой и третьей групп, сейчас же подробнее поговорим о второй.

High 2 2 17 2 0 0 0 2 10 8 0 0

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

Таблица 3. Количество найденных уязвимостей в БД Postgresql

Уровень опасности Low

Medium

3 1 6 3 1 0 2 0 7

1 2 2 3 2 9 7 7 4 5 4 16 20

Год Medium & High 3 6 8 5 6 10 8 7 5 7 4 16 20

High 2 4 6 2 4 1 1 0 1 2 0 0 0

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Уровень опасности Low

Medium

0 0 0 0 0 2 1 0 0 0 1 0

1 2 3 1 4 5 3 4 6 5 1

Medium & High 1 4 7 1 6 7 6 5 7 7 1

High 2 4 0 2 2 3 1 1 2 0

март 2012 системный администратор

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

сетевая безопасность Мне в «наследство» достался Windows-сервер с установленной на нем базой данных MySQL версии 5.5.8. База обслуживала подключения к ней из внешнего мира и прослушивала стандартный порт TCP 3306. Основной проблемой сервера была периодически «зависающая» БД, которую, недолго думая, лечили перезагрузкой всего сервера. В базе CVE для этой версии MySQL присутствует уязвимость под номером CVE-2011-5049. Ее суть в том, что удаленный атакующий может вызвать отказ в обслуживании (DoS) MySQL-сервера, послав на его порт TCP 3306 специально собранный пакет. Подозрительное совпадение. Кроме того, для данной уязвимости существует эксплоит, который вполне реально запустить. После обновления базы данных до наиболее свежей версии описанные проблемы исчезли.

для которых существуют в открытом доступе коды эксплоитов. Можно периодически использовать в работе такие пакеты, как, например, Metasploit, который имеет огромную базу готовых эксплоитов, а также удобный интерфейс для написания их самостоятельно. Схема работы примерно такая: >> выясняем наличие уязвимости с возможностью использования удаленно. >> Проверяем ее наличие с помощью Metasploit. >> Закрываем брешь с помощью патча или обновления версии. >> Повторно запускаем Metasploit, чтобы убедиться в том, что брешь закрыта.

Не поддавайтесь паранойе

Как добиться того, чтобы лишний раз не полениться с обновлением? Хорошо если в нашем ведении один сервер с БД, в этом случае можно и пересобрать пакет. Но что делать, если таких серверов достаточно много? Необходимо максимально автоматизировать процесс обновления. Со временем я пришел к выводу, что удобнее всего использовать пакет из дистрибутива (применительно к Linux). Например, при использовании Linux Debian обновление пакетов до последней версии происходит с помощью пары команд, при этом регулярно выходят обновления безопасности, благодаря чему спать можно гораздо спокойнее. Конечно, за это мы платим тем, что используем не самую последнюю версию пакета (версии в составе дистрибутива немного запаздывают), но зато получаем стабильный и безопасный продукт. Весьма интересной является статистика по количеству уязвимостей, найденных в тех или иных продуктах. Данные по некоторым из них (составлено на основе базы CVE) приведены в таблицах 1, 2 и 3. Более высокие цифры могут свидетельствовать как о большем количестве ошибок, допускаемых программистами, так и об активном и тщательном тестировании продукта. Например, в отличие от остальных продуктов в 2012-м уже появилось большое количество обнаруженных уязвимостей в MySQL (я даже специально добавил строчку с 2012 годом в соответствующей таблице). Возможно, Oracle с этого года просто внимательнее подошел к тестированию продукта. В любом случае важно то, насколько оперативно разработчики реагируют на появление тех или иных уязвимостей. Многие разработчики позволяют подписаться на новостные рассылки об их продуктах. В случае появления критической уязвимости и выхода патча исправления они оповестят об этом по электронной почте. Это избавляет от необходимости постоянного самостоятельного мониторинга ситуации.

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

Access Complexity. Переводится как сложность доступа к ресурсу. Чем больше специальных условий должно быть выполнено для удачной реализации атаки, тем выше сложность доступа.

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

Authentication. Необходимость аутентификации пользователя для возможности запуска эксплоита. Это тоже очень важный параметр, обозначающий необходимость предварительной авторизации на атакуемом сервисе. Если она требуется, то и возможность эксплуатирования уязвимости уменьшается. Применительно к базам данных: атакующий в этом случае должен иметь действительный логин и пароль для доступа к базе данных. Возвращаясь к упомянутой выше уязвимости, мы видим следующие параметры: access complexity – medium; access vector – network exploitable; authentication – not required to exploit. Таким образом, есть уязвимость, которой можно воспользоваться, имея доступ к сервису по сети, при этом нам не обязательно авторизовываться на нем. Больше всего стоит опасаться именно уязвимостей, доступных по сети,

системный администратор март 2012

Не ленитесь обновлять

*** В заключение хочу сказать, что в большинстве случаев ваша база данных будет в безопасности до тех пор, пока на нее не обратит внимания квалифицированный хакер. Он протестирует вашу систему на наличие брешей и, если они есть, скорее всего найдет их, потому о безопасности лучше позаботиться заранее. EOF 1. Денисов Ю. Все в комплексе. Безопасность баз данных. Часть 1. //«Системный администратор», №1-2, 2012 г. – С.61‑63.

61

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

ИТ для банков

Визитка

Виталий Иванов, эксперт по информационной безопасности

Контроль браузера клиента Важный шаг в безопасности ДБО

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

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

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

Опасности веб

В Rapport реализовано три технологии защиты пользовательских данных: >> Browser Lockdown – охрана паролей, которые хранятся в базе данных браузера; >> Keystroke Encription – шифрование пароля при наборе его на клавиатуре; >> Communication Lockdown – проверка идентичности сервера. Рассмотрим каждый компонент продукта подробнее.

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

62

Защита браузера

Browser Lockdown Многие пользователи сохраняют пароли от различных серверов в браузере. Хотя доступ к хранилищу имеет только сам браузер, его можно заставить ввести пароль на специальном хакерском сайте. Это можно сделать с помощью специального вредоносного кода на JavaScript или с помощью фишинговых сайтов или простой рекламы. Rapport шифрует все пароли так, что расшифровывать их может только сервер, на котором установлено специальное программное обеспечение. При этом данный компонент также проверяет целостность базы паролей перед их загрузкой в браузер. Сейчас поддерживаются наиболее популярные браузеры Internet Explorer, Firefox, Safari и Chrome.

март 2012 системный администратор

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

ИТ для банков

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

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

Communication Lockdown Данные, передаваемые по сети, могут быть перехвачены самыми разными способами – начиная от фишинга и заканчивая подделкой DNS. Часто браузер сам передает пользовательскую информацию на сервер злоумышленнику, не понимая, что он обратился не на легитимную систему, – именно так работает фишинг. Коммуникационный компонент Rapport перед отправкой конфиденциальных данных проверяет легитимность сайта, блокируя отправку подозрительным получателям. Компания Trusteer также предлагает инструменты для защиты и мобильных пользователей, функционал которых схож с Rapport. Это продукт Trusteer Mobile, который предназначен для мобильных платформ и планшетных компьютеров. В него входит два компонента: >> Secure Mobile Browser – является специальным защищенным браузером; >> Mobile Security SDK – компоненты для разработки защищенных мобильных приложений. Вместе с Rapport эти компоненты позволяют компании создать защищенную экосистему доступа для своих высококритичных веб-приложений.

системный администратор март 2012

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

Применение В целом продукты компании Trusteer предназначены для защиты корпоративных веб-приложений или предоставления защищенных услуг. В частности, системы дистанционного банковского обслуживания вполне могут быть защищены с помощью Rapport и других продуктов. Для этого поставщик услуг или корпоративный администратор вначале может установить Pinpoint, а уже по анализу оперативной ситуации рекомендовать тем или иным клиентам установку Rapport или Trusteer Mobile в зависимости от используемой ими платформы доступа. Продукт также хорошо подходит для защиты различных веб-приложений, которые оперируют конфиденциальными данными. Поэтому не менее востребован может быть набор защитных продуктов Trusteer и для любых других предприятий, у которых есть веб-приложения для мобильных сотрудников. С помощью Pinpoint, Rapport и Mobile такие компании могут защитить свои CRM, приложения коллективной работы, доступ к внутрикорпоративным базам данных и любым другим конфиденциальным источникам. Сегодня продукты Trusteer используются более чем в 200 банках по всему миру, включая крупнейшие – HSBC, Bank of America, ING и другие. Скачать бесплатную пробную 30-дневную версию продуктов можно на сайте официального дистрибьютора в России компании TopSecurity – www.tsecure.ru. ADV

63

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

угрозы

Визитка Игорь Савчук, работает в CoreLink Datacenter. Программист с 12-летним стажем. Автор более 200 опубликованных в печатной прессе статей по ИТ-тематике

Принтер как источник угрозы

Антируководство по взлому локальных сетей. Часть 2 Сетевые принтеры и МФУ. Какие скрытые проблемы безопасности и конфиденциальности они порождают? Как следует защищать и настраивать принтеры? Продолжаем начатый разговор

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

Дело о желтых точках Малоизвестная проблема принтеров – сложности с конфиденциальностью и встроенные функции слежения. И реализуется это, как правило, с помощью специальной скрытой маркировки всех распечатанных документов почти невидимыми желтыми точками. Несмотря на то что это явление получило общепризнанное название «маркировка желтыми точками» (yellow tracking dots) или printer steganography [2], не нужно понимать его буквально. Хотя микроскопические точки, безусловно, иногда встречаются, часто применяются и другие технологии для скрытой идентификации. Это могут быть неразличимые без специальной подготовки и оборудования особенности печати букв (шрифтов), неочевидные законо-

64

мерности изменения тонов определенного цвета (белогочерного), магнитные метки и тому подобное. Если сейчас уже есть специализированные программы, которые по распечатанному листу могут с большой степенью вероятности детектировать модель лазерного принтера, то насколько просто в этих совершенно невидимых особенностях печати скрыть гораздо более конкретные сообщения (IP-адрес принтера или компьютера-хоста, MACадрес и время печати, серийный номер принтера). Но одно дело, когда такой дополнительной маркировке подвергаются, например, деньги, и совсем другое, если подобная технология применяется скрытно от владельца принтера. Независимая организация EFF провела исследование [3], в ходе которого установила, что такая маркировка используется буквально повсеместно – из более 200 проверенных современных принтеров только у 31 из них не использовались методы скрытой стеганографии. Пример информационной поддержки граждан – общественная компания Seeing Yellow Campaign [4], где каждый покупатель принтера может получить бесплатную юридическую консультацию, как легально бороться с производителем такого принтера. На самом деле радикально решить эту проблему могло бы только одно – открытие исходных кодов прошивок, используемых на принтерах, так как только эта мера позволяет ясно и прозрачно убедиться в наличии закладок в функциональности и логике работы принтера или МФУ. На практике же… некоторыми производителями планируется еще большее ужесточение политики в области защиты содержимого прошивки.

Когда лекарство хуже болезни Ранее [1] мы уже основательно коснулись проблем, связанных с прошивками принтеров. Кратко суть проблемы заключалась в том, что некоторые современные принтеры позволяют довольно просто менять свою программную прошивку, в том числе удаленно, и во многих случаях для этого даже не требуется знание пароля. Что и было наглядно продемонстрировано [5] исследователями из Колумбийского университета.

март 2012 системный администратор

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

угрозы

Главная цель – привлечь внимание администраторов к часто игнорируемой проблеме безопасности принтеров и МФУ

В качестве решения подобных уязвимостей часто предлагается [6] «подписывание» прошивок уникальной цифровой подписью, чтобы принтеры могли запускать исключительно легитимный код. По моему мнению, производители только ухудшают ситуацию, предлагая «лекарство, еще опаснее самой болезни». Безусловно, оборудование, которое может работать только с подписанным кодом, теоретически безопасно, но тут важно дополнение – в том случае, если у самого владельца этого принтера (или его администратора) есть хоть какое-то право решать, какие подписи (прошивки) принимать, а какие – нет. Если же под ширмой «усиления безопасности» и вовсе все права по установке принтерного ПО не явным образом передать исключительно производителям оборудования (в некий Удаленный Центр Принятия Важных Решений), то это никакая не безопасность. На самом деле это отсутствие выбора вообще. Настало время подвести наш первый промежуточный итог. Эти (и многие другие) проблемы есть следствие того, что ключевые программные компоненты принтеров являются закрытыми и проприетарными. А текущий тренд еще больше ужесточить доступ к логике работы принтера через подписывание его ПО только усложнит борьбу с подобными явлениями.

Баррикадируемся изнутри Переходя к практическому обсуждению защиты сетевого офисного принтера от потенциальных сетевых атак, нужно начать с основного – установки пароля на нем. Второй оправданный шаг – это настройка списка доступа к принтеру (IP ACLs, Access Control Lists). Эта функциональность сейчас присутствует практически в любом современном сетевом принтере. Ниже хочу продемонстрировать сеанс такой настройки через telnet: savgor@corelink# telnet 168.188.1.12 Trying 168.188.21.12...

Please type "?" for HELP, or "/" for current settings

системный администратор март 2012

> allow:0 > quit savgor@corelink# telnet 168.188.1.12 Trying 168.188.21.12... > allow:168.188.18.57 > allow:168.188.21.0 255.255.255.0 > allow:list Access Control List: IP: 168.188.18.57 Mask: 255.255.255.255 IP: 168.188.21.0 Mask: 255.255.255.0 > quit Connection closed by foreign host.

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

FTP-сервис: не гарантийный случай В статье [1] я уже описывал простые, но чрезвычайно эффективные методы DDoS-атаки на принтеры и МФУ, но это не единственно возможные варианты. Например, достаточно болезненный метод, когда инициируется начало удаленного обновления прошивки, а потом эта процедура умышленно обрывается сразу после ее запуска. Такой принтер будет совершенно не работоспособен, пока вы не проявите свою природную любознательность и настойчивость и не найдете способ, как самостоятельно восстановить прошивку. Замечание: хотелось бы дать важное пояснение: некоторые международные компании – производители принтеров отрицают возможность удаленной перепрошивки их устройств, в то же самое время в языке PJL все-таки содержится недокументированная функция remote firmware update (RFU). И хотя некоторые диалекты PJL действительно не поддерживают RFU, в процентном исчислении это скорее исключение из правил.

65

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

угрозы

«Климатгейт» и проблемы «безопасности по умолчанию»

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

В ноябре 2009 года был взломан [7] центральный сервер научного центра Climatic Research Unit (CRU). Этот скандал широко освещался в мировой прессе и даже получил громкое название «климатгейт» (Climategate), так как были опубликованы похищенные сенсационные сведения о многочисленных подтасовках научных данных, связанных с теорией «глобального потепления». В данном случае нас интересует техническая сторона этого взлома, о которой до сих пор известно очень немногое. В прессе озвучиваются лишь два факта: во-первых, этот инцидент по ряду косвенных признаков имеет «российский след», а во-вторых, первичным вектором атаки, через который и был получен доступ к хорошо защищенной локальной сети научного центра, был взлом служебного МФУ. Впрочем, было бы ошибкой как-то отдельно демонизировать именно сетевые принтеры и МФУ. Так, компания Zscaler Labs в ходе многомесячного сканирования сети установила [8] огромное количество свободно доступных через Интернет и никак не защищенных от посторонних лиц сетевых сканеров, копировальных машин, DSL-концентраторов, вебкамер, сетевых устройств хранения данных и самых разных систем VoIPтелефонии, доступ к которым в самом лучшем случае был защищен стандартным заводским паролем.

Кроме «силовых» DDoS-атак (с распечатыванием содержимого винчестера, как это было показано на примере в [1]), также очень эффективны атаки «на удержание», суть которых сводится к тому, что, пока активна telnet-сессия, принтер не в состоянии обрабатывать текущую очередь печати. То есть внешне он будет скорее мертв, чем жив, что обусловлено отсутствием даже минимальной многозадачности в его софтверной конструкции. Современные принтеры являются носителями многочисленных встроенных сервисов, таких, например, как FTP, веб, SMB, SNMP и так далее. При этом программная реализация данных сервисов выполнена чрезвычайно примитивно, то есть они стабильно (я бы даже сказал, надежно) подвержены различным fuzzing-атакам. Для большей конкретики предлагаю скачать и применить какой-нибудь FTP Fuzzer для тестирования надежности реализации сервиса FTP на вашей модели принтера. Обещаю, вы будете очень удивлены: в большинстве случаев вскрывается огромное количество примеров переполнения буфера (buffer overflow) при работе подобного сканера. Замечание: самый простейший вариант TP Fuzzer входит в состав Metasploit [9], но лично мне больше нравятся 4n FTP Fuzzer [9] и Infigo FTPStress Fuzzer [9], азы их использования можно почитать здесь [10]. Замечание: очень показательно, но модель сетевого принтера, с которым проводилось вышеуказанное тестирование, содержит «на своем борту» версию реализации ftp-сервера, выполненную еще в далеком «перестроечном» 1986 году, хотя сам этот принтер был произведен в 2010-м. Что важно, есть ощутимая вероятность того, что после возникновения подобной ошибки принтер станет уже непригодным к использованию, то есть просто «отключить-ивключить» его заново не получится. Исходя из практического опыта можно утверждать, что в большинстве случаев достаточно вызова ftp-команды LIST с длиной строки параметров больше 256 байтов, чтобы констатировать переполнение буфера. Можно приводить и другие иллюстративные примеры удаленного выведения сетевых принтеров и МФУ из строя,

66

Принтер должен печатать, и ничего более Отключите на принтере все вспомогательные сервисы, до которых сможете дотянуться. Потому третий, самый главный и одновременно до ужаса банальный, вывод звучит так: единственное, что должен делать принтер, – это печатать. Худо-бедно, но печатать, и больше от него ничего не требуйте. Дошла очередь показать, какое безобразие творится с веб-панелью управления принтером. Наиболее просто обход авторизации выполняется на некоторых МФУ марки Toshiba, поэтому наш практический пример посвящен именно ей. Здесь нужно просто знать прямой путь-URL на любое вложенное меню веб-панели, но поскольку все эти пути стандартные на всех моделях принтера, то это не такой уж и большой секрет. Вот пример подобного произвольного пути в меню «Сканирование»: http://198.68.0.1/TopAccess/Administrator/Setup/ ↵

ScanToFile/list.htm

Если предварительно не авторизоваться на таком принтере/МФУ и попробовать сразу перейти на одну из страниц веб-панели, произойдет вполне логичный редирект на страницу c приглашением сначала ввести пароль: http://198.68.0.1/TopAccess/Administrator/Login/Login.htm

Да-да, это сработала встроенная система безопасности принтера – лично я очень впечатлен таким поворотом дел. Поймите правильно мой скепсис, я никого не хочу обидеть, но только от одного произнесения вслух фразы «система безопасности принтера» у меня на столе мгновенно скисает молоко. Добавляем дополнительный «слэш» в первоначальный адрес, как показано ниже, и пробуем еще раз: http://198.68.0.1/TopAccess//Administrator/Setup/ ↵

ScanToFile/list.htm

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

март 2012 системный администратор

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

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

Дьявол носит Praeda Тема обзора уязвимостей, доступных в принтерах и МФУ, огромна, но есть еще один момент, которого я бы хотел обязательно коснуться напоследок. Это ответ на логичный вопрос: «Как добывается такое количество уязвимостей на принтеры?» Руководствуясь золотым принципом «предупрежден – значит, вооружен», хочу очень кратко рассмотреть всего лишь один из множества хакерских инструментов для автоматизации исследования и поиска уязвимостей в принтерах, чтобы вы могли сами продиагностировать свои принтеры на потенциально возможные проблемы. В нашем примере мы рассмотрим специализированный инструмент – Praeda [11], который, несмотря на свою молодость, уже успел снискать определенную известность «в узких кругах». Praeda – это довольно объемный скрипт на Perl (в самом конце 2011 года принято принципиальное решение и начат процесс переноса этого проекта с языка Perl на Ruby, но этот процесс находится пока еще в самой начальной стадии своей реализации), предназначенный для поиска активных уязвимостей в веб-панелях управления современных лазерных принтеров и МФУ. Во время своей работы он пытается выудить максимально большой объем информации, включая имена зарегистрированных пользователей, адреса электронной почты, адресные книги пользователей, данные аутентификации SMB, e-mail, LDAP-пароли и т.д. Как правило, вся подобная информация используется как стартовая точка для развития атаки на локальную сеть. Давайте очень кратко остановимся на параметрах работы Praeda, так как документация к нему очень скудная. Вот общий формат запуска: praeda.pl target_file tcp-port project_name output_file [-ssl]

Файл target_file содержит список-перечисление всех принтеров (их сетевых адресов), которые должны быть исследованы, записанных в формате «один адрес на строчку». Аргумент tcp-port указывает на порт веб-панели (допускается только одно – общее для всех значение), а project_name – это название проекта-исследования. Физически же будет создана отдельная папка с таким же именем, куда станут складироваться все собранные в рамках этого запуска данные. В этой же папке будет создан файл журнала data-file.log, документирующего все операции, выполняемые Praeda (его название определяет обязательный аргумент – output_file). Опция ssl необязательна, она позволяет работать с принтерами, где доступ к веб-панели открыт только через этот криптографический протокол. Вот пример запуска его диспетчера (головного файла комплекса): ./praeda.pl target.lst 80 pentest1 data-file.log

Хотелось бы отметить, что различные модули Praeda, которые могут быть автоматически запущены, будут подключаться по разным протоколам и портам, отличным от указанного в строке запуска скрипта, поэтому предварительно

системный администратор март 2012

Современные принтерные языки Наиболее известный сегодня принтерный язык – PJL (HP Printer Job Language) [12], реализующий уровень контроля заданий и расширенного управления принтером (в противоположность PCL или HP-GL/2). Так, например, он обеспечивает прозрачное переключение между языками для каждого отдельного документа, вывод сообщений на контрольную панель, настройку конфигурации, команды по управлению файловой системой принтера и многое-многое другое. Известная хакерская утилита Phenoelit’s Hijetter [13] позволяет через сеть использовать по своему усмотрению любые PJL-функции принтеров, в том числе малоизвестные и недокументированные. Несмотря на уверения производителей в абсолютно безопасной реализации PJL, достаточно сделать запрос в Google по словосочетанию «PJL exploits», чтобы убедиться, что здесь не все так гладко. Исторически PJL задумывался как мощное расширение языков PCL и JCL и создавался на их основе. Несмотря на то что PJL – разработка компании HP, сейчас этот язык используется на множестве современных принтеров от других известных производителей. Правда, в некоторых случаях их реализации могут содержать свои собственные функции, несовместимые с прототипом (ситуация отчасти напоминает SQL с его множеством общих диалектов, иногда несовместимых между собой в деталях).

PJL отчасти наряду с более ранними и простыми языками PostScript (PS), Epson Job Language (EJL) и Printer Command Language (PCL) монопольно доминирует на рынке принтеров. В свою очередь, некоторые идеи PJL получили дальнейшее развитие в PML (HP Printer Managment Language) – новейшем объектно-ориентированном и двухстороннем протоколе для одновременного обмена информацией между множеством приложений и принтеров.

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

10 простых правил Чтобы в многообразии примеров и разнородных советах не потерялась столь драгоценная конкретика, предлагаю свой краткий план-алгоритм для проверки и настройки каждого принтера/МФУ. Первое правило. Рекомендую как исходную точку всех операций собственноручную перепрошивку своего принтера штатными средствами, предоставляемыми компанией – производителем принтера/МФУ. После выхода любой новой прошивки очень многие проблемы с безопасностью все-таки находятся и, как правило, очень неспешно исправляются. Поэтому, выполнив такой апгрейд самостоятельно, вы как минимум превентивно закроете какие-то самые известные дыры, тем более что такое обновление штатным образом обычно несложно сделать, это доступно любому пользователю компьютера. Например, для принтеров от фирмы HP можно предложить практически полностью автоматические в принципе своей работы HP Download Manager или HP Web Jetadmin [14], краткое руководство по этой процедуре можно найти здесь [15]. Второе правило. Установите сложный пароль к принтеру (как правило, он же общий пароль и для всех других служб). Третье правило. Настройте запрет доступа к принтерам из внешних сетей на шлюзе (необходимо обязательно запретить как входящие, так и исходящие соединения). Четвертое правило. Настройте правила доступа ACL на самом принтере (иногда эта функция может называться «firewall»). При создании ACL лучше руководствоваться принципом «запрещено все, что не разрешено».

67

Безопасность Нужно помнить, что иногда в веб-панели есть галочки типа Allow Web Server (HTTP) access or Allow http connections to bypass ACL. Советую сразу определиться с подобными неявными исключениями из действующих правил ACL, часто разбросанными по разным меню, учитывая наш следующий пункт. Пятое правило. Отключите на принтере/МФУ все дополнительные сервисы и начните это делать с веб-панели управлением принтером. В крайнем случае, включите доступ к нему по протоколу SSL/TLS, чтобы позволить тешить себя иллюзией «некоей защищенности». Возможно, я патологически старомоден, но почему-то очень настороженно отношусь к людям, которые используют smtp-релей принтера для отправки своей email-почты. Следующий шаг – внимательное и вдумчивое отключение всех лишних возможностей непосредственно у службы печати. В некоторых принтерах есть архиполезная функция Disable all features from features list except for 9100 Printing – это именно то, чему посвящен весь этот пункт. Шестое правило. Отключите встроенный Wi-Fi либо поставьте на него пароль и одновременно понизьте уровень сигнала до минимума. Если используете SNMP, сразу задайте имя сообщества (community name). Будет вообще здорово, если вы включите при этом работу только по SNMP v3. Седьмое правило. У сетевого принтера в идеале должен быть статический IP-адрес из диапазона вашей локальной сети (отключите на нем dhcp), а прописанный шлюз должен соответствовать требованиям пункта 3. Избегайте сохранять в таких устройствах какие-либо чувствительные пароли, например, интегрируя его с LDAP. Восьмое правило. После всего проделанного включаем и настраиваем SysLog Server на принтере: Syslog-svr: 128.255.*.* Syslog-max: 100 Syslog-priority: 5

После этого периодически анализируем критические уведомления от SysLog. Девятое правило. Для безопасности хранимых документов на внутренних винчестерах отключите протоколы PJM, PML, а также NFS – в совокупности это делает невозможным внешний доступ к файловой системе принтера. В современных МФУ и некоторых сетевых принтерах в качестве источника хранения данных используются винчестеры или карты памяти (Compact Flash Card) либо и то и другое одновременно. Также включите параметры Secure Fast Erase и Secure File Erase Mode – если первый запрещает принтеру хранить уже обработанные (распечатанные) документы в своем внутреннем хранилище, то второй параметр удаляет все эти документы действительно безвозвратно. В более новых МФУ есть возможность выставлять отдельный пароль на любой доступ к файловой системе устройства. Десятое правило. И, наконец, понадобится вдумчивое чтение специализированной инструкции по безопасности к конкретной модели принтера. Например, для HP в качестве хорошей отправной точки можно посоветовать три руководства: это HP Jetdirect Security Guidelines [16], HP Security Solutions FAQ [16], а также не менее полезное Nist Security Checklist [16].

68

угрозы *** Согласен, не часто в жизни застанешь системного администратора, поглощенного упоительным чтением инструкций к своему принтеру. Но это все же нужно делать, т.к. техника стремительно усложняется, и ее возможности становятся уже не такими очевидными и безобидными, как это было еще недавно. Не нужно воспринимать описанное в цикле из двух статей как абсолютную истину. Я не преследовал цель собрать здесь список актуальных уязвимостей, но хотел описать в образовательных целях типичные для принтера опасности. Я намеренно оставил за бортом рассмотрение более традиционных вопросов безопасности из серии «как расшарить принтер в локальной сети только для меня и моего шефа» – все это прекрасно изложено в стандартной учебной литературе. Главная цель статьи – привлечь внимание администраторов к часто игнорируемой проблеме безопасности принтеров и МФУ, дать базовые понятия об этом типе проблем, ибо, как говорил один великий грек: «Быстрее всего настигает та опасность, которой постоянно пренебрегают». EOF 1. Савчук И. Принтер как источник угрозы. Антируководство по взлому локальных сетей. //«Системный администратор», №1‑2, 2012 г. – С. 58-60.

2. Принтерная стеганография – http://en.wikipedia.org/wiki/Printer_ steganography, http://www.cartridgesave.co.uk/news/the-yellowdot-printer-conspiracy.

3. Список протестированных в EFF принтеров и методика обнаружения маркеров – https://www.eff.org/pages/list-printers-whichdo-or-do-not-display-tracking-dots, http://w2.eff.org/Privacy/printers/ docucolor.

4. Юридические компании против скрытой маркировки документов – http://seeingyellow.com, http://brahmsyellowdots.blogspot. com.

5. Отчет о методах перепрограммирования принтеров – http:// www.hacktory.cs.columbia.edu.

6. О подписывании прошивок принтеров – http://www.opennet.ru/ opennews/art.shtml?num=32522.

7. Инцидент взлома CRU – http://ru.wikipedia.org/wiki/Климатгейт.

8. Офисная техника как причина утечек информации – http:// www.opennet.ru/opennews/art.shtml?num=31272.

9. Набор ftp-fuzzer – http://www.infigo.hr/en/in_focus/tools, http:// sourceforge.net/projects/project4n, http://ru.wikipedia.org/wiki/ Metasploit.

10. Основы fuzzing – http://www.infigo.hr/files/INFIGO-TD-2006-04-01Fuzzing-eng.pdf.

11. Praeda Automated Printer Harvesting Tool – http://www.foofus. net/?page_id=218.

12. Язык PJL – http://en.wikipedia.org/wiki/Printer_Job_Language.

13. PJL-утилита Hijetter – http://www.phenoelit-us.org/hp/docu.html, http://packetstormsecurity.org/files/26557/Hijetter_exe.zip.html.

14. HP Download Manager и HP Web Jetadmin – http://bit.ly/zDlTs3, http://bit.ly/vrnvAR. 15. Upgrading HP firmware – http://bizsupport1.austin.hp.com/bc/ docs/support/SupportManual/c01943164/c01943164.pdf.

16. Руководства по безопасности принтеров от HP – http://h20000. www2.hp.com/bc/docs/support/SupportManual/c00746792/ c00746792.pdf, http://www.hp.com/united-states/business/catalog/ nist_checklist.pdf, http://h20424.www2.hp.com/program/wdyhts/ enterpriseprint/sg/en/pdfs/whitepaper/HP_security_solutions.pdf.

март 2012 системный администратор

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

Управление IP-телефонными аппаратами Любой IP-телефон вне зависимости от его реализации (программная или аппаратная) обладает огромным количеством функциональных возможностей. Рассмотрим в статье пример централизованной настройки программных абонентских терминалов для IP-телефонии

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

Лицензирование

Провижнинг

Counterpath X-Lite

Бесплатный

Нет

Counterpath Bria Professional

Платный

Есть*

PortGo

Бесплатный

Нет

3CX iPhone

Бесплатный

Есть**

Pangolin

Бесплатный

Нет

Cisco IP Communicator

Платный

Есть

телефона

системный администратор март 2012

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

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

Отсутствие мобильности Предположим, что пользователь Марина, сотрудник службы по работе с партнерами компании, работает за компьютером pc101. На этом компьютере «полетел» жесткий диск,

69

IP-телефония Особенности настроек некоторых софтфонов Если говорить о софтфонах X-Lite и 3CX, то они хранят свои настройки в ОС Microsoft Windows XP в папке LocalSettings/Application Datа, в ОС Microsoft Windows Vista и 7 в папке AppData/Local. В обоих случаях папки не входят в перемещаемый профиль и не «линкуются» с помощью Folder Redirection. Разве что в реестре пользователя можно изменить путь, но ради одного случая с софтфоном не нужно перемещать 3 Гб данных пользователя (именно столько данных часто хранится в этой папке). Более того, у X-Lite профиль не текстовый, а бинарный. Админу нужно поменять настройку QoS. И что делать? Искать способы «декомпиляции»? У Bria Professional данные хранятся там, где нужно, т.е. в Application Datа/ в XP и в AppData/Roaming в Vista и 7. Однако считаю, что использование перемещаемых профилей как средства хранения и объявления настроек софтфонов не всегда удобно. Есть компании, которые не используют софт, критичный к сохранению данных в профилях. Есть домашняя папка, в которой хранятся документы пользователя, часто это все, что ему нужно. Включать механизм перемещаемых профилей ради одного приложения затратно по времени. Есть компании, которые используют Mandatory Profiles [8]. Профиль в таком случае не сохраняемый и всегда один и тот же. Он определяется админом, всегда загружается с сервера и никогда не изменяется. В конце концов IP-телефония – это приложение, т.е. некий сервис. Вот сидит пользователь и работает, а админ сменил конфигурацию телефонов. Разослал всем сообщение о том, что изменились настройки. И что теперь? Нужно в ОС перевойти. Понятно, что это несложно. А если у пользователя 30 программ открыто? В данной статье предлагается удобный способ избежать всех описанных выше проблем.

и руководитель службы попросил Марину пересесть за компьютер pc102. Но на следующий день из отпуска вышла Дарья, которая всегда сидела за компьютером pc102. Марине пришлось пересесть за компьютер pc103. На каждом из этих ПК потребуется выполнять настройки снова, а это неудобно и только путает пользователя, который к тому же может забыть свой пароль или тот, который ввиду каких-либо причин пришлось поменять. Значит, потребуется снова звонить в ИТ-службу и запрашивать у них пароль для ввода на новой или на всех рабочих станциях, за которыми сидит пользователь. Все это создает немного проблем в сети, скажем, из 20 пользователей, но, когда инфраструктура насчитывает пару сотен рабочих станций, указанные процедуры становятся более частыми и ненужными. Полагаю, что верным решением является следование номера телефона и всех его настроек за самим пользователем независимо от его местонахождения. Причем важно, чтобы простота использования по-прежнему сохранялась: логин в систему, запуск софтфона (без ввода какой-либо дополнительной информации), работа. Никакой перенастройки! Подобно тому, как используется переносная телефонная трубка или сотовый телефон. Такая мобильность номера резко увеличивает эффективность работы, снижает нагрузку на администратора и делает работу более логичной.

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

70

Данная функция обеспечивает аппарат всеми параметрами, которые необходимы для работы: адреса NTPсерверов, диапазон RTP-портов, QoS, dialplan, что отображать на экране телефона (когда трубка опущена – одни софтклавиши, трубка поднята – другие), учетную запись и адрес SIP-сервера для регистрации. А вот что касается софтфонов – тут ситуация сложнее, так как не все представители семейства обладают таким функционалом. Я протестировал следующие варианты (см. таблицу 1). Как видно из таблицы, три программных продукта обладают функционалом, предусматривающим скорее частное, чем корпоративное использование, – все параметры должны храниться локально на компьютере, централизованное конфигурирование отсутствует. А что с остальными?

Counterpath Bria Professional – провижнинг касается только аккаунта пользователя (по крайней мере именно это следует из документации по продукту [1]) – остальные настройки должны вводиться пользователем вручную, требуется управление лицензионной информацией. Софтфон на конкретном компьютере должен «забрать» лицензию на сервере и «убедить» себя в ее корректности, «перемещаемость» номера осуществить затруднительно – пользователю требуется знать дополнительные параметры, чтобы «сказать» серверу, что это именно он.

3CX iPhone – провижнинг осуществляется для большого набора параметров (тут и кодеки и порты настраивать можно), однако непонятно, как решать вопрос с «перемещаемостью» номера.

Cisco IP Communicator – провижнинг осуществляется для всего набора параметров софтфона (точнее сказать, для 99%), «перемещаемость» номера осуществляется простыми настройками, ввода дополнительной информации не требуется. Я отдал предпочтение последнему программному продукту ввиду простоты управления и испытанной надежности решения.

Два слова о лицензировании программного телефона Cisco IP Communicator Согласно документу [5] приобретается право на использование софтфона, с которым покупатель получает ссылку для скачивания ПО. Никакой дополнительной информации, «убеждающей» продукт в правомерности его использования, не требуется. Кроме того, в документе EULA для этого ПО не говорится о том, с каким серверным продуктом следует использовать софтфон (в отличие от других программных продуктов Cisco, например, Cisco VPN-клиент). Я убедился, что данный программный телефон одинаково хорошо работает как с Cisco Call Manager (протокол SCCP), так и со свободно распространяемым IP PBX Asterisk. Итак, можно приступать к описанию параметров решения по администрированию программных абонентских терминалов.

Компоненты решения >> Сеть на основе доменной структуры. Я производил настройку параметров на серверах Microsoft Windows

март 2012 системный администратор

IP-телефония

Организация клиентской части IP-телефонии не должна отличаться от таковой в ее традиционном варианте

Server 2008 и Windows Server 2003 R2. В качестве рабочих станций использовались компьютеры под управлением Microsoft Windows XP Professional SP3, Windows Vista Enterprise и Windows7 Enterprise. >> TFTP-сервер TFTPD32 Service Edition v3.35. >> Версия софтфона Сisco IP Communicator: 7.0.2.0 (далее CIC). >> IP PBX Asterisk 1.6.2.17.2 на базе Centos 5.6 (2.6.18-238. el5). Предполагается, что читатель обладает необходимыми навыками и знаниями для настройки Asterisk, Windows Server 2008 и Active Directory.

Краткое описание схемы работы решения Итак, у нас имеются дистрибутив CIC в виде пакета msi, рабочие станции под управлением Windows XP Professional, два контроллера домена под управлением Windows Server 2008 и сервер с Asterisk под управлением CentOS 5.6 Решение разворачивается и функционирует по следующей схеме: >> Установка CIC. С помощью Active Directory на рабочие станции устанавливается msi-пакет CIC. >> Настройка CIC через реестр. С помощью групповых политик производится настройка параметров реестра, отвечающих за работу установленного пакета на рабочей станции. Если приложение разворачивается для работы всех пользователей домена, то имеет смысл перенести объект групповой политики с настройкой параметров реестра в корень той OU, где «обитают» учетные записи пользователей. >> На обоих контроллерах домена устанавливается TFTPсервер TFTPD32 Service Edition v3.35. (Чуть позже будут даны аргументы в пользу именно такой архитектуры.) В корневой директории TFTP-сервера вручную администратором формируются файлы настройки CIC для каждого пользователя. Формат файлов – xml. В момент запуска на рабочей станции CIC производит соединение со службой TFTP (расположенной на кон-

системный администратор март 2012

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

Подробное описание настроек системы Установка CIC Выполните на контроллере домена следующие действия. >> Запустите консоль управления групповыми политиками (далее gpmc). >> Разверните дерево домена и в ОУ, которая у вас запланирована для установки ПО на компьютеры, создайте объект групповой политики (GPO). Автор назвал этот объект CIC-Software-Install. >> Переходим по адресу «Конфигурация компьютера → Политики → Конфигурация программ → Установка программ». Создайте пакет для установки msi-пакета CIC на рабочие станции. Я предпочел назначенный вариант установки.

Настройка CIC через реестр Можно не дожидаться установки ПО на рабочие станции, а сразу приступить к процедуре конфигурирования. CIC, как и многие другие программные продукты, обладают как общесистемной, так и пользовательской частями реестра. Нас будет интересовать первая часть. Выполните на контроллере домена следующие действия. >> Запустите редактор реестра regedit. >> Перейдите в раздел реестра HKEY_LOCAL_MACHINE/ SOFTWARE. >> Cоздайте раздел со следующим названием: Cisco Systems, Inc. (точка в конце имени обязательна). >> Создайте подраздел Communicator. >> Запустите GPMC.

71

IP-телефония >> В той OU, где у вас находятся учетные записи пользователей, которые будут работать с IP-телефонией, создайте объект GPO. Я назвал этот объект CIC-SoftwareConfigure. >> В созданном GPO зайдите по адресу «Конфигурация Пользователя → Настройка → Конфигурация Windows → Реестр». Создайте параметры типа REG_DWORD с именем «TftpServer1» и «TftpServer2». По этому параметру CIC будет узнавать, к какому TFTPсерверу обращаться за пользовательскими файлами настроек. Здесь следует остановиться подробнее. Описанный способ настройки нетрадиционен. Разработчики Cisco в качестве средства, на которое должен опираться CIC для поиска серверов TFTP, рекомендует использовать DHCP. Для этого на DHCP-сервере задается значение для опции 150, которая как раз предназначена для хранения IP-адреса TFTP-сервера. По этому вопросу позволю себе сказать следующее. Программное обнспечение аппаратных телефонов указанной фирмы удачно справляется с задачей получения адреса серверов TFTP от DHCP-сервера. Однако программный аналог, а именно CIC в той версии, которую я тестировал, решает указанную задачу очень плохо. В разных ОС от Microsoft (XP, Vista, Windows 7) не было обнаружено никакой закономерности в нестабильном поведении CIC при получении адресов серверов TFTP. Адреса то получались, то не получались, перезагрузка компьютера в некоторых случаях решала проблему, однако в большинстве ситуаций процедура заканчивалась появлением сообщения об ошибке: TFTP Server not found, после запуска CIC. В качестве DHCP-сервера тестировали ПО от Microsoft и встроенный DHCP-сервер на базе аппаратного брандмауэра Cisco ASA. Оба варианта не дали результата как в доменной среде, так и при использовании рабочих групп. В противовес рекомендованному методу использование реестра отличает высокая стабильность (сообщение о недоступности серверов tftp при использовании такого приема ни разу не появлялось). Однако этот метод ввиду своей нетрадиционности несет некоторую сложность. Проявляется она вот в чем: >> Во-первых, DNS-имя в параметр реестра TftpServer1 вписывать нельзя. >> Во-вторых, IP-адрес хранится в указанном параметре не в привычной точечно-десятичной нотации, а в перевернутой шестнадцатиричной форме, т.е. первый байт адреса расположен как четвертый, второй как третий, третий как второй и четвертый как первый. Для сисадмина в принципе перевод одной нотации в другую проблем не составляет, однако этот вопрос в случае потребности в изменении адресов необходимо держать в голове и не забывать. Для полноты изложения я все-таки опишу процедуру перевода адреса из десятично-точечной нотации в ту, которая требуется CIC в реестре, на следующем примере: чтобы CIC мог обращаться к TFTP-серверам с адресами 192.168.1.1 и 192.168.1.2, значения параметров реестров TftpServer1 и TftpServer2 должны быть такими: 0101A8C0 и 0201A8C0.

72

Далее: >> В GPO из предыдущего пункта создайте еще один параметр типа REG_DWORD c именем «AlternateTftp». Установите его значение равным 1. Опираясь на этот параметр, CIC «понимает», что следует отказаться от поиска серверов TFTP на основе DHCP, и обращается к адресам, указанным в реестре. >> В той же GPO создайте параметр типа REG_SZ с именем HostName и установите его значение равным «%username%». Именно отсюда CIC берет имя файла с расширением xml, которое будет запрошено с сервера TFTP. Интересный нюанс: не обладая административными полномочиями, на компьютере нет возможности поменять этот параметр, так как он находится в общесистемной ветке реестра. Если же пользователь является локальным администратором, то даже после изменения значения данного параметра на другой за счет механизма обновления групповых политик, рано или поздно значение станет таким, каким было при входе в систему. Отсюда следует немаловажный вывод о том, что вероятность умышленной диверсии типа «Маша получила номер Даши, и звонки стали уходить в неверном направлении» сводится к минимуму, что очень близко к традиционной аналоговой телефонии, где пользователь не может изменять номера портов АТС. На этом настройку параметров CIC через реестр можно считать законченной. Перейдем к настройке сервера TFTP.

Настройка сервера TFTP Здесь позволю себе привести аргументы в пользу той архитектуры, которая была изложена в кратком описании (см. выше). Итак, роль TFTP-серверов играют у нас контроллеры домена. Почему они, а не, скажем, сервер, на котором расположена служба Астериск? Первая причина – это простота использования и избавления от регистрозависимости. Дело в том, что пользователи часто вводят свой логин в верхнем регистре, и именно таким он записывается в параметр HostName (см. выше) в реестр. Если мы располагаем TFTP-службу на Linux-сервере, где находится Астериск, а файлы конфигурации телефонов, расположенные в корневом каталоге TFTP-службы, имеют имена в нижнем регистре, то софтфон не получит нужного файла, поскольку будет сформирован запрос вида «Отдай мне файл USERNAME.xml», которого с точки зрения операционной системы Linux не существует. Эту проблему решить можно так называемым ремапом (remap) в настройках службы in.tftpd. А вот расположив TFTP-службу на сервере с ОС Windows, о таких сложностях думать не нужно вовсе. Переходим ко второй причине – резервному копированию конфигураций софтфонов. Безусловно, если сеть у нас большая и приложение телефонии является критичным для компании, то серверов телефонии на базе Астериск должно быть больше одного (то же касается и CUCM или CUCME при организации телефонии на оборудовании Cisco). Стало быть, логично расположить конфигурации на обоих серверах. И тут сразу встает вопрос о синхронизации этих самых конфигураций. В принципе решить его можно, используя rsync и ssh, однако, возложив работу по синхро-

март 2012 системный администратор

IP-телефония низации на контроллеры домена, администратор освобождает себя от еще одной службы, которую нужно настраивать и «допиливать» и за которой впоследствии придется следить. Созданные в подкаталоге каталога netlogon на контроллере домена файлы конфигурации («вес» каждого составляет примерно 7 Кб) благодаря встроенному механизму файловой репликации через несколько секунд окажутся на втором контроллере. Проблема резервного копирования и недоступности сервера – поставщика информации для телефонов решается автоматически. Итак, перейдем к настройке. Устанавливаем на обоих контроллерах службу TFTPD32 Service Edition v3.35. Затем отключаем все ненужные компоненты этого приложения, как-то Syslog-сервер, DHCP-сервер. Оставляем только TFTP-сервер. В интерфейсе управления в качестве Base Directory указываем локальный путь к подпапке, расположенной в папке netlogon на данном контроллере домена. Скажем, подпапку можно назвать «voip-configurations». После создания такого подкаталога на одном контроллере он благодаря механизму репликации автоматически будет создан на другом, поэтому аналогичной процедуры на втором сервере не требуется. С настройкой TFTP-сервера закончили. Перейдем к формированию конфигурационных файлов для телефонов. Файл с настройками телефона должен иметь следующее имя: logonname.cnf.xml, где logonname – логин пользователя в Active Directory. Весь набор настроек в xml-файле можно посмотреть в источниках [6, 7].

Настройка Астериск В директории /etc/asterisk откройте файл sip.conf на редактирование и создайте следующий шаблон: [office](!) type=friend nat=no host=dynamic context=context1 language=ru context=tensor-out dtmfmode=rfc2833 callgroup=1 pickupgroup=1 disallow=all allow=g729 allow=alaw allow=ulaw qualify=yes directmedia=no subscribecontext=subscribe

А далее можно создать номера по следующему примеру: [101](office) username=101 secret=123456 [102](office) username=102 secret=78910

После создания номеров выполните перезагрузку SIPмодуля Asterisk – sip reload.

системный администратор март 2012

*** Процедура выделения номера сотруднику компании:

>> Поступает запрос в ИТ-службу о выделении номера новому сотруднику Ивановой М.А. (учетная запись для пользователя в домене уже создана). >> Осуществляется поиск свободного номера для данного отдела. >> Создается экстеншн на SIP-сервере. >> Формируется файл на контроллере домена domaincontroller1 по адресу \\domaincontroller1\netlogon\ voip-configurations\ivanovama.cnf.xml, в котором прописываются номер телефона Ивановой М.А., пароль для регистрации на SIP-сервере и все необходимые настройки для телефона. >> Тикет закрывается с просьбой к пользователю запустить софтфон и пометкой «Готово». >> Через 60 секунд Иванова М.А. может начать работу, видя на экране свой номер и свой логин.

P.S.: Тем, кто применяет Cisco Unified Communication Manager, предлагаемое решение понадобится, если они используют не аппаратные, а программные абонентские терминалы (CIC). По умолчанию при запуске софтфон пытается найти файл SEPMAC-ADDRESS.cnf.xml., где MAC-ADDRESS – это адрес компьютера, где запущен софтфон. Можно сгенерировать с помощью веб-интерфейса CUCM шаблон, создать по его образу и подобию файлы с именем логина пользователя и вынести сервис tftp за пределы CUCM. Предоставленное решение, если сравнивать с аппаратным, получается дешевле более чем в два раза, ведь аппарат такого класса от Cisco, например, 7940G стоит от 6000 до 9000 руб. EOF 1. Подробный мануал по провижнингу CounterPath Bria Professional – http://www.counterpath.com/assets/files/189/ Provisioning_Bria_Professional_2.5_Retail_Edition_R2.pdf.

2. Частичный мануал по провижнингу 3Cx iPhone – http://www.3cx. com/forums/documentation-on-automatic-provisioning-19032. html.

3. FAQ по Cisco IP Communicator – http://www.cisco.com/en/ US/docs/voice_ip_comm/cipc/8_5/english/frequently_asked_ questions/b_CIPCfaq_olh.html.

4. EULA для Cisco IP Communicator – http://www.cisco.com/en/US/ docs/voice_ip_comm/cipc/CIPC_Licensing_Doc.html.

5. Вопросы и ответы по продукту Cisco IP Communicator – http:// www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ ps5475/prod_qas09186a00801f7ad8.html.

6. Конфигурирование IP-телефонов Cisco и Астериск – http:// www.voip-info.org/wiki/view/Asterisk+phone+cisco+79xx.

7. Конфигурирование IP-телефонов Cisco и Астериск – http:// www.minded.ca/default/2009-12-16/configure-cisco-ip-phoneswith-asterisk.

8. Описание механизма работа Mandatory Profiles – http:// msdn.microsoft.com/en-us/library/windows/desktop/ bb776895(v=vs.85).aspx.

73

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

технологии

Визитка Кирилл Сухов, веб-программист в дистрибьюторской компании MICS. Занимается проектированием и разработкой различных интернет-сервисов. Круг интересов банален – веб-технологии, RIA, Framework-среды

HTML5 – технология будущего Продолжаем погружение

В первой статье о HTML5 [1] я пытался сделать «путеводитель по технологии», пусть и недостаточно полный. Осознаю свою ошибку: во-первых, тема слишком обширна. Во-вторых, революция HTML5 идет прямо сейчас, стандарт далек от того, чтобы быть сформированным окончательно. Предлагаю рассмотреть интересные моменты

Храним данные на клиенте WebStorage/WebSQL/ WebNoSQL Сохранение данных на стороне клиента – давняя проблема веб-разработки. Решается она в настоящее время с помощью механизма HTTP cookie, но любой веб-разработчик, сталкивающийся, например, с проблемой сохранения состояний сложного пользовательского веб-интерфейса и подобных вещей, знает, сколько проблем связано с применением cookie. Прежде всего cookies имеют по умолчанию маленький размер, у них отсутствует привязка к сеансу работы (например, cookies с достаточно длительным периодом действия могут пережить перезагрузку браузера, даже если это бессмысленно в рамках данного веб-приложения). В конце концов cookies просто не надежны.

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

Session Storage – сохраняет данные в контексте сеанса работы пользователя (сессии). На практике это обозначает, что данные хранятся до закрытия окна или вкладки браузера. Работа с Session Storage осуществляется посредством следующих методов: sessionStorage.setItem('name','Vasya'); …......................................................... var name = sessionStorage.getItem('name'); sessionStorage.removeItem('name');

Local Storage – хранит данные в контексте домена, «запоминая» их между сеансами. Методы у него, естественно, такие же: localStorage.setItem('title','Vasya'); …......................................................... var name = localStorage.getItem('title'); localStorage.removeItem('title');

74

Кроме того, оба объекта имеют метод clear() для удаления всех пар «ключ/значение» и свойство length, представляющее собой количество сохраненных пар (правда, не следует рассматривать объект Local Storage как массив). Еще один интерфейс – WebStorage Event – определяет событие storage, возникающее при изменении состояния хранилища ( setItem() или clear()). Объект Storage Event предоставляет следующие свойства события: key – ключ, затронутый изменением; oldValue – старое значение ключа; newValue – новое значение ключа; url – адрес страницы на сервере; storageArea – тип хранилища (Session Storage или Local Stotage). Доступ к этим свойствам можно получить следующим образом: <body onstorage = 'storageInfo()' > <script> function storageInfo(e){ var message = 'Страница '+e.url+ ' поменяла ↵

значение '+e.key; message += ' с '+e.oldValue+' на '+e.newValue; console.log(message); } </script> </body>

Впрочем, на хранилище пар «ключ/значение» возможности HTML5 по сохранению информации на стороне клиента не заканчиваются. Для хранения структурированных данных предназначена технология WebSQL. WebSQL DB – это API для доступа к полноценному SQLхранилищу данных, основанному на SQLite. Впрочем, последнее обстоятельство – скорее особенность реализации и стандартом не оговаривается, хотя диалект SQL используется именно от SQLite. (Вообще использование SQLite в веб-браузере – практика не новая: Firefox и Chrome давно применяют эту компактную СУБД для хранения настроек, паролей, закладок.)

март 2012 системный администратор

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

технологии Работает этот механизм так: var db = openDatabase('my_db','1.0','test',2*1024*1024, ↵

function(){ console.log('БД открыта!') } , function(){ console.log('новая БД!') } );

Код создает объект для взаимодействия с базой данных. Если БД с таким именем не существует, она будет создана. Аргументы метода следующие: >> имя БД; >> версия БД; >> видимое название; >> объем БД (предполагаемый); >> функция обратного вызова, вызываемая при успешном открытии; >> функция обратного вызова, вызываемая при создании новой БД; Далее делаем запросы, оборачивая их в транзакцию: db.transaction( function(t){ t.executeSql( 'SELECT title FROM documents', [], ↵

function(){ }); }

Функция получает аргумент – объект транзакции (transaction object), вторым аргументом метода которого executeSql (обязателен только первый – строка запроса) является массив аргументов для запроса, подставляемых в него вместо знаков '?' (плейсхлодеров): db.transaction( function(t){ t.executeSql( 'INSERT INTO documents ( title, type ) ↵

VALUES (?, ?)', ['Order',3]); }

Чтение сохраненных значений производится из полей объекта набора значений, возвращаемого в результате соответствующего SQL-запроса:

t.executeSql( 'SELECT title FROM documents WHERE ↵ created < ?' , [min_create], ↵ function(t, result){ for(i=o; i < result.rows.length; i++){ doc_name = result.rows.item(i).title; console.log( doc_name); } });

var db = window.openDatabase("CandyDB", "1", ↵

"My candy store database", 1024); db.transaction(function(tx) { for (var index = 0; index < kids.length; index++) { var kid = kids[index]; tx.executeSql("INSERT INTO kids (name) VALUES ↵

(:name);", [kid], function(tx, results) { document.getElementById("display").textContent = ↵ "Saved record for " + kid.name + ↵ " with id " + results.insertId; }); } });

IndexedDB: var kids = [ { name: "Anna" }, { name: "Betty" }, { name: "Christine" } ]; var request = window.indexedDB.open("CandyDB", ↵

"My candy store database"); request.onsuccess = function(event) { var objectStore = event.result.objectStore("kids"); for (var index = 0; index < kids.length; index++) { var kid = kids[index]; objectStore.add(kid).onsuccess = function(event) { document.getElementById("display").textContent = "Saved record for " + kid.name + " with id " + ↵

event.result; }; } };

AppCache – управляем кэшированием вплоть до полного offline! Кэширование в браузере – совершенно необходимый в современном мире механизм, который еще менее надежен и предсказуем, чем вышеупомянутые HTTP cookies. HTML5 предполагает технологию кэширования ресурсов, в которой процесс целиком и полностью контролируем разработчиком. Это кэш приложений (AppCache) и API доступа к нему, позволяющий манипулировать загрузкой ресурсов и доступа к ним, в том числе в отсутствие связи с сервером. Управление кэшированием в AppCache осуществляется посредством деклараций в файле манифеста. Это простой Рисунок 1. Отображение на странице миниатюры выбранных на локальном компьютере изображений

Нельзя не упомянуть еще об одной технологии, так или иначе относящейся к данной теме, – IndexedDB. Это хранилище объектов или, если хотите, объектная СУБД для Web. По сути, это те же таблицы, типы данных, транзакции, курсоры, но вместо языка запросов там применяются методы доступа. Разницу подходов хорошо иллюстрирует пример с сайта одного из разработчиков IndexedDB, Mozilla.org: WebDatabase: var { { { ];

kids = [ name: "Anna" }, name: "Betty" }, name: "Christine" }

системный администратор март 2012

75

Программирование текстовый файл, расположенный в месте, доступном для вебприложения. Ниже приведен пример файла манифеста: CACHE MANIFEST CACHE: style/default.css images/sound-icon.png images/background.png NETWORK: comm.cgi FALLBACK: main_image.jpg backup_image.jpg

Все ресурсы, перечисленные в секции CACHE, всегда, кроме случаев начальной загрузки или перезагрузки вследствие изменения манифеста, будут загружаться не из сети, а с локального AppCache. Секция NETWORK, напротив, предполагает загрузку только с веб-сервера. Запись в секции FALLBACK означает, что при отсутствии доступа к серверу вместо ресурса main_image.jpg будет загружен сохраненный в AppCache файл backup_image.jpg. Как видите, все довольно просто. При использовании AppCache надо четко представлять, что этот механизм и обычный кэш браузера существуют независимо друг от друга. В частности, это означает, что данные, не упомянутые в манифесте, вполне могут сохраниться в кэше браузера. Связать манифест с HTML-документом можно, указав файл манифеста в качестве атрибута тега <html>: <html manifest="main.manifest">

Кроме того, необходимо сообщить веб-серверу правильный MIME-тип для манифеста. Например, для Apache это можно сделать, добавив в файл .htacces строчку: AddType text/cache-manifest .manifest

При изменении файла манифеста данные в AppCache целиком обновляются (загружаются заново). Для динамического управления процессом кэширования введен новый DOM-объект – window.applicationCache. Основное его свойство – applicationCache.status, и в процессе работы веб-приложения оно может принимать следующие значения: 0 – uncached – страница не имеет записей в кэше приложений. Этот статус будет возвращен и при первой загрузке страницы; 1 – idle – нет обновленных версий, в AppCache – самая новая; 2 – checking – идет проверка наличия обновленного файла манифеста; 3 – downloading – загрузка нового кэша; 4 – updateready – обновленный кэш готов к использованию; 5 – obsolete – файл манифеста отсутствует – кэш приложений теперь признан устаревшим и подлежит удалению. Переходу в любое из этих состояний соответствует событие объекта applicationCache, на которое возможно «навесить» обработчики (например, onupdateready, onobsolete).

76

технологии ApplicationCache обладает следующими методами, позволяющими динамически обновлять кэш и контент: applicationCache.update() – в случае изменения файла манифеста метод перезагружает кэш приложения в соответствии с новыми декларациями. При этом веб-приложение продолжает использовать старый кэш; applicationCache.swapCache() – сбрасывает старый кэш, заставляя приложение использовать ресурсы из AppCache, обновленного методом update(); applicationCache.abort() – прерывает связь приложения с AppCache. Работает все это следующим образом: setInterval(function () { do_update(); }, 1000000 ); function do_update() { cache = window.applicationCache; console.info("Cache updating... " + cache.status);

}

try { cache.update(); if (cache.status == cache.UPDATEREADY) { cache.swapCache(); } } catch (e) { console.error(e); }

Впрочем, если страница часто перезагружается, будет достаточно следующего кода: window.applicationCache.addEventListener('updateready', function(){ window.applicationCache.swapCache(); }, false );

AplicationCache.update должен вызываться автоматически при перезагрузке страницы.

File API – Ура! Свершилось! В HTML давно существует тип file элемента input, предназначенный для загрузки файлов на сервер. В целях обеспечения безопасности возможности этого элемента крайне ограничены (это очень мягко сказано) – можно произвести только одно действие: выбрать файл в локальной файловой системе, который при отправке формы будет загружен на целевой сервер. Безопасность – это важно (о ней мы еще поговорим), но жизнь диктует новые требования, и недостающий функционал для работы с локальными файлами просто не мог не появиться. Сейчас на небольшом примере мы рассмотрим новые возможности. Задача – отображать на странице миниатюры выбранных на локальном компьютере изображений. Для этого создадим такую HTML-разметку: <input type="file" id="myFile" name="myFile" /> <br> <div id="gallery"></div>

Зададим стили для будущих иконок (по сути, создадим класс):

март 2012 системный администратор

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

технологии <style> .icon { height: 75px; margin: 10px; } </style>

Теперь начнем использовать новое API. Сначала создадим функцию – обработчик выбора файла: function handleFileSelect(evt) { var files = evt.target.files; if(files[0].type.substr(0, 5) !== 'image'){ alert(“Файл не является рисунком!”); return false; } console.log(files[0].name); var reader = new FileReader(); reader.onload=function(e){ var span = document.createElement('span'); span.innerHTML = ['<img class="icon" src="', ↵

e.target.result,'" title="', ↵

files[0].name, '"/>'].join(''); document.getElementById('gallery').↵

insertBefore(span, null); } reader.readAsDataURL(files[0]); }

Осталось связать эту функцию с элементом input: <script> document.getElementById('myFile').addEventListener( ↵

'change', handleFileSelect, false); </script>

И проверить работу нашего приложения (см. рис. 1). Ну а теперь разберемся, что мы наделали и как это все работает. Прежде всего в строчке: var files = evt.target.files;

В переменную files мы получаем объект (класса) FileList, представляющий собой массив объектов File. В данном случае это массив из одного элемента, но мы это исправим ниже. А пока рассмотрим еще один объект (если точнее – интерфейс) – FileReader (названный так, наверное, чтобы возродить слегка подзабытую путаницу с Java/JavaScript).

FileReader, как нетрудно догадаться из его названия, предназначен для чтения содержания файла. Для этого у него есть следующие методы: FileReader.readAsBinaryString(Blob|File) – чтение в бинарном режиме. Результат будет содержать строку байтов.

FileReader.readAsText(Blob|File, opt_encoding) – текстовый режим. Результатом будет текстовая строка в заданной кодировке (по умолчанию – UTF-8).

FileReader.readAsDataURL(Blob|File) – чтение содержимого файла в виде специального URL (результат – не строка, а объект dataURL!).

FileReader.readAsArrayBuffer(Blob|File) – результат – данные в виде ArrayBuffer (общий контейнер фиксированной длины для бинарных данных).

FileReader также поддерживает обработку следующих событий: loadstart – вызывается в момент начала чтения файла;

системный администратор март 2012

load – происходит после прочтения файла; abort – происходит при отмене чтения; error – происходит при ошибке чтения; loadend — происходит при завершении процесса чтения, вне зависимости от результата; progress – вызывается в процессе чтения файла. Теперь, я думаю, все понятно. Еще одно приятное новшество позволит воплотить в жизнь множественную загрузку файлов. Это атрибут multiple у тега input: <input type="file" id="myFile" name="myFile" multiple />

И теперь, когда FileList может содержать более одного элемента, немного модернизируем handleFileSelect: function handleFileSelect(evt) { var files = evt.target.files; for (var i = 0; files[i]; i++) { var reader = new FileReader(); fileName = files[i].name; reader.onload=function(e){ var span = document.createElement('span'); span.innerHTML = ['<img class="thumb" src="', e.target.result,'" title="test"/>'].join(''); document.getElementById('gallery').insert ↵

Before(span, null); } reader.readAsDataURL(files[i]); } }

FileSystem API Это уже совершенно новый уровень работы с файлами. Со способами хранить информацию на стороне клиента мы уже сталкивались – это и Web Storage, и webSQL/IndexedDB, и даже в определенном смысле cookies. Операции с файлами и файловой системой – тоже один из этих способов, но, как можно понять, принципиально другого назначения. С помощью данного API веб-приложение может создавать, читать, перемещать и удалять бинарные объекты больших размеров, организованные в настоящую файловую систему. Ключевым объектом данного API является FileSystem, представляющий собой локальную файловую систему с возможностью создания, удаления, чтения и изменения файлов и директорий. Получить данный объект мы можем с помощью следующей конструкции: window.requestFileSystem(type, size, onInitFs, onError);

где: type – тип хранения файловых ресурсов. Может принимать значения TEMPORARY (ресурсы могут быть удалены при нехватке свободного места) и PERSISTENT (данные удаляются только явным образом – пользователем или приложением); size – размер файловой системы (в байтах); onInitFs – функция, вызываемая при удачном создании файловой системы. Получает аргумент – объект FileSystem; onError – функция, вызываемая при ошибке. Аргумент – объект FileError. Вот с FileError лучше разобраться подробнее. Вместо его описания напишем сразу реализацию функции errorCallback:

77

Программирование function onError(error) { var msg = ''; switch (error.code) { case FileError.ABORT_ERR: msg = 'Операция прервана'; break; case FileError.NOT_READABLE_ERR: msg = 'Файл нечитаем'; break; case FileError.ENCODING_ERR: msg = 'Проблемы с кодировкой'; break; case FileError.QUOTA_EXCEEDED_ERR: msg = 'Превышен объем хранилища'; break; case FileError.NOT_FOUND_ERR: msg = 'Файл не найден'; break; case FileError.SECURITY_ERR: msg = 'Небезопасная или недопустимая операция'; break; case FileError.NO_MODIFICATION_ALLOWED_ERR: msg = 'Невозможно изменить файл'; break; case FileError.INVALID_MODIFICATION_ERR: msg = 'Ошибка изменения файла'; break; case FileError.INVALID_STATE_ERR: msg = 'Ошибка состояния'; break; case FileError.SYNTAX_ERR: msg = 'Ошибка cинтаксиса'; break; case FileError.TYPE_MISMATCH_ERR: msg = 'Неприемплимый тип файла'; break; case FileError.PATH_EXISTS_ERR: msg = 'Файл уже существует'; break; default: msg = 'Неизвестная ошибка'; break; }; alert(msg); }

Все, к ошибкам больше не возвращаемся. Теперь будем творить обещанные операции с файловой системой. В предыдущем примере функция onInitFs() получает объект FileSystem, соответствующий инициированной файловой системе. Создание файла будет проходить так: function onInitFs(fs) { fs.root.getFile('log.txt', {create: true}, ↵

function(fe) { alert(fe.isFile); }, onError);

Рисунок 2. Теперь плашки с цифрами можно двигать мышью, а в случае использования сенсорного монитора – пальцами

78

технологии Метод geFile() создает в корне образованной файловой системы (а других папок еще не существует) файл log.txt. Анонимная функция обратного вызова здесь принимает в качестве аргументов объект (интерфейс) FileEntry, имеющий все методы и свойства обычного файла. Например, простенький эксперимент (используется браузер Google Chrome, в других результат может отличаться): var keys = Object.keys(fe); for (var i = 0, key; key = keys[i]; ++i) { console.log(key+" - "+fe[key]); }

даст следующий минимальный набор: >> isFile – true; >> Filesystem – [object DOMFileSystem]; >> fullPath – /log.txt; >> name – log.txt; >> isDirectpry – false. Другие свойства, например размер или тип, появятся у файла при записи в него какого-либо содержимого. Теперь запишем что-нибудь в созданный файл: fs.root.getFile('log.txt', {}, function(fe) { fe.createWriter(function(fw) { fw.onwrite = function(e) { console.log('Запись завершена'); };

fw.onerror = function(e) { console.log('Write failed: ' + ↵ e.toString()); }; var blob = new BlobBuilder(); blob.append('FilesystemAPI work!'); fw.write(blob.getBlob('text/plain')); }, onError); }, onError);

Для записи мы используем интерфейс FileWriter. Для формирования будущего содержания создаем объект BlobBuilder, представляющий собой объект BLOB. После добавления в него строки текста осуществляем запись. Чтение осуществляется проще. Используем уже знакомый нам FileReader: fe.file(function(file) { var reader = new FileReader(); console.log(file);

Рисунок 3. Теперь перемещение визуально оформлено, но пока от этого не очень много толку, нужно реальное перемещение

март 2012 системный администратор

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

технологии

});

reader.onloadend = function(e) { console.log(this.result); } reader.readAsText(file);

Теперь, когда мы из браузера произвели запись и выполнили чтение из святая святых – файловой системы на компьютере пользователя, самое время поговорить о безопасности новой технологии. Впрочем, тут все довольно стандартно и уже опробовано на подходе к работе с ресурсами в некоторых RIA, например, Google Native Client, – реализована концепция «песочницы», при которой браузер получает доступ только к тем файловым ресурсам, которые сам же и создал. Соответственно и процессы ОС в общем случае не имеют доступа к созданным браузером файлам и папкам/директориям. Безопасна ли подобная модель? Время покажет, а пока продолжим. Для полноты картины удалим файл: fs.root.getFile('log.txt', {create: false}, ↵ function(fileEntry) { fileEntry.remove(function() { console.log('Файл удален'); }, errorHandler); }, errorHandler);

Теперь попробуем сотворить то же с директориями: function onInitFs(fs) { fs.root.getDirectory('MyDir', {create: true}, function(de) { console.log('Директория создана'); }, onError ) }

Здесь – объект DirectoryEntry, реализующий, как и FileEntry, интерфейс Entry. Продемонстрируем и аналог FileReader – DirectoryReader. Сначала создадим несколько файлов в нашей новой директории: fs.root.getFile('/MyDir/log2.txt', {create: true}, ↵ function(fn) { }, onError); fs.root.getFile('/MyDir/log3.txt', {create: true}, ↵

function(fn) { }, onError); fs.root.getFile('/MyDir/log4.txt', {create: true}, ↵

function(fn) { }, onError);

Все это drag-n-drop! Такой простой и эффективный метод работы с объектами пользовательского интерфейса, как перетаскивание их мышью, давно используется веб-программистами. До настоящего времени данный эффект наиболее удачно реализовывался посредством JavaScript-библиотек, таких как jQuery или ExtJS, или ручного манипулирования DOM-объектами. В стандарт HTML5 поведение drag-n-drop включено изначально. Реализуется оно новым атрибутом «draggable» и рядом событий на каждый этап действий по перемещению объектов. Всего их семь: dragstart – событие начала перетаскивания объекта. drag – перемещение объекта. dragenter – событие вызывается, когда перетаскиваемый объект попадает на объект-приемник. dragleave – перетаскиваемый объект покидает объектприемник. dragover – событие вызывается во время перемещения перетаскиваемого объекта над объектом-приемником. drop – событие вызывается, когда перемещаемый объект попадает на объект-приемник и пользователь отпускает кнопку мыши (событие объекта-приемника). dragend – пользователь перестает перетаскивать объект. В отличие от drop это событие наступает для перетаскиваемого объекта. Это все, но давайте попробуем сотворить с этим набором что-нибудь полезное. Прежде всего нам нужны визуальные объекты, а значит, HTML-разметка и сопоставленные ей стили. Создадим объекты: <style>

.column { height: 36px; width: 36px; float: left; border: 2px solid #6666ff; background-color: #ccc; margin: 5px; border-radius: 10px; text-align: center; cursor: move; } .tr { height: 180px; width: 40px; border: 1px solid black; background-color: #ddd; margin-top: 120px;

Теперь считаем содержимое: fs.root.getDirectory('MyDir', {}, function(de) { var dirReader = de.createReader(); dirReader.readEntries(function(results) { for(i =0;results[i];i++ ){ alert(results[i].name); } }); // alert(dirReader.readEntries()); //console.log()? }, onError);

Рисунок 4. Реальное перемещение объектов

Тут results – массив, элементы которого – объекты FileEntry. Наверное, многих обрадует новость о том, что, помимо метода remove(), у DirectoryEntry есть еще метод removeRecursively. Есть также методы для перемещения и переименования каталогов и файлов – moveTo.

системный администратор март 2012

79

Программирование }

border-radius: 10px;

</style> <div id="columns"> <div class="column">1</div> <div class="column">2</div> <div class="column">3</div> <div class="column">4</div> <div class="column">5</div> <div class="column">6</div> <div class="column">7</div> </div> <div class="tr"> </div>

Наша задача – обеспечить возможность перемещать квадратики с цифрами внутрь большого прямоугольника в произвольном порядке (возможно, это будет что-нибудь вроде игры или головоломки). Начнем с того, что обеспечим саму возможность перетаскивать объекты мышью (здесь и далее мы будем использовать библиотеку jQuery – исключительно для сокращения объема кода). Никакие плагины вроде Draggable из jQuery UI тут не применяются. <script src="https://ajax.googleapis.com/ajax/libs/ ↵

jquery/1.7.0/jquery.min.js"></script> <script> $(document).ready(function () { $(".column").attr('draggable', 'true'); } </script>

Такой же эффект даст: <div class="column" draggable=true>

Теперь плашки с цифрами можно двигать мышью (см. рис. 2), а в случае использования сенсорного монитора – пальцами (к слову, свойство draggable установлено по умолчанию для таких объектов, как изображение или гиперссылка). Не будем останавливаться на достигнутом и начнем продвигаться к цели, используя вышеописанную событийную модель. Сначала займемся началом перемещения: $(".column").each(function(){ this.addEventListener('dragstart', ↵

handleDragStart,false); });

Рисунок 5. Перенос плашки с одного окна браузера на другое

технологии Пока просто сделаем перемещаемый объект полупрозрачным: function handleDragStart(e) { this.style.opacity = '0.4'; return false;

}

Теперь обозначим целевую область перемещения. У нас это div с id "tr". Снабдим его обработчиком событий onDragenter и onDragleave:

$(".tr").each(function(){ this.addEventListener('dragenter', ↵ handleDragEnter, false); this.addEventListener('dragleave', ↵ handleDragLeave, false); });

теперь создадим класс over, определяющий целевую область в момент нахождения над ней перетаскиваемого объекта (ее необходимо «подсветить» просто для удобства): .over {

border: 2px dashed #000; } var inCont = 0; function handleDragEnter(e) { $(this).addClass('over'); return false; inCont = 1; } function handleDragLeave(e) { $(this).removeClass('over'); inCont = false; }

Использование глобальной переменной inCont (это флаг, означающий нахождение перетаскиваемого объекта над объектом-приемником, он нам понадобится в дальнейшем), конечно, не лучшее решение, но сейчас для нас важен не стиль JavaScript-программирования. Теперь перемещение визуально оформлено (см. рис. 3), но пока от этого не очень много толку, нужно реальное перемещение. Тут нам на помощь придет новый объект dataTransfer, который хранит данные при перетаскивании объекта. Для его использования чуть-чуть модифицируем handle DragStar: function handleDragStart(e) { e.dataTransfer.effectAllowed = 'move'; e.dataTransfer.setData('text/html', this.outerHTML); this.style.opacity = '0.4'; return false; }

Теперь в dataTransfer у нас хранится код перетаскиваемого объекта. Далее нужно обработать событие drop: $(".tr").each(function(){ …. this.addEventListener('drop', handleDrop, false); }); function handleDrop(e) { var obj = e.dataTransfer.getData('text/html'); $(this).append(obj); $(this).removeClass('over'); }

80

март 2012 системный администратор

технологии И добавим обработку окончания перетаскивания: $(".column").each(function(){ this.addEventListener('dragstart', ↵

handleDragStart,false); this.addEventListener('dragend', handleDragEnd, false); }); function handleDragEnd(e) { e.srcElement.style.opacity = '1.0'; if(inCont == true){ $(e.srcElement).remove(); inCont = false; } $(this).removeClass('over'); }

Собственно, все. Правда, скорее всего ничего не работает, но это мы сейчас исправим. Дело в том, что в большинстве браузеров поведение при прекращении перетаскивания объекта реализовано по умолчанию (например, картинка, перенесенная с рабочего стола, раскроется, а div draggable вернется на прежнее место). Исправим это, используя preventDefault():

$(".tr").each(function(){ …. this.addEventListener('dragover', ↵ handleDragOver, false); this.addEventListener('drop', handleDrop, false); }); function handleDragOver(e) { if (e.preventDefault) { e.preventDefault(); } e.dataTransfer.dropEffect = 'move'; }

Теперь объекты перемещаются (см. рис. 4), и самое время задаться вопросом, зачем вообще все это, если с jQuery, MooTools или ExtJS все гораздо проще и красивее? Дело в том, что drag-n-drop, осуществляемый через атрибуты style и position DOM-элемента (а именно его используют вышеперечисленные библиотеки), и только что реализованное нами поведение имеют принципиальную разницу. Мы сделали настоящее перемещение с задействованием буфера обмена, а не имитацию его посредством стилей. Чтобы убедиться в этом, проведем небольшое испытание. Сначала чуть изменим handleDragEnd: function handleDragEnd(e) { e.srcElement.style.opacity = '1.0'; if((inCont == 1)|| (e.x < 0)){ $(e.srcElement).remove();

Таким образом, мы добавили случай выхода за пределы браузера (правда, только с одной стороны, это исправимо). Теперь откроем наш пример в двух окнах браузера и попробуем перетащить плашки с одного на другое. У меня получилось (см. рис. 5); для наглядности я сделал копию странички с другим классом для плашек. Чтобы дать окончательное понимание «подлинного» drag-n-drop и возможностей объекта dataTransfer, попробуем реализовать пример, посвященный FileAPI, через перетаскивание файлов мышкой. Для этого перепишем функцию handleDrop:

системный администратор март 2012

Программирование function handleDrop(e) { files = e.dataTransfer.files; var reader = new FileReader(); reader.onload=function(e){ var span = document.createElement('span');

span.innerHTML = ['<img class="icon" src="', ↵

e.target.result,'" title="', files[0].name, ↵

'"/>'].join(''); document.getElementById('gallery').↵

insertBefore(span, null); } reader.readAsDataURL(files[0]); }

Теперь можно грузить изображения мышью (я убрал плашки и добавил класс icon и div id=”gallery”). Этот скрипт легко модифицировать для мультизагрузки – оставляю это читателю в качестве упражнения. Я же добавлю выгрузку изображений на сервер (иначе наша галерея исчезнет с нажатием кнопки <F5>): function upload(file) { var reader = new FileReader(); reader.onload = function() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function () { if (this.readyState == 4) { if (this.status == 200) { console.log("Загрузка завершена!") return 1; } else { console.log("Ошибка!"); return 0; } } }; xhr.open("POST", "/upload.php"); var boundary = "testtest"; xhr.setRequestHeader("Content-Type", "multipart/ ↵

form-data, boundary=" + boundary); var body = "--" + boundary + "\r\n"; body += "Content-Disposition: form-data; name= ↵

'myFile'; filename='" + file.name + ↵

"'\r\n"; body += "Content-Type: application/octet-stream\ ↵

r\n\r\n"; body += reader.result + "\r\n"; body += "--" + boundary + "--"; xhr.send(body); }; reader.readAsBinaryString(file); }

Эту функцию можно вызвать, например, здесь: function handleDrop(e) { files = e.dataTransfer.files; if( upload(file[0]) { …

Ну а как реализовать upload.php, я думаю, объяснять нет необходимости. Все, визуальный загрузчик готов, а мы продолжим наши странствия по HTML5, но в следующей статье. EOF 1. Сухов К. HTML5 уже с нами. Неполный путеводитель по технологии. //Приложение «Веб-технологии» – «Системный администратор», №9, 2011 г. – С. 8-11.

2. Текущая спецификация HTML5 – http://dev.w3.org/html5/spec.

3. WebSQL Database – http://www.w3.org/TR/webdatabase.

4. IndexedDB – https://developer.mozilla.org/en/IndexedDB. 5. HTML5 API по-русски – http://html5man.blogspot.com.

81

Карьера/Образование

ит-управление

Визитка Константин Кондаков, работает старшим директором по ИТ в сан-францисской фирме Certain Software, обеспечивает бесперебойную работу центров данных и руководит системными администраторами в США, Великобритании и Австралии

Информационные тромбы

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

Правило первое. Кадры решают все Знаменитое сталинское выражение «кадры решают все» я бы поставил самым первым в списке приоритетов ИТдиректора. Понятно, что умный, опытный и эрудированный в обширном диапазоне самых разных информационных технологий системный администратор – это находка для любого отдела информационных систем. Речь сейчас о другом. Почему-то априори считается, что человек, нанимающийся на работу в китайский ресторан, должен понимать, что такое соевый соус, а любой сотрудник отдела продаж автомобилей – что такое стеклоочиститель и чем отличается полноприводный внедорожник от обычной машины. А вот с фирмами, специализирующимися на информационных услугах, просто беда. Часто случается, что в серьезной и технологически продвинутой компании, которая занимается разработкой и внедрением программного обеспечения или информационных систем и даже имеет слова «Networks», «Systems», «Software» в своем названии, встречаются люди, которые, как бы помягче сказать, имеют к ИТ весьма отдаленное отношение. Одно дело, если ИТ-отделы обслуживают детский сад или цветочный павильон, но в компании, скажем, профессионально занимающейся веб-хостингом или новым поисковым «движком», которая хочет подмять под себя Yandex, а в будущем и Google, все сотрудники, может быть, за исключением высшего исполнительного руководства и бухгалтерии, должны знать, что такое DNS, веб-трафик и количество уникальных посещений. Хотя бы в первом приближении. В реальности «коллеги» системных администраторов в подобных местах чуть ли не напоказ выпячивают свою вопиющую компьютерную безграмотность или знание ИТ в объеме «могу отправить и прочитать письмо» или того хуже – «знаю достаточно, чтобы быть опасным». Персонал, который в силу профессиональной деятельности обязан глубоко знать ИТ, но не обладает подобными знаниями и умениями, будет постоянно требовать к себе повышенного внимании. Эти сотрудники станут источником вечных недоразумений.

82

Поэтому ответ на вопрос: «Почему компания категории А (Google, Zynga, Facebook, Kaspersky) успешна, а компания категории Б (увы, история не сохранила имен) прогорела в течение нескольких лет?» – находится на поверхности. В компании категории А практически ВСЕ сотрудники разбирались в предметной области и были профессионалами своего дела. А при ликвидации «фирмы-неудачницы» при возможности посмотрите, что за люди там работали, вчитайтесь в их послужной список и попробуйте понять, что они делали на прошлой работе. Увы, часто приходится признать, что «вицепрезидент по развитию» или «директор отдела клиентских отношений» в лопнувшей технологической фирме более органично смотрелся бы в роли продавца арбузов на колхозном рынке или распространителя рекламы в метро. История умалчивает, что их свело в один коллектив с талантливыми специалистами и разработчиками программного обеспечения. Вот только компания от этого почему-то не развивалась. Подобные «квазипрофессионалы» постоянно отнимали время у отдела ИТ – сегодня нужен другой монитор, завтра принтер не печатает, послезавтра не могу отправить письмо по электронной почте, не знают, как работать в электронной таблице Excel. Это лишь полбеды. Беда в том, что даже те работники, которые более-менее разобрались со своими компьютерами и уже гордо называют себя «опытным пользователем» (power user), будут постоянно неверно задавать самые простые на первый взгляд вопросы и с огромным трудом понимать, что же конкретно надо сделать, чтобы донести до клиента ту или иную ИТ-просьбу. Например, простейший запрос клиенту «создать запись в DNS, чтобы mobile. site.com заработал» будет переписан и передан как «создать mobile запись в DNS» – хорошо, если на «том конце провода» разберутся, что конкретно надо сделать. А если нет? Вот и теряют системные администраторы свое драгоценное время на бесконечных совещаниях, курсах по компьютерному ликбезу «офисного планктона» – все это время фирма НЕ развивается, а учится «компьютерной азбуке». А в это время более ловкие и лучше подготовленные конкуренты захватывают рыночную нишу.

март 2012 системный администратор

ит-управление

Правило второе. Не допускаем вольных интерпретаций и трактовок в ИТ-документации В сфере ИТ чрезвычайно важны точность формулировок и отсутствие «опечаток». К сожалению, многие сотрудники фирм, работающие за пределами отдела ИТ или программистов, имеют весьма приблизительное представление о точности, требуемой для тех или иных информационных технологий и процессов. Непроверенный или неверно написанный адрес 206.155.98.178 вместо 206.155.98.173 (ну, подумаешь, перепутали 3 и 8 или нечетко написали от руки) приведет к полной неработоспособности целого портала, который сконфигурирован под этим адресом. Понятно, что за неделю профессионалами им не стать. Как же быть? Для успеха проекта, над которым работают не только ИТ-профессионалы, можно использовать несколько достаточно простых правил. >> Ясность терминологии. В начале работы над проектом надо обязательно очертить круг ИТ-технологий, которые будут использоваться, и кратко изложить, что это такое и какую роль данная технология играет в проекте. Этот перечень будет меняться от проекта к проекту. Например, в недавнем проекте мне пришлось постоянно работать с сетевыми средствами DNS, многократно вносить изменения в /etc/hosts, а также удалять временные cookies. После короткого совещания с участием представителей других отделов была подготовлена краткая памятка, в которой популярно (для неспециалистов) объяснялся этот материал, а также то, как он используется для миграции сетевых средств. >> Обязательное включение (хотя бы с совещательным голосом) ИТ-специалиста в процесс принятия любых решений, даже косвенно затрагивающих ИТ. Недавний пример: сотрудник отдела маркетинга (а «отдел маркетинга» обычно любит очень расплывчато говорить, собирая в одну кучу взаимоисключающие явления) предложил, чтобы продукт распространялся по схеме «попробовал, а потом купил». К счастью, на совещании присутствовал администратор баз данных, который сказал: «Идея отличная, но что будет, если 100 тысяч пользователей захотят попробовать?!» База данных, под которой работает приложение, разрабатывалась под строго определенную нагрузку, и вопрос с масштабируемостью до уровня «предложить попробовать произвольному количеству пользователей» никогда не ставился. Чтобы избежать разночтений в документации, особенно в сложном проекте, никогда не помешает в начале документа разъяснить все ключевые определения. Свежий пример из практики. Чтобы равномерно распределить нагрузку на серверы баз данных, всех клиентов разделили в алфавитном порядке на две группы: все имена, начинающиеся с букв «А» до «М», попали на первый кластер, а с «Н» до «Я» – на второй. Таким образом, всем сотрудникам компании было понятно, что означает «клиент из первой группы» и «клиент из второй группы». В начале года появился проект по миграции клиентов на новую платформу, и клиентов также распределили по разным срокам миграции –1 января, 15 января, 1 февраля. Когда кто-то использовал выражение «клиент первой группы для миграции», было неясно, имелось ли в виду разделение по кластерам

системный администратор март 2012

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

Правило третье. Назначаем ответственного за документ Достаточно часто над проектной документацией или клиентским предложением работают несколько человек из различных отделов фирмы. Хорошо, если структура документа изначально предназначена для заполнения несколькими людьми. Но чаще всего клиент присылает или в рабочем порядке составляется единственный документ, многочисленные копии которого в разной степени готовности и заполненности «гуляют» по информационным подразделениям. Нужно ли говорить, что в подобной ситуации возрастает риск того, что будет послана «не самая последняя версия» документа или чьи-то изменения будут случайно «затерты»? Чтобы этого не произошло, всегда должен быть назначен человек или определено место на доступной всем сотрудникам файловой системе, где хранится самая «последняя» (рабочая) копия документа, а параллельно этому процессу составляется расписание – кто и к какому сроку должен внести свои изменения. Примерно вот так: >> документ находится в /home/projects/doc_rfp_2011_ 12_07_xo.txt; >> админ баз данных вносит изменения до 11.00 утра 8 декабря 2011; >> директор отдела разработчиков до 15.00 8 декабря; >> отдел кадров до 18.00 8 декабря. >> Окончательную правку и вычитку делает вицепрезидент по ИТ до 9 декабря 11.45 , документ должен быть отправлен клиенту не позднее 11.55 9 декабря.

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

Правило пятое. Всегда выставляем сроки Очень простое, но постоянно игнорируемое правило – у любого проекта всегда должны быть выставлены сроки испол-

83

Карьера/Образование

ит-управление

Четыре правила для электронной почты

делен срок исполнения, потому он не сделан», или начинается штурмовщина, очень знакомая российскому читателю.

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

нения. Если ответить на письмо, то до конкретного числа, если установить сервер, тоже до конкретного числа, если обновить таблицу, снова требуется сделать «до 1 декабря». Профессионалы работы с информационными проектами нередко предпочитают программы типа Microsoft Project, но вовсе не обязательно осваивать этот серьезный продукт. Обыкновенные Microsoft Outlook, Apple Mail и многие другие почтовые программы уже давно умеют работать с календарем и с «напоминалками». Можно даже использовать обычный органайзер – тут вопрос не в выборе технологии, а в принципиальном понимании того, что любая задача должна иметь не только конкретного исполнителя, но и конкретный срок. Зарубежного ИТ-специалиста, впервые получившего работу в нормальной американской компании, приятно удивят уровень обозримости и статуса исполнения любого проекта и очень жесткая привязанность к срокам. Сроки выполнения не будут назначаться по типу «Когда надо? Вчера!». Если срок окончания проекта определен до 1 мая 2012 года, будьте уверены, что 2 мая все сотрудники фирмы так или иначе узнают, сдан проект вчера или нет. Многие стартапы в силу того, что надо делать все и сразу, спускают на тормозах зависимость от конкретных дат, а когда начинает поджимать время, оказывается, что «на данный проект не был назначен ответственный человек и не опре-

84

Правило шестое. Учимся логически мыслить «Гладко было на бумаге, да забыли про овраги – а по ним ходить». Системные администраторы – люди достаточно точные, поэтому грубых ляпов в архитектуре проекта или в работе над техническим заданием они, как правило, не допускают. Любой узел или часть проектируемой подсистемы всегда должны быть задокументированы на предмет: >> Кто знает, как ЭТО точно работает? >> ЭТО поддерживается производителем – если «да», то сколько стоит поддержка? >> Что делать, если ЭТО вышло из строя? Насколько мы становимся зависимыми? >> Как ЭТО мониторить и проверять, что работает именно так, как мы хотим? >> Нужны ли для ЭТОГО конфигурация, формальное описание, обучение, как и где его хранить и передавать? >> Насколько ЭТО масштабируемо? >> Сколько ЭТО стоит с учетом всех «скрытых расходов» – налогов, доставки, установки, настройки, обучения, поддержки? >> Насколько большие изменения надо совершить в других подсистемах, а может, и в функциональной структуре компании, чтобы ЭТО заработало? >> Можем ли мы связаться с клиентами, у кого ЭТО уже работает? Если рассматривается вопрос об установке новой и дорогой информационной системы, то всегда важны люди и организации, у кого она уже установлена, – кстати, в визитах в эти организации, как на «выставку достижений», часто бывают очень заинтересованы и фирмы-продавцы, системные интеграторы. И последний вопрос, который ставит в недоумение многих ИТ-директоров: >> Какую проблему ЭТО решает? Под словом «ЭТО» может подразумеваться обсуждаемая в настоящий момент новая информационная технология, аппаратное или функциональное решение, даже должность в компании! Как ни странно, часто четкое и внятное объяснение целесообразности проекта совершенно отсутствует, а финансовое обоснование взято из какого-то учебника и не имеет ничего общего с реальным положением дел в конкретной фирме. Поэтому все цифры тщательно проверяются и перепроверяются по состоянию на сегодняшний день и под конкретный объект. Однажды мне довелось быть наблюдателем в совещании ИТ-отдела, когда после оживленного обсуждения планов внедрения нового сетевого оборудования кто-то спросил: «Ребята, а, собственно говоря, какую проблему мы здесь решаем?» Немая сцена была ответом на этот простой вопрос.

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

март 2012 системный администратор

ит-управление Например, на рис 1. показано, как организован механизм управления информацией (content switching). Иногда, особенно в западных компаниях, системные администраторы и архитекторы чрезмерно увлекаются использованием «заметок на полях» – на досках, обрывках бумаги, салфетках, но только не в нормальных редакторах деловой графики (OmniPage, Visio).

Правило восьмое. Держим документацию всегда в аккуратном состоянии. Правильно и своевременно обновляем файлы К сожалению, к системной документации часто относятся, в лучшем случае, как к необходимому злу. Иногда ее нет вовсе, часто она безнадежно устарела – находится на том «опасном» уровне, когда полностью стереть ее и начать с нуля нельзя, слишком многое завязано на ней, но и доверяться тоже нельзя! Кстати, при собеседовании при устройстве на работу всегда нелишне спросить о состоянии дел с документацией в компании. Можно только догадываться об уровне «авралов» и «информационной запущенности» там, где установлено, скажем, 900 серверов, если ИТдиректор говорит: «Последний раз мы обновляли документацию года два назад, кстати, этим надо будет заниматься. Потом мы купили около 50 серверов, затем еще 150, потом мы их переделали, так что не было времени все это документировать». Приходится повторять, что отсутствие адекватной и аккуратной системной документации фактически приравнивается к неработающему серверу. А как же иначе? Если что-то выйдет из строя, всегда должен быть готов план по типу «использовать в случае пожара». Если же его нет, начинается свистопляска: как чинить, где пароль на сервер, зачем нужен этот файл?.. Понятно, что это уже не «информационный тромб», а «обширный инфаркт».

Правило девятое. Заручаемся поддержкой руководства и учимся составлять короткие аналитические записки Часто ИТ-проект начинает обрастать техническими подробностями, которые не всегда понятны сотрудникам фирмы, работающим в других подразделениях. Если финансовому директору или замгендиректора по развитию постоянно будут посылать сообщения по статусу «текущего состояния проекта», в которых рябит в глазах от ipsec vpn, csr 2048 bit, ssl vpn, то они либо просто потеряют интерес к происходящему, мол, «решайте сами», либо попробуют проект «спустить на тормозах». Для предотвращения этого «информационного тромба» надо заручиться официальной поддержкой руководства, чтобы ни у кого не возникало вопросов, почему это «рядовой системный администратор» проводит совещания и организует закупку дорогостоящего сервера. Чтобы руководство компании не тратило время на вникание в тонкости ИТ- проекта, всегда должны быть готовы краткие, но аккуратные «аналитические записки», которые отвечали бы на вопросы: >> где сейчас находится проект; >> ситуация по срокам; >> ситуация по стоимости;

системный администратор март 2012

Карьера/Образование >> ситуация по «видимости» для клиентов, если что-то не готово или не работает; >> что надо сделать, и кто это сделает.

Правило десятое. Контролируем процесс исполнения Как бы красиво ни смотрелись проекты и презентации «на бумаге» (или в электронном виде), всегда наступает момент, когда надо приступать к реализации того или иного проекта или решения. В классификационном реестре СССР по специальности «Документоведение и документационное обеспечение управления», который практически без изменений стал стандартом для российской документации, на оборотной стороне любого документа, принятого к исполнению (приказ, резолюция, решение), должна быть напечатана фамилия исполнителя и его контактная информация. Сегодня, во втором десятилетии ХХI века, как-то неловко говорить об «оборотной стороне отпечанного документа», но суть дела от этого не меняется. Для любого проекта, и ИТ не являются исключением, должен всегда быть назначен ответственный за исполнение, равно как и сроки исполнения и, если требуется, необходимые полномочия – в зависимости от типа и статуса проекта. Часто в матричной организационной структуре ответственные за исполнение, которых часто называют «менеджерами проектов» или «исполнительными продюсерами», могут руководить любыми сотрудниками компании, вплоть до ранга вице-президента. Например, мне пришлось быть свидетелем, как на собеседовании при приеме на работу спросили у одного из претендентов: «Как бы вы поступили, если бы проект, которым вы руководили, находился под угрозой срыва из-за вашего непосредственного начальника?» Ответ был таков: «Я бы дал ему знать, а, если необходимо, и другим сотрудникам компании, о возможном срыве проекта». Кандидату сразу же предложили работу, так как руководство фирмы было уверено – проект под его руководством будет выполнен! *** Следование этим правилам «информационной гигиены» поможет понять руководству компании, почему она пробуксовывает и где «теряется» эффективность труда работников. EOF Рисунок 1. Организация механизма управления информацией (content switching)

85

Карьера/Образование

ретроспектива

Визитка Владимир Гаков, журналист, писатель-фантаст, лектор. Окончил физфак МГУ. Работал в НИИ. С 1984 г. на творческой работе. В 1990-1991 гг. – Associate Professor, Central Michigan University. С 2003 г. преподает в Академии народного хозяйства. Автор 8 книг и более 1000 публикаций

Японские бизнес-фокусы В 1873 году предприниматель Суигура Рокусабуро открыл эру японского фотобизнеса. Спустя десятилетия знаменитая компания Konica Minolta, уйдя с рынка фотокамер и фототоваров, продолжает оставаться мировым лидером на других рынках

Сегодня японский промышленный гигант Konica Minolta занимается всем, чем угодно, кроме производства собственно фототехники. Хотя воспоминания об одном из ведущих японских производителей последней в памяти рядового потребителя сохранится еще надолго. Во всяком случае, до тех пор, пока будут верно служить миллионы купленных цифровых фотокамер с этим логотипом на корпусе. А до них мир успели заполонить – и три четверти века так же безотказно служили – камеры обычные, «пленочные», которые первой в Японии начала производить компания-предшественница Konica Minolta.

Народные средства лечения «фотозависимости» Вместо некогда «фирменной» фототехники нынешняя Konica Minolta предлагает потребителю весь спектр решений для поддержки и совершенствования «офисной среды». То есть всего, что позволяет обрабатывать и пересылать документы в соответствии с возрастающими требованиями современного документооборота – к цветовой гамме, оцифровке, скорости обработки и передачи, сетевым возможностям. Иначе говоря, лазерные принтеры, копиры, факсы, объединяющие все перечисленное (и многое другое) многофункциональные периферийные устройства (МФУ), системы микрофильмирования. А еще Konica Minolta производит высокотехнологичную оптику, копировальную технику, а также медицинскую, полиграфическую, измерительную, программное обеспечение… Многим читателям «СА», вероятно, будет приятно узнать, что одно из подразделений корпорации – Konica Minolta Business Technologies – является членом некоммерческого фонда The Linux Foundation, созданного для развития и продвижения известно чего… Но до этого главной специализацией и главной, как сейчас говорят, «фишкой» компании была фототехника. Только это была другая компания. Точнее, две, слившиеся сравнительно недавно – в 2004-м. За три четверти века до появления на рынке первой из них о японской фототехнике никто и понятия не имел – за отсутствием таковой. Фотографию изобрели, как известно,

86

на Западе, и в Стране восходящего солнца к началу прошлого века покупали технику импортную – в основном немецкую. Покупали, надо сказать, неплохо. И все же затею местного предпринимателя Суигуры Рокусабуро, решившего в 1873 году открыть в крупнейшем токийском фармацевтическом магазине «Конишайя Рокубе» продажу фототоваров, коллеги бизнесмена посчитали рискованной причудой. Потому что до этого Рокусабуро занимался делом престижным и понятным – он был старшим сыном в процветавшем «аптекарском» семейном клане. Тут два слова, ключевые для понимания специфики японского бизнеса: «старший сын» и «семейный клан». На подобных семейных фирмах – и более крупных конгломератах (дзайбацу) – традиционная японская экономика держалась вплоть до середины прошлого века. В частности, семейство Рокусабуро производило и торговало товаром также традиционным, проверенным за века и тысячелетия, – средствами народной медицины. Тем удивительнее выглядела «выходка» основоположника японского фотобизнеса, совсем не характерная для национального менталитета. Это ж надо – продавать дурно пахнувшие (во всех смыслах) фотореактивы! «Дьявольские штучки иноземцев-чужаков» – с точки зрения подданных островной империи, на века закрывшейся от внешнего мира. При этом новатор-«отщепенец» даже не подозревал, что занялся новым видом бизнеса на восемь лет раньше своего легендарного американского коллеги Джорджа Истмена – создателя первой фотопленки и основателя компании Kodak. Если кто забыл или вообще не в курсе – до «цифры» была пленка, но и до ее появления люди фотографировали. Запечатлевали первые «остановившиеся мгновения Истории» на особых стеклянных пластинках, на которые наносилась специальная фотоэмульсия. Потом снимки высушивались, проявлялись, фиксировались, переносились на фотобумагу… В общем, морока та еще – первые фотолюбители были, конечно же, подвижниками, но одновременно и мучениками своего хобби. Спустя пять лет после открытия отдела фототоваров в токийском магазине к Рокусабуро перешло по наследству се-

март 2012 системный администратор

ретроспектива мейное дело, и в соответствии с теми же традициями глава фирмы получил новое имя-титул – Рокуэмон VI. К тому времени он уже год как сменил амплуа. Торговать лекарствами ему стало неинтересно, поэтому он передал семейный магазин младшему брату, а сам открыл новый – первый в стране специализированный магазин фототоваров «Кониши Шотен». А затем, не прерывая торговли, стал одновременно и «отечественным товаропроизводителем». А именно – первым на родине начал выпускать «родные» фототовары. Сначала это были реактивы, фотобумага, осветительная техника и прочие аксессуары. И наконец, фотокамеры. Первой японской камерой, рассчитанной на обычного фотолюбителя, стала выпущенная в 1902 году модель, название которой переводится с японского как «портативная вишенка» (по-английски – Cherry Portable Camera). Сама компания при этом сменила название на «Конишироку Шотен» (производное от Кониши и Рокуэмон). Вскоре название писалось уже и на латинице, поскольку продукцию фирмы охотно покупали и иностранцы, постоянно проживавшие или посещавшие по делам Японию. Есть данные о том, что среди этих «понаехавших» был и легендарный советский разведчик Рихард Зорге. Хотя с профессиональной точки зрения – для поддержания собственной легенды – «немецкому журналисту и убежденному нацисту» следовало бы, конечно, пользоваться родной немецкой Leica. Первая камера под всем ныне известным брендом – Konica I – была выпущена уже после Второй мировой войны, в 1948 году. Успех этого семейства фотокамер на протяжении последующих четырех десятилетий привел к тому, что в 1987-м популярным именем-брендом была названа и сама компания-производитель.

Карьера/Образование

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

ной техники, принтеров, факсов) Minolta Co., Ltd., созданная бизнесменом Казуо Таджимой. Как и его старший коллега Рокусабуро, Таджима тоже начинал с торговли импортным товаром, основав в 1928 году в Осаке «Японо-германский магазин фотокамер» («НишиДоку Шашинки Шотен»). Но путь от торговца до товаропроизводителя прошел не в пример быстрее – спустя всего год выпустил на рынок собственную фотокамеру Nifcalette. А в 1933-м модель Plaubel Makina стали называть просто Minolta. Звучало, конечно, не совсем по-японски (как известно, в местном языке отсутствует звук «эль»), но зато короче. До начала Второй мировой войны Minolta успела порадовать японских фотолюбителей и профессионалов первой в стране двухлинзовой зеркальной камерой и первой же «родной» цветной фотопленкой. Назвали ее, конечно же, Sakura Natural Color – кто бы сомневался. Первое послевоенное десятилетие явило миру знаменитое «японское чудо» – расцвет и триумфальное шествие по планете японских высоких технологий. Можно назвать это своего рода мирным реваншем побежденных победителям в недавно закончившейся войне. Среди «реваншистов» заметное место занимала и компания Таджимы. Уже в 1956-м она закрепила свое присутствие на американском рынке, создав первую – но далеко не последнюю – дочернюю компанию в Филадельфии. Спустя два года появилась модель Minolta SR-2 – первая из семейства SLR-камер (интегрированных однолинзовых зеркальных 35‑мм камер с автофокусировкой), прославивших японскую компанию. Эти камеры не знали себе равных на протяжении последующих десятилетий – вплоть до прихода на рынок цифровой фототехники. В 1962 году Minolta вышла на новую орбиту – на сей раз в буквальном смысле слова. «Роман» компании с космосом начался несколькими годами раньше, когда с помощью ее оптики был оборудован первый в Японии планетарий. А затем прошла сенсационная и пока не превзойденная в истории Minolta «рекламная кампания», ставшая для детища Таджимы «подарком небес» – тоже буквально! Потому

Портативная фотокамера Konica Cherry

Фотокамера Konica Auto-reflex

Выход на орбиту второго «спутника фотолюбителя»

системный администратор март 2012

87

Карьера/Образование что Джон Гленн – первый американский астронавт, облетевший планету, взял с собой в космический полет… правильно, камеру от Minolta (модифицированную Hi-Matic)! Как и в случае с Konica, «бренд сделал свое дело», но в отличие от шекспировского мавра не ушел, а, наоборот, прочно закрепился в названии компании-производителя. В год первого полета американца в космос японская фирма сменила свое невыговариваемое для европейцев и американцев название на более простое и уже всем известное Minolta Camera Company, Ltd. Следующее десятилетие ознаменовалось для компании выпуском первой в мире SLR-камеры со встроенной вспышкой и 35-мм камеры-компакта с автофокусировкой, не говоря о других, не менее успешных новинках. А 1980-е годы стали десятилетием триумфа модели Minolta Maxxum 7000, также первой в мире коммерчески успешной SLR-камеры с автофокусировкой. Настолько успешной, что почин быстро подхватили другие производители, «наклепавшие» аналогичные собственные камеры. Дело дошло до того, что американская компания Honeywell в 1985 году обвинила Minolta в… присвоении ее, Honeywell, технологии автофокусировки! И суд принял сторону истца, оценив нанесенный ущерб в $127 млн. Имело ли место, мягко сказать, «заимствование» запатентованной технологии или произошло обычное в условиях жесткой конкуренции и временной гонки совпадение (обе компании в секрете друг от друга создавали одно и то же «технологическое чудо») – дело темное (в контексте данной статьи – несфокусированное) и за давностью лет закрытое. Потому что еще в последнем десятилетии прошлого века Minolta и Honeywell уладили споры «по-доброму» – в досудебном порядке.

ретроспектива

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

с функцией zoom, а также создала общенациональную систему печати водительских прав, назвав последнюю… Догадайтесь с одного раза! Точно – Sakura. Кроме того, было налажено производство медицинской лазерной техники. Эта экспансия привела к тому, что в 1994-м из названия компании пропало слово «камера». Но последние новоиспеченная Minolta Company, Ltd. продолжала выпускать попрежнему. С той лишь разницей, что со временем пришлось переходить на «цифру». Хотя нужно сказать, что с кардинальной перестройкой, обусловленной вхождением человечества в «цифровую» эру, Minolta слегка припоздала. Продолжая по традиции штамповать свои «пленочные» SRL (правда, совершенствуя их от модели к модели) и столь же беспроигрышные принтеры с копирами, компания к приходу Миллениума пропустила вперед сразу нескольких конкурентов – американскую Kodak и «родных» Fuji, Casio, Ricoh, Canon и Nikon. И, признав свое поражение, она, без малого век не знавшая равных на рынке фототехники, в 2006 году объявила об окончательном уходе с этого рынка, передав все свое «фотохозяйство» другим, в частности, производство фотокамер – компании Sony, с которой незадолго до того создала совместное предприятие. Только передавала это «хозяйство» партнеру уже не Minolta Company, а другая компания, имевшая к тому времени иное название и иные перспективы. Первые очертания альянса двух гигантов – Minolta и Konica – наметились за шесть лет до того: в 2000 году обе компании создали совместное производство полимерных тонеров для копировальной техники. Их деловой «роман» развивался стремительно, и в 2003-м бренд Minolta завершил свое «холостое» существование. После того как на рынке появилась последняя камера от Minolta (цифровая DiMAGE A1), обе фирмы объявили о грядущем слиянии. И начало нового 2004 года встретили, объединившись в корпорацию Konica Minolta Holdings. За логотип приняли слегка измененный логотип прежней Minolta. Как было разъяснено на корпоративном сайте компании, суть его следующая. Стилизованное изображение

Фотокамера Konica Hexar

Фотокамера Konica Minolta 35 C

Фокус со слиянием

88

март 2012 системный администратор

Карьера/Образование

ретроспектива земного шара выражает глобалистские амбиции компании, но не только территориальные, а и в плане «тотального» удовлетворения постоянно возрастающих запросов покупателей во всем мире. А почему земной шар рассекают именно пять горизонтальных линий, не меньше и не больше, – об этом чуть ниже. У бывшей Minolta был позаимствован и корпоративный слоган: «The essentials of imaging». На русский язык его чаще всего переводят буквально – «В основе изображений». Хотя оба существительных в оригинале имеют целый спектр значений, упускать которые не следует. Essentials – это и «сущности, неотъемлемые части», и «основы», и «предметы первой необходимости». А неологизм imaging, обозначающий всю сферу получения, обработки и передачи изображений, вообще не переводят – пишут без затей «имиджинг». Сам же слоган на указанном корпоративном сайте объясняется следующим образом: «Мы хотим, чтобы нас рассматривали как основную компанию, предлагающую потребителям основные продукты, сервисы и решения в сфере имиджинга». Как говорится, почувствуйте разницу.

Пленка закончилась Уйдя с рынка фотокамер и соответствующих фототоваров, обновленная Konica Minolta продолжает оставаться мировым лидером на других рынках – новых, открывшихся сравнительно недавно. Прежде всего это рынок, появлением которого мир обязан как раз японской компании. Она первой начала производить упоминавшиеся выше многофункциональные периферийные устройства (МФУ), или bizhubs. «Бизхаб» (от business и hub – втулка, ступица колеса, в переносном смысле – центр, средоточие) – это прибор, объединяющий функции лазерного принтера, цветного копира, сканера, факса, средства для рассылки и приема электронной почты. Короче, всего того, без чего сегодня немыслимо нормальное функционирование бизнеса, на глазах становящегося все более скоростным, мобильным и «сетевым». Причем спектр периферии не ограничен уже перечисленными устройствами и системами – bizhubs от Konica Minolta принципиально совместимы со всем, что ожидается – или только прогнозируется – на рынке периферии. Годом рождения первого bizhub стал год появления самой Konica Minolta – 2004-й. За первой моделью C350 последовали не менее успешная C450 и две модели для «профи» – bizhub PRO 1050 и bizhub PRO C6500. Кроме того, в ассортименте Konica Minolta сегодня представлены дигитайзеры (в том числе и первые в мире трехмерные и бесконтактные), уникальная медицинская аппаратура (например, для маммографии), специальные пленки для жидкокристаллических экранов. В альянсе с американской General Electric японская компания разрабатывает новые поколения органических светоизлучающих диодов. Не забыт и давний «роман с космосом» – крупнейший и самый технологически «навороченный» в стране планетарий Sunshine Starlight Dome «Manten» также оснащен аппаратурой от Konica Minolta. Сегодня многопрофильный холдинг объединяет пять независимых компаний – в соответствии с теми пятью световыми лучами, что рассекают земной шар на кор-

системный администратор март 2012

поративной эмблеме («эти пять лучей света выражают наш профессиональный опыт в сфере получения и обработки изображений»). Две из них, Multi-Functional Peripherals (MFPs) и Konica Minolta Printing Solutions, объединены в корпорации Konica Minolta Business Technologies, Inc. со штаб-квартирой в Токио и штатом около 20 тысяч человек. Именно последняя предлагает весь спектр решений для поддержки и совершенствования «офисной среды», о чем говорилось в начале статьи. Третья компания, Konica Minolta Opto, Inc., производит различные оптические приборы – как отдельные компоненты и узлы, так и целые системы, используемые во многих сферах науки и промышленности. Четвертая, Konica Minolta Medical & Graphic, Inc., занята производством, продажей и постпродажным сервисом техники и материалов для различных видов имиджинга в области медицины и полиграфии. Наконец, пятая, Konica Minolta Sensing, Inc., специализируется на выпуске разнообразных измерительных приборов и программного обеспечения для промышленности и той же медицины. Это трехмерные дигитайзеры, электронный редактор изображений Polygon Editing Tool (PET), спектрофотометры, колориметры, измерители освещенности и светимости, спектрорадиометры и прочее. Пленка давно кончилась, а в мире, становящемся день от дня все более «визуальным», еще столько всего нужно снять на «цифру», чтобы потом соответствующим образом обработать и разослать по всему миру! И не японцам, возведшим созерцание красоты в культ, отступать перед затопившим их страну и весь мир океаном визуальной информации. EOF

Bizhub PRESS C8000

89

Карьера/Образование

лабораторная работа

Визитка

Павел Закляков, ИТ-специалист

Представление чисел в памяти ЭВМ Часть 1. Целые числа

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

Термины ЭВМ, ПЭВМ [12], ПК и «компьютер» будем считать синонимами. Учитывая известное выражение, ставшее популярным благодаря Стивену Хокингу: «Каждая добавленная в книгу формула сокращает число её читателей вдвое», постараемся заполнить нишу между школьным курсом информатики и уровнем компьютерных стандартов, не распугав окончательно всех читателей журнала приводимыми в рассуждениях формулами. В отличие от встречающихся в сети (и литературе) материалов по данной теме наш будет дополнен примерами программ, с помощью которых можно проверить сказанное, выполнив предложенную лабораторную работу (желательно самостоятельно).

Основные теоретические сведения Примем как данное, что к моменту появления компьютерной техники (вычислительных машин и конечных автоматов) человечество уже использовало такие понятия, как «число», «натуральное число» ( , +) и «целое число» ( ), известные читателям ещё из школьного курса математики, в связи с чем и возникла потребность в частичном или полном Рисунок 1. Расположение чисел в памяти компьютера в двоичном формате в последовательных ячейках памяти номера битов

7-й

6-й

5-й

4-й

3-й

2-й

1-й

0-й

1

0

1

1

0

1

1

0

старший значащий разряд most significant bit (MSB)

младший значащий разряд least significant bit (LSB)

Рисунок 2. Предлагаемое условное направление движения мыслей между сущностями

90

представлении обозначаемых ими объектов в виде каких-то состояний внутри аппаратуры ЭВМ. Мы не будем рассматривать аппаратное устройство узлов и блоков ЭВМ, а также вникать в то, как осуществляются математические операции над числами. Ограничимся тем, что наиболее часто используется двоичная память, каждая элементарная ячейка которой может находиться только в одном из двух допустимых состояний, и соответствующая ей двоичная арифметика; иными словами, все хранимые числа в конечном итоге должны быть представимы в виде набора «0» и «1». Попытаемся порассуждать на тему, как было бы разумнее и эффективнее хранить конечные множества чисел в памяти. В этой части работы (статьи) не будут рассматриваться и ирдействительные (вещественные) (рациональные рациональные I = \ ), комплексные числа, кватернионы (H) и др. числа. ЭВМ, работающие в троичной (напр. «Сетунь»), десятичной (напр. «ENIAC») и иных системах счисления, также не станут рассматриваться.

Машинное представление целых чисел Обычно числа располагаются в памяти компьютера в двоичном формате в последовательных ячейках памяти, при этом минимальный набор двоичных ячеек, к которому применимы операции адресации (как следствие, и другие операции), составляет 8 двоичных ячеек или 8 бит (см. рис. 1). Ранее такой набор назывался машинным словом и имел размер 1 байт = 8 бит. Сейчас размер машинного слова больше и зависит от характеристик аппаратной части ПК. При рассмотрении вопроса о представлении различных чисел в памяти ЭВМ удобно записывать эти числа в десятичной (естественной для нас), в двоичной (естественной для компьютера) и шестнадцатеричной (более компактной) формах записи. Основная сложность в понимании излагаемого материала, на мой взгляд, состоит в том, что производимые операции следует рассматривать синхронно для шести различных сущностей (см. рис. 2), поэтому я попробую показать «условное направление» движения мысли стрелкой.

март 2012 системный администратор

лабораторная работа

Карьера/Образование

Для каждой сущности существуют свои правила, где-то они схожи с соседними, а где-то различны. Попробуем разобраться со всем этим. Исключим верхнюю ветку (2 → 16) рис. 2 из рассмотрения как тривиальную (после рассмотрения таблицы 1 этот шаг будет действительно очевиден) и распишем нижнюю ветку с пояснениями в виде таблицы 1. Следует обратить внимание, что шестнадцатеричная форма записи двоичных чисел может быть применена как к «абстрактным двоичным числам», так и к записи, выполненной в «двоичном формате хранения чисел в памяти ЭВМ». Иногда в литературе для обозначения «представлений в ЭВМ» над двоичной или шестнадцатеричной записью могут использоваться квадратные скобки. Если предположить, что двоичные записи (числа в двоичной системе счисления и в представлении в памяти ЭВМ) могут отличаться, то и компактные, шестнадцатеричные записи указанных сущностей также будут отличаться. Разные множества чисел (положительные целые, отрицательные целые и вещественные разных диапазонов) имеют различные двоичные форматы.

Обозначение одного байта по ГОСТ 8.417-2002 «Государственная система обеспечения единства измерений. Единицы величин»: «байт» или «Б». >> 1024 байта = 1 Кбайт = 1 КБ, >> 1 Мбайт = 1 МБ = 1024 КБ = 1024 Кбайта и т.д. Обратите внимание, что используется буква «К» (большая, заглавная, прописная), в то время как в международной системе единиц СИ (SI, фр. Le Systeme International d'Unites, не имеет никакого отношения в языку Си (анг. C) приставка «кило», означающая 1000 = 103, в русском языке обозначается буквой «к» (маленькая, строчная). Чтобы запомнить этот нюанс, приведём короткий анекдот: «Физик ошибочно думает, что в одном килобайте (КБ) тысяча (1000) байт, а программист– что в одном килограмме (кг) тысяча двадцать четыре (1024) грамма». В зарубежной практике сегодня используются рекомендации стандарта IEEE 1541-2002, согласно которым бит (англ. bit) обозначается как «b», а байт (анг. byte) – «B». При этом, чтобы не путать «килобайты с килограммами», используются приставки: kibi (обозн. «Ki») = 210 = 1024; mebi (обозн. «Mi») = 220 = 1048576; gibi (обозн. «Gi»), 230 = 1073741824 и др. Надо заметить, что, несмотря на цифру 2002 в названии, стандарт был встречен обществом «двояко» и лишь 27 марта 2008 года окончательно утверждён как действующий. Скорее всего он «скопирован»

Зачем столько двоичных форматов?

с утверждённого ещё в 1999-м МЭК стандарта IEC 60027-2. Отличие по-

Если появление различных систем счисления («10», «2», «16») объясняется удобством использования в конкретной ситуации (см. выше), то следует логичный вопрос: «Зачем нужно множить двоичные форматы?» Ответ – в целях экономии. Либо для уменьшения числа операций, затрачиваемых компьютером для осуществления операций сложения (и умножения), либо для упрощения схемотехники, реализующей эти операции. Следует заметить, что мы не рассматриваем двоично-десятичный код [5, стр.499] и другие, коих великое множество, а ограничимся представлением чисел в современном ПК, оснащённом процессором AMD или Intel. Представьте себе, сколько усилий было бы сэкономлено, если бы Homo sapiens имел 8 или 16 пальцев!» [5, стр.500].

Основы Запись первых 15 натуральных чисел и 0 в упомянутых выше системах счисления (не формах представления чисел в ЭВМ) будет выглядеть следующим образом. Чтобы различать, в какой системе счисления записано число, удобно указывать систему счисления нижним индексом в записи числа, например: >> 710 = 01112 = 716 >> 1310 = 11012 = D16

следнего в том, что в нём для обозначения бита вместо «b» предлагается использовать слово «bit». Поскольку в массе своей покупатели и продавцы не сведущи в обозначениях сокращений по стандартам, благодаря стараниям маркетологов приставки kibi и пр. не используются – занижать визуально наблюдаемый объём невыгодно. Например, диск с этикеткой «1000 у.е.» будет продаваться лучше, чем с «932 ГБ», хотя в абсолютном исчислении 932 * 1024 * 1024 * 1024 даже чуть больше, чем 1000 * 1000 * 1000 * 1000. В сегодняшних прайс-листах и технических спецификациях (в том, что у всех на виду) запросто можно увидеть ёмкости жёстких дисков в «попугаях» (см. мультфильм «38 попугаев»).

Учитывая, что для более-менее детального исследования вопроса представления целых чисел в памяти ЭВМ необходим доступ к ячейкам памяти, будем иллюстрировать наши рассуждения примерами на языке C. Определим, сколько места занимает в памяти компьютера переменная типа unsigned char и какое максимальное значение может принимать число, хранимое в переменной данного типа. Для этого выполним битовую инверсию «0», а получившийся результат сравним с константой UCHAR_MAX библиотеки limits.h.

Таблица 1. Категории сущностей (стрелки указывают направление движения мыслей) Число

10

2

2 в ЭВМ

16 в ЭВМ

Число

Десятеричная система счисления

Двоичная система счисления

Двоичный формат хранения чисел в памяти ЭВМ

Шестнадцатеричная форма записи двоичного формата хранения чисел в памяти ЭВМ

Изначальная математическая абстракция

Привычная человеку форма записи чисел

Математическая абстракция

Фактическое хранение чисел в памяти ЭВМ

Фактически bin2hex («2 в ЭВМ»), компактная форма записи чисел двоичного формата

361 

1 01101001 

01101001 00000001 00000000 00000000

69 01 00 00

системный администратор март 2012

91

Карьера/Образование

Усложним программу и посмотрим, как хранится в памяти число 13.

$ cat program1_unsigned_char_max.c #include <stdio.h> #include <limits.h>

$ cat program2_unsigned_char_representation.c

void main (void) { unsigned char a; // определение переменной a=~0; // битовая инверсия 0 printf("a max: %u\n",a); printf("a size: %d\n",sizeof(a)); printf("max: %u\n",UCHAR_MAX); } $ gcc program1_unsigned_char_max.c&&./a.out a max: 255 a size: 1 max: 255

Как видим, число занимает в памяти 1 байт, что составляет 1 * 8 = 8 бит. Максимальное число получится тогда, когда все 8 бит будут выставлены в «1» (см. рис. 3). При подсчёте получим: 27 + 26 + 25 + 24 + 23 + 22 + 21 + 20 = 255 = 256-1 = 28 - 1 Проверим: $ echo "2^7+2^6+2^5+2^4+2^3+2^2+2^1+2^0"|bc 255

#include <stdio.h> void PrintByte (const void * pnt) {

char *p=(char *) pnt;

int unit=128;

int c;

for (c=0;c<8;c++) {

if ( (*p) & (unit) ) {

printf("1");

} else {

printf("0");

}

unit>>=1;

} printf("\n"); } void main (void) { unsigned char a; a=13; printf ("по адресу %p хранится ",&a); PrintByte(&a); } $ gcc program2_unsigned_char_representation.c&&./a.out

$ echo "2^8-1"|bc

по адресу 0x7ffffa84bcef хранится 00001101

255

Рисунок 3. Как видим, число занимает в памяти 1 байт, что составляет 1 * 8 = 8 бит. Максимальное число получится тогда, когда все 8 бит будут выставлены в «1»

Таблица 2. Запись первых пятнадцати натуральных чисел и нуля в различных системах счисления Десятичная

Двоичная

Шестнадцатеричная

0

0000

0

1

0001

1

2

0010

2

3

0011

3

4

0100

4

5

0101

5

6

0110

6

7

0111

7

8

1000

8

9

1001

9

10

1010

A или a

11

1011

B или b

12

1100

C или c

13

1101

D или d

14

1110

E или e

15

1111

F или f

92

лабораторная работа

Как видим: 0 + 0 + 0 + 0 + 1 * 23 + 1 * 22 + 0 + 1*20 = 8 + 4 + 1 = 13. То есть мы проверили, что представление целых неотрицательных чисел типа unsigned char не отличается от канонической формы представления двоичных чисел. Действительно: (bn-1 bn-2 ... b1 b0)2 = bn-1 * 2n-1 + bn-2 * 2n-2 + ...+ b1 * 21 + b0 * 20, где bi принимают значения из {0; 1}. Такую форму представления целого неотрицательного числа называют прямым кодом.

Отрицательные числа Если с натуральными числами и нулём всё довольно просто, то с отрицательными целыми дело обстоит чуть сложнее. Для них действует та же самая схема рассуждений, что и для положительных чисел (см. рис. 2), но используются более сложные алгоритмы преобразования. Во-первых, никто не хранит только отрицательные числа, так как для этой цели можно использовать положительные (тип unsigned), мысленно добавляя знак «-». В связи с этим, интерес представляет не само хранение отрицательных чисел, а хранение отрицательных и положительных чисел вместе. То есть чтобы выделенная переменная могла позволить представление какого-то подмножества множества  (как из положительной области чисел, так и из отрицательной). В этом случае переход от абстрактного «числа» к его десятичной (как и к двоичной) форме обычно не вызывает проблем. Преобразование положительных чисел остаётся неизменным, а преобразование отрицательных чисел производится так же, как и положительных чисел, но по завершении операций преобразования спереди записи ставится знак минус.

март 2012 системный администратор

Карьера/Образование

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

Рассмотрим варианты, приходящие на ум Если мы задействуем дополнительный бит для знака, то получим числа размером в 8 + 1 = 9 бит, 32 + 1 = 33 бита и 64 + 1 = 65 бит, где будут записаны знак и модуль числа, что не очень удобно с точки зрения записи чисел в памяти и операций над ними (особенно с разными знаками). Также мы получим ситуацию, когда у нас будет два нуля – «+0» и «-0». Попробуйте ответить самостоятельно: «Сколько операций потребуется, чтобы сложить -4 и +4? А -4 и +5? Какой получится ответ, если произвести операции над указанными числами, представленными в двоичном виде (знак и модуль числа), с точки зрения обычной арифметики?» Возможное решение указанных проблем: ограничить максимальный и минимальный размеры чисел, выделив для их представления на один бит меньше, а с наличием двух нулей смириться. В [6] данный формат называется как «sign and magnitude», что дословно можно назвать «знак и значение» или «знак и модуль». Удобство хранения чисел в таком формате, с точки зрения человека, приведёт к излишним преобразованиям при сложении чисел компьютером. Если вы не поленились и постарались ответить на вопросы выше, то заметили, что обычные правила арифметики (« » – сложение по модулю 2), когда мы складываем числа с разными знаками «в столбик», работать не будут. Чтобы обойти этот недостаток, можно представлять числа со сдвигом (как это делается при хранении порядка у чисел с плавающей точкой/запятой) либо «таблично», в этом случае мы избавимся от двух нулей, но для осуществления арифметических операций удобств это не добавит. На практике вопрос хранения отрицательных чисел в памяти ЭВМ решают использованием дополнительного кода. Рассмотрим подробнее, почему используется этот формат, и проверим программой, так ли это.

Дополнительный код В зарубежной литературе (в частности, в [4, 6, 11]) вместо «дополнительный код» можно встретить «N-bit two's complement» и «two’s-complement», что дословно можно перевести «как дополнение в n-битах до двух» или коротко «дополнение до двух». Рассмотрим, что это означает, взяв алгоритмы преобразования из [6]. Мы уже увидели, что положительные числа в компьютере хранятся в двоичной системе счисления. Каждый компьютер имеет свою архитектуру и определённый процессор, а последний, в свою очередь, фиксированное число разрядов, называемое «словом» (word) и определяющее размер порции данных, которую процессор может обработать за один раз. В общем случае размер слова зависит от используемого процессора и режима его работы (который, в свою очередь, определяется ОС), но в большинстве современных архитектур он не меньше 32 бит [13]. Обычно при программировании придерживаются следующих правил: для «очень больших» чисел применяется тип long long, для «обычных» – int, для «небольших» –

системный администратор март 2012

Дополнительный код Положительное число: >> Первый бит в записи равен 0 (0xxxxx....xxxxx). >> Дополнительный код есть само число в прямом коде. Отрицательное число: >> Первый бит в записи равен 1 (1xxxxx....xxxxx). >> Дополнительный код определяется любым из рассмотренных алгоритмов. Благодаря дополнительному коду процессор может работать с положительными и отрицательными числами одинаково хорошо: a+ (-a) всегда даёт 0, и в семантику представления арифметический блок процессора вообще не вникает.

short, а для «совсем маленьких» – char. Правда, увлекаться экономией памяти ради экономии не стоит: выигрыш чаще всего невелик, работа с «невыровненными» данными, некратными по размеру слову, может негативно повлиять на производительность. При хранении в переменной чисел обоих знаков в двоичной форме записи этой переменной самый левый (старший) бит отводится под знак («знаковый бит»). Первое правило: если он равен 0, то, значит, мы имеем дело с положительным числом, если в знаковом бите стоит «1», то мы имеем дело с отрицательным числом. Далее в зависимости от этого бита действуют разные алгоритмы. С положительными числами всё просто, а вот для отрицательных существует несколько различных схем, упрощающих человеку их преобразование в «машинный формат» представления. Первое, что приходит в голову, – это формат «знака и значения», рассмотренный нами выше, но, как мы выяснили, это не лучший способ. Лучший способ, как показали практика и время, – это хранить числа в дополнительном коде (формате дополнения «до двух», см. врезку). Этот способ основывается на базовом принципе арифметики, что число a, сложенное со своим отрицанием -a, должно давать в сумме 0. Если это правило действует для первой сущности «число» (см. рис. 2), то почему бы его не перенести на сущность «2 в ЭВМ». То есть в двоичной арифметике для компьютера также должно выполняться правило, что дополнительный код положительного числа, сложенный с дополнительным кодом отрицания этого же числа, должен давать в сумме 0 (в формате двоичного представления внутри компьютера). Дополнительный код для положительных и отрицательных чисел высчитывается по-разному. В случае положительных чисел всё действительно просто. Спереди от числа, преобразованного в двоичный вид, дописываются незначащие нули, чтобы общая длина двоичной записи числа соответствовала размеру отводимой под него памяти. Иными словами, дополнительный код положительного числа «совпадает» с этим числом. Например, если взять «число 52», то на следующем этапе согласно рисунку 1 мы берём это число в десятичной системе счисления 5210, после чего мы преобразуем его в двоичный вид 1101002, а затем дописываем спереди нули. В случае хранения числа в одном байте памяти дописываем нули до 8 разрядов, то есть для «2 в ЭВМ» получим «00110100», а для случая использования типа integer (занимаемый объём – 4 байта) придётся дописать на 24 нуля больше, а запись

93

Карьера/Образование

лабораторная работа

«2 в ЭВМ» будет другой (о том, что и как переставляется, поговорим ниже). Теперь рассмотрим способ получения дополнительного кода для отрицательных целых чисел. Данный способ базируется на двух основных свойствах: на том, как компьютер осуществляет сложение, и факте, что число -a есть то число, которое вы должны добавить к a, чтобы получить 0. Например, если а = 3, то -a = -3, так как 3 + (-3) = 0, и если а = -4, то тогда -a = 4, так как -4 + 4 = 0. Возьмём два числа 00110100 и 11001100, произведём их сложение «в столбик», в результате чего получим 0. Последний (левый) 9-й бит «переноса» мы отбросили, т.к. сумма должна поместиться в 8 битах. Также заметим, что первым числом было как раз 5210 (см. рис. 4). Из получившегося результата (сумма равна 0) и свойств, предложенных выше, делаем вывод, что битовая комбинация 11001100, использовавшаяся нами при сложении с первым числом, есть дополнительный код (для 8-битового представления) для числа -52, так как -52 + 52 в сумме даёт 0. Теперь давайте разберёмся, как такое получилось. С одной стороны, вы можете сказать, вы же сами выбрали числа таким образом, чтобы их двоичная сумма была нулём. Это верно, но давайте подробнее рассмотрим, как мы производили операцию сложения этих чисел. Мы начали складывать биты в записи в столбик справа налево и, если было необходимо, осуществляли перенос единицы на следующий разряд, влево. А далее мы могли заметить, что, складывая два дополнительных кода (дополнительный код положительного числа есть прямой код), получали при сложении каждого бита всегда ноль. Наверняка эта закономерность бросилась в глаза, если вы честно сложили числа, а не пропустили этот шаг, как очевидный. Попробуем наблюдаемую закономерность преобразовать в алгоритм вычисления дополнительного кода. Алгоритм №1 поиска дополнительного кода (n-bit two's complement) представления числа -m (m>0): >> Находим двоичное представление числа m. Например, для m = 5210 получим 1101002. >> Дописываем слева от записи нули в необходимом количестве, для того чтобы у нас получилось всего n бит. Из 1101002 при n = 8 получим 001101002.

>> Двигаемся справа налево и дополняем каждый бит записи с первой встретившейся слева единицы (не затрагивая её) единицей. Для последующих разрядов, как легко заметить, будет действовать правило: если был 0, то в дополнении будет 1, а если была 1, то в дополнении будет 0 (см. таблицу 3). Заметьте, что если мы так будем дополнять число 0, то ожидаемая единица никогда не встретится, в результате получим также 0. Так что не зря говорится: «как ни крути, ноль – он и в Африке ноль». Другими словами, если вы возьмёте дополнительный код любого целого числа, как мы сделали выше, причём не важно положительного или отрицательного, и прибавите «1» к каждому его разряду левее первой встретившейся единицы справа, то вы получите дополнение этого числа (что в десятичной системе счисления соответствует отрицанию числа). Так, если возьмём исходно в дополнительном коде 11001100 (что есть -5210) и прибавим к каждому разряду «1» по модулю 2, после самой правой единицы, если двигаться налево, то получим 00110100 (что будет 5210 – отрицание числа -5210) (см. таблицу 4). Существует и другой способ получения дополнительного кода. Если бы сложение выше было не поразрядным, а, как обычно, с переносом (см. таблицу 5), то при сложении числа с его дополнением мы бы получили в конечном итоге 1000000002 = 25610. Следующее наблюдение даёт нам способ получения дополнения. Обратите внимание, что 110011002 = 20410 и что 52 + 204 = 256 (см. в таблице 5 правый столбец). То есть дополнительным кодом числа -52 будет представление в двоичном виде числа (28 - 52 = 204). В математической терминологии мы говорим, что число 204 есть дополнение до нуля числа 52 по модулю 256 (mod 256), что означает: это то число, в сумме с которым 52 даст 0. (Сложение по модулю 256 означает, что мы складываем числа как обычно, а после берём остаток от деления на 256. В нашем случае это 0.) В общем случае, т.е. не для 8-битных чисел, а для n-разрядных чисел, мы получим следующий порядок действий. Если в компьютере используется n бит для хранения чисел, то логично, что при выполнении операций с числами следует использовать арифметику по модулю 2n, потому как размер чисел будет ограничен представлением последних n-разрядами памяти. При этом оказывается, что опера-

Таблица 3. Дополняем каждый бит записи левее первой встретившейся единицы справа (не затрагивая её)

Таблица 4. Сложение разрядов с «1» слева от первой встретившейся единицы справа

0 1 1

0 1 1

1 1 0

1 1 0

0 1 1

1

0

0

исходное число 5210

-

-

-

дополнения разрядов по модулю 2

1

0

0

результат

Рисунок 4. Сложение двух чисел, представленных в двоичном формате

1

1

1 0

0

1

0

1

0

1

1

1

1

1

0

1

0

0

исходное число -5210

-

-

-

дополнения разрядов по модулю 2

1

0

0

результат

Таблица 5. Не поразрядное сложение двух чисел, а, как обычно, с переносом 1

1

1

1

1

1

1

1

0

0

1

биты переноса 1

0

0

слагаемое1 (-52)

20410 +

1

94

0

0

1

1

0

1

0

0

слагаемое2 (+52)

5210

0

0

0

0

0

0

0

0

сумма (0)

25610

март 2012 системный администратор

Карьера/Образование

лабораторная работа ция «отбрасывания» старшего бита переноса, выходящего за сетку сложения, по сути, и есть деление результата сложения на 2n и получение остатка от деления. Коротко сказанное можно записать следующим алгоритмом. Алгоритм №2 нахождения дополнительного кода (n-bit two's complement) представления числа -m (m>0) есть представление целого положительного числа 2n - m в двоичной системе счисления. Просто вычисляем это число. Рассмотрим критические значения, 0, +128, -128. Кстати, несмотря на то что m>0, если окажется m=0, то эффект будет тот же, что и раньше – «ноль – он и в Африке ноль», потому как 256 в 8 битах не запишется (девятая единица числа 1000000002 окажется за пределами восьми разрядов, отводимых под хранение, и будет отброшена). Что же касается чисел +128 и -128, то тут мы правильного результата не получим, но и использовать эти числа нельзя, т.к. «+128» не существует (при восьмибитном хранении числа указанное значение выходит за допустимые пределы), ведь мы старший бит числа отводим под знак числа, а для положительных чисел старший разряд будет 0. А «-128» однозначно не удовлетворяет нашему условию (m>0). Кстати, для получения дополнительного кода числа по модулю 2n можно воспользоваться ещё одним алгоритмом, который чем-то напоминает первый. На практике используется довольно часто, так как инвертировать побитно и суммировать визуально оказывается проще, чем искать первую встретившуюся единицу (как в Алгоритме №1) или возводить в степень и вычитать большие числа друг из друга (как в Алгоритме №2). Алгоритм №3 поиска дополнительного кода числа -m (m>0): >> Найдите двоичное представление модуля рассматриваемого десятичного числа. (Дословно: отбросьте знак и переведите в двоичную систему счисления. Например, для m=5210 получим 1101002.) >> В двоичном написании дополните это число спереди нулями до n-разрядного представления. >> Инвертируйте его запись, заменив все «0» в записи на «1», а «1» на «0» (см. таблицу 6). >> Прибавьте к числу 1. >> Отбросьте выходящий за пределы n-разрядов результат (n=8) (см. таблицу 7). Как легко догадаться, рассуждения, приводимые выше, применимы для любых n-разрядных чисел. Посмотрим, как на практике осуществляется хранение 32-разрядных чисел в памяти ЭВМ на примере типов unsigned int и int. Возьмём program3_unsigned_int_representation.c:

} printf("\n");

} void main (void) { unsigned int a; a=~0; printf("a max: %u\n",a); printf("размер: %d\n",sizeof(unsigned int)); printf("max: %u\n",UINT_MAX); a=13; printf ("по адресу %p хранится ",&a); PrintByte(&a); } $ gcc program3_unsigned_int_representation.c &&./a.out a max: 4294967295 размер: 4 max: 4294967295 по адресу 0x7fffca0d9dac хранится 00001101 $ echo "2^32-1"|bc 4294967295

Как видим, максимальное значение рассчитано правильно, также правильно выведено число 13 в двоичном виде, но вот вывод, использовавшийся нами для числа типа unsigned char, не подходит, потому как, возьми мы не 13, а число больше 255, получили бы неправильное отображение. А также, мы из работы программы видим, что число занимает в памяти 4 байта, а не один выводимый, поэтому изменим программу, чтобы увидеть все 4 байта. $ cat program4_unsigned_int_representation2.c #include <stdio.h> void PrintByte (const void * pnt) { //... аналогично программе выше... } void PrintNByte(const void * pnt, int n) {

int c;

char * p=( (char *)pnt)+n;

for (c=0;c<n;c++) {

PrintByte(--p);

if (c<n-1) { printf(" "); }

}

printf("\n"); } void PrintN2Byte(const void * pnt, int n) {

char * p=( (char *)pnt);

char * last_byte_address;

last_byte_address=p-1+n;

for (;p<=last_byte_address;p++)

Таблица 6. Алгоритм инверсии числа

$ cat program3_unsigned_int_representation.c

0

0

1

1

0

1

0

0

отбросили знак, 52

#include <stdio.h> #include <limits.h> void PrintByte (const void * pnt) {

char *p=(char *) pnt;

int unit=128;

int c;

for (c=0;c<8;c++) {

if ( (*p) & (unit) ) {

printf("1");

} else {

printf("0");

}

unit>>=1;

1

1

0

0

1

0

1

1

инверсия 52

системный администратор март 2012

Таблица 7. Алгоритм отброса выходящего за пределы n-разрядов результата 0

0

0

0

0

0

0

1

1

1

1

0

0

1

0

1

биты переноса, при сложении 1

инверсия 52

1

+1

1

1

0

0

1

1

0

0

результат 52 +1

1

1

0

0

1

1

0

0

отбрасываем старший разряд

95

Карьера/Образование

{

PrintByte(p);

printf(" ");

}

printf("\n"); } void PrintHexNByte(const void * pnt, int n) {

unsigned short int i; char *a;

for (i=0;i<n;i++)

{ a=( (char *) pnt)+i;

printf ("по адресу %p: ",a);

printf ("%02hhX\n",*a);

}

printf("\n"); } void main (void) { unsigned int a; a=13; printf(" Исходное число: %d\n",a); printf(" Двоичный вид: "); PrintNByte (&a,sizeof(unsigned int)); printf("Двоичный вид в памяти: "); PrintN2Byte (&a,sizeof(unsigned int)); printf ("по адресу %p хранится ",&a); PrintByte(&a); printf("\n"); PrintHexNByte (&a,sizeof(unsigned int)); }

$ gcc program4_unsigned_int_representation2.c &&./a.out Исходное число: 13 Двоичный вид: 00000000 00000000 00000000 00001101 Двоичный вид в памяти: 00001101 00000000 00000000 00000000 по адресу 0x7fff7240676c хранится 01101001 по адресу 0x7fff7240676c: 69 по адресу 0x7fff7240676d: 01 по адресу 0x7fff7240676e: 00 по адресу 0x7fff724 0676f: 00

Можно заметить, что байты в памяти хранятся в обратном порядке (LITTLE_ENDIAN; для процессоров с архитектурой BIG_ENDIAN, например, IBM POWER, функцию PrintNByte() придётся модифицировать: оставляем это читателю в качестве упражнения). Сделано это для того, чтобы не прибегать к дополнительным преобразованиям. Если мы ошибочно обратимся к числу типа unsigned int, как к типу unsigned char, то, если число укладывается в диапазон unsigned char, результат будет правильным. Данная особенность была важна для обратной совместимости в коде 8-, 16- и 32-битных приложений, для обратной совместимости на пути апгрейда при «скачке» процессоров 8085 → 8086, а потом на этапе 80286 → 80386. Кстати, исходя из этой особенности при написании программ, работающих с протоколом TCP, может использоваться функция htons() для преобразования номера порта (двухбайтовое число) в число с сетевым порядком следования байтов [10, стр.119]. Модифицируем программу, чтобы можно было передавать числа через командную строку, и посмотрим на отрицательное число в памяти. $ cat program5_int_representation.c #include <stdio.h> // Описание функций PrintByte, PrintNByte, PrintN2Byte, // PrintN2Byte как и в program4_unsigned_int_representation2.c void main (int argc, char **argv[])

96

лабораторная работа {

}

int a; if (argc>=2) { a=atoi(argv[1]); printf(" Исходное число: %d\n",a); printf(" Двоичный вид: "); PrintNByte (&a,sizeof(int)); printf("Двоичный вид в памяти: "); PrintN2Byte (&a,sizeof(int)); printf ("по адресу %p хранится ",&a); PrintByte(&a); printf("\n"); PrintHexNByte (&a,sizeof(int)); } else { printf ("Введите число вторым параметром.\n"); }

$ gcc program5_int_representation.c &&./a.out -1013 Исходное число: -1013 Двоичный вид: 11111111 11111111 11111100 00001011 Двоичный вид в памяти: 00001011 11111100 11111111 11111111 по адресу 0x7ffffab5d81c хранится 00001011 по адресу 0x7ffffab5d81c: 0B по адресу 0x7ffffab5d81d: FC по адресу 0x7ffffab5d81e: FF по адресу 0x7ffffab5d81f: FF

Как видим, практика не расходится с теорией. (Продолжение в следующем номере.) EOF 1. Дополнительный код для представления целых чисел со знаком – http://www.dpla.ru/celye/2.10072005.htm.

2. Дидактические материалы по информатике – http://compscience.narod.ru/didakt_i.html.

3. On-line калькулятор: прямой, дополнительный и обратный коды – http://planetcalc.ru/747.

4. Two's complement – http://en.wikipedia.org/wiki/Two%27s_ complement.

5. Хоровиц П., Хилл У. Искусство схемотехники/ пер. с англ. – изд. 6-е. – М.: «Мир», 2003. – 704 c., ил. ISBN 5-03-003395-5.

6. Two's Complement Representation of Integers – http://cs.roanoke. edu/Fall2008/CPSC120B/twoscomplement.html.

7. Порядок байтов – http://ru.wikipedia.org/wiki/Порядок_байтов.

8. Programmer's guide – ftp://ftp.freepascal.org/pub/fpc/docs-pdf/ prog.pdf.

9. Функция is_int() в PHP – http://www.php.net/manual/en/function. is-int.php.

10. Митчел М., Оулдем Д., Самьюэл А. Программирование для Linux. Профессиональный подход/ пер. с англ. – М.: Издательский дом «Вильямс», 2002. ISBN 5-8459-0243-6.

11. Kip R. Irvine, Assembly Language for x86 Processors (6th Edition), Prentice Hall, 2010, ISBN-10: 013602212X, ISBN-13: 978-0136022121.

12. ГОСТ 28043-89 Персональные электронные вычислительные машины. Интерфейс накопителей на жестких несменных магнитных дисках с подвижными головками. Общие требования – http://protect.gost.ru/document.aspx?control=7&id=139432.

13. Integer (computer science) – http://en.wikipedia.org/wiki/ Integer_%28computer_science%29.

14. Документация PHP: целые числа – http://www.php.net/manual/ ru/language.types.integer.php.

15. Документация PHP: числа с плавающей точкой – http://www. php.net/manual/ru/language.types.float.php.

16. Даймонд Д., Торвальдс Л. Just for fun. Рассказ нечаянного революционера/пер. с англ. – М.: «Эксмо-Пресс», 2002, ISBN 5-04-009285-7.

март 2012 системный администратор

ИТ-управление

Как оптимизировать расходы на ИТ Обходим подводные камни

98

Хранение данных

Платформа eDocLib по модели SaaS Новый веб-сервис по хранению и обработке данных

103

Технологии

Red Hat Enterprise MRG Realtime Linux реального времени – война за микросекунды

104

Облачные технологии

Полетят ли КИС в облака? Плюсы и минусы облачного корпоративного ПО

106

Облачная фильтрация интернет-ресурсов Безопасный доступ в Интернет – приоритетная задача ИТ-отделов

108

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

Не шпион, а разведчик DLP-решение на базе Mipko Employee/Terminal Monitor

109

Виртуализация Red Hat Enterprise Virtualization 3 Выход на массовый рынок

110

БИТ

ИТ-управление

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

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

Обслуживание ИТ-инфраструктуры всегда требует определенных финансовых затрат. И чем больше в вашей сети компьютеров, тем существеннее эти расходы. Они включают в себя целый ряд статей. Прежде всего используемое для работы оборудование: персональные компьютеры, серверы, принтеры, сетевые устройства, источники бесперебойного питания. Здесь расходы можно разделить на единовременные, как правило, связанные с приобретением оборудования, и периодические – приобретение сервисного обслуживания, а также расходные материалы. Затем идут лицензии на ПО, используемое для работы. Сюда также входят как единовременные закупки лицензий, так и их регулярное продление, например, для антивирусных систем. Также стоит сказать о цене внедрения и обслуживания ИТ-систем. Здесь имеются в виду работы (услуги) по установке оборудования и приложений, а также стоимость периодического обслуживания данных систем. Работы по внедрению обычно выполняют внешние компании – системные Рисунок 1. Архитектура VMware View

98

интеграторы. Обслуживание могут выполнять как штатные системные администраторы организации, так и сторонние специалисты – аутсорсеры. И еще одна статья расходов – обеспечение информационной безопасности. С учетом требований ФЗ №152 «О персональных данных» подойти к защите данных формально, установив «какой-нибудь» антивирус и межсетевой экран, уже не получится. Рабочие места и серверы, осуществляющие обработку персональных данных, должны защищаться с помощью сертифицированных ФСТЭК и ФСБ решений. В зависимости от того, имеется ли доступ из Интернета к системам, обрабатывающим персональные данные, могут потребоваться дополнительные расходы на безопасность. Поговорим о различных подходах к экономии на ИТ-инфраструктуре. Рассмотрим организации различного масштаба, так как способы экономии различаются в зависимости от размеров компании. Начнем с оборудования.

Виртуальная оптимизация Технология виртуализации помогает существенно оптимизировать использование существующего оборудования. Например, если в организации имеется несколько физических серверов, не полностью загруженных вычислительными задачами, но при этом достаточно мощных, есть смысл переместить все эти приложения на один сервер, в виртуальную среду. Кроме того, рабочие места пользователей также можно поместить в облака, тем самым избавившись от необходимости закупать мощные компьютеры для пользователей. Облачные технологии применительно к пользователям представляют собой «плавающее» рабочее место, когда пользовательский профиль хранится в облаке и загружается по требованию. На рис. 1 представлен пример такой системы на основе VMware View. Начнем с создания виртуальной среды. Для такого окружения масштаба среднего предприятия совершенно не обязательно разворачивать всю инфраструктуру. Достаточно установить ядро системы (гипервизор), а весь остальной

март 2012 системный администратор

БИТ

ИТ-управление

функционал собрать из доступных и бесплатных сторонних компонентов. Ядро, хотя и с некоторыми ограничениями, можно тоже развернуть на бесплатной основе. В качестве гипервизора предполагается использовать vSphere ESXi 5.0. По сути, это усеченная версия Linux с оптимизированными для встраиваемых систем UNIX-утилитами, а также с добавленными компонентами от самой VMware. При работе с серверами с объемом памяти ниже 32 Гб можно использовать этот гипервизор бесплатно. Такого объема памяти вполне хватит для того, чтобы развернуть виртуальный контроллер домена, бухгалтерские приложения и базу данных для сети порядка 50 пользователей. Технические аспекты внедрения такой виртуальной среды хорошо представлены в статье [1]. Рабочие места пользователей также могут являться существенной статьей расходов. Каждая новая версия офисных пакетов требует все больше аппаратных ресурсов, соответственно необходимо приобретать компьютеры с более мощным процессором и увеличенным объемом оперативной памяти. Можно существенно снизить расходы на закупку оборудования для пользовательских рабочих мест, переместив их в виртуальную среду. Понятно, что в таком случае не нужно волноваться об обновлении клиентского места. Все переносится в центральную виртуальную машину. В случае тонкого клиента, сделанного из старой настольной техники, обслуживание также будет стремиться к нулю, т.к. для него потребуется только минимальный комплект из операционной системы и сам программный клиент – как правило, 32‑64 Мб бывает достаточно. К тому же клиент может быть не только в программном виде, но и в качестве аппаратного устройства. Так, тонкий клиент может выступать в качестве (почти) обычного монитора – например, Samsung NC240. В нем имеется поддержка кодеков RDP и PCoIP, поэтому наличие рабочей станции пользователя вовсе не обязательно – вы просто подключаете «монитор» к локальной сети и начинаете работу. Техническая реализация такого варианта подробно описана в статье [2]. Читатель, внимательно ознакомившийся со статьями [1] и [2], может сделать вывод о квалификации специалиста, который будет обслуживать такую среду. Это должен быть администратор (или администраторы), хорошо знающий не только среду виртуализации, но и превосходно разбирающийся в ОС семейства Linux, т.к. для полноценного осуществления управления бесплатной виртуальной средой, описанной в первой статье, необходимо самостоятельно разрабатывать различные сценарии и командные файлы. Соответственно оплата труда таких специалистов должна быть выше. Еще один вариант оптимизации, объединяющий в себе два описанных ранее и предназначенный прежде всего для малых предприятий, представлен в статье [3]. Итак, подводя итог приведенным предложениям по оптимизации использования оборудования в компании, можно сделать следующие выводы: >> Реально переместить часть вычислительных нагрузок из физической в виртуальную среду. >> Виртуальная среда для малого предприятия может быть построена на бесплатных решениях.

системный администратор март 2012

>> Стоимость специалистов по таким решениям на рынке труда выше, чем тех, кто специализируется на продуктах Microsoft. Я уже коснулся темы стоимости используемого ПО, предложив применять бесплатные решения по виртуализации. Но более подробно мы рассмотрим тему стоимости ПО в следующем разделе.

Технология виртуализации помогает существенно оптимизировать использование существующего оборудования Свободное или платное? Свободное ПО сейчас обсуждают даже на самом высшем уровне. Достаточно вспомнить историю с Национальной программной платформой, которая, помимо прочего, должна использовать свободное ПО. Существует мнение, что свободное ПО и бесплатное ПО – одно и то же. Это не совсем так. Свободное ПО (free software) – программы, которые можно использовать, распространять, копировать, изменять (совершенствовать), обычно код таких программ открыт, они юридически защищены с помощью свободных лицензий. Бесплатное ПО (Freeware) – программы, за которые пользователь не должен платить «правообладателю», причем это зафиксировано в лицензионном соглашении. Это ПО обычно нельзя изменять (совершенствовать) и распространять (например, записывать на диск и продавать). Помимо этого, существует проблема именования бесплатного и свободного ПО. Многие тексты по программному обеспечению составляются на английском языке, на который слова «свободный» и «бесплатный» переводятся одинаково – «free». Это может создавать путаницу в именовании. Так появился термин Freeware, а для обозначения свободного и открытого ПО – термин FOSS (Free and Open Source Software). Однако фонд свободного программного обеспечения рекомендует называть свободное программное обеспечение «free software». Исходя из вышеизложенного хотелось бы рекомендовать при внедрении не требующего покупки лицензии ПО внимательно относиться к тому, какого оно типа. Если программа бесплатная, но нет возможности ее модифицировать, вы можете попасть в ситуацию, когда доработка ее крайне дорога или попросту невозможна. Например, по причине того, что разработчик бесплатной программы давно уже забросил свой проект и удалил исходный код программы. Использование бесплатных программ может привести к крайне неприятным последствиям. Наличие свободных исходных кодов намного упрощает доработку приложения под свои нужды. В зависимости от сложности задачи для доработки может быть достаточно одного квалифицированного программиста. Совсем другое дело, когда требуемая система разрабатывается с нуля.

99

БИТ

В процессе написания статьи в Интернете появились неофициальные версии ГОСТ Р 54593-2011 о внедрении свободного ПО в России [4]. Помимо прочего, в документе обозначаются основные термины, которые относятся к свободному и проприетарному ПО, открытым стандартам, протоколам и спецификациям.

Рекомендую при внедрении ПО, не требующего покупки лицензии, внимательно относиться к тому, какого оно типа Что нам стоит дом построить Когда руководство какой-либо компании принимает решение о внедрении корпоративной информационной системы (КИС), тут же возникает резонный вопрос: разрабатывать самим или привлечь стороннюю компанию-разработчика? В первом случае компания-разработчик привлекается еще на этапе анализа бизнес-процессов. Производится оптимизация, выбирается наилучшее решение. Затем системный архитектор проектирует КИС и руководит разработкой системы. Разработанное приложение передается тестировщикам, которые проводят его всестороннее тестирование. Технический писатель готовит инструкции для администраторов и пользователей системы. Затем разработанная КИС передается заказчику. При этом поддержка должна осуществляться в режиме 7/24, что позволяет избежать простоев в работе бизнес-процессов заказчика. Кроме всего прочего, при использовании внешнего разработчика не надо думать об оплате отпусков, больничных и других социальных выплатах для разработчиков – все это проблема другой компании. Во втором случае внедрение КИС обойдется существенно дороже, и, несмотря на все преимущества, которые дает использование профессиональных разработчиков, выбирают первый вариант. Обычно небольшие компании нанимают одного-двух программистов (зачастую студентов), которым ставится задача, и они разрабатывают код. При этом не привлекаются ни аналитики для анализа бизнес-процессов, ни архитекторы, способные оптимально спроектировать решение, ни тестировщики, проверяющие разрабатываемое приложение на наличие ошибок и уязвимостей. Не используются технические писатели для разработки документации для приложения. Также не уделяется должного внимания организации поддержки внедряемого приложения и обучению администраторов и пользователей.

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

100

ИТ-управление

предлагается набор размытых пожеланий, зачастую противоречащих друг другу. Программисты пишут код, при этом ничего не документируется, отсутствуют комментарии и контроль версий. Тестирование производится постольку поскольку, программисты сами проверяют написанные ими же процедуры. Протестированную таким образом систему передают в опытную эксплуатацию, которая плавно перетекает в промышленную. Процесс этот происходит не быстро, и часто программисты, которые начинали писать систему, к моменту ее ввода в эксплуатацию уходят, а пришедшим на их место требуется время, чтобы разобраться в незадокументированном решении. Это приводит к увеличению сроков разработки КИС. К тому же плохо оттестированное решение, будучи переданным в эксплуатацию, периодически «падает», останавливая соответствующие бизнес-процессы в организации. Еще одним недостатком такого самописного решения является плохая масштабируемость. За время разработки и внедрения компания может расширяться, у нее появляются территориально распределенные филиалы, которым также необходимо подключиться к системе. Появляются новые ОС и приложения. Проблема масштабируемости довольно распространенная, достаточно вспомнить, что во многих госучреждениях до сих пор используются «досовские» приложения. Те самые, с интерфейсом синего цвета, написанные в СУБД FoxPro. А ведь MS DOS давно уже не поддерживается компанией Microsoft. Почему я об этом напоминаю? Потому, что далеко не всегда разработка корпоративного приложения собственными силами является хорошим решением. Существует большая вероятность, что написание КИС собственными силами приведет к превращению системы в «долгострой» с множеством проблем, на которые будет потрачено намного больше средств, чем на разработку и внедрение сторонними силами. Итак, мы разобрались с тем, как можно оптимизировать расходы на аппаратную часть. Поговорили о разработке ПО. Теперь рассмотрим элементы инфраструктуры: ОС, СУБД, веб-сервер и т.д. Также не лишним будет вспомнить и о системных администраторах и расходах, связанных с их содержанием.

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

март 2012 системный администратор

БИТ

ИТ-управление

Что же остается? Как уже упоминалось, в качестве ОС и основных инфраструктурных приложений (СУБД, веб-сервер, виртуализация) можно использовать проприетарное или бесплатное ПО. Казалось бы, здесь все просто. Выбор коммерческого ПО ведет к дополнительным расходам, в то время как свободное ПО можно использовать бесплатно. Тут как нельзя кстати можно вспомнить последние политические веяния, связанные с разработкой национальной программной платформы и общей популяризацией свободного ПО. Но имеется ряд подводных камней, о которых необходимо знать.

Проприетарное ПО За использование проприетарного ПО придется платить. Однако что вы получаете взамен? Как правило, коммерческое ПО поддерживается разработчиком. В случае возникновения каких-либо проблем вы можете обратиться в службу технической поддержки разработчика и вправе рассчитывать на решение своей проблемы. В зависимости от условий договора, поддержка может осуществляться в режиме 7/24, а также с выездом специалистов по продукту непосредственно к заказчику. Стоит отметить, что крупные компании предпочитают использовать только коммерческие программные продукты именно потому, что есть к кому обращаться за поддержкой и предъявлять претензии в случае сбоев. Кроме того, проприетарные решения широко известны, компании-разработчики их активно рекламируют на всевозможных выставках и конференциях. Благодаря известности этих продуктов существует немало различной литературы и учебных курсов, с помощью которых большое количество специалистов овладевают данными решениями. В качестве примеров можно взять такие компании, как Microsoft, Oracle, Cisco. Их решения хорошо известны, существует масса литературы, учебных курсов и программ сертификации по их продуктам. Как следствие, на рынке труда всегда имеются системные администраторы и разработчики, владеющие данными решениями. Соответственно зарплатные ожидания этих специалистов более-менее адекватны и соответствуют рынку труда. Поэтому при внедрении, например, инфраструктуры Microsoft Active Directory вы можете сразу спланировать, сколько будет стоить наем специалистов, поддерживающих данную инфраструктуру, или обучение уже имеющихся администраторов на соответствующих курсах. Совокупная стоимость владения становится до определенной степени прозрачной. Также можно еще до приобретения лицензий спланировать, сколько будет стоить ее обслуживание как минимум на ближайший год.

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

системный администратор март 2012

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

Выбор коммерческого ПО - это дополнительные расходы. Свободное ПО можно использовать бесплатно. Но имеется ряд подводных камней, о которых необходимо знать Стоимость обслуживания А сейчас, продолжая тему стоимости обслуживания ИТинфраструктуры, хотелось бы рассмотреть ряд моментов, связанных с конфигурациями сетевой инфраструктуры, которые приходится обслуживать как Linux, так и Windowsсистемным администраторам. Как пример рассмотрим Linux и стандартный набор свободно распространяемых приложений: Apache в качестве веб-сервера, BIND в качестве службы DNS, Samba в качестве файлового сервера и аналога части компонент Active Directory, Postfix в качестве почтового сервера. Системный администратор разворачивает в корпоративной сети бесплатные программные решения. Например, все серверы и рабочие станции разворачиваются исключительно на основе Linux, Samba в качестве службы файловых серверов, Apache как веб и почтовую службу на базе Postfix. А еще можно вспомнить про IP-телефонию на базе Asterisk. Все это активно дополняется различными сценариями собственного написания, пересборками ядра ОС, доработками конфигурационных файлов и прочими нетривиальными действиями. Естественно, данный специалист обладает достаточно высокими навыками администрирования подобных систем. Что происходит со временем? Наш квалифицированный специалист покидает компанию. Причин тому может быть множество, например, отсутствие перспектив роста или однообразие работы, но главным поводом, как правило, является недостаточная, по мнению работника, оплата труда. Руководство компании не хочет повышать его зарплату, так как считает, что сможет легко найти ему замену. И тут начинается самое интересное. Кадровые специалисты обнаруживают, что найти человека, разбирающегося во всем этом «зоопарке», в принципе достаточно сложно. Такие специалисты не сидят без работы, а для того, чтобы переманить человека, необходимо сделать ему более интересное предложение с приличным окладом. К тому же на поиск необходимого компании специалиста может уйти несколько месяцев, в течение которых сеть либо не будет обслуживаться вообще, что чревато огромными финансовыми потерями в случае сбоев, либо придется привлекать стороннюю компанию аутсорсера, что так-

101

БИТ

же потребует дополнительных и весьма существенных финансовых затрат. Теперь рассмотрим сетевую инфраструктуру на базе решений Microsoft. Здесь присутствует типовая конфигурация, рекомендуемая разработчиком, а именно служба глобального каталога Active Directory, почтовые серверы на базе MS Exchange, система электронного документооборота Sharepoint и другие продукты. Набор внедренных решений – типовой, если системный администратор, обслуживающий сеть, покидает компанию, найти замену ему будет гораздо легче. Время поиска такого специалиста, как правило, не превышает трех месяцев. Предлагаю рассмотреть уровень оплаты труда системных администраторов Linux и Windows.

Кто дороже? Сравним зарплаты Linux и Windows-специалистов. Для того чтобы выяснить, какие специалисты сколько стоят, я воспользовался списком вакансий из двух открытых источников: сайтов hh.ru и rabota.yandex.ru. Была выполнена выборка по следующим критериям: раздел – Информационные технологии и Интернет, специальность – системный администратор, город – Москва, только вакансии с указанием зарплаты, ключевые слова – сначала Linux, потом Windows. Общая картина на обоих сервисах оказалась похожей. В среднем квалифицированный специалист с опытом работы по специальности от двух лет и знанием администрирования ОС семейства Linux и основных инфраструктурных сервисов (Apache, Sendmail, Postfix и т.д.) мог рассчитывать на зарплату от 80 до 100 тысяч рублей. Специалист по Windows с аналогичным опытом работы мог рассчитывать на зарплату от 50 до 70 тысяч рублей. Наличие сертификатов могло дать прибавку до 80 тысяч. Традиционно «портили» статистику вакансии для специалистов широкого профиля, то есть те, в которых требовалось как знание Windows, так и Linux-систем. «Многорукий шива» со знанием Windows, Exchange, MS SQL, Linux, Sendmail, MySQL и наличием соответствующих сертификатов может попытать счастье на вакансиях до 120 тысяч рублей. Однако многопрофильного специалиста найти еще сложнее, кроме того, человеческие силы не безграничны, и, взвалив на одного специалиста поддержку всей сетевой и серверной инфраструктуры, тем самым заставив его работать по 12 часов без выходных, работодатель рискует, что администратор просто устанет от такой жизни и также покинет компанию. Поэтому не стоит рассчитывать заменить одним человеком нескольких специалистов. В результате сравнения уровня зарплат можно сделать вывод, что в среднем специалисты по Linux обходятся работодателю на 30 процентов дороже, чем по Windows. Так что при внедрении бесплатных решений не все однозначно, и не стоит забывать о таких моментах.

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

102

ИТ-управление

меваю прежде всего операционные системы, не входящие в семейство Windows, и соответствующие приложения. Если для специалиста различия между рабочим столом Windows XP и KDE минимальны (по крайней мере в KDE всегда можно все настроить так, как удобно), то для пользователей все не так тривиально. Если бухгалтер несколько лет работал в Windows XP и привык к определенному набору значков, приложений и горячих клавиш, то переучиваться на что-то другое ему будет очень сложно. Для многих может оказаться проще сменить место работы, нежели освоить новые приложения. Кроме того, недовольство пользователей может серьезно осложнить взаимоотношения ИТ-департамента с другими отделами и, как следствие, с руководством компании. Также не стоит забывать и об аппаратных тонких клиентах, которые могут вызвать некоторые неудобства для пользователей. Таким образом, необходимо предусмотреть обязательное обучение пользователей новым нестандартным приложениям, а это, в свою очередь, ведет к удорожанию обслуживания ИТ. *** В своей статье я постарался рассмотреть основные моменты, возникающие при внедрении и обслуживании ИТ. Мы разобрались с тем, как можно оптимизировать расходы на аппаратную часть. Основным направлением оптимизации можно считать уход в виртуализацию и облачные технологии. Поговорили о разработке ПО. Разработка собственных приложений, как правило, обходится гораздо дороже, чем привлечение сторонних компаний. И, наконец, рассмотрели вопрос использования проприетарного и бесплатного ПО. Здесь я постарался указать на те подводные камни, с которыми придется столкнуться при внедрении и обслуживании бесплатного ПО. Думаю, что многие читатели не согласятся с теми критическими доводами, которые я привел относительно использования бесплатного ПО. Однако я хочу отметить, что, во‑первых, целью данной статьи не была критика свободного ПО как такового, а лишь привлечение внимания к ряду аспектов его внедрения. Во-вторых, не думаю, что специалистам по Linux-системам следует чего-то опасаться. По данным рынка труда, они достаточно востребованы, и уровень предлагаемой зарплаты в среднем для них на треть выше, чем у специалистов по Windows. EOF 1. Борисов А. Облако в руках. //«Системный администратор», №10, 2011 г. – С. 18-25.

2. Борисов А. Виртуальное рабочее место с помощью VMware View 5.0. Часть 1. //«Системный администратор», №11, 2011 г. – С. 22-27.

3. Борисов А. Виртуальное рабочее место с помощью VMware View 5.0. Часть 2. //«Системный администратор», №12, 2011 г. – С. 24-29.

4. Назаренко А. Инфопространство для малого бизнеса. //«Системный администратор», №12, 2010 г. – С. 110- 111 (http:// samag.ru/archive/article/1044).

5. Неофициальные версии ГОСТ Р 54593-2011 о внедрении свободного ПО в России – http://linuxwizard.ru/download/ gost_54593-2011_sample.pdf.

март 2012 системный администратор

хранение данных

БИТ

Платформа eDocLib по модели SaaS

Новый веб-сервис по хранению и обработке данных

На кого рассчитан новый сервис? Какие наиболее типичные задачи он позволяет решить? В чем преимущества использования сервиса для бизнес-пользователей? На эти и другие вопросы «СА» отвечает Сергей Полтев, менеджер по продуктам компании ЭОC

Беседовал Евгений Захаров

В чем основная идея нового сервиса и кто его потенциальные пользователи? Основная идея – в предоставлении доступа к продукту eDocLib по модели SaaS. В первую очередь в числе пользователей нового сервиса мы ожидаем увидеть наших действующих и потенциальных клиентов по системе eDocLib. О преимуществах SaaS – гибкости, масштабируемости, снижении рисков, уменьшении единовременных платежей – сказано уже очень много. Параллельно с ростом рынка аренды приложений наблюдается и стабильно растущий спрос на решения для управления корпоративным контентом. Быстрый рост объемов неструктурированной информации, который уже давно отмечали аналитики, сегодня наблюдается практически в каждой организации. И в ситуации, когда нужно получить максимально быстрый результат от внедрения системы управления корпоративным контентом, использование SaaS-услуг, в частности eDocLib как веб-сервиса, может быть подходящим выбором. Другая потенциальная группа пользователей сервиса – независимые разработчики, использующие платформу eDocLib для разработки собственных приложений. Запуск веб-сервиса предоставляет им качественно новые возможности, например, для разработки мобильных приложений, использующих для хранения данных eDocLib как веб-сервис. Можно ли выделить характерные признаки, указывающие на то, что в организации необходимо внедрение какой-либо системы для управления корпоративным контентом, например eDocLib? По определению основная задача любого решения для управления корпоративным контентом, или Enterprise Content Management ( ECM), – это своевременное обеспечение сотрудников организации необходимой им информацией. Соответственно внедрение ECM-решения оправданно, если извлечение необходимых для работы файлов и документов становится «узким местом» в ключевых бизнес-процессах компании. Среди наиболее распространенных случаев – наличие нескольких копий одного и того же документа, использование некорректных версий файлов и документов, затруднен контроль за действиями сотрудников, риск случайной или преднамеренной утраты информа-

системный администратор март 2012

ции. Низкий уровень надежности хранения информации – еще одна характерная проблема. Почему из довольно широкой линейки продуктов компании ЭОС для предоставления по модели SaaS выбрано именно решение eDocLib? Потому что это простая, легкая система в плане принятия решения о ее внедрении. Она достаточно демократична по ресурсам и по затратам на ее администрирование. То есть не требуется значительного времени на ее изучение, дополнительных затрат на аппаратное обеспечение. eDocLib всегда была самой доступной системой из всех, которые наша компания поставляла. Арендовать eDocLib по модели SaaS можно всего за несколько тысяч рублей в месяц. И получить, таким образом, возможность выстраивания и структурирования информационных потоков, внедрить методологию взаимодействия сотрудников и работы с информацией, одним словом, все основные возможности ECM-cистемы. Что касается других продуктов нашей компании, в частности, хорошо известных СЭД «ДЕЛО» и EOS for SharePoint 2010, то технологически они также готовы для использования по модели SaaS, но запуск соответствующих сервисов – дело ближайшего будущего, и об этом мы объявим дополнительно. Принято считать, что использование приложений по модели SaaS связано с повышенными рисками. Как обстоят дела с вашим веб-сервисом? Да, некоторое время назад был такой расхожий набор мифов о якобы высоких рисках и низком качестве решений по модели SaaS. Что касается качества услуги, то мы совместно с нашими партнерами потратили значительные усилия на то, чтобы пользователи веб-сервиса получали такое же качественное решение, как и пользователи «коробочного продукта». Завершающим этапом стало проведение нагрузочного тестирования на мощностях провайдера, подтвердившего оптимальные параметры аппаратно-программного решения и хороший запас по быстродействию. Что касается рисков, связанных с надежностью хранения и доступностью информации, то все необходимые гарантии, в том числе и юридические, обеспечиваются хостинг-провайдером. ADV

103

БИТ

технологии

Визитка

Алексей Ермаков, инженер. Работает в НЦПР, участвует в проектах по виртуализации Red Hat

Red Hat Enterprise MRG Realtime

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

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

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

Red Hat Enterprise MRG Realtime: основные особенности Одной из наиболее распространенных систем реального времени является Red Hat Enterprise MRG Realtime. Техни-

Рисунок 1. Время обработки события системой на базе стандартного ядра Linux и на базе MRG Realtime

104

март 2012 системный администратор

БИТ

технологии

В ОС реального времени неприемлемо «в среднем быстро», только «гарантированно быстро для каждого запроса»

чески MRG Realtime – это набор пакетов, превращающих стандартный Red Hat Enterprise Linux (RHEL) в ОС реального времени. MRG Realtime состоит фактически из двух компонентов – ядра реального времени, заменяющего стандартное ядро RHEL, и набора инструментов для настройки и тонкой профилировки.

MRG Realtime обеспечивает для критичных к задержкам задач стабильное время отклика с разрешением вплоть до микросекунд. Разница в скорости обработки событий стандартной ОС общего назначения и MRG Realtime наглядно видна из рис.1. На графике красным показано время обработки событий системой на базе стандартного ядра Linux и зеленым – системой на базе MRG Realtime. По оси X отложен номер события, по оси Y – время обработки в микросекундах. Масштаб времени по шкале Y логарифмический. Обычное ядро в среднем тратит на обработку одного события 9 мкс со стандартным отклонением 54.94 мкс. Ядро MRG Realtime позволяет достичь значения 8 мкс со стандартным отклонением 1.49 мкс. Чтобы такие результаты стали возможны, в ядро MRG Realtime было внесено заметное количество изменений по сравнению со стандартным ядром RHEL – переработаны механизмы работы с блокировками, включены таймеры высокого разрешения, невытесняемые участки кода ядра разбиты на минимальные блоки, сделан ряд других оптимизаций. Но все же основная особенность MRG Realtime не в этом. Главное отличие MRG Realtime от других ОС реального времени в том, что фактически, кроме ядра, не изменено ничего (строго говоря, изменения были, но они уже внесены в апстрим). Сегодня API RHEL и API MRG одинаковы, с точки зрения приложений они ничем не отличаются, и это позволяет запустить на MRG Realtime все то же программное обеспечение, которое было написано и собрано для RHEL. В результате становится возможным крайне быстро перенести приложения на ОС реального времени и начать работать с ними в новой среде. Разумеется, это не гаран-

системный администратор март 2012

тирует, что все мгновенно заработает с микросекундными задержками. Внедрение MRG Realtime – это всегда процесс взаимной оптимизации приложений, системы и инфраструктуры. Тем не менее крайне важно, что для начала работы не нужно что-либо переписывать и заново отлаживать. Можно сначала запустить систему с привычными приложениями, измерить полученные задержки на разных этапах обработки, после чего для достижения целевых показателей вносить правки только там, где они оказались объективно нужны.

Где это работает Области применения систем реального времени разнообразны. >> В телекоммуникациях для обеспечения качества связи. Так, на базе MRG Realtime работает оборудование Alcatel-Lucent [4]. >> В финансовом секторе – на биржах и в инвестиционных банках, где роботы соревнуются с роботами и «время – деньги». Большинство мировых компаний в этой области перешло на MRG Realtime, среди российских компаний ее используют ММВБ [2] и «Тройка-Диалог» [3]. >> В военных системах, когда время уже даже не деньги, а гораздо больше. Например, MRG Realtime активно используется в проекте Zumwalt Destroyer ВМФ США [5]. ADV 1. Материалы по MRG Realtime (на английском) – http://www. redhat.com/products/mrg/realtime.

2. Опыт использования MRG Realtime в ММВБ – http://www.cnews. ru/news/line/index.shtml?2011/12/09/468195.

3. Опыт использования MRG Realtime в «Тройка-Диалог» – http:// www.pcweek.ru/foss/wp/detail.php?ID=130860.

4. MRG Realtime в оборудовании Alcatel-Lucent – http://www. europe.redhat.com/news/article/2373.html.

5. Разработка системы реального времени для Zumwalt Destroyer – http://press.redhat.com/about/news/blog/red-hatenterprise-mrg-red-hat-customer-driven-innovation-and-opensource-leadership

105

БИТ

облачные технологии

Визитка Сергей Горшков, технический директор компании index.art. Руководитель более чем ста проектов по автоматизации предприятий. Автор книги «Построение информационных систем на платформе index.CRM»

Полетят ли КИС в облака? В пользе облаков для частных пользователей уже мало кто сомневается, а вот стоит ли переносить в них корпоративные информационные системы – вопрос гораздо более дискуссионный

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

SaaS – способ предоставления программного обеспечения, ключевыми особенностями которого являются: оплата права использования продукта на определенное время (аренда), его размещение в дата-центре (и доступ через Интернет), предоставление услуг хостинга и технической поддержки в одном пакете с правом использования продукта. Корпоративные информационные системы – это продукты, автоматизирующие те или иные бизнес-процессы организации. Они могут относиться к классам CRM, ERP, СЭД или представлять собой уникальные разработки, учитывающие особенности бизнес-процессов компании. Если офисные приложения, например текстовые редакторы или электронные таблицы, довольно легко перенести на облачную платформу (как показывает опыт сервиса Google Docs), то в случае корпоративной информационной системы не все так однозначно.

о клиентах, ведь таких случаев немало?» Если злоумышленники не будут найдены, то никто. А уж если что-то произойдет с компанией-поставщиком услуги… Об этом и подумать страшно. Преимущества облака на этом фоне будут выглядеть не столь солидно: можно надеяться на снижение затрат на внедрение и поддержку, перераспределение во времени вложений в лицензии и быстроту развертывания продукта. Не менее важные возражения при выборе облачной CRM связаны со спецификой программной системы. Для многих компаний процесс обслуживания клиентов – основное конкурентное преимущество. Если фирма существует на рынке, где сами товары или услуги более или менее стандартны, поддерживать лояльность клиентов можно только за счет такой организации бизнес-процессов, которая будет выгодно отличать компанию от ее конкурентов. Главную роль в достижении этой цели будет играть CRM, которая должна поддерживать заведомо не стандартные бизнес-процессы, а в идеале еще и служить инструментом коммуникации с клиентом. Понятно, что типовой продукт таких задач не решит: не могут же у всех компаний быть одинаковые преимущества. А по модели SaaS по определению поставляются только типовые решения… Даже если предположить, что поставщик ПО разрешит настройку или доработку арендованной CRM, какой в этом будет смысл? Все равно что делать капитальный ремонт в арендованной квартире. Если же рассматривать ERP или отраслевые системы, то наличие возможности доработки продукта однозначно становится обязательным требованием.

А почему бы и нет?

Выходит, что перенос корпоративных информационных систем в облака невозможен? К счастью, это не так. На Западе давно и успешно существуют облачные CRM-решения, такие как SalesLogix или SugarCRM. В чем секрет их успеха, каким образом они преодолевают перечисленные проблемы?

Представим себе директора, который рассматривает возможность использования облачной CRM. Он начинает размышлять: «Что делать, если отключат Интернет?» Как это ни печально – ничего: работа отдела продаж практически остановится. «Кто ответит, если произойдет утечка данных

106

CRM – полет нормальный!

март 2012 системный администратор

облачные технологии

В первую очередь благодаря гибкой политике поставщиков ПО, предлагающих разные решения для различных категорий клиентов. Для малых предприятий с типовыми бизнес-процессами (кстати, на Западе их намного больше, чем в России) подойдут «чистые» SaaS-решения. Ведь лояльность клиентов автосалона, небольшой юридической компании, салона красоты зависит не столько от качества или скорости обслуживания, сколько от того, что кому-то они просто географически ближе. На другом полюсе окажутся крупные (а значит, глобальные, по охвату рынка) корпорации, для которых типовые решения заведомо неприемлемы, ведь они существуют в условиях жесточайшей конкуренции с себе подобными. Их ресурсы позволяют быстро достигнуть уровня конкурентов в любой сфере, будь то улучшения продуктов, логистики или сервиса. Поэтому конкурентные преимущества в сфере работы с клиентами, формирования и поддержки лояльности имеют для таких компаний первостепенное значение. Развивать эти преимущества можно только с помощью собственной – во всех смыслах – CRM-системы. Для таких клиентов у производителей успешных SaaS-продуктов есть предложения другого характера. Разумеется, такая система будет дорабатываться, и интеллектуальные права на результаты работ будут принадлежать заказчику – ни одна серьезная компания не согласится на то, чтобы плодами ее усилий воспользовались конкуренты. Так что вендор будет оказывать услуги по индивидуальной доработке системы – если, конечно, ему интересны крупные клиенты. На первый план среди аргументов перехода в облака для таких клиентов выходит обеспечение надежной поддержки и хостинга приложения – с соответствующим уровнем ответственности по SLA (Service Layer Agreement – документ, устанавливающий требования к качеству услуги и ответственность поставщика за соблюдение заданных параметров). Термин SaaS в данном случае несколько размывается, от него остаются только частные аспекты: хостинг системы, способ оплаты лицензий (об этом поставщик и заказчик скорее всего договорятся индивидуально, как, впрочем, случается и при поставке обычных информационных систем). Между этими крайними случаями лежит множество промежуточных вариаций, которые и будут интересны огромному большинству предприятий. Компромиссные версии SaaS, предусматривающие синтез облачной идеологии и традиционного подхода к КИС, предлагают как лидеры мировой индустрии, так и российские вендоры.

БИТ

>> возможности индивидуальной настройки, а лучше адаптации (доработки) системы по требованиям заказчика; >> размещение в надежном дата-центре с реальной (а не фиктивной, как это часто случается!) ответственностью за выполнение SLA и обеспечение безопасности. Опираясь на четырехлетний опыт продвижения SaaSпродуктов на рынке CRM, мы можем утверждать, что российские компании выбирают облачный вариант приложения в тех случаях, когда выполняется одно из условий: >> требуется быстро преодолеть серьезные проблемы в работе отдела продаж; >> бизнес-процесс только формируется, еще не устоялся, собственный стиль в работе с клиентами еще не выработан; >> компания рассматривает выбранное CRM-решение как промежуточную ступеньку на пути к более серьезной системе; >> CRM-система необходима, но выделить на нее сколько-нибудь значимые средства в данный момент невозможно. Какой бы ни была причина выбора облачной CRM, практика показывает, что, если компания работает на ней длительное время – хотя бы полгода, затем система обычно выкупается в собственность. Это дает компании возможность владеть результатами выполняемых работ по настройке системы и обладать гарантиями сохранности и доступности своих данных. Вопрос о том, где при этом будет размещена система, носит второстепенный характер – само по себе размещение ПО на хостинге еще не делает его облачным. Мы считаем, что у корпоративных информационных систем, предоставляемых по модели SaaS, большое будущее. Наступит оно тогда, когда вендоры вместо слепого следования канонам «модной» технологии обратят внимание на реальные потребности рынка, а предприниматели будут готовы использовать облачные решения не только в перечисленных выше частных случаях. Это произойдет естественным образом в процессе усложнения структуры нашей экономики, возрастания конкуренции в ее наиболее интеллектуально насыщенных отраслях. Тогда проблемы снижения временных и финансовых затрат на корпоративное ПО наряду с необходимостью обеспечивать значимые конкурентные преимущества бизнеса станут для руководителей предприятий серьезным аргументом в пользу перехода в облака. EOF

Клиент и вендор: договоримся! С точки зрения руководителя малого или среднего российского предприятия информационная система, предоставляемая по модели SaaS, должна отвечать следующим требованиям: >> возможность в любой момент выкупить систему в собственность и перенести ее на собственные серверы компании – вместе с данными; >> наличие функции регулярного экспорта всех данных в формате, допускающем возможность хотя бы частичного их использования (например, в виде электронных таблиц), как страховка для экстренных случаев;

системный администратор март 2012

107

БИТ

облачные технологии

Визитка Алексей Кищенко, начинающий специалист в области IT Security. Работает в компании Entensys, являющейся вендором программного обеспечения в сфере информационной безопасности. Хобби: IT, PR, сноуборд

Облачная фильтрация интернет-ресурсов Стремление к росту показателей производительности связано с внедрением информационных технологий. Построение системы коммуникаций на базе средств глобальной сети приводят не только к ускорению обмена данными, но и к появлению ряда угроз. Безопасный доступ в Интернет – приоритетная задача ИТ-отделов

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

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

GateWall DNS Filter Cloud – облачное решение, основанное на фильтрации DNS-запросов, позволяющее блокировать опасные и нецелевые ресурсы, анализировать практику использования Интернета. Сервис использует в работе технологию Entensys URL Filtering. Каким образом осуществляется фильтрация DNS-запросов? Любое устройство, подключенное к сети Интернет, использует определенный сервер DNS. В тот момент, когда сотрудник компании набирает в адресной строке браузера URL-ресурс, например, «yandex.ru», его запрос перенаправляется на DNS-сервер, который в свою очередь возращает IP-адрес сайта. Только после этого пользователь наблюдает загрузку необходимой ему страницы.

GateWall DNS Filter Cloud позволяет фильтровать сайты самых разных направлений, например, «Социальные сети» или «Игры». База, используемая решением, насчитывает более 500 млн ресурсов, разделенных для удобства оперирования на более чем 80 категорий.

GateWall DNS Filter Cloud предоставляет возможность получать статистику по посещенным категориям сайтов, по разрешенным и блокированным хитам. Использование данных отчетов позволяет качественно анализировать проблемы, связанные с нецелевым использованием Интернета. Управление сервисом осуществляется в специальном личном кабинете пользователя, который становится доступным сразу же после подключения.

Как подключить сервис? Клиент регистрируется на сайте www.entensys.ru как пользователь облачных решений и получает доступ в Личный кабинет. После регистрации активируется 30-дневное бесплатное использование облачного сервиса. ADV

108

март 2012 системный администратор

БИТ

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

Визитка Александр Кириленко, инженер по информационной безопасности Международного научного центра информационных технологий

Не шпион, а разведчик

DLP-решение на базе Mipko Employee/Terminal Monitor Согласно регулярным исследованиям Cisco Systems главную «дыру » в ИБ компаний образуют социальные сети:именно оттуда в корпоративную сеть чаще всего попадает вредоносное ПО. Более того, социальные сети всё чаще становятся каналом утечек внутренней информации

Очевидное решение (для недальновидных руководителей) – «взять и запретить» использование не относящихся к рабочему процессу сервисов, дополнив его мониторингом корпоративной почты. Однако такой подход не учитывает оффлайн составляющую (копирование информации на носители, саботаж путем удаления информации) и отторжение со стороны сотрудников (для 75% людей до 30 лет такое «закручивание гаек» снижает привлекательность работы). Если же ИБ компании строится продуманно, то в ее структуре не обойтись без DLP-системы (от англ. – система предотвращения утечки). На рынке чаще можно встретить иностранные продукты, которые при возможных преимуществах обладают значительным минусом – они не адаптированы к нашим реалиям. Отечественные же ИБ-решения, такие как, например, программы компании Mipko, подготовлены разработчиками, в частности, для перехвата сообщений, чатов, действия пользователей в характерных для наших широт соцсетях: Вконтакте, Facebook. Продукты Mipko были упомянуты недаром, поскольку в бизнес-сегменте по соотношению «цена-качество» их решения – Mipko Employee Monitor и Mipko Terminal Monitor – одни из самых интересных. Mipko Employee Monitor предназначен для индивидуальных рабочих машин – устанавливается и настраивается на рабочем ПК сотрудника и вне зависимости от режима работы (скрытого или явного) защищен от блокирования и удаления рядовым пользователем. Утилита перехватывает нажатия клавиш (возможно применение шаблонов для сигнальных слов), периодически делает снимки экрана сотрудника, фиксирует запускаемые программы, посещенные сайты и активность на них (чаты, блоги, комментарии), выполняет мониторинг мессенджеров. Эта информация поступает администратору в реальном времени, сигнализируя о подозрительной активности, или в виде регулярных отчетов по е-mail или FTP. Замечание: читателям журнала «Системный администратор» эксклюзивно предлагается скидочный купон (промо-код), дающий право на 20% дисконта при покупке ПО Mipko. Подробности см. на http://www.mipko.ru/samag.

системный администратор март 2012

Для ИТ-инфраструктуры организации на базе сервера и оконечных терминалов следует использовать Mipko Terminal Monitor. В этом случае утилита работает на терминальном Windows или Citrix-сервере, ведя отдельные логи для каждого входящего в систему сотрудника.

Mipko Monitor поддерживают все Windows-платформы начиная с Win2K (поддержка Mac реализована в персональных версиях Mipko Monitor). Установка и настройка не требуют специальных навыков (хотя это не означает, что решение вопроса должно быть доверено непрофессионалам), тем более что справочная информация вшита в интерфейс: пояснения и примеры доступны рядом с его элементами. Для работы ПО необходим минимум ресурсов, но в зависимости от количества ПК, разрешения их мониторов, качества и частоты скриншотов на клиентских машинах или сервере следует выделить достаточно свободного дискового пространства. Возникшие проблемы можно решить через русскоязычную техподдержку по телефону или онлайн-тикетам. Но по некоторому функционалу Mipko Employee/Terminal Monitor пока не дотягивают до «взрослых» (и более дорогих) DLP-систем: отмечаем отсутствие перехвата распечатанных документов и удаленных файлов, а также некорректную работу с некоторыми «экзотическими» ICQ-клиентами. Соответствующие дополнения разработчики планируют реализовать в ближайших версиях продукта. А пока это делает Mipko Employee Monitor хорошим выбором для отделов и компаний с минимумом бумажной документации (callцентры, веб-разработка). Вы также можете изучить возможности похожих DLP-программ русскоязычного происхождения компаний AtomPark Software, InfoWatch, Trafica «Инфосистемы Джет» и ознакомиться с материалами по теме. >> Страница Mipko Employee Monitor на сайте разработчика – http://www.mipko.ru/employee-monitor. >> Сравнительный обзор популярных утилит мониторинга – http://www.3dnews.ru/software/spy_tools_1. >> Как выбрать DLP-систему? – http://www.pcweek.ru/ security/article/detail.php?ID=126125. ADV

109

БИТ

виртуализация

Визитка

Оксана Курышева, инженер, RHCSA. Работает в НЦПР, участвует в проектах по виртуализации Red Hat

Red Hat Enterprise Virtualization 3 Для многих специалистов Red Hat Enterprise Virtualization до сих пор выглядит неоднозначно. С одной стороны, крупнейшие мировые облака строятся на технологиях Red Hat – их выбрали Amazon, IBM, NTT. Однако на массовом рынке RHEV развивается не столь быстро. Что несет релиз RHEV3, чтобы изменить эту ситуацию?

Рекорды и проблемы RHEV до сегодняшнего дня Чтобы понять, почему возникает различие в отношении разных пользователей, стоит обратить внимание, как Red Hat Enterprise Virtualization (RHEV) используется при создании крупнейших мировых облаков. Разумеется, облачные провайдеры не раскрывают детали архитектуры, но в одном принципиальном моменте они сходятся. В ведущих мировых облачных системах RHEV используется как инфраструктурная платформа, на базе которой создаются собственные системы провайдера – порталы для пользователей, учет потребления ресурсов, управление биллингом, инструменты управления с учетом специфики конкретного провайдера (см. рис. 1). В силу этой специфики требований основные усилия разработчиков Red Hat были направлены на улучшение гиперРисунок 1. В крупнейших мировых облаках RHEV используется как основа инфраструктуры, на базе которой создаются собственные системы провайдера

визора KVM. В результате сегодня практически все рекорды производительности в области виртуализации по общепризнанным тестам SPECvirt принадлежат Red Hat. Абсолютный рекорд у Red Hat Enterprise Linux 6.1 с гипервизором KVM на серверах HP ProLiant DL980 G7. Более того, пять следующих результатов также принадлежат Red Hat, а ближайшие результаты VMware отстают практически в два раза [5]. Однако на массовом рынке пользователям важнее не рекорды производительности и плотности виртуальных машин, а простота развертывания и использования. Поэтому новая версия RHEV3 посвящена в первую очередь улучшению и упрощению средств управления.

Основные нововведения RHEV3 Прочитать об основных возможностях и принципиальной архитектуре RHEV можно в обзоре Андрея Маркелова в «Системном администраторе» [2]. Полный список технических нововведений новой версии (RHEV3) составляет более 100 пунктов [3]. В данном обзоре остановимся на наиболее принципиальных из них.

RHEV Manager на базе JBoss В новой версии RHEV3 управляющая система (RHEV Manager, RHEV-M) полностью переписана на Java, устанавливается на JBoss в качестве сервера приложений и использует PostgreSQL для хранения данных. Это дает возможность предельно просто развернуть ее на сервере Red Hat Enterprise Linux – все необходимые компоненты, включая сам RHEV-M, устанавливаются одной командой: yum install rhevm

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

110

март 2012 системный администратор

БИТ

виртуализация

руются именно на нее. RHEV до недавнего момента не был исключением – пользователи либо заводились локально, либо брались из AD. Начиная с RHEV3 появилась возможность использовать для этого LDAP (рекомендуется IPA). Трудно сказать, сколько корпоративных пользователей обратят внимание на это нововведение. Но для хостеров, которые строят публичные облака, независимость от продуктов Microsoft, безусловно, является сильным преимуществом.

Расширенные возможности работы с системами хранения данных В RHEV3 появились средства для «живой миграции» систем хранения данных. Теперь средствами RHEV-M можно перенести образы виртуальных машин с одной системы хранения на другую без остановки работы самой машины. Раньше такой функционал можно было реализовать, но это требовало отдельной настройки за рамками RHEV-M. Теперь все необходимое интегрировано в управляющую консоль. Есть приятные нововведения и для небольших инфраструктур, где задача «живой миграции» с одной внешней СХД на другую не актуальна из-за отсутствия внешних СХД как таковых. Традиционно все промышленные системы виртуализации ориентируются на использование внешних систем хранения, так как они позволяют не думать, на каком сервере хранятся нужные образы и данные, за счет чего обеспечивают максимальную гибкость в распределении виртуальных машин между физическими хостами. Тем не менее в небольших инфраструктурах обязательное требование внешней СХД часто становится неприятным сюрпризом, из которого приходится срочно настраивать iSCSI или хотя бы NFS. В RHEV3 появилась возможность использовать локальные диски для хранения образов машин. Разумеется, в этом случае приходится пожертвовать возможностью «живой миграции». Тем не менее иногда это оказывается разумным компромиссом между богатством возможностей и стоимостью необходимого оборудования.

Улучшения SPICE для WAN Значительно улучшен SPICE – протокол доставки рабочего стола для инфраструктуры виртуальных рабочих мест (VDI). Изменения в первую очередь коснулись оптимизаций для работы на плохих каналах связи. Кроме очевидного повышения качества компрессии, появились более тонкие оптимизации, такие как динамическая подстройка степени компрессии в зависимости от качества канала и автоматическая настройка глубины цвета и эффектов рабочего стола.

Улучшение производительности Традиционно обновлен гипервизор. Теперь он основан на RHEL6.1, а это значит, что в него вошли те оптимизации, которые позволили Red Hat установить рекорд в тестах SPECVirt. ADV 1. Официальный сайт RHEV3 (на английском) – http://www.redhat. com/promo/rhev3/resources.html.

2. Обзор RHEV2 в «Системном администраторе» – http://samag. ru/archive/article/1219.

3. Технические нововведения RHEV3 (на английском, pdf) – http:// www.redhat.com/promo/rhev3/pdf/rhev_3_datasheet.pdf.

4. Сайт Open Virtualization Alliance (на английском) – http://www. openvirtualizationalliance.org.

5. Результаты тестов SPECvirt (на английском) – http://www.spec. org/virt_sc2010/results/res2011q4/virt_sc2010-20110920-00036perf.html.

Рисунок 2. Расширенный интерфейс портала для пользователей

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

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

системный администратор март 2012

111

ПРОБЛЕМ НЕТ – ЕСТЬ ЗАДАЧИ Все говорят, что нужно делать, мы рассказываем, как достичь результата. Решений много – найдите свое в «Системном администраторе». Зайдите на zinio.com, скачайте номер журнала на компьютер, планшетник, смартфон. Читайте «Системный администратор». Теперь это просто! Цена одного номера – 120 рублей. Годовая подписка – 1200 рублей.