Повышение уровня защиты Microsoft SQL Server 2000

Серверы баз данных занимают свою нишу в информационной инфраструктуре предприятия. Зачастую в них хранится конфиденциальная информация, нарушение доступности, целостности или конфиденциальности которой может привести к значительным финансовым потерям.

Поскольку SQL Server представляет собой довольно сложный продукт, повышение уровня его защиты более рационально проводить в несколько этапов. В данной статье описывается методика поэтапной настройки сервера по уровням информационной инфраструктуры:

  • защита сетевого обмена;
  • защита операционной системы;
  • защита компонентов базы данных;
  • защита приложений, использующих базу данных.

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

Защита сетевого обмена

Для повышения сетевой безопасности сервера SQL Server необходимо решить следующие задачи:

  • выбор и настройка сетевых библиотек сервера;
  • фильтрация трафика и разграничение сетевого доступа;
  • шифрование трафика.

Настройка сетевых библиотек. Настройка сетевых библиотек сервера осуществляется через утилиту SQL Server Network Utility. При выборе сетевых библиотек необходимо исходить из задач, которые будут решаться сервером. Например, если сервер установлен на одном компьютере с сервером Web и его единственная задача — предоставлять Web-серверу данные для создания динамических страниц, можно очистить список используемых протоколов. Подобная настройка лишит сервер возможности обмена по сети, соответственно он не будет подвержен сетевым атакам.

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

И последний критерий — это возможности, поддерживаемые теми или иными библиотеками. Так, библиотека TCP/IP позволяет серверу задействовать SSL для шифрования трафика и протокола аутентификации Kerberos. Библиотека Named Pipes используется для поддержки протокола аутентификации NTLM при взаимодействии с устаревшими клиентами. Поддержка сервером библиотеки Multiprotocol (RPC) дает серверу возможность защищать сетевой обмен средствами операционной системы.

Стандартно рекомендуется использовать сетевую библиотеку TCP/IP и удалить все остальные. Это связано с возможностью использования злоумышленником дополнительных сетевых библиотек для компрометации сервера. К примеру, если в сети используется TCP/IP и фильтрация трафика настроена таким образом, что соединение с портами SQL Server разрешено только с определенных компьютеров, злоумышленник сможет обойти это ограничение и соединиться с сервером, используя библиотеку Named Pipes через порты 137, 139, 445.

В настройках библиотеки TCP/IP для каждого экземпляра сервера SQL можно указать номер TCP-порта, на котором работает экземпляр. Дополнительно можно «спрятать» экземпляр сервера, установив переключатель Hide server. После настройки этого режима экземпляр сервера автоматически настраивается на работу через порт 2433 и не публикуется через службу SQL Server Resolution Service (SRS UDP 1434). Использование данной настройки возможно только для одного экземпляра SQL Server на сервере.

Если задействована настройка Hide Serve», то при направлении клиентом широковещательного запроса с целью определения экземпляров SQL Server в данном сегменте экземпляр ему не ответит. Но если пользователь знает номер порта, на котором работает «спрятанный» экземпляр (т. е. порт 2433), он сумеет с ним соединиться.

Гораздо более эффективным методом сокрытия сервера является настройка библиотек TCP/IP на использование нетипичных номеров портов (например, в диапазоне выше 5000) с последующей фильтрацией трафика SQL SRS. Таким образом, соединиться с сервером можно будет, только зная используемый им номер порта. Для централизованной настройки клиентов можно задействовать административный шаблон групповой политики, настраивающий клиентские библиотеки на работу с используемым сервером номером порта путем изменения значения параметра реестраHKLMSOFTWAREMicrosoftMSSQLServerClient SuperSocketNetLibTcp DefaultPort. Однако следует понимать, что данные настройки являются элементом «политики запутывания» и не гарантируют защиты, если злоумышленник сумеет соединиться с сервером и применить эвристические методы определения служб специализированных утилит, таких как nmap или XSpider.

Фильтрация трафика. Фильтрация трафика дает возможность заблокировать взаимодействие с сервером SQL по неиспользуемым сетевым протоколам, что повышает уровень его защиты от атак через другие сетевые службы. Для фильтрации трафика и разграничения доступа можно воспользоваться политикой протокола IPSec или другими средствами фильтрации трафика уровня узла, например персональным межсетевым экраном Internet Connection Firewall.

Если на сервере реализована тщательно продуманная политика фильтрации трафика, это существенно ограничивает возможности злоумышленника. Так, если исходящие соединения с сервера запрещены, не будут работать механизмы взлома, использующие технологию обратного соединения (reverse shell), и, кроме того, злоумышленник не сумеет организовать соединение со своим сервером для загрузки дополнительных инструментов.

Для более безопасного разграничения сетевого доступа можно задействовать механизмы взаимной аутентификации клиента и сервера с использованием общих ключей IPSec или в случае, если SQL Server работает на основе Windows Server 2003, права Access this computer from network для учетной записи компьютера (см. статью «Неизвестный IPSec», опубликованную в Windows & .NET Magazine/RE №6 за 2003 год).

В табл. 1 представлен пример таблицы фильтрации трафика при помощи IPSec.

Таблица 1. Пример таблицы фильтрации трафика при помощи IPSec

Правило 1 разрешает взаимодействие со службой Server Resolution Service, необходимой для определения установленных экземпляров сервера. Если используется описанный выше метод настройки клиентских библиотек, это правило можно удалить.

В правиле 2 разрешается взаимодействие всех пользователей с портом 1433, на котором работает общедоступный экземпляр сервера SQL.

Правило 3 требует установления с портом 2433 защищенного соединения. Этот порт используется экземпляром сервера, который является основой для Web-приложения. Соединение с ним возможно только с компьютеров, успешно прошедших аутентификацию IPSec и наделенных правом Access this computer from network. В нашем случае это Web-сервер и рабочие станции администраторов.

Правила 4,5 и 6 разрешают взаимодействие с сервером по протоколам NetBIOS/CIFS. Данные протоколы используются сетевой библиотекой Named Pipes. Если применяется аутентификация Kerberos или NTLMv2, эти правила можно исключить.

Правило 7 разрешает защищенное взаимодействие по протоколу RDP, используемому сервером терминалов.

Правило 8 дает возможность взаимодействия с контроллером домена для аутентификации и применения групповых политик.

Шифрование трафика. Для шифрования трафика сервера SQL можно задействовать протоколы IPSec и SSL v 3.0. Во врезке «IPSec или SSL v 3.0?» приводится сравнение данных протоколов.

Для использования SSL, согласно рекомендациям статьи базы знаний Microsoft KB276553, необходимо получить сертификат X.509v3, выданный для аутентификации сервера на его доменное имя, и установить его в локальное хранилище компьютера. После этого требуется включить шифрование трафика в сетевых утилитах сервера и проверить соединение со стороны клиента.

Строка настройки соединения ODBC в этом случае будет выглядеть следующим образом:

Driver=SQLServer;Server=ServerName;

Network=DBNETLIB.DLL;Encrypt=YES

Возможно использование шифрования не на всех клиентских компьютерах. Для этого настройка Force Protocol Encryption включается не на сервере SQL, а в настройках клиентской библиотеки.

Защита операционной системы

При повышении уровня защиты базовой операционной системы необходимо решить следующие задачи:

  • настроить системные службы;
  • настроить права пользователей и разрешения файловой системы;
  • настроить шифрование файлов базы данных.

Настройка системных служб и прав пользователей. Microsoft SQL Server устанавливается и функционирует как несколько системных служб. Для каждого экземпляра базы данных создается служба с именем, образованным по схеме MSSQL$<имя экземпляра>. Так же создаются экземпляры SQL Server Agent (SQLAgent$< имя экземпляра>), отвечающие за выполнение периодических заданий, таких как автоматическая архивация, поддержка базы данных и т. д.

