Mostrando entradas con la etiqueta squid. Mostrar todas las entradas
Mostrando entradas con la etiqueta squid. Mostrar todas las entradas

martes, 24 de junio de 2014

Cómo crear Certificados SSL autofirmados para uso local

Como todos sabemos, el tráfico en Internet normalmente no va encriptado o protegido. Por lo que cualquier persona, conociendo las técnicas necesarias, puede interceptar nuestras cosas, y aún si consideramos que mucho de lo que enviamos y recibimos a través de Internet no es de importancia para otros, la existencia de los certificados SSL es debido a la necesidad de proteger nuestra información sensible de ser vistas por otros.

Obviamente, debido a los recientes acontecimientos sobre la NSA, los certificados SSL ahora solo nos dan un falso sentido de la seguridad, pero aún así no podemos dejar de usarlos.

El certificado que vamos a crear lo podemos usar ampliamente en nuestro servidor Web local o en Squid para aplicarle técnicas de filtrado (aunque esto no es muy ético).


domingo, 17 de junio de 2012

Pronto tendremos Squid 3.2

Luego de más de un año sin actualizaciones en Squid, el proxy-cache más conocido y utilizado en los sistemas GNU/Linux; el equipo de desarrolladores ha anunciado la pronta aparición de la versión 3.2 la cual esperamos que traiga convenientes mejoras y depuraciones necesarias.

Según indican en su blog oficial, es cuestión de un breve tiempo para (de hecho es un post del mes de marzo) que hagan las pruebas de lugar en la beta 3.2 para cersiorarse de que sean eliminados la mayor cantidad de bug. Para eso también están pidiendo nuestra colaboración.



lunes, 26 de marzo de 2012

Instalar Aquarium GUI para Squid Proxy en Fedora

Como vimos en un post anterior, Aquarium es una interfaz para Squid Proxy Caché que forma parte de TrafficSqueezer. Podemos usar Aquarium para facilitar la configuración del proxy. No obstante, editar el fichero squid.conf de forma manual sigue siendo la mejor opción para configurar Squid. Para el siguiente tutorial utilizaremos Fedora 14 o superior, los servicios Apache, MySQL, PHP y, por supuesto, Squid. Además de otras dependencias que nos ayudarán a compilar Aquarium.

Otro dato importante es el hecho de que podemos hacerlo en una máquina virtual (yo uso VirtualBox) con dos interfaces de red, una NAT y otra Bridged hacia nuestra red local para poder accesar la interfaz de Aquarium.

Manos a la obra...



viernes, 23 de marzo de 2012

Aquarium GUI para Squid Proxy Cache ahora es Open Source

Aquarium es la interfaz web de configuración para Squid Proxy Caché que forma parte de TrafficSqueezer, el cual a su vez es un proyecto Open Source para aceleración de tráfico en redes WAN, optimización de Internet y otras redes de datos y comunicaciones. Está definido también como una herramienta de ingeniería de paquetes de red, y aunque existen otras herramientas para estas tareas como IPtables, TrafficSqueezer ofrece características específicas para ingeniería de tráfico en optimización de redes WAN.

Con la lamentable noticia del cierre de Doublefish Solutions, la empresa de soporte detrás de TrafficSqueezer, llega la intersante nota de que Aquarium ha sido liberado por completo y está disponible para su descarga.




miércoles, 6 de abril de 2011

Configurar Proxy en Yum en Fedora/CentOS con Squid

Configurar Squid para que permita pasar los rpm de los repositorios:

admin@server:~$ sudo nano /etc/squid3/sitiospermitidos

fedora
repodata

Luego editamos el archivo squid3.conf para agregar la Lista de Control de Acceso y la Regla de Control de Acceso:

admin@server:~$ sudo nano /etc/squid3/squid.conf



martes, 15 de febrero de 2011

Monitoreo del acceso web vía Squid Proxy (access.log)

Como ustedes ya saben en este blog Squid Proxy no necesita introducción, además si estás buscando información sobre lo que trataremos sobre Squid ahora probablemente es porque ya has configurado un Proxy Squid en GNU/Linux; por lo que iremos directamente al asunto. Y bueno, solo por si las moscas no conoces lo que es Squid Proxy te diré que un proxy es un servidor o aplicación intermediaria entre una o varias computadoras por medio de las cuales se buscan recursos (regularmente de Internet) y el destino o servidor donde se encuentran dichos recursos. 

