Дипломная работа тема работы Обеспечение безопасности системы управления инфраструктурой центра обработки дан


Глава 1 Обзор тенденций и основ информационной безопасности



Pdf просмотр
страница2/5
Дата14.11.2016
Размер2.99 Mb.
Просмотров1895
Скачиваний3
ТипДиплом
1   2   3   4   5
Глава 1 Обзор тенденций и основ информационной безопасности
На первом этапе работы было проведено исследование современных тенденций в сфере защиты информации, проведено знакомство с базовыми понятиями информационной безопасности, шифрования и аутентификации.
1.1 Оценка тенденций в сфере защиты информации
В ноябре 1988 года, Роберт Моррис-младший (Robert Morris, Jr.) выпустил в Интернет своего первого “червя”. Тогда администраторы информационных систем впервые столкнулись с реальной опасностью всемирного масштаба.
“Червь” Морриса привел к потере тысяч часов рабочего времени системных администраторов [1].
С тех пор и по настоящее время наблюдается рост числа инцидентов в области информационной безопасности. Международной ассоциацией, объединяющей профессионалов в области ИТ-аудита, ИТ-консалтинга, управления ИТ-рисками и информационной безопасности ISACA (Information
Systems Audit and Control Association) в 2015 году было проведено исследование в области кибербезопасности. Опрос более полутора тысяч специалистов по защите информации показал:
 более 75% опрошенных отметили увеличение количества атак в
2014 году по сравнению с 2013;
 30% опрошенных в 2014 году имели дело со взломами и кражей конфиденциальной информации.
 82% опрошенных ожидают роста количества инцидентов в 2015 году [2].
По данным Лаборатории Касперского в 2006 году было зафиксировано 86 880 уникальных вредоносных объектов (скрипты, эксплойты, исполняемые файлы и т.д.), в 2015 году эта цифра составила 121 262 075 [3] [4].

19
Одновременно с количеством эволюционирует и качество угроз.
Хакерская деятельность все больше приобретает черты организованной преступности [2]. Число вредоносных объектов, которые обнаруживаются в сети ежегодно, исчисляется миллиардами, их распространение ведется более чем со
100 миллионов интернет адресов [5]. Каждый год их число увеличивается на
40%. Атаки в информационном пространстве наносят ущерб, который оценивается в сотни миллиардов долларов [6]. По заявлению начальника Бюро специальных технических мероприятий МВД России Алексея Мошкова каждую секунду 12 человек на Земле становятся жертвами киберпреступников. Только в
России удалось предотвратить хищение около 1 миллиарда рублей с банковских счетов граждан [7].
Эти тенденции призывают системных администраторов уделять особое внимание информационной безопасности.
1.2 Информационная безопасность
Безопасность информации — это свойство (состояние) передаваемой, накапливаемой, обрабатываемой и хранимой информации, характеризующее ее степень защищенности от дестабилизирующего воздействия внешней среды
(человека и природы) и внутренних угроз, то есть ее конфиденциальность
(секретность, смысловая или информационная скрытность), сигнальная скрытность (энергетическая и структурная) и целостность — устойчивость к разрушающим, имитирующим и искажающим воздействиям и помехам [8].
Базовая система безопасности строится на четырех основных принципах безопасности: учет, конфиденциальность, целостность и доступность [9].
 Учет — сохранение и обработка отчетов по всем событиям и опе- рациям, которые произошли в инфраструктуре ЦОД.

20
 Конфиденциальность — обеспечение необходимой секретности ин- формации и предоставление доступа только авторизованным поль- зователям.
 Целостность — неизменность информации. Целью данной службы является предотвращение неавторизованного изменения или разру- шения информации.
 Доступность — означает надежный и своевременный доступ для авторизованных пользователей.
Угрозы — это потенциальные атаки, которые могут быть выполнены на инфраструктуру. Такие атаки можно классифицировать как активные или пассивные. Пассивные атаки являются попытками получить неразрешенный доступ к системе. Они ставят под угрозу конфиденциальность информации.
Активные атаки означают модификацию данных, отказ в обслуживании, и атаки сокрытия авторства. Они ставят под угрозу целостность и доступность информации.
Область атаки, вектор атаки и показатель трудозатрат — это три фактора которые следует учитывать при оценке меры уязвимости окружения для угроз безопасности. Область атаки относится к различным точкам входа, которые атакующий может использовать для запуска атаки. Вектор атаки — это шаг или серия шагов, необходимых для выполнения атаки. Показатель трудозатрат означает сумму времени и усилий, необходимую для использования вектора атаки.
Идеальная безопасность недостижима, так как в модели безопасности практически любой системы есть несколько фундаментальных изъянов, которые невозможно преодолеть.
Программное обеспечение ориентировано, прежде всего, на удобство применения, что отнюдь не предполагает естественность и простоту защиты.
Концепция разработки и применения современного программного обеспечения заключается в обеспечении удобного манипулирования данными в сетевой многопользовательской среде.

21
Программное обеспечение разрабатывается большим сообществом программистов. Все они имеют разную квалификацию, по-разному относятся к своей работе и обладают различными знаниями о строении операционной системы и ее особенностях. Поэтому даже самые современные средства зашиты, выпущенные с самыми благими намерениями, могут приводить к появлению новых уязвимостей [1].
Для создания абсолютно непробиваемой защиты придется изолировать компьютер от всех устройств доступа (и, возможно, поместить его в специальную комнату, стены которой не пропускают электромагнитное излучение). Однако, попытаться изолировать информацию от лиц, для которых она не предназначена, можно не прибегая к столь кардинальным методам. Эту задачу, с разной степенью успешности, помогает решить шифрование. Здесь нужно понимать, что шифрование — это лишь инструмент в руках человека и только лишь шифрованием данных обеспечить безопасность не получится. Как написал в соей книге Брюс Шнайер — автор нескольких бестселлеров и признанный специалист в области безопасности и защиты информации:
«Безопасность – это цепь: где тонко, там и рвется» и «Безопасность – это процесс, а не продукт» [10].
Эффективность безопасности может быть измерена двумя критериями.
Во-первых, стоимость применения системы должна составлять лишь небольшую долю ценности защищаемой информации. Во-вторых, потенциальный атакующий должен затратить больше времени и денег, чтобы испортить систему, в сравнении со стоимостью защищенной информации [9].
1.3 Шифрование и аутентификация
Вопросами шифрования, дешифрования и расшифровки занимается наука под названием криптология. Криптография — раздел криптологии отвечающий за изобретение шифров. Искусство взлома шифров называется

