Компания IBM
Опубликован: 04.07.2008 | Доступ: свободный | Студентов: 456 / 58 | Оценка: 4.48 / 3.95 | Длительность: 13:58:00
Лекция 8:

Контроль спама при помощи Domino 7

8.4 Обнаружение спама

В этом разделе мы опишем, как обнаруживать спам.

8.4.1 Атаки на директории

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

  • Атака невидима, но влияния нет. Если вы настроите сервер Domino так, чтобы он принимал почту, только если в ней указан пользователь, упоминаемый в Domino Directory (см. 8.5.4, "Контроль получателей, указанных во входящих сообщениях"), вы можете даже не узнать, что были атакованы. Но спамер может продолжать занимать потоки слушателя (listener threads), сделав систему недоступной для нормальной почты.
  • Множество задержанных (held) сообщений. Если вы настроили сервер Domino так, чтобы он хранил недоставленную почту, эти сообщения становятся задержанными (см. 8.5.9, "Удержание недоставленных сообщений").
  • Множество зависших (dead) сообщений. Если вы используете настройки по умолчанию, сообщения, которые не были доставлены, будут возвращаться отправителю (отчет о невозможности доставки). В большей части спама в качестве адресов отправителей используются несуществующие адреса. Когда сервер Domino отправляет уведомление о невозможности доставки, оказывается, что отправитель не существует. Когда адресат отсутствует, сообщение получает статус зависшего (dead message). И проблема даже не в том, что зависшие сообщения остаются в почтовом ящике. Прежде чем изменить статус сообщения, сервер Domino пытается послать уведомление о невозможности доставки. Это расходует системные ресурсы и может сделать сервер недоступным для важных почтовых сообщений.

Просматривая журнал сервера, вы можете обнаружить сообщение, у которого много получателей, из которых только один или два являются допустимыми. Если вы просмотрите задержанные сообщения в почтовом ящике сервера, вы, возможно, заметите, что некоторые из этих сообщений имеют одинаковые или сходные строки Subject (Тема) (пример 8.5).

10/23/2005 09:58:01 AM SMTP Server: mx04.ca.mci.com (142.77.2.24) connected
10/23/2005 09:58:01 AM SMTP Server: Recipient: <carpenter@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <chandler@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <chapman@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <cohen@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <conner@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <cruz@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <cummings@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <daniel@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <daniels@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <dawson@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <delgado@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <dennis@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <douglas@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <duncan@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <dunn@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <ferguson@stdi.com>
Пример 8.5. Файл журнала сервера: список получателей

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

8.4.2 Фишинг и фарминг

Терминами "фишинг" (phishing) и "фарминг" (pharming) называются почтовые сообщения, целью отправителя которых является кража персональной информации о получателе. В большинстве случаев отправитель выступает в роли представителя официальной организации, которому нужно проверить персональную информацию. Лучшей защитой афер от данного типа является обучение пользователей.

За дополнительной информацией обращайтесь по адресу http://www.antiphishing.org

8.5 Блокирование спама

В этом разделе мы опишем методы блокирования спама.

8.5.1 "Белые списки" и "черные списки"

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

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

Для черных и белых списков существуют варианты – личный список (private) и список DNS. В личный список можно ввести доменное имя или IP-адрес.

DNS-вариант черных списков не является новым, но личный черный список, а также личный белый список и белый список DNS являются новинкой версии 7.

На рис. 8.3 показаны параметры черного списка DNS , белого списка DNS, лично- го черного списка и личного белого списка.

Черный список DNS, белый список DNS, личный черный список и личный белый список

увеличить изображение
Рис. 8.3. Черный список DNS, белый список DNS, личный черный список и личный белый список

В личном черном и белом списках, а также во всех других полях документа Server, в которые можно вводить имена хостов и IP-адреса, конкретные IP адреса должны заключаться в квадратные скобки, например [192.168.100.128]. Вы также можете указывать диапазоны адресов, например [192.168.100.128.255], а также можно использовать символы-шаблоны, например [192.168.128.144.*].

Новая возможность Domino 7 позволяет вам вводить адреса в формате бесклассовой междоменной маршрутизации – Classless Inter-Domain Routing (CIDR), например [192.168.0/16]. При использовании этого формата нужно соблюдать осторожность, поскольку интерпретация данного формата в Domino несколько отличается от стандартной. Строка CIDR [207/8] должна быть эквивалентна [207.0/8], но Domino неверно интерпретирует строку [207/8], так что, если вам нужно указать весь диапазон адресов классов A, B или C, обязательно используйте в строках CIDR символы ".0".