Fuera de los filtros o restricciones que se pueden establecer en un servidor o aplicación proxy, este suele trabajar en dos modalidades: 


domingo, 7 de noviembre de 2010

Cómo: Limpiar/Borrar la memoria caché de Squid Proxy

Como hemos visto en posts anteriores, Squid ofrece una solución ideal para el control de la navegacion en Internet en el lugar de trabajo o nuestro hogar.

En esta ocasión vamos a ver cómo podemos limpiar la memoria caché. Este es un procedimiento bastante simple pero casi siempre no tiene mucha relevancia hacer, pues si hemos configurado un límite para su tamaño en el fichero squid.conf este no pasará de ahí.

Básicamente lo primero que hay que hacer es deterner el daemon de Squid y hay varias formas de hacerlo, entre ellas:


miércoles, 22 de septiembre de 2010

How-To: Configurar squid-deb-proxy Ubuntu/Debian


Ya hemos tratado anteriormente en este blog sobre squid-deb-proxy. No obstante en ninguna parte del post habla sobre su instalación y configuración, tanto en el servidor como en los clientes.

Esto es útil si tenemos varios clientes Ubuntu/Debian la red local y todos ellos descargan las actualizaciones. En lugar de que cada cliente se conecte a Internet para obtener las actualizaciones, recibirá las actualizaciones desde el servidor de almacenamiento en caché.
En todo esto hay muchas ventajas:
  • Economizar ancho de banda.
  • Obtener las actualizaciones con mayor rapidez.
  • Más seguridad porque solo el servidor necesitará conexión directa a internet.
  • La configuración es sencilla.
  • Los clientes no necesitan configuración (solo instalar squid-deb-proxy-client).
  • Las actualizaciones se obtienen del servidor de caché cuando está disponible y cuando no está se ajusta automaticamente a conexión directa.
Para instalarlo lo podemos hacer desde el Centro de Software, Synaptics o desde el terminal, tanto en los clientes como en el servidor:

      admin@server:~$ sudo apt-get install squid-deb-proxy squid-deb-proxy-client
      admin@cliente1:~$ sudo apt-get install squid-deb-proxy-client
      admin@cliente2:~$ sudo apt-get install squid-deb-proxy-client

      etc, etc,

Como vemos, en el server también debemos instalar el squid-deb-proxy-client para que obtenga de caché las actualizaciones también.

Algunos archivos de configuración adicional:

      /etc/squid-deb-proxy/mirror-dstdomain.acl (para agregar mirrors adicionales).
      /var/log/squid-deb-proxy/ (folder que contiene los logs).


miércoles, 11 de agosto de 2010

How-To: Evadir el uso de la memoria caché en Squid3

Como hemos visto en posts anteriores, Squid ofrece una solución ideal para el control de la navegacion en Internet en el lugar de trabajo o nuestro hogar.

En esta ocasión vamos a ver cómo nos permite configurar algunos clientes o direcciones de internet para que no sean cacheadas, es decir, no nos presente la copia en memoria caché de paginas que hemos navegado anteriormente.

Luego de haber configurado Squid3 ya sea en nuestro servidor proxy transparente o de forma no transparente, podemos definir patrones en un archivo de texto plano como los siguientes:

admin@server:~$ sudo nano /etc/squid3/sitios-no-cache

dgii.gov.do
dida.gob.do
datacredito.com.do
tss.gov.do
jce.gov.do

También podemos permitir que uno o varios clientes en nuestra red tengan acceso a través del proxy sin usar la caché identificandolos por su dirección MAC:

acl cliente-no-cache arp MI:MA:CA:DD:RE:SS

Luego editamos el archivo squid3.conf para agregar la Lista de Control de Acceso y la Regla de Control de Acceso correspondientes:

admin@server:~$ sudo nano /etc/squid3/squid.conf

acl sitios-no-cache url_regex "/etc/squid3/sitios-no-cache"
acl cliente-no-cache arp 00:01:02:03:04:05
http_access allow sitios-no-cache
http_access allow cliente-no-cache
no_cache deny sitios-no-cache
no_cache deny cliente-no-cache
http_access deny all