22 криптоанализом. Сообщения, подлежащие зашифровке, называемые открытым текстом, преобразуются с помощью функции (алгоритма), вторым входным параметром которой является ключ. В 1883 году фламандским венным криптографом Аугустом Керкгофом был высказан следующий принцип: алгоритмы шифрования общедоступны; секретны только ключи [11].
Этот принцип, хоть и далеко не сразу, но получил широкое применение в современной криптографии. В январе 1997 года Национальный институт стандартов и технологий (NIST — National Institute of Standards and Technology)
— агентство Министерства торговли, занимающееся разработкой стандартов для
Федерального правительства США, — даже организовал открытый конкурс на лучший алгоритм для нового стандарта. Для представления своих разработок на этот конкурс были приглашены ученые со всего мира [11]. Все представленные на конкурсе алгоритмы были общедоступны, зашифрованные этими алгоритмами экземпляры открытого текста целенаправленно подвергались криптоанализу с целью выявить слабые стороны алгоритмов.
Различают симметричные и ассиметричные алгоритмы шифрования, либо, как их еще называют, алгоритмы с симметричным и открытым ключом соответсвенно. В первом случае для шифрования и дешифрования применяется один и тот же ключ, во втором существует открытый и закрытый ключи.
Открытым ключом осуществляется шифрование данных, а закрытым дешифрование. Суть ассиметричных алгоритмов шифрования состоит в том, что из открытого ключа в разумные сроки невозможно получить закрытый ключ.
Для получения открытого и закрытого ключа используются однонаправленные функции, к примеру, умножение двух больших простых чисел. Получить произведение, перемножив числа, не трудно. При этом на сегодняшний день считается, что разложить произведение на множители и получить два больших простых числа, нелегко. К несчастью для проектировщиков алгоритмов, этот процесс становится всё легче. В 1976 году
Ричард Гай (Richard Guy) писал: «Я был бы немало удивлен, если бы кто-нибудь научился разлагать на множители произвольные числа порядка 10 80
в течение

23 данного столетия» [12]. В 1977 году Рон Ривест (Ron Rivest) заявил, что разложение на множители 125-разрядного числа потребует 40 квадриллионов лет
[13]. В 1994 году было разложено на множители 129-разрядное число [14]. Из этого можно сделать следующие выводы: во-первых, предсказывать глупо; во- вторых, длину ключа стоит выбирать исходя из вычислительной мощности современных систем и существующих математических методов.
Вычислительная мощь обычно измеряется в mips-годах: годовая работа компьютера, выполняющего миллион операций в секунду. Разложение на множители ключа длиной 2048 бит при помощи алгоритма решета специального поля чисел занимает 4*10 14
mips-лет. Эта длина ключа рекомендована для использования в корпоративных сетях на 2015 год [15].
Помимо шифрования данных криптография нашла применение в вопросах идентификации собеседников в сети — аутентификация. Для задач аутентификации широкое применение нашли ассиметричные алгоритмы шифрования [8]. Для целей аутентификации используется та же ключевая пара, что и для шифрования: открытый ключ, закрытый ключ. Однако, применяются они с точностью до наоборот. Шифрование производят закрытым ключом, а дешифрование открытым. Суть алгоритма аутентификации по ассиметричным ключам можно выразить следующим образом:
1. Клиент инициализирует подключение к серверу;
2. Сервер генерирует произвольную строку и отправляет её клиенту;
3. Клиент шифрует полученную от сервера строку своим закрытым ключом и отправляет получившееся сообщение серверу;
4. Сервер дешифрует сообщение открытым ключом клиента и сравни- вает с отправленным ранее сообщением. Если сообщения равны, то клиент считается аутентифицированным.
Таким образом осуществляется подтверждение собеседника в сети. Идея заключается в том, что зашифровать сообщение таким образом, чтобы оно дешифровалось открытым ключом клиента, может только сам клиент, обладающий закрытым ключом. Очевидно, что прежде чем использовать

24 алгоритм аутентификации по ассиметричным ключам необходимо каким-либо образом передать на сервер открытый ключ клиента.

25
Глава 2 Исследование системы управления ЦОД в контексте
информационной безопасности
ЦОД ТПУ представляет собой инфраструктуру виртуализации, которая построена с целью консолидировать вычислительные ресурсы и ресурсы хранения данных. Благодаря консолидации снижаются накладные расходы на обеспечение бесперебойного электропитания и теплоотведения, появляется возможность использовать оборудование более высокого класса надежности и функциональности. Вопросами администрирования ЦОД и большинства размещенных в нем виртуальных машин занимается структурное подразделение
Главный информационный узел ТПУ (ГИУ). Помимо сотрудников ГИУ административный доступ к ряду виртуальных машин должны иметь сотрудники других структурных подразделений ТПУ, чьи информационные системы размещены на мощностях ЦОД.
В начале января 2016 года на мощностях ЦОД было размещено 575 виртуальных машин. Из них 260 машин под управлением различных версий
Microsoft Windows и 315 под управлением различных дистрибутивов GNU/Linux.
Подробная статистика по операционным системам виртуальных машин ЦОД приведена в таблице 1.
Таблица 1 — Виртуальные машины ЦОД в разрезе гостевых операционных систем
Гостевая операционная система
Количество, шт.
Microsoft Windows
260
CentOS Linux
210
Ubuntu Linux
52
Gentoo Linux
23
Debian Linux
23
Oracle Linux
6
SUSE Linux
1
Итого
575
Виртуальные машины под управлением Microsoft Windows по большей

26 части представляют собой клиентские машины, серверы домена, серверы корпоративной электронной почты, терминальные серверы с различным набором прикладного программного обеспечения. Все они включены в домен при помощи
LDAP-совместимой службы каталогов Active Directory. Рассмотрение вопросов обеспечения информационной безопасности операционных систем семейства
Microsoft Windows выходит за рамки данной работы.
Виртуальные машины ЦОД под управлением дистрибутивов GNU/Linux составляют основу, на которой размещены ключевые информационные системы
ТПУ. В число таких ресурсов входят: службы динамической настройки узлов, службы доменных имен в зоне tpu.ru, основная база данных университета, сайты домена tpu.ru, корпоративный портал, системы электронного документооборота, облачное файловое хранилище, системы резервного копирования и многое другое. Виртуальные машины размещены в публичных и приватных сетях, в зависимости от назначения. Система управления этим сегментом ЦОД имела хаотичный самоорганизующийся характер.
Учетные данные администратора атомарной виртуальной машины определялись исполнителем в момент её создания. Зачастую всё сводилось к установке пароля администратора, который знали все сотрудники отдела. Не существовало механизма оперативной смены учетных данных с правами администратора на случай их компрометации.
Настройки удаленного доступа также определялись администратором в момент создания виртуальной машины и зачастую оставлялись «по умолчанию».
При этом настройки «по умолчанию» имеют ряд проблем безопасности, к примеру, разрешен удаленный вход администратора под обезличенной учетной записью.
Обновления безопасности программного обеспечения устанавливались вручную после того как административному персоналу становилось известно о наличии уязвимостей в том или ином программном пакете. Установка обновлений безопасности на большое количество обслуживаемых узлов в ручном режиме требовала больших трудозатрат и неизбежно приводила к

