Рекомендации. Уязвимости подсистемы контроля доступа к СУБД

Проникновение

Уязвимости подсистемы контроля доступа к СУБД

А вот злоумышленник, осуществляющий свою несанкционированную деятельность в нерабочее время, может делать. СУБД должна блокировать такого рода попытки, но на практике ни одна из СУБД (Oracle, Microsoft SQL Server и т.д.) не контролирует доступ к базе данных в нерабочее время.

Sybase 12.x и в Oracle 8.x и более поздних версиях появился механизм контроля неудачных попыток регистрации в системе (sp_configure "maximum failed logins" в Sybase и FAILED_LOGIN_ATTEMPT в Oracle).

для СУБД действуют те же правила, что и для операционной системы. Этот вид ПО также нуждается в регулярной проверке с целью обнаружения всех несанкционированных изменений и наличия "дыр". Делать это можно вручную, используя уже названные источники информации (например, Web-сервер "Информзащиты" и серверы производителей) или применяя автоматизированные системы анализа защищенности, такие как Database Scanner компании Internet Security Systems (http://www.iss.net/), SQL <> Secure Policy компании BrainTree Security Software (http://www.braintree.co.uk/), e-Secure компании Cyrano (http://www.cyrano.com/), SFProtect компании Hewlett-Packard (http://www.hp.com/).

Рассмотрим сценарий атаки на сервер с установленным MS SQL Server 2000. Потенциальному нарушителю необходимо получить доступ к MS SQL с ролью «Администратор базы данных», а это может легко произойти если:

• пароль учетной записи «sa» пустой или может быть легко подобран, что часто встречается, когда СУБД используется в тестовой эксплуатации, либо как платформа для разработчиков;
• неправильно назначены роли пользователей в самой СУБД: учетная запись обычного пользователя СУБД обладает ролью «Владелец базы данных» master, либо ролью «Администратор базы данных».
• пароль некоторой учетной записи, входящей в группу «Администраторы», пустой или может быть легко подобран или определен (задача получения доступа к серверу, зная пароль администратора, на первый взгляд может показаться странной, но, например, если к серверу разрешено подключение только к портам MS SQL, описываемый в статье способ позволяет выполнять команды ОС).

Для устранения описанной уязвимости и снижения риска от проникновения нарушителя на сервер с установленной СУБД MS SQL рекомендуется:

1. Четко разграничить производственную и тестовую среду (среду разработки). Производственные сервера не должны содержать тестовых баз данных или инструментария разработчиков.
2. Исключить возможность совмещения различных корпоративных сервисов на сервере с установленной СУБД MS SQL.
3. Использовать сложные пароли для административных учетных записей как операционной системы, так и СУБД – не менее 15 символов, содержащих буквы в разных регистрах, цифры и специальные символамы.
4. Удалить из пользователей MS SQL группу «Администраторы» операционной системы и четко прописать, какие учетные записи операционной системы имеют доступ к базам данных.
5. Избегать предоставления доступа к расширенным хранимым процедурам для пользователей СУБД.
6. Использовать привилегированные учетные записи СУБД только для выполнения административных задач.
7. Запускать процесс MS SQL Server с правами учетной записи непривилегированного пользователя. Это серьезно усложнит проникновение в систему, так как потенциальный нарушитель в лучшем случае сможет выполнять команды только как пользователь с ограниченными привилегиями.
8. Протоколировать системные события MS SQL Server, что позволит упростить процесс слежения за действиями потенциального нарушителя.
9. Регулярно устанавливать обновления операционной системы Windows и СУБД MS SQL.
10. Ограничить с помощью межсетевого экрана доступ к портам MS SQL для пользователей, не использующих этот сервис.

Дата добавления: 2014-01-14