Передача запроса аутентификации SMTP на другой SMTP
У меня проблема, которая выше моего уровня компетенции. Поскольку мы работаем над улучшением мер безопасности, которые применяются в нашей сети, мы обнаружили (среди прочего) один недостаток, который мы не знаем, как исправить.
У нас есть собственный SMTP-сервер, локально основанный на MDaemon, и мы нанимаем профессиональную услугу хостинга, которая соединяет нас с глобальной сетью, и у них также есть свой собственный SMTP-ретранслятор, общедоступный. Поэтому, когда почта проходит, она приходит от их SMTP к нам, к нашим устройствам. Но мы обнаружили, что их tcp порт 587 не запрашивал аутентификацию, что означает, что мы можем подделать любой адрес, доменное имя которого они обрабатывают, отправив любое электронное письмо, например, с boss@ourcorp.com на accountants@ourcorp.com, упрощая его. для потенциального злоумышленника, чтобы сделать фишинг. Но наш поставщик услуг не может просто закрыть этот порт, потому что у нас есть кочевые пользователи, отправляющие через него почту со своего мобильного телефона. Вот варианты, о которых я думал, будучи неуверенным, насколько они осуществимы:
- Синхронизируйте свою базу данных пользователей SMTP с нашей (или сделайте ее просто своей), чтобы у них были логины / пароли для проверки подлинности и проверки подлинности, когда кто-то просто подключился по сети на MSA через порт 587,
- Не использовать их MSA и не ставить нашу публику напрямую, имея тот же практический эффект, что сводить его к одному общедоступному MSA, который имеет базу данных пользователей для проверки подлинности,
- Найдите способ передать запрос аутентификации от своего MSA нашему, сделав проверку и вернув жетон "принять" или "отклонить" своему MSA. Возможно, это был бы идеальный вариант, но я понятия не имею, как мы можем это сделать. Я знаю, что ретрансляционный запрос на аутентификацию используется для связанной цепочки ситуаций LDAP/LDAP или Active Directory/LDAP, но я не знаю, как его можно использовать практически или он работает с SMTP-AUTH,
- Найдите какое-нибудь антиспуфинговое программное обеспечение для размещения на наших серверах (но как оно будет проверяться? Почта всегда будет приходить от доверенного MSA с потенциально существующим адресом)
Если у вас есть какие-либо мысли по нашей проблеме, заранее спасибо.
1 ответ
Прежде всего, я полагаю, что порт 587 вашего интернет-провайдера защищен не так, как логин / пароль? Одним из способов является IP-адрес источника, так что он доступен только для клиентов, подключенных к этому интернет-провайдеру, но это ограничит пользователей мобильных телефонов подключением через этого интернет-провайдера. Другой способ - POP-before-SMTP, но он работает только в том случае, если интернет-провайдер также обрабатывает почтовое хранилище и, таким образом, может в любом случае аутентифицировать пользователей. Я не рекомендую ни один из этих двух способов, но единственное другое решение, которое я вижу, - это открытая ретрансляция, которую вы определенно хотите избежать, и чье существование плохо отразится на компетенции вашего интернет-провайдера.
В зависимости от MSA вашего провайдера и ваших собственных служб аутентификации, может быть возможна аутентификация через прокси. Я не рекомендовал бы это, поскольку кажется, что его довольно сложно настроить и поддерживать без каких-либо преимуществ, которые я вижу.
Я бы порекомендовал ваше второе решение: у вас уже есть почтовое хранилище, подключенное к Интернету через IMAP (я полагаю!), У вас уже есть почтовый сервер, у вас уже есть настроенный MSA, так что выставление MSA в Интернет не является огромным изменение экспозиции. Таким образом, все очень стандартно, очень просто объяснить, вы меньше зависите от своего провайдера, вы не передаете конфиденциальную информацию о логине / пароле без необходимости вашему провайдеру. Конечно, существуют проблемы с безопасностью, такие как атаки по словарю, но если я не ошибаюсь, это проблемы, с которыми вы уже сталкиваетесь, позволяя пользователям своего мобильного телефона проверять свою почту.
Вещи, которые могут заставить меня изменить свое мнение, будут
- количество пользователей (я не думаю, что мы говорим 10000+)
- невероятно низкая или дорогая пропускная способность вашего сайта (но вы уже запустили там свой почтовый сервер)
- если пользователи вашего мобильного телефона только отправляют почту, никогда не проверяйте почту из Интернета