У меня есть сервер SQL Server 2005, расположенный за пределами моего брандмауэра в центре обработки данных. Он полностью обновлен, содержит исправления и т. Д.
Есть старый червь MSSQL (Slammer?), Который ПО-ПРЕЖНЕМУ заражает тысячи серверов по всему миру, и они охотятся за серверами, чтобы заразить их. Когда они находят сервер, они начинают делать десятки попыток подключения, что ставит SQL Server на колени, даже если попытка заражения оказывается безуспешной.
За последние 5 лет или около того, что это происходило (в среднем примерно раз в несколько месяцев), я просто заблокировал каждый зараженный IP-адрес с помощью локальной политики безопасности.
Но это начинает стареть ...
Есть ли вариант конфигурации, дополнительное исправление, что-то что помешает ему даже слушать эти попытки подключения?
Я уже рассмотрел три решения:
Ответы на поставленные вопросы:
Если нет приемлемого решения, я буду жить со статус-кво.
Вы настроили в основном наихудший сценарий и, по-видимому, намерены его придерживаться.
Как вы уже выяснили, размещение сервера в открытом доступе из Интернета просто вызывает проблемы. Правильное решение - настроить VPN и использовать ее. Мне любопытно, почему ты этого не хочешь. Он добавляет один шаг к процессу подключения к серверу и обеспечивает высокий уровень безопасности для среды, поскольку люди не могут получить доступ к вашему SQL Server напрямую.
Хотя намного проще получить доступ к вашим серверам из общедоступного Интернета, гораздо опаснее просто избавиться от необходимости подключаться к VPN.
И кто сказал, что еще одна ошибка, подобная той, которая позволяет SQL Slammer уничтожать SQL-серверы по всей сети, больше не повторится, когда ваш SQL-сервер окажется под угрозой.
Отвечая на ваш вопрос, нет никакого способа указать SQL Server игнорировать эти запросы на соединение, поскольку они являются законными запросами на соединение.
Поскольку вы исключили наиболее вероятные «лучшие» решения в своем вопросе, я мог бы предложить одно предложение: установить на сервере брандмауэр на базе Linux и использовать какой-либо метод для регистрации этих сбоев в том месте, где fail2ban может их забрать. а затем заблокируйте их в брандмауэре. Это в основном автоматизирует процесс, который вы делаете сейчас вручную. Я не совсем уверен, как ваш SQL-сервер должен регистрировать эти сбои, чтобы fail2ban мог их поглотить.
Другой вариант - посмотреть на такие системы, как Фырканье который мог обнаружить атаку и справиться с ней.
Какая польза от сервера? Я полагаю, вы подключаетесь к нему для чего-то, управляя им или используя? Подключаются ли к нему также другие серверы и / или пользователи, где они расположены и что они с ним делают?
Как правило, никогда не помещайте серверы приложений в Интернет так незащищенными.
Как говорит Кевин, в худшем случае поставьте перед ним что-нибудь умное - например, Microsoft ISA или TMG, поскольку для начала это приложение Microsoft. Но все, что может автоматически обнаруживать и обрабатывать атаки, подойдет ...
... в противном случае - установление стандартного зашифрованного соединения определенно лучший способ. У вас должен быть двухточечный туннель между SQL Server и вашей внутренней сетью - я не понимаю, как при правильном выполнении этого можно добавить каких-либо проблем. Чтобы получить удаленный доступ в дороге, вы подключаетесь к своей сети, используя наиболее подходящий вам VPN, а затем переходите через туннель. Все платформы ОС имеют эти встроенные функции.
Если вам действительно нужно, чтобы он стоял посреди Интернета, но только вам нужно подключиться к нему, по крайней мере настройте ipsec, чтобы он принимал трафик только с определенных компьютеров в определенном домене Windows.
Вы говорите, что добавление дополнительной службы защиты от угроз увеличит ваши затраты на colo, но это не обязательно. Вы можете запустить эти службы на одном компьютере, если у него достаточно umpf, который не будет использовать дополнительное место в стойке. Вы даже можете запускать эти службы на виртуальных машинах, при этом все еще выглядя перед основной ОС с точки зрения подключающихся пользователей (и зомби) - поставьте SQL на локальный режим и пропустите порт 1433 из общедоступного интерфейса (ов). ) к детектору вторжений (be - это служба на главном хосте или в виртуальной машине) и пусть он передает соединения с основными службами по своему усмотрению.
Сколько адресов необходимость для подключения к вашему серверу и насколько они динамичны? Будет ли не ведение списка временного содержания более эффективным, чем использование только черного списка? Отмечать хорошее гораздо практичнее, чем перечислять плохое. Первый клиент подключается из двух мест с фиксированным адресом ?, разрешите эти адреса специально. Клиент 2 подключается от интернет-провайдера, который раздает динамические адреса? Разрешить им IP-пул провайдера и позволить автоматическому черному списку (fail2ban или тому подобному) попытаться поймать плохие хосты, которые также находятся в этом диапазоне.
Даже если вам нужен доступ в дороге, вам не понадобится доступ из каждый IP-адрес там. И если только вы (вы не указали размер и характер своей пользовательской базы) должны подключаться открыто, будет ли работать какое-то решение для блокировки портов? Хотя, как только вы начнете говорить в этом направлении, правильный VPN, вероятно, так же легко настроить.
Оба этих варианта, очевидно, добавляют дополнительные сложности, поэтому вам придется взвесить опасность, чтобы решить, стоит ли что-то подобное. Но, ИМО, опасность очень высока - эксплойт следующего нулевого дня может поразить вас до того, как он попадет в новости, поэтому у вас не будет никаких предупреждений, и вам просто придется полагаться на свои резервные копии и MS, очень быстро выпуская исправление - так что делаем ничего не было бы жизнеспособным решением в моей книге. Я знаю, что вы не хотите этого слышать, но я один из тех, кто скандировал бы «VPN, VPN, VPN» в такой ситуации ...
Денни прав. . . НО, если вы настроены продвигаться вперед, попробуйте настроить IPSEC и разрешить только зашифрованные соединения IPSEC по TCP / 1433.