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).
Departamento de Sistemas de Información Septiembre 2007 – Los

derechos de Autor sobre el siguiente Manual corresponde a sus
Creadores Originales
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.
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 3128
cache_mem 16 MB
cache_dir ufs /var/spool/squid 100 16 256
maximum_object_size 4096 KB
cache_access_log /var/log/squid/access.log
reference_age 1 month
refresh_pattern . 0 20% 4320
ftp_user Carles@mi-dominio.net
ftp_passive on
#Directivas para definir listas

acl password proxy_auth REQUIRED
acl redlocal src 192.168.0.0/255.255.255.0
acl adult url_regex www.sex microsoft
#Mínimas por defecto

acl all src 0.0.0.0/0.0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl SSL_ports port 443 563 --> HTTPS, SNEWS
acl Safe_ports port 80 21 443 563 --> HTTP, FTP, HTTPS, SNEWS
acl Safe_ports port 70 210 1025-65535 --> GOPHER, WAIS, Rango puertos
acl Safe_ports port 280 488 --> HTTP-MGMT, GSS-HTTP
acl CONNECT method CONNECT
#Directivas para definir reglas sobre las listas

http_access allow adult password
http_access allow redlocal
#Mínimas por defecto

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny all
#Otras directivas
no_cache deny adult
reply_body_max_size 4096 KB
cache_mgr Carles@mi-dominio.net
authenticate_program /usr/lib/squid/ncsa_auth /etc/squid/squid-passwd
#Directivas para la jerarquía de caches

icp_port 3130
cache_peer 192.168.0.84 parent 3128 3130

cache_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 80
http_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.log
Información general sobre el comportamiento de la caché
cache_store_log /var/log/squid/store.log
Muestra 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 year
reference_age 3.5 days
referense_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% 43200

refresh_pattern ^ftp: 1440 20% 10080
refresh_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 Carles@mi-dominio.net
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-passwd
2. Establecer permisos de lectura y escritura para Squid.

3. chmod 600 /etc/squid/squid-passwd
chown squid:squid /etc/squid/squid-passwd
4. 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-

passwd
6. Definir en el fichero squid.conf la lista acl correspondiente.
acl password proxy_auth REQUIRED
7. 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 posibles

acl redlocal src 192.168.0.0/24 --> Red correspondiente a 192.168.0.*
http_access allow redlocal password --> Usuarios con esas IP's autenticarse
http_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 posibles
acl redlocal src 192.168.0.0/24
acl adult url_regex www.sex.com erotic
http_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 Proxy
ProxyRequest On
Listen 80
Listen 8087
AllowCONNECT 443 563 23
ProxyBlock 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 50000
CacheGcInterval 1
CacheMaxExpire 24
CacheLastModifiedFactor 0.1
CacheDefaultExpire 3
CacheForceCompletion 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 On
ProxyRequest 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 8087
Listen 80
Listen 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 8087
2. 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.0

3. 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.edu

ProxyBlock *
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:8087

ProxyRemote * http://192.68.0.84:8087
ProxyRemote 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:8087
NoProxy .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
Indica que la respuesta a una petición puede ser ocultada
public
(cacheada) tanto por clientes como por el Proxy.
Indica que la respuesta no se puede cachear por caches
private 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.
Segundos máximos que se considera un objeto no caducado
max-age
desde que se realizó su petición.
must-
Obliga a comparar con el servidor web antes de usar el caché.
revalidate
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.
Val
Significado
or
Mostrará información como el nombre de la máquina del
On
Proxy.
Off No añade información en la cabecera Via.
Mostrará información como el nombre de la máquina y
Full
la versión del software.
Bloc
Eliminará las líneas en que aparezca la cabecera Via.
k
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.
Val
Significado
or
MIS La página no se ha servido
S desde el caché.
La página se ha servido desde
HIT
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 None
6. AllowOverride None
7. Order allow,deny
8. 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.
DIRECT
Indica al navegador que se conecte sin utilizar ningún Proxy.
PROXY host:port
Permite 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.
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 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 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

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Servidor Proxy

Transféré par

Droits d'auteur :

Formats disponibles

Hospital La Victoria – Manual Servidor Proxy y Firewall

Ventajas de un servidor Proxy

Un servidor Proxy actúa como intermediario entre el programa cliente

En cuanto a las ventajas, un servidor Proxy con caché en principio realiza

Puede controlar el acceso a Internet prohibiendo por ejemplo la entrada a

El coste del software y su instalación tienen un precio prácticamente

Desventajas de un servidor Proxy

Utilizar un servidor Proxy-Caché en principio puede parecer una gran

Debido a que el funcionamiento de un Proxy no es conocido por todos los

Un diseñador de páginas web puede indicar en el contenido de su web que

Departamento de Sistemas de Información Septiembre 2007 – Los

El hecho de acceder a Internet a través de un Proxy, en vez de mediante

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

(El RPM indicado viene con la distribución de RedHat 7-3 y es el que

Instalación mediante código fuente

Si no deseamos esperar a que salga la última versión en RPM y queremos

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

Una vez descomprimido el paquete debemos de ejecutar el siguiente script

Esta orden permite especificar el directorio donde instalaremos Squid. Una

Departamento de Sistemas de Información Septiembre 2007 – Los

Para compilar el código fuente ejecutar la orden make all y posteriormente

Ejemplo de configuración de sus directivas

En esta sección se muestra un ejemplo de las directivas más importantes

#Directivas para Proxy y caché

#Directivas para definir listas

#Mínimas por defecto

#Directivas para definir reglas sobre las listas

#Mínimas por defecto

#Directivas para la jerarquía de caches

cache_peer 192.168.0.84 parent 3128 3130

En el siguiente apartado se muestra una descripción detallada con ejemplos

Explicación de las directivas

Una vez presentadas las directivas explicaremos su utilidad y

Para el correcto funcionamiento de las directivas, se aconseja

http_port (Asignar Puerto)

Permite especificar uno o varios puertos de escucha para el servidor Squid.

La segunda línea especifica la dirección IP de la máquina donde se

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

Permite indicar la cantidad ideal de memoria RAM como máximo para

Los datos de estos objetos se almacenan en bloques de 4KB. Cache_mem

En el supuesto caso que el objeto en tránsito requiera una memoria mayor a

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

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

Permite indicar la cantidad de memoria física máxima para almacenar caché

Sus valores pueden ser: tipo directorio tamaño numero_subdir

cache_dir ufs /var/spool/squid 100 16 256

El numero 100 corresponde a 100MB como espacio máximo para almacenar

maximum_object_size (Tamaño máximo para cacheados)

Permite especificar en kilobytes el tamaño máximo de los objetos que se

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

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

reference_age (Tiempo máximo en la caché)

Permite especificar el tiempo máximo que puede permanecer un objeto en

refresh_pattern (Factor para páginas sin caducidad)

Permite especificar que fecha en minutos deben de tener los documentos

refresh_pattern -i \.gif$ 14400 70% 43200

El valor correspondiente a la expresión regular debe de contener la

El valor mín corresponde a los minutos mínimos que un objeto que no

El valor porcentaje sirve para especificar en aquellos objetos sin fecha de

ftp_user (Acceso anónimo para FTP)

Requerir autentificación por contraseña