Защита от хакеров корпоративных сетей

В рассмотренном примере пилот характеризуется своим «индексом потенциального доверия». Его законное командование, возможно, знало его подноготную, но было уверено, что только оно осведомлено о «персональной энтропии» пилота, о которой никто из посторонних не должен был знать. Израильтяне бросили вызов «персональной энтропии», которая по существу является разделяемым ключом. Тем самым они создали предпосылку для манеры поведения, которая нарушила стандартную процедуру защиты. (Вообще, чем более разрушительным является запрос, тем более высоким должен быть уровень аутентификации, иначе любой может оказаться опасным. Для получения прав суперпользователя должны быть запрошены наиболее полные подтверждения легитимности пользователя.) Пилот был обманут. В этот день израильская разведка вернула на нем все потраченные на нее деньги. Рассмотренные методы доступа к пилоту были совершенны и основаны на звуковой речи. Что пилот мог сделать? Он мог бы потребовать, чтобы с ним по рации переговорила его жена, но ее голос мог быть заранее записан на магнитофон. Будучи достаточно подозрительным, он мог бы потребовать, чтобы его жена затронула тему, о которой могли знать только они вдвоем. В этом случае пилот и его жена могли знать, что голос легко узнать, но его трудно подделать, а тайны брака являются чем-то, что не является общедоступным даже случайно.

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

Утонченные фальсификации и экономический саботаж

Основное различие между фальсификацией и использованием уязвимости следующее. Использование уязвимости извлекает пользу из различия между тем, что есть на самом деле, и тем, что только кажется. А фальсификация извлекает пользу из разницы между тем, что кто-то что-то посылает, и тем, кто маскируется под отправителя сообщения. Это различие имеет большое значение, потому что наиболее мерзкие атаки фальсификации основаны на маскировке не только злоумышленника, но и самого факта атаки.

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

Лестью ничего не достичь

Это не только гипотетическая дискуссия. В 1991 году Microsoft была вынуждена реагировать на достижения операционной системы DR DOS, одного из удачливых клонов операционной системы MS DOS, которая серьезна подрывала позиции компании Microsoft. Грэм Леа (Graham Lea) из популярной технической бульварной малоформатной газеты The Register в прошлом году написал следующее (текст статьи можно найти по адресу www.theregister.co.uk/991105-000023.html. Статья доступна в кэше Google. На сайте издательства архив издания The Register за 1999 год ныне недоступен из-за реакции Microsoft на популярность операционной системы DR DOS):

...

«30 сентября 1991 года Дэвид Кол (David Cole) и Фил Барретт (Phil Barrett) обменялись электронной почтой, в которой говорилось: „Совершенно ясно, что следует обеспечить возможность запуска Windows 3.1 только под управлением MS DOS или ее OEM версии“ и, далее, „следует использовать подход, который позволит обнаружить версию dr 6 и отказать ей в загрузке Windows 3.1. При этом должно выдаваться сообщение типа „Недопустимый интерфейс драйвера устройства (Invalid device driver interface)““.

У компании Microsoft было несколько способов обнаружения и саботирования использования операционной системы DR-DOS, пытающейся загрузить Windows. Один из них был реализован в программном коде под именем Bambi. Этот код был написан Microsoft для утилиты организации дискового кэша SMARTDRV, которая после определения выполняющейся DR-DOS отказывалась загружать Windows 3.1. Также хорошо известна уловка, использовавшаяся в коде AARD, но в настоящее время Caldera занята разбирательством четырех других известных случаев преднамеренной несовместимости программных продуктов. Одно из них связано с версией XMS в программе установки Windows 3.1, которая выдавала сообщение «Установленный вами драйвер XMS несовместим с Windows. Следует удалить его прежде, чем программа установки сможет продолжить инсталляцию Windows». Конечно, для подобной деятельности у компании Microsoft не было никаких оснований.

Возможно, основания все-таки были. Бывший администратор Microsoft Брад Силверберг (Brad Silverberg) достаточно откровенно привел их: «Как вы думаете, что должен делать чувствующий дискомфорт пользователь, если он обнаруживает ошибки, подозревая при этом, что их причиной является DR-DOS? Он идет и покупает MS-DOS. Или решает не рисковать при покупке других машин в офис».