Кроме того, для сервера в целом создаются службы Microsoft Search (отвечает за индексирование и поиск документов в том случае, если включена поддержка полнотекстового поиска) и DTS (служба, отвечающая за поддержку распределенных транзакций).

Служба MSSQL может работать в контексте учетной записи Local System или от имени учетной записи пользователя (доменного или локального). Очень нежелательно применять для запуска служб учетную запись LocalSystem, как и любую другую учетную запись с административными полномочиями. Это связано с тем, что в случае компрометации сервера все действия в системе будут производиться от имени этой записи, т. е. злоумышленник будет работать с административными привилегиями.

Рекомендуется запускать службы от имени учетной записи (локальной или доменной), имеющей ограниченные привилегии. Локальную учетную запись целесообразно использовать, если в задачи сервера SQL Server не входит сетевое взаимодействие с другими службами. В обратном случае применяется доменная учетная запись.

На сервере желательно отключить службы, которые для работы SQL Server не нужны. Их список приведен в табл. 2.

Таблица 2. Службы, которые не требуются для работы SQL Server

Учетной записи, от имени которой работают службы сервера, присваиваются следующие пользовательские права и привилегии:

Act as part of operating system

Lock pages in memory

Bypass traverse checking

Log on as service

Increase quotas

Replace a process level token

Deny logon locally

Deny log on through Terminal Services

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

Желательно устанавливать SQL Server на раздел, отличный от раздела с операционной системой. Это уменьшит влияние сервера базы данных на операционную систему и облегчит настройку ряда параметров безопасности.

Настройка разрешений файловой системы и реестра. При настройке разрешений файловой системы из списков контроля доступа сервера необходимо удалить учетную запись Everyone. Вместо нее можно использовать группу Users или Authenticated Users. Для нормального функционирования сервера необходимо установить разрешения на папки файловой системы и разделы реестра, описанные в табл. 3. Запись в другие папки системы, включая корневые разделы, должна быть доступна только для администраторов и учетной записи System.

Для ограничения возможностей злоумышленника в случае компрометации сервера баз данных необходимо либо удалить из системы, либо установить разрешение SQLServer — Deny Full Access на системные утилиты, такие как: explorer.exe, regedit.exe, poledit.exe, taskman.exe, at.exe, cacls.exe, cmd.exe, finger.exe, ftp.exe, nbstat.exe, net.exe, net1.exe, netsh.exe, rcp.exe, regedt32.exe, regini.exe, regsvr32.exe, rexec.exe, rsh.exe, runas.exe, runonce.exe, svrmgr.exe, sysedit.exe, telnet.exe, tftp.exe, tracert.exe, usrmgr.exe, wscript.exe, xcopy.exe

Шифрование баз данных. Для защиты файлов базы данных на физическом уровне имеет смысл зашифровать их. В операционной системе Windows 2000/2003 предусмотрена возможность шифрования базы данных при помощи шифрующей файловой системы. Encrypting File System — надстройка над NTFS, позволяющая в прозрачном для пользователя режиме шифровать и расшифровывать файлы на жестком диске компьютера.

Для использования этой возможности необходимо:

  1. Настроить службу SQL Server на запуск от имени учетной записи пользователя.
  2. Войти в систему, используя данную учетную запись.
  3. Используя «Проводник», открыть свойства папки Program Filesmicrosoft sql server<имя экземпляра>Data или другой, где сохранены базы данных.
  4. Установить для папки атрибут (Properties — Advanced — Encrypt contents to secure data).

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

Шифрование при помощи Encrypting File System является эффективным средством защиты данных, но только при условии соблюдения всех рекомендаций по ее настройке. В частности, необходимо удалять из системы секретный ключ агента восстановления. Также желательно удалить все локальные учетные записи из базы пользователей сервера SQL Server (особенно это касается локального администратора), поскольку при физическом доступе пароли этих учетных записей легко могут быть переназначены.