27 ошибкам обусловленным человеческим фактором. Администратор или группа администраторов могла легко пропустить какой-либо узел. Тем самым оставив его уязвимым для атак злоумышленников.
Отсутствовал централизованный сбор журналируемой информации, т.е. журналы хранились только локально на самих виртуальных машинах. Таким образом потенциальный взломщик имел возможность скрыть последствия своего проникновения отредактировав соответствующие журналы.
На рисунке 1 изображен пример поведения администраторов и злоумышленника в условиях системы управления до работ по модернизации.
ПК1 и ПК2 — это рабочие станции администраторов, которые имеют санкционированный доступ к управляемым узлам. Управляемые узлы на рисунке изображены элементами У1, У2 и У3. ПК3 — это рабочее место злоумышленника, атакующего управляемые узлы. Стрелками показаны соединения к управляемым узлам с примером передаваемых данных.
Администраторы, работающие за ПК1 и ПК2, аутентифицируются на управляемых узлах используя учетную запись «root» и пароль «x».
Злоумышленник эксплуатирует уязвимость программного обеспечения на У1, что приводит к выводу узла из строя, затем подбирает пароль к У2 и справившись удаляет следы из журнала, на У3 заходит уже зная учетные данные.

28
Для формирования требований к системе управления инфраструктурой с учетом выявленных проблем результаты исследования были помещены в таблицу 2.
Таблица 2 — Проблемы выявленные в системе управления ЦОД
Проблема
Угроза
Аутентификация по паролю
Потенциальная возможность пере- хвата пароля — угроза всем четырем основным принципам безопасности
Использование обезличенной учетной записи
Невозможность отследить авторство внесенных изменений — угроза принципу учета
У1
У2
У3
ПК1
ПК2
user: root; pass: x user: root; pass: x user: root; pass: x
ПК3
user: root; pass: x эксплуатация уязвимости user: root; pass: a, b … x
Журнал:
root вошел в систему с ПК1
kernel panic
Журнал:
root вошел в систему с ПК1
root отказано с ПК3
root отказано с ПК3
root вошел в систему с ПК3
Журнал:
root вошел в систему с ПК2
root вошел в систему с ПК3
Рисунок 1 — Система управления до модернизации

29
Проблема
Угроза
Отсутствие механизма оператив- ной смены учетных данных
Увеличивает время реакции при ком- прометации учетных данных
Отсутствие контроля за конфигу- рацией удаленного доступа
Могут быть включены «опасные» настройки, к примеру, уязвимые ал- горитмы установления защищенного соединения, либо возможность входа под обезличенной учетной записью
Отсутствие защиты от атак под- бора учетных данных
Вероятная компрометация учетных данных
Установка обновлений безопас- ности в ручном режиме
Увеличивает вероятность эксплуата- ции уязвимости программного обес- печения — угроза принципу доступ- ности
Отсутствие централизованного сбора журналов
Невозможно анализировать ситуа- цию, успешная атака может остаться незамеченной — нарушение прин- ципа учета
Использование сторонник источ- ников обновлений
Вероятность подмены инсталляцион- ного пакета программного обеспече- ния — нарушение принципа целост- ности
2.1 Область атаки атомарной виртуальной машины ЦОД
На основе информации собранной в таблице 2 была определена область атаки атомарной виртуальной машины под управлением операционной системы
GNU/Linux.

Эксплуатации уязвимостей программного обеспечения.

30

Подмена инсталляционного пакета.

Утечки учетных данных администратора.

Подбор учетных данных администратора.
Эксплуатация уязвимостей программного обеспечения несет большую угрозу информационным системам. Этот тип атаки хорошо поддается автоматизации. После того как уязвимость становится известна, в сети Интернет появляются инструменты для её эксплуатации, в следствии чего резко снижается показатель трудозатрат на осуществление успешного взлома. Взломщику не приходится даже вникать в суть уязвимости, вектор атаки сводится к одному шагу — нацелить инструмент на систему, а всё остальное сделает за него программа. По данным CVE Community, сообщества стремящегося вести централизованный учет обнаруженных в программном обеспечении уязвимостей, в 2015 году было зарегистрировано более 5000 уязвимостей программного обеспечения [16]. Значительно снизить риск можно оперативным обновлением программного обеспечения. Идея заключается в том, что эксплуатировать неизвестные уязвимости значительно сложнее, чем известные.
Атака на информационную систему может быть осуществлена через подмену инсталляционного пакета с новым или обновляемым программным обеспечением. Злоумышленник может создать управляемую удаленно закладку, которая позволит ему проникнуть в систему. Для защиты от атак данного характера инфраструктура распространения программного обеспечения в популярных дистрибутивах GNU/Linux использует контрольные суммы и электронные подписи [17] [18].
Утечка учетных данных администратора может произойти в результате перехвата, в момент передачи по сети, методом подбора, либо подменой сервера аутентификации. Во всех трех случаях снизить вероятность утечки учетных данных позволяет криптография.
Для того чтобы защитить учетные данные от перехвата можно просто не передавать их по сети. В программном обеспечении OpenSSH, реализации протокола Secure Shell (SSH), эта техника используется в методе аутентификации

31 по открытым ключам, когда по сети передается только подпись, полученная шифрованием сообщения от сервера закрытым ключом администратора.
Закрытый ключ администратора рекомендуется защитить парольной фразой, при этом ни парольная фраза, ни сам закрытый ключ в процессе аутентификации не покидают пределов рабочей станции администратора [19].
В случае успешной компрометации одной системы, к примеру, через уязвимость программного обеспечения, злоумышленник может перехватить пароль администратора, тем самым скомпрометированными окажутся все системы, на которые этот администратор имеет доступ. В случае использования обезличенной учетной записи, присутствующей на всех системах, скомпрометированными оказываются они все. Аутентификация по открытым ключам исключает компрометацию закрытого ключа даже в случае компрометации сервера аутентификации [19].
Защитить информационную систему от подбора учетных данных можно двумя способами: увеличив длину пароля, либо установив лимит на количество неудачных попыток аутентификации. При использовании аутентификации по ключам задача подбора сводится к получению открытого ключа и вычислению по нему закрытого. Здесь безопасность определяется длиной ключа и стойкостью алгоритма. Опираясь на выводы Брюса Шнайера (Bruce Schneier) примем, что оптимальная длина открытого ключа на сегодняшний день равна 2048 бит [15].
Точно так же как администратор аутентифицируется на сервере, сервер должен аутентифицироваться на рабочей станции администратора, предоставляя свой публичный ключ и сообщение зашифрованное закрытым ключом. Так как подразумевается, что закрытый ключ сервера неизвестен атакующему, то он не в состоянии предоставить администратору сообщение, дешифруемое публичным ключом оригинального сервера.


32
Глава 3 Проектирование системы управления инфраструктурой
Опираясь на выводы, сделанные выше были сформированы требования к системе управления. Эти требования относительно выявленных проблем собраны в таблицу 3.
Таблица 3 — Требования к системе управления инфраструктурой
Проблема
Решение
Аутентификация по паролю
Рассмотреть альтернативные ме- тоды аутентификации
Использование обезличенной учетной записи
Завести каждому администратору личную учетную запись
Отсутствие механизма оператив- ной смены учетных данных
Реализовать механизм оператив- ной смены учетных данных
Отсутствие контроля за конфи- гурацией удаленного доступа
Реализовать механизм контроля за конфигурацией удаленного до- ступа и возможность оперативного её изменения
Отсутствие защиты от атак под- бора учетных данных
Реализовать механизм защиты сер- висов аутентификации от атак под- бора учетных данных
Установка обновлений безопас- ности в ручном режиме
Реализовать механизм позволяю- щий включать автоматическое об- новление по требованию
Отсутствие централизованного сбора журналов
Реализовать централизованный сбор журналируемой информации
В дополнение к требованиям из таблицы 3, анализируя устройство существующей инфраструктуры, можно предъявить следующие требования к системе управления:

33
 система должна управляться централизованно;
 система должна поддерживать профили узлов и профили админи- страторов;
 система должна иметь возможность разделять пользователей на группы доступа;
 система должна иметь возможность управлять узлами, находящи- мися в приватных сетях;
 в случае отказа системы управления, управляемые узлы должны про- должать функционировать в штатном режиме;
 система должна поддерживать дистрибутивы построенные на базе операционной системы GNU/Linux из таблицы Таблица 1, т.е. использу- ющие пакетную базу rpm, deb и исходные тексты;
 система должна быть бесплатной и основанной на программном обеспечении с открытым исходным кодом.
В результате в распоряжении структурного подразделения ГИУ должна быть система, отвечающая всем основным задачам, сформулированным в этом разделе.
3.1 Выбор типа аутентификации
Как уже было сказано выше, аутентификация по паролю имеет ряд недостатков, отрицательно влияющих на уровень безопасности. Ниже приведены альтернативные методы аутентификации доступные в свободной реализации протокола SSH программном пакете OpenSSH.
3.1.1 Аутентификация по протоколу GSSAPI
Аутентификация с использованием общего программного интерфейса

34 сервисов безопасности (GSSAPI). GSSAPI стандартизирован IETF и представляет собой набор стандартных интерфейсов при помощи которых обеспечивается совместимость между различными сервисами безопасности [20].
К примеру, используя GSSAPI возможно аутентифицироваться на сервере
OpenSSH используя билет Kerberos от сервера Active Directory в домене Microsoft
Windows. Безопасность данного метода аутентификации зависит от безопасности программного продукта OpenSSH, реализации GSSAPI, нижележащего метода обеспечивающего аутентификацию, к примеру Kerberos и всех протоколов, которые используют эти протоколы [21].
3.1.2 Аутентификация по принципу доверенных узлов
Если узел, с которой пользователь инициализирует подключение, указан в файле /etc/hosts.equiv или /etc/shosts.equiv на удаленном узле и имена пользователей совпадают на обоих узлах, либо если файлы
/.rhosts или
/.shosts присутствуют в домашней директории пользователя на удаленном узле и содержат имя узла, с которого пользователь инициирует подключение, и имя пользователя этой машины, то пользователь считается аутентифицированным.
Дополнительно удаленный узел должен проверять ключ узла клиента в файле
/etc/ssh/ssh_known_hosts или
/.ssh/known_hosts для разрешения входа. Это дополнение закрывает угрозу атаки подменой IP, подменой DNS, либо подменой маршрута [22].
3.1.3 Аутентификация по открытым ключам
Схема базируется на криптографии открытых ключей или, как её еще называют ассиметричной криптографии, когда шифрование и дешифрование осуществляется разными ключами. Идея таких ключей заключается в том, что должно быть невозможно в короткие сроки получить ключ дешифрования

35
(закрытый) из ключа шифрования (открытый). Сервер должен знать открытый ключ и только аутентифицирующийся пользователь должен знать закрытый ключ. OpenSSH поддерживает следующие алгоритмы ассиметричного шифрования: DSA, ECDSA, Ed25519 и RSA [22]. Однако, начиная с версии
OpenSSH 7.0 алгоритм DSA отключен в ввиду его недостаточно стойкости [23].
Подтверждения уязвимости алгоритма DSA найти не удалось. В более ранних реализациях OpenSSH, к примеру OpenSSH-6.9p1, в реализации утилиты ssh-keygen, которая отвечает за генерацию ключей шифрования, можно найти следующий участок кода:
1. maxbits = (type == KEY_DSA) ?
2. OPENSSL_DSA_MAX_MODULUS_BITS : OPENSSL_RSA_MAX_MODULUS_BITS;
3. if (*bitsp > maxbits)
4. fatal("key bits exceeds maximum %d", maxbits);
5. if (type == KEY_DSA && *bitsp != 1024)
6. fatal("DSA keys must be 1024 bits");
OPENSSL_DSA_MAX_MODULUS_BITS это константа из заголовочного файла библиотеки OpenSSL, которая равна 10000. Таким образом, первые четыре строки проверяют не превышает ли указанная в процессе длина ключа значения в 10000 бит. При этом следующие две строки строго ограничивают длину ключа в 1024 бит. Такой противоречивый код может служить результатом того, что он был написан в разное время, а возможно и разными людьми. Ограничение длины
DSA ключа в 1024 бит было установлено стандартом FIPS 186-2, который был опубликован Национальным институтом стандартов и технологий США 27 января 2000 года [24]. Однако, с того времени было выпущено еще две редакции данного стандарта. В настоящий момент, на май 2016 года последняя версия стандарта FIPS 186-4 регламентирует использовать длину DSA ключа в 1024,
2048 и 3072 бит [25]. Можно предположить, что уязвимой является реализация
DSA именно в программном продукте OpenSSH.
Алгоритм Ed25519 является довольно новым для проекта OpenSSH. Этот алгоритм был добавлен в версии OpenSSH 6.5, которая вышла 29 января 2014 года [26]. Этот факт не позволяет нам использовать данный алгоритм, так как в

36 инфраструктуре ЦОД присутствуют дистрибутивы операционной системы
GNU/Linux которые получают только обновления безопасности и в которых версия OpenSSH никогда не будет обновлена до 6.5.
Алгоритмы ECDSA был добавлен в версии 5.7, которая вышла 23 января
2011 года [27]. Однако и этой версии нет, к примеру, в CentOS 5, виртуальные машины на основе которой еще используются в инфраструктуре ЦОД.
Наиболее широко распространенным алгоритмом является RSA. На май
2016 года он всё еще считается стойким при использовании длины ключа в 4096 бит [15]. RSA имеет проблемы быстродействия из-за довольно большой длины ключа, по сравнениями с алгоритмами основанными на эллиптических кривых
ECDSA и Ed25519. Однако этот недостаток не является существенным, так как ассиметричные алгоритмы используются только на этапе установления защищенного соединения и в процессе аутентификации. Всё остальное время сессия шифруется симметричным алгоритмом, к примеру, таким как AES [19].
Учитывая всё вышесказанное, для использования в системе управления, был выбран метод аутентификации по открытым ключам (Public key authentication) и алгоритма ассиметричного шифрования RSA с длиной ключа в
4096 бит.
3.2 Выбор способа распространения учетных записей
Проблемой под номером 2 требований к реализуемой системе управления из таблицы 3 являлось использование администраторами обезличенной учетной записи на всех управляемых узлах. Было решено завести каждому администратору личную учетную запись. Данное решение потребовало выработать механизм распространения учетных записей между управляемыми узлами. Были рассмотрены службы каталогов узлов NIS, LDAP и службы управления конфигурациями узлов Puppet, Chef, Ansible и Salt.

