Технологии безопасности

Еще раз про RBL’и

Мы попали!


Вчера вечером звонит мне один из наших коммерсантов и с ужасом говорит, что сервер попал в RBL, и теперь часть почты с нашего сервера до части клиентов не доходит. Добравшись до компьютера, обнаруживаю, что сетка, в которой стоит сервер, действительно, в очередной раз попала в список запрещенных sbl.spamhaus.org.

Я абсолютно уверен, что это не наша ‘заслуга’, т.к. наша компания спам никогда не рассылала и рассылать не будет, мы совсем по другой части. Но история эта повторяется уже не первый раз, так что порядок действий понятен: надо обращаться в поддержку РТКомм, где находится наш сервер. Что я и делаю, помянув создателей Spamhaus недобрым словом.

За что я не люблю Spamhaus


Чтобы понять, за что я не недолюбливаю Spamhaus, нужно объяснить, что это такое. Spamhaus это одна из онлайновых баз данных, содержащая IP-адреса, тем или иным способом связанные с рассылкой спама. Такие ресурсы называют также Real-time Blackhole Lists (списки запрещенных реального времени).

Принципы составления баз RBL довольно существенно различаются. Spamhaus представляет две базы, отличающиеся по способу наполнения. Первая база называется Exploits Block List (или сокращенно XBL), содержит IP-адреса известных или потенциальных источников спама, таких как открытые трансляторы почты (open relays) или машины с известными троянскими программами и вирусами, содержащими функции рассылки спама. XBL представляет собой компиляцию из трех тематических списков. Их авторы проводят тестирование компьютеров и выявляют возможность угрозы рассылки спама с тех или иных адресов.