Для повышения уровня защиты можно применить шифрование LSA при помощи утилиты Syskey. Лучше всего использовать в качестве ключа шифрования парольную фразу.

Защита компонентов базы данных

Первым этапом настройки безопасности SQL Server как приложения является выбор используемой модели аутентификации. Рекомендуется применять метод Windows в связи с изложенными выше проблемами метода SQL Server (пересылка пароля в закодированном виде).

Затем необходимо решить, будут ли члены группы локальных администраторов иметь доступ к серверу базы данных с привилегиями системных администраторов. Автоматически создаваемую серверную учетную запись Bultin/Administrators рекомендуется удалить. Эта рекомендация связана прежде всего с обязательным присутствием в данной группе учетной записи локального администратора, чей пароль может быть моментально изменен в случае наличия у злоумышленника физического доступа или подобран по сети. После того как злоумышленник получит доступ к системе от имени этой учетной записи, он сможет обойти все защитные механизмы, включая шифрование баз данных при помощи EFS.

С учетной записью локального администратора связаны и другие проблемы, узнать о которых подробнее можно из статьи «Локальная угроза», опубликованной в Windows & .NET Magazine/RE №3 за 2003 год. Перед удалением учетной записи Bultin/

Administrators необходимо создать серверную учетную запись на основе доменной группы и присвоить ей роль System Administrator.

Следующим этапом является удаление стандартных баз данных, входящих в дистрибутив в качестве примеров. К ним относятся базы данных NorthWind и pubs. Данные базы содержат ряд ошибок, имеют слабые разрешения и часто используются злоумышленниками для атак.

Затем необходимо запретить выполнение запросов типа AdHoc. Такие запросы (OPENROWSET, OPENQUERY и OPENDATASOURCE) позволяют серверу устанавливать соединение с внешним сервером и сохранять на нем свои данные. Они очень редко используются в приложениях, но могут быть применены злоумышленником для удаленного получения информации из баз данных сервера. Примером применения подобной техники является программа Data Thief, использующая метод внедрения SQL-кода (SQL Injection) для выполнения запросов AdHoc.

Для отключения возможности выполнения запросов AdHoc необходимо установить значение параметра системного реестра DisallowAdhocAccess равным 1 для каждой сетевой библиотеки сервера. Ниже перечислены разделы реестра, в которых располагаются настройки сетевых библиотек:

HKLMSoftwareMicrosoftMSSQLServerProviders MSDAORA;

HKLMSoftwareMicrosoftMSSQLServerProviders ADSDSOObject;

HKLMSoftwareMicrosoftMSSQLServerProviders DB2OLEDB;

HKLMSoftwareMicrosoftMSSQLServerProviders MSIDXS;

HKLMSoftwareMicrosoftMSSQLServerProviders MSQLImpProv;

HKLMSoftwareMicrosoftMSSQLServerProviders MSSEARCHSQL;

HKLMSoftwareMicrosoftMSSQLServerProviders MSDASQL.

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

Обычно такие процедуры расширяют функциональность базы данных, добавляя в нее, к примеру, возможность выполнять произвольные команды операционной системы, возможность чтения реестра, отправки почтовых сообщений и т. д. Случается, что подобные процедуры содержат ошибки (к примеру, внедрение кода в sp_msdropretry или переполнение буфера в ms_makewebtask), что может быть использовано для повышения привилегий.

По умолчанию роли public дано разрешение на выполнение некоторых потенциально опасных хранимых процедур. Необходимо установить более строгие разрешения на выполнение этих процедур и отслеживать их модификацию.

