Как Windows Server 2008 дава възможност на администраторите да скриват файлове и папки от потребителите които нямат права да четат тези обекти.

В голяма корпоративна мрежова среда където многото отдели има отделни споделени папки само за тяхно ползване се налага потребителите на файловите сървъри да имат достъп само до споделените файлове и документи от техният отдел.
Access-based Enumeration (ABE) е нова възможност (feature) която e част от File Server ролята в Windows Server 2008 (За Windows Server 2003 SP1 може да се изтегли допълнително от сайта на Microsoft). ABE дава възможност на администраторите на файловият сървър да скрият обектите до които потребителя няма достъп (права за четене). Когато на споделената папка (share folder) е разрешена тази функция на потребителя “логнал” се на файловият сървър ще се изведе лист с папките и файловете до които той има достъп. Ако за дадена папка или файл от съществуващите в споделената папка потребителя няма права за четене, то автоматично тази папка ще бъде скрита. Активна е само когато се отварят папки и файлове през споделена папка (Server Message Block  – SMB shares), и не е активна ако тези файлове и папки се достъпват чрез локалната файлова система.

Идеята на Access-based Enumeration

Скриването на файлове и папки до които потребителя няма достъп може да предпази конфиденциалната информация от “любопитни потребители”(някои от тях може да са и с лоши намерения). Ако не е активирана тази функционалност тогава на “любопитният потребител” ще му се покаже папката до която няма права и при опит да я отвори ще му се изведе съобщение за отказан достъп. ABE предпазва точно от опитите на “любопитните потребители” да достъпват класифицираната информация намиращата се в споделените папки.

Другото преимущество на ABE е, че поддържа споделената папка по чиста и потребителите виждат само това до което имат право на достъп. Така не се получават ненужни обаждания до ИТ поддръжката свързани с това, че потребителя не може да отвори папка и излишни обяснения към потребителя, че информацията в тази папка която се опитва да отвори не е предназначена за него.

Кога е въведена и в кои операционни системи се използва

Тази функция можете да използвате във Windows Server 2003 SP1 след като направите допълнителна инсталация. В Windows Server 2008 и по-новите операционни сървърни системи тази функция е вградена.

Как се активира или деактивира Access Based Enumaration (ABE)

В Windows Server 2008 има два варианта за активиране или деактивиране на тази функция.

През конзолата “Share and Storage management”

На таба Shares от Share and Storage management се избира споделената папка на която искаме да активираме/деактивираме опцията. След това се избира Properties от десният панел (Action pane). От появилият се прозорец се избира бутона Advanced.. Следва нов диалогов прозорец в който се намира опцията Enable access-based enumeration.

Share and Storage management

През конзолата DFS Managment

Разпъва се списъка Namespaces от лявата колона. В него са описани всички  споделени папки на сървъра на който се намираме. Избира се споделената папка на която искаме да активираме/деактивираме опцията. След това се избира Properties от десният панел (Action pane). От появилият се прозорец се влиза в таб Advanced и най-долу се намира опцията Enable access-based enumeration for this namespace.

DFS Managment - Enable Access Based Enumaration

В кои случай може да се използва

Сценарии 1 – на файловият сървър се намират работните файлове на няколко отдела. Всеки отдел си има собствена папка в която другите нямат достъп и не виждат. Също така трябва да се реши въпроса с достъпа до файлове до които ще трябва да имат достъп за отделни проекти по няколко отдели.

Ако не използваме ABE и за да постигнем целта ще трябва да направим толкова споделени папки колкото са отделите. За всеки отдел по една споделена папка. На всеки от потребителите да му даваме достъп чрез мрежово устройство до споделената папка на неговият отдел. Права за четене на всяка споделена папка ще имат потребителите от отдела за който е папката. Така никой от другите отдели няма да има достъп до документите на чуждите отдели.

