Методы защиты от нежелательных почтовых сообщений

Автор работы: Пользователь скрыл имя, 24 Октября 2011 в 20:20, курсовая работа

Описание

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

Содержание

ВВЕДЕНИЕ 2
1 КАК СПЛАНИРОВАТЬ И ОСУЩЕСТВИТЬ ЗАЩИТУ 5
2 ЗАЩИТА ОТ НЕЖЕЛАТЕЛЬНОЙ ПОЧТЫ И ФИШИНГА С ПОМОЩЬЮ КОДА ОТПРАВИТЕЛЯ 15
3 НАИБОЛЕЕ РАСПРОСТРАНЕННЫЕ СПОСОБЫ ЗАЩИТЫ ОТ СПАМА 29
4 ЗАКЛЮЧЕНИЕ 16
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 17

Работа состоит из  1 файл

реферат Методы защиты от нежелательных почтовых сообщений.doc

— 309.00 Кб (Скачать документ)

         Количество  получателей собщения (Limit number of recipients per message) по умолчанию - 64 000. Измените это  значение, установив новое в пределах между 100 и 1000. ОБРАТИТЕ ВНИМАНИЕ: значение, которое Вы выбираете, зависит от потребностей передачи сообщений вашей организации и размера внешних списков рассылки вашей организации. Любые сообщения, содержащие большее чем установленное количество получателей, будут возвращены отправителю с сообщением о недоставке (non-delivery report ) (NDR).

         Нажмите OK.

         Как использовать обратный поиск DNS

         Если  Вы получаете сообщения непосредственно  от других доменов Internet, Вы можете настроить  ваш виртуальный сервер SMTP так, чтобы  выполнить обратный поиск DNS у входящих почтовых сообщениях. Эта настройка проверяет, что IP адрес сервера посылающего сообщение (и его доменное имя) соответствуют имени домена отправителя сообщения. Обратный поиск помогает предотвращать имитацию адреса. Однако, обратный поиск добавляет дополнительную нагрузку вашему компьютеру с Exchange Server. Смотрите раздел "Решение проблем" для получения дополнительной информации. Эта методика также требует, чтобы ваш Exchange Server мог войти в контакт с обратными зонами просмотра домена отправителя.

         ОБРАТИТЕ  ВНИМАНИЕ: Если Вы только настраиваете ваш виртуальный SMTP виртуальный сервер, для выполнения обратного просмотра DNS, Вы не блокируете сообщения с несоответствием доменное имя/ip адрес. Обратный просмотр DNS определит DNS имя для IP адреса и заменит DNS имя в заголовке на имя, которое получено при обратном просмотре DNS.

         Для дополнительной информации, прочтите следующую статьи в Базе знаний Microsoft:

         297412 Выполнение обратного просмотра DNS для входящих сообщений

         Нажмите Пуск (Start), выберите Программы (Programs), Microsoft Exchange, и нажмите System Manager.

         В левой области окна Exchange System Manager, дважды щелкните Servers, и разверните компьютер с Exchange Server, который Вы хотите настроить.

         Разверните Protocols (Протоколы), и SMTP.

         Щелкните  правой кнопкой мыши Default SMTP Virtual Server (Виртуальный SMTP сервер по умолчанию), и нажмите Свойства (Properties).

         Чтобы настроить обратный поиск сервера DNS для входящих сообщений, выберите закладку Delivery (Доставка).

         Нажмите кнопку Advanced (Дополнительно), а затем  установите флажок Perform reverse DNS lookup on incoming messages (Выполнять обратный поиск DNS для  входящих сообщений).

         Нажмите OK, нажмите OK.

         Как настроить SMTP коннектор

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

         Нажмите Пуск (Start), выберите Программы (Programs), Microsoft Exchange, и нажмите System Manager.

         В левой области окна Exchange System Manager, дважды щелкните Connectors.

         Щелкните  правой кнопкой мыши SMTP коннектор, который  Вы используете для входящих и  исходящих почтовых сообщений Internet, и нажимаете Свойства (Properties). Вы увидете закладку General (Общие) диалогового окна для SMTP connector's Properties.

         Если  ваш поставщик провайдер обеспечивает хранение и пересылку ваших входящих почтовых сообщений, вероятно, что он также является сервером для ваших  исходящих почтовых сообщений. Если это так, нажмите Forward all mail through this connector to the following smart hosts (Пересылать всю почта через этот коннектор на следующие хосты), и затем введите FQDN (полное доменное имя) или IP адрес почтового сервера вашего провайдера Internet.

         Нажмите закладку Address Space (Адресное пространство) и удостоверьтесь, что флажок Allow messages to be relayed to these domains (Разрешить пересылать сообщения в домены). ОБРАТИТЕ ВНИМАНИЕ: Поскольку SMTP коннектор, который доставляет почтовые сообщения Internet обычно в качестве адресного пространства имеет звездочку (*) (которая указывает все домены), если Вы установите флажок Allow messages to be relayed to these domains (Разрешить пересылать сообщения в домены), это допускает передачу ко всем внешним доменам.

         Если  Вы используете хост для исходящих  почтовых сообщений, свяжитесь с  вашим провайдером, чтобы настроить  защиту для доставки сообщений. Выберите закладку Advanced (Дополнительно), и нажмите  кнопку Outbound Security.

         Если  ваш провайдер поддерживает идентификацию и кодирование, выберите Basic authentication (Основная идентификация), нажмите кнопку Modify (Изменить), добавьте учетную запись пользователя и пароль для доступа к хосту вашего провайдера, нажмите OK, и установите флажок TLS encryption.

         Как проверить функцию ограничения IP адресов

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

         Чтобы проверить функция ограничений пересылки, подключитесь с вашего POP3 и IMAP4 клиента с неисключенного IP адреса, и попробуйте послать почтовое сообщение внешнему домену. Вы получаете сообщение о том, что в отправке внешнему домену отказано из-за ограничений пересылки.

         Чтобы проверить идентификацию и TLS кодирование, убедитесь, что Вы можете получить почтовые сообщения от почтового сервера  вашего провайдера, который обеспечивает хранение и отправку для вашего домена. Запустите Сетевой монитор (Network Monitor) на компьютере с Exchange Server и фиксируйте пакеты, приходящие от почтового адреса сервера вашего провайдера на 25 порт (0019h). Эти пакеты содержат зашифрованные данные. Вы не сможете увидеть пароль или имя пользователя.

         Чтобы проверить обратный поиск DNS, Вы должны послать сообщение вашему домену от адреса, который не соответствует домену отправителю. Это сообщение появится в вашей папке Badmail.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 

         Защита  от нежелательной  почты и фишинга  с помощью кода отправителя

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

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

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

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

         В настоящий момент существуют два  общедоступных для использования  подхода к проверке подлинности  электронных сообщений: «Sender ID Framework, SIDF» (система кода отправителя) и  «DomainKeys Identified Mail, DKIM» (идентификация почты ключом домена). SIDF является решением, построенным на основе протокола IP и получившимся в результате объединения «Sender Policy Framework, SPF» (система политик отправителя) и «Microsoft Caller ID for E-Mail» (идентификатор отправителя электронной почты, разработанный корпорацией Майкрософт). В апреле 2006 года IETF опубликовала спецификации кода отправителя — RFC 4405-4408. Объединение промышленных и коммерческих организаций, включая и корпорацию Майкрософт, основываясь на факторах, включающих в себя коммерческую и производственную ценность, стабильность, степень разработки, легкость развертывания, минимальное влияние на производительность обработки входящего и исходящего потоков электронных сообщений, а также способность взаимодействия с экосистемой среды электронных сообщений организаций и поставщиков услуг Интернета, рекомендует развертывание системы SIDF.

         Подход DKIM является объединением спецификаций «Yahoo! DomainKeys» (доменных ключей Yahoo!) и  «Identified Internet Mail, IIM» (идентификация Интернет-почты) корпорации Cisco Systems Inc. В январе 2006 года IETF одобрила создание рабочей группы по DKIM, и в настоящий момент данная спецификация находится в процессе рассмотрения в IETF.

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

         Развитие  и всемирное использование SIDF было бы невозможным без вклада и поддержки множества организаций и компаний, включая AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign, а также многих других.

          
