Езопасность электронной почты

§6. ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ СЕРВИСОВ

езопасность WWW

Злоумышленник, работающий с системой WWW, может преследовать следующие цели:

— атака на компьютер пользователя посредством кода, написанного на JavaScript, Java или загруженного по технологии ActiveX;

— построение ложной копии WWW-сервера с целью ведения пользователя в заблуждение и принуждения его к раскрытию секретной информации;

— атака на HTTP-сервер через CGI-программы и другие средства динамической генерации контента с целью проникновения в его операционную систему или отказа в обслуживании;

— перехват передаваемых данных;

— перехват паролей и получение несанкционированного доступа к ресурсам WWW-сервера или к услугам прокси-сервера.

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

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

Второй вариант – автоматическая загрузка кода браузером без ведома пользователя при просмотре последним определенной web-страницы. Таким кодом могут быть встроенные в HTML-текст программы JavaScript, апплеты, написанные на языке Java, и управляющие элементы ActiveX.

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

Однако, несмотря на все предпринятые меры, для злоумышленников все равно остается определенное поле действий. Основными угрозами безопасности являются обман пользователя и атаки типа «отказ в обслуживании».

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

Загрузка Web-страниц со специальным кодом JavaScript может привести к блокированию браузера так, что для продолжения работы требуется его перезагрузка.

JavaScript имеет также возможность отправлять сообщение по электронной почте. Отправка данных может быть инициализирована любым действием пользователя.

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

Проблема перехвата данных злоумышленником, прослушивающим сеть, не решается в рамках протокола HTTP. Если запросы и ответы содержат секретную информацию, следует использовать протокол SSL. Протокол SSL в стеке TCP/IP расположен между транспортным (TCP) и прикладным уровнями. SSL обеспечивает шифрование всех данных прикладного уровня. При установлении соединения сервер предъявляет клиенту сертификат, подтверждающий «личность» сервера.

езопасность электронной почты

Злоумышленник может преследовать следующие цели:

oнедобросовестное использование электронной почты:

— атака на компьютер пользователя посредством рассылки почтовых вирусов;

— отправка поддельных писем;

— чтение чужих писем;

oатака на почтовый сервер средствами электронной почты с целью проникновения в его операционную систему или отказа в обслуживании;

oиспользование почтового сервера в качестве ретранслятора при рассылке непрошенных сообщений (спама, писем с вирусами);

oперехват паролей:

— перехват паролей в POP и IMAP-сеансах, в результате чего злоумышленник может получать и удалять почту пользователя без ведома последнего;

— перехват паролей в SMTP-сеансах, в результате чего злоумышленник может быть незаконно авторизован для отправки почты через данный сервер;

— перехват TCP-соединения после успешной аутентификации клиента.

Отправка сообщения от любого имени не представляет трудности. Злоумышленник может сделать это, изменив настройки своего пользовательского агента или непосредственно открыв SMTP-сеанс с транспортным агентом.

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

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

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

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

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

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

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

езопасность Java

В случае типичного приложения Java 2 Enterprise Edition (J2EE) основным клиентом обычно является браузер, использующий HTTP. Есть несколько способов аутентификации по этому протоколу и одно из преимуществ J2EE состоит в том, что веб-контейнер действительно осуществляет аутентификацию. Процесс происходит прозрачно для приложений. Аутентификация для веб-приложений J2EE чаще всего задается декларативно добавлением ограничивающего условия в дескриптор размещения веб-приложения.

Три основных метода регистрации пользователя, поддерживаемых контейнерами J2EE,- это базовая HTTP-аутентификация, аутентификация по форме и аутентификация по сертификату клиента. Некоторые контейнеры также используют дайджест-аутентификацию HTTP.

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

При аутентификации по форме J2EE возвращает страницу, являющуюся по сути HTML-формой, запрашивающей у клиента имя пользователя и пароль. Когда клиент передает форму, контейнер перехватывает запрос, извлекает из формы информацию об имени пользователя и пароле и проводит аутентификацию. Если пользователь авторизован для просмотра ресурса, который он запрашивал, контейнер обслуживает запрос для защищенного ресурса. Преимущество аутентификации по форме в том, что она может осуществляться при помощи страницы HTML, которая встраивается в схему представления веб-приложения. Чтобы использовать для приложений аутентификацию по форме, разработчик просто назначает HTML-страницу, которая будет отображена браузером в случае успешного входа в систему. Контейнер затем непрерывно перехватывает все запросы для защищенных ресурсов и использует вышеописанную аутентификацию пользователя. Впоследствии приложение не получит доступа к полномочиям пользователя. Все детали аутентификации будет реализовывать контейнер. Аутентификация по форме обычно использует метод HTTP POST и пересылает данные по сети без шифрования.

Аутентификация по сертификату клиента требует, чтобы клиент имел подписанный сертификат Х509, который содержит информацию об открытом ключе клиента с дайджестом, подписанным как доверенным секретным ключом (от СА), так и секретным ключом клиента.

§6. АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ

Основные особенности сетевой аутентификации

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

Можно выделить три типа аутентификации в порядке повышения надежности:

1)основанные на знании человеком паролей, цифровых кодов и т.п.;

2)основанные на том, что человек имеет: удостоверение, в том числе электронное;

3)основанные на том, кем человек является: т.е. на биометрических (отпечатки пальцев) и биологических (код ДНК) параметрах;

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

Удовлетворительный механизм сетевой аутентификации должен отвечать двум требованиям:

— аутентификация должна быть двухсторонней, т.е. и сервер и клиент должны предъявлять какую-либо информацию;

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

Т.о., задача построения механизма сетевой аутентификации тесно связана с криптографией.

Реально используемые системы аутентификации можно разделить на две категории:

А) надежные в криптографическом смысле (взломщик может рассчитывать только на криптоанализ полным перебором пространства ключей);

Б) «бюджетные» — взломщик может успешно применить эффективные атаки.

Простой метод запрос-ответ

Большинство моделей сетевой аутентификации основаны на вариантах метода запрос-ответ (CHAP – протокол аутентификации запрос-ответ).

Рассмотрим простейшую реализацию: клиент и сервер знают общий ключ КAB (согласование секрета обеспечивается внеполосными средствами). Клиент помнит этот пароль, а сервер хранит в хэшированном виде в БД учетных записей.

Односторонняя аутентификация запрос-ответ

Александр Валентина

Т.к. Александр знает Rв , а также ключ, то Валентина может проверить аутентичность подписи, следовательно она узнает, что Александр есть Александр.

Александр может проверить идентичность Валентины таким же способом: Сгенерировав случайное число RA , он пересылает его Валентине, она подписывает своей копией ключа и возвращает обратно. Убедившись, что Валентина «истинная» Александр приступает к обмену данными. Используя ключ АВ они могут согласовать сеансовый ключ для шифрования.

Двухсторонняя аутентификация запрос-ответ

Александр Валентина

В «оптимизированном» варианте (в том числе в ТСР, протокол управления передачей данных) – трехстороннее рукопожатие

Александр отправляет свой идентификатор «А» и случайное число RA. Валентина отвечает пакетом, в котором содержится KBB(RA) и RB. Александр отвечает пакетом KАB(RВ)

Оптимизированная двусторонняя аутентификация запрос-ответ

Александр Валентина

Этот протокол уязвим при «зеркальной» атаке: если сервер Валентины допускает несколько одновременных соединений от имени одного и того же пользователя, то злоумышленник может себя выдать за Александра. Послав запрос на аутентификацию А,RA, злоумышленник получает ответ: RB, KAB(RA). Теперь злоумышленнику необходимо построить KАB(RВ) (но он не может, т.к. не знает АВ). Но это знает Валентина. Он отправляет запрос на аутентификацию А, RB. Валентина отвечает: R’B, KAB(RB).

Зеркальная атака

Злоумышленник Валентина

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

Способы борьбы с такой атакой:

— запоминаются все Rx;

— использовать вместо Rx можно временные штампы;

— использовать уникальные значения (нонсы) (способ генерации нонсов – счетчик последовательных номеров.

Аутентификация в протоколе SMB (Server Message Block – блок сообщений сервера)

Прикладной блок стека Net BIOS (Базовая система ввода-вывода, Network Basic Input/ Output System) SMB используется операционными семействами (OS/2, Windows) для организации сетевых файловых систем.

При аутентификации клиент и сервер обменивается тремя пакетами (простой запрос-ответ). При этом используется менеджер безопасного доступа (SAM) – аутентификационный сервис для системы Win32. (SAM еще называют системой безопасности)

Каждый домен сети имеет собственную базу SAM (в простейшем случае домен состоит из одного сервера, клиенты могут не входить в домен.

Схемы запрос-ответ начинаются с того, что сервер вместе с выбранной версией протокола передает ключ Rх – псевдослучайную строку длиной 8 байт. Принято ее обозначать C8. Далее С8 подвергается преобразованию с использованием пароля в качестве секретного значения.

В качестве основы алгоритма преобразования используется DES (стандарт шифрования данных, Data Encruption Standart): хэшируемая строка используется в качестве ключа шифрования.

Если строка длиннее 7 байт (длина ключа 56 бит), используется более сложная процедура: сначала шифруется значение младшими семью байтами строки, затем – старшими шестью и объединяются полученные значения.

Такое преобразование обозначается как E(X,Y) и работает следующим образом:

если Х короче 7 байт (максимальная длина ключа DES), а Y – 8 (размер блока DES), то E(X,Y)=DES(X,Y). При этом X и Y дополняются пробелами либо нулевыми байтами (на каждом шаге уточняется чем именно) до соответствующих значений;

если X длиннее 7 байт, но короче 14, то X дополняется до 14 байт и E(X0X1,Y)=DES(X0,Y)DES(X1,Y). Аналогичным образом строится E(X0X1X2), которые длиннее 14 байт, но короче 21.

В диалектах, использующих схему аутентификации LM, вычисление ответа начинается с вычисления P16=E(P14,C8), где Р14 – четырнадцатисимвольный пароль, переведенный в верхний регистр и дополненный пробелами. C8 – строка ASKII. Значение Р16 строится на основе одного только пароля и статической информации и хранится в SAM в качестве хеша пароля.

Т.о., LM использует в качестве секретного значения довольно длинные пароли, состоящие из символов ASKII и нечувствительные к регистру букв (т.е. сужается реальное пространство перебора при вычислении пароля). Это ограничение обеспечивает совместимость со старыми клиентами NetBIOS. При авторизации таких клиентов сервер получает пароль открытым текстом, самостоятельно вычисляет Р16 и сравнивает его с записью в базе данных домена.

Затем Р16 дополняется нулевыми байтами до Р21 и вычисляется Р24=E(P21,C8), которое отсылается сервера в качестве ответа KAB(RA).

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

Клиент сервер

В диалекте NT4 используются пароли в кодировке Unicode практически неограниченной длины, чувствительные к регистру букв. В качестве Р16 используется дайджест MD4, сам же ответ Р24 вычисляется тем же методом, что и в диалекте LM.

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

SMB допускает многоступенчатую аутентификацию. Протокол при этом предусматривает два типа серверов:

— контроллеры сервера (которые содержат реплики SAM);

-простые серверы (имеющие локальную БД).

Установление идентичности происходит следующим образом:

Сервер устанавливает соединение с одним из контроллеров домена и пытается произвести аутентификацию от имени fat/domain. Аутентификация происходит синхронно: получив от контроллера запрос, сервер пересылает запрос клиенту. Получив от клиента ответ, сервер пересылает его контроллеру и ждет результата. Такое поведение называют «человек в середине».

Двухступенчатая аутентификация SMB

Клиент сервер контроллер домена

При соединении между контроллерами используется более совершенная схема, основанная на использовании двух паролей (так как оба контроллера имеют реплики SAM), они знают хэш друг друга. Поэтому межконтроллерные соединения заслуживают название – безопасный канал (schannel).

Доменная аутентификация SMB

Сервер Контроллер домена

Schannel

Клиент

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

В многодоменной сети применяется схема многоступенчатой аутентификации.

Статьи к прочтению:

Защита электронной почты. Практика!

Похожие статьи: