koral5057
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Latest Definitions from Symantec:Information is Currently Unavailable
Имеется SEPM 12.1.2015.2015 на Win2008R2 и более сотни машинок Windows7(x86/x64)/Windows10(x64) под его управлением с клиентами SEP 12.1.7004.6500.
C 04-mar-2020 в панели управления постоянно выводится надпись
Latest Definitions from Symantec:Information is Currently Unavailable
Последняя версия Symantec: Информация недоступна
Обновления для клиентов, тем не менее, скачиваются и раздаются штатно.
Причину и следствие я нашёл, но решения проблемы пока не вижу, о найденной информации поделюсь здесь, может быть кто то уже решил.
1. Начнём с того, что сервисы Symantec плавно переползали в облака Broadcom про причине поглощения с начала 2020, это было известно ещё в 2019-м.
Ссылку на KB в Broadcom я открывал, проверял и делал, что там написано, но всё это не помогло, в моём случае это было отключение IE Enhanced Security Configuration, остальные причины в той статье были проверены и не подтвердились.
И вот теперь XML-файл defstats.xml, отвечающий за инф. о последних обновлениях AV-определений, при попытке получить по фиксированной сслыке (на самом деле нет)
http://securityresponse.symantec.com/avcenter/venc/auto/defstats.xml редиректится на https://www.broadcom.com/avcenter/venc/auto/defstats.xml
в этом можно убедиться, открыв первую ссылку в браузере. Возвращается адекватный документ, который должен был бы обрабатываться, однако нет.
2. Поиск внутри папки менеджера показал, что всем интерфейсом заведует php и единственный скрипт, где проверяется искомая ссылка это C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Php\Include\Dashboard\getVirusDefs.php)
Ну, естественно, первым делом я поправил строчку с URL на новую, памятуя о том, что возможно, менеджеру не нравится редирект, т.к. скрипт проверяет только 200-ю http-ошибку (OK). Прошло около недели, результата не было.
3. Т.к. мои познания в php не очень, решил потренироваться на отдельной машинке, что же всё таки происходит в искомом скриптике и перенёс всю папку \PHP для опытов. Убедился что "hello,world" работает, стал смотреть.
Итак, после вызова curl_exec() показываются http-ошибка=0 (CURLINFO_HTTP_CODE) и curl-ошибка=35 (curl_errno()), что означает "SSL connect error". (Не) удивительно, т.к. новая ссылка на broadcom устанавливает соединение TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384).
SEP Manager данной версии всё ещё (должен) поддерживается до ноября этого года, явный косяк со стороны нового владельца.
4. PHP в менеджере версии 5.3.14. Нашёл, где есть поддержка SHA2-сертификатов, в 5.6.4 уже была, скачал, проверил тестовый скрипт. Если открывать новую ссылку (www.broadcom.com), то возвращается ошибка http 405 (Method Not Allowed), а вот если открывать по-старому, с последующим редиректом (securityresponse.symantec.com) то возвращается http 200 OK.
С причиной и следствием разобрались.
5. Гугление по теме Curl error=35 выдало инф. об обновлении требующихся dll:
php_curl.dll
ssleay32.dll
libeay32.dll
libssh2.dll
Последняя libssh2.dll вообще отстутствует в исходной папке с php, что подтверждает проблему в переезде ссылки с xml c http на https. Естественно, замена файлов ни к чему хорошему не привела, т.к. это потянуло к замене php5.dll и т.п.
6. Очевидный вывод - замена вcего php (5.3.14) на (5.6.4). На боевом сервере, честно говоря, что-то не хочется этого делать. Придётся разворачивать тестовую машину, сервер и тестить на живом примере.
Однако, сравнение бинарных dll показывает, что в SEPM все файлы имеют цифровую подпись Symantec, а
скачанное с https://windows.php.net/downloads/releases/archives/ - нет, что вызывает дополнительную тревогу.
Несколькими часами позднее:
UPD
Решил проблему костылём:
1. Хml обновляется отдельно через Scheduler+wget и кладётся в папку wwwroot локального пустого IIS web-сервера (к примеру), а ссылка в php-скрипте заменена на локальный web-ресурс. После перезагрузки SEPM-сервера ошибка пропала.
2. Ошибка 405 при прямом запросе через Broadcom обусловлена тем, что php-скрипт делает запрос методом POST. Это, по-видимому, сделано намеренно для обхода кеширования запросов локальными прокси-серверами (нужна же 100% актуальная информация). Но почему то прямой POST-запрос на broadcom.com не проходит, только через 301-редирект. Поэтому у себя на IIS нужно разрешить метод POST, если он запрещён, либо добавлять/заменять опции в скрипте в соответствующем месте:
curl_setopt($ch, CURLOPT_POST, FALSE);
curl_setopt($ch, CURLOPT_HTTPGET, 1); - чтобы получать обновление инф. через метод GET.
У меня ссылка и в wget получается методом GET и равна такой https://www.broadcom.com/avcenter/venc/auto/defstats.xml?47349234, где 47349234- любое случайное число, генерируется дополнительно, цель та же - пробиться сквозь промежуточное кеширование.
Если делать так (через GET), то:
a) либо в свойствах IIS-сервера ещё необходимо тоже сократить время кеширования до минимума
б) либо можно прямо в php вписать генерацию случайного числа и добавлять его в URL запроса локального сервера.
У меня всё.
|
Всего записей: 102 | Зарегистр. 16-09-2005 | Отправлено: 11:23 13-03-2020 | Исправлено: koral5057, 16:46 13-03-2020 |
|
Кто давно "сидит" на SEP, того от Касперского тошнит. Самодостаточный неуправляемый Dark Client незаметен в ресурсах и не просит денех. Вирус не пропустит и даже слишком иногда, имеет брандмауэр и контроль сетевой активности программ. Его нужно только правильно настроить и привыкнуть...