===Безопасность против безопасности===

История компьютерной безопасности полна примеров, когда при разработке вычислительных систем (ВС) требования совместимости, эффективности, удобства вступали в противоречие с требованиями безопасности, и безопасность проигрывала. Аналогично, при администрировании системы, лицо, ответственное за это, имеет возможность настроить систему на больший или меньший уровень защищенности, но часто жертвует безопасностью в угоду тому же удобству пользователей, скорости обработки данных и т.п. Наверное, каждый, кто хоть немного интересуется безопасностью компьютерных систем, может привести не один пример на этот счет¹.

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

Начну с примера, который и послужил толчком к созданию данной статьи.

У сетевой ОС Novell Netware (пользующейся репутацией достаточно защищенной ОС: по крайней мере, Novell Netware 4.11 - единственная ОС широкого назначения, имеющая американский сертификат по классу защищенности для сетевых ОС) среди настроек есть пункт "Intruder Detection" (обнаружение нарушителей). Это громкое название на самом деле ни что иное, как регистрация на сервере неоднократных попыток ввода неправильного пароля. Правильно ли это с точки зрения компьютерной безопасности? Безусловно, регистрация попыток неверной аутентификации - обязательное требование к защищенным вычислительным системам, упоминаемое как в импортных, так и отечественных нормативных документах. Однако фирма Novell пошла несколько дальше - и логику тут легко понять - действительно, почему бы не просто фиксировать такие попытки, но и не пресекать их средствами ОС? Пусть хакер пытается подобрать пароль к вашему ресурсу (account) в системе, тогда через N₁ попыток система выдает сообщение об попытке взлома, а через N₂ - вообще блокирует дальнейшие попытки ввода паролей (в настройках Novell Netware это называется "Lock account after detection"). Логично? Безусловно. Правильно? А вот тут стоит чуть-чуть задуматься о том, что же означают слова "блокировать дальнейшие попытки ввода паролей". А означают они буквально следующее - в течение некоторого времени t ("Length of account lockout") никакой пароль не будет восприниматься системой, ваш ресурс будет заблокирован (disabled). Иначе говоря, в течение этого времени t даже вам, законному пользователю, не дадут зарегистрироваться в системе из-за действий хакера.

В настройках Novell Netware 3.x по умолчанию N₁=3, N₂=7, t=15 минут. И вот теперь представим, что хакеру необходимо обезопасить свою новейшую атаку на Novell Netware от возможных контрдействий супервизора (замечу, супервизора, беспокоящегося о проблемах безопасности, поэтому он включил опцию "Intruder detection"). Он вводит 7 неправильных паролей супервизора, и в течении 15 минут может спокойно реализовывать свою основную атаку, супервизору останется лишь кусать локти. Самое интересное, что блокировка ресурса супервизора приводит к невозможности ни удаленно подключится к консоли с помощью RCONSOLE, ни разблокировать клавиатуру на консоли (опция в утилите MONITOR.NLM), т.е. он не может помешать атаке даже с консоли сервера.

Итак, парадоксальное свершилось - администратор, настроив свою систему на потенциально больший уровень безопасности, оказался более беззащитен перед новой угрозой, чем если бы он этого не делал! Да, здесь налицо видны недостатки того решения, что предложила фирма Novell - можно было блокировать дальнейшие попытки ввода пароля только с одного сетевого адреса (т.е. конкретной машины), можно было разрешать доступ даже к заблокированному ресурсу, если все же введен правильный пароль, можно было вообще решать проблему удаленного подбора паролей введением увеличивающейся задержки на отклик при вводе очередного неправильного пароля - но ведь сделано именно так и, если не углубляться, кажется, что правильно!

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

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

Таким образом, если условно разделить функции подсистемы защиты на (см. рис. 1):

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

К наиболее распространенным и универсальным (могущим существовать во многих ВС) я бы отнес следующие сценарии нарушения безопасности, использующие сами средства защиты (цифры соответствуют предыдущему списку):

2. Затруднение угрозы приводит к установке таких атрибутов безопасности, которые являются неприемлемыми для пользователей этой системы, что приводит к отключению или фактическому сведению на нет системы защиты (см. пример 4 - установка минимальной длины пароля для атак на криптографическую подсистему).

3. Система обнаружения угроз имеет такие расплывчатые признаки угрозы, что ее постоянное срабатывание приводит к ее полному отключению (пример - резидентные антивирусные блокировщики первого поколения, доводившие пользователя до исступления вопросами "Разрешать запись в файл XXX (Д/Н)?").

5. Использование системой регистрации значительных ресурсов ЭВМ, из-за чего происходит отказ системы (см. пример 3 - переполнение файла регистрации событий, приводящее к отказу в обслуживании).

6. Предположим, что система восстановления поле атаки восстанавливает "ядро" системы из некого резервного источника. Но, если в результате атаки хакер сможет внедрить "троянского коня" непосредственно в резервную копию, то в результате такого восстановления эта закладка попадет в реально работающую систему.

Далее будет рассмотрен ряд примеров, иллюстрирующий эти сценарии.

