seguridad en bases de datos (modulo 1)

Introduccin

Vicente Daz Sez

PID_00191661

CC-BY-NC-ND PID_00191661 Introduccin

Los textos e imgenes publicados en esta obra estn sujetos excepto que se indique lo contrario a una licencia deReconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 Espaa de Creative Commons. Podis copiarlos, distribuirlosy transmitirlos pblicamente siempre que citis el autor y la fuente (FUOC. Fundacin para la Universitat Oberta de Catalunya),no hagis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

CC-BY-NC-ND PID_00191661 Introduccin

ndice

1. Seguridad en bases de datos y aplicaciones web....................... 5

2. Evolucin de los ataques.................................................................. 8

3. Perspectivas.......................................................................................... 123.1. Tipos de ataque ........................................................................... 123.2. Modelos de programacin .......................................................... 13

4. Arquitectura de aplicaciones web................................................. 154.1. Arquitectura genrica .................................................................. 154.2. Tipos de aplicaciones .................................................................. 194.3. Amenazas a la arquitectura web ................................................. 21

4.3.1. Estado de la seguridad web ........................................... 214.3.2. Evaluacin de riesgos sobre la arquitectura web ........... 22

5. Arquitectura de bases de datos...................................................... 245.1. Oracle ........................................................................................... 24

5.1.1. Historia y evolucin ...................................................... 245.1.2. Arquitectura ................................................................... 25

5.2. Microsoft SQL .............................................................................. 315.2.1. Historia y evolucin ...................................................... 325.2.2. Arquitectura ................................................................... 33

5.3. MySQL ......................................................................................... 385.3.1. Introduccin .................................................................. 385.3.2. Historia y evolucin ...................................................... 395.3.3. Arquitectura ................................................................... 40

5.4. DB2 .............................................................................................. 435.4.1. Historia y evolucin ...................................................... 445.4.2. Arquitectura ................................................................... 46

Bibliografa................................................................................................. 51

CC-BY-NC-ND PID_00191661 5 Introduccin

1. Seguridad en bases de datos y aplicaciones web

Las bases de datos estn en todas partes. Es as de simple, son el almacn dela informacin de uso diario para prcticamente todo. Almacenan datos ban-carios, mdicos, el censo de la poblacin, antecedentes penales, informacinsobre avistamientos OVNI y los datos de la declaracin de la renta. No hayninguna organizacin o empresa que no haga uso de un modo u otro de unabase de datos, por lo que est claro que son una pieza clave y jugosa para cual-quier atacante, ante la que cualquier medida de proteccin es poca.

Esto no sera un gran problema si nuestras bases de datos se encontraran guar-dadas en una caja de seguridad en un lugar desconocido, pero entonces tam-poco seran muy tiles. Las bases de datos forman parte de un ecosistema des-de el cual se permite el acceso a la informacin que contienen a ciertos usua-rios. Dentro de este ecosistema casi siempre encontramos un aplicativo web,o dndole la vuelta, la prctica totalidad de servicios web utilizan de un modou otro una base de datos. Es por ello que ambos mundos estn ntimamenteinterrelacionados y por lo que cuando pensamos en seguridad no podemosconsiderar en dichos elementos como aislados.

Los servicios web y las aplicaciones que lo implementan viven en la actuali-dad su momento de mxima expansin. El crecimiento de los servicios 2.0 yla proliferacin del cloud computing han supuesto la explosin de la demandapara todo tipo de aplicaciones que implementan desde la posicin GPS de unusuario de un terminal inteligente hasta la generacin de nmeros aleatorios.Sea como sea, y ms all de los datos que hayan detrs, la aplicacin en s mis-ma supone la puerta de entrada para un potencial atacante a la infraestructuraen la que se encuentra. Un servicio mal securizado puede resultar en un ataqueque consiga una denegacin de servicio, que se cambie la pgina web de lacompaa o que se obtenga un control total de la red interna, es decir, unaamenaza para todos los clientes de la misma.

Se pueden encontrar numerosos ejemplos de ello. No es que no exista abun-dante documentacin anterior al 2011, pero quiz dicho ao ha sido especial-mente significativo en lo que se refiere a la popularizacin de ataques dirigi-dos contra grandes compaas y entidades ms all del afn de lucro o de ob-tencin de reputacin habitual entre los hackers buenos. Grupos hetero-gneos como Anonymous o Lulzsec consiguieron evitar los controles de segu-ridad existentes en compaas y entidades de talla mundial, publicando pos-teriormente los datos obtenidos. Y algo muy interesante: en la mayora de loscasos los ataques fueron extremadamente simples!


La prdida o acceso no autorizado, y especialmente la publicacin de los da-tos privados de una entidad, pueden suponer un dao irreparable para unaorganizacin en su reputacin, recordemos el caso de HBGARY, empresa de-dicada a la seguridad en Estados Unidos. Ante una prdida se pueden adoptarmedidas y precauciones, como copias de seguridad, pero una intrusin es untema ms delicado: el acceso a la informacin clave de una compaa puedesuponer una prdida irreparable.

Imaginemos el caso de una empresa farmacutica que dedica millones a investigacin ydesarrollo de nuevos frmacos. Dichos desarrollos duran aos y en muchos casos supo-nen la supervivencia de la compaa, seguro que todos somos capaces de encontrar unejemplo de farmacutica que se basa en un nico medicamento. Un caso de espionajeindustrial en este entorno sera fatal.

No se trata nicamente de temas de espionaje, existen temas legales que hayque tener muy presentes. La LOPD (Ley Orgnica de Proteccin de Datos deCarcter Personal en Espaa), en vigor desde el 13 de diciembre de 1999, ha-ce referencia precisamente a los datos que almacenan las empresas espaolasacerca de los ciudadanos y que son de carcter personal. Dicha ley estableceuna serie de medidas de obligado cumplimiento por parte de las organizacio-nes que almacenan dichos datos y en funcin de la informacin que se alma-cene. Se establecen tres niveles de importancia de datos y medidas relaciona-das con cada uno de ellos de obligado cumplimiento, con sus correspondien-tes sanciones.

En el Estado de California entr en vigor en julio del 2003 la ley OrgnicaSB 1386, que obliga a cualquier organizacin que tenga datos personales deresidentes del estado de California a notificar a dichos residentes la sospechade cualquier brecha digital que haya podido comprometer los datos, en casode no estar cifrados. En la actualidad, existen varias regulaciones y leyes quetratan de regular este problema en distintas reas de negocios, como SarbanesOxley (SOX), Payment Card Industry (PCI) Data Security Standard, HealthcareServices (HIPAA), Financial Services (GLBA), Data Accountability and Trust Act(DATA), etc.

En cada pas encontraremos un ejemplo similar o leyes actualmente en pre-paracin.

Pero qu impacto puede tener un ataque exitoso contra una entidad?

Es difcil estimar el valor de los datos robados en s, hay varias aproximacionespara dar un valor monetario a dichas prdidas.

La siguiente tabla es un ejemplo:

Tipo de dato Valor

Direccin $0.50

Estimacin del valor de los datos robados


Tipo de dato Valor

Telfono $0.25

Telfono no publicado $17.50

Mvil $10

Fecha de nacimiento $2

Educacin $12

Historia crediticia $9

Detalles de bancarrota $26.50

Informacin judicial $2.95

Historial laboral completo $18

Archivo militar $35

Tarjetas de crdito $1-6

Identidad completa $16-18

Disco duro con transferencias del Banco central de Rusia $1800

Historial de llamadas a travs de mviles $110-200

30.000 e-mails $5

Estimacin del valor de los datos robados

Revisaremos los principales aspectos relacionados con la seguridad en las apli-caciones web y en las bases de datos que utilizan, tanto a nivel conceptualcomo a nivel ms tcnico, teniendo en cuenta las arquitecturas ms populareshoy en da.

Detallaremos los problemas a los que nos enfrentamos para el diseo y defensade un aplicativo web, incluyendo el punto de vista de un atacante, las tcnicasque utilizar contra nosotros y las herramientas de las que dispone. Explicare-mos cmo funcionan, cmo podemos protegernos, cmo minimizar riesgos,y cmo monitorizar la infraestructura para detectar cualquier problema.


2. Evolucin de los ataques

El 25 de enero del 2003, un gusano conocido como Slammer infect ms de75.000 mquinas en un lapso de unos 10 minutos, propagndose a una velo-cidad nunca vista hasta la fecha y causando denegacin de servicio en algunosdominios y lentitud en el trfico en general.

Este gusano explotaba una vulnerabilidad de desbordamiento de buffer en Mi-crosoft SQL Server pblica y con parche disponible desde 6 meses antes delataque. Muchos administradores no haban parcheado sus sistemas de formaadecuada, pero sobre todo la difusin tan masiva fue debida a que muchosusuarios no eran conscientes de tener instalado MS SQL Server Desktop Engine(MSDE), el cual dispone de un motor de MS SQL Server.

Figura 1. Aumento del trfico BGP, indicativo de atascos en Internet

Este ejemplo es ilustrativo en varios aspectos:

En primer lugar, es un buen ejemplo de la amplsima difusin de las basesde datos, en este caso incluso sin el conocimiento de los usuarios de lasmismas. El motor de la base de datos estaba embebido en otro productode software.

Una base de datos, a parte de cualquier diferencia conceptual que se puedahacer, no deja de ser otro producto de software ms, susceptible a ataquesespecialmente dirigidos para obtener los datos que alberga, o simplementeataques genricos que aprovechen una vulnerabilidad no corregida comoen cualquier otro software.

La gran presencia de bases de datos accesibles para un potencial atacante.Al estar conectadas a Internet, en ocasiones dando servicios, otras de for-


ma inconsciente para el usuario que la alberga, son un objetivo potencial.Aunque la distribucin de este gusano fue indiscriminada, existen muchastcnicas para buscar bases de datos vulnerables a algn fallo conocido uti-lizando herramientas tan al alcance de todos como puede ser Google.

La vulnerabilidad, no por ser conocida ni por disponer de un parche desde6 meses antes del ataque, dej de ser fatal. Esto pone de relevancia no sloel problema de no disponer de una adecuada poltica de actualizaciones,sino del factor humano. Este factor, aunque difcilmente remediable, es enmuchos casos determinante para explicar el porqu de muchos problemasde seguridad, por lo que la formacin y la concienciacin son un temaclave al mismo nivel que cualquier otro aspecto tcnico.

En cualquier caso, se trata nicamente de un ejemplo de una vulnerabilidadexplotada exitosamente por parte de un atacante. Hay decenas de vulnerabi-lidades, con distintas dificultades de explotacin y con distinto grado de di-vulgacin. La evolucin que han seguido las vulnerabilidades y los ataquesen bases de datos es similar a la evolucin que han seguido en cualquier otrosoftware segn aumentaba en popularidad y en complejidad, con el atractivoque de ser explotado tiene una recompensa final muy jugosa. Pero tambinhan crecido una serie de vulnerabilidades concretas para bases de datos, comopueden ser los ataques de inyeccin SQL y que se discuten ms adelante.

Hay que contextualizar los problemas dentro del entorno en el que se han idoutilizando las bases de datos, ya que los diseadores han ido dando respuestasa las necesidades del mercado con nuevas funcionalidades. En este contexto,normalmente han sido los atacantes los primeros en pensar nuevos vectoresde ataque y los diseadores han ido dando respuesta a los problemas segnse iban detectando.

Sin embargo, en la actualidad se intenta pasar de un escenario reactivo a unescenario proactivo, en el que se detecten los posibles problemas antes de sacarun producto al mercado. Esto es debido a un cambio en la forma de pensaren las grandes compaas, pero sobre todo, en sus clientes. La seguridad hapasado de ser un extra a ser una absoluta necesidad, y son los propios clienteslos que la demandan, por lo que los creadores de motores de bases de datos yde software cada vez dedican ms recursos para asegurar sus productos.

En la actualidad cualquier producto pasa varias etapas de calidad relacionadascon seguridad. En general se pasa una auditora de cdigo en la que se buscanposibles debilidades en el cdigo fuente del aplicativo. Tambin se realizanataques de intrusin ( penetration test o pentest) en el que un auditor juegael rol de un atacante e intenta con todos los medios a su disposicin lograrel control del software auditado. De este modo, se buscan debilidades en las


que los diseadores del software no han pensado, simulando el papel reactivoque han jugado las compaas pero en este caso antes de sacar el productoal mercado.

Aparte de intentar que el software tenga el mnimo de vulnerabilidades, es vitaldisponer de un servicio de respuesta rpida a incidentes, que permita publicarparches en respuesta a vulnerabilidades en el menor tiempo posible. Aun as,desde la aparicin de una vulnerabilidad hasta la publicacin e instalacin delparche en el cliente, existe una ventana de exposicin en el que el softwarees vulnerable al problema detectado. Y esto suponiendo que la vulnerabilidaddetectada se reporte al vendedor y este publique un parche que lo solucione,ya que algunas vulnerabilidades no se reportan nunca al vendedor y son uti-lizadas por parte de atacantes: si alguien descubre una vulnerabilidad con laque acceder a un tipo de base de datos para sus propios fines, por qu hacerlapblica? Estas son las que se conocen como 0-day.

Incluso con la actual concienciacin e inversin en seguridad, siguen existien-do gran cantidad de problemas.

Durante el 2006 Oracle public cuatro actualizaciones crticas de seguridad relacionadascon servidores de bases de datos que resolvan ms de veinte vulnerabilidades remotas.En el 2007, todava hay ms de cincuenta vulnerabilidades no parcheadas en Oracle Da-tabase Server.

Evidentemente, esto es nicamente un ejemplo, no significa ni mucho menosque sea el nico motor de bases de datos afectado por este tipo de problemas.Esto significa que conseguir un sistema de bases de datos seguro al 100% no esposible, pero existen gran cantidad de medidas a implementar para minimizarla posibilidad y la gravedad de un eventual ataque.

Pero qu tipos de ataques son los ms usados? A continuacin se listan algu-nos de los ms habituales segn OWASP:

Ataques de fuerza bruta contra contraseas Esnifar credenciales en la red Configuraciones inseguras por defecto Explotacin de vulnerabilidades (pblicas o no) Inyeccin SQL Uso de troyanos y rootkits Robo de dispositivos de almacenamiento fsicos Personal interno

En realidad, la mayora de intrusiones todava se consiguen gracias a una admi-nistracin deficiente. Aunque existen gran cantidad de mtodos, siguen sien-do los ms triviales los que producen mejores resultados. Esto es debido a fal-ta de concienciacin o desconocimiento de los potenciales ataques. Por otraparte, hay gran cantidad de software heredado en las empresas que no se ac-tualiza por miedo a las actualizaciones o por necesidades de otro software he-


redado que se utiliza en la actualidad. Cuntas veces hemos odo si funcionano lo toques.? Esta situacin es muy problemtica, ya que en algunos casoslas compaas dejan de dar soporte a ciertas versiones de software tras la pu-blicacin de versiones ms recientes (como pasa por parte de Microsoft conWindows NT4).

Por lo tanto, aunque hoy en da el nivel de concienciacin respecto a seguridades mucho ms alto que hace unos aos, no es suficiente. Los ataques cada vezson ms evolucionados y cada vez existen ms herramientas para evitar losmismos, pero el factor humano sigue siendo el principal.

Es tarea tanto del administrador como de un auditor de seguridad im-plantar las medidas de seguridad disponibles para minimizar el riesgode ataque y realizar un seguimiento mediante polticas de seguridad queaseguren la base de datos a lo largo del tiempo.


3. Perspectivas

Es difcil saber qu va a ocurrir en un futuro, pero en este apartado se haceun pequeo ejercicio al respecto considerando las ltimas tendencias y lasperspectivas en cuanto a seguridad para los prximos aos.

3.1. Tipos de ataque

Lo que parece claro es que el nmero de ataques va a seguir creciendo. Durantelos ltimos aos este aspecto se ha disparado y han aparecido nuevos vecto-res de ataque. Est claro que la difusin de Internet as como de los serviciosproporcionados mediante dicho medio facilitan la posibilidad de buscar vcti-mas y de informacin para explotar vulnerabilidades. La figura del atacante

casual o script-kiddie1 es cada vez ms frecuente.

Es posible pensar en ello como alguien que lee cmo lograr una intrusin enciertos tipos de sistemas de modo sencillo y utiliza este conocimiento para ata-car un sistema vulnerable sin ningn propsito ms que la curiosidad. Aun-que este tipo de atacantes debera ser el menos preocupante por su falta deconocimientos tcnicos, puede ser tambin muy peligroso precisamente porlo mismo: el atacante puede no ser consciente del riesgo que implica su accinprecisamente por su falta de conocimientos tcnicos. Una buena poltica deactualizaciones, una configuracin correcta y el uso de medidas de seguridadadicionales deberan servir para que este tipo de atacantes no tuviesen xito.El problema es que en caso de tenerlo, su falta de conocimientos puede pro-vocar un dao mayor al que pretenda hacer precisamente por no saber quest haciendo realmente.

Por otra parte, hay otro perfil de atacante muy capaz tcnicamente y que estu-dia durante un tiempo a un posible objetivo. Existen en la actualidad personasque se dedican a la creacin de software especializado contra un determinadoobjetivo a partir de un encargo. En general, este tipo de encargos se realizanmediante el uso de troyanos que afectan a los clientes de determinadas enti-dades o que explotan vulnerabilidades de los sistemas operativos para lograracceder al entorno interno de la entidad y desde all lograr credenciales paraacceder a los sistemas crticos. Sin embargo, es posible que con el tiempo estetipo de ataques tengan como objetivo directo las bases de datos. En este caso,es posible que una poltica de actualizaciones sea importante para evitar vul-nerabilidades relacionadas con versiones antiguas, pero no tiene por qu. Esteescenario plantea el uso de una vulnerabilidad desconocida para el adminis-trador, por lo que puede estar indefenso. Sin embargo, existen una serie demedidas que pueden paliar este problema, descubrirlo mientras se est produ-ciendo o incluso evitarlo, como se explica durante este curso.

(1)Usuario que, sin necesidad de te-ner conocimientos tcnicos, usa unsoftware de terceros o una vulne-rabilidad conocida y fcilmente ex-plotable para lograr una intrusin.


Los aplicativos web se utilizan mayoritariamente para la generacin de pgi-nas web, foros, sistemas sencillos de gestin, blogs, etc. Creados muchas ve-ces por usuarios no profesionales que en general usan soluciones prediseadas(con vulnerabilidades conocidas o no), suelen descuidar la actualizacin. In-cluso son en ocasiones los propios creadores del software los que no propor-cionan un servicio al respecto. Inevitablemente, van apareciendo vulnerabili-dades asociadas a versiones antiguas, y una simple consulta en un buscadorde Internet permite el acceso a miles de sistemas vulnerables. Este sistema seutiliza generalmente por parte de gusanos para su rpida propagacin e infec-cin masiva de modo casi instantneo.

Por otra parte, los sistemas de bases de datos propiamente dichos, con dedica-cin exclusiva y debidamente actualizados, tienen un problema, ya que cadavez son ms grandes. La gran cantidad de servicios demandados por los usua-rios reflejan una necesidad del mercado a la que los fabricantes tienen que darrespuesta, pero el aumento de complejidad tambin supone la aparicin denuevas posibilidades de ataque.

Hay que buscar siempre el equilibrio entre funcionalidad, necesidad yriesgo. La poltica tradicional en este aspecto es evitar instalar cualquierservicio innecesario.

Pero no todo son malas noticias. Los fabricantes cada vez implementan msservicios dedicados a seguridad. Aunque algunos fabricantes ya los implemen-tan en algunos de sus productos en la actualidad, es previsible su implanta-cin masiva. El primer servicio es el de cifrado de datos de forma transparen-te. Aunque puede suponer una prdida de rendimiento en ciertos entornoscrticos, en otros es muy importante tener todos los datos cifrados de formaautomtica, ya que facilita la administracin y evita errores humanos. Por otraparte, casi todos los sistemas funcionan ya con comunicaciones tambin cifra-das y que evitan la posibilidad de que un atacante acceda a los datos transmi-tidos entre el cliente y el servidor. Es de esperar que estos sistemas se utilicende forma transparente y que se evite cualquier otro tipo de comunicacin entexto plano para una mayor seguridad del sistema.

3.2. Modelos de programacin

En cuanto a modelos de programacin que interactan con bases de datos,tambin han seguido una evolucin. La utilizacin de cierto tipo de ataques,como la inyeccin SQL, ha supuesto un cambio en el paradigma de programa-cin utilizado hasta el momento. Los nuevos frameworks de creacin de soft-ware que interacta con bases de datos ya incorporan medidas para evitar estetipo de problemas. En este marco, la situacin es parecida a la del uso masivode motores de bases de datos por parte de software de terceros, aunque ahorael problema no es del motor sino del software que interacta con la misma.


La prevencin en este escenario pasa por el uso de las medidas existentes enel momento de la creacin del software, y por el uso de cdigo bien estructu-rado que permita la adopcin sencilla de modificaciones que prevengan nue-vos ataques. Tambin se ha popularizado el uso de filtros, IDS e IPS (intrusiondetection system, intrusion prevention system). Aunque no es previsible la adop-cin de estas medidas en la parte del motor de la base de datos, es importantesiempre tener en cuenta el entorno en el que se encuentra la misma y utili-zar las medidas de proteccin en todos los niveles. Es un error pensar que sepuede tener una base de datos perfectamente securizada sin pensar en todo suentorno y en tenerlo tambin debidamente protegido.


4. Arquitectura de aplicaciones web

4.1. Arquitectura genrica

La arquitectura de los sistemas web establece las directrices que se deben seguirpara el diseo de los sistemas software. La figura 2 muestra la tpica estructuraen tres capas para esta arquitectura y el movimiento de datos entre las inter-faces de usuario y las capas de aplicacin y los almacenes de datos.

Figura 2. Arquitectura web general basada en tres fases

Esta arquitectura en tres capas permite el desarrollo modular de las interfacesde usuario dependientes de un dispositivo especfico (un programa determi-nado) para su comunicacin a travs de una estructura de envo de serviciosweb (web services) multicanal. Por otro lado tambin permite incorporar pro-cesos o estrategias de negocio existentes o totalmente nuevas.

El envo de web services est ajustado al modelo de paso de mensajes descritoen los protocolos OASIS web services reliable messaging (WSRM) propuesto porIBM, BEA, TIBCO y Microsoft (acorde con W3C).

En el lado del cliente, el navegador web proporciona la interfaz de usuarioy la lgica de presentacin.

En el lado del servidor, el servidor web captura todas las peticiones HTTPenviadas desde el usuario y las propaga al servidor de aplicacin el cualimplementa la lgica de la aplicacin.

En el lado del almacn de datos, se procesan de forma transicional e hist-rica los datos de las operaciones diarias y se almacenan en la base de datosdel sistema por el gestor de bases de datos.


El servidor de aplicacin enva una consulta (query) al servidor de bases de da-tos y obtiene el conjunto de resultados. El servidor prepara la respuesta desdeuna serie de procesos y la enva al servidor web para que este la haga llegar alcliente. Un usuario registrado puede iniciar sesin obteniendo un perfil en elque se especifican sus privilegios, derechos de acceso y el nivel de complejidad.Una arquitectura basada en esta estructura trifsica puede dar soporte tantoa una intranet como a un entorno accesible desde Internet. El usuario puedeutilizar, por ejemplo, un navegador web para acceder al servidor de pginasweb usando HTML y HTTP. El ncleo del sistema est situado en el lado delos servidores de aplicacin y proporcionar un conjunto de web services. Es-tos servicios se pueden comunicar unos con otros. Esta comunicacin puedeimplicar un simple traspaso de datos o puede implicar el intercambio de in-formacin necesario para que dos o ms servicios trabajen de forma conjuntapara realizar una nica actividad.

Figura 3. Arquitectura Orientada a Servicios Bsica

La figura 3 ilustra la arquitectura orientada a servicios bsica (services orientedarchitecture, SOA). Se muestra un consumidor de servicios enviando una peti-cin (mensaje de request) al proveedor de servicios. Este ltimo devuelve unmensaje de respuesta al consumidor (mensaje de response). Tanto el request co-mo las subsiguientes conexiones de respuesta estn definidos de tal maneraque son decodificables por los dos agentes participantes en la comunicacin.Para completar este esquema tan sencillo es necesario remarcar que un pro-veedor de servicios puede tambin actuar como un consumidor.

En el ejemplo que est ilustrado en la figura 3 todos los mensajes estn forma-teados usando SOAP, que puede usar distintos protocolos (HTTP, SMTP, etc.).SOAP proporciona el marco para enviar los mensajes de los web services a travsInternet o de la intranet. Este marco consta de dos partes:


Una cabecera opcional en la que se puede indicar informacin sobre laautenticacin o la codificacin de los datos.

Un cuerpo que contiene el mensaje. Estos mensajes pueden definirse usan-do la especificacin WSDL que emplea XML para definir los mensajes.XML es un lenguaje de etiquetado que puede ser utilizado tanto por elproveedor de servicios como por el consumidor para el intercambio de in-formacin sin tener que ajustarse a un protocolo en el que el orden de losdatos sea muy estricto.

La presencia de los estrictos lmites entre cada una de las capas de la figura2 se trasladar a las aplicaciones software implementadas sobre esta arquitec-tura. Una distribucin equilibrada de los componentes de cada capa entre lascomputadoras de la red garantiza un nivel de flexibilidad que no se alcanzacon otras arquitecturas alternativas. Como resultado, los recursos computacio-nales alcanzan un alto rendimiento que se ve reflejado en la alta complejidadde la funcionalidad que se puede implementar.

Resumen

Las caractersticas que definen esta arquitectura son las siguientes:

La informacin final es solicitada por el cliente y se genera en la capa de servidor. Conello se prescinde de que sea el cliente el ltimo responsable del procesado de los datos.

Todos los recursos de informacin y la lgica de la aplicacin estn concentrados en elservidor. En contra de la disposicin distribuida que se propona en arquitecturas ahoraobsoletas (por ejemplo, el modelo cliente-servidor).

Los protocolos que se utilizan para el intercambio de datos entre la capa del cliente y elresto de las capas son estndares, como TCP/IP sobre Internet.

Tambin se estandariza el control centralizado no solo del servidor, sino tambin de losequipos de los clientes, al menos en trminos de software. De forma que en cada estacinde trabajo es suficiente con tener un programa de navegacin estndar.

Estas workstation pueden ejecutar programas locales y, de forma remota, los de otros equi-pos de la red.

Todas estas caractersticas, a excepcin de la ltima, ayudan a mitigar el problema de se-guridad informtica. La concentracin de todos los recursos de informacin y aplicacinen capas ajenas a la que alberga a los clientes simplifican el diseo y la administracindel sistema gestor de la seguridad de la informacin. Adems, el diseo de los sistemasde proteccin de los objetos localizados en un nico lugar es ms sencillo que si estalocalizacin fuese distribuida.

El uso de estndares abiertos como TCP/IP para el intercambio de datos entrelos equipos de la red garantiza la unificacin de todos los mtodos de inter-accin entre workstations y servidores. Gracias a ello es posible proponer unasolucin para la securizacin de los intercambios de informacin vlida paratodos los sistemas. El control centralizado ejercido desde los servidores sobrelos equipos cliente reduce la probabilidad de errores cometidos por descuidoso falta de formacin de operarios o usuarios. Estos errores son una de las prin-cipales amenazas del sistema y son potencialmente muy peligrosos.


Como se apunt anteriormente, en esta arquitectura, el procesamiento de lainformacin distribuida asume que los programas obtenidos desde los servi-dores van a ser ejecutados en las workstations. Este sistema de procesamientodistribuido permite la concentracin de toda la lgica de la aplicacin en lacapa de servidor. Sin embargo, la posibilidad de ejecutar programas desde elservidor en un cliente genera nueva amenazas que obliga a ser ms exigentecon los sistemas de proteccin.

Como se mencion anteriormente, la implementacin ms comn de web ser-vices utilizan SOAP. Esto constituye un potencial problema ya que SOAP usa elprotocolo HTTP. Y esto implica que si no se establecen medidas de proteccinprecisas es posible llegar, usando HTTP, hasta los sistemas de almacenamientode la figura 2; lo que puede suponer un riesgo de seguridad significativo.

La forma ms habitual de solucionar este problema es integrar la arquitecturaweb con una arquitectura de comunicaciones segura basada en una configu-racin eficaz de firewalls. La figura 4 resume las principales caractersticas deesta arquitectura general securizada.

Figura 4. Estructura segura basada en redes perimetrales para la arquitectura web de tres capas


Como se aprecia en la figura, esta arquitectura incorpora un firewall de aplica-cin basado en XML sobre los web services internos para filtrar los mensajesque les llegan desde el servidor de aplicacin.

4.2. Tipos de aplicaciones

A partir de la arquitectura general propuesta en el apartado anterior, es posibleestablecer una clasificacin de aplicaciones que permite distinguir entre trescategoras:

Web site pblico Intranet Extranet

Las detallaremos a continuacin.

1) Web site pblico, Internet o World Wide Web

En este escenario la organizacin dispone de los recursos para montar un sis-tema de difusin de la informacin sin restricciones. No existen restriccionesaplicables a los usuarios que motiven la habilitacin de sistemas arquitectu-rales para el control de accesos. Todos los mecanismos de autenticacin de-pendern de la lgica de la aplicacin y sern, por tanto, gestionados por elservidor de aplicacin.

Las aplicaciones tpicas son aquellas en la que no se establece un sistema in-teractivo de negocio sino puramente informativo.

2) Intranet

En el sentido ms amplio del trmino, una intranet es una red decomputadores que establecen sus interconexiones usando protocolosdesarrollados para Internet, pero que no est integrada en la World WideWeb.

Sin embargo, desde una perspectiva puramente prctica, esta definicinsuele complementarse con la afirmacin de que una intranet est for-mada por aquellos sitios web o aplicaciones que pueden encontrarse enla red y que pueden usarse como recursos y plataformas de comunica-ciones nicamente para la organizacin que las gestiona; no la red decomunicaciones en s misma sino los recursos que sern solo accesiblesde forma privada.

En un entorno empresarial en el que constantemente se est incrementandola complejidad de las infraestructuras, las organizaciones tienen que afrontarel desafo que supone adaptar estas infraestructuras a las nuevas tecnologas


de captura y comparticin de informacin con el objetivo de alcanzar unaalta efectividad en la toma de decisiones. Existen tres categoras dentro de latecnologa de la informacin que necesitan de un entorno basado en intranetpara alcanzar este objetivo:

La planificacin de recursos de empresa a nivel transaccional (enterpriseresource planning, ERP).

La administracin de la relacin con los clientes (customer relationship ma-nagement, CRM).

El sistema de control de la produccin, a nivel de tiempo real (manufactu-ring execution system, MES).

La aplicacin de estas tres tecnologas sobre un escenario como una in-tranet persigue el cumplimento de los principios bsicos, como son el au-mento de la produccin, alcanzar el zero downtime y reducir los costes.

3) Extranet

Una extranet mantiene una posicin intermedia entre intranet e Inter-net. En este escenario surgen cuando el uso de los recursos privados deuna intranet se extiende para que sean accesibles por usuarios externosa la organizacin, tpicamente los clientes de la misma.

Las extranets se mantienen desde la red interna de la organizacin, ga-rantizando a los usuarios el acceso a los recursos, pero utilizan Internetpara el envo de informacin siempre y cuando algunos de sus usuariosson externos a la red interna de la organizacin. Es decir, en una extra-net se mantienen recursos privados para usuarios que pueden establecerun acceso externo a la organizacin.

En realidad la necesidad de adaptar el acceso a los recursos respecto a los que seplanteaba en el caso de la intranet no se debe a una alteracin en los objetivosque se persiguen. Estos objetivos seguirn siendo los mismos. Sin embargo, loque justifica la utilizacin de una extranet es la necesidad de aplicar mayorflexibilidad a la relacin con los clientes. De hecho, en una extranet es posi-ble gestionar dos modelos de negocio imposibles en una intranet: el comer-cio electrnico de empresa a empresa (business to business, B2B) y el comercioelectrnico entre empresa y consumidor (business to consumer, B2C).


4.3. Amenazas a la arquitectura web

4.3.1. Estado de la seguridad web

Ganando algo de perspectiva en el cumplimiento de los principios bsicos deproductividad y reduccin de costes asociados a la gestin de las aplicacionesweb, se puede concluir que es necesario abordar un anlisis del estado de laseguridad de estos sistemas. Para ello es imprescindible emprender un inten-to de localizar los puntos crticos de las aplicaciones antes comentadas, conel fin de evaluar qu amenazas son las que se ciernen sobre el sistema. Paraello se deben evaluar datos estadsticos sobre ataques implementados sobrediferentes sitios web. A partir de estos datos evaluar a qu tipo de amenazascorresponden.

La localizacin de fuentes a partir de las cuales extraer datos de valor estads-tico es un problema de difcil solucin. Las implicaciones que tiene sobre laimagen de la empresa y las prdidas derivadas del deterioro de las mismashacen que una poltica frecuente de las empresas sea la ocultacin de estosincidentes de seguridad en un intento de minimizar los efectos sobre su pro-ductividad y la relacin con sus clientes. Por ello no es posible disponer de lasuficiente cantidad de datos oficialmente reconocidos por las empresas paraestablecer resultados con validez estadstica.

La nica solucin para obtener informacin sobre qu tipo de sistemas sonms frecuentemente vctimas de ataques, cules son las motivaciones de losatacantes o si el ataque est enfocado al sistema operativo o a las aplicaciones,es preciso localizar fuentes alternativas de datos. De hecho, una alternativapara esta bsqueda de informacin es utilizar sitios web como www.zone-h.orgen los que es posible obtener datos sobre ataques implementados por distintasasociaciones de hacker y sobre sus motivaciones.

Atendiendo a este repositorio de informacin, y teniendo en cuenta que no setrata de una informacin absolutamente fiable, s que es posible extraer unaserie de conclusiones muy interesantes:

El nmero de intrusiones web se ha ido decrementando ao tras ao debidoa la implantacin de nuevas contramedidas y a las actuales arquitecturas web.Esto se puede deber a que la implementacin de los ataques cada vez exigeuna mayor profesionalizacin para contrarrestar los altos niveles tcnicos in-troducidos con las ltimas tecnologas de proteccin. De hecho, durante lostres primeros meses del 2009 el nmero de ataques registrados por zone-h hasido de 54.960 frente a los 108.514 ataques registrados en el primer cuatrimes-tre del 2008.


Los sistemas atacados no mantienen un perfil claramente definido. De hechose puede concluir que se atacan todas las tecnologas, desde los sistemas ope-rativos a las aplicaciones, sin atender a fabricantes especficos.

Los motivos son variados pero se pueden resumir en los siguientes:

econmicos, por venganza, polticos, diversin.

A partir de estos resultados se puede concluir que, a pesar de que parece quese est avanzando en la direccin adecuada en cuanto a la implementacin demedidas de proteccin, todava se estn asumiendo muchos riesgos al plantearlas soluciones web. Es preciso reducir los ms de 50.000 ataques exitosos portrimestre. Para ello, es preciso profundizar ms en el anlisis de las amenazasdefinidas sobre la arquitectura y las aplicaciones web.

4.3.2. Evaluacin de riesgos sobre la arquitectura web

La evaluacin de los riesgos que surgen a partir de la propuesta de arquitecturaweb es tan compleja que es preciso descomponer el anlisis para determinarsobre qu componentes de la arquitectura se ciernen las amenazas potencial-mente ms peligrosas.

1)Riesgossobrelosclientes

En la mayora de los casos los clientes acceden a los recursos de forma local oremota a travs del navegador de Internet. Este software ejecuta cdigo a ni-vel de usuario, con el nivel de privilegios que este tenga definido en su perfil.Los cdigos que se ejecutan desde el navegador son potencialmente peligro-sos debido a la gran funcionalidad que se puede implementar con ellos. Loslenguajes ms extendidos son HTML/DHTML, vbScript, JavaScript o JScript.El navegador web permite incrustar programas realizados como applets de Ja-va, ActiveX o Shockwave de Flash. Adems normalmente presenta el cdigosin establecer ninguna medida de proteccin; no suelen aparecer cifrados niofuscados. Esta ltima caracterstica es especialmente sangrante cuando exis-ten mltiples alternativas para establecer un nivel de proteccin en el cdigo(por ejemplo, Atrise Stealth o HTMLLock).

En realidad ninguna proteccin en cliente es buena, ya que adems de losataques directos al navegador web del cliente directos o con decompiladores,existen las tcnicas de man in the middle (MiM) que apartan totalmente al usua-rio de la posibilidad de evitar el xito de un ataque lanzado sobre el sistema.Algunas herramientas que permiten evaluar la potencial peligrosidad de losataques MiM son las conocidas Achilles, BurpSuite u Odysseus.


2)Riesgossobrelalgicadelaaplicacin

El servidor de la aplicacin concentra toda la lgica de la aplicacin y paraello necesita ejecutar cdigo en contextos privilegiados, convirtindose conello en un objetivo formidable para un ataque. Estos cdigos estn desarrolla-dos usando potentes lenguajes de programacin que incrementan mucho lacriticidad de un posible ataque sobre el sistema. Como se ha explicado, estecomponente accede a la base de datos, enva programas a clientes, transfiereficheros y ejecuta comandos sobre el sistema. Adems, proporciona soporte aherramientas para administracin de otras aplicaciones y presenta cdigos deejemplo para facilitar las tareas de configuracin.

Con todo ello este componente es el candidato ideal para convertirse en elobjetivo de los ataques o, en la mayora de los casos, servir de vehculo parala implementacin de ataques sobre otros componentes (sobre los clientes atravs de ataques de cross site scripting, sobre los almacenes de datos a travs deataques de inyeccin de cdigo (SQL injection, LDAP injection o XPATH injection;sobre el sistema con la inyeccin de ficheros).

3)Riesgossobrelosalmacenesdedatos

El almacenamiento de informacin suele considerarse la clave de negocio, yaque un ataque a su confidencialidad o su integridad puede acarrear enormesprdidas econmicas as como, en determinados casos, la implicacin en elquebrantamiento de la Ley de Ordenacin y Proteccin de Datos (LOPD). Elalmacenamiento de los datos suele realizarse en bases de datos relacionales ojerrquicas que sern accedidas mediante lenguajes de mayor o menor poten-cia. En el caso de las bases de datos basadas en objetos los lenguajes son muyavanzados (3. o 4. generacin) y permiten una altsima interaccin con elsistema. Un ataque exitoso sobre este tipo de sistemas puede resultar altamen-te crtico, dada la facilidad en su explotacin una vez que se hayan ganado losprivilegios necesarios. De hecho, un ataque de este tipo podra resultar demo-ledor si se ha configurado el sistema para permitir la ejecucin de programassobre el sistema.

En el caso de las bases de datos jerrquicas, la informacin almacenada esigualmente importante. Es frecuente almacenar el catlogo global de datos yproporcionar un lenguaje para garantizar el acceso. Normalmente, estos len-guajes son ms limitados que los definidos para otros entornos, pero aun as, sise ha ganado un nivel de privilegios suficiente podrn usarse para implemen-tar un ataque que permita la extraccin de toda la informacin almacenada.


5. Arquitectura de bases de datos

Aunque es muy difcil conocer todas las arquitecturas en profundidad, es muynecesario conocer los principios de todas ellas. Un estudio general permiteestablecer paralelismos entre los principales productos y la evolucin que hanseguido los mismos a lo largo del tiempo. Adems de contemplar el escenarioen el que se crea una nueva base de datos y se compra una licencia de uso decualquier fabricante de su ltima versin de software, es muy comn trabajarcon versiones antiguas, de ah la importancia de conocer las distintas versionesde cada arquitectura.

Existe un principio que formula que la base de datos ms segura es la que mejorse conoce. La eleccin debe ser un compromiso entre necesidad y funcionali-dad que ofrece cada arquitectura, y una vez hecha la eleccin entre la ofertadel mercado, estudiar en profundidad la misma para lograr un nivel ptimode seguridad.

5.1. Oracle

Probablemente, Oracle es la base de datos ms conocida y popular del mundo.Una muestra de su popularidad es que se encuentra presente en 98 de las 100industrias incluidas en el top 100 de Fortune. Fue uno de los primeros vende-dores del mercado y se ejecuta en una gran cantidad de plataformas, amn deproporcionar un muy buen producto, lo que explica su popularidad.

Sin embargo, ha tenido un historial de problemas relacionado con la gran can-tidad de funcionalidades que proporciona. En especial, inyeccin de PL/SQL(el lenguaje de scripting proporcionado por el producto) y desbordamientos debfer en distintas partes de cdigo han sido algunos de los principales proble-mas histricos de este producto.