37
3.2.1 Network Information Service
Network Information Service (NIS) представляет собой клиент-серверный каталог для распространения между узлами такой информации как учетные данные пользователей и имена узлов. NIS был разработан компанией Sun
Microsystems и изначально назывался Yellow Pages по аналогии с бумажным справочником, в котором перечисляются телефонные номера, но, из-за судебных преследований владельцами торговой марки, был переименован в NIS [28].
NIS является довольно старой разработкой, его улучшенная версия NIS+ была выпущена всё той же Sun Microsystems в 1992 году как часть операционной системы Solaris 2. В 2012 году компания Oracle, ранее купившая Sun
Microsystems, объявила о прекращении поддержки NIS+. Начиная с версии
Solaris 11 данный программный продукт исключен из операционной системы
[29].
NIS можно сконфигурировать в качестве сервера аутентификации в сети.
Однако, функционала данной службы недостаточно для распространения публичных ключей администраторов. Следовательно, необходимо разрабатывать дополнительный механизм для распространения публичных ключей администраторов.
NIS не поддерживает защиту данных на уровне сети. Вся передаваемая между клиентом и сервером информация проходит по сети в открытом виде.
Учитывая всё вышеперечисленное, был сделан вывод о том, что данная система не подходит в качестве механизма распространения учетных записей.
3.2.2 Lightweight Directory Access Protocol
Lightweight Directory Access Protocol (LDAP) предоставляет доступ к службе каталогов X.500. X.500 набор стандартов разработанных международным

38 консультационным комитетом по телефонии и телеграфии (МККТ, ITU-T) для упорядочивания и обеспечения взаимной совместимости каталогов описывающих объекты вычислительных сетей, такие как пользователи, компьютеры, почтовые адреса, сервисы, группы и многое другое [30]. LDAP разработан и стандартизирован IETF, как облегченный вариант разработанного
ITU-IT протокола DAP. LDAP — позволяет производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей [31].
LDAP является широко используемым стандартом доступа к службам каталогов. Из свободно распространяемых открытых реализаций наиболее известен сервер OpenLDAP, из проприетарных — поддержка протокола имеется в Active Directory — службе каталогов от компании Microsoft, предназначенной для централизации управления сетями Windows.
LDAP поддерживает доступ к данным каталога по защищенному каналу связи. Узлы под управлением дистрибутивов GNU/Linux поддерживают аутентификацию с использованием сервера LDAP. OpenSSH можно настроить на получение публичных ключей с сервера LDAP.
Несмотря на всё вышеперечисленное данный механизм был отвергнут в силу того, что использование сервера или кластера LDAP совместимых серверов привносят потенциальную угрозу доступности в систему управления узлами.
Очевидно, что при проблемах коммуникации управляемого узла и сервера LDAP, администраторы будут испытывать проблемы аутентификации.
3.2.3 Puppet
Puppet — это система автоматизации распространения конфигурации между узлами под управлением операционными системами GNU/Linux, Unix и
Windows. Puppet позволяет выполнять административные задачи, такие как добавление пользователя, установка пакетов, изменение конфигурационных

39 файлов на основе централизованного описания.
Конфигурация узлов пишется на сервере (puppet master) на специальном декларативном предметно-ориентированном языке. По своей структуре язык похож на Ruby. На узлах устанавливается агент (puppet agent), который периодически опрашивает сервер для получения обновлений конфигурации.
Поддерживаются два механизма, обеспечивающих защиту системы на уровне сети передачи данных.
 Первый механизм, используемый по умолчанию, только подписы- вает передаваемые данные, но не шифрует их. Подпись произво- дится SSL сертификатом, который генерируется для каждого узла в процессе подключения его к системе. Таким образом обеспечива- ется аутентификация всех передаваемых между сервером и агентом сообщений и их учет;
 Второй механизм, предполагает шифрования всех передаваемых данных симметричным алгоритмом шифрования AES, а процедуру аутентификации обеспечивает ассиметричная ключевая пара RSA
[32].
3.2.4 Chef
Chef — это, как и Puppet, система автоматизации распространения конфигурации между узлами. в нем также имеется сервер и агенты, установленные на управляемых узлах. В дополнение к серверу, установка Chef также требует рабочей станции, для управления им. Агенты могут быть установлены с рабочей станции с помощью утилиты knife, которая использует протокол SSH для подключения к узлам. После этого, управляемые узлы аутентифицируются на сервере при помощи SSL сертификатов [33].
Конфигурация Chef тесно связана с системой управления версиями Git, поэтому знание того, как работает Git необходимо для работы. Так же, как и

40
Puppet, Chef основан на ruby, поэтому потребуется и знание этого языка. Как и в случае с Puppet. Модули могут быть загружены или написаны «с нуля», после чего установлены на управляемые узлы, в соответствии с требуемыми настройками [34].
3.2.5 Ansible
Ansible имеет отличную от Puppet и Chef архитектуру. Ansible не требует установки агентов на управляемые узлы. Взаимодействие сервера и управляемых узлов осуществляетося с использованием протокола SSH. В Puppet и Chef агенты, установленные на узлах, инициализируют подключение к серверу и получают обновления конфигурации. В Ansible подключение инициализирует сервер, применяя описанную в сценарии конфигурацию к набору узлов. Ansible написан на Python, в отличие от Puppet и Chef, основанных на Ruby. Это позволяет управлять конфигурацией узлов, где присутствует Python, без установки какого- либо дополнительного программного обеспечения [35].
Установка Ansible может быть выполнена путем клонирования Git- репозитория на машину с которой будет осуществляется управление, либо из репозитория дистрибутива. Ansible использует протокол SSH для взаимодействия с узлами. Следовательно, все вопросы безопасности на уровне сетевого взаимодействия решает SSH. Ansible, вместо стандартного OpenSSH, может использовать Paramiko — реализацию протокола SSH на языке Python.
Ansible может быть запущен из командной строки без использования конфигурационных файлов для простых задач, таких как проверка, что некий сервис запущен, или для обновления триггеров и перезагрузки. Для более комплексных задач, конфигурационные файлы создаются с помощью YAML и называются «сценарии» (playbook). В них могут быть использованы шаблоны для расширения функциональности [36].

