Порт 1521 oracle для чего

Review this information for port numbers and protocols used by components that are configured during the installation. By default, the first port in the range is assigned to the component, if it is available.

Table E-1 Ports Used in Oracle Components

The port number is assigned automatically during installation. You cannot view or modify it afterward.

Cluster Synchronization Service daemon (CSSD)

The Cluster Synchronization Service (CSS) daemon uses a fixed port for node restart advisory messages.

This port is used on all interfaces that have broadcast capability. Broadcast occurs only when a node eviction restart is imminent.

Grid Plug and Play (GPNPD)

GPNPD provides access to the Grid Plug and Play profile, and coordinates updates to the profile among the nodes of the cluster to ensure that all of the nodes have the most recent profile.

Multicast Domain Name Service (MDNSD)

The mDNS process is a background process on Linux and UNIX, and a service on Windows, and is necessary for Grid Plug and Play and GNS.

Oracle Cluster Registry

The port number is assigned automatically during installation. You cannot view or modify it afterward.

Oracle Clusterware Daemon (CRSD)

Oracle Clusterware daemon internode connection. The port number is assigned automatically during installation. You cannot view or modify it afterward.

Oracle Connection Manager

Listening port for Oracle client connections to Oracle Connection Manager. You can configure Oracle Connection Manager after installation using NETCA.

Quality of Management Service (QOMS) Server

The CRS Agent uses port 8888 locally to manage the lifecycle of the container.

Quality of Management Service (QOMS) Server

Port for the Quality of Management Service server.

Oracle Data Guard

Shares the Oracle Net listener port and is configured during installation. To reconfigure this port, use Oracle Net Configuration Assistant (NETCA) to reconfigure the listener.

1521 (same value as the listener)

modifiable manually to any available port

Oracle Event Manager (EVM)

Generates events for Oracle Clusterware. The port number is assigned automatically during installation. You cannot view or modify it afterward.

Oracle Grid Interprocess Communication (GIPCD)

A support daemon that enables Redundant Interconnect Usage.

Oracle Grid Naming Service (GNSD)

The Oracle Grid Naming Service daemon performs name resolution for the cluster.

Oracle Grid Naming Service (GNSD)

The Oracle Grid Naming Service daemon performs name resolution for the cluster.

Oracle HA Services daemon (OHASD)

The Oracle High Availability Services (OHAS) daemon starts the Oracle Clusterware stack.

Oracle Net Listener

Allows Oracle clients to connect to the database by using Oracle Net Services. You can configure this port during installation. To reconfigure this port, use NETCA.

Port number changes to the next available port.

Modifiable manually to any available port.

Oracle Notification Services (ONS)

Port for ONS, used for the publish and subscribe service for communicating information about Fast Application Notification (FAN) events. The FAN notification process uses system events that Oracle Database publishes when cluster servers become unreachable or if network interfaces fail.

Use srvctl to modify ONS ports.

Oracle Real Application Clusters

The port number is assigned automatically during installation. You cannot view or modify it afterward.

Oracle Services for Microsoft Transaction Server

The port number for Microsoft Transaction Server is configured automatically by Oracle Universal Installer (OUI) the first time you install the software on a particular server. If you install the software in multiple Oracle homes on the same server, then OUI uses the same port number for all installations.

In most cases, you do not have to reconfigure the port number.

Oracle XML DB — FTP

The Oracle XML DB FTP port is used when applications must access an Oracle database from an FTP listener. The port is configured during installation and you cannot view it afterward.

Oracle XML DB — HTTP

The Oracle XML DB HTTP port is used if web-based applications must access an Oracle database from an HTTP listener. The port is configured during installation, and you cannot view it afterward.

Oracle XML DB Developer’s Guide for information about changing Oracle XML DB FTP port number.

Oracle XML DB Developer’s Guide for information about changing Oracle XML DB HTTP port number.

«Changing the Oracle Services for Microsoft Transaction Server Port» for information about changing Oracle Services for Microsoft Transaction Server port number.

Атака на оракула. Подробный гайд по векторам атак на Oracle DB

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

Внешний периметр. The listener is under attack

Кто хоть раз сталкивался с этой базой данных, знает, что взаимодействие с Oracle RDBMS осуществляется через TNS Listener. Listener — это своего рода балансировщик подключений. По умолчанию listener слушает 1521-й TCP-порт (в «будущем» Oracle обещает перейти на 2483 и 2484/SSL) и разруливает входящие подключения в зависимости от того, какая запрошена БД, что, соответственно, позволяет работать с несколькими. Идентификация конкретной базы данных происходит на основании буквенно-цифровой строки — ее SID’а (System IDentifier). Есть также понятие SYSTEM_NAME, которое чаще всего можно воспринимать как аналог SID (с пентестерской точки зрения, конечно).

