CITKIT.ru
3 терабайта свободного софта!
Logo    
IT-рынок Новости мира IT Океан(!) софта на CITKIT.ru Форумы Поступления в библиотеку Учебный центр Курилка
CitForum    CITForum на CD Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

23.05.2005

Google
WWW CITForum.ru

Новости мира IT:

  • 11.05 - Intel создает свою группу по Open Source
  • 11.05 - Банк контролирует использование USB устройств при помощи DeviceLock
  • 11.05 - Microsoft устранила опасную дыру в Windows
  • 11.05 - "Корпорация ОСС" создает антимонопольный альянс операторов IP-телефонии
  • 11.05 - В Mac OS X найдены множественные уязвимости
  • 11.05 - "Билайн" запускает услугу "Мобильная почта"
  • 11.05 - Две критические уязвимости в браузере Firefox 1.0.3
  • 11.05 - IBM покупает начинающую Open Source-компанию Gluecode
  • 11.05 - Microsoft готова к битве с Open Source за школы
  • 11.05 - Sun завершит "открытие" Solaris в ближайшие 45 дней
  • 11.05 - Создатели браузера Firefox выпускают юбилейные монеты в честь 50 миллионов скачанных копий
  • 11.05 - Вышла пятая версия мобильной ОС от Microsoft
  • 11.05 - Поисковые движки умнеют быстрее, чем люди
  • 11.05 - Фишеры постоянно совершенствуются
  • 11.05 - Специалисты прогнозируют появление аналога Google Adsense от "Яндекс"
  • 06.05 - ICANN озаботилась проблемой торговых марок
  • 06.05 - Google патентует сортировку новостей
  • 06.05 - Intel готовит двуядерные процессоры второго поколения
  • 06.05 - Schoolforge-UK и OSC продвигают Open Source в школы
  • 06.05 - Новая версия рекламной программы подстрекает пользователей купить ПО для своего лечения
  • 06.05 - Microsoft продает ряд своих закрытых разработок
  • 06.05 - Google Labs анонсировал ускоритель интернета
  • 06.05 - Microsoft подвешивает пиратам "морковку"
  • 06.05 - В США входят в обиход "интеллектуальные" тележки для супермаркетов
  • 06.05 - Microsoft работает над аналогом PDF
  • 05.05 - Yahoo video search теперь доступен массам
  • 05.05 - Алмазы помогут бороться с хакерами
  • 05.05 - Интернет-охоту хотят запретить
  • 05.05 - Microsoft привлекает блоггеров для теста Longhorn
  • 05.05 - Основатель Red Hat предложил Стиву Джобсу помощь в решении проблемы с торговой маркой
  • 05.05 - Компьютерная система оргкомитета Кубка мира по футболу 2006 года пострадала от червя Sober
  • 04.05 - Cisco Systems представила многофункциональный продукт Adaptive Security Appliance 5500
  • 04.05 - Администрация Евросоюза поддержала идею всеевропейской интернет-библиотеки
  • 04.05 - Компьютерный вирус дарит билеты на чемпионат мира по футболу
  • 04.05 - Лаборатория Касперского: Обзор вирусной активности - апрель 2005
  • 04.05 - Microsoft хочет отсудить у россиянина два домена
  • 04.05 - Сделка между Lenovo и IBM завершена
  • 04.05 - Эпидемия червя Sober.p зафиксирована в Западной Европе
  • 04.05 - Panda Software публикует отчет о вирусной активности за апрель
  • 03.05 - Институт SANS обновил список наиболее опасных уязвимостей

    Архив новостей >>>


  • 2004 г.

    Введение в аудит-возможности Oracle

    Пит Финниган
    Источник: http://www.securityfocus.com/infocus/1689,
    Oracle Magazine RE ,Январь/Февраль 2004

    Вступление

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

    Все примеры SQL приведенные в этом документе могут быть скачены с авторского веб сайта по адресу http://www.petefinnigan.com/papers/audit.sql

    Сложные вопросы

    Существует несколько основных вопросов, на которые необходимо ответить, при принятии решения об использовании средств аудита Oracle. Такие как:

      Зачем аудит нужен в Oracle?

    Странный вопрос? Тем не менее, многие компании, в действительности, не используют средства внутреннего аудита Oracle. А когда и пытаются использовать, то заваливаются предложенным выбором. Они включают все подряд для полноты контроля, затем, видя, что в отчете слишком много информации для прочтения и изучения - быстро снова его выключают. Это типично для использования фаерволов, систем обнаружения вторжения (IDS) или других инструментов информационной безопасности, созданных для обнаружения нападений на сеть или операционную систему. Так почему бы не отслеживать то, что пользователи делают с "сокровищами короны" организации - данными. Аудит 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 используется для записи информации о запуске и останове базы, а также о вносимых структурных изменениях, таких как добавление файла данных в базу.

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

    Некоторые примеры

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

      Аудит доступа к базе данных

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

      Аудит изменений в структуре базы данных

    В производственной базе данных никому из пользователей никогда не следует изменять структуру схемы. Администраторам баз данных следует вносить изменения в специально отведенное для этого время. Какие-либо другие изменения следует рассматривать как подозрительные. Наблюдение за структурными изменениями может включить индикаторы некорректного использования базы данных.

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

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

    Аудит в Oracle разделен на три части:

      • аудит таких выражений как CREATE TABLE или CREATE SESSION,
      • аудит привилегий ALTER USER и
      • аудит на объект на объектном уровне SELECT TABLE.

    Основная конфигурация

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

    Аудит включается для записи в базу данных добавлением следующей строки в файле init.ora. Символьная связь к нему обычно может быть найдена в $ORACLE_HOME/dbs

    audit_trail = db

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

    SQL> select name,value from v$parameter
      2  where name like 'audit%';
    
    NAME                           VALUE
    ------------------------------ ----------
    audit_trail                    DB
    audit_file_dest                ?/rdbms/audit
    
    SQL>

    Но контролируемые действия не отслеживаются до тех пор, пока эти действия не заданы явно; это верно, кроме случаев привилегированного доступа к базе данных, запуска и останова базы данных, структурных изменений, таких как добавление файла данных. Эти действия отслеживаются в файле операционной системы в $ORACLE_HOME/rdbms/audit до тех пор пока audit_file_dest не переопределено в файле init.ora. В Windows эти события появляются в Event Viewer.

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

    SQL> select * from dba_stmt_audit_opts
      2  union
      3  select * from dba_priv_audit_opts;
    
    no rows selected
    
    SQL>

    Что бы найти какие объекты уже контролируются аудитом, запросите представление dba_obj_audit_opts.

    Рабочие примеры

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

    SQL> audit create session;
    Audit succeeded.
    SQL>

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

    Заметка: Формат всех команд аудита по документации Oracle выглядит следующим образом:

    audit {statement_option|privilege_option}
    [by user] [by {session|access}] [ whenever
    {successful|unsuccessful}]

    Обязательными являются только лишь statement_option и privilege_option части выражения. Другие части являются опционными и их использование позволяет сделать аудит более специфичным.

    Что бы пользователь мог задать команду аудита, необходимым условием для него является наличие привилегии "AUDIT SYSTEM". Найти пользователей, которые имеют эту привилегию, можно выполнив следующее:

    SQL> select *
      2  from dba_sys_privs
      3  where privilege like '%AUDIT%';
    
    GRANTEE                  PRIVILEGE          ADM
    ------------------------- -----------------------
    CTXSYS                    AUDIT ANY         NO
    CTXSYS                    AUDIT SYSTEM      NO
    DBA                       AUDIT ANY         YES
    DB                        AUDIT SYSTEM      YES
    IMP_FULL_DATABASE         AUDIT ANY         NO
    MDSYS                     AUDIT ANY         YES
    MDSYS                     AUDIT SYSTEM      YES
    WKSYS                     AUDIT ANY         NO
    WKSYS                     AUDIT SYSTEM      NO
    
    9 rows selected.
    
    SQL>

    Выше приведенные результаты принадлежат базе данных Oracle 9i. Пользователи по умолчанию MDSYS, CTXSYS и WKSYS были бы неплохой мишенью для атакующего, так как любые действия аудита могут быть выключены любым из этих пользователей, что бы скрыть любые предпринятые действия.

    Теперь аудит будет отслеживать все попытки доступа, и нам необходимо подождать, когда какие-нибудь пользователи войдут в систему что бы выполнить свою работу. И пока они будут делать это, давайте установим аудит, для контроля изменений в схеме. Для краткости, не все изменения объектов схемы будем отслеживать, в этом примере. Хотя в принципе, можно отслеживать изменения любых объектов БД: таблиц, индексов, кластеров, представлений, последовательностей, процедур, триггеров, библиотек и т.д. В этом примере аудит будет включен на выборочной группе объектов. Настройка аудита может быть выполнена за два этапа, создание команд аудита и запуск на исполнение, как показано ниже:

    set head off
    set feed off
    set pages 0
    spool aud.lis
    select 'audit '||name||';'
    from system_privilege_map
    where (name like 'CREATE%TABLE%'
    or name like 'CREATE%INDEX%'
    or name like 'CREATE%CLUSTER%'
    or name like 'CREATE%SEQUENCE%'
    or name like 'CREATE%PROCEDURE%'
    or name like 'CREATE%TRIGGER%'
    or name like 'CREATE%LIBRARY%')
    union
    select 'audit '||name||';'
    from system_privilege_map
    where (name like 'ALTER%TABLE%'
    or name like 'ALTER%INDEX%'
    or name like 'ALTER%CLUSTER%'
    or name like 'ALTER%SEQUENCE%'
    or name like 'ALTER%PROCEDURE%'
    or name like 'ALTER%TRIGGER%'
    or name like 'ALTER%LIBRARY%')
    union
    select 'audit '||name||';'
    from system_privilege_map
    where (name like 'DROP%TABLE%'
    or name like 'DROP%INDEX%'
    or name like 'DROP%CLUSTER%'
    or name like 'DROP%SEQUENCE%'
    or name like 'DROP%PROCEDURE%'
    or name like 'DROP%TRIGGER%'
    or name like 'DROP%LIBRARY%')
    union
    select 'audit '||name||';'
    from system_privilege_map
    where (name like 'EXECUTE%INDEX%'
    or name like 'EXECUTE%PROCEDURE%'
    or name like 'EXECUTE%LIBRARY%')
    /
    spool off
    @@aud.lis

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

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

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

      1  select audit_option,success,failure
      2  from dba_stmt_audit_opts
      3  union
      4  select privilege,success,failure
      5* from dba_priv_audit_opts
    SQL> /
    
    AUDIT_OPTION           SUCCESS    FAILURE
    --------------------------- ---------- ----------
    ALTER ANY CLUSTER      BY ACCESS  BY ACCESS
    ALTER ANY INDEX        BY ACCESS  BY ACCESS
    ALTER ANY INDEXTYPE    BY ACCESS  BY ACCESS
    ALTER ANY LIBRARY      BY ACCESS  BY ACCESS
    ?
    EXECUTE ANY LIBRARY    BY SESSION BY SESSION
    EXECUTE ANY PROCEDURE  BY SESSION BY SESSION
    
    38 rows selected.
    
    SQL>

    Каждый раз, когда пользователь пытается что-нибудь затронуть в базе данных, на что включен аудит, ядро Oracle проверяет действие и создает или обновляет (в случае одной записи для сессии) запись в таблице AUD$, владельцем которой является пользователь SYS. Эта таблица по умолчанию находится в табличном пространстве SYSTEM. Кстати говоря, это само по себе может стать причиной проблемы при атаке – отказ в обслуживании. Если табличное пространство SYSTEM заполнится, то база данных зависнет.

    AUD$ - особенная таблица [словаря данных], так как только из нее пользователь SYS имеет право удалять из нее записи. Если журнал аудита включен и пишется в базу данных, то число записей в этой таблице необходимо внимательно контролировать что бы удостовериться что она не растет слишком быстро, и не заполнила все системное табличное пространство. Стратегия очистки нуждается в адаптации, что бы сохранять размер таблицы и если необходимо архивировать записи журнала аудита для будущего использования. Одна из тактик может состоять в том, что бы копировать записи в итоговую таблицу, созданную для выполнения спецпроверки с целью выявления злоупотреблений. Эти итоговые таблицы могут располагаться в отдельной базе данных для увеличения защищенности. После копирования таблица sys.aud$ может быть усечена.

    Таблицу SYS.AUD$ можно передвинуть в табличное пространство, отличное от SYSTEM, но сначала, уточните это в технической поддержке Oracle, так как это действие может более не поддерживаться.

    Только пользователи, которым предоставлен специальный доступ к таблице SYS.AUD$ могут читать, изменять и удалять данные из нее. По умолчанию этими правами владеет SYS, но эти действия может выполнять любой другой пользователь, наделенный необходимыми правами. Существуют две специальные роли, которым разрешен доступ к таблице SYS.AUD$ на select и delete, это роли DELETE_CATALOG_ROLE и SELECT_CATALOG_ROLE. Эти роли не следует предоставлять обычным пользователям.

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

    • Путем выборки записей из SYS.AUD$ - Это исходный журнал аудита
    • Путем выборки записей из dba_audit_trail – Это представление DBA показывающее исходный журнал аудита.
    • Путем выборки записей из dba_audit_session – Это представление показывает только лишь события входа и выхода.

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

    SQL> get check_create_session
      1  --
      2  -- check_create_session.sql
      3  --
      4  col username for a15
      5  col terminal for a6
      6  col timestamp for a15
      7  col logoff_time for a15
      8  col action_name for a8
      9  col returncode for 9999
     10  select     username,
     11     terminal,
     12     action_name,
     13     to_char(timestamp,'DDMMYYYY:HHMISS') timestamp,
     14     to_char(logoff_time,'DDMMYYYY:HHMISS') logoff_time,
     15     returncode
     16* from       dba_audit_session
    SQL> /
    USERNAME TERMIN ACTION_N TIMESTAMP       LOGOFF_TIME     RETURNCODE
    ----------- ------ -------- --------------- --------------- --------
    SYS      pts/1  LOGOFF   09042003:051046 09042003:051641          0
    ZULIA    pts/1  LOGON    09042003:051641                       1017
    SYS      pts/1  LOGOFF   09042003:051649 09042003:053032          0
    SYS      pts/2  LOGOFF   09042003:052622 09042003:053408          0
    ZULIA    pts/1  LOGON    09042003:053032                       1017

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

      Неудачные попытки входа

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

    SQL> select count(*),username,terminal,to_char
    (timestamp,'DD-MON-YYYY') 2 from dba_audit_session 3 where returncode<>0 4 group by username,terminal,to_char
    (timestamp,'DD-MON-YYYY'); COUNT(*) USERNAME TERMIN TO_CHAR(TIM ---------- --------------- ------ ----------- 1 BILL pts/3 09-APR-2003 3 FRED pts/3 09-APR-2003 4 ZULIA pts/1 09-APR-2003 SQL>

    Здесь можно заметить два возможных злоупотребления, первое – это то, что пользователь Zulia пытается войти в систему и получает отказ четыре раза в один и тот же день. Возможно, пользователь забыл свой пароль или может быть кто-то пытается его угадать. Если изменить SQL, как показано ниже, то это даст более детальную информацию:

    SQL> select count(*),username,terminal,to_char
    (timestamp,'DD-MON-YYYY'),returncode 2 from dba_audit_session 3 group by username,terminal,to_char
    (timestamp,'DD-MON-YYYY')
    ,returncode; COUNT(*) USERNAME TERMIN TO_CHAR(TIM RETURNCODE ---------- ------------ ------ ----------- ---------- 1 BILL pts/3 09-APR-2003 1017 1 EMIL pts/1 09-APR-2003 0 1 EMIL pts/2 09-APR-2003 0 1 EMIL pts/3 09-APR-2003 0 1 EMIL pts/4 09-APR-2003 0 3 FRED pts/3 09-APR-2003 1017 3 SYS pts/1 09-APR-2003 0 1 SYS pts/2 09-APR-2003 0 1 SYSTEM pts/5 09-APR-2003 0 4 ZULIA pts/1 09-APR-2003 1017 1 ZULIA pts/1 09-APR-2003 0 11 rows selected. SQL>

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

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

    Одно интересное дополнение к приведенному выше SQL позволяет отыскать попытки входа в систему под несуществующим пользователем. В этом случае тоже будут созданы записи аудита. Следующий SQL иллюстрирует это:

    SQL> select username,terminal,to_char
    (timestamp,'DD-MON-YYYY HH24:MI:SS') 2 from dba_audit_session 3 where returncode<>0 4 and not exists (select 'x' 5 from dba_users 6 where dba_users.username=
    dba_audit_session.username) SQL> / USERNAME TERMIN TO_CHAR(TIMESTAMP,'D --------------- ------ -------------------- FRED pts/3 09-APR-2003 17:31:47 FRED pts/3 09-APR-2003 17:32:02 FRED pts/3 09-APR-2003 17:32:15 BILL pts/3 09-APR-2003 17:33:01 SQL>

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

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

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

    SQL> select     username,
      2     terminal,
      3     action_name,
      4     returncode,
      5     to_char(timestamp,'DD-MON-YYYY 
    HH24:MI:SS'), 6 to_char(logoff_time,'DD-MON-YYYY
    HH24:MI:SS') 7 from dba_audit_session 8 where to_date(to_char(timestamp,
    'HH24:MI:SS'),'HH24:MI:SS') < to_date('08:00:00','HH24:MI:SS') 9 or to_date(to_char(timestamp,
    'HH24:MI:SS'),'HH24:MI:SS') > to_date('19:30:00','HH24:MI:SS') SQL> / USERNAME TERMIN ACTION_N RETURNCODE TO_CHAR(TIMESTAMP,'D TO_CHAR(LOGOFF_TIME, -------- ------ -------- ---------- -------------------- -------------------- SYS pts/1 LOGOFF 0 09-APR-2003 20:10:46 09-APR-2003 20:16:41 SYSTEM pts/5 LOGOFF 0 09-APR-2003 21:49:20 09-APR-2003 21:49:50 ZULIA pts/5 LOGON 0 09-APR-2003 21:49:50 EMIL APOLLO LOGON 0 09-APR-2003 22:49:12 SQL>

    Приведенные выше SQL показывает любые соединения до 8:00 утра и после 7:30 вечера. Любые соединения, особенно те, которые выполнены привилегированными пользователями, такими как SYS или SYSTEM, должны быть исследованы. Особенное внимание следует обратить на то, откуда был произведен доступ. Например, если привилегированный доступ выполнен с машины, которая не находится в отделе администратора, администратор должен выяснить зачем он производился.

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

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

    SQL> select count(distinct(terminal)),username
      2  from dba_audit_session
      3  having count(distinct(terminal))>1
      4  group by username
    SQL> /
    
    COUNT(DISTINCT(TERMINAL)) USERNAME
    ------------------------- ----------
                            4 EMIL
                            3 SYS
                            3 ZULIA 
    SQL>

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

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

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

    SQL> select count(distinct(username)),terminal
      2  from dba_audit_session
      3  having count(distinct(username))>1
      4  group by terminal
    SQL> /
    
    COUNT(DISTINCT(USERNAME)) TERMIN
    ------------------------- ------
                            3 pts/1
                            2 pts/2
                            3 pts/3
                            3 pts/5
    
    SQL>

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

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

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

    Простой SQL, приведенный ниже, покажет любые сведения из журнала аудита, имеющие отношения к созданным или измененным объектам:

    col username for a8
    col priv_used for a16
    col obj_name for a22
    col timestamp for a17
    col returncode for 9999
    select  username,
            priv_used,
            obj_name,
            to_char(timestamp,'DD-MON-YYYY HH24:MI')
    timestamp, returncode from dba_audit_trail where priv_used is not null and priv_used<>'CREATE SESSION' / SQL> @check_obj.sql ZULIA CREATE TABLE STEAL_SALARY 09-APR-2003 20:07 0 PETE CREATE PROCEDURE HACK 09-APR-2003 20:42 0

    Этот пример показывает, что пользователь ZULIA создал таблицу, а пользователь PETE писал PL/SQL процедуру. Любые изменения такого рода, в производственной базе данных, должны быть исследованы. Намного более специфичные злодеяния могут быть обнаружены в отношении изменений объектов и схемы, но в целом, пользователи не должны иметь возможности менять что-либо в производственной базе данных. И как результат, проверка может остаться чисто символической.

    Защита базы данных от рассмотренных злонамеренных действий

    Рассмотренные примеры - всего лишь основа для использования возможностей аудита Oracle. Настройка аудита это один из первых шагов для обеспечения безопасности базы данных. Использование аудита должно быть частью общего плана безопасности организации, в который входит и Oracle. Следует регулярно контролировать базу данных на неправильность конфигурации или наличие вновь обнаруженных уязвимостей, которые могут стать брешью в информационной безопасности системы.

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

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

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

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

    Последняя книга автора выпущенная SANS Institute “Безопасность Oracle шаг за шагом- руководство выживания для службы безопасности Oracle ”("Oracle security step- by-step - A survival guide for Oracle security" ) дает отличное руководство как сконфигурировать Oracle безопасным.

    Заключение

    Аудит Oracle очень мощное средство и иногда кажется довольно сложным. Как мы увидели во вступлении, существует более чем одна опция доступная для аудита базы данных Oracle. В СУБД Oracle существует возможность контролировать почти все с помощью стандартных команд, но не на строковом уровне. Если вам необходим высоко-уровневый аудит используйте стандартные функции что бы посмотреть общую активность, и затем рассмотреть исследуйте нужное в более мелких деталях.

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

    Для более детального аудита, используйте триггеры базы данных и мелко-уровневый(fine grained) аудит. Помните, что для использования и реализации этих методов необходим опыт программирования, так что они должны быть внимательно рассмотрены. Много полезной информации может быть собрано без аудита, на строковом уровне. Кроме всего прочего, внедрите принцип наименьших привилегий, что бы избегнуть изменений и чтений данных пользователями, для которых они не предназначены.

    Ссылки

    • Oracle security step-by-step -A survival guide for Oracle security, Pete Finnigan 2003, published by SANS Institute
    • Oracle security handbook - Aaron Newman and Marlene Theriault, published by Oracle Press.

    Pete Finnigan - автор ранее изданной книги "Oracle security step-by-step - A survival guide to Oracle security" опубликованную в 2003 институтом SANS (см. http://store.sans.org). Pete Finnigan - основатель и CTO PeteFinnigan.com Limited ( http://www.petefinnigan.com), компании в UK, которая специализируется по вопросам безопасности Oracle.
     


    ХАЙВЕЙ - лучший российский хостинг-провайдер: хостинг, регистрация доменов, услуга Ваша@почта, поддержка 24 часа


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


    STSS - известный поставщик надежных серверных решений различного назначения на платформе Intel (Xeon) и AMD.


    5-55: the ITIL company. Практический опыт и теоретические знания на лучших семинарах по ITIL и процессам ITSM.


    Подписка на новости IT-портала CITForum.ru
    (библиотека, ftp-архив CITKIT.ru)

    Новые поступления в on-line библиотеку:

    28 апреля

  • Выбор первого дистрибутива Linux: Пособие для начинающих
  • Обфускация и защита программных продуктов
  • Анализ и оптимизация циклов с помощью производящих функций
  • Стратегии объектно-реляционного отображения: систематизация и анализ на основе паттернов

    26 апреля

  • Business Intelligence обещает значительный рост в 2005 году
  • Десять основных тенденций 2005 года в области Business Intelligence и Хранилищ данных
  • Управление эффективностью бизнеса и предсказуемость
  • Увеличение эффективности бизнеса: пять ошибок управления, которых следует избегать
  • Потребность в организационных данных: модель комплексного управления эффективностью бизнеса
  • Технология Хранилищ данных для государственных учреждений
  • Оцените, насколько совершенно ваше Хранилище данных

    21 апреля

  • Исполнение моделей при помощи виртуальной машины
  • Параллельные алгоритмы компьютерной алгебры
  • От стандарта до стандарта (о стандартизации оптических разъемов)
  • За штурвалом IP-станции

    Продолжение дискуссии читателей:

  • Линукс и пользователи, или что мне не нравится в Linux
  • Еще один взгляд на альтернативные ОС (и софт для них)
  • О некомпетентности пользователя Windows
  • Переписка Долгачева В.С. и Монахова В.В.

    19 апреля

  • Межпротокольный шлюз NAT-PT с функциями DNS-ALG и FTP-ALG для обеспечения взаимодействия между сетями IPv4 и IPv6
  • Рефакторинг архитектуры программного обеспечения: выделение слоев
  • Комбинаторика слов и построение тестовых последовательностей
  • Функциональное тестирование Web-приложений на основе технологии UniTesK

    14 апреля

  • Как организовать двойную парольную защиту данных в Oracle
  • Деревянный интерфейс

    Продолжение дискуссии читателей:

  • Microsoft против мира
  • Впечатления от прочитанного

    12 апреля

  • Крупные проблемы и текущие задачи исследований в области баз данных
  • Глава 2 из книги Т.Кайта "Oracle для профессионалов"Архитектура

    Дискуссия читателей о Linux и Windows:

  • Деньги правят миром, и у кого их больше, тот и прав!
  • О злокозненности некомпетентных пользователей, или почему я не люблю ограниченных пользователей Windows

    7 апреля

  • О доблести Билла Гейтса, или почему Windows лучше, чем LINUX или Mac OS
  • Витая пара - все ли так просто?!
  • Выбираем сервер печати
  • Один слой хорошо, а два - лучше (о пишущих DVD-приводах)

    5 апреля

  • Использование Caché SQL Gateway
  • Глава 19 из книги Т.Кайта "Oracle для профессионалов"Хранимые процедуры на языке Java
  • Что такое PostgreSQL?
  • Обновлен PostgreSQL FAQ

    31 марта

  • Использование Веб-сервисов в Caché
  • Защита на уровне строк (Oracle)
  • Секции в реальном мире

    29 марта

  • Разработка успешных приложений для Oracle - первая глава из книги Тома Кайта "Oracle для профессионалов"
  • Web-сервисы: растущие опасения (мнение аналитиков IDC)
  • Технология OLAP - мощная альтернатива электронным таблицам
  • Какой модной стала подготовка отчетности

    24 марта

  • Многоверсионность данных и управление параллельными транзакциями
  • Исключение из правил. Опыт разработки и внедрения финансовой корпоративной системы
  • Обнаружение компрометаций ядра Linux с помощью gdb
  • Корпоративная сервисная шина - "бюджетный" подход к решению задач интеграции
  • Сервис-ориентированная архитектура
  • Бизнес-процессы и XML

    22 марта

  • Доступно. И точка! (обзор точек беспроводного доступа)
  • Коммутаторы Fast/Gigabit Ethernet для "большой" сети
  • Push to Talk: нажми на кнопку и ...говори
  • Сети нового поколения и технология softswitch

    17 марта

  • Часто задаваемые вопросы о proxy (proxy FAQ)
  • Самонастраивающаяся база данных: управляемые приложения и настройка SQL
  • Еще раз о волоконных трассах
  • Настраиваем русский Unicode в FreeBSD-5.3.

    10 марта

  • Еще не сказанное о волоконной оптике
  • Wi-Fi на службе оператора
  • Пора менять платформу?
    (о сокетах LGA775 и PGA478)

    Oracle:

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

    3 марта

  • Требования к проекту. Классификация - первый шаг к пониманию
  • Gtk vs. Qt: драки не будет
  • Управление бизнесом "по максимуму": BPM для финансовых учреждений
  • Реализация решения по управлению эффективностью бизнеса
  • Новые SerialATA-винчестеры
  • Карман для сервера

    1 марта

  • Выбрать корпус - нет ничего проще?
  • Создание виртуальной сети с удаленной загрузкой узлов
  • Текущее состояние и перспективы развития рынка интеграционных технологий
  • Интеграция корпоративной информации: новое направление
  • Архитектурные подходы к консолидации

    24 февраля

  • Каждому проекту своя методология
  • Императив интеграции
  • Безопасность IP-телефонии - полевые зарисовки
  • О злокозненности Билла Гейтса, или почему я не люблю Windows

    22 февраля

  • Oracle10: шифруем данные
  • В версии Oracle10 "виртуальные частные базы данных" данных стали избирательнее
  • Каждому (пользователю) свое (данное в таблице)
    Часть 1
    Часть 2
  • Ускоряем интернет
  • Сетевая аутентификация на практике
  • В фокусе Microsoft Virtual Server 2005

    17 февраля

    Открыт новый раздел
    Все об Open Source

    Все новости >>>



  • IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы - pr@citforum.ru, тел. +7 095 4119920 Пресс-релизы - manager@citforum.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...