Windows NT/2000/XP

Напрацювання Microsoft no OS/2 New Technology були в 1993 р. випущені на ринок під назвою Windows NT. Версії 3.x і 4.0 цієї системи забезпечували сумісність з 16-розрядними застосуваннями для OS/2 1.x в окремій підсистемі, без можливості звертатися з 16-розрядних додатків до 32-розрядних DLL і навпаки. У описуваний період з DEC в Microsoft у повному складі перейшла команда розробників ядра VMS під управлінням Д. Катери. Microsoft широко рекламував цей факт і стверджував, що Windows NT знаходиться з VMS в набагато ближчій спорідненості, ніж з OS/2 1.x. З таблиці. П.1 видно, що це твердження не дуже-то узгоджується з дійсністю.

Таблиця П.1. Порівняння OS/2 1.2, Windows NT і VMS

Найбільш важливі запозичення з VMS — сторінкове підкочування і ідентифікація користувача на рівні процесів — були відповіддю на насущні вимоги розвитку системи і могли бути запозичені з будь-якої ОС, адекватної часу. У останньому, таблиця. П.1 показує, що OS/2 1.x, безумовно, доводиться Windows NT набагато ближчою ріднею, ніж VMS.
Найбільш важливою запозиченою концепцією була журнальна файлова система NTFS, що є цікавим гібридом HPFS (основний ФС OS/2) і FCS2 (основний ФС VAX/VMS). Це запозичення слід визнати досить вдалим. Набагато менш вдалим було запозичення своєрідної стратегії управління робочою безліччю процесів в ОЗУ, використовуваною в VMS: розробники Microsoft усунули з цієї стратегії одне з ключових понять, квоту розміру робочої безлічі. В результаті вийшла система, практично не здатна скористатися перевагами сторінкового підкочування, тому що навіть невеликий брак оперативної пам'яті наводить до різкого падіння продуктивності із-за нездатності системи збалансувати потреби додатків і дискового кеша. Ще одна ключова для розуміння архітектури Win32 концепція була позаимствована зовсім не з VMS і навіть не з OS/2 1.x, а була, швидше за все, введена по наполегливих проханнях розробників графічних застосувань для Apple Macintosh. Йдеться про системному реєстрі (system registry) централізованій базі даних, в якій всі модулі системи, стандартні утиліти і прикладні програми зберігають все, що вважають потрібними зберегти.
Системний реєстр вперше був реалізований в Mac OS. Ця система має досить просте ядро і небагатий набір системних налаштувань, тому реєстр Mac OS в основному містить налаштування прикладних програм і в такій формі сповна терпимий. Навпаки, досить складна розрахована на багато користувачів Windows NT, що підтримує широкий спектр зовнішніх пристроїв, потребує великого об'єму конфігураційних даних для самої системи. Характер звернень до різних частин цих даних сильно розрізняється — деякі, наприклад, потрібні лише при завантаженні системи, а зміні підлягають лише при зміні апаратній конфігурації. Інші ж міняються при кожному відкритті нового вікна призначеною для користувача програмою. Відносна цінність цих даних також розрізняється дуже різко: спотворення деяких може привести до неможливості завантажити систему або до втрати користувачами доступу до неї, деякі інші можна було б і не зберігати зовсім. В світлі цього, ідея загального "звалища", в якому міститься все на світі, — починаючи від слів, які виголошував користувач, намагаючись прибрати з екрану знамениту скріпку, і закінчуючи БД облікових записів -представляется авторові не дуже-то здоровою думкою.
У Windows NT цей концептуальний недолік посилюється недоліками реалізації — реєстр не має адекватних засобів резервного копіювання і відновлення (при фатальних пошкодженнях реєстру Microsoft рекомендує переустановлення системи) і фактично позбавлений засобів самоконтролю і діагностики. В усякому разі, у версії 4.0 (автор не мав випадку перевірити це на пізніших версіях системи, але судячи по тому, що виправлення цієї помилки не анонсувалося, в 2000/ХР ситуація не змінилася) ОС ніколи не зменшувала об'єм реєстру, навіть після видалення великої кількості ключів.
Ще однією важливою новиною була підтримка декількох процесорів — окрім х8б перші версії Windows NT були реалізовані для RISC-процессоров MIPS і DEC Alpha, і, істотно пізніше, для POWERPC. Більшості RISC-процессоров не мають багаторівневих режимів доступу, характерних для VAX і 80286Д86, тому розробники Windows NT були вимушені відмовитися від привілейованих бібліотек (поняття, яке в тій або іншій формі було присутнє як в OS/2 1.x, так і в VAX/VMS), що розділялися, і перейти до дворівневої системи привілеїв.
Розробники додатків не виявили цікавості до альтернативної апаратної архітектури, тому NT на цій архітектурі не мала великого успіху, і в 1999 р. без великого шуму була припинена підтримка Windows NT для останнього неинтеловского процесора, який на той час вже називався Compaq Alpha [techupdate.zdnet.com]. До того ж, поки NT була маловикористовуваною системою з бідним набором мережевих сервісів, мало хто серйозно цікавився її зломом. Це привело до посилення тиску з боку управлінців - "ось бачите, у сусідів стоїть -- і нічого", тому сервери під управлінням NT все частіше і чаші підключалися до Internet, інколи навіть без закриття яким-небудь брандмауером (треба відзначити, що firewall (брандмауер) в даному випадку мало чим може допомогти — сайт [www.microsoft.com] закритий маршрутизатором з фільтрацією пакетів "по самі вуха", і те його "упускають" кілька разів в рік). Поширення системи привело до того, що зломщики із спортивного інтересу зацікавилися нею серйозно. Першою ластівкою був випущений в 1997 р. вільно поширюваний продукт Back Orifice (дослівно — "задній прохід"), що демонстрував цілий набір способів діставання неавторизованого доступу (у тому числі і з подальшою установкою троянських програм) до систем Win32. Встановлюваний як троянська програма компонент пакету довгий час був кращим з доступних інструментів видаленого управління Win32-системами і автор знає немало системних адміністраторів, які використовували його в своїх мережах [www.sourceforge.net bo2k]. Втім, одна ластівка весни не робить, і ще три роки користувачі Win32-cHCTCM жили відносно спокійно (якщо можцо вважати спокійним життям постійну боротьбу з макровірусами для MS Office, поштовими вірусами і іншими породженнями хворої фантазії). За цей час в систему додалися нові мережеві сервіси і розширилася номенклатура сервісів, що запускаються при установці ОС за умовчанням, — наприклад, в їх число попав флагманський серверний продукт, сервер ftp/HTTP і ряд інших протоколів, IIS (Internet Information Server). Власне весна настала в серпні 2001 р. з пандемією мережевого черв'яка Code Red, який, як і черв'як Моріса, використовував декілька каналів поширення, у тому числі зриви буфера в мережевих сервісах IIS. Як і черв'як Моріса, заразивши одну з машин домена, Code Red поширювався на інші машини того ж домена простим копіюванням по мережі. Подальший розвиток подій, втім, різко відрізнявся від наслідків атаки червя Моріса: Microsoft досить швидко випустила латки (patches)що виправляли частину використовуваних вірусом помилок — проте повна кількість помилок, що залишилися в коді системи і мережевих сервісів, від цього майже не змінилося. Атаки черв'яків і полівалентних (що використовують декілька каналів поширення) вірусів, які легко долають корпоративні брандмауери (firewalls) продовжувалися впродовж всього 2001 р., демонструючи все нові і нові проблеми в системі безпеки Windows NT/2000/XP. У опублікованому у вересні 2001 р. доповіді аналітична компанія Gartner Group рекомендувала ні за яких обставин не використовувати IIS через величезну кількість відомих і вельми песимістичні прогнози на кількість невідомих уязвимостей. До моменту написання книги прогнозувати подальший розвиток подій не представлялося можливим. Вочевидь, що ситуація з безпекою Windows може лише погіршуватися — або, точніше, абсолютна нетерпимість положення справ з безпекою в Windows може ставати лише і більш очевидніша все більшому і більшому громадянству. Спроби виправити положення законодавчими заходами, наприклад, застосовуючи кримінальні покарання до розробників вірусів або забороняючи публікацію відомостей про проблеми з безпекою, навряд чи можуть змінити тенденцію. Так, покарання для розробників вірусів, хоча і морально виправдано, але навряд чи може бути ефективним, тому що в більшості випадків творця практично неможливо ідентифікувати, а идентифицировав — вельми складно довести його провину по стандартах судочинства демократичних країн. У свою чергу, законодавча заборона публікації відомостей про помилки, розмови про яке почалися в 2001 р., не лише абсолютно не виправданий морально, але і украй шкідливий з прагматичної точки зору, хоч би тільки тому, що зробить неможливим прийняття контрзаходів адміністраторами уразливих систем. Оптимістичний сценарій розвитку подій може полягати в тому, що користувачі почнуть масовим чином відмовлятися від вживання Windows, або Microsoft перегляне свій підхід до проектування, розробки і тестування програмного забезпечення (або що в даному випадку включає). Так або інакше, виправлення положення зажадає значних вкладень в перебудову всієї обчислювальної інфраструктури і не може пройти безболісно. Втім, історичний досвід дає авторові вельми мало підстав для оптимізму.