СОФТ-ФОРУМ: Система безопасности в Windows семейства NT (updated 6.9.2008) - СОФТ-ФОРУМ

Перейти к содержимому

Страница 1 из 1
  • Вы не можете создать новую тему
  • Тема закрыта

Система безопасности в Windows семейства NT (updated 6.9.2008)

#1 Пользователь офлайн   Дед с бокорезами 

  • Дед форума
  • PipPipPipPipPipPipPipPip
  • Группа: VIP
  • Сообщений: 1 078
  • Регистрация: 20 Март 06

  Отправлено 28 Октябрь 2006 - 00:46

Базовая концепция системы безопасности ОС Windows семейства NT

Современные компьютерные технологии кроме полезности, удобства и прочих преимуществ имеют так же и опасность в виде вирусов, троянов, шпионов, сетевых атак, кривых рук пользлователей и т.д. Существуют различные решения для устранения даных проблем. Это-установка антивирусов, антиспаев, фаерволов, чистилок реестра и прочих программ по обслуживанию системы. Конечно же самое безопасное-отключить интернетовский кабель, CD и флоппи приводы и развлекаться в одиночку. Без набора вышеупомянтутых программ никак не обойтись-эта истина известна всем. Но ни один антивирус с антиспаем и фаерволом не даст вам 100% гарантии защиты и надежности, если не применять систему безопасности, которая основана на технологии NT. Как правило сервера оснащаются всевозможными системами защиты, но и рабочие станции не хуже и тоже имеют право быть надежными.

Суть системы безопасности заключается в следующем:
  • разграниечение праав пользователей;
  • установка только необходимого и доказанного ПО;
  • настройка параметров безопасности.
Перед установкой ОС-операционной системы (за ОС возьмем Windows XP Pro) необходимо четко спланировать стратегию установки системы:
  • опеределение задач, которые будут выполняться на системе;
  • разбиение жестких дисков на разделы;
  • составления списка программ, которые будут устанавливаться в системе. Вы должны будете сами себе доказать необходимость установки той или иной программы, т.к. программы могут в себе таить опасность и излишний перебор программ лишь подорвет стабильность системы в целом;
  • Какие политики безопасности будем применять.
Начнем с первого пункта-разбиение жестких дисков на разделы или использование индивидуальных жетских дисков для каждого раздела. Нам потребуется:
1)системный раздел размером 12-20ГБ (не более)
2)пользовательский раздел для хранения личных документов и прочих временных папок.
3)файловый архив располагаете как угодно

Поцесс установки вам известен, тут останавливаться не будем, за исключением нескольких моментов:
1)Все разделы надо отформатировать в систему NTFS или переконвертировать командой
convert метка тома: /fs:NTFS /x
2)При установке сетевой кабель/модем должны быть отключены.
3)При установке системы выбираем пароль администратора посложнее, чтобы его было труднее подобрать путем прямого перебора.

Когда установка завершена мы видим наш десктоп и первый вход в систему происходит под именем Administrator. Первым делом делаем следующие шаги:

Обновление системы

1)Включаем встроенный брандмауэр и на сайте http://windowupdate.microsoft.com
получаем все необходимые обновления для системы, после чего придется перезагрузить систему;

Создаем и администрируем пользователей

2)Учим систему различать пользователей, чтобы она понимала кто и зачем к ней обращается и какие права доступа у каждого пользователя:
Start -> Run... -> compmgmt.msc запускаем консоль управления компьютером Computer Management и в ней ищем раздел Local Users And Groups, раскрываем его и открываем раздел Users. В этом разделе в свободном месте нажимаем правой кнопкой и выбираем New User....
Здесь мы создаем ровно столько пользователей, сколько людей будет работать на ней. Имена задаем произвольно, главное, чтобы они были интуитивно понятны. И для себя создаем отдельный аккаунт, т.к. под администратором вы, как правило, работать не будете. Когда наши пользователи готовы, то можно на всякий случай проверить принадлежность пользователей к группе Users, а не к группе Administrators. Для этого двойным щелчком на каждом созданном пользователе вызываем свойства пользователя и переходимна закладку Member Of и вы должны увидеть примерно следующее:
Изображение
В данном случае я вызвал проверку членства в группах для пользователя Test.
Везде должна быть только группа Users все остальные группы удаляем кнопкой Remove.

Вы можете задать вопрос, а почему же группа Users? Я же владелец моей системы и хочу полностью владеть своей системой. Да, это желание вполне оправдланно собственными амбициями, но никак не оправдано действительностью. Увы, но хоть вы и владелец собственной системы, но вы можете отвечать лишь за то, что запускается в системе только с вашего ведома. А как же быть с процессами, что запускаются в системе без вашего ведома? Вы не можете это контроллировать самостоятельно, поэтому возложим эту хадачу на систему безопасности NT. Скажу откровенно, что простым ограничением прав пользвователя вы делаете бесполезными порядка 98-99% всех вирусов, троянов и прочего мусора. Я не буду приводить конкретные факты действия вирусов, а просто скажу, что большинство вирусов наносят вред системным файлам (подмена, изменение, запись новых и т.д.). А права Users исключают это автоматически за счет того, что группе Users запрещено:
  • запись в корень системного диска;
  • запись в папку и подпапки Program Files;
  • запись в папку и подпапки Windows.
А если мы не можем сделать запись в папку Windows или Program Files, то мы не можем менять системные файлы. Но вирусы запускаются под правами того пользователя, который их запустил и при включении пользователя в группу Users вирусы будут иметь те же права, что и пользователь и просто не будут иметь прав на изменение системных и програмных файлов и их деятельность просто обломится по всем статьям и не сможет чисто физически нанести сколько либо реального ущерба Вам. Необходимо понять этот момент и вы тут же поймете всю прелесть ограниченных прав. А теперь продолжим.

Можно для разнообразия встроенный аккаунт администратора переименовать в какой-нибудь другой (нажимаем правой кнопкой на аккаунт Administrator и выбираем Rename). На первом рисунке встроенный админский аккаунт переименован в #Root. Когда аккаунт админа переименован создаем еще один аккаунт с именем Administrator, задаем ему стойкий пароль, и выбираем свойства аккаунта. В закладке Member Of удаляем User и добавляем гостевую группу Guests,
Изображение Изображение

далее не закрывая окна свойств на закладке General выставляем чек-бокс напротив Account is disabled. Этим самым мы создадим головоломку для хакеров, которые будут пробовать взломать аккаунт администратора.

Здесь мы показали системе, что у нас есть один администраторский аккаунт и есть простые пользовательские аккаунты, у которых права доступа ограниченны и они могут не все делать на системе. Если вы думаете, что группа Users ничего не может делать в системе, то могу вас заверить, что это не так. Группа Users не может делать изменения на уровне системы, зато на уровне пользователя-всё что угодно. Желательно каждому аккаунту присвоить стойкий пароль, в котором сочетаются как минимум буквы разных регистров и цифрами (желательно). Хотя мы потом применим политику, предотвращающую взлом аккаунта путем перебора паролей, но стойкий пароль не будет лишним.

Настройка разрешений файловой системы NTFS

3)На разделе D: (подразумевается, что система находится на диске C: ) создаем 2 папки:
Games и папку Users. В первую папку мы будем устанавливать игры (как же без них B) ), а во второй папке будут храниться личные папки и файлы пользователей. И здесь мы уже начнем настраивать разрешения файловой системы NTFS. Для начала сделаем видимым закладку Security (Безопасность) в свойствах папок и файлов:
Tools -> Folder Options -> View и снимаем галочку с Use simple File Sharing. Применяем изменения и выбираем свойства папки D:\Users, переходим на закладку Security и в окне выбираем группу Users и внизу выставляем ей все галочки от Modify до Write. Галочку напротив Full Control ставить нельзя, т.к. это даст возможность пользователям изменять разрешения на чужие папки, поэтому только Modify. Можно убедиться, что у администратора есть права уровня Full Control, которые дают ему права полного управления папкой. Т.к. в этой папке у нас будут храниться личные файлы пользователей, то в папке Users создаем подпапки для каждого пользователя. Если вы одни работаете в системе, то создаем папку Administrator и еще одну папку для вас. И создаем еще одну папку для общих документов _ Shared Folder.
После этого берем свойства папки Administrator в папке d:\Users\ и переходим на закладку Security. В этой закладке мы видим всех пользовательских групп в системе и участников группы безопасности:
  • Administrators
  • Creator Owner
  • system
  • Users
В зависимости от вариаций, там могут быть и другие группы. Удаляем из этого списка группу Users и другие группы так, чтобы там осталось бы только это:
Изображение

Примечание: если при попытке удалить группу у вас появляется сообщение, что невозможно удалить, поскольку разрешение унаследовано от родительского обьекта, то нажмите кнопку Advanced и в закладке Permissions снимите верхнюю галочку после чего появится окошко, которое спросит, что делать с действующими разрешениями. В этом окошке нажмите Copy, чтобы скопировать разрешения.

Далее выбираем каждую папку пользователей и удаляем из закладки Security все группы, кроме групп Administrators, System, Creator Owner и добавляем кнопкой Add только того пользователя, которому она будет принадлежать и задайте ему права доступа уровня Full Control:

Изображение

Здесь мы видим, что к этой папке доступ будут иметь только:
  • администраторы
  • система
  • создатель-владелец
  • пользователь (в данном случае пользователь user name)
И никто больше не сможет попасть сюда, кроме вышеперечисленных пользователей/групп.

Далее, нам нужно максимально предохранить системный том от засорения временными файлами. Как известно, очень большое количество мелких и не очень временных файлов создают установочные программы, архиваторы (как WinRAR) и браузеры. Поэтому мы переместим как временные папки системы, так и кэша браузера. Если мы используем Internet Explorer, то делаем следующее:

1)запускаем браузер и в меню Tools выбираем Internet Options. Далее, в вкладке General находим кнопку Settings для раздела Temporary Internet Files. В открывшемся окошке мы можем задавать размер этого кэша и его месторасположение кнопкой Move Folder. Нажимаем на неё и в окне проводника указываем путь:

D:\Users\%username%\Temporary Internet Files

разумеется, там такой папки сейчас нету, но вы можете легко создать её из окна проводника нажатием кнопки Create new folder. В качестве параметра %username% используйте имя того пользователя для которого вы в данный момент изменяете место размещения папки. Если это пользователь User, то путь должен быть D:\Users\User\Temporary Internet Files. У меня есть пользователь Administrator и после переноса папки для него путь получился такой:

Изображение

Примечание: После проведения данной процедуры система попросит вас выйти из текущей сессии и перезайти (перелогониться) заново. Система за вас сама выйдет и предложит зайти снова.

Теперь займёмся переносом общесистемных временных папок. Их текущее местоположение и изменить его можно в свойствах системы:

Control Panel -> System

Переходим на вкладку Advanced и нажимаем кнопку Environment Variables. и Видим следующее окно:

Изображение

Здесь в верхнем окне у меня установлены новые пути. У вас они будут показывать на C:\Dociments and Settings\%username%\LocalSettings\Temp.
Нажмитке кнопку Edit и в строке пути пропишите следующее:
D:\Users\%username%\Temp
В данном случае нет необходимость прописывать имя конкретного пользователя, а воспользуйтесь переменной %username%. Система сама подставит нужное имя в переменную. После изменений вы увидите, что в итоге переменной %username% нету, а есть имя конкретного пользователя.

Теперь вренемся к забытой папке Games, чтобы и для нее настроить разрешения. Т.к. в эту папку будут устанавливать игры сами пользователи без вмешательства администратора и пользователям будет нужен доступ на сохраниния сэйвов и настроек игры, то в закладке Securtity мы даем группе Users права доступа уровня Full control и удаляем группу Guests. Вообще группу Guests можно удалить из всех этих списков, т.к. она вам не нужна для работы. На этом этапе с разрешениями пока всё. Но мы вернемся к этому вопросу чуть ниже, когда будем разбирать Аудит.

Краткое резюме: На данном этапе мы сделали следующее:
научили систему рапознавать пользователей, т.е. отличать администраторов от пользователей и пользователей между собой. В данном случае вы видите наглядное разграничение прав пользователей и работающее решение, которое можно применять на практике. Так же мы отделили систему от личных файлов пользователей и тем же самым распознованием пользователей мы запретили доступ пользователям к чужим личным папкам, когда выдали разрешение на папку user name только администратору и самому пользователю user name. Так же мы сняли нагрузку с системного раздела путем перемещения пользовательских временных папок, которые в процессе работы могут активно использовать жесткий диск и снижать скорость работы ОС, а так же, предохраняем системный раздел от лишнего и ненужного мусора.

Когда мы настроили пользователей и настроили разрешения для пользовательских папок, то можно приступить к установке прикладных программ. Замечу сразу, что этот раздел будет очень важным и серьезным и потребует от вас выдержки и терпения. Но в ответ вы получите хорошо настроенную систему с гибким управлением. Казалось бы что тут может быть сложным? А вроде ничего.. но это не так. Не все программы хотят работать под правами Users из-за чего многие просто избегают работы в этой группе. Но всё решаемо и эта проблема решается тоже.

Когда вы установили все необходимые программы, то требуется проверить их работоспособность под ограниченными учетными записями. Возможно вам повезет и все пргограммы будут корректно под ограниченными учетками. Но что делать, если какая-то программа не захочет работать корректно? Как быть? Вэтом случае нам поможет Аудит доступа к обьектам. Для примера можно взять WinISO, который при вводе серийного номера, который воодит администратор при устновке регистрирует ее. Но под правами Users программа будет незарегистрированной. Есть и другие программы, которые требуют записи в какие-то системные области диска или реестра и такие проблемы будем решать при помощи Аудита.

Когда вы наберете список программ, которые не хотят работать в пользовательском режиме приступим к самой кропотливой работе. Для начала заходим в систему под администратором и октрываем оснастку Local Security Policy
Strat –> Run.. -> secpol.msc
В ней ищем раздел Local Policy -> Audit Policy. В нем ищем элемент Audit Object Access вызываем его свойства и выставляем чек-бокс Failure. Этим самым мы включаем политику аудита на предмет неудачных попыток доступа к обьекту. Теперь надо указать, для какого обьекта будем делать аудит. Есть два места доступа ресурсов: жесткий диск и реестр. Т.к. мы работаем с ограниченными правами и нам недоступны для изменения следующие папки и ветки реестра:
  • корневой каталог системного диска
  • папка Program Files
  • папка Windows
  • папки учетных записей других пользователей
  • ветка реестра HKEY_LOCAL_MACHINE
  • ветка реестра HKEY_CLASSER_ROOT
При запуске программы иногда хотят внести изменения в вышеупомянутые папки и файлы. Но необходимо узнать, куда именно, чтобы открыть доступ лишь к требуемым файлам и папкам, а также ветвям реестра, чтобы не открывать полный доступ. Для этого необходимо включить аудит вышеупомянутых ресурсов:

Как известно в реестре ограниченным учетным записям запрещено писать в разделы HKCR и HKLM. Также нам известно, что программы при установке записывают свои значения в разделы: HKCU\Software и HKLM\Software. Мы также знаем, что в HKLM\Software у простых пользователей прав на запись ключей и подключей нету. Значит будем проводить аудит попыток записи в данный раздел простым юзерам. В групповой политике мы указали, что будем контролировать только неудачные попытки, т.к. любые попытки простому пользователю что-либо изменить в HKLM\Software окончатся неудачей.

Значит приступаем к следующему шагу:

Открываем редактор реестра под правами администратора, выставляем указатель на раздел HKLM\software нажимаем правой кнопкой и выбираем раздел Permissions (Разрешения). В открывшемся окне внизу нажимаем кнопку Advanced и переходим на закладку Auditing. В ней нажимаем кнопку Add и добавляем, либо пользователя, либо группу пользователей, которых мы хотим контролировать. Когда выберем пользователя, то будет предложено указать, какие действия мы хотим контролировать. Выставляем чек-бокс Full Control в графе Failure. Применяем все изменения (когда будете закрывать дополнительное окно назначения прав, то пройдет некоторое время, пока аудит будет применен ко всей ветви ключа). Вот с этого момента будет контролироваться каждая неудачная попытка записи/изменения ключа реестра HKLM\software.

Перелогониваемся обратно в ограниченную учетную запись. Выждав примерно 5 минут (в это время лучше ничего не делать и зафиксровать время) после чего пробуем запустить приложение. После сообщения об ошибке отменяем запуск приложения, ждем минуту-две и снова возвращаемся в аккаунт администратора. В аккаунте администратора выбираем:
start -> Run... -> eventvwr.msc
В открывшемся журнале событий раскрываем раздел Security и просматриваем все записи, которые помечены статусом как Failed. В окне события будет указано какой юзер, какое приложение и в какое место раздела HKLM\Software именно пыталось произвести изменение. Как правило будет 1 или 2 корневых подключа, которые относятся к приложению. Записываем на бумажку адреса этих ключей и открываем снова редактор реестра.

Вот пример сообщения журнала безопасности:
Event Type:	Failure Audit
Event Source:	Security
Event Category:	Object Access 
Event ID:	560
Date:		2006.10.20.
Time:		10:09:37
User:		CAMELOT\user name
Computer:	CAMELOT
Description:
Object Open:
	Object Server:	Security
	Object Type:	Key
	Object Name:	\REGISTRY\MACHINE\SOFTWARE\Fraps2
	Handle ID:	-
	Operation ID:	{0,71726323}
	Process ID:	5152
	Image File Name:	C:\Program Files\Fraps\fraps.exe
	Primary User Name:	user name
	Primary Domain:	CAMELOT
	Primary Logon ID:	(0x0,0x72708)
	Client User Name:	-
	Client Domain:	-
	Client Logon ID:	-
	Accesses:	DELETE 
			READ_CONTROL 
			WRITE_DAC 
			WRITE_OWNER 
			Query key value 
			Set key value 
			Create sub-key 
			Enumerate sub-keys 
			Notify about changes to keys 
			Create Link 
			
	Privileges:	-
	Restricted Sid Count:	0
	Access Mask:	0xF003F

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


Здесь мы видим, что программа Fraps.exe обратилась к ключу реестре HKLM\Software\Fraps2 (из раздела Object Name) с записью (это видим в разделе Accesses, где фигурируют команды Write и Create).

В редакторе реестра открываем корневой раздел для программы (как правило имеет вид HKLM\Software\ProgramName, где ProgramName - название или производитель программы) и выбираем правой кнопкой мышки Permissions. В открывшемся окне настройки разрешений выбираем нужную группу пользователей, или конкретного пользователя. (если его там нету в списке, то нажимаем кнопку Add и добавляем соответствующего пользователя/группу) и выдаем ей права Full Control только для этого раздела ключа HKLM\Software. Этим самым мы позволяем выбранной группе/пользователю производить запись/изменение не во всей ветке HKLM\Software, а только к подразделу, который относится лишь к самой программе, что не вызовет угрозы для самой системы.

Когда выставлены разрешения Full Control на все подключи, которые использует приложение, то снимаем аудит, т.к. это значительно тормозит систему. Возвращаемся в HKLM\Software, выбираем Permissions -> Advanced -> Auditing. Там кнопкой Remove удаляем пользователя/группу, которую проверяли и там ничего остаться не должно. Перелогонившись в ограниченную учетку можем запускать приложение и если вы дали разрешение на запись/изменение всех ключей реестра, которые использует приложение, то программа должна пойти без всяких проблем.

Однако, есть ситуации, когда игры/приложения используют системные библиотеки и требуют либо записи/изменений в системных фалах/папках. Как же быть? Ответ на этот вопрос тот же – Аудит. Вновь логонимся под учетной записью администратора и создаем аудит доступа к системным файлам (с реестром мы провели аудит и решили проблему записей ключей). Можно просто вызвать свойства системного раздела, перейти на закладку Security нажать на кнопку Advanced и перейти на заклдаку Auditing. Та же самая аналогия, что и в случае с реестром – фиксируем все неудачные попытки записизименения файлов в системных папках. В закладке Auditing добавляем того же пользователя (в нашем случае User Name)

Изображение

Как правило большинство проблем возникают в том, что невозможно что-то сделать с системныи областями (будь то реестр или физические файлы). И аудит нам помогает установить конкретно, что именно мы не можем. Когда мы создали аудит по файлам и папкам, то можем перелогиниться в ограниченную учетную запись с правами Users. Снова фиксируем системное время. Выжидаем минуты 2 (чтобы не возникло ошибок при анализе журнала ошибок) и запусакаем требуемую программу. Когда мы получаем сообщение об ошибке запуска (или любую другую ошибку, которая не дает нам запустить программу) мы выжидаеп еще минуту-две и перелогониваемся под учетной записью администратора и открываем журнал ошибок:

Start -> Run... -> Eventvwr.msc

