Я сейчас скажу кое-что, но только если вы пообещаете, что не будете кидать в меня камни. Ага, это вы сейчас говорите, что не будете.... ну да ладно, мне уже все равно. Короче, в отличии от, например, BSD, Windows NT не является многопользовательской операционной системой, поскольку только один пользователь может работать с компьютером в любой момент времени и, прежде чем переключиться на другого, необходимо завершить текущий сеанс, закрыв все приложения и лишь потом... А вот в BSD все очень просто: нажал Alt-F# и переключился на соседнюю консоль и все! В Windows XP наконец-то появилась возможность переключения сеансов разных пользователей без завершения, но... механизма взаимодействия между пользователи как не было, так и нет. Да и неудобно это все равно...
Правда, в текущем сеансе можно запускать программы от имени другого пользователя, но это, во-первых, совсем не то, а, во-вторых, далеко не все программы соглашаются на такой запуск, и еще меньше из них сохраняют свою работоспособность в полном объеме. Так что, без бубна здесь не обойтись. Если нет бубна, на худой конец сойдет и обычный оцинкованный таз.
Идея противостояния вирусам в общих чертах заключается в выборе правильной политики разграничения доступа, тогда вирус (или другая зловредная программа) просто не сможет напакостить и нанести сколь-нибудь значительный урон. А для этого все потенциально опасные программы нужно запускать в своеобразной песочнице. В идеале - на виртуальной машине типа VM Ware, однако, про VM Ware мы уже неоднократно писали, а вот про разграничение доступа материалов практически нет.
Начнем с того, что никогда, ни при каких обстоятельствах не следует постоянно сидеть под "администратором", поскольку при этом любая запущенная программа может делать с системой все, что ей вздумается. Под администратором следует заходить в систему только для выполнения "ремонтных" работ - установки новых драйверов, изменения параметров конфигурации и т.д. А все остальное время проводить под "опытным пользователем" или просто "пользователем" с ограниченным доступом. Чем меньше у вас привилегий, тем меньше их и у каждой запущенной вами программы, однако под обыкновенным пользователем многие программы работать отказываются, поскольку требуют записи в каталог Program Files или в другие "злачные" места, поэтому приходиться громко бить в бубен и долго трахаться, но зато потом! Потом наступает тишь да благодать! Ни вирусов, ни малвари...
Необходимости в периодическом резервировании, естественно, никто не отменял. Надежнее всего, конечно, резервироваться на CD-R/RW, DVD-RW, ZIP, стримеры и прочие внешние носители информации, однако это непроизводительно, неудобно, да и надежность у винчестеров все же повыше будет, чем у того же CD-RW. Поступим так. Создадим нового пользователя с администраторскими правами (Пуск -> Панель Управления -> Пользователи и пароли -> Имя -> Пароль -> Другой -> Администраторы), назовем его, к примеру, "backup", зайдем под его именем в систему, создадим каталог general-stores (т.е. общее хранилище) и скопируем туда все, что необходимо. Затем, щелкнув по каталогу правой кнопкой мыши, в появившемся контекстом меню выбираем вкладку "свойства", а там "безопасность" со списком допущенных лиц. По умолчанию каталог доступен для всех, что никак не входит в наши планы, поэтому удаляем "всех" нахрен, предварительно сбросив галочку "переносить наследуемые от родительского объекта разрешения на этот объект". Все!!! Теперь этот каталог недоступен никому, даже системе! И только владелец, создавший его (то есть "backup"), может войти в раздел "безопасность" и вернуть "всех" на место. Внимание! Администратор этого сделать не сможет!!! Ну, вообще-то, чтобы так не извращаться, после удаления "всех" можно добавить пользователя "backup", делегировав ему полный доступ к каталогу. Все же остальные пользователи, включая членов группы "Администраторы", добраться до этого каталога не смогут. Хорошая защита от вирусов и прочих деструктивных программ, не правда ли? (ну вообще-то, если зловредный код получит права администратора, он запросто сможет забить диск мусором на секторном уровне, но к счастью, такие вирусы практически не попадаются). Кстати говоря, задумаемся, а что произойдет, если случайно (преднамеренно) удалить пользователя "backup"? Ведь тогда к архиву доступ не сможет получить никто! К счастью, штатная утилита chkdsk распознает такую ситуацию и если видит подобный каталог-зомби, она автоматически возвращает "всех", воскрешая информацию из небытия.
Нашей следующей задачей будет постройка "песочницы" для всех тех программ, что могут быть атакованы из сети, к числу которых принадлежит IE, FireFox, Outlook Express, The Bat, ICQ и другие. Каждая из них должна быть запущена из-под ограниченного пользователя, не имеющего доступа ни к каким каталогам, кроме тех, что явно нужны самой программе. В принципе, можно завести одного ограниченного пользователя на всех, обозвав его к примеру "sandbox" (то есть, песочница), однако в этом случае червь, пробравшийся через IE, сможет разрушить почтовую базу, накопленную за многие годы, что будет обидно. Поэтому лучше всего дать каждой программе по пользователю (конечно, это увеличивает потребности системы в памяти, но не столь радикально).
Итак, создан ограниченный пользователь "sandbox", в свойствах "безопасности" каждого каталогов (или всех дисков целиков) "sandbox" добавлен и доступ ему запрещен (политика запрета имеет приоритет над политикой разрешений, поэтому удалять "всех" совершенно необязательно). По завершению этой нехитрой операции, у sandbox'а останутся только те каталоги, которые ему нужны (как правило, это каталоги самой программы, причем без права записи в исполняемые файлы).
Попробуем запустить в песочнице ну... например, FireFox. Создаем ярлык с firefox.exe (если только это не сделал инсталлятор), щелкаем по нему правой клавишей, идем в "свойства" и там взводим галочку "запускать от имени другого пользователя". Говорим "ОК" и запускаем. Появляется грозное диалоговое окно, требующее ввода имени и пароля. Вводим. И... ни хрена Горящий Лис не запускается! Между прочим, в Linux/BSD подобная операция протекает без каких бы то ни было проблем. А здесь нужен бубен или более конкретно - файловый монитор Марка Руссиновича, показывающий на каких именно файловых операциях программа обламывается (вот так, значит, разработчики относятся к сообщениям об ошибках). Качаем файловый монитор: http://www.sysinternals.com/Utilities/Filemon.html (он, кстати, занимает меньше двухсот килобайт и распространяется совершенно бесплатно). Запускаем из-под администратора (создаем ярлык и взводим уже известную нам галочку "запускать от..."), запускаем! В данном случае файловый монитор запускается (потому что запрограммирован правильно) и мы быстрым спортивным шагом идем в Options -> Filter/Highlight или нажимаем. В появившемся диалоговом окне взводим все галочки, кроме "Log Successes", поскольку мониторить успешные операции нам нахрен не нужно! Нам нужны ошибки! Нажимаем "OK" и перезапускаем программу (фильтр будет действовать только после запуска). Вновь запускаем Горящего Лиса. Что мы видим? Сначала идут ошибки поиска динамических библиотек в тех каталогах, где их нет - ну это нормально. А вот дальше... дальше, Горящий Лис пытается создать папку Mozilla прямо в каталоге WINNT (в ней он хранит свои настройки, кэш страниц и т.д.), куда его, естественно, не пускают и он тихо умирает.
А вот Опера хранит кэш не в профиле пользователя, а непосредственно в своем каталоге (впрочем, это зависит от ее настроек), поэтому sandbox'у необходимо присвоить права на запись в "program files\opera".
Остальные программы "распутываются" аналогичным образом. Если не помогает файловый монитор, качаем монитор реестра (http://www.sysinternals.com/Utilities/Regmon.html) и смотрим, в каких ветвях нуждается программа. Маленький подводный камень - перенаправить ввод с клавиатуры на файл, увы, не удастся и пароль придется каждый раз вводить вручную, что напрягает. Впрочем, программисты запросто напишут программу лишенную этих недостатков. Нам же главное - создать кучу пользователей, распределив правда доступа так, чтобы зловредные программы не имели никаких шансов ни для размножения, ни для шпионской деятельности.
Правда, в текущем сеансе можно запускать программы от имени другого пользователя, но это, во-первых, совсем не то, а, во-вторых, далеко не все программы соглашаются на такой запуск, и еще меньше из них сохраняют свою работоспособность в полном объеме. Так что, без бубна здесь не обойтись. Если нет бубна, на худой конец сойдет и обычный оцинкованный таз.
Идея противостояния вирусам в общих чертах заключается в выборе правильной политики разграничения доступа, тогда вирус (или другая зловредная программа) просто не сможет напакостить и нанести сколь-нибудь значительный урон. А для этого все потенциально опасные программы нужно запускать в своеобразной песочнице. В идеале - на виртуальной машине типа VM Ware, однако, про VM Ware мы уже неоднократно писали, а вот про разграничение доступа материалов практически нет.
Начнем с того, что никогда, ни при каких обстоятельствах не следует постоянно сидеть под "администратором", поскольку при этом любая запущенная программа может делать с системой все, что ей вздумается. Под администратором следует заходить в систему только для выполнения "ремонтных" работ - установки новых драйверов, изменения параметров конфигурации и т.д. А все остальное время проводить под "опытным пользователем" или просто "пользователем" с ограниченным доступом. Чем меньше у вас привилегий, тем меньше их и у каждой запущенной вами программы, однако под обыкновенным пользователем многие программы работать отказываются, поскольку требуют записи в каталог Program Files или в другие "злачные" места, поэтому приходиться громко бить в бубен и долго трахаться, но зато потом! Потом наступает тишь да благодать! Ни вирусов, ни малвари...
Необходимости в периодическом резервировании, естественно, никто не отменял. Надежнее всего, конечно, резервироваться на CD-R/RW, DVD-RW, ZIP, стримеры и прочие внешние носители информации, однако это непроизводительно, неудобно, да и надежность у винчестеров все же повыше будет, чем у того же CD-RW. Поступим так. Создадим нового пользователя с администраторскими правами (Пуск -> Панель Управления -> Пользователи и пароли -> Имя -> Пароль -> Другой -> Администраторы), назовем его, к примеру, "backup", зайдем под его именем в систему, создадим каталог general-stores (т.е. общее хранилище) и скопируем туда все, что необходимо. Затем, щелкнув по каталогу правой кнопкой мыши, в появившемся контекстом меню выбираем вкладку "свойства", а там "безопасность" со списком допущенных лиц. По умолчанию каталог доступен для всех, что никак не входит в наши планы, поэтому удаляем "всех" нахрен, предварительно сбросив галочку "переносить наследуемые от родительского объекта разрешения на этот объект". Все!!! Теперь этот каталог недоступен никому, даже системе! И только владелец, создавший его (то есть "backup"), может войти в раздел "безопасность" и вернуть "всех" на место. Внимание! Администратор этого сделать не сможет!!! Ну, вообще-то, чтобы так не извращаться, после удаления "всех" можно добавить пользователя "backup", делегировав ему полный доступ к каталогу. Все же остальные пользователи, включая членов группы "Администраторы", добраться до этого каталога не смогут. Хорошая защита от вирусов и прочих деструктивных программ, не правда ли? (ну вообще-то, если зловредный код получит права администратора, он запросто сможет забить диск мусором на секторном уровне, но к счастью, такие вирусы практически не попадаются). Кстати говоря, задумаемся, а что произойдет, если случайно (преднамеренно) удалить пользователя "backup"? Ведь тогда к архиву доступ не сможет получить никто! К счастью, штатная утилита chkdsk распознает такую ситуацию и если видит подобный каталог-зомби, она автоматически возвращает "всех", воскрешая информацию из небытия.
Нашей следующей задачей будет постройка "песочницы" для всех тех программ, что могут быть атакованы из сети, к числу которых принадлежит IE, FireFox, Outlook Express, The Bat, ICQ и другие. Каждая из них должна быть запущена из-под ограниченного пользователя, не имеющего доступа ни к каким каталогам, кроме тех, что явно нужны самой программе. В принципе, можно завести одного ограниченного пользователя на всех, обозвав его к примеру "sandbox" (то есть, песочница), однако в этом случае червь, пробравшийся через IE, сможет разрушить почтовую базу, накопленную за многие годы, что будет обидно. Поэтому лучше всего дать каждой программе по пользователю (конечно, это увеличивает потребности системы в памяти, но не столь радикально).
Итак, создан ограниченный пользователь "sandbox", в свойствах "безопасности" каждого каталогов (или всех дисков целиков) "sandbox" добавлен и доступ ему запрещен (политика запрета имеет приоритет над политикой разрешений, поэтому удалять "всех" совершенно необязательно). По завершению этой нехитрой операции, у sandbox'а останутся только те каталоги, которые ему нужны (как правило, это каталоги самой программы, причем без права записи в исполняемые файлы).
Попробуем запустить в песочнице ну... например, FireFox. Создаем ярлык с firefox.exe (если только это не сделал инсталлятор), щелкаем по нему правой клавишей, идем в "свойства" и там взводим галочку "запускать от имени другого пользователя". Говорим "ОК" и запускаем. Появляется грозное диалоговое окно, требующее ввода имени и пароля. Вводим. И... ни хрена Горящий Лис не запускается! Между прочим, в Linux/BSD подобная операция протекает без каких бы то ни было проблем. А здесь нужен бубен или более конкретно - файловый монитор Марка Руссиновича, показывающий на каких именно файловых операциях программа обламывается (вот так, значит, разработчики относятся к сообщениям об ошибках). Качаем файловый монитор: http://www.sysinternals.com/Utilities/Filemon.html (он, кстати, занимает меньше двухсот килобайт и распространяется совершенно бесплатно). Запускаем из-под администратора (создаем ярлык и взводим уже известную нам галочку "запускать от..."), запускаем! В данном случае файловый монитор запускается (потому что запрограммирован правильно) и мы быстрым спортивным шагом идем в Options -> Filter/Highlight или нажимаем
Рисунок 6. Файловый монитор, показывает на чем обламывается запуск Горящего Лиса.
Да... задача. Пробуем утилиту командной строки runas, запустив ее так: "runas /user:sandbox firefox.exe" (при этом firefox.exe должен быть в текущей директории). Нас деловито спрашивают пароль и... Ни хрена! Теперь, Горящий Лис лезет в Document-n-Setting\Default User, куда ему доступа также нет! В чем же дело?! В чем причина?! А в том, что для корректной работы большинства программ необходимо загрузить еще и профиль пользователя, от имени которого мы их запускаем, поэтому правильный вариант выглядит так: "runas /profile /user:sandbox firefox.exe". Теперь запуск проходит без проблем!А вот Опера хранит кэш не в профиле пользователя, а непосредственно в своем каталоге (впрочем, это зависит от ее настроек), поэтому sandbox'у необходимо присвоить права на запись в "program files\opera".
Остальные программы "распутываются" аналогичным образом. Если не помогает файловый монитор, качаем монитор реестра (http://www.sysinternals.com/Utilities/Regmon.html) и смотрим, в каких ветвях нуждается программа. Маленький подводный камень - перенаправить ввод с клавиатуры на файл, увы, не удастся и пароль придется каждый раз вводить вручную, что напрягает. Впрочем, программисты запросто напишут программу лишенную этих недостатков. Нам же главное - создать кучу пользователей, распределив правда доступа так, чтобы зловредные программы не имели никаких шансов ни для размножения, ни для шпионской деятельности.
Комментариев нет:
Отправить комментарий