viernes, 11 de octubre de 2013

Configuración básica de Apache

Acerca del protocolo HTTP.

HTTP (Hypertext Transfer Protocol o Protocolo de Trasferencia de Hipertexto) es el método utilizado para transferir o transportar información a través de Internet y (WWW, World Wide Web). Su propósito original fue el proveer una forma de publicar y recuperar documentos en formato HTML.
El desarrollo del protocolo fue coordinado por World Wide Web Consortium y la IETF (Internet Engineering Task Force  o Fuerza de Trabajo en Ingeniería de Internet), culminando con la publicación de varios RFC (Request For Comments), de entre los que destaca el RFC 2616, mismo que define la versión 1.1 del protocolo, que es el utilizado hoy en día.
HTTP es un protocolo de solicitud y respuesta a través de TCP, entre agentes de usuario (Navegadores, motores de índice y otras herramientas) y servidores, regularmente utilizando el puerto 80. Entre la comunicación entre éstos puede intervenir otros tipos de implementaciones, como serían servidores Intermediarios (Proxies), puertas de enlace y túneles.
URL: http://tools.ietf.org/html/rfc2616

Acerca de Apache.

Apache es un servidor HTTP de código fuente abierto y licenciamiento libre que funciona en Linux, sistemas operativos derivados de Unix™, Windows™, Novell™ Netware y otras plataformas. Ha desempeñado un papel muy importante en el crecimiento de Internet y continua siendo el servidor HTTP más utilizado, siendo además el servidor de facto contra el cual se realizan las pruebas comparativas y de desempeño para otros productos competidores. Es desarrollado y mantenido por una comunidad de desarrolladores auspiciada por Apache Software Foundation.
URL: http://www.apache.org/

Equipamiento lógico necesario.

En CentOS, Fedora™ y Red Hat™ Enterprise Linux.

Ejecute lo siguiente:
yum -y install httpd
Si se desea incluir soporte para PHP/MySQL, Perl, Python y SSL/TLS, ejecute lo siguiente:
yum -y install php php-mysql mod_perl mod_wsgi mod_ssl

Nota.
En CentOS 6, Fedora™ y Red Hat™ Enterprise Linux 6, el soporte para Python se incluye con el paquete mod_wsgi. En CentOS 5 y Red Hat™ Enterprise Linux 5, el soporte para Python se incluye con el paquete mod_python.
yum -y install mod_python
Para poder realizar pruebas desde el mismo anfitrión local, puede utilizar cualquier navegador, como serían Firefox y Google Chrome. A fin de poder prescindir del uso del modo gráfico y poder trabajar desde una terminal de texto, sugerimos instalar y utilizar el navegador Lynx.
yum -y install lynx

Iniciar servicio y añadir el servicio al arranque del sistema.

Para añadir el servicio al arranque del sistema, ejecute:
chkconfig httpd on
Para iniciar el servicio ejecute:
service httpd start
Para reiniciar el servicio interrumpiendo todas las conexiones establecidas en ese momento, ejecute:
service httpd restart
Para cargar los cambios en la configuración sin interrumpir el servicio y con ésto mantener activas las conexiones establecidas, ejecute
service httpd reload
Para detener el servicio, ejecute:
service httpd stop

SELinux y Apache.

En CentOS, Fedora™ y Red Hat™ Enterprise Linux, de modo predeterminado SELinux viene activo en modo obligatorio (enforcing). Éste añade seguridad y protección adicional a Apache. Sin embargo algunas opciones impedirán utilizar ciertas funciones en Apache, como directorios virtuales fuera del directorio /var/www, directorios ~/public_html, el envío de correo electrónico desde aplicaciones basadas sobre HTTP, etc.
Para permitir a Apache poder enviar correo electrónico desde alguna aplicación, ejecute:
setsebool -P httpd_can_sendmail 1
Para permitir que Apache pueda leer contenidos localizados en los directorios de inicio de los usuarios locales, ejecute:
setsebool -P httpd_read_user_content 1

Nota.
Estas últimas dos políticas son indispensables para el funcionamiento de cualquier cliente de correo electrónico basados sobre HTTP (Webmails).
Para permitir a Apache poder ejecutar guiones CGI, ejecute:
setsebool -P httpd_enable_cgi 1
Para permitir las inclusiones del lado del servidor (SSI, Server Side Includes), ejecute:
setsebool -P httpd_ssi_exec 1
Para permitir que Apache se pueda conectar a un base de datos localizada en otro servidor, ejecute:
setsebool -P httpd_can_network_connect_db 1
Para permitir a Apache realizar conexiones de red hacia otro servidor, ejecute:
setsebool -P httpd_can_network_connect 1
Para permitir que los usuarios locales puedan utilizar un directorio público (public_html), ejecute:
setsebool -P httpd_enable_homedirs 1

Nota.
Esta última política es indispensable para el funcionamiento de anfitriones virtuales asignados a usuarios locales, pues permite utilizar los directorios ~/public_html.
Para permitir administrar a través de FTP o FTPS cualquier directorio gestionado por Apache o bien permitir a Apache funcionar como un servidor FTP escuchando peticiones a través del puerto de FTP, ejecute el siguiente mandato:
setsebool -P httpd_enable_ftp_server 1
Para desactivar la ejecución de PHP y otros lenguajes de programación para HTTP a través de Apache, ejecute el siguiente mandato:
setsebool -P httpd_builtin_scripting 0
Para consultar todas políticas disponibles que existen para Apache, ejecute:
getsebool -a |grep httpd
Para consultar todas políticas disponibles que existen para Apache, junto con una breve descripción, ejecute:
semanage boolean -l |grep httpd
Para definir que un directorio fuera de /var/www, como por ejemplo /sitios/dominio.tld/html, pueda ser utilizado por Apache, se le debe asignar el contexto httpd_sys_content_t. Éste puede asignarse a través del mandato chcon, como se muestra en el siguiente ejemplo:
chcon -t httpd_sys_content_t /sitios/dominio.tld/html
Cualquier contenido que sea copiado o transferido dentro de /var/www automáticamente adquiere el contexto httpd_sys_content_t.
Para definir que se permite ejecutar un guión CGI en particular, como por ejemplo /sitios/dominio/cgi-bin/formulario.pl, se utiliza el siguiente mandato:
chcon -t httpd_sys_script_exec_t /sitios/dominio/cgi-bin/formulario.pl
Cualquier contenido que sea copiado o transferido dentro de cualquier sub-directorio de /var/www que se denomine cgi-bin, automáticamente adquiere el contexto httpd_sys_script_exec_t.
Para definir que, por ejemplo, /var/www/dominio/public_html/escribir.php pueda realizar procedimientos de sólo lectura de datos fuera del directorio /var/www, ejecute el siguiente mandato:
chcon -t httpd_sys_script_ro_t /var/www/dominio/public_html/leer.php
Para definir que, por ejemplo, /var/www/dominio/public_html/escribir.php pueda realizar procedimientos de lectura y escritura de datos fuera del directorio /var/www, ejecute el siguiente mandato:
chcon -t httpd_sys_script_rw_t /var/www/dominio/public_html/leer.php