Код отправителя. Общие сведения

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

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

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

         При использовании механизма SIDF запись SPF содержит простую текстовую запись всех серверов исходящей почты с указанием домена и соответствующих IP-адресов. Организация публикует запись SPF в свой файл зон DNS-сервера, который затем проверяется почтовым сервером получателя. Настроить запись SPF можно быстро, без особых усилий и бесплатно. Средство «Sender ID Framework SPF Record Wizard» (мастер записи SPF системы кода отправителя) содержит пошаговые инструкции по наблюдению за почтовыми серверами домена и созданию специальных записей, готовых к отправке. (Подробные сведения о публикации записи SPF доступны по адресу: microsoft.com/senderid (на английском языке). Программа находится по адресу microsoft.com/senderid/wizard.)

         Сервер  входящих сообщений SMTP запрашивает  наличие записи SPF у файла зон  в DNS, расположенного в домене. При наличии записи производится проверка IP-адреса отправляющего сервера по списку IP-адресов. В случае обнаружения сообщение считается прошедшим проверку подлинности. С другой стороны, в случае если сведения записи SPF о домене отправителя не совпадают с IP-адресом отправления, то сообщение считается не прошедшим проверку подлинности, что приводит к назначению ему отрицательной оценки и вероятности его перемещения в папку нежелательных сообщений. На рис. 1 показан пример данного процесса.

Информация о работе Методы защиты от нежелательных почтовых сообщений