Oracle АНТИХАКЕР - на дальних подступах
В этом разделе будет рассмотрена последовательность действий администратора СУБД Oracle по выявлению слабых мест в организации защиты от потенциального злоумышленника. Как обычно, любая защита от несанкционированного доступа не может быть нормально организована без имитации возможных угроз администратором БД и проверке действенности предпринятых мер защиты. Соответственно, любому способу защиты всегда противостоит соответствующий способ нападения. Законность применения тех или иных способов, программ, мероприятий остается целиком на ответственности лиц, их применяющих, и никаким образом не относится к авторам этого сайта. По ходу изложения будут использоваться тексты, скрипты и программы, принадлежащие третьим лицам. Там, где возможно, авторство будет указываться. В случае выявления каких-либо недоразумений в этом вопросе просим сообщить авторам.
Для иллюстрации способов нападения\защиты будем рассматривать собственно сервер БД Oracle, находящийся в локальной сети, которая, в свою очередь, имеет выход в Интернет через некий шлюз. Сразу же возникают два вопроса: адекватна ли защита сервера БД от потенциальных угроз из ЛОКАЛЬНОЙ сети и насколько оправдана доступность сервера БД извне. Оба эти вопроса неразрывно связаны с общей политикой безопасности в организации и, в основном, с политикой безопасности, реализуемой системными администраторами. Доступ к БД начинается с соединения с одним из доступных сервисов, связанных с БД, какими являются как сам сервер БД, способный принимать соединения без участия процесса-слушателя, так и этот процесс - LISTENER.
В большинстве случаев параметры для соединения с сервисами Oracle указаны в файлах настроек службы NET, размещение которых может определяться значением переменной среды TNS_ADMIN (TWO_TASK) или директорией, принятой Oracle по умолчанию: %ORA_HOME%/Network/Admin на компьютерах клиентов. Как правило, пользователи-клиенты имеют доступ на чтение этих файлов, следовательно - имеют необходимую информацию для соединения с сервисами БД. Таким образом, для злоумышленников, действующих из локальной сети, проблема доступа к серверу БД в значительной степени упрощается. Еще более серьезные последствия может иметь доступ к информации о параметрах соединения с БД у клиентов, работающих с удаленных компьютеров - файлы конфигурации в их системах имеют параметры доступа через Интернет, а значит могут быть использованы любым пользователем. Еще больше усложняет ситуацию использование переносных компьютеров, в том числе PALM. Для иллюстрации серьезного положения с этой проблемой можно воспользоваться поисковой системой Google, указав в параметрах поиска значения: "filetype=ora, port = ". Эта команда выведет все доступные в настоящий момент и АРХИВИРОВАННЫЕ (не существующие уже реально) поисковой машиной файлы, имеющие расширение ORA и содержащие специфическую строку "PORT =", что характерно для файлов TNSNAMES.ORA и LISTENER.ORA как на клиентах, так и на серверах БД. Можно воспользоваться ссылкой: этой ссылкой . Результат непременно впечатлит любого скептика :) А если указать тип файла DMP и строку "exp" ? Попробуйте!
Таким образом, сохранение конфиденциальности содержимого файлов сетевой конфигурации для доступа к БД является первым рубежом защиты БД. В локальной сети средством для решения этой задачи в версиях 8.1.5 и старше может быть использование имени БД (SID) или имени сервиса (SERVICE_NAME) в качестве наименования строки соединения для клиента NET8, для чего в настройках DNS-сервера (или файле hosts) необходимо указать IP-адрес компьютера-сервера БД соответствующим SID (SERVICE_NAME) БД (А-запись) и удалить все файлы конфигурации на компьютере клиента. Аналогичное решение может быть применено при соединении через Интернет с использованием alias в DNS ISP. На сервере БД должен быть запущен и сконфигурирован прослушивание на стандартного порта LISTENER. В версии 10G LISTENER уже не требуется. Если БД настроена на работу без участия прослушивателя LISTENER, то такое решение не всегда реализуемо. Эта возможность определяется параметрами запуска БД, указанными в файле INIT.ORA на сервере БД. При невозможности конфигурации DNS-серверов для обеспечения доступа к БД единственным решением остается применение утилиты Oracle Connection Manager из дистрибутива Oracle.
Для злоумышленника, не имеющего информации о параметрах соединения с целевой БД, задача несколько усложняется: ему придется искать IP-адрес целевого хоста и порт, прослушиваемый одним из сервисов Oracle. В локальной сети защита от этой проблемы решается применением системных политик безопасности, ограничивающих права пользователей на запуск определенных приложений, и контролем за состоянием сети, в частности - за сканированием портов. Полностью оправдано применение программ, контролирующих сетевую активность на сервере БД, например, весьма эффективен продукт Kerio Server Firewall от http://www.kerio.com. В условиях удаленного доступа решающую роль на этом этапе защиты играет конфигурация шлюза, через который сервер БД обслуживает входящие запросы. Применение межсетевых экранов и NAT здесь более чем оправданно. Целесообразно изменить принятые по умолчанию порты, прослушиваемые сервисами Oracle, на интерфейсах выхода в Интернет и применить трансляцию адресов\портов на адреса внутренней сети. Номера портов следует установить таким образом, чтобы они не совпадали с номерами портов известных служб и распространенных сетевых вирусов, т.е. отсутствовали в базах данных популярных сетевых сканеров. Данная мера не предотвратит возможность обнаружения сервисов Oracle, но весьма существенно затруднит это.
Перечисленные выше мероприятия должны решаться в самом тесном взаимодействии с системными администраторами, службой внутренней безопасности и разработчиками прикладного ПО. Чем тщательнее выполняются эти действия, тем больше затрудняется злоумышленнику обнаружение сервисов Oracle и все последующие действия по проникновению в базу данных.
Тем не менее, возможности злоумышленников по поиску параметров доступа к серверам Oracle могут быть весьма значительными и поиск открытых портов в каком-то случае вполне может дать положительный результат. Для целей поиска портов, прослушиваемых сервисами Oracle, может быть использован практически любой сетевой сканер. Трактовка результатов сканирования находится целиком в ведении лица, проводившего сканирование, потому эффективность применения нестандартных номеров портов для сервисов Oracle зависит от множества субъективных факторов. Например , сетевой экран разрешает входящие соединения на порт 7890, которые транслируются на внутренний адрес, прослушиваемый LISTENER сервера БД, но сам сервис LISTENER не запущен. Сетевой сканер классифицирует в случае обнаружения данный порт как закрытый. Если сервис LISTENER запущен, порт классифицируется как открытый, но не более того. Более подробную информацию о принадлежности данного порта к сервисам Oracle может дать утилита TNSPING из комплекта Oracle. Полученный положительный ответ на запрос этой утилиты дает основание считать, что задача обнаружения сервиса Oracle выполнена. Автоматизировать применение TNSPING с применением графического интерфейса для Win32 позволяет утилита TNScaner201, обеспечивающая поиск в диапазоне адресов, в диапазоне портов и поиск по внутренней базе ранее указанных адресов\портов. Применять утилиту для свободного поиска в широких диапазонах возможно, но ввиду крайне медленной работы TNSPING, особенно при обращении к закрытым или недоступным хостам\портам , быстродействие такого поиска весьма низкое. Проверка с использованием этой утилиты предполагаемых хостов\портов в нешироких диапазонах позволяет значительно ускорить принятие решения по оценке состояния обнаруженного сервиса .
Разберем конкретный пример. Воспользуемся поисковой машиной Google, просмотрим несколько полученных в результате файлов, выберем для проверки некоторые (измененные в тексте) параметры доступа к удаленным экземплярам Oracle, передав эти параметры в утилиту TNScaner201 , и посмотрим на итог ее работы.