Доп. сервера управления - Вопросы по Symantec Endpoint Protection - Форумы Anti-Malware.ru Перейти к содержанию
Flickerlight

Доп. сервера управления

Recommended Posts

Flickerlight

Доброе всем утро/день/ночь.

Переодически возникает проблема с обновлением дополнительных серверов управления SEP.

Для начала о структуре устновленного SEP.

Есть сайт SEP, где соответсвенно крутится база SQL и работет основной сервер.

К основному серверу подключается ряд дополнительных серверов SEP (географически расположенных в других городах). Такова политика партии компании.

При обновлении базы на основном сервере (с помощью файла *.jdb) начинают обновлятся доп. сервера (здесь все вроде как надо), но вот что происходит потом:

1. При обновлении основного сервера файлом размером порядка 85 Mb на доп. сервера уходит траффик в разы больше (приходится ограничивать скорость во избежании полной загрузки каналов)

2. По истечении неопределенного времени, которое затрачено на обновление сервера, клиенты, подключенные к доп. серверу остаются необновленными. Помагает только перезапуск сервиса SEPM на доп. сервере или его железная перезагрузка.

Уважаемые гуру, может кто сталкивался с такой проблемой, ее победил или сможет прокомментировать ситуацию, дабы успокоить админов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Олег Шабуров

у меня больше вопросов чем ответов)

К основному серверу подключается ряд дополнительных серверов SEP

это реализовано дополнительными сайтами? или SEPM сервера из регионов обращаются к удаленной базе данных, расположенной в основном филиале?

В зависимости от этого будут дальнейшие ответы...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Flickerlight
у меня больше вопросов чем ответов)

это реализовано дополнительными сайтами? или SEPM сервера из регионов обращаются к удаленной базе данных, расположенной в основном филиале?

В зависимости от этого будут дальнейшие ответы...

Почему-то я догадывался, что вопросов будет много )

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Олег Шабуров
анализ траффика показал постоянные sql-запросы, как я понял, это нормально

правильно.

Именно поэтому существует рекомендация иметь SEPM и SQL как можно ближе (в идеале на одном свитче). При малом кол-ве клиентов это не так важно, но при большом - может быть очень критично, т.к. постоянные запросы по узким каналам могут положить канал связи и серьезно "тормозить" SEPM.

Можете более детально описать инфраструктуру:

- сколько филиалов? + сколько там клиентов?

- есть ли "подфилиалы"? + сколько в них клиентов?

- ширина каналов?

- есть ли в филиалах прямой доступ в интернет или все идет через центр?

Может будет больше вопросов, но пока хватит.

Если не хотите делиться этой инфомацией публично, то можем пообщаться лично.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Flickerlight
Можете более детально описать инфраструктуру:

- сколько филиалов? + сколько там клиентов?

- есть ли "подфилиалы"? + сколько в них клиентов?

- ширина каналов?

- есть ли в филиалах прямой доступ в интернет или все идет через центр?

Может будет больше вопросов, но пока хватит.

Если не хотите делиться этой инфомацией публично, то можем пообщаться лично.

Информация такова:

1. Есть один головной офис, к которому в идеале должно подключится порядка 15 филиалов. У последних сеть тоже разветвленная (подфилиалы), но там планировалось обновления забирать с выделенных станции обновления (при необходимости), что б не "рожать" еще больше серверов.

2. По количеству клиентов - цифры будут разные, от величины филиала зависит. Где-то 500, где-то 300.

3. Ширина каналов различная, от 2 Мб до 512 Кб (есть предпосылки к увеличению), поэтому вынуждены ограничивать траффик.

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

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

6. Прямого доступа в Интернет для серверов SEP - нет.

7. Возможно использовать Live Update, конечно, ставить расписание в ночь и прочее, но у последнего обновления занимают от 1.5 Gb, а это "пипец" (с).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Олег Шабуров

Есть причины по которым не хотите полностью избавиться от серверов SEPM в регионах?

Мое предложение следующее:

1. Центральный офис: 2 SEPM (один из которых для отказоустойчивости и балансировки нагрузки).

2. Филиалы: в каждом филиале по 2 GUP (один из которых для отказоустойчивости).

3. Подфилиалы: в них тоже GUP, если есть возможность сделать пару - хорошо.

Теперь детали.

1. На SEPM-серверах храните большое кол-во обновлений. Если обновления качаются 3 раза в день, то желательно хранить около 45 обновлений (это необходимо для генерации дельт в тех случаях, когда машины пользователей не будут включаться по две недели). Это, конечно, займет довольном много дискового пространства (среднее обновление около 220МБ на диске + 70МБ в базе данных), но существенно облегчит нагрузку на каналы связи.

2. GUP-ами назначаете машины, которые постоянно в онлайне, желательно какой-нибудь файловый или другой сервер. На нем тоже устанавливаете срок хранения обновления подольше (недели достаточно, если понадобится дельта за больший срок - SEPM ее сгенерирует).

Если нагрузка на канал очень критична, то настраиваете GUP таким образом, что клиенты никогда не будут обращаться за обновлениями напрямую к SEPM.

3. В подфилиалах то же самое, что и в филиалах, но срок хранения обновленй можно сделать поменьше.

4. Дальше мониторите состояние GUP-ов и остальных клиентов. Например для этого можно использовать GUP Monitor.

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

но у последнего обновления занимают от 1.5 Gb

LUA - штука, не особо экономящая трафик.