Втората част от условието е по-сложна. В някои случаи може да се създаде една обща споделена папка в която всички да имат достъп и там да добавят общите проекти. Друг вариант е за всеки проект да се създава отделна споделена папка и до нея да се дава достъп само на отделите които трябва да имат достъп. В случай че проектите ще са повече така реализирана втората част от условието ще създаде в бъдеще повече работа за ИТ отдела.

Ако използва ABE можем да бъдем по-гъвкави като първо ще направим една споделена папка в която ще се създадат папки за всеки отдел. За всяка папка ще има настроени такива права, че само потребителите от отдела на който принадлежи да имат достъп до нея. След като се включи функция ABE на споделената папка всички потребители ще имат възможност да виждат само файловете от собствените си отдели. В този случай само до тук се спестяват няколко процеса от работата която ще трябва да извърши ИТ отдела.

Втората част също може да се реализира елегантно, като за всеки нов проект се създава по една папка в основната споделена папка. Върху тази папка ИТ отдела ще настрои права за достъп само на оторизираните потребители. Така потребител X от отдел Y който работи и по проект Z когато отвори споделената папка в нея ще види списък само на папки и файлове на отдела му Y и проекта Z. В този случай лесно може да се даде достъп на управленският персонал да вижда също цялата структура на споделената папка където се намират файловете и папките  на отделите и проектите.

Сценарии 2 – На файлов сървър се намират личните папки на всички потребители. Трябва всеки потребител да вижда само своите данни.

Ако не ползваме ABE – тогава ще трябва да се направи една основна споделена папка в която да се съхраняват личните папки на всички потребители. На всяка от личните папки ще трябва да се настрои права да има само нейният собственик. За да не се вижда списъка с всички папки тогава на всеки потребител ще трябва да се добавя като мрежово дисково устройсво (Network Map) следното “\\ServerName\Users\UserName” където Users е основната споделена папка в която се съхраняват всички останали лични папки. В този случай ако някой потребител влезе директно в “\\ServerName\Users” то той ще види списък с папките на всички останали потребители, но няма да може да влезе в никоя друга освен в неговата.

Ако използваме ABE стъпките са подобни но с малко опростяване и намаляване на броя операции които трябва да се извършат от ИТ отдела. Структурата и подредбата на потребителските папки остава същата. Разликата идва в това, че на основната споделена папка се включва функцията ABE и на всички потребители се дава възможност да влизат в “\\ServerName\Users”. В този случай потребител X като отвори “\\ServerName\Users” ще открие в списъка единствено личната си папка.

От всичко това до тук следва да направим извода, че използването на Access Based Enumaration е задължително за големи и динамични компании където ИТ специалистите не могат да си позволят загуба на време в работният процес. Тази функция е създадена да улесни тяхното ежедневие и затова в Windows Server 2008 е разрешена на всички споделени папки които се създават по-подразбиране. Не е разрешена в някои специални случаи като Admin Shares (C$, Admin$).

Windows firewall

Windows Firewall е вграден софтуер даващ възможност за ограничаване на трафика в съвременните операционни системи на Microsoft от Windows XP до момента. Предназначен е за осигуряване на защита от злонамерени програми или потребители които използват нежелан трафик за да атакуват компютърната система. Защитната стена помага да запазите компютъра по-сигурен. Програмата проверява целият трафик, който идва към компютъра от други компютри и мрежи и дава допълнителен контрол за управление на съдържанието което се изпраща към него. Основната и най-важна функция на една защитна стена е да предпазва от мрежовите атаки и вредителите които вървят по тях като вируси, троянци, хакерски атаки и други. Също така защитната стена се ползва и като бариера за мрежовият трафик които идва от различните мрежи по Интернет и вие може да разрешавате или забранявате кой трафик да се насочва към компютърната система.

Windows 7 и Windows 2008 както и по-новите версии предлагат разширена защитна стена която се нарича Windows Firewall with Advanced Security. Това е отделна конзола чрез която може да се управлява защитната стена на операционната система. За да стартирате тази конзола ще трябва да отворите Administrative Tools и от там да изберете Windows Firewall with Advanced Security. Лично за мен по лесният вариант е стартирането със следната команда:

