Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 DBA_AUDIT_TRAIL  [new]
Gibbons
Member

Откуда: Украина, Мариуполь
Сообщений: 51
Всем день добрый!

Товарищи, возник вопрос при просмотре таблички dba_udit_trail.
Есть коннекты, как бэ под SYS, но не совсем понятные.
1. USERNAME = SYS
OS_USERNAME = СИСТЕМА
USERHOST и TERMINAL = "другой наш сервак с БД"
ACTION = LOGON и LOGOFF
COMMENT_TEXT = "DBLINK_INFO: ....."
2. PRIV_USED = NULL
3. Длительность между LOGON и LOGOFF не больше секунды.
4. RETURNCODE всегда 0, причем даже если я меняю пароль SYS все-равно RETURNCODE = 0
5. DBLINK-ов с "другой нашего сервака с БД" на этот сервак под SYS-ом нет.
Я в общем-то понимаю, что это не хакеры, но вот железного объяснения тоже не нахожу.

PS
Сделал logon trigger который должен срабатывать на подключения под SYS, так вот ни одного коннекта с этой "другой БД" триггер не показал.
3 дек 15, 16:36    [18509464]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
SeaGate
Member

Откуда: Новосибирск
Сообщений: 1635
Gibbons,

Посмотрел в доступных БД.
В comment_text, кроме всего, есть часть source_global_name, вида:
(SOURCE_GLOBAL_NAME=xxx.0)

0 - это v$session.audsid удаленной БД (клиент). 0 соответствует background процессам (и internally generated SYS-sessions).
Во всех случаях, где я наблюдаю эти записи аудита, на БД есть dblink с удаленной БД (не под SYS, естественно).
Доступа нет к удаленной БД, чтобы посмотреть, какие там есть следы этого.
При этом, не во всех БД, к которым происходят соединения через dblink, есть эти сообщения.
Тоже не понятно, что это такое, сэмулировать сходу не получилось.
4 дек 15, 08:34    [18511897]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
Gibbons
Member

Откуда: Украина, Мариуполь
Сообщений: 51
SeaGate,

Да, SOURCE_AUDIT_SESSIONID=0

Что-то думаю связанно с "анатомией" коннекта и создания сессий вообще.
Для теста сделал:
create table sys.syslog (user1 varchar2(50), current_schema varchar2(50), current_user varchar2(50)) tablespace users ;

CREATE OR REPLACE TRIGGER SYS.SYS_LOGON
 AFTER LOGON
 ON DATABASE
BEGIN
  insert into sys.syslog values(user, sys_context('USERENV','CURRENT_SCHEMA'), sys_context('USERENV','CURRENT_USER'));
END;

select * from sys.syslog;
USER1      CURRENT_SCHEMA       CURRENT_USER
---------- -------------------- --------------------
TEST5S     SYS                  SYS
TEST5S     SYS                  SYS
TEST5S     SYS                  SYS
SLAVKA     SYS                  SYS
TEST5S     SYS                  SYS


Т.е. коннект я делаю под пользователем TEST5S, но при этом CURRENT_USER и CURRENT_SCHEMA = SYS
Но, когда пользователь TEST5S залогинился и у него открылся сеанс например в sqlplus получаем:
SQL> select sys_context('USERENV','CURRENT_SCHEMA') CURRENT_SCHEMA, sys_context('USERENV','CURRENT_USER') CURRENT_USER from dual;

CURRENT_SC CURRENT_US
---------- ----------
ASUPPP     ASUPPP

Видимо на начальном этапе любой коннект использует "что-то" из схемы SYS...
Но это мои догадки, какого-то хард-пруф доказательства нет.
4 дек 15, 11:13    [18512567]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
Может стендбай? Но он, по идее должен долбиться как SYSOPER
7 дек 15, 07:18    [18521859]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
dba123
Member

Откуда:
Сообщений: 1054
Gibbons
Видимо на начальном этапе любой коннект использует "что-то" из схемы SYS...
Но это мои догадки, какого-то хард-пруф доказательства нет.
А если создать отдельную
- схему SECADM
- дать права ADMINISTER DATABASE TRIGGER, CREATE SESSION
- создать там логон-триггер
то видимо
 insert into secadm.syslog values...
 select * from secadm.syslog;
USER1      CURRENT_SCHEMA       CURRENT_USER
---------- -------------------- --------------------
TEST5S     SECADM           SECADM
TEST5S     SECADM           SECADM
7 дек 15, 08:35    [18521936]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
Gibbons
Member