Переходим в раздел Security и анализируем все ошибки в категории Failed которые произошли в предварительно зафиксированное время. Анализировать следует ошибки, в которых требуемая нам программа пыталась совершить запись/изменение какого-то файла в запрещенной папке (системной папке). В некоторых случаях проблема кроется лишь в разрешениях реестра, а некоторые – в разрешениях файловой системы. Если вы там увидели в качестве обращающегося ресурса требуемую программу, которая обратилась к некому системному файлу, то стоит открыть разрешение на изменения того файла, к которому программа обратилась с задачей запись/изменение и которе фигурирует в разделе Object Name. Т.е. в этой категории мы вчитываем, что наша программа обратилась к этому файлу (смотрим в раздел Object Name) и убеждаемся, что программа хотела произвести запись/изменение файла – это вычитывыаем в разделе Accesses в отчете об ошибке журнала безопасности. Теперь мы знаем, что за файл требуется программе для перезаписи и открываем ему разрешение уровня Modify. Как это делается уже было описано выше (выбираем свойства файла или папки, переходим на закладку Security, выбираем требуемую группу пользователей (в нашем случяае группе Users) и задаём ей разрешение на файл или родительскую (корневую) папку файла (если файлов несколько) уровня Modify. То же самое делаем для всех всех файлов, которые фигурируют в журнале событий раздела Security помеченные статусом Failed. Когда эта процедура завершена можем снова логониться в ограниченную учетную запись (в нашем случае член группы Users) и проверять потворный запуск программы под ограниченной учетной записи. Если вы дали соответствующие разрешения на реестр и/или файлы/папки, то программа должна запуститься в нормальном режиме, т.к. мы путём разрешений реестра и файловой системы устранили все моменты, которые мешали программе нормально стартовать (запись в файл или системную часть реестра). Если этого не произошло, то произведите аудит еще раз, поскольку больше нигде проблема заключаться нигде не может, за исключением изначальной неработоспособности рограммы, что происходит крайне редко. Если у вас получилось запустить программу из под ограниченной учетной записи, то необходимо удалить аудит системного диска. Удаление происходит в том же месте, где мы его и задавали. В данном случае логонимся под административной учетной записью Администратора, выбираем свойства системного диска и переходим на закладку Security, нажимаем кнопку Advanced, переходим на закладку Auditing и там удаляем нашего пользователя или группу, которую мы контролировали. После чего заходим в
Start -> Run... -> secpol.msc
Локальную политику безопасности Local Policy -> Audit Policy. В нем ищем элемент Audit Object Access и снимаем галочку с чек-бокса Failure, чем мы отменяем аудит. Нам он на данном этапе не потребуется больше. И, также снимаем аудит с свойств разрешений файловой системы и реестра, чтобы убрать абсолютно все хвосты и разгрузить систему.

Здесь я хочу заострить ваше внимание на том, что аудит необходимо включать в:
  • Локальной политике безопасности;
  • том месте, что мы собираемся отслеживать (файловую систему или реестр).
Отслеживание работы групповых политик вам не понадобится в условиях этой статьи, поскольку вы редко применяете групповые политики. А так же не забывайте отключать аудит, после проверок, поскольку аудит потр*цензура*ет значительно количество системных ресурсов.

Краткое резюме: На данном этом этапе мы провели крайне кропотливую работу по аудиту доступа к системным ключам реестра и системных файлов и папок. Да, этот процесс относительно долгий и очень муторный (не каждый выдержит анализ системы аудитом), но с его помощью мы решаем следующие задачи:
  • делаем возможным запуск программ из под ограниченной учетной записи (которая входит в групу Users), которые обычно не хотят запускаться из ограниченного режима;
  • узнаем о возможностях аудита;
  • узнаем много нового о технологии NT, которая поможет нам в будущем;
  • самосовершенствуемся в познаниях ОС Windows семейства WindowsNT.
Очень вероятно, что с первого раза у вас может что-то не получиться. У меня самого с первого раза на всё получалось. Поэтому тут требуется практика. Необходимо прочитать вышеизложенный материал, повященный аудиту, разобрать и понять его в теории и применить на практике. Когда вы сможете решать проблему незапуска какой-либо программы при помощи аудита, то вы сможете решить проблему и для других программ. И только тогда, когда вы проработаете этот материал, то перед вами откроются неограниченные возможности анализа и изучения системы безопасности NT. Вы сможете отслеживать не только какие-то запреты на уровне файловой системы и реестра, как было описано в этой статье, но и сможете отслеживать работу групповых политик и локальных политик безопасности при помощи тгго же аудита. К слову сказать, при сдаче сертификационных экзаменов Microsoft по программамам MCP, MCSA, MCSE, MCT экзаминаторы достаточно большое внимание уделяют именно аудиту. Естественно, что вы не можете знать всего, но при помощи аудита вы сможете решить бОльшую часть своих проблем.

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

Применение политик безопасности будет намного проще аудита. Мы не будем особо мудрить, просто включим несколько важных политик безопасности, которые помогут нам избежать вредоносное действие атак хакров или прогармных роботов извне и локально. Тут мы затронем политиу паролей. Известно, что у многих открыт доступ к системе по различным протоколам (в том числе и FTP, RDP и другие) с использованием логина и пароля учетной записи пользователя. Вроде бы ничего страшного, но что делать если какой-то медвежный бот или юзер запустит программу, которая будет перебирать все пароли, пока не получит доступ к вашей системе? Но мы не дадимся этим хакерам и ботам так просто. Мы вообще заставим их, как говорит нынче молодежь, „бриться бритвой Харьков". Для этого, как я упомянул выше, мы создаем достаточно стойкие пароли для учетных записей. Я настоятельно рекомендую использовать слоджные пароли, которые включают в себя буквы обоих регистров и цифровые знаки. Не обязательно придумывать сверзсложный пароль, просто использовать понятные только вам пароли с такими качествами. И, также, надо будет бороться с тем, что пользователь решит сменить пароль, игнорировав требования по сложности пароля. Все эти задачи мы решим букввально в 2 минуты, если не быстрее. Поехали!

Открываем консоль локальной полтиитки безопасности:
Start -> Run... -> secpol.msc

В открывшейся политике переходим в:
Security Settings -> Password Policy
В правом окне мы видим список политик паролей (у меня они уже настроены, но по умолчанию они в статусе Not Configured):

Изображение

Здесь я поясню значение каждой политики:
  • Enforce password historyонтролирует неповторяемость пролей в течении некоторого количества запомненных паролей. Т.е. когда система требует смены пароля, чтобы пользователь не смог установить свой предыдущий пароль (не продлил старый пароль или использовал тот, что уже использовался). В моем случае установленно значение 10, что означает, что система хранит в памяти 10 предыдущих паролей пользователя и при смене пароля не даст ему установить пароль, который был в числе 10 предыдущих и заставит пользователя придумать новый уникальный пароль.
  • Maximum password age – эта политика устанавливает время жизни пароля, после которого она потребует смены пароля на новый Я установил значение в 360 дней. Это значит, что каждый год система будет требовать смену паролей и предыдущей политикой не позволит задать пароль, который уже использовался. Я не вижу необходимости делать это чаще, чем раз в год.
  • Minimum password age – задает минимальное время жизни пароля. Обычно пользователю дается возможность сменить пароль и он может обойти первую политику, изменив 10 раз пароль (чем он удалит пароль из памяти политики, где стоит память на 10 использованных паролей), который может быть кому-то известен. Этой политикой мы запрещаем пользлователю менять свой пароль чаще, чем каждые 10 дней (в моем случае).
  • Minimum password length – задает минимальную длину пароля. Я выбрал число 7. Это значит, что при замене пароля система не даст изменить новый пароль, который будет короче, чем 7 знаков. Тут вопросов возникнуть не должно.
  • Password must meet comlexity requirements – задает уровень сложности для пароля. Эта политика может иметь значение или Enabled или Disabled. Если политика включена, то система не даст задать пароль, если он не отвечает следующим требованиям: наличие букв обоих регистров, цифр и спец.символов.
  • Store passwords using reversible encription – эта политика так же имеет состояние или Enabled или Disabled. Если она включена, то пароля в системе хранятся в незашифрованном виде с возможностью обратимого шифрования и дается возможность восстановления пароля.
    Совет: Настоятельно рекомендую отключать эту политику и держать пароли без возможности обратимого шифрования и его восстановления, поскольку это легкая добыча для взломщиков. Мы ее отключаем и выставляем в положение Disabled.
В этом разделе мы задали правила для создания и метода хранения паролей для пользователей. Этот раздел достаточно важен, поскольку эти политики помогут нам быть уверенными, что пароли достаточно сложные и их подобрать будет нелегко.

Далее спускаемся на подраздел ниже, а именно:

Security Settings -> Account Lockout Policy

Здесь мы видим лишь 3, но очень важные политики:

Изображение

Поясняю каждую политику:
  • Account lockout duration – эта политика показывает время, на которое блокируется учетная запись пользователя после нескольких попыток ввода неправильного пароля (количество попыток определяется следующей политикой), что равносильно перебору пароля. Если учетная запись будет заблокирована, то даже при вводе правильного пароля пользователь или злоумышленник не сможет зайти в систему, поскольку учетная запись будет блокирована на некоторое время. В моем случае учетная запись блокируется на 30 минут, после чего можно будет еще раз попробовать залогониться.
  • Account lockout threshold – эта политика устанавливает количество попыток подряд для ввода неправильного пароля, прежде чем учетная запись пользователя будет блокирована. Я установил значение 10. Это значит, что после 10 раз подряд ввода неправильного пароля, учетная запись блокируется на время, указанное первой политикой в этом разделе.
  • Reset account lockout counter after – эта политика задает время хранения количества ввода неправильных паролей. Я выставил время в 30 минут также, как и первую политику. Это значит, что если вы в течении 30 минут 9 раз набрали неправильно пароль и сделали паузу в 30 минут (в данном случае), то через эти 30 минут счетчик количества неправильно набранных паролей сбрасывается и вы сможете сделать еще 9 попыток ввода неправильного пароля. Т.е. по 9 попыток каждые 30 минут. Однако взломщику вряд ли будет известно допустимое количество неправильных паролей, т.к. можно задать число не 10, а, скажем, 5, то после 5 неудачных попыток ввода пароля учетная запись блокируется.
В данной политике мы включаем блокировку учетной записи пользователя от перебора пароля. Как правило боты, или взломщики будут автоматически перебирать пароли, из-за чего успеет сработать блокировка и учетная запись заблокируется и взломщик не сможет войти в вашу систему.

Внимание!!! данные политики имеют один недостаток. Они не защищают от перебора встроенного администраторского пароля, а только пользователей любых других групп, кроме администраторов. Это очень неприятный момент, что пароль встроенного администратора никак не защищается от перебора, но Microsoft смогла исправить ситуацию путем применения программы passprop.exe, которая входит в состав Microsoft Windows 2000 Resource Kit и Microsoft Windows XP Resource Kit. Чтобы вам не искать эту программу, я выкладываю её здась, в пост. Синтаксис программы таков:
passprop.exe /complex /adminlockout
Прикрепленный файл  passprop.zip (2,83К)
Количество загрузок:: 91
Итоговое резюме: Вот, вроде и всё, что я хотел рассказать в данной статье. В этой статье я старался изложить концепцию системы безопасности на базе технологии NT без использования сторонних продуктов для защиты системы. Если подвести итог статье, то можно выделить примерно следующую концепцию системы безопасности:
  • учим систему различать пользователей по имени и по принадлежности к группам. Т.е. система понимает, что Коля это Коля, а не Вася, или Петя и понимает, что он принадлежит группе Users и обладает соответствующими правами и админ есть админ и обладает другим набором прав.
  • настраиваем разрешения файловой системы для разграничения пользовательских файлов, чтобы система понимала, что к папке Васи доступ имеет только Вася и не Юре и не Саше и никому другому доступ к ней иметь нельзя.
  • используем очень мощный инструмент Аудит при помощи которого можем производить анализ обращений программ к системным ресурсам и попыток изменения данных в системных областях и устранения проблемы незапуска программ из под ограниченных прав.
  • использовали политики защиты паролей от взлома и прямого перебора.

Если применить правильно данный материал, то можно создать достаточно устойчивую систему, которая не будет бояться ни вирусов, ни троянов ни атак извне и отказаться от использования антивируса. Этим самым мы высвобождаем ресурсы системы для выполнения других задач, а не для дармовой кормёжки анитвируса. Мы защищаемся лишь разрешениями файловой системы, правами пользователей и интегрированным брандмауэром ICF, который вполне решает все проблемы пользователей. Мы не затронули еще очень много, как более подробное изучение групповых политик и политик IPSec. Но это уже тема для отдельного разговора.

З.ы. Данная статья не претендует на какое-либо литературное качество, но я старался как можно ясней донести информацию до чиателя. Я не закрываю тему и оставляю открытой для обсуждения и вопросов. Только убедительная просьба для пользователей – оставляйте сообщения только по существу и не флудить и не оффтопить и если у вас возникли затрудения, то достаточно четко описывайте что вы сделали и в каком месте возникла пролблема.. Если не можете сформулировать вопрос, то пишите в личку.

Сообщение отредактировал Дед с бокорезами: 23 Февраль 2010 - 22:28

Microsoft MVP: PowerShell
мой блог: http://www.sysadmins.lv
0

#2 Пользователь офлайн   Дед с бокорезами 

  • Дед форума
  • PipPipPipPipPipPipPipPip
  • Группа: VIP
  • Сообщений: 1 078
  • Регистрация: 20 Март 06

Отправлено 18 Октябрь 2007 - 13:55

Software Restriction Policies - политики ограниченного использования программ.

В предыдущей статье мы с вами познакомились с базовой системой защиты локального компьютера от поражения вредоносным ПО (вирусы и трояны) методом ограничения прав пользователя и защитой от несанкционированной записи в системные папки диска и системные области реестра. Это гарантирует, что если на этой системе запустился вирус, то он не сможет скопировать свое тело в реестр или в системную папку и заразить необходимые системные файлы, чтобы вирус смог бы размножаться спокойно. Как уже отмечалось выше – это базовая система защиты и в ней сохраняется запуск вредоносного ПО, которое не способно повредить системе, но может повредить личным файлам пользователя. Количество вирусов, которые способны жить автономно (т.е. не нужно копировать свое тело в системные области, а может функционировать по принципу – не съем, так понадкусываю, попорчу пользовательские файлы) очень невелико, т.к. разрушения от их воздействия минимальны. Но если мы боремся за более высокую безопасность, то мы должны ограничить возможность попадания вредоносного ПО на локальный компьютер. Для этой цели мы будем использовать политику ограниченного использования программ или Software Restriction Policies – SRP. Этот инструмент также является встроенным в Windows и позволяет выполнять очень интересные вещи.
SRP является политикой. А все политики основываются на определенных правилах. Когда запускается некоторый файл, то он перед запуском проходит через список правил и на основании результата прохода правил задается действие – разрешить запуск, или запретить. SRP в качестве правил использует следующие параметры файла (которые мы будем использоать по отдельности или всё вместе):
  • Путь к файлу
  • Расширение файла
  • Хэш файла
  • Имя или часть имени файла (маска)
И для любых файлов может быть выбрано одно из действий (2 сразу не получится :) ):
  • Разрешить запуск
  • Запретить запуск.
Так же политика SRP обладает и правилом по умолчанию. Т.е. выбор строго определенного действия по отношению к файлам, параметры которых не подпадают ни под одно правило. Прежде чем приступить к реализации политики SRP и правил займется немного изучением системы, а точнее изучением путей попадания вредоносного ПО на компьютер.

1)Самый частый способ заражения – через интернет. Вредоносное ПО либо загружается вместе с веб-страницей в браузере или при открытии какого-то файла в браузере. Как известно любой браузер перед отображением страницы на экране скачивает саму страницу в собственный кэш, после чего браузер начинает отображение странцы. Когда страница скачана, то по некоторому внешнему воздействию (какое-то действие на странице. Например, какой-то объект на странице получает фокус, над ним проводят мышкой или любое другое событие) происходит запуск вредоносного .exe файла. Та же ситуация происходит, когда по ссылке предлагается сохранить или запустить файл. Если выбираем Открыть, то файл сначала скачивается в папку временных файлов браузера, после чего происходит её запуск.

2)Следующий путь по вероятности заражения – открытие архива WinRAR. Прежде чем показать содержимое архива, WinRAR незаметно от вас распаковывает заголовки архива в отдельную временную папку и только после этого показывает вам содержимое архива. Когда вы запускаете один файл из архива, то WinRAR распаковывает весь архив во временнюу папку (для обеспечения работоспособности связанных ссылок) и после этого запускает выбранный файл. Опять же вредоносное ПО может использовать внешнее событие, чтобы инициировать свой запуск.

3)Самый простой вариант – пользователь сам запускает зараженный файл и вызволяет вирус наружу. К этому относятся и файлы, которые запускаются из вложений в почте в почтовых клиентах.

4)Редко, но иногда вирусы приносят с CD-дисками. Там всё очень просто, на диск записывается вирус и путь к нему в секции AutoRun в файле autorun.inf. т.е. тут хватает того, чтобы диск поместить в привод и всё, больше ничего делать не надо. Сюда же припишу и USB-флешки на которых можно переносить вредоносное ПО.
Редко когда дома запущены специфические службы как FTP при помощи которой на компьютер можно закачать инфицированный файл и инициировать его запуск.
Сейчас мы рассмотрели наиболее частые пути попадания вредоносного ПО на наш любимый компьютер. Из логики следует, что необходимо защищать эти пути от запуска потенциально опасного файла. Чем мы сейчас и займёмся.
Итак, для реализации политики Software Restriction Policies нам необходимо запустить оснастку Local Security Policy: Start -> Run... -> secpol.msc

Изображение

Здесь в левой секции мы видим список доступных локальных политик безопасности, где и находится Software Resstriction Policies. А в правом окне видим предупреждение, что ещё ни одна политика не определена. Для того, чтобы определить политику, надо на названии политики нажать правой кнопкой мыши и выбрать New Software Restriction Policies. После этого правая часть окна станет иметь следующий вид:

Изображение

В правой секции у нас появятся вот такие элементы. Мы поработаем немного с каждым из них, но в основном мы будем работать с секцией Additional Rules. Итак, разьерём каждый элемент:

Security Levels – задаёт базовую политику стандарта Запрещено всё, кроме... или Разрешено всё, кроме... .Первый вариант относится к жёстким политикам, который запретит запуск любых .exe файлов, кроме тех, которые будут явно разрешены. Второй вариант относится к мягким политикам, где будет разрешён запуск любых приложений, кроме тех, которые мы явно укажем. По умолчанию (галочкой помечено Unrestricted) будет использована мягкая политика, с которой мы и будем работать.

Additional Rules – задаёт правила исключений по отношению к основной политике (если активирована жёсткая политика, то тут будут указаны правила для разрешённых путей и если мягкая политика, то наоборот). Это окно будет для нас основным в работе.

Enforcement – задаёт степень воздействия на дополнительные файлы программ и пользователей. По умолчанию запрет/разрешение (в нашем случае запрет) будет распространяться только на выбранные .exe файлы и любая разрешённая программа сможет использовать любые связанные с ней файлы (как .dll). Если выбрать All Software Files, то нам необходимо будет отыскивать библиотеки приложений и включать пути к ним или сами библиотеки в правила исключений. Здесь изменять мы ничего не будем. Ниже задаётся степень воздействия на пользователей. По умолчанию политика Software Restriction Policies (далее будем использовать сокращение SRP) действует на всех пользователей, включая администраторов. Если переставить переключатель вниз, то политика будет распространяться только на пользователей, которые не являются администраторами. Т.к. главный путь заражения происходит через учётную запись администратора, то здесь мы тоже ничего менять не будем и политика будет действовать на всех без исключения пользователей.

Designated File Types – задаёт список расширений файлов, которые помечаются как установочные, т.е. файлы с этими расширениями являются запускаемыми и они могут нести потенциальный риск заражения и будут проверяться данной политикой. Здесь можно, по желанию, добавить свои расширения, которые будут помечаться как запускаемые.

Trusted Publshers – задаёт ответсвенного за назначение доверенных поставщиков программ. По умолчанию выставлен End User, т.е. конечный пользователь. Доверенные поставщики относятся к исполняемым файлам и к элементам ActiveX. Когда вы инсталлируете некоторую программу система Windows показывает кто поставщик данной программы (по цифровой подписи) и если этот поставщик доверенный, то предлагается спокойно установить программу. Если поставщик не входит в группу доверенных или вообще не указан, то появится предупреждение, что данная программа может быть потенциально опасной и предложит отказаться от установки или продолжить (на свой страх и риск). Цифровая подпись несёт в себе и ещё одну функцию – неизменность программы. Если программа подписана цифровой подписью, то это значит, что с момента её компиляции, до запуска она ни разу и ни кем не была модифицирована (например, при заражении подписанного файла вирусом, её цифровая подпись слетает, т.к.цифровая подпись не будет соответствовать хэш-коду программы). Здесь мы так же ничего изменять не будем и оставим настройки по умолчанию.

Краткое резюме: сейчас мы рассмотрели порядок запуска консоли Local Security Policy и активацию в ней Software Rsstriction Policies. Так же рассмотрели все компоненты, которые можно отдельно настраивать для конкретных ситуаций, которые делают политику более гибкой.

Когда мы раскроем нужное нам окно – Additional Rules, мы увидим, что по умолчанию уже определены 4 правила пути (тот факт, что правило определено для пути видно во втором столбце, где написано Path). К этим путям относятся папки Windows, Windows\System32 (только .exe файлы) и папка Program Files с подпапками.

Изображение

При любой базовой политике, даже жёсткой, эти пути будут относиться как доверенные к запуску программ, т.к. они в любом случае необходимы для функционирования системы. Это видно по колонке Security Level, где указано Unrestricted, что значит, "не запрещено". В последней колонке уазывается дата и время последней модификации каждого исключения.
Итак, мы договорились, что наиболее частый метод заражения – через временную папку браузера (его кэш). Поэтому, мы сейчас создадим правило, которое будет запрещать запуск .exe файлов из папки кэша браузера. Здесь я буду показывать на примере браузера Internet Explorer. Для других браузеров, папки кэша находятся в других папках и вместо тех, что буду указывать я, вы можете указать путь к папкам кэша других браузеров. Если вы не знаете, как найти папку кэша Internet Explorer, то вы должны запустить браузер и в меню Tools выбрать Internet Options (или в панели управления) и на вкладке General есть секция Temporary Internet Files и кнопка Settings.

Изображение

В моём примере, папка находится по адресу:
D:\Users\Administrator\Temporary Internet Files

Примечание: согласно предыдущей статье, для предотвращения захламления я рекомендую переносить все временные папки пользователя и его личные папки (как My Documents) с системного диска на другой, например, D диск, как это сделано у меня. Это предотвращает постепенное торможение работы системы, которое отмечают многие пользователи со временем. Таким образом (и если устанавливать только необходимое ПО) даже через год использования системы скорость работы по сравнению с изначальной установкой системы будет приблизительно одинаковой и на глаз торможение не будет даже заметно.

Итак, мы создадим первое правило, для этого пути. Для этого в консоли в свободном месте нажимаем правой кнопкой мыши и в контекстном меню выбираем New Path Rule. Появится следующее окно, которое мы заполним таким образом:

Изображение

В поле Path указываем путь к кэшу браузера, в поле Security Level задаём действие на это правило – Disallowed (Запрещено). В поле Description указываем описание правила и нажимаем Ok. Теперь из этой папки будет запрещено запускать все типы файлы, расширения которых были указаны в Designated File Types. Когда мы скачиваем непосредственно с браузера некий .exe файл, вам сначала предлагается либо открыть файл, либо сохранить. В любом случае файл сначала будет скачиваться в папку:

C:\WINDOWS\Downloaded Program Files

А после этого, в зависимости от выбранного действия оно будет запущенно из этой папки сразу по окончанию закачки, или будет перемещён в папку, в которую вы указали сохранить файл. Чтобы уберечься от случайного запуска (когда в диалоговом окне запроса вы выбираете Open, а не Save) мы включим этот путь тоже в политику. Значит, снова в свободном месте правой кнопкой и выбираем New Path Rule. В пути указываем:
C:\WINDOWS\Downloaded Program Files

Примечание: вы можете обходить целый список расширений, которые подвергаются проверке, дописав в конце пути *.exe. Это запретит запуск только .exe файлов в этой папке, но, при этом прекратится наследование политики на подпапки. Если не указывать явно разрешение, то политика будет действовать как на указанную папку, так и на все её подпапки. Но, если указать явное расширение, то для каждой подпапки придется создавать отдельные правила. Если для подпапок создадите правила без явного указания расширения, то правило будет применяться для всех подпапок этой подпапки. А так же, если вы хотите запретить запуск некоторого разрешения в одной конкретной папке (а в остальных разрешить) и этого расширения нету в Designated File Types, то в конце пути добавляете своё расширение и всё. Это важно запомнить. Так же можно делать перекрещивание политики. Т.е. вы можете политикой накрывать полный список расширений, но дополнительно указать, что в таком-то месте конкретное расширение будет разрешено. Здесь важно усвоить одно правило: в результате действия двух противоречащих политик, выигрывает более узкая, т.е. которая определена более конкретно, чем, например, общий шаблон.

И в описании можем что-нибудь записать. И нажимаем Ok. Теперь у нас уже есть два правила, которые резко ограничивают браузер Internet Explorer по самовольному (через скрипт на странице) или случайно нажатый .exe файл на странице, который скачается и потом запустится. Поэтому в дальнейшем вам придется сначала сохранять .exe (здесь говорится не только о .exe, но и о всех расширениях, которые указаны в Designated File Types) в отдельном месте и потом запускать. Это заставит вас лишний раз подумать, а нужен ли вам этот файл.
Следуя нашим задачам следующий пункт у нас является WinRAR, прочие приложения основанные на нём (упакованные в SFX) и другие заархивированные установочные пакеты. В системе есть ещё две временные папки, которые находятся в каждой папке профиля пользователя. Это папки Temp и Tmp. Их нахождение можно легко определить: Start -> Control Panel -> System -> Advanced -> Environment Variables.

Изображение

В верхнем окне у меня определены эти пути как:
D:\Users\Administrator\Temp
Как уже отмечалось, все временные папки переносятся с системного тома на другой диск. В моём случае – диск D. Значит, следующий этап будет создания правила для этого пути. Правило создаём так же, как и предыдущие два правила. Теперь вы можете скопировать какой-нибудь .exe файл в эту папку и запустить его. Вы получите отлуп как здесь:

Изображение

Я скопировал в эту папку программу calc.exe (встроенный калькулятор) и получил сообщение, что запуск этого файла в этой папке запрещено политикой Software Restriction Policies. А, скажем, .xml файл откроется спокойно. Здесь уже я не смогу привести универсальное решение по управлению этой папкой, т.к. в каждом случае необходимо подходить индивидуально. В качестве решения можно нивелировать только явно задаваемыми расширениями, чтобы обойти весь список Designated File Types, а отрабатывать только явно указанные. Но, лучше (в плане безопасности) использовать полную политику и для установки какого-то приложения придется на время отключать политику. Я очень редко устанавливаю новое ПО в системе и особой проблемы в этом не вижу. Поэтому можете выбирать один из этих двух путей решения данной проблемы для установки нового ПО и которое использует эту временную папку.

С третьим потенциальным путём заражения – когда пользователь сам запускает инфицированный файл бороться очень трудно, но можно. Правда, в условиях домашнего компьютера практически невозможно. А вот для предприятий вопрос решается проще. Пользователь ограничен в правах и писать может только в папки своего профиля и рабочие папки. Так вот, запрет на запись во все системные папки устанавливается правми NTFS, которые не позволят занести инфекцию в систему, а политиками SRP накрываются служебные (рабочие) папки и вся папка с подпапками профиля пользователя. При таком решении пользователь в первом случае не может заразить систему правами NTFS, а во втором случае – всё остальное запрещает SRP. Вот так это делается пЃЉ, но в домашних условиях это будет очень неудобно и работа за такой системой превращается в настоящее испытание. Поэтому есть смысл накрывать политикой SRP только те папки, из которых вы гарантированно явно не запускаете *.exe файлы. Например папка My Documents. Вообще, пользователям рекомендую все личные .exe файлы держать в отдельном месте (допустим, папка Install, где вы будете хранить все интсаляшки). И вообще, все несистемные файлы лучше сгруппировать по их назначению в отдельные папки (например, аудио отдельно, видео отдельно, инсталлы отдельно и т.д.). Это очень удобно и поиск файлов занимает куда меньше времени. Тогда политикой можно защищать все остальные папки, кроме папки Install, к примеру.

Далее идут внешние диски CD/DVD. С ними всё гораздо тоскливей. Можно, конечно же, использовать политику и на него (т.е. предложить данные сначала скопировать в папку, на которую политика не распространяется), но проблема гарантированно возникнет, когда вы захотите установить, допустим, игру. Здесь можно подойти следующим образом. Можно отключить автозапуск при помощи групповых политик. Или можно разрешить запускать .exe файлы только с корня диска (как правило setup.exe располагается в корне диска), а зпуск второго setup.exe из подпапки запретить. Обход одного уровня папок делается указанимием вместо её названия (у дисков папки всегда разные) символа "*". Например:

Z:\*\

Если задать в пути такой формат, то политика будет распространяться только на папки второго уровня и ниже, но для корня диска правило работать не будет и вы сможете запустить *.exe.
Если говорить о флешках (USB-Stick), то с ними ситуация похожа как и с CD\DVD. Здесь можно применить те же правила, как и для CD\DVD. Т.е. разрешить только какой-то один или несколько уровней иерархии папок, а остальные контролировать политикой. А вот на предприятиях эти флешки – головная боль системного администратора. Правда, у них есть решение – отключать групповыми политиками USB Mass Storage. Т.е. запрещаются только USB-накопители. Но на прочее USB-оборудование, как принтеры, мышки, клавиатуры она не действует. Здесь я расписывать этот процесс не буду, т.к. он описан здесь:

http://support.micro...om/kb/823732/ru

Итоговое резюме: мы с вами познакомились с очень интересной и полезной политикой, которая является частью глобальной и масштабной системы безопасности операционных систем Windows семейства NT. К разочарованию некоторых, мы вынуждены ломать их общее представление о безопасности компьютеров и о методах и инструментах создания этой безопасности. Как правило у пользователей вся безопасность заканчивается антивирусом, файрволом, каким-нибудь антиспаем, или ad-aware и администраторской учётной записью ( :D ). Может быть первые две позиции в этом списке еще имеют какой-то смысл, то последнее – убивает все преимущества первых. Важно ещё раз понять, что не надо прятаться слепо от угроз антивирусом (а вы знаете как он работает вообще?). Необходимо изучать работу системы, искать возможные пути для атаки/заражения и не бороться с последствиями, а предотвращать атаку/заражение, закрыв заранее все доступные пути к этому. И к вопросу безопасности нужно подходить комплексно.