wf.msc

От тази конзола могат да се създават правила, които разрешават или блокират трафика в мрежата и в двете посоки на според необходимите изисквания. Може също да се създава IPsec правила за сигурност чрез които се защитават данните изпращани по мрежата към друг компютър.

Windows Firewall Profiles

Профилите в Windows firewall се използват за групиране на настройки, като правилата на защитната стена и правилата за осъществяване на сигурна връзка, които се прилагат към компютъра в зависимост от това къде е свързан. Съществуват три профили на Windows Firewall with Advanced Security които са:

Домейн (Domain)

Приложен към определен мрежов адаптер, когато той е свързан към мрежа с  домейн контролер и в който компютърът е добавен.

Частен (Private)

Профил прилагащ се към мрежови адаптер когато той е свързан към мрежа която се определи от потребителя или администратора като частна мрежа. Частната мрежа означава, че връзката с Интернет е зад някакъв защитен механизъм, като например NAT рутер или хардуерна защитна стена. Такава мрежа може да е бъде домашната мрежа или бизнес мрежата в която няма домейн контролер. Правата на Частният профил трябва да бъдат повече ограничени от правата на домейн профила.

Публичен (Public)

Прилага се към адаптер който е свързан към публична мрежа като тези намиращите се в летищата и кафенетата. Когато защитната стена не е настроена на нито един от другите два профила Domain или Private, профилът по подразбиране е публичен. Настройките на Публичният профил трябва да бъдат с най-много рестрикции защото сигуртността на публичната мрежа в която е свързан компютърът не може да бъде контролирана.

Достъпът до настройките на тези профили се осъществява след като се стартира конзолата Windows Firewall with Advanced Security и от десният панел се избере Properties което стартира диалогов прозорец с настройки.
За всеки от горните три профила потребителя или администратора има възможност да настрои състояние на профила (Firewall State). От тук се определя разрешаването или забраната на входящи или изходящи връзки.

Входящи връзки (Inbound connections)

Тази настройка определя поведението на входящите връзки, които не отговарят на правилата за входящи връзки на защитната стена (inbound firewall rules). Поведението по подразбиране е да се блокират връзки освен ако не съществува правило което да разрешава връзката. Има възможност да се изберат следните поведения за входящи връзки:

Block (default) – Блокиране по подразбиране.

Забранява всички връзки, които нямат правилата на защитната стена, които изрично позволяват връзката.

Block all connections – Блокиране на всички връзки

Забранява абсолютно всички връзки независимо от това, че съществува едно или нялколко правила за разрешаване на връзката.

Allow – Разрешаване

Позволява осъществяването на всички връзки освен ако има правило което изрично блокира връзката.

Изходящи връзки (Outbound connections)

Тази настройка определя поведението на изходящите връзки, които не отговарят на изходящите правила на защитната стена. Поведението по подразбиране е да се разрешава връзката освен ако не съществува правило което я блокира. Можете да изберете следното поведение за изходящи връзки:

Block –  Блокиране

Забранява всички връзки освен тези които са разрешени чрез правата зададени в защитната стена за изходящи връзки.

Allow (default) Разрешаване (по подразбиране)

Разрешава всички връзки освен тези за които в защитната стена има правило което изрично ги блокира.

Правила за входящи и изходящи връзки.

Намират се в конзолата Windows Firewall with Advanced Security и са разделени на две категории:

Правила за входящи връзки (Inbound Rules)

Тук са описани всички правила които са необходими на потребителя или администратора на компютърната система за входящи връзки. Тези правила могат да включват разрешаване на определени връзки от други компютри в мрежата или на други портове. Потребителя или администратора има възможност да въвежда неограничен брой правила които да разрешават или да блокират дадени връзки според определени критерии. Защитната стена ги взима в предвид в зависимост от това за кой профил са настроени (домейн, публичен, частен) и от състоянието (забранени входящи, забранени всички входящи или разрешени) което е настроено за този профил.