Именно с атак на службу listener, как правило, начинается пентест базы данных Oracle. С задачей нахождения и определения версии СУБД отлично справляется Nmap. Но первым делом для нас важно получение SID для подключения к «листенеру», ведь без него listener не станет с нами общаться. На эту тему Sh2kerr когда-то написал отличное исследование Different ways to guess Oracle database SID.

К основным методам получения SID можно отнести перебор типовых значений для конкретной платформы, так как SID может быть дефолтным. Например, ORCL — по умолчанию для обычного Oracle, XE — для версии Oracle Express Edition. Также SID может быть получен через сторонние ресурсы. Например, веб-интерфейс EM-консоли на 1158-м порту; через SAP web_appserver, XDB и прочие штуки, установленные поверх Oracle. Системный идентификатор можно пробрутить, так как listener при подключении возвращает различные ошибки в зависимости от того, существует такой SID или нет. К тому же есть давняя практика делать короткие идентификаторы (3–4 символа). При переборе не стоит забывать про название компании, название системы, имена хостов и прочие социальные аспекты. С последней задачей весьма эффективно справляется модуль из Метасплоита auxiliary/scanner/oracle/sid_brute. Для атаки достаточно указать IP-адрес удаленного хоста. Это весьма неплохая брутилка сидов, она имеет встроенный словарик на 600 типовых значений.

Кстати, встретить Oracle версии ниже 10.0 — настоящий праздник для пентестера. Listener одной из старых версий с настройками по умолчанию раскрывает все что можно, включая обслуживаемые SID, версию СУБД, тип ОС, и имеет еще ряд важных уязвимостей (здесь и далее мы используем утилиту lsnrtctl, которая входит в комплект Oracle):

Disclose: используя протокол TNS, можно отправить «листенеру» команды STATUS или SERVICE. В первом случае, даже если установлен пароль, listener раскроет немало инфы. STATUS вернет версию ОС, аптайм, директорию лог-файла и SID. SERVICE также показывает версию ОС и SID.
DoS: можно остановить listener.
DDoS: можно поставить высокий уровень трассировки событий, что нередко создает повышенную нагрузку на процессор и съедает все свободное дисковое пространство.
DDDoS: с помощью следующих команд можно выставить некорректные настройки коннектов, что приведет к неработоспособности сервиса:
pre-RCE: возможно изменить путь до лог-файла «листенера»:
RCE! Если к предыдущему пункту добавить то, что в лог попадают все запросы, то можно провернуть такую атаку под Windows: указать путь до папки автозапуска администратора (службы Oracle работают из-под System, так что с правами проблем нет) с расширением bat и отправить такой TNS-запрос на подключение, что в лог запишется какая-то виндовая команда. Например, добавление пользователя в ОС — `net user bob /add`. Когда админ зайдет в ОС (а призвать его нам помогут предыдущие примеры с DoS или какая-нибудь социалка), то наш злой bat запустится вместе со всеми командами внутри! Кстати, все, что туда будет писать listener, окажется пропущено виндой как несуществующие команды, так что об этом можно не волноваться.

Для реальной атаки мы воспользуемся утилитой tnscmd.pl, так как lsnrctl не может посылать кастомные запросы. Первым запросом указываем в качестве лога bat в автозагрузке, вторым добавляем пользователя:

В Linux можно наделать пакостей похожим способом, например добавить свои SSH-ключи. Подробнее про эту технику можно почитать в книге А. Полякова «Безопасность Oracle глазами аудитора: нападение и защита». Кстати, часть описанных выше действий мы можем совершить и с помощью одноименного модуля в Metasploit — auxiliary/admin/oracle/tnscmd. Наконец, если уже есть удаленный доступ к серверу с БД, то можно украсть из listener.ora (это такой конфигурационный файл, он лежит в $ORACLE_HOME/network/admin) хеш пароля от «листенера». До десятой версии его достаточно для коннекта.

Еще раз подчеркну, что эти атаки актуальны лишь для Oracle до десятой версии. Начиная с «десятки», удаленная конфигурация по умолчанию запрещена. Хотя немного информации из дисклоза мы получить все-таки можем.

Внешний периметр. TNS Listener Poison

Если ты встретил версию «листенера» посвежее, то тут уже особо не разгуляться, остается только брутфорс. Впрочем, все версии, включая 12c, с настройками по умолчанию уязвимы к атаке под названием TNS Listener Poison (разновидность техники «человек посередине», MITM). Правда, 12c уязвима лишь в некоторых конфигурациях. К примеру, один из вариантов, которые могут нам помешать, — это отключение динамического конфигурирования «листенера», что невозможно при использовании Oracle DataGuard, PL/SQL Gateway с подключением в APEX и некоторых версий SAP.

