Comments 6
Познавательно, спасибо. Первая часть отлично подойдет просто для хардеринга rhel-like ОС.
(пардон, что не вычитал, много текучки).
Хочу заметить, что ~90% описанных проблем возникает при условии, что в management сеть есть неавторизованный доступ.
При том, что в этой сети ходит нешифрованный трафик миграции машин и (потенциально) нешифрованный трафик SR'ов (LVM/NFS), то правильно говорить о необходимости полной изоляции этой сети от интернета или сетей пользователей (не говоря уже про виртуалки). Аналогичная же изоляция должна быть и на хранилищах (включая NFS) — там не должно быть никого, кроме администратора системы.
Хочу заметить, что ~90% описанных проблем возникает при условии, что в management сеть есть неавторизованный доступ.
При том, что в этой сети ходит нешифрованный трафик миграции машин и (потенциально) нешифрованный трафик SR'ов (LVM/NFS), то правильно говорить о необходимости полной изоляции этой сети от интернета или сетей пользователей (не говоря уже про виртуалки). Аналогичная же изоляция должна быть и на хранилищах (включая NFS) — там не должно быть никого, кроме администратора системы.
Ну вообще да, Цитриксы в СС так и писали. Изолирование, — the best.
Спасибо, дополню описание в шапке про сеть.
Ну тут еще подход как у CIS я пытался сделать: стараться закрыть все возможные пути даже если они невозможные. Отличный пример, — CIS RHEL 2.0.
Спасибо, дополню описание в шапке про сеть.
Ну тут еще подход как у CIS я пытался сделать: стараться закрыть все возможные пути даже если они невозможные. Отличный пример, — CIS RHEL 2.0.
Вы знаете, я когда читал ваше описание, меня постоянно мучал вопрос «а что мы при этом сломаем?».
XCP (и XenServer) в том смысле, как он есть — слишком закрытая вещь. Иногда можно обнаружить, что работоспособность всего и вся зависит от мельчайшей ерундовой настройки, которая отличает(ся) от дефолтного CentOS'а.
Так получилось, что я его больше знаю «вглубь», чем «в ширь». Я могу в деталях рассказать как стартует машина, каким макаром xapi узнаёт про имя диска внутри виртуальной машины и т.д.; но если меня начать гонять по казалось бы тривиальным опциям xe (типа xe role-add) и т.д., то я ничего внятно не отвечу, потому что не интересовался.
Зато я несколько раз обжигался на казалось бы тривиальных мелочах, вроде имени network. Поменял — всё, добавление в пул новых хостов поломалось. Сделал апгрейд — обрёл смену uuid'ов у шаблонов. (У меня где-то есть корпоративный файл документации с выписанными характерными шедеврами поведения xapi в некоторых случаях — оно душераздирающе).
И есть из этого простой вывод — «работает — не трогай». Изолировал сеть, защитил(ся) от бешенных машин — всё просто замечательно.
Зато я могу рассказать про множество (неочевидных) мер безопасности, которые есть в xapi.
Например, если засра… проблемный клиент решит поставить машину на постоянный ребут, то в коде xapi есть специальная проверка — его тормознут, и с каждым ребутом его будут ребутить всё дольше и дольше — до 2 минут паузы между ребутами.
Обычно упавшая (crashed) машина перезапускается. Однако, если машина падает в течение двух минут после запуска, её так же не перезапускают (защита от циклического падения из-за кривой процедуры загрузки).
Такие же меры есть в xenstore (защита от избыточного злоупотребления).
То есть xapi просто ориентировано на защиту системы от гостевых систем, а не от «страшных внешних угроз». Их просто не должно быть за счёт изоляции.
XCP (и XenServer) в том смысле, как он есть — слишком закрытая вещь. Иногда можно обнаружить, что работоспособность всего и вся зависит от мельчайшей ерундовой настройки, которая отличает(ся) от дефолтного CentOS'а.
Так получилось, что я его больше знаю «вглубь», чем «в ширь». Я могу в деталях рассказать как стартует машина, каким макаром xapi узнаёт про имя диска внутри виртуальной машины и т.д.; но если меня начать гонять по казалось бы тривиальным опциям xe (типа xe role-add) и т.д., то я ничего внятно не отвечу, потому что не интересовался.
Зато я несколько раз обжигался на казалось бы тривиальных мелочах, вроде имени network. Поменял — всё, добавление в пул новых хостов поломалось. Сделал апгрейд — обрёл смену uuid'ов у шаблонов. (У меня где-то есть корпоративный файл документации с выписанными характерными шедеврами поведения xapi в некоторых случаях — оно душераздирающе).
И есть из этого простой вывод — «работает — не трогай». Изолировал сеть, защитил(ся) от бешенных машин — всё просто замечательно.
Зато я могу рассказать про множество (неочевидных) мер безопасности, которые есть в xapi.
Например, если засра… проблемный клиент решит поставить машину на постоянный ребут, то в коде xapi есть специальная проверка — его тормознут, и с каждым ребутом его будут ребутить всё дольше и дольше — до 2 минут паузы между ребутами.
Обычно упавшая (crashed) машина перезапускается. Однако, если машина падает в течение двух минут после запуска, её так же не перезапускают (защита от циклического падения из-за кривой процедуры загрузки).
Такие же меры есть в xenstore (защита от избыточного злоупотребления).
То есть xapi просто ориентировано на защиту системы от гостевых систем, а не от «страшных внешних угроз». Их просто не должно быть за счёт изоляции.
Хороший гайд, а главное полезный. Спасибо.
Sign up to leave a comment.
Citrix XenServer 5.6 Free/Advanced Security Guide