5.1.1. Historia y evolucin

Dado que Oracle es un producto muy veterano en el mercado, existe una largahistoria de versiones del mismo. Es ms, cuando se habla de Oracle, se hablade un trmino ambiguo que puede dar lugar a confusin debido a la grancantidad de productos que existen de este vendedor.

Las primeras versiones tienen inters a nivel histrico, aunque hoy en da yano estn vigentes en el mercado. Las versiones ms actuales a da de hoy son:


Oracle versin 8i (1999): Incorpora mejoras para responder a las necesida-des de Internet (como la i en el nombre indica). Incluye una mquinavirtual de Java en el motor de la base de datos (JVM).

Oracle 9i (2001): Soporte para XML y Clustering, entre 400 nuevas funcio-nalidades.

Oracle 10g (2003): En este caso, la g del nombre pone nfasis en gridcomputing.

Oracle 10.2.0.1 (2005): Conocido como Oracle 10g Release 2 (10gR2).

Las distintas versiones se proporcionan en diferentes productos o ediciones:Enterprise Edition, Standard Edition y Standard Edition One, adems de laversin Express para evaluacin y entornos de desarrollo. Todas utilizan lamisma arquitectura, y aunque proporcionan distintas funcionalidades, a nivelconceptual y en cuanto a seguridad tienen las mismas caractersticas.

Aparte del motor de base de datos, existe gran cantidad de software que pro-porciona funcionalidad adicional e interaccin con distintos aspectos de labase de datos, como desarrollo de software (Oracle Developer Suite), un servi-dor de aplicativos (Oracle Application Server), clustering, etc.

5.1.2. Arquitectura

Aunque la arquitectura especfica para cada una de las versiones de Oracle esdistinta, existen una serie de conceptos que constituyen el esqueleto de unabase de datos Oracle heredados desde la versin 7 hasta las ms recientes. Noes el objetivo de este material conocer con detalle todos los aspectos de lamisma, pero s las ideas principales:


Figura 5. Arquitectura de Oracle

En esta imagen se observan los participantes en una base de datos Oracle.

Procesodeusuario: Se conecta al servidor para interactuar con la base dedatos.

Procesodelservidor: Escucha los procesos de usuario y realiza las peticio-nes a una instancia de la base de datos.

PGA (programglobalarea): Memoria reservada para un proceso de usua-rio. Se libera al morir la sesin.

Instancia: Conjunto de procesos tanto lgicos como de control para acce-der a los datos en s, almacenados en ficheros fsicos. Accede a una y slouna base de datos. Dentro de la instancia hay una serie de subprocesos quese detallan a continuacin: SMON (system monitor): Recupera la instancia al arrancar la base de

datos. PMON (process monitor): Monitoriza los procesos de usuario y libera los

recursos que ocupan los mismos cuando acaban. DBWR (database writer): Escribe los datos fsicamente en los ficheros de

logs de redo cuando es necesario liberar dichos buffers de la instancia. ARCH (archiver) (antiguo LGWR): Una vez los archivos de logs de redo

estn llenos, escribe los datos en los archivos correspondientes paraliberar espacio.

CKPT (checkpoint process): Cada vez que se vacan los buffers y se escri-ben en ficheros de logs, se produce un checkpoint. Este proceso es el en-cargado de coordinar todas las operaciones correspondientes a dichoevento y guardar la coherencia de la base de datos mediante la escri-tura de los datos en todos sus archivos correspondientes y asegurandoque las operaciones han tenido xito.


RECO (recover): Elimina y limpia cualquier dato incoherente resultantede una transaccin distribuida fallida. Este proceso se incluye en laversin de Oracle 10g.

Hay que tener en cuenta que los principales procesos se mantienen a travs delas distintas versiones. Sin embargo, es inevitable que algunos vayan cambian-do a raz de las nuevas funcionalidades que se incluyen con las nuevas versio-nes, como se aprecia en el ltimo de los procesos anteriormente descritos.

SGA (system global area): Es el rea de memoria creada al arrancar una ins-tancia de Oracle. Tiene una serie de subreas: Shared pool: Almacena tanto la estructura e ndices de los ltimos ob-

jetos a los que se ha accedido en la base de datos como de las funcionesy procedimientos PL/SQL utilizados.

Redo log buffer: Utilizado para deshacer las acciones sobre los datos f-sicos en caso de realizar un rollback de las acciones realizadas duranteuna sesin.

Database buffer cache: Hace referencia a todos los datos que cachea elservidor para evitar acceder a los datos fsicos cada vez que se realizauna consulta, favoreciendo el rendimiento para consultas repetitivasque hacen referencia a los mismos datos.

Java pool y large pool: Conceptualmente son lo mismo que el sharedpool, slo que se dividen para utilizarlos tanto en acceso de entrada/salidacomo para requerimientos de parseo de Java. No tienen un especialinters.

Database: Hace referencia a los archivos fsicos que almacenan los datos.Se dividen en: Archivosdecontrol (extensin .ctl) que almacenan informacin acer-

ca de los archivos que forman parte de la base de datos y se encargande mantener la consistencia de la misma.

Dedatos (extensin .dbf) que almacenan fsicamente los datos (hayque tener en cuenta que una nica tabla puede almacenarse en N fi-cheros).

Deredo-logs (extensiones .rdo y .arc) para deshacer acciones en losdatos fsicos hasta un punto de control, especialmente pensado pararecuperar el sistema a un punto seguro en caso de un fallo.

Parameter file, password file y archived log files: Archivos de control queguardan los parmetros especficos para un servidor Oracle (normalmenteinit.ora), contraseas (en desuso en versiones actuales del servidor) y ar-chivos de log del servidor.


Hasta aqu se ha comentado la arquitectura bsica a nivel de procesos y de ar-chivos, es decir, la arquitectura fsica. Sin embargo, la estructura interna lgicaa nivel de tablas y de estructuras de datos es incluso ms importante, ya quenormalmente se trata el nivel de seguridad dentro del contexto de un usuariocon acceso a la base de datos.

Los datos en Oracle se organizan por bases de datos, o tablespaces. Para cadauna de estas bases de datos, los nombres son nicos. En cada instalacin deOracle existe una base de datos por defecto en la que se guarda el esquema(schema) de todos los objetos del sistema. Esto es, todos los usuarios, basesde datos, tablas, vistas, procedimientos, funciones, etc. Como es normal, notodos los usuarios tienen permisos para acceder a esta base de datos y debe estarbien protegida, ya que contiene informacin vital, en este caso, metadatos.

Dicha base de datos es sys, que se corresponde con el catlogo del sistema. Acontinuacin se listan algunos de sus objetos ms importantes:

all_tables : Contiene informacin de todas las tablas del sistema. dba_users : Contiene informacin de usuarios que tienen permisos de

DBA. all_users : Contiene informacin de todos los usuarios de la base de

datos. tabs : Contiene informacin de todas las tablas de usuario. user_tab_columns : Contiene informacin de columnas de las tablas de

usuario. all_db_links : Contiene informacin de los enlaces con otras bases de

datos.

La diferencia entre muchas de estas estructuras es el prefijo, que especifica quusuario tiene permisos para consultarlas y qu nivel de informacin ofrecen.Las que tienen prefijo dba_ solo son accesibles por usuarios con dicho nivelde permisos y son las que ofrecen ms informacin. Hay que tener en cuentaque para no tener datos redundantes, estas estructuras son vistas, por lo quelos datos reales no se almacenan en las mismas.

Por eso en algunos casos pueden modificarse para hacer invisible informacinpara algunos (o todos) los usuarios.

La tabla llamada dual se utiliza como comodn por Oracle para hacer consultassin tener como objetivo ninguna tabla en concreto. Por ejemplo, se puedeseleccionar el usuario de la sesin de la base de datos con la consulta:

select user() from dual


En este caso no se est haciendo una consulta de una informacin residente enla tabla dual, sino que se utiliza para usar la sintaxis SQL teniendo en cuentaque dicha tabla en realidad solo contiene una columna llamada dummy y unnico registro.

En cuanto a la autenticacin contra la base de datos, Oracle permite autenticarmediante su propio sistema, mediante el sistema operativo o mediante unsistema mixto. A partir de la versin 10g, Oracle implementa el Oracle identitymanagement, que permite la integracin de la autenticacin de la base de datoscon el sistema operativo, con sistemas LDAP, sistemas de PKI, etc.

Figura 6. Oracle identity management

Una vez autenticados, los usuarios tienen un rol en la base de datos que leotorga una serie de permisos. Este apartado es ms interesante que el medio deautenticacin, ya que en funcin del rol que tenga asignado el usuario tendrunos permisos u otros.

Los permisos para estos roles se almacenan en las tablas:

system_privilege_map table_privilege_map

Aunque a partir de la consulta del objeto dba_users_privs se pueden con-sultar los permisos de un usuario.


Los roles con mximos permisos en el sistema son SYS y SYSTEM. Existen va-rias cuentas con privilegios de DBA (data base administator), que sera la segun-da cuenta con ms permisos del sistema, como ctxsys, wksys, mdsys o sysman,aunque existen listas con ms de 400 cuentas utilizadas por distintas versionesde Oracle. Este es uno de los problemas de seguridad en las instalaciones deOracle por defecto.

A continuacin se comentan los procesos que ejecuta una base de datos Oracle,as como la funcin de cada uno de ellos y se destacan los ms importantes.

En primer lugar, hay que tener en cuenta que Oracle puede ejecutarse en unagran cantidad de sistemas operativos, lo que sumado a las distintas versionesde la base de datos resulta en un nmero potencialmente alto de combinacio-nes. Sin embargo, se puede usar el siguiente criterio como gua.

En sistemas Windows, el proceso principal de Oracle corre bajo el nombre deoracle.exe.

En sistemas *nix (Unix y Linux), existe un ejecutable para cada una de lasfunciones que se destacan anteriormente en este apartado. Este conjunto defunciones depende de la versin exacta de la base de datos, pero en general seencuentran los procesos siguientes:

pmon smon reco dbwr lgwr ckpt

Uno de los procesos ms destacables es el TNS listener (transparent network subs-trate). Este proceso juega el rol de proceso del servidor descrito anteriormen-te, es decir, espera las peticiones de un usuario y las transmite a la base de datospara retornar la respuesta de la misma, es decir, atiende las peticiones de red.