Правила за изходящи връзки (Outbound Rules)

В този списък потребителя или администратора на компютърната система описва всички правила за разрешаване или забрана на изходящи връзки според определени от неговите нужди критерии. Всяко правило може да важи за различен профил и да зависи от състоянито на този профил.

Пример:
Как да настроим Windows Firewall да приема входящи връзки само от портоер 332 и 449.

  • Стартираме wf.mcs
  • Първо проверяваме и настройваме състоянието на всички профили от диалоговият прозорец който извикваме чрез Properties (от дясната лента)
    Във всички табове Domain, Private, Public настройваме състоянието на Inbound Connection да бъде Block (default) и приемаме настройките с OK
  • В списъка Inbound rules добавяме ново правило чрез New Rule (от дясната лента) което да разрешава всички входящи връзки използващи порт 332 и 449.
  • От появилият се помощтник избираме Port.
  • След това изреждаме със запетая портовете които са ни нужни.
  • На следващата стъпка задаваме, че този тип връзки ще бъдат позволени от защитната стена – Allow the connection
  • Следва избор към кой от профилите ще се използва това правило (избираме всичките три профила)
  • Накрая трябва да дадем име на новото правило и ако е необходимо да напишем описание.
  • След като натиснем бутона Finish новото правило се появява в списъка с правила.

Последователността от стъпки можете да видите по-долу:

 

 

Подписване на драйвери в Windows

Вместо увод ще отговоря на няколко въпроса:

Какво е драйвер?

Драйверът е специализиран софтуер, даващ възможност на компютърната система да осъществява комуникация с хардуера за който е този драйвер. Без драйвери хардуерът, който сте свързали към компютъра (например видеокарта или уеб камера), няма да работи правилно.

Какво е подписан драйвер?

Подписаният драйвер е софтуер за устройство, включващ цифров подпис.

Какво е цифров подпис и как се използва за подписвне на драйвери?

Цифровият подпис е електронен знак за сигурност, който определя издателя на софтуера, както и това, дали някой е променял драйвера след подписването му. Ако даден драйвер е подписан от издател, който е проверен от сертифициращ орган, можете да сте сигурни, че софтуерният драйвер е от този издател и не е бил променян.

Защо Microsoft въведе подписването на драйвери?

При инсталация на драйвери в съвременните Windows операционни системи се използват цифрово подписани драйвери за да може операционната система да се увери в целостта на пакетите на драйвера и за да определи дали може да се довери на производителя  създал драйвера  (анг. термин е The signer is trusted).

Кои файлове се подписват?

При подписването на драйвери със сертификат може да се изберат два варианта за подписване на файлове.
Първият е да се подпише каталог файла съдържащ информация за всички останали файлове от пакета с драйвери, а вторият е да се имплементира подписа дирекнто в даден драйвер файл който зарежда ОС.

Каква е разликата в подписването на каталог файла и вграждането на подпис директно в драйвера?

Директното подписване (embedded signature) се използва само в 64 битови ОС Microsoft Vista и по-нови и се използва за драйверите които се стартират заедно със “бутването” на ОС. Тези драйвери трябва да имат вграден подпис – Software Publisher Certificate (SPC). Този тип подписване не е задължителен за драйвери които не се зареждат при стартиране (boot-start). Драйверите които се стартират заедно с операционната система имат повече права за достъп и  ги наричат още kernel-mode драйвери.
Използвайки този тип подписване на драйвера времето на стартиране на ОС намалява защото няма необходимост да се търси и намира каталог файла на драйвера при стартирането на ОС. Вграждането на подпис в драйвера е задължително за всички драйвери които се стартират при стартирането на ОС за х64 битовите версии на Windows Vista и по-нови.