Опять Novell Netware. Известно, что все пароли пользователей хранятся в ней на сервере в виде 128-битных значений, получаемых в результате применения хэш-функции к паролю. Знание этого хэш-значения злоумышленником автоматически приводит к возможности зарегистрироваться на сервере под именем того пользователя, чье хэш-значение он знает. (Это может быть сделано с помощью специальной слегка подправленной программы login, а также путем генерации "псевдопароля" из известного хэш-значения. Здесь используется тот факт, что хэш-функция, применяемая во всех версиях этой системы, является очень нестойкой и допускает очень быстрое вычисление коллизий (т.е. последовательностей, которые будет на выходе давать одно и то же хэш-значение) [3]).

Именно поэтому хэш-значение тщательно охраняется, и не передается по сети в открытом виде при аутентификации пользователя на сервере. Вместо этого используется стандартная схема "запрос-отклик": сервер посылает случайную последовательность, рабочая станция шифрует ее с вычисленным хэш-значением введенного пароля и отсылает обратно, сервер делает то же самое с имеющимся у него хэш-значением, в случае совпадения двух строк пользователь успешно регистрируется в системе. Но для этого как-то хэш-значение должно оказаться на сервере? Нетрудно понять, что по крайней мере оно должно попадать туда при смене пароля пользователем. А раз так, то злоумышленник, чтобы перехватить хэш, должен дождаться, пока пользователь захочет поменять свой пароль 2. А это, к несчастью для него, может произойти в неопределенный момент времени. Если только он не знает этого момента заранее или ... не сможет заставить пользователя сделать это. Вспомним первый пример. Высока вероятность того, что пользователь (или супервизор), узнав о многочисленных попытках взлома своего ресурса (или обнаружив его заблокированным) захочет поменять свой пароль. (Впрочем, если он немного подумает, то он не попадется на эту удочку, и скорее всего попросит администратора отключить блокировку его ресурса в случае "обнаружения нарушителя").

Но на помощь кракеру может прийти другое мощное средство повышения безопасности системы Novell Netware (имеющееся, впрочем, почти во всех ОС, претендующих на защищенность), а именно "заставлять периодически менять пароль" (force periodic password changes). Зная, что администратор системы "повысил" ее защищенность путем периодической обязательной смены паролей, злоумышленнику остается только дождаться момента плановой смены паролей, и золотой ключик, т.е. хэш-значение супервизора у него в кармане. Этот пример я считаю весьма показательным.

Как известно, одна из версий Windows NT была сертифицирована по американским требованиям С2 для своего несетевого варианта. И хотя эта сертификация вызывает много вопросов, существует утилита C2Config, которая формально позволяет настроить Windows NT в соответствии с требованиями С2. В частности, эти требования распространяются и на подсистему регистрации и учета (audit). Утилита C2Config предлагает следующую настройку аудита для повышения безопасности всей системы:

