Файл: Служба безопасности и аутентификации баз данных (Анализ сетевой защищенности СУБД Oracle).pdf

Введение.

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

На данный момент самой распространенной версией СУБД Oracle является 9i, за ней следует 8i и 10g. Существуют версии для различных ОС, но самыми распространенными являются Windows и Linux.

Глава 1. Анализ сетевой защищенности СУБД Oracle.

1.1. Анализ безопасности TNS Listener’a.

Listener Oracle - компонент сетевого доступа к системам Oracle, который принимает клиентские запросы и направляет их для обработки в соответствующий серверный процесс. Плохо сконфигурированный незащищенный Listener предоставляет нарушителю различные способы осуществления атак. Атакой на TNS Listener можно получить детальную информацию об атакуемой системе (имена баз данных (SIDs), версию СУБД, пути к log-файлам, версию ОС, на которой установлена СУБД, переменные окружения(ORACLE_HOME, …)), произвести атаку отказа в обслуживании, выполнить SQL- команды от имени DBA, получить удаленный доступ к системе.

---

Listener Oracle контролируется утилитой lsnrctl. Утилита lsnrctl имеет команды: status, version, start, stop, set (Password, Log_file, Current_listener, Trc_status).Для осуществления атаки типа отказ в обслуживании можно также использовать утилиту lsnrctl. С помощью команды stop удаленный неавторизированный пользователь может остановить TNS Listener.

Для того, чтобы защитить TNS Listener нужно использовать следующие параметры: PASSWORD –этот параметр отвечает за установку пароля на подключение к TNS Listener’у . В том случае , если пароль установлен, выполняются только команды status и version, что дает информацию о версии Listener’a, установочной директории и операционной системе (по умолчанию не установлен), ADMIN_RESTRICTIONS – этот параметр во включенном состоянии запрещает любые изменения конфигурационного файла удаленно (по умолчанию установлен в OFF), LOCAL_OS_AUTHENTICATION – этот параметр во включенном состоянии позволяет управлять TNS Listener’ ом только локально, (по умолчанию установлен в OFF до версии 10g).

Первое и самое главное – это установить пароль на доступ к Listener’у, а так же включить протоколирование всех попыток подключения к Listener’у для обнаружения попыток перебора паролей, установить последние обновления безопасности (CPU) и защитить локальные конфигурационные файлы.

1.2. Подключение к СУБД.

Обычно в СУБД для идентификации и проверки подлинности пользователей применяются либо соответствующие механизмы операционной системы, либо SQL-оператор CONNECT. В случае СУБД Oracle оператор CONNECT имеет следующий вид: CONNECT пользователь[/пароль] [@база_данных];

Так или иначе, в момент начала сеанса работы с сервером баз данных, пользователь идентифицируется своим именем, а средством аутентификации служит пароль. Детали этого процесса определяются реализацией клиентской части приложения.
Обратим внимание на следующее обстоятельство. Некоторые операционные системы, такие как UNIX, позволяют во время запуска программы менять действующий идентификатор пользователя. Приложение, работающее с базой данных, как правило, имеет привилегии, значительно превосходящие привилегии обычных пользователей. Естественно, что при этом приложение предоставляет тщательно продуманный, строго фиксированный набор возможностей.

Для подключения к СУБД Oracle необходимо знать IP- адрес сервера, порт TNS Listener’a, имя базы данных (SID), имя пользователя и пароль.

Подобрать имя базы данных (SID) можно поиском информации в сторонних приложениях, например Oracle Application Server (порт 1158), SAP web-management (порт 8001/tcp). Так же имя базы данных может быть стандартным, например «ORCL», состоять из малого количества символов, являться словарным словом, частично или полностью совпадать с DNS/NETBIOS – именем хоста, а так же его можно узнать по ссылке из другой СУБД.

---

Подбор SID – первое, что обычно предпринимают в случае, если стандартным способом получить SID не удалось.

1.3. Подбор SID по словарю.

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

При подборе SID по словарю решающее значение имеет скорость. С этой целью было проведено два теста по измерению скорости работы приведенных выше утилит (Таблица «Результаты сравнения скоростей работы утилит по перебору SID»):

– Первый тест – замер времени перебора списка стандартных SID (~600 слов);

– Второй тест – замер времени подбора известного SID “ORCL” методом полного перебора

Утилита	Скорость перебора	Время проверки по списку стандартных SID	Время перебора SID “ORCL”
Ora‐brutesid	90 SID/сек	Опция не реализована	114 минут
Ora‐getsid	88 SID/сек	7 сек.	Опция не реализована
Oscanner	80 SID/сек	8 сек.	Опция не реализована
Sidguesser	71 SID/сек	10 сек	Опция не реализована
Sidguess	11 SID/сек	58 сек.	Программа не смогла завершить работу

. Таблица «Результаты сравнения скоростей работы утилит по перебору SID»

Исходя из результатов полученных тестов, наилучшие результаты по подбору по словарю показала утилита Ora‐getsid, а наихудшие результаты по перебору по словарю показала утилита sidguess.