41
3.2.6 Salt
Salt схож с Ansible по своей архитектуре. Он использует метод push для связи с клиентами. Он может быть установлен через Git или через систему управления пакетами на сервере и клиентах. Клиент делает запрос к головному серверу, и, если тот дает разрешение, позволяет управлять данным узлом с помощью агента (в терминах Salt — minion).
Salt может связываться с клиентами по протоколу SSH, но масштабируемость значительно расширяется за счет клиентских агентов. Также,
Salt включает асинхронный файловый сервер для ускорения обслуживания агентов, позволяя создавать хорошо масштабируемые системы.
Как и в случае Ansible, есть возможность отдавать команды, такие как как запуск сервисов или установка пакетов агентам напрямую из командной строки, или использовать конфигурационные файлы в формате YAML (state), для обработки комплексных задач. Также есть централизовано размещенные наборы данных (pillar) к которым имеют доступ конфигурационные файлы во время работы.
Есть возможность получать информацию о конфигурации — такую как версия ядра или детальную информацию о сетевом интерфейсе — напрямую от агентов через командную строку. Агенты могут также задаваться через использование элементов инвентаря, называемых «зернами» (grain), позволяющими легко передавать команды на определенные сервера, безотносительно к настроенным группам. Например, одной командой можно отправить запрос к агентам, расположенным на серверах с определенной версией ядра [37].
Большим достоинством систем управления конфигурациями то, что в них описывается желаемое состояние узла, а не вектор достижения этого состояния, как при написании скриптов автоматизации на bash, perl или python. То есть описывая конфигурацию при помощи, к примеру, puppet мы задаем желаемое

42 состояние узла и нам не важно какие шаги для этого необходимо сделать системе.
При написании своих скриптов автоматизации администратор наоборот пишет ряд шагов, которые, по его мнению, должны привести систему в желаемое состояние. Данный подход, во-первых, требует хорошей проверки как самих шагов, так и их взаимного расположения, во-вторых, может быть в корне ошибочным, если администратор недостаточно хорошо представляет начальное состояние узла.
Для более наглядного обзора механизмов распространения учетных записей, плюсы и минусы каждой рассмотренной системы были сведены в таблицу 4.
Таблица 4 — Выбор способа распространения учетных записей
Критерий\Механизм
NIS
LDAP
Puppet Chef
Ansible Salt
Безопасность
0 5
5 5
5 5
Децентрализация
0 0
4 4
4 4
Взаимодействие с узлами
3 3
3 3
0 0
Документация
1 2
2 1
2 1
Итого
4 10 14 13 11 10
Для построения таблицы Таблица 4 были определены критерии по которым определялось соответствие механизма поставленным задачам.
Критерии были расположены в порядке уменьшения их значимости для данной работы.
Наиболее значимым критерием является критерий безопасности.
Механизмы, отвечающие современным требованиям к безопасности, получали 5 баллов, не отвечающие 0 баллов.
Под децентрализацией имеется ввиду единой точки отказа, которая могла бы привести к ситуации, когда администратор не имеет возможность аутентифицироваться установленным способом. Балл за выполнение этого требования равен 4 баллам.

43
Взаимодействие с узлами, т.е. как управляемые узлы подключаются к серверу управления. Если подключение инициирует сервер — 0 баллов, если управляемый узел — 3 балла.
Доступность и качество написания документации. Максимальный балл 2.
Из таблицы Таблица 4 видно, что для использования в данной работе в лучше мере подходит проект Puppet. Стоит отметить, что программный продукт
Puppet, помимо распространения учетных записей между узлами, позволяет реализовать и ряд других требований, сформулированных в начале этой главы.
Такие как механизм оперативной смены учетных данных, механизм контроля за конфигурацией удаленного доступа и возможность оперативного её изменения, механизм, позволяющий включать автоматическое обновление по требованию.
3.3 Выбор способа защиты от атак подбора учетных данных
Выбранная в пункте 3.1 модель аутентификации по открытым ключам исключает возможность осуществления атаки подбором учетных данных.
Однако, на этапе проектирования было предположено, что ряд управляемых узлов не будут исключать возможность аутентификации по паролю, к примеру, когда кому-либо потребуется доступ к узлу под учетной записью не обладающей административными полномочиями.
3.3.1 Netfilter
Netfilter является стандартным в среде операционных систем GNU/Linux межсетевым экраном. Он включен в ядро Linux начиная с версии 2.4 и постоянно эволюционирует. Другое более распространенное название Netfilter — iptables.
Iptables это утилита при помощи которой администратор может манипулировать правилами Netfilter.
OpenSSH обеспечивает доступ к узлу посредством сервиса sshd, который

44 в конфигурации по умолчанию прослушивает порт 22 по протоколу TCP. Каждое соединение по протоколу TCP начинается с пакета, в котором установлен флаг —
SYN, а флаг ACK опущен [11]. Такой пакет однозначно обозначает начало TCP соединения. Таким образом, ограничивая число подобных пакетов в определенный промежуток времени (средствами Netfilter) и ограничивая максимальное количество попыток аутентификации за одно соединение
(средствами OpenSSH), мы можем существенно усложнить либо свести на нет попытки подбора учетных данных.
Однако, у этого способа есть существенный недостаток. Это угроза доступности. Потенциальный злоумышленник может осуществить атаку на систему, подменив адрес отправителя в TCP пакете, к примеру, на адрес машины администратора. Тем самым спровоцировав разрыв соединения администратора и последующую неспособность подключиться.
3.3.2 Fail2ban
Fail2ban является приложением, которое написано на языке Python.
Основная идея заключается в том, что специальный процесс регулярно перечитывает журналы и сверяет каждую новую строку журнала с регулярным выражением. Регулярное выражение описывает неудачную попытку аутентификации. Если количество неудачных попыток аутентификации от определенного источника за определенное время превышает максимально допустимое значение, то совершается действие исключающее повторные попытки аутентификации этим источником. К примеру, в Netfilter добавляется правило запрещающее всякое взаимодействие с указанным IP-адресом.
Модель работы Fail2ban исключает угрозу доступности описанную в пункте 3.3.1. Для осуществления полноценной попытки аутентификации необходимо, чтобы TCP соединение было полностью установленным
(ESTABLISHED). Установка соединения в протоколе TCP предполагает

45 прохождения тройного рукопожатия. Инициирующая сторона отправляет TCP пакет с установленным флагом SYN, опущенным флагом ACK и значением x флага SEQ. Узел, к которому осуществляется подключение, отвечает на данный пакет пакетом с установленным флагом SYN, ACK равным x + 1 и SEQ равным y. Инициирующая сторона должна ответить пакетом с опущенным флагом SYN,
SEQ равным x + 1 и ACK равным y + 1. Соединение считается установленным только когда выполнены все три вышеописанных шага [11]. Это означает, что в случае подмены адреса отправителя, соединение установлено не будет и активность потенциального злоумышленника не отразится в журнале sshd, а значит не приведет ни к каким действиям на узле.
Принимая во внимание особенности работы Netfilter и Fail2ban, описанные в пунктах 3.3.1 и 3.3.2 предпочтение было отдано проекту Fail2ban, для целей реализации механизма защиты от атак подбора учетных записей.
3.4 Выбор системы сбора журналируемой информации
Стандарты syslog берут своё начало в проекте Sendmail, а развитие получили как часть проекта Калифорнийского университета в Беркли — Berkeley
Software Distribution (BSD) при создании TCP/IP [38] [39].
Первая попытка стандартизировать протокол была предпринята
Инженерным советом Интернета (Internet Engineering Task Force, IETF) в августе
2001 года. Тогда был выпущен информационный бюллетень RFC3164: The BSD syslog Protocol. Публикация имела информационный характер и давала ряд рекомендаций при имплементации решений для журналирования информации.
Однако, не накладывала на разработчиков четких ограничений. Затем, в ноябре
2001 года, IETF выпустил стандарт RFC3195: Reliable Delivery for syslog, в котором имелось несколько ссылок на информационный бюллетень RFC3164:
The BSD syslog Protocol. Эти ссылки позволили считать стандарт RFC3195