Сообщение отредактировал Дед с бокорезами: 23 Февраль 2010 - 22:13

Microsoft MVP: PowerShell
мой блог: http://www.sysadmins.lv
0

#3 Пользователь офлайн   Дед с бокорезами 

  • Дед форума
  • PipPipPipPipPipPipPipPip
  • Группа: VIP
  • Сообщений: 1 078
  • Регистрация: 20 Март 06

Отправлено 18 Октябрь 2007 - 14:10

Базовый файерволинг на базе Internet Protocol Security (IPSec).

Прежде чем мы начнем разбирать вопрос базового файрволинга, хочу оговорить некоторые моменты:
  • Данный материал расчитан на подготовленного пользователя, который знает базовые принципы работы сети и сетевых программ.
  • Данный материал не является полным в контектсе названия, а будет освещать лишь важные моменты, которые актуальны для домашнего пользователя.
Лирическое отступление. Создание интернета можно считать одинм из самых значимым творением за последние четверть века. Интернет собой очень сильно изменил нашу жизнь, сделал нас более осведомленными в происзодящем в мире, позволил очень быстро и эффективно находить нужную информацию, сделал людей ближе друг к другу. Интернет стал едва ли не единым каналом передачи данных (начиная от обмена текстовыми сообщениями в telnet до пересылки правительственной конфидециальных данных). Но вместе с тем принёс и негативные моменты – появились хакеры. Их основная задача – использование интернета в своих личных, корыстных целях (кража информации), или дестабилизация работы сервисов интернета (например, DdOS-атаки, заражение машин вирусами). Всем известно, что они представляют серьезную угрозу для владельцев компьютеров или владельцев информации. С ростом технологий интернета, технологии хакеров растут так же. Поэтому появилась необходимость в защите от хакеров. В настоящее время пользователям предлагается множество программных (антивирусы, файрволы) и аппаратных (интеллектуальное активное сетевое оборудование. Например, маршрутизаторы) решений. В данной статье мы рассмотрим один из брандмауэров (файрволов), который уже интегрирован в систему Windows 2000/XP/Vista – IPSec.
В настоящее время используется только 2 типа брандмауэров:
  • Основанный на путях к программам, которым разрешён/запрещён доступ к интернету.
  • Основанный на сетевых протоколах, адресах и портах, по которым разрешается доступ к интернету.
Разберём каждый из них определим их достоинства и недостатки.

Первый тип является наиболее распространённым среди пользователей. К ним относятся такие продукты как Outpost Firewall, Kerio Winroute Firewall (KWF), Windows Firewall, а также брандмауэры, которые встроены в антивирусные пакеты как Symantec Internet Security, Kaspersky Internet Security и т.д. В чем заключается их принцип работы: вы указываете в правилах, что такому-то приложению разрешён доступ к сети. При этом приложение может делать в сети практически всё, что захочет и может занимать любые порты, какие захочет. В этом заключается главная их проблема – они не отслеживают трафик тех приложений, которые находятся в белом списке (разрешённых). Это значит, что какое-то вредоносное ПО может посредством стандартных API (Application Programming Interface) функций (или через внутренний язык приложения) инициировать передачу данных в сеть не обладая при этом разрешением выйти в сеть. Например троянская программа может сгенерировать некотоый запрос и сформировать его. Затем посредством внутренних функций передать его браузеру. Браузер будет это видеть как будто сам пользователь на страничке сгенерировал сообщение и передаст этот запрос в сеть (например, на нестандартный порт троянского сервера). Количество таких троянских программ сравнительно невелико, но они есть и их сбрасывать со счетов нельзя. Конечно же, продвинутые брандмауэры позволяют настраивать параметры протоколов, адресов и портов для создания правил, но я, честно говоря, не видел никого, кто бы этим занимался. И их настройка требует достаточно глубоких знаний работы сети вкупе к тому, что сами конфигураторы весьма неудобны в работе. Однако в этом есть и свои плюсы. Программные фаерволы не позволят неразрешенному приложению даже отправить рядовой запрос на DNS-сервер, не говоря уже об остальном. В достаточной степени это удобно, но ввиду недостатков, которые я описал выше в ряде случаев эти брандмауэры могут создать брешь в системе безопасности и обеспечить утечку информации (или её приток). Ещё одним плюсом таких брандмауэров заключается в том, что они определяют приложение не только по пути его размещения, но и по хэш-коду программы. Соответственно, если программа из белого списка будет как-то модифицирована (заражена), то изменится её размер и, соответственно, новый хэш-код и потеряет членство в "белом" списке.

Второй тип брандмауэров, который работает не на программном уровне (т.е. уровне представления) а на сетевом. Таких фаерволов можно спокойно пересчитать на пальцах: для linux-систем – ipfw для FreeBSD и netfilter/iptables для прочих linux-систем, и для Windows – IPSec (Internet Protocol Security) и Microsoft ISA Server (Internet Security and Acceleration Server). Справедливости ради, хочу отметить, что unix-реализация ipfw/iptables/netfilter является наиболее совершенной, чем вообще любой брандмауэр под Windows. Конкуренцию (по функционалу) здесь может составить разве что ISA Server, который является и файрволом (к слову говоря, он относится в равной степени к обоим типам файрволов) и прокси-сервером. Однако он обладает слишком широкими возможностями, что Microsoft создала отдельный учебный курс и сертификационный экзамен по этому продукту и он больше оптимизирован под корпоративные решения с интеграцией с Active Directory и в домашних условиях он не используется. Суть работы таких брандмауэров заключается в том, что они не контролируют какое приложение осуществляет доступ к сети. Т.е. любое приложение может инициировать запрос в сеть, но его запрос должен будет пройти целый ряд сетевых правил, которые решают судьбу пакета (т.е. передать или убить его). Как отмечалось выше, что программные брандмауэры в большинстве своём не следят за использованием портов приложениями. Поэтому, если троянская программа подружилась с кем-то из "белого" списка (посредством внутреннего языка приложения или API-функции), то она сможет через посредника рассылать данные в любые точки интернета. С IP-файрволами такие фокусы уже не проходят. Они строго ограничивают трафик только по их служебному назначению и любая отправка пакета на нестандартный удаленный порт (чем чаще всего и грешат такие троянские программы) приложением будет пресечена на корню. В этом заключается их главное преимущество, что они позволяют контролировать трафик на основании нескольких критериев характера этого трафика. Например, соответствие IP-адреса удаленного узла, его порта и протокола транспортного уровня. Если хоть под одно из этих условий сгенерированный пакет не подпадает, то он будет тут же убит. Например, вы не сможете создать TCP-сессию с удаленным узлом на 53-м порту, т.к. весь TCP трафик по такому пункту назначения запрещается (позже мы разберём, что порт 53 – порт DNS-сервера, а DNS работает с клиентом только по UDP-транспортному протоколу). Иными словами как бы не были хороши программные брандмауэры, но они не совершенны и имеют свои недостатки. К тому же программные брандмауэры имеют достаточно выскокий процент уязвимости, т.к. они используют в своей работе стандартные API-функции (иного им не дано, увы) уязвимость в которых отыскать куда проще, чем в остальных случаях. Например, если сопоставить общее кол-во уязвимостей, которые были опубликованы для Outpost Firewall и IPSec (а он как известно является открытым), то соотношение по этому показателю будет очень огромное, т.к. IPSec использует отличные от Outpost механизмы работы, которыми управлять достаточно сложно. Если взять, к примеру, ISA Server, то за последние 3 года (с релизом ISA Server 2004) в нём не было найдено ни одной(!) уязвимости в силу специфики их работы со стеком TCP/IP. Правда, здесь хочу отметить, что IPSec и ISA по разным (которые недоступны сторонним разработчикам) причинам очень тесно связаны с ядром ОС (которое в Windows закрыто) и степень влияния вредоносного ПО на них снижается в разы.

Примечание: Хотелось бы отметить еще один факт, который относится ко всем брандамауэрам без исключения, который сводит их полезность на «нет» - работа под администраторской учётной записью. Дело в том, что большинство брандмауэров имеют либо свой внутренний язык взаимодействия с дургими приложениями или стандартные API-функции, что позволяет другим приложениям общаться с брандмауэрам. Чем он популярней, тем более критичным для него становится сей факт. При работе под административной учетной записью троянской программе ничего не стоит обратиться к брандмауэру через один из интерфейсов (например, API) и от имени пользователя договориться о канале для себя (сымитировав включение в "белый" список программы самим пользователем) либо вообще прекратить его работу. В сети уже есть достаточно большое кол-во случаев, когда троянские программы запущенные под привелегиями администратора самовольно отключали он-лайн сканеры антивирусов и прекращали работу брандмауэров или открывали для себя порты. Поэтому я ещё раз хочу обратить ваше внимание на огромные риски постоянной работы под администраторской учетной записью. Тут вам уже ничто не поможет, поскольку административные полномочия позволяют почти всё и вы просто потеряете контроль над системой. Поэтому, работая под администраторской учетной записью полезность фаервола снижается очень и очень сильно.

Сразу оговорюсь, что IPSec не является только брандмауэром и его основная задача даже не является файрволингом. Если расшифровать термин, то получим IPSec – Internet Protocol Security (выше было дано определение) и IPSec был призван защищать трафик, который прохоидит через сетевые карты. При желании трафик можно шифровать, защищать пакеты от перехвата и их последующей переотправки и можно проверять целостность сообщения (убедиться, что с момента отправки до получения получателем пакет не модифицировался).

Для тех, кто знаком с 7-уровневой моделью OSI или 4-уровневой моделью TCP/IP могут понять, что IPSec работает на самом нижнем уровне этой модели – уровень IP (здесь и далее мы будем говорить только в рамках протокола TCP/IP version 4). Ниже уровня IP нету ничего, что позволяет нам создавать безопасность передачи данных не согласуя это с более высокими уровнями. А теперь разберём некоторые термины, которые очень важны для понимания данной статьи (Мы не будем разбирать процесс реализации модели OSI, инкапсуляции пакетов и т.д. ).

Для начала мы введём понятие IP-адрес. Думаю, что всем это известно – уникальный адрес абонента в пределах глобальной сети/интрасети.

Порт – вот тут остановимся поподробнее. На компьютере как правило установлено несколько программ, которые работают с протоколом TCP/IP, а значит, этому протоколу необходимо как-то различать конкретных получателей (самый верхний уровень модели OSI). Скажем, у нас есть сервер, на котором запущены службы HTTP и FTP при наличии только одного IP-адреса. Эти две службы слушают канал и ждут, когда к ним придут данные. А когда они придут, то по правилам его должен получить кто-то один, кому эти данные нужны. Поэтому во всем мире договорились поделить общий протокол TCP/IP на некие номера (как номера квартир) и на каждый номер посадить слушающего. Так же, для унификации и стандартизации во всем мире договорились, что общедоступные сетевые службы и приложения будут использовать только свои номера, но не чужие. Например, во всем мире все HTTP сервера (веб-сервера) сидят на порту под номером 80. Поэтому при наборе адреса в адресной строке браузера нам нет необходимости добавлять цифру 80, т.к. во всем мире договорились, что веб-запросы отправляются только на порт 80 и эту процедуру за вас сделает браузер. Соответственно, есть стандартная таблица соответствия имен служб к прослушиваемых ими портам. Например:
  • FTP – 21
  • Telnet – 23
  • SMTP – 25
  • DNS – 53
  • DHCP - 68
  • HTTP – 80
  • POP3 – 110
  • NetBIOS – 139
  • HTTPS/SSL – 443
Номерами портов мы уникально идентифицируем конкретную службу получатель на удаленном компьютере, на котором этих служб можеть быть огромное количество. Порт получателя обычно указывается через двоеточие (символ ":") сразу за адресом компьютера:
192.168.0.1:80 – данные для веб-сервера
192.168.0.1:110 – данные для POP3 сервера и т.д.

Краткое резюме: На данном этапе мы поняли, что на одном компьютере с одним IP-адресом может быть запущенно несколько сетевых приложений, как веб-сервер, почтовый сервер и еще какой-нибудь. Для идентификации конкретной службы мы ввели понятие сетевых портов при указании которого мы четко указываем, какому сетевому сервису предназначается пакет. Важно понять, что номер порта является простым числом, которое выполняет только одну функцию – идентификация службы и больше ничего эта цифра не делает.

