Симптомы

• Просим описать принципы работы функции SSH-инспекции.
• Позволяет ли функционал SSH-инспекции отличать легитимный трафик внутри туннеля (например, подключение к shell) от нелегитимного (например, туннелирование TCP/IP).
• Есть ли у UserGate какая-либо возможность централизованного управления ключами SSH-серверов, включая подписывание новых ключей. проверку подлинности SSH-сервера и SSH-клиента, отзыв ключей скомпрометированных SSH-серверов/клиентов?

Решение

Принципы работы SSH-инспекции

SSH-инспекция работает по принципу MITM: при установлении SSH-соединения по портам, указанным в правиле инспекции, происходит заворот трафика в модуль SSH-прокси. Модуль устанавливает соединение с клиентом от себя. Таким образом выполняется расшифровка и действия, указанные в правиле. Далее устанавливается соединение с сервером, после чего на него передается трафик, полученный от клиента.

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

Примеры записей в журнале при различной конфигурации правила:

• Запись shell указывает на подключение через ssh обычным образом: root@172.16.1.2
• Запись touch test указывает на удаленное выполнение команды: root@172.16.1.2 touch test

Для работы SSH-инспекции необходимо создать правило и включить на соответствующих зонах источника разрешение "SSH-прокси".

О настройке правил:

1. Вы создаете правило инспекции SSH - в нем указываете действие. Действие "Расшифровать" позволяет выполнять операции с трафиком и журналировать действие (shell или удаленное выполнение команд). Действие "Не расшифровывать" просто пропускает трафик через модуль инспекции без выполнения каких либо действий с ним и журналирования команды.
2. Действие "Блокировать удаленный запуск shell" не позволяет войти в shell по SSH: ssh root@172.16.1.2. Однако, не блокируется удаленное выполнение команд, например: ssh root@172.16.1.2 touch check.txt успешно выполнится.
3. Действие "Блокировать удаленное выполнение по SSH" наоборот - блокирует удаленное выполнение команд ssh root@172.16.1.2 touch check.txt, но никак не препятствует выполнению команд после подключения к shell. Опция "Редактировать команду SSH" позволяет указывать команды, которые необходимо запретить к выполнению, они пишутся в формате ssh username@172.16.1.2 command option. Можно указывать несколько команд - каждую на новой строчке.
4. Действие "Блокировать по SFTP" просто блокирует подключение по данному протоколу.
5. Фильтры "Пользователи", "Источник" и "Адрес назначения" используются по аналогии с другими правилами.
6. Вкладка "Сервис" предназначена для того, чтобы указывать в ней сервисы (характеризуются портами источника и назначения), трафик которых должен заворачиваться в модуль инспекции SSH. Нужно отметить, что в данном меню возможно выбрать только диапазоны протокола TCP. В противном случае будет выведена ошибка сохранения.
7. Вкладка "Время" предназначена для того, чтобы включать правило по расписанию.

Обнаружение SSH-туннелирования

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

Однако, реализация SSH-прокси не предполагает обслуживания специфического ПО для туннелирования TCP/IP, в связи с этим, попытки его использования могут вызывать ошибки модуля c последующим разрывом соединения. Например, при использовании Sshuttle:

Централизованное управление ключами

На данный момент подобный функционал отсутствует во всех версиях продукта (5, 6, 7, 7.1).