conti/Conti Documentation Leak/docs/misc/ТЗ статус проверки в криптопанели.txt

Доработка для хранения статуса проверки образцов в криптопанели

ЦЕЛЬ ДОРАБОТКИ

Это часть из комплекса мер по автоматизации тестирования закриптованых образцов.
Общий смысл доработки следующий:
- в криптопанели формируется очередь образцов на тестирование (очень похоже как на virustotal.com или dyncheck.com)
- у нас есть пул виртуальных машин, на которых есть скрипты тестирования
- скрипты дергают криптопанель, говоря например "привет, я машина IEWIN10, дай мне файлы, чтобы протестировать на мне"
- криптопанель в ответ отдает файл из очереди, делая у себя в БД нужные пометки
- скрипты что-то там тестируют, потом отдают ответ, например "привет, я машина IEWIN10, я протестила файл такой-то, отвечаю, файл - гавно! вот лог."


РЕАЛИЗАЦИЯ ДОРАБОТКИ

Сейчас в криптопанели хранятся образцы, загружаемые туда пользователями.
Нужно добавить для ЗАКРИПТОВАНЫХ образцов статусы:

- Не нужно проверять
- Нужно проверять
- Проверяется
- Проверено

Исходя из этих статусов:
- скрипты автоматизированного тестирования могут выбирать образцы для проверки на наших виртуалках
- а также отдавать результат проверки.

Все это в комплексе позволить минимизировать ручной труд при проверке криптов.


ДЕТАЛИ

Статусом "не нужно проверять" заведомо нерабочие либо те, которые по какой-то причине не нужно проверять.
К статусу "не нужно проверять" должна быть причина - enum { "заведомо нерабочий", "своя причина" (и тогда коммент к ней) }

К статусу "Нужно проверять" также нужно добавить следующие атрибуты:
- простое число - приоритет проверки. Для пользователя желательно сделать управление этим приоритетом через drag-drop, но это как удобнее.
*ПРАВКА 18.09.2018* Приоритет как отдельное свойство не нужен. Лучше добавлять файл на проверку в начало или конец очереди.
- признак отката виртуалки (булево значение). Значение по умолчанию = true.
Если данный флаг = true, это означает разрешение откатить виртуалку после теста.
Если флаг = false, то после теста ВМ не откатывать, запретить добавлять новые задачи на эту ВМ. В интерфейсе пользователя
необходимы индикаторы/кнопки статусов ВМ, с помощью которых оператор может вновь включить в работу ВМ.
Соответственно, у ВМ должен быть статус "активна"/"неактивна", каковой статус разрешает назначать на неё задачи.


К статусу "Проверено" идут детали:
* для каждой из виртуальных машин:
- полный лог проверки (текстовое поле длиной до 64к)
- статус проверки: success/failure
- дата-время начала и конца проверки

В системе должен быть раздел управления виртуальными машинами:
- создать-редактировать-удалить машину.
В свойствах машины:
- имя
- разрядность ОС
- версия ОС


Проверка происходит НА НЕСКОЛЬКИХ МАШИНАХ. Общий успех проверки определяется успехом проверки НА ВСЕХ МАШИНАХ.
Соответственно, должен быть раздел управления списком машин. У машины есть свойства - имя, и IP-адрес.
Когда скрипт проверки коннектится к панели через API, он представляется системе - называет имя машины, на которой он запущен.


ПОЛЬЗОВАТЕЛЬСКИЙ СЦЕНАРИЙ

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

*ПРАВКА 18.09.2018*
При назначении файла на проверку на конкретную виртуалку, необходимо выдать команду на запуск этой виртуалки.
Результат команды следует игнорировать - если виртуалка уже работает, то менеджер ВМ проигнорирует эту команду.


API

Нужно предусмотреть API для автоматизации работы скрипта, со следующими операциями:
1. дай мне следующий по приоритету файл в очереди для проверки на машине с именем %MACHINE%

HTTP POST /some-random-and-long-api-prefix/getfile

параметры:

pass: захардкоженый пароль - общий для всего API. Строка.
machine: имя компьютера. Строка.

Ответ: json следующего вида:
{
"file_id": 32,				// идентификатор файла в БД
"file": "TVqQAAMAAAAEAAAA//8AA"		// тело файла в кодировке base64
}

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


2. возьми результаты проверки файла на машине %MACHINE%

HTTP POST /some-random-and-long-api-prefix/setresult

параметры:

pass: захардкоженый пароль - общий для всего API. Строка.
machine: имя компьютера. Строка.
status: 0|1. Число. Возможно только два значения - обозначающие "ok" и "failed" соответственно. Означает общий результат тестирования.
log: лог тестирования. Длинная строка (будем считать, до 64к, но в теории может быть и больше) в кодировке base64.
file_id: число. Идентификатор файла, полученный в предыдущем запросе.

Система смотрит, какой файл проверялся на данной машине, и проставляет ему соответствующий статус.
ЕСЛИ файл на данной машине НЕ проверялся, либо время начала проверки слишком давнее (больше 24 часов), данный запрос следует игнорировать
как невалидный.

Если проверка завершилась успешно, ИЛИ если для данной проверки разрешен откат виртуалки,
следует откатить виртуальную машину через API phpVirtualBox (*В РАЗРАБОТКЕ*)
В противном случае, откат виртуалки не производится, и все ожидающие задачи на проверку на этой машине
так и продолжают ожидать, ПОКА оператор вручную не нажмет кнопку "откатить данную виртуалку".

Для этого, в интерфейсе пользователя должно появиться уведомление оператору, с кнопкой "Откатить".


ДОСТУП

Для минимизации риска утечки данных, нужно чтобы доступ к API не пересекался с обычными учетками системы.
Для этого предлагается:
- чтобы функции API предварялись длинным случайным префиксом в url (security by obscurity)
- функции API проверяли бы захардкоженный пароль, присылаемый в POST (чтобы пароль не светился в логах вместе с GET)
- функции API следует особо тщательно проверить на инъекции.