Todo debe colocarse en el orden en que esta aqui, pues Squid lee el archivo de arriba hacia abajo y si ponemos el http_acces deny all de primero, este denegará todo el acceso y las demas reglas serán inválidas.

Para finalizar reiniciamos el daemon de squid3:

admin@server:~$ sudo  /etc/init.d/squid3 restart



martes, 3 de agosto de 2010

How-To: Squid Proxy Cache Transparente en Ubuntu (Mas Simple)

Ya hemos tratado anteriormente en este blog sobre como configurar el Squid Proxy Cache. No obstante reconozco de una forma u otra que para muchos puede resultar bien complicado hacerlo. Es muy cierto que insralarlo y editar su archivo de configuracion no es cosa tremenda, pero no menos cierto es que las reglas de IPTables lo ponen algo mas complicado.

Para esta ocasión voy a asumir que tenemos dos NIC o tarjetas de red. Una (eth0) conectada a un modem DSL u otro tipos de acceso a internet, y la otra (eth1) la cual será la puerta de enlace predeterminada en nuestra red local y mediante la cual queremos dar acceso a internet controlado y filtrado usando Squid.

auto eth0
iface eth0 inet static
address 192.168.1.250
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.88

auto eth1
iface eth1 inet static
address 192.168.2.1
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255

Editar el archivo de configuracion de squid3 con nuestro editor favorito.

      admin@server:~$ sudo nano /etc/squid3/squid.conf

Y configurar la transparencia, la red local que usará el proxy y ajustamos el caché:

http_port 3128 transparent
acl nuestra_red src 192.168.2.0/24
acl redlocal src 127.0.0.1/255.255.255.255
http_access allow nuestra_red
http_access allow redlocal
cache_dir ufs /var/spool/squid3 7000 16 256

Aquí el primer numero denota el tamaño de la caché en megabytes. Guardamos los cambios y reinicamos el demonio squid3:

      admin@server:~$ sudo /etc/init.d/squid3 restart

Ahora procederemos a agregar la regla de IPTables que nos va a redireccionar al puerto 3128 (por defecto en Squid3) las peticiones hechas al puerto 80 y hacer la configuración pertinente para que permanezca despues de reiniciar (reboot) el computador: How-To: Restaurar reglas IPTables despues de un reboot en Debian/Ubuntu.

Finalmente, configurar los clientes (computadoras de la red local) con dirección IP estática y como puerta de enlace o gateway la IP 192.168.2.1. 



How-To: Restaurar reglas IPTables Squid3 despues de un reboot en Ubuntu

Debian y Ubuntu por defecto no proveen un initscript para IPTables. Pero eso no significa que sea imposible mantener reglas de firewall al reiniciar el computador si no deseamos usar una interfaz como Gufw o Firestarter. Se puede hacer de la siguiente manera.

Creamos algunas reglas IPTables como por ejemplo la siguiente, y luego las listamos:

sudo iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128
sudo iptables --list

Si estas reglas ya satisfacen nuestra necesidad entonces procedemos a guardarlas en un archivo, que puede estar en cualquier lugar pero lo pondremos en /etc/firewall.conf

sudo iptables-save > /etc/firewall.conf

Si en este paso nos da algun error por lo permisos, hacemos esto:

sudo chmod 766 /etc/firewall.conf

Luego creamos un script para que if-up.d cargue estas reglas al inicio (boot):

sudo nano /etc/network/if-up.d/iptables

#!/bin/sh
iptables-restore < /etc/firewall.conf
service squid3 restart

Ahora lo hacemos ejecutable:

sudo chmod +x /etc/network/if-up.d/iptables

Para finalizar reiniciamos y al volver probamos que las reglas se hayan cargado:

sudo iptables --list

miércoles, 28 de julio de 2010

Entendiendo el archivo access.log de Squid3

Los registros son una fuente valiosa de información sobre las cargas de trabajo y el rendimiento de Squid. Los registros no sólo accesan la información, sino también errores de configuración del sistema y el consumo de recursos (por ejemplo, memoria, espacio en disco). 

Hay registro de varios archivos gestionados por Squid. Algunos tienen que ser explícitamente activos durante el tiempo de compilación, otros con seguridad se puede desactivar durante el tiempo de ejecución. Hay algunos puntos básicos comunes a todos los archivos de registro. Las marcas de tiempo registrado en los archivos de registro suelen ser segundos UTC salvo que se indique lo contrario. La marca de tiempo inicial por lo general contiene una extensión de milisegundo.

Una entrada access.log por lo general consiste de (al menos) 10 columnas separadas por uno o más espacios:


1. time: Una marca de tiempo Unix como segundos UTC, con una resolución de milisegundos. Usted puede convertir las marcas de tiempo Unix en algo más legible para usar este script en perl resumen:

             s/^\d+\.\d+/localtime $&/e;

2. duration: El tiempo transcurrido se soporta debido a considera cuántos milisegundos la transacción ocupó la caché. Se diferencia de interpretación entre TCP y UDP: HTTP Para esto es básicamente el momento de haber recibido la solicitud de calamar cuando termina de enviar el último byte de la respuesta. Para la PIC, este es el tiempo entre una programación de respuesta y de hecho lo envío. Por favor tenga en cuenta que las entradas se registran después de la respuesta terminó siendo enviado, no durante la vida útil de la operación.

3. client address: La dirección IP de la instancia de solicitud, la dirección IP del cliente. La opción de configuración client_netmask pueden distorsionar los clientes por razones de protección de datos, pero hace que el análisis sea más difícil. Muchas veces es mejor usar uno de los anonimizadores archivo de registro. Además, la opción de configuración log_fqdn puede registrar el nombre de dominio completo del cliente en lugar de la cuaterna. El uso de esta opción no se recomienda debido a su impacto en el rendimiento.

4. result codes: Esta columna se compone de dos elementos separados por una diagonal. En esta columna se codifica el resultado de transacciones: El resultado de la solicitud de caché contiene información sobre el tipo de solicitud, la forma en que se ha cumplido, ni por qué ha fallado. Por favor, consulte los códigos de resultado para Squid válidos los códigos de resultado simbólico. Varios códigos de versiones anteriores ya no están disponibles, se cambia de nombre, o se separan. Especialmente los códigos ERR_ no parecen figurar en el archivo de registro más. También se refieren a los códigos de resultado Squid para obtener más información sobre los códigos ya no está disponible. La parte de estado contiene el resultado HTTP códigos con algunas extensiones específicas de Squid. Squid utiliza un subconjunto de los códigos de error RFC definidos para HTTP. Consulte la sección de códigos de estado para obtener detalles de los códigos de estado reconocido.

5. bytes: El tamaño es la cantidad de datos entregados al cliente. Lamentamos que esto no constituye el tamaño del objeto red, como los encabezados también se cuentan. Además, no podrán entregar las solicitudes una página de error, el tamaño de la que también se registra aquí.

6. request method: El método de solicitud para obtener un objeto. Por favor, consulte la sección de solicitar los métodos para los métodos disponibles. Si desactivó log_icp_queries en su configuración, no podrá ver (y por tanto incapaces de analizar) el intercambio de la PIC. El método PURGA sólo está disponible, si usted tiene una ACL para purgar "método" habilitadas en su archivo de configuración.

7. URL: Esta columna contiene la dirección URL solicitada. Tenga en cuenta que el archivo de registro puede contener espacios en blanco para la URI. La configuración por defecto para uri_whitespace niega o trunca los espacios en blanco, sin embargo.

8. rfc931: La octava columna puede contener las búsquedas ident para el cliente solicitante. Dado que las búsquedas han ident impacto en el rendimiento, la configuración predeterminada activa ident_loookups apagado. Si se apaga, o no hay información ident está disponible, un "-" se cerrará la sesión.

9. hierarchy code: La información de jerarquía se compone de tres elementos: a) Cualquier etiqueta jerarquía puede ser el prefijo TIMEOUT_, si el tiempo de espera se produce la espera de todas las respuestas a ICP regreso de los vecinos. El tiempo de espera sea dinámica, si el icp_query_timeout no se ha establecido, o el tiempo se ha configurado revolucionado. b) Un código que se explica cómo se manejó la solicitud, por ejemplo, mediante la transmisión a un compañero, o ir directamente a la fuente. Consulte la jerarquía de los códigos para obtener más información sobre los códigos de la jerarquía y quitar los códigos de jerarquía. c) La dirección IP o nombre de host donde (si un extraño) se remitió la solicitud. Para las solicitudes enviadas a los servidores de origen, esta es la dirección del servidor IP de origen. Para las solicitudes enviadas a un cache de vecinos, este es el nombre de host del vecino. versiones NOTA: mayores de Squid pondría el nombre del servidor origen aquí.

10. type: El tipo de contenido del objeto como se ve en la cabecera de respuesta HTTP. Tenga en cuenta que los intercambios de la PIC por lo general no tienen ningún tipo de contenido, y por lo tanto se registra "-". Además, algunas respuestas raro tener tipos de contenido ":" o incluso las vacías.

Códigos de resultados de Squid:

TCP_ Hace refrencia a peticiones en el HTTP usualmente en el puerto 3128.

TCP_HIT Una copia válida del objeto solicitado fue en la caché. 

TCP_MISS El objeto solicitado no estaba en el caché. 

TCP_REFRESH_HIT Objeto en caché se solicitó, pero el viejo. La consulta IMS para el objeto dado como resultado "304 no se modifica". 

TCP_REFRESH_FAIL_HIT El objeto solicitado guardada en caché, pero rancio. La consulta no IMS y el objeto de entrega era rancio. 

TCP_REFRESH_MISS El objeto solicitado guardada en caché, pero rancio. La consulta IMS devolvió el nuevo contenido.

TCP_CLIENT_REFRESH_MISS El cliente emitido la "no-cache" pragma, o algún comando de control de caché análogos junto con la solicitud. Por lo tanto, la caché tiene que refetch el objeto. 

TCP_IMS_HIT El cliente IMS emitió una solicitud para un objeto que estaba en la caché y fresco. 

TCP_SWAPFAIL_MISS se creía que el objeto se encuentre en la caché, pero no se podía acceder. 

TCP_NEGATIVE_HIT Solicitud de una manera negativa objeto en caché, por ejemplo, "404 no encontrado", por lo que la memoria caché cree saber que es inaccesible. También se refieren a la explainations para negative_ttl en su archivo squid.conf. 

TCP_MEM_HIT una copia válida del objeto solicitado fue en la caché y fue en memoria, evitando accesos a disco. 

TCP_DENIED Se denegó el acceso para esta solicitud. 

TCP_OFFLINE_HIT El objeto solicitado fue encontrado en la caché durante el modo fuera de línea. El modo fuera de línea no valida ningún objeto, consulte en el archivo squid.conf offline_mode. 

TCP_STALE_HIT El objeto fue servido en caché y rancio. Esto es causado usualmente por rancio-mientras-revalidar o rancio--error si. 

TCP_ASYNC_HIT La solicitud de antecedentes (por ejemplo, un iniciadas por rancio-mientras-revalidar) dio lugar a una actualización de golpe. TCP_ASYNC_MISS La solicitud de antecedentes (por ejemplo, un iniciadas por rancio -mientras-revalidar) resultó en un fallo, es decir, el objeto en caché (si los hay) se ha actualizado). 

UDP_HIT una copia válida del objeto solicitado fue en la caché. 

UDP_MISS El objeto solicitado no se encuentra en esta caché. 

UDP_DENIED Se denegó el acceso para esta solicitud. 

UDP_INVALID una petición no válida se recibió.

UDP_MISS_NOFETCH Durante "-Y" de inicio, o durante las averías frecuentes, una caché en modo de único hit se devuelven UDP_HIT o código de este. Los vecinos por lo tanto sólo recoger muestras. 

NONE Visto con peticiones cachemgr y errores, por lo general cuando la transacción falla antes de ser clasificados en uno de los resultados anteriores. 

Los sufijos de código siguientes son específicos de Squid3: 

_ABORTED significa que la conexión con el cliente HTTP se cerró o de otra manera no antes de tiempo. Esto incluye cliente de sockets cerrado la mitad cuando half_closed_clients en squid.conf está apagado. 

_TIMEDOUT Sufijo significa que la operación ha agotado el tiempo al escribir la respuesta al cliente HTTP (por ejemplo, el cliente no estaba leyendo o dejado de leer la respuesta de Squid). 

Los siguientes códigos ya no están disponibles en Squid-2: 

ERR_ ahora figuran en el código de estado. 

TCP_CLIENT_REFRESH Ver: TCP_CLIENT_REFRESH_MISS. 

TCP_SWAPFAIL Ver: TCP_SWAPFAIL_MISS. 

TCP_IMS_MISS suprimido, sustituido ahora con TCP_IMS_HIT. 

UDP_HIT_OBJ Se refiere a una versión antigua que enviaría aciertos de caché en ICP respuestas. Ya no implementado. 

UDP_RELOADING Ver: UDP_MISS_NOFETCH.




sábado, 10 de julio de 2010

How-To: Bloquear acceso a internet con excepcion de algunas paginas y durante cierto tiempo con Squid3

Como hemos visto en posts anteriores, Squid ofrece una solución ideal para el control de la navegacion en Internet en el lugar de trabajo o nuestro hogar.

En esta ocasión vamos a ver cómo nos permite bloquear por defecto todo el acceso a paginas de internet con algunas excepciones que especificaremos y durante un horario. Esto del horario es porque sería realmente desagradable y poco motivador bloquear todo el día el trafico, puesto que todos necesitamos en alguno momento revisar el correo y distraernos un poco en horario de almuerzo o de receso.

Luego de haber configurado Squid3 ya sea en nuestro servidor proxy transparente o de forma no transparente, podemos definir patrones en un archivo de texto plano como los siguientes:

admin@server:~$ sudo nano /etc/squid3/sitiosadmitidos

dgii.gov.do
dida.gob.do
datacredito.com.do
tss.gov.do
jce.gov.do

Luego editamos el archivo squid3.conf para agregar la Lista de Control de Acceso y la Regla de Control de Acceso correspondientes:

admin@server:~$ sudo nano /etc/squid3/squid.conf

acl sitiosadmitidos url_regex "/etc/squid3/sitiosadmitidos"
acl almuerzo time MTWHF 12:00-14:00
http_access allow sitiosadmitidos
http_access allow all almuerzo
http_access deny all

La primera acl define los sitios web que siempre podrán accesarse a cualquier hora del día. La segunda acl define el horario de almuerzo de 12 del mediodia a 2 de la tarde de lunes a viernes. La primera regla permite los sitios adminitidos en nuestra lista. La segunda regla permite todo el acceso a internet durante el horario de almuerzo y, finalmente denegamos todo el acceso que no cumpla con las condiciones anteriores.

Todo debe colocarse en el orden en que esta aqui, pues Squid lee el archivo de arriba hacia abajo y si ponemos el http_acces deny all de primero, este denegará todo el acceso y las demas reglas serán inválidas.

Para finalizar reiniciamos el daemon de squid3:

admin@server:~$ sudo  /etc/init.d/squid3 restart



lunes, 28 de junio de 2010

Gnome Proxy Applet

Proxy Applet es un applet para GNOME que permite cambiar  nuestra configuración de proxy de la red con un solo clic desde el panel de gnome, sin entrar en las preferencias de red y proxy de gnome. Está escrito en C puro y necesita por lo menos GNOME 2.26.

Está disponible su código fuente, y paquetes .deb para arquitecturas 32 y 64 bits.


jueves, 24 de junio de 2010

How-To: Bloqueo de sitios web y contenido con Squid3

En estos días hablar de productividad y uso de internet es una disyuntiva. Hay cierta incertidumbre a la hora pensar en que los usuarios tendrán acceso a internet y la productividad que reporten, a menos que necesiten trabajar directamente en la red.

En los casos en que el acceso a internet y la navegación por sitios web que no son de ayuda para el usuario ni para la empresa, sino que le quitan tiempo y reducen su capacidad de trabajo por estar distraídos y pendientes del correo, del facebook, etc. la mejor opción es configurar un proxy caché con bloqueo de sitios y contenido de palabras en las URL.

Luego de haber configurado Squid3 ya sea en nuestro servidor proxy transparente o de forma no transparente, podemos definir patrones en un archivo de texto plano como los siguientes:

admin@server:~$ sudo nano /etc/squid3/sitiosdenegados

www.facebook.com
www.hi5.com
www.hotmail.com
porn
xxx
adult
www.sitionodeseado.net
www.otrositio.com

Luego editamos el archivo squid3.conf para agregar la Lista de Control de Acceso y la Regla de Control de Acceso:

admin@server:~$ sudo nano /etc/squid3/squid.conf

acl sitiosdenegados url_regex "/etc/squid3/sitiosdenegados"
http_access allow redlocal !sitiosdenegados

Debemos tomar en cuenta que muchos sitios inocentes serán bloqueados porque sus URL contienen pablabras que hemos definido en sitiosdenegados, y para que esto no suceda lo que haremos es crear un fichero con la lista de los sitios que necesitamos que no sean bloqueados por el proxy.

admin@server:~$ sudo nano /etc/squid3/sitiosinocentes

Y como en el caso de los sitios denegados, tambien crearemos su Lista de Control de Acceso y su Regla:

acl sitiosinocentes url_regex "/etc/squid3/sitiosinocentes"
http_access allow all sitiosinocentes

Para finalizar reiniciamos el daemon de squid3:

admin@server:~$ sudo  /etc/init.d/squid3 restart


Fuente: Alcancelibre

miércoles, 23 de junio de 2010

How-To: Proxy Cache Transparente en Ubuntu Server LTS 10.04 con Squid3






Ver también: Squid Proxy Cache más simple aún


Squid es un proxy caché que soporta los protocolos HTTP, HTTPS, FTP y muchos otros. Un proxy reduce el uso de ancho de banda y mejora los tiempos de respuesta haciendo un caché y re-uso de páginas web solicitadas frecuentemente. Squid tiene un amplio control de acceso y acelera el servidor. Puede correr en casi todos los sistemas operativos, incluyendo Windows y su licenciamiento es GNU GPL.

1. Instalar Ubuntu Server LTS 10.04, incluyendo LAMP si lo deseas.

2. Configurar las interfaces de red manualmente y ponerlas estáticas.

      admin@server:~$ sudo nano /etc/network/interfaces

auto eth0
iface eth0 inet static
address 192.168.1.250
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.88

post-up iptables-restore < /etc/iptables.up.rules

auto eth1
iface eth1 inet static
address 192.168.2.1
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255

*En donde eth0 será para conectar el acceso a Internet (Cable, DSL, etc.) y eth1 para nuestra red local.

3. Instalar Web Admin (webmin) (opcional).

admin@server:~$ wget http://prdownloads.sourceforge.net/webadmin/webmin_1.510-2_all.deb
admin@server:~$ dpkg -install webmin_1.510-2_all.deb
admin@server:~$ sudo apt-get -f install

https://localhost-IP ADDRES:10000

*Hay que asegurarse de darle permisos en IPTABLES para acceder de forma remota al Webmin.

4. Instalar ClamAV y ClamAV-freshclam.

      admin@server:~$ sudo apt-get install clamav clamav-freshclam

5. Instalar squid.

      admin@server:~$ sudo apt-get install squid3

Editar el archivo de configuracion de squid3 con nuestro editor favorito.

      admin@server:~$ sudo nano /etc/squid3/squid.conf

Y configurar la transparencia y la red local que usará el proxy:

http_port 3128 transparent
acl nuestra_red src 192.168.2.0/24
acl redlocal src 127.0.0.1/255.255.255.255
http_access allow nuestra_red
http_access allow redlocal

Donde 192.168.2.0/24 es el rango de IP de la red local.

Probablemente tambien necesitaremos ajustar el tamaño de la cahé:

cache_dir ufs /var/spool/squid3 7000 16 256

Aquí el primer numero denota el tamaño de la caché en megabytes. Guardamos los cambios y reinicamos el demonio squid3:

      admin@server:~$ sudo /etc/init.d/squid3 restart

6. Editar el archivo /etc/sysctl.conf

      admin@server:~$ sudo nano /etc/sysctl.conf

Descomentar las líneas que habilitan el redireccionamiento de paquetes para IPv4 e Ipv6:

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

7. Editar la configuración de IPTABLES para NAT y FILTER.

      admin@server:~$ sudo nano /etc/iptables.up.rules

NAT:

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:3128
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-port 3128
-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

FILTER:

-A INPUT -i lo -j ACCEPT
-A INPUT -m state -i eth0 -state REALATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT # permitir ssh usando putty
-A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT # permitir acceso a webmin
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT # permitir pop3
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT # permitir smtp
-A INPUT -j LOG
-A INPUT -j DROP
-A FORWARD -i eth1 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth1 -j ACCEPT
-A FOWARD -o eth1 -j ACCEPT
-A FORWARD -s 192.168.2.0/24 -o eth0 -j ACCEPT
-A FORWARD -d 192.168.2.0/24 -m state --state ESTABLISHED, REALTED -I eth0 -j ACCEPT

8. Editar el archivo /etc/rc.local

      admin@server:~$ sudo nano /etc/rc.local

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

9. Reiniciar el servidor.

      admin@server:~$ sudo shutdown -r now

10. Finalmente, configurar los clientes (computadoras de la red local) con dirección IP estática y como puerta de enlace o gateway la IP del servidor. Debemos asegurarnos de que la dirección IP en los clientes esté en el mismo rango que se configuró en el paso 2. 

Fuente: Ubuntu Geek


miércoles, 16 de junio de 2010

squid-deb-proxy: Repositorio local de actualizaciones en ubuntu

Si es usted como yo y tiene varias máquinas Ubuntu bajo un mismo techo? ¿Está cansado de la descarga de la misma actualización varias veces? Harto de lo que parece ser duplicar el trabajo? Deja que te presente a mi pequeño amigo ... squid-deb-proxy. 

Squid-deb-proxy es un nuevo paquete para Ubuntu 10.04, y está diseñado para hacer su vida más fácil y permite actualizaciones más rápidas si se administra más de una máquina de Ubuntu. Conceptualmente, el squid-deb-proxy se compone de dos piezas, un cliente y un servidor. El paquete de servidor es "squid-deb-proxy" y el paquete del cliente es "squid-deb-proxy-cliente". El "squid-deb-proxy" paquete de servidor es básicamente un servidor de almacenamiento en caché de squid, con un fuera de la configuración de la caja que permite almacenar en memoria caché paquetes .deb y hacerlos accesibles a la red de área local. El "squid-deb-proxy-cliente" paquete es básicamente un archivo de inclusión en la configuración estándar que hace que apt este consciente del calamar-deb-proxy.

Para instalar el servidor, simplemente "sudo apt-get install squid-proxy deb-avahi-tools" en el equipo que desea que el servidor se encuentre habilitado. Esto instalará el servidor de almacenamiento en caché de squid y el avahi (Bonjour) utilidades de configuración automática de red, y comenzar a ambos servidores, por lo que el almacenamiento en caché del proxy squid empezará a emitir su disponibilidad en la red. A continuación, un "sudo apt-get install squid-deb-proxy-client" en cada computadora con Ubuntu 10.04 (incluido el servidor squid-deb-proxy) instalará la configuración de apt. Usted desea instalar el cliente en el servidor, así que cada vez que el servidor de descarga de actualizaciones en caché las actualizaciones son obtenidas por el proxy squid. Esto también permitirá que el servidor para instalar ya improbables actualizaciones a través del proxy.

Una vez hecho esto, el squid-deb-proxy es transparente para el usuario. El apt de cada máquina se verá en la red para un squid-deb-proxy, y si encuentra uno, ya pasará sus solicitudes a través de eso. El proxy caché de los .deb que vienen a través de él y los pone a disposición del cliente la próxima actualización que los necesita. El segundo cliente para solicitar estas mismas actualizaciones les tire hacia abajo desde el proxy squid, en lugar de tener que obtener de la Internet. Usted obtiene el beneficio de un repositorio local, sin la molestia de crear uno! 

La parte hermosa sobre squid-deb-proxy es que es una solución completamente transparente. Si usted tiene el cliente de squid-deb-proxy instalado en su computadora portátil y elige descargar una actualización, mientras que en viaje de negocios, su portátil puede grabar las actualizaciones desde el repositorio principal en el archivo sources.list, ya que el proxy no es en esa red de área local, la difusión de sus servicios a través de avahi. No hay necesidad de modificar su sources.list de ninguna manera, porque apt se da cuenta automáticamente. Es muy buen material.