Вторая база — Spamhaus Block List или SBL, — включает адреса источников спама, адреса, связанные со спамерскими командами, а также их информационной инфраструктурой. Поскольку понятие ‘команда’ и ‘инфраструктура’ четко определить невозможно, то внесение адресов производится в соответствии с политикой SBL. Эта политика опубликована на сайте spamhaus.org (http://www.spamhaus.org/sbl/sbl-rationale.html) и вкратце может быть сформулирована так: в базу SBL заносятся сети, из которых производится спамерская рассылка, а также сети, которые используются для поддержки и хостинга спамерских ресурсов — почтовых серверов, web-сайтов, DNS и т.п.

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

В простейшем случае письмо просто отвергается, если IP-адрес найден в списке запрещенных, или принимается, если адрес отправителя в них не ‘засвечен’. Более сложные антиспам-фильтры используют более изощренные правила, комбинируя информацию списка запрещенных с другими методами распознавания спама. Этот способ считается более надежным, т.к. позволяет сгладить ошибки каждого отдельного метода. Так что сам по себе Spamhaus, как, впрочем, и любой другой RBL-сервис, не фильтрует почту, а только предоставляет информацию о подозрительных IP-адресах отправителя. Доверять ли информации RBL и в какой степени, решает, в конечном счете, администратор почтового сервера, внедряющий и настраивающий антиспам-фильтры.

Вернемся к базам Spamhaus. Если к базе XBL, составляемой по чисто техническим показателям, явных претензий у меня, в общем-то, нет, то с SBL и его политикой дело обстоит существенно сложнее.

Разбор полета


Предлагаю рассмотреть практику применения политики SBL на примере последнего инцидента с нашим участием.

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

http://citibankonline.com/domain/redirect/citi.com/global_nav/iandm.htm?BVP=/&M=S&US&_u=visitor&BVE=http://cdsass40e.com*20006.da.RU

Разумеется, адреса сайта фишеров тут не видно — он замаскирован двумя редиректами, т.е. автоматическим перенаправлением запроса пользователя между сайтами. Первый редирект сделан прямо с сайта Ситибанка — это вся конструкция, начинающаяся с citibankonline.com до параметра BVE=, который, судя по всему, и показывает, на какой сайт нужно перебросить пользователя при нажатии на ссылку. Поскольку ссылка очень длинная, пользователь может не разобраться или попросту не заметить, что имеет дело не со ссылкой на сайт Ситибанка, а с перенаправлением на сайт cdsass40e.com*20006.da.RU.

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

Это действия спамеров. Реакция Spamhaus на эту рассылку такова: в базу SBL в соответствии с политикой были занесены сети РТКомм и Релкома (по 256 адресов каждая), в которых размещены:


  • собственно сайт Da.ru — это на основании того, что сайт поддерживает спамерские сервисы;
  • сеть провайдера, в которой размещен собственно сайт Da.ru;
  • сети, в которых размещены DNS-серверы, поддерживающие домен Da.ru.

Так получилось, потому что в соответствии с политикой Spamhaus сайт Da.ru поддерживает спамерские сервисы, а РТКомм и Релком обеспечивают инфраструктуру сайта, поддерживающего спамеров. Вместе с сетью РТКомма в SBL оказался наш сервер, а заодно и еще целый ряд вполне добропорядочных ресурсов, размещенных на хостинге в датацентре РТКомм.

Дальше происходит следующее. Мы начинаем получать сообщения, что какие-то почтовые системы отказались принимать наши письма на том основании, что IP-адрес нашего сервера обнаружен в sbl.spamhaus.org. Таких отказов в процентном отношении не очень много. Но они не могут не огорчать, т.к. среди ‘отказников’ есть и наши партнеры, и клиенты, с которыми ведется интенсивная переписка, так что эту проблему нужно решать. За этим я и обратился в поддержку РТКомма — общаться со Spamhaus по поводу блокировок должен владелец сети. Что и в какие сроки удастся сделать — посмотрим.

Кто виноват?


Ситуация сложилась достаточно странная — нормальные не спамерские ресурсы оказались под блокировкой. Виноваты в этом, разумеется, фишеры, из-за которых все и произошло. Но вот корректны ли действия остальных участников ‘процесса’?

На мой взгляд, обвинять Da.ru или провайдеров в пособничестве спамерам довольно странно. В конце концов, судьбу Da.ru может с легкостью разделить практически любой бесплатный ресурс — почта, редирект, хостинг, список можно продолжить. Провайдеры же, имеющие договорные отношения со своими клиентами, тоже не могут просто так отказать в обслуживании клиенту, который выполняет все предъявленные к нему требования: технические и юридические. Так что, на мой взгляд, применение Spamhaus своей политики не вполне корректно.

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

Тут, правда, тоже надо оговориться. Разные способы внедрения и настройки антиспама приводят к разной степени жесткости использования RBL. Например, в нашем случае я видел в логах сервера лишь единичные отказы от приема от SpamAssassin, который использует RBL только как один из признаков. Зато львиная доля отказов приходила от почтовых серверов, в которых RBL использовался в ‘жестком’ режиме, когда письма однозначно отвергаются в случае попадания IP-адреса в список запрещенных.

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

Что делать


В конце хотелось бы дать несколько рекомендаций администраторам, которые предпочитают использовать RBL’и более осмысленно.


  1. RBL’и, даже ‘правильные’, сами по себе дают не очень высокий процент распознавания спама при заметном числе ложных срабатываний. Из этого следует, что не стоит полагаться на встроенную в почтовые серверы ‘жесткую’ поддержку RBL. Лучше использовать их в составе антиспам-фильтров. При этом вес RBL в решающих правилах фильтра не должен быть слишком большим.
  2. Для фильтрации почты можно применять RBL’и, содержащие известные и потенциальные источники спама. К таким спискам относятся relays.ordb.org, dul.ru, orbs.dorkslayers.com, bl.spamcop.net, relays.mail-abuse.org и некоторые другие.
  3. Списки RBL, применяющие ‘политический’ подход к построению базы, использовать для фильтрации почты крайне нежелательно. К ним относятся, в частности, списки spews.dnsbl.sorbs.net, block.blars.org, sbl.spamhaus.org, а также наши отечественные списки work.drbl.mokr.ru, work.drbl.democracy.ru.

Для тех, кто заинтересовался вопросами применения RBL для борьбы со спамом, рекомендую следующие статьи:


1  Сразу хочу отметить, что к моменту написания статьи перенаправления и на сайте Ситибанка, и на da.ru были удалены. На сайте Ситибанка перенаправление ведет на страницу с предупреждением об опасности похищения информации карты и рекомендациями, как этого избежать. На da.ru — просто выдается сообщение о неизвестном адресе. >>

Еще раз про RBL’и

Ваш e-mail не будет опубликован. Обязательные поля помечены *

 

Отчеты

MosaicRegressor: угроза в недрах UEFI

Мы обнаружили скомпрометированный образ прошивки UEFI, содержащий вредоносный имплант для установки дополнительного вредоносного ПО на компьютеры жертв. Насколько мы знаем, это второй общеизвестный случай обнаружения активного заражения в прошивке UEFI.

Подпишитесь на еженедельную рассылку

Самая актуальная аналитика – в вашем почтовом ящике