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