Servidor Proxy

Hospital La Victoria – Manual Servidor Proxy y Firewall

SERVIDORES PROXY

INTRODUCCIÓN

Ventajas de un servidor Proxy

Un servidor Proxy actúa como intermediario entre el programa cliente (Netscape, Mozilla, Internet Explorer...) y el servidor web que contiene la información que queremos obtener. Su función consiste en almacenar páginas de Internet, gráficos, fotos, archivos de música... para que la próxima vez que se pida el mismo objeto no se deba acceder de nuevo al servidor web que lo alojaba, sino que se sirva directamente desde su memoria o lo que es lo mismo desde su caché.

En cuanto a las ventajas, un servidor Proxy con caché en principio realiza la misma función que el resto de caches privados como los que utilizan los navegadores, pero de manera compartida por un conjunto grande de usuarios que acceden a través de él. Al tratarse de un almacenamiento compartido es más probable que varios usuarios pidan los mismos objetos consiguiéndose de este modo una reducción en los tiempos de espera para el usuario final. Ésta no es la única ventaja de disponer de éste sistema, a continuación se indican otras ventajas a considerar.

Puede controlar el acceso a Internet prohibiendo por ejemplo la entrada a determinadas páginas web por su contenido erótico o por cualquier otro motivo, ya que un servidor Proxy puede realizar simplemente la función de pasarela sin realizar caché.

El coste del software y su instalación tienen un precio prácticamente nulo para acceder a Internet mediante una sola línea, a diferencia del coste de usar cualquier router.

Un servidor Proxy además también actúa como una barrera (firewall) que limita el acceso a la red desde el exterior.

Desventajas de un servidor Proxy

Utilizar un servidor Proxy-Caché en principio puede parecer una gran ventaja ya que se disminuye el tiempo de acceso al contenido deseado y además el servidor que aloja el contenido no recibe tantas peticiones, pero no todo son ventajas, a continuación se indican posibles inconvenientes.

Debido a que el funcionamiento de un Proxy no es conocido por todos los usuarios o webmasters, puede suponer un inconveniente al visualizar las páginas ya que éstas pueden no mostrarse actualizadas si no entendemos su funcionamiento.

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 para un Proxy (a menos que se utilicen lenguajes como PHP).

El hecho de acceder a Internet a través de un Proxy, en vez de mediante conexión directa, impide realizar operaciones avanzadas a través de algunos puertos o protocolos, aunque también es cierto que algunas pueden habilitarse tal como veremos más adelante.

Almacenar las páginas y objetos que los usuarios solicitan puede suponer una violación de la intimidad para algunas personas, aunque también es cierto que desde el punto de vista de las empresas es una manera de controlar las actividades de sus trabajadores.

Todas las pruebas que se presentan en este manual o han sido realizadas sobre Linux RedHat con una conexión de ADSL y un procesador Pentium con 128MB de RAM.

Departamento de Sistemas de Información Septiembre 2007 – Los derechos de Autor sobre el siguiente Manual corresponde a sus Creadores Originales


Configuración e instalación de Squid

Como instalar el servidor Squid

Instalación mediante RPM

La manera más sencilla de instalar el servidor Squid en nuestro sistema, es mediante una versión en RPM ya sea desde el CD de nuestra distribución o desde por ejemplo nuestra sección privada, ninguna versión anterior a la 2.4 STABLE1 se considera apropiada y lógicamente nosotros recomendamos instalar la versión estable más reciente posible.

Para instalar una versión en RPM, simplemente tenemos que ejecutar como usuario root la siguiente orden:

rpm -i squid-2.4.STABLE6-6.7.3.i386.rpm

(El RPM indicado viene con la distribución de RedHat 7-3 y es el que utilizaremos para realizar esta documentación).

Instalación mediante código fuente

Si no deseamos esperar a que salga la última versión en RPM y queremos instalar Squid desde el código fuente, simplemente tenemos que descargar la versión más actualizada desde www.squid-cache.org y descomprimirla mediante la orden:

tar -xzvf squid-2.5.STABLE2.tar.gz

Una vez descomprimido el paquete debemos de ejecutar el siguiente script con los siguientes parámetros:

./configure -prefix=/usr/local/squid

Esta orden permite especificar el directorio donde instalaremos Squid. Una vez realizada esta operación se generan los ficheros Makefiles y librerías necesarias para compilar el código.

Para compilar el código fuente ejecutar la orden make all y posteriormente make install para instalar el software de Squid en nuestro sistema.

Ejemplo de configuración de sus directivas

En esta sección se muestra un ejemplo de las directivas más importantes que deberían de situarse descomentadas dentro del fichero squid.conf, para hacer funcionar el servidor Squid.

#Directivas para Proxy y cachéhttp_port 3128cache_mem 16 MBcache_dir ufs /var/spool/squid 100 16 256maximum_object_size 4096 KBcache_access_log /var/log/squid/access.logreference_age 1 monthrefresh_pattern . 0 20% 4320ftp_user [email protected]_passive on

#Directivas para definir listasacl password proxy_auth REQUIREDacl redlocal src 192.168.0.0/255.255.255.0



acl adult url_regex www.sex microsoft

#Mínimas por defectoacl all src 0.0.0.0/0.0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/32acl SSL_ports port 443 563 --> HTTPS, SNEWSacl Safe_ports port 80 21 443 563 --> HTTP, FTP, HTTPS, SNEWSacl Safe_ports port 70 210 1025-65535 --> GOPHER, WAIS, Rango puertosacl Safe_ports port 280 488 --> HTTP-MGMT, GSS-HTTPacl CONNECT method CONNECT

#Directivas para definir reglas sobre las listashttp_access allow adult passwordhttp_access allow redlocal

#Mínimas por defectohttp_access allow manager localhosthttp_access deny managerhttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portshttp_access deny all

#Otras directivasno_cache deny adultreply_body_max_size 4096 KBcache_mgr [email protected]_program /usr/lib/squid/ncsa_auth /etc/squid/squid-passwd

#Directivas para la jerarquía de cachesicp_port 3130cache_peer 192.168.0.84 parent 3128 3130cache_peer 192.168.0.90 sibling 3128 0

En el siguiente apartado se muestra una descripción detallada con ejemplos de cada una de las directivas presentadas y en el orden en que se encuentran en esta página.

Explicación de las directivas

Una vez presentadas las directivas explicaremos su utilidad y funcionamiento para una mayor compresión de sus posibilidades.

Para el correcto funcionamiento de las directivas, se aconseja descomentarlas situándolas a la izquierda del todo.

http_port (Asignar Puerto)

Permite especificar uno o varios puertos de escucha para el servidor Squid. Sus valores pueden ser: [dirección-IP:]puerto... tal como se muestra a continuación.

http_port 3128 80http_port 192.168.0.87:3128

La segunda línea especifica la dirección IP de la máquina donde se encuentra el Proxy. Si queremos que Squid escuche en el puerto 80, debemos de tener en cuenta que los servidores web como Apache utilizan este puerto por defecto y por tanto deberemos de asignarle uno diferente.



cache_mem (Tamaño para la caché en memoria)