En este caso hay dos binarios asociados: el tnslnsr, que es el listener mismo, yel lsnctrl, que es la utilidad de control del listener.

En general, este proceso escucha en el puerto 1521 TCP, aunque es un parme-tro configurable en cada instancia de la base de datos. Cuando un cliente quie-re conectar con la base de datos, realiza una peticin al listener, el cual conoceel estado actual de la base de datos. En caso de estar todo correcto, respondecon un puerto al que el cliente debe conectar para realizar sus consultas direc-tamente contra la base de datos, mediante la autenticacin correspondiente.


Este proceso puede estar protegido o no. En las versiones anteriores a 10g nolo estaba en la configuracin por defecto, lo que supona un serio riesgo deseguridad, ya que se permita la administracin de lsnctrl remotamente a noser que el administrador de la base de datos lo evitara con una configuracinpersonalizada.

En caso de encontrar un proceso TNS listener desprotegido, es posible conocerinformacin acerca de la instancia de Oracle, como conocer los nombres delas bases de datos que alberga y ms informacin del sistema. Esto sin tener encuenta un gran nmero de vulnerabilidades ms avanzadas que se describenms adelante. En caso de estar protegido, tambin es posible obtener informa-cin acerca de los nombres de las bases de datos que alberga mediante ataquesde fuerza bruta.

Otro proceso destacable es el Oracle intelligent agent, que escucha en los puertosTCP 1748, 1808 y 1809. Realiza varias funciones, entre las cuales guardar datosrelativos a la administracin de los datos y a su rendimiento. Es interesante elproceso porque se puede consultar de forma remota sin necesidad de presen-tar ningn tipo de autenticacin, de forma que proporciona informacin quepuede resultar interesante a un atacante, como los procesos en ejecucin, eluso de memoria, etc.

5.2. Microsoft SQL

Microsoft SQL Server es una base de datos muy popular, en buena parte graciasa la gran cantidad de sistemas Microsoft Windows en todo el mundo, lo queno quiere decir que no sea un buen producto. Este motor de base de datosnicamente est disponible para sistemas Windows.

Microsoft comenz la evolucin en solitario de su motor de base de datos ba-sado en el cdigo desarrollado por Sybase, colaborador conjunto en las prime-ras versiones de SQL Server. Sin embargo a finales de los noventa, Microsoftadquiri todos los derechos de SQL Server y comenz su desarrollo basado enel cdigo de Sybase, pero reescribiendo su totalidad.

Su adopcin por parte del mercado comenz a partir de empresas pequeasy medianas, en las que acostumbran (o acostumbraban) a abundar sistemasWindows, aunque ha ido ganando cuota de mercado en las ltimas versionesa la par que mejoraba su rendimiento, seguridad y escalabilidad y se adopta-ban soluciones Windows para servidores de produccin tambin en grandesempresas. Esta ltima consecuencia, presumiblemente, se debe a la mejora delos sistemas servidores Windows en las ltimas versiones. Destacar que en elmomento de su entrada en mercado, MS-SQL Server no era un obstculo anivel econmico tan importante como otros productos ms consolidados enel mercado, lo que sin duda ayud a su adopcin inicial. En el 2001 era la basede datos ms popular en sistemas Windows.

Ved tambin

En el mdulo Ataques a apli-caciones web veremos msdetalladamente los ataques defuerza bruta.


La versin de SQL implementada por SQL Server se conoce como T-SQL, oTransact-SQL, y es una variante del estndar SQL-92 adoptado por la empresa,aunque con pequeas caractersticas propias tal y como introducen todos losvendedores de bases de datos.


Microsoft comenz a desarrollar a finales de los ochenta junto con Sybase laprimera versin de un motor de base de datos para competir con las grandesempresas hegemnicas en el mercado en aquella poca, como Oracle o IBM.Fruto de este trabajo apareci SQL Server 1.0 para OS/2. Posteriormente apa-reci la versin 3.0 para Unix, pero no fue hasta 1992 cuando apareci la pri-mera versin de Microsoft SQL Server como tal, la 4.2.

Figura 7. SQL Server 1.0 en OS/2

La siguiente versin que apareci fue la 6.0, para arquitecturas NT. A partir deesta versin, Microsoft negoci la exclusividad para el cdigo de SQL Serveren sus sistemas operativos, por lo que acaba la aventura conjunta con Sybase.

SQL Server 7.0 aparece en 1997, reescrita totalmente a partir del cdigo origi-nal de Sybase y es la primera versin que incorpora una interfaz grfica. Esun gran xito comercial y se considera la primera versin propia totalmentede Microsoft.

A partir de este punto las versiones han sido SQL Server 2000, lanzado enel 2000, y el 2005, ambas en distintos paquetes con distinta funcionalidadpara abarcar todo el espectro profesional del mercado. Estas son evolucionesnaturales del producto segn las demandas del mercado, logrando que enla actualidad sea un motor de base de datos fiable y con pocos problemas deseguridad conocidos. Las ltimas versiones soportan arquitecturas de 64 bits.


5.2.2. Arquitectura

En contraste con otras bases de datos que corren en distintos sistemas opera-tivos, SQL Server solo lo hace en Microsoft Windows, lo que determina mu-chas de sus caractersticas. Las posibilidades de combinacin de sistema ope-rativohardware es mucho menor que para algunos de sus competidores, co-mo Oracle, en que esta combinacin puede llegar a 26 casos. Es por esta raznpor lo que en algunos aspectos este hecho puede repercutir directamente enla seguridad, como en algunos gusanos que utilicen desbordamiento de bferpara conseguir la ejecucin de cdigo malicioso y puedan aprovechar direc-ciones de memoria o llamadas a la API del sistema operativo sin necesidad deafrontar una casustica compleja.

En este apartado se explican las caractersticas principales de la arquitecturade SQL Server 2000. Tanto la versin anterior (7) como la posterior (2005) sonmuy similares y las diferencias se comentan cuando es necesario. Aunque exis-ten diferencias, estas no son relevantes, ya que nuestro objetivo es presentarlas principales caractersticas estructurales de las bases de datos en cuanto aseguridad se refiere.

El principal proceso de SQL Server es sqlservr.exe (servicio MSSQLServer), ypor defecto escucha las peticiones en el puerto 1433. Se trata del servicio de labase de datos propiamente dicha, que accede y almacena los datos. La versinde SQL Server 2000 tambin escucha en el puerto 1434 UDP con el servicio SQLServer Monitor, el cual informa del estado del servidor a una peticin concreta.Como veremos ms adelante, este puerto proporciona posible informacin aun atacante, por lo que se desaconseja su acceso pblico. Estos puertos puedencambiarse, lo que es una prctica recomendable en cualquier base de datos paraevitar desvelar de forma inmediata el servicio que se encuentra tras un puerto.SQL Server dispone de una opcin para ocultarse de escaneos, llamada hideserver, mediante la que automticamente pasa a escuchar del puerto 2433 ydeja de responder a peticiones broadcast, aunque esta opcin tiene algunosproblemas cuando hay mltiples instancias del servidor.

Otro proceso importante es sqlmangr.exe (SQL Manager) cuya utilidad esarrancar y parar el servidor de la base de datos as como el agente SQL. El agen-te SQL (SQL Agent, servicio SQLServerAgent) es el proceso que se encarga delanzar tareas y procedimientos de forma programada anteriormente, una es-pecie de planificador para lanzar trabajos contra la base de datos. En la versin2005, este proceso ha recibido importantes mejoras en aspectos de seguridad.

Finalmente, existen otros servicios en SQL Server:

Open data services: Se tata de una interfaz entre las bibliotecas (Net-libraries)y las aplicaciones que utiliza el servidor. Su funcionamiento est intrnse-


camente ligado con el de los procedimientos extendidos, que se explicanposteriormente en este apartado.

Microsoft search service: Proporciona soporte para funcionalidades de bs-queda en texto y de indexacin en tablas. Esta funcionalidad se imple-mentaba como un servicio distinto en SQL Server versin 7, aunque pos-teriormente se integr con el servicio MSSQLServer.

Microsoft distributed transaction coordinator (MS DTC service): Servicio pa-ra coordinar transacciones entre distintos servidores implicados en unatransaccin distribuida.

Los datos fsicos se guardan en archivos con las siguientes extensiones:

mdf: Son los archivos primarios de la base de datos y apuntan al resto dearchivos que forman parte de la misma.

ndf: Son los archivos secundarios y guardan toda la informacin que nose guarda en los archivos primarios.

lgf: Guardan toda la informacin de log relativa a la base de datos y utili-zada para la recuperacin de datos en un punto de tiempo fijado.

Figura 8. Tipos de ficheros

Cada instalacin de SQL Server tiene cuatro bases de datos por defecto:

master: Es la ms importante y almacena la informacin de catlogo delresto de objetos de la base de datos.

model: Guarda las plantillas para la creacin de todas las bases de datosdel sistema.

tempdb: Guarda informacin temporal de tablas y de procedimientos.


msdb: La utiliza el servidor para lanzar alertas y trabajos programados conel SQL server agent.

En cuanto a las tablas ms importantes del catlogo de SQL Server, el esquemase almacena en la base de datos master. Algunas de las tablas ms destacablesson:

sysobjects: Almacena todas las tablas de las bases de datos. syscolumns: Almacena las columnas de las tablas de las bases de datos. sysusers: Informacin acerca de los usuarios de la base de datos. sysdatabases: Bases de datos disponibles. sysxlogins: Informacin acerca de las cuentas de usuario.

SQL Server dispone de varios roles de usuario predefinidos que tienen unospermisos preestablecidos. Estos se dividen en rolesdeservidor, que contem-plan aspectos de la administracin del servidor de base de datos, y rolesdebasededatos, que contemplan aspectos referentes a las bases de datos en s.Dichos roles no se pueden cambiar, crear ni borrar. Los ms destacables deservidor son:

dbcreator: Permite la creacin y administracin de bases de datos. diskadmin: Acceso y administracin de dispositivos de almacenamiento

fsicos. securityadmin: Permite la creacin y administracin de roles y usuarios. sysadmin: Control administrativo total sobre el servidor.

En cuanto a los roles de base de datos, los ms destacables son:

db_datareader: Permite el acceso de lectura a una base de datos. db_datawriter: Permite la modificacin, creacin y borrado de datos. db_owner: Permite realizar cualquier operacin en la base de datos. db_securityadmin: Permite la administracin de roles y de permisos de

objetos.

SQL Server permite la creacin de roles de usuario a los que se permiteasignar permisos de modo personalizado con cualquier objeto de la basede datos.

La autenticacin en SQL Server se realiza mediante dos mecanismos: autenti-cacin nativa de la base de datos y autenticacin mediante el sistema operati-vo. Tambin se proporcionan tres frmulas para este proceso:

nativa, sistema operativo,


mixta.

El hecho de poder utilizar la autenticacindelsistemaoperativo es algunade las caractersticas derivadas de su relacin con el mismo, as como de notener que ser flexible como para poder ejecutarse en otros sistemas operativosque no sean de Microsoft.

En el caso de la autenticacinnativa de SQL Server, los datos que se transmi-ten al servidor no se cifran, nicamente se ofuscan mediante una transforma-cin reversible, por lo que, en caso de no realizarse la autenticacin de formalocal o mediante una conexin segura, pueden ser interceptados y capturadossin dificultad. Es recomendable utilizar la autenticacin que proporciona me-diante el sistema operativo o asegurar que la comunicacin siempre es a travsde un canal cifrado.

Versin 2000

Este problema se da en la versin 2000 de la base de datos, ya que la 2005 proporcionanuevas funcionalidades para solucionar este problema, incluso proporcionando la opcinde crear certificados digitales para la autenticacin de usuarios. Adems, proporcionafuncionalidad para exigir una mnima complejidad y longitud en las contraseas, ascomo un tiempo de expiracin para su renovacin regular.

La autenticacinmixta simplemente mezcla ambos sistemas y realiza el pro-ceso en dos fases: primero comprueba las credenciales mediante el sistemaoperativo y posteriormente con las credenciales propias para el usuario de ba-se de datos.

TDS (tabular data stream protocol) es el protocolo que utiliza SQL Server para lacomunicacin clienteservidor, incluyendo la autenticacin y las peticiones yrespuestas de consultas a la base de datos. Existen implementaciones libres deeste protocolo ms all de la proporcionada por Microsoft.

Network libraries son las bibliotecas que utiliza SQL Server para la comunica-cin por red con los clientes. Por defecto la comunicacin se realiza medianteTPC/IP, aunque tambin es posible especificar comunicacin mediante named-pipes (en este caso ms lenta y nicamente en el mismo servidor), medianteshared memory (memoria compartida) en la que la comunicacin tambin eslocal pero obtiene la mxima velocidad disponible o mediante SSL (secure soc-ket layer) para cifrar la comunicacin entre ambos extremos. Existen varias bi-bliotecas adicionales que soportan protocolos menos comunes, siendo la ma-yora de ellos antiguos y nicamente existentes por cuestiones de compatibi-lidad.


Figura 9. Protocolos soportados para comunicacin cliente-servidor

Los procedimientos almacenados en SQL Server tienen la misma funcionali-dad que en otras bases de datos, que es la de extender la capacidad de las con-sultas mediante la creacin de procedimientos mediante el lenguaje de pro-gramacin TSQL. Adems, SQL Server proporciona los procedimientos alma-cenados extendidos (XSP eXtended Stored Procedures) que permiten crear nuevafuncionalidad mediante la creacin de procedimientos en lenguaje de alto ni-vel con C o C++ y almacenarlos en dlls para que pueda acceder a dichas fun-ciones la base de datos mediante la API de open dataservices .

Algunos de los procedimientos almacenados de SQL Server son el primer ob-jetivo de un atacante a la base de datos, debido a la gran potencia de los mis-mos, como veremos ms adelante. Cabe destacar que procedimientos comoxp_cmdshell permiten la ejecucin de comandos directamente contra el siste-ma operativo de la mquina que alberga la base de datos, por lo que se entien-de rpidamente por qu estos procedimientos son el primer objetivo de unataque. Por ello, es recomendable no dar permisos a ningn usuario que nosea el administrador, o eliminarlos completamente en caso de no ser necesa-rios. En caso de su eliminacin de la base de datos, es buena idea el borrado delas dll que proporcionan la funcionalidad para evitar que vuelvan a incluirsedentro de las funcionalidades de la base de datos.


SQL Server proporciona un mecanismo de encriptado de los procedimientosalmacenados para evitar la consulta del cdigo de los mismos.

5.3. MySQL

5.3.1. Introduccin

MySQL es una base de datos muy popular hoy en da a pesar de ser una de lasltimas en aparecer en el mercado a pesar de la falta de muchas funcionalida-des hasta versiones muy recientes. Segn la compaa, hay ms de 10 millonesde instalaciones de su producto en la actualidad. De hecho y desde un puntode vista purista, MySQL ha carecido de algunas de las principales caractersti-cas consideradas necesarias para un motor de bases relacional. Sin embargo,su popularidad se debe a la conjuncin del boom de Internet y a ser una basede datos de cdigo libre, aunque este aspecto se matiza ms adelante.

La falta de caractersticas funcionales de integridad no ha sido un obstculopara su popularidad. En un momento de aparicin de gran cantidad de aplica-tivos bajo licencias libres de todo tipo, la posibilidad de disponer de una basede datos bajo estas mismas condiciones y con un rendimiento aceptable paralas operaciones menos complejas fue todo un hito.

A partir de ese punto, MySQL fue cobrando popularidad con gran rapidez, pa-sando a un nuevo modelo de negocio en las versiones ms recientes. Hastaentonces sus ingresos se basaban en las certificaciones y el cobro de licenciaspara empresas que deseaban usar el producto bajo licencia no GPL. Sin em-bargo, a partir de la versin 5 se cre un nuevo concepto con la versin deMySQL Enterprise, que incluye adems del motor de base de datos relacionalun soporte continuo para clientes, ya pensado para un mercado ms empre-sarial en el que este tipo de servicios son necesarios. Para no perder sus ra-ces, MySQL continua en paralelo el desarrollo de MySQL 5 Community Edi-tion en un modelo parecido al adoptado por Red Hat con Fedora, siendo ladiferencia entre ambas versiones la disponibilidad de binarios compilados yoptimizados para distintas plataformas, que dejan de estar disponibles para laversin Community, as como el compromiso de la publicacin de versionesnuevas puntualmente cada mes con todos los bugs corregidos para la versinEnterprise. El cdigo contina disponible para su descarga bajo licencia GPL.

A pesar de su falta de implementacin de caractersticas bsicas en cualquierbase de datos relacional, como la integridad referencial, MySQL ha ido evo-lucionando poco a poco hasta llegar a un punto en que dispone de las mis-mas funcionalidades bsicas que cualquier otra base de datos comercial. Sinembargo, es importante no olvidar que el camino de su popularizacin fue sulicencia libre, su capacidad para correr en prcticamente cualquier plataformay su funcionamiento correcto como base de datos ligera para las funcionali-dades ms bsicas. En particular, lo que se conoce como plataforma LAMP


(con sus variaciones) que ha sido uno de los pilares de creacin de gestores decontenido en Internet (LAMP: Linux + Apache + MySQL + PHP), permitiendoprcticamente a cualquiera la creacin de aplicativos con una inversin mni-ma. MySQL fue el complemento ideal a una serie de herramientas de similarfilosofa y que irrumpi en el mercado en el momento adecuado. Hoy en dase encuentra en multitud de gestores de contenido libres, por lo que su cono-cimiento en cuanto a seguridad es muy importante por su gran presencia enel mercado. Es ms, debido a su historia y el entorno de popularizacin, sueleestar presente en muchas ocasiones en la DMZ de las compaas, constituyen-do un riesgo potencial en caso de no estar debidamente securizado.


MySQL es el nombre de la base de datos perteneciente a MySQL AB, que es lacompaa sueca que la cre (AB es el equivalente a S. A. en castellano). Desdeel momento de su creacin, la compaa ha querido instaurar una filosofade empresa parecida al famoso don't be evil de Google, destacando una seriede valores que se vieran reflejados en su comportamiento y productos y quese resume en una nica frase enunciada por ellos mismos: To make superiordata management software available and affordable to all (Crear software deadministracin de datos de calidad superior, disponible para todo el mundo).La compaa se fund por David Axmark, Allan Larsson y Monty Widenius.El nombre de la base de datos es por el hijo de Monty, llamado My (nombresueco).

Todas las versiones de MySQL estn disponibles para gran cantidad de plata-formas, lo que no es sorprendente siendo un producto de cdigo libre. Siemprees posible intentar la compilacin para nuevas plataformas, pero en la actua-lidad est disponible en su versin Enterprise para Red Hat Enterprise Linux,Novell SuSE Enterprise Linux, Debian GNU/Linux, Sun Solaris 10 y 9 y 8, HP-UX 11.23, Windows NT/2000, Windows XP, Windows 2003 Server, Apple MacOS X v10.4, IBM AIX, OpenServer 6.0,Fedora, openSUSE, CentOS y Ubuntu.La versin Community est disponible todava para ms plataformas, por loque queda patente la flexibilidad del motor de base de datos.

El cdigo inicial fue creado por Monty a finales de los ochenta, principiosde los noventa para uso propio. Segn fue creciendo el proyecto y aadien-do nuevas funcionalidades, empez a pensar en fundar una pequea compa-a para la comercializacin del producto. A mediados de los noventa fundaMySQL AB y se buscan inversores de capital riesgo para invertir en el desarrollodel producto, dando paso a las sucesivas versiones cada vez con mayor fun-cionalidad, si bien hasta la versin 5 no se han implementado caractersticasconsideradas como muy importantes, como pueden ser los procedimientosalmacenados, triggers o cumplimiento de las propiedades ACID (atomicidad,consistencia, isolacin y durabilidad) consideradas bsicas para bases de datosrelacionales. Es en esta poca cuando la compaa se traslada a California.


La adquisicin de la compaa por parte de Oracle puso toda esta filosofa enjaque. Desde entonces existe una community edition de cdigo abierto y otraversin nicamente de pago y que implementa las ltimas caractersticas. Estoha hecho que haya perdido parte de su pblico que han decidido migrar aotras soluciones de cdigo abierto. Uno de los fundadores de MySql decidiabandonarla para crear una nueva base de datos que siguiese la misma filosofainicial de MySql.

