3 - lopezbonilla

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.