Ошибки
Обработка ошибок в протоколе соединений SSL весьма проста. Когда ошибка детектирована, обнаруживший его посылает своему партнеру сообщение. Ошибки, которые являются неустранимыми, требуют от клиента и сервера разрыва соединения. Серверы и клиент должны "забыть" все идентификаторы сессии, сопряженные с разорванным соединением. Протокол диалога SSL определяет следующие ошибки:
NO-CIPHER-ERROR
Эта ошибка присылается клиентом серверу, когда он не может найти шифр или размер ключа, который поддерживается также и сервером. Эта ошибка неустранима.
NO-CERTIFICATE-ERROR
Когда послано сообщение REQUEST-CERTIFICATE, эта ошибка может быть прислана, если клиент не имеет сертификата. Эта ошибка устранима.
BAD-CERTIFICATE-ERROR
Такой отклик присылается, когда сертификат по какой-то причине считается принимающей стороной плохим. Плохой означает, что, либо некорректна подпись сертификата, либо некорректно его значение (например, имя в сертификате не соответствует ожидаемому). Эта ошибка устранима (только для аутентификации клиента).
UNSUPPORTED-CERTIFICATE-TYPE-ERROR
Этот отклик присылается, когда клиент/сервер получает тип сертификата, который он не поддерживает. Эта ошибка устранима (только для аутентификации клиента).
Основные уязвимости
Начинать следует с выявления возможно намеренных или случайных уязвимостей:
Процессора ЭВМ
BIOS, контроллеров внешних устройств, интерфейсов и пр.
Программного обеспечения ОС
Прикладного программного обеспечения, включая программы защиты
Программное обеспечение аппаратных сетевых устройств и систем аутентификации
Сетевые протоколы и их программные реализации
Первые два пункта крайне важны, именно с обеспечения неуязвимости этих объектов следовало бы начинать разработку комплексной системы безопасности. К сожалению это пока не достижимо по финансовым и технологическим причинам. Остальные позиции являются объектами различных этапов данного проекта.
Отсутствие аутентификации
Простейшая аутентификационная система не имеет аутентификации вовсе. Изолированная от сети частная персональная ЭВМ является примером, где аутентификация не нужна. Другим примером может служить автономная общедоступная рабочая станция, обслуживающая некоторые конференции, где раскрытие информации или ее модификация не являются критическими.
Пересылка файлов (FTP, TFTP)
FTP и TFTP позволяют пользователям получить и послать файлы в режиме точка-точка. Однако FTP требует аутентификации, в то время как TFTP нет. По этой причине TFTP следует по возможности избегать.
Неправильно сконфигурированные FTP-серверы могут позволить атакеру копировать, заменять и удалять файлы по своему усмотрению, так что очень важно конфигурировать этот вид услуг корректно. Доступ к шифрованным паролям и частным данным, и введение троянских коней являются лишь небольшой долей возможных неприятностей, которые могут случиться при неправильной конфигурации. FTP-серверы должны размещаться на своих собственных машинах. Некоторые узлы помещают FTP и Web-серверы на одной ЭВМ, так как оба протокола имеют схожие требования безопасности. Однако практика этого не рекомендует, особенно когда FTP-сервис позволяет записывать файлы (смотри раздел WWW выше). Как было упомянуто в начальных параграфах раздела 3.2.3, услуги, предоставляемые внутренним пользователям узла не должны соседствовать с услугами, предлагаемыми для внешних клиентов. Каждый вид услуг должен иметь свою ЭВМ.TFTP не поддерживает тот же список функций, что и FTP, и не имеет вообще никакой защиты. Эта услуга должна рассматриваться исключительно для внутреннего использования, и она должна конфигурироваться так, чтобы доступ был возможен к ограниченному и предопределенному набору файлов. Вероятно, большинство применений TFTP сопряжено с загрузкой конфигурационных файлов в маршрутизатор. TFTP должен размещаться на своей собственной ЭВМ, и не должен устанавливаться на машины, поддерживающие внешнийFTP или Web-доступ.
Почтовые списки и другие ресурсы
Было бы невозможно перечислить все почтовые подписные листы и другие ресурсы, имеющие отношения к безопасности. Однако ссылки, названные ниже, являются стартовыми точками, с которых читатель может начать. Все эти ссылки предназначены для клиентов ИНТЕРНЕТ. Некоторые специфические ресурсы (производители и географические адреса) могут быть найдены через представленные ниже ссылки.
Почтовые подписные листы
|
(1) |
Консультация CERT (TM) |
Посылайте почтовое сообщение по адресу: cert-advisory-request@cert.org. В теле сообщения надо написать: subscribe cert <FIRSTNAME> <LASTNAME>. Консультация CERT предоставляет информацию о том, как получить поправку (patch) к программе или подробности того, как обойти какую-то известную проблему безопасности. Координационный центр CERT работает с поставщиками, чтобы предоставлять нужные коррекции программ или методики для решения задач безопасности, и не публикует ничего об известных уязвимостях до тех пор, пока не будут найдены средства их защиты. Консультация CERT может также выдавать предупреждения клиентуре о возможных атаках (например, "CA-91:18.Active.Internet.tftp.Attacks").
Консультации CERT публикуются в группе новостей USENET: comp.security.announce.
Архивы консультации CERT доступны посредством анонимного FTP по адресу info.cert.org в каталоге /pub/cert_advisories.
|
(2) |
VIRUSL-List |
Посылайте почтовое сообщение по адресу: listserv%lehiibm1.bitnet@mitvma.mit.edu Тело сообщения: subscribe virus-L FIRSTNAME LASTNAME
VIRUS-L является почтовым подписным листом, работающим через посредника, и посвященным проблеме компьютерных вирусов. За дополнительной информацией рекомендуется обращаться к файлу "virus-l.README", доступному через анонимный FTP по адресу cs.ucr.edu.
|
(3) |
Интернет Сетевые экраны. Посылайте почтовое сообщение по адресу: majordomo@greatcircle.com Тело сообщения: subscribe firewalls user@host |
Подписные листы по сетевым экранам являются дискуссионным форумом для администраторов и программистов.
Группы новостей USENET
(1) | comp.security.announce | Группа новостей comp.security.announce работает через посредника и используется только для рассылки рекомендаций CERT. |
(2) | comp.security.misc | comp.security.misc является форумом для обсуждения компьютерной безопасности, особенно если это относится к ОС UNIX(r). |
(3) | alt.security | Группа новостей alt.security является также форумом для обсуждения компьютерной безопасности, и других вопросов, таких как замки автомашин и охранные системы. |
(4) | comp.virus | Группа новостей comp.virus работает через посредника и нацелена на компьютерные вирусы. Дополнительную информацию смотри в файле "virus-l.README", доступном через анонимный FTP по адресу info.cert.org в каталоге /pub/virus-l. |
(5) | comp.risks | Группа новостей comp.risks является форумом, работающим через посредника, посвященным рискам при работе с ЭВМ и смежным темам. |
(1) | http://www.first.org/ |
(2) |
(3) |
(4) |
Подавление
Когда факт инцидента установлен, наступило время ликвидации последствий и причин. Но прежде чем устранять причины, должны быть приняты меры по сбору всей необходимой информации о компрометированных системах и причинах инцидента, так как эти данные будут потеряны после полной очистки системы.
Помощь в ликвидации причин и последствий инцидента могут оказать специальные программы, такие, например, как антивирусные. Если атакером были созданы какие-либо файлы, архивируйте их прежде чем уничтожать. В случае вирусного заражения важно очистить и повторно отформатировать среду, содержащую инфицированные файлы. Наконец, убедитесь, что все резервные копии не содержат зараженных файлов. Многие системы, инфицированные вирусами, повторно заражаются просто потому, что народ своевременно не удаляет вирусы с контрольных копий. После ликвидации причин и последствий следует сформировать новые контрольные копии (backup).
Удалить все уязвимости после инцидента достаточно трудно. Ключевым моментом при ликвидации слабостей системы является понимание характера уязвимостей.
Может быть, необходимо взять исходный дистрибутив и заново сформировать систему. Чтобы облегчить наихудший сценарий следует записать установочную конфигурацию системы и каждое изменение конфигурации. В случае сетевой атаки важно инсталлировать все коррекции программ (patches) для каждой уязвимости операционной системы, которая может быть использована для атаки. Как это описано в разделе 5.4.2, журнальные записи безопасности могут оказаться наиболее ценными на фазе ликвидации уязвимостей. Журнальные записи показывающие, как инцидент был обнаружен и локализован, могут быть полезны позднее, чтобы помочь определить насколько велик был ущерб от данного инцидента. В идеале, следует автоматизировать и регулярно использовать тест для выявления инцидентов, сопряженных с безопасностью.
Если конкретная уязвимость локализована, следующим шагом является нахождения механизмов защиты системы. Информацию для решения этой проблемы можно найти с помощью тематических подписных листов и бюллетеней, целесообразно проконсультироваться в группах по ликвидации последствий инцидентов.
Подготовка и планирование обработки инцидентов
Часть мер в случае инцидента должна быть подготовлена до того, как инцидент произойдет в первый раз. Это включает установку приемлемого уровня защиты, как это было описано в предыдущих главах. Выполнение этого поможет вам избежать инцидентов в вашем узле, а также сократить потенциальный ущерб, вызванный атакой, если она действительно произойдет. Защита включает в себя также перечень мер в случае непредвиденного инцидента в вашей организации или узле. Наличие написанных планов исключит многие неопределенности, которые могут возникнуть в случае инцидента, и приведет к более адекватному и исчерпывающему перечню действий. Жизненно важно проверить предлагаемый план до того как произойдет настоящий инцидент на пробном прогоне. Команда может даже рассмотреть наем атакующей группы, которая будет работать в параллель с пробным прогоном. (атакующая группа - это команда специалистов, которые пытаются вторгнуться в систему безопасности). Обучение эффективному реагированию на вторжение является важным по многим причинам:
|
(1) |
Защита объектов, которые могут быть компрометированы |
|
(2) |
Защитные ресурсы, которые могли бы быть использованы с большей пользой, если инцидент не требует их услуг |
|
(3) |
Выполнение регламентаций (правительственных или других) |
|
(4) |
Предотвращение использования ваших систем в атаках против других систем (которые могут навлечь на вас юридическую ответственность) |
|
(5) |
Минимизация потенциала негативных проявлений |
При любом наборе предварительно спланированных мер, эти меры могут иметь разные приоритеты в разных узлах. Рассмотрим набор типовых мер, которые должны быть предприняты в связи с инцидентом:
|
(1) |
Описать, как это произошло. |
|
(2) |
Выяснить, как избежать дальнейшего использование тех же самых уязвимостей. |
|
(3) |
Исключить последствия и будущие инциденты. |
|
(4) |
Оценить воздействие и ущерб от инцидента. |
|
(5) |
Восстановить систему после инцидента. |
|
(6) |
Обновить политику и процедуры, как это требуется. |
|
(7) |
Найти, кто это сделал (если это возможно). |
В силу природы инцидента может иметь место конфликт между анализом источника проблемы и восстановлением систем и услуг.
Общие задачи ( типа обеспечения целостности критических систем) может стать причиной отказа от анализа инцидента. Конечно, это важное управленческое решение, но все вовлеченные лица должны понимать, что без анализа тот же самый инцидент может повториться.
Важно также определить заранее приоритет действий при инциденте. Иногда инцидент может быть настолько сложным, что невозможно, реагируя на него, сделать все сразу; приоритеты в этом случае крайне важны. Хотя приоритеты варьируются от организации к организации, ниже предложенные приоритеты могут служить отправной точкой для определения реакции вашей организации:
(1) | Приоритет номер один – защитить человеческую жизнь и безопасность людей; человеческая жизнь имеет всегда приоритет перед любыми другими соображениями. |
(2) | Приоритет два -- защитить категорированные и/или важные данные. Предотвратить использование категорированных и/или важных систем, сетей или узлов. Информировать подвергшиеся атаке категорированные и/или важные системы, сети или узлы об уже случившемся вторжении. (Ознакомьтесь с регламентациями вашего узла или правительства) |
(3) | Приоритет три – защита остальной информации, включая частную, научную, управленческую и прочую, так как потеря данных стоит дорого с точки зрения ресурсов. Предотвратить использование других систем, сетей или узлов и проинформировать уже затронутые системы, сети или узлы об успешном вторжении. |
(4) | Приоритет четыре – предотвращение разрушения систем (например, потерю или модификацию системных файлов, разрушение драйвов дисков и т.д.). Разрушение систем может вызвать дорогостоящие отказы и длительное восстановление. |
(5) | Приоритет пять – минимизировать урон вычислительных ресурсов (включая процессы). Во многих случаях лучше закрыть систему или отключить ее от сети, чем рисковать данными или системой. Узлы должны будут сопоставить возможности закрытия, отключения и сохранения открытого состояния. Может существовать локальное соглашение обслуживания, которое требует поддержания системы в подключенном состоянии даже с учетом возможности дальнейшего разрушения. Однако ущерб и область воздействия инцидента могут быть настолько значительны, что соглашение обслуживания может быть пересмотрено. |
Важным выводом для определения приоритетов является то, что, если затронуты вопросы человеческой жизни и национальная безопасность, более существенным оказывается сохранение данных, чем системное программное обеспечение и оборудование. Хотя в случае инцидента нежелательно иметь любой ущерб или потерю, системы могут быть замещены. Однако, потеря или компрометация данных (особенно категорированных или частных) обычно не может быть приемлемым при любых обстоятельствах.
Другой важной вещью является влияние на другие системы и сети, где имел место инцидент. В пределах ограничений, установленных правительственными регламентациями всегда важно проинформировать вовлеченные стороны как можно быстрее. Благодаря юридическим обстоятельствам этой темы это обязательно учтено в планируемых операциях, чтобы исключить дальнейшие задержки и неопределенности для администраторов.
Любой план реагирования на инцидент, нарушающий безопасность, должен регулироваться локальной политикой и регламентациями. Правительственные и частные узлы, имеющие дело с категорированным материалом, имеют специфические правила, которым они должны следовать. Политики, выбранные вашим узлом и сопряженные с тем, как реагировать на инцидент, будут определять ваши действия. Например, может уделяться мало внимания созданию механизмов мониторирования и отслеживания атакеров, если ваш узел не планирует действий против них в случае поимки. Другие организации могут иметь политики, которые окажут влияние на ваши планы. Телефонные компании часто выдают информацию об отслеживании телефонных звонков только юридическим силовым агентствам.
Обработка инцидентов может быть утомительным и потребует значительного числа действий от обслуживающего сеть персонала. Чтобы освободить технический персонал, может быть полезным определить круг лиц, кто будет помогать в решении таких задач как фотокопирование, отправка факсов и т.д.
Политика должна быть гибкой
Для того чтобы политика безопасности была жизнеспособна в долгосрочном плане, она требует большой доли гибкости, основанной на концепции архитектурной безопасности. Политика безопасности должна быть по большей части независимой от специфического оборудования и программного обеспечения. Механизмы актуализации политики должны быть четкими и понятными. Это включает процесс, вовлеченных людей и лиц, кто должен реализовать изменения.
Важно также понимать, что существуют исключения для любого правила. Всякий раз, когда возможно, политика должна разъяснять, какие исключения существуют для общей политики. Например, при каких условиях системному администратору позволено просматривать файлы пользователя. Могут также существовать случаи, когда несколько пользователей имеют доступ к одному и тому же идентификатору userid. Например, в системах с пользователем root, несколько системных администраторов могут знать пароль и использовать аккаунт root.
Другое соображение называется "Garbage Truck Syndrome" (синдром мусоровоза). Это относится к тому, что может произойти с сайтом, если ключевое лицо неожиданно становится недоступным для выполнения его/ее рабочих функций (например, неожиданно заболело или покинуло компанию). В то время как максимальная безопасность требует минимального распространения информации, риск потери критической информации увеличивается, когда данные не носят распределенного характера. Важно определить, какой баланс является приемлемым для вашего узла.
Политики безопасности
В данном документе будет много ссылок на политики. Часто эти ссылки будут содержать рекомендации для специфических политик. Читателю следует использовать советы, содержащиеся в данной главе, при формировании любой политики, которые будут рекомендованы далее в данном документе.
Полностью определенные планы безопасности
Все узлы должны определить всеобъемлющий план обеспечения безопасности. Этот план должен охватывать более высокий уровень, чем политики, обсужденные в главе 2, и он должен рассматриваться в качестве базы для широкого перечня инструкций, которым должны соответствовать специфические виды политики.
Важно иметь этот перечень в таком виде, чтобы индивидуальные политики могли быть совместимы с общей архитектурой безопасности узла. Например, жесткая политика в отношении к доступу в Интернет и слабые ограничения на использование модемов не согласуются с общей философией жестких ограничений на безопасность внешнего доступа.
План безопасности должен определять: список предоставляемых сетевых услуг; области организации, которые эти услуги предоставляют; кто будет иметь доступ к этим услугам; как осуществляется доступ; кто администрирует эти услуги и т.д. План должен рассматривать то, какова будет реакция на инцидент. Глава 5 содержит всестороннее обсуждение этой темы, но важно определить для каждого узла классы инцидентов и соответствующие меры противодействия. Например, узлы с сетевым экраном устанавливают порог на число попыток прохода, прежде чем будет запущен отклик? Должны быть определены уровни эскалации, как для атак, так и для откликов. Узлы без сетевого экрана должны определить, является ли инцидентом одиночная попытка соединиться с ЭВМ? Что делать с систематическим сканированием системы?
Для узлов, подключенных к Интернет, стремительно расширяющаяся среда Интернет в отношении числа инцидентов безопасности может замаскировать (потенциально) более серьезные внутренние проблемы безопасности. Аналогично, компании, которые никогда не подключались к Интернет, могут иметь сильные, хорошо определенные внутренние политики, но терпят неудачу в формировании адекватной политики внешних подключений.
Последствия инцидента
В связи с инцидентом нужно предпринять ряд действий. Эти действия перечислены ниже:
|
(1) |
Должна быть проведена инвентаризация всех повреждений (т.e., в результате тщательного осмотра должно быть определено, насколько система пострадала от инцидента). |
|
(2) |
Чтобы исключить возможность такого вторжения, план безопасности должен быть скорректирован с учетом опыта, извлеченного после инцидента. |
|
(3) |
С учетом данного инцидента должен быть произведен новый анализ рисков. |
|
(4) |
Расследование и наказание лиц, виновных в инциденте, если это считается желательным. |
Если инцидент явился результатом неудачной политики безопасности, и если политика не изменена, тогда повторение инцидента неизбежно. Как только узел оправился после инцидента, политика узла и процедуры должны быть тщательно рассмотрены и в них должны быть внесены изменения, чтобы предотвратить подобные инциденты в будущем. Даже в отсутствии инцидентов, представляется разумным пересматривать политику и процедуры на регулярной основе. Эти пересмотры обязательны с учетом современных изменений компьютерной среды.
Правила безопасности для пользователей
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
В 1997 году одна из подгрупп IETF выпустила справочник Site Security Handbook (RFC-2196). В нем содержатся рекомендации системным администраторам по разнообразным вопросам защиты сети, правилам использования и методике работы. Этот документ предлагает включить в правила следующие разделы: Рекомендации по закупке оборудования и программного обеспечения. Участие системных администраторов в выборе оборудования и программного обеспечения может оказать большую пользу, так как часто они знают о его недостатках и ограничениях то, чего не афишируют продавцы и производители.Политика секретности. Устанавливает степень контроля над почтой и действиями пользователей, а также политику размещения пользовательских файлов.Политика доступа. Определяет, кто может иметь доступ в систему, что можно делать в рамках этих прав доступа, какое программное обеспечение можно установить и пр. Данный документ должен включать те же меры предосторожности относительно авторизации доступа и степени контроля, что и политика секретности.Политика учетных записей. Содержит описание прав и обязанностей пользователей и системных администраторов.Политика аутентификации. Устанавливает правила использования паролей и порядка лишения доступа.Политика доступа. Определяет, в какое время система должна быть доступна, содержит расписание обслуживающих мероприятий, перечень действий при появлении проблем, а также инструкции по документированию проблем и оповещению о них администраторов и ориентировочное время их устранения.Политика управления. Устанавливает правила общения с внешним миром и порядок доступа для приглашенных из других организаций специалистов.
Правила для пользователей
В правилах для пользователей необходимо регламентировать следующие вопросы: Использование учетных записей совместно с друзьями и родственниками.Выполнение программ дешифрования паролей для расшифровки локального файла passwd, например, с помощью программы crack.Выполнение программ дешифрования паролей для расшифровки файлов passwd других систем.Нарушение нормального процесса обслуживания.Проникновение в чужие учетные записи.Неправильное использование электронной почты.Просмотр файлов других пользователей (есть ли возможность чтения? записи? одобряется ли?)Публикации в UseNet (запрещены? с оговорками? разрешены?)Импорт программ из Интернет (запрещен? разрешен? разрешен с оговорками?)Использование системных ресурсов (принтеров, дисков, модемов, процессора).Копирование лицензионного программного обеспечения.Выдача разрешений на копирование лицензионного программного обеспечения другим лицам.Копирование защищенных авторскими правами материалов (музыки, фильмов и пр.).Всевозможная незаконная деятельность: мошенничество, клевета и др.Вовлечение в деятельность, которая является запрещенной (например, порнография)
Примером соглашения для доступа к компьютерам может служить документ такого рода для факультета информатики университета Мельбурна. Смотри также .
Я, нижеподписавшийся, настоящим объявляю, что буду придерживаться приведенных ниже правил: Я буду использовать возможности компьютеров и сети факультета исключительно для учебных целей, относящихся к моему обучению информатике.Я знаю, что факультет предоставляет регистрационное имя для его использования исключительно получателем. По этой причине я не буду способствовать использованию моей учетной записи и файлов другими лицами и сообщать свой пароль кому бы то ни было.Я не буду осуществлять доступ или попытку доступа ни к одному компьютеру, регистрационной записи, сети или файлу без соответствующего и явного разрешения. Такой доступ является незаконным и противоречит университетским правилам. Если мне станет известно, что такой доступ имел место, я немедленно проинформирую об этом руководство факультета.Я знаю, что некоторые программы и данные, находящиеся в файловой системе, могут быть защищены законом об авторских правах и другими законами или лицензионными соглашениями.
Я не буду нарушать накладываемые ими ограничения.Я не буду использовать университетские ресурсы для получения, разработки, запуска и распространения нелицензионного программного обеспечения.Я обязуюсь сохранять конфиденциальность любых полученных мною от университета сведений о программном обеспечении (включая методы и принципы его использования), лицензионном для использования на ЭВМ университета, и тем самым обезопасить университет от претензий любого рода, связанных с разглашением этой информации.Я обязуюсь проявлять предельную честность и порядочность во всех вопросах, связанных с использованием компьютерных и сетевых возможностей университета, которые могут повредить репутации факультета или университета.Я понимаю, что действия, противоречащие изложенным выше принципам, повлекут за собой жесткие взыскания, включая отказ в изучении темы или предмета, временный запрет или лишение доступа к университетским вычислительным средствам, временное или полное исключение из университета, штраф и/или другие действия, предусмотренные Crimes Computer Act (этот закон действует в Австралии, но аналогичные законы имеются во многих других странах) 1988 года
Обратите внимание на неоднозначные слова о честности, порядочности и необходимости беречь репутацию университета. Подобные требования общего характера помогают охватить вопросы, которые трудно описать строгими детерминированными правилами. И хотя юридическая сила таких требований невелика, все же полезно их включить во внутренние правила компании или учреждения. Заверенная расписка пользователя о согласии следовать перечисленным правилам является юридическим документом и может использоваться в суде. Обязательно нужно проинформировать всех пользователей, что сам факт использования учетной записи, равносилен согласию соблюдать установленные правила. Должно быть известно, где можно ознакомится с правилами. Следует иметь в виду, что не имеющие юридической силы и противоречивые правила - хуже, чем их отсутствие.
Здесь нет ни слова об использовании программ сканирования, рассылки сообщений содержащих “троянских коней” или вирусы, попыток взлома защиты серверов и пр.
Это все преступления, которые обычно регламентируются уголовным кодексом. И следует учитывать, что оправдания типа, я решил просто посмотреть, как работает такая программа из любопытства и т.д., не могут служить оправданием. Полагаю, никто не воспримет серьезно оправдание вроде: “Я хотел лишь проверить, работает ли этот гранатомет, у меня и в мыслях не было разносить вдребезги эту бензоколонку…”
Не нужно думать, что права системных администраторов не ограничиваются ничем. Если системный администратор злоупотребляет своими полномочиями, им следует подобрать другую работу. Если специфика работы требует наличия нескольких администраторов, пароль root помещается в конверт, а конверт в сейф. Администраторы же пользуются программой sudo. Если в какой-то момент времени кому-то потребуется пароль root, конверт извлекается из сейфа, и после завершения операции пароль заменяется.
Рекомендуется помещать в файл /etc/motd (сообщение дня) предупреждение о действующих у вас правилах. Предупреждение должно содержать перечень мер, которые будут предприняты, при несоблюдении правил (удаление учетной записи, размер штрафа или уголовная ответственность).
При отсутствии идентификатора сессии
| Client-hello | C ® S: | challenge, cipher_specs |
| server-hello | S ® C: | connection-id,server_certificate,cipher_specs |
| client-master-key | C ® S: | {master_key}server_public_key |
| client-finish | C ® S: | {connection-id}client_write_key |
| server-verify |
S ® C: | {challenge}server_write_key |
| server-finish |
S ® C: | {new_session_id}server_write_key |
генерации экспортного ключа
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 требует пяти случайных байт для каждого из двух ключей шифрования и 16 байт для каждого ключа MAC, что составляет 42 байта ключевого материала. Выход PRF запоминается в key_block. Блок key_block делится, а ключи записи запоминаются, так как это алгоритм экспортного шифрования.
| key_block | = PRF(master_secret, |
| "key expansion", | |
| server_random + | |
| client_random)[0..41] | |
| client_write_MAC_secret | = key_block[0..15] |
| server_write_MAC_secret | = key_block[16..31] |
| client_write_key | = key_block[32..36] |
| server_write_key | = key_block[37..41] |
| final_client_write_key | = PRF(client_write_key, |
| "client write key", | |
| client_random + | |
| server_random)[0..15] | |
| final_server_write_key | = PRF(server_write_key, |
| "server write key", | |
| client_random + | |
| server_random)[0..15] | |
| iv_block | = PRF("", "IV block", client_random + |
| server_random)[0..15] | |
| client_write_IV | = iv_block[0..7] |
| server_write_IV | = iv_block[8..15] |
Проблемы
Фильтрация такого рода имеет шансы разрушить некоторые виды "специфических" услуг. В интересах сервис провайдеров, предлагающих такие услуги, рассмотреть альтернативные методы предоставления такого рода услуг, чтобы не страдать от входной фильтрации трафика. Мобильный IP, как это определено в [6], подвержен воздействию входной фильтрации трафика. Как это специфицировано, трафик к мобильному узлу туннелируется, но трафик от мобильного узла не туннелируется. Это приводит к тому, что в пакетах, посылаемых мобильным узлом, адрес отправителя не соответствует сети, к которой он подключен. Чтобы согласовать входную фильтрацию с другими соображениями, Рабочая группа Мобильного IP разработала методологию "реверсивных туннелей", специфицированную в [7]. Там предлагается метод передачи данных, посылаемых мобильным узлом, через туннель “домашнему агенту” до передачи информации в Интернет. У схемы реверсных туннелей существуют дополнительные преимущества, включая лучшую обработку мультикастного трафика. Такие реализации мобильных IP-систем располагают к использованию метода реверсных туннелей.
Как было упомянуто ранее, как входная фильтрация трафика существенно сокращает вероятность успешных атак с фальсифицированными адресами отправителя, это не мешает атакеру использовать реальные адреса других ЭВМ. Это, однако, гарантирует, что в случае действительной реализации такой атаки, сетевой администратор может быть уверен, что она осуществлена из одного ил анонсированных префиксов. Это упрощает отслеживание виновника, и в худшем случае, администратор может блокировать диапазон адресов отправителя до тех пор, пока проблема не будет решена.
Если используется входная фильтрация в среде, где работает DHCP или BOOTP, сетевому администратору рекомендуется предоставить возможность пакетам с адресом отправителя 0.0.0.0 и адресом получателя 255.255.255.255 доходить до соответствующего сервера. Область направленного бродкаста должна контролироваться, произвольная переадресация таких пакетов недопустима.
Процесс сбора данных
Процесс сбора должен осуществляться ЭВМ или ресурсом, к которому производится обращение. В зависимости от важности данных и необходимости их иметь под рукой в моменты, когда происходит отказ в обслуживании, информация может храниться локально или передаваться в память после каждого события.
В основном существует три способа запоминания контрольной информации: в файлы чтения/записи на ЭВМ, в устройствах с однократной записью (например, CD-ROM или специально сконфигурированный привод магнитной ленты), или с помощью аппаратуры записи типа строчного принтера. Каждый метод имеет преимущества и недостатки.
Система журнальных файлов является наименее ресурсоемкой из названных методов и наиболее легко конфигурируемой. Она позволяет немедленный доступ к записям для анализа, который может быть важным в момент атаки. Система журнальных файлов является также наименее надежным методом. Если ведущая журнал ЭВМ компрометирована, файловая система является первым объектом, подвергаемым атаке; атакер без труда может скрыть следы своего вторжения.
Сбор контрольных данных с помощью устройства с однократной записью требует несколько больших усилий по конфигурации, чем журнальные файлы, но имеет значительное преимущество большей безопасности, так как атакер не сможет ликвидировать следы своего вторжения. Недостатком этого метода является необходимость поддержания такого устройства и стоимость.
Ведение журнала с помощью строчного принтера является полезным, когда нужен постоянный и немедленный доступ к журналам состояния системы. Примером могут служить системы реального времени, где должна быть записана конкретная точка отказа или атаки. Лазерный принтер или другое устройство, которое буферизует данные (например, сервер печати), может страдать от потери данных, если буферы содержат нужные данные в критический момент. Недостатком такого способа документирования является необходимость постоянно поддерживать принтер в состоянии готовности (бумага, другие расходуемые материалы), а также ручной просмотр записей. Существует также вопрос, где хранить огромные объемы распечаток, накапливающиеся со временем.
Для каждого из описанных методов ведения журналов, существует также проблема обеспечения безопасности канала между устройством, генерирующем журнальные записи, и записывающим прибором (т.e., файл-сервером, магнитофоном/CD-ROM драйвом, принтером). Если этот путь скомпрометирован, формирование журнальных записей может быть остановлена или фальсифицирована. В идеале устройство записи журналов событий должно быть подключено с помощью одного простого кабеля по схеме точка-точка. Так как обычно это не практично, маршрут подключения должен проходить через минимальное число сетей и маршрутизаторов. Даже если журналы могут быть блокированы, фальсификация может быть предотвращена посредством криптографических контрольных сумм (вероятно, не нужно шифровать журнальные записи, так как они не содержат критической информации).
Противодействие
Целью противодействия является ограничение масштабов развития атаки. Существенной частью противодействия является принятие решения (например, определение, следует ли выключить систему, отключить ее от сети, мониторировать систему или сетевую активность, установить ловушки, закрыть функции, такие как удаленная передача файлов и т.д.).
Иногда это решение тривиально - выключить систему, если информация категорирована, чувствительна или является частной. Учтите, что аннулирование всякого доступа при инциденте обращает на себя внимание всех пользователей, включая подозреваемых, что может иметь вредное воздействие на расследование. В некоторых случаях, разумно ликвидировать все виды доступа или функциональность так быстро, как только возможно, а затем поэтапно восстановить нормальную работу. В других случаях, имеет смысл рискнуть, если сохранение системы в рабочем состоянии поможет идентифицировать виновника инцидента.
Этот этап должен включать в себя выполнение определенных заранее процедур. Ваша организация или узел должны, например, определить приемлемые риски в ходе преодоления последствий инцидента, и предложить соответствующие действия и стратегии. Это особенно важно, когда необходимо быстрое решение и невозможно при первом контакте заинтересованных сторон обсудить возможное решение. В отсутствии определенных заранее процедур лицо, ответственное за ликвидацию последствий инцидента, не имеет полномочий принимать сложные управленческие решения (вроде потери результатов сложного эксперимента при отключении системы). Данный этап завершается оповещением всех заинтересованных полномочных представителей.
Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Протокол Нидхэма-Шрёдера предназначен для решения проблемы аутентификации (см., например, , , а также [1]). Протоколу уже более 20 лет. Алгоритм предназначен для организации аутентифицированного канала между разными ЭВМ в сети по схеме точка-точка. Задача решается с помощью одного или двух серверов аутентификации с использованием общедоступных или общих секретных ключей. Данный протокол предоставляет децентрализованную услугу аутентификации.
Операция аутентификации может охватывать несколько процессов.
Установление виртуального канала двунаправленного обмена сообщениями между двумя субъектами, работающими на разных ЭВМ.
Установление однонаправленного обмена, который, например, имеет место при отправке почты. Здесь ситуация осложняется тем, что субъекты могут не быть одновременно доступны через сеть и не могут непосредственно обмениваться сообщениями.
Коммуникация, при которой источник информации и ее целостность может гарантироваться третей стороной.
Безопасная передача данных по сети, которая сама не является безопасной, предполагает шифрование передаваемой информации. Будем предполагать, что каждая из сторон, участвующих в обмене, способна шифровать и дешифровать данные. Протокол Нидхэма-Шрёдера может работать как для симметричной, так и несимметричной схем шифрования (с общим секретным ключом и с двумя парами ключей, соответственно). Будем также считать, что злоумышленник может подключить свою ЭВМ в любую точку пути, по которому происходит обмен и, таким образом, способен перехватить, воспроизвести или исказить любое сообщение. ЭВМ же субъектов обмена и сервер аутентификации предполагаются защищенными от вторжения.
Сервер аутентификации может предоставить идентификационную информацию, вычисляемую на основе секретного ключа субъекта аутентификации. Сначала рассмотрим вариант с использованием симметричного шифрования/дешифрования (один ключ).
При схеме шифрования с одним ключом, предполагается, что секретный ключ известен обоим субъектам обмена (А и В) и серверу аутентификации.
Инициатором обмена будем считать субъекта А. Сообщения, посылаемые от А к В, могут быть дешифрованы только В и субъект В должен быть уверен, что сообщение пришло именно от А. В начале предположим, что оба субъекта находятся в области действия общего сервера аутентификации (AS). AS знает секретные ключи субъектов А и В (KA и KB, соответственно).
Обмен начинается с того, что субъект А генерирует свой идентификатор IA1, который будет использоваться только один раз. Первое сообщение, посылаемое от A к AS, содержит:
A® AS: | (A, B, IA1) | (1) |
A® AS: | (A, B, IA1)KA | (1.1) |
Далее AS посылает субъекту А следующее сообщение:
AS® A: | (IA1, B, CK, {CK, A}KB)KA | (1.2) |
Так как выражение (IA1, B, CK, {CK, A}KB) зашифровано ключом КА, то только субъект А может его дешифровать и прочесть. Субъект А проверяет наличие идентификатора IA1 (это подтверждает то, что данное сообщение является откликом на сообщение А), и имени субъекта, с которым А намерен обмениваться данными (В). В результате дешифровки сообщения от AS А получает во владение рабочий ключ СК. Наличие В в сообщение является обязательным. В противном случае злоумышленник может заменить В на, например, Х в сообщении (1), и в дальнейшем А будет взаимодействовать с Х а не с В, сам того не подозревая. Заметим, что часть текста {CK, A}KB субъект А прочесть не может.
Если все прошло нормально, субъект А посылает В следующее сообщение:
A® B: | {CK, A}KB | (1.3) |
Нетрудно видеть, что содержимое {CK, A} KB является частью сообщения, полученного от AS. Дешифровать это послание может только субъект В, так как оно зашифровано его секретным ключом. После дешифровки В также становится владельцем ключа сессии CK. Наличие А в сообщении подтверждает факт, что код получен именно от данного субъекта. Все обмены между А и В далее будут выполняться с использованием ключа шифрования СK. Чтобы сделать схему симметричной и уменьшить вероятность атаки воспроизведения, В следует послать А свой идентификатор:
B® A: | {IB}CK | (1.4) |
A® B: | {IB-1}CK | (1.5) |
A® B: | {CK, A}KB, {IA2}CK | (1.3a) |
B® A: | {IA2 –1, IB}CK | (1.4a) |
Предполагается, что субъекты А и В вычислили пары ключей (PKA-SKA) и (PKB-SKB), соответственно. Имена ключей, начинающиеся с буквы P, относятся к общедоступным ключам (public), а имена, начинающиеся с буквы S, - к секретным. Инициатором, как и в предыдущем случае, будем считать субъект А. Обмен начинается с посылки AS запроса открытого ключа В (PKB).
A® AS: | (A, B) | (2.1) |
AS® A: | (PKB, B)SKAS | (2.2) |
Шифрование данных с использованием ключа SKAS не гарантирует конфиденциальности, но исключает модификацию сообщения по дороге (ведь никто посторонний не знает ключ SKAS).
Важно, чтобы субъект А был уверен, что он получил именно PKB, а не что-то иное. Следующим шагом будет посылка сообщения от А к В:
A® B: | {IA, A}PKB | (2.3) |
B® AS: | B, A | (2.4) |
AS® B: | {PKA, A}SKAS | (2.5) |
B® A: | {IA, IB}PKA | (2.6) |
A® B: | { IB }PKB | (2.7) |
Так как открытые ключи общедоступны, во многих случая для обеспечения большей достоверности следует использовать шифрование типа:
{{сообщение}SKA}SKB.
В реальной жизни субъекты не всегда могут находиться в пределах зоны ответственности одного общего сервера аутентификации. По этой причине в общем случае каждый из субъектов может иметь свой сервер аутентификации (ASA и ASB). Так как и в этом варианте перед субъектом А стоит задача сформировать для В сообщение типа {CK, A}KB (шаг 1.3). В вычисление таких выражений будут вовлечены оба сервера, так как только ASA может шифровать объекты посредством ключа КА, и только ASB может воспользоваться ключом КВ. Не исключается необходимость обеспечения безопасного обмена между AS. Примерами такого обмена могут служить операции, завершающие сессию аутентификации:
ASA® ASB: | (CK, A, B, IA1) | (1.11) | |
ASB® ASA: | (CK, A)KB, IA1, A | (1.12) | |
При работе с открытыми ключами возможно непосредственное обращение А к ASB, если субъект А владеет общедоступным ключом PKASB. По минимуму аутентификация при асимметричной схеме шифрования требует пересылки трех сообщений.
Протокол Нидхэма-Шрёдера пригоден и для работы с электронными подписями. Электронная подпись, как обычно, формируется на основе дайджеста D (например, MD5) пересылаемого документа. Сначала рассмотрим вариант с традиционной схемой шифрования. Субъект А начинает передачу с посылки AS сообщения:
A® AS: | (A, {D}KA) | (3.1) |
AS® A: | {A, D}KAS | (3.2) |
B® AS: | B, {A, D}KAS | (3.3) |
AS® B: | {A, D}KB | 3.4) |
В случае варианта шифрования с общедоступными ключами схема электронной подписи упрощается. В этом варианте можно даже не формировать дайджест можно послать текст, зашифрованный сначала секретным ключом А, а затем с привлечением общедоступного ключа В.
A® B: | { (текст)SKA }PKB |
В настоящее время разработан улучшенный протокол Нидхэма-Шрёдера (см. ).
[1] Roger M. Needham and Michael D. Schroeder, Using Encryption for Authentication in Large Networks of Computers. Communication of the ACM, V.21, N12, December 1978.
Протокол диалога
Протокол диалога TLS представляет собой один из фиксированных клиентов высокого уровня протокола записей TLS. Этот протокол используется для согласования атрибутов безопасности сессии. Сообщения диалога передаются уровню записей TLS, где они инкапсулируются в одну или более структур TLSPlaintext, которые обрабатываются и передаются так, как это специфицировано текущим состоянием активной сессии.
enum { hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
| struct | { HandshakeType msg_type; | /* тип диалога */ |
| uint24 length; | /* байтов в сообщении */ | |
| select (HandshakeType) { | ||
| case hello_request: | HelloRequest; | |
| case client_hello: | ClientHello; | |
| case server_hello: | ServerHello; | |
| case certificate: | Certificate; | |
| case server_key_exchange: | ServerKeyExchange; | |
| case certificate_request: | CertificateRequest; | |
| case server_hello_done: | ServerHelloDone; | |
| case certificate_verify: | CertificateVerify; | |
| case client_key_exchange: | ClientKeyExchange; | |
| case finished: | Finished; } body; | |
| } Handshake; |
Сообщения протокола диалога представлены ниже в порядке, в котором они должны быть посланы. Посылка сообщений диалога в неправильном порядке приведет к фатальной ошибке. Ненужные сообщения диалога могут быть опущены. Обратите внимание на одно исключение: сообщение сертификата используется в диалоге дважды (от клиента к серверу, а затем от сервера к клиенту), но оно описано лишь для первого случая его использования. Одно сообщение не привязано к этим правилам порядка обмена, это сообщение запроса Hello, которое может быть послано в любое время, но которое должно игнорироваться клиентом, если приходит в середине диалога.
Протокол диалога TLS
Протокол диалога TLS содержит набор из трех суб-протоколов, которые используются, чтобы партнеры могли согласовать используемые параметры безопасности для уровня записи, аутентифицировать себя, и уведомлять друг друга об ошибках.
Протокол диалога ответственен за согласования характеристик сессии, куда входят следующие объекты:
| идентификатор сессии |
Произвольная последовательность байтов, выбранная сервером для идентификации состояния сессии (активная/ возобновляемая). |
| сертификат партнера |
X509v3 [X509] сертификат партнера. Этот элемент состояния может быть равен нулю. |
| метод сжатия | Алгоритм, используемый для сжатия информации перед шифрованием. |
| спецификация шифра | Специфицирует алгоритм массового шифрования (такой как нуль, DES, и т.д.) и алгоритм MAC (такой как MD5 или SHA). Она определяет также криптографические атрибуты, такие как hash_size. (Смотри приложение A.6) |
| мастерный секретный код | 48-байтовый секретный код, общий для сервера и клиента. |
| 'is resumable' | Флаг, указывающий, может ли сессия использоваться для инициализации нового соединения. |
Эти объекты используются затем для определения параметров безопасности для уровня записей при защите прикладных данных. Многие соединения могут реализоваться в рамках той же сессии с помощью процедуры возобновления (resumption) протокола диалога.
Electrical Characteristics of Hierarchical Digital
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Интерфейс G.703 (ITU-T Recommendation G.703.Physical/ Electrical Characteristics of Hierarchical Digital Interfaces. 1972 last amended in 1991) был разработан в 1972 году и базируется на стандартах G.702, G.704 и I.430 и обслуживает сети с иерархией PDH и SDH. Первоначально он разрабатывался для систем с импульсно-кодовой модуляцией. G.703 может работать на скоростях передачи данных 64 Кбит/с, 1544, 6312, 32064 и 44736 Кбит/с (PDH, американская версия), 2048, 8448, 34368, 139264 Кбит/с (европейская версия). Предусматривается работа и при 155,52 Мбит/с. В качестве физического канала передачи может использоваться скрученная пара (Z=100-120 Ом) или коаксиальный кабель (75 Ом), амплитуда импульса 1-3В.
При скорости 64 Кбит/с через интерфейс передается три типа сигналов: информационный (64 Кбит/с) и два синхронизирующих тактовых 64 Кбит/с и 8 Кбит/с. Стандарт предусматривает 3 вида взаимодействия терминального оборудования: однонаправленный (codirectional; рис. 3.6.1), разнонаправленный (рис. 3.6.2) и с центральным тактовым генератором (рис. 3.6.3).
Рис. 3.6.1. Однонаправленная передача информации и тактовых сигналов
Рис. 3.6.2. Разнонаправленная передача информации и тактового сигнала для 64 Кбит/с
Во втором варианте терминалы неравноправны – один из них управляющий, другой – управляемый. Тактовые сигналы идут в этом случае только от управляющего терминала.
Рис. 3.6.3. Интерфейс с центральным тактовым генератором для 64 кбит/с
Частота синхронизирующих сигналов может быть меньше скорости передачи данных в 2, 4 и 8 раз. Тип кода зависит от скорости передачи и типа аппаратного интерфейса. Характеристики основных разновидностей интерфейса G.703 приведены в таблице 3.6.1.
Таблица 3.6.1.
| Скорость [кбит/с] | 64 | 1544 | 6312 | 32064 | 44736 | 2048 | 8448 | 34368 | 139264 | 155520 |
| Тип кода | AMI |
AMI B8ZS | B6ZS | AMI | B3ZS | HDB3 | HDB3 | HDB3 | CMI | CMI |
| Амплитуда, В | 1,0 | 3,0 | 1,0 | 1,0 | 1,0 |
2,37 3,0 | 2,37 | 1,0 | ±0,55 | ±0,55 |
| Ширина импульса, нс | 15000 | 323,5 | 79 | 15,6 | 11,2 | 244 | 59,0 | 14,55 | 3,59 | 3,2 |
Протокол изменения спецификации шифра
Протокол изменения спецификации шифра предназначен для оповещения об изменении стратегии шифрования. Протокол использует одно сообщение, которое зашифровано и архивировано в рамках текущего состояния соединения. Сообщение состоит из одного байта со значением 1.
struct { enum { change_cipher_spec(1), (255) } type;} ChangeCipherSpec;
Сообщение изменения спецификации шифра посылается как клиентом, так и сервером, для того чтобы уведомить партнера о том, что последующие записи будут защищены с помощью только что согласованных ключей и спецификации CipherSpec. Получение этого сообщения заставляет получателя на уровне записей немедленно скопировать состояние ожидания чтения в текущее состояние чтения. Сразу после посылки сообщения отправитель должен дать команду уровню записей преобразовать состояние ожидания записи в активное состояние записи. (Смотри раздел 6.1.) Сообщение изменения спецификации шифра посылается во время диалога после согласования набора параметров безопасности, но до посылки проверочного завершающего сообщения (смотри раздел 7.4.9).
Протокол оповещения
Одним из типов содержимого, поддерживаемого слоем записей TLS, является оповещение. Сообщения оповещения передают описание возникшей ситуации. Оповещения с аварийным уровнем вызывают немедленное прерывание соединения. В этом случае, другие соединения сессии могут оставаться в рабочем состоянии, но идентификатор сессии должен быть объявлен не действительным, блокируя установление новых соединений. Подобно другим сообщениям, оповещения шифруются и сжимаются, как это специфицировано состоянием текущего соединения.
enum { warning(1), fatal(2), (255) } AlertLevel;
enum { close_notify(0),
| unexpected_message(10), | |
| bad_record_mac(20), | |
| decryption_failed(21), | |
| record_overflow(22), | |
| decompression_failure(30), | |
| handshake_failure(40), | |
| bad_certificate(42), | |
| unsupported_certificate(43), | |
| certificate_revoked(44), | |
| certificate_expired(45), | |
| certificate_unknown(46), | |
| illegal_parameter(47), | |
| unknown_ca(48), | |
| access_denied(49), | |
| decode_error(50), | |
| decrypt_error(51), | |
| export_restriction(60), | |
| protocol_version(70), | |
| insufficient_security(71), | |
| internal_error(80), | |
| user_canceled(90), | |
| no_renegotiation(100), |
(255)} AlertDescription;
struct { AlertLevel level; AlertDescription description;} Alert;
Протокол PPP
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Протокол PPP (Point-to-Point Protocol; RFC-2716, -2701, -2688, -2687, -2686, -2615, -2516, -2509, -2508, -2507, -2484, -2472, -2433, -2420, -2419, -2364, -2363, -2290, -2284, -2153, -2125, -2097, -2043, -1994, -1993, -1990, -1989, -1979, -1978, -1977, -1976, -1975, -1974, -1973, -1969, -1968, -1967, -1963, -1962, -1915, -1877, -1841, -1764, -1763, -1762, -1663, -1662, -1661, -1638, -1619, -1618, -1598, -1570, -1552, -1378, -1377, -1334, -1332, -1331, и STD-51, cмотри также ) предназначен для решения тех же задач, что и SLIP, но лишен многих его недостатков, он служит для передачи мультипротокольных дейтограмм от одного узла к другому. Сам по себе список RFC, приведенный выше, впечатляющ. Он говорит о том, что данный протокол относится к числу наиболее важных и широко используемых. Это и понятно, большинство региональных сетей строится с использованием соединений точка-точка. PPP поддерживает, как асинхронный режим с 8 битами данных без бита четности (согласуется со свойствами последовательного интерфейса, имеющегося практически на всех ЭВМ), так и побитовый синхронный режим. Протокол содержит в себе три составные части:
Метод инкапсуляции дейтограмм при передаче по последовательным коммуникационным каналам.
Протокол LCP для установления, конфигурирования и тестирования информационных каналов
Набор протоколов NCP для установки и конфигурирования различных протоколов сетевого уровня.
Протокол управления каналом (LCP - Link Control Protocol) является частью PPP. Идеология NCP реализована и в протоколе TCP. Каждый кадр PPP начинается и завершается флагом 0x7E. За стартовым флагом-октетом следует байт адреса, который всегда равен 0xFF. Формат кадра PPP представлен на рисунке 3.5.1. Кадр ppp может содержать только целое число байт. При инкапсуляции других пакетов в PPP используется бит-ориентированный протокол HDLC (High-level Data Link Control).
Рис. 3.5.1 Формат кадра в протоколе PPP
Поле адрес всегда содержит байт 0xff (смотри также ).
Это указывает на то, что все станции должны принять этот кадр, и исключает необходимость выделения каких-то специальных адресов. Байт управления всегда равен 0x03, что указывает на ненумерованный тип кадра. По умолчанию кадры PPP передаются в режиме "без установления соединения". Если требуется надежная доставка, используется версия, описанная в RFC-1663. Двухоктетное поле протокол сходно по функции с полем тип в кадре Ethernet и определяет то, как следует интерпретировать информационное поле (см. табл. 3.5.1). Значение 0x0021 этого поля говорит о том, что последующее информационное поле содержит в себе IP-дейтограмму. Поле CRC (Cyclic Redundancy Check) представляет собой циклическую контрольную сумму, предназначенную для выявления ошибок при транспортировке PPP-кадра. Применение флагов-ограничителей кадра (0x7E) создает те же проблемы, о которых говорилось при описании SLIP-протокола, - эти байты не могут присутствовать в информационном поле. В синхронном режиме эта проблема решается на аппаратном уровне. При работе в асинхронном режиме для этого используется специальный ESC-символ, равный 0x7D. Когда этот esc-символ встречается в информационном поле, шестой бит в следующем за ним байте инвертируется. Так байт 0x7E будет преобразован в последовательность 0x7D, 0x5E, а байт 0x7D - в два байта 0x7D, 0x5D. Все символы с кодами меньше 0x20 также преобразуются в ESC-последовательности. Например, 0x07 будет преобразован в 0x7D, 0x27. Это необходимо делать, так как управляющие символы могут оказать непредсказуемые воздействия на режим работы драйверов или модемов, используемых в канале. Протокол ppp в отличие от SLIP допускает мультипротокольность и динамическое определение IP-адресов партнеров. Несмотря на определенные преимущества протокола PPP перед SLIP, последний распространен достаточно широко. Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации.
Таблица 3.5.1. Стандартизованные DLL-номера протоколов для PPP (поле протокол)
| DLL-код протокола (шестнадцатеричный) | Наименование протокола |
| 0001 | Протокол заполнения (padding) |
| 0003-001F | Зарезервировано |
| 0021 | IP-протокол |
| 0023 | Сетевой уровень OSI |
| 0025 | Xerox NS IDP |
| 0027 | Decnet фаза IV |
| 0029 | Appletalk |
| 002B | Novell IPX |
| 002D | Компрессированный TCP/IP протокол Ван Джекобсона |
| 002F | Не компрессированный TCP/IP протокол Ван Джекобсона |
| 0031 | PDU мостов |
| 0033 | Потоковый протокол (ST-II) |
| 0035 | Banyan Vines |
| 0039 | Appletalk EDDP |
| 003B | Appletalk Smartbuffered |
| 003D | Multi-link |
| 003F | Кадры Netbios |
| 0041 | Cisco Systems |
| 0043 | Ascom Timeplex |
| 0047 | Удаленная локальная сеть DCA |
| 0049 | Транспортный протокол для последовательных данных (PPP-SDTP) |
| 004B | SNA через 802.2 |
| 004D | SNA |
| 004F | Сжатие заголовков IPv6 |
| 007D | Зарезервировано (Управл. ESC) [RFC1661] |
| 00FD | 1-ый вариант компрессии |
| 0201 | Пакеты отклика 802.1d |
| 0203 | IBM BPDU базовой маршрутизации |
| 8021 | Управляющий протокол Интернет (IPCP) |
| 8023 | Управляющий протокол сетевого уровня OSI |
| 8025 | Управляющий протокол Xerox NS IDP |
| 8027 | Управляющий протокол Decnet фаза VI |
| 8029 | Управляющий протокол Appletalk |
| 802B | Управляющий протокол Novell IPX |
| 8031 | Бридж NCP |
| 8033 | Потоковый управляющий протокол |
| 8035 | Управляющий протокол Banyan Vines |
| 803D | Многосвязный управляющий протокол |
| 803F | Управляющий протокол кадров NetBIOS |
| 8041 | Управляющий протокол Cisco |
| 8043 | Ascom Timeplex |
| 8045 | Управляющий протокол Fujitsu LBLB |
| 8047 | Управляющий протокол удаленных локальных сетей DCA (RLNCP) |
| 8049 | Управляющий протокол передачи последовательных данных (PPP-SDCP) |
| 804B | Управляющий протокол для передачи sna поверх 802.2 |
| 804D | Управляющий протокол SNA |
| 804F | Управляющий протокол сжатия заголовков IPv6 |
| 80FD | Управляющий протокол сжатия |
| C021 | Канальный управляющий протокол |
| C023 | Протокол аутентификации паролей |
| C025 | Сообщение о состоянии канала |
| C081 | Управляющий протокол для работы с контейнерами |
Значения кодов поля протокола от 0xxx до 3xxx идентифицируют протоколы сетевого уровня, а значения в интервале 8xxx - bxxx говорят о том, что протокол соответствует NCP (Network Control Protocol). Коды из диапазона 4xxx - 7xxx используются для протоколов с низким уровнем трафика, а коды от cxxx до exxx соответствуют управляющим протоколам (например, LCP).
Протокол PPP при установлении соединения предусматривает процедуру аутентификации, которая является опционной (смотри рис. 3.5.2.). После перехода на сетевой уровень вызывается NCP-протокол, который выполняет необходимую конфигурацию канала.
Рис. 3.5.2. Алгоритм установления соединения PPP
При обнаружении несущей или по инициативе клиента система может попытаться установить соединение. В случае успеха система переходит в фазу аутентификации. Если же и фаза аутентификации завершается благополучно, система выполняет подключение к сети (IP, IPX, Appletalk и т.д.), настройка сетевого уровня производится в рамках протокола NCP. Во всех остальных случаях производится возврат в исходное состояние. Процедура закрытия соединения осуществляется протоколом LCP.
В поле данных PPP-пакета может быть вложен один LCP-пакет, в этом случае в поле протокол должен быть записан код 0xC021 (Link Control Protocol). LCP-протокол служит для установления соединения путем обмена конфигурационными пакетами. По завершении этого обмена система переходит в фазу аутентификации (рис.3.5.2). Формат LCP-пакета показан на рис. 3.5.3.
Рис. 3.5.3. Формат заголовка LCP-пакета
Вслед за заголовком следует поле данных. Поле код (1 октет) идентифицирует модификацию LCP-пакета. Если получен пакет с неизвестным полем код, посылается пакет-отклик “отклонение кода”. Поле идентификатор (1 октет) служит для нахождения соответствия между запросами и откликами. Если получен пакет с неправильным идентификатором, он просто уничтожается. Двухоктетное поле длина определяет размер LCP-пакета, включая размер заголовка. Октеты принятого пакета за пределами, заданными полем длина игнорируются.
В качестве примера можно рассмотреть процедуру подключения персональной ЭВМ к серверу через модем. После того как модем маршрутизатора ответит на вызов модема-клиента и установит физическое соединение, ЭВМ посылает последовательность LCP-пакетов, вложенных в поля данных одного или нескольких PPP-кадров. Это позволяет выбрать необходимые параметры PPP. По завершении этой процедуры посылается последовательность NCP-пакетов, которые конфигурируют сетевой уровень. Вероятно, ЭВМ захочет работать со стеком протоколов TCP/IP, и по этой причине нуждается в IP-адресе. Если провайдер имеет N IP-адресов в резерве, он может подключить одновременно N ЭВМ. Присвоение IP-адреса осуществляется также в рамках NCP-протокола. После этого ЭВИ становится узлом Интернет. Завершение сессии и освобождение IP-адреса выполняется также через NCP-протокол. Разрыв соединения осуществляет протокол LCP.
За полем длина могут следовать поля опций. Опции определяются все сразу на фазе конфигурирования канала. Описание опции содержит однооктетные субполя типа и длины, за которыми следует поле данных. Значения субполя типа представлены в таблице.
| Значение кода поля типа | Назначение опции |
| 0 | Зарезервировано |
| 1 | Maximum-Receive-Unit (указывает максимальный размер блока данных, который может быть принят) |
| 3 | Authentication-Protocol (протокол аутотентификации) |
| 4 | Quality-Protocol (протокол качества) |
| 5 | Magic-Number (магическое число, опция служит для выявления каналов с петлями обратной связи) |
| 6 | Protocol-Field-Compression |
| 7 | Address-and-Control-Field-Compression |
Пакеты конфигурации канала, которые используются при формировании виртуального канала (Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject) .
Пакеты закрытия канала (Terminate-Request и Terminate-Ack).
Пакеты поддержания, которые служат для управления и отладки(Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).
Аналогом LCP является протокол IPCP (IP Control Protocol). В поле код протокола в этом случае записывается 8021 (RFC-1332).
Формат пакета IPCP показан на рис. 3.5.4.
Рис. 3.5.4. Формат пакета IPCP. Младшие биты слева.
Поле тип содержит 2, в поле длина заносится число байт в пакете (?4). В поле протокол сжатия IP заносится код алгоритма сжатия (0х02D - в случае алгоритма Ван Джекобсона). Поле данные может содержать нуль или более октетов. Конфигурационный запрос может потребовать присылки (присвоения) IP-адреса. Для решения этой задачи предусмотрена опция IPCP-пакета, где поле тип=3, длина=6, а последующие 4 байта выделены для IP-адреса, куда отправитель должен его записать. Если туда записаны нули, это говорит о том, что отправитель запрашивает свой IP-адрес.
Протоколы PPP, LCP (Link Control Protocol), CCP (Compression Control Protocol; RFC-1962, -1967), и некоторые другие управляющие протоколы содержат 8-битовые поля код. Значения этих кодов приведены в таблице 3.5.2.
Таблица 3.5.2 Значения поля код LCP-заголовка
| Код | Тип пакета | |
| 1 | Запрос конфигурации | Configure-Request |
| 2 | Подтверждение конфигурации | Configure-Ack |
| 3 | Не подтверждение конфигурации | Configure-Nak |
| 4 | Отклонение конфигурации | Configure-Reject |
| 5 | Запрос завершения | Terminate-Request |
| 6 | Подтверждение завершения | Terminate-Ack |
| 7 | Отклонение кода | Code-Reject |
| 8* | Отклонение протокола | Protocol-Reject |
| 9* | Запрос отклика | Echo-Request |
| 10* | Эхо-отклик | Echo-Reply |
| 11* | Запрос отмены | Discard-Request |
| 12* | Идентификация | |
| 13* | Остающееся время | |
| 14** | Запрос сброса | |
| 15** | Отклик на запрос сброса | |
| *) Только LCP; | **) Только CCP |
Протокол PPP многолик, он способен поддерживать и многоканальные соединения (RFC-1990). Это бывает полезно при работе через ISDN, X.25, Frame Relay или при необходимости расширить пропускную способность за счет подключения нескольких параллельных каналов (MP - MultiLink Protocol). Так как я не сталкивался со случаями, когда пропускной способности было вполне достаточно, данную модификацию PPP-протокола следует считать крайне важной.
При этом одной из проблем является распределение пакетов по каналам и последующее их упорядочение принимающей стороной. Особую осторожность в этом случае следует соблюдать при использовании заполнителей. В этом режиме по виртуальному каналу MultiLink запрещается посылать конфигурационные LCP-пакеты Configure-Request, -Reject, -Ack, -Nak, Terminate-Request или -Ack. Принимающая сторона в случае их обнаружения должна их игнорировать. Применение других LCP-пакетов допускается (например, Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).
Формат MP-пакета представлен на рис. 3.5.5.
Рис. 3.5.5. Формат MР-пакета
Поля PID - идентификатор протокола. Субполе B (Beginning) - бит фрагмента =1 для первого фрагмента PPP и =0 для всех последующих фрагментов. Субполе E (Ending) - бит фрагмента =1 для последнего фрагмента PPP и =0 для всех прочих фрагментов. Поле номер по порядку имеет длину 24 бита. Существует модификация пакета с укороченным кодом (12 бит) номера по порядку. При этом к этому полю отходят 4 нулевые бита после BE00. Выбор длины этого поля осуществляется протоколом LCP. Значение полу увеличивается на 1 при посылке очередного фрагмента. Для вышерасположенных уровней совокупность совместно используемых каналов выглядит, как один виртуальный канал.
При передаче пакетов по каналу Multilink инкапсуляция производится согласно следующим правилам, которые задаются вручную:
Никакого асинхронного управления кодированием символов
Запрет использования магических чисел
Запрещено мониторирование качества канала
Сжатие полей адреса, протокола и управления
Никаких составных кадров
Запрет заполнения с самоописанием (Self-Describing-Padding)
Для предварительно фрагментированных пакетов запрещено дополнение нулями или использование каких-либо иных заполнителей. Рассмотрим пример Multilink-соединения, приведенный на рис. 3.5.6. Канал 1 между двумя системами согласуется сетевыми уровнями NL1, NL2 и MP. Затем эти две системы согласуют с MP канал 2. Кадры, полученные каналом 1, демультиплексируются на канальном уровне согласно сетевому протокольному идентификатору PPP и могут быть посланы NL1, NL2 или MP.
Канал 2 примет кадры со всеми сетевыми протокольными идентификаторами, с которыми принимает их канал 1. Кадры, полученные MP, позднее демультиплексируются на сетевом уровне согласно протокольному идентификатору PPP и посылаются NL1 или NL2. Любые кадры, полученные MP для других протоколов сетевого уровня, отбрасываются с помощью стандартного протокольного механизма (Reject).
Рис. 3.5.6. Пример Multilink-конфигурации
Так как межсетевые связи часто используют последовательные каналы (выделенные линии, радиомодемы и пр.), протокол PPP распространен достаточно широко. Протокол PPP служит и для создания межсетевых туннелей (протокол PPTP - Point to Point Tunneling Protocol). Протокол PPTP использует MTU=1532, номер порта 5678 и номер версии 0x0100, пакеты данных здесь транспортируются с использованием протокола инкапсуляции GRE V2 (см. сноску в начале раздела).
Протокол SLIP
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Протокол SLIP (Serial Line IP, RFC-1055) – это простейший способ инкапсуляции IP-дейтограмм для последовательных каналов связи. Этот протокол стал популярным благодаря возможностям подключения домашних персональных машин к сети Интернет через порт RS-232, который соединен с модемом. IP-дейтограмма в случае SLIP должна завершаться специальным символом 0xC0 называемым конец. Во многих реализациях дейтограмма и начинается с этого символа. Если какой-то байт дейтограммы равен символу конец, то вместо него передается двухбайтовая последовательность 0xDB, 0xDC. Октет 0xDB выполняет в SLIP функцию ESC-символа. Если же байт дейтограммы равен 0xDB, то вместо него передается последовательность 0xDB, 0xDD. Использование протокола SLIP предполагает выполнение ряда условий:
Каждый партнер обмена должен знать IP-адрес своего адресата, так как не существует метода обмена такого рода информацией.
SLIP в отличии от Ethernet не использует контрольных сумм, поэтому обнаружение и коррекция ошибок целиком ложится на программное обеспечение верхних уровней.
Так как кадр SLIP не имеет поля тип, его нельзя использовать, в отличии от кадров Ethernet, для реализации других протоколов методом инкапсуляции.
Впервые протокол SLIP был применен в 1984 году в 4.2BSD. Скорость передачи информации при использовании протокола SLIP не превышает 19.2кб/с, что обычно достаточно для интерактивного обмена в рамках протоколов telnet или RLOGIN. Максимальный размер передаваемого блока (MTU) для SLIP лежит вблизи 256-512 байт, что обеспечивает разумный компромисс между значением задержки отклика (~256мс.) и эффективностью использования канала (~98% для CSLIP). При этом для передачи одного символа (нажатая клавиша) используется 20 байт заголовка в IP-дейтограмме и 20 байт TCP-заголовка. Если мы учтем издержки формирования SLIP-кадра, накладные расходы превосходят 40 байт. Частично этот недостаток устранен в новой версии CSLIP (Compressed SLIP, RFC-1144, предложенной Джекобсоном в 1990 году).
В CSLIP заголовок сокращается до 3-5байт (против 40 в SLIP). Эта версия протокола способна поддерживать до 16 TCP-соединений на каждом из концов последовательного канала. Многие современные SLIP-драйверы поддерживают и CSLIP.
3.4.1. Протоколы RS
Протоколы RS (RS-232, RS-449, RS-423-А, RS-422-А и RS-485) относятся к семейству рекомендованных протоколов (буква R в названии обозначает recommended). RS-232 обеспечивает дуплексную связь и скорость передачи 19,2 кбит/с при длине связи до 15м. На практике при расстояниях порядка 10 метров можно получить быстродействие канала более 100кбит/с. Здесь обеспечивается связь точка-точка. Логической 1 соответствует уровень сигнала -(5-15)В, а логическому нулю +(5-15)В. В отличии от других упомянутых выше стандартов, которые допускают скорости обмена до 10Мбит/с (при длине линии 15м), данный протокол из-за низкой скорости обмена работает без использования симметричных сигналов на скрученной паре канала связи. Более подробную информацию можно найти, например, в http://ixbt.stack.net/comm/rs_proto.html. приведена в приложении.
Стандарт RS-449 представляет собой в действительности семейство, состоящее из 3-х стандартов. Механическая, функциональная и процедурная часть содержится в самом RS-449, а регламентации электрического интерфейса описаны в RS-423-A (подобен RS-232-C) дле схемы с общей землей. Балансная симметричная схема интерфейса представлена в документе на RS-422-A, для для передачи каждого сигнала используется два провода, что позволяет достичь быстродействия 2Мбит/с при длине соединения до 60м. Разводка разъемов представлена в .
Протокол SSL Безопасный уровень соединителей
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Протокол SSL спроектирован для обеспечения конфиденциальности обмена между двумя прикладными процессами клиента и сервера (см. ). Он предоставляет возможность аутентификации сервера и, опционно, клиента. SSL требует применения надежного транспортного протокола (например, TCP).
Преимуществом SSL является то, что он независим от прикладного протокола. Протоколы приложения, такие как HTTP, FTP, TELNET и т.д. могут работать поверх протокола SSL совершенно прозрачно. Протокол SSL может согласовывать алгоритм шифрования и ключ сессии, а также аутентифицировать сервер до того как приложение примет или передаст первый байт данных. Все протокольные прикладные данные передаются зашифрованными с гарантией конфиденциальности.
Протокол SSL предоставляет "безопасный канал", который имеет три основные свойства:
Канал является частным. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа.
Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, в то время как клиентская - аутентифицируется опционно.
Канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC).
Протокол записей TLS
Протокол записей TLS является послойным. На каждом уровне, сообщения могут включать поля длины, описания и содержимого. Протокол записей берет сообщения, подлежащие пересылке, разбивает их на блоки, опционно сжимает данные, применяет MAC, шифрует и передает результат. Полученные данные дешифруются, верифицируются, декомпрессируются, восстанавливается их первоначальный вид, результат передается клиентам верхнего уровня.
Четыре протокола описаны в данном документе: протокол диалога, протокол уведомления, протокол спецификации изменения шифра, и прикладной информационный протокол. Для того чтобы позволить расширение протокола TLS, разрешена поддержка протоколом дополнительных типов записей. Любые новые типы записей должны размещать значения типа немедленно за величинами ContentType четырех типов, описанных здесь (смотри Приложение A.2). Если реализация TLS получает рекорд нераспознаваемого типа, она должна его игнорировать. Любой протокол, предназначенный для использования поверх TLS, должен быть тщательно сконфигурирован, для того чтобы противостоять любым атакам. Заметим, что из-за того, что тип и длина записи не защищены шифрованием, следует принимать меры, чтобы минимизировать трафик анализа этих величин.
Протокольные сообщения Клиент/Сервер
Эти сообщения генерируются как клиентом, так и сервером.
ERROR (посылается открыто или зашифровано)
char MSG-ERROR
char ERROR-CODE-MSB
char ERROR-CODE-LSB
Это сообщение посылается, когда обнаружена ошибка. После посылки сообщения, отправитель закрывает соединение. Получатель регистрирует ошибку и затем также разрывает соединение.
Это сообщение посылается открыто, если произошла ошибка при согласовании ключа сессии. После того как ключ сессии согласован, сообщения об ошибках шифруются также как и обычные сообщения.
Приложение A. ASN.1 синтаксис сертификатов
Сертификаты используются SSL для аутентификации серверов и клиентов. SSL Сертификаты базируются в основном на X.509 [3]. Сертификат X.509 содержит следующую информацию (в нотации ASN.1 [1]):
X.509-Certificate ::= SEQUENCE { certificateInfo CertificateInfo,
signatureAlgorithm AlgorithmIdentifier, signature BIT STRING }
CertificateInfo ::= SEQUENCE { version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber, signature AlgorithmIdentifier,
issuer Name, validity Validity, subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo }
Version ::= INTEGER { v1988(0) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime }
SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY ALGORITHM OPTIONAL }
Для целей SSL наложены ограничения на некоторые значения полей X.509:
Поля X.509-Certificate::signatureAlgorithm и CertificateInfo::signature должны иметь идентичные значения.
Имя эмитента сертификата должно преобразовываться в имя, которое приемлемо для приложения, использующего SSL.
Сертификаты верифицируются в несколько шагов. Во-первых, проверяется подпись сертификата и, если она некорректна, некорректен и сертификат (произошла транспортная ошибка или попытка модификации). Далее верифицируется поле CertificateInfo::issuer. Там должна быть ссылка на эмитента, которому приложение доверяет.
Поле CertificateInfo:: validity проверяется на текущую дату и верифицируется.
Наконец, проверяется поле CertificateInfo::subject. Эта проверка опционна и зависит от уровня доверия, необходимого приложению, которое использует SSL.
Приложение B. Идентификаторы объектов и типов атрибутов
SSL использует субнабор X.520 типов атрибутов, а также несколько специфических идентификаторов объектов. Будущие модификации протокола SSL смогут поддерживать больше типов атрибутов и больше идентификаторов объектов.
B.1. Выбранные типы атрибутов
| commonName { attributeType 3 } | Общее имя, содержащееся в поле эмитента сертификата или субъекта сертификата. |
| countryName { attributeType 6 } | Название страны. |
| localityName { attributeType 7 } | Название местоположения. |
| stateOrProvinceName { attributeType 8 } | Название штата или провинции. |
| organizationName { attributeType 10} | Название организации. |
| organizationalUnitName { attributeType 11 } | Название подразделения. |
md2withRSAEncryption { ... pkcs(1) 1 2 }
Идентификатор объекта для цифровой подписи, которая используется при шифровании MD2 и RSA. Применяется при SSL-верификации подписи сертификата.
md5withRSAEncryption { ... pkcs(1) 1 4 }
Идентификатор объекта для цифровой подписи, которая используется при шифровании MD5 и RSA. Применяется при SSL-верификации подписи сертификата.
rc4 { ... rsadsi(113549) 3 4 }
Алгоритм симметричного поточного шифра RC4, используемый SSL для массового шифрования.
Приложение C. Значения протокольных констант
Ниже рассмотрены различные протокольные константы. Одна вещь требует особого упоминания - IANA зарезервировала номер порта для "https" (HTTP использующий SSL). Этот порт имеет номер 443.
C.1. Коды версии протокола
#define SSL_CLIENT_VERSION 0x0002
#define SSL_SERVER_VERSION 0x0002
C.2. Коды протокольных сообщений
Определены следующие значения для кодов сообщений, которые используются версией 2 протокола диалога SSL.
#define SSL_MT_ERROR 0
#define SSL_MT_CLIENT_HELLO 1
#define SSL_MT_CLIENT_MASTER_KEY 2
#define SSL_MT_CLIENT_FINISHED 3
#define SSL_MT_SERVER_HELLO 4
#define SSL_MT_SERVER_VERIFY 5
#define SSL_MT_SERVER_FINISHED 6
#define SSL_MT_REQUEST_CERTIFICATE 7
#define SSL_MT_CLIENT_CERTIFICATE 8
C.3. Коды сообщений об ошибках
Определены следующие значения для кодов ошибок, используемых в сообщениях ERROR.
#define SSL_PE_NO_CIPHER 0x0001
#define SSL_PE_NO_CERTIFICATE 0x0002
#define SSL_PE_BAD_CERTIFICATE 0x0004
#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006
C.4. Значения вида шифра
Определены следующие значения для кодов CIPHER-KIND, используемых в сообщениях CLIENT-HELLO и SERVER-HELLO.
#define SSL_CK_RC4_128_WITH_MD5 0x01,0x00,0x80
#define SSL_CK_RC4_128_EXPORT40_WITH_MD5 0x02,0x00,0x80
#define SSL_CK_RC2_128_CBC_WITH_MD5 0x03,0x00,0x80
#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 0x04,0x00,0x80
#define SSL_CK_IDEA_128_CBC_WITH_MD5 0x05,0x00,0x80
#define SSL_CK_DES_64_CBC_WITH_MD5 0x06,0x00,0x40
#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5 0x07,0x00,0xC0
C.5. Коды типа сертификата
Определено следующее значение для кода типа сертификации, используемое в сообщениях SERVER-HELLO и CLIENT-CERTIFICATE.
#define SSL_CT_X509_CERTIFICATE 0x01
C.6. Коды типов аутентификации
Определено следующее значение для кода типа аутентификации, используемое в сообщениях REQUEST-CERTIFICATE.
#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01
C.7. Верхние/нижние ограничения
Следующие величины определяют верхние/нижние ограничения для различных протокольных параметров.
#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 256
#define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES 16
#define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES 64
#define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER 32767
#define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER 16383
Приложение D: Атаки
В данном разделе описываются различные атаки, которые могут быть предприняты против протокола SSL. Этот перечень не может считаться исчерпывающим. SSL показал устойчивость к этим атакам.
D.1. Раскрытие шифров
SSL зависит от нескольких криптографических технологий.
Шифрование с общедоступным ключом RSA [5] используется для пересылки ключей сессии и аутентификации клиента/сервера. В качестве шифра сессии применяются различные криптографические алгоритмы. Если осуществлена успешная атака на эти алгоритмы, SSL не может уже считаться безопасным.
Атаки против определенных коммуникационных сессий могут производиться путем записи сессии, и затем, потратив большое количество компьютерного времени, предпринимается попытка подобрать ключ сессии или ключ RSA. В случае успеха открывается возможность прочесть переданную информацию. Этот подход легче, чем попытка вскрытия криптографии всех возможных сообщений. Заметим, что SSL пытается сделать цену таких атак выше, чем выгоды от успешной атаки, таким образом, делая ее пустой тратой времени и денег.
D.2. Атака открытого текста
Атака открытого текста производится, когда атакующий имеет соображения о том, какого типа сообщения посылаются зашифрованными. Атакующий может формировать базу данных, где ключами являются зашифрованные строки известного текста (или открытого текста). Раз база данных создана, с помощью простых просмотровых функций можно идентифицировать ключ сессии, который соответствует определенному зашифрованному блоку данных. Если ключ сессии удалось раскрыть, можно дешифровать весь поток данных. Общедоступные аппаратные средства могут сделать эту работу быстрее и эффективнее.
Из-за самой природы SSL атаки открытого текста возможны. Например, наиболее часто встречающейся строкой, пересылаемой HTTP-клиентом серверу является "GET". SSL пытается противостоять этим атакам, используя большие ключи сессии. Сначала клиент генерирует ключ, который длиннее чем допускается экспортными ограничениями, и посылает часть его открытым текстом серверу (это разрешено экспортными правилами). Открытая часть ключа объединяется с секретной частью, чтобы получить достаточно длинный ключ, например 128 бит, как этого требует RC4.
Способ блокирования атак открытого текста заключается в том, чтобы сделать объем необходимого общедоступного оборудования неприемлемо большим.
Каждый бит, добавляемый к длине ключа сессии, увеличивает размер словаря в два раза. Использование ключа сессии длиной 128 бит делает размер словаря далеко за пределами современных технических возможностей (решение потребует такого количества атомов, которого нет во всей вселенной). Даже если может использоваться меньший словарь, он должен быть сначала сформирован с использованием открытых битов ключа. Это достаточно время емкий процесс.
Другой способ, с помощью которого SSL может противостоять данной атаке, заключается в использовании максимально возможных длин ключей (например, в случае не экспортного варианта).
Заметим, что следствием всех этих мер защиты SSL является то, что самым простым и дешевым способом атаки становится лобовая атака ключа. Такого рода атаки требуют большой памяти и много времени и их стоимость достаточно легко оценить. Для 128-битового ключа стоимость его раскрытия можно считать бесконечной. В случае 40-битного секретного ключа цена много меньше, но все равно за пределами возможностей "дикого хакера".
D.3. Атака отклика
Атака отклика достаточно проста. Злоумышленник записывает коммуникационную сессию между клиентом и сервером. Позднее, он устанавливает соединение с сервером и воспроизводит записанные сообщения клиента.
SSL отбивает эту атаку, с помощью специального кода "nonce" (идентификатор соединения), который является уникальным. Теоретически злоумышленник не может предугадать этот код заранее, так как он основывается на наборе случайных событий, неподвластных злоумышленнику и, следовательно, он не может реагировать адекватно на запросы сервера.
Злоумышленник с большими ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать "правильную" сессию, основываясь на коде nonce, посланном сервером посылает в сообщении SERVER-HELLO. Однако коды nonce SSL имеют, по крайней мере, длину 128 бит, таким образом, злоумышленник будет вынужден записать примерно 264 кодов nonce, при этом он получит вероятность угадывания лишь 50%.
Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными.
D.4. Человек посередине
Атака посредника (человек посередине) предполагает участие в коммуникационной сессии трех субъектов: клиента, сервера и посредника-злоумышленника, находящегося между ними. Такое положение позволяет злоумышленнику перехватывать все сообщения, следующие в обоих направлениях, и при желании подменять их.
"Посредник" прикидывается сервером для клиента и клиентом для сервера. В случае SSL такая атака невозможна из-за использования сервером сертификатов. Во время диалога об установлении безопасного соединения с сервером необходимо предоставить сертификат, который подписан сертификационным центром. В этом сертификате размещается общедоступный ключ сервера, его имя и имя эмитента сертификата. Клиент верифицирует подпись сертификата, а затем проверяет имя эмитента.
Если посредник предоставляет поддельный сертификат, то он не пройдет проверку подписи, так как злоумышленник не может знать секретного ключа сервера.
Приложение E: Термины
Прикладной протокол
Прикладным протоколом является протокол, работающий поверх TCP/IP. Например: HTTP, TELNET, FTP и SMTP.
Массовый шифр
Массовые шифры используются, когда нужно за ограниченное время зашифровать/дешифровать большой объем данных. Примерами могут служить RC2, RC4 и IDEA.
Клиент
Клиентом считается приложение субъекта, который инициирует соединение с сервером.
CLIENT-READ-KEY Ключ сессии, который использует клиент для инициализации своего шифра чтения. Этот ключ имеет то же значение, что и SERVER-WRITE-KEY.
CLIENT-WRITE-KEY
Ключ сессии, который использует клиент для инициализации своего шифра записи. Этот ключ имеет то же значение, что и SERVER-READ-KEY.
Мастерный ключ
Мастерный ключ, который используется клиентом и сервером для формирования всех ключей сессий. CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY и SERVER-WRITE-KEY генерируются на основе MASTER-KEY.
MD2
MD2 [8] - это хэш-функция, которая преобразует поток данных произвольной длины в дайджест фиксированного размера.
Эта функция является предшественницей MD5 [7] [9].
MD5
MD5 [7] - это хэш-функция, которая преобразует поток данных произвольной длины в дайджест фиксированного размера. Функция имеет свойства, которые делают ее полезной при обеспечении конфиденциальности, главное из этих свойств - невозможность обратимости.
Nonce
Случайный код, который используется для предотвращения атак воспроизведения. Один партнер генерирует случайный код (nonce) и посылает его другому партнеру. Получатель шифрует его с помощью секретного ключа и возвращает отправителю. Так как nonce является случайным числом, злоумышленник не может предугадать его значение, что делает невозможной атаку воспроизведения. Получатель разрывает соединение, если обнаружит неверно зашифрованный код nonce.
Регистрируемый информационный обмен
Когда два партнера обмениваются информацией, бывает иногда важно иметь запись обмена, чтобы ни один из участников не мог утверждать, что он ничего такого не посылал. Версия 2 протокола SSL не поддерживает такой режим обмена.
Шифрование общедоступным ключом
Шифрование общедоступным ключом представляет собой метод асимметричного шифрования. Система с общедоступным ключом использует два ключа: общедоступный и секретный, которые образуют нерасторжимую пару. Сообщения шифруются общедоступным ключом, а дешифруются секретным. И наоборот, сообщения, зашифрованные секретным ключом, могут быть дешифрованы общедоступным ключом. Шифрование общедоступным ключом требует больших вычислительных ресурсов и по этой причине мало пригодно для массового шифрования.
Конфиденциальность
Конфиденциальность - это возможность двух участников обмениваться данными с гарантией того, что эти данные не станут достоянием третьей стороны. Конфиденциальность часто обеспечивается с помощью шифрования потока данных.
RC2, RC4
Массовые шифры, изобретенные RSA. RC2 является блочным шифром, а RC4 - поточным.
Сервер
Сервером считается приложение субъекта, которое реагирует на запросы установления соединения клиентов.
Сервер является пассивным объектом, ожидающим запросов от клиентов.
Шифр сессии
Шифр сессии является массовым шифром, который пригоден для шифрования или дешифрования произвольного объема данных. Шифры сессии используются в основном по причинам их высоких эксплуатационных характеристик (прежде всего, имеется в виду быстродействие). Шифры сессии, используемые этим протоколом, симметричны. Симметричные шифры предполагают применение одного и того же ключа, как для шифрования, так и дешифрования.
Идентификатор сессии
Идентификатор сессии является случайным числом, генерируемым клиентом, который идентифицирует таким способом себя серверу. Идентификатор сессии может рассматриваться как средство доступа обоих участников к записанному секретному ключу (в нашем случае к ключу сессии). Если оба партнера помнят идентификатор сессии, тогда считается, что секретный ключ известен и его не нужно согласовывать.
Ключ сессии
Ключ шифра сессии. В SSL существует четыре ключа, которые называются ключами сессии: CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY и SERVER-WRITE-KEY.
SERVER-READ-KEY
Ключ сессии, который используется сервером для инициализации шифра чтения сервера. Этот ключ имеет то же значение что и CLIENT-WRITE-KEY.
SERVER-WRITE-KEY
Ключ сессии, который используется сервером для инициализации шифра записи сервера. Этот ключ имеет то же значение что и CLIENT-READ-KEY.
Симметричный шифр
Симметричный шифр используется как для шифрования, так и для дешифрования. Примерами симметричных шифров могут служить: IDEA, RC2, RC4.
Ссылки
| [1] | CCITT. Recommendation X.208: "Specification of Abstract Syntax Notation One (ASN.1). 1988. |
| [2] | CCITT. Recommendation X.209: "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988. |
| [3] | CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988. |
| [4] | CCITT. Recommendation X.520: "The Directory - Selected Attribute Types". 1988. |
| [5] | RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, November 1993. |
| [6] | RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5, November 1993. |
| [7] | R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992. |
| [8] | R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 1992. |
| [9] | B. Schneier. Applied Cryptography: Protocols, Algorithms, и Source Code in C, Published by John Wiley & Sons, Inc. 1994. |
| [10] | M. Abadi и R. Needham. Prudent engineering practice for cryptographic protocols. 1994. |
Патентное заявление
Эта версия протокола SSL базируется на использовании патентованной технологии шифрования с общедоступным ключом, которая служит для аутентификации и шифрования/дешифрования. Процесс стандартизации в Интернет, определенный в RFC 1310, требует письменного заявления от владельца патента, что лицензия предоставляется пользователям на определенных, приемлемых условиях, прежде чем рекомендации будет одобрены в качестве предложения, проекта или стандарта Интернет.
Массачусетский Технологический институт и Совет попечителей Стэнфордского университета (Leland) предоставили эксклюзивные права PKP (Public Key Partners) на следующие патенты США и все соответствующие зарубежные патенты:
Криптографическое устройство и метод (Diffie-Hellman) No. 4,200,770
Устройство и метод для криптографии с общедоступным ключом (Hellman-Merkle) No. 4,218,582
Криптографическая коммуникационная система и метод (RSA) No. 4,405,829
Устройство и метод экспоненциальной криптографии (Hellman-Pohlig) No. 4,424,414
Эти патенты объявлены PKP покрывающими все известные методы шифрования с общедоступным ключом, включая вариации, базирующиеся на алгоритме Эль Гамаля.
Группа PKP предоставила письменные гарантии Интернет сообществу, что участники могут получить на разумных не дискриминирующих условиях права на использование технологий, покрываемых этими патентами. Эта гарантия представлена в документе RFC 1170 "Public Key Standards и Licenses". Данный документ датирован 20 апреля 1990, и может быть получен в IANA (Internet Assigned Number Authority).
Протокольные сообщения клиента
Существует несколько сообщений, которые могут быть сформированы только клиентом. Эти сообщения ни при каких обстоятельствах не могут быть посланы сервером. Клиент, получив такое сообщение, закрывает соединение с сервером и присылает приложению уведомление об ошибке.
CLIENT-HELLO (Фаза 1; посылается открыто)
char MSG-CLIENT-HELLO
char CLIENT-VERSION-MSB
char CLIENT-VERSION-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char SESSION-ID-LENGTH-MSB
char SESSION-ID-LENGTH-LSB
char CHALLENGE-LENGTH-MSB
char CHALLENGE-LENGTH-LSB
char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
char SESSION-ID-DATA[(MSB<<8)|LSB]
char CHALLENGE-DATA[(MSB<<8)|LSB]
Когда клиент впервые подключается к серверу, он должен послать сообщение CLIENT-HELLO. Сервер ожидает это сообщение от клиента первым. Любое другое сообщение от клиента в данных обстоятельствах рассматривается как ошибка.
Клиент посылает серверу свою версию SSL, спецификацию шифров, некоторые данные вызова (challenge data), и данные идентификатора сессии. Данные идентификатора сессии посылаются клиентом только в том случае, когда в его кэше имеется идентификатор сессии, а значение SESSION-ID-LENGTH не равно нулю. Когда идентификатора сессии нет, то значение SESSION-ID-LENGTH должно быть равно нулю. Данные вызова используются для аутентификации сервера. После того как клиент и сервер согласовали пару ключей сессии, сервер присылает сообщение SERVER-VERIFY с зашифрованной формой CHALLENGE-DATA.
Заметим также, что сервер не пошлет сообщения SERVER-HELLO пока не получит сообщения CLIENT-HELLO. Это делается так, чтобы сервер мог в первом сообщении клиенту определить состояние идентификатора сессии клиента (т.e. улучшить эффективность протокола и уменьшить объем обменов).
Сервер рассматривает сообщение CLIENT-HELLO и проверяет, поддерживает ли он версию программы клиента и хотя бы одну позицию в спецификации шифров клиента. Сервер может опционно отредактировать спецификацию шифров, удалив записи, которые он решил не поддерживать.
Отредактированная версия будет прислана в сообщении SERVER-HELLO, если идентификатор сессии не находится в кэше сервера.
Значение CIPHER-SPECS-LENGTH должно быть больше нуля и кратно 3. Код SESSION-ID-LENGTH должен быть равен нулю или 16. Значение CHALLENGE-LENGTH должно быть больше чем і 16 и Ј 32.
Это сообщение должно быть первым, посланным клиентом серверу. После его посылки клиент ждет сообщения SERVER-HELLO. Любое другое сообщение, присланное сервером (кроме ERROR) не допустимо.
CLIENT-MASTER-KEY (Фаза 1; посылается вначале открыто)
char MSG-CLIENT-MASTER-KEY
char CIPHER-KIND[3]
char CLEAR-KEY-LENGTH-MSB
char CLEAR-KEY-LENGTH-LSB
char ENCRYPTED-KEY-LENGTH-MSB
char ENCRYPTED-KEY-LENGTH-LSB
char KEY-ARG-LENGTH-MSB
char KEY-ARG-LENGTH-LSB
char CLEAR-KEY-DATA[MSB<<8|LSB]
char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
char KEY-ARG-DATA[MSB<<8|LSB]
Клиент посылает это сообщение, когда он определил мастерный ключ для работы с сервером. Заметим, что когда идентификатор сессии согласован, это сообщение не посылается.
Поле CIPHER-KIND указывает, какой шифр выбран из спецификации CIPHER-SPECS сервера.
Данные CLEAR-KEY-DATA содержат открытую часть MASTER-KEY. CLEAR-KEY-DATA комбинируются с SECRET-KEY-DATA, чтобы образовать MASTER-KEY, при этом SECRET-KEY-DATA составляет младшие байты MASTER-KEY. ENCRYPTED-KEY-DATA содержит секретные части MASTER-KEY, зашифрованные с использованием общедоступного ключа сервера. Шифруемые блоки формируются с использованием блоков типа 2 PKCS#1 [5]. Информационная часть блока имеет следующий формат:
char SECRET-KEY-DATA[SECRET-LENGTH]
SECRET-LENGTH равно числу байт каждого из ключей сессии. SECRET-LENGTH плюс CLEAR-KEY-LENGTH равно числу байт в ключе шифра (как это определено CIPHER-KIND). Если после дешифрования SECRET-LENGTH окажется неравным ожидаемому значению, регистрируется ошибка. Ошибкой считается и ситуация, когда CLEAR-KEY-LENGTH не равно нулю и CIPHER-KIND является не экспортным шифром.
Если алгоритм ключа требует аргумента (например, вектора инициализации DES-CBC), тогда поле KEY-ARG-LENGTH будет ненулевым и KEY-ARG-DATA будет содержать соответствующую информацию.
Для алгоритмов SSL_CK_RC2_128_CBC_WITH_MD5, SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5, SSL_CK_IDEA_128_CBC_WITH_MD5, SSL_CK_DES_64_CBC_WITH_MD5 и SSL_CK_DES_192_EDE3_CBC_WITH_MD5 должны присутствовать данные KEY-ARG с длиной 8 байт.
Вычисление ключей сессии клиента и сервера является функцией CIPHER-CHOICE:
SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]
Где KEY-MATERIAL-0[0-15] означает первые 16 байт данных KEY-MATERIAL-0, с KEY-MATERIAL-0[0], образующим старший байт CLIENT-READ-KEY.
Данные передаются хэш-функции MD5, начиная с MASTER-KEY, далее следует "0" или "1", затем вызов (CHALLENGE) и, наконец, CONNECTION-ID.
Заметим, что "0" означает ASCII символ нуль (0x30), а не значение нуль. "1" означает ASCII символ 1 (0x31). MD5 выдает 128 бит выходных данных, которые используются в качестве ключа алгоритма шифрования (старший байт хэша MD5 становится старшим байтом ключевого материала).
SSL_CK_DES_64_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]
Для DES-CBC, 16-байтовый ключевой материал формируется с помощью MD5. Первые 8 байт дайджеста MD5 используются в качестве CLIENT-READ-KEY, в то время как оставшиеся 8 байт используются в качестве CLIENT-WRITE-KEY. Вектор инициализации берется из KEY-ARG-DATA.
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]
Данные передаются хэш-функции MD5 в указанном порядке, слева направо: первым поступает MASTER-KEY, затем "0", "1" или "2", далее CHALLENGE и, наконец, CONNECTION-ID (идентификатор сессии).
Заметим, что "0" означает ascii символ нуль (0x30), а не код нуль. "1" означает ascii символ 1 (0x31). "2" означает ascii символ 2 (0x32).
Всего генерируется 6 ключей, 3 ключа читающей стороны для шифра DES-EDE3 и 3 - для пишущей стороны для функции DES-EDE3. Вектор инициализации формируется в KEY-ARG-DATA.
Вспомним, что MASTER-KEY передан серверу в сообщении CLIENT-MASTER-KEY. CHALLENGE выдается серверу клиентом в сообщении CLIENT-HELLO. CONNECTION-ID передается клиенту от сервера в сообщении SERVER-HELLO. Это делает получаемые в результате ключи, зависящими от исходной и текущей сессии. Заметим, что мастерный ключ никогда не используется для шифрования данных, и следовательно не может быть легко раскрыт.
Сообщение CLIENT-MASTER-KEY должно быть послано после сообщения CLIENT-HELLO и до сообщения CLIENT-FINISHED. Сообщение CLIENT-MASTER-KEY должно быть послано, если сообщение SERVER-HELLO содержит значение SESSION-ID-HIT равное 0.
CLIENT-CERTIFICATE (Фаза 2; посылается шифрованным)
char MSG-CLIENT-CERTIFICATE
char CERTIFICATE-TYPE
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char RESPONSE-LENGTH-MSB
char RESPONSE-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char RESPONSE-DATA[MSB<<8|LSB]
Это сообщение посылается клиентом SSL в ответ на сообщение сервера REQUEST-CERTIFICATE. CERTIFICATE-DATA содержит данные, определенные значением CERTIFICATE-TYPE. Сообщение об ошибке ERROR посылается с кодом NO-CERTIFICATE-ERROR, если данный запрос не может быть обработан корректно (например, получатель сообщения не имеет зарегистрированного сертификата).
CERTIFICATE-TYPE является одним из:
SSL_X509_CERTIFICATE
CERTIFICATE-DATA содержит подписанный сертификат X.509 (1988) [3].
RESPONSE-DATA несет в себе аутентификационные данные отклика. Эти данные зависят от значения AUTHENTICATION-TYPE, посланного сервером.
Когда код AUTHENTICATION-TYPE равен SSL_AT_MD5_WITH_RSA_ENCRYPTION, тогда RESPONSE-DATA содержит цифровую подпись следующих компонентов (в указанном порядке):
KEY-MATERIAL-0
KEY-MATERIAL-1 (только если определено типом шифра)
KEY-MATERIAL-2 (только если определено типом шифра)
CERTIFICATE-CHALLENGE-DATA (из сообщения REQUEST-CERTIFICATE)
Сертификат, подписанный сервером (из сообщения SERVER-HELLO).
Цифровая подпись формируется с привлечением MD5, полученный хэш шифруется с использованием общедоступного ключа клиента, формат подписи согласуется со стандартом PKCS#1 [5]. Сервер аутентифицирует клиента путем верификации его цифровой подписи. Допускается добавление нового типа AUTHENTICATION-TYPE или идентификатора алгоритма цифровой подписи.
Это сообщение должно быть послано клиентом только в ответ на сообщение REQUEST-CERTIFICATE сервера.
CLIENT-FINISHED (Фаза 2; посылается шифрованным)
char MSG-CLIENT-FINISHED
char CONNECTION-ID[N-1]
Клиент посылает это сообщение, после успешной обработки соответствующего сообщения сервера. Заметим, что клиент должен быть готов к приему сообщений от сервера, пока не получит сообщение SERVER-FINISHED. Данные CONNECTION-ID представляют собой исходный идентификатор соединения сервера, посланный в его сообщении SERVER-HELLO и зашифрованный посредством согласованного ключа сессии.
"N" равно числу байт в посланном сообщении, таким образом "N-1" равно числу байт в сообщении за вычетом одного байта заголовка.
Для версии протокола 2, клиент должен посылать это сообщение после получения сообщения SERVER-HELLO. Если в сообщении SERVER-HELLO флаг SESSION-ID-HIT не равен нулю, тогда сообщение CLIENT-FINISHED посылается немедленно, в противном случае сообщение CLIENT-FINISHED посылается после сообщения CLIENT-MASTER-KEY.
Протокольные сообщения сервера
Существует несколько сообщений, которые генерируются только серверами.
SERVER-HELLO (Фаза 1; посылается открыто)
char MSG-SERVER-HELLO
char SESSION-ID-HIT
char CERTIFICATE-TYPE
char SERVER-VERSION-MSB
char SERVER-VERSION-LSB
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char CONNECTION-ID-LENGTH-MSB
char CONNECTION-ID-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char CIPHER-SPECS-DATA[MSB<<8|LSB]
char CONNECTION-ID-DATA[MSB<<8|LSB]
Сервер посылает это сообщение после получения CLIENT-HELLO. Сервер возвращает флаг SESSION-ID-HIT, указывающий, известен ли серверу полученный идентификатор сессии (т.e. хранится ли он в кэше сервера). Флаг SESSION-ID-HIT будет не равен нулю, если клиент посылает серверу идентификатор сессии (в сообщении CLIENT-HELLO с SESSION-ID-LENGTH != 0), а сервер обнаружит этот идентификатор в своем кэше. Если флаг SESSION-ID-HIT не равен нулю, то поля CERTIFICATE-TYPE, CERTIFICATE-LENGTH и CIPHER-SPECS-LENGTH будут содержать код нуль.
Значение CERTIFICATE-TYPE, если оно не равно нулю, должно содержать одну из перечисленных выше величин (см. информацию о сообщении CLIENT-CERTIFICATE).
Когда флаг SESSION-ID-HIT равен нулю, сервер укладывает свой сертификат, спецификацию шифров и идентификатор соединения и посылает их клиенту. Используя эту информацию, клиент может сформировать ключ сессии и послать его серверу в сообщении CLIENT-MASTER-KEY.
Когда флаг SESSION-ID-HIT не равен нулю, как сервер так и клиент вычисляют новую пару ключей сессии, базируясь на мастерном ключе MASTER-KEY, который они получили при создании идентификатора SESSION-ID. SERVER-READ-KEY и SERVER-WRITE-KEY получаются из исходных ключей MASTER-KEY тем же способом, что CLIENT-READ-KEY и CLIENT-WRITE-KEY:
SERVER-READ-KEY = CLIENT-WRITE-KEY
SERVER-WRITE-KEY = CLIENT-READ-KEY
Заметим, что когда ключи получены и установлен флаг SESSION-ID-HIT, а сервер обнаружил идентификатор сессии клиента в своем кэше, тогда данные KEY-ARG-DATA используются с момента, когда определен идентификатор SESSION-ID.
Это делается, потому что клиент не посылает новых данных KEY-ARG-DATA (напомним, что данные KEY-ARG-DATA посланы в сообщении CLIENT-MASTER-KEY).
CONNECTION-ID-DATA представляет собой строку случайных байт, используемых сервером и клиентом в разных местах протокола. Сообщение CLIENT-FINISHED содержит зашифрованную версию CONNECTION-ID-DATA. Длина CONNECTION-ID должна лежать между 16 и 32 байтами, включительно.
CIPHER-SPECS-DATA определяет тип шифра и длину ключа (в битах), которые поддерживает принимающая сторона. Каждая спецификация SESSION-CIPHER-SPEC имеет длину 3 байта и выглядит как:
char CIPHER-KIND-0
char CIPHER-KIND-1
char CIPHER-KIND-2
Где CIPHER-KIND равен одному из:
SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
SSL_CK_DES_64_CBC_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
Этот список не является исчерпывающим и может быть расширен в будущем. Конфигурации этих средств безопасности стандартизованы (см. табл. 6.5.1).
Таблица 6.5.1
| Набор | Уровень безопасности | Описание |
| DES-CBC3-MD5 | Очень высокий | Тройной DES в режиме CBC, хэш MD5, 168-битный ключ сессии |
| DES-CBC3-SHA | Очень высокий | Тройной DES в режиме CBC, хэш SHA, 168-битный ключ сессии |
| RC4-MD5 | Высокий | RC4, хэш MD5, 128-битный ключ |
| RC4-SHA | Высокий | RC4, хэш SHA, 128-битный ключ |
| RC2-CBC-MD5 | Высокий | RC2 в режиме CBC, хэш MD5, 128-битный ключ |
| DES-CBC-MD5 | Средний | DES в режиме CBC, хэш MD5, 56-битный ключ |
| DES-CBC-SHA | Средний | DES в режиме CBC, хэш SHA, 56-битный ключ |
| EXP-DES-CBC-SHA | Низкий | DES в режиме CBC, хэш SHA, 40-битный ключ |
| EXP-RC4-MD5 | Низкий | Экспортное качество RC4, хэш MD5, 40-битный ключ |
| EXP-RC2-CBC-MD5 | Низкий | Экспортное качество RC2, хэш MD5, 40-битный ключ |
| NULL-MD5 | - | Без шифрования, хэш MD5, только аутентификация |
| NULL-SHA | - | Без шифрования, хэш SHA, только аутентификация |
MD5 используется в качестве хэш-функции для получения MAC и ключей сессии. Этот тип шифра предлагается для поддержки "экспортных" версий (т.e. версий протокола, которые могут быть применены за пределами Соединенных Штатов) клиента или сервера.
Экспортные реализации протокола диалога SSL будут иметь длины секретных ключей не более 40 бит. Для не экспортных реализаций длины ключей могут быть больше (рекомендуется, по крайней мере, 128 бит). Клиенты и серверы могут иметь не перекрывающийся набор поточных шифров. Но это означает, что они не могут общаться.
Версия 2 протокола диалога SSL определяет, что SSL_CK_RC4_128_WITH_MD5 должен иметь длину ключа 128 бит. SSL_CK_RC4_128_EXPORT40_WITH_MD5 также имеет длину ключа 128 бит. Однако только 40 бит являются секретными (другие 88 пересылаются от клиента к серверу открыто).
Сообщение SERVER-HELLO посылается, после того как сервер получит сообщение CLIENT-HELLO, и до того как сервер пошлет SERVER-VERIFY.
SERVER-VERIFY (Фаза 1; посылается шифрованным)
char MSG-SERVER-VERIFY
char CHALLENGE-DATA[N-1]
Сервер посылает это сообщение после пары ключей сессии (SERVER-READ-KEY и SERVER-WRITE-KEY), согласованных посредством идентификатора сессии или явно через спецификацию сообщения CLIENT-MASTER-KEY. Сообщение содержит зашифрованную копию данных CHALLENGE-DATA, посланных клиентом в сообщении CLIENT-HELLO.
"N" равен числу байт в сообщении, которое было послано, таким образом, "N-1" соответствует числу байт в CHALLENGE-DATA за вычетом байта заголовка.
Это сообщение используется для верификации сервера следующим образом. Настоящий сервер имеет секретный ключ, который соответствует общедоступному ключу, содержащемуся в его сертификате, переданном в сообщении SERVER-HELLO. Таким образом, настоящий сервер сможет извлечь и реконструировать пару ключей сессии (SERVER-READ-KEY и SERVER-WRITE-KEY). Наконец, только сервер, который выполнил корректно извлечение и дешифрование может правильно зашифровать CHALLENGE-DATA.
Это, по существу, "доказывает", что сервер имеет секретный ключ, который образует пару с открытым ключом из сертификата сервера.
Данные CHALLENGE-DATA должны иметь в точности ту же длину, что и в сообщении клиента CLIENT-HELLO. Их значение должно в точности согласовываться с посланным клиентом открыто в сообщении CLIENT-HELLO. Клиент должен дешифровать это сообщение и сравнить полученный результат с тем, что было послано, и только в случае успешного сравнения сервер считается достойным доверия. Если длины не совпадают или не согласуются значения, клиент соединение разрывает.
Это сообщение должно быть послано сервером клиенту либо после обнаружения идентификатора сессии (при этом посылается отклик SERVER-HELLO с флагом SESSION-ID-HIT не равным нулю) или когда сервер получает сообщение CLIENT-MASTER-KEY. Это сообщение должно быть послано до любого сообщения фазы 2 или до сообщения SEVER-FINISHED.
SERVER-FINISHED (Фаза 2; посылается зашифрованным)
char MSG-SERVER-FINISHED
char SESSION-ID-DATA[N-1]
Сервер посылает это сообщение, когда он удовлетворен результатом диалога с клиентом по поводу безопасности и готов продолжить передачу/прием протокольных данных верхнего уровня. Кэши идентификаторов сессии должны содержать копию MASTER-KEY, посланного в сообщении CLIENT-MASTER-KEY, в качестве мастерного ключа, предназначенного для генерации всех последующих ключей сессии.
Здесь "N" имеет то же значение, что и в определениях, представленных выше. Это сообщение должно посылаться после сообщения SERVER-VERIFY.
REQUEST-CERTIFICATE (Фаза 2; посылается шифрованным)
char MSG-REQUEST-CERTIFICATE
char AUTHENTICATION-TYPE
char CERTIFICATE-CHALLENGE-DATA[N-2]
Сервер может выдать этот запрос в любое время диалога второй фазы, требуя присылки сертификата клиента. Клиент немедленно откликается посылкой сообщения CLIENT-CERTIFICATE, если он имеет сертификат, в противном случае присылается уведомление об ошибке с кодом NO-CERTIFICATE-ERROR. CERTIFICATE-CHALLENGE-DATA представляет собой короткую строку байтов (с длиной і 16 байт и Ј 32 байтам), которую клиент использует для отклика на этот запрос.
Значение AUTHENTICATION-TYPE используется, чтобы выбрать конкретные средства для аутентификации клиента. Определены следующие типы:
SSL_AT_MD5_WITH_RSA_ENCRYPTION
Тип SSL_AT_MD5_WITH_RSA_ENCRYPTION требует, чтобы клиент сформировал MD5-дайджест сообщения, используя информацию, как это описано выше в разделе о сообщении CLIENT-CERTIFICATE. Раз дайджест сформирован, клиент шифрует его, используя свой секретный ключ. Сервер аутентифицирует клиента, когда получает сообщение CLIENT-CERTIFICATE.
Это сообщение может быть послано после сообщения SERVER-VERIFY и до сообщения SERVER-FINISHED.
Проводимые действия
На данный момент в вашем узле, надо полагать, полностью разработана политика безопасности и процедуры для конфигурации и управления вашей технологией поддержки этой политики. Как было бы здорово, если бы вы могли отсесть и расслабиться, будучи уверенны, что вы закончили работу с безопасностью. К сожалению, это невозможно. Ваши системы и сети не являются статическими, так что вам придется пересматривать политику и процедуры на регулярной основе. Существует много путей, которыми вы можете воспользоваться, чтобы решить проблему обновления. Ниже предлагается начальный набор, который вы можете дополнить с учетом требований вашего узла.
|
(1) |
Подпишитесь на справочную рассылку, которая осуществляется различными командами, которые специализируются на сетевых инцидентах, например, координационный центр CERT, и обновите ваши системы, чтобы избежать угроз, которые могут быть реализованы при технологии, используемой в вашем узле. |
|
(2) |
Отслеживайте и используйте программные поправки (patches), которые предлагаются поставщиком вашего оборудования. |
|
(3) |
Активно контролируйте конфигурацию ваших систем, чтобы идентифицировать любые изменения, которые могли произойти, и исследуйте все аномалии. |
|
(4) |
Ежегодно (как минимум) пересматривайте политику безопасности и все процедуры. |
|
(5) |
Читайте соответствующие почтовые списки рассылки и группы новостей USENET, чтобы быть в курсе всех новейших событий и знать обо всех важных новостях, сообщаемых вашими коллегами администраторами. |
|
(6) |
Регулярно проверяйте согласованность политики и процедур. Эта проверка должна выполняться человеком, который не принимал участие в формировании политики и процедур. |
Работа в экстренных ситуациях
Следует решить заблаговременно вопрос о том, кто должен руководить работами в экстремальной ситуации, определить субординацию. Имена и телефоны должностных лиц также как базовые IP-адреса следует хранить вне системы. Возможно, там (вне сети) следует держать и конфигурационную базу данных. Обычно руководитель ВЦ для этих работ не пригоден. Должно быть известно, где хранятся последние backup-копии жизненно важных частей ОС (помимо файла /etc/dumpdates). Для случай взлома WEB-сервера известной компании, нужно тщательно продумать тактику контакта со средствами массовой информации, клиентами. Это все настолько важно, что стоит подумать о необходимости специальных учений. Часто в таких ситуациях поток запросов серверу может резко возрасти (многие любопытные пытаются проверить слух об аварии, а слухи в сети распространяются как снежная лавина). Если ваш сервер не в полной мере восстановлен и излишняя загрузка для него губительна, позаботьтесь о передаресации избыточной части запросов на другой сервер, который будет уведомлять: “Извините, узел перегружен и в данный момент мы не можем обработать ваш запрос”. Рекомендуется использовать программу tripwire, чтобы согласовать действия системных администраторов, особенно если разные группы администраторов отвечают за разные аспекты работы одной ЭВМ. Например, “заплаты” СУБД Oracle и ОС могут конфликтовать друг с другом. В результате одна группа, поставившая “заплату” может и не подозревать, что текущая проблема является следствием действий другой группы. Программа tripwire идентифицирует, что и когда изменялось, и помогает доказать администраторам, что именно их действия явились причиной неполадок.
Раздача ключей и управление
Управление доступом для ключей является самой тяжелой проблемой, с которой приходится сталкиваться при обеспечении аутентификации в больших сетях Интернет. Протокол Нидхема-Шрёдера [NS78, NS87], который используется в системе Kerberos, базируется на централизованном сервере ключей. В больших корпоративных сетях требуется значительное число таких ключевых серверов, по крайней мере, один ключевой сервер на каждый административный домен. Существует также нужда в механизмах для отдельных ключевых серверов, необходимых для координирования генерации ключей сессий участников в различных административных доменах.
Большинство алгоритмов шифрования с использованием общедоступных ключей требуют достаточно больших вычислительных мощностей и по этой причине они неидеальны для шифрования пакетов в сети. Однако асимметричное свойство делает их очень полезными в начале сессии для получения симметричных ключей сессии. На практике, коммерческий сектор, вероятно, использует асимметричный алгоритм для цифровых подписей и пересылки ключей, но не для массового шифрования данных. Для целей пересылки ключей можно использовать алгоритмы RSA и Диффи-Хелмана [DH76]. Преимуществом асимметричной методики является отсутствие необходимости иметь центральный сервер для хранения и рассылки ключей. Система PEM использует цифровые подписи для аутентификации общедоступных ключей пользователей [Kent93]. Результатом этой операции является сертификат, который содержит общедоступный ключ партнера. Сертификаты ключей могут рассылаться различными способами. В одном из вариантов рассылка ключей встраивается в существующие службы каталогов. Это может быть сделано, например, путем расширения возможностей DNS и включения ключа ЭВМ в ресурсную запись нового типа.
Для мультикастных сессий, управление рассылкой ключей сложнее, так как число обменов, необходимых для широко используемых методик пропорционально числу участников.
Разделение услуг
Существует много услуг, которые узел может захотеть предоставить своим пользователям, некоторые из которых могут быть внешними. Существует много соображений безопасности, требующих изоляции услуг в пределах выделенных ЭВМ.
Услуги, которые узел может предоставить, в большинстве случаев, имеют различные уровни необходимости доступа и модели доверия. Услуги, которые важны с точки зрения безопасности или беспрепятственной работы узла, лучше разместить на специально выделенной ЭВМ с весьма ограниченным доступом (смотри раздел 3.1.3 модель "запрет всего"), а не на машине, предоставляющей услугу (или услуги), традиционно являющейся менее безопасной, или требующей более широкого доступа пользователей, которые могут спровоцировать подрыв безопасности.
Очень важно также уметь различать ЭВМ, которые работают с разными моделями доверия (например, все ЭВМ внутри контура firewall и любая ЭВМ незащищенной сети).
Некоторые услуги, которые следует учитывать, как потенциально изолируемые, рассмотрены в разделе 3.2.3. Важно помнить, что безопасность настолько надежна, насколько надежен самый слабый участок цепочки. Несколько наиболее известных проникновений за последние годы использовали уязвимость систем электронной почты. Атакеры не пытались украсть почтовые сообщения, они использовали уязвимость этой услуги для получения доступа к другим системам. Если возможно, каждая услуга должна работать на отдельной машине, чьей единственной заботой является предоставление специфицированных услуг. Это помогает изолировать атакера и ограничить потенциальный ущерб.
Разное
Комментарии начинаются с "/*" и завершаются "*/". Опционные компоненты выделяются с помощью помещения их в двойные квадратные скобки "[[ ]]". Однобайтовые объекты, содержащие не интерпретируемые данные, имеют 'непрозрачный' тип (opaque).
в сетях на периферии Интернет
Входная фильтрация трафика в сетях на периферии Интернет уменьшит эффективность DoS-атак с фальсификацией адреса отправителя. Сервис провайдеры и администраторы уже начали использовать этот тип фильтрации в периферийных маршрутизаторах. Рекомендуется внедрение такой фильтрации всеми сервис провайдерами причем как можно быстрее. Кроме избавления Интернет сообщества от такого типа атак, предлагаемый метод помогает сервис провайдерам локализовать источник атак.
Администраторы корпоративных сетей должны реализовать фильтрацию, чтобы гарантировать, что их корпоративные сети не станут источником подобных проблем. Действительно, фильтрация может использоваться в организации, чтобы гарантировать пользователям предотвращение возможностей проблем, сопряженных с некорректным подключением к сети. Фильтрация может также, на практике, блокировать анонимные атаки недовольных сослуживцев.
В ответственность всех сетевых администраторов входит предотвращение атак подобного рода.
RSA
Когда для аутентификации сервера и ключевого обмена используется RSA, 48- байтовый pre_master_secret генерируется клиентом, шифруется с помощью общедоступного ключа сервера и посылается серверу. Сервер использует свой секретный ключ для дешифрования pre_master_secret. Оба партнера преобразуют затем pre_master_secret в master_secret, как это специфицировано выше.
Цифровые подписи RSA реализуются с помощью PKCS #1 [PKCS1] с типом блока 1. Шифрование RSA с использованием общедоступного ключа выполняется с помощью PKCS #1 с типом блока 2.
Сертификат клиента
Это первое сообщение, которое может послать клиент после получения сообщения от сервера hello done. Это сообщение посылается только в случае запроса присылки сертификата со стороны сервера. Если приемлемого сертификата нет, клиент должен послать пустое сообщение сертификата. Если сервером для продолжения диалога требуется аутентификация клиента, он может откликнуться, послав уведомление о фатальной ошибке. Сертификаты клиента посылаются с использованием структуры сертификата, определенной в разделе 7.4.2.
Когда используется метод ключевого обмена, базирующийся на статическом методе Diffie-Hellman (DH_DSS или DH_RSA), если требуется аутентификация клиента, группа Diffie-Hellman и генератор закодированные в сертификате клиента должны соответствовать параметрам Diffie-Hellman'а, специфицированным сервером, если параметры клиента планируется использовать для ключевого обмена.
Сертификат сервера
Сервер должен послать сертификат, всякий раз, когда согласованный метод обмена ключами не является анонимным. За этим сообщением всегда непосредственно следует сообщение server hello.
Тип сертификата должен соответствовать выбранному алгоритму обмена ключами шифров, обычно это сертификат X.509v3. Он должен содержать ключ, который соответствует методу обмена ключами. Если не специфицировано обратного, алгоритм подписи для сертификата должен быть тем же, что и алгоритм для ключа сертификата. Если не специфицировано обратного, общедоступный ключ может иметь любую длину.
| Алгоритм обмена ключами | Тип сертификата ключа |
| RSA | Общедоступный ключ RSA; сертификат должен допускать использование ключа для шифрования. |
| RSA_EXPORT | Общедоступный ключ RSA с длиной больше чем 512 бит, который может быть использован для подписи, или ключ длиной 512 бит или короче, который может быть использован для шифрования или подписи. |
| DHE_DSS | Общедоступный ключ DSS. |
| DHE_DSS_EXPORT | Общедоступный ключ DSS. |
| DHE_RSA | Общедоступный ключ RSA, который может использоваться для подписи. |
| DHE_RSA_EXPORT | Общедоступный ключ RSA, который может использоваться для подписи. |
| DH_DSS | Ключ Diffie-Hellman. Алгоритмом, используемым для подписи сертификата, должен быть DSS. |
| DH_RSA | Ключ Diffie-Hellman. Алгоритмом, используемым для подписи сертификата, должен быть RSA. |
Все сертификатные профайлы, ключи и криптографические форматы определены рабочей группой IETF PKIX [PKIX]. Когда присутствует расширение использования ключа, бит digitalSignature должен быть установлен для ключа выбранного для подписи, как это описано выше, а бит keyEncipherment должен присутствовать, чтобы разрешить шифрование, как это описано выше. Бит keyAgreement должен быть установлен для сертификатов Diffie-Hellman.
Так как CipherSuites, который специфицирует методы нового ключевого обмена, заданы для протокола TLS, они используют формат сертификата и необходимые ключевые данные.
Структура этого сообщения:
opaque ASN.1Cert<1..224-1>;
struct { ASN.1Cert certificate_list<0..224-1>; } Certificate;
| certificate_list | Это последовательность (цепочка) сертификатов X.509v3. Сертификат отправителя должен быть записан в списке первым. Каждый следующий сертификат должен непосредственно сертифицировать предшествующий сертификат. Так как верификация сертификата требует, чтобы корневые ключи распределялись независимо, самоподписывающий сертификат, который специфицирует корневой источник сертификата, может быть опционно удален из цепочки, в предположении, что партнер должен уже иметь его, чтобы проверить его в любом случае. |
Тот же тип сообщения и структура будут использоваться для отклика клиента на сообщение запроса сертификата. Заметим, что клиент может не посылать сертификата, если он не имеет подходящего, чтобы послать его серверу в ответ на его аутентификационный запрос.
Серверы аутентификации и прокси (SOCKS, FWTK)
Прокси сервер предоставляет ряд улучшений безопасности. Он позволяет узлам концентрировать услуги посредством специально выделенной ЭВМ, что допускает мониторирование, сокрытие внутренней структуры и т.д. Такая скрытность услуг является привлекательной мишенью для потенциального атакера. Тип защиты, необходимой для прокси-сервера, сильно зависит от используемого прокси протокола и проксируемых услуг. Общим правилом ограничения доступа является разрешение доступа только машинам, которые действительно нуждаются в услугах. Причем даже для них разрешается доступ только к определенным видам услуг.
Серверы имен (DNS и NIS(+))
Интернет использует DNS (Domain Name System) для определения адресов ЭВМ и сетевых имен. Службы NIS (Network Information Service) и NIS+ не используются в глобальном Интернет, но являются причиной тех же рисков, что и DNS-сервер. Преобразование имени в адрес является критическим в отношении безопасного функционирования сети. Атакер, который может успешно управлять DNS-сервером, сможет перенаправить трафик, чтобы обойти защиту. Например, трафик для просмотра может быть перенаправлен на скомпрометированную систему; или, пользователи могут быть введены в заблуждения и они раскроют свои аутентификационные параметры. Организация должна создавать защищенные узлы, работающие в качестве вторичных серверов имен, и защитить свои DNS серверы от DoS-атак, использующих фильтрующие маршрутизаторы.
Традиционно DNS не имел средств обеспечения безопасности. В частности, информация, присылаемая в ответ на запрос, не может проверяться на предмет модификации и не может осуществляться верификация отправителя. Проделана работа по внедрению цифровых подписей в протокол, который в случае реализации, криптографически обеспечит целостность и верификацию информации (смотри RFC 2065).
Серверы ключей и паролей (NIS(+) и KDC)
Серверы паролей и ключей защищают жизненно важную информацию (т.e., пароли и ключи) с помощью алгоритмов шифрования. Однако даже пароли с однопроходным шифрованием могут быть раскрыты (здесь зашифрованные слова сравниваются с образцами, которые хранятся в памяти). Следовательно, необходимо гарантировать, что эти серверы недоступны для машин, которые не должны использовать этот вид услуги.
Сетевая безопасность
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Совсем недавно персональная ЭВМ стоила в России дороже автомашины, сегодня же десятки (а может быть и сотни) тысяч ЭВМ работают дома, развлекая и зарабатывая деньги своим хозяевам. Сети ЭВМ из достояния научных центров постепенно стали обязательным атрибутом процветающих торговых фирм, банков, милиции, таможни, налоговые службы и т.д. Если раньше главной проблемой было создание сети и обеспечение доступа к Интернет, то сегодня по мере увеличения размеров сети проблема безопасности выходит на лидирующие позиции. Безопасность - комплексное понятие, это и ограничение нежелательного доступа, и сохранность информации, и живучесть самой сети. Актуальность проблемы подтверждает количество RFC-документов, опубликованных за последнее время [1-14, 18] по данной тематике (см. библиографию в конце данного раздела). Эту статью следует рассматривать как обзор возможных угроз и способов защиты. В основном это касается обычных сетей, не содержащих конфиденциальную или тем более секретную информацию. Но многие соображения, приводимые здесь, носят достаточно универсальный характер.
Существуют юридические аспекты сетевой безопасности, организационные и программно-технические. Здесь будут рассмотрены два последних, тем более что следование букве закона не относится к числу главных добродетелей программистов. Рассмотрим сначала факторы, влияющие на надежность сети. Источниками ненадежности сети могут быть:
стихийные явления, к которым можно отнести отказы оборудования или питания, а также некомпетентность обслуживающего персонала;
несанкционированные действия операторов удаленных ЭВМ.
Основу стабильности сети составляют надежность ЭВМ и сетевого оборудования, а также устойчивость каналов связи. Каналы связи, особенно если речь идет о проводных, достались нам от проклятого царизма, их создатели давно умерли, и спросить не с кого. Начинать надо с того, что в вашей власти, а это, прежде всего, правильная конфигурация узла, разумное распределение ответственности и качество сетевого питания (стабильность напряжения и частоты, амплитуда помех).
Для решения последней проблемы используют специальные фильтры, мотор-генераторы и UPS (uninterruptable power supply). Выбор того или иного решения зависит от конкретных условий, но для серверов использование UPS крайне желательно (ведь вы не хотите восстанавливать дисковую систему, которая разрушилась из-за отключения питания в момент записи в FAT или dir). При выборе UPS нужно учесть суммарную потребляемую мощность оборудования, подключаемого к источнику питания, и время, в течение которого UPS способен работать без напряжения в сети. При этом главная задача UPS - обеспечение завершения операций обмена с диском до того, как произойдет полное обесточивание сервера, или когда будет произведено переключение на резервный канал питания. Это осуществимо при использовании специального интерфейса и соответствующего программного обеспечения, работающего согласно протоколу SNMP. Указанный интерфейс обеспечит блокировку начала новых операций обмена или выполнит shutdown, если напряжение в сети упало ниже допустимого уровня. К UPS не следует подключать дисплеи (эти приборы не столь критичны к питанию, как диски и оперативная память) и принтеры (лазерные принтеры запрещено подключать к UPS из-за мощных печек, входящих в состав этих приборов). Сетевые фильтры являются желательными при работе с любыми ЭВМ, так как сеть в России сильно засорена высокочастотными помехами.
С использованием нанотехнологии фирма IBM разработала запоминающее устройство с плотностью записи данных 1 Терабит на квадратный дюйм. Это позволяет записать 25 миллионов страниц или 25 DVD дисков на площади одной почтовой марки. Система использует тысячи сверх тонких иголок из кремния, которые служат для формирования миниатюрных углублений в тонкой синтетической пленке. Вершины иголок имеют размер нескольких атомов (диаметр ? 10нм). Технология допускает перезапись.Внедрение этой технологии на какое-то время решит проблему.
Поскольку абсолютная надежность недостижима, одним из средств сохранения информации является дублирование носителей (напр.
дисков), копирование и сохранение копий в надежном месте. Если раньше для этой цели годились гибкие диски или магнитные ленты, сегодня их пригодность может быть подвергнута сомнению. Конечно, ленты типа exabyte емкостью 2.5-20 Гбайт достаточно широко используются, но относительно высокая стоимость таких накопителей ограничивает их применимость (да и скорость записи для них не слишком высока). Альтернативой им могут стать накопители с перезаписываемыми CD, где стоимость устройства несколько ниже, за то емкость одного диска для дешевых моделей пока не превосходит 1 Гбайт. Не исключено, что в скором времени основным средством сохранения информации станет ее дублирование на независимом жестком диске. Это может произойти при широком внедрении компактных жестких дисков емкостью 10 Гбайт и более.
К сожалению, помимо объективных причин на надежность и устойчивость работы сети влияет и субъективный фактор. Это, прежде всего некомпетентный персонал, различные компьютерные вирусы и хакеры. Скрытая безработица среди высоко квалифицированных программистов способствует распространению хакерства в России. Практическое отсутствие сетевых вирусов связано с ограниченностью сетей в России и со сложностью их написания, но этот барьер будет скоро преодолен и к этому следует готовиться уже сегодня. Еще в декабре 1994 года я получил предупреждение о распространении сетевых вирусов (good times и xxx-1) по Интернет:
“there are two virus infected messages circulated in the internet.
one is called "good times" and the other "xxx-1".
do not read !! do not download !!! delete right away !!!!”
(Не читайте!! Не загружайте!!! Немедленно уничтожайте!!!!)
Или еще один более свежий пример
Сетевая информация, которую полезно собирать
Число различных сервисов, работающих на ЭВМ (например, telnet, ssh, rlogin, http, https, ldap, vns, irc, rpc, smtp и т.д.). Анализ этого списка и его вариаций со временем позволяет составить представление о возможной уязвимости системы. Определенную пользу может принести выявление ОС, установленных на ЭВМ сети (LINUX, Windows, FreeBSD и т.д.). Администратору проще иметь дело с одной ОС, но тотальная унификация имеет и недостатки. Один и тот же вирус или червь может парализовать единовременно всю сеть целиком. Понятно, что система сбора любых сетевых данных не должна поглощать заметной части ресурсов.
Рассмотрим признаки, которые могут свидетельствовать об успешном вторжении в ЭВМ (вариант ОС LINUX) (см. Network Security, V2004, Issue 8, "LINUX intrusion discovery: when security fails", Anton Chuvakin, август 2004, стр. 10-12):
Чрезмерная перегрузка ресурсов (ЦПУ, оперативной и дисковой памяти)
Частые сбои в работе ОС или приложений (самопроизвольная перезагрузка системы). Это может быть результатом, например, переполнения буферов или попытки поменять конфигурацию системы.
Появление необычных объектов (файлов, каталогов, акаунтов, процессов). К этому классу проявлений можно отнести запуск или остановку каких-то демонов, например, syslogd.
Необычная сетевая активность (новые соединения или резкое замедление сетевых операций).
Часто администратор лишь чувствует, что что-то происходит не так. Этого должно быть достаточно, чтобы начать исследования. Ниже приводится перечень команд, которые позволяют выявить и конкретизовать названные выше аномалии.
Для выявления файлов, существенно модифицированных в последнее время, что может свидетельствовать, например, о запуске программы типа sniffer, следует выполнить команду (наберитесь терпения, поиск будет происходить, начиная с корневого каталога):
find / -size +1000k -mtime +7 -print
Чтобы обнаружить наличие активных программ типа sniffer, можно выдать команду
ip link | grep PROMISC или /sbin/ifconfig
Наличие файлов Nobody может указывать, что атакер создал, использовал и затем удалил акаунт нового пользователя.
Выявить такие объекты можно с помощью команды:
find / -nouser -print
Для обнаружения файлов SUID root в необычных местах (например, вне каталогов /sbin и /bin), что иногда указывает на попытку сформировать люк для последующего входа в систему, следует выполнить команду.
find / -uid 0 -perm -4000 -print
Для выявления файлов с необычными именами (например, ".", " ", "..." и т.д.), что указывает на работу начинающего хакера, следует исполнить команду.
find / -name "..." -print
Для поиска подозрительных акаунтов (новые аккоунты с системными привилегиями) можно выполнить команду:
grep :0: /etc/passwd
Попытки хакера установить свое программное обеспечение часто приводит к повреждению системных или прикладных программ. В системе RedHat имеется встроенная система RPM (RedHat Package Manager), которая позволяет выявить такие повреждения. Например, команда
rpm -qa | # rpm -Va | sort
поможет решить эту проблему. Для этой же цели можно использовать программу chkrootkit (www.chkrootkit.org).
Просмотрев список активных процессов с помощью команды ps -aux, следует обратить внимание на демоны, проход к которым начинается с символа точка, а также на любые необычные имена процессов. Чтобы узнать подробности, следует заглянуть непосредственно в каталог /proc. Например, выдав команду cat /proc/20999, где 20999 - pid процесса. Для выявления прослушивающих сервисов можно выдать команду netstat -nap.
Число официально зарегистрированных в мире сетевых инцидентов различного рода возрастает экспоненциально, о чем можно судить по рис. 5. (см. http://www.cert.org/stats/). Этот рост совпадает с ростом числа узлов в интернет, так что процент хулиганов и шизефреников величина похоже инвариантная. Атаки можно разделить на несколько классов:
Базирующиеся на дефектах протоколов, например, TCP.
Использующие дефекты операционной системы
Пытающиеся найти и воспользоваться дефектами программ-приложений, включая, например, CGI
Эксплуатирующие человеческие слабости (любопытство, алчность (загрузка бесплатного программного обеспечения) и пр., например, троянские кони)
Список номеров портов для известных троянских коней можно найти в http://www.simovits.com/nyheter9902.html
В В 2004 году зарегистрировано 523 109 сетевых инцидентов (это явилось результатом мониторинга 450 сетей в 35 странах мира). Из них 41% атак соответствовали различным видам несанкционированной активности, 26% - попытки несанкционированного доступа, 21% - представляли собой сканирования, 9% - DoS атаки и 3% - попытки некорректного использования приложений. Особенно популярно в последнее время использование уязвимостей броузеров. За последние шесть месяцев 2005 года выявлено более 1000 новых сетевых червей и вирусов (см., например, http://www.acmqueque.com). Большинство вирусов и червей с самого начала делаются полиморфными и метаморфными. Разработчиками предпринимаются специальные меры по их маскировке. Некоторые виды этих вредоносных программ, попав в ЭВМ жертвы, выявляет возможные уязвимости (результат такого исследования может быть передан автору программы по IRC каналам) для последующих атак с привлечением других средств. Появились даже черви, которые уничтожают другие вредоносные программы в ЭВМ-жертве.
Внутренняя структура и функциональность вирусов и червей существенно усложняется. Они уже могут подбирать для себя специфические объекты для атаки. Для этих целей вирусы и черви используют информационные ресурсы, например, поисковые системы типа Google. Таким образом, они уменьшают вероятность обнаружения и повышают число жертв, так как время от момента разработки до детектирования и выработки средства противодействия увеличивается.
Если раньше большинство атак имели своей целью мелкое хулиганство, форму самоутверждения или спортивный интерес, теперь все больший процент атак преследует преступные цели и коммерческий интерес. Хакеры готовят и продают наборы взломанных ими ЭВМ для рассылки спама, фишинга и для DoS атак. На данном этапе эти атаки предпринимаются против полулегального бизнеса (азартные игры через Интернет, порнографические сайты и т.д.). В последнее время отмечается тенденция применения сетевых атак с политической мотивацией.
Данная тенденция означает, что средства вторжения будут выполнены все более профессионально.
К первому типу относятся и атаки типа SMURF, ICMP flood и TCP SYN flood. ICMP flood не использует эффектов усиления на локальных широковещательных адресах, а работает c адресами типа 255.255.255.255. Здесь следует заметить, что для аналогичных целей хакеры могут использовать и протоколы TCP или UDP.
Рис. 5. Распределение числа официально зарегистрированных сетевых инцидентов по годам.
Разнообразие угроз, подстерегающих пользователя, работающего в сети, огромно. Часть из них является платой за использование сложных информационных технологий, уязвимых к внешним воздействиям, другая часть сопряжена с деятельностью людей. Некоторые угрозы носят объективный характер, например, нестабильность или низкое качество питающего напряжения, электромагнитные наводки или близкие грозовые разряды, другие могут быть связаны с невежеством или неаккуратностью самого пользователя. На рис. 6. сделана попытка составить классификацию существующих угроз (схему нельзя рассматривать исчерпывающей).
Рис. 6. Схема классификации угроз
Ниже на рис. 7 показано распределение атак сети ИТЭФ по их разновидностям (Это и последующие два распределения построены студентом МФТИ А.Тарховым).
Рис. 7.
На рис. 8 показана зависимость числа атак от времени суток, полученная за 19 дней.
На рис. 9 показано распределение атак по доменным зонам. Из распределения видно, что этому занятию предаются чаще всего "жители" больших и комерческих сетей. Хотя нельзя исключить, что именно они являются чаще жертвами хакеров.
Рис. 9.
Для того чтобы писать и эффективно поддерживать программы распознавания атак, надо знать и учитывать распределение атак по сигнатурам, по времени суток (не исключено, что перечень регистрируемых сигнатур может меняться для дневного и ночного времени), по сложности распознавания и методам противодействия. Вычислительные ресурсы ЭВМ-регистратора всегда будут критическим параметром, так как число атак в единицу времени, и количество разных сигнатур будет только расти.
По этой причине вряд ли когда-либо можно будет позволить мониторировать все известные виды атак. Да и необходимость этого не очевидна (вряд ли сейчас нужно контролировать атаки ОС DOS). Здесь не рассматриваются проблемы информационной безопасности (аутентификация, сертификация, шифрование файлов и пакетов и пр.). В таблице 1 представлено распределение атак по определенным классам. (смотри http://advice.networkice.com/advice/Intrusions/)
Таблица 1
| Использование вирусов и червей | 9 | 1.3 | |
| Атаки уязвимостей протоколов | TCP | 15 | 2 |
| HTTP | 69 | 9.2 | |
| SNMP | 79 | 10.5 | |
| SMTP | 40 | 5.3 | |
| DNS | 21 | 2.8 | |
| SAMBA | 15 | 2 | |
| Telnet | 17 | 2.2 | |
| POP3 | 12 | 1.4 | |
| IMAP | 6 | 0.7 | |
| NNTP | 3 | 0.35 | |
| Finger | 11 | 1.3 | |
| FTP | 41 | 5.4 | |
| TFTP | 12 | 1.4 | |
| Rlogin | 5 | 0.6 | |
| IDENT | 5 | 0.6 | |
| Radius | 2 | 0.3 | |
| RPC | 42 | 5.6 | |
| Атаки через CGI | 49 | 6.5 | |
| Троянские кони | >40 | 5.3 | |
| Сканирование портов | 48 | 6.4 | |
| DoS | 12 | 1.6 | |
| Автоматический подбор паролей (login) | 10 | 1.3 | |
| Некорректные параметры заголовков пакетов и запросов | 22 | 2.3 | |
| Прочие | 167 | 22 | |
| Итого | 753 |
В статистику не были включены атаки маршрутизаторов (например, CISCO, Ascend и пр.), специфических серверов (например, поисковых, почтовых, печати, Firewall), атаки разнообразных драйверов баз данных, фальсификация МАС-адресов, перехват ключей, сертификатов и паролей и т.д. Реальное число зарегистрированных сигнатур атак, полагаю, давно перевалило за 1000.
Важным фактором является актуальность базы данных сигнатур, ведь наличие сигнатуры в базе данных не означает присутствия этого типа атак во входящем трафике. Некоторые сигнатуры “выходят из моды” быстро и навсегда.
Сигнатуры, распознаваемые по заголовку пакета, составляют несколько более 15% (здесь учтены манипуляции с заголовками SNMP, включая community, а также фальсификации DNS-заголовков).
Сюда следует, разумеется, отнести и подбор кода community.
Заметный процент составляют атаки, рассчитывающие достичь эффекта путем переполнения буфера (входного буфера приложения, пароля, имен и т.д.), это - 11.3%. Это один из самых сложных случаев, ведь надо знать размер буфера для каждого приложения, которое может стать объектом атаки.
Атаки на CGI сопряжены с генерацией нестандартных строк URL и параметров (6.5%), некоторые из них также работают в расчете на переполнение буфера параметров.
Некоторые сигнатуры, требуют анализа не только входящего, но и исходящего трафика (например, шторм неспровоцированных откликов), что существенно усложняет алгоритм распознавания (смотри комментарии к рис. 11).
Атаки, связанные с рассылкой вирусов, червей, кроликов, троянских коней или молдавская связь, как правило требуют для достижения цели сотрудничества со стороны жертвы (используется алчность, любопытство или хотя бы беспечность).
Мало зарегистрировать атаку, надо определить и корректно интерпретировать IP-адрес, откуда эта атака исходит. Чаще всего, имея IP-адрес, достаточно легко отследить путь атаки, например посредством Trace Route. Полезным может оказаться утилита NSLookup, а также служба Whois, которая позволяет определить сервис-провайдера атакера и его географическое положение.
Но существует класс атак с фальсификацией адреса отправителя, когда эту задачу решить затруднительно. Эта техника используется большинством атак отказа обслуживания (DoS), а также некоторыми другими. Два примера такого типа атак описаны на рис. 10 и 11.
Атака через прокси (например, при наличии загруженной в ЭВМ SOCKS программы WinGate) представлена на рис. 10.
Здесь атакер (hacker на рисунке) использует прокси-сервер, через который связаны с Интернет ЭВМ на левой части рисунка, для атаки машины (victim). При этом для атакуемой машины будет казаться, что ее атакует ЭВМ SOCKS. Особенностью этого класса атаки является то, что атакер может находиться где угодно в Интернет. Но в случае жалобы со стороны ЭВМ-жертвы его положение может быть легко локализовано.
На рис. 11 показана схема атаки с зеркалированием пакетов в маршрутизаторе R. Маршрутизатор R сконфигурирован так, чтобы копии пакетов, следующих из ЭВМ А в ЭВМ В, попадали в машину Х (ЭВМ атакера). В данной схеме атакер должен договориться с администратором R (если это не он сам), так как нужна специфическая конфигурация маршрутизатора. Но он может выйти из положения, сформировав на своей ЭВМ ложный маршрутизатор, поддерживающий протокол внешней маршрутизации BGP.
Такая схема позволяет Х атаковать А, создавая впечатление, что ее атакует ЭВМ В. Для ЭВМ В будет иметь место эффект шторма неспровоцированных откликов со стороны ЭВМ А (если для атаки использован протокол ТСР).
Для распознавания сигнатуры атаки в ЭВМ В нужно регистрировать входящие пакеты с адресом А и флагом ACK, проверяя в то же время факт, что ЭВМ В не посылала А никаких пакетов.
Данная схема атак (с фальсификацией адреса отправителя) пригодна также и для относительно безопасной рассылки SPAM.
В таблице представлен , не претендующий на полноту. См. также http://advice.networkice.com/advice/Intrusions/. Список номеров портов для известных троянских коней можно найти в www.simovits.com/nyheter9902.html
Сетевые экраны (Firewalls)
Одной из широко используемых мер безопасности является применение сетевых экранов - firewall. Сетевые экраны считаются панацеей от многих, если не от всех проблем безопасности в Интернет. Но это не так. Сетевые экраны являются лишь инструментом системы безопасности. Они предоставляют определенный уровень защиты и являются вообще средством реализации политики безопасности на сетевом уровне. Уровень безопасности, который предоставляет сетевой экран, может варьироваться в зависимости от требований безопасности конкретной машины. Существует традиционный компромисс между безопасностью, простотой использования, стоимостью, сложностью и т.д. Сетевой экран является одним из нескольких механизмов, используемых для управления и наблюдения за доступом к и из сети с целью ее защиты. Сетевой экран действует как шлюз, через который проходит весь входной и выходной трафик защищенной сети. Сетевые экраны помогают установить ограничения на число и тип коммуникаций, которые осуществляются между защищенной сетью и прочими сетями (например, Интернет или другой частью сети узла).
Сетевой экран является способом построения стены между одной частью сети, например, внутренней сетью компании, и глобальным Интернет. Уникальной чертой этой стены является наличие дверей, через которые при тщательном контроле проходит некоторый трафик. Трудной частью такой системы является установление критериев того, какие пакеты разрешить, а каким запретить проход через эти двери. В книгах, написанных о сетевых экранах, используется разная терминология для описания различных форм сетевых экранов. Это может сбивать системных администраторов, которые не знакомы с сетевыми экранами. Следует здесь заметить, что не существует стандартной терминологии для описания сетевых экранов.
Сетевые экраны не обязательно представляют собой отдельную машину. Сетевые экраны скорее представляют собой комбинацию маршрутизаторов, сетевых сегментов, и рабочих станций. Следовательно, в рамках данного обсуждения, термин "сетевой экран" предполагает наличие более одного физического устройства, фильтрующих маршрутизаторов и прокси-серверов.
Фильтрующие маршрутизаторы представляют собой простейший компонент сетевого экрана. Маршрутизатор передает данные в обоих направлениях между двумя (или более) разными сетями. "Нормальный" маршрутизатор принимает пакет из сети A и "переадресует" его к месту назначения в сети B. Фильтрующий маршрутизатор делает то же самое, но решает не только как маршрутизовать пакет, но также следует ли этот пакет посылать куда-либо вообще. Это делается путем установки ряда фильтров, с помощью которых маршрутизатор решает, что делать конкретно с данным пакетом.
При подготовке маршрутизатора для фильтрации пакетов, важны следующие критерии политики отбора: IP-адреса отправителя и получателя, номера TCP-портов отправителя и получателя, состояние бита TCP "ack", номера UDP-портов отправителя и получателя, и направление передачи пакетов (т.e., A->B или B->A). Другой информацией, необходимой для формирования схемы безопасной фильтрации, является, меняет ли маршрутизатор порядок инструкций фильтрации (с целью оптимизации фильтров, это может иногда изменить значение и привести к непреднамеренному доступу), и можно ли использовать фильтры для входящих и выходящих пакетов на каждом из интерфейсов. Если маршрутизатор фильтрует только выходные пакеты, тогда он является внешним по отношению своих фильтров и может быть более уязвим для атак. Кроме уязвимости маршрутизатора, это различие между фильтрами, используемыми для входных и выходных пакетов, является особенно важным для маршрутизаторов с более чем 2 интерфейсами. Другими важным моментом является возможность создавать фильтры на основе опций IP-заголовка и состояния фрагментов пакета. Формирование хорошего фильтра может быть очень трудным и требовать хорошего понимания типа услуг (протоколов), которые будут фильтроваться.
Для лучшей безопасности, фильтры обычно ограничивают доступ между двумя связанными сетями к лишь одной ЭВМ. Можно получить доступ к другой сети только через эту защищенную машину. Так как только эта ЭВМ, а не несколько сот машин, может быть атакована, легче поддержать определенный уровень безопасности, так как именно эта машина может быть защищена особенно тщательно.
Чтобы сделать доступными через этот сетевой экран ресурсы для легальных пользователей услуги должны переадресовываться соответствующим серверам через эту защищенную машину. Некоторые серверы имеют встроенную переадресацию (например, DNS-серверы или SMTP-серверы), для других услуг (например, Telnet, FTP, и т.д.) могут использоваться прокси серверы, чтобы обеспечить доступ к ресурсам безопасным способом через firewall.
Прокси сервер является средством передаресации прикладных услуг через одну машину. Существует обычно одна машина (защищенная ЭВМ), которая действует в качестве прокси сервера для широкого списка протоколов (Telnet, SMTP, FTP, HTTP, и т.д.), но могут быть индивидуальные машины для некоторых видов услуг. Вместо непосредственного соединения с внешним сервером, клиент подключается к прокси серверу, который в свою очередь инициирует соединение с запрашиваемым внешним сервером. В зависимости от используемого прокси сервера можно конфигурировать внутренних клиентов так, чтобы они осуществляли это перенаправление автоматически, без информирования пользователя, другие могут требовать, чтобы пользователь сам подсоединялся к прокси серверу и затем инициировал подключение в рамках специального формата.
Применение прокси сервера предоставляет существенные преимущества в обеспечении безопасности. Имеется возможность добавления списков доступа для протоколов, требующие от пользователей или систем обеспечения определенного уровня аутентификации прежде чем доступ будет предоставлен. Могут быть запрограммированы продвинутые прокси серверы, иногда называемые ALG (Application Layer Gateways), которые ориентированы на определенные протоколы. Например, ALG для FTP может отличать команду "put" от "get"; организация может пожелать разрешить пользователям выполнять "get" для файлов из Интернет, но запретить "put" для локальных файлов на удаленном сервере. Напротив, фильтрующий маршрутизатор может блокировать или нет FTP-доступ, но не может реализовывать частичные запреты.
Прокси серверы могут также конфигурироваться для шифрования потоков данных на основе разнообразных параметров. Организация может использовать эту особенность, чтобы разрешить криптографические соединения между двумя узлами, один из которых размещен в Интернет.
Сетевые экраны обычно рассматриваются как средство блокировки доступа для атакеров, но они часто используются в качестве способа доступа легальных пользователей к узлу. Существует много примеров, когда легальному пользователю может быть нужно получать регулярно доступ к базовой странице во время презентаций, конференций и т.д. Доступ к Интернет бывает часто реализован через ненадежную машину или сеть. Правильно сконфигурированный прокси сервер может допускать правильных пользователей в узел, блокируя доступ всех остальных.
В настоящее время наилучшим вариантом сетевого экрана считается комбинация двух экранирующих маршрутизаторов и одного или более прокси серверов в сети между маршрутизаторами. Такая схема позволяет внешнему маршрутизатору блокировать любые попытки использования нижележащего IP-уровня для разрушения безопасности (IP-фальсификация, маршрутизация отправителя, фрагменты пакетов), в то же время прокси сервер защищает окна уязвимости на уровне верхних протоколов. Целью внутреннего маршрутизатора является блокировка всего трафика кроме направленного на вход прокси сервера. Если реализована эта схема, может быть обеспечен высокий уровень безопасности.
Большинство сетевых экранов предоставляют систему журналов, которые могут настраиваться, чтобы сделать администрирование безопасности сети более удобным. Система мониторинга может быть централизована, а система сконфигурирована так, чтобы посылать предупреждения при возникновении ненормальной ситуации. Важно регулярно просматривать журнальные файлы при малейшем признаке вторжения или попытки взлома. Так как некоторые атакеры будут пытаться скрыть свои следы путем редактирования журнальных файлов, желательно защитить эти файлы. Существует много способов, включая: драйвы WORM (write once, read many), бумажные журналы и централизованные журнальные файлы, организованные через утилиту "syslog".
Еще одним методом является использование "фальшивого" последовательного принтера, где последовательный порт соединен с изолированной машиной, где хранятся журнальные файлы.
Существуют сетевые экраны в широком диапазоне качества и мощности. Цена коммерческого варианта начинается примерно с $10,000US и достигает $250,000US. "Самодельные" сетевые экраны могут быть построены за меньшую сумму. Следует учитывать, что правильная конфигурация сетевого экрана (коммерческого или самодельного) требует определенного мастерства и знания TCP/IP. Оба типа требуют регулярного обслуживания, установки пакетов обновления и корректировки программ и непрерывного контроля. При оценке бюджета сетевого экрана, эти дополнительные издержки должны также учитываться наряду с аппаратной частью сетевого экрана.
Сетевые экраны могут оказать помощь при обеспечении безопасности узла, они защищают от большого числа атак. Но важно иметь в виду, что они являются лишь частью решения. Они не могут защитить ваш узел от всех типов атак.
Симметричная криптография
Симметричная криптография включает в себя все системы, которые используют один и тот же ключ для шифрования и дешифрования. Таким образом, если кто-либо получит ключ, он сможет дешифровать и читать информацию, зашифрованную с его помощью. Такое лицо сможет шифровать и посылать любые данные, выдавая их за информацию, посланную легальным владельцем этого секретного ключа. Это означает, что знание ключа нежелательным третьим лицом полностью компрометирует конфиденциальность системы. Следовательно, используемые ключи должны доставляться безопасным способом, либо курьером, либо с применением специального протокола пересылки ключей, лучшим из которых является алгоритм Нидхэма-Шрёдера [NS78, NS87]. Широко используется алгоритм DES (Data Encryption Standard), который был стандартизован для защиты правительственной информации в США. Он представляет собой один из лучших симметричных алгоритмов шифрования [NBS77].
Хорошо известной системой, работающей в открытых сетях, является система аутентификации Kerberos (TM), которая была разработана в рамках проекта Athena в MIT [SNS88, BM91, KN93]. Система Kerberos базируется на алгоритме DES и использует специальный сервер, который хранит секретные ключи всех пользователей и услуг. Он может генерировать коды, которые позволяют пользователям и процессам идентифицировать себя в других системах. Как в любой схеме с распределенной аутентификацией, эти верительные коды работают в пределах местного административного домена. Следовательно, если пароль пользователя раскрыт, злоумышленник будет способен маскироваться под этого пользователя и проникнуть в любую систему, обслуживаемую Kerberos. Так как сервер Kerberos знает все секретные ключи, он должен быть достаточно безопасным. Ключи сессии Kerberos могут использоваться для обеспечения конфиденциальности при обмене между любыми объектами в пределах зоны действия сервера.
Система Firewall
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Учитывая важность проблемы защиты, разработана специальная система firewall ("огненная стена”). Система firewall заменяет маршрутизатор или внешний порт сети (gateway). Защищенная часть сети размещается за ним. Пакеты, адресованные Firewall, обрабатываются локально, а не просто переадресуются. Пакеты же, которые адресованы объектам, расположенным за Firewall, не доставляются. По этой причине хакер вынужден иметь дело с системой защиты ЭВМ Firewall. Схема взаимодействия Firewall с локальной сетью и внешним Интернет показана на рис. 6.3.1.
Рис. 6.3.1. Схема Firewall
Такая схема проще и надежнее, так как следует заботиться о защите одной машины, а не многих. Экран, маршрутизатор и ЭВМ управления экраном объединены небольшой, незащищенной локальной сетью. Основные операции по защите осуществляются здесь на IP-уровне. Эту схему можно реализовать и на одной ЭВМ, снабженной двумя интерфейсами. При этом через один интерфейс осуществляется связь с Интернет, а через второй – с защищенной сетью. Такая ЭВМ совмещает функции маршрутизатора-шлюза, экрана и управления экраном. Возможна реализация Firewall, показанная на рис 6.3.2. Здесь функция экрана выполняется маршрутизатором.
Рис. 6.3.2. Схема Firewall, где функцию экрана выполняет маршрутизатор
В этой схеме доступ из Интернет возможен только к прокси-серверу, ЭВМ из защищенной сети могут получить доступ к Интернет тоже только через прокси-сервер. Ни один пакет посланный из защищенной ЭВМ не может попасть в Интернет и, аналогично, ни один пакет из Интернет не может попасть непосредственно защищенной ЭВМ. Возможны и другие более изощренные схемы, например со вторым “внутренним” Firewall для защиты от внутренних угроз.
Недостатки FireWall происходят от ее преимуществ, осложняя доступ извне, система делает трудным и доступ наружу. По этой причине система FireWall должна выполнять функции DNS (сервера имен) для внешнего мира, не выдавая никакой информации об именах или адресах внутренних объектов, функции почтового сервера, поддерживая систему псевдонимов для своих клиентов.
Псевдонимы не раскрываются при посылке почтовых сообщений во внешний мир. Служба FTP в системе может и отсутствовать, но если она есть, доступ возможен только в сервер FireWall и из него. Внутренние ЭВМ не могут установить прямую FTP-связь ни с какой ЭВМ из внешнего мира. Процедуры telnet и rlogin возможны только путем входа в сервер FireWall. Услуги типа NFS, rsh, rcp, finger и т.д. не допускаются. Ни одна из ЭВМ в защищенной сети не может быть обнаружена с помощью PING (ICMP) извне. И даже внутри сети будут возможны только определенные виды трафика между строго определенными машинами. Понятно, что в целях безопасности защищенная сеть не может иметь выходов во внешний мир помимо системы экран, в том числе и через модемы. Экран конфигурируется так, чтобы маршрут по умолчанию указывал на защищенную сеть. Экран не принимает и не обрабатывает пакеты внутренних протоколов маршрутизации (например, RIP). ЭВМ из защищенной сети может адресоваться к экрану, но при попытке направить пакет с адресом из внешней сети будет выдан сигнал ошибки, так как маршрут по умолчанию указывает назад в защищенную сеть. Для пользователей защищенной сети создаются специальные входы для FTP (см. библиографию раздела 6 ), telnet и других услуг. При этом не вводится каких-либо ограничений по транспортировке файлов в защищенную сеть и блокируется передача любых файлов из этой сети, даже в случае, когда инициатором FTP-сессии является клиент защищенной сети. Единственные протоколы, которым всегда позволен доступ к ЭВМ Firewall являются SMTP (электронная почта) и NNTP (служба новостей). Внешние клиенты Интернет не могут получить доступа ни к одной из защищенных ЭВМ ни через один из протоколов. Если нужно обеспечить доступ внешним пользователям к каким-то данным или услугам, для этого можно использовать сервер, подключенный к незащищенной части сети (или воспользоваться услугами ЭВМ управления экраном, что нежелательно, так как снижает безопасность). ЭВМ управления экраном может быть сконфигурирована так, чтобы не воспринимать внешние (приходящие не из защищенной сети) запросы типа FTP, telnet и пр., это дополнительно повысит безопасность.
Стандартная система защиты здесь часто дополняется программой wrapper (см. раздел 6 “Сетевая безопасность в Интернет”). Немалую пользу может оказать и хорошая система регистрации всех сетевых запросов. Системы FireWall часто используются и в корпоративных сетях, где отдельные части сети удалены друг от друга. В этом случае в качестве дополнительной меры безопасности применяется шифрование пакетов. Система FireWall требует специального программного обеспечения. Следует иметь в виду, что сложная и дорогостоящая система FireWall не защитит от “внутренних” злоумышленников. Нужно тщательно продумать систему защиты модемных каналов (сама система FireWall на них не распространяется, так как это не внешняя часть сети, а просто удаленный терминал).
Если требуется дополнительная степень защиты, при авторизации пользователей в защищенной части сети могут использоваться аппаратные средства идентификации, а также шифрование имен и паролей.
При выборе той или иной системы Firewall следует учитывать ряд обстоятельств.
Операционная система. Существуют версии Firewall, работающие с UNIX и Windows NT. Некоторые производители модифицируют ОС с целью усиления безопасности. Выбирать следует ту ОС, которую вы знаете лучше.
Рабочие протоколы. Все Firewall могут работать с FTP (порт 21), e-mail (порт 25), HTTP (порт 80), NNTP (порт 119), Telnet (порт 23), Gopher (порт 70), SSL (порт 443) и некоторыми другими известными протоколами. Как правило, они не поддерживают SNMP.
Типы фильтров. Сетевые фильтры, работающие на прикладном уровне прокси-сервера, предоставляют администратору сети возможность контролировать информационные потоки, проходящие через Firewall, но они обладают не слишком высоким быстродействием. Аппаратные решения могут пропускать большие потоки, но они менее гибки. Существует также “схемный” уровень прокси, который рассматривает сетевые пакеты, как черные ящики и определяет, пропускать их или нет. Отбор при этом осуществляется по адресам отправителя, получателя, номерам портов, типам интерфейсов и некоторым полям заголовка пакета.
Система регистрации операций. Практически все системы Firewall имеют встроенную систему регистрации всех операций. Но здесь бывает важно также наличие средств для обработки файлов с такого рода записями.
Администрирование. Некоторые системы Firewall снабжены графическими интерфейсами пользователя. Другие используют текстовые конфигурационные файлы. Большинство из них допускают удаленное управление.
Простота. Хорошая система Firewall должна быть простой. Прокси-сервер (экран) должен иметь понятную структуру и удобную систему проверки. Желательно иметь тексты программ этой части, так как это прибавит ей доверия.
Туннелирование. Некоторые системы Firewall позволяют организовывать туннели через Интернет для связи с удаленными филиалами фирмы или организации (системы Интранет). Естественно, что информация по этим туннелям передается в зашифрованном виде.
Информацию по системам Firewall можно найти по следующим адресам.
| URL | Содержание |
| http://search.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html | Автоматическая конфигурация прокси для Netscape и Microsoft броузеров |
| http://www.software.digital.com | Alta Vista Firewall |
| http://www.cyberguardcorp.com/ | CyberGuard Firewall |
| http://www.raptor.com/ | Eagle Firewall |
| http://www.checkpoint.com/ | Firewall-1 |
| http://www.tis.com/ | Gauntlet Firewall |
| http://www.on.com/ | ON Guard Firewall |
| http://www.sctc.com | BorderWare Firewall |
| ftp://ftp.nec.com/pub/socks/ | SOCKS прокси |
| ftp://ftp.tis.com/pub/firewalls/toolkit | Средства для работы с Firewall |
| majordomo@greatcircle.com | Подписной лист по проблематике Firewall. Для подписки в тело сообщения следует поместить subscribe firewall. Там же имеется архив: |
Системы шифрования
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Проблема сокрытия содержания послания при его транспортировке волновала людей с древних пор. Известно, что еще Цезарь (100-44 годы до нашей эры) при переписке использовал шифр, получивший его имя. В 1518 году Джоанес Тритемиус написал первую книгу по криптографии, где впервые были описаны многоалфавитные подстановочные шифры. Лишь в 1918 году во время первой мировой войны в Германии была применена шифровальная система ADFGVX. Позднее в 1933-45 годах в Германии была разработана и применена первая шифровальная машина (на этом принципе работает система crypt в UNIX). Мощное развитие криптография получила в период второй мировой войны. С этой шифровальной машиной связан и первый успех в области вскрытия сложных шифров.
Чаще всего шифруются тексты документов, но в последнее время шифрованию подвергаются и изображения, голосовые данные и даже тексты программ.
Шифрование предполагает преобразование исходного текста Т с использованием ключа К в зашифрованный текст t. Симметричные криптосистемы для шифрования и дешифрования используется один и тот же ключ К. Появившиеся в последние годы системы с открытым ключом, осуществляют шифрование с помощью общедоступного ключа, для дешифрования в этом случае необходим секретный ключ, который порождается совместно с открытым. Как шифрование, так и дешифрование может реализоваться программно или аппаратно. При этом должны выполняться определенные требования:
Знание использованного алгоритма не должно снижать надежность шифрования.
Длина зашифрованного текста должна быть равна длине исходного открытого текста (это требование относится к числу желательных и выполняется не всегда).
Зашифрованный текст не может быть прочтен без знания ключа.
Каждый ключ из многообразия ключей должен обеспечивать достаточную надежность.
Изменение длины ключа не должно приводить к изменению алгоритма шифрования.
Если известен зашифрованный и открытый текст сообщения, то число операций, необходимых для определения ключа, не должно быть меньше полного числа возможных ключей.
Дешифрование путем перебора всех возможных ключей должно выходить далеко за пределы возможностей современных ЭВМ.
Если при шифровании в текст вводятся дополнительные биты, то алгоритм их внесения должен быть надежно скрыт.
Не должно быть легко устанавливаемой зависимости между последовательно используемыми ключами.
Алгоритм может быть реализован аппаратно.
В симметричных криптосистемах могут использоваться одно- или многоалфавитные подстановки (например, одно-алфавитная подстановка Цезаря), при этом производится замена символов исходного текста на другие с использованием достаточно сложных алгоритмов. Многоалфавитные подстановки несравненно более надежны. К числу простых методов шифрования относится способ перестановок символов исходного текста (этот метод эффективен только лишь при достаточно большой длине исходного текста). Множество перестановок символов для текста из N символов равно N!, что до какой-то степени гарантирует надежность процедуры. Несколько большую надежность предлагает метод гаммирования, когда на исходный текст накладывается псевдослучайная последовательность бит, генерируемая на основе ключа шифрования, например, с использованием операции исключающего ИЛИ. Обратное преобразование (дешифрование) выполняется генерацией точно такой же псевдослучайной последовательности и наложением ее на зашифрованной текст. Гаммирование уязвимо для случая, когда злоумышленнику становится известен фрагмент исходного текста. В этих обстоятельствах он без труда восстановит фрагмент псевдослучайной последовательности, а по нему и всю последовательность. Так если достаточно большое число сообщений начинается со слов "Секретно", а в конце ставится дата сообщения, расшифровка становится вопросом времени и терпения.
Ключ может быть одноразового и многоразового использования. Одноразовый ключ достаточно большой длины (или бесконечный) может обеспечить сколь угодно высокую надежность, но его использование создает неудобства, связанные с его транспортировкой (ключ должен быть как-то доставлен получателю зашифрованного послания).
В табличке 6.4. 1 приведен пример использования такого вида ключа.
Таблица 6.4.1.
| Исходный текст | 9 | 5 | 18 | 1 | 3 | 19 | 20 | 3 | 21 | 11 | 20 | 6 |
| Используемый ключ | 23 | 5 | 13 | 14 | 10 | 17 | 5 | 1 | 13 | 9 | 27 | 11 |
| Зашифрованный текст | 32 | 10 | 31 | 15 | 13 | 36 | 25 | 4 | 34 | 20 | 47 | 17 |
Примером шифрования с использованием секретного ключа является метод Видженера (Vigenere; ), относящийся к числу много алфавитных подстановок. Здесь берется небольшое целое число m и алфавит после каждой символьной подстановки сдвигается на m символов. Например, для m=4
1. abcdefghijklmnopqrstuvwxyz
ghijklmnopqrstuvwxyzabcdef
2. opqrstuvwxyzabcdefghijklmn
3. lmnopqrstuvwxyzabcdefghijk
4. fghijklmnopqrstuvwxyzabcde
Ключ = golf (смотри левую вертикальную колонку символов).
Исходный текст разбивается на группы по m символов (в рассмотренном случае по 4). Для каждой группы первый символ заменяется соответствующей буквой первого алфавита, вторая – из второго и т.д. Например, фраза "get me out of here please" будет преобразована следующим образом:
getm eout ofhe repl ease
mser kcfy utsj xsaq kohj.
Наибольшее распространение в последнее время получило блочное шифрование, где последовательность процедур воздействует на блок входного текста. Одним из наиболее известных таких методов стал DES (Data Encryption Standard), который работает с блоками данных по 64 байта (1998 год). Существует четыре режима работы:
| ECB | electronic code book. |
| CBC | cipher block chaining |
| CFB | cipher feedback |
| OFB | output feedback. |
Шифрование и дешифрование базируются на использовании ключей. Математически это можно выразить следующим образом (cм. ; www.ee.mtu.edu/courses/ ee465/groupa/overview.html):
EK(M) = C
DK(c) = M, где K – ключ, M – исходный текст; C – зашифрованный текст.
Эффективность системы шифрования определяется числом кодовых комбинаций или ключей, которое необходимо перебрать, чтобы прочесть зашифрованный текст. Существует две системы ключей шифрования/дешифрования. Для симметричных алгоритмов предполагается, что ключ дешифрования может быть вычислен по известному ключу шифрования. Оба ключа при этом должны быть секретными (например, система DES). Отправитель и получатель должны знать ключи до начала обмена (эти ключи могут и совпадать). Набор таких ключей может быть достаточно большим и в процессе инициализации осуществляется выбор пары ключей, которые будут использованы в данной сессии. В общем случае могут использоваться довольно большие кодовые таблицы, но такая схема неудобна для многоточечного обмена.
Шифры бывают поточными и блочными. В первом случае обработка исходного текста производится побитно или побайтно. Во втором – текст перед обработкой разбивается на блоки.
Асимметричные схемы шифрования/дешифрования предполагают существования независимых ключей для шифрования и дешифрования. Причем один не может быть получен из другого и наоборот. В идеале ключ дешифровки не может быть получен из шифрующего ключа за любое разумное время. В этом случае ключ шифрования может быть сделан общедоступным (например, алгоритм RSA). Партнеры до начала коммуникаций должны послать друг другу ключи шифрования КШО и КШП (ключи шифрования отправителя и получателя). Возможность перехвата таких ключей опасности не представляет. Дешифрование выполняется с помощью ключей КДО и КДП, которые образуют пары с КШО и КШП соответственно и формируются совместно. Ключи КШО и КШП обычно пересылаются на фазе инициализации сессии информационного обмена.
Шифрование может осуществляться по определенным правилам с помощью таблиц шифрования или ключей. При этом могут использоваться самые разные алгоритмы, в том числе, например, перемещение символов текста определенным образом.
За свою историю люди придумали достаточно большое число способов шифрования. Новейшие из них базируются на методиках, заимствованных из теории чисел. По этой причине, прежде чем переходить к следующему разделу, введем некоторые определения.
Конгруентность. a конгруентно b по модулю n (a є nb), если при делении на n a и b, получается идентичный остаток. Так 100 є 1134 (100 и 34 при делении на 11 дают остаток 1) и –6 є 810 (ведь –6 =8(-1)+2). Мы всегда имеем a є nb для некоторого 0 Ј bЈ n-1. Если a єnb и сє d, то справедливы равенства:
a +c є n(b + d) и ac єnbd
Аналогичная процедура для деления не всегда справедлива: 6є 1218 но 3№ 9. Приведенные здесь и далее математические определения и обоснования взяты из: http://lglwww.epfl.ch/~jkienzle/digital/node20.html.
Необходимо также вспомнить о знакомом всем со школьной скамьи понятии наибольшего общего делителя. Для a и b число (a,b) является наибольшим общим делителем, который делит a и b без остатка:
(56,98)=14; (76,190)=38
Теорема 1. Для любых a,b существуют целые числа x,y, для которых ax+by=(a,b). В данной статье не приводится доказательств представленных утверждений, их следует искать в книгах по дискретной математике.
В этом можно убедиться, решая уравнение 30x+69y=3 путем последовательных упрощающих подстановок (ищется целочисленное решение:
30x+69y=3
| 30x'+9y=3 | [x'=x+2y] |
| 3x'+9y'=3 | [y'=y+3x'] |
| 3x"+0y'=3 | [x"=x'+3y'] |
x'=x"-3y'=1 y=y'-3x'=-3 x=x'-1y=7
Мы можем решить уравнение вида 30x+69y=15 путем умножения нашего решения: y=-15, x=35. Должно быть ясно, что уравнение не будет иметь целочисленного решения, если 15 заменить на что-то некратное (30,69)=3.
Все другие целочисленные решения 30x+69y=15 могут быть получены, варьируя первое решение:
y=-15+(30/3)t x=35 –(69/3)t для целого t
Если мы проделаем то же для произвольного равенства ax+by=(a,b), мы возможно получим один из коэффициентов равным нулю, а другой – (a,b).
В действительности эта процедура представляет собой алгоритм Евклида для нахождения наибольшего общего делителя.
Важно то, что этот процесс реализуем на ЭВМ даже в случае, когда a и b имеют несколько сотен значащих цифр. Легко показать, что 600-значное число не потребует более чем 4000 уравнений. Теорема 1 справедлива и для простых чисел.
| Следствие 1. | Если p является простым числом, ar є pas и a № 0, тогда r є s. |
| Следствие 2. | Если p простое число и a № 0 mod p, тогда для любого b существует y, для которого ay є pb. |
| Следствие 3. | ("Теорема о китайском остатке"). Если (p,q)=1, тогда для любого a,b существует n, для которого n є pa и nє qb. |
a a2 a3 … mod p, где a и p целые числа.
Оказывается, можно выполнить такие вычисления даже для случая, когда в указанную процедуру вовлечены достаточно большие числа, например:
432678 mod 987.
Фокус заключается в том, что берется число и осуществляется возведение в квадрат.
4322 = 186624; 186624 mod 987 = 81; 4324 mod 987 = 812 mod 987 = 639
4328 -> 6392 mod 987 -> 690 …. 432512 -> 858
так как 678= 512+128+32+4+2, то:
432678->(81)(639)….(858) -> 204
Вычисления с использованием показателя включают в себя ограниченное число умножений. Если числа содержат несколько сотен цифр, необходимы специальные подпрограммы для выполнения таких вычислений. Рассмотрим последовательность степеней 2n mod 11:
2 4 8 5 10 9 7 3 6 1
Здесь числа от 1 до 10 появляются в виде псевдослучайной последовательности.
Теорема 2
Пусть p является простым числом. Существует такое a, что для каждого 1Ј b Ј p-1, существует такое 1Ј x Ј p-1, что axє pb, a не обязательно равно 2.
Степени 2 mod 7 равны 2, 4, 1. Далее числа повторяются, а числа 3, 5, или 6 не могут быть получены никогда. Рассмотрим некоторые следствия этой теоремы.
Следствие 4. Пусть a соответствует требованиям теоремы 2, тогда ap-1 є p1.
Следствие 5. Для любого b № 0, bp-1 є p1.
Следствие 6. Если x є (p-1)y, тогда bx є pby
Лемма
Пусть b № 0, d наименьшее положительное число, такое что bd єp1. Тогда для любого с>0 c bc єp1 d делит c без остатка. В частности для следствия 5, d делит p-1 без остатка.
Согласно теореме 2, если p простое число, существует такое a, при котором равенство ax є pb имеет решение для любого b№ 0. Такое значение a называется примитивным корнем p, а x называется дискретным логарифмом b. Получение b при заданных a и x относительно просто, определение же x по a и b заметно сложнее. Многие современные системы шифрования основываются на факте, что никаких эффективных путей вычисления дискретных логарифмов не найдено. Никакого эффективного метода определения примитивных корней также неизвестно. Однако часто возможно найти примитивные корни в некоторых специальных случаях. Возьмем p=1223. p-1=2*13*47. Согласно лемме, если a не примитивный корень, тогда мы либо имеем a26, a94 или
a611 є 12231. a=2 и a=3 не годятся, но a=5 соответствует всем трем условиям, таким образом, это значение является примитивным корнем. Мы могли бы сказать, что a=4 не может быть признано примитивным корнем без проверки.
Легко показать, что если a примитивный корень, ax примитивный корень в том и только том случае, если (x,p-1)=1. В этом примере это означает, что число примитивных корней равно
1222*(1/2)*(12/13)*(46/47)=552
Таким образом, если мы выберем а произвольно, вероятность того, что это будет примитивный корень равна ~.45. Выбирая а наугад и тестируя, можно сравнительно быстро найти примитивный корень.
Наиболее современные системы шифрования используют асимметричные алгоритмы с открытым и секретным ключами, где нет проблемы безопасной транспортировки ключа. К числу таких систем относится алгоритм rsa (rivest-shamir-adleman - разработчики этой системы – Рональд Ривест, Ади Шамир и Леонард Адлеман, 1977 год), базирующийся на разложение больших чисел на множители.
Другие сходные алгоритмы используют целочисленные логарифмы и вычисление корней уравнений. В отличие от других систем эти позволяют кроме шифрования эффективно идентифицировать отправителя (электронная подпись).
К системам с открытым ключом предъявляются следующие требования:
ифрованный текст трудно (практически невозможно) расшифровать с использованием открытого ключа.
становление закрытого ключа на основе известного открытого должно быть нереализуемой задачей на современных ЭВМ. При этом должна существовать объективная оценка нижнего предела числа операций, необходимых для решения такой задачи.
К сожалению, эти алгоритмы достаточно медленно работают. По этой причине они могут использоваться для транспортировки секретных ключей при одном из традиционных методов шифрования-дешифрования.
Но следует помнить, что не существует абсолютных мер защиты. На рис.6.4.1. показан способ нарушения конфиденциальности в системах с двухключевой схемой шифрования.
Рис. 6.4.1.
Если хакер умудрится вставить свою ЭВМ в разрыв канала, соединяющего субъектов А и В, у него появляется возможность перехватывать в том числе и шифрованные сообщения. Пусть субъект А сформировал пару ключей К1А и К2А (ключ с индексом 2 является секретным), аналогичную пару ключей сгенерировал субъект В (К1В и К2В). Хакер же тем временем подготовил две пары ключей (К1ХА:К2ХА и К1ХВ:К2ХВ). Когда субъект А пошлет открытый ключ К1А субъекту В, хакер его подменит ключом К1ХА. Аналогичную процедуру он проделает с ключом К1В, посланным от В к А. Теперь сообщение А к В, зашифрованное с помощью ключа К1ХА будет послано В. Хакер его перехватывает, дешифрует с помощью ключа К2ХА, шифрует с помощью ключа К1ХВ и посылает В. Субъект В, получив послание, дешифрует его с помощью "секретного" ключа К2ХВ, полученного от хакера (о чем он, естественно, не подозревает). Аналогичная процедура будет проведена и при посылки сообщения от В к А. В сущности единственным параметром который изменится существенным образом будет время доставки сообщения, так как это время будет включать дешифровку и повторную шифровку сообщения. Но при использовании быстродействующей ЭВМ и при работе с традиционной электронной почтой это может оказаться незаметным.Понятно, что между А и В появится дополнительный шаг (hop). Но и это может быть легко замаскировано под прокси сервер или Firewall.
Решить эту проблему можно путем пересылки открытого ключа своему партнеру по какому-то альтернативному каналу или сверки его по телефону.
Полезную информацию по системам шифрования можно получить на следующих серверах:
Сконструированные типы
Типы структуры могут быть сформированы для удобства из примитивных типов. Каждая спецификация декларирует новый, уникальный тип. Синтаксис определения весьма похож на используемый в Си.
struct {
| T1 f1; | |
| T2 f2; | |
| ... | |
| Tn fn;} [[T]]; |
Поля в структуре могут быть квалифицированы, используя имена типов, которые синтаксис подобный нумерованным элементам. Например, T.f2 относится ко второму полю предыдущей декларации. Структурные определения допускают вложения.
Смежные обстоятельства
Рабочая группа справочника по сетевой безопасности работает над справочником по Интернет безопасности. Он представляет собой практическое руководство для помощи пользователям в защите их информации и ресурсов.