5.3.3. Arquitectura

El principal programa de la base de datos es mysqld, aunque dependiendo delentorno puede ser mysqld-nt, que es el equivalente para entornos Windows, omysqld-max, en caso de que incorpore la base de datos MaxDB. Se trata de unsoporte a otro tipo de base de datos que tambin desarrolla MySQL AB, conun impacto en el mercado muy marginal y que no trataremos. Este programaes el que se encarga del acceso y tratamiento del motor de la base de datos, elresto son programas cliente.

Hay distintos mtodos para la comunicacin cliente-servidor:

TCP/IP, tanto para conexiones locales como remotas. Named pipes, en conexiones remotas solo en sistemas Windows. Sockets, en conexiones remotas slo en sistemas Unix.

En conexiones TPC/IP, el servidor escucha por defecto en el puerto 3306.MySQL no utiliza ningn protocolo extrao de red, y a partir de la versin4.0 soporta el uso de SSL en conexiones de red.

Existen distintas interfaces para interactuar con la base de datos como la libre-ra C llamada libmysqlclient, el conector ODBC o el conector JDBC.

En cuanto al tratamiento de los archivos por parte de MySQL, se asocia cadabase de datos con un subdirectorio bajo el directorio de almacenamiento dedatos, especificado en el archivo de configuracin de MySQL (normalmenteen el archivo my.cnf). Cada subdirectorio tiene el nombre de la base de datosque representa. Una base de datos puede estar vaca y puede no contener nin-gn subdirectorio. Cada tabla dentro de la base de datos se representa en unfichero con extensin .frm que contiene la definicin de la tabla. En cuanto alalmacenamiento de los datos propiamente dichos, depende del tipo de tablas,y aqu es cuando entra en juego una de las caractersticas ms llamativas deMySQL.

A la hora de crear una tabla, es posible especificar el tipo de la misma, demodo que el motor de base de datos correspondiente ser el que se encargue detratarla. Esto implica que en funcin de dicho tipo, las tablas tendrn distintascaractersticas, lo que puede resultar confuso. La mejor aproximacin es pensarcomo si existiesen distintas bases de datos en una, y a la hora de definir las

APIs de MySQL

Aparte de estas interfaces, queson las que soporta oficialmen-te MySQL, existen multitud deAPIs desarrolladas de forma in-dependiente con soporte paraPHP, Perl, Python, Ruby, Pascaly Tcl.


tablas el usuario elije con qu motor quiere trabajar. En funcin de dicho tipo,tambin se guardarn los ficheros en disco con un formato u otro. MySQLsoporta los siguientes tipos de tabla:

MyISAM: Se trata del tipo de tabla ms popular y el tipo de tabla originalde MySQL disponible desde las primeras versiones. El motor que se encar-ga de tratar este tipo carece de muchas caractersticas deseables para basesde datos relacionales, por lo que no dispone de funcionalidad como inte-gridad referencial. Estas tablas se representan en disco como archivos conextensin .MYD para almacenar los datos y archivos con extensin .MYIpara almacenar los ndices.

InnoDB: Este motor es el que, en buena parte, ha permitido que MySQLhaya evolucionado hasta ser una base de datos seria implementando ca-ractersticas de las que carecen los otros motores. Es compatible con laspropiedades ACID y permite transacciones atmicas, por lo que se puedenconfirmar o refutar con Commit y Rollback respectivamente. Tambin im-plementa integridad referencial. En este caso, las tablas no se almacenanen disco usando distintos archivos, sino que se guardan todos los datosen un nico espacio de almacenamiento que utiliza el motor de InnoDBy que puede consistir en uno o varios archivos, segn va creciendo de ta-mao. Por defecto, el nombre del espacio en el que InnoDB almacena losdatos es ibdata1, y donde almacena los logs ib_logfile0 y ib_logfile1.

Tanto InnoDB como MyISAM son los principales motores de MySQL, los quese listan a continuacin tienen una utilidad ms marginal:

Merge: Las tablas de este motor son una coleccin de tablas MyISAM idn-ticas, representadas en disco con la extensin .frm para el formato de latabla y .MRG para listar todas las tablas MyISAM que forman parte de latabla Merge. En esencia, se trata de crear una entidad que aglutina un con-junto de tablas MyISAM idnticas con la finalidad de sobrepasar las limi-taciones de espacio de las primeras.

BDB (Berkeley DB): Las tablas en disco tienen una extensin .frm para elformato y .db para almacenamiento de datos e ndices. Este motor imple-menta las propiedades ACID y soporta transacciones atmicas, as comobloqueo a nivel de pgina, lo que puede provocar problemas de bloqueocomo precio para un aumento de la concurrencia.

Memory tables: Se trata de tablas que, aunque tienen la definicin en discoen un archivo con extensin .frm, guardan los datos e ndices en memoria,resultando en el tipo de tablas ms rpido disponible. Al usar un recursoescaso, no es un tipo factible para tablas grandes. Utiliza bloqueo a nivelde tabla, lo que baja la concurrencia y evita bloqueos.


En la versin 5 de MySQL se introducen nuevos motores adicionales a estos. Cabe des-tacar que es posible crear un motor propio y utilizarlo en MySQL mediante un procesorelativamente sencillo, lo que favorece la aparicin de nuevos motores con el paso deltiempo, especializados en distintas funcionalidades. Los nuevos motores disponibles sonel Example, Federated, Archive, CSV y Blackhole.

Como se ha visto, el motor de MySQL permite trabajar con distintos tipos debases de datos con caractersticas propias. Sin embargo, cabe destacar que re-cientemente dos de las compaas que trabajaban conjuntamente con MySQLen el desarrollo de estas bases de datos han sido adquiridas por la competen-cia. En concreto, Oracle compr en 2005 Innobase OY, la compaa finlandesaencargada del desarrollo del motor InnoDB. Teniendo en cuenta que este mo-tor era el que implementaba un mayor nmero de funcionalidades necesariaspara una base de datos relacional, implementando la integridad referencialdesde las primeras versiones, puede suponer un revs importante para MySQL,aunque han llegado a un acuerdo para continuar el desarrollo conjunto du-rante un tiempo.

Un caso similar ha ocurrido con la adquisicin, tambin por Oracle, de Sleepy-cat Software, la compaa creadora de la Berkeley DB y tambin usada porMySQL.

En cuanto al esquema de las bases de datos, desde la versin 5 MySQL incor-pora la base de datos Information Schema, que incorpora las tablas en las quese almacena la informacin respecto al resto de bases de datos y tablas (meta-datos). Algunas de las tablas ms interesantes son:

Tables: Informacin acerca de las tablas de otras bases de datos. Columns: Campos que componen las tablas. Views: Vistas disponibles. User_privileges: Permisos de los que disponen los usuarios. Routines: Almacena procedimientos y funciones.

En versiones anteriores a la 5 esta base de datos no exista, por lo que se debanconsultar estos datos en la base de datos llamada mysql. Aunque no se recogainformacin en la misma respecto a las tablas que conformaban otras bases dedatos, se guardaba informacin respecto a los usuarios, incluyendo los hashesde las contraseas. En concreto, esta informacin estaba disponible en la tablauser.

MySQL utiliza un sistema propio para la autenticacin, consistente en el uso deun par usuario-contrasea. Permite especificar junto con el nombre de usuarioel host desde el que se permite su autenticacin, por lo que un intento deconexin desde otro dispositivo no permitira entrar en el sistema a pesar deconocer tanto el usuario como la contrasea correcta. No permite ningunainteraccin con el sistema operativo para la autenticacin.

Otras tablas

Otras tablas interesantes erandb, tables_priv y host.


A nivel histrico, han existido problemas con la autenticacin en MySQL. Enconcreto, en versiones anteriores a la 4.1 el conocimiento del hash de la con-trasea era suficiente para lograr la autenticacin, sin necesidad de ningncrackeo. En versiones anteriores a la 3.23.11, exista una debilidad que per-mita lograr la autenticacin con un nico carcter, por lo que el historial de labase de datos es malo en cuanto a problemas de autenticacin, lo que se sumaa que en versiones antiguas no se utilizaba ningn tipo de cifrado en la auten-ticacin por red, por lo que los datos podan ser interceptados por cualquiera.

Las funciones definidas por el usuario (UDF, user definded functions) son exten-siones que permiten la creacin de nuevas funcionalidades mediante la pro-gramacin en lenguajes de alto nivel (C, C++) y su importacin desde la basede datos. Aunque este punto se trata con ms detalle en prximos captulos,cabe decir que la potencia que aporta es enorme, as como los riesgos en casode no ser cuidadosos.

El tratamiento en el almacenamiento de datos que se utiliza en MySQL es bas-tante particular, no es frecuente encontrar la correspondencia tan directa en-tre bases de datos y tablas con archivos en disco. Esto implica que es necesarioun cuidado especial a la hora de securizar los permisos sobre estos archivos,porque el acceso a los mismos por parte de un usuario no autorizado implicala disponibilidad directa de los datos, siendo factible incluso la modificacinde los mismos sin demasiada dificultad.

En cuanto a los permisos en la base de datos, no existen roles predefinidos,sino que los permisos se asignan directamente a los usuarios. Hay que destacarque una vez que se cambian los privilegios, es necesario especificar de modoexplcito que se apliquen mediante la orden FLUSH PRIVILEGES, ya que hastaentonces no se producen los cambios. Los permisos pueden ser a dos niveles:

El primer nivel es en cuanto a los objetosdelabasededatos, siendo estolo habitual en otras bases de datos.

El segundo nivel es en cuanto a permisos de ejecutar ciertas acciones conelusuario en cuestin, como acceder a disco para cargar datos de un ar-chivo concreto o para guardar los resultados de una consulta en otro. Ensiguientes mdulos se explica cmo esta caracterstica es una de las msllamativas y que se debe tener muy en cuenta a la hora de securizar la basede datos correctamente.

5.4. DB2

DB2 Universal Database, creado por IBM, se considera por algunos como laprimera base de datos en utilizar SQL. Se trata de una de las bases de datosms veteranas en la industria.


Aunque esta base de datos tiene un porcentaje de mercado importante, da laimpresin de tener una presencia menor a la que muestran las estadsticas, talvez porque no est habitualmente expuesta a ent

seguridad en bases de datos (modulo 1)

Documents