Modificaciones necesarias en el muro cortafuegos.

Es necesario abrir el puerto 80 por TCP (HTTP).

Servicio iptables.

Puede utilizar iptables, ejecutando lo siguiente:
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

service iptables save
O bien edite el archivo /etc/sysconfig/iptables:
vim /etc/sysconfig/iptables
Y añada el siguiente contenido:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
Y reinicie el servicio iptables:
service iptables restart

Shorewall.

Edite el archivo /etc/shorewall/rules:
vim /etc/shorewall/rules
Las reglas corresponderían a algo similar a lo siguiente, permitiendo el acceso hacia el servicio HTTP desde cualquier zona del muro cortafuegos:
#ACTION	SOURCE	DEST	PROTO 	DEST		SOURCE
#				PORT		PORT(S)1
ACCEPT	all	fw	tcp	80
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
Para aplicar los cambios en Shorewall, ejecute lo siguiente:
service shorewall restart

Procedimientos.

Archivos de configuración.

Cualquier ajuste que se requiera realizar, ya sea para configurar anfitriones virtuales, u otra funcionalidad adicional, se puede realizar sin tocar el archivo principal de configuración (/etc/httpd/conf/httpd.conf), utilizando cualquier archivo con extensión *.conf dentro del directorio /etc/httpd/conf.d/.

UTF-8 y codificación de documentos.

UTF-8
UTF-8 es un método de codificación de ASCII para Unicode (ISO-10646), el Conjunto de Caracteres Universal o UCS. éste codifica la mayoría de los sistemas de escritura del mundo en un único conjunto de caracteres, permitiendo la mezcla de lenguajes y guiones en un mismo documento sin la necesidad de ajustes para realizar los cambios de conjuntos de caracteres.
Debido a su conveniencia actualmente se está adoptando UTF-8 como codificación para todo, sin embargo aún hay mucho material codificado en, por ejemplo, ISO-8859-1.
Lo correcto es cambiar a en UTF-8 la codificación de los documentos que están en ISO8859-1, u otras tablas de caracteres, utilizando métodos similares el siguiente:
cd /var/www/html/
for f in *.html
do
vi -c ":wq! ++enc=utf8" $f
done
Lo anterior sólo tendría sentido si dentro del directorio /var/www/html hubiera documentos HTML codificados en ISO8859-1.
Si desea continuar viviendo en el pasado y no aceptar el nuevo estándar, también puede desactivar la función en Apache que establece UTF-8 como codificación predefinida. Edite el archivo /etc/httpd/conf/httpd.conf:
vim /etc/httpd/conf/httpd.conf
Localice lo siguiente:
AddDefaultCharset UTF-8
Cambie UTF-8 por Off:
AddDefaultCharset Off

Directorios virtuales.

Si, por ejemplo, se quisiera añadir el alias para un directorio localizado en /var/contenidos/ejemplo/ y el cual queremos visualizar como el directorio /ejemplo/ en Apache, lo primero será crear el directorio:
mkdir -p /var/contenidos/ejemplo
Cambie los contextos de SELinux de este directorio, con la finalidad de que tenga rol de objeto (object_r), creado por usuario de sistema (system_u) y tipo httpd_sys_content_t:
chcon -u system_u /var/contenidos/ejemplo
chcon -r object_r /var/contenidos/ejemplo
chcon -t httpd_sys_content_t /var/contenidos/ejemplo
Genere el archivo /etc/httpd/conf.d/ejemplos.conf:
vim /etc/httpd/conf.d/ejemplos.conf
Añada el siguiente contenido:
Alias  /ejemplo  /var/contenidos/ejemplo
Guarde y cierre el archivo.
Recargue el servicio httpd.
service httpd reload
Asumiendo que realizará la prueba desde el mismo anfitrión local, visualice este nuevo directorio virtual, con cualquier navegador, a través de http://127.0.0.1/ejemplo/. Se mostrará que el directorio existe, pero el acceso a éste está denegado.
Si desea realizar las comprobaciones desde el mismo anfitrión, puede utilizar el navegador Lynx.
lynx http://127.0.0.1/ejemplo/
Lo anterior deberá mostrar un error 403 (acceso denegado), pues el directorio carece de un archivo índice. Para poder acceder deberá haber un documento índice en el interior (index.html, index.php, etc) o bien que dicho directorio sea configurado para mostrar el contenido.
Edite de nuevo el archivo /etc/httpd/conf.d/ejemplos.conf:
vim /etc/httpd/conf.d/ejemplos.conf
Modifique el contenido para que quede del siguiente modo:
Alias /ejemplo /var/contenidos/ejemplo
	<Directory "/var/contenidos/ejemplo">
		Options Indexes
	</Directory>
La opción Indexes indica que se deberá mostrar el índice de contenido del directorio.
Recargue el servicio httpd para aplicar la configuración:
service httpd reload
Asumiendo que realizará la prueba desde el mismo anfitrión local, acceda hacia http://127.0.0.1/ejemplo/ con cualquier navegador y visualice el resultado.
Si se requiere que este directorio tenga aún mayor funcionalidad, se pueden añadir más opciones, como por ejemplo AllowOverride, Includes y FollowSymLinks, como se muestra en el siguiente ejemplo:
Alias /ejemplo /var/contenidos/ejemplo
	<Directory "/var/contenidos/ejemplo">
		Options Indexes Includes FollowSymLinks
		AllowOverride all
	</Directory>
En el ejemplo anterior:
  • La opción FollowSymLinks habilita el uso de enlaces simbólicos dentro del directorio. Sólo utilice ésta si necesita acceder a contenidos fuera del directorio a utilizar.
  • La opción Includes especifica que se permite la utilización de los SSI (Server Side Includes). Sólo utilice ésta si así lo requiere la aplicación o programa utilizado dentro este directorio.
  • La opción AllowOverride, con el valor all posibilita utilizar archivos .htaccess, los cuales a su vez permiten aplicar opciones de directorio al vuelo, sin necesidad de modificar otros archivos de configuración.
