Як захистити SQL Server від хакерів


9

У мене виникає проблема, і я не міг зрозуміти, як її вирішити. У мене є сервер SQL на сервері Windows 2008 R2. Цей SQL Server 2005 використовується для отримання підписок на DB з іншого SQL-сервера, розташованого в інших місцях Інтернету. У мене відкритий порт сервера sql через брандмауер, однак у межах сфери застосування я ввів IP іншого SQL Server. Здійснюючи це, я сподівався, що запити на з'єднання через цей порт не дотягнуться до SQL Server, якщо запити не надходять від іншого SQL-сервера (IP-адреса якого вказана в області дії брандмауера). Але, коли я бачу журнал, є сотні записів "невдалого входу користувача з користувачем" (і вони приходять щосекундно). Здається, якийсь хакер намагається вгамувати пароль користувача. Але питання в тому, чому Windows дозволяє цим запитам дістатися до SQL Server, навіть якщо вони не надходять з IP-адреси, яка вказана в області брандмауера? Який правильний спосіб захисту цього SQL-сервера. Інший IP, ніж IP іншого SQL Server, не повинен підключатися до цього sql-сервера.

EDIT - Додаткова інформація:

Я запускав telnet на порту сервера sql з різних машин. Telnet виходить з ладу, за винятком випадків, коли він запускається з машини, про яку конкретно йдеться в області брандмауера. Отже, виявляється, що брандмауер прекрасно блокує порт сервера sql. Але чому я бачу ті невдалі запити для входу до користувача "sa" з різних IP-адрес у журналі SQL Server? Чи можливо хакер зайти в машину через порт 80 і потім якось намагається підключитися до сервера sql? Порти 80 та 443 відкриті для всіх. Усі інші порти закриті за винятком порту сервера sql (і він відкритий лише для одного конкретного IP-адреси). На порту 80 на веб-сервері нічого не працює, що може призвести відвідувача до SQL-сервера. Насправді на веб-сервері є лише один файл index.html (чистий HTML без підключення до SQL). Це лише тестовий сервер, який встановлюється для подальшого використання. Тільки тестові дані в SQL Server.

Редагувати:

Я ввімкнув трасування брандмауера, щоб включити як падіння, так і успіх. Зараз все простежується. Потім я переходжу до журналу SQL Server, де бачу ці невдалі спроби входу з різних IP-адрес у Китаї. Але записів для цих IP-адрес у журналі брандмауера немає. Як це можливо? Чи можуть вони потрапити на сервер SQL, повністю обходячи брандмауер? Якщо припустимо, якийсь порт брандмауера був відкритий, через який вони могли входити, журнал брандмауера повинен відображати запис для цієї IP-адреси. Я в повній втраті.


Як щодо використання тригера входу ? Крім того, SQL Server не повинен піддаватися доступу до Інтернету. Крім того, ви можете використовувати програмні правила в брандмауері Windows, щоб обмежити діапазон IP-адрес.
Кін Шах

Так, я міг би, але в глибині душі це не зовсім про SQL Server. Я намагаюся з’ясувати, чому брандмауер Windows не робить того, що він повинен робити, тобто не пропускає ці запити через те, що вони надходять не з єдиної дозволеної IP-адреси.

1
Так, це здається, що ваш брандмауер Windows неправильно налаштований. Можливо, у вас є ще одне більш загальне правило, яке дозволяє порт 1433 (або дозволяє все), або, можливо, брандмауер Windows вимкнено в інтерфейсі NIC, що має Інтернет. Важко сказати, не бачивши конфігурації. Але це справді більше питання для ServerFault, як каже Макс. Ви мали на увазі Windows 2008 R2, btw? 'RC' - це Release Candidate, програмне забезпечення перед випуском для тестування.
Джеймс Л


1
Ви справді використовуєте стару операційну систему кандидата на випуск ?! Виправте це першим.
Майкл Хемптон

Відповіді:


12

Звучить, що брандмауер неправильно налаштований. Це перший крок.

Зазвичай я би не сутенерну до написаної нами книги, але в цьому випадку я зроблю виняток. Це називається Забезпечення SQL Server, і це дозволить вам добре почати.


Що ж, ваша книга точно підходить до цього питання :-)
mfinni

Класно! Чи є вказівні інструкції щодо використання сертифікатів замість локальних / Windows auth для серверів, орієнтованих на Інтернет? ;-)
Грег Аскеу

Дивіться мої зміни. Начебто брандмауер працює нормально. Ці китайські хакери - це ще одна хитрість, щоб потрапити на SQL Server.
Аллен Кінг

1
Якщо хтось підключається до порту SQL з загальнодоступної IP-адреси, то брандмауер неправильно налаштований. Якщо вони надходять із внутрішнього ІР, то у вас є якісь інші проблеми. SQL самостійно не підтримує сертифікати. Це потрібно зробити через відображення AD та сертифікатів.
mrdenny

Назад до креслення дійсно для брандмауера. Я б витягнув сервер SQL з Інтернету, поки ви не вирішите ситуацію з брандмауером. Таким чином ви зможете відносно легко заборонити IP-адреси для всіх діапазонів IP-адрес.
Течі Джо

4

СІмплі сказав - ти цього не робиш. Я б не користувався afirewall і т. Д. - сервер SQL не має права бути в Інтернеті. ДУЖЕ ДУЖЕ мало винятків.

Для реплікації встановіть належний VPN.


Я трохи розгублений. Якщо сервер БД не є в Інтернеті, як сервер веб-застосунку Web App дістанеться до сервера БД?
Аллен Кінг

Через внутрішню мережу. Основні настройки. Веб-додаток працює в обох мережах.
TomTom

3

Окрім того, що правильно налаштувати брандмауер, є кілька загальних рекомендацій, щоб захистити SQL Server від грубої атаки:

  • Вимкніть обліковий запис 'sa'. Знання точного імені для входу полегшить атаки

    ALTER LOGIN sa DISABLE
    

Інший варіант - перейменувати обліковий запис 'sa' на менш очевидне ім’я

ALTER LOGIN sa WITH NAME = SimonXZY
  • Використовуйте автентифікацію Windows замість автентифікації в змішаному режимі. Під час автентифікації Windows застосовується політика щодо пароля Windows, і вона блокує логін у випадку послідовних невдалих спроб входу
  • Аудит невдалих логотипів. Найпростіший спосіб зробити це - встановити параметр аудиту входу на Властивості сервера, Захист на лише Не вдалося ввійти або Обидва невдалі та успішні входи. Це не допоможе вам захиститися від грубої атаки, але допоможе вам бути в курсі нападів

Більше корисних рекомендацій тут: Запобігання жорстокої атаки або нападу словника: як утримати брутантів подалі від вашого бабло

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.