Дело тут вот в чем: по умолчанию сервис «листенера» поддерживает удаленное конфигурирование, необходимое для создания кластера базы данных (RAC — Real Application Cluster). Фактически мы можем подключиться к «листенеру» и «зарегистрироваться», то есть сказать ему, что мы член кластера, на котором работает его база данных. Дальше можно ждать подключений от клиентов, которые нам будет перекидывать listener. Но не всех, а только части, потому что listener балансирует нагрузку на кластер: кого-то сразу подключит к настоящей СУБД, кого-то отправит нам. При этом для полноценной MITM-атаки никто не мешает перенаправлять подключающихся к нам клиентов обратно в СУБД. И при этом у нас будет возможность полностью контролировать передаваемый трафик: и просматривать его (данные, не считая аутентификации, не шифруются), менять команды и добавлять их.

Принцип эксплуатации уязвимости TNS Poison

Вот примерный алгоритм атаки:

Отсылаем TNS-запрос `CONNECT_DATA=(COMMAND=SERVICE_REGISTER_NSGR))`.
Уязвимый сервер ответит `(DESCRIPTION=(TMP=))`. Запатченный скажет `(ERROR_STACK=(ERROR=1194))`.
Формируем конфигурационный пакет с SID и IP нового «листенера» (нашего). Принципиальное значение имеет количество символов в имени текущего SID. Его необходимо знать, так как иначе поедет парсинг и пакет будет не «Well Formed».
Отправляем все это добро «листенеру».
Если все верно, то после этого часть новых подключений listener будет направлять на подконтрольный нам IP.

Внешний периметр. Users Brute force

Получил SID? Отлично, переходим к следующей типичной задаче — добываем учетку. С этого момента мы можем подключаться к «листенеру» и брутить учетные записи. Вообще, Oracle некогда был уязвим, и можно было сначала брутить логины, а потом пароли (та же проблема: различные ошибки для существующих и несуществующих пользователей), но имеющиеся тулзы стары и работают очень нестабильно. С классическим же перебором учеток снова выручает Metasploit и его модуль `auxiliary/scanner/oracle/oracle_login`. Он имеет встроенный словарик наиболее популярных дефолтных учеток в виде login:password. Хотя, конечно, он не покрывает всех возможных вариаций, и иногда приходиться гуглить инфу про ломаемую платформу или задумываться на тему фантазии сотрудников и снова брутить. При этом не стоит забывать, что Oracle поддерживает парольные политики и может заблокировать учетные записи.

Дефолтные записи представляют одну из самых распространенных и одновременно серьезных проблем безопасности в «Оракуле». Этих пользователей немало, они имеют различные привилегии, и некоторые из них не так-то просто отключить. Так что, проводя аудит безопасности продуктов Oracle, очень важно посмотреть в документации список учетных записей по умолчанию. Причем если в «чистой» Oracle DB подобных записей не так много, то, если на нее поставить ERP-систему вроде E-Business Suite, их становится около 300! Для более тщательного, но и длительного брутфорса советую обратиться к Nmap:

Учти, что этот скрипт перемешивает логины и пароли, то есть к каждому логину пробует каждый пароль, а это довольно долго!

Внешний периметр. Remote OS Auth

Несколько более изящный способ добыть себе учетку от базы — обойти проверку. Но это сработает, только если в тестируемой системе используется `Remote OS Auth`. Суть в том, что в Oracle RDBMS есть возможность перекладывать аутентификацию пользователя на плечи ОС. Таким образом, если пользователь аутентифицирован в ОС, то подключение к БД произойдет без проверки пароля. Логины таких пользователей в базе имеют префикс ops$ (например, ops$Bob). Причем эта функция работает и с удалёнными хостами. Таким образом, для атаки мы должны подключиться к «листенеру» с именем юзера и «сказать», что пароль проверен в ОС, так что нас можно пустить. Listener поверит и пустит :). Несмотря на кажущуюся странность, такой метод используется для связки SAP-систем c Oracle в качестве основного. Значит, практическая последовательность такова:

Узнать подобную учетную запись (например, для SAP она «рассчитывается» по известному алгоритму).
Создать такую учетку ОС у себя на машине.
Подключиться к СУБД, используя стандартные средства.

Проверка на remote auth. Вводим в SQL-терминале:
Включение r.auth (если FALSE):
Создание юзера EVIL с префиксом ops:
Выдача прав:

Кстати, пароль у пользователя в ОС и пароль у пользователя Oracle DB может отличаться, это ни на что не влияет.

На ZeroNights 2015 Роман Бажин (@nezlooy) поделился интересным наблюдением: оказалось, что в момент отправки пакета с запросом на авторизацию **можно подменить значение текущего пользователя**, а следовательно, можно устроить перебор. Сработает такая атака явно быстрее, нежели прямой брутфорс учеток, ведь нужно проверить лишь логины, без паролей. Подробнее про Remote OS Auth можно почитать тут и тут.

Внешний периметр. Remote stealth pass brute force

Еще одна серьезная уязвимость, которая была в Oracle RDBMS, — возможность удаленно получить хеш-пароль любого пользователя, а потом его локально пробрутить. К данной технике уязвимы версии 11.1.0.6, 11.1.0.7, 11.2.0.1, 11.2.0.2 и 11.2.0.3. Для того чтобы понять суть уязвимости, нужно рассмотреть, как работает протокол аутентификации с СУБД для одиннадцатой версии (маньяки из Oracle в каждой новой ветке меняют протокол аутентификации). Взаимодействие с сервером происходит по следующей схеме:

Клиент подключается к серверу и отправляет имя пользователя.
Сервер генерирует идентификатор сессии (`AUTH_SESSKEY`) и шифрует его, используя AES-192. В качестве ключа применяется хеш SHA-1 от пароля пользователя и добавляемой к нему соли (`AUTH_VFR_DATA`).
Сервер отправляет зашифрованный идентификатор сессии и соль клиенту.
Клиент генерирует ключ, хешируя свой пароль и полученную соль. Используя данный ключ, клиент расшифровывает данные сессии, полученные от сервера.
На основе расшифрованного идентификатора сессии сервера клиент вырабатывает новый общий ключ, который используется в дальнейшем.

Через Wireshark перехватить стартовый трафик при авторизации. Поможет фильтр tns.
Вытащить HEX-значения AUTH_SESSKEY, AUTH_VFR_DATA.
Подставить их в PoC-скрипт, который побрутит по словарю.

Внутренние атаки. Remote Code Execution

Так уж вышло, но добиться исполнения команд операционной системы в Oracle не так тривиально, как вызвать xp_cmdshell в MS SQL, даже если имеются привилегии DBO. Однако есть как минимум два отличных способа выполнения команд — использование Java-процедур и применение пакета DBMS_SCHEDULER. Кстати говоря, получить RCE можно и в случае нахождения SQL-инъекции в веб-приложении, разумеется, если у пользователя, от имени которого оно запущенно, хватает прав. Настоятельно рекомендую на данном этапе подготовить утилиту Oracle Database Attacking Tool ODAT. Не забудь установить необходимые библиотеки Python для работы с Oracle, а также сам Instant Client.

Итак, представим, что мы имеем админскую учетку. Весьма популярный способ исполнить свою команду на сервере в данном случае — написать процедуру `java stored`. Делается это в три этапа. Первый — создание Java-класса с именем oraexec. Для этого подключаемся через терминал sqlplus и пишем:

Далее напишем PL/SQL-обертку для этого класса:

Все! Теперь для выполнения достаточно отправить следующий запрос:

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

Внутренние атаки. Scheduler

Следующий способ, который выручит нас в случае отсутствия виртуальной машины Java (что свойственно Oracle Express Edition/XE), — это обращение к встроенному планировщику заданий Oracle `dbmsscheduler`. Для работы с ним необходимо иметь привилегию `CREATE EXTERNAL JOB`. Вот пример кода, который записывает строку 0wned в текстовый файл в корне диска C:

В результате будет создано, а затем исполнено задание по выполнению нашей команды. Еще один интересный момент заключается в том, что в основном multi-statement-запросы (то есть сложные запросы, состоящие из простых, разделенных точкой с запятой) не разрешены при работе с Oracle из внешних (то есть работающих через jdbc) приложений. Но есть такие процедуры, внутри которых можно исполнять «новые запросы», в том числе и multi-statement.

Пример такой процедуры — `SYS.KUPP$PROC.CREATE_MASTER_PROCESS`. Скажем, просто используя планировщик RCE, нельзя провести SQL-инъекцию, так как для нее требуется создание анонимной процедуры. А вот вместе с указанной выше процедурой уже можно. Таким образом, следующий запрос теоретически можно выполнить и в случае SQL-инъекции в веб-приложении.

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

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

Внутренние атаки. External tables

В качестве последнего способа добиться OS command execution я бы хотел описать внешние таблицы (External Tables). Этот же способ поможет далее скачивать файлы с сервера. Нам потребуются следующие привилегии:

UTL_FILE;
CREATE TABLE;
закрепленная за пользователем директория.

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

Шаг второй: создать исполняемый bat-файл с нужной нам командой:

Шаг третий: подготовим внешнюю таблицу `EXTT`, она нужна для запуска файла:

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

Терминал начнет выкидывать ошибки о невозможности сопоставить таблицу и вызываемый файл. Но в данном случае это неважно, ведь нам было нужно, чтобы открылся исполняемый файл, это и произошло. Утилита ODAT.py тоже умеет выполнять данную атаку, однако требует привилегию `CREATE ANY DIRECTORY` (она по умолчанию есть только у роли DBA), поскольку пытается исполнить файл из любой, а не из «нашей» директории:

