Большую часть почтового трафика в интернете сейчас составляют автоматически сгенерированные нежелательные рассылки. До 90% поступающих на популярные почтовые серверы писем могут являться спамом, и если почтовый сервер начнет сканировать каждое из них на вирусы и признаки спама, то очень скоро он окажется перегружен и возникнет риск того, что деловые письма не дойдут до адресатов. Чтобы этого не произошло, входящие письма нужно фильтровать, то есть по косвенным признакам определять подлинные письма от нежелательных. Одним из передовых решений для этого является Postscreen — встроенный в Postfix фильтр для отсеивания автоматически сгенерированных писем. В данной статье мы расскажем о том, как использовать и как настраивать Postscreen, чтобы он работал максимально эффективно и позволял не тратить серверные мощности на обработку нежелательных писем.

Принцип работы Postscreen заключается в мониторинге и проверке входящих подключений при помощи различных SMTP‑проверок, а также использовании динамических и статических белых и черных списков для их фильтрации.

Первые проверки, которые проходят входящие подключения — это проверки на наличие IP‑адреса в статических и динамических белых и черных списках, а также проверка с помощью фейкового MX.

Если подключающегося клиента нет ни в белых, ни в черных списках, Postscreen выполняет ряд проверок перед приветствием 220 SMTP. Эти проверки включают в себя тест на ожидание приветствия, а также проверка черных списков расположенных в интернете. Эти проверки позволяют эффективно защищаться от DoS‑атак.

Когда эти проверки пройдены, либо не применялись к входящему подключению, проводятся проверки после приветствия 220 SMTP. Они включают в себя глубокий анализ электронного письма. Среди них тест на выполнение одной команды за раз, тест на отправку команд не относящихся к протоколу SMTP, а также тест на символы в конце строки. Эти проверки являются наиболее «дорогими» с точки зрения затрат системных ресурсов, но при этом наиболее эффективными с точки зрения выявления спам‑рассылок..

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

Статические черные и белые списки

Администратор почтового сервера Carbonio может создавать списки доверенных и недоверенных сетей. При создании списка доверенных сетей все письма, которые приходят с входящих в него IP‑адресов, будут гарантированно успешно проходить проверку Postscreen, а письма, поступающие с IP‑адресов из недоверенных сетей будут автоматически отсеиваться.

Настраиваются черные и белые списки командой zimbraMtaPostscreenAccessList. По умолчанию она имеет значение «permit_mynetworks», то есть гарантирует успешное прохождение локальной доставки писем. Для того, чтобы иметь возможность добавлять адреса в белый и черный списки, требуется создать таблицу доступа и дополнить ей параметр zimbraMtaPostscreenAccessList.

Для примера создадим таблицу /opt/zextras/postscreen_access.cidr. Убедитесь, что пользователь zextras имеет права на чтение и запись в данный файл. После этого можно приступить к заполнению данной таблицы. Она состоит из двух столбцов: в левом содержится IP‑адрес или целая подсеть, а в правом действие, которое к ним применяется. Для примера:

192.168.0.1 permit
10.0.1.1/16 reject

В данном случае мы разрешаем доступ письмам с адреса 192.168.0.1 и запрещаем получение писем из подсети 10.0.1.1/16. Очень важным моментом является то, что правила из CIDR‑таблицы применяются по порядку. То есть если вы сначала одним правилом добавляете IP‑адрес в черный список, а затем другим правилом — в белый, то Postscreen применит к письму только первое правило и не дойдет до второго.

Для того, чтобы добавить созданную нами таблицу в Postscreen, используйте команду carbonio prov mcf zimbraMtaPostscreenAccessList permit_mynetworks,cidr:/opt/zextras/postscreen_access.cidr

Как и в любой другой проверке администратор может настроить действия, которые принимаются к хосту, если он находится в черном списке. Настраивается это при помощи параметра zimbraMtaPostscreenBlacklistAction. Доступны действия: игнорировать результаты данной проверки и перейти к другим (ignore), учесть результаты проверки перейти к следующим (enforce), отказать в соединении (drop).

Динамические белые списки

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

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

Администратор может задать время очистки кэша с временным белым списком. Делается это при помощи команды carbonio prov mcf zimbraMtaPostscreenCacheCleanupInterval. По умолчанию значение данного параметра составляет 12h, то есть 12 часов. Администратор может увеличить это время или уменьшить. В случае, если указано нулевое значение, кэш перестает очищаться вообще. Делать так не рекомендуется, потому что это не безопасно. С другой стороны очистка кэша создает нагрузку на почтовый сервер, поэтому запускать ее слишком часто также не стоит.