Подписването на каталог файлове в съвременните версии на 64 битовият Windows най-често се използва при драйвери за устройства от типа Plug and Play (PnP). Този тип подписване съществува и в по-стари операционни системи (въведено с Windows 2000). При използване на този тип подписване при инсталацията на драйверите ОС копира и съхранява каталог файла на този драйвери в папка %SystemRoot%\CatRoot и inf файла в %SystemRoot%\Inf. Това се изпълнява със следните “директиви” CatalogFile directive, INF CopyFiles directives. Подписа вграден в каталог файла съдържа отпечатъците на всички файлове от този набор от драйвери. По време на инсталацията се проверяват тези отпечатъци и обявяват пакета за невалиден ако се открие промяна на някой от файловете настъпила след подписването (тоест отпечатъците не съвпадат).

Процеси при подписване на драйвери

  • Производителя на драйвера получава от сертифициращ орган ( Certificate Authority – CA) цифров сертификат за подписване X.509. Този сертификат се издава след като CA е проверил производителя. Сертификата за подписване съдържа набор от данни които индетифицират производителя.
  • Подписването със сертификат се използва за да се подпише каталог файл (.cat) или директно да се подпише драйвера. Сертификатът за подписване съдържа двойка ключове: частен и публичен ключ. Частният ключ се използва за подписване на каталог файла (.cat) на пакета с драйвера или директно да се подпише и вгради в драйвера. Публичният ключ се използва за проверка на подписа направен на каталог файла или на този който е вграден в драйвера.
  • За да се подпише каталог файл или да се вгради подпис във файл процесът за подписване първо генерира криптографски хеш или отпечатък на файла или файловете. При подписване на каталог файл този отпечатък се прави на всички файлове от каталога, а когато се подписва само един драйвер файл се използва само неговият отпечатък. Следващата стъпка е да се криптира този отпечатък със частният ключ. Накрая се добавя криптираният отпечатък във файла който се подписва. Този процес също добавя информацията на издателя на софтуера и на сертифициращия орган издал сертификата за подписване. Цифровият подпис се добавя във секция от файла която не се използва при генерирането на отпечатък.

Проверка на подписаните драйвери

Процесът по проверка на цифровият подпис на файла от Windows операционна система се извършва като първо се прочете информацията за издателя на драйвера и за сертифициращият орган. След това се използва публичният ключ за да се декриптира отпечатъка.
Windows преминава към инсталиране на драйвера ако:

  • декриптираният отпечатък съвпада с отпечатъка на файла
  • сертификатът на издателя се намира в раздела Доверени Издатели (Trusted Publishers certificate store.)
  • root сертификата на сертифициращият орган издал сертификата на издателя в инсталиран в “Trusted Root Certification Authorities certificate store”

Сертифициращ орган ( Certificate Authority – CA) е орган в мрежа, която решава и управлява идентификационни данни за сигурност и публичен ключове за криптиране на съобщение.

От информацията дотук можем да извадим няколко извода
  • Драйвери без валиден цифров подпис или такъв, който е променян, след като е бил подписан, не могат да се инсталират на 64-битови на Windows.
  • Подписването на драйвери е въведено за да се предпазят операционните системи от вируси вградени в драйверите – особено kernel-mode драйверите.
  • Подписа гарантира, че производителя на драйвера е достоверен източник на софтуер за Windows.
1. Find and document as much as possible for the Windows Driver Signing process

Разлики между MBR и GPT

Съвременните операционни системи Microsoft Windows дават възможност за използването на два вида стандарти за разполагане на файловата таблица върху физически твърд диск. Това са MBR и GPT. MBR (MASTER BOOT RECORD) се превежда като Запис за първоначално зареждане. Той се записва в първият физически сектор на хард диск като този запис се прочита от BIOS-а веднага след проверката на паметта, дисковете и периферните устройства. GPT (GUID Partition Table) е формат на файловата таблица на който използва GUID (Globally Unique Identifiers). Тъй като са разработени и внедрени в операционните системи с доста голяма разлика във времето те имат и доста различия. По долу ще разберете подробно къде са основните им разлики:

Разработване и внедряване на в MBR и GPT

