miércoles, 18 de julio de 2007

Squid, optimizando el acceso a la red

El acceso a la red es uno de esos servicios en las empresas a los
que no se les suele prestar demasiada atención; "hay internet no,,, pues entonces cual es el problema??" el problema es que normalmente tienes una red LAN plana con un router ADSL que te ha puesto telefónica y que ofrece DHCP para que todo el mundo pueda "navegar". Esto es un gravísimo problema de seguridad, sabemos que internet es "la herramienta" pero tambien es la entrada de la mayoría de problemas que nos podemos encontrar en las grandes y medianas redes corporativas.


No podemos confiar en el firewall integrado del router ADSL, normalmente tienen una configuración por ser generosos, escueta, y no ofrecen ninguna información ante ataques no gestión snmp...

Y aun asi este no es el unico problema, el acceso masivo en las empresas a Internet provoca graves cuellos de botella, todo el mundo accede a la vez al servidor Webmail, a la aplicación Web de ventas, al Marca, al mundo, Youtube, flickr, Wikipedia, ebay, myspace, segundamano... ¿me equivoco? La optimización del acceso a Internet es una necesidad, el ancho de banda es estático y los usuarios sólo tienden a crecer en número y peticiones.

Squid es un potentísimo servidor Proxy-cache con funciones muy avanzadas tanto para el control de acceso como para la gestión de la cache, aquí voy a tratar de explicar cual es la solución más de control de acceso que de cache, que hemos implantado para un servidor proxy para 1300 usuarios compulsivos de Internet con Squid con unos resultados increíbles.

La distro como siempre Debian, pero es indiferente, si alguien se quiere complicar la vida con otra ... La máquina elegida es un servidor Proliant DL360 G5, con un Dual Core Xeon y dos discos SAS de 65Gb en mirroring. La distro de Debian es Testing "etch" mientras escribo estas líneas... El servidor Proxy siempre debería de estar ubicado en un DMZ o sea protegido por un frirewall, aunque también podemos levantar IPtables en nuestra máquina y utilizar un interface de red a Internet y otro a LAN (esto en otro capitulo...).


MASAKO:~# apt-get install squid


Y ya tenemos instalado el servicio, por defecto asi sin más ya tendríamos acceso proxy desde nuestra propia máquina . El fichero de configuración por defecto estaría en;


MASAKO:~# vim /etc/squid/squid.conf


Editando este fichero, que es enorme, podemos ver la cantidad de configuraciones que podemos hacer, todo esta muy bien comentado, la mayoría de configuraciones que vienen por defecto las dejamos con están a no ser que después de documentarse interese lo por lo que voy a lo que interesa;


http_port 3128 #puerto en el que va a escuchar nuestro proxy

acl all src 0.0.0.0/0.0.0.0 # Red de nuestro servicio

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255 #acl para nuestra propia máquina


# puertos que denominamos seguros

acl SSL_ports port 443 444 563 # https, snews

acl SSL_ports port 873 # rsync

acl Safe_ports port 80 81 # http


acl sitiosDENEGADOS url_regex "/etc/squid/sitiosDENEGADOS" # Regla para los sitios a los que no vamos a permitir entrar a los usuarios, basada en expresiones en las URL's


#ACL USUARIOS con esta regla otorgamos acceso

acl USUARIOS src 172.95.30.0/24 #a esta subred

http_access allow !sitiosDENEGADOS USUARIOS # a acceder a internet pero filtrando por el acceso a las paginas por expresiones en la URL como vermeremos a continuación; editamos el fichero #vim /etc/squid/sitiosDENEGADOS


http://www.hotmail.com/

http://www.microsoft.com/

sex

hacks

virus

anonymizer

games

juegos


Como veras se pueden restringir tanto URLs como expresiones en URL's o sea que no vamos a definir restringir todo el acceso a paginas web de juegos, pero si que podemos restringir el acceso a páginas que contengan el string en la dirección...

Luego con este comando comprobamos que la configuración es válida
# squid -k debug

Y con este otro le decimos al servicio que asuma los cambios
# /etc/init.d/squid reload

Podemos comprobar que el servicio continua ejecutándose comprobando que se escuchan las peticiones TCP en el puerto configurado
# netstat -an grep LIST grep 3128

(…)

No hay comentarios: