Все чаще крупные компании задумываются о контроле и отслеживанию доступа к критичным для бизнеса серверам. Кто зашел, что сделал и когда? Встроенное логирование не всегда удобно и «читабельно», и вот на российский рынок постепенно стали выходить продукты по «контролю привилегированных пользователей». Мне показалось интересным сравнить два «основных» продукта этой линейки, а именно Balabit Shell Control Box и Wallix Admin Bastion.
Примечание: Для сокращения объема статьи сравнение будет только в разрезе протокола rdp и функционала в целом, в результате чего имеет относительно общий характер. Протокол ssh также поддерживается данными продуктами, однако в этой статье он НЕ рассматривается, чтобы не мешать все «в одну кучу».
Системный администратор в наше компьютеризированное время стал едва ли не «царем и богом» it-пространства Компании. Как следствие этого, руководство предпочитает с ними особо не конфликтовать и по возможности идти на уступки, ведь уходя «по-плохому», бывший админ может нанести бизнесу порядочный ущерб. Поэтому сама фраза «контроль админов», возможно, покажется многим топ-5-сотрудникам избавлением от щекотливой проблемы и отличным ее решением, но…все ли так просто? Конечно, нет. Поэтому, в первую очередь, хотелось бы кратко обозначить компании, в которых действительно подобные продукты могут принести какой-то положительный выхлоп. Список рожден на базе собственного опыта и не претендует на истину в последней инстанции, т.е. носит изначально субъективный характер.
Итак, «контроль админов» пригодится:
В остальных случаях использования ПО по контролю админов, как правило, не целесообразно.
Обе нижеописанные системы представляют собой аппаратный или виртуальный appliance, базирующийся на несколько видоизмененных unix системах: Wallix разворачивается на базе Debian, Balabit – ZorpOS. Требуемые аппаратные мощности зависят от числа активных пользователей и количества защищаемых серверов.
Wallix умеет работать только в режиме «бастион» на прикладном уровне модели OSI, т.е. ставится в разрыв сети в явном, видимом для администратора виде. На сервере Wallix настраиваются правила (о них чуть ниже), на основании которых тот пропускает\блокирует подключения администраторов. Администратор подключается на сервер wallix по протоколу rdp (порт стандартный) и логинится на нем при помощи созданной локальной учетки (или импортированной из AD). После этого ему предоставляется доступный список пар сервер + конечная учетка, и он выбирает нужный сервер. Wallix может сам подставить пароль конечной учетки, но можно и запросить этот пароль у администратора. Для наглядности логическая схема подключения показана ниже:
Логическая схема подключения админов к защищаемым серверам через Wallix
Настройки Wallix представляют собой бинарные (истина-ложь\можно-нельзя) сопоставления между двумя типами групп: группы учетных записей на самом Wallix (можно заменить на учетные записи, импортированные из AD) и группы пар Сервер + конечная учетная запись.
Форма добавления\редактирования защищаемого сервера и конечной учетки
Число таких сопоставлений, как и самих групп, не ограничено и на их основе выстраивается матрица доступа кому и куда можно подключаться.
Wallix хранит записи rdp в виде видео-роликов (в файловом виде), которые можно прогнать через встроенный распознаватель текста (ocr), после чего искать по заголовкам (поиск по заголовкам в рамках не только одного видео обещали прикрутить в ближайших версиях).
Список сохраненных видео записей rdp-сессий
Как можно «заставить» админа ходить к нужным серверам через wallix?
Плюсы продукта
Минусы продукта
Balabit также ставится в «разрыв», но умеет работать в нескольких режимах на разных моделях OSI. При этом настройка «прозрачного»\ «непрозрачного» режима производится непосредственно в самом подключении, что весьма удобно с точки зрения «тонкой» настройки того или иного подключения.
Главное преимущество Balabit, что он умеет работать в «прозрачном» режиме, располагаясь в сети в скрытом для администраторов виде. IP-spoofing позволяет сделать его «невидимым» даже для FW и маршрутизаторов, подставляя в качестве ip-src ip-адрес ПК-админа, таким образом нет необходимости настраивать для него отдельные разрешения на сетевом оборудовании.
Для работы balabit в прозрачном режиме на маршрутизаторе прописываются соответствующие маршруты (что весь трафик из подсетки N направляем на IP-адрес Balabit). При этом трафик, который balabit не сможет распознать (выявить в нем контролируемые протоколы), будет пропускаться без изменений дальше (на указанный шлюз).
Примечание: в прозрачном режиме авторизация на сервере balabit не производится, однако система записывает под какой учётной записью авторизовался администратор на защищаемом сервере, что позволяет в последствии выставить требуемые фильтры и найти искомый видео-ролик.
Настройки balabit имеют разрез по защищаемым серверам – для каждого сервера задаются свои мгносоставные настройки и права доступа (для прозрачного режима: из какой сети можно подключаться к защищаемому серверу). Вариант настроек представлен ниже:
Настройки для доступа на защищаемый сервер через balabit
В прозрачном режиме основной пласт настроек ложится на маршрутизацию трафика и настройку сетевого оборудования. Настройки на самом balabit минимальны и оперируют ip-адресами, с которых обращаются к защищаемым серверам, а не пользователями и их правами, как это реализовано в Wallix.
Режим бастион имеет несколько реализаций:
Для каждого режима присутствуют свои настройки, в которые сейчас углубляться не хотелось бы. Достаточно сказать, что от количества полей порой разбегаются глаза :))
Система также хранит все сессии в виде видео-роликов. OCR производится единоразово. Поиск по распознанному тексту во всех видео-роликах уже присутствует. Для просмотра сессии необходимо клиентское ПО (Audit Player), которое поставляется вместе с дистрибутивом и устанавливается на ПК «оператора» с MS-операционкой на борту.
Список сохраненных видео записей rdp-сессий
Плюсы продукта
Минусы продукта
Как видно из текста выше, у каждого продукта есть свои сильные и слабые стороны – все зависит от пула поставленных перед ним задач. В сравнении не участвовали все возможности систем.
Также хотелось бы отдельно отметить, что по типу Wallix на рынке присутствует система CyberArk, имеющая схожий, но более расширенный функционал в режиме «бастион». За основу ее работы взят механизм MS Remote Application, что позволило увеличить количество поддерживаемых протоколов и возможностей подключения. К сожалению, автор не обладает достаточной компетенцией, чтобы добавлять ее в сравнение, однако и промолчать о ней считает преступным.
Примечание: Для сокращения объема статьи сравнение будет только в разрезе протокола rdp и функционала в целом, в результате чего имеет относительно общий характер. Протокол ssh также поддерживается данными продуктами, однако в этой статье он НЕ рассматривается, чтобы не мешать все «в одну кучу».
Кому нужны системы по контролю админов?
Системный администратор в наше компьютеризированное время стал едва ли не «царем и богом» it-пространства Компании. Как следствие этого, руководство предпочитает с ними особо не конфликтовать и по возможности идти на уступки, ведь уходя «по-плохому», бывший админ может нанести бизнесу порядочный ущерб. Поэтому сама фраза «контроль админов», возможно, покажется многим топ-5-сотрудникам избавлением от щекотливой проблемы и отличным ее решением, но…все ли так просто? Конечно, нет. Поэтому, в первую очередь, хотелось бы кратко обозначить компании, в которых действительно подобные продукты могут принести какой-то положительный выхлоп. Список рожден на базе собственного опыта и не претендует на истину в последней инстанции, т.е. носит изначально субъективный характер.
Итак, «контроль админов» пригодится:
- Компаниям, численность системных администраторов в которых превышает ~7-10 человек;
- Компаниям, it-поддержку в которой осуществляет сторонняя организация (аутсорс);
- Компаниям со специфичным ПО, которым требуется пускать на целевые сервера специалистов вендора\дистрибьютора;
- Компаниям, которых мучают регуляторы и требуют от них соответствия различным стандартам (не сталкивалась, но не исключаю).
В остальных случаях использования ПО по контролю админов, как правило, не целесообразно.
Обе нижеописанные системы представляют собой аппаратный или виртуальный appliance, базирующийся на несколько видоизмененных unix системах: Wallix разворачивается на базе Debian, Balabit – ZorpOS. Требуемые аппаратные мощности зависят от числа активных пользователей и количества защищаемых серверов.
Как это работает — Wallix Admin Bastion
Wallix умеет работать только в режиме «бастион» на прикладном уровне модели OSI, т.е. ставится в разрыв сети в явном, видимом для администратора виде. На сервере Wallix настраиваются правила (о них чуть ниже), на основании которых тот пропускает\блокирует подключения администраторов. Администратор подключается на сервер wallix по протоколу rdp (порт стандартный) и логинится на нем при помощи созданной локальной учетки (или импортированной из AD). После этого ему предоставляется доступный список пар сервер + конечная учетка, и он выбирает нужный сервер. Wallix может сам подставить пароль конечной учетки, но можно и запросить этот пароль у администратора. Для наглядности логическая схема подключения показана ниже:
Логическая схема подключения админов к защищаемым серверам через Wallix
Настройки Wallix представляют собой бинарные (истина-ложь\можно-нельзя) сопоставления между двумя типами групп: группы учетных записей на самом Wallix (можно заменить на учетные записи, импортированные из AD) и группы пар Сервер + конечная учетная запись.
Форма добавления\редактирования защищаемого сервера и конечной учетки
Число таких сопоставлений, как и самих групп, не ограничено и на их основе выстраивается матрица доступа кому и куда можно подключаться.
Wallix хранит записи rdp в виде видео-роликов (в файловом виде), которые можно прогнать через встроенный распознаватель текста (ocr), после чего искать по заголовкам (поиск по заголовкам в рамках не только одного видео обещали прикрутить в ближайших версиях).
Список сохраненных видео записей rdp-сессий
Как можно «заставить» админа ходить к нужным серверам через wallix?
- Закрытием маршрутов на уровне сети в купе с оргмерами «или так, или никак, иначе последуют суровые меры…»;
- Разрешить вход на защищаемые сервера только под специально созданными доменными учетками, пароль на которые Wallix будет менять раз в час\день\неделю\месяц (пароли высылаются в зашифрованном виде на указанный ящик. Нужен GPG-сертификат и ЗК к нему).
Плюсы продукта
- Простая, незамысловатая настройка;
- Стабильно работающий режим «бастион», возможность двойной авторизации и составление соответствующей матрицы доступа на ее основе;
- Возможность интеграции с несколькими AD.
Минусы продукта
- Нет стабильно работающего «прозрачного» режима. Тот, что заявлен, работает с бубном и через пень-колоду или не работает вовсе;
- Присутствуют неучтенные продакшн-нюансы (версия 4.2), которые приходится закрывать костылями и на бегу.
Как это работает — Balabit Shell Control Box
Balabit также ставится в «разрыв», но умеет работать в нескольких режимах на разных моделях OSI. При этом настройка «прозрачного»\ «непрозрачного» режима производится непосредственно в самом подключении, что весьма удобно с точки зрения «тонкой» настройки того или иного подключения.
«Прозрачный режим»
Главное преимущество Balabit, что он умеет работать в «прозрачном» режиме, располагаясь в сети в скрытом для администраторов виде. IP-spoofing позволяет сделать его «невидимым» даже для FW и маршрутизаторов, подставляя в качестве ip-src ip-адрес ПК-админа, таким образом нет необходимости настраивать для него отдельные разрешения на сетевом оборудовании.
Для работы balabit в прозрачном режиме на маршрутизаторе прописываются соответствующие маршруты (что весь трафик из подсетки N направляем на IP-адрес Balabit). При этом трафик, который balabit не сможет распознать (выявить в нем контролируемые протоколы), будет пропускаться без изменений дальше (на указанный шлюз).
Примечание: в прозрачном режиме авторизация на сервере balabit не производится, однако система записывает под какой учётной записью авторизовался администратор на защищаемом сервере, что позволяет в последствии выставить требуемые фильтры и найти искомый видео-ролик.
Настройки balabit имеют разрез по защищаемым серверам – для каждого сервера задаются свои мгносоставные настройки и права доступа (для прозрачного режима: из какой сети можно подключаться к защищаемому серверу). Вариант настроек представлен ниже:
Настройки для доступа на защищаемый сервер через balabit
В прозрачном режиме основной пласт настроек ложится на маршрутизацию трафика и настройку сетевого оборудования. Настройки на самом balabit минимальны и оперируют ip-адресами, с которых обращаются к защищаемым серверам, а не пользователями и их правами, как это реализовано в Wallix.
Режим «Бастион»
Режим бастион имеет несколько реализаций:
- Режим TS Gateway. В этом режиме в rdp-клиенте прописывается DNS-имя сервера balabit в качестве сервера шлюза удаленных рабочих столов. Этот режим использует сертификаты, шифруя трафик как до TS GW (сертификат сервера balabit), так и от balabita до защищаемого сервера (либо сгенерированный «на лету» сертификат, либо загруженный на balabit). При таком подключении возможно подставить заведенный заранее на сервере balabit пароль конечной учетной записи, таким образом администратор может не знать учетных данных для подключения на защищаемый сервер. Однако сам balabit автоматически не умеет менять пароли и как-либо ими «управлять». Интегрируется с отдельной SSO-системой Thycotic Secret Server.
Примечание: Такая схема весьма капризна в своей работоспособности, т.к. требует довольно приличное количество тонких настроек и понимания, что и почему настраивается. Порой могут возникнуть несколько непредсказуемые «затыки» (например, при прописанной в свойствах обозревателя проксе, rdp-клиент отказывался резолвить DNS-имя сервера balabit).
- Режим «Авторизация на GW». В этом режиме администратору
нужно иметь два мониторапотребуется начать подключаться к защищаемому серверу, после инициализации подключения авторизоваться в web-интерфейсе balabit и «разрешить» свое подключение. Этот вариант подключения также требует маршрутизации сетевого трафика и соответствующих настроек на роутере (-ах). - Режим «4 глаза». Принцип работы тот же, что в п. 2, но тут уже «разрешить» должен другой человек.
Для каждого режима присутствуют свои настройки, в которые сейчас углубляться не хотелось бы. Достаточно сказать, что от количества полей порой разбегаются глаза :))
Система также хранит все сессии в виде видео-роликов. OCR производится единоразово. Поиск по распознанному тексту во всех видео-роликах уже присутствует. Для просмотра сессии необходимо клиентское ПО (Audit Player), которое поставляется вместе с дистрибутивом и устанавливается на ПК «оператора» с MS-операционкой на борту.
Список сохраненных видео записей rdp-сессий
Плюсы продукта
- Умеет стабильно и профессионально работать в прозрачном-MiTM режиме;
- Имеет множество тонких настроек практически на любой вкус;
Минусы продукта
- Интегрируется только с одним AD (требуется ввод в AD);
- Режим «бастион» требует порой танцев с бубном и длительного курения манулов;
- Не умеет управлять паролями;
- Двойная авторизация имеет довольно запутанный характер и нрав;
Подводя итог
Как видно из текста выше, у каждого продукта есть свои сильные и слабые стороны – все зависит от пула поставленных перед ним задач. В сравнении не участвовали все возможности систем.
Также хотелось бы отдельно отметить, что по типу Wallix на рынке присутствует система CyberArk, имеющая схожий, но более расширенный функционал в режиме «бастион». За основу ее работы взят механизм MS Remote Application, что позволило увеличить количество поддерживаемых протоколов и возможностей подключения. К сожалению, автор не обладает достаточной компетенцией, чтобы добавлять ее в сравнение, однако и промолчать о ней считает преступным.
Комментарии (28)
Zuyza Автор
08.07.2015 17:55В шапке статьи специально было указано
сравнение будет только в разрезе протокола rdp и функционала в целом
Возможность контроля ssh также присутствует в этих продуктах, однако в статье этот функционал НЕ рассматривается, т.к. имеет свои особенности и тонкости, которые не хотелось бы скидывать в одну кучу.
Шапка скорректирована, дабы не вводить никого в заблуждение.
teamfighter
08.07.2015 18:18Остается лишь один вопрос — кто будет настраивать Wallix или balabit? Топ-менеджеры?
А сами админы всегда могут оставить себе лазейку.Zuyza Автор
08.07.2015 18:32+1Вы, видимо, как-то невнимательно читали…
Компаниям, численность системных администраторов в которых превышает ~7-10 человек;
Предполагается, что настраивать будут руководители тех самых 10 человек, которые не заинтересованы в лазейке для них же (своих подчиненных)
Компаниям, it-поддержку в которой осуществляет сторонняя организация (аутсорс);
Как правило в таких ситуациях всегда есть админ на стороне Заказчика (принимающий работы), который вполне в состоянии настроить все так, как нужно ЕМУ.
Компаниям со специфичным ПО, которым требуется пускать на целевые сервера специалистов вендора\дистрибьютора;
Настроить систему вполне могут «местные» админы, т.к. они, как и в п.1, заинтересованы в отсутствии лазейки для специалистов вендора\дистрибьютора.
Компаниям, которых мучают регуляторы и требуют от них соответствия различным стандартам (не сталкивалась, но не исключаю).
В этом случае, вероятно, подобная система будет чистой формальностью. Однако еще раз подчеркну, что не имела подобного опыта внедрения.
В остальных случаях не факт, что имеет какой-либо смысл внедрять такую систему, т.к., разумеется, топ-менеджеры ничего настраивать не будут, а «сами админы всегда могут оставить себе лазейку».teamfighter
08.07.2015 18:42Предполагается, что настраивать будут руководители тех самых 10 человек, которые не заинтересованы в лазейке для них же (своих подчиненных)
А руководителя ИТ отдела кто будет контролировать? Параноить — так по полной.
Мне видится только один вариант более-менее вменяемый — настройка софта в формате аутсорса со стороны вендоров этого софта. Все остальные варианты уязвимы. А вообще в среде именно профессионалов не принято «гадить» компании, уходя с рабочего места. Даже если расстались далеко не друзьями. Я бы не стал, например.
Опять-таки, не каждый админ согласится работать через такую замечательную тулзу. Даже если энтерпрайз во все поля. По той причине, что это просто неудобно.Zuyza Автор
08.07.2015 22:49Если честно, не вижу никакого смысла ставить заочные диагнозы и гадать на кофейной гуще о степени паранойи топов или руководства IT-отдела абстрактной компании N. Все люди разные и ситуация тоже на удивление бывают разными. А вести диалог в стиле «а если» (а если руководителя руководителя руководителя тоже надо контролировать?) — имхо, довольно пустая трата времени :)
В одном соглашусь — не гадить там, где работаешь(-л). Но я не даром привела список компаний, где такой продукт имел бы смысл — он не поможет тем, у кого паранойя и развившейся нервный тик от словосочетания «системный администратор».
Yurich
09.07.2015 15:00вообще-то удобно именно через эту штуку. Поверьте, я с этой системой работал, как эксплуатант.
Во-первых, сразу в одном месте все управляемые устройства. Во-вторых — иногда на устройство надо входить под разными учетками. Держать в голове несколько пар «логин/пароль» для десятков устройств мне лениво. Эта штука делает все сама. Надо просто выбрать.
Yurich
09.07.2015 15:08Валликсы, кстати, охотно настраивают свои системы.
Тарифы у них конские, что есть, то есть.
maledog
09.07.2015 16:42Очередные игрушки для менеджеров. IMHO полезным функционалом программы можно было вобще не наделять. Просто научить их выводить красивые отчеты. Системный администратор как правило прекрасно знает свое хозяйство и всегда может оставить себе неконтролируемый доступ.
Surge0n
10.07.2015 12:19CyberArk PASS? В частности модуль Privileged Session Manager. Если брать функционал PSM only без управления учетками, еще и под деньгам нормально получается.
amarao
Простите, этим говном можно пользоваться только через rdesktop? Буэ.
Унесите и закопайте.
Я на половину серверов вообще хожу по ssh методом ansible -i srv_list site.yml -f 50, так что ваше rdp тут как собаке пятая нога.
selenite
Аналогичный продукт для ssh/vnc рекламировался на stackoverflow где-то в 2010-2011. Смотрел, было довольно уныло и весьма энтерпрайзно.
Yurich
Авто статьи несколько неправ.
Прелесть WAB как раз в том, что он прекрасно умеет авторизовывать пользователя не только в винде, но и в юниксах/линуксах, ssh и телнет ему также прекрасно знакомы. Текстовые сессии он пишет в текстовый файл, rdp-сессии хранит видосами.
Если что, я эту систему эксплуатировал и перся с нее нечеловечески (я и разрабов лично знаю, много раз был у них в конторе, да и они ко мне в гости приезжали неоднократно).
Сейчас вот без нее сижу (поменял место работы и страну проживания), тоскую, т.к. удобнее ничего для управления олухами из подрядных организаций и развешивания им звездюлей (по факту просмотра сессий) я не встречал.
Купил бы и сюда, но те поставщики, которых я тут видел, какие-то обморочные, увы (кстати, охотно пообщаюсь в личке с желающими продать мне такую штуку, ну а также внедрить и принять на саппорт)
amarao
Поясните мне, как оно может писать ssh-сессию? Например, у меня типовой метод подключения к серверу через «вложенный ssh»:
Host *.serv
SendEnv EDITOR
ForwardAgent yes
ProxyCommand ssh -W $(echo %h | cut -d. -f1):%p -C proxy.serv
И что тут будет писаться? Шифрованный stdin/out? А это мы ещё не затрагивали вопросы -L/-R/-D
Yurich
Вы на экране что-то видите во время ssh-сессии? Вот это что-то оно писать и будет.
amarao
В каком из ssh'ей? Кроме того, когда я выполняю команду по ssh без создания терминала, её вывод оказывается только у моего ssh'а.
Короче, эта вся конструкция выглядит как попытка огородить неогораживаемое. Либо превратить мощный инструмент (ssh) в огрызок по образцу виндового telnet'а, отключив все функции socks-proxy, прокидывания портов и интерфейсов, ssh-агентов и stdin/out pipe'инга.
Yurich
Как Вам будет угодно. Как я понимаю, использование этой системы — вопрос сугубо добровольный.
Другой вопрос, что у них в клиентах Airbus, Societe Generale, Peugeot и многие другие крупные игроки, но я не сомневаюсь, что у них задачи могут быть и проще и неинтереснее.
amarao
И я всё равно не понимаю, как оно собирается обрабатывать проходящий по stdin/out шифрованный трафик.
Возможно, создатели этих систем просто не знали масштабы и возможности ssh-протокола?
Yurich
Создатели этой системы ssh знают весьма недурно (в отличие от меня, кстати, я ssh воспринимаю, как шифрованный телнет, увы мне, увы — не моя специфика).
Как я понимаю, их система проксирует ваше общение с управляемым девайсом и по факту с ним общается не ваш компьютер, а эта железка, вы же видите только то, что может видеть она.
Вы, кстати, вполне можете с ними связаться, английский у них вполне неплох.
amarao
Именно потому я и не понимаю, что они могут фильтровать и писать. Я только что написал пример «вложенного ssh», который оставит промежуточную систему с двумя потоками: stdin/stdout, которые по своей информативности не отличаются от tcpdump proto ssh.
И уровень вложенности может быть практически любой.
Yurich
Еще раз: пишется текстовый лог сессии. Того, что админ видит у себя в консоли. Если Вам этого недостаточно — значит, это не Ваша система, похоже.
amarao
Очевидно не моя, я просто указываю на её ущербность. Вся идея ssh в том, что никто не может видеть трафик между целевым хостом и пользователем. А тут приходят дерзкие люди говорят, что могут. Очевидно, что при правильном использовании ssh не могут и не должны.
ValdikSS
Они, очевидно, MiTM'ят все, может и прокси поддерживают.
amarao
Блин, я ж как раз и говорю, что я сквозь MitM'а пропущу шифрованный трафик, не показав ему ничего, кроме урла, куда я (на самом деле) иду.
man ssh_config, раздел ProxyCommand.
aim
странно что ты сам жтого не понимаешь, но поясню — в компаниях, в которых в голову приходит поставить по описанное в статье отрубают все эти возможности.
amarao
А как можно отрубить -W режим со стороны сервера? Я не троллю, мне интересно.
aim
подозреваю что-то типа PermitOpen none
сам никогда не интересовался этой темой
Zuyza Автор
Wallix совершенно спокойно пишет ssh-сессию с пробросом авторизации и «тунелем», т.к. вы изначально коннектитесь именно к серверу Wallix по ssh и уже через него ходите на другие сервера. Т.е. сервер Wallix выступает «конечной точкой», а не вклинивается mitm'ом в ваши сессии.
С Balabit, подозреваю, будет сложнее… И, как показали комментарии, стоит написать отдельную вторую часть, на этот раз по протоколу ssh. Как появится немного времени — обязательно займусь.