Откуда: Украина, Мариуполь
Сообщений: 51
Вячеслав Любомудров
Может стендбай? Но он, по идее должен долбиться как SYSOPER


Нет, не стендбай точно.
Т.е. стендбай вообще есть, но он на совсем другом серваке.
7 дек 15, 13:57    [18524243]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
Gibbons
Member

Откуда: Украина, Мариуполь
Сообщений: 51
dba123,

да, логично.
Триггер то под SYS-ом сделан, соответственно и current_user тоже будет SYS.
Но тем не менее откуда в аудите берется "недоконнект" под SYS - не понятно.
7 дек 15, 13:59    [18524261]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
dba123
Member

Откуда:
Сообщений: 1054
Gibbons,

почему непонятно?!

сделай тест как я попросил, плюс
- добавь в таблицу поля ...,sesuser varchar2(64),dts timestamp);
- в триггере добавь ...,sys_context('USERENV','SESSION_USER'),systimestamp);
- сделай 2 сессии
и проведи тест:

set timing on
в одной смотри что в syslog,
а в другой из плюса:
- честный коннект
- disconnect
- exit
- ввод неправильного пароля
- и снова правильный
7 дек 15, 15:37    [18524898]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
dba123
Member

Откуда:
Сообщений: 1054
dba123,

+ подожди еще и проверь лог
7 дек 15, 15:55    [18525045]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
SeaGate
Member

Откуда: Новосибирск
Сообщений: 1635
Gibbons,

Gibbons
Но тем не менее откуда в аудите берется "недоконнект" под SYS - не понятно.


Посмотрел, у меня это RECO (Recoverer Process).
Начал с записей в алерте:
Tue Dec 08 11:47:07 2015
Session (79,41018): RECO logon successful: Inbound connection from client
Session (79,41018): RECO logon successful: DB Logon User: RECO, Remote Machine: zyzy, Program: oracle@zyzy (TNS V1-V3), OS User: oracle

К ним есть соответствующие записи аудита:
SQL> select xmltype(cursor(select * from dba_audit_trail where timestamp=to_date('08.12.2015 11:47:07') and username='SYS')) from dual;

XMLTYPE(CURSOR(SELECT*FROMDBA_AUDIT_TRAILWHERETIMESTAMP=TO_DATE('08.12.201511:47:07')ANDUSERNAME='SYS'))
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<?xml version="1.0"?>
<ROWSET>
  <ROW>
    <OS_USERNAME>oracle</OS_USERNAME>
    <USERNAME>SYS</USERNAME>
    <USERHOST>zyzy</USERHOST>
    <TIMESTAMP>08.12.2015 11:47:07</TIMESTAMP>
    <ACTION>100</ACTION>
    <ACTION_NAME>LOGON</ACTION_NAME>
    <COMMENT_TEXT>Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=a.b.c.d)(PORT=56655)); DBLINK_INFO: (SOURCE_GLOBAL_NAME=zyzyzy.0)</COMMENT_TEXT>
    <SESSIONID>80902252</SESSIONID>
    <ENTRYID>1</ENTRYID>
    <STATEMENTID>1</STATEMENTID>
    <RETURNCODE>0</RETURNCODE>
    <EXTENDED_TIMESTAMP>08.12.2015 11:47:07.014190 +06:00</EXTENDED_TIMESTAMP>
    <INSTANCE_NUMBER>0</INSTANCE_NUMBER>
    <OS_PROCESS>13972</OS_PROCESS>
    <TRANSACTIONID>0000000000000000</TRANSACTIONID>
    <DBID>1110059808</DBID>
  </ROW>
</ROWSET>

Собрал простенький тест-кейс, который после перезапуска экземпляра воспроизводит нужные записи аудита при сбое распределенной транзакции.

+

SQL> select sysdate from dual;

SYSDATE
-------------------
08.12.2015 16:38:38

1 row selected.

SQL> 
SQL> create database link audsid0@local connect to tc identified by tc using 'userhost:1529/pdb1';

Database link created.

SQL> 
SQL> drop user tc cascade;

User dropped.

SQL> 
SQL> grant create session, create table to tc identified by tc;

Grant succeeded.

SQL> alter user tc quota 10M on users;

User altered.

SQL> 
SQL> create table tc.t as select dummy from dual;

Table created.

SQL> 
SQL> insert into tc.t@audsid0@local values ('x');

1 row created.

SQL> 
SQL> insert into tc.t values ('x');

