Угроза от инсайдера в облачной инфраструктуре

По мере движения к 100% виртуализации и автоматизации все увеличивается влияние администратора платформы виртуализации на всю инфраструктуру. Вплоть до того, всю работу одного из Top3 американских банков можно парализовать одним скриптом, запущенным с достаточными привилегиями.
Все чаще случаи, когда обиженный уволенный администратор заходит по вайфаю из МакДональдса и кладет всю инфраструктуру.
Нашумевшая история с CodeSpaces - преступники требовали денег, а не получив, удалили все данные и бэкапы.

При этом наблюдается ситуация, когда быстрее трат на информационную безопасность растут только финансовые потери от инцидентов.

В итоге безусловно будет усиливаться контроль и прессинг в сторону привилегированных пользователей и администраторов. Но что меня удивило - даже от самых профи, сидевших на сцене, я не слышал одного. Я не слышал даже подтверждения наличия чисто административной проблемы с инсайдерами.
Инсайдеров можно разделить на несколько типов:
1) Сделают гадость и продадут данные вне зависимости ни от чего
2) Могут сделать, а могут и не делать
3) Не будут делать гадость, даже если с ними обойдутся очень нехорошо.

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

В конечном итоге у меня сформулировалась пара тезисов по облачной безопасности:
1) Угроза от инсайдера всерьез начинается, когда сотрудников рассматривают как инсайдеров и угрозу, а не помощников. Когда их рассматривают в качестве легко заменяемых ресурсов, а не людей. 
2) Лояльность сотрудника к компании начинается с лояльности компании к сотруднику.

Выступающие не смогли ответить на вопрос: какой процент инцидентов с инсайдерами был вызван плохим отношением менеджмента к “инсайдерам”? Подразделения по ИБ НЕ занимаются этим вопросом.

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

По мотивам сессии SEC2296.

Security: сеть для VMotion / Fault Tolerance / IP Storage

Как построить безопасную сеть и как распределить VLAN'ы и физические адаптеры?

Прежде всего нужно подчеркнуть особенности VMotion, Fault Tolerance и IP Storage трафика - он нешифрованный и передается в прямом виде. Что из этого следует?

Все три типа трафика должны быть изолированы от общей сети, в которую входит VM Network. Кстати, это и к вопросу о выборе между ESX Software iSCSI и Guest Software iSCSI. При прослушке трафика можно получить в прямом виде состояние оперативной памяти (VMotion) вместе с ключами и паролями/хэшами паролей, и дисковый ввод/вывод вместе с ценными данными.

Отделение всех трех типов трафика от общей сети является ключевым моментом в предотвращении атаки. Хорошо, но нужно ли разделять их между собой? Строго говоря, рекомендуется. Проведу простую аналогию - стоит ли хранить патроны и оружие в одном сейфе или в разных, чтобы обезопасить детей? Будет значительно труднее собрать оружие и выстрелить при разных сейфах.
С другой стороны, ответ на этот вопрос сильно зависит от степени ценности данных. В общем случае особого беспокойства нет, и все три типа трафика можно комбинировать на одном физическом коммутаторе или даже в одном VLAN. Более того, подобная конфигурация может сохранить нам порты и упростить конфигурацию. При полном отделении трафика на физическом уровне требуется как минимум три физических порта, но их ведь нужно еще и резервировать -> уже 6 портов. Пожертвовав полным физическим отделением, можно обойтись всего 3мя - поставив их по кругу для всех 3-х VMkernel в active / standby.

Стоит ли отключить Tech Support доступ на ESXi?

Duncan Epping написал про обсуждение интересного вопроса о безопасности ESXi.

Стоит ли отключить Tech Support доступ на ESXi с целью усиления безопасности?

Технически это несложно, но лично я полностью согласен с Duncan’ом – с точки зрения ИБ бессмысленно.

1. Чтобы попасть на ваш сервер ESXi в Tech Support режиме (консоли), злоумышленнику необходим физический доступ к вашему серверу (либо iLO / IP KVM).
2. Если злоумышленник получил доступ к физической консоли сервера, то ему необходимо знать пароль root.

Как все мы помним из азов ИБ – “Если у кого-то постороннего есть физический доступ к вашему серверу, это больше не ваш сервер”. Ну а если злоумышленник имеет физический доступ к серверу и знает административный пароль, то у вас явно серьезные проблемы с безопасностью в целом, которые никак не решить запретом Tech Support Mode. А вот с поддержкой проблемы возникнут, поскольку при любом сбое ESXi будет просто невозможно зайти на него и расследовать причины.

Tech Support Mode можно будет включить обратно, да, но это потребует перезагрузки сервера и симптомы неисправности могут при этом просто исчезнуть.

vSphere 4.0 Security Hardening Guide

VMware опубликовала драфт руководства по усилению безопасности (Security Hardening Guide) vSphere 4.0.

Хотя это не финальная версия, любому администратору vSphere будет как минимум полезно ознакомиться с документом.

Само руководство разделено на пять частей:

• Виртуальные машины
• Хост
• vNetwork
• vCenter
• Сервис консоль (для ESX)
  

Использование non-persistent дисков

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

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

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

Поэтому рекомендуется полный отказ от использования непостоянных дисков, или использование их только в тестовых средах или средах разработки (эта мера так же рекомендована вендором - стр 6. VMware Security Hardening).

Безопасность в виртуальной среде (Infosecurity Russia 2009)

C 29 сентября по 1 октября в Экспоцентре проходит, ставшая уже традиционной, Международная выставка-конференция по информационной безопасности - Infosecurity Russia. В этом году организаторы и участники не обошли стороной и тему обеспечения безопасности в виртуальной среде. Помимо презентаций на стендах компаний прошел Круглый стол - «Безопасность в виртуальной среде: Технологии обеспечения. Почему традиционных средств недостаточно?» (30 сентября, 2 день) с участием:
1. Михаила Емельянникова (Информзащита)
2. Александра Ширманова (Код Безопасности)
3. Алексея Чеканова (Алмитек)
4. Антона Антича (VMware)
5. Сергея Халяпина (Citrix)

Участники Круглого стола поделились своим мнением относительно особенностей обеспечения безопасности в виртуальной среде. Особенно ценно то, что все участники сошлись во мнении, что новые возможности - это новые проблемы. Не обошли стороной участники и вопрос сертификации как самого ПО, так и средств защиты. Презентации участников Круглого стола можно будет скачать либо с сайта организаторов выставки либо с сайтов компаний.
Завтра, в последний день выставки, пройдет мероприятие под названием - "Львы и гладиаторы-2009". В ходе конкурса представители компаний-разработчиков и поставщиков средств защиты информации представляют новые (появившиеся в течение прошедших 12 месяцев) продукты для рынка информационной безопасности. Цель "гладиаторов" – убедить "львов" приобрести свой продукт. "Гладиатору"-победителю вручается приз – "гладиаторский меч". В этой битве будут представлены 2 продукта для виртуальных сред:
1. Reflex VMC
2. Stonegate IPS

Зарегистрироваться на мероприятие все еще возможно по адресу http://www.infosecuritymoscow.com

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

PS. Антон Антич пообещал до конца года Security Hardening по vSphere :)

Роли, которые мы выбираем…

Представьте себе ситуацию, кабинет Гиммлера, в него врывается Мюллер и начинает рыскать по шкафам, хватает папку с документами и убегает. Возможно ли такое при правильном сценарии?

Используй то, что под рукой и не ищи себе другое.

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

Помните одиозного помощника лорда Мейса? - «Есть ли у вас план, мистер Фикс? — Есть ли у меня план? Есть ли у меня план? Да у меня целых три плана!». В сущности, он был совершенно прав, имея целых три плана.
А сколько нужно нам для понимания масштабов бедствия и разработки возможных вариантов спасения утопающих, используя силы этих самых утопающих? Все те же 3 плана, точнее итерации:

1. Составьте для себя перечень повседневных задач, которые придется решать. Составьте его тщательно, продуманно, взвешенно. Но я ручаюсь, вы все равно что-нибудь да забудете. Впрочем, к этой работе можно будет вернуться еше раз, на второй итерации.
2. Чтобы выполнить все то, что вы описали ранее – а что КОНКРЕТНО надо делать? Вот так и распишите все как Петька оперу - про ВСЕХ И ОЧЕНЬ ПОДРОБНО.
3. Когда с первыми этапами покончено - задумайтесь, а КТО и ГДЕ все это будет делать? Это самый важный и сложный момент во всем вашем безумном предприятии.

