Pull to refresh

Comments 9

Много интересных ссылок, спасибо за качественно подобранный материал. Совсем не давно был опубликован материал на аналогичную тему (https://habr.com/ru/post/647579/). Механизмы SPF, DKIM и DMARC при корректной настройке почтового сервера не пропустят relay атаку и аналогичные. И самое главное, что они работают на стороне серверов, а не клиентов. Подписывать письма на клиентской стороне — классная идея, реализовать ее можно многими способами, если в этом есть необходимость.

Было бы интересно посмотреть на практике, как проходит спам/фрод атака на тестовый почтовый сервер, чтобы детальнее понимать механизмы защиты и возможности их обхода.

Ну вам же написали:

Как видим, существующие методы SPF, DKIM и DMARC можно обойти и подделать письмо

Видимо они думают, что всю эту информацию они предоставили тут в заметке...

Скажем так: о каком обходе gmail dmarc может идти речь когда у gmail чёрным по белому написано:

_dmarc.gmail.com.       600     IN      TXT     "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"

И такое у многих freemail. Просто реклама smime. Я с таким же приколом могу дать ссылку на efail: https://efail.de и сказать что smime это тлен и он не работает от слова совсем, но это будет точно такая же не правда как и та что написана в статье, ибо у всего есть свои кондишены, есть свои недостатки, и просто делать такие вбросы ради рекламы, ну фу...

P.s. не иметь шифрования между клиентом и почтовиком, это куда более страшный кейс чем не иметь smime без которого все живут на ура и наличие smime не каким боком не защитит вашу авторизацию к серверу без шифрования, просто вброс. Настраивайте client => ssl => mta => ssl => mta и будет вам счастье. Увы да, протокол smtp не может никак гарантировать как другой клиент с обратной стороны подключиться к своему mta, но это уже не на вашей совести. Добиться mandatory client => ssl => mta очень просто настройками вашего почтового сервера. Добиться входящего mta => ssl => mta тоже не так уж и сложно с помощью dane/mta-sts или обоих вместе взятых. Dane поддерживают почти все уважающие себя mta, в отличие от mta-sts, минус только в том что для некоторых dnssec непостижимо сложен или TLD тормозит с внедрением. В случаях когда TLD тормозит внедрение dnssec можно хотя бы сам MX повесить на нормальный TLD с dnssec, этого уже будет достаточно для того чтобы заставить отправителей не падать в plaintext. Добиться исходящего mta => ssl => mta можно с помощью политик, и написать их для всех заведомо частых dst.

 Gmail-аккаунтов высокопоставленных чиновников

Это не соединяемо от слова совершенно.

А может такой замечательный тренд, что у «высокопоставленных чиновников» нет свой государственой ИБ, что они позволяют себе гуано-ящики с тотальной индексацией содержимого использовать?

SPF, DKIM и DMARC — созданы для идентификации сервера отправителя, а не для защиты письма конкретного отправителя.

Раз вы вспомнили про S/MIME, то наверное стоит вспомнить и про PGP/GPG, которые и сейчас очень часто используют. Главное не забыть сказать, что тема письма не шифруется при шифровании самого тела письма.

А может такой замечательный тренд, что у «высокопоставленных чиновников» нет свой государственой ИБ, что они позволяют себе гуано-ящики с тотальной индексацией содержимого использовать?

высокопоставленными чиновниками не рождаются.
когда человек приходит на какую-то высокую должность, то у IT/безопасников может не хватить веса убедить его отказаться от использования привычного ему личного ящика для рабочих переписок тоже.

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

По поводу PGP читал статью, что он не стал популярным из-за сложности поддержки инфраструктуры верифицированных открытых ключей. А именно, если отправить неподписанное письмо с текстом: "Я потерял старый ключ, вот мой новый: ...", то неквалифицированному пользователю будет сложно разобраться, как верифицировать этот ключ (и что его в принципе надо верифицировать). В рамках TLS эта проблема решена через поддержку централизованных хранилищ доверенных открытых ключей, и это с оговорками, но работает, а вот с PGP всё уже не так просто.

Если S/MIME для всех важен и полезен(как TLS) то почему с S/MIME не сделают аналог let's encrypt?
Автоматизированное получение и обновление сертификатов бесплатное которое можно встраивать в почтовые клиенты чтобы была кнопка "получить сертификат S/MIME"?
Или денег хочется всем? Я вот знаю один более менее нормальный способ получить бесплатный сертификат S/MIME (через Actalis)
Почему нет возможности пусть за деньги но на внятных условиях простому продвинутому пользоватлю/мелкой фирме получить возможность S/MIME сертификаты для своего домена?
Денег хочется да — у GlobalSign сертификат на физика с проверкой только почты стоит дороже DV-сертификата домена. Ну точнее заявляют что продают а реально — идите туда не знаю куда (и при этом я под впн)

Sign up to leave a comment.