1 row created.

SQL> 
SQL> exec for sess_rec in ( select sid, serial# from v$session where username='TC') loop execute immediate 'alter system kill session '''||sess_rec.sid||','||sess_rec.serial#||''' immediate'; end loop

PL/SQL procedure successfully completed.

SQL> 
SQL> --commit comment 'ORA-2PC-CRASH-TEST-3';
SQL> commit;
commit
*
ERROR at line 1:
ORA-02050: transaction 7.28.35253 rolled back, some remote DBs may be in-doubt
ORA-03135: connection lost contact
ORA-02063: preceding line from AUDSID0@LOCAL


SQL> 
SQL> exec dbms_lock.sleep( 5 )

PL/SQL procedure successfully completed.

SQL> 
SQL> select xmltype(cursor(select * from dba_audit_trail where username='SYS' order by timestamp desc fetch first 1 row only)) from dual;

XMLTYPE(CURSOR(SELECT*FROMDBA_AUDIT_TRAILWHEREUSERNAME='SYS'ORDERBYTIMESTAMPDESCFETCHFIRST1ROWONLY))
-----------------------------------------------------------------------------------------------------------------------
<?xml version="1.0"?>
<ROWSET>
  <ROW>
    <OS_USERNAME>os_username</OS_USERNAME>
    <USERNAME>SYS</USERNAME> 
    <USERHOST>userhost</USERHOST>
    <TIMESTAMP>08.12.2015 16:38:54</TIMESTAMP>
    <ACTION>100</ACTION>
    <ACTION_NAME>LOGON</ACTION_NAME>
    <COMMENT_TEXT>Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=::1)(PORT=45732)); DBLINK_INFO: (SOURCE_GLOBAL_NAME=db.0)</COMMENT_TEXT>
    <SESSIONID>14476031</SESSIONID>
    <ENTRYID>1</ENTRYID>
    <STATEMENTID>1</STATEMENTID>
    <RETURNCODE>0</RETURNCODE>
    <EXTENDED_TIMESTAMP>08.12.2015 16:38:54.423488 +06:00</EXTENDED_TIMESTAMP>
    <INSTANCE_NUMBER>0</INSTANCE_NUMBER>
    <OS_PROCESS>10184</OS_PROCESS>
    <TRANSACTIONID>0000000000000000</TRANSACTIONID>
    <DBID>1741832066</DBID>
  </ROW>
</ROWSET>


1 row selected.

alert.log
Tue Dec 08 16:38:54 2015
Session (15,59816): RECO logon successful: Inbound connection from client
Session (15,59816): RECO logon successful: DB Logon User: RECO, Remote Machine: userhost, Program: oracle@userhost (TNS V1-V3), OS User: os_username



dba123,
Теоретик или проверял свои рекомендации?
8 дек 15, 13:48    [18529522]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
dba123
Member

Откуда:
Сообщений: 1054
SeaGate,

Проверял
Хорошо, что и ты проверил, и ТС, надеюсь, тоже проверит
А у меня даже линков нет:
select CURSCHEMA, CURUSER, SESUSER, BG_JOB_ID, dts from adm.syslog order by dts;

CURSCHEMA            CURUSER              SESUSER               BG_JOB_ID            DTS
-------------------- -------------------- -------------------- -------------------- -----------------------------
ADM                   ADM                  SYS                  17380                2015-12-07 14:31:36,988001
ADM                   ADM                  SCOTT                                     2015-12-07 14:34:32,501324
ADM                   ADM                  SYS                  89263                2015-12-07 14:35:02,970427
ADM                   ADM                  SYS                  17380                2015-12-07 14:36:36,969235
8 дек 15, 14:14    [18529770]     Ответить | Цитировать Сообщить модератору
 Re: DBA_AUDIT_TRAIL  [new]
Gibbons
Member

Откуда: Украина, Мариуполь
Сообщений: 51
SeaGate,

Ты прав.
У меня вот такие записи в alert.log на БД которая "светится" в аудите:
Tue Dec 08 17:42:57 2015
DISTRIB TRAN BUF.KMM.LOCAL.970520fb.25.30.5815
  is local tran 25.30.5815 (hex=19.1e.16b7))
  delete pending collecting tran, scn=4738945966941 (hex=44f.5f30e35d)


https://community.oracle.com/thread/2324633?tstart=0
Delete pending means that there was a pending transaction in DBA_2PC_PENDING and was recovered by RECO.
9 дек 15, 10:07    [18533598]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить