lunes, 22 de noviembre de 2010

activar archivelog mode


1. Añadimos una nueva unidad de disco para configurar ahi un destino.
a) Vamos a añadir un disco SCSI, si el sistema ha reconocido el disco nos encontraremos la ruta /etc/sdb (para un segundo disco), /etc/sdc (para un tercero).
b) Creamos una particion con fdisk /dev/sdb. Elegimos las opciones n para crear una nueva particion.p para crear una particion primaria y w para escribirla en la tabla de ficheros.
c) Formateamos la particion con ext3. mkfs -t ext3 /dev/sdb1
d) Creamos el punto de montaje.
d.1) mkdir mountdir
d.2) mount -t ext3 /dev/sdb1 /mountdir
e) Con df -k vemos si ha cogido todo el espacio.
f) Montamos el disco de forma permanente. Abrimos el fichero fstab y añadimos la siguiente linea:/dev/sdb1 /software ext3 defaults 1 1
2. Activamos el modo ARCHIVELOG mode.
a) Hacemos un backup del spfile al pfile.
CREATE PFILE=’/u01/app/oracle/spfilebackup.ora’ FROM SPFILE;
b) Modificamos el PFILE configurando el de las copias de los redo log (hasta 10 posibles)
i.e.
LOG_ARCHIVE_DEST_1 = ‘(LOCATION=/mountdir) MANDATORY REOPEN = 60′
Parametros:
1) LOCATION: destino del fichero
2) MANDATORY | OPTIONAL: indica si la escritura en esta ruta se debe de hacer o es opcional.
3) REOPEN: tiempo en segundos que va a esperar despues de un fallo, antes de volver a intentarlo.
c) Configuramos el ultimo destino para que almacene una copia en la Flash Recovery Area. Añadimos en la última direccion el string: USE_DB_RECOBERY_FILE_DEST
LOG_ARCHIVE_DEST_10=’LOCATION=USE_DB_RECOBERY_FILE_DEST’
d) Cofiguramos LOG_ARCHIVE_MIN_SUCCEDED_DEST con el numero de destinos escritos de forma correcta. y LOG_ARCHIVE_FORMAT con el formato que deseemos para las copias (i.e %t_%s_%r.dbf )
e) Activamos ARCHIVELOG
e.1) Volvemos a recrear el spfile con el pfile modificado:
CREATE SPFILE FROM PFILE=’/u01/app/oracle/spfilebackup.ora’
e.2) SHUTDOWN
e.3) STARTUP MOUNT
e.4) ALTER DATABASE ARCHIVELOG
e.5) ALTER DATABASE OPEN

comprobar archivelog

REDO LOG

Los ficheros de redo log se llenan con vectores que cambio que almancenan los cambios que se han realizado en un bloque y que serian necesarios para deshacer ese cambio.

Cada entrada en los redo logs se le asigna un numero de secuencia.

El proceso encargado de escribir en los redo log es LGWR. Escribe de forma circular, pasando de un redo log a otro cuando este se llena. Antes de sobreescribir un redo log si el modo de ARCHIVELOG esta activo este es almacenado en las ubicaciones especificadas por el parametro LOG_ARCHIVE_DEST_n.

Los redo log pueden encontrarse en varios estados (V$LOG):

a) Current: LGWR se encuentra escribiendo actualmente.

b) Active: Cuando el redo log es necesario para una recuperacion de la instacia.

c) Inactive: Cuando el redo log no es necesario para la instace recovery.

VISTAS QUE NOS INTERESAN:

– V$LOG:

Muestra el numero de grupos que tenemos, el numero de miembros que tiene ese grupo, el estado en el que se encuentra ese grupo y la secuencia de conmutacion.

– V$LOGFILE

Ubicación y estado de los ficheros de REDO log.

Para probar si la activación del modo ARCHIVELOG ha sido correcta podemos forzar una conmutacion de los archivos de redo log:

ALTER SYSTEM SWITCH LOG;

Viendo en la vista V$LOG como cambia el valor de la secuencia asignada a cada redo log.

Conceptos básicos tunning Oracle

Top-Down

Cuando realizamos una puesta a punto de nuestros sistemas, ORACLE recomienda una metodología Top-Down.

Ejemplo:

Prioridad Área que hay que examinar y realizar Tuning

  • Tuning the Data Design
  • Tuning the Aplication Design
  • Tuning Memory Allocation
  • Tuning I/O and Physical Structure
  • Tuning Resource Contention
  • Tuning the underlying Platform(s)

    Alert log

    Los “Alert logs” son registros que contienen la información de “mensajes de errores” obtenidos por la variedad de actividades que se realizan en la base de datos. Estas actividades y registros están almacenados cronológicamente del mas antiguo al más reciente. Este registro se encuentra en el directorio que hayamos fijado en nuestro init.ora bajo el parámetroBACKGROUND_DUMP_DEST. En una arquitectura OFA se recomienda que el directorio donde se encuentren estos archivos sea el siguiente: $ORACLE_BASE/adin/SID/bdumpen sistemas UNIX. En sistemas tales como Windows 2000 según este estándar podría encontrarse en%ORACLE_BASE%\admin\SID\bdump El nombre de este alert log será alert_ seguido de la instancia de la base de datos.

    Una de las cosas que podemos hacer para tener un seguimiento del alert log es mantener en un archivo las últimas 1000 líneas de este registro. Para hacer esto podemos echar mano del comando tail

    Ejemplo

    cd $ORACLE_BASE/admin/ALUMNOS/bdump
    tail –1000 alert_alumnos.log > alert_alumnos.log.ultimas
    mv alert_alumnos.log.ultimas alert_alumnos.log

    TRACE FILES

    Oracle trace files son archivos de texto que contienen información de la sesión para el proceso que han creado. “Trace files” pueden ser generados por procesos background . Muchos de estos “trace files” contienen información sobre el tuning que se le debe hacer a una base de datos.

    - Background Trace Files:
    Los “trace files” ( ficheros de traza ) generados por los procesos background pueden ser encontrados en el directorio especificado en el init.ora bajo el parámetro deBACKGROUND_DUMP_DEST . En sistemas que sigan el modelo OFA, $ORACLE_BASE/adin/SID/bdump en sistemas UNIX. En sistemas tales como Windows 2000 según este estándar podría encontrarse en %ORACLE_BASE%\admin\SID\bdump

    Ejemplo de trace files para los procesos background:

    Nombre del procesoSistemas UNIXSistema Windows
    PMONPmon_xxxx.trcsidPMON.trc
    SMONSmon_xxxx.trcsidSMON.trc
    DBW0Dbw0_xxxx.trcsidDBW0.trc
    LGWRLgwr_xxxx.trcsidLGWR.trc
    CPTCpt_xxxx.trcsidCPT.trc
    ARC0Arc_xxxx.trcsidARC0.trc

    - User trace files
    Los ficheros “user trace files” se encuentran también en el directorio especificado en el init.ora mediante el parámetro BACKGROUND_DUMP_DEST. Este fichero también incorpora en nombre de la instancia en los sistemas UNIX

    Ejemplo:

    Siendo alumnos el nombre de la instancia de nuestra base de datos ora_alumnos_4327.trc (sistemas UNIX) ora04327.trc(Windows 2000) , para identificar a qué usuario corresponde este trace file debemos de recurrir a dos vistas: V$PROCESS yv$SESSION.
    Con la siguiente consulta podríamos obtener el usuario cuyo proceso corresponde al 4327 :

    SQL > SELECT s.username,p.spid FROM v$session s, v$process p
    • WHERE s.paddr = p.addr AND p.background is null;

    USERNAME SPID ———– —- — ——————– — - ———————– ———
    USER1 4282
    USER2 5436
    USER3 4327
    USER4 4678

    Activando las trazas de usuario:

    Cuando ocurre un error, el archivo de traza se genera automáticamente, no obstante si el administrador de base de datos quiere que este archivo no solo se genere cuando haya un error entonces deberá realizar lo siguiente:
    Instance-Level Tracing:
    Si ponemos en init.ora el parámetro SQL_TRACE=TRUE, todos los procesos generarán sus archivos de traza. El parámetro por defecto para SQL_TRACE es FALSE.

    User Level Self-Tracing Un usuario puede activar o desactivar en su propia sesión su trace file utilizando los siguientes comandos de SQL :

    SQL > ALTER SESSION SET SQL_TRACE=TRUE
    SQL > ALTER SESSION SET SQL_TRACE=FALSE
    User Level DBA Tracing También podemos iniciar el user trace file mediante PL/SQL haciendo una llamada al paqueteDBMS_SYSTEM. Este paquete de PL/SQL contiene un procedimiento que nos permite activar el user trace file de algún usuario simplemente sabiendo el sid y el serial ( serial# )

    1. Identificamos el sid y el serial# de un usuario llamado DAVID :

      SQL> SELECT username, sid, serial#
      FROM v$session
      WHERE username = ‘DAVID’;
      USERNAME SID SERIAL
      —————————————- ——————— ————
      DAVID 10 2642

    2. Activamos el trace file para la sesión de DAVID usando el paquete DBMS_SYSTEM PL/SQL y los valores para el sid y el serial que hemos obtenido en el punto 1.

      SQL > exec sys.dbms_system.set_sql_trace_in_session(10,2642,TRUE);

      Hemos utilizado el procedimientoset_sql_trace_in_session del paquete dbms_system

    3. La sesión de DAVID generará un trace file que estará especificado en el parámetro USER_DUMP_DEST de nuestro init.ora En caso de que queramos para el trace file para el usuario DAVID ejecutaremos lo siguiente:

      SQL > exec sys.dbms_system.set_sql_trace_in_session(10,2642,FALSE);

    Cómo interpretar User trace file

    Una vez que estos trace file se han generado hay que aprender a interpretarlos. Se puede interpretar el contenido de un user_trace_file usando la utilidad TKPROF
    Gestionando trace files
    Podemos gestionar el tamaño de estos archivos mediante una serie de parámetros en el INIT.ora
    Parámetro especificado Tamaño máximo para User Trace

    MAX_DUMP_FILE_SIZE=10000 10000 OS bloques
    MAX_DUMP_FILE_SIZE=500K 500000 bytes
    MAX_DUMP_FILE_SIZE=10M 10 megabytes
    MAX_DUMP_FILE_SIZE=unlimited No limits on file size

    Performance Tuning Views

    Hay dos tipos de vistas de ORACLE que nos dan información:

    • Las v$ dynamic performance views
    • Las DBA Data dictionary views

    Los nombres de las vistas v$ son generalmente singulares de lasDBA views que utilizamos con nombres en plural. Un ejemplo para esto es V$datafile vs DBA_DATA_FILES.
    Muchas de las vistas están disponibles cuando la base de datos está en estado nomount ó mount. Las DBA views sólo están disponibles cuando la base de datos está abierta (open)

    Hay aproximadamente unas 225 V$, estas vistas están basadas en tablas dinámicas conocidas colectivamente como X$ tablas. Estas tablas existen en memoria con nombres encriptados comoX$KSMPS.

    Ejemplo de v$dynamic performance views

    Nombre de la vista Descripción de la vista

    V$SGASTAT Tamaño de todas las estructuras de memoria
    V$STATNAME Estadísticas del V$SESSTAT
    V$SYSSTAT Estadísticas del uso de cpu para todas las sesiones activas
    V$SESSTAT Estadísticas de las sesiones activas
    V$SESSION Sesiones activas.
    V$WAITSTAT Refleja la contención en términos del número de esperas en cuatro tipos de bloques de rollback

    Ejemplo de DBA Views

    Nombre de la vista Descripción de la vista :

    DBA_TABLES Tablas, líneas e información de bloques
    DBA_INDEXES Índices, líneas e información de bloques
    DBA_DATA_FILES Ubicación de los datafiles, nombre e información del tamaño.
    DBA_SEGMENTS Información sobre el espacio consumido en los segmentos de base de datos

    Ejemplo de consultas (query) para este tipo de vistas

    V$:

    SQL > Select s.username,n.name,t.value
    from v$session, v$statname n,v$sesstat t
    where s.sid=t.sid
    and t.statistic#=n.statistic#
    and s.username =’DAVID’;
    DBA VIEW:

    SQL > Select table_name, chain_cnt
    from dba_tables
    where owner = ‘DAVID’
    and chain_cnt !=0;

¿Que Mirar Cuando Auditamos una Base de Datos Oracle?

Cuando se realiza una auditoria, siempre es recomendable seguir una serie de pasos para no pasar por algo ningún detalle que pueda resultar crucial para nuestra investigación, a continuación les dejo un pequeño listado de las cosas a las que debemos echarle una ojeada cuando auditamos una base de datos oracle.


1). Determinar si en la BD esta activo el modo de operación en ARCHIVELOG o NONARCHIVELOG. Si este no esta activo, la evidencia de ataque o cambios serán sobrescritos por un nuevo redo.

Se puede determinar realizando una sentencia SQL a la BD:

  • SELECT VALUE V$PARAMETER WHERE FROM NAME=’archiv_log_start’;

2). Análisis de los Oracle Data Blocks, para determinar:

  • Registros eliminados
  • Localizar bloques asignados a tablas (OBJETOS DE INTERÉS)
  • Seguimiento de Objetos creados y eliminados
  • Localización de tablas eliminadas
  • Localización de Funciones eliminadas

3). Obtención del SID de la BD

4). Enumeración de usuarios

  • SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$;
  • SELECT USERID, COMMENT$TEXT FROM SYS.AUD$;

5). Consultar Ataques de Fuerza bruta o Diccionario a cuentas de usuario

  • SQL> SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$;
  • SELECT NAME, LCOUNT FROM USER$ WHERE LCOUNT>0;
  • SELECT NAME, LTIME FROM USER$ WHERE ASTATUS = 4;

6). Consulta de Ataques de Fuerza Bruta a la cuenta SYS

7). Consulta de intentos del exploit AUTH_ALTER_SESSION

  • SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$;

8). Consulta de intentos de iniciar una sesiÛn la base de datos a travÈs de XML (XDB)

  • SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$;
  • SELECT COMMENT$TEXT FROM SYS.AUD$ WHERE USERID = ‘DBSNMP’;
  • SELECT TERMINAL,SPARE1,TIMESTAMP# FROM SYS.AUD$ WHERE USERID=’DBSNMP’;

9). Consulta si la Auditoria esta habilitada

  • SELECT USER_ID, SESSION_ID, SAMPLE_TIME FROM SYS.WRH$_ACTIVE_SESSION_HISTORY ORDER BY SAMPLE_TIME;
  • SELECT USERID, ACTION#, RETURNCODE, TIMESTAMP# FROM SYS.AUD$;
  • SELECT USERID,ACTION#,TIMESTAMP#,LOGOFF$TIME FROM AUD$;

10). Consulta del archivo sqlnet.log,Agntsrvc.log, spfilesid.ora, o el init.ora todas las ubicaciones referentes a estos parámetros:

  • audit_file_dest ——-> Sistema de Auditoria (ORACLE_HOME/rdbms/audit)
  • background_dump_dest ——-> archivo alert.log y tracer de procesos ($ORACLE_HOME/admin/$ORACLE_SID/bdump)
  • core_dump_dest ——-> archivos Oracle core dump ($ORACLE_HOME/DBS/)
  • db_recovery_file_dest ——-> redo logs, flashback logs, y RMAN backups
  • user_dump_dest ——-> Archivos trace debuggin procesos/usuarios (/oracle/utrc)
  • utl_file_dir ——-> Especifica uno o m·s directorios que Oracle debe utilizar para PL/SQL archivos E/S.
  • control_files ——-> Especifica uno o varios nombres de archivos de control de Oracle
  • db_create_file_dest ——-> Especifica la ubicación predeterminada de archivos de datos administrados por Oracle.
  • db_create_online_log_dest_n—-> Especifica la ubicación de los redo logs y file control
  • log_archive_dest ——-> Es aplicable solo si la BD esta en modo de ARCHIVELOG
  • log_archive_dest_n ——-> Define hasta 10 archivos de registros logs.

11). Consulta de archivos Log Listener (ORACLE_HOME/network/admin/listener.ora) (lsnrctl status me dara la ubicación actual)

12). Revisión de los LOGS de sentencias(SQL $ORACLE_HOME/bin/LOGIN.SQL,$ORACLE_HOME/dbs/LOGIN.SQL,$ORACLE_HOME/SQLPlus/admin/glogin.sql)

13). Consultando información de los inicios de Sesion:

  • SELECT USER_ID, SESSION_ID, SAMPLE_TIME FROM SYS.WRH$_ACTIVE_SESSION_HISTORY

14). Consultar una lista de usuarios y roles, usuarios con función de DBA, para buscar inconsistencias,o usuarios creados por un atacante y la generación de contraseñas fuertes con la validación de los hash, cuentas bloqueadas, tiempos de password

  • SELECT USER#, NAME, ASTATUS, PASSWORD, CTIME, PTIME, LTIME FROM SYS.USER$ WHERE TYPE#=1;
  • 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#;

15). Consultar una lista de objetos y privilegios en el sistema

  • 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 OBJ#, OWNER#, NAME, TYPE#, CTIME, MTIME, STIME FROM SYS.OBJ$ ORDER BY CTIME ASC;

16). Consulta de tablas eliminadas

  • SELECT U.NAME, R.ORIGINAL_NAME, R.OBJ#, R.DROPTIME, R.DROPSCN FROM SYS.RECYCLEBIN$ R, SYS.USER$ U WHERE R.OWNER#=U.USER#;

17). Consulta de Directorios, archivos datos, archivos externos, tablas externas, buscando elementos perdidos o ubicados en sitios diferentes por el atacante.

  • SELECT T.NAME AS “TABLESPACE”, D.NAME AS “FILNAME” FROM V$DATAFILE D, TS$ T WHERE T.TS#=D.TS#;
    SELECT U.NAME AS “OWNER”, O.NAME AS “DIRECTORY”, D.OS_PATH AS “PATH” FROM SYS.OBJ$ O, SYS.USER$ U, SYS.DIR$ D WHERE U.USER#=O.OWNER# AND O.OBJ#=D.OBJ#;
  • SELECT O.NAME, D.DEFAULT_DIR FROM SYS.OBJ$ O, SYS.EXTERNAL_TAB$ D WHERE D.OBJ# = O.OBJ#;

18). El Monitor del Sistema (SMON) MON_MOD$ Table

  • SELECT U.NAME AS “OWNER”, O.NAME AS “OBJECT”, M.OBJ#, M.INSERTS,M.UPDATES, M.DELETES, M.TIMESTAMP FROM SYS.MON_MODS$ M, SYS.USER$ U,SYS.OBJ$ O WHERE O.OBJ#=M.OBJ# AND U.USER#=O.OWNER#;

19). Revision de Triggers al encendido, apagado, inicio y terminacion de sesion

  • SELECT U.NAME AS “OWNER”, O.NAME AS “ENABLED_TRIGGER_NAME”,DECODE(T.TYPE#, 0, ‘BEFORE’,2, ‘AFTER’,'NOTSET’) AS “WHEN” FROM SYS.OBJ$ O, SYS.TRIGGER$ T, SYS.USER$ U WHERE O.OBJ#=T.OBJ# AND O.OWNER# = U.USER# AND ENABLED=1;
  • SELECT U.NAME AS “OWNER”, O.NAME AS “ENABLED_TRIGGER_NAME” FROM SYS.OBJ$ O, SYS.TRIGGER$ T, SYS.USER$ U WHERE O.OBJ#=T.OBJ# AND O.OWNER# = U.USER# AND ENABLED=1 AND BITAND(T.SYS_EVTS,1) = 1;
  • SELECT U.NAME AS “OWNER”, O.NAME AS “ENABLED_TRIGGER_NAME” FROM SYS.OBJ$ O, SYS.TRIGGER$ T, SYS.USER$ U WHERE O.OBJ#=T.OBJ# AND O.OWNER# = U.USER# AND ENABLED=1 AND BITAND(T.SYS_EVTS,2) = 2;
  • SELECT U.NAME AS “OWNER”, O.NAME AS “ENABLED_TRIGGER_NAME” FROM SYS.OBJ$ O, SYS.TRIGGER$ T, SYS.USER$ U WHERE O.OBJ#=T.OBJ# AND O.OWNER# = U.USER# AND ENABLED=1 AND BITAND(T.SYS_EVTS,8) = 8;
  • SELECT U.NAME AS “OWNER”, O.NAME AS “ENABLED_TRIGGER_NAME” FROM SYS.OBJ$ O, SYS.TRIGGER$ T, SYS.USER$ U WHERE O.OBJ#=T.OBJ# AND O.OWNER# = U.USER# AND ENABLED=1 AND BITAND(T.SYS_EVTS,16) = 16;

20). Consulta de librerias, que puedan estar ejecutando codigo arbitrario(malicioso)

  • SELECT U.NAME AS “OWNER”, O.NAME AS “LIBRARY”, L.FILESPEC AS “PATH” FROM SYS.LIBRARY$ L, SYS.USER$ U, SYS.OBJ$ O WHERE O.OBJ#=L.OBJ# AND O.OWNER#=U.USER#;

21). Consultas de FlashBack (nuevos privilegios, derechos asignados, nuevos objetos, objetos eliminados) entre la tabla actual y la anterior en un tiempo determinado.

  • SELECT GRANTEE#, PRIVILEGE# FROM SYS.SYSAUTH$ MINUS SELECT GRANTEE#, PRIVILEGE# FROM SYS.SYSAUTH$ AS OF TIMESTAMP(SYSDATE – INTERVAL ’3600′ MINUTE);
  • SELECT NAME FROM SYS.OBJ$ MINUS SELECT NAME FROM SYS.OBJ$ AS OF TIMESTAMP(SYSDATE – INTERVAL ’156′ MINUTE);
  • SELECT NAME FROM SYS.OBJ$ AS OF TIMESTAMP(SYSDATE – INTERVAL ’156′ MINUTE) MINUS SELECT NAME FROM SYS.OBJ$;

22). Consulta de las tablas RECYLEBIN$ y OBJ$

  • SQL> SELECT MTIME, NAME, OWNER#, OBJ# FROM SYS.OBJ$ WHERE NAME LIKE ‘BIN$%’;

23). Consultas la Administracion automatica Deshacer ( UNDOTBS01.DBF)

  • SELECT SEGMENT_NAME,HEADER_FILE,HEADER_BLOCK,EXTENTS,BLOCKS FROM DBA_SEGMENTS WHERE SEGMENT_NAME LIKE ‘_SYSSMU%$’;

24). Consulta de los logs del Apache (Oracle Application Server)