Предупреждение: Описанное в статье несколько устарело, т.к. я забросил винды в эпоху Windows 2003.
Каждый раз, когда меня знакомые спрашивают: «какой антивирус лучше?», я могу сказать только одно: «антивирус — как придворный шаман. Бывают лучше, бывают хуже, но определить, кто лучше камлает, не получится». Антивирус не гарантирует защиту от вирусов, более того, у него есть полное моральное право пропустить новую заразу и начать её детектить дня через 2-3 после «инцидента». Т.е. как основное средство защиты он годится не очень.
Ниже описывается настройка windows, которая позволит защититься от любых реальных (т.е. встречающихся в природе) вирусов без использования антивирусов. Данная конфигурация уже 3 с половиной года работает на терминальном сервере, где пользователи (в лучшие времена до 70 человек) совсем не стесняются притаскивать на флешках всяких засранцев, лазать по сети где попало и т.д.
Любой уважающий себя вирус, оказавшись запущенным, тем или иным методом стремится в системе закрепиться, т.е. создаёт исполняемый файл или библиотеку, которая прописывается тем или иным образом в запуск. «Авто» запуск или в форме «дополнения» к другим исполняемым файлам (debugger, hander, плагин, и т.д.) — не важно. Важно: существует барьер под названием «запуск кода». Даже старые-добрые вирусы, дописывающие себя в исполняемые файлы, всё равно должны иметь возможность писать в файлы, которые предполагается запускать.
Безусловно, есть вирусы, размножающиеся без создания файлов (например, мс-бласт). Но условием появления этого вируса должна быть доступность сервера для обращений с носителей вируса или запуск кода через эксплоит в браузере\сетевой компоненте. В случае дыры в браузере дальнейшее размножение не возможно (т.к. нужно обращаться к браузерам на других машинах, а это требует поднятия сервера, куда будут ходить другие пользователи и мотивации пользователям ходить именно на этот узел). В случае дыры в сетевой компоненте и размножения без сохранения на диск, описанная мною методика с большой вероятностью работать не будет и возможна эпидемия. Однако, я не уверен, что антивирусы поймают такой 0day эксплоит, плюс, их (дыры) довольно резво фиксят, так что этот сценарий я откладываю как маловероятный. Наличие же файрволов ещё более уменьшает их опасность. От не-0day вполне же спасает своевременная (автоматизированная) установка обновлений.
Итак, основную бытовую опасность представляют вирусы, запускающиеся «из файла» (хотя бы потому, что они переживают перезагрузку компьютера). Если мы запретим каким-то образом запуск «неправильных» файлов, то проблема будет решена (т.к. несохраняющийся в файле вирус не сможет пережить перезагрузку, а в случае запуска с правами пользователя, даже банального релогина).
В Windows существует технология — политика ограниченного запуска приложений. Её можно активировать в режиме «запрещать всё, что не разрешено». Если поставить запрет полный — для всех, включая администраторов, все файлы, включая библиотеки, то мы получим точную гарантию того, что посторонний (не входящий в список разрешённых) файл не будет запущен. По-крайней мере я пока не слышал, чтобы в этой технологии были дыры. Обращаю внимание, нужно запрещать и библиотеки тоже, потому что печально известный конфикер запускается с флешек именно с помощью запуска библиотеки обманом rundll32.
Однако, запреты и разрешения не будут иметь смысла, если не сформулировать правила, которые запретят запуск «чужаков».
Перед тем, как описать подробно конфигурацию, сформулирую теоретические принципы её организации:
1. То, куда пользователь может писать закрыто для запуска.
2. То, что пользователь может запускать, закрыто для записи.
Эти два простых правила позволяют защитить систему от запуска вирусов пользователем — вирус не может образоваться там, куда пользователь не может писать, а туда, куда вирус сможет писать, не даст нужного эффекта — оттуда будет запрещён запуск. Заодно это защищает (на терминальном сервере) от запуска посторонних приложений с неизвестной прожорливостью по ресурсам.
Но за этой радужной простотой скрывается масса подводных камней.
Камень номер один: дикий софт. ПО, которое хранит исполняемые файлы в профиле пользователя, ПО, которое хочет писать «к себе в каталог». В предлагаемой модели строго действует правило: софт (исполняемые файлы) в своих каталогах, пользовательские данные и настройки в своих, и эти каталоги не пересекаются. (Фактически, это воссоздание классического юникс-вея с /usr/bin и ~, подмонтированным с запретом на +x). Сервера настраивают под задачу (а не подбирают задачи под сервер), так что наличие таких программ может автоматически означать невозможность внедрить описываемую систему. Дикого софта много, и он иногда удивляет (например, Adobe Illustrator хочет много писать в каталог Windows).
Камень номер два: скриптовые языки. От злонамеренного пользователя нас это не защитит, однако, от вирусов вполне защищает запрет на запуск скриптовых расширений. (логика такая: даже если вирус запустит скрипт, запустив разрешённый интерпретатор, он не сможет пережить перезагрузку, так как ему нужно будет после загрузки запустить интерпретатор с скриптом, а создание файлов, из которых можно запускать, включая ярлыки, запрещено).
Камень номер три: у пользователей не будут работать ярлыки. Частично это можно решить разместив нужные ярлыки в all users, но пользователи действительно не любят, когда им запрещают создавать ярлычки. Частично это решается созданием персональных quick launch панелей, на которые пользователь не имеет прав записи (т.е. обновление их идёт по запросу пользователя).
Камень номер четыре: многие обновления не будут ставиться (так как им запрещён запуск). Для решения этой проблемы нужно раскручивать групповую политику, ставить апдейты и закручивать её обратно.
Камень номер пять: сетевые компоненты, наподобие IIS/Exchange. Они всё ещё не могут отвыкнуть от привычки писать куда попало (а в случае IIS и выполнять код откуда попало), но я надеюсь, что вы не делаете Exchange на терминальном сервере.
Другими словами — защита не даётся малой кровью.
Запрет можно прописать в групповой политике сервера (я обычно использую политику с loopback processing и назначаю её на все терминальные сервера), или в локальной политике (gpedit.msc).
Путь к политике — Computer Configuration, Windows Settings, Security Settings, Software Restriction Policies. При первом использовании их нужно создать — правой кнопкой на Software Restriction Policies, «New Software Policies».
Сначала настраиваются пути, которые разрешены (additional rules):
Разрешается к запуску всё, что находится в c:\windows, c:\windows\system32 c:\program files. c:\documents and settings\all users\desktop, c:\documents and settings\Start menu. Всё остальное запрещено. В частности, обязательно нужно запретить запуск из корня диска, т.к. пользователи по-умолчанию могут писать в корень диска (да, это фагофича майкрософта для совместимости с старым тупым софтом). Разрешать запуск из c:\documens and settings\All users\* (оптом_ так же не следует — там лежит каталог общих документов, открытых на запись всем пользователям.
Всё, кроме перечисленного выше, запрещено. Точнее, в ходе работы может захотеться разрешить отдельные каталоги (например, сетевые шары), но следует строго соблюдать описанное правило: можно запускать — нельзя писать. Можно писать — нельзя запускать.
Запрет включается в два этапа — сначала в secruty levels (Disallowed), потом в корне Software Restriction Policy в Enforcement — в «All software files» и «All users».
Использование групповой политики домена хорошо тем, что если вы накосячили в политике и не можете ничего запустить (даже gpedit), то это можно поправить с стороннего сервера.
Конфигурация используется уже несколько лет без особых изменений, за это время не было ни одного случая инфицирования терминального сервера (в лучшие времена до 70 человек с IE6/7 и кучей флешек) или рабочих станций под управлением Windows XP (около трёх десятков в трёх фирмах). В в логах я периодически вижу сообщения о запрете запуска того или иного файла (чаще всего из temporary internet files). За это время было обнаружена масса ПО несовместимого с конфигурацией — от Autodesk view (просмотровщик DWG, кое-как работает, но с матюгами) до Thunderbird (который пытается хранить плагины в профиле у пользователя).
Эксплуатация этой конфигурации в автоматическом режиме с большой вероятностью будет неудачной (то не работает, это не работает), но при небольшом уходе она позволяет забыть о проблеме антивирусов (а в условиях терминального сервера позволяет существенно сэкономить на железе, т.к. нагрузка на сервер сильно уменьшается).
Более того, в этом режиме работает даже один компьютер из-под администратора (специфика применяемого ПО) — за это время не было ни одного удачного инфицирования (хотя теоретически в таких условиях оно возможно).
Тут я уже не очень уверенно могу говорить, но в том небольшом объёме, сколько я их смотрел, там поменяли имена каталогов (в частности, для приложений и all users), что требует существенной переработки политик (с пол-пинка windows 7 с описанными выше путями пользователю не позволяла запускать программы).
Каждый раз, когда меня знакомые спрашивают: «какой антивирус лучше?», я могу сказать только одно: «антивирус — как придворный шаман. Бывают лучше, бывают хуже, но определить, кто лучше камлает, не получится». Антивирус не гарантирует защиту от вирусов, более того, у него есть полное моральное право пропустить новую заразу и начать её детектить дня через 2-3 после «инцидента». Т.е. как основное средство защиты он годится не очень.
Ниже описывается настройка windows, которая позволит защититься от любых реальных (т.е. встречающихся в природе) вирусов без использования антивирусов. Данная конфигурация уже 3 с половиной года работает на терминальном сервере, где пользователи (в лучшие времена до 70 человек) совсем не стесняются притаскивать на флешках всяких засранцев, лазать по сети где попало и т.д.
Теория
Любой уважающий себя вирус, оказавшись запущенным, тем или иным методом стремится в системе закрепиться, т.е. создаёт исполняемый файл или библиотеку, которая прописывается тем или иным образом в запуск. «Авто» запуск или в форме «дополнения» к другим исполняемым файлам (debugger, hander, плагин, и т.д.) — не важно. Важно: существует барьер под названием «запуск кода». Даже старые-добрые вирусы, дописывающие себя в исполняемые файлы, всё равно должны иметь возможность писать в файлы, которые предполагается запускать.
Безусловно, есть вирусы, размножающиеся без создания файлов (например, мс-бласт). Но условием появления этого вируса должна быть доступность сервера для обращений с носителей вируса или запуск кода через эксплоит в браузере\сетевой компоненте. В случае дыры в браузере дальнейшее размножение не возможно (т.к. нужно обращаться к браузерам на других машинах, а это требует поднятия сервера, куда будут ходить другие пользователи и мотивации пользователям ходить именно на этот узел). В случае дыры в сетевой компоненте и размножения без сохранения на диск, описанная мною методика с большой вероятностью работать не будет и возможна эпидемия. Однако, я не уверен, что антивирусы поймают такой 0day эксплоит, плюс, их (дыры) довольно резво фиксят, так что этот сценарий я откладываю как маловероятный. Наличие же файрволов ещё более уменьшает их опасность. От не-0day вполне же спасает своевременная (автоматизированная) установка обновлений.
Итак, основную бытовую опасность представляют вирусы, запускающиеся «из файла» (хотя бы потому, что они переживают перезагрузку компьютера). Если мы запретим каким-то образом запуск «неправильных» файлов, то проблема будет решена (т.к. несохраняющийся в файле вирус не сможет пережить перезагрузку, а в случае запуска с правами пользователя, даже банального релогина).
В Windows существует технология — политика ограниченного запуска приложений. Её можно активировать в режиме «запрещать всё, что не разрешено». Если поставить запрет полный — для всех, включая администраторов, все файлы, включая библиотеки, то мы получим точную гарантию того, что посторонний (не входящий в список разрешённых) файл не будет запущен. По-крайней мере я пока не слышал, чтобы в этой технологии были дыры. Обращаю внимание, нужно запрещать и библиотеки тоже, потому что печально известный конфикер запускается с флешек именно с помощью запуска библиотеки обманом rundll32.
Однако, запреты и разрешения не будут иметь смысла, если не сформулировать правила, которые запретят запуск «чужаков».
Модель безопасности
Перед тем, как описать подробно конфигурацию, сформулирую теоретические принципы её организации:
1. То, куда пользователь может писать закрыто для запуска.
2. То, что пользователь может запускать, закрыто для записи.
Эти два простых правила позволяют защитить систему от запуска вирусов пользователем — вирус не может образоваться там, куда пользователь не может писать, а туда, куда вирус сможет писать, не даст нужного эффекта — оттуда будет запрещён запуск. Заодно это защищает (на терминальном сервере) от запуска посторонних приложений с неизвестной прожорливостью по ресурсам.
Проблемы
Но за этой радужной простотой скрывается масса подводных камней.
Камень номер один: дикий софт. ПО, которое хранит исполняемые файлы в профиле пользователя, ПО, которое хочет писать «к себе в каталог». В предлагаемой модели строго действует правило: софт (исполняемые файлы) в своих каталогах, пользовательские данные и настройки в своих, и эти каталоги не пересекаются. (Фактически, это воссоздание классического юникс-вея с /usr/bin и ~, подмонтированным с запретом на +x). Сервера настраивают под задачу (а не подбирают задачи под сервер), так что наличие таких программ может автоматически означать невозможность внедрить описываемую систему. Дикого софта много, и он иногда удивляет (например, Adobe Illustrator хочет много писать в каталог Windows).
Камень номер два: скриптовые языки. От злонамеренного пользователя нас это не защитит, однако, от вирусов вполне защищает запрет на запуск скриптовых расширений. (логика такая: даже если вирус запустит скрипт, запустив разрешённый интерпретатор, он не сможет пережить перезагрузку, так как ему нужно будет после загрузки запустить интерпретатор с скриптом, а создание файлов, из которых можно запускать, включая ярлыки, запрещено).
Камень номер три: у пользователей не будут работать ярлыки. Частично это можно решить разместив нужные ярлыки в all users, но пользователи действительно не любят, когда им запрещают создавать ярлычки. Частично это решается созданием персональных quick launch панелей, на которые пользователь не имеет прав записи (т.е. обновление их идёт по запросу пользователя).
Камень номер четыре: многие обновления не будут ставиться (так как им запрещён запуск). Для решения этой проблемы нужно раскручивать групповую политику, ставить апдейты и закручивать её обратно.
Камень номер пять: сетевые компоненты, наподобие IIS/Exchange. Они всё ещё не могут отвыкнуть от привычки писать куда попало (а в случае IIS и выполнять код откуда попало), но я надеюсь, что вы не делаете Exchange на терминальном сервере.
Другими словами — защита не даётся малой кровью.
Настройки
Запрет можно прописать в групповой политике сервера (я обычно использую политику с loopback processing и назначаю её на все терминальные сервера), или в локальной политике (gpedit.msc).
Путь к политике — Computer Configuration, Windows Settings, Security Settings, Software Restriction Policies. При первом использовании их нужно создать — правой кнопкой на Software Restriction Policies, «New Software Policies».
Сначала настраиваются пути, которые разрешены (additional rules):
Разрешается к запуску всё, что находится в c:\windows, c:\windows\system32 c:\program files. c:\documents and settings\all users\desktop, c:\documents and settings\Start menu. Всё остальное запрещено. В частности, обязательно нужно запретить запуск из корня диска, т.к. пользователи по-умолчанию могут писать в корень диска (да, это фагофича майкрософта для совместимости с старым тупым софтом). Разрешать запуск из c:\documens and settings\All users\* (оптом_ так же не следует — там лежит каталог общих документов, открытых на запись всем пользователям.
Всё, кроме перечисленного выше, запрещено. Точнее, в ходе работы может захотеться разрешить отдельные каталоги (например, сетевые шары), но следует строго соблюдать описанное правило: можно запускать — нельзя писать. Можно писать — нельзя запускать.
Запрет включается в два этапа — сначала в secruty levels (Disallowed), потом в корне Software Restriction Policy в Enforcement — в «All software files» и «All users».
Использование групповой политики домена хорошо тем, что если вы накосячили в политике и не можете ничего запустить (даже gpedit), то это можно поправить с стороннего сервера.
Практическая эксплуатация
Конфигурация используется уже несколько лет без особых изменений, за это время не было ни одного случая инфицирования терминального сервера (в лучшие времена до 70 человек с IE6/7 и кучей флешек) или рабочих станций под управлением Windows XP (около трёх десятков в трёх фирмах). В в логах я периодически вижу сообщения о запрете запуска того или иного файла (чаще всего из temporary internet files). За это время было обнаружена масса ПО несовместимого с конфигурацией — от Autodesk view (просмотровщик DWG, кое-как работает, но с матюгами) до Thunderbird (который пытается хранить плагины в профиле у пользователя).
Эксплуатация этой конфигурации в автоматическом режиме с большой вероятностью будет неудачной (то не работает, это не работает), но при небольшом уходе она позволяет забыть о проблеме антивирусов (а в условиях терминального сервера позволяет существенно сэкономить на железе, т.к. нагрузка на сервер сильно уменьшается).
Более того, в этом режиме работает даже один компьютер из-под администратора (специфика применяемого ПО) — за это время не было ни одного удачного инфицирования (хотя теоретически в таких условиях оно возможно).
Windows 2008/7/Vista
Тут я уже не очень уверенно могу говорить, но в том небольшом объёме, сколько я их смотрел, там поменяли имена каталогов (в частности, для приложений и all users), что требует существенной переработки политик (с пол-пинка windows 7 с описанными выше путями пользователю не позволяла запускать программы).