Что получилось в итоге? А в итоге мы получили три важных компонента управления доступа – перечень ролей, перечень конкретных привилегий для каждой роли и, о чудо, МАТРИЦУ ДОСТУПА к информации – мечту любого безопасника от мала до велика.

Три ореха это уже куча или еще не куча?

Никогда не используйте встроенные роли кроме системных, таких как в VI, так в vSphere всего 3 - No Access (по умолчанию для всех пользователей кому в явном виде не прописан доступ), Read Only (роль содержит привилегии на просмотр детальной информации на уровне объекта иерархии), Administrator (роль содержит все привилегии на уровне объекта иерархии).

Эти роли не подлежат удалению или изменению, так как для инфраструктуры это может окончиться плачевно.

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

Несколько слов о роли Administrator. Обычно эта роль назначается администраторам виртуальной инфраструктуры. Таких администраторов, скорее всего, будет несколько и каждый из них будет отвечать только за определенный участок работы, а, следовательно, каждый будет иметь полномочия, которые не соответствуют его функциональным задачам (контроль над всеми серверами ESX и возможность назначения полномочий). Хорошим решением в данном случае было бы создание 2 персонифицированных аккаунтов с ролью Administrator (основной и резервный) что называется на исключительный случай, а для повседневной работы создание специальных ролей для каждого администратора с минимально необходимыми привилегиями согласно функциональным задачам.

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

1. Resource Pool Administrator
2. Virtual Machine Power User
3. Virtual Machine User
4. VMware Consolidated Backup User
5. Virtual Machine Administrator
6. Datacenter Administrator

vSphere:

1. Resource Pool Administrator
2. Virtual Machine Power User
3. Virtual MachineUser
4. VMware Consolidated Backup User
5. Datastore Consumer
6. Network Consumer

Несколько слов о роли VMware Consolidated Backup User. Согласно технической документации компании VMware изменение или удаление это роли не допускается.

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

Рассмотрим на примере.
Роль Virtual Machine User (обычно назначается всем рядовым пользователям) обладает 15 полномочиями, среди которых – Global – CancelTask, VirtualMachine – ConsoleInteract, VirtualMachine – SetCDMedia, ScheduledTask – Create, ScheduledTask – Run. Вы уверены в том, что эти полномочия необходимы для работы? Это как в театре, если на сцене в первом акте висит ружьё, то в третьем оно непременно выстрелит.

Аутентификация пользователей должна производиться с использованием доменных учетных записей, аккаунты от локальных учетных записей, как и аккаунты роли Administrator (основной и резервный) необходимо использовать только в исключительных случаях и хранить в бумажном виде в сейфе.

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

«Разделяй и властвуй» Николо Макиавелли

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

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

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

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

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

Не получается создать локального пользователя на ESXi

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



Попробовал и я. Действительно для пар (логин/пароль) itadmin/itadmin и admin/admin такое сообщение. Но при этом прекрасно сработали пары itadmin/qweasdzxc и admin/qweasdzxc, и пользователи были созданы.

Проверил логи:

<Error type="Vmomi.Fault.SystemError">
  <Message>A general system error occurred: passwd: Authentication token manipulation error
passwd: 
</Message>
  <DetailedMessage>A general system error occurred: passwd: Authentication token manipulation error
passwd: 

</DetailedMessage>
  <Reason>passwd: Authentication token manipulation error
passwd: 
</Reason>
</Error>
[        :ShowErr ] 2009-07-07 14:40:40.936  Create User: User name or password has an invalid format

Итак, проблема в том, что passwd не хочет создавать пользователя с таким паролем, но почему? Открыл ssh до ESX

[root@esx2] ~ # passwd dummy
Changing password for user dummy.
New UNIX password: admin
BAD PASSWORD: it is too short
Retype new UNIX password:

[root@esx2] ~ # passwd dummy
Changing password for user dummy.
New UNIX password: itadmin
BAD PASSWORD: it is based on a dictionary word
Retype new UNIX password:

Вот, в общем-то и все, проблема в сложности пароля и недостаточной детализированности ответа ESXi. Все мы, конечно, понимаем, что "qweasdzxc" в качестве пароля вряд ли надежнее чем "admin", но ESXi в лице утилиты passwd считает иначе.