Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Для того что бы понять надо попробовать гипертрофировать утверждение.
Что даст антивирус на сервере базы данных, или на сервере DNS?
Что даст антивирус на сервере базы данных, или на сервере DNS?
Спасибо, дополню пост.
Считаю, что в этом случае (говоря о DNS на винде) антивирус не нужен в случае:
1) если сервер в отдельном сегменте
2) доступ к нему есть только по порту 53
В противном случае что-нибудь да может прилететь, а после — уже не будет доверия этому серверу.
В любом случае, в вашей задаче мало входных данных.
Считаю, что в этом случае (говоря о DNS на винде) антивирус не нужен в случае:
1) если сервер в отдельном сегменте
2) доступ к нему есть только по порту 53
В противном случае что-нибудь да может прилететь, а после — уже не будет доверия этому серверу.
В любом случае, в вашей задаче мало входных данных.
В топике речь идет о категоричности суждений: мне было однозначно заявлено, что антивирусов на серверах быть не должно. Без оговорок.
Ну категорично тоже судить нельзя. Если, например, это внутренний обменник файлов (даже на linux), то лучше туда поставить антивирус, дабы не распространять заразу между сотрудниками. Все зависит от предназначения сервера.
На моей практике все, куда есть файловый доступ (445, 3389 с маппингом дисков и т.п.) рано или поздно начинает требовать время администратора на очистку от всякой дряни.
Просто я подумал, что за два года, в течение которых я занимался меньше системным администрированием и больше — безопасностью, что-то поменялось )))) Решил уточнить у сообщества. Потому что заявлено было в лоб и без тени сомнения.
Просто я подумал, что за два года, в течение которых я занимался меньше системным администрированием и больше — безопасностью, что-то поменялось )))) Решил уточнить у сообщества. Потому что заявлено было в лоб и без тени сомнения.
Все как всегда, при принятии того или иного решения нужно прислушиваться к здравой логике. Например, я не понимаю политику безопасников раз в пол года для пользователей генерить здоровые пароли. Типичный пользователь такие пароли записывает на бумажку и хранит ее не дальше 2 метров от компа.
Это вопрос компетентности безопасников.
Безопасники должны не только требовать, но и помогать, и обучать. В одной компании, еще до внедрения политики смены и сложности паролей, я периодически делал рассылку, где в простой бытовой форме рассказывал о способах генерирования сложных, но легко запоминающихся паролей. Вы знаете, эффект был потрясающий. Даже без принуждения.
Плюс такие вещи надо рассказывать новым сотрудникам на их испытательном сроке.
Да и вообще, надо быть поближе к рядовым пользователям и знать их проблемы. И решать их =)
Безопасники должны не только требовать, но и помогать, и обучать. В одной компании, еще до внедрения политики смены и сложности паролей, я периодически делал рассылку, где в простой бытовой форме рассказывал о способах генерирования сложных, но легко запоминающихся паролей. Вы знаете, эффект был потрясающий. Даже без принуждения.
Плюс такие вещи надо рассказывать новым сотрудникам на их испытательном сроке.
Да и вообще, надо быть поближе к рядовым пользователям и знать их проблемы. И решать их =)
На моей практике все, куда есть файловый доступ (445, 3389 с маппингом дисков и т.п.) рано или поздно начинает требовать время администратора на очистку от всякой дряни.
У вас странная практика.
Положите вы хоть 100500 вирусных файлов в папку при правильной настройке разрешённых к запуску программ это будет безвредно. Система просто не даст запустить.
Ключевая фраза «при правильной настройке». В рамках данного вопроса не обсуждается насколько гарантированно «правильно настроено» разрешение на запуск программ.
А если кто-то где-то накосячил при «грамотной настройке»? Всегда ли можно полагаться только на одно решение? Не зря ведь даже на дверях квартир устанавливают более одного замка…
А если кто-то где-то накосячил при «грамотной настройке»? Всегда ли можно полагаться только на одно решение? Не зря ведь даже на дверях квартир устанавливают более одного замка…
И сервер баз данных, и DNS — критические ресурсы.
Наблюдал я как-то отвал внутренней зоны DNS, это полная жопа. Выяснилось, что никто даже не может оперативно добраться до бекапов, потому что бекапы на бекапных серверах, а бекапные сервера все знают только по хостнеймам, а кеш DNS везде протух :) Конечно, в итоге всё нашли, то это заняло лишних 10-15 минут как минимум. У конечных пользователей сервис все это время страдал. А что уж говорить про СУБД?
А зараза способна пролезть на сервер и без непосредственного двойного клика на зараженном исполняемом файле. Во имя удобства, доступ по SMB и RPC далеко не всегда ограничивают. Ежемесячная установка патчей — дело важное, но бывают 0-day и бывают инфраструктуры, где перезагрузка одного из серверов кластера требует длительных согласований и большой головной боли.
Наблюдал я как-то отвал внутренней зоны DNS, это полная жопа. Выяснилось, что никто даже не может оперативно добраться до бекапов, потому что бекапы на бекапных серверах, а бекапные сервера все знают только по хостнеймам, а кеш DNS везде протух :) Конечно, в итоге всё нашли, то это заняло лишних 10-15 минут как минимум. У конечных пользователей сервис все это время страдал. А что уж говорить про СУБД?
А зараза способна пролезть на сервер и без непосредственного двойного клика на зараженном исполняемом файле. Во имя удобства, доступ по SMB и RPC далеко не всегда ограничивают. Ежемесячная установка патчей — дело важное, но бывают 0-day и бывают инфраструктуры, где перезагрузка одного из серверов кластера требует длительных согласований и большой головной боли.
Не только для удобства, но иногда строго по необходимости это невозможно. Если днс-сервис работает на контроллере домена — думаю не надо объяснять, что закрыть (как угодно, хоть телеком-фильтрацией) RPC и прочие подобные вещи для него невозможно без потери функциональности. А тому же кидо или любому другому подобному зловреду нужен только открытый порт и соотв. уязвимая системная служба, которую из-за архитектуры винды и конкретной роли не выпилишь.
Я бы сказал так, по поводу опроса. На видне (любой) антивирус необходим. Даже если это достаточно нагруженная БД. В этом случае его надо гибко настраивать на предмет исключений и прочих тонкостей. Исключения — мега критичный софт, а-ля SCADA и безапелляционная официальная позиция вендора о несовместимости его продукта с анитвирусными решениями. Тогда только жесткие компенсационные меры. Максимальная сетевая изоляция, контроль подключаемых устройств, IDS/IPS, которые фактически берут на себя роль антивируса, только делают свою работу на уровне трафика.
Я бы сказал так, по поводу опроса. На видне (любой) антивирус необходим. Даже если это достаточно нагруженная БД. В этом случае его надо гибко настраивать на предмет исключений и прочих тонкостей. Исключения — мега критичный софт, а-ля SCADA и безапелляционная официальная позиция вендора о несовместимости его продукта с анитвирусными решениями. Тогда только жесткие компенсационные меры. Максимальная сетевая изоляция, контроль подключаемых устройств, IDS/IPS, которые фактически берут на себя роль антивируса, только делают свою работу на уровне трафика.
Так для таких ситуаций есть карта сети где должно быть описано какой сервер что он делает ип, номер в стойке и номер порта в коммутаторе, открыл файлик и знаешь что на каком сервере есть и как быстро его найти
Когда вся инфраструктура виртуальная, и виртуальных серверов тысячи, поддержка подобных списков по каждой виртуалке весьма тяжела и вообще нецелесообразна. Системы, которые отслеживают, где что, тоже везде записаны по хостнеймам, да. Как-то никто не подумал, что резервированный по паре десятков серверов DNS может внезапно взять и пропасть сразу везде, не по причине инфраструктурных аварий (сеть, SAN), после устранения которых сервис сразу поднимется. Никто не предусмотрел сценарий, что один из DC может каким-то образом закорраптить базу и отослать реплику на все остальные DC.
Ну в общем те самые 10-15 минут на то, чтобы каким-то образом откопать где-то в тех самых файликах и переписках адреса нужных серверов. Похоже, только в моем отделе люди помнят наизусть все важные устройства по IP адресам, и пропадание DNS никак не мешает доступу к устройствам.
Ну в общем те самые 10-15 минут на то, чтобы каким-то образом откопать где-то в тех самых файликах и переписках адреса нужных серверов. Похоже, только в моем отделе люди помнят наизусть все важные устройства по IP адресам, и пропадание DNS никак не мешает доступу к устройствам.
обычно кто обслуживает данные сервера тот и помнит
Я тоже помню все ИП серваков и хостов правда их не много чуть больше 70
Я тоже помню все ИП серваков и хостов правда их не много чуть больше 70
обычно кто обслуживает данные сервера тот и помнит
Один сервер может обслуживать целая куча разных подразделений, по куче народу в каждом из них.
1) Железо сервера и электропитание/охлаждение
2) SAN
3) Сеть
4) Виртуализация
5) Гостевая ОС
6) Безопасность (какие-нибудь антивирусы, DLP и т.д.)
7) Целевые сервисы, ради которых сервер и греет воздух.
Каждым из этих пунктов обычно занимаются представители разных отделов/департаментов. Кому из них все помнить? :)
правда их не много чуть больше 70
Ага. У меня в подчинении много-много сотен устройств, я, конечно, все наизусть не помню (о некоторых никто годами не вспоминает), но все важные знаю.
но много людей пускать на обслуживание серваков это тоже не безопасно, и они же должны понимать что делаю
А тут не надо всё помнить. Если говорим о куске локалки, где есть dns, то что стоит делать периодический экспорт dns в файл? При полном падении dns поблагодарите себя тысячу раз.
Если это структура вида failover cluster, где много чего крутится, то предварительно составить карту кластера, что его ноды имеют такие адреса и расположены в таких-то стойках с такими вот стикерами. Ну и функционал, который крутится на этом кластере. Это займёт времени только в первый раз.
Если это структура вида failover cluster, где много чего крутится, то предварительно составить карту кластера, что его ноды имеют такие адреса и расположены в таких-то стойках с такими вот стикерами. Ну и функционал, который крутится на этом кластере. Это займёт времени только в первый раз.
стоит делать периодический экспорт dns в файл?
А где хранить файл? Ну вы поняли :)
Догадался бы кто-нибудь до такого сценария отказа — подстелили бы соломки. Теперь подстелили. Можно проработать всё вплоть до нашествия зомби в машинном зале, но про такую «мелочь» (оказывается, кластер из множества контроллеров домена все-таки является единой точкой отказа, так как они многое реплицируют между собой) забудешь.
его ноды имеют такие адреса и расположены в таких-то стойках с такими вот стикерами
XXI век, виртуализация всего и вся, какие еще стикеры, когда все ноды кластера виртуальные на лезвиях в корзинах? Да и зачем ходить к стойкам? Транспорт в порядке, массивы и SAN живы, все машины работают. Просто оказалось, что никто не знает, как до них добраться, и это затянуло решение проблемы на десяток-полтора минут.
А где хранить файл? Ну вы поняли :)
А почему бы не у себя людям, которые отвечают за обслуживание/восстановление/администрирование?
XXI век, виртуализация всего и вся, какие еще стикеры
Ну это для особых случаев :) Ну у меня не сильно большое хозяйство. Помню всё наизусть практически. Не блэйды (нецелесообразно оказалось при просчёте под наши задачи при наших средствах). Кол-во серверов и до сотни не дотянет. Да и кластера виндовые. Так что с любой ноды тупо можно вломиться на нужный сервер и проделать все необходимые операции там. Но все ходы записаны, как говорится. Это как раз на случай, если сервер недостижим по разным причинам (сетевая инфраструктура, или dns, как у вас).
Кстати, если говорим о помещении dc в опасные среды, то для безопасности есть же штука как rodc. Но, как понимаю, в вашему случае неприменимо, ибо всё хранилось в надёжной среде.
А почему бы не у себя людям, которые отвечают за обслуживание/восстановление/администрирование?
То есть N человек, где N>10, должны постоянно актуализировать файл и желательно копировать его к себе локально (даже не в сеть, а то мало ли что)? Учитывая околонулевую вероятность подобных событий? :)
если говорим о помещении dc в опасные среды, то для безопасности есть же штука как rodc
Всякие среды соседствуют… Без RO DC никуда, разумеется. Только они тоже получают закосяченную реплику, да.
Сильно зависит от сервера. На сервере терминалов или на файлопомойке антивирус необходим. А на каком-нибудь сервере БД он будет бесполезен, как мне кажется. От дырки в ОС антивирус всё равно не спасёт, а файлы на этом сервере никто не запускает обычно.
Вы имели ввиду «на сервере БД, к которому есть доступ только по портам БД (1433, 3306 и т.п.)»?
Я смотрю вы прямо кайфуете от номеров портов :)
Я еще номера протоколов знаю =D
Последствия проектирования сегментов (с целью, кстати, снижения рисков вирусного заражения) =) Просто с номерами вопросы и утверждения воспринимаются однозначно =)
Последствия проектирования сегментов (с целью, кстати, снижения рисков вирусного заражения) =) Просто с номерами вопросы и утверждения воспринимаются однозначно =)
ИМХО, вирусное заражение не самое страшное. А по поводу портов — порты могут быть и не стандартные. Да и базы данных тоже бывают разные, а не только mssql и mysql :) Вообще с серверами БД политика безопасности с файрволом слабо применима.
Я ж для примера. Я знаю, что БД бывают разные: черные/белые/красные.
Просто если рассматривать проблему комплексно, то, например, я не хочу, чтобы БД, развернутая на винде, остановилась по причине того, что на этой самой винде начали отваливаться экземпляры svchost с характерными сообщениями (а я такое видел, причем на 2008-й винде) =)
Просто если рассматривать проблему комплексно, то, например, я не хочу, чтобы БД, развернутая на винде, остановилась по причине того, что на этой самой винде начали отваливаться экземпляры svchost с характерными сообщениями (а я такое видел, причем на 2008-й винде) =)
Плюс никто не мешает нам настроить антивирус таким образом, чтобы исключать из сканирования файлы баз данных. Незачем их мучить.
Или вообще какой-нибудь контроль целостности приложений развернуть и отказаться от антивируса (если бюджеты позволяют).
Или вообще какой-нибудь контроль целостности приложений развернуть и отказаться от антивируса (если бюджеты позволяют).
Нет. Я имел ввиду сервер БД, на котором работает только БД и нет никаких других сервисов, которые предполагали бы загрузку или выполнение программ на сервере. Потому что без загрузки файла вирус может пролезть только через дырку в ОС, которую антивирус прикрыть не сможет. Антивирус — это замок на воротах. А ОС — это забор. И каким бы хорошим не являлся замок, от дыр в заборе он не спасёт.
См. выше
А рулить вы этим сервером как будете, если там только порты БД открыты? С главной консоли?
Смотря что подразумевается под «рулить».
Если это подключение по RDP с запретом маппинга дисков клиента и буфера обмена, то нет видимых путей занесения заразы.
А если админ может закинуть туда файл, то это сможет сделать от его имени и какая-нибудь автоматизированная штука, о которой он может не знать. Вот здесь есть видимый путь.
Если это подключение по RDP с запретом маппинга дисков клиента и буфера обмена, то нет видимых путей занесения заразы.
А если админ может закинуть туда файл, то это сможет сделать от его имени и какая-нибудь автоматизированная штука, о которой он может не знать. Вот здесь есть видимый путь.
А антивирус чем поможет в таком случае? Все последние отловленные вирусы на работе (шифровальщики) проходили мимо антивируса — он их просто не знал.
Я вижу, что вы судите не так категорично, как ИТ-менеджер из топика, поэтому считаю ответ на мой вопрос полученным.
Мы уже начали обсуждать конкретные ситуации и взвешивать плюсы и минусы, а значит, вы согласны с подходом, предлагаемым мной.
Спасибо.
P. S. По поводу вашего вопроса… Естественно надо взвешивать все «за» и «против». Может, ваша инфраструктура вполне готова жить без антивируса, я ее не вижу, поэтому не могу однозначно ответить на ваш вопрос.
Мы уже начали обсуждать конкретные ситуации и взвешивать плюсы и минусы, а значит, вы согласны с подходом, предлагаемым мной.
Спасибо.
P. S. По поводу вашего вопроса… Естественно надо взвешивать все «за» и «против». Может, ваша инфраструктура вполне готова жить без антивируса, я ее не вижу, поэтому не могу однозначно ответить на ваш вопрос.
Я вообще никогда категорично не сужу.
Вообще, сама формулировка
Вообще, сама формулировка
не должно быть антивирусов, мы позволяем вам их туда ставить только потому что вы, безопасники, не обладаете нужной квалификацией для создания чистой экосистемы.плохая. Антивирус — это как раз один из шагов при создании «чистой экосистемы».
del
У нас по стандарту в компании все серверы MS должны быть с антивирусом. Если при внутреннем аудите обнаружится сервер без оного, нам дадут по шапке. Это помимо файрволлов на сервере, отдельных VLANов для промышленной среды, выключенных локальных администраторов итд
На ДК тоже держите антивирус?
А что такое ДК? Контроллер домена? Если да — то на нем в первую очередь. И богатый опыт, начиная со времен code red, свидетельствует о том, что это правильно и хорошо. Ну и человек вам верно написал. Плюс фильтрация, плюс сегментация, плюс анализ трафика. Но это когда недетский бизнес, а не контора по пошиву трусов.
Вы не поверите, но таки да. На dc держать антивирь — в первую очередь. Особенно если системы старые, но не снятые с поддержки типа win2k3. Тот же sality мог учинить немало бед, поскольку пакостил достаточно хорошо. Да и 0-day для инфицирования ещё никто не отменял. А эвристика у нынешних антивирусов не так уж и плоха.
Для данной ситуации существует медицинский термит «деменция». Думать головой порой бывает полезно :)
Антивирус сам может быть угрозой. Его код выполняется в режиме ядра, и не так хорошо протестирован, как стандартные компоненты ОС. Кто знает, сколько ошибок в коде антивируса, которыми можно воспользоваться.
Когда никто не знает, я использую статистику с учетом количества используемых сервисов.
Хотя бы так:
kaspersky critical vulnerability
norton critical vulnerability
windows critical vulnerability
mssql critical vulnerability
Хотя бы так:
kaspersky critical vulnerability
norton critical vulnerability
windows critical vulnerability
mssql critical vulnerability
Может. Но, как правило, это происходит гораздо реже, чем инфицирование системы.
Защиту нужно стараться строить многослойной.
Антивирус это один из слоев. Зачем от него отказываться?
Не забываем еще и про человеческий фактор. Знаю пример, когда администратор умудрился воткнуть в «пустой» сервер зараженную флешку со всеми вытекающими из нее последствиями.
Антивирус это один из слоев. Зачем от него отказываться?
Не забываем еще и про человеческий фактор. Знаю пример, когда администратор умудрился воткнуть в «пустой» сервер зараженную флешку со всеми вытекающими из нее последствиями.
>> ISO 27002:2005
А разве сами антивирусные вендоры не предупреждают что это нежелательно?
А разве сами антивирусные вендоры не предупреждают что это нежелательно?
Там имеется ввиду, что периметр защищается одним продуктом, сервера другим, а рабочие станции — третьим. Снижается вероятность пропустить вирус.
Хороший подход.
www.virustotal.com/ru/file/1e3f4e32ef7ad1e7b6e999688b3084f618a53e426e03ef7a5fb65a993e83b13e/analysis/
Пример вируса-шифровальщика. Половина антивирусов его не видит, хотя с момента первого «отлова» и жалобы на virinfo, прошла уже неделя.
При этом ситуация бывает и ровно противоположная. Сегодня первым видит угрозу avast, а drweb пропускает. Завтра первый реагирует drweb.
www.virustotal.com/ru/file/1e3f4e32ef7ad1e7b6e999688b3084f618a53e426e03ef7a5fb65a993e83b13e/analysis/
Пример вируса-шифровальщика. Половина антивирусов его не видит, хотя с момента первого «отлова» и жалобы на virinfo, прошла уже неделя.
При этом ситуация бывает и ровно противоположная. Сегодня первым видит угрозу avast, а drweb пропускает. Завтра первый реагирует drweb.
Хех, вспомнилась старую байку о том, как подрались 2 антивируса :) Не знаю насколько она правдива)
Если мы говорим об антивирусах в операционках (а преимущественно это всё о виндовых системах) на железе, то антивирус не является столь сильным источником деградации производительности системы. И, как правило, утилизация ресурсов в таких случаях не полная. При должной настройке он не потребляет чрезмерно много ресурсов. Если потребление ресурсов настолько велико, что не позволяет поставить антивирус, то тут впору задуматься об апгрейде, поскольку в околопредельных режимах (напр. утилизация памяти/ЦП/носителей по iops на 90%) появляются тормоза.
Т.е. обычно ситуация или «есть ресурсы для утилизации», или «ресурсов нет, пора апгрейдиться». Это беда систем на железе. Невозможно точно подогнать железку под планируемую нагрузку. Или будет простаивать, или будет тормозить функционал.
Если говорим о виртуальных машинах, то тут подгон ресурсов под требования много лучше. Вот тут об антивирусах надо думать более основательно.
Про boot-storm, думаю, знают все. Вот и антивири, думается, вполне способны устроить antivirus-storm. Но не использовать защиты — не знаю. Дыр в системе и 0-day никто не отменял. Помимо дыр в системе могут быть дыры в приложениях, выполняющихся там (тот же веб сервер).
Так что защищаться надо. Как по мне, это совершенно безответственно надеяться, что один UAC и фаервол справятся с защитой, или опасность минует конкретно меня.
Это что касается платформ.
Что касается функционала.
1) Потеря серверов с важным служебным функционалом — даже при наличии дубляжа — вещь неприятная. Лёгший dc или dns — приятного мало. Как минимум заморочки на восстановление и проверку корректности последующего функционирования
2) Потеря серверов со служебным функционалом для приложений, например, сервера лицензий для софта — это простои пользователей. А ну как у вас там отдел проектировщиков, а сервер лицензий к CAD лежит. И тут избыточность, или быстрая развёртка бэкапа рабочей системы — не панацея. Проблема может быть типовой для линейки операционок, и поэтому ситуация повторится и после развёртывания резерва.
Это при том, что в некоторых организациях такой плотный график использования ресурсов, что время на остановку ещё надо согласовать. А тут оно в процессе вывалится.
3) Файлопомойка. Да. Сама помойка может не инфицироваться. Зато может стать отличным перевалочным пунктом для зоопарка, который начал путешествие по сегменту сети.
Но можно сказать: Эй! Не виндой же едины!
Можно. И это правда.
Я лично ни разу за свою жизнь ещё не видел инфицированный sun solaris, centOS или freeBSD.
Но:
1) Ситуацию файлопомойки расписал.
2) Некоторое количество принципиально не имеет кросс-платформенной совместимости (есть у меня такой сервер лицензий для какого-то статистического софта, уж и не помню как зовётся. Но он настолько замечателен, что даже в винде работает на 32 битной системе только если сервер лицензий на 32 битной системе. И соответственно 64-64. Никсовым ничем даже и не пахнет.
3) Реализовать все серверные решения на никсах, а виндовое только самое необходимое для функционирования клиентов на виндах… А что необходимое? В крупной сети это будет dc, wsus. А если упадёт? Нужен дублёр. А если упадёт при дублёре вследствие вредоносного кода? Надо поднимать срочно. Лететь с одним крылом не очень. И думать, есть ли на дублёре подобная дыра?
То есть всё равно даже при попытке ухода серверной инфраструктурой на линуксы/bsd возвращаемся к изначальной проблеме.
Тут на одном форуме в общении поднималась такая тема, там человечек сказал, что антивирусов быть не должно на виртуалках, а целиком на себя функции подобного рода должен брать хост. Но, простите:
1) Я таких решений ещё не видел.
2) Средства защиты в интегрируемых компонентах должны подходить, в таком случае, к целой линейке ОС.
3) Средства защиты должны как-то обновляться, вероятно. Каждодневные обновления, как мне кажется, немножко несвойственный гипервизорам функционал.
4) Системы защиты при функционировании всё так же будут потреблять ресурсы.
5) Как по мне, красота виртуалок заключается и в том, что они относительно друг друга изолированы. А если поражённым окажется гипервизор на хосте и через свою систему защиты (предположим, что такая всё-таки существует) инфицирует виртуалки, что тогда? Я видел инфицированный разновидностью салити касперский лет 5 назад. На работу антивируса влияло лишь в плане невозможности обнаружения инфекции. Но можно же и другой функционал впихнуть.
В общем говоря, уязвимые системы надо защищать. Хочется того или нет. Просто надо всё-таки рассчитывать мощности на вот такую штуку, как защита, хотя и да. Может быть жалко. Но некоторое возможное(!) подтормаживание или ошибка в системе от антивируса всё же гораздо меньшее зло, нежели гарантированная эпидемия/потеря данных/простой при инфицировании незащищённой системы.
Т.е. обычно ситуация или «есть ресурсы для утилизации», или «ресурсов нет, пора апгрейдиться». Это беда систем на железе. Невозможно точно подогнать железку под планируемую нагрузку. Или будет простаивать, или будет тормозить функционал.
Если говорим о виртуальных машинах, то тут подгон ресурсов под требования много лучше. Вот тут об антивирусах надо думать более основательно.
Про boot-storm, думаю, знают все. Вот и антивири, думается, вполне способны устроить antivirus-storm. Но не использовать защиты — не знаю. Дыр в системе и 0-day никто не отменял. Помимо дыр в системе могут быть дыры в приложениях, выполняющихся там (тот же веб сервер).
Так что защищаться надо. Как по мне, это совершенно безответственно надеяться, что один UAC и фаервол справятся с защитой, или опасность минует конкретно меня.
Это что касается платформ.
Что касается функционала.
1) Потеря серверов с важным служебным функционалом — даже при наличии дубляжа — вещь неприятная. Лёгший dc или dns — приятного мало. Как минимум заморочки на восстановление и проверку корректности последующего функционирования
2) Потеря серверов со служебным функционалом для приложений, например, сервера лицензий для софта — это простои пользователей. А ну как у вас там отдел проектировщиков, а сервер лицензий к CAD лежит. И тут избыточность, или быстрая развёртка бэкапа рабочей системы — не панацея. Проблема может быть типовой для линейки операционок, и поэтому ситуация повторится и после развёртывания резерва.
Это при том, что в некоторых организациях такой плотный график использования ресурсов, что время на остановку ещё надо согласовать. А тут оно в процессе вывалится.
3) Файлопомойка. Да. Сама помойка может не инфицироваться. Зато может стать отличным перевалочным пунктом для зоопарка, который начал путешествие по сегменту сети.
Но можно сказать: Эй! Не виндой же едины!
Можно. И это правда.
Я лично ни разу за свою жизнь ещё не видел инфицированный sun solaris, centOS или freeBSD.
Но:
1) Ситуацию файлопомойки расписал.
2) Некоторое количество принципиально не имеет кросс-платформенной совместимости (есть у меня такой сервер лицензий для какого-то статистического софта, уж и не помню как зовётся. Но он настолько замечателен, что даже в винде работает на 32 битной системе только если сервер лицензий на 32 битной системе. И соответственно 64-64. Никсовым ничем даже и не пахнет.
3) Реализовать все серверные решения на никсах, а виндовое только самое необходимое для функционирования клиентов на виндах… А что необходимое? В крупной сети это будет dc, wsus. А если упадёт? Нужен дублёр. А если упадёт при дублёре вследствие вредоносного кода? Надо поднимать срочно. Лететь с одним крылом не очень. И думать, есть ли на дублёре подобная дыра?
То есть всё равно даже при попытке ухода серверной инфраструктурой на линуксы/bsd возвращаемся к изначальной проблеме.
Тут на одном форуме в общении поднималась такая тема, там человечек сказал, что антивирусов быть не должно на виртуалках, а целиком на себя функции подобного рода должен брать хост. Но, простите:
1) Я таких решений ещё не видел.
2) Средства защиты в интегрируемых компонентах должны подходить, в таком случае, к целой линейке ОС.
3) Средства защиты должны как-то обновляться, вероятно. Каждодневные обновления, как мне кажется, немножко несвойственный гипервизорам функционал.
4) Системы защиты при функционировании всё так же будут потреблять ресурсы.
5) Как по мне, красота виртуалок заключается и в том, что они относительно друг друга изолированы. А если поражённым окажется гипервизор на хосте и через свою систему защиты (предположим, что такая всё-таки существует) инфицирует виртуалки, что тогда? Я видел инфицированный разновидностью салити касперский лет 5 назад. На работу антивируса влияло лишь в плане невозможности обнаружения инфекции. Но можно же и другой функционал впихнуть.
В общем говоря, уязвимые системы надо защищать. Хочется того или нет. Просто надо всё-таки рассчитывать мощности на вот такую штуку, как защита, хотя и да. Может быть жалко. Но некоторое возможное(!) подтормаживание или ошибка в системе от антивируса всё же гораздо меньшее зло, нежели гарантированная эпидемия/потеря данных/простой при инфицировании незащищённой системы.
Спасибо за такой развернутый ответ.
Про boot-storm, думаю, знают все. Вот и антивири, думается, вполне способны устроить antivirus-storm.
Запросто. Достаточно всей виртуальной инфраструктуре одновременно начать обновлять антивирусные базы. Массивы резко проседают по IOPS — проверено.
Дыр в системе и 0-day никто не отменял.
Много было уязвимостей, получивших распространение до выхода патча?
Как по мне, это совершенно безответственно надеяться, что один UAC и фаервол справятся с защитой, или опасность минует конкретно меня.
Ещё есть AppLocker и EMET, а антивирус никак не заменяет полноценный IPS.
Я лично ни разу за свою жизнь ещё не видел инфицированный sun solaris, centOS или freeBSD.
А 0-day уязвимостей в них не бывает? Не говоря о том, что CentOS с FreeBSD в корпоративном окружении как Неуловимый Джо.
Я таких решений ещё не видел.
www.vmware.com/products/vsphere/features-endpoint
Менеджера можно понять, антивирус потребует серьёзного тестирования не только при пусконаладке, но и при каждом обновлении (вдруг сигнатура сожрёт критическое приложение/файрвол начнёт блокировать половину пакетов/деградирует производительность). А у него change management и бюджет на год уже утверждён, так что нового сотрудника не взять, а если взвалить на имеющихся, то они могут погрязнуть в рутине.
Я не утверждаю, что его быть не должно, особенно если регуляторы требует, но при возможности стараюсь избегать или сокращать его зону влияния (VMware Endpoint).
Я не утверждаю, что его быть не должно, особенно если регуляторы требует, но при возможности стараюсь избегать или сокращать его зону влияния (VMware Endpoint).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Антивирус на сервере — быть или не быть?