Что можно сделать для защиты открытого SQL 2005 Server без дополнительного оборудования?

Один из дешевых приемов - переместить порт прослушивания со значения по умолчанию 1433. Клиенты могут подключаться, используя явный синтаксис порта, например tcp:74.125.19.104,12345 если порт - 12345. Это устраняет подавляющее большинство ботов, сканирующих 1433 на наличие уязвимости sa, blank. Это, конечно, не освобождает компанию от других связанных с ней обязанностей: политики надежных паролей, повторного использования паролей, отслеживания журналов на предмет подозрительных действий и т. Д.

Еще одна вещь, которую они должны учитывать, - это реализовать Прямой доступ. DA устраняет большинство, если не все недостатки старых решений VPN, и компаниям, которые боятся затрат службы поддержки на VPN, следует серьезно подумать о DA.

И наконец, очевидный вопрос Зачем нужен ли им доступ к TDS из Интернета? Зная, каковы требования, мы можем порекомендовать альтернативные, менее опасные решения.

Настройте политику IPSEC, которая разрешает подключения к портам SQL Server на основе белого списка IP-адресов / диапазонов, как упоминалось ранее. Это означает, что ОС будет нести бремя игнорирования трафика (поэтому очевидно, что предпочтение отдается сетевым устройствам). Убедитесь, что брандмауэр включен для защиты всех портов ОС, особенно тех, которые связаны с RPC, SMB и т. Д. Убедитесь, что политика IPSEC разрешает ТОЛЬКО подключение к порту SQL Server. Вам не нужно открывать порт для службы браузера SQL (udp / 1434).

Если можете, измените порт, который SQL Server прослушивает (возможно, tcp / 1433), на какой-либо другой порт (убедитесь, что политика IPSEC соответствует). Если это не известный порт, особенно если это порт более высокого уровня, это остановит большинство сканирований системы. Пользователям просто нужно знать, чтобы подключиться через сервер,порт вместо просто сервер.

(Этот общедоступный IP-адрес принадлежит Google, поэтому в редактировании, вероятно, не было необходимости)

Лучшее, что вы можете сделать для защиты SQL-сервера любой полосы, - это занести в белый список хосты, которым разрешено подключаться к нему, и убедиться, что на этом компьютере запущено как можно меньше других служб.

Еще одна хорошая практика - строго ограничить доступ с веб-стороны. Если веб-приложению разрешено запускать только несколько десятков хранимых процедур, то векторов атак со стороны взломанного веб-сайта практически не существует. С другой стороны, если он может выполнять произвольные запросы, у вас будут проблемы.

Никогда не запускайте веб-сервер на компьютере с базой данных: это огромный ненужный вектор атаки, которого следует по возможности избегать. Веб-серверы и веб-сервисы очень часто используются. Если ваша база данных подключена к тому же компьютеру, то вероятность ее отключения также выше.

Самый простой способ добиться всего этого (без добавления какого-либо нового оборудования) - включить IPSEC и туннелировать запросы от вашего веб-сервера к серверу базы данных. Вот это базовое руководство по IPSEC.

Если вам нужно разместить их на одном сервере, вы можете немного обезопасить себя, разрешив только локальные соединения, но это не поможет, если ваш веб-сайт подвергнется эксплуатации.

Чтобы отключить удаленные подключения, перейдите в Сервер-> Свойства-> Подключения и снимите флажок «Разрешить удаленные подключения к этому серверу».

Немного старый, но все же есть хорошая информация. Глава MSDN о защите сервера базы данных. http://msdn.microsoft.com/en-us/library/Aa302434

Вы также можете приобрести программный брандмауэр, например Zone Alarm или Outpost.

Я настоятельно рекомендую разорвать все связи с компанией, которая настаивает на размещении своей БД в сети без какой-либо формы IPSec, брандмауэра или частных подключений. Я надеюсь, что они хоть как-то используют шифрование.

Это серьезная проблема, которая ждет своего часа; возможно судебный процесс или преступная халатность (в зависимости от задействованных данных).