Помимо стандартного кэша в Postscreen используется и расширенный кэш, который хранит данные клиентов, проходивших более глубокие проверки, в том числе связанные с необходимостью переподключения. Связанные с этим неудобства Postscreen компенсирует более долгим сроком хранения результатов проверки таких клиентов. Длительность их хранения регулируется командой carbonio prov mcf zimbraMtaPostscreenCacheRetentionTime. Значение этого параметра по умолчанию составляет 7d, то есть одну неделю, а установка нулевого значения подразумевает вечное хранение результатов глубокой проверки клиентов.

Проверка на подключение к резервному MX

Одним из наиболее частых приемов, которые используют спамеры - подключение к почтовому серверу через резервный MX-сервер, который при нормальных условиях используется только в случае отказа основных. Как правило защита на таких резервных MX гораздо слабее, чем на основных, однако если соответствующая проверка в Postscreen включена, то подключение хоста к резервному MX будет зафиксировано и если он в дальнейшем пройдет все остальные проверки на основных MX, то не будет занесен в белый список из-за этого. Данная проверка включается автоматически при наличии в Carbonio основного и резервного MX и не требует дополнительной настройки.

Проверка на ожидание приветствия

В рамках данной проверки Postscreen отправляет подключающемуся клиенту SMTP-приветствие и ожидает от него ответного приветствия. Суть проверки заключается в том, что автоматизированная рассылка реализуется таким образом, чтобы до победного пытаться отправить письмо со спамом и не рассчитана на более сложные паттерны поведения. Таким образом вместо ответного приветствия Postscreen получает очередную попытку отправить письмо и таким образом проверяет входящее подключение на легитимность.

Как и в случае других проверок администратор может настроить действия, которые предпринимаются при провале данной проверки. Доступны действия: игнорировать результаты данной проверки и перейти к другим (ignore), учесть результаты проверки перейти к следующим (enforce), отказать в соединении (drop). По умолчанию zimbraMtaPostscreenGreetAction имеет значение ignore.

При помощи параметра zimbraMtaPostscreenGreetTTL можно задать период времени, на протяжении которого прошедший успешно данную проверку хост будет находиться во временном белом списке. По умолчанию этот параметр составляет 1d, то есть один день. Настроить его можно с помощью команды вида carbonio prov mcf zimbraMtaPostscreenGreetTTL 7d. В случае выставления нулевого значения, прошедший проверку хост попадает во временный белый список навсегда.

Проверка на черные списки DNS

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

Настроить список сайтов с черными списками можно при помощи команды zimbraMtaPostscreenDnsblSites. В случае использования нескольких источников с черными списками DNS может возникнуть ситуация, когда в части из них хост представлен, а в части из них — нет. Чтобы не допустить ситуацию, при которой легитимное письмо будет отвергнуто почтовым сервером просто из‑за того, что хост попал в один из используемых вами черных списков, можно настроить определенный порог, который формируется на основании совокупных данных из используемых вами источников.

Настраивается этот порог при помощи команды carbonio prov mcf zimbraMtaPostscreenDnsblThreshold 2. По умолчанию, ответ от каждого из внесенных в список zimbraMtaPostscreenDnsblSites сайтов оценивается в 1 балл, однако администратор может увеличить это значение. К примеру, при выполнении команды carbonio prov mcf +zimbraMtaPostscreenDnsblSites blacklist.ru*2 в список сайтов с черными списками DNS будет добавлен сайт blacklist.ru, а обнаружение хоста в данном списке добавит ему 2 балла. В нашем случае, когда порог составляет всего два балла, это будет означать провал соответствующей проверки. Используйте множитель баллов только с тем черными списками DNS, в которых полностью уверены.

Также данная проверка может использоваться в качестве ультимативной проверки, при прохождении которой все остальные тесты либо не применяются, либо считаются пройденными, а хост вносится во временный белый список. Настраивается это командой carbonio mcf zimbraMtaPostscreenDnsblWhitelistThreshold 0. Таким образом не набравший ни одного балла при проверке черных списков DNS хост освобождается от дальнейших проверок и вносится во временный белый список.

Продолжительность нахождения в белом списке при прохождении теста на черные списки DNS регулируется параметром zimbraMtaPostscreenDnsblTTL. По умолчанию она составляет 1 час и может быть настроена аналогично другим проверкам.

Учитывая, что публичные черные списки регулярно обновляются, может оказаться, что прошедший эту проверку хост уже через минуту может в них оказаться. Именно поэтому для данной проверки существует возможность настроить исключения — добавленные в белые списки хосты всё равно должны будут периодически проходить данную проверку для отслеживания изменений. Настраивается данное исключение при помощи команд zimbraMtaPostscreenDnsblMinTTL и zimbraMtaPostscreenDnsblMaxTTL. С их помощью настраивается минимальный период времени, после которого хосту потребуется пройти данную проверку, а также максимальный срок хранения данных об успешном прохождении данной проверки. По умолчанию значение zimbraMtaPostscreenDnsblMinTTL составляет 60s, что соответствует одной минуте, а значение zimbraMtaPostscreenDnsblMaxTTL по умолчанию не задано.