Permite indicar la cantidad ideal de memoria RAM como máximo para almacenar caché de objetos en tránsito, objetos Hot y objetos negativamente almacenados en la caché.

Los datos de estos objetos se almacenan en bloques de 4KB. Cache_mem especifica un límite ideal en el tamaño total de bloques acomodados, donde los objetos en tránsito tienen mayor prioridad, es decir que el resto de objetos la podrán usar hasta que sea requerida.

En el supuesto caso que el objeto en tránsito requiera una memoria mayor a la especificada se excederá para satisfacer la petición, a continuación se muestra un ejemplo.

cache_mem 16 MB

Si el servidor tiene como mínimo 128 MB de RAM es aconsejable indicar este valor.

cache_dir (Tamaño y directorio para la caché física)

Permite indicar la cantidad de memoria física máxima para almacenar caché en el disco duro, es decir cuanto espacio almacenar de objetos de Internet. Sus valores pueden ser: tipo directorio tamaño numero_subdir numero_niveles, tal como se muestra a continuación.

cache_dir ufs /var/spool/squid 100 16 256

El numero 100 corresponde a 100MB como espacio máximo para almacenar caché, el 16 son el numero de subdirectorios que contendrá el directorio principal (en este caso /var/spool/squid) y el 256 significa el numero de niveles para cada subdirectorio. En caso de especificar un tamaño máximo inferior al espacio real disponible, el servidor Squid se bloqueará.

maximum_object_size (Tamaño máximo para cacheados)

Permite especificar en kilobytes el tamaño máximo de los objetos que se pueden cachear, es decir, los objetos más grandes del tamaño indicado no serán cacheados, a continuación se muestra un ejemplo.

maximum_object_size 4096 KB

En el ejemplo se han indicado 4MB como tamaño máximo de objetos en la caché.

cache_access_log (Log de peticiones y uso de la caché)

Permite definir en que fichero Squid debe guardar una lista de las peticiones que va recibiendo, con la información de la página que se ha consultado y si ésta ha sido facilitada desde la caché o desde el servidor web, a continuación se muestra un ejemplo.

cache_access_log /var/log/squid/access.log

Squid presenta más directivas para definir donde registrar sus logs, a continuación se muestran las siguientes dos que pueden ser de mayor utilidad.

cache_log /var/log/squid/cache.logInformación general sobre el comportamiento de la caché

cache_store_log /var/log/squid/store.logMuestra que objetos son ejecutados des de la caché y hasta cuando serán guardados.



reference_age (Tiempo máximo en la caché)

Permite especificar el tiempo máximo que puede permanecer un objeto en la caché sin que se acceda a él, transcurrido ese tiempo será borrado.

Squid el objeto que ha estado mas tiempo sin ser accedido lo calcula dinámicamente con el fin de ser borrado según el espacio disponible en la caché. Sus valores pueden ser: time-units, tal como se muestra a continuación.

reference_age 1 yearreference_age 3.5 daysreferense_age 2 hours

refresh_pattern (Factor para páginas sin caducidad)

Permite especificar que fecha en minutos deben de tener los documentos que su servidor no estableció una cabecera Expires indicando su caducidad.

Sus valores pueden ser: expresión_regular mín porcentaje máx, tal como se muestra a continuación.

refresh_pattern -i \.gif$ 14400 70% 43200refresh_pattern ^ftp: 1440 20% 10080refresh_pattern . 0 20% 4320

El valor correspondiente a la expresión regular debe de contener la especificación del objeto basándose en la dirección (URL) de la petición o un "." para indicar el resto. En los ejemplos se muestra como especificar cualquier objeto "gif" y cualquier petición "FTP".

El valor mín corresponde a los minutos mínimos que un objeto que no dispone de una cabecera Expires (indicando su caducidad), pueda ser considerado como no caducado (fresco). El valor "0" se recomienda para que no se obligue la retención de objetos no deseados como pueden ser los dinámicos.

El valor porcentaje sirve para especificar en aquellos objetos sin fecha de caducidad, cual será su fecha, aplicando un porcentaje sobre su tiempo desde la última modificación (la última modificación de un objeto se obtiene de la cabecera Last-Modified).

El valor máx corresponde a los minutos máximos que un objeto podrá ser considerado como no caducado.

ftp_user (Acceso anónimo para FTP)

Permite indicar el correo que debe usarse como contraseña para acceder de forma anónima a un servidor FTP. Esto es útil si se desea acceder a servidores que validan la autenticidad de la dirección de correo especificada como contraseña, a continuación se muestra un ejemplo.

ftp_user [email protected]

Requerir autentificación por contraseña

Hasta el momento hemos visto mediante las directivas acl y http_access como controlar el acceso según el origen de la petición o según el destino. En este apartado aprovechando también estas directivas mostraremos como conseguir que independientemente de la máquina que se utilice se requiera introducir un nombre de usuario y una contraseña en el cliente para poder acceder a través del Proxy.

1. Crear el fichero que contendrá los usuarios y sus contraseñas de forma encriptada.



touch /etc/squid/squid-passwd2. Establecer permisos de lectura y escritura para Squid. 3. chmod 600 /etc/squid/squid-passwd

chown squid:squid /etc/squid/squid-passwd4. Dar de alta los usuarios con sus contraseñas.

htpasswd /etc/squid/squid-passwd nombre_usuario

La orden nos pedirá introducir su contraseña correspondiente. El nombre de usuario es lógicamente independiente a los que hay ya definidos en el sistema y la orden htpasswd está disponible en el paquete: apache-1.3.22 o superior.

5. Definir en el fichero squid.conf que programa gestiona las autenticaciones (ver sección: Explicación de las directivas).

authenticate_program /usr/lib/squid/ncsa_auth /etc/squid/squid-passwd6. Definir en el fichero squid.conf la lista acl correspondiente.

acl password proxy_auth REQUIRED7. Aplicar reglas en el fichero squid.conf para quienes queramos que sean autenticados.

acl all src 0.0.0.0/0.0.0.0 --> Todas las IP's posiblesacl redlocal src 192.168.0.0/24 --> Red correspondiente a 192.168.0.*http_access allow redlocal password --> Usuarios con esas IP's autenticarsehttp_access deny all --> Denegamos el acceso a los demás.acl all src 0.0.0.0/0.0.0.0 --> Todas las IP's posiblesacl redlocal src 192.168.0.0/24acl adult url_regex www.sex.com erotichttp_access allow adult password --> Solo acceder a contenido adulto mediante previa autenticación.http_access allow redlocal --> Permitimos el acceso a las IP's de la red.http_access deny all --> Denegamos el acceso a los demás.

Una vez hemos configurado nuestro servidor Proxy solo tenemos que realizar una petición a un contenido prohibido y observaremos como nuestro navegador muestra una ventana para que nos autentiquemos.

Instalación mediante RPM

La manera más sencilla de poner en funcionamiento Apache en nuestro sistema es instalar una versión en RPM ya sea desde el CD de nuestra distribución o desde por ejemplo nuestra zona privada, ninguna versión anterior a la 1.1 es recomendada y nosotros aconsejamos lógicamente obtener la más actualizada posible.

