Как остановить странных пользователей от попытки подключиться к моей базе данных SQL сервера? - PullRequest
2 голосов
/ 20 марта 2009

У меня есть веб-сайт asp.net на сервере и база данных MS SQL 2005 на другом сервере, последние несколько дней веб-сайт показывает мне это сообщение об ошибке: «При установке соединения с SQL Server произошла ошибка, связанная с сетью или экземпляром. Сервер не был найден или не был доступен. Убедитесь, что имя экземпляра указано правильно и что SQL Server настроен для разрешения удаленных подключений. (Поставщик: Поставщик именованных каналов, ошибка: 40 - Не удалось открыть соединение с SQL Server) "

Когда я открыл сервер БД, я обнаружил, что в окне просмотра событий я обнаружил, что существует много неудачных попыток входа на сервер sql со странных IP-адресов, которые не являются нашими, я думаю, что они пытаются взломать БД, Обратите внимание, что db - аутентификация окна.

Мой вопрос, как это остановить?

Ответы [ 4 ]

9 голосов
/ 20 марта 2009

Лучшее, что вы можете сделать, это запретить доступ к порту SQL вашего сервера на брандмауэре. Запрос никогда не дойдет до вашего сервера, и вам будет хорошо. Вы, вероятно, хотите отрицать 1433 и 1444.

3 голосов
/ 23 марта 2009

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

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

2 голосов
/ 20 марта 2009

Ограничьте IP-адреса или разрешите только некоторые Mac, поищите хороший брандмауэр, который может предоставить вам эту функциональность

1 голос
/ 23 марта 2009

Звучит как компромисс или кто-то, по крайней мере, «возится» с уровнем Web / Apps или базой данных. Последнее проявляется, если вы открыли экземпляр базы данных непосредственно в Интернете - я искренне надеюсь, что вы этого не сделали. Если да (оставьте комментарий, и я свяжусь с вами в автономном режиме) ..... появляется сообщение о том, что кто-то инициировал множественные запросы на подключение к учетным записям прямого перебора. Если у вас есть политика паролей, которая реализует блокировку, то они, скорее всего, ее выбили. Учетные записи SQL? Хм, если бы я был, я бы попробовал "са" для начала. Разве это не веб-экземпляр, который не может найти базу данных?

Ознакомьтесь с принципами с сайта Чипа Эндрюса http://sqlsecurity.com. Кроме того, заблокированы ли IIS Config и соответствующая операционная система Windows?

Следующие шаги .....

Как ваше ASP-приложение / веб-уровень подключается к SQL-интерфейсу? Через хранимые процедуры или SQL на лету? В любом случае все еще существует возможность неправильного использования.

Например, начиная с SQL2005, более интересные хранимые процедуры, такие как xp_cmdshell, отключаются. Если вы не удалили dll из системы, вы все равно можете включить их, т.е.

exec sp_configure 'Показать дополнительные параметры', 1 exec sp_configureconfigure exec sp_configure 'показать дополнительные параметры', 1 exec sp_configure 'xp_cmdshell', 1 exec sp_configureconfigure

А если у вас есть SQL на лету, посмотрите методы проверки ввода, рекомендуемые на этом сайте.

Есть ли какие-либо области загрузки, предоставляемые сайтом?

Если вы внедрили встроенную аутентификацию Windows, если кто-то подключился к вашему серверу SQL через интерфейс, косвенно представленный через Web / App, он может затем настроить себя в качестве администратора домена и владеть всем имуществом Windows.

Приветствия. Кстати, по IP-фронту ..... К вашему сведению http://www.ripe.net/ в Европе и ARIN в США (также samspade.org) могут помочь определить эти мошеннические IP-адреса источника. Возможно, вы не сможете сделать очень много с информацией, если эти IP-адреса зарегистрированы у одного из крупных поставщиков услуг, таких как BT в Великобритании, но вы никогда не узнаете

...