Компания Microsoft действовала явно, открыто давая понять о своем желании помешать совместной работе графической оболочки Windows и операционной системы DR-DOS (действительно, было итоговое сообщение AOL о совместной работе клиентов Instant Messenger). Но поскольку это могло привести к недовольству слишком большого числа пользователей, то они изменили тактику своих действий. Конечно, определенное давление со стороны клиентов вынудило бы Microsoft смягчить свою политику в отношении операционной системы DR-DOS, но реакции пользователей все равно не оказалось бы достаточной для обеспечения совместной работы DR-DOS и Windows. В конечном счете производитель DR-DOS утратил доверие на рынке компьютерных программ и ушел с него в соответствии с планом Microsoft.

Что позволило случиться этому? Прежде всего точным оказался злонамеренный расчет. Прямой отказ компании Microsoft поддержать выполнение операционной системой DR-DOS своих функций мог бы вызвать ряд серьезных вопросов, суть которых сводилась к следующему: каким образом две столь похожие друг на друга системы, как DR-DOS и MS-DOS, в конечном итоге оказались столь несовместимыми? Поэтому компания Microsoft приняла блестящее решение: прямо не отказывая DR-DOS в поддержке, представить DR-DOS невразумительной и ненадежной программой, недостойной претендовать на роль настоящей операционной системы. Действуя таким образом, Microsoft смогла обратить в свою пользу все выдвинутые против компании обвинения в бесстыдстве и завышенной стоимости своих продуктов, переложив ответственность на чужие плечи, причем сделано это было вовсе не для обширных исследований Caldera, которая в конечном счете купила DR-DOS. Информация на этот счет до сих пор не увидела свет. Это была блестящая победа.

Всюду поможет тонкость расчета

Случай с компанией Microsoft предоставил превосходную возможность проникнуть в суть экономически мотивированного саботажа и увидеть его проявления. Распределенные приложения и системы, как, например, информационно-справочные системы продажи билетов, очень трудно проектировать с соблюдением требований масштабируемости. Часто страдает стабильность их работы. Из-за чрезвычайных последствий выхода из строя подобных систем они должны быть проверены на способность противостоять скрытым и недоказуемым атакам, ставящим перед собой цель нарушить стабильность и безопасность систем, которые намериваются эксплуатировать, продавать или администрировать. Успех проверки определяется способностью системы к самообороне. Предположение, что пользователь всегда сможет отличить активную атаку от повседневных отказов систем, по меньшей степени является ложным, если не сказать больше.

Конечно, можно впасть в другую крайность и во всем подозревать злонамеренный умысел нападающих! Документально зарегистрировано более чем достаточно случаев, когда большие компании обвиняли в непонятных простоях мифических и удобных для них злоумышленников. (Фактическая причина отказов? Отсутствие плана действий при непредвиденных обстоятельствах, если обновление не было выполнено так, как надо.)

В некотором смысле это проблема обнаружения сигнала. Очевидные атаки легко обнаружить, но угроза тонкого искажения данных (которая, конечно, в общем случае при резервном копировании данных сохраняется, и поэтому для ее обнаружения требуется время) вынуждают поднять порог чувствительности намного выше. Фактически настолько высоко, что ложные атаки становятся реальностью. Компьютер потерял «нюх»? Стало ли причиной неприятностей то, что никогда не было введено (ошибка пользователя), некорректно представлено (ошибка клиента), неправильно записано (ошибка сервера), изменено или искажено при передаче по сети (сетевая ошибка, встречается разумно редко), или это результат активного и злонамеренного вмешательства?

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

Отказ для выборочного восстановления

Одним из наиболее общепринятых принципов построения компьютерных сетей является их последовательность. Компьютерные сети работают по ярко выраженным детерминированным законам, и проблемы в них возникают или постоянно, или их нет совсем. Поэтому приводит в бешенство тестирование ошибки, возникающей периодически каждые две недели, каждые 50 000 ± 3000 транзакций и т. д. Такие ошибки могут формировать в компьютерных сетях что-то похожее на взрывы гамма-лучей, превосходя по своему значению основные события в мире сетей. Периодические ошибки происходят так редко и проявляются в течение такого короткого периода времени, что трудно получить нужный протокол работы ядра или отладочную трассировку в момент ошибки.