Para que surtan efecto los cambios hechos a la configuración, recargue el servicio httpd:
service httpd reload
Asumiendo que realizará la prueba desde el mismo anfitrión local, acceda hacia http://127.0.0.1/ejemplo/ con cualquier navegador y visualice el resultado.
Si desea realizar las comprobaciones desde el mismo anfitrión, puede utilizar el navegador Lynx.
lynx http://127.0.0.1/ejemplo/

Limitar el acceso a directorios por dirección IP.

Si se requiere limitar el acceso de un directorio en particular, para que éste esté disponible sólo hacia ciertas direcciones IP o bloques de red, defina algo como lo mostrado en el siguiente ejemplo:
Alias /ejemplo /var/contenidos/ejemplo
	<Directory "/var/contenidos/ejemplo">
		Order deny,allow
		Deny from all
		Allow from 127.0.0.0/8 192.168.70.0/25
		Options Indexes
		AllowOverride all
	</Directory>
El ejemplo anterior establece que el orden de acceso, donde primero se aplicarán las reglas de denegación y luego las que permitirán el acceso y que se denegará el acceso a todo el mundo, permitiendo el acceso sólo desde 127.0.0.0/8 y 192.168.70.0/25.
Para que surtan efecto los cambios hechos a la configuración, recargue el servicio httpd:
service httpd reload
sumiendo que realizará la prueba desde el mismo anfitrión local, acceda hacia http://127.0.0.1/ejemplo/ con cualquier navegador y visualice el resultado.
Si desea realizar las comprobaciones desde el mismo anfitrión, puede utilizar el navegador Lynx.
lynx http://127.0.0.1/ejemplo/

Limitar el acceso por usuario y contraseña.

La autenticación para directorios, contra un archivo que incluya nombres de usuario y claves de acceso, que también puede combinarse con el acceso por dirección IP, se realiza a través de la siguiente sintaxis:
AuthName "Acceso sólo para usuarios autorizados"
AuthType Basic
Require valid-user
AuthUserFile /cualquier/ruta/hacia/archivo/de/claves
Lo anterior puede ser incluido en la configuración existente para cualquier directorio o bien en archivo .htaccess.
Genere el directorio /var/www/privado/ ejecutando lo siguiente:
mkdir -p /var/www/privado
Genere un archivo denominado arbitrariamente /etc/httpd/conf.d/ejemplo-autenticar.conf:
vim /etc/httpd/conf.d/ejemplo-autenticar.conf
Añada con el siguiente contenido:
Alias /privado /var/www/privado
<Directory "/var/www/privado">
	Options Indexes
	AllowOverride All
	Order allow,deny
	Allow from all
</Directory>
Para que surtan efecto los cambios hechos a la configuración, recargue el servicio httpd:
service httpd reload
Genere el archivo /var/www/privado/.htaccess.
vim /var/www/privado/.htaccess
Agregue el siguiente contenido:
AuthName "Sólo usuarios autorizados"
AuthType Basic
Require valid-user
AuthUserFile /var/www/claves
Genere el archivo de claves de acceso como /var/www/claves, ejecutando el siguiente procedimiento:
touch /var/www/claves
Cambie los permisos de sólo lectura y escritura para usuario y cambie la propiedad al usuario y grupo apache:
chmod 600 /var/www/claves
chown apache:apache /var/www/claves
Agregue algunos usuarios virtuales al archivo de claves, /var/www/claves, ejecutando el mandato htpasswd, usando como argumentos la ruta del archivo de claves de acceso y nombre del usuario a añadir o modificar:
htpasswd /var/www/claves fulano
htpasswd /var/www/claves mengano
htpasswd /var/www/claves perengano
htpasswd /var/www/claves zutano
Asumiendo que realizará la prueba desde el mismo anfitrión local, acceda con cualquier navegador hacia http://127.0.0.1/privado/ y compruebe que funciona el acceso con autenticación, utilizando cualquiera de los dos usuarios virtuales que generó con el mandato htpasswd, es decir fulano o mengano.
Si desea realizar las comprobaciones desde el mismo anfitrión, puede utilizar el navegador Lynx.
lynx http://127.0.0.1/privado/

Asignación de directivas para PHP.

Suelen darse los casos donde una aplicación, escrita en PHP, requiere algunas directivas de PHP en particular. En muchos casos se llegan a necesitar variables que pueden comprometer la seguridad de otras aplicaciones hospedadas en el servidor. Para tal fin es que se puede evitar modificar el archivo /etc/php.ini utilizando el parámetro php_flag en un archivo .htaccess. La siguiente sintaxis es la siguiente:
php_flag directiva_php valor

Ejemplo

Se procederá a asignar las directivas register_globals, magic_quotes_runtime, magic_quotes_gpc y upload_max_filesize al directorio en la ruta /var/www/aplicacion, mismo que será visualizado desde Apache como http://127.0.0.1/aplicacion/. El valor para register_globals será On (requerido sólo por aplicaciones PHP muy antiguas o muy mal escritas), el valor para magic_quotes_runtime será On, el valor para magic_quotes_gpc será On y el valor para upload_max_filesize será 8M.
Genere el directorio /var/www/aplicacion ejecutando lo siguiente:
mkdir /var/www/aplicacion
Genere el archivo /etc/httpd/conf.d/ejemplo-directivas-php.conf ejecutando lo siguiente:
vim /etc/httpd/conf.d/ejemplo-directivas-php.conf
Añada el siguiente contenido:
Alias /aplicacion /var/www/aplicacion
<Directory "/var/www/aplicacion">
	AllowOverride All
</Directory>
Genere el archivo /var/www/aplicacion/.htaccess realizando lo siguiente:
touch /var/www/aplicacion/.htaccess
Edite el archivo /var/www/aplicacion/.htaccess y agregue el siguiente contenido:
php_flag register_globals On
php_flag magic_quotes_gpc On
php_flag magic_quotes_runtime On
php_value upload_max_filesize 8M
Genere el archivo /var/www/aplicacion/info.php, una función que muestra toda la información acerca de PHP en el servidor, a fin de corroborar los valores de las directivas de PHP en relación al directorio, con el siguiente contenido:
<?php
     phpinfo();
?>
Para que surtan efecto los cambios hechos a la configuración, recargue el servicio httpd:
service httpd reload
Acceda con cualquier navegador de red hacia http://127.0.0.1/aplicacion/info.php.
Si desea realizar las comprobaciones desde el mismo anfitrión, puede utilizar el navegador Lynx.
lynx http://127.0.0.1/aplicacion/info.php
Corrobore que los valores para las variables de PHP para el directorio involucrado realmente han sido asignadas. En la sub-sección PHP Core de la sección Configuration, hay tres columnas. La primera, Directive, corresponde a la directivas PHP. La segunda, Local Value, corresponde a los valores de las directivas de PHP para el directorio actual. La tercera, Master Value, corresponde a los valores de las directivas predeterminadas que están definidas en el archivo /etc/php.ini.
DirectiveLocal ValueMaster Value
magic_quotes_gpc On Off
magic_quotes_runtime On Off
register_globals On Off
upload_max_filesize 8M 2M

Re-dirección de directorios.

Cuando sea necesario, es posible configurar un directorio en particular para Apache redirija éste de modo transparente hacia cualquier otra dirección.
Genere el archivo denominado arbitrariamente como /etc/httpd/conf.d/ejemplo-redireccion.conf, reemplazando http://mail.docminio.tld/ por cualquier dirección válida.
vim /etc/httpd/conf.d/ejemplo-redireccion.conf
Añada el siguiente contenido:
Redirect 301 /webmail http://mail.dominio.tld/
Guarde el archivo y regrese al intérprete de mandatos.
Para que surtan efecto los cambios hechos a la configuración, recargue el servicio httpd:
service httpd reload
En el ejemplo anterior, se indica que si se trata de acceder hacia el sub-directorio /webmail en el servidor, Apache deberá redirigir hacia http://mail.dominio.tld/. El número 301 corresponde al mensaje del protocolo HTTP para indicar que la re-dirección es permanente. Si por ejemplo hubiese un objeto en /webmail, como por ejemplo /webmail/estadisticas/estadisticas.php, Apache realizaría el re-direccionamiento transparente hacia http://mail.dominio.tld/estadisticas/estadisticas.php.

Tipos de MIME.

Para añadir cualquier tipo de extensión y tipo MIME, como por ejemplo Ogg, definiendo además una descripción e icono, genere un archivo que denominado /etc/httpd/conf.d/mimes.conf:
vim /etc/httpd/conf.d/mimes.conf
Añada el siguiente contenido:
AddType application/ogg .ogg
AddDescription "Ogg Vorbis Audio" .ogg
AddIcon /icons/sound2.png .ogg
Para que surtan efecto los cambios hechos a la configuración, recargue el servicio httpd:
service httpd reload
Copie o transfiera cualquier archivo de audio Ogg Vorbis a cualquier directorio compartido a través de Apache que permita ver el índice de éste y visualice el resultado.

Impedir enlace remoto de imágenes.

Suele ocurrir que los administradores de algunos sitios encuentran fácil utilizar imágenes y otros tipos de contenido, vinculando desde sus documentos hacia los objetos en el servidor. Ésto representa un consumo ancho de banda adicional para el servidor, que sólo genera tráfico inútil y por lo tanto es considerado una práctica poco ética. En el siguiente ejemplo se desea proteger un directorio para que sólo se permita utilizar su contenido si es referido desde el mismo servidor.

Genere el directivo /var/www/imagenes ejecutando lo siguiente:
mkdir /var/www/imagenes
Copie o transfiera archivos de imágenes dentro de este directorio.
cp /usr/share/pixmaps/*.png /var/www/imagenes
Genere el archivo /etc/httpd/conf.d/imagenes.conf ejecutando lo siguiente:
vim /etc/httpd/conf.d/imagenes.conf
Añada el siguiente contenido:
# Se permite acceder directamente a la imagen o bien si se omite
# en el navegador la información del referente.
SetEnvIfNoCase Referer "^$" local_referal=1
# Se permite al propio servidor
SetEnvIfNoCase Referer "^http://127.0.0.1" local_referal=1
SetEnvIfNoCase Referer "^http://localhost" local_referal=1
SetEnvIfNoCase Referer "^http://localhost.localdomain" local_referal=1
SetEnvIfNoCase Referer "^http://192.168.70.50" local_referal=1
SetEnvIfNoCase Referer "^http://m50.alcancelibre.org.mx" local_referal=1
SetEnvIfNoCase Referer "^http://(www.)?midominio.org" local_referal=1
# Se permite utilizar las imágenes a otro servidor
SetEnvIfNoCase Referer "^http://(www.)?sitio-amigo.org" local_referal=1

Alias /imagenes /var/www/imagenes
<Directory  "/var/www/imagenes">
	Order Deny,Allow
	Deny from all
	Allow from env=local_referal
</Directory>
Para que surtan efecto los cambios hechos a la configuración, recargue el servicio httpd:
service httpd reload
Pruebe la configuración creando un documento HTML en el anfitrión local y en un anfitrión remoto, el cual enlace hacia imágenes hospedadas en el directorio /var/www/imagenes del servidor recién configurado, y compare resultados.
En lugar de lo anterior, puede utilizarse también un archivo .htaccess. Edite el archivo /etc/httpd/conf.d/imagenes.conf ejecutando lo siguiente:
vim /etc/httpd/conf.d/imagenes.conf
Reemplace el contenido existente por lo siguiente:
Alias /imagenes /var/www/imagenes
<Directory  "/var/www/imagenes">
	AllowOverride all
</Directory>
Para que surtan efecto los cambios hechos a la configuración, recargue el servicio httpd:
service httpd reload
Genere el archivo /var/www/imagenes/.htaccess:
vim /var/www/imagenes/.htaccess
Añada el siguiente contenido:
# Se permite acceder directamente a la imagen o bien si se omite
# en el navegador la información del referente.
SetEnvIfNoCase Referer "^$" local_referal=1
# Se permite al propio servidor
SetEnvIfNoCase Referer "^http://127.0.0.1" local_referal=1
SetEnvIfNoCase Referer "^http://localhost" local_referal=1
SetEnvIfNoCase Referer "^http://localhost.localdomain" local_referal=1
SetEnvIfNoCase Referer "^http://192.168.70.50" local_referal=1
SetEnvIfNoCase Referer "^http://m50.alcancelibre.org.mx" local_referal=1
SetEnvIfNoCase Referer "^http://(www.)?midominio.org" local_referal=1
# Se permite utilizar las imágenes a otro servidor
SetEnvIfNoCase Referer "^http://(www.)?sitio-amigo.com" local_referal=1

Order Deny,Allow
Deny from all
Allow from env=local_referal
Pruebe la configuración creando un documento HTML en el anfitrión local y en un anfitrión remoto, el cual enlace hacia imágenes hospedadas en el directorio /var/www/imagenes del servidor recién configurado, y compare resultados.

Fuente: http://www.alcancelibre.org/staticpages/index.php/como-apache?query=servidor+http

Configuración de Squid

¿Qué es Servidor Intermediario (Proxy)?

El término en ingles «Proxy» tiene un significado muy general y al mismo tiempo ambiguo, aunque invariablemente se considera un sinónimo del concepto de «Intermediario». Se suele traducir, en el sentido estricto, como delegado o apoderado (el que tiene poder sobre otro).
Un Servidor Intermediario se define como una computadora o dispositivo que ofrece un servicio de red que consiste en permitir a los clientes realizar conexiones de red indirectas hacia otros servicios de red. Durante el proceso ocurre lo siguiente:
  1. Cliente se conecta hacia un Servidor Proxy.
  2. Cliente solicita una conexión, archivo u otro recurso disponible en un servidor distinto.
  3. Servidor Intermediario proporciona el recurso ya sea conectándose hacia el servidor especificado o sirviendo éste desde un caché.
  4. En algunos casos el Servidor Intermediario puede alterar la solicitud del cliente o bien la respuesta del servidor para diversos propósitos.
Los Servidores Proxy generalmente se hacen trabajar simultáneamente como muro cortafuegos operando en el Nivel de Red, actuando como filtro de paquetes, como en el caso de iptables o bien operando en el Nivel de Aplicación, controlando diversos servicios, como es el caso de TCP Wrapper. Dependiendo del contexto, el muro cortafuegos también se conoce como BPD o Border Protection Device o simplemente filtro de paquetes.
Una aplicación común de los Servidores Proxy es funcionar como caché de contenido de Red (principalmente HTTP), proporcionando en la proximidad de los clientes un caché de páginas y archivos disponibles a través de la Red en servidores HTTP remotos, permitiendo a los clientes de la red local acceder hacia éstos de forma más rápida y confiable.
Cuando se recibe una petición para un recurso de Red especificado en un URL (Uniform Resource Locator) el Servidor Intermediario busca el resultado del URL dentro del caché. Si éste es encontrado, el Servidor Intermediario responde al cliente proporcionado inmediatamente el contenido solicitado. Si el contenido solicitado estuviera ausente en el caché, el Servidor Intermediario lo traerá desde servidor remoto, entregándolo al cliente que lo solicitó y guardando una copia en el caché. El contenido en el caché es eliminado luego a través de un algoritmo de expiración de acuerdo a la antigüedad, tamaño e historial de respuestas a solicitudes (hits) (ejemplos: LRU, LFUDA y GDSF).
Los Servidores Proxy para contenido de Red (Web Proxies) también pueden actuar como filtros del contenido servido, aplicando políticas de censura de acuerdo a criterios arbitrarios.

Acerca de Squid.

Squid es un Servidor Intermediario de alto desempeño que se ha venido desarrollando desde hace varios años y es hoy en día un muy popular y ampliamente utilizado entre los sistemas operativos como GNU/Linux y derivados de Unix®. Es muy confiable, robusto y versátil y se distribuye bajo los términos de la Licencia Pública General GNU (GNU/GPL). Siendo equipamiento lógico libre, está disponible el código fuente para quien así lo requiera.
Entre otras cosas, Squid puede funcionar como Servidor Intermediario y caché de contenido de Red para los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, caché transparente, WWCP, aceleración HTTP, caché de consultas DNS y otras muchas más como filtración de contenido y control de acceso por IP y por usuario.
Squid consiste de un programa principal como servidor, un programa para búsqueda en servidores DNS, programas opcionales para reescribir solicitudes y realizar autenticación y algunas herramientas para administración y herramientas para clientes. Al iniciar Squid da origen a un número configurable (5, de modo predeterminado a través dla opción dns_children) de procesos de búsqueda en servidores DNS, cada uno de los cuales realiza una búsqueda única en servidores DNS, reduciendo la cantidad de tiempo de espera para las búsquedas en servidores DNS.
Nota.
Squid carece de soporte para ser utilizado como Servidor Proxy para protocolos como SMTP, POP3, TELNET, SSH, IRC, etc. Si se requiere intermediar para cualquier protocolo distinto a HTTP, HTTPS, FTP, GOPHER y WAIS se requerirá implementar obligatoriamente un enmascaramiento de IP o NAT (Network Address Translation) o bien hacer uso de un servidor SOCKS como Dante (http://www.inet.no/dante/).
URL: http://www.squid-cache.org/

Equipamiento lógico necesario.

Para poder llevar al cabo los procedimientos descritos en este y otros documentos relacionados, se requiere instalar al menos lo siguiente:
  • Al menos squid-2.5.STABLE6
  • Todos los parches de seguridad disponibles para la versión del sistema operativo que esté utilizando.
  • Un muro cortafuegos configurado con system-config-firewall, Firestarter o Shorewall.
Squid sólo se instala de manera predeterminada cuando se instala el grupo de paquetes denominado «Servidor Web». El procedimiento de instalación es exactamente el mismo que con cualquier otro equipamiento lógico.

Instalación a través de yum.

Si se utiliza CentOS o Red Hat™ Enterprise Linux, ejecute:
yum -y install squid

SELinux y el servicio squid.

En CentOS 6 y Red Hat™ Enterprise Linux 6, la política squid_connect_any viene habilitada de modo predeterminado. En CentOS 5 y Red Hat™ Enterprise Linux 5, esta política viene deshabilitada de modo predeterminado. Esta política hace que SELinux permita a Squid aceptar conexiones de los clientes desde cualquier dirección IP. Si utiliza CentOS 5 y Red Hat™ Enterprise Linux 5, ejecute:
setsebool -P squid_connect_any 1
Para SELinux permita a Squid operar en modo transparente en CentOS 6 y Red Hat™ Enterprise Linux 6, ejecute:
setsebool -P squid_use_tproxy 1

Nota.
En CentOS 5 y Red Hat™ Enterprise Linux 5, se pude utilizar una política adicional. Para que SELinux permita al servicio squid funcionar normalmente, haciendo que todo lo anteriormente descrito en esta sección pierda sentido, ejecute:
setsebool -P squid_disable_trans 1

Antes de continuar.

Evite dejar espacios vacíos en lugares indebidos. El siguiente ejemplo muestra la manera incorrecta de habilitar un opción.
Mal
# Opción incorrectamente habilitada.
  http_port 8080
El siguiente ejemplo muestra la manera correcta de habilitar un opción.
Bien
# Opción correctamente habilitada.
http_port 8080

Configuración básica.

Squid utiliza el archivo de configuración localizado en /etc/squid/squid.conf y podrá trabajar sobre este utilizando su editor de texto simple preferido. Existen un gran número de opciones, de los cuales recomendamos configurar los siguientes:
  • Al menos una Lista de Control de Acceso
  • Al menos una Regla de Control de Acceso
  • http_port
  • cache_dir
  • error_directory, sólo si va a personalizar mensajes de error.
El resto de los opciones mencionados en este documento son, valga la redundancia, opcionales.
Edite el archivo /etc/squid/squid.conf:
vi /etc/squid/squid.conf

Controles de acceso.

Parapoder controlar el tráfico de los clientes hacia Internet, es necesario establecer Listas de Control de Acceso que definan una red o bien ciertos anfitriones en particular. A cada lista se le asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid.

Listas de control de acceso.

De modo predeterminado en CentOS 6 y Red Hat™ Enterprise Linux 6, Squid habilita el acceso a todas las redes locales, definidas en el RFC1918. Es decir, permite el acceso a 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7 y fe80::/10.
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7   # RFC 4193 local private network range
acl localnet src fe80::/10  # RFC 4291 link-local (directly plugged) machines
Deshabilite todo lo anterior, colocando una almoadilla (# al inicio de cada línea.
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
# acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
# acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
# acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
# acl localnet src fc00::/7   # RFC 4193 local private network range
# acl localnet src fe80::/10  # RFC 4291 link-local (directly plugged) machines
Regularmente una lista de control de acceso se establece con la siguiente sintaxis:
acl [nombre de la lista] src [lo que compone a la lista]
Si se desea establecer una lista de control de acceso que abarque a toda la red local, basta definir la IP correspondiente a la red y la máscara de la sub-red. Por ejemplo, si se tiene una red donde los anfitriones tienen direcciones del segmento IP 172.16.100.0/28, se puede utilizar lo siguiente:
acl localnet src 172.16.100.0/28
También puede definirse una Lista de Control de Acceso especificando un archivo localizado en cualquier parte del disco duro y la cual contiene una lista de direcciones IP. Ejemplo:
acl permitidos src "/etc/squid/listas/permitidos"
El archivo /etc/squid/listas/permitidos tendría un contenido similar al siguiente:
172.16.100.1
172.16.100.2
172.16.100.3
172.16.100.15
172.16.100.16
172.16.100.20
172.16.100.40
Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las direcciones IP incluidas en el archivo /etc/squid/listas/permitidos.

Reglas de Control de Acceso.

Estas definen si se permite o deniega acceso hacia Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda:
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
La sintaxis básica de una regla de control de acceso es la siguiente:
http_access [deny o allow] [lista de control de acceso]
Para desactivar la configuración predeterminada y poder utilizar una diferente, localice La línea que incluye http_access allow localnet:
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost
Deshabilite esta línea colocando una almohadilla (# al inicio de ésta:
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
# http_access allow localnet
http_access allow localhost
En el siguiente ejemplo se considera una regla que establece acceso permitido a Squid a la Lista de Control de Acceso denominada permitidos:
http_access allow permitidos
También pueden definirse reglas valiéndose de la expresión !, la cual significa no. Pueden definirse, por ejemplo, dos listas de control de acceso, una denominada lista1 y otra denominada lista2, en la misma regla de control de acceso, en donde se asigna una expresión a una de estas. La siguiente establece que se permite el acceso a Squid a lo que comprenda lista1 excepto aquello que comprenda lista2:
http_access allow lista1 !lista2
Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso y otro grupo dentro de la misma red al que se debe denegar el acceso.

Aplicando Listas y Reglas de control de acceso.

Una vez comprendido el funcionamiento de la Listas y las Regla de Control de Acceso, se procede a determinar cuales utilizar para la configuración.

Caso 1.

Considerando como ejemplo que se dispone de una red 172.16.100.0/28, si se desea definir toda la red local, se utilizaría la siguiente línea en la sección de Listas de Control de Acceso:
acl localnet src 172.16.100.0/28
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:
Listas de Control de Acceso: definición de una red local completa
#
# Recommended minimum configuration:
acl all src 0.0.0.0/0
acl manager proto cache_object
acl localhost src 127.0.0.1/8
acl localnet src 172.16.100.0/28
A continuación se procede a aplicar la regla de control de acceso:
http_access allow localnet
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar de modo similar al siguiente:
Reglas de control de acceso: Acceso a una Lista de Control de Acceso.
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
http_access allow localhost
http_access allow localnet
http_access deny all
La regla http_access allow localnet permite el acceso a Squid a la Lista de Control de Acceso denominada localnet, la cual, en el siguiente ejemplo, está conformada por 172.16.100.0/28. Esto significa que cualquier anfitrión desde 172.16.100.1 hasta 172.16.100.14 podrá acceder a Squid.

Caso 2.

Si sólo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un archivo que contenga dicha lista. Genere el archivo /etc/squid/listas/localnet, dentro del cual se incluirán sólo aquellas direcciones IP que desea confirmen la Lista de Control de acceso. Ejemplo:
172.16.100.1
172.16.100.2
172.16.100.3
172.16.100.4
172.16.100.5
172.16.100.6
172.16.100.7
Denominaremos a esta lista de control de acceso como localnet:
acl localnet src "/etc/squid/listas/localnet"
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:
Listas de Control de Acceso: definición de una red local completa
#
# Recommended minimum configuration:
acl all src 0.0.0.0/0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl localnet src "/etc/squid/listas/localnet"
A continuación se procede a aplicar la regla de control de acceso:
http_access allow localnet
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar de modo similar al siguiente:
Reglas de control de acceso: Acceso a una Lista de Control de Acceso.
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
http_access allow localhost
http_access allow localnet
http_access deny all
La regla http_access allow localnet permite el acceso a Squid a la Lista de Control de Acceso denominada localnet, la cual está conformada por las direcciones IP especificadas en el archivo /etc/squid/listas/localnet. Esto significa que cualquier anfitrión excluido del archivo /etc/squid/listas/localnet se le denegará el acceso a Squid.

Opción cache_mgr.

Esta opción es de carácter informativo. De modo predeterminado, si algo ocurre con el caché, como por ejemplo que muera el procesos, se enviará un mensaje de aviso a la cuenta webmaster del servidor. Puede especificarse una distinta si acaso se considera conveniente.
cache_mgr joseperez@midominio.net

Opción http_port.

Esta opción es utilizado para indicar el puerto a través del cual escuchará peticiones Squid. EL valor predeterminado es 3128, es deicr, Squid escuchará peticiones a través del puerto 3128/tcp.
http_port 3128
El puerto estándar designado para servidores de caché de Internet (webcache) es el puerto 8080.
http_port 8080
La opción permite establecer también si se quiere utilizar una dirección IP en particular. Esto añade mayor seguridad al servicio, pues si se tiene dos tarjetas de red, una con una dirección IP pública y otra con una dirección IP privada, se puede establecer que Squid solo permita conexiones desde la dirección IP privada.
http_port 192.168.80.1:8080
Si se necesita configurar un servidor proxy en modo transparente, solo es necesario añadir la opción intercept, misma que desde la versión 3.1 de Squid reemplaza a la opción transparent.
http_port 192.168.80.1:8080 intercept

Nota.
Para configurar un servidor proxy en modo transparente en CentOS 5 y Red Hat EnterpriseLinux 5 y versiones anteriores, utilice la opción transparent:
http_port 192.168.80.1:8080 transparent

Opción cache_dir.

Esta opción se utiliza para establecer que tamaño se desea que utilice Squid para almacenamiento de caché en el disco duro. De modo predeterminado Squid utilizará el formato ufs para crear en el directorio /var/spool/squid un caché de 100 MB, dividido en jerarquías de 16 directorios subordinados, hasta 256 niveles cada uno:
cache_dir ufs /var/spool/squid 100 16 256
Se puede incrementar el tamaño del caché hasta donde lo desee el administrador. Mientras más grande sea el caché, más objetos se almacenarán en éste y por lo tanto se consumirá menos el ancho de banda. La siguiente línea establece un caché de 2 GB:
cache_dir ufs /var/spool/squid 2048 16 256
El formato de cache ufs puede llegar a bloquear el proceso principal de Squid en operaciones de entrada/salida sobre el sistema de archivos cuando hay muchos clientes conectados. Para evitar que esto ocurra, se recomienda utilizar aufs, que utiliza el mismo formato de ufs, pero funciona de manera asincrónica, consiguiéndose un mejor desempeño.
cache_dir aufs /var/spool/squid 2048 16 256

Opción maximum_object_size.

Esta opción se utiliza para definir el tamaño máximo de los objetos en el caché. Se recomienda establecerla en escenarios con alta carga de trabajo, puesto que permite evitar desperdiciar recursos de sistema almacenando en el caché objetos de gran tamaño que probablemente sólo sean aprovechados por unos pocos usuarios, optimizando el uso del caché con objetos pequeños que de otro modo generarían una gran cantidad de peticiones hacia las redes públicas. En el siguiente ejemplo se establece un límite de 48 MB para los objetos del caché.
maximum_object_size 48 MB

Opciones cache_swap_low y cache_swap_high.

Es posible realizar una limpieza automática del caché de Squid cuando éste llegue a cierta capacidad. La opción cache_swap_low establece el porcentaje a partir del cual se comenzará a limpiar el cache. La opción cache_swap_high establece el porcentaje a partir del cual se comenzará a limpiar de manera agresiva el cache. En el siguiente ejemplo se establece que el cache se comienza a limpiar cuando alcanza el 90% y se comienza a limpiar de manera agresiva cuando alcanza el 95%.
cache_swap_low 90
cache_swap_high 95
Lo anterior permite tener un caché saludable que se limpia automáticamente. Se recomienda utilizar estas opciones en escenarios con alta carga de trabajo.

Opción cache_replacement_policy.

A través de esta opción se incluye soporte para los siguientes algoritmos para el caché:
LRU Acrónimo de Least Recently Used, que traduce como Menos Recientemente Utilizado. En este algoritmo los objetos que fueron accedidos hace mucho tiempo, son eliminados primero y manteniendo siempre en el caché a los objetos más recientemente solicitados. Ésta política es la utilizada por Squid de modo predeterminado.
LFUDA Acrónimo de Least Frequently Used with Dynamic Aging, que se traduce como Menos Frecuentemente Utilizado con Envejecimiento Dinámico. En este algoritmo los objetos más solicitados permanecen en el caché sin importar su tamaño optimizando la eficiencia (hit rate) por octetos (Bytes) a expensas de la eficiencia misma, de modo que un objeto grande que se solicite con mayor frecuencia impedirá que se pueda hacer caché de objetos pequeños que se soliciten con menor frecuencia.
GDSF Acrónimo de GreedyDual Size Frequency, que se traduce como Frecuencia de tamaño GreedyDual (codicioso dual), que es el algoritmo sobre el cual se basa GDSF. Optimiza la eficiencia (hit rate) por objeto manteniendo en el caché los objetos pequeños más frecuentemente solicitados de modo que hay mejores posibilidades de lograr respuesta a una solicitud (hit). Tiene una eficiencia por octetos (Bytes) menor que el algoritmo LFUDA debido a que descarta del caché objetos grandes que sean solicitado con frecuencia.
El algoritmo recomendado y que ha demostrado mejor desempeño en escenarios de alta carga de trabajo es LFUDA.
cache_replacement_policy heap LFUDA

Opción cache_mem.

La opción cache_mem establece la cantidad ideal de memoria para lo siguiente:
  • Objetos en tránsito.
  • Objetos frecuentemente utilizados (Hot).
  • Objetos negativamente almacenados en el caché.
Los datos de estos objetos se almacenan en bloques de 4 Kb. La opción cache_mem especifica un límite máximo en el tamaño total de bloques acomodados, donde los objetos en tránsito tienen mayor prioridad. Sin embargo los objetos frecuentemente utilizados (Hot) y aquellos negativamente almacenados en el caché, podrán utilizar la memoria sin utilizar hasta que esta sea requerida. De ser necesario, si un objeto en tránsito es mayor a la cantidad de memoria especificada, Squid excederá lo que sea necesario para satisfacer la petición.
De modo predeterminado, desde la versión 3.1 de Squid, se establecen 256 MB, que es más que suficiente para las necesidades de redes de área local con pocos anfitriones. Puede especificar una cantidad menor para obtener un mejor rendimiento, pues conviene utilizar la memoria disponible para hacer cache en memoria de muchos objetos pequeños que son frecuentemente visitados, que hacer cache de unos pocos objetos grandes que sólo unos pocos usuarios aprovecharán. En el siguiente ejemplo se establecen 48 MB como límite de tamaño para los objetos en tránsito:
cache_mem 48 MB

Nota.
En CentOS 5 y Red Hat EnterpriseLinux 5 y versiones anteriores, el valor predeterminado de cache_mem son 8 MB, por lo cual puede incrementar este valor hasta donde se considere pertinente.
cache_mem 32 MB

Estableciendo el idioma de los mensajes mostrados por Squid hacia el usuario.

Squid incluye traducción a distintos idiomas de las distintas páginas de error e informativas que son desplegadas en un momento dado durante su operación. Dichas traducciones se pueden encontrar en /usr/share/squid/errors/. Desde la versión 3.0 de Squid, el idioma se detecta automáticamente a partir del navegador utilizado por el usuario. Es innecesario modificar opción alguno, salvo que se haya personalizado los mensajes, en cuyo caso conviene utilizar una ruta distinta a la del idioma utilizado para evitar se sobre-escriban los archivos después de actualizar el sistema.
Nota.
En CentOS 5 y Red Hat™ Enterprise Linux 5 y versiones anteriores, el idioma de los mensajes de error se establece a través dla opción error_directory, cuyo valor predeterminado es /usr/share/squid/errors/English y puede ser cambiado por el valor /usr/share/squid/errors/Spanish:
error_directory /usr/share/squid/errors/Spanish

Iniciando, reiniciando y añadiendo el servicio al arranque del sistema.

Una vez terminada la configuración, para iniciar por primera vez Squid ejecute:
service squid start
Si necesita volver a cargar la configuración para probar cambios realizados, sin detener el servicio, ejecute:
service squid reload
Si necesita reiniciar para probar cambios hechos en la configuración, considerando que este proceso puede llegar a demorar algunos minutos, ejecute:
service squid restart
Para que Squid inicie de manera automática junto con el sistema, ejecute:
chkconfig squid on
Lo anterior habilitará el servicio squid en todos los niveles de ejecución.

Depuración de errores

Cualquier error al inicio de Squid sólo significa que hubo errores de sintaxis, errores de dedo o bien se están citando incorrectamente las rutas hacia los archivos de las Listas de Control de Acceso.
Puede realizar diagnóstico de problemas indicándole a Squid que vuelva a leer configuración, lo cual devolverá los errores que existan en el archivo /etc/squid/squid.conf.
service squid reload
Cuando se trata de errores graves que impiden iniciar el servicio, puede examinarse el contenido del archivo /var/log/squid/squid.out con el mandato less, more o cualquier otro visor de texto:
tail -80 /var/log/squid/squid.out

Modificaciones necesarias en el muro cortafuegos.

Si se utiliza un cortafuegos con políticas estrictas, como por ejemplo Shorewall, es necesario abrir el puerto 8080 por TCP (webcache), si se eligió utilizar el puerto 8080 en lugar del 3128.
La regla para el archivo /etc/shorewall/rules de Shorewall, que sólo permitirá el acceso hacia Squid desde la zona de red de área local, correspondería a algo similar a lo siguiente:
#ACTION SOURCE DEST PROTO  DEST  SOURCE
#    PORT  PORT(S)1
ACCEPT loc fw tcp 8080
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
Para aplicar los cambios en Shorewall, ejecute:
service shorewall restart

Re-direccionamiento de peticiones a través de la opción REDIRECT en Shorewall.

La acción REDIRECT en Shorewall permite redirigir peticiones hacia protocolo HTTP para hacerlas pasar a través de Squid. En el siguiente ejemplo las peticiones hechas desde la zona que corresponde a la red local serán redirigidas hacia el puerto 8080 del cortafuegos, en donde está configurado Squid configurado como Servidor Proxy (Proxy) transparente.
#ACTION SOURCE DEST PROTO  DEST  SOURCE
#    PORT  PORT(S)1
ACCEPT loc fw tcp 8080
REDIRECT loc 8080 tcp 80
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

Exclusión de sitios en Shorewall.

En el caso de sitios que se quiera excluir de ser utilizados con Squid, es decir, sitios problemáticos, se puede configurar en Shorewall que el acceso sea directo, con una configuración similar a la del siguiente ejemplo, donde se excluye de pasar por Squid las peticiones dirigidas a las redes 201.144.108.0/24 (IMSS.gob.mx) y 200.33.74.0/24 (SAT.gob.mx) y se abre el paso directo desde la red local hacia esta red:
#ACTION SOURCE DEST PROTO  DEST  SOURCE
#    PORT  PORT(S)1
ACCEPT loc fw tcp 8080
REDIRECT loc 8080   tcp 80 - !201.144.108.0/24,200.33.74.0/24
ACCEPT  loc net:201.144.108.0/24 all
ACCEPT  loc net:200.33.74.0/24 all
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

Re-direccionamiento de peticiones a través de iptables.

Bajo ciertas circunstancias, se requerirá tener salida transparente hacia Internet para ciertos servicios, pero al mismo tiempo se necesitará re-direccionar peticiones hacia servicio HTTP para pasar a través del el puerto donde escucha peticiones Squid, como proxy en modo transparente, es decir el puerto 8080/tcp, de modo que se impida la salida hacia alguna hacia servidores HTTP en el exterior sin que ésta pase antes por Squid. Ningún proxy conocido puede funcionar en modo transparente para los protocolos HTTPS, FTP, GOPHER ni WAIS, por lo que dichos protocolos tendrán que ser filtrados a través del NAT.
El re-direccionamiento se hace a través de iptables. Considerando para este ejemplo que la red local se accede a través de una interfaz eth1, el siguiente esquema ejemplifica un re-direccionamiento:
iptables -A INPUT -m state --state NEW -m tcp -p tcp \
     -i eth1 --dport 8080 -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp \
    --dport 80 -j REDIRECT --to-port 8080
service iptables save
 
Fuente original: http://www.alcancelibre.org/staticpages/index.php/19-0-como-squid-general 

martes, 6 de agosto de 2013

Virtualizacion para iOS y Android


Con los VMware Horizon View Clients para iOS y Android con Unity, es más fácil que nunca acceder a las aplicaciones de Windows en dispositivos con Android, iPhone o iPad. Ahora podrá trabajar con Windows en dispositivos móviles sin inconvenientes con una interfaz de usuario nativa para dispositivos móviles. Con Unity, los usuarios pueden examinar, buscar y abrir archivos y aplicaciones de Windows con facilidad, marcar aplicaciones y archivos como favoritos, y cambiar fácilmente entre aplicaciones en ejecución.

 Más información en : www.wmware.com

Búscalo en el Apple Store y en Google Play es gratuito.