VPN Roadwarrior con OpenVPN

Una VPN roadwarrior es una VPN de Acceso Remoto, la teoría la puse en la entrada anterior, vamos de frente a la configuración.

Consideraciones preliminares

OpenVPN

Es el software de código abierto que nos permite implementar los diferentes tipos de VPN, de acuerdo a nuestras necesidad mas información aquí:

http://openvpn.net/

Lo instalamos:

# yum -y install openvpn

Configuración:

En el servidor de OpenVPN no te olvides de activar el ip_forwarding.

Edita /etc/sysctl.conf y cambia ip_forwarding a 1 (está normalmente en 0).

Entonces ejecuta:

# sysctl -p

De olvidar lo anterior la vpn no hará ping hacia la red interna!

En el servidor openvpn necesitamos crear una serie de claves y certificados iniciales, para poder autenticar y encriptar la información que transitará desde/hacia el servidor/clientes.

Contamos con una serie de scripts en el directorio /usr/share/easy-rsa los cuales nos ayudarán mucho a ejecutar ésta tarea inicial.

Como primer paso, sugiero copiar ese directorio (easy-rsa) hacia /etc/openvpn y cambiarnos a ese directorio:

# cp -a /usr/share/doc/openvpn*/easy-rsa /etc/openvpn

# cd /etc/openvpn/easy-rsa/2.0

Una vez dentro de éste directorio procedemos a ejecutar los siguientes pasos:

# .vars

# sh clean-all

# sh build-ca

Con ellos lo que haremos es:

* Inicializar variables de ambiente para poder trabajar con los siguientes scripts de shell para generar las variables.

* Inicializamos el directorio de las claves (borrando potenciales archivos viejos).

Primero: Creando el certidicado CA

Procedemos a generar el certificado CA, en el último paso se nos pedirá una serie de información sobre nuestra red/empresa que debemos llenar lo más fielmente posible.

La variable que debemos procurar llenar (no dejar en blanco! es: Common Name. Se refiere al nombre del servidor.

Ejecutamos:

# build-ca


Segundo: Generación del certificado y de la clave de encriptación para el servidor

Siguiente a la generación del Certificado de autoridad, procedemos a crear el certificado del servidor y de su clave de encriptación, ejecutamos:

# sh build-key-server server

En éste paso, también se nos pedirá nuevamente información sobre el certificado propio del servidor. En éste caso por favor, escoger en Common Name un nombre diferente al anteriormente escogido. En mi caso escogí: server

Este paso nos generará dos archivos en el directorio /etc/openvpn/easy-rsa/keys/ los que debemos copiar dentro del mismo servidor en /etc/openvpn, ellos son:

* server.crt
* server.key

Tercero: Generando certificados y claves privadas para los clientes

Cada cliente debe tener su propio certificado y clave de seguridad, para cada cliente que tengamos deberemos repetir el siguiente paso. Los archivos obtenidos debemos copiarlos hacia el directorio /etc/openvpn/ de los clientes.

En el caso de que nuestros clientes sean en windows, debemos copiarlos hacia c:\program files\openvpn\

En nuestro servidor, generamos el certificado y las claves privadas para los clientes, dentro de /etc/openvpn/easy-rsa/

Ejecutamos:

# sh build-key client1

Debemos tener en cuenta que al ejecutar el programa sh build-key, le pasamos como parámetro el nombre del cliente (client1 en el ejemplo anterior) el cual debe ser diferente para cada cliente. En el common name ponemos el nombre del cliente (client1 en éste ejemplo) tal y como le pasamos de parámetro.

Se pueden generar tantas claves como sean necesarias:

# sh build-key client2

# sh build-key client3

Esto nos genera dos claves y certificados más, para client2 y client3, no olvidar en Common Name debemos poner client2 o client3 respectivamente.

Cuarto: Generamos el parámetro Diffie-Hellman

Ejecutamos:

# sh build-dh

Quinto: archivos a copiar al servidor

Hacia el directorio /etc/openvpn del servidor copiamos los siguientes archivos:

* ca.crt
* ca.key
* server.key
* server.crt
* dh1024.pem

Estos archivos están presentes en: /etc/openvpn/easy-rsa/keys

Sexto: Archivos a copiar al cliente

Hacia el directorio /etc/openvpn de cada cliente copiamos los siguientes archivos:

* ca.crt
* clientX.crt

* clientX.key

Tenga en cuenta que X es un número que se corresponde con el cliente (para el cliente 2 sería: client2.crt y client2.key por ejemplo).

Estos archivos están presentes en: /etc/openvpn/easy-rsa/keys del servidor.

Para la configuración en modo roadwarrior las configuraciones del cliente y el servidor varían un poco:

Configuración del servidor:

El archivo /etc/openvpn/server.conf quedará así:

* un push de la ruta hacia la red local interna del servidor. Esa ruta estática permitirá que el road warrior vea a las máquinas de la red interna

* server: Indica el rango de direcciones que se asignará a los clientes que se conecten, deben ser direcciones no similares a las de la red local.

Configuración del cliente:

En el caso del cliente, así quedaría el archivo de configuración, client1.conf:

Si usamos como cliente algún windows el archivo de configuración debe tener la siguiente extensión client1.ovpn.

Servidores VPN

• Qué es una VPN?

Una VPN (Virtual Private Network o Red Privada Virtual), es la tecnología que nos permite extender una red privada LAN hacía la red mundial WAN, mediante un proceso de encapsulación (tunneling) y en su caso de encriptación, de tal manera que desde cualquier lugar del mundo podremos conectarnos a nuestra red local, y trabajar de manera similar tal como si estuviésemos físicamente dentro de ella, para ello es necesario una conexión a internet.

• Tipos de VPN

Existen 4 tipos de VPN, las voy a detallar a continuación:

1. VPN de Acceso Remoto (roadwarrior)

Es quizás el modelo más usado actualmente, y consiste en usuario o proveedores que se conectan con la empresa desde sitios remotos (oficinas comerciales, domicilios, hoteles, aviones preparados, etc.) utilizando Internet como vínculo de acceso. Una vez autentificados tienen un nivel de acceso muy similar al que tienen en la red local de la empresa. Muchas empresas han reemplazado con esta tecnología su infraestructura dial-up (módems y líneas telefónicas).

2. VPN Punto a Punto (site to site)

Este esquema se utiliza para conectar oficinas remotas con la sede central de la organización. El servidor VPN, que posee un vínculo permanente a Internet, acepta las conexiones vía Internet provenientes de los sitios y establece el túnel VPN. Los servidores de las sucursales se conectan a Internet utilizando los servicios de su proveedor local de Internet, típicamente mediante conexiones de banda ancha. Esto permite eliminar los costosos vínculos punto a punto tradicionales, sobre todo en las comunicaciones internacionales. Es más común el siguiente punto, también llamado tecnología de túnel o tunneling.

3. TUNNELING

La técnica de tunneling consiste en encapsular un protocolo de red sobre otro (protocolo de red encapsulador) creando un túnel dentro de una red de computadoras. El establecimiento de dicho túnel se implementa incluyendo una PDU determinada dentro de otra PDU con el objetivo de transmitirla desde un extremo al otro del túnel sin que sea necesaria una interpretación intermedia de la PDU encapsulada. De esta manera se encaminan los paquetes de datos sobre nodos intermedios que son incapaces de ver en claro el contenido de dichos paquetes. El túnel queda definido por los puntos extremos y el protocolo de comunicación empleado, que entre otros, podría ser SSH.

4. VPN over LAN

Este esquema es el menos difundido pero uno de los más poderosos para utilizar dentro de la empresa. Es una variante del tipo "acceso remoto" pero, en vez de utilizar internet como medio de conexión, emplea la misma red LAN de la empresa. Sirve para aislar zonas de servidores dentro de la LAN. También es muy usada para mejorar la seguridad de las redes inalámbricas WIFI.

Servidor de Mensajería Openfire integrado con OPenLDAP

Hoy vamos a configurar el Servidor de Mensajería Instantánea Openfire (chat corporativo) y lo vamos a integrar con un server OpenLDAP (previamente configurado) o Active Directory, para centralizar y autenticar a nuestros usuarios. Openfire: Es desarrollado por la empresa Inigte Realtime, descargamos la último versión desde la web.

http://www.igniterealtime.org/downloads/

En este caso: openfire-3.6.4-1.i386.rpm

Descargamos el cliente Spark para windows y linux también de la misma web.

Procedimiento:

1. Instalamos openfire:

   # rpm -Uvh openfire-3.6.4-1.i386.rpm

2. Ingresamos al directorio /opt/openfire/bin, ejecutamos el script openfire.sh

   # cd /opt/openfire/bin

   # ./openfire.sh

3. En nuestro navegador tecleamos y escogemos nuestro idioma : http://localhost:9090

4. Definimos nuestro dominio redlinux.org, click en Continuar.

5. Seleccionamos Base de datos interna, click Continuar:

6. Seleccionamos Servidor de Directorio (LDAP), podemos elegir (OpenLDAP, Novell NDS, Microsoft Active DIrectory, etc.) de acuerdo a nuestra necesidad y luego click en Continuar.

7. En la pagina Seteos de perfil: Seteos de Conexión Paso 1 de 3: Seteos de Conexión Servidor LDAP configure su conexión a servidor LDAP, en el ejemplo Tipo de Servidor: OpenLDAP, Servidor: localhost, DN Base: dc=redlinux,dc=org, en Autenticación, DN del Administrador: cn=admin,dc=redlinux,dc=org y Clave: la clave del administrador, para comprobar que todo ha sido ingresado correctamente presione el botón Testear seteos (recomendado) o continúe presionando el botón Salvar y continuar.

8. Ahora pasamos al Paso 2 de 3: Mapeos de Usuarios presione el botón de Seteos Avanzados ingrese el filtro de usuarios, (objectClass=posixaccount) ahora con la barra de desplazamiento del navegador muévase a la parte inferior de la pantalla y presione los botones de Testear Seteos (recomendado) y luego Salvar y Continuar.

9. Pasamos al Paso 3 de 3: Mapeos de Grupos presione el botón de Seteos Avanzados ingrese en Modo Posix: No y en filtro de grupos, (objectClass=posixGroup), presione los botones de Testear Seteos (recomendado) y luego Salvar y Continuar.

10. Ahora ingresamos el nombre de un usuario que actúa como administrador de Openfire, este debe ser un usuario valido que se encuentre en el árbol LDAP, en este caso agregar Administrador: rdavila y presione el botón Agregar.
Finalmente nos conectamos a la consola de administración.

Instalamos el cliente Spark en Linux o windows y nos conectamos con los usuarios de nuestro servidor OpenLDAP. Reiniciamos los servicios y probamos.

Cualquier consulta..................

Configuración de Servidor FTP

Un Servidor FTP es un equipo que generalmente esta conectado a Internet WAN o una LAN desde el cual se pueden bajar o subir archivos mediante el protocolo FTP.

Servidor VSFTPD siglas de Very Secure FTP Daemon es un software utilizado para implementar servidores de archivos a través del protocolo FTP. Se caracteriza por su seguridad y configuración sencilla, en comparación con otras soluciones. Hoy en día se dice que VSFTPD es quizá el Servidor FTP más seguro del mundo.

Antes de empezar con la implementación del Servidor FTP debemos saber que el protocolo FTP requiere de múltiples puertos de red para funcionar correctamente. Cuando una aplicación cliente FTP inicia una conexión a un servidor FTP, abre el puerto 21 en el servidor, conocido como el puerto de comandos. Se utiliza este puerto para arrojar todos los comandos al servidor. Cualquier petición de datos desde el servidor se devuelve al cliente a través del puerto 20 llamado puerto de datos. Cuando el cliente FTP inicia una transferencia de datos, el servidor abre una conexión desde el puerto 20 en el servidor para la dirección IP y un puerto aleatorio sin privilegios (mayor que 1024) especificado por el cliente. Debido a esto muchos firewall normalmente rechazan las conexiones entrantes desde servidores FTP.

Para solucionar este pequeño obstáculo tenemos que crear reglas en el firewall que nos permitan encontrar puertos dinámicos de escucha de FTP, reglas para habilitar Connection Tracking. Bueno ahora empezamos con la implementación del Servidor FTP; el paquete requerido para este servidor es VSFTPD.

Instalamos software requerido:

# yum -y install vsftpd

Fichero de Configuración

El fichero para configurar es vsftpd.conf, cuya ruta es: /etc/vsftpd/vsftpd.conf
Entramos:

# cd /etc/vsftpd/
# ls (observamos el fichero de configuración)

es bueno hacer un backup del archivo.conf que viene por defecto:

# cp vsftpd.conf vsftpd.conf.backup

Ahora editamos el archivo con nuestro editor de texto preferido: # vim vsftpd.conf

Podemos configurar nuestro servidor FTP de tal manera que los usuarios puedan acceder como usuarios anónimos (no requiere autenticación) o usuarios autenticados.

1. Configuración de parámetros para usuarios anónimos

Para configurar correctamente un servidor FTP para usuarios anónimos debemos conocer algunos parámetros los que detallamos a continuación:

Parámetro anomymous_enable

Con este parámetro definimos si se van a permitir los accesos anónimos al servidor. Establecemos valor YES o NO. anonymous_enable=YES

Parámetro local_enable

Permitimos los accesos autenticados de los usuarios locales del sistema. Establecemos YES o NO.

local_enable=NO

Parámetro write-enable

Aquí definimos si se permite el mandato “write” (escritura) en el servidor. Establecemos YES o NO.

write_enable=YES

Parámetro anon_upload_enable

Con esto podemos permitir a usuario anónimos subir archivos al servidor. Antes tiene que estar activado el parámetro global write_enable.

anon_upload_enable=YES

Parámetro anon_mkdir_write_enable

Este parámetro permite a los usuarios anónimos, crear directorios en el servidor.

anon_mkdir_write_enable=YES

Parámetro ftp_banner

Este parámetro permite establecer una bienvenida cada vez que algún usuario se conecte al servidor.

ftpd_banner=Bienvenido al Servidor FTP de RedLinux S.R.L.

Parámetros para el Control del Ancho de Banda

Parámetro anon_max_rate

Con este parámetro limitamos la tasa de transferencia en bytes por segundo para los usuarios anónimos. Por ejemplo si queremos limitar la tasa de transferencia a 50 Kb por segundo para los usuarios anónimos: (esta línea la colocamos al final de vsfftpd.conf) .

anon_max_rate=51200

2. Configuración de parámetros para usuarios locales (autenticados)

Esta es la configuración de un servidor FTP para usuarios locales:

Parámetro anomymous_enable

Con este parámetro definimos si se van a permitir los accesos anónimos al servidor. Establecemos valor YES o NO.

anonymous_enable=NO (o comentamos la línea)

Parámetro local_enable

Permitimos los accesos autenticados de los usuarios locales del sistema. Establecemos YES o NO.

local_enable=YES

Parámetro write-enable

Aquí definimos si se permite el mandato “write” (escritura) en el servidor. Establecemos YES o NO.

write_enable=YES

Parámetro anon_upload_enable

anon_upload_enable=NO (o comentamos la línea)

Parámetro anon_mkdir_write_enable

anon_mkdir_write_enable=NO (o comentamos la línea)

Parámetro ftp_banner

Este parámetro permite establecer una bienvenida cada vez que algún usuario se conecte al servidor.

ftpd_banner=Bienvenido al Servidor FTP de RedLinux S.R.L.

Parámetro chroot_local_user y chroot_list_enable

El parámetro chroot_local_user permite o no a los usuarios locales acceder al servidor. Colocamos este parámetro a la altura de la siguiente sección del vsftpd.conf.

# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chroot_list

Parámetro local_max_rate

Con este parámetro limitamos la tasa de transferencia en bytes por segundo para los usuarios locales. Por ejemplo si queremos limitar la tasa de transferencia a 50 Kb por segundo para los usuarios locales. Esta línea la ponemos al final del archivo.

local_max_rate=51200

Finalmente iniciamos por primera vez el servidor VSFTPD:

# service vsftpd start

Para que se inicie automáticamente cada vez que iniciemos el sistema le damos:

# chkconfig vsftpd on

Para para vsftpd:

# service vsftpd stop

Para para reiniciar el servicio:

# service vsftpd restart

### espero les sirva ### se aceptan comentarios y sugerencias....gracias RDS.....

Configuración de Servidor Proxy

1. Servidor PROXY

Un servidor Proxy , es básicamente un programa que acepta peticiones de clientes para las URL, obtiene, y devuelve los resultados al cliente. Los Proxy se utilizan en redes en la que los clientes no tienen acceso directo a Internet, pero tienen que ser capaces de ver páginas Web y para la memoria caché de las páginas comúnmente solicitadas, de manera que si más de un cliente quiere ver la misma página, sólo tiene que ser una vez descargada.

1.1. Squid PROXY

Squid es el Proxy más popular servidor para sistemas Unix. Es libre y está disponible para su descarga desde www.squid-cache.org, y se incluye como paquete estándar con todas las distribuciones de Linux y muchos otros sistemas operativos. Squid soporta Proxy, caching y aceleración HTTP, y tiene un gran número de opciones de configuración para controlar el comportamiento de estas características.

2. Instalación y Configuración de Squid

Empezamos instalando squid y httpd:

# yum - y install squid httpd

Squid utiliza el fichero de configuración ubicado en la siguiente ruta:

/etc/squid/squid.conf, el cual podremos trabajar con nuestro editor preferido.

Configuración squid.conf

Antes de empezar a configurar algún servicio en Linux es recomendable hacer una copia del archivo de configuración que viene por defecto, esto lo hacemos de la siguiente manera:

# cp squid.conf squid.conf.original

Ahora pasamos a configurar squid.conf. Usamos algún editor vim, mcedit, etc. Entramos en la ruta absoluta del archivo de configuración:

# cd /etc/squid
# vim squid.conf

Configurar: parámetro http_port: (puerto que utilizará Squid)

De acuerdo a las asignaciones hechas por IANA y continuadas por la ICANN desde el 21 de marzo de 2001, los Puertos Registrados recomendados para servidores intermediarios (proxies) pueden ser el 3128 y 8080 a través de TCP.

De modo predefinido Squid utilizará el puerto 3128 para atender a peticiones, sin embargo podemos especificar que lo haga en cualquier otro puerto disponible o bien que lo haga en varios puertos a la vez.

Si queremos darle mayor seguridad, vinculamos el servicio a una IP que solo se pueda acceder desde la red local. Si nuestro servidor tiene la dirección IP: 192.168.1.45, hacemos lo siguiente:

Configurar: parámetro cache_mem

Este parámetro cache_mem establece la cantidad de memoria para:

-Objetos de transito
-Objetos frecuentemente utilizados (Hot).

Por defecto vienen 8 MB. Podemos especificar una cantidad mayor dependiendo de nuestras necesidades.

Si tenemos un servidor con al menos 128 MB de RAM, establecemos 16 MB como valor para este parámetro:

cache_mem 16 MB


Configurar: parámetro cache_dir

Establecemos que tamaño deseamos que tenga el caché en el disco duro para Squid. De modo predefinido Squid utilizará un caché de 100 MB, de modo que encontramos la siguiente línea:

cache_dir ufs /var/spool/squid 100 16 256

Podemos incrementar el tamaño del caché según nuestra necesidad.

Mientras más caché tengamos, más objetos se almacenarán en éste y por lo tanto se utilizará menos ancho de banda. Por ejemplo establecemos un caché de 10000 MB:

cache_dir ufs /var/spool/squid 10000 16 256

Los números 16 y 256 significan que el directorio del caché contendrá 16 directorios subordinados con 256 niveles cada uno. No es necesario modificar estos números.

Configurar: parámetro cache_mgr

De modo predefinido, si algo ocurre con el caché, como por ejemplo que muera el proceso, se enviará un mensaje de aviso a la cuenta webmaster del servidor. Puede especificarse una distinta si acaso de considere conveniente.

cache_mgr webmaster@redlinux.com

Controles de Acceso

Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertos equipos 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

La sintaxis para una lista de control de acceso por lo general es la siguiente:

acl [nombre de la lista] src [lo que compone la lista]

Si deseamos establecer una lista de control de acceso que abarque a toda la red, tenemos que definir la dirección IP correspondiente a la red y la máscara de sub-red.

Por ejemplo:

Mi red: 192.168.1.0 (nuestra red local) Máscara de sub-red: 255.255.255.0

La lista sería:

acl mired src 192.168.1.0/255.255.255.0

También podemos especificar una Lista de Control de Acceso especificando un fichero que contenga una lista de direcciones IP. Por ejemplo un grupo de IPs de los jefes.

Primero creamos el fichero dentro de la ruta de Squid:

# cd /etc/squid
# touch jefes

Editamos el fichero e ingresamos las direcciones IP:

# vim jefes

192.168.1.6

192.168.1.7

192.168.1.8

192.168.1.9

192.168.1.10

Aquí estamos definiendo la Lista de Control de Acceso denominada jefes estaría compuesta para las IP incluidas en el fichero /etc/squid/jefes. La lista sería:

acl jefes src “/etc/squid/jefes”

Reglas de Control de Acceso

Estas definen si se permite o no el acceso hacia Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso, es decir, a partir de donde se localiza la siguiente leyenda:

La sintaxis básica es la siguiente:

http_access [deny o allow] [lista de control de acceso]

Ahora un ejemplo con la Lista de Control de Acceso jefes definida anteriormente:

http_access allow jefes

También podemos definir reglas haciendo uso de la expresión ! que significa no. Por ejemplo: Dos listas de control de acceso una denominada jefes (acceso a Squid), y mired (sin acceso). Aquí establecemos que solo la lista jefes tendrá acceso a squid excepto todo lo que comprenda a mired.
http_access allow jefes !mired

Esto tipo de reglas se aplican cuando tenemos un 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

Ahora vamos a ver algunos casos donde podemos aplicar listas y reglas de control de acceso.

Ejemplo:

Si tenemos una red 192.168.1.0/255.255.255.0, si se desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de Control de Acceso:

acl mired src 192.168.1.0/255.255.255.0

Ahora la sección de listas de control de acceso deberá quedar más o menos del siguiente modo:

# Recommended minimum configuration:
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.0
acl mired src 192.168.1.0/255.255.255.0

Ahora procedemos a aplicar la regla de control de acceso:

http_access allow mired

Ahora la sección de reglas de control de acceso deberá quedar más o menos del siguiente modo:

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTES
#

La regla http_access allow mired permite el acceso a squid a la Lista de Control de Acceso denominada mired, la cual está conformada por 192.168.1.0/255.255.255.0. Lo que significa que cualquier maquina desde 192.168.1.1 hasta 192.168.1.254 podrá acceder a Squid.

Iniciado Squid

Una vez que terminamos de configurar Squid, ejecutamos por primera vez la siguiente instrucción:

# service squid start

Si necesitamos reiniciar el servicio para ejecutar algún cambio de configuración, hacemos:

# service squid restart

Para que Squid se inicie de manera automática cada vez que iniciemos el sistema, hacemos:

# chkconfig squid on

Restricción de Páginas Web Indebidas

Denegar el acceso a ciertos sitios de red permite hacer un uso más racional del ancho de banda. El proceso es simple, y consiste en denegar el acceso a nombres de dominio o direcciones Web que contengan patrones en común.

Definiendo patrones comunes

Debemos de generar una lista que contenga las direcciones Web y palabras utilizadas en nombres de ciertos dominios.

Ejemplos:

http://www.sitioporno.com/
http://www.otrositioporno.com/
sitioindeseable.com
otrositioindeseable.com
napster
sex
porn
mp3
xxx
adult
warez
celebri

Se recomienda denegar la dirección web del sitio, así como también el dominio, tal como se indico en el ejemplo anterior

Estos dominios y palabras las ingresaremos dentro de una lista en la ruta:

/etc/squid/sitiosdenegados

Previamente deberíamos haber creado el fichero sitiosdenegados dentro de /etc/squid

Parámetros en /etc/squid/squid.conf

Una vez generado el fichero sitiosdenegados, también debemos definir una Lista de Control de Acceso que defina a dicho fichero y la denominaremos “sitiosdenegados”.

La línea correspondiente debería quedar así:

acl sitiosdenegados url_regex “/etc/squid/sitiosdenegados”

Debemos tener lo siguiente:

Ahora generamos la Regla de Control de Acceso correspondiente a la lista “sitiosdenegados”, de la siguiente manera:

http_access allow mired !sitiosdenegados

Luego en squid.conf tendremos:

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTES
#
http_access allow localhost
http_access allow mired !sitiosdenegados
http_access deny all

Para que se efectúen los cambios de configuración ejecutamos:

# service squid restart

Restricción de Archivos por su Extensión

Squid permite denegar el acceso a ciertos tipos de extensiones, lo que nos permite hacer

un uso más racional del ancho de banda. El funcionamiento es simple, y consiste en denegar el acceso a ciertos tipos de extensiones que coincidan con lo establecido en una Lista de Control de Acceso.

Definiendo elementos de la Lista de Control de Acceso

Primero debemos generar una lista que contenga las extensiones que vamos a denegar, esta lista la generamos dentro de /etc/squid.

Ejemplo:

\.avi$
\.mp4$
\.mp3$
\.mpg$
\.mpeg$
\.exe$

Esta lista debe ser guardada con todas las extensiones de fichero que consideremos pertinentes, la guardamos como /etc/squid/listaextensiones.

Parámetros en /etc/squid/squid.conf

Debemos definir una Lista de Control de Acceso que a su vez defina al fichero /etc/squid/listaextensiones. Esta lista será denominada “listaextensiones”. Lo que debe quedar de la siguiente manera:

acl listaextensiones urlpath_regex “/etc/squid/listaextensiones”

Habiendo hecho esto, en la sección de Lista de Control de Acceso debemos tener:

Ahora generamos una Regla de Control de Acceso para la lista “listaextensiones”, de la siguiente manera:

http_access allow mired !sitiosdenegados !listaextensiones

Para que se efectúen los cambios de configuración reiniciamos Squid:

# service squid restart

###espero les sirva RDS......####