Внутренние атаки. Работа с файловой системой

Переходим к задачке о чтении и записи файлов. Если необходимо просто считать файл или записать его на сервер, то можно обойтись и без Java-процедур, которые, впрочем, тоже справляются с такого рода тасками. А обратимся мы к пакету `UTL_FILE`, который обладает требуемым функционалом работы с файловой системой. Приятная новость — по умолчанию доступ к нему имеют все пользователи, обладающие ролью `PUBLIC`. Плохая новость — по умолчанию у этой процедуры нет доступа ко всей файловой системе, только к заранее заданному администратором каталогу. Впрочем, нередко встречается заданный параметр каталога *, что буквально означает «доступ ко всему». Уточнить это поможет следующая команда:

Расширить доступ, при наличии соответствующих прав можно следующим запросом:

Наиболее короткий вариант процедуры, применяющей пакет `UTL_FILE`, я подсмотрел у Александра Полякова:

Если требуется более функциональный вариант, с возможностью записи, рекомендую погуглить скрипт под названием raptor_oraexec.sql. И по традиции, вариант с применением утилиты ODAT, который, как всегда, самый короткий:

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

Второй способ, о котором я бы хотел рассказать, — это вновь применить `External Tables`. Напомню: используя External Tables, база имеет возможность получить в режиме чтения доступ к данным из внешних таблиц. Для хакера это означает еще одну возможность выкачивания файлов с сервера, однако этот способ требует `CREATE ANY DIRECTORY` привилегию. Предлагаю сразу обратиться к ODAT, работает стабильно и быстро:

Внутренние атаки. Повышение привилегий

Повысить привилегии можно разными способами, начиная от классических переполнений буфера и патчинга DLL и заканчивая специализированными атаками для баз данных — PL/SQL-инъекциями. Тема очень обширная, в этой статье я не буду подробно останавливаться на ней, про это пишут отдельные исследования: о них можно почитать в блогах Личфилда и Финнигана. Покажу лишь некоторые из них, для общего представления. В ходе проведения тестирования советую просто обращать внимание на текущие привилегии и, уже отталкиваясь от этого знания, искать в интернете нужные лазейки.

В отличие от MS SQL, где атакующий может внедрить xp_cmdshell буквально сразу после SELECT, просто закрыв его, Oracle RDBMS такие фокусы категорически не любит. По этой причине классические SQL-инъекции нам не всегда подходят, хотя можно выкрутиться и в этом случае. Мы будем рассматривать PL/SQL-инъекции — изменение хода выполнения процедуры (функции, триггера и прочих объектов) путем внедрения произвольных команд в доступные входные параметры. (с) Sh2kerr

Для того чтобы внедрить полезную нагрузку, необходимо найти функцию, в которой входящие параметры не фильтруются. Основная идея атаки заключается в следующем: по умолчанию, если не указано иного, процедура выполняется от имени владельца, а не запустившего ее пользователя. Иными словами, если нам доступна для выполнения процедура, принадлежащая учетке `SYS`, и мы сможем внедрить в нее свой код, то наш пейлоад тоже исполнится в контексте учетной записи `SYS`. Так бывает не всегда, встречаются и процедуры с параметром authid current_user, а это означает, что процедура будет исполнена с привилегиями текущего пользователя. Впрочем, обычно под каждую версию СУБД можно найти функции, уязвимые к PL/SQL-инъекции.

Упрощенный вид PL/SQL Injection

Короче говоря, вместо ожидаемого честного аргумента мы передаем зловредный код, который становится частью процедуры. Хороший пример — это функция `CTXSYS.DRILOAD`. Она выполняется от имени `CTXSYS` и не фильтрует входящий параметр, что позволяет произвести легкий взлет до DBA:

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

Теперь можем внедрить процедуру в качестве аргумента уязвимой функции (пример для десятых версий):

В не слишком свежих версиях 10 и 11 есть приятное исключение, а точнее уязвимость, позволяющая исполнить команды на сервере, не обладая DBA-правами. Процедура `DBMS_JVM_EXP_PERMS` позволяет пользователю с привилегией `CREATE SESSION` получить права `JAVA IO`. Реализуется атака следующим образом:

Теперь, получив привилегии на вызов Java-процедур, можем достучаться до интерпретатора Windows и выполнить что-нибудь:

Полезные команды для начинающего DBA

Подключаемся к базе:

Показать SID базы:

Показать текущего юзера:

Вывести всех пользователей:

Показать таблицы, принадлежащие пользователю:

Подводим итоги

