Zabbix как сканер безопасности

    Привет! Все мы знаем и любим такие продукты для vulnerability assessment процессов как Nessus, Qualys, Max Patrol и всякие прочие OpenVAS. Одной из основных задач, которые они решают, является обеспечение контроля версионных уязвимостей.


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


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


    Что развернуто в большинстве продуктовых систем? Конечно же мониторинг. И довольно часто это Zabbix. Так давайте к нему и прикрутимся!


    В одной руке Zabbix


    Все просто: распределенная система агентов, дашборды для визуализации, многопользовательская система доступа, выполнение действий по заданным критериям уже сделаны без нас. Нам не нужно изобретать велосипед и делать это все с нуля.


    Прав у Zabbix-а хватает на получение информации о пакетах, куда их сложить тоже есть. Осталось их объединить и отправить на анализ в Vulners API. А затем обработать полученные знания об уязвимостях.


    Но давайте начнем с небольшого вступления, что умеет Zabbix и что нам потребуется сделать.


    Zabbix-агенты устанавливаются на сервера и позволяют:


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

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


    Анализируя полученные данные и основываясь на достаточно гибкой логике он может выполнять различные действия:

    • Отправлять оповещения по различным каналам (почта, смс, мессенджеры и т.д.);
    • Подключаться к серверам по SSH или IPMI и выполнять на них различные команды;
    • Или же выполнять различные корректирующие команды на серверах используя подключения к ним Zabbix-агент;

    Веб-интерфейс написан на PHP и позволят отображать собранные Zabbix-ом метрики, графики, сработавшие оповещения о проблемах, и выполненные системой мониторинга команды и действия.


    Также через веб-интерфейс осуществляется администрирование Zabbix.


    Zabbix API является API на основе веб и поставляется как часть веб-интерфейса. Он использует протокол JSON-RPC.


    • Позволяет получать, создавать, конфигурировать и удалять любые объекты в системе мониторинга.
    • Используя API можно с легкостью интегрировать систему мониторинга с различными внешними системами.

    Однако Zabbix ничего не знает про уязвимости! Зато про них знает Vulners :)


    В другой руке Vulners


    • Агрегатор данных об уязвимостях из более чем 115 источников
    • Удобное API для различных способов сканирования
    • Выдает данные в нормализованном, машино-читаемом виде
    • Работает очень быстро
    • Позволяет коррелировать данные из различных источников

    Мы попробовали их друг с другом интегрировать и вот что из этого получилось.


    Zabbix Threat Control


    Это плагин к Zabbix, с открытым исходным кодом, написан на Python, который:


    • Отображает в веб-интерфейсе Zabbix информацию об уязвимостях, найденных в вашей инфраструктуре.
    • Показывает уровень угрозы каждой уязвимости по стандарту CVSS.
    • И предлагает легко применимые способы устранения найденных уязвимостей.

    CVSS это открытый промышленный стандарт оценки критичности уязвимости. По сути — 10 бальная шкала.


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

    Про этот плагин мы рассказывали на Zabbix Moscow Meetup. Для тех, кто не любит читать, но любит смотреть — есть видео доклада.

    Консолидируйте информацию об уязвимостях


    Результат работы плагина в Zabbix выглядит следующим образом:


    Dashboard
    Это дашборд в Zabbix. На котором, слева на право, отображается следующая информация:


    • Распределение CVSS-балла по серверам. Круговая диаграмма показывает соотношение — как много у нас серверов с критическими уязвимостями, сколько имеют не критичные уязвимости или же вовсе не имеют известных уязвимостей.
    • Медианное значение CVSS-балла всей инфраструктуры. Отображается в виде графика, что позволяет наблюдать динамику его изменения.
    • Список уязвимых пакетов с индексом влияния уязвимости на инфраструктуру.
    • Полный список уязвимых серверов с уровнем угрозы для каждого из них.
    • Список бюллетеней безопасности, которые были «найдены» в инфраструктуре.

    Ниже более подробно про самое интересное:


    Информация об уязвимых серверах:


    Hosts


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


    По каждому серверу доступна следующая информация:


    1. Собственно имя уязвимого сервера.
    2. Максимальный CVSS-балл сервера. Отображается самый высокий балл из всех найденных уязвимостей для этого сервера.
    3. Команда для устранения всех обнаруженных уязвимостей на этом сервере. Выполнив которую, мы получим сервер, на котором отсутствуют известные версионные уязвимости.

    Данные представлены с сортировкой по CVSS, от максимального к минимальному. Это позволяет держать сервера, требующие наибольшего внимания, всегда наверху списка, перед глазами.


    Следующая панель показывает уязвимые пакеты:


    Packages


    Здесь для каждого уязвимого пакета в нашей инфраструктуре мы имеем краткую сводку:


    1. Имя уязвимого пакета.
    2. Уязвимая версия пакета.
    3. Количество серверов, на которых установлена уязвимая версия пакета.
    4. CVSS-балл данной версии пакета.
    5. Индекс влияния этой уязвимости на инфраструктуру.
    6. Список всех серверов, на которых обнаружена уязвимая версия пакета.
    7. Ссылка на бюллетень безопасности. Позволяет прочитать и понять насколько эта уязвимость критична именно в нашей ситуации.
    8. Команда исправляющая уязвимость в данном пакете.

    Данные представлены с сортировкой по Индексу влияния, от максимального к минимальному.


    Индекс влияния — это количество затронутых уязвимым пакетом серверов, умноженное на CVSS-балл уязвимости. Зачастую бывает что уязвимость с не самым выскоким балом имеет гораздо большее распространение в инфраструктуре, и поэтому потенциально более опасна.


    Выбирайте стратегии устранения уязвимостей


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


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


    Поэтому всегда стоит выбор — какие пакеты мы можем безболезненно обновить. По каким пакетам необходим отдельный план работ по реализации компенсирующих мер. А по каким мы можем принять риски.


    Предлагаемый в плагине подход позволяет выбирать подходящую вам стратегию устранения уязвимостей:


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

    Устраняйте найденные уязвимости


    Но мало знать какие у нас уязвимости и определить как и какие из них можно устранить. Необходимо ещё и сделать это!


    Для централизованного управления конфигурациями и обновления ПО широко используются такие системы как Puppet или Ansible. Вы можете использовать fix-команду, устраняющую уязвимость, и централизованно её выполнить с помощью таких систем.


    Если же в вашей инфраструктуре не используются такие системы — Zabbix Threat Control позволяет устранять уязвимости прямо из веб-интерфейса Zabbix.



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


    1. Как только проблема будет подтверждена через веб-интерфейс авторизованным на это пользователем;
    2. Запустится удаленная команда, которая выполнит на целевом сервере, или списке серверов, fix-команду исправляющую уязвимость.

    Как это работает



    1. Zabbix-сервер получает через zabbix-агенты информацию о пакетах и об операционной системе всех серверов в инфраструктуре.
    2. Плагин (с помощью Zabbix API) получает ранее собранный Zabbix-сервером отчет об ОС. Непосредственно с серверов плагин ничего не получает. И на данном этапе не треует с ними прямого контакта.
    3. Обработав полученную от Zabbix информацию плагин передает её в Vulners. От которого в ответ получает список найденных уязвимостей, их критичность и способ устранения.
    4. Плагин обрабатывает полученные данные, агрегирует их для формирования статистики и формирует пакеты данных для передачи в Zabbix.
    5. Плагин пушит в Zabbix данные в необходимом системе мониторинга формате. Делает он это с помощью утилиты zabbix-sender. После этого вы уже имеете в мониторинге все о найденных уязвимостях, которые отображаются на показанном ранее дашборде.
    6. После подтверждения проблемы выполняется удаленная команда, которая передает плагину:
      • Имя того, кто её инициировал
      • Fix-команду исправления уязвимости
      • Cписок серверов
    7. Получив все это Zabbix Threat Control:
      • Проверяет что команда на исправление инициирована тем, кем нужно. От того, кого не нужно — он команду не принимает :)
      • Выполняет переданную ему команду на нужном количестве серверов.

    По умолчанию плагин передает fix-команду на уязвимые сервера с помощью утилиты zabbix-get, обращаясь к Zabbix-агенту на целевом сервере с параметром nowait. Такой способ подключения позволяет процессу обновления пакетов выполняться в фоне не быть привязанным к процессам zabbix-агента. Также есть возможность выполнять команду на целевом сервере через простое SSH-подключение. Способ выполнения fix-команд выбирается опцией в конфигурацоинном файле плагина.


    И как результат работы — отсутствие уязвимых серверов, ваш спокойный сон и отличное настроение :)


    Установка


    Мы рассказали, что такое Zabbix Threat Control, зачем он нужен и как работает. Теперь расскажем как его установить и настроить!


    Зависимости


    Для работы плагин не требует ничего сверхестественого. Необходимо чтобы на Zabbix-сервере, на который мы ставим планиг, было следующее:


    • zabbix v3.4 для использования кастомных дашбордов (они появились только в этой версии).
    • zabbix-sender нужен для отправки в данных об уязвимостях в систему мониторинга.
    • zabbix-get для отправки fix-команд, исправляющих уязвимости, на сервера.
    • python v3 с модулями: pyzabbix, jpath, requests для запуска основных скриптов плагина.

    На всех серверах, для которых требуется сканирование на уязвимости требуется только:


    • zabbix-agent для сбора данных и запуска скриптов.
    • python v2 для запуска скрипта собирающего отчет об ОС.

    Установка плагина из пакетов


    Для начала подключаем репозиторий с пакетами:


    RPM-дистрибутивы


        rpm -Uhv https://repo.vulners.com/redhat/vulners-repo.rpm

    DEB-дистрибутивы


        wget https://repo.vulners.com/debian/vulners-repo.deb
        dpkg -i vulners-repo.deb

    После этого на Zabbix-сервере устанавливаем основной пакет, обеспечивающий всю логику работы плагина и пакет, формирующий отчетность об ОС:


    RPM-дистрибутивы


        yum install zabbix-threat-control-main zabbix-threat-control-host

    DEB-дистрибутивы


        apt-get update && apt-get install zabbix-threat-control-main zabbix-threat-control-host

    И на всех остальных серверах, для которых требуется сканирование на уязвимости, устанавливаем пакет, формирующий отчетность об ОС:


    RPM-дистрибутивы


        yum install zabbix-threat-control-host

    DEB-дистрибутивы


        apt-get update && apt-get install zabbix-threat-control-host

    Установка из исходников


    Если вы предпочитаете установку из исходиников, то сделать это тоже очень просто:


    На Zabbix-сервере устанавливаем основные скрипты, обеспечивающие всю логику работы плагина и скрипт, формирующий отчетность об ОС:


        git clone https://github.com/vulnersCom/zabbix-threat-control.git
        # main
        mkdir -p /opt/monitoring/zabbix-threat-control
        cp zabbix-threat-control/ztc* /opt/monitoring/zabbix-threat-control/
        chown -R zabbix:zabbix /opt/monitoring/zabbix-threat-control
        chmod 640 /opt/monitoring/zabbix-threat-control/ztc_config.py
        touch /var/log/zabbix-threat-control.log
        chown zabbix:zabbix /var/log/zabbix-threat-control.log
        chmod 664 /var/log/zabbix-threat-control.log
        # host
        cp -R zabbix-threat-control/os-report /opt/monitoring/
        chown -R zabbix:zabbix /opt/monitoring/os-report

    На всех остальных серверах, для которых требуется сканирование на уязвимости ставим только скрипт, формирующий отчетность об ОС:


        git clone https://github.com/vulnersCom/zabbix-threat-control.git
        # host
        mkdir -p /opt/monitoring/
        cp -R zabbix-threat-control/os-report /opt/monitoring/
        chown -R zabbix:zabbix /opt/monitoring/os-report

    Настройка


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


    Настраиваем сервера, требующие сканирования


    Необходимо разрешить Zabbix агенту выполнять удаленные команды. Для этого на всех серверах, для ктороых требуется сканирование, измените параметры в файле конфигурации zabbix-agent как показано ниже:


    EnableRemoteCommands=1
    LogRemoteCommands=1

    Файл конфигурации zabbix-агента обычно расположен здесь: /etc/zabbix/zabbix_agentd.conf


    Если вы хотите использовать функционал по устранению найденных уязвимостей с помощью Zabbix Threat Control, вам необходимо разрешить пользователю zabbix выполнять обновление пакетов (но не их установку или удаление).


    Для этого необходимо добавить следующую строку в файл /etc/sudoers:

    Для RPM-дистрибутивов строка выглядит так:


    zabbix ALL=(ALL) NOPASSWD: /usr/bin/yum -y update *

    Для DEB-дистрибутивов немного по-другому:


    zabbix ALL=(ALL) NOPASSWD: /usr/bin/apt-get --assume-yes install --only-upgrade *

    Подключаемся к Vulners


    Для использования Vulners API вам нужен api-ключ. Чтобы получить его:


    • Зарегистрируйтесь на vulners.com
    • В личном кабинете перейдите на вкладку API KEYS
    • Выберите "Scan" в области Scope и нажмите «GENERATE NEW KEY».

    Вы получите api-ключ, который выглядит следующим образом: RGB9YPJG7CFAXP35PMDVYFFJPGZ9ZIRO1VGO9K9269B0K86K6XQQQR32O6007NUK



    Теперь вам нужно добавить api-ключ Vulners в конфигурационный файл плагина /opt/monitoring/zabbix-threat-control/ztc_config.py


    Пример:


    vuln_api_key = 'RGB9YPJG7CFAXP35PMDVYFFJPGZ9ZIRO1VGO9K9269B0K86K6XQQQR32O6007NUK'

    Подключаемся к Zabbix


    Чтобы плагин смог подключиться к Zabbix, вам нужно указать следующие данные в файле конфигурации: /opt/monitoring/zabbix-threat-control/ztc_config.py


    • адрес веб-интерфейса Zabbix для работы с Zabbix-API;
    • имя и пароль пользователя, под которым будем подключаться к Zabbix API.

    доменное имя и порт Zabbix сервера для отправки данных с помощью утилиты zabbix-sender.

    Пример:


    zbx_pass = 'yourpassword'
    zbx_user = 'yourlogin'
    zbx_url = 'https://zabbixfront.yourdomain.com'
    
    zbx_server_fqdn = 'zabbixserver.yourdomain.com'
    zbx_server_port = '10051'

    Подготавливаем Zabbix


    Необходимо создать в Zabbix объекты, обеспечивающие работу плагина. Для этого нужно запустить скрипт /opt/monitoring/zabbix-threat-control/ztc_create.py. Скрипт проверит что плагин сконфигурирован верно и, используя API создаст в Zabbix:


    1. Хост-группу, в которую добавятся хосты, отображающие уязвимости.
    2. Шаблон, с помощью которого собирается отчет об ОС со всех серверов.
    3. Хосты для отображения уязвимостей по пакетам, серверам, бюллетеням и общей статистики.
    4. Экшен для выполнения удаленных команд по исправлению уязвимостей.
    5. Дашборд для удобного отображения все этой информации.


    После создания в Zabbix всех объектов скрипт покажет:


    • Ссылку на созданный дашборд в Zabbix, на котором будут отображаться уязвимости.
    • Время, когда будет запускаться сканирование инфраструктуры на уязвимости.

    После того, как в Zabbix буду созданы все необходимые объекты, необходимо зайти в веб-интерфейс Zabbix и слинковать только что созданный скриптом шаблон "Vulners OS-Report" со всеми теми серверами, для которых требуется сканирование на уязвимости.



    После этого остается дождаться запуска плагина в указанное при инсталляции время.


    Сканируем!


    Запуск основного скрипта обработки данных (ztc.py) происходит автоматически, один раз в сутки, через "Service Item..." на хосте "Vulners — Statistics" в указанное скриптом время.


    Вы можете поменять время запуска плагина на любое удобное вам, изменив "Scheduling interval" в этом элементе данных. При этом необходимо откорректировать и время сбора статистики в трех элементах данных шаблона "Vulners OS-Report" – метрики в шаблоне должны срабатывать минут на 10…15 раньше, чем основная метрика "Service Item..." на хосте "Vulners — Statistics".


    Время за которое будут обработаны все данные об уязвимостях зависит от количества серверов в инфраструктуре и количества установленных на них пакетов. Ориентировочно на обработку 1 тысячи серверов тратится около 30 минут.


    Планы


    Это лишь первая версия плагина Zabbix Threat Control. И мы продолжаем его разработку.


    В планах:

    • Добавить на дашборд информацию по найденным в инфраструктуре CVE.
    • Отказаться установки каких либо скриптов на агенты и собирать всю необходимую информацию об ОС и пакетах с помошью встроенных в Zabbix-агент ключей элементов данных.

    И так как это opensource — присоединяйтесь! Pull requests welcome :)

    Vulners
    14.05
    Company
    Share post

    Comments 19

      0
      Добрый день. Спасибо за статью, очень интересно. Есть несколько вопросов.
      1. Это работает только для linix-хостов? Можно ли подобное делать для Windows систем?
      2. В данном случае мы определяем только уязвимости установленных пакетов. Есть ли возможность сгружать в заббикс данные от сетевого сканера? Т.е. видеть в дашборде дыры, которые образуются в результате miss configuration (открытые порты, слабый пароль и т.д.)?
        0

        Добрый день.
        Да, сейчас плагин работает только с linux системами. Та как мы им решали свою задачу в рамках компании QIWI.
        Добавить функционал сканирования Windows-систем, как и добавить отображение уязвимостей от сетевого сканера — идея интересная, но нужен заказчик :)

          0
          Ну а в целом, Zabbix-агент позволяет собирать информацию об установленных приложениях и самое главное их версиях (под Windows)?
            0
            Промазал =), ответ чуть ниже
            0
            С сайта через раздел Аудит не получается указать Windows в поле ОС, есть какая-то серверная валидация ввода?
            Unknown operation system. Can't find comparator and splitter for packages

            Для того, что бы это заработало с Windows нужно что-то большее чем написать агента/плагин?
            Если есть путь отдать серверу Windows (версия — билд?) и список софта, и получить на это ответ по уязвимостям, то в принципе готов написать на powershell аналог того, что есть у вас на питоне для линукса.
              0
              Да, чтобы заработало сканирование Windows, необходимо реализовать поддержку и на стороне агента и на стороне Vulners API.
          0
          Команда:
          >wmic product get name,version
          выдаст список установленного ПО с именами и версиями, а заббикс-агент может запускать внешние скрипты, вывод которых отдавать заббикс-серверу…
            0
            Понял, спасибо.
              +1
              К сожалению, эта команда охватывает не все установленное ПО:
              C:\Utils>wmic product get name,version | find "SNMP"
              C:\Utils>
              C:\Utils>reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall /s | find "SNMP"
              HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\SNMP Informant Agent Standard Edition_is1
              

              Здесь можно взять powershell-скрипт для получения списка установленного ПО: gallery.technet.microsoft.com/scriptcenter/Get-Software-Function-to-bd2e0204
              0
              Чем данный софт в целом отличается от Vulners Audit Scanner, тем что через Zabbix реализован?
                0
                Технологии и API полностью идентичные.
                Отличается дашбордами, кнопкой «починить» и быстрой интеграцией в систему, если вы используете Zabbix как систему мониторинга.
                  0
                  На самом деле, я бы использовал для визуализации какую-нибудь Grafana. Данные для графиков/таблиц можно выдергивать через Zabbix-API. Получается отдельный интерфейс для безопасников, чтобы они не лазили в IT-шном заббиксе.
                    0

                    Grafana великолепна и ничего не мешает прикрутить её к существующему решению и не смотреть в дашборды Zabbix. Но веб-интерфейс Zabbix умеет выполнять fix-команды по запросу.
                    А еще zabbix-агент умеет работать сразу с несколькими экземплярами Zabbix-сервера. И можно для "безопасников" поставить отдельный экземпляр Zabbix-сервера, в который будут собираться только нужные им данные. И основной Zabbix "не захламлять" и найденные уязвимости не на виду.

                0

                У вас там есть поля для указания причины не устранения уязвимости ?

                  0
                  Такое поле есть. Правда этот функционал еще в разработке :)
                    0
                    У вас там есть поля для указания причины не устранения уязвимости ?

                    Наверное стоит детальнее это прокомментировать. В интерфейсе это сейчас работает вот так:


                    1. При Подтверждении проблемы нужно поставить галочку Close problem и в поле Message написать — почему мы решили проблему закрыть, а не обновлять пакет:
                      Подтверждение


                    2. После этого проблема будет считаться решенной (покрасится в зеленый цвет). И при наведении на нее будет показано то самое сообщение.
                      Решено



                    Осталось сделать чтобы Zabbix Threat Control не игнорировал галочку Close problem, которая указывает что проблема более не актуальна и её "закрыли" вручную. Вот это сейчас в работе.

                  0
                  Индекс влияния — это количество затронутых уязвимым пакетом серверов, умноженное на CVSS-балл уязвимости. Зачастую бывает что уязвимость с не самым выскоким балом имеет гораздо большее распространение в инфраструктуре, и поэтому потенциально более опасна

                  Смею не согласиться. Допустим, у меня имеется 50 серверов с низким уровнем уязвимости и 1 сервер с критической уязвимостью. Из-за такого расчета индекса влияния на верхней позиции окажется строчка с 50 серверами, и, пока я буду устранять уязвимости на этих серверах (а ведь таких серверов/ПК может быть и гораздо больше), может произойти компрометация сервера через критическую уязвимость. Исходя из собственного опыта, в первую очередь я бы начал устранять критические уязвимости и уязвимости с высоким уровнем опасности, т.к. это занимает меньше времени и эффективнее снижает риски ИБ.
                    0

                    Да, вы все верно пишете!
                    Именно по этому мы в ZTC предлагаем группировку и по уязвимым серверам и по уязвимым пакетам.


                    • Группировка по серверам отсортирована именно по максимальному баллу. Это позволяет видеть наиболее уязвимые сервера вверху списка.
                    • Группировка по пакетам отсортирована по индексу влияния. Ну и балл уязвимого пакета тоже виден. При этом у вас есть понимание о масштабах распространения этого уязвимого пакета.

                    А далее вы сами можете выбирать: или обновлять наиболее уязвимвый сервер или же обновлять уязвимый пакет.

                      0

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

                      Only users with full accounts can post comments. Log in, please.