Поиск Спамеров
Для администратора сервера спам подразделяется на:
Входящий спам - спамовые сообщения для пользователей сервера
Исходящий спам - спамовые сообщения, рассылаемые с сервера, соответствующими скриптами
В целях обнаружения, устранения и предупреждения спама каждого вида, следует использовать
нижеприведенные методики.
Входящий спам для пользователей
Входящий спам - это зло современного интернета и неудобство для пользователей, которое
может вызвать серьезные проблемы в работе сервера и использовании ресурсов на сервере. Такой спам
не только причиняет неудобства пользователям элекстронной почты, но и нарушает работу сервера в
целом.
Наилучшим способом борьбы со спамом, приходящим на сервер, является MTA (например, exim
SMTP-сервер для cPanel). При его помощи, вы можете заблокировать спамовые сообщения, до того как
они попадут в очередь обработки на сервере. Таким образом, вы экономите как на серверных ресурсах,
используемых при доставке сообщения, так и на дополнительных сторонних инструментах, которые помогают
обнаруживать спам в дальнейшем, после получения его сервером.
Во время обмена командами между SMTP серверами отправителя и получателя на этапе RCPT, т.е. еще до фактического
прихода сообщения на сервер, письма с/для несуществующего ящика электронной почты могут быть отсеяны.
Первичной формой спама является Атака по словарю (Dictionary Attack):
Обычно спамеры используют так называемую Атаку по Словарю на домен. Атакой по Словарю, в нашем
контексте, это попытка отправки почтового спама на аккаунты, представляющие собой набор случайных
имен на некотором домене, например bob@ourdomain.com fred@ourdomain.com harry@ourdomain.com, в надежде,
что одна из многих сотен записей окажется верной и спам будет доставлен.
Этот метод используется спамерами в основном потому, что большинство людей не
афишируют свои адреса электронной почты (из-за спама!), а спамеры хотят воспользоваться этим
неосвоенным рынком.
Чтобы избежать подобного рода спама, доходящего до места назначения, крайне важно, чтобы вы не
использовали по Адрес умолчанию(универсальный). Установите самостоятельно переадресаторы
(псевдонимы) для каждого своего адреса электронной почты, а затем установите Адрес по умолчанию в :Fail:
для каждого домена.
При использовании :fail: exim будет автоматически отвергать сообщения на этапе SMTP
команды RCPT и атака по словарю будет неудачной. Кроме того, Вы можете использовать в exim списки
контроля доступа для блокирования спамеров, которые уже совершали попытки Атаки по Словарю.
Использование таких списков освобождает сервер от нагрузки и сводит старания спамеров к нулю.
С точки зрения сервера, крайне важно, чтобы вы использовали : fail :, а не : blackhole :
адреса электронной почты или адрес по умолчанию для блокирования такого спама.
Еще одна профилактическая мера заключается в том, чтобы правильно задать опции :
WHM > Exim Configuration Editor > Verify the existance of email senders.
WHM > Exim Configuration Editor > Use callouts to verify the existance of email senders.
Сервера> Редактор конфигурации Exim> Проверять существование адреса электронной почты отправителей.
Сервера> Редактор конфигурации Exim> Использовать обращение для проверки существования адреса электронной почты
Сервера> отправителей.
Эти два варианта позволяют exim убедиться в том, что любой сервер при попытки ретрансляции
электронной почты на Ваш сервер, сможет получить электронную почту в ответ. Это часть
требований RFC к почтовым серверам. Если сервер не способен сделать это - вероятно
он спамер.
Есть еще множество проверок, которые вы можете выполнить на этапе SMTР RCPT в exim ACLs.
Примеры используют RBL для проверки отвергаемых сообщение, которые приходят с IP-адресов
известных спамеров, например :
deny message = Message rejected - $sender_fullhost is in an RBL, see $dnslist_text
!hosts = +relay_hosts
!authenticated = *
dnslists = bl.spamcop.net : sbl-xbl.spamhaus.org
Вы можете также проверить формат заголовков электронной почты, с тем чтобы они
соответсвовали RFC требованиям. Заголовки многих спам-серверов не соотвествуют
спецификации. Типичным примером является проверка SMTP HELO/EHLO для обеспечения его
правильной структуры, например :
deny message = HELO/EHLO set to my IP address
condition = ${if match {$sender_helo_name}{11.22.33.44} {yes}{no}}
(где 11.22.33.44 - ваш основной серверный IP-адрес)
deny message = EHLO/HELO does not contain a dotted address
condition = ${if match{$sender_helo_name}{\.}{no}{yes}}
А потом, когда письмо прошло через эти фильтры, Вы можете дополнительно проверить сообщения электронной почты
на предмет спама и маркировать их, если это необходимо. cPanel имеет встроенное решение по борьбе со
спамом - SpamAssassin, которое успешно используется многими. С его помощью вы можете
отфильтровывать письма со спамом на специальный почтовый ящик или же просто помечать в заголовке письмо со спамом.
Альтернативой SpamAssassin является использование инструмента MailScanner, который может быть очень эффективным
в борьбе со спамом.
Инсталлятор этого скрипта бесплатно доступен для серверов с cPanel вот тут
http://www.configserver.com/free/mailscanner.html.
Однако, данный скрипт не получил официального одобрения от разработчиков cPanel. Поэтому, при
возникновении проблем с электронной почтой, данный скрипт должен быть отключен или удален, чтобы
вы могли получить техническую поддержку от разработчиков cPanel.
Исходящий спам от сервера
Исходящий спам, вероятно, может поступать из двух источников :
Косвенно из-за ненадежных веб-скриптов клиентов
Непосредственно от клиента
Отправной точкой для обоих будет exim mainlog :
/var/log/exim_mainlog (Linux)
/var/log/exim/mainlog (FreeBSD)
Для примера возьмем ОС Linux.
Наиболее трудоемок способ отслеживания писем по mainlog exim и поиск подозрительных записей.
Это действительно очень трудно сделать, и вам действительно нужно сузить зону поисков.
Выявление спамеров является сложным делом, но можно сделать его проще при некоторой предварительной
настройке серверов. Я бы настоятельно рекомендовал Вам включить следующие конфигурации exim, что
значительно повысит удобство поиска на сервере спамеров :
В WHM > Exim Configuration Editor > Switch to Advanced Mode >
в первом текстовом поле добавьте следующую строку, а затем "Сохранить" :
log_selector = +arguments +subject
Это укажет exim путь на диске, с которого была произведена рассылка по электронной почте и
тему сообщения. После этого вам будет легче искать необходимое в mainlog exim.
Предпочтительно отыскать письмо-спам по заголовку. Такой материал можно получить либо от лица
заявившего о спаме либо из остатков спамовых писем в очереди exim.
В частности, для exim можно узнать идентификатор сообщения (id) в Received : в строке заголовка сообщения о спаме.
Как например, после заголовка сообщения :
Return-path:
Received: from [11.22.33.44] (helo=barfoo.com)
by foobar.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.52)
id 1FZ8z3-0006M4-Do
for fred@foobar.com; Thu, 27 Apr 2006 17:04:49 +0100
Received: from forums by barfoo.com with local (Exim 4.43)
id 1FZ8zt-0005lz-E7
for fred@foobar.com; Thu, 27 Apr 2006 12:05:41 -0400
To: fred@foobar.com
Subject: Buy Me!
From: bob@barfoo.com
Received: заголовки строки добавляются серверами электронной почты, поэтому первоначальная
Received: строка, содержит то, что нас заинтересует, - это :
Received: from forums by barfoo.com with local (Exim 4.43)
id 1FZ8zt-0005lz-E7
for fred@foobar.com; Thu, 27 Apr 2006 12:05:41 -0400
И номер чего мы хотим, - 1FZ8zt 0005lz - E7
Это уникальный идентификатор для этого письма, отправленного с сервера. Благодаря этому
мы можем отследить в exim обращение с помощью команды :
grep 1FZ8zt-0005lz-E7 /var/log/exim_mainlog
(известно, что exim_mainlog файлы могут быть подвергнуты ротации, так что вам, возможно,
придется распаковывать архивы и проводить поиск в них)
Результатом выполнения запроса может выглядеть так :
2006-04-27 17:43:41 1FZ8zt-0005lz-E7 <= bob@barfoo.com U=nobody P=local S=4001 T="Buy Me!"
2006-04-27 17:43:50 cwd=/home/ClientX/public_html/phpBB/ 5 args: /usr/sbin/exim -Mc 1FZ8zt-0005lz-E7
2006-04-27 17:43:53 1FZ8zt-0005lz-E7 => fred@foobar.com R=lookuphost T=remote_smtp H=foobar.com [44.33.22.11]
X=TLSv1:AES256-SHA:256
2006-04-27 17:43:53 1FZ8zt-0005lz-E7 Completed
В этом примере видно, что сообщение поступает от пользователя nobody локально
с сервера. Это означает, что скорее всего спам был отправлен из скрипта на сервере.
Пользователь nobody используется для запуска сервера Apache и является по умолчанию
именем и группой пользователей, которым Apache будет выполнять веб-скрипты. Две вещи
могут влиять на это :
1.suexec, если он включен, запускает CGI скрипты, под учетной записью владелеца скрипт,
как правило, имя учетной записи в cPanel
2.phpsuexec, если он включен, запустит скрипты таким же образом, как и CGI скриптах
suexec, как правило, всегда включен на веб-серверах, а phpsuexec может и не быть. В случае
если phpsuexec не разрешен, то по всей вероятности, скрипт запустить из-под учетной записи nobody.
Из приведенного выше примера мы видим, что сценарий начинается с
/home/ClientX/public_html/phpBB/
директории на сервере, которая будет указывать на проблемный скрипт этого каталога.
А вот еще пример спама от клиента, а не скрипта. Это может произойти либо со злым умыслом,
или если на ПК клиента имеются вирусы или черви :
2006-04-27 17:54:51 1FZ9lT-000707-O2 <= bob@barfoo.com H=someisp.com ([192.168.254.2]) [11.22.33.44] P=esmtpa
A=fixed_plain:bob@barfoo.com S=715 id=ABCDEFG T="Buy Me!"
2006-04-27 17:54:51 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1FZ9lT-000707-O2
2006-04-27 17:54:51 1FZ9lT-000707-O2 => fred@foobar.com R=boxtraper_autowhitelist T=boxtrapper_autowhitelist
2006-04-27 17:54:52 1FZ9lT-000707-O2 => fred@foobar.com R=lookuphost T=remote_smtp H=foobar.com [44.33.22.11]
X=TLSv1:AES256-SHA:256
2006-04-27 17:54:52 1FZ9lT-000707-O2 Completed
В данном примере ключевым элементом является :
A=fixed_plain:bob@barfoo.com
Это показывает, что в сообщении для аутентификации было использована ретрансляция SMTP
AUTH (т.е. fixed_plain ) и имя пользователя bob@barfoo.com клиента ПК.
Как вы можете видеть, есть большой объем работы, необходимый для отлова спамеров
на сервере плюс есть дополнительная работа по закрыванию дыр в безопасности скриптов, если они
имеются. В некоторых случаях, может быть гораздо более сложным проверить логи Apache для доменов в
/usr/local/apache/domlogs/*.
Оптимально при эксплуатации сервера проводить меры по повышению безопасности и быть в курсе, кто и что позволяет себе на вашем сервере.