Мы рассмотрели механизм разделения сетевых служб со стороны сервера. А теперь рассмотрим ситуацию со стороны клиента. Самый типичный пример – открытый браузер, в котором открыто несколько страниц (табов, закладок). Как браузер знает в какое окно выводить информацию с сайта? Здесь так же применяется метод разделения портов. Это значит, что каждое клиентское окно (таб) браузера будет иметь свой уникальный номер порта. Так же во всем мире договорились, что под клиентские приложения выделяется определенный диапазон портов, на которых серверные службы висеть никогда не будут. Диапазон выбран следующий: 1024-5000 (а при желании до 65535). Эти порты в Windows зарезервированы. Когда мы открываем браузер и открываем первую страничку, то браузер обращается к подсистеме Windows, чтобы та выделила свободный порт. Порт выбирается произвольно, но, обычно, по порядку. Если никто из сетевых приложений не работает, то система выделит для этого окна порт 1024. Этим номером мы уникально идентифицируем конкретное приложение и конкретное окно в приложении. Когда открываем другое окно (таб), то приложение снова обращается за портом. Система выделяет первый свободный порт. Можно предположить, что это будет порт 1025. Когда происходит обмен данными с сервером, то мы в заголовке пакета указываем следующую информацию:
  • IP адрес сервера;
  • Номер порта, на котором размещается требуемая служба на сервере;
  • IP адрес клиента (чтобы сервер знал куда обратно отправлять ответ);
  • Номер порта, на котором размещается служба/приложение клиента, которому нужно отдать эту информацию.
Тем самым, когда у нас в двух окнах браузера открыты разные страницы одного и того же сайта, у нас нету путаницы с обменом информации между одним сервером и двумя окнами браузера. Тут важно запомнить, что сервер будет отвечать клиенту только на тот порт, с которого сервер получил запрос. Сервер не будет гадать или наугад отправлять ответ, а отправит только на тот порт, откуда пришел запрос. Если окно браузера с портом 1024 обменивается данными с сервером, то условный для брандмауэра маршрут будет такой:
Клиент отправляет запрос на сервер:
192.168.0.5:1024 -> 192.168.0.1:80
Клиент сообщает серверу свой IP (192.168.0.5) и номер порта (1024), на который следует отвечать серверу. Сервер же обработав запрос отправляет ответ:
192.168.0.1:80 -> 192.168.0.5:1024

Тем самым клиент получив такой ответ передаст его окну приложения, которое использует порт 1024, а не 1025 или еще какой-нибудь. Таким образом один браузер может иметь и 10 открытых окон и отправлять одновременно на один веб-сервер 10 индивидуальных запросов, при этом каждое окно браузера уникально идентифицирует себя своим номером порта. Сервер обработав каждый запрос в полном соответствии с самим запросом сгенерирует ответные сообщения. И каждое ответное сообщение будет отправлено именно тому окну браузера, которое сгенерировало запрос. Для энтузиастов порекомендую приложение TCPView от Sysinternals и понаблюдать за сетевыми приложениями. Вы увидите, что браузер обращается к веб-серверу только к порту под номером 80 (так договорились во всем мире). Это видно после знака двоеточия в колонке Remote Address. И даже если у вас открыт один браузер, то в TCPView вы увидите процессов браузера ровно столько, сколько у вас открыто активных табов внутри браузера. Т.е. каждый таб себя уникально идентифицирует.

Краткое резюме: На данном этапе мы рассмотрели процесс взаимодействия клиентского приложения и серверной службы. Мы знаем, что когда клиент генерирует запрос на удаленный сервер, то сначала клиент обращается за уникальным портом для себя и на этом порту клиент будет ждать ответа от сервера. Сервер обработав запрос отправляет ответ именно на тот порт, с которого пришел запрос. И эти правила соблюдаются всегда и в обязательном порядке.

Изучив процесс взаимодействия клиента и сервера на низком уровне (с указанием IP и портов) мы можем начинать изучение взаимодействие на более высоком уровне – пользовательском. Как известно, механизмы взаимодействия приложений в сети очень сложны и для упрощения этого были введены некоторые сервисы и службы, которые прозрачно для пользователя делают всю работу по преобразованию пользовательского ввода в формат, который будет понятен более низкому и сложному уровню. Как известно, компьютеры в сети общаются посредством IP-адресов и портов. (если углубиться в сетевые технологии глубже, то это утверждение будет не совсем верным, т.к. в реальности они общаются по MAC-адресам и за процесс преобразования IP в MAC будет заниматься протокол сетевой маршрутизации ARP. Этот вопрос выходит за рамки текущей статьи и мы будем просто опутим этот процесс преобразования и договоримся, что общение между узлами происходит по IP). Но в строке браузера мы не пишем IP адрес веб-сервера, а пишем его дружественное имя (например, freesoft.ru), которое пользователю запомнить гораздо проще, чем IP. Чтобы это имя преобразовать в IP используется технология DNSDomain Name Service. DNS в упрощённом варианте работает до тупости просто. Просто напротив дружественного имени пишет его IP и всё. Когда клиент обращается к DNS серверу за IP, то сервер производит поиск имени и когда его находит возвращает вам IP адрес, который записан напротив этого имени. Все DNS сервера работают на 53-м порту. Это стандарт. И любое приложение, отправляющее запрос на DNS сервер будет отправлять его по умолчанию только на порт 53. Значит для того, чтобы работать в сети с брузером нам нужно для каждого запроса сделать 2 вещи:
  • Проеобразовать имя веб-сервера в IP адрес путем запроса DNS сервера на порт 53.
  • Отправить запрос на веб-сервер, порт 80.
Когда мы отправляем почту с клиента (MS Outlook, The Bat!, Mozilla thunderbird и т.д.) на удалённый SMTP-сервер почтового сервера мы должны проделать следующие операции:
  • Преобразовать имя почтового сервера (SMTP) в IP путем запроса DNS сервера на порт 53.
  • Отправить сообщение на SMTP сервер почтовика, порт 25.
Работая с клиентскими приложениями функции DNS практически всегда обязательны. Поэтому все брандмауэры пропускают трафик на 53-й порт, т.к. закрыв его мы значительно усложняем себе жизнь и комфортность работы в сети.
Процесс взаимодействия клиента с сервером DNS будет такой же, как и клиента с веб-сервером:
192.168.0.5:1065 -> 192.168.0.1:53
Клиент с произвольного порта отправляет запрос на 53-й порт сервера, а сервер ответит следующим образом:
192.168.0.1:53 -> 192.168.0.5:1065
Как мы здесь видим, то DNS сервер отвечает именно на тот порт, с которого был произведён запрос и клиент безошибочно определит кому доставить информацию.

Краткое резюме: На данном этапе мы расмотрели взаимодействие и преобразование пользовательской информации в более понятный компьютерный формат. Мы поняли, что кроме явных запросов в сети существуют и неявные запросы, такие как DNS-запросы, но которые необходимо учитывать при построении файрвола.

А теперь займемся уже построением конкретных схем с использованием информации, которую мы получили выше. Когда клиент генерирует запрос, то мы знаем явно только 3 вещи:
  • IP-адрес назначения;
  • Порт назначения;
  • Адрес получателя.
Вы спросите, почему здесь нету порта отправителя? Дело в том, что, как выше отмечалось, исходящий порт для клиента выбирается динамически из диапазона от 1024 до 5000 и этот процесс зачастую контролировать мы не можем. Соответсвенно порт отправителя нам неизвестен.

Совет: Хочется оговорить здесь следующий момент. Когда мы говорим о каком-то неизвестном нам параметре (IP-адрес, порт, протокол и т.д.) мы это неизвестное будем называть Any (в переводе с англ.яз. – Любой).
Рассмотрим, из каких сервисов состоит только веб-браузинг:
  • Преобразование имен в IP-адреса путем отправки запроса на DNS-сервер, порт 53.
  • Стандартна служба HTTP. Все запросы отправляются на порт 80.
  • Когда мы регистрируемся или логинимся, или вводим конфиденциальную информацию, то используется защищенный протокол HTTPS (Hyper Transport Transfer Protocol Secured) или SSL (Secure Socket Layer). Все такие запросы клиент отправляет только на порт 443.
  • Иногда на сайтах предлагается скачать файл по FTP (File Transfer Protocol) через то же окно браузера. Значит, на нужно знать, на каком порту работает FTP-сервер. FTP работает на порту 21 (редко 22). По умолчанию браузер будет отправлять запросы на FTP только на 21-й порт.
Теперь для каждого пункта составим таблицу исходного адреса/порта и адреса/порта получателя.
1. Так как мы не знаем с какого порта мы будем взаимодействовать с DNS-сервером (а с DNS будет взаимодействовать множество приложений и, соответственно будет будет использоваться много исходящих портов), то исходный порт нам неизвестен. По нашей договоренности исходящий порт будет равен Any. Так же для поддержания универсальности мы договоримся, что локальный адрес отправителя (клиента) будем указывать как My IP Address. Дело в том, что у каждого пользователя будут свои индивидуальные адреса, которые соответствуют локальному адресу localhost (127.0.0.1). Т.е. этот универсальный адрес localhost будем называть My IP Address. Значит мы уже знаем как будет выглядеть полный адрес отправителя:
My IP Address:any (это значит, что запрос отправляет наш компьютер с произвольного порта, который выделит нам система и его контролировать мы не в состоянии). Адреса DNS-серверов нам неизвестны явно, они в каждом случае будут разные. Но у них всех будет одно общее – порт 53. Значит получателя мы запишем как:
Any:53
Т.е. конкретного адреса мы не знаем и их может быть много, но порт нам известен. Если вы будете взаимодействовать только с одним или несколькими известными DNS-серверами (например, с DNS-сервером провайдера, что будет предпочтительным), то вместо адреса назначения Any можете указать конкретный IP-адрес DNS-сервера (то же самое относится и к дургим серверам).

Совет: Чтобы узнать адрес своего DNS-сервера (их адреса меняются очень редко) необходимо выполнить команду:
Start -> Run... -> cmd
В открывшемся окне набираем ipconfig /all и ищем адреса DNS-сервера (как правило их будет два).

Просто в общем случае мы ставим Any, чтобы не быть зависимым от конкретных сетевых настроек. Сложив обе половинки мы получим процесс запроса:
From My IP Address:any -> any:53
Читается как: с локального компьютера и с произвольного порта запрос может быть отправлен на любой IP (Any) но только на порт 53. Еще раз повторюсь, что все DNS-сервера сидят только на 53-м порту. Мы знаем, что DNS (равно как и любая служба) отвечает с того же порта, на который отправили запрос (в нашем случае 53) и на порт с которого был отправлен запрос (его мы не знаем, т.к. он динамически выделяется). Значит DNS должен ответить следующим образом (глазами клиента):
From Any:53 -> My IP Address:any
Читается как: с любого IP в интернете и порта 53 (т.е. только от DNS сервера) может быть отправлен на наш локальный компьютер и получить его может любой порт. Если вы обратили внимание, то ответ является зеркальным (т.е. по сравнению с первым вариантом просто получатель и отправитель поменялись местами). Зеркалироваться ответы будут практически всегда и это нужно запонмить, т.к это очень упростит нам жизнь.
Теперь подытожим цикл общения с DNS-сервером со стороны клиента:
Запрос – from My IP Address:any -> any:53
Ответ – from any:53 -> My IP Address: any

2. После того как мы разрешили имя в IP адрес, мы можем уже обращаться к самому веб-серверу. Мы знаем, что будем отправлять запрос с локального компьютера и неизвестного порта на любой IP (веб-серверов и веб-сайтов в мире миллионы, поэтому упростим перечисление всех сайтов одним параметром Any) и порт 80.
From My IP Address:any -> Any:80
Читается так же как и формулировка для DNS только порт будет не 53, а 80. Веб сервер будет так же отвечать зеркально (получатель и отправитель поменяются местами):
From Any:80 -> My IP Address: Any
Читается так же как и формулировка с DNS. Так мы можем подытожить взаимодействие локального компьютера с произвольным HTTP (веб) сервером:
Запрос – from My IP Address:any -> Any:80
ОтветAny:80 -> My IP Address: Any
Следуя этой простой аналогии мы создаем правила прохода HTTPS/SSL:
Запрос – from My IP Address:Any -> Any:443
ОтветAny:443 -> My IP Address:Any
И для FTP:
Запрос – from My IP Address -> Any:21
Ответ – from Any:21 -> My IP Address:Any
Если вы еще не заметили, то мы с вами написали практически полноценные правила для файрвола. Все аппаратные файрволы и программные файрволы основанные на характере трафика (например, IPSec) создают именно такие правила. Зная порт, на котором висит конкретная служба и, возможно, адрес мы можем по этому принципу написать правила для взаимодействия практически для любой сетевой службы. Например, для приёма почты по POP3:
Запрос – from My IP Address -> Any:110
Ответfrom Any:110 -> My IP Address:Any
Для SMTP:
Запрос – from My IP Address -> Any:25
Ответ – from Any:25 -> My IP Address:Any
Везде всё будет одинаковым, за исключением номера порта службы. Сейчас я постараюсь сделать выписку с наиболее часто используемыми сетевыми службами в домашних условиях с указанием порта и транспортного протокола (разбор транспортных протоколов как TCP/UDP выходит за рамки данной статьи, вам просто нужно запомнить, какая служба на каком транспортном протоколе работает):
  • FTP – 21 (TCP)
  • Telnet – 23 (TCP)
  • SMTP – 25 (TCP)
  • DNS – 53 (UDP)
  • DHCP – 68 (UDP)
  • HTTP – 80 (TCP)
  • Pop3 – 110 (TCP)
  • NetBIOS – 137, 138(UDP), 139(TCP)
  • HTTPS/SSL – 443 (TCP)
  • Remote Desktop/Remote Assistance 3389 (TCP)
  • RAdmin – 4899 (TCP)
  • Internet Radio – как правило 8000 (UDP).