46 расширением концепта из RFC3164. В конечно итоге это породило много проектов, заявляющих о соответствии с RFC3195, но при этом совершенно не совместимых между собой. Стандартизация провалилась [40].
Вторая попытка стандартизировать протокол Syslog была предпринята
IETF в марте 2009. Тогда был опубликован стандарт RFC5424: The Syslog Protocol и три его расширения: защита передаваемых данных при помощи TLS (RFC5425:
Transport Layer Security (TLS) Transport Mapping for Syslog), передача журналируемых сообщений поверх UDP (RFC5426: Transmission of Syslog
Messages over UDP) и соглашения для представления текстовых полей Facility и
Severity кодами в протоколе SNMP (RFC5428: Textual Conventions for Syslog
Management) [41] [42] [43] [44]. Эти публикации возымели успех. Позже было опубликовано еще несколько стандартов расширяющих протокол дополнительными функциями, такими как: подпись журналируемых сообщений
(RFC5848: Signed Syslog Messages), защита журналируемой информации передаваемой поверх UDP протоколом DTLS (RFC6012: Datagram Transport Layer
Security (DTLS) Transport Mapping for Syslog), передача журналируемой информации поверх TCP (RFC6587: Transmission of Syslog Messages over TCP)
[45] [46] [47].
В процессе выбора системы сбора журналируемой информации были рассмотрены две системы, наиболее широко распространенные в семействе дистрибутивов операционной системы GNU/Linux: Rsyslog и Syslog-ng. Все они основаны на протоколе syslog, что должно обеспечить совместимость на уровне представления журналируемой информации.
3.4.1 Rsyslog
Rsyslog — это программный продукт с открытым исходным кодом предназначение которого заключается в сборе, преобразовании и передаче журналируемой информации представленной в соответствии с протоколом

47 rsyslog. Rsyslog эволюционировал из проекта sysklogd — оригинального проекта системы журналирования разрабатываемой в рамках операционной системы
BSD. Ключевые возможности Rsyslog:
 модульная архитектура;
 мультипоточность;
 передача сообщений через UNIX-socket, UDP и TCP;
 защита соединения при помощи SSL и TLS;
 перенаправление сообщений в системы управления базами данных
MySQL, PostgreSQL и Oracle и многие другие;
 фильтрация по любой части журналируемого сообщения;
 полностью настраиваемый выходной формат
 поддерживается режим совместимости с RFC3195 и RFC5424.
В настоящий момент Rsyslog является системой журналирования используемой по умолчанию в таких дистрибутивах операционной системы
GNU/Linux как:
 Debian Linux 6 “Squeeze”, 7 “Wheezy”, 8 “Jessie”;
 CentOS Linux 5, 6, 7;
 Red Hat Enterprise Linux 5, 6, 7;
 Ubuntu 12.04 LTS “Precise Pangolin”, 14.04 LTS “Trusty Tahr”, 15.04
“Vivid Vervet”;
 Fedora 22, 21.
Создатель проекта Rsyslog Rainer Gerhards участвовал в работе над актуальной в данный момент серией стандартов IETF посвященных протоколу syslog [40].
3.4.2 Syslog-ng
Syslog-ng (Syslog next generation) имеет такое же назначение и схожий функционал, что и Rsyslog. Syslog-ng разрабатывается компанией BalaBit IT

48
Security. Выпускается две модификации Syslog-ng: свободная Open Source Edition и коммерческая Premium Edition. Основной отличительной особенностью проекта Syslog-ng является синтаксис написания конфигурационных файлов, а именно правил получения, фильтрации и передачи журналируемых сообщений.
Язык написания конфигурационных файлов имеет объектно-ориентированную структуру. Объектами являются источники журналируемых сообщений, сами сообщения, фильтры и назначения [48].
До появления проекта Rsyslog в 2004 году, Syslog-ng использовали многие дистрибутивы GNU/Linux, такие как SLES, Gentoo Linux, Arch Linux. Однако, отказались от него в пользу Rsyslog. В 2008 году в рассылке debian- devel@lists.debian.org был поднят вопрос о смене системы журналирования по умолчанию с sysklogd на Syslog-ng или Rsyslog. В пользу второго высказалось сразу несколько разработчиков. Основными доводами в пользу Rsyslog были: поддержка конфигурационных файлов формата sysklogd без дополнительных модификаций, разработка в соответствии с принципами свободного программного обеспечения. Главным недостатком Syslog-ng был тот факт, что многие функции доступны только в коммерческой версии, а доработки и исправления, предлагаемые сообществом, принимались только после подписания разработчиком соглашения о передаче всех прав на код и зачастую включались в первую очередь в коммерческую версию [49].
В силу популярности проекта Rsyslog среди основных дистрибутивов операционной системы GNU/Linux и большей открытости, для реализации системы централизованно сбора журналируемой информации был выбран проект Rsyslog.
3.5 Выбор дистрибутива операционной системы
В 1987 году Эндрю Таненбаум написал первую версию операционной

49 системы MINIX для иллюстрации к своей книге «Операционные системы:
Разработка и реализация». MINIX в то время была выпущена под лицензией ограничивающей её использование только для образовательных целей. Линус
Торвальдс будучи студентом Хельсинского университета основываясь на ядре
MINIX разработал ядро Linux, первая версия которого вышла 5 октября 1991 года. К тому моменту проект Ричарда Столлмана GNU уже содержал солидный набор приложений, составляющих пользовательское окружение операционной системы. Единственно чего не хватало GNU — это ядра. Таким образом появилась операционная система GNU/Linux.
По данным сайта distrowatch.org, на 30 мая 2016 года насчитывалось 279 активно развивающихся дистрибутивов операционной системы GNU/Linux, а всего их насчитывается более 800 [50].
Большая часть дистрибутивов GNU/Linux берет свое начало от:
 Debian Linux;
 SLS, в последствии Slakware Linux
 Red Hat Linux, позднее переименованный в Red Hat Enterprise Linux
(RHEL).
Популярным проектом на основе Debian Linux является Ubuntu, а на базе
Red Hat Linux основаны дистрибутивы Fedora и CentOS Linux.
При этом есть и не малое число самостоятельных проектов, наиболее известные из них:
 Enoch, в последствии Gentoo Linux
 Arch Linux [51].
Выбор стоял между Gentoo Linux, Debian Linux и CentOS Linux, так как у автора данной работы имелось больше опыта работы именно с этими тремя дистрибутивами.
3.5.1 Gentoo Linux

