Какие угрозы безопасности создает учетная запись SA и другие известные имена учетных записей?

Представляет ли известное имя учетной записи, например, sa, угрозу безопасности базы данных? При использовании проверки подлинности Windows на SQL Server накладывает ли она ту же политику паролей (если она была установлена ​​для блокировки учетной записи после 5 раз)?

Представляет ли известное имя учетной записи, например, sa, угрозу безопасности базы данных?

Учетная запись «бога» с известным именем обычно считается худшей идеей, чем учетная запись бога с менее известным именем. Это облегчает атаки методом перебора, поскольку злоумышленнику остается только угадать пароль, а не имя пользователя и пароль.

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

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

При использовании проверки подлинности Windows на SQL Server накладывает ли она ту же политику паролей (если она была установлена ​​для блокировки учетной записи после 5 раз)?

При использовании встроенной проверки подлинности Windows сервер SQL не контролирует блокировки учетных записей и т. Д. Он просто сопоставляет пользователя Windows с пользователем SQL и просит ОС поручиться за то, что пользователь предоставил соответствующие учетные данные. Для интерактивных пользователей это означает, что любая блокировка будет происходить, когда пользователь пытается выполнить аутентификацию в Windows, а не во время входа в SQL Server.

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

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

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

Я бы порекомендовал просмотреть контрольные показатели CIS ... у них их нет для каждой базы данных, но у них есть рекомендации для 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 для копирования и установки элемента управления ,