|
Mòdul
5
|
Serveis
de xarxa amb GNU/Linux |
Exercici      |
| Personalització
del servei
Introducció En aquest apartat descriurem
els paràmetres que composen la configuració mínima
de l'Squid de manera que, cada administrador, pugui deixar-lo amb els valors
mes òptims, tenint en compte les característiques de l'equip
on estigui instal·lat i els clients a qui ha de donar servei. Els paràmetres que
governen l'Squid apareixen tots dins un únic fitxer de text anomenat
squid.conf
desat normalment al directori /etc/squid.
Cada
cop que s'inicia llegeix aquest fitxer per adaptar el seu funcionament
als desitjos de l'administrador del sistema. Qualsevol modificació
de la configuració pot 'activar-se' sense haver d'aturar el servei,
executant l'ordre: # squid -k reconfigure Aquests
són els punts que ens permetran conformar una configuració
mínima completament operativa i segura: - Usuari
amb què s'executarà l'Squid
Usuari amb què s'executarà l'Squid Per evitar problemes de seguretat
és molt recomanable que l'Squid i els seus processos associats no s'executin
amb drets de l'usuari root. Així doncs crearem
un usuari i un grup de nom squid, per exemple, i l'inclourem dins
la configuració amb el paràmetre: cache_effective_user
squid
a partir d'aquest moment
podem arrencar el servei com a root i l'Squid adquireix els drets
de l'usuari squid. Aquest usuari doncs ha d'ésser
el propietari del directori on vulguem emmagatzemar la cache i també
d'aquell on hi desarà els logs, sinó, podem tenir problemes de
permisos. Selecció del port per atendre les peticions HTTP Per defecte el programari Squid
treballa pel port 3128; en les jerarquies europees normalment s'utilitza
el port 8080 per als serveis de cache. Així doncs hem de
modificar la configuració per fer que l'Squid respongui a les peticions
HTTP pel port normalitzat: http_port 8080 Aquest paràmetre també ens permet poder instal·lar més d'un Squid a la mateixa màquina, per exemple per avaluar una nova versió, senzillament indicant en el seu fitxer de configuració un port alternatiu, com pot ser el 8085. Relació amb altres caches, treball en jerarquia Tal com ja vam comentar en el resum de les funcionalitats de l'Squid, una de les seves millors prestacions és la facilitat de crear jerarquies de caches, per aprofitar al màxim el contingut i les connexions exteriors de tot el conjunt dels proxy d'una mateixa xarxa. Per defecte els proxy-cache dels centres només tenen un sol 'pare' el host proxy.xtec.es. Aquest enllaç el defineix a la línia: cache_peer proxy.xtec.es parent 8080 0 no-query no-digest default composada per: - El nom o adreça IP de l'equip amb el que ens volem enllaçar (proxy.xtec.es). - El tipus de relació: -- Pare (parent), aquest
proxy ens donarà l'objecte que li demanem, tant si el té a
la cache com si no. En molts casos ha d'anar a buscar-lo a Internet
i el lliurarà al seu fill. -- Germà (sibling),
aquest proxy només ens donarà l'objecte que li demanem si
el té a la cache, mai sortirà a l'exterior a cercar
res per als seus 'germans'. - El port pel que serveix
les peticions HTTP (8080).
- El port pel que serveix
les peticions ICP (0 = desactivat), protocol amb transport UDP que permet
interrogar prèviament als diferents 'pares' per saber quin d'ells
té l'objecte que l'usuari ens demana. - Els paràmetres opcionals
de la relació
Dins el fitxer squid.conf.default
hi ha una descripció dels altres paràmetres opcionals que
poden aplicar-se depenent de la relació 'pactada' entre els proxy.
Dimensionat
de l'espai de cache al disc i a memòria RAM
Tal com es va comentar a
l'apartat de requeriments necessaris l'Squid treballa bàsicament
amb un espai de disc i memòria RAM que utilitzarà de forma
exclusiva per emmagatzemar els objectes de la cache.
Caldrà doncs mesurar
aquests dos paràmetres en l'equip on vulguem posar en marxa el servei
de manera que treballi amb la màxima agilitat i no generi problemes
de rendiment al servidor, tenint en compte les seves altres possibles utilitzacions.
La mida d'aquests 'magatzems'
de disc dur i memòria es fixen amb els paràmetres cache_dir
i cache_mem respectivament.
Per exemple, suposem un equip
amb 16 Mb de RAM i un disc de 500 Mb.
Hi hem instal·lat
el SO Linux (153 Mb aprox. fent la instal·lació mínima)
amb les següents particions:
resultant un espai disponible
d'uns 295 Mb.
Així doncs les variables
de què disposem són:
16 Mb de RAM
Els paràmetres més
recomanables:
cache_dir ufs /var/spool/squid
100 16 256
cache_mem 4 MB
Com a regla general, podeu dimensionar aquest valor a una quarta part de la RAM total del sistema. En aquest cas, deixem, per al funcionament
normal del SO, 195 Mb de disc i 8 Mb de RAM.
En l'apartat final d'aquest
mòdul veurem com podem monitoritzar el rendiment del nostre servidor
i si el sistema ho permet augmentar les mides de cache de disc i
memòria per millorar l'aprofitament de l'equip.
Control
d'accés als serveis del proxy Squid
Com qualsevol bon servei
que hagi de treballar dins una xarxa de gran abast com l'actual Internet
l'Squid incorpora una gestió molt potent de control d'accés.
Aquesta funcionalitat de
l'Squid ens permetrà entre d'altres coses:
- Protegir el nostre proxy
de connexions externes, evitant que s'hi "pengin" clients desconeguts que
podrien saturar la nostra connexió amb l'exterior.
- Protegir als clients d'accessos
a ports classificats com a "perillosos" servint com a primer front de seguretat
contra els possibles atacs fets des de la Web destinats als SO més
vulnerables de les estacions de treball.
- Confeccionar de forma racional
l'estructura jeràrquica de caches, direccionant si convé
les peticions de certs dominis a cadascun dels pares, autoritzant nous
fills o germans, etc.
Analitzarem el conjunt mínim
de regles de control d'accés que permet treballar correctament amb
el PC clients de la nostra xarxa local amb l'adreçament 192.168.0.0
/ 255.255.255.0 i l'enllaç amb el proxy de la XTEC.
Les ACL (llistes de control
d'accés) es defineixen en dos passos, el primer descriu la pròpia
acl i el segon detalla l'aplicació o el destí d'aquesta:
Definició ACL
# Afegim a les definicions
que inclou l'Squid per defecte
acl clients src 192.168.0.0/255.255.255.0
acl xtec_manager src
193.145.88.0/255.255.255.0
Aplicació ACL
# Afegim les regles d'aplicació
de les nostres ACL
http_access allow
manager xtec_manager
http_access allow
manager clients
http_access allow
clients
# Deixem les que tanquen
les normes http_access
http_access allow localhost
http_access deny all
icp_access deny all
miss_access allow
clients
Vistes les definicions bàsiques
no ens seria gens difícil poder acceptar els clients d'una segona
xarxa, per exemple la 192.168.2.0/255.255.255.0.
Caldria afegir a les definicions
d'acl:
acl clients_segona_xarxa
src 192.168.2.0/255.255.255.0
i dins l'aplicació
de les acl unes entrades per garantir el permís:
http_access allow
clients_segona_xarxa
Reiniciant el procés
Squid (squid -k reconfigure) els nous clients podrien començar
a treballar sense veure el missatge d'accés denegat.
Dins el fitxer squid.conf.default
podreu trobar altres tipus de declaracions d'acl que us poden servir en
altres casos.
Restriccions
d'accés a nivell d'URL
Tot i que es tracta d'una
aplicació de les llistes de control d'accés ho detallem en
aquest apartat de forma separada, tenint en compte la seva naturalesa un
xic especial.
Les acl són tan potents
que permeten prendre una acció, fins i tot depèn de la URL de la
pàgina que l'usuari demani a l'Squid.
Això permet fer un
control d'accés que s'activi segons 'la paraula' que aparegui a
la URL, i llavors passar a denegar l'accés.
Si afegiu a la configuració
la declaració i l'aplicació de la següent acl:
acl url_denegades
url_regex "/etc/squid/llistat.txt"
http_access deny url_denegades
reinicieu l'Squid i si dins
l'arxiu llistat.txt hi ha:
llistat.txt
els clients rebran el missatge
d'accés denegat quan demanin una URL on apareguin les entrades
"esquirols.org" o "guineus.com", així doncs només cal anar
afegint dins aquest fitxer les URL que es vulguin 'filtrar'.
Si el que es vol és denegar
l'accés per paraules que poden composar el 'path' de la URL, no
el nom concret del host, es pot utilitzar l'entrada "urlpath_regex",
i comparar-la amb un fitxer de paraules 'indesitjades'.
Control
d'accés del proxy a l'exterior
Quan es treballa dins una
jerarquia de cache, on hi pot haver línies dedicades
exclusivament a connectar equips proxy, ens interessa moltíssim
assegurar que el nostre Squid no farà connexions de forma directa,
és a dir, sense passar pel 'pare' més proper.
Podem 'obligar' i de fet
ens interessa fer-ho, a que el nostre Squid faci totes les peticions al
seu 'pare' aprofitant al màxim aquesta jerarquia i els objectes
que hi ha.
Les següents entrades
dins el fitxer de configuració realitzen l'efecte comentat:
acl locals dst 192.168.0.0/255.255.255.0
always_direct allow
locals
never_direct deny
locals
Amb aquesta configuració
s'aprofita molt més la relació en jerarquia i augmenta la velocitat
però cal tenir en compte que les màquines que ens serveixen
(parents) esdevenen crítiques, doncs la seva aturada pot deixar
el nostre proxy sense accés a l'exterior.
Control
de l'aplicació de monitorització cachemgr.cgi
L'aplicació Squid
permet ésser monitoritzada des de qualsevol Navegador amb el cgi
cachemgr.cgi
desenvolupat pel mateix equip de treball.
Per poder consultar aquestes
dades de control des de l'aplicació
cachemgr.cgi és recomanable
assignar-li una contrasenya i com a mínim desactivar l'opció
que permet aturar l'Squid, per si algú desautoritzat aconsegueix
l'entrada al monitor.
Dins l'últim apartat
del mòdul veurem el funcionament del cachemgr.cgi, ara comentem
els paràmetres mínims per al seu funcionament:
cachemgr_passwd disable
shutdown
així queda desactivada
l'opció 'shutdown' i amb la contrasenya "squid" podem consultar
tots els altres paràmetres que ens ofereix el proxy.
Correu
electrònic de contacte amb l'administrador del sistema
Quan l'Squid presenta a un
usuari, que treballa amb el Navegador, un missatge d'error per qualsevol
motiu, ofereix la possibilitat que aquest pugui posar-se en contacte
amb l'administrador indicant-li una adreça de correu electrònic.
Aquesta adreça l'especificarem
amb l'entrada:
cache_mgr cachemgr@linux.intracentre
Moltes vegades és la manera
més ràpida d'adonar-nos que l'Squid té un problema,
doncs els usuaris ho detecten immediatament.
Nivell
i rotació del registre de funcionament (logs)
L'Squid manté un registre
del seu funcionament i de la gestió del magatzem de cache
de forma separada en quatre fitxers de 'log' localitzats als directoris:
1) /var/log/squid
access.log -
anota totes les peticions fetes pels clients al proxy squid. El contingut
d'aquest fitxer es processa i permet generar estadístiques del rendiment
de la cache.
Segons el nivell de peticions
que rebi el proxy aquest fitxer pot tenir un creixement força elevat,
arribant a superar 1 Mb per minut. Cal tenir-ho en compte doncs es pot
omplir la partició on hi hagi el directori /var/log/squid
i
deixar el servidor sense recursos si és el directori arrel.
cache.log -
anota les possibles incidències en la gestió de la cache,
els processos d'arrencada i aturada, la relació entre cache,
etc.
El seu creixement és molt
més lent, només pot augmentar de forma important si hi ha
algun problema reincident en el funcionament de l'Squid.
store.log -
anota l'estat de tots els objectes del magatzem de la cache.
Normalment aquest fitxer
no aporta cap tipus d'informació prou interessant per l'administrador,
el més recomanable és desactivar aquest registre afegint a la configuració
la línia:
cache_store_log none
Per defecte doncs el nivell
del registre és mínim ( 1 ) i pot augmentar-se gradualment fins
al màxim detall ( 9 ) quan cal depurar algun tipus d'error. Atenció,
un nivell molt alt de registre pot ocupar molt espai de disc en pocs minuts
de funcionament !
La rotació per defecte
és zero ( 0 ), no hi ha rotació o aquesta la fa una aplicació
externa com per exemple logrotate.
Quan s'activa la rotació
de l'Squid ( squid -k rotate
) i el paràmetre és
ú (1), els fitxers access.log i cache.log es tanquen,
es posen a zero i se'n fa una còpia.
Si ho augmentem a dos ( 2 ) tindrem dues còpies del registre anterior abans de l'execució
de la rotació, si el posem a tres ( 3 ) mantenim les dades de tres
rotacions i així fins a un màxim de deu còpies.
Els fitxers queden emmagatzemats
amb l'extensió:
access.log.0
indicant amb zero ( 0 ) la
còpia de la primera rotació.
Els paràmetres necessaris
per governar el registre quedaran:
debug_options ALL,1
Per evitar un creixement
indefinit dels fitxers de registre la instal·lació del paquet
rpm configura una rotació automàtica, cada setmana i emmagatzemant
cinc còpies, utilitzant la utilitat logrotate
i deixant sense
validesa el nivell de rotació intern configurat.
En molts casos aquesta rotació
no és convenient perquè emmagatzemar els logs de cinc setmanes demana
molt d'espai de disc i també perquè obliga a tenir la màquina
en marxa a les 4:02 de la matinada doncs és l'hora en què el sistema l'executa.
Dins l'últim apartat
d'aquest mòdul veurem com adaptar la rotació a les nostres
necessitats i aprofitar les dades per crear estadístiques del funcionament
de l'Squid.
2) /var/spool/squid
swap.state - fitxer
d'ús intern que manté un índex de tots els objectes
que hi ha emmagatzemats dins l'estructura de disc.
Aquest fitxer té un
creixement directament proporcional al nombre d'objectes que hi pugui haver
a la cache, per això cal assegurar sempre una reserva de
disc lliure en la partició on hi haurà el magatzem.
Per exemple, si s'utilitza
la partició /magatzem
de 500 Mbytes dedicada per a la cache, allò més lògic seria
utilitzar el paràmetre:
cache_dir ufs /magatzem
500 16 256
i un cop verificat que la
partició és de l'usuari "squid" amb què s'executa realment el proxy,
inicialitzaríem el nou espai
(
squid
-z ), i posaríem
en marxa l'Squid.
En principi funcionaria sense problemes però arribaria un moment que els objectes emmagatzemats
més la mida del fitxer swap.state ocuparien la totalitat de la partició
i l'Squid donaria un error de disc ple, doncs ell esperava poder
arribar a desar 500 Mb d'objectes... (no compte amb el que pot ocupar el
fitxer swap.state...).
Per evitar aquests errors
el més recomanable és deixar una reserva del 10% de l'espai que
vulguem dedicar a magatzem d'objectes.
Així l'opció
òptima configuraria l'espai de disc amb un marge de 50 Mb:
cache_dir ufs /magatzem
450 16 256
El fitxer swap.state
no es pot incloure en cap política de rotació de logs, el
seu contingut és vital per mantenir l'estructura d'objectes de l'Squid
i la seva gestió és interna.
|
|||||||||
 |
 |