Предупреждая о безопасности, автор хотел бы рассказать о чрезвычайной истории, произошедшей в результате нарушения новых законов. Это касается российской компании – разработчика программного обеспечения ElcomSoft Co. Ltd., специализирующейся на вскрытии паролей, снятии защиты от копирования и восстановлении поврежденных файлов. Имейте в виду, что на тот момент времени в России не было никакого закона против восстановления алгоритма работы программы по ее коду. Один из программистов компании ElcomSoft Co. Ltd., Дмитрий Скляров, прибыл на конференцию DEF CON 9 в Лас-Вегасе и сделал доклад относительно формата электронных документов eBook компании Adobe. Формат содержит некоторые смехотворные попытки безопасности. На следующий день Дмитрий был арестован и обвинен в «распространении изделия, предназначенного для обхода средств защиты авторского права». При этом упоминалась программа его компании, которая конвертировала формат eBook документа в стандартный формат Adobe Acrobat.PDF файлов. Выполнение подобного конвертирования покупателем одного из этих средств eBooks для себя юридически законно, поскольку пользователю разрешается делать резервные копии.
   Короче говоря, Дмитрий был арестован 17 июля 2001 года и отпущен домой только 31 декабря 2001 года. Компания Adobe отозвала свою жалобу из-за повсеместных протестов, но американское правительство отказалось снять обвинения. Поскольку вопрос не закрыт до сих пор, Дмитрий все еще полностью не освобожден от ответственности.
   Относительно сказанного хочется добавить, что используемые им методы для разгадывания системы безопасности изделия были относительно просты. Мы осветим подобные методы декодирования в главе 6.
   Пожалуйста, будьте осторожны с информацией, которая изложена в книге.

www.syngress.com/solutions, найдите адрес электронной почты авторов и пошлите им письмо. Возможно, ваше опровержение будет помещено на сайт.

www.lightlink.com/spacenka/fors.

www.microsoft.com/technet/columns/security/10imlaws.asp. Этот список приведен для иллюстрации подхода к теме с точки зрения администратора безопасности. По большей части читатель найдет, что приведенные законы – обратная сторона исследуемых авторами законов безопасности.
   Перед применением законов для обнаружения потенциальных проблем следует сформулировать их рабочее определение. В следующих разделах рассмотрены законы безопасности и их значение для обеспечения безопасности вычислительных сетей и систем.

www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/secur_c/scprt4/scencryp.htm#xtocid211509.
   Это – документ компании Cisco Systems, Inc., который описывает, помимо всего прочего, как обмениваться ключами стандарта цифровой подписи DSS. DSS – стандарт открытых/секретных ключей (public/private key standard), который Cisco использует для аутентификации одноранговых маршрутизаторов. Шифрование с использованием открытых/секретных ключей обычно считается слишком медленным для шифрования в реальном масштабе времени, поэтому для обмена информацией применяются симметричные сеансовые криптографические ключи (типа ключей DES или 3DES алгоритмов). DES – американский правительственный стандарт алгоритма шифрования, принятый в 70-х годах. 3DES – улучшенная версия алгоритма DES, связывающая вместе три отдельных выполнения алгоритма DES для двукратного или трехкратного, в зависимости от реализации, повышения криптостойкости алгоритма. Для успешной работы по описываемой схеме у каждого маршрутизатора должен быть правильный открытый ключ другого маршрутизатора. Если в случае атаки типа MITM злоумышленнику удастся обмануть каждый маршрутизатор, подсунув свой ключ вместо открытого ключа другого маршрутизатора, то сначала он сможет узнать все ключи сессии, а затем контролировать любой трафик сети.
   Cisco признает это и идет дальше, заявляя, что вы «должны устно проверить» открытые ключи. В документации описан сценарий, по которому два администратора маршрутизатора, имея безопасную связь с маршрутизатором (возможно, при помощи терминала, физически подключенного к консоли), связываются друг с другом по телефону. Во время обмена ключей они должны сообщить друг другу по телефону полученный ключ. Безопасность этого сценария основывается на предположении, что, во-первых, эти два администратора узнают голос друг друга, а во-вторых, трудно фальсифицировать чей-либо голос.
   Если администраторы хорошо знают друг друга и каждый из них сможет получить ответы на свои вопросы, если они оба зарегистрированы на консоли маршрутизаторов и маршрутизаторы не скомпрометированы, если нет ошибок в алгоритме шифрования, то эта процедура безопасна.
   Никто не собирается учить вас подражанию чьему-либо голосу или как захватывать коммутаторы телефонных компаний для неправильного соединения незнакомых друг с другом администраторов. В первую очередь критически разберем предположение о достижении безопасности при использовании двух администраторов и рассмотренного механизма безопасности.
   Есть подозрение, что вопреки документации компании Cisco большинство обменов ключами между маршрутизаторами этой компании осуществляются одним администратором с использованием двух Telnet-окон. Если дело обстоит именно так и если злоумышленник в состоянии сыграть роль «нарушителя посередине» и похитить Telnet-окна и ключевой обмен, то он сможет взломать зашифрованную передачу данных.
   Сформулируем выводы. Безопасность сети не может быть обеспечена в большей степени, чем безопасность наиболее уязвимого соединения. Если в нашем примере маршрутизатор может быть взломан и похищены секретные ключи, то не нужно никаких атак типа MITM. Кажется, в настоящее время компания Cisco уделяет большое внимание совершенствованию защиты секретных ключей. Их не могут просматривать даже уполномоченные администраторы. Однако ключи хранятся в памяти. Тот, кто захочет вскрыть маршрутизатор и воспользоваться той или иной разновидностью циклического опроса, сможет легко восстановить секретный ключ. К тому же до последнего времени в IOS Cisco не было проведено открытого изучения вопросов переполнения буфера и т. п. Авторы уверены, что когда-нибудь это произойдет, поскольку ряд известных нападений убедительно свидетельствует о возможности переполнения буфера.
   Другой способ реализации обмена заключается в использовании протокола SSL вашим браузером. При нормальном режиме обмена информацией, если от вас не запросили никакой информации, криптозащита должна быть отключена. Как в этом случае работает протокол SSL? Когда вы посещаете защищенную Wed-страницу, то от вас не требуется никаких действий по обеспечению безопасности. Подразумевает ли это, что SSL – жульничество? Нет, некоторая часть информации действительно используется совместно. Прежде всего это открытый ключ основного сертификата полномочий. Всякий раз, когда вы загружаете программное обеспечение браузера, оно активизирует встроенные в программу сертификаты. Эти сертификаты содержат необходимую информацию для обеспечения безопасности. Да, сохраняется вероятность атаки типа MITM во время загрузки файла. Если кто-то подпортил файл во время его нахождения на сервере, с которого файл был загружен, или во время загрузки по пути к вашему компьютеру, то теоретически весь ваш трафик по протоколу SSL может быть скомпрометирован.
   SSL особенно интересен, так как это один из лучших работающих образцов массового рынка средств обеспечения защиты, поскольку он управляет ключами и т. д. Конечно, протокол не без недостатков. Если вам интересны технические детали работы SSL, посетите сайт: www.rsasecurity.com/standards/SSL/index.html.