Задний план: Я администратор базы данных SQL Server. Я унаследовал около 50 SQL-серверов, и мне нужно настроить различные планы обслуживания и предупреждения. Чтобы получить полную выгоду, мне также нужно настроить Database Mail для отправки электронных писем при сбое задания, возникновении условий предупреждения и т. Д. Для этого требуется SMTP-сервер для ретрансляции электронной почты (надеюсь, я правильно понял формулировку). Поскольку каждый SQL Server находится в собственном домене, кажется, мне придется установить функцию SMTP и настроить ее на сервере в каждом домене. Я думаю, что сделаю это прямо на каждом хосте SQL Server.
Я выполнил пошаговые инструкции в эта статья MSDN. Там все имело смысл. После того, как я обошел пару препятствий на пути к антивирусу, я получил электронную почту.
Вопрос: Каковы последствия установки функции SMTP для безопасности? В моем доказательстве концепции я настроил SMTP, чтобы разрешить ретрансляции от 127.0.0.1 и никого другого. Считается ли это «безопасным». Есть ли другие вещи, которые я не замечаю?
Обновление 21.08.2014: Оказывается, у моей компании есть доступ к SMTP-серверу Microsoft. Мне сказали, что это платная услуга. Из этого я сделал вывод, что SMTP-сервер MS сам по себе не является открытым ретранслятором. Я подключаюсь к нему через анонимную аутентификацию, хотя я не уверен, откуда MS знает, что отправитель является одним из их платящих клиентов (возможно, IP-адрес?). Итак, в итоге у меня есть один SMTP-сервер, мне не нужно его обслуживать, и мне не нужно устанавливать и настраивать функцию SMTP на бесчисленных серверах SQL. Спасибо всем за ваш вклад.
Вот немного другой подход:
Вместо того, чтобы устанавливать экземпляр SMTP-сервера в каждой клиентской инфраструктуре, почему бы не настроить единственный экземпляр в своей инфраструктуре? Затем вы можете настроить Database Mail для каждого клиента для ретрансляции через ваш SMTP-сервер. Каждому клиенту в любом случае необходимо разрешить исходящий SMTP, так что какая разница, исходящий он с SQL Server или с SMTP-сервера?
Вы уменьшите административные издержки и потенциально уменьшите поверхность атаки, имея только один экземпляр SMTP для защиты.
Если вы потеряете клиента или они переведут свой бизнес в другое место, им легко перенастроить или отключить Database Mail. В этом случае вам также будет несложно перенастроить ваш SMTP-сервер.
Мы столкнулись с аналогичным вариантом использования, поскольку некоторые приложения не поддерживают аутентифицированный SMTP, который нам необходим для нашей основной системы электронной почты. Мы обычно рекомендуем иметь один SMTP-сервер и направлять все ваши серверы db на этот один сервер, хотя для простоты. Однако, если это невозможно, и вам действительно нужно установить его на каждом сервере db, обязательно просмотрите ограничения на количество подключений, и у вас будет несколько мест, где это можно сделать, в зависимости от вашей сети.
Начиная с виртуального SMTP-сервера, щелкните свойства сервера, а затем перейдите. Вы увидите там несколько вариантов, и вам нужно будет найти «Управление подключением» и «Ограничения реле». Установите для них IP-адреса машин, которым требуется доступ, если у вас есть только один SMTP-сервер для многих серверов db, или установите для него значение 127.0.0.1 или localhost, как вы уже сделали, чтобы ограничить только этот сервер, если он устанавливается на каждый сервер БД.
Вам также придется сделать поправки в брандмауэре Windows, которые вы можете использовать для дальнейшего ограничения доступа. В вашем случае, если вам нужно установить его на каждый сервер db, вы можете заблокировать весь входящий SMTP-трафик и разрешить только исходящий.
smtp имеет ДЛИННУЮ историю отказов безопасности (sendmail, emacs и др.). Так же MS. Честно говоря, последнее, что я когда-либо делал, это ожидал, что машина MS будет продолжать smtp безопасный. Обычно мы ставим smtp прокси между любой машиной Windows, предоставляющей почту, и Интернетом (например, FreeBSD с постфиксом, настроенным с антиспамовым антивирусным ПО и простой пересылкой).
Что, как говорится...
Если ваш smtp config является «только исходящим» (то есть: случайная машина не может открыть соединение с портами 25, 587 и / или 465), значит, вы действительно не слишком сильно открыли себя для атаки.
Наиболее вероятным режимом сбоя на любом MTA (не только в Windows) является взлом пароля. В таком случае кто-то взломал ваши сетевые порты, пытаясь угадать пару пользователь / пароль. Вы можете защититься от этого (что нелегко с Windows), отслеживая количество неудачных аутентификаций с данного IP и / или подсети и соответствующим образом изменяя брандмауэр (обычно x количество неудачных аутентификаций в течение t времени, истекающего на следующий день или около того). Вы также можете подписаться на RBL (что нелегко сделать в Windows). См.: http://en.wikipedia.org/wiki/Realtime_Blackhole_List. Вы также можете настроить брандмауэр или NMS так, чтобы они расстраивались из-за слишком большого количества исходящих SMTP-соединений (т.е. smtp был скомпрометирован, и машина превратилась в источник спама, рассылающий +100 сообщений в минуту в нечетные часы) и либо блокировал, либо предупреждал администраторов. (Также нелегко сделать с Windows.)
Обратите внимание, что если спамер угадывает пароль и превращает ваш сервер в источник спама, это просто наиболее вероятный режим отказа. Гораздо более уродливым сценарием является тот, когда вы открываете слабую пару пользователь / пароль для Интернета в целом и тем самым позволяете ребенку-скрипту извлекать выгоду из авторизации на ваших серверах. Вам нужна серьезная политика паролей. Вам нужно поставить любой такой входящий smtp в изолированной DMZ вашей сети. И вам необходимо внимательно следить за исключениями брандмауэра (например, установить snort)