|
Участник форума
Регистрация: 30.10.2006
Сообщений: 238
Провел на форуме:
966901
Репутация:
444
|
|
В Oracle 9i нет колонки LAST_ACTIVE_TIME, поэтому запрос нужно слегка изменить:
SQL> SELECT PARSING_USER_ID, SQL_TEXT FROM V$SQL ORDER BY
PARSING_USER_ID ASC;
В 10g таблицы Automatic Workload Repository History WRH$_SQLTEXT и WRH$_SQLSTAT могут также содержать факты и поэтому должны быть запрошены:
SQL> SET LONG 2000000000
SQL> SELECT ST.PARSING_SCHEMA_ID, TX.SQL_TEXT FROM WRH$_SQLSTAT ST,
WRH$_SQLTEXT TX WHERE TX.SNAP_ID = ST.SNAP_ID;
Строка, содержащая “SET LONG 2000000000” сообщает sqlplus показать 2000000000 символов для SQL_TEXT поскольку это будет обрезано иначе имеющий тип CLOB. Эта таблица содержит обширное количество предыдущих SQL запросов, а также очень высоковероятно, что она содержит множество точных фактов о точ, что есть нужные доказательства.Она содержит SELECT, UPDATE, INSERT, DELETE, возможно ALTER, то есть запросы, отнимающие много времени на выполнение. Это один из случаев, когда исследователь должен быть в состоянии найти некоторые SELECT – запросы в отсутствие аудита.
Как только данные извлечены из таблицы, они должны быть «безопасны»
move onto to другие запросы. «Безопасны» взято в кавычки потому что как только новые запросы выполнены, они поместят в SQL_TEXT записи от предыдущих выполненных запросов. Вот почему мы подвергли их сомнению.
Следующей строчкой должен быть лог аудита. Все должно быть извлечено из таблицы для последующего изучения и анализа.
SQL> SELECT * FROM AUD$;
Если аудит-информация подключена к серверу или к системному демону, она должна быть собрана до подключения и запросов к серверу.
Сбор информации о входах – текущих и прежних
Пока таблица AUD$ будет содержать информацию о входах, обеспечивая аудит, и подключена к серверу, можно получить свидетельства входов везде.
Фиксированный просмотр V$ACTIVE_SESSION_HISTORY использует циркулирующий буфер в SGA для размещения, взятую каждую секунду, об активных сессиях. Эти сессии протекают от SGA в таблицу WRH$_ACTIVE_SESSION_HISTORY, часто, как часть Automatic Workload Repository. Это важные данные, так как содержат информацию о всех входах в систему.
SQL> SELECT USER_ID, SESSION_ID, SAMPLE_TIME FROM
SYS.WRH$_ACTIVE_SESSION_HISTORY
Исследователь должен получить список пользователь, присутствующих на сервере в данный момент:
SQL> SELECT SID, USER#, USERNAME, TERMINAL, OSUSER, PROGRAM,
LOGON_TIME FROM V$SESSION;
Также важно получить список всех пользователей системы.
SQL> SELECT USER#, NAME, ASTATUS, PASSWORD, CTIME, PTIME, LTIME FROM
SYS.USER$ WHERE TYPE#=1;
Должен быть выбран хеш пароля, чтобы показать, насколько пароль стойкий для подбора взломщиком. ASTATUS покажет, заблокирован аккаунт или нет, если да, LTIME покажет когда; CTIME покажет дату создания, а PTIME – время последней смены пароля.
Список roles также важен
SQL> SELECT USER#, NAME, PASSWORD, CTIME, PTIME FROM SYS.USER$ WHERE
TYPE#=0;
Получение списка roles memberships
SQL> SELECT U.NAME AS "GRANTEE", U2.NAME AS "ROLE" FROM SYS.USER$ U,
SYS.USER$ U2, SYS.SYSAUTH$ A WHERE U.USER# = A.GRANTEE# AND
PRIVILEGE# = U2.USER#;
Получение списка привилегий объекта
Будет важно получить список всех привилегированных объектов, чтобы просмотреть, нет ли там чего нибуть подозрительного.
SQL> SELECT U.NAME AS "GRANTEE", P.NAME AS "PRIVILEGE", U2.NAME AS
"OWNER", O.NAME AS "OBJECT" FROM SYS.USER$ U, SYS.USER$ U2,
SYS.TABLE_PRIVILEGE_MAP P, SYS.OBJ$ O, SYS.OBJAUTH$ A WHERE U.USER# =
A.GRANTEE# AND A.OBJ# = O.OBJ# AND P.PRIVILEGE = A.PRIVILEGE# AND
O.OWNER#=U2.USER#;
Точно такиеже действия для системных привилегий:
SQL> SELECT U.NAME AS "GRANTEE", S.NAME AS "PRIVILEGE" FROM SYS.USER$
U, SYS.SYSAUTH$ A, SYS.SYSTEM_PRIVILEGE_MAP S WHERE U.USER# =
A.GRANTEE# AND PRIVILEGE# = S.PRIVILEGE ORDER BY U.NAME;
Исследователь должен получить список всех объектов, включая их ID, хозяина, имя, время создания и модификации, время спецификации.
SQL> SELECT OBJ#, OWNER#, NAME, TYPE#, CTIME, MTIME, STIME FROM
SYS.OBJ$ ORDER BY CTIME ASC;
Получение списка удаленных таблиц
В 10g, если пользователь удалил любые таблицы, не убрав их при этом из Корзины, они будут доступны:
SQL> SELECT U.NAME, R.ORIGINAL_NAME, R.OBJ#, R.DROPTIME, R.DROPSCN
FROM SYS.RECYCLEBIN$ R, SYS.USER$ U WHERE R.OWNER#=U.USER#;
Получение списка блоковых изменений
Каждый файл поделен на блоки, каждый блок содержит информацию о времени изменения, к примеру, после COMMIT. Она содержится в SCN.
Когда столбики изменяются, обновляется SCN, что означает, что все другие столбики в блоке отражают тот же самый SCN. Это важное открытие для исследований. Вот пример запроса и отрывок результата:
SQL> SELECT O.ORA_ROWSCN, O.CTIME, O.MTIME, O.STIME, U.NAME, O.NAME
FROM SYS.OBJ$ O, SYS.USER$ U WHERE U.USER#=O.OWNER# ORDER BY 1;
…
…
2282280 05-APR-07 06-APR-07 05-APR-07 SYS WRH$_SERVICE_WAIT_CLASS
2282280 05-APR-07 05-APR-07 05-APR-07 SYS WRH$_SERVICE_WAIT_CLASS_PK
2282280 05-APR-07 05-APR-07 05-APR-07 SYS P_TEST
2282280 05-APR-07 05-APR-07 05-APR-07 SYS VP_TEST
2282280 05-APR-07 05-APR-07 05-APR-07 SYS P_TEST
2282280 05-APR-07 05-APR-07 05-APR-07 SYS VANISH
2282280 05-APR-07 09-APR-07 09-APR-07 SYS X
2282280 05-APR-07 06-APR-07 05-APR-07 SYS WRH$_SQLSTAT
2282280 05-APR-07 06-APR-07 05-APR-07 SYS WRH$_SYSTEM_EVENT
…
…
Если преобразовать SCN в отпечаток времени, можно увидеть изменения 9 Апреля:
SQL> SELECT SYS.SCN_TO_TIMESTAMP(2282280) FROM DUAL;
SYS.SCN_TO_TIMESTAMP(2282280)
------------------------------------------------------------
09-APR-07 14.39.56.000000000
Смотря на результат предыдущего запроса, можно увидеть, что объект с именем X имеет MTIME и STIME установленные на эту, и это - единственный объект, который соответствует. Таким образом, можно увидеть, что SCN для всех других обьектов(чтение столбиков) в одном блоке разделяют один SCN даже если они не были модифицированы. Вот другой пример:
SQL> SELECT U.ORA_ROWSCN, U.NAME FROM SYS.USER$ U WHERE TYPE#=1 ORDER
BY 1;
ORA_ROWSCN NAME
---------- ------------------------------
537106 EXFSYS
537106 DMSYS
537106 TSMSYS
537106 DBSNMP
537106 ANONYMOUS
537106 XDB
537106 CTXSYS
537106 WMSYS
1465169 OUTLN
1465169 DIP
1465169 SYS
1465169 SYSTEM
2277427 MARK_POINT2
2277427 PWDTEST
2277427 MARK_POINT
2277427 FINDME_TOO
2277427 FINDME
2277427 SCOTT
2277427 MGMT_VIEW
2277427 MDDATA
2277427 SYSMAN
2277427 MDSYS
2277427 SI_INFORMTN_SCHEMA
2277427 ORDPLUGINS
2277427 TESTUSER
2277427 OLAPSYS
2277427 ORDSYS
27 rows selected.
Пользователи MARK_POINT2, PWDTEST, MARK_POINT, FINDME_TOO, FINDME,
SCOTT, MGMT_VIEW, MDDATA, SYSMAN, MDSYS,
SI_INFORMTN_SCHEMA, ORDPLUGINS, TESTUSER, OLAPSYS и ORDSYS существуют в одном блоке, и разделяют один SCN . Ели мы изменим пароль SCOTTа, SCN зафиксирует изменения для всех пользователей:
SQL> ALTER USER SCOTT IDENTIFIED BY PASSWORD;
User altered.
SQL> SELECT U.ORA_ROWSCN, U.NAME FROM SYS.USER$ U WHERE TYPE#=1
ORDER BY 1;
ORA_ROWSCN NAME
---------- ------------------------------
537106 EXFSYS
537106 DMSYS
537106 TSMSYS
537106 DBSNMP
537106 ANONYMOUS
537106 XDB
537106 CTXSYS
537106 WMSYS
1465169 OUTLN
1465169 DIP
1465169 SYS
1465169 SYSTEM
2283062 MARK_POINT2
2283062 PWDTEST
2283062 MARK_POINT
2283062 FINDME_TOO
2283062 FINDME
2283062 SCOTT
2283062 MGMT_VIEW
2283062 MDDATA
2283062 SYSMAN
2283062 MDSYS
2283062 SI_INFORMTN_SCHEMA
2283062 ORDPLUGINS
2283062 TESTUSER
2283062 OLAPSYS
2283062 ORDSYS
27 rows selected.
Поскольку SCN зафиксировал изменения всего блока, можно сделать вывод, что он не укажет вам иголку в стоге сена, но уменьшит объем работы.
Получение версии сервера и уровень пропатчености
Этот запрос вернет основную и вторичную версию сервера:
SQL> SELECT BANNER FROM V$VERSION;
Однако это не покажет, насколько пропатчен сервер. Вместо этого, могут быть взяты контрольные суммы для каждой PL/SQL сборки на сервере и сравнить их с имеющимися. Это позволит узнать, какие сборки были модифицированы:
Код:
SQL> SET NUMF 999999999999999999999999999999
SQL> DECLARE
TYPE C_TYPE IS REF CURSOR;
CV C_TYPE;
V_ONAME VARCHAR2(30);
V_OWNER VARCHAR2(30);
V_OBJID NUMBER;
V_HASH NUMBER;
BEGIN
DBMS_OUTPUT.ENABLE(100000);
OPEN CV FOR 'SELECT U.NAME,O.NAME,O.OBJ# FROM SYS.OBJ$ O,
SYS.USER$ U WHERE O.OWNER#=U.USER# AND O.TYPE# = 11
ORDER BY U.NAME';
LOOP
FETCH CV INTO V_OWNER,V_ONAME,V_OBJID;
EXECUTE IMMEDIATE 'SELECT
SUM(SYS.DBMS_UTILITY.GET_HASH_VALUE
(SOURCE,1,1073741824)) FROM SYS.SOURCE$ WHERE OBJ# = :1'
INTO V_HASH USING V_OBJID;
DBMS_OUTPUT.PUT_LINE(V_OWNER||'.'||V_ONAME||':'||V_HASH);
EXIT WHEN CV%NOTFOUND;
END LOOP;
CLOSE CV;
END;
/
Ответ будет следующим:
…
…
SYS.DBMS_PICKLER:235688071
SYS.DBMS_JAVA_TEST:821262485
SYS.UTL_FILE:992849395
SYS.UTL_RAW:407384329
SYS.UTL_TCP:308711346
…
…
Здесь номер после хозяина и сборек – хеш. Этот хеш был создан используя сумму хеша каждой строчки кода, зашифрованной функцией DBMS_UTILITY.GET_HASH_VALUE. Эти хеши также могут быть сравнены с списком известных хешей. Примите к сведению, что в скомпрометированной системе взломщик может изменить сборку DBMS_UTILITY или любой
Другой обьект включая функции памяти С.
Параметры сервера
Не достаточно всего лишь получить копию файла параметра загрузки сервера. Причина проста – файл параметра содержит настройки для первого запуска сервера. После этого настройки могут быть изменены с помощью команды «ALTER SYSTEM».
SQL> SELECT NAME,VALUE FROM V$PARAMETER
Любая разница между файлом загрузки и «живыми» параметрами должна быть узнана.
Также есть некоторое количество скрытых параметров. Они могут быть уточнены следующим запросом:
SQL> select n.ksppinm as "NAME", v.ksppstvl as "VALUE" from
sys.x$ksppi n, sys.x$ksppcv v where n.inst_id=userenv('Instance') and
v.inst_id=n.inst_id and n.indx=v.indx and substr(n.ksppinm,1,1)='_';
Получение всех параметров, в том числе и скрытых, в том же запросе может быть получено через удаление “and substr(n.ksppinm,1,1)='_'” из запроса выше.
Собирая внешние файлы, исследователь также может «открыть» новые места нахождения дампов из запроса выше, и любой файл, существующий в данных директориях, также должен быть скопирован на сервер
|