Які загрози безпеці представляє безпека для облікового запису SA та інших відомих назв облікових записів?

Чи відоме таке ім’я облікового запису, як sa, створює загрозу безпеці бази даних? Чи використовує автентифікацію Windows на SQL Server, чи застосовується та ж політика щодо паролів (якщо вона була встановлена ​​для блокування облікового запису через 5 разів)?

Чи відоме таке ім’я облікового запису, як sa, загрожує безпеці для бази даних?

Обліковий запис користувача "бог" із відомим іменем, як правило, вважається гіршою ідеєю, ніж користувач бога з менш відомим іменем. Це робить атаки грубої сили, що трохи простіше, тому що зловмисник повинен лише вгадати пароль, а не ім'я користувача та пароль.

Також мати богокористувача все одно може бути небезпечно. Як правило, краще мати конкретних користувачів з певними правами на те, що їм потрібно робити. Таку безпеку на основі привілеїв легше реалізувати з нуля, ніж пізніше впорядкувати у ваше середовище.

Відключення sa та надання певним користувачам певних прав адміністратора, як це потрібно на SQL-сервері, по суті є тією ж рекомендацією, що й відключення rootта передача прав адміністратора, як це потрібно через sudoLinux та подібні. Завжди можна знову ввімкнути saодин раз, безпосередньо підключений до машини, з відповідними привілеями, якщо щось не піде, і ви втратите всі права, які потрібні вашим користувачам для роботи (і виправлення проблеми) так само, як ви можете інженерувати кореневий доступ до Linux поле, якщо у вас є фізичний доступ до коробки - тому відключення облікового запису не є магічною кулею (але, коли зловмисник має фізичний доступ до вашої машини або повний адміністративний доступ через RDC або SSH, всі ставки все одно знімаються).

Чи використовує автентифікацію Windows на SQL Server, чи застосовується та ж політика щодо паролів (якщо вона була встановлена ​​для блокування облікового запису через 5 разів)?

При використанні Windows Integrated Authentication SQL сервер не контролює блокування облікових записів і таке - він просто відображає користувача Windows з користувачем SQL і просить ОС поручитися на те, що користувач надав відповідні облікові дані. Для користувачів інтерактивних людей це означає, що будь-яке блокування може відбуватися під час спроби автентифікації користувача з Windows, а не під час входу в SQL Server.

Непогано зробити так, щоб користувач адміністратора за замовчуванням (admin / root / postgres / sa / тощо) фактично не існував у вашій системі. Ви завжди можете створити привілейований обліковий запис під іншим ім’ям.

Якщо нічого іншого, люди, які намагаються експлуатувати вашу систему, не мають такого простого часу, як якщо б вони працювали незрячими (наприклад, sql-ін'єкція без інтерактивної оболонки, або не в змозі бачити прямий вихід із своїх команд)

Що стосується блокування облікових записів - якщо комусь вдалося пройти досить далеко, щоб навіть спробувати увійти у вашу машину, якщо ви спеціально не дозволяєте користувачам прямого входу, ви вже програли бій. Особисто я здебільшого не прихильник блокування, тому що це дає комусь можливість створити відмову в обслуговуванні, якщо їм вдасться отримати ім’я будь-якого з ваших користувачів. (а їх заблокувати суперкористувача? Не весело).

Я рекомендую переглянути еталони СНД ... вони не мають їх для кожної бази даних, але у них є рекомендації щодо Oracle, MS SQL, DB2 та MySQL. Якщо ви працюєте щось інше, все-таки варто переглянути загальні речі, які вони рекомендують.

Я не бачив, щоб хтось згадував це, тому додам його. За допомогою SQL Server 2005+, якщо ваш сервер є частиною домену, а домен має політику паролів, ви можете дозволити застосувати політику паролів на входах у систему SQL. Сюди входять вимоги щодо складності пароля та можливість примусової зміни пароля при вході в систему.

Зауважте, що це може часом спричиняти проблеми з деякими інсталяторами програмного забезпечення, які не оновлювались для роботи з SQL 2005+ і створювали логіни SQL з незахищеними паролями.

Є два режими аутентифікації, що використовуються в SQL Server: автентифікація Windows та змішаний режим (дозволяє як автентифікація Windows, так і автентифікацію SQL Server)

Перший режим є менш вразливим до жорстоких атак, оскільки зловмисник, швидше за все, натрапить на блокування входу (функція політики блокування облікових записів) після обмеженої кількості спроб атаки. Кожне виробниче середовище, якщо використовується режим автентифікації Windows, повинна використовувати функцію політики блокування, оскільки це робить неможливими атаки грубої сили

Якщо мова йде про вразливість грубої сили атаки автентифікації на SQL Server, ситуація не така сприятлива. Аутентифікація SQL Server не має функцій, які дозволять визначати, коли система перебуває під жорстокою атакою. Більше того, SQL Server дуже чуйний, коли справа стосується перевірки облікових даних автентифікації SQL Server. Він може легко впоратися з повторними, агресивними, грубими спробами входу без негативної загальної продуктивності, яка може вказувати на такі атаки. Це означає, що автентифікація SQL Server є ідеальною ціллю для розлому пароля за допомогою жорстоких атак

Крім того, методи грубої сили розвиваються з кожним нововведеним методом складності шифрування та пароля. Наприклад, зловмисники, які використовують таблиці веселки (попередньо обчислені таблиці для повернення криптографічних хеш-значень для кожної можливої ​​комбінації символів), можуть легко і швидко зламати будь-який хешированний пароль

Щоб захистити ваш SQL Server від жорстоких атак, слід врахувати наступне:

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

Обліковий запис sa, коли це ввімкнено, може робити все на SQL Server. Якщо зловмисник мав би потрапити в цей обліковий запис, він міг би зробити що завгодно на екземплярі SQL Server (і, можливо, на хост-операційній системі).

SA (та інші добре відомі назви акаунтів) - це добре відомі моменти, на які хакери можуть атакувати. Деякі з Oracle були слабо задокументовані, і тому паролі за замовчуванням не завжди змінювалися. Отримавши контроль над обліковим записом SA в SQL Server, ви керуєте сервером, на якому він працює, і можете запустити будь-який код або встановити все, що завгодно. У мої більше ковбойські дні я пам’ятаю, що мені не дозволили (потрібні документи, які я не збирався заповнювати), щоб встановити елемент керування ActiveX на веб-сервері, на якому розміщувався також SQL Server - тому я скопіював і встановив елемент керування xp_cmdshell .