1.4. Подбор SID методом полного перебора (Brute force).

В случае если подбор по словарю не дает желаемого результата, логично перейти к подбору SID методом полного перебора. Что касается скорости подбора методом полного перебора, то наилучшие результаты показала утилита ora brutesid. С помощью нее все 4символьные SID можно перебрать примерно за 3 часа; в случае если SID содержит 5 символов, то его придется перебирать порядка 3-х суток, что вполне осуществимо.

По проведенным тестовым запускам утилиты ширина пропускного канала незначительно влияет на скорость перебора, так как основное время занимает инициализация соединения. Учитывая эти особенности, можно запустить параллельно несколько экземпляров утилиты на разные СУБД.

Статистика проведения тестов на проникновение в крупных компаниях показывает: в 13% случаев SID является стандартным, в 19% – состоит из 3-х и менее символов и в 34% случаев – из 4-х символов.

---

Распределение стойкости SID

Таким образом, в среднем в 2-х случаях из трех (66%) возможно получение SID базы данных, для чего потребуется не более 3-х часов (время перебора всех 4-х символьных значений). Если учитывать возможность перебора SID по словарю, то вероятность увеличивается.

Существуют сервлеты, на которые нет ссылок с главной страницы. Один из таких сервлетов – это сервлет Spy, который можно использовать для получения SERVICE_NAME базы данных. Для этого необходимо обратиться напрямую к этому сервлету по ссылке http://hostname:5560/servlets/Spy, в результате чего в одной из вкладок мы можем получить SERVICE_NAME базы данных.

SID через Application Server , SID через Application Server 2, в 90% случаев SID можно легко подобрать( SID подбором), SID подбором.

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

Получение SID, имея учетную запись в ОС, на которой установлена СУБД; Получение SID, имея учетную запись на FTP сервере в ОС, на которой установлена СУБД; Получение SID, имея учетную запись в MsSQL сервере в ОС, на которой установлена СУБД.

Все предельно просто в случае, если пользователь, под именем которого мы подключились к серверу, имеет права на чтение файлов из директории ORACLE_HOME/NETWORK/admin, т.к. SID можно получить из конфигурационного файла tnsnames.ora. Этот файл предназначен для определения сетевого имени сервиса, по которому можно обращаться к БД, и хранит такие данные, как SID или SERVICE_NAME базы данных.

1.5 Получение SID при наличии учетной записи на ftp сервере.

В случае если у нас нет аккаунта, предоставляющего удаленный доступ на атакуемый сервер, но есть аккаунт на доступ к ftp‐сервису, установленному на этот сервер, то это дает возможность получения SID в случае, если ftp‐аккаунт имеет доступ на чтение на директорию $ORACLE_HOME.

Для получения SID мы можем прочитать файл tnsnames.ora, как указано в предыдущем разделе. Если доступ на чтение этого файла запрещен, что часто рекомендуется в документах по защите СУБД Oracle, то SID можно получить через список директорий. В различных версиях СУБД пути несколько отличаются. Ниже будут приведены три пути, по которым можно найти SID базы данных на примере СУБД Oracle 10g R2.

Первый способ – это вывести список директорий папки ORACLE_HOME\..\admin\:

C:\oracle\product\10.2.0\oradata >dir. Том в устройстве C не имеет метки.

Серийный номер тома: 8CFF-37FB Содержимое папки C:\oracle\product\10.2.0\admin

---

Название директории ORCL102 в данном случае является SIDом базы данных.

Второй способ – это вывести список директорий папки $ORACLE_HOME\..\oradata\:

C:\oracle\product\10.2.0\oradata>dir. Том в устройстве C не имеет метки.

Серийный номер тома: 8CFF-37FB Содержимое папки C:\oracle\product\10.2.0\oradata

Название директории ORCL102 в данном случае является SIDом базы данных.

И третий способ – вывести список директорий папки $ORACLE_HOME, содержащий папку, в названии которой будет фигурировать IP‐адрес сервера и SID, разделенные символом нижнего подчеркивания.

Содержимое папки E:\oracle\product\10.2.0\db_1 28.01.2008 17:30 <DIR> admin 28.01.2008 17:30 <DIR> assistants 19.06.2008 16:53 <DIR> BIN В данном случае SIDом базы данных является строка ORCL102.

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

• Сменить SID баз данных на случайный набор из не менее 8 символов
• Максимально ограничить доступ к файлам tnsnames.ora, оставив права на чтение лишь пользователю от имени которого запускается СУБД
• Ограничить доступ к системам через которые можно узнать SID, или модифицировать информацию, выводимую этими системами

1.6 Парольная политика.

Парольная политика СУБД может иметь следующие слабые стороны:

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

Некоторые не блокируются после установки. Множество приложений которые

интегрируются с СУБД имеют свои стандартные системные учетные записи.

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

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

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

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

С хранением и передачей пароля связаны основные проблемы:

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

---