Първо ще се спра на това кога са разработени. MBR технологията е разработена през 1980г. и затова е доста позната. Използва се във всички операционни системи Microsoft Windows от 20 години насам. GPT таблицата е разработена 10 години по късно през 1990г. обаче използването и от Microsoft е започнало през 2001г. когато приема GUID Partition table от EFI (Extensible Firmware Interface) спецификаците на Intel.

Обем на дяловете и размера на блоковете в MBR и GPT

MBR стандарта запазва информацията за адресирането на логическите блокове и техния размер в 32 бита, докато GPT разполага с 64 бита за същата информация(нарича се още LBA адресиране). Дяловете са последователни обеми от пространство, физически или логически, които функционират все едно са физически отделни дискове. Тези дялове ги вижда системния фърмуер (BIOS) и операционната система. Достъпът до дяловете бива контролиран първо от BIOS и след това от стартираната операционна система. За дискове с 512 байта сектори, регистърът на MBR позволява дялове с максимален размер 2.20 TB. GPT използва 64 битово LBA адресиране, което позволява дялове с размер до 9.44 ZB (зетабайта). Windows ограничава този размер до 256TB (терабайта) за един дял чрез NTFS limit(при размер на клъстера 65,536 bytes).

Маскимален брой на дяловете описвани от MBR и GPT

По подразбиране GPT таблицата има възможност за именуване на до 128 дяла, докато MBR таблицата позволява само четири дяла или 3 основни дяла (Primary Partitions) плюс 1 разширен дял(Extended Partition). Този така наречен Extended дисков дял може да бъде разделян на няколко логически дяла (Logical Partitions). GPT предоставя произволен номер за дисковете и дяловете, в зависимост от определения размер за файловата таблица, което премахва нуждата от разширени и логически дялове. Точно от там идва и абревиатурата GUID Partition table.

Къде съхраняват файловата таблица MBR и GPT

Това е едно от основните разлики между двата формата и благодарение на тях много от често срещаните проблеми при работа с MBR не възникват или се решават по лесно когато се използва GPT.
Старият MBR формат записва данните за всеки дял от физическият хард диск в така наречената таблица на дяловете (partition table) която се намира в скритият от потребителя Master Boot сектор в началото на хард диска. Това води до доста проблеми когато по някаква причина тази таблица се повреди или загуби. В този случай имаме данните в нашите дялове, но нямаме таблицата от която операционната система може да разчете къде във физическият хард диск се намират дяловете. От друга страна GPT форматът е добре дефиниран и напълно самоидентифициращ се защото всяка служебна информация за дяловете се записва върху самите тях, а не върх скрити сектори от хард диска. GPT запазва и бекъп хедър и информация за дяловата таблица на края на всеки диск, което спомага за възстановяване на данни, ако оригиналите са повредени.

Специфични изисквания и поддръжка от операционните системи

MBR се поддържа от всички Microsoft Windows операционни системи до момента и няма специфични изисквания към системния фърмуер на компютъра. От друга страна GPT ще го срещнете само в по-новите операционни системи като се започне с Windows Vista от клиентските ОС и следващите и от Microsoft Windows 2008 от сървърните операционни системи. Има някои изключения които са изредени в смисъка по-долу:

  • Windows XP x64 Edition има възможност да използва GPT само за данни
    всички версии на Windows Server 2003 Service Pack 1 могат да използват GPT само за дискове с данни
  • само х64 битовата версия на Windows Server 2003 Service Pack 1 може да зарежда (booting) на операционна система от такъв GPT дял.
  • GPT се поддържа също и от Linux и MAC операционни системи.

Тъй като GPT е разработен за новото поколение компютри (така наречените Itanium-based computers) се изисква задължително BIOS да е UEFI базиран, за да може да заредим операционната система от дял с GPT таблица. Затова GPT е препоръчително да се използва на високопроизводителни нови компютърни системи с поддръжка на UEFI и за дискове над 2TB.