Гарна ідея? Відмовитись від вхідних листів із закінченням власного домену? (тому що вони повинні бути підробленими)

33

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

Як зовнішня електронна пошта від fake@example.com?

Тому що якщо це буде від справжнього відправника нашої компанії, електронний лист ніколи не надходитиме ззовні?

Якщо так, то який найкращий спосіб зробити це?

security email-server exchange-2013

— Steffen Maier
джерело

3

Чи є у вас якісь рішення щодо фільтрації спаму?

— ewwhite

14

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

— Тодд Вількокс

6

@NeilMcGuigan Що б це мало? Пошта все ж має походити з внутрішнього поштового сервера? Це було б не з-за меж мережі лише тому, що він фізично не присутній.

— Метт

@Matt gotya, brainfart

— Ніл

1

Якщо у вас є автоматизовані сповіщення електронною поштою, що надходять з одного з ваших серверів, наприклад, повідомлення про невдалі завдання щодо роботи з Cron, або спроба порушення з боку IDS або монітора використання ресурсів, і вони налаштовані так, що їх адреса з вашим доменним іменем. Вам потрібно буде подбати про те, щоб перенести ці електронні листи через внутрішній поштовий сервер, або додати в білий список цих серверів як дозволених відправників.

— Лежи Райан

53

Так, якщо ви знаєте, що електронна пошта для вашого домену надходить лише з вашого власного сервера, тоді вам слід заблокувати будь-яку електронну пошту для цього домену, що надходить з іншого сервера. Навіть якщо клієнт електронної пошти відправника знаходиться на іншому хості, він повинен увійти на ваш сервер (або будь-який сервер електронної пошти, який ви використовуєте) для надсилання електронної пошти.

Зробивши цей крок далі, ви можете налаштувати свій сервер для перевірки записів SPF. Ось скільки хостів запобігає такій діяльності електронної пошти. SPF-записи - це запис DNS, запис TXT, який дає правила про те, яким серверам дозволено надсилати електронну пошту для вашого домену. Як увімкнути перевірку записів SPF залежатиме від вашої служби електронної пошти та не виходить за межі того, що тут потрібно охопити. На щастя, більшість хостинг-середовищ та програмного забезпечення матиме документацію для роботи зі записами SPF. Можливо, ви хочете дізнатися більше про SPF загалом. Ось стаття у Вікіпедії: https://en.wikipedia.org/wiki/Sender_Policy_Framework

— Дкінг
джерело

3

@Kurtovic добре налаштований сервер електронної пошти повинен відмовитись від електронної пошти, яку він відхиляє, тому відправника буде повідомлено.

— Калімо

8

@Calimo Не коли він відхиляє електронну пошту за те, що вона була спамом. Це просто дозволить спамеру продовжувати намагатися, поки він не дізнається, що дозволяє ваш алгоритм і не дозволяє.

— Джон Бентлі

27

@Calimo - ні. Прийняти і відмов - це найгірше, що можна зробити, ти сприяєш розповсюдженню спаму і дуже швидко потрапить у чорний список. просто відкиньте небажану пошту - вирішення цього питання - проблема хоста- відправки . Якщо ви не можете цього зробити, прийміть, перевіряйте та відмовляйтесь від спаму чи зловмисного програмного забезпечення. ніколи не приймай і не відскакуй.

— cas

2

@cas: Є третя альтернатива: відхилити під час прийому SMTP. Це залишає тягар створення відповіді на помилку на сервері SMTP, що відправляє, якщо він цього хоче, і тим самим дозволяє багатьом законним відправляючим перевіряти, чи не було відхилено їх пошту, гарантуючи, що ви ніколи не видаватимете спам самостійно.

— Р ..

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) Чи використовує хто-небудь у вашій компанії будь-який зовнішній сервіс (наприклад, опитування мавпи, постійний контакт тощо), щоб надсилати електронні листи, які, здається, "з" вашого домену? Навіть якщо вони цього не роблять сьогодні, чи можуть це зробити в майбутньому?

2) Чи є зовнішні адреси, які пересилають вашим користувачам? Наприклад, припустіть акаунт gmail "mycompany.sales@gmail.com" пересилає на "sales@mycompany.com", а ваш користувач "bob@mycompany.com" надсилає на "mycompany.sales@gmail.com". У такому випадку повідомлення надійде з "зовні", але з адресою "@ mycompany.com" з:.

3) Чи хтось із ваших користувачів підписався на зовнішні списки розповсюдження, які зберігають оригінальну адресу "Від:" у повідомленнях до списку? Наприклад, якщо Боб підписався на "foo-list@lists.apple.com" і надішле повідомлення, він отримає вхідне повідомлення, яке виглядає приблизно так: Від: bob@mycompany.com До: foo-list@lists.apple. com Відправник:

Якщо ваш сервер наївно дивиться на заголовок "Від:" (замість "Відправник:"), він може відхилити це повідомлення, оскільки ви отримуєте його ззовні.

Зважаючи на все вищесказане, мати політику, яка не відповідає "... від реального відправника в нашій компанії, електронний лист ніколи не надходитиме ззовні", не завжди можливо.

— Девід Гелхар
джерело

2

Це можна зробити в PowerShell, оновивши дозволи отримання Connector для того, щоб анонімні користувачі не могли надсилати повідомлення як авторитетний відправник домену:

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

Однак проблема виникає, коли у вас є віддалені сервери додатків, яким потрібно надсилати вам електронні листи про стан, оскільки вони, як правило, використовують ваше доменне ім’я у своїй адресі From. Можна створити додатковий роз'єм прийому для їх конкретних IP-адрес, щоб ви їх випадково не виключали.

— Ніл
джерело

1

GMail має налаштування, де воно дозволяє надсилати електронні листи з доменом, який не належить до GMail, за умови першої перевірки адреси електронної пошти. Ваше рішення заблокує ці електронні листи.

Від того, чи є у вас користувачі, які могли б використовувати цю функцію GMail і чи є сенс їх обслуговувати, дуже залежить від поведінки вашої компанії.

— Християнин
джерело

-1

SPF не зможе вилікувати це, оскільки конверт цілком може мати належний пропуск SPF (тобто спамерів, що використовують компрометований сервер), тоді як вони будуть підробляти електронну пошту всередині конверта. Вам потрібно блокувати на своєму власному домені повідомлення електронної пошти, яке має вихідний сервер електронної пошти на конверті, неприйнятному для вас.

— Джим
джерело

"Вам потрібно блокувати на власному домені повідомлення електронної пошти, яке має вихідний сервер електронної пошти на неприйнятному для вас конверті" - саме так ви робите з SPF. Створіть список законних серверів електронної пошти для вашого домену.

— GAThrawn