"Очистка протокола событий" (Event Log Wrapping) - "Не перезаписывать события (очищать вручную)" (Do Not Overwrite Events (Clear Log Manually).

Опять все кажется совершенно логичным. Да, администратор должен просмотреть все, что отражено в протоколе, после чего этот протокол можно стереть. Уничтожаться события в защищенной системе автоматически не должны, иначе регистрация атаки может оказаться невозможной.

Однако смотрим следующий пункт меню: "Останавливать систему когда протокол безопасности заполнен" (Halt system when security log is full). Настройка по С2, естественно, "Да". С точки зрения подсистемы аудита это, безусловно, правильно - протокол должен сохраняться всегда. А вот с точки зрения работоспособности системы?

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

Итак, многочисленными, но безвредными для системы запросами ее удалось "повесить". Зачем вам "нюки", господа кракеры, подарите ненавистному администратору утилиту C2Config!

Что самое забавное, в рекомендациях ВМФ США о безопасной инсталляции Windows NT 4.0 [4] пункт об остановке системы при переполнении протокола событий не рекомендуется разрешать! Что ж, здравомыслие иногда торжествует.

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

Человеческий фактор в криптосистемах (как, впрочем, и во всем остальном) играет особую и весьма заметную роль [3]. В частности, пользователи очень любят выбирать короткие и осмысленные пароли. Применив отрицание к последнему утверждению, получим, что пользователи не любят выбирать длинные или бессмысленные пароли. Ну а если некоторые характеристики паролей контролируются системой и "слабые" пароли не пропускаются? Проще всего проконтролировать длину пароля, а также совершить некоторые элементарные проверки - на совпадение с именем пользователя, с уже использованным паролем и т.п.

Итак, предположим, администратор установил нижнюю границу длину пароля в N символов. И недолго думая, взял и поставил N=15, полагая, что теперь-то ему атаки с перебором паролей совершенно не страшны.

Что же сделает пользователь? Пароль из 6 символов типа "A95jwh" он еще в состоянии запомнить, а вот требуемый от него 15-символьный "Rg27#kjs$Zyx83a" он уже не запомнит никогда (тем более, если он у него не один и время от времени меняется). Итак, у него есть два пути:

А вот последних паролей не так много. В 80% случаев это будут пароли типа "123456789012345", "aaaaaaaaaaaaaab", "svetasvetasveta", "qwertyuiop[]asd", "nuvy,blin,daete", "papauvasisilenv" - т.е. простые повторяющиеся комбинации, рядом стоящие символы на клавиатуре, припев популярной песенки и т.п. А такие пароли кракерам может быть легче вскрыть, чем бессмысленные 6-символьные.

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

Последний аспект коварства длинных паролей - их труднее набирать без ошибок. Ошибся несколько раз - и ... см. пример 1.

Важнейшей компонентой защиты распределенных вычислительных систем является шифрование информации, критичной к угрозе раскрытия, которая передается по открытым каналам связи (например, Internet).

Рассмотрим вероятность успеха одного подвида атаки, направленного на отказ в обслуживании. Он "состоит в передаче с одного адреса такого количества запросов на атакуемый объект, какое позволит трафик (направленный "шторм" запросов)" [6].

Допустим, что без использования методов шифрования трафика (т.е. без защиты от угрозы раскрытия), порог "шторма", при котором атакуемая система ничем другим не занимается, кроме как обрабатывает все новые и новые "плохие" запросы (и для "хороших" запросов эта система будет отказывать в обслуживании), равняется N запросов в секунду³. Вполне вероятно, что для хакера это N при низкопропускных каналах связи или значительной удаленности его от цели атаки будет недостижимым.

Теперь рассмотрим систему, защищенную от угрозы раскрытия применением методов шифрования. (Рассуждая с точки зрения эффективности, совершенно очевиден тот факт, что какими бы быстрыми не были применяемые криптографические алгоритмы, пропускная способность такой системы всегда будет меньше (обычно в 2-5 раз), чем системы без шифрования - т.к. пакеты нужно зашифровывать и расшифровывать). В этом случае хакер может несколько изменить свою атаку на шторм "псевдошифрованными" запросами. Допустим, криптографические алгоритмы вполне совершенны, и хакер не может подделать зашифрованный пакет так, чтобы он воспринимался как правильный 4. Но он вполне может подделать пакет так, чтобы он проходил первую (быструю) проверку "по внешнему виду" и поступал в процедуру расшифровки. И вот только она сможет его отвергнуть, расшифровав. Теперь уже совершенно очевидно, что система сможет обрабатывать значительно меньше запросов в секунду, чем N, из-за необходимости их расшифровки. А такое снижение N (до 2 порядков) вполне может привести к тому, что для хакера оно станет достижимым!

Так что же получается? Не надо менять свои пароли? Не надо использовать аудит? Не надо шифровать трафик? Или же сформулированный принцип "неповышения вероятности других угроз" невыполним? Я думаю, выполним. Просто при каждом решении, направленным на борьбу с некоторой угрозой, надо тщательно проанализировать, как это решение скажется на других угрозах. И, мне кажется, всегда можно найти более правильный вариант реализации решения. Фирме Novell надо было запрещать идентификацию при подборе паролей только с определенного сетевого адреса (или, еще лучше, всегда разрешать идентификацию с некоторого безопасного адреса). Администратору надо было поставить ограничение на длину пароля в 6 символов и объяснить, как придумывать и запоминать неосмысленные пароли. Регистрацией некоторых событий в протоколе придется жертвовать, если он переполнен и если безотказность системы важна. При реализации системы шифрования пакетов надо придумать некую схему, которая позволяла бы отвергать пакет без его (полной) расшифровки, сведя к минимуму количество необходимых для этого машинных операций.

Других обнадеживающим фактом я считаю, что все приведенные примеры не приводили к катастрофическим атакам, и, надеюсь, их не появится в будущем.

¹Вот один из последних, упоминаний о котором я не встречал. Windows NT можно настроить так, чтобы она не надоедала своим требованием нажать Ctrl+Alt+Del и ввести пароль, а делала это сама - например, с помощью программы Autologon Марка Руссиновича. Но при этом имя пользователя и его пароль будут хранится в реестре в открытом виде! Нужно ли говорить о том, что реестр иногда может быть просмотрен удаленно, а без установки Service Pack 3 это делается вообще элементарно!

²Знатоки Novell Netware не преминут меня подловить, сказав, что при смене пароля новое хэш-значение шифруется старым, и перехват его ничего не даст. А на это возражу, что в некоторых случаях, а именно, если пароль меняет супервизор через программу SYSCON, старое значение пароля у него не спрашивается.

^{3 Эксперименты
показывают, что для компьютера класса Pentium/166 это число равно
порядка 10000. Причем Windows NT (с установкой даже Service Pack
4) при шторме такой силы сбрасывалась в "синий экран".}

⁴А также стоит защита от посылки повторных пакетов.

Пример 1. Супервизор кусает локти.

Безопасность о двух концах.

Пример 2. Меняйте пароли чаще!

**Пример 3. Новый "нюк" (nuke) - система аудита Windows NT.**

Пример 4. Пароль больше - кракеру проще.

Пример 5. Шифрование сетевого трафика.

Резюме.