Причечание: Остальные приложения, как пиринговые клиенты (eMule, DC++, Torrents) являются распределенными и требуют ручной настройки портов для своей работы. Вы можете за этими приложениями закреплять любые порты в диапазоне от 5000 до 65535 и потом на основе вами указанных портов создавать правила. Подробнее проблему с пиринговыми клиентами разберём отдельно, если это будет необходимо.

Краткое резюме: На данном этапе мы изучили наиболее часто используемые порты сетевых служб в интернете и основываясь на этой информации мы научились писать самые настоящие правила для файрвола IPSec для работы с распространёнными сетевыми службами интернета. По этой же аналогии можно будет создавать правила и для других сетевых служб, которые не отмечены в списке.

Настало время знакомиться с консолью IPSec, которая есть в системе Windows 2000 и выше. Для работы с ней нам необходимо зайти в систему под учетной записью администратора и меню Run... (Выполнить...) запустить консоль MMC. В меню Action нужно выбрать Add/Remove Snap-in. В раскрывшемся списке указать IP Security Policy Management и перетащить в нашу консоль, после чего нажать Finish.

В правом окне мы увидим уже 3 преднастроенные политики IPSec – Client (Respond Only, Server (Request Security), Secure Server (Require Security). Первая политика является самой простой и открытой, т.е. трафик весь разрешён. При этом сам компьютер не инициирует соединения. Вторая политика (Request Security) сначала пытается установить защищённое соединение с удаленным узлом. Если ей это удается – то оно устанавливается. Если нет – то соединение переходит в незащищённый режим (обычный режим). Третья и наиболее жёсткая политика – Require Security. При этом с данным компьютером можно установить защищённое соединение (или данный компьютер с удалённым узлом). Если удаётся, то оно устанавливается. Если нет, то компьютер не установит соединения и будет блокировать все пакеты. В принципе, за основу можно взять любую из них но мы создадим свою политику. Для этого нажмём в свободном месте правой кнопкой мыши и выберем Create IP Security Policy и назовём её My Computer Policy. Далее выбираем активировать Default Response Rule и выбираем по умолчанию Kerberos и соглашаемся с предупреждением. После чего мы должны увидеть следующее окно:

Изображение

Вот это окно будет для нас самым главным. Здесь мы будем видеть список всех установленных нами правил (в граве IP Filter List), действие на правило (Filter Action) и прочие параметры, которые нас в данный момент интересовать не будут. Чтобы добавить новое правило, нажимаем кнопку Add. В окне Tunnel Endpoint выставляем This rule does not specify a tunnel. И продвигаемся дальше, выбираем для каких сетевых подключений будет использоваться данное правило. Выберем All Network Conncections. В следующем окне, которое будет выглядеть примерно так:

Изображение

Выставляем переключатель напротив All ICMP Traffic и нажимаем Next. После чего мы увидим окно, которое называется Filter Action. Нетрудно догадаться, что здесь будет выбираться действие, которое будет выполняться в случае, если трафик подпадёт под это правило. Окно будет иметь вид:

Изображение

И пока что есть 3 варианта. Это – Permit (разрешить), Request Security (запросить безопасное соединение. В случае неудачи установить обычное соединение) и Require Security (требовать безопасное соединение. В случае неудачи - разорвать соединение). ICMPInternet Connection Management Protocol – это особый вид трафика, который позволяет нам при помощи специальных пакетов отслеживать проблемы прохождения пакетов и отслеживать узлы в сети. Например, при отправке команды ping на удалённый узел система отправляет специальный ICMP пакет. Если ICMP запретить, то вас никто не сможет пропинговать, но и вы не сможете никому отправить пинг. К ICMP пакетам относятся все пакеты, которые отправляются при команднах ping, tracert, pathping и др. Чтобы в случае какой-то неисправности мы могли бы проверить работу узла мы разрешим ICMP трафик и в качестве действия выберем Permit. После чего нажимаем Next и Finish. Теперь мы вернулись в главное окно нашей политики IPSec и видим, что создано правило для ICMP пакетов. Если пакет подпадает под это правило (допустим, пингуем машину), то он будет на основании действия на это правило разрешён.

Теперь повторяем операцию нажатием Add и кнопками Next доходим до окна IP Filter List. Здесь мы видим ещё один вид трафика – All IP Traffic. К этому типу трафика будет относиться весь оставшийся трафик, который будет существовать на данной машине. Выставляем переключатель напротив этого пункта и нажимаем Next. Однако, согласно нашей стратегии мы будем запрещать весь(!) трафик, за исключением разрешённых правилами типов трафика и который не будет подпадать под наши правила. Для того, чтобы запретить весь трафик в этом окне мы создадим новое действие для всего IP-трафика кнопкой Add. В качестве названия действия выберем наиболее понятное слово – Deny (что знаить, запретить), а в поле Description напишем описание этого действия, например "Блокировать трафик»". Нажимаем Next и нам предлагаются следующие варианты: Permit (разрешить), Block (блокировать трафик) и Negotiate Security (требовать безопасность). Мы выберем здесь Block, т.е. запрещаем трафик. После чего нажимаем Next и Finish. Мы снова возвращаемся в окно Filter Action, где у нас появляется новое действие, которое мы только что создали:

Изображение

Выставляем переключатель напротив действия Deny и нажимаем Next и Finish. Мы снова возвращаемся в главное окно нашей политики, где мы наблюдаем, что у нас есть 2 правила для трафика (для ICMP и для всего IP) и для каждого правила определено действие, которое будет выполняться, если хоть один пакет подпадёт под одно из них. Если сейчас активировать эту нашу политику, то кроме отправки и получения ICMP пакетов у нас ничего работать не будет в сети. Эти два базовых правила будут определять общее правило нашей всей политики. Общие правила возможны следующие – "разрешить всё, кроме..." и "запретить всё, кроме..." (так же как мы определяли базовые правила для Software Restriction Policies). Т.к. мы весь IP трафик блокировали, то у нас получается второе правило. Теперь настало время заполнить многоточия в общих правилах и создать исключения для общего него.

Чтобы что-то начало работать мы должны создать набор правил для того типа трафика, который должен отправляться и приниматься. Выше мы уже рассматривали как строятся эти правила и создадим первое из них – для отправки пакетов на DNS-сервер, чтобы мы могли преобразовывать имена серверов в их IP-адреса. Ещё раз вспомним, как этот трафик будет проходить:
Запрос – from My IP Address:any -> any:53
Ответ – from any:53 -> My IP Address: any
В главном окне нашей политики мы создаём новое правило кнопкой Add. Кнопками Next мы доходим до окна со списками фильтров IP Filter List, где у нас уже есть фильтры для ICMP и IP. Т.к. мы создаём новый фильтр (правило), то здесь мы нажимаем кнопку Add. В качестве имени мы введём название DNS Client и в поле Description введём описание его (например,"преобразование имён серверов в IP-адреса"). Теперь мы должны описать само правило конкретными параметрами (адресами, портами и протоколами транспортного уровня). Для этого нажимаем Add

Изображение

Кнопками Next мы доходим до окна под названием IP Filter Description and Mirrored property. Как мы отмечали выше, у нас все правила будут зеркалироваться, т.е. ответ будет приходить туда же, откуда был отправлен запрос. Поэтому винзу отмечено галочкой Mirrored. Нажимаем Next и у нас появляется окно IP Traffic Source, где мы будем указывать адрес отправителя запроса. Т.к. запросы инициируем мы (согласно нашей схеме прохождения трафика, запрос от нас идёт первым), то в качестве адреса отправителя указываем My IP Address, что будет соответствовать адресу localhost. Нажимаем кнопку Next и мы переходим к окну, где требуется указать IP-адрес получателя, т.е. DNS-сервера. Если мы знаем его адрес (например, адрес DNS-сервера провадера), то мы выбираем A specific IP Address и в появившихся ниже полях указываем конкретный IP-адрес DNS-сервера. Если мы не знаем его адреса, то в списке указываем Any IP Address. И переходим к следующему окну, где укажем транспортный протокол. Если вернуться выше и посмотреть на таблицу сопоставления серверных служб их портам и протоколам, то мы увидим, что DNS работает через протокол UDP, а, значит, его мы и выбираем в списке (на самом деле DNS сервера между собой работают ещё на 53-м порту через протокол TCP, но такой трафик используется только для пересылки и репликации зон между серверами). После чего, нажимаем ещё раз Next и переходим к окну IP Protocol Port, где указываем порт отправителя (from) и порт назначения (To). Как мы уже условились, мы не можем знать, с какого порта поступит запрос на сервер, поэтому в поле From укажем From any port. Ещё раз смотрим таблицу сопоставления имён служб их портам, мы видим, что DNS-сервер сидит только на 53-м порту. Никогда DNS-сервер не будет сидеть, например, на 54-м или 52-м порту, только на 53-м. Значит в поле порта получателя указываем To this port и в окошко вписываем число 53. Далее, нажимаем Next и Finish. После чего мы возвращаемся в окно только что созданного фильтра для DNS клиента. Здесь мы можем просмотреть его описательные характеристики. Выглядеть это должно следующим образом:

Изображение

Где мы в нижнем окне видим параметры, которые мы задали, чтобы охарактеризовать запросы на DNS-сервер. Выше мы описывали как запрос на сервер, так и ответ от него, но сейчас мы указали только порядок запроса на DNS-сервер. Но, т.к. правила у нас все зеркальные (о чём свидетельствует графа Mirrored и значение – Yes), то мастер настройки фильтра уже сам добавит правило для получения ответа от сервера. Поэтому здесь мы заканчиваем и нажимаем кнопку Ok, после чего возвращаемся к окну со списками фильтров. Мы создавали правило для DNS-запросов, значит выставляем переключатель напротив нашего нового фильтра и нажимаем Next. Теперь мы переходим к окну Filter Action и указываем действие Permit. Здесь и далее в качестве действия на фильтр мы будем выбирать только Permit, т.к. весь остальной трафик у нас и так запрещён. Закрываем окно кнопкой Next и Finish. Сейчас главное окно нашей политики имеет следующий вид:

Изображение

Если сейчас активировать нашу политику, то у нас будет запрещён весь трафик, кроме ICMP и запросов/ответов на DNS-сервер.
Следуя предыдущей аналогии мы создадим правило, после которого у нас браузер сможет заходить на веб-сайты и просматривать странички. К браузингу будут относиться протоколы HTTP, HTTPS/SSL и пассивный клиент FTP.
Итак, снова вспомним, как у нас выглядят эти запросы.
Запрос – from My IP Address:any -> Any:80 – TCP - HTTP
ОтветAny:80 -> My IP Address: Any
Запрос – from My IP Address:any -> Any:443 – TCP – HTTPS/SSL
ОтветAny:443 -> My IP Address: Any
Запрос – from My IP Address:any -> Any:21 – TCP – Passive FTP
ОтветAny:21 -> My IP Address: Any

Здесь нас будет интересовать только запрос (правило для ответа будет автоматически будет создано мастером). Используя эту информацию мы приступим к созданию правила Web Client
В главном окне нашей политики нажимаем кнопку Add и в окне IP Filter List нажимаем Add и в поле названия правила впишем Web Client. В поле с описании добавим пояснительную запись (например"«фильтры для клиентских веб-протоколов HTTP/HTTPS(SSL)/FTP"). После чего нажимаем снова кнопку Add, чтобы добавить соответствующие фильтры для каждого типа веб-трафика. В окне IP Filter Description and Mirroring впишем "HTTP Client". Согласно нашей схеме адрес отправителя (т.е. адрес клиента) будет наш локальный адрес, значит в Source Address выбираем My IP Address, в поле Destination Address выбираем Any IP Address (мы не знаем к каким веб-серверам будем подключаться). В поле протокола указываем TCP. С портами будет так же как и с DNS, т.е. Source Port – Any, а для Destination Port – 80 (веб-сервера сидят на 80-м порту всегда). После нажатия кнопки Finish мы возвращаемся к окну нашего правила и видим, как добавился фильтр для HTTP трафика. Здесь же добавим фильтр для HTTPS/SSL по такому же принципу:
Add -> Description (любое понятное описание) -> My IP Address -> Any IP Address -> TCP – from any port/to 443 port -> Finish.
И для FTP Client:
Add -> Description (любое понятное описание) -> My IP Address -> Any IP Address -> TCP -> from any port/to 21 port -> Finish.
Если вы всё сделали правильно, то у вас должно получиться вот такое окно:

Изображение

Если у вас всё (за исключением полей Description, которые служат только для описания) соответствует, то нажимаем кнопку Ok и мы возвращаемся в окно IP Filter List, где появится наше новое правило. Напротив него мы выставляем переключатель, нажимаем Next и переходим к окну Filter Action мы выбираем Permit (мы разрешаем трафик, который будет подпадать под эти правила). Next, Finish и возвращаемся к главному окну политики, где мы можем рассмотреть уже созданные нами правила и при необходимости отредактировать их. Если у вас не получилось такое же окно, как на скриншоте, то перечитайте всю последовательность действий ещё раз.

Из часто используемых типов трафика у нас остаётся ещё почта. Детально уже расписывать не буду, как для них создавать правило (Mail Client) и фильтры (в одном правиле будет два фильтра – POP3/SMTP). Здесь нужно действовать в той же последовательности, что и при настройке правила Web Client, за тем исключением, что порты получателей будут 110 и 25, соответственно (эти данные можно взять из таблицы сопоставления, которая приведена выше).
Если у вас есть локальная сеть и вы через неё обмениваетесь файлами с другими компьютерами (через сетевое окружение), то необходимо создать правила как для клиента локальной сети (когда вы подключаетесь к кому-то) и как для Сервера локальной сети (когда кто-то извне подключается к вам). Сейчас я приведу таблицу портов и протоколов, которые нужны для работы NetBIOS:
  • Разрешение имён NetBIOS – 137 UDP
  • Обозреватель компьютеров (который отвечает за список компьютеров и рагаренных папок в сети) – 138 UDP
  • служба сеансов NetBIOS (которая отвечает за пересылку файлов по сети) – 139 TCP.
Примечание: Наличие разрешительных всех трёх фильтров для работы сетевого окружения обязательно!

Если клиентскую часть вы делаете по той же аналогии, что и для предыдущих примеров, то серверную часть (когда файлы скачивают с вас через сетевое окружение) необходимо делать так же, за той разницей, что в Source Address у вас будет не My IP Address, а Any IP Address и в поле Destination Address у вас будет My IP Address, т.к. подключаются к вам, а не наоборот.
Это должно выглядеть следующим образом:

Изображение

Для начала вы можете поупражняться на моих примерах с описаниями и после этого уже создавать свою финальную политику. Когда вы убедитесь, что все правила и фильтры для них созданы и задано действие для них, то кнопкой Ok вы закрываете главное окно нашей политики. Однако, наша политика ещё не действует, т.е. её нужно активировать. Чтобы активировать её, нажмите правой кнопкой на нашу политику и в контекстном меню выберите Assign (Присвоить) и в системе автоматически станут действовать наши правила. Чтобы отменить действие политики, достаточно на ней нажать правой кнопкой и выбрать Un-assign (отменить).

Совет: Если вы не знаете, какие порты использует тот или иной сервис в интернете, то воспользуйтесь утилитой TCPView от Sysinternals (при отключённой политике, разумеется), где вы можете просмотреть всю свою сетевую активность, где будут указаны адреса и порты получателей и отправителей данных. Эти данные можете потом использовать для построения новых правил и фильтров для своей политики.

Если, вдруг, вы переустанавливаете систему Windows или хотите перенести свою политику на другой компьютер, то вы можете легко её экспортировать. Для этого в левой части консоли (где находится IP Security Policies on Local Computer), нажать правой кнопкой и в меню All Tasks выбрать Export Policies и экспортировать в файл (расширение будет .ipsec). На другом компьютере вместо Export Policies выбираете Imort Policies и указываете путь к файлу.

Итоговое резюме: итак, мы с вами просмотрели и реализовали на практике свой собственный брандмауэр, основанный на встроенном в Windows брандмауэре IPSec, который в достаточно сильной мере усложнит жизнь вредоносному ПО и значительно снизит приход и отправку нежелательного трафика. Мы прошли действительно один из самых тяжёлых и сложных материалов, с которым может повстречаться рядовой пользователь. Скажу, что поднять домен Active Directory куда проще, чем настроить с нуля свой собственный файрвол на IPSec :) . На сертификационных курсах Microsoft теме IPSec (для безопасников) уделяется достаточно серьёзное внимание. На самом деле мы рассмотрели лишь десятую часть из всех возможностей IPSec, которые способны на 100% (и это правда) защитить компьютер от любого(!) несанкционированного подключения. Но в нашей задче было лишь рассмотрение файервольных возможностей IPSec. Если вы весь этот материал освоили, то можете считать, что вы получили уже хорошие знания по файерволингу, которые сможете в дальнейшем применять для настройки практически любых сторонних брандмауэров с высокой эффективностью.