У нас сейчас есть идея переработать его, чтобы он был более экономный, но это проект не на ближайшее время.

Поэтому настоятельно рекомендую использовать GUPы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Flickerlight

Тут вот какое дело.

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

Хотя возможно что-то делали не так, может буквари по SEP не дочитали.

P.S. Олег, может есть возможность как-то более он-лайн пообщаться?

P.P.S С уважением, Александр.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Олег Шабуров
может есть возможность как-то более он-лайн пообщаться

конечно, пишите на почту: oleg подчеркивание shaburov собака symantec.com

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
radamol

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Олег Шабуров
Ребята, выкладывайте пожалуйста хотя бы результаты личного общения

обязательно, как только пообщаемся получше.

а если есть какое-то недопонимание - пишите, подскажем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • demkd
      Да есть такой баг, выбор целого диска не предусмотрел.
    • PR55.RP55
      Сейчас попробовал добавить файлы и... E:\ [Error: 0x3 - The system cannot find the path specified. ] т.е. Файл > Добавить в список >  Все исполняемые файлы каталога. или пишет вышеуказанную ошибку или вешается. Это и на Win 7 и на Win 10 и с HDD дисками и с USB Диски нормально открываются т.е. доступны.
    • demkd
      А ничего с этим не сделать старые версии windows проблемные там система сама балуется внедрением потоков при очень низком уровне защиты системных процессов, а эцп вообще ничего не гарантирует когда речь заходит о внедренных потоках, зловред вполне может внедрить поток в системный процесс как с помощью подкинутой в правильное место "легитимной" dll, так и просто создав его, а тот уже в свою очередь внедрить в следующий системный и ищи концы среди вот этого вот всего.
      Все это усугубляется тем что тот же SVCHOST.EXE который был когда запущен может оказаться совсем не системным, хотя путь у него будет правильным как и файл будет иметь валидную эцп и запущен он будет якобы services.exe, в 10ке такое провернуть уже сложнее, а вот 7ке легко, потому урезать лог по принципу "оба файла имеют эцп" никак нельзя.
    • PR55.RP55
      uVS v5.0.6v x64 [http://dsrt.dyndns.org:8888]: Windows 7 Home Basic x64 (NT v6.1 SP1) build 7601 Service Pack 1 [C:\WINDOWS] (!) ПРЕДУПРЕЖДЕНИЕ: Ф зафиксировал внедрение потока C:\WINDOWS\SYSTEM32\SERVICES.EXE [428] внедрил поток [380] в процесс: C:\WINDOWS\SYSTEM32\SVCHOST.EXE [876]   C:\WINDOWS\SYSTEM32\SVCHOST.EXE [1060] внедрил поток [1276] в процесс: C:\WINDOWS\SYSTEM32\SVCHOST.EXE [336] и т.д.  А есть ли смысл выводить в лог десяток - другой аналогичных записей, если все эти файлы  в базе проверенных и у них легальная цифровая?  
    • demkd
      ---------------------------------------------------------
       5.0.6
      ---------------------------------------------------------
       o Добавлено 4 новых ключа автозапуска в список для проверки.

       o Добавлен новый статус "UWP".
         Его получают пакеты приложений универсальной платформы Windows (Universal Windows Platform Apps).

       o Добавлен новый твик #46: Отключить Windows Terminal и очистить реестр.
         Если Windows Terminal активен, в лог выдается предупреждение.
         При обнаружении подозрительных настроек Windows Terminal в конфигурационных файлах, реестре или в каталогах с фрагментами в лог выводится предупреждение.
         Если подозрительная строка найдена в JSON-файле настроек, то в список автозапуска добавляется этот файл с содержимым со статусом "подозрительный".
         В любом случае рекомендуется отключить Windows Terminal, а еще лучше немедленно удалить это из системы.
         Windows Terminal — крайне уязвимый и неоптимизированный кусок кода.

       o Улучшена функция масштабирования удаленного рабочего стола, повышено качество аппаратного апскейла, добавлен параметр "Резкость".
         (Требуется D2D и DX11 на клиентском компьютере)

       o Исправлена старая ошибка в функции отправки ответов серверной части uVS.
         Из-за ошибки в редких случаях могло происходить подвисание серверной и клиентской частей uVS при работе с удаленной системой.

       o Исправлена ошибка в функции завершения серверной части при выходе из удаленной системы.

       o Оптимизирована функция подключения к удаленной системе.

       o Оптимизирована функция сжатия фреймов для DDAL/DDAw режимов: шрифты теперь не теряют яркость, а картинка DDAL практически неотличима от DDA1/DDA2 на глаз, 
         при этом размер сжатого фрейма вырос лишь незначительно.

       o Добавлена x64 версия report_crash.

       o Обновалена функция сбора дампа при падении uVS, функция перенесена в утилиту report_crash, что позволит
         получить максимально точную информацию о произошедшей ошибке.

       o Временно добавлена аппаратная функция обнаружения разрушения списка автозапуска в памяти uVS, что позволит отлавливать сложные в обнаружении ошибки.
         Есть 5 дампов, по которым не удалось выяснить точное место ошибки и эта функция должна помочь найти проблемное место.
         Функция снижает скорость формирования списка на ~5% на современных процессорах.

       o Исправлена ошибка в функции подсчета удаленных ключей реестра.

       o Исправлена ошибка в функции записи параметров при выходе из uVS.

       o Исправлена ошибка разбора JSON-файлов.

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

       o Из списка доступных для подключения IP-адресов удалены адреса активных VPN.

       
×