Список расширенных хранимых процедур, доступ к которым необходимо ограничивать, можно взять из рекомендаций по настройке безопасности сервера SQL, например из рекомендаций центра SNAC NSA (http://www.nsa.gov/).

Выполнение описанных настроек можно автоматизировать при помощи сценариев на языке T-SQL. Пример подобного сценария приводится на сервере www.sqlsecurity.com. Как обычно, перед применением сценария в производственной среде его следует тщательно протестировать.

Аудит сервера SQL Server

Существует несколько разных методов настройки аудита в базах данных SQL Server. Лучшим решением является использование комбинаций данных методов в зависимости от решаемых задач. По умолчанию аудит на сервере не активизирован.

Аудит аутентификации сервера позволяет отслеживать попытки аутентификации на сервере SQL. Включить его можно через Enterprise Manager или путем модификации параметра реестра HKLMSoftwareMicrosoftMSSQLServerMSSQLServer Audit Level. Возможные значения 0...3.

Нулевое значение параметра означает отключение аудита, 1 — запись удачных попыток аутентификации, 2 — неудачных. При значении параметра 3 включается аудит всех попыток регистрации.

События сохраняются в журнале Application операционной системы. Дополнительные настройки позволяют сохранять события в журнале ошибок SQL Server. Настройка данного типа аудита предполагает включение отслеживания неудачных попыток аутентификации (значение 2) с последующим анализом на предмет выявления попыток несанкционированного доступа или подбора паролей.

Другой тип аудита относится к событиям сервера баз данных. Настраивать и отслеживать их можно при помощи утилиты SQL Profiler.

Включение любой из данных категорий событий аудита приведет к сохранению следующей информации о событиях:

дата и время события;

учетная запись пользователя;

тип события;

результат выполнения действия (успешно или нет);

место события (к примеру, имя компьютера);

имя объекта, к которому осуществлялся доступ;

текст SQL-запроса (за исключением паролей).

Условно их можно разделить на две группы — события управления и события работы с объектами.

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

Другая часть событий очень полезна при отладке приложений. Предположим, вы планируете внедрить систему на основе SQL Server, но не уверены, что разрешения на объекты базы данных сконфигурированы правильно. Это разумное предположение, поскольку разработчики обычно ограничиваются разрешениями по умолчанию или в крайнем случае добавляют недостающие разрешения.

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

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

При настройке аудита можно указать, где сохранять события — в файле или в таблице базы данных. Первый вариант имеет преимущество с точки зрения защищенности (компрометация сервера баз данных не грозит непосредственно файлу событий). Второй значительно удобнее с точки зрения анализа журналов, поскольку становится возможным применение запросов языка T-SQL к базам данных журналов.

Заключение

Повышение уровня защиты приложений на основе Microsoft SQL Server 2000 является довольно сложной задачей и в значительной степени зависит от работающего на его базе приложения. Лучше всего здесь действовать по принципу «отключить все лишнее и понемногу включать, пока не заработает». Процесс этот довольно долгий и требует некоторой практики, однако настроенные таким образом серверы могут работать годами, не требуя дополнительного внимания.

IPSec или SSL v 3.0?

  • SSL поддерживается клиентскими библиотеками SQL Server, соответственно может использоваться любой ОС семейства Windows. IPSec поддерживается Windows 2000 и выше.
  • SSL используется для защиты трафика SQL-сервера как приложения. IPSec защищает взаимодействие на сетевом уровне (например, по определенным портам). Поэтому в случае реконфигурации сервера (изменения настроек сетевых библиотек) необходимо изменять и настройки IPSec.
  • IPSec поддерживает взаимную аутентификацию клиента и сервера. В случае использования IPSec можно дополнительно разграничивать доступ при помощи прав Windows. В SSL реализована только аутентификация сервера.
  • IPSec при использовании ESP поддерживает два протокола защиты данных, DES и 3DES. SSL не позволяет выбрать алгоритм защиты.

Сергей Гордейчик (gordey@infosec.ru) — преподаватель учебного центра «Информзащита», автор курса «Повышение защищенности систем на основе Microsoft Windows Server 2003», MCSE, MCT