При настройке сервера исходящей почты на почтовом клиенте вы видите 3 опции для шифрования — без шифрования, SMTPS и STARTTLS, а также 3 возможных порта — 25, 465, 587. Что тут выбрать и для чего — давайте разбираться.
Видео
Previous < Режимы работы почтовых серверов
Next > DNS записи для почтовых серверов
Когда вы отправляете кому-то сообщение, ваш почтовый клиент использует протокол ESMTP для передачи этого сообщения, а затем ваш почтовый сервер использует тот же протокол, если ему нужно передать это сообщение на другой сервер. И хотя все говорят и пишут SMTP, речь обычно идёт про ESMTP – тот же самый SMTP, но с набором расширений, таких как авторизация и шифрование. Да, когда-то SMTP не поддерживал даже авторизацию.
Теперь немного про SMTPS. Когда-то интернет был настолько простым, что всё в нем передавалось в открытом виде. Потом появились криптографические протоколы шифрования, тот же самый SSL. И сервисы, которые раньше передавали информацию в открытом виде, начали заворачивать трафик в SSL.
Но сделать это на тех же стандартных портах оказалось непросто – клиент и сервер должны договориться о методе шифрования, а чтобы сервис на одном порту одновременно работал для одних с шифрованием, а для других без – требовало бы изменений в протоколах. И чтобы не усложнять всё, начали лепить отдельные порты для шифрованных соединений – так появился 443 для HTTPS и 465 для SMTPS. Но тут спохватились – выделенных портов мало, количество сервисов растёт, а если еще каждый для своих целей будет использовать по несколько портов с шифрованием и без – беда.
И в итоге решили немного доработать протоколы. В некоторых случаях это не очень получилось, например для HTTP, а в случае с SMTP получился вполне себе годный вариант. Для этого в SMTP добавили расширение STARTTLS. Вообще, расширение STARTTLS используется не только для SMTP, в целом это команда для начала переговоров о шифровании. В отличие от SMTPS, который использует выделенный порт 465 и сразу шифрует соединение, STARTTLS лишь расширение для SMTP, а значит сессия инициируется как обычная SMTP сессия. Почтовые сервера приветствуют друг друга, а потом предлагают начать шифроваться и выбирают доступные криптографические протоколы.
В итоге с появлением STARTTLS из стандартов решили убрать SMTPS на 465 порту как отдельный сервис. Из стандартов убрали, но сервис остался, и до сих пор используется. Насчёт шифрования я еще сделаю отдельную тему, а пока поговорим про STARTTLS.
Ранее я сказал, что при STARTTLS почтовые сервера или клиент/сервер открывают соединение без шифрования, а потом договариваются о шифровании. Для шифрования они используют тот же самый SSL/TLS. Но что, если они не смогут договориться? Получится, они будут общаться в незашифрованном виде? По интернету? А между тем, договариваются они без какого-либо шифрования, тем самым легко обмануть сервер или клиент отсутствием доступных методов шифрования. И в своё время уличили одного из провайдеров в такой атаке. И нафиг тогда такое шифрование нужно, спросите вы. Не всё так безнадёжно. На самом деле, администратор может отключить возможность передачи почты, если не удалось договориться о шифровании, а почтовые клиенты обязаны предупреждать о том, что сервер не поддерживает шифрования.
И так, мы разобрались с тем, что есть SMTP, который работает по 25 порту, есть SMTPS, который работает по 465, но есть еще один порт – 587, который также используется почтовым сервером.
Как вы заметили, почтовые клиенты подключаются к серверам по SMTP. И почтовые сервера подключаются друг к другу тоже по SMTP. Также я говорил в прошлой части, что есть такие сервера – релей хосты, которые пересылают почту. По определённым причинам, в основном человеческим, в интернете есть релей хосты, которые позволяют неавторизованным пользователям перенаправлять сообщения с любого адреса. И эти хосты появляются каждый раз, когда нерадивый админ поднимает почтовый сервер, а это бывает нередко. Как итог, злоумышленники поднимают временные сервера или заражают компьютеры пользователей, которые рассылают спам через эти релей хосты без авторизации.
Как итог, некоторые интернет провайдеры блокируют любые подключения пользователей к 25 порту.
Между серверами в интернете этот порт открыт, а вот для пользователей сделали отдельный сервис – MSA (message submission agent – агент отправки почты), тем самым отделив подключения пользователей от подключения серверов, которые общаются по прежнему по MTA. Вообще, даже на 25 порту работает MSA, но официальный порт для него – 587. Так что мешает спамерам использовать этот порт? То что на MSA, как правило, обязательна авторизация пользователей. Это не единственная причина существования MSA – так как он работает с почтовыми клиентами, он лучше оптимизирован под работу клиентов – сразу предупреждает о каких-либо ошибках в сообщениях, например, отсутствии доменного адреса получателя.
И напоследок, давайте проследим за процессом отправки почтового сообщения. Для этого используем wireshark, почтовый клиент и gmail аккаунт. Всё начинается со стандартного TCP хэндшейка, после чего запускается SMTP сессия. В рамках сессии почтовый клиент и сервер приветствуют друг друга, после чего почтовый клиент предлагает зашифровать сессию, сервер даёт согласие, после чего происходит обмен ключами и начинается зашифрованная сессия TLSv1.3, после чего в зашифрованном виде клиент авторизуется и передаёт сообщение, которое не видно для перехватчика трафика.
Chai_Nik
Полезная статья, спасибо. Расскажите, пожалуйста, поподробнее, если можно, про протокол обмена между серверами. Стандартный порт для подключения 25, а можно ли его сменить, например, на 2525, будет ли при этом установлено соединение между сервером, сменившим этот порт, и сервером назначения, будет ли выполняться отправка и получение почты, или эта настройка только для почтовых клиентов? Даже в англоязычной Вики описывается процесс общения по smtp только между клиентом и сервером. В этой части у меня большой пробел.
Спасибо.
datt Автор
Добрый день. К сожалению, смена стандартного 25 порта на что-то другое для входящей почты повлечёт проблемы, так как другие почтовые сервера не узнают об этом. Это можно сделать на relay хосте, и на вашем почтовом сервере указать порт для релей хоста, но это вроде не то, что вам нужно. Другой способ добиться этого — port forwarding. Честно говоря, не сталкивался с необходимостью сменить порт на почтовых серверах, но если вы объясните проблему, возможно, смогу подсказать решение.
Chai_Nik
Да обсуждаем сейчас проблему очередей в маршрутизаторе, в итоге не отправляется и не доставляется почта. Нужно быстрое решение, а релей ещё надо развернуть, и поможет ли это в данном случае? Встречаются инструкции по смене порта, например, здесь wiki.zimbra.com/wiki/Adding_additional_SMTP_listener_ports
Возникает вопрос — в каких случаях это делается?
Если инициатором соединения является сервер, у которого сменен порт, сервер назначения сможет установить его по smtp-протоколу и отправить почтовое сообщение, если сервер-отправитель указал свой нестандартный порт?
Ещё часто можно встретить упоминания, что порт 25 является «устаревшим», по отношению к чему он «устарел»? И что делать, если провайдер блокирует порт 25/tcp, опять-таки обычно на исходящие или входящие?
datt Автор
Я не совсем понял, как почта связана с вашими очередями на маршрутизаторе…
Нет, релей вряд ли будет выходом. Смена listener как правило нужна на релей хостах, чтобы избавиться от спам ботов, которые стучатся на 25, или при каких-нибудь сложных установках.
Исходящий порт на одном сервере никак не влияет на входящий на другом. Сессия установится нормально и сообщение передастся, но другие сервера не смогут обращаться к вашему серверу.
Устаревшим он является скорее всего в качестве MSA, так как провайдеры блокируют подключения по 25 порту.
Как решение, если вы считаете, что необходима смена порта, вы можете поднять простенький port-forwarding, хост, который будет слушать на 25 порту и форвардить это на ваш сервер. И на почтовом сервере вы можете добавить listener или тоже настроить port forwarding, чтобы всё приходило на стандартный порт. Это просто предположение, без проверки утверждать работу схемы не могу
Chai_Nik
Спасибо.
Я так понял, что очереди возникают из-за превышения возможностей роутера вследствие атак на почтовый сервер с множества адресов в целях вызвать отказ в обслуживании. Маршрутизатор и форвардит запросы на почтовый сервер, ведь почтовый не сам смотрит прямо в интернет.
А провайдеры типично блокируют именно входящий трафик на порт 25?
И что значит «эти хосты /релеи/ появляются каждый раз, когда нерадивый админ поднимает почтовый сервер»? Админы не хотят отправлять почту непосредственно от своего mta, а вместо этого специально заводят сервер-посредник? Зачем?
datt Автор
В случае с вашим маршрутизатором, если это не DDOS атака, могу посоветовать вот такую штуку — www.blocklist.de/en/export.html. Тут в txt формате адреса всяких спамеров, если они создают вам проблему — то можно прикрутить это к Edge фаерволу и избавиться от спамеров. Только нужно быть осторожным, ведь в списке можете оказаться вы или ваши партнёры.
Провайдеры обычно блокируют исходящий трафик по 25 порту. Потому что немало компьютеров под ботнетом, по щелчку хакера они начинают рассылать спам на 25 порт релей серверов. Чтобы избавиться от этого спама, провайдеры и блокируют исходящий трафик на 25 порт.
>> И что значит «эти хосты /релеи/ появляются каждый раз, когда нерадивый админ поднимает почтовый сервер»?
В настройках почтового сервера есть опция с доверенными адресами, для кого данный сервер может выступать в роли релея. Им для отправки почты не нужно авторизовываться на этом сервере, а отправлять они могут на любой адрес. Так вот, если админ по незнанию там напишет 0.0.0.0/0, то очень скоро этим сервером начнут пользоваться для рассылки спама.
>> Админы не хотят отправлять почту непосредственно от своего mta, а вместо этого специально заводят сервер-посредник? Зачем?
В основном, чтоб не попадать в спам. Ты платишь денюшку провайдеру, а он заботится о том, чтобы его сервера не попадали в спам. Потому что самому следить за этим бывает не просто — то через аккаунт Васи Пупкина с паролем Password2020 начнут рассылать спам, то Марь Иванна решит всех коллег всех партнёров поздравить с 8 марта, то еще какая-нибудь фигня. Из некоторых спам листов легко выйти, а из некоторых нереально сложно. А провайдеры всякие бонусы дают, например, возможность делать рассылки. Потому что для некоторых полноценная настройка почтового сервера — это тот еще гемор, особенно когда нужно на этажах картриджи поменять и комп Марь Иванны пропылесосить.
Еще слышал, что некоторые прячут свои Exchange сервера за каким-нибудь Exim. То ли для безопасности, то ли от Майкрософта. Не знаю
Chai_Nik
Релей поможет для отправки почты, а для приема почты от ddos ничего не поможет, разве что кроме замены оборудования на более мощное и применения балансиров? Потому что у всех контрагентов предприятия, известных или потенциальных, есть адрес, указанный на корпоративном сайте. Зловреды потом отстанут, и придется снова своих клиентов как то уведомлять.
И я не понял, на релее нужно для каждой учётной записи корпоративного почтового сервера тоже создавать учётки?
Ещё Вы пишете об «авторизации на сервере», это правильный в данном случае термин, или все же речь идёт об аутентификации?
datt Автор
Просто меня удивляет, что почтовый сервер могут DDOS-ить. Хотя знаете, вспомнил одну ситуацию. У клиента стоял керио коннект. И на нём была включена опция ограничения сообщений от одного адреса. А на роутере стоял нат на входящие пакеты, из-за чего при активности спама керио блокировал адрес роутера, из-за чего почта вообще отваливалась. Решалось отключением ната на входящие подключения.
Да, извиняюсь, аутентификация.
maledog
А почему нет? открываем сколько можем соединений и пробуем подобрать пароли к какому нибудь из ящиков, особенно если разрешено отправлять почту снаружи. Получили пароль ящика. Рассылаем спам внутренним пользователям. Правила для внутренних рассылок обычно слабее и доверия к ним больше. Плюс на почту могут пароли восстанавливать иногда даже в открытом виде.
datt Автор
Ну это скорее DOS, а не DDOS
Хотя даже DOS с натяжкой…
maledog
А из начальных условий не ясно была ли цель в вывести из строя сервер или просто «перестарались».
Chai_Nik
Мне это кажется невероятным. Все известные мне серверы обеспечивают достаточно надёжную политику — политику сложности пароля, защита от подбора пароля и т.п. А ещё надо угадать и «логин»! В случае трёх неудачных попыток аутентификации учётная запись блокируется или на определенный срок, или до вмешательства администратора. Другое дело, если используют уязвимости в самом сервисе.
datt Автор
Ха. Я в одной крупной организации видел, как у одного важного начальника пароль в домене был 123456.
Знаю организацию, где у всех пользователей практически одинаковые пароли, что-то типа Сентябрь2019 и т.п.
Chai_Nik
А что за сервер был? И в домене была отключена политика сложности пароля? Хотя да, конкретно для важняка можно её и отключить, он же нервничает и его все время забывает!)
datt Автор
AD + Exchange
maledog
Мы говорим об авторизации на почтовом сервере, а не в домене. Не все почтовые серверы привязаны к AD/LDAP. Даже если привязаны есть служебные записи, например для скриптов. И нигде я не встречал механизма блокировки учетных записей в LDAP. Но если бы и были, то сама по себе блокировка учетных записей могла бы устроить вам DOS притом похуже чем самостоятельно. Например, умышленно вводим неправильный пароль бухгалтера(ведь email обычно известен всем и как правило связан с авторизацией) и блокируем либо учетную запись в домене, либо только на почтовом сервере, что тоже неплохо. Потому при неудачных авторизациях почтовые серверы обычно банят подбирающего, а не учетку к которой подбирают пароль.
Chai_Nik
Зимбра (постфикс) в таких случаях с настройками по-умолчанию блокирует учётную запись. А ещё она любит выдавать «ошибку сети», которая на самом деле репрезентует попадание адреса источника в блэклист, откуда его вытаскивают прописью в белом списке.
maledog
Ну так это и есть бан атакующего. Вобще в нормальных организациях, чтобы этого избежать дают сотрудникам работающим извне VPN-доступ к почте и банят всех кто пытается авторизоваться не из внутренней сети либо VPN-сети.
Серверы не авторизуются, а для проверки серверов существуют другие механизмы.
Chai_Nik
В бан учетку бедного пользуна, забывшего в понедельник свой пароль, она отправляет надёжно, а вот адрес компьютера редко. У нас целые филиалы так иногда попадают, да, это неудобно, но зато можно зимбре довериться. (тьфу-тьфу, чтоб не сглазить). :)
maledog
Что-то я совсем нить потерял. Она же банит учетную запись на почтовом сервере, а не в AD?
Chai_Nik
Да, наша зимбра с АД не интегрирована никак.
maledog
И почему в таком случае пароль на почту меняется? Пользователь его регулярно в почтовом клиенте обновлять должен? Или мы говорим об интерфейсе для совместной работы?
Chai_Nik
У зимбры недопиленный клиент, он не подгружает контакты, приходится пользоваться веб-клиентом. Не знаю по какой причине он в браузере запрашивается в каждом случае, но по крайней мере в случае, когда пароль меняется по требованиям политики раз в три месяца. Пароль сменили, а на какой — не помнят. Чего то набирают, раз, два, три — звонок о помощи, в админке — блокировка.
maledog
М-да. Ну это проблема «политики», а не зимбры и smtp. Мне кажется если введут аутентификацию по usb-токенам, то некоторые и их будут менять раз в три месяца.
datt Автор
Нужно избавиться от пользователей — тогда заживём =)
Chai_Nik
Так политика-то такая у зимбры по-умолчанию. Год назад работал в банке, там пин-код на токен менялся вообще каждый месяц, токен предназначался для авторизации в домене. Тоже бегали разблокировали вместе с безопасницей). А политика по-умолчанию в АД — менять пароль каждые 60 (?) дней.
maledog
Тогда да. Косяк разработчиков. Следовало бы разделить пароли на вход в web-интерфейс и по smtp, либо оставить постоянными, но препятствовать подбору. Yandex и Google же не заставляют вас менять пароль кождый месяц — это глупо.
Все-таки пинкод к токену проще запомнить чем сложный пароль.
Во времена Win 2003 при установке AD по-умолчанию было 7 дней/сложный/не повторять 24 предыдущих.
maledog
Релей в комлекте с фаерволом поможет не тратить ресурсы на обслуживание соединений от атакующих. Если вас атакует не ботнет, то этого достаточно, иначе вы должны перейти дорогу кому-то очень богатому, способному купить ботнет.
maledog
Как показывает практика большинство таких провайдеров перманентно в спам-листах. Потому если не хотите улететь туда с кем-то за компанию, то лучше поднимать сервер самостоятельно.
Скорее затем, что Exchange сам по себе не «легкий» сервер, плюс полноценные возможности по фильтрации спама в нем требуют еще кучи денег за лицензии и аппаратных ресурсов. Потому и ставится перед ним легкий сервер, который проверит сервер отправителя на «вшивость»(PTR, SPF, DKIM, DMARK, наличие отправителя) и разными способами надолго отобьет желание слать спам(firewall, черные и серые списки). Плюс обычно в его задачи входит так же проверка и фильтрация содержимого писем(для того чтобы не пропустить спам с доверенных серверов и не допустить или хотя бы зафиксировать попытки слить конфеденциальную информацию), и также например бэкап всех входящих и исходящих.
datt Автор
Могу ошибаться, но разве те, кто покупает Exchange, не используют какую-нибудь проприетарную систему для фильтрации? Сдался им Exim для этого?
Хотя как edge, возможно, сойдёт, чтоб отсеивать совсем банальщину.
maledog
Не у всех кто «покупает» Exchange есть деньги еще и на все это. Особенно если организация не крупная.