Open relay

Как закрыть Open Relay и почему он появился?

Предисловие: Здесь рассматривается случай, когда вы имеете свою сеть с приватными адресами (вроде 192.168.x.x), шлюз в Internet и запущенные на нем smtp-сервер и/или http-proxy сервер. Администраторы сетей с реальными адресами, imho, в подобных статьях не нуждаются.

Любой сервис, если он не нужен наружным клиентам, следует сделать недоступным для них. Для почтового сервера это случай, когда он не обслуживает реальный домен. Тогда ему не нужно слушать 25 порт на внешнем интерфейсе. Поэтому или прикройте его firewall-ом, или привяжите к внутреннему интерфейсу, или задайте ограничения на адреса клиентов (не все почтовые сервера могут это делать). Лучше сделать сразу всё — для гарантии.
Что касается http-proxy, то он и не должен быть доступен внешним клиентам. Настройте его так, чтобы он слушал порт только на внутреннем интерфейсе. В squid это настраивается параметром http_port. Измените значение по умолчанию 'http_port 3128" на "http_port 192.168.0.1:3128" (или какой там у вас внутренний адрес и порт). Если в вашем http-proxy нет такой функции, запретите firewall'ом входящие пакеты на порт, слушаемый http-proxy и/или поставьте ограничения на адреса клиентов (в squid это acl src).

Теперь рассмотрим случай, когда ваш почтовый сервер обслуживает реальный домен и доступен снаружи. Все письма, принимаемые почтовым сервером к отправке, делятся на два типа:

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

Во втором случае возможна неправильная настройка почтовго сервера, когда он разрешает пересылку почты кому угодно и куда угодно. (Обычно такая конфигурация получается, если сервер не настраивают после инсталляции). Сервера, позволяющие бесконтрольно пересылать через себя почту называют "Open relay". Они являются одним из основных средств распространения спама. Чтобы предотвратить использование своего сервера в таком качестве, необходимо задействовать соответствующие настройки:

Разрешение выдается на основании ip-адресов клиентов, т.е. разрешается relay только для своей сети. Это imho самый распространенный подход. Так обычно поступают провайдеры (разрешая пересылку от клиентов из своих подсетей), администраторы предприятий, имеющих внутренние сети и пр.
Разрешение по обратному адресу. Так поступают системы вроде mail.ru и пр., клиенты которых разбросаны по чужим сетям. Не самое удачное решение, т.к. спамер может подставить обратный адрес одного из ваших клиентов. Если ваш почтовый сервер работает по такой методике, то лучше подумать о каком-нибудь более защищенном подходе.
SMTP-авторизация. В случае, если пользователи вашего домена отправляют почту через вас не только из сети предприятия, то фильтрация по ip-адресам неприменима. Разрешение на пересылку дается после успешной авторизации по smtp. В этом случае, спамер может узнать пароль одного из клиентов и использовать его account для пересылки своей почты. Поэтому стоит помнить, что, во-первых, пароли по smtp по умолчанию передаются в открытом виде (и могут быть перехвачены с помощью sniffer'а), и, во-вторых, спамер может подобрать пароль. Поэтому используйте различные методы шифрования трафика и доведите до сведения пользователей, что за все, что будет сделано под их учетной записью, отвечают они. Т.е. пусть выбирают сложные пароли и никому их не говорят. Рекомендуется иногда запускать программы подбора паролей и пытаться подобрать пароли пользователей (для проверки). Также лучше выставить ограничения по количеству неудачных login'ов.
Принцип SMTP after POP3. Примерно то же самое, что и предыдущий способ. После успешной авторизации по POP3 разрешается отправка почты с ip-адреса клиента в течение некоторого времени. Соображения те же, что и в предыдущем пункте.

Решение о сочетании тех или иных способов принимать вам. Помните, что все равно есть возможность рассылки спама от имени ваших пользователей (взлом пароля, взлом машины пользователя и использование её как relay, тривиальная глупость и пр.) Поэтому лучше дополнительно поставить ограничения на количество отправляемых за smtp-сессию писем, количество адресатов в одном письме и пр.

Кроме использования smtp, спам через ваш сервер могут слать еще несколькими способами:

Open proxy. Если вам не удалось сделать ваш http-proxy недоступным снаружи, то негодяи могут воспользоваться особенностями метода CONNECT для пересылки почты. В этом случае ваш http-proxy сервер будет выступать как open relay. Чтобы избежать этого:
1. Настройте сервис так, чтобы он был недоступен снаружи, как это было описано выше.
2. Запретите метод CONNECT на все порты, кроме тех, на которые он действительно должен подключаться. В squid для этого есть уже готовый acl и правила:
  acl CONNECT method CONNECT
  acl SSL_ports port 443 563 #(можно добавить еще 5190 для ICQ)
  http_access deny CONNECT !SSL_ports
Следует помнить, что Apache тоже может служить http-proxy, если был собран с модулем mod_proxy.
Использование backdoor. Если вашу машину взломали, то злодеи могут поставить вам какой-нибудь backdoor, работающий как smtp open relay, поэтому необходимо как следует следить за безопасностью своих серверов. Также, могут взломать одного из ваших клиентов, поэтому необходимо предусмотреть и этот случай и следить за подозрительной активностью изнутри сети.
Использование фич SMTP, вроде отправки сообщений на адреса вида:
В этом случае, все целиком зависит от возможности настройки конкретного почтового сервера. Если его поведение в таких ситуациях не задокументировано, проверьте его сами.

Даже если вы все хорошо настроили, будет полезно проверить самого себя и использовать какие-нибудь программы для тестирования. Для этих целей подходит X-Spider (к сожалению, начиная с версии 7, он не бесплатен). Можно использовать on-line тесты, например на www.ordb.org. Можно подключиться telnet'ом на 23 порт relay-test.mail-abuse.org — этот сервер сам произведет проверку подключающейся машины и выведет в окне сеанса подробный протокол. Если кто знает еще какие-нибудь хорошие (бесплатные) программы и on-line тесты -- пишите мне (articles <at> lithium.opennet.ru).