Отличная идея? Отказаться от входящих писем с окончанием нашего собственного домена? (потому что они должны быть поддельными)


33

У меня вопрос по поводу нашего сервера Exchange: считаете ли вы хорошей идеей отказаться от входящих внешних писем, которые в конечном итоге имеют наш собственный домен?

Как внешний адрес электронной почты от fake@example.com?

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

Если да, каков наилучший способ сделать это?


3
Есть ли у вас какое-либо решение для фильтрации спама прямо сейчас?
ewwhite

14
Вам следует еще раз проверить, что у вас нет поставщиков каких-либо веб-приложений, пытающихся отправлять сообщения с вашего собственного домена. Например, если у вас есть система начисления заработной платы, которая может отправлять вашим сотрудникам электронные письма от "payroll@example.com". Также проверьте, может ли отдел маркетинга или отдел кадров использовать внешнюю почтовую службу, и они хотят, чтобы сотрудники получали эти сообщения. Обычно эти сообщения имеют адрес отправителя или, по крайней мере, адрес для ответа кого-то в маркетинге или отделе кадров. В таких ситуациях вы, как правило, сможете включить почтовые серверы службы в список разрешенных и по-прежнему блокировать входящий в ваш собственный домен (это то, что мы делаем).
Тодд Уилкокс

6
@NeilMcGuigan Что бы это значило? Почта все равно должна исходить с внутреннего почтового сервера? Это не будет происходить извне сети только потому, что он физически не присутствует.
Мэтт

@Matt gotya, brainfart
Нил Макгиган

1
Если у вас есть автоматические уведомления по электронной почте, приходящие с одного из ваших серверов, например, уведомления о сбоях заданий cron, или попытка взлома из IDS, или монитора использования ресурсов, и они настроены так, чтобы их адрес From соответствовал имени вашего домена. Вам необходимо позаботиться о том, чтобы направлять эти письма через внутренний почтовый сервер или вносить в белый список эти серверы в качестве разрешенных отправителей.
Ложь Райан

Ответы:


53

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

Сделав этот шаг дальше, вы можете настроить свой сервер для проверки записей SPF. Это то, сколько хостов предотвращают подобную деятельность по электронной почте. Записи SPF - это запись DNS, запись TXT, в которой указаны правила, которым серверам разрешено отправлять электронную почту для вашего домена. Как включить проверку записей SPF, зависит от вашей почтовой службы и выходит за рамки того, что здесь описано. К счастью, большинство хостинговых сред и программного обеспечения будут иметь документацию для работы с записями SPF. Возможно, вы захотите узнать больше о SPF в целом. Вот статья в Википедии: https://en.wikipedia.org/wiki/Sender_Policy_Framework


3
@Kurtovic хорошо настроенный почтовый сервер должен отсылать отклоняемое письмо, поэтому отправитель будет уведомлен.
Калимо

8
@Calimo Не, когда он отклоняет электронную почту за спам. Это позволит спамеру продолжать попытки, пока он не узнает, что ваш алгоритм позволяет, а что нет.
Джон Бентли

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

2
@cas: есть третий вариант: отклонить во время приема SMTP. Это оставляет бремя создания ответа об ошибке на отправляющем SMTP-сервере, если он этого хочет, и тем самым позволяет многим законным отправителям видеть, была ли отклонена их почта, при этом гарантируя, что вы никогда не будете создавать спам самостоятельно.
R ..

2
@R .. я думаю, вы обнаружите, что это не третья альтернатива, это перефразировка того, что я сказал: «просто отвергайте нежелательную почту - решение этой проблемы - проблема отправляющего хоста».
Cas

31

Уже есть стандарт для этого. Это называется DMARC . Вы реализуете это с подписью DKIM (что в любом случае является хорошей идеей).

Общий обзор заключается в том, что вы подписываете каждое электронное письмо, которое покидает ваш домен, заголовком DKIM (что в любом случае является хорошей практикой). Затем вы настраиваете DMARC для отклонения каждого электронного письма, которое попадает на ваш почтовый сервер, из домена, которым вы владеете, и которое не подписано действительным заголовком DKIM.

Это означает, что внешние службы могут по-прежнему доставлять электронную почту на ваш домен (например, размещенное программное обеспечение службы поддержки и т. Д.), Но могут блокировать попытки фишинга.

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

Недостатком является то, что вы должны быть уверены, что у вас есть все тщательно разобрано заранее, или вы можете начать отбрасывать законные электронные письма.


3
Настоятельно рекомендуется внедрить SPF и DKIM перед тестированием DMARC.
Тодд Уилкокс

Как DMARC может работать с электронными письмами, которые приходят с сервера, отличного от вашего, например, с внешними службами, если они не будут подписаны вашим сервером?
jpaugh

1
@jpaugh, вы добавляете открытый ключ других серверов в свои записи DMARC в DNS. Они смогут дать вам запись для добавления.
Марк Хендерсон

Я добавил +1 к этому ответу, потому что он технически правильный - именно для этого и предназначен DMARC, но DMARC - очень плохая идея, если вы хотите взаимодействовать с такими вещами, как списки рассылки, поскольку он нарушает RFC и вообще плохо себя ведет.
MadHatter поддерживает Монику

11

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

Dkim может смягчить это до некоторой степени, предоставляя способ идентифицировать сообщение, которое было отправлено из вашей сети, прошло через список рассылки или пересылку, а затем было получено на вашу почту, но это не идеальное лекарство, некоторые списки рассылки могут сломать подписи dkim и у вас все еще есть проблема с отслеживанием всех законных точек отправления почты и проверкой того, проходят ли они подписчик dkim.

Действуйте осторожно, особенно если вы реализуете это в существующем домене


3

Возможно, но есть некоторые случаи, которые необходимо рассмотреть, прежде чем вносить такие изменения.

1) Кто-нибудь в вашей компании использует какие-либо внешние службы (например, Survey Monkey, Constant Contact и т. Д.) Для рассылки электронных писем, которые, по-видимому, «с» вашего домена? Даже если они не делают этого сегодня, могут ли они сделать это в будущем?

2) Есть ли внешние адреса, которые пересылают вашим пользователям? Например, предположим, что учетная запись gmail «mycompany.sales@gmail.com» пересылается на «sales@mycompany.com», а ваш пользователь «bob@mycompany.com» отправляет на «mycompany.sales@gmail.com». В этом случае сообщение будет доставлено извне, но с адресом «@ mycompany.com» From :.

3) Подписаны ли какие-либо из ваших пользователей на внешние списки рассылки, в которых в сообщениях в списке сохраняется оригинальный адрес «От:»? Например, если Боб подписывается на «foo-list@lists.apple.com» и отправляет сообщение, он получит входящее сообщение, похожее на: From: bob@mycompany.com To: foo-list@lists.apple. com Отправитель:

Если ваш сервер наивно смотрит на заголовок «From:» (вместо «Sender:»), он может отклонить это сообщение, потому что вы получаете его извне.

Из-за всего вышеперечисленного, наличие общей политики «... от реального отправителя в нашей компании, электронная почта никогда не пришла бы извне», не всегда осуществимо.


2

Это можно сделать в PowerShell, обновив разрешения для коннектора получения, чтобы исключить отправку анонимными пользователями в качестве уполномоченного отправителя домена:

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

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


1

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

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


-1

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


«Что вам нужно, так это блокировка почтового сообщения в вашем собственном домене, на котором почтовый сервер отправителя находится в конверте, неприемлемом для вас» - это именно то, что вы делаете с SPF, создайте список законных исходящих почтовых серверов для вашего домена.
GAThrawn
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.