Рассмотренные векторы, разумеется, не единственные, ведь появляются и новые уязвимости, причем регулярно. Плюс для актуальных версий есть ряд уязвимостей «из коробки», которые в Oracle, похоже, не торопятся исправлять. Oracle RDBMS — мощная, но очень сложная вещь, а потому подход «не трогай, если работает» очень распространен в компаниях. Это, безусловно, помогает при взломах.

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

SQL*Net (a.k.a Oracle TNS) and firewalls…

Most vendor’s firewalls have a SQL ALG that handles SQL*Net traffic. They listen on TCP port 1521. SQL*Net is based on Oracle’s TNS protocol. The specification for this protocol is proprietary and inaccessible, but you can figure it out by reading Oracle’s docs and looking at the Wireshark dissector source code.

Essentially TNS was specified in such a way that the session on port 1521 was a “control” session of sorts. The Oracle listener process listens on this port. Once connected to this port the client requests an Oracle “service.” If the listener knows of such a service, it would send a “redirect” message back to the client with the IP and port of the process providing that service. That other process is either a dedicated server process or a “dispatcher” process that arbitrates requests to a shared server process. This second TCP connection was commonly referred to as the “data session” or “data connection.” On the firewall the ALG inspects traffic in the “control” session looking for “HOST=” and “PORT=” in order to perform NAT properly and to open pinholes. That’s all the ALG does.

However, the terms “control” and “data” are somewhat misleading. Oracle TNS isn’t like FTP. Its not really a control session. A TNS connection is just a TNS connection. There isn’t a separate port or protocol messaging for control vs data. In fact, in most cases once the redirection occurs the original connection to 1521 should be closed according to the documentation.

The default behavior has changed in more recent versions of Oracle, however. When the secondary process (dispatcher process or dedicated server process) resides on the same host as the listener process, a redirect does not occur. Instead, internal to the server, the socket handle of the connection to port 1521 is passed to the secondary process. This means there is no second TCP connection. Subsequent SQL queries and the result sets are passed over this connection. Oracle refers to this method as “bequeathing the connection” or “direct hand-off.” Many Oracle deployments are built in this fashion now.

This poses two problems for the ALGs: (1) The firewalls must inspect the packets in the “control” session looking for IPs and ports. If a large amount of data is transiting the firewall over port 1521 this could impact the CPU of the firewall. (2) The programmer’s of the ALGs tuned down the buffers of the control session (why would you need large buffers for a control session?). This negatively impacts the performance of the Oracle Session.

Cisco tunes the buffers down to 16k (this is the equivalent of the SDU paramenter in Oracle) while Juniper tunes it down to 2k. The impact is not good on an SRX therefore. Juniper did “fix” this by increasing the window in 10.4R1, but it looks like its back to being 2k in 10.4R4. Even with the the larger buffer though, if you are using a newer version of Oracle that behaves this way by default and there are a lot of sessions then why impact the CPU unnecessarily? It has to inspect those packets looking for IPs and ports. If Oracle isn’t redirecting then there is no point to this.

As it happens, both Cisco and Juniper recommend bypassing the SQL ALG when using newer versions of Oracle that behave this way. You then would only enable or disable the ALG as required by policy on a per IP/port basis.

In Checkpoint firewalls, there are two ALGs for SQL*Net: “sqlnet1” and “sqlnet2.” sqlnet1 should be used for non-redirected sessions and sqlnet2 should be used for redirected sessions. The implication is that non-redirected sessions evaluated against sqlnet2 could negatively impact the CPU of the firewall.

For Cisco firewalls you can disable the SQL*Net ALG globally and then enable it as needed per policy using policy-maps. For Juniper SRXs, it appears that you must *disable* the ALG per policy as required using a custom application configuration. It may be possible to disable it globally and then enable it per policy as with Cisco, but I believe if you disable the ALG globally on the SRX then the ALG can’t be used. Honestly, I haven’t verified this yet.

SQL*Net Version 2 TNSFrames, Redirect, and Data packets will be scanned for ports to open and addresses to NAT, if preceded by a REDIRECT TNS frame type with a zero data length for the payload.

SQL*Net Version 1 is assumed for all other cases. TNSFrame types (Connect, Accept, Refuse, Resend, Marker, Redirect, and Data) and all packets will be scanned for ports and addresses.

Note:Disable SQL*Net inspection when SQL data transfer occurs on the same port as the SQL control TCP port 1521. The security appliance acts as a proxy when SQL*Net inspection is enabled and reduces the client window size from 65000 to about 16000 causing data transfer issues.

In general TCP port 1521 is the default port to trigger the SQL ALG and is a default port assigned to SQL. If there is an Oracle application which uses the SQL port 1521 for both the Control and Data channel, then TCP port 1521 being this the signalling channel for or SQLNET ALG, each packet is sent to the CPU. Depending on the number of packets hitting the firewall we can expect the firewall to experience high CPU.

When you are sure that all SQL applications are single threaded and using only port TCP 1521 for both the Control and Data channel, then you should consider turning off SQL ALG. Otherwise, you can consider having the DBA’s to change the port for such applications to something other than 1521.

The SQL ALG is recommended when Oracle applications are multi-threaded and where they open a high range of TCP ports dynamically for data channels and TCP port 1521 is only used for the Control connection.

There is an internal note in Juniper PR524444 that indicates, essentially, that Oracle sessions that are not redirected can bypass the ALG as it is not needed. This PR was opened because of the ALG’s impact on the performance of the Oracle sessions.

About Ethan Banks

Co-founder of Packet Pushers Interactive. Writer, podcaster, and speaker covering enterprise IT. Deep nerdening for hands-on professionals. Find out more at ethancbanks.com/about.

Comments

Wow I used to do a lot of TNS network protocol analysis in the late 90s and some of my papers on this are located here on my site. Just email me for them

Mostly I was able to get more information about TNS from oracle directly when escalating an issue. plus there is a good book called Oracle Networking from Oracle Press. dated but good.

Ora 15xxs etc full table scans et. al. Most of the problems I analyzed were not network related but SQL related. Poor SQl programming, invalid use of cursors, LOV processing etc over wan links made the application appear slow to users but it was never the network. Agilent at the time had the best TNS decodes going. 2 and 3 tier architectures analysis and table normalization, wow you bring back some memories.

“The default behavior has changed in more recent versions of Oracle, however.” Any chance you could be more specific on when you saw this default behavior occur? Which version of Oracle or a date range? We are currently troubleshooting this exact issue on some SRX5800s and your article has been a big help! Thank you!

Your Article was good help troubleshooting our Oracle issue on SRX240, issue was with big query (29K) applicaton freezed but not with small query or just -1 record from the big query also worked , port was used 1521. by disabling ALG resolved the issue.

F Managing Oracle Database Port Numbers

This appendix lists the default port numbers and describes how to change the assigned port after installation. This appendix contains the following topics:

F.1 About Managing Ports

During installation, Oracle Universal Installer (OUI) assigns port numbers to components from a set of default port numbers. Many Oracle Real Application Clusters (Oracle RAC) components and services use ports. As an administrator, it is important to know the port numbers used by these services, and to ensure that the same port number is not used by two services on your system.

Most port numbers are assigned during installation. Every component and service has an allotted port range, which is the set of port numbers Oracle RAC attempts to use when assigning a port. Oracle RAC starts with the lowest number in the range and performs the following:

Is the port used by another Oracle Database installation on the system?

The installation can be either active or inactive at the time; Oracle Database can still detect if the port is used.

Is the port used by a process that is currently running?

This could be any process on the host, including processes other than Oracle Database processes.

If the answer to any of the preceding questions is yes, then Oracle RAC moves to the next highest port in the allotted port range and continues checking until it finds a free port.

F.2 Viewing Port Numbers and Access URLS

In most cases, the Oracle Database component’s port number is listed in the tool used to configure the port. In addition, ports for some Oracle Database applications are listed in the portlist.ini file. This file is located in the directory %ORACLE_HOME %\install .

If you change a port number after installation, then it is not updated in the portlist.ini file, so you can rely on this file only immediately after installation. To find or change a port number, use the methods described in this appendix.

F.3 Port Numbers and Protocols of Oracle Components

Table F-1 lists the port numbers and protocols used by components that are configured during the installation. By default, the first port in the range is assigned to the component, if it is available.

Table F-1 Ports Used in Oracle Components

The port number is assigned automatically during installation. You cannot view or modify it afterward.

Cluster Synchronization Service daemon (CSSD)

The Cluster Synchronization Service (CSS) daemon uses a fixed port for node restart advisory messages.

This port is used on all interfaces that have broadcast capability. Broadcast occurs only when a node eviction restart is imminent.

Oracle Data Guard

Shares the Oracle Net listener port and is configured during installation. To reconfigure this port, use Oracle Net Configuration Assistant (NETCA) to reconfigure the listener.

1521 (same value as the listener)

Oracle Connection Manager

Listening port for Oracle client connections to Oracle Connection Manager. You can configure Oracle Connection Manager after installation using NETCA.

Cluster Ready Services daemon (CRSD)

Oracle Clusterware Cluster Ready Services (CRS) daemon internode connection. The port number is assigned automatically during installation. You cannot view or modify it afterward.

Oracle Cluster Registry

The port number is assigned automatically during installation. You cannot view or modify it afterward.

Oracle EM Database Control — HTTP

HTTP port for Oracle Enterprise Manager Database Control. The port is configured during installation. Section F.5, «Changing the Oracle Enterprise Manager Database Control Ports» explains how to modify this port number.

Oracle EM Database Control — Java RMI

