UNIDAD 1 INSTALACION DE SERVIDORES 1.1 Planificación de la Instalacion. 1.2 Análisis de Requerimientos. 1.3 Servidores de Bases de Datos. 1.4 Tipos de usuarios. 1.5 Calculo de espacio de memoria requerido. 1.6 Instalacion de Diferentes sistemas operativos. 1.7 Sistemas de Respaldo 1.8 Sistemas de energía interrumpida1.9 Estándares UNIDAD 2 ADMINISTRACIÓN DE SERVICIOS 2.1 Servidores de páginas de internet. 2.1.1 HTTP 2.1.2 SHTTP 2.2 Servidores de FTP, SFTP, TFTP 2.3 Servidor de correo electrónico. 2.4 Servidor de bases de datos. 2.5 Servidor de DNS. 2.6 Servidor de SSH 2.7 Servidores de impresión. 2.8 Servidores Proxy. 2.9 Administración de usuarios. 2.10 Servidor de aplicaciones UNIDAD 3 SEGURIDAD EN SITIO 3.1 ISO 17799 3.1.1 Dominios de control. 3.1.2 Objetivos de control. 3.1.3 Auditorias. 3.1.4 Consultoría 3.1.5 Implantación. UNIDAD 4 CONTROL DE ACCESO 4.1 Seguridad perimentral 4.2 Control de Acceso 4.3 Autenticación 4.4 Control de acceso criptográfico 4.5 Detección de intrusos 4.6 Bitácoras 4.6.1 Alcances de la Bitácora 4.6.2 Análisis de la Bitácora 4.7 Monitoreo de actividad de usuarios 4.8 Marco legal UNIDAD 5 TECNICAS Y HERRAMIENTAS PARA PROTECCION Y MONITOREO DE SERVIDORES 5.1 Protocolo SNMP 5.2 Corta fuegos físicos y lógicos 5.3 Husmeadores 5.4 Correo no deseado 2.1 Servidores de pagina de internet Editar 0 0 1… Un servidor web o servidor HTTP es un programa informático que procesa una aplicación del lado del servidor realizando conexiones bidireccionales y/o unidireccionales y síncronas o asíncronas con el cliente generando o cediendo una respuesta en cualquier lenguaje o Aplicación del lado del cliente. El código recibido por el cliente suele ser compilado y ejecutado por un navegador web. Para la transmisión de todos estos datos suele utilizarse algún protocolo. Generalmente se utiliza el protocolo HTTP para estas comunicaciones, perteneciente a la capa de aplicación del modelo OSI. El término también se emplea para referirse al ordenador que ejecuta el programa. Arquitectura Petición GET Un servidor web opera mediante el protocolo HTTP, de la capa de aplicación del Modelo OSI. Al protocolo HTTP se le asigna habitualmente el puerto TCP 80. Las peticiones al servidor suelen realizarse mediante HTTP utilizando el método de petición GET en el que el recurso se solicita a través de la url al servidor web. GET /index.html HTTP/1.1 HOST: www.host.com En la barra de URL de un navegador cualquiera la petición anterior sería análoga a la siguiente dirección Web: www.host.com/index.html Esquema de una petición GET Petición Web Véase también: Navegador Web Véase también: Telnet El navegador por medio de la interfaz de usuario permite al usuario realizar una o varias peticiones web. La interfaz de usuario o entorno de usuario es el conjunto de elementos del navegador que permiten realizar la petición de forma activa. Una petición Web no sólo puede ser realizada mediante un navegador sino con cualquier herramienta habilitada para tal fin, como una consola de comandos Telnet. Elementos del entorno de usuario más comunes en navegadores Web visuales: Nombre Descripción Hipervínculo enlace o link Es una porción de contenido Web, texto, imagen y otros elementos, que enlaza con una dirección Web. Al pulsar un hipervínculo el navegador genera una petición GET automática a la dirección URL de dicho link. Formulario web Al realizar el envío satisfactorio de los datos de un formulario, el navegador Web genera una petición GET o POST (comúnmente POST) automática a la par que envía los datos al servidor. Barra de direcciones Todos los navegadores incluyen una barra de direcciones mediante la cual puede accederse manualmente a cualquier dirección URL, de modo que el navegador generará una petición GET automática a dicha URL cada vez que el usuario lo desee. Script activo o pasivo Cualquier aplicación Javascript tiene acceso al estado del navegador, cómo puede modificar los datos que describen tal estado, de forma pasiva (sin medio de la intervención del usuario) o de forma activa (mediante alguna acción del usuario). 1.1 Socket a dirección DNS Se produce una socket con un servidor dado en dirección IP mediante TCP. Por lo general las direcciones que el navegador posee inicialmente son direcciones DNS (direcciones alfanuméricas) que deberá convertir a direcciones numéricas. 1.2 Resolución de DNS a IP Si la dirección dada es DNS y no existe una regla en la base de datos DNS, el Host Resolver Request solicita al servidor DNS la o las direcciones IPs correspondientes. El navegador crea una nueva regla y almacena la dirección IP junto a la dirección DNS en su base de datos de reglas DNS. 1.3 Recuperación de la regla DNS Una vez almacenada la regla se realiza una petición a la base de datos DNS para recuperar los valores de la regla. 1.4 Socket a dirección IP Se produce una socket con la dirección IP mediante TCP. La dirección IP puede haberse recuperado en el paso anterior. SOCKET 192.168.0.1 1.5 Preparación de la petición Se crea la petición GET estableciendo la url, un flag, la priority de la petición y el method (implícitamente GET). 1.6 Apertura Caché Se abre y/o se crea una entrada en el http cache 1.7 Efectuación de la petición Se realiza la petición GET. Se leen las cabeceras HTTP de la http transaction y más tarde el cuerpo de la http transaction. GET /index.html HTTP/1.1 1.8 Consulta en Caché Se consulta en el caché de disco si existe una entrada en el caché asociada al recurso que se ha solicitado. Los valores son created (true o false) y key (la url del recurso). 1.9 Retribución boleana existencialista del recurso solicitado Si la entrada no existe (si el valor de created es false) se escriben los datos en el caché de disco. Si no, se lee directamente. 2.0 Presentación visual del recurso Se concluye la operación y se muestra en pantalla (si es preciso) la información. Petición GET pasiva Javascript permite realizar modificaciones en el estado del navegador. El estado del navegador viene definido por el array de objetos location del objeto global Window. Se referencia a tal objeto con window.location. En concreto window.location.href contiene la dirección actual del navegador Web. Si una parte del script ejecuta tal sentencia: window.location.href='http://wikipedia.org'; El navegador hará tal petición Web sin que el usuario haya mediado en tal circunstancia o sus efectos. Del mismo modo se producirá una nueva petición GET si se altera el valor de window.location.search o window.location.protocol. Procedimiento del navegador La tarea del navegador Web es crear la petición a partir de los datos recogidos en el entorno de usuario de elementos del mismo, como enlaces, el valor del texto de la barra de búsqueda, los metatags. <a href="http://es.wikipedia.org">Entrar</a> Al pulsar en el enlace, el navegador crea automáticamente la petición GET y las cabeceras de la petición en base a los metatags (cabeceras definidas), los cookies y cabeceras automáticas del navegador, para luego enviarlas junto a la petición al Servidor. Petición POST Es el segundo tipo de petición HTTP más utilizado. Los datos a enviar al servidor se incluyen en el cuerpo de la misma petición con las cabeceras HTTP asignadas correspondientemente respecto al tipo de petición. Generalmente se asocia con los formularios web en el que los datos suelen ser cifrados para enviarlos de manera segura al servidor. Por motivos de convención se incluye en la petición la cabecera application/x-www-formurlencoded que indica el formato o codificación de los datos a enviar; esta es variable->valor en el formato: variable=valor separada cada par variable->valor por &. Esta cabecera, en los formularios HTML se envía automáticamente, pero en otras tecnologías web tal como AJAX, si se desea hacer correctamente una petición POST debe ser especificado o instanciado el objeto: setRequestHeader("Content-type:application/x-www-form-urlencode"); ajax.send(data); Si se utilizase el método GET los datos deberían de ser añadidos a la URL, lo que los expondría a ser vistos de forma directa. Estructura de una petición POST Artículo principal: Cabeceras HTTP. Estructura típica de una petición POST Muestra Petition type POST url HTTP/1.1 POST comment.php HTTP/1.1 Referer http-url-referer index.php Content-Length contentlenght-int 63 Origin http-url-origin http://es.wikipedia.org User-Agent useragent-string Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) ... Content-Type content-type-string application/x-www-form-urlencoded Accept mimetypes-acceptedstring application/xml,application/xhtml+xml ... Accept- language-accepted-string es-ES,es;q=0.8 Language Accept-Charset charset-accepted-string ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie phpsessid-string PHPSESSID=gm0ugf96iojuldio8i51u92716 Accept-Encoding accept-encoding-string gzip,deflate,sdch Content &data=4&lang=es+es Content-string Composición de una petición POST Las cabeceras más comunes que se envían en una petición POST: Petition type: Especifica el tipo de petición HTTP. (Esta cabecera no tiene nombre, se envía tal cual) Referer: Especifica la url desde la cual se hizo la petición POST. Content-Length: Especifica la longitud en bytes de los datos enviados en el cuerpo de la petición. Origin: Especifica la url principal del sitio. User-Agent:Especifica el identificador del navegador Web desde el cual se hizo la petición. Content-Type: Especifica el formato o MIME de los datos enviados en el cuerpo de la petición. Accept: Especifica el MIME que se espera en la respuesta. Accept-Language: Especifica el código del lenguaje esperado en la respuesta. Accept-Charset: Especifica la codificación que se espera en la respuesta. Cookie: Especifica un identificador de sesión en la petición derivado de un cookie. Accept-Encoding: Especifica el tipo de codificación (generalmente compresión) que se espera de la respuesta. (No todos los navegadores envían esta cabecera) Estructura de una respuesta POST Artículo principal: Cabeceras HTTP. Estructura típica de una respuesta POST Muestra HTTP version & state HTTP-version-state HTTP/1.1 200 OK Date date-string Tue, 07 Jun 2011 05:52:31 GMT Server server-string Apache/2.2.17 (Win32) mod_ssl/2.2.17... Expires expire-date-string Thu, 19 Nov 1981 08:52:00 GMT Cache-Control Cache-control-string no-store, no-cache, must-revalidate... Pragma pragma-string no-cache Content-Length Content-length-int 297 Content-Type Content-type-string text/html Keep-Alive Keep-alive-string timeout=5, max=98 Connection Connection-string Keep-Alive X-Powered-By X-powered-by-string PHP/5.3.5 Codificación del mensaje del cuerpo de la petición Los datos que se envían en el cuerpo de la petición POST deben tener algún formato que permita manipularlos en un futuro procesamiento. Por ello la petición debe tener asignada la cabecera Content-Type cuyo valor será la codificación de los datos. De este modo el sistema podrá diferenciar entre variables aisladas, datos binarios, texto plano, o cualquier otro tipo de formato. El formato de una cadena de datos se denomina MIME y es el valor que deberá ser incluido en esta cabecera. En HTML la cabecera Content-Type se especifica automáticamente y su valor es application/xwww-form-urlencoded, no obstante pueden especificarse por estándar otros dos valores: multipart/form-data y text/plain utilizando el atributo enctype del elemento form de la siguiente manera <form enctype="multipart/form-data">...</form> <form enctype="text/plain">...</form> <form enctype="application/x-www-form-urlencoded">...</form> O cualquier otro valor MIME. El multipart/form-data se utiliza para enviar grandes cadenas binarias que suponen cualquier otro tipo de documento que no sea texto plano, como imágenes, vídeos o ejecutables. Para varios valores, separar por comas. El application/x-www-form-urlencoded codifica de forma automática los valores de todos los elementos del formulario del modo variable=valor, separados por &. El atributo name de un input suele ser el nombre de la variable y su value el valor. Los espacios se reemplazan por + y los caracteres no alfanuméricos por $HH donde HH representa el número hexadecimal del carácter ASCII. id=valor+de+la+variable&tama%A4o=4 que representado de otra forma es: id: valor de la variable tamaño: 4 Procedimiento del navegador El navegador recopila la información del formulario para crear la petición y enviarla. Las cabeceras las envía junto a la petición POST, y se recopilan en base a los metatags definidos en el código, los automáticos del navegador y los Cookies. Es el navegador, también, el que codifica los datos si es necesario. Funcionamiento El Servidor web se ejecuta en un ordenador manteniéndose a la espera de peticiones por parte de un cliente (un navegador web) y que responde a estas peticiones adecuadamente, mediante una página web que se exhibirá en el navegador o mostrando el respectivo mensaje si se detectó algún error. A modo de ejemplo, al teclear www.wikipedia.org en nuestro navegador, éste realiza una petición HTTP al servidor de dicha dirección. El servidor responde al cliente enviando el código HTML de la página; el cliente, una vez recibido el código, lo interpreta y lo exhibe en pantalla. Como vemos con este ejemplo, el cliente es el encargado de interpretar el código HTML, es decir, de mostrar las fuentes, los colores y la disposición de los textos y objetos de la página; el servidor tan sólo se limita a transferir el código de la página sin llevar a cabo ninguna interpretación de la misma. Además de la transferencia de código HTML, los Servidores web pueden entregar aplicaciones web. Éstas son porciones de código que se ejecutan cuando se realizan ciertas peticiones o respuestas HTTP. Hay que distinguir entre: Aplicaciones en el lado del cliente: el cliente web es el encargado de ejecutarlas en la máquina del usuario. Son las aplicaciones tipo Java "applets" o Javascript: el servidor proporciona el código de las aplicaciones al cliente y éste, mediante el navegador, las ejecuta. Es necesario, por tanto, que el cliente disponga de un navegador con capacidad para ejecutar aplicaciones (también llamadas scripts). Comúnmente, los navegadores permiten ejecutar aplicaciones escritas en lenguaje javascript y java, aunque pueden añadirse más lenguajes mediante el uso de plugins. Aplicaciones en el lado del servidor: el servidor web ejecuta la aplicación; ésta, una vez ejecutada, genera cierto código HTML; el servidor toma este código recién creado y lo envía al cliente por medio del protocolo HTTP. Las aplicaciones de servidor muchas veces suelen ser la mejor opción para realizar aplicaciones web. La razón es que, al ejecutarse ésta en el servidor y no en la máquina del cliente, éste no necesita ninguna capacidad añadida, como sí ocurre en el caso de querer ejecutar aplicaciones javascript o java. Así pues, cualquier cliente dotado de un navegador web básico puede utilizar este tipo de aplicaciones. El hecho de que HTTP y HTML estén íntimamente ligados no debe dar lugar a confundir ambos términos. HTML es un lenguaje de marcas y HTTP es un "protocolo". Aplicación del lado del Servidor Una aplicación del lado del servidor es cualquier programa o conjunto de instrucciones diseñadas con la finalidad de que un Servidor Web las procese para realizar alguna acción. Las aplicaciones del lado del servidor están escritas mediante algún lenguaje de programación, entre los que destacan: Lenguaje Fecha de primera versión estable Sistema operativo Última versión estable PHP 5.3.5 1995 Multiplataforma ASP.Net 1998 Windows (Algunas versiones) 4.0 Perl 1987 Multiplataforma 5.12.3 Python 1991 Multiplataforma 3.2.0 Ruby 1995 Multiplataforma 1.9.3-p125 El 75% de las aplicaciones del lado del servidor están escritas en PHP, siendo ASP y las demás opciones usadas de forma alternativa y muy casual.2 Procesamiento del lado del servidor Un servidor web tiene la función de procesar los scripts del lado del servidor para dar una salida en HTML y otros lenguajes del lado del cliente al Navegador Web del cliente. La información a procesar podrá ser cedida por el cliente al script mediante cualquier aplicación en el entorno del Navegador. Para ello pueden utilizarse formularios web, enlaces con los valores implícitos en la cadena o cualquier otro método. Servidor Procesamiento de PHP Artículo principal: PHP. En PHP existen variables Globales que representan variables y datos de la conexiones que establece el Servidor con el cliente. Método GET Contiene todas las variables que se envían a través del método HTTP GET, se referencian a través del Array unidimensional $_GET['variable']. Esta variable contiene el dato enviado por GET asociado a tal variable, en caso de que exista. Método POST Contiene todas las variables que se envían a través del método HTTP POST, se referencian a través del Array unidimensional $_POST['variable']. Esta variable contiene el dato enviado por POST asociado a tal variable. Sesiones Contiene datos de sesión adquiridos mediante una petición GET, POST o la lectura de una Cookie . Se referencia a través del Array unidimensional $_SESSION['variable'].Esta variable contiene un dato de session. Cookies Contiene datos sobre todas las cookies adquiridas en la petición al server, proporcionadas por el navegador en la petición HTTP. Se referencia a través del Array unidimensional $_COOKIES['variable'] Servidor Contiene datos proporcionados por el Servidor Web. Se referencia a través del Array unidimensional $_SERVER['variable'] Procesamiento 1) Dado el siguiente código PHP. <span class="kw1">if</span><span class="br0">(</span><span class="sy0">!</span><span class="kw3">empty</span><span class="br0">(</span><span class="re0">$_GET</span><span class="br0">[</span><span class="st_h">'ip'</span><span class="br0">]){</span> <span class="kw1">if</span><span class="br0">(</span><span class="re0">$_GET</span><span class="br0">[</span><span class="st_h">'ip'</span><span class="br0">]</span><span class="sy0">==</span><span class="st0">"yes"</span><span class="br0">){</span> ip<span class="br0">()</span><span class="sy0">;</span> <span class="br0">}}</span> <span class="kw2">function</span> ip<span class="br0">(){</span> <span class="kw1">if</span> <span class="br0">(</span><span class="re0">$_SERVER</span><span class="br0">[</span><span class="st_h">'REMOTE_ADDR'</span><span class="br0">]</span><span class="sy0">==</span><span class="st0">"192.168.0.1"</span><span class="br0">){</span> <span class="kw1">echo</span> <span class="st0">"<b>Su dirección web es 192.168.0.1 </b>"</span><span class="sy0">;</span> <span class="br0">}</span> <span class="kw1">else</span> <span class="br0">{</span> <span class="kw1">echo</span> <span class="st0">"<b>Su dirección web no es 192.168.0.1 sino "</span><span class="sy0">.</span><span class="re0">$_SERVER</span><span class="br0">[</span><span class="st_h">'REMOTE_ADDR'</span><span class="br0">]</span><span class="sy0">.</span><span class="st0">"</b>"</span><span class="sy0">;</span> <span class="br0">}}</span> En el caso anterior, podría tomarse por supuesta la decisión del usuario utilizando un enlace cuyo destino sea el archivo que contenga el Script anterior + la variable y el valor utilizando la siguiente sintaxis: archivo.php?var=val donde var es el nombre de una variable dada y val es valor asignado a la variable. 2) En caso afirmativo el Script anterior genera el siguiente código html que es enviado posteriormente al navegador. <span class="sc2"><</span><span class="kw2">b</span><span class="sc2">></span>Su dirección web es 192.168.0.1 <span class="sc2"><</span><span class="sy0">/</span><span class="kw2">b</span><span class="sc2">></span> 3) El navegador interpreta el código html y lo muestra similar a : Su dirección web es 192.168.0.1 Servidor Web Local Un Servidor Web Local es aquel Servidor Web que reside en una red local al equipo de referencia. El Servidor web Local puede estar instalado en cualquiera de los equipos que forman parte de una red local. Es por tanto obvio, que todos los Servidores Web, son locales a la red local en la que se encuentran, o como mínimo, locales al sistema en el que están instalados. Cuando un servidor Web se encuentra instalado en el mismo equipo desde el cual se desea acceder puede utilizarse la dirección de Loopback, 127.0.0.1 en Ipv4 y ::1 en Ipv6. El puerto TCP 80 se obvia. Los archivos se almacenan en un directorio determinado por la configuración, generalmente modificable. Existen numerosas aplicaciones que facilitan la instalación automática de servidores web Apache y aplicaciones adicionales como Mysql y PHP (entre otros), de forma conjunta, como XAMPP, JAMP o EasyPHP. Estas aplicaciones reciben el nombre de LAMP cuando se instalan en plataformas Linux, WAMP en sistemas Windows y MAMP en sistemas Apple Macintosh. Software Algunos servidores web importantes son: Apache Internet Information Services (IIS) Cherokee Tomcat Otros servidores, más simples pero más rápidos, son: lighttpd thttpd 2.10 Servidor de aplicaciones En informática, se denomina servidor de aplicaciones a un servidor en una red de computadores que ejecuta ciertas aplicaciones. Usualmente se trata de un dispositivo de software que proporciona servicios de aplicación a las computadoras cliente. Un servidor de aplicaciones generalmente gestiona la mayor parte (o la totalidad) de las funciones de lógica de negocio y de acceso a los datos de la aplicación. Los principales beneficios de la aplicación de la tecnología de servidores de aplicación son la centralización y la disminución de la complejidad en el desarrollo de aplicaciones. Servidores de aplicación Java EE Editar 0 0 1… Como consecuencia del éxito del lenguaje de programación Java, el término servidor de aplicaciones usualmente hace referencia a un servidor de aplicaciones Java EE. Entre los servidores de aplicación Java EE privativos más conocidos se encuentran WebLogic de Oracle (antes BEA Systems) y WebSphere de IBM. EAServer de Sybase Inc. es también conocido por ofrecer soporte a otros lenguajes diferentes a Java, como PowerBuilder. Entre los servidores de aplicaciones libres se encuentran JOnAS del consorcio ObjectWeb, JBoss AS de JBoss (división de Red Hat), Geronimo de Apache, TomEE de Apache, Resin Java Application Server de Caucho Technology, Blazix de Desiderata Software, Enhydra Server de Enhydra.org y GlassFish de Oracle. Mucha gente confunde Tomcat como un servidor de aplicaciones; sin embargo, es solamente un contenedor de servlets. Java EE provee estándares que permiten a un servidor de aplicaciones servir como "contenedor" de los componentes que conforman dichas aplicaciones. Estos componentes, escritos en lenguaje Java, usualmente se conocen como Servlets, Java Server Pages (JSPs) y Enterprise JavaBeans (EJBs) y permiten implementar diferentes capas de la aplicación, como la interfaz de usuario, la lógica de negocio, la gestión de sesiones de usuario o el acceso a bases de datos remotas. La portabilidad de Java también ha permitido que los servidores de aplicación Java EE se encuentren disponibles sobre una gran variedad de plataformas, como Unix, Microsoft Windows y GNU/Linux. Otros servidores de aplicación Características comunes Usos El término servidor de aplicaciones también ha sido aplicado a otros productos no-J2EE. Por ejemplo, con el aumento de la popularidad de .NET, Microsoft califica a su producto Internet Information Server como un servidor de aplicaciones. Adicionalmente, se pueden encontrar servidores de aplicación de código abierto y comerciales de otros proveedores; algunos ejemplos son Base4 Server y Zope. Los servidores de aplicación típicamente incluyen también middleware (o software de conectividad) que les permite intercomunicarse con variados servicios, para efectos de confiabilidad, seguridad, no-repudio, etc. Los servidores de aplicación también brindan a los desarrolladores una Interfaz para Programación de Aplicaciones (API), de tal manera que no tengan que preocuparse por el sistema operativo o por la gran cantidad de interfaces requeridas en una aplicación web moderna. Los servidores de aplicación también brindan soporte a una gran variedad de estándares, tales como HTML, XML, IIOP, JDBC, SSL, etc., que les permiten su funcionamiento en ambientes web (como Internet) y la conexión a una gran variedad de fuentes de datos, sistemas y dispositivos. Un ejemplo común del uso de servidores de aplicación (y de sus componentes) son los portales de Internet, que permiten a las empresas la gestión y divulgación de su información, y un punto único de entrada a los usuarios internos y externos. Teniendo como base un servidor de aplicación, dichos portales permiten tener acceso a información y servicios (comoservicios Web) de manera segura y transparente, desde cualquier dispositivo. 2.2 Servidores de ftp Editar 0 0 1… FTP (siglas en inglés de File Transfer Protocol, 'Protocolo de Transferencia de Archivos') en informática, es un protocolo de red para la transferencia de archivos entre sistemas conectados a una red TCP (Transmission Control Protocol), basado en la arquitectura cliente-servidor. Desde un equipo cliente se puede conectar a un servidor para descargar archivos desde él o para enviarle archivos, independientemente del sistema operativo utilizado en cada equipo. El servicio FTP es ofrecido por la capa de aplicación del modelo de capas de red TCP/IP al usuario, utilizando normalmente el puerto de red 20 y el 21. Un problema básico de FTP es que está pensado para ofrecer la máxima velocidad en la conexión, pero no la máxima seguridad, ya que todo el intercambio de información, desde el login y password del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningún tipo de cifrado, con lo que un posible atacante puede capturar este tráfico, acceder al servidor y/o apropiarse de los archivos transferidos. Para solucionar este problema son de gran utilidad aplicaciones como scp y sftp, incluidas en el paquete SSH, que permiten transferir archivos pero cifrando todo el tráfico. File Transfer Protocol (FTP)|| Familia: Familia de protocolos de Internet Función: protocolo de transferencia de archivos Puertos: 20/TCP DATA Port 21/TCP Control Port Ubicación en la pila de protocolos Aplicación FTP Transporte TCP Red IP || Estándares: FTP: RFC 959 (1985) Extensiones de FTP para IPv6 y NATs: RFC 2428 (1998) El Modelo FTP El siguiente modelo representa el diagrama de un servicio FTP. En el modelo, el intérprete de protocolo (IP) de usuario inicia la conexión de control en el puerto 21. Las órdenes FTP estándar las genera el PI de usuario y se transmiten al proceso servidor a través de la conexión de control. Las respuestas estándar se envían desde el PI del servidor al PI de usuario por la conexión de control como respuesta a las órdenes. Estas órdenes FTP especifican parámetros para la conexión de datos (puerto de datos, modo de transferencia, tipo de representación y estructura) y la naturaleza de la operación sobre el sistema de archivos (almacenar, recuperar, añadir, borrar, etc.). El proceso de transferencia de datos (DTP) de usuario u otro proceso en su lugar, debe esperar a que el servidor inicie la conexión al puerto de datos especificado (puerto 20 en modo activo o estándar) y transferir los datos en función de los parámetros que se hayan especificado. Vemos también en el diagrama que la comunicación entre cliente y servidor es independiente del sistema de archivos utilizado en cada computadora, de manera que no importa que sus sistemas operativos sean distintos, porque las entidades que se comunican entre sí son los PI y los DTP, que usan el mismo protocolo estandarizado: el FTP. También hay que destacar que la conexión de datos es bidireccional, es decir, se puede usar simultáneamente para enviar y para recibir, y no tiene por qué existir todo el tiempo que dura la conexión FTP. Pero tenía en sus comienzos un problema, y era la localización de los servidores en la red. Es decir, el usuario que quería descargar algún archivo mediante FTP debía conocer en qué máquina estaba ubicado. La única herramienta de búsqueda de información que existía era Gopher, con todas sus limitaciones. Primer buscador de información Gopher significa 'lanzarse sobre' la información. Es un servicio cuyo objetivo es la localización de archivos a partir de su título. Consiste en un conjunto de menús de recursos ubicados en diferentes máquinas que están intercomunicadas. Cada máquina sirve una área de información, pero su organización interna permite que todas ellas funcionen como si se tratase de una sola máquina. El usuario navega a través de estos menús hasta localizar la información buscada, y desconoce exactamente de qué máquina está descargando dicha información. Con la llegada de Internet, los potentes motores de búsqueda (Google) dejaron el servicio Gopher, y la localización de los servidores FTP dejó de ser un problema. En la actualidad, cuando el usuario se descarga un archivo a partir de un enlace de una página web no llega ni a saber que lo está haciendo desde un servidor FTP. El servicio FTP ha evolucionado a lo largo del tiempo y hoy día es muy utilizado en Internet, en redes corporativas, Intranets, etc. Soportado por cualquier sistema operativo, existe gran cantidad de software basado en el protocolo FTP. Servidor FTP Un servidor FTP es un programa especial que se ejecuta en un equipo servidor normalmente conectado a Internet (aunque puede estar conectado a otros tipos de redes, LAN, MAN, etc.). Su función es permitir el intercambio de datos entre diferentes servidores/ordenadores. Por lo general, los programas servidores FTP no suelen encontrarse en los ordenadores personales, por lo que un usuario normalmente utilizará el FTP para conectarse remotamente a uno y así intercambiar información con él. Las aplicaciones más comunes de los servidores FTP suelen ser el alojamiento web, en el que sus clientes utilizan el servicio para subir sus páginas web y sus archivos correspondientes; o como servidor de backup (copia de seguridad) de los archivos importantes que pueda tener una empresa. Para ello, existen protocolos de comunicación FTP para que los datos se transmitan cifrados, como el SFTP (Secure File Transfer Protocol). Cliente FTP Cuando un navegador no está equipado con la función FTP, o si se quiere cargar archivos en un ordenador remoto, se necesitará utilizar un programa cliente FTP. Un cliente FTP es un programa que se instala en el ordenador del usuario, y que emplea el protocolo FTP para conectarse a un servidor FTP y transferir archivos, ya sea para descargarlos o para subirlos. Para utilizar un cliente FTP, se necesita conocer el nombre del archivo, el ordenador en que reside (servidor, en el caso de descarga de archivos), el ordenador al que se quiere transferir el archivo (en caso de querer subirlo nosotros al servidor), y la carpeta en la que se encuentra. Algunos clientes de FTP básicos en modo consola vienen integrados en los sistemas operativos, incluyendo Microsoft Windows, DOS, GNU/Linux y Unix. Sin embargo, hay disponibles clientes con opciones añadidas e interfaz gráfica. Aunque muchos navegadores tienen ya integrado FTP, es más confiable a la hora de conectarse con servidores FTP no anónimos utilizar un programa cliente. Acceso anónimo Los servidores FTP anónimos ofrecen sus servicios libremente a todos los usuarios, permiten acceder a sus archivos sin necesidad de tener un 'USER ID' o una cuenta de usuario. Es la manera más cómoda fuera del servicio web de permitir que todo el mundo tenga acceso a cierta información sin que para ello el administrador de un sistema tenga que crear una cuenta para cada usuario. Si un servidor posee servicio 'FTP anonymous' solamente con teclear la palabra «anonymous», cuando pregunte por tu usuario tendrás acceso a ese sistema. No se necesita ninguna contraseña preestablecida, aunque tendrás que introducir una sólo para ese momento, normalmente se suele utilizar la dirección de correo electrónico propia. Solamente con eso se consigue acceso a los archivos del FTP, aunque con menos privilegios que un usuario normal. Normalmente solo podrás leer y copiar los archivos que sean públicos, así indicados por el administrador del servidor al que nos queramos conectar. Normalmente, se utiliza un servidor FTP anónimo para depositar grandes archivos que no tienen utilidad si no son transferidos a la máquina del usuario, como por ejemplo programas, y se reservan los servidores de páginas web (HTTP) para almacenar información textual destinada a la lectura en línea. Acceso de usuario Si se desea tener privilegios de acceso a cualquier parte del sistema de archivos del servidor FTP, de modificación de archivos existentes, y de posibilidad de subir nuestros propios archivos, generalmente se suele realizar mediante una cuenta de usuario. En el servidor se guarda la información de las distintas cuentas de usuario que pueden acceder a él, de manera que para iniciar una sesión FTP debemos introducir una autentificación (en inglés: login) y una contraseña (en inglés: password) que nos identifica unívocamente. Cliente FTP basado en Web Un «cliente FTP basado en Web» no es más que un cliente FTP al cual podemos acceder a través de nuestro navegador web sin necesidad de tener otra aplicación para ello. El usuario accede a un servidor web (HTTP) que lista los contenidos de un servidor FTP. El usuario se conecta mediante HTTP a un servidor web, y el servidor web se conecta mediante FTP al servidor FTP. El servidor web actúa de intermediario haciendo pasar la información desde el servidor FTP en los puertos 20 y 21 hacia el puerto 80 HTTP que ve el usuario. Siempre hay momentos en que nos encontramos fuera de casa, no llevamos el ordenador portátil encima y necesitamos realizar alguna tarea urgente desde un ordenador de acceso público, de un amigo, del trabajo, la universidad, etc. Lo más común es que no estén instaladas las aplicaciones que necesitamos y en muchos casos hasta carecemos de los permisos necesarios para realizar su instalación. Otras veces estamos detrás de un proxy o cortafuegos que no nos permite acceder a servidores FTP externos. Al disponer de un cliente FTP basado en Web podemos acceder al servidor FTP remoto como si estuviéramos realizando cualquier otro tipo de navegación web. A través de un cliente FTP basado en Web podrás, crear, copiar, renombrar y eliminar archivos y directorios. Cambiar permisos, editar, ver, subir y descargar archivos, así como cualquier otra función del protocolo FTP que el servidor FTP remoto permita. Acceso de invitado El acceso sin restricciones al servidor que proporcionan las cuentas de usuario implica problemas de seguridad, lo que ha dado lugar a un tercer tipo de acceso FTP denominado invitado (guest), que se puede contemplar como una mezcla de los dos anteriores. La idea de este mecanismo es la siguiente: se trata de permitir que cada usuario conecte a la máquina mediante su login y su password, pero evitando que tenga acceso a partes del sistema de archivos que no necesita para realizar su trabajo, de esta forma accederá a un entorno restringido, algo muy similar a lo que sucede en los accesos anónimos, pero con más privilegios. Modos de conexión del cliente FTP FTP admite dos modos de conexión del cliente. Estos modos se denominan activo (o Estándar, o PORT, debido a que el cliente envía comandos tipo PORT al servidor por el canal de control al establecer la conexión) y pasivo (o PASV, porque en este caso envía comandos tipo PASV). Tanto en el modo Activo como en el modo Pasivo, el cliente establece una conexión con el servidor mediante el puerto 21, que establece el canal de control. Modo activo Modo activo. En modo Activo, el servidor siempre crea el canal de datos en su puerto 20, mientras que en el lado del cliente el canal de datos se asocia a un puerto aleatorio mayor que el 1024. Para ello, el cliente manda un comando PORT al servidor por el canal de control indicándole ese número de puerto, de manera que el servidor pueda abrirle una conexión de datos por donde se transferirán los archivos y los listados, en el puerto especificado. Lo anterior tiene un grave problema de seguridad, y es que la máquina cliente debe estar dispuesta a aceptar cualquier conexión de entrada en un puerto superior al 1024, con los problemas que ello implica si tenemos el equipo conectado a una red insegura como Internet. De hecho, los cortafuegos que se instalen en el equipo para evitar ataques seguramente rechazarán esas conexiones aleatorias. Para solucionar esto se desarrolló el modo pasivo. Modo pasivo Modo pasivo. Cuando el cliente envía un comando PASV sobre el canal de control, el servidor FTP le indica por el canal de control, el puerto (mayor a 1023 del servidor. Ej:2040) al que debe conectarse el cliente. El cliente inicia una conexión desde el puerto siguiente al puerto de control (ej: 1036) hacia el puerto del servidor especificado anteriormente (ej: 2040).1 Antes de cada nueva transferencia tanto en el modo Activo como en el Pasivo, el cliente debe enviar otra vez un comando de control (PORT o PASV, según el modo en el que haya conectado), y el servidor recibirá esa conexión de datos en un nuevo puerto aleatorio (si está en modo pasivo) o por el puerto 20 (si está en modo activo). En el protocolo FTP existen 2 tipos de transferencia en ASCII y en binarios. Tipos de transferencia de archivos en FTP Es importante conocer cómo debemos transportar un archivo a lo largo de la red. Si no utilizamos las opciones adecuadas podemos destruir la información del archivo. Por eso, al ejecutar la aplicación FTP, debemos acordarnos de utilizar uno de estos comandos (o poner la correspondiente opción en un programa con interfaz gráfica): Tipo ASCII Adecuado para transferir archivos que sólo contengan caracteres imprimibles (archivos ASCII, no archivos resultantes de un procesador de texto), por ejemplo páginas HTML, pero no las imágenes que puedan contener. Tipo Binario Este tipo es usado cuando se trata de archivos comprimidos, ejecutables para PC, imágenes, archivos de audio... Ejemplos de cómo transferir algunos tipos de archivo dependiendo de su extensión: Extensión de archivo Tipo de transferencia txt (texto) ascii html (página WEB) ascii doc (documento) binario ps (poscript) ascii hqx (comprimido) ascii Z (comprimido) binario ZIP (comprimido) binario ZOO (comprimido) binario Sit (comprimido) binario pit (comprimido) binario shar (comprimido) binario uu (comprimido) binario ARC (comprimido) binario tar (empaquetado) binario En la red existen diversas soluciones de software que desarrolla este tipo de tecnología, los más conocidos, son Filezilla (software libre) y CuteFTP (shareware). Guía de comandos FTP impresión de caracteres # a medida que se transfieren archivos, a modo de barra de progreso. Comando y argumentos open servidor Acción que realiza Inicia una conexión con un servidor FTP. close o disconnect Finaliza una conexión FTP sin cerrar el programa cliente. bye o quit Finaliza una conexión FTP y la sesión de trabajo con el programa cliente. cd directorio Cambia el directorio de trabajo en el servidor. delete archivo Borra un archivo en el servidor mdelete patrón Borra múltiples archivos basado en un patrón que se aplica al nombre. dir Muestra el contenido del directorio en el que estamos en el servidor. get archivo Obtiene un archivo noop No Operation Se le comunica al servidor que el cliente está en modo de no operación, el servidor usualmente responde con un «ZZZ» y refresca el contador de tiempo inactivo del usuario. mget archivos Obtiene múltiples archivos lcd directorio Cambia el directorio de trabajo local. ls Muestra el contenido del directorio en el servidor. prompt Activa/desactiva la confirmación por parte del usuario de la ejecución de comandos. Por ejemplo al borrar múltiples archivos. put archivo Envía un archivo al directorio activo del servidor. mput archivos Envía múltiples archivos. pwd Muestra el directorio activo en el servidor. rename archivo Cambia el nombre a un archivo en el servidor. rmdir directorio Elimina un directorio en el servidor si ese directorio está vacío. status Muestra el estado actual de la conexión. bin o binary Activa el modo de transferencia binario. ascii Activa el modo de transferencia en modo texto ASCII. ! Permite salir a línea de comandos temporalmente sin cortar la conexión. Para volver, teclear exit en la línea de comandos. ? nombre de comando Muestra la información relativa al comando. ? o help Muestra una lista de los comandos disponibles. append nombre del archivo Continua una descarga que se ha cortado previamente. bell Activa/desactiva la reproducción de un sonido cuando ha terminado cualquier proceso de transferencia de archivos. glob Activa/desactiva la visualización de nombres largos de nuestro PC. literal Con esta orden se pueden ejecutar comandos del servidor de forma remota. Para saber los disponibles se utiliza: literal help. mkdir Crea el directorio indicado de forma remota. quote Hace la misma función que literal. send nombre del archivo Envía el archivo indicado al directorio activo del servidor. user Para cambiar nuestro nombre de usuario y contraseña sin necesidad de salir de la sesión ftp. 2.3 Servidor de correo electronico Editar 0 0 1… Un servidor de correo es una aplicación de red ubicada en un servidor en internet cuya función es parecida al Correo postal solo que en este caso los correos (otras veces llamados mensajes) que circulan, lo hacen a través de nuestras Redes de transmisión de datos y a diferencia del correo postal, por este medio solo se pueden enviar adjuntos de ficheros de cualquier extensión y no bultos o paquetes al viajar la información en formato electrónico. Agente de Transferencia de Correo Los servidores de correo a menudo realizan diferentes funciones según sea el uso que se planifique para el mismo. Agente de Transferencia de Correo (del inglés Mail Transport Agent o MTA; también Message Transport Agent, Agente de Transporte de Mensajes) es uno de los programas que ejecutan los servidores de correo, y tiene como fin transferir un conjunto de datos de una computadora a otra. El MTA, tiene varias formas de comunicarse con otros servidores de correo: 1.- Recibe los mensajes desde otro MTA. Actúa como "servidor" de otros servidores. 2.- Envía los mensajes hacia otro MTA. Actúa como un "cliente" de otros servidores. 3.- Actúa como intermediario entre un "Mail Submision Agent" y otro MTA. Algunas soluciones de correo que incluyen un MTA son: Sendmail, qmail, Postfix, Exim, Mdaemon, Mercury Mail Transport System, Lotus Notes (IBM) y Microsoft Exchange Server. Por defecto el protocolo estándar para la transferencia de correos entre servidores es el SMTP, o Protocolo Simple de Transferencia de Correo. Está definido en el RFC 2821 y es un estándar oficial de Internet.( http://tools.ietf.org/html/rfc2821) Intercambio de correo electrónico Un servidor de correo realiza una serie de procesos que tienen la finalidad de transportar información entre los distintos usuarios. Usualmente el envío de un correo electrónico tiene como fin que un usuario (remitente) cree un correo electrónico y lo envíe a otro (destinatario). Esta acción toma típicamente 5 pasos. 1.- El usuario inicial crea un "correo electrónico"; un archivo que cumple los estándares de un correo electrónico. Usará para ello una aplicación ad-hoc. Las aplicaciones más usadas, en indistinto orden son: Outlook Express (Microsoft), Oulook (Microsoft), Mozilla Thunderbird (Mozilla), Pegasus Mail (David Harris), IBM Lotus Notes (IBM), etc. 2.- El archivo creado es enviado a un almacén; administrado por el servidor de correo local al usuario remitente del correo; donde se genera una solicitud de envío. 3.- El servicio MTA local al usuario inicial recupera este archivo e inicia la negociación con el servidor del destinatario para el envío del mismo. 4.- El servidor del destinatario valida la operación y recibe el correo, depositándolo en el "buzón" correspondiente al usuario receptor del correo. El "buzón" no es otra cosa que un registro en una base de datos. 5.- Finalmente el software del cliente receptor del correo recupera este archivo o "correo" desde el servidor almacenando una copia en la base de datos del programa cliente de correo, ubicada en la computadora del cliente que recibe el correo. A diferencia de un servicio postal clásico, que recibe un único paquete y lo transporta de un lugar a otro; el servicio de correo electrónico copia varias veces la información que corresponde al correo electrónico. Este proceso que en la vida real ocurre de manera muy rápida involucra muchos protocolos. Por ejemplo para obtener los mensajes del servidor de correos receptor, los usuarios se sirven de clientes de correo que utilizan el protocolo POP3 o el protocolo IMAP para recuperar los "correos" del servidor y almacenarlos en sus computadores locales. Seguro o inseguro Si tiene en cuenta el proceso, hay por lo menos una copia del correo en el servidor de envío y otra copia en el servidor de recepción. Las políticas de funcionamiento de cada servidor, con o sin aviso a los usuarios remitente y/o destinatario, podrían: 1.- No recibir correos de acuerdo a algún parámetro. 2.- Destruir las copias de los correos, por ejemplo al trasferirlos satisfactoriamente. 3.- Copiar los correos a algún otro registro o archivo. 4.- Enviar una o más copias a otros destinatarios. 5.- No destruir nunca los correos almacenados. Es de suma importancia considerar qué entidad, institución y funcionario son los responsables de administrar finalmente los servidores de correo que usamos. Los correos pueden en muchos casos ser fuente de invasión a la privacidad. Servidores de correo Web Una forma especial de servidor de correo, es aquél que es accedido vía Web usando el protocolo http. En realidad no es servidor, sino un cliente de correo que corre en un servidor web. A través de dicho cliente se puede acceder al servidor de correo sin necesidad de instalar un cliente de correo en la computadora local. En este tipo de servidor, el archivo de datos del remitente o destinatario puede ser accedido sin requerir un cliente local. En el mismo servidor se integran programas para acceder a los correos del mismo. Ejemplos típicos de este servicio son: www.hotmail.com, www.yahoo.com, www.gmail.com, etc. 2.4 Servidor de bases de datos Editar 0 0 1… Servidores de bases de datos Grandes proveedores de información para todo tipo de usuarios Los servidores de bases de datos surgen con motivo de la necesidad de las empresas de manejar grandes y complejos volúmenes de datos, al tiempo que requieren compartir la información con un conjunto de clientes (que pueden ser tanto aplicaciones como usuarios) de una manera segura. Ante este enfoque, un sistema gestor de bases de datos (SGBD, a partir de ahora) deberá ofrecer soluciones de forma fiable, rentable y de alto rendimiento. A estas tres características, le debemos añadir una más: debe proporcionar servicios de forma global y, en la medida de lo posible, independientemente de la plataforma. Internet se ha convertido en nuestros días en la mayor plataforma de comunicaciones jamás vista. Esto hace que las empresas tiendan a presentar su información a través de la Web en forma de contenidos, que después los clientes consultarán para establecer relaciones con dichas empresas. Una de las funciones que se empieza a exigir a los SGBD, puesto que sobre ellos recae el peso del almacén y proceso de la información, es la de proporcionar herramientas de apoyo a toma de decisiones ("datawarehouse") al tiempo que proporciona una plataforma de transacciones "on-line" (OLTP) que hacen que la información esté siempre actualizada y consistente. A lo largo del artículo iremos comentando las prestaciones de ambas implementaciones y cómo influye el SGBD en el proceso de las mismas. Aunque parece clara la función de un SGBD, en la actualidad cada vez más filosofías y tecnologías tienden a confluir en un mismo punto. Ya se está hablando acerca de las posibilidades de los nuevos SGBD de poder almacenar contenidos multimedia, objetos, documentos complejos... La explosión de nuevos servicios ha hecho que cada vez más aplicaciones dependan de estos servidores de datos, delegando la responsabilidad de la gestión y almacenamiento de la información a aquellos que mejor están preparados para su tratamiento. Para poder lograr estos objetivos, es un punto muy importante el que los SGBD proporcionen herramientas de administración completas (que simplifiquen la tarea de la configuración, seguridad, creación y gestión de bases de datos al tiempo que proporcionan mecanismos de integración con otros sistemas y políticas de copias de seguridad) y herramientas que permitan su programación (tanto a nivel de diseño como a nivel de reglas y procedimientos que encapsulen la arquitectura de la base de datos, de tal manera que, a través de conectores a datos, las aplicaciones sólo tengan que pedir la información que necesitan sin preocuparse de cómo se encuentra almacenada). Por último, puesto que los datos deben estar por encima de la plataforma, los SGBD deben proporcionar mecanismos de comunicación con otras plataformas que actúen también como clientes o servidores de datos. Lo que nos lleva al último punto que consideraremos: la posibilidad de la replicación de la información, posibilidad que permitirá que la información pueda estar almacenada en múltiples servidores de datos y accesible desde cualquier punto como si se tratase de un único volumen de información. Servidores de bases de dato relacionales Antes de comenzar a comentar las características a analizar de los SGBD, el primer paso es el de definir qué es un servidor de bases de datos relacionales y sus cometidos principales. Un servidor de bases de datos relacionales es un sistema bajo arquitectura cliente/servidor que proporciona servicios de gestión, administración y protección de la información (datos) a través de conexiones de red, gobernadas por unos protocolos definidos y a los que acceden los usuarios, de modo concurrente, a través de aplicaciones clientes (bien sean herramientas del propio sistema como aplicaciones de terceros). Dichos servidores solucionan los problemas de las empresas al manejar grandes volúmenes de información de una manera estable, fiable, coherente y segura en un entorno heterogéneo de trabajo y de necesidades de información. La información se almacenará de modo lógico de una manera relacional, como ya se ha visto, en la que un conjunto de almacenamientos que llamaremos tablas (y que se componen de un conjunto de campos que describen su contenido, y a los cuales denominaremos columnas) se relacionan entre sí a través de un conjunto definido de claves. Una de las responsabilidades del sistema y del diseño de la base de datos, será el que sea posible mostrar aquella información requerida a través de conjuntos de datos planos (que llamaremos cursores), independizando las relaciones establecidas y la arquitectura de la base de datos de la necesidad de información del usuario. Para proteger la información el sistema contará con mecanismos de control de transacciones basados en reglas que denominaremos disparadores, reglas de definición del tipo de entrada de datos y reglas de validación de las entradas de datos. Mediante complejos sistemas de indexación, estos sistemas serán capaces de ordenar y acelerar las consultas a la información requerida. Cuanto mejor se indexen los datos, más rápidas se realizarán las consultas. Por último, y como un factor muy importante de cara al diseño de bases de datos, los sistemas deben proporcionar la posibilidad de automatizar operaciones de acceso, filtrado y control de los datos, a través de los procedimientos almacenados. Todo ello se podrá realizar a través del lenguaje SQL (Structured Query Language, lenguaje estructurado de consulta) que se ha convertido en el estándar de interfaz de estos sistemas para su diseño, desarrollo y consultas de informaci6n. Desarrollado por IBM, se ha convertido en un estándar para el manejo de estos sistemas y queda recogido en la norma ANSI SQL'92, en la cual quedan registradas aquellas sentencias SQL que deben estar presentes en todo sistema gestor de bases de datos. En este apartado, que es donde los SGBD demuestran sus propios dones, es donde ya nos separamos del estándar, pues cada fabricante añadirá sus propias extensiones al lenguaje para aprovechar, como es lógico, las ventajas de sus propios motores. De lo indicado en los párrafos anteriores podremos obtener algunos de los parámetros que emplearemos en la comparativa: capacidad del servidor de conexión con el exterior; capacidad de atender peticiones concurrentes de clientes; seguridad del sistema; herramientas de administraci6n disponibles; herramientas de administración y automatización de tareas que reduzcan el TCO ("Total Cost Owner") y, por último, la cantidad de plataformas en la que se puede integrar el sistema. La seguridad En todo sistema abierto, debe proporcionarse un potente mecanismo de seguridad que garantice que ningún intruso pueda acceder o corromper la integridad del sistema. Si este concepto ya es crítico en los sistemas operativos actuales, hay que imaginarse cuánto más es de importante este concepto cuando ya no hablamos de recursos del sistema (como puedan ser archivos o correos, más o menos importantes) sino de información crítica para la empresa, en la que se almacenan datos de contabilidad, gestión, personal, o estratégicos de la cual depende para su existencia. En servidores de bases de datos hablaremos de la seguridad a 4 niveles básicos: seguridad de acceso al sistema, seguridad a nivel de objetos de datos, seguridad a nivel de datos y seguridad en cuanto a protección de los almacenamientos físicos de los datos. La seguridad de acceso se implementará de dos maneras posibles: a nivel de sistema operativo, en cuyo caso el SGBD se apoya en la seguridad de entrada al sistema operativo para comprobar la validez del acceso a los datos almacenados; o bien lo que llamaremos modo mixto, en el cual la seguridad de entrada a la información la llevará a cabo el propio servidor de datos a partir de la definición de cuentas de usuario al servidor (su denominación de mixta proviene de la capacidad de los sistemas de incluir como cuentas de acceso o login áquellas propias del sistema operativo, lo que facilita la transición de las cuentas de seguridad). La segunda será de gran ayuda cuando los clientes que acceden al sistema provienen de sistemas operativos con poca (o ninguna) seguridad o de aplicaciones instaladas que necesiten acceder a los volúmenes de información del sistema. En ambos casos, en los sistemas se contará con roles o papeles con los que contará el usuario al entrar al sistema para la realización de determinadas operaciones de cara al sistema. La seguridad a nivel de objetos entra ya en el detalle del acceso a nivel de creación y administración de objetos de datos: tablas, vistas, índices, relaciones, reglas...etc. Es decir, las responsabilidades y acciones que puede hacer el usuario en el esquema de la base de datos (el esqueleto a partir del cual el sistema definirá cómo se debe almacenar y relacionar la información). Se podrán especificar de nuevo roles a los usuarios, indicando quién podrá crear, modificar o eliminar cualquier objeto de datos (con lo que se permite establecer una política de delegación de responsabilidades). La seguridad a nivel de datos entra ya en la capa de la información en si. En la que indicaremos quién puede acceder a qué información para su consulta, actualización, inserción o borrado. Las características de los diversos motores determinarán hasta qué grado de seguridad se llega en este apartado (desde la protección de las columnas de una tabla hasta la tabla en si, creación de vistas...etc.). Por último, la seguridad a nivel de protección de los almacenamientos físicos de la información. Tendremos dos aproximaciones: la seguridad a nivel de sistema operativo de los archivos de datos del sistema, y las políticas de copia de seguridad y restauración de los datos (tanto con herramientas del sistema operativo como las proporcionadas por el propio servidor de datos) junto con sus posibles aproximaciones (total, incremental y diferencial), además de los soportes hardware compatibles de almacenamiento masivo empleados como destino de las copias. El soporte de red Puesto que se está implementando una solución cliente/servidor, es un elemento fundamental para la conexión entre los distintos clientes y el servidor un canal apropiado para la comunicación, que posibilite el intercambio de información. Los servidores de datos deben proporcionar mecanismos de comunicación óptimos, pues de cómo se envíe la información dependerán parámetros tan importantes como la velocidad de acceso a los datos. Todos los sistemas gestores analizados cuentan con múltiples configuraciones de protocolos, adaptándose a los protocolos existentes y estandarizados de la actualidad: TCP/IP, IPX, Banyan..., aunque el que tiene un auge imparable en este tipo de servicios es el omnipresente TCP/IP, lo que garantiza que la conexi6n de nuestros servidores estará al alcance de cualquier usuario desde cualquier parte del mundo. Es importante no sólo el canal de comunicaciones que está disponible para los servidores de datos sino también cómo es transmitida la información. Es lógico pensar que tienen que existir posibilidades de encriptación de la información para prevenir accesos no autorizados así como mecanismos de partición de los datos, para evitar que peticiones masivas de información sobrecarguen el ancho de banda de la red. Además, será una cuestión de optimización el saber que no toda la información es necesaria al mismo tiempo, y que el servidor debe ser capaz de ir proveyendo la información requerida en el momento justo en el que es necesaria (lo que ahorra ancho de banda y recursos de la máquina) . La configuración de las librerías de red dependerá mucho del tipo de sistema operativo que se encuentre en explotación. Y será un componente a configurar tanto en la máquina servidor como en los puestos cliente. Este apartado también dependerá del tipo de plataforma empleada. Recalcar que el proceso de configuración de los clientes deberá ser un proceso sencillo, que en la mayoría de los casos sólo implica conocer el nombre del servidor de datos y las cuentas oportunas, siendo el propio sistema operativo el encargado de encontrar los servidores referenciados (bien a través de un nombre DNS, una dirección IP o un nombre de servicio con un Puerto de escucha). Internet y bases de datos distribuidas Puesto que todo tiende a unificarse con Internet, los servidores de datos también deben proporcionar servicios de datos a la Red. Los servicios disponibles incorporan generación y alimentación de páginas Web a partir de consultas prediseñadas en la base de datos. Dichas consultas mantendrán alimentadas las páginas Web, las cuales estarán siempre actualizadas con la última información. Cuanto mayor sea el grado de integración con la Web, mejor podrá ser la presentación de información crítica de la empresa en las páginas. Los servidores de datos deben proporcionar mecanismos de actualización automática de las páginas, de manera que se asegure que cualquier cambio efectuado en la base de datos se haga efectivo en la correspondiente página Web. De esta manera, la integridad de la informaci6n también estará implementada a nivel de servicios de la Red. Lógicamente, también hay que pensar que esto no es viable de cara a actualizaciones masivas de datos, lo que implica una sobrecarga del servidor (pues no sólo actualiza datos sino también páginas Web). Por ello, generalmente deberemos contar con opciones que permitan realizar actualizaciones manuales o programadas en el tiempo (lo que reducirá significativamente el coste de actualización de las páginas). No sólo es importante el nivel de integración con el Web, sino que también es importante el grado de interacción del usuario con la misma. Generalmente las páginas Web proporcionan mecanismos de selección de información personalizada, lo cual permite que los usuarios accedan sólo a aquella información que precisan. Para ello, es importante que exista un soporte de interacción que se obtiene a través de código Java. Por lo tanto, cuanto mejor sea el soporte Java, más se asegura la interacción y se amplía el rango de servicios que puede proporcionar el servidor de datos. Una de las mejoras realizadas como consecuencia de la integración con la Red Global, es la de la posibilidad de permitir la compartición y distribución de la información a lo largo de los servidores situados en cualquier parte del mundo. Esto permitirá a las empresas disponer de su información sea cuál sea el lugar del mundo en el que se encuentre el departamento que la procesa. E, incluso, permitirá a las empresas poder integrar sus bases de datos con sus proveedores o clientes, de manera que podrán colaborar a nivel de servicios y recursos de información, ganando en rapidez y fiabilidad. Para ello, los servidores de datos deberán proporcionar los servicios de intercambio de información, reglas de sincronización y todo un conjunto de parámetros necesarios para que esta revolución en cuanto a acceso global a la información sea posible. Herramientas de administración Avanzando un grado más en las capas de servicios que debe proporcionar un servidor de datos, nos encontramos con las herramientas que proporciona tanto al usuario administrador como al cliente consumidor de los datos. De cara al administrador, las herramientas deben proporcionarle un entorno amigable y sencillo de manejar, que le permita orientarse a su trabajo y no preocuparse con detalles de más bajo nivel, al tiempo que le permite realizar sus tareas de la manera más rápida y simplificada posible. Indicar que cuanto mayor sea el nivel de automatización de las tareas, menor será el tiempo que tenga que dedicar a tareas generalmente repetitivas. Y cuanto mayor sea el número de opciones configurables, mejor servicio se podrá obtener de dichas tareas. La comodidad de acceso a las herramientas es otro parámetro a tener en cuenta. Cuanta más información tengamos a nuestro alcance, menor será el tiempo empleado en acceder a la información necesaria para la administración del servidor. No será extraño acceder a las opciones de configuración y gestión a través de consolas que permitan la integración de "snap-ins" o que, al menos, sirvan de pasarela entre las múltiples utilidades disponibles. Dichas herramientas, además, deben permitir la administración remota del servidor o servidores que estén a cargo del administrador. De nuevo, insistir en el grado de programación y automatización de tareas, ya que este mecanismo proveerá de la creación de planes automáticos de realización de tareas repetitivas de administración, lo que garantiza un alto grado de seguridad, optimización, ahorro de tiempo y esfuerzo. Como un componente fundamental de un servidor de datos, es el de Optimización de la Base de datos y de las consultas. Cuanto más efectiva sea la optimización del sistema, mayor velocidad adquirirán las consultas y mejor rendimiento se obtendrá del servidor. Muchas veces la velocidad no se encuentra en una máquina sobrada de recursos, sino en aprovechar al máximo los recursos de los que disponemos. Por lo tanto, cuanto mejor sea el soporte de optimización para el administrador, mejor se podrá configurar el sistema, lo que asegurará siempre un rendimiento máximo adaptado a las necesidades de la empresa. Las consultas y su proceso El servicio más importante que proporciona un servidor de datos es el del acceso a la información que almacena. El cómo recuperar y actualizar dicha información es un proceso crítico del que depende en mayor grado el éxito de este tipo de sistemas. El lenguaje que se emplea en la actualidad es el SQL bajo el estándar ANSI SQL'92. Esto, como comentamos anteriormente, garantiza que todo conjunto de sentencias empleado para el acceso a una base de datos puede ser empleado para cualquier tipo de servidor de bases de datos que siga este estándar. Lo que independiza la necesidad de información del cómo se encuentre almacenada. Las herramientas actuales permiten encapsular el código SQL, de tal manera que el usuario no tiene que conocer dicho lenguaje para acceder a la información. Incluso, y gracias a los procedimientos almacenados, es posible encapsular el código SQL dentro de la propia base de datos, lo que da lugar a la petición de información únicamente a través de un conjunto documentado de funciones sencillas. Esto de cara a aplicaciones y usuarios simplifica el acceso a la base de datos, y protege la arquitectura de la misma. La optimización automática de consultas SQL es una nueva opción que proporcionan los nuevos servidores de datos. Esto permite que sea el propio servidor el que reconozca la mejor manera de recuperar la información (optimización y asignación automática de índices, o aprendizaje/ entrenamiento de consultas) que es lo que se conoce como plan de ejecución de la consulta. Lo que en el caso de introducir una sentencia SQL no optimizada por motivos de rapidez o desconocimiento, permite acelerar al máximo el acceso a los datos. Esto, junto con las capacidades multiproceso de los servidores, permite que la ejecución de consultas complejas se convierta en una operación rápida y de alto rendimiento. Este apartado es muy importante de cara a la implementación de aplicaciones OLTP (en las cuales es crítica la velocidad de actualización de la información en línea) y en entornosdatawarehouse (en el que las consultas de recuperación de información para la toma de decisiones dependen de consultas muy complejas en proceso que devuelven valores calculados muy concretos). Por último, indicar en este apartado que será una opción de valor añadido el incorporar servicios de datawarehouse, que permitan la implementación de este tipo de arquitecturas en la empresa. En el caso de aplicaciones OLTP.es muy importante el asunto de los bloqueos de objetos de datos, pues el sistema gestor debe mantener la integridad de la información que está siendo actualizada por múltiples clientes al mismo tiempo. De no ser así, se podrían obtener situaciones de registros fantasma, información de cálculo erróneo, e información desactualizada. Habrá que estudiar cuál es el sistema que ofrece un grado muy fino de bloqueo, pues cuanto menor sea el nivel de bloqueo (se bloquea sólo lo justo) más usuarios podrán acceder a los recursos al mismo tiempo. Un bloqueo a nivel de columna permite a los usuarios acceder y modificar aquellas columnas que no están siendo actualizadas por otros usuarios, dentro de la misma fila. Un bloqueo a nivel de tabla paralizará temporalmente las operaciones de aquellos usuarios que no tienen el acceso a dicho recurso hasta que el operador termine su operación. En este apartado, uno de los factores críticos es el del control de las transacciones. Las transacciones son un conjunto de operaciones que se realizan como una unidad de ejecución y que deben terminar con éxito (en cuyo caso se actualiza la información implicada en todos los pasos, se denomina "commit") o en fracaso (en cuyo caso el servidor debe ser capaz de deshacer toda la operación para dejar la base de datos en el último estado consistente, conocido como "rollback"). Cuanto mayor sea el grado de recuperación y control de las transacciones, mayor integridad se obtendrá en la base de datos. Y este control se propaga en cuanto a transacciones distribuidas se refiere, pues el que una transacción caiga en un determinado servidor, debe implicar que todos los servidores implicados deben echar atrás la operación errónea, lo cuál puede resultar una operación compleja y de envergadura. Además, en caso de caída los servidores deben garantizar que todas las transacciones consideradas como válidas son restauradas para garantizar la integridad de la información en el momento del arranque de la máquina y antes de permitir el proceso por parte de los usuarios (y es por ello por lo que los servidores cuentan con el registro de LOG de transacciones). Plataformas y programación En este último punto comentaremos la importancia que tienen dos de los parámetros relacionados con las plataformas disponibles para el servidor y el grado de ampliación del mismo tanto de cara a su implementación interna como en su capacidad de proporcionar API de programación a los desarrolladores. La escalabilidad y portabilidad del servidor será un factor a tener en cuenta de cara a su adquisición o migración desde sistemas ya existentes. Y ya no sólo de cara al motor del servidor sino de cara a las plataformas de las herramientas de los clientes. Cuanto mayor sea el rango de plataformas soportadas, tanto más universal será el acceso al motor, lo que no limita a la empresa en cuanto a parque tecnológico se refiere. En este punto, decir también que cuanto mejor sea el soporte de migración y traspaso de información entre distintos servidores, más se garantizará la integraci6n/migración de la información ya existente, con el mínimo riesgo de pérdida de información y el mínimo coste de implantación y desarrollo. En cuanto al desarrollo, los servidores de datos deben proporcionar las API necesarias para asegurar que los desarrollos que se lleven a cabo puedan aprovechar los servicios de acceso y gestión de los datos de la manera más eficiente y completa posibles. Y, además, no deben limitar el desarrollo a la plataforma en la que se encuentra el sistema, sino que debe ser capaz de dar soporte a los lenguajes estándar de la Red como pueda ser Java, lo que garantizará una integración total con los recursos de la Red. El soporte hardware necesario Lógicamente, sin un buen soporte hardware que proporcione los factores de rendimiento necesarios para cumplir los objetivos de acceso a la información, no podremos obtener las prestaciones establecidas. En cuanto al procesador empiezan a aprovecharse al máximo las arquitecturas SMP (Multiproceso simétrico). Los servidores de datos serán capaces de distribuir la carga del análisis dé las consultas, la ejecución de la programación de tareas y, como no, el control de los accesos de múltiples usuarios al mismo tiempo. Es requisito imprescindible contar con una buena cantidad de memoria, pues una de las mejores maneras que, tienen los servidores de proporcionar los datos de la manera más rápida posible es mantener los sistemas de indexación, cursores y páginas caché en la memoria del servidor. Lo que requiere de una enorme cantidad de espacio libre. Ni que decir tiene que él disco duro es necesario que disponga de almacenamiento de sobra si quiere ser capaz de albergar varias bases de datos que son capaces de almacenar el nivel de información diario (presente y futuro) que requiere el funcionamiento de la empresa y sus reglas de negocio. 2.5 Servidor de dns Editar 0 0 1… Domain Name System o DNS (en español: sistema de nombres de dominio) es un sistema de nomenclatura jerárquica para computadoras, servicios o cualquier recurso conectado a Internet o a una red privada. Este sistema asocia información variada con nombres de dominios asignado a cada uno de los participantes. Su función más importante, es traducir (resolver) nombres inteligibles para los humanos en identificadores binarios asociados con los equipos conectados a la red, esto con el propósito de poder localizar y direccionar estos equipos mundialmente. El servidor DNS utiliza una base de datos distribuida y jerárquica que almacena información asociada a nombres de dominio en redes como Internet. Aunque como base de datos el DNS es capaz de asociar diferentes tipos de información a cada nombre, los usos más comunes son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico de cada dominio. La asignación de nombres a direcciones IP es ciertamente la función más conocida de los protocolos DNS. Por ejemplo, si la dirección IP del sitio FTP de prox.mx es 200.64.128.4, la mayoría de la gente llega a este equipo especificando ftp.prox.mx y no la dirección IP. Además de ser más fácil de recordar, el nombre es más fiable. La dirección numérica podría cambiar por muchas razones, sin que tenga que cambiar el nombre. Inicialmente, el DNS nació de la necesidad de recordar fácilmente los nombres de todos los servidores conectados a Internet. En un inicio, SRI (ahora SRI International) alojaba un archivo llamado HOSTS que contenía todos los nombres de dominio conocidos. El crecimiento explosivo de la red causó que el sistema de nombres centralizado en el archivo hosts no resultara práctico y en 1983, Jesus Botello "SysWarn" publicó los RFC 882 y RFC 883 definiendo lo que hoy en día ha evolucionado hacia el DNS moderno. Componentes Para la operación práctica del sistema DNS se utilizan tres componentes principales: Los Clientes DNS: Un programa cliente DNS que se ejecuta en la computadora del usuario y que genera peticiones DNS de resolución de nombres a un servidor DNS (Por ejemplo: ¿Qué dirección IP corresponde a nombre.dominio?); Los Servidores DNS: Que contestan las peticiones de los clientes. Los servidores recursivos tienen la capacidad de reenviar la petición a otro servidor si no disponen de la dirección solicitada. Y las Zonas de autoridad, porciones del espacio de nombres de dominio que almacenan los datos. Cada zona de autoridad abarca al menos un dominio y posiblemente sus subdominios, si estos últimos no son delegados a otras zonas de autoridad. Entendiendo las partes de un nombre de dominio Un nombre de dominio usualmente consiste en dos o más partes (técnicamente etiquetas), separadas por puntos cuando se las escribe en forma de texto. Por ejemplo,www.mohamedali.org o www.wikipedia.es A la etiqueta ubicada más a la derecha se le llama dominio de nivel superior (en inglés top level domain). Como org en www.ejemplo.org o es en www.wikipedia.es Cada etiqueta a la izquierda especifica una subdivisión o subdominio. Nótese que "subdominio" expresa dependencia relativa, no dependencia absoluta. En teoría, esta subdivisión puede tener hasta 127 niveles, y cada etiqueta puede contener hasta 63 caracteres, pero restringidos a que la longitud total del nombre del dominio no exceda los 255 caracteres, aunque en la práctica los dominios son casi siempre mucho más cortos. Finalmente, la parte más a la izquierda del dominio suele expresar el nombre de la máquina (en inglés hostname). El resto del nombre de dominio simplemente especifica la manera de crear una ruta lógica a la información requerida. Por ejemplo, el dominio es.wikipedia.org tendría el nombre de la máquina "es", aunque en este caso no se refiere a una máquina física en particular. El DNS consiste en un conjunto jerárquico de servidores DNS. Cada dominio o subdominio tiene una o más zonas de autoridad que publican la información acerca del dominio y los nombres de servicios de cualquier dominio incluido. La jerarquía de las zonas de autoridad coincide con la jerarquía de los dominios. Al inicio de esa jerarquía se encuentra losservidores raíz: los servidores que responden cuando se busca resolver un dominio de primer y segundo nivel. DNS en el mundo real Los usuarios generalmente no se comunican directamente con el servidor DNS: la resolución de nombres se hace de forma transparente por las aplicaciones del cliente (por ejemplo, navegadores, clientes de correo y otras aplicaciones que usan Internet). Al realizar una petición que requiere una búsqueda de DNS, la petición se envía al servidor DNS local del sistema operativo. El sistema operativo, antes de establecer alguna comunicación, comprueba si la respuesta se encuentra en la memoria caché. En el caso de que no se encuentre, la petición se enviará a uno o más servidores DNS. La mayoría de usuarios domésticos utilizan como servidor DNS el proporcionado por el proveedor de servicios de Internet. La dirección de estos servidores puede ser configurada de forma manual o automática mediante DHCP. En otros casos, los administradores de red tienen configurados sus propios servidores DNS. DNS en el mundo real.svg En cualquier caso, los servidores DNS que reciben la petición, buscan en primer lugar si disponen de la respuesta en la memoria caché. Si es así, sirven la respuesta; en caso contrario, iniciarían la búsqueda de manera recursiva. Una vez encontrada la respuesta, el servidor DNS guardará el resultado en su memoria caché para futuros usos y devuelve el resultado. Jerarquía DNS DNS arbol.svg El espacio de nombres de dominio tiene una estructura arborescente. Las hojas y los nodos del árbol se utilizan como etiquetas de los medios. Un nombre de dominio completo de un objeto consiste en la concatenación de todas las etiquetas de un camino. Las etiquetas son cadenas alfanuméricas (con '-' como único símbolo permitido), deben contar con al menos un carácter y un máximo de 63 caracteres de longitud, y deberá comenzar con una letra (y no con '-') (ver la RFC 1035, sección "2.3.1. Preferencia nombre de la sintaxis "). Las etiquetas individuales están separadas por puntos. Un nombre de dominio termina con un punto (aunque este último punto generalmente se omite, ya que es puramente formal). Un FQDN correcto (también llamado Fully Qualified Domain Name), es por ejemplo este: www.example.com. (Incluyendo el punto al final) Un nombre de dominio debe incluir todos los puntos y tiene una longitud máxima de 255 caracteres. Un nombre de dominio se escribe siempre de derecha a izquierda. El punto en el extremo derecho de un nombre de dominio separa la etiqueta de la raíz de la jerarquía (en inglés, root). Este primer nivel es también conocido como dominio de nivel superior (TLD - Top Level Domain). Los objetos de un dominio DNS (por ejemplo, el nombre del equipo) se registran en un archivo de zona, ubicado en uno o más servidores de nombres. Tipos de servidores DNS Preferidos: Guardan los datos de un espacio de nombres en sus ficheros Alternativos: Obtienen los datos de los servidores primarios a través de una transferencia de zona. Locales o caché: Funcionan con el mismo software, pero no contienen la base de datos para la resolución de nombres. Cuando se les realiza una consulta, estos a su vez consultan a los servidores secundarios, almacenando la respuesta en su base de datos para agilizar la repetición de estas peticiones en el futuro continuo o libre. Tipos de resolución de nombres de dominio Existen dos tipos de consultas que un cliente puede hacer a un servidor DNS: Iterativa Las resoluciones iterativas consisten en la respuesta completa que el servidor de nombres pueda dar. El servidor de nombres consulta sus datos locales (incluyendo su caché) buscando los datos solicitados. El servidor encargado de hacer la resolución realiza iterativamente preguntas a los diferentes DNS de la jerarquía asociada al nombre que se desea resolver, hasta descender en ella hasta la máquina que contiene la zona autoritativa para el nombre que se desea resolver. Recursiva En las resoluciones recursivas, el servidor no tiene la información en sus datos locales, por lo que busca y se pone en contacto con un servidor DNS raíz, y en caso de ser necesario repite el mismo proceso básico (consultar a un servidor remoto y seguir a la siguiente referencia) hasta que obtiene la mejor respuesta a la pregunta. Cuando existe más de un servidor autoritario para una zona, Bind utiliza el menor valor en la métrica RTT (round-trip time) para seleccionar el servidor. El RTT es una medida para determinar cuánto tarda un servidor en responder una consulta. El proceso de resolución normal se da de la siguiente manera: 1. 2. 3. 4. 5. 6. 7. 8. 9. El servidor A recibe una consulta recursiva desde el cliente DNS. El servidor A envía una consulta recursiva a B. El servidor B refiere a A otro servidor de nombres, incluyendo a C. El servidor A envía una consulta recursiva a C. El servidor C refiere a A otro servidor de nombres, incluyendo a D. El servidor A envía una consulta recursiva a D. El servidor D responde. El servidor A regresa la respuesta al resolver. El resolver entrega la resolución al programa que solicitó la información. Tipos de registros DNS A = Address – (Dirección) Este registro se usa para traducir nombres de servidores de alojamiento a direcciones IPv4. AAAA = Address – (Dirección) Este registro se usa en IPv6 para traducir nombres de hosts a direcciones IPv6. CNAME = Canonical Name – (Nombre Canónico) Se usa para crear nombres de servidores de alojamiento adicionales, o alias, para los servidores de alojamiento de un dominio. Es usado cuando se están corriendo múltiples servicios (como ftp y servidor web) en un servidor con una sola dirección ip. Cada servicio tiene su propia entrada de DNS (como ftp.ejemplo.com. y www.ejemplo.com.). esto también es usado cuando corres múltiples servidores http, con diferente nombres, sobre el mismo host. Se escribe primero el alias y luego el nombre real. Ej. Ejemplo1 IN CNAME ejemplo2 NS = Name Server – (Servidor de Nombres) Define la asociación que existe entre un nombre de dominio y los servidores de nombres que almacenan la información de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de servidores de nombres. MX (registro) = Mail Exchange – (Registro de Intercambio de Correo) Asocia un nombre de dominio a una lista de servidores de intercambio de correo para ese dominio. Tiene un balanceo de carga y prioridad para el uso de uno o más servicios de correo. PTR = Pointer – (Indicador) También conocido como 'registro inverso', funciona a la inversa del registro A, traduciendo IPs en nombres de dominio. Se usa en el archivo de configuración del Dns reversiva. SOA = Start of authority – (Autoridad de la zona) Proporciona información sobre el servidor DNS primario de la zona. HINFO = Host INFOrmation – (Información del sistema informático) Descripción del host, permite que la gente conozca el tipo de máquina y sistema operativo al que corresponde un dominio. TXT = TeXT - ( Información textual) Permite a los dominios identificarse de modos arbitrarios. LOC = LOCalización - Permite indicar las coordenadas del dominio. WKS - Generalización del registro MX para indicar los servicios que ofrece el dominio. Obsoleto en favor de SRV. SRV = SeRVicios - Permite indicar los servicios que ofrece el dominio. RFC 2782. Excepto Mx y Ns. Hay que incorporar el nombre del servicio, protocolo, dominio completo, prioridad del servicio, peso, puerto y el equipo completo. Esta es la sintaxis correspondiente: Servicio.Protocolo.Dominio-completo IN SRV Prioridad.Peso.Puerto.Equipo-Completo SPF = Sender Policy Framework - Ayuda a combatir el Spam. En este registro se especifica cual o cuales hosts están autorizados a enviar correo desde el dominio dado. El servidor que recibe, consulta el SPF para comparar la IP desde la cual le llega con los datos de este registro. 2.6 servidor de SSH Editar 0 0 1… SSH (Secure SHell, en español: intérprete de órdenes segura) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo la computadora mediante un intérprete de comandos, y también puede redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X (en sistemas Unix y Windows) corriendo. Además de la conexión a otros dispositivos, SSH nos permite copiar datos de forma segura (tanto ficheros sueltos como simular sesiones FTP cifradas), gestionar claves RSA para no escribir claves al conectar a los dispositivos y pasar los datos de cualquier otra aplicación por un canal seguro tunelizado mediante SSH. Seguridad SSH trabaja de forma similar a como se hace con telnet. La diferencia principal es que SSH usa técnicas de cifrado que hacen que la información que viaja por el medio de comunicación vaya de manera no legible y ninguna tercera persona pueda descubrir el usuario y contraseña de la conexión ni lo que se escribe durante toda la sesión; aunque es posible atacar este tipo de sistemas por medio de ataques de REPLAY y manipular así la información entre destinos. Historia Al principio sólo existían los r-commands, que eran los basados en el programa rlogin, el cual funciona de una forma similar a telnet. La primera versión del protocolo y el programa eran libres y los creó un finlandés llamado Tatu Ylönen, pero su licencia fue cambiando y terminó apareciendo la compañía SSH Communications Security, que lo ofrecía gratuitamente para uso doméstico y académico, pero exigía el pago a otras empresas. En el año 1997 (dos años después de que se creara la primera versión) se propuso como borrador en la IETF. A principios de 1999 se empezó a escribir una versión que se convertiría en la implementación libre por excelencia, la de OpenBSD, llamada OpenSSH. Versiones Existen 2 versiones de SSH, la versión 1 de SSH hace uso de muchos algoritmos de encriptación patentados (sin embargo, algunas de estas patentes han expirado) y es vulnerable a un hueco de seguridad que potencialmente permite a un intruso insertar datos en la corriente de comunicación. La suite OpenSSH bajo Red Hat Enterprise Linux utiliza por defecto la versión 2 de SSH, la cual tiene un algoritmo de intercambio de llaves mejorado que no es vulnerable al hueco de seguridad en la versión 1. Sin embargo, la suite OpenSSH también soporta las conexiones de la versión 1. Aplicaciones Cliente SSH Comparación de clientes SSH Aplicaciones Servidor SSH Comparación de servidores SSH 2.7 Servidor de impresion Editar 0 0 1… Un Servidor de Impresión (Print Server) es un concentrador, o más bien un servidor, que conecta una impresora a red, para que cualquier PC pueda acceder a ella e imprimir trabajos, sin depender de otro PC para poder utilizarla, como es el caso de las impresoras compartidas. Actualmente existen servidores de impresora para interfaz paralela, USB o impresoras de 2.8 Servidor proxy Editar 0 0 1… Un proxy, en una red informática, es un programa o dispositivo que realiza una acción en representación de otro, esto es, si una hipotética máquina A solicita un recurso a una C, lo hará mediante una petición a B; C entonces no sabrá que la petición procedió originalmente de A. Esta situación estratégica de punto intermedio suele ser aprovechada para soportar una serie de funcionalidades: proporcionar caché, control de acceso, registro del tráfico, prohibir cierto tipo de tráfico etcétera. Su finalidad más habitual es la de servidor proxy, que consiste en interceptar las conexiones de red que un cliente hace a un servidor de destino, por varios motivos posibles como seguridad, rendimiento, anonimato, etc. Esta función de servidor proxy puede ser realizada por un programa o dispositivo. Características La palabra proxy significa intermediario en inglés. o o o El uso más común es el de servidor proxy, que es un ordenador que intercepta las conexiones de red que un cliente hace a un servidor de destino. De ellos, el más famoso es el servidor proxy web (comúnmente conocido solamente como «proxy»). Intercepta la navegación de los clientes por páginas web, por varios motivos posibles: seguridad, rendimiento, anonimato, etc. También existen proxies para otros protocolos, como el proxy de FTP. El proxy ARP puede hacer de enrutador en una red, ya que hace de intermediario entre ordenadores. Proxy (patrón de diseño) también es un patrón de diseño (programación) con el mismo esquema que el proxy de red. Un componente hardware también puede actuar como intermediario para otros. Como se ve, proxy tiene un significado muy general, aunque siempre es sinónimo de intermediario. Cuando un equipo de la red desea acceder a una información o recurso, es realmente el proxy quien realiza la comunicación y a continuación traslada el resultado al equipo inicial Hay dos tipos de proxys atendiendo a quien es el que quiere implementar la política del proxy: proxy local: En este caso el que quiere implementar la política es el mismo que hace la petición. Por eso se le llama local. Suelen estar en la misma máquina que el cliente que hace las peticiones. Son muy usados para que el cliente pueda controlar el tráfico y pueda establecer reglas de filtrado que por ejemplo pueden asegurar que no se revela información privada (Proxys de filtrado para mejora de la privacidad). proxy externo: El que quiere implementar la política del proxy es una entidad externa. Por eso se le llama externo. Se suelen usar para implementar cacheos, bloquear contenidos, control del tráfico, compartir IP, etc. Ventajas En general (no sólo en informática), los proxies hacen posible: Control: sólo el intermediario hace el trabajo real, por tanto se pueden limitar y restringir los derechos de los usuarios, y dar permisos sólo al proxy. Ahorro. Sólo uno de los usuarios (el proxy) ha de estar preparado para hacer el trabajo real. Con estar preparado queremos decir que es el único que necesita los recursos necesarios para hacer esa funcionalidad. Ejemplos de recursos necesarios para hacer la función pueden ser la capacidad y lógica de cómputo o la dirección de red externa (IP). Velocidad. Si varios clientes van a pedir el mismo recurso, el proxy puede hacer caché: guardar la respuesta de una petición para darla directamente cuando otro usuario la pida. Así no tiene que volver a contactar con el destino, y acaba más rápido. Filtrado. El proxy puede negarse a responder algunas peticiones si detecta que están prohibidas. Modificación. Como intermediario que es, un proxy puede falsificar información, o modificarla siguiendo un algoritmo. Anonimato. Si todos lo usuarios se identifican como uno sólo, es difícil que el recurso accedido pueda diferenciarlos. Pero esto puede ser malo, por ejemplo cuando hay que hacer necesariamente la identificación. Desventajas En general (no sólo en informática), el uso de un intermediario puede provocar: Abuso. Al estar dispuesto a recibir peticiones de muchos usuarios y responderlas, es posible que haga algún trabajo que no toque. Por tanto, ha de controlar quién tiene acceso y quién no a sus servicios, cosa que normalmente es muy difícil. Carga. Un proxy ha de hacer el trabajo de muchos usuarios. Intromisión. Es un paso más entre origen y destino, y algunos usuarios pueden no querer pasar por el proxy. Y menos si hace de caché y guarda copias de los datos. Incoherencia. Si hace de caché, es posible que se equivoque y dé una respuesta antigua cuando hay una más reciente en el recurso de destino. En realidad este problema no existe con los servidores proxy actuales, ya que se conectan con el servidor remoto para comprobar que la versión que tiene en cache sigue siendo la misma que la existente en el servidor remoto. Irregularidad. El hecho de que el proxy represente a más de un usuario da problemas en muchos escenarios, en concreto los que presuponen una comunicación directa entre 1 emisor y 1 receptor (como TCP/IP). Aplicaciones El concepto de proxy es aplicado de muy distintas formas para proporcionar funcionalidades específicas. Proxy de web Se trata de un proxy para una aplicación específica el acceso a la web (principalmente los protocolos HTTP y HTTPS). Aparte de la utilidad general de un proxy a veces proporciona unacaché para las páginas web y los contenidos descargados. Cuando esto sucede se dice que el proxy web está haciendo un servicio de proxy-cache. Esta caché es compartida por todos los usuario del proxy, con la consiguiente mejora en los tiempos de acceso para consultas coincidentes. Al mismo tiempo libera la carga de los enlaces hacia Internet. o o Funcionamiento: El cliente realiza una petición (p. ej. mediante un navegador web) de un recurso de Internet (una página web o cualquier otro archivo) especificado por una URL. Cuando el proxy caché recibe la petición, busca la URL resultante en su caché local. Si la encuentra, contrasta la fecha y hora de la versión de la página demanda con el servidor remoto. Si la página no ha cambiado desde que se cargo en caché la devuelve inmediatamente, ahorrándose de esta manera mucho tráfico pues sólo intercambia un paquete para comprobar la versión. Si la versión es antigua o simplemente no se encuentra en la caché, lo captura del servidor remoto, lo devuelve al que lo pidió y guarda o actualiza una copia en su caché para futuras peticiones. Posibles usos Los proxys web pueden aportar una serie de funcionalidades interesantes en distintos ámbitos: Reducción del tráfico mediante la implementación de caché en el proxy. Las peticiones de páginas Web se hacen al servidor Proxy y no a Internet directamente. Por lo tanto se aligera el tráfico en la red y descarga los servidores destino, a los que llegan menos peticiones. El caché utiliza normalmente un algoritmo configurable para determinar cuándo un documento está obsoleto y debe ser eliminado de la caché. Como parámetros de configuración utiliza la antigüedad, tamaño e histórico de acceso. Dos de esos algoritmos básicos son el LRU (el usado menos recientemente, en inglés "Least Recently Used") y el LFU (el usado menos frecuentemente, "Least Frequently Used"). Mejora de la velocidad en tiempo de respuesta mediante la implementación de caché en el proxy. El servidor Proxy crea un caché que evita transferencias idénticas de la información entre servidores durante un tiempo (configurado por el administrador) así que el usuario recibe una respuesta más rápida. Por ejemplo supongamos que tenemos un ISP que tiene un servidor Proxy con caché. Si un cliente de ese ISP manda una petición por ejemplo a Google esta llegará al servidor Proxy que tiene este ISP y no irá directamente a la dirección IP del dominio de Google. Esta página concreta suele ser muy solicitada por un alto porcentaje de usuarios, por lo tanto el ISP la retiene en su Proxy por un cierto tiempo y crea una respuesta en mucho menor tiempo. Cuando el usuario crea una búsqueda en Google el servidor Proxy ya no es utilizado; el ISP envía su petición y el cliente recibe su respuesta ahora sí desde Google. Los programas P2P se pueden aprovechar de la cache que proporcionadas por algunos proxys. Es el llamado Webcaché. Por ejemplo es usado en Lphant y algunos Mods del Emule. o o El proxy puede servir para implementar funciones de filtrado de contenidos. Para ello es necesaria la configuración de una serie restricciones que indiquen lo que no se permite. Observar que esta funcionalidad puede se aprovechada no sólo para que ciertos usuarios no accedan a ciertos contenidos sino también para filtrar ciertos ficheros que se pueden considerar como peligrosos como pueden ser virus y otros contenidos hostiles servidos por servidores web remotos. Un proxy puede permitir esconder al servidor web la identidad del que solicita cierto contenido. El servidor web lo único que detecta es que la ip del proxy solicita cierto contenido. Sin embargo no puede determinar la ip origen de la petición. Además, si se usa una caché, puede darse el caso de que el contenido sea accedido muchas más veces que las detectadas por el servidor web que aloja ese contenido. Los proxys pueden ser aprovechados para dar un servicio web a una demanda de usuarios superior a la que sería posible sin ellos. El servidor proxy puede modificar los contenidosque sirven los servidores web originales. Puede haber diferentes motivaciones para hacer esto. Veamos algunos ejemplos: Algunos proxys pueden cambiar el formato de las páginas web para un propósito o una audiencia específicos (Ej. mostrar una página en un teléfono móvil o una PDA)traduciendo los contenidos. Hay proxys que modifican el tráfico web para mejorar la privacidad del tráfico web con el servidor. Para ello se establecen unas reglas que el proxy tiene que cumplir. Por ejemplo el proxy puede ser configurado para bloquear direcciones y Cookies, para modificar cabeceras de las peticiones o quitar javascript que se considere peligroso. Es frecuente el uso de este tipo de proxys en las propias máquinas de los usuarios (proxys locales) para implementar un paso intermedio y que las peticiones no sean liberadas/recibidas a/de la red sin haber sido previamente limpiadas de información o contenido peligroso o privado. Este tipo de proxys es típico en entornos donde hay mucha preocupación sobre la privacidad y se suele usar como paso previo a la petición del contenido a través de una red que persiga el anonimato como puede ser TOR. Los programas más frecuentes para hacer este tipo de funcionalidad son: Privoxy: Se centra en el contenido web. No presta servicio de cache. Analiza el tráfico basándose en reglas predefinidas que se asocian a direcciones especificadas con expresiones regulares y que aplica a cabeceras, contenido, etc. Es altamente configurable. Tiene extensa documentación. Polipo: Tiene características que lo hacen más rápido que privoxy (cacheo, pipeline, uso inteligente de rango de peticiones) pero tiene la pega de que no viene configurado por defecto para proveer anonimicidad a nivel de la capa de aplicación. El servidor proxy proporciona un punto desde el que se pueden gestionar de forma centralizada el tráfico web de muchos usuarios. Eso puede aprovecharse para muchas funciones adicionales a las típicas vistas anteriormente. Por ejemplo puede usarse para el establecimiento de controlar el tráfico de web de individuos concretos, establecer cómo se va a llegar a los servidores web de los que se quieren obtener los contenidos (por ejemplo el proxy puede configurarse para que en lugar de obtener los contenid s directamente, lo haga a través de la red TOR). Inconvenientes Si se realiza un servicio de caché, las páginas mostradas pueden no estar actualizadas si éstas han sido modificadas desde la última carga que realizó el proxy caché. Un diseñador de páginas web puede indicar en el contenido de su web que los navegadores no hagan una caché de sus páginas, pero este método no funciona habitualmente para un proxy. El hecho de acceder a Internet a través de un Proxy, en vez de mediante conexión directa, dificulta (necesario configurar adecuadamente el proxy) realizar operaciones avanzadas a través de algunos puertos o protocolos. Almacenar las páginas y objetos que los usuarios solicitan puede suponer una violación de la intimidad para algunas personas. Web Proxy Su funcionamiento se basa en el de un Proxy HTTP y HTTPs, pero la diferencia fundamental es que la petición se realiza mediante una Aplicación Web servida por un servidor HTTP al que se accede mediante una URL, esto es, una página web que permite estos servicios. Proxy SOCKS Los proxy SOCKS son muy diferentes de los proxys 'normales'. Cuando por ejemplo usas un proxy HTTP lo que éste hace es coger las peticiones HTTP y hace la petición por ti y te devuelve los resultados. Haciendo un simil con la vida real es como si alguien nos pidera que le pasaramos la sal de la mesa y el proxy la cogiera y nos la diera. Sin embargo lo que hace el protocolo SOCKS, es casi equivalente a establecer un túnel IP con un firewall y a partir de ahí las peticiones del protocolo son entonces realizadas desde el firewall. El cliente negocia una conexión con el servidor proxy SOCKS usando el protocolo SOCKS, nivel 5 del modelo OSI (capa de sesión). Una vez establecida la conexión todas la comunicaciones entre el cliente y proxy se realizan usando el protocolo SOCKS. El cliente le dice al proxy SOCKS que es lo que quiere y el proxy se comunica con el servidor externo y obtiene los resultados y se los manda al cliente. De esta forma el servidor externo sólo tiene que estar accesible desde el proxy SOCKS que es el que se va a comunicar con él. El cliente que se comunica con SOCKS puede estar en la propia aplicación (Ej. Firefox, putty), o bien en la pila de protocolos TCP/IP a donde la aplicación enviará los paquetes a un túnel SOCKS. En el proxy SOCKS es habitual implementar, como en la mayoría de proxys, autenticación y loggeo de de las sesiones. Proxies transparentes Muchas organizaciones (incluyendo empresas, colegios y familias) usan los proxies para reforzar las políticas de uso de la red o para proporcionar seguridad y servicios de caché. Normalmente, un proxy Web o NAT no es transparente a la aplicación cliente: debe ser configurada para usar el proxy, manualmente. Por lo tanto, el usuario puede evadir el proxy cambiando simplemente la configuración. Una ventaja de tal es que se puede usar para redes de empresa. Un proxy transparente combina un servidor proxy con NAT (Network Address Translation) de manera que las conexiones son enrutadas dentro del proxy sin configuración por parte del cliente, y habitualmente sin que el propio cliente conozca de su existencia. Este es el tipo de proxy que utilizan los proveedores de servicios de internet (ISP). Reverse Proxy / Proxy inverso Un reverse proxy es un servidor proxy instalado en el domicilio de uno o más servidores web. Todo el tráfico entrante de Internet y con el destino de uno de esos servidores web pasa a través del servidor proxy. Hay varias razones para instalar un "reverse proxy": Seguridad: el servidor proxy es una capa adicional de defensa y por lo tanto protege los servidores web. Cifrado / Aceleración SSL: cuando se crea un sitio web seguro, habitualmente el cifrado SSL no lo hace el mismo servidor web, sino que es realizado por el "reverse proxy", el cual está equipado con un hardware de aceleración SSL (Security Sockets Layer). Distribución de Carga: el "reverse proxy" puede distribuir la carga entre varios servidores web. En ese caso, el "reverse proxy" puede necesitar reescribir las URL de cada página web (traducción de la URL externa a la URL interna correspondiente, según en qué servidor se encuentre la información solicitada). Caché de contenido estático: Un "reverse proxy" puede descargar los servidores web almacenando contenido estático como imágenes u otro contenido gráfico. Proxy NAT (Network Address Translation) / Enmascaramiento Otro mecanismo para hacer de intermediario en una red es el NAT. La traducción de direcciones de red (NAT, Network Address Translation) también es conocida como enmascaramiento de IPs. Es una técnica mediante la cual las direcciones fuente o destino de los paquetes IP son reescritas, sustituidas por otras (de ahí el "enmascaramiento"). Esto es lo que ocurre cuando varios usuarios comparten una única conexión a Internet. Se dispone de una única dirección IP pública, que tiene que ser compartida. Dentro de la red de área local (LAN) los equipos emplean direcciones IP reservadas para uso privado y será el proxy el encargado de traducir las direcciones privadas a esa única dirección pública para realizar las peticiones, así como de distribuir las páginas recibidas a aquel usuario interno que la solicitó. Estas direcciones privadas se suelen elegir en rangos prohibidos para su uso en Internet como 192.168.x.x, 10.x.x.x, 172.16.x.x y 172.31.x.x Esta situación es muy común en empresas y domicilios con varios ordenadores en red y un acceso externo a Internet. El acceso a Internet mediante NAT proporciona una cierta seguridad, puesto que en realidad no hay conexión directa entre el exterior y la red privada, y así nuestros equipos no están expuestos a ataques directos desde el exterior. Mediante NAT también se puede permitir un acceso limitado desde el exterior, y hacer que las peticiones que llegan al proxy sean dirigidas a una máquina concreta que haya sido determinada para tal fin en el propio proxy. La función de NAT reside en los Cortafuegos y resulta muy cómoda porque no necesita de ninguna configuración especial en los equipos de la red privada que pueden acceder a través de él como si fuera un mero encaminador. Proxy abierto Este tipo de proxy es el que acepta peticiones desde cualquier ordenador, esté o no conectado a su red. En esta configuración el proxy ejecutará cualquier petición de cualquier ordenador que pueda conectarse a él, realizándola como si fuera una petición del proxy. Por lo que permite que este tipo de proxy se use como pasarela para el envío masivo de correos de spam. Un proxy se usa, normalmente, para almacenar y redirigir servicios como el DNS o la navegaciónWeb, mediante el cacheo de peticiones en el servidor proxy, lo que mejora la velocidad general de los usuarios. Este uso es muy beneficioso, pero al aplicarle una configuración "abierta" a todo internet, se convierte en una herramienta para su uso indebido. Debido a lo anterior, muchos servidores, como los de IRC, o correo electrónicos, deniegan el acceso a estos proxys a sus servicios, usando normalmente listas negras ("BlackList"). Cross-Domain Proxy Típicamente usado por Tecnologías web asíncronas (flash, ajax, comet, etc) que tienen restricciones para establecer una comunicación entre elementos localizados en distintos dominios. En el caso de Ajax, por seguridad sólo se permite acceder al mismo dominio origen de la página web que realiza la petición. Si se necesita acceder a otros servicios localizados en otros dominios, se instala un Cross-Domain proxy en el dominio origen que recibe las peticiones ajax y las reenvia a los dominios externos. En el caso de flash, también han solucionado creando la revisión de archivos xml de CrossDomain, que permiten o no el acceso a ese dominio o subdominio. 2.9 Administracion de usuarios Editar 0 0 1… Administración de Usuarios Usuarios de sistema. La parte de cuentas de usuario permite definir qué usuarios tendrán acceso a la plataforma SIE, y por lo tanto podrán utilizar sus servicios. Para la gestión de las cuentas de sistema se utiliza el servicio de directorio LDAP. Esto significa que toda la plataforma SIE de la empresa, independientemente de los servidores que la formen, estén en la misma red o repartidos en distintos centros, mantienen una única configuración de usuarios. Cuando damos de alta un usuario de sistema se crea automáticamente una cuenta de correo y una carpeta privada. A la carpeta privada podemos acceder desde el administrador de archivos de la intranet (SIEWEB) o desde Windows si tenemos el módulo File Server. Gestión de permisos Cuando instalamos un nuevo servicio en la plataforma automáticamente se incluyen los roles que utiliza para la gestión del servicio, de forma que solo tenemos que entrar en la administración de usuario y gestionar los permisos que queremos conceder a cada usuario de sistema.