Данные поля могут сильно разрастаться, и прямой ввод в них адресов может способствовать таким ситуациям, когда объем данных в документе Server превышает общий предел размера буфера. Избежать этого можно, вводя в эти поля имена групп и указывая имена и адреса хостов (в тех же форматах) в этих группах.

Упомянутые 4 варианта списков обрабатываются в такой последовательности:

  1. Личный белый список.
  2. Личный черный список.
  3. Белый список DNS.
  4. Черный список DNS.

Личный черный список и черный список DNS имеют следующие варианты: Log only (Только записать в журнал), Log and tag message (Записать в журнал и маркировать сообщение), Log and reject message (Записать в журнал и отклонить сообщение).

Личный белый список и белый список DNS имеют следующие варианты: Silently skip blacklist filters (Без уведомлений пропускать фильтры черных списков), Log only (Только в журнал), Log and tag message (Записать в журнал и маркировать сообщение).

При использовании варианта с маркированием в сообщение добавляется новое поле. При использовании черного списка добавляется поле $DNSBLSite, а при использовании белого списка – $DNSWLSite. При маркировании для белых и черных списков DNS в этом поле сохраняется URL. При маркировании для личных черных и белых списков в этом поле хранится значение PrivateWhitelist или PrivateBlacklist. Для обнаружения этих полей и выполнения соответствующих действий вы можете применять почтовые правила.

При использовании варианта с журналом в файл журнала сервера, в раздел Mail Routing Events (События маршрутизации почты) добавляется запись. В примере 8.6 показаны эти 4 возможных варианта.

SMTP Server: Remote host 192.168.1.221 (list.groofty.com) found in blacklist at
PrivateBlacklist
SMTP Server: Remote host 192.168.1.221 (groofty.com) found in blacklist at sbl.spamhaus.org
SMTP Server: Remote host stdi.com (192.168.1.221) found in whitelist at PrivateWhitelist
SMTP Server: Remote host list.stdi.com (192.168.1.221) found in whitelist at
query.bondedsender.org
Пример 8.6. Записи в журнале, связанные с белыми и черными списками

8.5.2 Контроль входящих соединений

Весь контроль входящих соединений осуществляется на основе IP-адресов. Поля SMTP при проверке не используются. Данная проверка производится до того, как сервер получает команду MAIL FROM. На рис. 8.4 показаны параметры контроля входящих соединений.

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

Рис. 8.4. Контроль входящих соединений

Обратите внимание на следующие параметры:

  • Verify connecting hostname in DNS field (Проверять имя соединяющегося хоста . в поле DNS). Domino производит инвертированный поиск в DNS. Для домена в DNS должна существовать запись PTR. Эта запись связывает IP-адрес и имя хоста.
    Примечание. Записи PTR не являются обязательными для правильной маршрутизации данных в Интернете. Многие организации не хранят эти записи в DNS. При включении этой функции соблюдайте осторожность.
  • Allow connections only from the following SMTP internet hostnames/IP addresses (Разрешать соединения со следующими именами/IP-адресами SMTP) и Deny connections from the following SMTP internet hostnames/IP addresses (Запрещать соединения со следующими именами/IP-адресами SMTP). Указываются имена хостов и IP-адреса, которым разрешено или запрещено соединение. Когда вы вводите имя хоста, Domino производит инвертированный поиск соответствующего ему IP-адреса в DNS.
    Примечание. Эта функция сходна с личным белым списком, хотя и не столь гибкая, поскольку в ней нет опций маркирования и записи в журнал.

8.5.3 Контроль отправителей входящих сообщений

Весь контроль отправителей входящих сообщений выполняется на основе поля MAIL FROM заголовка SMTP.

Примечание. Не все поля заголовка сохраняются в почтовом документе. Поле MAIL FROM заголовка SMTP сохраняется в файле журнала сервера и в журнале слежения за сообщениями. Адрес в поле MAIL FROM может отличаться от адреса отправителя в пользовательском почтовом файле.

На рис. 8.5 показаны следующие параметры контроля отправителей входящих сообщений:

Контроль отправителей входящих сообщений

Рис. 8.5. Контроль отправителей входящих сообщений
  • Verify sender's domain in DNS (Проверять домен отправителя по DNS). Domino проверяет, существует ли домен, к которому принадлежит отправитель. Домен берется из заголовка MAIL FROM. В DNS должны содержаться корректные записи MX, CNAME или A.
  • Allow/Deny messages only from the following external addresses/domains (Разрешать/запрещать сообщения только со следующих внешних адресов/доменов). Введите адреса и домены. Система Domino сравнивает поле MAIL FROM заголовка сообщения с указанными здесь адресами и доменами.