Para instalar una versión en RPM como ya sabemos, simplemente tenemos que ejecutar como usuario root la siguiente orden:

rpm -i apache-1.3.27-2.i386.rpm

(El RPM indicado viene con la distribución de RedHat 7-3 y es el que utilizaremos para realizar esta documentación).

Una vez instalado nuestro servidor Apache únicamente tenemos que editar el fichero de configuración de Apache llamado httpd.conf (generalmente situado en /etc/httpd/conf/httpd.conf), ya que el módulo para la función de Proxy ya estará compilado y únicamente tendremos que cargarlo.

Para activarlo simplemente descomentar las dos siguientes líneas:



#Load Module proxy_module /usr/liblapache/libproxy.so#AddModule mod_proxy.c

Una vez descomentadas las dos líneas ya tenemos cargada la funcionalidad de Proxy-Caché y podremos pasar a configurar y utilizar las directivas deseadas.

Instalación mediante código fuente

En caso que ya tengamos una versión de Apache en nuestro sistema y no aparezcan las dos líneas descritas en Instalación mediante RPM, posiblemente no tengamos compilado el módulo para poder utilizar el servidor como Proxy. En este caso deberíamos comprobar si disponemos de la librería libproxy.so en nuestro sistema, si es así, simplemente añadimos las dos líneas que faltan en httpd.conf. En caso de no disponer de la librería, debemos recompilar e instalar el código fuente.

Recomendamos guardar el archivo httpd.conf si deseamos conservar nuestra configuración actual. Una vez estemos seguros que no disponemos de la librería libproxy.so, podemos proceder a la descarga del paquete con el código fuente desde www.apache.org.

Para descomprimir el paquete utilizar la siguiente orden:

tar -xzvf apache_1.3.27.tar.gz

Una vez descomprimido el paquete debemos de ejecutar el siguiente script con los siguientes parámetros:

./configure -prefix=/usr/local/apache

Esta orden permite especificar el directorio donde se instalará el servidor apache (deberíamos especificar el mismo que teníamos). Una vez realizado esto se generarán los Makefiles y un nuevo fichero llamado config.status que actúa como script para seguir configurando. Por tanto indicaremos los módulos que queremos instalar que en éste caso serán: el modulo para poder utilizar módulos y el módulo para Proxy, tal como mostramos a continuación:

./config.status --active-module=src/modules/standard/mod_so.c

./config.status -enable-module=proxy

Una vez hemos realizados los pasos indicados, simplemente tenemos que compilar el código fuente mediante la orden make all y posteriormente indicar que se instale en el sistema mediante make install.

Ejemplo de configuración de sus directivas

En éste apartado mostramos un pequeño ejemplo de las directivas que deberían de situarse descomentadas dentro del fichero httpd.conf para poder utilizar el servidor Apache como Proxy y como Proxy con caché.

<If Module mod_proxy.c>#Directivas para realizar función de ProxyProxyRequest OnListen 80Listen 8087AllowCONNECT 443 563 23ProxyBlock www.sex.com www.microsoft.com#ProxyRemote * http://192.168.0.84:8087#NoProxy www.hotmail.com#ProxyPass / http://192.168.0.84/#ProxyPassReverse / http://192.168.0.84/<Directory proxy:*>



Order deny, allow Deny from all Allow from .informatica.escoladeltreball.org</Directory>ProxyVia Full

#Directivas para realizar la función de cachéCacheRoot "/var/cache/httpd"CacheSize 50000CacheGcInterval 1CacheMaxExpire 24CacheLastModifiedFactor 0.1CacheDefaultExpire 3CacheForceCompletion 90#NoCache pc47.informatica.escoladeltreball.org</IfModule>

En el siguiente apartado se describe el significado y la utilidad de las directivas en el orden presentado.

Explicación de las directivas

Una vez presentadas las directivas describiremos su utilidad y funcionamiento para una mayor comprensión de las posibilidades de Apache-Proxy.

ProxyRequest (Activar Proxy)

Esta directiva permite activar o desactivar la función de Proxy. Tener en cuenta que se anularán todas las directivas tanto para funciones de caché como de Proxy, excepto la directiva ProxyPass.

Sus valores pueden ser On u Off tal como se muestra a continuación y solo está disponible en Apache 1.1 y superiores.

ProxyRequest OnProxyRequest Off

Listen (Asignar Puerto)

Permite indicar a Apache que escuche peticiones en más de una dirección IP o puerto. Por defecto si no especificamos ninguna IP escucha para todas, pero solo para el puerto indicado.

Sus valores pueden ser [dirección-IP:]puerto tal como se muestra a continuación y solo está disponible en Apache 1.1 y superiores.

Listen 8087Listen 80Listen 192.168.0.87:8080

AllowCONNECT (Permitir método CONNECT)

Permite especificar una lista de puertos a los que el Proxy mediante el método CONNECT quizá conecte.

Sus valores pueden ser port [port]... tal como se muestra a continuación y solo está disponible en Apache 1.3.2 y superiores.

AllowCONNECT 443 563 23



Son los puertos que utiliza HTTPS, SNEWS y telnet respectivamente.

Un ejemplo práctico

Para probar su funcionamiento utilizaremos el cliente telnet con el fin de realizar una conexión a un host remoto a través del Proxy mediante el protocolo HTTP.

1. Hacemos un telnet al servidor Proxy en el puerto que está escuchando.

telnet 192.168.0.87 80872. Una vez realizada la conexión, el cliente telnet espera que le indiquemos una petición.

Conectamos desde el Proxy al ordenador deseado mediante el puerto 23 que utiliza telnet.

CONNECT 192.168.0.84:23 http/1.03. Presionamos la tecla Enter y la sesión telnet se realiza a través del Proxy y lógicamente

mantenida por éste ya que si desactivamos Apache con la orden: service httpd stop, la conexión se pierde.

ProxyBlock (Control acceso URL, control según destino)

Bloquea peticiones HTTP, HTTPS y FTP de documentos que contengan en su dirección la palabra, el host o el dominio especificado.

Sus valores pueden ser *|word|host|domain [word|host|domain]... tal como se muestra a continuación y solo está disponible en Apache 1.2 y superiores.

ProxyBlock www.sex.com rocky.wotsamattau.eduProxyBlock *

Tener en cuenta que especificar la palabra "sex" ya es suficiente para bloquear direcciones como: www.sex.com www.sexista.com http://sexologia.com y que utilizar el "*" significa bloquear todas las peticiones.

Además, esta directiva es muy interesante ya que en caso de enviar las peticiones a un Proxy remoto mediante la directiva ProxyRemote, el bloqueo se continúa realizando y por tanto se podrían utilizar Proxys para restringir el acceso a determinados usuarios y un Proxy remoto para realizar las peticiones que se hubieran permitido.

ProxyRemote (Desviar a un Proxy, control según destino)

Permite indicar que páginas web serán gestionadas por un servidor Proxy remoto, es decir será el remoto quien realizará la petición al servidor y la cacheará.

Sus valores pueden ser URL http://hostname[:port] tal como se muestra a continuación y solo está disponible en Apache 1.1 y superiores.

ProxyRemote http://hotmail.com/ http://192.68.0.84:8087ProxyRemote * http://192.68.0.84:8087ProxyRemote ftp http://192.68.0.84:8087

En la segunda línea se especifica que todas las peticiones de direcciones web las procesará un servidor remoto y en la tercera que todas las peticiones ftp las gestionará un servidor remoto.



NoProxy (No desviar a otro Proxy, control según destino)

Esta directiva hace referencia a la directiva ProxyRemote y permite especificar que peticiones no las ha de enviar al Proxy remoto sino que las tiene que procesar él directamente.

Sus valores pueden ser: domain|SubRed|IpAddress|Hostname [domain|SubRed|IpAddress|Hostname]..., tal como se muestra a continuación y solo está disponible en Apache 1.3 y superiores.

ProxyRemote * http://192.68.0.84:8087NoProxy .company.com 192.168.112.0/21 www.hotmail.com

Los ejemplos mostrados corresponden a un dominio una subred y un hostname.

ProxyPass (Desviar contenidos a un nuevo web server)

Permite al servidor Proxy local actuar como un espejo del servidor que en realidad ahora está sirviendo el contenido. Esta directiva es útil si en un pasado nuestro servidor Apache servia unos documentos web que ahora los sirve otro servidor, ya que no será necesario avisar a la gente del traslado y podrán continuar haciendo la petición al servidor antiguo ya que la directiva redireccionará sin que el usuario se dé cuenta de nada. Además esta directiva sigue funcionando aunque deshabilitemos la función de Proxy.

Sus valores pueden ser: path url, donde "path" es el nombre del antiguo "path virtual local" y "url" es una dirección parcial del servidor remoto, tal como se muestra a continuación y solo está disponible en Apache 1.1 y superiores.

ProxyPass /mirror/foo/ http://server2.org/

A la práctica si nuestro servidor local tuviera la dirección http://server.org/ y ya no ofreciera el contenido web, al pedir http://server.org/mirror/foo/web.html se redireccionaría la petición a http://server2.org/web.html.

Un ejemplo práctico

Tenemos un servidor Apache que ya no contiene documentos, con la dirección IP: 192.168.0.87 y un nuevo servidor Apache con la dirección IP: 192.168.0.84 que se encargará de servir los documentos a partir de ahora. Configuramos en el servidor 192.168.0.87 la directiva de redirección:

ProxyPass / http://192.168.0.84/

Ahora con el cliente pedimos http://192.168.0.87/icons/ y recibimos los documentos todo y que ya no los tiene, debido a que automáticamente a realizado la petición a http://192.168.0.84/icons/.

Conceptos y trucos para Apache y Squid

Cabeceras HTTP y funcionamiento de la caché

La finalidad de este apartado consiste en explicar como un navegador almacena y consulta las páginas de su caché y como lo hace un servido Proxy, de esta manera podemos presentar como modificar su comportamiento por defecto y averiguar posibles deficiencias. Antes de empezar se muestran algunas de las cabeceras del protocolo HTTP/1.1 que se suelen utilizar en Proxys y navegadores.

Cabeceras del mensaje

Las siguientes cabeceras forman parte del protocolo HTTP/1.1 definidas en el RFC2616, salvo que se indique lo contrario.



Cache-Control

Permite indicar si un elemento puede ser cacheado y su caducidad.

Valor Significado

public Indica que la respuesta a una petición puede ser ocultada (cacheada) tanto por clientes como por el Proxy.

private Indica que la respuesta no se puede cachear por caches compartidas, es decir, solamente en teoría podría cachearla un cliente.

no-cache No puede cachear el elemento ni el cliente ni el Proxy.

max-age Segundos máximos que se considera un objeto no caducado desde que se realizó su petición.

must-revalidate Obliga a comparar con el servidor web antes de usar el caché.

Pragma

Corresponde al HTTP/1.0 pero por razones de compatibilidad actualmente se considera soportado aunque solo para peticiones. Su sintaxis es la misma que en Cache-Control.

Via

Usado por Proxys o gateways para indicar el protocolo intermedio entre el cliente y el servidor. Generalmente se suele añadir la maquina y la versión del software del Proxy.

Valor SignificadoOn Mostrará información como el nombre de la máquina del Proxy.Off No añade información en la cabecera Via.Full Mostrará información como el nombre de la máquina y la versión del software.Block Eliminará las líneas en que aparezca la cabecera Via.

Expires

Indica cuando caducará una respuesta dada por el servidor web. El formato de esta cabecera esta definido en el RFC850.

Ejemplo fecha sin caducar --> Sun, 17 Jan 2038 20:14:07 GMT

Ejemplo fecha caducada --> Wed, 26 Feb 2001 08:21:57 GMT

Last-Modified

Indica en una respuesta cuando el servidor considera que se modificó por última vez la página o objeto que proporciona. Si la cabecera Expires no está presente, se toma este valor para determinar la caducidad. Cada Proxy y navegador utiliza su criterio, pero un ejemplo consistiría en que si tenemos un objeto en el caché desde hace 10 días y cuando se introdujo se sabía que había sido modificado 150 días antes, es lógico considerar que todavía no se habrá modificado.

X-Cache

Esta cabecera no pertenece a ningún estándar, la consideramos ya que servidores Proxy como Apache o Squid la añaden para indicar si la página ha sido cogida desde el caché o bien desde el servidor.



Valor SignificadoMISS La página no se ha servido desde el caché.HIT La página se ha servido desde el caché.

Fichero de auto-configuración para navegadores

El fichero de auto-configuración permite indicar a los navegadores que Proxy deben utilizar para realizar sus peticiones, de esta manera evitamos que el usuario sea el encargado de configurar manualmente su conexión a Internet.

El hecho de utilizar un fichero ya configurado permite además, modificar el puerto y las IP's de los servidores Proxy sin tener que volver a re-configurar todos los navegadores.

Creación del fichero

Para que el fichero pueda ser accesible desde cualquier navegador, podemos almacenarlo en un servidor web, en un directorio de red o en un servidor FTP, a continuación se muestran los pasos para que el navegador pueda acceder a este fichero mediante Apache Web Server.

1. Añadir la siguiente línea en el fichero /etc/mime.types que utiliza Apache Web Server para indicar al navegador (mediante la cabecera Content-Type), que tipo de fichero está recibiendo.

application/x-ns-proxy-autoconfig pac

De esta manera indicamos que todos los ficheros .pac que sirve Apache se interpreten como ficheros de auto-configuración.

2. Añadir las siguientes líneas en httpd.conf para que se pueda acceder al fichero de auto-configuración mediante por ejemplo: http://host/proxy/proxy.pac

3. Alias /proxy/ /ruta/del/fichero/4. <Directory /ruta/del/fichero>5. Options None6. AllowOverride None7. Order allow,deny8. Allow from all

</Directory>9. Creamos el fichero proxy.pac con permisos de lectura para todos. 10. touch /ruta/del/fichero/proxy.pac

chmod 644 /ruta/del/fichero/proxy.pac

Configuración del fichero

El fichero proxy.pac que hemos creado en la sección anterior debe de ser escrito en JavaScript y presentar como "main" la función FindProxyForURL(url, host), la cual recibe del navegador los dos argumentos especificados y devuelve a éste un valor que le indica como debe de actuar, los valores de retorno posibles se describen a continuación.

DIRECTIndica al navegador que se conecte sin utilizar ningún Proxy.

PROXY host:portPermite indicar al navegador la IP y el puerto del Proxy.

Ejemplo

return "PROXY 192.168.0.87:3128";


A continuación, presentamos un ejemplo del código que debe de tener el fichero de auto-configuración para que sea interpretado por los navegadores.

function FindProxyForURL(url, host){if (shExpMatch(url, "*.tu-dominio.org")) return "DIRECT";else if (isInNet(myIpAddress(), "192.168.0.0", "255.255.255.0")) return "PROXY 192.168.0.87:3128";else return "PROXY 192.168.0.87:8087";}

Configuración de los clientes

El código del fichero de auto-configuración que hemos presentado es válido para navegadores como Mozilla y Netscape, donde funciona correctamente.

1. Seleccionar en el menú de Mozilla y Netscape: Edit - Preferences - Advanced - Proxies

En caso de Internet Explorer seleccionar: Herramientas - Opciones de Internet - Conexiones - Configuración de LAN

2. Introducir la siguiente línea en la opción:

Automatic proxy configuration URL --> En Mozilla y Netscape

Usar secuencia de comandos de configuración automática --> En Internet Explorer

http://host/proxy/proxy.pac 3. Presionar la tecla Reload para activar los cambios en Mozilla y Netscape o reiniciar el navegador

para que se lea el fichero en caso de Internet Explorer.

CONCEPTO DE FIREWALLS (MURO DE FUEGO)

Es un sistema o grupo de sistemas que impone una política de seguridad entre la organización de red privada y el Internet. Es un mecanismo para restringir acceso entre la Internet y la red corporativa interna. Típicamente se instala un firewall en un punto estratégico donde una red (o redes) se conectan a la Internet.

Un buen Firewall para Internet puede ayudarle a impedir que extraños accedan a su PC desde Internet. Los Firewalls pueden ser de dos tipos, de software o de hardware, y proporcionan una frontera de protección que ayuda a mantener fuera a los invasores no deseados de Internet.La existencia de un firewall en un sitio Internet reduce considerablemente las probabilidades de ataques externos a los sistemas corporativos y redes internas, además puede servir para evitar que los propios usuarios internos comprometan la seguridad de la red al enviar información peligrosa (como passwords no encriptados o datos sensitivos para la organización) hacia el mundo externo.

Si el Firewall "observa" alguna actividad sospechosa: que alguien de fuera esté intentando acceder a nuestro Pc o que algún programa espía trate de enviar información sin consentimiento, el Firewall nos advertirá con una alarma en el sistema.


Para entender el funcionamiento de este sistema, debes saber que el ordenador dispone de varias puertas de salida y entrada cuando se conecta a Internet. Éstas se llaman puertos y cada servicio que utilizas se sirve de un puerto diferente: Los navegadores de internet necesitan el puerto 80, los programas FTP el 21, etc... En general tenemos todos los puertos abiertos.

ORIGEN DE LA PALABRA FIREWALLS

El concepto de firewall proviene de la mecánica automotriz, donde se lo considera una lámina protectora / separadora entre el habitáculo de un vehículo y las partes combustibles del motor, que protege a sus pasajeros en caso de incendio. Análogamente, un firewall, en un sentido más informático, es un sistema capaz de separar el habitáculo de nuestra red, o sea, el área interna de la misma, del posible incendio de crackers que se produciría en ese gran motor que es internet.

¿POR QUÉ UN FIREWALL?

Básicamente la razón para la instalación de un firewall es casi siempre la misma: proteger una red privada contra intrusos dentro de un esquema de conectividad a Internet. En la mayoría de los casos, el propósito es prevenir el acceso de usuarios no autorizados a los recursos computacionales en una red privada y a menudo prevenir el tráfico no autorizado de información propietaria hacia el exterior.

OBJETIVO DE UN FIREWALLS

Un firewall sirve para múltiples propósitos, entre otros podemos anotar los siguientes:

- Restricción de entrada de usuarios a puntos cuidadosamente controlados de la red interna.

- Prevención ante los intrusos que tratan de ganar espacio hacia el interior de la red y los otros esquemas de defensas establecidos.

- Restricción de uso de servicios tanto a usuarios internos como externos.

- Determinar cuáles de los servicios de red pueden ser accesados dentro de ésta por los que están fuera, es decir, quién puede entrar a utilizar los recursos de red pertenecientes a la organización.Todo el tráfico que viene de la Internet o sale de la red corporativa interna pasa por el firewall de tal forma que él decide si es aceptable o no.

BENEFICIOS DE UN FIREWALL

Administra los accesos posibles del Internet a la red privada.Protege a los servidores propios del sistema de ataques de otros servidores en Internet.Permite al administrador de la red definir un "choke point" (embudo), manteniendo al margen los usuarios no-autorizados, prohibiendo potencialmente la entrada o salida al vulnerar los servicios de la red.

Ofrece un punto donde la seguridad puede ser monitoreada.Departamento de Sistemas de Información Septiembre 2007 – Los derechos de Autor sobre el siguiente Manual corresponde a sus Creadores Originales


Ofrece un punto de reunión para la organización. Si una de sus metas es proporcionar y entregar servicios información a consumidores, el firewall es ideal para desplegar servidores WWW y FTP.

LIMITACIÓN DE UN FIREWALLS

Puede únicamente autorizar el paso del trafico, y él mismo podrá ser inmune a la penetración. Desafortunadamente, este sistema no puede ofrecer protección alguna una vez que el agresor lo traspasa o permanece en torno a éste.

No puede proteger contra aquellos ataques que se efectúen fuera de su punto de operación.

No puede proteger de las amenazas a que está sometido por traidores o usuarios inconscientes.

No puede prohibir que los traidores o espías corporativos copien datos sensitivos y los substraigan de la empresa.

No puede proteger contra los ataques de la "Ingeniería Social", por ejemplo un Hacker que pretende ser un supervisor o un nuevo empleado despistado.

No puede proteger contra los ataques posibles a la red interna por virus informativos a través de archivos y software.

BASES PARA EL DISEÑO DECISIVO DEL FIREWALL

Posturas sobre la política del Firewall.

La política interna propia de la organización para la seguridad total.

El costo financiero del Proyecto "Firewall".

Los componentes o la construcción de secciones del Firewall.

POLÍTICAS DEL FIREWALL

"No todo lo específicamente permitido está prohibido"

"Ni todo lo específicamente prohibido está permitido"

La primera postura asume que un firewall puede obstruir todo el tráfico y cada uno de los servicios o aplicaciones deseadas necesariamente para ser implementadas básicamente caso por caso.

La desventaja es que el punto de vista de "seguridad" es más importante que facilitar el uso de los servicios y éstas limitantes numeran las opciones disponibles para los usuarios de la comunidad.

La segunda postura asume que el firewall puede desplazar todo el trafico y que cada servicio potencialmente peligroso necesitará ser aislado básicamente caso por caso.

La desventaja de esta postura se basa en la importancia de "facilitar el uso" que la propia seguridad del sistema.

POLÍTICA INTERNA DE SEGURIDAD.Un firewall de Internet no está solo, es parte de la política de seguridad total en una organización. Para que ésta sea exitosa, la organización debe conocer qué es lo se está protegiendo.COSTO DEL FIREWALL.

¿Cuánto puede ofrecer una organización por su seguridad?. Un simple paquete de filtrado puede tener un costo mínimo.



Un firewall casero. Un sistema comercial.

Finalmente requiere de soporte continuo para la administración, mantenimiento general, actualización de software, reparación de seguridad, e incidentes de manejo.

¿CÓMO FUNCIONA?

Un Firewall funciona, en principio, denegando cualquier tráfico que se produzca cerrando todos los puertos de nuestro PC. En el momento que un determinado servicio o programa intente acceder al ordenador nos lo hará saber. Podremos en ese momento aceptar o denegar dicho tráfico, pudiendo asimismo hacer (para no tener que repetir la operación cada vez) "permanente" la respuesta hasta que no cambiemos nuestra política de aceptación.

También puedes optar por configurar el Firewall de manera que reciba sin problemas cierto tipo de datos (FTP, chat o correo, por ejemplo) y que filtre el resto de posibilidades. Un firewall puede ser un dispositivo software o hardware, es decir, un aparatito que se conecta entre la red y el cable de la conexión a Internet, o bien un programa que se instala en la máquina que tiene el modem que conecta con Internet.

Windows XP cuenta con un Firewall, aunque muy sencillo. Sólo te permite filtrar la información que entra en tu ordenador, no la que sale.

De esta forma, no te servirá de nada si tienes instalado un programa Adware que recoge datos de tu equipo y se conecta al exterior para enviarlos. Conviene que te instales un Firewall más completo y que te permita configurar políticas de seguridad.

Muchas compañías de seguridad disponen de vesiones shareware y freeware de sus Firewalls. - La empresa Kerio dispone de una versión gratuita para usuarios no profesionales.- ZoneAlarma es una de las firmas más populares en Firewalls.- En el site de Agnitum puedes optar por una versión gratuita y una Pro, dependiendo de tus necesidades.

¿QUÉ SON LOS SERVIDORES PROXY Y COMO TRABAJAN?

Un servidor proxy (algunas veces se hace referencia a el con el nombre de "gateway" - puerta de comunicación - o "forwarder" - agente de transporte -), es una aplicación que media en el tráfico que se produce entre una red protegida e Internet. Los proxies se utilizan a menudo, como sustitutorios de routers controladores de tráfico, para prevenir el tráfico que pasa directamente entre las redes. Muchos proxies contienen logines auxiliares y soportan la autentificación de usuarios. Un proxy debe entender el protocolo de la aplicación que está siendo usada, aunque también pueden implementar protocolos específicos de seguridad (por ejemplo: un proxy FTP puede ser configurado para permitir FTP entrante y bloquear FTP saliente).

Los servidores proxy, son aplicaciones específicas. Un conjunto muy conocido de servidores proxy son los TIS Internet Firewall Toolkit "FWTK", que incluyen proxies para Telnet, rlogin, FTP, X-Windows, http/Web, y NNTP/Usenet news. SOCKS es un sistema proxy genéricos que puede ser compilado en una aplicación cliente para hacerla trabajar a través de una Firewall.

COMPONENTES DEL SISTEMA FIREWALL Software Filtra-paquetes. Gateway a Nivel-aplicación. Gateway a Nivel-circuito.

Software filtra-paquetes

Toma las decisiones de rehusar / permitir el paso de cada uno de los paquetes que son recibidos. El programa examina cada datagrama para determinar si este corresponde a uno de sus paquetes filtrados y que a su vez haya sido aprobado por sus reglas.



Permite la entrada de sesiones Telnet únicamente a una lista especifica de servidores internos Permite la entrada de sesiones FTP únicamente a los servidores internos especificados Permite todas las salidas para sesiones Telnet Permite todas las salidas para sesiones FTP Rehusar todo el trafico UDP

Beneficios del software filtra-paquetes. El costo para implementar la filtración de paquetes no es cara. Es por lo general transparente a los usuarios finales y a las aplicaciones. no se requiere de entrenamiento especializado. No se requiere software específico que tenga que ser instalado en cada uno de los servidores.

Limitaciones del filtra-paquetes. Definir el filtrado de paquetes puede ser una tarea compleja. Si las necesidades de filtrado son muy complejas, se necesitará soporte adicional. Finalmente, éstas políticas serán menos fáciles de verificar para las correcciones de las reglas

de filtrado después de ser configuradas.Gateways A Nivel-Aplicación Los gateways nivel-aplicación permiten al administrador de red la implementación de una política de seguridad estricta que la que permite un ruteador filtra-paquetes. Mucho mejor que depender de una herramienta genérica de filtra-paquetes para administrar la circulación de los servicios de Internet a través del firewall, se instala en el gateway un código de proposito-especial (un servicio Proxy) para cada aplicación deseada. Si el administrador de red no instala el código Proxy para la aplicación particular, el servicio no es soportado y no podrán desplazarse a través del firewall.

Aun cuando, el código Proxy puede ser configurado para soportar únicamente las características especificas de una aplicación que el administrador de red considere aceptable mientras niega todas las otras.

Un aumento de seguridad de este tipo incrementa nuestros costos en términos del tipo de gateway seleccionado, los servicios de aplicaciones del Proxy, el tiempo y los conocimientos requeridos para configurar el gateway, y un decrecimiento en el nivel de los servicios que podrán obtener nuestros usuarios, dando como resultado un sistema carente de transparencia en el manejo de los usuarios en un ambiente "amigable". Como en todos los casos el administrador de redes debe de balancear las necesidades propias en seguridad de la organización con la demanda de "fácil de usar" demandado por la comunidad de usuarios.

Es importante notar que los usuarios tienen acceso por un servidor Proxy, pero ellos jamas podrán seccionar en el Gateway a nivel-aplicación. Si se permite a los usuarios seccionar en el sistema de firewall, la seguridad es amenazada desde el momento en que un intruso puede potencialmente ejecutar muchas actividades que comprometen la efectividad del sistema.

Por ejemplo, el intruso podría obtener el acceso de root, instalar un caballo de troya para colectar las contraseñas, y modificar la configuración de los archivos de seguridad en el filrewall.

Servidor de defensa

Un ruteador filtra-paquetes permite la circulación directa de los paquetes dentro y fuera del sistema, diferente a esto el Gateway a nivel-aplicación deja que la información circule entre los sistemas pero no permite el intercambio directo de paquetes. El principal riesgo de permitir que los paquetes se intercambien dentro y fuera del sistema se debe a que el servidor residente en los sistemas de protección de la red podrá ser asegurado contra cualquier amenaza representada por los servicios permitidos.

Un Gateway a nivel-aplicación por lo regular es descrito como un "servidor de defensa" porque es un sistema diseñado específicamente blindado y protegido contra cualquier ataque. Hay varias características de diseño que son usadas para hacer mas seguro un servidor de defensa:

La plataforma de Hardware del servidor de defensa ejecuta una versión "segura" de su sistema operativo. Por ejemplo, si el servidor de defensa es una plataforma UNIX, se ejecutara una versión segura del sistema operativo UNIX que es diseñado específicamente para proteger los sistemas operativos vulnerables y garantizar la integridad del firewall.



Unicamente los servicios que el administrador de redes considera esenciales son instalados en el servidor de defensa. La lógica de operación es que si el servicio no esta instalado, este puede ser atacado. Generalmente, un conjunto limitado de aplicaciones Proxy tales como Telnet, DNS, FTP, SMTP, y autenticación de usuarios son instalados en este servidor.

El servidor de defensa podrá requerir de una autenticación adicional para que el usuario accese a los servicios Proxy. Por ejemplo, el servidor de defensa es ideal para colocar un sistema fuerte de supervisión de autorización (tal como la tecnología "una-sola vez" de contraseña donde una tarjeta inteligente generaba un código de acceso único por medios criptográficos). Adicionalmente, cada servicio Proxy podrá requerir de autorización propia después que el usuario tenga acceso a su sesión.

Cada Proxy es configurado para soportar únicamente un subconjunto de aplicaciones estándar de un conjunto de comandos. Si un comando estándar no es soportado por la aplicación Proxy, es porque simplemente no esta disponible para el usuario.

Cada Proxy esta configurado para dejar acceder únicamente a los servidores especificados en el sistema. Esto significa que existe un conjunto de características/comandos que podrán ser aplicados para un subconjunto de sistemas en la red protegida.

Cada Proxy mantiene la información detallada y auditada de todos los registros del trafico, cada conexión , y la duración de cada conexión. El registro de audición es un herramienta esencial para descubrir y finalizar el ataque de un intruso.

Cada Proxy es un programa pequeño y sencillo específicamente diseñado para la seguridad de redes. Este permite que el código fuente de la aplicación pueda revisar y analizar posibles intrusos y fugas de seguridad. Por ejemplo, una típica aplicación - UNIX mail - puede tener alrededor de 20,000 líneas de código cuando un correo Proxy puede contener menos de mil.

Cada Proxy es independiente de todas las demás aplicaciones Proxy en el servidor de defensa. Si se sucitara un problema con la operación de cualquier Proxy, o si se descubriera un sistema vulnerable, este puede desinstalarse sin afectar la operación de las demás aplicaciones. Aun, si la población de usuarios requiere el soporte de un nuevo servicio, el administrador de redes puede fácilmente instalar el servicio Proxy requerido en el servidor de defensa.

Un Proxy generalmente funciona sin acceso al disco lo único que hace es leer su archivo de configuración inicial . desde que la aplicación Proxy no ejecuta su acceso al disco para soporte, un intruso podrá encontrar mas dificultades para instalar caballos de Troya perjudiciales y otro tipo de archivos peligrosos en el servidor de defensa.

Cada Proxy corre como un usuario no-previlegiado en un directorio privado y seguro del servidor de defensa.

Ejemplo: telnet proxy

Operación de un Telnet Proxy en un servidor de defensa. Para este ejemplo, un cliente externo ejecuta una sesión Telnet hacia un servidor integrado dentro del sistema de seguridad por el Gateway a nivel-aplicación.



Ilustración Telnet Proxy.

El Telnet Proxy nunca permite al usuario remoto que se registre o tenga acceso directo al servidor interno. El cliente externo ejecuta un telnet al servidor de defensa donde es autorizado por la tecnología "una-sola vez" de contraseña. Después de ser autentificado, el cliente obtiene acceso a la interface de usuario del Telnet Proxy. Este únicamente permite un subconjunto de comandos Telnet y además determina cual de los servidores son disponibles para el acceso vía Telnet.

Beneficios del Gateway a nivel-aplicación

Son muchos los beneficios desplegados en un gateway a nivel-aplicación. Ellos dan a la administración de red un completo control de cada servicio desde aplicaciones proxy limitadas por un conjunto de comandos y la determinación del servidor interno donde se puede accesar a los servicios. Aun cuando, el administrador de la red tenga el completo control acerca de que servicios que son permitidos desde la carencia de un servicio proxy para uno en particular significa que el servicio esta completamente bloqueado. Los gateways a nivel-aplicación tienen la habilidad de soportar autenticaciones forzando al usuario para proveer información detallada de registro. Finalmente, las reglas de filtrado para un gateway de este tipo son mucho mas fáciles de configurar y probar que en un ruteador filtra-paquetes.

Limitaciones del Gateway a nivel-aplicación

Probablemente una de las grandes limitaciones de un gateway a nivel-aplicación es que requiere de modificar la conducta del usuario o requiere de la instalación de software especializado en cada sistema que accese a los servicios Proxy. Por ejemplo, el acceso de Telnet vía gateway a nivel-aplicación demanda modificar la conducta del usuario desde el momento en que se requiere de dos pasos para hacer una conexión mejor que un paso. Como siempre, el software especializado podrá ser instalado en un sistema terminado para hacer las aplicaciones del gateway transparentes al permitir a los usuarios especificar el servidor de destino, mejor que el propio, en un comando de telnet.Gateway a nivel-circuito

Un Gateway a nivel-circuito es en si una función que puede ser perfeccionada en un Gateway a nivel-aplicación. A nivel-circuito simplemente trasmite las conexiones TCP sin cumplir cualquier proceso adicional en filtrado de paquetes.

Ilustración Gateway Nivel-Circuito.Tal como se menciono anteriormente, este gateway simplemente trasmite la conexión a través del firewall sin examinarlo adicionalmente, filtrarlo, o dirigiendo el protocolo de Telnet. El gateway a nivel-circuito acciona como una cable copiando los bytes antes y después entre la conexión interna y la conexión Departamento de Sistemas de Información Septiembre 2007 – Los derechos de Autor sobre el siguiente Manual corresponde a sus Creadores Originales


externa. De cualquier modo, la conexión del sistema externo actúa como si fuera originada por el sistema de firewall tratando de beneficiar el encubrir la información sobre la protección de la red.

El Gateway a nivel-circuito se usa frecuentemente para las conexiones de salida donde el administrador de sistemas somete a los usuarios internos. La ventaja preponderante es que el servidor de defensa puede ser configurado como un Gateway "híbrido" soportando nivel-aplicación o servicios Proxy para conexiones de venida y funciones de nivel-circuito para conexiones de ida.

Esto hace que el sistema de firewall sea fácil de usar para los usuarios internos quienes desean tener acceso directo a los servicios de Internet mientras se proveen las funciones del firewall necesarias para proteger la organización de los ataques externos.

FACTORES QUE NO HACEN DESEABLE UNA FIREWALL

INEFICIENTE: el firewall se convierte en un cuello de botella de toda la estructura y debe poseer por lo tanto una eficiencia en la manipulación de los streams de paquetes que sea igual o superior a la del enrutador que maneja tal enlace.

Normalmente la experiencia y conocimiento de los fabricantes de firewalls no se acerca siquiera a la tradición y conocimiento de los fabricantes tradicionales de enrutadores, por ello rara vez pueden cumplir el requisito anterior y lo que se consigue en la practica es un cuello de botella, así como enrutadores sub utilizados debido a la situación anterior.

Este factor también nos conduce a que los costos para maquina de firewall que cumplan tales requisitos sean bastante altos ya que su volumen de producción (numero de unidades vendidas) no se acerque a la producción típica de los enrutadores correspondientes para ese nivel de procesamiento de paquetes por segundo.

NO TAN SEGURO: los firewall son típicamente implementados en un sistema UNIX lo que los hace bastante vulnerables para los ataques de seguridad, ya que de tal sistema existe mayor conocimiento del público en general, y son bastante publicadas las posibles brechas de seguridad en ese sistema operativo, por ello es el blanco típico de ataque para los programas especializados de scanning de los hackers (estudian "pacientemente" múltiples opciones del sistema, hasta encontrar un punto de acceso o modificación).estos programas son en un 99% desarrollados para sistemas UNIX. Si mi seguridad esta sustentada en una maquina cuyo núcleo está apoyada en el sistema UNIX (el cual es precisamente el más conocido por los enemigos de mi seguridad), entonces mi sistema no es realmente tan seguro.

MUCHAS VECES NO SON TRANSPARENTES A LA OPERACIÓN DEL USUARIO: debido a su diseño, algunos de estos modelos no son tan transparentes a la operación del sistema, complican la administración del sistema de comunicación (usualmente tienen interfaces de manejo propietarias). Algunos modelos basados en "proxies" pueden ser muy seguros, pero algunos de ellos requieren versiones modificadas de los aplicativos, llevando los a ser poco deseables para montajes masivos.

SON INAPROPIADOS PARA MONTAJES MIXTOS: por su misma concepción el montaje solicitado por las compañías cuenta con dos niveles de VPNs (la intranet corporativa y luego las intranet de cada empresa), los cuales deben ser interrrelacionados de manera armoniosa para flujo de información y control de acceso. Este tipo de montaje seria bastante costoso, dificil de implementar y de administrar con dos niveles de firewalls.

COMPRAR O CONSTRUIR

Algunas organizaciones tienen la capacidad de construir sus propias firewall, usando cualquiera de los equipos y componentes de software disponibles o escribiendo un firewall. Al mismo tiempo, la totalidad de los vendedores ofrecen una amplia variedad de servicios en tecnología de firewall, desde proveer las herramientas necesarias hasta implementar pólizas de seguridad hasta cálculos fuera de riesgos, revistas de seguridad y entrenamiento de seguridad.



Una de las ventajas para una compañía al construir su propia firewall es que el personal de la misma entenderá las especificaciones del diseño y uso de la firewall. Tal conocimiento puede no existir para un vendedor - proveedor de firewall. Además, una firewall puede requerir una gran cantidad de tiempo para construirla, documentarla y mantenerla.

Una firewall puede ser tan efectiva como la administración que la hizo. Un mantenimiento pobre puede empezar a ser inseguro y permitir roturas mientras provee una ilusión de seguridad. La póliza de seguridad podría reflejar claramente la importancia de la administración de una firewall fuerte, y el manejo demostraría su importancia en términos de personal, fondos y otros recursos necesarios.

El contar con una firewall no es excusa para prestar menos atención a la administración de un sistema en el lugar, de hecho, si una firewall es penetrada, una administración pobre permitirá amplias intrusiones resultando dañada, también una firewall no reduce las necesidades de administrar un sistema altamente calificado al mismo tiempo.

Amoroso y sharp concuerdan en que no es sencillo y correcto el set de funciones de una firewall para todos los medio ambientes.

Ellos recomiendan que cada comprador seleccione funciones basadas en los requerimientos únicos de la empresa que desee contar con una firewall.

Un problema encontrado por muchos compradores de firewall es que los vendedores, preparan literatura que ponen a sus productos en lo más alto posible y describen diseños y filosofías de ventas apropiadas para la compañía. Sin embargo. Los estándares han surgido en otras arreas de hardware y software, ambos en tecnología y descripción de funciones.

CERTIFICACIÓN

ICSA, Inc. Intenta desarrollar criterios imparciales para definir buenos productos de seguridad. Por ejemplo, por muchos años ICSA ha estado probando y certificando productos antivirus. Los usuarios de estos productos han indicado que la certificación ha sido de gran ayuda. Una compañía compra un producto antivirus certificada sabe que realizara estándares claros establecidos y de esta manera podrá evitar más desordenes costosos que de otra manera requerirá de otra clase de diligencias.

La certificación firewall opera con principios similares. Las compañías que fabrican firewall pueden someterlos a prueba, y si pasan la prueba, ellos pueden colocar el logo de certificación. Esto proporciona una seguridad a los compradores que este producto satisface ampliamente un nivel de estándar de seguridad. En otras palabras, un comprador puede confiar que todos los productos que han sido certificados, realizan, en una perspectiva de seguridad, funciones en un mismo nivel. Por supuesto, algunos productos exceden el nivel y en algunas arreas la certificación será más y más severa (la certificación puede ser revocada si un producto falla al no mantenerse con el estándar).

La certificación ICSA es totalmente diferente de un análisis competitivo o examen de producto. El propósito de la certificación es no decir que un producto "A" hace o realiza mejor que el producto "B" respecto a esto o aquello. Es únicamente la ejecución relativa de pruebas lo que cuenta, como un paso binario/resultados fallidos. La realización de un producto en términos de velocidad, no es parte de la certificación.

El estándar inicial de certificación firewall depende de una definición de requerimientos mínimos aceptables para una compañía típica o una organización. Específicamente, los criterios de certificación significan que un producto firewall, que ha sido configurado de acuerdo a las instrucciones del fabricante, brinda protección contra ataques y al mismo tiempo, brinda una organización con funcionalidad operativa real.

La certificación esta diseñada para asegurar que una firewall repela importantes ataques, comunes y no comunes. ICSA utiliza una variedad de herramientas de rastreo comerciales e internas así como técnicas manuales para verificar que los ataques son combatidos efectivamente. Esto asegura que hay una fundación confiable de buenas técnicas de seguridad. La firewall debe proveer una organización con una Departamento de Sistemas de Información Septiembre 2007 – Los derechos de Autor sobre el siguiente Manual corresponde a sus Creadores Originales


funcionalidad real. Los usuarios pueden acezar al internet, pueden conectarce a sistemas internos a través de la firewall, puede una organización enviar y recibir correos a través del firewall, etc.

Las firewall certificadas por ICSA no garantizan que sean impenetrables. Un buen producto podría ser instalado inapropiadamente, permitiendo vulnerabilidades.


Servidor Proxy

Documents

Transcript of Servidor Proxy