Знакомство с PT Sandbox

В ранних статьях мы с вами уже познакомились с различными типами источников файлов, а также узнали, как правильно осуществить их настройку для проверки файлов.

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

Troubleshooting

При возникновении неисправностей в каком-либо компоненте продукта в веб интерфейсе на значке появляется красный индикатор, сигнализирующий о каких-то неполадках в работе. Нажав на него, можно более подробно узнать, в каком именно компоненте возникла ошибка.

Здесь же есть кнопка «Скачать файлы журналов» которая, как нетрудно догадаться, позволяет скачать файлы логов (журналов работы системы). По которым можно определить, в какой момент возникла неполадка. Кроме того, эти файлы будут необходимы при обращении в техническую поддержку.

Мы видим, что ошибка связана с источником файлов типа «Общая папка» (по названию компонента, совпадающему с названием источника). Перейдя в раздел «Источники для проверки» мы увидим, что ошибка состоит в том, что PT Sandbox не смог подключиться к данной папке.

В данном случае необходимо проверить правильность введенных данных и сетевую доступность источника. Однако далеко не все неисправности можно так просто выявить и определить их причину. Кроме того, бывают ситуации, когда веб-интерфейс продукта по какой-то непонятной причине недоступен. В таких ситуациях на помощь приходит командная строка.

Как уже было сказано во второй статье цикла, архитектура продукта PT Sandbox представляет собой множество небольших приложений, каждое из которых отвечает за выполнение определенных функций. Так называемая микросервисная архитектура. Технически это реализовано с помощью использования контейнеров, а также управления ими с помощью средства оркестрации kubernetes.

Сам kubernetes управляет так называемыми подами - абстрактными объектами Kubernetes, представляющими собой группу из одного или нескольких контейнеров и совместно используемых ресурсов для этих контейнеров.

Для работы с компонентами продукта используется инструмент командной строки kubectl. С его помощью можно управлять компонентами продукта, отслеживать их статус, перезапускать, а также просматривать логи. Весь этот функционал пригодится нам при поиске неисправности. В рамках данной статьи не описывается весь функционал данной утилиты, интересующиеся могут более подробно изучить ее работу на официальном сайте kubernetes: https://kubernetes.io/docs/reference/kubectl/

Так, например, у нас возникла другая ошибка. Нажав на индикатор, мы видим следующее сообщение:

Мы видим, что ошибка связана с источником файлов mailserv. Перейдя в раздел Источники для проверки мы увидим, что произошел какой-то сбой в работе данного источника:

Все еще непонятно, в чем проблема. Подключимся по SSH к серверу PT Sandbox, чтобы посмотреть логи данного источника. Для начала выведем список всех компонентов продукта командой (необходимо запускать с правами суперпользователя)
kubectl --kubeconfig /etc/kubernetes/admin.conf -n ptms get pod

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

Видим, что у подов mailserv-* статус “CrashLoopBackOff”, а значит, произошла ошибка в их работе. Для начала можно попробовать перезапустить их. Для этого выполним команду удаления (при удалении подов почти сразу поднимается их новая реплика).

Выполним следующую команду (имя пода(ов) необходимо указывать полностью)
kubectl --kubeconfig /etc/kubernetes/admin.conf -n ptms delete pod mailserv-7b7499b97c-fr7d9 mailserv-7b7499b97c-h2wvb, после чего проверим статус еще раз

У подов сначала проставляется статус “Error”, который после меняется на уже знакомый “CrashLoopBackOff”. Перезагрузка не помогла, тогда стоит посмотреть их логи.

Для этого выполним команду:
kubectl --kubeconfig /etc/kubernetes/admin.conf -n ptms log mailserv-7b7499b97c-8vjfn

Этот модуль отвечает за отправку файлов на проверку во внешние системы.

По логу видно, что ошибка произошла в 09:16:12.749: продукт не смог подключиться по указанному адресу, необходимо проверить корректность введенных данных и сетевую доступность источника файлов.

Таким образом можно выявлять многие ошибки продукта. Если данный способ не помогает решить проблему, можно обратиться в техническую поддержку Positive Technologies (Positive Technologies - Работает под управлением системы Kayako (ptsecurity.com)), в которой вам помогут с возникшей проблемой. При обращении подробно опишите возникшую проблему, а также приложите файлы журналов.

Как получить эти файлы из веб-интерфейса, мы уже знаем, но что делать, если данным способом выкачать файлы логов нет возможности?
Для этого предусмотрен механизм сбора логов из командной строки. Сделать это можно с помощью специального скрипта, поставляемого в комплекте с дистрибутивом продукта:

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

После этого нужно будет выкачать их с сервера PT Sandbox и передать в техническую поддержку.

Утилита ptmsctl

Еще одной вещью, о которой хотелось бы рассказать в этой статье, является утилита ptmsctl. Мы с ней уже немного познакомились в рамках работы с PT Sandbox по API, и сегодня узнаем больше о ее возможностях.

Данный инструмент является частью продукта PT Sandbox, устанавливается автоматически и предназначен для внесения определенных изменений в конфигурацию продукта, которые не вынесены в веб-интерфейс. Чтобы лучше узнать о возможностях данного средства, выполним довольно простую задачу.

Допустим, нам необходимо привязать доменное имя к адресу песочницы, чтобы вход в веб-интерфейс осуществлялся по нему, а не по адресу. Для этого из консоли сервера PT Sandbox выполним команду
ptmsctl web-interface domain-name apply <Доменное имя>

Спустя несколько минут новая конфигурация применится, и можно убедится в том, что теперь веб интерфейс продукта доступен по доменному имени:

В рамках примера, если вдруг вы ошиблись при вводе имени, либо вам надо его изменить, необходимо выполнить приведенную выше команду повторно с новым именем. Если необходимо посмотреть используемое имя, или удалить привязку, необходимо вместо apply ввести view или reset соответственно.

Подобным образом с помощью данной утилиты можно:

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

Кроме того, с помощью этой утилиты можно проверить версию продукта, обновить или восстановить его, посмотреть информацию о компонентах системы и версии антивирусных движков. А также удалить файлы из хранилища по хэш-сумме: все те функции, которые доступны в веб интерфейсе, но их таким образом можно выполнить и из консоли.

Серьезным удобством утилиты является то, что на любом этапе ввода команды можно добавить ключ -- help, и средство выдаст возможные опции, а также краткое описание к каждой из них - таким образом, совсем не обязательно запоминать, какая команда за что отвечает, за пару минут можно самостоятельно это узнать.

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