NDR-атака: Решение проблемы.

По-умолчанию, почтовый сервер Microsoft Exchange принимает все входящие по протоколу SMTP письма. Если сервер не может найти получателя письма внутри системы, то письмо возвращается назад отправителю (non-delivery report, NDR). В этой схеме кроется серьезная прореха в безопасности, так как адрес отправителя никак не проверяется и злоумышленник может указать любой адрес в качестве обратного.

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

• так как рекламное письмо возвращается сервером Exchange в виде вложения, то пользовательские фильтры, отлавливающие спам по ключевым словам в теле письма или заголовках, обычно пропускают его;
• многие из пользователей вручную удаляют рекламные письма, тратя на письмо менее секунды и не читая его, но увидев письмо с пометкой “ваше письмо не доставлено”, они, скорее всего откроют приложенное “недоставленное” письмо и уделят ему какое-то время – возможно, действительно, в их систему прокрался вирус и рассылает сообщения по адресной книге?;
• так как источникам рассылки в таких случаях является “честный” сервер, чей адрес не занесен ни в какие онлайновые базы (такие как SPEWS или ORDB), то серверные фильтры, включая новые фильтры появившиеся в сервере Microsoft Exchange 2003, пропустят его.

Последствия такой рассылки через ваш сервер могут быть печальными:

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

Но все эти неприятности покажутся мелочью по сравнению с таким сюрпризом, как попадание сервера в один из списков источников спама. Выбраться из такого списка гораздо сложнее, чем попасть в него. Пока вы переписываетесь с администратором одного из списков и объясняете, что пользователи были не совсем правы, когда писали что с вашего адреса идет спам, часть писем ваших пользователей не удается доставить, вашим пользователям перестает доходить часть писем. Самым неприятным сюрпризом является попадание в базу открытых релеев (серверов, которые принимают почту с любого адреса и доставляющих ее по назначению – такой сервер это настоящая находка для спамера). В этом случае сотни спамеров, которые внимательно изучают обновление этих списков, начнут пытаться разослать спам через ваш сервер. На протяжении нескольких недель, пока спамерская программа не выкинет ваш адрес как безнадежный, ваш сервер ждет серьезное испытание. А если среди спамеров окажутся те, кто рассылает спам при помощи NDR, то у вас будет только один выход – прекратить это безобразие, отказавшись от схемы с NDR.

Было бы не правильно говорить, что у Microsoft совсем нет никакого решения на этот счет. Как вариант, можно руководствоваться Q315631 - HOW TO: Forward Mail with Unresolved Recipients to a Single Mailbox. По этому сценарию нужно создать дополнительный виртуальный сервер SMTP, на который перенаправлять всю почту для unresolved recipients; создать при помощи Microsoft Visual Basic компонент ActiveX, который будет исправлять адрес в полученном письме, после чего письмо будет возвращаться на главный сервер.

Основной недостаток этого метода, не считая определенной сложности в реализации, в том что сервер Exchange все равно продолжает принимать все письма. Это создает и ненужный сетевой трафик, и ненужную нагрузку на сервер.

Оптимальное решение – когда письма на несуществующий адрес просто не принимаются сервером, отсекаясь еще на уровне протокола SMTP. В этом случае NDR для пользователя генерирует сервер отправителя, что, на самом деле, является общепринятой практикой.

Mail Storage Guard может предоставить на выбор оба варианта защиты от NDR-атаки. Он может либо перенаправить всю почту с unresolved recipient на выбранный ящик, либо может на уровне SMTP отказать в приеме почты на несуществующий адрес. Одним нажатием кнопки вы можете переключить схему работы Mail Storage Guard – во время атаки отказаться принимать почту на несуществующие адреса, а в “мирное время” перенаправлять ее администратору, чтобы он вручную переслал ее на правильный адрес.

Mail Storage Guard проверяет наличие существования адреса как по Active Directory, так и по простому списку в текстовом файле, что позволяет использовать его не только совместно с Microsoft Exchange Server, но и с обычным сервисом Windows SMTP, когда он выступает в качестве front-end для любого другого почтового сервера.

С остальными возможностями Mail Storage Guard вы можете ознакомиться на странице продукта.

Ссылки по теме (материалы на английском языке):

• PC World: Could You Be Sending Spam?
• Q324021 HOW TO: Create a "Catchall" Mailbox Sink for Exchange 2000.
• Q304897 XIMS: Microsoft SMTP Servers May Seem to Accept and Relay E-Mail Messages in Third-Party Tests
• Q315631 HOW TO: Forward Mail with Unresolved Recipients to a Single Mailbox
• Mail Storage Guard: Product overview.