50
Gentoo Linux развился из проекта Enoch Linux Дэниэля Робинса (Daniel
Robbins). Официальный поддерживаемый список, на май 2016 года, насчитывает
18,999 пакетов программного обеспечения [52], помимо официального существует большое количество пользовательских, которые может создать любой желающий. Пользовательские списки называются оверлеями. Оверлеи насчитывают 46398 пакетов программного обеспечения [53];
В Gentoo Linux отсутствуют регулярные выпуски. Дистрибутив обновляется постоянно. С одной стороны, это избавляет от необходимости раз в
10 лет переносить решение на новую версию дистрибутива, как в случае с
CentOS. С другой стороны, администраторы Gentoo Linux постоянно живут в процессе обновления. Если сравнивать с Debian, то обратно несовместимые обновления могут поступить только при смене стабильных выпусков, что случается примерно раз в три года.
Разработчиками проекта Gentoo создан мощнейший инструмент управления пакетами программного обеспечения — Portage. Его концептуальная идея очень похожа на порты FreeBSD. Все пакеты устанавливаясь проходят процедуру компиляция из исходных текстов, посредством системы USE-флагов и опций компиляции каждый программный продукт гибко настраивается под конкретную задачу, система слотов позволяет одновременно устанавливать несколько версий одного и того же программного обеспечения.
Система отслеживания уязвимостей Gentoo Linux Security Advisories
(GLSA) — позволяет получать отчеты о наличии в системе уязвимых пакетов и исправлять проблемы безопасности в автоматическом режиме.
3.5.2 Debian Linux
Один из старейших и популярных дистрибутивов GNU/Linux [54]. Проект
Debian имеет собственную инфраструктуру распространения пакетов программного обеспечения в формате .deb. На май 2016 стабильный релиз Debian

51 8 “Jessie” насчитывает более 43000 пакета программного обеспечения [55].
Самым главным достоинством Debian является его репутация в мире свободного программного обеспечения. Большое сообщество, отлаженная за многолетнюю историю и четко регламентированная система выпуска и поддержки дистрибутива располагают к тому чтобы использовать Debian в работе.
В среднем срок поддержки каждой версии дистрибутива составляет пять лет. С момента выпуска стабильного релиза и до релиза следующего исправления ошибок и обновления безопасности предоставляют разработчики, ответственные за пакеты и команда безопасности Debian. После того как выпускается новый стабильный релиз, еще в течение двух лет поддержку обеспечивает команда добровольцев, именуемая LTS [56].
Команда разработчиков Debian обеспечивает поддержку обновления между стабильными выпусками дистрибутива. Подобное обновление достаточно хорошо тестируется и документируется на этапе подготовки нового стабильного выпуска.
3.5.3 CentOS Linux
CentOS Linux основан на базе коммерческого RHEL. RHEL распространяется только между подписчиками, оплатившими поддержку дистрибутива, но компания Red Hat обязана публиковать исходные тексты тех программных продуктов, которые разрабатываются под лицензией GPL. Таким образом, сообщество CentOS имеет возможность компилировать приложения на основе исходных текстов RHEL. Компиляция пакетов выполняется в максимальном соответствии с RHEL, используются те же версии компиляторов и библиотек. Всё это позволяет достичь полной бинарной совместимости этих дистрибутивов, что, в свою очередь, позволяет заявлять о поддержке дистрибутивом CentOS Linux всех программных продуктов совместимых с

52
RHEL.
CentOS не обеспечивает поддержку обновлений между мажорными выпусками дистрибутива. При этом срок поддержки выпусков CentOS Linux составляет 10 лет. Подобный срок является очень хорошим показателем в индустрии.
На май 2016 выпуск CentOS Linux 7 содержит немногим более 9000 пакетов. Это существенно меньше чем в Debian и Gentoo. Однако, благодаря бинарной совместимости с RHEL, можно использовать пакеты из многих других
RHEL-совместимых дистрибутивов — это сам RHEL, Fedora Linux, Scientific
Linux, Oracle Linux и многие другие. Нужно отметить, что использование пакетов из других дистрибутивов может привести к взаимным конфликтам зависимостей программного обеспечения.
В качестве дистрибутива операционной системы GNU/Linux для реализации проекта был выбран дистрибутив Debian 8 “Jessie” архитектуры x86_64. Решающим качеством дистрибутива Debian перед Gentoo являются: простота поддержки за счет системы регулярных стабильных выпусков.
Решающим качеством дистрибутива Debian перед CentOS является широкий выбор программного обеспечения и возможность обновления между стабильными выпусками.
3.6 Концептуальная
модель
разрабатываемой
системы
управления
Было принято решение построить систему управления инфраструктурой
ЦОД ТПУ из двух узлов.

53
 Узел управления для осуществления административных операций, таких как: добавление пользователей на управляемые узлы, распро- странение публичных ключей, изменение конфигурации и обновле- ние управляемых узлов.
 Узел журналирования для сбора журналируемой информации с узла управления и управляемых узлов.
Было решено не управлять узлом журналирования при помощи узла управления, разместить узел журналирования в приватной сети ЦОД, доступ извне приватной строго ограничить на уровне межсетевого экрана шлюза сети.
3.6.1 Узел управления
Виртуальная машина, на которую были возложены функции автоматизации администрирования системы управления инфраструктурой ЦОД или узел управления. На этом узле было запланировано разместить сервер Puppet и разработанные к нему модули. Модули были разделены по основному назначению:
 модуль настройки политик удаленного доступа;
 модуль пользователей и групп;
 модуль настройки политик обновления;
 модуль настройки журналирования.
Модуль настройки политик удаленного доступа определяет настройки
OpenSSH с возможностью выбрать уровень безопасности для каждого управляемого узла. Под уровнем безопасности понимается строгость политик удаленного доступа, т.е. какие методы аутентификации будут доступны пользователям. Первый уровень безопасности предполагает аутентификацию только по публичным ключам. Второй уровень безопасности позволяет аутентифицироваться по паролю. Оба уровня запрещают аутентификацию под обезличенной учетной записью администратора. Дополнительно этот модуль

54 определяет конфигурацию Fail2ban для защиты от атак подбора учетных данных.
Модуль пользователей и групп содержит перечисление всех пользователей системы управления и их основные сведения, такие как: имя, учетная запись в домене ТПУ, публичный ключ, возможность повышать привилегия до административных. Пользователи соотнесены с группой, к которой они принадлежат. Пользователи включаются в ту или иную группу в соответствии с выполняемыми обязанностями. Модуль обеспечивает распространение учетных записей и публичных ключей по управляемым узлам.
Модуль настройки политик обновления задает источники обновлений программного обеспечения, обеспечивает возможность запускать обновление по требованию, а также отключать автоматическое обновление.
Модуль настройки журналирования активирует функцию отправления журналируемой информации на узел журналирования.
3.6.2 Узел журналирования
Виртуальная машина, на которую были возложены функции сбора журналируемой информации с управляемых узлов инфраструктуры ЦОД или узел журналирования. Было запланировано разместить на этом узле специальным образом сконфигурированный сервер Rsyslog. Назначение сервера
Rsyslog — принимать журналируемую информацию от управляемых узлов по протоколу UDP, фильтровать и перенаправлять в базу данных СУБД MySQL.
Было решено предусмотреть возможность доступа к сохраненной в базе данных журналируемой информации через web-интерфейс обеспечивающий быстрый поиск по базе данных.

1   2   3   4   5


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал