Подделка писем. Как защищаться

[aspirineilia]

Я правильно понимаю, что никакой из описанных способов не способен защитить от описанного в статье примера?

[Boris_Uskov]

Метод 7. Создание гранулярных фильтров «вручную». В данном примере помогло бы либо сравнение mail from с заголовком From, либо, в случае в ESA, функциональность Forged Email Detection.

[apixosoft]

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

[Boris_Uskov]

del

[Saffron]

Метод 8: PGP

[teifo]

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

[TalWar]

увы, но ЭЦП вполне себе компрометируются

[teifo]

Даже если блокчейн всякий использовать?

[Anastasia_K]

т.е. вы хотите положить приватную часть ЭЦП в публичный блокчейн?

[teifo]

Извините за столь поздний ответ. В качестве просвещения, а почему её нельзя выкладывать?

[mafia8]

А если заменяют поле From?

[epicf4il]

Я конечно дико извиняюсь, но вы статью то читали?

[Botkin]

Из наиболее очевидного
From: [e-mail]
Reply-To: [e-mail]

А вообще это всё ж для созидания создавалось изначально. «Своими для своих»

[acmnu]

Вы так говорите, как если бы существовал один RFC. Я не знаю точное число RFC связанных с SMTP и форматом писем, но думаю их больше 50.

А Reply-To это часто используемый заголовок. Например для групповых рассылок.

[Dima4ka]

Можно подробнее про то, от чего шаги 4-6 не защищают?
Если наивно предположить, что получатель внимательно следит за «cousin domain», то подделать можно?
И что на счет цифровой подписи письма?

[Boris_Uskov]

Вот как раз, если отбросить «cousin domain» и «free mail account», то мы вполне хорошо могли бы защититься с помощью SPF, DKIM, DMARC. Но проблема в том, что далеко не все это используют. В комментарии ниже очень верно подметили про ключевого партнёра с кривыми записями в SPF.

То же самое касается цифровой подписи PGP. Многие ли готовы её внедрять?

Именно поэтому я выделил в статье отдельный метод — создание гранулярных правил «вручную».

[yaka]

Все это хорошо до тех пор, пока не появляются интересные факты:
2. Корректные записи DNS. Злоумышленнику это сделать не сложно. Мы прямо сейчас получаем огромное количество спама от разных доменов .eu, причем все домены имеют совершенно корректно настроенный Postfix (не является open relay), совершенно корректные записи DNS (и MX и PTR) и не имеют сайта. Как бороться — непонятно. Пока помогает лишь массовая блокировка по подсетям датацентров с рассадниками.
4. SPF работает неплохо до тех пор, пока ключевой партнер (фирма в 100-1000 раз большая по размеру) не делает кривые настройки у себя, а потом присылает письмо «У вас слишком суровые правила фильтрации, отключите их».

Кстати, а кто-нибудь знает, в каком именно стандарте (RFC, например) описано, какие должны быть соотношения между A/MX/PTR/HELO для того, чтобы сервер считался корректно настроенным?

[TalWar]

Я бы предложил против такой подмены предупреждение в почтовом клиенте о том, что поля «From: » и «Reply-To:» не совпадают.
Либо на стороне почтового сервера при приеме модифицировать текст письма и вставлять эту информацию первой строкой.

[Boris_Uskov]

Согласен. Я рассматривал вариант сравнения mail from и заголовка From, безусловно, можно доработать и также сравнивать с Reply-To.

[comargo]

А можно пояснить вот этот момент из пункта про DKIM:

Но что если данные MTA окажутся скомпрометированными, и злоумышленник также получит возможность отправлять поддельные письма через эти серверы? Как установить подлинность отправителя в этом случае? На помощь приходит аутентификация писем.

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

А Сервер-отправитель (то есть поле smtp server в настройке моего почтового клиента) и MTA это разве не одно и тоже лицо?

[Boris_Uskov]

Да, одно и то же. Но часто бывает так: у вас есть свой сервер отправитель, тот же MS Exchange, который прописан в настройках почтового клиента. Но у него в настройках прописано слать все письма во вне через провайдерские релеи или какие-либо другие внешние почтовые релеи (в send connector настройка smart host, если не ошибаюсь). А уже провайдерские релеи отправляют письма дальше в Интернет. И именно IP-адреса или A-записи провайдерских серверов фигурируют в SPF. Если эти провайдерские MTA оказываются скомпрометированными, злоумышленник также получает возможность слать через них поддельные письма, а SPF-проверка на стороне получателя будет проходить успешно.

В этом случае, если ваш exchange будет формировать DKIM-отпечаток до отправки писем на провайдерские релеи, получатель сможет отличить ваше письмо от письма злоумышленника.

[Boris_Uskov]

Слать письма во вне через дополнительный хоп можно по разным причинам. Например, внешние релеи предоставляют услугу DLP.

[EllaVS]

А что делать, если From и Reply-To совпадают?
Например, сейчас на корпоративную почту идет спам от Сбербанка со ссылками на вредоносные файлы.
При этом:
From: [e-mail]
Reply-To: [e-mail]
Или
From: [e-mail]
Reply-To: [e-mail]
И другие вариации пользователей с доменом sberbank.ru. А также nalog.ru.
Блокировать весь домен? Но ведь в бухгалтерию нормальные письма от Сбербанка и налоговой должны доходить.

[Boris_Uskov]

SPF и DKIM не помогают?
Потом, никто не отменяет проверку тела письма. Это уже офтоп относительно материала статьи, но всё же… Например, у ESA есть возможность проверять ссылки в письме. URL проверяются по тем же базам, что и на web-proxy сервере WSA. Если URL ведёт на вредоносный сайт, можно карантинить такие письма, добавлять предупреждение в заголовок письма (если не ошибаюсь) или «портить»/вырезать URL из тела письма.

[bgelov]

О, помню спам того времени с маской *[e-mail], ещё нескольких банков и да, nalog.ru.
Искоренил не красиво, но эффективно, работая с *.s@ для всех затронутых доменов. У нормальных отправителей не встречалось такое именование.