Java Remote Method Invocation (RMI) port for Oracle Enterprise Manager Database Control. The port is configured during installation. Section F.5, «Changing the Oracle Enterprise Manager Database Control Ports» explains how to modify this port number.

Oracle EM Database Control — JMS

Oracle Java Message Service (JMS) port for Oracle Enterprise Manager Database Control. The port is configured during installation. Section F.5, «Changing the Oracle Enterprise Manager Database Control Ports» explains how to modify this port number.

Oracle Event Manager (EVM)

Generates events for Oracle Clusterware. The port number is assigned automatically during installation. You cannot view or modify it afterward.

Oracle HA Services daemon (OHASD)

The Oracle High Availability Services (OHAS) daemon starts the Oracle Clusterware stack.

Oracle Management Agent

HTTP port for Oracle Management Agent, which is part of Oracle Enterprise Manager. The port is configured during installation.

Oracle Net Listener

Allows Oracle clients to connect to the database by using Oracle Net Services. You can configure this port during installation. To reconfigure this port, use NETCA.

Oracle Notification Services (ONS)

Use srvctl to modify ONS ports.

Oracle Real Application Clusters

The port number is assigned automatically during installation. You cannot view or modify it afterward.

Oracle Services for Microsoft Transaction Server

In most cases, you do not have to reconfigure the port number. Section F.7, «Changing the Oracle Services for Microsoft Transaction Server Port» explains how to change this port number.

Oracle XML DB — HTTP

The Oracle XML DB HTTP port is used if web-based applications must access an Oracle database from an HTTP listener. The port is configured during installation, and you cannot view it afterward.

Oracle XML DB — FTP

The Oracle XML DB FTP port is used when applications must access an Oracle database from an FTP listener. The port is configured during installation, and you cannot view it afterward.

F.4 Changing the Oracle Management Agent Port

To find the current setting for the Management Agent port, search for EMD_URL in the file %ORACLE_HOME%\ host_sid \ sysman \ config \ emd.properties , where host_sid is a string that contains the local host name and the SID for the Oracle RAC database.

To change the Management Agent HTTP port, use the emca -reconfig ports command, as shown in this example:

F.5 Changing the Oracle Enterprise Manager Database Control Ports

To find the current HTTP, RMI, and JMS port settings, search in the following files, where host_sid is a string that contains the local host name and the SID for the Oracle RAC database:

HTTP port : Search for REPOSITORY_URL in the %ORACLE_HOME%\ host_sid \ sysman \ config \ emd.properties file

RMI port : Search for the port attribute in the rmi-server tag in the file %ORACLE_HOME%\ oc4j \ j2ee \ OC4J_DBConsole_ host_sid \ config \ rmi .xml file

JMS port : Search for the port attribute in the jms-server tag in the %ORACLE_HOME%\ oc4j \ j2ee \ OC4J_DBConsole_ host_sid \ config \ jms .xml file

To change the Oracle Enterprise Manager Database Control ports, use the emca -reconfig ports command:

In the previous example, option specifies one or more of the following ports and setting is the new port value:

Option	Description	Example
DBCONTROL_HTTP_PORT	Sets the HTTP port	emca -reconfig ports -DBCONTROL_HTTP_PORT 1820
RMI_PORT	Sets the RMI port	emca -reconfig ports -RMI_PORT 5520
JMS_PORT	Sets the JMS port	emca -reconfig ports -JMS_PORT 5521

You can specify multiple port settings in one line, for example:

F.6 Changing the Oracle XML DB Ports

By default, the FTP and HTTP (including HTTPS) ports for Oracle XML DB are set to 0, which disables FTP or HTTP access to Oracle XML DB. To change the FTP and HTTP ports for Oracle XML DB, you must run the catxdbdbca.sql script, which in a default installation is located in %ORACLE_HOME%\rdbms\admin .

To change the Oracle XML DB ports:

Check that the Oracle listener is running. In the Windows Services Control Manager, ensure that the Oracle listener service (for example, OracleOraDb11g_home1TNSListener ) is set to Started.

Run the catxdbdbca.sql script.

For example, assuming your Oracle home is located in the C:\app\oracle\product\11.2.0\db_1 directory, to use 2200 for the FTP port and 8200 for the HTTP port, you would enter the following SQL statement:

Oracle Database Administrator’s Guide for information about connecting to the database using SQL*Plus

F.7 Changing the Oracle Services for Microsoft Transaction Server Port

In most cases, you are not required to reconfigure the port number for the Oracle Services for Microsoft Transaction Server. If you must change the port number, then you can use the Registry Editor to edit its value in the HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\OracleMTSRecoveryService\Protid_0 Windows Registry key to any available port within the range 1024 to 65535.

During installation, Oracle Universal Installer takes the value for the port from the key, if it exists. Otherwise, a free port ranging from 49152 to 65535 is chosen automatically.

Порт 1521 oracle для чего