Обсуждение статей, предложения, поправки будет здесь:
http://forum.freesof...?showtopic=3155

Сообщение отредактировал Дед с бокорезами: 23 Февраль 2010 - 22:45

Microsoft MVP: PowerShell
мой блог: http://www.sysadmins.lv
0

#4 Пользователь офлайн   Дед с бокорезами 

  • Дед форума
  • PipPipPipPipPipPipPipPip
  • Группа: VIP
  • Сообщений: 1 078
  • Регистрация: 20 Март 06

Отправлено 06 Сентябрь 2008 - 14:24

Software Restriction Policies в Windows Vista
Постами выше я уже рассказывал про использование Software Restriction Policies в Windows XP/Windows Server 2003 и теперь хочу рассказать о ключевых изменениях данной политики в Windows Vista и Windows Server 2008.

Политика включается как обычно:
  • локальная - Start -> Run... -> secpol.msc -> Software Restriction Policies
  • доменная - Group Policy Object Editor -> Computer Configuration -> Windows Settings -> Security Settings -> Software Restriction Policies

Итак, какие изменения у нас появились по сравнению с предыдущими версиями:
  • в Security Levels добавился новый уровень безопасности Basic User;
  • в Additional Rules удалены 2 правила по умолчанию, которые разрешают запуск EXE файлов в папках Windows и Windows\System32;
  • при использовании правил Hash Rule теперь вместо MD5 (как в предыдущих версиях) используется более стойкий алгоритм хэширования Sha256, но при этом сохранилась совместимость со старыми клиентами XP/2003 (будет храниться 2 хэша - MD5/Sha1 и Sha256);
  • в Enforcement добавился Enforce/Ignore Certificate Rule;

Казалось бы, пустяк, но я считаю, что тут есть о чём поговорить. Итак, сначала поговорим о новом действии политики как Basic User. Данное действие политики было специально заделано под User Account Control (UAC) и которое совместно с UAC филтрует права пользователя на запуск. Если политики UAC распространяются на все приложения без исключения, то комбинирование действия по умолчанию UAC и при использовании Software Restriction Policies позволяет запретить повышение привелегий для некоторых приложений. Иными словами, даже если запустить приложение с повышенными привилегиями, они всё равно будут отфильтрованы.

Пример 1.

Рассмотрим поведение политики Basic User для установки действия Basic User для программы CMD.EXE:

Сперва при отключенной политике выполню команду, которая включает режим Hibernate для компьютера. Для этого нажимаю на ярлыке CMD правой кнопкой и выбираю Run As Administrator и получаю предупреждение UAC:

Изображение

соглашаюсь и получаю консоль командной строки, в которой набираю следующую команду и исполняю:

Изображение

данная команда включает режим Hibernate (возможно не самый удачный пример) и ошибок не вернула.

Действие общей политики здесь неважно, поэтому перейдём сразу к Additional Rules. Для этого я создал Hash Rule для CMD.EXE как показано на картинке:

Изображение

Теперь снова запускаю консоль CMD с повышенными привилегиями и повторяю процедуру:

Изображение
хоть я и просил повышенные привилегия для исполнения команды, но действие Basic User не дало этой возможности и отфильтровало мои права до обычного пользователя. Т.е. мы видим, что Basic User ни за что не позволяет выполнить приложение в привилигированном режиме!

Пример 2.

В предыдущем примере я добровольно пытался запустить приложение с повышенными привилегиями. В результате никакого повышения не получилось и приложение запустилось в обычном режиме. А теперь рассмотрим запуск приложения, которое требует повышенния привилегий через UAC. Для этого я буду использовать запуск консоли Computer Management с возможностью изменения настроек консоли. Я удалил правило для CMD.EXE и создал такое же правило для консоли compmgmt.msc:

Изображение
И при нажатии правой кнопкой на Computer -> Manage получил запрос на повышение прав от UAC с чем я и согласился:

Изображение

и снова действие Basic User отфильтровало мои повышенные права и выдало такое окошко. Как видно из скриншота политика блокировала запуск консоли. Ещё раз повторюсь, запуск данной консоли с возможностью изменения настроек без повышения прав через UAC невозможно, что мы и видим на рисунке.

Резюме: Действие политики SRP Basic User не позволяет ни в коем случае выполнить приложение с повышенными привилегиями. Если это доступно, то приложение запускается в обычном режиме, как показано на примере 1 или вообще запрещает запуск, если приложение для запуска требует повышенных прав, как это видно на примере 2.

Примечение: Когда первый раз я стал изучать политику SRP на своём нотебуке с Windows Vista был неприятно удивлён, когда при активации политики Disallowed у меня сохранялась возможность запуска .EXE файлов напрямую из проводника и .LNK из меню Start -> Run... . Я помню по XP/2003, что политика активировалась в момент при выборе действия политики. Здесь же я обнаружил что политика применилась лишь частично, игнорировав .EXE и .LNK файлы. Этим вопросом я озадачил Александра Станкевича, который позднее подсказал, что наблюдал такое же поведение на 2008 сервере до тех пор, пока не перезагрузил компьютер. Поэтому при инициализации политики для её полной активации нужно перезагрузить компьютер! Когда политика проинициализирована перезагрузка больше не требуется до полной отмены политики и все изменения применяются на лету. О чём, кстати сообщается в правом окне политики SRP, когда политика удалена или не создана (эхх, невнимательный какой).

Ну и ещё добавлю небольшую заметку по интеграции политик SRP с UAC. В Enforcement есть опция применения политики SRP For All Users except Administrators, т.е. применение политики ко всем пользователям, кроме администраторов. Данная опция работает только для приложений, которые запущены с повышенными привилегиями. Это вполне логично, т.к. даже локальный администратор работает в системе с правами обычного пользователя (ситуацию, когда UAC отключён совсем я не рассматриваю, ибо это не есть хорошо), поэтому в обычной работе политика в любом случае будет воздействовать на него. Это важно понимать, т.к. не совсем явная вещь и её легко упустить из виду.

Что касается Enforce/Ignore Certificate Rule, то тут наверное нету смысла объяснять, что это. По умолчанию правила сертификатов проверяются в первую очередь и если у вас они не используются, то включение обработки правил сертификатов может значительно снизить скорость запуска приложений.

Порядок (приоритет) применения правил политики SRP:
  • Certificate Rules
  • Hash Rules
  • Path Rules
  • Default Rule

поэтому отключение правил сертификатов, когда они не используются будет весьма кстати. Напомню, что Certificate Rule может использоваться не только для фильтрации подписанных приложений, но и для разрешения запуска подписанных доверенными сертификатами скриптов.

И на последок дам 3 .REG файла, которыми я пользуюсь в работе для управления политикой:

SRP_Enable - включает действие политики в Disallowed:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers]
"DefaultLevel"=dword:00000000


SRP_Disable - включает действие политики в Unrestricted:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers]
"DefaultLevel"=dword:00040000


SRP_Basic - включает действие политики в Basic User:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00020000


Я обычно кладу эти 3 файла (теперь 3, до этого использовались только SRP_Enable и SRP_Disable) в папку Windows и на рабочий стол администраторской учётной записи создаю ярлыки для них:

Изображение

эти ярлыки включены в исключения политики и указывают на соответствующие .REG файлы, которые так же находятся в исключениях. Однако хочу заметить, что действие этих ярлыков в среде рабочей группы может быть изменено после перезагрузки системы (после перезагрузки вернётся действие, которое указано в политике), а в доменной среде - либо после перезагрузки либо при последующем обновлении политик (по умолчанию - 1 раз в 90 минут). Поэтому данные ярылки дают лишь временный эффект, но как правило они и нужны на очень короткий срок.

Ну и хочу поделиться маленькой приятной особенностью, которая появилась сейчас. Администраторы, которые работали с политикой SRP в системах XP/2003 испытывали головную боль при обновлении серверов и рабочих станций. Проблема была в самом механизме работы инсталляторов апдейтов, которые в корне произвольного тома создавали папки с произвольными именами, в которые распаковывались апдейты и затем устанавливались. Такая схема не представляла возможным создание правил для SRP, чтобы без отключения политики установить апдейты. Поэтому во время апдейтов приходилось отключать политику и после включать её обратно. В Windows Vista и Windows Server 2008 это уже не так! Я сегодня же проверил возможность установки обновлений с Windows Update при включенной политике SRP Disallowed. И все 16 обновлений спокойно установились и политику отключать не пришлось. Это хороший плюс для Windows Vista!

Вроде осветил основные изменения политик Software Restriction Policies и ничего не забыл.

Using Software Restriction Policies to Protect Against Unauthorized Software

Сообщение отредактировал Дед с бокорезами: 23 Февраль 2010 - 21:57

Microsoft MVP: PowerShell
мой блог: http://www.sysadmins.lv
0

Поделиться темой:


Страница 1 из 1
  • Вы не можете создать новую тему
  • Тема закрыта

1 человек читают эту тему
0 пользователей, 1 гостей, 0 скрытых пользователей