Также с помощью параметра zimbraMtaPostscreenDnsblAction можно настроить действие, которое будет предприниматься при провале данной проверки. Как и в случае с другими проверками, доступны действия ignore, drop и enforce.

Проверка на не-SMTP команды

Данная проверка по умолчанию отключена, так как требует наибольшее количество ресурсов, а также сопряжена с определенными рисками. Ее суть заключается в том, что входящее SMTP‑соединение переводится на фейковый SMTP‑сервер, где его поведение тщательно анализируется и в случае, если он начинает передавать SMTP‑команды, которые запрещены к выполнению, проверка считается проваленной. В случае же, если проверка успешно пройдена, клиент все равно отключается от сервера для того, чтобы подключиться к реальному SMTP‑серверу.

Для включения данной проверки установите параметр zimbraMtaPostscreenNonSmtpCommandEnable на значение yes. Также при помощи параметров zimbraMtaPostscreenNonSmtpCommandAction и zimbraMtaPostscreenNonSmtpCommandTTL можно настроить действие, которое будет применяться при провале проверки (enforce, drop, ignore) и время нахождения в белом списке при успешном её прохождении (по умолчанию 30d)

Проверка соблюдения стандарта символов конца строки

Поскольку SMTP является строчно‑ориентированным протоколом, а длина строк и их окончание строго регламентирована, Postscreen может отсеивать входящие письма по признаку соответствия стандартам. К примеру, если данная проверка включена, то при поступлении обращения, строка в котором заканчивается на <LF> вместо предусмотренных стандартом <CR><LF>, либо превышена длина строки, Postscreen может автоматически отсеять такое письмо.

Данная проверка отключена по умолчанию, однако администратор может включить ее при помощи команды carbonio prov mcf zimbraMtaPostscreenBareNewlineEnable yes. Также требуется настроить действие, которое применяется при провале клиентом данной проверки. Доступны действия: игнорировать результаты данной проверки и перейти к другим (ignore), учесть результаты проверки перейти к следующим (enforce), отказать в соединении (drop). По умолчанию zimbraMtaPostscreenBareNewlineAction имеет значение ignore.

Время добавления прошедших проверку писем во временный белый список регулируется параметром zimbraMtaPostscreenBareNewlineTTL. По умолчанию он составляет 30d, то есть 30 дней. При указании нулевого значения прошедшие данную проверку клиенты вносятся в белый список навсегда.

Тест на одну команду за раз

Данная проверка позволяет выявить зомби‑ботов, которые бесконтрольно посылают множество SMTP‑команд на сервер вместо того, чтобы отправить одну команду, дождаться ответа на нее и потом послать следующую. Эта проверка также по умолчанию отключена и включить ее можно командой carbonio prov mcf zimbraMtaPostscreenPipeliningEnable yes.

Время добавления прошедших проверку писем во временный белый список регулируется параметром zimbraMtaPostscreenPipeliningTTL. По умолчанию он составляет 30d.При указании нулевого значения прошедшие проверку клиенты вносятся в белый список навсегда. Настроить действие при провале клиентом данной проверки можно с помощью параметра zimbraMtaPostscreenPipeliningAction.

Помимо самих проверок, Postscreen содержит и другие настройки, которые обеспечивают его надежную и безопасную работу. Это zimbraMtaPostscreenCommandCountLimit — параметр, который определяет максимальное количество SMTP‑команд, которое может передать клиент при подключении к Postscreen, а также zimbraMtaPostscreenWatchdogTimeout — параметр, который определяет максимальное время, которое дается Postscreen для ответа на запрос клиента. Он служит для защиты Postscreen от зависания или сбоев в самом Postfix. По умолчанию этот параметр составляет 10 секунд и не может быть ниже.

Наиболее оптимальными настройками Postscreen в Carbonio считаются:

• zimbraMtaPostscreenDnsblAction=enforce

• zimbraMtaPostscreenGreetAction=enforce

• zimbraMtaPostscreenPipeliningAction=enforce

• zimbraMtaPostscreenNonSmtpCommandAction=drop

• zimbraMtaPostscreenDnsblTTL=5m

Таким образом Postscreen является первой линией защиты почтового сервера от нежелательной почты, который фильтрует ее по внешним признакам. Более глубокой фильтрацией почты занимаются встроенные в Carbonio Amavis, SpamAssassin и ClamAV.

По вопросам тестирования, приобретения, предоставления лицензии и консультаций обращаться на почту sales@svzcloud.ru к эксклюзивному партнеру Zextras.